카카오의 Kanana 팀은 인간처럼 보고, 듣고, 말할 수 있는 통합 멀티모달 언어 모델 개발에 집중하고 있다. 기존 AI 음성 모델이 문법적으로 정확하고 자연스러운 음성 생성에만 주력했다면, Kanana 팀은 사용자가 원하는 방식으로 말하게 하는 것의 중요성에 주목했다. 이는 음성 AI가 개별 사용자의 의도와 맥락을 더 잘 반영해야 한다는 문제 인식에서 출발한다.

State of CSS 2026은 CSS 생태계의 트렌드와 개발자 선호도를 파악하기 위해 매년 진행되는 설문조사다. 올해는 5월 중순부터 6월 말까지 약 6주간 진행되어 4,902명의 개발자로부터 응답을 수집했으며, 앵커 포지셔닝을 포함한 최신 CSS 기술들에 대한 의견을 수렴했다.

당근의 데이터 가치화팀은 '매일 데이터를 통해 사용자를 위한 의사결정을 한다'는 비전 아래 전사 차원의 데이터 인프라와 도구 개발을 주도하고 있다. 이들이 만든 실험플랫폼은 어떤 기획안이 더 나은지 객관적으로 검증할 수 있도록 A/B 테스트 환경을 제공한다. 약 3년 전부터 운영된 이 플랫폼은 실험 설계부터 결과 분석까지의 전체 과정을 하나의 공간에서 지원함으로써 100명 이상의 팀원들이 더 나은 의사결정을 내릴 수 있게 돕고 있다.

카카오의 Kanana 조직은 보고, 듣고, 말하는 통합 멀티모달 언어모델을 개발하고 있다. 지난 5월 국내 최초로 해당 모델을 공개한 이후, 팀은 실제 서비스 환경에서 더 나은 사용자 경험을 제공하기 위해 음성 생성 기능을 지속적으로 개선하고 있다.

이번 고도화 과정은 단순히 자연스러운 음성 생성을 넘어, 사용자의 다양한 요구사항과 맥락에 맞게 음성을 생성하는 것으로 방향을 설정했다. 이는 AI의 표현력을 높이고 개별 사용 사례에 더 정확하게 대응할 수 있도록 한다.

데이터 사이언티스트는 주로 노트북 환경에서 모델을 개발하고 실험하는 데 집중하지만, 실제 프로덕션 환경에서 모델을 안정적으로 서빙하는 것은 별개의 도전 과제다. ML 엔지니어는 이러한 모델을 실제 서비스 환경에 배포하고 운영하는 역할을 담당하며, 두 직군 간의 효과적인 협업이 없으면 훌륭한 모델도 실제 가치를 발휘하기 어렵다.

Line의 Home SRE 팀은 장애 분석 시 메트릭은 Grafana/IMON, 로그는 LaaS/IU, 트레이스는 IMON 트레이스/Tempo, 프로파일은 별도 도구에서 각각 확인해야 했다. 도구 간 전환뿐 아니라 시간 범위, 서비스명, 라벨, 트레이스 ID 같은 분석 컨텍스트를 계속 옮겨 적어야 하는 비용이 컸고, 특히 장애 상황에서는 이 컨텍스트 스위칭이 큰 부담이었다.

SRE 팀은 먼저 자체 호스팅형 LGTM-P 스택(Loki, Grafana, Tempo, Mimir, Pyroscope)을 구축했고, OpenTelemetry Collector를 중심으로 메트릭·로그·트레이스·프로파일을 한곳에 모았다. 이를 통해 쿼리 성능, 보관 기간, 샘플링 정책, 데이터 간 연결 방식을 직접 조정할 수 있게 됐다. 그러나 데이터가 모여도 사용자는 여전히 데이터소스 선택, 라벨 규칙, 시간 범위 설정을 알아야 했다. 특히 같은 '서비스 이름'도 Prometheus 메트릭에서는 service_name, Tempo에서는 resource.service.name으로 표현되는 차이 같은 운영 지식이 숙련된 SRE의 머릿속에만 있었다.

