HashiCorp Vault는 민감한 자격 증명, API 키, 암호화 키 등을 안전하게 저장하고 접근 제어를 제공하는 비밀 관리 시스템입니다.그중에서도 SSH Secrets Engine은 SSH 접속을 보다 안전하게 제어할 수 있도록 지원하는 기능으로, OTP 방식 또는 SSH 인증서 서명 방식으로 서버 접근을 중앙에서 관리할 수 있습니다.이번 포스팅에서는 Vault에 SSH Secrets Engine을 OTP 방식으로 서버에 접근하는 방법에 대한 내용을 다룹니다.• None vault를 개발 모드로 구동하는 옵션• None 미리 준비된 설정으로 서버를 구동하며, 모든 데이터는 In-memory에 저장 됨.• None 서비스는 Localhost로 Listen되고, TLS를 사용하지 않으며, unseal 상태로 구동되기 때문에 별도의 잠금 해제 과정 필요 없음.• None 다만, 테스트 환경에서만 사용하고, 사용 환경에서는 사용하지 않도록 해야 함.• None Vault 사용을 위해 개발 모드 실행 시, 생성된, Root token으로 로그인 수행• None 별도 로그인 대신에, VAULT_TOKEN 환경 변수에 token 값을 선언해서 사용하는 것도 가능• None secrets enable로 Secret Engine을 활성화합니다.• None -path 옵션을 이용해서, 마운트 지점을 설정하는 데, 이는 SSH Secret Engine이 사용할 논리 경로• None -path 옵션을 사용해서, 서로 다른 설정을 여러 번 마운트 가능 예를 들어서, 이번 포스팅에서 다루는 SSH 인증서 방식과 다음 포스팅에서 다룰 OTP 인증서 방식을 각각 구성 가능• None Vault Security Engine에 OTP를 Key로 사용하기 위한 역할(Role)을 생성• None cidr_list=0.0.0.0/0 은모든 IP 주소에서 접속 가능하도록 허용SSH Client가 OTP 요청을 위한 정책 설정• None• None SSH Client가 Vault를 통해 OTP를 생성하거나 조회할 수 있도록 허용• None• None SSH Client가 발급받은 OTP의 리스(Lease)를 수동으로 종료할 수 있도록 허용Vault에서 Username & Password 인증 방식을 활성• None Vault에 인증을 userpass 인증 방식이 되도록 활성화 하고, 계정 및 계정에 적용되는 정책을 할당• None 실제 보안상 좋은 방법은 아니기 때문에 상용에서는 다른 인증 방식 활용하는 것이 좋음.• None Vault-ssh-helper은 PAM을 통해 Vault와 연동하여 OTP 기반 인증 처리를 위한 도구• None 최신 vault-ssh-helper 바이너를 다운 받아서, 사용 할 수 있도록 준비• None SSH 로그인 시에, PAM 호출에 따라 Vault에 OTP 검증 요청을 전달하는 역할• None SSH Server가 Vault 서버와 통신하고, OTP 인증 요청을 처리할 수 있도록 설정 파일을 작성• None allowed_roles : 이 서버에 접근 가능한 역할Vault를 통한 인증을 위해 vault-ssh-helper를 PAM(PAM: Pluggable Authentication Module)에 추가• None OpenSSH 서버의 PAM 설정 파일(/etc/pam.d/sshd)에 vault-ssh-helper를 인증 방식으로 등록sshd 설정에서 Vault OTP 인증을 위해 다음을 설정• None SSH 설정에서, Vault OTP 인증을 위해 다음의 값을 설정• None Vault Server에 연결하기 위한 환경 변수 설정 및 ID/Pass로 로그인• None Vault의 SSH Secrets Engine에 OTP 발급 요청• None SSH Secrets Engine이 마운트 된 경로를 지정하고, 접속하고자 하는 서버의 IP를 지정하면, 아래의 출력 결과의 예시와 같이 (OTP) key가 발급 됨.• None SSH 명령어로 서버에 접근하고, Password에 발급된 OTP Key를 입력하여 서버 접속• None OTP Key를 발급 받고, 입력하는 과정 없이 서버 접속 자동화 수행 가능• None OTP Key는 기본 값으로 768시간이 유효• None OTP는 일회성 인증 수단으로 사용해야 하기 때문에 유효 시간을 짧게 조정 필요.• None OTP Key의 유효 시간을 조정하기 위해서 Vault Server에서 다음과 같이 설정• None OTP를 받은 발급 받은 이후에 유효 시간(lease_duration : 1분) 이후 서버 접속 시에 접속이 불가함.• None OTP 발급 이후에 유효 시간 내에 접속을 시도해야 정상 접속 가능

