안녕하세요! 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 기반 운영데이터를 통한 의사결정 자동화우리는 운영의 미래를 만들고 있습니다우리는 여전히 시행착오를 겪고 있습니다. 하지만 명확한 것은