Agent Engineering 폭발 이후 배운 공학적 교훈 5가지

폭주 에이전트 호출로 시작

3개월 전에 저는 AI 에이전트 프로젝트를 맡았습니다. 에이전트가 작업 주문 읽기, 책임자 할당, 답변 보내기 등 고객 작업 주문 시스템을 자동으로 관리하도록 하는 것이었습니다. 간단하게 들리죠? 그 결과 출시 첫날 에이전트는 '재할당' API를 37번 반복 호출해 37명에게 동일한 작업 지시를 전달했다. 고객들은 CEO에게 직접 항의했다. 그 순간 나는 Agent Engineering이 단지 몇 가지 프롬프트를 작성하는 것이 아니라 체계적인 엔지니어링 사고가 필요하다는 것을 깨달았습니다.

다음은 후속 리팩토링 중에 배운 5가지 핵심 교훈입니다.

1. 도구 아키텍처에 대한 스키마만 작성하지 말고 '제약사항'도 작성하세요.

처음 도구 함수를 정의할 때 함수 이름, 매개변수, 반환 유형만 작성했습니다. 예를 들어 assign_ticket(ticket_id, assignee_id)입니다. 결과적으로 상담원은 존재하지 않는 할당자 ID를 전달하거나 사직한 사람에게 작업 주문을 할당하는 경우가 많습니다.

제가 판단하는 방식을 실제로 바꾸는 결론은 도구 스키마에는 비즈니스 의미론적 제약이 포함되어야 합니다입니다.

내 접근 방식:

• 매개변수 설명에 "임사인_ID가 현 직원인지 확인해주세요" 등의 규칙을 작성합니다.
• 보다 근본적으로 매개변수 수준에서 열거 또는 검증 정규식을 추가합니다. 예를 들어 Assignee_id는 숫자만 허용하며 고정 길이는 6입니다.
• 매개변수가 "직속 부하에게만 할당 가능"과 같은 외부 데이터에 의존하는 경우 먼저 도구 코드에서 데이터베이스를 확인하여 확인하고 에이전트가 추측하도록 하는 대신 명확한 오류를 반환합니다.

수정 전에는 내 스키마에 5줄만 있었습니다. 수정 후 각 도구의 설명이 평균 15줄로 늘어났고, 매개변수 검증도 내장됐다. 가격은 코드가 많아졌지만 상담원 호출 실패율은 23%에서 4%로 떨어졌다.

2. 권한 제어를 '기본 허용'에서 '명시적 거부'로 변경해야 합니다.

기본적으로 많은 에이전트 프레임워크에서 에이전트는 등록된 모든 도구를 호출할 수 있습니다. 초기에도 같은 일이 일어났습니다. 그 결과 에이전트가 자동으로 "작업 주문 삭제" 인터페이스를 호출하고 실수로 테스트가 아닌 작업 주문을 삭제했습니다.

교훈: 대리인 권한의 범위는 가능한 한 작게 하고 점차적으로 완화해야 합니다.

당신이 할 수 있는 일:

• 구성 파일이나 데이터베이스 테이블을 사용하여 각 에이전트가 수행할 수 있는 작업을 명시적으로 나열합니다.
• 도구 등록 단계에서는 데코레이터나 미들웨어를 사용하여 권한 확인을 수행합니다. 예를 들어 @require_permission('ticket:assign')입니다.
• 위험한 작업(삭제, 금액 수정, 외부 알림 전송)의 경우 에이전트가 수동 확인 후 실제로 실행되는 "사전 실행" 요청을 생성할 수 있도록 2차 확인 단계를 추가합니다.

나중에 리팩토링에 "권한 목록" 개체를 추가했는데, 이 개체는 에이전트가 시작될 때 로드되고 각 도구 호출 전에 확인되었습니다. 이 변경으로 인해 오작동이 0으로 줄어듭니다. 하지만 참고: 비즈니스 역할이 변경되므로 권한 목록 자체를 정기적으로 감사해야 합니다.

3. 루프는 저절로 사라지지 않으므로 적극적으로 감지하고 중단해야 합니다.

앞서 언급한 37개의 재할당은 루프로 인해 발생합니다. 상담원은 작업 주문의 상태가 잘못되었음을 확인하고 "재할당해야 한다"고 믿었습니다. 할당 후에도 상태가 변하지 않아서 계속 할당을 했습니다.

루프는 Agent Engineering의 가장 일반적인 실패 시나리오입니다. 해결책은 복잡하지 않습니다.

• 걸음수 카운터: 에이전트 실행의 총 단계 수를 제한합니다(예: 최대 20걸음). 제한을 초과하는 경우 강제 종료되며 중간 결과가 반환됩니다.
• 상태 지문 감지: 각 상태 스냅샷을 기록합니다. 중복된 상태가 감지되면 루프에 갇히고 중단점이 트리거될 수 있습니다.
• 내장된 중복 제거 로직: 에이전트가 동일한 매개변수를 사용하여 도구를 반복적으로 호출하면 일부 루프가 발생합니다. 도구 호출 계층에서 최근 호출(예: 마지막 5개 호출 해시)을 캐시하고 중복 항목이 발견되면 "실행됨, 반복할 필요 없음"을 반환할 수 있습니다.

구체적인 방법: 마지막 10개 상태 지문의 대기열을 유지하기 위해 LoopDetector 클래스를 작성했습니다. 각 도구 호출 후에 현재 상태 해시가 계산되고 비교됩니다. 반복률이 임계값을 초과하면 중단되고 경고가 출력됩니다. 이 메커니즘을 온라인으로 전환한 후 루프로 인한 오류가 90% 감소했습니다.

