본문 바로가기

Dev.../소프트웨어 아키텍처

[원고] 소프트웨어 아키텍트가 알아야할 97가지에 들어간 원고... ~.~



제목 : 개발에 있어 형식에 얽매이는 행위야 말로 삽질이다. - 꿈꾸는자.


제가 가장 좋아하는 문장이며 가장 역설적으로 아키텍트이외의 개발자들에게도 끊임없이 요구하는 내용이기도 합니다.


개발자들이 초보시절에 가장 흔하게 실수하는 행위중의 하나는 '이론'과 '경험'이 적기 때문에 자신이 알고 있는 가장 최선의 해결책인 '형식'에 치우치는 경향이 많습니다.

특히, 국내의 특이한 형태의 소프트웨어 개발조직에서 이러한 상황들이 발생하는 경우가 많습니다.


갑,을,병,정의 상황에서 을의 대기업의 이론으로만 무장된 초보 개발자가 어이없게도 아키텍트의 역활을 수행할때에...

병, 정의 고급엔지니어들을 제대로 활용하지 못하고. 자신의 '형식'에 파묻히는 특이한 현상이 발생되기도 합니다.


개발조직도 군대조직과 유사한 것 중의 하나는...

명장은 초보병정들을 데리고도 훌룡한 전투를 치룰 수 있으나, 미련한장수는 용맹스럽고 경험이 풍부한 병사들을 사지로 내모는 경우가 비일비재합니다.

그런 실수중의 하나가... 

바로 '형식'에 얽매여서 개발방향과 조직, 관리를 따라하게 되는 실수라고 하겠습니다.


더군다나, 아키텍트의 역활이 부여되었을때에 가장 먼저 저지르는 실수가 바로 자신이 알고 있는 '틀'에 치우져서  '형식'에 너무 치우치는 개발 스타일을 강요하거나, 종속적인 행위들을 요구하는 아키텍트의 역활을 하는 개발자들을 간혹 만나고는 합니다.


물론, 그들은 자신들이 알고 있는 생각의 틀에서의 '형식'에서 생각하는 것이 편해서인지, 그 틀에 주변의 사람들을 가두려는 경향이 있습니다.

그것이 자신이 판단하기 쉬운 상황으로 만들것이라고 큰 착각을 하게되는 것이죠.

특히나 '이론'에만 충실한 '방법론자'들을 만나게 되면 이런 '형식'의 '삽질'을 만들게 주변의 개발조직을 유도합니다.