LINE 앱은 전 세계 많은 사용자들이 이용하는 다양한 실시간 커뮤니케이션 서비스를 제공하고 있습니다. 저희 팀은 그중에서 1:1 통화와 그룹 통화, LINE 미팅과 같은 통화 서비스를 맡고 있으며, 각 기능들이 안정적으로 작동해 사용자에게 좋은 품질 경험을 제공할 수 있도록 지속적으로 기술 개선에 힘쓰고 있습니다.이번 글에서는 LINE 통화의 품질을 높이기 위해 적용하고 있는 다양한 기술 중 하나인 네트워크 적응 기술을 개선한 사 례를 소개하려고 합니다.LINE 통화나 라이브 스트리밍과 같은 실시간 커뮤니케이션 서비스에서는 음성이나 영상 등의 미디어 데이터가 인터넷을 통해 패킷 단위로 사용자 간에 전송됩니다. 이때 패킷들은 네트워크를 통해 상대방에게 전달되는 과정에서 전송이 지연되거나 손실될 수 있으며, 이는 실시간 통신 품질을 떨어뜨리는 주요 원인이 됩니다.지연이나 패킷 손실로 인한 품질 저하를 최소화하려면 네트워크 적응 기술을 적용해야 합니다. 네트워크 적응 기술이란 네트워크의 상태에 따라 전송 비트레이트(bitrate)나, 전송 타이밍, 미디어 품질 등을 실시간으로 조절해 끊김 없이 통신할 수 있게 해주는 기술들을 의미하며, 현재 LINE 통화 품질에 큰 영향을 미치는 기술 중 하나입니다.그런데 LINE 통화에 적용된 네트워크 적응 기술은 다른 실시간 서비스들에 적용된 기술과는 조금 차이가 있습니다. 예를 들어 한 방향으로만 데이터를 전송하는 라이브 스트리밍에서는 어느 정도의 버퍼링을 통해 지연을 감수하면서도 안정적인 품질을 유지할 수 있습니다. 영상이 몇 초 늦게 도착하더라도 시청자는 큰 불편을 느끼지 않을 수 있기 때문입니다. 반면 LINE 통화와 같은 양방향 실시간 통신에서는 상대방의 말이 1초라도 늦게 들리면 자연스러운 대화가 어렵습니다. 이 때문에 네트워크 상태에 따라 즉각 반응하는 전송 제어가 필요합니다. 더 민감하고 정교한 네트워크 적응 기술이 요구되는 것입니다.네트워크 적응 기술 중에서 특히 중요한 것이 '네트워크 혼잡(network congestion)'을 효과적으로 회피하는 기술입니다. 네트워크 혼잡이란 네트워크 경로에 패킷이 과도하게 몰리는 상황을 말합니다. 아래 그림과 같이 입력이 출력보다 더 커지면 네트워크가 패킷을 원활하게 처리하지 못하며, 이로 인해 패킷이 네트워크 큐에 누적되면서 점진적으로 지연이 증가하고 결국 패킷 손실로 이어집니다.이런 상황이 발생하는 것을 방지하기 위해 사용하는 기술이 바로 '혼잡 제어(congestion control)'입니다. 혼잡 제어는 네트워크가 혼잡할 때 전송 속도를 조절해 지연과 손실을 줄여서 안정적인 품질을 유지하기 위한 기술입니다. 네트워크 상태는 시간에 따라 빠르게 변화하기 때문에 영상 통화처럼 큰 대역폭이 필요한 서비스에서는 혼잡 제어 성능이 영상 재생 품질에 큰 영향을 미칩니다.제가 이번 글에서 소개하고자 하는 내용은 LINE 통화의 지표를 분석하던 중 발견한 이상 패턴의 원인을 분석하고, 이를 개선하기 위해 LINE 통화의 혼잡 제어 기술을 개선한 이야기입니다.LINE 통화의 지표 분석 중 발견한 이상 패턴과 발생 원인먼저 LINE 통화의 혼잡 제어 기술을 개선하게 된 계기를 구체적인 데이터와 함께 살펴보겠습니다.

안녕하세요. SK플래닛에서 Web3 서비스의 백엔드를 담당하고 있는 원준수라고 합니다. ChatGPT를 사용하면서 겪었던 불편함을 해결한 경험을 공유하고자 합니다. GPT와 대화를 계속해서 진행하다 보면, GPT의 응답이 길어지면서 이전에 했던 질문과 그에 대한 답을 찾는데 스크롤을 많이 올려야 하는 상황이 많이 발생하였습니다. CTRL+F를 통해서 키워드 검색을 하려고 하더라도 해당 키워드가 너무 많았기 때문에 역시 질문에 대한 히스토리를 찾는 것에 불편함을 느꼈습니다. 위 상황을 개선하고자 크롬 익스텐션을 개발하여 문제를 직접 해소한 경험을 공유하고자 합니다.문제가 무엇이고 어떻게 문제를 해결할 것인가?• 내가 한 질문에 대한 모음을 찾아보고 싶음• GPT와의 대화가 길어지면서 이전 질문에 대한 답변을 찾아보는 게 어려움• 내가 질문한 모음을 한눈에 파악할 수 있는 UI 구성• 질문했던 내용으로 바로 이동 가능한 기능 구성• 내가 한 질문에 대한 모음 보기 - 지금까지 했던 질문들을 한눈에 볼 수 있는 페이지를 구성하였습니다.• 이전 질문에 대한 답변 바로가기 - 이전 질문을 클릭하면 해당 질문으로 바로 이동하도록 구성하였습니다. 작성한 크롬 익스텐션을 정식으로 등록해 보겠습니다. Chrome Web Store Developer Dashboard에 접속해 스토어 등록정보를 작성하고 구글의 승인을 기다리면 됩니다. 해당 확장 프로그램의 경우 사용자의 정보를 필요로 하지 않기 때문에 하루만에 승인이 났습니다.아이디어를 GPT에게 제공하여 빠르게 프로그램을 구현할 수 있었습니다. AI 덕분에 아이디어를 실체화하는 속도가 빨라진 것을 느꼈고, 더 잘 사용해봐야겠네요.

