Workflow vs Agent, AI Agent 아키텍쳐

1. 정의 (주요 차이점 : 사전 결정 수준)

Workflow 

정해진 순서대로 움직이는 시스템 (엄격하고 사전 설계된 경로를 따름)

1→2→3 순서로 처리” 같은 예측 가능한 작업에 적합

 

Agent

스스로 판단해서 움직이는 시스템 (환경 피드백을 기반으로 실시간으로 적응하고 결정을 내림)

문제도, 해결 순서도 매번 달라지는 열린 문제에 적합

 

OpenAI 정의
지시사항(해야 할 것), 가드레일(하지 말아야 할 것), 도구(할 수 있는 것)을 가지고 사용자를 대신해 행동하는 AI 시스템

예를 들어, 사용자가 “서울 주말 날씨로 여행 일정 짜줘”라고 하면

1. 날씨 API를 부르고,
2. 호텔 예약 도구를 쓰고,
3. 여행 일정을 요약해서 출력까지 해주는 것.

2. 설계 원칙

1. 가장 단순한 솔루션으로 시작하기
    * 불필요한 복잡성 피하기
    * 명확한 이점이 있을 때만 복잡성 추가
2. 결과로 검증하기
    * 복잡한 Agent가 항상 더 나은 것은 아님
    * 실제 성과 지표로 평가
3. 점진적 개선
    * Workflow로 시작 → 필요시 Agent 기능 추가
    * 단계별로 복잡성 증가

실제로는 Workflow와 Agent를 결합하는 것이 효과적인 경우가 많음

예)

여행 플랜 자동 생성:
라우팅(“지역/기간/취향” 분기) → 병렬(맛집/코스/교통 동시 산출) → 평가–개선(예산/이동시간 기준 맞출 때까지)

커머스 Q&A 봇:
라우팅(환불/배송/가격) → 각 워크플로우(정해진 규정 답변) + 필요 시 에이전트가 재고/가격 API 조회 도구 호출

 

5. LLM 강화세트

패턴만 정해도 LLM이 허술하면 실패. 그래서 LLM을 실무용으로 보강 필요

• Structured Output(구조화 출력): LLM 답을 **스키마(JSON)**에 맞추게 강제 → 파싱 실수↓, 안정성↑
• Tool Calling(툴 호출): 계산·검색·DB·크롤러 같은 외부 능력을 호출 → 현실 업무 처리력↑
• Short-term Memory(단기 기억): 직전 상태/결과를 담아 단계 간 연결성↑

→ 이건 모든 패턴을 실제로 돌릴 때의 필수 옵션. 패턴 선택 후 LLM 강화 필요

 

6. LangGraph

LangGraph = 패턴을 안전하고 재현성 있게 제품 수준으로 돌리게 해주는 실행기

패턴/강화 이후 실행/상태/배포/디버깅이 필요함. LangGraph는 이를 위한 오케스트레이션 프레임워크:

• StateGraph로 노드/엣지 구성(체이닝·병렬·라우팅을 눈으로 설계)
• Persistence(상태 저장), Streaming(중간결과 스트림), Deploy & Debug 지원
• Send API로 동적 워커 생성(오케–워커 패턴 구현에 핵심)

 

7. 설계 순서

문제 성격 판단 절차 고정/검증 가능? → 워크플로우 위주 경로 유동/탐색 필요? → 에이전트 섞기(툴 권한·스텝 제한 필수) 패턴 조합 선택 (대표적인 6개 패턴 중에서 조합해서 사용 가능) - ai agent 아키텍쳐 예: “라우팅 → 병렬(요약/키워드/품질) → 평가–개선 → 통합” 동적 작업량이면 중간에 오케–워커로 확장 LLM 강화 적용 출력 스키마 정의(JSON) 필요한 도구 명세/권한/제약(쿼터, 타임아웃, 실패 재시도) 단기 메모리(노드 간 상태 키) 설계 LangGraph로 구현 노드/엣지 그래프화 → x-ray/시각화로 디버깅 Persistence/캐시로 비용↓, Streaming으로 UX↑ 배포 파이프라인(버전·로그·옵저버빌리티)

 

 

