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

kdongsu5509 · 2026-03-08T14:24:39Z

체크 리스트

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

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

주제 1. `Delegate` 패턴 도입에 관한 고찰

페어 프로그래밍 중 가장 치열하게 논의한 지점은 'View와 Model(Domain) 간의 상호작용을 전통적인 Controller로 제한할 것인가, 아니면 Delegate 패턴을 도입할 것인가'**였습니다. 현재는 Delegate를 활용한 흐름을 구현했으나, 이것이 Controller 본연의 역할을 충분히 수행하고 있는지에 대한 의구심이 남습니다.

일반적으로 Controller는 View와 Model의 중재자 역할을 수행합니다. 그러나 이번 구현에서는 별도의 Service 레이어 없이 View <-> Controller <-> Game(Domain)의 직결 구조를 가집니다. 이 과정에서 Controller가 Domain의 흐름에 강하게 결합되거나, Domain 내부 로직에 관여하게 되는 구조에 대해 "설계 원칙을 위반한 것이 아닌가"라는 생소함과 우려를 동시에 느끼고 있습니다.

주제 2. CLI 환경에서의 Web 아키텍처 고려 여부

페어는 'Web 환경의 확장성을 고려할 때, 상태 유지가 전제된 Delegate 방식은 부적절하다'는 의견을 제시했습니다. 웹의 요청-응답(Request-Response) 구조와 스레드 점유 문제를 고려하면 타당한 지적이나, 이를 CLI 환경에까지 강제 적용해야 하는지에 대해서는 의문이 생겼습니다.

모바일(Flutter) 환경에서는 서버와 통신할 때 ID 값 등을 넘겨 상태를 식별하는 방식으로 무상태성(Stateless)을 해결합니다. 반면 CLI는 프로세스가 유지되는 동안 상태를 메모리에 보관할 수 있습니다. 레벨 1에서 CLI와 Web의 구조적 차이(특히 HTTP의 무상태성으로 인한 리소스 관리 방식)를 깊이 있게 고민하는 것이 향후 레벨 2 웹 학습을 위한 필수적인 과정인지, 그리고 제가 이해한 '웹의 제약 사항 때문에 생겨난 설계의 차이'가 본질적으로 맞는지 확인하고 싶습니다.

주제 3. 설계의 적정 범위

이번 개발 사이클 이후 설계의 깊이와 구현 속도 사이의 최선의 중간 지점은 어디일까라는 고민이 생겼습니다. 과도한 사전 설계가 구현을 지연시킬 것이라 판단하여 최소한의 아키텍처와 핵심 객체만을 정의한 채 개발에 착수했으나, 이후 재설계와 코드 수정이 빈번하게 발생하여 많은 시간을 소요하였습니다.
게다가 불안정한 설계 상태에서의 TDD까지 시도하니 문제가 더욱 크게 다가온 것 같습니다. 설계가 변경될 때마다 작성된 테스트 코드도 수정해야 해서 시간이 더 걸렸다고 생각이 됩니다. 철저한 사전 설계와 간소한 설계 사이의 적정 설계를 결정하는 기준은 무엇인지, 그리고 이러한 설계적 직관을 기르기 위한 방법에 대해 깊은 고민이 남았으나 실마리조차 잡히지 않아 방향성을 어떻게 잡아야 할 지 고민입니다.

주제 4. 커밋의 단위

미션을 진행할 때 커밋의 단위는 기능이었습니다. 이 때문에 한 커밋에 100줄이 넘는 코드가 포함되는 경우가 잦았고, 이 정도로 큰 덩어리는 차후에 리뷰어께서 리뷰할 때 가독성을 크게 저하시키지 않을까라는 생각을 했습니다. 무작정 '기능 구현 완료'라는 명목으로 코드를 몰아넣는 것이 과연 최선인지, 아니면 협업과 코드 리뷰를 고려했을 때 가장 이상적인 커밋당 코드 양이나 분리 기준이 따로 있는지 궁금합니다.

딜러와 플레이어를 추가하였고, 그들의 공통 조상인 참가자를 추가함. 이후 카드와 카드들을 관리하는 덱의 정의를 추가함.

- 신규 덱 제공 기능 테스트 - 카드 뽑기 기능 테스트 추가(정상, 실패)

