낯설지만 의미 있는 선택, 〈퀸 크랩〉과 〈후 아 유〉로 본 왓챠의 감각 Part 2왓챠파티@무비랜드 회고 두 번째 편입니다. 이번 편에서는 낯설지만 그래서 더 특별했던 기획 아이디어와 왓챠팀의 비주얼 역량이 유난히 빛났던 두 개의 테마를 소개합니다. 왓챠와의 만남이 ‘운명’처럼 느껴졌던 〈퀸 크랩〉은 제인이, 가장 오랜 시간 준비해 다각적인 기획이 빛을 발한 〈후 아 유〉는 세로가 글을 맡았습니다. 이 두 테마를 통해 왓챠팀의 감각과 실행력이 어떻게 오프라인 파티로 구현되었는지 이야기해 볼게요.왓챠파티@무비랜드 프로젝트를 진행하면서 돌을 주문해 ‘눈알 스티커’를 붙이는가 하면, 폐조명과 연출할 ‘설탕 유리’를 만들기도 했는데요. 도움이 되는 일이라면, 모두가 자진해서 작은 것 하나라도 도전해 보곤 했습니다. 결과물을 만들기 위해 다양한 방법을 동원했고, 팀의 시너지를 가장 큰 원동력 삼아 때로는 우리가 판 무덤이다 탄식하면서도, 그 고통스러운 방식으로도 창작을 멈추지 않았습니다. 그중에서도 팀원들의 활발한 상상력과 실행력으로 완성된 6월의 테마, 〈퀸 크랩〉을 먼저 소개해 볼게요.1회차 〈에브리씽 에브리웨어 올 앳 원스〉 돌과 2회차 〈트루먼 쇼〉 무대조명은 무비랜드에 기증되었다.-영화를 보는 취향은 다양하다. 세상이 몰라줘도, 때로는 용기 내어 용감하게 추천하고 싶은 영화가 있다. 가끔은 이야기가 허무맹랑하고 무모할수록 만족스럽다. 조금이라도 그런 마이너 한 취향을 가지고 있다면, 당신의 DNA 깊숙한 곳에는 B의 의지가 흐르고 있다! B 필름은 용기(BRAVE) 있게 도전하고, 상식을 깨는(BREAK) 사람의 향유물. 〈퀸 크랩〉이 당신에게 B의 의지를 이어받을 수 있는 등용문이자 시험대가 되기를! — 〈퀸 크랩〉 테마 소개 중6월, B필름 좋아하세요? 〈퀸 크랩〉2022년 연말, 온라인을 뜨겁게 달군 ‘게’가 있었습니다. 왓챠 유저들의 입소문을 타고 바이럴이 된 영화 〈퀸 크랩〉. 왓챠도 조금 늦게 발견한 것이 아쉬울 만큼, 화제가 되었던 작품입니다. 해당 콘텐츠는 서비스 종료 직전, 왓챠 스트리밍 실시간 순위 1위를 기록하며 큰 주목을 받았고, 유저들의 요청에 힘입어 다시 왓챠에서 감상할 수 있게 되었어요. 유저들이 기억하는 이 대단한 ‘게’는 에너지 넘치는 6월의 테마로 더없이 어울리는 콘텐츠였습니다.왓챠와의 인연도 특별했지만, 영화 자체가 가진 매력 역시 강렬합니다. 〈퀸 크랩〉은 모두가 아는 유명한 작품은 아니었지만, 한 번 보면 절대적인 재미를 선사하는 B 필름의 전형이자, 왓챠 유저들이 특히 애정하는 장르이기도 했습니다. 이런 남다른 콘텐츠로 오프라인 파티를 구현해 보고 싶다는 바람은 팀 내에서 오래전부터 있었고, 〈퀸 크랩〉은 그 바람을 실현해 줄 완벽한 선택이었죠. 다양한 취향과 장르를 아우르는 사람들이 모여 있는 곳, 왓챠이기에 가능했던 기획이기도 했습니다.왓챠 비디오 가게 운영합니다!우리는 〈퀸 크랩〉을 둘러싼 상상력을 하나의 설정으로 구체화했습니다. “이 영화를 빌릴 수 있는 가상의 비디오 가게가 있다면 어떨까

