# AI 에이전트 최적화: 65% 코드 기반 워크플로 구축 방법

> 2026-03-04 · Tom Tunguz · 큐레이션 김태우
> https://challengekim.com/insights/ai-agent-optimization-code-based-workflow-65-percent-reduction-ko
> 원문: https://www.tomtunguz.com/hybrid-state-machine-agents/

## 핵심 요약

- **초기 문제**: 모든 작업을 LLM에 의존하면 정확도와 비용 문제 발생
- **해결책**: 결정론적 코드와 LLM을 명확히 분리한 블루프린트 아키텍처 도입
- **성과**: 워크플로의 65%를 코드 기반으로 전환, LLM 호출 67-91% 감소
- **핵심 원칙**: AI는 모호한 작업만 담당, 예측 가능한 작업은 코드로 처리

## AI 에이전트의 함정: 왜 모든 것을 AI에게 맡기면 안 되는가

처음에는 매우 간단했습니다. 모든 작업을 LLM에 맡겼거든요. 아이디어는 명확했습니다. **AI가 모든 결정을 내리고, 모든 작업을 수행하도록 하자** 는 것이었죠.

하지만 현실은 달랐습니다. LLM이 항상 정확한 것은 아니었습니다. 때로는 자신감 있게 틀린 답변을 제공하기도 했습니다. 이는 비용 증가, 예측 불가능한 동작, 오류 처리의 어려움으로 이어졌습니다.

**문제점들:**

- **비용**: 모든 작업에 LLM 호출이 필요하면 API 비용이 기하급수적으로 증가
- **신뢰성**: AI의 판단이 항상 정확하지 않아 잘못된 결과 발생 가능
- **속도**: 불필요한 LLM 호출로 인한 처리 지연
- **제어 불가능**: AI가 예상치 못한 경로로 진행될 수 있음

이 모든 문제를 해결하기 위해 저는 새로운 접근방식을 시작했습니다. **AI의 능력을 제한하되, 효과를 극대화** 하는 방법을 찾아야 했던 것입니다.

## 첫 번째 시도: AI 도구 제한 및 디스커버리 시스템

초기 문제를 인식한 후, 저는 **LLM이 호출할 수 있는 도구를 명시적으로 제한** 하기로 결정했습니다. 이는 간단하지만 효과적인 접근법이었습니다.

LLM이 특정 함수나 API만 사용하도록 강제하는 것입니다. 예를 들어, "데이터베이스 쿼리", "이메일 전송", "파일 저장" 같은 제한된 도구 세트만 허용했습니다.

**이 방식의 장점:**

- AI가 무분별하게 작동하는 것을 방지
- 예측 가능한 범위 내에서만 동작
- 오류 처리가 더 쉬워짐

하지만 여전히 부족했습니다. **AI가 어떤 도구를 사용해야 할지 알 수 없었기 때문입니다.** 이 문제를 해결하기 위해 **Discovery 도구** 를 추가했습니다. 이 도구를 통해 AI는 사용 가능한 도구들을 스스로 발견하고, 필요한 도구를 선택할 수 있게 되었습니다.

**그 결과:**

- 더 지능적인 도구 선택
- 자동화 범위 확대
- 하지만 여전히 근본적인 해결책은 아니었음

더 나은 방법이 필요했습니다. 그리고 바로 그때 **Stripe의 미니언 아키텍처** 를 발견했습니다.

## 블루프린트 아키텍처: 결정론적 코드 vs AI의 명확한 분리

Stripe 팀이 제시한 통찰력은 매우 간단하지만 강력했습니다:

> **결정론적 코드는 예측 가능한 것을 처리하고, LLM은 모호한 것을 다룬다.**

이 원칙을 바탕으로 저는 **블루프린트 아키텍처** 를 구현했습니다. 블루프린트는 단순히 **코드로 작성된 워크플로 차트** 입니다.

**블루프린트의 구성 요소:**

1. **노드(Nodes)**: 각 노드는 단일 작업을 담당
2. **노드 간 전환**: 조건에 따라 어느 노드로 이동할지 결정
3. **트리거 조건**: 특정 상황에서만 노드가 실행되도록 제어
4. **명시적 오류 처리**: 예외 상황에 대한 명확한 대응 방안

**실제 예시:**

```
extract_domain (code) → attio_find (code) → harmonic_enrich (code)
    → generate_summary (LLM, 1 turn) → notion_prepend (code)
```

이 워크플로를 보면:

