AI와 함께하는 프로젝트 자동화 : 더 빠르고, 더 스마트하게 (새 탭에서 열림)

네이버 엔지니어링 데이에서 발표된 이 내용은 로컬 LLM인 Ollama와 오픈소스 mcp-agent를 활용하여 프로젝트 자동화의 수준을 한 단계 높인 실무 사례를 다룹니다. 빌드 실패 분석부터 크래시 로그 요약, Slack 알림까지의 과정을 AI가 스스로 판단하고 수행하는 '협력자'로서의 모델을 제시하며, 이를 통해 개발자가 반복적인 모니터링 업무에서 벗어나 고차원적인 문제 해결에 집중할 수 있음을 보여줍니다. **로컬 기반 LLM 및 에이전트 활용 아키텍처** - Ollama를 활용하여 로컬 환경에 LLM을 구축함으로써 사내 보안 문제를 해결하고 데이터 유출 걱정 없이 분석 환경을 조성합니다. - 오픈소스인 mcp-agent(Model Context Protocol)를 도입하여 AI 모델이 단순한 텍스트 생성을 넘어 외부 도구 및 데이터와 실시간으로 상호작용하도록 설계합니다. - 단순 스크립트 기반 자동화와 달리, AI 에이전트가 상황을 인지하고 적절한 도구를 선택해 작업을 수행하는 유연한 워크플로우를 구현합니다. **지능형 빌드 실패 분석 및 크래시 모니터링** - 빌드 과정에서 발생하는 방대한 양의 에러 로그를 AI가 즉시 분석하여 실패의 근본 원인을 파악하고 요약합니다. - 앱 실행 중 발생하는 크래시 로그를 실시간으로 모니터링하고, 코드 변경 이력 등을 대조하여 해당 문제를 해결하기에 가장 적합한 담당자(Assignee)를 자동으로 매칭합니다. - 비정형 데이터인 로그 메시지를 의미론적으로 해석함으로써 기존 키워드 매칭 방식의 한계를 극복합니다. **Slack 연동을 통한 자동화된 리포팅 체계** - AI가 분석한 빌드 결과와 크래시 요약 내용을 Slack API를 통해 개발 팀 채널에 실시간으로 공유합니다. - 리포트에는 단순히 에러 메시지만 전달하는 것이 아니라, AI가 제안하는 해결 방안과 우선순위 등을 포함하여 팀의 의사결정 속도를 높입니다. - Slack 내에서 LLM과 대화하며 추가적인 로그 분석이나 세부 사항을 질의할 수 있는 대화형 자동화 환경을 제공합니다. **AI 자동화 도입 시 고려사항 및 한계** - LLM과 MCP의 조합이 강력하지만 모든 문제를 해결하는 만능 도구는 아니며, 결과값의 할루시네이션(환각 현상)에 대한 검증 프로세스가 병행되어야 합니다. - 자동화가 복잡해질수록 AI가 도구를 잘못 선택하거나 잘못된 분석을 내놓을 가능성이 있으므로, 단계적인 도입과 신뢰도 테스트가 필수적입니다. **실용적인 제언** 로컬 LLM을 활용한 자동화는 보안이 중요한 사내 프로젝트에서 비정형 데이터 분석 업무를 획기적으로 줄여줍니다. 특히 MCP와 같은 최신 프로토콜을 적극적으로 활용하여 LLM이 실제 개발 도구들과 긴밀하게 연결될 수 있도록 설계하는 것이 성공적인 AI 자동화 도입의 핵심입니다.

@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기 (새 탭에서 열림)

웹 애플리케이션에서 하나의 HTTP 요청 내에 발생하는 중복된 API 호출은 성능 저하와 리소스 낭비를 초래하며, 이를 해결하기 위해 요청 범위(Request Scope) 내에서 결과를 캐싱하는 `@RequestCache` 커스텀 애너테이션을 개발했습니다. 이 기능은 Spring의 `RequestAttribute`를 활용해 요청별로 독립적인 캐시 공간을 보장하며, 요청 종료 시 자동으로 메모리가 정리되는 효율적인 생명주기 관리 구조를 가집니다. 이를 통해 복잡한 파라미터 전달이나 부적절한 TTL 설정 문제를 해결하고 시스템의 전반적인 응답 속도를 개선할 수 있습니다. ### 파라미터 전달 및 범용 캐시의 한계 * **응답 객체 전달 방식의 복잡성**: 데이터를 실제 사용하는 말단 서비스까지 객체를 넘기기 위해 중간 계층의 모든 메서드 시그니처를 수정해야 하며, 이는 코드 가독성을 떨어뜨리고 관리를 어렵게 만듭니다. * **전략 패턴의 유연성 저하**: 공통 인터페이스를 사용하는 경우, 특정 구현체에서만 필요한 데이터를 파라미터에 포함해야 하므로 인터페이스의 범용성이 훼손됩니다. * **TTL(Time To Live) 설정의 딜레마**: Redis나 로컬 캐시 사용 시 TTL이 너무 짧으면 동일 요청 내 중복 호출을 막지 못하고, 너무 길면 서로 다른 요청 간에 의도치 않은 데이터 공유가 발생하여 데이터 정합성 문제가 생길 수 있습니다. ### @RequestCache의 특징과 동작 원리 * **RequestAttribute 기반 저장소**: 내부적으로 `ThreadLocal`을 사용하는 `RequestAttribute`에 데이터를 저장하여, 스레드 간 격리를 보장하고 각 HTTP 요청마다 독립적인 캐시 인스턴스를 유지합니다. * **자동 생명주기 관리**: 캐시의 수명이 HTTP 요청의 생명주기와 일치하므로 별도의 만료 시간을 계산할 필요가 없으며, 요청 완료 시 Spring의 `FrameworkServlet`에 의해 자동으로 정리되어 메모리 누수를 방지합니다. * **AOP 기반의 간편한 적용**: 비즈니스 로직을 수정할 필요 없이 캐싱이 필요한 메서드에 `@RequestCache` 애너테이션을 선언하는 것만으로 손쉽게 중복 호출을 제거할 수 있습니다. ### @RequestScope와 프록시 메커니즘 * **프록시 패턴 활용**: `@RequestScope`로 선언된 빈은 Spring 컨테이너에 프록시 객체로 등록되며, 실제 메서드 호출 시점에 현재 요청에 해당하는 실제 인스턴스를 찾아 호출을 위임합니다. * **상태 저장 방식**: `AbstractRequestAttributesScope` 클래스를 통해 실제 객체가 `RequestAttributes` 내에 저장되며, 이를 통해 동일 요청 내에서는 같은 인스턴스를 공유하게 됩니다. 동일 요청 내에서 외부 API 호출이 잦거나 복잡한 연산이 반복되는 서비스라면, 전역 캐시를 도입하기 전 `@RequestCache`와 같은 요청 범위 캐싱을 통해 코드 순수성을 유지하면서도 성능을 최적화할 것을 권장합니다.

이건 첫 번째 클릭! 히트맵 같이 보기 (새 탭에서 열림)

네이버 통합검색은 방대한 클릭 로그를 히트맵과 히스토그램으로 시각화하여 사용자의 행동 패턴을 직관적으로 분석하고 있습니다. 단순한 정량적 수치를 넘어 시각적 데이터를 활용함으로써 서비스 개선을 위한 구체적이고 객관적인 근거를 확보하는 것이 핵심입니다. 이를 통해 빠르게 변화하는 검색 서비스 환경에서도 사용자 중심의 최적화된 UX를 도출하는 기술적 노하우를 공유합니다. **히트맵과 히스토그램을 통한 데이터 시각화** * 클릭 로그를 히트맵 형태로 변환하여 사용자가 페이지 내 어느 요소에 가장 많이 반응하고 어디에서 이탈하는지 시각적으로 즉각 파악합니다. * 히스토그램을 활용해 단순 클릭 횟수뿐만 아니라 데이터의 분포와 흐름을 분석하여 사용자 행동의 맥락을 이해합니다. * 숫자로만 이루어진 정량적 데이터의 한계를 극복하고, 서비스 개선을 위한 직관적인 인사이트를 제공합니다. **동적 검색 서비스 대응 및 인프라 구축** * 실시간으로 변화하고 고도화되는 네이버 통합검색 환경에 맞춰 클라이언트 로그를 수집하고 시각화하는 FE 인프라 기술을 적용했습니다. * 다양한 UI 구성 요소와 서비스 변화 속에서도 시각화 데이터의 정확성을 유지하기 위해 겪은 시행착오와 해결 방안을 포함합니다. * 웹 페이지 내 사용자 소비 방식을 정밀하게 확인하고 싶은 개발자와 기획자를 위해 기술적 구현 방법론을 제시합니다. 데이터 분석 결과가 실제 서비스 개선으로 이어지기 위해서는 수치 뒤에 숨겨진 사용자의 의도를 읽어내는 것이 중요합니다. 시각적 분석 도구를 활용하면 데이터 해석의 격차를 줄이고, 팀 구성원 모두가 공감할 수 있는 서비스 개선 방향을 설정하는 데 큰 도움이 될 것입니다.

DBT, Airflow를 활용한 데이터 계보 중심 파이프라인 만들기 (새 탭에서 열림)

네이버웹툰은 기존 데이터 파이프라인에서 발생하던 복잡한 데이터 적재(Backfill) 작업과 높은 운영 비용 문제를 해결하기 위해 DBT와 Airflow를 결합한 'Flow.er' 시스템을 구축했습니다. Flow.er는 데이터 간의 의존성을 명확히 정의하는 데이터 계보(Lineage)를 중심으로 설계되어, 엔지니어가 데이터의 흐름을 온디맨드로 파악하고 관리할 수 있게 돕습니다. 이를 통해 데이터 품질을 높이는 동시에 여러 데이터 조직으로 확장 가능한 고도화된 데이터 플랫폼으로 발전하고 있습니다. **과거 파이프라인의 한계와 Flow.er의 탄생** * 과거에는 파이프라인 복구와 수동 백필 작업에 과도한 운영 리소스가 소모되어 업무 효율이 저하되는 문제가 있었습니다. * 데이터 간의 복잡한 연결 고리를 한눈에 파악하기 어려워 데이터 정합성을 유지하고 장애에 대응하는 데 한계가 존재했습니다. * 이러한 문제를 극복하기 위해 데이터 계보를 가시화하고 자동화된 운영이 가능한 'Flow.er' 서비스에 대한 PoC를 거쳐 실무에 도입했습니다. **DBT와 Airflow를 활용한 계보 중심 아키텍처** * **DBT의 역할**: SQL 기반의 데이터 모델링을 통해 데이터 변환 로직을 관리하며, 모델 간 의존성을 바탕으로 데이터 계보와 관련 문서(Documentation)를 자동 생성합니다. * **Airflow의 역할**: DBT로 정의된 모델들이 선후 관계에 맞춰 정확히 실행되도록 워크플로우를 오케스트레이션하고 스케줄링을 담당합니다. * **개발 생산성 향상**: 개인 인스턴스를 제공하여 개발자가 격리된 환경에서 모델을 테스트할 수 있게 하고, CI/CD 파이프라인을 통해 코드 변경 사항을 안전하게 배포합니다. **시스템 안정성 및 확장을 위한 컴포넌트** * **Playground & Tower**: 자유로운 데이터 실험을 위한 샌드박스 환경인 Playground와 파이프라인 상태를 실시간으로 감시하는 Tower를 통해 운영 가시성을 확보했습니다. * **Partition Checker**: 상위 데이터 소스의 파티션 생성 여부를 사전에 체크하여 데이터 누락을 방지하고 적재 정합성을 획기적으로 개선했습니다. * **Manager DAG System**: 수많은 데이터 모델과 DAG를 효율적으로 관리하기 위해 관리 전용 시스템을 개선하여 운영 편의성을 극대화했습니다. **Flow.er의 미래와 기술적 지향점** * **MCP(Model Context Protocol) 서버**: 데이터 모델의 컨텍스트를 외부 도구나 AI 에이전트가 이해할 수 있는 규격으로 제공하여 데이터 활용도를 높일 예정입니다. * **AI Agent 연동**: 단순한 파이프라인 운영을 넘어 AI가 데이터 계보를 분석하고 문제를 해결하거나 코드를 최적화하는 단계로의 발전을 준비하고 있습니다. 데이터 파이프라인의 복잡성으로 인해 백필과 운영에 고통받고 있다면, DBT를 활용해 계보를 명확히 정의하고 이를 Airflow와 유기적으로 연결하는 접근 방식이 필수적입니다. 데이터 계보 중심의 아키텍처는 단순한 자동화를 넘어 데이터 프로덕트의 신뢰성을 담보하는 가장 강력한 수단이 될 것입니다.

[AI_TOP_100] 문제 출제 후기 – 기술이 아닌, 사람을 묻다. - tech.kakao.com (새 탭에서 열림)

