아키텍트가 되기 위해서 우리에게는 어떠한 덕목이 필요할까요?
2007년 10월에 소프트웨어 아키텍쳐 이론과 실제 (Software Architecture in Practice)의 저자인 Rick Kazman이 한국을 방문해 ATAM에 대한 강연을 하였습니다.
세미나가 마친후 어떤 분이 “당신과 같이 휼룡한 아키텍트가 되기 위해서는 어떠한 소양과 지식이 필요한지 설명해 주시겠습니까?” 라는
질문을 했고, 이에 대한 멋진 답변을 해 주셨는데 제가 알고 있는 지식을 덧 붙여 여러분과 함께 공유하고자 합니다.
호환성 (Compatibility) 이라는 말을 들어보셨나요?
- .NET 3.0 버젼 Framework에서 .NET 2.0으로 구현했던 Application이 돌아가지 않는다면?
- JDK 1.6버젼에서 JDK 1.4 Framework 기반의 Application이 돌아가지 않는다면?
새로 나온 제품이 아무리 좋은 기능이 많이 추가 되어 있더라도..예전 제품과 호환이 되지 않는다면, 그 제품은 잘 팔리지 않을 겁니다. 이번 POST 를 통해 우리가 Product 또는 Framework을 만들때 고려해야 되는 호환성과 여러가지 종류에 대해서 공유하고자 합니다.
혹시 소프트웨어를 만드실때, 땅콩버터 방식으로 만드시지는 않나요?
땅콩 버터라는 것은 Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스를 말합니다.
Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들때 주로 사용하는 방법입니다.
이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올수 있는 장점이 있습니다. 마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저수준의 Library를 개발할때는 이러한 방식이 선호 됩니다.
만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야하고, 다양한 시나리오를 요구하는 경우인데도, Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 국내의 많은 회사들이 이러한 구조를 가지고 있는데요. 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될뿐만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제등이 발생됩니다.
여러분에게 좋은 소식을 하나 전해드리고자 합니다.
POSA2에 이어 또 하나의 명서인 Framework Design Guidelines 2nd Edition의 편역을 위한 모임을 가졌습니다.
이 책은 Framework를 잘 설계하기 위한 Guideline을 제공하는 서적으로 Microsoft의 .NET Framework 설계팀들이 직접 집필한 서적입니다. Framework을 처음 설계하는 개발자에게는 매우 유용한 서적이 될듯 합니다.
현재 http://fdg.springnote.com 에서 작업을 시도하고 있으면, 저희 스터디시 만들어진 가치있는 공유물들을 여러분과 함께 나눌 생각입니다.
Conway’s law (콘 웨이의 법칙)
If you have four groups working on a compiler, you’ll get a 4-pass compiler
당신이 하나의 컴파일를 만들기 위해 4개의 팀을 만든다면, 당신은 4단계(four-pass) 컴파일러를 얻을 것이다.
이 말은 시스템의 구조는 시스템을 설계한 조직의 구조(형태)를 그대로 반영한다는 것입니다. 보면 볼수록 묘한 감정과 예전 기억들이 떠오르는 법칙입니다.
성공적인 회사생활을 하기 위해서는 순수한 개발 능력외에 많은 변수들이 우리를 따라 다닙니다.
- 사내 정치에 승리하기 위한 명분 만들기
- 서로간의 책임을 회피하기 위한 일 덜 가져오기
- 영업 / 기획 / 개발 부서 간의 대화 단절
- 직급 문화가 가져오는 대화의 단절 (상명하복의 의사 전달)
블로터 닷넷에 저의 인터뷰 내용이 실렸습니다.
(제가 정한 제목이 아니라서요. .. 아키텍쳐 매니아 입니다. ^^;; 전 소프트웨어 구조에 관심이 많거든요. )
고수를 찾아서라는 제목으로 황치규 기자님이 실어 주셨는데. 거듭 강조하지만 전 절대 고수가 아닙니다. 역시 Architect의 A도 따라가지 못하는 사람입니다. 그러니 저를 고수로 둔갑해 주신 것이 매우 부담스럽습니다. 거듭 말해 고수가 아니라는점 강조 드리고 싶습니다 .
인터뷰 뒷 애기
황기자님께서 요점을 많이 잡아 주셨으나, 제가 강조해서 말한 부분이 일부 빠진거 같아 약간 보충을 하고자 합니다.
아마 소프트웨어 공학을 전공한 저만의 언어로 말해서 이런 일이 발생하지 않았나 생각이 드네요. 저의 생각을 이번 포스팅을 통해 좀더 다루고자 합니다.
저 역시 많은 경험이 없지만 10년이란 시간 동안 IT에 몸 담아온바 오랜만에 비 기술지향적인 애기들을 함으로써 후배 개발자들에게 몇가지 조언을 하고자 합니다.
제가 본업을 가지고 있으면서도 무료 세미나에 스피커로 활동한지도 5년이 다 되어 갑니다. 항상 신기술, 변화의 중심에 서 있을려고 노력했습니다. 하지만 많은 시간이 지난후 과거를 되돌아 보니, 너무 신기술만 바라보는 바보같은 생활을 하지 않았나 생각이 듭니다.
꿈을 찾아 당장 하고 싶은 재미난 흥미위주의 공부와 스터디를 해왔고 이것들이 나쁜 것들은 아니지만, 좀더 균형잡인 시선과 시각으로 기술을 이해하길 바라며 이러한 것들이 매우 중요하다는 것을 공유하고자 합니다.
2000년대 초 Windows Platform 기반하에 프로그래밍을 한 경험이 있다면 Dll Hell 을 들어보셨을 겁니다.
.NET이 나오고 나서 그 문제들이 해결 되었는데요.
요즘은 개발자들을 괴롭히는 새로운 Hell이 있으니 이름하여 Configuration Hell 입니다.
만약 여러분이 Configuration (설정부)를 사용하지 않고 프로그래밍을 즐겨 하신다면 별 감이 안오시겠지만..
.NET , Java 개발자라면 대부분 동감이 가는 단어일 것입니다.
위 플랫폼의 개발자들은 변화에 유연한 대처를 하기 위해 Metadata 지향적인 모델을 자주 사용합니다.
그렇다 보니 개발자는 많은 설정 영역들과 파일들을 만들어 내게 됩니다.
충돌없이 관리하는 것 부터 설정 기능등을 일일이 공부해야 되는 괴로움 다 아시죠!
그렇다고 설정 파일을 안 쓸수도 없구? 어떻게 해결 해야 될까요?
현재 나와 있는 해결사례들을 공유해 보도록 하죠
Architecture 101 