ChatGPT가 출시된 이후 계속해서 생성형 AI 기술을 활용한 서비스 개발 고도화뿐만 아니라, 각 기업 내 구성원들의 AI 활용을 높이기 위한 노력 또한 더욱 커지고 있는데요.따라서 AI를 잘 활용하기 위한 기업의 환경 조성 및 활용 문화의 확산 또한 중요해지고 있습니다.SK플래닛에서는 이미 2024년 여름, 사내 구성원들이 다양한 LLM(Large Language Model)을 실제로 체험할 수 있는 LLM 플레이그라운드를 사내에 시범 오픈하고,이를 활용한 프롬프톤(프롬프트 + 해커톤) 이벤트를 사내 개발팀과 지원팀의 콜라보레이션으로 진행한 사례를 공유드리오니 참고하시기 바랍니다.ChatGPT 기반 서비스에서 활용하는 LLM Playground (이하 '플레이그라운드')는 서비스에 적용되는 GPT 모델을 테스트해 볼 수 있는 웹 기반 인터페이스로,http://chatgpt.com/ 의 채팅 인터페이스와 유사한 구성으로 사용자가 익숙하고 편리하게 사용할 수 있습니다.또한 여러 가지 파라미터 변경 기능을 함께 제공하기 때문에, 사용자는 GPT의 답변 스타일을 직접 바꿔볼 수 있습니다.예를 들어 'Temperature(온도)'라는 파라미터 값을 낮게 설정하면 일반적인 문장의 답변을, 높게 설정하면 무작위성이 증가해 보다 창의적인 답변을 생성하게 되며,이를 활용해 생성형 AI 기반 서비스의 페르소나를 설계하고 테스트할 수 있습니다.여러분이 아시는 OpenAI에서 제공하는 Playground 뿐만 아니라, Amazon Bedrock, SKT A.X, 네이버 HyperClovaX 등LLM을 제공하는 기업 중심으로 플레이그라운드를 제공하고 있습니다(최근에는 각각의 활용 목적에 따라 원티드 LaaS, SK mySUNI의 교육용 Playground 등 다양한 모습의 플레이그라운드가 출시되고 있습니다).B. Pain Point와 멀티 LLM 플레이그라운드의 시작그런데 플레이그라운드의 '출시' 뒤에는 실은 개발자 등 실무자 관점에서의 Pain point가 있었는데요,AI엔지니어 및 개발자가 업무를 위해 LLM 모델을 테스트하기 위해서는 각 LLM 제공 회사의 사이트를 돌아다녀야 하였으며(Context Switching 발생),LLM 모델 별로 비용이나 속도를 비교해 보고 싶은데 그러한 기능을 제공하지 않는 곳도 있어 불편했다고 합니다.그래서 저희 개발팀에서는 '우리 회사가 자주 사용하는 LLM 모델을 한 곳에서 테스트해 볼 수 있도록 직접 만들어 사용하자!' 는 아이디어를 제안하였고,이것이 바로 '멀티 LLM Playground'의 시작이었습니다! : )C. 플레이그라운드의 주요 기능플레이그라운드의 화면 구성은 다음과 같습니다.• None 사내 인트라넷으로 접속 가능 (외부망 불가능)플레이그라운드는 다음 LLM 모델을 지원하도록 만들었습니다(현재는 제공하지 않는 모델도 있음).원래는 개발팀 등에서 업무 용도로만 사용하고자 해서 UI 등은 크게 신경을 쓰지 않고 빠르게 개발하여 사내에만 사용하고 있었는데 ,그래도 여러 모델을 한 화면에서 테스트할 수 있어 좋았고, 오른쪽 패널에서 입출력 토큰 비용 및 답변 속도값을 제공하고 있어서 모델별 조건을 바로바로 비교할 수 있었습니다.그러던 중 누군가가, '사내 구성원 전체에게 이 도구를 활용하여 프롬프트 엔지니어링을 경험해 볼 수 있는 기회를 제공하면 어떨까?' 하는 생각을 제안하였고,마침 담당 임원도 이 아이디어에 동의해 주셨습니다. 따라서 이 도구를 전사에 공개하고 개발팀과 지원팀 콜라보레이션의 '프롬프톤' 공동 이벤트 를 진행하게 되었답니다.(2) 지원팀: '프롬프톤' 이벤트를 통해 우리회사 서비스의 캐릭터를 경험케 하다!SK플래닛에서는 아시는 것처럼 OK캐쉬백(이하 OCB) 과 시럽(이하 Syrup) 서비스를 운영하고 있는데, 여기에서 사용되는 다양한 귀여운 캐릭터 '판타스틱4' 들이 존재합니다.오글오글/오글봇 , 래키(OCB) , 러비(Syrup) 및 최근 출시된 OLOCK: (오락: )의 로키 가 바로 그것이죠(아래 참조).처음에는 (1)에서 언급한 LLM Playground의 단순 활용 방안을 고민하고 있었는데,사내 다양한 분들의 이벤트와 캐릭터 활용 아이디어, 그리고 사내에서 공유해 주신 캐릭터 마케팅 관련 글에서 인사이트를 얻어"우리 회사 서비스 캐릭터들이 AI를 만나면 어떤 아이들이 될까?" 라는 테마의 프롬프톤 사내 이벤트가 탄생하게 되었습니다.요약하자면 Prompt Engineering을 통해, 내가 선택한 캐릭터의 페르소나를 정하는 즉 'AI Characterization' 을 진행하는 것이었죠.아래는 사내 인터뷰 일부이며, 사진과 이름 등은 익명 처리하였습니다.프롬프톤 1~3위 수상자의 회고(소감 인터뷰)를 함께 공유드립니다사내 데이터 분석가, UX 디자이너, 소프트웨어 엔지니어 가 골고루 선정되셨는데요!이들의 회고를 통해 프롬프톤이 어떻게 진행되었고 어떤 모델과 프롬프트, 생각으로 결과물을 작성하였는지 아이디어와 느낌을 간접 경험해 보시기 바랍니다.최근 그리고 계속해서 LLM 모델의 성능이 너무나 좋아지면서,프롬프트 엔지니어링을 강조하던 기조가 조금은(?) 줄어드는 것 같기는 하지만(웬지 수고 대비 효과를 찾는 휴먼의 관점일까요),오히려 Agentic AI 등이 떠오르고 있는 요즘 Agent에게 정확한 지시를 하기 위해 아직도 잘 짜여진 프롬프트의 중요성 은 아직도 그 위상을 지키고 있다고 생각합니다.또한 이 글에서는 언급하지 않았지만, '코드 기반 프롬프트' 도 'LLM에게 명확한 지시를 내린다' 는 관점에서 개발 업무, 자동화 코드 생성뿐만 아니라일반 기획업무 등에서도 유용하게 활용될 수 있을 것으로 기대됩니다

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

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 서비스 조직에서 Kafka를 사용할 때 알아 두어야 할 것들 (4)에서 이어집니다.Kafka Client는 어떻게 클러스터의 전체 상태를 알 수 있는가? 서비스를 개발하는 입장에서 관련 옵션을 어떻게 잡아 주면 좋은가? 에 대해 설명합니다.• 동작 매커니즘• 브로커 - 클라이언트 간 metadata 교환NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 서비스 조직에서 Kafka를 사용할 때 알아 두어야 할 것들 (3)을 보고 오시면 좋습니다. 발표 내용Kafka 프로듀서 최적화하기 + 압축 기능 활용하기목차배경: Kafka 자료 구조Kafka 자료 구조는 어떻게 생겼는가?프로듀서 동작 방식 및 최적화 방법프로듀서와 브로커는 어떻게 메시지를 주고받는가? linger.ms, batch.size, buffer.memory 사용법압축 동작 방식 및 최적화 방법(재)압축은 어떻게 이루어지는가?compression.type, compression.{type}.level 사용법 NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

