엔터프라이즈 환경에서 아키텍처 팀의 역할

- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다. 

프로젝트를 해요?~~~

프로젝트 사업을 만든다, 

고객의 요구사항을 듣는다,

제안서를 작성한다, 

요구사항 분석서를 작성한다, 

고객의 요구사항 중 비기능 요구사항을 식별한다, 

비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다, 

아키텍처를 설계하고 검증을 위한 선도 개발을 한다 , 

개발 표준을 제시하고 개발 표준의 준수여부를 체크한다. 

위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요? 고객 또는 P.M 입니다. 

하지만, 실제 프로젝트를 수행하다보면 이런 행정상의 문제 혹은 정치적인 문제 뿐만이 아닌 기술적인 문제에서 우리는 누가 해야 할 지 모를 일을 두고 서로 모르는체 넘어가는 경우가 있습니다. 일명 ‘회색지대’ 라고 부르는 영역이죠. 저는 그런 영역을 책임지고 가이드하고 리드하는 조직이 아키텍처 팀이라고 생각을 합니다.

 

아키텍처팀은 리드 아키텍트와 시니어, 주니어 로 구성된 아키텍트로 구성이 됩니다. 

예전엔 ‘공통팀’ 이라고 불리웠던 팀이 프로젝트가 대형화되고 조직화 되면서 시스템의 아키텍처를 담당하는 팀이 있어야 하므로 존재하게 되었습니다. EA 의 정의에 나오는 AA, TA, BA, DA  의 조직일 수도 있고 Software Architecture 에서 이야기 하는 SA Team 일 수도 있습니다. 

어떻게 명명이 되던지 아키텍처팀은 조직마다 역할이 달라지는 경향이 있습니다. 해당 조직에서 어떻게 Architecture 라는 놈을 바라보느냐에 달려있는 것 같습니다. 

여러가지 이견이 있을 수 있지만, 일반적으로 엔터프라이즈급 프로젝트를 하면 EA 기반하에 진행되는 경우가 많습니다. 그래서 역할명도 도메인 설계에 관련된 역할은 Application Arhcitecture Team 이 인프라나 미들웨어 관련 역할은 Technical Architecture Team이 Data 관련 사항은 Data Architecture Team 이 책임을 가지게 됩니다. 

저는 EA 의 정의를 따르지 않고 순수하게 Software 를 바라보는 Software Architect 의 입장에서 SA Team 을 바라보고 거기에 따른 얘기를 하려고 합니다. 굳이 비교를 하자면 SA 가 EA에서 말하는 AA와 TA 를 연결하는 선상에 있다고 생각을 하고 싶습니다. 

일반적으로 프로젝트를 하다보면 ‘애매~~한’ 상황이 생기기 마련입니다. 

예를 들면… 

구현과 설계의 매핑이 되지 않아요? 구현 후에 테스트를 어떻게 할 지 모르겠어요? 개발 환경 설정은 어떻게 하죠? 도대체 에러가 어디서 발생하는 거에요? 로그는 어떻게 보죠? 테스트 데이타는 어디 있어요? 테스트를 이렇게 손과 눈으로 해야 하나요? 테스트 시나리오는 어디서 도출해야 하나요? 그게 맞는지 검증은 어떻게 하나요? 비즈니스 검증은 누가 해야 하나요? 버전이 도대체 뭐가 최종이에요? 커뮤니케이션 문제발생시 해결방법은 어떻게 해야 하나요? 조직 구성 ( off-shore 등 ) 의 특성에 따른 프로세스를 고려 하고 있나요? 이슈관리 , 위험 관리는 어떤 프로세스로 관리 해야 하나요?  관련 문서는 어디서 찾아봐야 하나요?

이런 이슈제기나 질문을 하는 경우가 있습니다. 요고 요고 애매~합니다. 이거 정해 드립니다. 

‘기술적인 의사결정이 필요한 경우’ 

