기존 AI 모델의 한계와 새로운 도전여행 산업에서 AI의 활용은 이미 다양한 형태로 이루어지고 있어요. 특히 대규모 언어 모델(LLM)을 활용해 고객 문의에 응답하거나 여행 정보를 제공하는 서비스가 널리 사용되고 있죠. 하지만 이러한 LLM 기반 서비스에는 분명한 한계가 있었어요.“LLM 은 학습한 데이터 안에서만 답변이 가능하기 때문에, 여러가지 모델 밖의 정보를 찾아서 답변을 얻고자 하는 경우에는 한계가 있었습니다.”기존의 LLM은 마치 방대한 지식을 가진 도서관 사서와 같았어요. 학습된 데이터 내에서는 풍부한 정보를 제공할 수 있지만, 최신 정보나 실시간 데이터에 대해서는 답변하기 어려웠죠. 이런 한계를 보완하기 위해 검색 증강 생성(RAG, Retrieval Augmented Generation) 기술이나 실시간 검색 기능이 도입되었고, 이를 통해 AI의 응답 품질을 개선할 수 있었어요.하지만 여행 산업에서는 단순히 정보를 제공하는 것을 넘어, 실제로 고객의 여행을 계획하고 예약까지 도와주는 완전한 여행 도우미가 필요했어요. 이러한 요구에 부응하기 위해 AI 에이전트 시대로의 전환이 시작되었고, 그 핵심 기술 중 하나로 MCP(Model Context Protocol)가 등장했습니다.검색을 넘어 예약과 결제까지: 통합 AI 에이전트 구현여행 상품 검색추천팀에서는 MCP를 활용해 단순 정보 제공을 넘어선 진정한 AI 여행 에이전트를 개발하기 시작했어요.“AI 에이전트가 단순히 데이터를 조회하는 것을 넘어, 외부 정보 탐색부터 예약·전송·결제 등 실제 행동까지 수행하려면 견고한 기술 기반이 필요합니다. MCP는 바로 이러한 기반 기술 가운데 하나로 등장했습니다.”MCP는 AI 에이전트가 다양한 서비스와 데이터 소스에 표준화된 방식으로 접근할 수 있게 해주는 프로토콜이에요. 마치 오케스트라 지휘자가 여러 악기들을 조화롭게 조율하듯, MCP는 다양한 서비스와 데이터를 통합적으로 관리하며 AI 에이전트의 성능을 극대화합니다.검색추천팀은 이러한 MCP의 잠재력을 활용해 여행 플래너 서비스를 구현했어요. 사용자가 여행 관련 질문을 입력하면, AI 에이전트는 필요한 정보를 찾기 위해 지속적으로 검색을 수행하고, 충분한 데이터가 모이면 종합적인 여행 계획을 제안하는 식이죠.“화면에서는 MCP의 사고 과정을 그대로 볼 수 있습니다. 제가 프롬프트를 입력하면 MCP는 답변 전략을 세우고, 필요한 정보가 확보될 때까지 반복적으로 탐색을 이어갑니다.”예를 들어, 사용자가 ‘영국과 프랑스 여행을 계획 중’이라고 하면, AI 에이전트는 프리미어리그 경기, 미술관 등 사용자가 언급한 관심사에 맞는 정보를 찾고, 추천 투어 코스를 제안합니다. 더 나아가 이러한 추천 정보를 회사의 실제 여행 상품과 연계하여 제시할 수도 있어요.마이리얼트립의 투어, 통신, 교통 상품들로 여행 일정을 구성하는 모습여러 에이전트의 협업으로 구현하는 원스톱 여행 서비스MCP를 활용한 AI 여행 에이전트의 가장 큰 특징은 여러 특화된 에이전트들이 협업하여 종합적인 여행 경험을 제공한다는

