AI 에이전트가 데이터베이스를 지우는 문제는 모델이 멍청해서 생기지 않는다. 데이터베이스를 지울 수 있게 만든 하네스와, 지우기 전에 확인할 것을 요구하지 않은 운영 방식에서 시작된다.

최근 팀에서 개발 중인 프로젝트의 데이터베이스를 지워버린 일이 있었다. 운영 환경에서 10분짜리 쿼리를 만든 일도 있었다. 둘 다 당사자는 일을 끝내려 했을 것이다. 문제는 실행 전 단계에 없었다. 어떤 명령을 돌리는지, 얼마나 오래 걸리는지, 어떤 데이터를 건드리는지, 되돌릴 방법이 있는지를 확인하게 만드는 장치가 없었다.

AI 에이전트를 쓰기 시작하면서 이 문제는 더 빨라진다. 사람은 위험한 명령 앞에서 잠깐 멈추기도 한다. 반면 에이전트는 주어진 목표를 가장 짧은 경로로 끝내려 한다. "정리해줘"와 "삭제해줘"의 경계가 시스템에 명시되어 있지 않다면, 에이전트에게는 둘 다 수행해야 할 작업일 수 있다.

그래서 에이전트에게 일을 맡기기 전에 먼저 설계해야 할 것은 모델이나 프롬프트가 아니다. 어디까지는 제안이고, 어디부터는 승인이 필요한 실행인지다.

실행 권한을 막는 것만으로는 부족하다#

처음에는 위험한 명령을 막으면 충분하다고 생각하기 쉽다. DROP, DELETE, TRUNCATE, 프로덕션 배포 같은 명령을 하네스에서 차단하는 방식이다. 이것은 반드시 필요하다. 데이터 삭제처럼 되돌리기 어렵고 영향 범위가 큰 작업을 모델의 판단에 맡길 이유는 없다.

다만 이것만으로는 부족하다.

운영에서 오래 걸리는 쿼리가 좋은 예다. 쿼리 문법은 정상일 수 있다. 데이터를 지우지도 않는다. 하지만 실행계획을 보지 않고, 대상 범위를 확인하지 않고, 트래픽이 있는 시간에 돌리면 서비스에 영향을 줄 수 있다. 위험은 명령어 이름에만 있지 않다. 어떤 데이터에, 어떤 규모로, 어떤 환경에서 실행하느냐에 있다.

레거시 코드도 마찬가지다. 에이전트는 현재 저장소에서 가장 가까운 예시를 따라 한다. 그런데 가까이에 있는 코드가 오래된 예외 처리, 직접 SQL 실행, 무분별한 전역 상태, 이미 피해야 할 패턴이라면 그럴듯하게 복제한다. 코드를 읽고 기존 패턴을 따라 한 것이므로, 에이전트 입장에서는 합리적인 행동이다.

그러니 하네스가 해야 할 일은 위험 명령을 막는 데서 끝나지 않는다. 따라야 할 기준을 먼저 주고, 기준 밖의 실행은 멈추게 만드는 일까지 포함해야 한다.

에이전트는 실행자가 아니라 변경 제안자여야 한다#

내가 원하는 에이전트는 "완료했습니다"라고 말하는 에이전트가 아니다. 변경을 제안하고, 사람이 판단할 수 있게 필요한 근거를 정리하는 에이전트다.

변경을 실행하기 전에 최소한 아래 내용은 보여줘야 한다.

  1. 이유 — 왜 지금 이 변경이 필요한가.
  2. 정확한 실행 내용 — 어떤 명령, 어떤 파일, 어떤 쿼리, 어떤 환경에서 실행하는가.
  3. 영향 범위 — 데이터, 사용자, 성능, 다른 서비스, 배포 흐름 중 무엇이 달라지는가.
  4. 위험성 — 실패했을 때 무엇이 깨지고, 되돌릴 수 있는가.
  5. 기존 동작과의 차이 — 지금까지의 사용자 경험과 시스템 동작에서 무엇이 바뀌는가.
  6. 공유 대상 — 이 변경을 알고 있거나 승인해야 하는 팀원은 누구인가.

이건 결재를 위한 문서 작업이 아니다. 에이전트가 자신이 모르는 맥락을 드러내는 방식이다. 이 정보가 없으면 사람도 승인할 수 없고, 에이전트가 놓친 조건도 발견하기 어렵다.

좋은 승인 지점은 사람을 매번 붙잡아 두는 장치가 아니다. 사람이 봐야 할 순간만 선명하게 만든다. 파일을 읽고, 테스트를 돌리고, 초안을 쓰고, 로컬에서 실행하는 일은 빠르게 자동화할 수 있다. 하지만 프로덕션 데이터 변경, 외부 사용자에게 영향을 주는 메시지 발송, 배포, 권한 변경처럼 되돌리기 어렵거나 영향이 넓은 일은 멈춰야 한다.

