기고 | 데브옵스로 ‘지속적 아키텍처’를 구현하는 3가지 방법

지속적 아키텍처(Continuous Architecture)는 시시각각 변화하는 기업 환경과 사용자 요구사항에 적응할 수 있는 유연성을 제공한다. 
 

애플리케이션 및 시스템을 개발하기 위해 소프트웨어 아키텍처 및 시스템 계발 계획을 장황하게 세워야 했던 때가 있다. 심지어 몇몇 기업에서는 전제 조건이었다. 시스템 설계자는 상위 레벨(high level)의 요구 사항을 검토하고, 회사의 표준을 고려하면서 소프트웨어 개발 프로세스에 사용할 플랫폼, 디자인 패턴 및 구성요소의 아키텍처를 모두 아우르는 다이어그램을 구상하곤 했다. 

새로운 기술이나 소프트웨어 구성요소가 필요한 경우를 대비해 좀 더 빈조한 플래닝을 채택한 기업도 있었다. 아키텍처 리뷰 보드(Architecture review board)라는 것을 만들어 의사결정을 더 투명하게 하고, 아키텍처의 리스크를 감지하고, 예산을 맞추며 지속 가능한 개발 방법에 영향을 미칠 수 있는 다른 모든 부분을 검토하고자 했다. 그러나 아키텍처 리뷰 보드의 효과성에도 의문이 제기되곤 한다. 개발 팀의 자율성을 저해하고, 개발 흐름을 방해하며 과도한 문서화를 초래할 수 있다는 지적이 있다. 

다른 한편에는 애자일(Agile) 개발 방식이 있다. 이 개발 방식은 지시된 계획을 따르기 보다 변화에 빠르게 대응할 수 있도록 자율성과 권한을 추구한다. 이는 ‘애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)의 핵심 가치이기도 하다. 하지만 기술 리더에게는 재활용 가능한 플랫폼, 명확한 개발표준과 지속 가능한 운영 모델이 필요할 수 있다. 효율성, 품질 안정성을 유지하면서도 기술 부채를 줄일 수 있어야 하기 때문이다.

이러한 간극을 지속적 아키텍처(Continuous Architecture)가 메울 수 있다. 지속적 아키텍처 선언(Continuous Architecture Manifesto)은 ‘기능이 구현되기 전 아키텍처가 거의 확정됐던 기존의 워터폴(Waterfall) 접근방식에서 지속적 런웨이(Continuous Runway)로의 전환’을 내세운다. 이 선언문의 원칙으로는 ‘프로젝트 솔루션뿐만 아니라 장기적 제품 설계’ 및 ‘구현을 통한 아키텍처 검증’ 등이 있다. 이러한 원칙은 클라우드 아키텍처를 개발하는 데 있어 데브옵스 베스트 프랙티스, 개념 증명 및 애자일 스파이크(Agile Spike)를 이용하려는 팀에게 특히 어울린다. 

필자는 선언문과 이의 베스트 프랙티스에 관한 인사이트를 얻고자 지속적 아키텍처의 소프트웨어 설계자 피에르 퓨리어를 질의했다. 그는 “지속적 아키텍처 접근방식은 애자일, 데브옵스, 클라우드 시대에 지속 가능한 소프트웨어 아키텍처를 구성하고 유지할 수 있는 입증된 경로를 제시한다. 품질 속성 요건에 집중하기, 아키텍처 결정 유도하기, 기술 부채 파악하기, 피드백 루프 구현하기 등 필수적인 방법론의 중요성이 강조된다”라고 대답했다.

개발 및 테스트 환경 구성을 자동화하라
지속적 아키텍처의 개발 및 테스트 환경을 구성하려면 IaC(Infrastructure as Code)를 자동화하는 것과 같은 기본적인 데브옵스 활동부터 시작할 수 있다. 자동화는 설계자가 추구하는 표준 구성과 패턴을 구축해놓는 데 도움이 되며 개발팀이 요구하는 민첩성을 제공한다.

기업용 자동화 샌드박스 소프트웨어 제공업체 콸리(Quali)의 제품 관리 부사장 아미르 로젠버그는, “애플리케이션을 제공하는 조직에게 즉시 사용 가능하며, 안정적이고 높은 표준 준수성을 갖춘 환경은 매우 중요하다. 그래야 지속적인 소프트웨어 제공 파이프라인을 유지할 수 있다”라고 말했다.

로젠버그는 설계자가 데브옵스 팀과 협력하여 클라우드 인프라의 청사진을 그려야 한다고 조언했다. 그는 “데브옵스 팀이 개발팀, 제품 관리자, 테스트 담당자, 사전 영업 등의 부서에 인프라 청사진을 모델화하여 제공할 필요가 있다. 그러면 이 부서들이 기다리지 않고 자급자족할 수 있는 클라우드 인프라를 이용할 수 있게 된다”라고 말했다.

빌드카이트(Buildkite)의 설립자 겸 공동 CEO 팀 루카스도 이에 동의했다. 그는 “지속적 아키텍처는 기술뿐만 아니라 문화적 측면에서 개발팀과 사업부 모두의 헌신을 필요로 한다”며 “개발자 경험에 집중하고 이를 담당하는 전담 역할”을 만드는 것을 제안했다. 개발팀이 코드 개발 및 테스트에 필요한 환경과 배치 파이프라인을 자급자족하는 환경을 조성해 개발자 경험을 개선할 수 있다”라고 그는 덧붙였다. 

