Warp — CEO가 직접 따르는 코딩 매뉴얼, 그리고 시니어 개발자 저항 문제

1. 왜 이 사례인가

Warp는 터미널 도구에서 ‘에이전트형 개발 환경(Agentic Development Environment, ADE)‘으로 피벗한 개발자 도구 회사입니다. 이 사례에서 다루는 내용은 Warp의 상용 제품 자체가 아니라, Warp 내부 엔지니어링 팀이 자사 AI 도구를 써서 실제로 어떻게 코드를 작성하는가입니다. 즉 이 사례는 판매사가 자사 제품을 내부에서 도그푸딩(dogfooding)한 조직 관행 기록입니다.

First Round가 2025년 10월 8일 게재한 인터뷰에서 Warp 창업자 겸 CEO Zach Lloyd는 세 가지 내용을 공개했습니다. 첫째는 시니어 개발자가 AI 도구를 가장 강하게 거부하는 원인과 대응 방식입니다. 둘째는 모든 코딩 작업을 프롬프트로 시작하라는 팀 내부 매뉴얼의 전문과 원칙입니다. 셋째는 CEO가 직접 매뉴얼을 따르며 공개적으로 보여주는 행동이 채택률에 왜 결정적인지에 대한 설명입니다.

이 사례에서 살펴볼 대상은 Warp의 제품 성장 지표(Revenue 19배, 하루 300만 에이전트 실행)가 아닙니다. 이는 회사의 상업적 성과입니다. 이 글이 전달하는 핵심은 내부 엔지니어링 팀이 에이전트형 개발 방식을 실제로 정착시킨 조직 관행과 시행착오입니다.

2. Problem

Lloyd가 직면한 과제는 단순히 새 도구를 도입하는 일이 아니었습니다. 시니어 개발자의 구조적 저항이 핵심 문제였습니다.

Lloyd는 수백 개의 댓글이 달린 소셜 미디어 게시물에서 이 현상을 공개적으로 언급했습니다. “우리는 Warp에서 AI 개발 도구를 직접 만들고 있는데, 엔지니어들이 이 도구를 더 많이 쓰도록 습관을 바꾸게 하는 것이 여전히 어렵다”는 내용이었습니다. 반면 비개발 직군(디자이너, PM, CEO 본인)은 AI를 가장 적극적으로 채택하는 집단이었습니다.

시니어 개발자가 저항하는 이유는 세 가지입니다.

첫째, 비개발 직군에게 AI는 불가능을 가능하게 만들지만 시니어 개발자에게는 기껏해야 속도를 높여 주는 도구에 불과합니다. 이미 잘하는 일을 조금 더 빠르게 처리하는 것만으로는 강력한 동기가 생기지 않습니다.

둘째, 프롬프트 기반으로 처음 작업하면 오히려 시간이 더 걸리거나 실패하는 경험이 반복됩니다. 한두 번 시도해서는 업무 방식의 전환이 일어나지 않는 이유입니다.

셋째, 에이전트가 생성한 코드가 동작은 하더라도 팀의 코딩 표준이나 아키텍처 패턴을 따르지 않아 머지할 수 없는 품질인 경우가 발생합니다. 이러한 경험이 “AI는 쓸모없다”는 결론으로 이어집니다.

확인된 사실: CEO가 직접 매뉴얼을 따름(최근 약 3개월+), 비개발 직군이 가장 먼저 적극 채택(디자이너, PM, CEO), 시니어 개발자가 가장 강하게 저항, 매뉴얼 도입 3개월+ 후 전체 코딩 작업의 40~50% 프롬프트로 완료.

3. Solution

Lloyd의 대응책은 팀 전체에 배포한 내부 코딩 매뉴얼과, 이를 CEO가 솔선수범해 직접 따르는 가시적인 행동이었습니다.

3.1 5단계 코딩 매뉴얼

매뉴얼은 5단계로 구성됩니다.

