이제 PIP 대신에 uv를 사용하기UV는 Rust로 작성된 매우 빠른 Python 패키지 및 프로젝트 관리자입니다.이 튜토리얼에서는 UV의 설치부터 기본적인 사용법까지 단계별로 알아보겠습니다.UV는 Python 패키지 관리와 프로젝트 관리를 위한 현대적인 도구입니다. 주요 특징은 다음과 같습니다:• None ⚡️ pip보다 10-100배 빠른 속도• None• None pip: 수동으로 가상환경을 생성하고 활성화해야 함• None uv: 프로젝트 초기화 시 자동으로 가상환경 생성, 패키지 설치/실행 시 자동 활성화• None• None uv: 프로젝트 의존성을 체계적으로 관리 ( ), 버전 잠금 기능 ( )아래 명령은 uv를 특정 디렉토리에 초기화 하는 방법이다.현재 디렉토리에서 uv를 초기화 한다면 다음과 같이 작성하자.UV 초기화 시 다음과 같은 파일들이 생성됩니다:• None• None 프로젝트의 메타데이터와 설정을 저장하는 파일• None• None 프로젝트에서 사용할 Python 버전을 지정하는 파일• None• None 프로젝트의 의존성 목록을 저장하는 파일• None 초기에는 비어있음• None 명령으로 업데이트됨• None• None 개발 환경에서만 필요한 의존성 목록을 저장하는 파일• None 초기에는 비어있음• None 명령으로 업데이트됨• None• None 가상환경이 생성되는 디렉토리• None• None 의존성의 정확한 버전을 잠그는 파일• None 명령으로 생성/업데이트됨• None # 의존성 추가 후 잠금 파일 업데이트 uv add requests uv lock # requirements.txt 업데이트 uv pip freeze > requirements.txt uv pip freeze --dev > requirements-dev.txt• None # requirements.txt로부터 의존성 설치 uv pip install -r requirements.txt uv pip install -r requirements-dev.txt # 잠금 파일로부터 정확한 버전 설치 uv syncUV는 패키지 설치를 위한 두 가지 주요 명령어를 제공합니다. 각 명령어의 특징과 차이점을 알아보겠습니다:• None• None 프로젝트 의존성 관리에 최적화• None 파일에 의존성을 자동으로 추가• None 프로젝트의 의존성 목록을 체계적으로 관리• None 개발 의존성과 일반 의존성을 명확히 구분• None # 기본 의존성 추가 uv add requests # 개발 의존성 추가 uv add --dev pytest # 특정 버전 추가 uv add requests==2.31.0 # 로컬 패키지 추가 uv add -e ./local-package• None• None 프로젝트 의존성 목록을 자동으로 업데이트• None 의존성 버전을 명시적으로 관리• None 개발 환경과 프로덕션 환경의 의존성을 구분• None• None• None 전역 또는 가상환경에 패키지 설치• None 프로젝트 의존성 목록에 자동으로 추가되지 않음• None #

vLLM은 대규모 언어 모델(Large Language Model, LLM)을 고속으로 추론하기 위한 효율적인 엔진으로, 특히 serving 환경에서 높은 처리량과 낮은 지연 시간을 목표로 한다.핵심 기술은 PagedAttention이라는 메모리 관리 기법으로, GPU 메모리를 효율적으로 분할·재사용함으로써 여러 요청을 동시에 빠르게 처리할 수 있게 해준다.이를 통해 기존 대비 더 많은 동시 사용자 요청을 처리할 수 있고, 비용 효율적인 인퍼런스를 가능하게 한다.Hugging Face Transformers 와도 호환되며, OpenAI API 스타일의 서버도 쉽게 구성할 수 있어 실무 적용이 용이하다.vLLM 은 여러 연구 결과와 기술들을 효과적으로 조합하여 탄생 하였다. LLM 서빙 분야의 발전에 크게 기여 했다고 평가받는 주요 기술은 다음과 같다.• None ORCA : iteration level scheduling + selective batching (LLM 추론에 새로운 스케줄링 방식을 도입한 Friendli AI 의 유경인님 의 논문)vLLM 의 성능에 영향을 주는 옵션vLLM의 설정 항목은 매우 다양한데, 테스트를 거쳐 성능에 영향을 주는 설정들을 골라보았다 (v0.7.0 기준).최대 배치 토큰 크기 등 서비스 시나리오와 관련 있는 설정은 다루지 않았다.Prefix Caching 은 이전 요청의 KV 캐시를 저장해 두었다가, 이후 요청의 prefix 가 겹치는 경우 이를 재활용하는 방식이다.특히 system prompt 가 길게 유지되는 서비스에 효과적이며, TTFT (First Token Latency) 와 throughput 모두에 긍정적인 효과를 준다.TTFT 가 줄어드는 것은 일견 당연한데, throughput 도 서비스 시나리오에 따라 두 배 가까이 향상되기도 한다.ORCA 에서 영향을 받은 vLLM 의 기본 스케줄러는 prefill 작업을 먼저, decode 는 나중 순으로 스케줄링 하는데 이 둘을 섞지는 않는다.이로 인해 compute-bound 한 성격이 강한 다수의 prefill 작업이 한 번에 몰리면 decode 작업들이 밀리면서 평균 TTFT 가 저하되는 현상이 발생한다.Chunked prefill 은 SARATHI 논문의 아이디어를 구현한 것으로, decode 를 우선적으로 스케줄링하고(decode-maximal),남은 배치 영역에 하나의 prefill 을 잘라서(chunked-prefill) 포함시켜 토큰 생성의 효율을 높이는 방식이다.논문에 "P-D 비율이 클수록 throughtput 이 높다", "prefill chunk 마다 KV-cache 억세스에 따른 상당한 오버헤드가 존재한다" 고 하는데 이것이 하나의 prefill 을 사용하는 이유로 생각된다.이러한 이유로 설정 이름에는 chunk 가 들어가지만 chunk size 같은 왠지 있어야 할 것 같은 설정은 존재하지 않는다 (남은 배치 영역과 max-model-len 중 작은값으로 결정됨).• None 두개 이상의 prefill 을 하나의 배치

