본문 바로가기

Dev.../소프트웨어 아키텍처

[SA강좌] Part 1-10 아키텍트의 역할 정의

아키텍트의 역할 정의

아키텍트는 개발 프로젝트에서 초기에 기술적인 부분에 대하여 의사결정을 진행한다. 또한 프로젝트가 진행될 수 있도록 기술적인 이슈들을 해결한다. 아키텍트가 프로젝트의 각 phase마다 해결하는 문제는 다음과 같다.

표 Ⅱ-1. 프로젝트의 각 phase마다 아키텍트가 수행하는 역할

단계

아키텍트가 수행하는 역할

  • Inception 
  • Architecture prototyping
  • Make/buy trade-offs
  • Primary scenario definition
  • Archtecture evaluation
  • CASE tool, 개발 툴 등 각종 툴 사용 방안
  • 설계 문서 템플릿 결정
  • 설계자와 개발자의 작업 규칙 결정
  • Elaboration 
  • Architecture baselining
  • Primary scenario demonstration
  • Make/buy trade-off baselining
  • Construction 
  • Architecture maintenance
  • Multiple-component issue resolution
  • Performance tuning
  • Quality improvements 
  • Transition 
  • Architecture maintenance
  • Multiple-component issue resolution
  • Performance tuning
  • Quality improvements 

개발 프로젝트에서 아키텍트가 하는 역할은 다음과 같다.

아키텍트는 아키텍처를 만들고 컴포넌트와 컴포넌트 사이의 관계를 파악하고 인터페이스를 설계해야 한다. 프로젝트 관리자는 아키텍트가 아키텍처 문서를 생산하도록 관리해야 한다.

프로젝트에서는 아키텍처에 대한 일차 문서가 만들어지면 아키텍처 팀이 해체되고 각 subsystem에 대한 개발 리더로서 역할을 할 경우가 많다. 이 경우 시스템 전체를 보고 아키텍처를 upgrade하는 역할이 없어진다. 아키텍처가 일차 완성된 후에도 아키텍처는 자주 수정된다. 개발자들은 아키텍처 팀이 만든 문서를 받아들이지 않고 새로운 요구사항이 들어오면 아키텍처의 본래 목적에서 벗어난 방식으로 나름대로 개발하려 한다. 따라서 아키텍처 팀은 프로젝트 끝까지 해체되지 않고 아키텍처에 대한 수정 및 업그레이드에 대한 책임을 져야 한다.

또한 아키텍트는 개발자들이 아키텍처를 이해하도록 도와야 하고 아키텍처 밑에 숨은 결정 사항을 설명해야 한다. 즉 아키텍트는 개발자들에게는 컨설턴트로서 리더로서의 역할을 해야 한다.

이를 정리하면 다음과 같이 정리될 수 있다.

  1. 비즈니스 케이스 생성
    1. 비용과 기존 시스템과의 인터페이스 여부 설정
    2. 시스템의 한계 상황 설정
    3. 비즈니스 목표 설정
  2. 요구사항 분석
    1. 아키텍쳐는 이해관계자들의 요구사항을 어떻게 반영할것이냐는 점이다.
    2. 기존 시스템을 어떻게 분석할 것인가?
    3. 프로토타입은 어느 수준까지? 어떻게?
    4. 품질요구사항에 따르는 아키텍쳐의 기준은 어떻게?
  3. 아키텍쳐 구축
    1. 새로운 아키텍쳐를 만들것인가?
    2. 기존 아키텍쳐를 선택할 것인가?