1.3아키텍처 패턴 선택: 증강 LLM·워크플로·에이전트

Anthropic의 「Building effective agents」는 에이전틱 시스템을 구성하는 기본 요소부터 정리합니다.

증강 LLM(augmented LLM) 은 검색(retrieval), 도구(tools), 메모리(memory)가 붙은 단일 모델 호출입니다. 모델이 필요할 때 자기 도구를 쓰지만 전체 흐름은 한 번의 요청과 응답 안에서 끝납니다. 대부분의 실무 문제는 여기서 해결됩니다.

워크플로(workflow) 는 LLM과 도구가 미리 정의된 코드 경로를 따라 조율되는 시스템입니다. 단계와 순서를 코드가 정합니다.

에이전트(agent) 는 LLM이 스스로 과정과 도구 사용을 지휘하는 시스템입니다. 다음에 무엇을 할지 모델이 정하고, 코드는 루프와 도구와 종료 조건만 제공합니다.

판별 기준은 하나로 압축됩니다. 다음 단계를 누가 정하는가. 코드가 정하면 워크플로, 모델이 정하면 에이전트, 단계 개념 자체가 없으면 증강 LLM입니다.

# 증강 LLM: 한 번의 호출, 필요하면 모델이 도구를 쓴다
answer = call_model(question, tools=[search], model=MODEL)

# 워크플로: 단계와 순서가 코드에 있다
outline = call_model(f"개요를 작성하라: {topic}", model=MODEL)
draft = call_model(f"이 개요로 초안을 작성하라: {outline}", model=MODEL)

# 에이전트: 다음 행동을 모델이 고른다
while not done:
    action = call_model(history, tools=all_tools, model=MODEL)
    done = execute(action)

시험에서는 코드 조각이나 서술을 주고 어느 패턴인지 묻습니다. 도구를 쓴다는 사실만으로 에이전트가 되지 않는다는 점을 기억해 두십시오. 증강 LLM도 도구를 씁니다.

패턴 선택은 취향이 아니라 세 축의 계산입니다.

첫째, 경로 예측 가능성. 작업의 단계와 순서를 미리 열거할 수 있습니까? 인보이스에서 필드를 뽑고 검증한 뒤 ERP에 등록하는 일은 순서가 고정되어 있습니다. 반면 "이 버그의 원인을 찾아라"는 어디를 몇 번 봐야 할지 미리 알 수 없습니다. 앞은 워크플로, 뒤는 에이전트입니다.

둘째, 오류 비용과 관측 가능성. 에이전트는 중간 결정을 모델이 하므로 실패 지점이 실행마다 달라집니다. 오류의 비용이 크고 되돌리기 어려운 영역에서는 이 비결정성이 부담입니다. 같은 작업이라도 금전이 오가는 경로는 워크플로로 고정하고 판단 지점에만 모델을 두는 편이 안전합니다.

셋째, 지연과 비용 예산. 에이전트는 여러 턴을 돌고 각 턴이 누적 컨텍스트를 다시 읽습니다. 단순 작업에 에이전트를 쓰면 같은 결과에 몇 배의 토큰과 시간이 듭니다.

세 축을 표로 정리하면 선택이 기계적으로 나옵니다.

상황	권장 패턴
단일 질의, 근거 문서 필요	증강 LLM
단계가 고정, 예외 드묾	워크플로
단계 고정 + 판단 지점 존재	워크플로 + 지점별 모델 호출
경로 예측 불가, 탐색 필요	에이전트
경로 예측 불가 + 높은 오류 비용	에이전트 + 사람 확인 관문

마지막 행이 실무에서 가장 흔합니다. 에이전트를 쓰되 부작용이 있는 행동 앞에 확인을 두는 구조입니다.

워크플로를 골랐다면 그 안에서 다시 형태를 정합니다. Anthropic이 정리한 다섯 가지가 사실상 표준입니다.

• 프롬프트 체이닝(prompt chaining) — 작업을 순차 단계로 쪼개고 각 단계의 출력을 다음 입력으로 넘깁니다. 단계 사이에 프로그램적 검사(gate)를 두어 조건을 만족하지 못하면 중단합니다. 정확도를 위해 지연을 내주는 교환입니다
• 라우팅(routing) — 입력을 분류해 전문화된 후속 경로로 보냅니다. 유형별로 다른 프롬프트나 다른 등급의 모델을 쓸 수 있어, 한 프롬프트로 모든 유형을 처리할 때 생기는 품질 저하를 피합니다
• 병렬화(parallelization) — 독립적인 하위 작업을 동시에 돌리는 분할(sectioning)과, 같은 작업을 여러 번 돌려 결과를 모으는 투표(voting)로 나뉩니다. 투표는 신뢰도가 중요한 판정에 씁니다
• 오케스트레이터-워커(orchestrator-workers) — 중앙 모델이 작업을 동적으로 쪼개 워커에게 위임하고 결과를 종합합니다. 하위 작업의 개수와 종류를 미리 알 수 없을 때 씁니다
• 평가자-최적화자(evaluator-optimizer) — 한 모델이 생성하고 다른 모델이 평가해 되먹입니다. 평가 기준이 명확하고 반복이 실제로 결과를 개선할 때 값을 합니다

# 라우팅: 분류는 모델, 실행 경로는 코드가 통제
category = classify(ticket, model=SMALL_MODEL)   # 저비용 모델로 분류
handler = {"refund": refund_flow, "tech": tech_flow}.get(category, general_flow)
return handler(ticket)

라우팅 예시에서 분류에 작은 모델을 쓴 것이 핵심입니다. 분류는 단순 판단이라 상위 등급이 필요 없고, 전체 요청 수만큼 호출되므로 비용 영향이 큽니다. 패턴 선택은 모델 선택과 함께 갑니다.

Anthropic 문서가 반복해 강조하는 원칙은 가장 단순한 구성을 먼저 찾고, 복잡성은 성능으로 보상될 때만 더하라는 것입니다. 실무에서 이 원칙을 어겼는지 알아보는 신호가 있습니다.

• 오케스트레이션 코드가 프롬프트보다 길다 — 조율에 드는 노력이 판단에 드는 노력을 넘었다면 구조를 의심합니다
• 단계마다 같은 컨텍스트를 다시 넣는다 — 쪼갠 이득보다 재전송 비용이 클 수 있습니다
• 디버깅할 때 어느 단계에서 틀렸는지 사람이 추적하기 어렵다 — 단계 수가 관측 가능성을 넘어섰습니다
• 평가를 붙이지 못하고 있다 — 중간 산출물의 정답을 정의할 수 없다면 그 분해는 검증 불가능한 분해입니다

되돌리는 방법은 단계를 합치는 것입니다. 다섯 단계 체인을 두 단계로 줄였을 때 품질이 유지된다면 세 단계는 불필요했던 것입니다. 이 확인은 감이 아니라 평가 집합으로 합니다.

반대 방향의 함정도 있습니다. "항상 단순한 것이 낫다"는 서술은 시험에서 오답으로 자주 쓰입니다. 경로를 예측할 수 없고 탐색이 필요한 문제에 단일 호출을 고집하면 품질이 나오지 않습니다. 원칙은 단순함 우선이지 단순함 강제가 아닙니다.