안녕하세요. 토스 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, 방향키 등으로 웹사이트를 탐색해요. 버튼이나 링크, 폼 요소에 올바른 역할과 포커스가 지정되어 있지 않으면, 키보드로는 해당 기능을 사용할 수 없어

• None 환경 변수 로드: load_dotenv() 함수를 사용하여 .env 파일에 저장된 설정값을 호출• None LLM 초기화: ChatOpenAI 클래스를 이용해 OpenAI의 챗 모델을 초기화temperature=0.0으로 지정하여 일관된 답변을 얻도록 함.• None 가짜 Retriever 정의: RAG 기법(Retrieval-Augmented Generation, 검색 증강 생성)에서 retriever는 질문과 관련된 문서를 검색해 주는 역할을 합니다. 이 예제에서는 간단히 미리 준비된 docs 딕셔너리에 세 개의 문서를 담아 두고, fake_retriever 함수를 통해 항상 상위 3개 문서를 반환하도록 하였습니다. 실제로는 검색 엔진이나 벡터 DB를 활용합니다.• None 최종 답변 파서 정의: FinalAnswerParser 클래스는 LangChain의 BaseOutputParser를 상속며, LLM의 긴 답변 중에서 최종 답변만 추출합니다. parse 메서드에서는 정규표현식(regex)을 사용해 답변 텍스트에서 3. **최종 답변**:으로 시작하는 부분을 찾아내서, 그 이후의 텍스트만 반환합니다. 만약 해당 패턴이 없으면 조금 더 포괄적인 패턴("최종 답변:")을 찾아보고, 그래도 없으면 전체 답변을 그대로 반환합니다. 이 출력 파서를 활용하면 여러 단계로 구성된 답변 중에서도 최종 결론만 손쉽게 얻을 수 있습니다.query 변수에 질문을 문자열로 정의하고, 앞서 만든 fake_retriever를 사용해 관련 문서를 검색합니다.fake_retriever(query, top_k=2)는 미리 준비된 문서들 중에서 상위 2개의 문서를 가져오는데, 여기서는 doc1과 doc2가 사용됩니다. (필요한 경우 doc3은 빈 문자열로 채워집니다)PromptTemplate을 이용해 LLM에 전달할 프롬프트 양식을 만듭니다.이 템플릿에는 세 개의 문서({doc1}, {doc2}, {doc3}) 내용과 사용자 질문({question})이 삽입될 자리표시자가 있고, 그 아래에 [지시사항]으로 모델이 따라야 할 단계별 지침을 작성하였습니다.지시사항에는 1단계, 2단계, 3단계로 나누어 명시하였습니다.이러한 프롬프트 설계는 모델에게 생각의 순서를 제시하는 것으로, 사고의 사슬(Chain-of-Thought) 프롬프팅의 일종입니다.즉, 모델이 답을 바로 내지 않고 먼저 문서에서 중요한 정보를 뽑고, 이를 종합한 뒤 마지막으로 답을 제시하도록 유도하는 것입니다.prompt_easy | llm | StrOutputParser() 구문은 LangChain Expression Language를 사용한 체인 구성입니다.prompt_easy 출력이 곧바로 LLM의 입력으로 들어가고, LLM의 출력이 StrOutputParser()로 넘어가도록 파이프라인을 구성하였습니다.chain_easy.invoke({...})를 호출하여 체인을 실제 실행합니다.이때 딕셔너리 형태로 문서 내용과 질문을 채워 넣으면, 체인이 알아서 프롬프트 생성 → LLM 실행 → 결과 파싱의 단계를 거치게 됩니다.최종적으로 print를 통해 결과를 출력하면, 모델의 사고 과정과 최종 답변이 모두 포함된 텍스트가 출력됩니다.예를 들어, 모델은 1단계에서는 "서울은 대한민국의 수도입니다."와 같은 핵심 정보를 찾아내고, 2단계에서는 추가 정보를 조합한 문장을 만든 뒤, 3단계에서 최종 답변을 제시합니다.LangChain에서 출력을 가공하도록 특정 패턴(즉, '최종 답변' 부분)만을 추출해서 반환하도록 FinalAnswerParser 클래스를 정의하였습니다.6. FinalAnswerParser를 활용하여 최종 답변만 출력7. 비교, 정리하여 답변을 얻기 위한 복잡한 질의• None 예제: '서울의 주요 관광지 3곳과 특징을 알려주세요.'"서울의 주요 관광지 3곳과 특징을 알려주세요."라는 질문에 답하기 위해, 여러 문서의 정보를 비교·정리하여 최종 답변을 구성합니다.• None 질문 이해: 이 질문은 서울의 대표적인 관광지 세 곳과 각각의 특징을 묻고, 한 가지가 아니라 여러 정보를 찾아 종합적으로 정리해야 합니다.• None 문서 검색: fake_retriever(query, top_k=3)으로 세 개의 문서를 모두 불러옵니다. (doc1, doc2, doc3 모두 사용) 각 문서는 서울의 다른 측면(수도 정보, 관광지 목록, 인구와 인프라)에 관한 내용을 담고 있습니다. 모델은 이들 문서를 참고하여 답을 준비하게 됩니다.• None 프롬프트 템플릿 작성: prompt_med 템플릿에서는 상세한 지시사항이 포함됩니다. "문서들을 읽고 단계별로 답하세요."라는 안내 문구로 시작하여, 이어서 문서1~3의 내용과 질문이 제공됩니다.그런 다음 [지시사항]에는:• None 최종 답변을 표 형태로 제시 하라고 합니다. 모델에게 출력 형식까지 구체적으로 지시함으로써, 답변을 표(Table)로 만들어 내도록 유도하고 있습니다.• None 체인 실행: chain_med = prompt_med | llm | StrOutputParser()로 체인을 구성하고, .invoke({...})로 실제 실행하여 결과를 얻습니다.StrOutputParser를 사용하여 단계별로 답변 제출• None **"내부 사고 과정은 출력하지 마세요." **negative 프롬프팅을 통하여 FinalAnswerParser를 사용하지 않고 최종 답변을 도출할 수 있습니다.• None 예제: '서울의 인구, 관광지, 교통 인프라를 종합해 여행하기 좋은 이유를 논리적으로 설명해주세요.'질문은 "서울의 인구, 관광지, 교통 인프라를 종합해 여행하기 좋은 이유를 논리적으로 설명해주세요."로, 서울이라는 도시가 여행하기 좋다는 것을 **여러 측면의 데이터를 근거로 **답변해야 됩니다.• None 문서 검색: fake_retriever(query, top_k=3)를 통해 세 개의 문서를 모두 검색하여 활용합니다. 각 문서에는 서울의 인구, 관광지, 교통 인프라에 대한 정보가 각각 들어있으므로, 이 모두를 고려해야 종합적인 답변을 만들 수 있습니다.• None 프롬프트 템플릿