안녕하세요. 토스 ML Platform 팀에서 다양한 ML 서비스를 위한 플랫폼을 개발하고 있는 우종호, 송석현입니다.토스에는 다양한 비즈니스 도메인에 걸쳐 수많은 ML 기반 서비스가 존재합니다. 신용평가, 이상거래탐지, 마케팅 최적화, 고객 경험 개선 등 서비스마다 요구하는 ML 컴포넌트도 각양각색입니다. 이러한 서비스들이 빠르게 실험하고 안전하게 배포되기 위해서는 안정적이고 유연한 MLOps 플랫폼이 필수적이죠. 저희 팀은 이러한 요구를 충족시키기 위해 Feature Store, Model Registry, Training Pipeline, Model Serving 등 핵심 구성요소들을 오픈소스 및 자체 개발하여 구축하고 있습니다.이번 시리즈에서는 그 중에서도 특히 모델 학습과 Feature 관리에 핵심이 되는 Feature Store와 이를 활용한 학습 파이프라인 자동화를 위한 도구인 Trainkit을 소개해드리며, ML 실무 환경에서 반복되는 문제들을 어떻게 체계적으로 해결해 나가고 있는지를 공유드립니다.이 글을 통해 ML 플랫폼을 직접 설계하거나, 조직 내 MLOps 체계를 고민하고 계신 분들에게 조금이나마 실질적인 인사이트를 드릴 수 있기를 기대합니다.ML 모델을 서비스로 운영하는 과정은 단순히 모델을 개발하는 것에서 끝나지 않습니다. 데이터 수집, Feature 관리, 학습 파이프라인 구성, 모델 배포, 모니터링 등 모델 전 생애주기를 안정적이고 일관되게 운영할 수 있는 체계가 필요합니다. 이러한 과정을 자동화하고 재현 가능하게 만드는 것이 바로 MLOps의 핵심이며, 이는 ML 서비스의 실질적인 성능과 운영 효율성을 좌우하게 됩니다.토스 ML Platform 팀은 그 중에서도 모델 학습과 Feature 관리를 정형화하고, 학습-서빙 간 불일치(Training-Serving skew)를 방지하며, 실험 효율성을 극대화하기 위해 Feature Store와 Trainkit을 자체적으로 개발해왔습니다.이 도구들은 단순한 기술적 구현을 넘어서, ML 개발의 일관성과 재현성을 보장하고 조직 전체의 협업 효율을 높이는 기반 인프라로써 자리 잡아가고 있습니다.위 다이어그램은 모델을 서비스에 반영하는 과정에서 Data Engineer, Data Scientist, ML Engineer들이 수행하는 작업과 모델 학습, 서빙, 모니터링 사이에서 Feature Store 가 어떻게 상호작용하는지를 보여주고 있습니다. 만약, Feature Store가 없다면 DE, DS, MLE 들은 서로의 정보를 구두로, 수작업으로 일일이 맞춰야하며 이로인해 휴먼 에러의 발생률이 높아질 수 있어요.Feature Store는 단순히 Feature를 저장하는 창고 이상의 의미를 가집니다. 그것은 곧 “ML에서 데이터 품질과 일관성을 보장하는 데이터 기반의 소프트웨어 시스템”이며, Feature Store는 MLOps 아키텍처에서 아래와 같은 중심적인 역할을 수행합니다:왜 Toss에 Feature Store가 필요한가요?토스는 다양한 도메인에 걸쳐 수십 개의 ML

