AI 에이전트의 환상에서 벗어나라: 이제는 '시스템'이 승리하는 시대

단일 모델의 지능에 의존하는 에이전트 중심 설계의 한계를 분석하고, 워크플로우와 시스템 아키텍처로 성능을 극대화하는 실전 전략을 제시합니다.

많은 기업과 개발자들이 AI 에이전트라는 단어에 매료되어 있습니다. ‘스스로 생각하고, 계획을 세우고, 도구를 사용하여 문제를 해결하는 자율적인 존재’. 이 매혹적인 비전은 우리에게 매우 편리한 미래를 약속하는 것처럼 보입니다. 하지만 실제 프로덕션 환경에서 자율형 에이전트를 구축해 본 이들이라면 공통적으로 느끼는 좌절감이 있습니다. 바로 ‘불확실성’과 ‘통제 불능’입니다.

우리는 그동안 모델의 파라미터 수가 늘어나고 추론 능력이 향상되면, 에이전트가 더 복잡한 작업을 스스로 완벽하게 수행할 것이라고 믿어왔습니다. 하지만 현실은 다릅니다. 모델의 지능이 높아져도 루프(Loop) 속에서 길을 잃거나, 엉뚱한 도구를 호출하고, 예상치 못한 방향으로 추론을 전개하는 ‘할루시네이션’의 변종들은 여전히 존재합니다. 이제 우리는 질문을 바꿔야 합니다. 과연 AI 모델 하나가 모든 것을 해결하는 ‘전지전능한 에이전트’를 만드는 것이 정답일까요, 아니면 모델은 최소한의 역할만 수행하고 이를 감싸는 ‘시스템’이 전체 프로세스를 제어하게 만드는 것이 정답일까요?

모델의 지능보다 시스템의 구조가 중요한 이유

최근 AI 업계의 흐름은 ‘단일 모델의 거대화’에서 ‘컴포지셔널 AI(Compositional AI)’ 또는 ‘워크플로우 최적화’로 이동하고 있습니다. 이는 에이전트가 수행해야 할 일을 줄이고, 시스템이 수행해야 할 일을 늘리는 전략입니다. 에이전트가 ‘무엇을 할지’ 스스로 결정하게 만드는 대신, 시스템이 ‘어떤 순서로 무엇을 해야 할지’를 정의하고 모델은 그 단계에서의 ‘최적의 결과물’만 내놓게 하는 방식입니다.

이러한 접근 방식이 필요한 이유는 명확합니다. 첫째, 결정론적 결과의 필요성입니다. 비즈니스 로직은 예측 가능해야 합니다. 사용자가 A를 요청했을 때 AI가 매번 다른 경로로 추론하여 서로 다른 품질의 결과를 내놓는다면 그것은 제품으로서 가치가 없습니다. 둘째, 비용과 속도의 효율성입니다. 모든 단계에서 고성능 모델이 복잡한 추론(Reasoning)을 수행하게 하면 토큰 비용은 기하급수적으로 증가하고 응답 속도는 느려집니다. 시스템이 경로를 지정해주면, 각 단계에 맞는 가벼운 모델을 배치하여 효율을 극대화할 수 있습니다.

에이전트 중심 vs 시스템 중심: 패러다임의 전환

기존의 에이전트 중심 설계는 모델에게 목표(Goal)를 주고, 모델이 스스로 계획(Plan)을 세워 실행(Execute)하게 합니다. 반면 시스템 중심 설계는 개발자가 워크플로우(Workflow)를 설계하고, 모델은 각 노드(Node)에서 필요한 텍스트 생성이나 데이터 추출 같은 구체적인 작업만 수행합니다.