지난번 포스팅을 통해서, GPT의 구조가 대략적으로 어떻게 생겼고해당하는 구조를 통해서 다음단어 예측기(Decoder Only Transformer)가 대략적으로 어떻게 동작하는지 확인했습니다.이번 포스팅에서는 해당하는 다음단어 예측기를 통해서어떻게 GPT가 이 가능한지 알아봅니다.GPT는 이 주어졌을 때, 앞에있던 단어들을 가지고 다음에 올 단어을 예측합니다.이러한 문장의 경우 대부분 위키피디아 등에 존재하는 문서 형태이기 때문에인터넷의 수많은 문서를 학습한 상태의 LLM에게(이를 상태라고 합니다)라고 물어본다면이처럼 정상적이지 못한 다음단어만 예측을 하면서, LLM이 예상치 못한 결과만을 줄 뿐 입니다.이때 조금 책과 비슷한 형태의 텍스트를 입력하면, 아래와 같이 됩니다.서울의 날씨는 맑음. 부산은 아래지방 이므로이처럼 GPT는 Text를 받고, 해당하는 Text의 다음 단어를 예측할 뿐입니다.때문에 이런 GPT한테 어떻게 유저와 을 할지를 알려줘야하고이 과정을 이라고 합니다.이제 유저와의 이 가능하게 만드는 의 일종입니다.LLM의 경우 문장을 집어넣으면, 해당 문장 다음에 올 단어를 예측했었죠?이점을 동일하게 이용 합니다.일단 설명에 앞서, ChatGPT가 받아들이는 문자가 어떤 형태인지 볼 필요가 있습니다.유저가 chatGPT한테 너의 이름은 뭐야? 라고 입력할 경우아래와 같은 형태로 입력이 됩니다.우리는 단순하게 너의 이름은 뭐야? 라고 입력했다고 생각하지만실제로는 , 과 같은 특수 문자들이 삽입되어 있는 것을 확인할 수 있습니다.해당 문자들의 경우 과정에서 chatGPT가 학습을 했고,첫 다음에는 이라는 글자가 나와야하고, 그 다음은 이 나오게 학습된것 이라고 볼 수가 있습니다.그럼 도대체 어떻게 학습했길래 이게 가능 했을까요?ChatGPT의 instruction tuning 과정을 알 수는 없지만llama를 가지고 Alpaca를 만든 과정이 완벽하게 오픈소스로 공개되어서,어떤 과정으로 학습을 했을지 대략적으로 추측을 할 수가 있습니다.Alpaca의 경우, Meta의 llama를 사용해서 이 가능하게 만든 오픈소스 모델 입니다.Alpaca가 단순한 를 어떻게 이 가능하게 했는지는, 아래 형태를 통해서 알 수 있습니다.학습에 사용된 실제 데이터 입니다.보면 알 수 있듯, 때와는 다르게 세트로 구성되어있는것을 확인할 수 있습니다.이런 수많은 데이터를 학습한 이후에Alpaca와 Chat을 하기 위해서는 아래와같이 text를 만들 뒤 다음 단어를 예측하게 만들면 됩니다.상태의 LLM의 경우 평문에 대한 다음 단어 예측만 학습했기 때문에 Chat이란게 불가하지만위처럼 instrunction과 input이 주어지고, 그 다음 다음에는 어떤 식으로 단어를 예측 해야할지를 과정에서 배웠기 때문에단순한 다음단어 예측기 상태에서, Chat이 가능한 LLM으로서 활용이 가능하게 됩니다.huggingface에서 상태의 모델을 이라고 하고, 이 완료된 모델은 로 표기되는것을 볼 수 있습니다.이제 ChatGPT로 돌아가 볼까요?형태로 유저의 질문이 ChatGPT한테 입력되고, 그 뒷부분에 올 단어를 예측하게 되어있습니다.그러므로, ChatGPT의 경우 아래형태의 데이터를 사용해서 instruction tuning을 진행했을 것이란걸 예상해 볼 수 있습니다.

Bloter 애플 최대 협력업체 폭스콘, 인도 생산 확대 추진 2조원 투자

검색인프라팀은 분산 시스템 구축과 운영에 대한 다양한 경험을 쌓아왔습니다.이전에는 SaaS형 Redis 클러스터 제공 서비스(RC)와 MinIO 및 Kubernetes를 활용한 사내 스토리지 서비스 구축 경험을 공유한 바 있습니다.이번에는 분산 시스템의 핵심 과제 중 하나인 ‘합의(Consensus)’ 문제를 해결하는 Raft 알고리즘과, 이를 활용한 고가용성 우선순위 큐 구현을 통해 실제 적용 방법을 살펴보고자 합니다.검색인프라팀의 주요 업무는 데이터 수집, 가공, 연동, 서비스 개발이며, 이 과정에서 데이터의 일관성과 고가용성을 보장하는 것은 필수적이지만 매우 까다로운 과제입니다.특히, 네트워크를 통해 수많은 데이터가 실시간으로 입·출력되고,마이크로서비스 아키텍처 기반의 여러 노드가 유기적으로 연결된 환경에서는 노드 장애가 발생하더라도 서비스가 중단되지 않고, 데이터 일관성을 유지하는 것이 핵심입니다.이러한 배경에서 Raft 알고리즘을 팀내 어플리케이션에 도입한 경험을 공유하고자 이 글을 작성하게 되었습니다.이번 글에서는 자바 기반 Raft 구현체인 sofa-jraft 라이브러리를 활용해 3노드 환경에서 운영되는 고가용성 우선순위 큐를 구현하고, 이를 통해 Raft 알고리즘의 개념과 실전 적용 방안을 살펴보겠습니다.분산 시스템과 합의 알고리즘의 필요성분산 시스템은 여러 개의 독립적인 컴퓨터가 네트워크를 통해 통신하며 하나의 시스템처럼 작동하는 구조를 말합니다.이러한 시스템에서는 노드 장애, 네트워크 지연, 메시지 손실 등 다양한 문제가 발생할 수 있으며, 이런 상황에서도 시스템은 일관된 상태를 유지해야 합니다.• None 일관성 유지: 모든 노드가 동일한 데이터와 상태를 가져야 함• None 장애 허용성: 일부 노드가 실패해도 시스템이 계속 작동해야 함• None 네트워크 파티션 대응: 네트워크 분할 상황에서도 안전성 보장 필요이러한 문제를 해결하기 위해 Paxos, Raft, PBFT 등 다양한 합의 알고리즘이 개발되었습니다.그 중에서도 Raft는 이해하기 쉽고 구현이 용이하다는 장점으로 많은 분산 시스템에서 채택되고 있습니다.Raft는 분산 시스템에서 노드 간 합의를 이루기 위한 알고리즘으로, 스탠포드 대학의 Diego Ongaro와 John Ousterhout에 의해 개발되었습니다.Raft는 "이해하기 쉬운 합의 알고리즘"을 목표로 설계되었으며, 복잡한 Paxos 알고리즘의 대안으로 등장했습니다.Raft(뗏목)라는 이름의 유래위키피디아에 따르면, Raft는 "Reliable, Replicated, Redundant, Fault-Tolerant"의 약어에서 유래했다고 하지만, 이는 일부 해석일 뿐입니다.이 알고리즘을 만든 Diego Ongaro는 Google Groups에 직접 이름을 짓게 된 과정에 대해 남긴 기록이 있는데, 요약하면 다음과 같습니다.• None 처음엔 특정한 줄임말을 염두에 두진 않았지만, "Reliable", "Replicated", "Redundant", "Fault-Tolerant" 같은 단어들을 떠올림• None 로그(logs)를 떠올리며 이들로 무엇을 만들 수 있을지 고민(log는 '통나무'라는 의미도 있음)• None 기존 합의 알고리즘인 Paxos라는 '섬'에서 벗어나는 방법을 고민하던 중 **‘뗏목(Raft)’**이라는 이름을 떠올리게 됨Raft는 세 가지 핵심 메커니즘으로 구성됩니다:모든 노드는 리더, 팔로워, 후보자 중 하나의 상태를 가집니다. 클러스터가 시작되면 모든 노드는 팔로워 상태로 시작하고, 일정 시간 동안 리더로부터 신호가 없으면 후보자가 되어 리더 선출 과정을 시작합니다.• None 리더: 클라이언트 요청 처리 및 로그 복제 담당• None 팔로워: 리더의 요청에 응답하고 로그를 복제• None 후보자: 리더 선출 과정 중 투표를 요청하는 노드리더 선출은 랜덤한 타임아웃과 투표 과정을 통해 이루어지며, 과반수의 노드로부터 투표를 받은 후보자가 새 리더가 됩니다.클라이언트의 모든 요청은 리더가 받아서 처리합니다. 리더는 요청을 로그 항목으로 변환하여 자신의 로그에 추가한 후, 모든 팔로워에게 로그를 복제하도록 요청합니다.과반수(Quorum)의 노드가 로그를 복제하면 해당 항목이 '커밋'되고 상태 머신에 적용됩니다.로그 항목은 다음 정보를 포함합니다:Raft는 다음과 같은 안전성 속성을 보장합니다:• None 리더 완전성(Leader Completeness): 커밋된 로그는 모든 미래 리더의 로그에도 포함됨• None 상태 머신 안전성(State Machine Safety): 모든 노드는 커밋된 로그를 동일한 순서로 적용• None 로그 일치 속성(Log Matching Property): 같은 인덱스와 텀을 가진 로그는 동일한 명령을 포함Raft 알고리즘은 다음과 같은 주요 장점을 가집니다:• None 이해하기 쉽고 구현이 간편함: 복잡한 Paxos에 비해 명확한 개념 구조• None 장애 허용성(CFT): 전체 노드의 과반수가 정상 작동하는 한 시스템은 계속 작동• None 즉각적인 블록 완결성: 합의가 이루어진 데이터는 즉시 확정되어 롤백되지 않음sofa-jraft는 알리바바에서 개발한 Java 기반 Raft 구현체로, Baidu의 Braft를 Java로 재구현하고 최적화한 라이브러리입니다.고성능 분산 시스템 구축에 적합하며, 다양한 기능과 최적화를 포함하고 있습니다.• None 고성능: 완전 동시 복제, 복제 파이프라인 최적화 등을 통한 성능 향상• None MULTI-RAFT-GROUP: 복잡한 애플리케이션을 위한 다중 Raft 그룹 지원sofa-jraft는 다음과 같은 주요 컴포넌트로 구성됩니다:• None Node: Raft 그룹의 구성원으로, 리더/팔로워/후보자 상태 관리• None StateMachine: 애플리케이션 로직을 구현하는 상태 머신우선순위 큐는 각 요소가 우선순위를 가지며, 높은 우선순위의 요소가 먼저 처리되는 자료구조입니다.이 자료구조는 작업 스케줄링, 이벤트 처리, 네트워크 패킷 관리 등 다양한 분야에서 활용됩니다. 팀내에서는 수집 스케쥴 관리에 적용했습니다.우선순위 큐는 일반적으로

