에이전트를 통제하는 두 개의 손 — 무엇을 코드로 막고 무엇을 LLM에게 맡길까

집에 작은 AI 서버를 한 대 두고 코딩 에이전트(스스로 파일을 읽고 명령을 실행하는 LLM 기반 도구)를 종일 돌리다 보면, 가장 먼저 부딪히는 질문은 성능도 비용도 아니다. "이 녀석을 어떻게 믿고 키보드를 맡기지?"다.

에이전트는 똑똑하지만 변덕스럽다. 같은 상황에서 어제는 멀쩡히 테스트를 돌리고, 오늘은 rm -rf 한 줄을 천연덕스럽게 실행하려 든다. 그래서 우리는 가드레일(guardrail, 에이전트가 넘으면 안 되는 선을 강제하는 안전장치)을 친다. 그런데 가드레일을 설계하다 보면 더 근본적인 갈림길이 나온다.

바로 "이 규칙을 결정론적 코드로 막을 것인가, 아니면 LLM의 판단에 맡길 것인가"다. 이 글은 그 분담선을 어디에 긋는지에 대한 이야기다.

왜 한쪽만으로는 안 되는가

먼저 직관에 반하는 사실 하나. 똑똑한 LLM이 있는데도, 통제의 상당 부분을 "멍청한" 정규식과 린터에 맡기는 게 더 안전하다. 반대로, 코드로 다 막으려 들면 멀쩡한 작업까지 막혀 에이전트가 무력해진다.

이유는 두 접근이 정반대의 약점을 갖기 때문이다.

다이어그램 설명. 위 그림은 통제를 한쪽 극단에 몰았을 때 각각 어떤 함정에 빠지는지를 보여준다. 모든 판단을 LLM에게 맡기는 왼쪽 경로는 유연하지만, 같은 입력에도 매번 다른 결정을 내릴 수 있고(비결정성) "이건 안전한 명령이야"라고 프롬프트로 설득하면 뚫린다. 모든 판단을 코드로 굳히는 오른쪽 경로는 확실하지만, 규칙이 거칠어 정상 작업까지 차단하고 맥락을 읽지 못해 헛다리를 짚는다. 핵심은 두 약점이 대칭이라는 점이다 — 한쪽의 강점이 다른 쪽의 약점이라, 둘을 적재적소에 섞어야 비로소 빈틈이 메워진다. 흔한 오해는 "LLM이 더 똑똑하니 LLM에 몰면 된다"는 것인데, 똑똑함과 신뢰성은 별개다. 위험 차단처럼 절대 뚫리면 안 되는 자리에 필요한 건 똑똑함이 아니라 우회 불가능성이다.

분담의 기준 — 규칙이 정형화되는가

그렇다면 어떤 일을 어느 손에 맡길지 어떻게 정하는가. 판단 기준은 의외로 단순하다. "이 규칙을 사람이 미리 글로 또박또박 적을 수 있는가?"

적을 수 있으면 — 즉 규칙이 정형화(formalizable, 모호함 없이 명시적 조건으로 표현 가능)되면 — 결정론 게이트(deterministic gate, 정해진 규칙으로 통과/차단을 기계적으로 판정하는 관문)에 맡긴다. 위험 명령 패턴, 린트 규칙, 타입 에러처럼 "맞다/틀리다"가 코드로 떨어지는 것들이다.

적을 수 없으면 — 그때그때 맥락을 읽어야 판단이 서면 — LLM 판단에 맡긴다. 코드 리뷰에서 "이 변수명이 적절한가", "이 추상화가 과한가" 같은 뉘앙스의 영역이다.

