AI 에이전트 의존도를 줄이고 효율성을 높인 실제 사례. 블루프린트 아키텍처로 LLM 호출을 67-91% 감소시킨 방법을 공개합니다.
AI 에이전트 최적화: 완전 자동화에서 하이브리드 시스템으로의 진화
핵심 요약
- 초기 문제: 모든 작업을 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은 모호한 것을 다룬다.
이 원칙을 바탕으로 저는 블루프린트 아키텍처 를 구현했습니다. 블루프린트는 단순히 코드로 작성된 워크플로 차트 입니다.
블루프린트의 구성 요소:
- 노드(Nodes): 각 노드는 단일 작업을 담당
- 노드 간 전환: 조건에 따라 어느 노드로 이동할지 결정
- 트리거 조건: 특정 상황에서만 노드가 실행되도록 제어
- 명시적 오류 처리: 예외 상황에 대한 명확한 대응 방안
실제 예시:
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에게 넘어갈 수도 있습니다.
그렇다면 어떻게 대비해야 할까요?
- 유연한 아키텍처: 작업을 쉽게 이동할 수 있는 설계
- 명확한 경계: 각 역할의 책임을 명확히 정의
- 정기적인 검토: 기술 변화에 따라 아키텍처 재평가
- 성능 모니터링: 각 구성 요소의 효율성 추적
결론적으로:
AI 에이전트 최적화는 일회성 작업이 아닙니다. 지속적인 학습, 모니터링, 개선이 필요한 영역입니다. 블루프린트 아키텍처는 현재의 좋은 솔루션이지만, 미래의 기술 발전에 따라 조정되어야 할 것입니다.
결론
AI에게 모든 것을 맡기는 것에서 시작했지만, 6개월 동안 근본적으로 다른 접근 방식으로 진화했습니다. 블루프린트 아키텍처 를 통해 결정론적 코드와 LLM의 역할을 명확히 분리함으로써, AI의 효율성을 극대화할 수 있었습니다.
핵심은 "AI를 덜 사용하는 것이 아니라, AI를 더 현명하게 사용하는 것" 입니다. 예측 가능한 작업은 빠르고 정확한 코드에 맡기고, AI는 진정으로 필요한 모호한 작업에만 집중시키세요. 이것이 더 빠르고, 저렴하고, 안정적인 시스템을 만드는 길입니다.
지금 바로 여러분의 AI 워크플로를 점검해보세요. 어느 부분이 불필요하게 AI에 의존하고 있는지 찾아내고, 블루프린트 방식으로 재구성해보세요. 이것이 진정한 AI 최적화의 첫걸음 입니다.
Original source: Is AI Doing Less & Less?
powered by osmu.app