React-query 중복 호출 문제 해결하기마이리얼트립 고객경험개발팀은 통합 숙소 도메인의 성능 개선을 위해 다양한 페이지에 SSR(Server Side Rendering)을 도입하고 있습니다. 이를 통해 SEO 최적화와 초기 로딩 속도 향상을 기대하고 있으며, 특히 상품 상세, 객실 상세, 옵션 리스트, 검색 결과 페이지에 SSR을 적용하고 있습니다.하지만 적용 과정에서 예기치 못한 성능 저하와 중복 API 호출 문제가 발생하였고, 이를 해결하기 위한 원인 분석과 구조적인 개선이 필요했습니다.이 포스트에서는 단순히 개선 결과를 소개하는 것을 넘어문제를 어떻게 발견했고, 어떤 방식으로 검증했으며, 어떻게 구조적으로 해결했는지에 대해 상세히 기록하고자 합니다.이를 통해 SSR 도입을 고민 중인 다른 개발자분들께도 실질적인 인사이트를 드릴 수 있기를 바랍니다.(참고) 이 글에서는 Next.js v13.5.9와 TanStack Query(react-query) v4.29.12를 기준으로 작성되었습니다.목차SSR 도입 배경과 문제 인식실제 개선 사례와 성능 변화 측정SSR 개발 시 반드시 고려해야 할 설계 포인트결론 - 기술적 디테일을 넘은 구조적 학습1. SSR 도입 배경과 문제 인식도입 배경마이리얼트립의 통합 숙소 페이지는 사용자가 검색을 시작해 상품을 탐색하고 최종적으로 예약을 결정하는 핵심 여정의 중심에 위치한 페이지입니다. 이 페이지의 성능과 사용자 경험은 전환율에 직접적인 영향을 미치기 때문에 초기 렌더링 속도와 SEO(검색 엔진 최적화)를 개선하기 위한 전략으로 SSR(Server Side Rendering)을 도입하게 되었습니다.적용 대상 페이지는 다음과 같습니다. - 숙소 상세 페이지 - 객실 상세 페이지 - 숙소 옵션리스트 페이지 - 숙소 검색 결과 페이지문제 인식SSR을 적용한 이후, 다음과 같은 문제가 나타나기 시작했습니다. - 페이지 진입 시 초기 로딩 시간이 예상보다 길다는 자체 진단 - CSR로 hydration이 완료된 이후에도 로딩 스피너가 계속 노출됨 - FCP(First Contentful Paint), LCP(Largest Contentful Paint) 등 주요 성능 지표가 오히려 악화- 서버 로그 상 동일한 API가 여러 차례 호출되는 현상 발생특히, SSR을 적용한 의도가 클라이언트에서 API 요청을 줄이기 위한 목적이었기 때문에 중복 호출은 치명적인 문제가 될 수밖에 없었습니다.2. 실제 개선 사례와 성능 변화 측정SSR 도입 후 발생한 중복 API 호출과 성능 저하 문제를 해결하기 위해 각 페이지별로 원인을 분석하고 구조를 개선했습니다. 여러 페이지에서 공통적으로 발견된 문제와 그 근본 원인은 다음과 같았습니다.공통 원인 분석1. 구조적 중복 호출: 데이터 요청 로직 설계상 불필요한 중복 호출 발생- 변경 전 흐름 예시 ① fetchQuery로 접근 권한 등 초기 데이터 검증 ② prefetchQuery로 동일한 데이터를 다시 호출 (불필요한 중복) ③ 또 다른 fetchQuery로 데이터를 받아

