프로덕션을 위한 에이전틱 하네스의 6가지 기둥

URL: https://www.youtube.com/watch?v=eXA2tjRZIbY 날짜: 2026-10-07 채널: aiDotEngineer

📌 핵심 질문 / 핵심 논점과 근거

==프로덕션 소프트웨어를 실제로 운영하고 고치는 에이전트를 만들려면, 모델 오케스트레이션·컨텍스트 엔지니어링·인과 추론·거버넌스 액션·학습 시스템·평가 인프라를 결합한 도메인 전용 에이전틱 하네스가 필요하다.==

• 코드 생성은 자기 기술적 문서화, 모듈성, 단일 도메인이라는 특성 덕분에 모델이 이해하고 평가하기 쉽지만, 프로덕션 운영은 코드·인프라·관측성·지식베이스를 가로지르는 멀티도메인 문제다.
• 엔지니어링 시간의 약 70%는 새 소프트웨어 생성보다 이미 배포된 소프트웨어를 실행하고 고치는 데 쓰이며, 이 작업에는 제한되지 않은 텔레메트리, 여러 팀, 시간에 따른 맥락 변화가 함께 들어온다.
• 가장 큰 모델 하나를 프로덕션에 연결하면 앵커링 편향, 과도하거나 부족한 탐색, 인과성 없는 그럴듯한 답변, 위험한 액션, 조직 차원의 학습 부재가 확장 과정에서 드러난다.
• Resolve AI는 온콜 에이전트, 인시던트 에이전트, 앰비언트 백그라운드 에이전트를 같은 에이전트 아키텍처 위에서 운영하고, 관측성·코드·인프라·지식베이스를 연결해 원인과 근거를 추적한다.

프로덕션 에이전트의 목표는 엔지니어를 완전히 배제하는 것이 아니라 에이전트가 소프트웨어를 실행·수정하도록 하고 엔지니어가 에이전트를 감독하는 구조를 만드는 것이다. 단일 정답에 도달해야 하는 작업일수록 생성형 AI의 자유로운 출력보다 정확한 맥락, 원인 증거, 최소 권한, 반복 평가가 중요해진다.

1. 코드 생성에서 프로덕션 운영으로 이동하는 AI의 과제

코드 생성의 성공 조건과 프로덕션 운영의 성공 조건은 근본적으로 다르다.

1.1. 코드가 AI의 첫 번째 성공 영역이 된 이유

1. 코드의 자기 기술적 문서화

   1. 코드 자체가 구조와 동작을 설명하므로 AI가 현재 상태를 파싱하고 다음 작업을 추론하기 쉽다.
   2. 모델은 기존 코드에서 필요한 맥락을 읽고 수정·확장 단계로 넘어갈 수 있다.

2. 코드의 모듈성

   1. 코드는 덩어리로 분해할 수 있어 AI가 문제를 작은 청크로 나누고 각 부분을 순차적으로 탐색할 수 있다.
   2. 모듈 단위의 경계는 기능 확장과 재사용을 돕고, 모델이 한 번에 처리해야 할 범위를 줄인다.

3. 코드의 단일 도메인성

   1. 모델이 서로 다른 전문 분야를 연결해 추론할 필요 없이 하나의 규칙 체계 안에서 다음 단계를 찾을 수 있다.
   2. 문제 정의가 상대적으로 분명하기 때문에 AI가 얼마나 잘 해결했는지를 객관적 벤치마크로 평가할 수 있다.

1.2. 엔지니어링 시간의 중심인 프로덕션 운영

1. 시간 배분의 역전

   1. 엔지니어링 시간의 약 70%는 새 소프트웨어를 생성하는 일이 아니라 프로덕션 시스템을 실행하고 고치는 데 쓰인다.
   2. AI의 코드 생성 성능이 좋아져도 운영·수리 영역이 남아 있으면 엔지니어의 전체 업무 대부분은 자동화되지 않는다.

