좋은 주니어 되기
2022년 12월, 처음 백엔드 개발자라는 타이틀을 달고 시작한 개발자로서의 커리어. 앞으로 근 3년은 단 한가지의 목표, 좋은 주니어 개발자 되기에 집중하며 살기로 결심했었다.
하지만 ‘좋은’ 이라는 수식어는 참 모호하고 추상적이다. 나는 좋은 개발자가 되고 싶었지만 누군가 내게 “좋은 개발자는 어떤 개발자라고 생각하세요?” 라는 질문을 던진다면 멋지게 대답할 자신은 없었다.
그러던 중 최근에 ‘육각형 개발자’라는 책을 추천받아 읽게 되었다. 책 내용에 공감되는 점도 많고, ‘좋은 시니어가 되기 위한 좋은 주니어의 자세’의 정의에 대해 대다수가 납득할 만한 기준에 맞게 정의내리고 있다는 느낌을 받았다.
그래서 현업 개발자가 되고 처음으로 진행해보는 이번 회고에서는 이 책에서 소개하는 기준들을 살펴보며 내가 어느 요소는 잘 충족해왔고 어느 요소는 상대적으로 아쉬웠는지, 육각형 개발자 + KPT 회고 식으로 진행해보고자 한다.
KPT 회고란? Keep, Problem, Try의 약자로 회고 내용을 유지할 점, 문제점, 시도해볼 점이라는 세 가지 관점으로 분류하여 진행하는 회고이다.
육각형 KPT 회고
‘육각형 개발자’ 책에서는 좋은 시니어 개발자로 성장하기 위해 갖춰야 할 역량을 육각형 모양으로 나타내고 있다. 올해 회고는 이 책에서 말하는 역량들을 내가 1년동안 얼마나 만족시켜왔는가를 중점으로 진행해보고자 한다.
회고에 앞서 본 글의 이해를 돕기 위해 현재 내가 일하고 있는 환경에 대해 먼저 소개하고자 한다.
내가 속해 있는 팀은 크게 아래의 3가지 프로젝트를 운영하고 있다.
- (내가 입사했을 당시 막 착수한) 신생 프로젝트
- 시작한지 좀 됐고, 요구사항이 들어오면 개선이 지속적으로 이루어지는 프로젝트
- 이미 완성 단계에 접어들어 큰 개선이나 코드변경 없이 운영되고 있는 프로젝트
아래 회고를 진행하며 각각을 1번, 2번, 3번 프로젝트라고 부를 것이다. 각각이 신생 프로젝트, 유지보수 프로젝트, 완결 프로젝트라고 이해해주시면 된다.
1. 구현 기술을 꾸준히 학습했는가?
사실 구현 기술은 1년차이니만큼 많은 욕심을 부렸던 부분이기도 하다.
나는 2번 프로젝트의 개선 작업에 참여하면서 기존 구현 기술을 학습하고, 1번 프로젝트의 설계 및 기능 개발 작업에 참여하면서 기존 구현 방향을 개선할 수 있는 포인트를 찾기 위해 새 기술들을 학습해나갔다. 이러한 과정을 뒤돌아보며 정리한 이번 섹션의 KPT는 아래와 같다.
Keep - 항상 더 나은 방법을 찾기 위해 힘썼다. 각 기술들의 장단점을 비교하고 프로젝트의 특성이나 현재 처한 상황에 맞게 적용하려 했고, 다른 기업 기술 블로그들을 참고해가며 새로운 해결책이나 기존 기술을 더 잘 이해하는 방법들을 알아내려고 노력했다.
Problem - 구현 기술 학습을 위해 양질의 자료를 탐색하는 능력이 많이 부족했다. (공식 문서를 읽는 일은 여전히 어렵다.) 또한, 여러 기술을 학습하다보니 각각의 기술에 대한 깊은 이해를 갖추는 데에 시간을 많이 할애하지 못했다는 생각이 든다.
Try - 공식 문서 리딩 스터디같은 모임에 참여해보자. 그리고 내가 학습한 사실이나 구현한 내용을 발표하는 자리를 많이 만들어보자. (내가 알고 있는 내용을 잘 설명하려면 기술에 대한 탄탄한 이해가 뒷받침되어야 하기 때문이다. 또한, 질문/피드백을 받으며 몰랐던 부분을 알게 될 수도 있다.)
2. SW의 품질을 고려하고, 코드를 잘 이해하려고 했는가?
SW의 품질과 코드 이해는 최근 들어 많은 신경을 쓰게 된 부분이다. 1번 신생 프로젝트가 빠르게 발전하며 규모를 키웠고, 설계/구현에 많은 가담을 한 과거의 나(특징: 미움)는 이 부분을 많이 고려하지 못했기 때문이다.
지금의 유지보수성과 가독성이 좋은 코드를 작성하는 것이 발빠르게 변화하는 SW 산업 시장에서 얼마나 중요한 요소인지 조금은 깨달은 것 같다. 1년간 이 부분을 얼마나 고려해왔는지를 되짚으며 정리한 이번 섹션의 KPT는 아래와 같다.
Keep - 새 기능을 구현할 때 요구사항을 분석하며 ‘추후 이런 방향으로 확장될 수 있는가?’를 많이 고민해보는 편이다. 변경에 대한 유연한 대응을 항상 고려하며 구현하는 자세를 앞으로도 유지해야 한다.
Problem - 몇몇 기능 추가 요구에 대응하는 과정에서는 기능의 규모가 작음에도 얽힌 코드가 많아 생각보다 시간이 지연되는 일도 있었고, 예상치 못한 사이드 이펙트를 맞닥뜨려 해결하느라 진땀을 뺀 경험이 있었다.
Try - 클린 코드, 클린 아키텍처 등 관련 도서들을 읽으며 이 부분의 역량을 키워나가고 싶다.
3. 응집도와 결합도를 고려해 모듈을 잘 분리했는가?
결합도가 낮고 응집도가 높은 코드는 변화의 범위와 변화가 미치는 영향을 최소화할 수 있다.
하지만 이들의 정의와 중요성을 이해하는 것과 별개로, 실제 코드 내에서 이상적인 응집도/결합도를 유지하는 것은 쉽지 않은 일이라고 생각한다. 내가 얼마나 응집도와 결합도를 고려해 코드를 만들어왔는가를 고려하며 정리한 이번 섹션의 KPT는 아래와 같다.
Keep - 모듈 내에서 전혀 연관 없는 동작을 하고 있다고 느끼거나, 관련 없는 다른 모듈과 너무 강결합이 발생했다고 느낄 때에는 착실히 다른 클래스로 분리하고 있긴 하다.
Problem - 시스템의 규모가 커지다보니 응집도/결합도 보장을 위한 분리가 너무 많은 객체를 만들고 때로는 중복된 코드를 만드는 원인이 되기도 함을 느낀다. 단순 분리가 아닌 구조적 개선으로 이 문제를 풀어나가야 할 것 같은데, 여전히 해결에 난항을 겪고 있다.
Try - 이벤트 기반(Event-Driven) 아키텍처와 도메인 기반(Domain-Driven) 아키텍처에 대해 학습해보자. 이들이 Problem의 해결책이 될 수 있을지는 먼저 학습해보고 결정할 사안인 것 같다.
4. 리팩토링과 테스트를 잘 실천했는가?
리팩토링과 테스트는 SW의 안정성을 위한 중요한 요소다. 두 가지 모두 기능에 영향을 미치는 요소가 아니기 때문에 등한시하기 쉽지만, 장기적으로 봤을 때 생산성과 안정성을 높이기 위해 꼭 필요한 요소라고 생각한다.
하지만 두 가지 모두 핵심은 잘 알고 해야 도움이 된다라고 생각한다. 내가 얼마나 리팩토링과 테스트의 원칙을 잘 준수했는지를 되돌아보며 정리한 이번 섹션의 KPT는 아래와 같다.
Keep - 가독성, 유지보수성을 고려하여 리팩토링을 해 왔다. 작성한 코드에 대한 테스트 코드도 함께 push할 수 있도록 노력해왔다.
Problem - 팀 내에서 단위 테스트 독립성의 경계가 모호해지기 시작했다. 점점 테스트 수행 시간이 늘어나기 시작했고, 이제 테스트가 끝나길 기다리는 시간이 생산성에 악영향을 미치기 시작했다고 느껴진다.
Try - 테스트 코드 정형화를 위한 팀 단위의 Rule을 만들어보고자 한다. 이를 위해서는 나부터가 타당한 테스트 규칙을 정립해야 할 것 같다. JUnit in action을 읽어보고, 다른 팀/기업의 테스트 Rule을 들을 수 있는 자리를 마련해보자.
5. 아키텍처와 패턴을 잘 학습하고 적용했는가?
설계는 어렵다. 설계는 정말 아는 만큼 보인다는 말이 맞는 것 같다. 나는 아직 아는 것도, 경험도 많지 않아 설계가 정말 어렵게 다가오는 것 같다. 반대로 말하자면, 많은 설계 패턴을 학습하고 적용해보다보면 이러한 어려움이 해결될 것이라고 기대할 수도 있다는 것이다.
우선은 올해에 설계에 관여한 내용들을 정리해보기로 하며, 이번 섹션의 KPT는 아래와 같다.
Keep - 설계를 할 일이 있으면 최대한 적극적으로 내 일로 만들거나 관여했다. 경험이 제일 중요하다고 생각해 앞으로도 설계에 관여할 일을 최대한 많이 만들어보는 것이 좋겠다.
Problem - 막상 관여는 많이 했지만 많은 시도를 해보지는 못했다고 본다. 경험과 학습이 조화를 이뤄야 하는데, 아키텍처의 학습 면에 시간을 많이 할애하지 못했다. 그 때문인지 아직 설계를 마치고 구현을 하다가 다시 설계를 수정하러 뒤돌아가는 일이 빈번하게 발생하고 있다.
Try - 설계에는 정답이 없지만 상황에 따른 다양한 Best-Practice가 존재한다. 완성도가 높은 오픈소스 프로젝트들을 참고하거나 설계 관련 강연이 있는 컨퍼런스/세미나 등에 활발하게 참여하며 이러한 Best-Practice를 접할 수 있는 기회를 많이 만들어보자.
6. 업무 관리, 정리와 공유, 리드와 팔로우의 중요성을 숙지하고 잘 달성했는가?
이 부분은 1번 프로젝트가 고도화되며 많은 신경을 쓰게 된 부분이다.
보통 업무는 아래와 같은 내용을 담은 이슈로 할당되게 된다.
"현재 AB로 동작하고 있는 기능에 어떠한 이유로 C기능이 필요하게 되었다. (As-is)
이 이슈의 결과로 이제 ABC한 기능이 수행될 수 있어야 한다. (To-be)"
이슈를 받고 나면 TODO LIST를 정리하고, 우선순위를 정하고, 구현하고, 구현이 완료되면 배포를 내보낸다. 물론 모든 이슈가 이렇게 별다른 예외 없이 하나의 길을 타고 쭉 이어져 끝날 수도 있겠지만, 중간에 문제가 생기기도 하고 기획이 변경되기도 하고 다른 더 급한 이슈가 생겨 기존에 진행하던 이슈를 뒤로 미루기도 하며 얼렁뚱땅 파란만장한 여러 갈래 길이 펼쳐진다.
이러한 상황을 잘 컨트롤하기 위한 업무 관리, 정리와 공유 또한 일 잘 하는 사람이 되기 위한 중요한 역량이다. 올해에 이들을 얼마나 잘 달성했는지를 정리한 이번 섹션의 KPT는 아래와 같다.
Keep - 질문하고 공유하는 것을 주저하지 않았다. 잘못 이해하거나 잘못 이해시키는 일을 최소화하고 싶었다. 이러한 자세는 앞으로도 쭉 유지해야 한다고 생각한다.
Problem - 정리를 하지 않는 것은 아니지만, ‘잘’ 정리하는 능력이 부족했다. 진행한 이슈가 많아질수록 정리한 내용도 많아져 이전에 진행했던 내용을 확인하기 위해 이전 자료를 탐색하고 복기하는 데에 더 오랜 시간이 걸리기 시작했다.
Try - 정리한 내용을 타인에게 공유할 일을 많이 만들어보자. 공유를 하고 피드백을 받아볼 수 있는 자리를 많이 마련해보자.
Try로 보는 내년 목표
무려 6가지 요소에 대한 KPT 회고를 수행했지만, Try가 바라보는 방향은 얼추 비슷하다.
먼저, 활발한 소통이다. 다른 개발자들의 이야기를 들으며 배우고, 내 이야기를 공유해 피드백을 받으며 몰랐던/미숙한 부분을 채워나가고 싶다. 이를 위해 스터디, 커피챗, 세미나 등에 활발히 참여해보는 것이 좋겠다.
그리고, 독서다. 테스트, 아키텍처, 클린코드, DB 등 아직 깊이 학습하고 싶은 기법이나 도구들이 정말 많다. 책이나 강의, 공식문서 등을 집중해서 읽는 습관을 기르고 싶다. 2023년에는 짧고 읽기 편하다는 이유에서인지 주로 기술 블로그의 글만 많이 읽었기에, 2024년에는 좀 더 긴 호흡으로 학습할 수 있는 자세를 갖추고자 한다.
그런고로 2024년 내가 집중할 키워드는 네트워킹, 개발 서적 꾸준히 읽기 2가지로 정리할 수 있다. 더 많은 목표를 세우면 자칫 (가장 중요한) 회사 업무에 소홀해질 수도 있다고 생각하기 때문에, 퇴근 후와 주말 시간을 이용해 위의 2가지를 잘 달성하고자 노력해봐야겠다.