이번에 기능 테스트 중 발생한 예외 로그를 PM/디자이너 분들도 직접 Kibana에서 확인할 수 있도록 공유하는 구조를 고민했다. 현재 로그는 DB에 저장되고 있어 사후 분석은 가능하지만 실시간으로 확인하고 공유하는 데는 한계가 있었다. 특히 기능 검수 중 발생하는 예외를 빠르게 파악하려면 Kibana 같은 시각화 도구의 실시간 로그 조회 기능이 필요했고 이를 비용 부담 없이 구현하는 구조가 필요했다.
Elasticsearch/Kibana를 EC2에 띄우면 CPU와 메모리 자원 사용량이 높아져 요금 부담이 커진다. 그러나 UI/UX 검수 중 발생하는 예외 상황을 실시간으로 파악하고 빠르게 대응할 수 있는 방법이 필요했다. 개발자만 로그를 보는 것이 아니라 기획/디자인 담당자도 직접 확인 가능한 구조가 있으면 커뮤니케이션 효율이 크게 향상될 수 있다고 판단했다.
[EC2 운영 서버]
└─ Spring Boot 애플리케이션 로그 -> Filebeat -> SSH 리버스 터널링
[로컬 개발자 PC]
└─ Elasticsearch + Kibana (Docker)
└─ Kibana에 외부 접근을 위한 cloudflared (또는 Ngrok)
docker run -d --name elasticsearch -p 9200:9200 elasticsearch:7.17.20
docker run -d --name kibana -p 5601:5601 --link elasticsearch kibana:7.17.20
cloudflared tunnel
(Cloudflare)ngrok http 5601
생성된 URL 예시: https://logs-moomoo-gift.trycloudflare.com
필요 시 Basic Auth나 인증 토큰으로 보호
공유 텍스트 예시
실시간 로그 확인 페이지
기획/디자인 테스트 중 발생하는 에러를 바로 확인할 수 있는 페이지입니다.
URL: `https://logs-moomoo-gift.trycloudflare.com`
비밀번호: [개별 전달]
로그는 7일간 보관되며 운영자 로컬 PC에서만 저장 및 분석됩니다.
이렇게 공유하면 기획/디자인 시나리오 테스트 중 문제 발생 시 “로그를 캡처해 보내는 수고” 없이 공유 가능하다. “어떤 에러 메시지가 떴는지 몰라서 확인이 어렵다”는 커뮤니케이션 병목 제거할 수 있고 개발자와 실시간으로 로그를 공유함으로써 이슈 확인 및 피드백 속도 향상된다.
이번 로그 공유 구조를 설계하면서 가장 크게 느낀 점은 로그라는 도구가 단순히 개발자만을 위한 기술적인 리소스가 아니라는 것이다. 특히 기능 검수나 UI/UX 테스트 과정에서 발생하는 이슈는 개발자가 직접 재현하기 어렵고 PM이나 디자이너가 "무슨 일이 있었는지"를 정확하게 설명하기도 쉽지 않다. 이런 상황에서 로그를 실시간으로 함께 확인할 수 있으면 커뮤니케이션 병목을 줄이고 빠른 피드백 루프를 형성하는 데 큰 도움이 된다. 단순히 "어떤 버튼을 눌렀는데 이상했어요"라는 말보다 실제 로그를 근거로 원인을 바로 파악하고 대응할 수 있기 때문에 협업 효율이 눈에 띄게 향상된다.
또한 클라우드 자원 사용을 줄이기 위해 Elasticsearch와 Kibana는 로컬에서 운영하고 EC2에서는 Filebeat만 가볍게 띄운 뒤 리버스 터널링으로 데이터를 전달하는 방식은 실무에서도 충분히 효과적인 전략임을 확인했다. 비용과 보안 부담을 줄이면서도 필요할 때 외부 링크로 Kibana를 열어 기획/디자인 팀도 쉽게 로그를 확인할 수 있다는 점에서 매우 실용적이다. 앞으로는 이 구조를 기반으로 로그 수준 필터링, Slack 알림 연동, 특정 에러의 자동 감지 등도 단계적으로 확장해볼 수 있겠다는 가능성을 느꼈다.