2023년 4월 4주차 주간회고

 
가시적인 성과와 구체적인 보완점을 느꼈던 4월 4주가 마무리되었다.
 

새로운 과제 테스트를 시작했다.

지난 주말, 1분기를 돌아보면서 나는 아직 한 귀퉁이가 채워지지 않았다고 판단했고, 부족한 한 귀퉁이를 마저 채우기 위해 1-3주 가량 새로운 프로젝트를 하면서 그 부분들을 집중적으로 보완해야겠다고 생각하고 있었다.
 
당시 기존에 지원해뒀던 기업들에서 특별한 일이 일어나지 않는 한 새로운 프로젝트를 하는 동안은 취업활동을 잠시 중단할 계획이었다. 생각보다 장기전으로 갈 수도 있겠다 싶었기에, 지금처럼 애매한 상태에서 계속 헛다리를 짚으면서 셀프로 자신감을 떨어뜨리기보다는 애매하게 알고 있던 것들을 하나씩 확실하게 짚고 가면서 자신감을 다시 찾을 계획이었다.
 
특별한 일이 일어난다는 건 사실상 기적과 같다고 생각했다. 보통 일어나지 않기에 기적이라고 부르는.
 
그런데 며칠 뒤,
 
 

 
기적이 일어났다.
 
 
 
 
 
 

감사합니다 주여...

 
잠시 기존의 계획을 뒤로 늦추고 2주일 동안은 과제 테스트에 집중하게 되었다.
 
과제 테스트를 하는 것 자체도 어찌보면 하나의 웹 애플리케이션을 개발하는 것이기에, 기존 포트폴리오에서 부족했다고 느꼈던 부분들을 개선하거나, 새롭게 공부하거나 알게 된 것들을 적용해보는 것을 오히려 과제 테스트에서 실전적으로 시도해보게 되었다. 기술 요구사항들 중 실제로 사용해보지 않은 것들이 몇 가지 있기 때문에 해당 기술들에 대해서도 공부하고 과제에 적용해볼 예정이다.
 

적용해보고 있는 기술 혹은 패턴

- Nested Test
- 빌더 패턴
- Filter를 이용한 인가
- QueryDSL
 

적용을 계획하고 있는 기술 및 프로그래밍 언어

- Docker Compose
- Flyway
- Testcontainer
- Kotlin
 
이 과정에서 과제 테스트를 수행하는 것만큼이나 중요하게 인지하고 있는 부분은, 기존의 프로젝트에서 사용했던 기술이나 패턴과 다소 다른 방식을 과제 테스트에 적용해보면서 느껴지는 다른 점들을 살펴보고, 그러한 차이점들을 구체적인 맥락으로 정리해 기록하는 과정을 수행해야 한다는 것이다.


 

프로젝트를 통해 보완해야 할 지점이 어디인지 좀 더 구체적으로 알게 되었다.

링크드인을 통해 한 기업의 CTO님께 커피챗을 부탁드리는 메시지를 드렸었었는데, 메시지를 좋게 봐주셨던 것인지 해당 기업의 3년차 정도 되시는 백엔드 개발자분과 커피챗을 나눌 기회를 가질 수 있었다. 화요일에 사옥을 방문해 커피챗을 진행했고, 이력서에 대한 피드백을 위주로 취업 방향성에 대하여 이야기를 나눴다. 우연히도 같은 나이의 대학 동문이었고, 그래서인지 부담을 다소 내려놓고 좀 더 편안한 분위기에서 이야기를 주고받았던 것 같다.
 
그 자리에서 최근 고민하고 있었던 '다들 이력서가 좋다고는 하는데, 도대체 어떤 부분이 부족한 것인지'에 대한 피드백을 처음으로 구체적으로 받을 수 있었고, 이를 바탕으로 다음 이력서에서는 어떤 점을 보완해야 할 것인지 구체적으로 짚어보게 되었다.

 

사용하고 있는 기술들을 '왜 사용했는지' 고민한 흔적을 드러낼 수 있어야 한다.

수정할 다음 이력서에서 가장 신경쓰고자 하는 부분이다.
 
지금 사용하고 있는 프로젝트 소개서를 만들기가 굉장히 힘들었었다. 프로젝트에 사용한 기술들은 '당연히 그렇게 써야 하는 것 아냐?'라고 생각하면서 썼던 것들이 많았고, 프로젝트를 진행하면서 했던 고민들은 '배운대로 하지 않아서 그런 것인지 잘못된 구조로 코드를 작성하고 있는 것 같다'는 느낌의 고민들이 많았다. 그래서 '다른 기술들 대비 어떤 이점이 있고 이런 결과가 있었다'와 같은 내용들은 아무리 머리를 굴리고 고민을 해도 쉽게 나오지 않았다. 그래도 어떻게든 내가 했던 것들을 보여줘야 했기 때문에, 당연한 이야기라도 써가면서 내용을 채웠었다.
 

