지속적 통합(CI)은 개발자가 개발 주기 내내 새로운 코드와 코드 변경 사항을 정기적으로 중앙 코드 리포지토리에 통합하는 소프트웨어 개발 관행입니다. 이는 DevOps와 애자일 방법론의 핵심 구성 요소입니다.
지속적 통합은 소프트웨어 제공 프로세스를 간소화하는 자동화된 DevOps 워크플로인 CI/CD 파이프라인의 첫 번째 단계입니다. 지속적 통합은 DevOps 팀이 소프트웨어 애플리케이션을 지속적으로 개선하고, 일관된 피드백을 받고, 소프트웨어 성능에 영향을 미치기 전에 오류를 발견 및 수정하며, 보다 예측 가능한 일정에 맞춰 더 높은 품질의 소프트웨어를 제공할 수 있도록 합니다.
개발자가 버전 관리 시스템의 기본 또는 공유 분기에 코드 변경 사항을 커밋하면 CI 도구가 트리거되어 업데이트된 코드 베이스의 '빌드'를 수행합니다. CI 시스템은 새 코드를 가져와 기존 코드로 컴파일하고 종속성(예: 구성 파일, 라이브러리, 기타 리소스)과 함께 패키징합니다. 이것이 '빌드'를 구성합니다.
추가 테스트 위해 전달되거나 프로덕션 환경에 전달되는 결과 파일인 '빌드 아티팩트'가 생성되기 전에 자동화된 테스트가 실행되어 이 빌드를 검증합니다. 이 파이프라인의 다음 부분을 지속적 제공(CD)이라고 부릅니다.
CI는 기존 소프트웨어 개발과 관련된 과제, 즉 통합 및 배포 프로세스에 대한 솔루션으로 만들어졌습니다. 기존 개발 패러다임에서는 각 개발자가 새 코드를 앱이나 서비스의 새로운 반복에 수동으로 통합해야 했기 때문에 특히 대규모 개발 팀의 경우 통합은 시간이 오래 걸리고 오류가 발생하기 쉬운 프로세스였습니다.
서로 다른 코드 조각이 항상 잘 연동되는 것은 아니었고 개발자들은 서로 다른 타임라인에서, 때로는 마지막 순간에 변경 사항을 통합했기 때문에 통합 문제에 대한 피드백이 지연되는 경우가 많았습니다. 문제가 발생했을 때 피드백이 지연되면 팀에서 어떤 변경 사항이 문제를 일으켰는지 파악하기가 더 어렵고 디버깅 프로세스도 더 힘듭니다.
그뿐만 아니라 소프트웨어 테스트는 드물었습니다. 팀은 일반적으로 대규모 일괄 업데이트를 한꺼번에 시행했기 때문에 버그가 틈새로 빠져나가 코드 베이스에 누적될 수 있었습니다. 그 결과, 개발팀은 더 까다로운 문제 해결 작업, 더 높은 실패율, 느린 코드 릴리스에 직면했고, 기업은 비효율적인 프로세스로 인한 매출 손실, 사용자는 더 많은 소프트웨어 오류와 결함을 경험했습니다.
지속적 통합(CI)은 현대 DevOps 관행, 지속적 통합/지속적 배포(CI/CD) 파이프라인, 마이크로서비스 아키텍처의 기초적인 구성 요소로서, 통합 성능에 대한 빠른 피드백을 제공하여 빌드 프로세스를 간소화하는 데 도움을 줍니다.
CI 시스템을 사용하면 새 코드가 중앙 리포지토리에 추가되고(일반적으로 하루에 여러 번) 빌드 및 테스트를 위해 남아 있습니다. 시스템이 오류를 감지하면 알림을 보내고, 코드를 수정하고, 업데이트된 코드가 올바른지 확인한 후 소프트웨어의 코드 베이스와 완전히 병합합니다.
업계 뉴스레터
Think 뉴스레터를 통해 AI, 자동화, 데이터 등 가장 중요하고 흥미로운 업계 동향에 대한 최신 소식을 받아보세요. IBM 개인정보 보호정책을 참조하세요.
구독한 뉴스레터는 영어로 제공됩니다. 모든 뉴스레터에는 구독 취소 링크가 있습니다. 여기에서 구독을 관리하거나 취소할 수 있습니다. 자세한 정보는 IBM 개인정보 보호정책을 참조하세요.
지속적 통합(CI) 시스템의 구체적인 구성은 팀과 비즈니스마다 다르지만, 모든 CI 시스템은 코드 통합 작업을 최적화하기 위해 특정 구성 요소와 프로세스를 사용합니다.
CI는 모든 개발자가 코드를 커밋하는 중앙 공유 리포지토리에서 시작됩니다. 중앙 리포지토리는 CI 관행의 초석 역할을 합니다. Git과 Bitbucket과 같은 버전 관리 시스템(VCS)은 이러한 리포지토리를 관리하는 경우가 많습니다. 개발자가 변경 사항을 제출하면 중앙 리포지토리는 이를 추적하여 코드 변경의 전체 기록을 생성하고, 개발팀은 이를 활용해 더 효율적으로 협업할 수 있습니다.
리포지토리는 또한 분기 기법을 사용하여, 진행 중인 코드 변경을 메인 코드베이스(메인 브랜치)와 분리하고 병렬 개발을 촉진합니다. 분기를 통해 개발자는 특정 앱 기능을 격리하기 위한 기능 브랜치와, 작업을 메인 코드 브랜치에 병합하기 전 분리해 두는 단기 브랜치를 만들 수 있습니다.
예를 들어, Gitflow는 역할(예: 'main', 'feature', 'develop' 및 'release')을 서로 다른 분기에 할당함으로써 서로 상호 작용하는 방식을 제어하는 Git 기반 분기 모델입니다. Gitflow 분기를 사용하려면 개발자가 기능 분기를 만들고 기능이 완성될 때까지 기다렸다가 코드 변경 사항을 기본 분기에 병합해야 합니다.
CI 서버는 모든 CI 작업을 중앙 집중화하고 관리하는 도구입니다. 또한 CI 프로세스의 자동화 허브 역할을 합니다. CI 서버는 리포지토리에서 코드 변경을 모니터링하고 변경이 감지되면 사전 정의된 CI 파이프라인을 시작 및 구동합니다. CI 서버는 자동화된 빌드, 테스트 및 소프트웨어 릴리스를 실행하고, 버전 관리 프로토콜을 오케스트레이션하고, 상태 보고를 처리하고, 시스템 기능을 개선할 수 있는 플러그인을 지원합니다.
많은 CI 서버에는 팀이 워크플로를 모델링하고 시각화하며 지속적 전달(CD) 파이프라인을 구성할 수 있도록 돕는 사용자 인터페이스가 있습니다.
CI 시스템은 개발자가 매일 여러 번 코드 변경 사항을 제출하도록 권장하며, 특정 작업이나 기능에 대한 작고 집중적인 변경 사항을 우선시합니다. CI 도구를 사용하면 팀은 새 코드를 병합하기 전에 코드 검토를 시작하고 문제를 논의하므로 개발 프로세스 초기에 오류를 발견할 수 있습니다.
예를 들어, Git 기반 CI 시스템은 풀 요청을 시작하여 로컬 분기(단일 개발자의 컴퓨터에 로컬로 저장됨)에서 코드 변경 사항을 가져오고 이를 현재 원격 분기(원격으로 저장되고 전체 개발 팀이 공유)에 통합할 수 있습니다. 또한 병합 요청을 통해 개발자는 팀 검토, 토론 및 승인을 위해 로컬 분기에서 제안된 변경 사항을 다른 로컬 분기와 통합한 후 이를 원격 분기와 병합할 수 있습니다.
지속적 통합 서버와 툴(Jenkins, CircleCI, GitHub, AWS CodePipeline, GitLab CI 등 인기 있는 오픈 소스 툴 포함)은 중앙 리포지토리에서 코드 변경을 모니터링합니다. 새로운 변경을 감지하면, CI 서버는 빌드 프로세스를 시작하고 미리 정의된 워크플로와 빌드 스크립트를 실행하여 코드를 컴파일하고 패키징해 테스트 및 최종 배포를 준비합니다.
CI 도구는 코드 베이스와 병합하기 전에 코드의 유효성을 검사하기 위해 다양한 테스트를 실행합니다. 단위 테스트는 개별 구성 요소 또는 기능의 유효성을 검사하여 코드 동작에 대한 즉각적인 피드백을 제공합니다. 통합 테스트는 소프트웨어 구성 요소와 모듈 간의 상호 작용을 평가하여 함께 올바르게 작동하는지 확인하고 단위 테스트에서 놓칠 수 있는 문제를 파악합니다.
일부 CI 워크플로에서 엔드투엔드 테스트는 사용자 상호 작용을 시뮬레이션하여 소프트웨어가 사용자의 관점에서 올바르게 작동하는지 확인하여 소프트웨어를 검증합니다. 또한 팀은 코드 품질 테스트와 정적 분석을 실행하여 부하 시 애플리케이션의 응답성과 안정성을 확인하고 코딩 표준 위반 및 보안 취약점을 식별할 수 있습니다.
CI 서버는 빌드 또는 테스트가 실패할 경우 개발자에게 이를 즉시 알립니다. 오류가 발생할 경우 개발자는 기본 분기가 배포 가능한 상태로 유지되도록 코드를 복구하는 데 우선순위를 둘 수 있습니다.
소프트웨어 빌드가 성공하면, 서버는 빌드 과정에서 생성된 컴파일된 코드, Docker 이미지, 라이브러리와 같은 파일(아티팩트)을 생성하고, 이를 버전 관리하여 향후 테스트와 배포를 위해 리포지토리에 보관합니다. 결과에 관계없이, 주요 CI 시스템은 팀원이 항상 포괄적인 버전 문서에 액세스할 수 있도록 통합 시도, 성공률 및 기타 지표를 기록합니다.
테스트는 지속적 통합 프로세스의 중요한 구성 요소입니다. 테스트는 최소한 CI 활동의 약 1/3을 차지하지만, 이는 팀이 단일 테스트 단계를 실행하는 경우에만 해당됩니다. 테스트 활동이 CI 도구 워크로드의 대부분을 차지하는 경우가 많습니다.
CI 환경에서의 연속적인 테스트는 개발자가 코드 베이스에 새 코드를 커밋할 때 시작됩니다. 이 작업은 빌드 및 자동화된 테스트 프로세스를 트리거합니다. 대부분의 경우 빌드 아티팩트가 생성되면 추가 테스트가 수행됩니다(코드가 프로덕션 단계로 이동하기 전). 또한 개발자는 로컬 환경에서 모든 테스트와 테스트의 하위 집합을 실행하여 새 코드 변경 사항이 테스트를 통과한 후에만 소스 코드를 버전 제어에 커밋하도록 하는 것이 중요합니다.
다양한 기능, 사용 사례 및 통합을 다각도로 테스트하는 것을 통틀어 테스트 스위트라고 부릅니다. 이 접근 방식은 테스트 범위를 극대화하고, 코드 회귀를 방지하며, 성공적인 지속적 전달을 위한 기반을 마련합니다.
테스트 주도 개발(TDD)은 소프트웨어 개발에 대한 또 다른 접근 방식입니다. TDD는 개발자가 코드를 작성하기 전에 테스트를 작성하여 '역방향으로 작업'하는 접근 방식입니다. 이 접근 방식에서 개발자는 실패하는 단위 수준 테스트 사례를 작성한 후 통과를 위한 최소한의 코드를 작성합니다. 이 작업이 완료되면 테스트 코드와 프로덕션 코드를 모두 리팩토링하여 개선할 수 있습니다.
이 접근 방식은 개발자가 명확하게 정의된 요구 사항에 집중하고 불필요한 코드를 피하도록 도와줍니다. 또한 지속적 피드백을 강조하며, 개발 주기를 가속화하는 효과적인 기법이 될 수 있습니다.
DevOps 파이프라인은 기존에 각자의 사일로에 존재하던 개발팀과 IT 운영팀의 노력을 자동화하고 결합하여 고품질 소프트웨어의 제공을 가속화합니다.
성공적인 DevOps 프로세스와 문화는 개발과 운영을 넘어 플랫폼 및 인프라 엔지니어링, 보안, 컴플라이언스, 거버넌스, 위험 관리, 라인 오브 비즈니스, 최종 사용자 및 고객까지 포함합니다. 즉, 우수한 DevOps는 모든 애플리케이션 이해관계자의 의견을 소프트웨어 개발 라이프사이클에 통합해야 합니다.
DevOps 프레임워크에서 지속적 통합은 소프트웨어 개발 프로세스와 CI/CD 파이프라인의 시작점에 위치합니다. CI는 개발자가 코드를 자주 점검해 로컬 사본이 메인 코드 브랜치와 지나치게 멀어지지 않도록 합니다. 이 접근 방식은 배포 단계에서 빌드를 "깨뜨릴" 수 있는 병합 충돌을 피하는 데 도움이 됩니다.
CI는 또한 개발자가 작고 빈번한 업데이트를 제출할 수 있게 하여, 고객 요구 사항의 우선순위를 기반으로 한 빠르고 일관된 피드백 루프와 지속적 개선을 촉진합니다. 이는 DevOps 철학의 핵심 원칙입니다.
지속적 통합은 CI/CD 파이프라인의 첫 번째 단계이며 일반적으로 지속적 제공 및 지속적 배포 프로세스가 뒤따릅니다. 지속적 통합은 빈번한 코드 병합과 그에 따른 빌드 및 단위 테스트를 의미합니다.
지속적 제공(CD)은 지속적 통합이 중단되는 부분을 찾아 검증된 코드 기반 변경 사항(예: 업데이트, 버그 수정, 새로운 기능)을 일부 환경 또는 코드 리포지토리로 자동으로 전달합니다. DevOps 팀은 최신 빌드에 대한 알림을 받고 업데이트를 라이브 프로덕션 환경으로 수동으로 이동할 수 있습니다. 지속적 제공 파이프라인 단계의 목표는 최소한의 노력으로 새 코드를 배포하면서도 코드가 라이브로 전환되기 전에 어느 정도의 인간 감독을 허용하는 것입니다.
지속적 배포는 코드 무결성을 보장하기 위해 모방 환경에서 코드를 테스트하는 통합 테스트와 같은 일련의 사전 정의된 테스트를 통과한 후 최종 사용자에게 코드 변경 사항을 자동으로 릴리스합니다. 지속적 제공과 지속적 배포는 모두 파이프라인에서 CI보다 아래쪽에서 자동화를 처리하며 종종 같은 의미로 사용됩니다.
지속적 전달과 지속적 배포의 차이는 소프트웨어 또는 앱 릴리스에 사용되는 자동화 수준에 있습니다. 지속적 전달에서는 코드가 자동으로 프로덕션과 유사한 환경으로 이동해 추가 테스트 및 품질 보증(위험 평가, 소스 코드 취약점 식별 등)을 받습니다. 성공적인 테스트 이후에는 프로덕션으로 이동하기 위해 인간의 개입이 필요합니다.
지속적 배포에서는 자동화 수준이 더 높습니다. 코드가 테스트를 통과하면, 프로덕션으로의 배포가 자동으로 이루어지며 인간의 승인이 필요하지 않습니다.1
애자일 개발은 변화에 대한 유연성, 협업, 지속적 개선, 빠른 적응을 우선시하는 반복적 소프트웨어 엔지니어링 접근 방식입니다. 애자일은 개발을 더 작은 작업 단위(스프린트)로 나누어 개발자와 이해관계자 간의 협업을 간소화하고 소프트웨어 전달 속도를 높이는 방법입니다.
마찬가지로, CI에는 빈번한 증분적 코드 업데이트와 지속적인 코드 유효성 검사가 필요합니다. 이러한 반복적 개발 접근 방식을 통해 개발자는 시간이 지남에 따라 소프트웨어 솔루션을 빠르게 업그레이드 및 확장하고 사용자에게 고품질 제품을 더 빠르게 제공할 수 있습니다. 따라서 통합은 본질적으로 애자일 관행입니다.
지속적 통합은 개발팀이 더 빠르게 반복하고 더 나은 소프트웨어를 사용자에게 제공할 수 있도록 돕지만, 기업이 프로세스를 최적화하기 위해 취할 수 있는 추가 단계도 있습니다. 일반적으로 구현되는 CI 관행에는 다음이 포함됩니다.
통합된 중앙 집중식 코드 베이스를 통해 배포와 가시성을 간소화할 수 있습니다. 많은 조직에서는 소스 제어 관리를 사용하여 제품 빌드와 연결된 모든 파일을 추적하고 제어하는 단일 리포지토리를 유지 관리합니다.
조직은 개발자가 하루에 한 번 이상 기본 개발 스트림에 변경 사항을 커밋하도록 요구하여 작업 복사본이 일치하는지 확인함으로써 일관성 있는 문화를 만들 수 있습니다.
빌드 스크립트를 최적화하고, 작업을 병렬화하고, 캐싱 메커니즘을 사용하면 빌드 시간을 단축할 수 있습니다. 팀은 또한 CI 파이프라인을 구성해 새로운 통합을 반복 과정 초기에 검증할 수 있습니다. 이러한 사전 대응적 접근은 개발자가 문제를 신속히 해결하고 디버깅에 드는 시간을 줄이는 데 도움을 줍니다.
최종 프로덕션 환경과 최대한 유사한 테스트 환경을 구축하면, 테스트 결과가 실제 환경에서 소프트웨어가 어떻게 작동할지 정확히 반영하는 데 도움이 됩니다.
기능 플래그를 구현하여 새로운 기능의 릴리스를 제어하면 CI 시스템이 전체 생산에 영향을 주지 않고 불완전하거나 실험적인 기능을 기본 분기에 병합할 수 있습니다.
CI 파이프라인을 자주 검토하고 새로운 툴, 기술, 모범 사례를 반영해 업데이트하면, DevOps 팀은 파이프라인을 강화하고 프로젝트 요구에 따라 개발 관행을 개선할 수 있습니다.
TDD에서는 어떤 기능 코드도 구현하기 전에 테스트가 먼저 작성됩니다. 개발 및 제품 팀은 제품 사양을 함께 정의하고, 요구 사항을 코드 검증 항목 체크리스트로 변환하며, 개발자는 그 테스트를 충족하는 코드를 작성합니다. TDD 접근 방식은 팀이 고품질의 신뢰할 수 있는 코드 변경을 사전에 CI 파이프라인에 통합할 수 있도록 해줍니다.
지속적 통합 관행 그리고 더 넓은 의미에서 DevOps 프레임워크는 기업이 협업과 코드 통합을 간소화하고 지속적 전달 파이프라인을 유지할 수 있게 해줍니다. 이러한 방식은 소프트웨어 품질을 개선하고 소프트웨어 릴리스 프로세스를 가속화합니다. 최신 CI 툴에는 이러한 관행을 강화하고 가치를 높이는 다양한 신기술이 통합되어 있습니다.
예를 들어, 지속적인 통합 프로세스에서 인공 지능(AI)과 머신 러닝(ML)을 사용하는 것이 표준 개발 관행이 되어 가고 있습니다. AI 기반 툴은 개발자가 주요 개발 스트림에 영향을 미치기 전에 문제가 있는 코드를 자동적이고 자율적으로 식별하여 수정하는 자가 치료 시스템을 만드는 데 도움이 될 수 있습니다. ML 기반 CI 시스템은 코드 제출 및 수정 사항에 따라 맞춤형 테스트 케이스를 자동으로 생성하여, 개발자가 수동으로 코드 테스트를 만드는 데 소요되는 시간을 줄일 수 있습니다.
사이버 위협이 점점 더 정교해짐에 따라2 보안 관행을 소프트웨어 개발 프로세스에 직접 접목하는 개발자가 점점 더 늘어나고 있습니다. 이러한 '시프트-레프트(shift-left)' 보안 전략은 CI 프로세스를 포함한 개발 초기 단계에 보안 검사를 도입하여 배포 후가 아닌 코딩 중에 취약점을 포착할 수 있도록 합니다.
오늘날 Kubernetes와 더 넓은 컨테이너 관련 기술 에코시스템은 현대 IT 환경의 기반을 형성합니다. DevSecOps는 이러한 동적인 에코시스템과 함께 발생하는 보안 문제를 해결하기 위해 DevOps의 모든 단계에 보안을 통합합니다.
컨테이너는 애플리케이션 코드를 라이브러리 및 종속성과 함께 패키징하는 소프트웨어의 실행 단위로, 모든 컴퓨팅 환경에서 코드를 실행할 수 있도록 지원합니다. 또한 k8s 또는 kube라고도 하는 Kubernetes는 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 예약하고 자동화하기 위한 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다.
전통적으로 DevOps 팀은 보안 팀이 취약점을 식별하면 피드백을 받아 다음 앱 업데이트에서 코드 변경을 구현했습니다. 이제는 개발자가 컨테이너와 Kubernetes 클러스터를 보호하고, 소프트웨어 애플리케이션과 개발 프로세스 전반에 제로 트러스트 원칙을 적용하는 것이 기대되며, 이는 새로운 운영 패러다임을 반영합니다.3 DevSecOps 관행의 채택은 코딩과 소프트웨어 개발이 단순히 기능을 구축하는 것을 넘어 위험을 예측하는 과정이 되었음을 의미합니다.
서버리스 컴퓨팅과 클라우드 네이티브 아키텍처 또한 오늘날 DevOps 팀의 우선 과제입니다.
서버리스 컴퓨팅은 개발자가 서버나 백엔드 인프라를 프로비저닝하거나 관리하지 않고도 애플리케이션 코드를 구축하고 실행할 수 있게 해주는 앱 개발 및 실행 모델입니다. 서버리스 환경에서도 서버는 존재하지만, 전적으로 클라우드 서비스 제공업체(CSP)에 의해 관리됩니다. CI 파이프라인에서 서버리스 플랫폼은 개발자가 백엔드 인프라 문제에서 자유로워져 프론트엔드 코딩과 비즈니스 로직에 집중할 수 있게 합니다.
서버리스 컴퓨팅과 AI 애플리케이션이 확산됨에 따라 이벤트 기반 아키텍처(EDA)는 팀이 클라우드 컴퓨팅의 점점 더 복잡해지는 문제를 해결하는 데 핵심적인 역할을 합니다. EDA는 느슨하게 결합된 프론트엔드 시스템과 백엔드 시스템 간의 실시간 통신을 지원하여, 시스템이 독립적으로 작동하고 이벤트(시스템 내에서 발생하는 모든 변경 또는 작업)를 비동기식으로 처리할 수 있도록 지원합니다.
따라서 CI 파이프라인에서 개발자는 전체 애플리케이션에 영향을 주지 않고 개별 앱 구성 요소를 확장할 수 있으며, 이를 통해 팀은 보다 민첩하고 확장 가능한 코드베이스와 통합 프로세스를 만들 수 있습니다.
강력한 CI 파이프라인을 구축하려면 올바른 툴 선택, 빌드 및 테스트 워크플로 정의, 인프라 구성 등 세심한 계획과 설정이 필요합니다. CI 파이프라인은 코드베이스, 종속성(API 등), 인프라 변경 사항을 수용하기 위해 정기적인 유지 관리도 필요합니다.
그러나 CI를 구현하면 소프트웨어 개발 팀에 다음과 같은 다양한 이점을 제공할 수 있습니다.
CI 프로세스는 팀이 오류를 조기에, 때로는 코드 제출 후 몇 분 안에 해결할 수 있도록 합니다.
팀의 모든 구성원이 코드를 변경하고, 코드 변경을 병합하며, 코드 호환성 문제와 통합 오류를 식별할 수 있어 지식 공유가 간소화되고 동료 피드백을 통해 코드 및 소프트웨어 품질이 향상됩니다.
새로운 코드가 지속적으로 통합되기 때문에 팀은 대규모 코드 배치를 통합하고 테스트하는 데 소요되는 시간을 줄일 수 있습니다. 또한 CI 도구가 제공하는 가속화된 피드백 루프를 통해 개발자는 소프트웨어 업데이트와 신제품을 반복하여 최종 사용자에게 더 빠르게 제공할 수 있습니다.
코드 커밋이 잦다는 것은 이해하고, 검토하고, 테스트하기 쉬운 소규모의 점진적인 변경이 많다는 것을 의미합니다. 이렇게 하면 개발을 진행하면서 코드 베이스에 중대한 문제가 발생할 위험이 줄어듭니다.
온프레미스, 클라우드 또는 메인프레임의 모든 애플리케이션에 대한 소프트웨어 제공을 자동화합니다.
DevOps 소프트웨어 및 도구를 사용하여 여러 장치 및 환경에서 클라우드 네이티브 앱을 구축, 배포 및 관리합니다.
IBM Cloud 컨설팅 서비스를 통해 새로운 역량을 개발하고 비즈니스 민첩성을 향상하세요. 하이브리드 클라우드 전략 및 전문가 파트너십을 통해 솔루션을 공동으로 개발하고, 디지털 혁신을 가속화하고, 성능을 최적화하는 방법을 알아보세요.