소프트웨어 아키텍트 역할에 대해 생각해본다.

소프트웨어 아키텍트 역할에 대해서 한번 생각해본다. 

생각해보면.... 

2005년의 Database 와 UML , 객체지향을 학습하던 어느날. 'software architecture' 라는 단어가 눈에 들어왔다. 

도대체 이놈이 무엇일까를 고민하면서 많은 research 를 하고 고민을 하던 중 만나게 된 교육과정.SEI 의 교육과정과 동일한 커리큘럼으로 진행되는 비트 컴퓨터의 과정이었다.

여기서 훌륭하신 멘토 분들을 만났다. 그리고 꿈을 꾸었다. 

'저 사람들 처럼 되고 싶다.'

그리고 마틴파울러를 알게 되고 켄트벡을 알게 되었다. 

내가 꿈에 그리던 아키텍트가 아닌 다른 모양을 바라보는 현재까지도 그 꿈은 여전히 현재 진행형이다. '아름다운 아키텍처' 를 만들어보고 싶다 라는 생각을 항상 마음속에 품고 산다. 

여전히 능력은 내가 만족할 만한 수준도 아니요, 어딘가에 보여줄 수준도 아니다. 

가끔 고민을 해보는데.... '멘토 코스프레' 라고 했나? 그런 '멘토 코스프레'를 할 생각은 없다. 

아키텍트 라는 역할에 대해서 우리가 성장하기 위한 목표를 잡기 어려운 이유가 무엇일까? 

필자가 생각하기엔 아마도'아키텍트' 라는 역할의 정의가 불분명 하기 때문이다. 

'소프트웨어 아키텍트'는 직함이나 회사에서의 위치를 뜻하거나 지식수준을 일컫는 단어가 아니다. 

소프트웨어를 만들기 위해서 설계에 참여하는 사람들의 역할을 지칭한다.

그리고 저명한 서적들에서는 그들 중에서 기술구조를 결정할 수 있는 의사결정권이 있는 기술리더를 '소프트웨어 아키텍트' 라고 칭한다. 

필자가 경력을 시작하던 1999년 정도에 우리나라 소프트웨어 개발에서 설계자는 DB 모델러 라고 했다. 

정보시스템에서 기반이 되는 데이타를 설계하는 주 집단이 ( 특히 우리나라에서는 ) RDBMS 를 기반으로 하는 관계형 모델러 들이었기 때문이다. 

그래서 그들을 위주로 소프트웨어 개발을 돌아갔고 우리는 그게 당연했다. 필자 역시도 Data Modeler 가 초반 경력의 꿈이었다. 

대단하지 않은가? 프로젝트 혹은 프로덕트 전체가 특정 역할을 하는 사람들에 의해서 기반이 세워지고 그 시스템이 만들어 진다는 것이..

내게는 그 사람들이 시스템의 창조자 였으며 건물을 설계하는 아키텍트였다.

그러나 개발 패러다임이 바뀌고 '소프트웨어 아키텍처' 라는 이야기들을 들은 것은 '카네기 멜론 대학' 등의 교육과정을 통해서 성장한 이들이 우리나라에도 교육과정을 만들고 설파하기 시작한 2004년 정도 라고 생각을 한다. 

그때부터 소프트웨어 아키텍처 라는 이야기를 시작하고 소프트웨어 아키텍트 가 도대체 뭘까? 하는 이야기들을 하기 시작했다. 

그 때 당시의 소프트웨어 아키텍트의 정의는 '소프트웨어 아키텍처 인 프랙티스' 에서 정의한 '한 시스템의 소프트웨어 아키텍처란 그 시스템의 한 구조나 구조들로 각 요소들과 외부에 보이는 특성들 그리고 그들간의 관계를 절충한다' 였다. 

그리고 소프트웨어를 개발하기 위한 전지전능한 존재 라고 이야기 하기 시작했다. 

누가 어떤 논리로 이 단어를 표현하기 시작했든 간에… 

'전지전능한 존재'… 이 정의에서부터 프로그래머, S/W Developer 에게 진입장벽을 만들었고 개발자들에게는 위화감을 조성하게 되었다.

