메타데이터
- 채널: Tech Bridge
- 영상 링크: https://www.youtube.com/watch?v=bWCkf2yTIJc
- 발행일: 2026-08-01
- 영상 길이: 20:08
- 처리일: 2026-08-01
- 주제: AI 관찰 가능성(Observability) 플랫폼 위에서 동작하는 자가 수정(self-healing) AI 에이전트 "Signal" 소개 발표 + Q&A
1계층 — 핵심 요약
이 발표는 관찰 가능성(observability) 플랫폼 스타트업 창립자가 자사의 신규 자가 수정 에이전트 제품 **"Signal"**을 소개하는 세션이다. 핵심 주장은 "AI 시스템을 디버깅하는 시대(observability 1.0, 인간이 UI/그래프를 클릭)"에서 "AI 에이전트가 스스로 문제를 발견·진단·해결하는 시대(observability 2.0)"로 전환이 일어나고 있다는 것이다. Signal은 프로덕션 환경에서 발생하는 추적(trace)·로그·평가(eval) 데이터를 주기적/이벤트 기반으로 감시하다가, 문제가 감지되면 백그라운드에서 에이전트가 원인을 조사하고 수정안(혹은 최소한 "냉간 시동(cold start)" 형태의 조사 결과)을 사람에게 제시한다. 사람의 역할은 "직접 답을 찾는 사람(answerer)"에서 "에이전트가 제시한 조사 결과를 검토하는 사람(reviewer)"으로 바뀐다.
2계층 — 핵심 발언 및 근거 구조
배경: 발표자의 경험
- 발표자는 회사 창립자(founder)이자 "빌더(builder)"로 자신을 소개하며, 제품팀에 알렉스(Alex)라는 AI 에이전트 동료가 있다고 언급한다.
- "직접 개발한 에이전트의 첫 번째 버전은 솔직히 형편없었습니다. 아주 오래전, 아마 2년 전쯤이었죠. 이 분야에서 처음으로 그런 일을 한 사람이 있었거든요."
- 회사가 구축해온 많은 기능은 자신들이 실제로 에이전트를 구축하면서 겪은 경험에서 나온 것이며, Signal은 이 자동화 여정의 "차세대 버전"이다.
문제 제기: 창업자라면 누구나 겪는 경험
- "사용하시는 플랫폼에 문제가 발생했습니다. 늦은 밤이고, 당신은 그걸 고치러 가고 싶어합니다. 그리고 사실 그렇게 하려면 엄청난 에너지가 필요해요."
- 이 공통의 페인포인트에서 출발해 "미래의 자동화 시스템은 어떤 모습일지" 를 다룬다고 발표 프레임을 설정한다.
Observability 1.0 → 2.0 전환
- "관찰 가능성은 예전에는 인간의 전유물이었습니다. 예전에는 클릭하는 UI, 클릭하는 그래프, 그런 것들이 있었죠."
- "오늘날은 2.0 버전이 많이 등장하고 있다고 생각하는데, 이는 코딩 에이전트와 같은 요소들의 조합과 같습니다. 파이로스코프(Pyroscope)나 구글 클라우드 같은 걸 위한 스킬을 개발하신 분들은 이러한 기술이 시스템 디버깅에 도움이 됩니다."
- 원격 측정(telemetry)의 비유: "원격 측정은 마치 시스템에서 뿜어져 나오는 연기와 같아서, 이러한 에이전트들이 문제를 해결할 수 있도록 해주는 역할을 합니다. 코드에서 어떤 경로를 거쳤는지 알려줍니다. 그게 없으면 추측만 할 수밖에 없고, 결과는 수백만 가지로 예측 불가능할 겁니다."
- 목표 재정의: "우리가 여기서 정말로 하려는 것은 스스로 문제를 해결하는 자율적인 시스템을 어떻게 구축하는가 하는 것입니다."
루프 반전(Loop Inversion) — 이 발표의 핵심 아이디어
- 기존 방식: "사람이 문제를 살펴보고 에이전트가 수정하는 방식."
- 새 방식: "이제는 사람이 시스템에서 발생한 오류를 기반으로 문제점을 파악한 채로 아침에 일어날 수 있게 되었습니다. 에이전트가 실제로 문제를 제기하고 있는 겁니다. 사람이 데이터를 보기 전에 먼저 데이터를 보는 것입니다."
- 비유: "사람들이 티켓을 손에 쥐고 보고 있는 것과 관련된 어떤 심층적인 증거를 확보하는 것과 같습니다. 실제로 그것을 보기도 전에 이미 눈앞에 놓여 있는 증거 말이죠."
- 단, 현재는 완전 자동화가 아니라 "2단계와 3단계는 사람이 주도적으로 진행"하는 반자동 단계임을 명시한다.
병목의 이동: 속도가 아니라 신뢰(confidence)
- "에이전트 속도로 구축은 가능하지만, 현재로서는 이 속도로는 시스템을 실질적으로 개선할 수 없습니다. ... 병목 현상은 더 이상 해결책이 아닙니다."
- "숙련된 코딩 에이전트를 사용해 본 사람들은 대부분 '내가 제대로 하고 있는 걸까?'라는 자신감 부족이 가장 큰 걸림돌이라고 생각합니다. 이 문제의 상당 부분은 이 해결책이 추진해야 할 올바른 해결책인지에 관한 것입니다."
- 즉, 에이전트가 코드를 빨리 짤 수 있는 것은 이미 해결된 문제이고, 남은 진짜 문제는 "이 수정이 옳은 방향인지 사람이 확신할 수 있는가"라는 신뢰/검증의 문제라는 진단이다.
트리거와 맥락(Context)의 역할
- "관찰 플랫폼과 연결되는 스킬의 마법은 바로 맥락을 파악할 수 있다는 점입니다. 상담원(에이전트)은 문제 해결을 시작하기 위해 무엇이 필요한지, 무엇을 살펴봐야 하는지 결정할 수 있습니다."
- 트리거는 두 유형: 주기적(periodic)(예: 5분마다) / 이벤트 기반(event-driven)(오류 발생 시).
- 증거의 재료: 추적 기록(trace) > 로그 > "요즘 대부분의 AI 시스템은 에이전트 프레임워크의 흔적을 핵심에 간직하고 있어서" 흔적(trace)부터 살펴보는 것이 출발점이 된다.
- "일반적으로 이러한 요소들이 여러 조합으로 나타나는데, 맥락과 로그를 작성하는 데 사용되는 기술, 저장소가 거기에 있을 것"이라며 trace + log + repository(코드) 3요소의 조합을 강조한다.
아키텍처 원리: 데이터 → 저장소 파일 → 수정
- "에이전트가 다운로드하는 프로덕션 로그 또는 추적 정보는 일반적으로 저희 스킬이 저장소에 작은 임시 파일을 다운로드하는 방식입니다."
- "실제로 무슨 일이 일어났는지, 코드가 얼마나 필요한지 등을 파악하고, 이 모든 것을 종합해서 수정 사항을 적용하는 거죠. 저장소에 있는 데이터와 파일 형식, 그리고 코드가 모두 올바른 조합이어야 한다는 거죠. 그게 바로 이 제품의 매력이에요."
로컬 → 샌드박스로의 이동
- "저는 우리 모두가 노트북에서 샌드박스로 넘어가는 이러한 변화를 느끼고 있다고 생각합니다."
- 권장 워크플로우: "먼저 로컬 환경, 즉 노트북에서 제대로 작동하는지 확인한 다음, 저희와 같은 관찰 플랫폼을 기반으로 이벤트 기반으로 작동하도록 확장하십시오." 예약 실행 또는 오류 발생 시 실행 둘 다 지원.
사람의 역할 변화와 그 대가
- "당신의 업무는 답변자에서 검토자로 바뀌게 됩니다. 흔적과 평가가 어떤 형태로든 사라지지 않는다는 것입니다. 그들은 이제 그 순환 고리의 핵심적인 부분이 되었습니다."
- "추적하는 횟수가 10배 더 많아질 겁니다. ... 예전에는 그렇게 하지 않았죠. 왜냐하면 인간은 모든 로그를 파헤칠 수 없었기 때문입니다. 그건 그냥 소음일 뿐이야. 하지만 로그를 기록하고 추적하는 것이 소프트웨어에 대한 모든 해답을 제공하는 것은 아닙니다."
- 즉, 로그/추적량이 급증하는 것 자체는 인간에게는 의미가 없었지만, 이를 소비하는 주체가 에이전트로 바뀌면서 "더 많은 계측(instrumentation)"이 다시 유의미해진다는 논리다.
"AI용 SRE"에 대한 신중한 태도
- "제 생각에는 이것이 SRE, 즉 AI용 SRE를 구매하는 데 도움이 되는 무언가라고 생각합니다. 하지만 제 생각에는 아직 밝혀지지 않은 부분이 너무 많은 것 같아요."
- 실질적으로는 "클라우드 코드, 커서를 사용한 로컬 디버깅 경험을 주기적으로 실행하는 것뿐"이라며 과장하지 않고 현재 단계를 정직하게 규정한다. "모래밭을 고르고, 장비를 고르고, 기술을 고르세요. 저희가 여러 가지 음식을 미리 구워드릴 거예요."
3계층 — 사례
사례 1: 알렉스(Alex) 에이전트의 실제 버그 — "업데이트 취소" 오류
- 알렉스는 발표사 제품 내부의 AI 도우미로, 작업 목록(업데이트) 관리를 담당한다.
- 실제 사례: "스트리밍 이벤트가 취소된 경우"에 발생한 버그. 업데이트를 처리하려고 두 함수를 여러 번 호출하는 과정에서 오류가 발생했다.
- Signal이 백그라운드에서 이 문제를 자동으로 감지·조사해 "문제를 제기"했고, 해결책 자체는 "한두 줄짜리 간단한 수정"이었다. 발표자는 이런 소규모 수정이 "이상적인 사례"이며, 실제로는 규모가 클수록 사람이 더 주도적으로 개입해야 한다고 인정한다.
사례 2: 금융 거래(주식 트레이딩) 에이전트 데모
- 제품 데모로 "금융 거래 중개 에이전트"를 예시로 사용하되, 발표자는 명확히 선을 긋는다: "저는 금융 거래 에이전트가 되는 것을 추천하지 않습니다. 그걸로는 돈을 벌기 어려울 거예요. 적어도 아직은 아니에요."
- 이 데모의 목적은 수익화가 아니라, "현재 많은 사람들이 주식 거래에 대해 질문하는 내용에 답변을 제공하는" 상황에서 "이 방식이 실패할 수 있는 여러 방법"을 시연하기 위함이다.
사례 3: 제품 라인업 — AX(SaaS) vs Phoenix(오픈소스)
- 회사의 SaaS 플랫폼 이름은 AX이며, VPC 배포도 지원한다.
- 오픈소스 버전인 Phoenix도 제공하지만, Signal 기능 자체는 현재 AX SaaS 플랫폼에서만 사용 가능하다.
- 데모에서는 GitHub 저장소 연동, 평가(eval) 도구 생성, 특정 문제를 데이터셋으로 저장해 재사용하는 기능, Google Cloud 등 다양한 로깅 시스템 연동을 보여준다.
사례 4: VPC 배포 필요성 — Uber, Booking.com 등 실사용 고객
- "많은 고객들이 자사의 프로덕션 시스템을 Anthropic에 연결하는 것을 원하지 않습니다. 그래서 저희는 Uber부터 Booking.com에 이르기까지 수많은 유명 기업의 VPC에 서비스를 설치하고 있습니다."
- 이런 고객사는 "연결을 외부로 유출하고 싶어하지 않지만, VPC에 가상 머신을 설치하고 연결하는 데에는 매우 익숙"하다는 것이 회사의 관찰이다.
- 샌드박스 선택도 자유롭다: 자체 샌드박스, Rise Sandbox, Daytona 등 고객이 이미 관계를 맺어온 어떤 플랫폼이든 사용 가능.
사례 5: 커스터마이징 — "야, 공격적으로 굴지 마" / "보안 문제를 찾아보세요"
- 사용자가 하네스(harness)와 샌드박스를 직접 선택하고, 에이전트가 조사할 "주제"까지 직접 지정할 수 있다.
- 예시 프롬프트 톤: "야, 공격적으로 굴지 마" 또는 "보안 문제를 찾아보세요." 사전 검증된 스킬을 프리셋으로 추가할 수도 있다.
4계층 — 시사점 및 Q&A
Q&A 1 — "왜 클라우드 코드가 데이터에 직접 연결해서 트레이스를 읽고 스스로 PR까지 푸시하게 하면 안 되나요?"
- 질문자 요지: 왜 Cloud Code 같은 범용 코딩 에이전트가 관찰 데이터에 직접 연결해서 모든 작업(조사부터 PR 푸시까지)을 수행하게 하지 않는가.
- 발표자 답변: "답은 '그래야 한다'입니다." 다만 그것이 실제로 잘 작동하려면 "잘 설계된 기술(스킬)"이 필요하다.
- 핵심 설계 원칙: 관련 데이터(특정 세션·추적 기록 등)를 정확히 찾아 파일 형식으로 저장소에 저장하는 것이 우선이다. "이 하네스는 파일 다루기(줄질)에 정말 탁월"하기 때문에, 데이터를 파일로 만들어주면 그 이후 처리는 강점을 발휘한다.
- 저장소에는 10MB급 파일이 쌓이기도 하며, 이 데이터를 기반으로 "정말 훌륭하게 작동하도록 스킬을 설계"하고 클로드에게 "충분한 기술(스킬)"을 부여해야 한다.
- 구체 사례: 메모리 문제를 찾는 Pyroscope 스킬은 고객별로 그룹을 나누어 특정 고객이 문제를 일으키는지 확인할 수 있다.
- 결론: "클로드가 정말로 잘 활용할 수 있도록 스킬 활용 영역을 설계해야 해요. 그리고 그건 단순히 클로드에게 데이터를 가리키라고 하는 것과는 다릅니다." — 즉 "데이터 접근권 부여"와 "스킬 설계"는 다른 문제라는 것이 핵심 논지다.
Q&A 2 — "프로덕션 문제 신호가 왔을 때 평가(evaluation)는 어디에 쓰이나요?"
- 질문자 요지: trace 개념은 이해하지만, "프로덕션 환경에서 문제가 생겼다"는 신호가 왔을 때 evals가 정확히 어떤 역할을 하는지 궁금하다.
- 발표자 답변:
- 평가는 일반적으로 프로덕션 추적(trace)에 추가로 실행되며 이를 "온라인 평가(online evaluation)"라 부른다. eval은 추적 자체에 대한 부가 데이터이며, 에이전트는 trace에서 평가 값을 집계하는 기술을 갖추고 있다.
- 사용자가 제공한 스킬을 통해 하네스는 추적 데이터에서 평가 데이터를 함께 가져올 수 있다.
- 이는 "1세대 평가 방식"과 유사하며, LLM judge 요소가 AI 레이어로서 주기적으로 시스템을 실행·평가하는 역할을 한다. 다만 차이는 "데이터에 사전 처리된 정보를 조금 더 추가하는 것"이다.
- Signal이 실행될 때는 원시 데이터뿐 아니라 이렇게 레이어링된 평가 데이터도 함께 사용한다.
- 구체적 용도: 과거에 반복적으로 관찰된 실패 패턴(예: 프롬프트 인젝션 공격, 특정 응답 오류 유형)에 대한 평가자(evaluator)를 만들어두면, "다음번에 같은 문제가 발생하면 잡아낼 수 있"다. 이는 "항상 실행되고 있는 AI 평가 도구"에 가깝다.
- 부가 포인트: LLM judge는 대규모 운영이 가능하며, 실제 고객 중 일부는 전체 데이터셋에 걸쳐 LM을 평가 기준으로 사용하고, 이 경우 데이터가 주기적인 경향을 보이는 경우가 많다고 언급.
종합 시사점
- 자율 디버깅의 현실적 단계론: "완전 자율 수정"이 아니라 "사람보다 먼저 증거를 확보해 제시하는 조사관" 단계가 현실적인 다음 단계라는 진단은, AI 에이전트 제품을 과대 포장하지 않고 실제 도입 가능한 수준으로 설계하려는 실용적 관점을 보여준다.
- 병목의 재정의: 코드를 빨리 짜는 능력이 아니라 "이 수정이 옳다는 확신"이 현재 AI 코딩/디버깅 도입의 진짜 병목이라는 통찰은, 이후 관찰가능성·평가(eval) 인프라 투자의 정당성을 뒷받침하는 핵심 논리다.
- 로그/추적 증가의 재해석: 과거에는 "인간이 소화 못 하는 소음"이었던 대량의 로그·추적 데이터가, 소비 주체가 AI 에이전트로 바뀌면서 오히려 "10배 더 계측해야 하는" 자산으로 재평가된다는 관점은 관찰가능성 산업 전반에 시사하는 바가 크다.
- "스킬 설계"와 "데이터 접근"의 구분: 범용 코딩 에이전트에 데이터 접근권만 주는 것과, 도메인에 맞게 정교하게 설계된 스킬을 제공하는 것은 다른 문제라는 지적은, 에이전트 프로덕트를 만드는 팀들에게 실무적으로 유용한 설계 원칙이다.
- VPC/온프레미스 배포에 대한 시장 현실: Uber, Booking.com 등 대기업 고객이 프로덕션 데이터를 외부 AI 벤더에 직접 노출하길 꺼린다는 점은, 엔터프라이즈向 AI 에이전트 제품에서 VPC 배포·샌드박스 선택권이 필수 요건임을 보여준다.