본문 바로가기

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

[SA강좌] Part 1-14 소프트웨어 아키텍처 팀 운영 시 문제점에 대한 해결방안

소프트웨어 아키텍처 팀 운영 시 문제점에 대한 해결 방안

이 장에서는 소프트웨어 아키텍처 팀 운영 시 발생하는 다양한 문제점에 대한 해결 방안을 제시한다.

리더쉽에 대한 명확한 정의가 없는 경우

개발 조직에서는 조직원에게 명확한 권한과 책임을 부여하는 것이 매우 중요하다. 개발 팀이 지리적으로 두 개로 나누어져 있는 경우 각 팀마다 자체적으로 아키텍트의 역할을 하는 사람이 생기게 되며 이 경우 두 아키텍트 사이에 의견 충돌이 발생할 수 있다. 이 경우 프로젝트 관리자는 각 개인의 역할을 명확히 정의하고 지리적으로 나누어진 각 사이트에 테스팅 팀, 개발팀, 아키텍트 팀을 분배해야 한다. 즉 두 사람이 같은 역할을 소유하지 못하게 한다.

소프트웨어 아키텍트의 보고체계

소프트웨어 아키텍트는 프로젝트 팀장에게 직접 보고하는 경우가 많다. 그러나 너무 상세한 수준까지 보고하면 이 보고는 종종 실패하게 된다. 관리자가 기술적으로 불일치한 것을 검토할 수 있도록 보고서는 적당한 레벨을 유지해야 한다. 반대로 너무 추상적으로 보고하면 소프트웨어 아키텍트가 개발팀에서 소외 당하게 된다. 따라서 보고체계를 다음과 같이 설정하는 것이 좋다.

그림 Ⅱ-8. 소프트웨어 개발 조직의 보고체계


그림을 보면 소프트웨어 아키텍트는 소프트웨어 개발 팀장에게 보고하고 하드웨어 아키텍트는 하드웨어 팀장에게 보고한다. 소프트웨어 개발팀장과 하드웨어 팀장은 결정한 사항에 충돌이 없는지 검사해야 한다.

소프트웨어 아키텍트와 개발팀의 지리적인 위치

지역적으로 분산된 개발 환경에서는 소프트웨어 아키텍트는 중요한 개발팀과 같은 곳에서 근무하거나 여러 개발팀을 계속 방문해야 한다. 지역적으로 분산되어 있을 경우 특정 사이트에서 기술적인 문제가 많이 발생하기 때문에 그 사이트의 기술자 중 한 사람을 아키텍트로 선정하여 여러 사이트를 방문하면서 기술적인 이슈를 해결하도록 해야 한다.

소프트웨어 아키텍트 팀의 규모

프로젝트 관리자가 종종 기술 리더가 아닌 사람을 아키텍트 팀에 넣는 경우가 있고 스스로 기술 리더가 아니면서 아키텍트 팀에 포함되기를 원하는 사람들이 있다. 이 경우 소프트웨어 아키텍트는 아키텍트 팀의 규모를 제어할 수 있어야 한다. 즉 소프트웨어 아키텍트는 팀 규모에 대한 가이드라인을 작성하여 프로젝트 관리자와 대화할 수 있어야 한다. 팀이 지나치게 크거나 기술 리더가 아닌 사람이 팀에 포함될 때 소프트웨어 아키텍트 팀의 효율성은 떨어진다.

팀에 불필요한 사람을 포함시키지 않도록 아키텍트 팀의 모임에는 다양한 사람들이 참가하는 것을 허용하고 결정은 아키텍트 팀에서 내려야 한다. 아키텍트는 팀 내 대화와 정보 공유, 의사 결정에 대한 규칙을 가지고 있어야 한다.

종종 아키텍트 팀에서 능력 있는 사람이 배제되는 경우가 있다. 따라서 초기에 3-4명 정도의 인원으로 아키텍트 팀을 구성하고 이슈가 발생하여 사람이 필요할 때 추가해야 한다. 팀에서 사람을 배제하는 것은 매우 어렵기 때문에 초기에 팀 구성을 잘 해야 한다.

소프트웨어 아키텍트가 다른 프로젝트로 이동하는 경우

종종 소프트웨어 아키텍트가 프로젝트가 끝나기 전에 역할을 다 했다고 생각하고 다른 프로젝트로 옮겨가는 경우가 있다. 그러나 프로젝트가 완료되기 전에 소프트웨어 아키텍트를 새로운 프로젝트로 옮기는 것은 피해야 한다. 첫째 이유는 작성한 소프트웨어 아키텍처가 효과적인지는 시스템을 운영하기 전에는 알 수 없으며 최종 사용자의 불만 사항을 알아야 하기 때문이다. 소프트웨어 아키텍처의 효과를 확인하지 않고 다른 프로젝트로 옮기게 되면 새로운 프로젝트에서도 결함이 있는 아키텍처를 사용하게 된다. 따라서 소프트웨어 아키텍트는 개발팀에 합류하여 소프트웨어 아키텍트의 역할을 계속 수행하거나 기술적인 리더로서 역할을 수행해야 한다.