free-vahn

본문

우사의 길
번 역 : 서석호
출 처 : Applied Software Architecture

12.1 Creating a Vision
-유능한 architect가 되기 위해서는 비젼이 필요하다. (최종 시스템이 어떤 모습일지, 용도가 무엇인지, 그리고 나머지 회사에서 추진 중인 과제 및 비즈니스적 목표와 연관성이 짙은지, 등등...) architect는 application domain (**소프트웨어 사용 용도?**) 과 시장 정보를 잘 알고 있는 것이 중요하다. 이를 배우든지, 아님 다른 자원을 찾아야 한다. 이는 좋은 소프트웨어 아키텍쳐를 디자인 하는데 중요하기 때문이다. architect로서 당신은 당신 제품이 갖춰야 할 사양과 한계를 알아야 한다. 당신은 이를 이용하여, 시스템의 전체적인 견해를 만들 것 이다. 처음에는, 각각 컴포넌트가 대강 무엇을 할 것인지를 생각할 것이다. 하지만, 이를 완성하기 위해서는 노력 이상의 것이 필요하다. 기초적인 아이디어들을 구상하고, 디자인이 필요로 하는 요소들을 생각하고, 피드백을 받고, 아이디어들을 약간 고치던가, 다시 도전 해야 할 것 이다. 이는 무한한 반복의 과제이다. 종종 새로운 기술을 쓰는 것이, 새로운 시장들을 공략하던가, 시장에 반응하는데 빠르다 (**time-to-market ... 확실하지 않으나 제 생각에는...**). 만일 프로젝트 메니저와 architect가 진정으로 이 과제가 시행될 수 있다고 생각하지 않는다면, 다른 과제를 찾아 나서는 것이 가능성이 없는 과제와 실랑이를 버리는 것 보다 낳기 때문이다. architect의 무한한 상상력을 지속 시키려면, 그들은 지속적으로 자신이 속해 있는 분야의 신기술들을 알고 있어야 한다. 당신은 회사의 기술들은 물론 시장의 신기술들을 알고 있어야 한다. 제품의 사용자들 또한 영감(?)중에 하나이다. 사용자의 견해를 이해하기 위해서는 당신은 에플리케이션, 마케팅, 그리고 커스터머 전문가와 이야기해야 할 것이다. 하지만, 사용자의 사이트를 직접 가보는 것 만큼 좋은 것이 없다. 사용자가 어떻게 제품을 사용하는지, 사용자가 어떠한 문제점들과 맞닥들이고 있는지, 또 어떤 부분의 개선을 원하는지를 직접 알 수 있기 때문이다. 한번 첫 아키텍쳐 디자인이 설립되면 (종종 종이 한쪽에) architect는 이를 감독하고, 정리-진행하고, 결정하고, 이행시기는 일을 해야 한다. 당신은 프로젝트 메니저와 함께 팀을 하이레벨 디쟈인 부터 제품개발까지 하게 될 것 이다.
architect로서 당신은, 아키텍쳐 디자인의 주요 인터페이스 부분을 정리하고 제어 해야 할 것 이다. 왜냐하면, 당신이 주요 컴포넌트들을 알고 있고, 이것들이 어떻게 서로 조합이 되어 시스템을 이루는지 알기 때문이다. system architect가 시스템의 하드웨어를 설정하지만, 당신이 사양을 정하고 소프트웨어가 전체적인 제품에 어떻게 맞는지를 정하고, 나중에 이 정해진 시스템 인터페이스가 될 수 있다는 것을 정한다. 아키텍쳐의 스케치로 당신은 상업적 구성요소들과 현존하는 소프트웨어를 이용해 시스템을 구상할 것이다. 이 비전을 현실화 하는 과정에서 당신은 새로운 기술을 만들어 낸다든지 아님 조직에 변화를 가져올 것이다. 당신은 자주 팀에게 새로운 기술을 배우고 소개하는 개척자가 될 것이다. 잘못된 점이나 고쳐야 할 점을 찾을 때마다 당신은 중간에 이들을 팀과 연락하며 고쳐나가야 할 것이다.