---

 

1. AI Agent = 스스로 판단하고 행동하는 LLM 시스템
지시사항(해야 할 것), 가드레일(하지 말아야 할 것), 도구(할 수 있는 것)을 기반으로 목표 달성.

 

2. AI agent 핵심 구성요소

 

 

3. AI agent 사고 루프 구조 

상황분석 → 도구선택 → 실행 → 결과, 평가 → 부족 시 반복

 

 

4. 대표 설계 패턴 6가지

• 핵심 agent 아키텍쳐 유형
  • 라우터 아티텍처
    
    • LLM이 미리 정의된 옵션 중 단일 단계를 선택,
    • 구조화된 출력 기법 활용:
      - Prompt engineering (프롬프트 엔지니어링)
      - Output parsers (출력 파서)
      - Tool calling (도구 호출)

    • graph LR
          Input[질문] --> Router{라우터 Agent}
          Router -->|기술 지원| Tech[기술팀으로 전달]
          Router -->|결제 문의| Billing[결제팀으로 전달]
          Router -->|일반 문의| General[일반 지원팀으로 전달]

  • Tool- calling agent architecture(도구 호출 agent  아키텍처)
    • 1) Tool Calling (도구 호출)
      LLM이 다양한 도구를 선택하고 사용
      API 호출, 데이터베이스 쿼리, 외부 서비스 연동 등
      
      
    • 2) Memory (메모리)
      단기 메모리 (Short-term Memory):
      - 현재 시퀀스 내에서 정보 유지, 대화 컨텍스트, 중간 결과 저장
      - 예시: ChatGPT 한 세션에서 주고 받은 메시지
      
      장기 메모리 (Long-term Memory):
      - 상호작용 전반에 걸쳐 정보 회상, 사용자 선호도
      - 예시: CLAUDE.md, AGENTS.md
    • 3) Planning (계획 수립)
      재귀적 루프를 통한 계획:
      
      1. 호출할 도구 결정
      2. 도구 실행
      3. 결과 평가
      4. 충분한 정보가 수집되면 종료

  • graph TB
        subgraph "Tool-Calling Agent"
            LLM[LLM Core]
            Tools[도구 모음]
            Memory[메모리]
            Planning[계획 모듈]
    
            LLM <--> Tools
            LLM <--> Memory
            LLM <--> Planning
        end
    
        Input[입력] --> LLM
        LLM --> Output[출력]

 

• 고급 Agent 설계 패턴

 

 

1) Prompt Chaining (직렬 체인)

뭐야? 단계별로 LLM을 순서대로 부름.
언제? 검증 가능한 정형 작업을 쪼갤 때(요약→검증→폼맞춤).
장점: 디버깅 쉬움. 재현성 높음.
예: 번역 → 용어검수 → 포맷팅.

 

2) Parallelization (병렬)

뭐야? 독립 하위작업을 동시에 돌림.
언제? 속도가 중요하거나 평가기준이 여러 개일 때.
장점: 빠름, 다양한 관점 비교.
예: 한 문서에서 키워드 추출·요약·품질검사 동시 실행.

 

3) Routing (라운팅)

뭐야? 먼저 분류하고, 유형별 서브플로우로 보내기.
언제? “반품/환불/가격문의”처럼 케이스별 절차가 다른 QA/헬프데스크.
장점: 한 시스템으로 다품종 대응.
예: 문의 → 분류(가격/환불/배송) → 전용 처리로 이동.

 

4) Evaluator–Optimizer (평가–개선 루프)

뭐야? 생성 → 평가 → 부족하면 피드백 반영 재생성 반복.
언제? 정답은 없지만 기준은 있는 작업(번역 품질, 스타일 가이드).
장점: 품질 수렴. 기준 충족까지 자동 반복.
예: 번역 → 톤/정확도 평가 → 수정 → 합격까지.

 

