Asana에서 시작해 Discord 승인을 거쳐 AWS를 실행하는 운영 자동화 구축기
“환경변수 하나만 반영해 주세요.”
문장만 보면 간단한 요청처럼 보입니다. 하지만 ECS 환경변수 하나를 바꾸는 일은 생각보다 많은 단계를 거칩니다.
현재 Task Definition을 확인하고, 변경할 값을 검토하고, 새 Revision을 등록해야 합니다. ECS 서비스가 새 Revision으로 롤아웃되었는지 확인한 뒤에는 실제 Running Task가 어떤 Revision을 사용하고 있는지도 다시 확인해야 합니다. 마지막으로 Target Health와 애플리케이션 로그까지 정상이어야 비로소 작업이 끝납니다.
ALB 경로 하나를 추가하거나 특정 시간대의 오류 로그를 확인하는 요청도 마찬가지였습니다.
요청 자체는 몇 줄이었지만, 안전하게 처리하려면 그보다 훨씬 많은 확인이 필요했습니다.
문제는 이런 요청이 평일 업무시간에만 들어오지 않는다는 점이었습니다. 늦은 밤이나 주말에도 Asana 댓글과 메시지를 통해 요청이 들어왔습니다.
요청한 개발자는 늦은 시간에 연락해서 미안하다고 했고, 저는 바로 대응하지 못하면 또 미안한 마음이 들었습니다.
하지만 어느 순간 이런 생각이 들었습니다.
정말 이 방법밖에는 없을까?
반복되는 운영 요청을 처리하기 위해 항상 누군가가 깨어 있어야 할까?
그 질문에서 Hermes 기반 AWS 운영 자동화가 시작되었습니다.
문제 상황
기존 AWS 운영 요청은 대부분 다음과 같은 흐름으로 처리됐습니다.
```mermaid
flowchart LR
A["개발자가 Asana 또는 메시지로 요청"] --> B["인프라 담당자가 요청 확인"]
B --> C["기존 업무와 댓글 맥락 파악"]
C --> D["AWS 콘솔 또는 CLI로 조회·변경"]
D --> E["롤아웃과 로그 확인"]
E --> F["요청자에게 결과 전달"]
```단계만 보면 특별히 복잡하지 않아 보입니다. 그러나 실제 운영에서는 몇 가지 문제가 반복됐습니다.
첫 번째는 담당자의 가용성에 따라 처리 시간이 달라진다는 점이었습니다. 같은 요청이라도 제가 컴퓨터 앞에 있으면 바로 처리됐고, 그렇지 않으면 기다려야 했습니다.
두 번째는 요청의 맥락이 여러 곳에 흩어져 있다는 점이었습니다. Asana 업무 본문, 이전 댓글, Discord 대화와 기존 배포 이력을 함께 확인해야 요청의 실제 의도를 알 수 있었습니다.
세 번째는 실행보다 검증에 더 많은 주의가 필요하다는 점이었습니다. AWS API가 성공을 반환했다고 작업이 끝난 것은 아니었습니다. 특히 ECS에서는 서비스 롤아웃이 COMPLETED 상태여도 실제 Running Task가 기대한 Revision과 설정을 사용하지 않는 경우를 별도로 확인해야 했습니다.
마지막으로 요청, 승인, 실행 및 결과가 하나의 기록으로 연결되지 않았습니다. 누가 무엇을 요청했고, 어떤 값을 확인한 뒤 어떤 명령을 실행했는지를 사후에 다시 구성하려면 여러 시스템의 기록을 모아야 했습니다.
이 구조에서는 작은 요청이 반복될수록 인프라 담당자의 운영 부담도 함께 증가했습니다.
처음에는 실행 스크립트를 생각했습니다
가장 먼저 떠올린 방법은 자주 사용하는 AWS 명령을 스크립트로 만드는 것이었습니다.
ECS 상태 조회, 로그 검색, 환경변수 변경과 같은 작업을 스크립트로 만들면 실행 시간은 줄일 수 있습니다. Runbook을 정리하면 실수도 어느 정도 줄어듭니다.
하지만 근본적인 문제는 해결되지 않았습니다.
스크립트를 실행할 사람은 여전히 필요했습니다. 늦은 밤 요청이 들어오면 누군가는 요청을 읽고, 알맞은 스크립트를 선택하고, 파라미터를 입력한 뒤 결과를 검증해야 했습니다.
그다음에는 Hermes가 요청을 읽고 AWS CLI를 직접 실행하도록 하는 방식을 생각했습니다.
응답 속도만 보면 가장 단순한 해결책이었습니다. 그러나 에이전트에 AWS 자격증명과 자유로운 명령 실행 권한을 부여하는 순간, 자동화의 편리함보다 훨씬 큰 위험이 생깁니다.
자연어 요청을 잘못 해석할 수도 있고, 예상하지 못한 리소스에 접근할 수도 있습니다. 요청에는 없던 파라미터를 추론하거나, 로그와 Secret을 외부 채널에 노출할 가능성도 고려해야 했습니다.
그래서 방향을 바꿨습니다.
Hermes가 AWS를 자유롭게 조작하는 구조가 아니라,
Hermes는 실행계획을 만들고 제한된 실행기가 그 계획만 수행하도록 하자.
사람을 완전히 제외하는 것이 목표가 아니었습니다. 반복적인 확인과 실행은 자동화하되, 중요한 판단과 승인은 사람에게 남기는 것이 목표였습니다.
자동화가 갖춰야 할 조건
구현에 앞서 새로운 구조가 만족해야 할 조건을 정리했습니다.
| 요청 맥락 유지 | Asana 업무 본문과 기존 댓글을 함께 분석해야 한다 |
| 실행 전 승인 | AWS 변경 작업은 Discord에서 승인받아야 한다 |
| 계획 무결성 | 승인한 계획과 실제 실행 파라미터가 같아야 한다 |
| 실행 범위 제한 | 정의된 Tool과 Playbook만 실행할 수 있어야 한다 |
| 최소권한 | Playbook마다 필요한 AWS 권한만 사용해야 한다 |
| 멱등성 | 같은 댓글이나 이벤트가 두 번 실행되지 않아야 한다 |
| 실제 상태 검증 | API 성공이 아니라 Running Task의 실제 상태까지 확인해야 한다 |
| 민감정보 보호 | Secret 원문과 로그의 민감정보가 노출되지 않아야 한다 |
| 감사 가능성 | 요청·승인·실행·결과를 하나의 ID로 추적할 수 있어야 한다 |
| 후속 요청 지원 | 같은 업무에 추가 댓글이 달리면 이전 맥락을 이어서 처리해야 한다 |
이 조건을 기준으로 Asana, Hermes, Discord와 AWS 실행 Broker를 연결했습니다.
변경된 아키텍처
전체 흐름은 다음과 같습니다.
```mermaid
flowchart LR
A["Asana 댓글<br/>@Hermes 요청"] --> B["요청 수집기"]
B --> C["업무·댓글 맥락 조회"]
C --> D["Hermes 실행계획 생성"]
D --> E["Discord 승인 카드"]
E -->|"승인"| F["AWS 실행 Broker"]
E -->|"거절·만료"| G["실행 종료"]
F --> H["허용된 Playbook 실행"]
H --> I["실제 상태 및 근거 검증"]
I --> J["Discord 결과 보고"]
J --> K["원본 Asana 업무에 결과 등록"]
D -. "AWS 자격증명 없음" .-> F
```이 구조에서 각 컴포넌트의 책임은 명확히 분리했습니다.
- Asana는 요청과 업무 맥락을 관리합니다.
- Hermes는 자연어 요청을 분석해 구조화된 실행계획을 만듭니다.
- Discord는 사람이 계획을 검토하고 승인하는 지점입니다.
- AWS 실행 Broker는 승인된 Playbook만 실행합니다.
- AWS는 실제 상태를 제공하며, 검증 결과는 다시 Discord와 Asana에 기록됩니다.
핵심은 Hermes가 AWS 자격증명을 가지지 않는다는 점입니다.
Hermes는 “무엇을 해야 하는지”를 계획할 수 있지만, 직접 AWS API를 호출할 수는 없습니다.
1. 처리할 요청부터 제한하기
Asana에 작성되는 모든 댓글을 자동화 대상으로 삼지 않았습니다.
다음 조건을 모두 만족하는 댓글만 Hermes가 처리하도록 했습니다.
- ssinocean AWS Infra 프로젝트의 업무일 것
- 댓글에 @Hermes가 포함되어 있을 것
- 허용된 요청자가 작성했을 것
- 완료되지 않은 업무일 것
- Hermes가 작성한 댓글이 아닐 것
요청 수집기는 Asana Webhook을 검증한 뒤 댓글의 고유 ID를 기준으로 중복 여부를 확인합니다. 이미 처리한 댓글이면 새로운 실행을 만들지 않습니다.
Hermes가 작성한 결과 댓글도 다시 요청으로 인식하지 않도록 제외했습니다. 이 조건이 없으면 Hermes가 자신의 답변을 다시 읽고 또 답변하는 무한 반복이 발생할 수 있습니다.
Webhook 누락에 대비해서는 일정 주기로 최근 댓글을 대조합니다. 실시간 수집과 주기적인 보정 작업을 함께 두되, 두 경로에서 같은 댓글을 발견하더라도 하나의 요청만 생성됩니다.
2. 댓글 한 줄이 아니라 업무 전체를 읽기
운영 요청은 댓글 한 줄만 읽어서는 정확하게 이해하기 어려운 경우가 많았습니다.
예를 들어 다음 요청이 들어올 수 있습니다.
@Hermes 이전에 반영한 값을 true로 변경해주세요.
이 댓글만 보면 어떤 값을 의미하는지 알 수 없습니다. 업무 본문과 이전 댓글을 읽어야 대상 환경변수와 서비스, 이전 작업 결과를 확인할 수 있습니다.
따라서 Hermes에는 현재 댓글뿐 아니라 다음 정보를 함께 전달했습니다.
- Asana 업무 제목과 본문
- 프로젝트와 업무 상태
- 요청자 정보
- 이전 사용자 댓글
- 이전 Hermes 실행 결과
- 연결된 요청 ID와 승인 기록
- 대상 환경과 리소스 정보
후속 댓글이 달리면 완전히 새로운 요청으로 보지 않고, 동일한 업무 맥락을 참조하는 별도 요청으로 연결했습니다.
다만 이전 요청의 승인을 재사용하지는 않았습니다. 같은 업무의 후속 댓글이라도 새로운 AWS 변경이 필요하면 새로운 계획과 승인을 생성합니다.
3. 자연어를 실행계획으로 고정하기
Hermes는 요청을 바로 실행 명령으로 변환하지 않습니다. 먼저 정해진 Schema에 맞는 실행계획을 생성합니다.
실행계획에는 다음과 같은 정보가 포함됩니다.
{
"requestId": "HER-2026-00142",
"environment": "alpha",
"region": "ap-northeast-2",
"resource": {
"type": "ECS_SERVICE",
"cluster": "ssinocean-alpha",
"service": "api"
},
"playbook": "UPDATE_ECS_ENVIRONMENT",
"parameters": {
"name": "SSINOCEAN_NOTIFICATION_ADMIN_BASE_URL",
"value": "[MASKED]"
},
"expectedImpact": "새 Task Definition Revision 등록 및 ECS 롤아웃",
"validation": [
"서비스가 참조하는 Revision 확인",
"Running Task의 Revision 확인",
"Target Health 확인"
],
"rollback": "이전 Task Definition Revision으로 서비스 복구",
"expiresAt": "2026-08-25T23:30:00+09:00"
}Schema에 없는 작업이나 허용되지 않은 리소스가 포함되면 승인 단계로 넘어가지 않습니다.
계획이 만들어지면 정규화된 전체 내용으로 Hash를 생성합니다. 이 Hash는 Discord 승인 카드와 실행 요청에 함께 저장됩니다.
승인 이후 파라미터가 하나라도 변경되면 Hash가 달라집니다. 이 경우 기존 승인은 무효가 되고 새로운 계획을 다시 승인받아야 합니다.
이를 통해 “A라는 계획을 승인했지만 실제로는 B가 실행되는 상황”을 막았습니다.
4. Discord에서 실행 전에 확인하기
실행계획이 완성되면 Discord에 승인 카드가 생성됩니다.
카드에는 다음 정보가 표시됩니다.
- 요청 ID와 요청자
- 원본 Asana 업무
- AWS 계정, 환경 및 리전
- 대상 리소스
- 실행할 Playbook
- 현재값과 변경값
- 예상 영향
- 실행 후 검증 방법
- 실패 시 복구 방법
- Secret 포함 여부
- 승인 만료시간
- 실행계획 Hash
승인 버튼을 누른다고 바로 AWS API가 호출되지는 않습니다.
먼저 승인자의 Discord User ID와 채널을 확인합니다. 이어서 일회성 nonce, 승인 만료시간, 요청 상태와 실행계획 Hash를 검증합니다.
다음 중 하나라도 만족하지 않으면 실행을 거부합니다.
- 허용되지 않은 사용자가 승인한 경우
- 지정되지 않은 채널에서 승인한 경우
- 이미 사용된 승인 요청인 경우
- 승인 시간이 만료된 경우
- 계획 Hash가 달라진 경우
- 이미 실행됐거나 거절된 요청인 경우
거절되거나 만료된 요청은 AWS 실행 Broker까지 전달되지 않습니다.
5. 에이전트가 아니라 Playbook이 AWS를 실행한다
AWS 작업은 Hermes가 아니라 별도의 실행 Broker가 담당합니다.
Broker는 임의 Shell 명령이나 자유 형식 AWS CLI를 입력받지 않습니다. 사전에 구현된 Playbook 이름과 검증된 파라미터만 받을 수 있습니다.
초기에 개방한 조회 Playbook은 다음과 같습니다.
- ECS 서비스 및 Deployment 상태 확인
- Running Task와 Task Definition Revision 대조
- 비민감 환경변수 설정 확인
- Secret 참조 여부 확인
- ALB Listener Rule과 Target Health 확인
- CloudWatch Alarm 확인
- 지정 시간대 오류 로그 요약
- 배포 전후 상태 비교
읽기 전용 운영이 안정화된 뒤에는 Alpha 환경에 한해 제한된 변경 Playbook을 추가했습니다.
- ECS 비민감 환경변수 변경
- 기존 SSM 또는 Secrets Manager 참조 연결
- 새 Task Definition Revision 등록
- 지정 ECS 서비스 롤아웃
- 지정 Host 또는 Path의 ALB 규칙 추가
- ECS 강제 재배포
- 기능 게이트의 단계적 활성화
각 Playbook은 별도의 최소권한 IAM Role을 사용합니다. ECS 진단 Playbook이 ALB 규칙을 수정하거나, 환경변수 변경 Playbook이 IAM 정책을 조회하는 식의 동작은 허용하지 않습니다.
다음 작업들은 자동화 범위에서 명시적으로 제외했습니다.
- IAM과 권한 정책 변경
- AWS Organizations, SCP 및 KMS 정책 변경
- Secret 원문 조회
- RDS 직접 SQL 실행과 데이터 수정
- ECS, ALB, RDS 및 S3 리소스 삭제
- 임의 Shell 또는 AWS CLI 실행
- 영구 승인과 승인 우회
- Discord 단독 승인에 의한 Production 변경
자동화의 범위를 “할 수 있는 것”뿐 아니라 “절대로 하지 않는 것”으로도 정의한 것입니다.
6. API 성공을 작업 성공으로 보지 않기
이 자동화에서 가장 중요하게 본 부분은 실행보다 검증이었습니다.
ECS 환경변수 변경을 예로 들면 다음 상태를 순서대로 확인합니다.
```mermaid
flowchart LR
A["요청한 설정값"] --> B["등록된 Task Definition"]
B --> C["ECS 서비스가 참조하는 Revision"]
C --> D["실제 Running Task의 Revision"]
D --> E["Running Task가 참조하는 설정"]
E --> F["Target Health"]
F --> G["애플리케이션 동작 판별 로그"]
```새 Task Definition 등록에 성공했다고 작업을 완료하지 않습니다.
ECS 서비스가 새 Revision을 참조하고 있는지, 기존 태스크가 교체됐는지, 실제 Running Task가 목표 Revision으로 실행되고 있는지를 확인합니다. 환경변수는 해당 Running Task가 참조하는 Task Definition을 기준으로 다시 대조합니다.
설정만으로 실제 동작을 확정하기 어려운 경우에는 애플리케이션 로그나 검증용 엔드포인트를 함께 사용합니다.
예를 들어 다음과 같은 요청이 있었습니다.
“true로 반영했는데 계속 fake adapter가 실행됩니다.”
이 경우 Hermes는 단순히 Task Definition에 true가 있는지만 확인하지 않습니다.
- 요청에서 지정한 값
- 새로 등록된 Task Definition Revision
- ECS 서비스가 참조하는 Revision
- 현재 Running Task의 Revision
- 해당 Revision의 비민감 환경변수
- 애플리케이션의 adapter 선택 로그
이 항목들을 교차 검증한 뒤 어느 단계에서 불일치가 발생했는지 보고합니다.
롤아웃 상태가 COMPLETED라는 이유만으로 성공 처리하지 않고, 실제 태스크와 애플리케이션 동작까지 목표 상태에 도달했을 때만 성공으로 판정했습니다.
실제 요청은 어떻게 처리될까
특정 시간대의 장애 확인
다음과 같은 요청이 들어왔다고 가정해 보겠습니다.
@Hermes 15:25부터 15:40까지 API 오류 로그를 확인해주세요.
Hermes는 업무의 환경과 기준 시간대를 확인하고, KST 요청 시간을 UTC 조회 범위로 변환합니다. 이후 제한된 CloudWatch 및 ALB 진단 Playbook을 계획에 포함합니다.
승인이 완료되면 다음 항목을 확인합니다.
- 지정 구간의 5xx 및 4xx 발생량
- 애플리케이션 예외 유형
- 오류가 집중된 요청 경로
- ALB Target Health 변화
- 같은 시간대 ECS 이벤트
- 배포 또는 Task 교체 여부
로그 원문 전체를 Discord나 Asana에 게시하지는 않습니다. 정해진 건수와 시간범위 안에서 조회한 뒤 토큰, 개인정보 및 인증 헤더와 같은 민감정보를 마스킹하고 요약 결과와 근거만 전달합니다.
ECS 환경변수 반영
다음 요청은 변경 작업이므로 조회보다 더 많은 검증이 필요합니다.
@Hermes SSINOCEAN_NOTIFICATION_ADMIN_BASE_URL을 반영해주세요.
Hermes는 현재 Task Definition과 값을 조회한 뒤 다음 내용을 실행계획으로 만듭니다.
- 현재 Revision과 환경변수 확인
- 변경 전후 값 비교
- 예상 영향과 복구 Revision 표시
- Discord 승인
- 새 Task Definition Revision 등록
- ECS 서비스 업데이트
- 롤아웃 완료 대기
- Running Task Revision 재검증
- Target Health와 오류 로그 확인
- 결과를 Discord와 Asana에 등록
중간 단계가 실패하면 단순히 “실패했습니다”라고 응답하지 않습니다. 어느 단계까지 실행됐고, AWS 상태가 현재 어디에 머물러 있으며, 자동 복구가 수행됐는지 또는 사람의 확인이 필요한지를 함께 기록합니다.
기능을 한 번에 활성화하지 않기
ShopBy 실주문 활성화처럼 영향이 큰 기능은 하나의 변경으로 처리하지 않았습니다.
먼저 CLIENT_ID와 RETURN_URL을 반영하되 ORDER_ENABLED=false 상태로 배포합니다. 새 설정으로 애플리케이션이 정상 기동하는지 확인한 다음, 별도의 Discord 승인을 받아 ORDER_ENABLED=true로 두 번째 롤아웃을 진행합니다.
두 번째 롤아웃 이후에는 다음 항목을 다시 확인합니다.
- 실제 Running Task의 Revision
- 기능 게이트의 실효값
- fake/real adapter 선택 로그
- Target Health와 오류 로그
- 담당자의 E2E 테스트 결과
자동화가 성공했다고 해서 업무를 즉시 종결하지 않습니다. 사람의 E2E 확인이 필요한 단계라면 대기 상태로 남기고, 결과가 등록된 뒤 최종 상태를 확정합니다.
이렇게 자동화 단위를 작게 분리하면 위험한 변경을 한 번의 승인으로 모두 수행하는 것을 막을 수 있습니다.
하나의 요청 ID로 모든 과정을 연결하기
자동화 요청이 생성되면 고유한 요청 ID가 발급됩니다.
이 ID는 다음 기록에 공통으로 포함됩니다.
- 원본 Asana 댓글
- Hermes가 생성한 실행계획
- Discord 승인 또는 거절
- 승인한 사용자와 시각
- AWS 실행 Broker 요청
- Playbook 실행 결과
- CloudTrail 관련 기록
- Discord 결과 보고
- Asana 최종 댓글
덕분에 장애가 발생하거나 실행 결과를 다시 확인해야 할 때 여러 시스템의 기록을 하나의 흐름으로 연결할 수 있게 됐습니다.
감사 기록은 성공한 실행만 남기지 않습니다. 승인 거절, 만료, Schema 검증 실패, 권한 부족 및 부분 성공도 같은 방식으로 기록합니다.
도입 후 달라진 점
가장 큰 변화는 단순히 요청 처리 속도가 빨라진 것이 아니었습니다.
담당자의 가용성이 처리 조건에서 빠졌다
개발자는 인프라 담당자가 온라인인지 먼저 확인하지 않고 Asana에 요청을 남길 수 있게 됐습니다.
조회와 진단은 Hermes가 필요한 맥락을 수집하고, 정해진 Playbook을 통해 일관된 형식으로 처리합니다. 변경이 필요한 경우에도 인프라 담당자는 AWS 콘솔에서 모든 단계를 직접 실행하는 대신, 실행계획과 영향 범위를 검토하는 데 집중할 수 있게 됐습니다.
실행 기준이 일관돼졌다
사람이 직접 작업할 때는 상황에 따라 검증 범위가 조금씩 달라질 수 있습니다.
Playbook에는 실행 후 반드시 확인해야 할 조건이 포함되어 있습니다. ECS 변경이라면 Running Task Revision과 Target Health를 확인하고, ALB 변경이라면 새 경로의 도달 여부뿐 아니라 기존 규칙의 회귀 여부도 확인합니다.
완료의 의미가 명확해졌다
이전에는 AWS API 호출이 성공하거나 ECS 롤아웃이 완료되면 작업을 성공으로 판단하기 쉬웠습니다.
자동화 이후에는 요청한 값, 서비스가 참조하는 값, 실제 태스크가 사용하는 값과 애플리케이션의 동작이 일치해야 성공으로 판정합니다.
운영 기록이 자연스럽게 남았다
별도 문서를 만들지 않아도 요청부터 결과까지 같은 요청 ID로 연결됩니다. 누가 어떤 변경을 승인했고 어떤 근거로 성공을 판단했는지를 나중에 다시 확인할 수 있게 됐습니다.
자동화로 생긴 새로운 고민
물론 이 구조가 모든 운영 문제를 해결해 주는 것은 아닙니다.
Playbook 밖의 요청은 처리할 수 없다
자유로운 CLI 실행을 막았기 때문에 새로운 유형의 요청은 바로 자동화할 수 없습니다. 먼저 위험을 분석하고 Schema, 검증 방법과 IAM Role을 설계해야 합니다.
이는 의도한 제약입니다. 처리 범위를 빠르게 넓히는 것보다 예측 가능한 동작을 유지하는 것이 더 중요하다고 판단했습니다.
승인 피로가 생길 수 있다
모든 조회까지 매번 승인하도록 하면 안전성은 높아지지만 반복적인 승인으로 중요한 변경을 놓칠 수 있습니다.
그래서 리소스와 조회 범위가 고정된 저위험 진단은 자동 실행 후보로 분리하고, 상태 변경이 발생하는 Playbook은 계속 승인을 요구하는 방향으로 정책을 조정하고 있습니다.
자연어 해석은 검증 대상이다
Hermes가 만든 계획은 정답이 아니라 실행 후보입니다.
요청을 잘못 해석하거나 필요한 정보가 부족하면 계획 생성을 중단하고 추가 정보를 요청합니다. 대상 계정, 환경, 리전 또는 리소스가 불명확한 상태에서는 추론해서 실행하지 않습니다.
Production은 별도의 통제가 필요하다
현재 변경 자동화 범위는 지정된 Alpha 리소스로 제한했습니다.
Production 변경은 Discord 한 사람의 승인만으로 실행하지 않습니다. 2인 승인이나 AWS SSO를 통한 2차 확인처럼 더 강한 통제 방식을 별도로 적용해야 합니다.
마무리
처음에는 밤과 주말에 반복되는 요청을 더 빨리 처리하고 싶어서 시작한 일이었습니다.
하지만 구현하면서 자동화의 목적을 다시 생각하게 됐습니다.
좋은 운영 자동화는 사람을 단순히 실행 과정에서 제거하는 것이 아니었습니다. 사람이 판단해야 할 부분과 기계가 반복해야 할 부분을 분리하고, 기계가 수행할 수 있는 범위를 명확하게 제한하는 일이었습니다.
Hermes는 AWS를 마음대로 다룰 수 있는 또 한 명의 인프라 담당자가 아닙니다.
요청의 맥락을 정리하고, 실행 가능한 계획으로 바꾸고, 사람이 승인한 범위 안에서만 정해진 Playbook을 호출하는 운영 인터페이스에 가깝습니다.
그 결과 개발자는 늦은 시간에 요청을 남기며 미안해할 필요가 줄었고, 인프라 담당자는 즉시 대응하지 못했다는 이유로 미안해할 필요가 줄었습니다.
우리가 자동화한 것은 AWS 명령 몇 개가 아니었습니다.
누군가의 가용성에 의존하던 운영 흐름을, 승인 가능하고 검증 가능하며 추적 가능한 시스템으로 바꾼 것이었습니다.
