이번주 소감을 한 마디로 정리하자면 진짜 단전에서 우러나올 정도로 너무 재밌었다. 매일매일 이런 문제만 풀고 싶다. 특히, 지난 3주간 연마해온 설계 실력을 제대로 발휘한 느낌이었다. 물론 실제 구현에 들어가면 매번 머릿속에 생각한 이상적인 설계와 다르게 흘러가긴 하지만, 그럼에도 내가 프리코스 기간 동안 찾은 설계법을 이용했을 땐 세밀한 부분을 제외하곤 어느 정도 설계대로 구현한 것 같다. 어떤 모델들이 합쳐지거나 분화하긴 하지만 그렇다고 그 역할이 없어지는 건 아니기 때문이다.

이번 주차엔 마지막 주차라 그런지 그동안 배운 것들을 모두 사용하고 싶은 마음이 컸는데, 실제 과제에서 이를 실현할 수 있어 특히 좋았다. 프리코스 기간 중 내가 배운 내용을 마지막 주차에 펼쳐간 과정을 중심으로 소감을 작성해보겠다.

현업의 요구사항을 마주한 듯 대응해보았다 (with 일잘하는 개발자의 특징은 무엇일까?)

우테코에서 경험하고 싶었던 가장 큰 부분인 현장 중심의 교육을 이번 마지막 주차에서 특히 크게 실감할 수 있었다. 어딘가에서 일 잘하는 개발자 특징으로 “요구사항을 정리한다”라고 들어서, 우선 나도 요구사항을 차근히 문서화했다. 고등학교 때 요약 노트를 만들듯 나만 알아볼 수 있는 단어를 사용하진 않았지만, 나의 언어와 나의 사고과정으로 요구사항을 정리했다. 여기서 언어는 용어보단, 문장과 문단의 흐름을 말한다. 나열식 요구사항을 개발할 영역별로 분리하고, 문장을 보다 간결하고 이해하기 쉽게 바꾸는 것이다.

나는 큰 흐름으로 이벤트 설명과 개발 요청 사항을 분류했다. 이벤트 설명으론 이벤트의 목표와 내역, 특이사항, 메뉴판, 고객에게 안내할 주의사항을 정리해 두었고, 개발 요청사항으론 프로그램이 포함할 기능 위주로 정리해두었다. 즉, 기획 문서와 기능 요구 사항을 보고 쉽게 분리해둔 것이다. 이를 Readme의 부록 A에 정리해두었다. 그리고 이 부분은 실제로 구현을 하면서 굉장히 큰 도움이 되었다. 요구사항을 정리했을 때 개발 효율이 올라감을 체감했고 실제 실무에서도 이는 필수적일 거라 생각했다.

나의 설계법을 온전히 검증했다

내가 2주차부터 밀고 나가고 있는 설계법이 있다. 커뮤니티에도 정리해 공유해 29개의 나름의 소소한 좋아요를 받으며 검증 받아간 설계법인데, 바로 스토리텔링식 설계다. 이번주엔 이 설계 과정을 사용하며 데이터가 아닌 행동 위주로 사고하기에도 초점을 맞춰나갔다. 이번 요구사항은 보자마자 앱 화면이 떠올랐다. 따라서, 먼저 스토리텔링식 설계를 마친 뒤 스토리에 맞춘 가상의 그림을 그렸다. 이가 결국 후에 앱 화면과 연계되는 것이다. 가상의 그림엔 고객과 콜센터, 콜센터가 들고 있는 예약 장부가 존재한다.

예약장부를 펼쳐보면 날짜, 예약자, 메뉴판, 이벤트목록이 나와있는데 여기서 메뉴판의 경우 김밥천국과 같이 빈 메뉴판에 수량을 표기하는 식을 채택했다. 내가 그린 그림은 Readme의 부록 B.1에 정리해두었다. 스토리를 그림으로까지 그리니 동화책을 만든단 느낌이 들어 재밌었다. 물론 재미만 주고 끝나면 안되고, 이를 실제로 화면 설계서라 생각하고 구현을 시작했다. 그림까지 함께 보니, 구현 시 기존의 스토리텔링식 설계를 200% 활용할 수 있었다.

