블로깅을 시작한지는 그리 오래 되지 않았지만 블로그 운영을 시작하면서 자연스럽게 인터넷에서 소프트웨어를개발에 대한 다양한 글들을 보게 되었습니다.
대부분의 글들은 자신의 직,간접적인 경험에 의해서 작성되지만 모든 글들을 쓰면 그 백그라운드에 대해서는자세히 설명할 수가 없으므로, 글을 읽는 독자들은 오해를 하는 일들이 잦을 것으로 생각합니다. 즉 그 경험들과 지식들이 나에게 똑같이 적용이 되거나 도움이 될 것이라고 단순히 생각하는 오류가 벌어질 수도 있을 것 같습니다.
그래서 제가 쓰는 글들은 자연스럽게 소프트웨어를 개발하는 기본 원리나 원칙에 포커스를 하고 있습니다. 수많은 소프트웨어 개발사와 개발자들을 만나면서 단순한 기법이나 툴의 사용보다 기본 원리를 익히는 것이 더중요하다는 것을 알게 된 것도 한 이유입니다. 그리고 그런 글들을 계속 읽다보면 자연스럽게 친숙해지면서 몸에 익는다면 소프트웨어를 개발하는데 도움이 좀 되지 않을까 생각합니다.
결국 끝내주게 좋은 방법은 없고 원리를 알고 나서 응용을 하는 것이 제대로 소프트웨어를 개발하는 방법이라고 생각합니다.
소프트웨어를 개발하는 기본 원리는 소프트웨어의 종류나 규모에 따라서 다르지 않습니다. 다르다면 원리라고할 수 없겠죠. 팩키지 소프트웨어나 펌웨어나 SI나 게임이나 기본 원칙은 다르지 않습니다. 단지, 현실에 응용이 될 때는 각각의 특성에 따라서 다양한 방법의 변화가 있을 수 있죠.
최대 30MM이나 50MM짜리 프로젝트만을 수행해 본 개발자는 그 테두리에서의 경험에 대해서만 얘기를 할수 있는데, 그 방법이 수백MM 규모의 프로젝트와는 맞지 않을 수 있을 것입니다. 수백MM짜리 규모의 프로젝트는 차원이 다르죠. 어설픈 방법으로도 소규모 프로젝트는 그럭저럭 수행이 될 수 있어도 규모가 그정도 커지만 요행을 바라기는 어렵습니다.
또, 주로 SI프로젝트나 외주 용역 프로젝트만 수행을 해 본 경험이라면 소프트웨어를 개발하는 기본 원리보다는 예를 들어 고객을 다루는 법, 계속 변하는 요구사항에 대응하는 법, 적당한 품질로 타협하는 법 등에 대해서더 많이 고민해 봤을 수도 있습니다.
저 또한 SI의 경험보다는 팩키지라던가 대규모 프로젝트의 경험이 더 많기 때문에 모든 분야를 다 경험해보고하는 얘기는 아닌 것이죠.
결국 글을 일고 판단하는 것은 읽는 사람의 몫일 수도 있는데, 저의 괜한 기우일 수도 있겠네요.
판단은 스스로하고 너무 끝내주게 좋은 것을 찾으려고 하지는 맙시다.
