kakao·2026년 8월 6일·4분 읽기큐레이션 요약

개인화된 Airflow 테스트 환경 구축 및 운영 경험

수천 개의 Airflow DAG를 운영하는 카카오 데이터서비스 조직은 테스트 과정의 반복 작업과 환경 간 차이, 리소스 충돌 문제를 해결하기 위해 PR 단위의 개인 Airflow 환경인 AirZone을 구축했습니다. AirZone은 GitHub PR 코멘트에서 생성·삭제를 요청하면 Kubernetes Job과 전용 Helm 차트로 격리된 Airflow를 배포합니다. 사용자는 인프라를 직접 구성하지 않고 실제 운영 환경과 유사한 하둡·인증 환경에서 DAG를 테스트할 수 있습니다. ## 기존 테스트 방식의 한계 - **로컬 Airflow** - Airflow뿐 아니라 하둡 인증, 연결 설정, Docker 환경까지 직접 구성해야 합니다. - 초기 구축 비용이 크고, 로컬 환경과 운영 환경의 차이로 인해 실제 배포 후 실패할 수 있습니다. - **개발용 Airflow** - 코드를 커밋하고 푸시한 뒤 GitHub webhook, submodule 업데이트, DAG 파일 처리 과정을 기다려야 합니다. - DAG를 수정할 때마다 동기화 지연이 반복되어 개발 속도를 떨어뜨렸습니다. - **테스트용 Airflow** - SSH 컨테이너에 로컬 파일을 복사해야 하므로 코드 수정 때마다 추가 작업이 필요합니다. - 실제 데이터와 하둡에 접근하려면 prod VPN을 연결해야 하는 불편도 있었습니다. - **Production Airflow에서의 테스트** - 테스트 DAG가 스케줄러와 워커 자원을 점유해 다른 프로젝트의 실행을 지연시킬 수 있습니다. - 과도한 리소스 사용으로 노드 장애가 발생하면 같은 노드의 다른 태스크까지 중단될 위험이 있습니다. ## AirZone의 핵심 요구사항 - Kubernetes나 Helm을 몰라도 브라우저에서 Airflow 환경을 생성하고 삭제할 수 있어야 합니다. - 사용자는 DAG 검증에만 집중하고, 인프라 구성은 AirZone이 담당해야 합니다. - Jupyter Notebook을 제공해 별도 로컬 환경 없이 코드를 수정할 수 있어야 합니다. - 운영 환경과 유사한 DAG 실행 환경과 하둡 인증 방식을 제공해야 합니다. - PR마다 독립된 Airflow를 생성해 사용자와 테스트 작업을 서로 격리해야 합니다. ## PR 단위의 격리된 환경 - 레포지터리명과 PR 번호를 조합해 Kubernetes 네임스페이스를 생성합니다. - Airflow 웹 서버, 스케줄러, PostgreSQL, Jupyter, DAG PVC, 로그가 PR별로 분리됩니다. - 한 PR의 테스트가 다른 프로젝트의 스케줄러·워커 자원을 침범하지 않습니다. - 리뷰어는 PR에 남은 링크로 특정 코드 상태의 실행 결과를 직접 확인할 수 있습니다. - PR이 종료되면 네임스페이스를 기준으로 관련 리소스를 쉽게 정리할 수 있습니다. ## 요청 처리와 배포 작업의 분리 - `airzone-api`는 PR 존재 여부, PR이 열려 있는지, 네임스페이스 중복 여부 등 요청의 유효성만 검증합니다. - 실제 Helm 설치와 헬스체크는 별도의 Kubernetes Job이 수행합니다. - API가 수 분이 걸리는 배포 작업을 직접 기다리지 않으므로 빠르게 응답할 수 있습니다. - Job별로 상태와 로그가 독립적으로 남아 실패 단계와 원인을 추적하기 쉽습니다. - 실패한 Job을 삭제한 뒤 새 Job을 생성하는 방식으로 배포를 재시도할 수 있습니다. - 생성 요청은 `create-airzone-{namespace}`, 삭제 요청은 `delete-airzone-{namespace}` 형식의 Job 이름을 사용합니다. ## GitHub PR 코멘트를 사용자 인터페이스로 활용 - PR 생성 이벤트를 webhook으로 받아 저장소, 브랜치, PR 번호, 요청자 정보를 확인합니다. - 사용자가 선택할 수 있도록 하둡 환경별 AirZone 생성 링크를 PR 코멘트에 남깁니다. - 생성 완료 결과와 접속 정보도 PR에 표시해 별도 플랫폼 없이 테스트를 시작할 수 있습니다. - 다만 Jupyter 토큰과 Kubernetes 네임스페이스 토큰처럼 민감한 정보는 공개 범위가 넓은 PR 대신 카카오워크로 전달합니다. - 요청 접수와 배포 완료 시점에 카카오워크 알림을 보내 진행 상태를 알립니다. ## 전용 Helm 차트로 구성한 Airflow 기존 운영용 Airflow 차트가 아닌 AirZone 전용 Helm 차트를 만들어 테스트 환경에 필요한 구성만 묶었습니다. - **Airflow 구성** - 웹 서버와 스케줄러를 배포합니다. - `KubernetesExecutor`, DAG 스캔 주기, 로그 설정, 하둡 관련 변수를 테스트 환경에 맞게 설정합니다. - **데이터베이스와 저장소** - 개인 환경용 PostgreSQL을 함께 배포합니다. - scheduler와 Jupyter가 같은 DAG 작업 디렉터리를 사용하도록 DAG PVC를 공유합니다. - **DAG 동기화** - PR의 head repository와 branch 정보를 받아 해당 코드만 동기화합니다. - Git 초기화 컨테이너 등을 통해 배포 환경에 테스트 대상 DAG를 준비합니다. - **인증과 보안** - 사용자·공용 principal, 키탭, Jupyter 토큰을 환경에 주입합니다. - 하둡 접근에 필요한 Kerberos 인증을 운영 환경과 유사하게 구성합니다. - dkos에서 제공하는 TLS 인증서도 테스트 환경에 반영합니다. - **운영 연동** - 여유 있는 노드 그룹과 같은 리전의 `storageClass`를 선택합니다. - Airflow 로그를 Elasticsearch와 Kibana에서 확인할 수 있도록 연결 정보를 주입합니다. - Jupyter를 함께 제공해 브라우저에서 DAG와 관련 코드를 수정할 수 있게 합니다. ## 자동 정리와 운영 구조 - 생성·삭제 요청은 Kubernetes Job으로 처리합니다. - PR 종료 후 남아 있는 AirZone은 매일 실행되는 CronJob이 자동으로 회수합니다. - 사용자에게는 “PR 코멘트의 링크를 누르는 기능”으로 단순하게 보이지만, 운영자는 요청·설치·헬스체크·알림·정리 단계를 각각 추적할 수 있습니다. - 운영 환경에서 불필요한 PGBouncer나 외부 DB 연결 등은 제외해 개인 테스트 환경의 복잡도와 비용을 줄였습니다. AirZone과 같은 구조를 도입할 때는 테스트 환경을 운영 환경과 최대한 유사하게 유지하되, PR 또는 브랜치 단위로 리소스를 격리하는 것이 중요합니다. 또한 긴 배포 작업은 API 요청과 분리하고, Kubernetes Job의 상태·로그·재시도 기능을 활용하면 장애 대응과 운영 추적이 훨씬 쉬워집니다.

원문 읽기(새 탭에서 열림)

쿠버네티스PostgreSQLapache-sparkhelm+3

kakao·2026년 8월 3일·1분 읽기큐레이션 요약

말을 잘하는 AI를 넘어: 사용자가 원하는 방식으로 말하는 Kanana-o 만들기

제공된 내용에는 본문이 포함되어 있지 않고, 제목·작성자 정보·페이지 내비게이션만 있습니다. 따라서 Kanana-o 음성 생성 고도화 과정의 핵심 주장이나 기술적 세부 사항을 정확히 요약할 수 없습니다. ### 확인 가능한 정보 - 글 제목: **Beyond AI That Speaks Well: Making Kanana-o Speak the Way Users Want** - 관련 한국어 제목: **잘 말하는 AI를 넘어, 원하는 대로 말하는 AI로: Kanana-o 음성 생성 고도화 과정** - 작성자: martin.gale, abigail.r, edwin.ai - 본문 대신 다음·이전 글 링크와 검색 메뉴만 제공됨 본문 내용을 추가로 보내주시면 요청하신 형식에 맞춰 섹션별로 한국어 요약을 작성하겠습니다.

원문 읽기(새 탭에서 열림)

AI머신러닝kanana-ospeech-synthesis

kakao·2026년 8월 3일·4분 읽기큐레이션 요약

잘 말하는 AI를 넘어, 원하는 대로 말하는 AI로: Kanana-o 음성 생성 고도화 과정

