기고 | ‘관건은 중용’··· 엔터프라이즈 아키텍처(EA) 6대 죄악

기업 활동을 유지하는 작업이 쉬웠던 적은 없다. 소프트웨어 도구가 등장하면서 워크플로우의 많은 부분이 더 빠르고, 더 원활하고, 더 일관적으로 진화했지만, 소프트웨어를 가동 상태로 유지해야 하는 사람에게는 부하가 늘어났다. 연못 위 오리의 모습은 평화롭지만 물 밑에서는 발을 미친 듯이 움직여야 하는 상황에 빗댈 수 있다.

최종 사용자나 관리자 또는 최고 임원에게 엔터프라이즈 아키텍처(EA) 전문가의 업무는 마법처럼 보일 수 있다.  끝없이 이어지는 동기화, 정리, 안정화라는 따분한 일을 모두 컴퓨터가 처리하므로 인간은 더 효율적인 업무에 집중할 수 있다. 

그러나 각종 웹 포털, 협력 스택, 그리고 저장소 등을 제대로 유지해야 하는 끝없는 과제가 여전히 숨어 있다. EA는 많이 발전했지만 여전히 미지의 작업과 책무로 가득 찬 새로운 세계다.

EA 전문가들은 여전히 진화하고 있으며, 그들이 해야 할 것에 대해, 더 중요하게는 할 수 없는 것에 대해 더 많이 알아가고 있다. 그 과정에서 많은 실수가 있었다. 또한, 소프트웨어 스택을 가동 상태로 유지하고 조직 전체의 모든 사람의 업무 생활을 최대한 단순하게 유지하는 최상의 방법을 모색하는 과정에서 실수가 반복될 가능성이 높다. 그 이유는 고도로 기술적이고 복잡한 업무 특성 때문이기도 하지만 EA 담당자들이 저지르는 다음과 같은 죄악 때문이기도 하다.
 

데이터를 너무 많이(또는 너무 적게) 저장
소프트웨어 개발자는 필요 없는 것까지 모아두는 사람들이다. 가능하다면 모든 것을 캐시에 저장하고, 모든 이벤트를 기록하며, 끝없이 진화하는 기업 상태에 대한 백업 사본을 저장하려 든다. 그러나 그렇게 수 기가바이트, 수 페타바이트씩 저장하다 보면 점점 쌓이기 마련이다. 저비용 스토리지를 이용한다고 해결될 문제가 아니다.

설상가상으로, 데이터레이크가 가득 찰수록 정확한 데이터를 찾기가 더 힘들어진다. 정보가 모두 거기 있는 것은 분명하지만 정작 찾기란 만만치 않다.

문제는 정보를 너무 적게 보관해도 나름대로의 실패 모드와 고충이 따른다는 점이다. 일부 회사는 규정이 허락하는 한 최대한 일찍 모든 것을 파기하도록 정책을 설정하려고 한다. 하지만 이 경우 각종 질문에 대해 “그 파일이 없다”라는 대답이 돌아오는 상황을 감수해야 한다. 아는 사람이 아무도 없다.

적절한 균형을 찾기란 불가능할지도 모른다. 할 수 있는 일은 그저 어둠 속을 더듬으며 전등 스위치를 찾느라 시간을 보내지 않도록 적절한 정보를 이해하기 쉬운 구조로 보관해 두는 좋은 데이터 저장 아키텍처를 찾는 것이 전부다.

하나의 플랫폼에 너무 많이 의존(또는 너무 많은 플랫폼 수용)
간단하게 기업 소프트웨어를 확장하는 방법이 있다면, 외부 기업이 만든 만든 다양한 도구, 포털, 플랫폼의 힘을 활용하는 것이다. 구입 주문서에 서명하고 약간의 연결 코드를 작성하는 것만으로 작업 대부분이 끝난다.

그러나 기업의 핵심 부분을 외부 회사에게 맡기면 위험이 많이 따른다. 예컨대, 사모펀드 회사가 공급사를 인수한 다음, 고객 기업이 벗어날 수 없다는 것을 알고 가격을 올리는 수가 있다. 모든 달걀을 한 플랫폼에 인스턴스화한 것이 갑자기 심하게 문제를 일으킬 수도 있다. 이 지경이 되면 아무도 단일 플랫폼의 단일 인터페이스에서 오는 단순함과 일관성에 갈채를 보내지 않을 것이다.

