Kubernetes 환경에서 효과적인 GitOps를 위해서는 가능한 모든 Kubernetes 리소스를 Manifest 파일로 관리해야 합니다.다만, 여기서 Secret 리소스에 대해서는 고민이 필요합니다.일반적으로 Secret은 Kubernetes 환경에서 비밀번호, API 키, 인증 토큰 등의 민감 정보를 저장하기 위해 사용되는 리소스입니다.base64로 인코딩된 데이터를 포함하며, ConfigMap과 유사한 방식으로 Pod 내에서 환경변수나 파일 형태로 전달될 수 있습니다.그러나 Secret 자체는 기본적으로 암호화되지 않고 etcd에 저장되기 때문에, 특별한 보안 설정이 없으면 민감 정보가 노출될 위험이 있습니다.따라서 Secret을 안전하게 관리하기 위해서는 별도의 보안 조치가 필요하며, 특히 이를 GitOps 환경에서 다루는 것은 주의가 필요합니다.효과적인 GitOps를 위해서는 애플리케이션 및 인프라 구성은 물론, 모든 Kubernetes 리소스 구성을 Code Repo(=Git)에 저장하고 이를 기반으로 모든 리소스를 관리해야 합니다.그러나 Secret은 민감한 데이터를 포함하고 있어 Git 저장소에 직접 저장하는 것이 보안상 매우 위험합니다.manifest 에는 단순히 base64 인코딩한 값이이 저장되기 때문에, 별도 처리없이 Code Repo에서 관리한다면,사실상 Code Repo 에 접근이 가능한 사용자/개발자에게 민감정보가 오픈됩니다.그렇다고, Code Repo 의 접근권한을 통제하거나, Secret을 수동으로 클러스터에 적용하면 GitOps 철학에 맞지도 않고, 효율성이 떨어집니다.따라서 GitOps 를 유지하면서도 민감 정보를 안전하게 다루는 방법이 필요합니다.SealedSecret은 GitOps 환경에서 Kubernetes Secret을 안전하게 관리할 수 있도록 도와주는 오픈소스 입니다.사용자는 kubeseal CLI를 이용해 Secret을 암호화한 SealedSecret을 생성하고, 이를 Code Repo에 저장할 수 있습니다.SealedSecret은 Kubernetes 클러스터에서 SealedSecrets Controller에 의해 자동으로 복호화되어 실제 Secret 리소스로 변환됩니다.이렇게 하면 민감 정보가 암호화된 상태로 Code Repo에 저장되므로 보안이 강화되고, 효율적인 GitOps도 유지할 수 있습니다.기본적으로 Code Repo 에는 암호화된 SealedSecret 이 관리되고, Controller 를 통해서 클러스터 내부에서 복호화합니다.• None 개발자는 Secret 을 SealedSecret Controller 를 통해서 암호화된 SealedSecret.yaml 파일 생성• None 개발자는 Code Repo 에 SealedSecret.yaml 을 Commit아래 2가지 설치가 필요합니다• None kubeseal: 암호화된 SealedSecret 생성하기 위한 CLI 도구. Kuberentes 클러스터에 접근 가능한 환경에 설치아래와 같이 helm 명령어로 설치가 가능합니다.설치시에 key 만료 주기에 대한 설정에 대한 고민은 필요합니다.특히 keyttl 의 경우 키가 만료되기 전에 해당 Key 로 암호화된 모든 SealedSecret 은 갱신이 되어야 하니, 보안과 관리 효율성 측면을 고려해서 적절한 값 선택이 필요하며,이미 생성된 key 에 대한 만료주기 변경은 불가합니다.Kubernetes 클러스터에 접근 가능한 Client 에 아래처럼 설치합니다. (linux 기반)SealedSecret 은 아래와 같이 생성이 가능합니다.Code Repo 에 commit 한다면 민감정보가 노출됩니다.암/복호화 솔루션의 경우, 결국 암/복호화 key 를 안전하게, 잘 관리하는 것이 핵심입니다.따라서 key 를 적절하게 교체해주고, 별도 저장소 key 백업 등을 통해서 분실시 데이터 복구방법 등에 대해서도 사전에 고려하는것이 필요합니다.key 추출 등의 기능도 제공하니, 이를 활용한 구성을 권장드립니다.아직 0.3 버전입니다. 굉장히 복잡한 동작을 하는 오픈소스는 아니지만, 향후 업그레이드시 이슈 가능성 등은 감안해서 도입이 필요합니다.SealedSecret은 Kubernetes 환경에서 민감정보를 안전하게 관리하고 GitOps 에 통합하기 위해 간단하면서도 효과적인 오픈소스입니다.Code Repo 에서는 암호화된 SealedSecret 만을 관리하기 때문에, GitOps 통합과 보안성 둘다 확보할 수 있습니다.설정이 간단하고 운영 부담이 적다는 장점이 있지만, Vault나 ESO처럼 동적 Secret 발급, 외부 스토리지 연동 등의 고급 기능을 지원하지 않는점은 고려해서 도입이 필요합니다.

