호스팅 APM도, 프로덕션 트레이싱도, 일부러 기억해서 열어야 하는 대시보드도 없습니다. 따로 돈이 드는 건 로그 아카이브 하나로, 한 달에 2달러 정도입니다. 아래는 전체 목록과, 버렸거나 더는 믿지 않게 된 것들입니다. 그중 하나 때문에 저는 사용자가 한 명도 겪지 않은 장애를 며칠이나 쫓아다녔습니다.

여기서 말하는 모니터링, 그리고 이게 얼마나 작은 규모인지

#

제가 말하는 DevOps 모니터링은 두 가지입니다. 누가 알려주기 전에 뭔가 고장났다는 걸 먼저 아는 것, 그리고 짐작하지 않고 원인을 찾아낼 수 있는 것. 아래 도구는 전부 이 두 기준으로 평가했습니다.

작년에 개발자가 진짜로 쓰는 모니터링 만들기라는 글을 썼는데, 그때는 주로 팀을 염두에 뒀습니다. 작은 팀이라면 클라우드 업체가 기본으로 주는 모니터링, 서비스가 수백 개라면 호스팅 APM, 이런 식이었죠. 이번 글은 같은 생각의 가장 작은 쪽 끝입니다. 두 프로덕트 모두 요즘 쓰는 기술 스택에서 설명한 대로 Fly의 shared-cpu-1x 머신 위의 Django이고, 개발자는 둘 다 저 혼자입니다. 모니터링이 하나의 프로덕트이고 개발자가 그 사용자라면, 제 모니터링의 사용자는 딱 한 명인 셈이죠. 9월에 Fly 메트릭으로 기준치를 뽑아 봤더니 마켓플레이스 API의 평균 CPU 사용률이 1%였습니다. 엔터프라이즈 스택이 아니고, 그런 척할 생각도 없습니다.

메트릭, 로그, 트레이스라는 세 기둥 중 제게 있는 건 둘입니다. 두 프로덕트 모두 분산 트레이싱이 없습니다. 각각 Django 코드베이스 하나에 데이터베이스 하나라서, 트레이스가 넘나들 서비스 경계가 없기 때문입니다. 제가 보는 트레이스는 제 워크스테이션에서 돌리는 리버스 프록시의 트레이스가 전부입니다.

목록

#

표에서 “두 앱 모두"라고 적지 않은 건 전부 마켓플레이스 얘기입니다. 견적 앱은 이보다 적습니다. Fly의 헬스 체크, 로그, 메트릭, iOS 앱 분석, 그리고 데이터베이스를 매일 Parquet으로 내보내 DuckDB로 조회하는 것 정도죠. 크래시 리포팅도 알림 채널도 없고, 이 글에서 가장 큰 빈틈이 바로 이겁니다. (업데이트 서비스 행에 대해 밝혀 둘 것: 이 서비스를 만든 회사는 그쪽 블로그에 글을 쓰는 대가로 제게 돈을 지급합니다.)

에러: 채팅으로 올리는 로깅 핸들러

#

9월 전까지는 처리되지 않은 500, 실패한 푸시 알림, 깨진 WebSocket 프레임이 나타나는 곳이 flyctl logs뿐이었고, 그 스트림을 누가 시키지도 않았는데 읽는 사람은 없습니다. 지금은 로깅 핸들러가 ERROR 이상인 모든 레코드를 API, WebSocket 서버, 백그라운드 워커 어디서 나든 채팅 채널로 보냅니다. 경고(WARNING)는 일부러 알리지 않습니다.

핸들러는 백그라운드 스레드에서 전송하니 요청을 느리게 만들지 않습니다. 핸들러 안에서는 아무것도 로그를 남기지 않으니 재귀에 빠질 일도 없습니다. 그리고 같은 에러는 10분에 한 번까지만, 시간당 최대 30건까지만 보내서, 장애가 나도 메시지 천 개가 아니라 하나로 읽힙니다.

