www.redhat.com/ko www.facebook.com/redhatkorea 구매문의 080-708-0880 [email protected]비즈니스 성공에 있어 변화에 대응하는 능력이 점점 더 중요해지고 있습니다. 새로운 혁신적인 기업은 시장에 진입하고, 획기적인 기술의 등장으로 고객의 기대치가 뒤바뀜에 따라 조직은 그 어느 때보다 단축된 사이클로 비즈니스 계획을 변경해야 합니다. 현대적인 소프트웨어 아키텍처와 프로세스를 통해 조직은 이러한 변화를 효과적으로 처리하고 시장의 선두주자로 부상할 수 있습니다. 애자일(AGILE) 통합이라는 새로운 아키텍처 프레임워크는 컨테이너, 분산형 통합, API(애플리케이션 프로그래밍 인터페이스)라는 세 가지 중요한 아키텍처 기능을 통합합니다. 이 프레임워크는 이러한 핵심 기능을 통해 조직 내에서 민첩성을 향상하고 새로운 프로세스를 추진함으로써 경쟁 우위를 점할 수 있도록 합니다. 여행, 숙박 등의 산업이 새로운 비즈니스 방식을 통해 변화하였으며, 이제 새로운 서비스가 제공되어 소비자가 색다른 방법으로 서비스와 상호 작용하게 되었습니다. 이러한 혁신적인 변화의 동향은 신기술의 등장과 비즈니스- 고객 간 상호 작용 방식에 대한 새로운 사고방식의 출현에 힘입어 금융 서비스 기업부터 공공기관에 이르기까지 주요 산업 전반으로 확산되고 있습니다. 또한 이러한 변화는 기존 조직에게 자사의 IT 기술을 근본적으로 혁신하여 새로운 서비스를 제공해야 한다는 압박감을 기존 조직에 안겨주고 있습니다. 최신 동향에 발맞춰 나가기 위해서 조직은 계획을 수립하여 소프트웨어 시스템을 신속히 변경할 수 있어야 합니다. 오늘날의 빠른 속도에 맞춰 소프트웨어를 제공하려면 조직에 애자일 인프라 기반이 필요합니다. 이 맥락에서 애자일은 애자일 소프트웨어 개발을 의미하지 않으며 전통적인 의미, 즉 유연하고 빠르게 움직일 수 있는 능력을 말합니다. 그림 1. 애자일 정의 1 옥스포드 영어 사전 light on one’s feet( ) light-footed ( ) fleet-footed ( ) limber ( ) supple ( ) lithe( ) nimble( ) acrobatic ( ) : 1 ag • ile, ‘aj l/ e 애자일(AGILE) 통합: 엔터프라이즈 아키텍처를 위한 청사진 저자: Steve Willmott, David Codelli 편집: Deon Ballard E-BOOK
17
Embed
E-BOOK 애자일(AGILE) 통합 - redhat.com · 일반적으로 인프라 계획은 수 년에 걸친 장기적인 접근 방식을 취합니다. 다년간의 계획을 수립하려는
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
3www.redhat.com/ko E-BOOK 애자일 통합: 엔터프라이즈 아키텍처를 위한 청사진
산업 전통적인 서비스 혁신적인 기업 영향
운송 택시, 대중 교통 Uber, Lyft 현지의 소규모 회사에서는 따라하기
힘든 일관된 고객 경험 창출
자산 관리 투자 회사 펀드 자동화 자금 관리에 있어 개인의 역량이
아니라 알고리즘이 차별화 요소가 됨
소매 오프라인 쇼핑 Amazon 쇼핑 방식이 오프라인 쇼핑에서
온라인 구매로 변화
검색 엔진 Google, 브라우저
기반 검색
음성 검색 Google의 주요 시장 채널에 영향을
미치고 새로운 기업이 시장에 진입할
수 있게 됨
스타트업 기업과 혁신적인 기업이 가진 장점은 인프라, 팀, 애플리케이션, 아키텍처 및 배포 프로세스까지
자유롭게 구성할 수 있다는 점입니다. Rachel Laycock이 '레거시 피플(legacy people)'4이라고 표현한
것 처럼 레거시 인프라에 발이 묶여 있지 않기 때문에 이들 기업은 혁신적인 아이디어를 생각해내는 것을
넘어서 아이디어를 실현할 수 있고 민첩하게 행동할 수 있습니다.
이들 조직은 새로운 것을 구축할 수 있는 능력이 있을 뿐 아니라 변화에 바로 적응할 수 있는 시스템도
구축할 수 있습니다. 소프트웨어 인프라는 이들이 다른 기업과 차별화되는 요소 중 하나이며, 변화하는
시장의 요구에 따라 시스템의 거의 모든 부분을 교체, 업데이트, 제거할 수 있습니다. 스타트업 기업 일부는
적응력이 아직 제대로 갖춰지지 않아 어려움을 겪기도 하지만 우수한 조직은 어떤 경우에도 기업 스스로
변화하는 능력을 유지합니다.
과제를 해결하는 역량
급변하는 환경에서 성공하려면 전체 IT 인프라가 애자일 방식으로 작동해야 합니다.
다음과 같이 두 가지 측면에서 변화가 일어나야 합니다.
• 아키텍처 설계에서 팀 커뮤니케이션에 이르기까지, 조직적이고 문화적인 차원에서 애자일 프로세스를
지원해야 합니다.
• 기술 인프라에서 기능을 신속하게 업그레이드, 추가, 제거할 수 있는 능력이 창출되어야 합니다.
기술적 변화와 문화적 변화가 민첩성을 실현하는 것이 아니라 민첩성을 위한 기반이 됩니다.
eBay의 제품 관리자인 Marty Cagan은 스스로 세금이라 칭하는 개념을 모든 프로젝트에 적용합니다.
즉, 매일 수행되는 일반적인 프로젝트에서 어느 정도의 시간과 리소스를 확보하여 신규 인프라 프로젝트에
투입하는 것입니다.5 이렇게 함으로써 신규 프로젝트와 혁신을 최우선순위로 삼을 수 있습니다.
"민첩성을 기반으로 고객에게 지속적으로 서비스를 제공하기
위해서는 참여 시스템(SoE: System of Engagement)과 레코드 시스템(SoR: System of Record) 간의 인터페이스가
확장성뿐 아니라 적응성 측면에서도 민첩성을 구현해야 합니다. 예를
들어 기존 API에 새로운 속성을 추가하거나 향후
더 많은 컨텍스트를 제공할 수 있어야
합니다."
HENRY PEYRET,
THE FORRESTER GROUP
Peyret, Henry. 'TechRadarTM: 통합 기술, 2015년 2분기'
Forrester Research, Inc. 2015년 6월 23일.
4 Rachel Laycock, '지속적 제공(Continuous Delivery)', 오후 세션, Red Hat Summit – DevNation 2016. 2016년 7월 1일, 캘리포니아주 샌프란시스코. https://youtube.com/watch?v=y87SUSOfgTY
5 Cagan, Marty, '인스파이어드(Inspired): 고객에게 사랑받는 제품을 만드는 방법(How to Create Products Customers Love)' Wiley Press, 2017
6www.redhat.com/ko E-BOOK 애자일 통합: 엔터프라이즈 아키텍처를 위한 청사진
ESB를 사용하려면 팀은 개발 및 운영 환경에서 사용하고 있는 툴 외에 전체 라이프 사이클에서 ESB 툴을
사용해야 합니다. 이러한 제한으로 인해 운영에서 효율성이 떨어지고 여러 가지 문제와 오류가 발생하기
쉬워집니다.
메시징을 통해 통합 강화
분산형 통합은 그 구조상 통합을 마이크로서비스로 다루며 컨테이너화가 가능하고 로컬에 쉽게 배포할 수 있을 뿐 아니라 릴리스 사이클도 매우 짧습니다.
통합 기술은 이러한 경량의 마이크로서비스 기반 아키텍처를 지원할 수 있어야 합니다. Red Hat® JBoss® Fuse를 사용하면 사용자가 통합을 코드로 처리할 수 있으며 컨테이너를 포함한 모든 곳에서 이를 실행할 수 있습니다.
또한 JBoss Fuse는 Red Hat JBoss AMQ와 번들링되어 메시징 인프라를 제공합니다. 강력한 메시징 인프라를 통해 시스템 간에 이벤트와 데이터가 효과적으로 라우팅될 수 있습니다. 메시징은 비동기식 특성을 가지고 있어 종속성을 필요로 하지 않기 때문에 마이크로서비스 기반의 중요한 구조적 툴이 됩니다.
통합과 메시징을 결합하여 더 효과적인 라우팅, 여러 언어 및 프로토콜 지원, 비동기적 처리량, 데이터 관리 향상을 통해 통합 아키텍처의 전반적인 성능을 향상시킬 수 있습니다.
동향에 발맞추기
컨테이너 도입률은 점점 높아지고 있습니다. 그렇다면 어느 정도로 높아지고 있을까요? 그리고 그 이유는 무엇일까요? 451 Research에 따르면 컨테이너는 시장에서 250% 성장할 것이라 예측합니다.7 단, 이는 컨테이너 배포가 아닌 사용에 해당하는 수치입니다. 실제 컨테이너 배포는 측정하기가 더 어렵습니다. Red Hat의 의뢰로 실시된 Bain 설문조사 결과에 따르면, 현재 약 20%의 고객이 프로덕션 환경에서 컨테이너를 배포하고 있으며 개발 및 테스트 환경에서도 거의 동일한 비율로 배포하고 있지만, 30% 이상의 고객은 컨테이너를 평가하고 있거나 기술검증(POC)을 실행하고 있는 것으로 나타났습니다.8
컨테이너를 사용한다는 것이 어떤 의미인지에 관해 명확하지가 않은 상황입니다. 기업 프로젝트에서 컨테이너를 도입하는 패턴은 대략 네 가지입니다. 일반적인 개발 또는 배포 플랫폼으로 사용하거나, 클라우드 네이티브 또는 마이크로서비스 플랫폼으로 사용하거나, 하이브리드 클라우드 내에서 사용하거나, 혁신적인 프로젝트를 위해 사용하는 것입니다.9 컨테이너를 어떻게 사용하고 있는가에 따라 컨테이너 채택 방식이 달라질 수 있습니다.
애자일 통합에서는 기존 운영을 지원할 수 있는 인프라 플랫폼을 구축하는 것이 핵심입니다. 모든 구현 패턴에서 플랫폼을 차용할 수 있으나 그 핵심을 보면 신규 프로젝트와 기존 서비스 모두를 위한 기반이 되는 플랫폼으로 작동합니다.
7 클라우드 지원 기술 모니터 리포트에 따른 451 Research 인포그래픽, 2017년 1월. https://451research.com/images/Marketing/press_releases/Application-container-market-will-reach-2-7bn-in-2020_final_graphic.pdf
8 Bain 설문조사: 전통적인 기업에서 디지털 트랜스포메이션을 실현하는 방법과 컨테이너의 역할, 2016년 11월. https://www.redhat.com/ko/resources/path-digital-containers
7www.redhat.com/ko E-BOOK 애자일 통합: 엔터프라이즈 아키텍처를 위한 청사진
컨테이너
가상화, 클라우드, 컨테이너는 모두 유사한 기술로서 그 목표도 비슷합니다. 이러한 기술은 물리 서버와
별개로 소프트웨어 운영 환경을 추상화하여 하드웨어에 더 많은 인스턴스를 스택할 수 있도록 하고 가용성,
확장성을 제공하며 효과적인 배포가 가능하게 하지만 서로 다른 방식으로 과제를 해결합니다. 가상화는
운영 시스템 레이어를 추상화합니다. 클라우드는 영구적이며, 전용 서버 인스턴스라는 개념을 사용하지
않습니다. 컨테이너는 단일 애플리케이션을 실행하기 위한 라이브러리와 운영 체제의 적절한 버전을
정의합니다.
컨테이너 기술에 기반을 둔 경량의 규범적인 접근 방식을 통해 컨테이너는 현대적인 소프트웨어 환경에
이상적인 툴이 되었습니다. 각 인스턴스는 운영 체제에서 컨테이너에 포함된 각 라이브러리의 정확한
버전에 이르기까지 불변의 정의를 사용합니다. 이로써 각 인스턴스에 대해 환경을 반복적으로 일관성있게
유지하므로 지속적 통합과 지속적 제공(CI/CD) 파이프라인에 적합합니다. 이뿐만 아니라 컨테이너
이미지는 단일 애플리케이션에 필요한 요소만 정의하기 때문에 컨테이너가 마이크로서비스와 일치하고
컨테이너 오케스트레이션은 대규모 마이크로서비스 인프라의 배포와 관리를 오케스트레이션할 수
있습니다.
경량성과 반복성의 결합은 컨테이너가 애자일 통합에 적합한 기술 플랫폼이 되도록 합니다.
전통적인 통합 접근 방식에서는 ESB가 인프라의 주요 지점에 배치된 고도로 중앙 집중화된 구조가
사용되었습니다. 분산형 통합 및 API 관리에서는 분산된 아키텍처를 통해 특정 위치 또는 팀에 필요한
기능을 배포할 수 있습니다. 컨테이너는 불변의 특성 때문에 전체 환경에서 이미지와 배포가 일관되게
유지되어 두 접근 방식을 위한 기본 플랫폼으로 동작하므로 불투명한 종속성이나 충돌 없이 빠르게
배포하거나 교체할 수 있습니다.
통합을 사용하든 API를 사용하든 배포 아키텍처의 핵심은 복잡한 승인 프로세스 없이 새로운 서비스를
설계하고 배포할 방법이 있어야 한다는 것입니다.
컨테이너를 사용하면 분산형 통합과 API를 마이크로서비스로 다룰 수 있습니다. 개발팀과 운영팀
모두를 위한 공통된 툴링을 제공하고 관리형 릴리스 프로세스와 함께 신속한 개발 프로세스를 사용할
수 있습니다.
"흔히 디지털 트랜스포메이션이라
불리는 새로운 경쟁의 장에서 기업은 IT
아키텍처를 재고하고 온프레미스 인프라와 클라우드 전반에서
워크로드를 재분산하며 상호운영을 통해
비즈니스 전략과 운영을 지원할 수 있어야 합니다. 이 모든 변화를 위해서는 통합에 대한 새로운 접근
방식, 즉 '하이브리드 통합'이 필요합니다."
CARL LEHMANN,
451 GROUP
Carl Lehman, 451 Research, '새로운 하이브리드 통합 플랫폼
시장에서 iPaaS와 API의 혁신적인 역할'. 2017년 7월.
https://451research.com/report-long?icid=3862.
컨테이너에는 오케스트레이션 필요
마이크로서비스가 별도의 단일 기능을 나타내는 것처럼 각 컨테이너는 단일 서비스 또는 애플리케이션을 나타냅니다. 마이크로서비스 아키텍처에는 수십 개에서 수백 개에 이르는 개별 서비스가 있을 수 있으며 이는 개발, 테스트, 운영 환경 전반에 걸쳐 복제됩니다.
이렇게 많은 수의 인스턴스가 있기 때문에 인스턴스를 오케스트레이션하고 고도화된 관리 태스크를 수행하는 능력은 효과적인 컨테이너 환경을 위해 반드시 필요합니다.
Red Hat OpenShift는 Docker 컨테이너를 Google의 Kubernetes 오케스트레이션 프로젝트와 결합하며 인스턴스 관리, 모니터링, 로깅, 트래픽 관리, 자동화 등의 중앙 집중식 관리를 포함합니다. 이는 컨테이너만 있는 환경에서는 거의 제공하기 어려운 기능입니다.
또한 Red Hat OpenShift는 셀프 서비스 카탈로그, 인스턴스 클러스터링, 애플리케이션 지속성, 프로젝트 수준 격리와 같이 개발자에게 친숙한 툴을 제공합니다.
이러한 결합을 통해 특히 안정성과 테스트라는 운영 요구 사항 그리고 간편한 사용과 신속한 제공이라는 개발자 요구 사항 간에 균형을 이룰 수 있습니다.
9www.redhat.com/ko E-BOOK 애자일 통합: 엔터프라이즈 아키텍처를 위한 청사진
적합한 API 플랫폼을 통해 개발자 효율성 증대
API의 강점은 내부 개발자와 외부 사용자가 모두 사용할 수 있다는 데 있습니다. Red Hat 3scale API Management Platform은 모든 사용자를 위한 툴을 제공합니다. 또한 개발자에게는 개발자 포털을 제공하여 협업을 통해 API를 개발할 수 있고 관리 포털을 통해 이러한 API를 게시할 수 있습니다.
3scale API Management Platform은 인증을 제공하고 주요 클라우드 제공업체와 통합하며 컨테이너 내에서 실행하여 외부에서 API를 사용할 수 있게 합니다.
API 전략에는 퍼블릭 API를 위한 API 설계가 결합되어 있습니다. 3scale API Management Platform, 특히 컨테이너 플랫폼상에 구축된 3scale은 이러한 전략을 이행하기 위한 수단을 제공합니다.
12www.redhat.com/ko E-BOOK 애자일 통합: 엔터프라이즈 아키텍처를 위한 청사진
분산 하이브리드 클라우드 환경에는 문제의 백엔드 시스템이 다양한 물리적 위치에 다수 존재할 수
있습니다. 로컬 요구를 충족하기 위해 인접한 로컬 시스템을 통합하면 주요 비즈니스 로직이 포함된 단일
중앙 통합 시스템을 통해 모든 것을 라우팅하는 것보다 높은 효율성과 보안을 실현할 수 있습니다.
애자일 조직과 문화
인프라의 라이프 사이클은 소프트웨어 개발이나 운영의 라이프 사이클과는 매우 다릅니다. 개발
사이클에서는 하나의 프로젝트를 완료한 후 다음 프로젝트로 이동하게 되며, 제품을 얼마나 빨리
출시하느냐 또는 주어진 시간에 기능을 얼마나 많이 생성하느냐가 효율성의 기준이 됩니다. 유지관리와
안정성이 중시되는 운영 사이클에서도 보안 패치와 업데이트를 적용하거나 새로운 서비스를 배포하거나
변경 사항을 보다 신속하고 효율적으로 롤백하는 것이 여전히 큰 이점을 가져다줍니다.
하지만 인프라에는 상당히 다른 접근 방식이 있습니다. 인프라는 고도로 전문화된 여러 그룹이 많은 시간을
들여 구축하는 것이 대부분이며 다기능팀(Cross-Functional Team)이 특정 소프트웨어 엔지니어링
프로젝트를 진행하는 것과는 매우 다릅니다. 인프라 프로젝트는 일반적으로 소프트웨어 프로젝트보다
규모가 훨씬 크며 릴리스 사이클이 짧을 경우 많은 성과를 내는 것이 불가능해질 수 있고 불완전한 상태로
남겨질 수 도 있습니다. 엔터프라이즈 IT 전문가인 Andrew Froelich는 InformationWeek에서 인프라가
특히 하드웨어와 데이터센터와 관련하여 귀환 불능 지점이라는 제약을 가진다고 밝힌 바 있습니다. 퍼블릭
클라우드의 경우에도 더 이상 프로젝트를 폐기하고 다시 시작할 수 없는 지점이 존재합니다.10 인프라는
영구적입니다. 하지만 인프라 성능에 관해 방법론을 조정할 수 있습니다.
애자일 및 DevOps와 같은 응답성 높고 반복적인 프로세스를 통해 개발팀과 운영팀은 큰 이점을 얻을 수
있는 반면 인프라팀은 그렇지 않습니다. 하지만 Froehlich의 애자일 인프라 찬반 양론 분석에서는 한 가지
중요한 측면이 빠져 있습니다. 바로 인프라팀을 개발팀과 운영팀에 연계하는 일입니다. Rohan Pearce는
CIO에 인프라팀을 기능팀이 아니라 애자일 스타일의 워크셀로 바꾸어야 한다고 저술한 바 있습니다.11
Telstra Enterprise Services팀은 시스템을 점검하거나 업데이트를 수행하는 프로세스가 너무 번거롭고
복잡하기 때문에 개발자 그룹이 내부 시스템을 무시하도록 했습니다. 이렇게 실무 그룹을 조정함으로써
사이클을 212일에서 42일로 단축할 수 있었습니다.12
이 예는 인프라팀이 내부 그룹을 더 효과적으로 지원하는 데 프로세스 변화가 얼마나 중요한 역할을
하는지 보여줍니다.
애자일 통합 기술은 보다 민첩한 인프라를 뒷받침하며 API, 컨테이너 이미지, 분산형 통합은 소프트웨어
인프라 언급에서 새로운 주제로 부상했습니다.
10 Froehlich, Andrew, '애자일 IT 구현에 관한 찬반 양론'. 2015년 10월 6일. http://www.informationweek.com/infrastructure/pc-and-servers/should-it-go-agile-the-pros-and-cons/d/d-id/1322448
15www.redhat.com/ko E-BOOK 애자일 통합: 엔터프라이즈 아키텍처를 위한 청사진
애자일 원칙을 인프라 계획에 적용
대부분의 변경 관리 접근 방식에서는 모든 하위 시스템을 종합적으로 문서화해야 합니다. 이 문서는 모니터링 방법에서 성능 매개 변수 그리고 담당 팀에 이르기까지 시스템의 모든 측면을 상세하게 다루어야 합니다. 애자일 원칙에서는 협력과 적응성이 요구되며 이는 많은 문서화 작업을 필요로 하는 변경 관리와 충돌합니다.
잠재적인 이해 관계자, 변경 사항, 시스템 구성 요소 전체를 규범적으로 정의하려 할 것이 아니라 변경 요청과 계획을 평가하는 데 사용할 수 있는 일련의 지침과 표준을 정의해야 합니다. 다음 질문에 대한 답을 생각해 보십시오.
• 사용자를 위해 설계된 엔드 투 엔드 환경은 무엇인가?
• 각 팀, API, 시스템 등이 시간이 지남에 따라 이러한 환경을 개선하기 위해 어떻게 기여하고 있는가?
• 모니터링과 경고는 어떤 매개변수로 어떻게 정의되며 서비스 수준을 어떻게 유지하는가?
• 작동이 제대로 되는지 확인하기 위해 어떤 유형의 자동화된 테스트가 필요한가?
• 사용자 환경을 방해하지 않으면서 팀이 자체 하위 시스템의 새 버전을 테스트하고 배포하기 위한
릴리스 파이프라인은 무엇인가?
• 구성 요소 서비스의 장애가 전체 시스템의 서비스 수준에 어떤 영향을 미치는가?
애자일 인프라 내에서의 변경 관리는 계약보다는 지속적인 협력을 통해 이루어져야 합니다.
목표를 달성할 확률
귀사의 IT 프로젝트가 성공할 가능성은 어느 정도일까요? 먼저 사양을 충족하는 것, 고객 채택률을 높이는 것, 출시를 완료하는 것 등 성공의 기준을 파악하는 것이 중요합니다. 프로젝트 관리 교육을 전문으로 하는 그룹인 4PM은 예산 범위 내에서 사양에 맞게 정시에 프로젝트를 완료하는 것을 성공이라 정의합니다.13 이러한 정의를 기반으로 이 그룹은 IT 프로젝트의 약 70% 정도는 실패한다고 추정합니다.13 이러한 수치에 변화가 일어나고 있습니다. 최근에 실시된 Project Management Institute 설문조사에 의하면 지난 5년간 계획한 목표를 달성한 프로젝트의 수가 증가했음이 밝혀졌습니다.14 이렇게 수치가 증가한 것은 IT팀과 실무팀이 밀접하게 연계되어 자사의 전략에 대해 그리고 고객에 대해 더 나은 정보를 활용할 수 있기 때문이라고 합니다.8
이렇게 전략적 연계를 구축하는 이유 중 하나는 애자일 팀을 구현하는 것입니다. 애자일 방식은 협력과 피드백, 시스템과 문제에 대한 전체적인 시각 및 창의적인 접근 방식을 권장합니다.
13 4PM.com, '프로젝트가 자주 실패하는 이유'. 2015년 9월 27일. http://4pm.com/2015/09/27/project-failure/
14 Florentine, Sharon, 'IT 프로젝트의 성공률, 마침내 증가하다.' 2017년 2월 27일. https://www.cio.com/article/3174516/project-management/it-project-success-rates-finally-improving.html
Red Hat은 세계적인 오픈소스 솔루션 공급업체로서 커뮤니티 기반의 접근 방식을 통해 신뢰도 높은 고성능 클라우드, Linux, 미들웨어, 스토리지, 가상화 기술을 제공합니다. 또한, 전세계 고객에게 높은 수준의 지원과 교육 및 컨설팅 서비스를 제공하여 권위있는 어워드를 다수 수상한 바 있습니다. Red Hat은 기업, 파트너, 오픈소스 커뮤니티로 구성된 글로벌 네트워크의 허브 역할을 하며 고객들이 IT의 미래를 준비하고 개발할 수 있도록 리소스를 공개하여 혁신적인 기술 발전에 기여하고 있습니다.