개발자 비급(祕笈) – 3. 나의 폭망한 프로젝트 답사기

개발자 비급(祕笈) 시리즈는 직장 생활을 하는 모든 분들이 어떻게 하면 개발자의 방식으로 경력 관리, 업무 처리, 프로젝트 관리 등을 할 수 있을지 생각해 보는 시리즈입니다. 개발자들에게는 자기 자신을 돌아볼 수 있고, 비개발 직군에서는 자신의 경력 방향에 시금석이 되었으면 합니다.

주니어 개발자 시절부터 지금까지 수 많은 신규 서비스 개발 및 개편 프로젝트를 진행하거나 참여했습니다. 오늘은 가장 기억에 남는 실패 프로젝트 하나를 소개할까 합니다.

15여년 전 스타트업에서 일하다가 대형 포털 사이트인 Daum으로 이직한 후 얼마 되지 않을 때였습니다. 당시 저는 CTO 직속 R&D센터의 시니어 스탭으로 일하고 있었습니다. 회사 내부적으로 수백만 명이 사용하는 한메일 서비스 개편 프로젝트를 오랫동안 야심차게 준비해 왔습니다. 한메일 개발팀에서 전체 프론트 및 백엔드 개편을 진행하고 있었는데, 아무래도 인력이 좀 모자라다 보니 일부인 한메일 주소록 개편 진행을 우리 본부에 요청했습니다. 회사의 중요 프로젝트다 보니 몇몇 개발자와 함께 제가 개발 PM을 맡아서 도와 주기로 했습니다.

■ 신기술을 활용한 한메일 주소록 개편
사실 한메일 주소록 자체는 그렇게 사용자 트래픽이 많지 않았습니다. 왜냐하면, 대부분 사용자 패턴이 메일 쓰기 화면에서 주소를 검색해서 사용하지 실제 주소록 사이트에는 잘 가지 않으니까요. 메일 주소를 주소록에 저장할 때도 메일 쓰기 화면에서 원클릭으로 가능합니다. 그러니, 주소록 사이트는 간단한 관리 화면만 있고 한메일 원래 사이트에서 오는 API 요청 처리가 대부분이었습니다.

당시(2005년)는 한참 국내에 처음 Ajax 기반 사용자 인터페이스 기법을 막 도입하고 있던 시기였습니다. 개편 기획서가 오기 전에 저는 마치 데스크톱의 아웃룩에서 주소를 추가, 삭제, 검색하는 것 같은 리치 웹(Rich Web) 기반으로 제작하는 게 어떤가 하는 아이디어를 내고, 개발자들과 간단한 프로토 타입을 만들었습니다.

이걸 기획자에게 보여줬더니 기존에는 주소록에 뭔가를 할 때 마다 웹 페이지를 새로 고침 하는 정적 방식이었지만, 새로운 사용자 인터페이스는 훨씬 사용하기 편리해서 매우 좋아했습니다. 한메일과 달리 트래픽도 그렇게 많지 않은 서비스다 보니 새로운 기술을 실험해 보기에도 적합했습니다.

큰 부담 없이 프로젝트를 맡은 후 개발도 순조롭게 진행되고 드디어 오픈 시점이 다가왔습니다. 당시 한메일 주소록 테이블에 들어 있는 주소가 대략 3억개 정도 되고, 사용자도 수백만 명이 넘었습니다. 전체 사용자의 80% 이상이 주소를 50-100개 사이를 가지고 있었습니다. 테스트 시점에서는 각 사용자 주소를 200-300 정도씩 XMLHttpRequest로 가져와서 HTML 문서 객체(Document Object Model, DOM)을 만들고 삭제할 때, 웹 브라우저 성능이나 사용성 테스트를 진행했는데 아주 만족스러웠습니다.

혹시 문제가 생길 것을 대비해서 서비스 롤백(Rollback) 계획까지 다 마치고 나서 한메일 메인 사이트와 함께 개편 사이트를 오픈했습니다. 개편 후, 일단 기존 한메일 주소록 사용자가 로그인 하면, 개편 사이트로 갈 것인지 물어보고, 그 때 해당 사용자의 데이터만 마이그레이션한 후 신규 서비스를 이용하도록 합니다. 워낙 많은 사용자와 데이터를 한꺼번에 이전을 할 수 없기 때문에 대규모 사이트들이 큰 부담 없이 하는 마이그레이션 방식입니다.

문제는 오픈 후 일어났습니다.

■ 오픈 후… 고객센터가 마비되다
평소 한메일 고객센터에 전화 문의 대비 2-3배의 고객 클레임이 온 것입니다. 대부분 제가 맡은 한메일 주소록에 때문이었습니다. 사연을 들어보니, 전화하신 분들은 주로 보험이나 자동차 영업을 하시는 분들인데, 주소록에 수천 개의 고객 이메일을 관리하고 있었습니다.

이분들이 개편된 주소록으로 옮겨진 이후, 웹 브라우저에서 수백개씩 주소 데이터를 가져와서 DOM을 그리는 과정에서 잦은 이벤트가 발생하다 보니 웹 브라우저 성능 이슈가 생겼던 것이었습니다. 당장 전화번호를 검색해야 하는데, 느리고 관리가 안된다고 몇 번이고 전화를 하는 바람에 고객센터가 마비가 될 지경이었죠.

