안녕하세요, 카카오 기술 블로그 독자 여러분!두 번째 글로 다시 만나게 되어 정말 반가워요. 첫 번째 글인 AI야, 문서 좀 대신 써 줘 - 1. 일단 시작!에서 제가 Technical Writing(TW) 에이전트를 만들기 시작했다는 소식을 전해드렸죠.TW 에이전트의 핵심 요소, AI 모델TW 에이전트는 사용자가 제공한 자료를 읽고, 기술 문서를 대신 작성하거나 다듬어주는 AI 도구입니다. 사용자가 대상 독자나 문서 목적 같은 요구사항을 알려주고 필요한 자료를 전달하면, AI가 아래 과정을 척척 해결해 주는 게 목표죠.• 템플릿과 스타일 가이드 지키기사실, 이 과정은 테크니컬 라이터가 기술 문서를 작성할 때 따르는 흐름과 거의 같아요. 기술 문서는 작성 과정과 내용이 체계적이고 정형화된 경우가 많아서, AI에게 맡기기가 훨씬 수월하답니다.TW 에이전트가 일하는 과정을 예상해 보면 아래와 같아요.• 사용자가 TW 에이전트에게 문서 작성 요청• TW 에이전트가 AI 모델에게 기술 문서 작성 요청• AI 모델이 기술 문서 작성 후 TW 에이전트에게 전달즉, 사용자가 TW 에이전트에게 기술 문서 작성을 요청하면, 실제로 기술 문서를 작성하는 건 AI 모델이에요.그러니 어떤 AI 모델을 사용해야 할지부터 결정해야겠죠!그럼, 이 일을 잘 해낼 수 있는 AI 모델은 어떤 걸 골라야 할까요? TW 에이전트가 필요로 하는 아래 능력들을 기준으로 AI 모델을 선택해야 했어요.• 다양한 기술 정보를 분석하고 분류하는 능력• 복잡한 기술 정보를 이해하고 명확하게 설명하는 능력• 필요한 정보를 스스로 찾아서 사용하는 능력이 기준을 바탕으로, 추론에 강한 최신 AI 모델들을 후보로 골랐어요. AI 기술이 워낙 빠르게 발전하다 보니 아무리 최신 모델을 쓰더라도 금방 구식이 되더라고요.TW 에이전트 후보로 선택한 모델은 아래 세 가지입니다.이제, 후보 AI 모델들의 기술 문서 이해 능력을 시험해 볼 차례입니다! TW 에이전트는 복잡한 기술 문서를 제대로 읽고, 핵심을 잘 정리할 수 있어야 하니까요.그래서 ‘카카오 로그인’ 서비스의 기술 문서를 파일로 주고, 관련 질문에 답하는 일종의 '쪽지 시험’을 치르게 했어요. 성능을 평가하는 방법은 많지만, 기술 문서 이해력을 알아보는 데는 이런 방식이 딱이라고 생각했거든요.총 20문항의 문제지는 GPT-4o가 만들고 제가 검토했어요. AI 모델이 문제 내용에만 집중할 수 있도록 문제지는 XML 형식으로 준비했고, 각 AI 모델에게 문제를 풀어달라고 요청했어요.제가 사용한 제시어(Prompt)와 문제 예시는 이렇게 생겼어요.AI 모델들은 순식간에 답안지를 작성해 냈어요. 카카오 로그인은 OAuth 2.0에 대한 이해가 필요하고 다양한 기능이 있는 서비스인데도, 허무할 정도로 빠르게 시험이 끝났습니다.답안 채점도 AI에게 맡겼어요. AI가 자기 성능을 평가할 때 생길 수 있는 자기 편향(Self bias) 문제를 피하기 위해 GPT-4.5, Gemini 2.0, Claude 3.5 Haiku 세 가지를 채점자로 썼고, 채점 과