글. 방동민/ UX Researcher“이거 괜찮아 보이는데… 어때요?”서비스를 만들다 보면 자연스럽게 하게되는 말이에요. UX 리서처인 저 조차도 동료가 건내는 “이 문구 어때 보여요?”, “아이콘 바꿔봤는데 괜찮을까요?” 라는 질문을 들을 때면 무심코 고개를 끄덕이며 답변을 하기도 합니다. 편리함과 익숙함 때문에 고객보다는 동료에게 묻는 상황을 자연스럽게 받아들이게 되는거죠.디자이너, 기획자, 개발자 등 제품을 만드는 사람이라면 누구나 ‘지금 내가 만들고 있는 것이 고객에게 어떻게 보일지’에 대한 불확실성을 가지게되고 이 불확실성을 해소하기 위해 가장 빠르고 편한 방법은 바로 옆에 있는 동료나 지인에게 묻는 것입니다. 짧은 시간 안에 피드백을 받을 수 있고, 커뮤니케이션 비용도 낮으니까요.그런데 어느 순간부터 그 피드백이 ‘불편할 정도로 편하다’는 생각이 들기 시작했습니다.피드백의 편리함이 만든 편향동료나 지인에게 의견을 묻는 건 분명 빠르고 효율적인 방식입니다. 문제는, 이 효율이 반복되다 보면 우리가 놓치게 되는 시선이 생긴다는 거예요.내부 동료는 이미 그 제품이 어떤 배경에서 만들어졌는지 알고 있습니다. 설사 맥락을 모른다고 해도, 동일한 업무 환경과 유사한 문제 의식을 공유하고 있다는 점에서 사용자가 아니라 ‘메이커’의 시선으로 답변하게 됩니다. 지인의 경우도 마찬가지예요. 몇 번만 반복해도 학습이 이루어지면서 점점 ‘비전문가 사용자’와는 다른 방식으로 반응하게 됩니다.이런 구조에서는, 마치 거울 앞에서 계속 같은 표정을 연습하듯이 ‘정제된 반응’만 들을 위험이 생깁니다. 우리는 점점 ‘진짜 고객’의 언어와 경험에서 멀어지게 되죠. 그렇다면 질문은 간단해집니다.리서치의 접근성은 왜 여전히 높지 않은가우리는 왜 고객에게는 묻기 어려웠을까요? UX 리서처로서 오랜 기간 리서치 프로젝트를 진행해 오면서 한 가지 패턴을 자주 마주합니다.바로 리서치는 항상 일정과 리소스에 쫓기고, 접근하기 어려운 것처럼 여겨진다는 점입니다. 기획 초기에는 “이건 고객에게 물어봐야 해요”라는 공감대가 있지만, 현실적인 리크루팅, 가이드 설계, 일정 조율 등의 벽에 부딪히면 금세 대안은 ‘내부에서 빠르게 정리하자’로 기울게 됩니다.이건 리서치 방법론이 부족해서라기보단, 리서치 구조가 실무 흐름에 스며들어 있지 않기 때문입니다. 바로 이 지점을 개선하고 싶었습니다. 정교하게 설계된 리서치가 아니더라도 필요한 순간에 빠르게 활용할 수 있는 고객 피드백 구조를 만들 수는 없을까라는 고민을요.고객을 팀 안으로 초대해보기우리가 고객에게 알고 싶은 건 간단한 것들이었습니다. 예를 들어 “이 버튼의 기능이 예상되나요?”, “이 화면은 어떻게 이해되나요?”, “이건 복잡하거나 불편하지 않나요?”와 같이 복잡하지 않고, 그냥 짧고, 빠르게 의견이 필요한 질문들이었죠. 이런 질문은 대부분 리서치 타이밍을 놓치거나 우선순위에서 밀려나곤 합니다.하지만 제품의 완성도나 방향성에 실제로 결정적인 영향을 주는 미세한 순간이기도 하죠.작지만 중요한 질문들을 옆 자리 동료에게 가볍게

