How to Build an Agent
TMT올해 거의 모든 회사가 에이전트 구축에 대해 이야기하고 있지만, 실제로 이를 구현한 곳은 훨씬 적습니다. 에이전트가 비즈니스를 어떻게 변화시킬 수 있을지 상상하는 것은 쉽지만, 많은 팀이 어디서 시작해야 할지, 어떻게 진전을 이뤄야 할지, 기대치를 어디에 설정해야 할지 확신하지 못합니다.
이 가이드에서는 아이디어에서 임팩트까지 나아가는 프레임워크를 실제 이메일 에이전트 구축 예시와 함께 살펴봅니다.
1단계: 에이전트의 작업을 예시와 함께 정의하기
현실적이고 에이전트가 필요한 무언가를 선택하세요.
똑똑한 인턴에게 가르칠 수 있는 일을 선택하세요. 최고의 인턴이 충분한 시간과 자원이 주어져도 절대 완수할 수 없는 작업이라면, 그 작업은 비현실적이거나 너무 야심찬 것일 수 있습니다. 전문가 모드를 활성화하기 전에 기본적인 부분을 제대로 할 수 있는지 증명하세요.
작업에 대한 구체적인 예시 5~10개를 먼저 생각해보세요. 이는 두 가지 목적이 있습니다:
- 첫째, 아이디어가 너무 사소하거나 모호하지 않고 잘 범위가 정해졌는지 검증할 수 있습니다.
- 둘째, 나중에 성능을 측정할 수 있는 벤치마크가 됩니다.
예시: 이메일 에이전트 구축
이 단계에서는 에이전트가 처리해야 할 작업을 정의합니다. 예를 들어 다음과 같을 수 있습니다:
- 주요 이해관계자의 긴급 이메일 우선순위 지정
- 캘린더 가용성에 따라 미팅 일정 잡기
- 응답이 필요 없는 스팸 또는 불필요한 이메일 무시
- 회사 문서를 기반으로 제품 질문에 답변
피해야 할 레드 플래그:
- 구체적인 예시를 생각해낼 수 없다면, 범위가 너무 넓을 가능성이 높습니다.
- 기존 소프트웨어로 더 잘 처리할 수 있는 경우(예: 논리가 단순하고 고정되어 있으며 이미 구현된 경우) 에이전트를 사용하는 것. 에이전트는 느리고, 비싸며, 때때로 까다로울 수 있습니다. 기존 소프트웨어로 충분하다면 그걸 사용하세요!
- 존재하지 않거나 구축할 수 없는 API나 데이터셋에 연결하는 등 존재하지 않는 마법을 기대하는 것
2단계: 운영 절차 설계
사람이 해당 작업이나 프로세스를 수행하는 단계별 표준 운영 절차(SOP)를 자세히 작성하세요.
이 단계는 명확하고 합리적인 범위의 문제를 선택했는지 확인하는 데 도움이 됩니다. 또한 에이전트가 처리해야 할 주요 단계, 결정, 도구를 드러내어 무엇을 구축해야 할지 기반을 마련합니다.
예시: 이메일 에이전트 구축
이메일 에이전트의 단계별 절차는 다음과 같을 수 있습니다:
- 이메일 내용과 발신자 맥락을 분석하여 응답 우선순위 분류
- 캘린더 가용성 확인 후 화상 회의 일정 잡기
- 이메일, 발신자, 일정 맥락을 바탕으로 응답 초안 작성
- 빠른 인간 검토 및 승인 후 이메일 발송
이렇게 작성하면 작업의 범위가 적절한지 확인할 수 있고, 에이전트가 다뤄야 할 도구와 논리를 파악할 수 있습니다.
3단계: 프롬프트로 MVP 구축
어디서 시작할지 선택하는 것이 중요합니다. 에이전트가 복잡하다면 한 번에 모두 하려고 하면 너무 야심찹니다. SOP에서 정리한 에이전트 아키텍처(흐름, 필요한 결정, LLM 추론이 필수적인 부분)를 먼저 설계하세요.
그런 다음, 가장 중요한 LLM 추론 작업(예: 분류, 의사결정)에 집중하고 이를 잘 처리하는 프롬프트를 만들어 MVP를 구축하세요. 대부분의 에이전트가 실패하는 이유는 LLM이 작업에 충분히 잘 추론하지 못하기 때문입니다. 수작업으로 데이터를 넣어 단일 프롬프트가 잘 동작하도록 만드는 것이 전체 에이전트 구축 전 자신감을 쌓는 데 도움이 됩니다. LangSmith와 같은 프롬프트 엔지니어링 도구를 사용하면 프롬프트 버전 관리, 다양한 시나리오/데이터셋 테스트, 반복 과정에서 성능 추적이 쉬워집니다.
간단하게 시작하려면:
- 프롬프트에 필요한 데이터나 맥락은 일단 수동 입력으로 시작하세요(자동화는 나중에)
- 1단계에서 정리한 예시로 성능을 검증하세요
- LLM 추론이 제대로 되는지에 집중하세요
예시: 이메일 에이전트 구축
이 단계에서는 우선 가장 영향력 있는 추론 작업 하나를 식별하고 해결합니다.
이메일 에이전트의 경우, 이메일을 긴급도와 의도별로 분류하는 것이 나머지 에이전트가 의존하는 기초 단계일 수 있습니다.
핵심 프롬프트를 작성할 때 다음과 같이 수작업 입력을 활용하세요:
- 이메일 내용: “다음 주에 LangChain 제품 로드맵에 대해 미팅할 수 있을까요?”
- 발신자: “Jeff Bezos”, 직함: “Amazon CEO”
- 출력: 의도 = “미팅 요청”, 긴급도 = “높음”
모델이 다양한 테스트 케이스에서 일관되게 올바른 결과를 내면, 핵심 논리가 탄탄하다는 자신감을 가질 수 있습니다. 그리고 이를 기반으로 확장할 수 있습니다.
4단계: 연결 및 오케스트레이션
이제 동작하는 프롬프트가 준비되었으니, 실제 데이터와 사용자 입력에 프롬프트를 연결할 차례입니다.
프롬프트에 어떤 맥락이나 데이터가 필요한지(예: 이메일 내용, 캘린더 가용성, 제품 문서 등) 파악하고, 이를 프로그래밍적으로 접근하는 방법(API, 데이터베이스, 파일 시스템 등)을 계획하세요.
그런 다음, 프롬프트에 올바른 데이터를 연결하는 오케스트레이션 로직을 작성하세요. 간단한 경우에는 입력을 바로 전달하면 되지만, 더 복잡한 워크플로우에서는 어떤 데이터 소스를 언제 쿼리할지, 출력을 어떻게 결합해 LLM에 전달할지 결정하는 에이전트 로직이 필요할 수 있습니다.
예시: 이메일 에이전트 구축
이메일 에이전트의 경우, Gmail API(수신 이메일 읽기), Google Calendar API(가용성 확인), CRM 또는 연락처 데이터베이스(발신자 맥락 보강)와의 통합이 필요할 수 있습니다.
이후 다음과 같은 오케스트레이션 로직을 구축합니다:
- 새 이메일이 오면 에이전트가 트리거됨
- 에이전트가 CRM 또는 웹 검색을 통해 발신자 정보를 가져옴
- 전체 맥락을 프롬프트에 전달해 긴급도 및 응답 필요 여부 판단
- 미팅이 적절하다면 캘린더 가용성을 확인하고 시간 제안
- 에이전트가 응답 초안 작성
- 인간 검토 후 이메일 발송
5단계: 테스트 및 반복
MVP를 1단계에서 정의한 예시로 수동 테스트하는 것부터 시작하세요. 목표는 핵심 사용 사례에 대해 에이전트가 합리적이고 정확한 출력을 내는지 검증하는 것입니다. 여러 번의 LLM 호출이나 단계가 포함된 시스템이라면, LangSmith와 같은 도구로 트레이싱을 설정해 각 단계의 흐름을 시각화하고 의사결정 과정을 디버깅하는 것이 도움이 됩니다.
수동 테스트가 충분히 안정적이면, 자동화 테스트로 확장해 일관성을 확보하고 엣지 케이스를 잡아내세요. 팀에서는 보통 예시를 수십 개로 늘려 에이전트의 강점과 약점을 더 잘 파악합니다. 이는 더 많은 복잡성을 추가하기 전에 성능을 정량화하는 데도 도움이 됩니다:
- 모든 예시(기존 + 신규)를 프로그램적으로 에이전트에 통과시킴
- 자동화된 성공 지표 정의 — 이는 에이전트의 기대 동작을 명확히 하는 데 필수적입니다
- 지표로 잡히지 않는 문제는 선택적으로 인간 검토를 활용해 잡아냄
예시: 이메일 에이전트 구축
이메일 에이전트의 경우, 다음과 같은 주요 영역에서 성공을 정의하고 테스트해야 합니다:
- 톤과 안전성: 응답은 전문적이고, 존중하며, 환각이나 부적절한 내용이 없어야 함
- 의도 및 우선순위 감지: 이메일이 발신자와 내용에 따라 올바르게 분류되고 우선순위가 지정되어야 함
- 도구 사용 효율성: 에이전트는 필요한 도구만 호출해야 함(예: 일정이 필요 없는 경우 캘린더 확인 생략)
- 초안 품질: 제안된 답변은 입력 맥락에 따라 명확하고, 관련성 있으며, 정확해야 함
6단계: 배포, 확장, 개선
MVP가 안정적으로 동작하면, 범위를 확장하세요 — 새로운 기능, 더 넓은 사용 사례, 심지어 다중 에이전트 워크플로우까지. 새로운 기능이나 통합을 추가할 때마다 5단계의 테스트 과정을 반복해 기존 기능이 깨지지 않는지 확인하세요.
준비가 되면 실제 사용자에게 프로덕션에 배포하세요. LangGraph Platform을 사용하면 에이전트를 원클릭으로 빠르게 배포, 확장, 관리할 수 있습니다.
사람들이 실제로 에이전트를 어떻게 사용하는지 모니터링하세요. LangSmith와 같은 도구를 사용하면 에이전트의 동작을 실시간으로 추적할 수 있어, 비용 급증, 정확도 문제, 지연 현상을 쉽게 파악할 수 있습니다. 실제 사용은 초기 가정과 다를 때가 많으며, 이러한 인사이트는 격차를 드러내고, 예상치 못한 니즈를 발견하며, 다음 반복에서 우선순위를 정하는 데 도움이 됩니다.
중요한 것은 출시를 개발의 끝이 아니라 반복의 시작으로 여기는 것입니다.
예시: 이메일 에이전트 구축
이메일 에이전트를 배포한 후, 트래픽과 일반적인 사용 사례를 모니터링하면서 미처 다루지 못한 사용 사례를 발견할 수 있습니다.
이러한 새로운 패턴은 범위 확장의 기회 신호입니다. 그때마다 새로운 통합을 추가하고, 프롬프트와 오케스트레이션 로직을 업데이트하며, 항상 테스트와 사용자 피드백으로 각 추가 사항을 검증한 후 확장하세요.
결론
이 프로세스는 명확한 사용 사례에 기반하고, 실제 예시로 테스트하며, 실제 피드백에 의해 다듬어지는 에이전트를 만드는 데 도움이 되도록 설계되었습니다. 단순히 에이전트를 동작시키는 것이 아니라, 실제로 유용하고 신뢰할 수 있으며, 사람들이 실제로 일하는 방식에 맞는 것을 만드는 것이 목표입니다.
이메일 분류 자동화든 복잡한 워크플로우 오케스트레이션이든, 이 6단계는 아이디어에서 임팩트로 가는 실용적인 경로를 제공합니다. 하지만 배포가 끝이 아니라는 점을 명심하세요 — 최고의 에이전트는 반복을 통해 만들어집니다.
그러니 작게 시작하고, 사용자 중심을 유지하며, 계속 다듬어가세요.