'AI에게 어디까지 맡겨도 되는가'라는 질문은 더 이상 철학적 논쟁이 아니다. 이미 실무에서 매일 마주치는 설계 결정이다. Claude Code로 소프트웨어 개발 생명주기 전체를 오케스트레이션한 사례, MVP 단계에서 완벽한 아키텍처를 쫓다 3일을 날린 경험, 그리고 Bun이 Anthropic에 인수된 이후 서서히 쌓이는 불안—세 갈래의 이야기가 하나의 질문으로 수렴한다. 도구를 신뢰하는 것과, 도구에 의존하는 것은 어떻게 다른가.
에이전트 호출의 단위는 '판단'이어야 한다
dev.to에 공개된 Claude Code 오케스트레이션 아키텍처 사례는 이 질문에 가장 구체적인 답을 내놓는다. 저자가 수개월간 실제 운영한 이 시스템의 핵심 테제는 한 문장이다. "에이전트를 호출하는 단위는 워크플로우가 아니라 판단 단계여야 한다."
API 호출, 테스트 실행, git 조작처럼 결과가 예측 가능한 기계적 단계는 결정론적 Python 스크립트가 처리한다. Claude Code는 코드 작성, 리뷰 소견 평가, 두 아키텍처 옵션 중 선택처럼 진짜 판단이 필요한 순간에만 개입한다. 이 구분은 단순한 성능 최적화가 아니다. 에이전트를 감사(audit) 가능하게 만들고, 토큰 소비를 줄이며, 실패 지점을 명확히 격리한다.
6개 레이어로 구성된 이 아키텍처에서 눈에 띄는 원칙은 세 가지다. 첫째, Python이 조율하고 에이전트가 추론한다—기계적 단계는 2초 이내에 완료되는 결정론적 코드가, 판단이 필요한 단계만 Claude Code가 맡는다. 둘째, 실행이 아닌 제안—코드 병합, 티켓 종료 같은 비가역적 외부 액션은 반드시 사람의 승인을 거친다. 셋째, 컨텍스트 축적—아키텍처 결정, 팀 소유권, 티켓 이력은 영구 위키와 데이터베이스에 쌓여 매 세션마다 재도출하지 않는다. 이 세 원칙은 모두 같은 방향을 가리킨다. 자동화의 속도는 취하되, 통제의 고삐는 놓지 않는다.
'충분히 좋은 것'이 가장 좋은 설계일 때
위임의 기술은 도구를 상대로 한 이야기만이 아니다. AI 에이전트가 데이터를 쓰는 기능을 구현하면서 3일간 Lambda, IAM, API Gateway를 설계하다 코드 한 줄 작성 못 했다는 dev.to의 고백은, AI 도구 시대의 또 다른 함정을 드러낸다. 완벽한 아키텍처를 설계하는 것으로 '배포'를 회피하는 패턴이다.
멘토의 한마디가 이 상황을 깨뜨렸다. "SQLite 파일 하나 있는 로컬 개발 환경에서 클라우드 아키텍처를 설계하고 있다고요?" MVP 단계에서 진짜 리스크는 'AI가 잘못된 SQL을 쓸 수 있다'는 것이었고, 그 리스크의 99%는 네 개의 Python 함수—100줄 미만—로 충분히 막을 수 있었다. 입력 유효성 검증, 파라미터화된 SQL, 트랜잭션 래핑. 나머지 1%의 클라우드 권한 관리는 실제로 클라우드에 올라갈 때 해도 늦지 않다.
이 원칙은 AI 도구 위임에도 그대로 적용된다. 에이전트에게 무엇을 맡길지 결정할 때, 지금 단계에서 가장 큰 리스크가 무엇인지 먼저 물어야 한다. 최소한의 노력으로 그 리스크의 대부분을 막을 수 있다면, 나머지는 나중의 문제다. 완벽한 가드레일을 설계하느라 아무것도 검증하지 못하는 것보다, 작동하는 무언가를 빠르게 배포해서 실제 문제를 마주치는 편이 낫다. "배포된 99% 솔루션은, 존재하지 않는 100% 솔루션보다 가치가 높다."
도구 신뢰의 균열: Bun이 Anthropic에 들어간 뒤
그런데 맡길 도구 자체를 신뢰할 수 없다면? GeekNews에서 화제가 된 'Bun이 걱정된다'는 글은 이 질문을 정면으로 꺼낸다. 핵심은 Bun의 품질이 아니다. Anthropic이 2025년 12월 Bun을 인수한 이후, Claude Code라는 제품 레이어에서 드러나기 시작한 균열이 Bun에도 전이될 수 있다는 불안이다.
2026년 4월 이후 Claude Code에서는 품질 저하, 서드파티 하네스 제한, 예측 불가한 과금 동작이 잇따라 보고됐다. Anthropic이 공개한 사후 분석은 기본 추론 노력값 감소와 프롬프트 변경 같은 제품 계층 문제를 원인으로 지목했다. git 히스토리에 OpenClaw가 언급된 것만으로 요청이 거부되거나 추가 과금이 발생했다는 보도는, 이 도구가 실제 코드 수준에서 충분히 검증되지 않은 채 변경 사항이 배포됐음을 시사한다.
글쓴이의 진단은 날카롭다. "예전의 Claude Code는 Anthropic이 개발자 도구를 이해한다는 증거처럼 보였다. 지금은 Anthropic이 제품을 장기적으로 유지하고 개선하는 데 필요한 것을 모를 수 있다는 경고처럼 보인다." Bun은 Claude Code 안에 깊이 들어가 있다. Claude Code가 나빠지는 방식으로, Bun도 같은 방향으로 갈 수 있다는 우려는 Bun 팀의 역량 문제가 아니라 모회사의 정책이 제품 문화에 스며드는 방식에 대한 구조적 의심이다.
Hacker News의 반응은 엇갈렸다. Bun 팀원은 "Anthropic 합류 이후 안정성이 오히려 개선됐고 개발 속도도 빨라졌다"며 반박했다. 반면 "Anthropic은 JavaScript 커뮤니티 전체를 위해서가 아니라 Claude Code 투자를 보호하기 위해 Bun을 인수했다. 장기적으로 결과는 인센티브를 따라간다"는 냉소적 시각도 유효했다. 결론은 아직 열려 있다. 다만 한 가지는 분명하다—도구를 선택할 때, 그 도구가 누구의 인센티브 구조 안에 있는지도 설계의 일부다.
시사점: 위임 설계의 세 가지 축
세 이야기를 겹쳐 읽으면 AI 개발 도구 위임에서 지켜야 할 세 가지 축이 선명해진다.
첫 번째, 판단과 실행을 분리하라. Claude Code 오케스트레이션 사례가 증명하듯, 에이전트는 판단이 필요한 단계에만 개입해야 한다. 기계적 실행을 에이전트에게 맡기는 것은 토큰 낭비이자 감사 불가능성의 원인이다. 워크플로우의 어느 단계가 진짜 '판단'을 요구하는지 먼저 매핑하라.
두 번째, 현재 단계에 맞는 신뢰 수준을 설계하라. MVP에서는 100줄짜리 방어 계층으로 충분하다. 완벽한 보안 아키텍처를 설계하느라 검증을 미루는 것은 사실상 배포를 두려워하는 회피다. 지금 가장 큰 리스크가 무엇인지 물고, 그것만 막아라. 나머지는 실제로 필요해질 때 한다.
세 번째, 도구의 인센티브 구조를 신뢰의 조건으로 읽어라. 도구의 기술적 품질만큼이나, 그 도구를 만들고 유지하는 조직이 어떤 방향으로 움직이는지가 장기적 신뢰도를 결정한다. Bun 사례는 오픈소스 라이선스 유지 선언만으로는 충분하지 않음을 보여준다. 실제 제품 운영 방식과 커뮤니케이션 패턴을 지속적으로 관찰하는 것이 위임 설계의 일부다.
전망: 위임은 결국 설계의 문제다
AI 도구가 개발 워크플로우 깊숙이 들어올수록, 역설적으로 개발자가 설계해야 할 것들은 더 많아진다. 어떤 단계를 자동화할지, 어디에 인간 승인 게이트를 둘지, 지금 단계에서 어떤 리스크가 진짜 중요한지, 그리고 그 도구가 1년 뒤에도 같은 방향으로 움직일 것인지—이 모든 것이 위임 설계의 범위 안에 들어온다.
'맡기는 기술'이란 결국 경계를 긋는 기술이다. 에이전트에게 맡길 것과 인간이 쥐고 있을 것을 구분하는 선은, 도구가 그어주지 않는다. 그것은 여전히 개발자의 판단 영역이다—그리고 아마 가장 오래 그럴 것이다.