LLM은 “판단하는 도구”이지,
시스템의 규칙과 책임까지 대신 설계해주지는 않는다.
LangChain으로 Agent를 설계하다 보면
어느 순간부터 이런 프롬프트를 쓰고 있는 나를 발견하게 된다
“적절히 판단해서 처리해줘”
“상황에 맞게 알아서 결정해줘”
이게 나만의 문제는 아니라고 생각한다
LLM은 너무 똑똑해보이고 실제로 웬만한 질문에는 그럴듯한답을 내놓기 때문이다.
특히 멀티 에이전트 구조를 만들 때는 더 그렇다
각 에이전트가 역할을 나눠서 추론하고, 도구를 선택하고, 결론을 내리는 모습을 보고 있으면
“이 정도 판단은 LLM이 알아서 해주지 않을까?” 라는 유혹이 강하게 든다
나역시 금융 멀티 에이전트를 설계하면서
초반에는 통제보다 자율성에 더 무게를 뒀다.
하지만 그 선택은 분명한 대가로 돌아왔다.
LLM이 잘하는 판단 / 못하는 판단
이 지점을 명확히 나누지 않으면
Agent 설계는 반드시 흔들린다.
LLM이 잘하는 판단
- 맥락을 읽고 의미를 해석하는 것
- 여러 정보의 관계를 설명하는 것
- 사람이 이해할 수 있는 언어로 이유를 정리하는 것
- “왜 이런 결론이 나왔는지”를 서술하는 것
이 영역에서 LLM은 정말 강력하다.
LLM이 못하는 판단
반대로, 다음과 같은 판단은 LLM에게 맡기는 순간 위험해진다.
- 언제 종료해야 하는지
- 어떤 단계로 이동해야 하는지
- 비용이 발생하는 작업을 실행할지 말지
- 보안·책임이 수반되는 결정을 내려야 할 때
LLM은 확률적으로 그럴듯한 답을 내놓을 뿐
시스템의 규칙과 책임을 이해하지 않는다.
이걸 토대로 LLM에게 맡기면 안되는 판단 3가지를 정리해봤다.
1. Agent의 흐름 제어를 LLM에게 맡기는 것
LLM은 “다음에 뭘 할지”를 말하는 데 능숙하다.
말 그대로 다음에 올 단어를 “예측하는” 모델이기 때문이다.
하지만 언제 멈춰야 하는지, 지금 단계가 끝났는지를 판단하는 건 전혀 다른 이야기다.
예를 들어 LLM에게 프롬프트를 쓸 때 이런 식으로 작성하는 경우가 많다.
“이제 충분한 정보가 모였으면 종료해줘”
이런 프롬프트는 거의 항상 문제를 만든다.
- 무한 루프
- 너무 이른 종료
- 실행마다 다른 결과
흐름 제어는 코드의 책임이다.
LLM은 흐름을 결정하는 존재가 아니라
이미 정해진 흐름 안에서 의견을 내는 역할이 맞다.
2. Tool 선택 기준을 LLM에게 전적으로 맡기는 것
LangChain Agent을 구현할 때 가장 흔하게 보이는 실수다.
- Tool A, Tool B, Tool C 설계
- “어떤 Tool을 쓸지 LLM이 판단하도록”
문제는 이 판단이 전혀 안정적이지 않다는 점이다.
- 프롬프트 한 줄 변경
- temperature 변화
- 모델 버전 변경
→ 전혀 다른 Tool을 호출한다.
Tool 선택은 규칙 기반으로 고정하고
LLM은 “왜 이 Tool이 적합한지 설명”하는 역할만 맡기는 편이 훨씬 안정적이다.
3. 비용·보안 관련 결정을 LLM에게 맡기는 것
LLM은 비용을 모른다.
그리고 책임도 없다.
- 외부 API 호출
- 유료 연산 실행
- 민감한 데이터 접근
이런 결정을 LLM에게 넘기는 순간
Agent는 통제 불가능한 시스템이 된다.
이 영역만큼은 반드시
- 명시적 조건
- allowlist
- 코드 레벨 제한
이 있어야 한다.
LLM은 판단자가 아니라 설명자여야 한다.
실제로 문제가 생겼던 사례: “내가 통제력을 잃었다”는 감각
금융 도메인에서 멀티 에이전트를 만들다 보면
다음과 같은 판단들이 계속 등장한다.
- 지금 데이터가 충분한가?
- 추가 분석이 필요한가?
- 외부 API를 호출해도 되는가?
- 어떤 데이터를 어떻게 가공하여 사용할 것인가?
- 이 결과를 사용자에게 바로 노출해도 되는가?
나는 이 중 일부를 프롬프트로 넘겼다.
“지금까지의 정보를 바탕으로 추가 분석이 필요하면 진행해줘”
“필요한 API는 상황에 맞게 골라줘”
“데이터 검증 여부를 판단해”
처음엔 잘 되는 것처럼 보였다.
하지만 테스트 케이스가 늘어날수록 이상한 현상이 생기기 시작했다.
- 어떤 경우에는 과도하게 많은 분석을 수행하고
- 어떤 경우에는 너무 이르게 종료되었으며
- 같은 입력인데도 실행 결과가 계속 달라졌다
그때 처음으로 들었던 생각이 있다.
“아, 지금 이 시스템은 내가 통제하고 있지 않구나.“
문제는 LLM의 성능이 아니었다.
문제는 판단의 책임을 어디에 두었느냐였다.
지금 내가 쓰는 최소 원칙
여러 번의 시행착오 끝에
나는 Agent를 설계할 때 최소한 이 원칙들은 지킨다.
- 흐름과 종료 조건은 절대 프롬프트에 맡기지 않는다
- 비용·보안이 걸린 판단은 코드로만 제어한다
- LLM에게는 “결정”이 아니라 “의견”만 요청한다
- “알아서 해줘”같은 모호한 문장이 프롬프트에 보이면 다시 설계한다
이 원칙을 지키기 시작하면서
Agent의 행동은 눈에 띄게 예측 가능해졌다.
그리고 무엇보다
다시 내가 시스템을 통제하고 있다는 감각이 돌아왔다.
결론: 지피지기, Agent 설계에도 그대로 적용된다
손자병법에 이런 말이 있다.
지피지기면 백전백승
나를 알고 적을 알면 백 번 싸워도 위태롭지 않다.
Agent 설계에서도 이 문장은 그대로 유효하다.
여기서
- 적을 안다는 것은 LLM이 무엇을 잘하고 못하는지 아는 것이고
- 나를 안다는 것은 이 시스템에서 내가 반드시 통제해야 하는 책임과 규칙이 무엇인지를 아는 것이다.
LLM은
판단을 “대신” 내려주는 존재가 아니다.
판단을 “설명해 줄 수 있는” 존재에 가깝다.
이 경계를 흐리면 Agent는 똑똑해 보일 수는 있어도
결국 통제 불가능한 시스템이 된다.
반대로
- 흐름은 코드가 잡고
- 책임은 사람이 지며
- LLM은 그 안에서 의견과 해석을 제공할 때
Agent는 비로소 예측 가능하고 확장 가능한 구조가 된다.
LLM Agent 설계의 핵심은
더 많은 자율성을 주는 것이 아니라,
어디까지 맡기고 어디서부터 맡기지 않을지를 아는 것
이것이 내가 지금 이해한
에이전트 설계에서의 “지피지기”다.