그리고 실제 일을 해보니 화성인 아키텍트와 현실에서 구현을 하는 개발자간에 생기는 간극을 해소하지 못하는 문제들이 발생하게 되었다. 

그래서 그 두 집단(?)은 서로를 멀리하게 되고 서로를 욕하는 경우가 많아지게 되었다고 생각을 한다. 

왜 이런일이 일어나게 되었고 서로 어떤 부분을 오해하고 있는지에 대해서 조금더 많은 생각이 필요하다.

용어정의 ( 가끔 단어를 구분하지 않는 분들을 위해서 일단 단어 정의를 한다 ) 

소프트웨어 아키텍트 - 아키텍처를 설계하는 일을 하는 역할? 혹은 시스템 구조 설계자 

소프트웨어 아키텍처 - 소프트웨어를 구축하기 위해서 설계를 하기 위한 뼈대 설계 ( 더 낫고 디테일한 정의는 '소프트웨어 아키텍처 인 프랙티스' 를 추천한다 ) 

가끔 그런 글을 보거나 훌륭하신 분들중에서 이런말을 하시는 분이 있다.

'나는 대한민국에서 소프트웨어 아키텍트를 손가락으로 꼽을 만큼만 인정한다.'

'제대로 하시는 소프트웨어 아키텍트를 본적이 있습니까?'

필자는 몇가지 측면에서 이 말 자체가 잘 못 되어있다고 생각하는 사람이다. 

1. 일단 말 자체가 잘못되었다.

위에서도 이야기 했듯이 필자는 소프트웨어 아키텍트는 '역할' 이라고 생각한다. 

특히, 특정시점에서 소프트웨어 아키텍처를 설계하는 역할.

그런데 소프트웨어 아키텍트를 인정한다. 안한다. 이말이 무슨말인가… 말 자체가 이상하지 않은가? 

좀 어거지 스러울지 몰라도 이 말은 

'xxx 시스템에서 xxx 아키텍처를 설계하신 ooo 그 분은 xxx 측면으로 훌륭하게 아키텍트 역할을 하셨다' 는 의미로 들릴수 있도록 이야기가 되어야 한다고 생각한다. 

2. 대학에서 가르치는 사람은 교수, 건축물을 설계하시는 사람은 설계사 혹은 아키텍트 라고 불리운다. 

어떤 교수가 ooo 과목을 가르치는데 수준을 평가한다. 그리고 수준에 따라서 그 사람은 교수라고 불리지 못하게 되나? 

xxx 건축사가 건물 설계를 했는데 건물설계가 개판이다. 그럼 그 사람은 건축사가 아닌건가? 그냥 그 건축사에게 의뢰만 안하면 되는거 아닌가? 

소프트웨어 맥락으로 돌아와 보자.

저명한 서적에서 말했던 수많은 역량들

정치력, 커뮤니케이션 능력, 문서화 능력, 프레젠테이션 능력, 프로세스 설계 능력, 소프트웨어 설계능력, 구현능력, 배포/릴리즈 관여 …

이런 역량을 모두 갖춘 사람만 소프트웨어 아키텍트 역할을 하는 사람이라고 할 수 있는가? 

다른 측면에서 역할 이야기를 해본다. 

정보시스템 구축에서 2006년 즈음에Enterprise Architecture 에 대한 패러다임이 등장하고 그에 의해 나눠진 역할AA, BA, TA, DA 그리고 'Software Architect 는 이 네가지 역할중에 AA 에 가장 가깝지만 그 사이에 있는 것이다' 라는 모호한 경계선상에 놓여진 역할로 여겨지기 시작했다.

2013년 현재 프로젝트를 다니다보면 기업별로 정의하기 나름인 이 역할들. 그리고 Software Architect 라는 역할보다는 AA 혹은 TA 를 사용하기 시작했다. 

이런 역할과 관련된 일을 하면 그 사람은 시스템을 구축하는 아키텍트 역할을 하고 있는 것이다.

그렇지 않은가?