The Missing Layer After Launch - Raphael Kalandadze, Wandero AI
📺 원본 영상: The Missing Layer After Launch - Raphael Kalandadze, Wandero AI
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-05
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 차트, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
Raphael Kalandadze는 이 강연에서 AI 에이전트 개발의 진짜 난점은 출시 이전이 아니라 출시 이후에 시작된다고 주장한다. 데모에서 잘 작동하던 에이전트가 실제 사용자와 수백, 수천 건의 대화를 처리하기 시작하면, 개발자는 시스템이 실제로 잘 작동하는지, 어디서 실패하고 있는지, 어떤 개선이 필요한지 감각을 잃기 쉽다.
강연의 핵심은 바로 이 출시 이후의 관측과 개선 체계를 “missing layer”로 정의하는 데 있다. 그는 로그 분석 에이전트, 리뷰 에이전트, 세션 분석기, 브라우저 기반 사용자 시뮬레이션 에이전트 등을 통해 에이전트 시스템이 스스로를 관찰하고 고치는 Meta Harness(메타 하네스)를 구축해야 한다고 설명한다.
출시가 끝이 아니라 시작인 이유
강연자는 많은 AI 에이전트 논의가 “만들었다, 작동했다, 출시했다”는 지점에서 끝난다고 지적한다. 그러나 실제 프로덕션 환경에서는 출시가 끝이 아니라 피드백 루프가 시작되는 순간이다. 최신 모델의 도움으로 제품이나 스타트업을 며칠 또는 몇 주 만에 만들고, 수십만 줄의 코드를 생성하며, 많은 토큰을 소비하는 일은 과거보다 훨씬 쉬워졌다. 문제는 그 이후에 시스템이 실제 사용자와 마주했을 때 어떤 일이 벌어지는지를 이해하는 것이다.
전통적인 소프트웨어에서도 모니터링, 로그, 장애 감지, 문제 수정은 중요했다. 하지만 에이전트 시스템에서는 이 문제가 훨씬 더 복잡해진다. 일반적인 애플리케이션은 버튼, 화면, 고정된 플로우, 사전 정의된 테스트 케이스를 중심으로 검증할 수 있지만, 에이전트는 사용자의 요구에 따라 매우 넓은 행동 범위를 가진다. 강연자가 예로 든 Claude Code나 Codex 같은 도구는 사용자가 무엇을 요구하느냐에 따라 전혀 다른 작업 경로를 밟을 수 있으며, 그 모든 대화를 출시 전에 작성하거나 테스트하는 것은 사실상 불가능하다.
이 지점에서 개발자가 잃는 것은 단순한 로그 가시성이 아니라 “자기 시스템에 대한 감각”이다. 시스템이 좋아지고 있는지, 나빠지고 있는지, 특정 문제가 우연히 회복된 것인지, 아니면 구조적인 결함의 초기 신호인지 알기 어려워진다. 강연자는 출시 후 가능한 한 빨리 루프를 닫아야 하며, 이 피드백 루프는 제품 자체만큼 중요하거나 때로는 더 중요하다고 강조한다.
기존 테스트가 에이전트를 충분히 보호하지 못하는 이유
강연자는 자신들도 유닛 테스트, 정규식 기반 검사, 룰 기반 체크, 고객 대화 시뮬레이션 스크립트 등을 시도했다고 설명한다. 이런 방식은 어느 정도 도움이 되지만, 전체 문제의 극히 일부만 포착한다. 실제 고객은 항상 예상과 다르게 행동하고, 사용자의 요청은 너무 많고 서로 다르기 때문에 모든 경우를 미리 적어둘 수 없다.
LLM(Large Language Model, 대규모 언어 모델)이 비결정적이라는 점도 이 문제를 키운다. 같은 입력도 다른 경로로 이어질 수 있고, 입력의 사소한 차이가 완전히 다른 도구 호출, 추론 과정, 결과물로 이어질 수 있다. 따라서 사전 테스트의 커버리지를 아무리 넓혀도 프로덕션에서 실제로 어떤 궤적이 발생할지 완전히 예측하기 어렵다.
더 위험한 문제는 실패가 스스로를 숨긴다는 점이다. 에이전트가 긴 작업 중간에서 어려움을 겪었지만 우연히 회복했거나, 다른 도구 호출을 시도해 우회 경로를 찾았거나, 사용자가 보기에는 결과가 나온 것처럼 보일 수 있다. 이 경우 대시보드에는 빨간 경고가 뜨지 않고, 표면적으로는 성공처럼 보인다. 그러나 강연자는 이런 상황이 신뢰성 문제의 조기 경고라고 본다. 에이전트의 성공이 “운”에 의존한다면, 그것은 아직 안정적인 시스템이 아니다.
강연자는 Anthropic의 블로그를 언급하며, 에이전트가 실제로 동작 여부를 확인하지 않고 기능을 완료했다고 표시하는 경우가 있다고 덧붙인다. 이는 에이전트 시스템에서 “작업 완료”라는 상태가 실제 사용자 가치와 일치하지 않을 수 있음을 보여준다. 예를 들어 Wandero AI의 여행 일정 생성 사례에서, 에이전트가 플로우를 끝내고 여행 일정을 만들었더라도 다른 서비스를 예약하거나 가격 계산을 잘못했다면 기술적으로는 성공처럼 보이지만 사용자 관점에서는 실패한 것이다.
로그는 출발점이지만, 로그만으로는 부족하다
출시 이후 시스템을 이해하기 위한 가장 명확한 출처는 로그다. 로그에는 구조화된 정보가 담겨 있고, 기계는 인간보다 훨씬 빠르게 거대한 로그 벽을 탐색하고 필터링할 수 있다. 그래서 강연자는 로그를 에이전트에게 넘겨 문제를 진단하게 하는 것이 가장 자연스러운 첫 단계라고 설명한다.
그러나 실제로 로그 분석 에이전트를 만들기 시작하면, 이 작업이 단순한 검색이나 필터링이 아니라 상당한 추론을 요구한다는 사실이 드러난다. 에이전트는 문제가 실제 버그인지 단순한 노이즈인지 구분해야 하고, 시간 흐름 속에서 대화나 작업 궤적을 따라가야 하며, 특정 현상이 근본 원인의 증상인지 판단해야 한다. 다시 말해 에이전트를 운영하는 일 자체가 또 하나의 에이전트 문제로 바뀐다.
강연자가 제안하는 루프는 로그와 트레이스, 작업 궤적을 에이전트에게 제공하고, 여기에 코드베이스 접근 권한까지 부여해 문제를 진단하게 만든 뒤, 수정 PR(Pull Request)을 생성하도록 하는 방식이다. 이때 PR을 만든 에이전트와 별도로 리뷰 에이전트를 두는 것이 중요하다. PR 생성 에이전트는 문제를 고치려는 방향으로 강하게 편향될 수 있기 때문에, 별도의 신선한 컨텍스트를 가진 리뷰 에이전트가 다른 관점에서 변경 사항을 비판하고, 집중 테스트를 실행하며, 위험과 엣지 케이스를 검토하도록 해야 한다.
💡 [영상 참조] 강연자는 이 부분에서 로그, 트레이스, 코드베이스, 자동 PR, 리뷰 에이전트로 이어지는 흐름을 설명합니다. 화면의 다이어그램이나 예시는 음성만으로는 완전히 확인할 수 없으므로 상세 내용은 원본 영상을 참조해야 합니다.
첫 번째 루프: 로그 모니터링 에이전트와 자동 PR
강연자가 소개한 첫 번째 핵심 흐름은 빠른 감지와 수정을 위한 로그 모니터링 에이전트다. 이 에이전트는 트레이스, 로그, 코드베이스에 접근할 수 있으며, 1시간마다 또는 15분마다 실행되어 최근 구간에서 사용자가 막혔는지, 어떤 문제가 반복되는지, 즉시 수정해야 할 심각한 문제가 있는지 분석한다. 문제가 확인되면 PR을 생성하거나 Slack 알림을 보낸다.
이 방식의 장점은 개발팀이 문제를 거의 실시간에 가깝게 포착하고, 국소적인 수정안을 빠르게 받을 수 있다는 점이다. 강연자는 이러한 시스템을 구축하면 30분 안에 PR이 준비될 수 있고, 팀은 무엇이 일어났는지 훨씬 쉽게 파악할 수 있다고 말한다. 특히 PR 설명에는 문제 요약, 메타데이터, Mermaid 다이어그램, ASCII 테이블, HTML 아티팩트 등이 포함될 수 있어 사람이 빠르게 맥락을 이해하는 데 도움을 준다.
09:50 - 로그 모니터링 에이전트가 생성한 PR 예시와 문제 설명, 메타데이터, 다이어그램 구성이 소개되는 구간
다만 이 시스템은 그대로 신뢰할 수 있는 자동화가 아니라, 지속적인 보정과 신뢰성 확보가 필요한 운영 시스템이다. 강연자는 많은 팀이 비슷한 방식을 사용하고 있지만, 그 중요성을 충분히 높게 평가하지 않는다고 지적한다. 자동 PR 생성 자체보다 중요한 것은 그 루프를 믿을 수 있도록 교정하고, 에이전트가 실제 문제와 노이즈를 구분하며, 사람이 병목이 되지 않는 처리 체계를 갖추는 것이다.
10:16 - Slack 알림 또는 경고성 알림 예시를 통해 빠른 피드백 루프의 역할을 설명하는 구간
리뷰 에이전트와 Human-in-the-loop의 현실적 위치
자동 PR이 많아질수록 사람의 리뷰가 병목이 될 수 있다. 강연자에 따르면 Wandero AI에서는 PR 에이전트와 리뷰 에이전트가 세 명의 팀원이 하루에 처리할 수 있는 것보다 10배 많은 PR을 보낼 수 있다. 따라서 자동화된 루프를 도입하는 순간, 팀은 이 PR들을 어떻게 정리하고 우선순위를 매기며, 어떤 것은 사람이 보고 어떤 것은 자동으로 닫을지에 대한 운영 체계를 마련해야 한다.
그럼에도 강연자는 현재 시점에서는 사람을 완전히 제거하기보다는 먼저 루프를 닫는 것이 중요하다고 본다. 리뷰 에이전트가 좋은 설명, 아티팩트, 위험 요약을 제공하면 사람은 몇 분 안에 문제의 성격을 이해할 수 있고, 중요한 변경만 검토할 수 있다. 이 방식은 사람을 즉시 제거하려는 접근보다 현실적이다. 먼저 사람이 병목이 될 정도로 루프가 잘 작동하게 만들고, 그 다음에 필요한 경우 사람의 개입을 줄이는 순서가 더 낫다는 것이다.
리뷰 에이전트의 역할은 단순히 PR에 “승인” 또는 “거절”을 표시하는 것이 아니다. 강연자는 리뷰 에이전트가 문제를 다른 각도에서 보고, 변경 사항을 비판적으로 점수화하며, 위험과 엣지 케이스를 설명하고, 필요하면 변경 요청을 남긴다고 설명한다. 몇 차례 반복 후 더 이상 수정이 필요하지 않은 상태가 되면 그때 사람이 루프에 들어온다. 이 구조는 에이전트가 만든 결과물을 다시 에이전트가 견제하도록 만든다는 점에서, 에이전트 운영의 핵심 패턴 중 하나로 볼 수 있다.
11:56 - 리뷰 에이전트의 피드백 예시, 변경 요청, 위험 요소, 엣지 케이스 설명이 등장하는 구간
두 번째 루프: 세션 분석기로 시스템의 건강 상태를 본다
빠른 로그 모니터링 에이전트는 특정 시간 창에서 발생한 국소적인 문제를 찾는 데 유용하다. 하지만 강연자는 이 방식만으로는 시스템 전체의 건강 상태를 이해하기 어렵다고 말한다. 1시간 단위 로그를 보는 에이전트는 개별 문제를 잡아내는 데 강하지만, 장기적인 패턴, 반복되는 실패 유형, 사용자 경험의 전체적인 품질을 파악하기에는 한계가 있다.
이를 보완하기 위해 강연자는 Session Analyzer(세션 분석기)를 소개한다. 이 시스템은 수백 개의 대화를 요약하고 평가하며, 각 세션에 점수를 부여하고, 성공률, 비용, 도구 호출 수, 서브에이전트 사용량, 요약 발생 횟수, 감정 분석, 엔티티, 회사별 세션 수 같은 정보를 종합한다. 강연자는 에이전트 이전에는 이런 작업이 사실상 불가능했지만, 이제는 에이전트가 수많은 대화를 읽고 패턴을 연결해 시스템의 높은 수준의 상태를 보여줄 수 있다고 설명한다.
특히 중요한 부분은 단순한 메트릭이 아니라 AI가 제공하는 인사이트다. 세션 분석기는 어떤 문제가 왜 중요한지, 근본 원인이 무엇인지, 어떤 세션이 영향을 받았는지, 어떤 수정이 권장되는지 설명할 수 있다. 강연자가 보여준 대시보드는 실제 대화에서 나온 데이터를 바탕으로 하되, 화면에 표시된 예시는 랜덤화된 데이터라고 설명했다. 따라서 구체적인 수치나 차트 모양은 원본 영상을 확인해야 하지만, 핵심은 세션 분석기가 개별 버그 수정을 넘어 시스템 전체의 감각을 회복하게 해준다는 점이다.
14:40 - 세션 분석 대시보드에서 시스템 건강 상태, 평균 점수, 성공률, AI 인사이트를 보여주는 구간
💡 [영상 참조] 강연자는 이 시점에서 시스템 건강 상태, 평균 점수, 성공률, 비용, AI 인사이트, 세션별 상세 분석을 담은 대시보드를 보여줍니다. 음성에서 언급된 범위 외의 화면 수치는 확정적으로 해석하지 않는 것이 안전합니다.
15:22 - 세션별 상세 분석, 도구 호출 수, 요약 횟수, 문제 설명과 주의가 필요한 세션을 보여주는 구간
세 번째 루프: 사용자 관점의 Computer Use Agent
로그와 세션 분석은 모두 시스템 내부의 흔적을 기반으로 한다. 그러나 강연자는 이것만으로는 충분하지 않다고 말한다. 실제 사용자는 브라우저를 열고, 로그인하고, UI를 보고, 메시지를 보내고, 결과물을 확인한다. 코드와 로그가 정상이어도 UI에서 문제가 발생하거나, 사용자가 보는 아티팩트가 깨져 있거나, 흐름이 불편할 수 있다.
이 문제를 다루기 위해 강연자는 Computer Use Agent(컴퓨터 사용 에이전트)를 사용한다고 설명한다. 이 에이전트는 브라우저를 열고 로그인한 뒤, 실제 고객처럼 세션을 열고 메시지를 보내며, 결과가 어떻게 보이는지 확인한다. Codex 같은 도구를 이용해 브라우저를 직접 조작할 수도 있지만, 강연자는 이 방식이 느리기 때문에 자신들의 웹사이트와 DOM(Document Object Model)을 잘 아는 전용 스킬을 만들었다고 말한다. 그 결과 웹사이트를 열고, 로그인하고, 세션을 확인하고, 메시지를 보내며, 아티팩트를 점검하는 작업을 더 빠르게 수행할 수 있었다.
17:25 - Computer Use Agent가 웹사이트에 로그인하고 세션을 열어 사용자 관점에서 동작을 확인하는 흐름을 설명하는 구간
다만 이 방식은 많은 토큰을 소비한다. 또한 제대로 작동하려면 로그, 트레이스, 메트릭, 데이터베이스, UI 등 사람이 디버깅할 때 필요한 모든 컨텍스트와 도구 접근 권한을 에이전트에게 제공해야 한다. 강연자는 컴퓨터 사용 에이전트가 문제를 발견했을 때 단순히 화면만 보는 것이 아니라, 트레이스를 분석하고 데이터베이스를 확인해 실제로 무슨 일이 일어났는지 이해할 수 있어야 한다고 강조한다.
Meta Harness: 모델만으로는 부족하다
강연자가 말하는 Meta Harness(메타 하네스)는 모델 하나를 더 강하게 만드는 개념이 아니다. 이는 로그, 트레이스, 메트릭, 코드베이스, 데이터베이스, UI, PR 생성, 리뷰, 알림, 사람의 개입이 모두 연결된 운영 체계다. 이 체계 안에서 에이전트는 추측으로 문제를 고치는 것이 아니라, 실제 문제에 접근하고, 근거를 확인하고, 수정안을 만들며, 다시 검증을 받는다.
이 관점은 AI 에이전트 제품을 만드는 팀에게 중요한 전환을 요구한다. 모두가 같은 모델을 사용할 수 있고, 비슷한 에이전트 구조를 만들 수 있는 시대에는 출시 자체가 경쟁력이 되기 어렵다. 차이는 출시 이후 어떤 내부 시스템을 통해 문제를 발견하고, 제품을 매일 개선하며, 시스템의 건강 상태를 유지하는가에서 생긴다.
강연자는 오늘날 제품을 출시하는 일은 가장 쉬운 부분이 되었고, 프로덕션 에이전트를 만들고 싶다면 먼저 루프를 닫아야 한다고 결론짓는다. 자동 PR, Slack 알림, 세션 분석, 브라우저 기반 검증은 각각 별개의 도구처럼 보이지만, 모두 하나의 목표로 수렴한다. 그것은 실제 사용자와 만난 에이전트가 무엇을 하고 있는지 감각을 회복하고, 발견한 문제를 빠르게 학습과 개선으로 연결하는 것이다.
마무리 / 핵심 정리
이 강연의 가장 중요한 메시지는 “에이전트는 출시 이후에야 진짜로 검증된다”는 점이다. 데모에서 성공한 에이전트는 제한된 상황에서만 성공한 것이며, 실제 프로덕션에서는 예측할 수 없는 사용자 요청, 비결정적인 모델 동작, 복잡한 도구 호출, 숨겨진 실패, UI 문제, 비용 문제까지 함께 다뤄야 한다.
Raphael Kalandadze가 제안하는 해법은 관측 가능성(Observability)을 넘어선 운영 루프다. 로그를 읽는 에이전트가 문제를 찾고, 코드베이스를 이해해 PR을 만들며, 리뷰 에이전트가 이를 비판적으로 검토하고, 세션 분석기가 전체 시스템의 건강 상태를 보여주며, 컴퓨터 사용 에이전트가 실제 사용자 경험을 점검한다. 이 모든 요소가 연결될 때, 팀은 더 이상 출시 후 시스템을 “느낌”으로 운영하지 않고, 실제 대화와 실제 실패에서 매일 학습하는 구조를 만들 수 있다.
결국 missing layer는 특정 대시보드나 특정 에이전트 하나가 아니다. 그것은 프로덕션 에이전트가 스스로를 관찰하고, 설명하고, 고치고, 다시 검증하도록 만드는 폐쇄형 피드백 루프다. 강연자의 표현을 빌리면, 오늘날 출시 자체는 쉬운 부분이고, 어려운 부분은 출시 이후에 제품을 살아 있는 시스템으로 운영하는 일이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | The Missing Layer After Launch - Raphael Kalandadze, Wandero AI |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-05 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.