대한민국 대표 개발자 [짱가™] 2ed

- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다. 프로젝트를 해요?~~~프로젝트 사업을 만든다, 고객의 요구사항을 듣는다,제안서를 작성한다, 요구사항 분석서를 작성한다, 고객의 요구사항 중 비기능 요구사항을 식별한다, 비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다, 아키텍처를 설계하고 검증을 위한 선도 개발을 한다 , 개발 표준을 제시하고 개발 표준의 준수여부를 체크한다. 위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요..

- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만, 이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다. 다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ. 왜 아키텍트일까? 흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅..