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

[LEEJaeHyeok97]

안녕하세요. 수달, 나름대로 고민 지점을 기록하면서 구현했는데, DB가 추가되고 생소한 코드들이 많아져서 첫 PR이 늦어졌습니다.

그래도 스스로 고민하고 한가지라도 의미 있는 것을 얻어가고 싶다는 마음에
이번 미션에 대부분이 선택하지 않을 것 같은 MongoDB라는 NoSQL을 선택했고 콘솔 프로그램의 DB 연결과 몽고 디비의 구조에 대해 처음 알아가며 많은 것을 배운것 같습니다.
이번 리뷰도 잘 부탁드립니다!

체크 리스트

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

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

고민했던 지점.

1. 궁성 구현
   궁성 안에서의 이동전략은 기존 MoveStrategy에 작성하는 것은 메소드의 수를 늘려서 가독성을 저해한다고 생각했습니다.
   따라서 궁성 안의 이동전략을 새로 만드는 것이 가독성에 장점이 있다고 생각을 하다가,
   하지만, 이동 경로를 가져오는 getPath()를 궁성 안에서도 기존 이동 경로를 포함하여 궁성 안의 이동위치를 덧붙여 반환해야 하기 때문에기존 전략에 궁성 조건을 단순히 추가해(덧붙여) 주는 것으로 로직을 수정하기로 결정했습니다.
   분리를 하지 않았으니 한 클래스의 코드가 길어지고 조금 보기 어려워진다는 문제가 있다고 느꼈습니다.
   이 결정이 나쁘지 않은 결정인지 리뷰 부탁드립니다.

2. 왕이 잡히는 경우 게임에서 진다.
   보드에서 왕이 삭제되는 경우 즉시 게임을 종료해야합니다.
   보드의 move에서 이동하며 디오할 위치의 기물을 제거하고 있는데, 이동 메소드에 게임 종료 여부를 확인하는 책임까지 갖게 하는
   것은 과도한 책임이라는 생각이 들었습니다.
   따라서, JanggiGame 객체를 도입하여 게임 흐름을 관제하고 보드객체로 매턴 장군의 존재를 체크하게 하고 게임 종료를 유연하게
   관리할 수 있도록 구현했습니다.
   JanggiGame 객체를 도입함으로써 Board 객체가 컨트롤러에 흘러간 것을 제거할 수 있었고 이것은 분명히 객체지향적 노력의 수확이었습니다.

3. 컨트롤러를 수정하며서 든 궁금증
   Controller의 상차림이 이름과 쌍으로 매칭되는데 BiFunction을 쓰면 Formation enum클래스에서 한번에 초기화할 수 있을 것만 같은데 이 경우 Formation이 Board객체를 의존하게 됩니다. Formation 코드는 다소 지저분해지는 코드가 되는데 Controller의 코드는 상당히 깔끔해지게 됩니다. 이러한 설계가 적절한지 의견이 궁금합니다.

4. JanggiGame 객체
   새로 장기게임 객체를 도입했는데, 불변 객체로 쓰고 싶다는 생각이 들었습니다. 턴을 카운트하는 데이터인 turnCount는 가변인데, 이 부분에서는 완전한 불변 객체는 내부의 불변 데이터 하나만 바뀌어도 다시 새로 만들어서 불변 객체를 초기화해야 하기 때문에 코드의 가독성을 해칠 수 있다는 생각이 들어서 가변으로 turnCount를 만들었습니다. 이 부분이 괜찮을지 리뷰 요청드립니다.

5. DB 연결에 따른 DAO 도입과 기존 MVC 패턴의 확장 설계

DB를 도입하면서 기존 MVC 구조에 DAO 계층을 추가했습니다.
BoardDao를 Controller에 주입하여, Controller가 게임 흐름(새 게임/이어하기)에 따라 DAO를 통해 게임 상태를 저장하고 복원하도록 설계했습니다.
이 과정에서 고민했던 점은 DAO가 도메인 객체(Board)를 직접 반환하는 것이 과연 적절한가 입니다.
현재 findBoardByGameId()는 Document(몽고DB의 문서)를 Board로 반환하여 DAO가 도메인 객체의 생성 방식을 알아야 합니다.
DTO는 좋은 선택지가 될 수 있지만, 현재 규모에서는 오히려 과한 추상화라고 생각해서(현재 작은 규모라 뷰도 도메인을 의존하고 있음)
DAO가 도메인 객체를 직접 다룰 수 있게 선택했습니다.(실선 표시)

