안녕하세요, 오늘의집 Data Analyst Sophie, Technical Lead Minsoo입니다.

사건과 기록 사이에는 늘 간극이 있습니다. 아무리 정교하게 기록을 쌓아도, 해석 과정에서 빈틈이 생기기 마련이죠. 역사가가 파편화된 사료로 서사를 복원하고 탐정이 현장의 흔적을 추적해 시간을 복원하듯, IT 플랫폼에서 고객을 이해하는 일 또한 남겨진 증거를 통해 실체를 유추하는 과정에 가깝습니다. 고객의 생각을 직접 볼 수 없기에, 저희 팀은 클릭과 노출 같은 찰나의 로그(Log)를 더 집요하게 설계합니다. 어떤 순간을 포착하고 어떤 맥락을 함께 저장하느냐에 따라 이후 데이터가 말해주는 진실의 밀도가 달라지기 때문입니다.

이번 글에서는 로그를 남기는 방법론을 넘어, 파편화된 기록들을 '견고한 하나의 진실'로 관리해 왔는지, 그리고 그 과정에서 데이터의 신뢰를 어떻게 회복해 왔는지 이야기해 보려 합니다.

언어의 질서를 세우고 기준을 만들다

저희는 사용자의 행동을 깊이 이해하기 위해 그동안 수많은 이벤트 로그(OhsLog)를 쌓아왔습니다. 하지만 서비스가 확장되면서 로그를 기록하는 주체가 다양해졌고, 데이터 언어는 마치 지역별 방언처럼 제각각 파편화되기 시작했습니다. 특정 필드가 정확히 무엇을 의미하는지 매번 대조하고 확인하는 데만 막대한 리소스가 들 정도였습니다.

데이터의 신뢰를 회복하기 위해 저희가 가장 먼저 한 일은 도구를 바꾸는 것이 아니라 ‘언어의 규칙’을 다시 세우는 일이었습니다. 개인의 직관에 기대지 않고 누구나 읽고 바로 이해할 수 있는 기준을 만들기 위해 공식 매뉴얼인 ‘OhsLog 그라운드 룰’을 정립했습니다.

먼저 모호하게 흩어져 있던 필드들을 ID 체계로 규격화하고, 분석 의도가 명확히 반영된 명명 규칙을  세웠습니다. 기존의 수만 개 로그를 화면 모듈과 하나하나 매핑해 나가는 ‘역설계’ 과정은 결코 쉽지 않았지만, 이 지난한 과정을 거치며 파편화된 정보들은 비로소 하나의 '의도'로 묶이기 시작했습니다.

그렇게 정돈된 결과물 중 하나가 바로 통일된 '로그 명세'입니다. 로그 명세는 로그가 발화되어야 하는 상황과 구조, 그리고 꼭 필요한 정보를 설명하는 일종의 설계도인데요. 각 필드가 어떤 의미를 가져야 하는지 사람의 언어로 차근차근 풀어내니, 엔지니어가 로그를 구현할 때 참고할 수 있는 가장 명확한 요건 설명서가 되어주었습니다.

특히 OhsLog는 다른 플랫폼에 비해 로그 발생 시 함께 전달해야 하는 컨텍스트 정보가 유독 많습니다. 그만큼 명문화된 설명은 선택이 아닌 필수였죠. 모든 로그를 하나의 체계로 정리하기 위해 기록조차 남지 않은 오래된 레거시 로그까지 직접 수기로 검수하며 통합하는 과정도 거쳐야 했습니다. 이 일괄 정리를 통해, 수만 개의 파편은 비로소 하나의 언어로 수렴될 수 있었습니다.

하지만 과거의 기록을 모두 정리했다고 해서 끝은 아니었습니다. 서비스는 계속해서 새로운 로그를 필요로 하니까요. 거대한 사전을 만들었다고 해서 구성원 모두가 완벽한 문장을 쓸 수 있는 건 아니듯, 규칙을 세우는 것과 그 규칙이 현장에서 지켜지는 것은 전혀 다른 문제였습니다. 결국 개인의 의지나 노력에만 기대기보다, 잘못된 정의가 생성되는 것을 시스템적으로 방지하고 교정해 줄 더 강력한 질서가 절실해졌습니다.

스프레드시트로 시작한 관리, 그리고 드러난 한계

