||
글. 양현진(Cople) / 전시개발팀
안녕하세요. 전시개발팀 코플입니다.
저는 올해 사내에서 팀 이동을 하게 되었습니다. 공통플랫폼개발팀에서 약 2년 반 정도 플랫폼 개발 경험을 쌓고 전시개발팀으로 이동한 지 약 5개월이 지났습니다.
처음 경험하는 서비스 도메인 영역에서 우선적으로 서비스의 구조와 시스템을 파악하는 동시에 지금까지의 경험으로 팀에 기여할 수 있는 지점이 있는지도 고심하고 살피게 됐습니다. 특별히 큰 기여를 보다 작은 기여를 통해 팀에서 좋은 영향력을 줄 수 있지 않을까 를 먼저 생각하게 되었습니다. 이러한 생각은 주니어든 시니어든, 새 팀에 합류한 사람이라면 누구나 하는 생각이 아닐까 싶습니다.
팀에 무엇이 필요할까?
전시개발팀은 여기어때의 상품과 가격 정보를 앱과 웹에 빠르고 정확하게 서빙하는 역할을 수행하는 팀입니다. 게이트웨이 이후 서비스의 가장 많은 트래픽을 수용하는 위치에 있는 만큼 여기어때의 전반적인 트래픽이 전시개발팀의 서비스를 거치게 됩니다. 연계된 시스템과의 안정적인 통신을 통하여 가용성을 확보하고 Fail-open과 Fail-close를 관리하며, 데이터 동기화를 통해 서빙할 데이터를 적재하고 관리하는 것이 핵심 역할입니다.
그만큼 성능과 가용성에 민감하고 면밀하게 모니터링하는 수행하게 됩니다. 또한 서비스의 레이턴시를 감지하고, 오류 상황에 기민하게 대응해야 하며 연계된 시스템 중 어디서 문제가 발생했는지 빠르게 파악해서 전파하는 역할도 동시에 수행해야 합니다. 장애 알림이 울렸을 때 가장 먼저 판단해야 하는 질문 중 하나는 “이게 우리 문제인가, 아니면 우리가 호출하는 어딘가의 문제인가”입니다.
팀에 처음 이동하였을 때 최근 다른 클라우드 환경으로 주요 서비스 이관이 진행 중이었고, 옵저버빌리티 환경은 아직 기존 APM인 핀포인트의 사용성에 의존하는 경향이 있었습니다. 공통 대시보드가 있었지만, 문제의 요점을 직관적으로 확인하고 싶은 니즈가 있다는 것을 다시 확인하게 됐습니다. 마침 저는 이전 팀에서 OpenTelemetry와 Grafana를 기반으로 Metrics(Mimir), Traces(Tempo) , Logs(Loki)를 유기적으로 연결하는 옵저버빌리티 플랫폼을 설계하고 구축·운영한 경험이 있었습니다. 이 파이프라인과 경험을 바탕으로 전시개발팀의 트래픽 특성과 장애 대응 흐름에 최적화된 관측 가능성 대시보드를 구축하는 것을 첫 기여 지점으로 삼았습니다.
기준을 먼저 정했습니다
우선 관측 가능성을 높이기 위한 기준을 정의하였습니다. 어떤 정보와 기능을 제공해야 실제 관측 가능성을 증가시키고 모니터링을 쉽게 수행할 수 있을지가 관건이었습니다.
APM 도구가 제공하던 사용성에 근접할 것: 엔지니어의 장애 대응 모델을 깨지 않고 익숙한 분석 흐름을 유지합니다.
추가 인프라 비용/관리 부담을 최소화할 것: 새로운 에이전트나 전용 데몬 설치 없이, 이미 수집되고 있는 메트릭·로그 파이프라인을 100% 활용합니다.
연계 시스템(Incoming/Outgoing) 문제를 즉시 격리할 것: 대규모 트래픽을 중계·조합하는 전시 서비스 특성상 장애 전파 원인을 1초 만에 식별할 수 있어야 합니다.
에러 메트릭에서 실제 로그/트레이스로 원클릭 이동(Drill-down)할 것: 이상 감지부터 원인 로그 확인까지의 컨텍스트 스위칭을 제거합니다.
실제 업무(온콜·배포·이벤트)에서 바로 쓰일 것: 보여주기식 대시보드가 아닌, 실무자가 즐겨찾기해 두고 매일 보는 실전 도구가 되어야 합니다.
특히 첫 번째가 중요하다고 판단했습니다. 관측 가능성 도구 전환이 실패하는 흔한 이유는 기술적 한계가 아니라 사용성 후퇴가 가장 큰 요소로 작용한다고 판단했기 때문입니다. 만약 사용성이 저하되면 엔지니어는 장애 상황에서 익숙한 도구로 돌아가게 될 수 있으며, 다른 방식을 적용하게 돼 파편화가 이루어질 수 있다는 우려가 있습니다. 새로운 도구가 기존 도구의 문제 해결 흐름을 최소한 동등하게 재현하지 못하면 만들어진 다음 날부터 쓰이지 않게 됩니다. 추가로 비용적인 요소를 최소화하면서 전시개