반복되는 검수 업무, AI가 해결사로 나서다마이리얼트립에서 파트너 관리는 매우 중요한 업무입니다. 특히 새로운 파트너의 가입 승인을 위한 검수 작업은 CX 매니저들의 시간과 노력을 상당히 요구하는 반복적인 일이죠. 사업자 등록증, 계좌 사본, 신분증 등 다양한 증빙 서류를 검토하고, 기본 정보를 확인해야 하는 과정이 매 검수마다 반복되지요.“CX 매니저분들이 휴먼 리소스를 되게 많이 쓰고 계시는 업무들이 많았는데, 그중에서도 파트너를 검수한다던가 상품을 검수한다던가 하는 검수 과정을 다양하고 반복적으로 수행하시는 경우가 많았습니다.”이런 상황에서 한 디자이너가 흥미로운 도전을 시작했어요. 개발자가 아님에도 불구하고 AI를 활용해 이 반복적인 검수 작업을 자동화하는 프로젝트를 제안한 것이죠. 특히 개발자 리소스가 제한적인 상황에서, 테스트 성격의 이 프로젝트는 AI를 활용한 새로운 접근 방식이었습니다.“안 그래도 바쁜 개발자 리소스를 요구하기가 좀 어려웠던 상황이 있었고요. 그리고 AI를 이용할 거라서 제가 개발을 하는 거라고 생각하지 않았던 부분도 있었습니다.”이 디자이너는 구글 시트로 병행해서 진행하던 업무까지 포함한 검수 프로세스 전체를 AI로 자동화하려는 목표를 세웠습니다. 매니저 한 명이 한 건을 처리하는 데 2–3분 정도 걸리던 작업을 AI로 훨씬 빠르게 처리할 수 있다면, 업무 효율화에 크게 기여할 수 있을 것이라 판단했죠.ChatGPT와 Dify로 시작한 비개발자의 코딩 여정개발 지식이 전혀 없는 디자이너는 어떻게 자동화 솔루션을 만들 수 있었을까요? 그 비결은 바로 GPT와의 협업이었습니다. Dify 라는 AI 워크플로우 자동화 도구를 활용해 솔루션을 개발하기로 결정했고, AI Lab에서 이미 만들었던 마케팅 파트너 검수 워크플로우를 참고했어요.ChatGPT 가 알려준 대로 만들어본 초기의 Dify Workflow“처음부터 GPT한테 얘기를 했죠. 저는 Dify 을 사실 잘 쓰지는 못하지만 Dify 를 이용해서 이런 파트너 검수를 만들고 싶고, 비개발자이기 때문에 개발을 전혀 할 줄 모른다. 그러니까 나한테 스텝 바이 스텝으로 좀 상세하게 친절하게 알려줘야 된다.”그렇게 시작된 여정은 GPT의 안내에 따라 워크플로우를 작성하고, 에러가 발생하면 스크린샷을 찍어 다시 GPT에게 물어보는 과정의 연속이었습니다. 하지만 워크플로우를 완성한 후 실제 데이터를 연결하는 과정에서 첫 번째 난관에 부딪혔죠.에러가 나면 스크린샷을 찍어 보여주며 문제를 해결했어요.매니저 페이지(백오피스 시스템)의 파트너 정보를 Dify 워크플로우로 가져오는 방법을 찾아야 했습니다. GPT와의 대화 끝에 크롬 익스텐션을 개발하는 방법을 선택했지만, 여기서도 다양한 기술적 어려움이 있었어요. 특히 Dify 워크플로우과 크롬 익스텐션 연결에 필요한 API 키 문제로 한동안 고민했죠.“GPT가 자꾸 ‘sk-’로 시작하는 키를 가지고 오래요. 근데 제가 Dify를 아무리 뒤져봐도 ‘sk-’로 시작하는 키는 안 만들어지는 거예요.”결국 Dify API 공식 문서에서

안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니다.저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '왔던 길을 되돌아가 보자'입니다.왔던 길을 되돌아가 보자네트워크나 파일 시스템 같은 I/O를 사용하는 경우 I/O의 데이터 표현과 코드의 데이터 표현을 상호 변환해야 합니다. 대표적인 예 중 하나가 인터페이스 정의 언어(IDL)나 데이터베이스 스키마 등 외부에서 정의된 데이터와 코드에서 정의된 모델 클래스를 상호 변환하는 것입니다. 이때 '상태'나 '타입'을 의미하는 값을 사용한다면 코드에서 열거형(enumeration)을 사용하기도 합니다.다음 코드에서는 데이터베이스에서 사용되는 값과 열거자(enumerator)를 상호 변환하기 위해 을 사용합니다.위 코드에 문제가 있을까요?평행한 두 개의 도로위 코드에서는 데이터베이스 값에서 열거형으로 변환하는 것과 그 반대로 변환하는 것이 각각 별도로 정의돼 있기 때문에 다음 두 가지 문제가 발생합니다.• 사양 변경 시 두 을 모두 업데이트해야 한다.• 두 변환 간에 서로 대응이 잘 이뤄지고 있는지 보장할 수 없다.이 문제를 해결하려면 '역방향 변환'은 기존 변환으로 유도하는 것이 좋습니다. 특히 열거자 속성이나 / 식을 사용할 수 있는 경우 이를 대신 사용하면 모든 열거자를 포괄하는 것을 보장하기 쉽습니다.열거자 속성을 사용하면 모든 열거자가 그에 대응하는 데이터베이스 값을 갖도록 할 수 있습니다. 예를 들어 Kotlin의 경우 함수를 사용해 에서 으로 을 만들 수 있습니다. 다른 많은 언어에서도 과 같은 함수나 열거자에 대한 반복문을 작성해 같은 작업을 수행할 수 있습니다.다음 코드는 변환을 수행하는 예제입니다.위 구현 방법은 단순하다는 장점이 있지만, 이 광범위하게 사용되는 모델의 경우 도 광범위하게 보인다는 점이 문제가 될 수 있습니다. 또한 여러 데이터 표현 간에 상호 변환이 필요한 경우 에 해당하는 값을 여러 개 정의해야 하므로 혼란을 초래하기 쉽습니다.다음 구현은 여러 변환을 위한 값을 가지고 있는데요. 이대로 변환 대상과 변환 원본이 늘어나면 클래스 정의가 금세 비대해질 것이라는 것을 쉽게 예상할 수 있습니다. 이런 경우에는 다음에 소개할 '구현 예제 2' 적용을 고려해 보는 게 좋습니다.구현 예제 2: 개별 레이어 내에서 변환 구현 및 역변환 맵변환을 사용하는 코드가 기능이나 레이어, 스코프 내에 국한되어 있다면 해당 범위 내에서 변환을 정의하는 방법이 있습니다. 다음 코드는 와 의 상호 변환을 에 국한된 범위로 정의합니다. 이때 에서 로 변환하는 것에는 식을 사용해 모든 열거자를 포괄하는 것을 보장합니다.또 다른 방법은 나 와 같은 클래스를 별도로 정의하는 것입니다. 플랫폼에 따라 이를 쉽게 구현할 수 있는 플랫폼이 있습니다. 단, 나 를 구현하는 경우에도 순방향 변환과 역방향 변환은 같은 파일이나 클래스에서 정의해야 합니다.위 구현 예제는 둘 다 모든 열거자에 대응하는 값이 있다는 것(열거자가 정의역일 것)을 보장합니다. 단, 값이 중복되지 않는다는 것(단사일 것)은 보장하지 않습니다. 값이 중복되지 않음을 보장하려면 다음과 같은 테스트를 작성하면 됩니다.

