AI 에이전트(AI agent)를 활용하며 할 수 있는 가장 비용이 많이 드는 일은 그것을 지켜보는 것입니다. 감사를 하는 것도, 출력을 검토하는 것도 아닙니다. 단계별로, 승인 단계마다, 다음 행동을 하기 전 모든 동작을 의심하며 지켜보는 것입니다. 그럼에도 불구하고 2026년 현재 대부분의 엔지니어링 팀이 AI 에이전트를 배포하는 방식은 정확히 이렇습니다. 에이전트가 세 걸음도 채 떼기 전에 인간이 어깨를 두드려야 할 정도로 아주 짧은 목줄을 채운 채 말이죠.

그 이유를 이해합니다. 모델들은 환각 (hallucination)을 일으킵니다. 이해관계가 걸린 문제는 실재합니다. 새벽 2시에 AI 에이전트가 잘못된 마이그레이션 (migration)을 운영 환경에 배포하도록 방치한 엔지니어링 매니저가 되고 싶은 사람은 아무도 없습니다. 그래서 우리는 에이전트를 확인 대화 상자로 감싸고, 모든 분기점에서 인간의 승인을 요구하며, 우리의 신중한 거버넌스 (governance)를 자축합니다. 하지만 우리가 실제로 구축한 것은, 그것이 대체한 수동 프로세스보다 더 많은 인간의 주의력을 요구하는 자동화 시스템입니다.

더 나은 해답은 실행 단계에서의 더 많은 통제가 아닙니다. 의도 (intent) 단계에서의 더 나은 설계입니다. 의도로 조종하고, 예외로 모니터링하십시오. 에이전트에게 당신이 필요로 하는 결과가 무엇인지, 절대로 해서는 안 될 행동은 무엇인지, 그리고 어떤 결과가 중단할 가치가 있는 결과인지를 명확하게 말해주십시오. 그런 다음 에이전트가 일하게 두십시오. 단계가 아닌 결과를 지켜보십시오.

우리는 대체한 수동 프로세스보다 더 많은 인간의 주의력을 요구하는 자동화 시스템을 구축해 왔습니다. 그것은 거버넌스의 성공이 아닙니다. 그것은 설계의 실패입니다.

우리가 이곳에 도달한 이유
오늘날 대부분의 팀이 사용하고 있는 인간-AI 협업 모델은 주니어 개발자 감독 모델에서 물려받은 것입니다. 당신은 모든 풀 리퀘스트 (Pull Request)를 검토합니다. 모든 배포 (Deployment)를 승인합니다. 모든 스키마 (Schema) 변경을 최종 승인합니다. 그러한 모델이 존재하는 이유는 주니어 개발자들이 배우는 단계에 있고, 그들의 멘탈 모델 (Mental Model)이 불완전하며, 그들의 판단력이 아직 검증되지 않았기 때문입니다. 이를 AI 에이전트 (AI Agent)에 적용하면 동일한 가정을 하게 됩니다. 즉, 에이전트는 감독이 필요한 초보자라는 가정입니다.

하지만 AI 에이전트는 주니어 개발자가 아닙니다. 에이전트는 멘토링을 통해 개선될 코드베이스에 대한 불완전한 멘탈 모델을 가지고 있지 않습니다. 에이전트는 당신이 컨텍스트 (Context), 도구 (Tools), 그리고 지침 (Instructions)을 통해 부여한 바로 그 멘탈 모델을 가지고 있으며, 그 모델을 일관되게, 그리고 어떤 인간 검토자도 따라올 수 없는 속도로 사용할 것입니다. 오늘날 대부분의 AI 에이전트 워크플로 (Workflow)에서 병목 현상 (Bottleneck)이 발생하는 지점은 에이전트가 아니라, 에이전트가 대기해야 하는 인간 승인 대기열입니다.

더 중요한 것은, 실행 단계의 감독 (Action-level oversight)이 잘못된 보안감을 조성한다는 점입니다. 당신이 모든 개별 단계를 승인할 때, 당신은 결과가 올바른지 확인하는 것이 아닙니다. 당신은 단지 30초 동안 검토한 사람에게 각 단계가 합리적으로 보였음을 확인하는 것뿐입니다. 이 둘은 같은 것이 아닙니다. 개별적으로는 합리적인 단계들의 연속이 집합적으로 재앙적인 결과를 초래할 수 있으며, 승인 체계는 그 모든 단계에 대해 승인을 내렸을 것입니다.

