크리에이티브 커먼즈 라이선스
Creative Commons License
'아키텍처' 라는 단어에는 많은 의미들이 포함되어 있으며, 특히 SW 분야에서 아키텍처를 만드는 아키텍트에게 너무나 많은 역할이 부여되는 것이 사실입니다. 구태여 '소프트웨어'라는 단어를 붙인 이유는 수많은 의미로 아키텍처/아키텍트라는 단어를 사용하기 때문에 더욱 강조를 한 것 같습니다. '소프트웨어 아키텍트가 알아야 할 97가지' (원제 : 97 Things Every Software Architect Should Know') 라는 책은 처음에 블로그를 통해서 여러 SW 아키텍트들의 이야기를 접하게 되었습니다. 그 후, 본격적인 출판 작업 O'Reilly에서 진행하면서 위키로 해당 내용들을 옮겼습니다.


이 책의 내용은 여러 SW 아키텍트들이 경험한 내용을 이야기하듯이 적고 있습니다. 

위키에 있는 내용들을 하나 둘씩 블로그에 번역해서 올리면서 하나의 에피소드는 제가 가지고 있는 SW 아키텍처에 대한 지식과 같이 어우러져서 좀 더 폭넓고 다양한 시각에서 볼 수 있게 융화되기 시작했습니다. 또한, 다양한 사회 현상들도 같이 이해를 하면서 결국 SW는 인간이 결부되고, 그 안에 지식을 넣는 과정에서 수많은 문제와 싸울 수 밖에 없다라는 생각을 했습니다.

소통, 리더십, 융화, 선견지명, 다양성, 원칙/원리 등의 단어들이 SW 아키텍처 분야에서 왜 더욱 강조가 되고, 어떻게 기술적인 요소들과 어울리게 만들어야 하는지를 이해하게 되었습니다.

이 책에는 기술(technology) 이상의 기술(art)이 담겨져 있습니다. 대부분의 SW 아키텍처 관련 서적들이 다분히 학문적인 관점에서 쓰여졌다고 하면, 이책은 그 중에서 우리 업에 실제 체험한 아키텍트들의 이야기입니다. 이책을 읽으면서 부러웠던 점은 우리나라도 이러한 내용의 책들이 많이 나와서 현실적인 문제점들을 같이 공유하고 해결하고자 하는 노력들이 이루어졌으면 하는 생각이 들었습니다.

지금 한국의 IT는 제가 대학 전공을 선택하는 20년 전의 상황과 많이 다르며, 이제는 기피하는 학과가 되어 버렸습니다. 많은 글들이 한국의 SW 산업에 대한 우려와 정책에 대한 불만들을 이야기하고 있습니다. 하지만, 이제는 SW 산업 내에서 직접 몸담고 있는 사람들이 이러한 한국의 SW 분야의 문제를 어떻게 해결하고 무엇이 잘못 되었는지에 대한 자각이나 토의가 없는 것도 사실입니다. 그동안 보안상의 이유로, 혹은 너무나도 급히 만들어내는 관행으로 인해 정작 제대로 SW를 개발하는 것에 대한 내용들을 이야기하지 못했다면, 이제는 정말 이러한 부분들에 대해서 자성의 목소리를 낼 필요가 있고, 오해나 잘못된 부분들이 있다면 과감하게 바꿀 필요도 있을 것 같습니다. 먼저 SW 내부에서 이러한 움직임이 국내 SW 산업의 발전을 이룰 수 있는 토대를 형성할 것이고, 더 좋은 환경과 인재가 투입될 수 있을 것입니다. 한국의 SW의 미래에 대한 모습을 서로 공유하고 이에 대해 진지한 고민들이 필요할 것 같습니다.

다행히도, 많은 기업과 단체에서 SW 아키텍처에 대한 중요성과 필요성에 대해 인식을 많이 하고 있습니다. 이를 좀 더 발전된 형태로 만들어내기 위해서는 서로의 경험을 솔직하게 말하고, 다름을 인정하는 환경이 먼저 필요할 것 같습니다.

이 책은 처음에 블로그에 번역을 올리면서 Eva 팀의 손영수님을 알게 되면서 공동 번역의 형태로 작업을 했습니다. 또한, 우리 나라의 SW 아키텍트들의 이야기를 같이 실었으면 하는 의견에 동의하면서 제가 겪었던 이야기도 실어보았습니다. 또한, 베타리딩이 같은 회사의 연구소장님이 참여하면서 '정경유착' 이라는 내용으로 국내 SW 아키텍트 이야기도 같이 실렸습니다.

이 책에 있는 내용들은 기술적인 내용보다는 SW 아키텍트의 인간적인 내용들로 가득차 있습니다. 매 순간이 고뇌인 SW 아키텍처 작업은 혼자 고민하는 것보다는 서로의 의견을 같이 공유함으로써 나 혼자 만의 고민이 아닌 모든 SW 아키텍트의 고민으로 같이 해결해야 할 숙제인 것 같습니다. 아래에 제 블로그에 있던 내용들 한데 모아보았으며, 손영수님의 블로그에도 몇가지가 공유되어 있으니, 책의 내용들 중에 몇가지를 보실 수 있을겁니다. 좋은 참고 자료가 되었으면 하는게 이번 번역에 참여한 사람 중의 한사람으로써 바램입니다.

저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 대형이든 소형이든 대부분의 프로젝트에서는 아키텍트팀과 업무를 중심으로 한 업무 개발팀으로 나눕니다. 업무는 비즈니스로부터 구획화가 되며, 각 업무 간에는 의존관계로 연결됩니다. 하지만, 비즈니스가 칼로 자르듯이 구획화가 힘든 부분이 발생되기도 하며, 이는 비즈니스를 구현하는 IT 입장에서도 명확하게 나누는 것이 힘든 경우도 발생됩니다. 이와 같은 일이 발생되는 경우에 가장 흔하게 사용되는 것이 업무 공통이라는 영역을 나누는 방식입니다. 즉, 어느 업무 팀에도 할당하기 애매모호한 것들을 통틀어서 공통이라는 영역으로 두게 됩니다.

 일단 공통이라는 영역을 두게 되면, 수많은 애매모호한 성격의 일들이 이 영역으로 들어오게 됩니다. 심지어는 두 업무 사이에 명확하게 나누기 힘든 것 역시 이러한 공통 영역으로 들어오게 됩니다. 어떤 프로젝트에서는 기술 공통이라는 영역까지도 나눕니다. 기술의 범위가 너무나 협소해서 아키텍처 영역에 두기는 사소해서 이곳에 위치시킵니다.

 공통이라는 원래의 의미를 살펴보면, ‘여럿 사이에 다 같이 있거나 관계됨’ 이라고 정의되어 있습니다. 공통이라는 말에는 다수의 개념이 포함되어 있습니다. 여러 개의 개념들이 함께 공존하고 있다라는 의미는 표준이라는 개념을 염두해두고 있어야 한다는 것입니다. 다시 말해서, 애매모호하거나 명확하게 정의하기 힘든 영역이 공통이라는 것이 아닙니다. 공통 영역은 명확하게 정의되고, 표준화될 수 있는 영역이며, 이는 다수로부터 사용되는 영역입니다.

 공통코드, 로그인, 메뉴관리, 사용자 관리, 업무 정합성, 게시판, 달력, 팝업화면, 휴일관리, 조직관리 등 공통 업무나 기술 영역을 나누고 많은 프로젝트에서 구현했던 내용들의 예입니다. 이러한 내용들이 과연 표준화되고 명확하게 정의했던 내용들이었던가요? IT에서 구현하는 내용들은 대부분 비즈니스로부터 발생되며, 비즈니스 기준에 의해서 구획화되지만, 많은 아키텍트들은 이와 같이 애매모호한 것들을 그냥 공통이라는 이름으로 두고 관리하려고 합니다. 어찌보면 아키텍트의 역할을 제대로 하지 못해서 발생되는 영역이라는 생각이 더 듭니다. 명확한 기준과 표준을 제시하지 못했기 때문에 공통이라는 편리한 장치를 두고 이를 전가해버린 것입니다.

 컴포넌트나 클래스 명 역시 공통(common)이나 유틸리티(utility)라는 이름의 유혹을 떨쳐버릴 수가 없습니다. 그동안 이러한 이름으로 구현된 소스를 살펴보면, 과연 그 내용이 표준화되고 명확한 정의를 내릴 수 있는 기능으로 구현되었는지를 생각해보면 전혀 이와는 상관없이 구현되었다는 것을 알 수 있을 것입니다. 또한, ‘공통’ 이라는 이름 아래에 얼마나 많은 관련없는 기술과 비즈니스 로직이 구현되었는지는 바로 알 수 있습니다. 하나의 ‘공통’이라는 컴포넌트는 전혀 상관없는 인터페이스들로 구성되며, 시간이 흐르면서 이러한 공통 컴포넌트는 점점 더 많은 서로 관련이 없는 인터페이스들을 가지게 됩니다. 그로 인해서, 공통 컴포넌트 중에 일부 기능을 사용하는 다른 컴포넌트에서는 공통 컴포넌트의 인터페이스가 증가할 때마다 새로 해당 컴포넌트를 배포해야 하며, 영향도를 다시 검사해야 합니다. 즉, 공통 컴포넌트는 전혀 표준화가 되지 않은 영역입니다. 또한, 공통이라는 이름은 그 누구도 유지보수하지 않은 영역으로 변해버립니다. 늘 문제는 이러한 아무도 관리되지 않은 공통 영역에서 발생되며, 그 책임성 또한 모호해집니다.

 아키텍트는 공통이라는 단어를 주의깊게 사용해야 하며, 다음과 같은 원칙하에서 영역을 명확하게 구분해야 합니다.

  1. 공통(common)이라는 단어는 가급적 사용하지 않는다. 이는 컴포넌트 명이든, 클래스 명이든, 혹은 패키지 명이든 공통이라는 단어가 들어갈 경우, 늘 애매모호한 것들이 위치할 수 있다라는 가능성을 포함하고 있음을 유의한다.
  2. 항상 모든 개념에는 정확한 용어와 명확한 정의를 내려야 한다. 용어가 정확하지 않으면, 정의를 내리기가 어려우며, 그럴 경우 애매모호한 개념들이 들어갈 여지를 남겨두는 것이다. 우편번호는 그 자체로 고유한 정의로 사용되어야 하며, 공통이라는 이름으로 다른 개념들과 섞여서는 안된다.
  3.  재사용성과 표준화 관점에서 공통이라는 용어를 사용해야 하며, 공통이라는 단어를 빼기 힘든 경우에는 유틸리티(utility)라는 용어를 사용하자. 재사용성은 애플리케이션/도메인/범용 등으로 나뉠 수 있으며, 표준화는 업계나 해당 기술에 대한 표준 내용이 있는지를 먼저 점검하고, 만일 있는 경우, 가급적 이러한 표준적인 내용을 수용할 수 있어야 한다.

 아키텍처에서 공통이라는 이름을 사용하는 장점들은 많습니다. 예를 들어, 레이어에서 복잡하게 얽힐 수 있는 관계를 공통 레이어로 두어서 관리하게 되면, 재사용성이나 아키텍처 건전성 측면에서 더 향상될 수도 있습니다. 하지만, 이러한 장점만을 부각하여 애매모호한 것들을 공통 영역으로 두게 된다면 오히려 시스템에 악영향을 미칠 수 있으며, 책임 영역이 모호하여 유지보수도 힘들어질 수도 있습니다.

 소프트웨어 아키텍트는 시스템의 구성요소들을 식별하고, 이들 간의 관계를 원칙과 원리 하에 규정하는 작업을 하는데, 공통이라는 요소를 식별하여 여기에 애매모호한 내용들을 넣게 된다면, 자신의 역할을 다하지 못했다는 것을 반증합니다. 아키텍트는 늘 이러한 주인없는 영역에 대해서 정확한 용어와 명확한 정의를 내리는 역할을 수행해야 합니다. 공통은 모든 사람들이 소통할 수 있는 광장과도 같으며, 그러한 광장을 모든 사람이 손쉽게 접근하고 막힘없이 교류할 수 있는 장소로 만드는 것이 아키텍트의 역할입니다.

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이미 TV 프로그램의 대세가 되어버린 '버라이어티' 쇼 프로그램들은 시청자의 요구가 이미 이러한 환경으로 바뀌었음을 나타내는 증거입니다. 새로 생겨나는 TV 프로그램들이 이러한 환경에 제대로 적응하지 못하면, 시청률을 기준으로 퇴출당하게 되는 일은 이미 예삿일이 되어버렸습니다. '버라이어티' 프로그램들은 시청자의 마음을 읽고, 기존의 전형적인 프로그램의 기획을 과감하게 탈피하고 있습니다. 사전에 무엇을 할지를 기획하고, 기획된 대로 작업 시간을 만들고, 대본을 미리 만들어서 연습을 하고, 실제 촬영에서는 주어진 각본대로 찍고 또 찍는 것이 기존의 전형적인 틀이었습니다.

하지만, 이제 이러한 전형적인 틀로 찍어낸 TV 프로그램들은 시청자들에게 외면받는 시대가 되었습니다. 소프트웨어 프로젝트 역시 이러한 환경에 영향을 받아서인지 빠른 템포로 진행되는 비즈니스 환경을 요구하고 있습니다. 고객이 원하는 것은 기존에 잘 굴러가던 시스템보다는 고객의 비즈니스를 그때 그때 지원하는 시스템을 바랍니다. 이제 기존에 제공되는 서비스에 대해서 더 이상의 관심은 없습니다. 이미 기존 서비스들은 충분히 적응한 상태입니다.

이러한 환경에서 프로젝트를 진행하는 과정은 상당한 도전적인 내용을 필요로 합니다. '무한도전'이 아닌 '극한도전'이 필요합니다. 고객은 비즈니스 요건들을 이제 말로 하지 않습니다. 응당 당연히 알고 있으리라 생각하며, 거기에 더해 새로운 비즈니스 가치를 이야기합니다. 매일같이 새로운 기술의 요건들을 이야기합니다. 기존에 알고 있던 소프트웨어 지식들은 고객의 이와같은 변덕스러운 요구에 대해서 대응할 수 있는 체계를 갖추고 있지 않습니다. 프로젝트는 이제 기존 메커니즘을 갖다 들이대봤자, 시청률이 나오지 않는 전형적인 프로그램만 만들 뿐입니다.

'버라이어티' 쇼에서 해당 멤버들은 전체 쇼의 기획자이자, 작가이자, 연출자이며, 배우가 됩니다. 다음 순서, 다음 회차의 프로그램을 무엇을 할지 사전에 기획하는 것이 아니라, 프로그램이 진행하는 중간 중간 아이디어를 내어서 바로 채택합니다. 그 순간 멤버들의 캐릭터를 그 즉시 정하고, 서로의 눈치를 보며 전체적인 프로그램을 진행합니다. 무엇인가 빠진 듯하면, 바로 그 모자라는 부분을 채워줄 수 있는 캐릭터를 바로 만들어냅니다. 심지어 사실이 아닌 것을 사실인 것처럼 위장하기도 합니다. 이전의 TV 화면에서 나오지 않은 기획자, 작가, 연출자들은 때로는 이들의 모자란 부분을 도와주기 위해서 브라운관에 튀어나오기도 합니다. 하지만, 어디까지나 TV 프로그램의 주도는 '버리이어티'에 참여하는 배우들의 몫입니다.

프로젝트 역시 상당히 많은 역할들을 세분화할 수 있으며, 이러한 역할을 수행하는 사람들을 같이 참여하여 진행하게 됩니다. 개발 프로세스나 방법론에는 상세하게 어떤 작업을 수행하고, 어떤 산출물을 사용하며, 어떤 결과를 만들어내고, 누가 이를 수행하는지가 정의되어 있습니다. 이는 충분히 예측 가능한 결과를 내는데 효과적이었습니다. 아니, 효과적일거라 믿었지만, 실제로 이러한 결과를 내기에 상당히 부족하다라는 결론을 내고 있습니다. 프로젝트를 분석, 설계, 개발, 테스트라는 단계로 나누고 그 작업을 수행하는 사람들도 나누었습니다. 물론, 이들 간의 효율적인 작업을 위해 커뮤니케이션은 필수입니다. 하지만, 이러한 형태의 개발 방식은 이미 시청률마저 예측 가능하게 합니다. 물론, 애국가 시청률보다도 못한 시청률이겠지요.

이제 고객이 원하는 '버라이어티'를 위해서 소프트웨어 프로젝트 진행도 바꾸어야 합니다. 분석, 설계, 개발, 테스트가 별도의 역할을 수행하는 개개인이 아니라, 전체를 작업하는 참여자만 존재할 뿐입니다. 설사 참여자가 테스트에 대해서 잘 모른다고 하더라도, 역할이 나뉘어서 작업하는 형식이 아니라, 현재 진행 중인 개발자의 작업을 상세하게 알고, 모니터링 하고 있어서 그에 맞는 테스트 계획과 실행을 해야 합니다. 즉, 이 부분에서 투명한(transparency) 개발 환경은 필수가 되어 버렸습니다. 파티션을 나누어서 담을 쌓고 PC에 머리를 들이대면서 남의 일에 대해서 모르겠다라는 태도는 분명 시청률을 의식하지 않는 행동입니다. 바로 버라이어티 프로그램에서 퇴출당하는 것입니다. 분석 작업만 하면 본인의 일은 끝이라는 태도는 버라이어티에서 기획만 하고, 그에 해당하는 캐릭터를 포기하는 행위입니다. 시청자는 기획을 했으면, 기획한 사람이 끝까지 책임지기를 바랍니다. 이러한 사람은 바로 메인이 아닌, 들러리 밖에 안됩니다.

버라이어티 프로그램에 참여하는 배우들이 모든 것을 수행하듯이 소프트웨어 프로젝트에 참여하는 모든 사람들은 처음부터 끝까지 모든 것을 수행해야 합니다. 주도적인 참여가 아니더라도, 소극적이라도 참여해야 생존이 가능할 것입니다. 고객은 이러한 과정을 거쳐서 나오는 결과를 원합니다. 비록 그 결과가 그리 썩 좋지 않더라도, 그러한 방식에 대해서는 충분히 박수를 보낼 수 있을 것입니다. 전통적인 개발 방식을 버려야 된다는 것은 아닙니다. 수많은 배우들이 기본적인 배우의 자질을 이야기하듯이 소프트웨어 개발에 대한 지식은 반드시 필요한 내용입니다. 또한, 이러한 지식이 있어야지 응용이나 활용이 가능합니다. 전통적인 프로그램을 거치면서 버라이어티 프로그램에 적응한 배우들이 오랫동안 시청자의 사랑을 받듯이 소프트웨어 지식을 정확하고 충분히 알고 있는 사람은 이러한 변화에 적응해가면서 고객의 요청을 늘 부합하는 결과물을 낼 수 있을 것입니다.

고객의 요구의 본질은 똑같습니다. 하지만, 이를 원하는 고객의 태도는 바뀌기 마련이며, 이러한 태도에 얼마나 부합하느냐가 프로젝트의 성공을 결정합니다.
저작자 표시 비영리 동일 조건 변경 허락
신고

+ Recent posts

티스토리 툴바