[🚀 사이클2 - 미션 (기물 확장 + DB 적용)] 아티 미션 제출합니다. by ParkJiYeoung8297 · Pull Request #333 · woowacourse/java-janggi

ParkJiYeoung8297 · 2026-04-08T07:45:32Z

사이클 2

2.1단계 - 기물의 확장

궁성 영역에 대한 기능 추가
차와 상의 궁성 구현
점수 계산 및 출력 기능 구현
게임 종료 기능 추가 (왕 잡히면 종료)
상과 포의 규칙 추가
기물별 경로 탐색 기반으로 이동 좌표 계산 구조 변경
궁성에 대한 테스트 추가
보드에 대한 테스트 추가

1)궁성(宮城) 영역의 규칙을 포함

궁성영역인지 판단하는 메서드 isInPalace()을 추가 (Postition.java)
궁성영역에서 대각이동이 가능한 10개의 좌표에 위치하면, 탐색 방향에 대각 방향 추가하는 addPalaceDirection() 추가 (Postition.java)
(단, 기물이 대각 이동 시 궁성을 벗어나지 않는지는 piece 한칸씩 이동하면 postion.isInPalace()를 호출해서 판단)

2)왕이 잡혔을 때 게임을 종료

왕이 죽었는지 판단하는 isKingAlive() 추가 (Board.java)
왕이 죽었다면 state를 ExitGame 상태로 변경 (JanggiGame.java)

3)기물에 대한 점수

기물 점수를 계산하는 calculateScore() 추가 (Board.java)

4)이동 판단 로직 변경

기존에는 사용자에게 좌표를 입력받아서 이동가능한지를 판단했지만,

현재는 사용자가 기물을 선택하면 이동 가능한 좌표를 반환해주는 방식으로 변경되었습니다.

2.2단계 - DB 적용

JDBC DB 연결 설정 추가
게임 초기화
보드 초기 상태를 DB에 저장 및 기존 게임 조회 기능 추가
게임 이동 결과 DB 저장
h2의 서버 닫는 기능 추가

1)DB 선택 이유

H2가 기본으로 내장되어있어서, 설치없이 사용할 수 있는 H2를 선택했습니다.
Application을 실행시키면 "janggiGame.mv.db"파일이 로컬에 저장되고, H2 콘솔 브라우저가 열립니다.
http://localhost:8082/ 를 통해 H2 콘솔 브라우저를 접속할 수 있습니다.

2)DB 저장 시점

사용자가 초나라, 한나라의 마상마상을 선택했을 때 → 보드 정보 초기화하여 DB에 INSERT
한 턴이 끝났을 때 → 바뀐 보드 정보와 다음 순서를 DB에 UPDATE

질문

1. PieceFinder를 통해 Piece에서 Board 정보 조회하기
사이클 2에 들어와서, 각 기물에서 이동 규칙에 따라 한칸씩 이동하며 이동 가능한지 검증하는 방법으로 변경했습니다.
이에 따라, Piece에서 다른 기물에 대한 정보가 필요했는데, Piece가 Board에게 물어보면 순환 참조가 발생해서 불가능했습니다.
그래서 방법을 찾아보니, PieceFinder 인터페이스를 Board에서 구현하고, Piece에게 인터페이스를 파라미터로 넘겨주면, Piece가 인터페이스를 통해 Board의 정보를 가져오는 제어의 역전(IoC)이 된다는 답변을 받았습니다.
Piece에서 PieceFinder로 Board의 정보를 일부만 탐색하는 구조가 괜찮은지 궁금합니다.

(근데 이게 제어의 역전 개념이 맞을까요? Board가 Piece를 제어하는데, 인터페이스를 통해 Piece가 Board 정보를 가져오는 구조여서 제어의 역전이라고 이해했는데, 이게 맞는지도 궁금합니다.)

(Board.java - findAvailablePositions() 참고)

2. Service에서 JanggiGame 도메인 생성
DB를 추가하는 과정에서 기존에 Controller에서 사용하던 JanggiGame 도메인을 전부 int gameId로 수정했습니다.
그리고, Service의 각 메서드마다 gameId로 DB를 조회해서 JanggiGame을 생성하고, 이를 그대로 사용하는 방식으로 사용했습니다.
최대한 기존 코드 변경없이 DB 기능을 붙이고 싶어서, 위와 같은 방법을 사용했는데 이게 적절한 방법인지 궁금합니다.