이 채널에는 에러와 나란히 놓고 읽고 싶은 것들도 올라옵니다. 배포는 시작할 때, 올라왔을 때, 실패한 지점에서 커밋과 실행한 사람을 함께 올리고, OTA 업데이트와 웹 릴리스도 마찬가지입니다. 한 계정에 잘못된 로그인 코드가 몰리면 그것도 ERROR로 남기 때문에, 누가 비밀번호를 찍어 보고 있으면 장애와 같은 자리에 나타납니다.

10월에는 어느 로그에도 대응하는 줄이 없는 알림이 하나 왔습니다. 그 뒤로 알림마다 짧은 랜덤 id, 호스트명, 프로세스 시작 명령을 붙이고, 같은 줄을 그 프로세스의 로그에도 씁니다. 그래서 id를 어디서도 못 찾으면, 그 알림은 그곳에 로그를 남기지 않는 프로세스, 예컨대 SSH 셸에서 온 겁니다. 채널에 올라오는 건 전부, 제가 같이 일하는 코딩 에이전트가 읽을 수 있는 피드에도 들어갑니다. 코드를 만지는 에이전트도 제가 보는 시점에 같은 에러를 보는 거죠.

로그: Fly의 로그 쉬퍼로 S3에 쌓고 DuckDB로 조회

#

Fly 자체 버퍼는 몇 분치 출력, 대략 마지막 백 줄 정도를 갖고 있습니다. 배포를 지켜보기엔 충분하지만 어제 일에는 쓸모가 없죠. 그래서 세 번째 Fly 앱에서 Fly의 로그 시퍼를 돌립니다. 조직의 로그 스트림을 구독하는 Vector인데, S3 싱크 하나만 바꿨습니다.

[sinks.aws_s3]
  type = "aws_s3"
  bucket = "myapp-logs"
  compression = "gzip"
  key_prefix = "logs/{{fly.app.name}}/%F/"   # one folder per app per day
  batch.timeout_secs = 300                  # a quiet app still lands its lines

마켓플레이스 앱들의 모든 로그 줄이 gzip으로 압축된 JSON으로 S3 호환 버킷에 쌓입니다. 시퍼는 256MB짜리 shared-cpu-1x 머신 한 대로, 한 달에 2달러 정도에 스토리지는 푼돈입니다. DuckDB는 매크로 하나로 파일을 제자리에서 읽고, 하루치가 1초 안팎이면 나옵니다.

CREATE MACRO logs(app, day := '*') AS TABLE
  SELECT * FROM read_json_auto('s3://myapp-logs/logs/' || app || '/' || day || '/*.log.gz',
                               union_by_name := true);

SELECT timestamp, message FROM logs('myapp-api', '2026-09-06') WHERE message LIKE '% 500 %';

0으로 스케일 다운 글에서 콜드 스타트를 잰 것도 이 매크로였습니다. 시작 스크립트가 단계마다 알리고, 줄마다 머신 id가 붙어 있으니, 나머지는 GROUP BY 한 번이면 됩니다.

정리하면 하나의 스트림을 읽는 사람에 따라 세 단계로 나눈 셈입니다. 아카이브는 INFO 이상을 전부 보관하고(프로덕션 앱이 INFO로 로그를 남기는 이유이기도 합니다), 실시간 확인 스크립트는 경고와 에러만 보여주고, 채팅 채널은 ERROR를 받습니다. 다만 셋 다 호출한 쪽은 모릅니다. 액세스 로그에 클라이언트 IP도 user agent도 없어서, 그건 Cloudflare에서 봅니다.

메트릭: Fly에 기본으로 딸린 Prometheus

#

Fly는 조직마다 매니지드 Prometheus를 돌려주기 때문에 저는 메트릭 스택을 따로 운영하지 않습니다. 궁금한 게 생기면 API를 칩니다. 머신별 메모리, CPU, 버스트 크레딧(공유 CPU에서는 fly_instance_cpu_balance가 중요합니다), 앱별 응답 수와 동시 요청 수 같은 것들이죠. 처음부터 알았으면 좋았을 게 두 가지 있습니다. fly tokens create로 만든 토큰은 Authorization: FlyV1 <token>으로 보내야 합니다. Bearer는 flyctl auth token의 개인 토큰에만 통하고, 읽기 전용 토큰은 “something went wrong resolving organization"을 돌려줍니다. 그리고 보관 기간이 2주 정도입니다(Fly 설명으로는 15일쯤).

