안녕하세요. 에이닷사업부 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:

소프트웨어 서비스에 LLM이 도입되고 이제 AGI 시대로 접어든 이후 Tech서비스에는 AI의 활용이 점점 더 발전하고 있습니다.QA 테스트 자동화(Automation Test)에도 Chat기반 LLM Agent로 테스트 자동화를 빠르게 개발하고 도입할 수 있는 기술이 탄생했습니다.Chat기반 LLM Agent로 테스트 자동화를 진행하기 위해서는 Cursor IDE를 사용하고 있습니다.Cursor는 AI 코드 에디터이기 때문에 직접 테스트 프레임워크를 내장하고 있는 건 아니지만, 다양한 테스트 프레임워크와 잘 호환되도록 설계되어 있는데여러가지 테스트 프레임워크를 사용해봤지만 특히 Playwright 테스트 프레임워크와는 매우 강력한 호환성 시너지를 발휘합니다.Cursor는 Visual Studio Code(VS Code) 를 기반으로 만들어진 AI 코드 에디터입니다.GitHub Copilot이나 ChatGPT처럼 AI의 도움을 받아 코딩을 빠르고, 효율적으로 할 수 있도록 설계된 도구입니다.2024년 하반기 ChatGPT처럼 Chat 기반 Agent로 프롬프트 입력으로 개발 코드 작성을 지원해주는 업데이트를 지원합니다. (Chat 프리미엄 기능은 유료 - 참고)AI Model의 context User Roles 설정도 가능하며, OpenAI, Anthropic, Google, Azure API Key 연동도 가능합니다.Playwright는 Microsoft에서 개발한 Web 전용 End-to-End(E2E) 웹 애플리케이션 테스트 자동화 프레임워크입니다.Node.js를 통해 웹 브라우저를 실제 사용자가 조작하는 것처럼 자동화해서, UI 기능을 테스트하거나 웹 크롤링, 스크린샷, PDF 생성 등 다양한 작업을 할 수 있습니다.여러가지 테스트 프레임워크를 사용해 봤지만 Cursor는 다음과 같은 이유로 Playwright와 호환성 시너지가 가장 좋았습니다.• None AI가 시나리오 흐름을 잘 이해함: 예를 들어 “로그인 후 대시보드로 이동” 같은 흐름을 자연스럽게 코드로 생성• None 테스트 + 스크린샷 + mocking까지 프롬프트 기반으로 자동화 가능• None Headless 모드로 개발 이후 운영모드의 CI 확장성으로도 용의함QA에서는 테스트를 진행하기 위해서 TestCase를 작성 및 관리를 진행하고 있습니다.테스트 자동화의 가장 최적화 방법은 실제사용하고 있는 TestCase의 검증 동작을 테스트 자동화로 구현하는것을 목적으로 하고 TestCase 기반의 프롬프트를 샘플 코드로 작성합니다.[Web기반 에이닷 멀티LLM - 로그인 TestCase의 예시][TestCase] (아래 TC는 샘플코드를 위한 일부 생략된 예시 발췌 입니다.)샘플코드를 작성해보기 위해 몇개의 TestCase를 하나의 Prompt Step별 작성합니다.빠른 테스트 코드 작성을 위해서 일부 Button Control Element Locator를 미리 지정해두었고 (생략가능) PlayWrighr로 자동화 코드 생성을 요청하는 프롬프트를 만들었습니다.준비해둔