Kanana-o는 단순히 자연스럽게 말하는 것을 넘어, 사용자가 지정한 속도·음량·억양·감정 등에 맞춰 말하는 음성 생성을 목표로 고도화됐다. 이를 위해 음성을 의미 정보와 음향 정보로 나누어 표현하는 LM-SPT 음성 토크나이저와 온라인 강화학습을 적용했다. LM-SPT는 토큰 시퀀스를 절반으로 줄이고 waveform을 직접 복원해 생성 효율을 높이는 동시에, 음성 특성을 세밀하게 제어할 기반을 마련했다. ## Kanana-o 음성 생성 구조 - 기존 Kanana-o는 음성을 초당 25개의 이산 토큰으로 표현했다. - Voice Token LM이 대화 문맥과 텍스트 답변을 바탕으로 음성 토큰을 순차적으로 생성한다. - 생성된 토큰은 다음 두 단계를 거쳐 음성으로 변환된다. - **Token-to-Mel**: 음성 토큰을 mel-spectrogram으로 변환 - **Mel-to-Waveform**: mel-spectrogram을 waveform으로 복원 ## 기존 음성 토크나이저의 한계 ### 음향 특성 제어의 어려움 - 기존 토크나이저는 발화 내용과 의미를 안정적으로 표현하는 데 강점이 있었다. - 반면 음색, 높낮이, 억양, 속도, 감정 같은 세부 음향 정보는 충분히 구조화하지 못했다. - 따라서 “더 빠르게”, “낮은 목소리로”, “속삭이듯이” 같은 지시를 토큰 수준에서 직접 제어하기 어려웠다. - 같은 문장이라도 화자나 억양에 따라 토큰 표현이 달라지면, 언어모델이 내용과 음향 특성을 독립적으로 학습하기도 어려워진다. ### 긴 시퀀스와 복잡한 디코딩 - 초당 25프레임의 토큰은 발화가 길어질수록 생성해야 할 토큰 수와 연산량을 증가시킨다. - Token-to-Mel 단계에서 Diffusion이나 Flow-matching 기반의 반복 추론이 필요할 수 있다. - 이후 Mel-to-Waveform까지 수행해야 하므로 총 2단계 디코딩 구조가 된다. - 이로 인해 실시간 음성 대화에 필요한 응답 속도와 효율을 확보하기 어렵다. ## LM-SPT의 의미·음향 분리 구조 - LM-SPT는 **LM-aligned SPeech Tokenizer**의 약자로, 언어모델과의 결합을 고려해 설계됐다. - 음성을 기존의 절반인 **초당 12.5프레임**으로 압축한다. - 음성 정보를 다음 두 종류의 토큰으로 분리한다. - **의미 토큰**: 텍스트와 대화 문맥에 대응하는 발화 내용 - **음향 토큰**: 음색, 억양, 높낮이, 발화 속도 등 실제 목소리의 세부 특성 - 두 개의 인코더와 하나의 의미 코드북, 여러 개의 음향 코드북으로 구성된 **Split RVQ** 구조를 사용한다. - 의미 코드북이 발화의 핵심 내용을 표현하고, 여러 음향 코드북이 의미 토큰에서 빠진 음향 정보를 단계적으로 보완한다. ## 의미 음성-재합성 기반 증류 - 단순히 음성을 잘 복원하도록 학습하면 의미 토큰에 음향 정보가 섞이거나, 발화 내용이 음향 토큰에 분산될 수 있다. - 기존 방식은 HuBERT나 WavLM 같은 자기지도학습 음성 모델의 표현을 의미 토큰과 시간 단위로 맞추는 증류를 사용했다. - 그러나 다음과 같은 문제가 있다. - teacher 모델의 표현이 음소·발음 중심이어서 언어모델의 고수준 의미와 완전히 일치하지 않을 수 있다. - 서로 다른 frame rate를 맞추는 과정에서 표현을 평균·축약하면 의미 정보가 희석될 수 있다. - LM-SPT는 Whisper처럼 언어모델과 연계하기 좋은 음성 인코더를 활용한다. - 의미 토큰만으로 원본 음성을 재합성한 뒤, 원본과 재합성 음성의 의미 표현이 유사해지도록 학습한다. - 특정 시간 구간의 teacher 표현을 그대로 모방하지 않고, 압축된 의미 토큰만으로 원본의 발화 내용을 보존하도록 유도한다. - 이 방식은 frame rate가 달라도 인위적인 시간 정렬 없이 의미 정보를 학습할 수 있다는 장점이 있다. ## 효율적인 음성 복원 - 최종 복원 과정에서는 의미 토큰과 음향 토큰을 함께 사용한다. - mel-spectrogram이라는 중간 표현을 거치지 않고 waveform을 직접 생성한다. - 무거운 사전학습 음성 인코더 없이 가벼운 음성 인코더를 사용할 수 있다. - 12.5Hz의 낮은 frame rate로 Voice Token LM의 생성 시간 스텝을 기존 대비 절반으로 줄였다. - 단일 디코더로 waveform을 복원해 기존의 2-stage decoding보다 간결한 구조를 구현했다. ## 온라인 강화학습을 통한 지시 이행 - LM-SPT가 음성의 의미와 음향 특성을 표현할 기반을 제공한다면, 온라인 강화학습은 사용자의 발화 지시를 실제 출력에 반영하도록 모델을 조정한다. - 목표는 음질의 자연스러움을 유지하면서도 다음과 같은 요구를 충실히 따르는 것이다. - 말하기 속도 - 음량 - 음높이와 억양 - 감정과 말투 - 속삭임 등 특정 발화 스타일 - 이를 통해 Kanana-o는 “사람처럼 자연스럽게 말하기”에서 나아가 “사용자가 원하는 방식으로 말하기”를 지향한다. ## 실용적인 결론 음성 AI를 실제 서비스에 적용하려면 음질뿐 아니라 지연시간, 연산량, 제어 가능성을 함께 고려해야 한다. Kanana-o의 접근법처럼 의미·음향 정보를 분리한 저주파 토큰과 직접 waveform을 복원하는 디코더를 사용하고, 온라인 강화학습으로 지시 이행 능력을 보완하는 방식은 실시간·개인화 음성 서비스에 적합한 설계 방향이다.

원문 읽기(새 탭에서 열림)

multimodalkanana-ospeech-synthesislm-spt+3

kakao·2026년 7월 27일·4분 읽기큐레이션 요약

더 작고 강해진 Kanana SLM 개발

Kanana-2는 온디바이스 환경에 맞춰 크기와 추론 비용을 줄이면서도 대형 모델에 가까운 성능을 확보한 카카오의 SLM 시리즈다. 3B 모델을 TPU에서 처음부터 사전 학습한 뒤 Instruct 모델을 Teacher로 활용한 Distillation과 Long Context 학습을 적용했으며, 이를 기반으로 1.3B와 0.9B 모델을 단계적으로 압축했다. 또한 한국어 토크나이저 개선과 Sliding Window Attention(SWA)을 도입해 언어 처리량과 메모리 효율을 높였다. ## Kanana-2 SLM 개발 배경 - 대상 모델은 **Kanana-2-3B, 1.3B, 0.9B** 세 가지다. - 3B와 1.3B는 Base 및 Instruct 모델로 공개됐다. - 스마트폰 등 온디바이스 환경은 메모리와 연산 자원이 제한적이므로, 작고 빠르면서도 다양한 업무를 처리할 수 있는 SLM이 필요하다. - Kanana-2 개발에는 Kanana-2-30B-A3B 개발 경험과 기존 Kanana Nano의 Pruning·Distillation 노하우가 활용됐다. - 새로운 핵심 기법으로 Teacher 기반의 **off-policy·on-policy 학습**, 개선된 Pruning·Distillation, Kanana-2 Tokenizer, SWA가 적용됐다. ## 3B 모델의 TPU 기반 사전 학습 - Kanana-2-3B-Base는 TPU v5e 클러스터와 MaxText 기반 자체 학습 프레임워크로 처음부터 사전 학습됐다. - TPU에서 사전 학습한 뒤 GPU 클러스터에서 Distillation을 이어서 수행할 수 있도록 TPU와 GPU 간 학습 호환성을 확보했다. - 사전 학습은 2단계로 진행됐다. - **Stage 1:** 7.5T 토큰 - **Stage 2:** 2T 토큰 - 전체 사전 학습 구간에 **Muon Optimizer**를 적용했다. ## Proxy Token Scale을 활용한 Learning Rate 탐색 - 수조 개 토큰 규모의 본 학습에서 Learning Rate를 직접 탐색하는 것은 비용이 지나치게 크다. - Stage 1의 데이터 분포를 유지한 채 **100B 토큰 규모의 Proxy 학습**으로 후보 Learning Rate를 먼저 비교했다. - 이후 최적 Learning Rate를 본 학습 규모에 맞게 Token Horizon Scaling 법칙으로 조정했다. - 사용한 식은 다음과 같다. `LR*(Dtarget) ≈ LR*(Dproxy) × (Dtarget / Dproxy)^(-β)` - `Dproxy=100B`, `Dtarget=7.5T`, `β=0.32`를 사용했다. - 토큰 규모가 커질수록 최적 Learning Rate가 작아지는 경향을 반영해, 적은 탐색 비용으로 안정적인 학습 설정을 얻었다. ## Instruct Teacher를 활용한 Distillation - GPU 기반 Megatron-LM 프레임워크에서 **Kanana-2-30B-A3B-Instruct-2601**을 Teacher로 사용했다. - Base, Instruct, Thinking 모델을 각각 Teacher로 설정해 성능을 비교했다. - 실험 결과, 학습 전반에서 **Instruct 모델을 Teacher로 사용했을 때 가장 높은 성능**을 보였다. - 특히 Post-trained 모델을 Teacher로 사용하면 수학과 코드 영역에서 효과가 크다는 기존 연구 결과와도 일치한다. ## 32K Long Context 학습 - 4K 컨텍스트에서 YaRN을 적용해 최대 **32K 컨텍스트**까지 확장했다. - Learning Rate decay 단계에서 Mid-training 데이터를 추가해 최종 Base 모델을 완성했다. - Kanana-2-3B-Base는 이전 Kanana 3B 모델보다 한국어·영어 지식, 수학, 코드 등에서 향상된 성능을 보였다. - 유사한 크기의 오픈소스 SOTA Base 모델과 비교해도 대부분의 평가 영역에서 우수한 결과를 기록했다. ## 1.3B·0.9B 모델의 단계적 압축 - 3B Base 모델을 기반으로 **1.3B Base와 0.9B Base**를 순차적으로 개발했다. - 주요 압축 방식은 모델 구조를 줄이는 **Structured Pruning**과 Teacher의 지식을 전달하는 **Knowledge Distillation**이다. - Pruning 대상에는 Layer, Hidden Dimension, MLP 중간 차원, Attention Head 등이 포함될 수 있다. - 기존 Kanana Nano보다 Hidden Dimension pruning 방법을 고도화했다. ## PCA 기반 Hidden Dimension Pruning - 기존 방식은 Calibration 데이터의 Activation으로 각 Hidden dimension의 중요도 점수를 계산하고, 점수가 높은 차원만 남겼다. - 이 방식은 차원을 개별적으로 평가하기 때문에 여러 차원이 함께 형성하는 Hidden representation을 충분히 반영하지 못한다. - Kanana-2에서는 Ministral 3의 **PCA 기반 pruning**을 적용했다. - 처리 과정은 다음과 같다. 1. Calibration 데이터로 Attention RMSNorm, MLP RMSNorm, Final RMSNorm 입력의 Activation 통계를 수집한다. 2. PCA를 수행해 Global Rotation Matrix를 계산한다. 3. Token Embedding, Attention, MLP Projection Weight의 입출력에 동일한 회전을 적용한다. 4. 회전된 표현을 기준으로 Hidden dimension을 축소한다. - 이를 통해 개별 차원의 중요도뿐 아니라 여러 차원에 분산된 표현 구조까지 고려하는 것을 목표로 한다. ## SWA와 토크나이저를 통한 추론 효율 개선 - **Sliding Window Attention(SWA)**를 적용해 각 토큰이 제한된 범위의 이전 토큰만 참조하도록 했다. - 전체 시퀀스에 대한 Attention을 줄여 Decoding 병목을 완화한다. - KV Cache 크기를 축소해 온디바이스 추론에서 메모리 사용량을 줄인다. - SWA 구조에 맞춘 Long Context 학습도 별도로 수행했다. - **Kanana-2 Tokenizer**는 주요 언어인 한국어 처리 효율을 기존 대비 30% 이상 개선했다. - 토큰 수가 줄어들면 같은 문장을 처리할 때 필요한 연산량과 메모리 사용량도 함께 감소한다. ## 실용적인 결론 Kanana-2의 접근법은 단순히 모델 파라미터를 줄이는 것이 아니라, 3B 모델의 충분한 사전 학습과 강력한 Teacher Distillation, PCA 기반 구조적 pruning, SWA, 한국어 특화 토크나이저를 함께 최적화한 사례다. 온디바이스 서비스에서는 모델 크기만 비교하기보다 **한국어 토큰 효율, KV Cache 메모리, 실제 Decoding 속도, 압축 후 성능 유지율**을 함께 평가하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

knowledge-distillationkananatpusmall-language-model+4

kakao·2026년 6월 23일·3분 읽기큐레이션 요약

개발을 넘어 AI로 사회문제를 해결하다

