[우아한테크코스] 레벨 1 기록

💭 들어가며

회고가 꽤 늦었다. 방학 기간 동안 부족했던 체력을 보충하고, 오랜만에 부모님도 뵙고... 사실 놀면서 점점 미뤄온 게 가장 큰 이유다. 😅

방학 마지막 날에서야 다시 마음을 가다듬고, 레벨 1에서 배운 것들과 고민했던 부분을 복기하며 회고를 남겨보고자 한다.

 

 

 

✅ 미션 1 - 로또

▶ PR

• Step 1: 로또 Step1 PR 링크
• Step 2: 로또 Step2 PR 링크

 

▶ 학습

🔽 키워드

• MVC
• 테스트 코드
• Object

🔽 블로그 정리

• [Java] 테스트 코드, JUnit & AssertJ

 

▶ 고민했던 부분

1️⃣ 요구사항도 의심하자

프리코스를 진행할 때도 그랬듯, 단순히 요구사항을 완벽히 지키는 것에만 집중했던 것 같다. 로또 미션에서도 Getter 사용을 지양하라는 요구사항이 있었는데, 왜 그런 요구가 있는지 충분히 이해하지 못한 채, 그저 지침처럼 따르기만 했다.

 

그러다 테스트 코드를 작성하면서 문제가 발생했다. Getter 없이 단위 테스트를 작성하려다 보니, Reflection에 대한 이해 없이 extracting() 메서드를 사용하거나, 다른 public 메서드를 우회적으로 호출해 테스트를 작성하게 되었다. 그렇게 억지로 Getter를 사용하지 않으려 애쓰다 보니, 점점 내가 지금 무엇을 위해 이러고 있는지 헷갈리기 시작했다. 어느 순간 코드가 방향을 잃은 듯한 느낌이 들었다.

 

결국, 코드를 싹 지웠다. 그리고 나서야 요구사항은 절대적인 명제가 아니라, 그 안에 담긴 의도를 이해하고 판단해야 한다는 것을 깨달았다. 그 이후로는 단순히 지키는 데 급급하기보다, 그 요구사항이 어떤 목적을 가지고 있으며, 내 설계와 어떻게 연결되는지를 끊임없이 고민하며 개발하려고 의식적으로 노력하게 되었다.

 

2️⃣ 책임 분리를 어디까지 해야 할까

미션을 진행하면서 View–Controller–Domain 각각의 역할과 책임을 명확히 분리하는 것에 큰 주안점을 두었다.

 

처음엔 이게 좋은 설계라고 생각했지만, 점점 "이 객체가 저 레이어의 객체를 의존해도 되는가"라는 고민에 너무 과하게 신경을 쓰기 시작했다. 객체의 본질적인 책임보다도, MVC 각 계층의 규칙을 절대적으로 지켜야 한다는 압박이 커졌고, 결국 무의미하게 잘게 나뉜 객체들이 생기기 시작했다. 책임 분리를 하려다 오히려 객체의 응집력이 떨어지고, 이해하기 어려운 구조가 되었다.

 

결국, 책임 분리는 단순히 잘게 나눈다고 해서 좋은 것이 아니며, 어디까지 나누는 것이 적절한가를 판단하는 능력 자체가 중요하다는 것을 깨달았다. SRP에서도 강조하듯, 책임을 어떻게 나눌지는 개발자의 판단에 달려 있다. 그 이후로는 무작정 분리하려 하기보단 왜 분리하는가, 그리고 이 분리가 어떤 의도를 가지고 있는가를 고민하면서 코드를 작성하려고 노력해 왔다.

 

 

 

✅ 미션 2 - 출석

▶ PR

• Step 1: 출석 Step1 PR 링크
• Step 2: 출석 Step2 PR 링크

 

▶ 학습

🔽 키워드

• Stream
• 함수형 인터페이스
• 컬렉션 프레임워크
• TDD
• DTO
• 전략 패턴

🔽 블로그 정리

• [Java] 람다 표현식, 함수형 인터페이스, Stream API
• [Java] 컬렉션 프레임워크(Collection Framework)

 

▶ 고민했던 부분

