안녕하세요, 토스페이먼츠 김용성, 하태호입니다.지난주, 토스페이먼츠에서 PG업계 최초로 MCP를 소개하면서 많은 분들이 관심가져 주셨는데요. 이 글을 통해 MCP 서버 구현 과정과 그 안에서 얻은 러닝을 공유하고자 해요.* 길드(guild): 서로 다른 팀이나 사일로에 속한 팀원들이 느슨하게 모여 공통의 관심사를 공유하는 조직먼저 이해를 돕기 위해 짧은 시연 영상을 준비했어요. 외부 개발자분들이 토스페이먼츠 MCP를 활용해서 주문서 페이지를 만드는 상황에 대한 예시입니다. 로딩이나 일부 수정 과정은 생략했고, Claude 4 모델을 사용했습니다.토스페이먼츠는 출범 초기부터 어떻게 하면 고객사가 결제 시스템을 더 쉽게 연동할 수 있을지에 대한 고민이 많았습니다. 기존의 결제 시스템 연동 방식은 개발자에게 복잡하고 번거로운 작업이라는 인식을 풀어야 했기 때문이죠.이 문제를 해결하기 위해 직관적인 API와 SDK를 새로 만들고, 토스페이먼츠 결제 시스템을 연동하는 개발자들을 위한 개발자 센터를 만드는 등 다양한 활동을 수행하였고, 개발자분들로부터 좋은 피드백을 받았습니다.그렇지만 여전히 결제 시스템 연동의 어려움을 겪는 분들이 많이 계신데요, 개발팀이 따로 없는 작은 가맹점이나 외부에 개발을 맡긴 사업자분들이 특히 어려움을 겪고 있었습니다. AI 기반 코딩 도구를 활용하면 토스페이먼츠 연동을 더 쉽게 할 수 있지 않을까?하는 생각을 바탕으로 토스페이먼츠 연동 코드를 작성해 보았지만, 생성된 코드의 정확도가 많이 떨어지는 문제가 있었어요.이 문제를 해결하기 위한 고민을 하던 중, AI 모델이 이해할 수 있는 맥락 정보를 제공할 수 있는 방법인 MCP(Model-Context Protocol)라는 개념이 등장해서 이를 활용해보기로 했습니다.MCP는 엔트로픽에서 제안한, 인공지능 모델(LLM)이 다양한 상황과 맥락을 잘 이해할 수 있도록 돕는 표준적인 방법입니다. USB가 컴퓨터와 주변기기들을 간편하게 연결할 수 있는 표준을 만들었던 것처럼, MCP는 AI 모델과 다양한 환경이 자연스럽게 연결될 수 있도록 돕습니다. MCP 덕분에 하나의 서버에서 다양한 AI 툴(예: Cursor, Claude, Windsurf 등)을 편하게 사용할 수 있게 되는 것이죠. 저희는 MCP를 활용해, 개발자들이 더 쉽고 즐겁게 작업할 수 있는 '바이브 코딩' 환경을 만들려고 하고 있어요.MCP에서 가장 중요한 건, AI가 잘 이해할 수 있는 콘텐츠를 전달하는 것입니다. 하지만 모든 제품에 대해 콘텐츠를 개별적으로 제작하는 건 시간과 비용이 너무 많이 들죠. 다행히 저희는 이미 MDX 기반의 개발자 센터를 운영하고 있었고, CI/CD 과정에 CDN에 배포되는 구조라서 MCP 서버가 해당 콘텐츠에 접근한다면 문서의 버전업을 그대로 따라가는 구조를 충족할거라 생각했습니다. 이를 기반으로 LLM이 잘 이해할 수 있도록 파일을 만들어 프로토타입을 빠르게 구축할 수 있었어요. 특히 이 과정에서 프론트엔드 챕터의 신지호님께서 큰 도움을 주셨습니다.llms.txt는 대규모 언어 모델

