🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

시그널에서 PR까지 이어지는 스스로 고치는 AI 에이전트의 핵심은 코드 생성 능력보다 트레이스·로그·저장소·평가 데이터를 결합해 신뢰할 수 있는 수정 근거를 만드는 데 있다.

📌 핵심 요점

1. 문제 탐지 순서의 전환: Signal은 사람이 장애를 발견한 뒤 에이전트에 수정을 맡기는 대신, 오류·주기적 점검을 계기로 운영 데이터를 먼저 분석하고 증거가 포함된 이슈를 생성한다.
2. 운영 데이터와 코드의 결합: 트레이스와 로그를 저장소 내부의 파일로 가져오면 에이전트가 실제 장애 상태와 코드 경로를 같은 작업 공간에서 비교하며 원인과 수정 대상을 좁힐 수 있다.
3. 진짜 병목은 수정안에 대한 신뢰: 코드 변경을 빠르게 만드는 것보다 수정이 정확한지, 안전하게 배포할 수 있는지 판단하는 일이 어렵다. 따라서 현재의 사람은 장애를 처음부터 조사하기보다 증거와 수정안을 검토하는 역할로 이동한다.
4. 개방형 실행 구조와 보안 경계: 사용자는 샌드박스·하네스·스킬·프롬프트를 목적에 맞게 선택할 수 있으며, 민감한 프로덕션 데이터는 자체 VPC나 기존에 신뢰하는 실행 환경 안에서 처리할 수 있다.
5. 재발 방지를 포함한 Signal-to-PR 루프: 온라인 평가와 LLM 심사자가 반복 가능한 실패를 탐지하고, 이를 평가기와 데이터셋으로 축적하면 상시 실행되는 에이전트가 문제 발견부터 초기 수정안과 PR 작성까지 연결할 수 있다.

🧩 배경과 문제 정의

• 제품 내 에이전트의 초기 버전은 실제 운영 환경에서 기대한 수준의 안정성과 완성도를 보여주지 못했다. 발표자는 이 실패 경험이 반복적인 장애 분석과 수정 과정을 자동화하는 차세대 제품 Signal의 출발점이 됐다고 설명한다.
• 기존 관찰 가능성 도구는 사람이 그래프와 로그를 직접 탐색하며 원인을 찾는 방식에 가깝다. 반면 코딩 에이전트가 스스로 문제를 조사하려면 실제 실행 경로를 보여주는 트레이스·로그 등의 텔레메트리와 코드 저장소의 맥락이 함께 필요하다.
• 핵심 병목은 코드를 수정안으로 생성하는 능력 자체보다, 그 수정이 정확하고 안전하며 실제로 배포할 수 있는지를 신뢰하는 데 있다. 이에 따라 사람의 역할도 장애를 처음부터 조사하는 대응자에서, 에이전트가 수집한 증거와 수정안을 검토하고 최종 결정을 내리는 감독자로 이동한다.
• 궁극적인 목표는 프로덕션의 트레이스·로그·온라인 평가 결과를 지속적으로 수집하고, 문제 탐지부터 원인 분석·수정·PR 생성·재발 방지까지 반복하는 자율 개선 시스템을 구축하는 것이다.
• Signal의 성능과 금융 거래 에이전트의 수익성, 보안 문제 탐지 효과 등은 발표와 데모에서 제시된 설명이다. 이를 독립적으로 입증할 비교 평가나 운영 지표는 입력 정보에 포함되어 있지 않다.

🕒 시간순 섹션별 상세정리

1. 실패한 에이전트 경험과 관찰 가능성의 전환

• 발표자는 제품 내 에이전트 Alex를 직접 구축하고 운영하면서, 에이전트를 실제 환경에서 안정적으로 작동시키는 데 필요한 경험을 축적했다고 보여준다. [00:33]
• 약 2년 전에 만든 첫 번째 에이전트는 완성도가 낮았지만, 이 실패에서 얻은 교훈이 반복적인 운영 업무를 자동화하는 차세대 제품 Signal의 토대가 됐다. [01:04]

2. 자율 복구 목표와 신뢰의 병목

• 발표에서 제시하는 ‘관찰 가능성 2.0’은 코딩 에이전트와 플랫폼별 스킬을 결합하는 접근이며, 텔레메트리는 에이전트가 실제 실행 경로를 찾아가는 핵심 단서로 사용된다. [02:18]
• 텔레메트리가 없으면 수많은 코드 경로 가운데 장애 지점을 추측해야 하지만, 실행 데이터가 제공되면 에이전트가 실제 동작을 따라가며 소프트웨어를 직접 디버깅할 수 있다. [02:25]

