docs: 2024 회고 업데이트

docs/02.retrospect/2025-02-19-Y2024.md

@@ -0,0 +1,128 @@
+---
+layout: post
+title: 서버 개발자, 2024 회고
+sidebar_label: 2024 회고
+parent: retrospect
+lang: ko
+nav_order: 24
+permalink: /docs/retrospect/2024
+sitemap:
+  lastmod: 2025-02-19
+---
+
+24년은 작년에 맡았던 백업 서비스들을 고도화하는 작업들을 해볼 수 있는 시간이었다.  
+작년에 진행했던 팀 문화를 이끌고 개선해나가는 것과 모듈의 핵심 로직들에 대한 대규모 리팩토링이 바탕이 되어 서비스 개선을 위한 작업들을 더 수월하게 해낼 수 있었다.  
+내년엔 새로운 서비스를 맡게 되었는데 올해 고도화 작업을 많이 진행할 수 있어서 다행이다.
+
+
+## 지표에 대해 고민하기
+
+부끄럽게도 우리 팀이 맡고 있는 서비스들은 지표가 굉장히 부족하다. 그럼에도 24년 초까지는 '지표가 부족하다는 것' 자체를 인지하지 못했다.   
+올해는 팀 리더의 강력한 의지로 **체감품질**을 정리해보는 시간이 됐다.  
+처음엔 '이게 필요한가?'라는 생각으로 지표 작업을 시작했다. '다른 개발을 미루면서까지 하는게 맞을까' 생각도 했지만 결과적으로 많이 배울 수 있는 시간이었다.
+
+24년을 마무리하는 지금 지표가 왜 필요한지는 명확해 졌다.  
+지표는 그저 보고 자료인 것이 아니라 꼭 필요한 것이라는 것을 배웠다.
+
+### 1. 보고와 성과
+
+쿠팡 같은 서비스 회사들의 뉴스 기사를 보다보면 '어떤 이벤트가 어떤 결과를 가져왔다'는 기사를 보게 된다.  
+전엔 별 생각이 없게 봤던 뉴스지만 이제 다르게 보였다. **할인 이벤트를 준비한 팀에게 사용자와 매출 증가와 같은 결과를 냈다는 것**은 분명한 성과이자 명확한 보고이다.
+
+여태까지 우리 팀은 '이러이러해서 좋습니다' 같은 보고를 해왔다.  
+명확한 지표가 없기 때문에 이렇게 보고 되었던 것은 결국 우리 팀의 좋은 성과를 가볍게 만드는 아쉬운 역할을 했다.  
+지표는 어떤 면에서는 그 어떤 개선 작업보다도 중요하다. 명확한 지표가 없이는 성과도, 성과에 따른 보상도 명확해질 수 없다.
+
+### 2. 목표 설정
+
+대부분의 회사들의 연초 목표는 '매출 x 달성'과 같은 목표가 잡힌다.  
+그렇다면 서비스를 개발하는 개별 팀의 목표는 무엇인가?  
+그 목표가 바로 지표와 연결되어야 한다.
+
+우리 팀은 '이런이런 기능 제공' 혹은 '이런이런 개선 활동'과 같은 목표가 잡힌 적이 많았다.  
+그렇지만 명확한 지표를 통해 'MAU x 달성', '백업 완료 시간 x % 감소'와 같은 명확한 목표와 이 목표를 위한 개선/기능 추가 작업이 이루어지는 것이 맞다.  
+지표가 없다면 목표가 모호해지고, 목표 달성 또한 모호해진다.
+
+### 3. 문제 확인
+
+우리의 지표는 대부분이 'api의 성공률' 같은 것들이 대부분이었다.  
+이를 통해 확인할 수 있는 문제들도 있지만 서비스에 따라 정의되어야 하는 '품질 지표'가 명확하지 않다면 어떤 문제들은 발견이 늦어지기도 한다.  
+지표를 통해 문제를 찾을 수 있고, 고객 만족도와 경험을 개선하기 위한 작업들이 이어질 수 있다.
+
+
+## redesign
+
+작년엔 legacy 모듈을 맡고 신규 feature를 개발하면서 코드 레벨의 리팩토링과 내부 아키텍처 정리를 하는데 힘을 많이 썼다.  
+올해는 좀 더 큰 그림에서 작업들을 진행했는데, 리팩토링보단 redesign에 가까울 것 같다.
+
+### 1. 배치 개선을 위한 iService 도입
+
+서비스에 있던 묵은 배치 서버는 눈엣가시 같은 컴포넌트였다.  
+서비스의 로직들을 그대로 갖고 만든 배치 서버는 시간이 지나면서 서비스 코드와 벌어지며 문제를 만들었고, 유지보수 난이도를 높였다.  
+이를 개선하기 위한 작업들을 진행했고 깔끔하게 마무리 됐다.
+
+1. 배치 서버 로직을 서비스 서버로 이동
+2. 배치 수행을 위한 서비스 서버를 별도 도메인으로 deploy (Service, iService)
+3. 배치 event consumer가 iService로 배치 로직을 요청하도록 변경
+4. 배치 서버 down
+
+모니터링도 불가능하고, shard 적용 및 신규 피처에 대한 적용 어려움과 유지보수 난이도 상승, 떨어지는 신뢰도의 문제들을 위와 같은 방식으로 해결할 수 있었다.  
+특히 DB에 접근하는 동일한 로직을 여러 코드에서 중복으로 사용하는 점이 서비스 중 유지보수 과정에서 문제가 되는 경우가 제법 되었는데, 이걸 service - iService 구조로 풀어낸 것도 좋은 방향이었다.
+
+### 2. MSA와 on time migration 설계
+
+legacy 서비스를 없애는 것은 당연한 방향이나 사용자의 데이터를 관리하는 클라우드 서비스 특성상 쉽지 않은 경우가 많다.  
+legacy 서비스를 신규 서비스로 migration 하는 작업을 진행했다.
+멀티 디바이스와 앱 버전에 따라 다르게 동작해야 하는 요구사항을 정리하여 신규 서비스에 접근하는 사용자에 대해 on time migration을 수행할 수 있도록 했다.
+
+migration event 발행, event에 따른 migration trigger, migrator를 위한 internal service 모듈까지 MSA를 통해 안정적으로 구성했고, migration의 정합성을 위해 migration 기간에만 legacy와 신규 서비스가 공유하는 shared repository 구조를 채택했다.
+
+이번 설계는 on time migration을 위해 여러 요소를 고민하면서 event base로 역할과 기능을 명확하게 MSA로 구분해낸 점과 일반적으로 안티 패턴으로 분리되는 shared repository를 적절하게 사용한 점이 기억에 남는다.
+
+### 3. refactoring++
+
+작년에 진행한 코드와 아키텍처 단위의 리팩토링을 통해 가독성과 유지보수성이 많이 확보됐다.  
+이전엔 볼 수 없었던 비효율들을 발견할 수 있었는데 단순히 리팩토링이 아니라 data access pattern의 최적화를 이뤄낼 수 있었다.  
+기존에 비효율적으로 S3를 접근하고 사용하던 시나리오를 들어내고 동일한 요구사항을 더 안정적이고 효율적으로 개선했다.
+
+인상적인 점은 신경쓰지 못하고 운영하던 legacy의 비효율적인 코드를 리팩토링 후에 발견해낼 수 있었다는 점이다.  
+이 개선으로 생각하지 못했던 큰 규모의 비용 개선을 이뤄낼 수 있었다.
+
+
+## 정책에 대해 고민하기
+
+정책에 대한 문제는 서비스를 하면서 계속 고민이 되는 부분이다.
+서비스가 이미 출시된 이후로 정책을 바꾸는건 쉽지 않아서 미뤄두게 되었는데 이번에 일부 정책을 정리할 시간이 되어서 좋았다.
+
+### 1. life cycle
+
+여러 고민해야 할 정책들이 있지만 가장 중요한 것 중 하나는 life cycle이 아닐까 싶다.  
+data life cycle이 명확하지 않다면 garbage 처리를 진행할 수 없어 계속 쌓이게 된다.
+
+이번에 백업의 life cycle을 명확하게 정리했다.  
+state diagram을 그리고, state 별로 삭제할 수 있는 데이터들을 분리했다.  
+각 state에 맞춰 발생되는 event를 정의하고 이에 따라 삭제 로직을 정리했다.
+
+state와 state에 따른 데이터, event를 정의하니 명확하게 데이터를 정리하고 사용할 수 있었다.
+
+### 2. policy 정리
+
+legacy 서비스의 문제 중 하나는 policy 라는 개념이 존재하지 않거나, 파편화되어 있다는 것이다.  
+서비스를 유지보수하며 필요한 policy 들이 개별 코드에 들어가거나 재사용되지 않아서 여기저기 코드가 파편화되어 가독성을 헤친다.  
+그리고 policy 변경에 따른 적용이 예상처럼 되지 않는 문제들이 이어진다.
+
+1. 사용하지 않는 policy를 제거
+2. 산개되어 있는 policy를 정리
+3. domain에 policy를 추가
+4. policy를 순차적으로 domain으로 전환 및 배포
+
+위와 같은 방식으로 도메인 policy가 의도대로 수정되고 반영될 수 있는 구조를 만들었다.   
+policy도 domain 이어야 한다는 생각을 갖고 손대고 싶었는데 대지 못했던 부분들을 정리할 수 있는 좋은 기회가 되었다.  
+policy가 규모가 있다면 서비스가 MSA로 나가기 위해서 policy 부터 하나의 service로 분리되어야 한다는 생각을 했는데, 온전한 MSA로 전환하기엔 아직 길이 멀다.
+
+
+---
+
+서비스를 오래 하면서 '이제 연간 회고에서 어떤 새로운 배운점들을 얘기할 수 있을까?' 생각이 들었는데 생각보다 정리할게 많았다.  
+해가 갈수록 더 큰 그림을 보게 된다.  
+이제는 코드와 아키텍처 위의 서비스와 품질, 정책에 대해서 고민하게 되는데 내년에 새로운 도메인을 맡아 개발하게 될 때 이런 경험들을 어떻게 사용하게 될지.