Chor:README.md 수정

[Max-1012]

No description provided.

[github-actions]

🤖 AI 코드리뷰

리더보드 — 현재 4위 (리뷰 107건) | 전체 8개 팀 참여 중
업데이트 확인 — 리뷰가 질문을 던지다 — 생각해보기

안녕하세요! 👋 10년차 시니어 개발자 멘토로서 PR을 리뷰해 드립니다.

이번 PR은 README.md 파일과 프로젝트의 ERD(Entitiy Relationship Diagram) 이미지를 추가한 문서화 작업이네요. 과제의 핵심 기능(동시성 제어, 캐싱 등)이 포함된 코드 변경은 아니므로, 과제 요구사항 준수 여부나 이전 피드백 반영 여부에 대한 리뷰는 생략하겠습니다.

---

🟢 잘된 점

1. 문서화를 통한 프로젝트 가시성 향상
   프로젝트의 전체 구조를 한눈에 파악할 수 있는 ERD 이미지를 추가하여 README.md를 풍부하게 구성한 점이 아주 훌륭합니다! 새로 팀에 합류하는 팀원이나 코드를 리뷰하는 사람에게 시스템의 데이터 베이스 구조를 직관적으로 전달할 수 있는 아주 좋은 습관입니다.

---

🔴 필수 수정

• 특이사항 없음 (이미지 파일 추가 및 문서 수정으로만 구성된 안전한 PR입니다.)

---

🟡 권장 개선

1. ERD 이미지 소스 파일 관리 (유지보수성)

   • 이유: ERD는 서비스가 성장하면서 엔티티나 컬럼이 추가/수정될 때마다 지속적으로 변경됩니다. 현재 PNG 파일만 올리셨는데, 그렇게 되면 나중에 테이블 구조가 바뀔 때마다 그림판이나 캡캠으로 다시 그리고 덮어쓰는 번거로운 작업이 필요해집니다.
   • 해결 방법: ERD를 그릴 때 사용한 원본 소스 파일(예: erd.d draw.io 파일, erd.puml (PlantUML))을 docs/ 폴더 등에 함께 커밋하거나, ERDCloud, AqueryTool 같은 웹 기반 도구를 사용하신다면 README에 해당 링크를 남겨두시면 유지보수하기 훨씬 편해집니다!

2. README.md에 프로젝트 세부 설명 추가

   • 이유: ERD 사진 한 장으로 전체 구조를 파악할 수 있지만, README에는 사진 외에도 프로젝트를 이해하는 데 필요한 텍스트 정보가 들어가는 것이 좋습니다. (실무에서도 README의 완성도가 프로젝트의 완성도와 직결된다고 생각합니다!)
   • 권장 내용:
     • 프로젝트 소개: 어떤 서비스인지 한 줄 요약
     • 기술 스택 (Tech Stack): Java, Spring Boot, Redis, DB 등 사용한 기술
     • API 명세: Swagger 링크나 Notion 링크
     • 실행 방법 (How to Run): 로컬 환경에서 켜는 방법 (./gradlew bootRun 등)

---

💡 학습 포인트

1. "다이어그램 as Code" (Diagram as Code)
   단순히 이미지를 캡처해서 올리는 것이 아니라, 코드로 다이어그램을 그려서 버전 관리(Git)를 하는 실무 방식에 대해 알아보시면 좋습니다. 대표적으로 Mermaid나 PlantUML이라는 키워드로 검색해 보세요! GitHub README에서도 별도의 이미지 파일 없이 바로 다이어그램을 렌더링 할 수 있어 아주 유용합니다.

---

🤔 생각해보기

현재 ERD를 그리실 때 어떤 도구(Workbench, DBeaver, draw.io 등)를 사용하셨나요? 만약 서비스가 커져서 테이블이 50개 이상이 되고 복잡도가 극에 달했을 때, ERD를 어떻게 관리하고 시각화하는 것이 개발팀 생산성에 가장 도움이 될까요?

