orchestration

9 개의 포스트

github3분 읽기큐레이션 요약

GitHub Copilot CLI가 작업 위임을 더 선별적으로 하도록 만든 방법

GitHub는 Copilot CLI가 단순한 작업까지 불필요하게 서브에이전트에 위임해 발생하던 검색 반복, 도구 실패, 대기 시간을 줄이기 위해 위임 정책을 개선했다. 핵심은 좁고 명확한 작업은 메인 에이전트가 직접 처리하고, 독립적인 탐색·복잡한 조사·병렬 실행이 필요한 경우에만 서브에이전트를 활용하는 것이다. 그 결과 도구 실패가 23% 감소하고 P95 사용자 대기 시간이 5% 줄었으며, 품질 저하 없이 Copilot CLI 전체 트래픽에 적용됐다. ### 서브에이전트 위임은 항상 효율적이지 않다 - 서브에이전트는 복잡한 작업을 분해하고 여러 조사를 병렬로 수행하는 데 유용하다. - 하지만 단순한 파일 수정까지 위임하면 오히려 다음과 같은 비용이 발생한다. - 불필요한 에이전트 간 인계와 조정 - 동일하거나 겹치는 저장소 검색 - 메인 에이전트가 결과를 기다리는 시간 - 오래된 파일 경로, 잘못된 상대 경로, 워크스페이스 불일치에 따른 도구 실패 - 특히 메인 에이전트가 이미 충분한 맥락을 알고 있는데도 탐색 서브에이전트를 실행하면, 서브에이전트가 저장소를 다시 검색하면서 작업이 지연된다. ### 데이터 분석으로 불필요한 위임 패턴 식별 - GitHub는 에이전트의 전체 실행 궤적을 LLM으로 분석해 위임이 실제로 도움이 되는지 확인했다. - 분석 결과, 다음과 같은 작업에 서브에이전트가 과도하게 사용되고 있었다. - 범위가 좁고 명확한 작업 - 필요한 정보가 이미 핸드오프에 포함된 작업 - 파일을 찾고 읽은 뒤 한 곳을 수정하는 작업 - 이를 바탕으로 “간단한 탐색과 수정은 메인 에이전트가 직접 처리한다”는 방향을 개선 목표로 삼았다. ### 좁은 작업은 직접 처리하고 복잡할 때만 위임 - Copilot CLI의 새로운 정책은 가장 간단한 실행 경로에서 시작한다. - 파일 찾기 - 파일 읽기 - 특정 부분 수정 - 변경 사항 검증 - 다음과 같은 경우에는 서브에이전트 위임이 효과적이다. - 익숙하지 않은 대규모 저장소 탐색 - 서로 독립적인 코드 영역 조사 - 장시간 실행되는 명령 수행 - 여러 작업을 동시에 진행할 수 있는 경우 - 작업이 복잡하거나 불확실할 때 위임하고, 다시 작업 범위가 좁아지면 메인 에이전트가 직접 처리하도록 한다. - 서브에이전트는 메인 에이전트를 멈추게 하는 “일시정지 버튼”이 아니라, 독립 작업을 병렬화하는 도구로 사용해야 한다. ### 구체적인 핸드오프와 병렬 실행 - 서브에이전트를 실행할 때는 핸드오프에 다음 내용을 명확히 포함해야 한다. - 사용자가 요청한 전체 목표 - 메인 에이전트가 이미 파악한 정보 - 서브에이전트가 담당할 범위 - 반환해야 하는 결과의 형태 - 메인 에이전트는 서브에이전트의 결과를 기다리기만 하지 않고, 그동안 독립적으로 수행할 수 있는 작업을 계속 진행해야 한다. - 이 방식은 중복 검색과 순차적 대기를 줄이고, 실제로 병렬 처리가 가능한 작업에서 위임의 이점을 높인다. ### 오프라인 평가와 운영 환경 A/B 테스트 - GitHub는 자동 생성 회귀 테스트와 기존 벤치마크를 이용해 정책 변경을 먼저 오프라인에서 검증했다. - 이후 내부 사용자와 공개 사용자를 대상으로 A/B 테스트를 진행했다. - 평가 항목은 다음과 같았다. - 도구 안정성 - 사용자 응답성과 대기 시간 - 서브에이전트 사용량 - 최종 결과 품질 - 성능 향상은 개별 LLM 호출 자체를 빠르게 만든 결과가 아니라, 불필요한 서브에이전트 실행을 줄여 오케스트레이션 비용을 낮춘 결과였다. ### 측정된 개선 효과 - 세션당 도구 실패가 **23% 감소** - 검색 도구 실패: **27% 감소** - 편집 도구 실패: **18% 감소** - 사용자 대기 시간 개선 - P95: **5% 감소** - P75: **3% 감소** - 품질 저하는 관찰되지 않았다. - 개선된 위임 기능은 Copilot CLI 운영 트래픽의 100%에 배포됐다. - 사용자는 `/update` 명령으로 Copilot CLI **1.0.42 이상**으로 업데이트하면 적용된 기능을 사용할 수 있다. 간단한 작업에는 직접 실행을 우선하고, 서브에이전트는 독립성·복잡성·병렬성 때문에 실제 이득이 있을 때만 사용하는 것이 효율적이다. 이를 위해 위임 여부뿐 아니라 핸드오프의 구체성, 메인 에이전트의 병렬 진행 여부까지 함께 설계해야 한다.

