납득할 수 있는 설계를 어디서 배울 수 있을까? Methodoloy

저는 여전히 코더(coder)입니다~  일부 발췌..
하물며 마감 시한에 쫒기는 일개 개발자들이 소프트웨어 설계를 하기가 쉬운데 아닙니다. 그 보다 심각한 것은 개발자들이 설계를시도해도 아무도 그것을 가치있는 일이라고 인정하지 않는다는 것입니다. 오히려, 그럴 시간에 코드 한 줄이라도 더 작성하라는잔소리를 듣게 마련이죠.

또, 국내에서 아키텍트라거나 소프트웨어 디자이너 혹은 소프트웨어 설계 전문 컨설턴트라는명함을 달고 활동하시는 분들의 수가 지나치게 적고, 아키텍트라는 직함을 가지신 분들의 활동 역시 개발자들을 지도하는 역할이아니라 프로젝트 일정 제시, 리스크 관리, 방법론 제공, 문서 표준화, 표준 프레임워크 구현 등에 머물고 있다는 것입니다. 다들가기 싫어하고 얻을 게 없다는 군대를 가도 6주동안 훈련을 받습니다. 그런데 도무지 어디에도 소프트웨어 설계를 제대로 가르치는곳이 없다는 것입니다. 그럴 사람도 없습니다. 그런데, 프로그래머들에게 알아서 설계를 학습하라는 것이 얼마나 가혹한 요구인지 더이상 말하기도 지겨울 따름입니다
이견있는 부분을 언급하고
납득할수 있는 설계를 어디서 배워야 하는지 긁적여보겠음

먼저.. 설계가치를 인정하지 않는 자는 누굴까..
'심도있는 설계를 하느니 그 시간에 코딩 한줄 더 하는게 낫지..'
이와 같은 생각을 하고 설계가치를 저평가하고 취급하는 것은 개발자 자신.
시간에 쫓길 때 상대적으로 설계의 가치나 비중을 낮게 보는 개발자 분들이 많다.
널널할 때 하는게 설계가 아니다..
여유있을때만 설계를 할 수 있다면
자신이 하는 설계가 맞는 설계인지 잡짓은 아닌지 스스로 점검해보길 바람.
그리고 설계에서 코드레벨은 정말 일부.. 마지막 순간의 매직이란거;;.
그럼에도 불구하고 코드레벨 이외 영역에 관심을 두는 개발자분들은 많지 않던데..

업계에 설계전문 컨설턴트란 롤은 들어보지 못했다.
예로, 최근 설계에 대한 이슈를 안고 있는 대형 프로젝트가 두 개가 있는데..
이례적으로 아키텍처가 상세하게 분화되서 분야별 아키텍트가 컨설턴트로 투입되었고,
솔루션 기반의 implementation consulting이라는 롤도 별도로 존재하고 투입되었다.
하지만 이런 환경임에도 설계 컨설팅은 없다.
별도 롤로 구분하지 않고 기술관련된 전반적인 문제들을
아키텍처 팀이나 그룹에 위임을 하는게 일반적인 프로젝트들의 전략이기 때문.
실제로 대형 프로젝트 아키텍처 팀이나 그룹은 그러한 이유로 팀사이즈가 꽤 큰 편.
   