7. MongoDB 사용에 따른 장단점 인사이트
   장점:

• 스키마 유연성: 장기판의 기물 정보를 pieces 배열로 하나의 Document에 담을 수 있어, 별도의 테이블 설계(게임 테이블 + 기물 테이블 + JOIN)가 필요 없었습니다. 게임 상태를 하나의 문서로 자연스럽게 표현할 수 있다는 점이 특히 장기 도메인과 잘 맞았습니다.
• 빠른 프로토타이핑: DDL 작성이나 스키마 마이그레이션 없이 바로 데이터를 저장할 수 있어, 도메인 로직 구현에 집중할 수 있었습니다.
• ObjectId 자동 생성: 별도의 시퀀스나 Auto Increment 설정 없이 고유한 타임 스템프 기반 게임 ID를 자연스럽게 얻을 수 있었습니다.

단점:

• 직렬화/역직렬화 비용: Board ↔ Document 변환을 직접 구현해야 했습니다. Team, Type 같은 Enum을 문자열로 저장하고 다시 찾아오는 과정(findTeamByName, findTypeByName)이 필요했고,RDBMS + ORM을 사용했다면 이 부분이 더 간결했을 수 있습니다.
• 트랜잭션 미지원(단일 노드): 현재 구조에서는 문제가 없지만, 게임 상태 저장이 여러 컬렉션에 걸치게 된다면 트랜잭션 관리가 RDBMS보다 까다로울 수 있다는 점을 인지했습니다

[her0807]

안녕하세요 누누! ㅎㅎ

몽고디비를 연결해보셨군요?

적어주신 내용으로 미루어보았을 때 전공자 이신것 같은데 맞을까요?
혹시 다른 디비들을 사용해보시고 몽고디비를 연결해보신 것인지, 비정형데이터를 저장하는 디비도 몽고디비 뿐만 아니라 다른 디비들도 있는데 어떤이유로 선택했는지 조금 더 자세히 듣고싶어요!

[her0807]

Board에서 게임 흐름 관리를 분리해 JanggiGame으로 옮기셨군요? 👍🏻

이전에는 Controller가 Board를 직접 다루면서 턴 관리까지 했을 텐데, JanggiGame이 move(), isFinished(), passTheTurn(), currentTurn()을 하나로 묶어서 게임의 규칙을 한 곳에서 관리할 수 있게 됐어요. 아주 좋은 방향이네용!!

[LEEJaeHyeok97]

이 Game이라는 Orchestration 역할을 하는 도메인을 만들게 됨으로써 발생하는 단점은 없을까요?
매번 저는 이런 도메인을 만들곤 합니다. Lotto 미션에서도 LottoGame, RacingCar 미션에서도 RacingCarGame, ... 매번 했던 방식으로 진행하게 되는데,
게임이라는 이름이 실체가 없으면서 역할이 모호한 것 같아서 매번 사용하고 있으면서도 마음 깊은 곳에서는 불편함이 조금 자리잡고 있습니다. 차라리 Service 계층을 도입해서 Game 도메인이 아닌 Service에서 흐름을 조정하는 방식으로 해도 좋은 선택이지 않을까 하는 고민도 됩니다.
스프링 프로젝트 개발 시 domain-service-controller-repository 레이어드 아키텍처로 service 계층을 자연스럽게 줄곧 잘 쓰고 있어서 일지도 모릅니다.

[her0807]

이 메서드가 궁성 안인지 자체를 확인하지 않고 있어요. 특정 위치가 아니면 무조건 true를 반환하고 있어서, 궁성 밖 (5,5)에 있는 차나 포도 궁성에서 대각선 이동 가능으로 판정되어요!

한번 따라가보면요,,

• from = (5,5), to = (6,6)
• isInPalaceAndCanDiagonalMove((5,5)) → (5,5)는 블록 목록에 없으니까 → true
• isDiagonal → true
• 거리 합 = 2 <= 4 → true
• isNotCorrectPath → false

