본 내용은 Web에 있는 오디오를 텍스트로 변환 후 GPT로 포스트를 자동 생성하는 설명입니다.특히 이벤트 주도 아키텍처(EDA) 를 통해 확장성과 실시간 처리를 구현한 과정을 소개합니다.핵심은 프론트엔드와 AI 워크플로우의 완전한 분리입니다.이를 위해 Confluent Cloud 기반 이벤트 주도 아키텍처 를 채택했습니다.🍑 이벤트 주도 아키텍처(EDA)가 필요한 이유기존 모놀리식 시스템은 확장성과 유연성에 한계가 있었습니다.기술이 발전하고 확장성과 적응성에 대한 요구가 증가함에 따라, 특히 분산 시스템과 마이크로서비스의 등장으로 인해 EDA는 자연스러운 해결책이 되었습니다.• None EDA는 상태 변경, 사용자 작업 또는 시스템 트리거와 같은 이벤트를 상호작용의 핵심 단위로 처리함으로써 시스템이 구성 요소를 분리하고 비동기적으로 통신할 수 있도록 합니다.• None 이 접근 방식은 데이터 스트리밍을 사용하며, 생산자와 소비자는 공유되고 변경 불가능한 로그를 통해 상호작용합니다.• None 이벤트는 보장된 순서대로 유지되므로 시스템은 동적이고 독립적으로 변경 사항을 처리하고 대응할 수 있습니다.사용자 중심 애플리케이션을 AI에서 분리하기 위해 Confluent Cloud의 데이터 스트리밍 플랫폼을 사용합니다.이 플랫폼은 Kafka, Flink 를 활용하고 확장 가능한 AI 애플리케이션을 쉽게 구축할 수 있게 해줍니다.사용자가 오디오 목록을 클릭하면 앱은 서버에 백엔드 캐시에서 기존 LinkedIn 게시물을 확인하도록 요청합니다.LinkedIn 게시물을 데이터베이스에 저장할 수도 있지만, 저는 오랫동안 보관할 필요가 없으므로 임시 캐시를 선택했습니다.LinkedIn 게시물이 없는 경우, 백엔드는 MP3 URL과 에피소드 설명을 포함하는 이벤트를 Kafka 토픽에 기록합니다.이를 통해 LinkedIn 게시물을 생성하는 워크플로가 시작됩니다.Apache Flink는 실시간으로 대량의 데이터를 처리하도록 설계된 오픈소스 스트림 처리 프레임워크입니다.높은 처리량과 낮은 지연 시간을 요구하는 환경에서 탁월한 성능을 발휘하여 실시간 AI 애플리케이션에 매우 적합합니다.데이터베이스에 익숙하다면 Flink SQL이 표준 SQL과 유사하다고 생각할 수 있지만, 데이터베이스 테이블을 쿼리하는 대신 데이터 스트림을 쿼리합니다.Flink를 사용하여 오디오를 LinkedIn 게시물로 변환하려면 외부 LLM을 통합해야 했습니다.Flink SQL을 사용하면 널리 사용되는 LLM 모델을 정의할 수 있어 이 작업이 간편해집니다.아래와 같이 작업(예: text_generation)을 지정하고 시스템 프롬프트를 제공하여 출력을 안내할 수 있습니다.LinkedIn 게시물을 만들기 위해 먼저 MP3 URL을 기반으로 LinkedIn 게시물 요청 주제와 주제를 연결하여 에피소드 설명과 대본을 프롬프트 값으로 결합하고 이를 뷰에 저장합니다.뷰를 사용하면 가독성과 유지 관리성이 향상됩니다. 문자열 연결을 ml_predict 호출에 직접 포함할 수도 있지만, 그렇게 하면 워크플로

