[스프링] 서버 유목민을 위한 토이 프로젝트 로깅 전략: 파일 어펜더 vs 클라우드 로깅

토이 프로젝트, 로그 관리는 어떻게 하고 계신가요?

사이드 프로젝트나 토이 프로젝트를 진행하다 보면 가장 크게 와닿는 고민이 바로 서버 유지 비용입니다. 많은 분들이 무료 크레딧을 알뜰하게 사용하기 위해 AWS 프리티어와 GCP 무료 인스턴스를 번갈아 가며 사용하는 이른바 '서버 유목민' 생활을 하곤 합니다.

그런데 이렇게 서버 환경이 자주 바뀌거나 비용 절감을 위해 컨테이너를 수시로 띄웠다 내렸다 하는 환경에서, 애플리케이션의 에러를 추적할 로그(Log)는 어떻게 관리해야 할까요? 오늘은 비용과 효율성 사이에서 줄타기하는 소규모 프로젝트에 딱 맞는 로깅 전략에 대해 알아보겠습니다.

파일 어펜더(File Appender)의 치명적인 단점

흔히 처음 로깅을 세팅할 때 가장 먼저 떠올리는 방법은 파일 어펜더를 사용하여 서버 내부의 특정 폴더에 텍스트 파일 형태로 로그를 쌓는 것입니다. 설정이 매우 직관적이고 간단하다는 장점이 있지만, 클라우드를 옮겨 다니는 서버 유목민 환경에서는 여러 가지 치명적인 한계에 부딪히게 됩니다.

가장 큰 문제는 로그의 휘발성입니다. 비용 문제로 기존 서버를 삭제하고 새로운 클라우드 사업자로 이전하거나, 컨테이너를 새로 띄우게 되면 그 안에 쌓여있던 소중한 에러 로그들도 함께 증발해 버립니다. 문제가 발생했을 때 과거의 로그를 추적할 방법이 사라지는 셈입니다.

또한, 디스크 용량 관리도 골칫거리입니다. 프리티어 서버의 디스크 용량은 보통 20GB에서 30GB 남짓으로 매우 작습니다. 로그 로테이션(Log Rotation) 설정을 정교하게 해두지 않으면, 어느 순간 로그 파일이 디스크를 가득 채워 서버 전체가 멈추는 장애로 이어질 수 있습니다.

중앙 집중식 로깅(ELK), 토이 프로젝트엔 사치일까?

이러한 로컬 로그의 단점을 극복하기 위해 실무에서는 ELK(Elasticsearch, Logstash, Kibana) 스택 같은 중앙 집중식 로깅 시스템을 도입합니다. 로그를 별도의 외부 서버로 모아두기 때문에 서버가 삭제되어도 로그는 안전하게 보존됩니다.

하지만 소규모 토이 프로젝트에 ELK 스택을 도입하는 것은 배보다 배꼽이 더 커지는 상황을 초래합니다.

비교 항목	토이 프로젝트 메인 서버 (프리티어)	ELK 로깅 서버
목적	비즈니스 로직 처리	로그 수집, 저장, 검색
요구 스펙	1GB RAM 내외 (가벼움)	최소 4GB 이상 RAM 권장 (무거움)
비용	무료 크레딧으로 커버 가능	높은 사양 요구로 상당한 비용 발생

표에서 볼 수 있듯, 방대한 데이터를 인덱싱하고 검색하는 ELK 스택은 필연적으로 많은 메모리와 CPU 자원을 소모합니다. 1GB 남짓한 프리티어 환경에서는 구동조차 버겁고, 별도의 서버를 두자니 아껴둔 지갑이 열리게 됩니다.

현실적인 대안: 클라우드 관리형 로깅 시스템

결국 토이 프로젝트 환경에서는 인프라 관리 부담이 없고, 비용이 저렴하며, 서버가 삭제되어도 로그가 보존되는 환경이 필요합니다. 이에 대한 가장 현실적인 대안은 바로 클라우드 서비스 제공자가 기본적으로 지원하는 관리형 로깅 서비스(Managed Logging Service)를 활용하는 것입니다.

대표적으로 GCP의 Cloud Logging이나 AWS의 CloudWatch가 있습니다. 

