[🚀 사이클2 - 미션 (기물 확장 + DB 적용)] 레서 미션 제출합니다. by win9-tech · Pull Request #327 · woowacourse/java-janggi

win9-tech · 2026-04-08T06:31:53Z

체크 리스트

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

안녕하세요 주디 🦊
항상 꼼꼼한 리뷰 감사드립니다. 이번 사이클 2에서도 잘 부탁드려요!

DB 설정은 README 하단에 있습니다~!

1. DB 선택

장기 미션에서는 MongoDB(NoSQL)를 선택했습니다.

이유는 장기판의 특성입니다. 저장의 단위가 개별 기물이 아니라 장기판 전체 상태이기 때문에, 이를 하나의 문서로 표현하는 것이 자연스러웠습니다. 만약 RDS를 사용해 Piece를 정규화하면 빈칸을 포함하여 게임당 90개의 row가 필요하고, 판 상태를 불러올 때마다 JOIN이 발생하여 불필요한 쿼리 비용이 생깁니다.

또한 기물 종류가 추가되거나 변경될 때 별도의 스키마 마이그레이션이 없다는 점, 여러 컬렉션에 걸친 작업이 없어 트랜잭션도 필요하지 않다는 점에서 MongoDB가 적합하다고 판단했습니다.

단점도 생각해봤는데, "포가 3개 이상 남은 게임 조회"나 "기물별 생존율 조회"처럼 내부 필드에 대한 복잡한 쿼리는 어려워집니다. 하지만 콘솔 기반 장기 게임이라는 서비스 범위를 고려했을 때, 이런 쿼리가 필요한 상황은 발생하지 않을 것이라고 판단했습니다.

향후 유저 시스템, 대전 기록, 통계 분석 같은 기능이 추가된다면 그때 가서 RDS로 전환하는 것이 적절하다고 생각합니다!

2. 네이밍 및 도메인 책임 변경

Board → Game

기존 Board 클래스를 Game으로 변경했습니다. DB 저장/조회의 단위가 board 상태뿐만 아니라 id, turn을 포함한 게임 전체였고, 이를 하나의 클래스에서 관리하는 것이 적절하다고 판단했습니다. Board는 기물 배치 상태만을 의미하므로, 게임 전체 상태를 표현하는 Game이 더 적합한 이름이라고 생각했습니다.

Controller → Runner

기존에는 View와 Domain을 연결하는 중개자 역할에 초점을 맞춰 Controller를 선택했습니다. 그러나 Repository가 추가되면서 이 클래스의 책임이 확장되었습니다. 게임 ID 발급, 상태 저장, 복구, 삭제까지 게임의 전체 생명주기를 관리하게 되었고, 연결보다는 주도의 특성을 띄고 있다고 생각하여 네이밍을 수정했습니다.

3. 도메인 로직 설계

이번 미션을 진행하며 기물 이동 경로나 궁성 영역과 같은 복잡한 도메인 로직을 설계하는 과정이 머릿속에 잘 그려지지 않아 꽤 큰 어려움을 겪었습니다.

결국 한계를 느껴 크루원들과 의견을 나누고, 다른 코드들을 참고하거나 AI의 조언을 받아가며 겨우 구현을 완료할 수 있었습니다. 구현은 했지만, "처음부터 이 설계를 스스로 떠올릴 수 있었을까?" 하는 아쉬움과 스스로의 힘으로 해낸 게 아니다 보니, 성장하긴 한 걸까? 같은 고민이 남습니다.

이런 설계 역량은 결국 절대적인 경험치가 쌓여야만 자연스럽게 늘어나는 영역인지 궁금합니다 🥲

- Turn을 Game 내부로 이동 - ConsoleView에서 Position 직접 반환 - 컨트롤러 작업 단위로 메서드 분리

- public 메서드 정렬 - OutputView 중복 코드 추출

win9-tech · 2026-04-08T09:48:31Z

src/main/java/view/ConsoleView.java

@@ -0,0 +1,70 @@
+package view;


Runner의 의존성 개수를 관리하기 위해 InputView와 OutputView를 하나로 묶은 ConsoleView를 도입했습니다. 현재 구조는 Runner의 의존성을 단순화하고, View 관련 변경 사항을 ConsoleView 한 곳으로 응집할 수 있다는 장점이 있다고 생각하는데요.