1단계: 모든 코딩 작업을 Warp에서 프롬프트로 시작합니다. Lloyd는 세 가지 이유를 듭니다. 멀티스레딩(여러 에이전트를 병렬로 실행해 회의 중에도 코드를 작성하는 방식), 익숙하지 않은 코드 영역에서의 효율성, 그리고 팀의 도그푸딩 의무입니다.

2단계: 작업에 성공한 경우 #warped-it Slack 채널에 공유합니다. Lloyd는 이 채널에 본인의 PR을 직접 올립니다. 성공 사례를 공유해 눈에 띄게 만들면 팀 전체의 프롬프트 엔지니어링 관행이 개선됩니다.

3단계: 10분이 지나도 시간 낭비라는 생각이 들면 즉시 중단하고 피드백 채널에 공유합니다. Lloyd는 이를 “스마트한 탈출구”라고 부릅니다. 개인의 판단을 존중한다는 신호가 없으면 매뉴얼은 지적 억압으로 작용합니다. 공유된 피드백은 팀이 제품을 개선하거나 평가(eval)를 구축하는 소재로 쓰입니다.

4단계: 다른 AI 코딩 도구(Cursor, Claude Code)로 전환해 봅니다. 경쟁 도구를 써 보는 것은 자사 제품의 약점을 찾는 방법이자, 팀 전체가 시장 감각을 키우는 수단이기도 합니다.

5단계: 앞선 모든 단계에서 시간이 더 걸린다면 직접 손으로 코딩합니다. 소프트웨어를 배포해야 하는 상황에서 수작업이 여전히 가장 빠른 방법이라면 그렇게 진행해야 합니다.

3.2 세 가지 핵심 원칙

매뉴얼의 단계보다 더 실질적인 내용은 아래의 세 원칙입니다.

원칙 1: 결과 기반 프롬프팅을 피합니다. 에이전트에게 “이 기능이 이렇게 동작하면 돼”라고 말하는 대신, “이 함수를 이렇게 작성하고, 데이터 모델은 이 필드를 가지며, 테스트는 여기에 둬”처럼 구현 방법을 명시합니다. 결과만 지정하면 에이전트가 동작은 하지만 유지보수하기 어려운 코드를 생성할 가능성이 높습니다. 코드베이스를 이해하지 못한 채 에이전트의 출력에만 의존하면, 신규 팀원이 코딩 관행을 학습하기도 어렵습니다.

원칙 2: 코드 소유권은 개발자에게 있습니다. “AI가 짰다”는 말은 버그나 낮은 품질을 정당화하는 변명이 되지 못합니다. 에이전트가 생성한 코드는 수작업으로 작성한 코드와 똑같은 품질 기준을 충족해야 합니다. 단순히 동작하는 코드가 아니라 구조가 잘 갖추어진 코드가 목표입니다. “Vibe coding”은 위험 부담이 낮은 프로젝트에서만 허용됩니다.

원칙 3: 원샷보다 베이비시팅이 낫습니다. 에이전트를 실행해 두고 커피를 마시러 갔다가 한 시간 뒤 대량의 코드를 확인하는 방식은 복잡한 작업에서 실패하기 쉬운 패턴입니다. 에이전트가 변경을 진행하는 동안 코드를 자주 확인하면서 방향을 조정해야 합니다. 작고 독립적인 단위로 변경과 커밋을 요청하는 방식이 더 효과적입니다.

확인된 사실: 5단계 매뉴얼 Notion에 공개, 매주 팀 미팅에서 반복 검토, 10분 규칙, 피드백 채널 운영, #warped-it Slack 채널, 결과 기반 프롬프팅 금지, 에이전트 생성 코드 동일 품질 기준, CEO 직접 프롬프트 기반 PR 작성(약 800줄 PR 예시 포함), 목소리 입력(voice) 활용.

3.3 CEO의 가시적 실천

