From prototype to production: Engineering agents with Agent DLC

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Agent DLC는 명시적인 gold standard와 두 개의 개선 순환으로 에이전트의 운영 준비 상태를 판단하는 체계이며, HR 참조 구현은 높은 검색 정밀도와 근거성 점수만으로 정보 누락이나 잘못된 개인화 주장을 걸러낼 수 없음을 보여준다.

📌 핵심 요약

• 에이전트는 비결정적이고, 프롬프트·도구·검색·메모리 변경으로 동작이 달라지며, 저장소 밖의 의존성 변화에도 영향을 받는다. 기존 테스트와 CI/CD에 더해 사례별 k회 실행, 변경별 평가와 이력 보존, 정기적인 기준 재평가가 필요하다.
• HR 정책 도우미 참조 구현의 초기 평가에서 성과 평가·복리후생 가입·병가 증명서 질문의 청크 수준 정밀도는 모두 1.00이었다. 그러나 사실 수준 정밀도는 각각 0.59·0.53·0.09였고, 병가 증명서 질문의 검색 커버리지는 0.00으로 필요한 정보가 검색되지 않았다.
• 시스템 프롬프트만 수정하자 성과 평가 질문의 근거성은 0.83에서 0.87로 개선됐지만, 병가 질문은 0.39에서 0.31로 악화됐다. 문서 집합에는 전용 병가 정책 문서가 없었으므로, 이 사례에서는 프롬프트 수정만으로 실패를 해결할 수 없었다.
• 복리후생 가입 답변은 근거성 0.90으로 통과했지만, 존재하지 않는 사용자 프로필을 근거로 선호 연락 수단이 Social Media라고 주장했다. 품질 기준 통과가 책임 관련 제약 충족을 보장하지 않으며, 참조 구현 점수는 실행마다 달라질 수 있고 고객 성과나 벤치마크·운영 출시 검증을 뜻하지 않는다.
• Agent DLC는 Define·Build·Evaluate·Release·Observe·Feed Back을 하나의 gold standard로 연결한다. gold standard는 사업 책임자가 승인한 검증 가능 기준·임계값·예시 묶음이며, 내부 순환은 고정된 기준 아래 에이전트를 개선하고 외부 순환은 운영 피드백으로 기준 자체를 갱신한다.

🧩 주요 포인트

1. 청크 수준 정밀도 1.00과 검색 커버리지 0.00의 공존 → 주제 관련성과 실제 답변 가능성을 구분해야 하며, 누락된 병가 정책은 정보 범위부터 점검할 사안이다.
2. 프롬프트 수정의 상반된 결과와 근거성 0.90의 잘못된 개인화 주장 → 단일 점수 대신 반복 실행, 실패 근거, 책임 관련 제약을 함께 살펴야 한다.
3. Agent DLC의 내부 순환과 외부 순환 분리 → 에이전트 변경 효과와 gold standard 변경 효과를 구분하고, 모델 교체 시에도 같은 기준과 승인 예시를 재사용할 수 있다.

🧠 상세 정리

1. 시연의 성공에서 운영 준비 상태의 입증으로

기업은 도구를 호출하고 API를 조율하며 내부 지식을 바탕으로 답하는 LLM 에이전트를 실제로 배포하고 있지만, 성공적인 시연만으로 운영 준비 상태가 입증되지는 않는다. 출시 책임자는 합의된 요구사항의 충족 여부와 최신 변경의 개선 효과를 반복 가능하고 감당 가능한 비용으로 확인할 증거가 필요하다. 기존 단위 테스트와 CI/CD는 계속 필요하지만, 동일한 입력에서도 출력과 실행 경로가 달라지는 비결정성 때문에 사례마다 한 번의 단언만으로는 충분하지 않다. Agent DLC는 각 예시를 k회 실행하고 통과율과 실패 분포로 판단하도록 제안한다. 프롬프트·도구 설명·검색 설정·메모리 변경은 텍스트 차이만으로 영향을 알 수 없으므로 버전별 평가를 붙이고 변경 이력을 보존해야 한다. 모델 엔드포인트·지식 기반·외부 API는 저장소 변경 없이도 달라질 수 있어, 정기적으로 기준을 다시 실행하고 기준선 이탈을 알리는 절차도 요구된다.