- 새로운 덱 제공 기능 - 카드 선택 기능 을 추가하였습니다.

Ace 값 판정과 전체 카드 점수 합 기능은 상호 의존성을 띄기 때문에 Ace는 제외한 카드 점수 합을 계산하는 기능을 추가함.

- add card score total sum feature - add bust discrimination feature

딜러 생성 시 필요한 파라미터 Deck의 인스턴스 종류를 명시함

공통 로직을 제거하기 위해 participant 추가

딜러만의 고유한 카드 추가 로직을 위해 별도의 메서드가 선언되어 있습니다. 차후 다른 개발자가 addCard 메서드 호출 시 현재 설계상으로는 오류가 발생하기 때문에 UnsupportedOperationException을 던지는 것으로 override 해두었습니다

기존 변수 deck의 모호성을 제거하기 위해 변경

딜러와 플레이어의 카드 추가 메서드를 단일화하여 차후 Participant 로 사용이 가능하도록 변경

- 클래스 내부에서 필드 멤버로 List 사용하는 것을 줄이기 위해 - 추후 참가자들의 전체 정보를 알아야만 계산할 수 있는 내용들을 다룰 클래스가 필요해서

BufferedReader 사용 시 IOException 관련 문제가 존재. 해당 문제를 핸들링 하는 것 보다 속도가 다소 느리더라도 Scanner 을 이용하여 문제를 핸들링 하지 않게 되는 것이 더 좋다고 판단하여 변경함

테스트 로직 작성의 용이성을 위해 mockito 추가

- 부모 클래스(Participants)가 자식 객체를 생성하는 구조적 모순을 해결하기 위해 해당 공통 클래스 제거 - 다수의 플레이어를 관리하는 일급 컬렉션 Players 클래스 신규 추가 - Game 도메인이 Dealer와 Players를 각각 독립적인 필드로 분리하여 관리하도록 객체 구조 개선 - 도메인 구조 변경에 따라 Dealer에 getCards() 메서드를 추가하고, OutputView 출력 로직 수정

가독성을 위해 메서드 분리를 진행함

This reverts commit 2fb6f4b.

echo724

안녕하세요 라티! 반갑습니다! 첫 백엔드 미션 힘들진 않았나요? ㅎㅎ,, 아무래도 페어와 함께 설계하고 코드를 작성하는게 쉽지 않았을텐데, 고생 많으셨습니다.
피드백 남기긴 했는데, 이번 미션에서는 중복 이름 버그 위주로 고쳐주시고, 나머지는 커멘트로 남겨주세요! 아래는 질문에 대한 답입니다. 빠르게 남겨주시고 요청 남겨주세요~ 화이팅입니다!

주제 1. Delegate 패턴 도입에 관한 고찰
이 논의은 제가 미션 했을때도 많은 크루들 사이에 있었던 논의였던 기역이 있네요 ㅎㅎ,,
일단 그때로 다시 돌아가 저에게 해줄 수 있는 조언이 있다면, 현재 미션에 충실하라는 것 그리고 용어와 패턴 정의를 정확히 알라는 것입니다.
Controller라는 용어는 어디서 나왔을까요? 어떤 문제를 해결하고자 MVC 패턴이 나왔을까요? 웹 서비스에서의 Controller는 어떤 역할일까요?
CLI 서비스와 웹 서비스의 차이는 무엇일까요? MVC의 View는 어떤 역할을 하나요?
저는 특정 패턴에 대한 충분한 이해가 있을때 도입 여부를 생각해볼 수 있는 것 같습니다.
그래서 제 입장에서 Delegate 패턴은 MVC 패턴을 억지로 맞추려고 하다가 도입된 패턴으로 보입니다.
정말 Controller가 필요할까요? Delegation이 필요할까요? Game에 InputView, OutputView를 주입해서 사용하면 안될까요?
이번 미션의 UI 로직 분리 요구사항은 다음과 같습니다:

- 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 구분한다.
- UI 로직을 InputView, ResultView와 같은 클래스를 추가해 분리한다.

이 미션 요구사항은 UI로직을 분리하라지, Controller를 도입해라가 아닙니다.
이 부분 구분하셔서 잘 생각해보시면 좋을 것 같아요!