( 더군다나. 특정상황에 어울릴 법하거나, 특정한 인물들, 특정 조직과 문화에나 어울릴 법한 외국의 방법론을 국내의 말도안되는 상황에 대입시켜 놓고, 그 틀에서 움직이라고 한다면.. 과연 그 '형식'은 훌룡한 형식일까요?' )


저도 다양한 개발자들과 일해봤습니다. 각자의 경험과 각자의 해결책들을 다양하게 경험한 개발자들의 경험을 어떻게 소화시키고 조화롭게 이끌어가느냐가 아키텍트가 가져야할 중요한 포인트가 아닌가 합니다.



가끔은 자신의 방법론이 옳다고 우기는 방법론자 중심의 개발자를 만나기도 합니다.

물론... 그 방법이 틀렸다고 이야기하는 것은 아닙니다.

그 방법은 자신의 경험과 자신이 경험한 곳에서의 경험일 뿐이지. 자신이 그 '경험'을 다른 조직원이나 개발자들에게 '전파'할 수 있는 '지식'의 상태가 아니기 때문입니다.

그런 '지식'이 아닌 상태에서의 '경험'은... '형식'으로 흘러갈 가능성이 농후합니다.


이러한 '형식'의 문제점은 무엇일까요?


그것은 '형식'은 개발자들간에 가장 중요한 '의사소통'수단에 대한 강제화된 형식을 제시하게 합니다.

자신이 원하는 개발문서 양식, 업무 프로세스, 일하는 스타일, 잘 쓰는 패턴들 등.

자신이 경험한 '형식'을 최고로 생각하며 주변과 의사소통하려 하지 않기 때문입니다.


특히나... '관리'경험이나 '의사소통'의 경험이 적은 개발자들이 이러한 실수를 흔히 하게 되죠.


개발에 있어서 문서화나 의사소통은 '필요한 수준'의 적정선이 필요한 것이고, 조직의 능력과 역량에 맞는 형태여야 합니다.

자신이 연구실에서 얻은 방법은 그 연구실 사람하고 맞는 것이지. 실제 필드에 나와서 사용할 수 있는 '지식'의 수준이 아니기 때문입니다.


방법론이건 패턴이건. 개발의 경험과 지식은 모두 '전달'되어저야만 '지식'이 되는 것입니다.

'전달'되어지지 않은 '지식'은 자기만의 언어이고... 말그대로의 '형식'으로의 집착이 되는 것입니다.


다만, 수학에서 이야기하듯이 '공리'( 公理, axiom )와 같은 단어들은 필수겠죠.

개발자들간의 의사소통을 위해서 우리는 그 나름대로의 표현법을 배우고 사용하니까요.

하지만, 더 좋은 방법이 있고, 팀원들 대다수가 동의하는 현재 업무에 더 적합한 표기법등이 있다면...

나름대로 변형해서 사용해도 무방하다고 생각합니다.


소프트웨어 개발이야말로 '변증법'적이지 않나 합니다.

변증법적 접근의 목표 자체가 이견을 합리적인 토론으로 해결하는 것으로 명제를 찾아나가는 행위 자체가 소프트웨어 개발의 가장 중요한 키 포인트라고 생각합니다.


이제는 건축적인 컨셉과 마인드가 소프트웨어 개발에 중요한 영향을 주었다면, 이제 철학적인 부분들이 소프트웨어 개발에 중요한 형태가 된다고 생각합니다. 2.0적인 생각 자체가 그런것이 아닌가 합니다.

소프트웨어 개발 자체와 생태계, 개방형 구조등... 소프트웨어를 개발하는 그 자체만을 중요시하기 보다는, 소프트웨어를 개발하고 파생되는 형태와 미래에 대한 것까지 고민하는 것. 그것이 소프트웨어 개발의 미래학적인 모습이 아닌가 합니다.

뭐, 이 논제에 대해서는 나중에 시간나면.. ~.~


어차피, UML과 같은 표기법들도 그러한 발전과정을 거쳐서 왔으니까요.


'형식'에 대한 문제를 제기하고...

그 '형식'을 파괴할 때에만 '지식'은 하나씩 발전하는 것은 아닌지...


제가 가끔 소프트웨어아키텍처교육을 할때에 이야기하는 기본적인 컨셉은 몇가지 안됩니다.

하나는 소프트웨어는 100% 품질을 보장할 수 없다!

둘, 정말 중요한 것을 잊어버리면 안된다.

셋. 형식에 얽매이지 말아라.


이 3가지를 이야기합니다. 물론, 모두 같은 이야기입니다.


소프트웨어 개발이라는 행위는 분명 제한된 시간과 인력이 투입되는 행위입니다. 그리고, 통제할 수 없는 사람이라는 존재가 언제나 있죠.

여러 개발방법론과 선배들이 이야기하는 경험담을 듣다보면, 소프트웨어 개발을 할때에 어느 정도 기능이나 품질을 포기할 수 있는 방법을 가르쳐 주어야 한다는 것입니다.

더군다나, 어정쩡한 방법론 마케터들에게 휘둘려서...

잘 모르는 개념이나 문서화의 틀 속에 개발조직을 가두게 하는 행위야 말로 가장 큰 삽질입니다.


방법론이라는 것은 그렇게 '형식'적인 것이 아닙니다.

방법론에서 예제나 예시로 보여주고 있는 것들은 그 집단과 그 지식수준, 그 도메인과 그 형태에 맞는 방법일 뿐입니다.


방법론이란 기성제품처럼 백화점에서 사다가 입히는 옷이 아닙니다.

일종의 양복점이라고 해야할까요?

자신의 능력, 주변사람들의 능력, 축적된 기술수준, 도메인 지식, 의사소통능력, 상사의 인지능력, 개발기간 등등...

모든 것을 고려하여서...

적절한 수준의 목표와 비전과 함께 제시되어야 하는 일종의 '지식기술'입니다. ~.~

그러므로...

아키텍트들은 그런 형식과 이론, 기초 예제에 너무 따라가면 안됩니다.


또한, 패턴에 너무 얽매이는 것 또한 '삽질'입니다.

'패턴'은 '지식'일 뿐이지. 그 형식만을 중요하게 여기는 것은 아닙니다.


방법론이건 패턴이건 '형식'에 치우쳐서 그 '형식'을 지키려고만 하는 행위는 분명 삽질입니다.


사례와 '지식'을 그대로 따라간다고...

모든 일이 성공적으로 끝나는 것은 아닙니다.


선배들의 사례를 기반으로 그 '형식'에 치우치지 않고

자신만의 '지식'으로 습득하는 것이 최선입니다.


사실...

똘똘한 개발자 10명과 일하는 방법과

초보 개발자 10명과 일하는 방법이 같을 수 없겠죠.


또한,

1년의 개발기간... 6개월의 개발기간...

다 다르죠.


개발자이건 아키텍트이건 실제 업무에 들어가서 기억해야할 것은...


'형식에 얽매이는 행위야 말로 삽질이다'라는 것을 기억해야 합니다.


자기소개(?)...

현재 한국디지털병원 수출사업현동조합의 디지털병원IT전략 전문위원으로 자문일을 하고 있으며, (주)이디스넷에서 전략담당이사로 일하고 있습니다. (전)관동대학교 의과대학 명지병원의 정보통신팀장과 (전)헬스로그의 IT담당이사, 그리고 (전) 우리들병원/우리들헬스케어에서 온라인담당이사, (주)우리들제약과 (주)아원과 같은 제약, 의료기기생산업제의 정보시스템 경험과 온라인게임개발 부터 대형SI까지의 경험이 풍부한 삽질의 대가였으며 현재는 기존에 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있는 사람. 현 KEA( www.gokea.org 의 디지털병원수출기획단의 디지털병원 IT관련 자문위원도 하고 있다는.


GEDC0100.JPG
원문은...
http://zetlos.springnote.com/pages/5484737