차량 내에서도 에이닷 서비스를 더욱 편리하게 경험할 수 있는 시대가 다가오고 있습니다.이를 실현하기 위해 다양한 OEM 차량에서 에이닷 서비스를 제공하는 것이 무엇보다 중요했습니다.그러나 많은 OEM 차량에서는 저희가 개발한 SDK를 직접 탑재할 수 없는 한계가 있었습니다.이 문제를 해결하기 위해, SDK가 없는 차량에도 에이닷 서비스를 제공할 수 있는 방법을 고민한 끝에 서버 대 서버(Server-to-Server) 방식의 연동을 도입하게 되었습니다.이에 따라 OEM 서버와 에이닷 플랫폼 간의 원활한 차량 서비스 연동을 지원하는 Auto Proxy 서버를 개발하게 되었고 그 과정을 공유드립니다.• None 대형 메인프레임 컴퓨터가 주를 이뤘습니다. 이 거대한 기계들은 모든 기능을 단일 시스템 내에서 처리했고, 외부와의 통신 필요성이 거의 없었습니다. 데이터 교환은 주로 테이프나 카드와 같은 물리적 매체를 통해 이루어졌기 때문에, 현재와 같은 복잡한 네트워크 통신의 필요성이 크지 않았습니다.• None 기술 발전으로 PC, 워크스테이션, 소형 서버 등이 등장하면서, 컴퓨팅 환경이 크게 변화했습니다. 고가의 메인프레임의 기능을 여러 소형 서버로 분산시키고 네트워크로 연결하는 방식이 도입되었습니다. 이는 서버와 클라이언트 간의 통신을 기반으로 하는 새로운 모델을 탄생시켰고, 네트워크 기술의 중요성이 부각되었습니다.• None 프로세스 간 정보 교환이 활성화되면서 IPC(Inter Process Communication) 기술이 발전했습니다. 다양한 IPC 방식 중에서 소켓(Socket)은 네트워크를 통해 프로세스 간 통신을 가능하게 하는 중요한 수단이 되었습니다. 이를 통해 컴퓨터 간의 더욱 효율적인 통신이 가능해졌습니다.• None 소켓은 유용했지만 서비스가 확장하면서 더욱 다양한 데이터 종류를 송수신하게 되며 이를 매핑하는 과정이 복잡해졌습니다. 이러한 한계를 극복하기 위해 RPC 기술이 등장했습니다. RPC는 네트워크로 연결된 서버의 함수를 마치 로컬 함수처럼 호출할 수 있게 해주어 데이터 교환 방식을 단순화했습니다.gRPC와 REST: 현대 API 설계의 두 가지 접근법API 설계에 있어 REST와 gRPC는 각각 고유한 장점을 가진 두 가지 주요 접근 방식입니다. 이들의 특징을 비교해보면 다음과 같습니다.REST(Representational State Transfer)는 널리 사용되는 API 설계 방식으로, 몇 가지 주목할 만한 장점이 있습니다.• None REST는 단순성과 사용 용이성이 뛰어납니다. HTTP 메서드와 URL을 이용한 직관적인 설계로 개발자들이 빠르게 이해하고 구현할 수 있습니다.• None REST는 가독성과 디버깅이 용이합니다. JSON이나 XML 같은 사람이 읽을 수 있는 형식을 사용하기 때문입니다.• None REST의 stateless 특성과 HTTP 프로토콜 사용으로 캐싱 메커니즘을 쉽게 구현할 수 있어, 성능 향상과 서버 부하 감소에 도움이 됩니다.이러한 특징으로 REST는 개발자와 외부 사용자 모두