애플리케이션에서 발생하는 로그를 로컬 파일에 쓰는 대신, Spring Boot의 Logback 어펜더를 통해 실시간으로 GCP Cloud Logging으로 쏘아 보내는 방식입니다. 이 아키텍처를 적용하면 다음과 같은 압도적인 이점을 얻을 수 있습니다.

첫째, 서버 인스턴스와 로그 데이터가 완벽하게 분리됩니다. AWS의 무료 기간이 끝나서 GCP로 서버를 옮기더라도, 로그는 이미 별도의 클라우드 공간에 안전하게 저장되어 있으므로 언제든 과거의 에러 기록을 조회할 수 있습니다. 둘째, 파격적인 무료 제공량입니다. GCP Cloud Logging은 프로젝트당 매월 50GB의 로그 수집을 무료로 제공합니다. 트래픽이 엄청나게 몰리는 상용 서비스가 아닌 이상, 소규모 토이 프로젝트에서는 사실상 평생 무료로 강력한 로그 검색 및 필터링 시스템을 누릴 수 있습니다.

클라우드를 옮길 때, 기존 로그 데이터는 어떻게 할까요?

무료 크레딧을 위해 AWS에서 GCP로, 혹은 반대로 서버를 옮기게 되면 새 클라우드의 로깅 서비스를 이용하게 됩니다. 이때 "기존에 쌓아둔 로그 데이터도 새 클라우드 로깅 시스템으로 다 옮겨야 하나? 호환은 잘 될까?"라는 의문이 생기실 수 있습니다.

결론부터 말씀드리면, 두 클라우드 간에 관리형 로깅 데이터를 직접 통째로 이관(마이그레이션)하는 것은 권장하지 않으며, 실무에서도 잘 쓰지 않는 방식입니다. AWS CloudWatch와 GCP Cloud Logging은 로그를 저장하는 내부 엔진과 메타데이터 형식이 완전히 달라서 서로 직접적인 호환이 어렵기 때문입니다. 이를 억지로 맞추려면 막대한 시간과 비용이 소모됩니다.

따라서 서버를 옮길 때 로그 데이터는 다음 두 가지 방법으로 처리하는 것이 가장 현실적이고 효율적입니다.

첫째, 투 트랙 유지 후 자연 소멸 (가장 추천하는 방법) 로그는 회원 정보 같은 영구 데이터가 아니라, 일정 시간이 지나면 가치가 떨어지는 시계열 데이터입니다. 따라서 기존 클라우드(예: AWS) 계정을 닫지 말고, 로그의 보존 주기(Retention)를 30일 정도로 설정해 둡니다. 한 달 동안은 과거 에러를 찾을 때 AWS를 보고, 새로운 에러는 GCP에서 봅니다. 30일이 지나면 기존 로그는 알아서 삭제되므로 아주 깔끔하게 정리가 완료됩니다.

둘째, 스토리지 파일(JSON) 백업 감사(Audit) 등의 이유로 과거 로그를 무조건 영구 보존해야 한다면, 기존 로깅 시스템에서 로그 데이터를 AWS S3나 GCP Cloud Storage 같은 '파일 저장소'로 추출(Export)합니다. 추출된 데이터는 범용적인 JSON이나 순수 텍스트 파일 형식이 되기 때문에 호환성 걱정이 전혀 없습니다. 언제든 다운로드하여 텍스트 에디터로 열어볼 수 있습니다.

마무리

토이 프로젝트라고 해서 무조건 로컬 파일에 로그를 방치하며 장애 추적을 포기할 필요는 없습니다. 인프라 비용을 철저하게 방어하면서도 실무 수준의 안정적인 로그 관리 환경을 구축하고 싶으시다면, 기존의 파일 어펜더 방식에서 벗어나 클라우드 관리형 로깅 서비스를 적극적으로 검토해 보시길 바랍니다.

특히 클라우드를 이사할 때 로그 데이터 이관에 대한 부담을 내려놓고, '보존 주기를 활용한 자연 소멸' 전략을 사용하면 서버 유목민 생활이 훨씬 더 가벼워질 것입니다.