주제 2. CLI 환경에서의 Web 아키텍처 고려 여부
ㅎㅎ,, 위에 답변과 비슷한데요, 현재 미션에서는 벗어난 고민인 것 같습니다.
이번 미션 핵심 주제는 변경 가능한 프로그램은 어떻게 만드는가?입니다.
이번 미션에서는 객체의 책임과 분리, 협업 설계에 좀 더 학습해보시고 웹의 구조와 패턴은 이후 레벨에서 충분히 학습해보세요!
결국 이번 미션에서 이 부분을 충분히 학습하지 않는다면, 웹을 배우면서도 이 부분에서 모호함이 계속 남아있을 수 있습니다.
추가로 웹도 CLI도 결국에는 표현 방식 view의 영역입니다.
Redis에도 CLI로 돌아가는 Client 프로그램이 있고 Server 프로그램이 따로 있듯이, 각자의 책임과 역할에 따라 분리되는 거죠.
view쪽 단의 고민을 너무 하지 마시고 결국에는 핵심적으로 관리해야하는 비지니스 로직은 무엇인지, 어떻게 분리하고 지켜낼 수 있을지에 고민을 충분히 더 해보시길 추천드려요!

주제 3. 설계의 적정 범위
저는 개발 단계에서는 충분히 변경 될 수 도 있고 변경 되어야한다고 생각합니다. 변경이 최소화 되야하는 하는 때는 해당 프로그램이 배포 되어 실제로 사용되고 있을 때이구요.
배포 이후에 추가 요구사항으로 기존 설계가 크게 변경된다면 이는 잘못된 설계일 가능성이 있죠.
개발 단계에서는 충분히 시간을 들여 변화에도 내성이 있는, 즉 구조가 크게 바뀌지 않으면서 추가 요구사항을 처리할 수 있는 설계를 하는 것이 더 중요하다고 생각합니다.
그럼에도 시간이 너무 오래 걸리는 것 같다고 생각이 드신다면, 아무래도 실제 구현을 하면서 설계 때 놓친 요구사항이나 제약들이 있어서 그런 것일 수 있다고 생각합니다.
그래서 저는 철저한 사전 설계보다는, 철저한 요구사항 분석과 제약을 나열해보고 시작하시는 것을 추천 드려요.
그리고 테스트 코드 수정에 대한 부분도 얘기해주셨는데, 경험상 작은 부분부터 작성하다가 갑자기 상위 레이어에서 설계 변경이 있을 경우에 더 그럴꺼같아요? 맞을까요?
그런 경우에는 out->in 방식으로 큰 부분을 TDD로 구현해서 틀을 잡고, 내부 부품들을 구현해보는 것도 방법입니다. 이럴 경우, 내부 설계가 변경 되더다도 전체가 변경되진 않을테니까요.

주제 4. 커밋의 단위
아무래도 사람마다 차이가 있을 수 있는 부분이지만 개인적으로 롤백(revert)하기 좋은 단위를 저는 이상적인 커밋 단위라고 생각합니다.
아무래도 기능에 100줄 이상이라면 분명 여러 컴포넌트 작업이 같이 포함되어있을 수 있겠죠?
만약 다른 기능에서도 해당 컴포넌트를 사용하는데 해당 컴포넌트가 문제가 있을 경우에는 그러면 전체 기능을 롤백해야하는 상황이 생깁니다.
그리고 이렇게 롤백이 잘 되는 커밋은 또한 최대한 작은 커밋입니다.
그래서 코드 리뷰, 협업을 생각해서 커밋 단위를 정하시는 것 보다는 내가 이 커밋을 쉽게 되돌릴 수 있을까?를 기준으로 생각해보시는 것도 추천드려요!

echo724 · 2026-03-10T01:31:23Z

src/main/java/domain/Participant.java