1️⃣ TDD가 과연 정답일까

TDD 자체가 처음이었다. 출석 미션은 TDD 방식으로 처음부터 끝까지 구현해야 했는데, 막상 진행하다 보니 어느 순간 TDD 자체가 목적이 되어버린 듯한 느낌을 받았다. 테스트를 위한 구현인지, 실제로 필요한 기능을 위한 구현인지 헷갈리는 순간들이 있었고, 심지어 작성한 테스트 코드를 모두 지우고 다시 작성하는 상황도 겪었다.

 

이 경험을 통해서 느낀 건, TDD는 어디까지나 수단이지 목적이 되어서는 안 된다는 점이었다. 결국 더 중요한 것은 의미 있는 설계와 로직이라는 것을 다시 한번 깨달았다. TDD는 분명 좋은 도구이긴 하지만, 의미 없이 맹목적으로 따라가는 순간 오히려 설계를 흐릴 수도 있다는 것을 경험을 통해 배웠고, 지금도 TDD 자체에 대해서는 계속해서 의심하고 탐색 중이다.

 

2️⃣ 코드를 작성할 때, 다른 개발자가 이어받는다고 생각하자

나만 이해할 수 있는 코드는 결국 유지보수 비용이 커진다. 이틀 전에 내가 짠 코드를 이해하지 못하는 나를 보면서 메서드나 클래스의 이름, 로직의 순서 하나하나까지도 의도를 명확히 드러내는 것이 중요하다는 것을 느꼈다.

 

그 이후로는 "내가 아닌 다른 사람이 이 코드를 처음 봤을 때, 설계 의도와 흐름을 이해할 수 있을까?"라는 관점에서 코드를 바라보게 되었다. 사실 이전에는 메서드명이나 변수명은 별거 아니라고 생각해서 ChatGPT의 도움을 많이 받곤 했는데, 이후 진짜 중요한 것은 의도를 담는 것이라는 생각이 들었고, 이름 하나에도 온전히 내 의도를 담으려고 노력하고 있다. 단순히 작동하기만 하는 코드가 아니라, 함께 일하는 동료들도 쉽게 이해할 수 있는 코드를 쓰는 것이 진짜 개발의 시작이라는 생각이 들었다.

 

 

 

✅ 미션 3 - 블랙잭

▶ PR

• Step 1: 블랙잭 Step1 PR 링크
• Step 2: 블랙잭 Step2 PR 링크

 

▶ 학습

🔽 키워드

• 제네릭
• LSP, ISP
• 상속, 조합
• 값 객체

🔽 블로그 정리

• [Java] 제네릭(Generic)
• [Java] 불변 객체, 값 객체
• [Java] 상속, 조합

 

▶ 고민했던 부분

1️⃣ MVC를 왜 쓰고 있었지

MVC 구조는 프리코스 때부터 자연스럽게 접했던 패턴이었다. 백엔드뿐만 아니라 프론트엔드에서도(?) 사용했던 구조였기에, 큰 고민 없이 당연하다는 듯 받아들이며 미션에 적용해 왔다. 로또와 출석 미션에서도 MVC 구조를 고수했지만, 돌이켜보면 그 구조를 유지하기 위해 의미 없는 고민을 반복한 경우도 많았다.

 

특히 Controller가 그 시작이었다. 블랙잭 미션에서는 BlackJackGame이라는 흐름을 제어하는 객체는 이미 존재함에도 불구하고, MVC라는 형식에 맞추기 위해 억지로 Controller를 추가했다. 그 결과 오히려 계층 구조가 더 복잡해지고, 코드의 흐름을 파악하기 어려워졌다. 그때 처음으로 "내가 왜 MVC를 쓰고 있는 거지?"라는 의문이 들었고, MVC 자체가 목적이 되어버린 설계에서 벗어나고자 블랙잭 미션부터는 과감히 MVC를 탈피했다.

 

그러자 오히려 객체 간의 의존 관계가 더 명확히 드러났고, SRP를 지키는 데에도 훨씬 유리해졌다. 이 경험을 통해 디자인 패턴은 목적이 아니라 수단이라는 점을 몸소 느꼈고, 이후 설계에서 책임을 분리에 더욱 집중할 수 있게 되었다.

 

