김명현 | #Developer
대표님이 미쳤어요
어느 날 대표님이 Claude Code를 한참 쓰더니 뭔가를 만들어 왔습니다. 비주얼 노벨이랍니다. zeta처럼 AI가 스토리를 진행하는데, 인물과 배경도 그려줍니다. 로컬에서만 동작하긴 했지만, 개발자와 디자이너의 도움 없이 혼자 만들었다는 게 믿기지 않을 만큼 플레이 경험과 퀄리티가 좋았습니다. 그리고 대표님은 이렇게 말했습니다. "이제 개발자가 필요 없어요. 전부 내가 만들 수 있어요."
반은 맞는 말이었습니다. 에이전트 코딩 도구가 급격히 발전하면서, 아이디어만 있다면 누구나 동작하는 결과물을 만들어낼 수 있는 시대가 온 것입니다. 만들 수 있는 것의 폭이 달라졌다면, 유저에게 줄 수 있는 경험의 폭도 달라질 수 있습니다. 우리는 zeta의 채팅 기반 경험에 머무르지 않고, AI 엔터테인먼트가 줄 수 있는 더 다양한 경험을 시도해보고 싶었습니다. 사내에서 프로토타입을 몇 번 플레이해 본 뒤 곧바로 제품화 팀이 꾸려졌습니다. 그 첫 번째 시도가 대표님의 프로토타입에서 출발한 비주얼 노벨이고, 이런 새로운 경험들을 빠르게 실험하기 위해 기존 zeta에서 분리해 만든 웹 플랫폼이 zeta labs입니다.
그리고 우리는 대표님의 말을 우리 팀에도 적용해보기로 했습니다. 개발자만 만들 수 있는 팀이라면, 이터레이션은 개발자 수만큼만 돕니다. 하지만 기획자든 디자이너든 아이디어를 가진 사람이 직접 만들어보고 확인까지 할 수 있다면, 이터레이션은 팀원 수만큼 병렬로 돕니다. 그래서 zeta labs는 제품만큼이나 일하는 환경에 공을 들였습니다. 팀원 모두가 기획에서 배포, 검증까지 스스로 한 바퀴 돌 수 있는 환경.
이 글에서는 그 환경을, 제품이 만들어지는 사이클 순서 그대로 소개합니다. 기획이 문서가 되고, 문서가 코드가 되고, 코드가 배포되어 지표로 돌아오는 과정에 AI가 어떻게 녹아 있는지 하나씩 따라가 보겠습니다.
기획: 문서가 곧 개발의 시작
사이클의 출발점은 기획입니다. 그리고 팀원 모두가 만드는 팀이 되려고 하는 순간, 가장 먼저 마주치는 병목은 코딩이 아니라 파악이었습니다. 무언가를 만들거나 고치려면 지금 무엇이 어떻게 구현되어 있는지부터 알아야 하는데, 코드가 유일한 진실인 팀에서는 코드를 읽을 수 있는 사람만 그 출발선에 설 수 있습니다. 에이전트도 사정이 다르지 않습니다. 요청할 때마다 코드 전체를 뒤지게 하면 느리고, 무엇보다 "이 기능이 왜 이렇게 동작해야 하는지" 같은 기획 의도는 코드 어디에도 적혀 있지 않습니다.
그래서 우리는 코드가 아니라 문서를 진실의 원천으로 삼았습니다. 사람이든 에이전트든, 문서만 읽으면 현재 기획과 구현 상태가 파악되도록 만드는 것입니다. 다만 모든 것을 한 문서에 넣을 수는 없었습니다. 프로젝트 내내 유지되는 규칙과 매주 바뀌는 기획은 변경 주기가 다릅니다. 이 둘이 한 문서에 섞이면 자주 바뀌는 내용을 고칠 때마다 바뀌면 안 되는 규칙까지 함께 편집 범위에 들어오고, 수정이 거듭될수록 문서가 길어져 에이전트도 헷갈립니다. 코드에서 자주 바뀌는 모듈과 안정된 모듈을 분리하듯, 문서도 변경 빈도에 따라 세 층으로 나눴습니다.
AGENTS.md에는 가장 바뀌지 않는 것들을 담았습니다. 린트·포매팅 같은 회사 컨벤션, 이슈 관리 방식, 기획 문서 구조와 코드의 동기화 방식처럼 프로젝트 내내 유지되는 규칙들입니다. 에이전트는 어떤 작업이든 이 파일을 항상 먼저 읽기 때문에, "작업을 시작하기 전에 architecture에서 관련 문서를 확인하라"는 지시도 여기에 적어두었습니다. 무슨 작업을 시키든 에이전트가 관련된 아키텍처 문서부터 찾아 읽게 만드는 장치입니다.
architecture에는 개별 기능이 아니라 시스템이 어떻게 구성되어 있는지를 영역별로 담았습니다. 프론트엔드와 백엔드의 전체 구조, 로그가 쌓이는 파이프라인, 모니터링 구성, AI와 협업하는 전략까지, 영역마다 문서 하나씩입니다. 효과는 바로 체감됐습니다. 예를 들어 로그 관련 작업을 시키면 에이전트가 로깅 문서를 먼저 읽고 기존 파이프라인 컨벤션에 맞춰 코드를 짭니다. 문서가 없을 때는 매번 같은 설명을 프롬프트에 반복해서 붙여넣어야 했던 일입니다.
마지막이 기능 기획 문서, 기획자가 개발을 시작하는 곳입니다. 변경이 가장 잦은 층이라, 여기서도 "왜 만드는가"와 "어떻게 만드는가"를 다시 나눴습니다. design 문서는 해당 기능이 왜 필요한지, 설계, 유의사항이 담긴 기획 문서입니다. spec 문서는 design을 구현 레벨로 번역한 문서로, 에이전트는 이 문서를 보고 개발을 시작합니다. 이렇게 나눠두면 기획이 바뀌었을 때의 흐름이 만들어집니다. 기획자가 design 문서를 고치고, 그 변경을 spec에 반영하는 일은 에이전트에게 시키면, 간단한 변경은 기획자의 손에서 출발해 큰 리소스 없이 코드까지 흘러갑니다. 다만 "design → spec → 구현"이라는 단방향 파이프라인을 강제하는 수단이 없다 보니, 각 문서에 최종 수정 날짜를 기록해두고 design이 spec보다 최신이면 개발자에게 확인시키는 방어 프롬프트도 추가해두었습니다.
이렇게 해서 사이클의 첫 단계가 열렸습니다. 어떤 직군이든 문서를 읽으면 현재 상태를 파악할 수 있고, 기획 변경은 design 문서에서 출발해 에이전트를 타고 코드를 향해 흘러갑니다.
결정: 어떤 게 좋은지는 굴려봐야 안다
언제나 기획 과정에는 큰 난점이 하나 있는데, 만들어 보기 전에는 정할 수 없는 것들이 존재한다는 점입니다. zeta labs에는, 이야기가 결정적인 갈림길에 섰을 때, TRPG처럼 20면체 주사위를 굴려 성공과 실패를 판정하는 기능이 있습니다. 판정에 성공하면 이야기가 뜻대로 풀리고, 실패하면 예상치 못한 방향으로 흘러갑니다. 이야기의 운명이 하나의 굴림에 걸리는 순간이니, 주사위가 구르는 모션도 그만큼 긴장감 있고 "쫀득하고 맛깔나야" 합니다. 그런데 그러려면 물리 파라미터가 어때야 하는지 한 번에 답을 내줄 사람이 없었습니다. 예전이라면 이런 결정은 3D 모션 전문가의 실력에 맡기거나, 개발자가 파라미터를 하나 바꿔 빌드할 때마다 옆에서 지켜보며 "조금만 더…"를 반복해야 했습니다.
AI 에이전트가 여기서 빛을 발했습니다. 개발자가 여러 가설을 생각해 후보를 하나씩 만들어 보여주는 대신, LLM이 가진 지식을 통해 후보 파라미터를 제안하고, 가능한 변형들을 쭉 나열해 직접 굴려볼 수 있는 데모 페이지를 만들게 했습니다. 결정에 필요한 것이 전문 지식이 아니라 "무엇이 더 좋은지 고르는 감각"이 되도록 만든 것입니다. 고르는 일은 직군과 무관하게 누구나 할 수 있으니, 이제 기획자와 디자이너가 데모를 돌려보고 고르면 결정이 끝납니다. "스르륵" 말고 "다라락" 하는 느낌처럼 미묘하게 방향을 지시해도, 사람이었다면 화를 냈을 법하지만, 에이전트는 어떻게든 알아듣고 다른 기법과 파라미터를 적용해 또 제시해줍니다.
이렇게 "굴려볼 수 있는 상태"를 만드는 비용이 급감하니, 결정의 방식 자체가 바뀌었습니다. 회의실에서 상상으로 논쟁하는 대신, 후보를 전부 만들어 눈앞에 늘어놓고 고릅니다. 여러분도 결정이 막힐 때는 실험 데모부터 띄워 보시길 추천합니다.
구현: 에이전트 교통정리
기획과 문서가 정리되면, 이제 만들 차례입니다. 코드를 짜는 것 자체는 에이전트가 합니다. 간단한 수정이나 버그픽스라면 개발자가 아니어도 에이전트에게 시켜 처리할 수 있습니다. 그럼 개발자는 무엇을 할까요? 코딩이 사라진 자리에서, 개발자의 일은 완전히 다른 모양이 되었습니다.
할 일은 무척 쌓여 있고, 시간은 촉박합니다. 개발자 한 명당 이슈 오십 개는 처리해야 하고, 하다 보면 점점 늘어납니다. 이걸 하나씩 순서대로 짜다 보면 태양이 수명을 다하고 적색거성이 될 때까지 끝나지 않을 것 같았습니다. 에이전트는 코드를 몇 분 만에 짜내니, 답은 당연히 병렬처리입니다. 그런데 이슈를 위에서부터 5개씩 묶어 워크트리 만들어 돌리자 하면 될 리가 없습니다. 어떤 것은 그냥 코드 한 줄 고치면 되는 버그, 어떤 것은 장기적인 안정성을 위해 신중하게 구조를 잡아야 할 것, 어떤 것은 기획이 아직 확정되지 않아 결정부터 해야 할 것, 어떤 것은 다른 이슈가 먼저 처리되어야만 의미가 있는 것. 이슈마다 "지금 에이전트에게 시킬 수 있는 상태인가"가 다르기 때문입니다.
그래서 개발자의 일은 이슈 분류에서 시작합니다. 이슈를 "바로 시킬 수 있는 것 / 구조 결정이 필요한 것 / 기획 확정 대기 / 선행 이슈에 막힌 것"으로 나누고, 블로커가 없는 것들만 골라 워크트리와 세션을 배정해 병렬로 돌립니다. 많을 때는 6~7개 세션이 동시에 돌아갑니다. 에이전트들이 코드를 짜는 동안 개발자는 막혀 있는 이슈의 블로커를 풉니다. 기획 논의에 참여해 미확정 사항을 확정시키고, 구조 결정이 필요한 것은 직접 설계를 잡습니다. 그리고 끝난 작업들을 리뷰해 머지될 수 있는 상태로 만들어놓습니다. 코드를 짜는 시간 대신, 무엇을 시킬 수 있는 상태로 만들고, 시키고, 거둬들이는 데 시간을 쓰는 것.
개발자의 전문성이 사라진 것이 아닙니다. 코드 타이핑에 쓰이던 전문성이 구조를 결정하고, 의존성을 풀고, 결과물을 검수하는 곳으로 이동한 것입니다. 그리고 이 이동 덕분에, 팀 전체의 구현 처리량은 개발자가 직접 짜던 시절과는 비교할 수 없이 늘었습니다.
검증: 누구나 머지해도 안전한 파이프라인
여기까지 읽고 이런 의문이 들었을 겁니다. 에이전트가 짠 코드를, 때로는 비개발자가 시킨 코드를, 그렇게 막 머지해도 되는 걸까? 됩니다. 단, 조건이 있습니다. 사람의 꼼꼼함 대신 시스템이 코드를 걸러줘야 하고, 그 시스템이 충분히 빨라야 합니다.
빠른 검증이야 원래도 좋은 것이지만, AI 개발 사이클에서는 그 무게가 달라집니다. 에이전트가 코드를 10분만에 짰는데, 이걸 테스트하는 시간이 20분이라면? 이를 5분으로 줄일 수 있다면 한 시간에 개발할 수 있는 양이 2배로 늘어나는 셈입니다. 전체 개발의 속도를 검증 시스템의 속도가 좌우하게 된 것입니다.
그래서 속도에는 꾸준히 투자했습니다. 기술 스택부터 빌드가 빠른 것들로 고르고, 늘어나는 테스트 시간은 에이전트에게 맡겨 깎았습니다. 언제는 저녁 먹으면서 테스트 시간을 어떻게든 줄여놓으라고 했더니, 알아서 실험 PR을 올려가며 캐시와 샤딩 설정을 조정해 최종 시간을 10분 이상 줄여놓기도 했습니다. CI 러너는 사내에서 iOS 앱 빌드용으로 쓰던 맥북을 빌려다 탑을 쌓는 것으로 시작해, 동시에 CI가 도는 PR이 10개를 넘어서자 GitHub Larger Runners를 셋업하기도 했습니다.
테스트는 믿을 수 있게
속도만큼 중요한 것이 신뢰입니다. 사람 리뷰를 줄이려면 그 빈자리를 테스트가 채워야 합니다. 그런데 테스트가 신뢰를 얻으려면 먼저 항상 통과 상태여야 합니다. 깨진 유리창 이론처럼, 테스트가 깨진 채로 머지되는 일이 한 번 생기면 그다음부터는 아무도 자기 테스트를 통과시키는 데 노력을 기울이지 않게 됩니다. 기능이 다 개발되지도 않았고, 기획도 수시로 바뀌고, 의존성도 마구 추가되는 혼란 속에서 테스트를 안정화하는 게 쉽지 않아, 사실 저희도 한동안 깨먹었습니다. 여기서 AI의 아주 좋은 특성, "지치지 않고 끝까지"의 덕을 봤습니다. 자기 전에 Cursor Cloud Agent에 깨진 테스트를 모두 고쳐놓으라고 시켰습니다. 방향이 불분명한 것은 모아서 알려달라고 한 뒤, 몇 번 반복하니 금방 안정화됐습니다.
안정화 이후에는 유리창이 다시 깨지지 않도록 장치를 걸었습니다. 테스트 통과를 머지 조건으로 강제해 깨진 채 머지되는 일 자체를 막았고, 버그가 발견될 때마다 해당 케이스의 회귀 테스트를 추가해 같은 유리창이 두 번 깨지지 않게 했습니다. 테스트를 고치는 일도 에이전트에게 시키면 되니, "바쁘니까 일단 스킵"이라는 예외를 둘 이유가 없어졌습니다.
직접 만져보는 검증: PR마다 살아 움직이는 프리뷰
자동화된 테스트가 아무리 촘촘해도, 직접 만져봐야만 알 수 있는 것들이 있습니다. 화면의 느낌, 인터랙션의 리듬, 사용자 흐름의 어색함 같은 것들입니다. 문제는 "만져보는" 비용입니다. PR마다 브랜치를 받아 로컬에서 서버와 클라이언트를 띄워야 한다면, 개발자가 아닌 사람에게는 사실상 불가능한 일입니다.
그래서 PR을 열면 만져볼 수 있는 환경이 자동으로 따라오게 만들었습니다. PR 하나가 생성되면 웹, 어드민, 그리고 브랜치별 전용 서버까지 독립된 프리뷰가 뜨고, 웹 프리뷰는 자동으로 그 브랜치의 서버를 바라봅니다. 프리뷰 URL은 봇이 PR 댓글로 달아주고, 커밋을 푸시할 때마다 갱신됩니다. 링크를 클릭하기만 하면 되니, 기획자도 디자이너도 코드를 한 줄도 읽지 않고 "내가 시킨 변경"이 실제로 어떻게 동작하는지 확인할 수 있습니다.
코드 리뷰가 병목이 되지 않도록
빌드와 테스트가 빨라져도 마지막 관문이 남습니다. 코드가 나오는 속도는 몇 배가 됐는데, 사람이 리뷰하는 속도는 그대로입니다. 옛날처럼 사람의 코드 리뷰를 마냥 기다려서는 안 되었습니다.
그래서 대부분의 문제는 시스템이 잡도록 했습니다. 동작의 정합성은 테스트가 우선 봅니다. 테스트 통과 없이는 머지가 안 되고, 버그는 회귀 테스트로 다시 잡힙니다. 코드 품질은 AI가 잡습니다. GitHub에 연결해놓은 Copilot과 CodeRabbit이 모든 PR을 리뷰하고, 코드를 Codex로 짰다면 Claude에게 검증을 시키는 식으로 서로 다른 모델을 교차시켜 한 모델의 실수를 다른 모델이 잡게 했습니다. UI와 사용자 흐름의 변경은 앞서 소개한 프리뷰에서 직접 만져보며 확인합니다. 이 관문들을 통과한 PR은 각자 판단으로 머지합니다.
사람의 리뷰는 없어진 게 아니라 좁고 깊어졌습니다. 시스템이 대부분을 걸러주고, 사람은 인증·결제처럼 민감한 코드나 구조에 영향을 주는 변경처럼 기계가 판단하기 어렵고 잘못되었을 때 피해가 큰 부분에만 리뷰 시간을 씁니다. 모든 PR을 의무적이고 형식적으로 보는 대신, 중요한 PR을 제대로 보는 쪽으로 사람의 리뷰를 재배치한 것입니다.
이렇게 해서 "누구나 머지해도 안전한" 파이프라인이 완성됐습니다. 코드가 사람이든 에이전트든 어디서 출발했든, 같은 관문을 통과해야 배포에 도달합니다.
측정: 지표는 누구나 본다
배포가 나갔으면 이제 확인할 차례입니다. 결국 유저가 잘 써야 좋은 제품입니다. 우리는 클로즈베타를 열면서 "무엇을 보고 정식 출시를 판단할 것인가"를 네 가지 기준으로 먼저 정해두었습니다. 기준 없이 배포만 반복하면, 어떤 액션을 해야 할지도 언제 출시할 수 있을지도 흐릿해지기 때문입니다. 네 가지 기준은 다음과 같습니다.
- 재미: 사용 시간, 리텐션, 유료 재화 사용량으로 유저가 실제로 재미있어하는지 추적합니다.
- 퍼널: 진입 경로를 못 찾거나, 들어왔다가 나가거나, 버그로 이탈하는 등 유저 흐름의 각 구간에서 얼마나 빠져나가는지 측정합니다.
- 비용: 감당 불가능한 비용을 지출하면서 서비스를 지속할 수는 없으니, 비용이 예상대로 나가는지 모니터링합니다.
- 정상 작동: 많은 기능이 LLM에 의존하기 때문에, 대사가 너무 길게 나온다든지, 검수 모델이 너무 엄격하거나 관대하게 동작한다든지, 동적으로 생성되는 애셋이 제때 나오는지 등의 퀄리티를 추적합니다.
문제는 이걸 누가 보느냐입니다. 배포는 사이클을 돌 때마다 나가는데, 분석을 데이터 분석가나 엔지니어에게 요청해서 받는 구조라면 확인이 배포 속도를 따라가지 못합니다. 기획자가 자기가 낸 기능의 반응이 궁금해도 요청 대기열에 줄을 서야 하고, 그러는 동안 다음 배포가 나갑니다. 만드는 건 모두가 하는데 확인은 소수만 할 수 있다면, 사이클의 마지막 조각이 끼워지지 않은 셈입니다.
병목의 원인은 분석에 필요한 지식이 분석가의 머릿속에만 있다는 점이었습니다. 어떤 테이블에 어떤 로그가 쌓이는지, 지표를 어떻게 해석해야 하는지, 어떤 함정을 피해야 하는지. 이 문제를 해결해야 했습니다. 저희는 분석을 위한 리포지토리를 새로 만들고, 모든 컨텍스트를 파일에 꺼내기 시작했습니다. 로그 스키마 설명, 과거 쿼리, 참고사항, 그리고 분석 결과물까지, 분석에 필요한 모든 컨텍스트를 이 레포에 커밋해 쌓았습니다. 이렇게 쌓인 지식은 AI가 읽을 수 있게 되었고, 분석을 한 번 할 때마다 그 과정에서 얻은 지식이 레포에 남으니, AI의 다음 분석이 더욱 정확하고 일관성있게 되었습니다. 개발자든 기획자든 디자이너든 대표님이든, 분석하고 싶은 대상만 지정해주면 AI가 알아서 봐야 할 지표를 정하고, 쿼리해 분석하고, 결과를 리포트로 만들어 줍니다. Agent Skill도 많이 만들었는데, 예를 들어 자주 보는 리포트를 HTML로 만들어 내부 서버에 주기적으로 갱신되도록 자동화하는 일을 누구나 AI를 시켜 할 수 있게 되었습니다.
효과는 숫자 밖에서도 나타났습니다. 기획자가 자신이 기획한 기능이 의도대로 동작하는지 직접 확인하기 시작했고, 유저 행동 로그를 따라가다가 개발자가 파악하지 못한 버그를 먼저 발견해 제보하는 일도 생겼습니다. 만드는 사람과 확인하는 사람이 같아지자, 배포에서 다음 액션까지의 거리가 눈에 띄게 짧아졌습니다.
리듬: 일주일에 두 번, 마감이 온다
지표를 보면 개선할 것이 보입니다. 초기 지표는 목표 수치에 한참 못 미쳤고, 고칠 것은 많았습니다. 문제는 개선의 효과를 어떻게 측정하느냐입니다. 준비되는 대로 수시로 배포하면, 유저마다 처음 접한 제품이 제각각이 됩니다. 리텐션이나 전환율 같은 핵심 지표는 유저가 첫 경험을 어떤 버전에서 했는지에 크게 좌우되는데, 그 "첫 버전"이 유저마다 다르면 지표가 움직여도 어떤 변화 덕분인지 가려낼 방법이 없습니다. 기능마다 A/B 테스트를 붙이는 것이 정석이지만, 클로즈베타 규모의 유저 수로 매 배포마다 실험을 설계하기엔 시간도 표본도 부족했습니다.
그래서 배포를 일주일에 두 번으로 묶고, 매 주기마다 클로즈베타 인원을 새로 늘렸습니다. 이렇게 하면 주기마다 "같은 버전을 처음 접한 동질의 유저 배치"가 생깁니다. 각 배치는 그 시점 제품의 표본이 되고, 배치끼리 같은 조건으로 지표를 비교하면 그 주기에 나간 개선 묶음의 효과를 읽을 수 있습니다. 언제든 내보낼 자유를 조금 포기하는 대신, 모든 배포를 측정 가능한 실험으로 만든 셈입니다.
그런데 이 장치의 효과는 측정에서 끝나지 않고, 팀 전체를 가속시켰습니다. 일주일에 두 번, 마감은 어김없이 옵니다. 이번 배치에 실으려면 지금 끝내야 하고, 놓치면 다음 검증은 사나흘 뒤로 밀립니다. 마감이 강하게 박혀 있으니 모든 작업이 "다음 배치에 실을 수 있는 크기"로 저절로 쪼개졌고, 사이클 전체가 그 리듬에 맞춰 돌기 시작했습니다. 그리고 목표 지표가 배치를 거듭할 때마다 실제로 오르는 게 눈에 보이니, 팀 전체에 눈에 띄게 활기가 돌았습니다. 내가 이번 주기에 넣은 개선이 다음 주기 숫자로 돌아오는 경험은, 어떤 일정 관리 도구보다 강력한 동기였습니다.
AI로 지표를 뽑고 → 분석하고 → 개선을 배포하고 → 다음 배치로 효과를 검증하는 루프. 앞에서 소개한 모든 환경이 이 루프의 부품입니다. 문서가 기획 변경을 코드로 흘려보내고, 검증 파이프라인이 배포를 받쳐주고, 분석 레포가 효과를 측정합니다.
결과: 두 달 만의 출시, 그리고 멈추지 않는 배포
이 루프 위에서 팀은 실제로 어떻게 달렸을까요. 첫 커밋부터 클로즈베타 첫 출시까지 두 달이 걸렸고, 이후에도 일주일에 두 번씩 배포가 나가며 클로즈베타 유저는 누적 40만 명까지 늘었습니다.
그런데 숫자보다 더 보여드리고 싶은 것은 루프가 도는 속도입니다. 하루는 분석 레포에서 추천 알고리즘의 버그를 발견했는데, 바로 그날 제품 레포에 수정 PR들이 줄지어 올라왔고, 다음 날 새 배치가 열리자마자 수정 효과가 재측정됐습니다. 발견에서 검증 완료까지 이틀. 측정도 배포 속도를 따라갔습니다. 클로즈베타 한 달 남짓 동안 분석 레포에는 78건의 분석 결과가 쌓였습니다. 하루 2~3건꼴로, 배포되는 모든 것이 측정되고 있었다는 뜻입니다. 그리고 그 측정은 실제 개선으로 이어졌습니다.
zeta labs는 플레이 시 세 가지 다른 가격의 모델을 제공하고 있습니다. zeta는 광고를 보는 대신 무료이고, koji와 luca는 매 턴 유료 재화가 소모됩니다. 처음 오픈 시에는 zeta 모델을 제공하지 않다가 다음 배치부터 zeta 모델을 제공하였습니다. 우선 무료 모델을 제공해서 한 번이라도 써보게 하면 이후 유료 모델 사용량도 늘어날 거라는 가설이 있었습니다. 그러나 배포 이후, 활성 유저는 약 3배로 늘었지만 유료 모델을 써보는 비율이 오히려 이전보다 줄어들었습니다. 예상과 다른 결과였습니다. 그래서 다음 배치에서는 무료 사용 턴수를 제한하고, 유료 모델 사용을 권장하는 장치를 추가하였습니다. 그 결과 유료 모델 사용율을 끌어올릴 수 있었습니다. 매 배치마다 가설을 실험하고, 그 결과가 다음 배치의 아젠다가 되는 루프를 실제로 성공시킨 것입니다.
이 루프가 낸 성과 중 하나만 더 소개합니다. 앞서 소개한 주사위 판정은 첫 굴림은 무료지만, 실패하면 유료 재화인 피스로 다시 굴릴 수 있습니다. 출시 초기엔 회당 고정가였는데, 로그를 분석해 보니 다시 굴리기 수요가 "한 판정에 수십 번씩 굴리는" 두꺼운 꼬리에 몰려 있었습니다. AI에게 가격안별 매출 시뮬레이션을 맡겼더니 고정가 인상보다 누진제(굴릴수록 비싸짐)가 구조적으로 유리하다는 결과가 나왔고, 그대로 배포했습니다. 실측 결과 결제자당 매출이 약 3.5배로 뛰었고, "비싸지면 덜 굴리지 않을까"라는 우려와 달리 1인당 다시 굴리기 횟수는 오히려 유지·소폭 증가했습니다. 그리고 이 모든 과정, 로그 분석부터 가격 시뮬레이션, 배포, 효과 재측정까지를 한 사람이 처음부터 끝까지 혼자 진행했습니다. 팀원 모두가 사이클을 혼자 돌 수 있는 환경이 만들어낸 결과입니다.
마치며
"이제 개발자가 필요 없어요." 글을 시작한 대표님의 말은, 돌아보면 반만 맞았습니다. 개발자가 필요 없어진 것이 아니라, 팀원 모두가 개발자가 된 것입니다. 기획자가 문서로 개발을 시작하고, 디자이너가 데모에서 결정을 내리고, 대표님이 직접 지표를 분석합니다. 그리고 개발자는 그 모든 것이 안전하게 굴러가는 환경을 만들고 지휘합니다.
zeta labs는 아직 초기 단계로, 유저 경험을 더 다듬어 정식 출시를 앞두고 있습니다. AI를 제품 개발 전 과정에 어떻게 녹여낼지는 많은 시행착오가 필요했고, 지금도 정답을 찾았다고 생각하지 않습니다. 다만 한 가지는 분명해졌습니다. 아이디어를 가진 사람이 직접 만들어 확인할 수 있는 팀은, 그렇지 않은 팀과 완전히 다른 속도로 배웁니다.
이런 zeta 팀의 여정에 함께 할 멋진 동료를 구하고 있습니다. 관심 있으시다면 아래 링크로 연락해 주세요!
👉🏻 1:1 티타임 요청
Share article