[🚀 사이클1 - 미션 (보드 초기화 + 기물 이동)] 루디 미션 제출합니다. by Seonwu-K · Pull Request #256 · woowacourse/java-janggi

Seonwu-K · 2026-03-29T09:43:53Z

체크 리스트

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

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

서문

안녕하세요 제나! 리뷰 요청을 지각해버린 루디입니다 🥲

저는 이번 미션에서 요구사항 충족과 객체지향 원칙, 그리고 최근 학습한 내용을 함께 적용하려고 시도했습니다.

다만 진행 과정에서 설계와 구현 속도가 크게 느려졌고,
중간부터는 우선 동작하는 코드를 만드는 것에 집중한 뒤 리팩토링으로 보완하는 방식으로 방향을 전환했습니다.

이 과정에서 몇 가지 고민이 생겨 의견을 여쭙고 싶습니다.

설계에서 중점적으로 본 부분

1. Board를 단일 상태 저장소처럼 두었습니다

기물의 위치 상태를 Board만 관리하도록 두고, 다른 객체는 현재 판 상태를 기준으로만 협력하도록 설계했습니다.

public class Board {
    private final Map<Position, Piece> pieces;
}

기물 자체가 자신의 위치를 들고 있게 하면 상태 동기화가 어려워질 수 있다고 판단해, 위치 상태는 Board 한 곳에서만 관리하도록 두었습니다.

2. 이동 규칙 정의와 실제 판정은 분리하려고 했습니다

기물별 이동 규칙은 MoveStrategy가 만들고, 실제 이동 가능 여부는 현재 장기판 상태와 함께 판단하도록 구성했습니다.

return piece.makeRoutes(currentPosition).stream()
        .filter(route -> route.endPos().isInsideBoard())
        .filter(route -> piece.canMove(route, getBlockingPieces(route), getDestinationPiece(route)))
        .toList();

이 과정에서 MovePath는 규칙 템플릿, Route는 실제 좌표가 계산된 경로로 역할을 나누었습니다.

3. `Position`은 정적 팩토리와 캐시를 사용했습니다

이전 미션 리뷰에서 단순 가독성과 편의를 위해 적용했던 정적 팩토리 메서드에 대해 리뷰를 받고,
생성자 생성 방식으로 수정했던 경험이 있습니다.

이번에는 해당 블로그를 참고해서 정적 팩토리 메서드의 이점을 체크하고

동일 좌표를 반복해서 만들지 않도록 캐싱을 적용하고, 생성 경로를 제한하기 위해 도입해보았습니다.

private static final Map<Integer, Position> CACHE = createCache();

public static Position of(int row, int column) {
    validateBoardIndex(row, column);
    return CACHE.get(toCacheKey(row, column));
}

리뷰 받고 싶은 부분

1. “구현 우선 → 리팩토링” 방식에 대한 의견

처음부터 아직 익숙하지 않은 원칙(요구사항, TDD, 캡슐화, 객체지향 원칙)을 모두 지키며 구현하려다 보니, 설계와 코드 작성 속도가 매우 느려졌습니다.
사이클1 기간 동안 완성이 불가능 할 것 같다는 판단이 들어 미션 중간부터는 우선 동작하는 코드를 만든 뒤 리팩토링하는 방식으로 전환했습니다.

하지만 코드를 작성하면서 이렇게 기능 구현을 끝내고 나서 리팩토링 포인트를 놓치지 않을 수 있을 지에 대해 계속 불안감을 느꼈습니다. 좋은 코드를 위해, 이상적인 객체지향을 위해 고려해야 할 요소들을 적용해보고 익히는 것을 목표로 미션에 임했으나 현실적인 제출 기간에 맞춰 타협을 하고 '이렇게 하면 안될 것 같은데' 라는 생각이 드는 코드를 계속 작성해야 하는 상황이 불편하게 느껴졌던 것 같아요.

