흩어진 테크 블로그 글을 한곳에서 찾아 읽어요
여러 기술 블로그의 새 글을 제목·요약·태그로 검색하고 주제별·블로그별로 살펴볼 수 있어요. 글 상세와 원문은 로그인 없이 볼 수 있고, 로그인하면 읽음 표시와 즐겨찾기를 동기화하고 개인 노트를 저장할 수 있어요.
기업 기술 블로그별 최신 글 보기 → · 기획자·개발자별 활용 방법 →
NAVER D2
크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까?
네이버 사내 기술 교류 행사인 NAVER Engineering Day 10th 에서 발표되었던 세션을 공개합니다. 크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까? NAVER D2 | 크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까? naver.me 발표 내용 여러 엔티티를 한 공간에 담은 통합 임베딩과 범용 리트리벌이 크림 추천 곳곳에 쓰이는 방식, 운영하며 드러난 한계를 v2에서 해결한 과정, 그리고 확장 방향을 공유합니다. 발표 대상 추천 시스템의 후보 생성(Retrieval) 단계에 관심 있으신 분들 여러 서비스·지면에서 함께 쓰는 공용 임베딩을 설계하고 운영하고 싶으신 ML 엔지니어 조건(필터)이 걸린 벡터 검색의 지연과 메모리를 줄이고 싶으신 분들 구좌·서비스마다 늘어나는 추천 모델을 줄이고 싶은 추천·검색 조직의 엔지니어와 기획자 키워드 Recommendation System / Candidate Generation (Retrieval) Universal Embedding (Bi-encoder · Contrastive Learning) Matryoshka Representation Learning (MRL) Filtered Vector Retrieval (Roaring Bitmap · Brute-force vs ANN) Embedding Serving Optimization 목차 PART 1. 왜 통합 임베딩인가 2025년의 크림: 추천 구좌마다 모델이 따로 있었다 목표: 여러 목적에 쓸 수 있는 범용 임베딩 하나 구좌마다 ‘누구에게 · 무엇을 · 어떻게’가 다르다 통합 임베딩은 후보 생성에 직접, 랭킹에도 입력으로 설계 원칙: 모든 질문이 ‘벡터 + 조건’이 된다 PART 2. v1 모델 — 하나의 공간을 만들다 하나의 인코더가 검색어와 상품을 모두 읽는다 학습: InfoNCE를 받쳐 주는 일곱 가지 장치 학습은 상품 하나, 나머지는 모두 집계로 그림으로 보면: 모두가 상품 공간 위의 점 PART 3. v1 리트리벌 — 하나의 API로 꺼내 쓰다 질문 하나 = 요청 하나 조건별 상품 목록을 미리 만들어 두고 꺼내 쓰기 구좌 전용 모델 없이 붙은 첫 구좌들과 타겟 집단 추천 PART 4. 써 보니 드러난 v1의 한계 모델: 가끔 붕괴하고, 768차원은 무거웠다 리트리벌: 큰 조건을 감당하지 못했다 리트리벌: 조건을 자유롭게 조합할 수 없었다 v1의 한계, 한눈에 PART 5. v2 — 한계를 하나씩 걷어내다 모델 1차: 학습을 안정시키다 모델 2차: 하나의 벡터, 여러 해상도 (MRL) 좌표계: 회전으로 맞추려 했지만, 통하지 않았다 필터: Roaring Bitmap으로 조건을 실행할 때 조합 왜 근사 검색(ANN)이 아니라 후보 전부를 계산하나 점수 계산: 계산량은 그대로, 메모리 낭비만 없앴다 결과: 응답 지연은 약 4배 빠르게, 메모리는 1/6로 API: 조건 칸 하나 → 조건 리스트 v1의 한계 → v2의 처방 PART 6. 지금의 쓰임과 다음 확장 지금: 하나의 API가 채우는 지면과 구좌 비슷한 브랜드: 브랜드 벡터만으로는 부족했다 리트리벌 밖에서도 같은 벡터 다음으로 — 멀티벡터, 지면 확장, 마케팅 타겟팅 ◎ NAVER Engineering Day란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기) 올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다. [동영상 제공 채널 안내] 네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다. 앞으로
worxphere-tech - Medium
[5편] 숫자가 정답이 아닐 때, 결국 사용자를 만나야 알 수 있습니다
WORXPHERE 채용 지원 UT의 가설 세 개와 가설 밖 발견 세 개 안녕하세요. 잡플래닛에서 채용 지원 영역을 맡고 있는 6년차 프로덕트 디자이너 송인경입니다. 이번 글은 우리 팀이 연속 지원과 AI 이력서 매핑, 두 축에서 세 개의 가설을 기반으로 사용자를 만난 기록입니다. 결과만 먼저 공유드리면, 가설 두 개 중 둘은 기각되었고 하나만 조건부로 남았습니다. 대신 예상하지 못한 발견을 안고 돌아왔습니다. 정량 데이터가 가리키는 방향과 사용자가 실제로 원하는 방향이 다를 수 있다는 것을, 아홉 번의 인터뷰로 다시 배운 사흘이었습니다. 검증에 쓴 프로토타입은 Claude로 직접 만들어 GitHub Pages에 배포했습니다. 그 과정은 [2편] 코드 못 짜던 디자이너가, 네 프로젝트를 깃허브 저장소 하나로 합친 기록에서 자세히 다뤘으니 궁금하신 분은 2편을 봐주세요. 시작은 깔끔한 데이터 한 줄이었습니다 지원을 완료하고 10분 안에 다른 공고의 ‘지원하기’ 버튼을 누르는 사용자가 약 40% 였습니다. 채용 영역 중 어디부터 개선하면 좋을 지 지표를 훑다가 눈에 들어온 숫자였습니다. “사용자가 이미 연속 지원을 하고 있으니 연속 지원을 더 쉽게 해주면 더 많이 지원하지 않을까?” 생각은 자연스럽게 그쪽으로 흘렀습니다. 그렇게 가설을 세 개 세웠습니다. H1은 연속 지원, H2는 이력서 작성 부담을 줄이는 두 가지 접근(H2‑1, H2‑2)으로 나눴습니다. H1. 사용자는 지원을 완료한 뒤, 유사한 공고를 추천해주면 이어서 여러 군데 지원할 것이다. H2‑1. AI가 타사 혹은 가지고 있는 기존 이력서를 기반으로 자동으로 작성해주면, 잡플래닛에서도 이력서를 새로 작성할 것이다. (전제 조건: 새 이력서 작성에대한 부담감이 있을 것이다) H2‑2. 이력서 폼에서 필수와 선택 항목을 시각적으로 한눈에 구분해주면, 어디까지만 작성하면 되는지 빠르게 파악해 입력 부담이 줄 것이다. 채택 기준은 인터뷰 전에 미리 정해두었습니다. 9명 중 7명 이상이면 검증, 4~6명이면 조건부 채택, 3명 이하면 재설계로 판단하기로 했습니다. 결과를 본 뒤 기준을 바꾸는 일을 막기 위해서였습니다. 참여자는 이직이 급한 사람을 중심으로 모집했고, 긴급 7명과 비긴급 2명, 총 9명을 만났습니다. 그런데 가설이 뒤집혔습니다 첫 번째 가설은 9명 중 1.5로 연속 지원 40%라는 기존 데이터가 무색해졌습니다. 9명 중 7명이 거의 같은 이유로 거절했기 때문입니다. “진짜 막 지원할 때 아니고는, 첫 문장이라도 바꿔서 이력서를 다시 내려고 해요.” (P1, PM) “공고마다 직무 이름이 달라서 맞춰서 내요. 같은 이력서로 여러 군데를 어떻게 내지? 싶어서 저는 그냥 패스.” (P2, UX 리서처) “각각의 JD에 맞는 내용을 이력서에 넣어야 되기 때문에 똑같은 이력서로 연속 지원은 안 할 것 같아요.” (P4, 전략 기획) 여기서 알게 됐습니다. 40%는 ‘다시 지원하는 행동’의 숫자였지, ‘같은 이력서로 다시 지원하고 싶다’는 의향의 숫자는 아니었습니다. 사용자를 직접 만나지 않았다면 몰랐을 겁니다. 데이터만 봐서는 알 수 없는 이야기였으니까요. ‘방금 낸 이력서를 그대로 쓴다’는 건 우리 팀의 생각이었을 뿐, 사용자에게는 당연한 일이 아니었습니다. 화면 앞에서 머뭇거리는 모습을 보고 나서야 알았습니다. ‘AI 이력서’라는 단어가 만든 또 다른 오해 H2‑1, AI 이력서 매핑도 예상 밖이었습니다. 5명은 이력서 작성 화면에 진입조차 하지 않았습니다. “AI 이력서 채우기 기능이 있는 건 좋지만, 작성 페이지까지 넘어와서 이 여정을 시작하진 않을 것 같아요.” (P1) “이미 만들어 놓은 이력서가 있으니까, 여기서 새로 만들 필요가 없다고 느껴져요.” (P8) 힌트는 P8의 “여기서 만들 필요가 없다”는 말이었습니다. 우리는 기존 이력서를 그대로 불러올 수 있도록 설계했는데, 사용자는 새로 작성하는 기능으로 인지하고 진입 자체를 포기한 셈입니다. 진입한 4명 중 3명이 긍정적으로 반응했지만, 모두 조건을 달았습니다. 매칭률이 70%나 100%처럼
딸깍으로 안되는 Multi-interest 개발기
네이버 사내 기술 교류 행사인 NAVER Engineering Day 10th 에서 발표되었던 세션을 공개합니다. 딸깍으로 안되는 Multi-interest 개발기 NAVER D2 | 딸깍으로 안되는 Multi-interest 개발기 naver.me 발표 내용 다양한 관심사 추천 모델인 Multi-interest를 여러 지면에 적용하며 겪었던 문제를 해결했던 과정을 공유합니다. 주제: Multi-interest 추천 모델(MINER)의 KREAM 실서비스 적용 사례 문제: 인기 상품 목록에서 특정 상품이 전체 유저에게 동시 노출되는 hubness 발생 분석: 점수를 유저 의존 성분과 유저 무관 성분으로 분해, 가설 3개를 실측으로 검증 조치: 유저 무관 성분 제거(centering, bias 분리), 추천 결과 다양화, 분포 지표 기반 평가 체계 도입 결과: 과노출 상품 전량 제거, 노출 상품 종류 +25%, 구매 지표 유지 시사점: 논문 구조의 실서비스 적용 시 발생하는 문제와 사전 점검 항목 발표 대상 Multi-interest 추천 모델에 관심 있으신 분들 목차 문제상황 가설 수립, 유저 의존 성분 + 유저 무관 성분 전략 1. 유저 무관 성분 낮추기 전략 2. 유저 유관 성분 높이기 전략 3. 두 성분을 지표에서 모니터링 남은 과제 및 점검항목 ◎ NAVER Engineering Day란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기) 올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다. [동영상 제공 채널 안내] 네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다. 앞으로도 많은 관심과 팔로우 부탁드리겠습니다.
MUSINSA techblog — 무신사 테크 블로그 - Medium
예측을 넘어 결정과 발견으로: DeciML과 NeXA를 만든 이유
안녕하세요. 무신사에서 ML Engineer로서 추천, CRM, 유저 속성, ML 플랫폼 등을 담당하고 있는 Core-E Personalization 팀의 김윤태입니다. 저희 팀에서는 개인화와 관련된 여러 문제를 풀고 그 문제를 서비스에 전달하기 위한 플랫폼을 만들어 가면서 개인화가 앞으로 어떤 방향으로 확장될 수 있을지 고민해 왔습니다. 개인화의 범위가 넓어질수록 ML로 풀어야 하는 문제도 달라집니다. 커머스의 검색과 추천, 광고, 앱 푸시, 쿠폰, 배너 등 다양한 채널이 각각 다른 목적에서 출발했고, 무신사와 29CM에서도 그랬습니다. 하지만 이들은 개인화가 확장될수록 점점 하나의 질문으로 수렴합니다. 이 고객에게 지금 무엇을 보여줄 것인가? 고객이 반응할 확률을 구하는 예측(prediction) 문제만 풀어서는 이 질문에 답할 수 없습니다. 반응할 확률이 높다고 해서 고객에게 모든 것을 무한정 보여줄 수는 없기 때문입니다. 하루에 보낼 수 있는 푸시의 수, 이번 달에 사용할 수 있는 쿠폰 예산, 한 화면에 담을 수 있는 상품의 수처럼 쓸 수 있는 자원에는 늘 한계가 있습니다. 반응 확률을 예측한 뒤에도, 그 한계 안에서 누구에게 무엇을 보여줄지는 따로 결정해야 합니다. 이런 문제를 풀기 위해 저희는 DeciML과 NeXA라는 두 개의 ML 플랫폼을 새로 만들었습니다. 두 플랫폼은 문제에 맞는 ML 모델을 학습하고 그 결과를 서비스까지 전달합니다. DeciML은 결정(decision) 문제를, NeXA는 발견(discovery) 문제를 다룹니다. 이 글은 두 플랫폼을 소개하는 시리즈의 첫 편입니다. 이번 편에서는 저희가 마주한 문제와 새로운 플랫폼이 필요했던 이유, 그리고 두 플랫폼이 맡을 역할과 설계 방향을 이야기합니다. 후속 편에서는 두 플랫폼의 구조와 적용 범위, 플랫폼 위에서 문제를 풀어 나간 사례를 차례로 다룹니다. The Problems Ahead 점수 예측만으로는 답할 수 없는 지점들 지금까지 많은 개인화 문제는 비교적 익숙한 형태로 풀 수 있었습니다. 고객과 상품, 혹은 고객과 콘텐츠의 조합마다 “이 고객이 반응할 확률은 얼마인가”를 예측하고 그 값을 기준으로 가장 점수가 높은 선택지를 고르는 방식입니다. 클릭률(CTR)이나 구매 전환율(CVR)처럼 하나의 점수를 잘 예측하는 것이 문제 해결의 핵심이었습니다. 하지만 서비스와 지면의 복잡도가 높아지고 개인화의 범위가 넓어질수록, 단순히 높은 점수를 고르는 것만으로 풀어낼 수 없는 문제가 발생합니다. 무엇을 보여줄지에 더해 제한된 자원을 누구에게 배분할지도 결정해야 하고 고객의 행동이 실제로 서비스의 개입 때문에 바뀌었는지도 알아야 합니다. 여러 지면의 결정을 함께 고려해야 하는 경우도 있고 새로운 발견 지면이 생길 때마다 그곳에 ML을 빠르게 적용해야 하기도 합니다. 이런 한계는 이미 서비스 곳곳에서 나타나기 시작했고 개인화가 진행될수록 더 다양한 형태로 늘어날 것입니다. 그중 지금 저희가 중요하게 보고 있는 네 가지 유형은 다음과 같습니다. Constrained Allocation. 오늘 보낼 수 있는 푸시가 한 통뿐이라면 누구에게 보내야 할까요? 하루에 보낼 수 있는 푸시 슬롯은 정해져 있고 쿠폰 예산에는 한도가 있습니다. 이때는 정해진 슬롯과 예산을 누구에게 배분할지 답해야 합니다. 점수는 배분의 입력이 될 수 있지만 배분 자체는 제약을 함께 고려해야 풀 수 있습니다. 누구에게 보낼지뿐 아니라 누구에게 보내지 않을지도 결정할 수 있어야 합니다. Incrementality. 앱 푸시의 클릭률을 높였는데 왜 앱 진입이나 구매 같은 비즈니스 지표는 그대로일까요? 원래 앱에 들어올 가능성이 높은 고객에게 푸시를 보냈다면, 클릭이라는 반응은 만들 수 있어도 푸시가 없었을 때와 비교해 실제 행동이 얼마나 달라졌는지는 알 수 없기 때문입니다. 중요한 것은 반응할 확률이 아니라, 개입이 실제로 만들어낸 변화가 얼마나 되는가입니다. 이를 알기 위해서는 개입이 있었을 때와 없었을 때의 차이를 추정해야 합니다. Cross-surface Coordination.
미리디 블로그 - Medium
채팅으로 디자인하는 AI, 실제로 쓸까? — A/B 테스트와 사용자 행동 분석기
들어가며 안녕하세요. 미리캔버스 검색추천 스쿼드에서 데이터 분석가로 일하고 있는 윤지호입니다. 2026년 9월, 미리캔버스 에디터에 ‘AI 디자이너’ 기능이 추가됐습니다. 사용자가 채팅으로 원하는 작업을 요청하면 템플릿을 검색하거나 이미지를 생성하고, 캔버스에 있는 요소를 수정해 주는 AI 에이전트입니다. 이번 MVP에서 확인하고 싶었던 것은 사용자가 실제로 채팅을 통해 디자인 작업을 수행하려 하는지, 그리고 어떤 작업을 주로 요청하는지였습니다. 저는 이 프로젝트의 데이터 분석가로 참여해 PRD 단계의 이벤트 설계부터 실험 데이터 검증, 사용자 발화 분석, 배포 방향 제안까지 담당했습니다. 약 4주간의 A/B 테스트를 진행하면서 예상과 다른 사용자 행동을 여러 차례 발견했습니다. 특히 사용자가 에이전트를 한 번 사용한 뒤 돌아오지 않는 이유를 분석하는 과정에서 초기 가설을 수정해야 했고, 이를 바탕으로 제품의 개선 방향도 구체화할 수 있었습니다. 이번 글에서는 실험을 준비하면서 고민했던 지표 설계, 사용자 행동 분석 과정, 그리고 분석 결과가 실제 제품 의사결정으로 이어진 경험을 공유하려 합니다. 1. 사전 분석 시, 먼저 지표 설계를 통해 팀이 같은 숫자를 보게 했습니다 출시 전 저희가 확인하고 싶었던 질문은 크게 세 가지였습니다. 사용자는 채팅으로 디자인하는 경험을 원하는가? 외부 AI 서비스가 많은 상황에서 미리캔버스 에디터 안에서 채팅하는 것이 어떤 가치를 제공하는가? 여러 도구를 호출하는 에이전트의 응답이 느려지면 사용자는 이탈하는가? 이를 확인하기 위해 AI 디자이너의 노출 방식이 다른 세 개의 실험군과 에이전트가 없는 대조군을 구성했습니다. 국내 유료 에디터 2.0 사용자를 대상으로 9월 15일부터 10월 13일까지 약 4주간 실험을 진행했습니다. 분모를 합의하지 않으면 같은 데이터로 반대 결론이 나옵니다 실험을 준비하면서 먼저 정리해야 했던 지표 중 하나는 ‘도구 결과 채택률’이었습니다. AI 디자이너에는 하나의 결과를 반환하는 도구도 있고, 여러 결과를 목록으로 제공하는 도구도 있습니다. 그런데 이 두 유형을 동일한 기준으로 집계하면 채택률을 비교하기 어려웠습니다. 실제로 같은 템플릿 검색 도구라도 노출 이벤트를 기준으로 집계하는지, 사용자를 기준으로 집계하는지에 따라 채택률에 상당한 차이가 발생했습니다. 이런 상태에서는 지표를 확인하는 사람마다 서로 다른 숫자를 기준으로 기능의 성과를 판단할 수 있습니다. 이를 해결하기 위해 도구를 결과 반환 방식에 따라 단일 결과형과 목록형으로 구분하고, 각 유형에 적합한 분모를 정의했습니다. 이후 채택률을 집계할 때는 어떤 분모를 사용했는지 명시하도록 했습니다. 기존 대시보드에서 사용하던 정의와도 비교해 집계 기준을 맞췄습니다. 지표를 새롭게 정의하는 것뿐 아니라 기존에 확인하던 수치와 왜 차이가 발생하는지 설명하는 과정도 필요했습니다. 이렇게 집계 기준을 정리한 덕분에 이후 실험 결과를 비교하거나 도구별 성과를 분석할 때 일관된 기준을 적용할 수 있었습니다. 2. 이탈 유저 정의 및 유저 발화 분석 4주 동안 요청과 사용자는 목표보다 훨씬 많았습니다. 문제는 대화가 이어지지 않는 것이었습니다. 4주간의 실험에서 사용자 수와 요청 수는 모두 목표를 초과했습니다. 하지만 실제 사용 패턴을 살펴보니 아쉬운 부분도 있었습니다. 전체 대화 스레드의 절반 이상이 한 번의 요청으로 끝났고, 도구 결과 채택률도 출시 전 설정한 목표에 미치지 못했습니다. 에셋 전환율은 대조군과 큰 차이가 없었으며, 주간 리텐션 역시 기대했던 수준은 아니었습니다. 처음에는 응답 속도가 주요 원인일 것으로 예상했습니다. 도구 호출 응답시간의 중앙값이 30초를 넘었기 때문입니다. 사용자가 처음 에이전트를 경험했을 때 응답이 지나치게 느리면 다시 사용하지 않을 가능성이 있다고 생각했습니다. 하지만 실제 중단 비율을 살펴보니 응답 지연만으로 이탈을 설명하기는 어려웠습니다. 그래서 사용자가 어떤 요청을 보냈고, 그 요청이 실제로 처리됐는지 확인할 필요가 있었습니다. 먼저 분석 대상을 구체적으로 정의했
tech.kakao.com
AI 시대의 개발자를 꿈꾸는 학생 개발자에게
시작하며: 2018년과 2026년 사이의 간격과 격변기의 고민 2018년에 저는 '백엔드 개발자를 꿈꾸는 학생개발자에게'라는 글을 이곳 D2 블로그에 공유했습니다. 당시 학생 개발자들과의 미트업 행사에서 나왔던 질문과 답변을 정리한 글이었습니다. 그 후 8년의 시간이 흘렀기에 그 글만 노출된다면 학생들에게 현시점에 적절한 정보를 주지 못할까 봐 걱정되었습니다. 그래서 2025년 말 설문으로 질문을 받아 후속편을 작성했습니다. 그동안 저도 경험과 지식을 더 쌓았습니다. 하지만 지금 학생 개발자들이 한 질문에는 답하기가 더 어려워졌습니다. 개발자의 역할과 같은 큰 주제를 묻는 질문이 많았는데, 지금은 AI로 인한 변화가 큰 시기이기 때문입니다. 스스로도 확신이 없는 시기에 이런 글을 쓰는 것이 적절할지 고민도 했습니다. 그럼에도 2018년의 글에 보내 주신 관심에 용기를 얻어서 이 글을 발행합니다. 최근의 경험을 나누고 미래를 함께 상상해 보는 일이 지금 시점에는 더 의미가 있다고 생각합니다. 이 글을 목적지가 명확한 안내서보다는 격변기의 스냅샷 정도로 봐 주셨으면 합니다. 주요 질문과 답변 설문을 통해 들어온 질문들을 비슷한 주제로 모아서 답변을 정리했습니다. [AI 시대와 개발자] 가장 비중이 높은 질문 유형이었고 근본적인 주제이기도 합니다. 이 질문에 먼저 답하지 않고서는 다른 이야기를 풀어 가기가 어려웠습니다. AI 시대에 개발자의 역할은 어떻게 달라졌을까요? 누군가는 AI를 인터넷이나 전기, 불에 비견될 정도의 혁명이라고 말합니다.[1] 2025년부터는 그 주장이 과장이 아니라고 느낍니다. 제가 프로그래밍을 시작한 1989년 이후로 '코딩’이라는 활동에 가장 큰 변화가 왔습니다. AI 코딩 도구가 코드를 추천해 주는 역할에서 나아가 소스 작성, OS 명령 실행 등 사람의 실질적인 대리로 행동합니다. 역사를 돌아보면 기술이 발전하면서 지식 근로자가 하는 일은 이전 시대 관리자의 역할에 가까워졌습니다. 1980년대에 개인용 컴퓨터가 보급되기 전까지 지식 근로자의 작업 공간은 종이였고, 수기로 정보를 처리하는 일에 쓰는 시간의 비중이 컸습니다. AI 시대 전에도 계산, 정보의 형식 변환과 취합 등 컴퓨터가 하는 일의 범위는 꾸준히 늘어 왔습니다. 과거의 실무 일부를 컴퓨터가 하게 되면서 말단의 지식 근로자도 영향력이 큰 의사결정에 많이 관여할 수 있게 되었고 권한도 커졌습니다. CAD 도입 전 General Motors의 기술자들이 작업하는 모습 (이미지 출처: ArchDaily) 이제는 조직의 말단 작업자는 AI이고 모든 개발자는 AI 팀의 관리자가 되었습니다. 사람은 여러 AI 에이전트에게 업무를 지시하고 결과에 피드백을 줍니다. 아래에 나열한 일들은 전통적인 관리자의 역할이기도 하지만 '작업자’를 'AI 에이전트’로 바꿔서 읽어 본다면 이제는 모든 개발자가 하는 일입니다. 다수의 작업자에게 목표와 배경, 추구하는 가치, 평가 기준을 제시한다. 작업자의 정보 탐색 비용을 줄여 준다. 참조할 정보가 어디에 있는지 알려 준다. 작업자별 역할을 명확히 정의하여 할 일을 분배한다. 작업자별 장점과 투자액(과금액) 수준을 고려하여 각자의 작업에 집중할 수 있도록, 컨텍스트가 과도하게 넓어지지 않고 컨텍스트 전환이 최소화되도록 의사결정자와 작업자 간의 효율적인 피드백 사이클을 구축한다. 관리 업무의 멀티태스킹도 개발자가 적응해야 할 환경이 되었습니다. 에이전트에게 많은 일을 맡기려면 다수의 작업자가 병렬로 일을 진행할 수 있도록 지시를 내리고 결과물에는 빠른 피드백을 주어야 합니다. 작업자마다 컨텍스트를 좁혀 줄수록, 넓은 범위의 맥락을 머리에 올려 두고 빠르게 전환해야 하는 부담은 사람에게 더 크게 돌아옵니다. AI 에이전트와 일하는 형태는 여러 메신저 창을 왔다 갔다 하면서 다수와 병렬로 대화를 이어 가는 관리자의 모습과도 닮아 갑니다. 어떤 순간에는 화면을 어지럽게 전환하면서 게임 유닛에게 작업 지시와 확인, 판단을 쉴 틈 없이 하는 프로게이머와도 유사하게 느껴집니다. 정보를 찾을
당근 기술 블로그 - Medium
모델만 바꿨는데 LLM 비용이 3배가 된 이유
안녕하세요, 당근 커뮤니티홈팀에서 백엔드를 개발하는 제이(Jay)예요. 당근 앱의 커뮤니티 탭에는 이웃이 알려 주는 동네 정보부터 소소한 일상과 취미까지 나누는 동네생활, 모임, 카페, 아파트가 모여 있어요. 커뮤니티홈팀은 이 서비스들의 글을 한데 모아 보여 주는 피드를 맡고 있어요. 피드를 맡으며 가장 고민하는 건 사용자에게 더 알맞은 글을 어떻게 보여 줄지예요. 그래서 기존 머신러닝 추천에 더해, LLM으로 글의 다양한 메타데이터를 뽑아 추천에 쓰고 있어요. 그중 하나가 LLM에 카테고리 목록과 글을 주고 어느 주제에 속하는지 고르게 하는 주제 분류예요. 추천은 보여 줄 글 후보를 모으는 단계와 그 순서를 정하는 단계로 나뉘는데, 글마다 주제가 붙어 있으면 첫 단계부터 사용자가 관심 있는 주제의 글을 골라 올 수 있어요. 주제 분류를 할 때 LLM에 보내는 요청을 열어 보면 대부분이 매번 똑같은 지시문과 카테고리 목록이고, 글 본문은 끝에 조금 붙어 있을 뿐이에요. 이 글에서는 요청마다 똑같은 이 부분을 고정부라고 부를게요. 2026년 8월, 이 작업의 모델을 Gemini에서 단가가 20% 낮은 OpenAI GPT-5.6으로 바꿨어요. 응답은 정상이었고 에러도 한 건 없었어요. 닷새 뒤 보니 단가는 내렸는데 요청당 비용은 3.2배가 돼 있었어요. 원인은 프롬프트 캐시였어요. 입력 중 캐시에서 읽어 온 비율인 캐시 히트율이 85.8%에서 2.3%로 떨어져 있었죠. 교체 전후의 응답을 나란히 놓으면 달라진 곳은 사용량 정보 안의 캐시 필드 하나뿐이었어요. 캐시가 깨져도 에러는 나지 않아요. 비용만 늘어요. 이 글은 그 일을 해결하며 알게 된 것을 정리한 기록이에요. 캐시가 무엇을 재사용하는지, 비용은 어떻게 매겨지는지, 언제 켜지고 어디까지 저장되는지, 캐시에서 읽었는지는 어떻게 확인하는지를 OpenAI, Anthropic, Google Gemini를 나란히 놓고 살펴봐요. 같은 지시문에 입력만 바꿔 LLM을 대량으로 부르거나, 챗봇이나 에이전트처럼 앞부분이 같은 요청을 되풀이해 보내는 분이라면 참고가 될 거예요. 프롬프트 캐시의 원리 신입 검수자에게 매번 규정집 20쪽과 오늘 볼 글 한 편을 함께 준다고 해 볼게요. 규정집은 늘 같고 글만 바뀌는데, 이 검수자는 기억을 못 해서 글마다 규정집을 처음부터 다시 읽어요. 하루 10만 편이면 규정집을 10만 번 읽는 셈이에요. LLM도 똑같이 요청마다 프롬프트 전체를 처음부터 다시 읽어요. 이 낭비를 줄이는 게 프롬프트 캐시예요. 앞 토큰을 돌아보는 어텐션 LLM은 글을 토큰 단위로 하나씩 이어 써요. 다음 토큰을 고르기 전에는 앞 토큰들을 돌아보며 무엇을 참고할지 따지는데, 이 계산을 어텐션(attention)이라고 해요. “어제 시장에서 산 사과를 깎아서” 다음에 올 토큰을 고른다고 해 볼게요. 사람은 바로 “먹었다”를 떠올려요. “사과”와 “깎아서”가 가장 관련 있고 “어제”나 “시장에서”는 덜 중요하다는 걸 알기 때문이에요. 모델은 이 판단을 마지막 토큰 “깎아서” 자리에서 숫자로 해요. 어텐션에는 토큰마다 세 가지 값이 쓰여요. 도서관에서 자료를 찾는 일에 비유해 볼게요. Q(Query, 질문): 마지막 토큰이 다음 토큰을 고르려고 들고 있는 질문이에요. “무엇을 했는지 이어 쓰려면 어떤 정보가 필요하지?” 같은 것이에요. K(Key, 분류표): 앞 토큰마다 붙은 꼬리표예요. 책의 분류표처럼 “먹을 수 있는 물건”, “때를 나타내는 말” 같은 정보를 담아요. V(Value, 내용): 앞 토큰이 실제로 건네주는 정보예요. 책의 본문에 해당해요. 마지막 토큰 “깎아서”는 자기 Q를 앞 토큰들(자기 자신 포함)의 K와 하나씩 맞춰 보고 점수를 매겨요. “사과”와 “깎아서”는 높은 점수를, “어제”는 낮은 점수를 받아요. 그다음 점수 비율대로 V를 섞고 그 결과로 다음 토큰 “먹었다”를 골라요. 분류표(K)로 관련 있는 책을 고른 뒤, 그 책들의 본문(V)을 점수만큼 읽는 것과 같아요. 실제 Q, K, V는 사람이 읽을 수 있는 문장이 아니라 숫자 묶음(벡터)이고,
케이뱅크 공식 블로그금융 AI의 다음 단계는?
싱가포르 DIS 2026 출장기 금융 AI의 다음 단계? 2026.10.21 조용걸 AX팀 AI를 통해 고객의 금융 생활과 내부 업무를 개선하는 서비스를 개발하고 있습니다. 안녕하세요. 케이뱅크 AX팀 조용걸입니다. 제가 속한 AI CX 그룹에는 국내/해외 컨퍼런스 비용을 지원해주는 프로그램이 있습니다. 위 프로그램에 지원해 선정되어 싱가포르 국립대학교에서 개최한 DIS 2026 컨퍼런스에 다녀왔습니다. DIS(Designing Interactive Systems)는 HCI(Human-Computer Interaction) 분야 학회 중 하나로, 사용자와 시스템의 상호작용을 어떻게 설계할지에 대한 디자인·기술적인 주제와 함께 그것이 사회에 어떤 영향을 미치는지를 공유하는 학회인데요. 최근에는 AI가 주요 화두입니다. 두근두근, DIS 2026 입장! 최근 대화형 AI 서비스 업무들을 진행하면서 아래 네 가지 주제에 대해 고민해 왔습니다. 이번 기회를 통해 고민해 온 질문에 대한 실마리를 찾고, 앞으로 나아갈 방향에 대한 인사이트를 얻고자 했습니다. 네 가지 고민 주제 기능 탐색 — 대화형 AI 서비스가 제공하는 역할 범위가 커질 때 어떤 기능까지 제공하는지 사용자가 어떻게 이해하고 사용할 수 있는가? 개인화 — 사용자 정보 바탕으로 맥락에 맞는 행동 제안 및 사용 유도를 어떻게 할 수 있을까? 마케팅 — 서비스 사용성을 저해하지 않으면서 상품 권유 및 마케팅 요소를 어떻게 제공할 수 있을까? 인터페이스 — AI 결과를 어떻게 사용자에게 전달하면 좋을까? 학회는 주말 워크샵(토,일) 이후 월화수 총 5일 동안 진행되었습니다. 최근 화두가 생성형 AI인 만큼 학회 세션 & 포스터 부스도 생성형 AI와 관련된 내용이 대다수였습니다. 그 중 2개의 페이퍼 세션이 재미있었는데요. Eveline Ingesson & Maria Riveiro, “When Do Users (Not) Want Explanations? Understanding Explanation Demand in Human-AI Interaction” (원문 보기) Clarence Chi San Cheung 외, “Who Gets Left Out of Digital Banking in Later Life? Barriers and Opportunities in Hong Kong’s Silver Population” (원문 보기) 사용자에게 AI가 그 답변을 한 근거와 내용을 제공하는 게 당연히 좋다고 생각되지만, 선행 연구들에서는 사용자들이 이 설명을 읽는 걸 시간 낭비로 여기는 경우가 많아 설명을 기본값이 아닌 선택지로 구성하는 게 좋을 수 있다는 사실을 알게 되었고, 디지털 뱅킹을 이용하는 60세 이상 고객들을 같은 집단으로 보는 게 아니라 60/70/80대별로 다르게 봐야 한다는 점도 알게 되었습니다. 60대는 디지털 뱅킹을 굉장히 잘 사용하지만 ‘잘못 누를까 봐’ 같은 심리 장벽이 있고, 70대는 서비스를 이용하는 지식 장벽이 크다는 실험 결과였습니다. 이 외에도 학회 기간 동안 함께 살펴본 최근 HCI 학회(UIST·CHI·CSCW) 논문들에서 앞의 네 가지 고민에 대한 실마리를 얻을 수 있었습니다. 기능탐색 [CSCW 2026] PromptHelper ~ Texas A&M University 첫 프롬프트부터 “뭘 물어봐야 잘 답해줄까?”를 고민하는 Cold Start 문제가 있다. 두 번째부터는 한 우물만 파게 되어, 다른 서비스나 기능을 사용할 가능성을 잃는다. 현금 흐름 서비스 사용 직후 “남는 현금 흐름을 바탕으로 이런 상품 가입은 어때요?”처럼, 사용자가 질의한 내용과 의도적으로 거리가 있는 프롬프트를 제안하기 일부러 목적과 떨어진 프롬프트를 추천해도 인지 부하는 늘지 않았다. [UIST 2025] Morae ~ Carnegie Mellon University AI 에이전트가 작업을 처음부터 끝까지 혼자 해버려서, 정작 중요한 선택과 맥락 정보를 사용자에게 알리지 않는다. “제일 싼 탄산수를 장바구니에 담아줘”라고 하자, 같은 가격의 여러 제품 중
GS리테일 DX블로그
AI 개발 도구와 세션 기반 아이템 그래프를 활용한 i2i 추천 모델 개선
GS SHOP 앱에는 백 여개에 달하는 추천 영역이 고객 탐색 경험을 돕고 있습니다. 고객의 쇼핑을 더 빠르고 편리하게 도와줄, 추천 알고리즘 개선 프로젝트에서 AI 개발 도구의 생산성을 활용해 돌파구를 찾고 성과를 만들어 낸 경험을 공유드립니다. 안녕하세요, GS 리테일 검색추천파트의 최원일입니다. 2025년 GS 리테일에 합류해 추천 시스템 전면 재구축 프로젝트를 진행하면서, 다수의 아이템 간(item-to-item, 이하 i2i) 추천 구좌가 공통으로 의존하는 핵심 모델이 있다는 사실을 알게 됐습니다. 이 모델의 성능을 개선하면 현재 운영 중인 여러 추천 영역의 비즈니스 지표도 함께 개선될 가능성이 높다고 판단해 프로젝트를 시작했습니다. 기존 i2i 모델은 ItemCF 계열의 통계 기반 머신러닝 모델입니다. 수년간 온라인 테스트에서 검증되며 좀처럼 이기기 어려운 강력한 베이스라인으로 자리 잡았습니다. 구현·운영 비용이 낮고 성능과 커버리지도 준수해, 시대별 SOTA 모델과의 경
토스 기술 블로그, 토스 테크
UX 인사이트 블로그 | 뷰저블마케팅을 잘하는 브랜드는 ‘이럴 때’ GEO를 점검합니다
신기능을 출시한 A사가 있다고 가정해보겠습니다. A사의 구성원들은 새로운 기능을 소개하기 위해 공식 홈페이지를 개편하고, 블로그 글을 작성했습니다. 이를 통해 고객이 접하게 될 A사의 정보는 이전과 분명히 달라졌습니다. 그렇다면 AI가 A사를 설명하고, 추천하는 방식에는 어떤 변화가 생겼을까요? 검색을 통해 브랜드나 제품 정보를 찾던 고객들이 이제는 정보 탐색에 AI를 활용하고 있습니다. 따라서 AI가 브랜드를 어떻게 인식하고 있는지… 더 보기 »마케팅을 잘하는 브랜드는 ‘이럴 때’ GEO를 점검합니다 The post 마케팅을 잘하는 브랜드는 ‘이럴 때’ GEO를 점검합니다 appeared first on 뷰저블.
통합임베딩으로 개인화 푸시 CTR +21.3%를 만든 과정
유저를 한 번 이해하고, 모든 결정이 공유하는 Layer 0 1편: MATCH란 무엇인가 2편: MATCH Console & MAI 3편: 통합임베딩으로 개인화 푸시 안녕하세요. 무신사 Core-E Personalization 팀에서 개인화 모델을 개발하고 있는 오승모, 방효석입니다. 이 시리즈에서는 MATCH를 중심으로 데이터를 더 나은 결정으로 바꾸는 방법을 이야기해 왔습니다. 운영자가 규칙을 직접 만드는 대신 모델이 유저 단위의 결정을 만들고, 여러 결정의 우선순위를 시스템이 판단하는 과정도 소개했습니다. 그런데 이 모든 이야기에는 하나의 공통된 전제가 깔려 있습니다. “시스템이 유저를 충분히 이해하고 있다”는 전제입니다. 어떤 유저에게 어떤 기획전을 보내야 하는지 결정하려면, 시스템 어딘가에는 그 유저의 취향과 관심사를 표현하는 공통된 표현이 존재해야 합니다. 모델마다 유저를 제각각 이해한다면, 아무리 좋은 의사결정 로직을 만들어도 결국 그 한계를 넘기 어렵습니다. 이 공통된 기반을 만드는 일은 개별 서비스의 모델을 잘 만드는 일과는 성격이 다릅니다. 새 모델의 성과는 지표로 바로 보이지만, 유저에 대한 이해를 쌓는 일은 그 자체로는 눈에 보이는 숫자를 만들지 않습니다. 대신 그 위에 올라서는 모든 결정의 품질을 좌우합니다. 이번 글은 무신사의 모든 모델과 의사결정이 공유하는 유저 표현층, Layer 0(통합임베딩)을 구축하고 이를 개인화 푸시에 처음 적용한 과정을 담았습니다. 왜 통합임베딩이 필요했는가 1편에서는 개별 최적화가 아무리 정교해져도 전체 경험에는 두 가지 갭이 남는다고 이야기했습니다. 하나는 여러 시스템이 서로 다른 결정을 내리면서 생기는 일관성의 격차, 다른 하나는 각 시스템의 학습이 저마다의 사일로(Silo)에 갇혀 서로에게 이어지지 않는 학습의 격차입니다. 통합임베딩이 겨냥한 것은 그중에서도 학습의 격차입니다. 그동안 무신사의 유저 단위 의사결정은 대부분 각자의 전용 모델로 구현되어 왔습니다. 새로운 결정이 하나 생길 때마다 그 서비스만을 위한 로그를 모으고, 피처를 설계하고, 학습 파이프라인을 만들고, 서빙과 모니터링을 붙이는 일이 반복되었습니다. 문제는 모델의 수가 아니라, 같은 유저를 여러 번 배우는 구조였습니다. 추천 모델은 상품 반응을, 푸시 모델은 클릭을, 쿠폰 모델은 구매를 학습합니다. 모두 같은 유저를 대상으로 하지만, 각 모델이 쌓은 유저 이해는 서로 공유되지 않았습니다. 그래서 새 모델을 만들 때마다 유저를 처음부터 다시 배워야 했고, 유저에 대한 이해는 모델 수만큼 조각나 있었습니다. 개인화 푸시는 이런 구조를 가장 잘 보여주는 사례였습니다. 오랫동안 DeepFM 기반 CTR 예측 모델로 운영되며 유저와 기획전 피처를 입력으로 클릭 확률을 예측했습니다. 모델 자체의 성능이 나빴던 것은 아닙니다. 문제는 시간이 지나면서 구조 자체가 유지하기 어려운 형태로 변했다는 점이었습니다. 먼저 운영 지식이 점차 사라졌습니다. 모델의 운영 주체가 여러 차례 바뀌면서 어떤 피처를 왜 넣었는지, 장애가 발생했을 때 무엇을 점검해야 하는지 같은 맥락이 함께 사라졌습니다. 파이프라인은 매일 정상적으로 동작했지만 예측 품질의 변동을 설명할 수 있는 사람은 없었습니다. 시리즈 1편에서 이야기했던 “담당자가 바뀌면 마케팅 자산이 리셋된다”는 현상이 모델 레이어에서도 똑같이 일어나고 있었던 것입니다. 전용 학습 파이프라인을 유지하는 비용도 적지 않았습니다. 개인화 푸시만을 위한 데이터 생성, 피처 가공, 모델 학습 파이프라인을 매일 돌려야 했고, 사이클이 멈추면 그날의 발송 품질도 함께 흔들렸습니다. 세일즈 푸시와 라이브 푸시처럼 같은 앱푸시 채널 안에서도 서로 다른 모델과 파이프라인이 각각 운영되고 있었습니다. 이런 문제들은 모두 같은 원인에서 비롯되었습니다. 유저를 이해하는 책임을 각 모델이 따로 가지고 있었기 때문입니다. 모델이 하나 늘어날 때마다 유저를 이해하기 위한 학습과 운영도 함께 늘어났고, 그 비용 역시 계속 쌓였습니다. 그래서 방향을 바꿨습니다. 결정마다 새로운 모델을 만드는 대신
