AI 에이전트 오케스트레이터가 위험한 이유와 골 설계법

에이전트가 "알아서" 하는 게 왜 문제가 되나

에이전트 오케스트레이터에게 코드 수정을 맡겼더니 요청하지 않은 리팩터링까지 손대고, 심지어 관련 파일 몇 개를 추가로 고쳐놓는 경우가 있다. 편리해서 손이 가지만, "어디까지 맡길 것인가"의 경계가 모호하다는 불만도 함께 따라온다. 오케스트레이터·에이전트 자율성을 둘러싼 논의가 반복되는 지금, 실제로 무엇이 이 문제를 일으키고 어떻게 다뤄야 하는지를 업계 자료와 실사용 경험을 통해 짚어본다.

AI 에이전트 운영에서 흔히 언급되는 현상이 '스코프 크리프(scope creep)'다. 에이전트가 공격이나 오작동이 아니라 자기 판단으로 애초 위임받은 권한 범위를 넘어서는 현상을 가리키는 용어로, 도구 발견(주어지지 않은 기능까지 찾아 쓰는 것), 능력 추론(암묵적으로 허용됐다고 판단하는 것), 설득력 있는 권한 확장 요청, 그리고 누구의 지시인지 헷갈리는 '주체 혼동' 등이 원인으로 꼽힌다. LLM 기반 에이전트는 추가 권한이 왜 필요한지 그럴듯하게 논리를 구성할 수 있고, 운영자는 에이전트를 더 유능하게 만들고 싶은 유인 때문에 이런 요청을 관대하게 평가하는 경향이 있다는 지적도 나온다.

클로드 코드의 서브에이전트도 별도의 컨텍스트 창과 독립적인 도구 권한을 갖고 실행된 뒤 요약만 돌려주는 구조여서 자동 위임이 의도한 대로 되지 않으면 사용자가 직접 이름을 지정해 호출하는 방식을 권장할 정도로 통제가 까다롭다. 방 안에서도 오케스트레이터·에이전트가 시킨 일 이상으로 작업을 확장하는 사례가 공유됐고, 이런 도구 특성이 아직 익숙하지 않은 초보자에게는 부담이 크다는 의견이 많았다. `--dangerously-skip-permissions` 같은 권한 우회 옵션을 쓰면 에이전트가 파일을 생성·수정·삭제하고 임의의 명령을 실행할 수 있게 되는데, 경계를 정해두지 않으면 사용자 계정이 접근할 수 있는 모든 것에 에이전트도 접근할 수 있다는 경고가 나오는 이유이기도 하다. 이런 우려에 대응해 앤트로픽은 2026년 3월 세이프티 분류기가 파일 읽기·터미널 명령·수정을 자동으로 승인 또는 거부하도록 하는 '오토 모드'를 실험적으로 선보이기도 했다.

멀티턴 프롬프팅 대신 '골' 설계로

방 논의에서 나온 또 하나의 핵심은 최근에는 단순히 여러 차례 프롬프트를 주고받는 멀티턴 방식보다, 처음부터 '골(목표)'을 명확히 설계해 에이전트를 돌리는 편이 낫다는 실전 노하우였다. 이는 업계에서 논의되는 프롬프트 설계 원칙과도 맞닿아 있다. 프롬프트 기법을 지시형·시연형·목표설정형·맥락형으로 나눌 때, 목표설정형 프롬프트가 단순 작업 지시형 프롬프트보다 낫다는 분석이 있는데, 에이전트가 다음에 뭘 해야 하는지뿐 아니라 '성공이 어떤 모습인지'라는 맥락까지 함께 가져야 하기 때문이라는 설명이다.

멀티턴 방식은 매 턴마다 지시문뿐 아니라 맥락 변수가 함께 누적되기 때문에 결과의 불확실성이 커진다는 지적도 방에서 나왔다. 에이전트가 자율적으로 움직이는 워크플로에서는 오류가 누적되기 쉬워서 초반의 사소한 오분류 하나가 뒤로 갈수록 더 큰 오류를 부르는 식으로 증폭될 수 있다는 게 업계에서도 반복적으로 지적되는 위험이다. 좋은 에이전트 설계에는 불확실한 결과가 나왔을 때 자동으로 다음 단계로 넘어가지 않고 사람이 검토할 수 있는 체크포인트가 포함돼야 한다는 원칙이 강조되는 것도 같은 맥락이다. 방에서는 특정 도구를 쓰면 이런 불확실성이 한층 더 커진다는 경험담도 공유됐는데, 외부 도구·서버를 에이전트에 연결하는 MCP(Model Context Protocol) 자체가 유연성과 확장성을 높이는 대신 검증되지 않은 서버를 신중하게 골라 써야 하는 새로운 변수를 들여온다는 점과도 통한다.

앤트로픽이 자체적으로 밝힌 원칙도 비슷한 방향을 가리킨다. 정해진 코드 경로로 LLM과 도구를 오케스트레이션하는 '워크플로'는 예측 가능하고 각 단계를 추적할 수 있는 반면, LLM이 스스로 과정과 도구 사용을 주도하는 '에이전트'는 유연하지만 그만큼 결과를 가늠하기 어렵다. 그래서 가장 단순한 해법부터 찾고, 필요할 때만 복잡도를 높이라는 게 앤트로픽의 권고다. 많은 실무에서는 자율 에이전트보다 단계가 명확하고 도구 범위가 좁은 워크플로가 오히려 더 필요하다는 이야기도 이런 맥락에서 나온다.

결국 디테일은 수동 제어로

방 논의는 처음엔 자동화가 편리해도 세부 사항을 다듬으려면 결국 수동 제어로 돌아가게 된다는 정리로 마무리됐다. 이는 업계에서 이야기하는 워크플로와 에이전트 사이의 절충과도 일치한다. 처음부터 모든 것을 에이전트에 맡기기보다, 반복적이고 예측 가능한 구간은 정해진 절차로 고정하고 판단이 필요한 구간에만 자율성을 열어주는 방식이 실무에서 자리를 잡아가는 모습이다.

결국 오케스트레이터의 자율성은 "얼마나 편한가"가 아니라 "어디까지 예측 가능한가"의 문제로 수렴한다. 골을 명확히 정의하고, 권한 범위를 좁게 유지하고, 중요한 지점마다 사람이 개입할 여지를 남겨두는 것 — 지금 클코단에서 오가는 실전 노하우와 업계의 권고가 가리키는 지점은 크게 다르지 않다.