첫 6개월의 전쟁터: 플랫폼개발팀 매니저로 살아남기 — 2019년 하반기 회고

들어가며

2019년 7월 1일, 나는 한 크라우드펀딩 플랫폼의 **플랫폼개발팀 매니저(팀장)**로 합류했다.

첫 출근날, 책상에 앉자마자 받은 브리핑은 이랬다.

"우리 목표는 대한민국 전체 인구의 10%, 500만 회원을 감당하는 플랫폼을 만드는 겁니다."

당시 서비스 현황은? 평일 기준 동시 접속자 2,000명, TPS 700 수준. 리워드 프로젝트 오픈 시간(14시, 16시)에 트래픽이 몰리면 DB CPU가 99.8%를 찍으며 슬로우 쿼리가 폭포처럼 쏟아졌다. 목표와 현실 사이의 간극은 어마어마했다.

이 글은 그 간극을 좁히기 위해 정신없이 달려온 6개월의 기록이다.

1. 현실 파악: 입사 첫 2주

매니저로서 가장 먼저 한 일은 코드가 아니라 사람과 시스템을 파악하는 것이었다.

팀 구성원 1:1 면담

팀원 한 명 한 명과 만나 물었다.

• 지금 가장 큰 기술 부채는 뭐라고 생각하세요?
• 본인이 가장 잘하는 영역은?
• 6개월 후에 어떤 엔지니어가 되고 싶으세요?

이 면담에서 팀의 강점과 병목이 선명하게 보였다. 서버 아키텍처에 강한 시니어, 인프라와 배포에 능한 엔지니어, 데이터 분석에 관심이 큰 주니어 — 각자의 역량 지도를 그린 뒤, 하반기 과제에 매핑했다.

기술 현황 진단

APM 도구(Jennifer)를 열어보니 현실은 냉혹했다.

2. 500만 대응 프로젝트: 성능 5배 끌어올리기

전략: 12개 과제를 4단계로 쪼개기

"TPS를 5배 올려라"는 한 문장의 목표를, 실행 가능한 단위로 분해했다.

슬로우 쿼리와의 전쟁

Jennifer APM으로 에러 데이터를 분석했더니, 매일 10만~15만 건의 Bad Response SQL이 발생하고 있었다. 발생 비율 Top 2는 리워드 카드 리스트 조회 API — 전체 에러의 **96.7%**를 차지했다.

원인을 파헤쳐보니:

• 캐시 TTL이 1초로 설정되어 있어 캐시 히트율이 10% 수준
• RDB 쿼리 수행 시간이 0.8~9초로 편차가 극심
• DB Replication이 없어 읽기/쓰기가 모두 Master 한 대에 집중

또 하나의 숨은 병목은 외부 API 호출이었다. URL 단축 서비스(bitly) 호출이 평균 1초 이상 걸리며, 이것이 연쇄적으로 응답 지연을 일으키고 있었다.

인프라 확장: 서버를 키우는 것만으로는 부족하다

단순히 서버를 늘리기 전에 선행 과제들이 있었다:

1. 어드민 서버 분리 — 관리자 페이지가 서비스 웹 서버에 같이 올라가 있어, 어드민의 무거운 쿼리가 사용자 트래픽에 영향을 줬다
2. 세션 공유 방식 변경 — 서버가 1~2대일 땐 Sticky Session으로 버텼지만, 8대로 늘리려면 세션 클러스터링이 필수
3. Config 서버 도입 — 8대 서버의 설정을 수동으로 관리할 수 없으니 Spring Cloud Config를 도입

이 순서가 뒤집히면 스케일아웃 자체가 불가능했기에, 의존관계를 정리하고 순서를 지키는 것이 매니저로서의 핵심 역할이었다.

3. 검색 엔진 전환: DB LIKE에서 Elasticsearch로

문제: 첫 페이지 접속에 DB 쿼리 27건

메인 페이지를 한 번 로딩하면 DB로 쿼리가 27건 동시에 날아갔다. 그 중 가장 치명적인 것이 제품 검색 — LIKE '%키워드%' 쿼리로 동작하고 있었다. 리워드 프로젝트 오픈 시간에 사용자가 몰리면 이 검색 쿼리가 DB를 잡아먹었다.

전략: 외주와 내부 개발의 이중 트랙

검색 전환은 크게 두 트랙으로 나눴다:

내부적으로 먼저 최소한의 검색 전환을 빠르게 완료하고, 정교한 한글 형태소 분석이나 동의어 사전 관리 같은 기능은 검색 전문 외주 업체와 협력했다.

정책 결정: 성능 vs 데이터 정합성

검색 개선 과정에서 매니저로서 정책적 판단이 필요한 순간이 왔다. Elasticsearch와 RDB 사이의 데이터 동기화 주기를 어떻게 설정할 것인가?

• 기존: 리워드 1초, 투자 3초 주기로 데이터 집계
• 개선안: 동기화 주기를 1분으로 변경

1분으로 바꾸면 성능은 극적으로 좋아지지만, "리스트에서 본 투자 금액"과 "상세 페이지의 금액"이 최대 1분간 불일치할 수 있다. 이걸 사업부와 논의해서 **"사용자 경험상 허용 가능한 수준"**이라는 합의를 이끌어냈다.

기술적 결정이 비즈니스 임팩트를 갖는 순간, 매니저는 엔지니어와 사업부 사이의 통역사가 되어야 한다.

4. MSA 전략: 모놀리스를 어떻게 풀 것인가

현실 직시: 모놀리스의 고통

팀원들과 함께 현재 아키텍처의 문제점을 정리했더니, 목록이 끝이 없었다.

거버넌스 문제

• 데이터 불일치 → 배치/스케줄러로 땜질 → 운영 비용 증가
• 신규 기능 개발 후 어드민, 통계 반영이 따라오지 못함