2025년 2월, 토스가 10주년을 맞았어요. 브랜드에게 10년은 결코 짧은 시간이 아니지만, 토스에게는 여전히 갈 길이 먼 ‘초기’일지도 몰라요. 그래서 토스는 이번 10주년을 새로운 출발선으로 삼기로 했어요.이런 방향성은 10주년 캠페인의 이름에도 담겨 있어요. ‘10 to 100’, 지난 10년을 디딤돌 삼아 앞으로의 100년을 향해 나아가겠다는 의지예요. 그리고 캠페인에서 가장 중요하게 생각한 건, 토스와 사용자가 직접 만나고 경험할 수 있는 물리적인 접점이었어요. 그렇게 토스 10주년 기념 공간, ‘스퀘어 오브 토스’가 탄생했어요.하루에도 수많은 팝업이 생기고 사라지는 성수동에서, 단지 사람을 많이 불러모으는 것 이상의 좋은 브랜드 경험을 설계하기 위해 고민했던 세 가지 지점을 나눠볼게요.1. 캠페인 의도가 녹아든 로고와 공간 찾기기획 초기에 가장 중요한 두 가제 과제가 있었어요. 캠페인의 의미를 담은 로고를 만드는 것과, 그 메시지를 자연스럽게 전달할 수 있는 공간을 찾는 것.10 to 100은 ‘금융에서 일상으로, 온라인에서 오프라인으로, 국내에서 글로벌로’ 나아가겠다는 방향성과 함께 10년의 시작에서 100년의 여정으로 향한다는 뜻을 담고 있어요. 그래서 로고도 단순한 타이틀이 아니라, 변화의 여정을 시각화하는 데 집중했어요.10은 현재의 출발선, 100은 우리가 지향하는 미래를, to는 그 사이 움직임과 전환을 상징하는 흐름을 뜻해요. 이를 표현하기 위해 10과 100은 정적인 사각형 안에, to는 유동적인 원형으로 배치해 정체성과 움직임을 동시에 담았죠.이 로고에 담긴 메시지를 실제로 구현할 공간 역시 중요했어요. 사실 공간을 찾을 무렵, 스퀘어 오브 토스의 주요 프로그램은 어느 정도 밑그림이 그려져 있었어요. 토크 세션, 전시, 굿즈샵, 라이브러리 등 프로그램의 방향이 분명했기 때문에 기획 의도를 구현할 수 있는 공간을 역으로 찾기 시작했죠.서울역, 안국, 광화문 등 다양한 후보지를 돌며 결정한 공간은 성수동의 ‘앤더슨씨’였어요. 이곳은 중앙 광장을 중심으로 두 동의 건물을 함께 사용할 수 있는 구조예요. 프로그램을 유기적으로 배치할 수 있고, 하나의 흐름 속에서 다양한 경험을 연결할 수 있다는 장점이 있었어요. 10에서 100으로, 점에서 선으로 흐르는 여정을 공간에서도 자연스럽게 구현할 수 있다는 점에서 캠페인의 메시지와도 잘 어울린다고 느꼈죠.2. 내 삶에 닿는 이야기 찾기좋은 공간을 찾았으니, 이제 중요한 건 공간을 채울 프로그램을 구체화 하는 일이었어요. 집중한 질문은 하나였어요.기꺼이 시간을 내어 걸음 해준 분들에게, ‘내 삶에 도움이 되는 무언가’를 분명히 전하고 싶었거든요.그 고민 끝에 탄생한 것이 ‘토스 위닝 세션’과 ‘넥스트 토크 세션’이었어요. ‘위닝 세션’은 디자인, 개발, 비즈니스 등 6개 분야의 리더들이 직접 토스의 실패와 성장 경험을 솔직하게 나누는 자리였어요. 완성된 결과보다 과정 속에서 얻은 배움과 시행착오에 집중했기 때문에, 누구나 자신의 고민과 겹쳐 생각해볼 수 있는 순간들이 있었죠.