Android Auto는 스마트폰의 앱을 차량의 디스플레이에 최적화된 형태로 보여주는 플랫폼입니다.안드로이드 8(API 26) 이상의 휴대폰에 Android Auto 앱을 설치하고(대부분의 휴대폰에 기본 설치되어 있음) 호환 차량에 휴대폰을 연결하면,운전자가 차량 화면을 통해 휴대폰의 지원 앱들을 사용할 수 있습니다.휴대폰이 차량 UI에 투영되는 형태로 동작하며, 미디어 재생, 내비게이션, 메시징 등 운전에 적합한 앱 기능을 제공합니다.Android Auto는 자체적으로 앱의 백엔드 로직을 가지고 있지 않고, 휴대폰 앱에 정의된 서비스를 호출해 콘텐츠를 표시하거나 제어합니다.예를 들어 운전자가 차량 화면에서 음악 앱 아이콘을 탭하면, 차량 내 Android Auto 인터페이스가 음악앱(휴대폰)에 연결하여 음악 목록을 가져오고 재생 제어를 수행합니다.Android Auto의 구성 요소는 크게 휴대폰 측 앱 서비스와 차량 측 UI로 나눌 수 있습니다.휴대폰 측에서는 음악 재생을 처리하는 MediaBrowserService 와 Media3, ExoPlayer 같은 플레이어가 동작하고,차량 측에서는 Android Auto가 제공하는 표준화된 UI 템플릿(리스트, 플레이어 컨트롤 등)을 통해 콘텐츠를 표시합니다.이러한 구조 덕분에 앱 개발자는 차량용 별도 UI를 만들 필요 없이, 미디어 목록과 플레이어 제어만 적절히 제공하면 Android Auto가 알아서 표준 UI로 보여주게 됩니다.요약하면, Android Auto는 휴대폰 앱을 차량과 연결해주는 브리지 역할을 합니다.운전자는 차량 화면과 음성으로 앱을 제어하고, 실제 로직과 미디어 처리는 휴대폰 앱이 담당하는 형태입니다.이를 통해 운전 중에도 운전자 친화적인 방식으로 음악앱의 음악 스트리밍 서비스를 즐길 수 있습니다.Android Automotive OS 와의 차이점차량 자체에 내장된 안드로이드 OS 입니다. 쉽게 말해, 차 안에 안드로이드 태블릿이 내장되어 있다고 보면 됩니다.사용자들은 휴대폰이 아닌 차량의 PlayStore 에서 직접 앱을 설치하며, 앱이 차량의 하드웨어에서 독립적으로 실행됩니다.예를 들어 볼보, 폴스타 등의 일부 차량은 Android Automotive OS 를 탑재하고 있어서, 휴대폰 연결 없이도 차량 자체에서 음악앱을 설치해 음악 스트리밍을 할 수 있습니다.두 환경의 주요 차이점은 구동 위치와 앱 배포 방식입니다.Android Auto 는 휴대폰 앱을 필요로 하고 차량은 단순히 디스플레이/컨트롤 역할을 하지만, Android Automotive OS 는 차량이 독립적인 안드로이드 디바이스로서 앱이 직접 구동됩니다.따라서 Android Auto 용 앱은 일반 휴대폰 앱에 차량 연결용 서비스만 추가하면 되지만,Android Automotive OS 용 앱은 차량전용으로 Bundling 및 배포가 필요하며 일부 UI 컴포넌트(예: 설정/로그인 화면 등)를 차내에서 구현해야 합니다.• None 지원 앱 카테고리: Media, Messaging, Navigation 등 Google 승인 카테고리만 가능합니다.• None 특정 카테고리만 지원하며, Auto Car Head Unit 의 앱메뉴에서는 Auto 에서 사용가능한 앱만 표시됩니다.• None UI 직접 제어 불가: Android Auto 가 제공하는 템플릿 UI만 사용 가능• None 휴대폰에서 전달하는 data 를 통해 Android Auto 에서 직접 UI 표시• None• None Google의 Android Auto 플랫폼에서는 운전자 안전을 최우선으로 고려하기 때문에 앱 개발 시 여러 가지 제한사항과 준수해야 할 가이드라인이 존재하며, 구글 심사 시 엄격하게 심사된다고 알려져 있습니다.• None 화면에 표시되는 목록 수 제한 (20개 이하 권장)• None 가이드 라인: https://developers.google.com/cars/design/design-foundations/interaction-principlesAuto 용 앱으로 등록을 위해서는 음악을 재생하는 Service 에 아래와 같은 설정이 필요합니다.• None• None Auto system 에서 해당 Service binding 을 위해 필요• None• None Auto system 에서 해당 Service 를 인식하기 위한 필수 사항• None Android Auto, Wear OS, Android TV 같은 외부 기기나 다른 앱이 당신의 앱의 오디오/비디오 콘텐츠를 탐색하고 제어할 수 있게 해주는 서비스 역할• None 미디어 플레이어와의 연결 허브 * MediaSessionCompat 를 함께 사용하여, 플레이, 일시정지, 다음곡 같은 제어를 받음 * Android Auto 는 MediaBrowserServiceCompat 를 통해 미디어 앱을 인식MediaSessionCompat.Callback은 MediaBrowserServiceCompat와 연결된 MediaSession의 제어를 처리합니다.Android Auto에서 사용자 입력(재생, 일시정지, 다음 곡 등)은 MediaSession을 통해 앱에 전달됩니다.Android 에서 제공하는 CarConnection class 를 통해 Auto 연결 상황을 observing 할 수 있습니다.• None• None ID 는 리스트 형태로 전달 가능하며, 각 ID 들은 하위 카테고리의 ID 가 됨• None 차량 UI에서 카테고리 선택(하위 카테고리 ID) → onLoadChildren() 호출 → 카테고리에 해당 하는 MediaItem 리스트 반환• None 전달한 MediaItem 은 Auto UI 상에 리스트로 노출됨(List or Grid)• None Google Assistant 를 통한 검색 요청 → onSearch() 호출 → 검색한 결과 리스트 전달 → Auto 에 검색결과 노출• None 검색 결과에 대한 분석은 Google Assistant 에서 처리하여 앱에 data 전달• None "아이유의 너랑나 틀어줘"• None 사용자가 곡 선택 → onPlayFromMediaId() 호출 → Player에

