[개발자회고] #12. 2023 하반기 회고 (feat. 장애와 운영, 리더의 리더)

2023년의 하반기가 지났다. 개발자가 되고 쓰는 12번째 회고를 시작해 보자!

---

장애를 넘어라 💪

 상반기 회고에서 5월 31일(수)에 발생한 데이터베이스 장애를 대청소(Vacuum) 방법으로 해결해 냈다고 적었다. 하지만 분석해 보니 현 상태로 그대로 두면 2~3개월 뒤에 또 같은 문제가 발생할 확률이 높아 보였다. 그래서 데이터베이스의 성능개선을 목표로  '불필요한 로직 개선', '슬로우 쿼리 개선', '부하 쿼리 개선' 등이 진행했다.
 새로운 개념으로 접근한 부분이 "개별적으로는 빠르지만 호출이 많아 서버 전체적으로 부하를 주는 '부하 쿼리' 들을 어떻게 하면 개선할 수 있을까"였다. 대표적으로 초당 140회  호출되는 '기능플래그 조회' 쿼리가 12밀리초 정도 걸리고 있었다. 12밀리초면 0.012초이기때문에 이미 초패스트 쿼리이지만, 초당 140회 꾸준히 호출되고 있었기 때문에 서버 부하 TOP 5 안에 드는 쿼리였다. 튜닝을 통해 이 쿼리를 300마이크로초 수준으로 만들었다. (300마이크로초는 0.03밀리초이자 0.00003초를 의미한다.) 소요시간을 40분의 1로 개선해 내었다. 적용 후 서버 부하 TOP 50위 바깥으로 밀려난 것을 확인할 수 있었다. 
 또한,  서버 부하 TOP 1이었던 '게시물목록 조회' 쿼리를 30밀리초 => 10밀리초로 3분의 1로 개선해 내었고, 439 Line의 매우 복잡한 쿼리에서 155 Line으로 비교적 덜 복잡하게 리팩토링했다.
 그밖에, 쓰이지 않는데 쿼리 수행을 하고 있는 수많은 디테일한 부분들을 정리했다.
(이러한 개선 과정에서 9월 4일 인덱스 튜닝 작업으로 1시간 장애를 일으키기도 했다. 개선하는 과정에서 나온 장애였지만 더욱 하이스탠다드로 테스트가 진행되어야 함을 느꼈다)
 연말기준, 서버는 트래픽이 작년에 비해 2배가 늘어났지만 동일한 인프라에서 여전히 안정적인 수준으로 유지 중에 있다.
 그리고 ‘CPU 100%당 쿼리처리량’은 시간당 1억 건 처리 수준에서 시간당 1.5억 건 처리 수준으로 개선되었다!
(참고로 서비스의 일과시간 평균 TPS 1,500건, QPS 4,500건 정도 된다)

cpu 추이

운영은 중요해 ⚙️

 개발팀의 주요 업무에는 신규 기능을 개발하거나 R&D 하는 '개발' 업무와 고객 대응과  QA를 처리하는 '운영'  업무가 있다. 흔히는 SI와 SM이라고도 표현할 수 있는데 자체 서비스를 운영하는 경우에는 한 팀에서 이 것을 모두 처리해야 한다. 리더가 되기 전에는 '개발', '운영' 막론하고 주어진 일을 잘 해내는 데에만 초점이 맞춰져 있었다. 리더가 되고 나서는 우리 조직은 '운영'보다 '개발'이 우선순위가 높은 조직임을 깨달았다.
 조직의 방향을 무조건 따라가기엔 '운영'도 너무 중요했다. 위에서 언급한 장애를 비롯하여 수많은 장애 포인트와 고질적으로 꼬여버린 로직들, 30여 개가 넘는 엔터프라이즈, 글로벌, 사스 환경을 One Source로 관리하기 위해 파생되는 수많은 이슈 포인트들 때문에 조금만 정신줄을 놓으면 바로 이슈가 생길 수밖에 없었다.
 2023년에는 개인적으로 '운영'이 '개발'보다 더 중요하다는 생각이 지배적이었다. (모든 대화에 '안정화'가 1순위라고 언급했다) 위 개선 작업도 안정화의 한 부분이었는데 또 하나는 '테스트 자동화'였다. 서비스 규모는 엄청 크지만 테스트 코드 한 줄 없었다. 특정 과제에 한하여 테스트 코드를 활용하고자 하는 시도는 계속 있었지만 배포 과정에 녹여져 안정성이 올라 간 케이스는 없었다. 
 내가 바라는 첫 번째 스텝은 배포 때마다 매번 자동으로 주요 API 테스트를 진행하는 것이었다. 그 첫번째 스텝을 8월 24일부로 진행하게 되었다. 현재는 병합 및 배포가 진행될 때마다 24 종류의 API, 257 케이스를 커버하고 있다. (20초 소요) 