이게 제 몫을 한 건 9월이었습니다. 로그에 “Could not open a database connection"이 하루에도 몇 번씩 찍혔고, 딱 앱 버그처럼 보였습니다. 매니지드 Postgres 클러스터도 같은 Prometheus에 들어 있었는데, 그 에러가 난 매 분마다 프라이머리의 스크레이프 시간이 80밀리초 남짓에서 1~10초로 뛰었고, 레플리카는 멀쩡했고, Postgres 시작 시각은 그대로였습니다. Postgres가 재시작된 게 아니라 그 아래 호스트가 멈췄던 겁니다. 타임스탬프를 Fly 지원팀에 보냈고, 10월 초 점검 재시작으로 프라이머리가 다른 호스트로 옮겨진 뒤로 매일 나던 멈춤은 사라졌습니다.

크래시 리포트: 제 API를 바라보는 Sentry SDK

#

예전에는 폰에서 앱이 죽어도 제가 볼 수 있는 곳 어디에도 흔적이 남지 않았습니다. 뻔한 답은 Sentry였고, 저는 그 절반만 가져왔습니다. 앱에는 Sentry의 오픈소스 SDK가 들어 있지만 DSN은 제 Django API의 엔드포인트를 가리킵니다. 그 엔드포인트가 Sentry의 envelope 형식을 받아서 크래시를 묶고, 같은 채팅 핸들러로 알립니다. 트레이싱, 세션, 리플레이는 꺼 두었고 에러만 받습니다.

sentry.io에 가입하지 않은 건, 하루 몇 건 수준의 리포트를 위해 사용자 데이터를 쥔 업체 하나, 개인정보 처리방침 한 줄, 청구서 하나를 더 늘리고 싶지 않았기 때문입니다. 그 대가는 심볼리케이션이고, 이건 아직 대체하지 못했습니다. 스택은 minify된 JavaScript거나 날것의 네이티브 주소라서, 이슈를 보면 무엇이 어느 릴리스와 기기에서 죽었는지, 직전에 사용자가 뭘 했는지는 알지만 소스의 어디인지는 모릅니다.

대시보드는 메시지 하나

#

두 앱 모두 대시보드를 따로 만들지 않았습니다. 작년 글에 대시보드를 가리는 기준을 하나 적었는데, 아무도 알아서 열지 않는 대시보드라면 존재 가치를 증명하지 못한 거라는 겁니다. 알아서 도착하는 메시지는 열 필요가 없으니, 제게 가장 대시보드에 가까운 건 매일 아침 팀 채팅에 올라오는 글 하나입니다.

맨 앞은 지난 24시간의 프로덕션 에러입니다. 채팅 채널이 아니라 로그 아카이브에서 읽는데, 알림은 횟수가 제한돼 있어서 무언가가 몇 번 일어났는지 말해 주지 못하기 때문입니다. 숫자, id, 주소를 가린 뒤 묶기 때문에 같은 실패 백 건은 횟수가 붙은 한 줄이 되고, 이메일 주소가 채널에 흘러들 일도 없습니다.

그다음이 실패한 헬스 체크, 전날 사용량을 일주일 전 같은 요일과 비교한 것(일요일은 월요일과 절대 같지 않으니까요), 최근 일주일 검색 유입, 답장을 기다리는 채팅, 작업 보드, 그리고 지출입니다. 불러오지 못한 섹션이 있으면 그렇다고 적고, 글은 그래도 올라갑니다.

앱 분석 데이터를 API로 읽다 보면 숫자를 조금은 의심하게 됩니다. 8월에는 아제르바이잔에서 Android 첫 실행이 121건 찍히고 그 뒤로 삭제가 119건 따라왔는데, 그달 Android 합계는 이걸 빼고 읽습니다.

릴리스에는 따로 보는 화면이 있습니다. OTA 업데이트를 제 서버에서 내보내던 시절, 릴리스를 보는 방법은 “is active” 체크박스가 달린 관리자 목록이 전부였고, 업데이트를 받은 폰이 몇 대인지 전혀 몰랐습니다. 지금 쓰는 서비스의 대시보드는 기기들이 실제로 어떤 릴리스를 돌리는지, 설치가 어떻게 됐는지, 그리고 잘못된 번들이 죽어서 SDK가 이전 번들로 되돌렸을 때의 크래시 롤백까지 보여줍니다. 호스팅 업데이트 서비스로 옮긴 이야기는 따로 정리해 두었습니다.

버린 것, 또는 더는 믿지 않게 된 것

#

이 중 유료 도구는 하나도 없습니다. 대부분은 신호인 줄 알았는데 신호가 아니었던 것들이고, 하나는 잘못된 곳에서 돌던 작업입니다.

user agent로 묶어 보기 전까지의 Cloudflare 504 비율

#

9월에 Cloudflare 대시보드를 보니 하루 요청의 22%가 504로 실패하는 것처럼 나왔습니다. 앱이 30초마다 폴링하는 엔드포인트에 몰려 있었는데, 헬스 체크는 전부 정상이었고 앱 자체 로그로는 그 요청들이 빨랐습니다. 며칠을 매달렸습니다. 머신이 콜드 스타트에 25~33초가 걸리고 그걸 하루 92번 한다는 걸 찾아내 고쳤고, 0으로 스케일 다운 글에 그게 원인이라고 썼습니다.

다음 날 아침 같은 504를 user agent로 묶어 봤습니다. 9월 5일부터 9일 사이의 7,344건이 전부 Cloudflare 자체의 Early Hints 캐시 조회(user agent는 bastion early hints, nginx-ssl early hints)였습니다. 이 조회는 오리진에 아예 가지 않습니다. 그 줄의 504는 타임아웃이 아니라 캐시 미스를 기록한 것이죠. 실제 요청 경로를 따라 하기 때문에 가장 바쁜 엔드포인트에 떨어졌고, 정말로 사용자가 실패하는 것처럼 보였습니다. 앱, 브라우저, curl, 검색 엔진 크롤러에서는 한 건도 없었습니다. 오리진이 Link 헤더를 보내지 않으니 Early Hints는 아무 일도 하고 있지 않았고, 그래서 일단 껐습니다. 나중에는 제대로 동작하게 만들었습니다.

콜드 스타트 작업은 그래도 남는 게 있었습니다. 배포도 깨어나는 것도 빨라졌으니까요. 하지만 고친다고 생각했던 장애는 사용자에게 닿은 적이 없었습니다.

그래서 꼭 전하고 싶은 규칙이 이겁니다. CDN의 에러율을 믿기 전에 user agent로 묶어서, 그게 CDN 자기 장치에서 나온 게 아닌지 확인하세요. Cloudflare 무료 플랜에서는 httpRequestsAdaptiveGroups에 대한 GraphQL 쿼리로, 하루씩 끊어서 볼 수 있습니다. 다음 소동도 같은 쿼리로 정리됐습니다. 폴링 엔드포인트 하나가 하루 70~260건에서 2,880건으로 뛰었는데, 스크레이퍼가 아니었습니다. 테스트하고 나서 iOS 시뮬레이터에 앱을 켜 둔 채로 둔 제 Mac이었습니다.

초록불 헬스 체크

#

Fly는 두 앱의 /api/health/를 30초마다 확인하고, 그 결과로 어느 머신에 트래픽을 보낼지 정합니다. 그 일은 잘합니다. 하지만 헬스 체크는 이미 떠 있는 머신을 상대로 돌기 때문에, 머신이 뜨기 전에 일어나는 일은 보지 못합니다. 콜드 스타트, 프록시 앞의 대기열, 끝내 도착하지 않는 요청 같은 것들이죠. 지금은 라우팅 말고는 바라는 게 없습니다.