2️⃣ 과연 내가 작성하는 코드에 의도가 담겨 있는가

값 객체, 상속, 조합... 모두 한 번쯤 좋다는 얘기를 듣고 도입했던 개념들이었다. 하지만 블랙잭 미션을 진행하면서 "내가 정말 이 개념들을 이해하고 사용하고 있는 걸까?", "그냥 좋다니까 무작정 쓰고 있는 건 아닐까?" 하는 의문이 들기 시작했다. MVC 구조에 대해 가졌던 고민도 결국 같은 맥락에서 비롯된 것이었다.

 

그 후부터는 단순히 좋다더라가 아니라, 값 객체를 왜 써야 하는지, 어떤 상황에서 상속보다 조합이 더 적절한지 등 각 개념을 선택하는 이유와 맥락을 분명히 하려는 태도를 갖게 되었다. 처음으로 코드 한 줄, 객체 하나에도 명확한 의도를 담기 위해 고민했던 미션이었다.

 

 

 

✅ 미션 4 - 장기

▶ PR

• Step 1: 장기 Step1 PR 링크
• Step 2: 장기 Step2 PR 링크

 

▶ 학습

🔽 키워드

• 인터페이스, 추상 클래스
• SOLID
• Optional
• DAO

🔽 블로그 정리

• [Java] 인터페이스, 추상 클래스, 일반 상속
• [OOP] SOLID
• [Java] Optional

 

▶ 고민했던 부분

1️⃣ 진짜 중복과 가짜 중복

기물 간 유사한 로직이 많다 보니, 중복을 줄이기 위한 여러 가지 리팩터링을 시도했다. 하지만 그 과정에서 의미 없는 계층 분리나 지나치게 추상화된 클래스들이 생겨났고, 오히려 코드의 구조가 복잡해지기도 했다. 또한, 겉보기에 비슷해 보이는 코드라도 중복 로직으로 추출했을 때 오히려 코드의 의미를 파악하기 어려워지는 경우도 있었다.

 

이런 경험을 하던 중, 크루와의 토론을 통해 어떤 코드를 수정할 때, 함께 수정해야 하는 코드가 있다면 그것은 진짜 중복이고, 그렇지 않다면 형태만 닮은 가짜 중복이라는 것을 알게 되었다.

 

2️⃣ 확장성을 어디까지 고려해야 할까

원래는 체스 미션이었지만, 예상치 못하게 장기 미션으로 변경되면서, 자연스럽게 확장성을 어디까지 고려해야 하는가에 대한 고민이 생겼다.

 

확장성을 고려하면 자연스럽게 SRP나 OCP 같은 설계 원칙들을 의식하게 된다. 장기에서 체스로 다시 변경되는 상황을 가정하고, 그에 따른 변경 범위를 최소화하고자 기존의 추상 클래스 기반 구조에서 조합 기반 구조로 리팩터링을 진행했다.

 

이 과정은 단순한 구조 변경을 넘어서, 내가 어떤 기준으로 코드를 설계하고 있는지 스스로 점검해 보는 계기가 되었다. 점점 내 코드 철학이 점차 자리를 잡아가는 느낌이 들었다.

 

 

🌱 유연성 강화 스터디

유연성 강화 스터디(유강스)는 소프트 스킬 역량을 키우기 위한 훈련의 일환으로, 자신이 키우고 싶은 소프트 스킬을 기반으로 한 주간의 목표를 세우고 실천한 뒤, 팀원들에게 피드백을 받는 형식으로 진행된다.

 