사실 프로젝트 초기 사용자 분석할 때, 한메일 주소록의 주요 트래픽은 평균 수백 개의 메일 주소를 가진 80% 사용자였습니다. 하지만, 비록 소수의 작은 트래픽일지라도 이분들은 매일 방문해서 수천 개의 주소를 관리하는 헤비 유저(Heavy User)였습니다. 지금이야 빅데이터 로그 분석 및 사용자 분석 기법이 일반화 되어 있지만, 당시에는 평균적인 트래픽과 대상자만 확인보다 보니 이 분들의 행동이 잘 잡히지 않았던 것이죠.

덕분에 Daum의 한메일 개편에서 주소록은 ‘폭망’한 프로젝트로 기억되었습니다. 바로 기획자와 상의해서 개발자들과 발빠르게 헤비 사용자 데이터를 롤백하고, 한번에 불러오는 주소 갯수와 DOM 객체를 그리는 방식을 페이징 방식으로 변화를 주는 방식으로 급한 불을 껐습니다. 하지만, 그 이후로 한번 더 주소록 개편 프로젝트를 해야만 했지요. Daum도 실패를 용인하는 기업 문화를 가지고 있어서 다행히 짤리지 않고 그 이후로 8년을 더 다녔습니다.

■ 누가 헤비 유저인지 잊지말자
기술적 문제를 어느 정도 수습한 후, 프로젝트 실패 후기(Post-mortem)을 전사에 공유하면서 대규모 사용자 기반 서비스를 하더라도 눈에 쉽게 띄지 않는 소수의 헤비유저의 사용 행태를 분석하는 게 얼마나 중요한가 깨닫게 되었습니다. 무료 웹 서비스를 하는 경우, 대량의 사용자에게 공짜로 서비스를 하기 때문에 평균 사용자를 기반으로 기획 및 개발하는 경우가 많습니다. 핵심 사용자가 누구인지 제대로 알고 서비스나 비즈니스를 해야 한다는 간단한 명제를 간혹 잊어 버립니다.

사실 개발자들은 신규 혹은 개편 프로젝트에 들어가면, 어떤 신기술을 써 볼 것인가 하는데 집중하는 경향이 있습니다. 물론 한메일 프로젝트에서 발견된 문제와 축적한 경험을 통해 그 이후 Daum 서비스내 Ajax 기술 확산에 큰 역할을 했습니다. 특히, 수천개의 데이터를 가진 헤비 유저의 데이터를 DOM으로 조작할 때, 웹 브라우저 성능 저하이나 낮은 사용자 경험 등을 회피할 수 있는 방법 등 다양한 노하우를 얻기도 했지요. 다만, 신기술 구현에만 집중한 나머지 정작 중요한 것을 놓치는 우(愚)를 범할 수 있습니다.

제가 왜 이야기를 꺼냈는가 하면 우리가 비즈니스와 밀접히 관련된 IT 개발 프로젝트를 진행할 때도 개편으로 영향 받을 소수의 헤비 유저에 대해 간과하는 경우가 있기 때문입니다.

흔히 80대 20 규칙이라고 부르는 파레토 법칙(Pareto principle)은 ‘전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상’을 말합니다. 예를 들어, 일반적으로 전체 매출의 80%는 상위 20% 고객이 만든다는 것입니다. 즉, 모든 고객에게 골고루 이익이 되는 것 만큼 상위 20% 고객의 이익은 살피는 것은 매우 중요합니다.

온라인 플랫폼 서비스에서 신규 사용자 규모를 키우고, 이들에게 지속적으로 사용을 유도하는 혜택을 주는 것이 필수적인 요건입니다. 하지만, 현재 서비스를 많이 써 주고 피드백을 해주는 헤비 유저를 놓쳐서는 안됩니다. 한메일 주소록 개편에서 다수 사용자의 행동 데이터만 보고 개편을 하다가 소수의 헤비 사용자는 간과한 것처럼요.

이것을 제대로 파악할 수 있는 사람이 서비스를 직접 만들고 운영하는 개발자입니다. 핵심 사용자의 데이터를 꼼꼼하게 보고, 사용자들의 행동에 따라 어떤 기술적인 문제를 만들어 내는지 제대로 파악해야 합니다.

대부분 개발 프로젝트의 성패는 여기에 달려 있습니다. 내 서비스의 사용자가 누구인지 무엇을 원하는지 제대로 아는 것…

참고. 당시 한메일 주소록 개편 데모 영상

연재 목차

• 개발자 비급(祕笈) – 1. 연봉은 실력의 결과가 아니다
• 개발자 비급(祕笈) – 2. 업무 생산성을 최대로 올리는 법
• 개발자 비급(祕笈) – 3. 나의 폭망한 프로젝트 답사기
• 개발자 비급(祕笈) – 4. 팀장이 아니어도 괜찮아
• 개발자 비급(祕笈) – 5. 스타트업의 개발자 채용 비법

- Channy Yun (윤석찬);

※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)