[개발자회고] #14. 2024 하반기 회고 (feat. 마지막)

2024년이 끝났다. 개발자가 되고 쓰는 14번째 회고! 그리고 마지막 회고. 
(마지막의 의미는 가장 아래 챕터에서 ...)

---

전략

팀장이 되면서부터 제일 먼저 고려해야 하는 부분이 바로 전략 부분입니다.
뭐 특별한 일이라기보다는 팀의 목표 설정하는 것부터 전략의 시작이라고 생각합니다.

 "딜라이트룸" 테크 리더분께서 쓰신 글을 인상 깊게 읽었다.
여담이지만, <인프콘 2024>에서 "딜라이트룸 패널토크"를 매우 인상 깊게 보았기에 글이 반가웠다.
 자연스럽게 항상 고민했던 부분인데 실무도 아니고 매니징도 아니라 내가 고민하는 게 맞나 의문이 들었던 부분이 있었다.
 그게 전략이었던 것 같다. 

 개발부장으로서 "전략"적인 부분을 더 많이 고민해야겠다고 생각했으나 생각에 그쳤던 것 같다.
 주어진 과제들에서 헤어 나오지 못했고, 실무를 덜어내지 못했다. 서버도 내 기준으로 안정적이진 않았기에 기술적 개선이 계속 필요한 상황이었다.

---

[기술적 개선 1] Index Hint

 postgreSQL를 다루면서 인덱싱 제어가 어려웠다. 복잡한 로직을 구현함에 따라 1개의 테이블에 여러 개의 인덱스를 생성하게 되는데, 여러 개이기 때문에 내가 의도한 인덱스가 태워지지 않는 문제가 꼭 있었다. 행여나 데이터 적재에 따라 운영 중 갑자기 인덱스가 바뀔 때도 있었는데 이때 장애를 일으킨 적도 있었다. 
 postgreSQL에 pg_hint_plan이라는 확장 모듈이 있어 활용해보려 했지만 우리가 활용 중인 백엔드 프레임워크 특성상 할 수 없다고 오래전부터 인식하고 있었다. 서비스의 로직은 점점 더 복잡해졌고 문제를 계속 직면하고 있었다.
 그러던 중 어느 순간 "왠지 가능할 것 같다"는 생각이 들었고 바로 R&D 해보니 수동으로 인덱스를 제어 가능했다. 
  pg_hint_plan의 동작 원리와 자체 백엔드 프레임워크의 SQL 호출 로직을 이해하고 있었기에 어렵지 않게 가능했던 것 같다. 누구나 조금만 들여다보면 충분히 가능한 부분이겠지만 신입 입사할 때부터 안 된다고 들었던 부분을 6년 만에 스스로 깨버린 것이기에 굉장히 뿌듯했다.

---

[기술적 개선 2] Read DB

 피그마가 DB서버 1대로만 2020년까지 운영했다는 글이 24년 3월 정도에 퍼졌었다. (물론 1대로 올릴 수 있는 최고 스펙이 꽤 어마어마한데 최종 스펙인 r5.24 xlarge(96 코어) 짜리까지 업데이트했다고 한다) 이 글을 읽고 인프라 개선도 중요하지만 사업이 잘 되면 그때 고민해 봐도 된다는 인사이트?를 얻었던 것 같기도 하다. 어쩌면 무식하다고 볼 수도 있으나 1대로 96 코어까지 올려보는 것도 한 가지 방법이 될 수도 있다.