네이버 홈피드는 검색 홈 하단에서 사용자에게 개인화된 콘텐츠를 추천하는 피드 서비스입니다. 이 글에서는 사용자에게 보다 나은 추천을 제공하기 위해 고민하고 구현한 핵심 기술을 다루고자 합니다. 주요 내용은 다음과 같습니다.홈피드 서비스 톺아보기: 홈피드 전반의 구조와 구성 요소, 다양한 콘텐츠 재료, 그리고 대규모 언어 모델(LLM, large language model)을 활용한 개인화 추천 시스템 홈피드 추천 랭킹 로직 구성: 다양한 특징의 콘텐츠를 효과적으로 조합하는 방법, 클릭 외에도 고려해야 할 만족도 지표, 추천의 다양성을 확보하기 위한 전략 사용자 맞춤형 첫 번째 콘텐츠 선정 방법: 첫 번째 노출 콘텐츠(Rank1)의 중요성과 사용자 행동 및 관심사 기반 리트리버 모델의 최적화 방안홈피드 개발 과정에서 마주했던 기술적 도전과 그에 대한 해결 방안을 함께 살펴보겠습니다.1. 홈피드 서비스 톺아보기네이버의 홈피드 서비스는?홈피드는 사용자의 채널 구독, 읽은 문서, 검색 이력 등 네이버 내 활동을 기반으로 맞춤 콘텐츠를 제공하는, 네이버 검색 홈 하단에 위치한 개인화 추천 서비스입니다. 다양한 콘텐츠를 사용자 맞춤으로 제공하여, 검색 홈의 가치를 높이고 네이버의 여러 서비스로 이어지는 연결 고리 역할을 수행합니다.네이버의 첫인상인 검색 홈에서 즐길 수 있는 콘텐츠 경험을 풍부하게 만드는 것이 홈피드의 궁극적인 목표입니다.현재 홈피드에서는 블로그, 카페, 포스트뿐 아니라 네이버TV, 인플루언서, 프리미엄 콘텐츠, 클립 등 다양한 콘텐츠를 개인화해 제공하고 있으며, 사용자의 취향에 맞춘 콘텐츠 묶음 형태로도 제공하고 있습니다.처음 출시된 2023년 11월 이후 사용자 반응도 긍정적입니다. 일간 사용자 수는 출시 시점 대비 약 6배, 클릭 수는 약 8배 증가하며 꾸준히 성장하고 있습니다.맛있는 피드를 위한 재료홈피드 추천은 두 가지 핵심 재료를 바탕으로 다양한 콘텐츠 중 무엇을 보여줄지 결정합니다.먼저 블로그, 카페, 네이버TV, 포스트, 클립 등 다양한 콘텐츠를 모은 콘텐츠 풀(content pool)이 있으며, 개인화의 기반이 되는 사용자의 클릭 로그, 구독 정보, 검색 이력, 주제 선호도, 피드백 반응 등으로 구성된 사용자 컨텍스트(user context)가 함께 활용됩니다.이 두 가지 정보를 바탕으로, 리트리버(retriever)가 사용자에게 적합한 콘텐츠 후보를 수집하고, 랭커(ranker)가 이들에 순위를 매깁니다. 특히, 홈피드에서 가장 먼저 노출되는 Rank1 콘텐츠는 사용자 만족도에 큰 영향을 주기 때문에, 기존 랭킹 모델과는 별도로 Rank1 최적화 도구(Rank1 optimizer)를 활용해 더욱 정교하게 선정합니다.위 흐름 중 '리트리버'를 조금 더 자세히 살펴보겠습니다. 홈피드에서는 목적에 따라 다양한 리트리버를 활용합니다.구독 기반: 사용자가 구독한 채널이나 카페 게시판의 문서 추천키워드 기반: 클릭·검색 이력으로 추출한 관심 키워드 또는 주제군에 해당하는 인기 문서 추천인기도 기반: 사용자의 주제 선호도와 유사한 성별·연령대 사용자에게 인기 있는 문서 추천소비 이력 기반: 사용자가 클릭한 문서와 유사한 콘텐츠를 찾기 위해 EASE(Embarrassingly Shallow Autoencoders), two-tower 모델 등 활용검색 이력 기반: 사용자의 최근 검색어와 직접적으로 관련된 문서 추천키워드 기반 리트리버는 사용자들에게 인기가 있는 키워드와 그에 매칭되는 인기 문서들을 후보 풀로 사용하고, 검색 이력 리트리버는 사용자가 검색을 통해 직접적인 사용성을 보였던 주제와 연관된 문서를 사용한다는 점이 차이가 있습니다.신선한 제철 재료 추가하기 - 최근 검색/소비 반영'신선한 제철 재료 추가하기'라는 제목처럼, 이번에는 사용자의 가장 최근 사용성을 고려해 행동에 즉각 반응하는 리트리버 구축 사례를 소개하겠습니다.사용자는 네이버 앱에 접속해 콘텐츠를 소비하거나 검색하는 등 다양한 활동을 합니다. 이러한 실시간 사용성을 홈피드에 즉시 반영하면 더욱 만족스러운 개인화 결과를 제공할 수 있지 않을까 고민하며 리트리버 고도화를 진행했습니다.After Search: 사용자가 최근에 검색한 키워드와 연관된 문서 추천Click2Click: 사용자가 가장 최근에 클릭한 문서와 유사한 콘텐츠를 content-based 방식으로 추천After SearchAfter Search는 사용자가 하루 이내에 검색한 키워드와 연관된 문서를 추천합니다. 실시간 검색 로그를 기반으로, 검색 직후 수 초 이내에 관련 콘텐츠가 홈피드에 노출될 수 있도록 구성했습니다.전체 추천 파이프라인은 다음과 같습니다.검색 로그에서 주요 키워드 추출사용자별 검색 로그에서 추천에 적합한 탐색형 또는 시의성 높은 키워드를 식별합니다. 초기에는 모든 검색어를 seed로 사용했지만, 날씨 등 일상 정보성 키워드는 추천 문서 품질이 낮다는 한계가 있었습니다. 이를 개선하기 위해 네이버 검색의 쿼리 베이스 데이터를 연동해 키워드의 주제 및 검색 의도를 분류하고, 탐색형/시의성 질의에 한해 문서를 선정하도록 필터링합니다.사용자 선호도를 반영하여, 사용자가 꾸준히 소비하는 키워드는 순위를 높이고 이미 충분히 소비했거나 관심이 낮은 키워드는 페널티를 부여합니다.세션 내에서 이미 노출된 키워드나 이미 노출된 문서에서 추출된 키워드는 제외해 노출 피로도를 줄입니다.연관 문서 선정키워드에 대한 연관 문서는 TF-IDF와 TSDAE 모델을 활용해 선정합니다. 단, 이 모델들은 키워드-문서 간 연관성(relevance)만을 기준으로 하기 때문에, 추천 품질이 낮은 문서가 추출된다는 한계가 있습니다.사용자 피드백 기반 피처, 검색어별 사용자 반응이 좋았던 문서 정보를 함께 반영해 이를 보완합니다.정리하자면, After Search는 검색 사용성을 활용하지만, 단순 검색 결과가 아니라 사용자 선호 키워드를 중심으로 피드 내 선호 문서를 추출한다는 것이 차별화된 강점입니다.현재 사용 중인 TF-IDF, TSDAE 기반 연관 문서 선정 로직은 향후 LLM 기반 임베딩 모델로 고도화할 계획입니다.Click2ClickClick