의도 조종 (Intent-steering)의 실제 의미
의도로 조종한다는 것은 거버넌스 (Governance)를 전방 배치 (Front-loading)하는 것을 의미합니다. 에이전트가 시작되기 전에, 당신은 세 가지를 정확하게 정의해야 합니다. 첫째, 결과 (Outcome)입니다. 이는 작업 목록이 아니라, 측정 가능한 완료 정의 (Definition of Done)여야 합니다. '인증 모듈을 리팩터링하라'가 아니라, '인증 모듈이 모든 기존 테스트를 통과하고, 새로운 의존성 (Dependency)을 도입하지 않으며, 순환 복잡도 (Cyclomatic Complexity)를 최소 15% 감소시킨다'와 같아야 합니다. 둘째, 제약 사항 (Constraints)입니다. 이는 문맥상 아무리 합리적으로 보일지라도 에이전트가 절대 해서는 안 되는 일들입니다. 마이그레이션 스크립트 (Migration Script) 없는 프로덕션 데이터베이스 스키마 변경 금지 등이 이에 해당합니다.

이미 승인된 ConnectionTwin 레지스트리에 없는 서비스로의 외부 API 호출 금지. 복구 스냅샷 (Recovery Snapshot)을 먼저 생성하지 않은 상태에서의 파일 삭제 금지. 세 번째는 에스컬레이션 임계값 (Escalation Threshold)입니다. 즉, 에이전트가 동작을 멈추고 인간의 개입을 기다려야 하는 구체적인 조건입니다. '불확실할 때'와 같은 모호한 기준은 안 됩니다. 너무 막연하면 에이전트는 결코 멈추지 않을 것입니다. 구체적인 조건이 필요합니다: 테스트 커버리지 (Test Coverage)가 80% 미만으로 떨어지면 중단할 것. 알려진 CVE가 있는 종속성 (Dependency)이 도입되면 중단할 것. 리팩터링 (Refactor)이 12개 이상의 파일을 수정한다면, 진행하기 전에 중단하고 요약할 것.

그 외의 모든 것은 에이전트가 결정할 몫입니다. 리팩터링을 어떻게 구성할지, 어떤 함수를 먼저 다시 작성할지, 어떤 중간 상태 (Intermediate States)를 거칠지 등입니다. 당신은 그러한 결정 과정에는 신경 쓸 필요가 없습니다. 당신이 신경 써야 할 것은 결과입니다. 경로를 승인하려고 애쓰는 것을 멈추고, 목적지를 검사하기 시작하십시오.

경로를 승인하려고 하지 마십시오. 목적지를 검사하십시오.

예외 모니터링 (Exception Monitoring)의 실제 의미
예외 모니터링이란 에이전트가 수행한 작업의 기록 (Transcripts)을 읽는 것이 아닙니다. 당신이 사전에 정의한 기준에 따른 결과값의 대시보드를 지켜보는 것입니다. 테스트 커버리지: 유지되었는가? 보안 표면 (Security Surface): 확장되었는가? 성능 벤치마크 (Performance Benchmarks): 변동이 있었는가? 제약 조건 (Constraints): 위반된 것이 있는가? 이 네 가지가 모두 녹색(Green)이라면, 에이전트의 요약을 검토하고 배포하십시오. 하나라도 적색(Red)이라면, 페이지 알림 (Paged)을 받게 됩니다. 이는 에이전트가 실패했기 때문이 아닙니다. 에이전트는 당신이 지시한 대로, 즉 해당 조건이 충족되었을 때 멈추라는 명령을 정확히 수행한 것입니다. 에이전트는 멈췄습니다. 이제 인간이 결정을 내립니다.

이것이 소프트웨어 엔지니어링에서 이미 잘 설계된 모든 자동화 시스템이 작동하는 방식입니다. CI/CD 파이프라인은 인간에게 각 컴파일 단위 (Compilation Unit)를 승인해 달라고 요청하지 않습니다. 전체 스위트 (Full Suite)를 실행하고 실패 시 알림을 보냅니다. 관찰성 (Observability) 플랫폼은 모든 로그 엔트리 (Log Entry)마다 당신에게 페이지를 보내지 않습니다. 기준 동작 (Baseline Behavior)을 모델링하고 편차 (Deviation)가 발생할 때 알림을 보냅니다. 우리는 명확한 원칙을 가지고 이러한 시스템을 설계했습니다: 프로세스를 신뢰하되, 예외 상황에서 개입하라 (Trust the process, intervene on exception).

