[🚀 사이클2 - 미션 (기물 확장 + DB 적용)] 모카 미션 제출합니다.

[softmoca]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

어떤 부분에 집중하여 리뷰해야 할까요?

안녕하세요 두둠 ! 🙋🏻‍♂️
이번 PR은 이전과는 조금 다른 방식으로 진행해보았습니다.

이전 미션(블랙잭, 장기 사이클1)까지는
“모든 선택에 대해 충분히 고민하고 트레이드오프를 정리한 뒤, 스스로 납득한 상태에서 코드를 작성하는 것”을 목표로 했습니다.

하지만 이번 사이클2에서 DB 기능을 고려하며, 사전에 공부하고 정리하고 싶은 내용이 많다 보니 너무 과하게 진행 속도가 크게 느려졌고 TDD 사이클 또한 제대로 유지하지 못하는 상황이 발생했습니다.

특히 DB 설계를 여러 번 갈아엎으면서 테스트를 먼저 작성하기보다 기능 구현 → 콘솔 검증 → 테스트 추가 형태로 흐르게 되었고, 이 과정에서 기존 학습 방식에 대한 한계를 느끼게 되었습니다.

동시에 네오와의 1on1, 브라운의 피드백을 통해 학습 방향을 다음과 같이 수정해보았습니다.

👉 “완벽하게 고민하고 시작하기”보다 “부족하더라도 빠르게 구현하고, 자주 리뷰를 통해 방향을 잡아가기”

그래서 이번 PR은 이전처럼 정리된 설계를 검증받기 위한 PR이 아니라,

👉 구현 과정에서의 고민, 확신이 없는 선택, 혼란스러웠던 지점을 그대로 드러내고
리뷰를 통해 함께 방향을 맞춰보고 싶은 PR입니다.

즉,
기존: “이렇게 설계했는데 맞는지 검증해주세요”
이번: “이렇게 해봤는데 이 방향이 괜찮은지 함께 소통하며 여러 방향에 대해 대화하고 고민해보보고 싶어요 !!”
로 바뀌어 이렇게바뀐 스타일을 통해 인사이트를 얼마나 어떻게 얻는지 경험해보고자 해요 !

이전 PR과 스타일이 다른 이유가 이 부분이며,
이러한 맥락을 참고해서 리뷰해주시면 정말 감사하겠습니다 🙇🏻‍♂️

좋은 피드백 부탁드립니다! 🙏

고민하고 혼란스러웠던 지점들

궁성(Palace)을 별도 객체로 분리한 이유

• 처음에는 사이클 1의 주요 목적이었던 변경 범위를 줄이는 장점을 그대로 활용하고 싶어 MoveRule 내부에서 궁성 좌표를 직접 다루려고 했습니다.
• 하지만 그럴 경우 한 기물 파일의 코드가 300줄이 넘어가는 경우가 발생했으며, 5개의 기물이 모두 참조 해야해서 Palace라는 별도 객체로 분리하여 궁성 구조 판별 책임을 맡도록 했습니다.

MoveRule이 Palace를 직접 참조하지 않고 BoardView를 통해 접근하도록 한 이유

