이펙티브 개발자

책 리뷰에 들어가기 앞서,

정글 수료하자마자 멘토링을 찾아나섰다. 정글에서는 개발자에게 요구되는 기본 지식을 학습했다면, 이제는 높은 곳으로 도약하기 위한 방법을 알아내야했다. 아직은 전 회사와 비슷하거나 그보다 작은 규모의 회사로 가게 될텐데, 그렇게 되면 과거의 학습법을 답습할 것 같아서 우선 인프런 멘토링을 리서치했다. 대기업 재직자, 미들급 이상인 분으로 찾았고 그렇게 3회 멘토링을 받고 얻게된 점.

스타트업과 대기업 취준 전략은 다르다

 

너무 벙쪘다. 사실 멘토링 받기 전에는 정글에서 배운 지식 기반으로 3년 경력 살려서 이력서만 조금 손보면 되지 않을까 했다. 하지만 그와 배운 것들은 스타트업에서 단 한번도 고민해보지 못한 '성능', '기초', 그리고 '한가지를 파본 진득함' 이었다. 즉, 내가 어필했던 다재다능함, 다수 프로젝트 경험들은 핀트가 맞지 않았던 것이다. 그리고 고민했다. 중견 이상 기업을 가기위해 취준 기간을 늘릴 것인가, 스타트업에라도 들어갈 것인가. 결국 나는 스타트업에 다시 돌아가기로 했다. 마음 먹자마자 일은 쉽게 풀렸다. 정글 마지막 과제로 작성한 이력서를 18곳 지원했고 그 중 5곳 서류 통과를 했다. 그리고 협력사를 우선순위로 해서 일정상 가능한 곳만 과제 전형을 진행했다. 그렇게 수료 후 2주 만에 취준에 성공했고 1월 8일 입사를 앞두고 있다. 확실히 정글에서 마지막까지 푸시해주신 덕분에 몇군데라도 더 넣고 면접을 준비할 수 있었던 것 같다. 감사하다. 관련 포스팅은 추후 정글 수료 후기와 엮어서 올릴 예정이다.

 

다시 본론으로 돌아와, 그렇게 멘토링을 통해 내가 겪어보지 못한 세계에 대한 갈증을 해소할 수 있음을 경험하고, 돈이 아깝지 않다고 생각했다. 그래서 그간 고민했던 '에프랩'을 바로 지원했고 Kevin 멘토님께 4개월간 멘토링을 받게 되었다. 지난주에 첫 미팅 후 과제를 받았다. 이어서 리뷰할 [이펙티브 개발자] 책 읽고 생각 정리해오기. Kevin 멘토님은 개발자로서 Tech 기반으로 사업에 기여할 수 있어야한다고 이야기해주셨다. 새로웠다. 나는 그간 최고의 개발자는 기술력만 좋으면 되지 않을까했고 새로운 관점이 트이는 것 같았다. 이 책은 그 관점을 뒷받침해주는 그리고 회사에 기여하고 싶은 개발자들을 위한 책인 것 같다.

---

 

다 읽고 나서 들었던 생각은, '지난 회사에서 배운점, 아쉬웠던 점' 리뷰 시간 같았다 🤣 그래서 두번째 회사에서는 어떤 것을 도입해볼지 정리하려한다. 그리고 공감이 많이 되었던 '성장 마인드셋' 에 대해 서술하겠다.

 

[개발 주기를 빠르게 반복하기]

• CI/CD: 주별 배포 담당자를 정해서 주 2회 이상 배포를 진행했다. 커밋 전 husky 체크, CI 등 검증 단계가 있었지만 릴리즈 브랜치가 생성되면 QA망에 올려서 작업 기여자가 QA 후 Approve를 받는 절차가 있었다. cypress로 구축한 1시간 단위 E2E 테스트로 PRD 환경에서 발생한 응급도를 빠르게 모니터링했고 서버 health check 대시보드도 구축되어있었다. AWS를 사용할 적에는 편했던 롤백 및 브랜칭 기능을 Jenkins 에서 도입될 수 있도록 devops 팀에 요청하기도 했다. 확실히 인프라 구축이 잘 되어있었다. 모니터링 및 핫픽스 줄이기는 입사 3년차즈음 강조되었고 초반에는 확실한 사업 모델을 찾기 위해 기능 개발에 집중되었던게 사실이다.
• 개발측면: 자연스럽게 사용한 핫 리로딩, 버그가 있는 부분으로 바로 이동할 수 있도록 작업 흐름을 단축한 것은 직감적으로 터득한 것 같다.
• 시간 절약 도구: GTM, IDE (하지만 필자는 적응 못한 JetBrain), 코파일럿 등 적극적으로 도입해주셨다.
• 아쉬웠던 점은 환경은 충분했지만, 프로젝트 주기는 한달 이상으로 매우 길었다. 검증되지 않은 가설을 위해 한달 이상을 투자해야했고, 그래서 엎어졌을 때 회의감과 아쉬움은 켜켜이 쌓여갔다. 가설 단계에서는 빠르게 실험하고 포기할 수 있어야하고, 이 결정을 위한 MVP 제작에 2일 이상은 투자하지 않도록 경계하자.

 

