6주차 기준 코드 리뷰를 남깁니다.

[kimssy-gahyun]

• 테스트 코드

1. 예외 처리 체계 및 테스트 전략 점검
   테스트 코드 상 오류가 다른 에러 코드로 매핑된 사례가 있었습니다. 예외 타입과 에러 코드의 책임 범위를 명확히 구분해보시길 권장드립니다.
   또한 통합 테스트는 잘 구성되어 있었으나, 개발 단계에서 단위 테스트를 병행하지 않은 점은 보완이 필요합니다.
   기능 구현과 동시에 단위 테스트를 작성하는 TDD 방식은 로직 단위 검증과 회귀 방지에 효과적입니다.
   최종 발표 전에는 사용자 관점의 인수 테스트 및 시스템 테스트를 통해 전체 기능 흐름과 예외 시나리오를 종합적으로 점검해보시길 권고드립니다.

• 코드 리팩토링 관련

2. 결제·예치금·정산 서비스 분리
   세미프로젝트 초기 설계 단계에서 조금 더 깊이 고민했다면, 현재와 같은 구조를 처음부터 구현할 수 있었을 것으로 보입니다.
   또한 JPA 기술의 도입 배경이 객체 중심 설계를 유지하면서 반복적인 SQL 작성을 줄이기 위함이라는 점을 함께 설명드렸습니다.
   현재처럼 조인 의존도를 낮추고 엔티티 중심으로 개선된 구조는 JPA의 기술적 컨셉에 부합하는 방향입니다.
   이의 연장선에서, JPQL이나 직접 쿼리 작성 없이도 연관관계 매핑과 탐색만으로 해결 가능한 부분이 있는지 점검해보시길 바랍니다.
   지금도 "쿼리를 덜 쓰는 구조" 로 잘 리팩토링 하였지만, 여기서 "쿼리를 직접 작성하지 않아도 되는 구조" 로의 리팩토링을 고민해보세요.

3. Kafka 적용
   Apache Kafka 기반 비동기 환경에서 주문 로직에 락을 적용한 이유는 동시 접근에 따른 임계 구역 문제를 방지하기 위함으로, 의도 자체는 타당했습니다.
   다만 Redis 기반 분산 락을 모든 경로에 일괄 적용하는 것은 과도할 수 있으므로, 파티션 단위 처리와 메시지 특성을 고려해 필요한 구간에만 선택적으로 적용하는 것이 바람직해 보입니다.

• 배포 파이프라인 관련

4. CI 빌드 및 설정파일 구성
   공통 코드 규모가 작고 변경이 적다면 현행 유지도 가능하나, 규모가 크고 변경이 잦다면 시멘틱 버전 전략과 자동화된 배포 방식을 고려하는 것이 적절합니다.
   또한 테스트 등 외부 인프라에 대한 의존성이 있는 경우, CI 파이프라인에 테스트 환경을 함께 구성하여 재현 가능한 실행 환경을 만드는 것이 필요합니다.