글. 방동민/ 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분 목표도 달성하고 싶다!

여러분은 스크린리더라는 기능을 아시나요? 시각장애인 사용자가 앱을 탐색할 때 사용하는 보조 기술로, 화면 위의 요소들을 음성으로 읽어줘요. iOS에서는 ‘보이스오버(VoiceOver)’라는 이름으로 제공되고 있어요.보이스오버는 이 화면을 이렇게 읽어줘요.이 문장은 3가지 핵심 정보로 구성돼 있어요. 레이블, 역할, 상태인데요. 이 3가지 요소를 파악해야 이게 읽기만 하는 정보인지, 눌러야 할 버튼인지, 현재 어떤 상태인지를 정확히 파악할 수 있어요. 사용성에 가장 중요한 요소인거죠.사용자는 끝까지 듣지 않는다토스에서는 시각장애인 사용자를 대상으로 꾸준히 UT(사용성 테스트)를 진행해오고 있어요. 그 과정에서 반복적으로 발견된 한 가지 사용 패턴이 있었어요. 스크린리더 사용자는 음성을 굉장히 빠르게 듣고 다음 항목으로 넘어간다는 점이었죠. 화면을 볼 때 모든 글을 꼼꼼히 읽지 않고 훑는 것 처럼, 스크린리더 사용자도 모든 내용을 끝까지 듣지는 않는거죠.특히 리스트 컴포넌트처럼 앞부분에 읽어야 할 정보가 많은 경우, 사용자가 ‘역할 정보’를 듣기 전에 항목을 넘겨버리는 일이 많았어요.예를 들어, 이런 화면을 보이스오버는 “ 5,931,424원, 쌓인 이자 2,253원, 송금, 버튼 “ 이라고 읽어줘요. ‘버튼’이라는 역할 정보는 문장의 맨 끝에 오기 때문에, 사용자가 앞부분만 듣고 넘기면 이 항목이 눌러야 할 버튼인지조차 인지하지 못한 채 지나치게 돼요. 결국 다시 해당 항목으로 돌아와 재탐색해야 하는 불편함이 반복되는 거죠.역할 정보를 뒤에 읽어주는 것은 iOS의 기본 설정이지만, 사용자에게 최선은 아니라고 느껴졌어요. 그래서 리스트 컴포넌트를 어떻게 읽어줘야 더 좋은 사용성을 만들 수 있을지, iOS 개발자, 접근성 컨설턴트, 디자이너가 함께 머리를 맞댔어요. 그 과정에서 몇 가지 아이디어가 나왔어요.기존처럼 한꺼번에 읽어주는 게 아니라, 하나하나 쪼개서 읽어주는 거예요. 사용자가 빠른 속도로 탐색하더라도 역할 정보를 비교적 빨리 파악할 수 있죠. 하지만, 초점(Focus)이 지나치게 많아져 오히려 탐색 속도가 느려질 수도 있었어요.2.효과음으로 알려주기역할 정보를 짧은 효과음으로 구분해주는 아이디어도 있었어요. 예를 들어 버튼은 ‘띵’, 스위치는 ‘툭’, 텍스트는 무음처럼, 귀로 바로 감지할 수 있게 만드는 방식이죠. 사용자가 텍스트를 끝까지 듣지 않더라도, 소리만으로도 이게 어떤 컴포넌트인지 직관적으로 알 수 있어요.마지막으로 떠올린 방법은, 역할 정보를 문장 앞에서 먼저 읽어주는 방식이에요. 사용자가 탐색을 시작하자마자 이 항목이 버튼인지, 단순한 텍스트인지 바로 파악할 수 있도록요.하지만 이 방식은 iOS의 기존 시스템 문법과는 다르죠. 토스 앱만 예외적으로 앞에 읽도록 바꿔버리면, 다른 앱들과의 사용성 일관성이 깨질 수 있다는 우려도 있었어요. 그래서 결국 이 문제는 개별 앱이 해결하기보다, 시스템 차원에서 사용자가 읽는 방식을 선택할 수 있도록 옵션을 제공해야 한다는 결론을 내렸어요.그리고 이 중 두 가지를 정리해 토스에서 어

