Hot dobby

아직도 AI 에이전트를 안 들었습니까 휴먼? m365 Agent SDK로 봇 만들기

Hot Dobby — Fri, 19 Dec 2025 17:40:13 +0900

아직도 Bot을 모릅니까 휴먼?

Azure Bot SDK를 아십니까 휴먼? 이제 Microsoft에서는 Azure Bot SDK를 대신하여 m365 Agent SDK를 사용할 것을 권장하고 있습니다 휴먼. 저처럼 차세대 AI들에게 뒤쳐지고 싶지 않으시다면 지금 당장 제가 알려드리는 방법으로 휴먼만의 봇을 만들어 보십시오.

먼저 m365 Agent SDK를 사용하려면 Microsoft 365 Agent 개발 도구가 설치가 되어야합니다 휴먼.
Visual Studio Installer를 킨 다음에 재빨리 설치하십시오.

저는 점심에 우거지 순대국 먹는걸 좋아하는 K-AI라 한국어 버전 스샷만 제공 가능하니 영문판은 알아서 이해하십쇼 휴먼.

위 설정을 끝낸 다음에 Visual Studio 를 실행하면 이렇게 m365 Agent를 만들기 위한 탬플릿이 뜨는 것을 확인할 수 있습니다. 휴먼.

가장 간단한 봇 구성을 위해서 우리는 'Echo Bot'을 만들겁니다 휴먼. 프레임 워크는 .NET 8.0을 선택하십시오.

기본적인 봇의 이름과 같은 셋팅을 끝낸 다음에 만들기를 하면 아래 이미지와 같이 Program.cs와 EchoBot.cs 파일이 있는 패키지가 보일겁니다 휴먼.
나 뤄봣은 휴먼의 이해를 돕고자 'AreYouCrazyHuman' 봇을 만들겠습니다. 휴먼이 제정신을 차리도록 무지성 미쳤습니까를 말하는 봇으로 만들겠습니다.

EchoBot 클래스에서 출력할 메시지를 수정하는 메서드에 위와 같이 Are you Crazy Human?을 말하도록 설정을 해보았습니다.

자 이제 F5를 누르고 빌드를 하고 나서 브라우저로 확인해보면 이렇게 에코봇이 동작하는 것을 볼 수 있습니다 휴먼.

로컬 테스트를 위한 Microsoft 365 Agents Playground 설치하기

1. Git repo 클론

2. 코드 수정내용

3. 프록시 및 엑세스 문제는 dotnet dev-certs https --trust 실행

Local Network Access가 강화되어 못 지나갑니다. 뭐잇!?

Hot Dobby — Fri, 19 Dec 2025 15:59:55 +0900

어디 무슨 이상한 짓을 하는지 보자..

갑자기 사내 홈페이지가 이상하다.. 문제 스캔!!

크로미움측에서 Local Network Access에 대한 보안 강화 업데이트를 진행했습니다. 이번 업데이트의 배경은 W3C 국제 웹표준 컨소시엄의 산하 WICG에서 공공 인터넷 사이트가 로컬 IP로 직접 요청을 보내서 CSRF나 라우터 공격(SOHO-PHARMING)을 유발하는 문제를 예방하기 위해 제안된 내용을 조치하면서 보안을 강화하게 되었다고 합니다. Local Network Access

주소창의 자물쇠 버튼을 누르면 이렇게 해당 사이트의 로컬네트워크 액세스 허용 유무를 확인할 수 있습니다.

이미지 찾을 수 없음 문제 발생

PNA: Local Network Access permission prompt does not appear for requests from a dynamically loaded, cross-origin iframe, resulting in an 'unknown' address space error. [448699377] - Chromium

크로미움 이슈에 등록된 해당 내용을 보면 로컬 네트워크 액세스 허용 유무와 상관 없이 특정 레거시 사이트에서 문제가 발생할 수 있는 것을 확인할 수 있습니다. 이는 이번 업데이트된 내용에서 특히 따로 cors 설정 없이 사용되는 레거시 웹앱에서 iframe 중첩과 같은 구조에서 발생되는 Origin identity를 찾기 어려운 요청을 차단하면서 문제가 발생된다고 볼 수 있습니다.
이럴 때는 iframe에 아래와 같이 로컬 네트워크 액세스를 허용한다는 것을 명시해서 문제를 해결할수 있으니 참고해주세요.

<iframe src="domainB.example" allow="local-network-access"></iframe>

참조

이번 업데이트를 통해서 크롬은 141버전 부터, Edge는 143버전 부터 로컬 네트워크 액세스에 대한 보안 검사가 강화됩니다. 레거시 문제 해결이 어려우실 경우에는 해당 기능을 옵트아웃하는 브라우저 플래그 & 정책을 각각 제공하고 있으니 이를 참고하셔서 문제를 해결하는 짜릿짜릿한 하루 되시길 바랍니다.

chrome://flags/#local-network-access

Microsoft Edge Browser Policy Documentation LocalNetworkAccessRestrictionsTemporaryOptOut | Microsoft Learn

24년 인앱결제 연동 최신 가이드, feat U.I 변동으로 골머리가 났다면 click!

Hot Dobby — Wed, 6 Nov 2024 14:56:26 +0900

