WebAuthn 스펙은 FIDO 스펙이 진화한 결과입니다. 애플, 구글, MS 등의 업체들이 지지하고 있으며 "패스키(Passkey)"라는 브랜드 네임으로 알려져 있습니다. WebAuthn 스펙을 정말 잘 설명하고 있는 글이 있어 일부를 번역하여 공유합니다. 그냥 "좋은 글이 있어요"라고 링크만 소개하고 말기에는 아깝다는 생각이 들었습니다. 글의 출처는 https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html 입니다.쓰레기입니다. 이 글을 읽는 분이라면 이미 이 생각에 동의하시겠지만, 왜 그런지 다시 한 번 살펴 봅시다.사람들은 보통, 패스워드 몇 개를 여기저기 돌려씁니다.웹사이트는 패스워드의 해시값을 저장하고, 인증할 때 이 해시값을 사용합니다.그런데 대부분의 패스워드는 엔트로피가 낮아서, 해시값만 유출돼도 무차별 대입 공격에 의해 노출됩니다.패스워드 데이터베이스가 유출되면, 패스워드가 유출된 그 웹사이트만 문제가 되는 게 아닙니다.패스워드를 여러 곳에서 돌려쓰는 행태 때문에, 다른 웹사이트들도 문제가 됩니다.다음으로, 패스워드는 사람이 기억하기 때문에, 비슷해 보이는 웹사이트로 사람을 속여서 패스워드를 입력하게 할 수 있습니다.이러한 "피싱(phishing)" 공격은 흔하고 효과적입니다.마지막으로, 패스워드는 소프트웨어 계층 여기저기서 유출될 수 있습니다.거대 기업 페이스북조차 수억 개의 패스워드를 실수로 로깅(logging)한 적이 있습니다.그리고 자바스크립트 인젝션 공격은 패스워드를 포함해서 웹사이트에 입력하는 모든 내용을 유출시킬 수 있습니다.공개키 서명 체계(public key signature scheme)를 사용해서 더 나은 인증(authentication) 시스템을 만들려는 노력에 관한 이야기입니다.공개키 서명은 ECDSA, RSA, ML-DSA 등으로 불립니다.이는 결과값이 얼마나 큰지, 결과값을 얻는 데 얼마나 오래 걸리는지, (아직 이론적인 이야기지만) 양자 컴퓨터 내성을 얼마나 갖고 있는지에 따른 분류입니다.공개키 서명 체계는 세 가지 연산을 제공합니다.• None 연산은 난수 비트를 받아서 공개키와 개인키라고 불리는 두 개의 바이트 문자열을 반환하는 작업입니다.• None 연산은 개인키와 임의의 바이트 문자열(메시지라고 함)을 받아서 "서명(signature)"이라고 불리는 또 다른 바이트 문자열을 생성하는 작업입니다.• None 연산은 공개키, 메시지, 서명 값을 받아서 해당 서명이 해당 개인키를 사용해서 생성됐는지 검증하는 작업입니다.공개키 서명 체계가 유용하려면 다음과 같은 속성이 있어야 합니다.• None 공개키로부터 개인키를 계산하는 것은 불가능해야 합니다.• None 개인키 없이는 서명을 계산할 수 없어야 합니다.공개키 서명을 사용한 인증(authentication) 방식의 간단히 예입니다.사용자는 username과 password를 만들어 웹사이트에 등록하지 않습니다.대신 사용자는 웹사이트에 등록하기 위해 usrename을 만든 다음 사용자의 컴퓨터에서 연산을 실행해서 key pair(공개키와 개인키)를 만듭니다.그리고 사용자의 컴퓨터에 개인키를 저장한 다음, 공개키와 username을 웹사이트에 제출합니다.로그인할 때 사용자는 username을 입력합니다. 그러면 사용자의 컴퓨터가 사용자의 개인키를 사용해서 "let me in" 메시지에 대해 서명 값을 계산합니다.그리고 username과 서명 값을 웹사이트로 전송합니다. 마지막으로 웹사이트는 사용자가 가입할 때 등록한 공개키를 사용해서 "let me in" 메시지와 제출된 서명을 검증합니다.서명이 유효하다면 사용자는 로그인됩니다.우리는 방금 데이터베이스 유출 문제를 해결했습니다.이제 웹사이트는 패스워드 해시 대신 공개키를 저장하면 됩니다. 공개키는 서명을 생성하는 데 사용할 수 없고, 오직 서명을 검증하는 데만 사용됩니다.따라서 패스워드와 달리, 공개키는 유출되더라도 이를 이용해서 해당 웹사이트나 다른 웹사이트에 로그인할 수 없습니다.피싱(phishing) 문제가 남았습니다. 사람들은 여전히 가짜 웹사이트에 서명 값을 제출할 수 있습니다.사용자의 서명 값을 알아낸 공격자는 이를 사용해서 해당 사용자인 것처럼 진짜 웹사이트에 로그인할 수 있습니다.피싱은 공격자가 사용자의 로그인 정보를 갈취하는 수법입니다. 피해자가 실수로 가짜 웹사이트에 로그인하면, 공격자는 그 정보를 실제 웹사이트에서 재사용합니다.앞에서 소개한 로그인 방식은 모든 웹사이트가 "let me in"이라는 동일한 메시지를 사용해서 서명을 만들었기 때문에 피싱에 취약했습니다.첫 번째로 할 일은 서명할 메시지를 바꾸는 것입니다. 서명할 메시지에 로그인할 웹사이트의 이름을 넣어 봅시다. 그리고 메시지를 JSON 형태로 바꿔 봅시다.사용자가 로그인할 때 사용자의 컴퓨터는 사용자의 개인키를 사용해서 서명 작업을 실행합니다.하지만 이제 "let me in" 메시지 대신 메시지를 사용합니다.웹사이트는 생성된 서명에 대해 검증 작업을 실행해야 합니다.검증 작업에는 메시지 입력이 필요하므로 사용자의 컴퓨터에서 서명 및 username과 함께 메시지를 전송하도록 합시다.이제 사용자가 악성 링크를 클릭해서 exampl3.com(악의적인 피싱 웹사이트)에 로그인을 시도할 때 어떤 일이 일어나는지 생각해 봅시다.사용자의 컴퓨터는 이라는 메시지에 서명합니다.피싱 사이트가 이 서명을 갈취해서 진짜 웹사이트에 전달하면 진짜 웹사이트는 사용자의 서명이 다름(다른 origin를 기초로 만들어진 것임)을 인식하고 로그인을 거부합니다.피싱 사이트는 메시지를 바꿀 수 없습니다. 메시지를 바꾸더라도 사용자의 개인키가 없기 때문에 유효한 서명을 새로 만들 수 없습니다.피싱 사이트 문제는 해결됐습니다.하지만, 진짜 웹사이트에서 서명 값이 유출됐을 경우 유출된 서명 값이 사용자 로그인에 사용될 수 있다는 문제는 여전히 남아 있습니다.패스워드 해시와 달리 서명 값은 저장할 필요가 없습니다. 하지만, 자바스크립트 인젝션 및 부주의한 로깅을 통해 서명 값이 유출될 위험은 있습니다.우리는 피싱 사이트 문제 해

