line·2026년 2월 13일원문

Claude Code Action: 조직 전반의 코드 품질을 지키는 AI 코드 리뷰 플랫폼화 (새 탭에서 열림)

LINE NEXT는 조직의 성장에 따른 코드 리뷰 품질 편차를 줄이고 개인 단위로 파편화된 AI 도구 활용을 조직 차원의 표준으로 통합하기 위해 Claude Code를 활용한 플랫폼화된 코드 리뷰 시스템을 구축했습니다. GitHub Actions를 기반으로 설계된 이 시스템은 리뷰 기준과 실행 로직을 중앙에서 관리함으로써 수많은 프로젝트에 일관된 품질의 피드백을 신속하게 제공합니다. 결과적으로 개별 팀의 운영 부담은 최소화하면서 보안과 거버넌스가 강화된 자동화된 리뷰 환경을 전사적으로 확산시키는 성과를 거두었습니다. ### AI 코드 리뷰 플랫폼화의 배경과 목적 * **품질 편차 해소:** 조직 규모가 커짐에 따라 리뷰어의 경험과 성향에 따라 달라지는 코드 리뷰의 깊이와 관점을 조직 차원에서 일관되게 유지할 필요가 있었습니다. * **개인 도구의 한계 극복:** 개별 개발자가 로컬에서 AI를 사용할 때 발생하는 리뷰 기준의 상이함, 프로세스 단절, 신규 구성원 온보딩의 어려움을 해결하고자 했습니다. * **DevOps 관점의 표준화:** 파편화된 품질 프로세스를 하나로 묶어 PR(Pull Request) 워크플로에 자연스럽게 녹아드는 '표준 구성 요소'로 재정의했습니다. ### GitHub Actions 기반의 통합 전략 * **기존 흐름 유지:** LINE NEXT의 표준 소스 관리 도구인 GitHub와 CI/CD 도구인 GitHub Actions를 활용하여 개발자의 학습 비용을 낮추고 기존 워크플로에 즉시 통합했습니다. * **인프라 운영 효율화:** DevOps 팀이 공통 GitHub App Runner 환경을 제공함으로써, 각 서비스 팀은 추가 인프라 구성 없이 설정만으로 AI 리뷰를 도입할 수 있게 했습니다. * **접근성 향상:** PR 내에서 `@claude` 멘션만으로 리뷰를 트리거하고, 결과물은 GitHub 댓글이나 리뷰 형태로 즉각 확인하는 직관적인 UX를 제공합니다. ### 호출과 실행을 분리한 설계 구조 (Caller-Executor) * **서비스 리포지터리(Caller):** AI 리뷰의 진입점 역할만 수행하며, 서비스명과 리뷰 타입 등 최소한의 정보만 전달하여 구조적 단순함을 유지합니다. * **중앙 리포지터리(Executor):** 프롬프트 관리, 페르소나 정의, 리뷰 정책, 권한 제어 등 핵심 로직을 집약하여 관리합니다. * **일관성 및 확산성:** 중앙에서 프롬프트를 수정하면 연결된 모든 프로젝트에 즉시 반영되며, 새로운 프로젝트는 표준 워크플로 호출만으로 빠르게 온보딩이 가능합니다. * **보안 강화:** GitHub Apps 기반의 인증과 Secrets 중앙 관리를 통해 외부 AI 호출 시의 보안 권한과 코드 접근 이력을 명확히 추적하고 통제합니다. ### 기술적 제약 극복: 포크(Fork) 기반 PR 처리 개선 * **공식 Action의 한계:** Claude Code Action의 초기 버전은 변경 코드가 `origin` 저장소에 있다는 것을 전제로 하여, 외부 포크 저장소에서 생성된 PR의 차이(diff)를 가져오지 못하는 문제가 있었습니다. * **내부 참조(ref) 활용:** 특정 브랜치를 fetch하는 방식 대신, GitHub가 모든 PR에 대해 자동으로 생성하는 특수한 참조 주소인 `refs/pull/<PR 번호>/head`를 사용하도록 로직을 재설계했습니다. * **결과:** 이 구조적 개선을 통해 내부 브랜치뿐만 아니라 외부 기여자의 포크 PR에 대해서도 중단 없는 AI 코드 리뷰가 가능한 범용적인 플랫폼 환경을 완성했습니다. ### 실용적인 제언 AI 코드 리뷰 도구를 도입할 때는 단순히 개별 리포지터리에 적용하는 것을 넘어, **'호출은 단순하게, 책임은 중앙으로'** 분리하는 아키텍처를 설계하는 것이 중요합니다. 이를 통해 조직 전체의 리뷰 품질을 상향 평준화하고, 보안 정책 변경이나 프롬프트 고도화 시 발생하는 운영 비용을 획기적으로 줄일 수 있습니다.