AI 기술이 비약적으로 발전하는 시대에 도구를 다루는 인간의 실제 문제 해결 역량을 측정하기 위해 ‘AI TOP 100’ 경진대회가 기획되었습니다. 단순히 AI를 사용하는 수준을 넘어, 인간과 AI의 긴밀한 협업 과정을 통해 복잡한 현실 문제를 해결하고 최적의 의사결정을 내리는 ‘문제 해결자’를 선별하는 데 초점을 맞추었습니다. 결과물뿐만 아니라 AI의 한계를 인간의 통찰로 보완해 나가는 '과정' 자체를 핵심 평가 지표로 삼은 것이 이번 대회의 결론입니다. **AI와 인간의 협업 루프(Human-in-the-loop) 설계** * 단순히 문제를 복사하여 붙여넣는 방식으로는 해결할 수 없도록, 사람의 분석과 AI의 실행, 그리고 다시 사람의 검증이 순환되는 구조를 지향했습니다. * 사람은 직관적으로 파악하지만 AI는 분석하기 어려운 데이터 구조(식단표, 복잡한 표의 행/열 관계 등)를 제공하여 인간의 사전 가이드가 성능을 좌우하게 설계했습니다. * 이미지 생성과 피드백 분석, 프롬프트 개선 과정을 에이전트에게 위임하여 자동화 파이프라인을 구축하는 등 고도화된 협업 능력을 측정했습니다. **'딸깍' 방지를 위한 입체적인 난이도 설계** * 최신 AI 모델이 단 한 번의 프롬프트(One-shot)로 정답을 맞히지 못하도록 의도적인 기술적 제약과 논리적 미로를 문제 속에 배치했습니다. * '낮은 진입 장벽과 높은 천장' 원칙에 따라, 초보자도 쉽게 접근할 수 있는 시작 문항부터 깊은 통찰이 필요한 킬러 문항까지 '난이도 사다리' 구조를 도입했습니다. * 특정 프레임워크에 국한되지 않고 출제자가 예상치 못한 창의적인 방식으로도 문제를 해결할 수 있는 열린 구조를 유지했습니다. **현실의 복잡성을 반영한 4가지 문제 패턴** * **분석 및 정의(Insight):** 정답이 없는 복합 데이터 속에서 유의미한 문제나 기회를 스스로 발견하는 역량을 평가합니다. * **구현 및 자동화(Action):** 정의된 문제를 해결하기 위해 AI 솔루션을 실제 작동하는 코드나 워크플로로 구현하는 능력을 측정합니다. * **전략 및 창의(Persuasion):** 기술적 솔루션을 비기술 이해관계자에게 설득력 있게 전달하기 위한 논리와 창의적 콘텐츠 생성 능력을 확인합니다. * **최적화 및 의사결정(Decision):** 제약 조건 하에서 목표를 최대화하는 최적의 의사결정 시뮬레이션을 수행합니다. **엄격한 검증을 거친 문제 고도화 파이프라인** * 아이디어 단계부터 최종 확정까지 4단계의 파이프라인을 구축하고, 출제위원 내부 테스트 및 알파·베타 테스트를 통해 문제의 신뢰도를 검증했습니다. * AI 모델이 매일 업데이트되어 어제의 난제가 오늘의 쉬운 문제가 되는 환경에 대응하기 위해 지속적인 실증 테스트를 반복했습니다. * 문제의 겉보기 난이도가 아니라 실제 해결에 필요한 노력 비용을 기준으로 점수를 재조정하는 '캘리브레이션' 과정을 거쳐 변별력을 확보했습니다. AI 시대의 진정한 경쟁력은 도구의 기능을 단순히 암기하는 것이 아니라, AI의 한계를 명확히 이해하고 이를 인간의 기획력으로 보완하여 실질적인 가치를 만들어내는 데 있습니다. 이번 출제 후기는 기술보다 '그 기술을 다루는 사람'의 사고방식이 더 중요하다는 점을 강조하며, 앞으로의 AI 리터러시 교육과 평가가 나아가야 할 방향을 제시합니다.

Zoomer: 지능형 디 (새 탭에서 열림)

Meta는 수십만 개의 GPU를 운용하는 대규모 AI 인프라의 효율성을 극대화하기 위해 자동화된 디버깅 및 최적화 플랫폼인 **Zoomer**를 도입했습니다. Zoomer는 트레이닝과 추론 워크로드 전반에 걸쳐 심층적인 성능 인사이트를 제공하여 에너지 소비를 줄이고 워크플로우를 가속화하는 역할을 합니다. 이를 통해 Meta는 모델 트레이닝 시간을 단축하고 초당 쿼리 처리 수(QPS)를 유의미하게 개선하며 AI 인프라 최적화의 표준을 구축했습니다. **통합 분석을 위한 3계층 아키텍처** * **인프라 및 플랫폼 계층**: Meta의 블롭 스토리지 플랫폼인 Manifold를 기반으로 분산 저장 시스템을 구축하여, 수천 대의 호스트에서 발생하는 방대한 트레이스 데이터를 안정적으로 수집하고 처리합니다. * **분석 및 인사이트 엔진**: Kineto와 NVIDIA DCGM을 통한 GPU 분석, StrobeLight 기반의 CPU 프로파일링, dyno 원격 측정을 통한 호스트 지표 분석을 결합합니다. 이를 통해 분산 학습 시 발생하는 스트래글러(straggler) 감지, 메모리 할당 패턴 분석, 통신 패턴 최적화 등의 기능을 수행합니다. * **시각화 및 UI 계층**: 복잡한 성능 데이터를 직관적인 타임라인, 히트맵, 대시보드로 변환합니다. Perfetto와 통합되어 커널 수준의 검사가 가능하며, 하드웨어 활용도가 낮은 outlier를 신속하게 식별할 수 있는 요약 정보를 제공합니다. **지능형 프로파일링 트리거 및 데이터 수집** * **자동화된 트리거**: 트레이닝 워크로드의 경우 초기 시작 시점의 노이즈를 피해 안정적인 상태인 550~555회 반복(iteration) 시점에서 자동으로 프로파일링을 수행합니다. 추론 워크로드는 온디맨드 방식이나 자동화된 부하 테스트 시스템과 연동하여 트리거됩니다. * **포괄적 데이터 캡처**: SM 활용도, 텐서 코어 가동률, GPU 메모리 대역폭 등 하위 레벨 지표뿐만 아니라 CPU, 네트워크 I/O, 스토리지 액세스 패턴을 동시에 수집하여 시스템 전반의 병목 현상을 파악합니다. * **추론 및 통신 특화 분석**: 추론 환경에서는 서버 레이턴시와 요청당 메모리 할당 패턴을 정밀 분석하며, 분산 학습 환경에서는 NCCL 집합 통신 작업과 노드 간 통신 효율성을 집중적으로 검사합니다. **실제 적용 성과 및 운영 효율화** * Zoomer는 광고 추천, 생성형 AI(GenAI), 컴퓨터 비전 등 Meta의 핵심 모델 서비스에 적용되어 매일 수만 개의 프로파일링 보고서를 생성하고 있습니다. * 성능 안티 패턴을 자동으로 감지하고 실행 가능한 최적화 권고 사항을 제공함으로써, 엔지니어가 수동으로 병목 지점을 찾는 데 드는 시간을 대폭 줄였습니다. * 불필요한 리소스 낭비를 제거하여 확보된 컴퓨팅 자원을 더 큰 모델 트레이닝이나 사용자 서비스 확대에 재투자함으로써 인프라 전반의 선순환 구조를 실현했습니다. Zoomer는 대규모 GPU 클러스터를 운영하는 조직에서 성능 튜닝을 자동화하고 표준화하는 것이 얼마나 중요한지를 보여주는 사례입니다. 인프라의 1% 효율 개선이 막대한 비용 절감과 혁신 가속화로 이어지는 만큼, Zoomer와 같은 통합 최적화 플랫폼은 생성형 AI 시대의 핵심 인프라 기술로 평가받습니다.

