date
slug
author
status
tags(최대 3개)
summary
type
thumbnail
category
updatedAt
TL;DR
- ECS·EC2·EKS 세 플랫폼의 흩어진 배포를 한 채널·한 포맷으로 통합
- 공통 신호로 APM 트레이스의
git SHA 태그사용: Lambda가 신규 배포만 감지
- 장애가 나면 직전 30분 배포를 장애 스레드에 자동 첨부
- 결과: prod 247개 서비스 통합, 배포 단서 자동 첨부 중앙값 13초, 원인 규명 24건 기여
도입 "최근에 뭐 배포했어?"
지난 겨울 인프라팀에 합류해 우리 환경을 처음 들여다봤을 때, 한 가지가 눈에 걸렸습니다. 배포가 어디에도 한눈에 보이지 않았습니다. 누가·언제·어디에 배포했는지 한곳에 모이지 않으니, 장애가 날 때마다 가장 먼저 나오는 질문은 늘 똑같았습니다. "최근에 뭐 배포했어?" 원인 1순위가 배포인데 대응은 늘 ArgoCD·배포 서버·깃을 번갈아 뒤지는 확인부터 시작됐습니다.
이건 새로 온 저만의 불편이 아니었습니다. '배포 이력을 추적하자’는 2025년 8월부터 티켓에 올라왔지만, 우선순위에 밀려 반년 가까이 손대지 못한 일이었습니다. 그 일을 입사 직후 첫 온보딩 과제로 맡아, 2달만에 끝냈습니다.
이렇게 빠를 수 있었던 건 아임웹이 AI를 적극적으로 활용하는 환경이기 때문입니다. 낯선 코드 파악부터 검토까지 AI를 붙이니, 갓 합류한 사람도 레거시와 신규 인프라를 가로지르며 속도를 낼 수 있습니다.
세 플랫폼, 세 가지 배포
배포가 보이지 않은 건 채널이 많아서가 아닙니다. 세 플랫폼의 배포 방식이 애초에 달랐기 때문입니다.
- EKS: ArgoCD GitOps, 매니페스트 머지로 배포
- ECS: 태스크 정의 교체로 롤아웃
- EC2 / ASG: 배포 서버에서 rsync로 수십 대에 배포
변경(배포)은 일어났는데 한곳에서 보이지 않았습니다. 관측 가능성의 공백입니다.
장애가 나면 "최근에 뭐 배포했어?"의 답을 플랫폼마다 다른 방법으로 찾아야 했습니다. EKS는 그나마 나았습니다. ArgoCD가 채널에 알림을 쐈으니까요. 다만 어떤 커밋이 나갔는지(git SHA)는 거기 없었습니다. ECS는 알림조차 없어 콘솔에서 태스크 정의 리비전을 하나씩 열어 대조했습니다. 다만 EC2 레거시는 알림이 있어도 포맷 없는 단발성이라, 결국 Git 커밋을 직접 열어 무슨 변경인지 확인했습니다.
결국 채널은 흩어져 있고 포맷도 제각각이라, 한곳에서 같은 모양으로 보이는 게 없었습니다. 장애가 흐르는 내내 확인했습니다.
하나로 묶는 공통 신호, APM 스팬 태그
흩어진 배포를 한곳에서 보이게 하고 싶었습니다. 처음엔 단순하게 생각했습니다.
’ArgoCD처럼 제각각 쏘던 알림을 그냥 한 채널에 모으면 되지 않을까’
하지만 그건 알림을 쌓는 것일 뿐, 세 플랫폼을 같은 기준으로 묶는 것도, 나중에 자동 첨부·분석으로 확장하지도 못했습니다.
그 무렵, 저희는 Datadog을 전사 통합 모니터링 표준으로 들이고 있었기 때문에 APM 활용을 고려했습니다. ECS·EC2·EKS 셋 모두에 공통으로 찍히는 신호가 거기 있습니다.
- 쿠버네티스 이벤트: EKS에서만 나오고 git SHA 없음
- ECS 배포 이벤트: git SHA 없음
- APM 트레이스: 세 플랫폼 공통, 게다가 커밋(SHA)까지
다만 APM에 그 태그가 처음부터 있던 건 아닙니다.
ECS엔 사이드카를 설치하고, 서비스마다 dd-trace를 넣어 트레이스에
@version·@git.commit.sha가 찍히게 만들었습니다. Datadog 도입으로 어차피 하던 작업이라 배포 신호는 그 위에 얹으면 됐습니다.이제 배포되면 version이 바뀝니다. Lambda가 1분마다 스팬을 집계 조회해,
(service, env, version, git_sha) 조합이 처음 등장하면 그때를 새 배포로 봅니다.
플랫폼마다 다른 배포 이벤트를 좇는 대신, 모든 서비스가 어차피 남기는 트레이스 하나로 묶었습니다. 모니터링 토대 위에 배포 관측이 그대로 얹혔습니다.
APM 트레이스를 신호로 쓰는 건 공짜가 아니었습니다.
- 트래픽이 흘러야 신호가 생깁니다. 트레이스는 요청이 들어와야 찍히므로, 트래픽이 거의 없는 서비스는 배포돼도 첫 스팬이 늦게 떠 탐지가 지연될 수 있습니다. (4장의 배치 누락도 이 약점의 한 변종이었습니다.)
- 태깅이 전제입니다. 모든 서비스에 dd-trace와 Unified Tagging이 정확히 박혀야 합니다. 태깅이 누락된 서비스는 곧 탐지 사각이 됩니다.
1단계: 한 채널·한 포맷
플랫폼과 무관하게, 같은 채널에서 같은 포맷으로 배포가 뜹니다.
- 플랫폼별로 다른 도구를 열 필요 없음
- EC2 레거시 서비스도 EKS·ECS와 똑같이 알림 수신
포맷도 통일했습니다. 어떤 플랫폼에 배포되든 한 장의 같은 카드로 뜹니다. 서비스명·버전·플랫폼·변경 내용(커밋)·커밋터·바로가기가 한곳에 모이고, 장애 발생 시 "이게 그 배포인가"를 맞춰볼 정보들을 기준으로 추가했습니다.
함정: EC2 배치
"version 바뀌면 배포" 규칙이 유일하게 통하지 않은 곳, EC2 배치(PHP CLI)입니다.
웹(PHP-FPM)은 멀쩡한데 배치만 누락됐습니다. 원인은 FPM과 CLI의 스팬 생명주기 차이였습니다.
[PHP-FPM] 요청마다 root 스팬 관리 → add_global_tag("version") → root에 반영 [PHP CLI] 프로세스 시작 시 root 스팬 '즉시' 생성 → 나중에 태그 달아도 소급 안 됨
배치는 CLI라, 태그를 달 시점엔 root 스팬이 이미 만들어진 뒤였습니다. 그래서 version이 비어 탐지에 실패했습니다. 해결은 이미 만들어진 root 스팬에 직접 태그를 쓰는 것이었습니다. (CLI에서만, 실패해도 무영향)
배치 배포도 다른 플랫폼과 똑같이 즉시 보이게 됐습니다. 비로소 세 플랫폼이 빠짐없이 한 규칙으로 묶였습니다.
작은 환경 차이가 큰 구멍을 만듭니다. FPM에선 되던 게 CLI에선 안 됐습니다 — "되겠지"가 아니라 환경별로 확인해야 했습니다.
2단계: 장애 스레드로 배포를 끌어오기
이제 찾으러 가지 않아도, 배포가 알림으로 따라옵니다.
1단계로 배포는 한 채널에 모였습니다. 하지만 그건 배포 채널을 열어봐야 보이는 정보입니다. 장애 한복판에 그 채널을 따로 띄워 맞춰볼 여유는 없습니다.
그래서 찾으러 가는 대신, 장애가 난 바로 그 자리로 밀어주기로 했습니다. 긴급 장애 알림이 뜨면, 그 시점 직전(최근 30분)에 나간 배포를 같은 스레드에 자동으로 붙입니다. 대응하는 사람은 알림만 열면 "방금 이게 배포됐다"를 바로 봅니다.
+0s [Datadog] Triggered: [P1] ALB Healthy Host Count 임계값 이하 ... +12s [devops-bot] 배포이력 (최근 30분, 1건) ← 자동 첨부 +42s [AI 분석봇] 분석 결과: fo-chat MFE 배포 중 일시적 헬스체크 실패 → 복구 완료
실제 사용 케이스: [P1] APM Error Rate 급증 → +109초, 담당자: "affiliate 쪽 배포가 많이 나갔네요. 관련 문제일 수 있어요" → PR 작성자 멘션
결과
흩어져 있던 배포를 하나의 신호로 묶었습니다. ECS·EC2·EKS 세 플랫폼에 걸쳐 247개 prod 서비스를 한 채널에서 관리합니다.
규모만 묶은 게 아닙니다. 장애가 나면 봇이 직전 배포를 같은 스레드에 중앙값 13초에 자동으로 붙입니다. 도입 전엔 이게 자동으론 뜨지 않았습니다. 누군가 "혹시 배포한 거 아니냐"고 알아채야 했고, 그마저 드물었습니다. 그리고 그 단서는 24번 실제 원인 규명으로 이어졌습니다(사람 21, AI 3).
마치며
배포가 어디에도 보이지 않던 데서 시작했습니다. 이제 세 플랫폼 어디에 배포되든 한 채널·한 포맷으로 모이고, 장애가 나면 직전 배포가 스레드에 먼저(중앙값 13초) 와 있습니다.
모니터링 토대(APM) 위에 배포 관측을 얹었을 뿐인데, 변경이 보이기 시작하자 장애 대응의 출발선이 통째로 당겨졌습니다. "최근에 뭐 배포했어?" 이제 그 답은 묻기 전에 와 있습니다.
다음 단계
지금 방식의 한계도 분명합니다. APM 트레이스에 의존하다 보니 사후 관측만 가능하고(trace가 떠야 감지, 최대 1분 지연), 빌드·배포가 시작되는 순간은 볼 수 없습니다. 한 배포가 한 메시지로 끝나 라이프사이클의 흐름도 보이지 않습니다. 그래서 2차 고도화는 Pull(1분 폴링)에서 Push로 관측 방식 자체를 바꿉니다.
- 파이프라인이 직접 이벤트를 쏩니다 빌드 시작 → 빌드 완료 → 배포 시작 → 배포 완료(또는 실패)를 한 메시지에서 타임라인으로 갱신합니다.
- 여기에 LLM을 얹습니다 배포마다 위험 등급(P1~P4)을 자동 산정해, "방금 이 배포가 얼마나 위험한가"를 사람이 가늠하기 전에 알려줍니다.
- P1처럼 위험한 배포라면, 담당자가 무엇을 먼저 봐야 하는지 모니터링 포인트까지 함께 제시합니다.
배포 알람을 통합하며 알람 시스템의 초석을 다졌습니다. 앞으로 고도화하여 배포의 가시성을 더욱 향상시키는 것이 목표입니다.
이승민A SRE Engineer
손이 떨리는 겁쟁이 SRE입니다. 끝없는 자동화를 추구합니다.