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의 기존 시스템 문법과는 다르죠. 토스 앱만 예외적으로 앞에 읽도록 바꿔버리면, 다른 앱들과의 사용성 일관성이 깨질 수 있다는 우려도 있었어요. 그래서 결국 이 문제는 개별 앱이 해결하기보다, 시스템 차원에서 사용자가 읽는 방식을 선택할 수 있도록 옵션을 제공해야 한다는 결론을 내렸어요.그리고 이 중 두 가지를 정리해 토스에서 어