[작업 우선순위 산정]

• 프로젝트 시작 시, 유저 스토리 기반으로 JIRA 이슈 카드 싹 다 생성하고 먼저 시작하거나 사전에 체크해야할 어려운 작업을 파악했다. 그리고 각 소요 시간을 추정해 마감일을 산정했다. 초기에는 이 작업을 전부 PM이 해야하지 않나 생각했다. 왜냐하면 '일정 관리'는 Project Manager의 할일 중 하나라고 생각했기 때문이다. 하지만 이제는 일정 산정은 작업자 본인이 하는게 맞고, PM은 병목 사항을 파악하고 타부서간의 협업을 원활히 돕는 역할임을 알게되었다. 그리고 이 작업이 하루 채 걸리지 않고, 앞으로의 프로젝트 진행에 필요한 레버리지 투자임을 인지하며 적극적으로 임하려한다.
• 특히 최근 나만무 프로젝트에서 11시, 20시 스크럼으로 수시로 작업 우선순위를 파악했고 효과적이었다. 11시에 오늘 해야할 작업을 선언했고, 20시에 병목이 있다면 해당 사항을 파악해 풀어주었고, 유휴시간이 생긴 팀원에게는 다음 우선순위 높은 작업을 바로 지시할 수 있었다. 그 덕분에 다른 팀이 매일 야근을 할 때 우리는 정시 퇴근을 했고, 나름 좋은 컨디션을 유지하며 3주 프로젝트를 마무리할 수 있었다.
• 전 회사에서 아쉬웠던 점은 항상 마감일을 타부서에서 결정했고, 우리는 일정이 부족하다면 야근을 해서라도 모든 기능을 개발해야한다고 생각했다는 것이다. 하지만 그 마감일은 출처가 없기도 했고 혹여 프로젝트가 무산된다면, 개발자는 그냥 개고생하고 남은게 아무것도 없었다.
• 그리고 책에서 '중요도, 긴급도를 기준으로 사분면을 나누고 너무 1사분면 (중요도 높, 긴급도 높)에만 집중하고 있지 않은지, 2사분면(중요도 높, 긴급도 낮) 성장을 위한 투자가 부족하지 않은지 경계할 필요가 있다' 고 했는데 대부분 1사분면 작업에 급급했고, 그리고 엎어지기일쑤여서 만족감이 떨어졌다. 반대로 유휴시간에 진행한 2사분면 작업들은 만족감이 높았다. 예로 디자인 시스템 npm으로 분리하기, utm 모듈 분리하기 등. 팀 전체에 기여한 작업이었고 성장감을 느낀 기간이었다.
• 아쉬운건 책에서 추천한 인프라 꾸준히 확장하기, 새로운 프로그래밍 언어 배우기, 컨퍼런스 발표, 멘토링 등에 적극적으로 임하지 못하고 환경 탓만 했다는 것이다. 물론 항상 치고 들어오는 작업에 바빴던 것 맞지만 과연 그게 정말 '이펙티브하게 기여할 수 있는 작업이었는지' 의문을 제기하지 못했던 수동적인 자세에 반성한다. 저자는 '프로젝트에 몇 주를 매달려 있었는데 효과나 영향력이 거의 없거나 배운 내용이 없다면, 나는 아무 일도 하지 않은 것이나 마찬가지다.' 라고 서술했다. 적극 공감하는 바이다. 그 실천법으로 '신호(만약)와 따라야하는 행동(그렇다면) 사이에 연결고리 만들기'를 추천했는데, 나에게 적용해보면.. 회사에서 시간이 남는다면, '컨퍼런스 발표' 영상을 자주 찾아보자. 웹서핑 하지 말고 ^^
• 그 외 공감된 부분.
  • 일정에 집중하는 시간 블록의 길이를 최대한 길게 유지하라.
  • 엔지니어링 외적 업무를 반복해서 처리해야한다. 하루 8시간을 다 쓰는게 아니다. 방해요소를 감안한 1일치 업무량을 파악해야한다.
  • 누구나 자신의 금융 자산을 최대한 이율이 높은 상품에 투자하려한다. 하물며 시간은 가장 제한적인 자산인데, 이를 다르게 취급할 이유가 있을까? 자신의 시간을 학습률이 가장 높은 활동에 투자하자.

 

[작업 지표 선택하기]