DevOps데이터베이스 설계쿠버네티스CI/CD+4

toss·2026년 1월 20일원문

레거시 인프라 작살내고 하이브리드 클라우드 만든 썰 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 인프라의 비효율성을 극복하기 위해 오픈소스 기반의 OpenStack 프라이빗 클라우드를 직접 구축하고, 이를 퍼블릭 클라우드와 결합한 'Active-Active 하이브리드 클라우드' 환경을 구현했습니다. 단 2명의 엔지니어가 운영 경험 없이 시작했음에도 불구하고 자동화와 고가용성 전략을 통해 인프라 제어권을 100% 확보했으며, 결과적으로 어떤 환경에서도 즉시 배포 가능한 유연한 기술 기반을 마련했습니다. ### 1,997개의 라우팅이 보여주는 레거시 인프라의 한계 * 과거 인수한 인프라는 네트워크 장비가 아닌 개별 서버가 직접 라우팅 정보를 관리하는 비정상적인 구조로, 서버당 약 2,000개의 라우팅 경로가 설정되어 있었습니다. * 새로운 경로 추가 시 모든 서버를 일일이 수정해야 하는 관리 포인트의 과부하가 발생했으며, 이는 서비스 확장의 심각한 병목 현상이 되었습니다. * 초기에는 퍼블릭 클라우드 도입으로 대응했으나 비용 증가, 환율 변동, 하이브리드 DR 구성의 어려움 및 가시성 부족이라는 새로운 문제에 직면했습니다. ### OpenStack 기반 프라이빗 클라우드 내재화 * 상용 솔루션 대신 오픈소스인 OpenStack을 선택하여 기술 내재화와 유연한 인스턴스 타입(VM, Container, K8S) 대응력을 확보했습니다. * 부족한 운영 경험을 극복하기 위해 3가지 버전의 OpenStack을 수십 번 설치하고 장애 시나리오를 반복 재현하며 아키텍처 이해도를 높였습니다. * 로드밸런서인 옥타비아(Octavia)의 소스 코드를 직접 수정하여 비즈니스 요구에 맞는 로그 포맷을 생성하는 등 오픈소스의 이점을 극대화했습니다. ### 자동화와 모니터링을 통한 운영 효율 극대화 * Ansible과 Terraform 코드를 활용해 모든 자원의 라이프사이클을 자동화했으며, 골든 이미지를 통해 신규 인스턴스 생성 시간을 10초 이내로 단축했습니다. * Zabbix, Prometheus, Mimir, Grafana 등 다양한 오픈소스 툴을 조합하여 모든 메트릭을 수집하고, 실시간 알람 체계를 구축해 장애 감지 능력을 높였습니다. * 운영 인력의 한계를 극복하기 위해 CMDB와 연동된 봇(Bot)을 구현하여 인프라 현황을 실시간으로 조회하고 관리할 수 있도록 했습니다. ### 고가용성을 위한 다중 클러스터 및 Cluster API 전략 * 장애 발생 시 서비스 가용성을 즉시 확보하기 위해 서로 독립된 3개의 OpenStack 클러스터를 구축하고 평상시 Active-Active로 운영합니다. * 특정 클러스터 장애 시 트래픽을 즉시 차단하는 방식으로 복구 시간을 최소화했으며, 클러스터 간 의존성을 완전히 제거했습니다. * K8S 관리를 위해 Cluster API(CAPI)를 도입하여 쿠버네티스 클러스터 자체를 쿠버네티스 리소스로 관리함으로써 퍼블릭 클라우드 수준의 관리 편의성을 프라이빗 환경에서도 구현했습니다. 전통적인 금융 인프라의 보수성을 탈피하고 오픈소스 기술을 깊이 있게 내재화한다면, 퍼블릭 클라우드의 편리함과 온프레미스의 통제권을 동시에 거머쥘 수 있습니다. 인력 부족이나 기술적 난도는 자동화와 표준화된 도구(CAPI, Terraform 등)를 통해 충분히 극복 가능하므로, 비용 최적화와 기술적 가시성이 필요한 조직이라면 하이브리드 클라우드 전략을 적극 권장합니다.

