Application Architect란?

몇년전 JCO 컨퍼런스에 참석한적이 있었습니다.
제가 들으려는 section은 사람들이 너무 많아서
들을 수가 없었습니다.
그래서 시간내서 온 것이 아까워서 사람들이
덜 몰리는 section쪽으로 갔습니다.

이동한 section의 컨퍼런스 주제는
"Application Architect" 였습니다.

※ 이하 Application Architect를 AA로 하겠습니다.

내용을 곰곰히 들어 보니 현재 제가 하고 있는
일도 포함이 되었고 반면에 내가 하지 않은
생소한 일도 있었습니다.

마지막에 강사님께서 앞으로
프로젝트에서 AA 롤은 반드시 필요 하며
또한 그에 따른 수요도 증가 할 것이다.

앞으로 고급 프로그래머라면 충분히 도전할
만한 가치가 있다 라고 말씀 하셨습니다.

레퍼런스가 끝나고 저를 포함한 참석했던 분들의
애매한 표정이 생각 납니다.

그러고 몇년이 지나서 최근 프로젝트에
조금씩 AA롤을 수행 하는 분들을 종종 만나게 됩니다.

그분들에게 "What's Application Architect?"
라고 물어보면 대답이 다들 제각각 이였습니다.
심지어 어떤곳은 TA (Technical Architect)라는용어를
사용하거나 프레임웍커(프레임웍 구축자)라고
하는 곳도 있었습니다.

혹시나 해서 웹 으로 검색을 해봐도
AA에 대한 정의가 개념적이지 구체적인
내용을 찾기가 어려웠습니다.

그렇다면 과연 AA는 프레임웍 과 공통 모듈을
구현 하는 사람인지 아니면 GoF의 디자인 패턴을
사용해서 멋지게 UML 설계를 하는 사람인지..

과연 여러분은 프로젝트에서 AA는 무엇이라고 생각
하십니까?

불명확한 실체에 대해서 한 개인이 정의를 내린다는 것은
상당히 조심스러운 행동이라고 생각 합니다.

그래서 주관적인 생각을 최대한 자제 하고
관련 책들과 자료 그리고 AA 담당자들과
대화에 근거 해서 설명 드리도록 하겠습니다.

• Application Architect란?

시스템 특징에 적합한 설계와 구현의 지침인 아키텍쳐
를 작성하고, 이것을 개발팀 전원이 파알할 수 있도록
하는 것이다. 이를 통해 시스템의 품질을 끌어 올린다.
다수가 참여하는 프로젝트에서 아키텍트의 주된 업무는
설계 단계에 진행된다.
아키텍트는 설계 단계 전까지 준비한 아키텍쳐를 개발팀
에게 전달 하고, 팀원들이 아키텍쳐 설계서에 따라
설계와 구현을 할 수 있도록 지원 한다.

- 아키텍트 이야기 85p -

정보시스템에 대한 전반적인 지식과 시스템 구축
노하우를 보유한 경험이 풍부한 기술 전문가로서
프로젝트 전반에 대한 기술적인 총괄 책임을
담당한다.
아키텍처 정의에서 아키텍트가 수행
하여야 하는 업무로서 프로젝트에서 구축 하고자
하는 정보 시스템의 기반 구조를 정의한다.
기반구조의 정의에는 시스템 플랫폼,운영 및 개발환경
,표준 프로토콜,소프트웨어/하드웨어 솔루션 벤치마킹
및 선정 ,시스템 인터페이스 관계 정의,데이터 분산 및
통합 방안등 시스템의 기본적인 골격에 관련된
내용을 포함 한다.

- SI Project (전문가로 가는길) -

즉, 쉽게 설명하면 분석시에 업무담당자 한테
시스템 모모 필요 하니? 필요한 청사진 그리고
설계 단계에서 좀더 구체적으로 표준안 잡고
프레임웍 구축하고 개발자 교육하고
테스트 하는 일련에 Application A~Z까지
전체 총괄하는 롤이라고 이해 하시면 됩니다.

• 아키텍트 수행 역할

- 프로젝트 착수 시 제안서와 계약서를 검토하여 기본적인
소프트웨어 및 하드웨어 아키텍쳐 환경에 대안 초안을
작성 한다.

- 분석 단계에서 전체 시스템에 대한 아키텍쳐 정의를 통해
소프트웨어 및 하드웨어 인프라 구조 정의,
서버 및 네트워크의 기본 모델 정의, 어플리케이션 모듈의
최상위 수준 모델링 등을 수행한다.

- 분석 단계에서 프로세스 모델링 및 데이터 모델링을 수행할 때
시스템 기본 아키텍처를 준수하도록 분석 산출물에
대한 검증을 수행한다.

