경계가 무너지고 있다
Vibe coding과 agentic engineering은 원래 명확히 달랐다. 전자는 코드를 거의 보지 않고 결과만 받아들이는 방식, 후자는 보안·유지보수성·성능 제약을 이해한 엔지니어가 AI를 최대한 활용하는 방식이다. Simon Willison은 이 둘을 엄격히 구분해왔는데, 최근 그 구분이 흔들리고 있다고 고백한다. Claude Code가 JSON API 엔드포인트, SQL 쿼리, 테스트, 문서화를 반복적으로 잘 처리하면서 생성된 코드를 전부 검토하지 않는 일이 자연스럽게 생겨버린 것이다.
문제는 이게 팀 단위로 확산될 때다. 나 혼자 코드 리뷰를 생략하는 건 내 책임이다. 하지만 팀 전체가 에이전트 결과물을 블랙박스처럼 신뢰하기 시작하면, 책임 소재가 불분명해진다. 사람 팀은 전문적 평판과 책임 압박이 있다. Claude Code에는 없다. '일탈의 정상화'가 조용히 진행된다—모델이 감시 없이 올바른 코드를 작성할 때마다 신뢰가 쌓이고, 나중에 잘못된 순간에 과신해 피해를 볼 위험도 함께 커진다.
속도가 10배 늘면, 병목은 다른 곳으로 간다
하루 코드 200줄을 만들던 팀이 2,000줄을 만들 수 있게 되면 무엇이 깨지는가. 코드 작성 자체가 더 이상 병목이 아니다. 설계, 검증, 운영, 실제 사용이 새 병목이 된다. 이건 좋은 소식이기도 하고 위험 신호이기도 하다. 기존 소프트웨어 개발 생애주기는 하루 몇백 줄 속도를 전제로 설계됐다. 코드 리뷰 프로세스, 스프린트 단위, QA 주기—모두 그 속도를 기준으로 짜여 있다. AI가 생산 속도를 10배 높이면 이 구조 전체가 흔들린다.
더 구체적으로: 커밋 100개, 아름다운 README, 전체 테스트가 있는 저장소를 이제 30분 만에 만들 수 있다. 겉모습만으로 품질을 판단하는 기존 코드 리뷰 기준이 무력해진다. Willison이 제시하는 실질적 품질 기준은 단 하나—누군가가 그 소프트웨어를 실제로 꾸준히 사용했는가다. Vibe coded 결과물이라도 만든 사람이 2주 동안 매일 썼다면, 한 번도 실행해보지 않고 뱉어낸 테스트 100% 커버리지 코드보다 훨씬 가치 있다.
터미널이 새로운 통제 레이어가 되는 이유
에이전트 워크플로우를 통제하려면 환경 설계가 먼저다. Dev.to의 한 엔지니어가 공유한 터미널 중심 개발환경 설계가 이 맥락에서 흥미롭다. VS Code 중심에서 벗어나 Ghostty + Zellij + Claude Code CLI + Vim + Lazygit 조합으로 이동한 이유가 단순한 도구 취향이 아니다—태스크 단위로 컨텍스트를 격리하고, 에이전트를 독립 환경 안에 두기 위해서다.
핵심 설계 원칙은 이렇다: 각 태스크 = 별도 Zellij 세션, 각 세션 = 고유한 컨텍스트, 에이전트는 별도 창이 아닌 작업 환경의 일부. Claude Code CLI가 파일·Git·로그·아티팩트와 같은 공간에 위치한다. 이 구조의 의미는 단순하다—에이전트가 어느 컨텍스트에서 무엇을 보고 있는지 리드가 명확히 통제할 수 있다. IDE에서 수십 개 탭이 열린 채 에이전트 권한 범위가 불분명한 상태와 근본적으로 다르다.
토큰 비용 최적화: 통제선의 경제학
에이전트 워크플로우 통제는 품질만의 문제가 아니다. 비용 문제이기도 하다. Claude Code의 기본 동작은 쿼리에 답하기 위해 파일 전체를 컨텍스트로 읽어들이는 것이다. 수백 개 파일을 가진 코드베이스에서 cross-cutting 검색 한 번에 수만 토큰이 소모된다. 대규모 문서는 더 심각하다—SEC 10-K 파일 하나가 80,000토큰을 넘어 컨텍스트 블로우아웃을 일으킨다.
Dev.to에서 공개된 실전 사례에 따르면, Semble(시맨틱 코드 검색 MCP)과 SEC 파일링 MCP를 .mcp.json으로 Claude Code에 연결하면 토큰 사용량을 최대 98% 줄일 수 있다. 작동 방식은 간단하다: Claude가 read_file 대신 search_code나 get_filing_section을 호출하도록 검색 레이어를 MCP로 끼워 넣는다. 파일 전체가 아닌 관련 청크만 컨텍스트로 들어온다. 팀 전체가 Claude Code를 쓴다면 이 차이가 월 단위 비용에서 유의미하게 잡힌다.
팀 리드가 설계해야 할 3가지 통제선
이 모든 맥락을 종합하면, AI-First 팀 리드의 역할은 에이전트를 잘 쓰는 것이 아니라 에이전트가 팀 안에서 어떻게 작동할지 구조를 설계하는 것이다. 구체적으로 세 가지 통제선이 필요하다.
첫째, 컨텍스트 격리 구조. 태스크 단위로 에이전트 세션을 분리하고, 에이전트가 접근할 수 있는 파일·권한 범위를 명시적으로 정의한다. 터미널 기반 워크플로우가 하나의 방법이고, IDE 환경이라면 workspace 설정으로 격리 범위를 잡아야 한다.
둘째, 품질 관문 재설계. 코드 생산 속도가 10배 빨라졌다면 기존 리뷰 프로세스는 이미 병목이 됐거나 형식화됐다. 전체 코드 라인 리뷰 대신 아키텍처 결정 지점, 보안 경계, 외부 의존성 변경—이 세 레이어에 집중하는 '선택적 심층 리뷰' 체계가 현실적이다. Hacker News 댓글에서 한 엔지니어가 지적했듯, 에이전트 코딩 이전에도 프로세스 없이 만들려 할 때 팀이 곤란해졌다. 지금은 그 문제가 AI 속도로 증폭될 뿐이다.
셋째, 비용·컨텍스트 관리 레이어. MCP를 활용한 검색 레이어 구성은 단순한 비용 절감이 아니다. 에이전트가 얼마나 많은 정보를 한 번에 보는지를 리드가 설계할 수 있다는 의미다. 컨텍스트 크기를 통제하면 에이전트 동작의 예측 가능성도 높아진다.
지금 당장 해야 할 것
AI 도구는 기존 엔지니어의 경험을 대체하지 않고 증폭한다. 무엇을 하고 있는지 아는 사람이 AI 도구와 함께 훨씬 빠르게 움직인다—반대로, 기준 없이 움직이는 팀은 AI 속도로 기술부채를 쌓는다. 배관 YouTube 영상을 충분히 보면 직접 배관을 고칠 수 있지만 배관공을 고용하는 이유가 있듯, 에이전트가 코드를 잘 짜도 그 코드가 실제로 작동하고 유지보수 가능한지 검증하는 구조는 여전히 사람이 설계해야 한다.
내일 당장 팀 리드로서 할 수 있는 것: Claude Code를 쓰는 팀원들에게 에이전트 세션 로그를 공유하게 하고, 어떤 파일에 어떤 범위로 에이전트가 접근했는지 가시화하라. 그 로그가 없다면—통제선이 없는 것이다.