그렇다면 프로젝트에서 누가 설계를 가이드해야 할까?
설계는 다분히 전략에 대한 내용들도 많고, 영향을 미치거나 받는 부분이 많다.
시간적으로도 일정 'phase'에 국한되지 않고, 특정 'discipine'에 한정되지도 않는다.
전략들을 설계로 모으고 드라이브 하는 사람은 방법론과 아키텍트.
아키텍처 적용이전은 방법론, 적용되는 시점부터는 아키텍트.
따라서 방법론, 아키텍트 둘의 긴밀한 협조로 설계를 일궈나가야 한다.
그렇지만, 200억, 500억대 프로젝트에서 아키텍트, 방법론
둘 다 빵꾸내기도 하는 이 현실은 완전 시궁창이지만서도..(먼산~)
방법론 롤 자체가 공석인 경우가 많다.
그럼 누군가는 프로젝트 전반, 영역별로 전략을 수립하거나 조정해야 한다.
하지만 아무도 해당 영역의 롤을 커버하지 않기 때문에
설계시점에 설계정책,원칙,기준이 전혀 마련되어 있지 않은 상태가 대부분.
능력있는 사람도 구하기 쉽지 않고, 능력이 있어도 쉽지 않음.. 중립성, 소속, 정치 등
(가령 경영진이 중요요건에 영향을 주는 것을 상당히 늦게 준다 치자.
(그럼 분석설계깊이, 정의방법, 일정, 연계전략, 조직구조, 마이그레이션, 테스트 등..
(discipline이나 파트별로 널린 것들의 수행전략과 방법을 수립하고 피드백, 정리해서
(고객과 pmo, 수행팀의 각 영역별 관련자들을 깔끔히 설득하고 가이드를 내놔야 한다.
(품질, 아키텍트에게는 롤오버라 원래 책임이 없기 때문에 컨트롤 안된다. pm은 바쁘다.

아키텍트 또한 롤이 빵꾸나는 경우가 많아서 일이 힘에 부침.
돈 아깝다고 아키텍트 롤을 중간중간 빵꾸내고 진행하는 프로젝트 부지기수..
생각외로 아키텍트 인력이 꽤 모자란채로 돌아가는 프로젝트들이 많다.
코드 외에 도메인 및 기타 영역에 관심을 두는 아키텍트도 매우 드문 상황에서..
남을 도와주기능 커녕 내 배가 고픈 상황이 전반적.. 편하게 가는 프로젝트도 있겠지만서도;;
 
그럼 설계 전체적인 윤곽이나 납득할 수 있는 설계를 배우려면 어떻게 해야 하나?
우선, 개발라이프사이클 전반에 대한 경험 필요.
책에서 언급되는 모든 것을 배제한 퐌타쥐한 환경에서
개발자의 코드레벨에서 최종 구현에 대한 일부 얘기와 고찰만으로 한계가 있음..
(요구공학 책,논문 수십개 봐도 요구사항 잘 안나오는것과 마찬가지;

이후, 대규모 프로젝트에서 설계의 시작과 끝을 드라이브해 본 사람 붙들고,
무슨 삽질을 했었고, 무슨 일이 발생했는지.. 언제 뭘 왜 하는 지 물어보는게좋다.
이 분야를 오래 지키고 경험해온 수십명의 각파트별 리더라던가 아키텍트들을
포함한 1-2백명의 개발자와 고객사, 수행사 인력들과 주변 인물들로 부터
이해를 획득했다는 것은 그만한 무언가가 있었다는 것이니까..

그리고 여러번 경험해 본 사람이 훨씬 나을 확률이 높은데
왜냐면.. 나름의 공부와 고통스러운 통찰에도 불구하고
환경, 또는 자신의 부족함으로 먹히지 않는 가이드가 걸러지고 거기서 배우기 때문.


p.s 한마디 하는데 본인포함 블로그에는 거품이 많다는거..
조낸 무식한 본인이 보기에도 열에 아홉은 설계와 쥐뿔 관계없는
상상의 나라 얘기, 개발의 일부 얘기, 아니면 무슨책 몇페이지 얘기;;
블로그 이미지 뻥튀기 마케팅이 참 대단하다고 해야할 지 뭐라 해야 할 지;;

툴, 코드, 프레임워크 등으로 운좋게 권력을 획득해서
잘 모르고, 확신없이 책과 여기저기서 주워들은 것으로도
설계에 대한 가이드가 종종 먹혀 들어가는 경우도 꽤 많은데..
줏어들은 설계로 개발자에게 완전 헛삽질시키는거 자주 봄.. 블로그에서도 자주 봄;;
똘똘한 고객에 걸려서 줏어들은거로 응대하려다가 논리부족에 피보거나,
신경질적 대응으로 압도하려다가 잘 안통해서 개피보는 경우도 보고;;  애도;;

핑백

  • Blog.RedAge.NET » Blog Archive » 아아.. 이것이 현실이다!!! 2008-11-09 16:07:39 #

    ... Age.NETWelcome to Avalon Home About RedBaron is… Wish List Subscribe 아아.. 이것이 현실이다!!! Cavin님의 글 의 ps 이후 부분이 너무 공감되어 관련된 글을 다시 남겨봅니다. p.s 한마디 하는데 본인포함 블로그에는 거품이 많다는거.. 조낸 무식한 본인이 보기에도 ... more

덧글

댓글 입력 영역