그 지점이 정확하게 걸렸다.
 
다른 개발자분들이 같이 이력서를 보면서 냈던 의견들 중의 하나로 '한 건 많은데, 사용한 기술들에 대해서 고민하면서 썼다고 확신할 수 있을까?'가 있었다고 했다. 그런 고민을 했는지를 중요하게 보는 이유는, 그 기술에서 발생할 수 있는 문제를 얼마나 알 수 있는가, 문제가 생겼을 때 해결할 수 있는 능력이 있는가를 판별해야 하기 때문이라고 했다. 아쉽게도 지금의 프로젝트 소개서에서는 당연한 이야기인 '방식' 그 자체가 쓰여있었기 때문에 기술이나 문제에 대한 고민이 깊게 드러나있지 않아 보였고, 그로 인해 이력서를 보는 개발자들이 확신을 갖기 어려울 것이라는 피드백을 들었다.
 
포트폴리오에서 가장 자신있게 내세우고자 하는 '테스트 코드'에 대해서도 마찬가지. 개발자분께 드린 이력서는 첫 페이지의 내용을 약간 수정한 상태였는데, 이런 내용이 들어가 있었다. (이 이력서는 아직 지원에 사용하지 않았다.)
 

테스트 코드와 객체지향의 중요성을 인식하는 개발자입니다.

포트폴리오 프로젝트 백엔드 단위 테스트 86% 커버리지,
프론트엔드 단위 테스트 93% 커버리지를 달성한 경험이 있습니다.

 
 
이 부분에 대한 피드백으로는 긍정적인 부분, 고민해야 할 부분이 모두 있었다. 우선 '테스트 코드'가 있다는 것 자체만으로도 개발자들이 프로젝트의 코드를 확인해보고 싶다는 생각을 갖게 된다는 것을 확인했다. 개발자분이 레포지토리에 직접 들어가 궁금한 부분의 소스코드를 직접 확인하는 모습을 눈앞에서 확인했고, 처음으로 '다른 사람들이 레포지토리에 처음 들어온 순간부터 관심 있을 가장 하부의 소스코드까지 어떻게 찾아 들어가게 될까?'에 대해 신경쓸 수 있어야겠다는 생각을 갖게 되었다.

고민해야 할 부분은 '높은 테스트 커버리지'가 반드시 평가에 유리하게 작용하지만은 않는다는 것이었다. 해당 문구에 대한 개발자분들의 의견 중 하나로 '필요하지 않은 테스트까지 굳이 하고 있을 것 같다'는 의견이 있었음을 들었다. 즉, 정말 필요한 테스트가 아닌 테스트를 위한 테스트를 작성하고 있을 가능성이 있을 것 같이 느껴지기도 한다는 이야기였다.
 
수치를 이용한 성과 증명을 이전에도 조금 시도해보면서 이에 대한 피드백을 구했던 적이 있었는데, '굳이'의 느낌이 드는 수치를 단순 나열하는 것으로는 이야기할 거리가 그다지 있기 어려울 것이라는 피드백을 들었던 적이 있었다. 수치를 이용한 증명은 '그 방식을 사용한 의도가 명확히 드러날 때' 빛을 발할 수 있을 것임을 느끼게 되었다.
 
 
 

무엇을 할 것인가?

다음 주차까지는 일단은 주어진 과제 테스트를 수행하는 데 집중할 계획이다. 구체적인 플랜은 다음과 같다.
 
- 5월 2-3일까지: 모든 기능 구현, 단위 테스트를 통한 동작 검증
- 5월 5-6일까지: 추가적인 기술 적용 및 API 문서화. 이때까지 모든 요구사항을 충족하는 Java 기반으로 동작하는 서버 애플리케이션을 구성하는 것을 목표하고 있다.
- 이후 시간 여유가 있을 경우: Kotlin으로 마이그레이션 시도
 
 
과제 테스트를 제출한 이후에는 상황에 따라 달라질 수는 있겠지만, 프로젝트와 관련하여 세우고 있는 전반적인 방향성은 다음과 같다.
 
1. '내일회' 클론 코딩 프로젝트를 1-2주 가량 진행하면서, 사용하고 있었던 개념들에 대한 자세한 학습
2. SMASH 프로젝트 리팩터링: 아키텍처나 도메인에 맞게 동작을 리팩터링하고 미완성된 기능을 추가할 것인지, 종목 도메인을 '야구'로 한정하고, 이에 특화된 요구사항을 다시 도출하는 것부터 리팩터링을 수행할 것인지에 대한 고민이 있다.