정보의 바다에서 길을 잃으셨나요?여러분은 끝없이 펼쳐진 정보의 바다에서 길을 잃어본 적이 있나요?학술 연구를 하거나, 시장을 분석하거나, 중요한 의사 결정을 해야 할 때 복잡한 정보들 속에서 우리는 종종 난관에 부딪히곤 합니다.무엇을 찾아야 할지 명확히 알고 있는 '알려진 미지(Known Unknowns)'는 이제 어렵지 않습니다.최신 AI 챗봇이나 검색 엔진을 통해 쉽게 답을 찾을 수 있죠. "GPT-4의 최신 업데이트는 무엇인가요?"와 같은 구체적인 질문에는 정확한 답변을 얻을 수 있습니다.하지만 진짜 어려운 건 우리가 무엇을 모르는지조차 모르는 영역, 바로 '알려지지 않은 미지(Unknown Unknowns)'를 탐색할 때입니다.이는 단순히 정보를 검색하는 것이 아닌, 우리가 미처 생각하지 못했던 새로운 관점과 지식을 발견하는 것을 의미합니다.그렇다면 왜 기존의 시스템들은 이러한 '알려지지 않은 미지' 탐색에 한계를 보였을까요?• None AI 챗봇의 한계: 구체적인 질문에는 강하지만, 사용자가 미처 생각하지 못한 영역을 발견하는 데는 부족합니다.• None 질의응답 시스템의 수동성: 사용자가 모든 질문을 직접 해야 하다 보니, 새로운 관점을 발견하기 어렵습니다.• None• None 사용자의 질문에 수동적으로만 반응합니다.• None 기존 관점만 강화하는 쪽으로 대화를 만들어냅니다.• None 특히 사전 지식이 부족한 사용자는 더 큰 어려움을 겪습니다.이러한 한계를 극복하기 위해 Co-STORM - Collaborative Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking이 탄생했습니다.Co-STORM은 사용자가 '알려지지 않은 미지'를 효과적으로 탐색하고, 새로운 지식의 지평을 넓힐 수 있도록 도와주는 혁신적인 도구입니다.앞서 살펴본 바와 같이, 기존 정보 시스템들은 우리가 무엇을 모르는지조차 인지하지 못하는 '알려지지 않은 미지(Unknown Unknowns)'를 탐색하는 데 한계를 가지고 있었습니다.이러한 문제에 대한 해답을 찾기 위해 Co-STORM은 근본적인 아이디어, 즉 협력적 담론을 통한 학습 - Learning through Collaborative Discourse에 집중했습니다.이 아이디어는 일상생활 속에서 흔히 접할 수 있는 교육 시나리오에서 영감을 받았습니다.아이들이나 학생들이 부모나 교사와의 대화를 듣고 참여하면서 자연스럽게 지식을 습득하고 이해를 깊어지게 하는 방식을 여러 언어 모델(LM) 에이전트 간에서도 이루어질 수 있도록 차용하게 한 것이죠.사용자가 모든 질문을 던져야 하는 기존의 질의 응답 시스템과는 달리, 이런 방식을 택하게 되면서 사용자는 “알려지지 않은 미지”의 정보를 우연히 발견하며 학습을 진행할 수 있게 되었습니다.Co-STORM은 사용자가 능동적으로 참여하거나 대화를 관찰하면서 “알려지지 않은 미지”를 발견하고 복잡한 정보를 탐색하며 학습할 수 있도록, “협력적 담론”이라는 방법론을 활용합니다.실제로 이 방법론은 아래와 같은 플로우로 구현되어 있으며 → 플로우의 끝에서 다양한 관점이 녹아있는 훌륭한 리서치 보고서를 얻을 수 있다는 것을 확인할 수 있습니다.이 플로우 전체 과정 중에 가장 중요한 5가지 주요 과정은 다음과 같습니다.Co-STORM은 다음과 같은 4가지 주요 역할을 수행할 수 있는 에이전트를 마련하고 있습니다.A. CoStormExpert (전문가 에이전트)• None 특정 관점에서 정보를 제공하고 분석• None 대화에 전문적 깊이 추가• None 대화가 정체되거나 반복될 때 새로운 질문 생성• None 사용되지 않은 정보를 기반으로 새로운 관점 주입• None 대화의 균형과 다양성 유지• None 실제 사용자의 의도에 따른 질문 생성• None 다른 전문가들이 특화된 관점을 제시할 수 있도록 기반 마련플로우 전체에서 활약하는 전문가 에이전트는 아래와 같이 1) 일반적인 전문가와 2) 특정 초점에 맞는 전문가를 생성할 수 있도록 구분되어 있으며,각 전문가 에이전트는 주제에 대한 배경 정보를 갖추는 것과 더불어 다양성, 대립성, 관련성, 균형을 유지할 수 있도록 생성된다는 것을 확인할 수 있습니다.• None 다양성: 서로 다른 관점, 역할, 소속을 가진 전문가들• None 대립성: 반대 입장을 가진 전문가들 포함• None 관련성: 주제와 직접적으로 연결된 전문가들3) 사용자 참여 과정 (사용자 개입 여부 판단)다양한 전문가 에이전트 간의 협력적 담론이 이어지다보면, 실제 인간의 대화처럼 질문과 답변이 균형있게 이루어지지 않는 케이스가 종종 발생할 수 있습니다.이러한 문제에서 벗어나기 위해 사용자가 대화의 중간에 참여할 수 있는 조건을 마련해두고, 이를 활용할 수 있도록 기능이 마련되어 있습니다.• None 대화가 정체되거나 반복될 때 새로운 질문으로 방향 전환Co-STORM에서는 대화 턴을 아래와 같은 우선순위를 통해 관리하고 있습니다.• None• None (참고) simulate_user=True, 이 옵션은 연구목적으로 사용되고 있습니다.• None• None 답변이 3회 (기본값) 이상 이어질 때 → 새로운 관점을 가지고 있는 질문을 해줄 수 있는 사회자를 개입시킵니다.• None 참고로 질문이 있을 경우, 사용자가 개입할 수 있습니다.• None• None 마지막 대화가 질문이 아닐 경우, 계속 답변할 수 있는 전문가를 순차적으로 투입하고 있습니다.• None 투입된 전문가들은 답변을 이어서 진행하게 됩니다.5) 전문가 동적 업데이트 과정대화 턴 배정 시 마지막 대화가 다시 질문이 되면, 해당 질문에 적절한 답변을 내놓을 수 있는 전문가들을 아래와 같이 다시 설정하게 됩니다.*실제로 focus, background_info가 다시 요청된 질문에 따라서 갱신되게 되며, 갱신된 정보를 토대로 새로운 전문가들이 생성되고 설정되게 됩니다.• None 더 적합한 전문가들이 필요할 때Co-STORM의 성능 평가 결과Co-STORM의 성능 평가는 자동 평가와 인적 평가의 두 가지 방식으로 이루어졌습니다.• N

