cherry-pick <commit hash>

사용 경우: 현재 브랜치가 아닌 다른 브랜치에 있는 커밋 해시를 현재 워킹 트리에 Merge함 핵심은 해당 커밋해시를 Merge한다는 거임

머지하지 않고 staged 상태로만 불러오고 싶다면? -n 옵션을 주어서

cherry-pick -n <commit hash> 갱장히 유용하니 까먹지 말쟈

만약에 -n을 까먹고 체리픽을 해버렸다? -> git cherry-pick --abort 로 취소하자

혹은 git reset --soft HEAD~1 or --hard

방문자 패턴은 알고리즘들을 그들이 작동하는 객체들로부터 분리할 수 있도록 하는 행동 디자인 패턴입니다.

알고리즘들을 그들이 작동하는 객체들로부터 분리한다라..

문제

1. 기존 클래스 변경 안돼
2. XML 내보기내기 메서드가 해당 클래스에 있는게 맞아? <-SRP
3. 다른 형식으로 내보내기 기능이 추가될꺼 같은데? <- OCP

해결

새로운 메서드를 기존 클래스에 통합하는 대신에 visitor라는 별도의 클래스에 배치하자

class ExportVisitor implements Visitor is
    method doForCity(City c) { ... }
    method doForIndustry(Industry f) { ... }
    method doForSightSeeing(SightSeeing ss) { ... }
    // …

해당 메서드를 정확히 어떻게 호출할 수 있을까? 특히 전체 그래프(foreach)를 다룰 때, 이 메서드들은 시그니처들이 다르므로 다형성을 사용할 수 없습니다.

for Each {
    if (node instance of City) 
        exportVistor.doForCity((City) node)
    if (node instance of Industry)
        exportVisitor.doForIndustry((Industry) node)
}

이 방법은 번거로운 조건문 없이 객체에 적절한 메서드를 실행하는 것을 목표로합니다. 객체들은 자신의 클래스들을 알고 있으므로 비지터가 올바른 메서드를 선택할 수 있도록 할 수 있습니다.

foreach (Node node in graph)
    node.accept(exportVisitor)

// City
class City is
    method accept(Visitor v) is
        v.doForCity(this)
    // …

// Industry
class Industry is
    method accept(Visitor v) is
        v.doForIndustry(this)
    // …

노드(Element) 안바꾼다면서 바꿨.... accept 추가했네..

다이어그램

의사코드

// interface - element
interface Shape is 
    method move(x,y)
    method draw()
    method accept(v: Vistor)

// implement - concrete element
class Dot implements Shape is
    method accept(v: Visitor) is
        v.visitDot(this)

class Circle implements Shape is
    // …
    method accept(v: Visitor) is
        v.visitCircle(this)

class Rectangle implements Shape is
    // …
    method accept(v: Visitor) is
        v.visitRectangle(this)

class CompoundShape implements Shape is
    // …
    method accept(v: Visitor) is
        v.visitCompoundShape(this)

// interface - visitor
interface Visitor is 
    method visitDot(d: Dot)
    method visitCircle(c: Circle)
    method visitRectangle(r: Rectangle)
    method visitCompoundShape(cs: CompoundShape)

// implements - concrete visitor 
class XMLExportVisitor implements Visitor is
    method visitDot(d: Dot) is
        // 점의 아이디와 중심 좌표를 내보냅니다.

    method visitCircle(c: Circle) is
        // 원의 아이디, 중심 좌표 및 반지름을 내보냅니다.

    method visitRectangle(r: Rectangle) is
        // 사각형의 아이디, 왼쪽 상단 좌표, 너비 및 높이를 내보냅니다.

    method visitCompoundShape(cs: CompoundShape) is
        // 모양의 아이디와 그 자식들의 아이디 리스트를 내보냅니다.

// 클라이언트 코드 
class Application is
    field allShapes: array of Shapes[]

    method export() is
        exportVisitor = new XMLExportVisitor()

        foreach (shape in allShapes) do
            shape.accept(exportVisitor)

더블 디스패치

accept 이 필요한 이유 더블 디스패치 아래서 한번 더 보자

foreach (shape in allShapes) do
    shape.accept(exportVisitor)

allShapes에 Dot, Circle 등이 섞여 있지만 루프에서는 전부 Shape 타입으로 잡힘 컴파일러는 구체적으로 뭔지 모름

1단계 디스패치 : Shape 타입 결정하기

shape.accept(exportVisitor)를 호출하면 런타임에 shape의 실제 타입에 따라 해당 클래스의 accept가 호출, 예를 들어 실제로 Dot 객체라면

class Dot implements Shape is
    method accept(v: Visitor) is
        v.visitDot(this)  

이 시점에서 Dot이 확정 이게 첫 번째 디스패치

2단계 디스패치 :Visitor 타입 결정

accept 안에서v.visitDot(this)를 호출하면, v의 실제 타입에 따라 어떤 visitDot이 실행될지 결정 v가 XMLExportVisitor라면

class XMLExportVisitor implements Visitor is
    method visitDot(d: Dot) is
        // 점의 아이디와 중심 좌표를 내보냅니다.  

한번의 호출로는 shape, visitor 두 축을 동시에 결정할 수 없어서 두번의 호출로 각각 다형성을 적용 그래서 더블 디스패치..

그러니깐 accept 쪽에서 자기 자신을 this로 넘겨줘야 visitor에서 해당 구현된 shape의 데이터에 접근된다는건데 ..

적용은

Class는 해당 클래스만이 가지고 있는 기능 또는 목적이 있을 것임

쉽게 말하면 모든 기능을 하나의 클래스에 다 때려박지 말라는 말

그럼 그 기준은 어떻게 정하냐고 물을 수 있다. << 이건 개발자 영역

기준이 모호하기 때문에 변경을 책임의 기준으로 삼으면 설계에 용이할 수 있다.

객체를 쪼갤 때 기능으로 쪼개든 목적으로 쪼개든 다 좋은데 그 근본 목표가 유지보수를 향해있어야한다. 즉 유지보수성을 극대화해라! S/W의 특징(유연함)