Bloter SKT, 외부 전문가 중심 고객신뢰위원회 출범

루틴 속 익숙해진 불편함, AI로 새롭게 해결하기까지   당근 AI Show & Tell #4당근은 매주 AI Show & Tell 을 통해 각 팀의 AI 실험을 전사적으로 공유해요. AI를 업무에 어떻게 적용하고 있는지, 그 과정에서 어떤 시행착오와 인사이트가 있었는지 가감 없이 나누죠. 당근은 완벽한 정답을 찾기보다 먼저 과감하게 실행하며, 새로운 시대의 문제 해결 방식을 빠르게 찾아가고 있어요. AI로 만드는 생생한 도전의 순간들, 지금 만나보세요. ️ 이 콘텐츠는 생성형 AI를 활용해 제작한 콘텐츠입니다.해당 이미지는 OpenAI의 이미지 생성 모델인 DALL·E를 활용하여 GPT-4o에서 생성되었습니다.계정과 인증을 담당하는 아이덴티티 서비스팀은 최근 AI로 일하는 방식을 새롭게 바꿔냈어요. 이 팀은 플랫폼 조직이라는 특성상, AI를 서비스 전반에 적용할 만한 아이디어를 찾기가 쉽지 않았는데요. 팀원들은 일단 작게라도 시도하면서 방향을 찾아보자 는 데 뜻을 모았어요. 그렇게 4일간의 해커톤을 기획해, 평소 업무에서 느껴왔던 문제를 각자 AI로 해결해 보기로 했죠.짧은 시간 동안 몰입한 결과, 팀원들은 각자의 자리에서 눈에 띄는 변화를 만들었어요. 반복적인 루틴을 간소화하고, 인수인계 과정의 병목을 없애고, 복잡한 기술 이슈도 더 직관적으로 처리할 수 있도록 개선했죠. 지금도 그 결과물들은 실무에 유용하게 쓰이고 있고, 사용성도 계속 고도화되는 중이에요. 익숙한 업무 루틴 속에서 문제를 발견하고 AI로 일의 방식을 바꿔낸 아이덴티티 서비스팀의 사례들을 하나씩 소개해드릴게요.Project 1. PM의 아침 루틴을 30분에서 3분으로, 당근 지표 리포터 PM인 Audrey는 매일 아침 사내 지표 플랫폼에서 국가별 가입자 수와 가입 전환율을 확인해요. 수치가 떨어진 항목을 발견하면, 관련 지표를 하나하나 비교하며 원인을 추적했죠. 반복적이고 시간 소모가 큰 아침 루틴을 바꿔보기 위해, Audrey는 중요한 지표 변화만 자동으로 정리해 주는 슬랙봇 당근 지표 리포터 를 직접 만들어보기로 결심했어요.해커톤 첫날부터 Audrey는 바쁘게 움직였어요. 자동화 구조를 익히기 위해, 유튜브 영상 요약 슬랙봇을 먼저 실습 삼아 구현했죠. 이후 n8n을 활용해 실제 당근 지표 리포터를 만들기 시작했어요. 중간중간 막히는 부분이 생길 때마다 유튜브나 검색을 통해 스스로 해결하며 끝까지 밀어붙였어요. 누구도 대신 정리해주지 않는 문제를 혼자 정의하고, 스스로 풀어낸 몰입의 시간이었죠.완성된 슬랙봇은 매일 아침 핵심 지표 변화와 특이사항을 자동으로 정리해주고 있어요. Audrey는 이 경험을 통해 일하는 방식을 새롭게 바라보게 됐어요. 생각보다 많은 업무가 일정한 흐름과 패턴을 따르고 있고, 그 구조만 파악하면 대부분 자동화할 수 있겠다는 감이 생긴 거예요. 해커톤 이후 Audrey는 프로세스가 명확한 작업들을 하나씩 자동화하는 계획을 직접 실행에 옮기고 있어요.Project 2. 그동안 쌓인 온콜 이슈를 한눈에, Oncall Summary Bot 아이덴티티 서비스팀에서는 온콜 담당자가 바뀔 때마다, 슬랙에서 지난 이슈를 일일이 다시 찾아봐야 했어요. 해결되지 않은 이슈가 있으면, 새 담당자는 수많은 스레드를 뒤지며 상황을 파악해야 했죠. 시간도 오래 걸릴 뿐 아니라, 중요한 내용을 놓치기 쉬웠죠. Mandy는 AI로 이 과정을 자동화해 보기로 했어요. 반복 작업을 줄이려다 오히려 리소스를 더 많이 쓰는 상황은 피하고 싶었기 때문에, 최대한 가볍고 효율적으로 만드는 게 목표였어요. 그래서 Mandy는 코딩 없이 워크플로우를 자동화할 수 있는 n8n을 활용해 요약봇을 만들었어요.그 과정이 쉽지만은 않았어요. 초반엔 결과 포맷이 매번 달라지는 멱등성 문제에 부딪혔죠. Mandy는 최소한의 리소스로 가볍게 구현하려는 목표에 맞춰, 파라미터 조정 없이 정교한 프롬프팅만으로 해결하려 했어요. 그런데 프롬프트가 길어지며 일부 요청이 누락되는 문제가 생기자, 에이전트를 두 개로 분리했어요. 하나는 자연어 입력을 슬랙 검색 쿼리로 바꾸고, 다른 하나는 해당 쿼리로 메시지를 검색해 요약했죠. 각 에이전트에 입력되는 프롬프트가 간결해지니, 최종 아웃풋도 일관되게 나왔어요.지금 이 요약봇은 팀의 온콜 인수인계 과정에 유용하게 쓰이고 있어요. 복잡한 대화 흐름을 한눈에 파악할 수 있게 정리해, 업무 연속성과 효율을 높이고 있죠. Mandy는 이번 경험을 통해 적은 리소스로도 실용적인 도구를 만들 수 있겠다는 자신감을 얻었어요. 이를 위해선 구현 초반부터 멱등성을 관리하는 게 핵심이라는 인사이트도 발견했고요. Mandy는 이번 실행을 계기로 앞으로도 안정적인 자동화 툴을 더 효율적인 방식으로 만들어갈 예정이라고 해요.Project 3. 에러를 일일이 살피던 밤은 이제 끝, 에러 박사 아이덴티티 서비스팀은 서버 에러가 발생하면 슬랙에 알림이 오도록 설정했어요. 실시간 대응에는 유용했지만, 긴급하지 않은 이슈에도 민감하게 반응할 수밖에 없었죠. 또 미국, 캐나다, 영국 등 시차가 다른 지역에서도 서비스가 운영되다 보니, 온콜 담당자는 24시간 내내 긴장을 놓을 수 없었고요. 가장 큰 문제는 온콜 담당자가 모든 이슈의 맥락을 알 수는 없다는 점이었어요. 스택 트레이스를 봐도 그 맥락을 구체적으로 모르면, 다른 팀원들까지 새벽에 함께 대응해야 하거나 에러 해결이 늦어지곤 했죠.Brave는 AI가 코드 맥락을 파악해 원인과 해결책까지 제시해 준다면, 부담을 크게 줄일 수 있을 거라 생각했어요. 그래서 MCP* 도구의 데이터 소스로 Sentry와 GitHub를 연동해 보기로 했죠. 우선 에러 알림이 오면, n8n 기반의 워크플로우가 자동으로 시작돼요. 몇 가지 분기를 거쳐 Sentry에서 에러 이벤트를 가져온 뒤, 메시지에 포함된 코드 위치를 기준으로 GitHub에서 관련 코드를 조회하죠. 이후 LLM이 코드를 분석해 추정 원인과 해결책을 도출하고, 슬랙 알림 댓글에 요약을 남겨요. 처음엔 맥락을 놓치거나 환각이 발생하기도 했지만, 분석 단계를 멀티턴으로 나눠 안정성을 높였어요.*MCP: AI 모델이 외부 시스템이나 데