LY Corporation에서 오는 6월 30일과 7월 1일 양일간 테크 컨퍼런스 Tech-Verse 2025를 개최합니다.Tech-Verse는 전세계 LY Corporation 그룹사 소속 엔지니어와 디자이너, 프로덕트 매니저의 발표 세션으로 구성되며, 공식 사이트의 온라인 참가 등록에서 누구나 무료로 사전 등록 후 온라인으로 참여할 수 있습니다.• 공식 사이트에서 누구나 무료 참여 등록 가능이번 Tech-Verse 2025에서는 메인 테마인 AI와 보안을 비롯해 12개 분야의 기술 이야기를 만나볼 수 있습니다. 총 127개 세션이 준비돼 있으며, 세션은 한국어, 영어, 일본어의 3개 언어로 실시간 통역이 제공됩니다.보다 자세한 정보는 아래 일정별 트랙과 타임테이블을 확인해 주세요.다음은 각 분야별 추천 세션입니다.• AI | AI와 함께 진화하는 개발 프로세스• Infrastructure | Central Dogma Control Plane으로 LY Corporation의 수천 개 서비스를 연결하기• Data Platform | AI로 데이터 분석가 일자리 뺏기 - 생성형 AI를 이용한 데이터 파이프라인 구축 및 데이터 분석 자동화• App | Demae-can의 대변혁: React Native에서 Flutter로의 과감한 이행 전략• Product Management | 데이터와 현장 조사로 밝혀낸 "LINE Talk" 사용자 인사이트추천 세션 외에도 흥미로운 세션이 가득하니 Tech-Verse 2025에서 LY Corporation 그룹사의 기술 비전과 도전 사례를 꼭 만나 보세요!

슈퍼브에이아이의 혁신적인 비전 파운데이션 모델 '제로'의 기술 노하우를 담은 백서. 0.9M 데이터로 SOTA 성능을 달성한 제로의 개발 배경, 핵심 기술, 모델 구조를 공개합니다. 시간과 비용 절감 효과를 백서에서 바로 확인하세요.복잡한 비전 AI 모델 개발, 이제 끝! '제로'로 즉시 프로덕션에 적용하세요.AI는 다양한 산업 분야에 혁신을 가져오고 있습니다. 특히 컴퓨터 비전 분야에서는 객체 감지(Object Detection), 이미지 캡셔닝(Image Captioning) 등 복잡한 시각 정보를 이해하고 처리하는 기술의 중요성이 더욱 커지고 있는데요. 비전 AI 모델을 개발하고 실제 산업 현장에 적용하는 과정은 여전히 많은 시간과 비용, 그리고 전문성을 요구하는 어려운 과제입니다.슈퍼브 AI는 이러한 어려움을 해결하고, 기업들이 AI를 통해 비즈니스 가치를 신속하게 창출할 수 있도록 돕기 위해 국내 최초 산업 특화 비전 파운데이션 모델 '제로(ZERO)'를 개발했습니다. '제로'는 기존의 복잡한 모델 개발 패러다임을 혁신적으로 변화시키며, 효율적이고 유연한 AI 도입을 가능하게 합니다.'제로(ZERO)'가 제시하는 비전 AI 개발의 혁신적인 변화슈퍼브에이아이의 '제로'는 0.9M의 데이터셋만으로 Visual-G AP 35.2의 우수한 성능을 달성하며, 대규모 데이터셋(20M~100M)을 사용하는 SOTA 모델과 비교해 압도적인 데이터 효율성을 입증했습니다. 이는 곧 시간과 비용을 획기적으로 절감하면서도 최고 수준의 AI 성능을 구현할 수 있음을 의미합니다.기술 백서에서 다루는 주요 내용데이터 중심 AI 철학을 담아 개발한 '제로'의 기술 노하우를 담은 기술 백서를 공개합니다.• 비전 파운데이션 모델(VFM)의 정의 및 특징: 파운데이션 모델의 정의와 그 중요성, 그리고 비전 파운데이션 모델의 특징에 대해 상세히 설명합니다.• 관련 연구 동향: 최근 객체 감지 기술의 발전 동향과 오픈셋 감지 모델의 필요성, 그리고 CLIP, GLIP, Grounding DINO등 주요 연구들을 소개합니다.• VFM '제로' 소개: '제로'의 개발 배경, 핵심 기술, 그리고 '제로' 모델 구조에 대해 자세히 설명합니다.• 성능 비교 및 기술 사양: '제로'의 모델 성능 및 기술 사양을 상세히 공개하고, 다른 선행 연구 모델들과의 비교를 통해 '제로'의 우수성을 객관적인 지표로 제시합니다.• 향후 계획: 포인트/스케치 기반 프롬프팅 확장 계획과 데이터 중심 접근법을 통한 자동화 파이프라인 구축 등 '제로'의 지속적인 성능 향상을 위한 슈퍼브에이아이의 비전을 제시합니다.'제로(ZERO)' 기술 백서 다운로드지금 바로 슈퍼브 기술 백서를 다운로드하여 '제로'가 어떻게 귀사의 AI 도입을 가속화하고 비즈니스 성장을 견인할 수 있는지 확인해보세요.아래 양식을 작성하시면 백서를 바로 보실 수 있습니다.