UV는 정말 빠를까? 그리고 얼마나 실용적일까?기존 프로젝트에서는 poetry를 패키지 매니저로 도입해 사용하고 있었지만, uv가 “빠르다”는 이야기를 듣고 테스트해보지 않을 이유가 없었습니다.실제로 성능 차이를 체감할 수 있을지 궁금했기 때문입니다.FastAPI는 정말 Flask보다 빠를까?잠깐 주제를 벗어나지만, 속도에 대한 이야기를 하다 보면 예전에 경험했던 FastAPI 도입 사례를 빼놓을 수 없습니다.과거 저희 팀은 백엔드에 큰 트래픽이 없는 구조였기 때문에 초기에는 Flask로 REST API 서버를 구성했습니다.그러다 FastAPI가 “속도가 빠르다”는 장점으로 각광받기 시작하면서 관심을 가지게 되었고, 실제로 FastAPI로의 전환을 시도해보았습니다.물론, 단순히 “빠르다”는 이유만으로 프레임워크를 바꾸는 건 위험하다고 판단해 간단한 벤치마크 테스트를 진행했는데요.테스트 결과, FastAPI가 약간 더 빠른 듯 보이긴 했지만, 기대만큼의 큰 차이는 아니었습니다.특히 실제 운영 환경에서 기존 Flask API를 FastAPI로 마이그레이션해보면서 그 차이는 더욱 미미하게 느껴졌습니다.대부분의 API가 DB에 접근하는 구조였기 때문에 IO가 병목이 되는 상황에서는 FastAPI든 Flask든 성능 차이가 거의 없었습니다.이러한 의문은 저만의 생각은 아니었고, 커뮤니티에서도 비슷한 피드백들이 많았습니다.FastAPI가 처음에는 “가장 빠른 프레임워크”로 소개되었지만, 현재는 슬쩍 “빠른 프레임워크 중 하나”라는 표현으로 바뀐 것도 인상 깊은 변화였습니다.그럼에도 불구하고 FastAPI는 pydantic과의 연계로 명확한 파라미터 검증을 제공하고, 문서화가 자동으로 이루어지는 등 속도 외에도 많은 장점을 가진 프레임워크라는 점은 분명합니다.이런 경험이 있었기 때문에, uv에 대해서도 단순히 “빠르다”는 인상만으로는 판단하지 않고 실제로 테스트를 해보기로 했습니다.UV는 실제로 얼마나 빠를까?간단한 실험으로 numpy, beautifulsoup4 두 개의 패키지를 설치하는 데 걸리는 시간을 비교해 보았습니다.격리된 환경에서의 공정한 비교를 위해 Docker를 활용하였으며, 사전 준비로 패키지 매니저(pip, poetry, pdm, uv)는 미리 설치해둔 상태에서 진행했습니다.참고: pyenv만 사용할 경우 캐싱 이슈가 발생할 수 있어 Docker 컨테이너 내에서 테스트를 수행했습니다.위 결과에서 알 수 있듯, uv가 다른 툴들보다 다소 빠르긴 했지만 “극적인 차이”까지는 아니었습니다.이는 패키지 자체의 빌드 지연 등 외부 요인에 영향을 받은 결과로 보입니다.만약 수십 개의 패키지를 설치하거나 복잡한 의존성 그래프가 있는 경우에는 uv의 장점이 더 뚜렷하게 드러날 수 있을 것으로 예상됩니다.다만 유의할 점은, uv 측의 주장처럼 10~100배 빠르다는 수치는 특정 조건에서의 최대 성능 기준이지, 항상 그런 건 아니라는 점입니다.결국 도구의 도입 여부는 실제 사용 환경에서의 유의미한 개선이 있는지를 중심으로 판단해야 합니다.기존에 po