여기서 한 가지 고민이 생겼습니다.

ConsoleView 의존 (현재): 의존성 개수가 줄어 Runner가 깔끔해지지만, 단순히 메서드를 전달만 하는 클래스가 생기는 것 아닌가 하는 우려가 있습니다.

Input/OutputView 직접 의존: 클래스 개수는 줄어들지만, Runner가 View의 구체적인 책임(입력과 출력) 두 가지를 모두 알게 됩니다.

주디는 단순히 의존성 개수를 줄이기 위해 추상화 계층(Facade)을 두는 것에 대해 어떻게 생각하시나요? 혹은 이런 상황에서 어떤 방식을 더 선호하시는지 궁금합니다!

저는 Input/OutputView가 하는 역할이 확실하고, 현재 구조는 ConsoleView에 변경이 있으면(다른 역할이 생겨 메서드명을 변경하는 경우) 어차피 모든 곳에서 변경이 일어날 것 같아요
그래서 Input/OutputView 직접 의존을 더 선호합니다!

의견 주셔서 감사합니다! 저도 직접 의존 방식을 더 선호하지만, 이번에는 '인스턴스 변수 3개 이하'라는 제약 사항을 지키기 위해 현재 구조를 유지해보겠습니다 ㅜㅜ!!

win9-tech · 2026-04-08T10:01:00Z

src/main/java/domain/Palace.java

+
+public class Palace {
+
+    private static final Palace INSTANCE = new Palace();


궁성 좌표와 이동 방향은 불변 데이터이고, 애플리케이션 전체에서 하나만 존재하면 되기 때문에 싱글톤으로 구현했습니다.

싱글톤이 테스트를 어렵게 만든다는 의견이 있는데, 현재 코드에서는 다음 이유로 문제가 되지 않는다고 판단했습니다.

Palace는 불변 데이터

기물 테스트 시 실제 궁성 좌표로 테스트하더라도 상태가 변경되지 않는다.

혹시 싱글톤으로 인해 테스트가 어려워지는 케이스가 있을까요? 이에 대해 어떻게 생각하시나요??

레서가 말씀주신대로 불변 데이터 싱글톤은 일반적인 싱글톤 테스트 문제에서 자유로운 게 맞아요!
테스트가 어려운 케이스는 상태가 변경되는 경우인데, 현재는 명시적으로 Palace 상태를 변경하는게 없네요!

win9-tech · 2026-04-08T10:18:54Z

src/main/java/repository/MongoDBRepository.java

+            MongoCollection<Document> collection = getCollection(client, "boards");
+            Long id = Long.parseLong(gameId);
+            Document document = collection.find(Filters.eq("_id", id)).first();
+            return Optional.ofNullable(parseGameStatus(id, document));


Optional과 Exception 중 고민이 있어 질문드립니다.

"정상적으로 결과가 없을 수 있는 경우엔 Optional, 예외적인 오류 상황엔 Exception"이라는 글을 보고 Optional을 선택했는데, 존재하지 않는 게임을 불러오는 상황은 오히려 예외에 해당하는 것 아닌가 하는 생각도 들어서 확신이 서지 않습니다.

또한 Optional이 null 가능성을 명시적으로 드러낸다는 장점이 있다고 하지만, Exception으로도 "이 상황은 발생하면 안 된다"는 의도를 충분히 드러낼 수 있지 않나 하는 의문도 있습니다.

이런 상황에서 둘의 기준을 어떤 식으로 잡으시는지 궁금합니다!

게임이 없으면 NotFoundException을 내는 것도 일반적인 상황일 것 같아요!
전체적으로 의도한 예외가 발생하면 -> 에러메세지 -> 이전 입력을 재시도하는 구조로 잡으신 것 같아서 일단 현재 구조가 통일성이 있네요!
정답은 아니지만 저는 게임 흐름을 예외로 가져가진 않아서, 이런 구조가 아닌 Optional을 쓸 것 같고용~ Optional와 Exception은 조회한 객체가 없는게 정상적인 상황이라면 Optional을 쓰고 없는게 문제라면 Exception을 씁니다!

jurlring

레서 안녕하세요!
질문 주신 부분에 대한 답변과 코멘트 몇가지 달아두었습니다.
시간 괜찮으실 때 확인해주세요 :)