배포 때는 대신 프로브 스크립트를 씁니다. 배포 내내 오리진을 치다가 하나라도 실패하면 1로 종료합니다. 이 스크립트가 평범한 flyctl deploy에서 7.3초짜리 공백을 잡아냈고, 예비 머신을 먼저 깨우는 배포 스크립트로 바꾼 뒤에는 2,514건 중 실패가 0건이었습니다.

헬스 체크는 스스로 장애를 두 번 일으키기도 했습니다. 7월에는 Django의 SECURE_SSL_REDIRECT가 Fly의 평문 HTTP 프로브에 301로 답해서, 모든 머신이 체크에 실패했고 모두가 503을 받았습니다. 8월에는 헬스 뷰의 except Exception을 좁혔더니 “connection already closed” 에러가 500으로 새어 나갔고, 뷰의 재시도가 바로 그 경우를 위해 있었는데도 Fly가 머신을 빼 버렸습니다. 지금 체크는 이 프로세스가 요청을 처리할 수 있는지만 묻고, DB가 멈춰도 두 앱이 라우팅에서 빠지지 않습니다.

아침 요약도 세는 법에서 같은 교훈을 얻었습니다. 마켓플레이스는 놀고 있는 머신을 서스펜드하기 때문에, 요청에 깨어난 머신은 시작 후 몇백 밀리초 만에 첫 체크에 실패하고 다음 체크는 통과합니다. 이걸 세다 보니 매일 아침이 장애처럼 읽혔고, 그래서 1분 안에 다시 통과한 실패는 이제 머신 기상과 배포로 따로 적습니다.

CI의 예약 작업

#

아침 요약은 cron 일정으로 도는 CI 워크플로로 시작했다가 하루 만에 옮겼습니다. 앱 분석과 검색 데이터를 읽게 되자 필요한 키가 분석 프로젝트의 서비스 계정 키였는데, 그 프로젝트에서 뭐든 할 수 있는 키라 CI 시크릿에 두고 싶지 않았습니다. 지금은 제 Mac의 스케줄러가 20분마다 실행하고, 오클랜드 시간으로 아침 8시가 지났는데 오늘 글이 아직 안 올라갔을 때만 올립니다. 그러니 8시에 잠들어 있던 Mac은 깨어나면서 올리죠. 워크플로는 앱 분석과 검색 섹션을 뺀 수동 대비책으로 남겨 두었습니다.

다시 시작한다면

#

첫 장애가 난 뒤가 아니라 첫 사용자가 오기 전에 세 가지를 깔겠습니다. 팀이 이미 읽는 채팅 채널로 에러 보내기(횟수 제한 포함), SQL로 조회할 수 있는 오브젝트 스토리지 로그 아카이브, 그리고 플랫폼이 이미 모으고 있는 메트릭. 한 달에 몇 달러면 됩니다. 크래시 리포팅은 앱이 폰에 올라가는 주에 붙입니다. 그러지 않으면 폰에서 난 크래시는 아무에게도 아무것도 알려주지 않으니까요. 아침 요약은 확인할 곳이 너무 많아져서 결국 아무 데도 확인하지 않게 될 즈음에 붙이면 됩니다.

트레이싱은 요청이 넘나들 두 번째 서비스가 생길 때까지, 호스팅 APM은 공유 대시보드와 온콜 순번, 남의 청구서를 감당할 예산이 필요한 팀이 생길 때까지 미루겠습니다. 작년 글의 도구들이 제값을 하기 시작하는 건 그때부터입니다. 그 전까지 가장 쓸모 있는 습관은 공짜입니다. 숫자가 무서워 보이면, 무엇이 고장났는지 정하기 전에 그 숫자를 무엇이 만들었는지부터 확인하세요. 이 글에 나온 소동 중 여럿은 프로덕트가 아니라 모니터링에서 나왔습니다.

“내 컴퓨터에서는 되는데"와 “프로덕션에서 된다” 사이에는 간극이 있고, 모니터링은 그 간극을 메우라고 존재합니다. 그런데 대부분은 메우지 못하죠. 장애가 났을 때 개발자가 손을 뻗는 도구가 아니라, 운영팀을 위한 도구로 만들어지기 때문입니다.