제조 현장의 불량 검수를 AI로 하고 있다면, 성능이 나아지지 않는 AI에 불만족하다면, 이 튜토리얼이 도움이 되실 것입니다. 카메라를 활용한 데이터 수집부터 슈퍼브에이아이 플랫폼으로 데이터 선별, 라벨링, 모델 학습 및 실시간 배포까지 전체 과정을 단계별로 알아봅니다. 생산 라인에서 자동화된 품질 관리 시스템을 구축하는 실용적인 워크플로우를 제공합니다.필자: 슈퍼브에이아이 솔루션 엔지니어 ​Sam Mardirosian고성능 컴퓨터 비전 모델을 개발하려면 효과적인 모델 학습 파이프라인을 구축하는 것이 필수적입니다. 파이프라인을 잘 구축하면 데이터를 효율적으로 수집하고, 똑똑하게 선별하고, 정확하게 라벨링하고, 효과적으로 모델을 학습시켜 현실 시나리오에도 우수한 일반화 성능을 보이도록 만들 수 있습니다. 또한 파이프라인의 각 단계를 최적화하면 강건한 AI 시스템을 개발하는데 필요한 시간, 비용, 노력을 절감할 수 있습니다.이번 튜토리얼에서는 데이터 수집, 선별부터 모델 학습 및 배포에 이르는 전체적인 모델 개발 및 배포 파이프라인을 단계별로 살펴보겠습니다. 또, 어떻게 슈퍼브에이아이의 올인원 AI 플랫폼을 통해 이 과정을 자동화하고 효율화하여 성능과 효율성이라는 두 마리 토끼를 잡을 수 있는지 보여드리고자 합니다.산업 현장에 적용할 일반적인 실시간 결함 탐지 모델을 개발해 보겠습니다. 이번에는 Lucid Vision Labs의 표준 카메라를 사용할 예정이지만, 이 워크플로우는 보안 카메라(예: RTSP CCTV)나 웹캠과 같은 다른 카메라 종류에도 적용할 수 있습니다. Lucid Vision Labs 카메라로 이미지 데이터를 취득하고, 슈퍼브 큐레이트와 슈퍼브 라벨을 이용해 데이터를 선별 및 라벨링하고, 슈퍼브 모델로 AI 모델을 학습시킨 뒤 최종적으로 배포하여 실시간 결함 모니터링을 진행할 예정입니다. 이 방법은 보안, 안전, 장비 모니터링 및 규제 컴플라이언스와 같은 다른 객체 탐지 사례에도 충분히 적용할 수 있습니다.이 튜토리얼이 마무리될 때 쯤에는 다양한 유즈 케이스에 적용해 볼 수 있는 실용적인 파이프라인을 구축하실 수 있을 것입니다. 이를 통해 적절하게 선별된 고품질의 데이터로 여러분의 컴퓨터 비전 모델을 학습시키고 실제 환경에 배포할 준비를 마쳐보세요.컴퓨터 비전 모델 학습의 시작이자 끝은 바로 데이터 수집이라고 할 수 있습니다. 첫 단계이지만, 가장 중요한 단계이기도 합니다. 정확하고 신뢰할 수 있는 모델 성능을 유지하기 위해서는 품질과 다양성이 모두 확보된 데이터셋을 준비하는 것이 가장 중요하기 때문입니다. 필요한 데이터의 양은 모델이 수행하려는 작업이 얼마나 복잡한지에 따라 달라집니다. 간단한 작업을 처리하는 것이라면 상대적으로 적은 이미지로도 충분하지만, 보다 어렵고 예외적인 데이터, 즉 엣지 케이스가 많이 발생하는 시나리오를 처리하려면 더 많고 더 다양한 데이터가 필요합니다.이번 튜토리얼에서는 여러분이 학습용 데이터 수집 및 모델 배포에 Lucid Vision Labs 카메라를 활용하며 Lucid Arena SDK를

