에이전트 엔지니어링 (Agent Engineering): 새로운 학문 분야

만약 에이전트 (agent)를 구축해 본 적이 있다면, "내 컴퓨터에서는 작동한다"와 "프로덕션 (production) 환경에서 작동한다" 사이의 차이가 매우 클 수 있다는 점을 알고 있을 것입니다. 전통적인 소프트웨어는 입력값을 대부분 알고 있고 출력값을 정의할 수 있다고 가정합니다. 하지만 에이전트는 그 어느 것도 보장하지 않습니다. 사용자는 말 그대로 무엇이든 말할 수 있으며, 가능한 행동의 범위는 매우 넓게 열려 있습니다. 이것이 에이전트가 강력한 이유인 동시에, 예상치 못한 방식으로 빗나갈 수 있는 이유이기도 합니다.

지난 3년 동안, 우리는 수천 개의 팀이 이러한 현실과 씨름하는 것을 지켜보았습니다. Clay, Vanta, LinkedIn, Cloudflare와 같은 기업들처럼 프로덕션에 신뢰할 수 있는 무언가를 출시하는 데 성공한 팀들은 전통적인 소프트웨어 플레이북을 따르지 않습니다. 그들은 새로운 것, 즉 **에이전트 엔지니어링 (agent engineering)**을 개척하고 있습니다.

에이전트 엔지니어링이란 무엇인가?

에이전트 엔지니어링은 비결정론적 (non-deterministic) LLM 시스템을 신뢰할 수 있는 프로덕션 경험으로 정교화하는 반복적인 과정입니다. 이는 **구축, 테스트, 출시, 관찰, 개선, 반복 (build, test, ship, observe, refine, repeat)**의 순환적인 과정입니다.

여기서 핵심은 출시 (shipping)가 최종 목표가 아니라는 점입니다. 그것은 단지 새로운 통찰력을 얻고 에이전트를 개선하기 위해 계속 나아가는 방법일 뿐입니다. 의미 있는 개선을 이루기 위해서는 프로덕션에서 어떤 일이 일어나고 있는지 이해해야 합니다. 이 사이클을 더 빠르게 통과할수록 에이전트는 더욱 신뢰할 수 있게 됩니다.

우리는 에이전트 엔지니어링을 함께 작동하는 3가지 기술 세트가 결합된 새로운 학문 분야로 보고 있습니다:

**제품 사고 (Product thinking)**는 범위를 정의하고 에이전트의 행동을 형성합니다. 여기에는 다음이 포함됩니다:

• 에이전트의 행동을 유도하는 프롬프트 (prompts) 작성 (종종 수백 또는 수천 줄에 달함). 여기서 좋은 커뮤니케이션과 작문 능력이 핵심입니다.
• 에이전트가 복제하는 "수행해야 할 과업 (job to be done)"에 대한 깊은 이해
• 에이전트가 "수행해야 할 과업"에 따라 의도한 대로 수행하는지 테스트하는 평가 (evaluations) 정의

**엔지니어링 (Engineering)**은 에이전트를 프로덕션 환경에 적용할 수 있도록 인프라를 구축합니다. 여기에는 다음 사항이 포함됩니다:

• 에이전트가 사용할 도구 (tools) 작성
• 에이전트 상호작용을 위한 UI/UX 개발 (스트리밍 (streaming), 인터럽트 처리 (interrupt handling) 등 포함)
• 지속 가능한 실행 (durable execution), 인간 참여형 일시 중지 (human-in-the-loop pauses), 메모리 관리 (memory management)를 처리하는 견고한 런타임 (runtimes) 생성

**데이터 과학 (Data science)**은 시간이 지남에 따라 에이전트의 성능을 측정하고 개선합니다. 여기에는 다음 사항이 포함됩니다:

• 에이전트의 성능과 신뢰성을 측정하기 위한 시스템 (평가 (evals), A/B 테스트, 모니터링 등) 구축
• 사용 패턴 분석 및 에러 분석 (에이전트는 전통적인 소프트웨어보다 사용자가 사용하는 방식의 범위가 더 넓기 때문)