DevOps쿠버네티스infrastructure-as-codehigh-availability+4

naver·2025년 11월 27일원문

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

네이버 통합검색은 서비스 복잡도가 급증함에 따라 발생하는 장애 대응의 한계를 극복하기 위해 LLM 기반의 DevOps 에이전트를 도입했습니다. 이 에이전트는 단순히 장애 알람을 전달하는 수준을 넘어, 시스템 메트릭과 로그를 스스로 분석하고 최적의 조치 방안을 추천하며 경험을 통해 지속적으로 진화합니다. 결과적으로 복잡한 검색 인프라 운영의 효율성을 극대화하고 장애 복구 시간(MTTR)을 단축하는 것을 목표로 합니다. **기존 장애 대응 프로세스의 한계** * 네이버 검색은 수많은 마이크로서비스가 복잡하게 얽혀 있어, 장애 발생 시 원인을 파악하기 위해 확인해야 할 메트릭과 로그의 양이 방대합니다. * 기존의 룰 기반(Rule-based) 시스템은 정해진 규칙 외의 변칙적인 장애 상황에 유연하게 대응하기 어렵고, 운영자의 숙련도에 따라 대응 속도 차이가 크게 발생했습니다. * 장애 상황마다 산재한 데이터를 수동으로 취합하고 분석하는 과정에서 발생하는 인지적 부하와 시간 지연이 주요 해결 과제로 대두되었습니다. **Devops Agent의 구조적 진화 (v1에서 v2로)** * **v1 설계 및 한계:** 초기 버전은 기본적인 데이터 수집과 리포팅 자동화에 집중했으나, 다양한 인프라 환경에서 발생하는 복합적인 컨텍스트를 LLM이 완벽히 이해하고 추론하기에는 한계가 있었습니다. * **v2 구조 개선:** v1의 한계를 극복하기 위해 Agentic Workflow를 강화하여, 에이전트가 상황에 따라 필요한 도구(Tools)를 스스로 선택하고 분석 단계를 세분화하여 실행하도록 재설계했습니다. * **SW Stack 고도화:** 최신 LLM 프레임워크와 네이버의 인프라 데이터를 효율적으로 결합하여, 실시간으로 변화하는 시스템 상태를 에이전트가 즉각적으로 파악할 수 있는 기반을 마련했습니다. **시스템 동작과 이상 탐지 메커니즘** * **Trigger Queue:** 모든 장애 징후와 알람을 큐(Queue) 시스템으로 관리하여 분석의 우선순위를 정하고, 누락 없는 대응이 가능하도록 설계했습니다. * **이상 탐지(Anomaly Detection):** 단순 임계치 기반 알람이 아니라, 통계적 모델과 AI를 활용해 평상시 패턴에서 벗어나는 이상 현상을 정교하게 포착합니다. * **평가 체계:** 에이전트가 내놓은 분석 결과와 추천 액션의 정확도를 지속적으로 평가하며, 실제 엔지니어의 피드백을 학습 데이터로 환류시켜 분석 품질을 높입니다. **지속 가능한 DevOps를 위한 향후 과제** * **컨텍스트 확대:** 장애 당시의 로그뿐만 아니라 배포 이력, 설정 변경 내역 등 더 넓은 범위의 데이터를 연동하여 분석의 정확도를 높이고 있습니다. * **액션 추천 및 자동화:** 장애 원인 분석을 넘어 "특정 서버 그룹의 트래픽을 차단하라"와 같이 구체적인 실행 코드를 생성하거나 직접 조치하는 단계로 확장 중입니다. * **지속 가능한 학습:** 새로운 유형의 장애가 발생할 때마다 이를 지식화하여 에이전트가 다음번 유사 사례에서 더 똑똑하게 대응할 수 있는 선순환 구조를 구축하고 있습니다. 이 시스템은 인프라 운영자가 반복적인 데이터 취합 업무에서 벗어나 의사결정과 문제 해결에만 집중할 수 있는 환경을 제공합니다. LLM 에이전트의 도입은 단순한 도구 활용을 넘어, 대규모 시스템 운영 노하우를 데이터화하고 지능화된 자동화로 전환하는 중요한 기술적 이정표가 될 것입니다.