우리는 AI 에이전트 (AI agents)에도 동일한 원칙을 적용해야 하지만, 이상하리만큼 이를 주저해 왔습니다.

이러한 주저함은 제 생각에 범주 오류 (category error)에서 비롯됩니다. 우리는 AI 에이전트를 판단력을 검증해야 하는 자율적 의사 결정자 (autonomous decision-makers)로 취급하고 있지, 결과물을 검증해야 하는 충분히 결정론적인 프로세스 실행자 (deterministic-enough process executors)로 취급하지 않고 있습니다. 이러한 관점의 전환이 이루어지면 거버넌스 모델 (governance model)은 완전히 바뀝니다. 당신은 사람을 감독하는 것이 아닙니다. 당신은 시스템을 운영하는 것입니다. 시스템은 관리 (managed)하는 것이 아니라 모니터링 (monitored)하는 것입니다.

진지하게 고려할 만한 반론
이 접근 방식에 대한 실제 반론은 원칙적으로 틀렸다는 것이 아닙니다. 정밀한 의도 (intent)를 정의하는 것이 어렵다는 점입니다. 진정으로 측정 가능한 결과 정의 (outcome definition), 완전한 제약 조건 목록 (constraints list), 그리고 잘 조정된 에스컬레이션 임계값 (escalation threshold)을 작성하는 데는 시간과 전문 지식이 필요합니다. 이는 엔지니어링 매니저 (engineering manager)가 에이전트가 시작되기 전에 성공이 어떤 모습인지, 실패가 어떤 모습인지를—특히 그 차이를 자동화할 수 있을 만큼 구체적으로—알고 있어야 함을 의미합니다. 솔직히 말해서 대부분의 팀은 현재 그러한 노력을 투자하지 않고 있습니다. 그들은 모호한 의도를 밀도 높은 감독 (oversight)으로 보완합니다.

그러한 보완 방식은 현재 대부분의 AI 배포 관행을 고려할 때 합리적입니다. 하지만 이는 확장 가능하지 (scale) 않습니다. AI 에이전트의 가치는 병렬적이고 지속적이며 자율적인 실행에 있습니다. 세 명의 에이전트를 동시에 잘 정의된 결과로 유도하고 대시보드에서 그들의 수렴 (convergence)을 모니터링할 수 있는 팀은, 밀착 감독 하에 한 번에 하나의 에이전트만 실행하는 팀과는 근본적으로 다른 역량을 갖게 됩니다. 정밀한 의도 정의에 대한 투자는 바로 그 역량을 해방시키는 투자입니다.

더 나은 브리프 (briefs)를 작성하십시오. 작업 (tasks)이 아니라 결과 (outcomes)를 정의하십시오. 단계 (steps)가 아니라 제약 조건 (constraints)을 명시하십시오. 패닉에 빠진 후가 아니라, 시작하기 전에 에스컬레이션 임계값을 조정하십시오. 그런 다음 에이전트가 일하게 두고, 중요한 것, 즉 '어떻게 걸어갔는가'가 아니라 '목적지에 도달했는가'를 지켜보십시오.

우리가 실제로 필요로 하는 거버넌스 모델

2026년의 AI 에이전트 거버넌스(Governance) 논의는 두 가지 잘못된 선택지에 의해 지배되고 있습니다. 바로 가드레일(Guardrails)이 없는 완전한 자율성, 그리고 에이전트를 무가치하게 만드는 단계별 인간의 감독입니다. 올바른 모델은 이 둘 중 어느 것도 아닙니다. 그것은 모든 성숙한 공학 분야가 이미 알고 있는 방식입니다. 즉, 결과(Outcome)를 위해 설계하고, 경계 조건(Boundary conditions)을 제한하며, 결과를 모니터링(Monitor)하는 것입니다. 의도로 조종하십시오. 예외로 모니터링하십시오. 당신이 구축한 시스템을 신뢰하고, 신뢰할 수 있을 만큼 충분히 잘 구축하십시오.

만약 당신의 AI 에이전트가 모든 결정 과정에서 인간의 손길을 필요로 한다면, 문제는 에이전트가 아닙니다. 문제는 당신이 에이전트가 실제로 무엇을 하기를 원하는지 아직 결정하지 않았다는 것입니다.