오늘 데브피아에서 주최하는 "Meet The Architect: 책에서 들려주지 않는 아키텍트 이야기"라는 세미나에 참석하였습니다.
위의 그림에서 처럼 한국 마이크로소프트 5층 교육장에서 진행되었습니다. 약 20분정도 늦게 도착했습니다.
강사님은 박현철 이사님이었는데 이전에 두세번 멀리서 뵈었었는데 오늘 제대로 뵐 수 있었습니다.
박현철 이사님에 자세한 약력은 위와 같습니다. 아마 독자님들 중에 뵈신 분들도 계실것입니다.
오늘 세미나 일정과 각 세션의 주제는 다음과 같았습니다.
| 시 간 | Session | 강 좌 제 목 | |
| 15:00 ~ 15:50 | 50분 | Session 1 | 니 경험 있나? 내도 있다. |
| 15:50 ~ 16:00 | 10분 | 휴식 | |
| 16:00 ~ 16:50 | 50분 | Session 2 | 중요한 것은 뭐고, 중요하다는 것은 또 뭔데? |
| 16:50 ~ 17:00 | 10분 | 휴식 | |
| 17:00 ~ 17:50 | 50분 | Session 3 | 그래서 어떻게 하라고? |
각 세션의 제목을 읽어보면 상당히 센세이션한데~ 박현철 이사님의 헤어스타일도 센세이션합니다. (^-^);;
오늘 상당히 좋은 이야기들을 들었습니다. 직접 실무에서 활동하시는 아키텍트이시기 때문에 더욱 실제적인 이야기들을 많이 들을 수 있었습니다.
특히 아키텍트의 자질에 대한 이야기들과 아키텍트가 되기 위해서 IT를 바라보는 시각에 대한 이야기들이 좋았습니다.
다음은 제가 정리한 오늘 세미나의 주요 내용들입니다.
우리가 알고 있는 Java나 C++ 및 C#과 같은 언어는 완벽한 객체지향언어가 아니다.
제대로된 객체지향언어가 되기 위해서는 다이나믹 타이핑(Dynamic Typing)이 되어야 하는데 현재까지 나온 언어는 객체지향개념중에 캡슐화(Encapsulation)이나 상속(Inheritance)와 같은 일부 객체지향의 개념만 지원하기 때문에 제대로 객체를 표현하는데 한계가 있다.
C++를 통하여 IT에 입문하셨는데 EJB 및 Java에도 많은 경험을 가지고 계신것 같습니다. 특히 Spring Framework에 대한 따끔한 지적도 상당히 좋았는데 다음과 같습니다.
과연 Spring Framework가 EJB 보다 쉬운가?
전 이 질문에 동감합니다.
사실 최근 필자는 "J2EE Development without EJB"란 책을 다시 읽고 있습니다. 예전에 Spring Framework를 처음 접하면서 로드 존슨의 생각을 자세히 알고자 읽어보았는데 당시 짧은 영어실력으로 제대로 읽지 못하였습니다. 하지만 요즘은 전보다 영어 실력이 나아졌기 때문에 나름 잘 읽고 있습니다.
AOP(Apspect Oriented Programming)은 좋은 개념임에는 틀림없습니다.
하지만 박현철 이사님께서 질문하신것처럼 EJB처럼 Spring Framework도 이해하기 어렵습니다. 필자의 경우 Spring Framework는 절대 만능 해결사가 아니라고 생각합니다. 만약 Spring Framework를 통하여 모든 일을 할 수 있다고 생각하시는 분들이 있다면, 이는 예전에 EJB가 등장하였을때 EJB가 완전무결한 서버측 컴포넌트로서 모든 기술적인 문제를 EJB를 중심으로 해결할 수 있다고 믿는 것과 동일한 맹신을 하시는 것입니다.
즉, 로드 존슨이 복잡한 스펙과 구현의 어려움으로 가득한 EJB를 비판한것처럼 또 다른 로드 존슨이 나타나 Spring Framework를 비판한 날이 올 수 있다는 것입니다.
이런 면에서 Spring Framework을 통한 AOP도 좋지만 좋은 아키텍트가되려면 모든 비즈니스 요구사항을 포괄할 수 없기때문에 기술의 장단점을 파악하여 비즈니스 요구사항에 맞게 적용할 수 있어야 한다고 이야기 하였습니다.
아키텍트는 기술로만 살 수 없다!
기술은 아키텍트가 될 수 있는 One of Them이다.
아키텍트가 될 수 있는 One of Them중에 하나가 디자인 패턴(Design Pattern)입니다.
하지만 여기서 중요한 것은 많은 디자인 패턴을 알고 있는 것보다 어떤 경우에 디자인 패턴을 적용할 것이가를 알고 있어야 한다는 것입니다.
또한 재사용(Reuse)에 관한 관점도 이야기하였는데 최근에는 변화가 매우 빠르기 때문에 재사용이란 개념이 재사용의 단위라기 보다는 변화에 따라 교체될 수 있는 단위라는 이야기를 하였습니다. 사실 이와 같은 이야기를 다른 아키텍트 분에게 들은 적이 있는데 재사용이란 이상적인 아이디어가 현실에서는 "교체될 수 있는 단위"로 인식되는 것이 더욱 좋은 소프트웨어를 만드는데 적합하다라는 생각을 하였습니다.
컴포넌트(Component)는 교체(Replecement)의 단위이다.
저의 경우에도 많은 경우 재사용하기 보다는 해당 모듈이나 컴포넌트를 교체하는 경우가 훨씬 많습니다.
하지만 이러한 논리에 여러 반박이 있을 수 있습니다만, 결국 현실적인 재사용은 "사용자가 원하는 모듈이나 컴포넌트로 안정적으로 교체하여 원활하게 동작할 수 있다면 달성된 것이 아닌가?" 라는 생각을 해봅니다.
이러한 측면에 관한 아키텍트적인 관점은 갑의 논리에 따라야 한다는 것입니다.
갑의 입장에서 소프트웨어 개발은 돈 낭비이며 시간낭비입니다. 갑은 소프트웨어를 빨리 구축한 후 이를 운영하여 수익을 얻는 것이 목적입니다.
하지만 을의 경우 소프트웨어를 개발하는 것이 목적입니다.
이러한 관점에서 재사용의 개념을 다시 생각해본다면, 갑의 입장에서는 재사용이 중요한 것이 아니라 개발된 소프트웨어가 비즈니스의 변화를 빠르게 수용할 수 있으면 됩니다. 즉 소프트웨어 모듈이나 컴포넌트가 재사용되든 교체되든 상관없이 소프트웨어가 원활하게 동작하여 수익을 얻으면 됩니다.
갑의 논리에 집중해야 한다.
하지만 을의 입장에서 본다면 소프트웨어의 개발에 초점이 맞추어져 있기 때문에 재사용은 교체의 대상이 아니라고 생각할 수 도 있습니다.
여러분은 갑의 입장이십니까? 아니면 을의 입장이십니까?
아키텍트는 체계를 정하고 이에대한 메타 레벨을 조정(Control)할 수 있어야 한다.
메타 레벨을 조정한다는 것이 언듯 이해되지 않을 수 있지만 결국 스케일(Scale)에 관한 문제입니다.
라면 하나 끓여 먹는 것은 쉬운 일이나 300명의 사람들이 먹을 라면을 끊인다면 어떤 방법으로 라면을 제공하겠습니까?
라면 하나의 스케일은 매우 작아서 조정해야 할 것들이 적지만 300명이 먹을 라면을 끊인다면 스케일이 커서 이것 저것 신경써야 할 것들이 매우 많습니다. 결국 스케일이 엄청나게 차이가 나는 것입니다.
소프트웨어도 마찬가지 입니다.
아키텍트는 300명이 끊이는 라면을 만드는 것처럼 소프트웨어를 만들 줄 알아야 합니다. 즉 스케일이 커야하며 큰 스케일을 효과적으로 조정할 수 있어야 합니다. 이를 위해서는 메타 레벨을 조정할 수 있어야 합니다.
메타는 2가지로 특성이 있는데 Behind와 Model for Model 입니다.
저 역시 메타데이타에 많은 관심을 가지고 있는데 쉽게 메타데이타를 설명하자면 데이타를 위한 데이타입니다. 여러분이 TV 시청을 원활하게 하기 위하여 TV 편성표를 본다면 TV 편성표는 TV 시청을 위한 메타데이타입니다. 메타데이타를 잘 이용하신다면 소프트웨어를 더욱 디테일하게 컨트롤 할 수 있습니다. Spring Framework의 Bean Definition XML이 대표적인 예입니다.
아키텍트의 경우 스케일을 원활하게 컨트롤 하기 위하여 방법론을 잘 알아야 합니다. 여기서 "방법론을 잘 안다"는 개념은 "방법론을 가장 필요한 부분에 적용할 수 있다!" 입니다.
즉 아키텍트는 스케일에 맞게 방법론을 테일러링할 수 있어야 합니다. 따라서 방법론 자체도 중요하지만 방법론을 프로젝트의 스케일에 맞출 수 있어야 합니다.
또한 만들어진 소프트웨어는 시장성을 가지고 있어야 합니다. 시장성이란 것은 만들어진 소프트웨어에 대한 가치를 인정받는 것입니다.
이런 면에서 아키텍트가 시장성을 확보하기 위해서는 갑이 원하는 품질을 갖춘 소프트웨어를 만들어야 합니다. 품질을 만족시킨다는 것은 여러 모로 여러운 일입니다. 열심히 도를 닦아야 겨우 갑이 원하는 품질을 만족시킬 수 있을까 말까입니다.
참고로 품질을 만족시키기 위해서 아키텍트는 고객들을 장악할 수 있어야 합니다. 제 생각에도 일관된 품질을 제공하기 위하여 요동치는 고객의 요구사항을 정리하기 위해서는 정치력을 발휘해서라도 고객을 장악할 필요가 있다고 생각합니다.
소프트웨어는 사람이 만들기 때문에 좋은 동기 부여를 통해서 좋은 품질의 소프트웨어를 개발할 수 있습니다. 여기서 Agile적 방법이 좋은 효과를 발휘할 수 있는데 Agile에서는 먼저 도전하고 더 잘할 수 있게 동기부여하는 것을 중요하게 생각하며 더 좋은 성과를 내면 그에 상응하는 보상(Benefit Share)을 하여 소프트웨어 개발에 참여하는 사람들이 자발적으로 좋은 품질의 소프트웨어를 개발할 수 있도록 유도합니다.
아키텍트는 중요한 것을 찾아내고 조정(Control)할 수 있어야 합니다. 여기서 중요한 것의 의미는 바뀌었을 때 파급효과가 매우 큰 것입니다.
아키텍트가 되려명 여러모로 철저한 준비가 필요합니다.
C와 같은 언어를 사용한다면 함수와 데이타를 바탕으로 소프트웨어를 개발할 수 있습니다.
하지만 소프트웨어가 복잡해질수록 함수와 데이타만 가지고서는 빠르게 변하는 비즈니스 환경에 맞는 소프트웨어를 개발하기에는 한계가 따릅니다.
무었인가 고객의 요구단위에 맞게 소프트웨어를 변경할 수 있는 단위가 필요합니다. 이러한 단위가 (함수 + 데이타) > 객체(Object) > 컴포넌트(Component) > 서비스(Service) 순으로 발전하였다고 생각합니다.
예를 들어 통신사의 경우 고객에게 많은 새로운 서비스를 제공하여야 하기 때문에 컴포넌트 등을 활용하여 시스템을 구축하지만 제조업의 경우 변화가 적기 때문에 C와 같이 함수와 데이타를 기반으로만 시스템을 구축하기도 합니다.
아키텍트는 공통에 많은 관심을 가지고 있으며 공통되는 부분을 해결하기 위하여 지속적으로 미팅을 통하여 Interface와 Data를 찾아야 합니다.
여기서 박현철 이사님만의 노하우를 하나 배웠는데 Software Architect Board(SAB)라는 것입니다.
SAB는 여러 Meeting을 포함하고 있는 커뮤니케이션 방안입니다.
- CIO Meeting (CxO Level)
- SAB A: 부장급 Meeting
- SAB B: 운영팀 Meeting
- SAB C: SI 조직의 품질관리 조직 Meeting
- SAB D: 갑의 과장 및 대리급 Meeting
마지막으로 좋은 아키텍트가 되기 위해서는 T-Network가 중요하며, Fun & Professional을 갖추는 것이 중요하다는 조언을 해주었습니다.
그리고 현재 서비스 플랫폼이란 것을 만들고 있는 나에게 서비스란 개념은 풀기 어려운 숙제여서 박현철 이사님께 "서비스란 무었인가?" 라는 질문을 하였습니다. 이사님의 답변은 "서비스란 비즈니스이다." 였습니다.
결국 비즈니스를 완성하기 위해서 서비스가 존재하므로 이는 맞는 이야기입니다. 수 많은 서비스의 정의보다 간략하고 많은 의미를 내포하고 있다고 생각합니다. 물론 구체화는 제가 시켜야겠지만요 ^^
좋은 아키텍트가 되는 아낌없는 조언을 해주신 박현철 이사님께 감사드립니다.
박현철 이사님께서 본 세미나에 관한 요약 및 SOA에 대한 좋은 글을 작성하셨습니다. EVA의 리더이신 손영수님의 블로그에 가시면 박현철 이사님의 좋은 글을 다운로드 받으실 수 있습니다. 무려 90장이 넘는 PDF 문서인데 좋은 글과 재치넘치는 글이 실려 있습니다.
제가 박현철 이사님께 드린 약간은 바보같은 "서비스란 무었인가?"에 대한 좋은 답이 들어 있습니다. 모두 한번씩 살펴보시길 권해드립니다.
'Architecture for Software' 카테고리의 다른 글
| 정보시스템 기술 가이드 라인에 대하여 (2) | 2009.03.13 |
|---|---|
| Devide and conquer와 Separation of Concerns (1) | 2008.08.26 |