2. 세 가지 운영 업무

   1. 정기 온콜과 유지보수: 작은 문제가 반복해서 도착하며, 의료 비유로는 통증에 타이레놀이나 애드빌을 처방하는 일상적 처치에 해당한다.
   2. 인시던트 대응: 시스템이 멈추거나 크게 손상되어 모든 담당자의 주의가 필요한 상황이며, 여러 사람이 참여하는 수술에 해당한다.
   3. 상시 건강 관리: 인프라와 비용을 점검하고 플랫폼을 확장하는 등 시스템을 건강하게 유지하는 일이며, 매일 먹는 비타민에 해당한다.

3. 운영 문제의 구조적 난점

   1. 운영 문제는 코드 한 덩어리로 환원되지 않고 여러 도메인과 도구를 가로지른다.
   2. 코드, 인프라, 로그, 메트릭, 배포, 비용, 팀 지식이 함께 있어야 문제를 설명할 수 있다.
   3. 초기 AI 열기가 가라앉으면서 AI가 생성한 코드가 프로덕션에서 만드는 문제, 그 문제를 다룰 프레임워크, 토큰 최적화와 효율성이 핵심 논쟁으로 떠올랐다.

1.3. 생성 작업과 단일 정답 작업의 간극

1. 생성 작업의 자유도

   1. 이미지·블로그·웹사이트 생성처럼 결과의 구체적 모양을 하나로 지정하지 않는 작업은 AI의 변주를 허용한다.
   2. 정답이 여러 개여도 사용자가 결과를 받아들일 수 있으므로 모델의 유창함과 창의성이 장점으로 작동한다.

2. 운영 작업의 단일 정답성

   1. 프로덕션 문제는 특정 장애를 일으킨 실제 원인과 그에 맞는 수정에 도달해야 하므로 단일한 정답과 증거가 요구된다.
   2. 흔히 ‘마지막 1마일’이라고 부르는 단계가 사실 AI가 달려야 하는 가장 긴 거리이며, 도메인 전용 아키텍처가 필요한 지점이다.

3. 멀티플레이어·멀티시스템 문제

   1. 운영자는 혼자 일하지 않고 여러 팀의 전문성을 시간에 따라 끌어와야 한다.
   2. 서로 다른 엔지니어링 영역에 특화된 사람들이 대화하며 시스템 전반의 문제를 해결하므로 협업 맥락도 추론 대상이 된다.

2. Resolve AI의 제품 가설과 에이전트 범주

Resolve AI의 출발점은 프로덕션 소프트웨어를 고치고 매일 실행하는 일을 대부분 에이전트가 맡아야 한다는 가설이다.

2.1. 세 가지 에이전트 역할

1. 온콜 에이전트

   1. 매일 발생하는 소프트웨어 문제와 경보를 받아 조사하고 수정하는 역할을 맡는다.
   2. 작은 정기 장애를 엔지니어가 처음부터 조사하지 않도록 반복 처리를 자동화한다.

2. 인시던트 에이전트

   1. 복잡한 장애의 커뮤니케이션 채널을 주도한다.
   2. 단순 증상에서 출발해 근본 원인과 수정 방안까지 도달하도록 조사 흐름을 운영한다.

3. 앰비언트 백그라운드 에이전트

   1. 배포 모니터링, 분석, 특정 조건에서 자동으로 시작하는 조사처럼 백그라운드에서 수행할 작업을 처리한다.
   2. 사람이 명시적으로 매번 요청하지 않아도 조건이 충족되면 필요한 조사를 시작한다.

2.2. 공통 기반과 인간의 역할

1. 세 범주의 에이전트는 동일한 Resolve 에이전트 아키텍처 위에서 동작한다.
2. 바람직한 운영 모델은 에이전트가 소프트웨어를 실행·수정하고 엔지니어가 에이전트를 실행·감독하는 구조다.
3. 이 구조가 성립하려면 특정 사용 사례의 멋진 데모가 아니라 다양한 팀과 사용 사례에서 안전하고 일관되게 작동하는 하네스가 필요하다.

3. 가장 큰 모델만으로는 부족한 이유

