Agent Engineering: A New Discipline

🖼️ 인포그래픽

Agent Engineering: A New Discipline 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

에이전트 엔지니어링은 예측 불가능한 LLM 에이전트를 실제 운영 환경에서 신뢰할 수 있게 만들기 위해 구축, 테스트, 배포, 관찰, 개선을 반복하는 새로운 실무 discipline이다.

📌 핵심 요약

글은 전통적 소프트웨어와 달리 에이전트는 입력과 출력 범위를 미리 확정하기 어렵기 때문에, 로컬에서 작동하는 것과 프로덕션에서 신뢰할 수 있게 작동하는 것 사이의 간극이 크다고 설명한다.
에이전트 엔지니어링은 비결정적인 LLM 시스템을 안정적인 프로덕션 경험으로 다듬는 반복 과정이며, 핵심 주기는 build, test, ship, observe, refine, repeat이다.
이 discipline은 제품 사고, 엔지니어링, 데이터 과학이 결합된 형태로 나타나며, 프롬프트와 범위 정의, 도구와 런타임 구축, 평가·모니터링·오류 분석이 함께 필요하다.
필요성이 커진 이유는 LLM이 복잡한 다단계 업무를 수행할 만큼 강력해졌지만, 동시에 자연어 입력, 도구 호출, 문맥 기반 판단 때문에 기존 방식으로는 디버깅과 품질 판단이 어렵기 때문이다.
성공적인 팀들은 출시 전 완벽함을 목표로 하기보다 프로덕션을 학습의 장으로 삼고, 모든 의사결정과 도구 호출을 추적하며, 실제 사용 데이터 기반 평가와 빠른 개선을 반복한다.

🧩 주요 포인트

글은 전통적 소프트웨어와 달리 에이전트는 입력과 출력 범위를 미리 확정하기 어렵기 때문에, 로컬에서 작동하는 것과 프로덕션에서 신뢰할 수 있게 작동하는 것 사이의 간극이 크다고 설명한다.
에이전트 엔지니어링은 비결정적인 LLM 시스템을 안정적인 프로덕션 경험으로 다듬는 반복 과정이며, 핵심 주기는 build, test, ship, observe, refine, repeat이다.
이 discipline은 제품 사고, 엔지니어링, 데이터 과학이 결합된 형태로 나타나며, 프롬프트와 범위 정의, 도구와 런타임 구축, 평가·모니터링·오류 분석이 함께 필요하다.
필요성이 커진 이유는 LLM이 복잡한 다단계 업무를 수행할 만큼 강력해졌지만, 동시에 자연어 입력, 도구 호출, 문맥 기반 판단 때문에 기존 방식으로는 디버깅과 품질 판단이 어렵기 때문이다.
성공적인 팀들은 출시 전 완벽함을 목표로 하기보다 프로덕션을 학습의 장으로 삼고, 모든 의사결정과 도구 호출을 추적하며, 실제 사용 데이터 기반 평가와 빠른 개선을 반복한다.

🧠 상세 정리

1. 전통적 소프트웨어 방식으로는 부족한 이유

글은 에이전트를 만들어 본 사람이라면 “내 컴퓨터에서는 된다”와 “프로덕션에서 된다” 사이의 차이가 매우 크다는 점을 먼저 짚는다. 전통적 소프트웨어는 대체로 입력을 알고 있고 출력도 정의할 수 있다는 전제 위에 세워지지만, 에이전트는 사용자가 사실상 무엇이든 말할 수 있다. 가능한 행동의 범위도 넓기 때문에 예상하지 못한 방식으로 빗나갈 수 있다. 저자들은 지난 3년 동안 수많은 팀이 이 현실과 씨름하는 모습을 보았고, 신뢰할 수 있는 에이전트를 배포한 팀들이 기존 소프트웨어 개발 방식만 따르지 않았다고 설명한다.

2. 에이전트 엔지니어링의 정의와 반복 주기

에이전트 엔지니어링은 비결정적인 LLM 시스템을 신뢰 가능한 프로덕션 경험으로 다듬는 반복적 과정으로 정의된다. 핵심은 만들고, 테스트하고, 배포하고, 관찰하고, 개선한 뒤 다시 반복하는 순환 구조다. 여기서 배포는 끝점이 아니라 새로운 통찰을 얻고 에이전트를 개선하기 위한 수단으로 제시된다. 중요한 개선을 하려면 실제 운영 환경에서 무슨 일이 일어나는지 이해해야 하며, 이 순환을 빠르게 돌릴수록 에이전트의 신뢰성이 높아진다는 것이 글의 중심 주장이다.

3. 필요한 세 가지 역량: 제품, 엔지니어링, 데이터 과학

