2025-02-05

목차

1. 도메인 주도 설계(DDD)와 디자인 패턴 적용 시기와 학습법
2. Prisma 스키마 폴더 사용 시 배포 이슈와 해결 방법
3. HTTPS 도메인 문제 원인과 점검 포인트
4. NestJS에서 Redis 캐시 매니저 연동 문제
5. MSA에서 메시지 큐 활용과 데이터 유실 방지
6. NestJS API 문서 자동화 - Swagger vs Nestia
7. AWS Lambda 서버리스 환경과 비용 절감 전략
8. 개인 깃허브 활동과 이직에 미치는 영향
9. 유한 상태 머신(FSM) 상태 전이와 태깅된 유니언
10. TypeORM에서 날짜 필드 변환 문제 사례 공유

1. 도메인 주도 설계(DDD)와 디자인 패턴 적용 시기와 학습법 🎯

• 핵심: 디자인 패턴과 DDD는 문제가 발생했을 때 자연스럽게 필요성을 느끼며 적용하게 됨.
• 설명:
  • DDD는 복잡한 도메인 로직을 분리하고 유지보수 쉽게 하기 위한 아키텍처 설계 방식.
  • 디자인 패턴은 반복되는 문제를 해결하기 위한 재사용 가능한 코드 구조.
• 조언:
  • 문제 상황을 겪어보면서 왜 필요한지 깨닫는 것이 중요.
  • 예를 들어, 헥사고날 아키텍처는 복잡하거나 이상한 코드를 만났을 때 도입.
• 패턴별 예시:
  • 상태 패턴(State Pattern): 상태에 따른 동작을 객체로 분리해 상태 관리를 쉽게 함.
  • 전략 패턴(Strategy Pattern): 알고리즘을 캡슐화해 런타임에 전략을 바꿀 수 있음.
  • 비지터 패턴(Visitor Pattern): 복잡한 매핑 로직을 주요 비즈니스 로직에서 분리하고 싶을 때 사용.
• 학습 팁:
  • GOF 패턴 모두 외우기보다 자주 쓰면서 자연스럽게 익히는 게 효율적.
  • 강의나 간단한 코드만으로는 필요성을 느끼기 어려울 수 있음.
• 참고: https://github.com/next-step/kotlin-blackjack (상태패턴 연습용 프로젝트)

2. Prisma 스키마 폴더 사용 시 배포 이슈 및 해결 방법 🔧

• 상황: previewFeatures = ["prismaSchemaFolder"] 옵션 도입 후 firebase 함수 배포 실패 (Cannot find module '.prisma/client/default').
• 원인 분석:
  • 로컬에서는 정상 동작하지만, 배포 환경에서 Prisma 클라이언트가 제대로 생성되지 않거나 모듈 경로 문제가 발생.
  • 배포 후 prisma generate 명령을 누락했거나, 패키지 설치 과정에서 @prisma/client가 빠짐.
  • pnpm과 npm 사용 차이, 캐시 문제 등도 원인으로 지목됨.
• 해결 방법:
  • 배포 전에 prisma generate 명령 수행 필수.
  • 배포 프로세스 점검: prisma generate → 빌드 → 배포 순으로 진행.
  • 로컬과 비슷한 환경에서 docker로 배포 테스트 해보기 권장.
  • node_modules 삭제 후 재설치, 캐시 클리어 시도.
  • package-lock.json 재생성 권장.
• 추가 팁: webpack 등의 번들러 환경에서는 prisma 클라이언트 빌드 설정 별도 필요.

3. HTTPS 도메인 문제 원인과 점검 포인트 🔍

• 문제: HTTP 접속은 정상인데, HTTPS 접속 시 다른 회사 사이트가 나타남.
• 원인 가능성:
  • SSL 인증서가 잘못된 대상에 등록돼 있거나, 인증서 충돌.
  • DNS 구성 문제, Route53 설정 오류.
  • 프록시, CDN, 캐시 설정 꼬임.
  • 외주 업체에서 잘못된 인프라 설정.
