How Intuit built an agentic disaster recovery assistant with Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Intuit는 기존 재해 복구 실행 시스템 EWOK에 Amazon Bedrock 기반 EWOK Agent를 결합해, 모델의 복구 판단과 결정론적 실행을 분리한 자연어 장애 조치 환경을 구축했다.

📌 핵심 요약

• Intuit의 EWOK는 YAML로 선언한 복구 의도에 따라 인프라 작업을 조정하며, 지원 대상 워크로드의 복구 시간을 수 시간에서 약 20분으로 줄였다.
• EWOK Agent는 워크플로 선택, 준비 상태 확인, 변경 동결 같은 정책 제약 대응에 필요한 판단을 지원하며, Intuit 팀들은 이를 8개월 동안 장애 조치에 사용했다.
• Amazon Bedrock은 단일 API를 통한 수백 개 기반 모델 접근과 모델 교체를 지원하며, Intuit는 모델 인프라를 직접 운영하지 않고 EWOK 위에 추론 계층을 추가했다.
• EWOK Agent는 엔지니어링 포털이나 IDE에서 자연어 요청을 받아 자산과 워크플로를 확인하고, 준비 상태와 정책을 검사한 뒤 실행 ID와 변경 기록을 반환하며 단계별 진행 상태를 보고한다.
• 아키텍처는 사용자 접점, 에이전트, 스킬, 실행의 네 계층으로 구성된다. 호출마다 Amazon Bedrock Guardrails를 적용하고, 모델이 선택한 작업은 EWOK API를 통해 결정론적으로 실행하며, 판단과 승인에는 엔지니어가 계속 참여한다.

🧩 주요 포인트

1. EWOK의 약 20분 복구와 남아 있던 판단 의존성 → EWOK Agent는 기존 실행 자동화 위에 워크플로 선택과 정책 대응을 지원하는 계층을 추가한다.
2. 형식이 지정된 스킬과 모델·실행 경계 → 모델의 작업 선택을 구조화된 요청으로 전달하고 실제 복구는 EWOK의 준비 상태 검사와 정책 통제에 연결한다.
3. Amazon Bedrock의 모델 교체와 완전관리형 운영 → 에이전트 구조를 다시 설계하거나 모델 인프라를 직접 관리하는 부담을 줄이면서 복구 추론에 적합한 모델을 선택할 수 있다.

🧠 상세 정리

1. 대규모 재해 복구와 기존 EWOK의 성과

Intuit는 TurboTax, QuickBooks, Mailchimp, Credit Karma처럼 수백만 명이 사업 운영과 재무 관리에 사용하는 제품을 지원하며, 여러 AWS 리전에 걸친 수천 개 마이크로서비스 규모에서 재해 복구를 수행한다. 이런 환경에서는 장애 발생 시 서비스를 다른 리전으로 안정적으로 전환하기 위해 여러 인프라 작업을 조정해야 한다. 기존 중앙 집중형 내부 시스템인 EWOK는 컴퓨팅, 데이터베이스, 네트워킹, 캐시, 비동기 워크로드 전반의 장애 조치 실행을 표준화했다. 서비스 소유자가 YAML로 복구 의도를 선언하면 EWOK가 실제 인프라 작업을 조정하며, 지원 대상 워크로드의 복구 시간은 수 시간에서 약 20분으로 줄었다.

2. 실행 자동화 이후에도 남은 판단의 공백

EWOK가 실행을 자동화한 뒤에도 어떤 복구 워크플로가 적합한지 선택하고 자산의 준비 상태를 확인하는 일은 숙련된 당직 엔지니어의 경험에 의존했다. 복구 도중 발생하는 예외를 처리하는 지식도 같은 방식으로 개인에게 축적되어 있었다. 대표적인 사례는 세금 신고 시즌처럼 중요한 업무 기간의 가용성을 보호하기 위해 배포와 변경을 제한하는 변경 동결 기간이다. 이때 장애 조치 요청이 거부되면 엔지니어는 진행에 필요한 세부 긴급 예외 절차를 알아야 했다. Intuit는 이러한 판단의 공백을 줄이기 위해 Amazon Bedrock 기반 EWOK Agent를 구축했으며, 원문에 따르면 여러 팀이 이를 8개월 동안 장애 조치에 사용했다.