에이전트 중심 (Agent-Centric): 목표 설정 $
ightarrow$ 자율적 계획 $
ightarrow$ 도구 선택 $
ightarrow$ 실행 $
ightarrow$ 결과 평가 $
ightarrow$ (반복)
시스템 중심 (System-Centric): 입력 $
ightarrow$ 단계 1(모델 A: 분류) $
ightarrow$ 단계 2(모델 B: 추출) $
ightarrow$ 단계 3(코드: 검증) $
ightarrow$ 단계 4(모델 C: 합성) $
ightarrow$ 출력

시스템 중심 설계에서는 모델이 ‘생각’하는 시간을 줄이고 ‘작업’하는 시간에 집중하게 합니다. 이는 마치 숙련된 요리사 한 명에게 “맛있는 저녁 식사를 준비해줘”라고 맡기는 것(에이전트 방식)과, 레시피를 정교하게 짜고 각 단계마다 재료 손질, 가열, 플레이팅 담당자를 배치하는 것(시스템 방식)의 차이와 같습니다. 후자가 훨씬 더 일관된 품질의 요리를 빠르게 내놓을 수 있는 것과 같은 이치입니다.

기술적 구현 전략: 워크플로우의 세분화

시스템 중심의 AI 제품을 구축하기 위해서는 ‘작업의 원자화’가 선행되어야 합니다. 복잡한 요청을 한 번의 프롬프트로 해결하려 하지 말고, 이를 최소 단위의 작업으로 쪼개야 합니다. 예를 들어, 고객의 불만 사항을 분석하여 답변을 생성하는 시스템을 만든다면 다음과 같은 파이프라인을 구성할 수 있습니다.

먼저, 입력된 텍스트의 감정과 의도를 분류하는 ‘분류기(Classifier)’ 단계를 둡니다. 여기서 모델은 단순히 ‘불만/문의/칭찬’ 중 하나를 선택합니다. 그 다음, 분류된 의도에 따라 필요한 내부 데이터베이스에서 정보를 가져오는 ‘리트리버(Retriever)’ 단계를 거칩니다. 이후 가져온 정보가 질문에 적절한지 검증하는 ‘검증기(Validator)’를 배치합니다. 마지막으로 검증된 정보만을 바탕으로 답변을 작성하는 ‘생성기(Generator)’가 작동합니다.

이 과정에서 각 단계는 서로 다른 프롬프트와 서로 다른 모델을 사용할 수 있습니다. 분류 단계에서는 매우 빠르고 저렴한 소형 모델(SLM)을 사용하고, 최종 답변 생성 단계에서만 고성능 모델(GPT-4o, Claude 3.5 Sonnet 등)을 사용하는 식입니다. 이렇게 하면 전체 시스템의 안정성은 높아지고 비용은 낮아집니다.

시스템 중심 접근법의 장단점 분석

모든 설계 선택에는 트레이드오프가 존재합니다. 시스템 중심 접근법 역시 완벽한 정답은 아닙니다. 아래 표를 통해 에이전트 방식과 시스템 방식의 차이를 명확히 비교해 보겠습니다.

비교 항목	자율형 에이전트 (Agentic)	구조적 시스템 (Systemic)
예측 가능성	낮음 (매번 결과가 다를 수 있음)	높음 (정해진 경로를 따름)
개발 속도	빠름 (프롬프트 하나로 시작)	느림 (워크플로우 설계 필요)
유지보수	어려움 (디버깅 포인트가 모호함)	쉬움 (특정 단계의 문제 파악 가능)
확장성	모델 성능에 의존적	모듈 교체 및 추가가 용이함

결국 에이전트 방식은 ‘탐색적 작업’이나 ‘창의적 문제 해결’에 적합하고, 시스템 방식은 ‘반복적 업무’나 ‘기업용 서비스’에 적합합니다. 우리가 만드는 것이 장난감이 아니라 제품(Product)이라면, 당연히 시스템 중심의 설계가 우선되어야 합니다.

실무자를 위한 단계별 액션 가이드

지금 당장 운영 중인 AI 기능의 성능을 높이고 싶다면, 다음의 단계를 따라 설계를 변경해 보십시오.