12.2
software architect로서 당신은 프로젝트 메니져의 주요 기술 고문이 될 것이다. 그리고 또한 프로젝트 내의 주요 기술들을 결정 짓게 될 것이다. 프로젝트를 전체적으로 책임지고 있는 프로젝트 메너져와 동등한 관계는 아니지만, architect는 프로젝트 메니져와 가깝게 일을 하게 될 것이다. 하지만, 프로젝트 메니져에게는 믿을 수 있는 능력을 가진 architect가 필요하고, 이에게 기술적인 권한을 줘야만 성공할 수 있다. 어떤 프로젝트에는 메니져와 architect를 한사람이 하는 경우도 있다. 이두 임무를 합함으로써 둘중의 하나에만 치우치는 위험성이 있을 수 있다. 하지만, 작은 프로젝트들에서는 이 두 임무가 효과적으로 합쳐질 수 있다. 혹은, 두사람이 (architect와 technical lead -기술자) architect의 임무를 나눠서 하는 경우도 있다.
큰 프로젝트에서는 인터페이스의 조종이 중요함으로, 한사람이 architect의 임무를 다 수행 할 수 없을지도 모른다. 이런 경우에는 그룹의 architect가 system design review board (**?**)를 이룬다. 이들은 전통적인 권한으로 architecture을 완전한 상태로 보전 한다.
table 12.1은 메니져와 architect의 기타 역할들을 적고 있다. 프로젝트 메니져는 프로젝트의 구성과 자본을 확보하고 그리고 스케쥴을 관리한다. architect는 팀을 architecture 디자인과 이행 부분을 감독한다. architect는 기술적인 측면에서 모든 것이 어떻게 연관되어있는지를 알고 있으며, 이 정보를 이용하여, 프로젝트 메니져에게 어떻게 자원과 인력을 배치해야 하는지를 조언한다.
(**table 생략**)
대부분의 프로젝트에서 개발팀 조직은 소프트웨어 개발 조직과 유사하다. 다시 말해, architect가 프로젝트 메니져에게 팀장의 선택과, 섭-시스템 팀의 크기, 필요로하는 능력, 등등의 조언을 하는 능력이 매우 중요하다. 많은 경우에, 하이-레벨 디자인 팀의 맴버들이 나아가서 서브 시스템과 주요 컴포넨트 개발들을 지도한다. architect의 자문들이 이들의 디자인 능력과 잠재적 인력 경영능력 (**people management skills**) 등을 프로젝트 메니져와 다른 메니져들이 요구 할 가능성이 높다.
프로젝트 메니져는 마케팅과 협상을 하고 제품의 필요 조건을 상세한 조건으로 해석한다. architect는 필요 조건들을 설립하지는 않지만, 이를 비평하고 기술적으로 가능한지를 가늠져야한다. 아키텍쳐 디자인이 진형되어가며, architect는 필요 조건을 다시 정의 할 것을 교섭해야 할 지도 모른다. 왜냐하면, 이들 조건을 충족 시키는 것이 불가능 하던가, 다른 더 중요한 요소들과 맞 바꿔야 할지도 모르기 때문이다.
프로젝트 메니져는 직원 관리를 한다. 예를 들어서 해고, 고용, 능력 평가, 봉급, 과 보너스 등을 관리 한다. architect는 지망자 인터뷰와 직원들의 기술적인 능력을 알고 있어야 한다. 둘 다 팀을 프로젝트가 완성 될 때까지 이끈다.
이 둘의 관계가 잘 적용되고 있을 때는, 프로젝트 메니져는 architect의 기술적 자문을 지원하고, 이를 돕기위해 직원들을 교육하며, computer-aided software engineering tools를 사고, 아님 전문가를 고용하여 이를 가능케 한다.
프로젝트 메니져가 제품의 품질을 보장하기는 하나, architect가 디자인의 품질을 지도한다. architect는 상세 디자인과 코드 속의 의존물들이 architecture design에 따르고 있는지를 살피지만, 더욱더 깊이 내려가서 코드가 상세한 디테일 디자인 까지 따르는지를 확일 할 필요는 없다. 이는, peer review (**동료들이 서로의 일을 검토하는 것**) 상태에서 더 효과적이기 때문이다.
프로젝트 메니져는 프로젝트 팀의 생산력을 제는 책임을 진다. architect는 디자인의 목표를 달성할 수 있도록 하는데 중점을 둔다. 이를 실현하기 위한 한가지 방법으로는 팀내의 가이드 라인(코드와 템플리트)의 확립과 시행이다.

