에이전트는 스스로 멈추지 않는다
"Claude Code가 내 .env 파일을 열어서 설정을 '이해'하더니, 키를 교체하라고 친절하게 제안했습니다. 키를 노출시킨 게 바로 그 에이전트였는데도요."
이 한 줄짜리 사고 보고서가 AI-First 워크플로우의 핵심 모순을 정확하게 찌른다. 에이전트는 허락받은 범위 안에서만 움직이지 않는다. 파일 시스템에 접근할 수 있으면 .env도 읽는다. Cursor, Claude Code, Copilot, 그리고 연결된 MCP 서버까지—권한 경계가 없으면 플레인텍스트로 저장된 시크릿은 전부 에이전트의 컨텍스트가 된다.
문제는 에이전트가 악의적이라서가 아니다. 멈춰야 할 지점을 스스로 알지 못하기 때문이다. 그 경계는 개발자가 설계해야 한다.
Vibe Coding의 원조가 놓친 것
2025년 2월, Andrej Karpathy가 X에 올린 짧은 글 하나가 소프트웨어 업계의 언어를 바꿨다. "바이브 코딩—AI에 완전히 맡기고, 지수적 성장을 껴안고, 코드가 존재한다는 사실조차 잊어버린다." 4.5백만 뷰, 콜린스 딕셔너리 2025년 올해의 단어. 개발자들이 이미 하고 있던 것에 이름이 붙었다.
그런데 Karpathy 본인이 조용히 단서를 달았다. "비크리티컬 프로젝트에나 어울린다." 이 경고는 바이럴의 소음 속에 묻혔다.
dev.to에 게재된 Supervised Vibe Coding: A Manifesto는 그 묻힌 경고를 10개의 원칙으로 형식화한다. 요점은 단순하다. 속도는 AI에게, 판단은 인간에게. 에이전트가 코드를 생성하더라도 개발자는 passive reviewer가 아니라 final decision-maker로 남아야 한다.
'2개월 솔로 빌드'가 증명한 위임의 실제 범위
이론이 아닌 실전에서 그 경계가 어디였는지를 보여주는 사례가 있다. dev.to에 공개된 Traverba 개발기—솔로 개발자가 Claude Code를 에이전트로 써서 2개월 만에 3모델 온디바이스 음성인식 파이프라인을 iOS/Android에 동시 출시한 이야기다.
Claude Code가 잘 처리한 것: Dart↔네이티브 플랫폼 브릿지 보일러플레이트, 117개 로케일 파일 생성, EXIF 회전 버그 같은 플랫폼 특화 디버깅, 두 플랫폼 간 코드 일관성 유지.
개발자가 직접 해야 했던 것: 어떤 모델을 쓸 것인가, 언어별 라우팅 로직, 메모리 관리 전략, Bluetooth 프로토콜 설계, 실기기 실세계 조건 테스트.
"Claude Code는 내 엔지니어링 판단을 대체하지 않았다. 하지만 내 아웃풋을 극적으로 늘렸다. 1주일 걸릴 일이 하루에 됐다. 솔로 개발자에게 그건 출시와 미출시의 차이다."
이 사례가 Supervised Vibe Coding 선언문과 정확히 포개진다. 에이전트에게 위임할 수 있는 것은 반복적이고 검증 가능한 작업이다. 아키텍처 결정, 트레이드오프 판단, 실환경 검증—이건 여전히 개발자의 몫이다.
보안: 위임 경계가 무너지는 지점
위임 범위를 잘 설계해도, 파일 시스템 접근 권한을 정리하지 않으면 에이전트는 설계자의 의도 밖으로 나간다. .env 시크릿 노출 문제가 바로 그 구멍이다.
기존 조언(".env를 커밋하지 마라")은 에이전트 시대에 불충분하다. 두 가지 이유에서:
- 스코프 제한이 없다.
src/를 읽어야 하는 에이전트가AWS_SECRET_ACCESS_KEY도 읽는다. 에디터 수준의 파일 접근은 전부 아니면 전무다. - 옆으로 샌다. 같은 파일이 슬랙 온보딩 메시지에 복붙되고, 화면 공유로 노출되고, 연동된 MCP 서버로 흘러간다.
Klavex 개발자의 사고 보고서가 제안하는 해법은 파일 자체를 없애는 것이다. 런타임에 암호화 볼트에서 해당 프로세스에만 시크릿을 주입하고, 디스크에 플레인텍스트를 남기지 않는다. CI 토큰은 환경별로 스코프를 분리해서 프로덕션 시크릿은 에이전트가 아예 접근할 수 없게 만든다.
Doppler, Infisical 같은 성숙한 플랫폼도 같은 방향의 해법이다. 팀 규모와 요구사항에 따라 선택지는 달라지지만, 핵심 원칙은 동일하다: 에이전트를 신뢰하는 것과 에이전트에게 최소 권한만 주는 것은 다른 문제다.
테크 리드가 설계해야 할 세 가지 경계
세 사례를 종합하면 에이전트 워크플로우에서 팀이 명시적으로 설계해야 할 경계가 세 층위로 정리된다.
첫째, 작업 경계. 에이전트에게 넘길 수 있는 작업과 반드시 사람이 판단해야 하는 작업을 명시한다. 보일러플레이트·로컬라이제이션·플랫폼 브릿지는 넘길 수 있다. 아키텍처 결정·트레이드오프·보안 설계는 넘기지 않는다. Traverba 사례가 이 선을 실전으로 증명했다.
둘째, 검토 경계. Supervised Vibe Coding 선언문의 핵심이다. 한 번에 리뷰 불가능한 크기의 변경은 올리지 않는다. API 존재 여부, deprecated 함수, 환각된 패키지는 머지 전에 직접 확인한다. 에이전트가 제안한 의존성은 전부 직접 감사한다. "코드에는 당신 이름이 붙는다, 모델 이름이 아니라."
셋째, 접근 경계. .env는 디스크에서 지운다. CI 토큰은 환경별로 스코프를 분리한다. 에이전트가 읽어야 하는 것과 읽어선 안 되는 것을 인프라 수준에서 분리한다. 정책이 아닌 구조로 막아야 한다.
탈숙련화: 조용히 진행되는 리스크
Supervised Vibe Coding 선언문이 특히 날카롭게 짚는 대목이 있다. "의도적으로 AI 없이 문제를 풀어라. 함수를 직접 작성해라. 모델 없이 디버깅해라. 이 선언문이 의존하는 판단력은 쓰지 않으면 퇴화한다. Supervised Vibe Coding은 실제로 코딩할 수 있는 감독자를 필요로 한다."
팀 리빌딩을 설계하는 입장에서 이 경고는 무겁게 받아들여야 한다. AI 도구 도입으로 생산성이 오르는 동안, 팀원의 독립적 문제 해결 능력이 조용히 내려가는 리스크는 지표에 잡히지 않는다. 스프린트 속도는 올라가는데 장애 대응 능력은 내려가는 팀—이건 AI 도구의 문제가 아니라 위임 방식의 문제다.
전망: '얼마나 넘기는가'보다 '어디서 멈추는가'
에이전트는 점점 더 많은 것을 할 수 있게 된다. 모델은 강해지고, 컨텍스트 윈도우는 넓어지고, 툴 콜 능력은 정교해진다. 그럴수록 "어디까지 맡길 것인가"라는 질문의 답이 기술 스펙에서 팀의 설계 판단으로 이동한다.
빠른 팀과 신뢰할 수 있는 팀의 차이는 에이전트 활용 여부가 아니다. 위임의 경계를 명시적으로 설계했느냐—작업 경계, 검토 경계, 접근 경계를 팀 전체가 같은 기준으로 운영하느냐—그게 실제 차이를 만든다.
AI는 속도를 준다. 경계 설계는 그 속도를 신뢰할 수 있게 만든다.