Python은 높은 개발 생산성으로 많이 사랑받는 프로그래밍 언어 중 하나입니다. 하지만 높은 생산성의 대가로 성능에 대해 많은 비용을 지불해야 한다는 것이 정설로 여겨지고 있었습니다.그러나 Python 3.11을 시작으로, 이제는 Python에서도 성능을 챙기려는 노력이 이어지고 있습니다. 그 연장선으로 이 글에서는 프로파일링 도구 중 하나인 Yappi를 활용해서 Python 서버의 성능 개선을 이루어낸 사례를 소개하고자 합니다. 이 글이 Python 애플리케이션의 성능을 더 쉽게 분석하고 최적화하는 데에 도움이 되었으면 좋겠습니다.배경 지식저희가 당면한 문제에 대해 이야기하기 위해, 먼저 주요 용어와 구조를 간단히 설명하겠습니다.서치피드 등 최근 네이버에서 새롭게 출시되는 많은 피드의 뒤에는 수많은 컴포넌트가 존재합니다. 피드를 구성하기 위해서는 일련의 과정이 필요합니다. 가장 간단하게 피드를 구성한다고 가정하면 필요한 과정은 다음과 같습니다.주어진 질의와 연관된 문서를 DB에서 100개 가져온다. 가져온 문서의 피처(feature)를 종합해 순위(랭킹)를 매긴다. 가장 높은 랭킹을 얻은 문서 10개를 차례로 노출한다. 피처란? "In machine learning and pattern recognition, a feature is an individual measurable property or characteristic of a data set." 어떤 개체에 대한 정보, 특징을 이야기하며 보통 ML 모델의 입력값으로 사용됩니다. 블로그 문서를 예로 들면, 20대 남성이 해당 문서를 좋아하는 정도를 [0, 1] 사이의 값으로 나타낸 것도 피처라고 할 수 있고, 문서에 포함된 사진의 개수도 피처가 될 수 있습니다. 메타 정보와의 경계성은 모호하나, 저희 팀에서는 한 단계 이상의 정제 과정을 거친 값을 피처로 취급하자'라는 기준을 공유하고 있습니다.고품질의 피처는 곧 고품질의 서비스로 이어집니다. 네이버에서는 더 좋은 사용자 경험을 위해 다양한 피처를 활용해 랭킹을 하고 있으며, 다양한 서비스에서 활용할 수 있게 피처 정보를 제공하는 별도의 서버(Feature Serving Agent, 이하 FSA)를 마련했습니다. 그런데 이 구조는 효과적이지만 성능이 만족스럽지 않다는 문제가 있었습니다.대량의 단순 조회가 너무 느리다는 문제FSA란FSA는 Redis와 같은 일종의 키-값 저장소입니다. 블로그/카페 문서의 피처를 계산해 DB에 적재하고, 문서의 ID로 피처를 조회할 수 있게 합니다. 이때 고품질 피처를 계산하기 위해 ML 모델을 사용해 배치로 계산합니다.FSA의 기본 동작은 최대 800개의 문서 ID를 받아 각 문서의 피처 정보를 제공하는 것입니다. Redis와 같은 기존 솔루션을 이용하면 빠르게 개발할 수 있지만 FSA를 사용하게 된 2가지 이유가 있습니다.무한대의 scale-out 필요성: 최대 800개의 문서에 대해서 mget 수행 시 CPU 사용, 응답 시간의 측면에서 성능이 더 뛰어나며, 무엇보다 '이론상' 무한대로 scale-out이 가능한 인하우스 분산 DB를 사용하고자 했습니다. Redis 클러스터는 안정성을 이유로 scale-out 상한이 존재합니다.운영 유연성 확보: 다양한 곳에서 쉽게 사용하고 신뢰성 있는 서비스를 제공하기 위해서는 호출처 트래킹, 트래픽 컨트롤, 비즈니스 로직 추가 등의 추가 기능이 필요합니다.성능 테스트 결과FSA 개발이 완료되고 nGrinder를 이용해 성능을 테스트했습니다. 정확한 성능을 측정하고자 캐시는 사용하지 않았습니다.자세한 성능 테스트 환경은 다음과 같습니다.서버 인스턴스 1대 - 16 CPU 코어(AMD genoa/milan)테스트 대상 문서 ID의 개수는 10K, 한 번의 호출당 랜덤으로 800개를 뽑아서 사용호출 QPS(query per second)는 85 175테스트 결과는 다음과 같습니다.성능 테스트에서 살펴보는 지표는 다양하지만, 가장 기본이며 핵심적인 CPU 사용률과 응답 시간을 살펴보겠습니다. CPU 사용률로 적절한 인스턴스 수를 산정할 수 있고, 응답 시간은 곧 서비스 품질로 이어지기 때문입니다.CPU 사용률은 17.8%(85qps), 36%(175qps)평균 응답 시간은 약 44ms, p99 응답 시간은 약 87msFSA는 2500qps의 요청을 받을 예정이었기 때문에 이를 바탕으로 필요한 서버 인스턴스 수를 산정해 보겠습니다. 저희 팀은 안정적인 서비스를 위해서 인스턴스당 CPU 사용률을 30% 이하로 맞추고 있습니다. CPU 사용률 1%당 약 4.8qps를 받을 수 있으며, 30%의 사용률은 약 144qps입니다. 인스턴스 1대당 144qps를 받을 수 있으므로 필요한 서버는 최소 17대 이상입니다. CPU 코어로 계산하면 272코어가 됩니다.272코어의 리소스는 절대 작은 수치가 아니며, 팀 내 다른 서버의 리소스 사용률과 비교해서 판단해보면 FSA의 로직은 너무 무거웠습니다. 또한, 하위 1% 응답 시간이 87ms임을 보아 분명히 어딘가에 병목이 존재한다고 생각했습니다.병목 지점 찾기병목 지점을 찾기에 앞서, 왜 병목 지점을 찾는 것이 중요한지 간단하게 짚고 넘어가겠습니다.암달의 법칙(Amdahl's law)에 따르면 병렬화 등에 따른 성능 향상은 결국 순차 실행되는 코드의 비율에 제한됩니다. 병렬화를 떠나 실행 시간 관점에서 다시 쉽게 풀어본다면, 이론적으로 얻을 수 있는 최대 속도 향상은 전체 실행 시간 중에서 차지하는 비율로 제한됩니다. 쉽게 말해, 전체 실행 시간의 10%를 차지하는 부분을 최적화해서 2배 빨라졌다고 하더라도 전체를 보면 단 5% 빨라지는 셈입니다.결국, 들이는 노력에 비해 크게 성능을 향상시키려면 실행 시간의 대부분을 차지하는 지점을 찾아야 합니다. 이러한 병목 지점을 찾아내는 것이 '프로파일링'입니다. 개발자들은 프로파일링에 다양한 방법을 사용합니다. 여기서는 Python을 기준으로 몇 가지 방법을 소개합니다.각 함수의 시작과 끝에서 타임스탬프를 기록해서 확인하기가장 원시적이고 적용하기 쉬운 방법입니다. 소규모 프로젝트에서는 꽤 빠르고 효과적일 수 있지만, 불필