오디오 출력도 자원입니다: Audio Focus를 이해하는 첫걸음Android 앱을 개발할 때 우리는 CPU, 메모리, 배터리, 네트워크 등 다양한 자원을 신중하게 다룹니다.성능을 최적화하고 사용자 경험을 향상시키기 위해 리소스를 아끼고, 효율적으로 사용하는 것은 개발자의 기본 소양이죠.우리가 멀티미디어 앱을 개발할 때 고려해야할 중요한 리소스가 있습니다.바로 오디오에 대한 권한, 즉 Audio Focus입니다. 오디오 포커스는 시스템이 관리하는 공유 리소스입니다.하나의 앱이 독점할 수도 있고, 다른 앱과 양보하며 사용할 수도 있습니다. 이를 무시하거나 무분별하게 다루면 사용자 경험은 순식간에 망가질 수 있습니다.이 글에서 우리는 Audio Focus를 하나의 소중한 리소스로 보고, 이를 올바르게 요청하고 반납하며, 다른 앱과 어떻게 공존할 수 있을지를 살펴보겠습니다.Audio Focus는 단순한 권장사항이 아닙니다. 이를 무시하고 오디오 재생이나 녹음을 수행할 경우, 사용자는 다음과 같은 혼란스러운 경험을 겪을 수 있습니다.다음은 Android 앱 개발시 발생할 수 있는 대표적인 사례들입니다.1. 백그라운드 음악 앱 위에 겹치는 소리• None 사용자는 음악 스트리밍 앱을 실행한 상태에서 팟캐스트나 라디오 앱을 켭니다.• None 라디오 앱이 Audio Focus를 요청하지 않고 오디오를 재생합니다.• None 결과: 두 앱의 소리가 겹쳐 재생되며 사용자 경험이 망가집니다.2. 전화 수신 중에도 계속 재생되는 오디오• None 사용자가 음악을 듣고 있는 중에 전화가 옵니다.• None 음악 앱이 재생을 중지하지 않고 계속 재생됩니다.• None 결과: 전화 상대방의 목소리와 음악이 섞여 들리며 통화 품질이 저하됩니다.• None 내비게이션 앱이 음성 안내를 시작합니다.• None 음악 앱은 계속 재생되고 있습니다.• None 결과: 중요한 안내를 사용자가 놓칠 수 있습니다.4. 의도하지 않은 소리 녹음• None 사용자가 음성 메모 앱을 실행해 녹음을 시작합니다.• None 배경에서 동작 중인 음악 앱이나 라디오 앱이 여전히 재생 중입니다.• None 결과: 원하지 않은 소리가 녹음될 수 있습니다.앞서 소개한 시나리오처럼 사용자가 원하지 않는 경험을 피하고, 바람직한 경험을 제공하기 위해 AudioFocus를 어떻게 활용할 수 있는지 살펴보겠습니다.앞에서 우리는 Audio Focus에 대한 처리 없이 오디오 재생 앱을 개발할 경우에 발생할 수 있는 이슈를 살펴 보았습니다.이를 해결하기 위해서 Android는 Audio Focus기능을 제공합니다.다음 그림은 Android 앱이 Audio Focus를 사용하여 서로 다른 앱들이 오디오를 재생하는 일반적인 케이스를 보여줍니다.• None 음악 앱이 에게 AudioFocus를 요청합니다.• None 는 음악 앱의 AudioFocus 요청을 승인(Grant) 합니다.• None 음악 앱은 음악을 재생합니다.• None 라디오 앱이 에게 AudioFocus를 요청합니다.• None 는 라디오 앱의 AudioFocus 요청을 승인(Grant) 합니다.• None 는 현재 AudioFocus를 가지고 있는 음악 앱에게 AudioFocus를 잃었음(LOSS)을 알립니다.• None 음악 앱은 현재 재생 중인 음악을 일시정지 혹은 정지합니다.• None 라디오 앱은 재생을 시작합니다.• None 라디오 앱은 재생이 끝나면 사용한 AudioFocus를 반환합니다.지금부터 위에서 사용된 요소들에 대해 간단히 살펴보겠습니다.• None : Audio Focus를 요청하거나 해제할 때 사용하는 Android Audio 관리를 위한 핵심 시스템 서비스 클래스• None : Audio Focus 요청에 대한 상세를 가진 클래스• None : Audio Focus 상태가 변경될때 호출받을 Callback 인터페이스• None : Audio Focus를 획득 요청하며, 획득 유무 결과를 반환• None : 생성 시, 필수로 필요합니다. focus를 요청 시, 어떤 용도&목적을 가지는지를 의미합니다. 사용시간이 길거나 예상되지 않을 경우, 다른 앱에게는 영구적인 정지를 요청하고 싶은 경우 짧게 사용하며 다른 앱에게 Ducking(Volume down)을 요청하고 싶은 경우 짧게 사용하며 다른 앱에게 Mute혹은 정지 등을 요청하고 싶은 경우• None• None 획득한 Audio Focus를 해제, 해제 결과를 반환(실제 시스템에 문제가 있어 예외가 발생하는 경우를 제외하면, 항상 성공)• None 직전에 AudioFocus를 가지고 있던(현재는 AUDIOFOCUS_LOSS_TRANSIENT_XXX 상태) 로 Focus를 넘겨준다.• None 타 앱의 AUDIOFOCUS_GAIN 요청에 의해 Focus를 완전히 잃은 경우 타 앱의 AUDIOFOCUS_GAIN_TRANSIENT or AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE 요청에 의해 일시적으로 Focus를 잃은 경우 타 앱의 AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK 요청에 의해 일시적으로 Focus를 잃은 경우 * AUDIOFOCUS_LOSS(_XXX) 상태에서 Focus를 가진 앱이 Focus를 반환한 경우 * AudioFocus 요청이 Delay된 이후 획득한 경우API 문서에는 없는 것들1. AudioFocus 요청은 언제 실패하나요?를 통해 Audio Focus를 요청한다고 해서 항상 성공하는 것은 아닙니다.시스템은 다양한 이유로 요청을 거부할 수 있으며, 이 경우 반환값으로 가 전달됩니다.이러한 실패는 흔치 않지만, 앱이 안정적으로 오디오를 재생하려면 반드시 실패 케이스에 대한 예외처리 필요합니다.1. 특별한 권한을 가진 앱이 Audio Focus를 사용 중인 경우우리는 앞서 이 상황을 전화 시나리오에서 확인했습니다. 전화는 Android 시스템에서 특수하게 처리되는 오디오 사용 케이스입니다.통화가 시작되면(ringtone이 울리면), 시스템은 내부적으로 Audio Focus를 잠금(Lock) 상태로 전환하며, 일반 앱의 Audio Focus 요