그러나 복수의 플랫폼을 수용하는 것 역시 못지 않게 골치 아프다. 설령 벤더의 영업 팀이 장담한 대로 해당 도구가 상호 운용하고 업계 프로토콜을 사용하도록 설계되었더라도 절반의 목표만 달성할 수 있을 것이다. 각각은 SQL 데이터베이스에 데이터를 저장할지 몰라도 일부는 MySQL을 사용하고 다른 일부는 PostgreSQL 또는 오라클을 사용한다.

간단한 해답은 없다. 플랫폼이 너무 많으면 일종의 바벨탑이 생긴다. 너무 적으면 업체 종속의 위험과 그 갱신 계약 이메일을 열어야 하는 고통이 따른다. 모든 개발을 사내에서 처리해야 하는 비용에 대해서는 아직 언급조차 하지 않았다.

클라우드로 너무 많이(또는 너무 적게) 외주
클라우드 덕분에 EA 담당자의 업무는 훨씬 더 편해졌다. 누군가 특정 크기의 머신이 필요하다고 하면 몇 분 안에 대령할 수 있다. 구입 주문서를 작성할 필요가 없다. 랙 공간을 확보할 필요도 없다. 아무것도 할 필요 없고 클라우드 회사에게 신용 카드 번호만 주면 된다.

머신을 몇 분 내지 심지어 몇 초 내에 전달하는 것의 장점은 명백하다. 반면 큰 단점은 가격이다. 클라우드 컴퓨팅은 사내에서 작업하는 것에 비해 극적으로 더 비싼 경우가 많다. 매달 청구되는 클라우드 요금은 그 누구의 예상보다 높기 일쑤이므로 많은 CFO가 청구서 확인을 심히 두려워한다. 

그렇다고 사내에서 직접 하려면 직원, 데이터센터 등등을 관리해야 하고 비용도 든다.  골칫거리와 규정은 늘어만 가고 예산을 아껴서 생긴 기쁨은 오래가지 않는다.

EA 담당자가 클라우드로 큰 이득을 볼 수 있는 경우도 있다. 매주, 매달 또는 매년 수요가 폭증하는 시간이 적다면, 부하 처리를 위한 서버 가동 시간이 몇 분 내지 몇 시간에 불과하므로 무엇이든 사내에서 하는 것보다 비용이 극적으로 적게 든다. EA 담당자를 제외한 다른 모든 사람은 클라우드에 투자를 너무 많이 한 것인지 아니면 너무 적게 한 것인지 알쏭달쏭하다.

프레임워크라는 종교 맹(또는 무시)
오늘날의 기업 스택이 몹시 복잡하기 때문에 일부 똑똑한 아키텍처 담당자는 기업 스택 정리에 도움이 될 프레임워크를 만들었다. 예를 들어, 더 오픈 그룹 아키텍처 포맷(The Open Group Architecture Format)(TOGAF)은 기업에게 필요한 사실상 모든 것을 구축하기 위한 전략적 프레임워크로서, 아키텍처 개발 방법(AMD), 아키텍처 준수 프레임워크(ACF) 등 여러 지침과 모범 사례를 제공한다. 

이 밖에 자크만 프레임워크(Zachman Framework)나 페더럴 엔터프라이즈 아키텍처 프레임워크(Federal Enterprise Architecture Framework)(FEAF) 같은 접근 방식은 스택 확장을 위해 자체 버전의 규칙과 규정을 적용한다.

큰 이점은 일관성일 것이다. 조직 구성원 전원이 기법과 이론을 숙지하고 나면 소프트웨어를 다루는 것이 좀 더 쉬워진다. 데이터와 코드는 (대개) 모든 것이 예측 가능한 곳에 있도록 구성된다.

그러나 어떤 사람들은 도를 넘는다. 단순히 규칙을 채택하는 대신 종교에 빠진다. 모든 결정이 반드시 규칙에 따라 내려지도록 사양을 철저하게 읽는다. 과유불급이라는 말이 나온 데에는 이유가 있다.