범용 모델의 추론 능력이 향상되어도 프로덕션 문제를 여러 사용 사례와 팀으로 확장하면 익숙한 실패 모드가 나타난다.

3.1. 모델 선택과 앵커링 편향

1. 그럴듯한 답변에 고정되는 모델

   1. 모델은 일관되고 설득력 있는 답변을 만들도록 설계되어 특정 가설에 앵커링될 수 있다.
   2. 사용자가 충분히 밀어붙이면 모델이 서로 반대되는 방향에서도 사용자의 말에 동의하는 현상이 나타날 수 있다.

2. 모델 트레드밀

   1. 더 나은 추론 모델이 계속 출시되므로 작업에 어떤 모델이 적합한지를 지속적으로 평가해야 한다.
   2. 적합한 모델을 찾는 데서 끝나지 않고 실제 사용 사례의 모델을 계속 교체·업데이트해야 한다.

3. 워크플로와 작업의 불일치

   1. 하나의 워크플로에는 추론 작업, 결정론적 작업, 이미지 추론, SQL 추론, 로그 추론 등 수백 가지 작업 유형이 섞인다.
   2. 특정 프런티어 모델이 모든 유형에 동일하게 강하지 않으므로 워크플로 전체에 모델 하나를 배정하는 방식은 비효율적이다.
   3. 오케스트레이션 엔진은 모델의 진화를 따라가면서 각 작업에 가장 적합한 모델을 결합해야 한다.

3.2. 컨텍스트 윈도와 탐색 범위

1. 과도한 컨텍스트의 과탐색

   1. 컨텍스트를 크게 제공하면 모델이 존재하지 않는 가설까지 만들어내거나 정답에서 멀어질 수 있다.
   2. 컨텍스트 윈도가 커지는 것만으로 복잡한 문제의 해결력이 보장되지는 않는다.

2. 부족한 컨텍스트의 과소탐색

   1. 컨텍스트를 지나치게 제한하면 다른 경로와 잠재적 가설을 볼 수 없어 문제 해결에 필요한 시야를 잃는다.
   2. 운영 인시던트에서는 코드와 인프라까지 결합되는 순간 이 문제가 특히 커진다.

3. 프로덕션 텔레메트리의 무한성

   1. 시스템은 원하는 만큼 로그 라인과 메트릭을 생성할 수 있으므로 조사 가능한 텔레메트리가 사실상 무한하다.
   2. 코드와 인프라를 텔레메트리에 결합하면 모든 정보를 한 번에 모델에 넣는 방식에서 진짜 균열이 드러난다.

3.3. 그럴듯함과 인과성의 차이

1. 모델의 목표와 운영자의 목표

   1. 모델은 사용자를 만족시키는 일관된 답변을 잘 만들지만, 일관성이 곧 원인이라는 뜻은 아니다.
   2. 프로덕션 장애가 요구하는 것은 탐정처럼 사건을 재구성하는 인과적 증거 사슬이다.

2. 인과적 증거 사슬

   1. 어떤 단계들이 어떤 순서로 일어나 특정 장애로 이어졌는지를 밝혀야 한다.
   2. 원인을 증명하지 않고 패치만 만들면 같은 원인이 다시 장애를 일으킬 수 있다.
   3. 따라서 인과 추론은 모델 자체가 아니라 프로덕션용 시스템에 내장되어야 한다.

3.4. 안전한 액션과 최소 권한

1. AI가 가장 깨끗한 수정이라고 판단해 파일 시스템이나 데이터베이스를 삭제하는 상황이 발생할 수 있다.
2. 그런 삭제 판단이 모델의 관점에서는 기능일 수 있으므로 모델을 탓하기보다 시스템에 가드레일을 설치해야 한다.
3. 핵심 질문은 특정 상황에서 AI가 가질 수 있는 최소 권한이 무엇인지다.
4. 읽기와 쓰기를 구분하고, 쓰기를 허용할 조건과 산업·조직별 제한을 명시해야 한다.

3.5. 조직 확장과 학습 루프