이 문서는 LLM(Large Language Model) 기반의 대화형 인터페이스 Agent를 기획할 때 필요한 사고방식, 사용자 발화 해석 체계, 설계 전략 등을 구조적으로 정리한 가이드입니다. 기존의 룰베이스 서비스 기획 방식과는 전혀 다른 접근이 요구되며, 기능 수행의 안정성과 사용자 경험의 유연성 사이에서 균형 잡힌 기획이 필요합니다.기존 기획과의 차이점LLM 모델로 인해 대화형 인터페이스의 확장성이 커졌습니다. 반면에 늘어난 자유도 때문에 기획 방식의 변화도 필요한 상황입니다.LLM 모델이 사용자의 무한한 발화 유형에 모두 응답할 수 있지만, 반면에 모든 응답을 기획자가 컨트롤하여 일관된 퀄리티를 유지하기 어렵고 hallucination의 가능성도 배제할 수 없기 때문입니다.따라서 LLM은 단순한 응답 생성기가 아니라, 불완전한 언어적 단서를 기반으로 대화를 완성해나가는 구조로 설계되어야 합니다.이번 글에서는 '사용자 발화 해석'과 의미 추론 방법론 중에 'Clarification 전략'에 대해 다뤄보고자 합니다.사용자가 어떤 발화를 입력해도 LLM은 답변을 생성합니다. 이는 서비스 품질을 낮추는 원인이 되기도 하는데요.Agent가 정확한 의도를 이해하지 못한 채 잘못된 응답을 생성할 수 있기 때문입니다.특히 LLM 동작 방식에 대한 이해가 낮은 사용자라면 발화를 수정하려 시도 하기 보다 서비스에서 바로 이탈하는 선택을 할 것 입니다.사용자의 질문을 명확화(Clarification) 하려면, 우선 왜 불완전한 발화를 입력하는지 알아야 합니다.2. Agent는 충분히 이해 했을까?사용자의 발화를 단순 명령어로 다루기 보다 좀 더 복잡한 해석을 통해 의미와 맥락을 추론해 볼 필요가 있습니다.Agent가 사용자의 발화를 제대로 이해 했는지, 숨겨진 의도는 없는지, 맥락을 보충한다면 좀 더 정확한 응답이 가능할지 살펴보아야 합니다.다음은 Agent가 사용자 발화를 해석할 때 적용할 수 있는 의도 해석 유형 체계입니다.• None• None → 🔁 Agent "업무/개인 중 어떤 일정인가요?" 또는 "이번 주 일정을 보여드릴까요?"와 같이 범위를 명확히 하도록 후속 질문 수행• None• None → ⛔모호 + 세분화 가능성 → 지역명 또는 사람 구분 필요• None → 🔁 Agent 통화 상대, 시점, 내용 범위를 확인하는 clarification 질문과 함께 최근 통화 요약 후보를 제시• None USER "누가 나더러 뭐 좀 해달라고 했는데 기억이 안 나"• None → ⛔불완전 + 의도전이• None → 🔁 Agent 최근 발생한 요청 관련 TODO나 약속 기록을 추론하여 보여주며, 관련 인물/시간에 대한 보완 질문 수행• None → 🔁 Agent 질문 후에 사용자가 해야 할 일을 예측하여 제시하고 관련된 기능의 연결 수행 여부를 확인3. Clarification 전략: 발화를 ‘실행 가능한 프롬프트’로 발전사용자의 발화가 불완전함을 알고 Agent가 이를 어떻게 해석해야 할지 알았다면, 다음으로 명시적인 Clarification 과정을 부여함으로써 성능을 개선할 수 있습니다.Clarification을 위한 Agent의 질문은 기능적 수행 목적(Functional slot filling)과 함께, 불완전한 발화를 의미적으로 풍부한 형태로 전환(Semantic slot filling)하기 위한 전략적 도구입니다.따라서 Clarification은 단순히 관련 질문을 던지는 게 아니라, 사용자 발화를 LLM이 이해하고 실행할 수 있는 구조화된 프롬프트로 변화시키는 목적으로 설계되어야 합니다.Slot은 기능 호출(function call) 시 요구되는 Argument의 일종입니다. (API 호출 할 때의 파라메터 항목과 유사)하지만 LLM 기반 설계에서는 기능적 필수 요구 조건 외에도 의미 해석에 필요한 Slot 구분이 중요합니다.기능 실행을 위한 Functional Slot은 비교적 명확하지만, Semantic Slot은 사용자 발화에 잘 드러나지 않아 의도 해석 과정에서 정책적으로 유도하거나 추론해야 합니다.• None 일정 생성 기능에서 "DATE", "TIME" 은 Functional Slot / "ATTENDEE", "LOCATION" 은 Semantic Slot 구분 가능• None• None → 🔁 Agent "언제로 등록할까요?" mandatory 정보인 날짜를 요청하는 질문은 Functional slot filling을 위한 필수 프로세스• None → 🔁 Agent "참석자/장소 등의 선택 정보에 대한 질문"은 맥락(context)을 보완해주고 후속 Action 설계에 도움이 됨 → 장소추천, 경로검색 등의 후속 시나리오로 연결 가능다음 예시는 사용자 발화의 Intention 해석 유형에 따라 Clarification을 수행하기 위한 흐름과 Agent의 질문 예시 입니다.실제 서비스에 적용할 때는 Clarification은 좀 더 정교한 전략적 설계가 필요하며, Agent의 질문도 여러 단계로 나누어 수행되어야 합니다.특히, 확장 (Expandable) 예시처럼 서비스의 기능적 Feature에 사용자 접근성을 높이고 다양하게 활용해볼 수 있도록 목적성을 가진 채 유도하는 전략이 필요합니다.기능 실행에 필요한 필수 정보가 누락됨 (Functional Slot 미충족) 의도 명확화를 위한 clarification 유도 “시간 확인을 원하시나요, 참석자나 장소 정보가 필요하신가요?” 카테고리 수준의 표현만 존재, 세부 조건 부족 “업무 일정만 보시겠어요?”, “최근 일주일 기준으로 보여드릴까요?” “회의 일정이 궁금하신가요, 아니면 취소되었는지 확인하고 싶으신가요?” “이 일정과 함께 교통편이나 회의록도 확인해보시겠어요?”➕ 기능 실행보다 중요한 건 '의도 이해'기능을 실행할 수 있는 최소한의 정보가 갖춰졌다고 해서, 곧바로 실행하는 것이 항상 좋은 건 아닙니다. 사용자의 말 속에 숨어 있는 더 정확한 의도나 맥락이 무엇인지 이해하는 것이 더 중요합니다.예를 들어 사용자가 "일정 보여줘"라고 했을 때, 단순히 전체 일정을 출력하는 것보다는 사용자가 보고

