The 6 Pillars of an Agentic Harness for Production — Varun Krovvidi, Resolve AI

한 줄 핵심

생산 환경에서 소프트웨어를 고치고 운영하는 에이전트를 만들려면 단순한 모델 호출이 아니라 모델 오케스트레이션, 컨텍스트 설계, 안전한 액션, 학습 루프, 평가를 묶은 하네스가 필요하다.

시간별 요약

1. 0:00
   소개 Resolve AI는 소프트웨어를 운영하고 고치는 에이전트를 만들고 있으며, 이를 위해 필요한 6가지 하네스를 설명한다.
2. 0:48
   누가 온콜을 맡는가 온콜 경험과 AI 활용 경험을 묻고, 실제로는 온콜 업무의 대부분을 AI가 처리하는 단계에 아직 이르지 못했음을 문제의 출발점으로 삼는다.
3. 1:33
   AI가 코드에 강해진 이유 코드는 자기 문서화가 잘 되어 있고, 모듈화되어 있으며, 단일 도메인이라서 AI가 이해·분해·평가하기 쉽다.
4. 2:33
   운영과 수정을 위한 70% 실제 엔지니어링 시간의 큰 부분은 새 코드를 만드는 것이 아니라 프로덕션에서 소프트웨어를 운영하고 고치는 데 쓰이며, 이 영역은 훨씬 복잡하다.
5. 2:53
   온콜, 인시던트, 그리고 일상적 관리 운영 업무는 일상적 알림 대응, 대규모 장애 대응, 인프라·비용·스케일링 점검 같은 상시 관리로 나뉘며, 서로 다른 도구와 도메인을 가로지르기 때문에 어렵다.
6. 4:13
   무한한 AI 시대의 종료 이제는 토큰 최적화와 효율적인 아키텍처가 중요해졌고, 도메인별 AI가 작동하려면 기본 모델 위에 추가 구조가 필요하다.
7. 5:18
   마지막 구간이 가장 길다 생성 작업과 달리 정답이 있는 운영 문제는 마지막 구간의 해결이 가장 길고 어렵기 때문에, 특정 문제에 맞춘 구조가 필수다.
8. 5:28
   다자 협업 문제 프로덕션 운영은 여러 팀과 여러 시스템이 얽힌 문제이며, 공통 맥락을 유지한 채 협업해야 해결이 가능하다.
9. 6:23
   Resolve의 세 가지 에이전트 Resolve AI는 일상 온콜 대응용, 인시던트 대응용, 배경 작업용의 세 가지 에이전트를 두고, 모두 같은 아키텍처 위에서 동작하게 설계한다.
10. 7:02
    왜 그냥 모델을 프로덕션에 붙이면 안 되는가 단일 데모는 잘 되더라도, 사용 사례와 팀이 늘어나면 모델 편향과 규모 확장 문제 때문에 곧 한계가 드러난다.
11. 7:37
    첫 번째 균열: 고정 편향과 모델 러닝머신 모델은 한 가지 답으로 수렴하려는 편향이 있고, 모델이 계속 바뀌므로 작업별로 어떤 모델이 적합한지 지속적으로 평가하고 바꿔야 한다.
12. 8:47
    두 번째 균열: 너무 많거나 너무 적은 맥락 맥락이 지나치면 모델이 과탐색하고, 부족하면 필요한 경로를 보지 못한다. 특히 로그·메트릭·코드·인프라가 모두 섞이는 장애 분석에서 이 문제가 심각하다.
13. 9:47
    세 번째 균열: 일관성은 인과성이 아니다 모델은 그럴듯한 답을 잘 만들지만 원인과 결과의 연결을 보장하지 않는다. 프로덕션 문제에서는 사건의 인과 사슬이 핵심이다.
14. 10:27
    네 번째 균열: 가드레일 AI가 잘못된 삭제나 변경을 하지 않도록 최소 권한과 실행 제약을 설계해야 하며, 이는 버그가 아니라 안전장치의 문제로 봐야 한다.
15. 11:02
    다섯 번째 균열: 학습 루프 여러 팀이 같은 맥락을 공유하고 이전 조사 경험이 다음 조사에 축적되어야 하며, 그렇지 않으면 매번 처음부터 다시 시작하게 된다.
16. 11:52
    여섯 기둥: 모델 오케스트레이션 도메인 특화 AI를 만들려면 최신 모델을 추적하고, 이미지·결정론적 단계·개방형 조사 등 작업 특성에 맞춰 최적 모델을 배치하는 오케스트레이션이 필요하다.
17. 12:42
    컨텍스트 엔지니어링 중요한 것은 어떤 기술을 썼는지가 아니라 문제 해결에 필요한 정확한 양의 맥락을 넣는 것이며, 단계가 진행될수록 도구 호출을 정밀하게 제한해야 한다.
18. 13:32
    증거의 인과 사슬 근본 원인은 항상 정확한 증거 사슬로 뒷받침되어야 하며, 그 사슬이 없으면 낮은 신뢰도로 답하고 다른 방향으로 유도해야 한다.
19. 14:12
    관리되는 액션 팀과 산업의 규칙에 따라 읽기만 가능한지, 쓰기까지 허용하는지, 어떤 조건에서 쓰기가 가능한지 명확한 권한 정책이 필요하다.
20. 14:32
    학습 시스템 모든 상호작용은 학습 기회이며, 사용자의 긍정·부정 피드백과 개입 패턴까지 포함해 시스템이 스스로 개선되어야 한다.
21. 15:07
    다섯 단계 평가 평가는 강화 신호, 경로 추적, 엔지니어 수준 비교, 자기 캘리브레이션 등 다섯 수준에서 이뤄져야 하며, 모델이나 구조가 바뀔 때마다 계속 검증해야 한다.
22. 15:57
    데모: 알림에서 근본 원인까지 Slack으로 들어온 Grafana 알림을 받아 여러 에이전트가 코드·인프라·지식베이스·관측 데이터를 교차해 조사하고, 근본 원인과 권고안을 제시한다.
23. 18:12
    데모: 배제된 가설 GCP 장애처럼 겉보기에는 그럴듯한 원인도 함께 제시되지만, 실제 조사에서는 반증된 가설을 보여줘 사용자가 탐색 경로를 이해하게 한다.
24. 19:02
    데모: 에이전트에 반박하기 의도적으로 더 날카로운 질문을 던져도 시스템은 인과 사슬에 근거한 답만 유지하며, 동료를 Slack으로 불러 함께 조사하는 협업 흐름도 지원한다.
25. 20:11
    마무리 프로덕션용 AI는 하네스뿐 아니라 사용자 앞에서 안정적으로 동작하는 제품화 계층까지 필요하며, 추가 정보는 부스에서 확인할 수 있다.

실무 인사이트

• 프로덕션 에이전트는 모델 성능보다도 모델 선택, 맥락 압축, 권한 통제, 평가 체계가 함께 설계되어야 실제 운영에 들어갈 수 있다.
• 장애 분석용 AI는 그럴듯한 답을 내는 것보다 증거의 인과 사슬을 유지하고, 확신이 낮을 때는 낮다고 말하는 구조가 더 중요하다.
• 여러 팀이 함께 쓰는 운영 에이전트는 단일 사용자 도구가 아니라 협업·피드백·학습이 누적되는 시스템으로 설계해야 한다.