1단계: 실패 지점의 정밀 분석
현재 AI가 내놓는 오답들을 수집하십시오. 모델이 계획을 잘못 세웠는지, 도구 호출 단계에서 실수했는지, 아니면 최종 답변 생성 단계에서 헛소리를 했는지 구분해야 합니다. 대부분의 문제는 ‘너무 많은 일을 한 번에 시켰을 때’ 발생합니다.

2단계: 워크플로우 맵핑 (Workflow Mapping)
사용자의 입력부터 최종 출력까지의 과정을 순서도로 그리십시오. ‘판단’이 필요한 지점과 ‘실행’이 필요한 지점을 명확히 구분하십시오. 모델이 스스로 판단하게 두지 말고, if-then-else 구조의 로직을 통해 경로를 강제하는 구간을 만드십시오.

3단계: 모델의 역할 분리 (Role Separation)
하나의 거대한 프롬프트를 여러 개의 작은 프롬프트로 쪼개십시오. ‘너는 최고의 분석가이자 작가이며 검토자야’라고 말하는 대신, 분석 전용 프롬프트, 작성 전용 프롬프트, 검토 전용 프롬프트를 각각 만드십시오. 각 단계의 출력값이 다음 단계의 입력값이 되는 체인을 구성하십시오.

4단계: 가드레일 및 검증 루프 추가
모델의 출력값이 기대한 형식(JSON 등)인지 확인하는 스키마 검증 단계를 추가하십시오. 만약 형식이 틀렸다면 다시 생성하게 하는 단순한 루프를 시스템 레벨에서 구현하십시오. 이는 모델의 지능에 기대는 것이 아니라 코드의 안정성에 기대는 방식입니다.

결론: 지능의 도구화

AI 모델은 더 이상 ‘해결사’가 아니라, 시스템이라는 거대한 기계를 돌리는 ‘부품’이 되어야 합니다. 모델의 성능이 올라갈수록 우리는 모델에게 더 많은 자유를 주는 것이 아니라, 더 정교한 시스템 속에 모델을 배치하여 그 성능을 100% 끌어낼 수 있는 환경을 만들어야 합니다.

에이전트가 스스로 생각하게 만드는 마법에 매달리지 마십시오. 대신, 모델이 실수할 수 없는 구조를 설계하는 엔지니어링에 집중하십시오. 에이전트는 덜 하고, 시스템은 더 많이 하게 만드는 것. 이것이 현재 LLM을 활용한 제품 개발에서 가장 빠르게 성공하는 길입니다.

FAQ

The Agent Does Less. The System Does More.의 핵심 쟁점은 무엇인가요?

핵심 문제 정의, 비용 구조, 실제 적용 방법, 리스크를 함께 봐야 합니다.

The Agent Does Less. The System Does More.를 바로 도입해도 되나요?

작은 범위에서 실험하고 데이터를 확인한 뒤 단계적으로 확대하는 편이 안전합니다.

실무에서 가장 먼저 확인할 것은 무엇인가요?

목표 지표, 대상 사용자, 예산 범위, 운영 책임자를 먼저 명확히 해야 합니다.

법률이나 정책 이슈도 함께 봐야 하나요?

네. 데이터 수집 방식, 플랫폼 정책, 개인정보 관련 제한을 반드시 점검해야 합니다.

성과를 어떻게 측정하면 좋나요?

비용, 전환율, 클릭률, 운영 공수, 재사용 가능성 같은 지표를 함께 보는 것이 좋습니다.

지금 바로 시작할 수 있는 실무 액션

현재 팀의 AI 활용 범위와 검증 절차를 먼저 문서화합니다.
작은 파일럿 프로젝트로 KPI를 정하고 2~4주 단위로 검증합니다.
보안, 품질, 리뷰 기준을 자동화 도구와 함께 연결합니다.

AI 에이전트의 환상에서 벗어나라: 이제는 ‘시스템’이 승리하는 시대