이번 글은 카카오와 삼성전자가 공동 개최한 AI 해커톤을 통해, 개발 역량을 사회문제 해결과 연결한 사례를 소개합니다. 참가자들은 AI 민생 10대 프로젝트를 주제로 실제 서비스 프로토타입을 개발하며 문제 정의, 협업, 전문가 피드백의 중요성을 경험했습니다. 글은 이러한 실전형 협력이 AI 시대의 개발자 양성과 사회적 가치 창출을 동시에 이루는 출발점이라고 결론짓습니다. ## 카카오·삼성 공동 AI 해커톤의 배경 - 2026년 6월 13~14일 경기도 용인 카카오 AI캠퍼스에서 개최됐습니다. - 카카오테크 부트캠프와 삼성 청년 SW·AI 아카데미(SSAFY)가 처음으로 공동 주최했습니다. - 두 기관 모두 고용노동부 K-디지털 트레이닝 사업을 기반으로 디지털 인재를 양성하고 있습니다. - 예선을 통과한 12개 팀, 약 90명의 교육생이 참여했습니다. - 단순한 개발 경연을 넘어 서로 다른 교육 배경의 참가자들이 협업하고 성장하는 것을 목표로 했습니다. ## AI 민생 10대 프로젝트와 사회문제 해결 - 참가자들은 정부가 선정한 ‘AI 민생 10대 프로젝트’ 중 하나를 주제로 선택했습니다. - 주요 문제 영역은 다음과 같습니다. - 소상공인 지원 - 보이스피싱 대응 - 아동·청소년 보호 - 해양 안전 - 제한된 시간 안에 문제를 정의하고 사용자 관점에서 해결책을 설계했습니다. - AI 기술을 적용한 서비스 모델을 실제 프로토타입으로 구현했습니다. - 기술 자체의 활용보다 AI가 어떤 사회적 가치를 만들어낼 수 있는지에 초점을 맞췄습니다. ## 정부·현업 전문가의 실전형 멘토링 - 경찰청, 법무부, 여성가족부 등 정부 부처 담당자들이 멘토로 참여했습니다. - 참가자들은 정책과 현장의 요구사항을 직접 확인하고 질의응답을 진행했습니다. - 카카오 현업 개발자들은 특강과 기술 멘토링을 제공했습니다. - 전문가 피드백을 통해 아이디어의 현실성, 서비스 완성도, 문제 해결 방향을 개선했습니다. - 교육 과정에서 배운 기술을 실제 공공 문제에 적용하는 경험을 제공했습니다. ## 서로 다른 배경의 개발자 간 협업 - 카카오테크 부트캠프와 SSAFY는 서로 다른 교육 방식과 경험을 가진 참가자들을 배출해왔습니다. - 참가자들은 처음 만난 동료들과 역할을 나누고 아이디어를 발전시켰습니다. - AI를 결과물 제작에 어떻게 활용할지 논의하며 새로운 개발 방식을 실험했습니다. - 다양한 경험과 관점을 공유하면서 기존에 생각하지 못했던 해결책을 발견했습니다. - 기술 역량뿐 아니라 소통, 협업, 공동 문제 해결 능력의 중요성을 체감했습니다. ## 수상작과 개발자 생태계 확장 - 최종 심사를 통해 총 5개 팀이 수상했습니다. - 고용노동부 장관상은 통신 두절 상황에서도 AI로 해상 구조를 지원하는 서비스 ‘DRIFT’를 개발한 ‘골든타임’ 팀이 받았습니다. - 카카오 대표이사상은 AI 기반 민원 접수·처리 서비스 ‘민담’을 개발한 ‘SSAIKA’ 팀이 수상했습니다. - 전체 상금은 1,500만 원 규모였습니다. - 카카오는 2022년부터 660명 이상의 디지털 인재를 양성해왔으며, 이번 행사를 통해 SSAFY와 교육 경험을 연결했습니다. - 기업 간 경쟁보다 인재 양성과 사회적 가치 창출을 위한 협력 모델을 제시했다는 데 의미가 있습니다. ## 미래 개발자에게 필요한 역량 - AI 시대에는 단순한 코딩 능력만으로는 충분하지 않습니다. - 중요한 역량은 다음과 같습니다. - 사회문제를 발견하고 정의하는 능력 - 사용자 관점에서 해결책을 설계하는 능력 - AI 기술을 실제 서비스에 적용하는 능력 - 다양한 배경의 사람들과 협업하는 능력 - 기술의 사회적 영향과 가치를 고려하는 태도 - 실전 프로젝트와 전문가 멘토링은 이러한 역량을 짧은 시간 안에 종합적으로 경험하게 합니다. 개발자 교육과 해커톤은 최신 기술 구현에만 머물지 않고, 실제 사회문제를 해결하는 방향으로 설계될 필요가 있습니다. 교육기관과 기업이 협력해 현장 전문가, 사용자, 개발자가 함께 참여하는 프로젝트를 확대한다면 기술 인재 양성과 사회적 가치 창출을 동시에 달성할 수 있습니다.

원문 읽기(새 탭에서 열림)

AIsoftware-developmentcollaborationai-hackathon+2

kakao·2026년 6월 15일·4분 읽기큐레이션 요약

AI 에이전트로 카카오톡 추천 지표 분석 자동화하기

카카오는 기존 Hadoop 환경에 AI 에이전트를 연결해 추천 지표 분석 절차를 자동화했다. 핵심은 새로운 플랫폼이나 권한을 추가하는 것이 아니라, 사람이 알고 있던 데이터 접근 절차·지표 정의·판단 기준을 Markdown 기반 스킬과 컨텍스트 문서로 정리하는 데 있었다. AI는 분석 초안을 빠르게 만들고 다음 질문을 제안하지만, 결과의 정확성과 최종 판단은 사람이 검증해야 한다. ## 반복적인 추천 지표 분석의 비효율 - CTR 하락, 실험군 반응, 배포 후 사용자군 변화 등을 확인하려면 다음 과정을 반복해야 한다. - 분석 환경 접속 - 적절한 테이블 탐색 - SQL 작성 및 실행 - 결과 해석 - 연령대·카테고리·시간대 등 관점별 추가 분석 - 질문은 간단해도 데이터 준비와 추출에 많은 시간이 걸린다. - 반복적이고 절차가 정형화된 업무이므로 AI 자동화에 적합하다. ## Hadoop 접속 절차를 Agent Skill로 정리 - 기존 Hadoop 접속 스크립트와 실행 환경은 그대로 활용했다. - AI가 Hadoop을 사용할 수 있도록 접속·쿼리 실행 방법을 `SKILL.md` Markdown 문서로 작성했다. - 여러 스킬을 묶은 사내 플러그인 `hadoop-butler`를 통해 AI가 다음 작업을 수행하도록 했다. - Hadoop 클러스터 접속 - 분석 목적에 맞는 SQL 작성 - 쿼리 제출 및 결과 수집 - 결과 정리와 인사이트 도출 - 새로운 분석 플랫폼이나 MCP 서버를 구축하기보다, 기존 인프라에 업무 지식을 “접착제”처럼 추가한 접근이다. ## 컨텍스트 문서로 분석 기준 명시 - 분석 디렉터리에 `CLAUDE.md`, `AGENTS.md`와 같은 컨텍스트 문서를 배치했다. - 문서에는 다음 정보를 담았다. - 분석 대상 테이블과 Hadoop 클러스터 - `watch_length`, `valid_view` 등 주요 컬럼의 의미 - 사용자·세션 집계 기준 - CTR 등 주요 지표의 정의 - 명확한 기준을 문서화하면 AI가 매번 테이블과 컬럼의 의미를 추측하지 않아도 된다. - 이는 AI의 분석 품질을 높이는 동시에 팀의 데이터 지식을 문서화하고 신규 구성원의 온보딩에도 도움을 준다. ## AI는 분석 초안을 만들고 사람은 질문을 확장 - 자연어로 분석 목적을 설명하면 AI가 첫 번째 리포트와 추가 분석 후보를 제시한다. - 이상치 확인, 실험 결과 비교, 주간 현황 점검처럼 반복 업무에 특히 효과적이다. - 대시보드가 수치를 빠르게 보여준다면, 자연어 분석은 “어디를 더 살펴볼지”를 제안한다. - 사용자는 초안 결과를 확인한 뒤 세부 사용자군이나 특정 기간 등으로 질문을 이어가며 분석을 구체화할 수 있다. - AI 결과는 최종 결론이 아니라 검토 대상이며, 쿼리 기준과 지표 정의를 사람이 확인해야 한다. ## AI가 그럴듯하게 만드는 의미·성능 오류 - **의미 오류** - 사용자 수 집계에 계정 단위 식별자인 `user_id` 대신 세션 성격의 `session_user_id`를 사용할 수 있다. - 쿼리는 정상 실행되지만 실제 사용자 수 의미와 다른 결과를 낼 수 있다. - **성능 오류** - 여러 컬럼에 대해 `COUNT(DISTINCT ...)`를 한 번에 실행하는 SQL을 생성할 수 있다. - Hive에서는 이 방식이 단일 리듀서로 처리되어 매우 느려질 수 있다. - 컬럼별 쿼리를 분리해 병렬 실행하는 방식이 더 적절하다. - 문법적으로 올바른 SQL과 업무적으로 올바른 분석은 다르므로, 도메인 지식과 실행 엔진 특성에 대한 검증이 필요하다. ## 문서화와 회귀 테스트로 품질 관리 - 자주 발생하는 오류를 지침에 명시적으로 추가했다. - 사용자 수 집계에는 반드시 `user_id` 사용 - 모든 컬럼명은 백틱으로 감싸 예약어 충돌 방지 - 다중 `COUNT(DISTINCT)`는 컬럼별로 분리해 병렬 실행 - 스킬과 프롬프트가 늘면서 한 지침 수정이 다른 기능을 깨뜨리는 회귀 문제가 발생했다. - 이를 해결하기 위해 MLflow 기반 E2E 평가 파이프라인을 구축했다. - 스킬별 기대 동작을 테스트 시나리오로 정의 - 에이전트를 헤드리스 모드로 실행 - LLM Judge가 결과를 평가 - 도구 호출 순서, 실행 트레이스, 최종 출력까지 다층 검증 - 배포 전 전체 시나리오를 자동 회귀 테스트 - 자연어 지침도 소프트웨어처럼 테스트와 배포 관리가 필요하다는 점을 강조한다. ## 실용적인 도입을 위한 네 가지 요소 - **모델**: 자연어 요청을 이해하고 분석 절차를 수행하는 에이전트 - **컨텍스트**: 테이블, 피처, 지표 정의와 업무 규칙 - **실행 환경**: 실제 데이터에 접근할 수 있는 기존 Hadoop 인프라 - **검증 루프**: 결과와 도구 실행 절차를 확인하는 자동 테스트 체계 반복 업무에 AI를 도입할 때는 새로운 시스템부터 만들기보다, 기존 절차와 도메인 지식을 문서화하고 실행 환경에 연결하는 것이 효과적이다. 다만 AI의 결과를 그대로 신뢰하지 말고, 명확한 분석 기준과 회귀 테스트를 함께 마련해야 실무에서 안전하게 활용할 수 있다.

원문 읽기(새 탭에서 열림)

AI 에이전트sqlcontext-engineeringhadoop+4

kakao·2026년 6월 15일·4분 읽기큐레이션 요약

Vibe Coding하는 비개발자는 개발자인가(3)