jurlring · 2026-04-08T14:24:05Z

src/main/java/JanggiRunner.java

+
+    private void playGame(Game game) {
+        boolean isRunning = true;
+        gameRepository.saveBoard(game.getId(), game.getTurn(), game.getBoard());


gameRepository를 컬렉션 별로 나누면 어떨까요?
gameRepository인데 saveBoard를 하는 부분이 어색하고 파라미터로 각 상태를 모두 꺼내지말고 game을 넘기면 안되나요?
game의 상태가 늘어날 경우 이 부분도 같이 수정이 필요할거에요 😢

1. gameRepository를 컬렉션 별로 나누면 어떨까요?

현재 구조에서는 (Id, Turn)과 Board가 항상 함께 조회/저장되고, MongoDB를 사용하고 있다는 점, MongoDB는 document 단위 atomicity를 보장하고 JOIN이 없는 구조라, 컬렉션을 분리할 경우 조회/저장 시 오히려 비용이 증가한다는 점에 기반하여
하나의 document로 관리하는 것이 더 적합하다고 판단했습니다.

만약 강하게 결합되어있는 게임의 메타데이터인 (Id, Turn)과 <-> 도메인 데이터 board를 엄격히 정규화하고 별도의 repository를 통해 분리하여 저장해야하는 상황이었다면 RDS를 사용할 것같은데 어떻게 생각하시나요??

2. gameRepository인데 saveBoard를 하는 부분이 어색하고 파라미터로 각 상태를 모두 꺼내지말고 game을 넘기면 안되나요?

말씀주신 부분 생각해보니 저장하는 대상은 Game이고 Game의 Id, Turn, Board 정보를 저장하고있는데 saveBoard 네이밍은 어색한거같네요 saveGame으로 바꿔보았습니다!

3. 파라미터로 각 상태를 모두 꺼내지말고 game을 넘기면 안되나요? game의 상태가 늘어날 경우 이 부분도 같이 수정이 필요할거에요 😢

game 객체를 그대로 넘기면 repository 내부에서도 결국 필요한 값들을 꺼내서 사용한다는 측면에서 "꺼낸다는 행위"는 동일하지만
Runner에 있으면 Runner와 Repository Interface를 변경해야 하는 반면, Repository에 있으면 Repository만 바꾸면 되니까 Runner에서 꺼내는 것보다 Repository에서 꺼내는 게 변경 범위의 최소화 관점에서 적절하다고 생각하시는 걸까요?

제가 말한 건 document 구조 분리가 아니라, gameRepository와 gameRepository 의 구현제체인 MongoDBRepository 클래스 안에 boards 컬렉션 관련 로직과 counters 컬렉션 관련 로직이 함께 있는데, 이걸 BoardRepository와 CounterRepository처럼 클래스 레벨로 나누는 게 어떻냐는 의미였어요. MongoDBRepository가 가진 책임이 너무 크다고 느꼈습니다.

👍

네 수정의 최소화 측면에서 말씀드렸어요 :)

jurlring · 2026-04-08T14:25:47Z