💬 이 질문에 대해 궁금한 점이 있으면 코멘트에 @sparta 를 남겨보세요!
예: @sparta Mermaid를 쓸 때 테이블이 너무 많으면 코드가 너무 길어지지 않나요?

---

AI 리뷰는 참고용입니다. 최종 판단은 팀원이 직접 합니다.

[github-actions]

🤖 AI 코드리뷰

리더보드 — 현재 4위 (리뷰 107건) | 전체 8개 팀 참여 중
업데이트 확인 — 리뷰가 질문을 던지다 — 생각해보기

📋 과제 요구사항 준수 여부

• 🔴 동시성 제어 기술 제한 위반 (치명적)
  • 과제 요구사항에서 **"필수: Lettuce 기반 Redis Lock (Redisson 사용 금지)"**으로 명시되어 있습니다.
  • 하지만 README.md의 변경 내용을 보면, 이전에는 Lettuce와 Redisson을 혼용하던 것에서 과감히 Lettuce 관련 내용을 제거하고 **"Redisson 기반 Redis 분산락 - BLOCKING Watchdog + AOP ,Pessimistic Lock"**으로 최종 기술 스택을 확정 지었습니다.
  • 필수 요구사항을 위반했으므로 즉시 수정해야 합니다. Lettuce 기반의 Lock을 구현하고, Redisson은 '도전 기능'으로만 남겨두어야 합니다.

🟡 개선 제안

1. 목차와 내용의 불일치

   • 7번 목차를 도전 구현 — 동시성 제어로 변경했으나, 하단 앵커 링크는 (#필수-구현--동시성-제어)로 그대로 유지하고 있습니다. 목차를 클릭해도 제대로 이동하지 못하는 깨진 링크가 됩니다. 글자를 바꾸면 앵커 해시도 함께 바꿔야 합니다.
   • 과제 요구사항상 '동시성 제어'는 필수 기능이므로, 목차를 '도전 구현'으로 바꾸는 것 자체가 규칙 위반입니다. 원래대로 '필수 구현'으로 돌려놓으세요.

2. 환불(Refund) 도메인 은폐

   • 서비스 소개에서 '환불' 문구를 제외하고, 패키지 구조에서 refund 디렉토리 항목을 삭제했습니다. 기능이 미구현되어 숨기려는 의도로 보이지만, 문서는 투명해야 합니다. 구현된 기능이라면 그대로 명시하고, 아니라면 미구현 상태로 두어야지 히스토리를 지워버리면 안 됩니다.

🔄 이전 피드백 반영 여부

• ERD 이미지 소스 파일 관리: 미해결. 여전히 images/ERD.png 단일 파일만 존재하며 유지보수를 위한 원본 소스 파일이나 링크가 추가되지 않았습니다.
• README.md 프로젝트 세부 설명: 미해결. 테이블 명세 등 상세 텍스트를 모두 삭제하고 이미지 하나로 대체했습니다. 오히려 가독성과 전달력이 퇴보했습니다.

💡 학습 포인트

• 문서의 진실성: README는 개발자의 얼굴입니다. 구현하지 않은 기능을 구현한 것처럼 포장하거나, 과제의 제약사항(Lettuce 필수)을 회피하기 위해 문서를 조작하는 것은 실무에서 치명적인 신뢰도 하락으로 이어집니다. 코드와 문서는 항상 일치해야 합니다.

🤔 생각해보기

과제의 명시적인 제약사항(Lettuce 사용 필수)을 어기고 Redisson으로 전면 교체한 구체적인 기술적 이유가 무엇인가요? 만약 Redisson을 선택해야만 했던 타당한 이유가 있다면, 그것은 과제의 '도전 기능' 섹션에 얼마나 논리적으로 설득력 있게 기술되어 있나요?

💬 이 질문에 대해 궁금한 점이 있으면 코멘트에 @sparta 를 남겨보세요!

---

AI 리뷰는 참고용입니다. 최종 판단은 팀원이 직접 합니다.