AI 에이전트는 비개발자에게 단순히 코드를 생성해주는 도구를 넘어, 업무를 실행 가능한 구조로 재정의하게 만드는 동반자다. 글쓴이는 로컬 HTML 도구를 공유 서비스로 확장하고, 스프레드시트·웹훅·환경변수·스킬·MCP 등을 활용하며 입력과 출력, 권한, 보안, 검증 조건을 자연스럽게 고민하게 되었다고 말한다. 결국 중요한 것은 코딩 능력 자체보다 자신의 업무를 AI가 수행할 수 있는 단위와 규칙으로 구조화하는 능력이다. ## 로컬 HTML에서 공유 데이터 도구로 - 초기 도구는 브라우저에서 실행하는 단일 HTML 파일이었다. - 서버와 데이터베이스가 필요 없고 혼자 사용하기에 충분했다. - 다른 사람과 공유하려면 배포 주소, 최신 버전 반영, 데이터 저장 문제가 생겼다. - 정적인 화면을 넘어 다음 요구사항이 발생했다. - 과거 입력값 조회 - 여러 사용자의 데이터 공유 - 상태 변경에 따른 화면 갱신 - 사용자별 조회·수정 권한 관리 - 잘못된 수정의 복구와 데이터 백업 - 정식 데이터베이스는 접근 권한 설계와 운영·보안 부담이 컸다. - 대신 구글 스프레드시트를 공유 데이터 저장소로 활용했다. - 기존 협업 UI와 권한 관리 기능을 이용할 수 있었다. - 수정 이력과 공유 기능도 이미 제공됐다. - Apps Script 코드를 직접 붙여넣는 방식에서 시작해, 이후 `clasp`를 이용한 Apps Script API 기반 배포·실행 방식으로 발전했다. - 핵심 변화는 코드를 많이 작성한 것이 아니라, 데이터 위치·공유 방식·권한·변경 이력을 설계하기 시작했다는 점이다. ## 웹훅 연동과 보안 습관 - AI 에이전트의 도움으로 업무 환경과 연결되는 웹훅 봇을 구현할 수 있게 되었다. - 웹훅 URL과 토큰을 다루면서 다음 보안 원칙을 익히게 됐다. - 비밀값을 코드나 프롬프트에 직접 입력하지 않기 - `.env` 파일에서 환경변수로 읽기 - `.gitignore`로 저장소에 비밀값이 올라가지 않도록 하기 - 로그에 토큰 등 민감정보를 출력하지 않기 - 실제 비밀값 대신 placeholder 사용하기 - 작은 자동화라도 외부 시스템과 연결되는 순간 실행 환경과 접근 권한, 비밀값 관리가 함께 고려되어야 한다. - 보안은 별도의 전문 작업이 아니라 AI에게 코드를 요청할 때마다 반복하는 작업 습관이 되었다. ## 손작업을 명세와 파이프라인으로 바꾸기 - 파일 복사·정리, 문서 변환, 영상 편집, 음성 추출, 요약 등 기존의 수작업도 AI 에이전트에게 맡기기 시작했다. - 사람이 직접 할 때는 감으로 처리하던 작업도 에이전트에게 맡기려면 구체적인 명세가 필요했다. - 대상 입력 파일 - 결과 파일명과 저장 위치 - 기존 파일 덮어쓰기 여부 - 실패 시 중단 조건 - 결과의 정상 여부를 판단하는 검증 기준 - 이 과정에서 반복 업무가 다음과 같은 업무 단위로 분해됐다. - 입력 - 처리 단계 - 출력 - 예외 상황 - 검증 조건 - 자동화의 핵심은 명령어를 아는 것이 아니라, 한 단계가 완료되었다고 판단할 기준과 입력·출력 형식을 정의하는 데 있다. ## 회의록 스킬과 반복 판단의 축적 - 매주 반복되는 회의록 작성 과정에서 일정한 수정 패턴이 발견됐다. - 글쓴이는 Codex와 Claude의 `skill`을 만들어 회의 유형별 규칙을 저장했다. - 회의록의 출력 형식 - 결정사항과 액션 아이템 추출 방식 - PMO 관점에서 확인할 신호 - AI가 독단적으로 결론 내리지 않고 사용자에게 질문해야 하는 경우 - 스킬은 단순한 프롬프트 모음이 아니라 반복되는 판단 기준과 업무 규칙을 저장하는 장치였다. - AI가 초안을 작성하면 최종본과 비교해 개선점을 찾고, 그 결과를 다시 스킬에 반영하는 순환 구조를 만들었다. - 내부 데이터를 정리하다가 대화 기록을 잃어버린 사례도 있었다. - 스킬 파일은 남았지만 대화에 포함된 맥락이 사라져 성능이 일시적으로 저하됐다. - 반복 업무에서는 규칙뿐 아니라 맥락과 사례를 보존하는 것도 중요하다는 점을 보여준다. ## MCP와 스킬을 이용한 GA 리포트 자동화 - 기존에는 구글 애널리틱스(GA) 데이터를 확인하고 여러 대시보드를 만들어 인사이트를 도출하는 과정이 번거로웠다. - GA MCP를 통해 API로 데이터를 가져오고, 스킬로 월간 리포트 형식을 유지했다. - 지난달과 이번 달의 차이를 비교해 변화가 의미 있는지 판단하는 방식으로 리포트가 개선됐다. - MCP는 데이터를 가져오는 통로이고, 스킬은 반복되는 리포트 구조를 유지하는 장치다. - 중요한 것은 단순히 숫자를 요약하는 것이 아니라 다음을 판단하는 것이다. - 어떤 변화가 발생했는가 - 그 변화가 설명할 가치가 있는가 - 추가 조사가 필요한 신호인가 - AI의 분석 결과에 사용자의 업무 맥락을 결합하면 이전에는 발견하기 어려웠던 변화를 준실시간으로 탐지할 수 있다. ## 개발의 경계가 넓어지는 방식 - 변화의 본질은 AI 도구의 개수가 늘어난 것이 아니라, 기존 업무를 다른 구조로 바라보게 된 데 있다. - AI가 만든 결과물 자체보다 AI가 수행할 수 있도록 업무를 설명하는 방식이 중요해졌다. - 앞으로 더 많은 사람이 다음 요소를 일상적으로 고민하게 될 것으로 전망한다. - 입력과 출력 - 권한과 보안 - 반복 작업과 파이프라인 - 완료 조건과 검증 방법 - 이는 모든 사람이 전통적인 개발자가 된다는 뜻은 아니다. - 다만 비개발자의 업무도 점차 쪼개지고, 자동화되고, 실행 가능한 형태로 재정의될 수 있다. AI 에이전트를 효과적으로 활용하려면 “무엇을 만들어 달라”보다 “입력은 무엇이고, 결과는 어떤 형식이어야 하며, 실패와 보안 문제를 어떻게 처리할지”를 구체적으로 정의하는 것이 좋다. 반복되는 수정과 판단을 스킬이나 문서로 축적하고, 민감정보와 작업 맥락을 안전하게 관리하는 습관을 함께 갖추는 것이 실용적인 출발점이다.

원문 읽기(새 탭에서 열림)

AI 에이전트모델 컨텍스트 프로토콜claude-codewebhooks+3

kakao·2026년 6월 8일·4분 읽기큐레이션 요약

에이전틱 AI 생태계의 주인공들, MCP Player 10 성료와 Next!

카카오의 MCP 기반 개방형 플랫폼 PlayMCP에서 열린 ‘MCP Player 10’ 공모전이 약 150개 팀의 참여 속에 마무리됐다. 수상작들은 보육 행정, 창업 지원사업, 육아, 법률, 문화생활, 게임, 보안 등 일상과 전문 영역의 문제를 AI 에이전트로 해결했다. 카카오는 PlayMCP를 개발자 중심 플랫폼으로 발전시키고, Kakao Tools 및 카카오톡과 연계해 MCP 서비스의 대중화를 추진할 계획이다. ## 60일간 진행된 MCP 공모전 - 공모전은 2025년 12월 19일부터 2026년 1월 18일까지 진행됐다. - 카카오의 MCP 기반 플랫폼 **PlayMCP**를 활용해 실용적인 MCP 서버를 개발하는 방식이었다. - 약 150개 팀이 참여했으며, 창의성·사용 편의성·기술적 안정성을 기준으로 최종 10팀을 선정했다. - 단순한 기술 시연보다 실제 생활 속 불편을 해결하고 서비스로 발전할 가능성이 중요한 평가 기준으로 소개됐다. ## 대상: 어린이집 행정을 돕는 ‘어린이ZIP’ - 현직 교사의 행정 업무 부담을 줄이는 AI 보육 조수다. - 활동 사진을 분석해 알림장과 보육일지 초안을 자동 생성한다. - 아이별 알레르기, 하원 방법 등 개별 특이사항을 기억해 맞춤형 답변을 제공한다. - 보육 현장에 적합한 따뜻한 문체와 전문가의 톤앤매너를 반영한다. - “사진으로 오늘 보육일지 작성”, “아이의 알레르기 정보 확인”과 같은 자연어 명령으로 사용할 수 있다. ## 최우수상: 창업 지원사업을 분석하는 ‘SeedUp’ - 정부 창업 지원사업 공고를 수집하고 분석하는 창업 지원 MCP다. - 여러 기관에 흩어진 공고와 첨부 파일을 한곳에서 검색·요약한다. - 지원 자격과 주요 조건을 확인하고, 지원사업별 합격 전략까지 안내한다. - 창업자가 “이번 주 주요 공고”, “AI 스타트업 관련 사업” 등을 자연어로 검색할 수 있다. ## 다양한 생활 문제를 해결한 수상작 - **공유 비밀의 방** - 익명성을 보장하는 디지털 소통 플랫폼이다. - AI와 나눈 고민이나 대화를 익명으로 공유하고 다른 사람의 이야기에 공감할 수 있다. - **바우만 16 안티에이징솔루션** - 바우만 피부 유형 16가지 분류법을 AI에 적용했다. - 화장품 성분과 피부 특성을 분석해 개인별 스킨케어 루틴과 제품을 추천한다. - **아라드도우미** - 던전앤파이터 이용자를 위한 게임 전문 AI 비서다. - RAG와 Vision AI를 활용해 패치 노트, 아이템 메타, 직업별 빌드를 분석한다. - **키즈허브** - 육아 정보와 공공데이터를 통합한 서비스다. - 응급실 현황, 성장 단계, 어린이집 대기 정보 등을 제공하고 가족 단톡방 공유도 지원한다. - **택배추적기** - 배송 조회뿐 아니라 택배 사칭 스미싱 URL도 탐지한다. - 배송 관련 문자 속 위험 링크를 분석해 개인정보와 금융 피해를 예방한다. - **ArtBridge** - 약 20만 건의 공연·전시 데이터를 활용하는 문화생활 추천 서비스다. - 위치, 예산, 취향을 바탕으로 연극·뮤지컬·클래식 등 9개 장르의 콘텐츠와 예매 정보를 추천한다. - **KidSafe** - 어린이와 청소년의 AI 대화를 보호하는 안전 MCP다. - 유해 표현과 정서적 위기 신호를 감지하고, 필요하면 보호자나 전문 상담 자원과 연결한다. - **LexiLink_ko** - 법령, 판례, 행정 해석례를 자연어로 검색하는 법률 리서치 도구다. - 복잡한 법적 쟁점을 통합 검색하고 이해하기 쉽게 정리한다. ## PlayMCP의 향후 발전 방향 - PlayMCP는 개발자가 MCP 서버를 만들고 공유하는 전문 공간으로 운영된다. - 일반 사용자가 MCP를 경험하는 공간은 카카오톡의 **Kakao Tools**가 담당하며, 두 서비스는 긴밀하게 연결될 예정이다. - 현재는 개발자가 MCP 서버의 엔드포인트와 운영을 직접 관리해야 한다. - 향후 카카오 클라우드 기반 서버 지원과 배포 자동화 등 매니지드 서비스 도입을 검토하고 있다. - 카카오톡 안에서 MCP가 JSON 기반 위젯 등 자체 UI를 렌더링하도록 지원하는 방안도 검토 중이다. ## 다음 공모전: Agentic Player 10 - 카카오는 2회 공모전인 **Agentic Player 10**을 예고했다. - 이번에는 Kakao Tools와 연계해 개발자가 만든 에이전트를 더 많은 사용자에게 직접 선보이고 검증할 기회를 제공한다. - 특히 스타트업과 예비 창업팀이 실제 사용자 접점을 확보하고 서비스 성장을 실험하는 장으로 활용할 수 있도록 설계될 예정이다. - MCP 서버가 카카오톡 안에서 대중적인 AI 에이전트로 발전하는 것이 주요 목표다. 수상작들은 MCP가 단순한 개발자용 연동 기술을 넘어, 특정 업무와 사용자 문제를 해결하는 실용적인 AI 서비스로 발전할 수 있음을 보여준다. MCP 서비스를 개발한다면 명확한 사용자 문제를 정하고, 신뢰할 수 있는 데이터와 안전장치, 자연어 기반 사용성을 함께 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

AI 에이전트모델 컨텍스트 프로토콜RAGjson+3

kakao·2026년 5월 21일·4분 읽기큐레이션 요약

메시징 서버의 스트레스 테스트 노하우와 AI 가 덜어 준 부분

