“내 컴퓨터에서는 되는데"와 “프로덕션에서 된다” 사이에는 간극이 있고, 모니터링은 그 간극을 메우라고 존재합니다. 그런데 대부분은 메우지 못하죠. 장애가 났을 때 개발자가 손을 뻗는 도구가 아니라, 운영팀을 위한 도구로 만들어지기 때문입니다.
최근 프리랜서로 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로 수집해 통합 뷰를 만드는 거죠. 멋은 없지만, 잘 굴러갑니다.
처음부터 시작한다면#
제가 하는 순서는 이렇습니다. 먼저 개발자들에게 인시던트 때 뭐가 힘든지 묻습니다. 중요한 플로우의 SLO를 정의합니다. 로그인, 체크아웃, 검색에서 “작동한다"는 게 정확히 무슨 뜻인지요. 그 크리티컬 패스부터 계측하고, 다음으로 분산 트레이싱을 넣습니다. 마이크로서비스 구조에서는 디버깅 투자 대비 효과가 제일 크거든요. 모든 알림에 런북을 붙여서 새벽 3시의 내가 뭘 확인해야 할지 알 수 있게 하고, 분기마다 리뷰 일정을 잡아 묵은 알림을 지우고 어긋난 임계값을 고치고 대시보드가 현재 아키텍처와 맞는지 확인합니다.
팀들을 자주 건져내는 함정들도 적어둡니다. 도구 과잉(연동되는 3개가 연동 안 되는 6개보다 낫습니다), 베이스라인 없는 그래프(500 rps가 평소 수준인가요, 10배 스파이크인가요?), 사용자와 무관한 것 모니터링(스테이트리스 컨테이너의 디스크 I/O 같은 것), 그리고 모니터링 자체의 이중화 부재. 인시던트 도중에 알림 시스템이 죽으면, 가장 잘 보여야 할 순간에 아무것도 안 보이게 됩니다.
이 중 어느 것도 최고급 도구를 요구하지 않습니다. 필요한 건 개발자가 필요한 정보를, 실제로 보는 곳에서, 빠르게 얻는 것뿐입니다.