실무에서도 이런 식으로 일부 원칙을 포기하고 구현을 우선하는 상황이 자주 있는지, 있다면 이런 상황에서 어떤 기준으로 판단하고, 이후 어떻게 관리하는지 이 방식이 학습 단계에서도 적절한 접근인지 제나의 의견이 궁금합니다.

2. Board, Piece, MoveStrategy의 책임 분배가 자연스러운지

현재는 아래처럼 역할을 나눴습니다.

Board: 현재 장기판 상태 관리, 실제 이동 반영
Piece: 자신의 이동 전략 보유
MoveStrategy: 이동 가능한 경로 생성, 규칙 판정

다만 이 과정에서 Board가 상태 조회를 많이 제공하게 되었고, 이것이 Tell, Don't Ask나 캡슐화 관점에서 부적절 하다고 판단되었지만 어떻게 개선할 수 있을지 좋은 방식을 떠올리지 못해 현재의 구조로 진행하게 되었습니다.

3. `Board`를 중심으로 상태를 모은 구조가 적절한지

상태를 한 곳에서 관리하면 동기화 문제는 줄어들지만, 다른 객체들이 Board에 많이 질의하는 구조가 됩니다.
이런 방식이 허용 가능한 선택인지, 아니면 메시지 중심으로 더 나은 구조가 가능한지 피드백 부탁드립니다.

4. 정적 팩토리 도입이 타당했는지

특히 Position에서 정적 팩토리와 캐시를 사용한 선택이 적절했는지 궁금합니다.
단순 편의성 수준인지, 생성 제어와 재사용 이점을 실제로 잘 살린 케이스인지 의견 부탁드립니다.

5. 인터페이스 `default` 메서드 활용이 적절했는지

공통 코드를 줄이는 것을 목적으로 코드를 작성하면서, MoveStrategy에서 공통 경로 생성 로직을 default 메서드로 두었습니다.
인터페이스를 적극적으로 도입했던 것은 처음이라 이 방식이 좋은 추상화인지, 아니면 추상 클래스 쪽이 더 적절했는지 기준을 알고 싶습니다.

- 테스트 시나리오 작성 - 기능 구현 리스트 순서 수정

…nStrategy

yenawee · 2026-03-30T21:56:42Z

README.md

+
+
+
+- [ ] [판정] 장군 멍군 구현


사이클 1 기능 구현목록 💯
😄 사이클 2 도 먼저 고려해보신건가요 ?

맞습니다.. 사전학습 및 토론 활동 까지는 사이클1까지만 구현하면 된다고 의식하고 있었는데
페어와 설계를 짜다가 사이클 1,2 구분을 잊고 그냥 '장기'라는 게임 전체의 로직을 고민하면서 설계를 하게 되었습니다 ..

yenawee · 2026-03-30T22:13:59Z

src/main/java/io/InputView.java

+import java.util.Scanner;
+
+public class InputView {
+    private static final String FORMATION_CHOICE_PROMPT = " 상차림 선택 (1. 안상 2. 바깥상 3. 좌상 4. 우상) > ";


마상마상, 상마상마 의 정보도 같이 표시해주면 사용자 입장에서 편리할거 같아요 :)

생각해보니 실제 장기 게임에서도 상차림 명칭보다는 배치 순서를 기준으로 설명을 해준다는 것을 놓쳤네요..! 해당부분 반영해서 수정하겠습니다.

yenawee · 2026-03-30T22:16:27Z

src/main/java/Main.java