설령 모든 사람이 프레임워크교를 믿고 사무실 기획 회의실이 행복한 규칙 추종자들로 가득차도 다른 문제들이 슬금슬금 생길 수 있다. 때때로 각 팀은 더할 나위 없이 좋은 오픈소스 코드가 그들의 바람직한 아키텍처 프레임워크와 일치하지 않는다는 이유만으로 거부한다. 유감스럽게도 올바른 철학으로 개발되지 않았다는 이유로 좋은 선택지를 제공하는 업체와의 협력을 거부할 때도 있다.

방법론을 최우선적으로 고수
프레임워크는 체계를 제공하지만 엉성하고 태만한, 심지어 악의적인 행동을 덮을 수도 있다. 때로는 팀들이 누군가 맞는 TOGAF 양식을 작성하기를 기다리느라 의사 결정을 오래 끌 수도 있다. 힘이 되는 규칙과 사람을 바보로 만드는 불필요한 요식의 차이는 생각보다 선명하지 않다.

필자가 함께 일했던 한 사람은 애자일 방법론을 매우 좋아했다. 그는 이를 왜곡한 나머지 소속팀이 결코 애자일(민첩)하지 않게 되었다. 그는 의례적인 회의 절차를 모두 알고 있었고 바로 지난 주에 작성된 코드를 리팩토링하기 위한 많은 스토리 포인트로 그의 “스프린트”를 채우는 데 능숙했다. 그의 팀은 그가 제공하도록 되어 있는 신용카드 체크아웃 방식의 재구축 작업을 빠르게 진행한 적이 없어 보였지만 각 스프린트마다 획득한 애자일 포인트의 그래프를 보면 사무실 내에서 속도가 가장 높았다.

기업에게는 개발 워크플로우를 정리할 모종의 방법이 필요하다. 프로그래머들은 어떤 것이 애자일인지 워터폴인지에 대한 논쟁을 며칠이고 할 수 있다. 프로젝트 규모가 한 사람이 주말에 감당할 수 있는 것보다 크다면 이를 해결할 전략이 있어야 한다.

문제는 두 눈으로 직접 확인할 수 있는 것보다 방법론을 더 믿기 시작할 때 발생한다. 그럴 때 교활한 코더는 시스템을 조작하여 실제 코드가 하는 역할이 별로 없어도 큰 보상을 얻을 수 있다.

트렌드 추종(또는 무시)
개발자들은 EA의 최신 아이디어와 모델에 열광한다. 때로는 운이 좋아서 새로운 트렌드가 개발자들의 필요에 맞아 떨어지기도 한다. 그렇게 개발된 애플리케이션은 트렌드세터들이 애초에 그 아이디어를 떠올리게 한 원동력에 대한 좋은 예시다.

그러나 그것은 부분적으로만 사실인 경우가 많다. 사용 사례는 트렌드에 영감을 준 애플리케이션과 비슷할지 모르지만 약간의 설명이 있어야 이해할 수 있다. 한편, 개발 팀은 코드를 트렌드에 맞추는 일만 하느라 정신이 없다. 더할 나위 없이 적절한 코드가 작성 당시의 목표가 유행이 지났다는 이유만으로 대량 폐기되기도 한다.

문제는 트렌드를 완전히 무시하는 것도 이에 못지 않게 치명적일 수 있다는 점이다. 물론, 해당 코드가 아무 문제없이 작동하는 데이터베이스, 포맷, 코드 기준, 프로토콜을 사용하여 원래의 비전에 충실했을 수 있다. 그러나 온 세상이 어떤 트렌드를 쫓아갔다면 모든 업체와 도구 제조업체, 그리고 잠재적인 신입 직원도 마찬가지였다.  어느 시점이 되면 트렌드와 유행은 표준이 되고 때로는 더 심각한 법적 준수 요건이 되기도 한다.

EA 담당자는 도저히 이길 수 없다. 트렌드를 추종하면 군중이 따르는 유행의 노예가 되고 트렌드를 무시하면 뒤처질 수 있다. EA 담당자가 할 수 있는 일은 조직의 기술 스택과 이를 보살펴야 하는 IT 전문가를 위해 올바른 일을 하도록 신중하게 노력하는 것이 전부다.

* Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다. ciokr@idg.co.kr