안녕하세요! SK AX AI 엔지니어 조경진입니다.요즘(?) AI Agent 얘기가 정말 뜨거운데요, 막상 현업에서 구현하려고 하면 "어디서부터 시작해야 하지?" 하는 막막함이 있죠.오늘은 생성형 AI를 활용한 Agent 구현의 핵심인 ReAct 패턴에 대해 실무 관점에서 풀어보려고 합니다!현 시점에서 생성형 AI를 다루려면 LangChain 프레임워크를 다루는 것은 필수적인데요, LangChain이 과연 무엇인지 간략하게 한번 살펴보고 가겠습니다.LangChain이란 LLM을 활용한 어플리케이션 개발을 쉽게 해주는 오픈소스 프레임워크입니다.기존에 LLM은 단순한 언어 모델로써 "텍스트 입력 → 텍스트 출력" 수준의 모델로만 활용할 수 있었던 반면,LangChain 프레임워크를 활용하면 여러가지 기능을 추상화하고 외부 API를 활용하여 훨씬 더 복잡하고 실용적인 기능을 수행할 수 있게 됩니다.다음부터 나오는 개념들과 모듈들은 모두 LangChain을 기반으로 합니다. 그러니 LangChain에 대해서 잘 알고 있어야 생성형 AI 서비스를 잘 구축할 수 있겠죠?LangChain을 기반으로 만들어진 기능 중 하나가 바로 AI Agent입니다.GPT나 Claude와 같은 LLM은 기본적으로 "질문 → 답변"의 수동적인 응답 시스템을 보여주는 반면,실제 LLM 서비스에서는 보다 복잡한 목표를 달성하기 위해 능동적으로 행동하고 외부 API를 활용하는 서비스를 구현하고자 합니다.이 한계를 극복하기 위해서 LLM이 스스로 판단하고 행동하는 구조, 즉 AI Agent가 필요해졌습니다.AI Agent(AI 에이전트)는 스스로 목표를 설정하고, 계획을 세우고, 실행까지 수행할 수 있는 자율적인 인공지능 시스템입니다.단순히 질문에 답하는 수준을 넘어서:• None 다양한 도구(검색, 계산, API 호출 등)를 활용하고• None 점진적으로 작업을 완수합니다최근에는 LLM을 중심으로 구성된 에이전트들이 많아서, 자연어로 주어진 목표를 이해하고, reasoning(추론)과 planning(계획)을 통해 문제 해결이 가능합니다.• None RAG 파이프라인을 구성해 문서를 찾아 요약하거나• None 이메일을 분석해 자동으로 회신을 작성하는 것도 가능합니다이러한 AI Agent도 많은 발전을 이루고 있으며, 그중에서 주요한 발전 단계들을 소개드리겠습니다.가장 초기의 AI 에이전트 개념으로, 사람이 미리 정의한 조건-행동 규칙(if-then) 에 따라 작동합니다.• None 특정 문장을 인식하면 정해진 응답을 하는 챗봇 등이 대표적• None 상태 추론 없이 입력에 대한 정해진 반응만 수행• None 지능적인 사고나 적응은 불가능• None 초기 엑스퍼트 시스템(expert system), RPA 봇들이 여기에 해당• None 복잡한 문제에는 대응하기 어려움• None 사전 정의된 환경에서만 안정적으로 동작하지만 지금의 AI 에이전트 설계에도 여전히 룰 기반 요소가 병합되어 활용됩니다. 즉, 인간이 통제할 수 있는 구조로서 중요한 시작점이었습니다.2. Planning Agent (고전 AI 기반 계획 에이전트) 🎯AI가 목표를 달성하기 위해 일련의 행동 계획을 스스로 수립하는 연구로, STRIPS, GOAP 등이 대표적입니다.• None AI가 가능한 행동의 조합을 시뮬레이션하며 "이 상태에서 어떤 행동이 최선인가?"를 판단• None 주로 게임 AI나 로봇 행동 제어 등에서 사용• None 단순 반응형이 아니라, 상태와 목표를 고려하는 구조로 진화• None 자연어 기반이 아니기 때문에 LLM 기반 에이전트와는 거리가 있음그럼에도 불구하고, 현대 에이전트 프레임워크들이 사용하는 Task Planning 기법의 뿌리가 됩니다. (예: AutoGen Planner, LangGraph의 조건 분기 노드 구조 등)GPT-3의 등장 이후, 자연어만으로도 고차원적 사고와 판단이 가능해지며 LLM 기반 에이전트가 등장합니다.• None ReAct 패턴(Reasoning + Acting) 이 2022년에 제안되며, 추론과 도구 사용이 결합• None 에이전트가 자연어로 문제를 분석하고, 필요한 경우 Tool(예: 검색, 계산)을 호출• None LangChain, OpenAI Function calling 기능도 이 시기에 본격 등장하며 빠르게 확산• None 주로 "입력 → 생각 → 도구 사용 → 결과 정리"의 단순 루프 구조• None 복잡한 상태 추적이나 협업은 아직 부족했지만, 현대 LLM Agent의 토대를 마련ReAct, MRKL, AutoGPT 초기 버전이 여기에 해당합니다.2023년에는 LLM에게 목표를 주면 계획 수립, 태스크 분해, 반복 실행까지 가능한 자율 에이전트 구조가 유행합니다.• None 목표 → 작업 생성 → 실행 → 검토 → 반복이라는 loop 기반으로 작동• None 파일 시스템 접근, 브라우저 조작, 외부 API 호출 등이 가능해지며 실제 환경과 상호작용하는 수준까지 발전• None 대부분 불안정한 계획, 루프 오류, 비용 낭비 문제로 실무 적용에는 제한적• None 단일 LLM으로만 구성했기 때문에 복잡한 협업은 어려움하지만 실제 행동하는 AI의 가능성을 대중적으로 알린 계기가 되었습니다.2024년 이후에는 단일 LLM 대신 여러 역할을 가진 에이전트들이 협업하는 멀티 에이전트 구조가 주류가 됩니다.• None 이제는 에이전트가 단순한 도구가 아니라 하나의 작업 주체로서 설계되고 있음• None Langfuse, W&B Traces 등을 활용한 로깅, 평가, 디버깅 툴도 병행되어 프로덕션 적용이 가능해짐🧠 AI Agent에서 LLM이 필요한 이유✅ LLM이 에이전트의 머리인 이유• None 문제 이해: 에이전트가 받은 사용자 지시나 환경 상태를 자연어로 해석하는 데 LLM이 사용됩니다.• None 추론 및 판단: 주어진 정보에 대해 "무엇을 해야 할까?", "다음에 어떤 도구를 써야 할까?"를 결정하는 사고 루틴을 LLM이 수행합니다.• None 행동 계획: ReAct, AutoGPT, LangGraph 등에서는 LLM이 "검색해보자", "계산이 필요하다"는 식으로 다음 행

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다.ADVoost Shopping에서 실시간 유효 광고 선정을 위해 Apache Flink와 Paimon을 활용한 architecture에 대해 소개합니다. Apache Paimon의 주요 기능과 다양한 옵션들에 대해 소개합니다.• 실시간 처리를 위해 고민하고 있는 데이터 엔지니어• Paimon, Iceberg와 같은 lakehouse format을 운영하거나 도입하려는 데이터 엔지니어• Episode 1: ADVoost Shopping에서 실시간 유효 광고 선정을 처리하는 법• 실시간 유효 광고 선정에서 Apache Flink + Paimon을 도입한 이유NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2025(5월)의 일부 세션을 공개합니다.