@@ -0,0 +1,8 @@
+public class Main {
+
+    public static void main(String[] args) {


장기판 출력이 깨지는 것 확인부탁드려요

해당 코드가 윈도우 화면 기준에서는 정상적으로 출력이 되지만 맥북 환경에서는 다르게 출력이 되는 것 같습니다.
맥북 화면 기준에서 정상적으로 출력될 수 있도록 수정해보겠습니다.

yenawee · 2026-03-30T22:18:45Z

src/main/java/io/InputView.java

+public class InputView {
+    private static final String FORMATION_CHOICE_PROMPT = " 상차림 선택 (1. 안상 2. 바깥상 3. 좌상 4. 우상) > ";
+    private static final String PIECE_CHOICE_PROMPT = " 차례, 선택할 기물 번호 > ";
+    private static final String ROUTE_CHOICE_PROMPT = "이동할 경로 번호 선택 (0은 뒤로가기) > ";


어디로 이동할 수 있는지 나와있어서 게임 진행이 편리하네요 ! 💯

yenawee · 2026-03-30T22:22:47Z

src/main/java/domain/game/TurnManager.java

+public class TurnManager {
+
+    private TeamColor currentTurn;
+    private int moveCount;


사용되는 변수일까요?

해당 변수는 사이클2까지 구현을 가정하고 미리 도입하게 된 코드인데 미션 진행중에는 미쳐 인지하지 못하였습니다.. 리뷰를 받고 확인해보니 당장 쓰지 않는 변수임에도 추후 확장을 위해 도입한 케이스라서 우선 제거해두겠습니다!

yenawee · 2026-03-30T23:02:08Z

src/main/java/domain/board/Position.java

+    }
+
+    public Position next(Direction direction) {
+        final int nextRow = this.row.value() + direction.dRow();


direction 의 값을 꺼내서 더하는 게 아니고 direction 에게 다음 위치를 계산하는 메서드를 만들어 사용해볼까요?

객체로부터 계속 값을 꺼내오는 구조가 되는게 불편했지만 미션 구현을 먼저 목표로 두고 타협을 하다 보니 결국 캡슐화가 깨지도록 코드를 짜게 된 것 같습니다.. 리뷰 반영하여 direction과 사용 방식 수정해두겠습니다 😃

yenawee · 2026-03-30T23:19:45Z

src/main/java/domain/board/Board.java

+        return pieces.entrySet().stream()
+                .filter(entry -> entry.getValue().getTeamColor() == teamColor)
+                .sorted((left, right) -> {
+                    final int rowCompare = Integer.compare(left.getKey().row(), right.getKey().row());


좌표의 대소 비교는 Board가 할 일이 아니라, 좌표를 들고 있는 Position 객체 스스로가 판단해야 할 책임으로 보여요.
Comparable을 구현해볼까요?

포지션이 스스로 자신의 상태에 대해서 책임을 지는게 능동적인 캡슐화가 가능하다는 점에서 맞는 것 같습니다.
Comparable의 경우 사용해본 적이 없어서 어떤 상황에 사용하면 좋을지 공식 문서를 찾아봤는데,

This interface imposes a total ordering on the objects of each class that implements it. This ordering is referred to as the class's natural ordering

해당 설명을 읽고 자연스러운 순서를 가지고 있는 값에 대해 Comparable을 사용하는 것을 권장하는 것으로 이해했습니다.

그런데 현재 Position의 경우 row, column 기준 정렬이 이 타입의 본질적인 natural ordering이라고까지 보기는 조금 어렵다고 생각합니다. 지금 비교 규칙은 보드에서 말을 출력하거나 선택지를 보여주기 위한 맥락에서 사용되고 있어서, Position 자체의 기본 순서라기보다 특정 사용처에 맞는 정렬 규칙에 더 가깝다고 생각했습니다.

그래서 포지션 족에서 별도 비교 메서드를 구현하거나, Comparator를 사용하는 것이 더 적절하다고 판단되는데 제나의 의견이 궁금합니다

yenawee · 2026-03-30T23:24:08Z

docs/images/flowchart.png

사이클 2 에 대한 내용은 사이클 1 미션 완료 후 생각해보는게 좋을거같아요
미리 사이클2에 대비해서 설계를 진행하는 것보다 요구사항이 추가되었을때 얼마나 많이 코드를 리팩터링해야하는지, 설계를 어떻게 고쳐야 하는지 고민하는 점에서 학습하는게 있다고 생각합니다!

다른 리뷰 댓글에도 남겼듯 처음에는 사이클1만 고려하고 있었지만
페어와 설계를 진행하다 보니 범위가 확장되어 사이클2 내용까지 미리 설계하게 되었고,
뒤늦게 사이클2 영역을 앞서 진행하고 있었다는 점을 깨닫게 됐었습니다.

리뷰를 듣고 보니 말씀 주신 부분에 대해서도 의식하면서 학습에 임해야 보다 많은 것을 배울 수 있겠다는 생각이 들었어요. 다음 미션부터는 설계할 때 사이클 내용에 집중하고, 이후 요구사항 변화에 따라 설계를 개선하는 방식으로 진행해보겠습니다.

yenawee · 2026-03-30T23:29:08Z

src/main/java/domain/board/Board.java

+        this.pieces = new HashMap<>(pieces);
+    }
+
+    public List<Piece> getBlockingPieces(Route route) {


private 함수일까요?

getBlockingPieces()는 외부에 노출할 의도가 없는, Board 내부에서 이동 가능 여부를 판단하기 위한 보조 메서드라서, private으로 수정이 필요할 것 같습니다.

yenawee · 2026-03-30T23:29:16Z

src/main/java/domain/board/Board.java

+                .toList();
+    }
+
+    public Optional<Piece> getDestinationPiece(Route route) {


private 함수일까요?

getBlockingPieces()과 마찬가지로 private으로 수정이 필요할 것 같습니다 😅

yenawee · 2026-03-30T23:38:11Z

src/main/java/domain/board/Board.java

+                .orElseThrow(() -> new IllegalArgumentException("보드에 없는 기물입니다."));
+
+        return piece.makeRoutes(currentPosition).stream()
+                .filter(route -> route.endPos().isInsideBoard())


Position 객체 자체가 보드 범위를 벗어나는 값으로는 생성이 불가하네요! isInsideBoard() 는 현재 여기서 무의미한 메서드로 보입니다.

현재 Position은 생성 시점에 이미 보드 범위를 검증하고 있어서, 정상적으로 생성된 객체에 대해 isInsideBoard()를 다시 확인하는 의미가 없는게 맞는 것 같습니다.

처음에는 좌표 유효성 검사를 사용 시점에도 한 번 더 하고자 했었는데, 지금 구조에서는 생성 불변식으로 이미 보장되고 있어서 해당 코드는 수정해두겠습니다.

yenawee · 2026-03-31T00:05:58Z

src/test/java/strategy/move/HorseMoveStrategyTest.java

+    class 차단검사 {
+        @Test
+        public void 마는_장애물이_없으면_지나갈수_있다(){
+            MoveStrategy moveStrategy = new PawnMoveStrategy();


strategy 확인해주세요 (다른 테스트코드들도)

테스트 이름과 실제로 생성한 strategy가 일치하지 않는 부분이 있었네요. 각 테스트가 검증하려는 기물과 사용한 strategy가 맞는지 전체적으로 다시 확인해보겠습니다

yenawee · 2026-03-31T00:06:37Z

src/test/java/strategy/move/MoveStrategyTest.java

+import org.junit.jupiter.api.Test;
+
+public class MoveStrategyTest {
+


default 메서드 테스트 추가해주세요

yenawee

안녕하세요 루디!
장기 미션으로 만나게 되어서 반갑습니다.

Getter 지양 (객체간 책임 분배 재고려)
테스트 코드 오류 확인 및 시나리오 추가

중점으로 피드백 반영 먼저 해주세요 🙂

“구현 우선 → 리팩토링” 방식에 대한 의견

실무에서도 완벽한 설계보다 고객에게 가치를 전달하는 빠른 배포가 중요한 경우가 많다고 생각해요. tech debt 가 필연적으로 생기게 될텐데 이러한 부채들을 해결하는 우선순위는 기능의 비즈니스 데드라인이 얼마나 타이트한지 (얼마나 회사 수익에 영향이 가는지), 요구사항이 얼마나 자주 변하는지 (자주 변하면 완벽하게 설계할 필요 없음) 등이 있을 거 같아요.
이렇게 기능 구현을 끝내고 나서 리팩토링 포인트를 놓치지 않을 수 있을 지에 대해 계속 불안감을 느꼈습니다 -> 테스트 코드가 있으면 이런 부분에 대해 안정감을 느낄 수 있어요. 나중에 내부 구조를 뜯어고칠 때 기존 기능이 깨지지 않음을 증명하기 위해, 핵심 기능에 대한 테스트 코드만큼은 구현 우선 단계에서도 작성해보는 것을 권장합니다.

Board, Piece, MoveStrategy의 책임 분배가 자연스러운지, Board를 중심으로 상태를 모은 구조가 적절한지

현재로는, 책임분배가

Board : 장기판 상태 관리, 실제 이동 반영 + 이동 가능 경로 판별 (과부하🚨)
Piece : 스스로 판단하는 것 없음. teamColor와 moveStrategy를 묶는 용도, MoveStrategy 에 모든 행동 위임
MoveStrategy : 경로 생성과 이동 가능 여부 판단

로 보여요.

전반적으로 게터가 많아진 이유는 Piece는 아무 판단 능력을 갖지 않고 Strategy에 완전히 위임하면서, Board가 Strategy를 위해 데이터를 꺼내주는 중간자가 되어서인 것으로 보여요.
또한 "이동 가능한지 판단"하는 책임이 Board와 MoveStrategy에 걸쳐 있어요. findMovableRoutes에서 Board가 isInsideBoard() 필터링을 하고, canMove 판단은 MoveStrategy가 합니다.

객체들의 책임을 다시 정리해보고 getter 사용을 지양하는 방향으로 리팩터링 진행해봐요! (다른 리뷰 코멘트보다 이 부분에 먼저 집중해주세요!!)

정적 팩토리 도입이 타당했는지

장기판 위치는 90개로 유한하고, 불변이고, 반복 참조된다 — 캐싱의 교과서적인 조건을 모두 만족합니다. 잘 도입하셨다고 생각해요 👍

인터페이스 default 메서드 활용이 적절했는지

상태 없이 행위만 공유하고 있으니 추상클래스보다 인터페이스 default 가 적절한 방식이었다고 생각합니다.

yenawee · 2026-03-31T00:12:27Z

src/test/java/domain/board/BoardTest.java

+    }
+
+    @Nested
+    class 이동 {


예외 케이스 시나리오도 추가해주세요

Seonwu-K added 30 commits March 25, 2026 00:19

docs: write README.md

73ef847

docs : update README.md

3cba931

- 테스트 시나리오 작성 - 기능 구현 리스트 순서 수정

test : create Row test code

3f575b4

test : create Column test code

19be458

feat : create Column and Row feat

81beec7

refactor: modify exception message

8f98db3

refactor: move to domain package

8e9a344

test: 안상차림 전략 구현체 테스트 작성

5863b48

feat : implement InnerFormationStrategy

47ac216

feat: implement outer formation strategy

2225189

feat: implement left formation strategy

5e84a19

feat: implement right formation strategy

3c9ee98

refactor: rename FormationStrategy

3bb207b

feat : add fixed piece's formation setup function for InitialFormatio…

19e5a8b

…nStrategy

test : create Initializer Test Code

28a8271

feat : implement Initailizer and Piece feature

17e78ab

refactor: wrapping FixedPieces and Formation method

18bd9da

refactor: 이니셜라이저 동작 setUpPieces로 수정 및 캡슐화

4c654a0

test: add PieceStorage test code

6482ce8

refactor: 구조 수정으로 인한 PieceStorage 삭제

42ebe3b

test: add TurnManager test code

01759d8

feat: implement TurnManager

93922c6

feat: implement InitalGameState

7d3355b

test: create pawnMoveStrategy test code

1330f25

feat : implement PawnMoveStrategy

af7cfaa

test : create RookMoveStrategy test code

9bd2ff7

feat : implements RookMoveStrategy

9bd2bea

test : implements KingMoveStrategy test code

f9d5234

feat : implements KingMoveStrategy

d3fbf6a

test: create HorseMoveStrategy test code

dd279bd

Seonwu-K added 15 commits March 28, 2026 14:46

refactor: MoveStrategy 경로 생성 책임 분리

04b4635

refactor: 전략 선택 분기 조회 방식으로 변경

c11552d

refactor: Runner 전략 생성 방식 단순화

be63431

docs: gitignore 항목 추가

44f11f1

refactor: null 사용하던 로직을 Optional 적용하여 수정

6d7f63e

docs: 사이클1 미션 기록 내용 수정

a0109b9

refactor: 사용하지 않는 BlockingPieces 제거

b750fcb

refactor: 매직넘버 및 문자열 상수로 정리

a68b090

refactor: 재할당 없는 값에 final 적용

0740d02

fix: Row와 Column 음수 입력 검증 추가

f6b7213

refactor: Position 정적 팩토리 캐싱 추가

bb1b301

refactor: 도메인 패키지 분류

15a6ddd

refactor: 네이밍 수정 및 객체 설명 README 추가

c9ceaae

docs: 다이어그램 사진 수정

e411225

refactor: 네이밍 수정

f793152

yenawee reviewed Mar 30, 2026

View reviewed changes

yenawee reviewed Mar 31, 2026

View reviewed changes

yenawee requested changes Mar 31, 2026

View reviewed changes

yenawee reviewed Mar 31, 2026

View reviewed changes

		@@ -0,0 +1,8 @@
		public class Main {

		public static void main(String[] args) {

		import org.junit.jupiter.api.Test;

		public class MoveStrategyTest {

Conversation

Seonwu-K commented Mar 29, 2026

체크 리스트

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

설계에서 중점적으로 본 부분

1. Board를 단일 상태 저장소처럼 두었습니다

2. 이동 규칙 정의와 실제 판정은 분리하려고 했습니다

3. Position은 정적 팩토리와 캐시를 사용했습니다

리뷰 받고 싶은 부분

1. “구현 우선 → 리팩토링” 방식에 대한 의견

2. Board, Piece, MoveStrategy의 책임 분배가 자연스러운지

3. Board를 중심으로 상태를 모은 구조가 적절한지

4. 정적 팩토리 도입이 타당했는지

5. 인터페이스 default 메서드 활용이 적절했는지

Uh oh!

yenawee Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

yenawee Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Seonwu-K Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

yenawee Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Seonwu-K Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

yenawee Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

yenawee left a comment

Choose a reason for hiding this comment

“구현 우선 → 리팩토링” 방식에 대한 의견

Board, Piece, MoveStrategy의 책임 분배가 자연스러운지, Board를 중심으로 상태를 모은 구조가 적절한지

정적 팩토리 도입이 타당했는지

3. `Position`은 정적 팩토리와 캐시를 사용했습니다

3. `Board`를 중심으로 상태를 모은 구조가 적절한지

5. 인터페이스 `default` 메서드 활용이 적절했는지

yenawee Mar 30, 2026 •

edited

Loading

yenawee Mar 30, 2026 •

edited

Loading

Seonwu-K Apr 2, 2026 •

edited

Loading

yenawee Mar 30, 2026 •

edited

Loading

Seonwu-K Apr 2, 2026 •

edited

Loading

yenawee Mar 30, 2026 •

edited

Loading