이번 포스팅에선 프로젝트에 참여하여 데이터를 수집하고 관찰 가능성(Observability)를 향상시키는 과정에서 문제를 정의하고 적절한 해결을 위해 고민한 내용들을 공유하고자 합니다.

당시 팀에는 데이터 인프라가 전혀 없었고, 문제가 발생해도 원인 분석에 한참이 걸렸으며 사용자를 이해하기 위한 정보가 부족해 팀 내 의사결정과 소통이 어려웠습니다. 이런 팀의 불편을 해결하기 위해 제가 직접 문제를 정의하고 솔루션을 구축했습니다. (구축된 솔루션은 계속해서 디벨롭 중입니다.)

앞으로 시리즈로 여러 관련 포스팅을 작성할 예정이며 데이터 인프라를 어떻게 구축하였고 데이터 인프라가 어떻게 팀의 소통과 의사결정에 긍정적인 영향을 미치고 더 나은 서비스 품질에 영향을 주는지를 공유해보고자 합니다.

데이터 인프라는 alloy - loki - grafana 구성으로 시스템을 구축했습니다.

데이터 수집의 중요성

최근 IT 시스템에 이어 AI까지 크게 발전하면서 디지털 데이터의 중요성이 매우 커졌습니다.

잘 수집된 데이터는 의사결정을 위한 근거가 되고, IT 기반 서비스를 운영할 때도 서비스 운영의 효율성 및 가용성을 향상시켜 고객 만족도를 높이는 데 큰 역할을 합니다.

또한, AI를 잘 활용하는데에도 필수입니다. Context engineering이라는 용어가 나올 정도로 AI 활용을 잘 하기 위해선 raw data의 존재는 필수 불가결합니다.

현재 상황과 문제 정의

현재 팀에는 별도의 데이터 수집 인프라가 존재하지 않으며, 당시 팀은 CloudWatch와 S3에 로그를 흩뿌려 저장할 뿐이었고, 저는 이를 한눈에 볼 수 없다는 점을 가장 큰 리스크로 생각했습니다.

또한, shopify 기반 서비스로 shopify에서 수집한 정보들은 적절한 가공이 힘들며 따라서, shopify에서 제공하는 대시보드를 이용하여 수집된 정보를 확인할 수 밖에 없습니다.

이렇게 서비스 운영을 위한 데이터 주권이 없는 것 또한 서비스의 장기적인 리스크라고 생각했습니다.

문제 정의

저는 다음과 같이 현재 상황의 문제를 정의했습니다.

AWS 자원 각각에서 로그가 수집 됨

한눈에 확인하기가 쉽지 않음.
중앙 관제가 어려움.
비개발자들에게도 필요한 정보를 제공해줄 수 없음.

실제로 장애 발생 시, ECS 인스턴스 로그, lambda 로그들을 각각 다른 콘솔에서 찾아야 했습니다. 그 과정에서 대응이 늦어지는 문제가 있었습니다.

또한, 장애 발생 시, 비개발자분들에게 필요한 정보를 제공해주기가 어려웠습니다.

정제되지 않은 로그

노이즈가 많아 시스템 문제 파악이 어려움.

Cloudwatch에 찍힌 로그엔 일반적으로 찍힌 로그들과 에러 로그가 뒤섞여 있어, 에러 로그를 파악하기가 어려웠습니다.

수집된 정보는 모두 shopify 소유

수집된 정보들은 shopify에서 제공하는 대시보드를 이용하여 확인할 수 밖에 없음.
내재화된 정보가 아니어서 적절한 가공이 힘듦.
가공이 힘들어 더 세세한 의사결정을 위한 데이터를 얻기가 어려움.

shopify가 공개한 여러 API들을 이용해 shopify에 저장된 정보를 가져와 가공할 수는 있었습니다.

하지만, 가져오기까지의 수고로움과 가져온 데이터들과 함께 연동하는 과정까지 번거롭고 복잡한 과정이었습니다.

문제 해결

위 문제를 적절하게 해결하기 위해 다음의 조건을 만족하는 시스템을 구축하기로 했습니다.

중앙 관제가 가능한 시스템
필요한 정보만 정제하여 볼 수 있는 시스템
정보 내재화

어떻게 적절하게 해결할 수 있을까?

문제를 정의했다면 어떻게 해결할 것인가?에 대해 고민해야 합니다.

다양한 해결 방법들이 있지만 해결 방법을 정할 땐, 현재 상황과 가용 비용 등 여러가지 요인을 고려하여 적절한 트레이드 오프를 고려해야 합니다.

여러가지 로깅 / APM 도구들

활용할 수 있는 여러가지 도구들을 알아보았습니다.

Google Analytics

서비스내의 사용자의 정보와 행동을 분석할 수 있는 솔루션으로 비개발자분들의 사용성 측면에서 가장 좋은 솔루션입니다.

서비스에 간편하게 설치하여 사용할 수 있어 개발 비용 측면에서도 부담이 없습니다.

중요한 의사결정을 위해 필요한 데이터를 자유롭게 가공할 수 있고 자동으로 깔끔한 대시보드를 제공해주기 때문에 큰 도움이 될 수 있는 솔루션입니다.

Grafana 생태계 (Loki, Prometheus, Tempo, etc.)