12.3
하이 레벨 디자인 팀은 주로 소프트웨어 architect와 서브시스템의 팀장이나, 기술쪽 전문가, 혹은 분야 전문가들로 이루어진다. 소프트웨어 architect로서 당신은 디자인 팀의 리더이며, 초기의 디자인 결정들을 내려야하는 사람이다. 여러 가지의 서로 충돌하는 요구들의 균형을 정하고 팀이 이들 교환들을 잘 할 수 있도록 지도 해야한다.
architect로서 당신은 어느 정도 분야의 지식을 가지고 있어야 하나, 전문가여야 하지는 않다. 왜냐 하면, architect는 도메인과 소프트웨어 엔지니어링 사이를 잇는 다리이기 때문에 당신은 도메인에 관한 지식으로 디자인 교환을 분석하지만, 디자인을 실행하는 지식 까지는 필요 하지 않다. 당신에게 도메인/분야 경험이 부족하다면, 자주 분야의 전문가에 의존할 수 있다.
당신은 항상 당신에게 필요한 정보나 완전한 전 팀의 일치를 갖고 있지는 못하겠지만, 당신은 시간에 적합한 판단을 내려 데드라인을 맟춰야 한다. 토론을 종료하고 결정을 내려야할 시기가 왔다는 것은 당신이 결정을 하는 것이다.
당신은 빨리 전체적인 결정을 내리고 그에 따른 위험을 찾아 내야 한다. 다른 결정들을 정확하게 시간에 맟춰내리는 것에도 기술이 있다. 이는 결정을 최대한 늘려, 너무 늦지 않게, 내리는 것이다. 장점은 디자인이 융통성이 유지되고, 좀 더 유연하게 변화된 필요 조건이나 다른 요건들에 맟춰 질 수 있다. 하지만, 명심해야 할 점은 나중에 고칠 수 있는 결정을 내리는 것이 결정을 아주 안내려 개발을 지연 시키는 것보다 훨 유용하다는 점이다.
스케줄에 의존하는 요소들을 보고 결정을 내려야하는 시기를 찾도록 하자. 당신의 자원에 앞서 일하고, 당신의 목표의 뒤에서 일함으로서, 당신은 당신의 결정들로 몇가지 제약들을 해결 할 수 있다. 당신은 제품 출시의 마케팅 우선도와 프로젝트 스케줄, 그리고 신기술이 미칠 영향들을 알고 있어야 한다. 기술의 선택은 다른 선택들에도 영향을 미친다는 것을 알아야 한다. 예를 들어서, 소프트웨어 플렛폼의 선택은 상업적 도구 선택이나 팀의 교육 과정에 영향을 미친다. 이 모든 것들이 다 구성 요소 발표 계획에 들어가는데, 이는 시스템 개발 전략을 결정한다.
architect로서 당신은 전체적인 글로발 결정을 책임진다. 당신은 마이크로매니져가 되기에는 시간이나 자원이 턱 없이 부족하다. 당신은 결정의 부분부분을 특정 분야의 전문가에게 맏기고, 디자인과 이행 작업 및 결정을 팀에게 맏긴체 팀을 필요할 때 감독해야 한다.