요즘 AI 업계에서 가장 뜨거운 키워드를 하나만 꼽으라면 단연 Agentic AI일 것입니다.기존 소프트웨어에서 'Agent'라는 용어는 주로 단순하고 반복적인 작업을 자동화하는 도구를 지칭했습니다.그러나 LLM의 등장은 이 개념에 새로운 의미를 부여했습니다. 이제 AI Agent는 단순한 자동화를 넘어서 일정 수준의 자율성과 판단력을 갖춘 지능형 도구로 진화하고 있습니다.요즘 AI 분야에서 가장 뜨거운 화두를 꼽으라면 단연 '에이전틱 AI(Agentic AI)'일 것입니다.과거 소프트웨어에서 '에이전트'는 단순 반복 작업을 자동화하는 도구를 의미했지만, LLM의 등장은 이 개념에 새로운 의미를 부여했습니다.이제 AI 에이전트는 단순 자동화를 넘어, 목표를 설정하면 스스로 계획을 세우고 외부 도구를 활용해 문제를 해결하는, 마치 지능을 가진 조수처럼 진화하고 있습니다.이렇게 스스로 판단하고 행동하는 AI를 우리는 "에이전틱(agentic)하다"라고 표현하며, 이러한 시스템을 에이전틱 AI라고 부릅니다.마치 영화 속 자비스처럼, 사용자의 복잡한 요구사항을 이해하고 필요한 정보를 찾아오거나 외부 시스템과 연동하여 작업을 수행하는 미래가 현실로 다가오고 있는 것이죠.그렇다면 이렇게 자율적인 AI가 어떻게 현실 세계와 상호작용하며 복잡한 임무를 수행할 수 있을까요?이러한 상호 작용을 가능하게 하는 기반 기술 중 하나가 바로 Function Calling입니다.Function Calling은 LLM이 자연어 요청을 이해하고 적합한 외부 함수(API)를 호출하도록 유도하는 기술로, 사용자의 의도를 정확히 파악해 필요한 정보를 준비하는 메커니즘입니다.예를 들어 사용자가 “오늘 날씨 어때?”라고 물으면, LLM이 날씨 API 호출에 필요한 정보를 생성하여 실시간 날씨 정보를 가져오게 됩니다.이 덕분에 LLM은 더 이상 학습된 데이터에만 의존하지 않습니다.실시간 정보에 접근하고, 반복적인 작업을 자동화하며, 복잡한 워크플로우를 조율하는 등 훨씬 더 강력하고 유연한 능력을 갖추게 되었습니다.이번 글에서는 LLM의 잠재력을 한 단계 끌어올리는 Function Calling 기술에 대해 알아보겠습니다.이 기술이 왜 필요하게 되었는지, 어떤 원리로 작동하는지, 그리고 실제 오픈소스 LLM에서 어떻게 활용할 수 있는지 차근차근 살펴보겠습니다.본문에 사용된 코드는 아래 GitHub 링크에서 다운로드할 수 있습니다.기존의 LLM은 실시간 정보를 가져오거나 복잡한 계산을 수행하거나 외부 시스템과 상호작용하는 데 한계가 있었습니다.예를 들면, 특정 시점 이후의 최신 뉴스나 현재 날씨와 같은 정보는 정확히 답변하기 어려웠죠.이러한 한계를 극복하기 위해, 외부 정보를 LLM의 답변 생성 과정에 통합하려는 다양한 아이디어들이 등장하기 시작했습니다.그 중 대표적인 사례가 2022년에 발표된 ReAct (Reasoning and Acting) 기법입니다.ReAct는 모델이 질문에 대해 먼저 내부적 추론(Thought)을 수행하고 이를 바탕으로 필요한 외부 행동(Act)을 결정합

CUDA OOM 오류는 NVIDIA GPU에서 제공하는 메모리(RAM)가 부족할 때 발생하는 오류입니다.주로 딥러닝 모델 학습이나 대용량 데이터 처리 중 다음과 같은 상황에서 발생합니다:• None 모델 파라미터나 입력 데이터가 GPU 메모리를 초과잘만 돌아가던 코드에서 어느날 갑자기 CUDA OOM 이 발생했다.심지어 학습도 아니고 데이터셋 로딩 단계에서 OOM 이 발생했다.부분에서 CUDA OOM이 발생했는데...dataset 로딩은 cpu 에서 일어나는 것이지, gpu 를 사용하지 않는다. input 데이터를 gpu 로 올리는 것은 학습 시작 후 collator 에서 해주도록 코드가 구현되어 있다.이전에 비해서 데이터셋의 사이즈가 늘어나기는 했지만 애초에 cpu memory 에러도 아니고 gpu memory를 사용했다는 사실이 이상하다.torch distributed 라는게, NCCL-based process 이므로 기본적으로 GPU 를 이용한 통신을 사용한다.obj 가 들어오면 이걸 pickle 로 변환하고, 해당 pickle 을 tensor 로 변환하는 작업부터 시작하는 것이다.이 때 torch.cuda.current_device() 를 통해 rank 별 GPU 를 설정하고, 각 rank 의 데이터를 각 rank GPU 에 올린 뒤 통신을 시작한다.그러니까 결국 CPU 에 있는 데이터를 한데 모으고 싶었던 것 뿐인데, 모든 데이터가 GPU 로 올라가고 all-gather 를 해버린 것.데이터가 늘어나면 OOM 이 발생할 수 밖에 없는 구조였다 (지금 발견해서 다행이다)해결법은 두가지 정도가 생각난다.• None 데이터를 일정 chunk 단위로 끊어서 all-gather를 해줌으로써 순간 GPU memory 사용량을 줄여주는 것• None 장점: Distributed 세팅에 최적화. 32 노드를 사용한다고 치면, 32 * 8 = 256 GPU 에서 distributed loading 이 가능해진다. (빨라짐)• None 단점: 근본적으로 GPU 를 사용하지 않아도 되는 것에서 GPU 를 사용한다. GPU 간 통신 속도가 느리다면 데이터 로딩도 느려진다.• None torch distributed 가 아닌 multiprocessing 을 이용해서 데이터를 로딩하는 것• None 장점: 모든 데이터가 CPU 에서 로딩된다.• None 단점: 노드별 distributed loading은 불가능하다. RANK 별로 붙어있는 CPU 개수만큼만 multiprocessing 이 가능 (나의 경우 32)• None Lazy loading 을 이용하여 학습시 각 rank 에서 필요한 데이터만 loading• None 단점: Sorted batch 와 같이 미리 데이터를 로딩해야 사용할 수 있는 테크닉을 쓸 수 없다.현재 나의 상황은 노드가 매우 많으며 (>32), 노드끼리 전부 infiniband 로 연결되어 GPU간 통신 속도가 매우 빠르고, 데이터가 너무 많아서 최대한 분산을 쳐야 하고, sorted batch 와 같은 테크닉들을 모두 적용해