메시징 서버의 안정적 운영을 위해서는 실서비스와 동일한 환경에서 상시 스트레스 테스트를 수행하고, 실제 트래픽 패턴과 최악의 시나리오를 재현해야 한다. 테스트는 단순히 서버가 장애 없이 버티는지를 보는 것이 아니라 RPS, 지연 시간, 오류율, 시스템 자원 등을 계층적으로 분석해 병목 원인을 찾아내는 과정이다. 관측성 도구, 프레임워크, OS·보안 시스템, 신규 기능 변경 전후에도 스트레스 테스트를 적용해야 운영 장애를 예방할 수 있다. ## 상시 스트레스 테스트 환경 구성 - 테스트 대상 서버는 실운영 서버와 동일한 JVM heap, CPU·메모리 한도, 네트워크 사양으로 구성한다. - 운영 서버 대수가 다르면 측정값을 그대로 비교하기 어렵기 때문에 필요한 경우 수치 보정을 적용한다. - 부하 생성에는 Locust를 사용하며, 클러스터 리소스에 따라 수백 개의 워커 파드까지 확장한다. - 부하 생성 클라이언트의 자원 부족이 서버 성능 측정에 영향을 주지 않도록 클라이언트 리소스를 충분히 확보한다. - 경우에 따라 `org.openjdk.jmh:jmh-core`를 이용해 프레임워크나 프로토콜 자체를 벤치마크한다. ## 실제 트래픽을 반영한 시나리오 설계 - 여러 사용자 동작을 실제 환경의 비율에 맞춰 조합한다. - 평시 정오에는 메시지 전송, 채팅방 입장, 채팅방 목록 조회, 메시지 조회가 비교적 고르게 분포한다. - 신년 자정에는 메시지 전송 비중이 52%에서 61%로 증가하고, 채팅방 목록 조회는 18%에서 8%로 감소한다. - 같은 RPS라도 READ·WRITE 프로토콜 비율에 따라 병목 지점과 최대 처리량이 달라질 수 있다. - 새로운 시나리오마다 부하 코드를 새로 작성하지 않고, 사용자 수·요청 비율·동시성 등 설정값을 조합해 다양한 트래픽을 재현한다. ## 변경 유형별 스트레스 테스트 ### 관측성과 로깅 인프라 추가 - Logstash, Fluent Bit, OpenTelemetry, Vector DB 등 관측성 컴포넌트가 애플리케이션 처리량과 응답 시간에 미치는 영향을 확인한다. - 메트릭 수집 때문에 애플리케이션 부하가 증가하거나 CPU·메모리·네트워크 사용량이 변하지 않는지 측정한다. - 높은 트래픽에서 내부 메트릭과 알림 시스템 자체가 지연되는지도 검증한다. ### 프로토콜·프레임워크 벤치마크와 포팅 - 비즈니스 로직을 제외하고 동일한 I/O 부하를 주어 프로토콜이나 프레임워크별 성능을 비교한다. - WebFlux, virtual thread 등 기술 선택을 추상적인 장점이 아니라 실제 RPS, latency, CPU 사용량으로 판단한다. - CPU 부하와 I/O 대기 시간을 단계적으로 늘려 현재 서비스가 CPU-bound인지 IO-bound인지 확인한다. - C++에서 Kotlin으로 메인 서버를 포팅할 때도 전후 시스템 지표를 비교하고, GC 튜닝 등을 통해 성능 차이를 줄였다. ### OS 변경과 보안 시스템 도입 - 온프레미스 호스트 OS 변경, 백신, 보안·모니터링 에이전트 추가가 고부하 상황에서 미치는 영향을 검증한다. - 평상시에는 드러나지 않던 slab 메모리 누수나 백신 동작 시 리소스 급증이 대규모 트래픽에서 문제가 될 수 있다. - 적용 전후 응답 시간과 처리량이 악화되지 않는지 확인한 뒤 인프라 변경을 진행한다. ### 메시징 도메인 특화 임계 상황 - 한 채팅방에서 여러 사용자가 동시에 메시지를 전송하는 상황을 재현한다. - 자정 메시지 burst, 수백 명 규모의 단체 채팅방 입장 등 최악의 시나리오를 별도로 검증한다. - 신규 기능도 부하 상황에서 예상되는 병목을 먼저 파악한 후 출시한다. ## 지표를 계층적으로 분석하는 방법 ### 엔드포인트 지표 - **RPS**: 워커 수를 점진적으로 늘려 포화 지점을 찾거나, 동일한 부하에서 RPS가 안정적으로 유지되는지 확인한다. - 예상보다 낮은 RPS에서 포화되거나 처리량이 급격히 흔들리면 내부 원인 분석으로 넘어간다. - **Latency**: - P50은 대부분 사용자의 일반적인 경험을 나타낸다. - P95·P99는 최악의 응답 시간과 내부 병목을 파악하는 데 유용하다. - P95·P99가 급증하면 처리량 한계나 대기열 문제를 의심한다. - P50 자체가 목표치나 실제 환경보다 높아도 비정상으로 판단한다. - **Error rate**: - 5xx는 서버 처리 한계에 도달했을 가능성이 있다. - timeout은 클라이언트 자원 부족이나 타임아웃 설정을 확인해야 한다. - 400 오류는 테스트 데이터나 비즈니스 시나리오가 잘못되었을 가능성이 있다. ### 시스템 자원 지표 - 본문은 시스템 자원 레이어 설명 중간에서 끝나지만, 엔드포인트 지표에서 이상이 발견되면 CPU·메모리·네트워크 등 하위 시스템 지표를 세부적으로 확인하는 방식으로 이어진다. - 스트레스 테스트 결과는 단순한 성공·실패가 아니라, 어느 계층에서 병목이 발생했는지 추적하는 디버깅 과정으로 해석해야 한다. 실무에서는 운영과 유사한 테스트 환경을 상시 유지하고, 평시 트래픽뿐 아니라 도메인 특유의 폭증 시나리오까지 자동화하는 것이 중요하다. 또한 변경 사항을 도입할 때 RPS, P50/P95/P99 latency, 오류율, 시스템 자원을 동일한 기준으로 비교해 정량적으로 판단하는 것이 권장된다.

원문 읽기(새 탭에서 열림)

옵저버빌리티Kotlinopen-telemetryperformance-testing+4

kakao·2026년 5월 5일·4분 읽기큐레이션 요약

음성 AI 모델을 프로덕션에 올리기까지: Kanana-O 서빙 최적화 여정

Kanana-O를 실시간 음성 대화 서비스로 제공하려면 모델 학습과는 별개의 서빙 최적화가 필요하다. 카카오는 Thinker·Talker·VoiceBox로 구성된 파이프라인에 특화된 Kanana-Omni Server를 구축해 임베딩 전달, 스트리밍 지연, 프로세스 안정성, 동시 요청 처리 문제를 해결했다. 그 결과 동시 사용자 64명 기준으로 vllm-omni 대비 상대 처리량 1.6배를 달성했다. ## Kanana-O의 멀티모달 음성 생성 구조 - **Thinker**는 텍스트·이미지·오디오 입력을 이해하고 텍스트를 생성하는 대형 언어 모델이다. - **Talker**는 Thinker의 텍스트 임베딩을 받아 음성 토큰을 순차적으로 생성한다. - **VoiceBox**는 음성 토큰을 실제 오디오 파형으로 변환한다. - 프로덕션 환경에서는 다음 조건을 동시에 만족해야 한다. - 수백 밀리초 안에 첫 음성을 제공해야 한다. - 여러 사용자의 요청을 동시에 처리해야 한다. - 텍스트와 오디오를 끊김 없이 스트리밍해야 한다. - 각 모델의 GPU 메모리 요구량 차이를 관리해야 한다. ## 범용 멀티모달 서빙 프레임워크의 한계 - Thinker가 Talker에 전달하는 값은 토큰 ID가 아니라 수천 차원의 **히든 스테이트 임베딩**이다. - 임베딩을 직렬화하거나 CPU로 복사하면 지연이 커지므로 GPU 메모리 주소를 직접 공유하는 zero-copy 방식이 필요했다. - Talker는 매 스텝 음성 토큰을 생성하지만 VoiceBox는 일정량의 토큰이 쌓인 뒤 청크 단위로 소비한다. - Talker의 입력에는 다음 값이 누적된다. - 화자 특성을 나타내는 스피커 임베딩 - Thinker의 출력 임베딩 - 이전 스텝에서 생성한 음성 임베딩 - 이처럼 생산자와 소비자의 속도가 다르고 입력 길이가 계속 증가하는 구조는 일반적인 LLM 서빙 패턴과 맞지 않았다. - 자체 서버를 구축한 결과 상대 처리량은 다음과 같았다. - naive 구현: 0.44 - vllm-omni: 1 - Kanana-Omni Server: 1.6 ## 공유 메모리와 CUDA IPC를 활용한 데이터 전달 - 프로세스 간 임베딩 전달을 매번 직렬화·역직렬화하면 토큰마다 큰 오버헤드가 발생한다. - 서버 시작 시 OS 레벨에서 공유 메모리 블록을 미리 할당해 런타임 할당·해제를 제거했다. - Thinker는 공유 메모리 풀의 블록에 데이터를 쓰고, Talker에는 실제 데이터 대신 블록 번호와 크기 같은 메타데이터만 전달한다. - 같은 노드의 GPU 간 텐서 전달에는 **CUDA IPC**를 사용했다. - GPU 텐서를 CPU로 내렸다가 다시 GPU로 올리는 `Device → Host → Device` 복사를 제거해 컴포넌트 간 통신 지연을 줄였다. ## Cascaded Streaming Pipeline - Thinker가 전체 텍스트를 생성한 뒤 Talker를 실행하는 순차 방식은 첫 음성 응답까지 수 초가 걸릴 수 있다. - 세 컴포넌트를 비동기 태스크와 큐로 연결해 파이프라인을 겹쳐 실행했다. - Thinker가 첫 청크를 생성하면 Talker는 즉시 음성 토큰 생성을 시작한다. - Talker가 앞선 토큰을 생성하는 동안 VoiceBox는 이전 토큰 청크를 오디오로 합성한다. - 각 단계가 동시에 진행되므로 전체 처리 시간보다 첫 음성까지의 체감 지연을 크게 줄일 수 있다. ## 프로세스 분리와 장애 격리 - Thinker와 Talker는 각각 독립적인 vLLM 엔진으로 실행된다. - 하나의 프로세스에서 두 엔진을 구동하면 CUDA 컨텍스트 충돌이나 GPU 메모리 관리 간섭이 발생할 수 있다. - 따라서 두 모델을 별도 프로세스로 분리하고 각자의 CUDA 컨텍스트에서 실행했다. - 프로세스 생성에는 `fork` 대신 `spawn`을 사용했다. - `fork`: 부모의 CUDA 상태와 메모리를 복제해 충돌 위험이 있다. - `spawn`: 깨끗한 Python 인터프리터에서 시작해 GPU 상태 오염을 줄인다. - Thinker가 OOM으로 종료되더라도 Talker와 API 서버까지 함께 영향을 받지 않아 독립적인 재시작과 장애 대응이 가능하다. ## vLLM continuous batching을 이용한 동시 처리 - 요청마다 이미지·오디오 입력 크기와 누적 임베딩 길이가 달라 직접 배치를 구성하기 어렵다. - 수동 배칭은 padding 낭비와 복잡한 동기화 문제를 유발한다. - Kanana-Omni Server는 배치 구성을 vLLM의 **continuous batching 스케줄러**에 위임했다. - 서버는 요청을 비동기로 빠르게 엔진에 제출하고, vLLM이 GPU 메모리와 요청 상태를 고려해 forward pass를 묶는다. - 각 요청은 `request_id`로 결과를 구분하므로 여러 요청이 하나의 배치에서 처리돼도 개별 응답을 독립적으로 스트리밍할 수 있다. - 내부 루프는 요청을 받자마자 `asyncio.create_task(generate(...))`로 실행해 다음 요청을 즉시 수락한다. ## FastAPI `workers=1`과 비동기 처리 - 일반적인 FastAPI 서버처럼 여러 워커를 실행하면 각 워커가 vLLM 모델을 별도로 로드한다. - 그 결과 GPU 메모리 사용량과 모델 로딩 시간이 워커 수만큼 증가해 멀티워커 구성이 현실적으로 어렵다. - 모델별 서버를 따로 두면 워커 확장은 가능하지만, Thinker와 Talker 사이의 임베딩이 네트워크를 거쳐 zero-copy 이점을 잃게 된다. - 따라서 API 서버는 `workers=1`로 운영하고, 단일 이벤트 루프가 블로킹되지 않도록 요청부터 오디오 생성까지 전체 경로를 `async/await`로 구성했다. - 단일 워커 환경에서는 동기 작업 하나가 모든 사용자의 처리를 막을 수 있으므로, 끝에서 끝까지 비동기 설계가 필수다. 실시간 멀티모달 모델을 서비스할 때는 모델 자체보다 모델 간 데이터 이동, 스트리밍 타이밍, GPU 메모리 관리, 장애 격리가 성능을 좌우한다. 특히 모델 간 임베딩 전달이 빈번하다면 공유 메모리와 CUDA IPC를 검토하고, 긴 생성 파이프라인은 비동기 스트리밍과 continuous batching으로 구성하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

