아키텍트(Architect)란 여러 뜻이 있지만 IT(Information Technology)에서는 ‘전체 시스템을 설계하는 사람’ 또는 그에 준하는 전문가의 뜻을 가진다. 아키텍트라는 단어 자체가 가지고 있는 범위가 너무 크기 때문에 좀 더 세분화 하여 표현들을 하는데 오늘은 각 세분화된 아키텍트가 가지고 있는 의미에 대해 이야기를 나눠보려고 한다.
종류는 아래와 같다. (참조 : 제타위키)
- 엔터프라이즈 아키텍트 (Enterprise Architect, EA)
- 비즈니스 아키텍트 (Business Architect, BA)
- 소프트웨어 아키텍트 (Software Architect)
- 어플리케이션 아키텍트 (Application Architect, AA)
- 솔루션 아키텍트 (Solution Architect, SA)
- 시스템 아키텍트 (System Architect)
- 테크티컬 아키텍트 (Technical Architect, TA)
- 데이터 아키텍트 (Data Architect, DA)
위에 분류된 종류는 개인적인 생각으로는 너무 많이 세분화가 되어 있는 것 같다. 위 리스트 중 영문 표기에 줄임말로 표현되는 아키텍트들은 표준처럼 언급되는 아키텍트다.
EA(Enterprise Architect)
전체 아키텍처 설계를 담당하는 개인 또는 조직을 뜻한다. EA는 그 아래의 아키텍트를 포괄하고 있다고 보면 되며, 전체적인 전략을 수립하고 수행하는 입장으로 보면 된다.
AA(Application Architect)
어플리케이션 기술에 특화된 아키텍트다. 프로그래밍 팀의 리딩 역할을 하는 사람이 주로 맡으며, 어플리케이션 레벨의 아키텍처를 설계하고, 표준 가이드를 작성한다.
SA(Solution Architect)
어쩌면 가장 유명한(?) 아키텍트일 것 같다. 클라우드 관련 자격증을 보면 솔루션 아키텍트 관련 자격증은 항상 등장하는 것 같다.
그 이유는 이 아키텍트의 역할을 소개해보면 알 수 있을 것 같다.
SA는 비즈니스에서의 요구사항, 성능, 가용성, 보안, 비용 등을 고려하여 통합 솔루션을 구성 및 설계하는 역할을 한다.
여기서 말하는 비즈니스란, 간단하게 예를 들자면, 우리는 우리가 필요한 시스템을 설계하기도 하지만 Outsourcing을 하기도 하는데,
그럴때 우리가 필요한 시스템이 무엇인지, 그리고 그 시스템이 운용되기 위해서는 서버의 사양이 어느정도가 되어야 하며
연중무휴 협의된 시간이 아닌 이상 무중단으로 운영이 되길 원하고(가용성) 외부의 침입을 허용해서는 안되는(보안) 시스템을 만들고 싶다.
그럼 얼마인가?(비용) 이런 고민들을 하는 전반적인 내용을 비즈니스라고 한다.
(이런 비즈니스의 내용들을 관리하는 것을 BA분들이 하시는데, 이번 포스트에서는 따로 언급은 하지 않는다.)
사실상 거의 모든 내용을 포괄하고 있다고 봐도 무방할 정도이다..;
비용추산까지 하는게 SA의 역할이기 때문이다.
그만큼 자신이 SA의 역할을 하고 있다면, 인정을 받을 수 있지만 그만큼의 책임감도 따른다는 이야기이다.
TA(Technical Architect)
인프라 설계, 하드웨어 및 네트워크 아키텍처를 설계하는 역할을 한다고 한다.
사실 이 역할에 대해서는 의견이 분분하다. SA가 Software에 가까운 아키텍트라면 TA는 Hardware에 가까운 아키텍트라고 하는 분들도 계시고, 설계 구축 과정에서 막히는 부분에 대해 기술지원을 해주는 것을 TA라고 하는 분들도 계신다.
내 생각에는 TA는 전자에 더 가깝다고 생각이 되며 솔루션의 아키텍처가 나오면서 그 아키텍처가 구현되기 위해 필요한 더 Under Layer의 아키텍처를 설계하며, SA와 지속적인 커뮤니케이션을 통해 서로에게 더 최적화된 아키텍처를 만들 수 있게 하는 것이 TA와 SA의 관계라고 생각이 된다.
하지만 점점 Bare-metal로 구성하여 설계하던 시스템이 Virtualization화 되면서 클라우드를 선택하는 기업도 많아지는 이 시점에는 SA와 TA의 경계는 지금도 모호하지만 점점 더 모호해지면서 합쳐질 것 같다는 생각이 든다.
DA(Data Architect)
데이터 관리 시스템을 위한 아키텍처를 설계하는 역할을 한다. 기본적으로는 비즈니스 요구사항에 맞춰 데이터 구조 최적화를 할 것이고, 가용성과 성능, 보안 등을 고려해야 한다. 또한 차후 확장성 등을 고려하여 설계를 해야하며, 데이터베이스 개발 표준을 작성하고 관리해야 한다.