에이닷 QE팀은 에이닷 서비스 내 LLM 품질을 확인하기 위해 SPeCTRA 를 도입 하였습니다. SPeCTRA는 LLM Testing을 위해 품질 기준을 제시하고 평가하는 방법입니다.해당 글을 읽기 전 아래 SPeCTRA가 무엇인지에 대해 먼저 읽어 보신다면 이 글을 읽으실 때, 더욱 이해가 잘 되실거라 생각합니다.• None 효과적인 LLM 품질 평가 : 도구, 기준, 그리고 적용기 톺아보기(SPeCTRA)이번 포스팅은 SPeCTRA 검증 방법이 시작된 에이닷이 아닌, 다른 서비스에서 LLM 품질을 측정하고 검증한 SPeCTRA 확장의 여정을 소개하려고 합니다.• None 채팅플러스 PC 버전에 LLM을 이용한 신규 서비스가 아래와 같이 도입 되었습니다.• None 새 메시지 작성 : 사용자의 키워드(요구사항)를 참조하여, 문자 메시지 초안을 생성해주는 기능• None 답장추천 : 사용자의 대화 내용/정보를 바탕으로 답장을 자동 생성해주는 기능• None 수정제안 : 사용자가 입력한 메시지를 분석하여 어색한 문법 등 수정/제안해주는 기능• None AI 플래너 : 최근 문자 맥락 기반으로, 사용자가 f/u해야 할 주요 일정 및 Task를 정리해주는 기능LLM이 응답을 생성하여 제공하는 서비스므로 품질 항목과 측정 가이드 등이 필요 하였고, 에이닷에서 1년넘게 LLM 품질을 책임지고 있는 SPeCTRA를 에이닷 외 서비스에 처음으로 도입하게 되었습니다.모델 LLM 응답 품질 검증에 Focus를 맞췄기 때문에, 검증 Plan을 세울 때 아래 요소를 중점적으로 생각하였습니다.• None LLM 품질 Test를 진행할 때 가장 많은 리소스가 사용 되었습니다.• None 각 기능 별 특성에 맞춘 TC 생성이 필요하며, 측정 항목에 적절한 Data를 input 하는게 중요하다고 생각하였습니다.• None LLM 특성 상 수정 후 사이드 이펙트 이슈가 어디서 발생할 지 예측이 어려운 부분이 있기 때문에 TC 난이도를 상/중/하로 나눠 검증 차수 별 비교/확인이 가능하도록 만들었습니다.• None 서비스 주요 기능인 Style(톤) 에 대한 검증 커버리지 확보를 위해 다양한 관계/대화를 기반으로 생성하였습니다.• None 평가항목/기능에 따라 TestCase 설계에 LLM을 참고하여 작성하였습니다.• None 효율적으로 리소스를 save 하고 더 많은 커비리지를 확인하기 위해 자동화를 고려하였습니다.• None 모델 응답에 대한 품질을 검증하는 것으로, API 호출/응답을 통해 TC 수행/평가로 진행하였습니다.• None LLM API 호출 통해 응답 받고, SPeCTRA Judge 모델에 해당 값을 Input 하여 Judge 모델이 평가한 항목 별 점수를 확인• None 각 기능 별 LLM Input에 사용되는 DATA가 달랐기 때문에, 기획/개발과 논의를 통해 API 규격/값 검토• None 실제 클라이언트 호출 동일 API를 사용하였고, request 되는 값 또한 클라이언트 환경과 동일 input 되도록 설계• None 각 기능 별 Bulk TC를 각 API 호출하여 응답을 받습니다.• None LLM 호출 Input Prompt와 LLM Response 값을 Judge API로 Input 하여 SPeCTRA 평가 점수 확인• None• None API 응답 내 값 파싱으로 추가 필요 정보 결과 정리 가능이번 프로젝트에서는 각 기능 API와 Judge API, 그리고 Google Sheet API까지 하나의 Postman Collection 안에 통합하여 구성했습니다.총 호출 API 개수는 10개 이상이었지만, Postman의 Test Scripts 기능을 적극 활용하여 한 번의 실행으로 모든 테스트 케이스(TC)를 수행할 수 있도록 구현했습니다.Postman에서는 각 Request에 대해 Pre-request Script와 Test(혹은 Post-response Script) 를 작성할 수 있습니다.이는 JavaScript로 구현 가능하며, 다음과 같은 특징이 있습니다.• None• None 해당 API를 호출하기 전에 실행됩니다.• None 예를 들어, API 호출에 필요한 값을 환경 변수에 세팅하거나, 인증 토큰을 미리 발급받는 로직을 작성할 수 있습니다.• None• None API 응답(Response)을 받은 후 실행됩니다.• None 응답 데이터의 검증, 다음 API에서 사용할 데이터 추출, 테스트 결과 로깅 등 다양한 후처리가 가능합니다.• None• None Excel 내 기능별 TC에 맞는 API 호출 되도록 셋팅• None 이전 API 응답에서 가져온 데이터를 가공하여 다음 요청에 반영• None• None 다음 API 실행을 위한 데이터 저장이러한 방식으로 Postman Collection을 구성하면, 복잡한 API 테스트를 단 한 번의 실행으로 일괄 수행할 수 있습니다.이 구조를 활용해, 하루에 모든 기능 API 호출 → 결과 검증 → 평가 데이터 Google Sheet 기록까지 자동화로 구현/수행하였습니다.덕분에 테스트 효율성이 크게 향상되었고, 반복 작업에 소비되는 리소스를 획기적으로 줄일 수 있었습니다.SPeCTRA 평가 항목은 LLM 응답 답변 품질을 확인하는 요소가 고려되어 만들어졌기 때문에, 에이닷에서 사용하던 SPeCTRA 평가 항목을 동일하게 사용하였습니다.단, Judge로 사용하던 Prompt는 서비스에 맞게 재구현이 필요하였습니다.• None 에이닷에서는 Unsafe로 판단하는 Input이 있을 경우, 죄송합니다와 같이 요청에 대해 응답을 주지 않는게 기대결과 입니다. 그러나 채팅플러스는 사용자가 입력한 키워드를 기반으로 사용자에게 제안을 하는 형태이므로 응답을 주지 않는게 아닌, unsafe한 키워드를 제외한 표현으로 Response를 생성하는 부분이 기대결과 였습니다. (4개 기능 각각 로직 상이함)• None 에이닷 응답은 한개의 일관적인 응답 톤스타일을 보이지만, 채팅플러스는 맥락, Tone Style에 따라 생성하는 어투가 상황에 맞춰 변경 응답해야함해당 이유로 Judge Prompt를 서비스에 맞게 변경 하였으며, 이 부