코드 품질 개선 기법 24편: 유산의 가치 (새 탭에서 열림)

코드에서 로직은 동일하고 단순히 값만 달라지는 경우, 인터페이스와 상속을 사용하는 대신 데이터 클래스와 인스턴스 생성을 활용하는 것이 더 효율적입니다. 상속은 동적 디스패치나 의존성 역전과 같은 특정한 목적이 있을 때 강력한 도구가 되지만, 단순한 값의 차이를 표현하기 위해 사용하면 불필요한 복잡성을 초래할 수 있습니다. 따라서 객체의 속성 값만 변경되는 상황이라면 상속 불가능한 클래스를 정의하고 값만 다른 인스턴스를 만들어 사용하는 것이 코드의 가독성과 예측 가능성을 높이는 지름길입니다. **상속이 과용되는 사례와 문제점** * UI 테마(색상, 아이콘 등)를 적용할 때 인터페이스를 정의하고 각 테마(Light, Dark)별로 클래스를 상속받아 구현하는 방식은 흔히 발견되는 과잉 설계의 예시입니다. * 바인딩 로직이 모든 테마에서 동일함에도 불구하고 상속을 사용하면, 각 하위 클래스가 자신만의 고유한 로직을 가질 수 있다는 가능성을 열어두게 되어 코드 추적을 어렵게 만듭니다. * 특히 단순히 속성 값을 반환하는 목적일 때는 인터페이스를 통한 동적 디스패치가 성능상 미미한 오버헤드를 발생시킬 뿐만 아니라 구조를 복잡하게 만듭니다. **상속을 사용해야 하는 정당한 경우** * **로직의 동적 변경:** 상황에 따라 실행 시점에 로직 자체를 갈아끼워야 하는 동적 디스패치가 필요할 때 사용합니다. * **합 타입(Sum Types) 구현:** Kotlin의 `sealed class`처럼 정해진 하위 타입들의 집합을 정의해야 할 때 유용합니다. * **추상화와 구현의 분리:** 프레임워크의 제약 조건 대응, 의존성 주입(DI), 또는 빌드 속도 향상을 위해 인터페이스가 필요할 때 활용합니다. * **의존성 역전 법칙(DIP) 적용:** 순환 의존성을 해결하거나 의존성 방향을 단방향으로 유지해야 할 때 상속과 인터페이스를 사용합니다. **인스턴스 기반 모델링의 이점** * 인터페이스 대신 모든 속성을 포함하는 단일 클래스(Model)를 정의하고, 각 테마를 이 클래스의 인스턴스로 생성하면 구조가 훨씬 간결해집니다. * Kotlin의 기본 클래스처럼 상속이 불가능한(`final`) 클래스로 정의할 경우, 해당 인스턴스에 고유한 로직이 포함되지 않았음을 보장할 수 있습니다. * 속성 값이 변하지 않는다면 각 인스턴스는 데이터의 묶음으로서만 존재하게 되어, 상태 변화나 로직의 부수 효과를 걱정할 필요 없이 안전하게 재사용할 수 있습니다. 단순히 값만 다른 여러 타입을 구현해야 한다면 먼저 "상속이 반드시 필요한 로직의 차이가 있는가?"를 자문해 보시기 바랍니다. 로직이 같다면 클래스 상속보다는 데이터 모델의 인스턴스를 생성하는 방식이 유지보수하기 훨씬 쉬운 코드를 만들어줍니다.

Central Dogma 컨트롤 플레인으로 LY Corporation의 수천 개 서비스를 연결하기 (새 탭에서 열림)

LY Corporation은 수천 개의 서비스를 효율적으로 연결하기 위해 Central Dogma를 활용한 통합 컨트롤 플레인(Control Plane)을 구축했습니다. 기존 레거시 시스템의 한계를 극복하고 xDS 표준 프로토콜을 도입함으로써, 물리 서버(PM), 가상 머신(VM), 쿠버네티스(K8s)를 아우르는 유연한 서비스 메시 환경을 구현했습니다. 이 시스템은 GitOps 기반의 설정 관리와 사이드카 없는(Sidecar-less) 아키텍처 지원을 통해 개발자 경험과 시스템 성능을 동시에 향상시키는 성과를 거두었습니다. ### 레거시 시스템의 한계와 새로운 요구사항 * **타이트한 결합과 동적 등록의 부재:** 기존 시스템은 특정 프로젝트 관리 도구(PMC)에 강하게 의존하고 있어 서비스의 동적인 변경사항을 즉각적으로 반영하기 어려웠습니다. * **상호 운용성 부족:** 자체 커스텀 메시지 스키마를 사용했기 때문에 Envoy나 다른 오픈소스 에코시스템과의 통합이 제한적이었습니다. * **제한적인 트래픽 제어:** 단순한 레지스트리 역할에 치중되어 있어 서킷 브레이커, 카나리 배포, 세밀한 로드 밸런싱 등 현대적인 컨트롤 플레인 기능을 수행하기에 부족함이 있었습니다. ### Central Dogma 컨트롤 플레인의 설계 및 구현 * **xDS 프로토콜 표준화:** 업계 표준인 xDS 프로토콜을 채택하여 Envoy 프록시 및 gRPC 클라이언트와 원활하게 통신할 수 있는 기반을 마련했습니다. * **GitOps 기반 관리:** Central Dogma의 Git 기반 저장소 특성을 활용해 설정 변경 사항을 버전 관리하고, 외부 Git 저장소(GitHub 등)와의 미러링을 통해 안전하게 설정을 배포합니다. * **하이브리드 인프라 지원:** PM, VM 환경의 레거시 데이터와 K8s의 엔드포인트를 모두 수용할 수 있도록 플러그인 구조를 설계하여 통합적인 엔드포인트 관리를 가능케 했습니다. * **고신뢰성 및 인증:** 다중 데이터센터 복제를 통해 가용성을 확보하고, 강력한 인증 시스템을 통합하여 보안성을 강화했습니다. ### 사이드카 없는 서비스 메시(Sidecar-less Service Mesh) * **리소스 및 복잡성 해결:** 일반적인 서비스 메시에서 발생하는 사이드카 프록시의 리소스 오버헤드와 운영 복잡성을 줄이기 위해 Proxyless 방식을 도입했습니다. * **라이브러리 수준의 통합:** gRPC 및 Armeria 라이브러리를 사용하여 애플리케이션이 컨트롤 플레인과 직접 xDS로 통신하게 함으로써 사이드카 없이도 서비스 메시의 이점을 누릴 수 있게 했습니다. * **효율적인 통신 제어:** 별도의 프록시 계층을 거치지 않고도 클라이언트 사이드 로드 밸런싱, 자동 재시도, 존 인식 라우팅(Zone-aware routing) 등을 직접 수행하여 성능을 최적화했습니다. 대규모 인프라에서 수천 개의 서비스를 연결해야 한다면, xDS와 같은 표준 프로토콜을 준수하면서도 기존에 검증된 구성 관리 도구(Central Dogma 등)를 컨트롤 플레인으로 확장하는 전략이 유효합니다. 특히 운영 효율성과 성능이 중요하다면 사이드카 없는 방식의 서비스 메시 도입을 적극적으로 고려해 볼 만합니다.

