레벨 2 회고

 

벌써 레벨 2가 끝나고 방학이 왔다. 이번에는 레벨 1과 다르게 미션마다 회고를 하지 않고 나의 레벨 2에 대한 회고를 작성해보려고 한다.

 

 

 

 

레벨 1과 레벨 2의 다른 점

레벨 1 때 객체지향 공부가 너무 재밌었다.

 

미션마다 새로운 것들을 많이 경험하고, 크루원들마다 구현한 코드가 다 달라서 코드를 보는 것이 흥미로웠다.

 

옛날에 정리되지 않았던 것들이 하나둘씩 정리되는 느낌이 너무 좋았다. 틀 없이 자유분방하게 뛰어다니는 코드를 작성하고, 보고, 리뷰를 받았었다.

 

하지만 레벨 2에서 스프링 부트를 만나면서, 레벨 1 때 배운 객체지향과 다르게 '틀'이라는 것이 생긴 느낌이었다.

 

그 '틀'이라는 것을 누가 만든 지는 모르겠지만, 나도 모르게 그 틀 안에서 코드를 작성하고 있었고, 크루원들도 마찬가지였다. 그래서 웹 자동차 경주, 쇼핑 장바구니 미션과 같이 스프링 부트의 기본 기능들을 익히는 미션에서 "이게 객체지향인가? 아닌 것 같은데,,"라는 생각이 매번, 매일 들었다.

 

하지만 이전에 스프링을 공부했던 경험 덕분에 이런 생각을 빨리 깨부술 수 있었다.

 

"지금은 스프링 기본 기능들을 익히는 미션이니까 대부분 간단한 기능 구현이었고, 객체지향이 있기 어렵다"라고 말이다.

그리고 "'프레임워크'라는 '틀'을 사용했기 때문에 '틀'이 존재하는 게 당연한 게 아닌가?"라는 얘기를 네오와 했었다.

 

그래서 이때는 옛날에 고민했지만 아직까지 답을 내리지 못한 것들에 대해 리뷰어에게 질문 폭탄들을 남겼다. "응답에 대한 DTO는 어디에서 변환하는 게 좋나요?", "서비스에서 서비스를 참조할까요 DAO(Repository)를 참조할까요?" 또는 기존에 궁금했던 스프링 내부 동작 과정을 디버깅하며 하나하나 살펴보았다.

 

 

이때까지만 해도 재밌었는데 어느 날 스프링 내부 동작 과정을 며칠 동안 보고 나서 포스팅을 하는데 아래와 같은 생각이 들었다.

"나는 왜  스프링 내부 동작을 보고 있었던 거지? 나는 스프링 개발자 할 것도 아닌데 말이야"

 

물론 내부 동작을 보는 게 나중을 위해선 좋은 일이다.

하지만 현재 나는 지금 그것보다 더 많은 것들을 경험해야 하는 시기이다. 깊이가 아닌 넓이가 중요한 시기라고 생각한다.

 

그래서 우연히 내 손에 들어온 근로 '프롤로그'를 나의 경험에 대한 밑거름으로 사용하려고 다짐했다.

 

현재 운영되고 있고, 고정 사용자가 있는 프로젝트가 나에게 오는 것은 정말 흔치 않은 기회라고 생각한다.

운영 및 유지보수도 할 수 있으며, 내가 문제를 만들면 만들수록 나에게 더 많은 경험들이 되어줄 것이다. 그래서 현재는 모니터링 시스템을 구축해보려고 한다.

 

 

 

 

실패를 통한 성장

대망의 지하철 미션이었다. 이전 체스 회고에서 설계 실패를 겪었던 내가 어떻게 성장했는지 보여줄 수 있는 미션이었다.

 

미션 시작 전에 먼저 페어에게 설득과 이해를 구했다.

 

“우리가 도메인을 탄탄하게 만들면 DB나 API 설계는 어떻게든 끼워 맞출 수 있다. 지금은 스프링에 대한 테스트보다는 도메인 단위 테스트를 매우 매우 자세히 작성하여 탄탄한 도메인을 만들면 성공적으로 미션을 마무리할 수 있다”라고 말이다.

 

