[🚀 사이클1 - 미션 (블랙잭 게임 실행)] 이프 미션 제출합니다. by jihwankim128 · Pull Request #1012 · woowacourse/java-blackjack

jihwankim128 · 2026-03-08T07:27:45Z

개요

안녕하세요 제나, 이번에 블랙잭 미션을 수행하게된 이프라고 합니다.

페어프로그래밍을 처음 진행하면서 네비게이터의 도움을 받아, 더 넓은 시야로 프로그래밍에 임할 수 있다는 것을 배웠습니다. 완성도는 낮을 수 있겠지만 step2에서 더 높은 완성도로 리팩토링하기 위해 많은 조언을 받고 싶습니다 😊

아낌없이 조언을 주시면 성장에 큰 도움이 될 것 같아요!

그리고 처음에 TDD라는 요구사항을 못봐서 다시 진행하느라 시간이 조금 늦었습니다!! 기존 커밋에 이어 7a845ba 해당 커밋부터 다시 TDD로 구현했습니다.

체크 리스트

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

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

1. 페어 프로그래밍 과정에서 '속도'와 '합의' 사이의 균형을 어떻게 잡아야 할까요?

페어 프로그래밍을 진행하며 사고 확장 등 학습 효과를 크게 느끼고 있지만, 의사결정 과정에서 발생하는 '속도 저하'를 어떻게 해결해야 할지 고민이 되어 질문드립니다.

상황
페어와 협업할 때 서로의 의견이 일치하지 않는 경우가 종종 발생합니다.
저는 '페어의 방식을 존중하자'는 생각으로 진행했지만, 이 과정에서 제가 생각한 흐름이 깨져 다음 스텝에 대해 설계를 재구성하거나 의견을 조율하는 데 많은 시간(n분+)을 할애하게 됩니다. 결과적으로 개발 속도가 더뎌지고, 다시 흐름을 재설계하는 과정에서 피로감을 느끼기도 합니다.

고민
단순히 제 의견을 설득하거나 강요하는 것이 아니라, 건강하게 합의점을 찾는 과정 자체가 페어 프로그래밍의 핵심이라고 생각합니다. 하지만 이 과정이 너무 길어질 때 어떻게 조율해야 할지 감이 잘 잡히지 않습니다.

질문

실무에서도 페어 프로그래밍을 진행하나요?
- 진행한다면 이렇게 의사결정에서 충돌이 발생하면 어떻게 효율적으로 해결하나요?
아니면 이 '더뎌지는 과정' 자체가 페어 프로그래밍에서 당연히 겪어야 할 학습의 일부일까요? 멘토님의 경험담이 궁금합니다.

2. 상속을 통한 재사용과 LSP(리스코프 치환 원칙)에 대한 고찰

블랙잭 미션을 구현하며 Dealer와 Player 사이의 공통점을 처리하기 위해 상속을 활용했으나, 이 과정에서 객체의 책임과 LSP 사이에서 고민이 발생해 질문드립니다.

상황

초기 설계에서는 Dealer가 Player의 속성(이름, 카드 관리, 점수 계산)을 공유한다는 점에 집중해 상속 관계(Dealer extends Player)를 맺었습니다. 이후 "실제 세계에서 딜러가 카드를 나눠준다"는 직관을 반영하기 위해, 기존 CardDispenser에 있던 '덱 관리'와 '카드 분배' 책임을 Dealer에게 통합하는 리팩토링을 진행했습니다. (commit: d677afa)

고민

리팩토링 후, 다음과 같은 설계적 모순을 발견했습니다.