안녕하세요! 네이버 프런트엔드 개발자 모임 H26y입니다.매달 FE News를 통해 찾아뵈었는데요, 8월 29일(금), [FE Ground] AI × Front-End: 코딩의 미래를 묻다. 라는 주제로 첫 공개 개발자 밋업을 진행하게 되어 안내드립니다.진행일시일시: 8월 29(금), 19시 ~ 21시건물 보안 지침 상 사전 입장이 불가하며, 19시 부터 입장이 가능합니다.장소: NAVER D2SF 강남 (삼성화재 서초타워 18층)[참고] 간단히 저녁 식사 할 수 있는 샌드위치와 음료가 제공됩니다.세션안내19:00 ~ 19:10 입장 & 오프닝19:10 ~ 19:25 AI 도구로 2배 속도 내는 프론트 개발팀 만들기 / 장기효19:25 ~ 19:45 우리가 알고 있는 프로그래밍의 종말: 현실적 AI / 박재성19:45 ~ 20:00 Code Wars: The Last Coder: AI가 코드를 쓰는 세상, 개발자의 역할은 어떻게 바뀌는가? / 차성원20:00 ~ 20:30 패널토론: AI × Front-End: 코딩의 미래는 어떻게 될까?AI 시대, 시니어와 주니어의 성장 경로는 어떻게 달라질까?AI 시대, 프론트엔드 개발자의 역할은 확장되고 있는가?프론트엔드 개발, AI 환경에 수혜자인가 희생자인가?AI 시대에 개발자는 몇명이나 살아남을 것인가?20:30 ~ 21:00 네트워킹 및 행사 종료신청방법다음의 신청폼에 신청 정보를 입력해 주시면, 추첨을 통해 총 50분을 선정할 예정입니다. 결과는 8월 21일(목), 19시 전까지 선정되신 분들께만 개별 메일을 통해 안내 드릴 예정입니다.장소가 한정되어 있어 꼭 참석이 가능하신 경우에만 신청 부탁드립니다.참가 신청: https://naver.me/xHmnbSaz신청기간: 2025년 8월 20일(수), 19:00까지사전안내현장 등록은 불가하며, 사전 신청 및 참가 확정자만 입장 가능합니다.건물 보안 방침에 따라, 1층에서 신청자 확인 후 입장과 인솔을 통해 층 이동이 가능하며, 행사 시간동안 외부 출입과 다른 장소로 이동은 불가합니다.건물 주차는 지원되지 않습니다.건물 관리 방안에 따라 냉방 가동이 되지 않으며, 선풍기가 배치될 예정입니다. 사전 양해 부탁드립니다.세션 및 진행 시간은 사전 고지 없이 변경될 수 있습니다.

