클라우드

블로그 | '위원회에 의한 클라우드 아키텍처'가 여전히 나쁜 아이디어인 이유

David Linthicum | InfoWorld 2022.05.25
구글에서 “위원회에 의한 디자인(Design by committee)”을 검색해보라. 좋은 것은 하나도 볼 수 없을 것이다. 이 문구는 수많은 디자이너가 참여했으나 공통된 계획이나 비전이 없는 프로젝트를 비웃는 표현이다. 

필자는 최근 클라우드 아키텍처에서 이런 식의 접근법을 자주 보는데, 사실 결과물이 엉망진창이다. 코로나19 팬데믹 때문에 사람들이 원격으로 참여해야 하기 때문인지, 아니면 중요한 의사결정을 맡길 만한 기술력있는 사람이 부족해서인지 알 수 없다.
 
ⓒ Getty Images Bank

IT 경력이 오래된 사람은 아키텍처 조정 위원회를 기억할 것이다. 서로 다른 부서, 즉 보안이나 데이터베이스, 개발 등의 책임자들이 모인 그룹으로, 함께 모여서 모두가 동의할 수 있는 총체적인 아키텍처를 결정하는 역할을 한다.

아이디어는 논리적으로 보인다. 사람들이 계획을 따르도록 하려면, 계획을 세우는 데 참여시키는 것이 좋다. 하지만 이렇게 구성한 위원회가 만든 기술 전문 용어의 뒤범벅은 나중에 바로잡는 데 수백만 달러가 들기에 십상이다. 

왜 이런 일이 일어날까? 서로 다른 구상과 그 구상에 편중된 서로 다른 기술이 원인이다. 보통 이런 위원회는 비즈니스 요구사항 같은 아키텍처의 총체적인 목표를 생각하지 않는다. 대신에 자신의 요구사항을 둘러싼 전술적인 문제에 집중한다. 위원회를 달래기 위해서는 각 구성원에게 요청 권한이 주어져야 하고, 선택한 기술이 각자에게 나쁘지 않아야 한다. 이렇게 설계된 아키텍처는 기술을 모아 놓으면 제대로 동작하지 않았으며, 구축하는 데 수백만 달러, 실패해서 고치는 데 수백만 달러가 들었다.

필자로 이런 혼란의 도가니 속에 있었고, 당시의 기억은 아직도 아프게 남아있다. 짧지만 정신과 치료를 받아야 했지만, 위원회 디자인이 나쁜 아이디어라는 것을 여실히 깨달았고, 이후에는 자리를 내놓을 각오로 격렬하게 반대했다.

오늘날은 사공이 많으면 배가 산으로 간다는 것을 다들 잘 알고 있는 편이다. 작고 결속력 강한 팀을 마스터 아키텍트가 이끌 때 성공한다는 것을 알게 됐다. 이런 팀은 모든 비즈니스 요구사항을 고려하며, 비즈니스 요구사항만을 기준으로 최적화된 클라우드 기술 스택을 고른다.

이런 의사결정을 중앙집중화하는 것은 완전히 민주적이지는 않겠지만, 보통은 더 나은 결과물, 더 빠른 의사결정, 더 나은 배치로 이어진다. 의사결정은 여전히 정치적인 영향을 받지만, “위원회에 의한 디자인을 원합니까?”라고 한마디 하면 한 걸음 물러설 것이다. 

앞서 언급한 것처럼 아키텍처 조정 위원회가 부활해 클라우드 컴퓨팅 기술을 고르고 배치하는 것으로 보인다. 원격 근무와 부족한 기술 인력이 주된 원인일 것이다. 그래서인지 많은 기업이 투표로 기술을 선정하는 브레인 트러스(Brain Trust) 모델을 바뀌고 있다.

필자는 기업이 엄청난 어려움을 겪고 큰 실수를 바로잡느라 고생하기 전에 경고하고 싶다. 위원회는 여전히 나쁜 아디이어이다. 필자를 믿어주기 바란다. 나중에 가서 “내가 말했잖아”라는 말은 하고 싶지 않다.
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.