ellie.sys 사용자에게 친숙한 서비스를 제공하기 위한 고민과 열정을 가득 느낄 수 있었습니다. 보험과 비슷한 환경으로 고민이 있는 서비스가 있다면 유용한 인사이트를 얻어 가실 수 있을 거예요!안녕하세요, 저희는 금.용.사(금융용어사전) 서비스를 만든 아 팀이름 안정했따 팀입니다. 카카오페이에서는 최근 AWS와 함께 AI를 활용하는 해커톤, 카페톤을 진행했는데요. 저희는 어려운 금융용어를 사용자가 이해하기 쉽게 설명해 준다는 콘셉트를 가지고 서비스를 만들었습니다. 팀원 구성이 보험(인슈어런스클랜) 크루들이다 보니, 저희가 처음 보험이라는 도메인을 접했을 때 느꼈던 용어의 어려움이 사용자들에게도 분명 해석이 필요할 것이라고 생각했습니다.아이디어 선정 과정저희는 아래 내용을 중심으로 아이디어를 선정했습니다.• 저희가 잘 아는 보험 도메인• 사용자가 저희 서비스를 이용하는데 도움이 되는 아이디어저희 팀 모두 인슈어런스 클랜의 크루들이다 보니, 아무래도 보험이라는 도메인에 대해 많이 익숙합니다. 그만큼 사용자들이 어떤 어려움을 겪고 있는지, 또는 어떤 부분이 허들이 되는지 기존에도 많이 고민하고 있었는데요. AI, 그리고 카페톤이라는 평소와는 다른 제약조건 하에 저희가 기존에 해결하고 싶었던 문제들을 어떻게 풀 수 있는지 고려하여 아이디어를 선정했습니다.또, 사용자의 실제 어려움을 해소해 줄 수 있는 아이디어를 원했습니다. 저희는 복잡한 금융을 쉽게 풀어 제공하는 서비스를 만들고 있습니다. AI를 활용한 서비스가 무궁무진하게 쏟아져 나오고 있는 상황에서, 저희는 AI 역시 기존과 같은 목적으로 사용하고자 하였고, 이에 따라 사용자가 경험할 수 있는 서비스 내 허들을 AI를 이용해 해소하고 싶었습니다.마지막으로, 실현 가능성을 고려하여 아이디어를 선정했습니다. 카페톤은 사전에 자료 및 기술 조사가 허용되었고, 실제 구현은 당일에 이루어져야 했습니다. 네 명의 팀원들 모두 AWS의 AI 서비스들을 처음 접하는 상황이었고, 실제로 구현 가능한 시간은 한정되어 있었기 때문에, 이를 감안하여 아이디어를 선정했습니다.이를 바탕으로 저희가 선정한 아이디어는 ‘금융 용어 사전’, 줄여서 ‘금.용.사.‘입니다. 금융 서비스를 이용할 때, 어려운 용어 때문에 이해하지 못하고 넘어가는 사용자들이 많은 점에 착안하여, 이러한 허들을 AI를 활용하여 해소하고자 하였습니다.뿐만 아니라 용어와 관련된 금융 상품 조회 등, 사용자가 필요할 수 있는 정보를 AI가 선정하여 함께 제공하도록 하였습니다. 저희가 보험 도메인에 익숙한 만큼 실제 구현은 보험을 중심으로 진행했지만, 대출, 카드, 투자 등 다른 금융 도메인에도 접목시킬 수 있는 아이디어입니다.고생 끝에 완성한 결과물입니다. 우선 영상부터 보시죠!사용자가 카카오톡 알림톡 등을 통해 진입하는 과정을 가정했습니다.우선 화면에서 사용자가 클릭을 하면 용어를 해석해 준다는 것을 인지시키기 위해, 토글 버튼을 활용했습니다. 토글을 클릭하면 화면에 있는 용어들 중 사용자가 어려워할 만한 용어들을 AI가 인식해서 설명이 가능한