요고 요고 애매 하죠? 누가 의사결정을 하느냐? 관리자냐? 고객이냐? 개발자냐?

네 그렇습니다. 요놈은 ‘아키텍처팀’ 이 합니다. 

‘String Utility 하나 만들어주세요.’ 요론거.. 요론거는 기술적인 의사 결정 아니죠? 이거는 아키텍처팀의 역할 아닙니다. 정말 ‘공통팀’ 이 하는 겁니다. 아마도 ‘아키텍처팀’ 의 하부조직으로 만드는 것이 좋을 것 같습니다. 

‘각 모듈 개발이 시작할 때 전체 관점에서 방향제시’ 네. 기술적인 방향제시, 전체 구조상의 방향제시. 요놈은 ‘아키텍처팀’ 이 하는 거 맞습니다. 

가끔 대략적인 컨셉만 주고 ‘각 모듈팀에서 알아서 하세요’ 하는 경우 있는데 이거 아닙니다. 아키텍처팀이 해야 합니다. 실제 아키텍처 팀에서는 스스로 내놓은 솔루션을 검증하기 위해 Pilot Test 를 필수로 진행해야 합니다. 

그렇다면 아키텍처팀의 존재 목적이 위의 두어가지 역할만 하면 되는 것인가? 

아마도 회사의 아키텍처팀 이냐 프로젝트의 아키텍처팀 이냐에 따라서 달라질 것입니다. 

어느 조직이든 간에 비슷한 역할은 정책결정, 기술리드, 리서치 및 솔루션 제시 , 품질에 대한 가이드, 학습조직 등의 역할을 하리라 생각이 됩니다.

 특히, 프로젝트 혹은 운영 팀의 경우 아키텍처를 담당하는 팀에서는 아래와 같은 사항이 기술적으로 집중적으로 관리 되어야 할 사항입니다. 

‘어느 개발자가 오더라도 개발환경 셋팅을 쉽게 하고 샘플을 개발할 수 있는 가이드 마련, 코드 표준 , 권한/로그 등의 표준 , 요구사항 추가/변경에 따른 기술적인 대안 마련 , 자동화된 테스트 구현을 위해 테스트 프레임워크 마련 , 자동화된 빌드 환경 구축’ 

이런 것들이 집중 관리되고 있어야 프로젝트 진행 중에 문제 발생 확률이 적어지리라 생각을 합니다. 

저는 프로젝트 초반의 역할이 정말 중요하다고 생각이 되는데요. 

‘기능/비기능 요구사항에 대한 수집, 프로젝트의 품질 요구사항에 적합한 기술구조 수립, stakeholder 별 뷰 작성, 필요한 기술구조에 대한 숙련자 선별 , 필요한 기술구조 학습, 품질 요구사항에 따른 대안 마련, 대안별 파일럿 작성, 프로토타이핑을 수행할 우선순위에 따른 모듈 선택, 빌드 프로세스 수립, 로그 표준 작성, 예외 표준 작성, 프로젝트 요건에 따른 대안 샘플링 테스트, 선정 모듈 프로토타이핑, 프로젝트 개발 템플릿 작성, 개발자 가이드 작성, 필요 도구 개발, 빌드 파일 개발, 테스팅 도구 개발’ 

등을 통해서 프로젝트 초반에 기틀을 확실히 하려고 노력해야 프로젝트 진행 중 위험요소가 적어질 수 있다고 생각을 합니다. 어느정도 아키텍처가 자리를 잡고 구성원 모두가 같은 뷰를 바라보게 되는 시점에서는 아키텍처팀의 분산이 일어나야 합니다. 그래서 프로토 타이핑 수행 후 각 모듈팀으로 아키텍처팀원들의 분산 & 기술 리더 역할을 수행하고 각 프로젝트 팀의 이슈사항들을 아키텍처 팀으로 피드백 반영을 하는 역할을 수행해야 합니다. 