원문 읽기(새 탭에서 열림)
kakao3분 읽기큐레이션 요약

카나나 스칼라 1회 세미나 현장 스케치

카카오의 ‘카나나 스칼라’ 1회 세미나는 카나나 파운데이션 모델의 기술 성과와 향후 AI 전략을 학계와 공유한 자리였다. 카카오는 적은 학습 토큰으로 높은 성능을 달성한 효율성과 한국어·다중모달 처리 능력을 강조했으며, 기술 주권과 서비스 최적화를 위해 자체 모델 개발을 지속하겠다는 방향을 밝혔다. 또한 초개인화 에이전트, 디지털 월드모델, 실전형 실행 능력, 산학 협력을 중심으로 AI 생태계를 확장할 계획을 제시했다. ## 카나나 파운데이션 모델의 성과 - 카카오는 외부 모델을 활용하는 대신, 처음부터 직접 개발하는 ‘카나나’ 파운데이션 모델 라인업을 구축하고 있다. - 유사한 규모의 글로벌 모델이 23조 개의 학습 토큰을 사용한 데 비해, 카나나는 약 11조 개의 토큰만으로도 뛰어난 성능을 달성했다고 설명했다. - 이는 학습 데이터의 정제 수준과 품질이 모델 효율성에 크게 기여했다는 의미로 소개됐다. - 텍스트와 이미지뿐 아니라 오디오까지 실시간 처리하는 옴니 모델 **Kanana-o**도 시연했다. - Kanana-o는 감정을 담은 음성 표현과 다화자 대화 처리를 선보였으며, 현장에서는 한국어 구사 능력이 뛰어나다는 평가를 받았다. ## 자체 모델 개발과 기술 주권 - 외부 AI 모델에 의존할 경우 라이선스 정책 변경이나 기술 공개 제한 등 외부 변수에 영향을 받을 수 있다. - 카카오는 독자 모델을 통해 서비스 환경에 맞는 고효율·맞춤형 AI를 운영하고, 실질적인 비즈니스 성과를 창출하려 한다. - 교수진은 한국의 문화적 맥락과 사회적 이슈를 독자적으로 통제하려면 자체 모델이 필요하다고 평가했다. - 독자적인 모델 역량은 서비스 안정성과 기술 주권을 확보하는 전략적 자산으로 논의됐다. ## 디지털 월드모델과 초개인화 에이전트 - 카카오는 카카오톡 플랫폼에서 발생하는 사용자의 행동과 대화 맥락을 이해하는 ‘상황 이해 지능’에 주목하고 있다. - 온디바이스 기술을 활용하면 대화 내용이 외부로 유출되지 않도록 보호하면서도 사용자의 요청을 즉시 처리할 수 있다. - 이를 바탕으로 사용자의 일상과 맥락에 맞춰 행동하는 초개인화 에이전트를 구현하려 한다. - 교수진은 디지털 월드모델을 로봇이나 물리적 환경에만 한정하지 말고, 플랫폼 내 상호작용과 인과관계를 예측하는 모델로 확장하자고 제안했다. - 카카오톡의 방대한 서비스·사용자 상호작용은 카카오만의 차별화된 디지털 월드모델을 구축할 기반으로 평가됐다. ## 생성 능력보다 중요한 실전형 실행력 - 카카오는 단순히 문장을 생성하는 능력보다, AI가 작업을 계획하고 필요한 기능을 호출해 최종 과업을 완료하는 능력을 중시한다. - 자체 ‘오케스트레이션 벤치마크’를 개발해 복합적인 실제 문제 해결 능력을 평가할 계획이다. - 이는 여러 단계의 추론과 도구 사용이 필요한 서비스 환경에서 AI의 실질적인 유용성을 검증하기 위한 접근이다. - 교수진은 사용자가 느끼는 지능은 벤치마크 점수보다 복잡한 요구를 끝까지 해결하는 능력에서 드러난다고 강조했다. - 글로벌 모델과 단순 생성 품질 경쟁을 하기보다, 카카오 서비스 안에서의 실행력에 집중하는 전략이 효과적일 수 있다는 의견이 제시됐다. ## 학계와 산업계의 AI 인재 협력 - 카카오는 세미나를 계기로 대학 연구실과 학부 AI 동아리에 GPU 자원을 지원하는 방안을 검토하고 있다. - 지원 방식으로는 GPU 크레딧 제공이나 공동 과제 형태 등이 논의됐다. - 이러한 협력은 연구자와 학생들이 실제 AI 모델 개발과 실험을 수행할 수 있도록 돕고, 국내 AI 인재 생태계를 강화하는 데 목적이 있다. - 카나나 스칼라는 기술 논의뿐 아니라 지속적인 산학 협력의 출발점으로 추진될 예정이다. 카카오는 카나나를 단순한 대규모 언어 모델이 아니라, 한국어와 국내 서비스 맥락을 이해하고 실제 작업까지 수행하는 플랫폼형 AI로 발전시키려 한다. 향후에는 모델 성능 자체보다 개인정보 보호, 카카오 서비스와의 결합도, 복합 과업 실행력, 그리고 산학 협력을 통한 생태계 확장이 중요한 경쟁력이 될 것으로 보인다.