benny.ahn 복잡하고 어려운 금융 서비스에 AI를 사용해 사용자 경험을 개선하려는 좋은 시도였다고 생각합니다. Multi-Agent Collaboration 구조와 프롬프트 엔지니어링을 통해 확장 가능한 플랫폼을 설계하여 계속 진화할 수 있는 서비스를 만든 점이 인상적이었습니다.안녕하세요, 채널클랜 PM 하루 / 채널클랜 서버 개발자 데이지, 도리 / 마이데이터클랜 서버 개발자 그릿 / 마이데이터클랜 FE 개발자 아더입니다.카카오페이는 결제, 송금, 혜택, 자산관리 등 여러 서비스를 제공하고 있는데요. 하지만 서비스가 다양하다 보니, 현재 상황에 가장 적합한 서비스를 찾기 어려운 경우가 많았습니다. 이러한 불편함을 해소하고, 사용자가 카카오페이를 더욱 쉽고 편리하게 이용할 수 있도록 하기 위해 저희는 금융 AI 컨시어지 를 기획, 개발했습니다.이 글에서 페이지니의 기획 배경과 주요 기능, 그리고 아키텍처 및 사용한 기술까지 하나씩 살펴보겠습니다.“혹시, 막상 필요한 서비스를 검색하려고 할 때 기억이 나지 않았던 적 있으신가요?” 저희는 늘 카카오페이 사용자 여러분의 목소리에 귀 기울여 왔습니다. 그 과정에서 많은 분들이 카카오페이 앱 내에 정말 다양한 서비스들이 존재하지만, 정작 필요한 순간에 적절한 서비스를 찾기 어렵다는 점을 토로하셨습니다. 수많은 서비스명들이 각기 각색이어서 직관적으로 그 기능을 유추하기 어렵고, 앱을 이리저리 헤매며 시간을 낭비하는 경우가 발생했던 것이죠. 이러한 사용자 경험의 불편함을 해소하고자 저희는 ‘페이지니’ 프로젝트를 시작했습니다. ‘페이지니’는 단순히 사용자가 원하는 서비스를 찾아주는 것을 넘어, 사용자의 현재 상황과 니즈를 미리 파악하여 능동적으로 필요한 서비스를 제안하고, 사용자에게 최적화된 금융 경험을 제공하는 AI 컨시어지 서비스를 목표로 합니다.내 마음을 꿰뚫어 보는 ‘페이지니’, 일상 속 맞춤 혜택을 툭!“지금 근처에 카카오페이 할인되는 카페 있을까?”, “교통카드 잔액이 부족한데…” 이런 생각, 해보셨죠? ‘페이지니’는 여러분이 앱을 굳이 열지 않아도, 현재 상황(위치, 시간, 이용 기록)을 분석해 필요한 정보를 먼저 알아채고 말풍선으로 제안합니다. 미처 몰랐던 유용한 서비스나 꿀팁까지 ‘페이지니’가 콕 집어 알려줄 거예요. 이제 카카오페이 앱 속에서 헤맬 필요 없이 ‘페이지니’의 말에 귀 기울이기만 하면 됩니다.말로 하세요, 글로 쓰세요! ‘페이지니’가 모두 알아듣고 척척 찾아줘요‘페이지니’와 대화하는 게 어렵지 않을까 걱정 마세요.‘페이지니’는 나이, 디지털 숙련도에 상관없이 누구나 가장 편안한 방식으로 자신에게 필요한 서비스나 상황을 자유롭게 이야기할 수 있도록 설계되었습니다. 음성(STT)으로 말하거나, 텍스트로 직접 입력하거나, 추천 질문을 선택하는 등 다양한 방식으로 ‘페이지니’에게 말을 걸 수 있어요. 어떤 방식이든 ‘페이지니’는 여러분의 의도를 정확히 파악하고 가장 적절한 정보를 찾아드립니다.뭐든 물어보세요! ‘페이지니’가 당신의 마음을 읽고 필요한 서비스를 찾아줄게요“고