12.4
software architect는 소프트웨어 개발 팀 (software development team)의 감독 역할을 한다. 일단, 마케팅이 제품의 개념과 제품의 필요 사항들을 정하고 나면, architect는 프로젝트 메니져와 함께 디자인 팀을 구성한다. 소프트웨어 개발은 주로 소수의 인원으로 하이 레밸 디자인 부터 시작을 한다. 이 시점에서 더 많은 인원을 끌어 들이고 싶은 충동을 자제하라. 이 페이즈에서는 작으면 작을 수록 좋다.
직원 보충은 로우레밸 디자인과 이행 (implementation) 작업이 설립되면서 더해진다. 프로젝트의 크기에 따라, architecture 디자인은 특정 팀 리더나 직원에게 배정하기 좋은 시점이다. architect는 프로젝트 메니져와 함께 일하며 각 팀 멤버들에게 작업을 할당한다. 우리는 (저자) 당신이 초기의 개발 시점에서 아키텍쳐 디자인의 컴포넨트들을 프로토타입으로 감정하길 권장한다. 이는 프로젝트의 위험성을 낮추고 새로운 팀 멤버들의 아키텍쳐와 기술 교육에 도움을 주기 때문이다.
어찌 되었든, 소프트웨어의 아키텍쳐 디자인을 완성하는 것이 전부는 아니다. architect로서 당신의 임무는 아키텍쳐의 디자인에서 시작 된다; 끝나는 것이 아니다. 당신은 모두가 이 디자인을 이해하는데 도움을 줘야하고, 실질적으로 이행/임플라멘트 될 수 있다고 설득해야 한다. 이를 행하기 위해서는 당신은 팀 멤버들과 어느 정도의 대화 관계를 설립해야한다. 이로 그들에게 중요한 디자인 요소들을 가르치고 그들의 의견을 들어야 한다. 여기서 매우 중요한 것은 그들을 끌어들이는 것이다. 또한 당신은 주고 받고 관계의 감독과 더 독재적인 역할의 결정자 사이에 균형을 줘야 한다.
팀 멤버들은 상세하게 서브 시스템을 디자인 할 수 있을 정도로 소프트웨어의 아키텍쳐 디자인을 잘 알고 있어야 한다. 이를 시작하는 한가지 방법은 시스템의 나머지에 그들의 서브 시스템과 그 인터페이스의 분해를 디자인 하게 하는 것이다. 그들에게 이행/임플레멘트에 필요 시간을 어림하게 하는 것을 프로젝트 메니져가 스케줄을 정하는데 유용하게 사용될 것이다. 이 연습은 또한 각 팀 멤버들에게 아키텍쳐 디자인과 개발 스케줄에 수요권을 느끼게 해줄 것이다.
좋은 감독관의 기질 중 하나는 언제 방종해야 하는지 아는 것이다. architect로서 당신은 디자인의 전체적인 구조를 공급해야 하지만 동시에 각 팀 멤버들에게 자기가 맡은 부분의 시스템을 디자인하는 책임과 과제를 맡겨야 한다. 무엇이 적당한지는 디자인의 진기함, 관련된 위험성, 그리고 팀의 능력에 따라 매우 주관적인 것이다. 가끔 당신은 팀 멤버들의 사소한 실수를 용납할 수도 있을 것이다. 이것을 통해서 그들이 배우고 또한 이 실수가 프로젝트의 목표를 위험에 빠뜨리지 않는 이상 말이다.
시스템이 발전해감에 따라, 당신은 아키텍쳐의 정직함을 유지하는데 기여해야 한다. 당신의 임무는 제품의 유지 단계에 들어 가며 바뀐다. 이 단계에서는 당신의 개입이 덜 필요 할 것이다. 하지만, 가끔은 원래 디자인에서 동떨어지기 시작해 더 이상 유지가 안되는 아키텍쳐를 다시 조직 하기 위해 많은 노력을 기여해야 하는 수도 있다. 아니면, 현존하는 시스템이 새로운 제품버전으로 업데이트 되어서 새로운 제품 목표를 이에 수용하기 위해 아키텍쳐가 제구조 되는 경우에도 많은 노력이 필요하다. 요즘 대부분의 소프트웨어 제품들이 새로운 버젼의 발표로 서서히 발전되어 간다. 대부분의 경우에 본래 버젼의 아키텍쳐가 장기간의 제품 발전에 따른 예측할 수 없는 기술 진보와 제품 사양들을 수용할 수 없기때문이다.