DevOpsAI대규모 언어 모델incident-management+3

line·2025년 7월 16일원문

LY의 테크 컨퍼런스, 'Tech-Verse 2025' 후기 (새 탭에서 열림)

LY Corporation(이하 LY)은 기술 컨퍼런스 'Tech-Verse 2025'를 통해 합병 이후의 플랫폼 통합 전략과 AI 기업으로의 전환 비전을 제시했습니다. LY는 자체 프라이빗 클라우드 구축을 통해 압도적인 비용 절감과 보안 강화를 실현하고, 모든 서비스에 AI 에이전트를 도입하여 사용자 경험을 혁신할 계획입니다. 특히 생성형 AI를 활용한 개발 프로세스의 전면적인 진화로 엔지니어가 서비스 본질에 집중할 수 있는 환경을 구축하는 것이 핵심입니다. **CatalystOne: 고효율 통합 플랫폼 구축** * **자체 클라우드 기반의 비용 최적화**: 퍼블릭 클라우드 대비 약 4배의 비용 절감 효과를 거두고 있으며, 50만 대의 서버와 3Tbps에 달하는 대규모 트래픽을 효율적으로 관리하고 있습니다. * **플랫폼 통합(CatalystOne)**: 합병 후 중복된 인프라를 'CatalystOne'이라는 이름 아래 통합하여 기술, 엔지니어, 시설 등 핵심 자원의 운영 집중도를 높였습니다. * **보안 및 혁신 가속화**: 통합된 플랫폼을 통해 거버넌스를 강화하고, 폭발적인 데이터 성장과 생성형 AI 수요에 기민하게 대응할 수 있는 차세대 프라이빗 클라우드 'Flava'를 구축했습니다. **전 서비스의 AI 에이전트화와 개발 혁신** * **퍼스널 에이전트 구현**: 현재 44개 서비스에 생성형 AI를 도입했으며, 수천만 개의 에이전트를 연계하여 개별 사용자의 니즈를 정교하게 지원하는 것을 목표로 합니다. * **AI 기반 개발 솔루션 도입**: 2025년 7월부터 모든 엔지니어에게 AI 개발 솔루션을 전면 도입하며, RAG(검색 증강 생성) 기술로 사내 지식을 활용해 코드 품질을 높입니다. * **생산성 지표의 획기적 개선**: PoC 결과 'Code Assist'는 96%의 정답률을 기록했고, 'Auto Test' 도입으로 테스트 시간을 97% 단축하는 등 압도적인 개발 효율성 향상을 확인했습니다. **실용적인 결론** LY의 전략은 대규모 인프라를 운영하는 기업이 단순히 AI를 도입하는 것에 그치지 않고, 인프라 통합을 통한 비용 효율화와 AI를 활용한 개발 문화 혁신이 병행되어야 함을 보여줍니다. 특히 엔지니어링 환경에 AI를 적극적으로 이식하여 확보한 리소스를 사용자 가치 증대에 재투자하는 선순환 구조는 기술 기업들이 참고할 만한 모델입니다.

DevOpsAIAI 에이전트생성형 AI+4

figma·2024년 8월 12일·3분 읽기큐레이션 요약

아틀라시안 방식:

Atlassian은 개발자의 업무 마찰을 줄이고 개발의 본질적인 즐거움을 회복하는 ‘developer joy’를 개발자 경험의 새로운 기준이자 회사 차원의 핵심 목표로 삼았다. 도구와 프로세스를 정비하고 개발자에게 개선 ownership을 부여한 결과, 개발자 만족도와 배포 빈도, 풀 리퀘스트 처리 속도가 크게 향상됐다. 이 사례는 개발자 만족을 단순한 복지나 감정의 문제가 아니라 장기적인 사업 성과로 측정하고 관리할 수 있음을 보여준다. ## Developer joy의 의미 - 기존의 developer experience가 개발자의 전체 업무 흐름, 프로세스, 제품의 사용성을 다룬다면, developer joy는 개발이라는 직업의 본질과 장인정신, 개발자가 중요하게 여기는 기준과 가치를 강조한다. - 핵심은 개발자가 좋아하는 일에 집중할 수 있도록 불필요한 마찰과 인지 부하를 제거하는 것이다. - Atlassian의 조사에 따르면 개발자는 비효율 때문에 매주 8시간 이상, 전체 업무 시간의 약 20%를 잃고 있었다. - Stack Overflow 조사에서는 개발자의 25%가 문제 해결이나 답을 찾는 데 하루 한 시간 이상을 사용한다고 나타났다. - 개발 외에도 디자인 협업, 부서 간 조율, 기획과 같은 활동에 업무 시간의 20~30%가 소요되며, 이런 마찰이 개발의 즐거움을 떨어뜨렸다. ## 생산성 위기에서 출발한 변화 - 2022년 Atlassian은 공개 로드맵의 대부분을 제때 달성하지 못했고, 개발자 만족도도 50% 미만이었다. - 문제의 원인은 개인의 역량이 아니라 중복되거나 비효율적인 도구와 시스템, 복잡한 프로세스에 있었다. - 정보를 찾고 다른 팀과 조율하는 데 드는 시간이 누적되면서 개발자의 핵심 업무 집중력이 약화됐다. - Atlassian은 단순히 더 빨리 일하도록 압박하는 대신, 업무 환경 자체에서 불필요한 장애물을 제거하는 방향을 택했다. ## Developer joy를 운영 체계로 만들기 - Atlassian은 문제를 조직 전체에서 찾고 해결하기 위해 여러 직군이 참여하는 ‘champions’ 프로그램을 시작했다. - 개선 작업은 크게 시스템과 문화라는 두 영역으로 나뉘었다. - **시스템:** 기존 도구와 프로세스를 점검하고 표준화하거나 불필요한 항목을 제거했다. - **문화:** 코딩 표준, 조직의 가치, 성과 측정 기준을 정해 개발의 품질과 장인정신을 업무 방식에 반영했다. - 여러 팀이 비슷한 도구를 각각 보유한 상태를 Matt Schvimmer는 ‘도구의 노아의 방주’라고 표현했다. - 모든 엔지니어링 팀이 업무 시간의 10%를 개발자 생산성 개선에 사용하도록 했다. - 개발자들이 개선의 대상이 아니라 해결 과정의 주체가 되면서 조직 전체에 ownership이 생겼다. - 이후 developer joy는 전사 OKR로 채택됐고, 각 팀이 매월 관련 성과를 보고하게 됐다. ## 즐거움의 사업적 가치 측정 - developer joy를 회사 차원의 OKR로 삼으려면 단기 매출보다 참여도와 업무 환경 개선을 우선하는 선택이 필요했다. - Atlassian은 이를 장기적으로 복리 효과가 발생하는 투자에 비유했다. - 성과를 감정적 만족도에만 의존하지 않고 정량·정성 지표를 함께 측정했다. - 몇 달 만에 다음과 같은 변화가 나타났다. - 개발자 만족도 50% 증가 - 풀 리퀘스트 처리 사이클의 중앙값 50% 감소 - 배포 빈도 3배 증가 - 고객 로드맵의 모든 항목을 계획대로 전달 - 내부 고객 만족도(CSAT) 50% 미만에서 80%로 상승 - 도구를 개선하고, 프로세스 문제를 해결하며, 측정할 지표를 명확히 한 것이 성과로 이어졌다. ## Team joy로 확장되는 개념 - 개발자 만족도와 생산성 개선이 실제 성과로 확인되면서, Atlassian은 developer joy를 더 넓은 ‘team joy’의 관점으로 확장하려 했다. - 처음에는 ‘joy’라는 표현을 가볍거나 측정하기 어려운 개념으로 받아들이는 사람도 있었지만, 구체적인 지표와 사업 성과가 개념의 신뢰성을 뒷받침했다. - 개발자 개인의 경험을 개선하는 데서 나아가 팀 전체의 협업 방식과 조직 문화를 개선하는 방향으로 논의가 확대됐다. 도입할 때는 먼저 중복 도구와 불필요한 프로세스를 조사하고, 개발자들이 개선 과제에 직접 참여할 수 있는 시간을 보장하는 것이 현실적이다. 이후 만족도뿐 아니라 PR 처리 시간, 배포 빈도, 로드맵 달성률처럼 업무 흐름과 사업 결과를 함께 측정해야 developer joy를 지속 가능한 조직 목표로 만들 수 있다.

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