• 점검 방법:
  • Route53 DNS 레코드 및 NS 설정 확인.
  • CloudFront, ALB, Nginx 등 서버 설정의 IP 및 포트 매핑 점검.
  • 인증서 관리자(Certificate Manager)에서 인증서 발급 내역 확인 및 충돌 여부 확인.
  • 클라이언트 측 DNS 캐시 및 브라우저 캐시 초기화 (dns flush) 권장.
  • VPN이나 프록시 영향 여부 조사.
• 현실 조언: 인프라 엔지니어가 없다면 인프라 담당자 티켓을 발행하는 게 빠름.

4. NestJS에서 Redis 캐시 매니저 연동 문제 🐞

• 상황: Redis 서버는 로컬과 WSL에서 정상 작동하나, 코드에서 cacheManager.set() 호출 시 값이 들어가지 않음.
• 원인 추측:
  • NestJS 내 CacheModule 설정과 실제 Redis store가 연결되지 않았을 가능성.
  • WSL과 윈도우 간 포트 및 네트워크 연결 문제.
  • cache-manager-ioredis 라이브러리와 DI(CACHE_MANAGER) 간 호환성 문제.
• 점검 사항:
  • Redis 서버가 WSL 내에서 실행되고, NestJS 서버도 동일 환경에서 실행되는지 확인.
  • 윈도우 CLI에서 Redis 접속 시 연결 여부 확인.
  • NestJS CacheModule 설정에서 store, host, port 올바르게 지정되었는지 검증.
  • 재시작 후 데이터가 날아가는 현상은 TTL 또는 Redis persistence 설정 문제 가능성.
• 권장 대응:
  • Docker 기반 Redis 사용 검토.
  • 실서버는 Linux 환경에 Redis 운영 권장.
  • 캐시 모듈과 Redis 직접 연결 여부 확인 및 공식 문서 비교.

5. MSA에서 메시지 큐 활용과 데이터 유실 방지 🎧

• 기본 구조: 클라이언트 → API Gateway → 메시지 서비스 → Kafka/RabbitMQ → 소비자 서비스 → DB
• 설명:
  • 메시지 큐를 통해 부하 분산.
  • 메시지 서비스가 바로 DB에 저장하지 않고, 큐를 통해 비동기로 처리.
• 장단점:
  • 장점: 부하 분산, 비동기 처리.
  • 단점: 큐 장애 시 데이터 유실 위험.
• 유실 방지 방법:
  • 트랜잭션 아웃박스 패턴 사용: DB에 데이터 저장 후 큐에 메시지 발행.
  • CDC(Change Data Capture) 활용.
  • 주기적 재전송 스케줄러 구현.
• 운영 팁:
  • 큐 메시지 내구성 설정 필수.
  • 장애 상황 대비 큐 상태 모니터링 강화.
  • MSA 환경에서는 DB 커넥션 풀 관리도 중요.

6. NestJS API 문서 자동화 - Swagger vs Nestia 📚

• 배경: 기존 Swagger 데코레이터 관리가 번거롭고 복잡해 API 문서 자동화 도구 필요.
• Nestia 소개:
  • typia 기반 자동 타입 검증 및 SWAGGER 문서 생성.
  • Swagger 데코레이터를 수동으로 하나하나 달 필요 없이 자동화 지원.
  • 코드 생산성이 올라가고, 오류 가능성 감소.
• 사용 시기 및 효과:
  • 큰 규모 API, 복잡한 DTO 활용 시 효과 극대화.
  • 데이터 요청/응답 구조가 복잡하거나 대용량일 때 성능 차이 체감.
• 현장 평가:
  • 체감 차이가 크지 않을 수도 있음(간단한 API 한정).
  • 널리 쓰이고 있는 공식 Swagger 대안.

7. AWS Lambda 서버리스 환경과 비용 절감 전략 ☁️

• 서버리스 개념: 호출 있을 때만 실행되고, 사용한 만큼 비용을 지불하는 컴퓨팅 모델.
• 핵심 장점:
  • 서버 관리 불필요.
  • 초기 단계나 사이드 프로젝트에 비용 효율적.
  • 프리티어 범위가 넓어 거의 무료 사용 가능.
• 실제 운영:
  • NestJS 서버는 람다 핸들러 진입점(lambda.ts)과 일반 main.ts 분리.
  • 도커 컨테이너 이미지로 람다 배포 가능(ECR 활용).