https://aws.amazon.com/ko/ec2/instance-types/r5/

 사용자가 늘어나고, 기능들이 많아지고 복잡해지며 점진적으로 부하는 증가하는 상황이었다. 당장은 아니지만 선조치를 하지 않으면 장애까지 이어지겠다고 판단되는 상황이었다.
 위에 말한 피그마처럼 96코어까지 늘리는 선택지도 있었지만 스케일업은 언제나 비용이 딱 계산되기 때문에 쉽게 추진하기는 어려웠다. "기술자로서 최적화를 하면서 나아가지 않으면 너무 많은 비용을 지불하며 가야 된다"는 생각도 틀린 생각이 아니었다. 심각한 수준의 부하가 계속 발생하는 것이 아니라 점진적으로 부하가 증가하는 상황이라 계속 R&D로 풀어보자는 생각이 있었던 것 같다. 
 글로벌 서비스를 준비하면서 여러 가지 기술들이 적용되었지만 국내 서비스는 이전과 같은 인프라로 운영되고 있었다. 
 여러 개선 방향 중에 리드 디비를 운영하는 것은 그리 어려운 일은 아닌데 잘 추진이 되지 않았었다. 인프라팀에게 적극 요청하고 현 상황에서 해결이 안 되면 스케일업을 해서 비용이 지불될지도 모른다는 설득을 통해 리드 디비가 준비되었다. 
 리드 디비에 대해 잘 알지는 못했지만 메인 디비와 리드 디비의 "동기화"가 얼마나 빨리 되느냐에 대한 물음이 먼저 들었다. 이러한 개념을 "Replica Lag" (복제 지연시간)이라고 한다는 것을 처음 알게 되었다. 직접 실험해 보니 우리 서버 기준으로 평균 10ms 정도 걸렸다. Replica Lag에 영향을 주는 것이 대표적으로 "리전, 메인DB스펙, 메인DB트랜잭션량"이다. 다른 리전에도 리드디비를 만들 수 있었고 리전에 따른 레이턴시를 고스란히 잡아먹는 듯했다.
 대량 삽입에도 동기화가 잘 되는지도 테스트해 보았다. 마스터 디비에는 12초 걸리는 대량 삽입이 리드 디비에 20ms 만에 반영되는 것도 잘 확인했다. 이러한 분석결과를 개발조직에게 전파했다. 그리고 부하가 생기는 조회 쿼리들을 리드디비를 바라보게 개선해 주었다. 예상했던 것보다 효과가 훨씬 좋은 쿼리들도 있었는데 다른 과제도 있었기에 딥하게 분석하지는 않았다. 여하튼 개선이 많이 되었기에 스케일업에 따른 비용을 당장은 지불할 필요는 없게 되었다.

---

[기술적 개선 3] Session Caching

  부하 문제를 해결하기 위해 캐싱은 매우 보편적인 방법임에도 불구하고 적용을 못하고 있었다. 다른 팀원들이 Redis를 활용하여 캐싱서버 문제를 풀고자 했으나 매번 이슈가 있었다. 추가로 엔터프라이즈 서비스를 병행하고 있었기 때문에 Redis 캐싱 서버를 인프라에 추가 구성하는 것이 부담이 된다고 생각했다. 그러던 중 세션에 꽤 많은 데이터를 보관하여 활용한다는 것을 인지했다. 와스서버에 세션이 많아지거나 많은 데이터를 저장하여 활용하면 이 또한 부하가 생길 수 있다는 점은 인지하고 있었다. 하지만 와스서버는 디비서버에 비해 훨씬 고스펙으로 분산 처리되어 있었기 때문에 디비 부하보다는 와스 부하가 낫지 않을까란 생각으로 접근을 해보았다. 
 쿼리 결과값을 JsonString으로 만들고 세션에 저장했다. 여러 곳에 응용해서 활용해 보았는데 와스에는 cpu, memory 차원에서 크게 영향이 없었다. 대신 주요한 대량 호출 쿼리들의 호출 수가 줄었고 부하적으로도 개선이 되었다. 이때, JsonParser도 유틸에 따라 성능 차이가 있음도 확인했다. 4개의 parser 유틸을 혼용해서 쓰고 있었는데 최대 속도와 최소 속도차이가 14배까지 차이가 났다. (물론 마이크로초 단위라서 매우 매우 미미하지만 티끌도 모이면 부하가 된다)
 세션 캐싱이 보편적으로 쓰이는 개선은 아니지만 여러 가지를 고려했을 때 단시간에 가장 빠른 효과를 보았지 않나 싶다.

---

TFT

 "첫 유저들에게 좋은 경험을 주고 싶다"는 생각으로 TFT가 추진되었다. 회의는 항상 뜨거웠다. 좋은 경험을 주었으나 유료전환은 하지 않은 케이스, 좋은 경험은 아니지만 유료전환은 한 케이스를 다뤄보면 결국 "유료전환하고 싶은 마음이 들만한 경험을 처음에 주어야 한다"로 모아졌던 것 같다. 데이터를 들여다보고 어떠한 행동이 유료전환을 이끌었는가 인과관계를 따져보았다. "어떠한 특정 행동 패턴이 유료전환을 이끈다"라 할만한 몇 가지 패턴들이 있기는 했으나 적극 도입검토를 하려고 마음먹은 사람이 그냥 그러한 행동을 하는 것이지 구경삼아 온 사람이 이러한 행동들을 유도한다고 유료전환을 하게 될지는 미지수였다. 이런 분야에 전문가가 있다면 미친 듯이 조언을 구하고 싶은 마음이 들었다.  
 위 문제를 딱 하고 해결한 것은 아니지만 우리 서비스를 다른 회사가 어떻게 쓰고 있는지를 구경할 수 있게 해 주면 분명 더 긍정적으로 도입을 검토할 것이다라는 생각은 모두가 일치했다. 그래서 "다른 프로젝트 구경하기"가 추진되었다. 
 AI 기술을 활용하면 들어오는 유저마다 "당신의 회사와 비슷한 회사가 이런 식으로 서비스를 활용하고 있으니 잘 참고해 보세요" 하고 맞춤형 제안을 할 수 있을 거라 생각했다.
 최종적으로는 맞춤형 제안은 하지 못했고 프로젝트 20개만 고정적으로 제공하는 MVP 수준으로 만들어 오픈했다. 눈에 띌만한 성과를 만들어내지는 못 했다. 계속 개선해 나가면 된다고 생각하여 더 추진하고자 했으나 여러 업무를 병행하는 TFT팀원들은 지친 듯했다. 마케팅, CX, 사업, 개발, 기획 등 다양한 부서들의 인원이 1명씩 모여 공동의 과제를 추진해 보는 TFT가 처음이었기에 새로운 경험이었으나 기존 업무와 병행하며 무언가를 추진하기엔 쉽지 않았던 것 같다. 조직이 변화되면서 자연스럽게 TFT는 해체되었다. 뜨거웠던 회의는 좋은 기억으로 남았다. 

---

제안

 회사 체육대회 전날인 10월 24일(목) 대표님에게 뜻밖의 제안을 받았다. 
 현재 맡고 있는 주요 역할이 "AI, TFT, 기술적 개선, 개발부서원 11명 매니징 등"이었고 최근 AI를 더 개선해야 한다는 의견을 계속 냈었어서 AI 부서를 신설할 테니 맡아달라는 제안을 하실 거라 생각했다.
 제안의 시작은 아무도 예상 못한 조직개편을 구상 중에 있고 그 중심에 내가 있다는 이야기였다. 더 들어보니 개발을 내려놓고 SaaS 사업을 대표님과 같이 이끌어가 보지 않겠냐는 제안이었다. 피드백이 반영되지 않더라도 항상 회사가 더 좋은 방향으로 나아갈 수 있게 기획, 마케팅, 사업 전분야에 적극적으로 피드백했었던 점이 컸던 것 같다. 
 여러 가지 생각이 들었다. 개발 경력이 만 6년 정도 되었는데 여기서 경력이 끝이 되는 것일까? 다른 분야도 싫진 않지만 전혀 경험이 없는데 잘할 수 있을까? 나의 커리어는 어떻게 그려지는 것일까? 어쩌면 내가 현 직책인 개발 리더를 잘 못하고 있어서 다른 부서를 제안하는 것일까? 나의 부서원들 11명은 받아들일 수 있을까? 회사 직원들 모두 이 조직개편을 납득할 수 있을까?  CEO이신 대표님과 CTO이신 부대표님과 많은 대화를 나눴지만 끝까지 스스로 결정을 내리기는 어려웠다.
 대표님의 적극적인 설득으로 11월 27일(수) "개발부장"에서 "사업부장"으로 부서 이동 발령이 났다. 대부분의 직원분들이 당일 알게 되었는데 새로운 부서원들조차 내가 본인들의 리더가 되는 것을 발령 당일 처음 알게 되었다. 
 그래서 개발자회고는 마지막이라는 표현이 맞을 것 같다. (그래도 회고는 계속해야지)

---

책임

 제안부터 발령까지 한 달의 시간이 있었다. 어차피 부서가 바뀌면 맡지 않을 일인데 이렇게 까지 열심히 해야 하나? 새로운 부서에 잘 적응할 수 있게 지금부터 조금씩 준비를 해야 하는 것은 아닐까?라는 마음이 들었다. 마치 퇴사를 앞둔 사람도 이런 마음이겠구나 싶었다. 하지만 유종의 미는 중요하기에 최대한 티 안 내고 현재 역할에 충실하고자 했다. AI 코파일럿 과제도, 구글 워크스페이스 크롬 익스텐션 과제도, 사내 해커톤도 밤을 새워가며 최선을 다해 임했다. (사내 해커톤 2등으로 마무리~)
 발령이 나고도 새로운 업무에 적응하랴, 기존 과제들을 병행하랴 매일 같이 열심히 달렸다. 열심히 달렸지만 훌륭하게 부서이동을 하지는 못했다. 되는대로 닥치는 대로 신입 때보다 더한 긴장감으로 하루하루를 보냈다. 다행히 오래도록 함께한 기존 팀원들이 많이 지지해 주고 새롭게 함께하게 된 팀원들도 잘 알려주고 믿어줘서 버틸 수 있었다. 
 "사업부장"이라는 직책이 내가 맡은 부서만으로 성과를 낼 수 있는 분야는 아니라고 생각했다. 우리 부서인 컨설팅팀, 고객경험팀을 비롯하여 마케팅팀, 개발팀, 기획팀 등 전 분야에 걸쳐 사업 전략을 구상하고 추진해야 한다고 생각했다. 잘 알고 있는 제품 개발 경험과 이제 새로 배우는 고객 경험을 잘 융합하여 책임감 있게 2025년 잘 달려봐야겠다고 생각했다.