원문 읽기(새 탭에서 열림)
line원문

AI 활용 능력을 높이기 위한 사내 워크숍, 'Orchestration Development Workshop' 기사 목록 (새 탭에서 열림)

LY Corporation은 엔지니어들의 실무 AI 활용 능력을 고도화하기 위해 'Orchestration Development Workshop'을 운영하며 기술 역량 강화에 집중하고 있습니다. 이 워크숍은 단순한 AI 사용을 넘어 여러 AI를 유기적으로 연계해 창의력을 극대화하는 '오케스트레이션' 기반의 개발 문화를 지향합니다. 조직적 학습을 통해 개별 엔지니어의 역량을 넘어 팀 전체의 생산성을 높이고 실질적인 개발 병목 현상을 해결하는 것을 최종 목표로 합니다. **오케스트레이션 개발 워크숍의 철학** * 단일 AI 도구 활용에서 벗어나, 여러 AI 모델과 서비스를 연계하여 복잡한 문제를 해결하는 '오케스트레이션' 능력을 배양합니다. * 공동 창작의 장을 마련하여 엔지니어들이 서로의 노하우를 공유하고 새로운 AI 활용 방식을 함께 탐색합니다. * 이론적인 학습에 그치지 않고 실제 업무 현장에서 직면하는 기술적 과제들을 해결하는 데 초점을 맞춥니다. **AI를 활용한 코드 리뷰 문화의 혁신** * 워크숍의 첫 번째 성과로 Pull Request(PR) 과정에서 발생하는 리뷰 정체 현상을 AI 지원을 통해 해소한 사례를 다룹니다. * AI 리뷰 어시스턴트를 도입하여 코드 검토의 속도를 높이고, 단순 반복적인 리뷰 업무를 자동화함으로써 리뷰어의 부담을 줄입니다. * 기술적 도구 도입뿐만 아니라 사내 워크숍을 병행하여 리뷰 문화 자체를 생산적인 방향으로 변화시키는 경험을 제공합니다. AI 시대의 개발 경쟁력은 단순히 최신 모델을 사용하는 것이 아니라, 이를 조직의 워크플로우에 얼마나 유기적으로 통합(Orchestration)하느냐에 달려 있습니다. 사내 PR 리뷰 정체와 같은 구체적인 문제부터 AI로 접근해 보며 조직 전반의 학습 문화를 구축해 나가는 것을 추천합니다.

line원문

AI 활용의 열쇠는 '조직적 학습'에 있다 - Orchestration Development Workshop의 시작 (새 탭에서 열림)

