[IT] 아키텍트 이야기

야마모토 케이지 저/이지연 역/이용원,한의근 감수 | 인사이트(insight) | 2007년 04월

아키텍트(Architect)?
IT 바닥에서 그리 생소한 말이 아니지요.
생소하지 않은게 아니라, 너무나 유행처럼 번지고 있다고 할까?
심지어 '아키텍트 10만 양병설'이 들리는가 하면
대기업들의 경우 독자적인 사내 아키텍트 과정을 운영하기로 합니다.

이 책에서 말하는 아키텍트는 '소프트웨어 아키텍트'를 말합니다.
의미가 명확하게 정의되기는 어렵겠지만, 대략 '책임 설계자'나 '상위 설계자' 정도의 의미가 될 듯 합니다.
모듈이나 기능에 대한 상세한 설계에 이르기 앞 단계에서, 시스템의 구성단위와 인터페이스,
주요 기능의 구현 방법/방안 제시 등의 역할을 한다고 볼 수 있을 것 같습니다.

"아키텍트 이야기"
이 책에서 가장 눈에 띄는 부분은, 대개의 설명을 두리뭉실한 개념적 언급이 아니라
가상의 프로젝트를 대상으로 비교적 실무적인 언급들을 많이 한다는 점입니다.
그 만큼 개발 현장에서 뛰는 사람들에게는 피부에 와 닿는 효과가 있으며
비교적 아키텍트의 역할에 대해서 구체적으로, 행동 사례를 중심으로 설명합니다.
다만, 저자가 책에서 소개하는 '아키텍트'는 어디까지나 저자가 바라보는 아키텍트일 뿐
실제적으로 아키텍트는 바로 이런 사람이다... 라고 명확하게 말하기는 힘들 듯 합니다.

그러나, 실제 현장에서는...
책에 등장하는 아키텍트는 실로 누구나 바라마지 않는 수퍼맨이지요. ^^
폭넓은 배경 지식에, 능숙한 커뮤니케이션 능력, 비즈니스적 수완,
더구나 프로젝트의 핵심 프레임웍을 직접 제작하여 개발자에게 제공하고
개발자들과 짝 프로그래밍을 하면서 개발을 리드하기도 합니다.

실제 상황에서 이런 사람... 사실 거의 없다고 봐야죠.
만약 있다고 해도 매우 드물것이고, 드물게나마 그런 사람을 구할 수 있다고 해도
몸값이 아주 비싸거나 세계적인 유명 회사의 개발 책임자로 근무할 가능성이 클테니까요.

저도 여러가지 프로젝트를 수행하면서, 일면 아키텍트의 역할을 하기도 합니다.
그러나... 실제적으로 제한된 기간과 비용, 인원을 가지고 움직이는 한계상황속에서
프로젝트 매니저, 요구사항 분석, 상위설계, 테스트 플래닝 및 테스트 주관, 각종 산출물 관리까지...
이 모두를 함께 담당하는 경우가 많습니다.
(혼자서 다 못하지요. 다른 프로젝트 팀원들의 협조를 구하면서, 전체적인 책임하게 주관해야 합니다.)

사람의 성향
어떤 사람은 프로그래밍에 아주 능하며 여러가지 언어와 환경을 잘 다룹니다.
각종 시스템이나 툴에 대해서도 해박하게 꽤뚫고 있을뿐만 아니라
개발대상 모듈에 대한 설계를 병행하면서도 최종 완성품 또한 깔끔하기 그지 없으며
짧은 시간에 남보다 많은 양을 생산해 내기도 하지요.
하지만... 실제 업무 현장에서 보면, 이러한 개발자들은 커뮤니케이션에 능숙하지 않거나
좀 더 넓은 관점, 즉 기획적인 입장이나 고객의 핵심적인 요구사항을 찾아내는 일,
개발품의 비즈니스적 가치 등에 대해서는 다소 둔할 경우가 많습니다.
(정확히는... 이런 일들을 귀찮아 하거나 신경쓰기 싫어하는 경향이 강하죠.)

반면에... 커뮤니케이션과 High-level의 설계에 능숙한 사람들은
앞서 말한 수퍼 개발자에 비해서 프로그래밍이나 시스템적인 기술 능력은 떨어지죠.
(마찬가지로... 성향상 이런 일들은 주된 관심사가 아니라고 봐야죠.)

개인적인 의견이지만, 대개는 성향에 따라 이 두 가지 유형으로 나누어지며
각 그룹에 속하는 사람들은 아예 성향과 학습능력, 개인적인 철학 자체가 다름을 종종 느낍니다.
(두 가지 다 못하는 사람은 많이 보겠지만, 반대로 두 가지를 모두 잘하는 사람은 거의 못보지요. ^^)
가령, 처음에는 같이 프로그래밍을 하는 싹수가 짱짱한 스마트 개발자로 출발을 했더라도
시간이 흐름에 따라 어떤 사람은 Guru 개발자적인 역할로 깊숙히 파고들어가며
다른 성향의 사람은 상위 설계자나 기획자, 관리자적인 역할로 범위를 넓히는 것 같습니다.