하네스는 세 층으로 작동해야 한다#

첫 번째는 기본 차단이다. 데이터베이스 삭제, 대량 삭제, 운영 자격 증명 변경, 직접 배포처럼 위험이 명확한 작업은 애초에 실행 권한을 주지 않는다. "조심해서 하라"는 프롬프트보다 하네스의 차단 규칙이 강하다.

두 번째는 실행 전 검증이다. 쿼리라면 실행계획과 대상 범위, 예상 실행 시간, 인덱스 사용 여부를 확인한다. 코드 변경이라면 테스트 결과와 변경 diff, 영향을 받는 경로를 남긴다. 에이전트가 결과를 말하는 대신, 결과를 믿을 수 있는 근거를 제출하게 하는 단계다.

세 번째는 따라야 할 기준의 명시다. 레거시가 아니라 현재의 설계 원칙, 허용된 라이브러리, 안전한 코드 예시, 금지 패턴, 테스트 기준을 에이전트가 먼저 읽게 해야 한다. 에이전트는 빈 저장소에서 일하지 않는다. 주변 맥락을 학습한다. 그러므로 어떤 맥락을 앞에 두는지가 결과를 결정한다.

이 세 층은 서로 대체되지 않는다. 차단 규칙만 있으면 문법적으로 안전하지만 운영상 위험한 실행을 놓친다. 검증만 있으면 위험한 행동을 시도하는 비용이 남는다. 기준만 있으면 마지막 실행 권한이 열려 있는 문제가 남는다.

자동화율보다 중요한 것은 멈춤의 품질이다#

최근 읽은 사례들도 같은 방향을 가리킨다.

라인은 AI로 E2E 회귀 테스트를 생성하면서, 테스트가 통과했지만 원래 의도와 다른 대상을 검증하는 문제를 만났다. 해결책은 더 많은 코드 생성이 아니라 locator 검증, 기대 결과 점검, 사람 리뷰를 포함한 파이프라인이었다. 자동화의 목표는 사람을 없애는 것이 아니라 사람이 봐야 할 곳을 줄이고 분명하게 만드는 것이었다.1

로앤컴퍼니의 VOC 조사 에이전트도 조사·초안·문서화는 AI가 맡고, 검증·담당자 지정·코드 수정은 사람이 맡도록 역할을 나눴다.2 모두의주차장은 음성 에이전트를 만들면서도 결제는 사용자가 버튼으로 확인한 뒤에만 실행하게 했다.3

이 사례들의 공통점은 AI를 덜 믿어서가 아니다. 오히려 AI를 실제 업무 흐름에 넣기 위해, 믿어도 되는 일과 반드시 확인해야 하는 일을 구분했다는 데 있다.

에이전트를 도입하는 팀이 물어야 할 질문은 "어디까지 자동화할 수 있나"가 아니다.

이 실행은 누가 승인해야 하는가. 승인하려면 무엇을 봐야 하는가. 그리고 그 정보는 실행 전에 자동으로 준비되는가.

이 세 질문에 답할 수 있어야 에이전트는 속도를 내도 팀을 불안하게 만들지 않는다.

마치며#

AI 에이전트는 개발자를 대체하는 실행자가 아니라, 더 나은 판단을 위한 준비를 빠르게 만드는 동료에 가깝다. 좋은 에이전트는 많은 권한을 받은 에이전트가 아니다. 위험한 곳에서 스스로 멈추고, 사람이 판단할 근거를 빠뜨리지 않고, 이미 낡은 관행 대신 팀이 정한 기준을 따라가는 에이전트다.

신뢰는 한 번의 멋진 데모에서 생기지 않는다. 내가 직접 했을 때와 비슷한 결과를 반복해서 내고, 내가 놓친 위험을 먼저 찾아내고, 중요한 실행 앞에서는 정확한 제안을 남기고 기다릴 때 쌓인다.

그래서 에이전트의 자율성을 키우기 전에, 먼저 승인 지점을 설계해야 한다.

참고#

  1. AI로 E2E 회귀 테스트 자동화하기: ‘딸깍’을 파이프라인으로 바꾸기까지, LY Corporation Tech Blog. ↩
  2. AWS X 로앤컴퍼니 AI 해커톤 : VOC 자동 조사 에이전트 “민붕이” 개발기, AWS 기술 블로그. ↩
  3. 모두의주차장 AI 음성 주차 개발기: AWS AI-DLC 워크숍에서 출시까지, AWS 기술 블로그. ↩