안녕하세요, 카카오 기술 블로그 독자 여러분!Technical Writing(TW) 에이전트 프로젝트의 세 번째 소식으로 돌아왔습니다. 그동안 무슨 일이 있었는지 함께 살펴볼게요.지난 AI야, 문서 좀 대신 써 줘 - 2. 쪽지 시험에서 최신 AI 모델들이 기술 문서를 얼마나 잘 이해하는지 실험해 봤어요. 결과는 꽤 괜찮았지만, 마음 한켠엔 아직 물음표가 남아 있었습니다.왜냐하면 쪽지 시험에 사용한 문서는 테크니컬 라이터가 정성껏 작성한 완성형 문서였거든요. 그런데 실제 현업에서는 정리되지 않은 초안이나 회의 메모처럼 다듬어지지 않은 자료를 가지고 문서를 써야 해요. 과연 AI도 그런 자료로 잘 쓸 수 있을지 궁금해졌습니다.그래서 이번에는 NotebookLM을 사용해 보기로 했습니다. 구글 랩스(Google Labs)에서 만든 AI 기반 문서 분석 도구인데요, 자료를 올리면 요약해주고, 질문에도 척척 답해줘요. 논문이나 기술 자료 읽을 때 아주 유용하죠! 그리고 NotebookLM은 업로드한 자료를 학습용으로 사용하지 않습니다.(참고)아래는 NotebookLM으로 A Survey of AI Agent Protocols 논문을 읽으며 생성해 본 마인드맵이에요.실제로 사내 개발자와 기획자가 정리한 문서 수십 장을 NotebookLM에 업로드해봤어요. 사람이 읽고 이해하려면 며칠 걸릴 양인데, NotebookLM은 금세 내용을 요약하고, 원문을 근거로 질문에 답해줬어요. 카카오의 기술 문서와 스타일 가이드 기반으로 기술 문서를 새로 쓰는 것도 물론 가능했습니다.하지만 아쉽게도, TW 에이전트는 훨씬 더 다양한 제품과 기술을 다뤄야 하고, 누구나 쉽게 쓸 수 있어야 해요. NotebookLM만으로는 부족할 것 같아, 다시 원래대로 AI 모델이 직접 기술 문서를 작성하게 하는 방식으로 돌아왔습니다.앞서 TW 에이전트에게 필요한 세 가지 능력 중, 기술 정보를 분석하고 분류하는 능력은 이미 확인했죠. 이제 두 번째 능력, 복잡한 기술 정보를 이해하고 명확하게 설명하는 능력을 검증해 볼 차례예요.이번에는 구글 AI 스튜디오에서 TW 에이전트의 주인공, Gemini 2.5 Pro를 사용해 세 가지 케이스를 테스트했습니다.• 카카오의 스타일 가이드에 맞춘 문서 재작성• 템플릿과 스타일 가이드를 모두 준수한 문서 재작성테스트용 원문은 Claude 3.7 Sonnet으로 생성했어요. 실제 사내에서 개발자와 기획자가 작성하는 기술 문서처럼 보이도록, 가상의 제품 기술 문서를 만들어 테스트에 활용했습니다.기본 템플릿과 스타일 가이드는 카카오 내부에서 실제 사용하는 문서 기준을 그대로 사용했지만, AI가 이해하기 쉽도록 설명과 예시를 약간 보완했어요.기술 문서 작성 지침과 스타일 가이드는 시스템 인트로덕션(System Introductions)에 입력했고, 기술 문서 템플릿과 테스트용 원문은 첨부 파일로 전달했습니다. 파라미터는 기본값 그대로 두었어요.테스트 설계는 ChatGPT와 함께했고, 결과 평가는 Claude에게 맡겼어요. 든든한 팀이에요!첫 번째 테스트는 스타일 가이드에 맞지 않는 문장과 표현을 고치는 작업이었어요. Claude에게 “스타일 가이드 준수 여부를 평가해 달라”고 요청했더니, 변경된 내용과 부족한 부분을 시각적으로 정리한 보고서를 순식간에 만들어줬어요.아래는 보고서 내용의 일부에요.두 번째 테스트는 AI가 기술 문서 템플릿에 맞춰 문서 구조를 재구성하고 작성하는 실험이었어요. 기대했던 대로 적절한 템플릿을 선택해 문서를 구성했고, 정보 누락도 없이 중요한 내용을 잘 포함했어요. AI가 기술 문서 작성 지침과 템플릿을 올바르게 이해한 것 같아요.세 번째 테스트는 템플릿과 스타일 가이드를 모두 지키며 문서를 재작성하는 종합 테스트였어요. 사실상 TW 에이전트가 실제 업무에서 수행해야 하는 작업이기도 하죠. 테스트용 원문도 가장 복잡한 내용이었는데, 역시 AI는 몇 분 안에 멋지게 작업을 마쳤어요.전반적으로 결과가 나쁘지 않았지만, 문서 길이가 다소 길고 군데군데 읽기 불편한 표현들이 남아 있었어요. 저도 직접 검토하면서 문서가 조금 부담스럽다고 느꼈어요.첫 번째 테스트를 통해 파악한 주요 개선 포인트는 아래와 같았어요.• AI가 일관된 용어를 사용하도록 가이드가 필요하다.• AI가 가독성을 중시해 문서를 쓰도록 해야 한다.• 부족한 정보를 보완할 수 있는 장치가 있어야 한다.그래서! 저부터 살기 위해(?) 가독성 개선에 집중해 보기로 했어요. 좀 더 읽기 쉬운 문서를 만들 수 있도록 기술 문서 작성 지침을 보완해 동일한 테스트를 다시 진행했습니다.아래는 그때 추가한 가독성 개선을 위한 지침의 예시입니다.가독성 개선 지침을 반영한 문서를 Claude에게 평가하게 했어요. 효과는 굉장했다! 문장은 더 짧고 간결해졌고, 중복 표현은 줄었으며, 정보의 품질도 한층 나아졌어요. Claude의 평가를 종합하면 약 30%의 가독성 개선 효과가 있었다고 하네요.아래는 가독성 개선 평가 보고서의 일부에요.역시 보기 좋은 문서가 읽기도 훨씬 편했어요. 하지만, 또 다른 문제가 있었습니다.두 테스트의 토큰 사용량을 비교해보니, 두 번째 테스트의 출력 토큰이 거의 2배로 늘었어요. AI가 더 고민을 많이 한 만큼, 추론이 길어졌다는 뜻이겠죠?문서의 길이는 짧아졌지만, 더 많은 비용이 들게 된 상황이네요. API 사용 요금은 출력이 몇 배로 비싸기 때문에, 출력 토큰을 줄이는 방법을 고민해봐야겠어요.이번 테스트를 통해 최신 AI 모델이 템플릿과 스타일 가이드를 사용해 기술 문서를 작성하는 능력이 꽤 훌륭하다는 걸 알 수 있었어요. 이제 사용자를 위한 TW 에이전트의 인터페이스를 고민할 차례에요.그럼, 다음 편에서 만나요!• Vibe Coding하는 비개발자는 개발자인가(2)• AI는 어디까지 나를 대체할 수 있나?• Vibe Coding, 새로운 개발 패러다임의 시작일까요?• 바이브 코딩 바이블: AI 에이전트 시대의 새로운 코딩 패러다임