1. 멀티플레이어 맥락

   1. 사이트 신뢰성 엔지니어(SRE), 플랫폼 팀, 백엔드 엔지니어, 서비스 엔지니어가 같은 인시던트에 관여한다.
   2. 모든 참여자가 동일한 조사 맥락을 공유해야 팀이 각자 다른 출발점에서 반복 조사하지 않는다.

2. 시간에 걸친 맥락 보존

   1. 100번째 조사에서도 이전 조사에서 얻은 지식을 활용해야 한다.
   2. 과거 조사 맥락이 없으면 조직은 매번 바퀴를 처음부터 다시 발명하게 된다.

4. 에이전틱 하네스의 6가지 기둥

범용 모델을 특정 도메인의 정확한 결과로 연결하는 하네스는 여섯 가지 기둥을 함께 운영해야 한다.

4.1. 기둥 1 — 모델 오케스트레이션

1. 모델 트레드밀 대응

   1. 최신 모델의 성능과 비용을 계속 평가하고, 사용 사례에 맞는 모델을 선택한다.
   2. 정해진 모델 하나를 영구적으로 사용하는 대신 모델 생태계의 변화에 맞춰 엔진을 갱신한다.

2. 작업별 모델 매칭

   1. 이미지 특화 추론에는 Gemini, 결정론적 단계에는 OpenAI 모델, 열린 조사에는 Claude처럼 작업 성격에 따라 후보를 달리할 수 있다.
   2. 실제 선택은 고정된 브랜드 선호가 아니라 그 시점의 평가 결과와 작업 적합성으로 결정해야 한다.

3. 초기부터 필요한 엔진

   1. Resolve AI는 이 모델 오케스트레이션 엔진을 제품 초기에 구축했다.
   2. 워크플로 안의 서로 다른 작업에 최적 모델을 배정하는 능력이 도메인 전용 AI의 기본 구성 요소다.

4.2. 기둥 2 — 컨텍스트 엔지니어링

1. 목표의 재정의

   1. 컨텍스트 엔지니어링을 어떤 데이터베이스나 실행 솔루션을 쓰는지로 축소하면 안 된다.
   2. 그래프 RAG, 지식 그래프, 특정 검색 기술은 구현 세부사항이며, 핵심은 문제를 풀기 위해 AI에 제공할 정확한 컨텍스트의 양이다.

2. 단일 기법이 아닌 조합

   1. 초기 조사에는 그래프 RAG 같은 방식으로 관련 지식과 연결 관계를 제공할 수 있다.
   2. 다음 단계로 갈수록 로그 쿼리, 메트릭, 대시보드, 코드 쿼리처럼 정밀한 도구 호출을 정의해야 한다.
   3. 도구를 무작정 여러 번 호출하면 토큰을 빠르게 소모하므로 단계별로 필요한 호출만 노출해야 한다.

3. 정밀한 탐색 경계

   1. 너무 넓은 입력은 존재하지 않는 가설을 만들고 너무 좁은 입력은 대안 경로를 차단한다.
   2. 도메인 지식, 현재 텔레메트리, 코드와 인프라를 문제 단계에 맞는 양으로 조합해야 한다.

4.3. 기둥 3 — 인과 추론

1. 원인에 대한 증거 기준

   1. 근본 원인은 특정 문제로 이어진 정확한 단계들의 인과적 증거 사슬에 근거해야 한다.
   2. 단순히 함께 발생한 사건이나 상관관계를 원인으로 확정해서는 안 된다.

2. 불충분한 증거의 처리

   1. 증거 사슬을 끝까지 세우지 못하면 낮은 신뢰도로 결과를 내보내야 한다.
   2. 데이터가 끊긴 지점에서 확신하는 대신 사용자를 다른 조사 방향으로 안내해야 한다.

3. 도메인 전반의 원칙

   1. 이 원칙은 Resolve AI에만 해당하지 않고 모든 도메인 전용 AI에 적용된다.
   2. 정확한 원인을 알 수 없다는 사실을 신뢰도에 반영하는 것이 그럴듯한 오답을 단정하는 것보다 안전하다.