최근 프리랜서로 DevOps와 인프라 일을 시작했는데, 새로운 현장에 들어가면 가장 먼저 보는 것 중 하나가 모니터링 구성입니다. README보다 팀의 실체를 훨씬 잘 보여주거든요. 그리고 실패 패턴은 거의 매번 같습니다. 도구는 다 있는데, 개발자가 실제로 일하는 방식과 연결이 안 되어 있는 겁니다. 프로덕션 로그만 볼 수 있었다면 5분에 끝날 버그에 누군가 3시간을 쓰고, 장애는 알림이 아니라 고객 문의 티켓으로 알게 되고, 반대로 하루 200개씩 쏟아지는 알림은 대부분 노이즈라 모두가 전부 무시하게 되고, 그 결과 인시던트가 터질 때마다 처음 30분을 “고치는” 게 아니라 “뭐가 고장났는지” 찾는 데 씁니다.

이 글은 일반론입니다. 프로덕트 두 개에 제가 지금 실제로 쓰는 도구는 따로 정리해 뒀습니다.

메트릭, 로그, 트레이스는 연결돼야 의미가 있다

#

메트릭은 뭔가 잘못됐다는 걸 알려줍니다(에러율 급증, 레이턴시 상승). 로그는 무슨 일이 있었는지(스택 트레이스, 요청 페이로드, 에러 메시지), 트레이스는 어디서 일어났는지(어느 서비스, 어느 엔드포인트, 어느 DB 호출) 알려주죠. 여기까진 다들 아는 얘기입니다. 중요한 건 이 셋이 연결되어 있느냐입니다. 알림이 울리면 메트릭에서 관련 로그로, 다시 트레이스로 클릭만으로 넘어갈 수 있어야 합니다. 개발자가 도구 세 개를 오가며 타임스탬프를 손으로 맞추고 있다면, 각 도구가 아무리 훌륭해도 그 구성은 실패한 겁니다.

대시보드에도 같은 잣대를 들이댈 수 있습니다. CPU, 메모리, 디스크 I/O는 용량 계획에는 중요하지만 500 에러 디버깅에는 아무 도움이 안 됩니다. 개발자들이 자발적으로 여는 대시보드에는 기술 메트릭 옆에 비즈니스 메트릭(에러율 옆에 시간당 가입 수), 타임라인 위에 겹쳐진 최근 배포, 로그 링크가 붙은 최근 1시간 상위 5개 에러, 그리고 평균이 아닌 레이턴시 퍼센타일(p50, p95, p99)이 있습니다. 아무도 알아서 열지 않는 대시보드라면 존재 가치를 증명하지 못한 거죠.

알림도 같은 원리입니다. 모든 알림은 두 가지 질문에 답해야 합니다. 뭐가 고장났는가, 그리고 어디서부터 봐야 하는가.

나쁜 알림: “web-server-3 CPU 높음”

좋은 알림: “14:32부터 /api/payments 에러율 > 5%. 마지막 배포: 14:15, @sarah. [로그 보기] [트레이스 보기]”

두 번째 쪽으로 가려면 몇 가지 요령이 있습니다. 임의의 임계값이 아니라 베이스라인 이탈로 알림을 걸고, 소유권 기준으로 라우팅하고(결제 에러는 조직 전체가 아니라 결제팀으로), 연관된 에러는 개별 알림 50개가 아니라 Slack 메시지 하나로 묶는 겁니다. 피드백 루프도 짧게 유지해야 합니다. “뭔가 고장남"에서 “개발자가 알게 됨"까지 1분 이내가 기준인데, 그러려면 5분 배치가 아닌 실시간 로그 스트리밍, 모든 대시보드의 배포 마커, 서비스 경계를 넘어도 끊기지 않는 분산 트레이싱이 필요합니다.

쓸 사람을 위해 만들 것

#