src/main/java/domain/piece/Soldier.java

 public class Soldier extends Piece {

-    private final List<List<Direction>> paths;
+    private final List<List<Direction>> PATHS;


상수가 아닌데 대문자로 쓰신 이유가 있나요~?

Soldier는 다른 기물들과 다르게 진영에 따라 paths가 달라지다 보니 인스턴스 변수로 관리해야 하는데, 순간적으로 상수라고 착각해서 대문자로 변경했습니다. 😂 컨벤션에 맞게 수정했습니다. 꼼꼼한 확인 감사합니다!

jurlring · 2026-04-08T14:29:35Z

src/main/java/domain/ScoreStatus.java

+public class ScoreStatus {
+
+    private double choScore = 0;
+    private double hanScore = 1.5;
+
+    public void reflect(Piece piece) {
+        if (piece.getSide() == Side.CHO) {
+            choScore += piece.getScore();
+            return;
+        }
+        hanScore += piece.getScore();
+    }


getChoScore(), getHanScore() getter가 있고, 필드도 double choScore, double hanScore로 가변 상태예요.
요구사항에 게터/세터를 쓰지 않는다 가 있는데, 현재 ScoreStatus가 getter를 외부에 공개하고 있네요..!
또한 reflect()로 상태가 변경되는 가변 객체인데, 점수 계산 결과를 불변으로 만들면 어떨까요?

리뷰 감사합니다! 말씀하신 대로 가변 상태를 관리하는 게 위험해 보여서 아예 불변 객체로 구조를 바꿨습니다. 😊

우선 reflect() 메서드 대신 팩토리 메서드를 써서 생성할 때 계산을 끝내도록 했습니다. 또한 Getter를 지우고 winner()처럼 결과를 바로 반환하는 행위 기반 메서드들을 추가해봤습니다!

jurlring · 2026-04-08T14:30:37Z

src/main/java/JanggiRunner.java

+        while (true) {
+            try {
+                return selectGame();
+            } catch (IllegalArgumentException e) {
+                consoleView.printErrorMessage(e.getMessage());
+            }
+        }


요 클래스에서 while(true) + try/catch 패턴이 동일하게 반복되는 것으로 보이는데요~
중복을 없앨 방법은 없을까요?

readOption(), readSourcePosition(), readTargetPosition() 등에서 동일한 패턴이 6번 반복되고 있는 걸 확인했습니다.

패턴이 반복된다고 생각은 했지만, 제거할 생각은 못 했는데요. 찾아보니 람다로 해결하는 방법이 있었네요! 감사합니다!!

jurlring · 2026-04-08T14:42:37Z

src/main/java/repository/MongoDBRepository.java

+    private final MongoClient client;
+
+    public MongoDBRepository() {
+        this.client = MongoClients.create(URI);


커넥션은 언제 닫나요?

설계 당시에는 해당 미션이 단일 사용자 환경이고, 로컬 DB를 사용하여 프로그램 종료 시 OS가 리소스를 회수한다는 점, 그리고 웹 서버로의 확장 계획이 없다는 점을 고려하여 별도의 close 코드를 작성하지 않았습니다.

하지만 추가로 검토해 본 결과, CLI 환경에서는 문제가 없더라도 테스트 코드 실행 시 Repository 객체가 반복 생성되며 커넥션 누수가 발생할 수 있다는 점을 깨달았습니다.

무엇보다도, 리소스 해제를 명시하는 것이 코드의 의도를 명확히 전달하는 좋은 습관이라 판단되어
프로그램 정상 종료, 예외 종료 시 커넥션을 닫는 로직을 추가했는데,

혹시 제가 놓친 부분이 있거나 다른 의도로 질문 주신건지 궁금합니다 :)

jurlring · 2026-04-08T15:02:10Z

src/main/java/view/ConsoleView.java

@@ -0,0 +1,70 @@
+package view;


저는 Input/OutputView가 하는 역할이 확실하고, 현재 구조는 ConsoleView에 변경이 있으면(다른 역할이 생겨 메서드명을 변경하는 경우) 어차피 모든 곳에서 변경이 일어날 것 같아요
그래서 Input/OutputView 직접 의존을 더 선호합니다!

jurlring · 2026-04-08T15:02:24Z

src/main/java/repository/MongoDBRepository.java

+            MongoCollection<Document> collection = getCollection(client, "boards");
+            Long id = Long.parseLong(gameId);
+            Document document = collection.find(Filters.eq("_id", id)).first();
+            return Optional.ofNullable(parseGameStatus(id, document));


게임이 없으면 NotFoundException을 내는 것도 일반적인 상황일 것 같아요!
전체적으로 의도한 예외가 발생하면 -> 에러메세지 -> 이전 입력을 재시도하는 구조로 잡으신 것 같아서 일단 현재 구조가 통일성이 있네요!
정답은 아니지만 저는 게임 흐름을 예외로 가져가진 않아서, 이런 구조가 아닌 Optional을 쓸 것 같고용~ Optional와 Exception은 조회한 객체가 없는게 정상적인 상황이라면 Optional을 쓰고 없는게 문제라면 Exception을 씁니다!

jurlring · 2026-04-08T15:04:02Z

src/test/java/GameTest.java

@@ -280,28 +296,30 @@ class GuardMove {
            @DisplayName("사가 한 칸 이동한다.")


대각선으로 가는 케이스는 없는 것 같아요

차,포,사, 쫄, 병 대각선 이동 테스트케이스 추가했습니다!

jurlring · 2026-04-08T15:04:34Z

src/main/java/JanggiRunner.java

+    }
+
+    private boolean handleMoveResult(Game game, Turn turn, Piece captured) {
+        if (captured.isKing()) {


요 케이스는 테스트가 있나요~?

handleMoveResult()는 private 메서드이고, consoleView, gameRepository와 밀접하게 결합되어 있어 직접 테스트가 어렵다고 생각했습니다

그래서 Game 안으로 넣을까도 생각해봤지만 ConsoleView, GameRepository에 의존해야한다는 점, 흐름제어 또한 담당하는 Runner의 특성상 현 위치에 배치하는게 올바르다고 생각했는데요, 이에 대해서 어떻게 생각하시는지 궁금합니다!

이 고민 자체가 사실 설계 신호일 수 있어요!
테스트하기 어렵다는 것은 종종 해당 로직이 외부 의존성과 너무 강하게 결합되어 있다는 의미이기도 하거든요.
captured.isKing()이면 게임 종료라는 판단 자체는 사실 Game이 알고 있어도 되는 것 아닐까요?
Game.isOver()나 Game.isCapturedKing(captured) 형태로 판단은 Game에, 후속 처리(DB 삭제, 출력)는 Runner에 두는 구조를 생각해보셔도 좋을 것 같아요 ~

jurlring · 2026-04-08T15:11:18Z

src/main/java/domain/Palace.java

+
+public class Palace {
+
+    private static final Palace INSTANCE = new Palace();


레서가 말씀주신대로 불변 데이터 싱글톤은 일반적인 싱글톤 테스트 문제에서 자유로운 게 맞아요!
테스트가 어려운 케이스는 상태가 변경되는 경우인데, 현재는 명시적으로 Palace 상태를 변경하는게 없네요!

win9-tech · 2026-04-10T12:45:39Z

src/main/java/domain/Position.java

-    private static final String INVALID_POSITION_RANGE = "x 좌표는 1~9, y 좌표는 1~10, 사이여야 합니다.";
-
-    private static final Map<Integer, Position> CACHE = new HashMap<>();
+    private static final Position[][] CACHE = new Position[MAX_X + 1][MAX_Y + 1];


추가로 저번 미션 마지막에 남겨주셨던 키값 생성방식 x * 100 + y의 확장성, 안전함에 대한 판단, 의도전달에 대한 문제를 고민해봤습니다.

고민 결과 2차원 배열을 사용하기로 결정했습니다. 장점은 아래와 같습니다.

2차원 좌표 -> 2차원 배열로 의도가 명확하다

배열 크기가 MAX_X + 1, MAX_Y + 1로 선언되어 범위가 명시적으로 드러난다

키 계산이 없기떄문에 추론이 불필요하다

고민 과정에서 인덱스 0이 낭비된다는 점을 고민하긴 했지만, 사소한 부분이라 생각하여 이대로 진행했습니다!!

jurlring

레서 안녕하세요~
질문에 대한 답변과 코멘트 몇가지 달아두었습니다~!
시간 괜찮으실 때 확인해주세요 :)

jurlring · 2026-04-11T13:39:02Z

src/main/java/repository/GameStatus.java

+
+import java.util.Map;
+
+public class GameStatus {


요구사항에 getter/setter 사용 금지가 있는데, GameStatus 관련해서는 어떻게 생각하시나요? GameStatus가 직접 Game을 만들어 반환하는 방식은 어떨까요 ~?

jurlring · 2026-04-11T13:45:21Z

src/main/java/JanggiRunner.java

+        return move(game, turn);
+    }
+
+    private boolean move(Game game, Turn turn) {


이동 실패 후 같은 턴에서 다시 이동을 시도하게 하고 싶다면 어떻게 달라져야 할까요 ~?

jurlring · 2026-04-11T13:48:43Z

src/main/java/constant/BoardConstant.java

@@ -0,0 +1,9 @@
+package constant;
+
+public class BoardConstant {


상수만 담는 클래스인데 private 생성자가 없네요!
외부에서 new BoardConstant()가 가능한 상태인데, 이런 유틸성 상수 클래스는 인스턴스화를 막으면 어때요?

jurlring · 2026-04-11T13:49:48Z

src/main/java/JanggiRunner.java

+        return retryOnError(consoleView::readOption);
+    }
+
+    private void playGame(Game game) {


새 게임을 생성할 때는 createNewGame()에서 보드 상태를 출력하지만, 저장은 playGame()에서 이루어지고 있네요.
새 게임 생성 → 바로 저장이 아니라 게임 루프 진입 후 저장되는 흐름이 자연스러운지, 아니면 createNewGame() 안에서 저장하는 편이 더 응집도가 높은지에 대해서 어떻게 생각하시나요?

jurlring · 2026-04-11T13:50:29Z

src/main/java/JanggiRunner.java

+    }
+
+    private boolean handleMoveResult(Game game, Turn turn, Piece captured) {
+        if (captured.isKing()) {


이 고민 자체가 사실 설계 신호일 수 있어요!
테스트하기 어렵다는 것은 종종 해당 로직이 외부 의존성과 너무 강하게 결합되어 있다는 의미이기도 하거든요.
captured.isKing()이면 게임 종료라는 판단 자체는 사실 Game이 알고 있어도 되는 것 아닐까요?
Game.isOver()나 Game.isCapturedKing(captured) 형태로 판단은 Game에, 후속 처리(DB 삭제, 출력)는 Runner에 두는 구조를 생각해보셔도 좋을 것 같아요 ~

jurlring · 2026-04-11T13:50:39Z

src/main/java/JanggiRunner.java

+
+    private void playGame(Game game) {
+        boolean isRunning = true;
+        gameRepository.saveBoard(game.getId(), game.getTurn(), game.getBoard());


제가 말한 건 document 구조 분리가 아니라, gameRepository와 gameRepository 의 구현제체인 MongoDBRepository 클래스 안에 boards 컬렉션 관련 로직과 counters 컬렉션 관련 로직이 함께 있는데, 이걸 BoardRepository와 CounterRepository처럼 클래스 레벨로 나누는 게 어떻냐는 의미였어요. MongoDBRepository가 가진 책임이 너무 크다고 느꼈습니다.

👍

네 수정의 최소화 측면에서 말씀드렸어요 :)

jurlring · 2026-04-11T14:10:37Z

src/main/java/repository/MongoDBRepository.java

+
+public class MongoDBRepository implements GameRepository {
+
+    private static final String URI = "mongodb://localhost:27017";


NoSQL 종류별로 직접 조사하고 비교해서 선택하신 과정이 인상 깊었어요! 👍
다만 MongoDB도 트랜잭션을 지원하고 있어서 ACID 유무가 선택의 근거가 되긴 어려울 것 같아요! https://www.mongodb.com/ko-kr/docs/manual/core/transactions/
장기판 전체 상태를 하나의 도큐먼트로 저장하는 구조 자체는 MongoDB랑 잘 맞아서 선택 자체는 자연스럽다고 생각해요 ~

win9-tech added 30 commits April 3, 2026 13:21

refactor: 에러 메시지 상수 클래스 분리

be79a1c

refactor: 보드 범위 상수 클래스 분리

72a6ccd

refactor: 기물명 한글 -> 한자 변경

7fbe277

refactor: Piece 테스트 API 리팩토링

ff3a8a8

feat: MovementStrategy에 경로 조회 기능 추가

7374ace

feat: Piece에 이동 규칙 검증 메서드 추가

ae193ef

feat: Board 경로 필터링 및 movePiece 시그니처 변경

16d3e12

feat: 이동 가능 위치 노란색으로 표시

9a3258d

refactor: PieceType Elephant 전략 주입 누락 수정

76594f2

test: King, Guard 테스트 코드 궁성영역 반영

543f23c

refactor: Position, Direction에 유틸 메서드 추가

c7498bc

feat: 궁성 대각선 이동 규칙 구현

1f25960

refactor: 코드 컨벤션 통일

742b791

feat: 왕 캡처 시 게임 종료 로직 구현

6ead671

feat: 기물 점수 계산 기능 구현

e12cdf2

feat: MongoDB 의존성 및 Repository 인터페이스 추가

6d56217

feat: BoardStatus 도메인 객체 추가

292fcbb

feat: Board에 게임 ID 관리 기능 추가

36ec240

feat: MongoDB Repository 구현

6c70a35

feat: 게임 저장/불러오기 기능 연동

7b3638d

refactor: Controller (InputView, OutputView 의존) -> (ConsoleView) 의존으로 변경

1e903bc

refactor: Board -> Game 클래스 네이밍 수정 및 컨트롤러 간소화

9586b9b

- Turn을 Game 내부로 이동 - ConsoleView에서 Position 직접 반환 - 컨트롤러 작업 단위로 메서드 분리

refactor: View 클래스 메서드 정리

15d9e89

- public 메서드 정렬 - OutputView 중복 코드 추출

refactor: Repository 네이밍 변경

c68a67c

refactor: MongoDBRepository 메서드 분리 및 간소화

40f05c9

feat: 점수승, 궁이 잡힌 경우 DB에서 Board 삭제 기능 구현

101e92c

refactor: 결과 출력 문자 수정

e695b17

refactor: readOption 반환타입 int로 변경 및 입력 검증 추가

32eb0bc

refactor: Controller -> Runner로 클래스 네이밍 변경

db0790b

refactor: 패키지 구조 변경

9ca3a53

win9-tech added 2 commits April 8, 2026 18:50

refactor: MongoDBRepository 상수 사용

0600822

refactor: MongoClient 단일 연결 방식으로 변경

05134f7

win9-tech commented Apr 8, 2026

View reviewed changes

feat: 존재하지 않는 게임 ID 입력 시 재선택 기능 추가

399e602

win9-tech commented Apr 8, 2026

View reviewed changes

win9-tech added 2 commits April 8, 2026 19:22

docs: README.md 패키지 구조 변경 및 기능 추가

ad5bafb

docs: README.md MongoDB 설정 추가

ae05064

jurlring requested changes Apr 8, 2026

View reviewed changes

win9-tech added 8 commits April 9, 2026 17:19

refactor: Soldier 고유의 움직임 변수명 PATHS -> path로 수정

ba62c63

refactor: game 저장 메서드 네이밍 변경 및 파라미터 수정

f716660

refactor: 함수형 인터페이스를 통해 중복코드 제거

99a687d

test: Palace 테스트 코드 구현

72fd55f

test: 기물 대각선 테스트 코드 구현

386d856

refactor: ScoreStatus 불변 객체로 리팩토링

fee3526

fix: MongoDBRepository 커넥션 명시적 종료 처리

a46c4a4

refactor: Position 캐시를 2차원 배열로 변경

822c1e3

win9-tech commented Apr 10, 2026

View reviewed changes

jurlring requested changes Apr 11, 2026

View reviewed changes


		public class Palace {

		private static final Palace INSTANCE = new Palace();

		@@ -280,28 +296,30 @@ class GuardMove {
		@DisplayName("사가 한 칸 이동한다.")

		@@ -0,0 +1,9 @@
		package constant;

		public class BoardConstant {


		public class MongoDBRepository implements GameRepository {

		private static final String URI = "mongodb://localhost:27017";

Conversation

win9-tech commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

체크 리스트

1. DB 선택

2. 네이밍 및 도메인 책임 변경

3. 도메인 로직 설계

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jurlring left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

1. gameRepository를 컬렉션 별로 나누면 어떨까요?

2. gameRepository인데 saveBoard를 하는 부분이 어색하고 파라미터로 각 상태를 모두 꺼내지말고 game을 넘기면 안되나요?

3. 파라미터로 각 상태를 모두 꺼내지말고 game을 넘기면 안되나요? game의 상태가 늘어날 경우 이 부분도 같이 수정이 필요할거에요 😢

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jurlring left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

win9-tech commented Apr 8, 2026 •

edited

Loading