내가 예전에 만들었던 소프트웨어에 이런 것이 있었다.

AutoCad에 애드인하는 소프트웨어 였는데. 건축설계사무소에서 Cad에 설계를 할때에 정의된 클립아트 형태 ( 계단, 지붕, 문 등등 )를 사용해서 아파트나 주유소와 같은 건축물을 설계하면 관련 클립아트들이 컴포넌트 형태로 건축 일위대가라는 속성과 연결되어져서 실제 건축에서 산정되는 단가를 추출해주는 프로그램이었다.

건축가의 처음 '투시도'하나에서… 실제 '건축내역서'까지 파생되는 과정을 보면, 현재의 소프트웨어의 구상과 참으로 유사한듯 하다.

아마도, 완성된 프로그램을 빠르게 도식화해서 '고객'과 협의에 사용하게 하는 프로그램이 만들어진다면, 정말 괜찮을 듯 하다.

말이 조금 빗나갔지만, 아키텍쳐를 바라보는 View에 따라서 다 다르다.

업무관점에서 바라봤을때에..

구현관점에서 바라봤을때에..

시스템 관점에서 바라왔을때에.. 모든 시야에 따라서 그 레이어는 달라지게 된다.

네번째로 기술적으로 균일하게 만들 수 없다는 것을 알아야 한다.

다양한 기술과 다양한 개발자들과 일해야 하기 때문에, 그 기술 구조와 업무 구조에 따른 형태를 잘 구상해야 한다. 특히나 사업관리와 잘 이야기해야 할 것이 유지보수도 쉽고, 인력 수급도 쉽고, 개발 난이도도 낮은 수준의 시스템을 그리라는 것이다.

목표치를 조금은 낮추어 잡아야 프로젝트의 성공확률이 높아진다.

그리고, 개발언어, 툴에 너무 끌려다니면 안된다. 그래서, 구현을 생각하지 말고 생각해야 한다. 단순 CRUD성 프로그램을 만들기 위해서 복잡한 아키텍쳐를 구사할 필요가 없다.

가능하면 자동 코드 생성이 되는 툴을 사용하라.

다섯째로 일은 사람이 한다는 점.

이야기 많이 하고 술 같이 많이 마시고, 담배피고.. 결국 머리가 희게된다..ㅡ.ㅡ;

사람과의 관계가 가장 중요하게 된다는 점이다.

이올린에 북마크하기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.