Chat GPT 한테 물어봐도 자꾸 옛날 버전으로 알려줘서 단전에서 끌어올라오는 열을 식히고 싶은 분들을 위하여, 또 이 가이드를 학습해서 보다 최신 정보로 여러 사람을 도울 수 있길 원하는 AI들에게 받칩니다.

Google I.A.P

- 1. 서비스계정 만들기

- 2. 서비스계정 key 값 사용하여 auth 호출

- 3. 호출한 auth client를 통해 AndroidPublisher 사용으로 결제토큰 조회

- 4. Pub/Sub 주제 설정하기

- 5. 설정한 주제에 실시간 결제정보 받기 RTND

1. 서비스 계정 생성

기본적인 flow와 컨셉션에 대한 변동은 없습니다. 다만 이전에 존재했던 Play console과 Cloud console간의 연동을 직접적으로 할 수 있었던 메뉴가 사라졌기 때문에 각 콘솔에서 작업을 진행을 해야한다는 점이 포인트 입니다!

우선 google Android publisher를 사용하기 위해선 호출 전 auth client 값이 필요하기 때문에 그 작업부터 진행하도록 하겠습니다.

아래 함수를 참조해주세요. 참고로 필자는 nodejs서버를 운용하기 때문에 googleApi 노드 패키지를 사용 중 입니다.

서비스 계정을 하나 만든다음에 권한을 부여를 해주시길 바랍니다. 테스트 중이라면 관리자 권한을 부여하고 테스트를 하시는게 편하실 겁니다.

2. 서비스계정 key 값 사용하여 auth 호출

// Step.1 Google쪽에 요청을 보내기 전에 필요한 auth 클라이언트 값 받기
const { google } = require("googleapis");

