안녕하세요, 카카오 기술 블로그 독자 여러분!두 번째 글로 다시 만나게 되어 정말 반가워요. 첫 번째 글인 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 #