요즘 Cursor로 대표되는 AI 코드 에디터가 정말 핫한데요. 일단 제 주변 개발자들은 모두들 사용하고 있는 것 같습니다.다양한 툴들이 있지만 대부분 Cursor를 사용하시는 것 같고 저도 그랬는데요, 우연한 기회에 Windsurf라는 툴을 알게 돼서 지금도 주력으로 사용하고 있습니다.제가 파워유저는 아니지만 Windsurf를 조금은 특이하게 사용하고 있어서 사용기를 공유하려고 합니다.Windsurf의 전신은 Codeium이라는 코딩 어시스턴트 툴이었는데요, github copilot를 떠올리시면 이해가 빠를 듯합니다.Codeium은 VSCode, JetBrains, chorme 등 다양한 개발 도구에 익스텐션 형태로 추가해서 사용하는 형태였습니다.이를 Cursor처럼 독립된 IDE로 출시한 것이 바로 Windsurf입니다.하지만 설치 시 Windsurf Editor가 아닌 Windsurf Plugins를 선택하면 여전히 기존 개발도구에 익스텐션 형태로 붙여서 사용할 수도 있습니다.지난 포스트에도 반복해서 썼지만 저는 게임 개발자로서 게임 엔진인 Unity를 꽤 오랜 기간 사용해 왔는데요.여기에 Jetbrains Rider라는 IDE를 붙여서 C# 기반의 코드 작업을 했습니다.지금은 주로 python 코드를 작성하는 ML/DL 엔지니어(라고 떳떳하게 말하기엔 아직 모자라지만..)로서 Jetbrains PyCharm을 주력 IDE로 사용하고 있습니다.Rider와 다른 툴이지만 같은 Jetbrains 계열이라 쉽게 적응하고 갈아탈 수 있었습니다. Cursor, Windsurf는 둘 다 VS Code를 fork해서 개발했다고 합니다.그래서 VS Code를 사용하던 개발자 분들께는 그 환경이 익숙할 텐데요. 주로 Jetbrains 계열 도구를 사용해 온 저에게는 살짝 불편하고 낯선 느낌이 없지 않았습니다.처음에는 저도 Windsurf를 별도 Editor로 사용하다가 PyCharm에 Windsurf를 Plugin으로 붙여서 사용해 보니 결과적으로 익숙함과 편리함이라는 두 마리 토끼를 모두 잡을 수 있었습니다.참고로 Windsurf Plugins는 Jetbrains 계열 도구만 뿐 아니라 VS, VS Code, Vim, Jupyter Notebook, Chorme, Eclipse 등 다양한 IDE 및 플랫폼을 지원합니다.Windsurf Plugin을 설치하는 방법은 너무 간단한데요.PyCharm에서 Settings -> Plugins 메뉴를 열고 검색창에 windsurf를 입력해서 찾고 설치하면 끝입니다.더 자세한 내용은 아래 Windsurf 메뉴얼 페이지를 참고해 주세요.다만 기존 IDE의 보조 도구인 Windsurf Plugins는 Windsurf Editor에 비해서는 기능이 제한적인 것 사실입니다.예를 들어 코드 에디터 창 외에도 하단의 콘솔 창이나 프로그램 실행(Run) 창에서 구문을 드래그해서 바로 Windsurf Chat에 물어보는 기능인 plugin에는 없습니다.이는 Windsurf Editor의 설정 창에서 'Show Selection Popup'를 활성화하면 작동하는 기능입니다.또, Cursor의 Agent 모드와 비슷한 Windsurf의 핵심 기능인 Cascade 모드는 Jebrains 계열 IDE에만 제공됩니다.다행히 저는 PyCharm을 사용하고 있기 때문에 이 부분에 대한 불만은 없습니다^^;이런 부분을 감안하고 기존 IDE를 그대로 사용하면서 가볍게 plugin 형태로 AI agent의 도움을 받고자 한다면 Windsurf Plugins도 나쁘지 않은 선택일 것입니다.

