AI 시대, 아키텍처 리뷰 보드(ARB)의 역할과 변화

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기]

엔터프라이즈 아키텍트팀이 아키텍처 리뷰 보드(Architecture Review Board, ARB)를 처음 만날 때 불안했던 기억이 납니다. ARB는 새로운 시스템과 애플리케이션 아키텍처에 대한 계획을 검토합니다. 필자의 프레젠테이션은 템플릿을 따라야 했고 프레젠테이션 전에 리뷰 보드의 인프라 및 보안 책임자의 검토를 받아야 했습니다. CIO가 기술 플랫폼을 선택하고 도입했기 때문에 사용에 문제가 없을 것으로 예상했지만, 필자의 팀은 여전히 기술과 비즈니스 요구사항에 대해 배우고 있었습니다. 기껏해야 애자일 개발 프로세스를 통해 다듬고 개선할 수 있는 개념적인 아키텍처를 가지고 있었습니다. 아키텍처는 승인되었지만, 엔터프라이즈 아키텍트들이 아키텍처를 발전시키기 위해서 더욱 민첩한 접근 방식에 적응하려면 약간의 창의성이 필요했습니다.

시대에 뒤떨어진 아키텍처 리뷰 보드

필자는 요즘에도 리더들이 아키텍처 리뷰 보드와 그 프레젠테이션 과정을 이야기할 때면 몸서리를 칩니다. 분명히 말하지만, 리뷰 보드는 중요합니다. 그러나 요즘의 더 빠르고 민첩한 개발 프로세스를 위해서는 미션, 프로세스 및 툴을 현대화해야 합니다. 또한 ARB와 엔터프라이즈 아키텍트는 구현 트레이드오프에 대해 의견을 제시하고 특정 이니셔티브에 필수적인 비기능적 요구사항을 정의함으로써 디지털 트랜스포메이션을 향상할 수 있는 많은 기회가 있습니다.

Quickbase의 CIO 달란 윈부쉬(Dalan Winbush)는 “과거에 아키텍처 리뷰 보드의 역할은 훨씬 독재적이었으며, 일률적인 철학에 따라 대규모 조직을 대신해 결정을 내리는 소규모 그룹이 이끌었다. 그러나 노코드/로우코드, 애자일, AI 기술을 통한 소프트웨어의 민주화가 ARB의 역할을 변화시키고 있다.”고 설명합니다. 아키텍처 리뷰 보드는 더욱 협력적이고 신속하게 대응할 것으로 예상됩니다. ARB는 거버넌스, 보안, 컴플라이언스, 데이터 관리, 연결성, 협업을 모두 고려하여 더 큰 비즈니스 목표를 위해 더 광범위하게 역할을 수행할 것입니다. 이러한 ARB의 책임에는 애플리케이션 개발 프로세스, 데이터, 전반적인 IT 인프라의 무결성을 보장하는 것이 포함될 것입니다.

2018년에 발표된 Open Group Architecture Framework(TOGAF) 버전 9.2에서는 조직 간 아키텍처 보드의 역할을 전략 실행을 감독하는 것으로 설명되어 있습니다. 여기에는 구성 요소 재사용을 목표 설정, 조언 제공, 갈등 해결 등 20가지 이상의 책임이 명시되어 있습니다. 그러나 “아키텍처와 관련된 모든 의사결정의 근거 제공”과 같이 나열된 책임 중 일부는 데브옵스 리더들을 움츠러들게 할 수 있습니다.

아키텍처 리뷰 보드에 대한 현대화된 접근 방식은 파트너십을 구축하고, 신뢰를 구축하며, 비즈니스 리더, 데브옵스팀, 컴플라이언스 부서 간의 협업을 모색하는 것에서 시작해야 합니다. 기업 내 모든 사람이 기술을 사용하고, 많은 사람이 아키텍처의 경계를 확장하는 플랫폼을 활용하는 것입니다.

윈부쉬는 데브옵스팀이 엔터프라이즈 아키텍트와 리뷰 보드를 포함하여 협업 범위를 확장해야 한다고 제안하면서, “ARB를 장애물로 보지 말고, 팀과 비즈니스를 보호하는 데 꼭 필요한 인사이트를 제공하는 신뢰받는 팀으로 생각해야 한다.”고 조언합니다.

아키텍처 리뷰 보드는 팀과 기업이 다음과 같은 경쟁적인 의제를 탐색하는 데 도움이 되는 이정표를 설정하는 데 특히 유용합니다.

• 더 빠른 혁신 vs. 더 안전한 규제 준수
• 실험 vs. 베스트 프랙티스
• 자기 조직화 vs. 신뢰할 수 있는 스탠다드

아키텍처 리뷰 보드의 역할과 잠재력에 관한 세 가지 시나리오를 살펴봅니다.

아키텍처 혁신과 기술 부채 최소화

마이크로서비스를 개발하는 기업들은 사용성, 안정성 및 지속적인 지원을 보장하기 위한 스탠다드를 어떻게 만들까요? 이러한 기업들이 포인트 솔루션 서비스, 문서화되지 않은 솔루션, 자동화된 테스트가 없는 API를 만들지 않으려면 어떻게 해야 할까요? 지나치게 많은 자율성을 부여하면 기술 부채와 서포트하기 어려운 마이크로서비스가 만들어질 수 있습니다.

또 다른 영역의 복잡성은 기업이 여러 CI/CD 툴을 지원하고 데브옵스팀이 자체 CI/CID 파이프라인을 생성하고 커스터마이즈하고, 서포트하도록 권한을 부여할 때 발생합니다. 시간이 지남에 따라 자기 조직화의 이점은 줄어들고 비용, 복잡성 및 기술 부채로 인해 개발 속도가 저하될 것입니다.

Cockroach Labs의 기술 에반젤리스트 롭 레이드(Rob Reid)는 “요즘 애플리케이션은 20년 전보다 더 복잡해졌다.마이크로서비스 아키텍처의 관리 복잡성을 클라이언트-서버 아키텍처와 비교해 보면 1시간 미만의 복원이 왜 점점 더 꿈같은 이야기인지 알 수 있다. 배포 파이프라인은 점점 더 비표준화되고 있고, 모든 팀은 최신 툴을 사용하여 자신만의 맞춤형 파이프라인을 신중하게 만들고 있다. 팀과 기술이 발전함에 따라 이러한 파이프라인과 기술에 대한 지식은 꿈과 함께 사라져 버린다.”고 합니다.

ARB는 기술 부채 지표를 정의하고, 자기 조직화된 표준을 홍보하고, 데브옵스팀이 베스트 프랙티스를 안내하여 복잡성을 피할 수 있도록 도움을 줄 수 있습니다.

위험 대응의 우선순위 결정과 간소화

IT팀은 한때 스프레드시트에서 위험 로그를 수집하여 위험 발생 가능성과 비즈니스에 미치는 영향에 따라 점수를 매겼습니다. 그런 다음 이 점수를 사용하여 대응 우선순위를 정했습니다. 오늘날, 위험을 파악하고, 우선 순위를 정하고 관리하는 것은 Jira와 Confluence의 Risk Register, ServiceNow의 Risk Management 같은 툴을 사용하여 애자일 개발 및 IT 관리 서비스에 통합될 수 있습니다.

하지만 통합 툴로는 우선순위를 평가하고 대응 비용을 최소화하는 솔루션을 파악하는 이슈를 해결하지는 못합니다. ARB는 때때로 위험 백로그에 대한 제품 관리자 역할을 하고, 때로는 구현을 감독하는 딜리버리 리더로서 중요한 역할을 담당할 수 있습니다.

