이번 글에서는 에이닷 멀티LLM WEB 기반 프로젝트를 진행하며 경험한OS 및 브라우저별 특성, QA 과정에서 마주쳤던 어려움, 그리고 WEB 검증 시 중점적으로 살펴봐야 할 요소 등 전반적인 노하우를 공유하고자 합니다.본 내용은 각 WEB 사이트의 개발 환경, 구현 방식, 로직에 따라 다소 차이가 있을 수 있으니 참고해주시기 바랍니다.WEB 검증은 기기, 운영체제, 브라우저 환경(브라우저 버전 등 포함)등 조합이 다양하여 검증 전 유관부서와 함께 품질을 보장하는 커버리지에 대해 협의 후 진행하는게 좋습니다.에이닷 경우 모바일 브라우저와 PC 브라우저 화면 구성이 달랐고, 화면 크기에 따라 반응형 디자인으로 동작하였습니다.품질 보장 커버리지는 브라우저/OS 시장 점유율, 각 운영체제, 기기의 대표 브라우저 등을 고려하여 협의 후 선정하여 진행하였습니다.브라우저/OS 시장 점유율은 아래 사이트에서 확인 가능합니다.• None 브라우저 / 사용 OS / OS 버전 등 기간/나라 별로 점유율 조회 가능(https://gs.statcounter.com/)• None Chrome / Samsung Internet(Android) / Safari(MAC/iOS) / Whale / Edge : 우리나라 TOP 5 위 브라우저에 한하여 검증 진행 하였으며, 최신브라우저 버전으로 검증 진행하였습니다.• None 브라우저가 하위버전일 경우 최신 표준 규격 적용 시 기능이 정상적으로 동작하지 않는 경우가 있습니다. 브라우저 구버전에 동일 기능을 적용하려면 분기 되어 각 개발 적용이 필요하여 리소스 소요가 증가할 수 있어,서비스 오픈 시기,기간,타겟 등 고려하여 QA 시작 전 논의/협의 후 진행이 필요합니다.앞서 언급한 것처럼, Web 테스트는 테스트 기기, 브라우저, OS에 따라 다양한 조합으로 진행할 수 있습니다.각 조합별로 고유한 특징이 존재하며, 이에 따라 검증 과정에서 기대했던 결과와 실제 결과가 달라지는 경우도 종종 발생하였습니다.실제 테스트 과정에서 경험했던 몇 가지 대표적인 특징들을 정리해보았습니다.• None 다크모드는 WEB 브라우저의 테마 색상을 어둡게 변경하는 것을 의미합니다.• None 다크모드 셋팅은 아래 두가지 영향을 받을 수 있습니다.• None WEB에서 구현한 다크모드 적용을 확인하려면 어떻게 셋팅 되어야 할지 아래와 같이 정리하였습니다.• None WEB 자체 별도 시스템 설정이나, 추가적인 커스텀마이징 되는 경우 동작 상이할 수 있습니다.• None ❗❗) Samsung-internet 경우 기본 브라우저 다크모드 동작은 자체 로직을 통해 컨텐츠의 색상을 변경합니다. 이는 실제 개발에서 구현된 색상과 다르게 표현될 수 있습니다.• None 삼성인터넷에서 각 서비스 개발에서 구현된 색상 확인을 위해서는 삼성인터넷-설정-실험실 "웹사이트 다크 테마 사용" 옵션을 ON 해줘야 합니다.Mobile 이미지 다운로드• None 저희 서비스에서는 이미지를 다운로드 받을 수 있는 기능이 있습니다.• None LLM 응답에 포함되는 이미지

본 내용은 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 호출에 직접 포함할 수도 있지만, 그렇게 하면 워크플로

안녕하세요. 상용개발센터 CV AI LAB 윤재욱 책임입니다. CV AI LAB은 AI, LLM 기술의 PoC를 inhouse로 개발 및 검증하는 그룹입니다.이번 포스팅은 국내 1호 프롬프트 엔지니어 강수진 박사의 강의를 소개하겠습니다.이 영상을 추천 드리는 이유는, 프롬프트에 대한 기본적인 설명뿐만 아니라 최신 트랜드인 Reasoning model 을 수행할 때 어떤 방식의 프롬프트 전략이 유효한지 자세히 설명하고 있다고 생각해서 인데요. 특히, 강수진 박사의 경우 언어학 전공으로 프롬프트 엔지니어링에 대해 언어학적인 관점으로 어떤 전략으로 대응할 것인지에 설명하고 있기 때문에, 개발자들에게는 조금 부족할 수 있는 언어학적 관점이 자연어 처리인 프롬프트 전략 수립에 도움이 될 것이라고 생각하여 영상을 추천드립니다.# 영어에 1~5형식이 있듯이, 프롬프트에도 4형식이 있다.영어에 1~5형식 문장 있듯, 프롬프트에도 4형식 문장이 있다 (강수진 박사)1. 프롬프트 구성의 기본 요소프롬프트를 효과적으로 구성하기 위해서는 네 가지 기본 요소가 필요합니다. 네 가지 기본 요소는 지시 (Instructions), 입력 데이터(Input Data), 문맥 (Context), 출력 지시문 (Output Indicatior) 구성됩니다. 각 구성 요소에 대한 설명은 아래와 같습니다.명령문: 사용자가 원하는 행동을 지시하는 문장. 예) HMG Developer 블로그 작성을 위한 글을 작성해줘.문맥: 추가적인 정보나 배경 설명. 예) HMG Developer 블로그는 HMG 개발자들이 정보를 공유하기 위한 공간입니다.입력 데이터: 언어 모델이 참고해야 할 정보. 예) 이번 작성글은 국내 1호 Prompt Engineer인 강수진 박사에 대한 설명과 prompt engineering에 대한 기본 정보에 다루려고 합니다.출력 지시문: 응답 형식이나 포맷을 지정하는 문장. 예) 출력을 블로그 발행 text에 맞게 제목, 소제목, 내용 기준으로 작성하고, bullet point로 문장 구분해서 작성해줘.2. 맥락의 중요성언어 모델에서 맥락은 매우 중요합니다. 이는 사람의 대화와 비슷하다고 판단할 수 있는데요. 예를 들자면 오늘 지인과 점심식사에 대한 메뉴 이야기를 하고 있다가, 갑자기 이와 관계없는 주제에 대해서 이야기한다면 상대방이 이에 대해 알아듣지 못하는 경우가 발생할 수 있습니다. 언어모델에게도 배경설명이 중요하고, 이를 기준으로 질문했을 때 이전에 했던 질문이나 대화의 흐름을 기억하여 더 나은 응답을 제공할 수 있습니다.3. 프롬프트 유형 A, B, C, D사용자는 사용하는 LLM의 유형이나 필요로하는 정보에 따라 프롬프트의 유형을 나누어서 선택하는 것이 효과적인 응답을 얻을 수 있습니다. 강수진 박사는 프롬프트의 유형을 총 4가지로 나눌 수 있다고 이야기하고 제시한 유형은 아래와 같습니다.타입 A: 지시문 + 출력문 - 가장 기본적인 질문 형식입니다. 질문의 내용과 원하는 출력의 양식만 제안하는 형식입니다.   예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야?타입 B:지시문 + 맥락 + 출력문 - 추가적인 맥락을 제공하는 질문 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 언어 모델의 '추론 성능'과 관련된 내용으로만 답변해줘.타입 C: 지시문 + 맥락 + 예시 +출력문 - 타입 B에 예시를 포함한 질문 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 언어 모델의 '추론 성능'과 관련된 내용으로만 아래 예시의 구조처럼 답변해줘.타입 D: 지시문 + 입력값 + 출력문 - 입력값을 변수로 지정하여서 동일 질문의 형식을 활용해서 다양한 답변을 받을 수 있습니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 아래 {입력값}을 활용해서, 내용을 보충해줘. 한 문단으로 완성해4. 결론프롬프트 엔지니어링은 AI와의 상호작용에서 중요한 역할을 수행합니다. 프롬프트 엔지니어링은 수학공식과 같이 정확한 공식이 있는 것이 아니라 문학적인 관점과 같이 다양한 형태에 따라 결과값이 달라질 수 있습니다. 강수진 박사가 제안한 형식을 기본으로 사용하되, 사용자가 원하는 결과물을 얻기 위해  다양한 요소를 조합하여 효과적인 프롬프트를 작성하는 것이 필요할 것으로 판단됩니다.#  김훈처럼 써라. ChatGPT도 단문, 두괄식, 명쾌한 동사 좋아한다. 김훈처럼 써라. 챗GPT도 단문, 두괄식, 명쾌한 동사 좋아한다 (강수진 박사)이 컨텐츠의 핵심 주제는 효과적인 프롬프트 제작법으로, 간단하고 명확한 언어 사용이 중요하다는 점을 강조합니다. 강수진 박사는 단문, 명확한 동사, 그리고 일상어를 활용하여 AI와의 소통을 개선하는 방법을 제시하며, 이러한 요소들이 결과물의 질을 높이는 데 기여한다고 설명합니다. 따라서, 프롬프트를 작성할 때는 간결하고 직관적인 표현이 필수적임을 강조합니다.1. 효과적인 프롬프트 제작법첫 번째 : 간단하고 명확한 단어의 프롬프트 AI와 잘 대화하기 위한 가장 간단한 방법은 간단하고 짧은 프롬프트로 시작하는 것입니다. 특히 명확한 동사를 사용하는 것이 중요하고, 뜻이 하나인 동사를 써야 사용자가 원하는 결과를 얻는데 도움이 됩니다. 예) "체중을 줄이다" 보다는 "체중을 감소시키다"의 단어를 사용하는 것이 명확한 의도를 전달하는데 좋습니다. 또한 일상어를 사용하는 것이 원하는 결과를 얻는데 도움이 될 수 있습니다. 이는 언어모델이 학습한 데이터가 web base를 기반으로 학습되었기 때문에 대부분의 단어들이 일상어로 구성되어 있기 때문입니다.두 번째 : 지시하는 문장을 처음 또는 끝에 배치 프롬프트 문장에서 위치도 중요합니다. 일부 언어 모델의 경우 지시문이 마지막에 들어가는 경우 정확한 답변을 제공합니다. 이러한 문제가 생기는 이유는 프롬프트가 긴 경우 중간에 내용을 언어모델이 이를 놓치는 경우가 발생 (Lost in the middle 현상이라고 부름)하여, 지시문에 따라 정확한 답변을 수행하지 못하는 경우가 있습니다.세 번째 : 기호를 활용 기호를 사용하면 AI가 정보를 더 잘 이해하고

LY Corporation에서는 2024년 10월에 사내 웹 프런트엔드 개발에 관여하는 사내 구성원을 대상으로 본인이 생각하는 2024년의 웹 프런트엔드 관련 근황 및 관련 툴 이용 현황을 알아보는 설문 조사, 'State of LY Frontend 2024'를 실시했습니다. 이와 유사한 설문 조사로 State of JavaScript나 State of CSS가 많이 알려져 있는데요. 이런 설문 조사의 LY Corporation 사내 버전이라고 생각하시면 이해하기 쉬울 것 같습니다.이번 설문 조사는 합병 후 1년여의 시간이 흐르며 새로 탄생한 회사의 체제가 정비된 후 처음으로 전사적으로 실시된 설문 조사입니다. 그 덕분에 웹 프런트엔드 개발자만 342명이 참여하는 등 단독 그룹사 직원을 대상으로는 드물게 대규모 조사 결과를 얻을 수 있었습니다.이례적으로 많은 응답을 받은 만큼 설문 조사 결과 내역을 더 자세히 살펴볼 수 있는 웹페이지도 제작했습니다(아쉽지만 사내에서만 접근 가능해 이 글에서 공유하지는 않겠습니다). 이를 통해 서로 관련 있는 각 문항의 응답을 연관 짓고 비교해 볼 수 있었고, State of JavaScript 및 State of CSS의 결과와 비교해 LY Corporation의 웹 프런트엔드 동향은 어떠한지 그 특징을 자세히 살펴볼 수 있었습니다. 이번 글에서는 그 중에서 특히 흥미로웠던 점을 골라 살펴보겠습니다.• 대상: LY Corporation 그룹 프런트엔드 엔지니어(한국, 일본, 베트남, 대만 조직 소속)다음은 응답자의 소속 조직을 살펴본 결과입니다. 응답자 비율을 살펴보면 일본(LY Corporation) 외에도 베트남 거점(LINE VIETNAM COMPANY LIMITED/LINE TECHNOLOGY VIETNAM CO., LTD)과 한국 거점(LINE Plus Corporation), 대만 거점(LINE Taiwan Limited) 등 다양한 지역의 구성원이 설문 조사에 참여했습니다.다음은 응답자들의 현재 회사에서의 근무 기간을 조사한 결과입니다. 입사한 지 5년 미만인 임직원의 비율이 가장 높았으며 10년 이상 근무한 임직원도 상당수 있었습니다. 또한 조직에 따라 응답자들의 근무 기간 구성 비율에 편차가 있다는 것도 알 수 있었습니다.다음은 현재 어떤 분야의 업무를 맡고 있는지 조사한 결과입니다. 복수 응답이 가능했는데요. 백엔드 개발에 참여하고 있다고 답한 응답자 중 77%가 프런트엔드 개발에도 참여하고 있다고 응답했습니다. 특히 Yahoo Japan Corporation 출신 구성원 중 상당수가 프런트엔드를 담당하면서 백엔드 나 디자인 분야를 함께 담당하고 있는 것으로 나타났는데요. 이는 구 LINE Corporation에서는 웹 프런트엔드 개발이 비교적 독립적인 개발 조직이었던 반면, 구 Yahoo Japan Corporation에서는 백엔드 개발자나 디자이너가 웹 프런트엔드 개발을 겸하는 경우가 많았기 때문입니다.또한 위 조사 결과에서는 응답자 342명 중 웹 프런트엔드 개발을 담당한다고 응답

'나’는 누구인가?카카오에서 내부플랫폼을 개발을 하고있는 hook.jeong입니다. 제가 AI를 처음 개발자로서 접하게 된건 사내 설명서 서비스에 챗봇을 도입하는 일이었습니다. 이후 AI Native TF에서 사내 지식베이스 에이전트를 개발했고, 사외 교육에서 AI 프로젝트 멘토와 심사위원으로 활동하며 AI 분야에 대한 경험을 쌓아왔습니다. 현재는 AIOps와 관련된 개발을 진행하고 있으며, 일상적인 개발 업무에서도 LLM을 적극 활용하고 있습니다.'나’는 왜 "Vibe"를 해보게 되었나?최근 AI를 활용한 Vibe Coding이 개발자들 사이에서 주목받고 있습니다. 이는 자연스럽게 "AI가 개발자를 대체할 수 있을까?"라는 논쟁으로 이어지고 있습니다. 이러한 논쟁을 지켜보며 한 가지 궁금증이 생겼습니다. "지금의 AI는 과연 '내’가 하는 일을 어디까지 대신할 수 있을까? 개발 업무 중, AI가 실제로 대체 가능한 영역은 어디까지일까?"라는 호기심을 해결하기 위해, AI의 개발자 대체 가능성을 직접 검증해보는 토이 프로젝트를 진행하기로 결정했습니다.'나’는 무엇을 검증하고자 했나?플랫폼 개발자로서 수행하는 주요 업무를 요구사항 분석, 시스템 설계, 데이터 설계, 코딩, 서비스 운영으로 크게 다섯 가지로 분류해보았습니다. 이 중에서 AI의 개발자 대체 가능성을 검증하기 위해 코딩 영역에 초점을 맞추기로 했습니다. 구체적인 검증 항목은 다음 세 가지입니다:• 코드 없이 구어체만으로 웹 프로젝트를 구현할 수 있는가?• 가능하다면 어느 정도의 속도로 개발할 수 있는가?• 정말 개발자의 개입 없이 구현이 가능한가?어떤 기준으로 검증을 해보았나?• 등록된 MCP를 Elasticsearch를 통하여 검색• 완전히 빈 프로젝트에서 시작• 는 Cursor 디렉터리 내 인기 설정 기준으로 선택• 모든 개발은 구어체 입력 후 accept 방식으로 수행• 에러 발생 시 검색 없이 copy & paste로 해결• 오류 없이 기능이 수행되는 것은 완성이라고 정의1. 코드 없이 구어체만으로 구현 가능한가?구현은 가능합니다. 오류 없이 기능이 정상적으로 수행되는 수준을 기준으로 보았을 때, 구어체만으로도 웹 프로젝트를 충분히 구현할 수 있었습니다. 실제로 단 한 줄의 코드도 직접 작성하지 않고, 프로젝트의 핵심 기능을 구현하는 데 성공했습니다.2. 구현 속도는 어느 정도인가?개발 속도 측면에서는 기존 방식과 비교할 수 없을 정도로 빠릅니다. 사내 콘솔, 외부 인증 페이지, 설명서 사이트 등 다양한 웹 프로젝트를 설계하고 개발한 경험이 있는 저의 기준으로도, 일반적인 개발 방식으로는 최소 3일 이상의 개발 기간이 필요할 것으로 예상됩니다. 그러나 이번 실험에서는 단 6시간 만에 4개의 페이지(24개 파일, 1,500줄 이상의 코드)를 구현할 수 있었습니다. 완전히 처음부터 만든 경우라는 점을 고려했을 때, AI 도구를 활용하면 얼마나 빠르게 목표에 도달할 수 있는지 알 수 있었습니다.3. 개발자의 개입 없이 가능한가?현재 수준에서는 개발자의 개입 없이 진행하는 것은

요즘 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은 프롬프트 안에서 프로그램되는 것처럼 동작한다는 점이 강조되었고, 작은 문구 설계 차이가 결과물의 품질을 크게 바꿀 수 있음이 밝혀졌습니다. 이는 곧 정교하게 구성된 프롬프트 한 줄이