매출도, 팀도 함께 성장한 브랜드 커머스 프로젝트 이야기안녕하세요, 오늘의집 커머스 프로덕트(Commerce Product)팀 프로덕트 오너(PO) Conan, Soori입니다. 오늘은 브랜드에는 더 나은 비즈니스 환경을, 고객에게는 더 풍부한 선택지를 제공하기 위해 시작했던 '브랜드 커머스 프로젝트'의 여정을 소개하려고 해요.커머스 프로덕트팀은 어떤 팀인가요?커머스 프로덕트팀은 정해진 커리어 패스가 없어요. 서로 다른 배경과 경험을 가진 사람들이 모여 문제를 정의하고 해결하며 사용자 경험을 더 좋게 만들어가는 팀이에요. 다양한 관점이 모이면 더 나은 결론에 도달할 수 있다고 믿기에, 각자의 전문성을 존중하며 함께 오늘의집을 짓고 있답니다.💬 Conan 저는 오늘의집 합류 전 UX리서치, 기획, 데이터분석 등 다양한 도메인과 직군에서 짧지만 폭넓은 경험을 쌓았어요. 새로운 것을 배우고 변화에 적응하는 걸 즐기는 성향 덕분에, 그 과정에서 겪은 시행착오와 경험이 제게 큰 자산이 되었죠. 이런 경험들이 모여 ‘Product Management야말로 내가 가장 잘할 수 있는 일’이라는 확신이 들었고, 커리어를 전환하게 되었습니다. 특히 커머스 프로덕트팀은 제가 흥미를 느끼는 데이터와 고객 경험을 무엇보다 중요하게 여기는 팀이라, 망설임 없이 합류할 수 있었어요.💬 Soori 저는 비즈니스 사이드에서 커리어를 시작했어요. ‘프로덕트’라는 영역조차 몰랐던 대학 시절, 단순히 멋져 보여 지원해 시작했던 커머스 전략 인턴으로 정책팀, 마케팅팀에서 일하면서 카테고리 운영, 프로모션 기획, 상품 속성 관리 등 비즈니스 전반을 경험했어요. 그러다 문득, 문제 해결을 위해 프로덕트팀을 찾는 제 모습을 발견했어요. 결국 팀 이동을 신청했고, 지금은 PO로 일하고 있습니다. 그때 쌓았던 비즈니스 경험들은 지금도 제게 가장 든든한 기반이 되어주고 있어요.오늘의집은 고객이 자신의 취향에 맞는 라이프스타일을 발견하고, 그 감각을 현실로 만들 수 있도록 돕는 플랫폼이에요. 그리고 그 ‘현실’을 완성하려면 취향만큼이나 다양한 상품과 브랜드가 함께해야 하죠. 누군가는 익숙하고 믿을 수 있는 브랜드를 선호하고, 또 누군가는 감각적인 아이템을 찾아 헤매기도 하니까요.그래서 저희는 생각했습니다. ‘취향이 이렇게 다채롭다면 선택의 폭도 그만큼 넓어야 하지 않을까?’ 그리고 그 다양성을 채워주는 브랜드라면, 저마다의 아이덴티티를 지키면서 브랜드와 잘 맞는 고객을 만날 수 있는 공간도 필요하다고요.그렇게 시작됐습니다. 고객의 취향을 가장 잘 만족시키는 라이프스타일 커머스를 만들기 위한, 브랜드 커머스 프로젝트! 🚀브랜드와 고객을 잇는 시도들브랜드 커머스 프로젝트는 지난 반년간 프로덕트팀·마케팅팀·영업팀이 TF를 이뤄 실행한 협업의 결과물이에요. 저희는 크고 작은 제품들을 빠르게 론칭하며, 두 가지 실행 방향을 정리해 차근차근 실현해 나갔어요.첫 번째, 브랜드 노출과 매출을 높이는 기반 만들기판매자가 프로모션을 진행할 때 더 많은 고객과 만날 수 있도록 다양한 도구와 지면을 개발해

기존 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개의 상품들 중에는투어, 티켓, 교통 등 여러가지 상품들이 섞여 있기 때문에, 축약된 제목에는 다른 상품의 맥락이 섞여 있을 수 있죠. 큰 데이터를 한꺼번에 주면 처리를