- 소프트웨어 개발 환경 표준을 정의한다. 소프트웨어 개발을 위한
개발도구의 선정과 프로토타이핑를 주관한다.

- 설계 단계에서 프로그램 및 데이터베이스에 대한 설계 내용을
아키텍처 관점에서 표준의 준수 여부를 검증한다.

- 시스템 테스트 시나리오에서 아키텍쳐와 관련된 시스템 테스트
시나리오의 작성을 총괄 한다.

• 아키텍트에게 요구 되는 것

※상,중,하는 역량의 중요도 입니다.

- 비용관리 (하)
- 일정 관리 (하)
- 요구 사항정의(하)
- 명세 수립 (중)
- 소프트웨어 설계 (상)
- 프로그래밍 (상)
- 개발 방법론 (상)
- 인프라 구축 (중)
- 테스트 방법 (중)
- 품질 관리 (하)

• 실무에서 Application Architect

실무에서 만났던 대부분의 AA는
개발 주관 업체(일명:"을" Big3) 에서 하거나
컨설팀 업체에서 담당을 합니다.
(이유는 크리티컬한 업무이기 때문이죠^^)

그리고 전체적인 분석 및 설계 부분을
대부분 참여 하고 프레임웍 구축 및
코어 공통 모듈에 대해서는 거의
참여를 하지 않습니다.
그래서 대부분 AA + 전문 기술팀(Technical Architect) 또는
AA +TA로 구성된 단일 AA팀으로 구성이 되어있 있습니다.

개인적으로는 이러한 구성이 맞다고 생각 합니다.
과연 AA만으로 신기술과 오픈 소스 홍수 속에서
구현까지 잘 할수 있을까요?
그리고 장애복구,서버이중화등 비기능적 크리니컬
영역에 대해서도 해당 전문가와 co-work를 해야
합니다.
물론 단기 프로젝트거나 프로젝트 규모가
크지 않다면 충분히 혼자서도 가능 하겠죠.

• AA 준비 하기...

사실 저도 AA는 아닙니다. (전 해커에 가깝다고
할까요 ㅋㅋ. 워낙 오픈소스 기반에 매쉬업을
좋아해서 )
이런 위치에서 AA 준비를 이렇게 하라고 말
하는 자체가 웃긴 일이지만 저 또한 AA가
되기 위해서 노력하는 사람으로써 말씀 드리겠습니다.

먼저 되도록 Big3 업체 또는 개발 전문 컨설팅 업체
에서 근무 하는 것이 좋다고 생각 합니다.
물론 들어가서 AA쪽으로 빠진다는 보장은 없습니다.
단 일반 SI 회사보다 기회가 많다는 뜻 입니다.

일반 SI 회사일경우는 정말 매니아적인
마인드가 필요 합니다.
프로젝트 특성상 SI는 업무 중심이기 때문에
기술적으로 깊이 있게 경험을 쌓기에는 제약
사항이 있습니다.
그렇기 때문에 더욱더 기술분야에 관심을
갖어야 할 것 같습니다.

초,중급일 경우 최신 트렌드 보다는
기술적 기본기에 투자를 많이 해야 합니다.
가끔 초,중급 개발자들 중에서 Spring의 한가지
기능을 사용했다고 해서 본인이 스킬이 뛰어난
사람이라고 착각 하는 경우를 종종 보게 됩니다.

초,중급분들한테 거의 아키텍처 관련된 구현을
맡기지 않습니다. 본인들이 교육을 받고 비지니스
로직을 구현할 정도의 센스만 실무에서 경험하고
나머지 시간은 집중적으로 core java,network,xml등
기본적인 기술을 연마 해야 합니다.
(프레임웍크는 업무에 편하지만 기술적인 부분은 점점
개발자를 바보로 만들고 있습니다.)

최소 7년간의 실무 경험이 필요 합니다.
AA는 절대로 물리적 시간과 경험이 필요 합니다.
7년까지는 구현에 대해서 많은 투자가 필요하고
그 이후는 설계에 더 무게 중심을 두어야 할 것 같습니다.
(요새 저도 설계쪽에 많은 시간을 투자 하고 있습니다.)

횡성수설 잘 알지도 못하면서 말씀 드렸네요
어쨌든 앞으로 시스템은 점점도 복잡하고
규모더 커쳐 가고 있습니다. 이럴때 AA의
역할은 절실히 대두되고 있습니다.
AA는 단기간에 만들어 지는 것이 아니며 양성하기도
쉽지 않습니다.
오직 열정과 매니아 정신만이 AA가 될수있다고
생각 합니다.