지금의 방식이 최선일까? AI로 임팩트를 바꾸는 당근 운영실 — 당근 AI Show & Tell #3당근은 매주 ‘AI Show & Tell’을 통해 각 팀의 AI 실험을 전사적으로 공유해요. AI를 업무에 어떻게 적용하고 있는지, 그 과정에서 어떤 시행착오와 인사이트가 있었는지를 가감 없이 나누죠. 당근은 완벽한 정답을 찾기보다 먼저 과감하게 실행하며, AI 전환에 빠르게 몰입하고 있어요. AI로 만드는 생생한 도전의 순간들, 지금 만나보세요.✍️ 이 콘텐츠는 생성형 AI를 활용해 제작한 콘텐츠입니다.서비스 운영실 팀 내부 세션 ‘Nextstep for Service Operation’ 발표 자료당근 운영실은 최근 AI를 활용해 실행과 학습 속도를 높일 수 있도록 조직 구조와 일하는 방식을 재설계했어요. 그 구체적인 변화는 🔗‘모두가 AI 로켓에 올라타도록, 당근 운영실이 AI로 일하는 법’에서 소개해 드렸는데요. 이번에는 ‘당근 AI Show & Tell’ 세션에서 발표된 내용을 바탕으로, 그 전환이 어떤 구체적인 결과물로 이어졌는지 전해드리려 해요.이번에 소개할 세 가지 프로젝트는 기존의 문제 해결 방식을 AI를 통해 새롭게 바라본 시도들이에요. 지금의 방식이 정말 최선인지 근본부터 다시 점검했고, 더 효과적인 해결 방법을 새롭게 기획했죠. 이후 “AI를 활용하면 빠르게 구현할 수 있다”는 확신 아래, 과감하게 실행에 나섰어요. 수개월간 준비하던 프로젝트를 AI 기반 프로덕트로 전면 피봇한 사례부터, 반복 업무를 줄이기 위해 비개발자가 주말 동안 직접 AI 툴을 만들어낸 실험까지 — 그 치열한 몰입의 과정을 지금부터 하나씩 살펴볼게요.Project 1. 누구나 쉽게 조립하는 멀티 AI 에이전트 시스템, ‘KAMP’AI 전환이 본격화되던 시기, 운영개발팀은 여러 차례 논의와 얼라인을 거쳐 팀원 모두가 멀티 AI 에이전트 시스템을 염두에 두고 있다는 점을 확인했어요. 이는 서로 다른 역할의 AI들이 협업해 복잡한 문제를 효율적으로 처리하는 구조인데요. 제재 사유 설명이나 운영 정책 안내처럼 다양한 데이터를 다뤄야 하는 CS 업무에서는 AI 에이전트의 역할을 분리하는 게 응답 정확도와 처리 속도 모두에 유리했어요. 운영개발팀은 서비스별로 필요한 CS 대응 시스템을 누구나 쉽게 구현할 수 있도록, 개발 없이도 에이전트를 조합할 수 있는 플랫폼을 기획했어요.이렇게 탄생한 것이 운영개발팀 Backend Engineer Julius가 개발한 KAMP(Karrot Agent Management Platform)예요. KAMP는 ‘프로젝트–에이전트–도구’라는 세 가지 요소로 구성돼 있어요. 프로젝트는 해결하려는 문제, 에이전트는 LLM 기반으로 역할을 수행하는 AI, 도구는 외부 정보를 조회하거나 특정 행동을 할 수 있도록 해주는 API를 의미하죠.이 세 가지를 상황에 맞게 조합하기만 하면, 복잡한 응대 시나리오도 코드 없이 손쉽게 구현할 수 있어요. 예를 들어 기본적인 사용자 질문에 응대하는 ‘고객지원 상담사’ 에이전트에게는 사용자 정보를 조회할

컴퓨터 비전 AI 성능의 핵심은 올바른 카메라 선택에 있습니다. 이 가이드에서는 영역 스캔, 단파 적외선, 라인 스캔, CCTV 등 산업용 카메라 4가지 유형의 특징, 활용 사례 및 통합 시 고려사항을 알아봅니다. 제조 검수 자동화와 품질 관리를 위한 최적의 카메라 솔루션을 찾아보세요.필자: 슈퍼브에이아이 대표 김현수컴퓨터 비전은 고품질 이미지 데이터에 의존하기 때문에 최적의 성능을 보장하기 위해서는 올바른 카메라를 선택하는 것이 중요합니다. 카메라 종류마다 특장점이 다르기 때문에 제조 검수 또는 위협 탐지가 목적인 경우에는 불량 검수 자동화가 목적인 경우와 다른 카메라를 사용하는 것이 좋습니다.이번 가이드에서는 산업 및 제조 비전 AI에 사용되는 4종류의 카메라와 실제 활용 사례, 그리고 카메라를 시스템과 통합할 때 고려해야 할 사항들에 대해 알아보겠습니다.1. 정적인 이미지 검사에 적합한 “영역 스캔(Area Scan) 카메라”영역 스캔 카메라(Area scan camera)는 시각적으로 확인할 수 있는 스펙트럼(RGB) 내에서 온전한 2D 이미지를 구현할 수 있어 객체가 검수를 위해 일시 또는 완전 정지하는 시나리오에서 사용하기 적합합니다. 특히 제조 품질 검사와 같이 상품을 반드시 정해진 절차에 따라 처리하고 정적인 상태에서 촬영할 수 있는 경우 많이 사용됩니다.• 생산 라인 품질 검사(예: 전자기기나 기계 부품의 결함 확인 등)• 깨끗하고 정적인 이미지가 많은 일반적인 산업용 검수• 조명이 변하지 않고 통제된 환경에서 가장 좋은 성능을 보임• 스냅샷 촬영을 위해 생산 라인이 잠시 멈춰야 함• 기존의 머신 비전 시스템과 통합하기 용이함• 안정적인 이미지 다운로드를 위해 일반적으로 USB보다는 PoE 카메라를 권장함• Lucid Vision Labs: 공정 자동화에 적합한 고성능 영역 스캔 카메라 개발사. 품질 관리 및 제조 검수용 깨끗한 풀프레임 이미지 제공• IDS: USB 및 GigE 영역 스캔 카메라 제공. 산업용 생산 라인과 부드럽게 통합되도록 설계되어 안정적인 결함 탐지 및 공정 모니터링 가능• MindVision Technology: 초고속 검사, 전자기기 제조, 품질 관리 자동화 시스템을 위한 정밀 촬영 등에 최적화된 산업용 영역 스캔 카메라 제공2. 가시 스펙트럼을 넘어 촬영할 때 적합한 “SWIR(단파 적외선) 카메라”SWIR 카메라는 사람이 시각적으로 인식할 수 있는 파장 너머를 인식하기 때문에 일반적인 RGB 카메라로는 보이지 않는 결함을 탐지할 수 있습니다. 특히 원료나 수분, 또는 눈에 띄지 않는 이상함을 탐지할 때 유용합니다.• 재료 품질 분석(예: 플라스틱, 직물, 반도체 등의 결함 탐지)• 일반 RGB 카메라보다 비용이 높음• 정확한 결과를 위해 특수한 조명이나 필터가 필요한 경우가 많음• Lucid Vision Labs: Sony의 SenSWIR 센서를 부착해 폭넓은 스펙트럼에서 고해상도 이미지를 촬영할 수 있는 SWIR 카메라 제공• 1stvision: GigE 인터페이스와 라인 스캔 이미징을 적용