프로덕션 아키텍처 정의 시 고객과 사용자의 요구를 모두 고려하라
데브옵스팀이 자동화로 생산성을 높이려 하는 것처럼, 프로덕트 매니저, 데이터 과학자, 표준 준수 담당자 등의 비즈니스 리더도 프로덕션 환경의 구조적인 민첩성을 추구한다. 이에 따라 사용자 요구에 따라 프로덕션 환경을 확장하거나 축소해야 하는 경우가 많다. 때로는 표준 준수 요건에 맞추어 여러 개의 환경을 구성해야 한다.

루카스는 프로덕션 환경에서 중요한 주요 디자인 원칙을 추가로 언급하면서 “지속적성을 위해서는 중단 현상을 줄여야 하기 때문에 실패 감소(failure reduction)에 투자하는 것이 좋다”라고 제안했다.

데이터 과학자에게는 통합 및 배치를 위한 요건이 소프트웨어 개발팀의 보편적인 요건과 다른 경우가 많다. 오픈소스 데이터 플랫폼 나임(KNIME)의 공동 설립자 겸 CEO 마이클 베트홀드는 “통합 중 구성된 데이터 과학 프로덕션 프로세스는 데이터 과학 팀이 만든 것과 다르며, 프로덕션 시 모니터링은 업데이트와 재배치를 자동으로 시작시킬 수 있다”라고 말했다.

사용량 및 인프라 모니터링은 스케일 업 혹은 다운 조치로 이어질 수 있다. 하지만, 모델옵스(Modelops) 모니터링은 구성 변화 또는 재배치의 시발점이 되기도 한다. 버트홀드는 데이터 사이언스와 머신러닝 파이프라인에 대해 “배치 사이클은 데이터 과학 프로세스를 점검하는 모니터링 프로세스에 의해 자동으로 작동될 수 있으며, 큰 변화가 감지되어야만 프로세스 전체가 다시 시작된다”라고 말했다.

아키텍처는 미래의 가능성에 집중해야 한다
비즈니스 리더는 단기적인 기회에 집중하려는 경향이 강한 반면, 데브옵스팀은 흔히 확장 가능한 모듈식 소프트웨어 구성요소를 개발하는 데 관심을 가진다. 지속적 아키텍처를 효과적으로 지원하는 환경을 조성할 수 있는 방법을 몇 가지 소개한다. 
 

• 클라우드 네이티브 및 서버리스(Serverless) 아키텍처로 개발하기
• 배치 파이프라인 표준화하기
• 지속적인 테스트 환경 지원하기
• 마이크로서비스 구축 및 API 라이프 사이클 지원하기
• 플랫폼이 사용자별 제각각인 솔루션을 간소화하거나 지양하도록 돕는 로우코드(Low-code) 솔루션 활용하기

기업 애플리케이션 통합(EAI) 업체 액스웨이(Axway)의 VP 겸 CITO 빈스 파두아는 개방형 아키텍처를 강조하며 “기업 간(B-2-B) 통합과 협업은 API와 클라우드를 기반으로 하는 디지털 전환을 가속할 것이다. 클라우드 네이티브 및 API 기반 접근방식은 OE(Open Everything) 아키텍처로 발전했으며, 더 적은 자원으로도 협업과 파트너십 중심의 혁신이 더 용이해졌다”라고 말했다. 

많은 기업이 현재 고객 경험, 통합, 디지털화된 워크플로우를 위한 사용자 맞춤형 소프트웨어에 투자하고 있으며, 베스트 프랙티스를 참고하여 미래 경쟁력을 확보해야 한다고 파두아는 말했다. 그는 “오늘날 기업 표면(enterprise surface area)이 API 중심적으로 변화하고 있다. 이에 따라 더 많은 혁신의 가능성이 열렸다. 산업 및 업종간 공급망을 언번들링(unbundling)하거나 리번들링(rebundling)함으로써다.  B2B용 여행, 물류, 창고 관리, 제조, 대출, 보험 및 부티크 소매 분야까지 상당한 투자 및 스타트업 성장의 기회가 시장에 도사리고 있다”라고 말했다.

지속적 아키텍처를 실제로 구현하려면 현재 기업의 요구사항과 데브옵스팀이 생산성을 유지하는데 필요한 요구사항 간의 균형을 맞춰야 한다. 또한 동시에 기업 미래의 변화, 확장, 그리고 앞으로 생길 새로운 요건을 지원할 수 있는 방식에 대한 비전이 있어야 한다. 따라서 설계자는 현재 아키텍처를 개발하는 팀이 언제든지 바뀔 수 있다는 점을 염두에 두고, 새로운 팀원이 쉽게 배울 수 있고 막힘없이 변경할 수 있는 코드로 구성된 빌딩 블럭 솔루션을 추구한다. 변화를 검증할 수 있는 테스트 범위가 충분한 것도 이런 솔루션의 중요한 요소다.

이렇듯 지속적 아키텍처는 재사용할 수 있는 개발 패턴의 필요성을 수용한 동시에 완벽한 청사진을 구상하는 것이 힘들다는 점도 감안하고 있다.  

*Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr