현재 제가 진행 중인 프로젝트의 IT 환경에서 컨테이너 기술은 매일 사용되는 필수적인 요소가 되었습니다.특히 Kubernetes(K8s)와 같은 오케스트레이션 도구를 통해 클라우드 네이티브 애플리케이션의 배포와 관리를 정말 편리하고 신속하게 수행할 수 있게 되었죠.과거에는 Kubernetes 설치를 위해 Docker 기반으로 복잡한 설정 과정을 거쳐야 했지만,containerd와 같은 경량화된 컨테이너 런타임의 발전으로 설치 과정이 간소화되어 온프레미스 환경에서도 보다 효율적이고 안정적인 구축이 가능해졌습니다.이번 글에서는 컨테이너 런타임의 개념과 발전, 그리고 이를 통해 클라우드 네이티브 Kubernetes 설치가 얼마나 간편해졌는지를 실무 사례와 함께 소개해 드리겠습니다.컨테이너 런타임의 개념과 의의컨테이너 런타임(Container Runtime)은 컨테이너의 생성, 실행, 관리를 담당하는 핵심 소프트웨어로, 클라우드 네이티브 환경에서 중추적인 역할을 수행합니다.여기서 "런타임"은 단순한 실행 시간을 넘어 컨테이너의 전체 생명 주기 관리, 리소스 할당(CPU, 메모리, I/O 등), 격리 환경 유지, 호스트 운영 체제와의 상호작용을 아우르는 포괄적인 개념입니다.이러한 포괄적인 기능을 통해 컨테이너는 안정적이고 효율적인 방식으로 애플리케이션을 구동할 수 있습니다.컨테이너 런타임의 본격적인 발전은 2013년 Docker의 등장과 함께 시작되었습니다.Docker는 컨테이너 기술을 대중화하고 개발자 친화적인 도구와 생태계를 구축했지만, 그 복잡한 아키텍처로 인해 경량화된 런타임이 필요했습니다.관련해서 Docker는 2016년 containerd를 오픈소스로 분리하여 보다 가볍고 간결한 런타임을 제공했고, Kubernetes와의 긴밀한 통합을 통해 클라우드 네이티브 환경의 사실상 표준으로 자리 잡았습니다.컨테이너 런타임은 클라우드 네이티브 애플리케이션의 효율적인 배포와 관리를 가능하게 합니다.특히 OCI(Open Container Initiative)와 CRI(Container Runtime Interface) 표준은 런타임 간 호환성과 상호 운용성을 높여 컨테이너 생태계의 표준화와 유연성을 강화했습니다.containerd와 같은 경량 런타임은 자원 활용의 효율성과 성능 최적화를 통해 대규모 분산 시스템에서 뛰어난 안정성과 확장성을 제공합니다.컨테이너 런타임의 표준화 OCI와 CRI• None OCI(Open Container Initiative): 2015년 Docker와 주요 업체들이 설립한 오픈소스 프로젝트로, 컨테이너 형식과 런타임에 대한 표준을 정의합니다. OCI 이미지 스펙과 OCI 런타임 스펙을 통해 Docker, containerd, CRI-O 등 다양한 런타임에서 동일한 이미지를 실행할 수 있습니다.• None CRI(Container Runtime Interface): Kubernetes가 컨테이너 런타임과 통신하기 위한 표준 인터페이스로, containerd와 CRI-O는 CRI를 구현하여 Kubernetes와 원활히 통합