- **extract_domain**: 코드로 도메인 추출 (예측 가능)
- **attio_find**: 코드로 데이터베이스 검색 (결정론적)
- **harmonic_enrich**: 코드로 데이터 보강 (규칙 기반)
- **generate_summary**: LLM으로 요약 생성 (1회만 호출, 모호한 작업)
- **notion_prepend**: 코드로 Notion에 저장 (예측 가능)

**블루프린트 vs 스킬의 차이:**

- **스킬**: LLM에게 "이런 도구를 사용할 수 있어"라고 알려줌
- **블루프린트**: 시스템에게 "LLM을 언제 개입시켜야 하는지"를 지정함

이는 **근본적으로 다른 접근방식** 입니다. 블루프린트는 전체 워크플로의 구조를 코드로 정의함으로써, **AI가 개입할 부분을 명확히 한정** 합니다.

## 워크플로 분류: 각 카테고리별 AI 의존도 분석

블루프린트 아키텍처를 도입한 후, 전체 워크플로를 분석했습니다. 그 결과는 매우 흥미로웠습니다.

### 1. 거래 파이프라인 업데이트, 채팅 메시지, 이메일 라우팅 (29%)

**특징**: **LLM 호출 0회**

이 카테고리의 작업들은 완전히 예측 가능합니다:

- 거래 파이프라인 업데이트: "A 상태에서 B 상태로 변경" → 규칙 기반 코드로 처리
- 채팅 메시지 라우팅: "키워드에 따라 올바른 담당자에게 전달" → 조건 분기로 처리
- 이메일 라우팅: "발신자, 제목, 내용에 따라 분류 및 전달" → 정규표현식과 규칙으로 처리

**왜 AI가 필요 없는가?**

- 명확한 규칙이 존재
- 예외 상황이 적음
- 속도가 중요
- 비용 최적화 가능

**코드 기반 실행 비율**: **100%**

### 2. 회사 조사, 뉴스레터 처리, 인물 조사 (36%)

**특징**: **LLM 호출 67-91% 감소**

이 카테고리는 **제한된 AI 개입** 이 필요합니다:

- **추출 단계**: 코드로 웹 페이지 크롤링, 텍스트 파싱 → 결정론적
- **요약 단계**: LLM으로 정보 요약 및 분류 → 1\~3회 호출만 필요
- **저장 단계**: 코드로 데이터베이스에 저장 → 결정론적

**구체적인 예:**
```

1. 회사명 추출 (코드) → 공개 API에서 기본 정보 조회 (코드)
2. 뉴스레터 본문 파싱 (코드) → 주요 내용 요약 (LLM 1회)
3. 인물 정보 스크래핑 (코드) → 직급/경력 분류 (LLM 1회)
4. 모든 정보를 구조화된 형식으로 저장 (코드)

```

**워크플로 구성**: **67-91% 코드, 9-33% LLM**

이 방식의 핵심은 **LLM이 봐야 할 것을 명확히 제한** 하는 것입니다. AI는 미리 처리된 데이터만 받으므로, 더 정확하고 빠른 결과를 제공할 수 있습니다.

### 3. 블로그 게시물, 문서 분석, 버그 수정 (21%)

**특징**: **진정한 하이브리드 워크플로**

이 카테고리는 **AI와 코드가 모두 중요한 역할** 을 합니다:

- **블로그 게시물 작성**: 아이디어 생성(LLM) → 구조화(코드) → 콘텐츠 개선(LLM) → 형식화(코드)
- **문서 분석**: 문서 로드(코드) → 핵심 내용 추출(LLM) → 검증(코드) → 요약(LLM)
- **버그 수정**: 에러 로그 파싱(코드) → 원인 분석(LLM) → 코드 생성(LLM) → 테스트(코드)

**특징:**

- **여러 LLM 호출**: 품질 향상을 위해 2\~5회 반복
- **점진적 개선**: 각 단계에서 코드가 결과 검증
- **동적 분기**: 이전 단계의 결과에 따라 다음 단계 결정

**워크플로 구성**: **약 50% 코드, 50% LLM** (반복 포함)

### 4. 데이터 변환 및 오류 조사 (14%)

**특징**: **완전히 에이전트 기반**

이 카테고리는 **완전한 자유도** 가 필요합니다:

- **데이터 변환**: 예측 불가능한 형식의 데이터를 처리
- **오류 조사**: 왜 문제가 발생했는지 탐색적으로 진단

**왜 AI의 자유도가 필요한가?**

- 문제가 사전에 정의되지 않음
- 여러 가능성을 탐색해야 함
- 일반적인 규칙을 적용할 수 없음

**LLM 의존도**: **높음 (70-100%)**

## 변화의 결과: AI가 덜 일하지만, 시스템은 더 많이 일한다

6개월 전과 비교하면 극적인 변화가 있었습니다.

### AI의 역할 변화

**이전**: 모든 작업 담당

- 라우팅 결정
- 도구 선택
- 데이터 처리
- 오류 처리
- 코드 작성

**현재**: 전략적 작업만 담당

- **라우팅**: 어디로 전달할지 결정 (남음)
- **예외 처리**: 예상 밖의 상황 판단 (남음)
- **조사**: 왜 문제가 발생했는지 분석 (남음)
- **계획**: 새로운 워크플로 설계 (남음)
- **코딩**: 복잡한 로직 구현 (남음)

**제거된 것**:

- ❌ 예측 가능한 라우팅 결정
- ❌ 구조화된 데이터 추출
- ❌ 규칙 기반 분류
- ❌ 데이터베이스 조회
- ❌ 표준 형식의 데이터 처리

### 시스템의 역할 강화

코드가 담당하게 된 새로운 역할들:

- **데이터 검증**: 입력값이 올바른지 확인
- **조건 분기**: 복잡한 조건에 따라 경로 결정
- **에러 처리**: 예상된 예외 상황 대응
- **성능 최적화**: 불필요한 API 호출 방지
- **감사 추적**: 모든 단계 기록

### 수치로 보는 효과

**LLM 호출 감소:**

- 카테고리 1 (29%): 0% → 100% 코드 기반
- 카테고리 2 (36%): 67-91% → 코드 기반
- 카테고리 3 (21%): 50% 코드 기반 유지
- 카테고리 4 (14%): 높은 LLM 의존도 (필요)

**전체 워크플로:**

- **초기**: 95% 이상 LLM 호출
- **현재**: 35% 이상 LLM 호출로 감소
- **개선율**: 약 60% 감소

## AI 아키텍처의 미래: 지속적인 진화의 필요성

하지만 중요한 것을 기억해야 합니다.

**블루프린트, 도구, 기술은 일시적인 발판일 수 있습니다.**

새로운 모델이 출시될 때마다 가능성이 확장됩니다. GPT-3에서 GPT-4로 넘어갔을 때 많은 것이 달라졌습니다. 마찬가지로 다음 세대 모델이 출시되면 또 다른 변화가 필요할 것입니다.

**현재의 예시들이 미래에도 유효할까요?**

6개월 전에는 **결정론적 코드가 필수** 였던 작업들이 내일은 그렇지 않을 수 있습니다. AI가 더 똑똑해지면, 일부 작업은 다시 LLM에게 넘어갈 수도 있습니다.

**그렇다면 어떻게 대비해야 할까요?**

1. **유연한 아키텍처**: 작업을 쉽게 이동할 수 있는 설계
2. **명확한 경계**: 각 역할의 책임을 명확히 정의
3. **정기적인 검토**: 기술 변화에 따라 아키텍처 재평가
4. **성능 모니터링**: 각 구성 요소의 효율성 추적

**결론적으로:**

AI 에이전트 최적화는 **일회성 작업이 아닙니다.** 지속적인 학습, 모니터링, 개선이 필요한 영역입니다. 블루프린트 아키텍처는 현재의 좋은 솔루션이지만, 미래의 기술 발전에 따라 조정되어야 할 것입니다.

## 결론

AI에게 모든 것을 맡기는 것에서 시작했지만, 6개월 동안 근본적으로 다른 접근 방식으로 진화했습니다. **블루프린트 아키텍처** 를 통해 결정론적 코드와 LLM의 역할을 명확히 분리함으로써, AI의 효율성을 극대화할 수 있었습니다.

핵심은 **"AI를 덜 사용하는 것이 아니라, AI를 더 현명하게 사용하는 것"** 입니다. 예측 가능한 작업은 빠르고 정확한 코드에 맡기고, AI는 진정으로 필요한 모호한 작업에만 집중시키세요. 이것이 더 빠르고, 저렴하고, 안정적인 시스템을 만드는 길입니다.

지금 바로 여러분의 AI 워크플로를 점검해보세요. 어느 부분이 불필요하게 AI에 의존하고 있는지 찾아내고, 블루프린트 방식으로 재구성해보세요. 이것이 **진정한 AI 최적화의 첫걸음** 입니다.

---

원문을 바탕으로 AI 가 한국어로 요약·재구성한 글입니다. 인용·수치는 원문 링크에서 확인해 주세요. [원문 링크](https://www.tomtunguz.com/hybrid-state-machine-agents/)