3. Amazon Bedrock 선택과 운영·보안 특성

Amazon Bedrock은 단일 API로 여러 AI 공급자의 수백 개 기반 모델에 접근하게 하므로, Intuit는 장애 조치 추론에 적합한 모델을 평가하고 선택할 수 있다. 요구가 바뀌어도 에이전트 아키텍처를 다시 설계하지 않고 모델을 교체할 수 있다는 점이 선택 이유로 제시된다. 완전관리형 서비스이므로 기존 EWOK 위에 추론 계층을 추가하면서 모델 인프라를 직접 프로비저닝하거나 관리할 필요도 없었다. 원문은 Amazon Bedrock Guardrails와 함께 데이터가 모델 학습에 사용되지 않고 전송 중 및 저장 시 암호화된다는 보호 특성을 설명하며, 이를 운영 중인 금융 시스템에 접근하는 에이전트의 맥락과 연결한다. EWOK Agent는 플러그인으로 제공되어 엔지니어링 포털이나 엔지니어가 선택한 IDE에서 사용할 수 있다.

4. 설계 패턴의 범위와 적용 전제

이 글은 단계별 배포 절차가 아니라 아키텍처와 재사용 가능한 설계 패턴을 설명하며, 코드도 완전한 실행 구현이 아닌 예시 발췌문이다. 패턴을 적용하려면 사용할 AWS 리전에서 선택한 기반 모델이 제공되는지 확인하고 모델 접근 권한 부여 방식을 이해해야 한다. 스킬을 도구 명세로 변환하는 설계를 따라가려면 Amazon Bedrock Converse API의 도구 사용 기능과 Guardrails, 관련 IAM 작업에 대한 이해가 필요하다. 예시 코드는 Python과 Boto3, langchain-aws를 사용하므로 이들에 대한 친숙함도 전제로 제시된다. EWOK 자체는 Intuit 내부 시스템이지만, 형식이 지정된 스킬과 얇은 모델 연결 계층, 결정론적 실행기 위의 제한된 에이전트 반복 구조는 인증과 감사가 가능한 API를 제공하는 다른 시스템에도 적용할 수 있다고 설명한다.

5. 복구 자산과 실행 통제의 기본 개념

EWOK에서 자산은 트래픽을 관리하는 등록된 복구 단위이며, 서비스나 서버리스 앱의 컴퓨팅 계층, 트래픽 엔드포인트, 데이터베이스, 캐시, 비동기 또는 상태 유지 의존성을 포함할 수 있다. 복구 워크플로는 성능이 저하된 기본 리전에서 정상 보조 리전으로 자산을 옮기는 자동화 단계의 순서로, YAML 예시는 컴퓨팅 확장, 데이터베이스 승격, 캐시 전환, 트래픽 이동을 차례로 선언한다. 준비 상태 검사는 트래픽 이동을 안전하게 조정할 기술적 요건을 확인하고, 정책 게이트는 그 위에서 조직·운영·규정 준수상의 진행 허용 여부를 판단한다. 실행 ID는 한 번의 워크플로 실행을 시작부터 완료 또는 실패까지 식별한다. 변경 기록은 운영 환경 변경을 승인하고 문서화하는 공식 항목으로, EWOK가 실행 시작 시 열고 종료 시 닫으며 운영 환경의 워크플로는 이 기록 없이 실행되지 않는다.

6. 엔지니어의 자연어 요청부터 상태 보고까지

엔지니어가 포털이나 IDE에서 운영 환경의 payments-gateway를 장애 조치해 달라고 요청하면, EWOK Agent는 먼저 대상 자산을 식별하고 사용 가능한 복구 워크플로를 찾는다. 이어 적절한 워크플로를 선택하되 여러 워크플로가 해당하면 엔지니어에게 선택을 요청한다. 실행 전에는 준비 상태와 활성 변경 동결 같은 정책 게이트를 확인하며, 이후 EWOK를 통해 실행을 시작하고 실행 ID와 변경 기록을 반환한다. 에이전트는 장애 조치가 끝날 때까지 각 단계의 상태를 추적하고 보고한다. 기존에는 엔지니어가 운영 절차서를 찾아보고 여러 콘솔을 방문하며 API 호출을 조정했지만, 이 흐름에서는 대화를 감독하면서 필요한 판단과 승인을 담당한다.