토스에서 전생 프로필 이벤트를 참여해보신 적 있나요? 이 글에서 금전적 보상이 없이 바이럴에 성공한 전생 프로필 이벤트 탄생 과정을 공유드려요.카페나 음식점에서 ‘내 얼굴’로 결제하고 콘서트 입장도 간편하게 얼굴로 할 수 있다면 어떨까요? 얼굴로 입장과 결제를 할 수 있는 페이스페이·페이스패스가 곧 전국에서 사용 가능할 예정이에요.페이스페이·페이스패스 오픈을 준비하며, 서비스 쓰려면 거쳐야하는 긴 퍼널 문제를 해결하기 위해 최대한 많은 유저를 사전신청 단계에서 확보하려는 목표를 세우고, 이를 위한 이벤트를 기획하게 됐어요.*퍼널 : 사용자가 앱 내에서 특정 목표(예: 결제, 기능 이용 등)에 도달하기까지의 단계별 여정을 뜻해요. 여기서는 “개인정보 처리 및 약관동의 → 얼굴확인 → 본인인증 → 결제수단&서명 등록” 흐름이 퍼널에 해당해요.얼굴 인증을 활용한 페이스페이·페이스패스는 기존 토스 서비스에서 볼 수 없었던 새로운 사용성인 만큼 거부감을 줄일 수 있으면서, 유저가 얼굴 인증을 재미있게 느낄 수 있는 이벤트 기획이 필요했어요. 특히, 금전적 보상에 의존하지 않고 유저의 참여를 유도할 수 있는 새로운 바이럴 포인트를 찾아야 했죠.유저가 심리적 연결고리를 느낄 수 있는 결과물을 제공한다면, 유저의 흥미를 자극해 동의 전환율을 높이고 바이럴 효과도 증대될 것이라 판단했어요.예를 들어 MBTI나 심리테스트처럼, 유저가 자신의 결과에 흥미를 느끼면 이를 주변 사람과 공유하고 싶어하는 심리가 생기는 것 처럼요.1. 캐릭터와 스토리를 통해 유저가 몰입할 수 있는 환경을 조성우리는 무언가에 공감했을 때 그 안에서의 행동이나 결정을 자연스럽게 받아들여요. 그리고 공감과 몰입에 가장 효과적인 방법 중 하나는 스토리예요. 전생 이벤트에서는 신비로운 구슬이 "얼굴을 보고 전생을 찾는다"는 흥미로운 스토리로 유저를 몰입시켜 얼굴 확인 과정을 자연스러운 단계로 느낄 수 있게 했어요. 또한 전환에 허들인 약관 동의를 스토리의 일부로 제시해 거부감을 줄이려 했어요.그 결과, 스토리 요소로 인해 페이지 수가 4장 더 많았던 A버전이 더 짧은 B버전에 비해 약관 동의율이 9.1%p 더 높았어요.*허들(Hurdle) : 목표를 달성하거나 다음 단계로 나아가는 데 방해가 되는 장벽이나 문제를 의미해요. 예를 들어, 앱에서 회원가입 절차가 너무 복잡하면 이것이 허들로 작용해 전환율(=회원가입 통과율)이 낮아질 수 있어요.2. 다양한 전생 결과를 제공하여 유저의 호기심을 자극혹시 MBTI 테스트를 어떤 이유로 받았는지 기억나세요? 친구가 공유해준 결과를 보고 “내 MBTI는 뭘까?”하는 궁금증으로 시작하지 않았나요? 이처럼 전생 이벤트에서도 ‘만성피로 임금’부터 ‘대감집 머슴’까지 다양한 조선의 직업과 내용으로 결과에 대한 유저의 호기심을 유도했어요.또한, 이러한 다양한 직업 제공은 유저로 하여금 결과물이 자신에게 맞춰진 내용이라고 느끼게 하여 자기표현 욕구를 자극할 수 있어요. 이는 곧 유저 스스로 대화 소재로 결과를 주변 사람들에게 공유할 가능성이 높아지는 것을 의미

데이터 분석과 프로토타이핑의 기본 도구로 Jupyter 노트북이 널리 사랑받는 이유는 코드 실행과 결과 확인이 직관적이어서입니다.하지만 사용하다 보면 기분 좋은 경험 뒤에 이렇게 고민하게 됩니다.반복 실행의 귀찮음 : 코드 하나 수정 후 셀들을 순서 맞춰 다시 실행해야 하는 귀찮음.숨겨진 상태(hidden state): 불필요한 변수나 실행 순서 때문에 내용이 어긋나는 경우가 많음.버전 관리의 고민: .ipynb는 JSON이라 변경 내역 추적이 어려워 협업이 힘듬.이런 이유로 GitHub에 공개된 Jupyter 노트북 중 36%는 실행 순서가 엉망[1]이며, 최종 실행 결과가 재현될 확률은 고작 4%에 불과[2]하다고 합니다.그래서 오늘은 이런 골칫거리들을 해소해 주는 차세대 Python 노트북, marimo를 소개합니다.1. 각 셀의 의존성을 파악해, 변경된 셀과 그 셀에 영향을 받는 셀이 자동으로 반영됨: 위 Cell이 변경 되었을때, 연계된 Cell을 Run시키지 않아도 자동 반영.예시) 2번 Cell만 변경 시, 나머지 Cell들은 Run 하지 않아도 자동으로 변경됨.2. “숨겨진 상태”를 완전히 없애 실행 흐름이 일관되고 예측 가능하게 유지예시) 2번 Cell이 삭제되었을때 의존성을 가진 Cell을 Run하지 않아도, 즉시 Error 발생하여 Issue 파악 가능그외에도.py 파일 기반으로 Git 친화성 강화이며, Jupyter가 JSON형태로 저장되는 것과 다르게 Python 코드로 저장돼 읽기 쉬우며, 웹 앱 형태로 손쉽게 배포 가능한 오픈 소스 툴입니다.물론, LLM의 도움을 받아 Code 작성에 도움을 받을 수도 있습니다.해당 위치에서 더 상세한 사용 예시를 확인 할 수 있습니다.1. 설치 ( Terminal 창에 pip를 이용해 간단히 설치 가능합니다.)Web Base로 시작되며, URL 통해 접속도 가능합니다.Packages ( 설치된 Pakage List, 버튼으로 Upgrade, Remove 가능 )썸네일의 Marimo는 생성형AI를 통해 만들어진 Image이며 marimo와 반려식물 marimo는 관계가 없습니다.