메신저에 도입된 키 투 (새 탭에서 열림)

메타(Meta)는 메신저의 종단간 암호화(E2EE) 보안을 한 단계 강화하기 위해 '키 투명성(Key Transparency)' 시스템을 도입했습니다. 이 시스템은 사용자가 대화 상대의 공개 키가 변조되지 않았음을 자동으로 검증할 수 있게 하여, 메타를 포함한 그 누구도 중간에서 메시지를 가로챌 수 없도록 보장하는 강력한 신뢰 계층을 제공합니다. **키 투명성의 개념과 사용자 편의성** * 키 투명성은 메시지 암호화에 사용되는 공개 키의 변경 이력을 누구나 확인하고 감사할 수 있도록 기록하는 시스템입니다. * 기존에는 사용자가 보안 코드를 직접 비교하는 수동 검증 방식이 있었으나, 여러 기기를 사용하거나 기기를 교체할 때마다 매번 확인해야 하는 번거로움이 있었습니다. * 새로운 시스템은 이러한 검증 과정을 자동화하여, 사용자가 복잡한 절차 없이도 자신의 대화가 올바른 키로 암호화되고 있음을 확신할 수 있게 합니다. **신뢰성 확보를 위한 외부 감사 아키텍처** * 메타는 자사의 AKD(Auditable Key Directory) 라이브러리를 활용하여 키를 안전하게 배포하고 관리합니다. * 시스템의 객관성을 높이기 위해 클라우드플레어(Cloudflare)를 독립적인 외부 감사자(Auditor)로 지정했습니다. * 클라우드플레어는 키 투명성 대시보드를 통해 실시간 로그를 유지하며, 이를 통해 누구나 키 배포 과정이 투명하게 이루어지고 있는지 직접 확인할 수 있습니다. **대규모 데이터 처리를 위한 기술적 최적화** * 메신저의 방대한 규모로 인해 약 2분마다 수십만 개의 새로운 키가 추가되며, 현재 데이터베이스에는 이미 수십억 개의 키 항목이 저장되어 있습니다. * 데이터가 기하급수적으로 늘어나는 상황에서도 빠른 검증을 유지하기 위해, 키 버전이 증가해도 증명(Proof) 데이터의 크기가 일정 수준을 유지하도록 알고리즘 효율성을 대폭 개선했습니다. * 과거 트리 높이에 따라 선형적으로 증가하던 증명 크기 문제를 해결하여, 수십억 개의 노드가 존재하는 트리 구조에서도 실시간 조회가 가능하도록 최적화했습니다. * 왓츠앱(WhatsApp)의 키 투명성 운영 경험을 바탕으로, 일시적인 장애 상황에서도 데이터 순서가 뒤섞이지 않고 신속하게 복구될 수 있는 인프라 탄력성을 확보했습니다. 이 기능은 현재 메신저의 1:1 채팅에 적용되어 있으며, 사용자들은 별도의 설정 없이도 자동화된 보안 검증의 혜택을 누릴 수 있습니다. 보안에 민감한 사용자라면 클라우드플레어의 공개 대시보드를 통해 시스템의 무결성을 직접 모니터링해 보는 것을 추천합니다.

전기차 주행 거리 불안 (새 탭에서 열림)