Part 1 에서는 Knowledge distillation 이 어떤 것인지, 어떤 방법론들이 존재하는지 살펴봤다.Part 2 에서는 distillation 을 이용해 LLM 추론 속도를 높이는 speculative decoding과, 가장 최신의 knowledge distillation 방법론들에 대해서 알아본다.사실 Distillation 의 장점은 student 모델의 성능 개선에만 있는 것이 아니다!Transformers는 학습 병렬화를 통해 거대 모델의 학습이 가능하게 했지만, 추론 할 때 엄청 느리다.Input sequence 에 대한 logit 은 한번에 구할 수 있는데, token 을 생성할 때에는 sequential 하게 생성해야 하기 때문이다.그래서 나온 Speculative decoding은 큰 모델의 답변과 비슷하게 답변하는 작은 모델을 통해 큰 모델의 속도를 높이는 방법이다.• None 작은 모델은 빠르게 생성할 수 있으니까 일단 token 여러개를 생성한다• None 큰 모델로 token 여러개에 대한 logit 을 한번에 뽑아서, 잘못 생성된 token 을 찾는다.• None 잘못 생성된 token 부터 다시 작은 모델로 토큰을 생성한다 -> 반복이게 되려면 큰 모델과 작은 모델의 답변이 비슷해야 속도가 올라간다. 만약에 모든 토큰이 다 달라버리면, 괜히 작은모델을 태워서 리소스만 더 잡아먹는 것이다.그런데 같은 데이터셋으로 학습했다고 하더라도 작은 모델과 큰 모델의 답변이 비슷할거라는 보장이 없다. 따라서 Distillation 을 통해서 speculative decoding 성능을 극대화하는 방법이 제안되었다.Distillation을 하면 student model 의 답변들이 teacher 와 비슷해지면서 10~45% 추론 속도가 증가했다.이 방법론은 실제로 Google 검색 페이지에 적용되어 있다가장 최근에는 이 Speculative decoding을 응용한 하이브리드 방법론도 제안되었다.GKD 가 성능이 좋기는 하지만, Student 의 on-policy response 가 썩 좋지 않은 상태에서 GKD 를 하는 게 괜찮을까에 대한 의문이 있다.이런 상황에서는 off-policy 더라도 퀄리티 좋은 teacher 의 response 를 써서 Supervised KD 를 하는게 나을 수도 있다.이 두 방법론의 장점만을 취한 방법론이 SKD 다.우선 Student 의 on-policy response 를 뽑는다. 그리고 각 token이 teacher 의 top-K token 에 포함되어 있는지 확인한다.만약 모두 포함되어 있는 경우라면 on-policy 응답이 꽤 좋은 상황이므로 GKD를 수행한다.포함되지 않는 토큰이 있는 경우라면 해당 토큰을 Teacher 의 token 으로 교체하여 퀄리티를 높이고, 이를 이용해 Supervised KD를 수행한다.이 SDK 방법론을 적용했을 때 성능도 오르고 speculative decoding 속도도 올랐다고 한다.왜냐면 Student 의 성능 관점에서는 on-pol

