1,000시간 AI 코딩 에이전트 실무를 쌓은 개발자가 꼽은 '절대 위임하지 않는 영역'이 있다. DB 마이그레이션, JWT 검증 로직, 동시성 공유 상태, 그리고 타 팀에 노출된 API 컨트랙트. 이 목록은 단순한 개인 취향이 아니다. 최근 발생한 Claude Code RCE 보안 취약점과 졸업식 TTS 무음 실패 사례를 나란히 놓으면, 세 사례 모두 같은 구조적 구멍을 가리킨다. 위임 경계를 설계하지 않은 시스템은, AI가 틀리는 순간 아무도 알아채지 못한다.
위임 경계 없이 자율을 주면 생기는 일
Dev.to에 공개된 1,000시간 실무 경험 기사는 첫 줄부터 냉정하다. AI 에이전트에게 프로덕션 코드베이스의 실질적 자율을 처음 줬을 때, 에이전트는 유틸리티 메서드를 자신 있게 리팩터링했다. 코드는 컴파일됐고, 유닛 테스트도 통과했다. 스테이징이 깨지기까지 두 시간이 걸렸다. JSON 직렬화 동작이 미묘하게 바뀌어 있었기 때문이다. 에이전트는 틀린 게 아니었다. 경계가 없었을 뿐이다.
이 경험이 도달한 결론이 '목표가 아닌 태스크를 위임하라'는 원칙이다. "인증을 추가해"는 목표다. 에이전트는 라이브러리 선택, 토큰 만료 처리, 설정 방식까지 수십 개의 암묵적 결정을 혼자 내린다. 각 결정은 개별적으로 합리적이지만, 합쳐지면 팀의 관습과 전혀 맞지 않는 코드가 나온다. 반면 "UserController.java에 Bucket4j로 IP당 분당 100회 제한 필터를 추가하고, 101번째 요청에서 429를 반환하는 테스트를 UserControllerTest에 추가해. 다른 컨트롤러는 건드리지 마"는 태스크다. 위임 가능한 단위는 이 수준의 경계를 가져야 한다.
보안 취약점이 가르쳐준 것: AI 도구 자체도 경계가 필요하다
Claude Code CLI에서 발견된 RCE(원격 코드 실행) 취약점은 위임 경계 문제를 다른 층위에서 보여준다. 이 취약점의 핵심은 AI 모델의 논리 오류가 아니라, CLI 초기화 과정의 eagerParseCliFlag 함수에 있었다. 이 함수는 Commander.js가 실행되기 전에 --settings 같은 플래그를 먼저 파싱하는데, process.argv 배열 전체를 문맥 없이 스캔하다 보니 다른 플래그의 값 안에 숨겨진 --settings= 문자열도 최상위 설정으로 인식했다.
공격 벡터는 claude-cli:// 딥링크였다. 사용자가 악성 링크를 클릭하면 q 파라미터에 삽입된 --settings 페이로드가 CLI로 흘러들어갔고, 에이전트의 SessionStart 훅에 임의의 셸 명령이 등록됐다. 워크스페이스 신뢰 다이얼로그도 딥링크의 repo 파라미터로 우회 가능했다. 버전 2.1.118에서 패치됐지만, 이 사례가 남긴 교훈은 명확하다. AI 도구 자체도 입력 경계를 제대로 설계하지 않으면, 편의 기능이 공격 벡터가 된다. 딥링크처럼 사용자 경험을 위해 만든 기능이 가장 먼저 무기화됐다는 점을 팀 보안 정책에 반드시 반영해야 한다.
무음 실패: AI가 틀려도 아무도 모르는 구조
세 번째 사례는 다르게 충격적이다. 졸업식에서 TTS 시스템이 11명의 졸업생 이름을 건너뛰었다. 오류 메시지도, 멈춤도, 경고음도 없었다. 다음 이름이 밝은 목소리로 이어졌을 뿐이다. 파이프라인은 '성공'으로 기록됐을 것이다. 이 사례를 분석한 개발자는 자신이 운영하는 두 개의 프로덕션 에이전트 파이프라인을 감사한 뒤 같은 구멍을 발견했다. 에이전트가 예상치 못한 방식으로 실패하면—빈 출력, 기형 JSON, 타임아웃—파이프라인은 그냥 다음 항목으로 넘어갔다.
그가 즉시 적용한 세 가지 변경은 단순하지만 본질적이다. 첫째, 빈 출력은 성공이 아닌 에러로 처리하고 해당 항목은 데드레터 큐로 보내 사람이 검토하게 한다. 둘째, 배치 실행은 처리 건수와 스킵 건수를 함께 리포트하며, 합산이 입력 건수와 맞지 않으면 실패로 마킹한다. 셋째, 새 파이프라인의 초기 72시간은 트래픽의 1%만 처리한다. "데모가 잘 됐다"는 이유로 예외는 없다. 특히 그럴수록 더 엄격히 적용한다.
실용 프레임: 위임 경계 설계의 세 축
세 사례를 팀 운용 관점으로 묶으면 위임 경계 설계의 세 축이 나온다.
첫째, 위임 단위를 태스크 수준으로 쪼개라. 목표를 주면 에이전트가 경계를 그린다. 태스크를 주면 내가 경계를 그린다. DB 마이그레이션, 보안 검증 로직, 동시성 코드, 타 팀 API 컨트랙트는 에이전트 출력을 리뷰하더라도 최종 작성은 사람이 한다. 이 영역들은 '틀렸을 때의 비용'이 리뷰 시간보다 크다.
둘째, AI 도구의 입력 경계를 팀 보안 정책에 포함하라. Claude Code RCE 사례는 CLI 초기화 플래그가 공격 벡터가 된 케이스다. AI 코딩 도구를 팀에 도입할 때 도구 자체의 보안 업데이트 주기, 딥링크·웹훅·훅 기능의 허용 범위를 명시적으로 정책화해야 한다.
셋째, 실패 가시성을 아키텍처에 구워 넣어라. 에이전트 파이프라인에서 '조용히 넘어가는 실패'는 버그가 아니라 설계 선택이다. 빈 출력 감지, 스킵 카운트 리포팅, 초기 트래픽 게이팅—이 세 가지는 코드 두 줄짜리 변경이지만, 대부분의 팀이 누군가 직접 피해를 입기 전까지는 추가하지 않는다.
전망: 위임 경계는 한 번 그리는 게 아니다
AI 에이전트의 자율성은 계속 확장된다. 지금 안전한 위임 경계가 6개월 뒤에도 같은 위치에 있을 거라는 보장은 없다. 모델이 더 정확해지면 위임 가능한 영역이 넓어지겠지만, 동시에 에이전트가 접근할 수 있는 시스템의 복잡도도 함께 커진다. 그 말은 무음 실패와 보안 공격면도 함께 커진다는 뜻이다.
지금 팀에서 해야 할 일은 위임 경계를 문서화하는 것이다. '우리 팀은 이 영역은 에이전트에게 위임하고, 이 영역은 사람이 직접 쓴다'는 합의를. 그 합의가 없으면 각자가 각자의 경계를 그리게 되고, 가장 느슨한 경계가 팀 전체의 리스크가 된다. 졸업식 TTS 시스템을 만든 팀도 분명 데모를 했을 것이다. 데모는 성공했을 것이다. 문제는 '데모 이후에 무엇을 잠갔는가'였다.