로그 확인과 모니터링 도구
Chapter 6. 회사 시스템 파악
"에러가 났는데... 로그를 어디서 봐야 하지?"
배포가 끝났다. 선배가 "이제 모니터링하면서 지켜봐야 해"라고 말한다. 그런데 뭘 어떻게 지켜보는 건지 모르겠다.
화면에는 알 수 없는 그래프들이 실시간으로 움직이고 있다. 선배는 능숙하게 여러 개의 대시보드를 오가며 "음, 지금 에러율 정상이고, 응답 시간도 괜찮네" 중얼거린다.
'저 그래프가 뭘 의미하는 거지? 에러가 나면 어떻게 알 수 있는 거야? 저 숫자들은 뭐지?'
Slack에서 갑자기 알람이 울린다. "#alert-production"이라는 채널이다. 빨간색 메시지가 올라온다.
[CRITICAL] API 응답 시간 3초 초과 Server: api-server-3 Timestamp: 2026-02-05 14:23:15
팀원들이 재빠르게 반응한다. 누군가는 "로그 확인 중"이라고 쓰고, 누군가는 대시보드 링크를 올린다. 나는 그저 지켜볼 뿐이다.
'나도 저렇게 할 수 있을까? 에러가 났을 때 뭘 봐야 하는 거지?'
걱정하지 마라. 로그와 모니터링은 처음에는 복잡해 보이지만, 기본만 알면 생각보다 어렵지 않다. 여기서는 로그를 어디서 확인하는지, 모니터링 도구는 어떻게 사용하는지, 그리고 알람이 왔을 때 어떻게 대응하는지 정리했다.
로그가 뭔가?
로그(Log)란 애플리케이션이 실행되면서 남기는 기록이다.
쉽게 말하면, 프로그램의 일기장이다. "누가 언제 로그인했다", "어떤 에러가 발생했다", "이 API 호출에 몇 초 걸렸다" 같은 정보들이 시간 순서대로 기록된다.
왜 로그가 중요할까?
로그 없이 개발하는 건 눈을 감고 운전하는 것과 같다.
예를 들어, 사용자가 "로그인이 안 돼요"라고 신고했다고 해보자. 로그가 없다면 우리는 아무것도 알 수 없다. "왜 안 될까?" 추측만 할 뿐이다. 하지만 로그를 보면 정확히 알 수 있다. "14시 23분에 이 사용자가 로그인 시도했고, 비밀번호가 틀려서 실패했다" 또는 "DB 연결이 끊어져서 실패했다" 같은 구체적인 원인을 찾을 수 있다.
특히 에러가 발생했을 때, 로그는 가장 중요한 단서다. 스택 트레이스, 에러 메시지, 발생 시간, 관련된 요청 ID 등이 모두 로그에 기록되어 있다.
로그 저장 위치
로그는 어디에 저장될까? 회사마다 다르지만, 크게 세 가지 패턴이 있다.
1. 서버에 직접 저장
가장 전통적인 방식. 애플리케이션이 실행되는 서버의 특정 디렉토리에 로그 파일이 저장된다.
일반적인 로그 파일 위치:
/var/log/application.log
/home/app/logs/app.log
/opt/app/logs/error.log
장점:
추가 도구 없이 바로 확인 가능
명령어만 알면 빠르게 검색 가능
단점:
서버가 여러 대면 각각 접속해서 확인해야 함
로그 파일이 커지면 검색이 느려짐
서버가 다운되면 로그도 못 봄
이렇게 서버에 직접 저장하는 회사라면 로그를 보기 위해 매번 서버에 SSH로 접속해야 한다. 처음에는 명령어가 익숙하지 않다면 타이핑한 걸 메모장에 적어두자. 명령어로 하나 하나 타이핑 하면서 확인하는데 처음에는 며칠이 걸렸다. 하지만 익숙해지니 오히려 편했다. 직접 서버에 들어가서 로그를 보면 시스템을 더 깊이 이해하게 된다.
2. CloudWatch (AWS 환경)
AWS에서 애플리케이션을 운영하는 경우, CloudWatch를 많이 사용한다. 애플리케이션 로그가 자동으로 CloudWatch로 전송된다.
CloudWatch 확인 방법:
AWS Console 접속
CloudWatch → Logs → Log groups 선택
해당 애플리케이션의 Log group 클릭
로그 스트림 선택해서 확인
특징:
로그를 시간대별로 검색 가능
여러 서버의 로그를 한 곳에서 확인
특정 키워드에 대한 알람 설정 가능
이전 회사에서 CloudWatch를 처음 접했을 때가 생각난다. 동료 개발자가 "로그 보려면 AWS 콘솔 들어가서 CloudWatch 가면 돼" 라고 알려줬다. 그런데 막상 들어가니 Log groups가 수십 개였다. '/aws/lambda/...', '/ecs/...', '/api-server/...' 뭐가 뭔지 하나도 모르겠더라. 결국 동료 개발자에게 다시 물어봤다. "우리 서비스 로그는 어느 그룹이에요?" 동료가 "/api-server/production" 이거 보면 된다고 알려줬고, 북마크해뒀다. 그리고 Filter 기능을 알려줬는데, 이게 정말 유용했다. 특정 사용자 ID로 검색하거나, 에러 메시지로 검색할 때 Filter 한 줄이면 바로 찾을 수 있었다. 다만 로그가 많은 날에는 검색이 좀 느려서, 시간 범위를 좁혀서 검색하는 게 요령이었다.
3. ELK Stack (Elasticsearch, Logstash, Kibana)
대규모 서비스에서 많이 사용하는 로그 관리 시스템이다.
구성 요소:
Elasticsearch: 로그를 저장하고 검색하는 데이터베이스
Logstash: 로그를 수집하고 처리하는 도구
Kibana: 로그를 시각화하고 검색하는 웹 인터페이스
Kibana 사용 방법:
브라우저에서 Kibana URL 접속
Discover 메뉴에서 로그 검색
시간 범위 설정
검색 쿼리 입력 (예: level:ERROR, service:api-server)
장점:
강력한 검색 기능 (Elasticsearch의 전문 검색)
여러 서버의 로그를 통합 관리
시각화 대시보드 구성 가능
실시간 로그 스트리밍
단점:
초기 설정이 복잡
리소스 소비가 큼
처음엔 Kibana 인터페이스가 너무 복잡해 보였다. 왼쪽에는 메뉴가 잔뜩 있고, 검색 쿼리 문법도 처음 보는 거였다. 옆자리 개발자에게 물어보니 "일단 Discover 메뉴만 알면 돼요. 여기서 시간 설정하고, 저 검색창에 키워드 넣어서 사용해보세요"라고 알려줬다. 그렇게 하나씩 익히니 나중엔 ELK 없이는 못 살 정도로 편해졌다. 특히 여러 서버의 로그를 한 번에 검색할 수 있다는 게 정말 강력하다.
4. 기타 로그 관리 도구
Splunk: 대기업에서 많이 사용. 강력하지만 비용이 높음.
Datadog Logs: Datadog의 로그 관리 기능. 모니터링과 로그를 한 곳에서.
Sumo Logic: 클라우드 기반 로그 관리 서비스.
실전 팁
회사가 어떤 도구를 쓰든, 가장 중요한 건 "로그가 어디 있는지 아는 것"이다. 입사 첫 주에 "로그는 어디서 확인하나요?"라고 물어보고, 실제로 한 번 접속해보자. 그리고 간단한 검색 (예: "ERROR" 검색)을 해보면서 익숙해지자.
모니터링 대시보드
로그는 문제가 생긴 후에 원인을 찾는 도구다. 반면 모니터링은 문제가 생기기 전에 미리 감지하는 도구다.
모니터링이 중요한 이유
만약 서비스의 응답 시간이 점점 느려지고 있다면? 로그만 봐서는 알기 어렵다. 하지만 모니터링 대시보드를 보면 한눈에 알 수 있다. "아, 지난 1시간 동안 응답 시간이 1초에서 3초로 증가했네. 이건 문제가 생기려는 징조야." 모니터링은 시스템의 건강 상태를 실시간으로 보여주는 계기판이다.
Grafana
오픈소스 모니터링 대시보드 도구. 많은 스타트업과 중소기업에서 사용한다.
주요 기능:
CPU, 메모리, 디스크 사용률 시각화
API 응답 시간 그래프
에러율 추이
커스텀 대시보드 구성 가능
Grafana 대시보드 보는 법:
브라우저에서 Grafana URL 접속
왼쪽 메뉴에서 Dashboards 선택
관심 있는 대시보드 클릭 (예: "Production API", "Database Metrics")
시간 범위 설정 (우측 상단)
각 패널의 그래프 확인
주요 메트릭:
Request Rate: 초당 요청 수 (RPS)
Response Time: 응답 시간 (ms)
Error Rate: 에러 발생률 (%)
CPU/Memory Usage: CPU 및 메모리 사용률
실전 팁: Grafana 대시보드를 처음 보면 그래프가 너무 많아서 뭘 봐야 할지 모르겠다. 일단 이 세 가지만 보자:
에러율이 평소보다 높은가?
응답 시간이 평소보다 느린가?
CPU/메모리 사용률이 80% 이상인가?
처음 Grafana 대시보드를 열었을 때가 생각난다. 화면 가득 그래프 20개. 꺾은선, 막대, 숫자만 보이는 패널들. '뭘 봐야 하지?'
옆자리 개발자가 말했다. "배포 후에는 여기 보면서 모니터링하면 돼."
솔직하게 물어봤다. "이 그래프들 다 뭐예요?"
동료가 웃으면서 알려줬다. "처음엔 다 그래. 세 개만 봐."
Error Rate, Response Time, CPU Usage.
"이것만 확인해. 에러율 튀거나, 응답시간 느려지거나, CPU 높으면 문제야."
그날부터 배포할 때마다 이 세 개만 봤다.
한 달쯤 지나니 패턴이 보였다. 평소 에러율 0.5%인데 갑자기 3%면 문제구나. 응답시간 보통 200ms인데 갑자기 2초면 뭔가 느린 거구나. 복잡한건 그렇게 하나씩 하나씩 익혀가면 되는거다.
DataDog
클라우드 기반 모니터링 서비스. 대기업과 스케일이 큰 스타트업에서 많이 사용한다.
주요 기능:
APM (Application Performance Monitoring)
로그 관리
인프라 모니터링
알람 설정
분산 추적 (Distributed Tracing)
DataDog 대시보드:
각 서비스별 응답 시간, 에러율을 한눈에 확인
특정 API 엔드포인트의 성능 추적
느린 쿼리 찾기
서버 리소스 모니터링
최근 회사에서 DataDog을 처음 써봤는데, 정말 강력했다. 특히 APM 기능이 인상적이었다. 어떤 API가 느린지, 그 API 안에서 어떤 DB 쿼리가 시간을 많이 잡아먹는지 한눈에 보였다. 한번은 특정 페이지가 느리다는 피드백이 왔는데, DataDog APM으로 확인해서 문제를 해결했다. 그래 로그만 잘봐도 다 해결 가능하겠구나라고 생각했다.
기타 모니터링 도구
New Relic: APM 특화 도구. 애플리케이션 성능 모니터링에 강점.
Prometheus: 오픈소스 모니터링 시스템. Kubernetes 환경에서 많이 사용.
Sentry: 에러 추적 전문 도구. 프론트엔드 에러 모니터링에 강력.
실전 팁
모니터링 도구는 회사마다 다르지만, 보는 지표는 비슷하다. 에러율, 응답 시간, 리소스 사용률. 이 세 가지만 기억하자.
체크리스트: 로그와 모니터링 파악 완료
입사 첫 주~2주에 다음 항목들을 확인했는지 체크하자.
로그 확인
로그는 어디에 저장되는가? (서버, CloudWatch, ELK 등)
로그 확인 방법을 알고 있는가? (URL, 명령어)
에러 로그를 검색하는 방법을 알고 있는가?
특정 시간대 로그를 찾는 방법을 알고 있는가?
모니터링 대시보드
모니터링 도구는 무엇인가? (Grafana, DataDog, New Relic 등)
대시보드 URL을 알고 있는가?
주요 메트릭이 무엇인지 알고 있는가?
정상 범위를 알고 있는가? (예: 에러율 1% 미만)
외계어가 이제 보인다.
처음에는 복잡해 보였던 그래프들, 알 수 없었던 숫자들. 이제 조금 의미가 보이기 시작했을 것이다.
로그는 과거를 알려주고, 모니터링은 현재를 보여준다. 이 두 가지가 있으면 시스템에서 무슨 일이 일어나는지 알 수 있다. 그리고 문제가 생겼을 때 빠르게 대응할 수 있다.
물론 처음 몇 주는 여전히 낯설 것이다. 대시보드를 열어도 무슨 의미인지 모르는 그래프가 대부분일 것이다. 괜찮다. 매일 조금씩 보다 보면 익숙해진다. 선배가 "저기 에러율 좀 봐"라고 할 때마다 따라서 보다 보면, 어느새 혼자서도 볼 수 있게 된다.
로그와 모니터링을 파악했다. 복잡한 외계어 글자가 하나 둘 보이듯 그렇게 복잡한 것들도 익숙해져가면 된다.