토스 쇼핑 추천 시스템: 수백만 사용자와 상품을 잇는 멀티 스테이지 접근법안녕하세요, 토스 커머스 개인화팀의 ML Engineer 김정오입니다.현재 토스 앱 하단 메뉴의 중앙은 저희팀에서 만들어가고 있는 토스 쇼핑이 자리하고 있는데요. 토스 쇼핑은 사용자 데이터를 기반으로 사용자에게 가장 필요한 상품을 추천해주게 되어있어요. 이 글을 통해서 토스 쇼핑은 어떻게 개인화 추천 시스템을 만들고 있는지 간략히 설명해 드리고자 합니다.토스 쇼핑은 다양한 소비자 유형을 다루고 있어요. 이 중 특히 중요한 두 가지 유형은 목적형 사용자와 탐색형 사용자인데요, 그 정의는 아래와 같습니다.• None 명확한 구매 목표 또는 특정 상품에 대한 수요를 가지고 플랫폼에 방문하는 사용자입니다. 이들은 구체적인 상품명, 카테고리, 가격대 등의 기준을 기반으로 검색 및 탐색 활동을 수행하며, 최대한 빠르게 원하는 상품을 발견하고 구매하는 것을 목표로 해요.• None 명시적인 구매 목적 없이 플랫폼을 탐색하며 다양한 상품을 둘러보는 사용자입니다. 이들은 우연히 발견한 상품 및 정보를 통해 흥미를 느끼고, 구매로 이어질 가능성을 높이는 행동 패턴을 보여요. 탐색형 사용자는 상품 카테고리에 대한 관심이 광범위하며, 구매 결정까지 상대적으로 긴 경로를 거치는 경향이 있습니다.→ 토스 쇼핑은 탐색형 사용자의 비중이 높습니다. 따라서, 사용자가 자연스럽게 흥미를 느끼고 구매 행동으로 이어지도록 돕는 개인화 추천 시스템이 필수적이에요.• None 수백만 명의 사용자와 수백만 건의 상품이 존재하는 대규모 플랫폼에서는, 사용자와 상품 간의 최적 매칭을 수작업으로 제공하는 것은 불가능합니다.• None 특히 탐색형 사용자의 경우, 명확한 검색 키워드 없이도 매력적인 상품을 발견할 수 있도록 돕는 이 핵심 역할을 합니다.• None 추천 시스템은 사용자 경험을 향상시키고, 구매 전환율을 높이며, 서비스 체류 시간을 증가시키는 데 직접적인 영향을 미칩니다.대규모 추천 문제를 해결하기 위해, 저희는 성능과 속도를 모두 고려하여 멀티 스테이지(Multi-Stage) 구조를 채택했어요. 이 구조는 크게 다음과 같은 단계로 이루어집니다.Retrieval 단계에서는 수백만 개의 상품 중에서 사용자에게 어울릴 가능성이 높은 수천 개의 상품을 빠르게 후보로 뽑아내요. 이 단계는 매우 빠른 응답 속도가 요구되며, 아래와 같이 다양한 방법론이 활용됩니다.• None : 사용자와 아이템 각각을 임베딩하여 벡터 공간에 매핑하고, 벡터 검색(Nearest Neighbor Search)을 통해 유사한 상품을 빠르게 검색합니다. DNN 기반 인코딩을 사용하며, 두 타워의 임베딩 결과를 내적(Dot Product)하여 유사도를 계산합니다.• None : 사용자-상품 상호작용 데이터를 그래프 형태로 표현하여, Graph Neural Network(GNN)를 통해 잠재적 연관성을 학습합니다. GraphSAGE, PinSage, LightGCN 등의 기술이 활용돼요.• None : 사용자의 행동 이력을 시퀀스로 모

안녕하세요, 카카오 기술 블로그 독자 여러분!저는 카카오에서 테크니컬 라이터로 일하고 있는 탈리사( )입니다. 복잡한 기술 정보를 쉽고 명확하게 풀어낸 기술 문서를 작성해, 카카오의 개발자들이 멋진 일을 해낼 수 있도록 조금이나마 힘을 보태고 있어요. TMI를 덧붙인다면, 매일 한복을 입고 다니는 고양이 세 마리의 집사입니다.아래는 최근 유행하는 ChatGPT의 이미지 생성 기능으로 만들어 본 제 프로필 이미지에요.요즘엔 누구나 이렇게 멋진 프로필 이미지를 만들 수 있을 정도로, AI 기반의 다양한 서비스가 정말 많아요. 정말이지 AI의 세상이라 해도 과언이 아니에요. 저도 업무 중 여러 AI 도구의 도움을 받아요. 그러다보니 동료들과 이런 이야기를 종종 나누곤 했습니다.“문서를 작성하는 데 어려움을 느끼는 동료들을 위해, 혹은 시간이 부족한 동료들을 위해, AI가 문서 업무를 도와주면 어떨까?”카카오에는 정말 많은 사내 서비스와 개발 도구들이 있어요. 이러한 도구들을 잘 사용하려면 상세한 기술 문서가 필요해요. 하지만, 기술 문서 작성은 많은 크루들에게 여전히 어렵고 부담스러운 일로 여겨지곤 합니다.그리고 AI 에이전트(Agent)의 시대가 도래한 지금, 리더인 양( )의 전폭적인 지지에 힘입어, 한 프로젝트를 시도해보기로 했습니다.이름하여 Technical Writing(TW) 에이전트! 사용자가 전달한 원문이나 자료를 바탕으로, AI가 기술 문서를 대신 작성하거나 편집해주는 도구를 만들어보려 해요.저는 테크니컬 라이터입니다. 서비스 개발 과정에 처음부터 끝까지 참여하지만, 직접 서비스를 만들어 본 적은 없어요. 그건 저와 함께 TW Agent를 만들어갈 동료인 스텔라( )도 마찬가지였습니다.막상 기획자와 개발자 없이 사용자 인터페이스(UI), 파일 저장과 관리, 사내 인증 같은 세부 기능들을 하나하나 만들어야 한다고 생각하니, 머릿속이 너무 복잡했어요. 그래서 AI 전문가인 동료 로빈(Robin.hwang)에게 조언을 구했고, 질문 폭탄을 날려댔죠.“초안이나 자료를 주면 AI가 기술 문서를 써주는 AI 도구를 만들고 싶어요. 이런 게 가능할까요?” “AI가 지정된 서식과 스타일 가이드에 맞춰 문서를 작성할 수 있을까요?” “사내에서 사용하는 위키(Wiki), 지라(Jira), 깃허브(Github)와 연동하고 싶어요. 참고 사례가 있을까요?” “TW 에이전트를 만들려면 어떤 AI 도구와 모델을 사용하는 게 가장 좋을까요?” “AI 모델이 도식 형태의 시스템 구조도를 잘 이해하고, 또 그려낼 수 있을까요?”다행히 로빈은 우리의 질문을 진지하게 받아들였고, 몇 가지 현실적인 조언을 해줬습니다. 덕분에 현실적인 초기 목표와 진행 방향을 설정할 수 있었습니다.우리는 먼저, 추론에 강한 AI 모델과 프롬프트(Prompt) 기법으로 정보 분석과 문서 작성 능력을 파악해 보기로 했어요. 복잡한 태그가 없는 마크다운 문서를 처리하는 것부터 시작해 보자고 했고요. 이후에는 API 연동과 MCP 서버(Server) 개발까지 넓혀, 실제 실무에 쓸 수

