2025년 12월 9일
에이전트를 구축해 본 경험이 있다면, “내 컴퓨터에서는 작동한다”와 “프로덕션에서 작동한다” 사이의 간극이 얼마나 큰지 알 것입니다. 전통적인 소프트웨어는 입력값을 대부분 알고 있으며 출력값을 정의할 수 있다고 가정합니다. 하지만 에이전트는 둘 다 제공하지 않습니다. 사용자는 말 그대로 무엇이든 말할 수 있고, 가능한 동작의 범위는 완전히 열려 있습니다. 바로 이것이 에이전트가 강력한 이유이며, 동시에 예상치 못한 방식으로 약간 빗나갈 수 있는 이유이기도 합니다.
지난 3년 동안 우리는 수천 개의 팀이 이러한 현실과 씨름하는 것을 지켜봤습니다. Clay, Vanta, LinkedIn, Cloudflare와 같은 기업들처럼 프로덕션에 안정적인 무언가를 출시하는 데 성공한 팀들은 전통적인 소프트웨어 플레이북을 따르지 않습니다. 그들은 새로운 것을 개척하고 있습니다: 에이전트 엔지니어링.
에이전트 엔지니어링이란 무엇인가?
에이전트 엔지니어링은 비결정적 LLM 시스템을 안정적인 프로덕션 경험으로 정제하는 반복적 프로세스입니다. 이것은 순환적 프로세스입니다: 구축, 테스트, 출시, 관찰, 개선, 반복.
여기서 핵심은 출시가 최종 목표가 아니라는 것입니다. 출시는 단지 새로운 인사이트를 얻고 에이전트를 개선하기 위해 계속 나아가는 방법일 뿐입니다. 중요한 개선을 하려면 프로덕션에서 무슨 일이 일어나고 있는지 이해해야 합니다. 이 사이클을 더 빠르게 순환할수록 에이전트는 더욱 안정적이 됩니다.
우리는 에이전트 엔지니어링을 함께 작동하는 3가지 스킬셋을 결합한 새로운 분야로 봅니다:
- 제품 사고는 범위를 정의하고 에이전트 동작을 형성합니다. 여기에는 다음이 포함됩니다:
- 에이전트 동작을 주도하는 프롬프트 작성(종종 수백 또는 수천 줄). 여기서는 뛰어난 커뮤니케이션과 작문 능력이 핵심입니다.
- 에이전트가 복제하는 “완수해야 할 작업”에 대한 깊은 이해
- “완수해야 할 작업”의 의도대로 에이전트가 수행하는지 테스트하는 평가 정의
- 엔지니어링은 에이전트를 프로덕션 준비 상태로 만드는 인프라를 구축합니다. 여기에는 다음이 포함됩니다:
- 에이전트가 사용할 도구 작성
- 에이전트 상호작용을 위한 UI/UX 개발(스트리밍, 인터럽트 처리 등)
- 지속 가능한 실행, 휴먼-인-더-루프 일시 중지, 메모리 관리를 처리하는 견고한 런타임 생성
- 데이터 사이언스는 시간이 지남에 따라 에이전트 성능을 측정하고 개선합니다. 여기에는 다음이 포함됩니다:
- 에이전트 성능과 안정성을 측정하는 시스템(평가, A/B 테스팅, 모니터링 등) 구축
- 사용 패턴 분석 및 오류 분석(에이전트는 전통적인 소프트웨어보다 사용자가 사용하는 방식의 범위가 더 넓기 때문)
에이전트 엔지니어링이 나타나는 곳
에이전트 엔지니어링은 새로운 직함이 아닙니다. 대신, 추론하고, 적응하며, 예측 불가능하게 동작하는 시스템을 구축할 때 기존 팀이 맡게 되는 일련의 책임입니다. 오늘날 안정적인 에이전트를 출시하는 조직들은 엔지니어링, 제품, 데이터 팀의 기술을 확장하여 비결정적 시스템의 요구사항을 충족시키고 있습니다.
실무에서 이러한 실천이 일반적으로 나타나는 곳은 다음과 같습니다:
- 소프트웨어 엔지니어와 ML 엔지니어는 프롬프트를 작성하고 에이전트가 사용할 도구를 구축하며, 에이전트가 특정 도구 호출을 한 이유를 추적하고, 기본 모델을 개선합니다
- 플랫폼 엔지니어는 지속 가능한 실행과 휴먼-인-더-루프 워크플로를 처리하는 에이전트 인프라를 구축합니다
- 제품 매니저는 프롬프트를 작성하고, 에이전트 범위를 정의하며, 에이전트가 올바른 문제를 해결하도록 보장합니다
- 데이터 사이언티스트는 에이전트 안정성을 측정하고 개선 기회를 식별합니다
이러한 팀들은 빠른 반복을 수용하며, 소프트웨어 엔지니어가 오류를 추적하고 그 인사이트를 바탕으로 프롬프트를 조정하도록 PM에게 인계하거나, PM이 엔지니어에게 새로운 도구가 필요한 범위 문제를 식별하는 것을 자주 볼 수 있습니다. 각자는 에이전트를 강화하는 실제 작업이 프로덕션 동작을 관찰하고 학습한 내용을 바탕으로 체계적으로 개선하는 이 사이클을 통해 이루어진다는 것을 인식합니다.
왜 에이전트 엔지니어링이고, 왜 지금인가?
두 가지 근본적인 변화가 에이전트 엔지니어링을 필요하게 만들었습니다.
첫째, LLM은 복잡한 다단계 워크플로를 처리할 수 있을 만큼 강력해졌습니다. 우리는 에이전트가 단순한 작업이 아닌 전체 업무를 처리하는 것을 목격해 왔습니다. Clay는 에이전트를 사용하여 잠재 고객 조사부터 개인화된 아웃리치, CRM 업데이트까지 모든 것을 처리합니다. LinkedIn은 에이전트를 사용하여 대규모 인재 풀을 스캔하여 채용하고, 후보자의 순위를 매기며, 가장 강력한 매치를 즉시 표면화합니다. 우리는 에이전트가 프로덕션에서 의미 있는 비즈니스 가치를 제공하는 임계점을 넘기 시작하고 있습니다.
둘째, 그 힘에는 실질적인 예측 불가능성이 따릅니다. 단순한 LLM 앱은 비결정적이지만 더 제한된 동작을 보이는 경향이 있습니다. 에이전트는 다릅니다. 여러 단계에 걸쳐 추론하고, 도구를 호출하며, 컨텍스트에 따라 적응합니다. 에이전트를 유용하게 만드는 바로 그것들이 에이전트를 전통적인 소프트웨어와 다르게 동작하게 만듭니다. 이것은 일반적으로 다음을 의미합니다:
- 모든 입력이 엣지 케이스입니다. 사용자가 자연어로 무엇이든 질문할 수 있을 때 “정상적인” 입력 같은 것은 없습니다. “팝하게 만들어줘” 또는 “지난번에 한 것처럼 하되 다르게 해줘”라고 입력할 때, 에이전트는 (사람처럼) 프롬프트를 다양한 방식으로 해석할 수 있습니다.
- 기존 방식으로 디버깅할 수 없습니다. 많은 로직이 모델 내부에 있기 때문에 각 결정과 도구 호출을 검사해야 합니다. 작은 프롬프트나 설정 조정이 동작에 엄청난 변화를 만들 수 있습니다.
- “작동한다”는 것은 이진법이 아닙니다. 에이전트는 99.99% 가동 시간을 가지면서도 여전히 궤도를 벗어나 고장날 수 있습니다. 에이전트가 올바른 호출을 하고 있는가? 도구를 올바른 방식으로 사용하고 있는가? 지시사항 뒤의 의도를 따르고 있는가? 와 같이 중요한 질문에 대한 단순한 예/아니오 답변이 항상 있는 것은 아닙니다.
이 모든 것을 종합하면 — 실제로 높은 영향력의 워크플로를 실행하면서도 전통적인 소프트웨어로는 해결할 수 없는 방식으로 동작하는 에이전트 — 새로운 분야에 대한 기회와 필요성이 있습니다. 에이전트 엔지니어링을 통해 LLM의 힘을 활용하면서 프로덕션에서 실제로 신뢰할 수 있는 시스템을 구축할 수 있습니다.
실무에서 에이전트 엔지니어링은 어떤 모습일까?
에이전트 엔지니어링은 전통적인 소프트웨어 개발과는 다른 원칙으로 운영됩니다. 안정적인 에이전트 시스템을 달성하기 위해, 출시는 학습 후에 하는 것이 아니라 학습하는 방법입니다.
우리는 성공적인 엔지니어링 팀들이 다음과 같은 에이전트 개발 리듬을 따르는 것을 봤습니다:
- 에이전트의 기반 구축. 도구를 사용한 단순한 LLM 호출이든 복잡한 멀티 에이전트 시스템이든, 에이전트의 기반을 설계하는 것부터 시작하세요. 아키텍처는 얼마나 많은 워크플로(결정적 단계별 프로세스) 대 에이전시(LLM 기반 결정)가 필요한지에 따라 달라집니다.
- 상상할 수 있는 시나리오를 기반으로 테스트. 프롬프트, 도구 정의, 워크플로의 명백한 문제를 잡기 위해 예제 시나리오에 대해 에이전트를 테스트하세요. 사용자 플로우를 매핑할 수 있는 전통적인 소프트웨어와 달리, 사용자가 자연어 입력과 상호작용할 모든 방법을 예측할 수 없습니다. “철저히 테스트한 다음 출시”에서 “합리적으로 테스트하고, 실제로 중요한 것이 무엇인지 배우기 위해 출시”로 사고방식을 전환하세요.
- 실제 동작을 보기 위해 출시. 출시하면 즉시 고려하지 않았던 입력을 보기 시작할 것이며, 모든 프로덕션 추적은 에이전트가 실제로 처리해야 하는 것이 무엇인지 보여줍니다.
- 관찰. 모든 상호작용을 추적하여 전체 대화, 호출된 모든 도구, 에이전트가 내린 각 결정에 정보를 제공한 정확한 컨텍스트를 확인하세요. 프로덕션 데이터에 대해 평가를 실행하여 정확도, 지연 시간, 사용자 만족도 또는 기타 기준 등 관심 있는 항목이 무엇이든 에이전트 품질을 측정하세요.
- 개선. 무엇이 실패하고 있는지 패턴을 식별한 후에는 프롬프트를 편집하고 도구 정의를 수정하여 개선하세요. 회귀 테스팅을 위한 예제 시나리오 세트에 문제가 있는 케이스를 다시 추가할 수 있으므로 모두 연속적입니다.
- 반복. 개선 사항을 출시하고 프로덕션에서 무엇이 변하고 있는지 관찰하세요. 각 사이클은 사용자가 에이전트와 상호작용하는 방법과 귀하의 컨텍스트에서 안정성이 실제로 의미하는 것에 대해 새로운 것을 가르쳐줍니다.
엔지니어링의 새로운 표준
오늘날 안정적인 에이전트를 출시하는 팀들은 한 가지를 공유합니다: 그들은 출시 전에 에이전트를 완벽하게 만들려는 시도를 멈추고 프로덕션을 주요 교사로 취급하기 시작했습니다. 다시 말해, 모든 결정을 추적하고, 대규모로 평가하며, 분기가 아닌 며칠 안에 개선 사항을 출시합니다.
에이전트 엔지니어링은 기회가 요구하기 때문에 부상하고 있습니다. 에이전트는 이제 이전에 인간의 판단이 필요했던 워크플로를 처리할 수 있지만, 신뢰할 수 있을 만큼 충분히 안정적으로 만들 수 있어야만 가능합니다. 지름길은 없으며, 단지 체계적인 반복 작업이 있을 뿐입니다. 질문은 에이전트 엔지니어링이 표준 관행이 될 것인가가 아닙니다. 팀이 에이전트가 할 수 있는 것을 잠금 해제하기 위해 얼마나 빨리 이것을 채택할 수 있는가입니다.