안녕하세요! 동네생활팀 프론트엔드 엔지니어 인턴 링커(Linker)예요. 저희 팀은 동네 정보와 이야기를 자유롭게 나누는 커뮤니티, 동네생활을 만들고 있어요.동네생활은 모바일 기기 성능이 좋지 않거나 웹뷰 로딩이 느린 환경에서도 사용자에게 원활한 경험을 제공하기 위해 Streaming SSR*을 도입했어요. 이런 구조에서 디버깅을 수월하게 하기 위해 서버 로깅을 적극적으로 활용해 왔죠. 그런데 서비스 규모가 커지면서 서버 내부에서 출력되는 로깅이 많아지자 몇 가지 문제를 직면하게 됐어요.이 글에서는 웹앱 서버 로깅의 구조를 개편해, 가시성을 높이고 모니터링을 용이하게 한 과정을 공유하려고 해요.*동네생활팀에서 사용하고 있는 Streaming SSR이 궁금하시다면 입사 1개월차 프론트엔드 개발자의 자체 기술 온보딩 Streaming SSR편 을 확인해 보세요.기존 로깅 시스템에서 발생한 문제먼저 동네생활 팀이 어떤 문제들을 마주했는지 구체적으로 설명해 드릴게요.로그의 흐름을 따라가는 게 아니라 상황으로 예측해야 했어요.오류를 추적할 때는 로그와 모니터링 툴을 활용해 오류의 범위를 점차 좁혀 나가야 해요. 해당 유저의 오류 발생 시간대, 기기 종류, 상태값 같은 메타데이터 정보를 하나하나 대조하거나, 과거에 발생했던 유사한 에러 사례를 떠올리며 이 오류일 것이다 라고 추측해야 하는 거죠. 오류를 추적하는 데 많은 시간과 리소스를 들여야 했고, 오류의 원인을 정확히 파악했는지 확신하기도 어려웠어요.예를 들어 한 사용자가 동네생활에 접근할 수 없다고 CS 제보를 한 적이 있어요. 해당 원인을 분석하려면 유저의 접근 기록을 순차적으로 확인해야 했지만, 현재 시스템에서는 불가능했어요. 엔지니어가 모니터링 툴과 웹앱 서버 로그 등을 전부 확인하며 오류와 관련된 단서를 일일히 찾고 이를 연결해야 했어요.2. 잘못된 로그를 남겼을때 해당 로그가 어디에서 로깅했는지 찾기 어려웠어요.한 번은 불필요한 오류 로그가 단시간 내 다량으로 발생해 오류 스파이크 알림을 받았어요. 문제는 이 불필요한 로그가 어디서 호출됐는지 정확히 알지 못한다는 점이었어요.공교롭게도 그날은 팀원들과 함께 봄나들이 소풍을 나간 날이었는데요. 돗자리에 앉아 여유를 즐기던 중, 모든 팀원이 노트북을 꺼낼 수밖에 없었어요. 모두가 힘을 힙을 합쳐 4시간 동안 소거법으로 로그를 하나하나 지운 끝에 오류 스파이크가 호출된 위치를 발견할 수 있었어요.두 문제들의 근본 원인은 일관성 없는 로깅 정책이에요. 기존에는 엔지니어 개인이 로거를 자유롭게 사용하다 보니 로그 형식이 통일되지 않았어요. 문제가 발생했을 때 작성자가 아니면 원인을 파악하기 어려워 비효율적이었죠. 이를 개선하기 위해 모두가 이해하고 활용할 수 있는 로깅 정책을 수립했어요. 어떤 문제가 발생하든 팀원 누구나 쉽게 모니터링할 수 있도록 말이죠.로그 포맷 변경팀에서는 네 가지 구성 요소를 활용해 로그 포맷을 통일했어요.1. 로그 level정보가 많은 로그 안에서 모든 메시지가 같은 수준으로 보이면, 중요한 내용도 쉽게 묻힐 수 있어요. 그래서 level을 사용해 로그메시지의 심각도나 중요도를 구분했어요. 또 필요한 정보를 직관적으로 파악할 수 있도록 각 level별로 색상을 적용했고요. 색상은 레벨에 따른 대표 색상을 기본으로 하되, 필요에 따라 팀 내에서 협의해 세분화했어요.터미널에서 색상은 ANSI escape 코드를 사용해 추가할 수 있어요. ANSI는 텍스트의 색상이나 스타일을 제어할 수 있는 터미널 제어 시퀀스예요. 예를 들어 로그 앞에 \\033[31m처럼 색상 코드 문자열을 삽입하면 터미널에서 색상이 표시돼요.2. 로그 메시지각 level의 색상을 사용해 단순 문자열을 남겨요. 별도의 포맷이 없으므로 간결하거나 핵심적인 내용을 명확히 표현하는 게 중요해요.3. 로그 트레이스로그 메시지에 코드 발생 위치를 정확하게 알려주는 트레이스를 추가해요. JS의 Error객체의 stack trace를 활용해 구현할 수 있어요. 로거를 사용하는 시점에 stack trace를 가져오면 호출된 위치를 알 수 있어요. JavaScript의 스택 구조에 stack[N]는 현재 함수 기준으로 N단계 위의 호출 위치를 가리키므로, 로거가 호출된 실제 위치에 맞춰서 조절할 수 있어요.출력된 로그를 바탕으로 로깅 위치를 즉시 확인할 수 있기 때문에 엔지니어는 오류를 빠르게 추적하고 관리할 수 있어요. 또한 모든 팀원이 로직에 대한 맥락을 더 쉽게 파악할 수 있어, 로그를 이해하는 데 좋은 기반이 되기도 하죠.4. 메타데이터저희 팀은 로그 집계 시스템인 Loki를 사용해 로그를 저장하고 쿼리해요. Loki에서 쿼리로 로그를 필터링하고 그룹화할 수 있도록, 다양한 값을 JSON 형식의 메타데이터로 함께 추가해요. 팀에서는 모든 로그에 요청 식별자, 사용자 식별자 같은 공통 메타데이터를 포함시켜 특정 기준에 따라 로그를 쉽게 그룹화할 수 있도록 구성했어요. 공통 메타데이터뿐만 아니라 검색에 필요한 개별적인 메타데이터 값도 함께 추가해서, 나중에 더 정밀하게 로그를 조회할 수 있도록 만들었어요.로깅 개선의 이점이렇게 로그를 구조화했을 때 다음과 같은 일들이 가능해져요.1. 유저 식별자를 통한 검색으로 유저 자체의 로그를 확인할 수 있어요[Before] 로깅 포맷을 통일하기 전 (*실제 로그가 아니라 가상의 데이터로 제작된 예시 이미지)기존에는 위 이미지처럼 모든 로그 메시지들이 각자 다른 포멧을 가지고 있어요. 특정 유저의 기록을 보고 싶어도 일부 로그는 확인이 어렵거나, 형식이 일관되지 않아 전체 흐름을 정확히 파악하기 힘들었죠. 이로 인해 로그가 존재하더라도 확인 과정에서 놓치는 경우가 발생하곤 했어요.[After] 로깅 포맷을 통일하고 난 후 (*실제 로그가 아니라 가상의 데이터로 제작된 예시 이미지)이제는 특정 유저가 요청한 시간순으로 로그를 검색해 확인할 수 있고, 어디에서 문제가 발생했는지 곧바로 알 수 있어요. 위 이미지처럼 문제의 종류와 정보를 직관적으로 파악할 수 있고, 확인 과정에서 로그를 놓치는 경우도 없어졌어요.2. 요청 식별자를 통한 검색으로 요청 로그를 확인할 수

안녕하세요, SK플래닛에서 프론트엔드 개발을 담당하고 있는 김찬민이라고 합니다.작년 이맘때까지만 해도 프론트엔드 개발자가 AI를 사용하는 용도는 새로운 기술을 습득하거나 코드를 리팩터링하는 등 프롬프트를 기반으로 하는 코드 생성 작업이 대부분이었던 것 같은데요, MCP와 코딩 에이전트의 등장 후로는 훨씬 더 다양한 방식으로 AI를 활용할 수 있게 된 것 같습니다. AI의 활용 방법들 중 하나로, 이번 글에서는 Framelink Figma MCP 를 사용해 프론트엔드 개발자의 숙제 중 하나인 UI 컴포넌트를 효율적으로 개발하는 방법을 소개해보려 합니다.(참고) 글을 쓰는 시점에 Figma 공식 MCP 의 베타 버전이 공개되어 있기는 하나, 아직까지는 Framelink Figma MCP가 더 안정적으로 동작한다고 느껴져 Framelink Figma MCP를 다루었습니다.Framelink Figma MCP 는 Cursor, GitHub Copilot 등의 코딩 에이전트와 Figma를 이어주는 MCP로, 피그마 노드(≈ UI 요소)의 주소를 프롬프트에 추가하면 UI를 인식해 코드로 전환할 수 있습니다.Framelink Figma MCP를 사용하기 위해서는 먼저 피그마 액세스 토큰이 필요합니다.• 토큰 권한은 모두 Read-only로 부여했습니다.다음으로 Cursor 에디터에 MCP를 추가하기 위해 Cursor 설정에 진입합니다.MCP 설정에 진입했다면 "New MCP Server" 버튼을 눌러 MCP 서버를 추가할 수 있습니다.MCP 서버를 추가한 뒤 MCP Tools에 Framelink Figma MCP에 초록불이 들어와 있다면 성공입니다. 이제 프롬프트에 Figma 노드 정보를 포함시키면 MCP 서버가 Figma API를 통해 해당 노드의 정보를 불러올 수 있고, 코딩 에이전트는 이를 코드로 변환할 수 있게 됩니다.MCP 설정이 끝났다면 테스트를 위해 구글에서 유지보수하는 UI 컴포넌트 라이브러리인 Material UI 의 피그마 시안을 코드로 옮겨 보겠습니다.Figma에서 개발하고자 하는 UI 컴포넌트를 선택하고 해당 요소의 URL을 복사합니다(Pages가 아닌 Layers 메뉴에서 노드를 복사해야 하는 점만 유의해 주세요).Figma Dev Mode를 사용한다면 조금이나마 더 쉽게 요소를 선택할 수 있습니다.2-b. 코딩 에이전트에 프롬프트 작성하기이제 Cursor 에디터에 다음과 같이 프롬프트를 작성하면 LLM이 피그마 파일을 읽을 수 있게 됩니다.프롬프팅의 결과로 Figma Material UI 중 Alert UI에 대응하는 컴포넌트와 스토리북 문서가 생성되었습니다.개인적으로는 LLM에게 수동적으로 코드 개선을 요청하는 단계를 넘어, 피그마 파일을 읽고 마크업을 생성해주는 모습에 큰 인상을 받았습니다. 그래서 React 기반의 OK캐쉬백 서비스에 사용되는 일부 컴포넌트를 Vue로 재작업하는 과정에 MCP를 실제로 사용해 보았습니다.• MCP 기반으로 생성된 컴포넌트를 튜닝해 완성한 모습MCP가 성공적으로 컴포넌트를 생성해 주었고, 스위치가 더 자연스럽게 움직일 수 있도록 motion 라이브러리를 사용해 애니메이션을 다듬으니 만족스러운 결과물을 얻을 수 있었습니다.제가 직접 처음부터 구현해야 했다면 4시간 정도 걸렸을 것 같은 작업이었는데, 수 분 내에 작업을 마치고 작은 디테일들을 보완하는 데에 사용할 수 있는 시간이 늘었던 만족스러운 경험이었습니다.화면 전체 UI를 코드로 옮기려 시도하면 유지보수가 어려운 코드가 생성되는 등 아직은 AI가 완벽하지 않은 모습을 보이기도 하지만, 단위 컴포넌트를 구현하고 스토리북 문서를 관리하는 목적만으로도 프론트엔드 개발자의 부하를 크게 줄여줄 수 있게 되었습니다.수동적으로 코드 생성, 개선을 요청하는 용도를 넘어 프론트엔드 개발에서 중요한 과정인 디자인을 코드로 옮기는 데에 들이는 시간을 크게 단축할 수 있게 되었다는 점에는 만족하지만, 앞으로 프론트엔드 개발자들이 일하는 모습은 어떻게 변화해야 할지, 어떤 식으로 경쟁력을 갖춰야 할지에 대해서는 어려운 고민거리를 던져준 것 같습니다.UI 구현에 어려움을 겪을 수 있는 타 직군이나 주니어 개발자들에게 이 글이 도움이 되셨길 바라며, 더 좋은 글로 다시 찾아뵙겠습니다.(참고) 작가의 최근 글은 여기서도 읽으실 수 있습니다.• LoadingSpinner를 도입하여 웹앱 사용자 경험을 개선하다(웹앱 사용자 경험을 개선하는 기술 한 스푼)• [Vue] motion 라이브러리로 더 나은 UX 제공하기

안녕하세요, 카카오의 AI 모델 개발을 담당하는 카나나 LLM 조직에서 Pre-Training을 연구하는 Lana, Post-Training을 연구하는 Khel, Kevin 입니다.최근 대규모 언어 모델 (LLM) 크기와 성능이 경쟁이 치열해지면서, 모델 파라미터 수가 기하급수적으로 증가함에 따라 이제는 연산 비용 절약, 메모리 사용량 최적화, 효율적인 학습을 어떻게 할 것인지가 업계의 큰 화두가 되었습니다. 이러한 문제를 해결할 수 있는 강력한 방법 중 하나로 주목받고 있는 기술이 바로 “Mixture of Experts (이하 MoE)” 입니다. 초기 MoE 관련 연구 중 하나인 Switch Transformer [1] 논문에 따르면, Sparse 구조인 MoE 모델은 토큰 하나를 처리하는 데 필요한 연산량 (FLOPS per token)이 동일한 Dense 모델에 비해 원하는 성능까지 7.5배 빠른 학습 속도로 도달할 수 있으며, expert 수가 많아질수록 학습 속도도 더욱 빨라졌습니다. 이는 동일한 학습 시간과 컴퓨팅 자원이 주어졌을 때, MoE 모델 구조를 활용하면 더욱 빠른 속도로 목표 성능에 도달이 가능함을 의미합니다. 해당 논문에서는 더 나아가 토큰당 필요한 연산량이 3배 이상인 Dense 모델과도 비교해보았을 때, MoE 모델에서 여전히 좀더 효율적인 학습이 가능했음을 시사하고 있습니다.저희 조직에서도 이러한 효율적인 MoE 언어 모델을 만들기 위해 내부적으로 다양한 연구를 진행해왔습니다. 그 결과로 단 3B 수준의 활성 파라미터만으로 8B Dense 모델에 준하는 성능을 달성한 MoE 모델 Kanana-1.5-15.7B-A3B를 소개해드리고자 합니다. 해당 모델은 Kakao Hugging Face에 오픈소스로 공개되어 있으니, 많은 관심 부탁드립니다.1) Mixture of Experts: 필요한 부분만 효율적으로 사용하자Mixture of Experts (MoE) 모델이 왜 필요한가?일반적인 대규모 언어 모델 (LLM), 소위 “Dense 모델”은 입력된 데이터를 처리하기 위해 모든 파라미터가 연산에 참여하여 출력을 만들게 됩니다. 저희 조직에서 앞서 오픈소스로 공개했던 Kanana-1.5-8B, Kanana-1.5-2.1B 같은 모델들이 여기에 해당합니다. Dense 구조를 갖는 경우 언어 모델의 파라미터 규모가 클수록 더 많은 지식을 저장할 수 있어 성능이 향상되는 장점이 있지만, 한편으로는 파라미터 규모에 비례하여 연산량이 같이 증가한다는 명백한 한계가 존재합니다. 따라서 모델이 커질 경우 추론 시에 사용되는 장비의 부담과 비용이 늘어나기 때문에, 모델 성능을 높이기 위해서 무한정 파라미터 수를 늘리는 것은 현실적으로 거의 불가능합니다.이러한 Dense 구조의 큰 모델이 갖는 한계를 보완하면서도 모델의 수용 가능한 지식의 총량을 확장하기 위해 MoE [2] 구조가 활용될 수 있습니다. MoE 구조의 언어 모델은 전체 파라미터 중 주어진 입력에 가장 적합한 일부 전문가 (expert) 파라미터들을 선별적으로 활성화하여 추론에 필요한 연산을 진행합니다. 이러한 특징을 가지는 MoE 모델은 크게 두 가지 목적으로 활용될 수 있습니다.• 초거대 모델 학습 : Dense 구조로는 현실적으로 초거대 규모의 모델을 만드는 것에 무리가 있지만, MoE 구조를 채택한다면 가능합니다. 대표적인 예시로, DeepSeek-V3 [3] (671B 파라미터 중 37B 활성화), Qwen3-235B-A22B [4] (235B 파라미터 중 22B 활성화), Llama 4 Maverick [5] (400B 파라미터 중 17B 활성화) 같은 모델들은 MoE 구조 덕분에 엄청난 수의 전체 파라미터로 지식의 총량은 확장하면서도 추론에 사용되는 연산에는 일부만 사용하면서 부담을 줄여 강력한 성능을 갖는 거대 모델을 구현할 수 있었습니다.• 추론 비용 효율화 : 모델의 절대적인 사이즈를 확장하는 용도 외에도, 성능을 유지하되 추론 비용 효율화를 위해서도 MoE 구조가 활용될 수 있습니다. 모델을 실제로 사용할 때 모든 파라미터가 연산에 사용되는 Dense 구조의 모델과 달리, MoE 모델은 필요한 일부 파라미터만 선별적으로 연산에 참여하게 되므로 모델 커널 최적화만 충분히 되어있다면 추론 비용을 크게 절약할 수 있습니다. 약 10B 규모의 성능을 보이는 알리바바 그룹의 Qwen3-30B-A3B [4] 모델이 이런 목적에 해당된다고 볼 수 있습니다.이번에 소개해드릴 Kanana-1.5-15.7B-A3B 모델은 위 내용 중 두 번째 목적인 추론 비용 효율화에 중점을 두었습니다. 앞서 공개되었던 Kanana-1.5-8B 모델에 버금가는 성능을 보이면서도, 추론 연산에는 2~3배 적은 활성 파라미터만을 사용하여 높은 효율을 달성하는 것이 이번 모델의 목표였습니다.MoE 모델과 Dense 모델의 가장 핵심적인 구조적 차이는 단연 Dense 모델의 MLP (Multi-Layer Perceptron) 레이어가 MoE (Mixture of Experts) 레이어로 대체되었다는 것입니다. MoE 레이어에서 입력을 받게 되면, 가장 먼저 router에서 어떤 expert들이 적절할지 expert들의 점수를 매긴 뒤, 상위 몇 개의 expert들로만 입력 값을 흘려보내 처리하도록 해줍니다. 이후 활성화된 expert들로부터의 연산 출력값을 router가 매긴 점수에 따라 가중치를 두어 합하고 (weighted sum), 이후 연산 과정에 사용합니다. 이러한 MoE 아키텍처는 전체 전문가 (expert) 수, 그리고 router로부터 선택되어 활성화되는 expert 수의 규모에 따라 크게 두 가지로 나뉩니다.• Coarse-grained MoE : Mixtral [6] 시리즈와 같은 비교적 초기의 MoE 모델들은 10개 미만의 소수의 expert를 갖는 Coarse-grained 구조를 가지고 있었습니다. 이 경우 각 expert는 단독으로 Dense 모델의 MLP 레이어 역할을 할 수 있을 정도의 크기를 가지며, 추론 시에는 약 2개 정도로 적은 수의 expert만을 활성화하게 됩니다.• Fine-g