품질을 정의하는 기준이 달라지고 있다.기존 QA는 기능이 “요구사항대로 동작하는지”를 검증하는 데 집중했습니다. 그런데 이제는 사용자들이 기대하는 ‘경험 품질(UX Quality)’이 훨씬 더 중요한 평가 기준이 되고 있습니다.“기능은 되는데 왜 이렇게 쓰기 불편하지?”는 곧“이건 불완전한 제품이야.”로 인식됩니다.즉, 제품의 사용성은 이제 더 이상 기획자나 디자이너, 개발자만의 영역이 아니라, QA도 살펴보고 챙겨야 할 품질의 일부입니다.사용성이 왜 중요한가요?기능의 완성도도 중요하지만, 사용자가 ‘쉽고 자연스럽게’ 기능을 이용할 수 있는가는 그에 못지않게 중요합니다. 실제 사용자들은 복잡한 설명서를 읽거나 기능을 학습할 시간이 부족합니다.처음 접했을 때 직관적으로 사용 가능한가, 최소한의 클릭으로 목표를 달성할 수 있는가가 제품의 경쟁력으로 이어집니다. 그러나 이 ‘직관성’은 기획자, 디자이너, 개발자가 스스로 판단하기 어렵습니다.내부에선 당연해 보이는 것들이, 실제 사용자에겐 장벽이 되곤 하죠. 그래서 필요한 것이 바로 사용성 테스트(Usability Testing) 입니다.QA의 시선으로 본 사용성 테스트우리가 말하는 사용성 테스트(Usability Testing)는 사용자가 시스템과 상호 작용하는 동안,• 오류를 얼마나 쉽게 유발하는지• 작업을 얼마나 효율적으로 수행하는지• 목표 달성까지 몇 단계나 걸리는지같은 것들을 검증하는 과정입니다.QA의 업무로 보면, 이건 단순히 “테스트 케이스 설계 범위를 확장하는 일”입니다. 즉, 기능 요구사항 외에도 사용 시나리오 기반의 ‘경험 흐름’을 검증 항목으로 다뤄야 한다는 것입니다.닐슨의 휴리스틱 평가 10원칙을 QA 테스트 항목으로 해석☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예)입니다.• TestCase#1 파일 업로드 시 진행률이 표시되는가?• TestCase#2 파일 업로드 완료된 후 피드백이 즉시 제공되는가?• TestCase#3 저장, 전송, 로딩 등의 작업 상태를 시각적으로 알리고 있는가?• TestCase#4 완료 후 확인 메시지가 존재하는가?• TestCase#5 진행 중인 작업에 대한 피드백(로딩 인디케이터 등)이 충분한가?• TestCase#7 상태 메시지가 명확하고 눈에 띄는가?• TestCase#8 시스템 오류나 지연 발생 시 실시간 안내가 제공되는가?☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예) 입니다.• TestCase#1 버튼/메뉴 명칭이 사용자에게 익숙한 용어로 되어 있는가?• TestCase#2 실제 업무 용어와 UI 용어 간 괴리가 없는가?• TestCase#3 사용자 기대와 일치하는 흐름으로 동작하는가?• TestCase#4 비즈니스 규칙이 UI와 일관되게 반영되는가?• TestCase#5 아이콘/심볼이 실제 의미와 일치하는가?☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예)입니다.• TestCase#1 되돌리기(undo), 취소(cancel) 기능이 있는가?• TestCase#2 파괴적인 작업(삭제 등)에는 확인 메시지가 있는가?• TestCase#3 잘못된 선택을 쉽게 복구할 수 있는 경로가 있는가?• TestCase#4 팝업 또는 선택 중인 모드를 쉽게 빠져나올 수 있는가?• TestCase#5 시스템 동작 중단(강제 종료 등) 을 사용자가 제어할 수 있는가?☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예)입니다.• TestCase#2 UI 컴포넌트가 동일한 형태와 위치로 반복 사용되는가?• TestCase#3 내비게이션/단축키가 일관적으로 적용되는가?• TestCase#4 동일 기능이 여러 화면에서 동일한 방식으로 작동하는가?• TestCase#5 외부 서비스와의 연결 시 표준 UX 흐름을 따르고 있는가?☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예)입니다.• TestCase#1 날짜나 숫자 입력 시, 잘못된 값을 막을 수 있는가?• TestCase#2 선택 UI에서 잘못된 조합을 선택할 수 없도록 제한하고 있는가?• TestCase#3 입력값 제약 조건이 명확히 안내되고 있는가?• TestCase#4 중요 작업 전 필수 조건 누락 여부를 사전에 안내하는가?• TestCase#5 실시간 유효성 검사가 제공되는가?6. 인식보다는 회상에 의존하지 않기 (Recognition Rather than Recall)☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예) 입니다.• TestCase#1 메뉴/기능이 잘 보이는 위치에 배치되어 있는가?• TestCase#2 최근 사용 기능, 추천 기능 등으로 접근을 돕고 있는가?• TestCase#3 기억이 아닌 시각적인 힌트를 주고 있는가?• TestCase#4 반복되는 설정/입력은 자동 저장되거나 제안되는가?• TestCase#5 항목 선택 시 이전 선택 값이 기억되어 있는가?☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예)입니다.• TestCase#1 고급 사용자용 단축키나 빠른 이동 기능이 제공되는가?• TestCase#2 반복 작업을 줄일 수 있는 기능이 있는가?• TestCase#3 자동완성, 저장된 옵션 불러오기 등의 기능이 존재하는가?• TestCase#4 매크로나 사용자 정의 단축 기능이 존재하는가?• TestCase#5 같은 결과를 여러 경로로 달성할 수 있는 유연성이 있는가?8. 미적이고 최소한의 디자인 (Aesthetic and Minimalist Design)☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예)입니다.• TestCase#1 불필요한 UI 요소나 중복 정보는 없는가?• TestCase#2 핵심 기능이 눈에 잘 띄는가?• TestCase#3 시각적 구조(그리드, 정렬)가 깔끔하게 정리되어 있는가?• TestCase#4 복잡한 메시지는 간결하게 요약되어 있는가?• TestCase#5 컬러, 여백, 폰트 크기 등이 일관적이고 조화로운가?☞ 위 원칙을 QA 테스트 항목으로 해석해 본 TestCase의 (예)입니다.• TestCase#1 에러 메시지