아키텍처팀은 개발 프로세스에도 관여를 해야 합니다. 근래에는 전통적인 프로세스들과 애자일 프로세스가 양립하며 애자일 프로세스를 선호하는 조직도 많습니다. 따라서 애자일 프로세스의 실천법들을 프로젝트에 적용을 할 수 있는 선도 역할을 해야 합니다. 특히 TDD 나 Pair Programming 같은 부분에서는 아키텍처팀에서 먼저 실천을 해 볼 수 있으면 좋을 것이고 아니라해도 경험자적인 측면에서 아키텍트들의 리드가 필요할 수 있습니다. 

위의 나열한 여러가지 역할을 수행하기 위해서 아키텍처 팀의 필요 보유 역량으로는 

첫째로 품질요건 도출 및 솔루션 제시를 할 수 있어야 합니다. 즉, 요구사항 분석 내용에서 품질 속성 도출, Legacy 시스템 등 연동 요건에서의 품질 요소 도출, 아키텍트의 경험 및 운영자의 경험에서 비롯된 품질 속성 도출, 일반적인 Enterprise 기반 시스템에서의 품질 속성 도출 등의 Activity 를 통해서 품질속성들을 도출하고 해당 품질 속성을 만족시키기 위한 기술적인 요소들을 설계 할수 있어야 합니다. 그러기 위해서 아키텍처팀은 기술 트렌드 파악하는데 많은 학습을 필요로 합니다. 시장을 주도하는 기술 트렌드의 특징 및 속성에 대한 지속적인 정보를 파악해야 하고 , 전사 거버넌스 차원에서의 전략에 기반한 기술 트렌드 파악, 프레임워크 등의 세부 기술요소 들에 익숙해지고 숙달되어야 합니다. 

둘째로 프로젝트 진행중에는 여러가지 문제가 일어나는 만큼 문제 해결을 할 수 있는 역량 역시 중요합니다. 

WAS, ESB 등의 플랫폼 기술에 대한 기술 스펙, WAS 셋팅, 트러블 슈팅, 메모리 관리 원리, ESB 의 작동 원리, WebService , XML Parsing 기술, API 설계/구현 능력, 공통 API 설계 능력, Framework Wrapping, 기능 공통 구현 능력 등을 갖추려 노력해야 하고 실제로 실현함으로써 프로젝트 팀을 기술적으로 리드할 수 있습니다. 

셋째로 프로젝트의 기술적인 리드 입니다. 선장 없는 배가 흔들리듯이, 건축가 없는 건축물이 기초도 뼈대도 불안하듯이 소프트웨어 역시 튼튼한 기반을 갖추기 위한 소프트웨어 설계자가 필요합니다. 이런 몇가지 역량중에서도 가장 중요한 것은 역시 세번째의 기술적인 리드라 할 수 있겠습니다. 

이렇게 아키텍트팀이 갖춰야 할 역량은 많습니다. 그러나 S/W 아키텍트로서의 역할을 팀이 온전히 할 수 있려면 역시 기술적인 트렌드에 밝아야 하고 커뮤니케이션에 능통해야 합니다. 고객과의 커뮤니케이션은 물론이고 관리자와의 커뮤니케이션, 개발자를 리드할 수 있는 커뮤니케이션 능력, QA등의 Project Support 조직과의 커뮤니케이션 등이 아키텍처팀이 해야 할 커뮤니케이션이라 할 수 있습니다. 그리고 아키텍처가 틀이 잡히고 위험요소들에 대한 검증이 마무리가 되어가면 아키텍처 팀은 각 서브 프로젝트 팀으로 배치되어서 기술적인 리드를 수행하고 아키텍처팀에게는 역으로 피드백을 할 수 있는 선순환 고리가 마련이 되어야 할 것입니다. 

마지막으로 아키텍처 팀을 한마디로 정의 내려보자면

‘프로젝트의 기술적인 방향을 결정하지만, 실제로는 프로젝트의 각 영역간의 의사결정이 모호한 회색지대를 메우는 팀’ 이라고 정의를 하고 싶습니다.