기존 오픈소스 Grafana LLM 플러그인 PoC로 확인한 한계는 다섯 가지였다. 첫째, 사용자 컨텍스트와 권한을 Grafana 인증 정보 기준으로 안정적으로 전파받기 어려웠다. 둘째, 도구 호출 순서, 재시도 정책, 위험한 작업 제한 같은 운영 정책을 사용자 질의와 분리하여 체계적으로 관리하기 어려웠다. 셋째, 기본 도구 호출 라운드가 짧아서 메트릭→트레이스→로그로 이어지는 다단계 분석이 중간에 끝났다. 넷째, 데이터 소스별 라벨 차이를 처리하지 못해 쿼리가 0건 결과를 반환했다. 다섯째, 운영 환경에 맞게 수정해 배포하기에는 라이선스와 제약이 있었다.

이 PoC 경험을 통해 팀은 '자연어 질의 자체보다 중요한 것은 LLM 에이전트의 행동을 운영 환경에 맞게 통제할 수 있는 제어권'이라는 결론에 도달하고, SRELens를 직접 구현하기로 결정했다. SRELens는 Grafana 애플리케이션 플러그인으로 프런트엔드는 채팅 UI를, 백엔드는 LLM 호출·도구 오케스트레이션·프롬프트 합성·사용량 제어를 담당하며, MCP 게이트웨이를 통해 관측성 데이터를 조회한다.

최근 LLM은 공개된 지식 질문에는 뛰어난 능력을 보이지만, 기업 내부의 정책·코드·회의록·메신저 등에 흩어진 정보에 기반한 질문에는 제대로 답하지 못한다. 필요한 정보가 여러 출처에 분산되어 있고, 각 정보가 현재도 유효한지, 서로 충돌하지 않는지 판단하기 어렵기 때문이다. 초기에는 이를 검색 문제로 접근했으나, 검색 결과가 개선되어도 문서 최신성·실제 코드와의 일치도·메신저 논의의 최종성 등을 판단할 수 없다는 근본적 한계가 남았다.

토스는 이 문제를 재정의하여 '검색을 잘하는 것'이 아니라 'LLM과 사람이 함께 신뢰할 수 있는 컨텍스트를 관리하는 것'이 핵심임을 깨달았다. 이를 위해 만든 시스템 Topic은 문서·코드·사내 메신저의 원본 데이터를 공통의 ContentUnit 형태로 정규화하되, 각 출처의 의미적 완결 단위와 신뢰 판단 방법을 보존한다. 신뢰도를 단일 점수(예: 0.87)로 압축하지 않고, 원본 근거 충분성·최신성·일관성·출처 명확성 등을 독립적인 여섯 가지 축으로 나누어 관리한다.

출처별로 가장 적합한 추출 방식을 적용한다. 문서는 고정 길이가 아닌 Markdown 제목 계층을 기준으로 분할하여 문맥 구조를 유지하고, 사내 메신저는 개별 메시지가 아닌 스레드 전체를 의미 단위로 요약하여 결정의 최종성을 보존한다. 코드는 파서로 함수·클래스 같은 심볼을 추출한 후, 비즈니스 동작을 설명하는 semantic card(subject, behavior, domain_terms, code_terms, spans)로 여러 심볼을 묶어낸다.

코드 semantic card는 LLM 에이전트가 import graph 중요도와 변경 빈도 신호로 우선순위를 정한 영역부터 시작하여 실제 구현을 추적하며 생성한다. 생성 후에는 규칙 기반 검사로 파일·줄 위치의 실제 존재 여부, span 검증, 반복 제거, 지역 편중 방지를 검증한다. 최신성 검사 시에도 카드의 설명만 신뢰하지 않고 현재 코드의 실제 span을 직접 재읽음으로써, 설명과 구현 간 괴리를 감지한다.