안녕하세요. 무신사에서 프론트엔드 개발을 담당하는 프론트엔드개발팀 엔지니어 김기범입니다.이번 글에서는 MDS(Musinsa Design System) 개발 생산성 및 유지보수를 높이기 위한 과정에서 겪은 고민, 이슈, 그리고 해결 방법을 공유하며, 작게나마 독자 여러분께 도움이 되고자 합니다.우리는 왜 MDS를 구축했나기존에는 각 프로젝트마다 컴포넌트를 개별적으로 개발하다 보니 디자인 일관성이 부족했고 비슷한 컴포넌트를 반복 개발하는 비효율이 발생했습니다. 또한 디자이너와 개발자 간의 소통 비용이 높았습니다. 이런 문제들을 해결하고 개발 생산성을 높이기 위해 통일된 디자인 원칙과 재사용 가능한 컴포넌트 라이브러리가 필요했습니다. 결국 팀 전체의 협업 효율성을 높이고 사용자에게 일관된 경험을 제공하기 위해 디자인 시스템 개발을 진행하게 되었습니다.구축하기 위해 어떤것을 검토했나소프트웨어를 개발할 때, 특정 관점에 집중하게 되는 것은 일반적인 현상입니다. 많은 부분이 있지만 대표적으로 성능, 사용자 경험, 설계, 유지보수, 보안 등 여러가지가 있습니다. 그러나 개발자마다 중점을 두는 부분이 다를 수 있으며, 이러한 요소들은 모두 중요하지만, 프로젝트의 요구사항, 일정, 외부 요인에 따라 우선순위가 달라지기도 합니다.무신사 프론트엔드 개발팀에서는 디자인 일관성을 포함한 유지보수성을 핵심 포인트로 잡고 개발을 진행하였습니다. MDS는 비즈니스 로직을 분리한 Headless UI 라이브러리 아키텍처로 구축했습니다. 다양한 개발 고려사항 중에서 유지보수를 최우선으로 둔 배경과 이유를 간단히 말씀드리겠습니다.https://www.frederikbanke.com/clean-code-a-deep-dive-into-the-basics/Headless UI일반적으로 소프트웨어를 처음 개발하는 시간보다 유지보수하는 시간이 훨씬 더 길어집니다. 요구사항 변경, 버그 수정, 기능 확장은 개발 생애 주기에서 불가피한 과정입니다.따라서 코드의 수정 포인트를 최소화하고, 변경이 필요할 때 예측 가능하며 효율적으로 작업할 수 있는 구조를 설계하는 것이 중요한 포인트가 되었습니다. Headless UI는 비즈니스 로직과 UI를 분리하기 원할해지기 떄문에 이러한 유지보수성을 향상시키는 기반을 제공하기에 Headless UI를 선택하였습니다.재사용성 및 유지보수성두 번째로, 비즈니스 로직과 UI를 분리하는 것 이상으로 중요한 유지보수 요소는 수정 포인트가 단일 지점으로 유지되는지 여부입니다.대부분의 개발자는 코드를 작성하면서 간헐적으로 불편함을 느낍니다. 변수명을 짓기 어렵거나, 더 나은 방식으로 코드를 개선할 수 있을지 고민하거나, 예외 처리를 놓쳤을까 걱정하는 경우가 많죠. 하지만 그중에서도 특히 공감되는 불편함은 중복된 코드에서 비롯됩니다. 주변 동료나 커뮤니티에서도 이 문제를 자주 언급하는 걸 보면, 이는 보편적인 경험인 듯합니다.일반적으로 중복된 코드로 인해서 알 수 없는 불편함이 발생한다면 이를 개선하기 위해 노력한 여러 가지 기법이 있습니다.중복 제거에는 여러 종류가 있습니다. 예를 들어:Gzip 압축 알고리즘: 데이터 크기를 줄이는 물리적 중복 제거.DB 정규화: 데이터베이스에서 중복 데이터를 제거해 일관성을 유지.SSOT(Single Source of Truth): 단일 데이터 소스를 통해 중복 정의를 방지.이러한 중복 제거 기법들은 일반적으로 물리적인 크기 감소나 성능 개선을 가져옵니다. 하지만 현대 사회에 진입하면서 고사양의 저장장치와 CPU, Memory가 보편화되었습니다. 따라서 단순한 최적화를 위해 개발 생산성을 희생하는 접근 방식은 특정 분야를 제외하고는 우선순위가 낮아지고 있습니다.코드 중복이 개발자를 불편하게 만드는 이유그렇다면 우리는 왜 코드 중복에 불편함을 느끼고 이를 개선해야 하는 것일까요?단순히 코드 라인이 길어지기 때문일까요? 물론 코드량 증가도 하나의 문제입니다. 하지만 가장 큰 문제는 유지보수성에 있습니다. 버그가 발생하거나, 기능이 추가되거나, 수정이 필요할 때, 변경해야 할 코드가 한 곳이 아니라 여러 곳에 흩어져 있다면 문제가 심각해집니다. 복잡한 애플리케이션에서는 소스 코드가 방대해지고, 확장성을 고려하지 않은 설계로 인해 간단한 UI 상태 변경조차 사이드 이펙트를 유발하며 수정이 어려워지는 상황을 많은 개발자가 경험했을 것입니다.https://martinfowler.com/articles/headless-component.html따라서 중복 제거를 통해 수정 포인트를 단일화하고, 변경이 필요할 때 한 곳에서만 수정할 수 있도록 설계하는 것이 중요합니다. Headless UI는 UI 컴포넌트의 뼈대만 제공하고, 구체적인 로직이나 스타일을 사용처에 위임함으로써 수정 포인트를 분산시키지 않고 중앙화할 수 있게 합니다.중복 제거가 전부일까?초기 개발 단계에서는 비즈니스 로직과 UI를 분리하고, 중복 로직을 최소화하는 데 집중했습니다.하지만 소프트웨어는 하드웨어와 달리 유연한 대응이 가능하다는 점이 큰 장점이며, 이를 바탕으로 더 나은 서비스를 제공하기 위해 새로운 비즈니스 로직이 지속적으로 추가되거나 기존 로직이 변경될 가능성이 높습니다.결국 추가되는 비즈니스 로직에 의해서 혹은 쉬운 해결 방향을 찾다보면 한곳에 기능이 집중되는 경우가 많이 발생합니다. 결국 조금더 넓은 시야로 바라보며 관리하지 않는다면 단점이 더 부각되는 복잡한 Atom 컴포넌트가 될 가능성이 매우 높아집니다.그렇다면 중복을 없애기 위해 모든 코드를 공통 컴포넌트로 통합하면 문제가 해결될까요? 이론적으로는 좋아 보일 수 있습니다. 버그가 없고, 앞으로 수정이나 추가 기능이 필요 없는 컴포넌트라면 이상적인 코드가 될 수 있죠. 하지만 현실에서는 소프트웨어가 끊임없이 변화합니다. 수정 요구사항이 늘어날수록, 확장성을 고려하지 않은 공통 컴포넌트는 오히려 유지보수의 걸림돌이 됩니다.예를 들어, 공통 컴포넌트를 사용하는 여러 기능에서 디자인 변경, 테스트용 Mock 데이터 추가, 신규 API 연동 같은 작은 수정이 필요할 때를 생각해보세요. 이 컴포넌트가 강하게 결합되어 있다면, 한 곳에서 수정한 내