코드 리뷰를 통해 피드백 받았던 부분들을 적용했다

코드 리뷰의 긍정적인 효과 중 하나는 다음번에 비슷한 실수를 하지 않게 돕는다는 점이 있다. 그리고 이를 이번 프리코스 4주간 계속해 실감해와 마지막 주차에 그 꽃을 피울 수 있었다. 이전 코드들에서 질문받았던 부분들이 하나하나 떠올랐고 이번 주차 코드를 작성할 땐 이를 자연스럽게 고려해 짜게 되었다. 물론 여전히 부족한 부분들은 있겠지만, 적어도 1주차의 나보단 성장했다고 확신할 수 있다.

예를 들어, 재귀 호출을 사용자가 컨트롤하게 하면 stackoverflowerror가 날 수 있다는 점과, static을 붙일지 결정할 때 인스턴스화 뿐만 아니라 동시성을 고려해보면 좋다는 점 등이 귓가에 스치듯 떠올랐고 적어도 저번주보단 더 질좋은 코드를 만들어낼 수 있었다.

테스트코드를 쓰는 습관이 생겼다

첫 주차만 해도 테스트 코드의 효용성을 몰랐다. 이번 주차에 특히나 테스트 코드를 딱 한 곳에서 미뤘다가 나중에 고치는 데 시간이 배로 걸리는 걸 직접 경험하기도 했고, 4주간 느낀 테스트 코드가 주는 안정감을 통해 이젠 테스트코드를 선호하는 개발자가 되었다. 특히 현업에 가면 끊임없이 요구사항이 변할 텐데, 이때 테스트코드 작성 유무가 업무 효율성에 어떻게 영향을 미칠 지 생각해볼 수 있었다. 사실 이전에 토이프로젝트를 하면선, 테스트코드를 작성하는데 더 시간이 걸릴 거란 착각에 빠진 적도 있었다. 하지만, 이번 우테코 프리코스 과정 속에선 처음엔 요구사항으로 인한 시작이었지만,테스트코드를 작성하는 게 전체 코드 작성 시간을 단축시켜준단 걸 실감했기에 테스트코드의 효용을 아는 개발자가 될 수 있었다.

이번주와 한 달을 정리해보자면

이번 주차의 핵심은 객체지향적 설계였다. 프리코스 4주간 가장 많이 배워간 걸 묻는다면 물론 코드 작성과 코드 리뷰 과정 속에 얻은 지식들도 있겠지만, 설계적인 측면이 가장 컸다고 답하고 싶다. 실제로 객체지향적인 흐름에 대해 많이 고민해볼 수 있었고 아직 부족하지만, 조금씩 다가가고 있다.

이번 주차엔 아쉽게도 tdd를 완벽히 적용하진 못했지만, 적어도 그 의미를 조금은 표방했다고 말할 수 있을 거 같다. 그 이유는, 각각의 단위 테스트를 작성해나가며 어떨 땐 테스트코드를 먼저 작성해두고 기능을 구현하는 게 더 편해 테스트를 먼저 작성한 적이 꽤 있기 때문이다. 앞으로 tdd 에 대해 더 공부해 나가고 싶단 생각이 들었다.

앞으로를 계획하자면

2, 3주차 소감에서도 언급했지만, 우테코 방식으로 자기주도 학습을 이어나가고 싶다. 개발자 영위엔 물론 동반 성장도 있지만, 그 기반엔 자기주도 학습 능력이 필요하다 생각한다. 그리고 이를 길러나가려면 딥다이브가 필요하고, 나는 이번 우테코 4주간의 과제에서 딥다이브를 어떻게 해야 하는지 경험해나갈 수 있었다. 따라서 우테코가 끝나고도 이 방식에 힘 입어 스스로 학습을 이어나가고 싶다. 이 과정에서 책도 읽고, 딥다이브한 프로젝트들도 경험하며 확장적 사고가 가능한 개발자가 되고 싶다. 그리고 이 과정이 동반되어야 실무에서도 함께 일하기 좋은 개발자가 되리라 생각한다.