Warp의 10분 규칙과 40~50% 완수율

요약

모든 코딩 작업을 인공지능 프롬프트로 시작하도록 지침을 세웠습니다.
시니어 개발자의 저항을 10분 비상구 규칙과 최고경영자의 솔선으로 풀었습니다.
도구 강제보다 명확한 탈출구와 일관된 코드 품질 기준이 변화를 이끕니다.

인공지능 개발 도구를 만드는 회사가 맞닥뜨린 저항

인공지능 개발 도구를 직접 만드는 소프트웨어 회사라면 구성원 모두가 누구보다 앞장서서 그 도구를 쓸 것이라고 짐작하기 쉽습니다. 현실은 전혀 달랐습니다. 벤처 투자사 First Round가 2025년 10월 8일 공개한 인터뷰에서, 개발자 환경을 만드는 스타트업 Warp의 창업자이자 최고경영자인 Zach Lloyd는 뜻밖의 고민을 털어놓았습니다.

Lloyd는 수백 개의 댓글이 달린 소셜 미디어 글에서 이렇게 밝혔습니다. “우리는 말 그대로 Warp에서 인공지능 개발자 도구를 만들고 있지만, 이 도구를 더 많이 쓰게 해 사람들의 일하는 습관을 바꾸는 일은 여전히 어렵습니다.”

Warp는 원래 명령어를 입력하는 화면인 터미널을 현대적으로 다시 정의하는 작업에서 출발했습니다. 그러다 인공지능 에이전트가 스스로 코드를 작성하고 실행하는 에이전트형 개발 환경(ADE)을 구축하는 회사로 방향을 틀었습니다. 사내에 새로운 도구를 도입하자 가장 먼저 열렬하게 반응한 사람들은 소프트웨어 엔지니어가 아니었습니다. 디자이너, 프로덕트 매니저(PM), 그리고 Lloyd 본인 같은 비개발 직군이었습니다.

정작 가장 강하게 저항한 집단은 기술력이 뛰어난 사내 시니어 개발자들이었습니다. 그들이 새 작업 방식을 밀어낸 데에는 세 가지 분명한 이유가 있었습니다.

첫째, 비개발 직군에게 인공지능은 이전에는 혼자 힘으로 할 수 없었던 소프트웨어 제작을 가능하게 만들어 줍니다. 반면 시니어 개발자에게 인공지능은 기껏해야 이미 잘 아는 작업을 조금 더 빠르게 해 주는 속도 향상 도구에 불과합니다. 작업 방식을 송두리째 바꿀 만큼의 절박한 동기가 생기지 않는 것입니다.

둘째, 프롬프트, 즉 컴퓨터에 내리는 자연어 작업 지시문으로 코딩을 처음 시도하면 실패로 끝나거나 손으로 직접 짤 때보다 시간이 더 오래 걸리는 일이 잦았습니다. 한두 번 시험 삼아 써 본 경험이 오히려 불신을 키웠습니다.

셋째, 인공지능이 생성한 코드가 겉보기에 잘 돌아가더라도, 팀 내부의 코딩 표준이나 시스템 설계 방식을 따르지 않아 바뀐 부분(diff)을 기존 코드에 합칠 수 없는 경우가 많았습니다. 코드를 합쳐 달라는 요청인 PR(Pull Request)을 올려도 쓸모없는 코드로 판정받기 일쑤였습니다.

Lloyd는 자사 제품을 사내 구성원이 직접 쓰면서 검증하는 관행인 도그푸딩을 조직의 공식 규율로 세우기로 했습니다.

다섯 단계로 설계한 사내 코딩 지침

Lloyd는 모든 엔지니어가 따라야 하는 5단계 코딩 지침을 세웠습니다. 지침 전문은 사내 협업 도구인 Notion에 공개했고, 매주 팀 회의에서 내용을 점검했습니다.

1단계는 모든 코딩 작업을 Warp에서 프롬프트로 시작하는 것입니다. 여기에는 세 가지 이유가 있었습니다. 첫째는 여러 에이전트를 동시에 띄워 두고 회의에 들어가더라도 백그라운드에서 작업이 알아서 진행되는 멀티스레드 개발이 가능해지기 때문입니다. 둘째는 평소 다루지 않던 낯선 코드 영역을 수정할 때 작업 속도를 크게 끌어올릴 수 있기 때문입니다. 셋째는 자기가 만든 제품을 스스로 매일 써 보아야 할 제품 개발팀의 기본 의무이기 때문입니다.

