스프링 부트 애플리케이션을 운영하다 보면, 규모와 무관하게 최소한의 운영 가시성은 반드시 필요하다. 애플리케이션이 정상적으로 응답하는지, 에러가 늘고 있지는 않은지, 언제 재시작됐는지를 아는 것은 서비스 신뢰성의 기본이다. 문제는 이런 질문에 답하기 위해 곧바로 프로메테우스(Prometheus)와 그라파나(Grafana) 조합을 떠올리는 관성이다. 대형 관측 플랫폼은 강력하지만, VPS 한 대에 서비스 한둘을 올려 운영하는 상황에서는 도입과 유지 비용이 얻는 것에 비해 과하다. StatLite는 바로 이 지점, 즉 '풀 스택 모니터링까지는 필요 없지만 JSON 엔드포인트를 매번 열어보기는 번거로운' 중간지대를 겨냥한 도구다.
액추에이터가 이미 절반을 해결한다
스프링 부트를 쓰는 개발자라면 액추에이터(Actuator)는 익숙할 것이다. 헬스 체크와 마이크로미터(Micrometer) 기반 메트릭 엔드포인트를 통해 애플리케이션 상태와 각종 수치를 이미 노출하고 있기 때문이다. 이 데이터는 다른 시스템과 연동하기에는 훌륭하지만, 사람이 매일 눈으로 확인하는 대시보드로서는 불편하다. 헬스 상태를 보려고 JSON 응답을 열어보고, 요청 수와 지연 시간을 확인하려고 또 다른 엔드포인트를 여는 식의 반복은 일상적인 운영 점검에 적합하지 않다.
StatLite는 이 액추에이터 데이터를 그대로 읽어들여 헬스, 요청 수, 에러, 지연 시간, 메모리, 가동 시간, 재시작 횟수 같은 실무에서 가장 자주 들여다보는 신호만 추려 대시보드로 보여준다. 구조적으로도 가볍다. 하나의 Go 바이너리로 실행되고, 이력 데이터는 SQLite 파일에 저장한다. 별도의 데이터베이스 서버나 여러 컴포넌트를 세우고 관리할 필요가 없다는 뜻이며, 이는 리소스가 빠듯한 소형 VPS 환경에서 특히 의미가 크다.
설정과 동작 방식
도입 절차 자체는 단순하다. 먼저 애플리케이션 설정에서 필요한 액추에이터 엔드포인트를 노출하도록 열어준다. StatLite는 이 노출 단계를 대신 처리해 주지 않는, 의도적으로 '액추에이터 우선(Actuator-first)' 방식을 취한다. 다시 말해 액추에이터를 활성화하고 노출하는 책임은 여전히 사용자에게 있다. 이때 보안 측면을 반드시 함께 고려해야 한다. 액추에이터는 신뢰할 수 있는 네트워크에서만 접근 가능하도록 제한하고, 배포 환경이 요구한다면 인증을 추가하는 것이 원칙이다.
StatLite 자체의 핵심 설정은 세 가지로 요약된다. listen은 대시보드가 어느 주소에서 수신할지를 정하며 기본값은 로컬 전용이다. sqlite_path는 대시보드 이력을 담을 파일 경로이고, actuator_base_url은 모니터링 대상 애플리케이션의 액추에이터 기본 URL을 가리킨다. 설치는 릴리스 인스톨러나 Homebrew를 이용할 수 있고, 소스에서 직접 빌드하려는 사람은 저장소를 클론해 바이너리를 만들면 된다. Basic 인증, 다중 대상 지정, 데이터 보존(retention), 프로덕션 보안 같은 세부 항목은 별도 설정 문서에서 다룬다.
동작 방식에서 한 가지 유념할 점은 폴링(polling) 기반이라는 것이다. StatLite는 설정된 주기마다 액추에이터를 조회하므로, 트래픽을 발생시키거나 애플리케이션을 재시작한 직후에는 다음 폴링이 돌아올 때까지 기다려야 화면에 반영된다. 저장소에 포함된 스프링 액추에이터 데모를 함께 실행하면, 성공 요청과 데이터베이스 요청, 느린 요청은 물론 400·404·500 응답까지 만들어내는 트래픽 스크립트로 요청·에러 차트가 실제로 어떻게 움직이는지 확인할 수 있다.
어디까지 쓰고, 어디서 멈춰야 하나
StatLite의 가치는 그 한계를 명확히 아는 데서 나온다. 개발사 스스로도 이 도구가 엔터프라이즈급 관측 시스템의 대체재가 아니라고 분명히 한다. 다수의 서비스와 호스트를 다뤄야 하거나, 긴 데이터 보존이 필요하거나, 유연한 메트릭 쿼리·알림 라우팅·분산 추적·중앙 집중식 로그·조직 전체가 공유하는 대시보드가 요구되는 상황이라면 여전히 프로메테우스와 그라파나 같은 본격적인 플랫폼이 정답이다. StatLite가 잘하는 일은 어디까지나 'VPS 한 대 위의 스프링 부트 서비스 몇 개를 풀 스택 없이 들여다보는 것'에 한정된다.
실무적으로 흥미로운 점은 이 둘이 배타적 선택이 아니라는 사실이다. 지금 초점이 좁은 대시보드가 필요해 StatLite를 택했다고 해서, 요구사항이 커졌을 때 프로메테우스와 그라파나를 나중에 도입하지 못하게 되는 것은 아니다. 두 접근은 공존할 수 있다. 결국 판단의 기준은 도구의 화려함이 아니라 지금 해결해야 할 운영상의 과제 크기다. 사이드 프로젝트나 소규모 서비스를 운영하는 개발자라면, 무거운 스택을 세우기 전에 이미 가지고 있는 액추에이터 데이터를 가볍게 시각화하는 선택지를 먼저 저울질해 볼 만하다.