개발일지 (1월 회고)

 

Overview

회사가 성과를 측정하는 방식을 22년 1분기부터 KPI(Key Performance Index)에서 OKR(Objective - Key Result)로 변경하면서 여러 가지 변화들이 있었다. 새로운 지표에 맞추어 플래닝이 진행되어야 하다 보니 기존 플래닝보다 조금 더 시간이 걸리는 듯했고, 덕분에 미루고 미뤄왔던 프론트엔드 팀 내의 칸반 작업들을 정리하고 기존에 작성되어 있었던 로직들에 대해서 적당한 수준으로 리팩터링 하고 누락된 테스트 코드를 작성하는 데 시간을 쏟을 수 있었던 것 같다.

 

Frontend Tech Lead

지금 다니는 회사는 Group 내에 여러 TF(Task Force)가 있고 전사의 분기별 목표를 여러 Group이 나눠 갖고, 각 Group안에 있는 TF들이 Group의 목표를 조금 더 구체화해서 진행하는 구조이다. 당연한 이야기지만 TF에 할당되는 업무의 범위는 웹 프로젝트를 기준으로 정해지는 것이 아니라 "달성해야 하는 목표" 이를테면 "동영상 풀이를 제공한다"라든지 "멤버십 결제를 유도한다"와 같은 보다 UX적인 기준으로 정해지는 것이 일반적이다. 당장 몇 달 전까지만 해도 저쪽 TF에서 진행했던 웹 프로젝트를 건드려야 하는 경우도 있고, 새로운 프로젝트를 생성해서 세팅부터 진행해야 하는 경우도 있으며, 3~4개의 프로젝트를 동시에 건드려야 하는 경우도 있었다.

 

 

각 TF마다 Frontend 개발자들이 있지만, 전체적인 Context를 알고 각 TF 내에서의 기술적인 결정들이 Group의 목표와 향후 확장성을 고려하여 이루어지도록 돕는 역할이 필요했던 것 같고, 특정 TF에서 웹 개발이 없을 때, 적절히 리소스를 분배해서 궁극적으로는 Group의 목표를 잘 달성하는 일종의 컨트롤 타워 역할이 필요했던 것 같다. 이런 이유들로 작년 3분기부터 Group Frontend Tech Lead라는 직책이 내가 속한 그룹에 우선하여 암묵적으로 생겼고, 요게 잘 동작했는지 이번 1분기부터는 모든 그룹에 Group Frontend Tech Lead, Group Backend Tech Lead 등의 직책들이 공식적으로 생겼다.

 

 

Tech Lead(이하 TL)라는 직책이 처음 주어졌을 때 혼자 굉장히 많은 고민들을 했었고 여러모로 부담이 되었던 기억이 난다. (물론 지금도 매우 부담되기는 한다.) 웹 쪽에서 일어나는 결정들에 대해 "책임"이 주어지는 자리이기 때문에 부담감이 생겨 한번 고민했었고, 규모가 크든 작든 팀을 이끄는 역할을 하기에는 기술적으로나 커뮤니케이션적으로나 경험도 부족하고 경력도 짧은데 이런 역할을 "잘"해낼 수 있을지에 대한 이유로 한번 더 고민했었던 것 같다. 고민과 상관없이 어느 정도는 결론이 나 있던 상태였지만 직책을 맡은 뒤에도 이런저런 고민을 계속하게 되었다.

 

 

목표에 대한 명확한 인식

TL을 맡고 나서 가장 크게 변화했던 부분은 "목표에 대한 명확한 인식"이다. "나 혼자 다 한다"가 아닌 어떻게 하면 "우리 모두가 잘 협력해서 목표를 달성할까"가 되어야 궁극적으로는 규모 있는 프로젝트들을 성공적으로 매듭지을 수 있는 것이고, 그러기 위해서는 먼저 목표를 명확하게 Define 해야 한다는 것을 배웠다.

 

