작은 서비스에서 로그 다음으로 필요한 것은 상태를 보는 화면입니다

서비스를 만들다 보면 로그를 먼저 생각하게 됩니다. 문제가 생겼을 때 원인을 찾아야 하고, 어떤 요청에서 실패했는지 확인해야 하기 때문입니다. 저도 닷넷 프로젝트를 만들 때 Serilog 같은 구조화 로깅 도구를 자주 떠올립니다.

하지만 로그를 남기기 시작하면 곧 다른 질문이 생깁니다. 로그는 문제가 생긴 뒤에 뒤져보는 기록에 가깝습니다. 그렇다면 지금 서비스가 어떤 상태인지, 오늘 어떤 일이 있었는지, 사용자가 실제로 어떤 흐름을 지나고 있는지는 어디에서 봐야 할까요.

이 지점에서 작은 대시보드나 상태 확인 화면이 필요해집니다. 거창한 분석 시스템이 아니라, 운영자가 매일 한 번쯤 열어보고 서비스의 현재 상태를 감각할 수 있는 화면입니다. 혼자 운영하는 서비스일수록 이런 화면이 생각보다 중요합니다.

로그는 자세하지만 한눈에 보이지 않습니다
로그는 운영에 꼭 필요합니다. 요청 경로, 예외 메시지, 사용자 식별자, 처리 시간 같은 정보는 문제가 생겼을 때 큰 도움이 됩니다. 구조화된 로그를 잘 남겨두면 특정 사용자나 특정 기능을 기준으로 상황을 좁혀볼 수도 있습니다.

하지만 로그는 기본적으로 자세한 기록입니다. 한 줄 한 줄을 따라가며 맥락을 찾아야 합니다. 어떤 문제를 이미 알고 있을 때는 로그가 강력하지만, 아직 무엇을 봐야 할지 모르는 상태에서는 오히려 부담스럽습니다.

예를 들어 어제보다 오류가 늘었는지, 특정 작업이 계속 실패하고 있는지, 사용자가 생성한 데이터가 정상적으로 쌓이고 있는지 알고 싶을 때가 있습니다. 이때 모든 로그를 검색해서 판단하는 것은 번거롭습니다. 운영자가 먼저 봐야 할 신호는 조금 더 압축된 형태로 보여야 합니다.

상태 화면은 이 역할을 합니다. 로그가 현미경이라면, 상태 화면은 작은 지도에 가깝습니다. 지금 어디를 봐야 하는지 알려주는 첫 화면입니다.

작은 서비스에도 관찰 가능한 지점이 필요합니다
관찰 가능성이라는 말을 쓰면 조금 거창하게 들립니다. 대규모 시스템, 분산 추적, 메트릭 수집, 알림 체계 같은 것들이 먼저 떠오르기 때문입니다. 하지만 작은 서비스에서도 관찰 가능한 지점은 필요합니다.

사용자 수가 많지 않아도 작업은 실패할 수 있습니다. 배치 작업이 멈출 수도 있고, 외부 API 호출이 실패할 수도 있고, 특정 데이터가 예상과 다르게 쌓일 수도 있습니다. 혼자 운영하는 서비스에서는 이런 문제를 누가 대신 알려주지 않습니다.

그래서 처음부터 완성된 모니터링 시스템을 만들 필요는 없지만, 최소한 자주 확인해야 할 상태는 화면으로 꺼내두는 편이 좋습니다. 오늘 생성된 항목 수, 실패한 작업 수, 최근 오류, 대기 중인 작업, 오래 처리되지 않은 요청 같은 정보만 있어도 운영 감각이 달라집니다.

이 화면은 예쁜 차트가 아니어도 됩니다. 숫자 몇 개와 목록 몇 개로 시작해도 충분합니다. 중요한 것은 운영자가 지금 서비스를 확인할 수 있는 입구가 있다는 점입니다.

대시보드는 의사결정을 위한 화면이어야 합니다
대시보드를 만들 때 조심해야 할 부분도 있습니다. 보기 좋은 숫자를 많이 모아놓는다고 해서 좋은 운영 화면이 되는 것은 아닙니다. 오히려 너무 많은 숫자는 중요한 신호를 가리기도 합니다.

혼자 운영하는 서비스에서 대시보드는 의사결정과 연결되어야 합니다. 이 숫자를 보고 제가 무엇을 할 수 있는지 생각해야 합니다. 실패한 작업 수가 보인다면 다시 실행하거나 원인을 확인할 수 있어야 합니다. 미처리 문의가 보인다면 바로 상세 화면으로 들어갈 수 있어야 합니다. 최근 오류가 보인다면 로그로 이어질 수 있어야 합니다.

즉, 대시보드는 단순한 통계판이 아니라 작업의 출발점이어야 합니다. 숫자를 보고 끝나는 화면보다, 숫자를 보고 다음 행동으로 넘어갈 수 있는 화면이 운영에는 더 도움이 됩니다.

저는 이 기준이 특히 1인 서비스에 중요하다고 느낍니다. 시간이 넉넉하지 않기 때문에, 화면을 열었을 때 바로 확인하고 바로 처리할 수 있어야 합니다. 보는 화면과 일하는 화면이 너무 멀리 떨어져 있으면 결국 다시 사용하지 않게 됩니다.

로그와 상태 화면은 서로 이어져야 합니다
로그와 대시보드는 서로 다른 역할을 하지만, 따로 떨어져 있으면 힘이 줄어듭니다. 상태 화면에서 이상한 신호를 발견하면 로그로 내려갈 수 있어야 합니다. 반대로 로그에서 반복되는 오류를 발견했다면, 다음에는 그 오류를 상태 화면에서 빨리 볼 수 있도록 정리할 수 있어야 합니다.

