Warp가 OpenAI와 함께 공개한 Open Agentic Development 사례는 개발팀이 코딩 에이전트를 어떻게 운영해야 하는지 보여주는 좋은 재료입니다. Warp는 올해 터미널 클라이언트를 오픈소스로 공개했고, OpenAI가 해당 repo의 founding sponsor로 참여했습니다. 공개 설명에 따르면 Warp는 약 100만 명의 개발자가 사용하고, Fortune 500의 56% 이상에서 쓰이며, 내부 엔지니어링 조직에서는 에이전트가 회사 pull request의 약 90%를 공동 생성한다고 말합니다. 또한 GPT-5.5가 GPT-5.4 대비 agentic coding task에서 30% 적은 토큰을 사용했다는 내부 벤치마크도 언급했습니다.
이 글은 Warp 자체 홍보가 아니라, 장시간 코딩 에이전트를 터미널과 클라우드에서 운영하려는 팀이 무엇을 준비해야 하는지 정리합니다. 핵심은 모델이 아니라 observability, coordination, memory, human review입니다.
짧은 코드 생성은 쉽습니다. 함수 하나, 테스트 하나, README 수정은 대부분의 모델이 그럴듯하게 처리합니다. 문제는 장시간 작업입니다. 저장소를 탐색하고, 계획을 세우고, 여러 파일을 바꾸고, 테스트를 실행하고, 실패를 고치고, PR을 여는 흐름은 완전히 다릅니다.
오래 도는 에이전트는 다음 문제를 만납니다.
Warp가 terminal을 에이전트 협업의 자연스러운 장소로 본 이유는 명확합니다. 개발자의 실제 작업은 명령, 로그, 파일, 리뷰, 협업이 만나는 곳에서 일어납니다. 에이전트도 같은 곳에서 관측 가능해야 합니다.
일반 코딩 도우미는 현재 파일과 근처 컨텍스트를 봅니다. 장시간 에이전트는 여러 실행 환경과 작업 상태를 관리해야 합니다. Warp의 Oz는 로컬과 클라우드 환경에 걸쳐 에이전트를 배포하고 조율하는 control plane 역할을 합니다. 웹 인터페이스에서 에이전트를 시작하고, predefined skill과 environment를 선택하고, 모델과 호스팅 구성을 고르고, 실행 상태와 산출물을 중앙에서 봅니다.
여기서 중요한 포인트는 “에이전트를 여러 개 띄운다”가 아닙니다. 어떤 에이전트가 무엇을 맡고, 어떤 권한이 있고, 어디까지 진행했으며, 사람이 언제 개입할 수 있는지를 관리하는 체계입니다. 이 체계 없이 에이전트를 병렬로 돌리면 속도가 아니라 혼선이 늘어납니다.
첫째, 작업 분해 레이어입니다. 모든 작업을 한 에이전트에게 맡기지 말고 탐색, 구현, 테스트, 리뷰 준비를 나눕니다. 코드 검색이나 파일 분석은 dedicated subagent가 맡을 수 있습니다. 하지만 데이터 스키마, 인증, 결제처럼 강한 일관성이 필요한 영역은 병렬화하지 않는 편이 안전합니다.
둘째, 메모리 레이어입니다. 긴 작업에서는 context compaction과 persistent memory가 필요합니다. 다만 모든 대화를 저장하면 잡음이 됩니다. 기억해야 할 것은 목표, 결정, 변경 금지 영역, 이미 확인한 파일, 실패한 시도, 현재 가설입니다.
셋째, 권한 레이어입니다. 읽기 전용 탐색, 파일 수정, 테스트 실행, 네트워크 접근, 배포 명령을 분리해야 합니다. 에이전트가 처음부터 모든 권한을 가지면 실수 비용이 커집니다.
넷째, 리뷰 레이어입니다. PR은 코드 diff만 있으면 안 됩니다. 에이전트가 왜 이 범위만 바꿨는지, 어떤 테스트를 실행했는지, 어떤 리스크를 남겼는지 써야 합니다. 사람이 판단할 수 없는 PR은 자동화가 아니라 부채입니다.
Warp 사례에서 흥미로운 부분은 로컬과 클라우드 사이의 handoff입니다. 에이전트가 클라우드에서 계속 돌고, 개발자는 live session을 inspect하며, 필요하면 로컬 환경으로 이어받을 수 있습니다. 이 패턴은 실제 개발팀에서 유용합니다.
예를 들어 긴 마이그레이션 작업을 클라우드 에이전트에게 맡깁니다. 에이전트는 의존성 오류를 고치고 테스트를 돌립니다. 개발자는 중간에 로그를 보고 특정 방향을 중단시키거나, 브랜치를 로컬로 가져와 직접 디버깅합니다. 다시 에이전트에게 남은 반복 작업을 맡길 수 있습니다.
이를 구현하려면 세 가지 정보가 항상 남아야 합니다.
이 세 가지가 없으면 handoff는 “대화 이어가기”가 아니라 “처음부터 다시 설명하기”가 됩니다.
Warp는 GPT-5.5가 GPT-5.4보다 agentic coding task에서 30% 적은 토큰을 사용했다고 설명했습니다. 토큰 효율은 중요합니다. 장시간 작업에서는 같은 목표를 더 적은 턴과 토큰으로 끝내는 모델이 비용과 지연 시간을 줄입니다.
하지만 팀 내부 평가는 토큰만 보면 안 됩니다. 다음 지표를 같이 보세요.
토큰이 적어도 PR이 이해 불가능하면 실패입니다. 반대로 토큰이 조금 더 들더라도 변경 범위가 작고 리뷰가 쉬우면 실무에서는 더 낫습니다.
처음부터 “PR의 90%를 에이전트가 만들게 하자”는 목표를 잡으면 안 됩니다. Warp 같은 팀도 control plane, memory, evaluation, human review를 함께 만들었습니다. 일반 팀은 작은 루프부터 시작해야 합니다.
1단계는 읽기 전용 분석입니다. 이슈를 주고 관련 파일, 영향 범위, 위험 지점을 찾게 합니다. 2단계는 테스트 추가입니다. 기능 변경 없이 실패를 재현하는 테스트나 회귀 테스트를 만들게 합니다. 3단계는 작은 패치입니다. 수정 파일 수를 제한하고 PR을 열게 합니다. 4단계는 반복 마이그레이션입니다. 패턴이 분명한 변경을 여러 파일에 적용하게 합니다.
각 단계마다 rollback과 review 기준을 정해야 합니다. “에이전트가 알아서 하겠지”가 아니라 “어디까지 허용할 것인가”가 먼저입니다.
Warp 사례의 핵심은 “터미널에 AI를 붙였다”가 아닙니다. 장시간 코딩 에이전트를 운영하려면 control plane이 필요하다는 점입니다. 모델은 작업을 실행하지만, 팀이 신뢰하는 속도는 관측, 조율, 메모리, 리뷰에서 나옵니다.
참고: OpenAI, “Warp’s big bet on building open source with GPT-5.5”, 2026-05-27.
