그로스 엔지니어

마케팅팀이 가입 화면을 고쳐 보고 싶으면 개발팀에 요청서를 넣던 시절이 있었습니다. 요청서는 대기열 뒤쪽에 붙고, 순서가 오면 개발이 시작되고, 검토를 거쳐 배포됩니다. 한 바퀴 도는 데 3주가 걸렸습니다. 그런데 이런 시도는 대개 열에 여덟이 실패합니다. 한 번에 3주씩 걸리면 한 분기에 네 번밖에 못 돌리고, 네 번 중 세 번이 실패하면 분기 내내 얻는 것이 하나입니다.

속도만 문제가 아니었습니다. 요청서를 받은 개발자 입장에서는 그 화면을 오래 쓸 물건으로 만드는 것이 맞습니다. 테스트를 붙이고 예외를 처리하고 다른 화면과 맞춰 둡니다. 그렇게 두 주를 들여 만든 것이 두 주 뒤에 지워지면 만든 사람도 허탈하고 회사도 손해입니다. 만드는 사람과 시키는 사람이 그 코드의 수명을 서로 다르게 보고 있었던 겁니다.

그로스 엔지니어는 이 불일치를 없애려고 생긴 자리입니다. 지워질 것을 전제로 짜는 개발자를 처음부터 실험하는 팀 안에 두면, 3주 걸리던 한 바퀴가 이틀로 줄고 수명이 짧다는 사실에 아무도 불편해하지 않습니다.

하루의 대부분은 이번 주에 확인하기로 한 시도를 화면에 올리는 데 씁니다. 가입 화면의 입력 칸을 다섯 개에서 두 개로 줄인 안을 만들고, 기존 화면과 나란히 띄운 뒤, 어느 쪽 통과율이 높은지 셀 수 있게 기록을 심습니다. 여기까지가 보통 하루에서 사흘입니다.

일은 대체로 네 덩어리로 돌아갑니다.

1. 두 갈래를 만들어 띄웁니다. 사용자를 무작위로 나눠 한쪽에만 바뀐 화면을 보여 주는 A/B 테스트의 구현 쪽을 맡습니다. 나누는 비율과 대상 조건을 코드에 박지 않고 피처 플래그로 빼 둡니다. 배포 없이 껐다 켤 수 있어야 실패한 안을 그날 안에 내릴 수 있습니다.
2. 셀 수 있게 만듭니다. 어느 버튼을 눌렀는지, 몇 번째 화면에서 나갔는지가 기록으로 남아야 결과를 읽을 수 있습니다. 이벤트 수집을 심는 일이 실제로는 화면을 만드는 일보다 오래 걸릴 때가 많습니다.
3. 결과가 나오면 지웁니다. 진 쪽의 코드와 플래그, 임시로 만든 화면을 걷어 냅니다. 이 청소를 미루면 석 달 뒤 아무도 켜져 있는지 모르는 분기가 수십 개 쌓입니다.
4. 반복되는 작업을 도구로 만듭니다. 같은 방식으로 플래그를 붙이고 기록을 심는 부분은 한 번 만들어 두고 다음 실험부터 설정만 바꿉니다. 한 바퀴를 이틀에서 반나절로 줄이는 것이 이 자리의 성과입니다.

일반 개발과 갈리는 지점은 완성도를 어디까지 올릴지 정하는 기준입니다. 두 주를 들여 예외 처리까지 마친 화면과 이틀 만에 만든 화면이 같은 답을 준다면 후자가 맞습니다. 다만 아무렇게나 짜도 된다는 뜻은 아닙니다. 이긴 안은 정식 코드로 다시 쓰이고, 실험용 코드가 그대로 남아 운영에서 장애를 내면 그 분기의 실험은 전부 멈춥니다.

가장 붙어 있는 사람은 그로스 리드입니다. 무엇을 확인할지와 순서를 정하는 자리라, 아이디어 서른 개 중 이번 분기에 돌릴 다섯 개를 골라 넘겨 줍니다. 그로스 엔지니어는 그 다섯 개를 받아 만들면서 각각이 며칠짜리인지를 되돌려 줍니다. 사흘짜리 안과 3주짜리 안이 섞여 있으면 순서가 바뀌기 때문입니다.

