계좌제로 소프트웨어 아키텍처 분석 및 설계 수업을 한국생산성본부에서 월요일부터 오늘까지 4일간 들었습니다.
저의 커리어패스로 소프트웨어 아키텍처를 생각하고 있었기 때문에 이 수업을 듣게 되었는데요.
강사님은 한국소프트웨어아키텍처 그룹의 백용규 회장, SK C&C의 김정호 아키텍트, 짧게나마 IBM의 윤석빈 차장님이 강의해주셨습니다.
아래에 정리를 해보았습니다. 1~3일자는 주로 이론을 배웠는데요. 그보다는 오늘 강의를 해주신 SK C&C의 김정호 강사님의 강의가 너무 쏙쏙 들어와서 그와 관련하여 정리해 보았습니다.
소프트웨어 아키텍트
개집을 만들때는 혼자서 만들 수 있으나 큰 아파트는 시공자, 인테리어 전문가, 배선전문가등 각각의 전문가들이 각 고유의 영역을 담당합니다. 소프트웨어 개발도 대형화되고 복잡해 짐에 따라 자바 전문가, 네트워크 전문가, 데이터베이스 전문가등 각각의 전문가들의 각각의 영역을 담당합니다. 그러한 전문가들 사이에서 프로젝트에서서 결정해야할 기술들을 다양한 지식으로 수직적이 아닌 수평적인관계로 전문가들과 합심하여 아키텍처를 정립합니다. 다양한 지식을 가진 사람들과 의사소통하기 때문에 의사소통 능력이 중요합니다. 또한 소프트웨어 개발은 기계가 하는 제조업과는 다르게 모든 공정을 사람을 필요로 하기 때문에도 사람간의 의사소통이 가장 중요합니다.
또한 이 뿐만이 아니라 고객과 프로젝트를 투자하는 이해관계자들과의 의사소통도 소프트웨어 아키텍트의 역할입니다. 아파트를 사는 사람들도 실제 설계도 보다는 3D 조감도가 더 보기 쉽고 모델하우스가 더 눈에 와닿는것 처럼 소프트웨어 아키텍트도 개발자가 아닌 고객과 이해관계자들도 쉽게 이해하도록 글자보다는 이해하기 쉬운 그림위주로 추상화하여 표현하는 능력이 필요합니다. 즉 고객이 원하는 그림을 만들수 있어야 소프트웨어 아키텍트입니다. 보이지 않는 S/W를 보이게 하는 능력도 소프트웨어 아키텍트의 능력입니다.
그래서 전문개발자가 아키텍트가 되기 어렵습니다. 아키텍트의 가장 큰 적은 자신이 가진 기술입니다. 자신이 가진기술만을 생각하여 프로젝트에서 결정해야할 기술을 아키텍트의 관점에서만 바라보는 잘못을 할 수도 있기 때문입니다.
시스템은 반드시 하나의 아키텍처만 가집니다. 일관성이 필요합니다. 단지 관점에 따라 다르게 보이지만 실제 아키텍트는 하나입니다. 프로젝트 매니저는 프로젝트를 책임지며 소프트웨어 아키텍트는 소프트웨어 프로덕트를 책임집니다.
IEEE1471 : 아키텍트 정의
기능적 요구사항과 비기능적 요구사항
요구사항은 기능과 비기능요구사항이 있습니다. 기능적 요구사항은 인풋과 아웃풋이있는 것이고 여기서 아웃풋은 테스트 결과로 나와야 하는것입니다. 기능적 요구사항은 자동차, TV하면 자동으로 차가 가고 TV가 나오고 하는 등 기능적 요구사항은 그 소프트웨어가 갖추어야 할 필수적인 기능입니다. 그러나 자동차에 연비, 디자인등이 중요하고 TV도 TV만이 아닌 LCD, LED등 성숙될 수록 실제 기능이 아닌 비기능적 요구사항이 중요해지고 있습니다.
기능적 요구사항을 구현하기 위하여 아래의 세가지 방식과 같은 다양한 방식이 있습니다. 이러한 방식중에서 비기능요구사항중 성능, 가용성, 보안, 변경용이성, 테스트용이성, 사용성과 같은 시스템 품질에 따라 기능적 요구사항을 선택하게 됩니다. 이렇게 기능적 요구사항과 비기능적 요구사항은 결합되어있습니다. 그리고 이러한 품질속성시나리오에 따라 소프트웨어 아키텍처에서 의사결정을 하게 됩니다.
여러 비기능적 의사결정과정에서 전문가들은 자신이 잘하는 것을 결정하는 잘못을 범할 수 있는데 고객과 이해관계자 입장에서 결정을 해야합니다. 이러한 의사결정과정은 아키텍트가 책임을 집니다.
아키텍처를 기술하는 관점에는 물리적으로는 Allocation 뷰, 정적으로는 Module 뷰, 런타임으로는 Runtime 뷰가 있습니다.
보통 개발자라면 개발관련지식만을 떠올리게 되는데 소프트웨어 아키텍트는 소프트웨어 지식 뿐 아니라 소프트웨어가 동작하는 하드웨어, 네트워크 환경등에서도 지식이 있어야 합니다.
연계시스템을 파악하기위하여 컨텍스트(Context)다이어그램이 필요하며 품질에 대한 중요도를 측정하여 그에 따른 전략을 수립하고 3가지의 뷰타입을 생성하는 과정을 거칩니다.
소프트웨어 아키텍처는 소프트웨어의 청사진을 만드는 과정입니다. 기술적인 요소만이 아니라 의사결정과정 그리고 문서작업 보다 사람들과의 다양한 마찰과 의견충돌이 생길 수 있는 만큼 의사소통 능력과 따뜻한 마음이 필요합니다.
후기
사실 소프트웨어 아키텍처에서 무엇인가 크게 배울 수 있을 거라고 생각했고 경력이 거의 없는 저도 소프트웨어 아키텍트 수업을 통해 소프트웨어 아키텍트 활동을 할 수 있을 것이라고 생각했습니다. 하지만 제가 아직까지 바로 소프트웨어 아키텍트 직책을 갖기에는 많이 모자르다고 생각하게 된 수업이었습니다. 아직까지 다양한 IT경험을 하면서 소프트웨어 아키텍트의 지식을 꾸준히 쌓아야 할 것이라고 생각합니다. 물론 소프트웨어 아키텍트는 전문적인 기술과는 거리가 있기는 하지만 특히 도매인 지식과 하드웨어, 네트워크에 이르는 다방면의 지식이 부족한 저에게 아직까지는 많은 지식이 필요할 것이라고 생각합니다. goodhyun님 트위터를 보니.. 아키텍트는 파워포인트로 그림그리는 사람이라는 말을 적어두신것을 보았습니다. 소프트웨어 아키텍트가 프로젝트의 프로덕트를 책임지기 때문에 소프트웨어 아키텍트의 자질이 모자르면 개발자뿐만아니라 프로젝트에 참여하는 많은 사람이 피해를 입게 됩니다.
또한 UML이 모델링에 필수적인 기술은 아니지만 수업에 참여하신 분들이 대부분 모른다는 것에 깜짝놀랬고... 의외로 기술에 대한 관심이 적다는 것을 알았습니다. 그만큼 도매인 지식과 짬(?)은 확실히 있어보였지만... 흠 저에게 또 다른 생각을 하게 만들었습니다....
이 장소를 Daum지도에서 확인해보세요.
서울특별시 종로구 사직동 | 한국생산성본부