운영팀이 저지르는 가장 큰 실수는 자기 자신을 위한 모니터링을 만드는 겁니다. 해법이 대단한 것도 아닙니다. 디버깅 중인 개발자 옆에 앉아서 어디서 막히는지 지켜보세요. 인시던트 중에 어떤 질문이 오가는지 물어보세요. “어느 서비스야?”, “뭐가 바뀌었지?”, “요청이 어떻게 생겼는데?” 같은 것들이요. 그리고 제품에 정말 중요한 메트릭이 뭔지 찾아내세요. CPU인 경우는 거의 없고, 보통은 체크아웃 완료율이나 업로드 성공률 같은 것들입니다.

그다음은 마찰 제거입니다. 새 서비스 계측에 하루가 걸리면 아무도 안 합니다. 쓰고 있는 프레임워크(Django, Express, Spring)를 자동 계측하는 라이브러리, 복사해서 바로 쓰는 대시보드·알림 템플릿, 티켓 없이 직접 메트릭을 추가할 수 있는 셀프서비스 도구를 마련하세요. 그리고 전체를 코드처럼 다루세요. 설정은 버전 관리에 넣고, 알림 규칙은 “울려야 할 때 울리는지” 테스트하고, 멀티 리전으로 갈 계획이라면 처음부터 반영해 두는 겁니다.

만든 뒤에는 같은 습관으로 살려 둡니다. 계측 코드는 다른 프로덕션 코드와 똑같이 코드 리뷰를 거치고, 직접 만든 메트릭에는 테스트를 붙입니다. 포스트모템 때마다 “어떤 모니터링이 있었으면 더 빨리 잡았을까"를 묻고, 그 답은 보고서가 아니라 그 주의 대시보드와 알림에 반영합니다. 그리고 일 년에 몇 번은 전체를 훑어서 아무도 안 여는 걸 지웁니다. 아무도 반응하지 않는 알림은 다음 알림도 무시하도록 사람들을 길들이니까요.

AWS 위의 소규모 팀이라면 일단 CloudWatch

#

엔지니어 50명 미만에 AWS를 쓰고 있다면 CloudWatch가 올바른 출발점입니다. 첫날부터 더 화려한 걸 사고 싶은 유혹은 참는 게 좋습니다. EC2, Lambda, RDS, ECS가 전부 자동으로 CloudWatch에 리포트하니 계측 코드 없이도 가시성이 생기고, 소규모 팀 기준 월 10~50달러에 고정 플랫폼 비용도 없습니다. 메트릭, 로그, 트레이스(X-Ray 경유), 알람이 한곳에 모여 있고, 의미 있는 알림과 대시보드 정도는 몇 주가 아니라 반나절이면 만듭니다.

과소평가된 기능이 CloudWatch Logs Insights입니다. Elasticsearch를 따로 세우지 않아도 로그에 쿼리를 날릴 수 있죠:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)

그 밖의 포인트:

• 복합 알람으로 노이즈를 줄이세요. 에러율이 높고 “동시에” 응답 시간이 나빠졌을 때 울리게 하는 겁니다. 조건마다 따로가 아니라요.
• 진짜 가치는 커스텀 메트릭에 있습니다. CloudWatch SDK로 비즈니스 메트릭(가입, 거래, 기능 사용량)을 인프라 메트릭과 나란히 보내세요.
• CloudWatch Synthetics는 사용자 여정을 따라가는 카나리 테스트를 스케줄로 돌려줍니다. 체크아웃이 깨진 걸 사용자보다 먼저 알게 되죠.
• X-Ray면 최소한의 설정으로 분산 트레이싱이 됩니다. 대부분의 마이크로서비스 구조에는 이걸로 충분합니다.

졸업 시점도 명확합니다. 멀티 클라우드로 가거나, 제대로 된 이상 감지가 필요해지거나, 대시보드 커스터마이징이 고통스러워지거나, 팀이 50명을 넘어 본격적인 협업 기능이 필요해질 때입니다.

팀이 커지면 Datadog

#

Datadog은 비쌉니다. 큰 조직이면 연간 2만~10만 달러 이상이 보통이지만, 규모가 되면 값을 합니다. AWS, Azure, GCP, 온프레미스, 컨테이너, 서버리스, 데이터베이스, 프론트엔드를 하나의 뷰에서 봅니다. Watchdog이 임계값을 손으로 조정하지 않아도 이상 패턴을 잡아주는데, 서비스가 수천 개면 사람이 눈으로 지켜볼 방법이 없으니 이게 큽니다. CloudWatch에 없는 협업 레이어도 갖춰져 있습니다. 팀별 대시보드, RBAC, 공유 조사 노트북, PagerDuty/Opsgenie 연동, 다중 조건 알림, 임계값 돌파 예측, 유지보수 윈도우, 그리고 코드 수준 프로파일링까지 내려가는 APM과 자동 생성 서비스 맵까지요.

도입 순서는 대략 이렇게 잡습니다. 중요한 서비스부터 계측하고, 첫날부터 팀·환경별 태깅을 철저히 합니다. 메트릭 명명 규칙, 대시보드 템플릿, 알림 심각도 레벨, SLO 정의는 초반에 합의하세요. 표준을 나중에 소급 적용하는 건 정말 고역입니다. CI/CD 배포 마커, 인시던트 관리, Slack과 연동하고, 교육 시간도 확보하세요. Datadog은 강력하지만 그냥 봐서는 못 씁니다. 그리고 청구서를 주시하세요. 노이즈 많은 메트릭은 필터링하고, 트래픽 많은 서비스는 트레이스를 샘플링하고, 실제로 쓰는 기능이 뭔지 정기적으로 점검하는 겁니다.

계약 전에 볼만한 대안으로는 New Relic(비슷한 구성, 대용량 트레이싱은 더 쌀 수도), Dynatrace(AIOps가 강하고 금융권에서 인기), Splunk(로그 분석은 최고 수준, 보안팀이 이미 쓰고 있다면 더욱), Grafana Cloud(이미 Prometheus/Loki를 쓴다면 자연스러운 선택)가 있습니다.

실제로는 많은 팀이 하이브리드로 정착합니다. AWS 네이티브 서비스는 자동에 저렴한 CloudWatch로, 애플리케이션 레이어는 Datadog으로, 그리고 CloudWatch 메트릭을 Datadog으로 수집해 통합 뷰를 만드는 거죠. 멋은 없지만, 잘 굴러갑니다.

CloudWatch vs Datadog 한눈에 비교

#

처음부터 시작한다면: 모니터링 시스템 구축 순서

#

제가 하는 순서는 이렇습니다.

1. 개발자들에게 인시던트 때 뭐가 힘든지 묻습니다.
2. 중요한 플로우의 SLO를 정의합니다. 로그인, 체크아웃, 검색에서 “작동한다"는 게 정확히 무슨 뜻인지요.
3. 그 크리티컬 패스부터 계측합니다.
4. 다음으로 분산 트레이싱을 넣습니다. 마이크로서비스 구조에서는 디버깅 투자 대비 효과가 제일 크거든요.
5. 알림은 CPU가 아니라 그 플로우에 걸고, 알림마다 담당 팀으로 보냅니다.
6. 모든 알림에 런북을 붙여서 새벽 3시의 내가 뭘 확인해야 할지 알 수 있게 합니다.
7. 분기마다 리뷰 일정을 잡아 묵은 알림을 지우고, 어긋난 임계값을 고치고, 대시보드가 현재 아키텍처와 맞는지 확인합니다.

제가 팀들을 여러 번 건져내야 했던 함정들도 적어둡니다. 도구 과잉(연동되는 3개가 연동 안 되는 6개보다 낫습니다), 베이스라인 없는 그래프(500 rps가 평소 수준인가요, 10배 스파이크인가요?), 사용자와 무관한 것 모니터링(스테이트리스 컨테이너의 디스크 I/O 같은 것), 그리고 모니터링 자체의 이중화 부재. 인시던트 도중에 알림 시스템이 죽으면, 가장 잘 보여야 할 순간에 아무것도 안 보이게 됩니다.

이 중 어느 것도 최고급 도구를 요구하지 않습니다. 필요한 건 개발자가 필요한 정보를, 실제로 보는 곳에서, 빠르게 얻는 것뿐입니다.