두 가지 근본적인 변화가 에이전트 엔지니어링 (Agent Engineering)을 필연적으로 만들었습니다.

첫째, LLM (Large Language Models)은 복잡하고 다단계인 워크플로우 (workflows)를 처리할 수 있을 만큼 강력합니다. 우리는 에이전트가 단순한 태스크 (tasks)를 넘어 직무 전체를 수행하는 것을 목격하고 있습니다. Clay는 잠재 고객 조사부터 개인화된 아웃리치 (outreach) 및 CRM 업데이트에 이르기까지 모든 과정을 처리하기 위해 에이전트를 사용합니다. LinkedIn은 채용을 위해 방대한 인재 풀을 스캔하고, 후보자의 순위를 매기며, 가장 적합한 매칭 결과를 즉시 제시하는 데 에이전트를 활용합니다. 우리는 에이전트가 실제 운영 환경 (production)에서 의미 있는 비즈니스 가치를 전달하는 임계점을 넘어서기 시작했습니다.

둘째, 그러한 강력함에는 실제적인 예측 불가능성이 수반됩니다. 단순한 LLM 앱은 비결정론적 (non-deterministic)이긴 하지만, 비교적 통제된 동작을 보이는 경향이 있습니다. 에이전트는 다릅니다. 에이전트는 여러 단계에 걸쳐 추론하고, 도구 (tools)를 호출하며, 문맥 (context)에 따라 적응합니다. 에이전트를 유용하게 만드는 바로 그 요소들이 에이전트를 전통적인 소프트웨어와 다르게 동작하게 만듭니다. 이는 보통 다음과 같은 의미를 갖습니다:

모든 입력이 엣지 케이스 (edge case)입니다. 사용자가 자연어로 무엇이든 물어볼 수 있는 상황에서는 "정상적인" 입력이라는 것이 존재하지 않습니다. 사용자가 "눈에 띄게 만들어줘" 또는 "지난번처럼 하되 이번에는 다르게 해줘"라고 입력할 때, 에이전트는 (사람과 마찬가지로) 프롬프트 (prompts)를 다양한 방식으로 해석할 수 있습니다.

기존 방식으로는 디버깅 (debug)할 수 없습니다. 너무 많은 로직이 모델 내부에 존재하기 때문에, 각 결정과 도구 호출 (tool call)을 일일이 검사해야 합니다. 작은 프롬프트나 설정 (config)의 미세한 조정만으로도 동작에 거대한 변화를 일으킬 수 있습니다.

"작동 여부"가 이진법적이지 않습니다. 에이전트는 99.99%의 업타임 (uptime)을 유지하면서도, 통제를 벗어나 망가져 있을 수 있습니다. 에이전트가 올바른 결정을 내리고 있는가? 도구를 올바른 방식으로 사용하고 있는가? 지시 사항 뒤에 숨겨진 의도를 따르고 있는가? 와 같이 중요한 질문들에 대해 항상 단순한 예/아니오 식의 답이 나오는 것은 아닙.

이 모든 것을 종합해 볼 때 — 에이전트가 실제 영향력이 큰 워크플로우를 실행하면서도 전통적인 소프트웨어로는 해결할 수 없는 방식으로 동작한다는 점 — 새로운 학문 분야에 대한 기회와 필요성이 존재합니다. 에이전트 엔지니어링은 LLM의 강력한 힘을 활용하는 동시에, 실제 운영 환경에서 진정으로 신뢰할 수 있는 시스템을 구축할 수 있게 해줍니다.

에이전트 엔지니어링은 실제로 어떤 모습인가요?

에이전트 엔지니어링은 전통적인 소프트웨어 개발과는 다른 원칙에 따라 작동합니다. 신뢰할 수 있는 에이전트 시스템을 구축하기 위해서는, 배포(shipping)가 학습을 마친 후에 하는 일이 아니라, 학습을 하기 위한 방법이 되어야 합니다.

성공적인 엔지니어링 팀들이 다음과 같은 리듬(cadence)을 따르며 에이전트를 개발하는 것을 목격했습니다:

