레거시와의 전쟁, PO 체제 전환, 그리고 57명의 CTO 조직: 2022년 회고

들어가며

2022년은 안과 밖 모두에서 전쟁이었다.

안으로는 10년 넘은 모놀리식 레거시의 WAS 스레드 문제가 반복적으로 서비스를 흔들었고, 밖으로는 카카오 데이터센터 화재라는 전례 없는 외부 장애에 대응해야 했다.

조직은 57명 규모의 CTO 조직으로 성장했고, 기능 조직(팀 기반)에서 **PO밴드 체제(목적 조직)**로 전환하는 대수술을 단행했다. 동시에 기술 문서 문화를 정착시키고, 해외 개발 아웃소싱을 본격 도입하고, 주간 프로덕트 미팅을 운영하며 데이터 기반 의사결정을 밀어붙인 한 해였다.

1. 레거시와의 전쟁: WAS 스레드 문제 근본 해결

반복되는 유령 같은 장애

대규모 트래픽 유입 후 트래픽이 빠져도 특정 서버의 응답 지연이 자연 복구되지 않는 문제가 반복되었다. L4에서 해당 서버를 제외하고 재시작하거나, 전체 재배포로 대응하는 상황 — 근본 원인이 파악되지 않은 채 임시 처치만 반복하고 있었다.

5단계에 걸친 근본 원인 분석

이 문제를 해결하기 위해 체계적인 분석 시리즈를 진행했다.

Slow Query 장애 방지 체계

동시에 Slow Query로 인한 장애 전파 방지 체계도 수립했다. 모놀리식 아키텍처에서 하나의 Slow Query가 전체 서비스를 멈추는 문제에 대해, JDBC timeout 설정(Transaction Timeout, Statement Timeout)을 체계적으로 검토하고 적용했다.

2. 카카오 데이터센터 화재: 외부 장애 대응

2022년 10월 15일 토요일

카카오 데이터센터에 화재가 발생하면서, 카카오 관련 서비스(알림톡, 카카오페이, 카카오 로그인 등)가 전면 중단되었다. 플랫폼에서도 카카오 관련 기능이 연동되어 있어 즉각 대응이 필요했다.

장애 보고서를 작성하고, 카카오 의존성이 있는 모든 기능을 점검하고, Fallback 처리 현황을 파악했다. 이 사건은 외부 서비스 의존도에 대한 경각심을 조직 전체에 심어준 계기가 되었다.

3. 기능 조직에서 PO밴드 체제로

왜 조직 구조를 바꿨는가

기존의 기능 조직(FE팀, BE팀, QA팀 등)은 **"누가 이 기능을 만들 것인가"**에 최적화되어 있었지만, **"왜 이 기능을 만들어야 하는가"**에는 취약했다.

2022년 상반기, CTO 리더십 교육(sudo 2022 컨퍼런스)에서 다른 스타트업의 사례를 집중적으로 학습했다:

• 데이원컴퍼니(패스트캠퍼스): 3명 → 60명 팀빌딩 경험
• 29CM: 시스템/제품팀 관점의 성장기

이를 바탕으로 하반기에 PO(Product Owner) 밴드 체제로 전환했다.

각 PO밴드에 기획, 디자인, FE, BE, QA 인력이 크로스펑셔널로 배치되어, 하나의 제품 영역에 대한 오너십을 갖고 운영하는 구조.

전환의 현실

조직 구조 변경은 발표로 끝나지 않는다. QnA 세션에서 나온 질문들이 현실의 복잡함을 보여줬다:

• "PO밴드 간 담당자 이동이 가능한가?"
• "기존 SVCREQ(서비스 요청)는 어떻게 운영되나?"
• "데일리 스크럼은 밴드별로? 팀별로?"

이런 디테일 하나하나를 정리하고, FAQ 문서를 만들고, 주간 디렉터 회의에서 지속적으로 조율했다.

4. 기술 문서 문화와 프로덕트 미팅

기술 문서 작성 문화 정착

2022년 초, CTO 조직 전체에 기술 문서 작성 문화를 본격 도입했다. 1분기 OKR에 **"기술 문서 50개 작성"**을 KR로 설정할 정도로 강하게 밀어붙였다.

"블로그는 기술 문서 중에서 외부 공개 가능하고, 개발 문화 전파와 채용에 도움이 되는 글을 선정합니다."

기획팀의 정책 분기 처리 문서, FE의 성능 개선 사례, 플랫폼의 AWS 마이그레이션 기법, HTTP Proxy를 활용한 레거시 연동 등 — 팀원들이 실제 업무에서 겪은 경험을 문서로 남기기 시작했다.

주간 프로덕트 미팅

하반기부터 주간 프로덕트 미팅을 운영했다. 대표, CTO, PO, 디렉터가 모여 제품 방향과 데이터를 리뷰하는 자리.

매주 논의된 주제들:

• 찜하기 기능의 결제 전환율 데이터
• 통합 AI 추천 로직의 A/B 테스트 결과
• 메인 영역별 클릭 데이터 분석
• 검색 개편 효과 측정

5. 2022년을 돌아보며

타임라인으로 보는 1년

배운 것들

1. 레거시는 "방치"하면 이자가 붙는다

10년 된 Apache BIO 설정, 디폴트 timeout, 세션 관리 방식 — 이런 것들이 복합적으로 얽혀 반복 장애를 만들었다. 레거시를 방치할수록 해결 비용은 기하급수적으로 증가한다. 작게라도 꾸준히 개선하는 것이 유일한 답이다.

2. 조직 구조 변경은 "발표"가 아니라 "운영"이다

PO밴드 전환을 발표하는 것은 하루면 되지만, 실제로 새 구조가 동작하려면 수개월의 조율과 FAQ 대응과 문화 변화가 필요하다. 조직 변경의 80%는 발표 이후에 일어난다.

3. 데이터가 토론의 언어가 되어야 한다

주간 프로덕트 미팅에서 "찜하기 페이지 일 결제금액 2,500만원", "AI 추천 개선안 8~9% 클릭률 향상" 같은 숫자가 의사결정을 이끌었다. 데이터 없는 토론은 의견 대결이고, 데이터 있는 토론은 의사결정이다.

마치며

2022년을 한 문장으로 요약하면, **"레거시를 직시하고, 조직을 재설계하고, 데이터로 의사결정하기 시작한 해"**였다.

4년간의 여정을 돌아보면, 2019년에는 서버 2대를 8대로 늘리는 것이 가장 큰 과제였고, 2022년에는 57명 조직의 일하는 방식을 바꾸는 것이 가장 큰 과제가 되었다. 기술의 복잡도는 변했지만, **"올바른 문제를 찾고, 올바른 방법으로 해결하고, 그 과정에서 팀이 성장하게 만드는 것"**이라는 CTO의 본질은 변하지 않았다.

기술 부채는 코드에만 있는 것이 아니다. 조직 구조, 일하는 방식, 의사결정 프로세스에도 부채가 쌓인다. CTO의 역할은 이 모든 종류의 부채를 인식하고, 상환 계획을 세우고, 팀과 함께 갚아나가는 것이다.