토스증권의 혁신에 유저들이 찐 감동한 이야기최근 토스증권에서 출시한 서비스에, 사용자들이 이런 의견까지 남겨줄 정도로 감동을 받았어요.바로 토스증권의 '해외기업 어닝콜 실시간 번역 서비스(이하 ‘어닝콜')예요. 어닝콜은 해외 특정 기업의 실적 발표 직후, 경영진이 투자자와 애널리스트를 모아 숫자 뒤에 숨겨진 해석과 전략을 발표하는 오디오 회의예요. 한국 증권사 최초로, 어닝콜을 실시간으로 들으면서 한국어 번역과 요약까지 볼 수 있는 제품이라 이렇게 뜨거운 반응을 얻을 수 있었던 것 같아요.토스증권 내부에서는 예전부터 어닝콜 서비스에 대한 아이디어가 있었어요. 어닝콜은 투자자들이 가장 주목하는 행사였거든요. 어닝콜 시즌만 되면, 주식 커뮤니티에서는 늘 어닝콜 이야기가 활발하게 오갔죠.이번 글에서는, 어닝콜 서비스를 딱 두 달 만에 제작한 이야기를 공유드리려고 해요.어닝콜을 정말 어렵게 보고있는 유저들해외기업 어닝콜 실시간 번역 서비스가 한국 증권사 최초라고 말했는데요. 그럼 사용자들은 원래 어닝콜을 어떻게 보고 있었을까요? 리서처 팀과 함께, 어닝콜을 챙겨보시는 분들을 인터뷰 했어요.생각보다도 훨씬 불편한 방법으로 어닝콜을 보고 계시더라고요. 어닝콜은 보통 1~2시간 정도 진행되는데, 그 시간동안 그냥 듣고 있다고 하셨어요. 특히 외국 기업의 어닝콜은 대부분 영어로 진행되기 때문에, 번역 앱을 쓰거나, 그냥 영어 듣기를 하거나, 유튜브에서 실시간으로 어닝콜을 요약, 해설해주는 스트리밍을 보기도 했어요. 유튜브 라이브는 무려 세시간 동안 진행되더라고요. 어닝콜이 끝난 후 AI 로 스크립트를 해석해서 읽거나, 요약 영상을 보는 분들도 계셨어요.놀라웠던 점은 어닝콜을 열심히 보는 분들을 모아 인터뷰를 했음에도, 어닝콜을 처음부터 끝까지 다 듣는 분은 거의 없었다는 거예요. 그렇다면 초보 투자자들은 더더욱 접근이 어려웠겠죠.어닝콜, 실시간으로 요약해준다면?초보 투자자든, 고수 투자자든 어닝콜을 더 쉽고 잘 읽히게 만드는 게 목표가 되어야겠다고 생각했어요. 앞서 유튜브 실시간 요약 콘텐츠를 보는 사용자가 있다고 말씀드렸죠? 그것처럼 실시간 요약 기능이 있다면, 번역 스크립트만 보는 것보다 훨씬 도움이 될 것 같았어요.만약 그대로 번역만 해줬으면 좌측 영상처럼 텍스트가 그냥 주르륵 나오게 됐을거예요. 그러면 읽는데 굉장히 오랜 시간이 걸렸겠죠?어닝콜을 실시간으로 요약해주는 경험이 특별하게 느껴지려면, UI의 심미성도 중요하다고 생각했어요. 사용자가 평소와는 완전히 다른, 특별한 라이브 환경에 있다는 걸 확실히 느낄 수 있도록 다크모드를 고정하고 로고의 색이 배경에 은은하게 비치는 시각 효과를 주었어요.또 텍스트가 번역되거나 요약될 때 음성보다 약간의 딜레이가 생길 수 있는데, 사용자가 이걸 오류로 느끼지 않도록 ‘•••’ 이모지와 ‘번역 중’ 텍스트로 자연스럽게 안내했어요. 긴 전문이 자연스럽게 짧은 요약으로 합쳐지는 것처럼 보이는 인터랙션도 추가해, 사용자가 별도의 안내 없이도 직관적으로 상황을 이해할 수 있게 만들었어요.라이브가 끝난 후 요약노트