3. 사람이 개입하기 전에 증거를 준비하는 루프

• 기존의 ‘사람이 문제를 발견하고 에이전트가 수정하는’ 순서를 뒤집어, 에이전트가 오류 데이터를 먼저 분석하고 사람이 확인하기 전에 관련 이슈를 생성하도록 한다. [04:24]
• 사람은 아무 정보가 없는 티켓에서 조사를 시작하는 대신, 장애와 연결된 증거와 운영 맥락이 준비된 상태에서 조사 방향과 후속 조치를 결정한다. [04:40]

4. 트레이스·로그·저장소를 결합한 실행 환경

• AI 시스템에서 중요한 증거가 되는 트레이스를 조사 출발점으로 삼고, 5분 단위의 주기적 점검이나 특정 오류 이벤트를 조건으로 분석 작업을 실행할 수 있다. [06:13]
• 로그와 스킬이 제공하는 운영 맥락에 코드 저장소를 결합하면, 실제 장애 상태와 가능한 코드 경로를 함께 비교하면서 수정해야 할 위치를 좁힐 수 있다. [06:32]

5. Alex 장애 사례와 연속 개선 운영 방식

• 실제 사례에서는 제품 내 비서 Alex가 작업 목록을 관리하는 todo update 호출을 반복하던 중 스트림 취소 오류를 일으켰다. [08:33]
• Signal은 백그라운드에서 관련 오류 데이터를 결합해 이슈를 생성하며, 사람이 장애 분석을 시작하기 전에 필요한 증거와 맥락을 준비한다. [08:47]

6. 개방형 실행 구조와 Signal 제품 데모

• 이 구조는 불투명한 단일 SRE 에이전트에 모든 작업을 맡기기보다, 사람이 수행하던 로컬 디버깅 경험을 주기적으로 재현하는 데 초점을 둔다. 사용자는 실행에 사용할 샌드박스·하네스·스킬을 선택할 수 있다. [10:45]
• 데모에 등장하는 금융 거래 에이전트는 주식 관련 질문에 답하지만, 발표자는 아직 수익성을 기대하기 어렵다고 보여준다. 또한 답변이 생성되는 과정에는 분석 대상이 될 수 있는 여러 실패 경로가 존재한다. [11:24]

7. 저장소 연동과 보안 경계를 갖춘 실행 환경

• GitHub 저장소를 연결하면 이슈와 평가기를 만들 수 있고, 특정 장애 사례와 관련 트레이스를 데이터셋에 추가해 같은 유형의 문제를 다시 탐지하도록 구성할 수 있다. [12:16]
• Google Cloud와 로깅 시스템을 위한 기본 스킬은 여러 데이터 원천을 연결한다. 사용자 정의 스킬을 추가하면 가드레일 소진이나 안전 문제 등으로 디버깅 범위를 확장할 수 있다는 것이 발표의 설명이다. [12:40]

8. 에이전트 군집 관리와 Signal-to-PR 루프

• 플랫폼은 주기적으로 실행되는 Signal을 포함해 여러 에이전트의 상태를 추적한다. 사용자는 각 실행 세션과 대화 기록을 확인하고, 클라우드에서 시작된 세션을 로컬 환경에서 이어갈 수 있다. [14:28]
• 사용자는 하네스와 샌드박스뿐 아니라 수정의 공격성, 보안 문제 우선 탐색 여부 같은 프롬프트 정책과 저장소별 스킬 구성을 직접 결정한다. [14:56]

9. Claude Code를 직접 연결하기 위한 기술 설계

• 프로덕션 트레이스를 Claude Code에 연결하면 에이전트가 문제를 읽고 PR 생성까지 진행하도록 만들 수 있다. 다만 이를 안정적으로 작동시키려면 데이터에 접근하고 처리하는 절차를 스킬로 먼저 설계해야 한다. [16:35]
• 해당 스킬은 특정 세션과 관련된 트레이스 묶음을 정확히 찾고, 필요한 데이터를 저장소 내부 파일로 옮겨 에이전트가 처리할 수 있는 형태로 제공해야 한다. [16:59]

10. 온라인 평가를 이용한 장애 탐지와 재발 방지

• 온라인 평가는 프로덕션 트레이스와 함께 실행되며, 각각의 트레이스에 장애 여부를 판단하는 데 필요한 평가 데이터를 덧붙인다. [18:11]
• 에이전트는 전용 스킬을 사용해 개별 트레이스의 평가 데이터와 전체 트레이스의 집계값을 함께 가져온다. 이를 통해 단일 실패 사례뿐 아니라 시스템 수준에서 나타나는 이상 추세까지 분석하고, 탐지·수정·재평가로 이어지는 지속적인 개선 루프를 구성한다. [18:41]