결국 처음에 언급한 대로 기준은 변경 가능성이며 그 판단은 개발자의 몫 SRP는 "무조건 기능 하나당 클래스 하나"가 아니라 "변경 이유가 섞이지 않게 해라"는 원칙

증상

• NestJS 서버에서 에러 발생 시 Telegram Bot API로 알림을 보내는 기능

• 간헐적으로 알림이 오지 않는 현상 발생

• 서버 로그에는 에러가 정상적으로 찍히지만, Telegram 메시지는 도착하지 않음

  디버깅 과정

  1단계: 코드 문제 확인

  TelegramTransport에서 axios 에러를 .catch(() => {})로 무시하고 있어서, 실패해도 아무 로그가 남지 않았음.
  catch에 로그를 추가하여 원인 파악 시작.

  // 기존 — 에러를 삼킴
  axios.post(url, data).catch(() => {});

  // 디버깅용 — 에러 내용 출력
  axios.post(url, data).catch((err) => {
  console.error('[TelegramTransport]', err.code, err.message);
  });

  결과: ETIMEDOUT 확인

  2단계: 네트워크 문제 확인

  Docker 컨테이너 내부에서 테스트

  wget → 성공

  docker exec server wget -q -O- https://api.telegram.org

  Node.js https 모듈 → ETIMEDOUT

  docker exec server node -e "require('https').get('https://api.telegram.org', ...)"

  Google은 정상

  docker exec server node -e "require('https').get('https://google.com', ...)"

  → status: 301 (성공)

  wget은 되고 Node.js는 안 되는 상황.

  3단계: DNS 조회

  docker exec server node -e "
  require('dns').resolve4('api.telegram.org', (e, a) => console.log('IPv4:', a));
  require('dns').resolve6('api.telegram.org', (e, a) => console.log('IPv6:', a));
  "

  IPv4: [ '149.154.166.110' ]
  IPv6: [ '2001:67c:4e8:f004::9' ]

  api.telegram.org는 IPv4, IPv6 둘 다 지원.

  4단계: IPv4 직접 연결 테스트

  IPv4 IP로 직접 연결 → 성공. IPv6 경로가 문제라는 것을 확인.

  원인

• api.telegram.org는 IPv4/IPv6 듀얼 스택

• Node.js는 기본적으로 IPv6를 우선 사용 (happy eyeballs 알고리즘)

• Docker 기본 네트워크(bridge)는 IPv6 외부 라우팅을 지원하지 않는 경우가 많음

• IPv6로 연결 시도 → 라우팅 불가 → ETIMEDOUT

• wget은 IPv4를 우선 사용하기 때문에 성공

• 간헐적으로 알림이 온 이유: Node.js가 IPv4로 먼저 연결되는 경우도 있었기 때문

  해결

  axios 인스턴스에 family: 4 옵션을 추가하여 IPv4 연결을 강제.

  // 변경 전
  axios.post(this.apiUrl, { chat_id: this.chatId, text }).catch(() => {});

  // 변경 후 this.httpClient = axios.create({
  timeout: 10000,
  family: 4, // IPv4 강제
  });
  this.httpClient.post(this.apiUrl, { chat_id: this.chatId, text }).catch(() => {});

  핵심 정리

  ┌──────┬───────────────────────────────────────────────┐
  │ 항목 │ 내용 │
  ├──────┼───────────────────────────────────────────────┤
  │ 환경 │ Docker (bridge network) + Node.js │ ├──────┼───────────────────────────────────────────────┤
  │ 증상 │ 외부 API 호출 간헐적 ETIMEDOUT │
  ├──────┼───────────────────────────────────────────────┤
  │ 원인 │ Node.js IPv6 우선 + Docker IPv6 라우팅 미지원 │
  ├──────┼───────────────────────────────────────────────┤
  │ 해결 │ family: 4로 IPv4 강제 │
  ├──────┼───────────────────────────────────────────────┤
  │ 교훈 │ .catch(() => {})로 에러를 삼키지 말 것 │
  └──────┴───────────────────────────────────────────────┘

객체의 내부 상태가 변경될 때 해당 객체가 ctx의 행동을 변경할 수 있도록 하는 패턴 객체가 행동을 변경할 때 객체가 클래스를 변경한 것처럼 보일 수 있다.

1. 행동을 변경??
2. 클래스를 변경한 것처럼?? -> 실제로는 변경이 일어나지 않았다는건가?

   궁금증은 아래서

상태 패턴은 객체의 내부상태 변화에 따라 객체의 동작을 변경할 수 있는 패턴 이 패턴은 유한 상태 기계의 개념과 유사 상태 패턴은 패턴 인터페이스에 정의된 메서드 호출을 통해 전략을 전환할 수 있는 전략 패턴으로 해석 가능

FSM 유한 상태 기계?

정해진 상태들 사이를 규칙에 따라 이동하는 기계(하드웨어) 신호등(초록, 노랑, 빨강), 자판기(돈 -> 음료선택(유한)), 개찰구(open-close) 등 ->

상태 패턴은 FSM이라는 이론적 개념을 소프트웨어에서 OOP로 구현한 패턴

주요 개념

1. 모든 주어진 순간에 프로그램이 속해 있을 수 있는 상태들의 수는 유한하다는 것.
2. 현재 상태에 따라 프로그램은 특정 상태로 전환 or 전환되지 않을 수 있음

-> 이러한 전환 규칙들을 천이(transition)이라고 하며 이 규칙들 또한 유한하며 결정적

문제점 feat.절차지향

class Document is
    field state: string
    // …
    method publish() is
        switch (state)
            "draft":
                state = "moderation"
                break
            "moderation":
                if (currentUser.role == "admin")
                    state = "published"
                break
            "published":
                // Do nothing.
                break
    // …

아아.. 이런 코드는 OOP에서 OCP원칙을 위반한다고~ 쓰지말라고! 아래서 한번 절차지향적/객체지향적 장단점에 대해 얘기해봄

