바로 어제 진행한 Microsoft Build 2025 행사에서 새롭게 선보인 NLWeb에 대해 알아보겠습니다.NLWeb은 웹사이트를 손쉽게 AI 앱처럼 만들 수 있는 오픈 프로젝트로서, 사용자가 웹 콘텐츠를 자연어로 질의하고 대화하듯 상호작용할 수 있게 해줍니다.이 발표에서 NLWeb을 가리켜 “리치한 시맨틱 웹 상호작용”이라고 강조했고, 이는 오늘날 웹 검색 경험을 한 단계 도약시키려는 Microsoft의 비전의 일환이었습니다.지금부터 NLWeb이 무엇인지, 어떠한 구조와 목표를 갖고 있는지, 그리고 실제로 이를 활용해보는 방법을 차례로 살펴보겠습니다.NLWeb의 등장은 웹 상호작용 방식의 혁신과 관련이 깊습니다.Microsoft는 NLWeb을 “에이전틱 웹(Agentic Web)의 HTML”에 비유했는데,이는 HTML이 웹1.0 시대에 문서 공유를 표준화했듯이 NLWeb은 AI 시대의 웹 상호작용을 표준화하려는 시도라는 뜻입니다.기존에도 웹사이트에 챗봇이나 검색 기능을 붙이는 시도가 있었지만, 복잡한 통합 작업, 벤더 종속성 등의 한계가 있었습니다.NLWeb은 이러한 장벽을 허물고 몇 줄의 코드만으로 대화형 AI 인터페이스를 웹에 추가할 수 있도록 설계되었습니다.그 결과 웹 운영자는 자신만의 데이터와 원하는 AI 모델로 손쉽게 자연어 챗봇 경험을 제공할 수 있게 됩니다.NLWeb의 근본 목표는 웹을 통째로 AI 환경으로 탈바꿈시키는 데 있습니다.사용자는 더 이상 검색어 키워드 나열이 아닌 대화 형태로 사이트 콘텐츠를 탐색하고, 웹사이트 역시 이러한 질의에 대응하여 정확하고 풍부한 답변을 제공할 수 있습니다.특히 이 프로젝트를 이끄는 R.V. Guha는 RSS, RDF, Schema.org 등을 만들어 웹 표준을 주도한 인물로,NLWeb을 통해 오랜 기간 고민해온 “개방형 웹”의 가치를 AI 시대에 접목하고 있습니다.기존 기술과의 차별점NLWeb이 기존의 검색 엔진이나 챗봇과 근본적으로 다른 점은 개방성과 표준성입니다.지금까지는 개별 웹사이트가 챗봇을 도입하려면 특정 업체의 API에 의존하거나 커스텀 개발을 해야 했습니다.예를 들어 쇼핑몰이 OpenAI와 제휴해 자체 챗GPT 기반 검색을 구현하는 식의 일대일 맞춤형 계약이 필요했습니다.본 발표에서 NLWeb에 대해 “더 이상 이러한 1:1 커스텀 딜이 아니라 오픈 프로토콜로 가는 것”이라고 설명합니다.즉, NLWeb을 도입하면 어떠한 웹사이트라도 손쉽게 표준화된 방법으로 AI 검색 기능을 제공할 수 있고, 외부 거대 모델과도 동등하게 통신할 수 있다는 의미입니다.NLWeb은 여러 컴포넌트로 이루어진 경량 서비스입니다. 주요 구성은 다음과 같습니다.• None Agent (코어 서비스): 자연어 질의를 처리하는 백엔드 엔진입니다. 질의를 받아 벡터DB 조회, LLM 응답 생성 등의 핵심 로직을 수행합니다. 필요에 따라 프롬프트 템플릿이나 응답 형식 등을 커스터마이즈할 수 있습니다.• None Data Connector: 다양한 LLM 모델(OpenAI GPT, Anthropic Claude 등)과 벡터 데이터베이스(Qdrant, Milvus, Azure Cognitive Search 등)에 연결하는 플러그인 모듈입니다. 개발자는 구성 파일만 변경하여 선호하는 모델과 DB를 선택할 수 있습니다.• None 데이터 투입 도구: 웹사이트의 콘텐츠를 벡터DB에 적재하는 툴입니다. Schema.org 마크업 데이터, RSS 피드, JSONL 등 반정형 데이터를 읽어들여 임베딩 생성 후 인덱싱합니다. 이를 통해 사이트의 페이지, 상품, 리뷰 등의 정보가 검색 가능한 벡터 형태로 저장됩니다.• None 웹 서버 프론트엔드 & UI: 사용자 질의를 받아 Agent에 전달하고 응답을 보여주는 경량 웹 서버 및 채팅 UI입니다. 기본 제공되는 샘플 UI는 사용자가 브라우저에서 질문을 입력하고 답변을 확인하는 챗봇 형태 인터페이스를 제공합니다. 실제 프로덕션 환경에서는 이 UI를 커스터마이징하거나 별도 애플리케이션에 통합하는 것이 좋습니다.이처럼 NLWeb은 코어 엔진부터 데이터 적재, UI까지 한 패키지로 제공되어, 개발자가 복잡한 통합 없이 곧바로 동작하는 챗봇 서비스를 구축할 수 있다는 장점이 있습니다.또한 모든 구성요소가 MIT 라이선스 오픈소스로 공개되어 있어, 필요하다면 코드를 직접 수정하여 자신만의 특화된 기능을 추가하는 것도 가능합니다.NLWeb을 특별하게 만드는 또 하나의 특징은 MCP 지원입니다.MCP는 Anthropic 등이 주창하는 오픈 프로토콜로, 다양한 AI 에이전트가 툴이나 외부 지식에 접속해 상호작용할 수 있도록 해줍니다.NLWeb은 모든 인스턴스가 MCP 서버로 동작하도록 설계되어, 사람뿐 아니라 다른 AI도 해당 웹의 NL 인터페이스에 질의할 수 있습니다.쉽게 말해 NLWeb = MCP를 말하는 웹용 챗봇 서버라고 보시면 됩니다.MCP의 동작은 일종의 약속된 질문/응답 API로 이루어지는데,NLWeb 측에서는 이 프로토콜을 통해 질문을 받으면 자신의 벡터DB와 LLM을 활용해 답변하고, 그 결과를 JSON 등 구조화된 형식으로 반환합니다.이를 통해 외부 에이전트가 NLWeb에 접속해 실시간으로 해당 웹의 최신 정보를 얻어갈 수 있게 됩니다.예를 들어 NLWeb을 도입한 TripAdvisor 사이트가 MCP 기능을 활성화하면,ChatGPT나 Claude 같은 모델이 인터넷 검색 대신 해당 TripAdvisor NLWeb endpoint에 직접 질의를 보내어 풍부한 여행 정보를 받아갈 수 있습니다.웹사이트 입장에서는 자신의 데이터를 구조화된 방식으로 제공함으로써 AI 에이전트 생태계의 일부가 될 수 있고,사용자는 각 사이트의 최신 정보에 기반한 정확한 답변을 얻을 수 있어 Win-win이 됩니다.다만 MCP 참여는 사이트 운영자의 선택 사항이며, 공개 범위도 설정할 수 있습니다.데이터를 모두 개방할지 일부만 허용할지 결정함으로써, 데이터 주권과 개방성 사이에서 유연한 조율이 가능합니다.Microsoft는 이러한 MCP 지원을 통해 NLWeb이 “열린 에이전틱 웹”의 기반이 되리라 보고 있으며,궁극적으로 HT