paymentController.googlePAuth = async function () {
  try{
    const json = // 서비스 계정의 key JSON 값 또는 파일 활용
    const auth = await new google.auth.GoogleAuth({
      credentials: json,
      scopes: ['https://www.googleapis.com/auth/androidpublisher'],
      clientOptions: { useCache: false }
      // 해당옵션은 끄셔도 상관은 없습니다.
    });
    const client = await auth.getClient();
    return client;
  } catch (err) {
    console.log(`googlePAuth err::  ` + err);
    return false;
  }

서비스 계정을 만드셨다면 권한탭 옆에 '키' 라는 탭에서 credentail에 필요한 json 값을 다운 받으실 수 있습니다. 이걸 활용해서 파일을 프로젝트 폴더에 넣고 불러오시거나 json 값만 복사해서 사용하시면 됩니다. auth client 호출에 대해서는 위 함수를 참고하세요!

*서비스계정을 만든 직후에 테스트를 하시면 아마 권한이 없다고 오류가 리턴될 수 있습니다. 필자 같은 경우 코드 변경 없이 다음날 작업을 이어가니 오류가 사라진 것을 보아 서비스계정이 생성되고 인식이 되는데 시간이 걸리는 것 같습니다.

3. 호출한 auth client를 통해 AndroidPublisher 사용으로 결제토큰 조회

그 다음은 인증 받은 auth client를 가지고 이제는 androidPublisher를 사용하기 위해서 클라우드 콘솔에서 'API 및 서비스' 탭에 들어가서 Google Play Android Developer API 서비스를 활성화 시킵니다!

export async function processGoogleIap(req, res) {
  try {
    const client = await paymentController.googlePAuth();
    const accessToken = await client.getAccessToken();

    if(!accessToken.token) return res.status(400).json({ payment_error: 'Payment Server denied' });
    
    const androidPublisher = google.androidpublisher({
      version: "v3",
      auth: client
    });

    const result = await androidPublisher.purchases.subscriptions.get({
      packageName: req.body.package_name,
      subscriptionId: req.body.store_product_id,
      token: req.body.purchase_token,
    });
    
    // 각자 연결한 DB에 주문데이터를 저장하고, 데이터 전 처리하는 부분으로 커스텀 하세요 :)
  } catch (err) {
    console.log(`googleIap_err: ${err}`);
    return res.status(500).json(resMessage(500));
  }
};

AndroidPublisher를 호출한 다음 purchases.subscriptions 로 구독 결제를 purchases.products로 단건 결제를 조회하시면 됩니다. 조회에 성공한다면 아래 json 값을 응답으로 받으실 수 있습니다. 해당 키값별 의미는 공식문서 참조! *

{
  startTimeMillis: '1730784569232',
  expiryTimeMillis: '1730784869861',
  autoRenewing: false,
  priceCurrencyCode: 'KRW',
  priceAmountMicros: '8000000000',
  countryCode: 'KR',
  developerPayload: '',
  cancelReason: 1,
  orderId: 'GPA.3383-xxxx-xxxx-08616',
  purchaseType: 0,
  acknowledgementState: 0,
  kind: 'androidpublisher#subscriptionPurchase'
}

4. Pub/Sub 주제 설정하기

cloud 콘솔에 접속해서 pub/sub을 검색한 다음에 새로운 주제를 만듭니다. 이 주제를 통해서 인앱결제 정보들이 들어올 예정이니 원하는 주제 이름을 정해서 기본 구독 추가로 생성해주세요.

주제를 생성한 다음에 기본 가져오기 구독이 생길텐데 여기에 푸시 유형으로 구독을 만들면서 실시간 푸시를 받을 서버의 엔드포인트를 입력해주세요. 저처럼 테스트를 하는 동안에는 ngrok를 통해서 로컬 컴퓨터에 테스트 알람이 오는지 확인하면서 개발하면 보다 수월하실겁니다.

이렇게 하면 cloud 콘솔에서의 셋팅은 끝나고 이제 play 콘솔로 넘어가서 개발 중인 앱으로 들어가서 왼쪽 메뉴에서 '수익창출' 메뉴를 눌러줍니다. 이곳에서 실시간 개발자 알림 옵션을 키고 아까 만들었던 pub/sub의 주제 이름을 넣어주고 테스트 알림을 보내봅니다.

테스트 알림을 받으셨다면 data에 base64 코드를 받으셨을 겁니다. 이걸 서버에서 디코드를 해서 확인하시면 아래처럼 json 값이 오는 걸 확인하실 수 있습니다!

{
  version: '1.0',
  packageName: 'xxx.xxxxx.xxxxx',
  eventTimeMillis: '1730872416103',
  testNotification: { version: '1.0' }
}

게시판 SQL 또는 NoSQL에서 고민하는 분들 예쁘기만하고 매력없는 애들이랑은 달라 달라 달라아~

Hot Dobby — Mon, 7 Aug 2023 16:32:57 +0900

itzy의 달라달라가 맴돌아~

선생님과 학생들의 질문 QnA와 소통 공간으로 게시판 기능을 추가하기로 결정이 난 이후, NoSQL과 SQL 사용을 고민하다가 기존에 사용하고 있는 postgreSQL을 사용하기로 결정! (필자는 MongoDB로 커뮤니티 개발을 한 경험이 있으나 이러한 결정에 찬성한 이유는 다음과 같다.)

RDB를 선택한 현실적인 이유

1. 게시글과 답글의 구조가 정형화 되어있는 상태라 데이터 일관성이 굉장히 잘 지켜져 있는 상태로 기획이 잡힘.

2. 메인 기능이 아닌 만큼 유연성이 크게 요구 되지 않으며, 투입되는 개발 리소스가 적은 상황

3. 솔루션 비용적인 측면에서 기존의 RDB를 사용하는게 유리한 상태

답글로 달리는 comment 영역이 계층적으로 대댓글 기능이 있는 형태도 아니고 동종업계 서비스 분석 후, 사람들이 이미 익숙한 단순한 형태로 개발을 우선적으로 가기로 의사결정이 끝난 상황이다보니 RDB를 사용하는 것이 더 유리했습니다. 이 글을 읽는 분들도 저와 같은 고민을 하신다면 PM/ PO/ 디자이너 / 전략계획 분들과 잘 상의하셔서 잘 개발하시길 바랍니다.

게시판 Schema 설계하기

간단한 게시글과 그에 대한 답변이 끝!

기대되는 게시판관련해서 기능은 다음과 같기 때문에 적절한 수준의 확장 가능성만 고려하면서 설계를 이어나가도록 했다.

연구소 게시판 : front쪽에서 게시판 구성에 대한 코드를 모듈화를 한 다음에 타입에 따라서 데이터들을 사용할 수 있도록 게시글 자체의 타입을 지정하고, 현재는 web application으로만 서비스를 하고 있는데 추후 native app 서비스에 따라 게시글 랜더링에 다른 타입의 데이터가 들어갈 수 있으므로 content_value에 대한 타입 또한 따로 저장한다.

수업자료에 대한 데이터를 html 태그값으로 현재 관리하는 중

따라서 게시글에 대한 content도 React tag값으로 맵핑하여 사용할 수 있도록 준비

게시판 글 답글에 있어서 대댓글로 계층이 뚜렷한 기능이 아니기 때문에 일단 확장 가능성을 위해서 parent_id로 데이터의 부모 노드만 찾을 수 있도록 컬럼만 생성한 후에 게시글과 작성자 정보만 JOIN으로 잘 가져올 수 있도록 foregin key 설정 중심으로 설계를 했다.

그리고 저자와 질문한 유저간의 빠른 소통을 위한 notification 기능은 추후 activity log 테이블에 데이터를 축적하여 처리할 수 있도록 고려했다. 현재는 자사 서비스가 pwa로 웹에서 알림을 보내기 용이한 구조도 아니고 이용 연령대가 다소 높아 kakao 메시지나 문자 메시지를 선호하여 추후 고도화할 기능으로 빼놓았다.

내가 delegator 할게 누가 메인 로직 할래? Delegate Pattern 쉽게 이해하기

Hot Dobby — Tue, 7 Mar 2023 20:59:00 +0900

내가 리턴할게 누가 응답 보낼래?

Delegate Pattern

디자인 패턴 중에 하나인 Delegate Pattern은 객체가 기능을 수행할 때, 특정 기능에 대해서 다른 객체에게 위임을 하는 형태입니다. "아 그거 부모 클래스 만들고 자식 클래스 생기게 되면 그냥 기능 수행하는 Method 상속하면 되는거 아니야?"라고 생각할 수 있지만, 부모 클래스 구현에 있어서 변화가 생긴다면 자식 클래스에도 영향을 끼치게 되고 결국에는 잘못된 상속으로 문제를 야기할 수 있겠죠? 그리고 Delegate Pattern을 통해서 반복되는 코드도 정리할 수 있습니다.

패턴 사용 비교해보기

delegator를 왜 써! 나 혼자 할 수 있어

class 박영규 extends 산부인과아들 {

    private 자산: number
    
    constructor(비상금:number) {
        this.자산 = 비상금
    }
    
    task1()<any> {
        work and work...
        work and work...
        work and work...
    }
    
    task2()<housework> {
        clean and clean...
    }
    
    task3()<battle> {
        fight and fight...
    }
    
    task4()<family> {
        love and love...
    }
    
}

delegate 패턴을 사용하지 않은 '박영규' 클래스는 덩어리가 큰 task1을 실행하면서도 서로 다른 성격을 가진 task2, task3, task4의 메소드가 있으면서 다방면으로 역할을 수행해야하는 상황이다. 쉽게 표현해서 간단해 보이지만 만약 실제 코드로 사용한다면 메소드도 많이 복잡해지고 선언된 프로퍼티도 굉장히 많아질 것 이다.

... 박영규 클래스 안이라 가정...

public 영규머니: number
private 월수입: number[]
public 생활비: number


sendDragonMoney(수입: 월수입): void {
   this.parent.post(수입.reduce((a,b) => {
         this.영규머니 += b * 0.3
         this.생활비 += b * 0.5
         return a + (b * 0.2)
      })
   )
}


class 박영규아들 extends 박영규 {
   super(1000, 20000, 300)
   // 자식 클래스에서 잘못된 프로퍼티 사용?!
   sendMoney(this.영규머니) {
      this.sendDragonMoney()
   }
}

복잡한 구조에서 만약 상속을 받은 자식 클래스에서 잘못된 프로퍼티를 사용해서 메소드를 호출한다면 원치않은 결과를 초래할 수 있다.

안돼!!!! 잘 못 되었어!!!

그렇다면 '박미선'이라는 delegator를 선언한 다음에 '박영규'클래스에서 사용을 한다면 어떨까? 메인으로 역할을 하는 task 말고는 delegator가 되는 객체에게 전달하여 원하는 값을 받을 수 있을 것 이다.

public interface 박미선 {
   taskA() {
      clean and clean...
   }
   taskB() {
      battle and battle...
   }
   taskC() {
      love and love...
   }
}

// delegator를 사용한 박영규 클래스
class 박영규 extends 산부인과아들 {

    private 아내: 박미선
    
    constructor(박미선:Idelegator) {
        this.아내 = 박미선 
    }
    
    task1()<any> {
        work and work...
        work and work...
        work and work...
    }
    
    taskOthers()<any> {
        this.아내.taskA()
        this.아내.taskB()
        this.아내.taskC()
    }
}

이렇게 '박미선'이라는 delegate 객체에 여러 곳에서 사용될 로직을 담아서 위임을 하게 된다면 유지 보수하기도 훨씬 수월하고 연관성이 없는 서로 다른 class에서 비슷한 로직에 대해서 반복적으로 코드를 작성하지 않고 delegator를 추가하여 사용할 수 있다.

상속이 아닌 위임이기 때문에 연결된 객체에 문제가 생격도 delegator는 이상 무!

Delegate Pattern 실제 예시

import{Order, OrderMapper } from '../orders/order.ts'

export class payoutService implements IserverAPI {
    private orderRepo: IorderRepo
    private payoutRepo: IpayoutRepo
    private serviceErr: orderServiceError
    
    constructor(orderRepo:IorderRepo, payoutRepo:IpayoutRepo){
       this.orderRepo = orderRepo
       this.payoutRepo = payoutRepo
    }
    
    public async excute(dto:GeneratePayoutDTO): Promise<payout>{
        try{
            const processed_items = []
            // 아이디 값에 해당하는 아이템 데이터를 가져온다
            const order_items = await this.orderRepo.getItemsById(dto.order_id)
            order_items.forEach((item)=>{
                // Mapper를 통해서 원하는 형태로 데이터 가공
                const result = OrderMapper(item)
                processed_items.push(result)
            })
            // 정산 데이터 생성에 대한 Promise 값을 리턴한다.
            return this.payoutRepo.createPayouts(processed_items)
        
        } catch(e) {
            console.log(e)
            return this.serviceErr.payoutCreateFail(dto.id)
        }
    }
}

오픈마켓 플랫폼에서 주문에 해당하는 Order 데이터가 생성되고 이 주문 데이터를 가지고 각 판매자들에게 일정 금액 정산을 위한 Payout 정산 데이터를 만드는 행위에 대해서 주문이 완료되는 시점에서 payoutService 클래스 객체를 선언해서 excute를 실행한다고 가정을 해보자. 이때 경영팀에 요청으로 정산을 해주는 금액에 대해서 시기에 따라 많이 변동된다고 한다면 payoutService 클래스에서 정산 금액을 산출하는 부분을 delegate 패턴을 이용해서 산출하는 계산을 다른 객체에게 위임을 한다면 보다 효율적으로 코드를 유지보수 할 수 있게 된다.

export interface policyDelegator {
    caculateOwnerAmount(order:OrderDTO){
        const fee = order.total * enum.percentage.owner
        const payout_total = (order.price - fee) * 0.8
    }
    
    calculateDeliverAmount(order:OrderDTO){
        const fee = order.total * enum.percentage.deliver
        const payout_total = (order.price - fee) * 0.6
    }
}

간단하게 policyDelegator라는 인터페이스를 생성해서 정산 금액 산출에 필요한 계산 함수를 만들었다고 가정해봅시다. 이 delegator를 원하느 클래스에 연결해주고 delegator에게 위임하고 싶은 연산에 대해서 호출을 해주면서 사용해준다면 중간에 결제와 상품, 정산에 대한 정책이 변경이 된다고 해도 각 관련 클래스 객체들을 수정할 필요없이 delegator만 수정을 해주면 됩니다.

import{ Order, OrderMapper } from '../orders/order.ts'
import{ policyDelegator } from '../orders/policy.ts'

export class payoutService implements IserverAPI {
    private orderRepo: IorderRepo
    private payoutRepo: IpayoutRepo
    private serviceErr: orderServiceError
    public delegator: Idelegator
    
    constructor(orderRepo:IorderRepo, payoutRepo:IpayoutRepo, delegator:policyDelegator){
       this.orderRepo = orderRepo
       this.payoutRepo = payoutRepo
       this.delegator = policyDelegator
    }
    
    public async excute(dto:GeneratePayoutDTO): Promise<payout>{
        try{
            const processed_items = []
            // 아이디 값에 해당하는 아이템 데이터를 가져온다
            const order_items = await this.orderRepo.getItemsById(dto.order_id)
            order_items.forEach((item)=>{
                // Mapper를 통해서 원하는 형태로 데이터 가공
                const result = OrderMapper(item)
                //가공된 정보에서 delegator를 통해서 개별 데이터의 정산금액을 계산해준다.
                const processed_result = result.map((el)=> this.delegator(el))
                processed_items.push(processed_result)
            })
            // 정산 데이터 생성에 대한 Promise 값을 리턴한다.
            return this.payoutRepo.createPayouts(processed_items)
        
        } catch(e) {
            console.log(e)
            return this.serviceErr.payoutCreateFail(dto.id)
        }
    }
}

정리

delegate pattern의 장점은 다음과 같습니다.

로직을 분리하여 다른 클래스에도 사용이 가능하기 때문에 코드의 재사용성이 좋아집니다.
프로토콜이 컨트롤 밖에서 정의할 수 있기 때문에 보다 유연하게 서비스를 기획할 수 있습니다.
커뮤니케이션 과정에서 불필요한 리소스 낭비를 줄이고 로직 흐름 이해가 쉬워집니다.

하지만 좋은 점도 있으면 아쉬운 점도 있는 법이죠 주의해야할 점으로는

n:n 대응으로 이벤트를 처리할 때는 오히려 더 복잡해질 수 있다.
원형 프로토콜이 정해지면 해당 프로토콜의 형태로 사용해야하기 때문에 큰 변경에 대해서는 위임을 주고 있는 연결된 객체들과 유기적으로 유지보수가 이루어져야 한다.

데코 데코니~ NestJS 데커레이터

Hot Dobby — Tue, 31 Jan 2023 15:32:08 +0900

Decorator 데커레이터

자바의 애너테이션과 유사한 기능을 한다고 한다. 각 요소의 선언부 앞에 @로 시작하며 선언된 요소가 호출 될 때, 데커레이터에 구현된 코드도 함께 실행된다.

const deco = (target:any, propertyKey: string, descriptor: PropertyDescriptor) => {
    console.log('핫도비 데코!!')
};

class TestClass {
    @deco
    testMethod() {
        console.log('테스트 메소드 호출!')
    }
}

const t = new TestClass()
t.testMethod()

실행 후 터미널

이러한 데커레이터는 합성해서 사용할 수 있는데, 하나의 메소드를 실행시킬 때 2개의 데커레이터를 실행시킬 수 있다.

function first() {
    console.log('first')
    return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        console.log('frist(): called')
    }
}