LY Corporation은 AI 도입 초기 단계를 넘어, 여러 AI를 유기적으로 연계하여 엔지니어의 창의성을 극대화하는 ‘오케스트레이션 개발 워크숍(Orchestration Development Workshop)’을 본격적으로 시작했습니다. 이 워크숍은 단순한 도구 활용을 넘어 AI와 협업하는 조직으로 진화하기 위한 실무 중심의 배움터로, 반복적인 업무를 자동화함으로써 엔지니어가 보다 가치 있는 설계와 창의적 활동에 집중할 수 있는 환경을 구축하는 것을 최종 목표로 합니다. **여러 AI를 연계하는 ‘오케스트레이션’ 개발 방식** * AI 오케스트레이션은 단일 도구 사용을 넘어, 여러 AI를 조합해 복잡한 개발 프로세스를 일괄 수행하는 '협주형' 개발 방식을 의미합니다. * 주요 사례로 Jira 티켓 기반 코드 자동 생성, 테스트 및 리뷰 수행, Pull Request(PR) 작성까지 AI가 연속적으로 처리하는 워크플로우를 제안합니다. * Slack을 통해 접수된 장애 보고를 바탕으로 AI가 원인을 추정하고 즉각적인 수정안을 제시하는 등 실전적인 대응 모델을 포함합니다. **지속적인 지식 확산을 위한 3단계 조직 구조** * 특정 개인의 열정에만 의존하지 않고 조직 전체가 성장할 수 있도록 ‘추진(DevRel)’, ‘현장 인사이트(길드)’, ‘품질 보증(TD)’의 체계적인 협력 구조를 구축했습니다. * DevRel 조직은 프로젝트의 운영과 전사적 확산을 담당하며 지식 전파의 엔진 역할을 수행합니다. * 현장 엔지니어로 구성된 길드가 실무 지식을 제공하고, TD(Technical Director)가 콘텐츠의 품질과 재현성을 검증하여 교육의 신뢰도를 높입니다. **실무 재현성을 극대화한 양방향 학습 설계** * ‘보기만 하다 끝나지 않는다’는 슬로건 아래, 참가자가 발표자의 화면을 보며 실시간으로 따라 하는 핸즈온(Hands-on) 실습 환경을 제공합니다. * Zoom을 통한 실시간 대화와 Slack을 활용한 질문 수집을 병행하여, 학습 과정에서 발생하는 과제를 그 자리에서 즉시 해결하는 양방향 소통을 지향합니다. * 단순한 지식 전달을 넘어 각 엔지니어가 자신의 실제 프로젝트에서 AI 오케스트레이션을 재현할 수 있는 실질적인 기술 습득에 초점을 맞춥니다. **엔지니어의 창의성 해방과 미래 전망** * AI 활용의 본질은 단순한 작업 속도 향상이 아니라, 엔지니어를 반복 작업에서 해방시켜 고부가가치 설계 영역에 집중하게 만드는 것입니다. * 생성형 AI뿐만 아니라 비생성형 AI까지 아우르는 폭넓은 주제를 다루며, 사내에서 축적된 AI 주도 개발 노하우를 기술 블로그 등 외부 채널을 통해 적극적으로 환원할 예정입니다. AI가 코드를 작성하고 인간이 리뷰하는 단계를 넘어, 설계 단계부터 AI와 긴밀히 협업하는 시대가 오고 있습니다. 이제 엔지니어는 개별 코딩 기술에 매몰되기보다 여러 AI를 조율하고 제어하는 '오케스트레이터'로서의 역량을 갖추는 것이 필수적입니다. LY Corporation의 사례처럼 실무 중심의 핸즈온 학습을 통해 AI와 함께 만드는 조직 문화를 선제적으로 경험해 보길 추천합니다.

github3분 읽기큐레이션 요약

‘텍스트로서의 AI’ 시대는 끝났다. 실행이 새로운 인터페이스다.