• 처음에는 5개의 MoveRule(이 Palace를 직접 import하고 있었습니다. 이 구조에서 Palace의 메서드가 변경되면 5개 파일을 모두 수정해야 했습니다. 사이클1에서 다형성으로 "기물별 규칙이 독립적이어서 변경 범위가 작다"는 구조를 만들었는데, Palace 의존으로 인해 그 장점이 약해지고 있다고 생각이들었습니다
• 그래서 BoardView에 궁성 관련 메서드를 추가하고, Board가 내부에서 Palace에 위임하는 구조로 변경해서 MoveRule들은 BoardView 인터페이스에만 의존해서, Palace가 변경 되어도 Board 한곳만 수정하면 되는 구조가 되었습니다.

장과 사의 MoveRule을 분리한 이유

• 현재 장과 사의 이동 규칙은 완전히 동일합니다. 그래서 처음에는 PalaceMoveRule 하나를 공유하고 있었습니다. 하지만 "코드가 지금 같다"는 것과 "같은 이유로 변경된다"는 것은 다르다고 판단했습니다.
• 만약 사의 규칙만 2칸 이동으로 바뀐다면, 해당 공유 구조에서는 PalaceMoveRule을 수정해야 하고 장도 영향을 받는다고 생각했습니다. 하지만 분리되어 있었다면 AdvisorMoveRule 1개 파일만 수정하면 된다는 장점을 가진다고 생각했습니다.
• 또한 사이클1 규칙 "변경 이유가 다르면 분리한다"와 딱 맞는 상황이라고 생각이 들어 KingMoveRule과 AdvisorMoveRule로 분리했습니다.

pieceType enum을 도입한 이유

• 사이클 1 PR에 도입을 했다가 제거를 했지만 이번에는 그 역할이 다릅니다. 현재 기물의 toString()은 "차", "마" 같은 한글 문자를 반환하며 이걸 그대로 바로 DB 저장에 사용하면 표시용 표현과 저장용 식별자가 결합이 된다고 생각했습니다.
• 이후 화면 출력을 한자 혹은 영어로 바꾸면 DB에 이미 저장된 데이터와 불일치가 생길 것 같다고 생각했습니다. 그래서 이번 PieceType enum은 저장(Piece → 문자열)과 복원(문자열 → Piece) 변환 책임을 가져 DB 저장/복원 용도로 책임을 분리했습니다.

Board의 내부 자료구조를 Map으로 바꾸면 더 좋았겠다는 생각

• 이번 사이클2를 진행하면서, Board의 내부 자료구조가 List<List<Piece>>가 아니라 Map<Position, Piece>였다면 더 자연스러웠겠다는 생각을 자주 했습니다.
  현재 Board는 외부와 소통할 때 거의 항상 Map을 거치고 있습니다.
  들어올 때는 Board.of(Map)으로 Map을 받아서 내부 List로 변환하고, 나갈 때는 findAllPieces()로 내부 List를 순회해서 Map으로 변환합니다. 테스트에서 Board를 만들 때도, DB에서 복원할 때도, DB에 저장할 때도 전부 Map을 경유합니다. 즉 양방향에서 매번 변환을 하고 있습니다.
• 만약 내부가 Map이었다면 Board.of()는 그대로 저장하면 되고, findAllPieces()는 방어적 복사만 하면 되고, 빈 칸을 위해 90칸 중 58개의 EmptyPosition 객체를 만들 필요도 없어질것 같습니다.
• 분명 사이클1 사전학습에서 여러 상황들을 고려해보고 "장기판은 고정 격자 구조이고, 초기 배치를 눈으로 대응하기 쉽다"는 이유로 2차원 리스트를 선택했고, 그 시점에서는 합리적인 판단이라고 생각했습니다.
• 하지만 DB 연동, 테스트용 팩토리, 기물 목록 추출 같은 추가 기능 요구사항이 확장되면서 Board를 사용하는 쪽이 모두 "위치 → 기물" 매핑인 구조가 훨씬 좋은 선택이라는 생각이 내내 들었습니다.
  이것은 처음 설계가 틀렸다는 것이 아니라, 요구사항이 변하면서 더 적합한 자료구조가 드러난 것이라고 생각했습니다.

🙋🏻‍♂️질문

궁성(Palace)을 별도 객체로 분리한 이유 관련 질문 🙋🏻‍♂️

• 처음에는 사이클1의 핵심이었던 "한 기물의 규칙이 바뀌면 그 파일 하나만 수정하면 된다"는 장점을 그대로 유지하고 싶어서, MoveRule 내부에서 궁성 좌표를 직접 다루려고 했습니다. 하지만 그렇게 하면 한 기물의 MoveRule 코드가 300줄이 넘어가는 경우가 발생했고, 궁성 관련 상수와 판별 로직이 5개의 MoveRule에 중복으로 들어가야 했습니다. 그래서 Palace라는 별도 객체로 분리하여 궁성 구조 판별 책임만 맡도록 했습니다.
• 그런데 이 결정을 하면서 모순적인 생각이 들었습니다.
• 처음 구상대로 각 MoveRule이 궁성 로직을 직접 가지고 있으면, 한 기물의 규칙이 변경될 때 그 파일 하나만 수정하고 그 파일의 단위테스트만 확인하면 됩니다. 변경이 전파되는 지점이 1곳이라 유지보수에 좋다고 생각했습니다.
• 반면 현재 구조에서는 궁성의 규칙이 변경되면, 궁성 로직을 참조하는 5개의 기물(장/사/차/포/졸)을 모두 확인하고 수정해야 합니다. 변경 지점이 늘어나므로 유지보수가 나빠진다고 느꼈습니다.
• 하지만 동시에 반대 방향의 생각도 들었습니다. 변경 포인트가 5곳으로 늘어나더라도, 확인해야 하는 하나하나의 파일은 궁성 로직이 빠져있어 코드량이 작고, 각각의 단위테스트가 독립적으로 존재하기 때문에 더 정교하게 검증할 수 있습니다. 즉 "변경 지점은 늘었지만, 각 지점의 파악과 검증은 더 쉬워졌다"는 것입니다.
• 변경 지점이 적은 것이 좋은지, 변경 지점이 많더라도 각각이 작고 독립적인 것이 좋은지에 대해 의견을 듣고 싶습니다.

DB 관련 테스트를 어떻게 짜야 하는지 혼동관련 질문 🙋🏻‍♂️

• DB 기능을 적용하면서 PieceRepositoryTest, GameRepositoryTest, DBConnectionManagerTest, DBInitializerTest 같은 테스트를 작성했는데, 이 테스트들이 무엇을 위한 것인지 확신이 들지 않았습니다.
• 도메인 테스트는 명확했습니다. "차가 직선으로 이동할 수 있는가", "포가 1개를 넘어야 이동 가능한가" 같은 규칙을 검증하는 것이고, 테스트가 깨지면 게임 규칙이 잘못 구현된 것입니다. 실패 원인이 분명하고, 수정해야 할 곳도 명확합니다.
• 반면 DB 테스트는 "저장하고 조회하면 같은 값이 나오는가"를 반복적으로 확인하는 느낌이었습니다. "새 게임을 저장하고 ID를 반환한다", "저장한 게임을 ID로 조회한다" 같은 테스트를 작성하면서, 이것이 JDBC API가 정상 동작하는지를 확인하는 건지, 내가 SQL을 올바르게 작성했는지를 확인하는 건지, 아니면 변환 로직(도메인 ↔ DB)이 맞는지를 확인하는 건지 구분이 되지 않았습니다. 그저 "테스트가 있어야 하지 않을까?"라는 생각만으로 작성한 느낌이 내내 들었습니다.
• 그래서 이 테스트들이 View나 Controller 테스트처럼 도메인 테스트에 비해 효율이 아주 낮은 경우가 아닌가 하는 생각이 들기도 했습니다. 혹은 Repository 단위로 테스트하는 것이 아니라, "게임을 생성하고 → 기물을 이동하고 → 프로그램을 재시작하고 → 이어하기로 복원했을 때 상태가 일치하는가"처럼 Game과 Board를 포함한 통합 테스트에서 활용하는 것이 더 자연스러운 건지도 궁금합니다. DB 관련 테스트는 어떤 관점에서, 어떤 범위로 작성하는 것이 효과적인지 의견을 듣고 싶습니다.

TDD 과정에서 테스트가 예상과 다르게 통과해버린 경험 관련 질문 🙋🏻‍♂️

• 사이클2에서 포(Cannon)의 궁성 대각선 규칙을 TDD로 구현하던 중 혼란스러운 상황을 겪었습니다.궁성 대각선 이동이 가능한 케이스(기물 1개를 넘어 이동)를 먼저 구현한 뒤, 실패해야 할 케이스들의 테스트를 작성했습니다. "중간에 기물이 없으면 이동 불가", "다리가 포이면 이동 불가", "도착 칸에 포가 있으면 이동 불가", "1칸 대각선은 넘을 기물이 없으므로 이동 불가" 같은 테스트들입니다.
• 그런데 이 테스트들이 빨간불이 나와야 했는데, 작성하자마자 파란불이 떴습니다. 이유는 기존 직선 이동 로직의 검증에서 이미 걸러지고 있었기 때문입니다. 궁성 대각선은 직선이 아니므로 isStraightLine 검사에서 false가 되고, 궁성 대각선 조건도 만족하지 못하면 최종적으로 false가 반환되어 테스트가 통과한 것입니다. 즉 제가 새로 추가한 궁성 로직이 아니라 기존 로직이 테스트를 통과시키고 있었습니다.
• 이 경험에서 여러 혼란이 생겼습니다.
• 첫째, 이 테스트들은 CannonMoveRule 전체의 동작을 검증하는 통합테스트 성격인데, 제가 의도한 것은 "궁성 대각선 규칙"만 단위로 검증하는 것이었습니다. 테스트 대상을 잘못 잡은 것인지, 아니면 이런 형태가 자연스러운 것인지 판단이 되지 않았습니다.
• 둘째, 궁성 대각선의 실패 케이스를 CannonMoveRule에서 테스트할 것인지, Palace 테스트에서만 검증하고 믿을 것인지 애매했습니다. Palace에서 이미 "궁성 밖이면 false", "대각선 선이 아니면 false"를 테스트하고 있는데, CannonMoveRule에서 비슷한 맥락의 테스트를 또 작성하니 중복이라는 느낌이 강했습니다.
• 셋째, 이런 중복적인 테스트가 유지보수에 오히려 독이 될 수 있겠다는 생각이 들었습니다. 궁성 규칙이 변경되면 Palace 테스트도 수정하고, CannonMoveRule 테스트도 수정하고, TankMoveRule 테스트도 수정해야 합니다. 관리되지 않는 테스트는 "안전망"이 아니라 "변경을 방해하는 짐"이 될 수 있다고 느꼈습니다.
• TDD에서 새로 추가한 로직이 기존 로직에 의해 이미 통과되어 버리는 경우, 그 테스트를 유지해야 하는지 제거해야 하는지, 그리고 하위 객체(Palace)에서 이미 검증한 내용을 상위 객체(CannonMoveRule)에서 다시 검증하는 것이 중복인지 안전망인지에 대해 의견을 듣고 싶습니다.