목차
- Typia 설치와 의존성 문제
- E2E 테스트 데이터 생성 방법
- 테스트용 팩토리 함수 활용법
- Payment 관련 DB 테이블 설계와 네이밍 고민
- 모든 API 응답에 공통 응답 구조 적용 방법
- Typia Tags를 이용한 Swagger 문서 생성 이슈
- BDD 스타일 E2E 테스트 의견
- 외부 서비스 설계 참고자료 소개
- Go 게임서버 프로젝트 소개
- 기타 소식 및 링크
1. Typia 설치와 의존성 문제 🛠️
- Typia는 타입스크립트 타입 기반의 JSON 검증, 변환 라이브러리임.
- Typia 설치 가이드 참고할 것.
- 점점 의존성이 많아져서 세팅이 까다로워지는 편.
- 설치 시 계속 추가 패키지를 설치해야 해서 번거로울 수 있음.
- 실패하는 프로젝트가 있으면 Typia 관련 플러그인과 설정을 다시 점검하길 권장함.
2. E2E 테스트 데이터 생성 방법 🔍
- 테스트 데이터 생성 시 직접 데이터 소스 객체를 통해 하나씩 생성하는 방법과
- 서비스 레이어나 실제 유스케이스대로 요청을 보내서 테스트 데이터를 만드는 방법 두 가지가 있음.
- 직접 Prisma 같은 ORM 객체를 하나씩 생성하는 방식은 데이터가 많으면 비효율적임.
- 이상적인 방법은 테스트 목적에 맞게 전략적으로 선택하는 것인데,
- 간단한 단위 테스트에는 직접 생성이 편리하고,
- 시나리오 기반 E2E 테스트에는 실제 서비스 호출 방식을 선호함.
- 테스트 데이터 롤백과 시드 관리를 위한 도구를 만드는 것도 좋은 방법임.
- setup/teardown을 별도 함수로 분리하는 게 테스트 유지관리 측면에서 유리.
3. 테스트용 팩토리 함수 활용법 ⚙️
- 테스트 관련 기능을 지원하는 팩토리 함수나 헬퍼를 만들어 두면 편리함.
- 서비스 함수에 의존하다 보면 미구현 기능이나 다른 의존성이 발생할 수 있어 분리 권장.
- 팩토리는 실제 서비스 구조를 모방하지만 테스트 목적으로 단순화한 구현체로 볼 수 있음.
- 테스트 시간이 단축되고, 테스트 목적에 맞는 데이터 생성과 클린업이 쉬워짐.
4. Payment 관련 DB 테이블 설계와 네이밍 고민 💳
- 주문(Order)과 결제(Payment) 도메인 설계 시 다음 테이블 분리를 고려함.
- PaymentTransaction: 결제 상태, 수단, PG 거래번호 등 결제 단위 정보를 담는 테이블.
- PaymentTransactionLog / History / Snapshot: 결제 및 주문 취소 이력 기록용.
- 네이밍 차이
- 로그(Log): 시스템 이벤트, 메타데이터 기록용, 주로 기술적 목적.
- 히스토리(History): 상태 변화나 비즈니스 이력 기록용, 기록의 연속성과 의미가 있음.
- 스냅샷(Snapshot): 특정 시점의 상태를 저장, 조직마다 해석이나 컨벤션이 다름.
- 추천: 기록 목적이라면 'History'가 직관적이고 의미에 부합.
- Payment vs PaymentTransaction 차이
- Payment는 전체 결제 프로세스 단위 또는 큰 도메인 개념.
- PaymentTransaction은 결제 시도 하나하나(성공, 취소 등) 내역을 뜻함.
- 참고: 실제 서비스 설계는 다양하니 토스페이먼츠, PayPal 등 문서 참고 추천.
5. 모든 API 응답에 공통 응답 구조 적용하기 📡
- 응답에 항상 statusCode, message 등 공통 데이터를 포함하고 싶을 때
- DefaultResponseDTO<T> 같은 제네릭 DTO를 만들고, 필요한 DTO를 주입하여 사용 가능함.
- Interceptor나 미들웨어에서 응답 포맷을 통일하는 방법도 있음.
- 각 방법은 프로젝트 특성 및 프레임워크 지원에 따라 선택.
6. Typia Tags를 이용한 Swagger 문서 생성 이슈 🐞
- Typia tags를 이용해 Nestia로 생성하는 Swagger 문서에서 array 타입 Example 지정 문제 발생.
- 중첩된 배열 타입이나 복잡한 인터페이스에서 Example 필드가 제대로 동작하지 않는 경우 있음.
- 해결법으로는 직접 Swagger 데코레이터를 추가하거나 manual override 작업 필요.
7. BDD 스타일 E2E 테스트 적용 의견 🧪
- BDD(Behavior Driven Development) 스타일을 반영한 E2E 테스트를 지지하는 의견이 많음.
- 실제 유스케이스를 시나리오로 표현하여 테스트 가독성과 유지보수성 향상.
- 실제 서비스 흐름과 유사하게 테스트 설계를 권장.
8. 외부 서비스 설계 참고자료 소개 📚
- Token 결제, 주문 도메인 설계 참고 자료로 '토스페이먼츠' 공식 문서가 추천됨.
- https://developer.paypal.com/docs/api/payments/v1/ 도 PayPal 결제 API 설계 참고에 유용.
- 이 외에도 도메인에 맞는 실제 사례를 다양하게 조회해보는 것이 설계에 큰 도움이 됨.
9. Go 게임서버 프로젝트 소개 🎮
- Go 언어로 만든 게임 서버 'animalized-server' 소개 및 홍보.
- GitHub: https://github.com/BJS-kr/animalized-server
- 외국 개발자들에게도 긍정적 반응을 얻고 있어 관심 추천.
10. 기타 소식 및 공유된 링크 🔗
- Typia 설치 가이드: https://typia.io/docs/setup/#unplugin-typia
- 결제 API 참고 문서
- 토스페이먼츠: (내부 언급 참고)
- PayPal: https://developer.paypal.com/docs/api/payments/v1/
- 게임서버 GitHub: https://github.com/BJS-kr/animalized-server
- 기술 뉴스: https://news.hada.io/topic?id=18751&utm_source=slack&utm_medium=bot&utm_campaign=T01CRCQLR4K
면접팁⚡
- Payment 도메인 설계 시 테이블과 네이밍을 명확히 구분하고 그 이유를 설명할 수 있어야 함.
- E2E 테스트 전략 선택 시, 직접 데이터 생성 vs. 서비스 호출 방식의 장단점을 알고 있으면 좋음.
- 공통 응답 구조 설계에 대한 이해 및 DTO, Interceptor 활용 경험이 큰 장점.
- Typia 같은 타입 변환 및 검증 도구 활용 경험을 어필하면 최신 트렌드에 밝다는 인상을 줄 수 있음.
- BDD 스타일 테스트 설계 경험 및 그 효과를 구체적으로 말할 수 있으면 면접에서 좋은 점수 획득 가능.
#Typia#E2ETesting#DBDesign#PaymentSystem#NestJS#Swagger#BDD#GoLang#APIResponse#SoftwareTesting