이번 전문가 초청 세미나는 카네기-멜론 대학의 컴퓨터 공학과 교수님이신 Anthony Lattenze의 소프트웨어 아키텍처 강의가 있었습니다.
우선 결론적으로는 저희가 실행하기에는 힘든 방법론이었습니다.
그냥 참고할만한 수준으로 이해하시면 될 것 같습니다.
우선은 강사의 말을 그대로 핵심만 옮겨 봅니다.
우선 주제는 정확하게 말해서 소프트웨어 아키텍처의 전략적 자원화(Software Architecture as Strategic Asset)입니다.
원래는 “사례로 보는 SW Architecture”라는 세미나를 참여 했는데, 내용과 파워포인트의 제목을 보니 “소프트웨어 아키텍처의 중요성과 회사에서는 이를 전략적 자원화하여야 한다.”가 주제였습니다.
Architecture이라는 것은 결국 사용자의 요구사항과 구현(개발)을 이어주는 다리 역할을 하는 것이다.
아키텍처를 잘 만들면 요구사항과 구현간의 gap을 줄일 수 있다.
아키텍처에는 3가지 종류가 있다.
Enterprise Architecture, System Architecture, Software Architecture
흠~ 당연히 다른 개발 방법론들처럼 정확한 방법론과 절차를 따르면 고객과 개발자 사이의 간격을 줄일 수 있는 것!!
즉, 소프트웨어 아키텍처, 또한 하나의 개발 방법론(절차서)로 이해 하면 될 듯.
실제로 Architecture 디자인을 한다는 것은 기능을 분배하고, 각각의 기능에 권한을 부여하는 일연의 과정이며, 각 기능간의 관계를 나타내는 것이다.
이는 세세한 단위로 이루어 지는 것이 아니라 적절한 추상화를 통해 이루어 져야 한다.
이때 소프트웨어의 성능, 보안, 가용성, 효율성, 변경가능성을 반영하여야 한다.
그리고, 프로세스 중심적이어야 하며, 이벤트 중심적이어서는 안 된다.
또, 이 모든 과정은 반드시 문서화 되어야 한다.
실제로 소프트웨어 아키텍처를 어떻게 구성하고 그 예가 어떤 것인지를 설명해줬으면 했으나……
결국 현실적인 이야기 보다는, 개념적인 이야기가 많았습니다.
소프트웨어 아키텍처는 밑단까지 상세하게 구조화 시키는 것은 아니다!!! 추상화된 대략적으로 구성해야 한다.
사실, 이 대략이 힘들죠?? 어디까지가 과연 대략인지!!
관리자들은 SW Architecture 구성하면 단순히 불필요한 작업이 늘어 나는 것으로 보지 말아야 한다.
SW Architecture 구성함으로써 프로젝트 진행에 있어서의 미래를 예측할 수 있고, 발생될 문제점 등을 예측할 수 있다.
결국 SW Architecture라는 것은 전략적으로 생각함을 의미한다.
관리자들은 SW Architecture의 중요함을 인식하고 이를 수용하고 실행하여야 한다.
결국 미래를 내다 보고 설계하라는 것인데, 그 것을 합리화 시킨 것이 소프트웨어 구성을 대략적으로 해야 한다는 것!!
빈 박스 3~4개 그려놓고 이게 인사 시스템이다!!! 하면???
이것을 CJ에서도 사용하고 Global에서도 사용하고, 외부에도 팔 수 있게 만들었다고 할 수 있을런지?
물론 소프트웨어를 구조화 시키는 것은 중요하다는 것은 모두가 인식하고 있고, 위의 예가 극단적일 수 도 있지만, 그 효용성에 대하여 좀더 자세한 설명이 있었으면 했습니다.
SW Architecture는 코드의 재사용을 의미하는 것이 아니라 앞에서 말한 바와 같이 추상화된 기능들의 재사용이다.
세세한(fine) 기능의 재사용이 아닌 데이터베이스, J2EE처럼 거친(coarse) 기능들의 재사용이다.
쉽게 말해 재 사용은 코드 하나하나를 재사용 한다고 보면 안 되는 것이고, 웹에서 인쇄 모듈을 사용하고, C나 JAVA에서 기본 IO모듈을 상속해서 사용하는 것이 바로 재사용이다.
실제 이러한 재사용은 제품 라인업에서 볼 수 있다.
제품 라인업이라는 것은 미리 재사용을 위해 디자인된 것이다.
이러한 제품 라인업은 분기점과 공통점을 정확하게 구분 하는 것이 관건이다.
그리고, 어떤 곳에서나 제품 라인업이 사용되는 것은 아니며, 비용과 비즈니스가 맞아 떨어질 때 적용되어야 하는 것이다.
알zip 알ftp처럼 알 소프트에서는 같은 ftp프로그램도 라이센스(알 zip 개인용, 알 zip 회사용)나 기능(알 map, 알 map-pro, 알 map-pocket)에 따라 제품 라인업을 가집니다.
이들과 같은 제품 라인업들을 모아 놓고 보면 분명히 공통 모듈이 있고, 라인업 별로 틀린 모듈이 있습니다.
결국 이렇게 분리 될 수 있는 것들이 바로 소프트웨어 아키텍처 하나하나의 요소가 될 수 있는 것이다.
이렇게 거꾸로 여러 가지 버전의 소프트웨어를 만든다고 가정하고 그 차이점과 공통점을 반대로 묶어 가는 것이 바로 SW 아키텍처 디자인이다.
글로벌 개발이라는 것은 개발팀을 전세계적으로 분산하여 관리/협업하는 시스템을 말한다.
이때 발생하는 여러 가지 문제점들에 대한 해결책도 SW 아키텍처이다.
즉, 권한과 결정권을 가지는 중앙 아키텍처 팀을 구성하여 운용하여야 한다.
그들이 정의한 아키텍처를 중심으로 분산된 개발 팀들은 협업을 진행하여야 한다.
저희는 전혀 글로벌 개발이라는 것을 하지 않기에 적용이 안되다고도 볼 수 있지만 외부 개발자를 쓰거나 여러 팀이 협업하여 개발할 때 적용된다고 보면 될 듯 합니다.
단지 소프트웨어 아키텍처 문서가 아니더라도 정확한 문서 표기와 공유가 중요하다는 것을 다시 일깨워 주는 부분입니다.
각 사의 관리자들은 SW Architect의 중요성을 인지하여야 한다.
SW Architect는 PM과는 분리되어야 하지만, 같은 관리자 그룹에 속하여야 한다.
SW Architect를 교육 시켜야 하며, 그들의 CDP보장하여야 한다.
저희 회사에는 없는 직무 중 하나가 아닐까 합니다.
개발 전문 회사가 아니기에 소프트웨어 아키텍이 존재 하지 않지만, 외국의 경우 아키텍 그룹과 팀이 따로 있을 정도로 중요 시 되고 있는 직무라고 합니다.
이 아키텍은 다른 말로 디자이너라고 부르기도 합니다.
국내에서 일반적인 디자이너가 그래픽 디자이너를 의미 하지만, 외국 같은 경우 프로그래머라고 하면 디자인을 하느냐 못 하느냐가 아주 중요한 경력사항 중 하나입니다. (어제 저녁에 미국에서 온 사촌 동생들과 저녁을 먹는데, 내가 프로그래머라고 하니까 바로 이 질문을 하더군요! 그럼 디자인도 하냐구? ㅠㅠ;;)
여하튼 아직은 국내의 개발 환경 자체가 분업화가 많이 되어 있지 않아 아키텍이나 QA의 역할이 많이 떨어지는 것은 사실인 듯 합니다.
사실 쭉 강의를 듣고 느낀 것은 대학교에서 컴퓨터 공학과 수업을 듣는 듯 했습니다.
이게 과연 실형 가능한 것인지…… 멀 하라는 것인지…… 심지어 졸리기 까지 하더군요 ㅋㅋ
여하튼 조금 더 실 예를 들어 설명해 주지 못한 부분이 아쉬웠던 것 같습니다.
(0) 
(0)Posted by akiss4u