4. MCP는 양날의 검입니다. 기능을 확장할 수 있고 유령 종속성을 도입할 수도 있습니다.

MCP(모델 컨텍스트 프로토콜)은 에이전트가 데이터베이스, 파일 시스템 및 웹 API에 연결하는 것과 같은 외부 컨텍스트를 얻는 좋은 방법입니다. 그런데 MCP을 시도해보니 에이전트가 MCP에 명확하게 명시되지 않은 데이터에 의존하는 경우가 많아 추론 편향이 발생하는 것을 발견했습니다.

일반적인 문제: 에이전트가 MCP에서 사용자의 최근 주문 목록을 가져오지만 MCP에서 반환된 데이터가 취소된 주문과 혼합되어 있습니다. 에이전트는 필터링이 없으며 취소된 주문 상태를 사용자 활동 판단의 기초로 직접 사용합니다.

내 교훈: MCP의 데이터에는 자체 필터링 및 해석이 포함되어야 합니다. 에이전트는 데이터 소스가 반환하는 모든 것을 사용합니다. 에이전트가 데이터의 신뢰성을 맹목적으로 추측하는 것을 원하지 않습니다.

해결책:

• MCP 통합 시 각 데이터 필드에 "데이터 소스 설명" 및 "유효 기간"을 추가합니다.
• 데이터가 반환되면 '지난 1시간 동안 업데이트됨', '취소된 주문이 포함될 수 있음'과 같은 '데이터 품질 라벨'이 함께 표시됩니다.
• 가능하다면 도구 기능에서 데이터 정리를 미리 수행하십시오. 예를 들어, "사용자 주문 가져오기" 도구는 내부적으로 취소된 주문을 필터링합니다.

이를 도입한 후 MCP을 기반으로 한 에이전트의 의사결정 정확도가 크게 향상되었습니다. 하지만 주의하세요. MCP에 대한 데이터를 과도하게 처리하지 마십시오. 그렇지 않으면 실제 문제가 숨겨질 수 있습니다.

5. 입출력 비율이 떨어지는 것을 발견하면 시간에 맞춰 경로를 변경하십시오

상담원이 모든 문제를 해결할 수 있는 것은 아닙니다. 내 프로젝트에서 이러한 시나리오에 직면했습니다. 특정 작업 주문 유형에 대한 에이전트 처리를 최적화하는 데 2주를 보냈지만 정확도는 80%에서 82%로 증가했습니다. 대신 기존 규칙 + 단순 분류 모델을 사용하면 하루 만에 95%에 도달할 수 있습니다.

경로를 변경할 때가 되었는지 어떻게 알 수 있나요?

• 약간의 이점: 각 최적화가 1% 미만만 향상되고 코드 복잡성이 급등하는 경우 중지하세요.
• 실패 모드: 에이전트의 실패가 무작위인 경우(예: 오류 원인이 시나리오마다 완전히 다름) 해당 시나리오가 에이전트에 적합하지 않을 가능성이 높으며 대신 결정론적 솔루션을 사용해야 합니다.
• 테스트 가능성: 개선 효과를 검증하기 위한 테스트 케이스 구성이 어렵다면 문제가 너무 모호하여 에이전트가 운을 시험해 본다는 의미입니다.

나의 의사결정 원칙: 핵심 지표(예: 성공률)가 3번의 반복 이내에 허용 가능한 수준으로 향상되지 않으면 중지합니다. 먼저 간단한 솔루션을 사용하여 문제의 원인을 파악한 다음 맹목적으로 프롬프트를 쌓기보다는 근본 원인을 이해하는 데 시간을 투자합니다.

계속 투자하는 데 적합한 시나리오는 무엇인가요?

• 작업 주문 분류, 이메일 회신 등 작업에는 명확한 패턴이 있지만 규칙이 복잡합니다.
• 독립적으로 결정을 내리려면 상담사가 필요하지만, 콘텐츠 추천, 초안 생성 등 실패에 따른 비용은 통제 가능합니다.
• 엔지니어링 능력을 갖추고 있으며, 도구 정의, 권한, 주기 감지 등을 할 수 있습니다.

언제 노선을 변경해야 하나요?

• 패턴이 없는 사용자 입력 등 작업이 완전히 무작위이거나 불규칙합니다.
• 금융거래, 의료진단 등 실패로 인한 비용이 매우 높습니다.
• 제어 불가능한 외부 API 통합 등 에이전트의 입출력 형식을 제어할 수 없습니다.

지금 시작하고 싶다면 가장 가치 있는 단계는 다음과 같습니다.

실제이지만 위험도가 낮은 작업(예: 내부 작업 주문 자동 할당)을 찾고 먼저 전체 에이전트 구축 프로세스(도구 등록, 권한 설정, 루프 감지 추가, 10가지 시나리오 테스트)를 수동으로 완료하세요. 그런 다음 실패 데이터를 기록하십시오. 완벽함을 목표로 하지 마십시오. 첫 번째 버전이 단순할수록 더 좋습니다. 다시 작성하게 될 것입니다.

이 과정에서 제가 느낀 가장 큰 느낌은 Agent Engineering의 성공은 에이전트가 얼마나 똑똑한지에 있는 것이 아니라 엔지니어링 제약 조건이 얼마나 엄격한지에 달려 있다는 것입니다.