AI Lab은 모든 직원이 일정 예산 안에서 원하는 AI 툴을 자유롭게 구독할 수 있도록 지원하는 일도 하고 있어요. 이번엔 격무에 시달리던 서비스 운영팀이 AI 를 통해 생산성을 혁신하고 업무의 본질에 더 다가가게 된 사례를 소개합니다.반복 업무의 늪: 서비스 운영팀이 직면한 도전여행 서비스 업계에서 고객 경험은 모든 것의 중심이지만, 이를 지원하는 운영 업무는 반복적이고 시간을 많이 소모하는 작업들로 가득 차 있어요. 서비스 운영팀은 이런 현실에 직면해 있었죠.“회사 내에 대부분의 팀들이 그러하겠지만 저희 팀도 매일 접수되는 업무, 요청 오는 업무로 대부분의 리소스가 투입되고 있는 상황이에요.”팀은 본래 운영 리스크를 줄이고 운영 정책을 고도화하는 중요한 업무에 집중해야 했지만, 현실은 달랐어요. 하루의 대부분을 후기 권리침해 대응, 부정거래 계정 관리, 외부거래 모니터링 같은 일상적인 반복 업무에 소비하고 있었죠.문제 해결을 위해 이 팀은 업무의 일부를 운영법인에 이관하거나 제품 개발팀에 개발을 요청하는 방법을 고려했어요. 하지만 다른 모든 조직도 마찬가지로 리소스가 제한되어 있고 각자의 우선순위가 있었기에, 이런 방식으로는 상황을 개선하기 어려웠어요.결국 팀은 스스로 문제를 해결해야 한다는 결론에 도달했고, 여기서 AI를 활용한 자동화의 가능성에 주목하게 되었어요.비개발자의 AI 자동화 도전기: 모두의 AI에서 찾은 희망해결책을 찾던 중, 서비스 운영팀은 회사 내에서 진행되는 ‘AI 리터러시’ 향상 프로그램인 “모두의 AI” 세션에서 중요한 인사이트를 얻게 되었어요.“모두의 AI 섹션이 저한테는 한줄기의 빛이었어요. 모두의 AI 세션은 조직의 비슷한 고민을 하고 있는 팀들이 자동화한 경험을 들려주었기에 더 와닿더라구요.”이 세션을 통해 팀은 구글 확장 프로그램, 클로드(Claude) AI(Claude for Sheets), 구글 Apps Script등의 도구를 활용하면 비개발자도 업무 자동화가 가능하다는 것을 알게 되었죠. 특히 유튜브나 다른 채널에서 볼 수 있는 일반적인 AI 활용사례보다 같은 회사 내에서 유사한 고민을 가진 팀들의 경험이 더 실질적인 도움이 되었어요.팀은 이 인사이트를 바탕으로 가장 시간이 많이 소요되는 세 가지 핵심 업무부터 자동화하기로 결정했어요:후기 권리침해 처리: 매일 약 1시간씩 소요되는 업무로, 권리침해 신고 접수부터 후기 블라인드 처리, 메일 발송까지 모든 과정이 수작업으로 진행되었어요. 한 건 처리에만 평균 10분이 소요되었죠.부정거래 계정 관리: 부정거래가 의심되는 계정을 확인하고, 판단하고, 메일을 발송하고, 계정을 정지하는 작업으로 역시 많은 수작업이 필요했어요.외부거래 모니터링: 하루에 150–200건의 메시지를 검토해 플랫폼 외부로 결제를 유도하는 행위를 식별하는 업무였어요.자동화 과정에서 가장 중요했던 것은 각 업무에서 가장 시간이 많이 소요되는 부분을 정확히 파악하고, 그 부분에 집중하는 것이었어요. 예를 들어 후기 권리침해 업무에서는 메일 발송과 후기 내용 요약 부분이 가장 시간이