5) Orchestrator–Worker (오케스트레이터–워커)

뭐야? **기획자(오케스트레이터)**가 작업을 쪼개 워커들에 배분, 모아 합침.
언제? 섹션 수나 파일 수가 매번 달라지는 문서/코드 작업.
장점: 동적 fan-out(작업 개수 가변), 확장성.
예: “보고서 목차 자동 설계 → 섹션별 워커가 작성 → 통합”.

 

6) Agents (도구 쓰는 자율 루프)

뭐야? LLM이 어떤 도구를 언제 쓸지 스스로 결정하며 반복.
언제? 경로가 미정(검색→추론→코드실행→재검색… 같은 열린 탐색).
장점: 유연성 최고.
주의: 가드레일/리밋(스텝 수, 코스트, 툴 권한) 꼭 설정.

 

 

++ 고급 기능

👨‍🏫 Human-in-the-Loop (인간 개입)

• 중요한 의사결정 시 사람의 승인 필요.
• 예: 금융 승인, 콘텐츠 검수.

🪞 Reflection (성찰)

• Agent가 자신의 결과를 스스로 평가·개선.
• 예: “이 답변 괜찮았나?”를 되돌아보는 구조.

 

++ 무엇을 써야 할까?

• 절차가 고정이고 검증 가능 → Workflow (Prompt Chaining/Parallel/Routing)
• 작업 개수/구조가 매번 달라짐 → Orchestrator–Worker
• 기준 충족까지 다듬기 필요 → Evaluator–Optimizer
• 탐색·결정·도구선택을 스스로 하게 하고 싶음 → Agent
• 현업 서비스면 보통:
  “라우팅(분기)” + “오케스트레이터–워커(확장)” + “평가–개선(품질)”을 조합,
  위험 구간만 에이전트로 자율화(툴 권한/스텝 제한 필수).

 

5. 싱글 vs 멀티 에이전트 비교

구분	설명	장점	단점
🧍‍♂️ 싱글 Agent	한 LLM이 전체 과정 수행	일관성 높고 비용 적음	느리고 확장성 제한
👥 멀티 Agent (오케–워커)	중앙 Agent가 여러 전문 Agent를 병렬 제어	빠르고 병렬처리 가능	토큰 사용량 많고 맥락 단절 가능

 

예시: 리드 Agent → 섹션별 워커에게 보고서 작성 지시 → 결과 통합 → 품질 평가.

 

• 멀티 에이전트가 유리한 경우 (Anthropic)
  Orchestrator-Worker 패턴:
  - 리드 Agent가 전문화된 하위 Agent들을 병렬로 조정
  - 연구 평가에서 싱글 Agent 대비 90.2% 성능 향상
  
  적합한 작업:
  - 병렬화가 가능한 독립적 탐색 경로
  - 단일 컨텍스트 윈도우를 초과하는 정보량
  - 여러 복잡한 도구 동시 사용 필요
  
  한계:
  - 토큰 사용량 15배 증가
  - Agent 간 의존성이 높은 작업엔 비효율적
  - 코드 작성 등 병렬화 어려운 작업엔 부적합

 

• 싱글 에이전트를 선택해야 하는 경우 (Cognition AI)
  
  • 멀티 에이전트의 취약점:
    graph TD
        A[Agent 1] -->|불완전한 컨텍스트| Decision1[결정 A]
        B[Agent 2] -->|다른 컨텍스트| Decision2[결정 B]
        Decision1 -.상충.-> Conflict[충돌하는 결과]
        Decision2 -.상충.-> Conflict
    • 컨텍스트 단절: 하위 Agent간 세밀한 컨텍스트 공유 어려움
    • 일관성 문제: 병렬 작업시 상충되는 결정 발생
    • 의사결정 충돌: "행동은 암묵적 결정을 담고, 충돌하는 결정은 나쁜 결과를 초래"