소프트웨어에서는 코드가 앱을 문서화합니다. AI에서는 트레이스가 그렇게 합니다
TMThttps://www.blog.langchain.com/in-software-the-code-documents-the-app-in-ai-the-traces-do/
요약(TL;DR)
- 전통적인 소프트웨어에서는 앱이 무엇을 하는지 이해하려면 코드를 읽습니다 — 의사결정 로직은 코드베이스에 존재합니다
- AI 에이전트에서는 코드는 단지 스케폴딩일 뿐 — 실제 의사결정은 런타임의 모델에서 일어납니다
- 이 때문에, 앱이 실제로 무엇을 했고 왜 그렇게 했는지에 대한 진실의 근원(source of truth)이 코드에서 트레이스로 이동합니다 — 트레이스는 에이전트가 실제로 수행한 것과 그 이유를 문서화합니다
- 이는 우리가 디버그, 테스트, 최적화, 모니터링, 협업, 제품 사용 이해를 수행하는 방식을 변화시킵니다
- 만약 에이전트를 좋은 가시성 없이 만들고 있다면, 시스템이 실제로 무엇을 하는지에 대한 진실의 근원을 놓치고 있는 것입니다
전통적인 소프트웨어에서는, 문제가 생기면 코드를 읽습니다. 기능이 어떻게 동작하는지 이해하고 싶으면 코드를 읽습니다. 성능을 개선하고 싶으면 코드를 프로파일합니다. 코드는 진실의 근원입니다.
AI 에이전트에서는, 더 이상 이것이 통하지 않습니다.
왜 코드는 에이전트 동작을 문서화하지 못하는가
전통적인 소프트웨어에서는, 사용자가 폼을 제출할 때 무엇이 일어나는지 이해하려면 handleSubmit()을 열어 그 함수를 읽습니다. 의사결정 로직이 바로 거기에 있습니다: 입력 검증, 인증 확인, API 호출, 에러 처리. 이것은 결정적입니다 — 같은 입력, 같은 코드 경로, 같은 출력.
AI 에이전트에서, 코드는 단지 스케폴딩입니다.
다음은 에이전트 코드가 실제로 어떻게 보이는지에 대한 단순화된 버전입니다:
agent = Agent(
model="gpt-4",
tools=[search_tool, analysis_tool, visualization_tool],
system_prompt="You are a helpful data analyst..."
)
result = agent.run(user_query)여러분은 구성 요소를 정의했습니다: 어떤 모델, 어떤 도구, 어떤 지시사항. 그러나 의사결정 로직은 여러분의 코드에 있지 않습니다. 코드는 LLM 호출을 오케스트레이션할 뿐입니다.
실제 결정 — 언제 어떤 도구를 호출할지, 문제를 어떻게 추론할지, 언제 멈출지, 무엇을 우선순위로 둘지 — 이 모든 것은 런타임의 모델 안에서 일어납니다.
앱에서 LLM이 더 많은 부분을 주도할수록(에이전트에서 발생하는 일), 단지 코드를 보는 것만으로는 앱이 실제로 무엇을 할지에 대한 가시성이 점점 줄어듭니다.
여러분은 여전히 오케스트레이션 코드를 디버그할 수 있습니다 — 도구 호출이 동작하는지, 파싱이 동작하는지. 그러나 ‘지능’을 디버그할 수는 없습니다. 에이전트가 좋은 결정을 내리는지, 효과적으로 추론하는지 — 그 로직은 모델 안에 존재하며, 여러분의 코드베이스에는 없습니다.
새로운 문서로서의 트레이스
그렇다면 실제 동작은 어디에 존재할까요? 트레이스에 존재합니다.
트레이스는 에이전트가 취한 단계들의 연속입니다. 이는 앱의 로직을 문서화합니다 — 각 단계의 추론, 어떤 도구가 왜 호출되었는지, 결과와 타이밍을 담습니다.
이는 소프트웨어 세계에서 코드를 대상으로 하던 운영들을, 에이전트 세계에서는 트레이스를 대상으로 하게 됨을 의미합니다.
디버깅, 테스트, 프로파일링, 모니터링 — 이 모든 것이 코드에서 트레이스로 중심이 이동합니다.
전통적인 소프트웨어에서는, 두 번의 실행이 다른 출력을 내면 다른 입력 혹은 다른 코드라고 가정합니다. AI 에이전트에서는, 같은 입력과 같은 코드로도 다른 출력을 낼 수 있습니다. 다른 도구 호출, 다른 추론 체인, 다른 결과.
무슨 일이 일어났는지 이해하는 유일한 방법은 트레이스를 보는 것입니다. 왜 과제 A는 성공했지만 과제 B는 실패했는가? 트레이스를 비교하세요. 프롬프트 변경이 추론을 개선했는가? 변경 전후 트레이스를 비교하세요. 왜 에이전트가 같은 실수를 반복하는가? 트레이스 전반의 패턴을 보세요.
에이전트 빌드 방식의 변화
진실의 근원이 로직에서 코드에서 트레이스로 옮겨갈 때, 다른 모든 것들도 따라갑니다. 여러분이 코드로 하던 모든 운영 — 디버깅, 테스트, 최적화, 모니터링 — 이제 트레이스를 중심으로 해야 합니다. 실제로 이것이 무엇을 의미하는지 살펴봅시다.
디버깅은 트레이스 분석이 된다
사용자가 “에이전트가 실패했다”고 보고하면, 코드를 열어 버그를 찾지 않습니다. 트레이스를 열어 추론이 어디서 잘못되었는지 봅니다. 에이전트가 과제를 오해했는가? 잘못된 도구를 호출했는가? 루프에 갇혔는가?
“버그”는 여러분의 코드의 로직 에러가 아닙니다. 에이전트가 실제로 한 것의 추론 에러입니다.
예시: 한 에이전트가 동일한 실패한 API 호출을 포기하기 전까지 다섯 번 재시도합니다. 여러분의 코드에는 재시도 로직이 있습니다 — 그것은 잘 동작합니다. 버그는 에이전트가 에러 메시지로부터 학습하지 않는다는 것입니다. 이는 트레이스에서만 보입니다: 동일한 도구 호출, 동일한 파라미터, 동일한 실패, 반복.
추론에 브레이크포인트를 설정할 수 없다
전통적인 소프트웨어에서는, 버그를 찾으면 코드에 브레이크포인트를 설정합니다.
AI 에이전트에서는, 추론에 브레이크포인트를 설정할 수 없습니다. 결정은 모델 내부에서 일어납니다.
하지만 트레이스 + 플레이그라운드를 사용해 ‘로직’에는 브레이크포인트를 설정할 수 있습니다. 특정 시점의 트레이스를 엽니다 — 에이전트가 잘못된 결정을 내리기 직전. 그 정확한 상태를 플레이그라운드에 로드합니다. 플레이그라운드는 코드 대신 추론을 위한 디버거와 같습니다.
여러분은 볼 수 있습니다: 에이전트가 어떤 컨텍스트를 가지고 있었는지? 메모리에 무엇이 있었는지? 어떤 도구가 사용 가능했는지? 프롬프트는 어떻게 보였는지? 그런 다음 반복합니다 — 프롬프트를 조정하고, 컨텍스트를 바꾸고, 다른 접근을 시도하고 — 에이전트가 더 나은 결정을 내리는지 확인합니다.
테스트는 평가(Eval) 중심이 된다
이제 로직의 진실의 근원이 트레이스에 있으므로, 여러분은 그 트레이스를 테스트해야 합니다. 이는 두 가지를 의미합니다:
첫째: 트레이스를 테스트 데이터셋에 추가하는 파이프라인이 필요합니다. 에이전트가 실행될 때, 트레이스를 캡처하여 평가할 수 있는 데이터셋에 추가합니다.
둘째: 프로덕션에서 트레이스를 평가해야 합니다. 전통적인 소프트웨어에서는, 배포 전에 테스트하고 출하합니다. AI에서는, 에이전트가 비결정적이므로 품질 저하와 드리프트를 포착하기 위해 프로덕션에서 지속적으로 평가해야 합니다.
성능 최적화가 변화한다
전통적인 소프트웨어에서는, 뜨거운 루프를 찾고 알고리즘을 최적화하기 위해 코드를 프로파일합니다. AI 에이전트에서는, 불필요한 도구 호출, 중복 추론, 비효율적 경로 같은 의사결정 패턴을 찾기 위해 트레이스를 프로파일합니다. 병목은 에이전트의 결정에 있으며, 그것들은 트레이스에만 존재합니다.
모니터링은 업타임에서 품질로 이동한다
에이전트는 오류 0으로 “가동 중”일 수 있지만 여전히 매우 형편없이 수행할 수 있습니다 — 잘못된 과제를 성공한다든가, 10배 비용으로 비효율적으로 성공한다든가, 정확하지만 도움이 되지 않는 답을 준다든가.
여러분은 ‘시스템 상태’뿐만 아니라 ‘의사결정의 품질’을 모니터링해야 합니다 — 과제 성공률, 추론 품질, 도구 사용 효율. 트레이스를 샘플링하고 분석하지 않으면 품질을 모니터링할 수 없습니다.
협업은 관측성(Observability) 플랫폼으로 이동한다
전통적인 소프트웨어에서는, 협업이 GitHub에서 이루어집니다. 코드를 리뷰하고, PR에 댓글을 남기고, 이슈에서 구현을 논의합니다. 코드는 모두가 함께 작업하는 산출물입니다.
AI 에이전트에서는, 로직이 코드에 있지 않습니다 — 트레이스에 있습니다. 따라서 협업은 트레이스가 있는 곳에서 이루어져야 합니다. 물론 오케스트레이션 코드를 위해 여전히 GitHub를 사용합니다. 하지만 에이전트가 왜 잘못된 결정을 내렸는지 디버깅할 때는, 트레이스를 공유하고, 특정 의사결정 지점에 댓글을 추가하고, 왜 이 경로를 선택했는지 논의해야 합니다. 여러분의 관측성 플랫폼은 단지 모니터링 도구가 아니라 협업 도구가 됩니다.
제품 분석은 디버깅과 통합된다
전통적인 소프트웨어에서는, 제품 분석은 디버깅과 분리되어 있습니다. Mixpanel은 사용자가 무엇을 클릭했는지 알려줍니다. 에러 로그는 무엇이 깨졌는지 알려줍니다. 서로 다른 질문을 위한 다른 도구입니다.
AI 에이전트에서는, 이것들이 합쳐집니다. 사용자 행동을 에이전트 행동을 이해하지 않고는 이해할 수 없습니다. 분석에서 “30%의 사용자가 좌절하고 있다”를 보면, 에이전트가 무엇을 잘못했는지 보기 위해 트레이스를 열어야 합니다. “사용자들이 데이터 분석 기능을 요청하고 있다”를 보면, 에이전트가 이미 어떤 도구를 선택하고 있고 무엇이 잘 작동하는지 보기 위해 트레이스를 봐야 합니다. 사용자 경험은 에이전트의 결정이며, 그 결정은 트레이스에 문서화됩니다 — 따라서 제품 분석은 트레이스를 기반으로 구축되어야 합니다.
전환을 이루세요
전통적인 소프트웨어에서는, 코드가 여러분의 문서입니다. AI 에이전트에서는, 트레이스가 여러분의 문서입니다.
전환은 간단합니다: 의사결정 로직이 여러분의 코드베이스에서 모델로 이동하면, 진실의 근원은 코드에서 트레이스로 이동합니다.
여러분이 코드로 하던 모든 것 — 디버깅, 테스트, 최적화, 모니터링, 협업 — 이제 트레이스로 합니다.
이를 실현하려면, 좋은 관측성이 필요합니다. 검색, 필터, 비교가 가능한 구조화된 트레이싱. 전체 추론 체인을 볼 수 있는 능력 — 어떤 도구가 호출되었는지, 얼마나 시간이 걸렸는지, 비용이 얼마였는지. 역사적 데이터에 대한 평가(evals)를 실행하여 시간이 지남에 따른 품질을 모니터링할 수 있는 능력.
만약 여러분이 에이전트를 만들고 있으면서 이것을 갖추지 못했다면, 눈가리고 작업하고 있는 것입니다. 중요한 로직은 오직 그 트레이스에만 존재합니다.