상어코딩

DTO 관리 전략과 API 계약 모듈 도입도입 동기서비스가 많아지면서 API마다 각기 다른 Request/Response DTO가 수십 종으로 증가했습니다.BFF 레이어에서 뷰모델을 위해 동일한 DTO를 중복 정의하거나, 혹은 모든 필드를 그대로 내려보내는 방식은 유지보수 비용과 보안 리스크를 키웠습니다.이를 해결하기 위해 API 계약(contract) 모듈과 BFF 전용 뷰모델(view-model) 매핑 전략을 결합했습니다.설계 목표DTO 중복 제거: 서비스와 BFF 간 하나의 계약 모듈로 Request/Response 타입 공유응답 스펙 최적화: 클라이언트가 실제 사용하는 필드만 담은 뷰모델 제공유지보수 효율화: 계약 변경 시 한 곳만 수정하면 전체 동기화타입 안정성 확보: 컴파일 타임에 스펙 불일치..

1편. 배경 및 아키텍처 선택 과정도입 배경스타트업 초기에 빠르게 기능을 개발하고 운영 부담을 최소화하는 것은 가장 중요한 목표였습니다.초창기 서비스는 사용자 인증, 프로필 조회, 주문 내역 확인, 알림 제공 정도의 단순한 기능을 요구했지만, 점차 사용자 증가와 함께 동시성, 장애 격리, 로깅·모니터링, 권한 검증 같은 공통 관심사가 대두되었습니다.이때 두 가지 접근을 놓고 고민했습니다.요구사항 정리인증·인가: JWT 기반 인증, 권한 검증 로직이 필요오케스트레이션: 여러 서비스 호출을 병렬로 조합해 클라이언트에 반환공통 정책: 회로 차단, 리트라이, 로깅, 메트릭 수집운영 효율: 가능한 한 애플리케이션 수를 줄이고 배포·모니터링을 단순화확장성: 기능 추가 시 최소한의 코드 변경으로 대응비교 대상항목Sp..