• 비용 주의점:
  • NAT Gateway, RDS 사용 시 비용 상승 요인.
  • 높은 트래픽이나 공격성 트래픽에 노출되면 비용 급증 가능.
• 비교:
  • Fargate 대비 람다는 오토스케일링과 비용 측면에서 유리하나 RAM 제한 존재.
  • 배치 작업에 AWS Batch 활용 권장.
• 운영 팁:
  • 콜드 스타트 문제는 대부분 유즈케이스에서 크지 않음.
  • nginx 설정, ALB 연동 등은 람다 부가 설정에서 자동 처리되는 경우 많음.
  • 클라우드 인프라 관리 부담 감소.

8. 개인 깃허브 활동과 이직에 미치는 영향 🌱

• 질문: 개인 프로젝트 깃헙 잔디가 비어도 이직에 불리한가?
• 답변:
  • 경력과 최근 3개월 활동이 중요.
  • 회사 일에 충실한 개발자라면 충분히 좋은 평가를 받음.
  • 잔디 많다고 평가가 오르는 건 아님.
• 조언:
  • 개인 프로젝트보다는 회사 실적과 업무 경험을 중심으로 어필.
  • 필요 시 알고리즘 문제 풀이나 오픈소스 기여 병행.

9. 유한 상태 머신(FSM)에서 이전 상태에 따른 전이 관리 🧩

• 문의: 같은 상태라도 이전 상태에 따라 다음 상태가 다를 때 상태 머신 설계 방법.
• 설명:
  • 이 경우 별도의 상태로 분류하는 게 일반적.
  • Tagged Union(태깅된 유니언) 타입이라는 타입 시스템 개념과도 연결.
  • 상태 전이 그래프로 표현할 때 같은 상태라도 여러 노드로 구분 가능.
• 도움말:
  • FSM(Finite State Machine)은 상태별 행동 규칙을 명확히 정의하는 오토마타 모델.
  • mermaid.js 같은 도구로 시각화 가능.
  • AI 도구라도 상태 전이 그래프 생성에 도움될 수 있으나 비용 고려.

10. TypeORM에서 날짜 필드 변환 문제 사례 공유 ⏳

• 문제: 일부 timestamp(6) 필드가 DB에서 문자열로 변환되어 나옴.
• 원인 조사:
  • 같은 엔티티 클래스 내에서도 필드별 dateTransformer 구현 오류 가능성.
  • 예시: from/to 메서드 반대로 작성된 경우 발견됨.
• 해결책:
  • 변환 로직 꼼꼼히 검토.
  • 엔티티 클래스 내 각 컬럼 트랜스포머 코드 점검.
• 학습 포인트:
  • ORM에서 날짜나 특수 타입 변환은 직접 구현 로직에 따라 크게 달라질 수 있음.
  • 디버그 시 엔티티 값 타입 일관성 확인이 중요.

면접팁⚡

• 디자인 패턴은 공부만 하지 말고, 실제 문제를 접하며 자연스럽게 습득한다는 점 언급.
• 깃허브 잔디가 없어도 경력과 직무 관련 프로젝트 경험이 더 중요함을 인지.
• 서버리스 개념을 단순한 ‘서버 없음’으로 오해하지 말고, 호출 시점에 서버가 활성화되는 ‘숙박 개념’으로 이해하면 설명하기 쉬움.
• FSM과 Tagged Union 컨셉 이해도가 높으면 복잡한 상태 관리 이슈 해결에 강점.

링크🔗

• 상태 패턴 연습 예제: https://github.com/next-step/kotlin-blackjack
• AWS Fargate Spot (저비용 실행 옵션): https://aws.amazon.com/ko/blogs/korea/aws-fargate-spot-now-generally-available/
• NestJS Redis 커스텀 캐시 예제: https://github.com/iamkanguk97/Mappilogue-Server/tree/dev/src/modules/core/custom-cache
• NestJS + Lambda 예제 레포: https://github.com/ddi-ring/backend
• Imweb DNS 캐시 초기화 가이드: https://imweb.me/faq?mode=view&category=30&category2=43&idx=49037