결과적으로 궁성 밖 모든 위치에서 대각선 이동이 허용되는 상황이에요. 이 메서드를 작성할 때 "궁성 밖 위치"에서 호출되면 어떤 값이 반환되는지 한번 추적해보면 좋을 것 같아요!

[LEEJaeHyeok97]

isNotCorrectPath(...) 옳지 않은 길인가를 체크할 때 궁성 안이 아닌데 대각 이동 -> 이동 불가 판정을 빠뜨리고
궁성 안이면서 불가능한 대각선 이동인가? -> 이동 불가 만 체크하고 있었습니다.

궁성 안이 아닐 때 각선 이동 체크하는 것을 먼저 해서 해당 부분을 수정하였습니다!

private boolean isNotCorrectPath(final Position from, final Position to) {
        if (!palaceInRange(from)) {
            if (isDiagonal(from, to)) {
                return true;
            }
        }
...

[her0807]

대각선 이동을 차단하는 위치 목록 (0,4), (9,4) 가 누락된 것 같아요! 👀
궁성 대각선은 중앙(1,4)/(8,4)과 꼭짓점만 연결하는 건데요, (0,4)는 궁성 상단 변의 중간이라 대각선 라인 위에 없거든요. 현재 코드에서 궁(General)이 (0,4)→(1,5)로 대각선 이동이 가능한 상태입니다!

[LEEJaeHyeok97]

누락된 부분 추가하고 테스트까지 추가했습니다!
보시다시피 이렇게 많은 조건들이 || 연산으로 이어지면 새로운 기능 추가 시 미스가 날 확률이 높아지는 것 같은데, 객체 지향적 설계가 잘못된 신호로 볼 수 있을까요?

[her0807]

항복하면 movePosition()에서 return하는데, playGame()의 while 루프는 계속 돌아요. isFinished()는 장군이 살아있는지만 확인하니까 항복 상태를 모르거든요. 항복 후에 다시 이동 입력을 요청하는 상황이 됩니다.

isFinished()에 항복 상태를 어떻게 반영하면 좋을지 고민해보면 좋을 것 같아요! JanggiGame에 상태를 추가하는 방법도 있고, movePosition의 반환값으로 알려주는 방법도 있는데 어떤 게 더 자연스러울까요?

[her0807]

Map.put()이 기존 값을 덮어쓰니까 동작 자체는 하는데요, 상대 기물을 "잡는다"는 도메인 행위가 코드에서 명시적으로 안 드러나고 있어요. 의도한 거라면 괜찮지만, 만약 나중에 "잡힌 기물 목록"을 보여줘야 한다면 현재 구조에서 어떻게 확장할 수 있을지 한번 생각해보면 좋겠어요!

[her0807]

Team/Type의 getName()을 DB 저장값으로 쓰고 있는데, 이게 어떤 위험이 있을까요? 🤔

현재 getName()이 반환하는 값은 OutputView에서 사용자에게 보여주는 표시명이기도 하고, DB에 저장되는 값이기도 해요. 만약 출력 형식을 "초" → "楚"로 바꾸고 싶다면, 기존에 DB에 "초"로 저장된 데이터는 어떻게 될까요?

표시용 값과 저장용 값을 분리하는 방법에 대해 고민해보면 좋을 것 같아요!

[her0807]

BoardDao가 도메인 객체를 직접 생성하고 있는데, 이 구조를 선택한 이유가 궁금해요.

DAO가 Position.of(), Piece.of(), Board.of()를 직접 호출해서 도메인 객체의 생성 방식을 알고 있는 상태인데요. PR 설명에서 "현재 규모에서는 DTO가 과한 추상화"라고 했잖아요? 그 판단 자체는 괜찮은데, 한 가지 더 생각해보면 좋을 것 같아요.

만약 Board 생성자가 바뀌거나(예: 검증 로직 추가), Piece 생성 방식이 달라지면 DAO 코드도 같이 수정해야 하거든요. 이게 "DB 적용 시 도메인 객체의 변경을 최소화"라는 요구사항과 어떻게 연결되는지 생각해보면 좋겠어요!

[her0807]

누누가 정리한 MongoDB 장점 중 스키마 유연성: pieces 배열로 하나의 Document에 담을 수 있어 JOIN이 불필요라는 부분이 있었는데요, 한 가지 더 깊이 생각해보면 좋을 것 같아요.

현재 구조에서는 매 턴마다 전체 기물 배열을 통째로 교체하고 있어요.

RDBMS였다면 이동한 기물 1~2개만 UPDATE하면 되는데, MongoDB Document 구조에서는 기물 32개를 매번 전부 직렬화해서 저장하고 있거든요. 이 trade-off를 인지하고 있었나요? 현재 규모에서는 문제 없지만, Document로 한 번에 담는 게 항상 좋은 건지 생각해보면 좋을 것 같아요!

[her0807]

PR 설명에서 이렇게 적어주셨는데요!

트랜잭션 미지원(단일 노드): 현재 구조에서는 문제가 없지만, 게임 상태 저장이 여러 컬렉션에 걸치게 된다면 트랜잭션 관리가 RDBMS보다 까다로울 수 있다는 점을 인지했습니다

이 부분은 사실 정확하지 않아요! MongoDB는 4.0(2018년)부터 멀티 도큐먼트 트랜잭션을 지원합니다. 누누가 사용 중인 드라이버(mongodb-driver-sync:5.3.1)도 당연히 지원하고요.

// MongoDB에서도 트랜잭션이 가능해요
try (ClientSession session = client.startSession()) {
    session.startTransaction();
    collection1.insertOne(session, doc1);
    collection2.insertOne(session, doc2);
    session.commitTransaction();
}

다만 누누의 현재 구조에서는 게임 상태가 단일 Document 하나에 전부 들어가기 때문에 트랜잭션이 필요 없는 구조이긴 해요. MongoDB는 단일 Document에 대한 원자적 쓰기를 기본 보장하거든요. 그래서 replaceOne()이 중간에 실패해도 반쯤 저장되는 일은 없어요.

정리하면, 트랜잭션이 안 돼서 까다롭다가 아니라 단일 Document 구조라서 트랜잭션이 애초에 필요 없다가 더 정확한 표현이에요!

[her0807]

장기 도메인에 MongoDB가 정말 적합한 선택일까? 🤔

누누가 MongoDB를 선택한 도전 정신은 정말 좋았어요! 다만 솔직하게 이야기하면, 장기는 RDBMS가 더 자연스러운 도메인이라고 생각해요. 이유를 몇 가지 정리해볼게요.

장기가 RDBMS에 더 맞는 이유

• 데이터 구조가 매우 고정적이에요. 9x10 보드, 고정된 기물 타입, 고정된 팀 — 스키마가 변할 일이 없어요, 그렇기 때문에 몽고디비의 비정형 데이터를 저장하는 이점을 못누리는 상황이에요.
• 기물 이동은 1~2개 행만 변경하면 되는데, Document 구조는 매번 32개 기물을 전부 직렬화해야 해요
• "진행 중인 게임 목록", "특정 플레이어의 전적" 같은 쿼리는 RDBMS가 훨씬 자연스러워요
• 스키마 강제가 오히려 잘못된 데이터 저장을 방지해줘요 예를들면 piece_type에 오타가 들어가면 제약 조건에서 잡히니까요. 지금은 잘못 저장되면 나중에 enum 이나 다른걸로 조회할 때 캐스팅하는 과정에서 오류가 나겠죠?

MongoDB가 빛나는 도메인은

• 데이터 구조가 유동적인 경우 (예: 사용자별 설정, 로그, CMS 콘텐츠)
• 비정형 데이터가 많은 경우
• 수평 확장이 필요한 대규모 트래픽

물론 현재 미션 범위에서는 둘 다 충분히 동작하고, MongoDB를 직접 써본 경험 자체가 귀하다고 생각해요. 학습목적으로 선택한것도 이유가 되니까요!

[her0807]

gameId만 입력하면 어떤 게임이든 불러올 수 있는데요, 만약 이미 왕이 잡혀서 끝난 게임을 불러오면 어떻게 될까요? isFinished()가 바로 true를 반환해서 게임이 즉시 끝나겠지만, 사용자 입장에서는 이어하기를 선택했는데 바로 종료 메시지가 나오는 상황이에요.

MongoDB Document에 게임 종료 여부(isFinished)를 저장하고, 이어하기 시 끝나지 않은 게임만 불러오도록 하면 어떨까요?

[her0807]

두 메서드 모두 _id로 같은 Document를 조회하는데, 네트워크 요청이 2번 나가고 있어요. 하나의 메서드에서 Document를 한 번만 조회해서 Board와 turnCount를 같이 반환하면 어떨까요?

이걸 해결하려고 하면 Board와 turnCount를 묶어서 반환하는 객체가 필요해지는데요, 이게 사실 누누가 PR 설명에서 언급한 DTO의 자연스러운 도입 시점이라고 생각해요.

[LEEJaeHyeok97]

융합소프트웨어학부를 졸업한 전공자 맞습니다!
예리하시군요 :)