얼마나 다양한 테스트를 만들 수 있나요?	얼마나 복잡한 테스트를 만들 수 있나요?
필터별로 곱셉으로 나아가면 케이스를 만들 수 있습니다. 예를들어, 업무모아보기는  '전체 대상 or 프로젝트 대상' 곱하기 '내업무 or 요청한업무 or 전체업무' 곱하기 '요청 or 진행 or 피드백 or 완료 상태필터' 곱하기 '긴급 or 높음 or 보통 or 낮음 우선순위필터' 곱해서 96가지 테스트를 손쉽게 해볼 수 있습니다.	유저 1번, 유저 2번을 가입시키고 1번 유저로 로그인해서 프로젝트를 만들고 프로젝트에 2번 유저를 초대하고 1번 유저 로그아웃하고 2번 유저 로그인해서 초대된 프로젝트에서 게시물에 글을 3개 쓰고 다시 1번 유저로 로그인해서 알람이 3건 와있는지 확인하고 알람을 1건 읽으면 잔여 알람건수가 2건이 되는지 까지 확인이 가능합니다!

API 테스트 중에 오류가 나면 희열을 느끼고 오류가 나지 않으면 괜스레 마음이 편안해진다.
하지만 그때 이후로 단 한 케이스도 추가되지 않아 현재까지는 최초 범위와 똑같은 범위만 커버 중에 있다. 이는 개발자들이 손쉽게 만들 수 있는 방식이 아니거나 테스트 자동화가 아직은 중요하지 않다고 모두가 느끼고 있거나 기능을 개발할 시간을 있지만 테스트 코드를 짤 여유가 없거나 일 것 같다. 내가 더 노력해야 하는 분야로 보인다.

 '운영'은 숨쉬기 운동이다.
손으로 코와 입을 막아보면 비로소 중요했다는 걸 깨닫는다.
하지만 코와 입을 막은 손을 내리자마자 바로 그 사실을 까먹는다.

리더의 리더 🧭

 21년 5월부터 파트장으로 리더 임무를 수행했고 만으로 2년 7개월 정도 되었다. 그 시간 속에 팀원이 2명에서 9명까지 늘어났어도, 파트장에서 팀장으로 승진했어도 최초 리더 직책을 달게 되었던 순간만큼 임팩트는 없었다. 
 최초 리더 직책을 달게 되었던 순간은 '어떻게 하면 좋은 리더가 될 수 있을까?' 고민을 최초로 하던 시기 었기에 고민이 많았었다. 하지만 그 이후는 항상 하던 생각이었기에 특별한 점은 없었다. 
 꾸준한 생각과 실천을 통해 주어진 과제를 해내는 것과 별개로 개발 문화(테크세미나, 팀노션, 실험실기능)를 만들고 팀의 리소스(리소스차트, R&R)를 명확하게 관리할 수 있게 만들고 매번 모범이 되기 위해 기록하고 공유했던 것 같다. 
 그러던 어느 순간부터 개발하는 시간보다 커뮤니케이션하는 시간이 대폭 증가했다. 오전부터 회의를 달려 모든 일정을 마치면 17시가 되는 날이 허다했다. 늦은 오후가 되어야 개발에 집중할 수 있었다. 중간중간 의사결정 혹은 리뷰, 문의 등을 위해 내 자리를 찾아오는 사람이 늘어났다. 옆 자리 팀원께서 '번호표 뽑으세요'라고 농담을 하기 전까지는 무던히 소화했던 것 같았다. 
 이때 내 상태는 불만이라기보단 '관리'와 '개발'을 같은 수준으로 병행하는 게 효율적이지 않고, 나로 인해 병목이 되는 게 조직의 관점에서 효율적이지 않다고 느꼈던 것 같다. 
 그러던 중 23년 12월 나는 팀장에서 부장으로 인사발령이 났고 선임으로 역할을 잘하고 있던 팀원들이 팀장이 되었다. 어쩌다 리더의 리더가 되었다. 최초 리더 직책을 달게 되었던 순간만큼 임팩트 있게 다가왔다. 아직 팀장으로서 많이 부족하다고 느꼈는데 팀장을 잘 육성해야 되는? 포지션이 돼버렸다.
  2023년 팀 회고 시간을 통해 좋은 팀장과 아쉬운 팀장에 대한 이야기를 허심탄회하게 나누었다. 이번에 팀장이 된 인원들은 직책만 팀장이 아니었지 리더의 역할을 충분히 해내고 있었던 인원들이라 잘 해낼 것이라고 생각한다.
 공교롭게도 여러 상황들이 맞물려서인지 팀장이라고 하는 직책이 주는 힘인지 팀장들이 스스로 변화하여 역할의 범위를 늘려나가고 있는 것 같아 보인다. 내심 우리 조직이 어느 한 명 나무랄 때 없이 좋은 조직인 것 같다는 생각이 든다.

