클라우드

IDG 블로그 | 클라우드 아키텍처 감사에 대응하는 올바른 자세

David Linthicum | InfoWorld 2021.08.02
필자는 누군가가 설계한 기업 클라우드 솔루션을 검토할 때 최선을 다한다. 누군가의 아기를 못생겼다고 말하는 것은 무례한 일이고, 아기가 못생긴 데는 충분한 이유가 있을지도 모른다. 필자는 절대 결론을 바로 내리지 않으며, 전체 그림을 이해할 때까지는 편견을 배제하려 노력한다.
 
ⓒ Getty Images Bank

선택한 기술의 중요성과 잠재적인 영향, 선택 이유, 어떻게 구성하는지 등이 어렴풋이 드러난다. 필자의 직업적 특성 상 꼭 써야 할 비용의 두 배를 쓰고 핵심 비즈니스 기능을 방해하는 비효율적인 클라우드 솔루션을 사용하는 기업을 만나는 경우는 드물지 않다. 잘못된 기술 선택에 발목이 잡혀 실적이 떨어지는 기업도 적지 않게 만난다. 경쟁사는 시장을 허물고 먹을거리를 다 가져가는데 말이다.

그래서 아키텍처 감사가 시작된다. 당연히 CEO나 CFO가 이런 감사를 요청하고, 때로는 이사회가 요청하기도 한다. CIO나 CTO, 아니면 기업 IT 부서의 책임자가 이런 요청을 하는 경우는 매우 드물다.

하는 쪽이나 받는 쪽이나 모두 성공적으로 클라우드 아키텍처 감사를 진행할 수 있는 몇 가지 팁을 소개한다.

책임 공방을 벌이지 말라. 목표는 잘못을 찾는 것이 아니라 현재의 솔루션을 좀 더 비용 및 기술 효율적으로 만들 방법을 찾아 더 큰 비즈니스 이점을 만들어내는 것이다.

의사결정이 내려진 맥락을 이해하라. 예를 들어, 전반적인 기능이 부족한 현재의 보안 솔루션이 선정된 이유는 자동화된 컴플라이언스를 지원하기 때문일 수 있다.

대안 기술을 모색하라. 물론 대안 기술을 이용하는 비용과 위험성도 함께 고려해야 한다. 많은 경우, 선택된 기존 기술이 최적의 해법은 아니지만, 이를 교체하는 데 드는 비용은 잠재적인 이점보다 더 크다.

양쪽 모두 틀릴 수 있다. 아키텍처 평가에서 데이터 유출 위험을 낮추기 위해 암호화 수준을 높여야 한다는 권고안이 나왔다. 하지만 이 권고안은 성능에 미치는 영향을 계산하지 않았고, 권고안대로 하면 데이터베이스가 사용할 수 없는 상태가 될 수도 있다. 좁은 영역의 아키텍처를 결정이 넓은 영역의 아키텍처 실수가 될 수 있다.

함께 일하는 법을 배운다. 가장 힘든 일이다. 평가와 변경 권고안에 동의하지 않더라도 일정 부분에서 모두가 통일된 전략을 밀어붙여야 할 필요가 있다. 궁극적으로는 양쪽 모두 비즈니스에 필요한 것이 무엇인가를 생각해야 한다. 100%에 가깝게 최적화할 수 있는 아키텍처 전략과 기술 솔루션, 프랙티스를 만들 수 있는 방안을 마련해야 한다. 점진적인 개선을 수행할 수 있는 적절한 계획을 세워야 한다.

좋은 아키텍트는 다른 사람을 지적을 잘 받아들인다. 동료를 포함한 내부 조직의 지적은 물론 감사 등 조직 외부의 지적도 마찬가지다. 필자도 젊은 CTO 시절에는 외부의 평가를 성가시고 주의를 산만하게 하는 요소로 봤다. 이제는 주변의 똑똑한 사람들로부터 가능한 한 많은 지적을 받는 것이 성공의 핵심임을 안다. 

아키텍처 감사에 대해 조언하자면, 신뢰할 수 있는 인재에게 도움을 청하고 이런저런 경험이 많은 사람의 조언을 모두 경청하기 바란다. 지식은 언제나 유용한 툴이다. 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.