다이어그램 설명. 이 그림은 통제 대상 하나를 손에 들고 던지는 단 하나의 질문, 그리고 그에 따른 두 갈래를 보여준다. 위에서 아래로 읽으면 된다 — 먼저 "이 규칙을 미리 명시적으로 적을 수 있는가"를 묻고, 적을 수 있으면 결정론 게이트로, 맥락이 필요하면 가드를 두른 LLM 판단으로 내려간다. 이 결정 트리가 중요한 이유는, 분담을 직감이 아니라 한 줄짜리 판별 질문으로 환원해 주기 때문이다. "위험 명령을 차단한다"를 두고 고민할 필요 없이, "위험 명령 패턴을 정규식으로 적을 수 있나? 있다" → 게이트, 이렇게 기계적으로 갈린다. 함정은 마지막 줄에 있다 — 게이트는 빠르고 우회 불가지만, LLM 쪽은 유연한 대가로 매 호출에 토큰 비용이 들고 같은 입력에도 결과가 흔들린다. 그래서 "맥락이 필요한가?"라는 질문은 꼭 필요할 때만 LLM으로 넘기라는 비용 통제이기도 하다.

실제 통제 작업을 두 영역에 매핑하면

추상적인 이야기를 내 로컬 AI 서버의 실제 통제 작업에 대입해 보자. 코딩 에이전트가 종일 파일을 고치고 명령을 실행하는 환경에서, 다음과 같은 가드들을 운영한다.

통제 작업	맡기는 손	이유
위험 명령 차단 (rm -rf /, force push 등)	결정론 게이트 (정규식)	위험 패턴이 정형화됨. 절대 뚫리면 안 되므로 우회 불가성이 최우선
코드 스타일·문법 (린트 규칙)	결정론 게이트 (린터)	규칙이 명문화됨. "줄당 길이 100자" 같은 건 기계가 센다
타입 정합성	결정론 게이트 (타입체커)	타입 에러는 참/거짓이 명확. 해석 여지 없음
기능 회귀 (테스트)	결정론 게이트 (테스트 스위트)	"통과/실패"가 결정적. 같은 코드면 같은 결과
코드 리뷰의 설계 뉘앙스	LLM 판단 + 가드	"이 추상화가 과한가"는 맥락. 규칙으로 못 적음
변수·함수 작명 적절성	LLM 판단 + 가드	"좋은 이름"은 의미 해석. 정규식으로 정의 불가

표 설명. 이 표는 실제 통제 작업 여섯 개를 두 영역에 배치한 결과다. 위 네 줄(위험 명령·린트·타입·테스트)은 모두 "규칙을 미리 적을 수 있는가"에 예로 답해 결정론 게이트로 갔고, 아래 두 줄(설계 뉘앙스·작명)은 아니오라서 LLM 판단으로 갔다. 한눈에 보이는 패턴은, 위험하고 자주 일어나며 명확한 일일수록 결정론 쪽에 쏠린다는 점이다. 통제의 양으로 따지면 결정론 게이트가 압도적으로 많다 — LLM은 "기계가 도저히 적을 수 없는" 소수의 자리에만 투입된다. 이게 비용 면에서도 합리적이다. 매 명령마다 LLM을 부르면 느리고 비싸지만, 정규식 대조는 공짜에 가깝다.

실행 시점에서 본 통제 파이프라인

이 분담이 실제로 어떻게 흐르는지, 에이전트가 명령 하나를 실행하려는 순간을 따라가 보자.

다이어그램 설명. 위 파이프라인은 에이전트의 한 행동이 거치는 통제 관문들을 시간 순서로 보여준다. 맨 위에서 행동이 시도되면, 가장 먼저 정규식 기반 위험 명령 검사가 가로막는다 — 여기서 걸리면 토론의 여지 없이 즉시 거부된다. 통과하면 행동이 실행되고, 코드 변경이라면 린터·타입체커·테스트라는 결정론 게이트들이 차례로 검사해 하나라도 실패하면 커밋을 막는다. 이 모든 결정론 관문을 다 통과한 뒤에야 비로소 LLM이 등장해 설계와 작명의 뉘앙스를 본다. 읽어야 할 핵심은 순서다 — 값싸고 확실한 결정론 게이트가 앞단에서 거르고, 비싸고 유연한 LLM은 맨 뒤에 둔다. 위험한 것일수록 앞에서, 기계적인 것일수록 앞에서 막는다. 흔한 설계 실수는 이 순서를 뒤집어 LLM에게 먼저 "이 명령 위험해?"를 묻는 것인데, 그러면 느린 데다 프롬프트로 우회까지 가능해진다. 그리고 LLM 단계의 끝은 "차단"이 아니라 "사람에게 넘김"이다 — 뉘앙스 판단은 틀릴 수 있으므로 최종 결정권을 사람이 쥔다.