MCP(Model Context Protocol)는 2024년 11월 처음 공개된 이후 한동안 제한된 커뮤니티 내에서만 활용되어 왔으나, 최근 OpenAI의 Agents SDK가 이를 공식 지원하면서 주목도가 빠르게 높아지고 있습니다. 본 글에서는 MCP가 무엇인지, 그리고 어떤 방식으로 동작하는지를 자세히 살펴보겠습니다.MCP는 LLM Agent 구축을 위한 규격 중 하나인데요. MCP를 이해하기 위해 먼저 LLM과 LLM Agent의 개념을 살펴보겠습니다. LLM과 LLM Agent 간의 차이는 다음과 같습니다.다음과 같이, 같은 “날씨 알려줘”의 사용자 쿼리에 대해 LLM과 LLM Agent의 응답은 차이가 있습니다.이처럼, 단순히 텍스트를 생성하는 LLM과 실제 툴을 사용해 사용자 요청을 해결하는 LLM Agent는 근본적인 차이가 있습니다. 최근에는 단순 응답을 넘어, 외부 도구를 능동적으로 활용하는 LLM Agent 개발이 주목받고 있습니다.하지만 Agent를 만드는 과정은 아직까지 표준화되지 않아 여러 문제들이 발생하고 있으며, 이에 대한 논의는 다음과 같습니다.2-2) LLM Agent 개발의 파편화와 표준화의 필요성MCP가 등장하기 전까지, LLM Agent를 구축하는 방식은 프레임워크마다 제각각이었습니다.각기 다른 방식으로 툴을 연결하고, 자체적인 구성 요소를 따로 구현하면서 다음과 같은 문제가 발생했습니다.• 다양한 Agent 프레임워크가 난립하며 툴 연동 방식이 서로 달랐고,• 툴과 컴포넌트의 재사용과 확장이 어려워졌으며,• 커뮤니티 생태계도 분절되어 협업이 힘든 구조가 되었습니다.• 동일한 기능의 툴조차 프레임워크마다 다시 구현해야 했고,• 시스템 간 연동이 어려워 툴 생태계 전체가 고립되기 시작했습니다.이처럼 Agent 개발의 파편화가 심화되자, 모든 Agent들이 공통으로 사용할 수 있는 ‘표준 프로토콜’의 필요성이 커졌고,바로 그 해결책으로 MCP(Model Context Protocol)가 등장하게 된 것입니다.• MCP는 애플리케이션이 LLM에 컨텍스트를 제공하는 방법을 표준화하는 개방형 프로토콜• Claude LLM을 제공하는 Anthropic 미국 스타트업에서 제안• MCP는 AI 애플리케이션을 위한 USB-C 포트와 같음. USB-C가 다양한 주변기기와 액세서리에 기기를 연결하는 표준화된 방법을 제공하는 것처럼, MCP는 AI 모델을 다양한 데이터 소스와 도구에 연결하는 표준화된 방법을 제공MCP는 Host, Client, Server로 크게 3가지로 이루어져 있습니다.Host는 LLM 애플리케이션 자체로, MCP 통신의 중심이며 여러 개의 Client를 포함하고 이들을 관리합니다.• 내부에 MCP Client들을 여러 개 포함• 각 Client와 연결된 Server들의 실행 결과와 context를 통합해 LLM에 전달• MCP Client들의 초기화 및 라이프사이클 관리• 여러 Client로부터 받은 정보를 Context로 통합• 사용자와 LLM 사이의 브릿지Claude Desktop App과 Cursor AI는 사용자가 직접 마주하는 Host 인터페이스로서, Agent와 상호작용하는 프런트엔드 역할을 수행합니다. 이러한 앱들은 사용자에게 친숙한 환경을 제공하며, 에이전트에 쉽게 접근하고 활용할 수 있는 통로가 되어줍니다. 덕분에 사용자는 복잡한 설정 없이 자연어로 명령하고 다양한 Tool을 손쉽게 사용할 수 있습니다.Client는 MCP Server 들과 연결되어 있으며, 양방향 메시지 교환, 기능 목록 관리, 초기 협상 등을 수행합니다.• 하나의 MCP Client는 하나의 MCP Server와 연결• 내부적으로 메시지를 주고받고, 서버 상태나 기능 목록을 파악함• 각각의 클라이언트는 특정 목적(예: Linear 연동, Slack 연동)을 위해 존재• 요청/응답/알림 등의 메시지 라우팅 처리OpenAI Agents SDK, mcp-agents, Langchain 등은 Client 단에서 에이전트를 손쉽게 생성하고 실행할 수 있도록 지원하는 도구들입니다. 이들 프레임워크는 LLM과 Tool, Memory, Planner 등을 연결하는 복잡한 과정을 추상화하여, 개발자가 보다 직관적으로 Agent를 설계하고 운영할 수 있도록 도와줍니다.Server는 LLM이 외부 세계와 상호작용할 수 있도록 도와주는 기능적 확장제로, MCP의 하위 컴포넌트인 Tool, Resource, Prompt Template을 제공합니다.• Tool (도구) :외부 API 또는 기능을 실행하는 명령 단위. LLM이 호출 가능예: 파일 목록 가져오기, 이메일 전송, 데이터베이스 조회 등• Resource (리소스) :텍스트, 로그, DB 스키마 등 LLM이 참고할 수 있는 외부 컨텍스트• Prompt Template (프롬프트 템플릿) :LLM이 따라야 할 지시문 혹은 형식• LLM이 직접 호출할 수 있는 도구(Tool) 제공• Host/Client가 요청하는 리소스 정보 제공• 초기화 과정에서 프로토콜 협상 수행• Client로부터 받은 요청을 처리하고 응답 반환Smithery는 MCP 기반 서버 레지스트리로, 이미 4,000개 이상의 MCP Server가 등록되어 있습니다. 사용자는 이들 서버를 자유롭게 선택하여 자신의 에이전트에 연동할 수 있으며, 마치 API 마켓 플레이스처럼 필요한 기능을 손쉽게 가져다 쓸 수 있는 환경이 제공됩니다.MCP 기반 LLM Agent는 입력된 요청의 성격에 따라 두 가지 방식으로 동작합니다.일반적인 대화나 단순 질의의 경우에는 LLM만으로 응답이 생성되며, 복잡한 작업이나 외부 정보가 필요한 경우에는 Tool을 호출해 작업을 수행합니다.각 방식의 흐름을 예시와 함께 살펴보겠습니다.• Tool 없이 LLM만 응답하는 경우이제 각 경우의 실제 흐름을 구체적으로 살펴보겠습니다.5-1) Tool 없이 LLM만 응답하는 경우• 간단한 인사, 요약, 번역, Q&A 등은 LLM이 자체적으로 응답을 생성• 별도의 외부 연동 없이 빠르게 결과 제공사용자가 “안녕, 난 한컴이야.” 와 같은 단순한 자연어 메시지를 입력하면, MCP 시스템에

