안녕하세요, 2025년 3월 말부터 약 3개월간 마이리얼트립 AI Lab에서 인턴으로 근무했던 김다연입니다.인턴 생활을 마무리하며 제가 경험했던 일들과 배운 점들을 기술 블로그에 남겨보려 해요.AI 리터러시를 높이기 위해 들어간 곳마이리얼트립의 AI Lab은 사내의 AI 활용 능력(문해력). 즉, ‘AI 리터러시’를 올리는 데 진심인 팀이에요. 이곳에 인턴으로 합류하면서 제 인턴 생활도 시작됐습니다. AI Lab팀은 규모가 작아요. 저와 팀장님, 딱 둘이서 모든 걸 꾸려가야 했어요. 하지만 팀이 작다고 해서 할 일이 적은 건 아니었습니다. 오히려 수백 명의 직원의 리터러시를 올려야 했기 때문에 더 빠르고 유기적으로, 그리고 효율적으로 일해야만 했었어요.입사 전부터 팀에서는 이미 ‘모두의 AI’라는 사내 세션을 진행하고 있었어요. 반복 업무를 자동화하거나, AI를 잘 활용한 사례를 공유하는 자리였어요. 누군가가 문제를 갖고 찾아오면, 우리가 자동화 아이디어를 제시하고, 그걸 실현한 분이 나중에 사례 발표를 하는 방식이에요. 입사하자마자, 저는 이 세션의 발표를 정리하는 사내 블로그 작성 업무를 맡았어요. 발표 영상을 팀장님이 줌으로 녹화해서 전달해주셨고, 저는 그걸 바탕으로 사내 위키 글을 작성했어요. 발표에 참석하지 못한 구성원들도 언제든 내용을 볼 수 있도록 요약과 영상 링크를 정리한 거죠. 위키를 다 올리고 나면 슬랙에 “오늘 모두의 AI 위키 올라왔습니다!”라고 공지도 했답니다.‘AI 김다연’의 탄생그러던 어느 날, 팀장님이 제게 제안을 하나 하셨어요. “다연님, 다연님 인턴 기간이 끝나도 다연님처럼 일하는 웹사이트같은 거 하나 만들어보면 어때요?” 이렇게 ‘AI 김다연’ 프로젝트가 시작됐습니다.‘AI 김다연’ v1은 이런 기능을 가지고 있었어요.영상을 업로드하면 OpenAI Whisper 모델로 자막을 추출하고,자막이 입혀진 영상을 자동으로 만들어 다운로드 또는 드라이브에 저장하고,드라이브에 저장된 영상을 바탕으로 위키 글을 자동 생성,Slack에 해당 위키 글을 업로드 했다고 자동 공지까지!이렇게 콘텐츠 자동화의 처음과 끝을 모두 자동으로 처리하는 시스템을 만든 거예요. 위키에 올라갈 글을 작성하던 저의 업무가, 이젠 버튼 몇 번이면 끝나는 구조가 되었죠.위키 페이지를 작성하고그 위키 문서를 첨부해서 슬랙 공지를 했어요입사 직후의 기억: AI 툴 수요조사 자동화AI Lab에 입사하고 거의 바로 맡게 된 업무도 기억에 남아요. 마이리얼트립에서는 일정 금액 한도 내에서 직원들에게 AI 툴 구독을 지원하고 있었는데, 이를 위해 구글 폼 수요조사를 진행했어요. 문제는 중복 응답이 많았다는 거예요. 같은 이메일로 여러 번 응답이 들어와서 예산 계산에 혼선이 생겼죠. 저는 이를 해결하기 위해 Google Apps Script로 중복 응답을 감지하고 자동으로 처리하는 시스템을 만들었어요. 이 덕분에 재무팀도 수월하게 예산을 관리할 수 있었죠.구글 폼이 입력될 때마다 구글 시트에 한 줄씩 응답이 쌓여요. 중복 이메일인 경우에는 응답 행이 추가

최근 다양한 AI 서비스에서 대형 언어 모델(LLM)을 활용한 검색 기능이 빠르게 확산되고 있습니다.하지만 이러한 모델들이 웹 검색 기반 정보에만 의존할 경우, 도메인 특화 지식, 실시간 정보, 플랫폼 전용 콘텐츠와 같은 특화된 영역에서는 정확한 답변을 제공하기 어렵습니다.이러한 한계를 극복하기 위해, 도메인별로 구조화된 In-house 데이터를 직접 색인하고 검색에 활용함으로써, LLM의 응답 품질을 획기적으로 향상시킬 수 있습니다.특히 일반적인 웹 검색으로는 노출되지 않는 다음과 같은 정보에 대해 정확하고 컨텍스트 기반의 답변을 생성할 수 있다는 점에서 그 의의가 큽니다.이 글에서는 SKT의 다양한 도메인 데이터를 활용한 AI 검색 품질 향상 전략을 중심으로, 검색-생성 통합 구조가 어떻게 구현되고 어떤 차별점을 제공하는지를 살펴봅니다.In-house 데이터는 실시간 웹 검색 기반의 외부 데이터가 아닌, 내부에서 직접 관리하고 있는 데이터를 의미합니다.외부 검색과는 분리된 자체 검색 인프라를 통해 검색되도록 구축되어 있습니다.예를 들어 다음과 같은 데이터들이 이에 해당합니다.이러한 데이터는 도메인 특화되어 있기에, 공개 범용 데이터보다 검색 정확도 및 관련성 측면에서 훨씬 높은 가치를 가집니다.RAG는 대규모 언어 모델(LLM)의 답변 품질을 향상시키는 데 사용되는 기술로,LLM이 응답을 생성하기 전에 외부 데이터베이스나 지식 기반에서 관련 정보를 검색(Retrieval)하여 이를 기반으로 답변을 강화(Augmented Generation)하는 방식을 의미합니다.SKT는 RAG에 필요한 3가지 요소인 하이브리드 검색(Hybrid Retrieval), 쿼리 분석(Query Analysis), 그리고 랭킹 모델(Ranking Model) 최적화 기법을 통해RAG를 구현하며 In-house 데이터를 기반으로 AI 검색 품질을 높이는 방향으로 설계되어 있습니다.첫 번째, Retrieval 알고리즘을 간단하게 살펴보면 아래와 같습니다.내부적으로 높은 수준의 검색 품질 요구를 충족하기 위해 Hybrid retrieval 전략과 알고리즘을 적용하고 있습니다.이를 위해서는 Sparse Retrieval에 필요한 기술을(형태소 분석기, Query Analyzer 등) 내재화 하고 있으며,Dense Retrieval에 필요한 기술(Semantic Embedding Model, Metric Learning 등) 또한 내재화 하고 있습니다.기반 기술들을 바탕으로 Hybrid Search Engine 을 구성하고 Relevance를 최적화 하는 방향으로 전략적으로 사용하고 있습니다.두 번째, 쿼리 분석(Query Analysis)은 사용자의 질문 의도를 명확히 파악하고 검색 성능을 극대화하기 위해 초기 쿼리를 더 효과적인 형태로 변환하거나 분해하는 과정을 말합니다.이는 더 정확한 정보를 검색하여 최종 답변의 품질을 높이는 데 결정적인 역할을 합니다.• None Query reformulation : 사용자의 초기 검색 쿼리(Query)를 더 나은 검색 결과를 얻을 수 있는 형태로 변환하거나 확장하는 모든 기술을 의미합니다. 검색 엔진이 관련성 높은 문서를 찾을 확률을 극대화하기 위한 필수적인 과정입니다.• None Query Expansion : 가장 고전적이면서도 여전히 강력한 기법으로, 원본 쿼리에 관련 용어를 추가하여 검색 범위를 넓히는 전략입니다. 어휘 불일치(Vocabulary Mismatch) 문제를 해결하는 데 효과적입니다.아래 수식은 기본적인 랭킹알고리즘을 표현한 수식입니다.내부적으로는 Recency model, Popularity model 등 다양한 요소를 기반으로 Relevance를 최적화 하는 방향으로 랭킹 알고리즘이 정의되어 있습니다.랭킹모델은 뉴스, 뮤직, 미디어 등 다양한 도메인에 최적화하는 방향으로 정의하고 튜닝되어 있습니다.예를들어 뉴스는 Recency 가중치가 높은 모델로 정의되어 있고 뮤직, 미디어는 Popularity, Recency 가 높은 모델로 정의되어 있습니다.이러한 기술들은 단순히 개별적으로 존재하는 것이 아니라 서로 긴밀하게 연결되어 RAG 시스템의 근간을 이루고 있습니다.특히 Hybrid Retrieval은 Sparse Retrieval의 속도와 키워드 기반 검색의 강점, Dense Retrieval의 문맥적 이해와 높은 Recall 확보 능력을 결합하여 매우 높은 정확성과 유연성을 제공합니다.쿼리 분석은 사용자의 의도를 정밀히 파악하여 검색 정확도를 향상시키며, 랭킹 모델은 검색된 결과를 효율적으로 정렬하고 최적화하여 사용자 경험을 극대화합니다.위에서 설명한 세 가지 핵심 기술을 기반으로 하여, SKT는 다양한 검색 환경과 요구 사항에 유연하게 대응 가능한 Hybrid Search Engine을 설계하고 있습니다.이를 통해 최종적으로는 RAG 시스템이 단순한 AI 검색 도구가 아닌, 실제 환경에서 높은 수준의 검색 품질과 생성 품질을 동시에 달성할 수 있는 강력한 솔루션으로 자리 잡을 수 있도록 구성하고 있습니다.내부적으로는 보다 복잡한 알고리즘과 다차원적인 기술 요소들이 RAG 시스템에 적용되고 있으며, 이러한 기술들은 각 도메인별 특성에 맞추어 최적화되고 정교하게 조율되고 있습니다.예를 들어 뉴스 분야에서는 최신 정보를 반영하기 위해 Recency 모델이 중점적으로 사용되며, 음악이나 미디어 분야에서는 Popularity와 Recency가 조화를 이루는 방식으로 설계됩니다.이처럼 도메인별로 맞춤형 검색 구조를 제공함으로써, RAG 시스템은 폭넓은 활용 가능성과 높은 수준의 검색 및 답변 품질을 보장합니다.각 도메인의 데이터는 성격과 구조가 다르기 때문에, 각 도메인에 특화된 별도의 검색 엔진을 개별적으로 구축합니다.검색 엔진의 색인 데이터와 검색 로직은 밀접한 관계가 있지만 마찬가지로 도메인마다 특성이 다르기 떄문에 검색 로직 또한 최적화 하여 전문성 있는 검색 기능을 제공하는게 필수적입니다.뉴스는 시의성과 신뢰도가 중요한 도메인이지만, 기존에는 웹검색 의존도가 높아 적극적인 활용에 한계가 있었기에 내부 기준 기반의 뉴스 색인을 통해