잘못 배치하면 둘 다 실패한다

이 분담선의 진짜 교훈은 "각자 잘하는 걸 시켜라"가 아니다. 잘못된 곳에 잘못된 도구를 쓰면 둘 다 망가진다는 것이다. 두 가지 오배치를 각각 따라가 보자.

▲ 오배치 ① — 맥락이 필요한 일을 결정론으로 막을 때

다이어그램 설명. 첫 번째 오배치는 "좋은 변수명"처럼 맥락이 필요한 판단을 정규식 규칙으로 강제하려는 경우다. 위에서 아래로 따라가면, 규칙으로 좋은 이름을 정의하려는 시도가 끝없는 예외 규칙의 증식으로 이어지고, 그렇게 규칙을 늘려도 결국 맥락을 못 읽어 멀쩡한 이름을 잘못된 것으로 잡는 오탐이 폭발하며, 마지막엔 정상 작업까지 막혀 에이전트가 일을 못 하게 된다. 핵심 교훈은 결정론의 강점인 "확실함"이 여기서는 독이 된다는 점이다. 확실하게 틀린 판정을 확실하게 강제하니, 유연성이 필요한 자리에서 경직성이 재앙이 된다.

▲ 오배치 ② — 정형화 가능한 규칙을 LLM에 맡길 때

다이어그램 설명. 두 번째 오배치는 정규식 한 줄이면 끝날 위험 명령 차단을 LLM의 판단에 맡기는 경우다. 흐름을 따라가면, 같은 위험 명령에도 매번 다른 판정이 나와 신뢰할 수 없고, 프롬프트로 "이건 안전한 명령이야"라고 설득하면 그대로 뚫리며, 결국 우회 가능한 안전장치는 안전장치가 아니다라는 결론에 닿는다. 첫 번째 오배치와 정확히 거울상이다 — 거기서는 유연해야 할 자리에 경직성을 넣어 정상 작업을 막았고, 여기서는 확실해야 할 자리에 비결정성을 넣어 위험을 통과시킨다. 두 다이어그램을 나란히 놓고 보면, 잘못된 도구 선택의 대가가 양방향으로 대칭임이 드러난다.

그래서 무엇이 남는가

결정론 게이트와 LLM 판단은 경쟁 관계가 아니다. 서로의 빈틈을 메우는 두 개의 손이다. 한 손(결정론)은 빠르고 반복가능하며 우회 불가능해 신뢰성을 책임지고, 다른 손(LLM)은 맥락을 읽어 유연성을 책임진다.

분담선을 긋는 질문은 끝까지 하나다 — "이 규칙을 미리 명시적으로 적을 수 있는가?" 적을 수 있으면 코드로 굳히고, 없으면 LLM에 맡기되 사람이 최종 결정권을 쥔다.

이 선을 잘 그으면 신뢰성과 유연성을 동시에 얻는다. 잘못 그으면 — 맥락 판단을 정규식에 맡기거나 정형 규칙을 LLM에 맡기면 — 신뢰성도 유연성도 함께 잃는다. 에이전트 통제의 설계는 결국 "이 일은 어느 손에 속하는가"를 매번 정확히 판별하는 일이다. 똑똑한 도구를 갖는 것보다, 각 도구를 제자리에 두는 게 먼저다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.