안녕하세요. 에이닷사업부 AI서비스개발본부 iOS개발팀 kimdocs입니다.🍀모바일 앱을 개발하다 보면,Android와 iOS에서 동일한 비즈니스 로직을 각각 따로 구현해야 하는 상황이 꽤 자주 생깁니다.서비스가 커지고 수정/변경이 반복될수록 플랫폼 간 로직 중복 및 불일치, 유지보수 부담이 점점 쌓여가죠.그러다 보니 자연스럽게 이런 고민이 생겼습니다...🤔 공통 로직을 하나의 코드로 공유할 수 있는 구조는 없을까?!그 해답을 찾기 위한 도구 중 하나로 Kotlin Multiplatform을 직접 검토해보게 되었습니다.Kotlin Multiplatform은 하나의 공통 Kotlin 코드베이스로 여러 플랫폼 (Android, iOS, Web, Desktop 등)에 앱을 개발할 수 있도록 도와주는 크로스 플랫폼 개발도구에요.JetBrains에서 제공하는 SDK로, Flutter나 React Native처럼 크로스 플랫폼 개발을 지원한다는 점에서는 유사하지만,가장 큰 차이점은 기존 플랫폼 언어(Android는 Kotlin, iOS는 Swift)를 그대로 사용할 수 있다는 점이에요.🧐 UI는 각 플랫폼별로, 혹은 Compose로?!일반적으로 Kotlin Multiplatform에서는 UI는 각 플랫폼 고유 방식으로 개발하고,공통 비즈니스 로직만 공유하는 구조를 많이 사용해요.하지만 최근에는 Jetpack Compose를 확장한 Compose Multiplatform도 함께 주목받고 있습니다.이걸 활용하면 UI까지도 Kotlin으로 공유할 수 있기 때문에, 진정한 의미의 “한 번 작성해 두 플랫폼에서 동작하는 UI”가 가능해집니다.그럼에도 불구하고, UI를 각 플랫폼 언어로 구현하는 전략에도 분명한 장점이 있어요• None 플랫폼 고유의 UX 가이드에 맞춘 구현이 용이 (예: iOS의 네이티브 제스처, 스타일)• None 최신 플랫폼 기능을 제약 없이 활용 가능• None 기존 네이티브 코드와의 통합이 자연스러움👉 이번 포스팅에서는 UI는 Android는 Kotlin, iOS는 Swift로 구현하고,비즈니스 로직만 Kotlin Multiplatform으로 공유하는 구조를 기준으로 설명할 예정이에요.Kotlin Multiplatform, 어떤 구조로 동작하나요?Kotlin Multiplatform에서는 공통 비즈니스 로직(예: API 통신, 데이터 가공, 도메인 처리 등)을shared 모듈에 Kotlin으로 작성하고, 이를 Android에서는 Gradle 의존성으로, iOS에서는 Framework로 가져다 씁니다.덕분에 중복 구현 없이 동일한 로직을 두 플랫폼에서 그대로 사용할 수 있게 됩니다.Kotlin Multiplatform 프로젝트는 구조상 Shared, Android App, iOS App 크게 세 가지 영역으로 나눌 수 있어요.이 영역은 실제로 Android와 iOS 앱으로 빌드되는 코드들이 위치한 부분이에요.구성 방식은 기존 네이티브 개발과 동일하기 때문에, Android 개발자나 iOS 개발자 모두 익숙하게 접근할 수 있습니다.• N