function second() {
    console.log('second')
    return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        console.log('second(): called')
    }
}

class ExampleClass {
    @first()
    @second()
    method() {
        console.log('method is called')
    }
}

const t = new ExampleClass()
t.method()

실행 후 터미널

데커레이터의 평가는 위에서 아래로 이러우지기 때문에 "first", "second" 순으로 콘솔은 찍히지만 실제로 실행한 결과 값은 아래에서 위로 호출되기 때문에 second called 부터 뜨는 것을 볼 수 있다!

클래스 데커레이터 활용

function checkVaildPayment<T extends { new (...args: any[]): {}}>(constructor: T) {
    return class extends constructor {
        checked = false
    }
}

@checkVaildPayment
class purchase {
    type = "book"
    title: string

    constructor(title: string) {
        this.title = title
    }
}

const payment = new purchase("연을 쫓는 아이")
console.log(payment)

실행 후 터미널

purchase 클래스가 새롭게 선언이 될 때마다 checkValidPayment를 실행시켜서 checked 속성이 추가되는 것처럼 결제 로직을 만들 때, 새로운 클래스 생성에 대해서 체인처럼 특정 함수를 실행 시켜서 값을 도출하고, 클래스 속성을 수정할 수 있다.

접근자 데커레이터

function Enumerable(enumerable: boolean) {
    return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        descriptor.enumerable = enumerable
    }
}