1. 바이브 코딩과 AI 에이전트안드레이 카파시(Andrej Karpathy)는 2025년 초 “바이브 코딩(Vibe Coding)”이라는 용어를 도입하면서, 사람 대신 대형 언어 모델(LLM)에 의존해 코드를 생성하는 새로운 코딩 방식을 제시했습니다 (바이브 코딩 - 위키백과). 전통적인 프로그래머가 일일이 코드를 타이핑하는 대신 자연어로 의도를 표현하면 AI가 실제 코드를 만들어주는 형태입니다. 카파시는 자신의 코딩을 “실제로 코딩하는 게 아니다. 그냥 보고, 말하고, 실행하고, 복사해서 붙여넣으면 대부분 작동한다”고 묘사했는데, 실제로 그는 Cursor 같은 AI 코드 에디터와 음성 입력 도구를 활용해 “사이드바 패딩을 반으로 줄여줘”처럼 말로 코딩하고, 결과를 바로 적용해가며 작업한다고 합니다. 이렇게 AI에 완전히 몸을 맡기고 코드의 세부 구현보다는 지수적 발전을 받아들이는 코딩 스타일이 바로 바이브 코딩의 철학입니다.바이브 코딩이라는 개발 철학 또는 스타일은, 이를 기술적으로 실현시켜주는 핵심 동력인 AI 에이전트의 발전과 함께 진화하고 있습니다. 즉, 개발자의 사고방식과 작업 흐름의 변화(바이브 코딩)를 AI 에이전트라는 구체적인 기술이 뒷받침하는 것입니다. 최신 LLM 기반 AI들은 단순 코드 생성뿐 아니라, 프로그래머의 “페어(Pair) 코더” 혹은 에이전트로서 실시간으로 제안을 하고 반복적인 작업을 자동화해줄 정도로 성장했습니다. 다시 말해, 사용자가 평문으로 의도를 말하면 AI 에이전트가 이를 실행 가능한 코드로 변환하고, 필요한 표준 코드 구조까지 만들어주는 AI 개발 환경이 현실화되고 있습니다. 바이브 코딩은 이러한 환경에서 사람이 코드의 정확한 구현보다는 아이디어와 문제 정의에 집중하고, AI 에이전트는 코드 작성과 보조 역할을 맡는 새로운 협업 모델을 의미합니다. 즉 개발자는 코드를 “직접” 짜기보다 AI와 대화하면서 결과물을 얻고, 필요하면 AI에게 오류 수정이나 개선도 연쇄적으로 요청해가며 목표한 기능을 구현해나갑니다. 이렇게 하면 초기 프로토타입을 매우 빠르게 만들 수 있는데, 실제로 비개발자가 바이브 코딩을 활용해 개인용 소프트웨어를 몇 가지 만들어본 사례들도 종종 소개됩니다. 종합하면, 바이브 코딩은 “프로그래밍 언어로서의 자연어”라는 비전을 담고 있으며, AI 에이전트의 힘으로 더 많은 사람이 소프트웨어를 신속하게 만들 수 있는 시대를 열고 있습니다.2. 바이브 코딩 시대의 프롬프트 엔지니어링 중요성과 역할바이브 코딩에서는 프롬프트(prompt), 즉 AI에게 보내는 자연어 명령과 지시문의 품질이 곧 코드 결과물의 품질을 좌우합니다. 카파시가 “가장 인기 있는 새로운 프로그래밍 언어는 영어”라고 농담했듯이, 이제 자연어로 AI를 “프로그래밍”하는 능력이 중요해졌습니다. 실제 OpenAI의 GPT-3 논문 등에서도 LLM은 프롬프트 안에서 프로그램되는 것처럼 동작한다는 점이 강조되었고, 작은 문구 설계 차이가 결과물의 품질을 크게 바꿀 수 있음이 밝혀졌습니다. 이는 곧 정교하게 구성된 프롬프트 한 줄이