추론 모델(Reasoning models)은 Inference-time scaling이라고도 불리는, 생성 시간에 더 많은 자원을 투자하여 고품질의 답변을 만들어내는 원리를 적극 활용하는 모델들로,OpenAI의 o1, o3, o4 모델들, Gemini-2.5 pro, DeepSeek-R1처럼 think trace를 거쳐 유저에게 전달할 답변을 생성하는 것이 특징입니다.그런 추론 모델을 잘 만들기 위한 방법들 중 오늘 소개드릴 내용은 어떻게 추론 모델을 학습시킬 데이터를 잘 만들 수 있을까에 대한 논문으로,Qwen2.5-7B-Instruct model의 수학/코드/과학 성능을 비약적으로 상승시킨 결과롤 소개하고 있습니다.Open Thoughts에는 Stanford, University of California Berkeley, University of Washington, Bespoke Labs, UT Austin 등 다양한 소속의 연구자들과 엔지니어들이 소속되어있으며,저에게는 Alpaca 시리즈로 유명한 Tatsunori Hashimoto 교수님과, 최근에 Allen Institute of AI/UW 에서 각각 NVIDIA/Stanford 로 소속을 옮기신 최예진 교수님이 익숙한 저자입니다.Open Thoughts에서는 추론 모델 학습 데이터를 만드는 과정에서 엔지니어링이 필요한 변수들을 다양하게 탐색해보기 위해,파이프라인의 한 단계씩에서 평가를 통해 수학/코드/과학 벤치마크에서 전반적으로 가장 우수한 성능을 낸 방식을 채택하여 다음 단계를 진행하는 식으로 실험이 진행되었습니다.이 글에서는 Open Thoughts 논문에 소개된 다양한 실험들을 정리해보면서, 저의 생각도 함께 정리를 해볼까 합니다.• None 문제별로 Teacher model 답변을 여러개 생성하는건 효과적이고, 성능상의 이점도 크다.• None 꼭 teacher 성능이 좋은 teacher를 보장하는건 아니고, QwQ-32B가 DeepSeek-R1보다 좋은 teacher일 수 있다.• None 답변 verification이나 filtering이 성능 향상에 크게 영향을 주지는 않는다.• None 데이터 소스들 중 질문난이도 평균 점수 기준 top8 뽑는거보다 top 1, top 2 뽑는게 나았다.• None 질문의 난이도나 답변길이 필터링이, embeddings나 fastText filtering보다 나았다.• None 프로젝트 진행과 성능 향상 과정• None OpenThoughts 114K: 기존 데이터들 합치고 오답 filtering• None 별다른 얘기가 없으면 각 단계 실험용으론 31600개 sample로 구성하고, DeepSeek-R1으로 답변 생성한 dataset으로 실험했다고 합니다.• None• None Top N 개 data sources 중 31600/N개씩 random sample 해서 데이터를 구성해본 실험 결과• None 여러개 데이터 고르지 말고, 분야별 top1~2에서만 고르자는 결론을 낼 수 있었다고 합니다.• None 최종 선택된 5개 Sources는 다음과 같습니다.• None Math: OpenMath-2-Math (이 데이터의 크기가 커서 1개만 선택)• None• None 5개 소스로부터 이번엔 random sample하지 말고, 필터링 방법을 다양하게 해보면• None Math나 science는 GPT 답변 길이로, Code는 질문 난이도 GPT 평가로 filtering한게 가장 좋았다고 합니다.• None• None 답변당 답변 개수 여러개로 만들고, 중복 제거(deduplication)도 다양한 방법으로 해보니• None 16개 answers 좋았고, Math나 science는 exact dedup, code는 no dedup이 좋았다고 저자들은 적어두었습니다.• None 16개 answers 로 고정하면, code는 fuzzy, math는 exact dedup, science는 no dedup이 좋았다고도 해석할 수 있을 것 같습니다.• None 제가 이 표의 결과를 정리한다면• None Code는 문법이 좀 더 strict하기때문에 variability가 낮아서 4개 답변정도, Math/science는 16개 답변정도가 좋고• None 대부분의 deduplication 방법들은 숫자를 무시하기 때문에, 숫자가 많이 들어간 Math는 dedup의 의미가 크지 않거나, 숫자가 바뀜으로써 결과가 달라지는 것도 배워야 한다고 생각하면 수학은 dedup하지 않는 것이 괜찮고, code는 문제를 deduplication 하는 것이 나았다고 할 것 같습니다.• None• None• None 일반적으로 상상하기에는 답이 맞았는지/틀렸는지가 추론 능력 향상에 굉장히 중요한 요소일거라 생각하지만, 의외로 그런 검증 방법이 성능 향상에 도움이 되지 않는다고 합니다.• None 심지어 최종 실험을 진행한 공개된 학습 데이터의 62% 정도는 추론 trace도 끝나지 않은 데이터인데, 이를 제거하여 학습하면 성능의 저하가 심해서, 모두 포함하여 학습했다고 합니다.• None Embedding model을 사용한 필터링이 추론능력 향상에는 큰 도움이 되지 않았다는 점도 주목해볼만 합니다.• None 참고로, 답변이 맞았는지 틀렸는지를 verification한 방법에 대한 detail은 appendix에 있으니 궁금하신 분들은 확인해보셔도 좋겠습니다.• None• None 답변을 어떤 모델로 생성한게 나았나 보니• None 의외로 R1에 비해 benchmark 성능은 낮지만, QwQ-32B로 distillation 하는 것이 낫다는 것이 밝혀져, 이 이후로는 QwQ-32B 를 teacher model로 사용했다고 합니다.• None LIMO 등에서 주장된것과 달리 31.6k까지 데이터 늘려보면서 실험해보니 데이터 많아질수록 좋아지는 추세가 아직 있어서, 데이터 더 추가하기로 했다고 합니다.• None 최종 1.2M 만든 pipeline은 다음과 같습니다.• None 1.2M 까지 증가시키며 Scaling experiments를 더 해본 결과• None 1.2M 까지 데이터가 늘어날