이제 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 을 하나의 배치

시작하며안녕하세요. 현대자동차 인포테인먼트CCS개발팀에서 프론트엔드 개발을 담당하고 있는 안효원입니다. 저희 팀은 현대자동차그룹(현대자동차, 제네시스 및 기아)의 커넥티드카 서비스에 필요한 다양한 개발 업무를 수행하고 있으며, 서비스가 고객에게 더욱 안정적이고 효율적으로 전달될 수 있도록 다양한 기술 기반의 운영 도구와 관리 플랫폼을 구축하고 운영하고 있습니다.이번 글에서는 이러한 공간데이터 시각화 플랫폼이 필요했던 구체적인 배경과 함께, 프론트엔드 관점에서 플랫폼 구축 과정에서 마주친 다양한 기술적 난제들을 소개하고자 합니다. 또한, 시행착오를 거쳐 문제를 극복하기 위해 적용했던 기술적 접근방법들과 그 과정에서 얻은 경험 및 인사이트를 보다 자세히 공유드리겠습니다.공간데이터 시각화 플랫폼이 필요했던 이유데이터를 시각화하고 분석하는 방법에는 여러 가지가 있습니다. 일반적으로 많은 기업들이 다루는 데이터는 텍스트나 숫자를 기반으로 한 관계형 데이터로 구성되어 있으며, 주로 테이블, 그래프 또는 차트와 같은 일반적인 시각화 방식을 통해 표현됩니다. 하지만 현대자동차와 같은 자동차 및 모빌리티 기업의 경우, 기존의 일반적인 데이터 외에도 GPS 좌표(위경도 정보)를 포함한 다양한 공간 기반 데이터를 매우 빈번하게 처리합니다.예를 들어 다음과 같은 GPS 좌표 데이터를 생각해 보겠습니다.37.39552222,127.112225위 좌표는 실제 현대자동차의 판교 사무실(판교테크원)이 위치한 지점의 GPS 좌표입니다. 하지만 단지 좌표 데이터만으로는 직관적으로 위치를 파악하는 데 한계가 있습니다. 이처럼 자동차 및 모빌리티 기업은 고객들에게 제공하는 날씨 정보, 충전소 위치 정보 등 콘텐츠 데이터뿐 아니라, 차량에서 실시간으로 수집되는 도로 위 포트홀, 교통사고 지점 등 다양한 안전 관련 공간 데이터를 지속적으로 수집하고 관리합니다.이러한 데이터를 기업 내부에서 관리하고 분석하는 과정에서 텍스트 형태의 좌표만으로는 효율성에 분명한 한계가 존재합니다. 예를 들어, 담당자가 데이터 정확성을 점검하는 과정에서 경부고속도로 인근 포트홀 발생 이력 을 확인하고자 했을 때, 만약 해당 데이터가 잘못 입력되어 영동고속도로에 잘못 표기된다면 데이터 신뢰성이 저하되고 결국 고객 서비스 경험에도 부정적 영향을 미칠 수 있습니다.이 문제를 해결하기 위해 위치 정보를 텍스트 형태로 관리하는 대신, 지도 위에서 데이터를 직관적으로 시각화하여 오류를 빠르게 발견하고 관리할 수 있는 환경이 필요했습니다. 기존에도 유사한 관리 도구가 존재했지만, 대부분 외부 업체를 통해 개발된 솔루션이었기 때문에 새로운 기능 추가나 데이터 연동이 쉽지 않았고, 유지보수와 최적화 측면에서도 많은 어려움이 있었습니다. 특히 다양한 내부 데이터 연동 시 내부 의사결정 및 절차에 많은 시간이 소요되어 효율성이 떨어지는 문제도 있었습니다.이러한 배경으로, 팀 내부적으로 직접 관리와 유지보수가 가능한 서비스를 자체 개발하기로 결정하기로 한 것입니다. 임직원들이 공간 데이터를 신속하고 직관적으로 분석함으로써 데이터 품질과 정확성을 높이고, 궁극적으로 서비스 품질 개선에 기여하는 것이 주요 목표였습니다. 하지만 공간 데이터를 시각적으로 표현하는 과정은 결코 쉽지 않았습니다. 지도와의 연동 문제, 대규모 데이터 처리 성능, 인터랙티브한 프론트엔드 구현 등 여러 기술적 난제와 예상치 못한 어려움들을 마주하게 되었습니다.프론트엔드 기술 스택 선정 과정과 지도 구현 방식 결정프론트엔드 기술스택 선정과정프론트엔드 개발을 여러 해 동안 해왔고, 이제는 익숙해질 법도 하지만, 프론트엔드 기술 스택을 선정할 때마다 여전히 깊은 고민이 뒤따릅니다. 프론트엔드 생태계는 그 특성상 매년 새로운 기술과 라이브러리들이 등장하고 빠르게 변화합니다. (저희는 이를 두고 흔히 매년 새로운 Hype가 나타난다고 표현하기도 합니다.)이러한 상황에서 프론트엔드 기술 조합을 결정하는 과정은 마치 서브웨이에서 샌드위치 메뉴를 고르는 것과 비슷합니다. 모두가 선호하는 인기 있는 조합은 존재하지만, 결국 개개인의 요구사항이나 팀 상황에 따라 최적의 선택은 달라질 수밖에 없습니다. 실제로 매년 진행되는 State of Frontend 설문조사를 보더라도, 다양한 라이브러리와 프레임워크들이 매년 치열하게 경쟁하며 개발자들의 선택을 받기 위해 끊임없이 변화하고 있음을 확인할 수 있습니다.물론 음식이라면 한 번 잘못 선택해도 다음 주문에서 바꾸면 되지만, 프론트엔드 기술의 경우 한 번 선택하면 서비스 전체의 유지보수성 및 확장성에 장기적인 영향을 미치기 때문에 더욱 신중한 접근이 필요합니다.매년 보이는 스택들도 보이지만 매년 새롭게 나타나는 수많은 라이브러리들이 있습니다 (출처. https://tsh.io/state-of-frontend)다행히 현대자동차 내부 프론트엔드 조직에서는 기본적으로 표준화된 기술 스택이 이미 존재하고 있었고, 저희 팀도 가능한 이 공통 기술 스택을 활용하기로 결정했습니다.스타일링을 위한 Styled-Components, 빠른 빌드 속도와 개발 편의성을 제공하는 Vite, UI 컴포넌트 구현을 위한 React와 TypeScript가 대표적입니다. 특히 React와 TypeScript의 경우, 사내에서 공통으로 사용하는 디자인 시스템과 컴포넌트 라이브러리들이 이미 이 기술 스택을 채택하고 있었기에, 기본적인 기술 기반은 이들 위에 구축하기로 했습니다.(사내 디자인 시스템 및 컴포넌트 라이브러리에 대해서는 별도의 글로 다시 소개할 기회가 있으면 좋겠습니다.)여기에 더해, React를 조금 더 효율적으로 개발할 수 있는 Next.js, 상태 관리를 위한 Jotai 등 회사 내에서 이미 표준화되어 활용 중인 추가 기술 스택 역시 특별한 이견 없이 선택하게 되었습니다.지도 구현 방법기본적인 프론트엔드 기술 스택 선정은 상대적으로 수월하게 결정되었지만, 본 플랫폼 구축에서 가장 큰 고민거리는 지도 라이브러리의 선정이었습니다. 공간 데이터를 다루는 플랫폼의 특성상, 한 번 지도 라이브러리를 선택하게 되면 이를 나중에 변경하는 것은 매우 어렵고, 서비스 전체에 미치는 영향 또

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를 이뤄 실행한 협업의 결과물이에요. 저희는 크고 작은 제품들을 빠르게 론칭하며, 두 가지 실행 방향을 정리해 차근차근 실현해 나갔어요.첫 번째, 브랜드 노출과 매출을 높이는 기반 만들기판매자가 프로모션을 진행할 때 더 많은 고객과 만날 수 있도록 다양한 도구와 지면을 개발해