개발 지식이 온전하지 않아도 일단 무언가를 만들 수 있게 되었습니다. 이런 시대에 비개발자는 바이브 코딩(Vibe Coding)으로 어디까지 개발자 흉내를 낼 수 있을까요? 이 질문의 여정을 몇 편의 글로 나누고자 합니다.'AI Native’이고 'AI monolingual’인 개발자코딩을 AI 시대에 처음 시작한 것은 아니지만, ‘개발’이라 할 수준이 아니었기 때문에, 저의 개발 모국어는 AI라고 말해도 과언이 아닙니다. 즉, 저는 개발에 있어 AI Native 입니다. 그리고 다른 개발 언어가 아닌 오직 AI로만 개발할 수 있는, AI Monolingual이라 할 수 있습니다(이런 표현이 있는지는 모르겠네요). 프롬프트만으로 개발한다는 점에서 ‘Vibe Coder’라고도 할 수 있겠습니다. 다르게 표현하자면, 저는 비개발자입니다.AI Monolingual이기에 저는 개발을 시작할 때 항상 AI에 의존합니다. AI를 가장 소극적으로 활용한다면, LLM에게 방법을 물어보며 제가 하나씩 해결해 나갈 것이고, AI를 가장 적극적으로 활용한다면 에이전트(agent)에게 진단부터 적용까지 모든 과정을 맡길 것입니다.예를 들어 깃허브(GitHub) 원격 저장소에 로컬 작업사항을 푸시(push) 할 때, ChatGPT에게 방법을 물어보면 터미널 명령어를 알려주는데요, 이를 따라하면 개발자들이 하는 일을 유사하게 할 수 있습니다. 그 지식을 익히면 다음에는 ChatGPT에게 묻지 않아도 푸시할 수 있습니다. 반면 코파일럿(Copilot)의 에이전트로 같은 작업을 한다면, ‘현재 버전을 main에 push해 주세요’라는 자연어 입력만으로 충분합니다. 에이전트가 알아서 터미널에 명령어를 실행하여 상태를 확인하고 커밋(commit)과 푸시를 완료합니다. 에이전트가 어떤 명령어를 사용하는지 볼 수는 있지만, 굳이 확인하거나 알지 않아도 목표한 작업을 수행할 수 있습니다.'푸시 해야지’라고 생각했을 때, 자연스럽게 후자의 방식이 떠오르는 것이 AI Native가 지향하는 사고방식에 더 가까울 것 같습니다. 할 수 있지만 직접 하지 않아도 되는 작업을 AI에게 맡긴다는 점이 중요한 전환 같습니다. 저는 AI 없이는 개발할 수 없기 때문에 습관적으로 스스로 해결하려는 단계 없이 바로 AI를 찾게 되는데요, 이런 점에서 AI Native 개발의 모습을 기존 개발자 선배님들과 다른 방향으로 접근해야 하는 것 같습니다.기다리는 것이 배우는 것보다 빠르다6개월 전과 비교하여 저의 프롬프팅(prompting) 역량에는 큰 차이가 없지만, 만들어내는 결과물에는 큰 차이가 있습니다. 학습으로는 몇 달 사이에 도달할 수 없는 성장을, 기술의 발전이 대신 이뤄내고 있는 시대입니다. 그래서 감히 ‘기다리는 것이 배우는 것보다 빠르다’는 말을 해봅니다. 현재의 구현 능력에 한계가 있어 벽을 만났을 때, 물론 당장은 문제 해결을 위해 최선을 다하겠지만, 곧 더 강력한 에이전트나 새로운 기술이 등장해 그 벽을 허물고 가능성의 영역을 확장해갈 것입니다.한 가지 사례를 공유합니다. 아래는

