AI 에이전트는 탐색에 쓰고, 반복은 코드로 고정해야 한다

Lead: AI 에이전트를 잘 쓰는 팀은 에이전트에게 모든 일을 맡기지 않는다. 불확실성과 탐색은 에이전트가 처리하고, 이미 답이 나온 반복 작업은 코드로 고정한다. 이 분리가 되면 MCP도 가벼워지고, 제품도 안정되고, 토큰도 아낄 수 있다.

TL;DR

에이전트는 예외 처리, 비정형 데이터 이해, 새로운 경로 탐색에 강하다.
결정론적 코드와 툴은 정형 데이터 처리, 반복 업무, 정확도가 중요한 비즈니스 로직에 강하다.
MCP는 외부 시스템을 많이 붙이는 장치가 아니라, 정확히 필요한 연결만 남기는 얇은 통로여야 한다.
좋은 AI 제품은 “더 똑똑한 모델”보다 역할 분리와 검증 루프로 강해진다.

왜 지금 중요한가

요즘 많은 팀이 같은 실수를 한다. LLM이 똑똑해 보이니까, 반복되는 일까지 전부 에이전트에게 시킨다. 처음에는 편하다. 하지만 조금만 커지면 문제가 바로 드러난다.

같은 작업을 매번 다시 생각한다.
결과가 조금씩 흔들린다.
예외가 쌓일수록 프롬프트가 길어진다.
MCP와 툴이 늘어나면서 오히려 관리가 어려워진다.

핵심은 단순하다. 에이전트가 잘하는 일과 코드가 잘하는 일을 섞지 않는 것이다.

핵심 규칙: 불확실성은 에이전트가, 확실성은 코드가

에이전트는 본질적으로 탐색형 도구다. 답이 하나로 고정되지 않은 문제에 강하다.

고객 입력이 애매할 때
문서가 정리되지 않았을 때
여러 경로 중 무엇이 맞는지 비교해야 할 때
로그를 읽고 다음 행동을 추론해야 할 때

반대로 코드가 강한 구간도 분명하다.

구조화된 데이터 파싱
계산과 검증
정해진 API 호출
반복적인 상태 전이
실패 시 재시도 규칙

즉, 에이전트는 “무엇을 해야 할지 찾는 역할”, 코드는 **“찾은 일을 정확히 끝내는 역할”**이다.

flowchart LR
  A[불확실한 입력] --> B[에이전트 탐색]
  B --> C[패턴 발견]
  C --> D[결정론적 코드로 고정]
  D --> E[툴 / API / 스킬]
  E --> F[반복 실행]
  F --> G[검증]

이 흐름이 짧을수록 좋다. 에이전트가 오래 고민할수록 좋은 제품이 되는 게 아니다. 한 번 발견한 패턴을 얼마나 빨리 고정하느냐가 더 중요하다.

3단계 전환: 탐색 → 패턴화 → 고정

이 방식이 실전에서 가장 잘 먹힌다.

1단계: 탐색

처음에는 에이전트에게 넉넉한 자유도를 준다. 여러 방법을 시도하게 하고, 로그를 남긴다.

이 단계의 목표는 정답이 아니다. 반복되는 모양을 찾는 것이다.

2단계: 패턴화

같은 작업 흐름이 3회 이상 보이면 주목해야 한다.

예를 들면 이런 식이다.

항상 같은 API를 먼저 조회한다.
항상 같은 정렬 규칙으로 결과를 바꾼다.
항상 같은 예외 처리 분기를 탄다.

이때부터는 프롬프트를 더 키우기보다, 흐름을 읽어야 한다.

3단계: 고정

고정된 입력과 출력이 보이면 결정론적 코드로 옮긴다.

정규화는 함수로
검증은 테스트로
반복 호출은 스크립트나 API로
단순 변환은 스킬이나 툴로

이렇게 하면 에이전트는 더 어려운 문제에만 집중할 수 있다.

MCP는 많이 붙이는 게 아니라, 얇게 유지하는 것이다

MCP를 도입할 때 흔한 함정이 있다. 연결할 수 있는 시스템이 많아지면 좋아 보인다는 착각이다. 실제로는 반대다.

툴이 너무 많아지면:

컨텍스트가 낭비된다.
어떤 툴을 써야 하는지 헷갈린다.
유지보수 범위가 커진다.
환각이 늘어난다.

그래서 원칙은 단순해야 한다.

1 MCP = 1 목적

하나의 MCP는 하나의 명확한 역할만 가져야 한다. 예를 들어:

GitHub 조회 전용
DB 조회 전용
Slack 알림 전용
배포 상태 확인 전용

에이전트는 그 결과를 읽고 판단만 하면 된다. MCP는 판단하는 장치가 아니라, 정확한 데이터를 가져오는 통로다.

실무에서 바로 적용하는 방법

1) 에이전트가 매번 다시 생각하는 구간을 찾는다

같은 질문, 같은 변환, 같은 승인 흐름이 반복되는지 본다.

2) 정형 로직과 비정형 로직을 나눈다

정형 데이터 파싱, 정렬, 필터링, 검증은 코드로 넘긴다. 에이전트는 해석과 예외 처리만 맡긴다.

3) 자주 쓰는 툴만 남긴다

툴이 20개, 30개로 불어나면 구조가 이미 망가지고 있는 신호다. 정말 자주 쓰는 핵심만 남겨야 한다.

4) 결과 분석기로 에이전트를 재배치한다

에이전트의 가치는 작업 수행 그 자체보다, 결과를 해석하고 다음 결정을 돕는 능력에서 더 크게 나온다.

리스크 / 반론

물론 모든 걸 코드로만 고정할 수는 없다.

규칙이 자주 바뀌는 도메인은 오히려 에이전트가 필요하다.
초반에는 패턴이 부족해서 고정하기 어렵다.
너무 빨리 고정하면 유연성을 잃을 수 있다.

그래서 정답은 “전부 코드”가 아니다. 탐색은 에이전트, 반복은 코드라는 분리를 유지하는 것이다.

결론

AI 에이전트 구축의 핵심은 더 많은 기능을 붙이는 게 아니다. 이미 답이 나온 일을 계속 생각하게 하지 않는 데 있다.

에이전트는 불확실한 곳에 쓰고, 결정론적 코드는 반복 구간에 박아 넣어라. MCP는 그 사이를 잇는 얇은 통로로만 남겨라.

이 원칙이 잡히면 제품은 단순해지고, 비용은 줄고, 신뢰는 올라간다. 그리고 그때부터 에이전트는 “똑똑한 데모”가 아니라 실제로 운영 가능한 시스템이 된다.