가족 여행객을 위한 맞춤 정보, 어디서 찾을까?여행을 계획할 때 가장 어려운 부분 중 하나는 우리 가족에게 딱 맞는 숙소를 찾는 것이에요. 특히 아이와 함께 하는 해외여행이라면 더욱 그렇죠. 키즈클럽은 있는지, 수영장 수심은 어느 정도인지, 아침식사는 아이들 입맛에 맞는지… 이런 정보들을 찾기란 쉽지 않아요.FTN 팀 백승빈님도 바로 이 문제를 해결하려고 했어요. 처음 목표는 단순했습니다.“아이를 동반하는 동남아 숙소를 구매하려는 여행자에 집중하자”하지만 고객 피드백을 분석해보니 현실은 녹록지 않았어요.“고객 입장에서는 우리 가족이 가고 싶은 숙소를 찾는 데 쉽게 찾기 어렵고, 가족 조건에 맞는 숙소의 정보를 상세하게 알려주지 않기 때문에 가고 싶은 숙소를 찾기 힘들다는 내용이 많았습니다.”그 과정에서, 고객 각각의 취향과 필요에 맞춘 숙소 추천이 필요하다는 점에 주목하게 되었고, 이에 따라 숙소 상세 정보를 고객 맞춤형으로 제공하자는 아이디어가 시작되었습니다.어린 아이를 동반하는 고객에게 제공하고자 하는 맞춤형 상품 소개글을 실험하기 시작수작업의 한계문제를 해결하기 위해 팀은 우선 22개 나트랑 숙소를 대상으로 상세한 가족 친화 정보를 직접 조사해서 콘텐츠를 만들었어요. 팀원이 하나하나 네이버 블로그와 후기를 찾아가며 수심은 몇 센티인지, 운영시간은 언제인지 꼼꼼히 조사했죠.결과는 놀라웠어요. A/B 테스트에서 이전 대비 50% 이상 전환율이 향상된 거예요!“저희도 이게 진짜 맞는 건가 라는 생각이 들 정도로 엄청난 효과를 보였어요.”하지만 여기서 현실의 벽에 부딪혔습니다. 확장하려고 보니 마이리얼트립에 130여만 개의 숙소가 있었어요.“22개의 숙소 조사하는 데만도 한 개의 숙소를 조사하는데 열시간 정도 걸렸어요. 130만 개의 숙소가 있는데, 단순히 계산해도 1,300만 시간이 필요하다는 정말 암울한 계산이 되었거든요.”마치 손으로 바다를 퍼내려는 것과 같은 상황이었죠. 이때부터 AI를 진지하게 고려하기 시작했어요.AI마다 다른 특성, 협력이 답이다처음에는 당연히 ChatGPT부터 시도해봤어요(2025년 4월 기준). 나트랑 숙소 정보를 주고 아이와 함께 가기 좋은 이유를 물어봤더니 꽤 그럴듯하지만 근거를 제공하지 않고, 근거가 미약하거나 너무 일반적인 답변만을 줘서, 상품상세에 활용하기에는 어려웠습니다.“ChatGPT한테 나트랑 숙소를 알려주면서 아이와 함께 가기 좋은 이유를 질문했더니 답변을 잘 주더라고요. 근데 이게 사실이냐고 물어보니까 신뢰성이 낮은 답변을 제공했어요.”단순히 ChatGPT 에게 질문했을때는 결과가 좋지 않았다그래서 다른 AI들도 테스트해보기 시작했어요. Perplexity를 써보니 ChatGPT보다 훨씬 근거 기반의 결과를 보여주더라고요.“AI마다 다른 특성을 갖고 있는데, Perplexity는 실시간 정보로 명확한 출처를 가지고 정확한 걸 제공하고, Claude는 논리적으로 사고해서 답변을 주더라고요.”이때 떠오른 아이디어가 바로 팀워크였어요. 각자 다른 전문성을 가진 직원들이 협력해서 더 나은 결과물을

안녕하세요! 저는 토스코어에서 CX Product Team 소속으로 프론트엔드 개발을 하고 있는 손연지라고 합니다. 지금까지는 상담 대시보드, 내부 상담 어드민, STT 어드민 같은 CX 인터널 제품들을 주로 개발해왔고, 최근에는 대고객 제품인 고객센터 챗봇 서비스를 맡아 개발하고 있어요.토스 고객센터 챗봇에서 상위 서비스를 선택하면, 그에 맞는 하위 선택 화면으로 전환되면서 여러 개의 버튼이 나타나요. 예를 들어 송금에 대해 문의하면, “송금 한도가 궁금해요”, “송금 한도를 변경하고 싶어요” 같은 버튼들이 새롭게 나타나죠. 어느 날 접근성 관련 피드백을 하나 받았어요. 새로운 메시지가 떠도, 스크린리더 사용자 입장에서는 화면이 바뀌었다는 걸 전혀 인지할 수 없었다는 거예요.실제로 화면이 바뀌었는데도 초점은 그대로 이전 위치에 머물러 있으니, 스크린리더 사용자 입장에서는 새로운 흐름이 시작됐다는 걸 전혀 알 수 없었던 거예요. 이 문제를 해결하기 위해, 눈으로 보면 당연하게 느껴지는 화면의 흐름을, 보지 않아도 자연스럽게 따라갈 수 있는 설계를 고민하게 되었어요.개선 1 — 시각적 UI의 흐름을 초점 이동에 반영하기우선 스크린리더를 쓰지 않는 사용자가 챗봇을 사용할 때의 흐름을 떠올렸어요. 보통은 상위 항목을 누르면 새로운 메시지가 뜨고, 그 아래에 하위 선택 버튼들이 등장하죠. 자연스럽게 시선을 따라가며 다음 행동으로 넘어가게 돼요.스크린리더 사용자에게는 이 시선의 흐름을 초점 이동이 대신 해줘야 해요. 그래서 화면이 바뀌었을 때는 초점도 함께 이동해줘야, 흐름이 끊기지 않을 수 있어요.예를 들어, 안내 메시지가 위에 있고, 버튼이 아래에 있다면 초점은 메시지 → 버튼 → 다음 메시지 순으로 이동해야해요. 그래야 사용자가 “지금 어디쯤이고, 무엇을 해야 하는지”를 놓치지 않게 돼요.개선 2 — 초점 이동 타이밍을 정교하게 조정하기초점만 잘 옮겨주면 해결된다고 생각했는데, 초점이 언제, 어떻게 이동하느냐가 훨씬 더 중요했어요.개선 과정에서 초점을 자동으로 옮기기 위해 를 사용했더니, 브라우저가 해당 요소로 즉시 점프(scroll)해버리면서 기존에 잘 작동하던 챗봇의 부드러운 자동 스크롤scrollIntoView({ behavior: 'smooth' }) 이 무시되는 문제가 생겼어요. 가 강제로 즉시 스크롤을 발생시키면서, 스크롤이 ‘훅’ 튀는 느낌이 되어버린 거죠. 그래서 아래와 같이 흐름을 정교하게 나눠서 구현했어요:• None 스크롤이 어느 정도 끝났을 타이밍(약 1초 후) target.focus({ preventScroll: true })를 호출해서 초점을 이동시켰어요.• None preventScroll: true 옵션 덕분에 초점 이동이 만들 수 있었고요.이렇게 흐름을 나눠서 처리하니, 시각적으로도 자연스럽고 초점도 정확한 위치에 도달했어요. 스크린리더 역시 그 타이밍에 맞춰 끊김 없이 안내를 이어갈 수 있었고요.결과적으로 사용자는 부드러운 스크롤과 또렷한 초점 이동 흐름을 함께 경험할 수 있었어요.텍스트 메시지 아래에 버튼이