전쟁 속에서도 사이드는 피어난다  🌱

현재 관리 중인 사이드는
- 팀 블로그 플랫폼 https://teamlog.cc
- 농구영상 편집기 및 기록 플랫폼 https://cutin.cc
(두 서비스 합쳐서 서버 비용은 월 $20 (25,000원) 쓰고 있음 - 라이트세일)

teamlog는 22년 6월에 시작하여 10개월 걸려 23년 3월 출시하였고 23년 7월까지 개선하다가 멈추었다.
일 사용자는 10명 이내이지만 무엇보다 내가 즐겨 방문해 글들을 보고 있기에 의미가 있다.
회사 개발팀원들의 블로그를 https://teamlog.cc/@flow_dev/blog 로 묶을 수 있기 때문에 또 재밌다.

cutin은 매주 토요농구를 하고 있기에 겸사겸사 영상편집해 보고자 편집기를 만들어 배포하는 걸 시작으로
현재는 기록플랫폼을 만들어 기록과 영상을 연계하여 바로 볼 수 있고 실질적으로 농구동호회에 배포해 보고자 개발 중에 있다.  

나의 허접한 플레이?를 구경해 볼 수도 있다. (허접해도 스스로는 매우 재밌다.)
https://cutin.cc/watch/player/%EC%9C%A0%EB%AF%BC%ED%98%B8?clubCode=gba

사이드의 개발속도는 극히 느리지만 시간의 힘을 믿고 조금씩 지속해서 개선 중이다.
사이드에 쏟는 시간은 평균적으로 일주일에 2시간 정도 되는 것 같은데 줄이면 줄였지 더 늘리기는 정말 어렵다.
짧은 시간이지만 사이드는 제품과 개발에 새로운 시야를 만들어주는 시간이자 스트레스 해소의 영역이 되어버렸다.

사랑스러운 모든 순간 🌸

 아가는 많이 커서 어린이가 되었다. 말이 늘어 이제는 의사소통이 충분히 된다. 귀찮게 하면 코 고는 척도 하고 혼날 땐 사랑한다며 애교를 피는 영리한? 어린이가 되었다. 말썽이 배로 늘었지만 사랑도 배로 늘었다.
 요즘엔 어린이집 등원을 하고 있다. 어린이집이 조금 거리가 돼서 차로는 15분, 버스로는 30분 정도 걸리는데 짧은 시간이지만 아침마다 도란도란 이야기를 나누고 있다. 어린이집 입구에서 가기 싫다고 울 때도 있고 뒤도 안 돌아보고 달려 들어갈 때도 있다. 토요일 아침마다 농구를 가는 아빠에게 '오늘은 두골 넣고 와'라고 응원해 준다. 모든 순간이 사랑스럽고 행복한 느낌이다. 2024년도 이렇게 행복하고 사랑스러운 나날이 계속되길.

끝!