저자들은 에이전트 엔지니어링이 세 가지 역량의 결합이라고 설명한다. 제품 사고는 에이전트의 범위와 행동을 정의하며, 때로 수백 줄이나 수천 줄에 이르는 프롬프트를 작성하고 에이전트가 대체하려는 ‘해야 할 일’을 깊이 이해하는 역할을 한다. 엔지니어링은 에이전트가 사용할 도구를 만들고, 스트리밍이나 중단 처리 같은 상호작용 UI/UX를 개발하며, 지속 실행·사람 개입·메모리 관리를 처리하는 런타임을 구축한다. 데이터 과학은 평가, A/B 테스트, 모니터링, 사용 패턴 분석, 오류 분석을 통해 성능과 안정성을 측정하고 개선한다.

4. 조직 안에서 나타나는 실무 책임

글은 에이전트 엔지니어링이 반드시 새로운 직함을 뜻하는 것은 아니라고 강조한다. 대신 추론하고 적응하며 예측하기 어려운 시스템을 만드는 기존 팀들이 떠맡는 새로운 책임들의 묶음으로 설명된다. 소프트웨어 엔지니어와 ML 엔지니어는 프롬프트를 쓰고 도구를 구축하며 특정 도구 호출이 왜 일어났는지 추적하고 모델을 개선한다. 플랫폼 엔지니어는 지속 실행과 사람 개입 흐름을 처리하는 인프라를 만들고, 제품 관리자는 범위와 문제 정의를 담당하며, 데이터 과학자는 신뢰성을 측정하고 개선 기회를 찾는다. 이 과정에서는 엔지니어, PM, 데이터 담당자가 생산 환경의 관찰 결과를 바탕으로 빠르게 역할을 오가며 개선한다.

5. 왜 지금 필요한가: 강력해진 능력과 커진 예측 불가능성

에이전트 엔지니어링이 필요해진 배경으로 글은 두 가지 변화를 든다. 첫째, LLM은 이제 단순 작업이 아니라 복잡한 다단계 워크플로를 처리할 만큼 강력해졌고, Clay의 잠재고객 조사·개인화 아웃리치·CRM 업데이트나 LinkedIn의 대규모 인재 풀 검색과 후보자 랭킹 같은 사례에서 비즈니스 가치를 내기 시작했다. 둘째, 그 힘은 큰 예측 불가능성을 동반한다. 사용자의 자연어 입력은 사실상 모든 경우가 엣지 케이스가 될 수 있고, “지난번처럼 하되 다르게 해줘” 같은 요청은 여러 방식으로 해석될 수 있다. 또한 모델 내부에 많은 로직이 있기 때문에 각 결정과 도구 호출을 살펴봐야 하며, 99.99%의 가동률이 있어도 실제 행동이 틀리면 에이전트는 여전히 망가진 상태일 수 있다.

6. 실무 방식과 새로운 엔지니어링 기준

실무에서 에이전트 엔지니어링은 전통적 개발과 다른 원칙을 따른다. 먼저 단순한 도구 사용 LLM 호출이든 복잡한 멀티 에이전트 시스템이든, 필요한 워크플로와 자율성의 비율에 맞춰 기반 구조를 설계한다. 그다음 예상 가능한 시나리오로 프롬프트, 도구 정의, 워크플로의 명백한 문제를 잡되, 모든 자연어 상호작용을 사전에 예측할 수 없다는 점을 받아들인다. 배포 후에는 실제 입력과 프로덕션 trace를 통해 에이전트가 무엇을 처리해야 하는지 확인하고, 대화 전체와 도구 호출, 판단에 쓰인 문맥을 관찰한다. 이후 운영 데이터에 평가를 적용해 정확도, 지연 시간, 사용자 만족도 등을 측정하고, 실패 패턴을 바탕으로 프롬프트와 도구 정의를 수정하며, 문제 사례를 회귀 테스트에 다시 넣는 식으로 반복한다.

🧾 핵심 주장 / 시사점

에이전트의 신뢰성은 출시 전 설계만으로 확보되는 것이 아니라, 실제 프로덕션 행동을 관찰하고 반복적으로 조정하는 운영 역량에서 나온다.
에이전트 품질은 단순한 가동률이나 성공·실패 이분법으로 판단하기 어렵고, 의도 이해, 도구 사용의 적절성, 문맥 기반 판단까지 함께 평가해야 한다.
성공적인 에이전트 개발은 특정 직군 하나의 일이 아니라 제품 범위 정의, 런타임 구축, 평가와 오류 분석이 맞물리는 cross-functional 반복 시스템에 가깝다.

✅ 액션 아이템

에이전트 운영 계획에서 입력·출력 범위를 완전 고정할 수 없다는 점을 전제해 적용 범위 가정과 실패 허용 조건을 먼저 정리한다.
build·test·ship·observe·refine·repeat 주기를 릴리스 단위로 고정해 각 단계마다 실사용 데이터 기반으로 개선 대상을 선별해 반영한다.
프롬프트·도구·런타임·모니터링을 분리 설계한 뒤 의사결정과 도구 호출 추적 로그를 묶어 오류 분석 체계를 확보한다.