구글 리서치는 전기차 운전자의 '주행거리 불안(range anxiety)'을 해소하기 위해 특정 시간 후의 충전 포트 가용성을 예측하는 경량화된 AI 모델을 개발했습니다. 이 모델은 복잡한 신경망 대신 단순한 선형 회귀(Linear Regression) 방식을 채택하여 짧은 지연 시간과 높은 효율성을 동시에 달성했습니다. 연구진은 직관적인 실세계 논리와 머신러닝을 결합함으로써, 충전소의 현재 상태를 단순히 유지하는 기존의 강력한 기준 모델보다 더 정확한 예측이 가능함을 입증했습니다. ## 단순하고 효율적인 선형 회귀 모델 설계 * **모델 선택의 이유**: 의사결정 나무(Decision Tree)나 심층 신경망 등 다양한 구조를 테스트했으나, 가장 성능이 우수하고 견고한 것은 단순 선형 회귀 모델이었습니다. 이는 배포 인프라와의 공동 설계를 통해 속도와 예측력을 모두 잡기 위함입니다. * **데이터 샘플링**: 캘리포니아와 독일 지역의 실시간 데이터를 활용해 훈련되었으며, 교통량이 많고 실사용 사례를 더 잘 반영하는 대형 충전소를 우선적으로 포함했습니다. * **경량 피처 활용**: 예측 속도를 극대화하기 위해 피처 세트를 최소화했으며, 사용자가 도달할 시점의 예상 가용 포트 수를 즉각적으로 계산합니다. ## 시간 기반 가중치를 통한 점유율 변화 예측 * **시간 피처(Hour Feature)**: 하루의 각 시간을 개별 피처(예: 오전 9시, 오후 5시 등)로 처리하여 시간대별 운전자의 행동 패턴을 반영합니다. * **가중치(Weights)의 의미**: 선형 회귀를 통해 학습된 가중치는 포트 점유율의 변화율을 나타냅니다. 양수 가중치는 해당 시간에 점유율이 증가함을, 음수 가중치는 점유율이 감소(포트가 비워짐)함을 의미합니다. * **예측 논리**: 모델은 단순히 현재 상태를 보여주는 것이 아니라, 현재 가용 포트 수에 시간별 가중치를 더해 미래 시점의 가용성을 산출합니다. 특히 출퇴근 시간처럼 변화가 급격한 시점에 유의미한 예측값을 제공합니다. ## 성능 검증 및 벤치마크 결과 * **강력한 베이스라인과의 비교**: '현재 상태 유지(Keep Current State)' 모델을 대조군으로 설정했습니다. 일반적으로 30분 이내에 상태가 변하는 포트는 10% 미만이기에 이를 능가하는 것은 매우 어려운 과제입니다. * **평가 지표**: 평균 제곱 오차(MSE)와 평균 절대 오차(MAE)를 사용하여 정확도를 측정했습니다. 특히 '최소 한 개의 포트가 비어있을 것인가'라는 실질적인 질문에 답하기 위해 이진 분류 성능도 평가했습니다. * **실전 성과**: 30분 및 60분 후를 예측하는 실험에서, 제안된 모델은 점유율 변동이 빈번한 결정적인 순간들을 정확히 포착하여 베이스라인보다 향상된 성능을 보여주었습니다. ## 실용적 결론 이 연구는 복잡한 AI 모델이 항상 최선은 아니라는 점을 시사합니다. 충전소 가용성 예측과 같이 실시간 응답이 중요하고 피처가 단순한 도메인에서는 선형 회귀 모델만으로도 충분히 강력한 성능을 낼 수 있습니다. 전기차 내비게이션 시스템에 이 모델을 통합하면 운전자는 경로상의 충전소에 도착했을 때 실제 충전 가능 여부를 더 높은 확률로 신뢰할 수 있게 되어, 전반적인 주행 경험이 개선될 것으로 기대됩니다.

서비스 조직에서 Kafka를 사용할 때 알아 두어야 할 것들 (5) (새 탭에서 열림)

Apache Kafka의 차세대 소비자 그룹 프로토콜(Consumer Group Protocol v2)은 기존 v1 프로토콜이 가진 리밸런싱 성능의 한계와 복잡성을 근본적으로 해결하기 위해 도입되었습니다. 새로운 프로토콜은 리밸런싱 로직의 주체를 클라이언트에서 서버(Broker)로 옮겨 전체적인 시스템 안정성을 높였으며, 대규모 클러스터 운영 시 발생하던 중단 시간을 획기적으로 단축했습니다. 이 글은 네이버의 실무 경험을 바탕으로 v2의 주요 특징과 성능 개선 사항, 그리고 안정적인 마이그레이션 전략을 제시합니다. **기존 Consumer Group Protocol v1의 문제점** * **Stop-the-world 리밸런싱:** 리밸런싱이 발생하면 모든 컨슈머가 데이터 처리를 멈추고 파티션을 재할당받아야 하므로 일시적인 처리 지연이 불가피했습니다. * **클라이언트 측의 과도한 부담:** 리밸런싱 로직이 컨슈머 클라이언트에 포함되어 있어, 클라이언트 수가 늘어날수록 통신량과 계산 복잡도가 급증하는 구조적 한계가 있었습니다. * **디버깅의 어려움:** 리밸런싱 과정이 복잡하고 클라이언트별로 상태가 달라 문제 발생 시 원인 파악과 모니터링이 까다로웠습니다. **Consumer Group Protocol v2의 핵심 특징과 장점** * **서버 중심 리밸런싱:** 그룹 코디네이터(Broker)가 파티션 할당 로직을 직접 수행하여 클라이언트의 계산 부하를 줄이고 전체 프로세스를 단순화했습니다. * **점진적 협력 리밸런싱:** 모든 컨슈머를 멈추지 않고, 변경이 필요한 파티션만 점진적으로 재할당하여 서비스 가용성을 극대화했습니다. * **하트비트 메커니즘 개선:** 하트비트 응답 내에 리밸런싱 명령을 포함시켜 별도의 JoinGroup/SyncGroup 절차 없이도 빠른 상태 동기화가 가능해졌습니다. **성능 향상 및 운영 효율화** * **확장성 강화:** 수천 개의 파티션과 수백 명의 컨슈머가 참여하는 대규모 그룹에서도 리밸런싱 시간을 일관되게 유지합니다. * **불필요한 리밸런싱 감소:** 컨슈머의 일시적인 네트워크 순단이나 짧은 지연에 대해 보다 유연하게 대응하여 불필요한 그룹 재편성을 방지합니다. * **전용 툴 지원:** 새로운 프로토콜에 최적화된 모니터링 툴과 API를 통해 소비자 그룹의 상태를 더 정밀하게 확인하고 관리할 수 있습니다. **성공적인 마이그레이션 및 설정 가이드** * **호환성 확인:** Kafka 브로커와 클라이언트 버전을 확인하여 v2 프로토콜(KIP-848) 지원 여부를 먼저 점검해야 합니다. * **단계적 도입:** `group.protocol` 설정을 통해 기존 v1과 새로운 v2를 선택적으로 적용할 수 있으며, 개발 환경에서 충분한 검증 후 운영 환경에 반영하는 것이 권장됩니다. * **클라이언트 업데이트:** v2의 이점을 온전히 누리기 위해서는 브로커뿐만 아니라 컨슈머 클라이언트 라이브러리 역시 최신 버전으로 업그레이드해야 합니다. 대규모 트래픽을 처리하며 리밸런싱으로 인한 지연 시간에 민감한 서비스라면 Kafka 3.x 후반대 버전부터 도입된 Consumer Group Protocol v2로의 전환을 적극적으로 검토해야 합니다. 특히 컨슈머 그룹의 규모가 크거나 빈번한 배포가 일어나는 환경일수록 v2 도입을 통한 운영 안정성 향상 효과가 더욱 뚜렷하게 나타날 것입니다.

API 호출식 웜업의 부작용을 넘어서 : 라이브러리만 데우는 JVM 웜업 (새 탭에서 열림)