개발 생산성 문제

• core와 web이 분리되어 있지만 비즈니스 로직이 양쪽에 흩어져 있음
• 사용하는 기능과 사용하지 않는 기능이 혼재 → 영향도 분석에 시간 소모
• 여러 테이블에 걸친 비즈니스 코드 → 추가 기능 분석에 과도한 시간

운영 문제

• 웹 서버 배포에 20분 이상 소요
• DB 전문 인력 부재

판단: "MSA가 정답인가?"

팀 내부에서 치열하게 토론했다. 내가 던진 질문은 두 가지였다:

1. MSA 변화를 위해 개발실의 스킬업과 공감대가 충분한가?
2. 모듈형 모노리틱으로 충분하지 않은가?

결론적으로, 완전한 MSA 전환은 현 시점에서 리스크가 크다고 판단했다. 대신 점진적 접근을 택했다:

5. 미래 투자: ML 연구팀 구축

성능 개선과 아키텍처 정비가 생존을 위한 전투였다면, ML 연구는 미래를 위한 투자였다.

ML 추천 시스템 로드맵

팀 내 데이터에 관심 있는 2명의 엔지니어에게 체계적인 스킬업 시간을 배정했다.

이 로드맵의 핵심은 서비스 개발 업무와 병행 가능한 현실적인 페이스를 설정한 것이다. 매주 수요일 오후를 ML 연구 시간으로 확보하고, 격주로 진행 상황을 공유하는 리듬을 만들었다.

동시에 머신러닝의 비즈니스 적용 방향도 정리했다:

• 개인화 추천: 사용자별 상품(투자/리워드) 추천
• 리스크 관리: 악성 회원 자동 분류, 프로젝트 리스크 사전 감지
• 운영 효율: ML 기반 상품 심사 어드바이저

6. 조직 빌딩: 매니저의 숨은 업무들

기술 과제만 나열하면 화려해 보이지만, 실제로 매니저의 시간 대부분은 눈에 보이지 않는 일에 쓰인다.

장애 대응 프로세스 수립

입사 전에는 장애 대응이 체계화되어 있지 않았다. 1급 장애 대응 프로세스를 새로 만들었다.

장애 등급을 정의하고, 부서별 컨택포인트를 지정하고, 장애 보고서 양식을 표준화했다. 특히 **"발생 시각, 복구 시간, 장애 원인, 영향도, 조치 내용, 재발 방지 대책"**을 반드시 기록하게 한 것은, 같은 실수를 반복하지 않기 위한 장치였다.

기업부설연구소 설립 추진

ML 연구를 체계적으로 추진하기 위해 기업부설연구소 설립도 준비했다. 연구개발활동 개요서, 조직도, 인력 현황서, 연구기자재 현황서를 작성하고, 병역특례와 R&D 세액공제 등의 혜택을 경영진에게 설명했다.

7. 6개월을 돌아보며

타임라인으로 보는 6개월

배운 것들

1. 매니저의 첫 번째 무기는 "우선순위"다

모든 것이 중요해 보이는 상황에서, **"지금 안 하면 서비스가 멈추는 것"**과 **"하면 좋지만 다음 달에 해도 되는 것"**을 냉정하게 구분하는 능력이 가장 중요했다.

2. 기술 결정에는 항상 비즈니스 맥락이 따라온다

검색 동기화 주기 1분 vs 실시간, MSA vs 모듈형 모노리틱 — 순수한 기술 최적해는 없다. "우리 서비스의 사용자는 1분 지연을 허용하는가?"라는 질문에 답하려면, 기술팀 밖으로 나가야 한다.

3. 조직의 속도는 가장 느린 의존관계가 결정한다

서버 스케일아웃을 하려면 세션 공유가 먼저, 세션 공유를 하려면 어드민 분리가 먼저. 이 의존관계 체인을 관리하는 것이 매니저의 핵심 업무다.

4. 미래 투자를 빼먹지 말 것

당장 급한 성능 이슈에 매몰되면, ML 연구나 MSA 전략 같은 중장기 과제가 영원히 "다음에"로 밀린다. 전체 리소스의 20% 정도는 미래 투자에 의식적으로 배분했다.

5. 사람이 먼저다

결국 12개의 성능 과제, 검색 엔진 전환, MSA 전략 — 이 모든 것은 팀원들이 해낸 것이다. 매니저는 방향을 제시하고, 장애물을 치우고, 성장할 기회를 만들어주는 역할이다. 매니저는 현실적으로 이 바쁜 상황에서 개별 면담과 코칭 시간을 빼먹기 쉽지만, 오히려 이 시간이 6개월의 성과를 만들어낸 원동력이었다.

마치며

돌이켜보면, 2019년 하반기 6개월은 내 커리어에서 가장 밀도 높은 시간이었다. 성능 5배 개선, 검색 엔진 전환, MSA 전략 수립, ML 연구팀 구축, 장애 프로세스 체계화, 외부 세미나 기획 — 이 모든 것을 6개월 안에 병렬로 추진했다.

완벽했느냐고 묻는다면, 절대 아니다. MSA 전환은 여전히 진행형이었고, ML 추천은 아직 서비스에 반영되지 못한 상태였다. 하지만 6개월 전에는 방향조차 없었던 과제들에 로드맵과 추진 인력과 첫 번째 마일스톤이 생겼다는 것, 그것이 이 6개월의 진짜 성과였다.

새로운 조직에 기술 매니저로 합류하는 분들께 한마디 하자면:

첫 6개월은 "완성"이 아니라 "방향 설정"의 시간이다. 모든 것을 끝내려 하지 말고, 모든 것이 올바른 방향으로 움직이기 시작하게 만들어라.