(Service에서 매번 JanggiGame을 새로 생성하는 것이 맞는지에 대해 의문이 들어서 드리는 질문입니다.
Service에서 장기게임을 한번 생성하고, 이를 controller에 넘기는 방식은 계층의 분리가 혼재될 것 같아서 지양해야할 거 같은데 ,
Service의 메서드마다 JanggiGame을 생성하는 방식이 적절한 걸까요?)

3. DB Connection pool
DB Connection은 트랜잭션 단위로 열고 닫아야한다고 생각을 해서, Service의 메서드에서 매번 connection pool을 열고 닫는 코드가 되었습니다. 그러다보니 코드의 중복이 많아지는 것 같은데, 이를 효율적으로 리팩토링하는 방법이 있을지 궁금합니다.

4. DB 기물 데이터 update 방법
현재는 사용자가 기물을 이동했을 떄, piece_position 테이블에서 해당 게임과 관련된 piece를 모두 삭제하고, 새로 insert하는 방식을 사용하고 있습니다. delete하고 insert하는게 비효율적이라고 느껴지기도 하지만, 작은 규모에서는 해당 piece를 찾아서 update하는 것보다 delete + insert가 간단하고 데이터 정합성을 지키는데 더 나을 거라고 생각이 드는데 이에 대해 어떻게 생각하시는지 궁금합니다.

5. 테스트 코드
기능이 많아지고, DB까지 추가하고 나니까 어느 테스트를 우선 시 해야할까에 대해 고민이 생겼습니다.
저는 현재 도메인 테스트 위주로 작성을 했는데, 도메인 외 계층에서도 DB를 거치는 등의 기능들이 추가되니까
"도메인 테스트 추가보다 차라리 service에서 한꺼번에 테스트하는 것이 나을까?"라는 생각이 들었습니다.
테스트해야할 기능이 많을 때, 우선순위로 두시는 테스트가 있는지 궁금합니다.

6. 각 기물 리팩토링
각 기물 클래스에서 비슷한 로직이 있는거 같은데 이 부분을 리팩토링할 방법을 고민하고 있습니다.
혹시 추천해주실 방법이 있을지 조언을 구하고 싶습니다.

- 브라우저 서버 여는 메서드 추가 - 데이터 초기 로드와 DB connection 분리

younghoondoodoom

안녕하세요 아티~! 이번 사이클2도 잘 부탁드립니다 🙌

사이클2도 잘 구현해주셨군요~! 다만, 요구사항을 충족하지 못한 부분과 고민이 필요한 부분이 보여서 코멘트 남겨놨으니 반영 부탁드립니다!

다음은 질문에 대한 답변입니다.

PieceFinder를 통해 Piece에서 Board 정보 조회하기

리뷰 conversation에서 대화 나눠보시죠!

Service에서 JanggiGame 도메인 생성

리뷰 conversation에서 대화 나눠보시죠!

DB Connection pool

리뷰 conversation에서 대화 나눠보시죠!

DB 기물 데이터 update 방법

만약 기물을 이동할때마다 update를 하는게 아닌 게임이 끝났을때 마지막 상태에 대해서 db update를 하는 구조였다면 delete -> insert하는게 더 효율적일 수 있을거 같아요. 하지만 지금은 기물을 이동할때마다 위치를 update하는 구조다보니 모든 기물을 삭제하고 다시 insert를 하는게 쿼리도 훨씬 많이 나가고 수정 비용이 더 많을 것 같네여!

테스트 코드

기능이 많아지다보면 자연스럽게 단위 테스트 코드에 대한 부담이 있는걸 사실입니다. 다만, 모든 단위에 대해서 테스트를 작성하는게 어플리케이션의 안정성을 높히는 것도 맞습니다. 지금은 프로덕션을 구현하는 훈련도 하지만 테스트 작성에 대한 훈련도 하는 미션입니다. 모든 단위에 대해서 테스트를 작성하시는걸 추천드려요. 지금 테스트 코드가 많이 부족해보입니다!

각 기물 리팩토링

추상 클래스나 util성 메소드를 고려해보세요~!

younghoondoodoom · 2026-04-10T02:53:14Z

src/main/java/controller/JanggiController.java

