한빛출판네트워크

아키텍트의 요구 사항은 건축가가 건물을 설계하고 짓는 것보다 훨씬 더 빨리 변경되고 도구와 기술도 원하는 대로 변경할 수 있다. 아키텍트가 만들어내는 결과물이 특정 시점을 기준으로 고정되는 일은 없다. 소프트웨어가 일단 실운영 환경production environment에 출시된 후에는 사용되는 방식에 따라 계속 진화할 것이다. 즉, 아키텍트는 일단 고객의 손에 전해진 소프트웨어가 그대로 정체되는 일 없이 고객의 요구에 맞게 반응하고 적응해야 한다는 사실을 받아들여야 한다. 그러므로 아키텍트는 처음부터 완벽한 최종 제품을 만들려하기보다는 추가 학습을 통해 적합한 시스템이 생성되고 지속해서 성장할 수 있는 프레임워크를 만드는 데 보탬이 되도록 생각을 전환해야 한다.

지금까지 아키텍트의 직업과 다른 직업을 지나치게 비교하지 않도록 경고하는 데 이 장의 많은 부분을 할애해왔지만, 필자는 우리가 바라는 IT 아키텍트의 역할을 더 잘 요약하는 다음의 비유를 좋아한다. 에릭 도넌버그Erik Doernenburg(옮긴이 주_ 소트워크스(Thoughtworks) 사의 기술 책임자이자 소프트웨어 개발자, 컨설턴트다. 그의 블로그(http://erik.doernenburg.com)와 강연(특히 Architecture without architecture)에서 많은 영감을 얻기 바란다.)는 아키텍트의 역할을 건축가보다는 도시 설계자town planners에 가까운 의미로 접근해야 한다는 아이디어를 처음으로 필자와 공유했다. 도시 설계자의 역할은 이전에 심시티SimCity 게임을 해봤던 사람이라면 누구에게나 친숙할 것이다. 도시 설계자의 역할은 다양한 정보 소스를 파악하고, 현재 시민의 요구에 부응함과 동시에 미래의 용도까지 고려하면서 도시 배치를 최적화하는 것이다. 도시 설계자가 도시 발전에 영향을 미치는 방식은 흥미롭다. 그는 ‘특정 건물을 거기에 만들라’고 하는 대신 도시를 구역화한다. 심시티 게임에서와 마찬가지로 도시 일부를 산업 구역이나 주거 구역으로 지정할 수 있다. 정확히 어떤 빌딩을 세울지는 다른 이들이 결정할 일이지만, 공장은 산업 구역에 세워야 한다는 규제는 존재한다. 도시 설계자는 구역 내에서 발생하는 일에 대해 지나치게 염려하기보다는 사람이나 공공설비가 구역 간을 어떻게 이동할 것인가에 대해 고민하는 데 더 많은 시간을 할애할 것이다.

많은 사람이 도시를 살아 있는 생명체라고 여겨왔다. 도시는 시간이 흐르면서 변화한다. 거주자의 다양한 생활 방식과 외력에 의해 도시는 바뀌고 발전한다. 도시 설계자는 이 같은 변화를 예측하기 위해 최선을 다하겠지만, 도시에주 발생하는 모든 측면을 직접 통제하려는 노력은 헛수고임을 이미 알고 있다.

소프트웨어와의 비교 역시 명확하다. 사용자가 우리 소프트웨어를 사용하는 한 우리는 그에 대응하고 변화해야 한다. 아키텍트는 앞으로 발생할 모든 일을 예측할 수 없는 만큼, 모든 사태에 대해 미리 계획하기보다는 과욕을 부리려는 충동을 절제하고 변화를 받아들이도록 해야 한다.

도시, 즉 시스템은 이용자 모두를 위한 즐겁고 행복한 장소가 되어야 한다. 사람들이 흔히 잊어버리는 한 가지는 아키텍트가 만드는 시스템이 단지 사용자만 수용하는 것이 아니며, 그곳에서 일하는 개발자와 운영자, 그리고 요청에 따라 시스템을 변경하는 업무를 가진 사람들까지 수용한다는 점이다. 프랑크 부쉬만Frank Buschmann(옮긴이 주_ Simens AG 사의 수석 소프트웨어 엔지니어로서 『Pattern-Oriented Software Architecture』 시리즈의 저자다.)의 용어를 빌리자면, 아키텍트는 개발자도 거주할수 있는habitable 시스템을 만들 의무가 있다.

아키텍트와 마찬가지로 도시 설계자 또한 그의 계획이 수행되지 않는 때가 언제인지 알아야 한다. 도시 설계자는 권위적이지 않은 만큼, 지시 사항을 바로잡는 데는 최소한으로 관여해야 한다. 그러나 누군가가 하수처리장을 주거지역에 지으려 한다면 도시 설계자는 그것을 중단시킬 수 있어야 한다.

그러므로 도시 설계자로서의 아키텍트는 방향 자체는 개괄적으로 설정하되, 특정 경우의 세부 구현에 대해서만 매우 구체적으로 관여해야 한다. 시스템이 현재의 목적에 들어맞을 뿐만 아니라 미래의 플랫폼으로서 적합하다는 것을 보장해야 하고, 나아가 사용자와 개발자가 똑같이 행복해지도록 해야 한다. 이것은 꽤 무리한 요구처럼 들린다. 과연 아키텍트는 어디서부터 시작해야 할까?