[소프트웨어 아키텍트] 아키텍트 성향 3가지 총정리

프로젝트를 관리하는 아키텍트 성향은 3가지로 나눠지게 되는데 내 맘대로 아키텍트, 유체이탈 아키텍트, 유능한 아키텍트 구분할 수 있다. 각 성향별 특징에 대해서 알아보자!

내 맘대로 아키텍트

내 맘대로 아키텍트의 경우 소프트웨어 개발 프로세스의 세세한 부분을 일일이 통제 하려고 하는 아키텍트를 칭한다. 이런 아키텍트가 내리는 결정은 하나같이 세부적으로 저수준의 관한 내용이라서 개발팀에 과도한 제약을 초래 한다.

내 맘대로 아키텍트의 경우 개발자가 할 수 있는 일에 대해서도 뺵뺵하게 본인이 하도록 설정을 하고 명명 규칙, 클래스 설계, 매서드 길이와 같은 내용을 엄격하게 제한하고 슈드코드까지 친절하게(?) 짜주는 아키텍트라고 볼 수 있다. 이렇게 내맘대로 모든 아키텍트를 설계 하면 개발자는 좌절감에 빠지고 더 이상 아키텍트를 존경하지 않는다.

특히 개발자에서 아키텍트로 전향한 사람이 이런 사람이 되기 쉬운데 아키텍트의 역할은 애플리케이션 컴포넌트 구성 요소를 만들고 컴포넌트간 상호 작용을 결정하는 일이다. 개발자는 이런 컴포넌트를 가져와 클래스 다이어그램을 및 설계 패턴을 사용해 최선에 구현 방안을 결정하는 것이다. 근데 최근까지 개발자로 있었던 아키텍트의 경우 이런 세세한 것 까지 본인이 직접하고픈 유혹에 빠지기 쉽다.

유체이탈 아키텍트

유체이탈 아키텍트의 경우 내 맘대로 아키텍트와 정반대인 경우이다. 이 아키텍트의 경우 아키텍처를 수립할 때 거의 나몰라라 하는 아키텍트 이다. 이런 아키텍트는 아키텍처 초안이 완성되면 개발팀과 연락을 끊기고 소통이 안되는 케이스라고 볼 수 있다.

이런 사람들은 머리가 꽉 막힌 사람들이므로 팀을 리드하거나 가이드하는 일은 애당초 불가능 합니다. 그리고 이런 사람들은 네모 몇개를 그리고 아키텍처라고 말하는 사람들이다. 가짜 아키텍처를 그린다고 볼 수 있다. 또한 이런 아키텍트들의 아래와 같은 징후를 나타낸다.

• 비즈니스 영역, 비즈니스 문제, 기술을 온전히 이해하지 못한다.
• 소프트웨어 개발 실무 경력이 부족하다.
• 아키텍처 솔루션 구현에 함축된 의미를 전혀 신경 쓰지 않는다.

이러한 아키텍처가 안되기 위해서는 프로젝트에 쓰이는 기술을 익히고 비즈니스 문제/영역을 잘 이해하려고 노력해야 합니다.

유능한 아키텍트

마지막으로 유능한 아키텍트 이다. 이 아키텍트는 개발팀에 적절한 제약조건과 경계를 설정하고 팀원들이 서로 잘 협력할 수 있도록 독려하며 그들을 올바른 수준으로 가이드 합니다. 또 팀이 용도에 맞는 도구와 기술을 보유하고 있는지 확인하고 개발자들이 목표를 달성하는데 걸림돌이 될 만한 요소를 제거 합니다. 아래는 유능한 아키텍처가 되기 위한 몇가지 조건 이다.

팀원 간 친밀도

팀원들이 친절하다면 스스로 조직화하기 시작하므로 덜 제어가 덜 필요하고, 그 반대일수록 팀원이 협업하고 파벌을 없애기 위한 더 많은 제어가 필요 합니다.

팀 규모

팀이 커질 수도록 더 많은 제어가 필요하고, 팀이 작을수록 제어가 덜 필요 합니다.(큰팀 : 12명 이상, 작은팀 : 4명 이하)

전체적인 경험

시니어에 경우 제어가 덜 필요하고 주니어의 경우 어느정도 멘토링을 하면서 제어를 해야 합니다.

프로젝트 복잡도

복잡도가 높은 프로젝트를 수행하려면 팀에 더 많은 관여를 해야 하고 복잡도가 낮은 프로그램이면 별로 제어할 필요가 없습니다.

프로젝트 기간

프로젝트 기간이 길수록 더 많은 제어가 필요하고 프로젝트 기간이 짧을수록 제어가 덜 필요 합니다. 직관적으로 보면 짧은게 제어가 많이 필요 할 수 있지만 단기 프로젝트(2개월)를 진행한다고 할때 아키텍트가 여러가지 제어를 하면 괜스래 더 방해가 될 수 있습니다. 그래서 유체이탈 아키텍트처럼 어느정도는 덜 제어를 해야 할 것 입니다. 반면 2년짜리 프로젝트를 진행한다고 가정하였을때 시간이 여유로우니 개발자는 긴장을 풀고 어떤 긴박감도 갖지 않은채 커피를 먹으며 휴가계획을 짜고 있을 것 입니다. 따라서 프로젝트를 적시에 진행시키고 복잡한 작업을 진행하려면 아키텍트가 더 많은 제어를 해야 합니다.