“사람이 하던 일을 AI가 대체하는 시대가 왔다. 그런데 우리는 단지 따라가기보다, ‘어떻게 운영을 AI 중심으로 재설계할 수 있을까’를 고민하기 시작했다.”안녕하세요, 저는 마이리얼트립 운영법인 AICX의 CTO 허원진입니다.2025년, 우리는 단순한 조직 개편이 아닌 철학의 전환을 선택했습니다.마이리얼트립의 운영법인이던 MRTCX는 AICX로 사명을 변경하며 AI 시대에 걸맞은 새로운 정체성을 선언했습니다.그저 이름만 바뀐 것이 아닙니다. 우리는 ‘사람이 모든 운영을 처리하던 시대’를 넘어서, AI가 운영의 중심이 되는 시대를 준비하고 있습니다.왜 지금, 왜 AI인가여행 산업, 그중에서도 항공은 예외와 변수가 매우 많은 산업입니다. 기상이변, 천재지변, 파업, 분쟁 등으로 인해 예기치 못한 예약 변경/취소 문의가 폭증하고, 그 대응은 수십 명의 상담 인력이 밤낮 없이 처리해야 했습니다. 그러나 이 방식은 점점 더 비효율적이고 지속 불가능해졌습니다.대응 속도는 늦고, 사람의 피로도는 높아지며, 고객 만족도는 떨어졌습니다. 그래서 우리는 자문했습니다.“이걸 계속 사람이 해야 할까?” “우리는 기술로 이 문제를 해결할 수 있을까?”그래서 가장 먼저, 우리의 정체성을 담고 있는 ‘사명’부터 바꾸었습니다.MRTCX → AICXAICX는 단순한 이름 변경이 아니라, 우리가 앞으로 어떤 회사가 될 것인가에 대한 선언입니다.AI를 기반으로 운영의 많은 반복 업무를 자동화하고 고객 경험(CX)을 개선하는 것을 통해 우리는 이제 운영(Operation)을 넘어, AI 기반 운영 인프라를 구축하는 조직으로 거듭나고자합니다.우리가 해결하고 있는 과제들1. 고객 응대 자동화: 챗봇 + AI 콜봇Before: 전화/게시판/채팅 상담으로 모든 문의 응대Now & Future: GPT 기반 챗봇과 AI 콜봇으로 반복 문의 자동 응답마이리얼트립 AI콜봇2. 파트너 운영 자동화: AI 검수와 자동 등록Before: 파트너 등록, 상품 검수, 번역, 수동 발권 모두 사람이 수행Now: AI가 신청서 분석, 상품 카테고리 분류, 번역 품질 개선, 유효성 체크Future: 파트너가 등록만 하면 AI가 검수 → 등록 → 판매 연동까지 자동화파트너 가입승인 검수 예시 화면3. 항공권 운영 자동화Before: 항공사 정책 파악 → 수기 처리Future - 발권 조건을 규칙화하여 자동 발권/변경/재발행 처리- 고객이 요청만 하면 AI가 조건을 판단하고 자동 처리우리가 지향하는 운영의 철학사람이 하던 일을 그대로 AI가 대신하는 게 아닙니다. 사람은 고차원적 의사결정과 케어링에 집중하고, AI는 반복적이고 빠른처리가 필요한 운영을 전담합니다.우리는 운영을 더 이상 ‘지원 조직’이 아닌 ‘비즈니스 성장의 핵심 엔진’으로 정의합니다.AICX가 AI 운영 도입을 위해 얻고자 하는 것예측 가능한 문의 흐름실시간 무중단 대응 시스템고객 여정에 최적화된 AI 기반 운영데이터를 통한 의사결정 자동화우리는 운영의 미래를 만들고 있습니다우리는 여전히 시행착오를 겪고 있습니다. 하지만 명확한 것은

안녕하세요. 데브시스터즈 기술본부에서 조직·기술 문화를 가꾸고 있는 전경아입니다. 이번 글에서는 2025년 5월 29일에 진행했던 <제2회 데브시스터즈 엔지니어링 데이 - Data> 에 대해 소개해드리고, 온라인 다시보기 영상도 공유하고자 합니다.‘데브시스터즈 엔지니어링 데이’란, 데브시스터즈에서 마주하는 기술적인 문제를 공유하고, 어떻게 풀어가는지 외부에 경험을 나누는 행사입니다. 본 행사를 통해 개발자 간에 소통할 수 있는 교류의 장을 만들고, 개발자 생태계에 긍정적인 영향을 주기 위해 노력을 기울이고 있습니다.데브시스터즈의 서비스를 견고히 지탱해나가는 Infra/SRE 분야에서 일하고 계시는 세 명의 발표자를 모시고 발표와 패널톡을 진행했던 제1회 데브시스터즈 엔지니어 링 데이 - Infra/SRE(링크)가 지난 2025년 2월 큰 관심 속에 마무리되었는데요, 다음으로 데이터와 관련된 행사도 있으면 좋겠다는 피드백을 반영하여 제2회 엔지니어링 데이는 '데이터'를 핵심 주제로 정했습니다. 데브시스터즈의 게임은 240여개국, 누적 2억 명 이상의 많은 유저분들에게 큰 사랑을 받고 있으며, 그 결과 매일 10 TB 이상의 데이터가 수집됩니다. 이 데이터를 효과적으로 관리하고 게임 기획부터 라이브 서비스까지 다양한 의사결정에 활용하기 위해, 데브시스터즈의 데이터 분야에서는 어떤 문제들을 고민하고 해결해 나가고 있는지 소개해 드리고자 합니다.발표 1 - 스키마, 버전 그리고 로그: 안정적인 로그 파이프라인 구축기JSON 형식의 로그는 높은 자유도 및 편의성 을 제공하지만, 한편으로 다양한 문제도 있습니다. JSON 로그의 문제를 해결하기 위해 도입된 ‘스키마 기반 로그 파이프라인’의 전반적인 설계와, 여러 버전의 스키마를 동시에 지원하기 위한 방법을 공유하고 JSON 로그의 자유도와 복잡함 속에서 어떻게 일관된 구조를 지키고 안정적인 분석 환경을 만들 수 있는지 소개해주셨습니다.데브시스터즈는 게임 런칭과 같은 핵심 순간에 필요한 지표를 신속하게 제공하기 위한 준실시간 데이터 파이프라인을 구축했습니다. 본 세션에서는 기존 시스템의 정확도와 안정성 문제를 해결하기 위해 어떤 고민을 하고 설계했는지 그 과정을 공유하고, 기술적인 이야기뿐만 아니라, 팀과 고객의 요구사항을 반영하여 실용적인 데이터 서비스를 만들어나가는 데브시스터즈의 일하는 가치관도 함께 소개해주셨습니다.조금 더 기술적인 내용은 발표에서 QR 코드로 소개해주셨던 기술블로그 포스팅 ‘지금 매출 얼마인가요’를 참고해주세요.발표 3 - DW는 계획대로 되지 않아! - 게임 데이터 공통화, 이상과 현실 사이에서의 여정데브시스터즈에서 서비스하는 게임이 늘어남에 따라, 모든 게임 데이터를 하나의 통합된 DW로 관리하는 '게임 DW 공통화'를 추진했습니다. 하지만 이상적으로 보였던 계획은 예측하기 어려운 데이터 앞에서 여러 난관에 부딪혔습니다. 이 과정에서 겪은 현실적 문제들과 이를 해결하는 과정, 그리고 앞으로의 과제와 새로운 도전 방향을 소개해주셨습니다.쿠키런: 킹덤 팀은 더 좋은 게임, 더