카카오의 멀티모달 언어모델 ‘Kanana-v’의 개발과 오픈소스 공개 소식을 공유합니다안녕하세요, 카카오의 AI 모델 개발을 담당하는 카나나(Kanana) 조직의 Samuel(강성훈), Sonny(손동희)입니다. 저희 조직에서는 이미지를 포함한 다양한 모달리티 데이터를 처리할 수 있는 멀티모달 언어모델을 개발하고 있습니다.작년 12월, 저희는 첫 번째 멀티모달 언어모델인 ‘Kanana-v’를 소개하며, 한국형 멀티모달 AI 모델의 가능성을 선보인 바 있습니다. 그 후속 모델로, 경량화된 구조와 보다 향상된 멀티모달 지시 이행(Multimodal Instruction Following) 능력을 통해 실용성과 성능을 모두 갖춘 ‘Kanana-1.5-v-3b-instruct(이하 Kanana-v-3b)’를 새롭게 개발하였습니다. 특히 이번에는 그간의 모델 개발과정과 함께, 허깅페이스를 통해 모델을 오픈소스로 공개합니다. 상업적으로 활용 가능한 Kanana License를 적용하여 누구나 사용할 수 있으니 많은 관심 부탁드립니다!Kanana-v-3b는 카카오의 자체 언어모델 ‘Kanana-1.5-3b-instruct’를 기반으로 이미지와 텍스트를 함께 입력받아 자연어로 응답을 생성할 수 있도록 확장한 경량 멀티모달 언어모델입니다. [그림 1]에서 보이듯, ViT 기반의 Vision Encoder와 자체개발한 C-Abstractor [1] 구조를 사용하여 이미지 정보를 LLM이 이해할 수 있는 형태로 변환하여 입력하고, LLM은 입력된 정보와 텍스트 지시를 이해하여, 텍스트 형태의 답변을 생성하는 구조로 구성되어 있습니다.그림 1. ‘Kanana-v-3b’의 구조. Kanana-v-3b는 카카오에서 개발된 ‘Kanana-1.5-3b-instruct’에 이미지 모달리티 이해 능력을 확장한 멀티모달 언어모델입니다.약 36억 개(3.6B)의 파라미터를 가진 Kanana-v-3b는 비슷한 규모(<4B)의 글로벌 모델과 비교하여 다양한 한국어 벤치마크에서 뛰어난 성능을 기록했습니다. 영어 벤치마크에서도 경쟁력 있는 결과를 보였으며, 특히 소형 모델임에도 멀티모달 지시 이행 능력(Multimodal Instruction Following)에서도 우수한 성능 [그림 2] 을 보입니다.그림 2. Kanana-v-3b와 비슷한 파라미터(<4B)를 지닌 경쟁 모델들의 영어, 한국어, 멀티모달 지시 이행 성능의 비교. 모델 이름 오른쪽 괄호 내에 표기된 숫자는 각 모델의 파라미터 숫자입니다.이 글에서는 Kanana-v-3b의 성능뿐 아니라, 소형 멀티모달 모델 개발 과정에서 저희가 집중했던 문제와 해결 방법을 어떻게 학습 과정에 반영했는지 자세히 소개하겠습니다.Kanana-v-3b 모델은 특히 사용자의 지시(Instruction)를 정확히 이해하고 이를 충실히 따르는 능력인 지시 이행 능력(Instruction Following)의 성능 향상에 중점을 두었습니다. 지난 Kanana-v 개발기에서는 주로 LLM이 이미지를 보고 이해하는 능력 학습에 집중했다면, 이번 글에서는 사용자의 의도를 정확히 파악하고, 보다 정확하고 자연스러운 답변을 생성하는 사용감 좋은 모델을 학습하는 데에 초점을 맞추었습니다.Kanana-v-3b의 전반적인 성능은 멀티모달 지시 이행, 한국어 및 한국 문화 특화 벤치마크, 영어 벤치마크의 세 가지 주요 측면에서 측정되었습니다. 각 평가는 실제 환경에서 사용자가 AI 모델과 자연스럽게 상호작용할 수 있는지와 모델의 산업적 활용을 비롯하여 다양한 응용 분야로의 적용 가능성을 판단하는 데 중요한 기준이 됩니다.첫 번째로, 텍스트와 이미지에 기반한 복잡한 지시를 얼마나 잘 이해하고, 지시를 충족한 답변을 생성하는지 평가하는 멀티모달 지시 이행 능력(Multimodal Instruction Following)의 성능을 살펴보고, 이어서 Kanana-v-3b 모델의 가장 큰 장점인 한국어, 및 한국문화 특화 성능을 다양한 벤치마크를 통해 분석합니다. 마지막으로는 타 글로벌 모델들과의 경쟁력을 평가하기 위해 널리 사용되는 영어 벤치마크를 통해 모델의 성능을 비교하겠습니다.말귀를 잘 알아듣는 멀티모달 언어모델멀티모달 지시 이행 능력(Multimodal Instruction Following)이란, 텍스트뿐만 아니라 이미지 등의 다양한 모달리티 입력을 바탕으로, 자연어로 주어진 지시(Instruction)를 이해하고 그에 맞는 응답을 생성하는 능력을 의미합니다. 예를 들어, 사용자가 “이미지를 요약해서 개조식으로 정리해 줘”라고 입력했을 때, 모델은 입력 이미지와 텍스트를 정확히 이해하고, 지시된 포맷에 맞춰 응답해야 합니다.이제 사용자는 AI모델에게 명확한 명령어만 입력하는 것이 아니라, [표 1]의 예시와 같이 “욕실이나 방이라는 단어를 사용하지 않고 이미지를 한 문장으로 설명해 줘”처럼 더 복잡하고 직관적인 요청을 자연어로 입력하고 있습니다. 이러한 멀티모달 지시 이행 능력(Multimodal Instruction Following)은 사용자와 AI가 더욱 자연스럽게 상호작용하도록 만드는 핵심 기술입니다. 특히 실제 서비스 환경에서는, 이 기술이 “이 모델, 진짜 똑똑하네!”라는 인상을 사용자에게 줄 수 있는 중요한 차별화 포인트가 됩니다.최근의 연구들은 멀티모달 지시 이행 능력(Multimodal Instruction Following)을 평가하기 위해, 영어를 대상으로 한 벤치마크들(MIA-Bench[2], MM-IFEval[3], MM-OmniAlign[4] 등)을 제안하고 있습니다. 하지만 한국어의 경우 이러한 벤치마크가 존재하지 않기에 MIA-Bench의 이미지와 질문을 사용하여 MIA-Bench-Ko라는 벤치마크 [표 1]를 자체적으로 제작하였습니다.MIA-Bench를 단순히 한국어로 번역하는 것에서 한 걸음 더 나아가, 영어와 한국어 사이의 문법적, 문화적 차이점으로 적절하지 않은 질문들을 [표 2]와 같이 수정하여, 한국어 문법과 문화를 반영할 수 있도록 구성하였습니다.[표 2] MIA-Bench-Ko의 지시 예시. MIA-Bench의 지시(Instruction)를 한국