이 글은 AI가 단순히 텍스트를 주고받는 도구를 넘어, 계획을 세우고 도구를 호출하며 실제 작업을 수행하는 실행 계층으로 발전하고 있다고 주장합니다. GitHub Copilot SDK를 사용하면 애플리케이션에 Copilot CLI의 검증된 계획·실행 엔진을 직접 내장할 수 있습니다. 이를 통해 개발자는 고정된 자동화 스크립트나 자체 오케스트레이션 계층을 만들지 않고도, 제약 조건 안에서 적응적으로 동작하는 에이전트형 시스템을 구축할 수 있습니다. ## 텍스트 기반 AI에서 실행 기반 AI로 - 기존 AI 사용 방식은 텍스트를 입력하고 텍스트를 받은 뒤, 사용자가 다음 행동을 직접 결정하는 구조였습니다. - 실제 운영 소프트웨어는 다음과 같은 실행 루프를 필요로 합니다. - 작업 계획 수립 - 도구 호출 - 파일 및 시스템 변경 - 명령 실행 - 오류 복구 - 실행 중 상황 변화에 따른 대응 - 따라서 AI의 핵심 인터페이스가 텍스트가 아니라, 제약 조건과 관찰 가능성을 갖춘 실행으로 바뀌고 있습니다. ## 여러 단계 작업을 에이전트에 위임 - 기존 스크립트는 작업 단계가 고정되어 있을 때는 유용하지만, 상황에 따라 흐름이 바뀌거나 오류 복구가 필요하면 취약해집니다. - Copilot SDK를 사용하면 애플리케이션이 구체적인 절차 대신 작업의 의도와 제약 조건을 전달할 수 있습니다. - 예를 들어 “이 저장소를 릴리스 준비 상태로 만들어라”라고 요청하면 에이전트가 다음을 수행할 수 있습니다. - 저장소 구조 탐색 - 필요한 작업 계획 수립 - 파일 수정 - 명령 실행 - 실패 발생 시 대안 적용 및 복구 - 고정된 예외 처리를 직접 작성하지 않고도, 규모가 커지는 업무 흐름에 적응하는 자동화를 구현할 수 있다는 점이 핵심입니다. ## 구조화된 런타임 컨텍스트 활용 - 시스템 로직을 프롬프트에 계속 추가하면 프롬프트가 복잡하고 취약해지며, 테스트와 유지보수가 어려워집니다. - Copilot SDK는 컨텍스트를 텍스트가 아닌 구조화되고 조합 가능한 도구와 데이터로 제공합니다. - 애플리케이션은 다음과 같은 방식으로 실행 환경을 확장할 수 있습니다. - 도메인 전용 도구 및 에이전트 스킬 정의 - Model Context Protocol(MCP)을 통한 도구 연결 - 실행 시점에 필요한 컨텍스트 검색 - 예를 들어 에이전트가 직접 다음 정보를 조회할 수 있습니다. - 서비스 소유 팀 - 과거 의사결정 기록 - 의존성 그래프 - 내부 API 스키마 - 권한과 안전 제약 조건 - MCP는 에이전트가 실제 시스템과 권한이 부여된 데이터에 근거해 행동하도록 연결하는 기반 역할을 합니다. ## IDE 밖에 실행 기능 내장 - AI 기능은 더 이상 IDE나 터미널 안에서만 제공될 필요가 없습니다. - Copilot SDK를 활용하면 다음과 같은 애플리케이션에 에이전트 실행을 통합할 수 있습니다. - 데스크톱 애플리케이션 - 사내 운영 도구 - 백그라운드 서비스 - SaaS 플랫폼 - 이벤트 기반 시스템 - 파일 변경, 배포 이벤트, 사용자 동작 등을 감지한 뒤 애플리케이션에서 Copilot을 프로그래밍 방식으로 호출할 수 있습니다. - 결과적으로 AI는 별도의 보조 창이 아니라 제품 내부에서 실행되는 인프라가 됩니다. ## 애플리케이션 아키텍처의 변화 - Copilot SDK는 Copilot CLI를 구동하는 계획·실행 엔진을 애플리케이션의 프로그래밍 가능한 계층으로 제공합니다. - 개발자는 매번 오케스트레이션 로직을 새로 구축하기보다, 애플리케이션이 달성해야 할 목표와 실행 가능한 범위를 정의하는 데 집중할 수 있습니다. - 다만 실제 운영 환경에서는 도구 권한, 안전 제약, 실행 결과 관찰, 오류 처리 등을 명확히 설계해야 합니다. Copilot SDK는 AI를 “답변을 생성하는 기능”에서 “실제 업무를 수행하는 시스템 구성 요소”로 확장하려는 접근입니다. 반복 작업이나 복잡한 운영 흐름에 적용할 때는 의도 중심의 에이전트 실행, MCP 기반의 구조화된 컨텍스트, 명확한 권한·안전 제약을 함께 설계하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
spotify원문

더 스마트한 광고를 위한 우리의 (새 탭에서 열림)