서비스의 관찰 가능성을 향상시키고 서비스 내부의 문제를 파악하고 해결하는데 큰 도움이 될 수 있는 솔루션입니다.

Grafana Cloud를 이용한 서비스를 이용할수도 있지만 오픈 소스 솔루션으로 직접 운용한다면 infra 비용 이외엔 서비스 이용 비용이 없어 장기적인 비용 부담이 적은 것이 장점입니다.

하지만, 직접 운용한다면 모니터링 시스템을 구축 및 운용하는 수고로움이 있을 수 있습니다.

Grafana는 기존엔 metric을 관찰하는데 사용되었지만, Loki, Tempo 등과 연동하여 더욱 확장성 있는 관찰 가능성 시스템을 구축할 수 있습니다.

따라서, 확장성 측면에서 매우 우수한 솔루션이라고 생각합니다.

ELK stack

ELK는 Elasticsearch, Logstash, Kibana의 약자로, 가장 유명한 로그 수집 및 관리 솔루션입니다.

ELK는 서비스의 관찰가능성 뿐만아니라 비즈니스의 의사결정까지 자유롭게 할 수 있을 정도로 강력한 솔루션이라고 생각합니다.

Grafana와 동일하게 Elastic에서 제공하는 서비스를 이용할수도 있지만, 자체적으로 구축하여 운용할 수도 있습니다.

직접 운용한다면 모니터링 시스템을 구축 및 운용하는 수고로움이 있을 수 있지만 장기적인 비용 부담이 적은 것이 장점입니다.

충분히 매력적인 선택지이지만, Grafana 생태계와 비교했을 때 운용 및 인프라 비용이 더 비싼 편으로 Grafana 생태계를 선택하였습니다.

Datadog

Datadog는 관찰 가능성 측면에서 매우 우수한 솔루션입니다.

설치도 매우 간단하고 설정도 간단하며 UI와 기능들도 매우 우수합니다. RUM 또한 제공되어 FE에서의 문제점도 빠르게 파악할 수 있습니다.

하지만 비용이 상당히 비싼 편으로 팀 리소스와 맞지 않았습니다.

AWS Amplitude or Vercel

FE 프로젝트를 배포하는데 가장 좋은 솔루션 중 하나라고 생각합니다.

이 두 서비스의 강점은 FE 팀이 스스로 프로젝트를 배포하고 관리하고 협업하는데 유리한 솔루션이라고 생각됩니다.

하지만, 현재는 FE팀이 따로 없고 비용문제가 있어 고려하지 않았습니다.

어떤 방법이 가장 적절할까? - 상황에 맞는 트레이드 오프 고려

현 상황을 고려하면 다음과같은 조건이 있었습니다.

운용 비용보다는 금전 비용을 최소화하는 것이 중요함
확장성 있는 솔루션이 필요함
- AWS 이외의 클라우드를 사용할 가능성이 있음.
팀 전체의 효율적인 소통을 위한 중앙 관제가 가능한 솔루션이 필요함
- 서비스가 다양하게 운용될 예정이어서 각 서비스들과 각자의 리전에서 로그를 다루고 저장하면서도 중앙 관제가 가능한 솔루션이 필요함.

문제의 목적과 조건을 고려하면 다음과같은 솔루션이 가장 적절할 것 같다고 판단하였습니다.

Grafana 생태계
Google Analytics

ELK vs Grafana

ELK 또한 위 조건에 부합하는 솔루션이어서 Grafana 생태계와 여러 방면에서 고민을 해보았고 다음과 같은 이유로 Grafana 생태계를 선택하였습니다.

가장 중요하게 고려했던 점은 팀에 제한적인 운영 인력으로, 상대적으로 경량화된 Grafana 생태계가 훨씬 실용적이라고 판단했습니다.

상대적으로 간편한 Grafana 생태계 구축과 운영 비용
- ElasticSearch의 높은 인프라 및 관리 비용 따끈따끈한 전사 로그 시스템 전환기: ELK Stack에서 Loki로 전환한 이유 - 우아한형제들 테크블로그 -> ELK Stack대비 23% 저렴한 비용
뛰어난 Grafana 생태계의 확장성 Tempo, Prometheus, etc. 등과 연동하여 더욱 확장성 있는 관찰 가능성 시스템을 구축할 수 있음
Google Analytics로 비즈니스 의사결정을 위한 정교한 쿼리 기능을 대체할 수 있음

진행

이번 구축 경험은 단순 로깅 이상의 의미가 있었습니다. 비즈니스에 영향을 줄 수 있는 서비스의 문제를 정의하고 트레이드오프 속에서 적절한 결정을 내리는 과정들을 직접 체득한 과정이었습니다. 저는 이 과정을 통해 기술적 깊이뿐 아니라, 서비스 오너십과 의사결정자의 시각을 체득할 수 있었습니다.

특히 ‘ELK 대신 Grafana’라는 선택은 단순한 비용 절감이 아니라, 스타트업 맥락에서 어떤 솔루션이 현실적으로 팀에 맞는지를 판단한 의사결정 경험이었습니다.

최종 결과물

구축된 최종 결과물은 다음과 같습니다.

앞으로의 시리즈는 이 최종 결과물을 설계하고 구현하고 어떤 효과가 있었는지에 대한 내용이 진행됩니다.

관찰 가능성 시스템 구현기 1 - 문제 정의