또한, 이전 체스에서의 제일 큰 문제점이 설계에 대해 너무 많은 시간을 쏟았기 때문에 이번 미션에서는 설계를 하고 코드 작성해 보고, 다시 설계 엎고 코드를 작성했다.

 

페어인 로이가 허락했기에 위와 같은 과정으로 미션을 진행했고, 미션 제출날 성공적으로 PR을 낼 수 있었다.

 

 

이때 로이와 얘기를 하다가 공통적으로 느낀 게 있다.

 

 

도메인 단위 테스트 진짜 매우매우매우매우매우매우매우 중요한 것 같다,,,

 

 

그 이유는 로직을 추가할 때마다 테스트 코드를 돌리면서 기존 코드가 무엇이 안되는지 빠르게 파악하여 수정할 수 있었고, 매번 애플리케이션을 돌리지 않아서 시간을 매우 줄일 수 있었다.

일단 TDD든 뭐든 간에 내가 무엇을 검증하고 싶은지에 대해 생각하면서 검증할 결과를 먼저 작성하고, 코드 작성한 뒤에 제대로 수행되면 된 거다. 이게 개발 속도가 왜 빠르다고 하는지 이해할 수 있었다.

쉬운 요구사항에서는 테스트 작성 시간 > 기능 구현 시간이었지만, 복잡한 요구사항일수록 기능 구현 시간 > 테스트 작성 시간이었고, 수정하는 것 또한 마찬가지였다. 그래서 테스트가 숙제처럼 생각되지 않고, 무조건 작성해야 하는 것이었다. 테스트가 있어야 기능 구현 및 수정하는 시간이 조금이나마 줄어들기 때문에,,

위와 같은 프로세스를 통해 개발하다 보니 도메인이 풍부해져서 다른 크루원들이 말하는 “왜 나는 서비스가 이렇게 뚱뚱하지?”라는 느낌을 받지 않았다. 테스트 덕분인지 아닌지는 잘 모르겠지만 나는 풍부한 도메인을 가질 수 있었다.

 

 

첫 스터디

우테코를 시작하면서 처음으로 스터디를 운영해 보았다.

 

거대한 것은 아니었고, 1차, 2차 리뷰를 할 때마다 모여서 자신의 미션과 리뷰에 관해서 얘기를 하는 의견을 나누는 스터디였다.

이번 스터디에서 가장 중요한 것은 부담을 가지지 않는 것이며, 자연스러운 토의를 하고 싶었다. 그래서 무엇을 얘기할지 준비하기보다는 자신의 리뷰를 정리하며 같이 말하고 싶은 것들을 가져왔고, 양질의 주제를 위해서 억지로 주제를 꺼내지 않도록 30초 동안 침묵이 유지되면 그날 스터디는 끝을 냈다. 마찬가지로 스터디 시간도 정하지 않았다. 30분이든 10분이든 1시간이든 상관없었다.

단지 크루원들과 자유로운 얘기를 하고 싶은 스터디를 만들고 싶었다.

스터디를 하다가 규칙을 더 엄격하게 했어야 했나?라는 아쉬움도 있었지만 그럭저럭 괜찮았던 것 같다.

 

 

 

 

여우가 레벨 인터뷰 끝나고 나서 슬랙에서 위와 같은 얘기를 하니 나름 뿌듯했다. 그래서 괜찮았던 것 같기도 하고?

 

 

레벨 3에서의 목표

 

자바, 스프링에 대한 기본 지식을 얻는 미션들이 끝났다.

 

지금부터는 협업 프로젝트 미션 시작이다. 레벨 3가 곧 시작하는데, 제일 이루고 싶은 목표는 하루마다 일기를 작성하는 것이다. 그리고 일주일마다 회고를 작성하는 것,,? 거창한 게 아닌 하루에 한 문장이라도 무엇을 했는지 적어보고, 일주일을 마무리하는 주말에 그 글들을 모아서 일주일 간단한 회고록을 작성해보려고 한다.

 

이번 주 프로젝트 회의에서는 무엇을 했고, 좋았던 점, 반성해야 할 점 등을 적으면서 더 발전하기 위함이다.

 

 

레벨 3가 마무리되고, 이 글을 다시 읽을 때 목표를 성공적으로 이뤘으면 좋겠다!!