안녕하세요, 무신사 QA팀 서비스 파트에서 상품 QA를 담당하고 있는 임예슬입니다. 업무를 하며 일을 더 효율적으로 할 수 없을까? 고민하는 편인데요. 그 고민의 결과로 QA팀의 생산성을 높인 경험이 있어 공유드리려 합니다.QA팀(Quality Assurance)에서 통합테스트를 진행하면서 결과리포트를 받아보셨을텐데요! QA담당자가 작성하는 리포트는 어떻게 생성되는지 궁금증을 가져본 적 없으신가요? (무신사에서는 이러한 보고서를 Daily Report 와 Final Report 라는 명칭으로 발행하고 있습니다.)구 버전의 Daily Report현재 발송되는 리포트를 보니 몇 가지 개선해 볼 만한 항목이 보였습니다.엑셀 기반으로 데이터를 관리함에 따라 휴먼 에러(Human Error)의 가능성이 있었습니다.입력된 테스트 수행 데이터를 데이터베이스화하면, 향후 BI(Business Intelligence)도구 등을 활용한 대시보드 구성을 통해 QA팀 뿐만 아니라 유관 부서에도 유용한 인사이트를 제공할 수 있겠다고 판단했습니다.양식은 표준화되어 있지만, 화면을 캡쳐해서 표를 첨부하는 방식 때문에 작성자나 모니터의 해상도에 따라 표의 크기가 일정하지 않은 문제가 있었습니다.작업 목표수기 입력의 비효율성과 오류 발생 가능성을 줄이고자 API를 통해 수집가능한 데이터는 최대한 활용하려 합니다.BI(Business Intelligence) 도구에서 쉽게 가공할 수 있도록 데이터를 구조화해서 데이터베이스에 저장하려고 합니다.누구든 동일한 양식의 리포트를 빠르게 생성할 수 있어야 합니다.환경 구성QA 팀에서는 웹 자동화 테스트 수행 시 Python 언어를 사용하기 때문에, 향후 유지보수성과 작업 효율성을 고려해 Python 언어로 선정했습니다. 수집된 데이터는 Flask 웹 프레임워크를 활용하여 API 응답값과 DB 데이터를 웹 에서 조회할 수 있도록 구성했습니다.Daily ReportDaily Report사용자는 기존 방식대로 과제별 테스트를 진행한 후, QA Admin 화면에서 해당 과제를 선택하면 영역별 테스트 진행률과 결함 현황이 자동으로 표시됩니다. 여기에 추가 의견만 직접 입력하면 Daily Report 가 손쉽게 완성됩니다.자동생성한 Daily ReportQA Admin에는 Daily Report 출력 기능 외에도 과제 수행데이터 입력, 웹 자동화 테스트에 사용되는 xPath 관리, 앱 리뷰 데이터 관리 기능이 포함되어 있습니다.QAT 수행데이터QAT 수행데이터QA 종료 후 수행한 과제에 대한 데이터를 입력하는데, 이전에는 결함 관련 데이터(결함 건수, 반려 건수)를 수기 입력하였다면, API를 통해 데이터를 불러와 사용자의 입력부담을 줄였습니다. 기입된 정보들은 QA 범위 산정과 과제 분석에 유용한 자산이 되고 있습니다.앱리뷰 관리무신사 앱에 등록되는 리뷰를 크롤링하여 자동으로 수집하고 있고, 해당 데이터를 데이터베이스에 저장하도록 구성했습니다.수집된 리뷰는 유형별로 분석한 뒤 대시보드 형태로 관리하고 있습니다.XPath 관리무신사 웹 자동화 수행 시 사용하는 XPath도 QA Admin 에서 관리하고 있습니다. (자세한 내용은 호철님의 이전 블로그 글을 참고해 주세요.) 이를 통해 웹 자동화 유지보수의 30% 정도 차지하는 XPath 수정 관련 빌드 시간을 단축하고, 유지 보수는 더 효율적으로 할 수 있게 되었습니다. QA Admin 을 기획할 때, 엑셀로도 잘 하고 있는데, 굳이 시스템까지 만들어야 하나? 하는 고민도 있었습니다. 하지만 단순히 입력을 편하게 하려는 게 아니라, 기준 데이터를 일원화하고, 등록된 정보를 바탕으로 더 의미 있는 인사이트를 얻는 데 초점을 두었습니다. QA Admin 을 QA 팀 내에서 오픈하면서 팀원들의 테스트를 통해 정말 많은 이슈들을 발견할 수 있었는데요. 사실 개발 단계에서는 제가 직접 여러 번 테스트해봤다고 생각했는데, 막상 QA팀이 본격적으로 테스트에 들어가자 제가 미처 발견하지 못했던 다양한 이슈들이 쏟아졌습니다.QA팀원들의 날카로운 관점과 꼼꼼한 검증 덕분에 사소하지만 중요한 문제들도 빠짐없이 찾아낼 수 있었고, 이 경험을 통해 QA 관점에서 개발된 서비스를 바라보는 시각이 얼마나 중요한지 다시 한 번 느꼈습니다.앞으로는 QA Admin 은 여러 차례의 배포를 통해 오류를 점진적으로 개선하고, 필요한 기능도 꾸준히 추가되고 있습니다.아직 완벽하진 않지만, 앞으로 QA 업무를 더 효율적으로 만들어줄 핵심 도구로 성장시킬 계획입니다. 단순한 도구를 넘어, QA 프로세스를 혁신할 수 있는 플랫폼으로 발전시키는 것이 목표입니다!MUSINSA CAREER무신사 QA팀은 품질을 문화로 만들어, 사용자에게 신뢰할 수 있는 서비스 경험을 제공하는 것을 지향합니다.웹, 모바일 앱, 백엔드 API 등 다양한 영역에서 지속 가능한 품질 확보를 목표로, 자동화, 테스트 전략, 모니터링을 체계적으로 운영합니다. 또한, 기획·설계 단계부터 품질을 함께 설계하며 조기 결함 예방에 힘쓰고, 개발, 기획, CS, 운영 등 전 부서와의 유기적인 협업을 통해 품질 책임을 조직 전체로 확장합니다.테스트 결과, 결함 데이터, 고객 피드백을 수치화하여 데이터 기반으로 품질을 진단하고 개선 방향을 제시하는 것 역시 무신사 QA팀의 핵심 역할입니다.우리는 테스트를 넘어, 무신사의 서비스 가치와 고객 신뢰를 함께 만들어 갑니다. 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요) 팀 무신사 테크 소식을 받아보는 링크드인 무신사 테크 블로그 29CM 테크 블로그 무신사 테크 유튜브 채널채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!무신사 QA 팀은 어떤 도구를 업무에 사용할까? was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