오늘은 최근 화제가 되고 있는 개발자 소프트스킬 | 퍼스널브랜딩 | 개발문화 도서, "코드 너머, 회사보다 오래 남을 개발자" 의 요약 및 독후감을 작성하여 보았어요~(요즘 학교에서는 "독후감"이라는 표현보다는 자유롭게 책을 읽고 기록하며 생활 속에서 실천을 강조하는 "독서생활본(讀書生活本)"의 작성을 권장한다고 하는데요,웬지 성찰/학습/개선이라는 패턴의 개발자 회고(Retrospect) 와도 유사한 점이 많은 것 같습니다.나의 업무와 회사의 문화를 회고하는 마음으로 퀵하게 작성해 보았사오니 참고 부탁드립니다!)• None 도서 링크는 여기에! https://product.kyobobook.co.kr/detail/S000216932006 (교보문고)돌아오는 7월 25일 (금) 19:00 ~ 22:00, 서울 서대문구 연희로2길 62 한빛미디어 B동 1층 리더스홀에서 100명의 청중을 모시고"기술보다 강한 '나'를 만드는 실전 커리어 전략" 이라는 제목으로 본 책의 북토크 를 진행하오니 관심있는 분들께서는 참고하시기 바랍니다(본 글을 포스팅하는 시점에는 이미 마감되었다고 합니다).기타 자세한 사항은 여기를 참조하세요 => https://techtopic.skplanet.com/techseminar2025-2h/1. 왜 이 책이 화제일까요?본 도서는 소프트스킬, 개발문화, 퍼스널 브랜딩 이라는 세 영역에서 주 독자인 개발자와 예비 개발자들에게 현업 사례와 경험과 함께 이들의 중요성을 전해 주는 실무서입니다.문득 이 세 영역을 삼각형 으로 도식화해보고 싶은 생각이 들었는데요(책에는 그림이 없습니다 ^ ^),각 꼭짓점인 소프트 스킬, 개발 문화, 퍼스널 브랜딩은 상호 보완하면서 개발자의 성공을 이끌어나가게 됩니다.• None 소프트 스킬: 조직 안에서 협업을 가능하게 하는 또 하나의 "역량"• None 개발 문화: 그런 소프트 스킬이 존중받고 발휘되며 업무에 몰입, 성장하도록 돕는 환경• None 퍼스널 브랜딩: 자신의 전문성과 가치를 외부로 확장하여 커리어 기회를 확장하는 전략.• None 삼각형은 (양방향) 피드백 루프를 형성하며, 삼각형의 중심은 "지속 가능한 개발자의 성장" 을 추구참고로 도서 정보는 다음과 같습니다.• None 도서명: '코드 너머, 회사보다 오래 남을 개발자'• None 핵심 메시지: 당신의 코드보다 '당신'을 기억하게 하라• None 주요 주제: 소프트 스킬, 개발문화, 퍼스널 브랜딩으로 확보되는 결정적 경쟁력• None 집필진: 국내 주요 IT기업의 만렙 DevRel 매니저님들 ^ ^본 챕터는 크게 "대화의 기술 (휴먼은 코드로(만) 소통하지 않는다)"과 "회의의 기술 (회의에서 눈도장 찍고 스카웃되기?)"의 두 파트로 크게 나눌 수 있는데요,인간의 기본 활동인 듣기와 말하기가 회사라는 필드에서는 커뮤니케이션과 회의에서 나타나는데요, 나와 회사에서 바로 도입할 수 있는 실제적인 "스킬" 중심으로 정리되어 있는 것들이 인상적이었습니다.자세한 내용은 책을 참조 부탁드리며, 저의 눈에 들어왔던 내용 일부만 공유드립니다.• None 상대방을 진심으로 인정하는 것이 경청의 시작• None 대화를 이어나갈 수 있는 질문 '스킬' 익히기• None 왜(Why) 보다는 '무슨 이유로', '어떤' 을 선호하기• None 말하기와 듣기의 비율은 3:7 로 유지• None 상어 같은 대화자 vs. 고래 같은 대화자• None 조언보다는 인정과 공감하기• None 회의의 목적과 기대 결과를 미리 그리고 명확하게 전달하기(2) 우테코 리사 코치가 말해주는 소프트 스킬의 중요성참고로 우테코는 "우아한테크코스", 즉 우아한형제들 회사 내 외부개발자 양성을 위한 교육조직으로 수 년간 좋은 개발자들을 양성하고 있습니다- 박재성(포비) 님을 비롯하여 다양한 직무별 강사 및 소프트스킬 코치님들이 도움을 주고 계세요.이 챕터에서는 정확한 자기 인식의 힘이 나와 조직 성장의 시작점이라고 정의를 내리고 있는데요,(1) 개인 관점에서는 자기 인식에서 시작하여 자기 효능감과 회복 탄력성을 길러 나가고,(2) 조직과 리더 관점에서는 심리적 안전감을 잘 제공해 줄 수 있으면 행복한 개발자 문화가 이루어지겠구나 하는 생각이 들었습니다(제 의견은 책의 내용과는 살짝 다르지만 개인만으로는 힘들 수도 있다고 생각하거든요).(3) 유연성과 자기 결정력 은 그 정반합(?)의 결과일 수 있겠다는 생각이 들었습니다.개인적으로 좋아하는 내용들, 고민하는 내용들이 나와서 매우 반가왔고 동시에 이러한 요소들이 실제로 잘 Working하는지가 궁금하기도 했던 터라 흥미있게 읽었습니다.주요 내용은 다음과 같습니다.덧. 그러다가 어제 우형 피플실에 근무하시는 분께서 쓰신 "일터의 설계자들" 이라는 책을 병행해서 읽게 되었는데 내용들이 상호보완되어 좀더 이해가 잘 되었고"정말 회사에서 이런 부분까지 다뤄준단 말이야?" 하는 생각 역시 함께 들었습니다(조직 레벨에서 이 부분을 다뤄 준다면 개발자는 몰입할 수 있고 따라서 행복할 수 있겠네요.다만 모든 회사가 규모나 상황상 이렇게 하기는 쉽지 않으니 어떤 펑션으로 도움을 받는 것도 현실적으로 필요하겠다는 생각이 듭니다).참고로 이 책에서도 "관리보다 관심을", "심리적 안정감을 키우는 일터의 조건" 등의 컨센서스가 보였습니다.(3) 공유와 소통으로 키워가는 성장의 선순환이 챕터를 한줄 요약하면 "커뮤니티 및 기술 블로그와 함께 성장하기(feat. SK데보션 빌드업 스토리)" 로 적을 수 있을 것 같아요.소속 특징(?) 때문에 데보션 커뮤니티와 담당자를 종종 뵙고 있지만 감탄하는 것 중 몇 가지는 다음과 같은데요,• None (1) SKT에서 시작하였지만 이를 넘어 하이닉스, AX, 플래닛 등 SK ICT의 엔지니어를 아우르는 개발자 커뮤니티를 만들어 냈다는 것(그래서 도메인이 sk.com입니다).• None (2) 오프라인 커뮤니티와 온라인 테크 블로그를 융합하여 운영하고 있다는 것• None (3) 올해는 좀 성격이 바뀌었지만 수 년간 데보션을 채용 브랜드로까지 이끌어 냈다는 점입니다.아울러 올해는 역량개발 플랫폼으로의 새로운 도전 중으로, 다양한 스터디 모임을 진행하고

