실패의 원인은 모델이 아닐 수 있습니다
에이전트의 신뢰성은 기반이 되는 대규모 언어 모델뿐만 아니라, 그 주변을 감싸는 harness(하네스), 즉 규칙, 도구, 워크플로우, 메모리, 가드레일로 구성된 아키텍처에 결정적으로 달려 있습니다. 모델의 성능에만 집중하면 실제 운영 환경에서 성과를 좌우하고 실수를 방지하는 운영 프레임워크를 간과하기 쉽습니다.
이러한 하네스를 구축하는 방식에 중대한 변화가 일어나고 있습니다. '과거의 방식'은 Python이나 TypeScript로 복잡한 오케스트레이션 로직을 직접 코딩하는 것이었습니다. 오늘날 에이전트의 동작은 지침, 기술, 구성을 위한 유연하고 수정 가능한 Markdown 파일을 사용하여 선언적으로 정의되고 관리됩니다. 이는 고급 AI 코딩 에이전트에서 볼 수 있는 강력하고 스스로 개선되는 시스템과 유사합니다.
이러한 선언적 접근 방식은 harness engineering(하네스 엔지니어링)을 실용적이고 반복적인 주기로 만듭니다. 더 강력한 모델이 시스템적 결함을 보완해주길 바라는 대신, 개발자는 프로덕션 트레이스에서 에이전트의 실패를 검사하고, 누락된 지침이나 잘못된 프로세스를 식별한 뒤 하네스를 직접 개선합니다. 이는 핵심 코드를 다시 작성하는 대신 Markdown 지침 파일을 업데이트하거나 기술 정의를 다듬는 것을 의미합니다.
이 방법은 또한 코딩 에이전트 구성 요소와 프로덕션 비즈니스 에이전트 간의 직접적인 유사성을 도출합니다. 규칙 및 지침 파일은 시스템 프롬프트에 매핑되고, 서브 에이전트는 멀티 에이전트 오케스트레이션이 되며, 기술은 구조화된 표준 운영 절차(SOP)로 기능합니다. 이러한 1:1 매핑은 강력하고 적응력 있는 AI 에이전트의 개발과 지속적인 개선을 간소화합니다.
코딩 에이전트 플레이북, 이제 비즈니스 봇에 적용되다
신뢰할 수 있는 AI 코딩 에이전트를 위한 아키텍처 청사진은 이제 프로덕션급 비즈니스 봇 설계에 직접적인 정보를 제공합니다. 이러한 변화는 깨지기 쉽고 하드코딩된 로직에서 유연하고 선언적인 구성으로 전환함으로써 에이전트 시스템을 구축하고 관리하는 방식을 재정의합니다.
직접적인 매핑을 고려해 보십시오. INSTRUCTIONS.md와 같은 지침 파일은 에이전트의 전역 컨텍스트와 페르소나를 정의하는 시스템 규칙이 됩니다. 이전에 코딩에서 작업 분해를 위해 사용되었던 서브 에이전트는 이제 멀티 에이전트 오케스트레이션에서 위임된 워크플로우를 나타냅니다.
결정적으로, MCP tools(Model Context Protocol)는 외부 데이터베이스 및 API를 위한 표준화된 통합 지점을 제공하며, Markdown 레시피로 정의된 기술은 복잡한 함수를 구조화된 단계별 절차 가이드라인으로 대체합니다. 마지막으로, 훅(hooks)은 정책 인터셉터로서 실행 전후 검사를 수행하여 결정론적 제어를 보장하는 가드레일을 강화합니다.
Markdown 및 YAML 파일을 활용하는 이 선언적 접근 방식은 워크플로우를 본질적으로 검사하고 수정하기 쉽게 만듭니다. 에이전트는 런타임 피드백을 기반으로 이러한 구성을 스스로 수정할 수도 있으며, 이는 하네스 엔지니어링의 핵심 원칙입니다. 코드는 여전히 필수적인 배관 작업과 결정론적 제어를 처리하지만, 상위 수준의 로직은 인간과 AI가 모두 읽을 수 있는 구성 파일에 상주합니다.
Cole Medin의 영상은 구현 예시로 LangChain의 Managed Deep Agents를 사용하지만, 이 기저의 아키텍처는 보편적입니다. 규칙, 기술, 가드레일을 외부화하는 동일한 원칙을 다른 배포 및 오케스트레이션 플랫폼에서도 적용할 수 있으며, 이는 특정 도구보다 설계 패턴의 전략적 중요성을 강조합니다.
두 개의 루프가 실수를 운영 메모리로 전환합니다
실수는 실패가 아니라 데이터 포인트입니다. 에이전트 시스템은 두 가지 별도의 피드백 루프를 통해 이러한 데이터 포인트를 포착하여 런타임 오류를 운영 메모리로 변환합니다.
첫째, runtime memory loop는 즉각적인 불확실성을 해결합니다. 에이전트가 새롭거나 모호한 상황에 직면하면 신중하고 잠정적인 응답을 제공한 다음, 검토를 위해 사람에게 사례를 에스컬레이션할 수 있습니다. 사람이 답변을 확인하거나 수정하면, 이 수정 사항은 즉시 에이전트의 메모리에 다시 기록됩니다.
이 수정 사항은 컨텍스트 허브에 저장되어 검색 가능한 교훈이 됩니다. 이 메모리는 개별 사용자에게 범위를 지정하여 개인화된 학습을 보장하거나, 더 광범위한 시스템 개선을 위해 관련 사례 전반에 걸쳐 공유될 수 있습니다. 에이전트는 무엇을 해야 할지뿐만 아니라 내부 규칙과 워크플로를 어떻게 조정해야 할지도 학습합니다.
Archon의 지원 에이전트를 예로 들어보겠습니다. 사용자가 로컬 수정 사항이 누락되었다고 보고했지만, origin/main 워크트리를 참조하던 에이전트는 이를 찾지 못했습니다. 사람의 수정 후, 에이전트는 사용자의 브랜치와 올바른 로컬 수정 위치라는 특정 컨텍스트를 기록했습니다. 이후 관련 쿼리가 들어오면 새로 획득한 이 특정 메모리를 직접 활용하여 자신 있게 답변할 수 있습니다. 강력한 에이전트 설계에 대한 자세한 내용은 Building Effective AI Agents - Anthropic Engineering을 참조하십시오.
두 번째 루프인 retroactive trace loop는 에이전트의 전체 상호작용 기록을 면밀히 조사하며, 이는 성능 데이터의 풍부한 "금광"과 같습니다. 이 루프는 런타임 루프가 놓칠 수 있는 더 깊고 체계적인 문제를 식별합니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
트레이스를 분석하되, 인간의 제동 장치를 유지하십시오
더 느린 retroactive loop는 프로덕션 트레이스에서 반복되는 실패를 찾아냅니다. 이러한 정보의 "금광"을 통해 에이전트는 자체 운영 기록을 분석하고 단일 사례 수정을 넘어 핵심 지침, 기술 또는 가드레일에 대한 업데이트를 제안할 수 있습니다.
유용한 메모리와 영구적인 harness fix를 구분하는 것이 중요합니다. 런타임 메모리는 고객의 이전 선호도와 같이 즉각적인 적용을 위해 사례별 교훈을 검색합니다. 그러나 워크플로 및 지침 업데이트는 반복적인 실패를 더 광범위하게 방지하여 에이전트의 기본 논리를 강화합니다.
이러한 변경 사항을 구현하려면 주의가 필요하며 사람이 제동 장치를 잡고 있어야 합니다. 에이전트가 제안한 편집 내용을 검토한 다음, 다양한 대표 사례 세트에 대해 테스트하십시오. 중요한 확인 사항의 경우 deterministic hooks를 구현하여 정책을 시행하십시오. 마지막으로 업데이트를 점진적으로 배포하고 배포 후 트레이스를 모니터링하여 수정 사항을 확인하고 harness engineering에서 새로운 회귀가 발생하는 것을 방지하십시오.
자주 묻는 질문
AI 에이전트를 위한 harness engineering이란 무엇인가요?
Harness engineering은 AI 모델을 둘러싼 규칙, 워크플로, 도구, 메모리 및 가드레일을 개선하여 모델의 동작을 더욱 신뢰할 수 있게 만드는 것입니다.
AI 에이전트는 프로덕션 실수로부터 어떻게 학습할 수 있나요?
불확실하거나 실패한 상호작용을 포착하고, 사람과 함께 검토한 다음, 확인된 수정 사항을 검색 가능한 메모리나 에이전트의 지침 및 기술에 대한 업데이트로 전환합니다.
AI 에이전트가 자신의 지침을 자동으로 다시 작성해야 하나요?
변경 사항을 제안할 수는 있지만, 중요한 편집 내용은 배포 전에 사람이 검토하고 테스트해야 합니다.
프로덕션 트레이스는 어떤 역할을 하나요?
트레이스는 워크플로가 어디에서 중단되는지, 도구가 어디에서 잘못 사용되는지, 어떤 지침을 개선해야 하는지를 밝혀내어 에이전트의 harness를 개선하는 데 귀중한 증거가 됩니다.