기획자와 개발자를 위한 공개 기술 사례 검색
제품을 기획하고 구현할 때, 회사의 실제 기술 사례를 찾아보세요
여러 기업 기술 블로그의 글을 주제와 발행처별로 검색하고, 가입 없이 원문까지 이어 읽을 수 있습니다.
기획자 · 제품 조사
제품 문제와 가까운 사례를 검색하세요
추천, 검색, 결제처럼 제품에서 다루는 주제를 검색해 기업이 공개한 구현·운영 경험을 살펴볼 수 있습니다.
‘추천’ 검색 결과
- 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%처럼
- NAVER D2딸깍으로 안되는 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)으로 이동하였습니다. 앞으로도 많은 관심과 팔로우 부탁드리겠습니다.
개발자 · 구현 사례
기술 주제와 원문으로 구현 맥락을 확인하세요
프론트엔드, 백엔드, AI·ML 등 주제별로 최신 글을 보고, 각 회사가 공개한 원문에서 선택의 배경을 확인할 수 있습니다.