최근 LLM의 성능이 좋아지면서 한국어 <-> 영어 번역을 많이 활용하고 있습니다.외국업체에 이메일을 보낼 때나 논문, 기사 중 어려운 문장이 있는 경우, 빠르게 논문이나 기술 자료를 읽어야 할때 자주 사용하는데요.몇년 전만해도 구글 번역기나 네이버 파파고를 사용했었는데, 요즘은 ChatGPT, Claude, Gemini에 바로 물어보고 빠르게 답을 얻곤 합니다.최근 업무에서 정식적으로 한영/영한 번역 기능이 필요하여 객관적인 LLM 모델간 성능 비교가 필요했는데,그동안 제가 개인적으로 했던 번역 성능은 주관적이다 보니 평가지표가 없는지 찾아봤습니다.LLM 이 평가자가 되어 번역 성능을 평가하는 흥미로운 논문이 있어 리뷰해보려고 합니다.이 연구는 거대 언어 모델(LLM)을 활용한 영어에서 한국어로의 문학 기계번역을 자동화된 방식으로 평가하는 프레임워크를 제안하고, 그 가능성과 한계를 심도 깊게 분석하고 있습니다.최근 GPT, Claude, Gemini와 같은 LLM 모델들은 나올 때마다 기존의 모델들의 성능을 뛰어넘으며, 전반적인 성능이 빠르게 발전하고 있습니다.기본적으로 언어간 번역 성능도 뛰어난 편이지만 문학 번역은 단순히 텍스트의 의미를 전달하는 것을 넘어, 미묘한 언어의 미학적, 정서적 사용, 문학적 표현에도 중점을 두어야 합니다.또한 문화적 맥락이 매우 중요하며, 원문의 뉘앙스, 작가의 의도, 등장인물 간의 관계 등을 섬세하게 포착해야 하기에 일반 기사나 기술자료의 번역보다 난이도가 높은 편입니다.문제는 이러한 문학 번역의 복잡성 때문에 기존의 성능 평가 지표들, 예를 들어 BLEU나 BLEURT 같은 것들이 문학 번역의 미묘한 뉘앙스를 제대로 평가하지 못한다는 점입니다.그렇다고 매번 비용이 많이 드는 숙련된 언어 전문가의 평가에만 의존할 수도 없으니,LLM 에이전트나 파이프라인 개발자들에게 번역이 필요한 기준을 충족하는지 알려줄 수 있는 자동화된, 세분화된 평가 방법이 절실한 상황입니다.이 논문은 바로 이러한 필요성에서 출발합니다.이 연구는 문학 번역 평가의 복잡성을 해결하기 위해 두 단계로 구성된 프레임워크를 제안합니다.프레임워크의 첫 번째 단계는 DA-MQM(Direct Assessment-Multidimensional Quality Metric) 이라고 불립니다.연구진들은 먼저 기계 번역 시스템이 영어를 한국어로 번역할 때 자주 범하는 네 가지 주요 오류 유형을 식별했습니다.• None 단어/구/표현 문제: LLM은 지나치게 직역하여 비유적인 표현 등에서 어색하거나 부자연스러운 한국어 단어를 선택할 수 있습니다.• None 문맥 관련 문제: 문화적, 역사적 뉘앙스가 종종 사라집니다. 예를 들어, 'abolitionist(노예제 폐지론자)'와 같은 용어는 한국어에 직접적인 역사적 대응어가 없어 혼란스러운 번역으로 이어질 수 있습니다.• None 형식 관련 문제: 구두점, 문장 구조, 일관성 없는 이름 표기 등의 문제는 글의 흐름을 방해할 수 있습니다.• None 경어법(Honorifics): 이는 한국어에서 매우 중요한 요소입니다. 관계와 사회적 지위를 반영하는 복잡한 경어법 체계가 MT 시스템에 의해 잘못 해석되어 부자연스럽거나 틀린 대화로 이어지는 경우가 많습니다.이를 위해 전문가들이 직접 설계한 세분화된 평가 rubric (Extensive human curated rubric)을 사용하며,이 루브릭은 영어-한국어 번역에서 흔히 발생하는 기계번역 오류 유형을 감지하도록 특별히 고안되었습니다.평가 기준은 다음 네 가지 주요 범주에 초점을 맞춥니다:• None 어휘 선택 (Lexical Choice): 숙어 표현 및 전반적인 단어 선택이 목표 언어의 유창성을 얼마나 잘 보여주는지 평가합니다.• None 대화에서의 적절한 존대법 사용 (Proper Use of Honorifics in Dialogues): 한국어만의 고유한 특성으로 문학 텍스트에서도 특히 중요한 요소입니다. 존댓말과 반말이 명확하게 구분되어 있는 한국어에서 대화 참여자들의 사회적 지위와 관계를 정확히 반영하는 동사 어미 선택이 자연스러운 한국어 대화를 만들어내는지 평가합니다. 존대법 오류는 독자의 독서 경험에 부정적인 영향을 줄 수 있습니다.• None 구문 및 문법 (Syntax and Grammar): 문장의 문법적 정확성, 삽입절, 접속사, 문장 연결의 적절성, 문장의 내부 논리 및 구두점 등을 평가하여 한국어로 번역문이 얼마나 자연스럽게 읽히는지 확인합니다.• None 내용 정확도 (Content Accuracy): 원문의 의미를 얼마나 잘 보존하고 있는지, 특히 문학적 표현이 제대로 번역되었는지 평가합니다. 명확성을 위해 일부 추가나 생략이 있을 수 있지만, 원문의 내용과 맥락에 필수적인 중요한 단어나 구절이 변경되거나 생략되어서는 안 됩니다.DA-MQM 단계에서는 LLM이 1점부터 5점까지의 척도로 점수를 부여합니다.기술적으로 완벽한 번역이 반드시 훌륭한 '문학적' 번역은 아닙니다.VERSE(VERification-based Story-specific Evaluation) 라고 명명된 두 번째 단계는 원작의 고유한 문학적 특성이 잘 보존되었는지를 평가하여 이 문제를 해결합니다.작동 방식은 다음과 같습니다.• None 질문 생성: 뛰어난 성능의 LLM(이 연구에서는 GPT-4)에게 원문과 이야기 요약을 컨텍스트로 제공하고, 특정 단락의 문학적 측면에 대한 검증 질문 목록을 생성하도록 지시합니다. 이 질문들은 텍스트의 문학적 구조를 더 깊이 파고들도록 설계되었습니다.• None 평가: 다른 LLM이 심사관 역할을 하여, 생성된 질문들을 바탕으로 기계 번역 결과물을 1점에서 3점 척도(1점=불만족, 2점=부분 만족, 3점=완전 만족)로 평가합니다.먼저 고성능 LLM 모델 (이 연구에서는 GPT-4o)이 성공적인 문학 번역에 필요한 검증 질문 목록을 생성합니다.해당 질문들은 역사적 및 문화적 맥락, 이미지 및 묘사 품질, 인물화, 대인 관계 역학, 관용적 자연스러움, 미묘한 함의, 서사적 속도 및 리듬, 문체적 공명, 전반적인 일관성 및 응집력 등 다양한 문학적 측면을 고려합니다.그다

