본문 바로가기


Developer Story/Architecture

[Architect] '아키텍트'란?

"아키텍트"의 정의와 역할에 대하여 세 차례에 걸쳐 포스팅 됩니다. 

[Architect] '아키텍트'란?
[Architect] '아키텍트'의 역할
[Architect] '아키텍트'가 갖추어야 할 자질

그 첫번째로 이번에는 "아키텍트"의 정의에 대해서 알아보고자 합니다.

일반적으로 얘기하는 "시스템"이란, 공동 과업의 수행이나 목적을 달성하기 위해 공동으로 작업하는 조직화된 구성 요소의 집합이라 정의할 수 있으며, "아키텍쳐"란 특정 비즈니스 요구사항을 만족하는 시스템을 구축하기 위한 전체 시스템의 구조를 정의한 산출물의 집합이라 할 수 있다.

그리고 이것은 문서가 될 수도, 프로토타입 코드가 될 수도 있다 (필자 개인적인 생각으로는 산출물의 양식에 제약을 받아서는 안 된다). 그리고 산출물 내에는 시스템을 구성하는 컴포넌트에 대한 설명과 독립적인 컴포넌트간의 관계, 그리고 각각 컴포넌트가 다루는 데이터를 정의할 수 있어야 한다. 즉, 아키텍쳐는 실제 동작하는 시스템에 대한 설계도라 할 수 있으며, 잘 설계된 SW 아키텍쳐는 현재의 요구사항을 수렴할 수 있어야 할뿐만 아니라 변화되는 비즈니스 전략에 대응이 가능하도록 충분히 유연해야 하며, 장기적인 로드맵을 수용할 수 있도록 디자인 되어야 하고, 가능하다면 구현 및 사용하고자 하는 조직의 기술 수준, 규모, 형태에 맞추어 설계되어야 한다.

아키텍트란 이러한 아키텍쳐 및 시스템을 설계하기 위하여 구성하는 각각의 컴포넌트를 선택하고 그에 따른 표준을 정립하여 독립적인 컴포넌트 간의 관계를 정의함으로써 유기적인 하나의 시스템을 설계하는 사람 뜻한다. Wikipedia에 나온 정의를 따르면 다음과 같다.

Software architect is a computer programmer that makes high-level design choices and dictates technical standards, including software coding standards, tools, or platforms.
아키텍트는 high-level 엔지니어 입니다. 교제와 시험만으로 만들어진 결과물이 아닙니다.

이러한 아키텍트는 전문성 계층에 따라 다음과 같이 세부적으로 분류되어 질 수 있다.

1. Enterprise Architect (EA)
Business Architecture를 포함하여 전체 아키텍쳐의 설계에 대한 책임을 갖고 있다. 비즈니스의 이해를 바탕으로 전체 시스템에 대한 큰 그림을 설계하며, 장기적인 IT전략 수립을 담당한다. 그렇기 때문에 EA의 경우, 단기적 프로젝트뿐만 아니라, 조직의 비즈니스 전략에 맞춰서 모든 시스템, 프로젝트에 대한 아키텍쳐를 책임지기도 한다. (그렇기 때문에 기술적인 지식 수준뿐만 아니라, 현재 진행하는 비즈니스에 대한 이해도도 높아야만 가능하다.) 이러한 전체적인 구조를 설계하는 역할을 담당하기 때문에 SA, TA, AA, DA, BA에 대한 통제권한을 가지고 팀을 운영하기도 한다.

2. Solution Architect (SA)
SA는 특정 솔루션에 대한 Architecture를 설계한다. SA가 하는 업무가 EA와 겹치는 부분이 있을 수도 있지만, EA가 전체 구조에 대한 설계라면 SA는 특정 분야에 대한 세부설계를 담당한다고 할 수 있다. 그렇기 때문에 EA보다는 특정 영역에 대해서 전문적인 지식이 필요 되어진다.

3. Technical Architect (TA) – Infra Architect
프로젝트에서 필요로 되어지는 Hardware 및 네트워크의 아키텍쳐를 설계한다. 예를 들어, EA 또는 SA가 3-Tier 모델을 정의함에 각각의 Tier 사이에 물리적인 네트워크의 구조를 정의할 필요는 없으며, 이와 같은 부분을 TA가 담당하게 된다.

4. Application Architect (AA)
특정 어플리케이션의 구축에 대한 표준 가이드 및 아키텍쳐 구조를 담당한다.
간혹 SA와 AA를 혼동할 수 있지만, SA는 각각의 독립적인 Application간의 종속성이 발생하는 것에 대한 설계를 진행하며, AA는 독립적인 Application의 세부 설계를 담당하게 된다.

5. Data Architect (DA)
전체 데이터에 대한 구조적 설계를 담당한다.

6. Business Architect (BA)
일반적으로 역할을 구분하지는 않지만, EA의 경우 기술적인 측면과 비즈니스적인 측면에 대한 이해도가 모두 높아야 한다. 하지만 현실적으로 두 가지에 대한 이해도가 높은 사람이 극히 드물기 때문에 EA는 좀더 기술적 측면에 집중하고 BA로 하여금 비즈니스적 측면을 고려할 수 있도록 역할을 분담하고 있다.

위와 같이 6개 정도로 역할에 따라 구분될 수 있지만, EA를 중심으로 SA, TA, AA, DA 등의 원활한 커뮤니케이션이 없이는 좋은 구조를 설계할 수도, 유지할 수도 없다. (아무리 아키텍트의 중요성이 대두되었다고는 하지만, 아쉽게도 위와 같이 역할로 나뉘어진 전문화된 아키텍트 그룹을 갖고 있는 조직은 거의 없으며, 대부분은 한 사람이 모든 것을 담당하기도 한다. 그래도 있으면 다행이다.  ^^;; )

종합적으로 아키텍트는 기술 패러다임의 본질을 알고, 복잡하고 다양하게 등장하는 여러 기술 및 솔루션의 특성과 장단점을 구체적으로 파악하여 구축하고자 하는 시스템에 올바르게 적용함으로써 프로젝트의 성공과 수익성 제고에 기여할 수 있는 능력을 갖춘 기술 전문가이다. 아키텍트가 없다고 프로젝트가 실패를 하거나, 항상 잘못된 방향으로 흘러가는 것은 아니다. 하지만, 좋은 아키텍트의 존재만으로 프로젝트 결과에 대한 품질은 엄청난 차이를 가져올 수 있다는 것을 잊어서는 안된다.

지금까지 "아키텍트"의 사전적 의미, 업계에 통상적으로 일컬어지는 직무에 대한 설명이었으며, 다음에는 "아키텍트의 역할"에 대해서 알아보도록 한다.


'Developer Story > Architecture' 카테고리의 다른 글

[Architect] "아키텍트"의 자질  (2) 2013.12.24
[Architect] "아키텍트"의 역할  (0) 2013.12.19