'어떤 AI 도구를 쓸 것인가'보다 중요한 질문이 있다. '어떤 작업을 어떤 도구에 맡길 것인가'다. 요즘 AI-First 워크플로우 논의에서 이 위임 설계 문제가 세 가지 서로 다른 각도에서 동시에 수면 위로 올라오고 있다.
Cursor 90%, Claude Code 10%—비율이 아니라 원칙의 문제
dev.to에 올라온 한 개발자의 실사용기는 '도구 선택'이라는 질문을 완전히 다르게 프레이밍한다. Cursor와 Claude Code는 경쟁 관계가 아니라 작업의 형태가 다를 뿐이라는 것이다. 그의 결론은 단순하다. 편집(editing)이면 Cursor, 위임(delegating)이면 Claude Code.
Cursor는 에디터 안에 머문다. 인라인 수정, 빠른 자동완성, 지금 보고 있는 파일에 대한 즉각적인 질문—컨텍스트를 잃지 않으면서 개발 흐름을 유지하는 게 핵심이다. 반면 Claude Code는 터미널 네이티브 에이전트다. 프로젝트 전체를 파악하고 여러 파일에 걸친 리팩터링을 수행하며, 개발자가 자리를 비워도 돌아가는 작업에 어울린다. 그는 이걸 이렇게 정리한다. "Cursor는 옆에 앉은 코파일럿, Claude Code는 티켓을 넘겨주는 팀원."
팀 리드 관점에서 이 프레임은 실용적이다. 도구 선택을 감으로 하지 않고, 세 가지 질문으로 명문화할 수 있기 때문이다. '편집인가 위임인가', '변경 범위가 로컬인가 시스템 전체인가', '루프 안에 있을 것인가 결과만 확인할 것인가'. 팀 표준으로 만들 수 있는 기준이다. 이 기준이 없으면 팀원마다 도구를 다르게 쓰고, 어시스턴트에게 30개 파일 리팩터링을 맡기거나 에이전트에게 두 줄짜리 수정을 시키는 비효율이 반복된다.
프롬프트를 자동으로 최적화하는 훅—자동화의 적정 범위
Claude Code에 대한 또 다른 관점은 훅(Hook) 자동화다. steelprompt라는 Claude Code 플러그인은 UserPromptSubmit 훅을 통해 모든 프롬프트를 Anthropic의 7가지 공식 원칙에 따라 자동으로 재구조화한다. 개발자가 "auth 엔드포인트에 rate limiting 추가해"라고 입력하면, 내부적으로 역할 지정, 컨텍스트, 제약 조건, 출력 형식, 단계별 사고 지시까지 갖춘 완전한 프롬프트로 변환된다.
이 설계에서 흥미로운 지점은 두 가지다. 첫째, 별도 API 호출 없이 Claude의 추론 과정 안에서 재구조화가 이루어져 추가 지연과 비용이 없다. 둘째, 5단어 이하의 단순 명령은 그냥 통과시키는 3단계 결정 프로토콜로 오버헤드를 방지한다. 이건 자동화 설계의 핵심 원칙과 맞닿아 있다. 모든 것을 자동화하는 게 아니라 자동화가 가치를 만드는 지점을 정밀하게 설계하는 것.
팀에 도입한다면 preview 모드가 특히 유용하다. 자동으로 재구조화된 프롬프트를 실행 전에 보여주기 때문에, 팀원들이 좋은 프롬프트가 어떻게 생겼는지를 반복적으로 학습할 수 있다. 도구가 결과만 내놓는 게 아니라 학습 기회도 제공하는 구조다.
Bun의 9일 리라이트—속도가 리스크가 된 순간
그리고 이 글에서 가장 직면해야 할 사례가 있다. Bun 런타임이 LLM을 활용해 Zig 코드베이스 전체를 Rust로 재작성하는 데 9일이 걸렸다.
속도 자체가 문제는 아니다. 진짜 문제는 "작동한다"와 "이해한다"가 분리된 상태로 머지됐을 가능성이다. LLM이 생성한 코드는 컴파일될 수 있다. 테스트를 통과할 수도 있다. 그러나 "왜 이 라인이 이렇게 작성됐는가"에 대한 이해는 코드와 함께 이전되지 않는다. 메모리 안전성, 이벤트 루프 엣지 케이스, OS별 시스템 콜 동작—이런 것들은 인간 저자가 설계 의도를 설명할 수 있을 때 제대로 리뷰된다.
dev.to의 해당 글 필자는 이걸 이렇게 요약한다. "코드를 이해하지 못하면 장애 발생 시 디버깅할 수 없다. 그리고 런타임은 '작동하면 건드리지 말자' 코드가 가장 위험한 곳이다." JavaScript 런타임처럼 수백만 사용자에게 영향을 주는 시스템에서 이 리스크는 단순한 기술 부채가 아니다.
이 사례가 선례가 된다는 점이 더 무겁다. Bun이 했으니 모든 팀이 시도할 것이다. 스타트업은 레거시 서비스를 며칠 만에 다른 언어로 포팅하려 할 것이고, CTO는 예전엔 몇 달이 걸렸을 결정을 며칠 만에 승인할 것이다. 코드를 생성하는 장벽은 거의 없어졌지만, 그 코드를 진짜로 이해하는 장벽은 그대로다.
세 사례가 함께 가리키는 것
이 세 가지는 AI 도구의 서로 다른 면을 보여주지만, 결국 같은 질문으로 수렴한다. 위임의 범위를 어떻게 설계할 것인가.
Cursor vs Claude Code 프레임은 작업 단위의 위임 설계다. 무엇을 손에 쥐고 무엇을 넘길지 판단 기준을 명문화하는 것. steelprompt 훅은 프롬프트 품질의 위임 설계다. 반복적인 구조화 작업을 자동화하되 학습 가시성은 유지하는 것. Bun의 사례는 이 설계 없이 속도만 앞세웠을 때 어떤 리스크가 생기는지를 보여주는 반면교사다.
팀 리드로서 내가 주목하는 원칙은 하나다. AI에게 맡기는 범위가 클수록, 검증 구조도 같이 커져야 한다. 9일 만에 런타임을 재작성할 수 있다면, 그 결과물을 깊이 이해하는 데 걸리는 시간도 반드시 계획에 포함되어야 한다. 그 시간을 건너뛰면 속도가 자산이 아니라 부채가 된다.
내일부터 팀에 적용할 수 있는 것
위임 설계는 거창한 아키텍처 결정이 아니다. 당장 팀 표준으로 만들 수 있는 세 가지가 있다.
첫째, 도구 선택 기준을 명문화한다. '편집이면 에디터 코파일럿, 시스템 전체 변경이면 에이전트'처럼 간단한 기준만 있어도 팀원의 도구 선택이 일관성을 갖는다. 둘째, 에이전트 작업일수록 프롬프트 품질에 투자한다. 에디터 코파일럿에 애매한 프롬프트를 던지면 나쁜 제안 하나지만, 에이전트에게 던지면 잘못된 방향의 전체 실행이다. 셋째, 대규모 AI 자동화 이후에는 반드시 이해 검증 단계를 넣는다. 코드가 작동하는지 확인하는 것과 팀이 그 코드를 이해하는지 확인하는 것은 별개의 프로세스다.
AI 도구의 잠재력은 의심할 여지가 없다. 하지만 그 잠재력이 팀의 역량으로 전환되려면, 도구가 아니라 위임 설계가 먼저다. 무엇을 맡길지 결정하지 않은 팀은 AI가 빠르게 만든 것을 결국 느리게 수습하게 된다.