비정형 데이터를 저장하는 데이터베이스는 redis 등 다른 것도 많지만, 처음에 Redis 사용을 고려했습니다. 이유는 레디스가 인메모리 DB이고 마비노기 같은 게임의 DB로도 사용되는데, 장기게임에 사용하지 못할까라는 생각으로 고민을 시작했던 것 같아요.
Redis를 고려했을 때 장기를 표현하기 위해서 Key-Value 형태로 저장을 해야해서 어떤 값을 Key로 잡는가가 설계하기 어렵다고 느껴서 RDBMS보다 그럼 장점이 없는 것 아닌가? 어차피 RDB도 테이블을 설계해야 하는데 라는 생각이 들었고 Redis는 선택지에서 지웠습니다.
또 테이블 개념이 없어서 redis는 prefix로 각기 다른 테이블을 구분해야 하는게 불편했는데,
MongoDB는 collection이라는 테이블 개념이 있는 NoSQL DB였고 비정형 데이터를 저장하는 DB 라는 점이 큰 장점으로 느껴졌습니다.

그 이유로는 MySQL 같은 RDB로 테이블 설계 시,
Game(id, turn) -1:N - PieceType(id, game_id, type) - 1:N - Piece(id, piece_type_id, team, row, col)
이런 식으로 설계가 될 것 같은데, 그러면 매버 장기 상태를 저장하고 수정하고 조회하는데, RDB의 경우 조인이
많아지고, 저희 토론조의 산출물이 매 입력마다 데이터를 저장하는 것을 룰로 정해졌으므로 매번 입력마다
저장하기에는 RDB보다 NoSQL 장점이 있다고 느꼈습니다.
데이터베이스가 변경되어야 한다면 MySQL은 인덱스를 추가해야 하고 B-Tree 리밸런싱도 해야하고 조인을 매 요청마다 O(N)으로 탐색해서 하는 것 보다 NoSQL인 MongoDB가 단순히 Document만 저장하는게 다 이므로 현재 단순히 장기판 상태를 저장하고 꺼내는 상황에서 효율적인 판단이라고 생각했습니다.