멀티모달 AIvllmcontinuous-batchingfastapi+3

kakao·2026년 4월 22일·4분 읽기큐레이션 요약

카카오톡 예약하기에서 그려 본 캘린더

카카오톡 예약하기는 카드 목록만으로는 재고와 예약을 한눈에 파악하기 어렵다는 문제를 해결하기 위해 타임 블록형 캘린더를 구현했다. 예약을 시작 시간과 종료 시간에 따라 정렬하고, 겹치는 예약을 그래프로 모델링한 뒤 DFS로 배치 깊이와 확장 가능 범위를 계산했다. 이후 루트 노드 간의 길이 차이로 남는 공간이 생기는 예외까지 보정해 예약 블록을 최대한 빈틈없이 배치했다. ## 캘린더 제작 배경과 요구사항 - 파트너센터의 예약 관리 화면은 예약을 카드 목록으로 보여주고 있었다. - 카드 목록은 많은 예약과 재고를 한눈에 비교하기 어렵다는 불편이 있었다. - 이를 해결하기 위해 예약과 재고를 시간축 위에서 확인할 수 있는 타임 블록형 캘린더를 제작했다. - 주요 요구사항은 다음과 같다. - 하나의 시간대에 최대 10개의 예약이 존재할 수 있다. - 하나의 예약은 최대 6시간을 차지한다. - 예약 블록 사이에 빈 공간을 최소화하면서 최대한 잘 보이게 배치해야 한다. ## 예약 배치 순서 ### 이용 시간이 이른 예약부터 정렬 - 예약이 입력된 순서가 아니라 시작 시간이 빠른 순서대로 배치했다. - 판매자가 하루를 시작할 때 가장 먼저 확인할 가능성이 높은 예약을 왼쪽 위에 배치하기 위한 결정이다. - 사용자의 시선이 일반적으로 왼쪽 위에서 오른쪽 아래로 이동한다는 시각적 우선순위도 고려했다. - 첫 번째 배치 규칙은 **“이용 시간이 이른 순서로 정렬한다”**이다. ### 같은 시간에는 소요 시간이 긴 예약부터 정렬 - 같은 시간대에 여러 예약이 겹치면 소요 시간이 긴 예약을 앞에 배치했다. - 긴 예약이 뒤로 밀리면 앞쪽 예약이 차지한 공간 때문에 긴 블록의 확장이 제한될 수 있다. - 긴 예약을 먼저 배치하면 이후 예약들이 남은 공간을 기준으로 배치되고, 각 예약이 확보할 수 있는 영역을 예측하기 쉬워진다. - 두 번째 배치 규칙은 **“같은 시간 내에서는 소요 시간이 긴 순서로 정렬한다”**이다. ## 예약을 그래프로 모델링 - 단순히 DOM 요소의 위치를 조정하는 대신, 예약 간의 겹침 관계를 그래프로 표현했다. - 각 예약을 그래프의 노드로 만들고, 서로 영향을 주는 예약을 연결했다. - 노드에는 예약 정보와 함께 이전 예약(`prevBooking`), 다음 예약(`nextBooking`) 같은 연결 관계를 저장했다. - 이 구조를 이용하면 예약이 어떤 경로로 연결되어 있고, 어느 정도까지 확장될 수 있는지 계산할 수 있다. ## DFS를 이용한 위치와 확장 범위 계산 - 각 노드에서 DFS를 수행해 다음 정보를 계산했다. - 그래프에서의 깊이 또는 레벨 - 연결된 예약 중 가장 끝에 있는 예약까지의 최대 거리(`maxLength`) - 깊이는 예약 블록의 가로 방향 위치를 결정하는 데 사용된다. - 최대 거리는 해당 예약이 오른쪽으로 얼마나 확장될 수 있는지 판단하는 기준이 된다. - 계산된 값을 바탕으로 각 노드의 다음 UI 속성을 구한다. - `left`: 블록의 시작 위치 - `width`: 블록이 차지할 가로 너비 - 그래프의 가장 왼쪽에 있는 노드부터 기준을 잡아 예약 블록을 배치하고 확장했다. ## 루트 노드 간 길이 차이로 발생한 예외 - 초기 알고리즘은 모든 예약이 연결된 그래프에서도 공간이 남는 경우를 완전히 처리하지 못했다. - 위쪽 루트 노드의 `maxLength`가 더 길고, 아래쪽 루트 노드의 `maxLength`가 짧으면 하위 그래프가 끝까지 확장되지 않았다. - 그 결과 예약 간 연결은 유지되지만 일부 빈 공간이 남는 문제가 발생했다. - 이 문제를 해결하기 위해 다음과 같은 보정 과정을 추가했다. - 현재 노드의 `left + width`보다 다음 노드의 `left`가 크면 두 노드 사이에 확장 가능한 공간이 있다고 판단한다. - 해당 노드와 연결된 예약들을 확인한다. - 여러 개의 빈 공간이 있으면 가장 작은 공간을 기준으로 연결된 노드들의 너비를 확장한다. - 이 과정을 반복해 예약 블록이 가능한 한 빈틈없이 영역을 채우도록 했다. ## 구현 과정에서 얻은 교훈 - 겉보기에는 단순한 UI라도 다양한 입력 데이터와 최악의 배치 상황을 고려해야 한다. - 타임 블록 캘린더는 예약의 정렬, 겹침 처리, 가로 확장, 예외 보정이 결합된 알고리즘 문제에 가깝다. - 그래프와 DFS 같은 자료구조·알고리즘이 실제 프런트엔드 UI 배치 문제를 해결하는 데 직접 활용될 수 있다. - 프런트엔드 개발자는 데이터를 화면에 어떻게 보여줄지 결정하는 책임과 권한을 함께 가진다. - 실제 서비스에서는 초기 알고리즘을 완성형으로 보기보다, 운영 중 발견되는 버그와 새로운 입력 패턴에 맞춰 지속적으로 개선해야 한다. 타임 블록 캘린더를 구현할 때는 먼저 예약을 시작 시간과 지속 시간 기준으로 안정적으로 정렬하고, 겹침 관계를 그래프로 모델링하는 방식이 유용하다. 이후 DFS로 배치 깊이와 확장 범위를 계산하되, 루트별 길이 차이로 생기는 잔여 공간과 같은 예외 케이스를 별도로 검증하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

사용자 인터페이스data-visualizationfrontendcalendar-ui+2

kakao·2026년 4월 21일·3분 읽기큐레이션 요약

카나나 스칼라 1회 세미나 현장 스케치

카카오의 ‘카나나 스칼라’ 1회 세미나는 카나나 파운데이션 모델의 기술 성과와 향후 AI 전략을 학계와 공유한 자리였다. 카카오는 적은 학습 토큰으로 높은 성능을 달성한 효율성과 한국어·다중모달 처리 능력을 강조했으며, 기술 주권과 서비스 최적화를 위해 자체 모델 개발을 지속하겠다는 방향을 밝혔다. 또한 초개인화 에이전트, 디지털 월드모델, 실전형 실행 능력, 산학 협력을 중심으로 AI 생태계를 확장할 계획을 제시했다. ## 카나나 파운데이션 모델의 성과 - 카카오는 외부 모델을 활용하는 대신, 처음부터 직접 개발하는 ‘카나나’ 파운데이션 모델 라인업을 구축하고 있다. - 유사한 규모의 글로벌 모델이 23조 개의 학습 토큰을 사용한 데 비해, 카나나는 약 11조 개의 토큰만으로도 뛰어난 성능을 달성했다고 설명했다. - 이는 학습 데이터의 정제 수준과 품질이 모델 효율성에 크게 기여했다는 의미로 소개됐다. - 텍스트와 이미지뿐 아니라 오디오까지 실시간 처리하는 옴니 모델 **Kanana-o**도 시연했다. - Kanana-o는 감정을 담은 음성 표현과 다화자 대화 처리를 선보였으며, 현장에서는 한국어 구사 능력이 뛰어나다는 평가를 받았다. ## 자체 모델 개발과 기술 주권 - 외부 AI 모델에 의존할 경우 라이선스 정책 변경이나 기술 공개 제한 등 외부 변수에 영향을 받을 수 있다. - 카카오는 독자 모델을 통해 서비스 환경에 맞는 고효율·맞춤형 AI를 운영하고, 실질적인 비즈니스 성과를 창출하려 한다. - 교수진은 한국의 문화적 맥락과 사회적 이슈를 독자적으로 통제하려면 자체 모델이 필요하다고 평가했다. - 독자적인 모델 역량은 서비스 안정성과 기술 주권을 확보하는 전략적 자산으로 논의됐다. ## 디지털 월드모델과 초개인화 에이전트 - 카카오는 카카오톡 플랫폼에서 발생하는 사용자의 행동과 대화 맥락을 이해하는 ‘상황 이해 지능’에 주목하고 있다. - 온디바이스 기술을 활용하면 대화 내용이 외부로 유출되지 않도록 보호하면서도 사용자의 요청을 즉시 처리할 수 있다. - 이를 바탕으로 사용자의 일상과 맥락에 맞춰 행동하는 초개인화 에이전트를 구현하려 한다. - 교수진은 디지털 월드모델을 로봇이나 물리적 환경에만 한정하지 말고, 플랫폼 내 상호작용과 인과관계를 예측하는 모델로 확장하자고 제안했다. - 카카오톡의 방대한 서비스·사용자 상호작용은 카카오만의 차별화된 디지털 월드모델을 구축할 기반으로 평가됐다. ## 생성 능력보다 중요한 실전형 실행력 - 카카오는 단순히 문장을 생성하는 능력보다, AI가 작업을 계획하고 필요한 기능을 호출해 최종 과업을 완료하는 능력을 중시한다. - 자체 ‘오케스트레이션 벤치마크’를 개발해 복합적인 실제 문제 해결 능력을 평가할 계획이다. - 이는 여러 단계의 추론과 도구 사용이 필요한 서비스 환경에서 AI의 실질적인 유용성을 검증하기 위한 접근이다. - 교수진은 사용자가 느끼는 지능은 벤치마크 점수보다 복잡한 요구를 끝까지 해결하는 능력에서 드러난다고 강조했다. - 글로벌 모델과 단순 생성 품질 경쟁을 하기보다, 카카오 서비스 안에서의 실행력에 집중하는 전략이 효과적일 수 있다는 의견이 제시됐다. ## 학계와 산업계의 AI 인재 협력 - 카카오는 세미나를 계기로 대학 연구실과 학부 AI 동아리에 GPU 자원을 지원하는 방안을 검토하고 있다. - 지원 방식으로는 GPU 크레딧 제공이나 공동 과제 형태 등이 논의됐다. - 이러한 협력은 연구자와 학생들이 실제 AI 모델 개발과 실험을 수행할 수 있도록 돕고, 국내 AI 인재 생태계를 강화하는 데 목적이 있다. - 카나나 스칼라는 기술 논의뿐 아니라 지속적인 산학 협력의 출발점으로 추진될 예정이다. 카카오는 카나나를 단순한 대규모 언어 모델이 아니라, 한국어와 국내 서비스 맥락을 이해하고 실제 작업까지 수행하는 플랫폼형 AI로 발전시키려 한다. 향후에는 모델 성능 자체보다 개인정보 보호, 카카오 서비스와의 결합도, 복합 과업 실행력, 그리고 산학 협력을 통한 생태계 확장이 중요한 경쟁력이 될 것으로 보인다.