7. 네 계층 아키텍처와 모델·실행의 경계

사용자 접점 계층은 내부 엔지니어링 포털과 IDE 통합으로 구성되며, MCP를 통한 연결을 포함해 자연어 요청을 에이전트에 전달한다. 에이전트 계층은 모델 선택, 제한된 추론 반복, 스킬 전달을 처리하며 모든 모델 호출에 Amazon Bedrock Guardrails를 적용한다. 스킬 계층은 형식과 버전이 지정된 정의를 도구 명세로 변환하고, 에이전트는 요청과 이 명세를 Amazon Bedrock Converse API로 모델에 보낸다. 모델이 대상 자산과 환경 등을 포함한 구조화된 도구 사용 요청을 반환하면 스킬 실행기가 EWOK API로 작업을 수행한다. 실제 복구는 컴퓨팅, 데이터베이스, 캐시, 트래픽별 실행 에이전트가 담당하고 상태는 같은 경로를 거슬러 사용자에게 전달되며, 전체 설계는 모델이 무엇을 할지 결정하고 EWOK Agent가 어떻게 할지를 결정론적으로 실행한다는 원칙을 따른다.

8. 운영 지식을 형식이 지정된 스킬로 표현

EWOK Agent의 핵심 설계 결정은 사람이 읽는 운영 절차서를 작성하는 데서 나아가, 사람이 이해하면서 기계도 사용할 수 있는 스킬로 장애 조치 지식을 표현하는 것이다. 스킬은 Markdown 파일이며, 형식이 지정된 입력·출력 스키마를 선언하는 YAML 머리말과 모델이 따를 지시·규칙·판단 논리를 담은 프롬프트 본문으로 구성된다. YAML 스키마는 작업의 계약 역할을 하고, 프롬프트 본문은 해당 기능을 언제 어떻게 선택할지에 필요한 지침을 제공한다. 제시된 failover-manager 예시는 워크플로 조회, 장애 조치 호출, 실행 상태 확인을 다루며 작업 종류, 자산 이름, 대상 환경을 필수 입력으로 정의한다. 변경 동결 예외에 필요한 사고 번호 항목도 등장하지만 제공된 원문은 그 정의 도중에 끝나므로, 이후의 구현이나 추가 동작은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 복구 시간 약 20분은 기존 EWOK의 지원 대상 워크로드 성과이며, EWOK Agent 도입 이후의 추가 시간 단축 수치는 제공된 원문에 제시되지 않는다.
• 모델의 판단과 결정론적 실행을 분리하는 구조에서는 스킬이 두 영역을 연결하고, 준비 상태 검사와 정책 게이트가 실제 복구의 진행 조건을 통제한다.
• 엔지니어의 역할은 개별 API 호출을 조정하는 업무에서 대화를 감독하고 판단·승인에 참여하는 업무로 이동하며, 사람의 개입 자체가 없어지는 것은 아니다.

✅ 액션 아이템

• EWOK의 약 20분 복구 성과를 지원 대상 워크로드 범위와 함께 해석.
• EWOK Agent 적용 시 워크플로 선택, 준비 상태 확인, 변경 동결 대응에서 필요한 엔지니어 판단과 승인 범위 검토.
• Amazon Bedrock 기반 모델 선택 시 복구 추론 적합성, 모델 교체 가능성, 완전관리형 운영 특성을 함께 평가.

❓ 열린 질문

• EWOK가 약 20분 복구를 달성한 지원 대상 워크로드의 구체적인 범위는 무엇인가?
• EWOK Agent에서 변경 동결 같은 정책 제약이 발생하면 엔지니어는 어떤 판단과 승인을 담당하는가?
• Amazon Bedrock에서 복구 추론에 적합한 모델을 선택하고 교체하는 평가 기준은 무엇인가?