아키텍트 이야기

아키텍트 이야기
야마모토 케이지 지음, 이지연 옮김, 이용원 외 감수 / 인사이트 / 2007년 4월

유난히 정년이 짧은 프로그래머, 개발자라는 직업. 보통 30대 후반이 넘어가면 개발자로서는 늙었다는 말을 많이 들으며, 자의 혹은 타의에 의해 개발자의 길을 벗어나 관리직 등의 개발이 아닌 다른 길을 찾아야 하는 경우가 많다. 프로그램 개발이라는 것이 창의력을 많이 요구하는 것이다 보니 이런 풍토가 생겨나고 이것이 거의 정해진 것인 양 받아들여지고 있다. 안타깝지만 이것은 현실이다.

이 정도 경력이 되면 이전에는 눈에 보이지 않던 것들이 서서히 보이기 시작하고 개발 프로젝트의 전체적인 흐름 파악도 어느 정도 될 시점인데, 이제는 프로그래밍을 그만 둬야 하나? 지금까지 익혀온 기술과 눈치(?)가 아깝게 느껴진다. 프로젝트 관리자 등을 맡아서 프로젝트의 성공을 위해 일을 할 수는 있지만, 지금까지 쌓아놓은 개발 노하우는 어디에 써야 한단 말인가. 그냥 그대로 묵혀놔야 할까. 아깝다.

나이가 먹어서도 계속 프로그래밍을 할 수 있는 방법은 없을까? 어느 정도 실력과 연륜을 쌓은 개발자로 현장에서 일할 수 있는 방법은 없을까? 이 책에서는 하나의 길을 제시하고 있다.

바로 아키텍트라는 것인데, 아키텍트는 아래와 같이 정의할 수 있다.

아 키텍트는 아키텍처를 설계하고 그것을 시스템 개발 전체에 미치게 하는 것이 임무다. 개발팀의 중심인물로, 팀원을 이끈다는 의미에서 '프로젝트 리더(PL)'와 겹치는 부분도 있지만, 시스템 기획 같은 초기 단계에 기술 전문가로 참여하거나, 시스템이나 프로젝트의 특성에 맞춰서 문서세트를 구성하는 등, 활동무대는 더욱 폭넓다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 11쪽.

그럼 아키텍처는 무엇인가? 아는 사람은 다 아는 이 단어는 건축에서 기초와 골격에 비유할 수 있다. "시스템 전체의 대략적인 구성과 거기에 구체적인 구현지침을 합친 개념" 정도라고 이 책에서는 이야기하고 있다.

이 책에서 이야기하는 아키텍트의 주요 업무로는 다음과 같은 것들이 있다.

• 요구사항 정의에 참여
• 아키텍처 설계
• 프레임워크 준비
• 문제 해결
• 테스트 지원
• 개발 이외의 업무 지원

이 내용들을 보면 프로젝트 관리자(Project Manger, PM)의 역할과 비슷해 보이는데, 프로젝트 관리자는 프로젝트가 원활하게 수행되도록 하는 데 중점을 두는 반면, 아키텍트는 설계와 프레임워크 개발 등 프로젝트의 기술적인 핵심 부분을 담당하게 되는 역할이라고 할 수 있다.

아키텍트가 하는 일은 결정된 명세를 프로그래밍하는 프로그래머나, 프로젝트의 원활한 진척을 계획하는 프로젝트 관리자의 업무와 다르다. 기술적 관점에서 시스템 전체를 넓게 바라볼 수 있는 존재가 바로 아키텍트다. 아키텍트라는 말은 '책임 설계자'로 번역하는 것이 정확할 것이다. 아키텍트의 역할이 애플리케이션의 설계와 구현 전체를 책임지고 개발팀을 이끄는 것이기 때문이다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 19쪽.