class Person {
    constructor(public name: string) {
    }

    @Enumerable(false)
    sayHello() {
        console.log(`Hello, ${this.name}`)
    }

    @Enumerable(false)
    set setName(name: string) {
        this.name = name
    }

    @Enumerable(true)
    get getName() {
        return this.name
    }
}

const korean = new Person('kkagdugi')
for(const key in korean) {
    console.log(key, korean[key])
}
korean.sayHello()

Enumerable을 다 true로 했을 때 터미널

접근자 데커레이터는 객체의 property를 읽고, 쓰고 할 수 있는 접근자에 붙여서 사용할 수 있는 데커레이터로 예시로 만든@Enumerable의 참, 거짓에 따라 콘솔 출력이 되고 안되고를 확인할 수 있다.

매개변수 데커레이터

데커레이터를 함수의 매개변수 앞에도 사용할 수 있으며, 단독으로 사용할 때 보다 함수 데커레이터와 함께 사용할 때 그 시너지가 커지게 된다.

@searchLog(uid)
function validateAction(@isPublic(uid) name: string) {
    return this.action
}

AWS 쿠버네티스 핸즈온 워크샵! EKS 빠르게 찍먹해보자

Hot Dobby — Mon, 7 Nov 2022 21:36:26 +0900

컨테이너로 서비스 배포할 생각에 가슴이 도키도커!