---

둘째

 올해 가장 큰 이벤트, 9월 둘째가 태어났다. 4가족이 되었다. 현재 140일 정도 되었는데 세상 제일 귀엽다.
 6개월마다 쓰는 회고록과는 별개로 가족의 큰 이벤트는 별도로 후기를 적고 있다. 최근 둘째 출산 후기는 네이버 블로그에 정리해 두었다.
 자식이 하나인 가족의 삶과 자식이 두 명인 가족의 삶은 또 다른 차원의 난이도를 가지고 있는 것 같다. 난이도는 올라갔지만 행복의 순간은 2배 늘어났다. 첫째의 순간과 둘째의 순간. 각자가 만드는 행복한 순간들이 우리 가족을 행복하게 만들고 있다.

---

사이드

 사이드 프로젝트가 취미가 돼버려 무언가를 개발해야겠다는 생각은 들었지만 이번에는 그렇다 할 다른 아이디어를 떠올리지 못하고 있었다. 그냥 경험 삼아 사이드 프로젝트를 하는 것이 아닌 무언가 유의미한 것을 해내고 싶다는 욕망이 있어 실행이 쉽지 않았다.
 그러던 중 스레드를 만났고 너무 나를 드러내면 솔직하게 하지 못할 것 같아서 부캐를 만들고 이런저런 사이드를 준비하며 드는 생각을 써 내려가기도 했다. 쓰레드에서 "인디해커"라는 용어가 보였다. "혼자서 사이드 프로젝트를 만들어 수익을 창출하는 개발자"라는 뜻이었다. 막연히 인디해커가 되어야겠다는 생각보다 경쟁력 있는 사람이 되려면 이 방향도 좋은 방향이라는 생각이 들었다.
 둘째 출산휴가에 맞춰 사이드 프로젝트를 진행했다. 앞서 만들었던 "농구영상편집기"가 용량을 많이 차지해서 인프라 유지 비용 든다는 아쉬움, 그리고 자주 챙겨보는 유튜브 프로그램 "턴오버"의 타임라인 댓글 챙겨보는 습관에서 아이디어는 시작되었다.
 최종적으로 YoutubeMoments라는 유튜브 명장면 추출 & 공유 서비스를 만들었다. 쓰레드에 홍보하고 서버가 터지는 등 인상 깊은 순간들은 있었으나 계속 디벨롭시키지는 못했다. 유튜브 앱에서 바로 쓸 수 있으면 훨씬 좋을 텐데 별도 서비스에서 해야 할 만큼 개선하지는 못했다. 가진 것을 잘 활용해서 유튜브 프로그램 "턴오버"를 기념하여 영상 모음을 만들어주었고 개개인에게도 전달해 드렸다. 수익은 1도 못 만들어냈지만 유의미하지 않았나 싶다. 

 계속 이 프로젝트를 개선할 의지도 있었으나  11월 말 조직 개편으로 도저히 사이드할 시간을 낼 수 없었다. 가끔 들어가 인급동 보면 시간 가는 줄 모른다. 쓰레드는 활동을 조금씩 이어나갔는데 쓰레드 1,000명 팔로우를 넘어섰다. 크게 달라진 것은 없지만 뿌듯함은 남았다.

---

마지막

 직무 전환으로 인해 개발이 주 업무는 아니게 되었다. 하지만 어떠한 문제를 마주했을 때 충분히 개발로 풀 수 있을 것 같다는 생각이 계속 든다. 그 생각이 이어져 일과 중에는 "사업부장"으로, 일과 외 시간에는 "개발자"로 활동하고 있다. 이 방향이 언제까지 계속될지, 과연 나는 잘 적응하여 좋은 성과를 만들어낼 것인지는 한 치 앞도 예상되지 않는다. 항상 그래왔듯 최선을 다하고 몰입하면 결과는 따라올 것이라 믿고 2025년도 달려봐야지. 아자!