사례 05 · 주요 사례
바탕이 되는 개발력: 수십억 노출과 스스로 도는 마켓플레이스
- 과거 운영 사례 —— 권리는 고용주에 귀속
같은 애드테크 회사에서 두 차례, 합쳐서 11년: 4년은 플랫폼 개편에서 유일한 프론트엔드 엔지니어, 이어서 셀프서비스형 광고 마켓플레이스를 처음부터 구축, 그리고 초당 수만 건의 요청을 받는 백엔드입니다.
- 역할
- Software Engineer, then Senior Software Engineer
- 역량
- 규모 · 플랫폼 · 직접 구현
- 영역
- 애드테크 —— 퍼블리셔, 영업, 광고 운영
- 기간
- 두 차례, 11년
배경
퍼블리셔, 영업, 광고 운영 플랫폼을 하는 애드테크 회사입니다. 2011년에 입사했고 2017년에 제 회사를 시작하려고 나왔습니다. 그 뒤 2년 동안 두 번 연락이 왔고, 2019년에 직급을 올려 돌아가 팬데믹 전 기간을 함께했습니다.
과제와 불분명했던 점
11년 동안 세 개의 다른 문제가 있었지만 모양은 같았습니다: 어떤 규모에서는 도는 것이 다음 규모에서는 돌지 않는다 —— 그리고 고쳐야 할 곳은 늘 모두가 보고 있는 부분이 아니었습니다.
내 역할
1~4년차: 플랫폼 운영 화면을 옛 시스템에서 새 시스템으로 개편하는 프로젝트에서 유일한 프론트엔드 엔지니어이자 QA 겸임. 5년차: 백엔드로 옮기고 싶다고 직접 요청해 받아들여졌습니다 —— 발령이 아니라 제가 요청한 것입니다. 그 뒤 회사의 B2B 셀프서비스형 광고 마켓플레이스를 구축했고, CTO 직속으로 일했습니다. 두 번째 재직 기간에는 백엔드와 API 개선, 그리고 새 API 구조로의 이전을 주도했습니다.
요구사항 파악
그 운영 화면들은 디자인 연습이 아니라 사업의 날이 서 있는 사용성 문제였습니다: 상담을 확신 단계를 따라 성사까지 밀고, 다시 집행 수명 주기로 잇는 영업 파이프라인. 국가, 광고주, campaign, flight, 광고 지면, 소재 계층을 아우르는 집행 관리 화면. 그리고 지면 설정, 수익 적립, 출금 신청까지 포함하는 퍼블리셔 백오피스. 이것들을 제대로 만들 수 있었던 것은 사양서 앞이 아니라 광고 운영과 영업 옆에 앉아 있었기 때문입니다.
설계와 트레이드오프
규모에 관한 작업은 옛 구조를 새 API 면으로 옮기는 것이었고, 양쪽 다 결국 같은 하나입니다: 일을 요청 경로 밖으로 빼내기. 광고 텔레메트리 —— 노출, 클릭, 광고 안에서 어떤 요소가 눌렸는지 —— 는 이벤트마다 호출하면 서버가 넘칩니다. 그래서 이벤트를 모아 두었다가 일정 간격으로 별도의 기록 서비스로 보내 본체 밖에서 처리한 뒤 되씁니다. 리포트는 원래 동기로 생성돼서 다 끝날 때까지 페이지가 멈춰 있었습니다. 그 부분을 워커 배치 처리로 옮겨, 페이지는 즉시 뜨고 작업이 끝나면 알리도록 했습니다.
구현과 연동
그 마켓플레이스는 사업 면이 온전히 갖춰진 것입니다: 광고를 패키지와 플랜으로 묶고, 복잡한 코어 위에 의도적으로 단순하게 만든 회원 계층을 씌우고, 회사의 API 엔진에 붙였습니다. 구매자 쪽은 셀프서비스 주문과 관리, 소재 업로드, 선불 포인트 충전과 차감. 퍼블리셔 쪽은 수익 적립과 출금 신청. 퍼블리셔는 패키지를 올리고 자기 지면을 설정해 판매할 수 있습니다.
운영 단계의 장치
리포트 제출은 멱등하게 만들었습니다 —— 새로고침해도 이미 돌고 있는 작업이 중복으로 시작되지 않습니다. 사용자가 일주일 안에 반드시 밟는 종류의 결함입니다. 부하가 높은 경로에는 다층 캐시, 데이터베이스 쿼리 튜닝, 그리고 Node.js 재작성을 넣었습니다.
결과
플랫폼 규모: 이 백엔드들은 초당 수만 건의 요청, 월 수십억 건의 광고 노출을 처리합니다. 이 숫자가 말하는 것은 플랫폼의 규모이지 제가 혼자 담당한 컴포넌트의 것이 아닙니다 —— 제가 담당한 것은 그중 특정 백엔드 경로입니다. 그 경로들에서는 앞에 적은 배치 처리, 쿼리 튜닝, 다층 캐시, Node.js 재작성으로 p95 응답 시간이 100밀리초 안으로 들어왔습니다. 잰 것도 손댄 그 경로들입니다.
가져갈 수 있는 배움
규모에서의 두 성과는 같은 하나의 동작에서 나왔습니다 —— 일을 요청 경로 밖으로 빼내기 —— 그리고 둘 다 재작성이 필요 없었습니다. 그 처리량 숫자는 그 판단의 결과이지, 그 자체가 성과는 아닙니다. 숫자에 대해 질문받기보다 구조에 대해 질문받는 편이 좋습니다.
공개할 수 있는 근거
위에 적은 것이 공개해서 말할 수 있는 범위입니다. 아래는 비공개인 것과 준비 중인 것입니다:
Charlie의 보완 필요 —— 이 10년은 코드 저장소보다 자료(항목 P8)로 보여 주는 편이 맞습니다. 너무 오래됐고 고객사에 귀속되는 부분이 너무 많아, 정직하게 재현할 수 없기 때문입니다.
답변은 이 사이트에 적힌 내용을 근거로 합니다. 할 가치가 없는 일이라면 그렇게 답합니다.