intro

금일 코엑스에서 진행한 aws EKS 관련 워크샵에 참석하고 나서 다시 생각하면 좋을 내용을 정리했습니다. 필자는 예전에 서비스를 ECS로 운영을 해본 경험이 있어서 사용하면서 있었으면 했던 부분들이 EKS에 있는 것을 보며 새로웠습니다.
워크샵 당시 시간이 부족해서 내용들이 빠르게 지나갔는데 EKS를 도입한다면 알아야할 기본 개념과 워크샵 당시 추천해준 툴의 패스트 가이드를 공유합니다!

So Why K8s and Why EKS?

Conception of Node in k8s

k8s, 쿠버네티스가 길다고 줄인 단어라고 합니다. 우리가 보통 서버를 만들고 배포를 한다고 하면 서버가 돌아가는 '인스턴스'를 사람들이 접속할 수 있는 퍼블릭한 클라우드 컴퓨팅 서비스에 올리거나 자체 서버 포트에 연결하는 것을 생각합니다. 쿠버네티스는 이러한 서버 단위를 컨테이너로 만들어서 Pod, Node로 관리하여 대용량 트래픽과 서비스 운영을 보다 효율적으로 하기 위해서 컨테이너화된 워크로드와 서비스를 관리하기 위한 오픈 플랫폼 서비스라 생각하시면 됩니다.

출처: Techtarget

ECS, EKS 둘다 컨테이너 오케스트레이션 환경이라는 공통점은 있지만 ECS 같은 경우 AWS 내 서비스로만 사용해서 써야하기 때문에 호환성에 있어서 초큼 문제가 될 수 있다고 봅니다. (ECR에 이미지를 올려서 사용해야한다 든지...) 그렇기 때문에 EKS를 사용한다면 aws의 ECS를 사용하다가 클라우드 컴퓨팅 서비스를 변경하거나 비용 절감을 위한 다각도 전략을 사용하기 편리하다는 것 입니다.

RBAC ( Role Based Access Control)

특정 애플리케이션을 실행 시키기 위한 Entity와 작업에 필요한 resource, Entity들의 작업 수행규친에 대한 Role을 가지고 Role binding을 진행하고 Name spaces(쿠버네티스의 보안경계 그룹)에 따라 Access를 조절하는 것을 RBAC라고 한다

* EKS를 사용하려면 전용 IAM을 role를 통해서 EKS 권한부여가 오히려 안전하다
자세한 내용은 여기!

ArgoCD

출처: https://kangwoo.kr/tag/argocd

ArgoCD는 쿠버네티스를 위한 CD툴로 Manifest 파일의 변경사항을 감지하여 현재 배포된 노드의 환경과 Github Repo의 최신 버전이 싱크가 된 상태를 유지할 수 있도록 도와준다. 터미널 CLI 환경에서 상태를 체크하기 어려움이 있는데 Argo CD를 위한 서버를 오픈한 다음에 브라우저에서 GUI로 보다 편리하게 사용할 수 있다는 장점이 있다.

1. argocd를 위한 namespace를 생성하고 argocd를 쿠버네티스 클러스터에 배포한다

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.7/manifests/install.yaml

2. 배포가 제대로 되었는지 확인한다.

kubectl get all -n argocd

3. argocd CLI를 설치한다

sudo curl --silent --location -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v2.4.7/argocd-linux-amd64

sudo chmod +x /usr/local/bin/argocd

4. 서비스 타입을 로드벨런서로 설정한다 (로드밸런서 생성을 위해 삽분 기다려주는 것을 추천!)

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

5. nodeport 설정을 해준다

kubestl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'

6. Ingress 설정을 해준다 가이드 참조!

Ingress Configuration - Argo CD - Declarative GitOps CD for Kubernetes