클릭의 바다에서 헤매는 여행 상품 담당자들의 이야기여행 패키지 상품을 만드는 과정은 생각보다 복잡해요. 항공, 숙박, 관광 상품을 묶어 하나의 패키지로 제공하기 위해서는 수많은 옵션을 검토하고 선택해야 하죠. 또한 예약 일정이 변경되는 경우에는 수작업이 많았는데, 특히 항공편 탐색 과정은 가격 차이가 크기 때문에 비슷한 가격에 같은 클래스의 좌석을 찾는 것이 담당자들에게 큰 부담이었어요.복잡하고 불편한 항공편 검색 화면“항공 구성 상품을 탐색할 때 굉장히 많은 리소스가 투입되고 있었어요. 그리고 고객이 예약하고 나서 고객 사정으로 대체 항공편을 찾아야 될 때도 굉장히 많은 리소스가 투입되고 있었어요.”여행 상품 담당자들은 매일 이런 반복적인 작업에 시간을 쏟고 있었어요. 예를 들어, 오전 6시에서 8시 사이에 출발하고 돌아올 때는 오후 6시에서 8시 사이에 출발하는 항공편을 찾기 위해서는 여러 필터를 조합해야 했죠. 그런데 기존 시스템의 필터는 6시간 단위로만 구분되어 있어서 원하는 시간대만 정확히 볼 수 없었어요.또한 성인 일반가만 보기 위해서는 여러 할인 옵션을 하나하나 해제해야 했고, 좌석이 충분히 남아있는 항공편을 찾는 것도 쉽지 않았어요. 이런 반복적인 작업들이 담당자들에게 많은 스트레스를 주고 있었죠.GPT와 함께 웹 구조 분석하기: 코딩 없이도 가능한 크롬 확장 프로그램 개발이 문제를 해결하기 위해 패키지 담당 PM(Product Manager)은 세 가지 솔루션을 검토했어요. 특정 계정으로 더 고도화된 필터를 제공하는 방법, 슬랙 항공편 검색봇을 만드는 방법, 내부 관리 시스템에 검색 기능을 추가하는 방법이었죠. 하지만 모두 개발 비용이 너무 크거나 사용성이 떨어진다는 문제가 있었어요.ChatGPT 에게 웹 페이지 구조를 전달하며 크롬 익스텐션을 개발하는 모습 (예제)그래서 담당 PM은 컴퓨터 전공 지식을 살려 새로운 접근법을 시도했어요. GPT의 도움을 받아 웹사이트 구조를 분석하고 크롬 확장 프로그램을 개발하기로 한 거죠.“GPT랑 함께 웹 구조를 분석하고 크롬 확장 프로그램을 통해서 필터를 만들어 보자라는 생각을 하게 되었습니다.”GPT에게 웹 페이지의 HTML 구조를 보여주고, 자신이 원하는 기능을 설명했어요. 예를 들어 할인카드 필터에서 ‘성인’ 옵션만 남기고 나머지를 자동으로 해제하는 스크립트를 요청했죠. GPT는 이 요청을 바탕으로 바로 실행 가능한 코드를 생성했고, PM은 이를 테스트해 효과를 확인했어요.“여기 디비전에서 성인, 체크박스를 제외하고 모두 해제할 거야. 개발자 도구에서 테스트할 수 있도록 스크립트를 줘.”라고 요청하면 GPT가 바로 코드를 만들어줬고, 실제로 잘 작동했어요.이렇게 다양한 기능을 하나씩 개발하여 최종적으로는 크롬 확장 프로그램 형태로 패키징해 팀원들에게 배포했어요. 놀라운 점은 이 모든 과정에서 PM이 직접 코딩을 거의 하지 않았다는 거예요. GPT와의 대화만으로 필요한 기능을 구현할 수 있었죠.“이전과는 완전히 달라졌어요”: 담당자들이 체감한 업무 혁신새롭게 개발된 크롬 확장 프

마이리얼트립 AI Lab은 모든 마리터들이 AI를 더 가깝고 편안하게 활용할 수 있도록 많은 일을 하고 있어요. 그 활동중 하나로, 매주 한두 번 ‘모두의 AI’라는 시간을 마련해 우리가 직접 시도해 본 경험과 깨달음을 나누고 있지요. 덕분에 직무 구분을 넘어 서로의 아이디어가 자연스럽게 이어지고, 곳곳에서 새로운 임팩트가 싹트고 있어요. 이 블로그에서도 그런 이야기를 하나씩 담아보려 합니다.“21시간” -> ”5분”. 여정의 시작여행 상품 플랫폼을 운영하는 커머스팀은 1분기에 중요한 미션을 가지고 있었어요. 바로 상품에 대한 신뢰도를 높여 고객의 구매 결정을 돕고 전환율을 개선하는 것이었죠. 이를 위해 고객이 가장 먼저 접하는 메인홈 화면 개편이 필요했어요.문제는 메인홈에 노출되는 수천 개의 상품 제목이었어요. 파트너들이 직접 등록한 이 제목들은 가독성이 떨어지고 일관성이 없었어요. 괄호나 대괄호를 사용하거나, 지나치게 긴 제목으로 사용자 경험을 저해하고 있었죠.“실제 T&A(Tours and Activities)상품의 제목을 메인홈에 딱 올려봤더니 왼쪽 화면처럼 보이더라고요. 즉 여행자들이 대문에 딱 들어와서 보는 제목이 가독성이 굉장히 떨어지게 되는 거죠.”파트너의 상품 입력 타이틀을 그대로 사용한 경우(좌) / 상품 제목을 일관되게 수정(우)이 문제를 해결하기 위해 메인홈 노출용 상품 제목을 별도로 만들기로 결정했어요. 하지만 주요 도시 78개, 인기 상품만 2,500개… 상품 하나당 30초씩만 수정해도 21시간이 필요한 계산이 나왔어요. 또한 도시와 상품은 계속 확장될 예정이었기에, 이는 일회성이 아닌 반복적으로 발생할 비효율이었지요.시행착오를 거쳐 찾아낸 AI 활용법처음에는 GPT를 활용해 상품 제목을 자동으로 변환하는 방법을 시도했어요. 중화중문학과 출신의 PM이 AI에 처음 도전한 순간이었죠.기존 상품 제목과 카테고리 정보 (예시)“가독성을 향상시키기 위해서는 일단 짧아야 된다고 생각을 했어요. 그래서 15자 이내라는 조건을 한번 GPT한테 줘봤어요. 그랬더니 수정 퀄리티가 굉장히 낮더라고요.”첫 시도는 실패했지만, 포기하지 않고 프롬프트를 변경하며 테스트했어요. 상품 유형인 카테고리 정보를 함께 제공하자 퀄리티가 크게 향상됐어요. 가이드 투어나 프라이빗 투어 등 카테고리별 특성을 반영한 15자 이내의 제목이 잘 생성되었죠.그러나 2,500개 전체 리스트를 한꺼번에 처리하려 했을 때 다시 문제가 발생했어요. 대량의 데이터를 한 번에 처리하니 GPT가 맥락을 잃고 엉뚱한 결과를 내놓기 시작했던 것이죠.2500개 상품 제목이 있는 스프레드시트를 올려서 다건 처리를 시도하는 장면 (예시)“GPT가 대답을 할 때 우리가 준 질문에 어떤 부분이 중요한지를 판단을 한다고 합니다. 그런데 우리의 질문이 점점 길어지면 길어질수록 뭐가 중요한지를 잃어버리는 거예요. 2500개의 상품들 중에는투어, 티켓, 교통 등 여러가지 상품들이 섞여 있기 때문에, 축약된 제목에는 다른 상품의 맥락이 섞여 있을 수 있죠. 큰 데이터를 한꺼번에 주면 처리를