성능 최적화가 중요한 이유웹사이트의 성능은 사용자 경험(UX)과 비즈니스 성과에 큰 영향을 미칩니다. 페이지 로딩 시간이 길어질수록 사용자는 서비스를 이탈할 가능성이 높아지고, 전반적인 전환율이 감소합니다. 연구에 따르면, 페이지 로딩 시간이 1초 지연될 때마다 사용자의 약 10%가 사이트를 떠날 가능성이 높아진다고 합니다.속도가 중요한 또 다른 이유는 검색 엔진 최적화(SEO)입니다. 구글은 웹사이트 속도를 검색 순위의 중요한 요소로 평가하며, 특히 모바일 검색 결과에서 속도가 중요한 역할을 합니다. 즉, 웹사이트가 빠르게 로딩될수록 검색 결과에서 더 높은 순위를 차지할 가능성이 커집니다.기업 사례를 살펴보면, 성능 최적화가 실제 비즈니스 성장으로 이어질 수 있음을 알 수 있습니다.예를 들어, Vodafone은 웹사이트의 주요 성능 지표인 LCP(다음 내용 참조) 를 31% 개선하여 판매량을 8% 증가시켰습니다. 또한, 웹사이트 성능을 개선하면 사용자 참여도가 증가하고, 반복 방문율도 높아지는 경향이 있습니다.결론적으로, 웹사이트의 성능을 최적화하는 것은 단순한 기술적 개선이 아니라 사용자 만족도와 비즈니스 성공을 위한 필수 전략입니다.Web Vitals는 구글이 웹사이트 사용자 경험을 객관적으로 평가하기 위해 정의한 지표입니다. 페이지 로딩 속도, 사용자 인터랙션, 시각적 안정성을 핵심 지표로 분류하며, 이를 Core Web Vitals라 정의하고 있습니다.Core Web Vitals를 모니터링하고 개선하기 위해 노력함으로써 다음의 목적들을 달성할 수 있습니다.• 사용자 경험(UX) 개선사용자 경험을 정량적으로 평가할 수 있도록 하여, 사이트 방문자의 이탈률을 낮추기 위해 활용할 수 있습니다.• SEO(검색 엔진 최적화) 최적화Google은 Web Vitals 지표를 검색 순위 알고리즘에 반영하기 때문에 관련 지표를 개선하면 검색 결과에서 상위에 노출될 가능성이 높아집니다.• 전환율(Conversion Rate) 및 수익 증대빠르고 안정적인 웹사이트는 사용자의 만족도를 높여, 이탈률이 낮아지며 최종적으로 매출 증가 및 비즈니스 성과 향상으로 이어질 수 있습니다.• 개발 생산성 향상 및 운영 효율성 증가측정과 분석을 위한 도구들이 다양해 성능 문제를 빠르게 파악하고 해결할 수 있습니다. 또한 측정되는 데이터를 지속적으로 모니터링하기 쉬워 사이트 운영 효율성이 높아집니다.2025년 3월 기준 Core Web Vitals를 구성하는 지표들은 LCP, INP, CLS이며 각 지표의 의미와 주요 내용에 대해 알아보겠습니다.LCP는 사용자가 페이지로 처음 이동한 시점을 기준으로 화면(View Port)에서 가장 큰 영역을 차지하는 콘텐츠(이미지, 텍스트 블록 또는 동영상) 가 화면에 나타나는 데 걸리는 시간을 측정합니다. 일반적으로 가장 큰 영역을 차지하는 콘텐츠는 해당 페이지의 핵심 요소일 가능성이 높아 해당 콘텐츠를 로드 중일 때 사용자는 페이지가 아직 완전히 로드되지 않은 것으로 인식하고 기다릴 수 있습니다. 따라서 가장 큰 콘텐츠는 최대한 빠르게 표시하여 체감 로드 속도를 높이는 것이 중요합니다.LCP 측정 기준과 타임라인을 이해하기 위해 두 가지 사례를 비교해 보겠습니다.첫 번째 예는 기사 메인 이미지가 가장 큰 콘텐츠이며 페이지의 모든 구성 요소가 로드된 후 마지막에 로드되어 표시되고 있습니다.하지만 두 번째 예에서는 텍스트 단락이 가장 큰 콘텐츠이며 이미지나 로고와 같은 다른 구성 요소들이 로드되기 전에 가장 먼저 표시되고 있습니다.예시와 같이 LCP에서는 페이지 내 요소들 중에서 화면에 가장 크게 보이는 콘텐츠의 표시 속도를 측정하며 다음과 같은 성능 기준을 제시하고 있습니다.가장 큰 콘텐츠가 2.5초 이하로 화면에 표시되면 해당 사이트의 로딩 성능이 우수한 것으로 판단할 수 있으며, 2.5초 이상 특히 4.0초 이상으로 측정된다면 사용자 경험 개선을 위한 최적화가 필요할 것입니다.CLS는 사용자가 느끼는 시각적 안정성에 관한 지표로 페이지가 로드되는 동안 내부 레이아웃이 얼마나 변경되었는지 측정합니다. 예기치 않은 레이아웃 변화는 사용자가 읽던 위치를 놓치는 것부터 잘못된 링크나 버튼을 클릭하게 하는 것까지 사용자 경험을 심각히 저해하는 요인입니다.이러한 문제는 주로 비동기적으로 로드되는 리소스나 동적으로 추가되는 DOM 요소로 인해 발생하며, 이미지나 비디오의 크기가 지정되지 않았거나, 글꼴이 예상치 못하게 렌더링 되거나, 서드 파티 광고나 위젯이 동적으로 크기를 조정할 때 발생할 수 있습니다.CLS 지표는 화면 변경 비율(Impact Fraction)과 콘텐츠 이동 거리 비율(Distance Fraction)의 곱으로 계산되며, 각 요소의 측정 원리는 다음과 같습니다.Impact Fraction은 화면에서 변경이 발생했던 영역이 차지하는 비율이며 위 상황을 예로 들어보겠습니다. 첫 번째 프레임에선 콘텐츠가 50%의 영역을 차지하고 있다가 다음 프레임에서 아래로 25% 이동하여 총 75% 영역에서 변경이 발행하였습니다. 따라서 해당 케이스의 Impact Fraction 값은 0.75이며, 측정값이 클수록 사용자는 시각적으로 큰 변화를 느끼게 됩니다.Distance Fraction은 요소가 화면에서 이동한 거리를 나타내는 비율이며 동일한 상황을 예로 들어보겠습니다. 콘텐츠가 이동한 거리는 화면(View Port)의 25%이며 해당 상황의 Distance Fraction은 0.25입니다.위 예시의 CLS 값을 계산하면 아래와 같습니다.위 계산은 단일 세션에 대한 예시이며, 실제로는 여러 세션을 반복하여 가장 높은 값을 결과로 도출합니다. 1초 이내에 발생한 움직임들은 단일 세션으로 그룹화되어 합산되고, 변경이 발생한 특정 시점으로부터 1초를 초과한 변경은 새로운 세션으로 계산됩니다.이런 원리로 CLS 지표로 사용자가 느끼는 시각적 안정성을 평가할 수 있으며 다음 기준이 제시되고 있습니다.CLS 수치가 0.1 이하라면 해당 사이트는 시각적으로 안정적이나 0.25 이상으로 측정된다면 레이아웃 변화를 줄이는 등의 개선이 필요한 것으로 판단할 수 있습니다.INP는 웹