안녕하세요. SR(Service Reliability) 팀에서 SRE(site reliability engineer, 사이트 안정성 엔지니어링) 업무를 맡고 있는 이채승(argon)입니다.SR 팀은 Service Engineering 실에 속해서 LINE 앱에서 제공하는 서비스의 품질 향상 및 가용성 확보를 위한 기술 활동을 수행하고 있습니다. 이를 위해 AWX와 Rundeck, Concourse CI와 같은 자동화 플랫폼을 운영하며, 서비스 출시와 이벤트에 필요한 기술적 요소를 확인하고 적절한 솔루션을 제공해 개발 조직이 개발과 운영에 더욱 집중할 수 있도록 지원합니다.저의 주 업무는 오픈챗 SRE로 오픈챗 서비스의 신뢰성을 높이기 위해 노력하고 있으며, 동시에 전사 직원들의 업무 자동화를 돕기 위한 AWX 플랫폼 운영 업무를 겸하고 있습니다. 이번 글에서는 AWX 플랫폼을 운영하면서 반복되는 문의에 효과적으로 대응하기 위해 RAG(Retrieval-augmented generation, 검색 증강 생성)를 활용한 AWX 지원 봇 도입 사례를 소개드리고자 합니다.사람들은 뭔가를 시작할 때 가이드 문서를 읽어야 한다는 사실을 알고 있음에도 실제로는 읽지 않고 시작하는 경우가 많습니다. 이런 문제는 특히 초기에 읽어야 할 가이드 문서의 분량이 방대한 경우 나에게 필요한 정보를 찾기 어려워지면서 발생하는데요. 이때 많은 사용자들이 빨리 시작하고 싶은 마음에 관리 측에 동일한 문의를 중복으로 남기기 시작하면 관리자는 이에 대응하느라 운영 리소스를 크게 소모하게 됩니다.위와 같은 문제를 해결하기 위해 가이드 문서를 읽어본다면 충분히 알 수 있는 문의에 대해서는 1차적으로 자동 답변을 제공할 수 있는 시스템이 필요했고, 검색과 생성을 결합한 RAG 기법을 활용해 AWX 지원 봇을 개발하게 되었습니다.자세한 설명에 앞서 AWX 지원 봇 구현에 사용한 프레임워크 및 툴을 소개하겠습니다.• Slack 봇 프레임워크: Bolt for Python• Slack에서는 다양한 언어 기반의 봇 프레임워크를 제공하고 있습니다. 그중 개인적으로 익숙한 Python 봇 프레임워크를 선택했습니다.• LLM 프레임워크: LangChain• LangChain 프레임워크는 Python과 JavaScript, 이 두 가지 언어로 제공됩니다.• AWX 지원 봇은 많은 기능이 필요하지 않아서 LangChain을 사용했는데요. 만약 조금 더 복잡한 워크플로와 상태 관리, 다중 에이전트 협업을 원하신다면 LangGraph를 사용하는 것을 권장합니다.• 임베딩 모델: paraphrase-multilingual-mpnet-base-v2• 문장을 벡터로 변환해 주는 임베딩 모델은 SBERT 모델, OpenAI 텍스트 임베딩 모델 등 다양한 선택지가 있으며, 그중 오픈소스인 SBERT 모델을 선택했습니다.• LY는 여러 나라의 임직원이 함께 서비스를 개발하고 있기 때문에 문의 또한 여러 언어로 접수됩니다. 이를 고려해 SBERT에서 제공하는 성능 평가 표를 참조해서 다국어를 지원하는 모델 중 문장 비교 성능이 가장 괜찮은 paraphrase-multilingual-mpnet-base-v2를 선택했습니다.• 벡터 DB: OpenSearch• 사내에서 PaaS(platform-as-a-service)로 제공되고 있고, 개인적으로 가장 익숙한 플랫폼이라서 OpenSearch를 선택했습니다.• OpenSearch 외에도 Chroma나 Faiss, Milvus와 같이 성능 좋은 벡터 DB가 다양하게 출시돼 있기 때문에 상황에 맞게 구성하실 수 있습니다.• LLM: OpenAI(ChatGPT)• 저희 회사에서는 적절한 용도로 신청하면 OpenAI API를 사용할 수 있기 때문에 OpenAI를 선택했습니다.• OpenAI Enterprise의 경우 기본적으로 비즈니스 데이터를 학습하지 않고 있다는 점도 고려했습니다(참고: https://openai.com/enterprise-privacy/).• LangChain 프레임워크에서는 OpenAI뿐 아니라 Ollama나 Amazon Bedrock 등 다양한 LLM과 연동할 수 있는 프레임워크를 지원하고 있기 때문에 각자의 환경에 적합한 LLM을 선택할 수 있습니다.RAG 기법을 이해하기 위해서는 먼저 LLM(large language model)과 LLM의 한계를 알아야 합니다.LLM은 방대한 양의 데이터로 사전 학습된 딥러닝 모델로, 텍스트에서 의미를 추출하고 단어 및 구문의 관계를 이해해 결과물을 생성합니다. 학습한 데이터를 바탕으로 적절한 답변을 생성하기도 하지만 다음과 같은 몇 가지 한계 때문에 적절하지 않은 답변을 생성하기도 합니다.• 최신 정보 반영의 어려움: 답변이 사전 학습된 데이터에 기반하므로 최신 정보를 반영하지 못합니다.• 허위 정보 생성 가능성: 사전 학습 시 사용한 데이터에 없는 질문에 대해서는 부정확하거나 허위 정보가 답변으로 제공될 수 있습니다.• 출처 확인의 어려움: 모델이 생성한 답변의 출처를 명확히 알 수 없습니다.이와 같은 한계를 보완하기 위해 RAG 기법을 사용합니다. RAG는 LLM에게 질문과 함께 콘텍스트(신뢰할 수 있는 데이터)를 전달해서 콘텍스트를 바탕으로 정확한 답변을 생성하도록 유도하는 프로세스입니다. 다음은 기존 LLM의 답변과 RAG 기법을 사용해 콘텍스트를 전달한 LLM의 답변을 비교한 예시입니다.이와 같이 RAG를 사용하면 LLM은 데이터를 추가로 학습할 필요 없이 특정 도메인이나 조직 내부 DB(예: LY의 AWX 서비스)로 AI 서비스를 확장할 수 있습니다.이처럼 RAG는 LLM에 질의할 때 외부 DB의 신뢰할 수 있는 데이터를 함께 전달해 더 정확한 답변을 생성하도록 유도하는 프로세스입니다. 하지만 질문할 때마다 외부 DB의 모든 데이터를 LLM에게 함께 전달한다면 답변 생성에 불필요한 데이터도 함께 전달되므로 비효율적일 것입니다. 예를 들어, "우리 회사의 AWX 관리자는 누구야?"라는 문의에 이 질문과 무관한 콘텍스트인 'AWX 가입 방법'과 '사용자 가이드' 등의 데이터를 모두 함께 전달한다면 비효율적이겠죠?이 문제를 개선하

안녕하세요. 카카오페이증권 DevOps 팀의 벨입니다.본 글은 다양한 Kubernetes 플랫폼에 서비스를 분산 배포하고, 클라우드 종속성을 줄이면서 장애 상황에도 유연하게 대응할 수 있는 구조를 통해 고가용성과 안정성을 동시에 확보한 클러스터 운영 경험을 공유합니다.클라우드 환경에서 운영 중인 서비스의 안정성 향상에 고민하는 분들을 위한 글입니다.서비스 가용률 99.999%. 많은 업계에서 이 수치는 단순히 “좋은 서비스의 상징”처럼 여겨지지만 증권업에서는 선택이 아니라 의무에 가깝습니다. 서비스가 몇 분 멈췄다는 사실보다 언제 장애가 발생했고, 얼마나 지속됐고, 그 여파가 어땠는지를 증명해야 하는 업이죠.단 0.001%의 가용성 손실은 하루 24시간 기준으로 약 5분의 장애를 의미합니다. 2024년 카카오페이증권의 SLO였던 99.993%는 객관적으로는 높은 수치입니다. 하지만, 증권업의 특성상 0.007%의 손실은 10분 이상의 장애로 고객이 제대로 돈을 벌 수 있는 투자 문화를 만들어가기 위해서는 이 수치조차도 부족할 수 있습니다.시스템이 잠시 멈춘 그 순간 고객의 중요한 투자 기회가 지나갈 수 있습니다. 즉, 기술적인 이슈를 넘어서 금융 서비스가 지켜야 할 고객과의 신뢰 문제로 이어집니다.그래서 스스로 묻게 됐습니다. “진짜 99.999%에 가까워질 수 있을까?” 그리고 이 질문은 자연스럽게 더 유연하고 견고한 인프라 구조, 더 빠른 장애 대응 체계, 플랫폼에 얽매이지 않는 서비스 운영 방식을 고민하게 만들었습니다.그 결과가 바로 이 글에서 소개할 멀티 클러스터 그리고 하이브리드 클러스터입니다.멀티 클러스터: 하나의 서비스를 n개의 클러스터에카카오페이증권의 서비스들은 총 3개(AWS EKS, IDC Kubernetes, KakaoCloud Kubernetes Engine)의 쿠버네티스 플랫폼 위에서 운영되고 있습니다. (* 이후 서술에서는 ‘KakaoCloud Kubernetes Engine’를 KC KE로 축약하여 표기합니다.)이렇게 다양한 클라우드 플랫폼을 사용하게 된 이유는 증권업이라는 업의 특성상, 장중 거래량의 급격한 변화에도 안정적으로 대응할 수 있는 유연한 인프라가 요구되기 때문입니다. 이러한 요구사항을 충족시키기 위해 다양한 클라우드 플랫폼을 활용하는 방향을 택하게 되었습니다.즉각적인 스케일링이 요구되는 서비스나 S3, CF 등 클라우드에서 제공하는 매니지드 인프라 서비스를 사용하는 경우 네트워크 경로 최적화 및 서비스 연동 편의성을 고려해 해당 서비스와 같은 클라우드 환경 즉, AWS EKS나 KC KE 위에 배포하는 방식으로 구성했습니다. 반면, 단순히 내부 시스템이나 데이터센터 내 서비스들을 호출하는 서비스의 경우에는 IDC Kubernetes 클러스터에서도 충분히 안정적으로 운영이 가능했고 비용과 운영 효율 측면에서도 더 적합한 선택이었습니다.물론 최근에는 IAM Role Anywhere 같은 기능을 활용해 KC KE나 IDC 클러스터에서도 AWS 리소스를 직접 사용할 수 있게 되면서 플랫폼 간 경계가 점점

geuru.geon DDD를 팀 내에 도입한 배경과 과정을 코드를 통해 더 쉽게 이해할 수 있는 글입니다. 혹시 독자분들이 정책이 견고한 도메인을 다루고 계시다면, DDD 도입도 좋아 보입니다! 필립의 경험을 통해 확인해 보시죠. 😊yooni.que 복잡한 도메인에서의 DDD 적용 과정을 예시와 함께 보다 구체적으로 이해하는 데 도움이 되는 문서입니다. 독자분들도 프로젝트팀의 입장에서 같이 고민해 보시며 DDD를 실제 프로젝트에 적용하는 데 한 걸음 더 나아갈 수 있기를 바랍니다.안녕하세요. 카카오페이 후불결제TF에서 Backend 개발을 하고 있는 필립입니다. 카카오페이 후불결제(BNPL)의 여신코어시스템을 DDD(Domain Driven Design, 도메인 주도 설계)로 구축한 경험을 공유하고자 합니다. 여신비즈니스가 시스템으로 구현되는 과정에서 DDD를 프로젝트 팀에서 어떻게 활용하였는지, 코드레벨에서는 어떤 구조로 설계하고 구현하였는지에 대해 공유하고자 합니다. 신규로 시스템 구축을 준비하시거나, 운영한 지 오래된 시스템을 다시 새로운 구조로 구축하고자 하시는 분들께 도움이 되었으면 좋겠습니다.DDD는 Eric Evans가 2003년 출간한 “Domain Driven Design”이라는 책에서 처음 소개된 개념으로, 복잡한 도메인 모델을 설계하고 구현하기 위한 방법론입니다. DDD는 도메인 전문가와 개발자가 협력하여 도메인 모델을 정의하고, 이를 기반으로 소프트웨어를 설계하는 것을 목표로 합니다. DDD는 다음과 같은 주요 개념을 포함합니다.• 도메인(Domain): 소프트웨어가 해결하고자 하는 문제 영역입니다. 예를 들어, 여신 시스템의 경우 대출, 심사, 승인 등의 도메인이 있습니다.• 유비쿼터스 언어(Ubiquitous Language): 도메인 전문가와 개발자가 공통으로 사용하는 언어로, 도메인 모델을 설명하는 데 사용됩니다. 이를 통해 팀원 간의 의사소통을 원활하게 하고, 도메인에 대한 이해를 높일 수 있습니다.• 바운디드 컨텍스트(Bounded Context): 도메인을 명확하게 구분 짓는 경계입니다. 각 바운디드 컨텍스트는 독립적으로 개발되고 배포될 수 있으며, 서로 다른 바운디드 컨텍스트 간의 상호작용은 명확한 인터페이스를 통해 이루어집니다.• 애그리거트(Aggregate): 도메인 모델의 일관성을 유지하기 위해 관련된 객체들을 묶어 관리하는 단위입니다. 애그리거트는 하나의 루트 엔티티(aggregate root)를 가지며, 외부에서는 루트 엔티티를 통해서만 접근할 수 있습니다.• 엔티티(Entity): 고유한 식별자를 가지며, 상태와 행동을 갖는 객체입니다. 엔티티는 도메인 모델의 핵심 구성 요소입니다.• 밸류오브젝트(Value Object): 고유한 식별자를 가지지 않으며, 불변성을 가지는 객체입니다. 값 객체는 도메인 모델의 속성을 표현하는 데 사용됩니다.왜 프로젝트팀은 DDD를 선택하였을까?카카오페이는 2021년 정부의 금융규제 샌드박스제도에 소액후불결제 후불교통 서비스를 인가받았습니다. 서비스를 위한 여

안녕하세요, Kanana LLM팀입니다. 저희는 언어모델의 성능을 꾸준히 개선하기 위해 지속적인 연구 개발에 매진하고 있으며, 최근 AI 분야의 주요 화두인 Agentic AI의 무한한 가능성에 주목하고 있습니다.Agentic AI는 스스로 목표를 설정하고 주변 환경과 상호작용하며 복잡한 과제를 자율적으로 계획하고 실행하는 지능형 시스템입니다. 이러한 Agentic AI가 제 기능을 제대로 발휘하려면 단순 정보 검색이나 텍스트 생성을 넘어, 사용자의 복잡한 의도를 파악하고 여러 단계의 추론을 통해 문제를 해결해야 합니다. 이때, 문제 해결을 위한 구체적인 실행 계획을 코드로 변환하고, 외부 도구 및 API와 효과적으로 연동하며, 사용자와의 긴 대화나 방대한 문서로부터 맥락을 정확히 파악하여 일관성을 유지하는 능력이 필수적입니다. 기존 LLM들이 특정 질의에 대한 응답 생성에는 능숙했지만, 이처럼 능동적이고 복잡한 작업을 자율적으로 수행하기에는 핵심 역량을 한층 더 발전시켜야 할 필요가 있었습니다.Kanana 1.5는 Agentic AI로서 역할을 할 수 있도록 코딩 및 수학 능력 고도화, Long context 처리 능력 확대, 그리고 Post-training 방법 개선을 통하여 사용성 강화를 주요 목표로 삼았습니다. 본 글에서는 기존 1.0 버전 대비 Kanana 1.5의 다각적인 개선을 위해 저희 팀이 기울인 노력과 그 구체적인 성과를 공유해 드리고자 합니다.Kanana LLM의 첫 번째 버전의 모델도 출시 당시에는 준수한 성능을 보였으나, 코딩과 수학 성능에서 상대적으로 아쉬운 측면이 있었습니다. 기존 학습 데이터는 주로 일반적인 웹 코퍼스에서 수집된 내용이 많아, 전문적이거나 고품질의 코드, 수학 데이터가 상대적으로 부족했습니다. 이러한 데이터로 학습된 모델은 때때로 피상적인 패턴만을 학습하여 복잡한 문제 해결에 실패하거나, 논리적 오류가 있거나 비효율적인 코드를 생성할 가능성이 있었습니다. 특히, 다단계 추론이 필수적인 수학 문제나, 실제 환경에서의 실행 정확성과 안정성이 중요한 코드 생성에 있어서는 이러한 한계가 더욱 두드러졌습니다. 예를 들어, 수학 문제에서는 풀이 과정의 논리적 비약이 발생하거나, 코드 생성에서는 특정 엣지 케이스를 고려하지 못하는 경우가 있었습니다.이러한 한계를 극복하기 위해 Kanana 1.5 개발 초기 단계에서는 다양한 공개 코드 및 수학 데이터셋을 면밀히 검토했습니다. 몇몇 데이터셋이 특정 영역에서는 가능성을 보였지만, 저희가 목표로 하는 포괄적인 품질, 충분한 데이터 양, 그리고 학습에 이슈가 없는 라이센스 조건을 만족시키는 경우는 찾기 어려웠습니다. 단순히 많은 데이터를 투입하는 것만으로는 해결되지 않는, 데이터의 '질’에 대한 근본적인 고민이 필요했습니다. 결국 Agentic AI로 가기위한 관련된 역량을 제대로 강화하기 위해서는 목표 성능에 부합하는 고품질 데이터를 직접 확보해야 한다는 결론에 도달했습니다. 여러 데이터 확보 방안 중, 특히 의도에 맞는 데이터를 수집해야한다는 점에서 우수한 성능의 LLM을 활용하여 통제된 환경에서 목적에 맞는 양질의 데이터를 직접 생성하는 것이 가장 효과적이고 효율적인 전략이라고 판단했습니다.LLM의 성능은 학습 데이터의 품질에 의해 결정된다고 해도 과언이 아닙니다. 특히 특정 도메인의 전문성을 높이기 위해서는 무작정 양을 늘리기보다는 데이터의 질을 높이는 것이 중요하며, 때로는 목적에 맞게 정교하게 설계하고 생성한 합성 데이터(Synthetic data)가 기대 이상의 효과를 가져오기도 합니다. 저희는 이러한 원칙에 따라 수학 및 코드 코퍼스 구축에 많은 노력을 기울였습니다.• 수학 코퍼스 생성 과정: 수학 문제를 잘 풀려면 논리적인 사고력과 단계별 추론 과정의 정확성이 뒷받침되어야 합니다. 따라서 학습 데이터를 어떻게 구성하느냐가 매우 중요합니다. 저희는 Apache 라이선스로 공개된 NuminaMath 데이터의 일부를 초기 시드(Seed) 코퍼스로 활용하여 데이터 생성의 일관된 스타일과 구조를 확보하고, 기본적인 품질 기준선을 설정했습니다. 이 데이터를 기반으로, 강력한 외부 고성능 모델 및 저희가 내부적으로 개발한 수학 문제 특화 모델들을 동원하여 문제에 대한 풀이 과정과 정답을 생성했습니다. 이 과정에서는 단순히 많은 문제를 생성하는 데 그치지 않고, 하나의 문제에 대해서도 여러 모델이 각기 다른 접근 방식이나 설명 스타일로 답변을 만들도록 유도했습니다. 이렇게 답변의 다양성을 확보하는 것이 모델이 다양한 문제 해결 전략을 학습하고, 특정 표현 방식에 과적합되지 않으며, 결과적으로 일반화 성능을 높이는 데 매우 효과적이라는 사실을 실험을 통해 확인할 수 있었습니다. 생성된 데이터는 최종 평가에 사용될 주요 벤치마크와의 데이터 중복 및 유사성을 제거하는 오염 제거(Decontamination) 과정을 거쳤습니다. 최종적으로 데이터 형식은 주로 문제와 상세한 풀이 과정 및 최종 정답의 쌍으로 구성하여, 모델이 정답뿐만 아니라 문제 해결 과정 자체를 학습하도록 유도했습니다.• 코드 코퍼스 생성 과정: 코드 데이터 역시 수학 데이터와 유사한 정제 및 생성 과정을 거쳤으며, 실용성과 다양성 확보에 중점을 두었습니다. 우선, 라이선스 문제가 없는 대규모 오픈소스 코드 저장소 그리고 알고리즘 학습 자료 등에서 다양한 난이도와 프로그래밍 언어, 그리고 다양한 문제 유형을 포괄하는 문제들을 시드(Seed) 데이터로 확보했습니다. 이후, 코드 생성에 특화된 최신 고성능 LLM들을 활용하여 확보된 문제에 대한 솔루션 코드를 생성했습니다. 수학 데이터 생성에서와 마찬가지로, 하나의 문제에 대해 여러 가지 유효하거나 스타일이 다른 코드 솔루션을 생성하여 모델이 다양한 코딩 패턴과 문제 해결 접근법을 학습하도록 했습니다. 이는 실제 개발 환경에서 다양한 스타일의 코드를 접하게 되는 상황에 대한 대비이기도 합니다. 최종적으로 HumanEval, MBPP 등 주요 코드 생성 벤치마크와의 오염 제거(Decontamination) 과정도 수행하였습니다.다른 벤치마크 성능을 유지하면서 수학 및 코딩 능력을 향상시키기

카카오의 자체 언어모델 ‘Kanana(카나나)’가 첫 공개된 지 3개월 만에, 한층 업그레이드된 ‘Kanana 1.5’를 새롭게 선보입니다.이번 연구 성과의 일환으로, 전체 언어모델 중 8B와 2.1B 두 모델을 상업적 활용까지 가능한 오픈소스로 공개합니다. Apache 2.0 라이선스로 누구나 자유롭게 사용할 수 있습니다.이번 공개는 단순한 기술 공개를 넘어, 국내 LLM 생태계의 활성화를 위해 열린 시도입니다. 연구자는 물론, 기업도 목적에 맞게 자유롭게 모델을 튜닝하고 활용할 수 있습니다. 복잡한 문제 해결부터 빠른 응답이 필요한 서비스까지, 다양한 분야에 즉시 적용 가능합니다.Kanana 1.5, 어떻게 달라졌을까요?이제 AI는 사용자의 명령 수행에서 더 나아가, 스스로 판단하고 행동하는 에이전트로 진화하고 있습니다. Kanana 1.5는 Agentic AI로 나아가기 위해 기존 모델 대비 수학과 코딩 능력을 크게 강화하고, 입력 길이(Context Length)를 확장했습니다. 또한, Function Calling 기능도 수행할 수 있도록 개선했습니다.Pre-training 단계에서부터 코딩 및 수학 데이터를 대폭 확대했고, 그 결과 글로벌 모델 대비 압도적인 한국어 성능은 물론, 코드 및 수학 문제 해결 능력에서 오픈소스 SOTA 모델에 견줄만 한 유의미한 수준의 성능을 달성했습니다. 또한, 에이전트로서 기본적으로 요구하는 능력인 Function Call, 즉 외부 도구나 API를 호출해 실제 작업을 수행하는 능력도 고도화하였습니다.이를 통해 Kanana 8B를 기준으로, 코딩과 수학 문제 해결, Function Calling 능력에서 이전 모델 대비 평균 1.5배의 성능 향상을 기록하였습니다.Pre-training부터 Post-training까지, 카나나 언어모델 라인업 전체(Flag, Essence, Nano)의 자세한 1.5 개발과정과 상세 성능은 해당 링크를 통해 확인해 보세요!2. 긴 문맥 이해와 간결한 답변으로 향상된 사용성Kanana 1.5는 더 긴 입력을 안정적으로 처리하면서도, 더 짧고 정확한 답변을 제공합니다.먼저 Context Length를 기존 8K에서 최대 128K까지 확장시켰습니다. 기존 1.0에서는 짧은 동화책 하나를 처리할 수 있었다면, 이제는 전공책 수준의 긴 입력도 처리할 수 있게 되었습니다.또한, 같은 질문에 대해 더 빠르고 정확한 답변으로 더 나은 대화 경험을 제공합니다. 일반적으로 응답을 짧게 만들면 정보가 누락되기 쉽지만, Kanana 1.5는 정확도를 유지하면서도 응답 길이를 최적화해 불필요한 설명 없이 핵심만 간결하게 전달합니다. 이는 응답 속도가 중요한 실제 서비스 환경에서 사용자 체감 성능을 실질적으로 높이는 요소로 작용합니다. 예를 들어, 대답이 1~2초 빨라진다거나, 10줄짜리 응답 중 핵심 문장 한 줄이 더 자연스럽게 표현되는 것만으로도 체감 성능은 전혀 다르게 다가옵니다.현재 카카오는 Kanana 1.5에서 그치지 않고, ‘오픈소스를 뛰어넘는 카카오 서비스에 최적화된 LLM’을 목표로 Kanana 2를 개발하고 있습니다. 더 긴 입력 처리, 정교한 추론, 구조적 효율성까지, 모든 영역에서 한층 진화한 차세대 모델을 준비 중입니다.앞으로도 지속적인 오픈소스 공개와 업데이트를 통해 더 많은 개발자와 연구자, 기업들이 국산 LLM의 가능성을 체감할 수 있도록 생태계를 확장해 나가겠습니다. 이러한 열린 접근이 국내 AI 생태계를 더욱 풍요롭게 만들고, 앞으로 더 많은 혁신적인 AI 모델이 등장하는 기회로 연결되길 기대합니다.지금 바로 Kanana 1.5를 자유롭게 활용해 보세요! 👉 Kanana 1.5 다운로드 👉 Kanana 1.5 개발기 바로가기• 이미지와 음성을 아우르는 카카오의 멀티모달 언어모델 Kanana-o 알아보기• 작지만 강한 Kanana Nano 효율적으로 개발하기• 이미지도 찰떡같이 이해하는 카카오의 멀티모달 언어모델 Kanana-v 알아보기• 나만의 프로필 이미지 생성 모델 개발기• 카카오의 AI 모델, 카나나 모델 패밀리를 소개합니다

ZoneRulesException :: Unknown time-zone ID: Europe/Kyiv평소에 못 보던 오류가 발생했다. 보자마자 바로 알았다. 아 러시아 우크라이나 전쟁 때문이구나.키이우: Europe/Kyiv키예프: Europe/Kiev2022년 러시아가 우크라이나를 침공했을 때 전 세계적으로 우크라이나 수도의 이름을 키예프에서 키이우로 바꾸자는 운동이 일어났다. 이 때문에 구글 지도를 비롯한 나무위키, 위키백과에서 모두 우크라이나어와 발음이 비슷한 키이우로 변경이 됐다. 타임존까지 영향을 주었구나.회사에서 사용하고 있는 코파일럿에 해결 방법을 물어봤다. 내 예상과 비슷하게 답을 했다. JVM 버전을 올리거나 ‘IANA TZDB’ 업데이트하면 된다. IANA(Internet Assigned Numbers Authority)는 처음 들어 보는 키워드였다. IANA는 여러 가지 역할을 하는 기관인데, 여기서는 그중 하나가 타임존을 관리하는 것이라고 알고 넘어가자.아래 주소에서 최신 타임존 데이터를 다운로드 받을 수 있다.https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz압축을 풀면 대륙별로 파일이 있다. europe 파일을 열어보니 예상한 대로 Europe/Kyiv 타임존이 있다. 문득 우리나라도 궁금해서 asia 파일도 열어 봤다.아래는 서울과 평양에 해당하는 타임존 데이터다.# Zone NAME STDOFF RULES FORMAT [UNTIL]Zone Asia/Seoul 8:27:52 — LMT 1908 Apr 1 8:30 — KST 1912 Jan 1 9:00 — JST 1945 Sep 8 9:00 ROK K%sT 1954 Mar 21 8:30 ROK K%sT 1961 Aug 10 9:00 ROK K%sTZone Asia/Pyongyang 8:23:00 — LMT 1908 Apr 1 8:30 — KST 1912 Jan 1 9:00 — JST 1945 Aug 24 9:00 — KST 2015 Aug 15 00:00 8:30 — KST 2018 May 4 23:30 9:00 — KST타임존 변화 기록으로 보인다. 코파일럿에 해석을 시켰더니 내 예상이 맞았다.우리나라는 1908년까지 타임존 개념이 없었다. 이에 비해 일본(도쿄)은 1887년, 미국(뉴욕)은 1883년, 그리니치 천문대가 있는 영국(런던)은 1847년에 타임존 개념을 도입했다. 과학기술을 발전시키기 위해서는 표준화가 바탕에 있어야 한다. 타임존의 도입 시기부터 우리나라는 근대화에 뒤처졌다는 것을 알 수 있다.더 슬픈 건 그다음이다.국권피탈 시기 중 1912년부터 1945년까는 JST를 사용했다. 일본은 이렇게 우리의 주권을 철저하게 빼앗아 간 것이다. 1945년 광복 이후 약 한 달 만인 9월 8일에 다시 KST를 사용해 우리나라의 표준화 주권을 찾았다. 그 이후로 여러 정치, 경제적인 이슈로 08:30으로 갔다가 다시 지금 우리가 사용하고 있는 09:00로 이동했다.북한은 우리보다 조금 이른 8월

안녕하세요, 여기어때 iOS 개발팀 드락입니다.여기어때 앱은 당연! 하게도 지도 기반 탐색 기능을 제공하는데요, 오늘은 모바일 앱에서 지도 기반 기능을 구현할 때 이해하고 있으면 좋은 특성과, 최근 진행한 지도 검색 로직 개선 포인트에 대해 공유드리고자 합니다.“같은 줌 레벨에서 지도는 디바이스마다 다른 영역을 보여줍니다.”여기어때 앱은 국내 사용자를 위한 지도 기능 구현에 네이버 지도 엔진을 활용하고 있습니다. 우선 스크린샷을 한 장 보시죠.좌측 아이폰 / 우측 갤럭시 폴드두 디바이스 모두 지도의 줌 레벨은 14입니다. 소수점은 표기하지 않았지만 완전히 동일한 값으로 설정되어 있습니다. 하지만 보시는 것처럼, 같은 줌 레벨임에도 불구하고 각각 보이는 지도 영역은 확연히 다릅니다. 9시부터 6시 방향으로 한번 살펴보자면 아이폰은 ‘블루맨 뮤지컬웨딩’부터 ‘길목 신관’까지, 갤럭시 폴드는 ‘S-Tower’부터 ‘삼성동더샵’까지 지도 화면 안에 들어옵니다. 줌 레벨은 같더라도 지도에 표기되는 영역에 차이가 있죠?극적인 비교를 위해 아이폰과 갤럭시 폴드를 예시로 삼았지만, 아이폰이라고 하더라도 모델에 따라 화면의 크기와 해상도가 다르기 때문에 동일한 줌 레벨에서 지도에 표시되는 영역에 차이가 있을 수 있습니다.좌측 iPhone 12 Pro Max / 우측 iPhone 13 mini. 보여지는 범위가 다르죠?지도엔진의 동작 성격 상 디바이스 화면의 크기와 관계없이 같은 줌 레벨에서는 같은 축척의 지도를 제공하는 느낌이라고 이해하면 될 것 같은데요(따라서 화면 크기가 큰 디바이스에서 지도가 더 크게 보이는게 아니라 더 넓은 영역을 화면에 표시하게 됩니다.) 여기에 추가로 디바이스 스크린의 해상도에 따라 조금씩 달라지는 부분도 있어서요 그냥..‘같은 지도 같은 줌 레벨이어도 폰이 다르면 노출 영역이 다를 수 있구나’정도까지만 인지해 두고 넘어가면 좋을 것 같습니다:)“레거시 지도 재탐색 방식, 그리고 고민들..”이제 지도 화면 기준으로 제휴점을 검색해서 화면에 표시하는 기능을 이야기드려 볼게요. 먼저 레거시 지도 검색 로직을 간단하게 정리해보겠습니다.앱에서 디바이스의 줌 레벨과 중앙 좌표값을 서버에 보냄서버는 전달받은 줌 레벨에 보편적인 차원에서 최대한 스무스하게(?) 대응되도록 만들어둔 줌 레벨-반경 맵핑 테이블을 참조하여 지금 줌 레벨에서는 이 반경값으로 검색하면 되겠다고 알아냄중앙 좌표를 기준으로 반경검색을 수행하여 결과를 앱에 제공해 줌public enum ZoomType { ... LEVEL_21(30, 21), LEVEL_20(30, 20), LEVEL_19(50, 19), LEVEL_18(100, 18), LEVEL_17(500, 17), LEVEL_16(1000, 16), LEVEL_15(1000, 15), LEVEL_14(1000, 14), LEVEL_13(1500, 13), LEVEL_12(3000, 12), LEVEL_11(5000, 11), LEVEL_10(10000, 10), LEVEL_9(20000, 9), LEVEL_8(

글. 한동현(Noah) / Product Brand Designer작년 말, 여기어때는 YDS 6.0 프로젝트를 통해 홈 리스킨을 진행했어요. 그 중에서도, 앱 메인 상단의 카테고리 아이콘 개선이 큰 변화였는데요. 이번 글에서는 그 과정과 아이콘 개선에 대해 소개할게요.아이콘 개선 방향이번 홈 카테고리 아이콘 개선 작업은 두 가지 핵심 방향을 중심으로 진행되었어요.누구나 직관적으로 이해할 수 있는 메타포아이콘은 짧은 시간 안에 의미를 전달해야 하는 UI 요소예요. 따라서, 누구나 처음 봐도 이해할 수 있는 보편적인 메타포를 기준으로 아이디어를 구성했어요. 복잡한 형태보다는 단순하고 명확한 상징을 통해, 사용자가 고민 없이 빠르게 선택할 수 있도록 했어요.익숙함은 유지하되, ‘Lively’ 더하기기존 아이콘의 사용자의 경험을 해치지 않으면서도, 이번 YDS 6.0 리디자인의 핵심 가치 중 하나인 ‘Lively(Spark Joy with Design)’한 감성을 담아내고자 했어요. 생동감 있고 유쾌한 분위기를 더해, 아이콘만 봐도 ‘여기어때’스러움이 느껴질 수 있도록 디자인했어요.Lively란?Lively는 여기어때 비주얼 리디자인 과정에서 정의한 코어 밸류 중 하나로 여행의 설렘처럼 생동감 있는 감성을 전하는 디자인 원칙이에요.Casual UT에서 찾은 리디자인의 힌트처음에는 기존 아이콘이 사용하는 가구 중심 메타포(침대, 쇼파 등)를 그대로 유지하면서 스타일만 리뉴얼하는 방향으로 접근했어요. 이미 사용자들에게 익숙한 메타포였기 때문에, 그 틀을 굳이 바꿀 필요는 없다고 생각했어요.그래서 리뉴얼 스타일만 적용한 상태에서 Casual UT를 진행했는데요, 예상과는 다르게 ‘가구’로 표현된 아이콘들이 실제 카테고리와 잘 연결되지 않는다는 피드백을 받았어요. 예를 들어, ‘침대’ 아이콘만 봐서는 모텔인지 호텔인지 구분하기 어렵다는 의견이 있었어요.Casual UT 결과를 분석하면서, ‘해외 숙소’, ‘모텔’, ‘호텔’처럼 클릭률이 높은 카테고리는 기존의 가구 중심 아이콘보다는 건물 형태로 표현하는 것이 더 명확할 수 있겠다는 생각이 들었어요. 건물 형태를 사용하면 카테고리 간 시각적 구분이 더 뚜렷해지고, 아이콘이 의미하는 바도 더 직관적으로 전달될 수 있을 것 같았어요.특히, 가구처럼 상황에 따라 해석이 달라질 수 있는 메타포보다는, 공간의 특성을 직접적으로 드러내는 방식이 인지 측면에서 더 효과적일 거라는 가설을 세웠어요. 클릭률이 높은 카테고리일수록 유저가 혼동 없이 빠르게 이해할 수 있도록 시각적 오해를 줄이는 것이 중요하다고 판단했기 때문이에요.하지만 여기서부터 새로운 고민이 시작됐어요. ‘건물’이라는 단어 자체는 분명하고 직관적인데, 실제 아이콘으로 표현하려고 하다 보니 어떤 기준으로 어디까지 다르게 그려야 할지가 애매했어요. 현실 속 건물 형태는 너무 다양해서, 자칫하면 호텔이 모텔처럼 보이거나, 그 반대로 보일 수도 있었거든요.그래서 각 카테고리 메타포의 시각적 특징을 좀 더 명확히 정의하기 위해, 실제 건물 이미지를 수집하고 분

화면을 아래로 당기면 나오는 그래픽, Pull To Refresh. 그 짧은 찰나에 아름다움을 담기 위한 고민을 들려드려요.