토스가 네뷸라를 만들기 전, 각 팀은 자체 테스트 자동화 환경에서 폰을 직접 꽂고 관리하며 기기 운영이라는 부업을 강요받고 있었다. 이는 테스트 코드 작성과 품질 향상이라는 본업에 집중하지 못하게 했다. 네뷸라의 출발점은 이 중앙화되지 않은 비효율을 한 곳으로 모아 전문적으로 운영함으로써 각 팀이 자신의 일에만 집중할 수 있게 하는 것이었다.

네뷸라는 작은 규모에서 시작했다. 맥미니 5대에 기기 15대, 개발자는 1명으로 6개월을 고군분투한 후 팀원이 합류해 현재 1년째 운영 중이며, 기기 수는 100대를 넘어 수백 대를 향해 계속 증설되고 있다. 단순한 목표—'누구든, 어디서든, API 호출 한 번으로 실기기를 제어'—를 위해 뒤에서는 복잡한 아키텍처가 작동한다.

네뷸라의 4단계 아키텍처는 클라이언트(Frontend, SDK·CLI, API 직접 호출), 오케스트레이션 서버(Kafka 기반 메시지 큐와 여러 러너가 테스트 요청을 분산 처리), 에이전트(호스트에서 로컬 기기 자동 발견 및 관리), 기기 계층(호스트당 controller server 1개, 실제 터치 및 입력 수행)으로 구성된다. 서버는 분산 락(occupy·assign·release)을 통해 한 기기에 여러 테스트가 동시 접근하는 것을 방지한다.

Appium을 버리고 직접 만든 Nebula Driver는 세 가지 이점을 제공한다. 첫째, 속도 우선의 철학으로 안드로이드 클릭·입력이 Appium 대비 10배 이상 빠르다(Appium의 80%는 화면 안정화 대기 시간). 둘째, stateless HTTP 호출 방식으로 세션 기반 Appium의 시작 비용과 확장에 따른 세션 실패를 제거했다. 셋째, 인터페이스 스펙을 자체 소유해 필요한 커스텀을 즉시 적용할 수 있다. Android는 ADB와 UiAutomation 위에, iOS는 Swift·XCTest 위에 얇게 얹었으며, OpenAPI 스펙으로 정의해 Go·TypeScript 코드를 자동 생성했다.

가장 큰 기술적 과제는 '보면서 동시에 조작'이었다. 기기가 서버실에 있어 직접 볼 수 없으므로, 테스트 작성자가 실시간 화면 미러링을 보며 동시에 기기를 제어할 수 있어야 했다. Android 미러링은 scrcpy의 인코딩 방식을 참고해 직접 내재화했으며, SurfaceControl로 가상 디스플레이를 생성하고 MediaCodec으로 H.264 영상으로 인코딩한 후 브로드캐스터를 통해 여러 시청자에게 동시 전송한다. iOS의 경우 기술적 세부사항이 본문에서 미완이지만, USB라는 벽이 가장 오래 지속된 문제였다.

LINE Android 팀은 대규모 모바일 개발 환경에서 AI 코딩 에이전트를 도입했습니다. 수백 명의 개발자가 수백 개의 Gradle 모듈로 이루어진 단일 Git 저장소에서 함께 작업하고 있으며, Claude Code를 비롯한 여러 AI 에이전트를 일상적으로 활용 중입니다. 그러나 이러한 규모에서는 에이전트가 토큰을 과도하게 소비하는 상황이 빈번하게 발생합니다.

대규모 저장소에서 기존의 텍스트 검색 방식(grep/glob)은 방대한 결과를 반환하고, 이 결과가 에이전트의 컨텍스트에 포함되면 비용이 빠르게 증가합니다. 더 근본적인 문제는 텍스트 검색이 '이 심볼이 어디에서 선언되는지' 같은 의미론적 질문에 정확히 답할 수 없다는 점입니다. 에이전트가 질문과 무관한 결과에 의존해 재시도를 거듭하면서 토큰 낭비가 기하급수적으로 증가하며, 모듈이 많을수록 이 비효율은 더욱 커집니다.