2단계는 프롬프트로 코딩 작업을 끝내는 데 성공했다면, 사내 메신저 Slack의 #warped-it 채널에 작업 결과와 PR을 공유하는 것입니다. Lloyd도 자기 PR을 이 채널에 직접 올립니다. 성공 사례를 팀 전체에 눈으로 보여 주면 동료들이 프롬프트를 작성하는 요령을 서로 배울 수 있고, 팀 전체의 작성 기술도 함께 늘어납니다.

3단계는 10분이 지나도 프롬프트 작성 때문에 시간을 낭비하고 있다는 생각이 들면 즉시 작업을 멈추고 사내 피드백 채널에 기록을 남기는 것입니다. 이 10분 규칙은 개인의 전문적 판단을 존중하는 안전판 역할을 합니다. 이런 비상구가 없으면 지침은 구성원의 생각을 구속하는 족쇄가 되고 맙니다. 엔지니어들이 남긴 생생한 실패 피드백은 Warp 제품의 기능을 개선하거나 품질을 자동으로 검사하는 평가 세트(eval)를 만드는 원천 자료로 쓰였습니다.

4단계는 Warp에서 막혔다면 Cursor나 Claude Code 같은 경쟁사의 인공지능 코딩 도구로 작업을 다시 시도해 보는 것입니다. 다른 도구를 직접 써 보아야 Warp가 개선해야 할 약점을 파악할 수 있고, 인공지능 코딩 도구 시장 전체의 흐름을 읽는 감각도 기를 수 있기 때문입니다.

5단계는 여러 도구를 써 보아도 여전히 사람 손으로 직접 타이핑하는 편이 소프트웨어를 배포하는 데 가장 빠르다면, 미련 없이 손으로 코드를 짜는 것입니다.

Warp 5단계 코딩 지침 흐름도

프롬프트로 시작해 성공하면 공유하고 10분이 지나도 정체되면 중단 후 다른 도구나 수작업을 택합니다. (출처: First Round)

이 지침은 인공지능을 쓰지 못하는 사람을 질책하기 위한 규칙이 아니었습니다. 프롬프트로 시작하되 막히면 10분 만에 빠져나오게 함으로써, 시니어 엔지니어가 겪는 초기 전환 비용을 낮춰 주는 안전장치였습니다.

유지보수 가능한 코드를 지키는 세 가지 원칙

지침을 따를 때 코드가 엉망이 되는 사태를 막기 위해 Lloyd는 세 가지 핵심 원칙을 함께 못 박았습니다.

첫 번째 원칙은 최종 결과물만 툭 던지는 프롬프트를 피하는 것입니다. 기능이 겉으로 어떻게 동작해야 하는지만 설명하는 대신, 어떤 함수를 만들어야 하는지, 데이터 모델에 어떤 필드를 추가해야 하는지, 테스트 파일은 어느 폴더에 둘 것인지 구체적인 구현 방식을 지시해야 합니다. 결과만 요구하면 당장은 돌아가더라도 유지보수와 테스트가 불가능하고 기존 모듈과 어울리지 않는 코드가 만들어집니다. 더구나 코드의 내부 구조를 이해하지 못한 채 인공지능이 뱉어낸 결과에만 의존하면, 새로 들어온 팀원이 사내 코딩 관례를 배울 기회마저 사라집니다.

두 번째 원칙은 코드의 주인은 작성자 자신이라는 점입니다. 버그가 터지거나 코드 품질이 떨어졌을 때 “인공지능이 썼다”는 말은 결코 변명이 될 수 없습니다. 인공지능이 작성한 코드도 사람이 손으로 짠 코드와 똑같이 엄격한 품질 기준을 통과해야 합니다. 감에 의존해 코드를 마구 뽑아내는 바이브 코딩은 실패 위험이 극히 낮은 프로젝트에서나 허용될 뿐, 전문적인 엔지니어링 환경에서는 통하지 않습니다.