조건문들에 기반한 상태 머신의 가장 큰 약점은 상태들과 상태에 의존하는 행동들을 추가할수록 분명해지겠죠?

• 코드베이스 이빠이 커짐..(설계 단계에서 모든 상태 + 천이를 예측하기란 어려워)
• 유지 보수 빡셈

해결(HOW)

1. 상태 패턴은 모든 가능한 상태들에 대해 새로운 클래스를 만든다.
2. 모든 상태별 행동들을 클래스들로 추출한다.

조금 더 구체적으로는? 3. context(ctx)라는 원래 객체는 모든 행동을 구현하는 대신 "현재 상태"를 나타내는 상태 객체 중 하나에 대한 참조를 저장 + 모든 상태와 관련된 작업을 해당 클래스에 위임

ㅇㅎ 상태를 만들겠군 State합성 합성 영어로는 ? 콤포지숀(Composition)~ 그리고 State는 합성이니깐 고수준 모듈(interface)이겠고 이거슬 구현한 ConcreteState가 있겠군!

구체적인 해결 With 코드

SUDO

Context = 리모컨 
State<<interface>> = 현재 TV 상태 인터페이스
ConcreteState = 실제 상태들 

TS

일단은 간단하게 켜기/끄기만 구현

interface TVState {
 pressButton(tv: TV): void;
}

// TV off 상태 
class TVOffState implements TVState {
    pressButton(tv: TV): void {
        console.log('티비가 켜짐!');
          tv.setState(new TVOnState());
    }
}

class TVOnState implements TVState {
    pressButton(tv: TV): void {
        console.log('티비가 꺼짐!');
          tv.setState(new TVOffState());
    }
}

class TV {
    private state: TVState = new TVOffState();

      setState(state: TVState) {
        this.state = state; 
    }

      public pressPower() {
        this.state.pressButton(this);
          // this를 호출한 객체.
    }
}

// -------CLIENT-------
const tv = new TV();

tv.pressPower(); // off -> on 
tv.pressPower(); // on -> off

여기서 음량 조절 채널 버튼을 추가하면 어떻게 될까? *상태패턴은 유한한 상태지만 많은 상태가 있어야 유의미한거잖아요! *

interface TVState {
 pressButton(tv: TV): void;
 // 음량, 채널 
 pressChannel(direction: 'up'| 'down'): void
 pressVolume(direction: 'up'|'down'): void
 // 그외 음소거 버튼 등등등 .. 
}

전략패턴 vs 상태패턴

전략 패턴과 비슷해 보이지만 한 가지 중요한 차이점이 있습니다. 상태 패턴에서의 특정 상태들은 서로를 인식하고, 한 상태에서 다른 상태로 천이(on -> off)를 시작할 수 있지만 전략패턴들은 대부분 서로에 대해 알지 못한다는 것입니다.

전략 패턴은 사용자가 필요에따라 런타임에 바꿔!! 바꿔!! 바꿔!! 가능 (사용자가 갑) 상태 패턴은 사용자가 X "응~ 니가 누르는거에 따라서 알아서 바뀔거야~" (상황이 갑)

솔직히 잘 모르겠음..

궁금증 해결하기

1. 행동을 변경??

const tv = new TV();  // TV 객체는 하나

tv.pressPower();  // "티비가 켜짐!" → ON 상태의 행동
tv.pressPower();  // "티비가 꺼짐!" → OFF 상태의 행동

2. 클래스를 변경한 것처럼?? -> 실제로는 변경이 일어나지 않았다는건가?

상태 패턴을 사용하면 다음과 같은상태를 가진 클래스로 바꾼것처럼 행동한다는 뜻 실제로는 변경없음, 상태만 변경됨

tv.state = new TVOnState()   
tv.state = new TVOffState()  

절차지향 vs 객체지향

근데 꼭 절차지향이 나쁜건 아니거덩요. 언어라는 도구를 잘 활용하면 좋거덩요 꼭 oop에 갇혀 있을 필욘 없거덩요 상황에 맞춰서 쓰면 되거덩요 그러하거덩요

절차지향 C

#include <stdio.h>

// 상태 ENUM
typedef enum {
    TV_OFF,
    TV_ON
} TVState;

// 데이터 구조체 (행동 없음, 데이터만)
typedef struct {
    TVState state;
} TV;

// 함수가 구조체 밖에 존재
void press_power(TV* tv) {
    switch (tv->state) {
        case TV_OFF:
            printf("티비가 켜짐!\n");
            tv->state = TV_ON;
            break;
        case TV_ON:
            printf("티비가 꺼짐!\n");
            tv->state = TV_OFF;
            break;
    }
}

int main() {
    TV tv = { TV_OFF };  // 초기화
    press_power(&tv);    // 포인터로 넘김
    press_power(&tv);
    return 0;
}

또한 상태가 많지 않다면 가독성 + 유지보수성은 절차지향이 편리함 (등가교환)

"뭐가 더 자주 바뀌냐" 에 따라 선택이 달라짐

기능(함수)이 자주 추가 -> 절차지향 타입(클래스)이 자주 추가 -> OOP

절차지향은 자료구조는 바꾸기 어렵지만 함수 추가는 EZPZ OOP는 자료구조는 바꾸기 쉽지만 함수 추가는 HARD

흐름

클라이언트가 WebSocket 연결 시도
↓
allowRequest(req, cb) 실행
↓
req.headers.origin 확인 (요청을 보낸 출처)
↓
├─ origin이 없음 → cb(null, true) → 연결 허용 │ (Postman, curl, 서버 간 통신 등 브라우저가 아닌 경우)
│
├─ origin이 corsOrigin 목록에 있음 → cb(null, true) → 연결 허용
│ (예: 'http://localhost:3010'이 목록에 포함)
│
└─ origin이 목록에 없음 → cb('CORS_NOT_ALLOWED', false) → 연결 거부
(예: 'http://evil.com'에서 접근 시도)

cb(err, success)의 의미

• cb(null, true) — 에러 없음, 연결 승인