로컬 프로필, 당근에서 다루는 업체의 단위안녕하세요. 당근 로컬 비즈니스 실에서 백엔드 엔지니어로 일하고 있는 Bruno(브루노)예요.당근에서 업체 관련 서비스를 이용해 본 적 있으신가요? 당근은 중고 거래 서비스로 많이 알려졌지만, 그 외에도 동네 업체들을 연결하는 다양한 지역 기반 서비스를 운영하고 있어요. 저는 그중에서도 당근 내 서비스들이 동네 업체 를 잘 다룰 수 있도록 지원하는 플랫폼 서비스를 담당하고 있는데요. 그 중심에 있는 기능이 바로 로컬 프로필 이에요.로컬 프로필은 당근 내에서 업체를 표현하는 가장 기본적인 단위예요. 홈 탭에서 보이는 동네 업체 소식이나 에어컨 청소·용달 같은 예약·견적 서비스, 동네 지도 탭에서 확인할 수 있는 업체들까지 업체 로 보이는 대부분의 기능은 로컬 프로필 이라는 도메인을 기반으로 하고 있어요.저희는 로컬 프로필을 구성하기 위해 정보들을 다양한 방법으로 수집하고 있는데요. 이번 글에서는 정보들을 어떻게 취합하고 그 과정에서 어떤 문제들이 발생했는지, 그리고 그 문제들을 어떻게 풀어가고 있는지 소개해 보려고 해요.로컬 프로필의 생성과 중복로컬 프로필은 크게 세 가지 방식으로 생성돼요.사장님이 업체를 직접 등록한 경우유저가 제안하여 생성된 경우외부로부터 수급한 정보로 생성된 경우전국의 모든 사장님이 당근에 업체를 등록해 주시면 가장 좋겠지만 현실적으로 쉽지 않아요. 그렇다고 사장님이 등록해 주신 업체만으로는 당근 내의 다양한 업체 서비스들을 충분히 지원하고 유저에게 만족할 만한 탐색 경험을 제공하기는 어려워요. 그래서 제안과 외부 수급이라는 방식을 통해 더 많은 수의 업체 정보를 확보해 왔어요.유저 제안은 유저들이 업체를 사장님 대신 당근에 등록하는 기능이에요. 그런데 만약 유저 제안으로 로컬 프로필이 생성된 뒤, 사장님이 업체를 당근에 등록하려고 하시면 어떻게 될까요? 같은 업체가 여러 개 노출된다면 사용자들은 큰 혼란을 느끼게 되겠죠.그래서 우선 로컬 프로필이 중복으로 생성되지 않도록 방지하는 장치를 마련했어요. 예를 들면, 사장님이 프로필을 중복으로 생성하려는 경우에는 유사한 로컬 프로필을 미리 탐지해 보여드려요. 직접 프로필을 관리하실 수 있도록 연결해 드리는 거죠.다만 수많은 경로에서 로컬 프로필이 생성되고 수정되다 보니, 위 장치만으로 모든 중복을 방지할 수는 없었어요. 그래서 사전에 프로필이 중복으로 생성되는 것을 방지하는 걸 넘어, 중복으로 생성된 프로필을 탐지하고 처리하는 기능이 필요하다고 판단했죠.중복의 해결책, 병합로컬 프로필의 중복을 탐지하면, 중복된 프로필 목록을 구할 수 있어요. 그 목록에서 대표로 삼을 프로필을 하나 선정하고, 나머지 프로필들을 대표 프로필로 병합하는 방식으로 중복을 처리했어요. 아래와 같은 병합 시스템을 기반으로, 다양한 경로로 업체 정보를 수집하면서도 중복 로컬 프로필을 제거할 수 있었어요.병합의 기본 정책은 아래와 같아요.대표 로컬 프로필은 노출하고, 병합된 로컬 프로필은 미노출한다.병합된 프로필로 접근하는 경우, 대표 프로필로 연결한다.그런데 이렇게 프로필을 병합하다 보니 아쉬운 점이 하나 발견됐어요. 병합되어 미노출되는 프로필에 더 좋은 정보가 담겨 있는 경우가 종종 있었어요. 예를 들어 병합된 프로필에 기재된 전화번호가 최근에 업데이트된 전화번호였던 거죠. 단지 대표 프로필로 선정되지 않았다는 이유로 최신의 정보가 사용자에게 노출되지 않은 셈이에요.앞으로 데이터가 많아질수록 이런 경우가 더 자주 발생할 거라고 생각했어요. 그렇다고 최근에 업데이트된 프로필만을 대표 프로필로 선정하는 것도 답은 아니었어요. 데이터 항목별로 좋은 데이터를 가진 경우가 달랐고, 기존의 대표 프로필이 전반적으로 좋은 정보를 더 많이 포함할 가능성이 높았기 때문이에요. 이런 상황에서 여러 프로필에 흩어진 좋은 정보들을 대표 프로필로 잘 모으려면 어떻게 해야 할까요?고도화된 정보 수집, Composite Snapshot개발자라면 누구나 익숙한 도구인 git에서 해결의 실마리를 찾았어요. git에서는 각 브랜치가 자신만의 변경 이력(commit)을 갖고 있어요. 변경 이력을 기반으로 여러 브랜치를 하나의 메인 브랜치에 병합하면서도 필요한 변경 사항만 잘 추려서 최종 코드를 만들어낼 수 있죠. 아래와 같은 도식처럼 말이에요.이 구조를 보고 문득 이런 생각이 들었어요. 로컬 프로필이 변경될 때마다 이력을 남길 수 있다면, 병합된 프로필에 있는 양질의 정보를 선별하고 대표 프로필에서 보여줄 수 있지 않을까? 기존에도 변경 이력을 저장하긴 했지만, 일부 데이터에 대해서만 저장하고 있었거든요. 게다가 변경 이력을 토대로 대표 프로필의 데이터를 산정할 만큼 신뢰성이 있지도 않았고요.신뢰성 있는 변경 이력을 남기기 위해 가장 먼저 로컬 프로필이 변경되는 절차를 통일했어요. Local Profile Mutation이라는 객체를 만들고, 이 객체를 통해서만 모든 로컬 프로필이 생성되고 변경되도록 제약했어요. 그러자 로컬 프로필이 변경될 때마다, 변경 이력도 자연스럽게 일관된 형태로 저장됐어요. 변경 이력에는 변경 시점, 변경 소스(액터, 유즈케이스 등), 변경 값 등의 항목들을 포함하도록 해, 병합 문제를 해결할 수 있는 기반으로 삼았어요.그렇게 쌓인 변경 이력을 기반으로 가장 좋은 데이터를 대표 프로필에 반영하는 로직을 만들었어요. 병합 관계에 있는 모든 로컬 프로필의 변경 이력을 조회하고 그중에서 가장 좋아 보이는 변경 값을 선별했어요. 변경 값을 선별하는 데에는 변경 시점과 변경 소스를 사용했고요. 그렇게 선별된 데이터를 모아 Snapshot을 구성하고 대표 로컬 프로필에 반영했어요. 이 방식을 통해 가장 합리적인 데이터가 어느 프로필에 있든 대표 로컬 프로필에 보이도록 만들었어요.Composite Snapshot, 데이터 선정 정책조금 더 자세히 들여다보면, 각 프로필의 변경 로그들은 변경 시점을 기준으로 정렬된 뒤 필드별로 Snapshot Candidate로 변환돼요. 그리고 필드 별로 정의된 정책들에 의해 가장 합리적인 값을 선정해요.Snapshot Candidate 목록에서 스냅샷 값을 선정하는 로직은 R