오늘은 리서치 플랫폼팀과 리서치팀이 협업해 만든 ‘리서치 자율주행 프로젝트’ 이야기를 들려드리려고 해요. 리서치 자율주행 프로젝트는, UX 리서처의 도움 없이도 팀원 혼자서 필요한 리서치를 찾아서 수행할 수 있는 환경을 만드는 프로젝트예요. 리서처 수빈님과 리서치 오퍼레이터 매니저 소희님을 만나서 두 팀이 어떻게 목표를 맞추고 협업하게 되었는지 이야기를 들어봤어요.토스에서는 다양한 서비스가 운영되고 있어요. 서비스가 늘어날수록 팀원들의 리서치 수요도 함께 늘어났는데, 리서처 수는 한정적이었어요. 그래서 리서치팀에게는 리서처의 도움 없이 팀원 스스로 필요한 리서치를 수행할 수 있는 환경을 만드는 게 중요한 과제였어요. 그래서 ‘리서치 자율주행 프로젝트’를 시작하게 됐죠. 리서처와의 미팅 없이도, 내게 맞는 리서치가 어떤 것인지 파악할 수 있게 하고 싶었어요.초기에는 리서치팀 안에서만 이 문제를 풀려고 했어요. 첫 시도로 구글폼을 활용해 리서치 신청 프로세스를 정형화해보려 했죠. 팀원이 조사 목적과 배경을 폼에 입력하면, 별도 미팅 없이 리서치 방향을 잡을 수 있도록 하려 했어요.1년 동안 구글폼을 활용해봤었는데, 결과적으로는 미팅이 줄지 않더라고요. 제품팀이 어떤 리서치를 하고 싶은지는 알 수 있었지만, 리서치가 필요한 맥락을 충분히 파악할 수 없었거든요.예를 들어, 구글폼에 나와있는 "퍼널 이탈 이유를 알고 싶어요" 같은 단편적인 정보만으로는 적합한 리서치 방법을 결정하기 어려웠어요. 퍼널의 맥락, 유용성 검증 여부 등 추가적인 정보가 필요했던거죠. 결국 리서처가 추가 미팅을 제안하는 경우가 많았고, 미팅 수는 줄지 않았어요.게다가 팀원 입장에서도 구글폼 작성이 번거로웠어요. 리서치 배경, 리쿠르팅 정보 등 입력 항목이 많다 보니 중도 포기하는 사례도 있었어요. 방식 자체를 개선해야 겠다고 생각했고, 이때부터 리서치 플랫폼팀과 협업하게 됐죠.리서치플랫폼팀은 일반 팀원들이 더 쉽게 유저 리서치에 접근할 수 있는 환경을 만드는 것에 집중하고 있는 팀이에요. 자율주행 프로젝트의 목표는 그런 환경을 만드는 것 보다는, 리서처 리소스 절감이라고 생각해서 처음부터 협업하지는 않았었죠.하지만 점점 팀원들이 리서치에 관심을 가지면서, 리서처가 해야 할 일도 함께 늘어난다는 것을 알게 됐어요. 팀원 리서치 활성화와 리서처 리소스 효율화는 결국 같은 문제의 양면이었던 거죠. 그렇게 자연스럽게 목표가 정렬됐고, 리서치 자율주행 프로젝트에 참여했어요.먼저 문제를 다시 정의했어요. 구글폼 작성 이후에도 미팅을 요청하는 사례들을 살펴보니, 같은 요청이라도 리서처마다 대응이 다르다는 문제가 있었어요. 리서처마다 생각하는 리서처의 역할이 조금씩 다르다 보니, 안내 방식뿐 아니라 미팅에서 파악하는 정보에도 차이가 있었어요.리서치 자율주행이 제대로 작동하려면, 팀원들이 자주 하는 리서치 요청에 대해 리서처들의 공통적인 기준을 세우는 게 먼저라는 생각이 들었어요. 그래서 모두 모여 워크샵을 하는 걸 제안했죠.워크숍에서는 리서처들이 함께 모여, 같은 요청에 대해 어떤 질문

ConfigMap 변경을 자동으로 반영하는 GitOps 구성을 하기 전까지, 우리 팀은 다음과 같은 방식으로 작업을 진행하고 있었습니다.개발자들이 ConfigMap에 추가하거나 수정해야 할 값이 생기면,제가 ArgoCD와 연결된 Git 저장소 내 ConfigMap 정의 파일을 직접 수정하고, 커밋한 뒤, 관련 파드를 수동으로 재시작(rollout restart)해주는 방식이었죠.이 작업은 표면적으로는 단순해 보이지만, 운영팀 전체 리소스의 반복적인 소모를 유발하고 있었고, 개발자 입장에서도 빈번한 요청을 전달하는 데 부담이 따를 수밖에 없었습니다.이러한 불편함을 줄이고, 더 나아가 자율적인 설정 관리가 가능하게 만들 수 없을까 고민하게 되었습니다.그래서 저는 다음과 같은 질문을 중심으로 접근을 시작했습니다:• None 우리가 이미 보유한 기술 스택으로 해결할 수 있는 문제인가?• None 개발자들이 직접 ConfigMap을 컨트롤할 수 있는 방식은 무엇인가?• None ConfigMap이 수정되었을 때, 자동으로 관련 파드를 재시작할 수 있는 툴이나 프로젝트가 존재하는가?여러 대안을 비교해본 결과, 우리 팀의 GitOps 구조에 가장 잘 맞는 해법은 Reloader + Argo CD 조합이었습니다.주요 이유는 별도의 커스텀 로직 없이도 단순하게 적용 가능하고, DevOps팀이 직접 개입하지 않아도 개발자들이 설정을 변경했을 때 곧바로 반영된다는 점이었습니다.Reloader를 간단히 설명드리자면, Reloader는 Kubernetes에서 ConfigMap이나 Secret 리소스에 변경이 감지되면,해당 리소스를 참조하고 있는 Deployment나 StatefulSet을 자동으로 재시작해주는 컨트롤러입니다.저희 팀은 이미 Kustomize + Argo CD 조합으로 GitOps 기반의 배포 환경을 운영하고 있었고,애플리케이션 리소스들과 함께 ConfigMap도 하나의 배포 단위로 포함되어 있었습니다.하지만 이 구조에서는 ConfigMap만 수정하려 해도 전체 애플리케이션 리소스를 함께 변경해야 했기 때문에, 설정 관리의 유연성이 떨어지고 커밋 단위도 무거워지는 문제가 있었습니다.그래서 저는 먼저 ConfigMap을 분리했고, ConfigMap만 별도로 관리할 수 있도록 GitOps 구조로 변경했습니다.변경 후 개발자분들은 직접 ConfigMap을 수정하면, Argo CD를 통해 해당 변경이 자동으로 동기화되고,Reloader가 이를 감지하여 관련 Deployment가 자동으로 재시작되는 것을 확인할 수 있었습니다.글로만 보면 다소 이해가 안될 수 있기 때문에, 그림을 보면서 다시 설명드리겠습니다.저희는 먼저 ConfigMap을 별도의 Git 저장소로 분리했고, Argo CD가 해당 저장소를 바라보도록 설정했습니다.그리고 Reloader가 클러스터 내 ConfigMap 리소스를 watch하도록 구성했으며, 이후에는 ConfigMap 값에 변경이 생기면,이를 참조하고 있는 리소스를 자동으로 rollout restart하도록 설정했습니다.example 네임스페이스에서 사용되는 ConfigMap들을 Kustomization으로 관리할 수 있도록 설정합니다.ConfigMap에 reloader.stakater.com/match: "true" 어노테이션을 추가하여, Stakater Reloader가 이 ConfigMap의 변경을 감지할 수 있도록 합니다.ArgoCD에서 ConfigMap 리소스를 관리할 수 있도록 kustomize 경로를 지정하여 자동 동기화가 가능하게 구성합니다.해당 Deployment가 참조 중인 ConfigMap 변경을 감지할 수 있도록 reloader.stakater.com/search: "true" 어노테이션을 추가합니다.이번 구조 개선을 통해 ConfigMap 변경 작업이 더 이상 번거로운 수작업이 아닌, GitOps 기반으로 자동화되었습니다.비록 작은 구조적 변화였지만, 개발자와 운영자 모두의 부담을 크게 줄일 수 있었고, GitOps의 진정한 장점을 팀원들과 함께 체감할 수 있는 계기가 되었습니다.앞으로도 이런 작지만 실용적인 개선을 꾸준히 이어가 보려 합니다.