-            outputView.printChangeTurnMessage(janggiGame.getCountry().getName());
-            playTurn(janggiGame, board);
-            isGameContinue= isGameContinue();
+    private static void checkRetryLimit(int retry) {


이 메소드는 안에서만 내부 메소드인데 static일 이유가 없을거 같아요. 그리고 메소드 순서 정리도 부탁드립니다!

넵 static 제거하고, 순서 정리하겠습니다!
혹시 두둠은 어떤 기준으로 메소드 순서를 정리하시는지 궁금합니다!

younghoondoodoom · 2026-04-10T03:00:13Z

src/main/java/controller/JanggiController.java

+            int choose = inputView.chooseGameStartNewOrAgain();
+            if (choose == 2) {
+                int num = inputView.requestGameId();
+                janggiService.validateExistGame(choose);


db에서 장기 게임이 존재하는지 체크하는김에 장기 게임을 가져오는게 디비 쿼리 효율 상 좋을것 같아요

num이 아니라 choose를 넘기고 있는데요?

사용자에게 game_id를 입력받고 이 id가 있는지만 체크하면, 사용자가 입력한 값을 그대로 사용할 수 있습니다. Controller에서는 janggiGame 도메인을 사용하지 않고, 모두 game_id로 사용하도록 분리해두었기 때문에 검증만 수행했습니다!

num을 넘겨야하는데 잘못 했네요.😅 num으로 수정했습니다.

src/main/java/domain/pieces/Sa.java

src/main/java/repository/JanggiGameRepository.java

younghoondoodoom · 2026-04-10T03:10:32Z

src/test/java/testUtil/BoardTestUtil.java

        );
    }
+
+//    public static Board defaultBoard() {


주석처리 하는 대신 불필요하면 삭제 부탁드립니다

younghoondoodoom · 2026-04-10T03:16:59Z

src/main/java/domain/pieces/Po.java