그 질서를 담기 위해 처음 선택한 그릇은 스프레드시트였습니다. Page ID, Enum, 로그 명세를 각기 다른 시트에 나누어 체계적인 관리를 시작했어요. 예를 들어, 지면 관리를 위해 Page ID라는 고유 키를 정의하고 기존에 페이지 구분을 위해 사용하던 URL 패턴까지 함께 정리했습니다. 동시에 모듈 구분을 위해 한글로 값을 입력하던 기존의 object_section 체계를 영문 Enum 기반의 object_section_id로 전면 이관하는 작업도 병행했습니다. 모듈 이외에도 비정형 텍스트로 제각기 쓰던 필드들은 모두 Enum으로 정리했습니다.

이렇게 각 영역별 고유 규칙을 세우며 로그 그라운드룰을 정립해 나갔고, 적어도 하나의 문서 안에서 이 모든 흐름을 파악할 수 있게 된 건 무척 큰 발전이었습니다. 전사적으로 활용할 수 있는 본격적인 관리의 구심점이 드디어 마련된 셈이니까요. 하지만 체계가 잡히는 듯했던 기쁨도 잠시, 곧 ‘시트 지옥’이라는 새로운 병목에 부딪히고 말았습니다.

우선 프로세스의 비효율이 너무 컸습니다. 거대한 시트 위에서 명세 작업을 마쳐도, 이를 로그 관리 시스템에 반영하려면 데이터 엔지니어가 별도의 스크립트를 실행해야 하는 이중 작업이 반복됐습니다. 앱 지면을 정의하는 Page ID나 URL 매핑을 추가할 때마다 엔지니어가 직접 파이프라인 코드를 수정하고 배포해야 하는 수작업도 여전했습니다.

신뢰성에도 한계가 드러나기 시작했습니다. 기획용과 개발용 로그 명세 시트가 따로 존재하고, 도메인별로 시트가 파편화되면서 무엇이 '최신본'인지 알 수 없는 상황이 벌어진 거죠. 규칙은 세웠지만 이를 담는 그릇이 제각각이다 보니, 그토록 바랐던 단일 진실 공급원(Single Source of Truth)은 여전히 멀리 있었습니다.

로그 생애주기의 통합 기준점, Log Center

파편화 문제를 근본적으로 해결하기 위해, 흩어진 그릇들을 하나로 모을 통합 로그 관리 플랫폼, 'Log Center'를 구축했습니다. Log Center는 단순히 기존 시트를 웹으로 옮겨놓은 시스템이 아닙니다. 로그 데이터의 설계와 탄생부터 개발, 검증, 운영, 그리고 폐기에 이르는 전 생애주기(Lifecycle)를 플랫폼 내에 완벽히 내재화했다는 점에 핵심이 있습니다.

이제 로그 명세에 필요한 Enum 정보는 물론, 시각적 맥락을 제공하는 Figma 스크린샷, 그리고 각 항목의 정합성을 보장하는 검증(Validation) 규칙까지 모든 메타데이터가 Log Center 내에서 중앙 관리됩니다. 덕분에 별도의 코드 수정 없이도 실시간으로 데이터 체계를 업데이트할 수 있는 유연성까지 확보하게 되었습니다.

무엇보다 Log Center는 각 직군의 역할을 하나의 흐름으로 자연스럽게 연결해주었습니다. Data Analyst의 정교한 로그 설계부터 Software Engineer의 명확한 코드 구현, 그리고 Data QA Engineer의 신속하고 정확한 검증에 이르기까지. 전 과정이 하나의 플랫폼 안으로 모이면서, 모두가 같은 정보를 보고 같은 맥락으로 소통할 수 있는 협업 환경도 갖춰졌습니다.

[ 플랫폼 핵심 기능 ]

Log Center는 서로 연결된 기능을 바탕으로 로그 관리 과정을 더 효율적으로 만들어주었습니다.

❶ 시각적 로그 명세 관리 (Figma 연동)

기존의 텍스트 중심 명세만으로는 실제 UI 맥락을 충분히 전달하기 어려웠습니다. 이를 보완하기 위해 Figma API를 활용해 디자인 프레임과 로그 명세를 직접 연결했습니다. 이제 개발자는 설명만 읽는 것이 아니라, 실제 화면의 어느 지점에서 로그가 발생하는지 함께 확인할 수 있습니다. 덕분에 기획 의도를 다르게 해석할 가능성이 줄었고, 개발 정확도도 함께 높아졌습니다.