🧾 결론

• 스스로 고치는 AI 에이전트는 단순히 프로덕션 시스템을 범용 모델에 연결한다고 완성되지 않는다. 필요한 트레이스를 정확히 찾고, 운영 데이터를 파일로 변환하며, 저장소 맥락과 결합하는 전용 스킬과 데이터 접근 절차가 필요하다.
• 현실적인 도입 단계에서는 에이전트가 초기 탐색·증거 수집·이슈 생성·작은 수정안을 담당하고, 사람이 조사 방향·대규모 변경·최종 배포 여부를 결정하는 협업 구조가 적합하다.
• 자동화하기 쉬운 한두 줄 수준의 수정과 달리 변경 범위가 커질수록 사람의 개입이 중요해진다. 이때도 에이전트가 미리 준비한 증거의 품질은 전체 장애 대응 시간을 줄이는 핵심 요소가 된다.
• 장기적으로는 더 많은 로그와 트레이스, 온라인 평가 결과를 지속적으로 수집해 문제 탐지→원인 분석→수정→재발 감시가 반복되는 연속 개선 체계를 만드는 것이 목표다.

📈 투자·시사 포인트

• 관찰 가능성의 사용자가 사람에서 에이전트로 확장될 가능성: 그래프 중심 UI뿐 아니라 에이전트가 직접 읽을 수 있는 트레이스·로그·평가 데이터와 파일형 인터페이스의 중요성이 커질 수 있다.
• 모델보다 통합 계층이 차별화 요소가 될 가능성: 저장소 연동, 데이터 검색 스킬, 샌드박스, 하네스, 평가기처럼 운영 데이터와 코딩 에이전트를 안전하게 연결하는 인프라가 핵심 경쟁 영역으로 제시된다.
• 엔터프라이즈 도입에서는 보안과 배포 통제가 관건: 자체 VPC 실행, 데이터 경계 유지, 실행 세션 추적, 사람이 최종 수정안을 승인하는 구조가 실제 채택 여부를 좌우할 수 있다.
• 평가 시스템은 장애 탐지와 재발 방지 자산으로 확장 가능: 과거 실패를 데이터셋과 평가기로 전환하면 같은 유형의 오류를 지속적으로 감시할 수 있어, 온라인 평가 인프라의 활용 범위가 넓어질 수 있다.
• 별도 검증 필요: Signal의 실제 제공 범위, AX·Phoenix의 기능 차이, 고객 환경에서의 수정 정확도·오탐률·PR 채택률·장애 대응 시간 절감 효과는 영상의 설명만으로 판단할 수 없으므로 제품 문서와 운영 지표를 추가로 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Signal이 AX SaaS와 VPC 환경에서 제공된다는 설명은 발표 내용에 기반하므로, 현재 지원 범위·가격·도입 조건은 공식 문서에서 별도로 확인해야 한다. [11:38–11:57]
• Signal-to-PR 루프가 제시됐지만, 수정 성공률·오탐률·평균 복구 시간·자동 배포 가능 범위 등 신뢰성을 판단할 정량 지표는 소개되지 않았다. [15:27–15:33]
• Alex의 todo update 반복 호출과 스트림 취소 오류가 언급됐으나, 정확한 근본 원인과 실제 수정 내용, 수정 후 재발 여부는 설명되지 않았다. [08:33–09:10]
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 한 개의 반복 장애 유형을 선정해 트레이스·로그·관련 코드 경로를 동일한 작업 공간에서 조회할 수 있는 최소 실험 환경을 구성한다.
• 에이전트가 특정 세션의 트레이스만 검색하고 필요한 데이터만 파일로 가져오도록 데이터 접근 스킬과 최소권한 정책을 설계한다.
• 일정 기반 점검과 오류 이벤트 기반 실행을 구분하고, 각각의 실행 조건·중복 방지·실패 재시도 기준을 정의한다.
• 자동 생성 이슈와 PR에 근거 트레이스, 관련 로그, 추정 원인, 변경 범위, 검증 결과가 반드시 포함되도록 검토 템플릿을 만든다.

❓ 열린 질문

• 에이전트가 이슈나 PR을 생성하기 위해 충족해야 하는 최소 증거 수준은 무엇이며, 근거가 상충할 때는 어떻게 처리해야 하는가?
• 자동 수정이 허용되는 변경 범위와 반드시 사람이 주도해야 하는 변경 범위는 어떤 기준으로 구분할 수 있는가?
• 생성된 수정안이 테스트를 통과해도 실제 운영 배포가 안전하다고 판단하려면 어떤 추가 평가와 승인 절차가 필요한가?