+    public Optional<Card> addCard(Deck totalDeck) {
+        Card newCard = totalDeck.drawCard();
+        this.deck.addCard(newCard);
+        return Optional.of(newCard);


newCard가 Null이 되는 경우가 있나요? Optional을 왜 사용하신 거죠?

아 Dealer가 카드를 더 받을 수 있을지 없을지에 대해 판단을 리턴값으로 하고, 이를 위해 리턴 타입을 Participant에서 맞춰준 거군요?

즉, 부모 타입인 Participant가 자식 타입인 Dealer의 카드 드로우 로직을 위해 리턴 타입이 맞춰진 부분이라고 볼 수 있겠죠? 현재 Optional로 감싸진 형태라 괜찮긴 한데, 이상적으로는 상위 타입은 하위 타입 구현에 대해 알고 있으면 안됩니다. 이는 다른 하위 타입을 생성할때, 다른 하위 타입의 구현 디테일을 알아야하고, 상위 타입의 로직이 바뀔 경우 하위 타입의 변경 가능성이 커지기 때문입니다. 혹시 어떻게 생각하시나요?

echo724 · 2026-03-10T01:44:38Z

src/main/java/domain/Game.java

+        return new Game(totalDeck, dealer, players);
+    }
+
+    public void play(GameDelegate observer) {


delegate, observer 두 용어가 동시에 사용되고 있네요. play 메서드 안에서 특별한 의미를 갖지 않는 이상 통일 하시길 추천드립니다.

echo724 · 2026-03-10T01:54:38Z

src/main/java/domain/Game.java

+        Map<Result, Integer> dealerWinLossResults = new HashMap<>();
+        List<Player> playingPlayers = playerWinLossResults.keySet().stream().toList();
+        for (Player player : playingPlayers) {
+            Result dealerResult = playerWinLossResults.get(player).reverse();
+            int currentValue = dealerWinLossResults.getOrDefault(dealerResult, 0);
+            dealerWinLossResults.put(dealerResult, currentValue + 1);
+        }
+        return dealerWinLossResults;


for (Result playerWinLossResult : playerWinLossResults.values()) { Result dealerResult = playerWinLossResult.reverse(); int currentValue = dealerWinLossResults.getOrDefault(dealerResult, 0); dealerWinLossResults.put(dealerResult, currentValue + 1); }

이 부분, values만 있으면 되지 않을까요?

echo724 · 2026-03-10T01:59:32Z

src/main/java/domain/Participant.java

+import java.util.regex.Pattern;
+
+public abstract class Participant {
+    private final Deck deck;


Participant가 Deck을 갖고 있는게 저는 조금 어색해보입니다. 이럴 경우 isBurst()와 calculateCardScoreSum() 같이 플레이어 핸드에만 필요한 메서드/로직 들이 Deck에 들어가고, 반대로 Participant에서는 덱 생성 로직이나 덱과 관련된 로직들이 접근 가능해지죠? 간단한 예로, 만약 2년 뒤에 어떤 개발자가 Participant와 관련된 기능을 만든다고 할때, Participant에 Deck이 있는 것을 보고 이게 게임에 사용되는 모든 카드의 덱인지, 아니면 2장만 있는 카드 덱인지 어떻게 알 수 있을까요?

리뷰어님이 남겨주신 문제 상황은 현재 Deck에 2가지 역할이 혼재하기 때문에 충분히 발생 가능할 것 같습니다.
첫 번째 역할은 전체 카드를 생성, 관리하는 역할이고 두 번째 역할은 Player 의 인스턴스 변수로 생성되어 사용자들의 카드를 관리하는 역할이라고 판단을 하였습니다.
두 가지 역할의 혼재로 인한 혼란인 만큼 클래스를 역할 단위로 분리하여야 할 것 같음을 인지하였습니다!

echo724 · 2026-03-10T02:03:57Z

src/main/java/domain/Participant.java

+        Pattern NAME_PATTERN = Pattern.compile("^[a-zA-Z가-힣]+$");
+        validateIsNotBlank(name);
+        validateKoreanAndEnglish(name, NAME_PATTERN);


사소할 수 있긴 한데, NAME_PATTERN을 validateKoreanAndEnglish 밖으로 뺀 이유를 알 수 있을까요? 해당 네임 패턴은 한국어와 영어인지 검사하는 패턴 아닌가요? 그러면 validateKoreanAndEnglish 메서드 내부에 있는게 자연스러워 보이는데 어떻게 생각하시나요? 혹시 이 패턴이 이 메서드 외에 다른 곳에서도 사용될 수 있을까요?

NAME_PATTERN 을 밖으로 빼낸 특별한 이유는 없습니다. Ctrl + Alt + M 을 이용한 메서드 추출 기능을 사용하여 해당 부분을 간과했습니다.

echo724 · 2026-03-10T02:20:06Z

src/main/java/domain/Deck.java

+        return calculateCardScoreSum() > BUST_CRITERIA;
+    }
+
+    public int calculateCardScoreSum() {


다른 커멘트와 마찬가지로 이 로직이 Deck에 필요한 로직일까요? 게임 덱과 참여자 핸드가 둘다 Card 컬렉션을 필요로 하는 것은 맞지만 둘의 생명주기(LifeCycle)도 다르고 역할과 책임도 다르다고 생각합니다

다른 커멘트에서 언급한 바와 같이 Deck 에 2가지 역할이 존재하게 되면서 발생한 문제라고 판단이 됩니다. Deck을 역할을 기준으로 분리하여서 필요한 경우에만 생성되고, 책임도 줄어든 형태로 리팩토링 진행하겠습니다

echo724 · 2026-03-10T02:22:21Z

src/main/java/domain/Deck.java

+
+    public int calculateCardScoreSum() {
+        int sumExceptAce = calculateCardScoreSumExceptAce();
+        int sumAce = new AceScoreDiscriminator().calculateAceCardsSum(cards, sumExceptAce);


이 클래스의 경우, 내부 상태가 없어보이는데 이렇게 계산할때마다 생성하는게 맞을까요?

테스트 코드 작성에만 초점을 두고 객체의 생성 비용에 대한 고려를 하지 못한 것 같습니다. 이것을 static 한 메서드로 변경하여 최초의 프로그램이 jvm 위에서 로딩될 때 한 번만 생성되는 것이 적절할 것 같습니다.

echo724 · 2026-03-10T02:29:39Z

src/test/java/controller/BlackJackControllerTest.java

+import view.OutputView;
+
+@ExtendWith(MockitoExtension.class)
+class BlackJackControllerTest {


BlackJackControllerTest를 볼때, Game run 관련 로직은 해당 Controller 테스트로 커버가 안되고 있죠? 테스트가 어렵다면 이는 그 로직이 해당 객체의 역할에 맞지 않을 수 도 있다는 의미일 것 같습니다.

echo724 · 2026-03-10T02:31:26Z

src/main/java/domain/Players.java

+        return new Players(createPlayers(playerNames, totalDeck));
+    }
+
+    private static List<Player> createPlayers(List<String> playerNames, Deck totalDeck) {


중복 이름 관련 생성 방어 로직이 빠진 것 같습니다. 다음과 같이 중복 이름의 경우, 플레이는 되는데 결과 창에서 한 명의 참여자 결과만 보이더라구요. 확인해보세요!

게임에 참여할 사람의 이름을 입력하세요.(쉼표 기준으로 분리) ee,ee 딜러와 ee, ee에게 2장을 나누었습니다. 딜러카드: A하트 ee카드: 10클로버, J다이아몬드 ee카드: 3스페이드, K다이아몬드 ee는 한장의 카드를 더 받겠습니까?(예는 y, 아니오는 n) y ee카드: 10클로버, J다이아몬드, 4스페이드 ee는 한장의 카드를 더 받겠습니까?(예는 y, 아니오는 n) n 딜러카드: A하트, 9하트 - 결과: 20 ee카드: 10클로버, J다이아몬드, 4스페이드 - 결과: 24 ee카드: 3스페이드, K다이아몬드 - 결과: 13 ## 최종 승패 딜러: 2승 ee: 패

echo724 · 2026-03-10T02:33:33Z

src/test/java/domain/GameTest.java

+@ExtendWith(MockitoExtension.class)
+class GameTest {
+    private static final List<String> TEST_PLAYER_NAMES = List.of("pobi", "terry", "rati", "gump");
+    private static final CardCreationStrategy STRATEGY = GameTest::createSampleCards;


random을 CreationStrategy로 빼셔서 잘 테스트 하셨군요👍

감사합니다!

Yeji-Kim-Erica added 30 commits March 4, 2026 17:44

docs(README): add feature list

4d992f1

feat: add name input feature

37074a5

feat: add hit or stand input feature

070e5ba

feat: add game instruction output feature

0e85d53

docs : add domains features

f121afe

딜러와 플레이어를 추가하였고, 그들의 공통 조상인 참가자를 추가함. 이후 카드와 카드들을 관리하는 덱의 정의를 추가함.

test : add card contents test

e2d44c2

feat : add card and enum class for card

8582f6d

test : add deck creation test

11fb3ea

feat : add deck creation feature

644c62b

docs : check what I implemented

b80246c

test : add deck test

3a01775

- 신규 덱 제공 기능 테스트 - 카드 뽑기 기능 테스트 추가(정상, 실패)

feat : add DRAW_CARD_OUT_OF_RANGE

ab9bdbc

feat : add new deck features

8571797

- 새로운 덱 제공 기능 - 카드 선택 기능 을 추가하였습니다.

test: add participant deck creation and cards draw

b8d0a79

feat: add participant deck creation feature

6c65b8c

docs: check what I implemented

fac0ae3

refactor: seperate card creation responsibility

4772f2a

refactor: change ace default card score

debd9c0

feat: add card sum calculation excluding aces

5598c39

Ace 값 판정과 전체 카드 점수 합 기능은 상호 의존성을 띄기 때문에 Ace는 제외한 카드 점수 합을 계산하는 기능을 추가함.

feat: add ace score discrimination feature

12c235e

feat: add card score related feature

430f617

- add card score total sum feature - add bust discrimination feature

feat: add card addition feature

80d3469

feat: add conditional card drawing feature for dealer

200ce6c

refactor: change dealer constructor parameter name

b79ef33

딜러 생성 시 필요한 파라미터 Deck의 인스턴스 종류를 명시함

test: add dealer constructor test

160cc41

refactor : separate common logic between Dealer and Player

7721bca

공통 로직을 제거하기 위해 participant 추가

fix : fix typo

f6ed131

refactor: delete '\n'

638445c

feat: add Player class

30ef159

Yeji-Kim-Erica added 22 commits March 6, 2026 17:30

docs: check what is implemented

61377fc

refactor : change variable name to totalDeck

3790ad7

기존 변수 deck의 모호성을 제거하기 위해 변경

fix : integrate adding card feature

ee65136

딜러와 플레이어의 카드 추가 메서드를 단일화하여 차후 Participant 로 사용이 가능하도록 변경

feat : add createParticipants feature

08f1a5e

fix: refactor participant list to a first-class collection

a78de9b

- 클래스 내부에서 필드 멤버로 List 사용하는 것을 줄이기 위해 - 추후 참가자들의 전체 정보를 알아야만 계산할 수 있는 내용들을 다룰 클래스가 필요해서

feat: add game creation feature

627bee8

feat : add constraint to Participants number

9e65f06

build : add mockito for test logic

00e8662

테스트 로직 작성의 용이성을 위해 mockito 추가

feat: add initial card share detail printing feature

ec4784b

feat: add name validation feature

44e10cf

feat: add create result feature

223b55e

refactor: divide card creation method

ce29cb5

가독성을 위해 메서드 분리를 진행함

refactor: introduce DTO

9196820

feat: bring in Delegate method

aa38ca7

feat: add card info and game result printing feature

60d6dfb

feat: add card info and game result printing feature

2fb6f4b

Revert "feat: add card info and game result printing feature"

9b63e36

This reverts commit 2fb6f4b.

Revert "feat: add card info and game result printing feature"

4283373

This reverts commit 2fb6f4b.

feat: add flow control logic and game progression feature

d4c97f6

feat: assemble components for running

c8818cd

echo724 self-requested a review March 10, 2026 01:03

echo724 requested changes Mar 10, 2026

View reviewed changes

Conversation

kdongsu5509 commented Mar 8, 2026

체크 리스트

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

주제 1. Delegate 패턴 도입에 관한 고찰

주제 2. CLI 환경에서의 Web 아키텍처 고려 여부

주제 3. 설계의 적정 범위

주제 4. 커밋의 단위

Uh oh!

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

kdongsu5509 Mar 10, 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!

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

주제 1. `Delegate` 패턴 도입에 관한 고찰

kdongsu5509 Mar 10, 2026 •

edited

Loading