이번 분기에 우리 Group은 무엇을 목표로 하는지, 이 목표가 전사의 목표를 달성하는데 얼마만큼의 Impact를 줄 수 있는지, 우리 Group의 목표를 달성하기 위해 각각의 TF들은 어떤 일을 하고 각각의 TF가 설정한 목표를 달성하면 Group의 목표가 달성되는 게 자명한지 등등을 따져보는데 많은 시간을 쓰게 되었다. 처음에는 코드를 작성하는 시간이 줄어서 "내가 개발자가 맞나?"라는 생각이 들 때도 있었지만, 내가 생각하는 개발자는 "코드를 작성하는 사람"이 아니라 "문제를 해결하는 사람"이고 좋은 개발자라면 먼저 해결해야 할 문제를 정확하게 이해하고 그다음에 코드로 옮겨야 하기 때문에 이렇게 하는 것이 좋은 개발자가 되는 길인 것이라는 생각이 들었다.

 

또한 리소스를 분배할 때도 팀원들에게 어떤 목표를 달성하기 위해 이 태스크를 해야 하는 것이고, 이 태스크가 얼마나 중요한 태스크인지, 이 태스크를 달성하면 어떤 것들이 달성되고, 어떤 것에 기여하는 것인지를 알려주는 것이 매우 중요하다는 것을 배웠다. 나는 회사에서 중요한 사람이 되고 싶고, 내 옆에 있는 팀원들도 이러한 소망을 가진 사람이기를 꿈꾼다. 내가 하는 일이 중요하다는 것을 알면 적당한 부담감과 함께 문제를 조금 더 적극적으로 해결하려고 하게 되고, "코드를 작성하는"개발자에서 "문제를 해결하는"개발자가 되는 여정에 조금 더 가까워진다고 믿는다. 처음에는 이런 생각을 갖는것이 조금 어려웠는데, 이제는 나보다 내 동료들이 훨씬 뛰어난 개발자들이 되어있기를 꿈꾼다 (그래야 나도 더 많이 배우겠지)

 

 

"내가 했다"가 아닌 "문제를 풀었다"

TL이라는 직책이 주어진 건 Group의 문제를 "해결"하기 위해서이지, TL을 맡은 사람에게 박수를 보내고 스포트라이트를 주기 위해서가 아니다. 그렇기 때문에 문제를 해결할 수만 있다면 어떤 방법을 써서라도(물론 도덕적이고 남에게 해를 끼치지 않는 선에서!?) 문제를 해결하면 되는 것이다. 실제로 작년 3~4분기에 Group에서 맡게 된 태스크들은 기술적으로 고려해야 할 사항들도 굉장히 많았고, 하나의 결정을 내리는 데 사용할 수 있는 선택지들도 꽤 많았었다. 

 

돌이켜보면 참 잘했다고 생각이 드는 건, "나는 아직 주니어고, 모든 의사 결정을 능수능란하게 할 수 있을 만큼의 경험을 갖추지 못했기 때문에 열심히 조언을 구하자"라는 태도로 의사결정을 하나씩 해 나갔던 점이다. 시니어분들을 열심히 쫓아다니면서 경험에서 우러나오는 여러 조언들을 구했고, 동일한 문제에 대해 여러 시니어분들과, 이미 해당 경험을 해 본 적이 있는 여러 다른 개발자들, 심지어는 프론트 파트가 아닌 백엔드, DevOps 개발자분들과도 논의를 해보면서 어려운 결정들을 잘 해낼 수 있었던 것 같다. 결과적으로 "내가"한 건 거의 없지만 우리 Group은 문제를 풀었고, 그것으로 된 것이다.

 

 

Antifragility

다음 스터디 주제를 열심히 찾고 있는 프론트엔드 팀원들에게 [Web.dev] 스터디를 하는 것이 어떻겠냐고 제안했고 이 글을 쓰는 시점인 2월 둘째 주 목요일부터 스터디를 본격적으로 시작했다. 작년 9월 "Antifragile"이라는 책을 처음 접하고서 "예측할 수 없는 변화들로부터 이익을 얻으려면 어떻게 해야 하는가?"에 대해서 여러 분야에 걸쳐 고민을 하기 시작했고, 이는 "빠르게 변화하는 웹 생태계에서 어떠한 학습을 하는 것이 나에게 도움이 될까"에 대한 고민으로 이어졌다.

 

이건 정말이지 내 인생책이다

 