안녕하세요. 상용개발센터 CV AI LAB 하승구 연구원입니다.CV AI LAB은 AI 및 LLM 기술의 PoC(Proof of Concept)를 in-house로 개발 및 검증하는 그룹으로, 최신 연구 동향을 분석하고 실제 적용 가능성을 연구하고 있습니다.이번 포스팅에서는 최근 AI 업계에서 큰 반향을 일으킨 DeepSeek-R1 논문을 소개하려 합니다. DeepSeek-R1은 순수한 강화 학습(Reinforcement Learning, RL)만으로 LLM의 추론 능력을 최적화하는 접근법을 연구했으며, 기존의 지도 학습(Supervised Fine-Tuning, SFT) 없이도 효과적인 추론이 가능함을 입증했습니다.1. 기존 LLM 학습 방식의 한계기존 대형 언어 모델(LLM)들은 일반적으로 SFT 후 강화 학습(RLHF, RL with Human Feedback)을 적용하는 방식으로 학습됩니다. 하지만 이러한 접근에는 몇 가지 문제점이 있었습니다.(1) SFT 의존성: 방대한 고품질 데이터가 필요하며, 구축 비용이 높음.(2) 보상 모델의 부정확성: RLHF 방식에서 보상 모델(Reward Model, RM)은 피드백 오류가 발생할 가능성이 높음.(3) 테스트 시점 최적화 부족: 기존 모델은 학습된 데이터만 활용하여 즉각적인 답변을 생성하지만, 추론 강화 과정이 부족함.DeepSeek-R1은 이러한 한계를 극복하기 위해 Cold Start 후 RL 기반 학습을 적용하여 모델을 최적화하는 방법을 도입했습니다.  SFT : 지도학습을 활용한 LLM 미세조정 방법. 주어진 입력과 정답 데이터셋을 사용해 모델이 원하는 출력을 학습하도록 조정하며, 특히 도메인이나 태스크에 맞게 성능을 개선하는데 활용RLHF : 인간피드백을 활용한 강화학습 방식. LLM의 출력을 평가한 후 보상 모델을 학습시키고, 이를 기반으로 강화학습을 적용해 모델의 응답 품질을 개선2. DeepSeek-R1의 핵심 방법론DeepSeek-R1은 크게 두 가지 학습 접근법을 제안합니다.(1) DeepSeek-R1-Zero: 순수 강화 학습 기반 모델 학습DeepSeek-R1-Zero는 SFT 없이 순수한 RL만으로 모델을 학습했습니다. 기존 방식과 달리, 데이터 주입 없이도 LLM이 자체적으로 추론 능력을 발전할 수 있는지 실험했습니다.RL 알고리즘 : GRPO GRPO(Group Relative Policy Optimization): GRPO는 Critic(가치함수) 없이도 학습을 진행할 수 있는 방법을 제공합니다. 모델이 스스로 여러개의 답반을 생성하고, 이 답안들을 그룹으로 묶어 비교하여 상대적인 보상을 설정합니다. 이를 통해 메모리와 연산량을 절약하고, LLM과 잘 맞는 학습 방식을 제공합니다.PPO (Proximal Policy Optimization) : PPO는 학습의 안전성을 위해 Critic (가치함수)을 도입하여 기대 점수선을 설정하고, Clip 기법을 통해 정책의 급격한 변화를 방지합니다. 또한, Reference Model을 사용하여 부정행위를 방지하고, KL패널티로 기준 정책에서 크게 벗어나지 않도록 합니다.간단하게 요약하자면 GRPO는 상대평가, PPO는 절대평가입니다. PPO는 Critic을 도입하여 메모리와 연산량이 많은 반면 GRPO는 Critic 없이 학습을 진행하여 메모리와 연산량을 절약할 수 있습니다.OpenAI (RLHF)DeepSeek (GRPO)학습 방식지도학습 + 강화학습 (PPO)강화학습 (GRPO)필요한 모델 수4개 (AI, 평가, 보상, 레퍼런스)3개 (AI, 보상, 레퍼런스)GPU 사용량매우 높음상대적으로 낮음 (평가 모델 제거)학습 비용높음낮음학습 안정성하이퍼파라미터 조정이 어려워 모드 붕괴 가능성 있음상대적으로 안정적데이터 의존도보상 모델을 훈련하기 위해 직접적인 인간 피드백 필요그룹별 응답을 상대적으로 평가하여 정책을 최적화보상 시스템:정확성(Accuracy) 보상 : 응답의 정확도를 평가합니다.EX) 수학 문제 : 정답을 규칙 기반 검증 시스템으로 평가, LeetCode 문제 : 컴파일 결과로 정답 여부 확인논리적 형식(CoT, Chain-of-Thought) 보상 : 모델이 추론과정을 \태그로 구분하고, 최종 응답을 \로 명확히 표시하도록 학습(2) DeepSeek-R1: Cold Start 후 RL 적용DeepSeek-R1-Zero는 강력한 추론 능력을 보였지만, 출력 문장이 읽기 어렵거나 불안정한 문제가 있었습니다. 이를 해결하기 위해, DeepSeek-R1에서는 Cold Start 데이터셋을 활용하여 초기 SFT를 수행한 후, RL을 적용하는 방식을 도입했습니다.Cold Start 데이터 구축: 수학, 과학, 논리 문제 등 고품질 Reasoning 데이터 포함단계별 문제 해결 과정을 포함하는 Chain-of-Thought(CoT) 데이터셋 구축Reasoning-oriented RL: 논리적인 추론을 강화하도록 보상을 최적화다국어 혼합 문제(Language Mixing)를 방지하는 언어 일관성 보상(Language Consistency Reward) 적용DeepSeek-R1은 OpenAI-o1-1217 수준의 성능을 달성했으며, 다양한 Reasoning 벤치마크에서 기존 모델 대비 높은 성능을 기록했습니다.3. 소형 모델 증류(Distillation)DeepSeek-R1은 초기에는 32B, 70B와 같은 대형 모델로 학습되었습니다. 그러나 실용성을 고려하여 소형 모델(7B, 14B)로 지식을 압축(Distillation)하는 과정을 진행했습니다.Qwen2.5-32B 기반으로 7B, 14B 모델 증류 진행Distilled 모델이 원본 모델과 유사한 성능을 유지하도록 최적화그 결과, DeepSeek-R1-Distill-Qwen-7B 모델이 QwQ-32B-Preview보다 뛰어난 성능을 달성하며,소형 모델에서도 고급 추론 성능을 유지할 수 있는 가능성을 보였습니다.4.  결론DeepSeek-R1 연구는 순수한 RL 기반 학습이 LLM의 추론 능력을 극대화할 수 있음을 증명한 중요한 사례입니다.기존의 지도학습 (SFT) 없이도 RL만으로 강력한 추론 능