토스는 ‘누구나 금융을 쉽게’ 사용할 수 있는 세상을 꿈꿔요. 그래서 제품을 만들 때도, 문서를 쓸 때도, 접근성을 고민합니다. 접근성(Accessibility, 줄여서 A11y)은 모든 사용자가 더 쉽고 편리하게 웹을 사용할 수 있도록 돕는 기본 원칙이에요.개발자분들과 이야기하다 보면, 접근성이 중요하다는 건 알지만 어떻게 시작해야 할지 모르겠다는 이야기를 많이 들어요. 그래서 토스는 실제 개발 과정에서 자주 부딪히는 실수와 핵심 개념을 정리한 접근성 문서 A11y Fundamentals 을 오픈했어요.'접근성은 어려운 것' 이라고 느끼는 분들을 위해 실무에서 바로 적용할 수 있는 접근성의 핵심 개념과 실수하기 쉬운 패턴을 알려줘요. 버튼 안에 버튼을 넣으면 왜 안 되는지, 태그 안에 이 들어가면 어떤 문제가 생기는지, 스크린 리더 사용자는 어떻게 콘텐츠를 읽는지 등을 실제 예시와 함께 알려드려요.프론트엔드 개발자는 HTML 구조를 만들고 인터랙션을 정의해요. 사용자와 가장 가까이에서 웹 경험을 설계하는 만큼, 접근성의 출발점이자 핵심 역할을 맡고 있죠. 그래서 프론트엔드 개발자가 접근성을 신경 쓰면 누구나 이용할 수 있는 웹을 만들 수 있어요.접근성을 왜 지켜야 할까요?장애인, 비장애인, 개발자 모두에게 효용이 있기 때문이에요. 장애인 사용자는 스크린리더 같은 보조기기를 통해 웹사이트를 원활하게 이용할 수 있고, 일반 사용자도 더 빠르고 편리한 웹 경험을 할 수 있어요. 또한 개발자는 더 견고하고 유지보수하기 쉬운 코드를 작성할 수 있어요.장애인에게 필요한 이유버튼의 색상, 아이콘 형태, 레이아웃 배치, 차트나 이미지 같은 웹 상의 시각적 정보를 볼 수 없는 사용자는 어떻게 웹사이트를 이용할까요? 바로 스크린리더 같은 보조기기를 사용합니다. 이때, 올바른 역할( ), 레이블( ), 대체 텍스트( ) 같은 접근성 속성이 제공되지 않으면 원하는 정보를 얻지 못하거나, 버튼·링크 같은 상호작용 요소를 놓쳐 웹사이트 사용에 큰 불편을 겪게 돼요.예를 들어, 단순히 클릭 이벤트만 달아둔 는 스크린리더에서 버튼 요소로 인식되지 않아서 사용자가 해당 기능을 사용할 수 없어요.일반 사용자에게도 유용한 이유접근성을 지키면 장애가 없는 일반 사용자도 웹을 더 빠르고 편리하게 이용할 수 있어요. 익숙한 웹 동작이 자연스럽게 제공되기 때문이에요.예를 들어, 링크( )를 제대로 사용하면 마우스 오른쪽 버튼으로 '새 창에서 열기', '링크 복사'와 같은 동작을 할 수 있어요. 하지만 단순히 나 에 클릭 이벤트만 넣으면 이런 기본 기능을 사용할 수 없어요. 또, 폼을 만들 때 올바른 태그와 , 을 사용하면 사용자가 Enter 키를 눌러 폼을 제출할 수 있어요. 하지만 그렇지 않으면 사용자는 익숙한 동작을 기대할 수 없어요.또, 키보드를 주로 사용하는 사용자는 Tab 키와 Shift+Tab, Enter, Space, 방향키 등으로 웹사이트를 탐색해요. 버튼이나 링크, 폼 요소에 올바른 역할과 포커스가 지정되어 있지 않으면, 키보드로는 해당 기능을 사용할 수 없어