세 번째 원칙은 한 번에 큰 묶음을 맡기기보다 곁에서 지켜보며 방향을 잡는 것입니다. 에이전트에게 일을 맡겨 두고 커피를 마시러 갔다가 한 시간 뒤에 돌아와 거대한 양의 코드를 확인하는 방식은 복잡한 소프트웨어 작업에서 실패합니다. 개발자는 에이전트가 단계를 밟아 나가는 과정을 세밀하게 지켜보면서, 작고 독립적인 변경 사항과 커밋을 요구하며 올바른 길로 이끌어야 합니다.

실제 현장에서는 원칙을 지키기 위한 구체적인 방법들이 쓰였습니다. 원문 기사에서 Lloyd는 여러 에이전트를 동시에 돌릴 때 코드베이스 사본 여러 개나 git worktree를 쓰라고 권하면서, 실제로 한 사람이 동시에 관리할 수 있는 에이전트는 3~4개를 넘기 어렵다고 밝혔습니다.

git worktree를 쓰면 하나의 저장소에서 여러 작업 폴더를 따로 분리할 수 있어 에이전트끼리 빌드 캐시가 엉키지 않습니다. 하지만 여러 에이전트가 같은 파일을 건드리면 결국 나중에 코드를 합칠 때 충돌이 발생합니다. 현장에서 확인한 3~4개라는 한계는 합치는 과정에서 생기는 충돌 위험과 사람의 주의력 분산 사이에서 경험으로 얻어낸 균형점이었을 것입니다.

피드백 채널에 쌓인 데이터도 버려지지 않았습니다. 엔지니어가 작성한 프롬프트, 대화 식별자, 실패한 전후 사정이 모이면, 실패 유형을 맥락 부족, 저장소 관례 미준수, 모델의 추론 오류 등으로 분류했을 것입니다. 그리고 기대하는 코드 변경분을 정의해 품질 평가 세트로 바꿨을 가능성이 높습니다. 이는 내부 개발 생산성을 높이는 동시에 상용 제품의 성능을 끌어올리는 일석이조의 자산이 되었을 것입니다.

또한 코드 리뷰에서 가장 자주 걸러지는 문제가 기존 기능의 중복 구현이나 아키텍처 패턴 불일치였던 만큼, PR 본문에 에이전트에게 어떤 맥락과 지시를 주었는지 기록하게 하거나, 중복 함수가 없는지 사내 유틸리티를 재사용했는지 확인하는 점검 항목을 리뷰 기준이나 커밋 전 자동 검사 단계에 배치했을 것입니다.

솔선수범이 만든 수치와 조직의 변화

지침을 정착시키는 데 결정타가 된 것은 최고경영자의 솔선수범이었습니다. Lloyd는 전사 회의(All Hands), 고객과의 통화, 매주 진행하는 YouTube 라이브 방송, 심지어 언론 인터뷰 중에도 실시간으로 프롬프트를 입력해 코드를 짜는 모습을 보여 주었습니다.

그는 탭 이름을 바꾸는 화면의 버그를 고치는 PR, 파일 경로를 열 때 터미널 환경 변수인 $EDITOR를 지원하는 작업, 닫았던 터미널 창을 다시 되살리는 단축키인 Command-Shift-Alt-T 기능을 직접 프롬프트로 작성해 구현했습니다. 약 800줄에 이르는 대형 PR도 프롬프트로 시작해 만들었고, 코딩할 때는 주로 음성 입력을 씁니다. Google에서 수석 엔지니어(principal engineer)로 일했던 그의 탄탄한 기술 이력 덕분에, 이런 공개 실천은 개발자들에게 단순한 연출이 아니라 기술적 설득력으로 다가갔습니다.

인터뷰에서 Lloyd는 지도자가 스스로 행동해야 하는 이유를 이렇게 설명했습니다. “내 팀의 모든 엔지니어에게 일하는 방식을 바꾸라고 요구한다면, 내가 그 방식을 진심으로 믿고 있고 실제로 해낼 수 있다는 것을 보여 주는 일이 도움이 됩니다. 그렇지 않으면 나는 그저 인공지능 유행을 따르라고 강요하는 흔한 CEO 중 한 명에 불과할 테니까요.”

이 지침을 3개월 넘게 성실히 실천한 결과, 당시 Warp 내부 엔지니어링 팀은 전체 코딩 작업의 40~50%를 프롬프트로 끝낼 수 있게 된 것으로 추정되었습니다.