+        for (Direction direction : directions) {
+            List<Piece> pieces = new ArrayList<>();
+            int i = Position.MAX_ROW;
+            Position now = start;
+            while (i-- > 0) {
+                Optional<Position> position = move(now, direction);
+                if (position.isEmpty()) {
+                    break;
+                }
+                now = position.get();
+                if (Direction.getDiagonalDirections().contains(direction) && (!now.isInPalace())){
+                    break;
+                }
+                Piece endPiece = finder.find(position.get());
+                if (isNotPo(endPiece) && isDifferentCountry(endPiece.getCountry()) && hasNotPoAmongPath(pieces) && hasOnePieceAmongPath(pieces)) {
+                    availableRoute.add(position.get());
+                }
+                pieces.add(endPiece);
+            }


이 부분도 10줄 유지, depth 유지 1로 수정 부탁드려요

younghoondoodoom · 2026-04-10T03:22:05Z

src/main/java/service/JanggiService.java

-    public BoardDto buildBoardDto(Board board) {
+    public BoardDto buildBoardDto(int gameId) {
+        Connection conn = ConnectionManager.getConnection();
+        JanggiGameRepository janggiGameRepository = new JanggiGameRepository(conn);


JanggiGameRepository를 메소드 내에서 생성하는 이유가 뭔가요?

younghoondoodoom · 2026-04-10T03:23:11Z

src/main/java/service/JanggiService.java

+        Connection conn = ConnectionManager.getConnection();
+        JanggiGameRepository janggiGameRepository = new JanggiGameRepository(conn);
+        JanggiGame janggiGame = janggiGameRepository.findByGameId(gameId);
+        ConnectionManager.closeConnection(conn);


db connection에 대한 관리는 모두 service에서 하고있네요. 왜 이런 결정을 하셨는지 설명 부탁드려요!

younghoondoodoom · 2026-04-10T03:34:09Z

src/main/java/domain/Board.java

+    public List<Position> findAvailablePositions(Position start) {
        Piece startPiece = board.getOrDefault(start, None.INSTANCE);
-        Piece endPiece = board.getOrDefault(end, None.INSTANCE);
+        PieceFinder finder = new PieceFinder() {
+            @Override
+            public Piece find(Position position) {
+                return board.getOrDefault(position, None.INSTANCE);
+            }
+        };
+        return startPiece.getAvailableRoute(start,finder);
+    }


PieceFinder를 통해 Piece에서 Board 정보 조회하기

Piece에서 Board를 호출하면 의존성 방향이 깨지기 때문에 PieceFinder를 사용하셨군요. PieceFinder를 통해서 board에 대한 직접 의존을 끊었으니 좋은 방향이라고 생각합니다~!
하지만 굳이 PieceFinder을 만들 필요가 있었나 싶은 생각은 있습니다. 그냥 getAvailableRoute에 현재 기물위치를 board에서 복사해서 파라미터로 전달했으면 간단하게 끝나는 일이 아닌가 싶어요!
그리고 이 경우는 ioc는 아니고, 인터페이스를 통해 기물 위치를 조회한거입니다. ioc에 대해서는 좀 더 공부하시는거 추천드립니다!

younghoondoodoom · 2026-04-10T03:40:15Z

src/main/java/controller/JanggiController.java

    }

+    public void run() {
+        int gameId = initOrGetGame();


Service에서 JanggiGame 도메인 생성

controller에서 JanggiGame 객체에 직접 의존하지 않기위해 id를 통해 통신하는군요! 하지만 확실히 이 문제를 피하기 위해서 service마다 id를 전달해주고 service에서 JanggiGame을 찾아서 쓰는게 비효율적입니다. 특히 db 쿼리가 많이 나가요.
controller와 service가 id를 통해 통신하는건 올바른 방향이라고 생각합니다. controller가 janggiGame에 의존하고 있으면 도메인 캡슐화가 깨지고 영향범위가 늘어나기 때문입니다.
이대로 유지하면서 db 쿼리를 덜 나가게 하기위한 방법을 고민해보세요!

ParkJiYeoung8297 added 25 commits April 3, 2026 01:50

feat: 방향 도메인 추가 및 이동 규칙에 의한 모든 좌표 반환

f053104

test: 이동 규칙에 의한 기물별 테스트 추가(차,장,졸,마)

319019b

chore: 안쓰는 메서드 삭제

8ee68de

refactor: 탐색 방향 전환을 기물에서 보드로 이동하는 리팩토링 (for문을 보드로 추출)

757dc3a

test: 보드와 기물 리팩토링으로 인한 테스트 수정

c1b0872

feat: 상 대각 이동 기능 구현 및 테스트 추가

507c426

feat: 왕 죽으면 게임 종료 기능 구현

015817c

feat: 점수 계산 및 출력 기능 구현

f5fe45a

feat: 게임 승자 계산 및 출력 구현

05b818b

feat: 이동 가능한 좌표 입출력 구현

374fc63

refactor: 기물별 경로 탐색 기반으로 이동 좌표 계산 구조 변경

a304623

chore: 안쓰는 메서드 삭제

b7884ad

fix: 포 이동 검증 추가 구현

0e07374

feat: 궁성 영역에 대한 기능 추가

79553f1

chore: 안쓰는 메서드 삭제

4150b2a

feat: JDBC DB 연결 설정 추가

15ddbfd

feat: db 초기화 기능 구현

6903857

fix: H2 브라우저 서버 여러번 여는 문제 해결 (오류 by포트 충돌)

ef5e9cd

- 브라우저 서버 여는 메서드 추가 - 데이터 초기 로드와 DB connection 분리

feat: 보드 초기 상태 DB 저장 및 기존 게임 불러오기 기능 추가

ddc1b57

feat: 게임 이동 결과 DB 저장

71fb1e7

feat: h2의 서버 닫는 기능 추가

b501182

refactor: 메서드 중복 코드 제거 및 분리 리팩토링

d132f1d

test: 졸 이동 테스트 추가

5cf7096

docs: Readme update

1e90fa6

docs: Readme update

d090a69

younghoondoodoom requested changes Apr 10, 2026

View reviewed changes

Conversation

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

Uh oh!

사이클 2

2.1단계 - 기물의 확장

1)궁성(宮城) 영역의 규칙을 포함

2)왕이 잡혔을 때 게임을 종료

3)기물에 대한 점수

4)이동 판단 로직 변경

2.2단계 - DB 적용

1)DB 선택 이유

2)DB 저장 시점

질문

Uh oh!

younghoondoodoom 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

Uh oh!

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ParkJiYeoung8297 commented Apr 8, 2026 •

edited

Loading