안녕하세요. LINE VOOM 서비스의 추천 시스템을 개발하는 ML 엔지니어 이창현, 백진우입니다. 저희는 LINE VOOM의 실시간 추천 시스템을 위한 대규모 벡터 데이터베이스 도입 프로젝트를 진행했습니다. 이번 글에서는 그 도입 과정을 자세히 소개하고자 합니다.먼저 저희가 개발하고 있는 서비스, LINE VOOM을 소개하겠습니다. LINE VOOM은 LINE 앱 내에서 서비스하는 비디오 콘텐츠 중심의 소셜 네트워크 서비스입니다. 현재 일본과 대만, 태국 등에서 서비스하고 있습니다.LINE VOOM에서는 누구나 콘텐츠 크리에이터가 되어 콘텐츠를 업로드할 수 있으며, 사용자는 다양한 콘텐츠를 탐색하고 소비할 수 있습니다. For you 탭에서는 사용자가 흥미를 느낄 만한 동영상을 연속적으로 시청할 수 있고, Following 탭에서는 팔로우한 크리에이터의 콘텐츠를 모아볼 수 있습니다.이 글에서는 주로 For you 탭에서 제공하는 추천 프로세스를 다룰 예정입니다. For you 탭은 사용자에게 개인화한 콘텐츠 추천 결과를 제공하는 탭입니다. 사용자의 콘텐츠 피드백, 예를 들어 이전에 시청 혹은 클릭했거나 '좋아요'를 누른 등의 피드백을 토대로 사용자가 선호할 만한 콘텐츠를 추출해 제공합니다.이전에 사용하던 추천 시스템의 전체 작동 흐름은 다음과 같습니다.• 포스트 작성: 사용자가 비디오 포스트를 작성합니다.• 포스트 임베딩 생성: 작성된 포스트에 대한 임베딩을 생성합니다.• 포스트 임베딩 저장: 생성된 임베딩을 벡터 데이터베이스에 저장합니다.• 유사한 포스트 검색(ANN(approximate nearest neighbor)): 유사성 검색을 통해 해당 포스트와 유사한 포스트들을 찾습니다.• 추천 포스트 요청 및 가져오기: 사용자에게 추천된 포스트들을 제공합니다.이 과정을 통해 사용자는 자신의 관심사에 맞는 다양한 콘텐츠를 쉽게 접할 수 있었는데요. 한 가지 문제가 있었습니다.기존 추천 시스템은 포스트 임베딩을 생성해 저장한 후 추천 후보군을 추출해서 인메모리 데이터베이스에 저장하는 과정을 모두 일 단위 오프라인 배치 작업으로 처리했습니다. 이 때문에 추천 후보군을 업데이트하는 데 최대 하루가 걸린다는 한계가 있었고, 이 한계는 사용자 경험에 다음과 같은 문제를 초래했습니다.• 크리에이터 A가 새해를 맞아 'Happy New Year'라는 내용의 영상을 게시했을 때 이 영상이 사용자들에게 즉시 추천되지 않습니다.• 크리에이터 B가 월드컵 경기 중 골을 넣은 장면을 담은 영상을 게시했지만 이 영상 역시 사용자들에게 즉시 추천되지 않습니다.이와 같이 신선한 콘텐츠를 바로 볼 수 없다는 '즉시성 부족' 문제는 사용자 경험을 저하했습니다. 이를 해결하기 위해 시스템을 개선할 필요가 있었고, 실시간 추천 시스템을 구현하는 프로젝트를 시작했습니다.이 프로젝트의 목표는 사용자가 게시한 포스트를 즉각 추천 후보군에 반영해 더 신선한 포스트를 사용자에게 추천하는 것이었습니다. 이를 위해서 기존 시스템의 많은 부분을 변경했는데요. 일 단위로 후보군 풀(포스트 풀)을 생성하던 방식을 모델 기반의 실시간 후보군 생성 방식으로 변경했고, 벡터 검색 방식을 오프라인 연산에서 온라인 연산으로 전환했습니다.그중 이 글에서는 벡터 검색 구조의 변경에 중점을 두고 설명하려고 합니다.새로운 실시간 추천 시스템의 구조와 벡터 DB가 필요했던 이유새로 개발한 실시간 추천 시스템의 전체적인 작동 흐름은 다음과 같습니다.위와 같이 실시간 추천을 구현하기 위해 이전 추천 시스템에서 오프라인으로 수행하던 작업들을 온라인으로 전환해야 했는데요. 이를 위해 두 가지 작업이 필요했습니다. 첫 번째로 포스트 임베딩을 저장해 두는 공간을 오프라인 저장소에서 온라인 저장소로 교체해야 했습니다. 두 번째로 이전에는 유사성 검색을 통해 추천 가능한 모든 포스트를 오프라인에서 미리 찾아 그 결과를 온라인 저장소에 저장하는 방식으로 진행했는데요. 이제는 중간 저장 과정 없이 즉시 유사성 검색을 수행해야 했습니다.저희는 온라인 저장소와 실시간 유사성 검색, 이 두 가지 기능을 구현하려면 벡터 DB를 도입해야 한다고 판단했고, 여러 벡터 DB 플랫폼을 탐색하기 시작했습니다.지금까지의 과정을 요약해 보겠습니다.• 기존 추천 시스템은 오프라인 저장소와 배치 처리를 통해 유사성 검색을 수행했으며, 이로 인해 즉시성이 떨어지는 문제가 있었습니다.• 기존 추천 시스템의 주요 문제는 포스트 생성 후 추천 후보군에 포함되기까지 최대 하루가 소요된다는 점이었으며, 이 때문에 사용자들에게 즉시 포스트를 제공하지 못하고 있었습니다.• 기존 시스템의 문제를 해결하기 위해 오프라인 작업을 모두 온라인으로 전환하기로 결정했고, 이를 위해서는 포스트 임베딩을 온라인 저장소에 저장하고, 중간 과정 없이 실시간으로 유사성 검색을 수행하는 시스템으로 개선해야 했습니다.• 온라인 저장소와 유사성 검색을 실시간으로 처리하려면 벡터 DB를 도입할 필요가 있었습니다.벡터 DB 선정 기준과 Milvus를 선택한 이유최근 벡터 DB 생태계가 발전하면서 다양한 선택지가 생겼는데요. 저희는 그중에서 적합한 플랫폼을 선정하기 위해 다음과 같은 몇 가지 기준을 세웠습니다.• 벡터 전용 DB여야 한다.• 오픈소스여야 한다.• 온프레미스 환경에 직접 구축할 수 있어야 한다.• 실시간 추천을 위해 높은 부하에서도 안정적으로 작동하며 지연 시간이 낮아야 한다.이러한 기준을 두고 탐색했을 때, 적절한 프레임워크는 Milvus와 Qdrant가 있었습니다. 이제 두 프레임워크를 비교해 보겠습니다.Milvus는 성능 면에서 Qdrant에 비해 우수했고, 스토리지와 컴퓨팅을 분리해 안정성 또한 더 높았습니다. 또한 다양한 인덱스 알고리즘을 지원하고 있어서 여러 실험을 통해 저희 시나리오에 맞게 성능을 최적화할 수 있는 가능성이 크다고 판단했습니다. 스트림과 배치 작업이 분리되어 있어 온라인 INSERT와 오프라인 벌크 INSERT 기능을 지원하기 때문에 향후 임베딩 업데이트에 대응하는 기능도 구현할 수 있을 것으로 판단했으며, 더불어 활발한 커뮤니티 덕분에 문제 발생 시 정보를 쉽게 얻을 수 있다는

