2008. 10. 10. 10:40

소프트웨어 개발자의 로망, 아키텍트(Architect)!

소프트웨어 개발은 그 학문적 특질이 유사한 건축과 연관관계를 맺고 있다. 소프트웨어 개발의 특정 조건에서 발생되는 규칙적인 문제를 해결하기 위한 디자인 패턴도 이런 건축학에서 비롯되었다(건축학의 역사가 더 오래된 만큼 당연한 결과.). 건축 설계자를 영어로 아키텍트(Architect)라고 하듯 소프트웨어 개발 역할에도 아키텍트가 존재하는데, 여기서 그 역할을 소개하고자 했으나, 좋은 책이 있어 떠중이의 말은 줄이고 그 책의 목차나 소개하고자 한다.

책, 아키텍트 이야기(야마모토 케이지 저)의 목차


책을 읽어볼 요량이 없는 분들을 위해 아키텍트의 두가지 측면만 간단히 요약, 설해보도록 하겠다. 첫째는 개발 단계별로 필요한 공수고, 둘째는 단계별 업무 분야다.

소프트웨어 개발 단계를 크게 4단계(요구분석, 설계, 구현, 테스트), 개발 역할을 6 분야(요구분석 담당자, 아키텍트, 프로그래머, 인프라 담당자, 테스트 담당자, 프로젝트 관리자)로 나누었을 때 그 공수는 다음과 같다.(숫자가 높을수록 들어가는 공수(工數)가 많다.)

 요구분석 담당자
5
3
2
1
 아키텍트 3
5
2
1
 프로그래머  1 3
5
3
 인프라 담당자
 2 1
1
2
 테스트 담당자
3
1
4
5
 프로젝트 관리자
 3 2 2
3
  요구분석 단계
설계 단계
구현 단계
테스트 단계

아키텍트의 요구분석 단계에서는 프로젝트 관리자의 비지니스 마인드로 프로젝트를 바라보는 능력이 아키텍트에게도 요구되며, 요구분석 담당자에게는 기술 전문가의 입장에서 조언하는 조언자의 역할을 수행한다. 여기서 아키텍트는 기술 관련 위험요소를 개발 초기에 해결 혹은 해결을 위한 계획을 수립해야 한다. 비기능 요구사항(사용자가 사용하는 기능 외 시스템이 요구하는 기능)도 적극적으로 제안할 필요가 있다.

설계 단계에서 아키텍트는 개발 명세 설계에 참여하게 되는데 명세 설계 주 담당자와 더불어, 기술에 편중되지 않고 효율적인 사용자 중심 설계가 되도록 노력해야 한다. 그러나 주요 업무는 역시 '아키텍처 설계'이다. 아키텍처는 기술 문제를 정리해야 하므로 초기에 검토되어야 하고, 요구분석 단계에서 나온 요구사항을 해결할 수 있어야 한다. 이 설계서는 개발자를 위한 최초의 문서가 되며, 이후 프로젝트 산출물의 표준양식이 된다. 따라서 개요를 확실히 이해해야 기술 요소를 정확하게 설명할 수 있고, 팀원과의 의사소통을 원활히 하여 설계서에 명시된 바에 따라 제대로 된 구현을 할 수 있다.

구현 단계에서 아키텍트는 실제로 구현하는 프로그래머의 중개자 역할을 수행하게 된다. 설계된 아키텍처를 적용할 수 있는 프레임워크를 제공하여 아키텍처가 효과적으로 지켜질 수 있도록 하고, 팀원의 수준에 맞춰 역할을 분담한다. 그리고 팀원들의 프레임워크에 대한 적극적 참여를 동기 부여하여, 아키텍처나 프레임워크에 대한 피드백을 받도록 하고, 프레임워크가 팀원들의 수준과 프로젝트 목적에 맞춰지도록 조율을 한다.

테스트 단계에서 아키텍트의 실질적 공수는 적다. 테스트의 주인공은 테스트 담당자이기 때문이다. 하지만 아키텍트는 구현 단계에서와 같이 중개자로서 팀의 윤활유 역할을 해야한다. 나아가 앞의 설계 단계에서 단위 테스트와 결합 테스트를 효율적으로 진행할 수 있는 아키텍처를 테스트 담당자와 함께 구현 단계 전에 미리 생각해보는 것도 좋은 방법이다.

10년 뒤에도 기술자로 일하고 싶은가? 소프트웨어 설계를 넓은 안목으로 보라. 소프트웨어 구현(코딩)이 즐거움을 주는 것은 사실이지만, 개발이 취미거나 프리랜서에 해당하지 않고, 오래 회사 밥을 먹으며 개발을 하고 싶다면, 숲을 보는 더 큰 즐거움을 좇는 혜안이 필요하다.

Matrix - Neo vs. Architect


Comment 12