JVM 기반 웹 애플리케이션은 실행 초기 JIT(Just-In-Time) 컴파일러의 최적화 과정에서 발생하는 응답 지연 문제를 해결하기 위해 '웜업' 과정이 필수적입니다. 기존의 API 호출식 웜업은 데이터 오염이나 외부 시스템 부하와 같은 부작용을 초래할 수 있으나, 본 발표에서는 이를 극복하기 위해 핵심 라이브러리만을 직접 예열하는 '라이브러리 웜업' 방식을 제안합니다. 이 기술을 통해 부작용 없이 애플리케이션 배포 직후의 성능을 안정적으로 확보할 수 있습니다. **JVM 웜업의 필요성과 기존 방식의 한계** * JVM은 실행 초기에 인터프리터 방식으로 동작하다가, 반복되는 코드를 JIT 컴파일러가 네이티브 코드로 최적화하는 과정을 거치며 성능이 올라갑니다. * 이 최적화가 완료되기 전까지는 응답 시간이 길어지거나 CPU 사용량이 급증하는 현상이 발생하므로, 실제 트래픽이 들어오기 전 코드를 미리 실행하는 웜업이 필요합니다. * 기존의 API 호출 방식은 가짜 요청을 보내는 과정에서 DB 데이터 정합성을 해칠 수 있고, 외부 API 호출에 따른 불필요한 연동 부하를 발생시키는 단점이 있습니다. **라이브러리 웜업의 핵심 아이디어와 구현** * 비즈니스 로직 전체를 수행하는 대신, 애플리케이션에서 성능 비중이 크고 공통적으로 사용되는 '라이브러리 코드'만을 타겟팅하여 예열합니다. * 예를 들어 JSON 파싱, 암호화, 복잡한 수치 계산 모듈 등 JIT 컴파일 임계치(Threshold)를 넘겨야 하는 핵심 메서드들을 반복 호출하도록 설계합니다. * 애플리케이션 시작 단계(Post-Construct 등)에서 비즈니스 로직과는 독립된 웜업 코드를 실행함으로써 데이터 오염의 위험을 원천적으로 차단합니다. **성능 검증 및 실무적 이점** * 라이브러리 웜업 적용 후, 배포 초기에 발생하는 응답 속도의 '튀는 현상(Spike)'이 현저히 감소하고 전체적인 레이턴시가 안정화됨을 확인했습니다. * API 호출 방식보다 구현이 단순하고 외부 의존성이 적어 관리가 용이하며, 배포 파이프라인의 안정성을 높이는 데 기여합니다. * 다만, 모든 비즈니스 경로를 커버하지는 못하므로 성능 영향도가 높은 핵심 모듈을 선별하여 집중적으로 웜업하는 전략이 유효합니다. 빠른 스케일 아웃이 필요한 마이크로서비스 환경이나 지연 시간에 민감한 실시간 서비스라면, API 기반 웜업의 대안으로 이와 같은 라이브러리 단위의 정밀한 웜업 도입을 적극 권장합니다.

우리가 진짜 문제를 풀고 있었을까? — POPM 과정이 남긴 질문 - tech.kakao.com (새 탭에서 열림)

카카오의 POPM 교육 과정은 단순한 지식 전달을 넘어, 파편화된 실무 개념을 구조적으로 정리하고 이를 반복 가능한 '문제 해결 루프'로 연결하는 데 집중했습니다. 제품 전략이 팀의 일상적인 실행 지침이 되도록 돕는 이 과정은, 단순한 기능 배포가 아닌 '진짜 문제를 해결하고 있는가'라는 본질적인 질문을 실무에 던지게 합니다. 이를 통해 참가자들은 가설 검증과 지표 분석을 바탕으로 한 데이터 중심의 의사결정 체계를 실무에 직접 이식하는 성과를 거두었습니다. **전략적 사고와 지표의 재발견** * 전략을 거창한 구호가 아닌, 실무 현장에서 팀원들이 판단을 내릴 수 있게 돕는 '판단 기준'으로 재정의하고 MECE, MVP 등의 개념을 맥락에 맞게 재구성했습니다. * 지표를 단순한 데이터가 아니라 제품의 문제를 드러내는 '언어'로 인식하며, 퍼널·리텐션·코호트·LTV 등의 지표가 문제 정의와 어떻게 연결되는지 체득했습니다. * '내가 해석하는 지표가 우리 제품의 본질과 맞는가'라는 관점의 전환을 통해 데이터 해석의 정교함을 높였습니다. **실험 설계와 UX의 본질적 접근** * 실험의 성공 여부보다 '실패한 실험을 해석하는 루틴'을 중시하며, MASS 조건(측정 가능성, 기인 가능성, 민감도, 단기 확인)을 통한 구체적인 실험 체크리스트를 활용합니다. * UX 디자인을 단순한 심미적 요소가 아닌 '사용자 맥락에 기반한 설계'로 정의하고, 카카오 내부 서비스의 실제 사례를 통해 적합한 설계를 스스로 질문하게 유도했습니다. * 작게 시작하는 실험의 중요성을 강조하여 실무에서 즉시 가설을 검증해 볼 수 있는 자신감을 배양했습니다. **실무로 이어지는 실행 구조 설계** * '문제 정의 → 가설 → 지표 → 검증 → 회고'로 이어지는 루틴을 확립하여, 릴리스가 끝이 아닌 학습과 다음 우선순위 설정의 시작이 되도록 변화시켰습니다. * 과제 시작 전 '문제 정의, 기대 행동, 확인 지표'를 명문화하는 템플릿을 도입하고, 사용자 스토리 방식을 통해 팀 전체가 업무의 목적을 공유하도록 했습니다. * 주간 또는 격주 단위로 지표 확인 및 인사이트 공유 시간을 고정하여, 실행이 일시적인 이벤트가 아닌 조직의 습관으로 자리 잡게 했습니다. 프로덕트 매니저는 단순히 기능을 배포하는 것에 만족하지 말고, 배포 이후의 지표 변화가 당초 정의한 문제를 실제로 해결했는지 확인하는 '루프 기반 실행' 구조를 조직 내에 안착시켜야 합니다. "지금 우리가 하고 있는 이 일이 정말 문제 해결을 위한 실행인가?"라는 질문을 끊임없이 던지는 것이 제품 성장의 핵심입니다.

POPM 과정은 어떻게 하나의 ‘제품’이 되었나 - tech.kakao.com (새 탭에서 열림)