❷ 중앙화된 Enum 관리

서비스 전반에 쓰이는 모듈, 오브젝트, 이벤트 등 모든 Enum 값은 Log Center에서 통합 관리합니다. 명세마다 다르게 쓰이던 값을 표준화하면서 데이터 정합성을 더 안정적으로 확보할 수 있게 되었고, 사람이 직접 입력하는 과정에서 생기던 실수도 줄일 수 있었습니다.

❸ 협업 및 히스토리 관리 (커뮤니케이션 기능)

플랫폼 내 코멘트 기능을 통해 로그 명세의 각 항목에 대한 논의와 의사결정 과정을 함께 기록할 수 있습니다. 개발과 QA 이력도 로그의 맥락 안에서 함께 남기 때문에, 담당자가 바뀌더라도 이전 배경을 쉽게 파악할 수 있습니다. 또한 Jira 티켓과 연동해 개발 진행 상황도 한곳에서 확인하고 관리할 수 있게 되었습니다.

❹ 실시간 로그 조회 및 자동 검증

Log Viewer를 통해 개발 환경에서 발생하는 로그를 실시간으로 모니터링하며, 정의된 명세와 일치하는지 즉시 확인할 수 있습니다. 여기서 한 단계 더 나아가 Log Validator는 수집된 로그가 데이터 타입, 필수값 여부 같은 명세 규칙을 잘 지키고 있는지 자동으로 검증합니다. 이 두 기능이 함께 작동하면서 개발과 검증 사이의 피드백이 빨라졌고, 전체 작업 효율도 한층 높아졌습니다.

 [ 워크플로우가 바꾼 협업의 방식 ]

Log Center의 도입은 툴 하나를 바꾼 일에 그치지 않았습니다. 같은 데이터를 함께 보고 이야기할 수 있는 기반이 생기면서, 직군 간 소통 방식도 자연스럽게 달라졌습니다. 이제 모두가 Log Center라는 하나의 창구를 통해 같은 정보를 바라보게 되었고, 각자 맡은 역할에 더 집중할 수 있는 환경도 갖춰졌습니다.

• Data Analyst (DA)는 더 이상 여기저기 흩어진 문서를 모으고 맞춰보는 데 시간을 쓰지 않습니다. 대신 데이터의 구조와 흐름을 설계하는 본래 역할에 더 집중할 수 있게 됐습니다. 잘 정의된 데이터가 곧 비즈니스 가치로 이어진다는 기준 아래, 이전보다 더 정교하고 완성도 높은 명세를 설계하고 있습니다.
• Software Engineer (ENG)는 명세를 해석할 때 느끼던 모호함이 크게 줄었습니다. Figma 연동으로 시각적 맥락을 함께 확인하고, 중앙화된 규칙을 기준으로 코드를 작성할 수 있게 되면서 불필요한 재작업과 커뮤니케이션 비용도 눈에 띄게 줄었습니다. 특히 Log Viewer를 통해 직접 개발한 로그가 의도한 대로 동작하는지 바로 확인할 수 있어, 개발의 완성도는 물론 자신감도 함께 높아졌습니다.
• Data QA Engineer (DQA)는 반복적이고 수동적인 검증 작업에서 한층 자유로워졌습니다. Log Validator가 명세 기반의 정합성을 자동으로 점검해주기 때문입니다. 덕분에 실제 데이터가 어떻게 활용될지를 고려한 더 깊이 있는 품질 검증에 시간을 쓸 수 있게 되었습니다. 무엇보다, 로그 명세 시트, 로그 QA 시트, Jira 티켓으로 나뉘어 있던 커뮤니케이션을 Log Center로 일원화하여 커뮤니케이션의 복잡도를 크게 낮출 수 있었습니다.

이처럼 Log Center는 DA, ENG, DQA가 각자의 역할에 더 집중하면서도 자연스럽게 협업할 수 있는 환경을 만들었습니다. 그리고 이런 변화는 더 빠르고 안정적인 데이터 기반 의사결정으로 이어지고 있습니다.

공통 문법이 가져온 AI 업무 변화