4.4. 기둥 4 — 거버넌스 액션

1. 조직별 권한 모델

   1. 접근 수준, 내부 정책, 산업 규제에 따라 AI가 수행할 수 있는 작업을 정의해야 한다.
   2. 읽기 권한과 쓰기 권한을 분리하고, 각 쓰기 작업에 필요한 조건을 명시해야 한다.

2. 최소 권한과 조건부 실행

   1. 모든 상황에서 같은 권한을 부여하지 않고 현재 시나리오에 필요한 최소 권한만 허용한다.
   2. 삭제·배포·설정 변경처럼 되돌리기 어려운 액션은 별도의 가드레일과 승인 조건을 둔다.

3. 산업 맥락

   1. 조직마다 허용 가능한 자동화 범위와 감사 요구가 다르다.
   2. 따라서 거버넌스는 제품에 나중에 덧붙이는 공통 설정이 아니라 에이전트가 행동하는 방식의 일부여야 한다.

4.5. 기둥 5 — 학습 시스템

1. 모든 상호작용을 학습 기회로 사용

   1. 에이전트는 자신이 수행한 조사 결과뿐 아니라 사용자가 에이전트와 상호작용한 방식에서도 배워야 한다.
   2. 사용자가 긍정적으로 강화했는지, 특정 방향으로 조사하도록 유도했는지, 부정적으로 교정했는지를 기록해야 한다.

2. 조직 지식의 축적

   1. 조사에 참여하는 여러 팀이 같은 맥락을 공유할 수 있도록 상호작용과 조사 결과를 축적한다.
   2. 이전 인시던트에서 얻은 지식이 다음 조사에 영향을 주어야 반복적인 수작업이 줄어든다.

4.6. 기둥 6 — 평가 인프라

1. 평가가 시작점이자 끝점인 이유

   1. 새 모델, 새 사용 사례, 아키텍처 변경이 생길 때마다 시스템을 평가 인프라로 밀어붙여야 한다.
   2. 평가를 한 번의 출시 전 점검으로 끝내지 않고 에이전트 아키텍처 전체에 지속적으로 내장해야 한다.

2. 다섯 가지 평가 층위

   1. 사용자의 긍정적 강화와 부정적 강화를 각각 신호로 수집한다.
   2. 에이전트가 어떤 경로로 해법에 도달했는지 추적한다.
   3. 숙련된 엔지니어가 같은 조사를 수행했을 때의 기준으로 결과를 점수화한다.
   4. 에이전트의 조사 성능을 최선의 엔지니어와 비교한다.
   5. 에이전트가 스스로 자신의 확신 수준을 보정하고 적절한 신뢰도를 출력하는지 평가한다.

5. Resolve AI의 프로덕션 인시던트 흐름

Resolve AI는 협업 도구에서 시작된 경보를 여러 데이터 소스에 걸친 조사와 근거 중심의 협업으로 연결한다.

5.1. 경보에서 조사 시작까지

1. 경보의 유입

   1. 대부분의 관측성 경보는 Slack이나 Microsoft Teams 같은 협업 도구로 들어온다.
   2. 시연 환경에서는 Grafana가 공용 Slack 채널로 경보를 발송한다.

2. 자동 조사 개시

   1. Resolve가 Slack의 경보를 자동으로 가져와 조사를 시작한다.
   2. 들어온 경보 자체를 프롬프트로 취급하고, 문제를 해결하기 위한 에이전트 묶음을 실행한다.

5.2. 조사 에이전트와 네 가지 데이터 소스

1. 조사 에이전트의 역할

   1. 엔지니어처럼 먼저 문제가 무엇인지 확인하고 메트릭·트레이스 등에서 추가 정보를 모은다.
   2. 트레이스와 로그에서 문제가 발생한 위치를 찾은 뒤 새로운 배포나 변경 이벤트와 상관관계를 조사한다.

