|| 영원희(YoungWonHee) 서비스 개발기이번 글에서는 모듈유닛으로 구성된 매장(이하 모듈매장)의 운영 및 디버깅에 다루고 있습니다.
모듈유닛이 무엇인지 궁금하다면?
페이지를 이루는 최소 기능 블록, 모듈유닛 | SSG TECH BLOG
안녕하세요.
프론트서비스개발팀 서비스매장파트의 조원현입니다.
모듈매장과 코너 영역을 운영하다 보면, 노출 여부나 데이터 정합성과 관련된 문의가 종종 발생합니다.
“모듈매장에 등록한 코너의 상품/배너/기획전이 노출이 안 됩니다.”
“오반장에 상품을 등록했는데 노출이 안 됩니다.”
“특정 모듈이 노출되고 있지 않습니다.”
단순한 문의처럼 보이지만, 실제로는 원인을 바로 특정하기가 쉽지 않습니다. 사용자가 보는 화면은 하나의 API 결과가 아니라, 여러 전시 데이터와 내부 후처리 로직이 결합된 최종 결과이기 때문입니다.
이 글에서는 이런 운영 이슈에 더 빠르게 대응하기 위해 만든 내부 디버깅 서비스 “영원희”를 소개하려고 합니다. 참고로 ‘영원희’ 라는 이름은 서비스를 함께 고민하고 만든 영진, 원현, 희수의 이름에서 한 글자씩 따왔습니다.
YoungWonHee왜 이런 도구가 필요했을까
모듈매장은 하나의 독립적인 데이터 소스만으로 동작하지 않습니다. 다양한 전시 데이터를 조합해 최종 화면을 구성하는 서비스입니다. 모듈에서 조회하는 데이터에는 코너, 광고, 기획전, 배송 정보, 개인화 추천, 브랜드, 카테고리 등 SSG에서 제공중인 다양한 정보가 포함됩니다.
각 모듈은 설정된 정보를 바탕으로 필요한 API들을 호출해 데이터를 조회합니다. 호출된 API는 요청값을 기준으로 내부 로직을 수행한 뒤 응답을 반환하고, 모듈매장에서는 이 데이터를 조합하고,후가공하여 최종 전시 데이터를 구성합니다. 어떠한 모듈을 조회할지 판단하는 로직, 최종 결과에서 특정 모듈을 제외할 지 결정하는 등의 공통 로직 또한 모듈매장 내부에서 수행됩니다.
즉, 사용자가 보는 결과는 단일 API의 응답이 아니라, 모듈매장에서의 전처리, 여러 서비스의 응답, 후처리 로직이 결합된 결과입니다. “노출이 안 된다”, “데이터가 이상하다”라는 문의가 들어오면 단순히 한 곳만 확인해서는 해결되지 않습니다.
원인을 찾기 위해서는 단계별로 모두 확인해야 했습니다.
1. 모듈 설정이 정상적으로 되어 있는지
2. 원천 데이터가 정상적으로 저장되었는지
3. 관련 API가 어떤 요청값으로 호출되었는지
4. 응답 데이터가 기대한 값인지
5. 후처리 과정에서 제외되거나 변경된 것은 아닌지기존 대응 방식의 한계
기존에는 이런 문제를 해결하기 위해 여러 시스템을 오가며 DB 직접 조회, 개별 서비스 로그 확인, 관련 소스 분석, 서비스 간 호출 흐름 추적을 수작업으로 진행해야 했습니다.
특히 MSA 환경에서는 각 서비스의 로그가 분산되어 있기 때문에, 하나의 문의를 처리하기 위해 여러 로그를 따로 확인한 뒤 머릿속에서 연결해야 했습니다.
이 과정은 시간이 많이 들 뿐 아니라, 운영 대응 속도에도 직접적인 영향을 주었습니다. 같은 유형의 문의가 반복될수록 비효율은 더욱 커졌습니다.
초기에는 반복 문의에 자동으로 답변할 수 있는 “자동 문의 응답 봇”까지 구상했습니다. 하지만 그 전에 먼저 해결해야 할 문제가 있었습니다.
빠른 운영 대응을 위해 가장 중요했던 것은 관련 로그를 한 곳에서 모아보고, 요청 흐름을 한눈에 파악할 수 있는 공통된 관찰 도구가 필요했습니다.
그 출발점으로 만든 것이 바로 영원희(YoungWonHee)입니다.
영원희의 핵심 아이디어: 요청 흐름을 묶기
영원희의 핵심은 매우 간단합니다. 하나의 요청 흐름을 하나의 식별자로 연결하는 것입니다. 서비스 요청 시작 시 생성하거나 전달 받은 logGroupId를 연계되는 내부 API 호출이나 세부 로직, 쿼리 조회 등의 요청과 응답을 로그로 함께 남기고, 이를 시간 순서대로 수집해 화면에서 확인할 수 있도록 했습니다. 각 서비스에서 발생한 로그를 시간 정보를 포함하여 Kafka Topic 메시지로 생성해 전달하고, Consumer가 이를 비동기적으로
모듈유닛이 무엇인지 궁금하다면?
페이지를 이루는 최소 기능 블록, 모듈유닛 | SSG TECH BLOG
안녕하세요.
프론트서비스개발팀 서비스매장파트의 조원현입니다.
모듈매장과 코너 영역을 운영하다 보면, 노출 여부나 데이터 정합성과 관련된 문의가 종종 발생합니다.
“모듈매장에 등록한 코너의 상품/배너/기획전이 노출이 안 됩니다.”
“오반장에 상품을 등록했는데 노출이 안 됩니다.”
“특정 모듈이 노출되고 있지 않습니다.”
단순한 문의처럼 보이지만, 실제로는 원인을 바로 특정하기가 쉽지 않습니다. 사용자가 보는 화면은 하나의 API 결과가 아니라, 여러 전시 데이터와 내부 후처리 로직이 결합된 최종 결과이기 때문입니다.
이 글에서는 이런 운영 이슈에 더 빠르게 대응하기 위해 만든 내부 디버깅 서비스 “영원희”를 소개하려고 합니다. 참고로 ‘영원희’ 라는 이름은 서비스를 함께 고민하고 만든 영진, 원현, 희수의 이름에서 한 글자씩 따왔습니다.
YoungWonHee왜 이런 도구가 필요했을까
모듈매장은 하나의 독립적인 데이터 소스만으로 동작하지 않습니다. 다양한 전시 데이터를 조합해 최종 화면을 구성하는 서비스입니다. 모듈에서 조회하는 데이터에는 코너, 광고, 기획전, 배송 정보, 개인화 추천, 브랜드, 카테고리 등 SSG에서 제공중인 다양한 정보가 포함됩니다.
각 모듈은 설정된 정보를 바탕으로 필요한 API들을 호출해 데이터를 조회합니다. 호출된 API는 요청값을 기준으로 내부 로직을 수행한 뒤 응답을 반환하고, 모듈매장에서는 이 데이터를 조합하고,후가공하여 최종 전시 데이터를 구성합니다. 어떠한 모듈을 조회할지 판단하는 로직, 최종 결과에서 특정 모듈을 제외할 지 결정하는 등의 공통 로직 또한 모듈매장 내부에서 수행됩니다.
즉, 사용자가 보는 결과는 단일 API의 응답이 아니라, 모듈매장에서의 전처리, 여러 서비스의 응답, 후처리 로직이 결합된 결과입니다. “노출이 안 된다”, “데이터가 이상하다”라는 문의가 들어오면 단순히 한 곳만 확인해서는 해결되지 않습니다.
원인을 찾기 위해서는 단계별로 모두 확인해야 했습니다.
1. 모듈 설정이 정상적으로 되어 있는지
2. 원천 데이터가 정상적으로 저장되었는지
3. 관련 API가 어떤 요청값으로 호출되었는지
4. 응답 데이터가 기대한 값인지
5. 후처리 과정에서 제외되거나 변경된 것은 아닌지기존 대응 방식의 한계
기존에는 이런 문제를 해결하기 위해 여러 시스템을 오가며 DB 직접 조회, 개별 서비스 로그 확인, 관련 소스 분석, 서비스 간 호출 흐름 추적을 수작업으로 진행해야 했습니다.
특히 MSA 환경에서는 각 서비스의 로그가 분산되어 있기 때문에, 하나의 문의를 처리하기 위해 여러 로그를 따로 확인한 뒤 머릿속에서 연결해야 했습니다.
이 과정은 시간이 많이 들 뿐 아니라, 운영 대응 속도에도 직접적인 영향을 주었습니다. 같은 유형의 문의가 반복될수록 비효율은 더욱 커졌습니다.
초기에는 반복 문의에 자동으로 답변할 수 있는 “자동 문의 응답 봇”까지 구상했습니다. 하지만 그 전에 먼저 해결해야 할 문제가 있었습니다.
빠른 운영 대응을 위해 가장 중요했던 것은 관련 로그를 한 곳에서 모아보고, 요청 흐름을 한눈에 파악할 수 있는 공통된 관찰 도구가 필요했습니다.
그 출발점으로 만든 것이 바로 영원희(YoungWonHee)입니다.
영원희의 핵심 아이디어: 요청 흐름을 묶기
영원희의 핵심은 매우 간단합니다. 하나의 요청 흐름을 하나의 식별자로 연결하는 것입니다. 서비스 요청 시작 시 생성하거나 전달 받은 logGroupId를 연계되는 내부 API 호출이나 세부 로직, 쿼리 조회 등의 요청과 응답을 로그로 함께 남기고, 이를 시간 순서대로 수집해 화면에서 확인할 수 있도록 했습니다. 각 서비스에서 발생한 로그를 시간 정보를 포함하여 Kafka Topic 메시지로 생성해 전달하고, Consumer가 이를 비동기적으로