안녕하세요 현대자동차 자율주행 기반기술팀 조재훈 책임연구원입니다. 이번 포스팅은 'AI 학습 데이터'에 대한 현업에서의 고민을 정리해 보았으며 1) AI시대의 데이터, 2) 자율주행 도메인(domain)에서의 데이터, 3) 결론 3파트로 구성하였습니다.AI시대의 데이터최근 어딜가나 'AI'라는 키워드가 빠지지 않는데요, 좋은 성능을 갖는 AI를 개발하기 위해서 중요한 요소는 어떤것들이 있을까요?AI 모델? AI모델을 학습하기 위한 전용 GPU? AI를 학습하기 위한 데이터?모두 중요 하지만, AI 성능에 직접적이면서 결정적인 역할을 하는 것은 '데이터'라고 생각합니다. 그렇기에 많은 회사들이 데이터 센터 구축 및 활용 방안에 집중하고 있으며, 국가적인 차원에서도 국제적인 R&D 기술력 확보를 위해 정책적으로도 많은 고민을 하고 있는 것을 확인할 수 있습니다.그러면 여기서 이런 궁금증이 드는데요 ' 어떤 데이터가 좋은 데이터일까요?'좋은 데이터란 단순히 많은 양을 확보하는 것이 아니라, 모델이 학습할 수 있도록 구조적이고 체계적인 방식으로 정제된 데이터를 의미합니다. 특히, AI 모델이 일반화(generalization) 능력을 갖추려면, 다양한 상황과 환경을 반영한 데이터가 필요합니다. 그러나 현실적으로 모든 케이스의 데이터를 수집하는 것은 시간과 비용, 그리고 윤리적인 문제 등 여러 가지 한계가 존재합니다.실제(real) 데이터의 한계실제 데이터는 AI 모델 학습에 있어 가장 이상적인 데이터 소스이지만, 몇 가지 문제점이 존재합니다.데이터 수집의 어려움: 특정 도메인(예: 자율주행, 의료)에서는 데이터를 얻는 것이 쉽지 않으며, 개인정보 보호법 등의 규제에 의해 사용이 제한될 수 있음비용 문제: 대규모 데이터셋을 확보하고 라벨링하는 데는 많은 비용과 시간이 소요됨희귀한 사례 부족: 특정 상황(예: 드문 사고 상황, 극단적인 날씨 조건 등)의 데이터는 충분히 확보하기 어려워 모델이 특정 환경에서만 잘 작동하는 문제(편향, bias)가 생길 수 있음이러한 한계를 극복하기 위한 방법 중 하나가 합성(synthetic) 데이터입니다.합성(synthetic) 데이터란?합성 데이터는 실제 환경을 기반으로 컴퓨터가 생성한 가상의 데이터입니다. 3D 시뮬레이션, Generative 모델을 활용한 데이터 생성 (generated data 또는 pseudo label), 데이터 증강 기법(data augmentation) 등을 이용하여 기존 데이터를 변형하거나 완전히 새로운 데이터를 만들어낼 수 있습니다.합성 데이터가 유용한 이유는 다음과 같습니다.다양한 환경 및 변수 조절 가능: 현실에서 수집하기 어려운 다양한 조건(예: 다양한 조명 조건, 다양한 장애물 상황 등)을 자유롭게 생성할 수 있음비용 절감: 실제 데이터를 수집하는 것보다 훨씬 낮은 비용으로 대량의 데이터를 생성할 수 있음개인정보 보호 문제 해결: 의료 데이터, 금융 데이터 등 민감한 정보를 포함한 데이터셋의 경우, 합성 데이터를 활용하면 프라이버시 문제를 해결하면서도 모델 학습이 가능함합성 데이터는 비용 효율적이고 확장 가능한 AI 모델 학습 솔루션을 제공하지만, 이를 단독으로 사용할 경우 실제 환경에서 모델을 바로 적용하는데 문제가 발생할 수 있습니다. 가장 큰 문제는 '도메인 갭 (domain gap)'으로, 합성 데이터와 실제 데이터 간의 질감, 조명, 객체의 형태 및 환경 조건의 차이로 인해 발생합니다. 합성 데이터로만 학습한 모델은 '일반화(generalization)'가 어려워 실제 환경에서 예측 정확도가 저하될 확률이 높습니다. 아래의 Fig. 1은 합성데이터와 실제 데이터에 대한 예시를 보여주는데요, 아무리 정밀하게 실제 데이터처럼 합성데이터를 생성한다 하더라도, domain gap 문제는 발생할 수 밖에 없습니다. 우리가 봤을 때 차이가 느껴지는 것 처럼, AI 모델 또한 다르게 인식을 하는 것이죠.Fig 1. (좌) 합성 KITTI 데이터, (우) 실제 KITTI 데이터자율주행 도메인에서의 데이터Fig 2. Data-Driven Development Loop (DDDL)자율주행에서는 데이터를 어떻게 구축/활용하고 있을까요? Fig 2. 는 자율주행 개발 프로세스를 간단히 표현한 그림입니다. 딥러닝 네트워크 관점에서의 개발 파이프라인을 DDDL (Data-Driven Development Loop) 이라고 표현을 하였으며, 4가지 단계를 포함합니다:데이터 수집 (Data construction)네트워크 학습 (Training)성능 평가 및 검증 수행 (Evaluation & Validation)최종 네트워크 배포 및 피드백 (Release)Fig 3.은 각 단계별 소모되는 Man power (인력), 시간 (Time), 비용(Cost)를 시각화 하여 비교한 결과를 보여줍니다.Fig 3. 자율주행 개발 시 발생하는 비용 비교 정리Man power (y축): 각 단계를 수행하기 위해 투입되는 인력에 대한 정량 분석 결과Cost (x축): 각 단계를 수행할때 필요한 총 가격에 대한 정량 분석 결과 (데이터 구축/활용/검증/배포 비용, GPU 등)Space of circle: 각 단계를 수행할 때 소모되는 시간(Time)에 대한 정량 분석 결과* 해당 내용은 정량 평가를 시각화 하기위해 나타낸 그림입니다. Waymo, Tesla, Nvidia의 technical report등에 명시된 자료들을 기반으로 구성하였지만 오차가 있을 수 있습니다. (Waymo: 1,000만 마일 이상의 실 도로 주행데이터 수집 2년이상 투자/ Tesla: FSD (Full Self-Driving) 학습 및 검증에 매주 1백만 마일의 도로 주행 데이터 수집 및 처리/ NVIDIA autonomous driving platform: NVIDIA GPU resource 사용량은 1~ 3주 학습 기간 산정함/ Cruise (GM 자율주행 부문): 실제 차량 배포까지 2주 ~ 1개월의 시간을 필요로함)해당 분석으로 부터, 다음의 3가지 결론을 내렸습니다.자율주행 개발 프로세스에서 데이터 구축은 가장 많은 시간과 비용 인력을 필요로하는 것으로 보