Player를 기대하는 곳에 Dealer를 넣었을 때, 진행자로서의 '덱' 상태가 의도치 않게 공유됩니다. 또한, 향후 '베팅' 기능이 추가된다면 Player의 자식인 Dealer는 해당 기능을 거부(Exception 등)해야만 하며, 이는 명백한 LSP 위반으로 이어질 것이라 판단했습니다.
YAGNI(You Ain't Gonna Need It) 원칙에 따라 "아직 일어나지 않은 베팅 기능을 위해 추상화 계층을 미리 만드는 것이 과유불급인가?"라는 의구심이 들었습니다. 하지만 현재 구조는 Dealer에게 '참가자'와 '진행자'라는 두 가지 책임이 섞여 있어 SRP 측면에서도 불안정해 보입니다.

질문

추상화의 적절한 시점: YAGNI를 지키면서도 미래의 LSP 위반을 방지하기 위해, 지금 단계에서 abstract class Participant와 같은 추상화 계층을 도입하여 Dealer와 Player를 형제 관계로 분리하는 것이 타당한 선택일까요?
직관 vs 설계 원칙: 현실 세계의 역할(딜러의 분배)을 코드에 녹여낼 때, 도메인 모델의 직관성을 위해 원칙(LSP, SRP)을 어느 정도 타협해도 괜찮은지, 혹은 원칙을 고수하여 '분배기'와 같은 기능적 객체를 유지하는 것이 장기적으로 옳은 방향인지 멘토님의 견해가 궁금합니다.

3. 컨트롤러의 책임 범위와 도메인 객체(BlackjackGame)에 대한 고민

MVC 패턴을 적용하며 Controller가 비즈니스 로직의 상세한 흐름을 어디까지 제어해야 하는지, 그리고 이를 도메인 객체로 캡슐화하는 기준에 대해 고민이 생겨 질문드립니다.

상황

현재 BlackjackController는 단순히 모델과 뷰를 연결하는 역할을 넘어, 다음과 같은 블랙잭 흐름을 직접 제어하고 있습니다.

사용자의 입력 결과에 따라 카드를 추가로 뽑는 while 루프와 조건문(canHitMore)이 컨트롤러에 위치
딜러가 16점 이하일 때 자동으로 카드를 뽑는 로직
컨트롤러가 Dealer, Player, Deck 등을 각각 관리하며 이들의 상호작용을 일일이 지시하고 있습니다.

고민

컨트롤러가 뚱뚱해지는 현상을 피하고 싶었지만, 사용자의 입력(InputView)에 따라 도메인 상태가 변하는 구조(예: 카드를 더 받을지 말지 결정, 도메인 처리에 따른 즉각 출력 등)때문에 로직을 도메인으로 완전히 밀어 넣는 데 어려움을 겪었습니다.

BlackjackGame과 같은 별도의 도메인 객체를 만들어 Dealer, Players를 감싸고 게임의 진행 상태를 관리하게 하는 것이 MVC 패턴의 본질에 더 가까운 것인지, 아니면 현재처럼 흐름을 명시적으로 보여주는 컨트롤러 구조도 괜찮은건지 고민이 됐습니다.

질문

멘토님이 생각하시는 컨트롤러의 '선'은 어디까지인가요? 비즈니스 로직의 순서(Workflow)를 컨트롤러가 알고 있는 것이 자연스러운 것인지, 아니면 이 순서조차 도메인 내부로 숨기는게 더 좋은건지 궁금합니다.
while문 안에서 InputView를 호출해야 하는 경우처럼, 도메인 로직과 UI 인터랙션이 끈끈하게 결합될 때 이를 구조적으로 깔끔하게 분리할 수 있는 멘토님만의 노하우가 있으신가요? (예: 함수형 인터페이스 활용 등)
BlackjackGame이라는 객체를 도입한다면, 이를 상태를 가진 도메인 객체로 설계하는 것이 좋을까요, 아니면 행위만 가진 서비스 레이어로 설계하는 것이 좋을까요?

감사합니다.

* 참가자 추가 카드 오픈 후 한 번만 카드 목록을 출력하도록 수정

여기서부터 TDD로 진행합니다.

* enum 미사용 메서드 제거 * 미사용 클래스 제거

yenawee

안녕하세요 이프! 블랙잭 1단계 잘 구현해주셨네요.
한번 보완하고 넘어갈 점들 코멘트로 남겨놨으니 확인해주세요🙂

페어 프로그래밍 과정에서 '속도'와 '합의' 사이의 균형을 어떻게 잡아야 할까요?
실무에서도 우테코 방식처럼은 아니지만 페어를 꽤 많이 진행하는 거 같아요. 보통 신규 팀원 온보딩 시, 핵심 로직이나 복잡한 비즈니스 아키텍처 설계 시 페어를 했었던 적이 있습니다. 페어를 하면 개발속도가 더뎌지는 건 맞아요. 그렇지만 코드리뷰+의견 나누는 법 배우기+디버깅 등 나중에 PR 리뷰하고 피드백을 받으면서 코드를 수정하는 시간은 단축될 수 있다는 장점도 있을 거 같아요. 서로 시간을 정해두고 토론을 하거나, 페어 사이에 명확한 역할 분리를 해서 품질이 아닌 취향의 문제라면 현재 키보드를 잡고 있는 사람의 의견을 따르는 방식도 좋을 거 같아요 :)
상속을 통한 재사용과 LSP(리스코프 치환 원칙)에 대한 고찰
이 부분은 코멘트로 달아뒀으니 한번 고민해보시는게 좋을거같아요.

베팅 기능이 없어도 딜러와 플레이어는 규칙이 다릅니다.
객체지향은 현실의 물리적 법칙을 그대로 옮길 필요가 없어요. 딜러는 게임을 진행하고 카드를 나눠주고 게임의 참가자 역할도 하지만 모두 딜러의 책임으로 넣는다면 너무 많은 책임을 가지게 되겠죠. 기존에 하셨던 CardDispenser를 분리해 둔 설계가 오히려 책임 분리가 더 잘된 것처럼 보여요.

컨트롤러의 책임 범위와 도메인 객체(BlackjackGame)에 대한 고민
비즈니스 로직의 순서는 컨트롤러가 아는 것이 자연스럽다고 생각해요. 하지만 상세 비즈니스 로직은 도메인 안에서 처리해야 한다고 생각합니다.
BlackjackGame 을 도입한다면 Dealer, Players 등을 변수로 가진 객체로 설계하는 것이 좋다고 봐요. 그러면 컨트롤러가 변수들을 들고다니며 조작할 필요도 없어 가벼워질 거 같네요.
도메인, UI 분리 관련해서는 현재 코드처럼 컨트롤러가 도메인 상태를 읽고, UI 호출한뒤, 다시 도메인을 업데이트하는 중재자 역할을 잘 하고 있는 것처럼 보여요.

추가 궁금한 점 있으면 코멘트나 디엠으로 남겨주세요! 감사합니다 :D

yenawee · 2026-03-09T12:16:01Z

src/main/java/model/Cards.java

+import java.util.List;
+import java.util.stream.Stream;
+
+public class Cards {


blackjack 게임에선 Deck 이라는 용어를 쓰는데 네이밍 바꿔보는 건 어떨까요?

감사합니다! Card라는 객체가 있으면 이에 대한 일급 컬렉션은 그대로 복수형으로 표현하고자 하는 고정관념이 있었어요!
그런데 보다 조금 더 명확한 표현을 사용하는게 더 좋겠군요..!

yenawee · 2026-03-09T12:43:51Z

src/main/java/model/Dealer.java

+
+import java.util.List;
+
+public class Dealer extends Player {


현재 Dealer 가 Player 를 상속받고 있어요. 둘의 역할에 대해 다시 생각해보면 좋을거같아요.
이 상속관계라면 "딜러가 플레이어다" 가 성립하는지 생각해볼까요?

Tip)
둘의 공통 행위를 생각해보고 그 공통행위를 추출한 인터페이스를 구현해봅시다!

카지노 게임 참여자는 딜러다, 카지노 게임 참여자는 플레이어다. 그리고 이에 반대되는 명제도 성립하는 것 같아요.
반면 딜러가 플레이어다는 완전히 같은 역할을 하지 않는 이상, 명제가 성립 될 수 없겠네요 !

좋은 피드백 감사합니다 :)