Lloyd가 매뉴얼 정착 과정에서 가장 중요하다고 강조하는 점은, 스스로 매뉴얼을 따르고 이를 공개적으로 보여주는 행동입니다. All Hands 미팅 발표, 고객 통화, YouTube 주간 라이브 스트림, First Round 인터뷰 중에도 직접 프롬프트 기반 개발을 시연합니다. 탭 이름 변경 인터페이스 버그 수정 PR, 파일 링크 환경변수($EDITOR) 지원 PR, 터미널 분할 창(pane) 복원 단축키(Command-Shift-Alt-T) 추가 PR 등이 대표적인 사례입니다.

확인된 사실: CEO가 실제 프롬프트 기반 PR 작성(~800줄 포함), All Hands·YouTube·미디어에서 시연, Google 전직 수석 엔지니어 출신(신뢰성 기반), 매뉴얼 Notion 전문 공개.

4. Impact

First Round 기사(2025-10-08) 기준 내부 엔지니어링 지표입니다.

지표	수치	비고
코딩 작업 완료율 (프롬프트 기반)	40~50%	매뉴얼 도입 3개월+ 후 기준
매뉴얼 검토 빈도	주 1회	팀 미팅에서 반복
기준일	2025-10-08	First Round 게시일 기준

기사에는 Warp 상용 제품의 성장 지표도 함께 언급됩니다(일 300만 에이전트 실행, 주 2억 5천만 줄 코드, 97% diff 수락률, 매출 19배 성장). 이 수치들은 외부 사용자의 Warp 제품 사용 지표이며, 내부 엔지니어링 팀의 성과와 혼동해서는 안 됩니다.

Lloyd는 도입 3개월 후 더 구체적인 생산성 측정 지표를 마련하는 방안을 검토 중이라고 밝혔으나, 기사가 나온 시점까지 정량적인 내부 생산성 데이터는 공개되지 않았습니다.

5. Insight

이 사례의 핵심은 단순한 기술 도입이 아니라 조직 행동 변화의 설계에 있습니다.

시니어 개발자 저항은 기술적 문제가 아닙니다. 저항이 일어나는 이유는 AI 성능이 떨어져서가 아니라, 전환 비용(실패 경험의 반복, 품질 기준의 불일치)이 즉각적으로 얻는 이익을 넘어서기 때문입니다. 매뉴얼의 10분 규칙과 탈출 조항은 이러한 전환 비용을 낮추도록 설계된 장치입니다.

리더가 직접 따르지 않는 매뉴얼은 작동하지 않습니다. Lloyd의 접근법은 “나를 보라”는 방식입니다. 인터뷰에서 그는 “엔지니어들에게 이렇게 일하라고 요청한다면, 내가 실제로 그렇게 믿는다는 것을 보여주는 것이 필요하다. 그렇지 않으면 AI 유행을 따르라는 CEO에 불과하다”고 말합니다.

결과 기반 프롬프팅 금지는 단기와 장기의 트레이드오프입니다. 결과만 지정하면 에이전트가 더 자율적으로 작동해 언뜻 빨라 보이지만, 코드 품질 저하와 코드베이스에 대한 이해 부족 탓에 장기적인 비용이 발생합니다. 이 원칙은 일시적인 생산성 극대화보다 코드베이스의 건전성을 우선시한 판단입니다.

피드백 채널이 학습 루프를 만듭니다. 에이전트 실패 경험을 개인의 좌절로 묻어 두지 않고 팀 채널에 공유하도록 하여, 반복되는 실패 패턴이 제품 개선이나 평가 구축으로 이어지는 구조를 마련했습니다.