에이전트의 기반을 구축하세요. 도구(tools)를 사용하는 간단한 LLM 호출부터 복잡한 멀티 에이전트 시스템(multi-agent system)에 이르기까지, 에이전트의 기반을 설계하는 것부터 시작하세요. 여러분의 아키텍처(architecture)는 워크플로우(workflow, 결정론적인 단계별 프로세스)와 에이전시(agency, LLM 기반의 의사결정)를 어느 정도 비율로 필요로 하는지에 따라 달라집니다.

상상할 수 있는 시나리오를 기반으로 테스트하세요. 프롬프트(prompts), 도구 정의(tool definitions), 그리고 워크플로우의 명백한 문제들을 포착하기 위해 예시 시나리오를 바탕으로 에이전트를 테스트하세요. 사용자 흐름(user flows)을 설계할 수 있는 전통적인 소프트웨어와 달리, 사용자가 자연어 입력(natural language input)과 상호작용하는 모든 방식을 예측할 수는 없습니다. "철저히 테스트한 후 배포한다"는 사고방식에서 "적절히 테스트하고, 실제로 무엇이 중요한지 배우기 위해 배포한다"는 사고방식으로 전환하세요.

실제 환경의 동작을 확인하기 위해 배포하세요. 배포하고 나면, 미처 고려하지 못했던 입력값들을 즉시 목격하게 될 것이며, 모든 프로덕션 트레이스(production trace)는 에이전트가 실제로 무엇을 처리해야 하는지를 보여줍니다.

관찰하세요. 모든 상호작용을 추적(trace)하여 전체 대화 내용, 호출된 모든 도구, 그리고 에이전트가 내린 각 결정의 근거가 된 정확한 컨텍스트(context)를 확인하세요. 정확도(accuracy), 지연 시간(latency), 사용자 만족도(user satisfaction) 또는 기타 기준에 상관없이, 에이전트의 품질을 측정하기 위해 프로덕션 데이터에 대해 평가(evals)를 실행하세요.

개선하세요. 무엇이 실패하고 있는지에 대한 패턴을 파악했다면, 프롬프트를 편집하고 도구 정의를 수정함으로써 개선하세요. 이 과정은 모두 연속적입니다. 문제가 된 사례들을 회귀 테스트(regression testing)를 위한 예시 시나리오 세트에 다시 추가할 수 있기 때문입니다.

반복하세요. 개선 사항을 배포하고 프로덕션에서 무엇이 변하는지 관찰하세요. 각 사이클은 사용자가 에이전트와 어떻게 상호작용하는지, 그리고 여러분의 맥락에서 신뢰성(reliability)이 실제로 무엇을 의미하는지에 대해 새로운 것을 가르쳐 줍니다.

엔지니어링을 위한 새로운 표준

오늘날 신뢰할 수 있는 에이전트(agents)를 출시하는 팀들은 한 가지 공통점을 공유합니다. 그들은 출시 전에 에이전트를 완벽하게 만들려고 노력하는 것을 멈추고, 프로덕션(production) 환경을 주요 스승으로 삼기 시작했습니다. 다시 말해, 모든 결정을 추적(tracing)하고, 대규모로 평가(evaluating)하며, 분기 단위가 아닌 며칠 단위로 개선 사항을 배포(shipping)하는 것입니다.

에이전트 엔지니어링(Agent engineering)이 부상하는 이유는 그 기회가 이를 요구하기 때문입니다. 에이전트는 이제 이전에 인간의 판단이 필요했던 워크플로(workflows)를 처리할 수 있지만, 이는 여러분이 에이전트를 신뢰할 수 있을 만큼 충분히 신뢰성(reliable) 있게 만들 수 있을 때만 가능합니다. 지름길은 없으며, 오직 반복(iteration)이라는 체계적인 작업만이 존재합니다. 문제는 에이전트 엔지니어링이 표준 관행이 될 것인가가 아닙니다. 여러분의 팀이 에이전트의 잠재력을 끌어내기 위해 얼마나 빨리 이를 도입할 수 있느냐입니다.