안녕하세요, 토스페이먼츠 김용성, 하태호입니다.지난주, 토스페이먼츠에서 PG업계 최초로 MCP를 소개하면서 많은 분들이 관심가져 주셨는데요. 이 글을 통해 MCP 서버 구현 과정과 그 안에서 얻은 러닝을 공유하고자 해요.* 길드(guild): 서로 다른 팀이나 사일로에 속한 팀원들이 느슨하게 모여 공통의 관심사를 공유하는 조직먼저 이해를 돕기 위해 짧은 시연 영상을 준비했어요. 외부 개발자분들이 토스페이먼츠 MCP를 활용해서 주문서 페이지를 만드는 상황에 대한 예시입니다. 로딩이나 일부 수정 과정은 생략했고, Claude 4 모델을 사용했습니다.토스페이먼츠는 출범 초기부터 어떻게 하면 고객사가 결제 시스템을 더 쉽게 연동할 수 있을지에 대한 고민이 많았습니다. 기존의 결제 시스템 연동 방식은 개발자에게 복잡하고 번거로운 작업이라는 인식을 풀어야 했기 때문이죠.이 문제를 해결하기 위해 직관적인 API와 SDK를 새로 만들고, 토스페이먼츠 결제 시스템을 연동하는 개발자들을 위한 개발자 센터를 만드는 등 다양한 활동을 수행하였고, 개발자분들로부터 좋은 피드백을 받았습니다.그렇지만 여전히 결제 시스템 연동의 어려움을 겪는 분들이 많이 계신데요, 개발팀이 따로 없는 작은 가맹점이나 외부에 개발을 맡긴 사업자분들이 특히 어려움을 겪고 있었습니다. AI 기반 코딩 도구를 활용하면 토스페이먼츠 연동을 더 쉽게 할 수 있지 않을까?하는 생각을 바탕으로 토스페이먼츠 연동 코드를 작성해 보았지만, 생성된 코드의 정확도가 많이 떨어지는 문제가 있었어요.이 문제를 해결하기 위한 고민을 하던 중, AI 모델이 이해할 수 있는 맥락 정보를 제공할 수 있는 방법인 MCP(Model-Context Protocol)라는 개념이 등장해서 이를 활용해보기로 했습니다.MCP는 엔트로픽에서 제안한, 인공지능 모델(LLM)이 다양한 상황과 맥락을 잘 이해할 수 있도록 돕는 표준적인 방법입니다. USB가 컴퓨터와 주변기기들을 간편하게 연결할 수 있는 표준을 만들었던 것처럼, MCP는 AI 모델과 다양한 환경이 자연스럽게 연결될 수 있도록 돕습니다. MCP 덕분에 하나의 서버에서 다양한 AI 툴(예: Cursor, Claude, Windsurf 등)을 편하게 사용할 수 있게 되는 것이죠. 저희는 MCP를 활용해, 개발자들이 더 쉽고 즐겁게 작업할 수 있는 '바이브 코딩' 환경을 만들려고 하고 있어요.MCP에서 가장 중요한 건, AI가 잘 이해할 수 있는 콘텐츠를 전달하는 것입니다. 하지만 모든 제품에 대해 콘텐츠를 개별적으로 제작하는 건 시간과 비용이 너무 많이 들죠. 다행히 저희는 이미 MDX 기반의 개발자 센터를 운영하고 있었고, CI/CD 과정에 CDN에 배포되는 구조라서 MCP 서버가 해당 콘텐츠에 접근한다면 문서의 버전업을 그대로 따라가는 구조를 충족할거라 생각했습니다. 이를 기반으로 LLM이 잘 이해할 수 있도록 파일을 만들어 프로토타입을 빠르게 구축할 수 있었어요. 특히 이 과정에서 프론트엔드 챕터의 신지호님께서 큰 도움을 주셨습니다.llms.txt는 대규모 언어 모델

안녕하세요! 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 에러 메시지