부제: 프로토타입부터 프로덕션 팀의 실무까지, 단계별 실험 사례를 통해 확인한 바이브 코딩의 가능성과 한계들어가며지난 4월 15일, 사내 개발자들과 ‘바이브 코딩(vibe coding)’을 주제로 라이브 인터뷰를 진행했습니다.이 글은 그 인터뷰와, 지난 3월 중순부터 진행한 바이브 코딩 실험을 바탕으로 한 기록입니다.AI 에이전트와의 협업이 실제 개발에 어떤 변화를 가져오는지 직접 느낀 점들을 공유합니다.바이브 코딩이란?Q. 바이브 코딩이...

🔁 OpenAI 기반 MCP 에이전트를 Gemini 기반으로 바꾸는 실전 사례기존 OpenAI 기반 프로젝트를 다른 모델(Google Gemini, Claude, Mistral 등)로도 유연하게 실행할 수 있는 구조를 갖추는 것이 매우 중요해졌습니다.이번 글에서는 제가 직접 실습해 본 기반 Youtube 추천 에이전트를 OpenAI에서 Google Gemini로 교체한 과정을 공유하고자 합니다.AI 에이전트 개발은 이제 특정 모델에 종속되지 않고, 다양한 LLM을 상황에 따라 유연하게 사용하는 능력이 중요해졌습니다.특히 API 기반으로 동작하는 Gemini, Claude, Mistral 등도 OpenAI 못지 않게 빠르게 발전하고 있기 때문에, 코드를 모델 간에 이식 가능하도록 구조화하는 연습이 중요하다고 생각했습니다.MCP는 LLM 기반 시스템에서 에이전트가 외부 도구(function/tool) 와 통신할 수 있도록 해주는 구조입니다.예를 들어 사용자가 유튜브 영상을 추천해달라고 요청하면, LLM은 같은 도구를 호출하고, 그 결과를 다시 사용자에게 자연어로 출력합니다.MCP 구성 요소는 다음과 같습니다:• None : LLM과 대화하고, 필요한 도구 호출을 중계• None : 도구(function)를 실행하는 서버• None : 에이전트가 사용할 수 있는 기능 목록 (예: 유튜브 검색)OpenAI 기반 클라이언트는 다음과 같은 흐름으로 동작합니다:• None GPT가 도구 호출(function_call)을 응답에 포함• None 클라이언트가 해당 도구를 MCP 서버에 호출• None 도구 결과를 GPT에 다시 전달하여 최종 응답 생성• None 응답을 옵션으로 스트리밍 출력• None tools: OpenAI에 도구 명세를 JSON Schema 기반으로 전달이제 동일한 기능을 Gemini 기반에서 수행하도록 바꿔보겠습니다. 핵심 목표는 다음과 같습니다:• None OpenAI 의존성을 제거하고 Gemini API 활용• None MCP 서버와의 도구 호출 연동 유지• None 응답을 자연어로 처리하는 흐름 유지Gemini는 google.generativeai 패키지를 통해 사용할 수 있습니다. API 키를 환경변수로 설정한 후, 모델을 초기화합니다.2. MCP 도구 → Gemini 도구로 변환OpenAI에서는 tool_call 명세를 JSON으로 직접 전달하지만, Gemini에서는 types.Tool() 형태로 선언해야 합니다.• None openai_schema: 기존 MCP 도구가 JSON Schema로 선언된 형식• None Gemini는 이 스키마를 그대로 호환하므로 손쉽게 재활용 가능Gemini는 generate_content() 메서드를 통해 입력을 처리합니다. 이때 도구 정보도 함께 전달해야 합니다.• None contents: 대화 이력 입력 (OpenAI의 messages에 해당)• None function_calling_config: 도구 호출을 자동으로 처리하도록 설정Gemini의 응답에서 도구 호출이 포함된 경우

