본 논문은 AI 에이전트 개발에서 "source of truth"가 전통적인 소프트웨어의 "code"에서 "traces"로 변화하고 있음을 심층적으로 다룹니다. 전통적인 소프트웨어 애플리케이션에서 애플리케이션의 동작 방식과 의사결정 로직은 "codebase"에 명시되어 있으며, 개발자는 코드를 읽고 디버깅하며 최적화합니다. 이는 예측 가능하고 "deterministic"한 동작을 보장합니다.

그러나 AI 에이전트의 경우, 코드는 "scaffolding" 역할만 수행합니다. 즉, 사용할 "model"(예: GPT-4), "tools"(예: search_tool, analysis_tool), 그리고 "system_prompt"와 같은 기본적인 구성 요소만 정의합니다. 실제 의사결정 로직, 즉 언제 어떤 "tool"을 호출할지, 문제를 어떻게 추론할지, 언제 멈출지, 무엇을 우선시할지 등은 런타임 시 "Large Language Model"(LLM) 내부에서 발생합니다. LLM이 애플리케이션의 핵심을 구동할수록 개발자는 코드를 통해 애플리케이션의 실제 동작을 예측하기 어렵습니다. "Intelligence"와 "reasoning"은 코드베이스가 아닌 "model" 내부에 존재하므로, 코드만으로는 에이전트의 지능적 결함을 "debug"할 수 없습니다.

이러한 변화에 따라, 에이전트의 실제 동작 방식은 "traces"에 기록됩니다. "Trace"는 에이전트가 취한 일련의 단계들을 의미하며, 각 단계의 "reasoning", 호출된 "tool", 결과 및 시간 정보 등을 문서화합니다. 즉, "traces"가 AI 에이전트 애플리케이션의 새로운 "source of truth"가 되는 것입니다.

이러한 "source of truth"의 전환은 에이전트 개발의 모든 측면에 영향을 미칩니다:

1. Debugging: 에이전트 오류 발생 시 개발자는 더 이상 코드를 검토하지 않고 "trace"를 분석하여 "reasoning error"를 찾습니다. 에이전트가 작업을 오해했는지, 잘못된 "tool"을 호출했는지, 반복적인 루프에 빠졌는지 등을 "trace"를 통해 파악합니다. 전통적인 소프트웨어처럼 코드에 "breakpoint"를 설정할 수는 없지만, "playgrounds"를 사용하여 특정 "trace" 시점에서 에이전트의 상태(context, memory, available tools, prompt)를 로드하고 "reasoning" 과정을 "debug"할 수 있습니다.

2. Testing: "Logic"의 "source of truth"가 "traces"로 이동함에 따라, "testing"은 "eval-driven" 방식으로 전환됩니다. 에이전트 실행 시 생성되는 "traces"를 "test dataset"에 추가하고, 이 데이터를 기반으로 "eval"(evaluation)을 수행합니다. 또한, AI 에이전트는 "non-deterministic"하므로 배포 전 테스트를 넘어 "in-production eval"을 통해 지속적으로 품질 저하 및 "drift"를 감지해야 합니다.

3. Performance Optimization: 전통적인 소프트웨어에서는 코드 "profiling"을 통해 "hot loops"나 알고리즘을 최적화했지만, AI 에이전트에서는 "traces"를 "profile"하여 불필요한 "tool call"이나 비효율적인 "reasoning path"와 같은 "decision patterns"을 식별하고 최적화합니다. 병목 현상은 에이전트의 의사결정에 있으며, 이는 오직 "traces"에만 존재합니다.

4. Monitoring: "Monitoring"의 초점은 시스템 "uptime"에서 "quality of decisions"로 이동합니다. 에이전트가 오류 없이 작동하더라도, 잘못된 작업을 성공시키거나, 비효율적으로 높은 비용으로 성공시키거나, 올바르지만 도움이 되지 않는 답변을 제공할 수 있습니다. 따라서 "task success rate", "reasoning quality", "tool usage efficiency" 등을 모니터링해야 하며, 이는 "traces"를 샘플링하고 분석함으로써 가능합니다.

5. Collaboration: "Collaboration"의 중심이 GitHub와 같은 코드 기반 플랫폼에서 "observability platforms"로 이동합니다. 에이전트의 로직이 "traces"에 있으므로, 팀원들은 특정 "trace"를 공유하고, 특정 의사결정 지점에 주석을 달며, 에이전트가 특정 경로를 선택한 이유를 논의하게 됩니다. "Observability platform"은 단순히 모니터링 도구가 아닌 협업 도구가 됩니다.

6. Product Analytics: "Product analytics"와 "debugging"이 통합됩니다. 사용자의 행동을 이해하기 위해서는 에이전트의 행동을 이해해야 합니다. "User experience"는 에이전트의 의사결정에서 비롯되며, 이 의사결정은 "traces"에 문서화되어 있으므로, "product analytics"는 "traces"를 기반으로 구축되어야 합니다.

결론적으로, AI 에이전트 개발에서는 "decision logic"이 코드에서 "model"로 이동함에 따라, "source of truth"가 "code"에서 "traces"로 이동합니다. 이에 따라 "debugging", "testing", "optimizing", "monitoring", "collaborating" 등 모든 개발 작업이 "traces"를 중심으로 이루어져야 합니다. 이를 위해서는 검색, 필터링, 비교가 가능한 "structured tracing", 전체 "reasoning chain"의 가시성, 그리고 과거 데이터에 대한 "eval" 실행 능력 등 강력한 "observability" 도구가 필수적임을 강조합니다. 이러한 도구 없이는 개발자들이 에이전트의 실제 로직을 파악하기 어렵다고 지적합니다.