우리는 다양한 상황에서 음성으로 AI와 대화하고 있습니다. 대부분의 음성 챗봇은 사용자의 입력이 끝나야 다음 단계가 진행되는 순차 처리 방식입니다.• None STT (Speech-to-Text): 사용자의 음성을 텍스트로 변환• None LLM (Large Language Model): 변환된 텍스트를 기반으로 AI 응답 생성• None TTS (Text-to-Speech): 생성된 텍스트 응답을 다시 음성으로 합성이 구조는 음성을 → 텍스트로 → 생각하고 → 다시 음성으로 바꾸는 방식으로 동작하고 있습니다.그런데 이 구조에는 두 가지 한계를 가지고 있습니다.• None 챗봇이 음성으로 응답하는 동안에는 사용자가 말을 시작할 수 없습니다.• None 즉, 사람이 대화 중 끼어들 듯 말하는 barge-in 기능이 지원되지 않아, 실제 대화처럼 자연스럽게 주고받는 흐름이 어렵습니다.• None 음성 입력 → 텍스트 변환(STT) → 응답 생성(LLM) → 음성 합성(TTS) 과정을 순차적으로 거치기 때문에, 각 단계의 처리 시간이 누적되며 전체 응답 속도에 영향을 줍니다.사람과의 자연스러운 대화처럼, 말이 겹치고 바로 반응하는 진짜 실시간 대화란 어떤 모습일지에 대해 고민해보게 되었습니다.여기서 말하는 ‘실시간’은 단순히 빠른 응답이 아니라, 사용자와 챗봇이 동시에 말하고, 끊고, 반응하는 자연스러운 상호작용을 의미합니다.이러한 경험이 가능할지 탐색하는 과정에서, 우리는 OpenAI의 Realtime API를 테스트해보며 그 가능성을 살펴보게 되었습니다.OpenAI Realtime API는 멀티모달 모델(GPT-4o 및 mini) 을 기반으로 한 초저지연(ultra low-latency) 양방향 인터페이스입니다.WebSocket 또는 WebRTC 연결로 텍스트와 오디오를 동시에 스트리밍하고, 실시간 음성 대화를 구현할 수 있게 만들어졌습니다. (Speech-to-Speech)OpenAI Realtime API는 다음 두가지 연결 방식을 지원합니다.우리는 기존의 백엔드 시스템에서 관리할 수 있도록 WebSocket을 활용하여 서버 - 서버 연동을 테스트해보았습니다.클라이언트에서 실시간으로 음성 데이터를 서버로 전송하면, 서버는 이를 OpenAI Realtime API에 전달하고, 응답 결과(음성 또는 텍스트)를 다시 실시간으로 클라이언트에 전달하는 구조입니다.서버는 이 과정에서 중계와 함께 DB에서 프롬프트 설정을 조회하거나, 로그를 저장하는 등 비즈니스 로직도 함께 처리할 수 있습니다.그리고 OpenAI Realtime API와는 WebSocket 연결을 유지한 채, 스트림 기반으로 상시 통신하고 있습니다.4. Go Channel과 Goroutine으로 WebSocket 양방향 스트림을 쉽게 다뤄보자우리가 목표로 했던 것은 WebSocket 기반 OpenAI Realtime API와의 실시간 양방향 통신을 안정적이고 명시적으로 다루는 것이었습니다.WebSocket을 사용하면 다음과 같은 이유로 구현이 복잡해질 수 있는데요.• None 하나의 스트림에서 동시에 송수신이 일어나야 합니다. (별도의 스레드, 비동기 핸들링 구조 필요)• None 연결 종료, 네트워크 오류, 타임아웃 등 다양한 실패 케이스가 송수신 양쪽에서 다르게 발생하므로 예외 처리가 분산될 수 있습니다.• None 연결 상태를 mocking하거나 제어하기 어렵습니다.이를 위해 Go에서 제공하는 채널(channel) 과 고루틴(goroutine) 을 활용했습니다.Go의 chan(채널)은 Goroutine 간 데이터를 주고받을 수 있는 안전한 통신 수단입니다.간단히 말하면, 두 개의 흐름 사이에 데이터를 흘려보내는 파이프 같은 개념입니다.goroutine Go의 초경량 스레드로, 함수 하나를 동시에 실행시키는 비동기 작업 단위입니다.수천 개를 띄워도 메모리 부담이 거의 없기 때문에, WebSocket처럼 동시에 여러 작업이 일어나는 환경에서 특히 유용합니다.그래서 우리는 Go의 chan과 goroutine 조합을 사용해 읽기와 쓰기, 에러 처리, 종료 흐름을 명확히 분리하고 구조화했습니다.그 결과, 내부 로직은• None 채널에서 꺼내는이처럼 데이터 흐름을 명확히 분리한 덕분에 WebSocket의 읽기/쓰기 처리뿐 아니라 에러 핸들링과 종료 처리까지도 직관적으로 구현할 수 있었고, 테스트 작성 역시 수월해졌습니다이후 서비스 로직에서는 session의 In과 Out 채널을 통해 메시지를 주고받기만 하면 되므로, WebSocket 처리에 직접 관여하지 않고도 실시간 흐름을 간결하고 편리하게 구현할 수 있습니다.이번 글에서는 OpenAI Realtime API가 무엇인지, 그리고 어떤 상황에서 활용할 수 있는지부터 이를 Go의 goroutine과 channel을 활용해 실시간으로 연결하는 구조까지 함께 살펴보았습니다.복잡할 수 있는 WebSocket 스트림도, Go의 채널을 활용하면 직관적인 흐름으로 추상화할 수 있다는 것을 확인할 수 있었고,이를 통해 실시간 음성 응답 흐름을 안정적이고 효율적으로 구현할 수 있었습니다.Realtime API는 현재 베타(Beta) 단계로, 지속적으로 발전 중인 기술입니다.실제 서비스에 안정적으로 적용하기 위해서는 프롬프트 설정, 보이스 옵션, 그외 여러 파라미터 등 다양한 기능들을 상황에 맞게 테스트하고, 최적의 조합을 찾아가는 과정이 필요했습니다.하지만 그만큼 앞으로 더 많은 기능이 추가되고, 더 나은 성능과 커스터마이징 옵션들이 제공될 것이라는 기대도 큽니다.Go의 channel과 goroutine은 이러한 실시간 스트리밍 구조에 매우 강력한 도구입니다.이번 예제를 바탕으로, 여러분의 프로젝트에서도 채널 기반의 구조를 다양하게 시도해 보시길 추천드립니다. 😄

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용유저 세그먼트를 손쉽게 정의하고, 이를 다양한 액션 채널(Braze, IDS, GAM 등)과 자동 연동할 수 있는 네이버 웹툰의 Cohort System을 소개합니다. 조건 기반 필터링, ML 모델 연동 등 다양한 방식으로 세그먼트를 만들고, 중복 제거 로직과 함께 효율적으로 활용할 수 있습니다. 시스템 구조와 기술 스택, 실제 마케팅 활용 사례까지 함께 공유하며, 데이터에서 인사이트, 나아가 액션까지의 연결을 어떻게 자동화했는지를 설명합니다.강의 대상데이터 엔지니어 / 백엔드 엔지니어: 데이터 흐름 자동화, 시스템 구조에 관심 있는 분ML 엔지니어 / 데이터 사이언티스트: ML 결과를 실시간 타겟팅에 적용하고 싶은 분마케터 / PM: 타겟 유저 추출과 액션 전환까지의 전체 흐름을 이해하고 싶은 분목차Episode 1: 데이터 추출, 아직도 수작업으로 하시나요?반복과 오류, 그리고 비효율의 문제Episode 2: 웹툰의 코호트 시스템코호트 시스템의 구조와 흐름Episode 3 : Data 연결: 코호트에서 액션으로ML 모델IDSBrazeGAMEpisode 4 : Data 확장: 코호트에서 코호트로코호트 간 중복 제거 기능Episode 5: 캠페인 사례로 본 Cohort System의 효과코호트 시스템은 어떻게 쓰여질까? NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2025(5월)의 일부 세션을 공개합니다.