• ’에이전틱 AI’ 주제로 AI 도구**, 바이브코딩 활용한 사내 해커톤 개최**• 전 직군 대상으로 확대**, 75개 팀·250명 참가… 참여율 전년 대비 50% 증가**카카오(대표이사 정신아)가 26일 경기도 용인에 위치한 '카카오 AI 캠퍼스’에서 사내 해커톤 '2025 10K’를 개최한다고 밝혔다.‘해킹’과 ‘마라톤’의 합성어인 해커톤은 개발자와 서비스 기획자들이 개인 또는 팀으로 참가해 특정 주제를 해결하거나 각자의 아이디어를 프로토타입(시제품)으로 구현하는 개발 경연대회다. 카카오는 2013년부터 ‘크루(임직원)를 위한 24시간’이라는 의미의 ‘24K’라는 이름으로 매년 사내 해커톤을 진행해왔다.카카오는 AI를 활용해 짧은 시간 안에 더 높은 생산성을 경험하는 새로운 협업 방식과 개발 문화를 사내에 전파하고자 이번 해커톤을 기획했다. 이를 위해 해커톤 개최 이래 처음으로 AI 기반 개발 방식인 ‘바이브 코딩(Vibe Coding)’을 도입했으며, 기존 24시간에서 10시간으로 진행 시간을 대폭 축소해 진행한다. ‘바이브 코딩’이란 자연어로 명령하면 AI가 코딩 작업을 대신해주는 새로운 프로그래밍 방식이다.또한, 이번 10K는 AI를 적극적으로 활용해 아이디어를 빠른 시간 안에 MVP(최소 기능 제품)로 구현하는 데 초점을 맞췄다. 참가자들은 다양한 AI 도구를 활용해 3시간 단위의 짧은 개발 스프린트를 반복하며 아이디어를 프로토타입(시제품)으로 만들고, 최종 결과물을 내기까지 기존 방식보다 2배 이상 빠른 속도로 프로젝트를 진행하게 된다.개발 과정뿐 아니라 심사 과정에도 AI가 참여한다. AI 모델이 1차 개발 스프린트 후 진행되는 MVP의 완성도를 평가하며, 해당 점수가 최종 심사 점수에도 반영된다.바이브 코딩 도입으로 올해는 개발자뿐 아니라 기획, 디자인, 비즈니스 등 다양한 직군의 크루들이 10K에 참여했다. 총 75개 팀, 250여 명이 참가해 지난해 대비 50% 이상 참여율이 증가하는 등 높은 관심을 나타냈다.정규돈 카카오 최고기술책임자(CTO)는 “이번 사내 해커톤은 AI 도구를 동료삼아 누구나 자신의 아이디어를 최종 프로덕트로 구현해보는 경험을 제공하고자 기획됐다” 며 "AI 네이티브 기업을 지향하는 카카오의 비전처럼, 이번 해커톤이 일상 속에서 AI와 협업하는 새로운 개발 문화의 출발점이 되길 기대한다” 고 말했다.• 카카오의 Next AI를 만들어가는 경험톤&해커톤(24K)