Spotify는 광고 비즈니스의 다양한 구매 채널 간에 발생하는 의사결정 로직의 파편화 문제를 해결하기 위해 멀티 에이전트 아키텍처를 도입했습니다. 기존의 하드코딩된 워크플로우 대신, 광고주의 의도를 이해하고 공유된 신호를 바탕으로 추론하는 '프로그래밍 가능한 의사결정 계층'을 구축하여 모든 채널에서 일관된 최적화를 달성하고자 합니다. 이를 통해 복잡한 비즈니스 제약 조건을 유연하게 처리하고, 기존 광고 서비스들을 에이전트가 활용하는 도구로 재정의함으로써 시스템 전반의 운영 효율성을 극대화하는 것이 이 글의 핵심입니다. ### 기존 워크플로우의 구조적 한계와 파편화 * **채널별 로직 불일치:** 동일한 백엔드 인프라를 공유함에도 불구하고 Direct, Self-Serve, Programmatic 등 각 구매 채널별로 의사결정 로직과 휴리스틱이 다르게 구현되어 동작의 불일치가 발생합니다. * **중복 구현과 기술 부채:** 예산 할당이나 인벤토리 선택과 같은 핵심 로직이 각 채널 및 사용자 접점(Spotify Ads Manager, Salesforce, Slack 등)마다 중복 구현되어 관리 비용이 증가하고 로직의 변질(Drift)이 일어납니다. * **의도 계층(Intent Layer)의 부재:** 기존 시스템은 "브라질 내 도달 범위 극대화 및 비디오 인벤토리 보호"와 같은 복합적인 목표를 이해하고 이를 실행 가능한 도구 호출 순서로 변환하는 능력이 부족했습니다. ### 멀티 에이전트 기반 의사결정 계층의 도입 * **모듈형 에이전트 구조:** 복잡하고 확률적인 광고 로직을 정적인 규칙 엔진(Rules Engine)에 가두는 대신, 상황에 따라 추론하고 실행하는 독립적인 에이전트들의 집합으로 구성했습니다. * **공유 신호 기반 최적화:** 모든 에이전트는 인벤토리, 오디언스, 성능 이력 등 동일한 기저 신호를 공유하며 광고주의 목표와 Spotify의 비즈니스 제약 조건을 동시에 고려하여 최적의 경로를 찾습니다. * **기존 서비스의 도구화:** 기존 광고 서비스들을 처음부터 다시 만드는 대신, 에이전트가 목적에 따라 호출하여 사용할 수 있는 '도구(Tools)'로 활용함으로써 오케스트레이션 성능을 높였습니다. ### 에이전트 중심 설계를 위한 기술적 패러다임 전환 * **API 설계의 변화:** 단순히 데이터를 생성하고 수정하는 CRUD 방식에서 벗어나, 에이전트가 특정 기능을 실행하기 위해 직관적으로 이해하고 사용할 수 있는 '도구 중심 API'로 재설계했습니다. * **행동 중심의 평가:** 전통적인 유닛/통합 테스트를 넘어, 에이전트가 내린 결정이 비즈니스 목표에 부합하는지 확인하는 '행동 평가(Behavioral Evaluation)' 체계를 구축했습니다. * **추론 과정의 관측성:** 시스템 성능 지표뿐만 아니라 "에이전트가 왜 그런 결정을 내렸는가"에 대한 추론 과정을 추적하여 투명성을 확보했습니다. * **자율성을 제어하는 가드레일:** 입력값 검증 수준을 넘어 반자율적인 에이전트의 결정이 비즈니스 규칙과 안전 가이드라인 내에서 유지되도록 하는 가드레일 메커니즘을 도입했습니다. 복잡한 비즈니스 로직이 여러 플랫폼에 흩어져 있다면, 이를 개별 서비스로 관리하기보다 통합된 '의사결정 엔진'으로서의 에이전트 플랫폼을 구축하는 것이 장기적인 유지보수와 기능 확장 면에서 유리합니다. Spotify는 이를 미디어 플래닝(Media Planning) 영역에 우선 적용하여 복잡한 변수 속에서도 일관된 최적화 성능을 증명하고 있습니다.

netflix원문

Temporal이 넷플릭스의 안정 (새 탭에서 열림)

넷플릭스는 배포 시스템인 Spinnaker의 클라우드 작업 안정성을 높이기 위해 '지속 가능한 실행(Durable Execution)' 플랫폼인 Temporal을 도입했습니다. 기존 시스템은 인스턴스 재시작이나 네트워크 일시 오류 발생 시 작업 상태를 잃어버리는 구조적 한계로 인해 약 4%의 배포 실패율을 보였습니다. Temporal 도입 후, 상태 정보를 자동으로 유지하고 장애 시 중단 지점부터 재개하는 방식을 통해 일시적 장애로 인한 실패율을 0.0001%까지 획기적으로 낮추는 성과를 거두었습니다. **기존 Spinnaker 구조와 상태 관리의 한계** * 배포 엔진인 Orca가 Clouddriver에 작업을 요청하면, Clouddriver는 내부 오케스트레이션 엔진을 통해 클라우드 제공업체의 API를 호출하는 구조였습니다. * 작업 상태가 메모리나 휘발성 저장소에 유지되었기 때문에, 클러스터 업데이트나 인스턴스 종료와 같은 운영 작업 중 실행 중인 모든 작업이 유실되거나 일관성이 깨지는 문제가 빈번했습니다. * 복잡한 다단계 클라우드 작업 중 중간 단계에서 오류가 발생하면, 수동으로 개입하여 상태를 정리하거나 재시도 로직을 직접 복잡하게 구현해야만 했습니다. **Temporal을 이용한 지속 가능한 실행 구현** * 비즈니스 로직을 담당하는 '워크플로우(Workflow)'와 외부 API 호출 등 부수 효과를 수행하는 '액티비티(Activity)'를 분리하여 설계했습니다. * Temporal은 작업의 모든 실행 단계를 데이터베이스에 기록(Event Sourcing)하므로, 실행 중 프로세스가 죽더라도 새 인스턴스에서 마지막 상태를 복구하여 즉시 재개할 수 있습니다. * 개발자는 일시적인 네트워크 오류나 API 제한에 대비한 복잡한 재시도 코드를 작성하는 대신, Temporal의 선언적 재시도 정책을 활용해 "장애가 없는 것처럼" 코드를 작성할 수 있게 되었습니다. **도입 결과 및 운영 효율성 향상** * 일시적 장애로 인한 배포 실패율이 4%에서 0.0001%로 감소하며 시스템 신뢰도가 비약적으로 상승했습니다. * CDN 장비 업데이트와 같이 며칠 혹은 몇 주가 소요되는 장기 실행 작업도 타임아웃이나 상태 유실 걱정 없이 안정적으로 관리할 수 있게 되었습니다. * 인프라 운영 팀은 시스템 점검이나 배포를 위해 기존 작업을 강제로 중단하거나 완료될 때까지 기다릴 필요가 없어져 운영 유연성이 크게 확보되었습니다. 복잡한 분산 시스템에서 상태 관리와 재시도 로직을 직접 구현하는 것은 매우 까다롭고 오류가 발생하기 쉽습니다. 넷플릭스의 사례처럼 장기 실행 작업이나 높은 신뢰성이 요구되는 마이크로서비스 환경에서는 Temporal과 같은 워크플로우 엔진을 도입하여 인프라 수준에서 안정성을 보장받는 것이 효율적입니다.

naver원문

네이버 TV (새 탭에서 열림)

VLOps는 학습, 평가, 배포 과정을 Typed Message 단위로 정의하고 이를 감지해 자율적으로 실행하는 이벤트 기반 MLOps 시스템입니다. 기존 파이프라인 방식의 복잡성을 해결하고 시스템 간 느슨한 결합을 통해 클라우드 호환성과 기능 확장성을 극대화한 것이 특징입니다. 이를 통해 사용자는 내부의 복잡한 오케스트레이션 구조를 몰라도 메시지 발행만으로 효율적인 모델 관리 파이프라인을 구동할 수 있습니다. **이벤트 기반 MLOps의 핵심 구조** * 학습, 평가, 배포 등 MLOps의 각 단계를 Typed Message라는 독립적인 데이터 단위로 정의하여 관리합니다. * Event Sensor가 발행된 메시지를 실시간으로 감지하고, 정의된 로직에 따라 적절한 작업을 자율적으로 수행하는 구조를 가집니다. * 메시지 중심의 설계를 통해 각 시스템 간 의존성을 낮추는 느슨한 결합(Loose Coupling)을 실현하여, 특정 클라우드 환경에 종속되지 않는 호환성을 확보했습니다. **기존 파이프라인 방식과의 차별점** * Kubeflow와 같은 전통적인 파이프라인 도구와 달리, 전체 워크플로우에 대한 엄격한 버전 관리가 강제되지 않아 운영의 유연성이 높습니다. * 새로운 기능을 추가할 때 전체 시스템을 재설계할 필요 없이, 단순히 새로운 메시지 타입을 정의하고 추가하는 것만으로 기능을 확장할 수 있습니다. * 사용자는 복잡한 내부 인프라 로직을 이해할 필요 없이 표준화된 메시지만 발행하면 동일한 파이프라인 결과를 얻을 수 있어 개발 경험이 개선됩니다. **Omni-Evaluator와 대시보드를 통한 통합 관리** * Omni-Evaluator는 파편화된 다양한 모델 엔진과 벤치마크 도구들을 하나로 통합하여 일관된 평가 환경을 제공합니다. * VLOps Dashboard를 통해 전체 작업의 진행 상태를 실시간으로 모니터링하고 시각화된 결과 지표를 한눈에 파악할 수 있습니다. * 시스템에 의한 자동 트리거뿐만 아니라, 사용자가 필요 시 직접 이벤트를 발생시켜 특정 평가나 배포를 수행할 수 있는 사용자 주도적 제어 기능을 지원합니다. 모델의 규모가 커지고 복잡해지는 멀티모달 LLM 환경에서는 경직된 파이프라인보다 이벤트 기반의 비동기 아키텍처가 변화에 더 유연하게 대응할 수 있습니다. 인프라의 복잡도를 추상화하고 메시지 기반의 확장성을 확보하려는 조직에게 VLOps와 같은 접근 방식은 매우 실용적인 대안이 될 것입니다.