웹 서비스를 준비하는 과정에서 부하테스트는 서비스 운영 중 발생할 수 있는 문제를 미리 파악하는 데 필수적인 단계입니다.특히 LLM(Large Language Model)을 활용하는 서비스는 기존 웹 서비스와는 다른 특성을 가지고 있기 때문에,이에 맞는 지표(Metric)를 정확히 이해하고 적절한 테스트를 진행하는 것이 매우 중요합니다.이 글에서는 LLM 기반 서비스의 부하테스트에서 반드시 확인해야 하는 주요 Metric과 간단한 예제를 함께 정리하여 설명합니다.여기서는 대표적으로 많이 사용되는 프레임워크인 vLLM을 기준으로 설명하나, 다른 프레임워크를 사용하더라도 핵심 원리와 지표 측정 방식은 크게 다르지 않으므로 참고하시면 좋을 것 같습니다.LLM을 이용한 서비스는 일반적으로 대화형(Chat) 기반으로 설계됩니다.기존 API 서비스가 요청 처리 후 최종 데이터를 JSON 형태나 바이너리 등 완결적 결과를 주로 전달하는 반면, LLM 서비스는 생성되는 답변을 실시간으로 스트리밍 형태로 제공합니다.이에 따라 사용자의 첫 번째 응답까지 걸리는 시간(TTFT), 각 토큰 생성 시간, 평균 응답 길이 등과 같이 전통적인 웹 서비스와는 차별화된 Metric을 사용하여 테스트해야 합니다.또한 이 새로운 Metric들을 기존 서비스와 비교하기 위해 다른 형태로 환산하거나 분석하는 경우도 흔히 발생합니다.부하테스트에서 중요하게 측정하는 MetricLLM 서비스를 제공할 때 가장 중요한 두 가지 요소는 지연 시간(Latency)과 처리량(Throughput)입니다. 세부적인 Metric을 살펴보면 다음과 같습니다.• None TTFT(Time To First Token): 사용자가 요청 후 첫 번째 토큰을 받을 때까지 걸리는 시간으로, 체감 응답 속도를 가장 잘 나타냅니다. vLLM에서는 로 측정합니다.• None 총 대기 시간: 요청이 시작되어 최종 응답까지 걸리는 전체 시간으로, 긴 출력이 예상되는 서비스에서는 특히 중요합니다. vLLM에서는 로 확인합니다.• None 토큰당 생성 시간: 각 토큰 생성에 걸리는 평균 시간을 나타내며, vLLM에서 로 측정됩니다.• None 토큰 처리량: 초당 생성되는 토큰 수(tokens per second, TPS)로 서비스의 성능을 평가할 때 가장 흔히 사용하는 지표입니다.• None 요청 처리량: 초당 처리 가능한 요청 수를 의미하며, 시스템 전체 성능을 평가하는 데 매우 중요합니다.만약 vLLM 을 사용해서 서비스를 구성한다면, vLLM 기반 부하테스트는 vLLM에서 제공하는 benchmark_serving.py를 사용해 쉽게 진행할 수 있습니다. 샘플 스크립트는 다음과 같습니다.각 인자의 의미는 다음과 같습니다.• None dataset-name: 사용 데이터셋 유형( 는 Hugging Face 데이터셋 사용 시 지정)부하테스트의 예시 결과는 아래와 같습니다.이 중 주요하게 봐야 할 Metric은 Mean TTFT, Mean ITL, Request throughput, Output token throughput입니다.예를 들어 평균 100 토큰을 생성하는 서비스라면, 사용자가 최종적으로 답변을 받기까지 약 4.5초 정도 소요될 것으로 예상할 수 있습니다(598.11ms + 100 토큰 × 41.94ms).여기서 **TPOT(Time per Output Token)**는 토큰 자체의 순수 생성 시간이고, **ITL(Inter-token Latency)**은 생성된 토큰이 사용자에게 실제 전달될 때까지 걸리는 지연 시간입니다.따라서 ITL이 실질적인 사용자 체감 속도를 더 정확히 나타냅니다.특히, 평균값과 중간값 간 큰 차이가 있을 경우 스파이크 등 외부 요인으로 인한 성능 저하 가능성을 염두에 두고, 추가 분석을 진행해야 합니다.또한, 높은 P99 값(예: TPOT 43.4ms 대비 ITL 326.1ms)이 나타날 경우 네트워크나 시스템 구성에 잠재적 문제가 있는지 점검하는 것이 필요합니다.LLM 서비스를 준비할 때는 기존 웹 서비스와는 차별화된 지표들을 명확히 이해하고, 이를 바탕으로 철저한 부하테스트를 진행해야 합니다.특히 TTFT와 ITL, 토큰 처리량 등의 데이터를 면밀히 분석하여 사용자 체감 성능을 최적화하는 것이 중요합니다.또한 Metric을 통해 도출된 데이터를 토대로 시스템 전반의 문제점을 파악하고, 네트워크 환경을 포함한 다양한 요소를 점검한다면, 보다 견고한 서비스로 발전시킬 수 있을 것으로 생각됩니다.