"3년 뒤에 더 이상 웹 개발자들이 리액트를 사용하지 않고, 리덕스를 사용하지 않고, Nextjs를 사용하지 않는다고 해도, 나는 여전히 쓸모 있는 개발자일까?"라는 관점에서 고민을 계속해 나가다가, "웹" 자체에 대한 공부의 비중을 더 높여야겠다는 생각에 이르렀다. 결국에는 리액트도, 리덕스도, 웹 생태계에서 해결하고 싶은 문제를 해결하기 위한 수단으로써 등장한 "도구"이고, 이 도구의 사용법 자체를 익히는 것도 매우 중요하지만, 그 이전에 이 도구는 "어떤 문제를", "어떻게 해결하려 하는가"에 대한 고민이 필요하지 않을까 하는 것이다.

 

 

MDN문서에 정의된 수많은 헤더들과 여러 기능들, React, Angular, Vue와 같은 수많은 렌더링 프레임워크와 라이브러리들 이전에 "문제"가 있었고, 어떻게서든 그 문제를 지금 이 시점에서 가장 효율적으로 해결했다고 평가받는 것들만이 살아남아 있는 것이 아닐까 하는 생각을 한다. 때문에 기술과 도구 그 자체보다도 이 도구가 풀어내고자 하는 문제와, 그 문제를 해결한 방식에 대해 조금 관심을 더 기울여야겠다는 다짐을 한다. 

 

 

Test Driven Development

앞서 너무 많은 이야기를 한 것 같아서 테스트 주도 개발 관련한 리서치에 대한 내용은 짧게 언급만 하려고 한다. 최근 "애자일"한 조직은 어떤 조직인가에 대한 고민을 많이 하고 있고 그런 의미에서 "Clean Agile"이라는 책이 이 고민을 이어가는데 많은 보탬이 되었다. 애자일이라는 주제 자체만 해도 내용이 워낙 많아서 이 부분은 나중에 정리해볼까 하는 생각도 든다. 어쨌거나 조직이 애자일 해지기 위해서는 필연적으로 "용기"가 필요하고, 여기서의 용기란 기존 코드를 정리하고 수정하고 기능을 추가할 용기다. 이러한 용기를 주는 것이 바로 테스트 코드이며, 테스트 코드 자체가 곧 기술 스펙을 의미한다. (어떻게 수정하든 올바르게 작성된 테스트가 통과한다면 유저는 그걸로 만족할 만한 서비스를 제공받을 수 있으니까 말이다)

 

 

 

 

따라서 사내에서 테스트코드를 작성하고 TDD로 개발하는 문화를 만들자는 목소리를 열심히 내어 사람들의 동의를 구했고, 팀원들의 생각들과 의견들, 경험들을 모아 사내에서도 테스트 코드 레이드를 시작했고 레이드의 PM을 맡아서 열심히 테스트 문화를 만들어가고 있다. 모두가 테스트 코드의 필요성과 애자일한 조직에 대한 중요성을 알고 열정적으로 참여해주시는 것 같아서 많이 놀랍기도 하고, 들뜨기도 했던 것 같다. 생각했던 것보다 더 빠르고 적극적으로 진행이 되어서 "와 이게 되네?"라는 생각을 굉장히 많이 했었던 것 같다.

 

 

실제로 프론트엔드의 메이저한 프로젝트들이 일부분 TDD로 스펙 추가에 대한 개발들을 진행하고 있고, 효율적인 CI / CD 지원을 위해 도커와 cloudbuild, pubsub, cloudfunction 등을 사용하면서 새롭고 재미있는 것들도 많이 시도해보고 있다. (아래는 Cloudbuild에서 Integration Test를 돌린 후에 실패한 테스트 케이스에 대한 정보를 해당 커밋에 바로 Feedback 해주는 시스템의 Prototype이다)

 

 

기대보다 훨씬 더 적극적으로 참여해주시는 팀원들 덕분에 TDD방식을 도입하면서 마이그레이션 할 수 있도록 여러 가지 예제들을 정리하고, 테스트 코드를 작성할 때 PO와 QA팀과의 긴밀한 협업을 위해 BDD방식까지 리서치가 되어 부분적으로 도입이 되고 있다. 3월 전에 Phase 1을 마무리하고 2분기에는 Phase 2를 논의할 예정이고, 좋은 테스트 문화가 정착되면 여러 모로 참 뿌듯할 것 같다는 생각이 든다.