LINE 팀은 Google의 Android CLI 도입을 통해 이 문제를 해결하기 시작했습니다. 가장 먼저 적용한 기능은 공식 문서 검색으로, 기존의 Google Cloud Knowledge MCP 서버를 대체했습니다. 기존 방식은 수백 명 규모의 개발자마다 개별적으로 API 인증을 구성해야 했고, 운영 복잡도를 줄이기 위해 인증 프락시를 도입했지만 결국 할당량 제한 대응 로직까지 유지해야 했습니다. Android CLI로의 교체는 이 모든 부수 인프라를 제거하면서도 에이전트가 최신 공식 문서를 적은 토큰으로 참조할 수 있게 해줍니다.

LINE 팀은 Android CLI 바이너리를 Git 저장소에 번들링하는 방식을 선택했습니다. 저장소의 고정 경로(.agents/tools/android-cli/android)에 바이너리를 포함함으로써 개발자 장비, CI, 에이전트 실행 호스트 등 모든 환경에서 동일한 버전이 배포되어 환경 파편화를 방지합니다. 보안 정책상 에이전트 호출 시 불필요한 데이터 수집을 제어하기 위해 래퍼를 통해 필수 인자를 강제해야 하는데, 이를 위한 전제 조건이 바이너리의 고정 경로 번들링입니다. 또한 대규모 저장소가 이미 git-lfs를 적용 중이어서 바이너리 포함의 비용도 크지 않았습니다.

카카오는 지난번 'Kanana Nano'에서 비용 효율적인 SLM 개발 방법론을 제시한 바 있습니다. 이번 글에서는 그 뒤를 잇는 두 번째 SLM 시리즈인 Kanana-2를 소개합니다. 개발 조직은 더 강력한 성능을 실현하면서도 모델을 더욱 작게 만드는 데 초점을 맞췄습니다.

Kanana-2-3B 등의 모델이 공개될 예정이며, 카나나 LLM 조직의 개발자들이 그동안의 경험과 기술적 접근 방식을 상세히 다룰 것으로 보입니다. 이를 통해 제한된 리소스에서도 효율적으로 언어모델을 구축할 수 있는 방법을 제시하고자 합니다.

네이버 사내에서 개최된 '모두의 Engineering Day AI 해커톤'에 참여한 팀이 낯선 재무 업무 영역에서 AI 기반 솔루션을 개발해야 하는 과제에 직면했다. 처음에는 자연스럽게 AI의 자동화 능력에 초점을 맞춰 무엇을 자동으로 처리할 수 있을지에 집중했다. 그러나 프로젝트가 진행되면서 팀의 질문은 근본적으로 달라지기 시작했다.

AI가 할 수 있는 일의 범위보다 어떤 작업을 안심하고 맡길 수 있을지, 결과가 그럴듯해 보이는 것보다 실제로 틀렸을 때 그것을 발견하고 설명할 수 있는지, 자동화 자체보다 AI 시스템이 작동하지 않을 때도 업무가 중단되지 않도록 설계할 수 있는지가 더 중요한 기준으로 부각됐다. 이는 현업에서 AI를 도입할 때 단순한 효율성보다 신뢰성과 복원력을 먼저 고려해야 함을 시사한다.

당근의 광고주플랫폼팀은 광고주가 광고 생성부터 성과 리포트 확인까지 모든 과정을 당근의 내부 구조를 몰라도 쉽게 할 수 있는 플랫폼을 운영한다. 이는 웹 화면과 서버가 하나의 매끄러운 흐름으로 이어져야만 가능한 일이다. 그러나 올해 초까지 이 팀의 조직 구조는 이 목표와 맞지 않았다.

프론트엔드와 백엔드가 별도의 팀으로 분리되어 있었기 때문이다. 단 하나의 기능을 내려놓기 위해서도 프론트엔드와 백엔드에 각각 티켓이 생성되어야 했고, 두 팀의 스프린트 일정까지 별도로 조율해야 했다. 사용자의 일관된 경험을 만들어야 한다는 목표와 조직 운영 방식 사이에 거리가 생긴 것이다.