먼저 고정해야 했던 것은 서비스 수가 아니었다
TravelPlanner를 AWS에서 검증할 때 처음부터 EKS를 도입하는 선택도 가능했습니다. 하지만 당시 더 중요한 질문은 오케스트레이터의 종류가 아니었습니다.
- 어떤 리소스가 계속 남아 있어야 하는가
- 어떤 리소스는 실험할 때만 만들고 제거해야 하는가
- 비용 화면의 금액을 어느 범위까지 주장할 수 있는가
- 다음 구조 변경을 비교할 기준선이 있는가
이 네 질문에 답하지 못한 상태에서 서비스 수만 늘리면 운영 복잡도는 커지지만 판단 근거는 좋아지지 않습니다. 그래서 지속되는 dev 경계와 실험 시 생성하고 제거하는 dev-runtime, dev-load-test 경계를 먼저 나눴습니다.
여기서 중요한 제한이 있습니다. 이 구조도는 실험 당시의 수명 주기를 설명합니다. TravelPlanner 런타임이 현재 계속 운영 중이라는 뜻이 아닙니다.
US$12.54가 말하는 범위
공개할 수 있는 비용 문장은 하나로 고정했습니다.
2026-08-13 캡처 시점의 2026년 8월 AWS 계정 누적 비용은 화면 표시 US$12.54였습니다.
CSV의 정확 합계는 12.5405041414이고 세금 항목은 1.14입니다. 화면과 CSV는 반올림 범위에서 일치합니다.
그러나 이 금액만으로는 다음을 말할 수 없습니다.
- TravelPlanner만 사용한 비용
- 한 달 전체 run-rate
- 특정 구조가 절감한 금액이나 비율
- 화면에 표시된 17개 서비스가 모두 TravelPlanner에서 사용되었다는 주장
비용 화면에 월별 평균이라는 표현이 보이더라도, 캡처에 Billing 필터가 나타나지 않기 때문입니다. 그래서 프로젝트 카드, 사례연구, 이 글 모두 계정 누적 비용이라는 같은 범위를 사용합니다.
기준선이 있어야 다음 선택을 설명할 수 있다
EKS는 미래 대안으로 검토할 수 있지만 이 프로젝트에서 구현한 결과로 표현하지 않습니다. 당시에는 ASG 기반 실행 경계와 관측 흐름을 먼저 검증했습니다. 그 위에서 20 rps 기준선 후보를 세 번 반복하고, 배포와 복구 시나리오를 같은 판정 계약으로 비교했습니다.
이 순서가 남긴 가치는 서비스 이름이 아니라 비교 가능성입니다.
- 비용은 계정 누적 범위로 고정
- 환경은 지속 경계와 일시 경계로 분리
- 성능은 같은 입력 계약으로 반복
- 복구는 통과와 기준 미달을 모두 보존
다음 단계에서 EKS를 검토한다면 질문도 명확해집니다. 운영 부담, 배포 회복성, 관측 가능성, 비용이 현재 기준선보다 실제로 나아지는지를 같은 계약으로 비교하면 됩니다.
내가 맡은 범위와 팀 결과를 분리했다
여행 일정 제품과 AWS 실행 결과는 팀 시스템의 성과입니다. 개인 기여로는 protove 비병합 커밋에서 확인되는 Terraform 실행 경계, GitHub OIDC, ASG 이미지 갱신, 관측 흐름, CI 정책, 부하·복구 evaluator, 백엔드 보안 경계를 구분해 기록했습니다.
이 구분은 겸손을 위한 표현 장치가 아닙니다. 누가 무엇을 바꿨는지 확인할 수 있어야 다음 장애와 비용 판단에서도 책임 범위를 정확히 찾을 수 있기 때문입니다.
다음 글
다음 글에서는 20 rps라는 숫자보다 더 중요한 내용을 다룹니다. 기준선 후보 3회는 통과했지만 전체 B-01 gate가 실패한 이유, 그리고 다섯 배포·복구 시나리오에서 3건 통과와 2건 기준 미달을 어떻게 읽었는지 정리합니다.