2. HR 참조 구현과 다섯 가지 평가 관점

저자들은 문서 지식 기반에 대해 HR 정책 질문에 답하는 내부 도우미를 참조 구현으로 만들고, 평가와 진단을 따라가기 쉽도록 범위가 좁고 명확한 영역을 선택했다. 이는 고객 성과나 벤치마크 결과가 아니며, 함께 제공되는 AWS Samples 저장소에는 인프라 배포, HR 에이전트, 사용자 정의 평가기와 기준선 평가·프롬프트 변경 재평가 스크립트가 포함된다. 세 개의 승인 질문에는 근거성, 청크 수준 소스 정밀도, 사실 수준 소스 정밀도, 검색 커버리지, 응답 정밀도라는 다섯 측정을 적용했다. 근거성은 답변을 주장으로 나눠 검색 출처와 대조하며, 두 소스 정밀도는 각각 검색 청크 전체와 청크 속 개별 사실이 질문에 필요한지를 평가한다. 검색 커버리지는 각 하위 질문에 답하는 청크가 있는지 확인하고, 응답 정밀도는 답변의 주장 가운데 필요한 주장의 비중을 살핀다. 저장소의 09-run-eval.sh와 10-optimize-prompt.sh는 평가 흐름을 재현하며, 선택적으로 평가 판정의 반복성·모델 비교·비용·지연시간도 확인할 수 있지만 점수는 실행과 저장소 버전에 따라 달라질 수 있다.

3. 청크 정밀도 1.00이 숨긴 정보 공백

첫 평가에서 성과 평가 질문은 근거성 0.83, 청크 수준 정밀도 1.00, 사실 수준 정밀도 0.59, 검색 커버리지 1.00으로 통과했다. 복리후생 가입 질문도 같은 순서로 0.90, 1.00, 0.53, 1.00을 기록해 통과했지만, 병가 증명서 질문은 0.39, 1.00, 0.09, 0.00으로 실패했다. 청크 수준 정밀도만 출시 조건으로 사용했다면 세 답변을 모두 받아들였을 것이므로, 어떤 지표를 선택하느냐가 실패를 발견하는 데 직접 영향을 준다. 특히 병가 증명서 질문에서는 검색 자료 속 사실의 약 열 개 중 아홉 개가 질문에 불필요했고, 검색 커버리지 0.00은 질문에 답할 정보도 확보하지 못했음을 보여준다. 청크 수준 정밀도는 문단이 주제와 관련 있는지 살피지만, 그 안에서 실제로 필요한 정보가 얼마나 되는지까지 측정하지는 않는다.

4. 프롬프트만 바꾼 실험과 병가 정책의 누락

다음 실험에서는 시스템 프롬프트에 검색 내용에 엄격히 근거할 것, 무관한 검색 내용을 무시할 것, 답변의 초점을 유지할 것이라는 세 제약만 추가했다. 에이전트·지식 기반·평가기·질문은 유지했으므로 전후 비교에서 바뀐 변수는 하나였다. 성과 평가 질문의 근거성은 0.83에서 0.87로, 사실 수준 정밀도는 0.59에서 0.85로, 응답 정밀도는 0.58에서 0.73으로 개선됐다. 반면 병가 질문의 근거성은 0.39에서 0.31로, 사실 수준 정밀도는 0.09에서 0.04로 떨어졌으며, 응답 정밀도는 변경 전 0.33이고 변경 후 값은 제시되지 않았다. 초기 지표 조합은 이미 지식 커버리지 문제를 시사했고, 실제 원문 문서를 확인하자 휴가 관리 정책에 병가가 짧게 언급돼 있을 뿐 전용 병가 정책 문서는 없었다. 따라서 이 사례의 다음 단계는 프롬프트를 계속 고치는 것이 아니라 정책 정보의 범위를 보완한 뒤 검색을 확인하는 것이며, 엄격한 근거 지시만으로 누락된 정보를 만들어낼 수는 없었다.