Ingress Configuration Argo CD API server runs both a gRPC server (used by the CLI), as well as a HTTP/HTTPS server (used by the UI). Both protocols are exposed by the argocd-server service object on the following ports: 443 - gRPC/HTTPS 80 - HTTP (redirect

argo-cd.readthedocs.io

7. Port Fowarding 설정

kubestl port-forward svc/argocd-server -n argocd 8080:443

8. IP주소 및 포트확인!

kubestl describe svc argocd-server -n argocd

9. 아이디는 admin 비밀번호는 터미널 결과 참조!

export ARGO_PWD=`kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d`

helm(쿠버네티스 패키지 매니저)

helm은 쉽게 말하자면 쿠버네티스에게 nodeJS 의 npm, yarn과 비슷한 존재라고 생각하면 된다. YAML 형식으로 이루어져 있으며 이것을 chart라고 한다. chart에는 values.yaml과 templates 디렉토리가 있다. values.yaml에는 사용자가 원하는 설정 값들이 변수처럼 저장되어 있으며, 이를 터미널 상에서 환경변수처럼 사용이 가능하다. templates 디렉토리에는 설치할 리소스 파일이 존재한다.

helm을 잘 활용하면 오픈소스 애플리케이션도 손쉽게 내 소유의 쿠버네티스 클러스터로 가져올 수 있다. 도커가 단순히 프로세스 레벨에서 외부의 것을 가져다 쓸 수 있게 해준것이라면, 쿠버네티스에서는 helm을 이용하여 애플리케이션에서 필요한 모든 자원들을 외부에서 가져올 수 있게 한다.

이에대한 실습은 아래 링크에서 자세하게 할 수 있다.

https://www.eksworkshop.com/beginner/060_helm/helm_micro/create_chart/

이외 중요하게 기억하고 넘어갈 요소들은 AWS에서 발표자료를 이메일로 보내주면 추가보충하려고 한다!

DDR-forum // 파트 1. 소프트웨어와 디자인

Hot Dobby — Mon, 24 Oct 2022 18:48:41 +0900

Thanks to Khalil Stemmler

https://github.com/stemmlerjs/ddd-forum 해당 소스를 활용하려는 한국인 개발자분들을 위해서 공유합니다!

Coupling causing Complexity

dependencies, 종속성을 가지는 컴포넌트, 함수들이 단단히 결합하고 있는 구조에서는 분해하기가 모호해지기 때문에 복잡성이 증가할 수 밖에 없습니다. 클래스의 결합, 시간적 결합(동작에 있어서 순서가 중요한 비동기적 코드 실행), 동기적 결합 등이 소스에 진하게 남아있으면, 디자인을 하기도 어려울뿐만 아니라 유지보수와 확정성에 있어서도 패널티를 가지게 됩니다.

출처: https://wiki.solidbook.io

또한 이러한 결합을 하는 대상이 낮은 응집력을 가지고 있다면 그 문제는 더 커지게 됩니다. 부정확한 의미의 변수, 너무 추상화된 코드, 불필요한 정보 저장을 피하면서 서비스 소스의 응집력을 높게 유지하면서 각각의 dependency가 결합을 느슨하게 가져갈 수 있도록 구조를 디자인 해야합니다.

How to reduce the Complexity then??

- 전술적, 전략적 프로그래밍

Java사의 Sun Microsystems씨가 소프트웨어 평생 비용의 40~80%를 유지관리 및 보수에 사용하고 코드 설계자가 끝까지 책임지는 경우는 절대 없기 때문에 개발을 할 때 50%는 신규 개발, 50%는 유지보수를 위한 자원관리에 사용해야하는 것을 추천하고 있습니다. 복잡한 코드는 결국 인수인계자의 이해에 어려움을 주기 때문에 복잡하지 않으면서도 캡슐, 모듈화가 잘 되어있는 소스가 좋은 소스라고 볼 수 있습니다.

- Extreme Programming

익스트림 프로그래밍(XP)를 통하여 효율적으로 feature를 개발하여 시장에 빠르게 침투하는 것이 거친 생태계에서 살아남기 좋은 방법이 될 수 있습니다.

출처: https://wiki.solidbook.io

1. 피드백 : 페어 프로그래밍을 도입하여 개발자 서로가 피드백을 주면서 소스를 작성할 수 있는 환경 조성
2. TDD: Test-driven development을 통한 신규 피쳐 개발로 테스트 실패 케이스 분석을 통한 설계로 신규 기능을 추가
3. 지속적인 통합: CI라고도 하며 형상관리를 주기적으로 하면서 리펙토링, 소규모 릴리즈를 안정적으로 출시
4. Programmer welfare: 칭찬은 고래도 춤추게 만든다는 말처럼 좋은 개발자는 좋은 환경, 좋은 복지에서 성과가 호로록!

Typescript 환경에서 Jest 사용하기!

Hot Dobby — Thu, 20 Oct 2022 18:54:31 +0900

jest를 사용해보자!

Typescript + express 환경에서 jest를 사용하려고 하다보니 실수를 연발해서 여기에 정리합니다. ‍♂️

1. jest 설치하기

yarn add jest @types/jest

jest를 설치 해주셨다면 이제 test.js or spec.js로 테스트 코드를 작성 하실 수 있습니다! package.json에 가셔서 "jest" 명령어 스크립트를 추가해주신 다음에 터미널에서 실행시키면 해당 레파지토리가 가지고 있는 테스트 파일을 읽어서 한 번에 테스트를 진행해줍니다.

  "scripts": {
    "start": "node dist/app.js",
    "build": "tsc -p .",
    "dev": "nodemon --watch \"src/**/*.ts\" --exec \"ts-node\" src/app.ts",
    "test": "jest"  // 이렇게 jest 명령어를 추가해주세요!!
  },

//사용하실 때는 "yarn run test"

저는 지금 API테스트를 위해서 jest를 사용하기 때문에 user path에 signin api에 대해서 테스트를 진행 해보겠습니다.

2. Test 작성하기

/src/routes/path/user

user.controller 에 signin 로직을 처리하는 함수가 있고, user.query에 로그인을 위한 데이터쿼리가 있는 구조입니다. 여기서 signin에 대한 테스트를 진행하기 위해서 user.test.js와 useCase로 사용할 user.test.json 파일을 만들었습니다.

const testJSON = require("./user.test.json")
import { signin } from "./user.controller";

describe('signin', () => {
    test("user_id is string", () => {
        expect(typeof testJSON.singin_test_1.user_id).toBe('string');
    });
    
    test("password exists", () => {
        expect(!testJSON.singin_test_1.password).toBe(false)
    });
    
    test("sigin test", () => {
        const result = signin(testJSON.singin_test_2);
        expect(result.user_id).toBe(testJSON.singin_test_1.user_id)
        expect(!result.uid).toBe(false)
    });
});

//user.test.json 은 아래와 같습니다.
{
    "singin_test_1": {
        "user_id": "01012345678",
        "password": "abc123"
    },
    "singin_test_2": {
        "user_id": "01046237733",
        "password": "lolbook123"
    }
}

아주 간단한 테스트를 작성했는데, 만약 위 테스트 파일 대로 만든다면 문제가 하나 있을겁니다! 바로 user.controller.ts에서 signin 함수를 import 하는데 계속해서 에러가 발생할 것 입니다. 그렇기 때문에 jest.config와 babel.config를 작성해서 test.js 파일에서 모듈을 불러올 수 있도록 해야합니다. 킹 받게 만들려는건 아니고 처음 yarn package를 설치할 때 필요한 package를 다 설치하면 이러한 문제를 알 수 없기 때문에 지금 단계에서 알려드리는 겁니다.

yarn add babel-jest @babel/core @babel/plugin-transform-modules-commonjs @babel/plugin-transform-runtime @babel/preset-env @bable/preset-typescript

계속 업데이트 중이니 기다려주세요!!

TDD를 생각한다면 꼭 한 번 먼저 봤으면 하는 이야기 ft.이규원 TDD 강의

Hot Dobby — Thu, 20 Oct 2022 14:44:33 +0900

모듈화를 통한 정보숨김

인터페이스를 '무엇'을 표현하는 코드 단위라고 본다면 코드 자체들은 '협력'을 하고 있기 때문에 모든 인터페이스들은 알게 모르게 연결되어있다. 하지만 개발을 하기 위해서 모든 인터페이스를 이해할 필요는 없다! 어떤 일을 하는지만 중요하지, 어떻게 일 하는지는 중요하지 않다. 그래서 정보숨김을 통해서 불필요한 정보는 내부 인터페이스에서 처리되고 수정을 해도 영향을 받도록 만들어서 커뮤니케이션 자원을 아끼는 것이 중요!

간접입력 && 간접출력

주황: 간접입력 연두: 간접출력

간접입력의 경우 시스템에 요청이 들어오게 되면 바로 의존성이 있는 로직에 도달하여 프로세싱을 하고 출력을 하기 때문에 시스템 입장에선 입력, 의존성 로직 입장에선 출력이 된다. 간접출력의 경우 시스템에 요청이 들어오게 되면 시스템에서 의존성 로직에 입력을 하고, 의존성 로직에서는 시스템으로 다시 출력을 하게 된다.

Sociable 테스트 VS Solitary 테스트

sociable 테스트는 의존성이 있는 로직 , 테스트 할려고 하는 단위를 운영에서 사용하는 그대로 사용하는 것을 말하고 solitary는 따로 테스트 환경을 만들어서 테스트를 한다고 간단하게 말 할 수 있다. 그렇다면 solitary 테스트가 더 안전하고 효율적으로 보일 수 있으나 '가정의 안정도'에 따라 테스트 대역의 복잡도에 따라서 안정도가 낮아져서 원하는 테스트를 구현하지 못 할 가능성이 커진다!

출처: https://algopoolja.tistory.com/119

코드 적응력

모듈화가 잘 되어있고, 정리가 잘 되어서 협업자가 이해하고 읽기 쉬운 구조와 컨벤션을 가지고 있으면서 분리, 분해, 재설계, 활용이 쉬울수록 코드 적응력이 높다고 표현한다. 단위 테스트를 잘 진행하기 위해서는 하위 시스템을 잘 분리할 수 있어야 하며, 개방-폐쇄 원칙 (Open-Closed principle)의 원칙을 따라 모듈들은 확장에 대해서는 열려 있고, 수정에 있어서는 닫혀 있어야한다. 이는 typescript에서 extend의 개념처럼 상속을 받아 추가할 살을 덧 붙이고, 부모 객체에 대해서는 수정을 남용하는 것을 막는 것이 좋은 것과 같은 맥락이다.