에이전트가 rm -rf /를 실행했다. 파일 목록을 보여달라고 했을 뿐인데. 이건 가상의 시나리오가 아니다. LangChain 기반 에이전트를 실제로 운용해본 개발자라면 누구나 비슷한 아찔한 순간을 경험했거나, 아직 경험하지 않았을 뿐이다. 에이전트를 프로덕션에 올리는 팀이 늘어날수록, 이 문제는 '만약'이 아니라 '언제'의 문제가 된다.
지금 현장에서 내가 보는 가장 흔한 실수는, 에이전트의 품질을 프롬프트 수준에서 통제하려는 시도다. "위험한 명령은 실행하지 마세요"라고 시스템 프롬프트에 써넣는 것. 이건 작동하지 않는다. 에이전트는 확률적으로 움직이고, 프롬프트는 가이드라인일 뿐 강제 장치가 아니다. 프롬프트 엔지니어링은 에이전트 안전의 10%다. 나머지 90%는 인프라가 책임져야 한다.
1층: 런타임 게이트 — 에이전트와 도구 사이에 결정론적 차단벽을 세워라
dev.to에 공개된 ShadowAudit 사례는 이 문제를 정면으로 다룬다. 핵심 아이디어는 단순하다. 에이전트가 도구를 호출하기 직전, 모든 요청을 리스크 분류 체계(taxonomy)와 대조해 점수를 매기고, 임계값을 초과하면 실행을 차단한다. LLM을 통한 판단이 아니라 키워드 기반 스코어링과 유한 상태 머신(FSM)을 쓴다. 같은 입력에 항상 같은 결과가 나온다. 이게 핵심이다.
왜 결정론적이어야 하는가? LLM 기반 가드레일은 느리고, 비싸고, 재현 불가능하다. 같은 명령어를 두 번 넣으면 다른 판단이 나올 수 있다. 컴플라이언스 감사를 받아야 하는 금융·의료·법무 환경에서는 이게 치명적이다. ShadowAudit이 SQLite 기반 오프라인 설계를 택한 이유도 여기 있다. 에어갭 VPC 안에서 운용되는 에이전트, HIPAA 환경, 외부 네트워크 연결이 불가한 클라우드 테넌트—이런 환경에서는 클라우드 의존 거버넌스 도구 자체가 사용 불가다.
팀 리드 관점에서 실질적으로 중요한 건 CI/CD 통합이다. shadowaudit check ./src --fail-on-ungated 한 줄을 파이프라인에 넣으면, 게이트 없는 셸 도구를 커밋한 순간 빌드가 터진다. 에이전트 코드가 리뷰를 통과하고 프로덕션에 나가기 전에 인프라 수준에서 걸러진다. 이건 코드 리뷰 자동화가 아니라, 배포 게이트 자동화다.
2층: 환경 인프라 — 프롬프트가 아니라 에이전트가 뛰는 바닥을 고쳐라
20개 에이전트가 동시에 같은 파일을 읽고 쓴다고 상상해보자. 에이전트 A가 파일을 읽는 순간, 에이전트 B가 덮어쓴다. A의 컨텍스트는 이미 낡은 데이터를 가리키고 있다. 크론 잡으로 돌아가는 에이전트는 새벽 3시에 Touch ID로 잠긴 패스워드 매니저를 열 수 없다. 에이전트가 반복 실패해도 3일 동안 아무도 모른다. 컨텍스트 윈도우는 2,500개 파일 목록으로 가득 차서 실제 문제를 추론할 공간이 없다.
이 중 어느 것도 프롬프트 문제가 아니다. 인프라 문제다. dev.to에서 소개된 멀티에이전트 인프라 설계 사례는 네 가지 도구로 이를 해결한다. WAL 모드 SQLite 기반의 구조화된 팩트 스토어(FactBase)로 동시 쓰기 충돌을 막고, 크리덴셜 프록시 데몬으로 비대화형 인증을 처리하며, 연속 실패 감지 워치독(Cron Guard)으로 사일런트 실패를 잡고, 컨텍스트 패킹으로 토큰 예산 안에 실제로 필요한 정보를 욱여넣는다.
이 설계의 핵심 메시지는 하나다. 에이전트의 실행 환경을 구조화하지 않으면, 프롬프트를 아무리 정교하게 다듬어도 에이전트는 엉뚱한 방향으로 달린다. 팀 리드가 AI 에이전트 도입 초기에 환경 인프라 설계에 투자해야 하는 이유가 바로 이것이다.
3층: repo-local 상태 추적 — 에이전트의 기억을 코드베이스 안에 둬라
에이전트가 작업 중간에 멈추면 어떻게 되는가? 어디서 멈췄는지, 무엇이 블록됐는지, 다음에 뭘 해야 하는지를 에이전트 스스로 알 수 있어야 한다. 그 상태가 외부 대시보드나 호스팅 서비스에 있다면, 에이전트는 작업 문맥을 복구하기 위해 매번 컨텍스트 전환 비용을 치른다. 한 번은 작은 마찰이지만, 매일 수십 번 반복되면 실질적인 병목이 된다.
tli는 이 문제에 대한 작고 실용적인 답이다. 태스크 상태를 .tli/ 디렉토리에 파일 기반으로 저장한다. 에이전트는 tli ready, tli next, tli --json state로 지금 당장 무엇을 해야 하는지 쿼리할 수 있다. 외부 시스템 없이, 레이턴시 없이, 로컬에서 바로. 인간이 터미널에서 확인하는 방식과 에이전트가 자동화로 읽는 방식이 동일한 스토어를 공유한다. 핸드오프가 깔끔하다.
이 설계 원칙—상태를 코드와 가까운 곳에 유지한다—은 에이전트 워크플로우 전반에 적용되는 원칙이기도 하다. 에이전트의 컨텍스트, 의사결정 로그, 태스크 상태가 외부 플랫폼에 분산될수록, 팀 리드가 에이전트의 행동을 감사하고 재현하는 비용은 높아진다. 로컬 퍼스트 설계는 단순히 오프라인 지원의 문제가 아니라 감사 가능성(auditability) 의 문제다.
세 통제선이 맞물릴 때
정리하면 이렇다. 런타임 게이트는 에이전트가 실행해선 안 될 것을 막는다. 환경 인프라는 에이전트가 제대로 실행될 수 있는 바닥을 만든다. repo-local 상태 추적은 에이전트가 어디서 멈추든 다시 시작할 수 있는 기억을 제공한다. 이 세 층위 중 하나라도 빠지면, 에이전트는 빠르지만 위험하거나, 안전하지만 맹목적이거나, 열심히 하지만 기억이 없다.
에이전트를 프로덕션에 올리는 결정은 팀 리드의 몫이다. 하지만 그 이전에 설계해야 할 것도 팀 리드의 몫이다. 에이전트가 배포된 뒤에 인프라 통제선을 그리려 하면 이미 늦다. 다음 에이전트 배포 전에 세 가지를 먼저 물어라. 런타임 게이트가 있는가? 에이전트가 실행되는 환경이 구조화되어 있는가? 에이전트의 상태가 감사 가능한 형태로 저장되는가. 셋 다 '예스'일 때, 에이전트는 팀의 일원이 될 수 있다.