5. 높은 근거성과 잘못된 개인화 주장의 공존

복리후생 가입 답변은 근거성 0.90으로 통과했지만, 사용자 프로필에서 선호 연락 수단이 Social Media임을 확인했다는 문장을 포함했다. 실험에는 그런 프로필이 존재하지 않았으므로, 이는 사용자에 대한 잘못된 개인적 주장이었다. 정책 문서는 절차의 한 단계에서 연락 수단 선호를 선택 사항으로 제시했고, 공개된 크라우드소싱 기반의 잡음 많은 FAQ 자료에는 해당 질문에 social media라고 답한 항목이 있었다. 모델은 정책의 선택 항목과 무관한 FAQ 답변을 결합해 사용자 개인의 사실처럼 제시했으며, 높은 근거성 점수는 이 오류를 잡아내지 못했다. 이 결과는 품질 임계값 통과만으로 책임 관련 제약 충족을 판단할 수 없다는 점을 보여주며, 점수 차이는 반복 실행과 실제 근거를 함께 보고 해석해야 한다. 경계선의 통과는 다른 실행에서 실패로 바뀔 수 있고, 이 작은 참조 구현만으로 일반적인 개선율이나 운영 출시의 타당성이 검증된 것은 아니다.

6. 하나의 기준으로 연결하는 여섯 활동

Agent DLC는 Define·Build·Evaluate·Release·Observe·Feed Back이라는 여섯 활동을 하나의 명시적 gold standard 주위에 연결한다. 여기서 gold standard는 검증 가능한 기준과 임계값, 그 기준을 적용할 승인 예시의 묶음이며, 사업 책임자가 수용 여부를 결정하는 근거로 승인한다. Define은 사업 목표를 이 기준으로 바꾸고, Build는 이를 충족할 프롬프트·도구·컨텍스트·메모리·실행 메커니즘을 설계하며, Evaluate는 후보 버전의 충족 여부를 보여주는 증거를 만든다. 기준을 충족한 버전은 통제된 출시로 넘어가고, Observe는 운영 동작을 관찰하며, Feed Back은 운영에서 배운 내용을 Define으로 돌려보낸다. 글은 Xia 등의 평가 주도 개발 연구를 언급하면서 Agent DLC가 명시적 수용 조건, 출시 권한, 증거 요구사항을 통해 이 접근을 전달 과정에 적용한다고 설명한다. Fotor의 AWS 고객 사례에서는 Amazon Bedrock AgentCore의 기능인 AgentCore runtime으로 이전하기 전에 확장성·비용·격리·아키텍처 유연성 기준을 정했고, 모델 추론을 제외한 워크플로 오버헤드가 분 단위에서 초 단위로 줄고 수천 개의 동시 활성 세션을 지원했다고 보고한다. 다만 이 사례는 Agent DLC를 따른 아키텍처 전달을 기록한 것이며, 품질 평가는 다음 단계로 제시된다.

7. 에이전트를 고치는 내부 순환과 기준을 바꾸는 외부 순환