결론은 협업!
"아키텍트 이야기"의 주인공과 같은 수퍼 아키텍쳐를 모델로 삼기는 어렵습니다.
지금 막 이 바닥에 발을 디디는 개발자라면 충분히 Role Model로 삼을 수 있겠지만
이미 이 바닥에서 몇 년을 일해왔고, 자기 나름의 업무 역량을 갖춘 사람이라면
군인이 되기 위해서 나이 마흔이 넘어서 육군사관학교에 입학하는거나 마찬가지겠지요.

현재 각 개발 업무에서 아키텍트 레벨의 지위나 역할을 가진 사람들이 많을텐데
(직책이나 직함만 다를 뿐... 실제적으로 아키텍트의 역할을 하는 사람들은 많다고 봅니다.)
책에서 소개하는 수퍼 아키텍트의 역량을 가지기 위해 노력하기 보다는
손발이 잘 맞는 협업 파트너와 함께 일하는 것이 훨씬 효과가 좋을 것 같습니다.
(현실적으로 그렇기도 하지요.)

고객의 요구사항을 어떤 형태로 구현하여 제공할 것인가를 결정하고
그 세부적인 구현 방법은 나와 함께하는 Guru의 힘을 빌리는 것이지요.
반대로, 그 Guru는 실제 개발집단(프로그래밍 집단)의 리더로 일하면서
상위 레벨의 의사결정이나 조율이 필요한 사항들에 대해서는 아키텍트의 힘을 빌리구요.

실제로 제가 경험한 프로젝트에서는, 대개의 성패가 각 참여자의 능력이나
수퍼 개발자의 능력에 의해 좌우되기 보다는
수퍼, 준수퍼 급의 능력자들의 총체적인 협업 효율성에 따라 결판나는 것 같습니다.
각자가 잘하는 것도 중요하지만, 각자가 못하는 것들을 협업을 통해 어떻게 극복하는가가
더욱 중요합니다.

그래서... 아키텍트란?
개인적인 의견으로는... 그냥 멋있으라고 붙인 말이 아닐까 생각합니다. ^^
책임 설계자나 상위 설계자, 기술 기획자...
영어로 표현할 때 Abstract Designer나 High-level Designer 보다는 있어보이면서
Chief Designer 내지 Chief Developer 보다는 덜 권위적이고 어감도 좋지요. ^^
Product Manager, Product Designer 등의 표현 보다 더 귀족적이고.... ^^

마이크로소프트의 빌 게이츠나 애플의 스티브 잡스가 이런 직함을 가진다면 잘 어울리겠지요.
그러나... 현실적으로 단발성 프로젝트라든가 시간과 범위가 정해진 상품을 만드는 과정에서는
프로젝트 관리도 하면서, 고객사의 요구사항을 잘 정제하여 시스템 기능으로 정리하고,
시스템의 구성 단위와 인터페이스를 잘 정리하여 각 개발파트의 Role을 명확히 해주고,
개발이 진행되는 과정에서 발생하는 무수한 현안 이슈들을 해결하고,
그 과정에서 생산되는 각종 산출물들을 책임져야 하며,
심지어는 사용자 인터페이스 설계와 최종 테스트까지 두루두루 손을 대고,
절대적인 인원부족 상황에서 떠져나오는 각종 빵구들을 어떻게든지 메워나가는...

개발 백그라운드를 가졌으면서도, 개발과 비개발을 오가는
업무 영역의 경계가 없는 두리뭉실한 개발자...
문제를 직접 해결하지는 않지만, 문제 해결을 위한 방향을 제시하고
개발 담당자와 함께 해결방법을 찾을 수 있는 사람...
현실적인 상황에서 소프트웨어 아키텍트를 정의하면 이 쯤이 되지 않을까 생각합니다. ^^

....

소프트웨어 개발에 종사하시는 분들이라면, "아키텍트 이야기"라는 책을 한 번 읽어보시기를 권합니다.
아키텍트의 역할이나 중요성을 이해하기 위함이 아니라,
우리가 현장에서 직면하는 각종 상황들에 대해서 비교적 사실적으로 문제에 접근하고 있기 때문에
공감할 수 있는 부분이 많으리라 생각됩니다.

아울러... 개발 현장에 발을 디딘지 얼마 안되는 사람들에게는
오로지 Guru로 성장하는 것만이 길이 아니라, 그에 못지 않게 중요하고 가치있는,
호칭 마저도 그럴싸한(^^) 역할 모델이 있다는 것을 느낄 수 있을 것입니다.
자신의 성향과 관심사를 놓고 한 번쯤 스스로의 방향을 생각해 보는 것도 좋을 것 같습니다.

단, 간과하지 말 것은!!!
어느쪽의 길을 가던 간에, 개발 백그라운드와 폭넓은 기술의 이해,
그리고 이론적인 무장은 필히 갖출 것!