일하면서 한 번쯤, 이상을 꿈꿔본 적이 있나요?빠른 문제해결이 중요한 토스에서도, 그 너머의 이상을 그리는 사람들이 있어요. 디자이너, 리서처, 라이터, 엔지니어링 등 다양한 분야에서 정교하고 아름다운 UX를 실현하기 위해 새로운 시도를 이어가고 있죠.하지만 현실은 쉽지만은 않아요.이번 시즌에서는, 일하는 누구나 꿈꿔본 이상을 현실로 만들기 위해 고군분투한 토스팀의 여정을 들려드려요. 우리는 어떤 고민을 했고, 어떻게 답을 찾았을까요?그래픽, 인터랙션, 엔지니어링, UX 라이팅, 리서치, 플랫폼 디자인까지, 총 14개의 이야기가 준비되어 있어요. 잠깐 들여다보실래요?토스다움을 완성하는 순간들이토록 아름다운 새로고침화면을 아래로 당기면 나오는 그래픽, Pull To Refresh. 그 짧은 찰나에 아름다움을 담기 위한 고민을 들려드려요.인터랙션으로 첫인상 만들기토스를 처음 써보는 외국인에게 토스를 어떻게 소개해야 할까? 모두가 감탄한 온보딩, 그 중심에는 인터랙션이 있었어요.IT 업계에 3D 그래픽이 넘쳐나는 시대. 토스는 어떻게 '토스다움'을 만들어냈을까요? 그 여정을 보여드려요.인터랙션 개발의 매력은 무엇일까요? 아름다움과 감각을 설계하는 세 명의 인터랙션 개발자가 답해드릴게요.2,800만 명이 쓰는 앱에서 7,000명의 스크린 리더 사용자 경험까지 챙기기 위해, 토스는 어떤 노력을 하고 있을까요?시각 장애인이 토스를 더 쉽게 쓰려면, 무엇이 달라져야 할까요? 리서치를 통해 얻은 세 가지 인사이트를 공유할게요.토스가 사용자 경험과 마주하는 법사용자가 원하는 기능을 잘 찾는지, 정성적인 경험도 이제 수치로 말할 수 있어요. 토스만의 새로운 기준으로요.모두가 유저를 만나는 순간까지일하느라 사용자를 만날 시간이 없다면, 점심시간은 어떨까요? 식사하며 사용자의 목소리를 듣는 토스 팀의 이야기를 들려드릴게요.UX가 AI를 만났을 때AI시대에 라이터로 살아남기AI는 UX라이터에게 위기이자 기회예요. 다크패턴을 계기로, 라이터에서 프롬프트 엔지니어로 성장한 이야기를 들려드려요.AI봇을 만들면서 배운 3가지사용자를 만나기 전에 가볍게 의견을 물어볼 수 있는 AI UT봇. ‘휴리봇’ 을 만들면서 배운 3가지들 알려드릴게요.토스 그래픽을 10초 만에 그리는 AI‘토스트’를 소개합니다. 인간이 3일 걸려 만드는 3D 그래픽을 10초 만에 만든다니, 퀄리티까지 따라올 수 있을까요?익숙함 너머, 본질을 보다동의 화면도 간결해질 수 있을까각종 법적 제한 때문에 자유롭지 않은 동의 화면 디자인. 관성을 깨면 얼마나 달라질 수 있을까요?토스가 디자인툴을 만든 이유스케치, 피그마, 프레이머… 모두 써봤지만 우리에게 딱 맞는 건 없었어요. 그래서 만들었습니다. 토스만의 디자인 툴, 데우스.아무도 쓰지 않는 디자인 시스템새로운 컴포넌트를 배포했는데, 왜 아무도 안 쓰지? 컴포넌트를 넘어서, 일하는 방식 자체를 바꿔보기로 했어요.Simplicity 25는 거창한 해답보다는, 현실 속에서도 이상을 놓지 않으려 한 태도에 대해 이야기 하려고 해요. "정말 이런 게 가능할까?

