(문서화 외 작업기간 - 약 4일)
아래 API를 구현합니다. 단, 기술 제약사항을 사전에 고려하여 설계해주세요.
1) 커피 메뉴 목록 조회 API
2) 포인트 충전하기 API
3) 커피 주문, 결제하기 API
4) 인기 메뉴 목록 조회 API

@Version 어노테이션 + version 컬럼 적용status 컬럼 추가각 Entity의 상태를 표시하는
status는 이벤트 등 다양한 변화나 통계 추출 등 목적에 따라 유연하게 적용하기 위해Enum이 아니라String으로 관리.



Redis 이미지가 업데이트되어 계정 연동 + Cloud Database만 생성되도록 제한되어 있는 이슈
RedisInsight로 Kafka로 보낸 메시지 내용이 잘 저장되는지 확인하려고 했다.

상당히 낯선 UI가 등장했다. 지난 주까지만 해도 왼쪽의 사이드바가 까만 색이었는데, latest 버전으로 이미지를 가져왔는데 그 사이 업데이트된 걸까?
Database를 생성하려고 하니 로그인 페이지로 이어진다. 자동으로 Cloud DB만 생성하도록 설정되어 있나보다.

Docker Hub로 들어가보니 바로 6일 전에 업데이트 됐다.
→ Docker Hub에서 특정 이미지 버전을 확인해 지정한다.


latest를 2.70으로 바꿔 이전 버전의 RedisInsight를 사용하도록 docker-compose.yml을 수정했다.
Kafka 숙련하기
강의에서 바로 3개의 Partition, Broker를 구성해 클러스터를 형성시키는 걸 시도했었기 때문에 이번 과제에서는 단일 → 다중 클러스터 구조로 발전시키는 과정을 도전해보고 싶었다. 그러나 단일 노트 클러스터를 구성하기에는 아직 내 이해도가 부족한지 여러 에러&경고 메시지를 만났다.
결국 제출 기한을 맞추기 위해 실습 때 작성했던 docker-compose 파일을 그대로 가져왔지만 프로젝트에 적절하게 최적화(병렬 처리)를 못 했다. 제출 기한이 지난 뒤 오후에 이어서 메뉴 조회 API나 Entity 수정을 하며 함꼐 작업을 해볼까 한다.
DB Lock 이해하기
User, 사용자 계정으로 동시에 다른 요청이 들어와 충돌이 발생해 DB에 적절하지 못한 데이터로 수정되는 것을 막기 위해(데이터 정합성) 낙관적 락을 적용했다. 사용자 정보와 관련된 요청이 들어올 때 version 컬럼을 조회하고 예상한 값과 다를 경우 요청이 진행되지 않도록 설정했다.
그리고 구현하지는 않았지만 메뉴 정보 수정 API가 있다고 할 때 주문 요청 API와 동시에 전달될 때 어떻게 할지를 정해야 했다. 프로젝트 구현 중 gemini-CLI를 적용해봤는데 지적을 받고 어떻게 해야 하는지 방법을 우연히 제시당했다. 전체 메뉴를 조회할 때 가격 수정이 적용되지 않도록 비관적 락을 Repository에 적용했다. 동시성 제어 테스트를 아직 제대로 해본게 아니라 잘 했는지 결과는 테스트 방법을 더 조사해본 뒤 시도해야 한다.