참고로 당시 회사의 외부 상용 제품은 하루 약 300만 개의 에이전트가 실행되고 매주 2억 5,000만 줄의 코드가 생성되며 diff 수락률이 97%에 이르고 매출이 19배 성장하는 지표를 보였습니다. 하지만 이는 외부 사용자들이 Warp 제품을 쓰면서 기록한 상업적 성과일 뿐, 내부 엔지니어링 팀 지침의 성과와는 엄격히 구분되어야 합니다. 내부 개발팀의 정량적인 생산성 수치는 당시 구체적으로 공개되지 않았으며, Lloyd는 더 정밀한 내부 측정 방법을 찾는 중이라고 덧붙였습니다.

전환 비용을 낮추는 안전망과 리더십의 솔선

Warp의 세 가지 원칙은 개발자에게 작업 방식을 구체적으로 통제할 것을 요구합니다. 개발자는 단순히 최종 기능이 어떻게 동작해야 하는지만 프롬프트에 던져 넣어서는 안 되며, 어떤 함수를 만들어야 하는지, 데이터 모델에 어떤 필드를 추가해야 하는지, 테스트 파일은 어느 위치에 둘 것인지 직접 지정해야 합니다. 또한 에이전트가 생성한 코드라도 자신이 직접 작성한 코드와 똑같은 품질 기준을 적용해 스스로 온전히 책임져야 하며, 작업을 한 번에 끝내려 하기보다 작은 단위의 변경과 커밋을 지켜보며 올바른 방향으로 이끌어야 합니다. 결과만 지시하는 프롬프트를 금지한 것은 작업의 당장 빠른 속도보다 코드베이스의 장기적인 건강을 선택한 조치였습니다.

시니어 개발자가 보인 저항은 인공지능의 성능 자체에 대한 거부감이 아니었습니다. 반복되는 실패와 기존 코드 품질 기준과의 불일치로 인해 초기에 치러야 하는 전환 비용이 당장 얻는 속도 향상이라는 이득보다 컸기 때문입니다. Lloyd가 마련한 10분 규칙과 비상구는 엔지니어가 시간 낭비라고 판단할 때 즉시 작업을 중단하고 다른 도구나 손코딩으로 넘어갈 수 있게 함으로써, 이 초기 전환 비용을 실질적으로 낮추도록 설계되었습니다.

더 나아가 이 지침은 실패를 개인의 답답함으로 남겨 두지 않고 전용 피드백 채널에 공개적으로 모아 Warp 제품 자체의 기능을 개선하고 내부 평가 세트(eval)를 구축하는 조직적 학습 고리로 전환했습니다. 그러나 이러한 방식이 성립하기 위해서는 분명한 전제 조건이 충족되어야 합니다. CEO나 최고 기술 리더가 지침을 직접 지키며 결과를 공개적으로 보여 주지 않는 상향식 도입은 시니어 개발자의 저항을 넘어서기 어렵습니다. 또한 Warp는 개발자 도구를 만드는 회사이므로 사내 사용이 곧바로 자사 제품의 피드백으로 연결되는 이중 유인이 존재했습니다. 이러한 유인이 없는 일반 조직이라면 10분 뒤 작업을 멈추고 구조화된 피드백을 남기는 3단계를 제도로 튼튼하게 갖추지 않고서는 40~50%라는 프롬프트 작업 완수율에 도달하기 더 어려울 수 있습니다.

이 사례는 소프트웨어 개발을 직접 하지 않는 독자에게도 조직의 행동 방식을 바꾸는 방법에 대해 분명한 시사점을 줍니다. 새로운 작업 방식을 도입할 때 생기는 마찰을 줄이려면 구성원을 억지로 몰아붙이기보다 전문적 판단을 존중하는 안전한 탈출구를 먼저 마련해 전환 비용을 낮춰 주어야 합니다. 실패를 개인의 실패로 묻지 않고 시스템을 고치는 자산으로 환류하는 장치, 그리고 최고 책임자가 규칙을 스스로 실천하며 효용을 증명하는 리더십이 함께 갖추어져야 비로소 일하는 방식의 정착을 기대할 수 있습니다.

출처

First Round — Start With a Prompt: Inside How Warp’s CEO Follows His Own AI Coding Mandate — https://www.firstround.com/ai/warp — 2025-10-08