이 책은 실제 개발 프로젝트에서 일어날 만한 일을 예로 들어 아키텍트 C가 이를 어떻게 풀어나가며 어떤 일을 하는지를 설명하고 있다. 이 흐름을 따라가면 아키텍트가 주로 어떤 일을 해야 하고 어떤 것들을 알아야 하는지 파악할 수 있을 것이다. 이 책에서도 강조하고 있는 부분은 개발자라고 해서 개발만 잘 하면 되는 것은 아니라는 것이다. 개발자가 아키텍트의 역할을 제대로 수행하기 위해서는 무엇보다도 비즈니스를 이해하고 의사소통 능력이 필요하게 된다.

아키텍트는 기술력을 토대로 시스템 개발과 IT를 활용하는 비즈니스에 이르는 넓은 범위에 대해 깊은 이해가 있어야 한다. 이러한 아키텍트의 역할을 이미 다양한 비즈니스 현장에서 요청하고 있다. 비즈니스에 대한 IT의 영향력이 커지면 아키텍트의 필요성 역시 높아질 것이다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 214쪽.

물론 아키텍트는 개발팀 내에서 최고 개발자이기 때문에 기술적인 능력도 뛰어나야 한다. 단순히 자신이 알고 문제를 해결하는데 끝나는 것이 아니라, 이러한 기술력을 바탕으로 다른 팀원들이 해결하기 힘든 경우 도와줄 수 있어야 하며, 기술적인 문제에 대해 개발자가 아닌 다른 부서의 사람들을 이해시킬 수 있어야 한다. 즉, 기술력 뿐만 아니라 이를 풀어서 설명할 수 있는 능력과 의사소통 능력이 중요하다는 말이다.

아키텍트는 책임 설계자이며 최고 개발자로서, 개발팀을 이끌 수 있을 정도의 전문적인 기술과 역량이 요구되는 역할이다. 기술에 대해 잘 알고 있는 팀원들을 결속시키기 위해서는 그들이 인정할만한 기술력이 필요하다. 이와 동시에 개발팀과 비즈니스의 가교 역할을 해야 한다. … 아키텍트는 시스템 개발이라는 활동에서 기술자와 비즈니스 관계자들이 서로 협조할 수 있도록 조정자 역할을 한다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 215쪽.

기술자가 흔히 하는 실수는 전문용어를 남발하는 것이다. 그 기술을 아는 사람들끼리는 전문용어를 쓰는 것이 의사소통에 도움이 될 지 모르겠지만, 이런 기술을 모르거나 익숙하지 않은 사람에게 자세한 설명 없이 전문용어를 무분별하게 쓴다면 이야기를 하기 싫다는 뜻으로 받아들여지기 딱 좋을 것이다. 전문용어는 상대를 봐가면서 쓰도록 하자. 전문용어를 쓰지 않고도 상대에게 내가 하고자 하는 말을 제대로 전달할 수 있어야 제대로 된 기술자가 아닐까?

비기술자인 결정권자에게 기술자의 의견을 적절하게 전달하는 데는 어려움이 많다. 기술적으로 정확한 판단과 근거, 부적절한 판단이 가져올 위험요소를 이해시키려면, 프로그램을 한 행씩 지적하며 설명하거나, 프로그램 언어나 제품 등에 대해 자세하게 가르쳐야 하기 때문이다. … 비기술자에게 의견을 전달할 때는 전문용어를 되도록 쓰지 않고, 도표나 비유를 이용하여 설명한다. 문제가 복잡한 경우에는 개요만을 정확히 전달하는 방법으로 앞서 말한 실수를 피할 수 있다. 물론 때에 따라서 정확하고 자세하게 설명하지 않아도 되는 상황도 있을 수 있다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 181쪽.

아래는 이 책을 감수하신 한의근님이 책의 첫머리에 하신 말씀이다. 그리고, 내가 하고 싶은 말이기도 하다.

기술자의 정년은 마흔이라는 말을 들을 때마다 안타깝다. 나이가 많아지면 그만큼 경륜이 생기는데도 관리직 일을 맡아 경험을 충분히 활용할 수 없게 되는 경우를 적지 않게 보아 왔다. 현재 가지고 있는 소망 중 하나는 나이가 들어서도 장인 기술자로 남고 싶다는 것이다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 6쪽.