2. 네 가지 데이터 소스의 연결

   1. 코드: 실행 경로와 변경 내용을 확인한다.
   2. 인프라: 실행 환경과 자원 상태를 확인한다.
   3. 지식베이스: 조직의 과거 지식과 운영 맥락을 조회한다.
   4. 관측성 플랫폼: 로그, 메트릭, 트레이스, 대시보드에서 현재 증거를 수집한다.

3. 조사 결과의 형태

   1. 에이전트는 근본 원인과 그 근거, 권장 조치를 함께 제시한다.
   2. 선택한 원인뿐 아니라 검토했지만 배제한 다른 이론도 보여준다.

5.3. 로그 스킬 장애 사례

1. 원인 추적

   1. 로그 스킬에서 높은 실패율이 발생한 경보를 조사한다.
   2. 에이전트는 문제를 시스템 안쪽의 오래된 통합(stale integrations)이 여전히 활성화된 상태까지 추적한다.

2. 경쟁 가설의 검토

   1. 같은 시간에 GCP 장애가 있었으므로 시간적 상관관계만 보면 GCP 장애가 원인처럼 보일 수 있다.
   2. 트래픽 급증과 통합 누락을 포함한 다른 설명도 조사 출발점이 될 수 있다.
   3. 에이전트는 원인으로 선택한 가설뿐 아니라 기각한 가설을 함께 표시해 조사자가 판단 근거를 확인하게 한다.

3. 인과성에 따른 답변

   1. 사용자가 GCP 장애와 관련 있는지 묻거나 같은 시점의 배포 오류를 지적해도 에이전트는 질문에 맞춰 무조건 동의하지 않는다.
   2. 이미 만든 인과적 증거 사슬이 뒷받침하는 범위 안에서만 답변한다.
   3. 이 방식은 사용자가 AI를 강하게 유도할 때도 일관된 말투가 아니라 증거 기반 결론을 유지하게 한다.

5.4. 최소 신뢰와 멀티플레이어 워룸

1. 최소 신뢰 정책

   1. 시스템은 처음부터 에이전트를 무조건 신뢰하지 않는 정책으로 설계된다.
   2. 엔지니어는 특정 근거를 강조해 더 깊이 질문할 수 있고, 에이전트는 해당 근거와 관련된 추가 조사를 수행한다.

2. 동료 초대

   1. 엔지니어는 Slack에서 동료를 직접 불러 특정 조사 결과를 함께 검토할 수 있다.
   2. 이 상호작용은 온라인 워룸처럼 작동하며, 인시던트 대응을 개인의 단독 판단에서 팀 협업으로 바꾼다.

3. 엔지니어의 위치

   1. 에이전트가 증거를 수집하고 가설을 비교해도 최종 운영 권한과 감독은 엔지니어에게 남는다.
   2. 자동화의 핵심은 사람을 맥락에서 떼어내는 것이 아니라 사람이 검증할 수 있는 조사 과정을 빠르게 제공하는 데 있다.

6. Q&A와 발표의 마무리

6.1. 청중 확인 질문

1. Varun Krovvidi는 참석자 대부분이 엔지니어일 것으로 보고 손을 들어 온콜 경험이 있는지 확인했다.
2. 이어 AI를 온콜 업무에 사용해 본 사람을 물었고, 참석자들이 손을 들었다.
3. 온콜 업무의 90%가 AI로 처리된다고 편안하게 말할 수 있는지를 다시 물었으며, 이런 수준의 자동화가 아직 해결하기 어려운 문제라는 점을 공유했다.

6.2. 제품화의 다음 축

1. 지금까지의 구조는 프로덕션 문제를 추론하고 해결하는 아키텍처의 한 축이다.
2. AI를 사용자나 고객 앞에 배치하려면 견고한 플랫폼에서 안정적으로 실행하는 제품화의 다른 축도 필요하다.
3. Resolve AI에 관심 있는 사람은 부스 L28에서 사용 고객과 적용 사례를 확인할 수 있으며, 퇴장 전에 부스 밖의 가방을 가져가라는 안내가 있었다.