기술 문서는 늘 부족합니다. 특히 좋은 기술 문서가 부족하죠.테크니컬 라이터는 좋은 기술 문서를 쓸 수 있지만, 사내 프로젝트를 모두 담당하기에는 수가 턱없이 모자랍니다. '개발자 글쓰기 교육'으로 그 간극을 메워보려는 시도도 있지만, 과연 교육만 들으면 모든 개발자가 기술 문서를 잘 쓰게 될까요?글쎄요, 저는 회의적입니 다. '잘 쓰는 방법을 몰라서'는 개발자가 기술 문서를 쓰지 않는 원인 중 하나일 뿐, 전부가 아니니까요. '시간'이나 '관심' 같은 외부적 원인은 교육으로는 해결하지 못합니다.문서 엔지니어로서, 저는 이 문제를 '개발자 교육'보다 '엔지니어링'으로 풀어보려고 노력해 왔습니다. 프로세스를 통한 강제화, 도구를 이용한 자동화로요. 생성형 AI가 글 쓰는 직무를 대체할 것이라는 예측도 있지만, 이런 관점에서 볼 때 도큐먼트 엔지니어에게 AI가 반드시 경쟁자인 것만은 아니더군요. 오히려 기존의 한계를 극복하게 해주는 기회에 가깝죠. 비유하자면, 테크니컬 라이터가 한 땀 한 땀 공들여 문서를 만들어 내던 가내수공업 방식을 공장형 자동 생산으로 바꿀 기회랄까요.LINE Plus의 Document Engineering 팀은 이런 마음가짐으로 AI를 꾸준히 활용해 왔고, 덕분에 그 아이디어를 시험해 볼 기회를 얻었습니다.LY 그룹은 업무에 생성형 AI를 도입하는 데 적극적입니다. 그 일환으로 주요 개발 단계에서 생성형 AI를 활용하는 프로젝트를 진행 중인데요. 대상 작업 중 하나가 문서화입니다.저희 팀은 프로젝트를 시작하면서 문서화 생산성을 높이겠다는 목적 아래 개발 단계에서 가장 필요한 문서가 무엇일지 한참 고민했습니다(프로젝트 자체 요구 사항을 참고해서요). 몇 가지 아이디어가 있었고, 그중 소스 코드를 이용하면서 개발자나 사용 자에게 모두 영향을 미치는 API 레퍼런스 문서에 적용해 보기로 했습니다.소스 코드를 설명하는 기능은 GitHub Copilot 같은 코딩 어시스턴트가 이미 잘하고 있는데 '뭘 더 하려는 것일까?'하는 의문이 생기실 수도 있겠네요. 아쉽게도 코딩 어시스턴트로는 해결하지 못하는 문제가 몇 개 있습니다.더불어 프로젝트마다 API 문서 형식도 다르고 배포하는 곳도 달라서 참고하기 어렵다는 개발 팀 의견도 있었습니다. 코딩 어시스턴트는 이것도 해결하지 못하죠. 따라서 저희는 '사내 정보를 참고해서 사내 스타일에 맞는 API 주석을 작성하고, 이를 레퍼런스로 만들어 한곳에서 배포하기'를 목표로 삼아 프로젝트를 시작했습니다.저희 팀은 기술 문서를 검토하고 다국어화한 경험이 많습니다. 이미 몇몇 프로젝트에서는 문법, 표현, 스타일 일관성을 확인하는 용도로 프롬프트를 만들어 AI를 활용하고 있고요.사내 스타일 가이드에 맞춰 일관된 톤과 스타일을 유지하려면 꽤 긴 프롬프트가 필요합니다. 여기에 프로그래밍 언어별로 상세한 API 주석을 작성하는 방법과 용어 정보까지 더했더니 LLM이 몇몇 지시를 놓치기 시작했습니다(LLM도 지시가 많으면 기억력이 떨어지나 봅니다). 그러잖아도 사내 머신 러닝 팀 전문가의 도움을 받고 있었던 터라 개선 방안을 여쭸더니, 실행 단계를 나누고 단계별로 수행할 프롬프트를 분리하라고 하시더군요.처음에는 아래와 같이 세세하게 단계를 나눴습니다.