aws원문

AWS Lambda Durable Functions를 사용하여 다단계 (새 탭에서 열림)

AWS Lambda Durable Functions의 출시로 개발자들은 별도의 상태 관리 인프라를 구축하지 않고도 복잡한 다단계 애플리케이션과 AI 워크플로우를 익숙한 Lambda 환경에서 구현할 수 있게 되었습니다. 이 기능은 '체크포인트 및 재실행(Checkpoint and Replay)' 메커니즘을 통해 실행 상태를 자동으로 추적하며, 실행 도중 실패가 발생하더라도 마지막 완료 지점부터 작업을 재개합니다. 특히 대기 상태에서는 컴퓨팅 비용이 발생하지 않으면서도 최대 1년까지 실행을 일시 중단할 수 있어, 결제 처리나 사용자 승인이 필요한 장기 프로세스에 최적화된 솔루션을 제공합니다. ### 지속성 실행(Durable Execution)의 핵심 메커니즘 * **체크포인트 및 재실행:** Durable execution SDK를 사용하면 함수가 실행될 때마다 진행 상황이 자동으로 기록됩니다. 예기치 않은 오류로 실행이 중단되더라도 Lambda는 처음부터 핸들러를 다시 실행하되, 이미 완료된 단계는 스킵하고 마지막 체크포인트부터 비즈니스 로직을 이어갑니다. * **비용 효율적인 대기:** 실행 중 특정 지점에서 실행을 일시 중단하면 컴퓨팅 자원 할당이 해제되어 유휴 비용이 발생하지 않습니다. 이후 정의된 조건이 충족되면 자동으로 실행이 재개됩니다. ### 워크플로우 제어를 위한 주요 프리미티브(Primitives) * **context.step():** 비즈니스 로직에 자동 재시도 및 체크포인트 기능을 추가합니다. 해당 단계가 성공적으로 완료되면 이후 재실행 시 다시 수행되지 않도록 보장합니다. * **context.wait():** 지정된 기간 동안 함수의 실행을 중단합니다. 최대 1년까지 대기가 가능하며, 대기 기간 동안에는 비용이 청구되지 않습니다. * **create_callback():** 외부 API 응답이나 사람의 직접적인 승인과 같은 외부 이벤트를 기다릴 수 있는 콜백을 생성합니다. * **wait_for_condition():** REST API 폴링 등을 통해 특정 조건이 충족될 때까지 실행을 일시 정지합니다. * **parallel() 및 map():** 복잡한 병렬 처리 및 동시성 유스케이스를 지원하여 효율적인 리소스 활용을 돕습니다. ### 서비스 도입 시 고려사항 * **설정 방식:** Durable Functions 기능은 Lambda 함수를 처음 생성하는 단계에서만 활성화할 수 있으며, 기존에 이미 생성된 함수에는 소급 적용이 불가능합니다. * **개발 환경:** 함수 생성 시 'Durable execution' 옵션을 활성화한 후, 코드 내에 오픈 소스로 제공되는 Durable Execution SDK를 포함하여 비즈니스 로직을 작성해야 합니다. * **활용 사례:** 주문 처리 프로세스, AI 에이전트의 다단계 추론 오케스트레이션, 인적 승인이 필요한 결재 시스템 등 상태 유지가 필수적인 워크로드에 강력한 이점을 제공합니다. AWS Lambda Durable Functions는 Step Functions와 같은 외부 오케스트레이션 도구 없이도 코드 수준에서 상태ful한 워크플로우를 관리할 수 있게 해줍니다. 단순한 이벤트 처리를 넘어 긴 호흡의 비즈니스 로직을 관리해야 하는 백엔드 개발자나 AI 엔지니어에게 매우 실용적인 도구가 될 것입니다.