Document 수정 시에도 전체 문서를 덮어쓰기하는 방식말고 부분 field만 꺼내 update할 수 있는 방법이 존재했습니다. 이 방식은 Document 필드 offset을 통해 전체 문서를 교체하지 않고 특정 필드만 수정할 수 있도록 이진 데이터를 교환하는 방식으로 실행할 수 있었습니다!

RDB는 장기판 정보를 저장하려면 Game 테이블과 Piece 테이블 등을 나누고 외래키로 연결하고 조인해야 합니다. 기물 하나를 움직일 때마다 Piece 등에서 특정 행을 찾은 후 업데이트 하고, 조회시에는 또 다시 여러 행을 Join해서 가져와야 합니다. ACID 원칙에 의한 엄격한 검증 절차는 덤이고요

MongoDB는 BASE 원칙을 따라 RDB보다 유연한 원칙을 따릅니다. 장기판 자체를 하나의 애그리거트(연관된 객체 묶음)으로 보고, 게임 하나 = 문서 하나라는 직관적인 구조 덕분에 코드가 단순해지고, 데이터를 가져올 때 단 한 번의 디스크 I/O로 판 전체 상태를 복원할 수 있습니다.

따라서, NoSQL이 데이터 모델링의 효율성의 이점이 크고 잦은 저장이 필요한 장기 게임에서 속도도 빠르다면 선택하지 않을 이유가 없다는 결론에 도달했습니다.

참고 자료
https://www.youtube.com/watch?v=DrEDCn4X7gQ

마비노기 모바일은 실시간 데이터 처리 혁신을 위해 Amazon MemoryDB를 도입했습니다.