• cb('CORS_NOT_ALLOWED', false) — 에러 메시지와 함께 연결 거부

  왜 필요한가

  cors 옵션만으로는 HTTP의 preflight(OPTIONS) 요청에만 적용됩니다. WebSocket upgrade 요청은 preflight가 없어서 브라우저가 CORS를 강제하지
  않습니다. 그래서 allowRequest로 서버 측에서 직접 Origin을 검사해야 합니다.

발단

class UserDto {
  address: string; 
  signature: string;
}

@Post('login/verify')
async login(@Body() dto: UserDto, @Res() res:Response ): any {
      const result: { accessToken: string; refreshToken: string } = await this.authService.login(
      dto.address,
      dto.signature,
    );
}

• 사용 스택: nestjs

일단 사건의 발단은 저 코드에서 UserDto가 실제로 컴파일타임, 런타임에 무슨 역할을 하는지 궁금했음

내가 알고 있는 TS에대한 지식으로는 저렇게 클래스를 선언하면 변수를 할당하지 않는 이상 해당 클래스는 아무런 프로퍼티가 없는 상태다 class MetaMaskVerifyDto {} <- 컴파일 시점에는 빈 객체 이게 과연 런타임에 무슨 의미가 있을까, 그리고 어떻게 dto.[property]에 접근할 수 있었을까?

조금 더 질문을 좁혀보자면 다음과 같다.

1. interface/type과 비교해 class로 작성하는 이유?

2. 컴파일시점과 런타임에는 어떻게 동작하는가?

3. dto를 js/ts에는 어떻게 다뤄야하는가?

1

일단 ts 공식문서에서는 찾지 못했지만 내가 사용하는 프레임워크인 nestjs공식문서에서 다음과같은 글을 찾았따. https://docs.nestjs.com/controllers Before we proceed (if you're using TypeScript), we need to define the DTO (Data Transfer Object) schema. A DTO is an object that specifies how data should be sent over the network. We could define the DTO schema using TypeScript interfaces or simple classes. However, we recommend using classes here. Why? Classes are part of the JavaScript ES6 standard, so they remain intact as real entities in the compiled JavaScript. In contrast, TypeScript interfaces are removed during transpilation, meaning Nest can't reference them at runtime. This is important because features like Pipes rely on having access to the metatype of variables at runtime, which is only possible with classes.

Let's create the CreateCatDto class:

create-cat.dto.tsJS

export class CreateCatDto {
  name: string;
  age: number;
  breed: string;
}

DTO를정의할 때 interface/type을 상용하게 되면 트랜스파일링할때 지워져서 해당 entity에 접근할 수 없다. 그렇기 때문에 class로 작성하는 것을 권장한다.

그리고후에 pipe를 활용할 만들어 놓은 dto 객체가 사용된다고 명시되어 있다.(like Pipes rely on having access to the metatype of variables at runtime, which is only possible with classes)

즉, interface/type을 사용해도 상관은 없지만 nest에서는 다른 feature들을 사용하기 위해서는 class로 dto를 정의한다고 보면된다.

2

1번에서 많은 의문점이 해소되었지만 컴파일시점 js로 변환됐을 때는 해당 class의 껍데기만 남게된다.

class UserDto {}

그리고 런타임 시점에서는 아무런 역할도 하지 않는다. 그저 객체가 body로 들어오면 아. 들어왔구나 통과~ 다음 로직에서 처리하게 된다.

즉

this.authService.login(
      dto.address,
      dto.signature,
    );

이렇게 dto.address -> json에 address property가 없다? 그냥 undifined로 할당 -> 다음 로직 실행

3

DATA TRANSFER OBJECTS

데이터를 전달하는 객체...

아마 zod를 몇번 더 써보면 정확하게 답이 나올거같아서 현재는 더 길게는 안적을꺼같음

처음에 작성할 때 의문은 1,2,3 이렇게 3개였는데 1번에서 꽤 많은 의문점이 해소되었다.

http는 데이터를 달라고 요청만 함 그 중간에 데이터가 유실되거나 순서가 섞였는지는 확인하지 않음 이러한 복잡하고 중요한 일은 tcp가 해결함

• 데이터 분할 : 큰 데이터를 작은 단위의 페킷 형태로 전송
• 순서 보장 : 페킷들을 도착지에서 순서가 바뀌어도 다시 올바른 순서로 조립
• 재전송 : 가는 길에 데이터가 유실되면 다시 보내줘라고 요청해서 누락 없이 전달.

그럼 과연 재전송하면 새로 오나? 아니면 빠진 부분만 가져오나?

TCP의 동작 방식 3-way-handshake TCP는 데이터를 보내기전에 상대방과 연결이 가능한 상태인지 먼저 확인하는 절차를 거침 이를 3-way-handshake라고 함

1. 클라이언트 : 나 데이터 보내도 돼?
2. 서버 : 나도 보내도 돼?
3. 클라이언트 : 응 그럼 보낼께~

• 기술스택에만 집중했던것을 후회함 오히려 그 스택중 기본이 되는 것을 더욱 파고 드는게 중요

• 왜? 라는 의문점을 항시 가져야 함 그냥 좋아서 썼어요 <- 실제로 이런 경우는 잘 없겠지만 그 부분이 왜 좋았는지 기존의 문제는 무엇이였는지, 다른 것들과 비교해볼 때 어떤게 좋았는지, 새로운 문제를 발생시키지 않을지 등 다양한 요소들에 대해서도 생각해보는게 좋음

• 기초 결국 FE 개발자는 브라우저 , 네트워크, 이런것에 기초가 단단하고 사용하는 Js 코어, React 코어 그리고 그 배경까지 빠삭하게 이해하는게 중요함

• 개발자라면 논리적인 추론 흐름을 꼭 연습하는게 중요함

• 전체 프로젝트를 진행하는 것도 중요하지만, 모듈식으로 부분 부분 내가 필요한 부분을 만들어서 공부하는 것도 중요한 방식임

일단은 여기까지 작성하고 후에 이런 부분들을 고려해서 글을 작성할 때 참고해야겠음