신용대출 찾기 서비스는 다양한 제휴사의 대출 상품을 연동하여, 고객이 보다 편리하게 대출 상품을 탐색하고 신청할 수 있도록 돕는 서비스입니다.이번 글에서는 신규 제휴사 연동 이후 제휴사의 테스트 서버가 유효한 응답을 주지 않거나, 특정 케이스를 테스트하기 어려운 상황을 어떻게 해결했는지, 그리고 이를 위해 설계한 mock 서버를 소개하고자 해요.신규 제휴사 연동 이후 다음과 같은 문제들이 반복적으로 발생했어요.• None 특정 퍼널 또는 고객 조건에 맞는 테스트 데이터 확보의 어려움• None 테스트 과정에서 실제 제휴사 서버로부터 유효한 응답을 받기 어려운 상황이러한 문제들은 QA 및 신규 기능 개발 효율을 떨어뜨릴 뿐 아니라, 서비스 출시 일정에도 영향을 주었습니다. 이를 해결하기 위해 사용자, 제휴사, 퍼널 단위로 정밀하게 동작을 제어할 수 있는 mock 서버를 설계했어요.본격적인 설명에 앞서, 대출 도메인과 관련된 주요 용어를 간략히 정리할게요.• None : 은행, 저축은행, 보험사 등 대출 상품을 제공하는 금융기관• None : 고객 정보를 활용해 대출 금리, 한도 등을 간단히 확인하는 행위• None : 가심사 결과를 바탕으로 고객이 특정 상품에 대해 대출을 신청하는 행위• None : 제휴사가 고객 정보를 활용해 대출을 실행하고 자금을 입금하는 행위기능적 / 비기능적 요구사항은 아래와 같았어요.mock 서버는 다음과 같은 구성요소로 설계되었습니다.신용대출 찾기 서비스는 mock 동작 여부나 mock 데이터 생성 시 필요한 유저 정보를 클라이언트 요청의 헤더를 통해 주입받습니다. 이렇게 하면 비즈니스 로직에는 전혀 영향을 주지 않고, 테스트를 유연하게 제어할 수 있어요.• None RestTemplate에는 인터셉터를 통해 요청마다 헤더를 추가할 수 있어요. 아래는 유저 ID와 원장 ID를 주입하는 예시입니다.• None 에 등록하면, 모든 제휴사 요청에 자동으로 헤더가 포함됩니다.• None WebClient에서는 을 활용해 헤더를 주입해요. 아래는 동일한 목적의 필터 예시입니다.• None 와 같이 등록해주면 돼요.모든 설정값은 DB 테이블에서 관리하여 유연성을 확보했어요.• None• None 콜백 을 N 초 후에 받을 것인지• None 특정 퍼널 에 대해 어떤 mock 응답을 받을 것인지 등정의된 정보를 사용해 mock 응답 을 생성합니다.mock 서버에서는 실제 제휴사처럼 콜백 응답을 지연하여 전송하는 기능이 필요합니다. 이를 통해 비동기 응답을 테스트할 수 있도록 지원하며, 실제 서비스 환경을 더 현실감 있게 시뮬레이션할 수 있어요.예약은 다음과 같이 두 단계로 구성됩니다.• None 가심사 조회나 대출 신청 API 호출 시점에,• None 각 요청에 대해 몇 초 후 콜백을 호출할 지 결정되며, 이 설정은 유저 설정( )에 정의된 값을 사용합니다.• None 필드에 실행 시점을 기록합니다.• None mock 서버에서는• None 를 사용해 콜백 API 요청을 실제로 전송합니다.mock 응답은 실제 제휴사 응답과