오늘은 반복적인 데이터 요청에 대응하기 위해, 기존 SQL 쿼리를 임베딩해 자동화한 AI 도구 ‘MySQLTrip’을 소개합니다.반복되는 쿼리 요청, 작은 팀의 큰 도전마이리얼트립에서 데이터는 의사결정의 핵심입니다. 하지만 데이터 분석팀에게는 끊임없이 들어오는 데이터 분석 요청이 큰 도전이 되곤 해요. 특히 비슷해 보이지만 각기 다른 요청들은 처리하는 데 많은 시간이 필요하죠.“저희도 비슷한 요청들(BI 를 위한 SQL 작성해달라는)이 되게 많이 들어와요. 그런데 이게 비슷한데 뭔가 비슷하지 않은… 이거를 만들려면 되게 많은 시간이 드는 그런 요청들이 되게 많이 들어옵니다.”겉으로 보기에는 간단한 요청도 데이터팀 입장에서는 완전히 새로운 작업이 될 수 있어요. 한 칼럼만 추가해달라는 요청이 실제로는 엄청난 작업량을 필요로 하는 경우가 많죠.“어찌 보면 ‘칼럼 하나만 추가해주세요’ 단순해 보이는 요청인데, 저희 입장에서 생각하면 ‘(그림을 보며)여기가 비어있는데 산을 그려주세요’ 이런 느낌이에요.”더구나 마이리얼트립은 ‘데이터 맛집’이라고 할 수 있을 정도로 데이터를 적극적으로 활용하고 있어요. 하지만 데이터 분석팀은 단 3명에 불과해 모든 요청을 처리하는 데 병목 현상이 생길 수밖에 없었죠.이렇게 줄 서서 기다려야 하는 상황, 그리고 각기 다른 요청에 맞춰 계속 새로운 ‘요리’를 만들어야 하는 환경에서 우리는 AI의 도움을 받기로 결정했어요.AI를 활용한 SQL 쿼리 자동 생성 시스템 개발반복적인 SQL 쿼리 작성 작업을 효율화하기 위해 ‘MySQLTrip’이라는 AI 도구를 개발했어요. (이름도 AI에게 부탁해서 지었답니다!)이 도구는 데이터 분석팀이 기존에 작성했던 검증된 SQL 쿼리들을 활용해 새로운 쿼리를 자동으로 생성하는 시스템이에요.하지만 모든 쿼리를 다 활용할 수는 없었어요. 신뢰할 수 있는 쿼리들만 선별했고, 너무 복잡한 비즈니스 로직이 포함된 것은 제외했죠. AI가 아직은 우리 비즈니스를 완벽하게 이해할 수 없기 때문이에요.“너무 복잡한 쿼리나 비즈니스 로직이 많이 포함된 것들을 포함하지는 않았어요. 왜냐하면 AI가 아직은 저희 비즈니스를 다 이해할 수 없기 때문이죠.”시스템 구축을 위해 우선 기존 쿼리들을 카테고리화했어요. 고객 추출, 유입 전환 퍼널, GMV, 커뮤니티, 마케팅 파트너, 예약 후 리드 타임 등의 카테고리로 나누고, 이를 데이터베이스에 저장했죠.그 다음 단계로 이 쿼리들을 Embedding했어요. Embedding이 무엇인지 쉽게 설명해 드릴게요.“Embedding 을 간단하게 설명드리면 이렇게 샌드위치, 각각의 음식에 대해서 이 음식이 어디에 존재하고 있는지를 거치보면 점으로 찍어놓은 거라고 보면 될 것 같아요. 그래서 여기는 샌드위치화된 애들은 이쪽에 있고 디저트화된 거는 이쪽에 있고…”이렇게 음식 종류별로 위치가 다르듯, 각 쿼리도 특성에 따라 벡터 공간에 배치되죠. 그러면 새로운 요청이 들어왔을 때, 그 요청과 가장 비슷한 기존 쿼리를 찾아낼 수 있어요.이런 방식으로 고객의 데이터 요청과 가장 관