안녕하세요! 저는 IT 회사에서 프로젝트 관리 업무를 하고 있습니다.현재는 개발 업무를 하지 않지만 신입 시절에는 Visual Basic, Oracle, VMS, COBOL 등 미들웨어 관련 개발도 했고, 웹 개발 경험이 있습니다.시간이 지나면서 지금은 개발보다는 프로젝트 전반을 관리하고 이것저것 잡일(?)을 도맡아 하고 있습니다. 😂작년에 데보션에 처음 합류하면서 Java, Spring Boot 등에 관심을 갖게 되었고, 혼자서 유튜브나 온라인 강의를 통해 공부도 해봤습니다.하지만 항상 드는 생각은 "공부를 해도 돌아서면 금방 잊어버린다"는 거였죠. 반복해서 보고, 코딩해보고 해도 실무에서 자주 쓰지 않다 보니 잊혀지기 마련입니다.그러던 중 우연히 Cursor AI라는 툴을 알게 되었고, 사용하면서 인상이 깊어 이렇게 블로그에 사용기를 남겨보게 되었습니다.간단히 말하면 Cursor AI는 ChatGPT가 내장된 AI 코드 편집기입니다.VS Code 기반의 에디터이며, 내장된 에이전트(Agent)가 LLM과 협력해 코드를 자동으로 완성하고, 리팩토링하고, 설명해주는 똑똑한 도구입니다.Cursor에서 가장 놀라운 기능은 바로 Agent입니다.일반적인 프롬프트 입력처럼 자연어로 "파이썬으로 구구단 프로그램을 만들어줘"라고 말하면, 실제로 파일을 생성하고 주석까지 달아서 코드를 생성해줍니다.프론트엔드/백엔드 상관없이 다양한 언어(Python, Java, Kotlin, JavaScript 등)의 코드 생성을 지원하고, 질문을 대충 해도 이해하고 코드로 응답해줍니다.물론 더 정확하고 디테일하게 질문하면 더 품질 좋은 결과물이 나오는 건 당연하겠죠!제 업무 중 하나는 사내 인트라넷 시스템 유지보수인데요, 총 16대의 웹서버가 있고 각 서버는 L4 스위치를 통한 이중화 구성입니다.인프라 팀에서 포트 기반 모니터링을 하긴 하지만, 실제 브라우저 접속을 통한 테스트는 자동화가 안 되어 있었습니다.그래서 Cursor Agent에게 이렇게 물어봤습니다:하지만 사내 VDI 환경에서는 인터넷이 안 되어 pip 설치가 안 되는 상황이 발생했고, Cursor에게 도움을 요청했습니다."사내망이어서 인터넷이 안 돼. pip 설치 안 되는데 어떻게 해야 해?" 그러자 로컬에서 필요한 패키지를 다운로드하고, VDI에 복사한 뒤 설치할 수 있는 방식으로 코드를 만들어줬습니다.. 중간에 의존성 이슈나 순서 문제로 몇 번 막히긴 했지만, Cursor는 묵묵히 도와줬고, 결국 완성할 수 있었습니다.• None .env 파일에 로그인 정보(ID/PW)를 저장• None 크롬 브라우저로 실제 사이트 접속• None 자동 로그인 또는 수동 로그인 처리• None 그리고 마지막에는 리팩토링까지 요청해서 코드 품질을 다듬었습니다. 이 모든 걸 Cursor와 ChatGPT Plus를 병행하며 수행했어요. 결과적으로 아래와 같은 실제 자동화 스크립트 + 결과 리포트까지 완성했습니다:파이썬을 잘 아시는 분들이라면 짧은 시간에 만들 수 있었겠지만, 저처럼 개발 업무가 주가 아닌 입장에서는 Cu