오늘은 지난주 구글에서 오픈 소스로 공개한 Agent2Agent(A2A)에 대해 알아보겠습니다.다양한 에이전트가 자연스럽게 협업할 수 있을까?지금까지의 에이전트 시스템은 각자 독립적으로 동작하는 경우가 많았습니다.프레임워크도 다르고, 개발한 벤더도 제각각이기 때문에 서로 간의 소통이 쉽지 않았습니다.Google의 A2A(Agent-to-Agent) 프로토콜은 바로 이 문제를 해결합니다.다양한 환경에서 만들어진 자율 에이전트들이 서로 그리고 사용자와 자연스럽게 협업할 수 있도록 표준화된 통신 방식을 제시합니다.이제는 하나의 언어로, 더 똑똑하게 함께 일할 수 있는 기반이 마련되었습니다.기업 환경에서도 에이전트 통합을 쉽게A2A는 복잡한 통합 과정을 단순화합니다.기존의 엔터프라이즈 애플리케이션에 에이전트를 붙이고 싶어도 인터페이스, 권한, 보안 문제 등으로 골치가 아팠는데요,A2A는 간단하고 일관된 방식으로 에이전트를 연결할 수 있게 도와줍니다.덕분에 기업은 기존 시스템을 바꾸지 않고도 AI 에이전트의 역량을 비즈니스 전반에 확장할 수 있습니다.A2A는 단순한 연결 프로토콜을 넘어, 실제 운영 환경에서 필요한 핵심 기능들을 기본으로 갖추고 있습니다.• None 기능 탐색 (Capability Discovery): 에이전트는 JSON 형식의 “에이전트 카드(Agent Card)“를 사용하여 자신의 기능을 알립니다.• None 작업 관리 (Task and state Management): 클라이언트와 원격 에이전트 간의 통신은 작업 완료를 지향하며, 작업의 결과물은 “산출물(artifact)“로 표현됩니다.• None 보안 협업 (Secure Collaboration): 에이전트는 엔터프라이즈 인증과 OpenAPI 기반의 권한 부여를 지원하여 보다 안전하게 컨텍스트, 응답, 산출물 또는 사용자 지침을 전달하여 협업할 수 있습니다.• None 사용자 경험 협상 (User Experience Negotiation): 각 메시지에는 생성된 이미지와 같이 완전히 구성된 콘텐츠 조각인 “부분(parts)“이 포함되며, 사용자 인터페이스 기능에 대한 협상을 명시적으로 포함할 수 있습니다. 결과적으로, A2A는 기업이 신뢰할 수 있는 에이전트 생태계를 구축하는 데 꼭 필요한 요소들을 두루 갖춘 프로토콜입니다.MCP: 도구와 리소스를 연결하는 표준 프로토콜에이전트를 현업에서 제대로 활용하려면, 단순히 똑똑하기만 해서는 부족합니다.Tool, API, 외부 리소스와 자연스럽게 연결되어 실제 액션을 수행할 수 있어야 하며, 이를 위한 핵심 역할을 하는 것이 바로 **MCP(Model Context Protocol)**입니다.MCP는 구조화된 입력/출력 체계를 통해 에이전트가 다양한 외부 자원과 연결될 수 있게 도와줍니다.예를 들어, 사용자가 “환율 조회해줘”라고 말하면, 에이전트는 이를 MCP 형식으로 구성된 API 요청으로 변환하여 실제 환율 정보를 가져올 수 있게 됩니다.특히 Google의 **ADK(Agent Developer Kit)**는 MCP 기반 도구

