비개발 직군에서도 마찬가지였지만, 개발자로 처음 일하기 시작했을 때 난 어떤 개발자가 될 수 있을지를 고민했었다. 사실 어떤 개발자가 되고 싶다는 말은 다소 추상적이며 큰 그림에 가깝지만, 그려나가는 과정은 결국 구체적인 액션을 통해 이루어진다고 생각한다. 주니어 레벨에서는 그런 구체적인 액션을 하나하나 사고하기엔 어려움이 있기 때문에 그 어려움에 봉착했을 때 이런 류의 가이드북이 도움이 되는 것 같다.
이런 가이드북 형태의 도서는 시중에 꽤 많지만, 사실 경력이 1~2년 정도일 때는 눈앞의 업무에 몰두하느라 큰 그림을 그려보지 못했던 것 같다. 현재에도 아직 배울 거 투성이지만 과거의 나보다는 조금 더 경험이 생긴 시점에서 큰 그림을 그려보고 싶던 차였는데, 공교롭게 적당한 시기에 이 책을 읽게 되었다는 생각이 든다.
이 책은 크게 6부로 나뉘어 있는데, 구체적으로 보자면 ‘개발자 커리어의 기본 사항’, ‘유능한 소프트웨어 개발자’, ‘다재다능한 시니어 엔지니어’, ‘실용주의 테크리드’, ‘롤모델로서의 스태프 및 수석 엔지니어’, ‘결론’ 이렇게 구성되어 있다. 그 안에서 각 파트에 맞게 다양한 섹션으로 나뉘어 있는데, 예컨대 ‘업무를 완수하는 개발자’, ‘소프트웨어 아키텍처’, ‘프로젝트 관리’, ‘비즈니스의 이해’와 같은 섹션들이다. 이 책은 관심사에 맞게 찾아 읽기 좋은 구성으로 되어 있다. 나도 처음에는 순서대로 읽기 시작했지만, 곧 관심 있는 섹션부터 찾아 읽어 나가는 방식이 더 효율적이라고 느꼈다. 실제로 커리어를 그려 나감에 있어서 개개인의 고민이 다르기 때문에 사전에서 단어를 찾듯 당장 눈앞에 놓인 고민과 관련된 섹션을 먼저 읽어나가는 방법을 권하고 싶다. 원래 사람은 닥쳐야 더 집중이 잘 되지 않나.
내가 가장 먼저 택한 섹션은 ‘커리어 관리’였다. 최근에 혼자 웹 프론트 개발을 진행하면서 어떻게 일을 잘할 수 있을지, 미래의 나를 위해 어떤 식으로 일해 나가는 게 좋을지에 대한 고민을 종종 하는데, 거기에 대한 조언을 구하고자 싶은 마음이었다. 인상적이었던 구절은 ‘내가 한 일을 사람들에게 알리자’라는 부분이었다. 혼자 작업하다 보면, 스스로에게 얼마나 관대하냐에 따라 작업의 품질이 달라지기 마련이었다. 물론 그렇다고 프로젝트의 진행이 더뎌질 정도로 엄격하게 구는 건 곤란하지만, 실제로 어느 정도의 엄격함을 적용하려면 자신만의 잣대가 필요하다. 그 잣대를 결정하는 기준, 그리고 그 잣대를 소화해 내는 나에 대한 평가와 더불어 생기는 여러 고민이 있었고, 그 과업을 해결했을 때 스스로가 내리는 결론이나 남은 과업을 바라보며 생기는 다양한 사고 등이 있었다. 이런 것들은 끝내 내가 안고 가는 것들이고 누군가에게 공유하지 않으면 타인은 알기 어려운 것들이다. 책에서는 성과에 대한 것들을 사람들에게 알리자는 짧은 맥락이었지만, 난 조금 더 폭넓은 관점에서 내 고민과 사고에 대해 알리면 좋을 것 같다는 생각이 들었다.
그다음으로는 ‘승진’이었다. 당장 회사에서 승진을 원한다기보다 매년 상급자를 통해 평가를 받아야 하는 입장에서 상급자의 시선이 궁금했고, 그리고 그런 평가의 과정 속에서 어떻게 현명하게 대처할 수 있을지가 궁금했다. 인상적으로 읽은 부분은 업무 정리와 성과 기록에 대한 내용이었다. 실제로 바쁘게 업무를 하다 보면 전체적인 정리나 성과를 기록하는 건 잊게 되는 경우가 많은데, 인간은 망각의 동물이기 때문에 나중에 돌이켜보면 과거의 내가 어떤 업무를 했는지 가물가물한 경우가 많았다. 이는 승진이나 연봉 협상을 떠나, 스스로를 객관적으로 판단하는 데에도 어려움이 있기 때문에 특정 템플릿을 통해 일일 기록이 어렵다면 주간 기록이라도 남기는 편이 좋겠다는 생각이 들었다.
다음으로 찾은 섹션은 ‘업무를 완수하는 개발자’였다. 실제로 이 파트가 주니어에게 중요하다고 생각하는 건, 코드의 퀄리티도 중요하지만 과업을 정해진 기간 안에 끝내는 것이 가장 중요한 일이기 때문이다. 나의 케이스를 돌이켜 보면 안 되는 걸 안 된다라고 말하는 데까지에는 시간이 꽤 걸렸는데, 크게 두 가지가 있었다. 구현이 막힌 것이 아니라 단순히 물리적인 기간 안에 구현이 어려운 케이스와 물리적인 기간과 무관하게 어디서부터 접근해서 해결해 나가야 하는지 난감한 케이스라고 볼 수 있다. 첫 번째 케이스는 거절과 협의의 과정이 미숙해서 생긴 문제였고, 두 번째 케이스는 기술적 성숙도가 떨어지는 문제도 있었지만 근본적으로는 문제를 명확하게 파악하지 못하는 것이 더 큰 문제였다.
이 책에서 권고하는 방식은 작업의 우선순위를 정하고 그 우선순위의 과업을 해결하지 못할 때는 거절하는 법을 배울 필요가 있다는 점이었다. 실제로 내 경우에도 커리어 초기에 특정 애니메이션을 구현하는 파트에서 막혀 꽤 시간을 소요했던 기억이 있다. 사실 우선순위로 놓고 보자면 상품의 상세 페이지로 가는 라우터 작업과 API 호출, 그리고 해당 객체가 호출되지 않았을 때를 대비한 예외 처리가 더 중요했지만, 작업이라는 게 하다 보면 특정 구간에 꽂히기 마련이었다. 그때 도움을 줄 수 있는 건 스스로 마음속에 지니고 있는 우선순위라고 생각한다. 우선순위를 정해놓고 자주 리마인드하다 보면 마음 한구석에서 지속적으로 경보가 울리기 때문에 미리 정해놓는 게 중요했다. 그다음으로 언급되는 내용이 거절할 필요에 대한 이야기인데, 결국 거절을 하기 위해선 우선순위를 명확히 하는 것이 선행되어야 했다. 우선순위가 명확하지 않으면 거절의 근거를 마련할 수 없고, 그런 근거가 없다면 명령권자로부터 내려진 작업에 대해 협의하기도 어렵기 마련이었다. 이 책에는 이러한 명확한 우선순위를 정하는 것, 그리고 거절의 흐름을 가져가기 위한 조언을 말하고 있다.
그 외에 세 개의 연속된 소제목이 공감되었다. ‘작은 단위로 작업 쪼개기’, ‘작업 소요 시간 추정’, ‘선의 통장’. 일반적으로 작업을 맡게 되면 여러 작은 단위의 기능이 결합되어 있거나, 특정 단위의 모듈로 분리할 필요가 있거나, 혹은 다른 직군과의 지속적인 소통이 필요한 경우가 있다. 그 작업을 온전히 수행하려면 가장 작은 단위부터 작업을 쪼개고, 이를 기준으로 컴포넌트를 분리하는 편이다. 이런 작업이 선행되면 작업 소요 시간을 추정하는 일은 상대적으로 쉽게 판단할 수 있었다.
그리고 ‘선의 통장’이라는 표현은 다른 사람을 도우면 선의 통장의 잔고가 늘어나고 도움을 청하면 잔고가 줄어든다는 의미로 사용하고 있다. 이 부분은 주니어 레벨에서 요구되는 ‘질문 잘하기’와 연관이 있다고 느꼈다. 사실 이건 개발에만 해당되는 부분이 아니다. 분야를 떠나 경험이 적은 회사원에게도 해당되고, 무언가 배울 때에도 숙련도가 부족한 학생에게도 해당되는 영역이라고 생각한다. 나의 경우에는 매 순간 다양한 질문을 하고 싶었고, 그 질문은 당장 당면한 문제를 어서 해결하고 싶은 말초적인 욕구로부터 나오기 때문에 정리된 질문이라고 보기는 어려웠다. 우리는 무언가 학습하거나 업무에 익숙하지 못할 때 선임자나 강사로부터 질문을 망설이지 말라는 조언을 듣지만, 정리되지 못한 질문은 명쾌한 답변을 내어놓기 어렵고 그 과정에서 서로 불편한 관계에 놓이게 될 가능성이 높다. 실제로 요즘 이렇게 하려고 노력하고 있는데, 책에서 조언하는 방식은 크게 세 가지다. 기업 내부 지식 베이스에서 찾아볼 것, 프레임워크나 기술 관련 문서를 꼼꼼히 읽어볼 것, 관련 커밋 기록을 살펴볼 것. 사실 이건 옵셔널한 게 아니라 질문하는 사람이 기본적으로 해야 할 일이라고 생각하고, 앞서 저런 선행 과정을 거치고 나면 질문의 맥락이 보이고 이어질 꼬리 질문에 대한 그림까지도 그려지는 경우가 많았다.
그 외 다양한 사례와 조언을 마주하면서 책의 마지막인 6부 ‘결론’에 도달하면 배움을 멈추지 말라는 말과 함께 여러 가지 조언을 이어간다. 가장 먼저 호기심을 유지하는 태도다. 이 책에서 세 가지 질문이 도움이 된다고 권유하고 있는데, 그 세 가지는 다음과 같다. 이 솔루션은 정확하게 어떻게 동작하는가, 이 컴포넌트는 내부에서 어떤 일을 하는가, 처음부터 자체 솔루션을 구축하면 어떤 효과가 있을까. 앞서 두 개의 질문은 실제로 기능 구현을 하면서 종종 고민하는 포인트인데, 마지막 질문은 자주 고민하지 못하곤 한다. 실제로 Sentry를 통해 에러 트래킹을 구축했을 때 사수 역할을 해주시는 시니어 개발자님이 하셨던 이야기가 생각났다. “이거 나중에 저희가 만들어보죠. 구조 자체는 어렵지 않은 거 같은데”. 그때 뭔가 부담스러우면서 동시에 인상적이었던 기억이 난다. 아 라이브러리나 툴이 그저 그 존재 자체로 받아들이고 끝나는 게 아니라 직접 구축의 미래까지 그려볼 수 있구나. 경력이 쌓여 나가면서 중니어, 시니어 개발자가 된다는 건 단순히 기능 구현과 내부 코드 파악으로 끝나는 것이 아니라 개선의 여지, 혹은 그 이상의 무언가를 바라보는 것도 중요한 포인트라는 생각이 든다.
그다음은 계속 학습하고 도전할 것을 권유하고 있다. 개발의 모든 분야가 그러하지만 내가 주로 작업하는 웹 프론트엔드는 변화가 심한 분야이다. 실제로 작년에 Next.js 13 버전을 통해 프로젝트를 했었지만 얼마 전에 15 버전이 나온 상황이고, React 또한 현재 RC 버전이긴 하지만 19 버전 출시를 앞두고 있다. 웹 프론트엔드 개발자 커뮤니티에서는 매 순간 새로운 기능에 대한 논의가 오가고, 업계 동향을 살핀다. 개발자가 최근 몇 년 사이에 유망 직업으로 떠오르면서 부트캠프니 KDT니 다양한 교육이 진행되고 있지만, 그 이면에는 LLM을 통해 대체되는 것이 아니냐는 불안 또한 공존한다. 물론 난 온전한 대체가 아닌 유용한 툴로서의 LLM이 존재하고 그 활용도에 따라 각각의 미래가 달라질 거라고 생각하지만, 어쨌든 청사진만 존재하지 않기 때문에 학습과 도전이 숙명적인 분야라는 생각을 한다.
책에서 제시한 조언과 사례들은 유용하지만 결국 도구나 지침에 가깝다. 결국 중요한 것은 어떻게 나의 상황과 맥락에 맞게 해석하고 활용하느냐에 있다. 이 책을 멋대로 한 줄 요약하자면, 능동적인 성장의 주체가 되라는 의미로 보였다. 단순히 업무 성과를 내는 것에 그칠 것이 아니라 자신의 커리어와 삶 전반에 걸쳐 능동적으로 목표를 설정하고, 그 목표를 향해 나아가는 주체적인 행동들이 결국 전체 그림을 그려내는 과정이라는 것이다. 개발 직무를 떠나 내가 어떤 사람이 될지는 지금 내가 무엇을 고민하고, 실행하는가에 달려 있다는 점이다. 그 실행은 끝내 능동적이고 주체적이어야 할 것, 그 메세지와 함께 책의 마지막 챕터를 덮었다.
"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."