dan.dy 사내 해커톤이 어떻게 진행되는지 궁금하시다면 이 글을 통해 생생한 현장으로 들어가 보시죠!안녕하세요, 카카오페이 Developer Relations 담당자 로라입니다.4월 14일~15일 양일간 두 번째 카카오페이 해커톤, 카페톤을 성공적으로 마쳤습니다. 무려 29개 팀, 138명의 크루와 함께한 이번 카페톤은 크루들의 열정으로 가득했는데요. 이틀 동안 후끈후끈했던 현장 함께 보실까요?카카오페이 해커톤, 카페톤은 2022년 온라인으로 시작했습니다. 사내 슬랙 도입에 맞춰 ‘슬랙봇 만들기’를 주제로 진행했었어요. 2022년 카페톤 수상작 살펴보기3년 만에 진행한 2025 카페톤은 드.디.어 오프라인으로 진행했답니다. 일반적으로 해커톤은 무박 2일로 진행하지만, 첫 오프라인 진행인 만큼 저희는 1박 2일 일정으로 진행했어요.• 예선: 참가 팀이 많아 예선은 팀별로 부스를 꾸려 부스 투어로 진행본격 카페톤 시작 전, 참가자 전원에게 웰컴 키트도 제공했답니다. 웰컴 키트에는 어두운 후드가 대부분인 크루들을 위해 밝은 후드 집업과 보조 배터리, 카페톤 참가 목걸이 3종을 담아 전달드렸어요.이번 카페톤은 AWS Generative AI 서비스를 활용해 크루들의 아이디어를 실현하고, AI 활용 역량을 높이는 것을 목표로 진행했어요. 사전에는 Amazon Bedrock과 SageMaker를 중심으로 한 원데이 교육을 진행했고, 행사 기간 내내 AWS의 아낌없는 기술 지원이 함께했습니다. 덕분에 참가한 모든 크루들이 AWS의 기본적인 활용법은 물론, 생성형 AI 모델 적용 경험까지 함께 얻을 수 있는 기회의 장이 되었답니다.처음으로 오프라인에서 진행해 더욱 특별했던 카페톤에서 크루들의 열정은 어땠을까요?DAY1 기획부터 개발까지 풀가동!막을 수 없는 크루들의 열정 열정 열정🔥DAY1 공식 행사 시간은 오전 10시부터 오후 10시까지였는데요. 크루들의 열정 앞에서 행사 시간은 큰 의미가 없었습니다. 행사 시작쯤 오늘 몇 시까지 계실 거냐는 질문에 자신 있게 ‘10시 전에는 가죠.’ 하던 크루들의 모습은 어디 가고, 공식 행사 시간인 오후 10시 이후부터는 ‘오늘 안에 갈 수 있을까요?’, ‘로라 설마 집에 가시나요?’ 질문만 돌아왔다는 후문이…한 번 시작하면 끝을 봐야 하는, 조금이라도 아쉬움이 없어야 하는 크루들의 열정 하나로 새벽까지 판교를 지킨 팀이 꽤나 되었답니다.빠질 수 없는 식사와 이벤트점심, 저녁 그리고 혹시 모를 밤샘 팀을 위한 CEO 앨런의 치맥 지원까지~~~🍗🍻 끝이 안 보이는 식사 제공으로 크루들이 이제 그만 먹으면 안 되냐고 할 정도였으면, 말 다 했죠?집중력이 흐트러질 타이밍에는 크루들의 집중력을 높이기 위한 카훗(Kahoot!) 퀴즈 이벤트를 진행했습니다. 카훗은 실시간으로 문제를 풀고 순위를 다투는 퀴즈 플랫폼으로, 간단한 클릭만으로도 모두가 함께 참여할 수 있어 짧은 시간에 현장 분위기를 확 띄울 수 있었어요. 재미난 이벤트를 제안하고 진행까지 해주신 AWS 진성님 감사합니다.해당 이벤트에서는 “이번 카페톤 참