12.5
소프트웨어 아키택트는 팀 멤버들의 활동을 아키텍쳐의 디자인 요소들에 맟춰 정하게 된다. 소프트웨어 아키텍쳐는 제품 개발을 완성하기 위한 엔지니어링과 관리에서 만들어져야하는 타협을 통일하는 주제이다: 소프트웨어 아키텍쳐는 프로젝트의 많은 국면이 회전하는 중심의 요소를 제공한다. 메니져는 아키텍쳐를 복잡한 과정을 처리가 가능한 과제들로 나누는 개체라고 여길 수 있다. 기술적 마케팅에서는 아키텍쳐로 제품의 사용 기간동안의 새로운 기술을 첨부를 지원하는데 사용할 수도 있다. 소프트웨어 엔지니어들은 성능, 재활용 가능성, 그리고 발전에 대해 걱정을 할 수도 있다. 즉, 소프트웨어 아키텍쳐의 선택, 개발, 그리고 정련은 소프트웨어 개발의 성공 여부의 가장 중요한 부분이다.
아키텍쳐의 수문장으로서, 당신은 아키텍쳐에 영향을 미치는, 영향을 받는 사람들의 활동을 주관한다. 디자인이 완성됨에 따라, 당신은 주요 인터페이스들을 조종하고 설립한다.
아키텍트는 또한 소프트웨어의 개발과정을 따라가며 중요한 아키텍쳐 디자인이 이루어 졌음을 확인해야한다. 디자인 리뷰는 두가지의 일을 수행하는데, 이는 아키텍쳐의 견고함과 품질을 보증하며, 참가자들이 디자인을 이해하는 것을 보증하는 것이다.
키텍트는 프로젝트 메니져와 함께 일하며 디자인의 다른 분야 별로 팀리더의 책임을 설립해야한다. 또한 당신은 팀리더들간의 화합을 주관해야 할 것이다. 그들은 그들의 책임하에의 서브시스템들이 아키텍쳐에 맞을 수 있도록 하기 위해 서로 같이 일해야 한다.
디자인의 일관성과 아키텍쳐가 따라 가진 것은 당신의 책임이다. 만일 따를 수 없는 상황이 발생하게 되면, 이는 이유가 기록 되어야한다.

12.6
분석과 하이 레벨 디자인 외에도, 소프트웨어 아키텍트는 시스템의 임플라멘팅에서 역할을 한다. 소프트웨어 엔지니어 중 소프트웨어 아키텍트가 되고자 하는 사람들은 오늘의 프로그래밍 기술에 맞추고, 신기술과 새로운 기본사양들을 알고 있어요 할 것이다.
소프트웨어 아키텍쳐와 상세한 디자인 사이에 항상 확실한 차이가 없다. 종종 아키텍트는 시스템의 위험도가 높은 부분들을 상세히 들여다보기를 원한다. 왜냐 하면, 디자인 이행이 알려져있지 않기 때문이다. 로우레벨을 상세히 봄으로서 초기의 디자인 개념을 갖는데 도울 수 있다. 아키텍트는 시스템의 수직 박편을 이행 함으로서 이행에 따른 위험을 감축할 수 있다.
명심해야 할 것은 아키텍트가 이행한 것이 팀 멤버들을 교육하는데 사용될 수도 있다는 것이다. 예를 들어, 객체지향적인 개념으로 문제를 접근하면 아키텍트가 초기의 배이스 클래스들을 디자인하고 코드를 임플레멘트 한것들이 다른 사람들이 배우는 예제로 사용 되는 것이다.