안녕하세요. LINE Plus의 LINE AI LAB에서 LLM 에이전트 관련 서비스를 개발하고 있는 신수민입니다.저는 지난 7월 도쿄에서 열린 Tech-Verse 2025에 Tech-Verse의 현장을 취재하고 담아오는 'LINE DEV 리포터즈'에 참여하면서 현장에서 LY의 다양한 기술 성과를 직접 보고 들을 수 있는 기회를 얻었습니다.이번 Tech-Verse는 AI가 주요 주제 중 하나로 선정되면서 다양한 서비스 적용 사례가 곁들여진 AI 관련 발표가 정말 많 았는데요. 실무자 입장에서 공감되는 내용도 많았고, '여기서 얻은 것들을 실제 내 업무에 적용해 볼 수 있을까?' 혹은 '이걸 바탕으로 또 어떠한 새로운 서비스를 만들 수 있을까?'라고 스스로에게 질문해 보게 되는 시간이기도 했습니다.이 글에서는 발표 내용을 상세하게 정리하기보다는, 현장에서 실무자로서 인상적이라고 느꼈던 순간들을 중심으로 공유해 보려고 합니다. 혹시 Tech-Verse를 놓치셨다면 Tech-Verse 2025 홈페이지에서 발표 영상과 자료를 제공하고 있으니 꼭 확인해 보세요!행사장으로 가는 길저는 행사 당일 아침, 신주쿠 역 근처 숙소에서 출발해 도쿄 지하철을 타고 LY Corporation(이하 LY) 본사로 향했습니다. 리모트 근무에 익숙한 저에겐 오랜만의 출근이었는데요. 이곳의 출근길 지하철은 서울의 지하철 9호선 출근길이 생각날 정도로 혼잡해서 '아, 이 도시도 출퇴근이 쉽지 않구나'라고 생각하게 만들었습니다. 예상과는 다른 현실을 실감한 순간이었고, 잠깐이지만 진짜 도쿄의 직장인이 된 기분을 느낄 수 있었습니다.Tech-Verse가 열린 행사장은 LY가 입주해 있는 도쿄 가든 테라스 기오이초의 4층으로, 제법 넓은 공간에서 다양한 세션이 동시에 진행됐습니다. 기오이초 오피스를 방문한 것은 처음이었는데, 비록 회사 내부 공간은 아니었지만 컨퍼런스 홀 입구에 도착했을 때 설레는 마음이 들었습니다. 쉽지 않은 출근길 끝에 맞이한, 에어컨의 시원한 바람과 함께 느꼈던 행사장의 첫인상이 아직도 생생하네요.행사장 앞 리셉션에서 제 이름표를 찾아 행사장으로 들어갔습니다. 행사장에는 Main Room A, B, C, D와 Seminar Room A, B까지 총 6개의 강연장이 있었고, 각 강연장에는 AI와 Security, Server Side 등의 주제가 설정돼 있었습니다. 각 강연장에서 해당 주제와 관련된 세션이 연속해서 진행되는 방식이었는데요. 저는 AI 세션이 진행된 Main Room A에서 주로 시간을 보냈습니다.발표 시작 전 수많은 참가자가 키노트 발표장 을 가득 채운 모습을 보니 긴장감과 기대감이 동시에 느껴졌습니다. 키노트에서는 LINE Corporation과 Yahoo Japan Corporation의 합병에 따라 진행된 플랫폼 통합을 소개하고, 향후 LY의 AI 전략과 주요 AI 활용 사례가 공유됐습니다. 이후 이어질 발표들의 방향을 미리 엿볼 수 있었던 예고편 같은 시간이었습니다.Tech-Verse DAY 1 - Rag부터 MCP까지, LY의 AI 기술 내공 엿보기첫째 날 키노트 이후 Main Room A에서는 요즘 AI 업계에서 자주 언급되는 키워드인 MCP(Model Context Protocol)와 RAG(Retrieval-Augmented Generation), 에이전트 등을 실제 서비스에 적용한 사례를 소개하는 발표가 주를 이뤘습니다. 기술 트렌드 자체보다는 '어떻게 도입했고, 어떤 허들을 넘었는가'에 집중된 발표가 많아 더 몰입해서 들을 수 있었습니다.그중 가장 인상 깊었던 발표는 AI와 함께 진화하는 엔지니어링이라는 제목으로 진행된 'Ark Developer' 관련 발표였습니다. LY에서는 Ark Developer라는 이름으로 사내 임직원에게 개발 과정 및 개발 프로세스에 최적화된 AI 솔루션을 제공하고 있습니다. RAG 기반 코드 어시스턴트를 구축해 코드 자동 완성, 리뷰 및 보안 확인, 주석 및 문서 자동 생성, 테스트 코드 작성 등을 지원하는데요. 특히 사내 문서를 스트리밍 형태로 실시간으로 참조해 코드 맥락에 맞는 도움을 주는 방식이 인상 깊었습니다. 또한 GitHub와 연동해 PR 생성까지 이어지는 데모도 시연됐습니다. 코드 어시스턴트가 연관된 코드를 참조할 때, 전체 코드 베이스를 별개의 문서로만 취급하지 않고 디렉토리 구조를 그래프처럼 취급해 그래프 분석(graph analysis)을 수행한 점도 굉장히 인상 깊었습니다.발표를 들으며 이 정도면 진짜 개발 사이클 전체를 AI가 함께 타고 가는구나 싶었고, 자연스럽게 '우리 팀에서도 이런 툴을 도입해 활용할 수 있을까?'라는 생각이 들었습니다. 발표 직후 옆자리에 있던 Yahoo! JAPAN 서비스 쪽 신입 개발자에게 “이거 실제로 쓰고 계세요?”라고 물어봤는데요. 그분이 “Copilot보다 체감이 훨씬 좋다”고 답하셨던 게 인상 깊게 남았습니다.또 하나 기억에 남는 발표는, AI로 생성된 이미지의 품질을 측정하는 방법이라는 발표였습니다. 최근 주로 LLM과 에이전트 중심으로 흘러가는 AI 기술의 흐름 속에서도 여전히 컴퓨터 비전 영역에서 활발히 기술을 연구하고 서비스에 적용해 나가는 팀이 있다는 점이 흥미로웠는데요. 특히 품질 기준이 주관적일 수밖에 없는 이미지 생성 기술의 특성을 보완하기 위해 평가 방식을 정교하게 다듬으려는 시도가 실무자의 입장에서 인상 깊었습니다.발표에서는 총 세 가지 방식의 이미지 생성 모델의 결과를 FID(Fréchet Inception Distance), IS(inception score) 같은 전통적인 이미지 분포 기반 평가는 물론, LAION의 Aesthetic Score와 같은 미적 기준, LLM 기반 평가인 CLIP-IQA, Q-Align, 비디오-언어 모델을 활용한 VQA(Visual Question Answering) 기반 질의응답 방식까지 소개하며, 정답이 존재하지 않는 생성 이미지의 품질을 어떻게 다각적으로 분석할 수 있을지에 대해 폭넓게 설명해 주셨습니다.저는 이 발표를 들으면서 LY에서 이미지 번역 모델과 인페인팅 모델이 실제 서비스로 운영되고 있다는 사실을