SK Hynix의 김병도 입니다.이번 포스팅은 제가 사내에서 LLMops를 운영&개발하면서 느꼈던 필수 요건, 팁 등을 공유드리겠습니다.Chat PPT는 대중적으로 나와있는 PPT 분석기와 매우 유사합니다.VLM(Vision Model)이 슬라이드 마다 API를 호출하여 분석 후 결과를 출력하며, 이 결과들을 User Prompt에 넣고 LLM을 통해 결과를 호출하는 프로그램입니다.크게 1. 목표 설정 / 2. 개발 과정 / 3. 품질 향상 과정 으로 구성 하였습니다.• None 회사에서 제공하는 API를 활용 ( Qwen2-VL-72B / Llama3.3_70B ) * 유동적 변경• None API가 Local LLM이기에 보안 제약이 없음.• None 많은 구성원이 '필요'로 하는 기능과, 쉽게 접근 할 수 있도록 구현 -- pyinstaller기능을 통한 .exe로 구성(Web은 보안상 불가)• None 서비스에 Input 될 규격이 항상 일정하고, 사내 가장 많은 자료를 갖고 있는 PPT를 공략• None 매우 전문적이고, 숫자하나, 단어하나 놓치지 않고 출력 할 수 있도록 구성• None 단순히 단어 뿐아니라 그림, 모식도,도표 등을 이해하고 출력 할 수 있도록 Fine Tunning• None 속도 vs 정확성에서 전문적인 지식을 도출하는 만큼 정확성을 선택.• None DRM으로 인해, 일방적으로 PPT를 읽는 것은 불가능. -- PPT를 한 장씩 클립보드에 담아 VLM으로 보내는 방식 채택• None DPI 고정을 통해 캡쳐된 PPT의 화질이 손상되는 것을 예방• None LLM Api 부하가 걸리지 않게 break time 설정 및 한장 씩 호출 - 결과 추출을 반복• None -- Progress : 각 SIlde 마다 데이터 추출 진척사항, 에러 등을 보여주며, 종료 후 csv 형태로 저장• None ASK 답변에는 200 page 이상 추출된 Data가 한 번에 Input 가능한 LLM 사용• None 가 Open 이후 주변 동료에게 Feedback 요청• None 한문, 형상문자 출력 / 디테일한 정보 부족 / 숫자 추출 부정확 / 도표 이해 / 그림 이해 등 많은 문제를 해결필요 -- VLM의 메타인지를 위해 System Preprompt에 들어갈 내용을 ChatGPT를 통해 생성. -- 질문 예시) "나는 Skhynix 반도체 회사에 다니는 LLMops 개발자야. 회사내 전문적인 지식을 기반으로 만들어진 PPT를 Vision Model 에게 질의하여 최대한 자세한 답변을 받고 싶어. 0000등을 정확히 추출할 수 있도록 Pre-prompt 를 영어로 작성해줘."• None VLM 성능 향상을 위해 답변은 최대한 영어로 하되 의미를 최대한 살리게함(최종 답변은 한글로)• None 실제 자료 추출 결과와 비교해가며 다시 1번부터 품질향상 과정 진행 반복다음 이야기 : Progress에 저장된 데이터를 기반으로 Graph-RAG 구성제가 실제로 사내에 Chat PPT라는 프로그램을 구현했던 개발과정을 담았으며,사용 친화적이고 Error 나 할루시네이션 등이 최소화되는게 중요하다고 생각합니다. 사용 중 부정확한 성능이나, 불만이 생기면 사용자는 빠르게 이탈하기 때문입니다.오직 글로만 존재하여 지루하셨겠지만, 개발 과정에서 도움을 드릴게 있을까하여 내용을 담았습니다.필요하신 내용은 답글연락주시면 답변드리겠습니다. ( + 하트 한 번 부탁드립니다.)