1. Docker Hub 가입 및 설정 + Docker Hub 필요 이유
2. git actions 작성
3. git runners(셀프 호스팅) 설정
4. nginx + Let's Encrypt (SSL 인증서)

Docker Hub

완전 자동화 CI/CD 구축을 위해서는 Docker Hub의 repository를 이용하면 개굿임 진짜 편함!

사진처럼 도커 이미지 생성하는 법을 알아보자

1. ID + 비밀번호 or Access Token 필요 Access Token의 권한은 Read & Write 정도는 필수

Docker Hub 무료 플랜 (참고용 그닥 쓸모 X)

여담인데 배포해보니깐 그냥 대머리 될거같음 공짜 공짜 공짜.. ㄹㅇ 공짜만 찾아 댕기는 듯 ㅠ....

다시 본론 ...

무튼 Docker ID, PW or Access Token 이 필요한 이유는

이따가 GitHub Actions를 이용한 CI/CD를 구축하기 위해 보안 정보가 필요 함 ( 아래 사진 참고 )

Docker Hub 회원가입 했지?

만약 보안을 위해 Private으로 유지하고 싶다면 EC2 터미널에 접속해서 아래 명령어를 딱 한 번만 실행 ㄱㄱ

# EC2 터미널에서 입력
docker login -u [도커_허브_아이디]
# Password 입력창이 뜨면 '비밀번호'가 아닌 발급받은 'Access Token'을 입력하세요.

이렇게 한 번 로그인해두면 그 이후부터는 GitHub Actions가 도커 이미지를 올리고 EC2가 내려받는 과정이 막힘없이 진행됨

git action

"배포 스크립트","CI/CD 파이프라인", "깃헙 Actions 설정" 이 중에 뭐라고 부르는지는 잘 모르겠지만 일단 이 코드는 잘 자기 프로젝트에 맞게 작성할 것

# .github/workflows/deploy.yml

name: My server CI/CD

on:
  push:
    branches: [ main ] # 메인 브랜치에 푸시될 때 실행 

현재 branches: [main]으로 되어 있는데 이건 CI/CD를 구축하기에 안전한건 아님 왜냐하면 git Ubuntu가 내 SSH에 들어가서 직접적으로 수정하는거라서 SSH 22번 포트를 내 ip 외에도 열어줘야함

난 일단 초짜라 요금 폭탄 맞기 싫어서 누구한테도 안열어 줄겅미

Git Self-Hosted Runner

5분은 무슨 한 30분 걸린듯. ㅠ

이대로 실행하면 되긴하는데 약간의 디테일이 있음 Download부분은 저 대로 EC2 터미널에 하나씩 입력하면되고

Configure에 ./config.sh --url https://~~~입력한 뒤에 ./run.sh 대신에 아래 명령어 하면 좋음

# 서비스를 설치합니다. (관리자 권한 필요)
sudo ./svc.sh install

# 서비스를 시작합니다.
sudo ./svc.sh start

# 서비스 상태를 확인합니다.
sudo ./svc.sh status

이렇게하면 다음과 같다고 함

Dependency 에러 생길경우

# Amazon Linux 2023 기준 수동 설치
sudo dnf install libicu -y

nginx + Let's Encrypt

docker-compose.prod.yml에 nginx에 대한 필요한 코드 작성해주고~ nginx.conf도 작성해주고~

내 폴더 구조는 이래용 (NestJS)

나는 nginx + certbot 폴더 생성해줬음

server
├── src
├── nginx/
│   └── default.conf
└── certbot/
    ├── conf/
    │   └── .gitkeep  
    └── www/
        └── .gitkeep  

폴더구조는 자기 환경에 맞게끔 잘 조절해주면 GOOD!

# 1. 먼저 전체 서비스를 실행합니다. (이때 Nginx는 인증서가 없어 에러가 날 수 있지만 일단 띄웁니다)
docker compose -f docker-compose.prod.yml up -d

# 2. Certbot을 이용해 인증서를 발급받습니다.
docker compose -f docker-compose.prod.yml run --rm certbot certonly --webroot --webroot-path /var/www/certbot -d <url>

발급 성공하믄 근데 아마 여기서 발급받을 때 소스코드 부분 몇번 변경을 할거임

• 포트 열어주고 -> 다시 닫아주고 이 과정 한번 거쳐야함

SSL 인증서까지 받았따면!? docker compose restart nginx ㄱㄱ 리스타트

참고로 인증서는 다음과 같음

여기까지 했다면 배포 굿 잘 된것임!!

AWS EC2의 '퍼블릭 IPv4 주소'는 인스턴스를 중지(Stop)했다가 다시 시작(Start)할 때마다 변경될 가능성이 있음

• 문제점: IP가 바뀌면 Route 53에 등록한 설정값도 매번 수동으로 수정해야 함 + 그동안 서비스 접속이 끊김

• 해결책: AWS 콘솔의 '탄력적 IP' 메뉴에서 고정 IP를 할당받아 인스턴스에 연결한 후, 그 고정된 IP 주소를 Route 53 값에 입력 권장

Elastic IP는 결국 돈나감 ㅠ

편의상 Route 53으로 설명했는데 필자는 Route 53 대신 가비아(국내) DNS 관리 툴에서 설정 했음

• Route53은 무료 플랜에서 사용 불가 항목

호스트(api) : api.your-domain.com <- 에서 앞 api. 부분 설정임

암튼 핵심은 도메인 연결은 기본 퍼블릭 IP는 바뀔 수 있으니 고정 IPdㅣㄴ Elastic IP(탄력적 IP)를 받아서 설정 해놓으면 수고스러움을 덜 수 있다.

도메인 연결은 검색하면 자료가 많아서 굳이 더 다루지 않겠음.

1. EC2 인스턴스 생성

• amzaon linux - 2023 사용
• t3.micro

무료 플랜은 이거 사용하면 됨 우분투는 시간당 0.016이라 패스 (극강의 효율 가즈아)

• 키를 생성하면 <key pair>.pem이런걸 다운로드 하는데 AWS 키페어는 EC2 인스턴스에 처음 접속하기 위한 마스터 키