지난 글에서는 비개발자의 시선에서 ‘바이브 코딩(Vibe Coding)’과 AI Native에 대한 생각을 먼저 나눴습니다. 이번에는 그런 생각의 토대가 되었던 실제 경험을 바탕으로 이야기를 이어가고자 합니다.‘필요한 도구를 찾는 것보다 내가 직접 만들어서 쓰는 것이 더 빠르다’는 것을 깨달으면서 저는 바이브 코딩을 시작하게 되었습니다. HTML 도구를 ‘개발’했다고 소개하려 하니, ‘HTML은 프로그래밍 언어가 아니다’라는 밈이 떠오르네요. 비록 HTML 파일이 주요 결과물이지만 CSS, 자바스크립트, 타입스크립트 등 작은 웹 앱 형태로 구색을 갖추는 경우도 있으니 너그러이 봐주세요. 물론, 실제 개발자 분들이 만드는 제품처럼 견고하고 확장성 있는 결과물은 아니고, 최소 기능 제품(Minimum Viable Product) 수준에서 충분히 유용하게 활용하고 있습니다.사용할 수 있는 AI 개발 도구들이 다양한데요, 제 경험은 크게 아래 두 가지로 나누어 보겠습니다.• LLM으로 만들기 (ChatGPT/Claude/Gemini)• AI 에이전트(agent) 도구로 만들기 (Copilot Agent)➊ LLM으로 만들기ChatGPT, Claude, Gemini 같은 LLM(거대 언어 모델)은 요청할 때마다 결과가 조금씩 달라진다는 특징이 있습니다. 때로는 입력 데이터 중 수정하면 안 되는 부분까지 답변 생성 과정에서 수정되어 버리는 경우도 있습니다. 이런 일이 발생하면 결국 모든 데이터를 일일이 확인해야 하는 번거로움이 따릅니다.그런데 단순히 정해진 규칙대로 반복적인 처리만 필요한 경우도 많습니다. 예를 들어, 텍스트 목록 전체에 동일한 머리말을 추가하거나, 숫자 형식을 규칙에 맞게 한 번에 변환하는 작업처럼 말입니다. 이런 경우에는 결과를 예측하기 어려운 ‘블랙박스’ 같은 LLM에게 직접 작업을 요청하는 것보다, 차라리 그 규칙대로 작동하는 간단한 도구를 만들어 달라고 하는 편이 결과의 신뢰도와 일관성을 높이는 데 훨씬 효과적입니다.예를 들어 다음과 같이 프롬프트를 작성하면 됩니다.위 이미지는 저의 첫 바이브 코딩 작품인 '영어 to 한글 키보드 변환기’입니다. 이 도구를 만들었던 2024년 하반기만 해도, 비교적 간단한 규칙 기반의 작업을 LLM이 제대로 처리하지 못하는 경우가 있었습니다. 제가 발견했던 사례는, 키보드 한/영 키를 잘못 눌러 영문으로 입력된 한글을 다시 한글로 바꾸는 작업이었습니다. (예: → )당시 여러 프롬프트와 언어모델을 사용해 보았지만, 처음 몇 개의 알파벳은 잘 변경해 준 뒤, 그 뒤로는 앞 단어를 기반으로 새로운 문장을 창조하면서 변환 작업을 잊어버리는 것 같았습니다. 그래서 프롬프팅에 능한 동료 로빈(Robin.hwang)에게 자문을 구했고, 로빈의 추천으로 이 키보드 변환 규칙을 직접 수행하는 웹 도구를 LLM에게 프롬프팅 하여 만들게 된 것입니다. 귀여운 고양이 테마 디자인도 (역시 로빈의 아이디어로) 프롬프팅으로 추가했습니다.물론 몇 개월 후에는 LLM 성능이 빠르게 발전했고, 지금은 이런 도구 없이 LLM 채팅창에서도 변환이 곧잘 가능해졌습니다.생각을 시각화하기 위해 저는 가끔 머메이드(Mermaid) 문법으로 다이어그램을 그립니다. 하지만 이를 위해 VS Code를 실행하고 새 파일을 만드는 것이 번거로웠습니다(비개발자인 저는 평소에 IDE를 켜두지 않으니까요). 그래서 ‘그냥 웹에서 바로 쓰고 바로 볼 수 없을까?’ 하는 생각에, 저장 기능은 빼고 라이브 편집 기능만 갖춘 HTML 페이지를 ChatGPT에서 바로 만들었습니다. 이름하여 '머메이드 라이브 에디터’입니다.저는 머메이드를 자주 사용하지 않는 탓에 필요할 때 문법이 기억나지 않는 경우가 많았는데요, 에디터가 로딩될 때 샘플 문법을 입력창에 미리 보여주도록 수정하니 사용이 편리했습니다. 이처럼 도구를 만들 때, 입력 형식이나 예시 데이터를 미리 작성해서 첫 화면에서 보여주는 것이 좋았습니다. 그러면 시간이 흐른 뒤에 다시 사용할 때에도 헤매지 않고 바로 사용할 수 있었습니다.엑셀 함수로도 가능하지만, 매번 수식을 입력하거나 직접 확인하기엔 번거로운 단순 반복 작업들이 있습니다. 이런 작업들 역시 LLM에게 요청하여 규칙 기반으로 작동하는 HTML 파일 하나로 만들어 두면 필요할 때마다 편리하게 사용할 수 있습니다. 예를 들어 ‘중복 텍스트 검출기’, ‘데이터 개수 세기’, ‘랜덤 추첨기’ 같은 것들입니다. LLM에게 명확한 규칙을 알려주면, 이런 자주 쓰는 기능을 빠르고 정확하게 수행하는 도구를 쉽게 만들 수 있습니다.여러분의 업무에서 자주 반복하는 간단한 작업들이 있다면 작은 기능 단위부터 직접 도구를 만들어 활용해 보시길 추천드립니다.➋ AI 에이전트 도구로 만들기에이전트는 사용자가 모든 세부 사항을 지시하지 않아도, 사용자 경험(UX)을 고려하여 전체적인 결과물을 만들어 줍니다. 단 한 줄의 프롬프트로도 수준 높은 결과물을 얻을 수 있는 것이죠. 빠른 기술의 발전 덕분에, 이제는 LLM 도구만으로도 에이전트와 유사한 경험을 할 수 있습니다. 그럼에도 예를 들어, VS Code 환경에서 코드 복사・붙여넣기 조차 직접 하지 않아도 되는 등, 에이전트 개발 도구만의 편리한 특징들이 있는 것 같습니다.앞서 소개한 ‘중복 텍스트 검출기’를 코파일럿(Copilot)의 에이전트로 다시 만들어 보겠습니다.우선 LLM으로 만들 때와 비슷한 프롬프트를 입력했습니다(아래 프롬프트는 ChatGPT가 썼어요).그랬더니 LLM으로 만들었던 것과 유사한 결과물이 일단 나왔습니다.여기서 에이전트가 실력을 발휘할 수 있도록 다음의 프롬프트를 입력했습니다.이렇게 두 번의 대화로 아래의 결과물이 완성되었습니다.위 사례는 단일 HTML 파일 작업이라, 에이전트의 장점이 크게 와닿지 않으실 수도 있습니다. 하지만 여러 파일을 오가며 작업하거나, 오류를 해결할 때 등, 번거로운 작업이 늘수록 에이전트의 편리함을 체감하게 됩니다.이 사례처럼 간단한 도구를 만들 때는 프롬프트가 짧아도 훌륭한 성능을 경험할 수 있습니다. 반면 복잡한 요구사항을 정확히 반영해야 하는 경우에는, 처음부터 최대한 완성도 높은 결과