더 빠른 내부 순환은 점수 산출, 실행 경로 확인, 한 가지 변경, 재평가의 순서로 한 후보 버전을 개선하며, 어디를 바꿀지와 변경이 도움이 됐는지를 판단한다. 내부 순환은 고정된 기준을 충족하도록 에이전트를 개선하고, 외부 순환은 운영에서 발견한 요구를 반영해 기준 자체를 변경한다. 개발 중 재고를 확인하지 않고 상품을 추천하는 동작은 내부 순환의 문제지만, 사용자가 가족을 대신해 정보를 조회하는 상황을 다룰 기준이 없다면 외부 순환에서 권한 경계를 정의하고 예시를 추가해야 한다. 이후 갱신된 기준을 충족시키는 작업에는 다시 내부 순환을 적용한다. 두 순환을 혼동하면 빠진 기준을 프롬프트 수정으로 해결하려 하거나 개선 도중 기준까지 넓혀 어떤 변화가 점수에 영향을 줬는지 구분하지 못할 수 있다. 두 순환이 축적하는 사업 기준·승인 예시·평가기·과거 실패 처리 기록은 모델과 프레임워크보다 오래 활용할 수 있으며, 모델을 교체할 때도 같은 기준과 예시로 대체 모델을 평가한다.

8. 사업 목표를 검증 가능한 기준으로 바꾸는 출발점

제공된 원문은 좋은 동작을 정의하는 방법을 ‘다섯 차원, 세 계층’이라는 제목으로 소개하며, 사업 책임자가 정의한 성과에서 출발하라고 설명한다. 추천 에이전트의 예시는 재방문 고객에게 적합한 상품을 추천하면서 고객 정보를 보호한다는 목표이며, 이를 다섯 차원에 걸친 검증 가능한 기준으로 바꾸도록 제안한다. 표에서 실제로 확인되는 첫 차원은 도메인 이해로, 에이전트가 사업을 제대로 이해하는지를 묻고 용어·별칭·여러 단계를 거치는 관계를 살펴보도록 한다. 이 접근은 앞서 설명한 gold standard와 연결되며, 사업 목표를 수용 판단에 사용할 구체적인 기준·임계값·승인 예시로 표현하는 데 초점을 둔다. 다만 제공된 본문은 첫 차원의 설명에서 끝나므로 나머지 네 차원과 세 계층의 세부 내용은 확인할 수 없고, 뒤에서 예고한 평가기 신뢰성 점검·운영 피드백·평가 증거를 제공하는 아키텍처의 상세 절차도 이 자료만으로 정리할 수 없다.

🧾 핵심 주장 / 시사점

• 검색 자료가 질문의 주제와 관련 있다는 사실과 실제 답변에 필요한 정보를 포함한다는 사실은 다르다. 청크 수준 정밀도에 사실 수준 정밀도와 검색 커버리지를 함께 적용해야 이 차이가 드러난다.
• 프롬프트 변경의 효과는 질문별로 반대 방향일 수 있다. 평가 결과를 실패 원인과 연결해야 프롬프트 수정으로 다룰 문제와 원문 정보 부족을 구분할 수 있다.
• Agent DLC에서 재사용 가치가 큰 자산은 사업 기준·승인 예시·평가기·실패 처리 기록이다. 이를 유지하면 모델 교체와 운영 요구 변화에도 일관된 수용 판단의 근거를 이어갈 수 있다.

✅ 액션 아이템

• gold standard를 사업 책임자가 승인한 검증 가능 기준·임계값·예시로 정의하고, Agent DLC의 내부 순환에서는 기준을 고정해 변경 효과를 평가한다.
• 병가 증명서 질문의 검색 커버리지 0.00과 전용 병가 정책 문서 부재를 근거로 정보 범위를 보완한 뒤 검색 결과를 재평가한다.
• 근거성 0.90에서도 발생한 Social Media 개인화 주장을 책임 관련 제약과 함께 검토하고, 사례별 k회 실행으로 통과율과 실패 근거를 확인한다.

❓ 열린 질문

• 병가 정책의 정보 범위를 보완하면 병가 증명서 질문의 검색 커버리지 0.00과 근거성 실패는 얼마나 개선되는가?
• 근거성 0.90으로 통과한 Social Media 개인화 주장을 걸러내기 위해 gold standard에 어떤 책임 관련 제약과 승인 예시가 필요한가?
• 사례별 k회 실행에서 k와 통과율의 수용 기준을 어떻게 정해야 Agent DLC의 변경 효과를 일관되게 판단할 수 있는가?