• 나중에 git action에 ssh 연결할 떄 쓰임

2. 접속

# .pem 파일 드래그 앤 드랍해서 .pem 파일 위치 넣기
chmod 400 <keypair-경로.pem>

# 퍼블릭 DNS을(를) 사용하여 인스턴스에 연결
ssh -i <keypair-경로.pem> ec2-user@내-퍼블릭-IP주소>

*chmod 400 * chmod 400은 파일 소유자에게만 읽기(read) 권한을 부여하고, 그룹 및 다른 사용자에게는 어떠한 권한도 주지 않는(권한 없음) 설정

ec2-linux-shell

일단 여기까지 왔으면 아래 사진처럼 접속이 됨

docker, docker-compose, git이 필요함 설정하는건 다음과 같음

sudo dnf update -y # 보안 패치 및 버그 수정의 이유로 패키지 업데이트 
sudo dnf install -y docker # Docker 엔진을 설치
sudo systemctl start docker # Docker 서비스 시작 
sudo systemctl enable docker # EC2 재부팅해도 Docker가 자동으로 시작되게 설정
sudo usermod -aG docker ec2-user # ec2-user를 docker 그룹에 추가
sudo dnf install -y docker-compose-plugin #  Docker Compose 플러그인 설치
docker compose version # docker-compose 버전 확인
sudo dnf install -y git # 깃 설치
git --version # 깃 버전 확인 

sudo usermod -aG docker ec2-user 역할: ec2-user를 docker 그룹에 추가 왜 필요? Docker 명령어는 기본적으로 root 권한 필요 효과: sudo 없이도 docker 명령어 사용 가능

# 이 명령 전
sudo docker ps  # sudo 필요
>
# 이 명령 후 (재로그인 필요)
docker ps 

⚠️ 주의: 적용하려면 로그아웃(exit) 후 재로그인 필요w 재로그인: ssh -i <keypair.pem> ec-user@퍼블릭 ip주소

