소프트웨어를 개발하는 끝내주게 좋은 방법

블로깅을 시작한지는 그리 오래 되지 않았지만 블로그 운영을 시작하면서 자연스럽게 인터넷에서 소프트웨어를개발에 대한 다양한 글들을 보게 되었습니다. 

대부분의 글들은 자신의 직,간접적인 경험에 의해서 작성되지만 모든 글들을 쓰면 그 백그라운드에 대해서는자세히 설명할 수가 없으므로, 글을 읽는 독자들은 오해를 하는 일들이 잦을 것으로 생각합니다. 즉 그 경험들과 지식들이 나에게 똑같이 적용이 되거나 도움이 될 것이라고 단순히 생각하는 오류가 벌어질 수도 있을 것 같습니다. 

그래서 제가 쓰는 글들은 자연스럽게 소프트웨어를 개발하는 기본 원리나 원칙에 포커스를 하고 있습니다. 수많은 소프트웨어 개발사와 개발자들을 만나면서 단순한 기법이나 툴의 사용보다 기본 원리를 익히는 것이 더중요하다는 것을 알게 된 것도 한 이유입니다. 그리고 그런 글들을 계속 읽다보면 자연스럽게 친숙해지면서 몸에 익는다면 소프트웨어를 개발하는데 도움이 좀 되지 않을까 생각합니다.

결국 끝내주게 좋은 방법은 없고 원리를 알고 나서 응용을 하는 것이 제대로 소프트웨어를 개발하는 방법이라고 생각합니다.

소프트웨어를 개발하는 기본 원리는 소프트웨어의 종류나 규모에 따라서 다르지 않습니다. 다르다면 원리라고할 수 없겠죠. 팩키지 소프트웨어나 펌웨어나 SI나 게임이나 기본 원칙은 다르지 않습니다. 단지, 현실에 응용이 될 때는 각각의 특성에 따라서 다양한 방법의 변화가 있을 수 있죠.

최대 30MM이나 50MM짜리 프로젝트만을 수행해 본 개발자는 그 테두리에서의 경험에 대해서만 얘기를 할수 있는데, 그 방법이 수백MM 규모의 프로젝트와는 맞지 않을 수 있을 것입니다. 수백MM짜리 규모의 프로젝트는 차원이 다르죠. 어설픈 방법으로도 소규모 프로젝트는 그럭저럭 수행이 될 수 있어도 규모가 그정도 커지만 요행을 바라기는 어렵습니다.

또, 주로 SI프로젝트나 외주 용역 프로젝트만 수행을 해 본 경험이라면 소프트웨어를 개발하는 기본 원리보다는 예를 들어 고객을 다루는 법, 계속 변하는 요구사항에 대응하는 법, 적당한 품질로 타협하는 법 등에 대해서더 많이 고민해 봤을 수도 있습니다.

저 또한 SI의 경험보다는 팩키지라던가 대규모 프로젝트의 경험이 더 많기 때문에 모든 분야를 다 경험해보고하는 얘기는 아닌 것이죠. 

결국 글을 일고 판단하는 것은 읽는 사람의 몫일 수도 있는데, 저의 괜한 기우일 수도 있겠네요.

판단은 스스로하고 너무 끝내주게 좋은 것을 찾으려고 하지는 맙시다.