대학 시절부터 사람들 앞에서 대표로 나서 말해야 하는 순간이 많았다. 때로는 그 자리가 꽤 무겁고 중요한 자리이기도 했는데, 그럴 때마다 어김없이 긴장했고, 말을 매끄럽게 하지 못하는 나 자신을 보며 자신감을 잃기도 했다. 최근에도 누군가가 임기응변으로 유창하게 말하는 모습을 보며 부러움을 느끼곤 했다. 그래서 유강스를 진행한다고 들었을 때, 망설임 없이 나의 목표를 "말하기"로 정했다. 사실 유강스를 시작할 당시에는 큰 기대가 없었다. 이미 나의 단점을 충분히 마주했다고 생각했기 때문이다. 하지만 이 생각은 완전히 뒤집혔다. 뒷 내용은 조금 감성적인 내용이라, 유강스를 회고했던 레벨 1 글쓰기에서 확인해 주면 좋겠다...ㅎㅎ [레벨 1 글쓰기 링크]

 

정리하자면, 큰 기대 없이 시작한 활동이었지만, 내가 약하다고 생각했던 "말하기"에 대해 정말 많은 인사이트를 얻을 수 있었고, 약점을 팀원들과 함께 공유하며 더 돈독해졌다고 생각한다. 사람들과 협업이 중요한 개발자 모두에게 꼭 추천하고 싶은 활동이었다!

 

 

 

💬 레벨 1 인터뷰

제출한 레벨1 인터뷰이 문서

레벨 1의 마지막 즈음부터 약 80명의 백엔드 크루를 반으로 나누어, 이틀에 한 번씩 오프라인 출석을 하고 나머지 하루는 재택으로 운영되었다. 재택 너무 좋았다. 레벨 1 인터뷰는 무작위로 코치 한 명과 크루 5명 정도가 팀을 이루어 진행되었는데, 돌아가며 한 명은 인터뷰이, 한 명은 인터뷰어, 나머지는 옵저버 역할을 맡는 방식이었다. (팀마다 방식에 약간의 차이는 있었다.) 1차 목표는 레벨 1 동안 배웠던 내용을 되돌아보는 회고, 2차 목표는 모의 면접을 연습해 보는 것이라고 들었다. 솔직히 나는 "말하기"가 약점이라고 생각했기 때문에, 이 인터뷰 시간이 꽤 기대되었다.

 

아니나 다를까, 너무 좋았다. 레벨마다 계속하고 싶을 정도였다. 면접이라고 생각하고 참여했기 때문에, 인터뷰어로서 좋은 질문을 던지는 것도 쉽지 않았고, 인터뷰이로서도 긴장감 속에서 말하는 것 역시 결코 쉽지 않았다. 그럼에도 불구하고, 유강스를 통해 꾸준히 말하기에 집중해 온 노력의 결과가 이 순간에 잘 드러났다고 느꼈다. 예전보다 말하기 습관이 눈에 띄게 나아졌고, 좋은 피드백도 받을 수 있었다. 무엇보다도 레벨 1에서 배운 내용을 돌아보며, 정말 많이 성장했음을 체감할 수 있었던 뜻깊은 시간이었다.

 

 

 

🎬 마무리하며

정말 바빴다. 초반에는 이전 활동들이 의도치 않게 시기가 겹쳐서 개인적으로 많이 힘들었기도 했고, 후반에는 이사까지 겹쳐 정신없이 바빴다. 우테코를 했던 사람들로부터 정말 바쁘다는 이야기를 많이 들었는데, 정말 그러했다...🥹 학습량도 어마어마했고, 활동도 많았다.

 

그럼에도 불구하고, 이렇게 바쁜 와중에도 퀀텀 점프하듯 성장하고 있는 나 자신을 돌아보며 큰 보람을 느꼈다. 무엇보다도 이번 레벨 1에서 코드에 대한 내 기준이 조금씩 세워지고 있다는 점이 가장 크게 얻은 수확이었다. 또한, 하드 스킬뿐만 아니라 소프트 스킬 역시 꾸준히 의식하고 노력하고 있다는 게 문득 느껴지기도 했다. 그리고 우리 레벨 1 구구조와도 많이 친해졌는데, 이제 헤어지게 되니 아쉽기도 하다...

 

내일부터는 드디어 레벨 2가 시작된다. 방금 레벨 2 팀 배정 결과도 나왔다. 앞으로 어떤 공부, 어떤 활동, 어떤 인연들이 기다리고 있을지 벌써부터 기대된다! 그런데 내 방학 어디 갔을까