# git 설정 (레포지토리가 private 일때만)
```shell
# ec2 터미널에서 
ssh-keygen -t ed25519 -C "내이메일@example.com"

엔터 3번 -> cat ~/.ssh/id_ed25519.pub(공개 키 확인 및 복사)

# 공개키는 다음과같이 생김 
`ssh-ed25519 AAAA... 내이메일@example.com`

GitHub 저장소에 키 등록

1. 본인의 GitHub Private 저장소 페이지로 이동

2. Settings 탭 클릭 → 왼쪽 메뉴에서 Deploy keys

3. Add deploy key 버튼을 클릭

4. Title: EC2-Server (본인이 알아보기 쉬운 이름)

5. Key: 방금 복사한 문자열을 붙여넣기

6. Add key를 눌러 저장 (Write 권한은 필요 없으므로 체크하지 않아도 됨)

이렇게 설정하면 SSH로 이제 git clone 가능

git clone (레포 복사)

1. SSH 연결 테스트 (가장 먼저 확인!)

ssh -T git@github.com

• Hi 계정명/저장소명! You've successfully authenticated... 라고 나오면 성공

ec2의 루트 경로 [ec-user@...]에서

• 현재 위치한 경로 알고 싶으면 : pwd

# SSH 주소!!!
git clone git clone git@github.com:계정명/저장소명.git

.env 설정

# 1. env 파일 만듦 
vi .env

# 2. `i` 를 눌러 -- INSERT -- 모드로 바꾼 뒤
.env파일 복붙 

# 파일 저장 & 나가기
Esc #키를 누름 (입력 모드 해제).
:wq # 입력 (Write and Quit).
Enter # 터미널로 돌아옵니다.

compose build requires buildx 0.17 or later

이런 경고가 뜨면 버전 업글해주면됨

mkdir -p ~/.docker/cli-plugins

curl -L https://github.com/docker/buildx/releases/download/v0.19.1/buildx-v0.19.1.linux-amd64 -o ~/.docker/cli-plugins/docker-buildx

chmod +x ~/.docker/cli-plugins/docker-buildx

docker buildx version

RDS 연결까지

# nc(netcat) 명령어로 해당 IP와 포트 통신 확인
sudo dnf install -y nc # 설치
nc -zv <프라이빗IP> <dbport> # 확인

데이터베이스(RDS)는 일종의 '성'이고, 보안 그룹은 그 성문을 지키는 '수문장'입니다. 현재 EC2가 성 안으로 들어오려고 하지만, RDS의 수문장(default)이 막고 있는 상태입니다. 따라서 default 보안 그룹의 인바운드 규칙을 수정하여 EC2(launch-wizard-3)를 통과시켜줘야 합니다.

나는 다음과같음 default가 rds 설정할 떄 썼던거고 launch-wizard-3가 내 ec2 인스턴스에 추가한거

보안 그룹 규칙 추가 순서

1. default

2. 인바운드 규칙 편집: 하단 탭에서 인바운드 규칙(Inbound rules)을 선택하고, 오른쪽의 인바운드 규칙 편집(Edit inbound rules) 버튼을 누릅니다.

3. 규칙 추가: 아래와 같이 새로운 규칙을 입력합니다.

• 유형: PostgreSQL (선택하면 자동으로 포트 범위가 5432로 설정됩니다.)

• 프로토콜: TCP (자동 설정)

• 포트 범위: 5432 (자동 설정)

4. 소스(Source): '사용자 지정'을 선택한 뒤, 옆의 입력창에 launch-wizard-3의 보안 그룹 ID를 입력합니다. (입력창을 클릭하면 목록에 sg-... (launch-wizard-3)가 나타날 텐데, 그걸 선택하는 것이 가장 정확하고 안전합니다.)

5. 저장: 하단의 규칙 저장(Save rules) 버튼을 누릅니다.

자 이제 다시 네트워크 확인해보자

nc -zv <프라이빗IP> <dbport> # 확인
# >connected 뜨면 정상

AWS EC2 보안 그룹 확인

아까 확인하신 launch-wizard-3 보안 그룹은 현재 EC2 인스턴스의 '성벽' 역할을 합니다. 여기에 3000번 포트를 열어주는 규칙이 있는지 확인해야 합니다.

1. AWS 콘솔 → EC2 인스턴스 목록에서 현재 실행 중인 인스턴스를 클릭합니다.

2. 하단의 보안(Security) 탭을 누르고, 보안 그룹(Security groups) 아래에 있는 launch-wizard-3 링크를 클릭합니다.

3. 인바운드 규칙(Inbound rules) 탭에서 인바운드 규칙 편집(Edit inbound rules)을 누릅니다.

4. 아래 규칙을 추가하고 저장하세요.

• 유형: 사용자 지정 TCP
• 포트 범위: 3000
• 소스: Anywhere-IPv4 (또는 주소창에 0.0.0.0/0 입력)

5. 저장

1.퍼블릭 액세스 설정 변경하기

RDS 콘솔로 가서 해당 → 데이터베이스를 클릭합니다.

상단의 → [수정(Modify)] 버튼을 누릅니다.

화면을 아래로 쭉 내려서 [연결(Connectivity)] 섹션을 찾습니다.

[추가 구성(Additional configuration)]을 클릭하여 메뉴를 펼칩니다.

퍼블릭 액세스(Public access) 항목을 [예(Yes)]로 변경합니다.

맨 아래로 내려가 [계속(Continue)]을 누릅니다.

수정 예약에서 반드시 [즉시 적용(Apply immediately)]을 선택하고 [DB 인스턴스 수정]을 누르세요.

주의: '다음 예약된 유지 관리 기간에 적용'을 선택하면 당장 바뀌지 않습니다.

2.보안 그룹(Security Group)에서 내 IP 허용하기

퍼블릭 액세스를 켰더라도, 보안을 위해 "특정 IP(사용자님의 컴퓨터)만 접속을 허용하겠다"는 설정을 반드시 해줘야 합니다.

RDS 콘솔의 DB 인스턴스 상세 페이지에서 [연결 및 보안] 탭을 클릭합니다.

오른쪽의 [VPC 보안 그룹] 아래에 있는 파란색 링크(예: sg-0abc...)를 클릭합니다.

화면 하단의 [인바운드 규칙] 탭을 선택하고 [인바운드 규칙 편집] 버튼을 누릅니다.

[규칙 추가]를 누르고 다음과 같이 설정합니다.

유형: PostgreSQL (자동으로 포트 5432가 입력됩니다.)

소스: '내 IP'를 선택합니다. (현재 사용자님의 인터넷 IP 주소가 자동으로 들어갑니다.)

설명(선택 사항): My PC Access라고 적어두면 나중에 알아보기 편합니다.

[규칙 저장]을 누릅니다

3. 접속 주소(엔드포인트) 복사하기

실제 DB 주소를 알아야 도구에서 접속할 수 있습니다.

다시 RDS 상세 페이지의 [연결 및 보안] 탭으로 가서 엔드포인트(Endpoint) 주소를 복사해 두세요.

예: database-1.xxxx.ap-northeast-2.rds.amazonaws.com

3단계: DB 관리 도구(DBeaver)로 접속 테스트 이제 사용자님의 컴퓨터에 설치된 DB 클라이언트 도구(DBeaver 등)를 켭니다.

새 연결(New Connection)을 만들고 PostgreSQL을 선택합니다.

Host: 복사한 '엔드포인트' 주소를 붙여넣습니다.

Port: 5432를 확인합니다.

Database: 기본값인 postgres를 입력합니다. (별도로 생성한 DB가 없다면 기본 DB명입니다.)

Username: 설정하셨던 마스터 이름(예: postgres)을 입력합니다.

Password: 설정하신 마스터 암호를 입력합니다.

[Test Connection] 버튼을 눌러 연결되는지 확인합니다.

4. CLI

psql -h <엔드포인트> -p 5432 -U <마스터사용자이름> -d postgres

ls -lh docs/sample/original-comparison.json -> 81KB

필드명 축약

ls -lh docs/sample/compressed-comparison.json -> 58KB

zlib 압축 + 필드명 축약

zlib 압축 + OG

도커는 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼입니다. 소프트웨어를 '컨테이너'라는 표준화된 유닛으로 패키징하여, 개발 환경과 운영 환경의 차이 없이 어디서든 동일하게 실행되도록 돕습니다. 가상 머신보다 가볍고 빠르며 자원을 효율적으로 사용하는 것이 특징입니다.

2. Docker Image

도커 이미지는 컨테이너를 생성하기 위한 읽기 전용 설계도(템플릿)입니다. 코드, 라이브러리, 설정 파일 등 애플리케이션 실행에 필요한 모든 것을 담고 있는 스냅샷과 같습니다. 한 번 만들어진 이미지는 변하지 않으며, 이 이미지를 공유하면 누구나 똑같은 환경을 복제할 수 있습니다.

3. Docker Container

컨테이너는 도커 이미지를 실행한 상태로, 애플리케이션이 실제 구동되는 격리된 공간입니다. 이미지라는 설계도로 만든 '실제 제품'에 비유할 수 있으며, 독립된 자원을 할당받아 프로세스가 실행됩니다. 하나의 이미지로 여러 개의 컨테이너를 동시에 띄울 수 있고, 삭제와 생성이 매우 자유롭습니다.

4. Dockerfile

도커파일은 이미지를 만들기 위한 명령어들을 모아놓은 텍스트 파일입니다. 어떤 베이스 이미지를 쓸지, 어떤 파일을 복사할지, 어떤 명령어를 실행할지 적어둔 '레시피'와 같습니다. 이 파일을 실행(build)하면 자동으로 도커 이미지가 생성되어 환경 구축을 자동화할 수 있습니다.

차이점 요약

1. Docker Compose

Docker Compose는 여러 개의 컨테이너를 하나의 서비스로 정의하고 묶어서 관리할 수 있게 도와주는 도구입니다.

별도의 run.sh 스크립트 파일을 작성하지 않아도, 하나의 docker-compose.yml 파일만으로 여러 컨테이너의 실행 환경과 설정을 선언적으로 정의할 수 있습니다.

####### run.sh #######
# 1. 네트워크 생성
docker network create my-project-network

# 2. 볼륨 생성
docker volume create postgres_data

# 3. Redis 실행
docker run -d --name my-project-redis \
  --network my-project-network \
  redis:7-alpine

# 4. Postgres 실행
docker run -d --name my-project-postgres \
  --network my-project-network \
  -e POSTGRES_USER=myuser -e POSTGRES_PASSWORD=mypass \
  -v postgres_data:/var/lib/postgresql/data \
  postgres:15-alpine

# 5. API 서버 빌드 및 실행 (매우 복잡해짐)
docker build -t myproject-api -f Dockerfile.dev .
docker run -d --name my-project-server \
  --network crypto-express-network \
  -p 3000:3000 \
  -v $(pwd):/app -v /app/node_modules -v /app/.pnpm-store \
  -e DATABASE_URL=... (기타 환경변수 생략) \
  crypto-api sh -c "pnpm install && pnpm run start:dev"

• https://tsx.is/
• https://www.npmjs.com/package/dotenv
• https://node-postgres.com/

DB 만들기 - Docker

https://orm.drizzle.team/docs/guides/postgresql-local-setup 해당 문서 참고

drizzle.config.ts

import { defineConfig } from 'drizzle-kit';

export default defineConfig({
  schema: './src/db/schema.ts',
  out: './drizzle',
  dialect: 'postgresql',
  dbCredentials: {
    url: process.env.DATABASE_URL!,
  },
});

Database 모듈 설정

// db.module.ts
import 'dotenv/config';
import { drizzle } from 'drizzle-orm/node-postgres';
import { Module, Global } from '@nestjs/common';
import { Pool } from 'pg';

import { NodePgDatabase } from 'drizzle-orm/node-postgres';
import * as schema from './schema'; // Your Drizzle schema files

// The type for your fully configured Drizzle DB instance
export type DB = NodePgDatabase<typeof schema>;

const dbProvider = {
  provide: 'DATABASE',
  useFactory: () =>
    drizzle({
      connection: {
        connectionString: process.env.DATABASE_URL,
        ssl: false, // 로컬 Docker에서는 SSL 지원 X 
      },
    }),
};

@Global()
@Module({
  providers: [dbProvider],
  exports: ['DATABASE'],
})
export class DbModule {}

schema - user

import { integer, pgTable, varchar } from 'drizzle-orm/pg-core';

export const usersTable = pgTable('users', {
  id: integer().primaryKey().generatedAlwaysAsIdentity(),
  name: varchar({ length: 255 }).notNull(),
  age: integer().notNull(),
  email: varchar({ length: 255 }).notNull().unique(),
});

뽀나스

import { drizzle } from "drizzle-orm/node-postgres"
const db = drizzle(process.env.DATABASE_URL);
const pool = db.$client;

// above is equivalent to
import { drizzle } from "drizzle-orm/node-postgres";
import { Pool } from "pg";
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});
const db = drizzle({ client: pool });

첫번째 방식은 기본설정을 그대로 쓰는 것 튜닝 X

두번째는 Pool을 만들어서 세부 설정(튜닝)함 해당 튜닝 config 정보들은 링크 참고

• https://node-postgres.com/apis/client

type Config = {
  user?: string, // default process.env.PGUSER || process.env.USER
  password?: string or function, //default process.env.PGPASSWORD
  host?: string, // default process.env.PGHOST
  port?: number, // default process.env.PGPORT
  database?: string, // default process.env.PGDATABASE || user
  connectionString?: string, // e.g. postgres://user:password@host:5432/database
  ssl?: any, // passed directly to node.TLSSocket, supports all tls.connect options
  types?: any, // custom type parsers
  statement_timeout?: number, // number of milliseconds before a statement in query will time out, default is no timeout
  query_timeout?: number, // number of milliseconds before a query call will timeout, default is no timeout
  lock_timeout?: number, // number of milliseconds a query is allowed to be en lock state before it's cancelled due to lock timeout
  application_name?: string, // The name of the application that created this Client instance
  connectionTimeoutMillis?: number, // number of milliseconds to wait for connection, default is no timeout
  keepAliveInitialDelayMillis?: number, // set the initial delay before the first keepalive probe is sent on an idle socket
  idle_in_transaction_session_timeout?: number, // number of milliseconds before terminating any session with an open idle transaction, default is no timeout
  client_encoding?: string, // specifies the character set encoding that the database uses for sending data to the client
  fallback_application_name?: string, // provide an application name to use if application_name is not set
  options?: string // command-line options to be sent to the server
}

참고자료

• https://docs.nestjs.com/fundamentals/custom-providers

• https://orm.drizzle.team/docs/get-started/postgresql-new

• https://orm.drizzle.team/docs/get-started-postgresql#node-postgres

하지만 이때 발생되는 에러는 TS가 모든 폴더 및 파일을 컴파일 하다보니 dev 환경에서 서버를 시작하면 컴파일 에러가 나와 바로 테스트하기 어려운 경우도 생긴다.

이때 tsconfig를 다음과 같이 수정해서 컴파일 문제를 해결한다.

// tsconfig
{
  "compilerOptions": {
    // ... 기존 설정
  },
  "exclude": [
    "node_modules",
    "src/archive" // archive 폴더를 컴파일 대상에서 제외
  ]
}

기본적인 Union 타입 선언

type Fruit = "apple" | "orange" | "lemon"| "melon"

const myFruit: Fruit  = "kiwi" // Type '"kiwi"' is not assignable to type 'Fruit'

const yourFruit: Fruit = "apple"

배열에서 Union 타입 추출하기

const fruits = ["apple", "orange", "lemon"] as const

type Fruits = typeof fruits[number]

객체에서 Union 타입 추출하기 (key, value)

const countryCurrency = {
    KOREA : "KRW",
      USA : "USD",
      CANADA : "CAD",
} as const;

type Country = keyof typeof countryCurrency
type Currency = (typeof countryCurrency)[keyof typeof countryCurrency]