DevOpssoftware-developmentdeveloper-experienceagile+3

microsoft·2024년 7월 18일원문

관리형 DevOps 풀 – 탄생 비 (새 탭에서 열림)

마이크로소프트는 전사적으로 파편화되어 있던 5,000개 이상의 자가 호스팅 Azure DevOps 풀을 '1ES 호스팅 풀(1ES Hosted Pools)'이라는 단일 서비스로 통합하여 인프라 효율성과 보안성을 극대화했습니다. 이 시스템을 통해 인프라 비용을 60% 이상 절감하고 개발자들이 인프라 관리 대신 제품 개발에 집중할 수 있는 환경을 구축했으며, 내부적인 성공을 바탕으로 최근 외부 고객을 위한 '관리형 데브옵스 풀(Managed DevOps Pools, MDP)'을 출시했습니다. ### 분산된 자가 호스팅 환경의 문제점 * **중복 투자와 비효율:** 수천 개의 팀이 각자 유사한 인프라 관리 도구를 구축하는 데 개발 자원을 낭비했으며, 자동 스케일링 기능 부재로 사용하지 않는 자원에 비용이 지출되었습니다. * **낮은 신뢰성 및 지원 체계:** 팀 규모에 따라 지원 수준이 달라 장애 발생 시 CI/CD 파이프라인 복구 속도에 차이가 발생했습니다. * **보안 및 규정 준수의 어려움:** 인프라가 파편화되어 있어 보안 패치 여부를 추적하기 어렵고, 전사적인 보안 정책이나 컴플라이언스 기준을 일괄 적용하고 감사하는 데 막대한 시간이 소요되었습니다. ### 1ES 호스팅 풀의 핵심 기술적 기능 * **유연한 네트워크 및 이미지 구성:** 사설 네트워크 연결을 지원하여 내부 패키지 저장소나 비밀 관리자에 안전하게 접근할 수 있으며, 팀별 맞춤형 이미지를 베이스 이미지 위에 구축해 사용할 수 있습니다. * **상태 유지 및 성능 최적화:** 기본적으로는 작업마다 새 에이전트를 생성하는 상태 비저장(Stateless) 방식이지만, 로컬 캐시 활용이 필요한 경우 상태 유지(Stateful) 옵션을 제공하며 디스크 공간에 따른 자동 리사이클링을 지원합니다. * **지능형 리소스 관리:** 다양한 Azure SKU 선택은 물론, 과거 데이터를 기반으로 한 에이전트 사전 예열(Standby Agents) 기능을 통해 파이프라인 시작 시간을 단축했습니다. * **비즈니스 연속성 보장:** 특정 지역의 장애에 대비해 여러 지역에 백업 풀을 구성하여 에이전트를 즉시 가동할 수 있는 체계를 갖추었습니다. ### 표준화 시스템 도입의 성과 * **비용 절감:** Azure SPOT VM 활용과 워크로드에 최적화된 SKU 선택, 데이터 기반의 자원 활용도 개선을 통해 인프라 비용을 60% 이상 줄였습니다. * **보안 강화 및 중앙화:** Confidential VM, Trusted Launch, SecureTPM 등 고급 보안 기능을 모든 풀에 일괄 적용했으며, 일관된 텔레메트리 데이터를 통해 규정 준수 여부를 즉각적으로 확인할 수 있게 되었습니다. * **개발 생산성 향상:** 수천 개의 자가 호스팅 풀이 수십 개로 줄어들면서 인프라 관리 부담이 사라졌고, 팀 간 이동 시에도 동일한 도구를 사용하게 되어 개발 환경 적응 기간이 단축되었습니다. 현재 자체적으로 VM 확장 집합(Scale Set)이나 자가 호스팅 에이전트를 운영하며 관리 부담을 느끼고 있다면, 마이크로소프트의 내부 운영 노하우가 집약된 **Managed DevOps Pools(MDP)**로 전환하는 것을 추천합니다. 이를 통해 보안 수준을 높이는 동시에 운영 비용과 관리 오버헤드를 획기적으로 줄일 수 있습니다.

DevOpsCI/CDcloud-infrastructureazure+3