• 이벤트 설치 작업을 많이 했고, 전용 로그 시스템을 따로 제작할 정도로 회사에서는 이벤트 작업에 많이 할애했다. 하지만 때로는 관습처럼 설치했고 무작정 뷰/클릭 이벤트를 로깅하며 이 작업을 왜 해야하지 의문을 품기도 했다. 왜냐하면 결국 주요 퍼널 전환만 확인했고 결국은 해당 페이지만 필요한게 아닌가 싶었다. 그리고 단순히 페이지 방문수/전체 인입수 수식이 아니라 의미있는 분석을 위해 WAU 등을 도입했지만 사실.. 이해하지 못했다. Daily 와 달리 Weekly 데이터가 때로는 신뢰있는 이유가 뭔지, 데이터 정확도를 높이기 위해 시간을 투자하는게 맞는지 확신이 없었다. 그리고 여전히 해결책을 찾지 못한 영역이다. 그래도 얻은 힌트는 다음과 같다.
  • 숏클릭 vs 롱클릭 (사용자가 검색 결과를 클릭한 뒤 다시 뒤로 돌아오지 않고, 결과 페이지에 오래 머무는 것) 등으로 단순 수식을 넘어 전환을 고려한 분석이 필요할 수도
  • 예로 책집필하기에 퇴고하는 시간을 더 들이는 것을 보고 출간일을 앞당기기 위한 목표를 위해 하루에 3시간 쓰기가 아닌 하루에 1,000단어 쓰기를 지표로 설정
  • 설사 다른 회사라 할지라도, 관심 영역이 유사한 팀의 지표를 참고할 수도
• 그리고 이러한 지표를 얻기 쉬운게 아닌, 가장 큰 효과, 실행하기 좋고, 즉각 반응하되 견고한 것으로 팀 전체가 공감할 수 있는 것으로 시간 투자할 가치가 있다는 것이다.

 

[빠르게 실험하기]

• MVP는 노코드도 가능. 동영상도 좋다. 가짜 버전도 좋다. 예로 구글 로그인 도입이 고민된다면, 가짜 버튼을 넣고 '곧 출시될 예정입니다. 감사합니다' 등의 문구로 관심도를 파악할 수 있음
• 이는 마케터분들을 위해 파이어베이스로 어드민 환경을 제작한 예시가 떠올랐다. 이미지 리스트와 CTA 문구를 템플릿으로 데이터만 넣어주면 알아서 페이지가 생성되도록 작업했다. 그 덕분에 하루에도 수십개 실험을 무배포로 진행할 수 있었다.
• 다만 어떻게 하면 빠르게 MVP를 얻을 수 있을지 개발속도를 높이는 훈련도 필요한 것 같다.

 

[리팩토링 욕구]

• 저자는 '무언가를 바닥부터 재작성하려는 욕구는 개발자의 아주 일반적인 특징' 이라 서술했고 너무 공감했다. 특히 나는 한줄만 작성해도 '어 변수명 마음에 안드는데, 이거 파일 분리하고 싶은데' 등의 속마음을 품으며 항상 더 좋은 코드가 있지 않을까 아름다운 코드를 추구하는 경향이 있다. 하지만 사내 컨벤션이 가장 적합한 것이고, 눈이 뜨이기 위해서는 외부 오픈 소스를 가깝게는 타 개발팀의 코드를 접해보는 것도 좋은 방법이었다.
• 그리고 나중에는 1인 1프로젝트를 진행하면서 PR리뷰 문화가 사라지는게 아쉬웠는데 이 또한 옳고 그름 없이 팀과 상황에 따라 적합한 방법 찾기가 필요한 것 같다.

 

[리더급 개발자]

• 더 높은 자리에 오를수록 개인적인 기여보다 주변 사람에게 미친 영향이 효과성을 측정하는 기준
• 그 사람의 존재로 인해 팀이 전체적으로 나아진다면 책임 개발자, 회사가 전체적으로 나아진다면 수석 개발자, 업계가 더 발전한다면 최고 개발자

끝으로 나는 확실히 성장 마인드셋을 갖고 있어서 성장 정체감을 느끼고 퇴사를 결정했다. 다만, 그 성장 정체감은 마인드와 달리 가만히 환경탓을 하며 낙담한 시간에서 오는 것이었고 그래서 정글 과정동안 몰입 경험이 필요했다. 그 습관을 어떻게는 유지하려고 아침 CS 기상 스터디에 가입하고 에프랩을 지원했고 만족한다. 나는 리더급 개발자가 되고싶고 영향력 있는 사람이 되고 싶다. 하지만 지난 3년은 임팩트있는 작업을 쟁취하며 개인 성장에만 집중했고, 팀에 대한 기여는 부족했음을 인지했다. 두번째 직장에서는 조금 더 넓은 시야로 고민하며 성장할 수 있을 것 같아 기대된다.