전통적인 산업 소프트웨어의 지능화 작업을 오랫동안 진행해왔습니다. 처음에는 LLM이 JSON 데이터를 생성하여 소프트웨어가 파싱하도록 만들었고, 점차 전체 업무 프로세스를 에이전트가 처리하고 사람이 중간 결과를 확인하는 방식으로 발전했습니다. 이제는 에이전트가 완전한 작업을 수행하도록 진화했으며, 이 과정에서 여러 어려움을 겪고 혼란을 해소했습니다. 현재 에이전트에 대한 생각을 기록합니다.
일, 에이전트 개발의 핵심 패러다임: 워크플로우
개인적 이해: 모든 에이전트는 워크플로우입니다 공학적 실무에서 에이전트는 "자유로운 사고의 블랙박스"가 아니라, 제약된 프로세스 노드(Executor)로 구성된 방향성 그래프입니다.
1.1 단순 워크플로우(명시적 프로세스 오케스트레이션)
이것은 가장 일반적이면서도 가장 안정적인 에이전트 설계 방식입니다.
기본 개념
- 복잡한 목표를 고정된 순서의 하위 작업으로 분해
- 각 하위 작업은 단일 책임을 가지며 입력과 출력이 명확해야 함
- 워크플로우를 통해 실행 순서를 명시적으로 연결
전형적인 구조
거시적 워크플로우:
요구사항 입력
→ 작업 분해
→ 구조화 모델링
→ 결과 생성
중첩된 하위 워크플로우(예: 작업 분해):
엔티티 추출
→ 엔티티 보완
→ 엔티티 관계 인식
→ 시나리오 요약
장점
- 예측 가능한 행동 패턴
- 디버깅 및 추적이 용이함
- 고 신뢰성, 강 제약 업무 환경에 적합
한계
- 유연성이 제한적
- 알려지지 않은 문제에 대한 일반화 능력이 약함
1.2 일반 워크플로우: ReACT 패러다임
문제 공간이 더 개방적이 되면 단순 워크플로우는 너무 딱딱하게 느껴질 수 있습니다. 이때 ReACT(Reasoning + Acting) 아키텍처를 도입할 수 있습니다.
ReACT 핵심 루프
사고(Thought) → 행동(Action) → 관찰(Observation) → 사고(Thought)
- 사고: 현재 상태 분석, 다음 단계 결정
- 행동: 도구 또는 하위 시스템 호출
- 관찰: 실행 결과 수집
- 판단: 목표 달성 여부 판단 또는 다음 루프 진입
장점
- 적응성이 높음
- 비구조화된 동적 문제 처리 가능
- '탐색형' 작업에 매우 적합
공학적 현실
실제 시스템에서는 순수 ReACT는 거의 단독으로 사용되지 않으며, 다음과 같은 형태가 더 일반적입니다:
ReACT + 워크플로우 쉘
즉:
- 외부 레이어는 제어된 워크플로우
- 내부 레이어의 일부 노드는 ReACT 능력을 가짐
이, 주요 에이전트 오픈소스 프레임워크의 공학적 관점
공학적 유지보수성을 데모 경험보다 우선시할 때, 일반적인 프레임워크에 대한 인상은 다음과 같습니다:
| 프레임워크 | 공학적 평가 |
|---|---|
| LangChain | 추상화가 복잡하여 디버깅 비용이 높음 |
| AutoGen / Agent Framework | 코드 구조가 직관적이며 복잡한 에이전트에 적합 |
| LlamaIndex | 빠르게 시작할 수 있으나 지식 검색에 특화되어 에이전트 기능이 약함 |
경험적 결론:
에이전트 프레임워크는 "모든 것을 대신 해결"해서는 안 되며, 워크플로우 설계를 지원하는 역할을 해야 합니다.
삼, 복잡한 분석형 에이전트의 워크플로우 설계 실천
3.1 시나리오 추상화
시뮬레이션 / 의사결정 / 분석 시스템의 일부에서 에이전트의 목표는 다음과 같습니다:
입력된 상황을 기반으로 다단계 분석을 자동으로 수행하고 구조화된 결과 체인을 생성합니다.
이러한 문제의 특징은 다음과 같습니다:
- 다중 엔티티
- 다중 제약 조건
- 강력한 논리적 순서
- 반성 및 역추적 능력 필요
3.2 워크플로우 분해 원칙
(1) 엔티티 처리: 단순 워크플로우
엔티티 관련 작업은 순차적이고 결정론적인 프로세스에 매우 적합합니다.
예시 코드(추상화됨):
def build_entity_processing_workflow():
"""
EntityExtractor -> CoreferenceResolver -> EquipmentQuery
-> EntityClassifier -> MatrixBuilder
"""
entity_extractor = DataExtractor(id="data_extractor")
coreference_resolver = ReferenceResolver(id="reference_resolver")
equipment_query = EquipmentFinder(id="equipment_finder")
entity_classifier = TypeClassifier(id="type_classifier")
matrix_builder = RelationMatrix(id="relation_matrix")
workflow = (
ProcessBuilder()
.add_step(entity_extractor, coreference_resolver)
.add_step(coreference_resolver, equipment_query)
.add_step(equipment_query, entity_classifier)
.add_step(entity_classifier, matrix_builder)
.set_start_point(entity_extractor)
.construct()
)
return workflow
설계 핵심 포인트:
- 각 Executor는 단일 작업만 수행
- 출력은 반드시 구조화되어야 함
- "자유로운 발휘"를 허용하지 않음
(2) 작업 분해: 반성 능력이 있는 워크플로우
작업 분해는 에이전트가 가장 쉽게 통제를 벗어나는 부분이므로 다음과 같은 요소가 필요합니다:
- 반복 횟수 상한
- 원자 작업 보장
- 반성 및 중단 메커니즘
간소화된 로직은 다음과 같습니다:
iteration = 0
max_iterations = 5
while current_tasks and iteration < max_iterations:
iteration += 1
new_tasks = []
for task in current_tasks:
is_atomic, method, sub_tasks, llm_result = analyze_task(task)
if is_atomic:
mark_as_atomic(task, llm_result)
else:
record_approach(task, method)
new_tasks.extend(sub_tasks)
current_tasks = new_tasks
핵심 경험:
- 모델이 "스스로 멈출 것"이라고 믿지 마세요
- 각 루프에는 양적화 가능한 수렴 조건이 있어야 함
- 원자 작업은 명확하게 정의되어야 함
3.3 에이전트 프레임워크 요구 능력 요약
복잡한 워크플로우에서 에이전트 프레임워크는 최소한 다음을 지원해야 합니다:
- 순차 실행
- 병렬 실행
- 조건 분기
- 결과 반성 / 롤백
- 관찰 가능한 중간 상태
그렇지 않으면 에이전트는 "매우 똑아 보이지만 실제 서비스에 적용할 수 없는 데모"에 불과합니다.
사, 요약: 공학적 관점에서 본 에이전트 설계 원칙
- 자유로운 추론보다 결정론적 프로세스를 우선시
- 반성 능력은 반드시 명시적으로 설계해야 함, 에이전트 프레임워크 내장 반성 메커니즘에 의존하지 말 것 (본질적으로 프롬프트이며 특정 작업에 최적화되지 않음)