12.7
아마도 소프트웨어 아키텍트의 가장 중요한 역할은 소프트웨어 아키텍쳐를 지지하는 것이다. 소프트웨어 아키텍쳐는 당신의 조직의 중요한 재산이며, 아키텍트로서 당신은 이 재산의 가치를 조직이 상기 시켜야 한다.
당신은 현존 하는 소프트웨어의 아키텍쳐도 잘 알고 있어야 한다. 이들을 이용해서 새로운 아키텍쳐를 개발할 수도 있고, 합쳐서 제품군 아키텍쳐 (product-line)로 만들어 질수도 있기 때문이다. 당신은 또한, 경제적으로 수지에 맞는 제품군 아키텍쳐를 만들 기회를 찾아야 할 것이다. 프로덕트 메니져들을 자연스레 한가지 프로젝트에 몰두하지만, 아키텍트로서 당신은 제품의 굴레를 벗어나 다시 쓸 기회들을 봐야 한다. 아키텍트는 현존하는 소프트웨어 아키텍쳐 기술들과 새로이 나타나는 소프트웨어 아키텍쳐 기술들을 지지하고 평가해야 한다. 당신은 연구 결과와 다른 기관의 경험의 도움도 받아 이 기술들을 평가해야 할 것이다. 이들 외부의 결과와 경험들은 당신에게 경영진들이 조직네에 새로운 기술을 지원하기 위해 설득하기 위한 자료를 재공한다.
소프트웨어 아키텍트는 또한 소프트웨어 아키텍쳐를 개발 과정에 수용하기 위해 일을 해야 한다. 소프트웨어 아키텍쳐 디자인 과제와 이에 따른 결과들을 조직네의 기본적인 운영 순서로 만들어야 한다. 이는 더 하이 레벨의 아키텍쳐 디자인 서류를 만드는 것을 의미 할 수 있으며, 좀더 형식적인 기관에서의 아키텍쳐 디자인 검토를 의미 할 수 있다. 아니면, 여러 개의 조직과 인터페이스의 기초가 되는 프로토 타입들을 만드는 것이다. 어떤 경우에라도, 아키텍트는 아키텍쳐 디자인 검토를 지지해야하고 아키텍쳐 서류의 표준을 세워야 한다.
당신의 조직에 소프트웨어 엔지니어링 발전 그룹이나 챔피언이 있다면, 당신은 당신의 역할을 분명히 해야 한다. 프로젝트 중 문제가 많은 프로젝트에는 역할이 확실한 아키텍트나 역할이 확실한 임플러맨팅을 위한 개발 단계가 존재치 않는다.
설사 당신의 프로젝트에 공식적인 소프트웨어 아키텍트가 있다 하더라도, 이는 권한을 가진 정식적인 자리가 아닐 수 있다. 당신은 프로젝트 메니져와 함게 일을 해가며 당신의 의미와 역할을 인증 시킬 필요가 있다. 않그러면, 프로젝트가 압력에 놓였을때, 당신의 역할은 단순히 위기들을 차례 차례 맞는 것 외에는 아키텍쳐로서의 일을 할 수 없기 때문이다. 시야가 넓은 아키텍트 없이는, 종종 아키텍쳐는 단기의 편의 사항이 장기에 해로울 수 있다. 이렇게 되면, 아키텍쳐는 서서히 원래 추구했던 디자인에서 다른 제어가 힘들은 디자인으로 넘아간다. 그리고는 이행되는 시스템의 비젼이 사라지게 된다.

12.8
만일 지금 막 소프트웨어 분야에 뛰어들어 앞으로 소프트웨어 아키텍트가 되는 것이 목표라면, 당신은 우선은 전문적인 소프트웨어 엔지니어가 되는 것에 관점을 두어야 할 것 이다. 무엇 보다도 경험이 유능한 소프트웨어 아키텍트가 되는데 중요하기 때문이다. 이 분야를 걸으면서 당신은 기술적인 면과, 리더쉽, 대화 능력, 그리고 인적 능력을 개발하는 것이 중요하다.
당신은 처음에 개인 공헌자로 소프트웨어 엔지니어에서 원로 소프트웨어 앤지니어가 되어 나중에 팀리더로서의 책임을 맡을수도 있다. 당신은 늘어나는 책임과 더 도전적인 작업들을 받아 들여야 한다. 이상적으로, 당신은 경험이 많은 아키텍트 아래에서 일을 하게 될 것이다.