원문 읽기(새 탭에서 열림)

AIAI 에이전트멀티모달 AIorchestration+4

kakao·2026년 3월 15일·5분 읽기큐레이션 요약

수억 건의 보안 신호 속 진짜 위협 찾기 — AI로 보안 모니터링의 패러다임을 바꾸다

수억 건의 보안 이벤트를 사람이 규칙만으로 분석하는 방식은 오탐, 맥락 부족, 비용 증가 때문에 지속하기 어렵다. 글은 규칙 기반 필터와 AI 분석, 멀티모델 교차 검증, 자가 학습을 결합한 다단계 보안 모니터링 구조를 제안한다. 핵심은 모든 이벤트를 AI에 맡기는 것이 아니라, 정상 패턴과 노이즈를 먼저 걸러낸 뒤 맥락 판단이 필요한 위협만 정밀 분석하는 것이다. ## 대규모 보안 이벤트와 AI의 필요성 - 엔드포인트에서는 프로세스 실행, 네트워크 연결, 파일 변경, 권한 상승 등이 모두 이벤트로 수집된다. - 서비스가 확장될수록 이벤트는 기하급수적으로 증가하지만, 실제 공격의 비율은 극히 낮다. - 이벤트 증가에 맞춰 분석 인력을 계속 늘리는 방식은 지속 가능하지 않다. - 문제의 본질은 데이터의 양뿐 아니라, 여러 이벤트의 관계와 맥락을 이해해야 하는 복잡성에 있다. - 따라서 단순히 경보 수를 늘리는 것이 아니라, 실제 대응 가치가 높은 신호를 선별하는 시스템이 필요하다. ## 규칙 기반 탐지와 상관분석의 한계 - 규칙은 특정 명령어 실행이나 파일 생성처럼 명확한 패턴을 빠르게 탐지하지만, 실행 목적과 주체, 업무 맥락은 이해하지 못한다. - 정상적인 배포 작업과 악성 백도어 설치가 동일한 명령어를 사용할 수 있어 오탐이 많다. - 분석가의 경험과 근무 시간에 따라 판정 품질이 달라지는 문제도 발생한다. - 호스트 정보, 프로세스 이력, 네트워크 세션, 파일 변경 로그를 사건 단위로 조합하는 작업은 높은 인지 부담을 요구한다. - SIEM 상관분석은 여러 로그를 연결할 수 있지만, 사전에 정의된 공격 시나리오에 의존하므로 알려지지 않은 공격이나 변형된 행위에 취약하다. - 규칙이 늘어날수록 유지보수 비용과 매칭 성능 부담도 커진다. - 결국 기존 방식은 이벤트를 연결하는 데는 성공했지만, “왜 해당 행위가 위협인지”를 맥락적으로 설명하는 데 한계가 있다. ## 다단계 깔때기와 하이브리드 분석 - 수억 건의 이벤트를 모두 AI에 전달하지 않고, 단계별로 분석 대상을 줄이는 깔때기 구조를 사용한다. - 1단계에서는 규칙 기반 필터가 명백한 노이즈를 제거한다. - 2단계에서는 반복되는 정상 패턴을 학습해 예외 처리한다. - 3단계에서야 AI가 정밀 분석을 수행하므로 비용과 처리량을 관리할 수 있다. - 명확한 패턴은 규칙이 빠르게 처리하고, 복합적인 맥락 판단은 AI가 담당하는 하이브리드 방식을 채택한다. - 새로운 위협 유형이나 분석 범주가 추가되어도 동일한 파이프라인에서 처리할 수 있도록 확장성을 고려했다. ## 멀티모델 교차 검증과 운영 신뢰성 - 서로 다른 추론 특성을 가진 여러 AI 모델이 동일한 이벤트를 독립적으로 분석한다. - 모델 간 결과를 비교해 특정 모델의 편향, 오탐, 누락을 보완한다. - 판정이 일치하지 않으면 이를 불확실성 신호로 보고 분석가의 추가 검토를 유도한다. - 모델 장애, API 가용성 저하, 모델 업데이트에 따른 품질 변동에도 다른 모델로 전환할 수 있다. - 목표는 단순한 정확도 향상뿐 아니라 중단 없이 운영되는 복원력과 신뢰성 확보이다. ## 보안 환경의 맥락을 AI에 주입 - 범용 LLM에 이벤트만 전달하면 내부 서버 역할, 서비스 구성, 자동화 계정, 정상적인 네트워크 흐름을 알 수 없어 정상 작업을 공격으로 오인할 수 있다. - 이를 해결하기 위해 호스트 역할, 관련 서비스, 정상 행위 패턴 등을 구조화해 AI에 제공한다. - 중요한 것은 원본 데이터를 전달하는 것이 아니라, 올바른 판단에 필요한 배경 지식을 함께 설계하는 것이다. ## 개별 이벤트가 아닌 행위 흐름 분석 - `curl`로 파일을 내려받고 `chmod`로 권한을 바꾼 뒤 스크립트를 실행하는 행위는 정상 배포와 공격 모두에서 나타날 수 있다. - 개별 명령어만 보면 정상과 악성을 구별하기 어렵다. - 프로세스 실행 이력, 네트워크 세션, 파일 변경 등을 시간 순서로 연결해 호스트 단위의 전체 행위 흐름으로 분석한다. - 같은 명령어라도 실행 시점, 순서, 주체, 주변 맥락에 따라 위협성이 달라진다는 점을 활용한다. ## 표준화된 이벤트 스키마와 동적 피처 - 원본 이벤트에는 분석과 무관한 정보가 많아 토큰을 낭비하고 정확도를 떨어뜨릴 수 있다. - 통계 기반 이상 탐지와 행위 시퀀스 분석은 필요한 정보가 서로 다르다. - 표준화된 이벤트 스키마로 데이터를 정제하고, 탐지 유형별로 필요한 특징만 동적으로 구성한다. - 분석 관점에 맞는 피처를 선별해 토큰 효율과 판단 정확도를 함께 개선한다. ## WALT 기반 자가 학습 피드백 루프 - 초기에는 AI 분석 결과를 분석가가 수동으로 검토한 뒤 탐지 정책에 반영해야 했다. - 이를 자동화하기 위해 WALT(Whitelist-Assisted Learning and Tuning)를 구축했다. - AI가 반복적으로 정상이라고 판정하고 검증된 패턴은 자동으로 예외 정책에 등록된다. - 이후 동일한 이벤트는 AI 분석 전에 필터링되어 불필요한 분석과 오탐을 줄인다. - 수천 건의 탐지 정책이 자동 생성되어 운영 중이며, 시간이 지날수록 정상 패턴 학습이 축적된다. - 다만 필터링을 강화하면 비용과 속도는 개선되지만 실제 위협을 놓칠 위험이 있고, 멀티모델 검증은 신뢰성을 높이는 대신 비용을 증가시킨다. ## 비용·속도·정확도의 균형 - 모든 이벤트를 AI로 분석하면 수억 건 규모에서 비용과 지연 시간이 급증한다. - 따라서 사전 필터링으로 AI 투입량을 줄이고, 필요한 이벤트에만 고비용 분석을 적용해야 한다. - 시스템 설계에서는 탐지 누락 위험, 모델 호출 비용, 실시간 대응 속도, 모델 장애 대응력을 함께 조율해야 한다. - 글의 제공된 본문은 이 과제를 설명하는 도중 끝나므로, 이후의 구체적인 구현 방식과 최종 성과는 확인할 수 없다. 실무에서는 규칙을 AI로 전면 대체하기보다, 규칙으로 대량의 노이즈를 제거하고 AI에는 충분한 내부 맥락과 행위 흐름을 제공하는 방식이 현실적이다. 또한 멀티모델 불일치와 자동 생성 정책을 반드시 검증 대상으로 두어, 비용 절감이 탐지 누락으로 이어지지 않도록 운영해야 한다.

원문 읽기(새 탭에서 열림)

AI대규모 언어 모델anomaly-detectionsecurity-monitoring+4

kakao·2026년 3월 12일·4분 읽기큐레이션 요약

학생에서 개발자로: DB, 보안부터 AI까지, 정답보다 합리적인 선택을 배우다

카카오 신입 개발자 온보딩은 기술의 정답을 암기하는 교육이 아니라, 대규모 트래픽과 운영 환경을 견디는 합리적 설계를 배우는 과정이었다. DB에서는 변경과 운영 비용을 고려하고, 보안에서는 취약점을 자신의 코드 문제로 인식하며, AI에서는 모델의 불확실성을 시스템 설계로 통제하는 관점을 익혔다. 결국 개발자의 핵심 역량은 상황과 리소스에 맞는 선택을 하고, 그 근거를 팀과 공유·설득하는 능력이라는 결론에 도달한다. ## DB: 이론적 정답보다 운영 가능성을 우선하기 - 무결성은 반드시 DB가 전부 책임져야 하는 규칙이 아니라, DB와 애플리케이션 중 어디에 책임을 둘지 정하는 운영 모델이다. - 물리적 Foreign Key는 무결성을 보장하지만, 트래픽과 변경이 많은 환경에서는 락, 성능 저하, 스키마 변경의 유연성 문제를 일으킬 수 있다. - 애플리케이션이 무결성을 담당한다면 테스트와 데이터 보정 로직을 강화해야 한다. - 삭제된 데이터를 복구하거나 감사 추적해야 하므로 `deleted_at`을 활용한 소프트 딜리트가 실무의 중요한 운영 전략이 된다. ## 인덱스와 SQL: 결과가 아니라 실행 경로 설계하기 - 인덱스는 단순히 조회 속도를 높이는 기능이 아니라, 데이터 특성과 질의 방식에 맞는 자료구조 선택이다. - B-Tree 외에도 GIN, GiST, SP-GiST, Vector 인덱스 등 다양한 선택지가 있으며, DB가 어떤 질문을 받는지에 따라 적합한 인덱스가 달라진다. - 실행 계획을 확인하면 동일한 SQL이라도 인덱스를 사용하는지, 테이블 전체를 스캔하는지 파악할 수 있다. - 이러한 실행 경로의 차이는 디스크 I/O와 응답 시간에 직접 영향을 준다. - SQL 작성은 단순히 원하는 결과를 반환하는 작업이 아니라, 효율적인 실행 경로를 유도하는 작업으로 이해해야 한다. ## 중복과 반정규화: 데이터 중복을 성능 전략으로 활용하기 - 정규화와 JOIN이 항상 최선은 아니며, 데이터 규모와 트래픽이 커지면 JOIN이 병목이 될 수 있다. - 읽기 성능을 위해 일부 데이터를 의도적으로 중복 저장하는 반정규화가 합리적인 선택이 될 수 있다. - 당시의 비즈니스 상태를 보존해야 한다면 관련 정보를 스냅샷으로 저장하는 방식도 필요하다. - MongoDB에서는 관계를 `ref`로만 연결할 경우 조회가 복잡해질 수 있어, 화면에 필요한 정보를 함께 저장하면 추가 조회를 줄일 수 있다. ## DB 생태계: 성능·일관성·확장성의 트레이드오프 이해하기 - MySQL의 고가용성 구조, PostgreSQL의 PK 설계, Neon의 스토리지·컴퓨팅 분리 등 DBMS마다 고유한 설계 철학이 있다. - 어떤 시스템도 모든 상황에서 최선일 수 없으며, 성능·일관성·확장성·운영 비용 사이의 균형을 선택해야 한다. - Hadoop과 Spark 같은 빅데이터 기술도 개별 도구가 아니라 저장, 관리, 처리, 분석으로 이어지는 데이터 생태계의 일부로 이해해야 한다. - 이론적으로 완벽한 구조보다 변경에 안전하고 운영 비용을 감당할 수 있는 설계를 우선하게 되었다. ## 보안: 외부 조직의 일이 아니라 개발자의 기본값 - 개인정보 유출 가능성을 가정하면서 보안을 규정이나 인프라팀의 업무가 아닌 자신의 코드에서 시작되는 책임으로 인식하게 되었다. - Dev/Prod 분리, VPN, 백신 등은 편의성을 일부 희생하더라도 안전을 확보하기 위한 장치다. - DDoS 대응에서는 공격을 차단하는 것뿐 아니라 정상적인 트래픽 폭증과 공격을 구분하는 일이 어렵다는 점을 배웠다. - 개발자가 적용할 수 있는 기본 방어책으로 Rate Limit을 활용하고, 이상 징후가 발생하면 혼자 해결하지 않고 대응 체계에 연결해야 한다. ## API 보안과 지속적인 점검 - 취약점을 직접 공격해보는 실습을 통해 보안을 이론이 아닌 자신의 코드에 대한 문제로 체감했다. - AI를 활용한 취약점 탐색, QR 코드 공격, 앱 권한 악용처럼 방어 기술과 공격 기술이 함께 발전하고 있다. - 보안은 배포 직전에 한 번 점검하는 절차가 아니라 개발 초기부터 기본값으로 포함되어야 한다. - 코드 품질은 작성자가 자리를 비워도 다른 개발자가 빠르게 이해하고 운영할 수 있는지까지 포함한다. ## AI Agent: 모델보다 중요한 것은 시스템 설계 - AI Agent는 특별한 모델 자체라기보다, 도구 호출, 라우팅, 예외 처리, LLM 호출을 조합한 시스템 설계에 가깝다. - 기존 서비스 개발에서 사용하던 함수 분리와 조건 분기, 장애 대응 습관을 AI 시스템에도 적용할 수 있다. - LLM은 확률 모델이므로 매번 결과가 달라질 수 있어, 한 번의 뛰어난 답보다 일관된 출력과 안정적인 실행 흐름을 설계해야 한다. - Prompt Chaining으로 작업을 단계별로 나누고, Few-shot으로 출력 형식을 구체화하며, Routing으로 상황에 따라 프롬프트를 분기할 수 있다. ## 멀티 에이전트와 RAG·MCP의 결합 - 하나의 거대한 AI에 모든 역할을 맡기기보다 분석, 콘텐츠 생성 등 역할을 나눈 멀티 에이전트 구조가 더 빠르고 안정적일 수 있다. - 이는 기능과 책임을 분리하는 MSA의 설계 철학과 유사하다. - MCP는 내부 시스템의 데이터와 기능을 AI가 호출할 수 있는 Tool로 노출해, 원격 Function Calling처럼 활용하게 한다. - RAG는 문서를 청킹하고 유사 벡터를 검색해 관련 정보를 컨텍스트에 추가함으로써 할루시네이션을 구조적으로 줄인다. - AI를 잘 활용하려면 결과가 마음에 들지 않을 때 감정적으로 반응하기보다 목표, 출력 형식, 예시, 필요한 데이터와 컨텍스트를 명확히 정의해야 한다. 실무에서는 “무엇이 이론적으로 맞는가”보다 트래픽, 변경 가능성, 보안 위험, 운영 비용을 함께 검토해야 한다. DB 설계와 보안 점검, AI 기능 개발 모두를 일회성 작업이 아니라 지속적으로 관찰하고 개선하는 시스템으로 접근하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

데이터베이스 설계대규모 언어 모델AI 에이전트PostgreSQL+4

kakao·2026년 3월 12일·5분 읽기큐레이션 요약

학생에서 개발자로: 로또 구현부터 레거시 개선까지, 서버의 흐름을 배우다

서버 개발은 복잡해 보이지만, 설계 이유를 질문하고 검증하는 과정을 거치면 막연함을 줄일 수 있다는 것이 글의 핵심 주장입니다. 카카오의 기술 온보딩은 TDD·객체지향 구현, 레거시 인수 테스트, 리팩터링을 단계적으로 수행하며 유지보수 가능한 구조와 안전한 변경 능력을 길렀습니다. 결국 좋은 개발자는 코드를 작성하는 데 그치지 않고, 설계·테스트·협업·AI 활용의 기준을 스스로 세우는 사람이라는 결론입니다. ## 기술 온보딩의 목표와 구성 - 온보딩은 총 3단계로 진행되었습니다. 1. TDD와 OOP 기반 기능 구현 2. 레거시 코드에 대한 인수 테스트 작성 3. 테스트로 보호된 레거시 코드 리팩터링 - 정답을 전달하기보다 다음과 같은 질문을 반복하며 설계의 근거를 고민하게 했습니다. - 왜 이렇게 설계했는가? - 이 책임은 정말 해당 객체가 가져야 하는가? - 이 테스트는 무엇을 보호하는가? - 목표는 유지보수 가능한 구조 설계, 레거시 분석 및 안전한 개선, 협업과 AI를 포함한 책임 있는 개발 역량을 기르는 것이었습니다. - 서버뿐 아니라 FE, Android, iOS 직군도 참여했으며, 기술 스택과 관계없이 좋은 엔지니어링의 기준은 공유될 수 있다는 점을 강조했습니다. ## 질문과 협업으로 서버 개발의 막연함 줄이기 - 트래픽, 동시성, 확장성, 데이터베이스 설계처럼 추상적으로 느껴지는 주제를 실제 구현과 리뷰를 통해 구체화했습니다. - 매일 데일리 미팅에서 트러블슈팅을 공유하고, 페어 프로그래밍으로 설계를 논의하며, PR 리뷰에서 구현 이유를 설명했습니다. - 이를 통해 개발은 개인의 코딩 능력만으로 완성되는 일이 아니라는 점을 체감했습니다. - 코드의 동작 여부보다 스스로 설계를 설명하고 변경의 영향을 예측하는 능력을 중요하게 다뤘습니다. ## 로또 게임 구현: TDD와 객체지향 설계 - 첫 번째 미션은 로또 가격, 자동·수동 발급, 당첨 통계를 구현하는 과제였습니다. - 다음과 같은 제약 조건이 설계 개선을 유도했습니다. - 들여쓰기 깊이 1단계 유지 - 메서드 10라인 이하 - 원시값 포장과 일급 컬렉션 사용 - `else` 사용을 줄이고 Early Return 활용 - TDD 방식으로 테스트를 먼저 작성해 요구사항과 설계를 점검했습니다. ### 랜덤 로직의 테스트 가능성 확보 - 랜덤 번호 생성은 실행마다 결과가 달라 테스트가 어려웠습니다. - 이를 해결하기 위해: - 번호 생성 전략을 인터페이스로 추상화하고 - 생성 전략을 외부에서 주입받으며 - 테스트 전용 Generator를 별도로 구현했습니다. - 그 결과 테스트에서 생성 값을 통제할 수 있었고, 구현체에 대한 결합도도 낮아졌습니다. - TDD는 단순히 테스트를 추가하는 방식이 아니라, 테스트 가능한 구조를 설계하게 만드는 도구로 작용했습니다. ### 값 객체와 캐싱에 대한 고민 - 같은 값을 가진 객체를 매번 새로 생성할지, 재사용할지 고민하며 객체의 정체성과 값의 동일성을 구분했습니다. - 1부터 45까지의 로또 번호처럼 값의 범위가 제한된 경우 캐싱 전략을 검토할 수 있었습니다. - 이 미션을 통해 기능 구현보다 객체의 책임, 생성 방식, 재사용 가능성 등 설계 기준을 고민하게 되었습니다. ## 인수 테스트: 레거시를 안전하게 이해하기 - 두 번째 미션에서는 실제 서비스 수준의 레거시 코드를 바로 수정하지 않고, 먼저 인수 테스트를 작성했습니다. - 테스트가 보호해야 할 대상은 다음과 같았습니다. - 사용자의 행동 - 시스템의 반환 결과 - 외부에서 관찰 가능한 상태 변화 - 단순히 성공 여부만 확인하는 것이 아니라, 결과가 정확한지 검증하는 Strong Assertion 전략을 적용했습니다. - Cucumber 기반 BDD를 사용해 비개발자도 이해할 수 있는 시나리오 형태로 테스트를 구성했습니다. - 테스트를 개발자만의 코드가 아니라 팀 전체가 공유하는 실행 가능한 명세로 바라보았습니다. ### 운영 환경과 테스트 환경 맞추기 - “내 컴퓨터에서는 동작한다”는 문제를 줄이기 위해 Production Parity를 적용했습니다. - 구체적으로: - H2 대신 운영과 같은 PostgreSQL 사용 - Docker 기반으로 실행 환경 통일 - Gradle Task를 이용한 테스트 자동화 - 환경 차이로 인한 테스트 결과의 불일치를 줄이고, 누구나 동일한 조건에서 테스트를 실행할 수 있게 했습니다. ### 테스트 데이터 격리 - 테스트 간 데이터 의존성을 제거하기 위해 다음 전략을 사용했습니다. - 외래 키 관계를 고려한 역순 삭제 - `TRUNCATE ... CASCADE` - 공통 Cleanup 유틸리티 작성 - 모든 테스트가 초기화된 동일한 상태에서 시작하도록 보장해 테스트의 재현성과 안정성을 높였습니다. - 중요한 것은 특정 도구를 사용하는 것보다 상황에 맞는 데이터 격리 방법을 선택하는 판단 기준이라고 설명합니다. ## 레거시 리팩터링: 구조와 동작의 분리 - 세 번째 미션의 핵심은 레거시 코드를 단순히 “클린 코드”로 바꾸는 것이 아니라, 안전한 변경의 기준을 세우는 것이었습니다. - 가장 중요한 원칙은 구조 변경과 동작 변경을 분리하는 것입니다. - 구조를 개선할 때는 기존 동작을 유지 - 동작을 변경할 때는 구조 개선과 섞지 않기 - 이렇게 변경 목적을 분리하면 코드 리뷰와 테스트를 통해 변경 범위를 명확히 검증할 수 있습니다. - 의도하지 않은 동작 변화가 발생하면 리뷰에서 이를 찾아내고, 변경을 통제하는 능력을 기를 수 있었습니다. ## AI와 협업할 때의 검증 범위 - 리팩터링 과정에서 AI를 활용해 넓은 범위의 코드 개선을 빠르게 시도했습니다. - 그러나 AI에게 한 번에 큰 범위의 변경을 요청하면 수정량이 커져 검증이 어려워지는 문제가 발생했습니다. - 따라서 AI의 제안을 그대로 수용하기보다 변경 범위를 작게 나누고, 각 변경을 테스트와 리뷰로 확인하는 방식이 필요하다는 교훈을 얻었습니다. - AI는 개발자를 대신하는 도구가 아니라, 개발자가 책임 있게 검토하고 통제해야 하는 협업 도구로 다뤄졌습니다. 실무에서는 기능 구현 전에 책임과 설계 이유를 설명할 수 있는지 확인하고, 레거시 코드는 먼저 외부 동작을 보호하는 테스트를 마련하는 것이 좋습니다. 이후 구조 변경과 동작 변경을 분리해 작은 단위로 개선하며, AI를 사용할 때도 변경 범위를 제한하고 반드시 테스트와 리뷰로 검증하는 접근이 안전합니다.

원문 읽기(새 탭에서 열림)

PostgreSQLDocker & 컨테이너Javaoop+4