Log Center를 통해 로그가 한곳에 모이면서, 데이터는 단순히 쌓아두는 기록을 넘어 실제 업무에 활용할 수 있는 자산으로 자리 잡기 시작했습니다. 신뢰할 수 있는 SSOT 명세 기반이 갖춰지자, AI를 실무에 연결할 수 있는 환경도 조금씩 만들어갈 수 있었습니다.

명세 작성 단계에서의 AI 활용은 디자인과 명세를 자동으로 연결하는 일이었습니다. Figma 데이터에서 로그 관련 컴포넌트를 자동으로 식별해 명세서 초안을 만들고 Data Analyst는 명세서 초안을 검토하는 정도로, 기존 대비 리소스 절감을 크게 했습니다.

또 다른 눈에 띄는 변화 중 하나는 MCP(Model Context Protocol)를 통해 개발 환경을 확장할 수 있게 된 점이었습니다. Log Center에 축적된 정제된 데이터를 Claude 같은 AI 어시스턴트와 연결할 수 있게 되면서, Software Engineer는 여러 문서를 오가며 명세를 해석하지 않아도 자연어로 필요한 내용을 확인할 수 있게 됐습니다. AI는 우리 플랫폼의 공통 문법과 맥락을 바탕으로 로그 코드를 제안하고, 경우에 따라 코드 수정까지 도와주는 방식으로 활용되고 있습니다.

로그 QA 단계에서의 활용은, Data QA Engineer가 파악한 이슈를 로그 명세에 메모하면 이를 기반으로 JIRA 티켓을 생성할 수 있게 되었습니다. 기존에 로그 QA 과정 중 나오는 여러 논의가 파편화되어 이뤄졌다면, 이제는 로그 QA 과정과 티켓 처리가 모두 센터에 히스토리 관리가 됩니다. 덕분에 커뮤니케이션 비용도 낮추고 QA 과정에도 일부 자동화를 구현했습니다. 과거 수작업으로 진행되던 고단한 반복 업무들이 지능형 보조 시스템을 통해 획기적으로 줄어들기 시작한 것이죠.

이런 효율화가 가능했던 건, 그 바탕에 신뢰할 수 있는 SSOT 명세 시스템이 있었기 때문입니다. 로그를 체계적으로 관리하는 시스템을 갖추면서, AI가 실제로 읽고 활용할 수 있는 데이터 기반도 함께 만들 수 있었습니다. 물론 데이터의 가치를 정의하고, 어떤 질문을 던져야 하는지 판단하는 일은 여전히 사람의 몫입니다. 다만 이런 변화 덕분에 반복적인 작업에서 벗어나, 데이터가 보여주는 더 중요한 문제와 기회에 집중할 수 있게 되었습니다.

기술을 넘어 문화로

Log Center는 단순한 기술 도입을 넘어, 조직의 데이터 활용 방식을 바꾸는 기반이 되었습니다. 모든 직군이 신뢰할 수 있는 하나의 기준을 함께 바라보게 되면서, 부서와 직군 사이의 소통 장벽도 자연스럽게 낮아졌습니다. 공통의 맥락과 언어가 생기자 업무를 설명하고 조율하는 비용은 줄었고, 데이터의 통일성과 정합성, 신뢰도를 바탕으로 협업 효율도 함께 높아졌습니다.

이제 데이터를 설계하는 일에는 기술적인 숙련도만이 아니라, 비즈니스 맥락을 데이터 구조에 담아내는 시야도 함께 필요해졌습니다. 로그 관리는 더 이상 기술적인 과제를 해결하는 데 그치지 않습니다. 데이터를 조직의 핵심 자산으로 만들어가는 일이며, 동시에 함께 일하는 방식을 바꾸는 일이기도 합니다.

저희는 로그를 통해 서비스의 성장을 기록하고, 잘 정의된 명세를 통해 구성원과 AI가 이해할 수 있는 언어를 만들어가고 있습니다. 하나하나의 기록은 작고 흩어진 흔적일 수 있지만, 그것이 일관된 기준 아래 쌓일 때 더 나은 판단과 다음의 방향을 만드는 기반이 됩니다. 로그가 모두의 업무 흐름 안에서 자연스럽게 쓰이는 공통 언어가 되도록, 저희 팀의 여정은 앞으로도 계속될 것입니다.