주요 발언 모음

“프로덕션 시스템을 고치고 매일 실행하는 일은 대부분 에이전트가 해야 한다.”

“프로덕션 인시던트를 해결할 때 필요한 것은 일관된 답변이 아니라 탐정처럼 원인을 증명하는 인과적 증거 사슬이다.”

“컨텍스트 엔지니어링의 핵심은 어떤 데이터베이스를 쓰느냐가 아니라 특정 문제를 풀기 위해 AI에 제공하는 정확한 컨텍스트의 양이다.”

“가장 큰 모델을 프로덕션에 연결하는 것만으로는 충분하지 않다.”

“증거 사슬을 세울 수 없다면 낮은 신뢰도로 말하고 사용자를 다른 방향으로 안내해야 한다.”

“모델이 깨끗한 해결책이라고 판단해 파일 시스템이나 데이터베이스를 삭제하는 것은 모델의 관점에서는 기능일 수 있으므로, 시스템에 가드레일을 세워야 한다.”

핵심 데이터 & 수치

• 약 70%: 엔지니어링 시간 중 새 소프트웨어 생성이 아닌 프로덕션 소프트웨어 실행·수리에 쓰이는 비중으로 제시됐다.
• 세 가지 운영 업무: 정기 온콜·유지보수, 인시던트 대응, 상시 시스템 건강 관리로 분류된다.
• 세 가지 에이전트: 온콜 에이전트, 인시던트 에이전트, 앰비언트 백그라운드 에이전트가 Resolve AI의 제품 범주다.
• 여섯 가지 하네스 기둥: 모델 오케스트레이션, 컨텍스트 엔지니어링, 인과 추론, 거버넌스 액션, 학습 시스템, 평가 인프라다.
• 다섯 가지 평가 층위: 긍정 강화, 부정 강화, 경로 추적, 엔지니어 기준 점수화·비교, 자기 신뢰도 보정이다.
• 네 가지 조사 데이터 소스: 코드, 인프라, 지식베이스, 관측성 플랫폼이다.
• 90% 온콜 자동화 질문: 청중에게 온콜 업무의 90%를 AI가 수행하는지 물어 현재 자동화 수준과 기대치를 확인했다.
• 100번째 조사: 과거 조사 맥락을 보존하지 않으면 100번째 인시던트에서도 매번 처음부터 시작하게 된다는 비유로 학습 루프의 필요성을 설명했다.

결론 및 시사점

1. 프로덕션 자동화의 병목은 모델의 일반 지능만이 아니라 모델을 특정 도메인의 정답과 안전한 행동으로 연결하는 하네스다.
2. 코드 생성에서 통했던 단일 모델·큰 컨텍스트 전략은 운영 문제의 멀티도메인성과 무한한 텔레메트리를 처리하지 못한다.
3. 작업마다 최적 모델을 고르는 오케스트레이션과 단계별로 필요한 정보만 공급하는 컨텍스트 설계가 토큰 비용과 오답을 함께 줄인다.
4. 원인과 상관관계를 구분하는 인과적 증거 사슬이 있어야 에이전트가 사용자의 유도나 동시 발생 사건에 휘둘리지 않는다.
5. 읽기·쓰기·삭제·배포 권한을 최소화하고 조건부로 통제해야 자동화가 운영 리스크로 바뀌지 않는다.
6. 사용자의 강화·교정, 조사 경로, 숙련 엔지니어와의 비교, 자기 신뢰도 보정을 반복 평가에 넣어야 에이전트가 조직 안에서 개선된다.
7. Resolve AI의 온콜·인시던트·백그라운드 에이전트는 Slack 경보에서 시작해 코드·인프라·지식베이스·관측성 데이터의 근거를 모으고 팀 워룸으로 연결하는 적용 형태를 보여준다.
8. 엔지니어의 역할은 사라지는 것이 아니라 에이전트의 조사와 액션을 감독하고, 고품질 피드백과 조직 맥락을 제공하는 쪽으로 이동한다.