복제 조건: 이 사례의 핵심 전제는 CEO나 최고 기술 리더가 매뉴얼을 직접 따르고 공개적으로 시연하는 것입니다. 리더십의 솔선수범이 없는 상향식 도입만으로는 시니어 개발자의 저항을 해소하기 어렵습니다. 아울러 Warp는 자사 AI 도구를 직접 개발하는 회사이므로, 도그푸딩 과정이 제품 피드백 수집과 맞물려 돌아가는 특수한 유인이 존재합니다. 이러한 유인이 없는 조직이라면 3단계(10분 후 중단 및 피드백 공유)를 시스템으로 갖추지 않고서는 40~50% 완료율에 도달하기가 더 어려울 수 있습니다.

6. 원문에 없는 추정 (구현 가설)

6.1 멀티스레딩 환경 설정: 워크트리와 병렬 에이전트 관리

근거: 기사는 Lloyd가 여러 에이전트를 동시에 실행하는 방법으로 코드베이스 복사본 여러 개를 두거나 git worktree를 활용할 것을 권장하며, 3~4개 이상의 에이전트를 동시에 관리하기는 어렵다고 설명합니다.

git worktree는 하나의 리포지터리에서 브랜치를 서로 다른 디렉터리에 체크아웃하는 고유 기능입니다. 에이전트마다 독립된 작업 디렉터리를 할당하면 빌드 캐시 충돌 없이 병렬로 실행할 수 있습니다. 다만 여러 에이전트가 동일한 파일을 수정할 경우 나중에 머지할 때 충돌이 발생합니다. Warp 팀이 3~4개를 실용적인 한계로 제시한 것은 이러한 충돌 위험과 컨텍스트 전환 비용을 함께 고려한 경험치일 가능성이 높습니다.

6.2 피드백 채널 데이터의 평가(eval) 파이프라인 전환

근거: 기사는 에이전트 실패 경험을 피드백 채널에 공유하면 팀이 그 데이터로 평가(eval)를 구축할 수 있다고 언급합니다.

엔지니어가 “프롬프트, 대화 ID, 실패 맥락”을 공유한다는 것은 실패 사례마다 구조화된 입력값이 축적된다는 뜻입니다. 이 데이터를 eval로 전환하려면 실패 유형 분류(문맥 부족, 코드베이스 패턴 불일치, 모델 추론 오류 등)와 기대 출력 정의가 필요합니다. Warp는 자사 에이전트 제품을 내부에서 직접 사용하므로, 이 eval 파이프라인은 내부 생산성 도구와 외부 상용 제품 개선이라는 두 가지 목적을 동시에 지원합니다. 이러한 이중 활용 구조가 피드백 수집을 유도하는 조직적 요인으로 작용하고 있을 것으로 분석됩니다.

6.3 원칙 2(코드 소유권)의 실질적 적용 방법

근거: 기사는 에이전트가 생성한 코드를 수작업 코드와 동일한 품질 기준으로 검토하며, 코드 리뷰 과정에서 중복 코드와 패턴 불일치가 가장 많이 발견된다고 설명합니다.

에이전트가 작성한 코드를 리뷰할 때는 추가적인 인지 부담이 따릅니다. 작업자가 코드를 직접 작성하지 않았으므로 리뷰어가 변경 의도와 구현 방식을 함께 파악해야 하기 때문입니다. 따라서 Warp의 매뉴얼에는 “PR 본문에 에이전트와 협력한 방식을 명확히 설명하라”는 요구 사항이 포함되어 있을 가능성이 있습니다. 또한 에이전트 기반 PR에 적용되는 특화 리뷰 체크리스트(중복 함수 확인, 기존 유틸리티 재사용 여부 확인, 테스트 커버리지 확인)가 Warp의 코드 리뷰 가이드라인에 추가되었거나, 자동화된 사전 점검 단계로 통합되어 있을 개연성이 높습니다.

7. 출처

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 (기사 본문 날짜)
- 본 초안은 Warp 내부 엔지니어링 관행만 다룹니다. 기사에 언급된 상업 제품 성장 지표(매출, 에이전트 실행 수 등)는 내부 팀 성과와 별개의 데이터입니다.