컴퓨팅 성능의 발전에 따라 데이터 통합 프로스세가 전통적인 ETL(추출, 변환,로드)에서 ELT(추출, 로드, 변환)로 전환되고 있습니다. ETL은 컴퓨팅 성능가 상대적으로 지금처럼 강하지 않았을 때 개발된 개념으로, 데이터의 관점에서 보면 데이터를 먼저 로드한 후 변환하는 것이 성능과 확장성 측면에서 유리합니다.이에 따라 Apache Iceberg와 같은 오픈 테이블 형식을 비롯하여, 스키마 진화(Schema Evolution)가 가능한 다양한 기술이 등장했습니다. 또한 고성능 OLAP 엔진의 필요성이 더욱 커지면서 StarRocks와 같은 데이터베이스가 최근에 주목을 받고 있습니다.ETL에서 ELT로의 변화에 맞는 OLAP 엔진의 중요성기존의 빅데이터 분석에는 플랫 테이블 구조를 사용하는 것이 일반적이었습니다. 모든 칼럼을 단일 테이블에 추가해 쿼리를 실행했고, 따라서 기존 테이블에 칼럼을 추가하는 방식으로 큐브를 생성했습니다. 그러나 거버넌스 환경으로의 전환이 가속화되면서 잘게 분리되어 유통되는 데이터가 많아짐에 따라, JOIN을 활용한 방법의 장점이 극대화되고 있습니다.또한 고속 OLAP 데이터베이스를 도입하면, 데이터베이스 내에서 중간 및 최종 집계 데이터를 롤업하여 세분화된 데이터를 다양하게 변환할 수 있습니다.OLAP 엔진 플랫폼 비교ClickHouse와 StarRocks는 OLAP 워크로드를 빠르게 처리할 수 있는 대표적인 데이터베이스입니다.특징ClickHouseStarRocks데이터 변환다양한 테이블 엔진과 materialized view를 통해서 지원(Transform After Load)generated column과 materialized view를 통해서 지원(generated column을 통해서 일부 Transform Before Load가 가능)materialized view 업데이트 방식원본 데이터에 데이터가 INSERT될 때 트리거되는 Near Realtime 방식직접적인 명령에 의해 기본 테이블의 데이터를 기반으로 데이터 업데이트자동화를 위한 스케줄러 내장스토리지 구조LSM 트리 기반 스토리지LSM 트리 기반 스토리지, 네이티브 스토리지로 분산 스토리지를 지원하여 클라우드 데이터베이스로 동작 가능JOIN 기능제한적, 대규모 테이블 조합에 한계뛰어난 JOIN 기능으로 다양한 데이터 조합 가능데이터 거버넌스 적합성분리된 데이터에 대한 JOIN 능력이 한정됨잘게 분리된 데이터를 JOIN해야 하는 데이터 거버넌스 환경에 적절하지 않을 수 있음분리된 다양한 데이터를 JOIN 가능다양한 거버넌스 환경에서 통합 분석 가능배포 시나리오PM/컨테이너 모두 지원PM/컨테이너 모두 지원쿼리 엔진최적화된 MPP(Massively Parallel Processing) 아키텍처로 대규모 데이터 고속 처리 가능최적화된 MPP 아키텍처로 대규모 데이터 고속 처리 가능GROUP BY 성능StarRocks에 비해 전반적인 GROUP BY 성능은 조금 뒤처짐테스트 전반에 걸쳐 Clickhouse에 비해서 GROUP BY 성능이 우수(대상

1. 천국과 지옥 사이: AI와 데이터 사이의 여정링크드인을 스크롤하다 우연히 2컷 만화를 마주쳤습니다. 데이터라는 지옥, AI 라는 천국이라는 컨셉의 이 만화는 단순하면서도 강렬한 메시지를 전달했습니다.첫 번째 컷에서는 구름이 가득한 하늘을 배경으로 사람이 편안하게 계단을 내려오고 있었습니다. 마치 천국에서 내려오는 듯한 이 모습은 AI를 활용하며 느끼는 행복감을 표현한 것 같았습니다.두 번째 컷은 불지옥 배경에서 사람이 힘겹게 계단을 올라가는 모습이었습니다. 데이터라는 세계에서 고생하는 사람의 모습을 담아냈습니다.링크드인에서 봤던 이미지는 간단한 그림체로 명확하게 의미 전달했는데 기억을 되살려 GPT-4o로 재현해보니 원본보단 강렬한 이미지가 만들어진 것 같습니다.나의 여정이 만화는 제 여정과 묘하게 겹쳐집니다. 현재 AI 플랫폼 개발을 담당하고 있지만, 이전에는 AccuInsight+ 빅데이터 플랫폼 개발을, 그 전에는 CRM / BI 솔루션 개발을 했습니다.지금은 AI를 모든 업무에 적용하려 노력하고 있지만 AI만으로는 충분하지 않다는 것을 깨달았습니다.AI가 제대로 작동하기 위해서는 그 기반이 되는 데이터에 대한 깊은 이해가 필수적입니다.우선 업무 프로세스를 이해해야 하고 그 업무에서 생성되는 데이터의 본질을 파악해야 하며, 이를 효과적으로 활용할 수 있는 단계까지 나아가야 합니다.2. 프로젝트로 보는 데이터의 다양한 모습처음 프로젝트에서는 더미 데이터로 AI를 활용해 목업 화면, 자동 코드 생성, 차트 구성 등 아이디어를 확장하는 과정이 흥미로웠습니다.하지만 곧 현실의 벽에 부딪혔습니다. AI는 보편적 용어를 사용하는 반면, 프로젝트에서는 전문화된 용어가 사용되었습니다."현재 내용과 맞지 않는데?"라는 피드백이 이어졌고, 프롬프트에 메타 정보를 지속적으로 입력해야 했습니다.이 경험을 통해 AI에게 프로젝트 관련 정보성 데이터를 우선 구성하고, 원천 DB가 아닌 중간지 DB를 구성해야 한다는 필요성을 인식했습니다.금융향 AI Coding Assistant: 도메인 지식의 중요성Microsoft Copilot과 유사한 sLLM 기반 AI 코딩 개발 과정에서도 새로운 도전이 있었습니다.자연어 기반 쿼리 생성(Text2SQL)과 NEXCORE 프레임워크 기반 코드 생성이 실제 업무 수준에 완전히 부합하지 않았습니다.금융권에서는 메타정보를 별도 관리하고 있었고, SQL 개발 가이드와 프레임워크 운영 가이드 준수가 필수였습니다.해결책으로 RAG를 통한 가이드 지식화와 MetaStore를 도입한 도메인 특화 메타데이터 통합 관리 시스템 구축이 필요했습니다.조달청 차세대 나라장터: 데이터 이행의 미로입찰심사 파트에서 데이터 이행 과정 중 "데이터 지옥"을 경험했습니다.AS-IS에서 TO-BE로의 마이그레이션에서 데이터 구조 차이, 맥락 파악 불가능한 불완전한 데이터, 잦은 법령 변경으로 인한 테이블 구조와 코드 체계 변경이 주요 문제였습니다.매핑 정의서만으로는 데이터 관계 파악과 무결성 유지가 어려웠고, 업무 담당자들의 잦은 변경으로 오래된

Meta에서 4월 5일 토요일에 Llama 4를 발표했습니다.이미 며칠 지나서 지금은 새로운 소식들에 묻힌 감이 있습니다만 요즘 AI가 하루하루가 다르기 때문이겠죠.메타에서 토요일에 부랴부랴 발표를 진행한 것도 더는 미룰 수 없었기 때문이라는 견해도 나오고 있습니다.라마2와 3은 구조상 차이가 크지는 않았는데, 라마4는 이전 모델들과 여러 가지 차이가 있습니다. 우선 모든 크기에서 멀티모달 모델이고, MoE 구조를 채택했습니다.긴 입력을 지원하기 위해서 새로운 임베딩 알고리즘을 도입했습니다. 데이터가 고갈되면서 다시 아키텍처가 중요한 시대가 되는 것 같습니다.자세한 기술은 technical report가 발표된 뒤에 확인하기로 하고, 이 글에서는 내용이 모두 공개되어 있는 토크나이저만 살펴 보겠습니다.라마4 토크나이저라마4 토크나이저에 대한 분석은 이미 나와 있습니다.Sionic AI에서 라마 4는 한국어에 가장 친화적인 오픈소스 모델입니다는 분석을 발표했습니다.라마4 토크나이저에 포함된 한국어 관련 토큰 비중이 크게 증가했다는 내용입니다.비록 라마4의 공식 지원 언어에 한국어가 명시되지는 않았지만, 다국어 데이터를 늘리면서 한국어 데이터도 많이 늘어난 것으로 보입니다.그렇다면 라마4 토크나이저의 한국어 효율이 얼마나 향상됐는지 확인해 보겠습니다.위 분석글에서 한국어 텍스트가 몇 토큰으로 처리되는지 분석하지는 않았으므로 직접 확인해 보겠습니다.예시로 Meta Llama 3 간단한 분석에서도 보았던 데보션 매니페스토를 측정해 보겠습니다. 데보션 매니페스토는 아래와 같습니다:문장부호와 빈 칸을 포함해서 171글자로 된 데보션 매니페스토를 라마2 토크나이저에 입력하면 246토큰이 됩니다.라마2에서는 한글 토큰 비율이 낮아서 한글 한 글자를 세 개의 토큰으로 나타내는 경우가 있기 때문입니다.이보다 개선된 라마3 토크나이저에서는 93토큰이 됩니다. 거의 2글자당 1토큰 정도로 효율이 꽤 높아졌습니다.그렇다면 라마 4는 어떨까요? 확인 결과,확실히 한국어 토큰이 늘어난 효과가 있습니다.다른 오픈소스와 비교해 보면, OpenAI의 o200k_base 토크나이저가 88토큰이니까 라마4 토크나이저가 훨씬 효율적입니다.이 정도면 엑사원과 비슷한 수준이고 다국어 모델 중에서 최고 수준입니다.한국어에 중점을 둔 SKT A.X 토크나이저보다는 30% 정도 토큰을 더 사용합니다만 그래도 충분히 효율적이라고 볼 수 있겠습니다.비슷한 규모의 모델끼리는 토크나이저 효율이 높으면 언어 이해 및 생성 성능도 상승하는 경향이 있습니다.아무래도 한국어 지원이 가장 중요한 부분이기 때문에 먼저 설명했습니다. 이제 라마4 토크나이저의 전반적인 특졍을 간단히 보겠습니다.라마3에서는 OpenAI의 cl100k_base에 다국어 토큰을 추가해서 만들어서 토큰의 80% 이상이 겹쳤는데 라마4는 Meta 독자적으로 토크나이저를 만들었습니다.토큰 수 (vocab size)는 정확하게 20만개를 맞추었습니다. 토크나이저 인코딩은 이전과 똑같이 BBPE이기 때문에 눈으로 개별 토큰이 무엇인지

안녕하세요! 검색플랫폼팀의 Backend Engineer 하이(Hy)에요.당근에는 중고거래, 동네생활, 동네업체, 채팅 등 다양한 서비스가 있는데요. 검색플랫폼팀은 검색 서비스를 안정적으로 지원하는 플랫폼을 만들며, 다양한 서비스의 검색을 지원하고 있어요. 이를 위해서는 가장 먼저 각 서비스들의 데이터가 필요한데요. 이번 글에서는 각 서비스의 데이터를 검색 엔진에 전달하는 색인 파이프라인을 운영하면서, 어떤 문제가 있었고 어떻게 해결했는지 이야기하려고 해요.색인 파이프라인은 1) 실시간성을 보장하기 위한 Online 색인과 2) 사전 변경, 데이터 보정을 위해 하루에 한 번 전체 색인을 하는 Offline 색인을 해요. 이 두 가지를 진행할 때, 기존 파이프라인은 아래와 같은 문제점이 있었어요.생산성데이터를 가져오고 색인하는 로직의 패턴은 대부분 동일하지만, 서비스마다 로직이 따로 존재해서 관리 포인트가 많아져요.의존성당근의 서비스 DB에 직접적으로 붙어서 데이터를 가져오기 때문에, 각 서비스 DB에 강한 의존성을 가지게 됐어요.비용하루에 한 번 OnlineDB의 내용을 전체 Full Scan해야 하기 때문에 색인 파이프라인의 DB의 사이즈가 커야 했어요. 또한 서비스팀에서도 저희를 위한 ReplicaDB를 만들어주어야 해요.가시성어떤 필드가 어떻게 색인이 되는지, 필터링 로직 등 색인 로직이 어떻게 구성됐는지 등을 파악하려면, 늘 코드를 전부 일일이 확인해야 했어요.이전 색인 파이프라인에서 개발해야 하는 부분위의 4가지 문제를 해결하기 위해 다음과 같은 목표를 세웠어요.설정 기반의 인터페이스로 자동화하여, 누구나 기여할 수 있는 생산성이 높은 시스템을 만들어요.외부 서비스 DB에 대한 의존성을 낮춰서, 상태가 변경되어도 안전한 색인 파이프라인을 만들어요.하루에 한 번 풀색인(Full Indexing)의 부담을 낮추고 비용을 줄여요.이벤트가 쏟아져도 안전한 고가용성의 시스템을 만들어요.1) 설정 기반의 인터페이스로 자동화하여, 누구나 기여할 수 있는 생산성이 높은 시스템을 만들어요.위의 목표를 달성하기 위해서는 동작을 명시하는 설정 Interface가 잘 정의되어야 해요. 또한 아무리 자동화가 목적이라도 안전한 시스템을 갖추기 위해선, 먼저 안전한 스키마를 설계해야 해요. 그래서 아래와 같은 원칙을 세웠어요.해당 인터페이스에 명시된 동작만 이루어져야 하며, 이외에 다른 동작을 하는 마술은 부리지 않아야 함모든 데이터는 스키마를 가지고 안전하게 처리할 수 있도록 해야 함모든 in/out 사이에는 비즈니스로직을 자유롭게 넣을 수 있어야 함사용자가 몰라도 되는 core 로직은 데이터 처리 외에는 하지 않아야 함먼저 동작을 명시하는 Interface를 정의하기 위해 비교적 접근성이 쉬운 yaml을 사용하였어요. 아래는 데이터를 어떻게 가져오고, 적재하고, 관리할지를 보여주는 Datastore의 Interface 예시예요.version: 1name: {서비스이름}_datastorestorage: datastoresources: - table: