[Observability 1/5] Monitoring·APM·Observability, 무엇이 다를까?
이 글에서 다룰 주제
- 관찰할 대상: 검색 버튼을 누른 뒤에는 어떤 일이 일어날까?
- 세 가지 관점: Monitoring·APM·Observability는 같은 문제를 어떻게 볼까?
- 근거로 조사하기: 느린 구간을 찾은 것과 원인을 밝힌 것은 어떻게 다를까?
주요 단어 · Monitoring · APM · Observability · Telemetry · Instrumentation
웹 요청과 응답을 들어본 독자를 위한 입문 글이다. 읽고 나면 “검색이 느리다”는 문제에서 이미 아는 사실과 추가로 수집해야 할 정보를 나눌 수 있다. 도구 설치 경험은 필요하지 않다.
1. 출발점: 서버는 정상인데 검색은 왜 느릴까?
검색 버튼을 눌렀다. 잠시 기다린 뒤 결과가 나온다. 서버는 켜져 있고 오류 화면도 없다. 그렇다면 서비스는 정상일까?
가상의 demo-api를 생각해 보자. 브라우저가 GET /search 요청을 보내면 API가 검색 저장소를 조회하고 결과를 돌려준다. API는 여기서 검색 결과를 요청할 수 있는 서버의 창구, 저장소는 검색에 필요한 데이터를 찾아주는 구성요소다.
그림 1. 이 시리즈가 따라갈 가상의 검색 서비스. 실제 회사나 프로젝트 구성도가 아닌 설명용 개념도다.
그림의 요청 경로를 따라 읽어 보자. 브라우저에서 시작한 작업은 API와 저장소를 거친다. 사용자가 기다린 시간에는 서버 처리뿐 아니라 네트워크 이동과 브라우저의 화면 그리기도 영향을 줄 수 있다. 한 구성요소가 살아 있다는 사실만으로 전체 경험을 설명할 수는 없다.
설명을 위해 2026-10-04 10:00~10:05 KST에 API 요청 100건을 관찰했다고 가정하자. 이 시리즈의 수치와 로그는 직접 만든 학습용 데이터이며 실측 결과가 아니다.
| 관찰한 항목 | 가상 결과 | 알 수 있는 것 |
|---|---|---|
| HTTP 상태 코드 | 100건 모두 200 | 서버가 정상 응답 코드로 답했다 |
| 요청 처리시간 | 90건은 100ms, 10건은 2,000ms | 일부 요청이 다른 요청보다 오래 걸렸다 |
| 5xx 응답 비율 | 0 / 100 = 0% | 이 표본에는 서버 오류 응답이 없었다 |
ms는 밀리초이며 1,000ms가 1초다. HTTP 200은 응답의 상태 코드다. 결과의 내용이 정확한지, 충분히 빠른지는 별도로 확인해야 한다.
따라서 “오류율 0%”와 “모든 사용자가 빠르게 검색했다”는 다른 말이다. 이제 같은 상황에 세 가지 질문을 붙여 보자.
2. Monitoring: 정해 둔 상태와 변화를 계속 확인하기
Monitoring(모니터링)은 관찰할 항목과 기준을 정하고, 그 상태와 변화를 지속적으로 확인하는 활동이다.
검색 API를 모니터링한다면 적어도 다음을 구분해 볼 수 있다.
- 양: 요청이 얼마나 들어오는가?
- 실패: 무엇을 실패로 정했고, 얼마나 발생하는가?
- 시간: 응답이 얼마나 걸리는가? 일부 요청만 느리지는 않은가?
가상 표본에서는 HTTP 오류율만 봤다면 2초 걸린 10건을 놓쳤을 것이다. 지연시간 분포도 함께 봐야 한다. 평균은 290ms인데 느린 쪽을 보는 p95는 2,000ms다. p95의 계산과 해석은 2편에서 직접 계산한다.
2.1 알림에는 측정 기준이 숨어 있다
“오류율이 2%를 넘으면 알린다”는 문장만으로는 규칙이 완성되지 않는다. 예를 들어 다음처럼 범위를 정해야 한다.
최근 5분 동안
demo-api의/search요청 중 HTTP 5xx 응답 수를 전체 완료 요청 수로 나눈 비율이 2%를 넘었는가?
이때 4xx를 포함할지, 연결 실패를 어디서 셀지, 요청이 한 건도 없으면 어떻게 처리할지는 별도의 선택이다. 1건 중 1건 실패와 1만 건 중 1만 건 실패는 같은 100%지만 영향과 통계적 근거가 다르다.
대시보드에 그래프가 많다는 것보다, 숫자의 대상·시간창·단위·분모를 설명할 수 있는지가 중요하다. 모니터링은 숫자 그래프에만 한정되지 않는다. 로그를 감시하거나 외부에서 주기적으로 접속해 상태를 확인하는 방법도 있다.
3. APM: 애플리케이션이 시간을 어디에 썼는지 보기
APM(Application Performance Monitoring/Management)은 애플리케이션의 성능과 가용성을 관찰하고 개선하는 영역이다. 제품마다 포함하는 기능 범위는 다르다.
앞에서는 “느린 요청이 있다”는 것을 발견했다. 이번에는 “그 요청은 어느 작업에서 시간을 썼는가?”를 묻는다.
그림 2. 그림 1의 배치를 유지하고, 이번에 살펴볼 애플리케이션 구간을 강조했다. 강조색은 장애 확정 표시가 아니다.
2초 걸린 요청 하나를 계측했더니 다음과 같은 기록을 얻었다고 하자. 세 작업이 겹치지 않고 순서대로 실행되는 가정이다.
| 작업 | 경과시간 |
|---|---|
| 입력 검사 | 20ms |
| 검색 저장소 호출 | 1,800ms |
| 응답 생성 | 180ms |
| API 전체 | 2,000ms |
저장소 호출 구간이 전체의 90%를 차지한다. 그렇다면 첫 조사 대상은 저장소 호출과 관련된 구간이다. 서버 CPU 그래프만 볼 때보다 질문이 구체적이 됐다.
그런데 이것만으로 “저장소의 CPU가 느리다”고 결론 내릴 수는 없다. 1,800ms에는 연결을 기다린 시간, 네트워크 왕복, 상대 서비스의 대기와 실행 등이 들어 있을 수 있다. 이 기록은 조사할 구간을 좁힌 근거다.
요청을 이런 작업 구간으로 나누어 기록하는 대표적인 방법이 트레이싱이다. APM 제품은 트레이스 외에도 메트릭·로그·프로파일·브라우저 성능 데이터를 함께 사용할 수 있다. APM과 트레이싱을 같은 단어로 외울 필요는 없다.
4. Observability: 새로운 질문에 답할 근거가 남아 있는가?
Observability(관측성)는 시스템이 내보내는 데이터를 근거로 내부 상태와 동작을 이해할 수 있는 정도를 뜻한다.
시스템이 만든 측정값과 기록을 Telemetry(텔레메트리)라고 부른다. 이 데이터를 만들도록 코드나 실행 환경을 준비하는 작업은 Instrumentation(계측)이다. 예를 들어 요청의 시작·종료를 기록하고, 어떤 서비스의 어느 작업인지 함께 남기는 것이 계측이다. OpenTelemetry 개념 설명
관측성은 도구 개수보다 조사할 질문에 데이터로 답할 수 있는가와 연결된다. 같은 요청을 두 가지 방식으로 기록했다고 생각해 보자.
| 남겨 둔 기록 | 나중에 답할 수 있는 질문 |
|---|---|
| 전체 평균 처리시간만 저장 | 전체적으로 빨라졌는가, 느려졌는가? |
| 경로·버전별 지연과 요청의 호출 관계도 저장 | 어느 경로와 버전에서 느려졌고, 해당 요청은 어디를 거쳤는가? |
두 번째 방식은 더 구체적인 질문을 가능하게 한다. 하지만 모든 필드를 무제한으로 저장하라는 뜻은 아니다. 수집·저장 비용과 민감한 데이터 포함 가능성도 늘어난다. 개별 요청 ID를 메트릭 라벨로 무작정 붙이는 문제는 다음 편에서 다룬다.
4.1 관찰 → 가설 → 확인을 구분하기
그림 3. 조사 과정의 개념도. 근거가 부족하면 이전 질문으로 돌아가거나 계측을 보완한다.
우리 예제에 이 과정을 적용하면 다음과 같다.
- 관찰: 요청 100건 중 10건이 2초 걸렸다.
- 추가 관찰: 느린 요청 하나는 저장소 호출에 1.8초를 썼다.
- 가설: 특정 조건의 저장소 요청이 오래 걸리는 것은 아닐까?
- 확인: 빠른 요청과 느린 요청의 호출 조건·버전·동일 요청 로그를 비교한다. 필요하면 저장소 측 계측도 추가한다.
이 글의 가상 데이터만으로는 3번 가설을 확정하지 않는다. 예컨대 저장소가 요청을 받기 전 연결을 기다린 것이 원인일 수도 있다. 특정 시간대에 CPU와 지연이 함께 올랐다는 사실도 원인 확정과는 다르다.
관측 데이터가 없을 때도 구분이 필요하다. “오류 기록이 없다”가 “오류가 없었다”는 뜻인지는 수집기가 정상인지, 해당 요청이 샘플링에서 빠졌는지, 보존 기간이 지났는지에 따라 달라진다.
5. 세 용어의 관계: 발전 단계로 외우지 않기
| 용어 | 중심 질문 | 이 예제에서의 역할 |
|---|---|---|
| Monitoring | 상태가 기준에서 벗어났는가? | 지연과 오류율 변화를 지속적으로 확인 |
| APM | 애플리케이션의 어느 구간이 느린가? | API와 의존성 호출의 성능 조사 |
| Observability | 내부 동작을 설명할 근거가 충분한가? | 새로운 질문을 데이터로 좁혀 가기 |
이것은 제품을 세 칸으로 나눈 분류표가 아니다. 같은 지연 메트릭을 모니터링과 원인 조사에 모두 쓸 수 있고, APM 도구가 관측성을 높이는 데 기여할 수 있다.
“모니터링을 끝내면 APM으로, 그다음 관측성으로 진화한다”는 식으로 볼 필요는 없다. 활동, 관심 영역, 시스템을 이해하는 능력을 구분하기 위한 관점이다.
직접 판단해 보기
Q. HTTP 오류율이 0%라면 지연 알림은 필요 없을까?
A. 우리 표본에서도 모두 200이지만 10%가 2초 걸렸다. 실패와 지연은 서로 다른 질문이다.
Q. 저장소 호출에 1.8초가 걸렸다면 저장소 CPU가 원인일까?
A. 아직 모른다. 호출 구간 안의 연결 대기·네트워크·상대 처리 등을 구분할 근거가 더 필요하다.
다음 편에서는 이 근거를 메트릭·로그·트레이스·프로파일로 나누고, 실제로 어떤 값과 필드를 읽어야 하는지 살펴본다.
개정: 2026-10-04. OpenTelemetry의 관측성·계측 개념을 확인했다. 예제 서비스·숫자·조사 과정은 작성한 학습용 가정이며 실제 운영 경험이나 측정 결과가 아니다.