여행을 준비할 때 우리는 숙소, 투어, 액티비티, 입장권 등 다양한 상품을 한 곳에서 검색하고 싶어합니다. 마이리얼트립의 통합검색은 바로 이런 니즈를 반영해, 항공을 제외한 모든 여행 상품을 한 곳에서 검색할 수 있도록 설계된 기능입니다. 하지만 이렇게 다양한 상품을 한 번에 보여줄 때, “어떤 종류의 상품을 먼저 노출할 것인가?” 라는 중요한 문제가 발생합니다. 예를 들어, 사용자가 ‘제주 신화월드’ 를 검색했을때는 국내 숙소를, ‘홍콩 디즈니랜드’ 를 검색했을때는 티켓을 먼저 보여줘야 하는 거죠.검색추천팀의 머신러닝 엔지니어인 이성진님은 이런 문제를 해결하기 위해 사용자가 입력한 키워드를 분석하여 어떤 종류의 여행 상품(예: 숙소, 티켓, 투어 등)을 가장 먼저 보여주는 것이 사용자의 의도에 부합하는지 판단할 수 있는 AI 기반 검색어 분류 시스템을 개발하기 시작했습니다.검색 결과와 사용자 의도 사이의 간극기존 ‘제주 신화월드’ 통합검색 결과 — 숙소가 아닌 투어, 티켓이 상단에 노출되던 모습마이리얼트립의 통합검색을 통해 키워드 검색을 하면 가끔 사용자의 실제 의도와 검색 결과가 일치하지 않는 경우가 있습니다. 가령 ‘제주 신화월드’ 를 검색했을 때 투어/티켓 검색 결과가 상단에 나오는 경우를 들 수 있지요. 이렇게 여행 검색은 다양한 의도를 담고 있어 더욱 복잡합니다. 호텔을 찾는 것인지, 관광지 정보를 원하는 것인지, 아니면 티켓 예약을 원하는 것인지에 따라 적절한 결과가 달라져야 하지만, 현실은 그렇지 않은 경우가 많았습니다.처음 시도했던 방식과 그 한계“NER은 지나치게 복잡했고, 직접적인 의도 분류로 이어지기 어려웠습니다.”가장 먼저 시도한 접근은 NER(Named Entity Recognition)을 활용한 방식이었습니다. Claude 기반으로 BIO 태깅(단어에 B(시작), I(내부), O(밖) 형태의 라벨을 붙여 엔터티 위치를 나타내는 방식)된 데이터를 생성하고, Llama 3.2B 및 Blossom 같은 Open 모델을 미세조정해 학습시켰습니다. 그러나 이 방식은 결과적으로 의도 분류라는 목적에 비해 구조가 지나치게 복잡했고, 실제 서비스 적용에 적합하지 않았습니다. 엔터티를 추출한 후 다시 해석해야 하는 이중 구조가 실효성을 떨어뜨렸기 때문입니다. NER 기반 접근은 여기서 중단하고, 보다 직접적인 분류 방식으로 전환했습니다.초기 구상했던 NER 모델의 파인튜닝 워크플로우Claude를 활용한 분류 시스템 구축우리는 분류 모델을 통해 쿼리를 직접 투어, 티켓, 숙소, 렌터카, 쇼핑, 복합 등으로 나누기로 했습니다. 우선 3개월간의 통합검색 로그 30만여건 중 8회 이상 검색된 약 5만 개의 쿼리를 수집했고, 이 중 기존에 수작업 처리된 쿼리를 제외한 4.5만 개 정도에 대해 Claude를 이용해 분류를 진행했습니다.방향성 수정 후 워크플로우“약 90%의 쿼리를 안정적으로 분류할 수 있었고, 그 중 24%는 기존의 노출 순서를 바꾸는 효과를 냈습니다.”프롬프트는 총 12회 이상의 반복 실험을 통해 개선되었고, 각 클래스