yenawee · 2026-03-09T12:46:27Z

src/main/java/model/Cards.java

+        return cards.removeLast();
+    }
+
+    public int calculateScore() {


점수 계산이나 Ace 카드 수 세기 등은 참가자가 가지고 있는 카드들에서 행해지는 행동들이겠죠?

CreateDeck Shuffle, pickCard 등은 덱에서 행해지는 행동들 같아요.

책임을 분리해봅시다!

앞서 Cards 클래스를 Deck으로 변경하는 제안을 주셨는데, 해당 리뷰를 보니 Deck 객체로 Cards를 따로 관리하는게 좋을 것 같다는 생각이 들었어요!

최종적으로 아래와 같은 규칙을 만들게 됐습니다!

Cards는 Card의 상태를 관리한다.

Deck은 Card 정보들로 블랙잭만을 위한 동작을 담당한다.

yenawee · 2026-03-09T12:48:35Z

src/main/java/controller/BlackjackController.java

+
+    private void printGameResult(Dealer dealer, List<Player> players) {
+        PlayerResult playerResult = PlayerResult.judgeByPlayer(dealer, players);
+        int winCount = playerResult.countByStatus(GameStatus.LOSE);


딜러 관점 winCount 겠죠? 그러면 변수명을 명확히 dealerWinCount 라고 해보는게 어떨까요?

감사합니다 :)
Lose 상태의 count를 가져오는데 winCount라는 변수를 받으니, 오해의 여지가 있네요!

yenawee · 2026-03-09T12:50:48Z

src/main/java/model/Cards.java

+                .count();
+    }
+
+    public List<Card> getCard() {


내부 리스트를 바로 반환한다면 외부에서 cards 를 변경시킬 수 있어요.

복사 후 반환하는 건 어떨까요?

public class Cards { private final List<Card> cards; public Cards(List<Card> cards) { // this.cards = cards; this.cards = new ArrayList<>(cards); } ... }

감사합니다. 주신 피드백에 이어 생성자에서도 새로 주소 값을 할당해 저장하도록 하겠습니다!

yenawee · 2026-03-09T12:56:48Z

src/main/java/model/PlayerResult.java

+        this.result = result;
+    }
+
+    public static PlayerResult initResult() {


사용하지 않는 메서드는 제거합시다

yenawee · 2026-03-09T12:57:37Z

src/main/java/model/Dealer.java

+public class Dealer extends Player {
+
+    private static final String DEALER_NAME = "딜러";
+    private static final int MINIMUM_STAND_SCORE = 16;


HIT_THRESHOLD / MAX_HIT_SCORE

yenawee · 2026-03-09T12:58:17Z

src/main/java/view/InputView.java

+
+    public static List<String> readPlayerNames() {
+        System.out.println("게임에 참여할 사람의 이름을 입력하세요.(쉼표 기준으로 분리)");
+        return Arrays.stream(readLine().split(","))


플레이어 이름 검증 추가해보는게 어떨까요?

이런 부분도 항상 고민이 됐었는데, PR에 추가하지 못했네요 ㅠㅠ

요구사항에 명시되지 않은 검증을 추가해야하는가?

지금 이름이라는 정보는 저희가 추가하는 규칙이 될 것 같은데,
개발자는 필요에 따라 요구사항에 명시되지 않은 규칙을 추가해도 되나요?

실무에서는 마음대로 추가할 경우 제재를 먹겠지? 라는 생각으로 주어진 요구사항에 구현하는 것에 초점을 뒀습니다.
제나의 경우, 예측할 수 있는 범위의 검증은 그냥 추가하시나요?!

yenawee · 2026-03-09T12:58:33Z

src/main/java/view/InputView.java

+                .toList();
+    }
+
+    public static String readMoreCard(String playerName) {


잘못된 입력값 입력시 재입력 처리도 한번 고민해볼까요?

앞서 답변과 같은 내용으로 궁금합니다 :)
#1012 (comment)

yenawee · 2026-03-09T13:23:02Z

src/main/java/controller/BlackjackController.java

+
+    private void printGameResult(Dealer dealer, List<Player> players) {
+        PlayerResult playerResult = PlayerResult.judgeByPlayer(dealer, players);
+        int winCount = playerResult.countByStatus(GameStatus.LOSE);


결과 계산은 도메인 로직으로 넘겨주세요

감사합니다! 확실히 결과 계산 후 조회하도록 하는게 더 깔끔하겠네요...
count라는 메서드는 단순히 조회용이 아니라 비즈니스 로직처럼 느껴지네요!

좋은 피드백 정말 감사합니다 :)

* 패키지 분류 * Cards를 Hand, Deck으로 기능 별 일급 컬렉션으로 분리 * CardShuffler 도입으로 구현 결합도 감소

mvg01 and others added 14 commits March 4, 2026 16:59

docs: 리드미 작성

00af296

feat: 블랙잭 플레이어 이름 입력받기

bca8312

feat: 카드 관련 클래스 생성

bd83b3f

feat: 딜러와 플레이어 카드 나눠주는 기능 추가

1a38370

feat: 카드 중복 방지 로직 및 플레이어별 카드 추가 수령 기능 구현

f1fc1d7

feat: 딜러의 추가 카드 오픈을 정하는 로직 구현

bd33719

* 참가자 추가 카드 오픈 후 한 번만 카드 목록을 출력하도록 수정

feat: 딜러 카드와 플레이어 카드 결과 출력

7fd4de0

feat: 블랙잭 덱 생성 기능 추가

7a845ba

여기서부터 TDD로 진행합니다.

feat: 카드 디스펜서가 카드 나눠주는 기능 추가

a3d7634

feat: 카드 점수 계산 기능 추가

05951fd

feat: 딜러 및 플레이어의 카드 수령 가능 여부 로직 구현

e7f122f

feat: 블랙잭 결과 판정 기능 추가

0f595d4

* enum 미사용 메서드 제거 * 미사용 클래스 제거

refactor: 블랙잭 게임 흐름 메서드 분리로 Controller 정리

cd90102

refactor: controller 주석 제거 및 로직 추가 분리

d677afa

yenawee self-requested a review March 9, 2026 12:06

yenawee requested changes Mar 9, 2026

View reviewed changes

jihwankim128 added 5 commits March 11, 2026 10:30

refactor: 블랙잭 카드 연관 객체 리팩토링

9593c4a

* 패키지 분류 * Cards를 Hand, Deck으로 기능 별 일급 컬렉션으로 분리 * CardShuffler 도입으로 구현 결합도 감소

refactor: 참여자 공통 로직 분리

b470203

refactor: 게임 참여자 목록 일급 컬렉션으로 개선

03cb4e9

refactor: 딜러가 단일 책임을 가지도록 개선

e767b6e

refactor: 참여자 이름 검증 추가

9b756d1

Conversation

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

Uh oh!

개요

체크 리스트

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

1. 페어 프로그래밍 과정에서 '속도'와 '합의' 사이의 균형을 어떻게 잡아야 할까요?

2. 상속을 통한 재사용과 LSP(리스코프 치환 원칙)에 대한 고찰

3. 컨트롤러의 책임 범위와 도메인 객체(BlackjackGame)에 대한 고민

Uh oh!

yenawee 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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jihwankim128 commented Mar 8, 2026 •

edited

Loading