카카오의 POPM 교육은 단순한 지식 전달 과정을 넘어, PO와 PM이 공통의 언어로 협업하고 문제를 해결할 수 있도록 돕는 하나의 '제품'으로 설계되었습니다. 교육 과정을 제품 개발 프로세스와 동일하게 '구조화'와 '반복 실험'의 관점에서 접근했으며, 수강생의 피드백을 데이터로 치환하여 지속적으로 기능을 개선하듯 커리큘럼을 고도화했습니다. 결과적으로 이 과정은 전략이 실제 실행으로 이어지도록 만드는 조직 차원의 구조적 프레임워크를 구축하는 성과를 거두었습니다. **POPM 교육의 탄생 배경과 목적** * PO와 PM의 역할이 모호하고 비가시적인 업무가 많아 발생하는 의사결정의 혼선을 줄이기 위해 시작되었습니다. * 문제 정의, 지표 해석, 실험 설계 등 실무에서 반복되는 질문들에 대해 조직이 공유할 수 있는 공통 언어를 수립하는 것이 핵심 목표입니다. * PO의 전략적 고민과 PM의 실행이 단절되지 않고 하나의 목표로 이어질 수 있는 구조적 기틀을 마련하고자 했습니다. **제품 개발 프로세스를 닮은 교육 설계** * 파일럿 과정(1기)의 8개 세션을 시작으로, 매 기수마다 '사용자 피드백'을 반영하여 구조를 최적화했습니다. * 3기부터는 '전략 → 지표 → 실험 → 디자인 → 실행'의 5개 핵심 세션으로 고정하여 흐름을 단순화하고 몰입도를 높였습니다. * 교육 설계자는 PM의 관점에서 교육을 하나의 제품으로, 각 세션을 기능으로, 각 기수를 소프트웨어 버전으로 정의하여 반복 개선을 수행했습니다. **데이터 기반의 기회 점수 도출과 리디자인** * 수강생 대상의 사전/사후 설문을 통해 각 세션의 '중요도'와 '만족도' 매트릭스를 분석했습니다. * 중요도는 높으나 만족도가 낮은 영역(예: 데이터/지표 세션)을 '기회 영역'으로 정의하고, 이를 제품 기능의 우선순위처럼 취급하여 최우선적으로 개선했습니다. * 단순한 내용 수정을 넘어 슬라이드 재구성, 실습 난이도 조정, 워크시트 포맷 변경 등 구조적인 해결책을 적용하여 기회 점수를 관리했습니다. **설계자가 얻은 구조적 인사이트** * 교육은 사람의 변화보다 '구조의 누적'에 집중해야 하며, 시스템이 바뀌지 않으면 동일한 시행착오가 반복된다는 점을 확인했습니다. * 지식의 전달보다 '질문의 리듬'을 설계하는 것이 중요하며, 슬라이드 하나에도 질문과 예시, 흐름을 유기적으로 배치하여 수강생의 사고를 유도했습니다. * 실습의 목적은 정답 작성이 아니라 '생각의 구조화'에 있으며, 실습 과정이 실제 팀의 업무 루틴으로 자연스럽게 이어지도록 설계했습니다. 조직 내 교육이나 프로세스를 설계할 때 이를 하나의 고정된 커리큘럼이 아닌, 지속적으로 개선 가능한 '제품'으로 바라보는 시각이 필요합니다. 수강생을 사용자로 정의하고 그들의 불편함을 데이터로 측정하여 구조를 개선해 나간다면, 교육은 단순한 학습을 넘어 조직의 실행력을 높이는 강력한 도구가 될 수 있습니다.

LTV를 넘어 서비스의 가치를 측정하는 새로운 지표, MTVi (새 탭에서 열림)

토스는 기존 LTV(LifeTime Value) 지표가 가진 긴 측정 주기와 증분 측정의 어려움을 해결하기 위해 MTVi(Mid term Value - incremental)라는 새로운 지표를 도입했습니다. MTVi는 유저가 특정 서비스를 처음 경험했을 때 향후 1년간 발생하는 재무적 순증 가치를 정의하며, 이를 통해 서비스가 플랫폼 전체에 기여하는 진정한 가치를 정량화합니다. 결과적으로 토스는 서비스별 투자 효율을 판단하고 전사적인 의사결정의 우선순위를 정하는 공통의 언어로 이 지표를 활용하고 있습니다. **기존 LTV 지표의 한계와 새로운 지표의 필요성** * LTV는 보통 3~5년의 긴 기간을 전제로 하기에, 빠른 실험과 개선을 반복하는 서비스 사일로의 의사결정 속도를 따라가지 못합니다. * 투자 회수 주기가 너무 길어 마케팅 비용(CAC) 집행의 적절성을 단기적으로 판단하기 어렵습니다. * 유저 전체의 평균 가치만을 보여줄 뿐, 특정 서비스 이용으로 인해 '추가로' 발생한 증분(Incremental) 가치를 분리해내지 못한다는 맹점이 있습니다. **MTVi의 정의와 산출 로직** * MTVi는 유저가 서비스를 새롭게 경험함으로써 발생하는 '향후 1년간의 순증 재무 가치'를 의미합니다. * A/B 테스트가 어려운 환경을 극복하기 위해 인과추론 방법론인 DID(Difference-in-Difference, 이중차분법) 추정법을 사용합니다. * 특정 월에 서비스를 처음 쓴 그룹(NAU)과 쓰지 않은 그룹(NEVER)을 비교하되, 유저 특성(연령, 활동 규모 등)에 따른 왜곡을 방지하기 위해 세그먼트 단위로 나누어 정밀하게 측정합니다. * 이를 통해 서비스가 없었더라도 발생했을 '자연 성장'분을 제거하고, 해당 서비스로 인해 유도된 순수한 가치 변화만을 남깁니다. **플랫폼 관점에서의 가치 구성** * MTVi는 '서비스 자체의 직접 손익'에 '해당 서비스로 인해 발생한 플랫폼 내 타 서비스로의 전이 가치'를 더해 계산합니다. * 예를 들어 '만보기'처럼 유저에게 혜택을 퍼주어 직접 손익은 마이너스인 서비스라도, 유저를 앱에 더 자주 머물게 하여 다른 금융 서비스 이용을 이끌어낸다면 MTVi는 플러스가 될 수 있습니다. * 이러한 관점은 마이데이터나 송금 등 플랫폼의 기초가 되는 서비스들의 재무적 가치를 증명하는 근거가 됩니다. **데이터 기반 의사결정의 변화** * "유저당 1년간 평균 N원의 가치를 만든다"는 명확한 숫자를 통해 모든 팀이 동일한 기준으로 소통하게 되었습니다. * 마케팅비나 운영비 등의 투자 판단 시, 고객 획득 비용(CAC)이 MTVi를 넘지 않도록 설정하는 등 정량적인 투자 효율 가이드를 제공합니다. * 여러 서비스 중 어떤 것에 먼저 자원을 투입해야 할지 우선순위를 정하는 데 있어 객관적인 지표로 기능합니다. 플랫폼 비즈니스에서 각 서비스가 독립적인 수익을 내지 않더라도 전체 생태계에 기여하는 바를 측정하는 것은 매우 중요합니다. 토스의 MTVi 사례처럼 단순한 매출 합계가 아닌 인과관계에 기반한 '증분 가치'를 측정할 때, 비로소 서비스의 진정한 가치를 이해하고 지속 가능한 성장을 위한 자원 배분이 가능해집니다.