이번년도 춘천마라톤을 참가하게 되었습니다.작년에 처음 도전해서 어떻게든 완주는 했는데... 기록이 4시간 55분으로 저조하였습니다.그래서 올해는 4시간 30분 안에 골인하는 것을 목표로 잡았습니다.하지만 문제는 훈련을 스스로 하기엔 의지가 부족하여 "누가 아침마다 일정을 제안해주면 얼마나 좋을까? 라는 생각을 하였습니다.PT를 하기엔 너무 비싸고 그래서 직접 만들어보자라고 생각을 했습니다.최근 핫한 바이브 코딩을 활용해서 러닝 코치를 직접 만드는 프로젝트를 시작했습니다.매일 아침 7시에 훈련 계획을 알려주고, 완료 여부를 체크하고 히스토리 기반으로 계획을 추천해주는 코치요금이 부과되지 않는 것을 목표로 하였습니다. (훈련도 안하고 돈만 나가면 아쉬워서..)훈련 기록을 토대로 훈련 계획을 제시하기 위함 - 무료 플랜바이브코딩의 파트너로 챗GPT를 선정하였습니다.선정 이유는 이미 유료플랜을 사용하고 있기 때문입니다.• None 완료한 훈련을 기반으로 LLM 에게 추천을 받고 싶었지만 제안된 코드는 그렇지 않아 수정 요청했습니다.• None 원하는 방식이 아닌 다른 방식으로 Firebase 인증을 하고 있어서 수정 요청했습니다.• None 제안된 코드에서 순환참조가 발생하여 리포트하였습니다.• None 자동으로 푸시되는 훈련과 유저가 오늘의 훈련이 뭔지 요청했을 때 훈련의 내용이 다름제안된 코드를 보면서 살짝 수정을 더해 완성한 애플리케이션 결과입니다.구상하고 있는 아키텍처와 기능을 전달해주면 정말 빠르게 구현할 수 있는 것 같다.질문을 대충하면 가끔 다른 길로 빠져 돌아오지 못하는 경우도 있지만 질문을 잘 해주면 정말 좋은 도구임에는 틀림이 없다.꼭 4시간 30분 목표도 달성하고 싶다!