예를 들어 최근 24시간 동안 실패한 작업 수를 대시보드에 보여준다고 가정해보겠습니다. 숫자만 보여주면 아쉬움이 남습니다. 클릭했을 때 실패한 작업 목록으로 들어가고, 각 항목에서 관련 로그나 오류 메시지를 볼 수 있으면 훨씬 실용적입니다.

또한 로그에 남긴 요청 ID나 작업 ID를 상태 화면에서도 함께 보여주면 문제를 추적하기 쉬워집니다. 로그를 잘 남기는 것과 운영 화면을 잘 만드는 일은 결국 같은 방향을 향합니다. 나중에 원인을 찾을 수 있게 맥락을 남기는 일입니다.

이런 연결은 처음부터 완벽할 필요가 없습니다. 중요한 작업부터 하나씩 이어두면 됩니다. 실패한 생성 작업, 결제 실패, 외부 API 오류, 오래 걸리는 요청처럼 운영자가 실제로 불안해하는 지점부터 화면으로 꺼내면 됩니다.

닷넷에서는 작은 상태 API부터 시작할 수 있습니다
닷넷 기반 서비스라면 처음부터 복잡한 대시보드 시스템을 붙이지 않아도 됩니다. ASP.NET Core에서 간단한 관리자용 API를 만들고, 필요한 상태 데이터를 모아 내려주는 것만으로도 시작할 수 있습니다.

예를 들어 /api/admin/status 같은 엔드포인트에서 오늘의 가입자 수, 최근 오류 수, 실패한 작업 수, 대기 중인 작업 수를 내려줄 수 있습니다. React 화면에서는 이 데이터를 TanStack Query로 가져와 카드나 목록으로 보여주면 됩니다.

이때 중요한 것은 데이터의 기준입니다. 오늘이라는 범위를 어느 시간대로 볼 것인지, 실패 상태는 어떤 값을 기준으로 볼 것인지, 운영자가 직접 처리해야 하는 항목과 자동 재시도될 항목을 어떻게 구분할 것인지 정해야 합니다.

결국 상태 화면을 만든다는 것은 단순히 SQL을 몇 개 작성하는 일이 아닙니다. 서비스의 현재 상태를 어떤 언어로 설명할지 정하는 일에 가깝습니다. 이 기준이 생기면 운영이 조금 더 차분해집니다.

처음에 볼 만한 항목들
작은 서비스에서 처음 대시보드에 올릴 만한 항목은 많지 않아도 됩니다. 오히려 적은 편이 좋습니다. 제가 먼저 생각하는 항목은 다음과 같습니다.

최근 24시간 동안 생성된 주요 데이터 수
최근 24시간 동안 발생한 오류 수
실패 상태로 남아 있는 작업 목록
처리 대기 중인 요청이나 문의 수
최근 배포 이후 발생한 주요 예외
이 정도만 있어도 매일 서비스를 확인하는 기준이 생깁니다. 사용자가 많지 않은 단계에서는 숫자가 작을 수 있습니다. 그래도 괜찮습니다. 중요한 것은 숫자의 크기가 아니라 흐름을 보는 습관입니다.

나중에 필요해지면 응답 시간, 외부 API 실패율, 결제 전환, 기능별 사용량 같은 항목을 추가할 수 있습니다. 처음부터 모든 것을 넣으려 하면 화면이 무거워지고, 운영자가 실제로 보지 않는 정보가 늘어납니다.

상태 화면은 불안을 줄이기 위한 도구입니다
혼자 서비스를 만들고 운영하다 보면 작은 불안이 계속 생깁니다. 사용자가 작업하다가 막히지는 않았을까, 어제 배포한 기능이 제대로 동작하고 있을까, 백그라운드 작업이 멈춰 있지는 않을까 하는 생각입니다.

상태 화면은 이 불안을 완전히 없애주지는 않습니다. 하지만 불안을 확인 가능한 항목으로 바꿔줍니다. 막연히 걱정하는 대신 오늘의 실패 목록을 보고, 최근 오류를 확인하고, 필요한 작업을 처리할 수 있게 해줍니다.

이 점에서 상태 화면은 운영자의 정신적인 부담을 줄이는 도구이기도 합니다. 문제가 생겼을 때 어디를 봐야 하는지 알고 있으면, 서비스 운영이 조금 덜 막막해집니다.

마무리
로그는 서비스 운영의 중요한 기록입니다. 하지만 로그만으로는 지금 서비스가 어떤 상태인지 한눈에 보기 어렵습니다. 작은 서비스에서도 현재 상태를 압축해서 보여주는 화면이 필요합니다.

대시보드는 처음부터 거창할 필요가 없습니다. 오늘의 주요 숫자, 실패한 작업, 최근 오류, 처리해야 할 항목 정도로 시작해도 충분합니다. 중요한 것은 그 화면이 다음 행동으로 이어지는가입니다.

저는 요즘 작은 서비스를 만들 때 로그 다음에는 상태 화면을 생각하게 됩니다. 기록을 남기는 것에서 한 걸음 더 나아가, 그 기록을 운영자가 볼 수 있는 형태로 정리하는 일입니다. 아직 완성된 기준은 아니지만, 혼자 오래 운영할 수 있는 서비스를 만들기 위해 계속 다듬어가야 할 부분이라고 느낍니다.