비용 대시보드는 있는데, 에이전트가 지금 뭘 하고 있는지는 모른다. 샌드박스는 돌리는데, 실행 결과가 어디에 남는지 설계하지 않았다. 에이전트가 이상한 짓을 해도 언제 멈춰야 할지 기준이 없다. 이 세 가지가 동시에 없는 팀이라면, 에이전트를 '활용'하는 게 아니라 그냥 '방치'하고 있는 거다.
문제의 핵심: 에이전트는 조용히 틀린다
dev.to에 올라온 한 엔지니어의 사례가 이걸 잘 보여준다. 벤더 리스트 정리 작업을 에이전트에게 맡겼더니, 에러도 없고 출력도 깔끔했다. 그런데 들여다보니 모회사가 같은 두 공급업체를 하나로 합쳐버렸고, 그 결과 하위 지출 집계 전체가 틀어질 뻔했다. 아무것도 경보를 울리지 않았다. 그 엔지니어가 알아챈 건 순전히 '전에 비슷하게 당해봤기 때문'이었다. 이게 에이전트의 실패 패턴이다. 조용하고, 출력이 그럴싸하고, 그래서 더 위험하다.
첫 번째 레이어: 관찰성(Observability) — 에이전트가 뭘 하는지 실시간으로 봐야 한다
Claude Code 대시보드에 실시간 활동 로깅과 보안 점수를 추가한 사례(dev.to)가 좋은 출발점이다. 핵심 아이디어는 단순하다. Claude Code의 훅(hook) 시스템을 활용해 에이전트가 실행하는 모든 액션—파일 읽기, 커맨드 실행, API 호출—을 타임스탬프와 리스크 레이블과 함께 스트리밍으로 기록한다. ~/.claude/settings.json에 PostToolUse 훅 한 줄이면 된다.
더 중요한 건 보안 점수 개념이다. 이 대시보드는 7개 항목을 체크해서 100점 만점으로 환경 안전도를 측정한다. sudo *가 allow 리스트에 있으면 -20점, ~/.ssh/**가 deny에 없으면 -20점, .env 파일 보호가 없으면 -15점 식이다. 점수 자체보다 중요한 건 이 프레임이다. 에이전트에게 '무엇까지 허용되어 있는지'를 수치로 만들어 팀이 함께 볼 수 있게 하는 것. 보이지 않으면 통제할 수 없다.
두 번째 레이어: 샌드박스 — 실행 환경을 워크스페이스로 설계하라
AI 코딩 도구들이 코드를 생성하는 문제는 어느 정도 풀렸다. 아직 안 풀린 문제는 '그 코드를 안전하게 실행하는 것'이다. Jhansi.io가 v0.2에서 바꾼 아키텍처 방향이 이 문제를 정확히 짚는다.
초기 모델의 문제는 명확했다. 코드를 문자열로 보내고, 격리된 컨테이너에서 실행하고, 결과를 반환한다. 동작은 한다. 하지만 멀티파일 프로젝트를 다룰 수 없고, 매번 전체 페이로드를 재전송해야 하고, 변경분만 추적할 수 없다. 실제 팀의 코드베이스는 이런 방식으로 작동하지 않는다.
핵심 전환은 '샌드박스를 컨테이너가 아니라 워크스페이스로 보는 것'이다. 샌드박스마다 디스크에 전용 폴더를 할당하고, 파일은 변경될 때만 업로드하고, 실행은 파일명만 넘긴다. 컨테이너는 실행 후 죽지만 워크스페이스는 살아남는다. 이 구조 위에서 델타 싱크, 의존성 자동 탐지, 실행 감사 추적이 모두 가능해진다. 팀에서 에이전트 실행 환경을 설계할 때 '일회용 컨테이너'로 접근하고 있다면 재검토가 필요하다.
세 번째 레이어: 개입 기준 — 언제 키보드를 빼앗을 것인가
관찰하고, 격리하고, 그다음은? 결국 에이전트가 드리프트하는 순간을 사람이 포착하고 멈춰야 한다. 이 능력은 읽어서 생기지 않는다. 직접 경험해야 생긴다.
실용적인 개입 설계는 에이전트에게 작업을 넘기기 전 단계부터 시작된다. 태스크 범위를 statement of work처럼 명세화하는 것이다. '온보딩 개선'이 아니라 정확히 무엇을 in_scope로 두고, 무엇을 out_of_scope로 두는지를 에이전트가 실행하기 전에 코드로 써놓아야 한다. 앞서 벤더 리스트 사례에서 out_of_scope: merging distinct legal entities를 명시했더라면 그 오류는 발생하지 않았을 것이다.
그 다음은 출력 검증 방식의 재설계다. 에이전트가 한 것만 보지 말고, 하지 않은 것을 봐야 한다. 스킵된 케이스, 처리되지 않은 엣지 케이스. 그리고 검증 자체가 '작업을 다시 하는 것'과 같은 비용이 든다면, 그 태스크 슬라이싱 자체가 잘못된 것이다.
테크 리드가 내일 당장 할 수 있는 것
세 레이어를 한꺼번에 구축하려면 시간이 걸린다. 하지만 우선순위는 명확하다.
첫째, 관찰부터 시작하라. Claude Code를 쓰고 있다면 훅 설정 하나로 액티비티 로그를 켤 수 있다. 팀이 에이전트에게 무엇을 허용하고 있는지를 먼저 눈으로 봐야 논의가 시작된다. 둘째, 에이전트 실행 환경을 일회용으로 쓰고 있다면 워크스페이스 개념으로 전환을 검토하라. 감사 추적 없는 실행은 언제든 문제가 됐을 때 원인을 알 수 없다. 셋째, 팀원 한 명이라도 에이전트에게 실제 태스크를 맡기고 '개입 반사'를 직접 경험하게 하라. PMP가 AI 역량을 필수 항목으로 넣었다는 건 이 능력이 이제 전문 역량으로 인정된다는 신호다. 하지만 그 능력은 시험으로 증명되지 않는다.
전망: 통제 구조 없는 에이전트 도입은 기술 부채가 된다
AI 에이전트 도입 속도는 빠르다. 하지만 로깅도, 격리도, 개입 기준도 없이 에이전트를 팀에 풀어버리면, 그건 자동화가 아니라 비가시적 리스크를 쌓는 것이다. 조용히 틀리는 에이전트를 아무도 모르게 운영하다가 문제가 터졌을 때 원인을 찾을 수 없는 상황—이게 AI-First 팀이 가장 경계해야 할 시나리오다.
관찰성(observability), 격리된 실행 환경, 개입 기준 설계. 이 세 가지는 에이전트를 '쓰는 것'이 아니라 '안전하게 쓸 수 있는 구조'의 최소 요건이다. 도구를 켜기 전에 이 구조부터 먼저 그려야 한다.