그로스 마케터와는 유입 쪽에서 만납니다. 광고를 누른 사람이 도착하는 랜딩 페이지를 문구별로 여러 벌 띄워야 할 때, 마케터가 문구를 쓰고 엔지니어가 그 여러 벌을 나눠 보여 줄 장치를 만듭니다. 데이터 분석가와는 결과 쪽에서 만납니다. 벌어진 차이가 우연인지 아닌지를 판단하는 일은 분석가 몫이고, 그 판단에 필요한 기록이 제대로 쌓이게 만드는 일이 엔지니어 몫입니다.

제품팀과는 경계가 자주 문제가 됩니다. 같은 가입 화면을 제품팀도 고치고 있으면 두 변경이 부딪힙니다. 그래서 이 역할은 대개 그로스 팀이라는 별도 조직에 속합니다. 기획·디자인·분석을 한 팀에 섞어 두고 기능 출시가 아니라 지표 개선만 맡기는 조직입니다. 직군을 섞는 이유는 시도 하나가 네 직군을 모두 거치는데, 요청서를 옆 팀에 넘겨 순서를 기다리면 다시 3주가 되기 때문입니다.

"이건 그로스 엔지니어 붙여서 이틀 만에 띄워 보죠."

정식 개발 일정에 넣지 말고 실험용으로 빠르게 확인하자는 제안입니다.

"플래그로 빼 주세요. 안 되면 바로 내려야 하니까요."

배포 없이 끌 수 있게 만들어 달라는 요청입니다.

"지난 분기 실험 코드 정리부터 하겠습니다."

쌓인 실험 잔재를 걷어 내는 일을 이번 주 작업으로 잡겠다는 말입니다.

페이지덱에서는 태오가 이 역할을 겸하고 있습니다. 현우가 광고로 들어온 사람의 가입 전환율이 낮다고 가져오면, 태오는 가입 화면을 두 벌 만들어 절반씩 보여 줍니다. 한 벌은 입력 칸이 다섯 개인 기존 화면이고 다른 한 벌은 이메일과 비밀번호만 받는 화면입니다. 기록을 심어 두고 두 주를 기다립니다.

결과가 나오면 대개 셋 중 하나입니다. 바뀐 쪽이 이기면 정식 코드로 옮기고, 지면 그날 플래그를 끄고 코드를 지웁니다. 차이가 애매하면 판단을 지현과 현우에게 넘깁니다. 태오가 하지 않는 일은 어느 쪽이 좋아 보이는지 자기 감으로 고르는 것입니다. 그 판단을 없애려고 두 벌을 만든 것이기 때문입니다.

코드 품질을 신경 쓰지 않는 개발자라고 읽는 경우가 많습니다. 빨리 만들고 지운다는 설명만 들으면 그렇게 들립니다. 하지만 짧게 사는 코드와 허술한 코드는 다릅니다. 실험용 화면도 운영 환경에서 실제 사용자에게 보이고, 거기서 오류가 나면 그 사용자는 그냥 나가 버립니다. 실제로 달라지는 것은 품질 기준이 아니라 무엇에 시간을 쓰느냐입니다. 예외 처리와 기록은 챙기고, 다른 화면과의 디자인 통일이나 재사용 구조는 이긴 뒤로 미룹니다.

실험을 빨리 돌리면 지표가 오른다고 생각하는 것도 자주 보입니다. 횟수가 늘면 이기는 안도 늘어나니 그럴듯합니다. 하지만 무엇을 확인할지 고르는 일이 부실하면 횟수를 늘려도 얻는 것이 없습니다. 이미 잘 통과하는 화면의 버튼 색을 스무 번 바꾸는 것보다 사람이 가장 많이 빠지는 자리를 한 번 건드리는 쪽이 낫습니다. 속도는 좋은 질문 위에서만 값을 합니다.