SADA의 CTO 마일즈 워드(Miles Ward)는 다음과 같이 조언합니다. “적절한 권한이 부여되면, 리뷰 보드는 지속적으로 발전하는 최신 기술 -기술팀이 취하는 특정 조치로 어떻게 변환되는지-, 베스트 프랙티스, 규제 준수에 관한 광범위한 대화를 진행하면서 중재자로서 중요한 역할을 해야만 한다. 보안 침해나 초과 비용을 되돌아보고 이를 방지하는 방법에 대해 광범위한 지침을 제시하는 것은 쉽다. 실제로 부정적인 결과를 예방하는 구현을 예측하고 우선순위를 정하고 추진하는 것이 훨씬 더 어렵다. 이 어려운 문제를 해결하는 회사는 그렇지 않은 회사보다 더 나은 성과를 거둘 것이다.”

AI, 자동화 및 관찰 가능성 확대

데브옵스팀은 CI/CD, 코드형 인프라, 쿠버네티스 오케스트레이션을 비롯한 스캐폴딩 프로세스를 자동화하여 수고를 줄입니다. 코딩 코파일럿은 데브옵스팀이 코드를 요청할 수 있게 지원하는 반면, 자동화와 AI 에이전트는 IT 서비스 관리자가 인시던트와 요청에 대응할 때 더 나은 직원 경험을 제공할 수 있도록 돕습니다.

데브옵스가 자동화와 AI를 사용하여 생산성을 향상하는 상황에서, ARB는 어떻게 프레젠테이션, 스프레드시트, 수작업으로 만든 아키텍처 다이어그램을 주요 커뮤니케이션 툴로 계속 사용할 수 있을까요?

vFunction의 CEO 모티 라팰린(Moti Rafalin)은 “아키텍처 리뷰 보드는 애자일 환경에서 여전히 중요하지만, 실무자와의 인터뷰와 엔지니어링 속도를 저해하는 전통적인 툴 등의 수작업 프로세스를 넘어서 진화해야 한다."고 조언합니다. “개발을 향상하고 혁신을 지원하기 위해서는 AI 기반의 툴을 도입해야 한다. 실시간으로 아키텍처를 시각화, 문서화, 분석할 수 있으며, 일상적인 작업을 간소화하고, 앱 개발을 관리하여 복잡성을 줄일 수 있다.”

ARB를 위한 한 가지 기회는 관찰 가능성 스탠다드와 사이트 신뢰성 엔지니어링 툴을 도입하는 것입니다. 이 두 영역은 데브옵스팀을 운영 책임과 연결하는데, 이는 스탠다드, 거버넌스, 플랫폼을 통해 장기적인 비즈니스 가치를 제공할 수 있습니다.

라팰린은 덧붙였습니다. “아키텍처의 관찰 가능성과 거버넌스는 패러다임 전환을 의미한다. 이는 아키텍처를 사전 예방적으로 관리하고, 아키텍트가 마이크로서비스의 확산과 그로 인한 복잡성을 방지하기 위한 개발 가드레일을 설정할 수 있게 한다.”

지금은 아키텍처 리뷰 보드의 리브랜드 시점!

ARB가 있는 IT 조직이라면 협업과 신뢰를 의미하는, 더 매력적이고 개방적이며 포용적인 이름으로 리브랜드하는 것을 권고합니다. 포럼, 허브, 팀, 심지어 카운실과 같은 단어가 보드라는 단어보다 더 친근하게 다가옵니다. ‘review’라는 단어는 반응적이고 판단적인 프로세스를 암시하는 반면, ‘enablement, excellence, growth’와 같은 단어는 비즈니스팀, 데브옵스팀, 데이터 사이언스팀과의 협업 강화를 암시합니다.

비공식적으로 투표를 실시한 결과, '협업 아키텍처 허브(collaboration architecture hub)'라는 리브랜드가 가장 많은 표를 얻었습니다. 이러한 허브에 참여하는 엔터프라이즈 아키텍트들은 툴, 관행 및 사고방식을 현대화함으로써 더 많은 청중을 확보하고 결과를 개선할 수 있을 것입니다.

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.