본문 바로가기

Study

[내일배움캠프 TIL] 20일차 - 1차 프로젝트 마무리, 회고

728x90
반응형

1차 프로젝트가 끝났습니다.

다른조들 발표를 보면서 제가 부족한게 많구나 생각을 했습니다.

 

아쉬웠던 점과 피드백 등 정리해보았습니다.

 

 

1. 아쉬운 점: 인프라의 자동화 (CI/CD)

  • Docker 기반 CI/CD 미구현: AWS에 jar파일로 배포하는 것도 처음이라 시행착오가 있었고, 시간이 없어 실제 배포 과정에서 Docker를 활용한 파이프라인 구축까지 나아가지 못한 점이 아쉽습니다.

2. 외부 API 관리와 시스템 안정성 (Resilience)

실무에서는 외부 API(AI API 등)가 언제든 실패할 수 있다는 가정을 해야 함을 배웠습니다.

  • 서킷 브레이커 (Circuit Breaker): 외부 API 호출 실패가 반복될 때, 시스템 전체가 마비되지 않도록 통로를 차단하고 대체 로직을 실행하는 패턴의 중요성을 배웠습니다.
  • Fallback 로직 설계: AI API 호출에 실패하더라도, '메뉴 저장'과 같은 핵심 비즈니스 로직은 중단 없이 완료되어야 합니다. 서비스의 필수 기능과 부가 기능을 분리하여 설계하는 능력이 필요함을 느꼈습니다.
  • 로깅과 과금 관리: AI 서비스는 호출 횟수가 곧 비용(과금)입니다. 모든 호출 이력을 로그로 남겨 추적성을 확보하고, 호출 실패 및 성공에 대한 Fail 다이어그램을 작성하여 예외 케이스를 정형화해야 합니다.

3. 코드의 품질과 협업 컨벤션

  • Import 최적화: 실무에서는 사용하지 않는 import *(아스타 링크)를 지양합니다. 명확한 의존성 파악을 위해 필요한 클래스만 명시적으로 임포트하는 습관을 들여야 합니다.
  • Naming & Style: 변수와 메서드의 네이밍 이슈를 방지하고, 팀원 간 코드 스타일을 강제로 일치시키기 위해 ArchUnit 같은 도구를 활용하여 아키텍처와 코딩 규칙을 자동 검증하는 방법을 알게 되었습니다.
  • Lost Update(두 번의 갱신 분실) 방지: 동시성 제어가 미흡할 때 발생하는 데이터 손실 문제를 인지했습니다. 이번 프로젝트에서 고민했던 비관적 락Retry 전략을 통해 이를 어떻게 해결했는지 다시 한번 되새겼습니다.

4. 향후 액션 아이템 (To-Do)

  • Docker 학습: 로컬 개발 설정을 넘어 배포용 컨테이너 최적화 공부.
  • Resilience4j 적용: 서킷 브레이커 라이브러리를 직접 적용해보고 실패 시 대응 로직(Fallback) 구현해보기.
  • ArchUnit 도입: 다음 프로젝트 시작 시 코드 스타일 검증 룰을 먼저 설정하고 시작하기.
반응형