코로나, 마스크 대란, 그리고 조직 확장: 플랫폼개발팀 디렉터 — 2020년 회고
들어가며
2019년 하반기, 정신없이 달려온 첫 6개월이 끝나고 2020년이 시작되었다. "올해는 좀 더 체계적으로 해보자"고 다짐했는데, 세상이 먼저 뒤집어졌다.
코로나19 팬데믹.
2월부터 재택근무가 시작되었고, 같은 달에 마스크 프로젝트 하나가 서비스를 통째로 흔들었다. 조직은 3개 팀으로 분화했고, 정부 R&D 과제 수주라는 새로운 도전도 시작되었다.
이 글은 크라우드펀딩 플랫폼의 플랫폼개발 디렉터(매니저) 2년차가 겪은 2020년의 기록이다.
이전 글에서 다뤘던 500만 대응 프로젝트, 검색 엔진 전환, MSA 전략 — 이것들이 2020년에 어떤 결실을 맺었고, 또 어떤 새로운 과제를 만들어냈는지를 중심으로 이야기합니다.
1. 마스크 대란: 성능 개선의 진짜 시험대
2020년 2월 22일 토요일, 14시
그날은 토요일이었다. 마스크 펀딩 프로젝트가 14시에 오픈되었고, 동시 접속자 7,500명이 몰렸다.
2019년에 웹 서버를 2대에서 8대로 늘리고, DB Replication을 적용하고, 슬로우 쿼리를 잡았지만 — 7,500명은 또 다른 차원의 문제였다.
| 시각 | 상황 |
|---|---|
| 14:02~14:04 | 전체 서비스 접속 장애 발생 |
| 14:05~14:15 | 간헐적 접속 장애 지속 |
| 14:15 이후 | 점진적 정상화 |
장애 원인 분석
장애 보고서를 작성하면서 원인을 파헤쳤다.
단일 병목이 아니라 여러 지점이 동시에 터지는 복합 장애였다. Redis 세션 관리의 netty thread 설정 문제, JSP 페이지의 구조적 한계, MongoDB의 부하 분산 부재가 겹쳤다.
개선: 한 단계 더 깊이
이 장애를 계기로 성능 개선의 깊이가 달라졌다.
| 영역 | 개선 내용 |
|---|---|
| Redis | 세션 관리 netty thread 튜닝, 설정 최적화 |
| DB | Slave 활용 확대, 캐시 레이어 강화 |
| MongoDB | Replication 확대, Second Level Cache(Redis) 도입 검토 |
| 모니터링 | 대용량 트래픽 시 로그 수집 실패 → Elastic APM 도입으로 JMX 기반 모니터링 전환 |
| 장애 대응 | Fallback Default Data 준비 (기획팀과 협의) |
2019년에 "5배 성능 개선"을 달성했다고 자축했지만, 실전에서는 예상치 못한 조합의 병목이 터진다. 성능 개선은 "완료"가 아니라 "계속"이다.
이후에도 3월에만 두 건의 장애가 추가로 발생했다 — 3월 17일의 트래픽 급증 장애, 3월 20일 새벽 4시의 DB 장애. 매 건마다 장애 보고서를 작성하고, 원인을 분석하고, 재발 방지 대책을 수립하는 사이클을 반복했다.
2. 코로나와 재택근무: 매니저의 새로운 도전
갑작스러운 리모트 전환
2월부터 재택근무가 시작되었다. 기술적 문제보다 매니저로서의 도전이 더 컸다.
- 팀원들의 업무 진행 상황을 어떻게 파악할 것인가?
- 재택에서도 팀 간 협업이 원활하게 이루어지는가?
- 성과를 어떻게 공정하게 측정할 것인가?
퍼포먼스 로그 시스템 도입
팀원별 퍼포먼스 로그를 도입했다. 매주 각자 Todo(계획), Done(완료), Feedback(직책자 피드백)을 기록하는 방식이다.
핵심 원칙:
- 데일리 미팅: 매일 아침 각자 2분 이내로 계획과 어제 진행 사항 공유
- 주간 리뷰: 전주 업무 전체 리뷰 및 다음주 계획
- Jira 연동: 모든 업무가 Jira에 표현되도록 체계화
인사팀과의 협의에서 내가 강조한 것은 **"Output 기반 성과 측정"**이었다. 시간 추적(Time tracking)이 아니라 산출물로 평가하겠다는 방향. Jira Structure를 활용해 팀 전체의 업무를 한 눈에 볼 수 있는 대시보드를 구축했다.
강제로 시작된 재택근무가 오히려 업무 가시성을 높이는 계기가 되었다. 사무실에서는 "옆에 앉아 있으니 대충 파악 가능"이라는 착각이 있었는데, 재택이 되면서 체계적인 업무 추적의 필요성이 분명해졌다.
3. 조직 확장: 1개 팀에서 3개 팀으로
디렉터로의 역할 변화
2020년에 가장 큰 변화는 조직 구조였다. 2019년에는 플랫폼개발팀 한 팀을 이끌었지만, 2020년에는 3개 팀을 관장하는 디렉터 역할로 확장되었다.
각 팀의 역할을 명확히 정의했다:
| 팀 | 핵심 미션 |
|---|---|
| 시스템 플랫폼 | 서비스 안정화, 장애 관리, 인프라 운영, 공통 기능(결제/파일/알림) 개발, Kubernetes 도입 |
| 데이터 플랫폼 | 전사 데이터 분석 플랫폼 구축, 프로젝트 리스크 감지, 추천 서비스, 정부 R&D 과제 수행 |
| QA | 서비스/플랫폼 QA, 테스트 자동화, TC 관리 |
매니저를 매니징하기
개별 팀원을 직접 관리하던 것에서 매니저를 통해 간접 관리하는 방식으로 전환하는 것은 완전히 다른 스킬이었다.
내가 실천한 원칙들:
- 각 매니저에게 자율권 부여 — Jira 운영 방식, 데일리 미팅 형태 등은 매니저가 결정
- 주간 OKR 리뷰 — 대표 주관 전사 OKR 회의에 3개 팀의 진행 상황을 대변
- 채용 프로세스 체계화 — 서류 평가 → 코딩 테스트 → 1차 기술 면접 → 2차 컬쳐 면접의 파이프라인 정립
4. OKR 도입: 목표 관리의 프레임워크 변화
2020년은 조직에 OKR(Objectives and Key Results) 이 본격 도입된 해였다.
분기별 OKR 사이클
매 분기마다 전사 OKR과 정렬(Align)된 팀 OKR을 설정하고, 매주 대표 주관 리뷰 회의에서 진행 상황을 점검했다.
2020년 하반기 플랫폼개발 OKR의 핵심은:
O1. 서비스 구조 개선을 통해 개발 생산성 기반을 마련한다
- KR1) 주요 서비스의 신규 API 서버와 독립적 프론트엔드 구축
- KR2) 레거시를 신규 구조로 개선
O2. 데이터 기반 서비스로 사용자 신뢰를 증대시킨다
- KR1) 프로젝트 리스크 사전 감지 서비스를 데일리로 운영
- KR2) AI 기반 추천 고도화
O3. 보안 조치와 잠재 리스크 개선으로 서비스 신뢰를 향상한다
- KR1) 장애 발생 가능 요소 개선을 월 2건 이상 진행
OKR은 좋은 프레임워크지만, 운영성 업무와의 균형이 항상 과제였다. 장애 대응, 긴급 배포, 인프라 이슈 — 이런 것들은 OKR에 명시되지 않지만 팀 리소스의 상당 부분을 차지한다. "KR에 없으니 안 해도 된다"가 아니라, 운영 안정성이 모든 KR의 전제조건이라는 인식을 팀에 심는 것이 중요했다.
5. 정부 R&D 과제 수주: 기술 조직의 새 도전
AI 크라우드펀딩 이상 징후 탐지 과제
2019년에 씨앗을 뿌린 ML 연구가 2020년에 정부 R&D 과제 수주라는 결실로 이어졌다.
과제명: "AI(인공지능)를 이용한 크라우드 펀딩 이상 징후 탐지 기술 및 개인화 추천 기술 개발"
| 단계 | 시기 | 내용 |
|---|---|---|
| 지원 분야 검토 | 2월 | 4차 산업혁명 전략 분야 중 적합 품목 선정 |
| 사업계획서 작성 | 2~4월 | 기술성(개발실) + 사업성(경영) 공동 작성 |
| 대면 평가 | 5월 | 평가 피드백 반영 후 사업계획서 수정 |
| 최종 선정 | 5월 28일 | 종합 평가 결과: 최종 선정 |
| 협약 체결 | 6월 | 연구 노트 작성 시작, 과제 본격 수행 |
과제 수행: 데이터 플랫폼 구축
과제의 핵심은 두 가지였다:
- 정형/비정형 데이터 플랫폼 구축 — 전사 데이터를 통합 분석할 수 있는 인프라
- AI 기반 이상 징후 탐지 + 추천 — 악성 회원 사전 감지, 프로젝트 리스크 판단, 개인화 추천
매월 연구 노트를 작성하고, 분기마다 진척 보고를 하는 것은 일반 서비스 개발과는 전혀 다른 리듬이었다. 하지만 이 과제 덕분에 데이터 플랫폼팀이 체계적인 로드맵 아래에서 집중할 수 있는 명분과 리소스를 확보할 수 있었다.
6. 개발 문화 개선: 팀원들의 목소리
2020년 중반, 개발 문화에 대한 팀원들의 솔직한 목소리를 수집했다.
요청 사항 Top 5
| 영역 | 팀원들의 의견 |
|---|---|
| 문화 | 주기적 All-Hands Meeting, 공식 Slack Day |
| 개발 | 코드 리뷰 문화 정착, TDD 도입, 기획 단계부터 개발자 참여 |
| 배포 | 배포 주기 정규화 (매일 → 주 2회) |
| 장애 | 장애 리뷰 문화, Post-Mortem — 탓하지 않는 분위기 |
| 프로젝트 | PM 역할 명확화, 변경 사항 관리, 히스토리 추적 |
가장 인상 깊었던 의견은 **"장애를 탓하지 않는 분위기와 Post-Mortem 문화가 있으면 좋겠습니다"**였다. 2019년에 장애 대응 프로세스를 만들었지만, 그것은 프로세스일 뿐 문화는 아니었다.
이를 계기로 실천한 것들:
- 주 2회 배포 프로세스 시범 운영
- **장애 보고서를 "비난의 도구"가 아닌 "학습의 기록"**으로 포지셔닝
- 워크 그룹(스터디) 제도 도입 — Python 스터디 등 자발적 기술 학습 지원
7. 2020년을 돌아보며
타임라인으로 보는 1년
| 분기 | 주요 활동 |
|---|---|
| 1Q | 마스크 대란 장애 대응 및 성능 개선, 재택근무 전환, 정부 R&D 과제 사업계획서 작성, 장애 보고서 체계 강화 |
| 2Q | R&D 과제 최종 선정, OKR 2분기 본격 운영, 리모트워크 성과 측정 체계 구축, 개발 문화 서베이 |
| 3Q | 조직 3팀 체제 안정화, 데이터 플랫폼 1차 구축, 서비스 KMS(지식관리) 체계 정비 |
| 4Q | 퍼포먼스 로그 시스템 정착, DevOps 서비스 문서화, 2021년 목표 수립 |
숫자로 보는 2020년
| 지표 | 내용 |
|---|---|
| 관장 팀 수 | 1개 → 3개 (시스템플랫폼, 데이터플랫폼, QA) |
| 관장 인원 | 약 15명+ |
| 장애 보고서 작성 | 5건+ (전부 원인 분석 + 재발 방지 대책 포함) |
| OKR 리뷰 | 매주 대표 주관 회의 참석 (약 40회+) |
| 정부 R&D | 과제 수주 및 수행 시작 |
배운 것들
1. 성능 개선에 "완료"는 없다
2019년에 5배 개선을 달성했지만, 2020년 마스크 대란에서 또 터졌다. 트래픽은 예측 불가능하게 성장하고, 병목은 항상 새로운 조합으로 나타난다. 성능은 지속적 관리 대상이다.
2. 위기가 체계를 만든다
코로나 재택근무가 퍼포먼스 로그를, 마스크 장애가 Elastic APM 도입을 만들었다. 위기 상황에서 "임시 대응"에 그치지 않고 체계를 만들어 남기는 것이 매니저의 역할이다.
3. 매니저의 매니저는 다른 직업이다
팀원을 직접 관리하는 것과, 매니저를 통해 간접 관리하는 것은 완전히 다른 스킬셋이 필요하다. 위임의 범위를 명확히 하고, 결과로 평가하되, 과정에서 코칭하는 밸런스가 핵심이다.
4. 기술 리더는 기술만 하면 안 된다
OKR 리뷰, 정부 과제 사업계획서, 인사팀과의 성과 측정 협의, 채용 프로세스 설계 — 2020년 업무의 절반 이상이 "코드가 아닌 일"이었다. 기술 리더가 이런 업무를 기피하면, 결국 팀이 제대로 된 환경에서 일할 수 없게 된다.
5. 팀원의 목소리를 듣는 시간을 빼먹지 말 것
개발 문화 서베이에서 나온 "장애를 탓하지 않는 Post-Mortem 문화" 요청은, 내가 미처 인식하지 못했던 조직의 두려움을 보여줬다. 바빠도 팀원들이 솔직하게 말할 수 있는 채널을 유지하는 것이 중요하다.
마치며
2019년이 "방향 설정"의 해였다면, 2020년은 **"체계 구축과 확장"**의 해였다.
1개 팀에서 3개 팀으로, 팀원 직접 관리에서 매니저 매니징으로, 목표 관리 없이에서 OKR로, 단발성 ML 연구에서 정부 R&D 과제로 — 모든 축에서 한 단계 업그레이드가 이루어졌다.
동시에 코로나라는 예상치 못한 변수가, 재택근무 성과 관리, 원격 협업, 비대면 채용이라는 새로운 과제를 안겨줬다.
돌이켜보면 2020년의 가장 큰 성과는 특정 기술 과제의 완료가 아니라, "이 조직이 내가 없어도 돌아갈 수 있는 체계"를 만들기 시작한 것이다. 매니저에서 매니저의 매니저로 성장한다는 것은, 결국 자신의 부재에도 팀이 흔들리지 않을 구조를 설계하는 일이다.
2년차 매니저의 핵심 과제는 "내가 잘하는 것"이 아니라 "팀이 잘 돌아가는 것"을 만드는 일이다.