✅ 장기 사이클1: 사전학습
| 목적 | 키워드 |
| 게임 구현 | 장기 규칙, 보드 구조(9x10), 기물 종류, 초기 배치 |
| 상태 모델링 | 불변 객체, 방어적 복사 |
| 이동 규칙 구현 | 기물별 이동 방식(차, 마, 상, 사, 장, 포, 졸) |
| 다형성 | 인터페이스, 추상 클래스, 오버라이딩 |
본격적인 활동에 앞서 먼저 위의 키워드들에 대해서 가볍게 공부해보고 다음의 4가지 실험을 했다.
- 실험1: 보드 초기화 설계
- 장기판은 어떤 자료구조로 표현할 것인가?
- 기물은 어떤 정보를 가지는가?
- 위치 정보는 누가 관리하는가? (보드? 기물?)
- 빈 칸은 어떻게 표현하는가?
- 실험2: 상태 분류
- 상태가 변할 때 누가 변경하는가?
- 상태가 외부에 노출되어도 괜찮은가?
- 상태가 잘못 변경되면 어떤 문제가 생기는가?
- 실험3: 기물 이동시 조건문 폭발
- 기물 종류 개수는?
- 각 기물별 이동 규칙 개수는?
- 예상되는 조건문 개수는?
- 가장 복잡한 기물의 이동 규칙은?
- 실험4: 확장의 어려움
- 새 기물 추가 시 수정해야 하는 곳은?
- 기존 기물 규칙 변경 시 영향 범위는?
- 조건문이 한 곳에 모여 있으면 생기는 문제는?
- 조건문 없이 이동 규칙을 처리하는 방법은?
😃 Liked (좋았던 점)
- 무빙 크루와 장기판을 표현할 자료구조를 의논하면서 혼자 고민할 때는 놓쳤던 부분들을 잡을 수 있어서 좋았다.
- 실제 구현에 들어가기 전에 사전 학습을 통해 다양한 상황을 미리 실험해볼 수 있었던 점이 인상적이었다. 단순히 구현부터 시작했다면 놓쳤을 부분들까지 미리 인지할 수 있었고, 덕분에 더 깊이 있게 문제를 이해할 수 있었다.
☹️ Lacked (부족했던 점)
- 답이 없는 문제를 너무 오래 혼자 고민했다.
🧐 Learned (배운 점)
- 처음에는 장기판의 자료구조를 단순히 “장기판은 2차원 배열처럼 생겼으니, 2차원 배열로 구현하는 것이 자연스럽겠다”라고 생각했다. 하지만 Map<위치, 기물> 형태로도 충분히 표현할 수 있다는 것을 보면서, 어떤 객체를 추상화할 때 반드시 그 물리적인 모습을 그대로 코드로 옮기는 것만이 정답은 아니라는 점을 깨달았다.
- 개발을 공부하다 보면 하나의 정답으로 결론 내리기 어려운 경우가 많다. 장기판의 자료구조를 고민했던 경험이 그 대표적인 예였다. 이런 문제를 혼자만 고민하기보다는 다른 사람과 함께 의견을 나누는 것이 훨씬 도움이 된다는 것을 다시 한번 느끼게 되었다.
🤗 Longed for (앞으로 바라는 점)
- 특정 문제가 30분이상 고민된다면 바로 다른 크루와 의논하자!
✅ 장기 사이클1: 토론
사전학습한 내용을 기반으로 다음 주제로 크루들과 토론하는 시간을 가졌다
- 위치 정보는 보드가 가지는가, 기물이 가지는가?
- 기물 객체는 불변이어야 하는가?
- 보드의 상태를 외부에서 직접 수정할 수 있어야 하는가?
- 빈 칸은 null인가, 객체인가?
- 조건문은 언제 문제가 되는가?
- 다형성으로 대체할 수 있는 조건문의 기준은?
- 기물은 자신의 이동 규칙을 알아야 하는가?
- 공통 인터페이스는 어떻게 설계하는가?
😃 Liked (좋았던 점)
- 하나의 주제에 대해 다양한 의견을 들을 수 있어 좋았다.
예를 들어, 장기판을 Map으로 관리한다는 점에는 모두 공감했지만, 보드의 빈칸을 어떻게 처리할지에 대해서는 서로 다른 의견이 있었다. 어떤 크루는 빈칸까지 Map에 포함시키는 것이 좋다고 했고, 나는 Map에 존재하지 않는 key를 조회했을 때 빈칸으로 간주하는 방식이 더 적절하다고 생각했다.
☹️ Lacked (부족했던 점)
- 내 생각을 충분히 명료하게 정리해 전달하지 못한 부분이 있었던 것 같다. 급한 마음에 머릿속에 있는 생각을 정리하지 않은 채 이야기하다 보니, 전달 과정에서 말이 꼬이고 더듬게 되었다.
🧐 Learned (배운 점)
- 생각을 정리한 뒤 차분하게 전달하는 것이 중요하다는 점을 느꼈다.
- 공통 인터페이스를 설계할 때 추상 클래스와 인터페이스를 언제 사용하는 것이 적절한지 토론을 통해 정리할 수 있었다.
인터페이스는 역할 중심의 설계와 유연한 확장이 필요할 때, 추상 클래스는 공통 상태와 기본 구현을 공유해야 할 때 사용하는 것이 적절하다는 점을 이해하게 되었다.
🤗 Longed for (앞으로 바라는 점)
- 생각을 정리한 뒤 말하는 습관을 가져야겠다고 느꼈다. 바로 정리가 어렵다면, 잠시 양해를 구하고 정리한 뒤 이야기하는 것이 더 효과적일 것 같다.
✅ 장기 사이클1: 페어 프로그래밍
이번 장기 미션에서의 페어는 '밀란'이다.
축구를 좋아해서 AC'밀란'의 밀란을 딴 이름인줄 알았는데, 그건 아니고 파스타를 좋아해서 이탈리아 도시인 밀란을 이름으로 했다고 한다.
참고로 축구는 관심 없다고 한다...
내 PR:
[🚀 사이클1 - 미션 (보드 초기화 + 기물 이동)] 제이 미션 제출합니다. by jhk01007 · Pull Request #197 ·
체크 리스트 미션의 필수 요구사항을 모두 구현했나요? 프로그래밍 요구사항 중, indent 조건과 메서드 10줄 제한 조건을 아직 충족시키지 못한 부분이 있습니다. 해당 부분은 제가 리뷰포인트에
github.com
😃 Liked (좋았던 점)
- 페어 프로그래밍이 두번째라 그런가 걱정했던 것보다 매우 순조롭게 진행됐다. 이게 다 밀란 덕분이라고 생각한다.
- 설계 방식에 대해 토론하는 과정이 재미있게 느껴졌다.
구현을 진행하던 중 설계가 다소 어색하다는 느낌이 들어 잠시 멈추고 화이트 보드에 적어가면서 설계에 대해 이야기를 나누었는데, 그 과정을 통해 더 나은 방향으로 구조를 개선할 수 있었다.
☹️ Lacked (부족했던 점)
- 내가 알고리즘 구현 능력이 많이 부족하다는 것을 체감했다.
코딩테스트 공부를 안한지 오래돼서 그런지 기물의 이동 규칙을 구현하는 과정에서 많이 버벅였다.
🧐 Learned (배운 점)
- 객체지향 설계를 시작하는 새로운 방법에 대해 알게 되었다.
밀란은 객체지향 설계를 시작하는 방식이 나와는 달랐다. 나는 요구사항을 먼저 쭉 정리하고 객체를 정리하는 편이라면, 밀란은 객체를 먼저 선별하고 그 객체를 기반으로 요구사항을 정리한다. 이렇게 하니 요구사항이 더 뚜렷해지는 느낌이 들었다.
🤗 Longed for (앞으로 바라는 점)
- 코딩테스트 공부를 다시 시작해야겠다는 생각이 들었다. 이전 블랙잭 미션부터 이번 장기 미션까지, 로직이 조금만 복잡해져도 시간이 오래 걸린다는 것을 체감했다.
'우테코 8기 > 본과정 회고' 카테고리의 다른 글
| [우테코 8기] 4주차 회고 (0) | 2026.03.22 |
|---|---|
| [우테코 8기] 3주차 회고 (0) | 2026.03.15 |
| [우테코 8기] 2주차 회고 (0) | 2026.03.08 |
| [우테코 8기] 1주차 회고 (0) | 2026.03.01 |