일반적으로 소프트웨어 개발 기업에는 Software Engineering에 대한 가이드 라인이 있다.
단계별 문서양식은 어떻고, 산출물은 어때야 하며, 코딩 스타일은 어때야 하고,
또 소스 관리나 문서 관리는 어떻게 해야 한다는 등이다.
일반적으로 지키라고 하면 괜히 하기 싫은게 우리다.
특히나 같은 부서가 아니라 '기준'을 만드는 부서에서 하는 말이라면 말이다.
최근 가게된 부서는 신규 사업팀이라 SE 부서가 없다.
그렇게도 지키기 싫어했던 개발 가이드들이지만 막상 강제성이 없으니 룰이 없으니 정작 필요한 것들에 대해서는 아쉬움이 생기더라는 말이다.
그래서 이 글에서는 소프트웨어 개발 프로젝트의 효율성을 높이기 위한 SE 요소를 경험에 비추어 이야기 하고자 한다.
어디까지나 비전공자의 글이므로 딴지는 사양한다. 조언은 감사하게 받아들이지만...
대강 이야기 하면...
다음 사항은 내가 일하거나 내와 함께 일하는 사람들이 지켜주길 바라는 내용이다.
하나. 코딩 스타일 통일
사실 코딩 스타일까지 이야기 하고 싶지는 않은 생각도 있다.
워낙 쓸데없는 자유를 좋아하는데다가, 코딩 스타일에 어느정도 개인적인 성향이 나타난다고 생각하기 때문이다.
(모 대기업같은 경우는 한 건물에서 일하는 소프트웨어 인원이 한 2000여명 된다고 생각된다. 이 사람들이 짠 코드가 다 한 사람이 짠것같다면... 웬지 좀 매트릭스스럽지 않은가.)
그러나 이러한 생각은 사실 한사람이 한가지 알고리즘을 맡는 특수성을 지니는 소프트웨어나 한 사람이 한 플랫폼을 담당하는 벤처에서는 별 문제없이 작동했다.
그러나 대기업에서 여러사람이 개발을 하고, 선배가 후배의 코드를 보며 (사실 그러는 경우는 거의 없다! ^^), 담당자가 자주 바뀌는 경우 문제가 발생한다.
남의 코드를 보기 싫어하기 때문이다. ('차라리 새로 짜는게 쉽다'라는 얘기들은 한번씩 들어봤을 것이다.)
다른 사람이 짠 코드를 누구나 쉽게 볼수 있게 하는게 코딩 스타일 통일의 목적이다.
흔히들 '가독성' (readibility)를 높인다고 고상하게 표현하곤 한다.
초심자는 자신의 코딩 스타일을 고집하거나, 특별한 코딩 테크닉을 쓰기도 한다.
더구나 코드를 공유하는 것을 싫어한다. (누가 감히 내가 짠 코드를 함부로 보는건 좀 건방지잖아?)
(나 역시 오랬동안 초심을 읽지 않았었다!!!)
그러나 통일성을 높여 공유를 할 수 있게 만드는게 결국은 좋다는 결론이다.
(내 경험에 비추어보면 회사에만 좋은 것이 아니다.
내가 부서를 옮길때도, 쉽게 도망갈 수 있다. 또, 다른 사람에게 일을 맡기고 휴가가기도 쉽다!!!)
둘. 개발 환경
대부분 통합 개발 환경은 컴파일러가 속한 툴에 의해 결정된다.
여기서 개발 환경이란 에디터, 컴파일러, 빌드 유틸리티, 프로젝트 관리 툴, 디버깅 툴들을 전부 이야기 하는 것이다.
예를 들어, 윈도우 어플리케이션을 개발할때는 MS Visual Studio를 쓰는 것처럼 말이다.
그러나 플랫폼과 CPU 아키텍쳐가 다양해지면 선택의 폭도 넓어진다.
또 메인 환경에 추가적인 툴을 사용하기도 한다.
(MSVS를 사용하면서도 코드 분석을 위해 추가적인 에디터로 source insight를 쓰는 것은 그다지 놀라운 일은 아니다.)
각각의 툴은 장단점을 가지고 있으나 개발자들간에 대략적으로 통일된 툴을 사용하는 것이 혼돈을 줄일 수 있다.
(예를 들어 GNU환경에서 누구는 make 사용을 좋아하고, 누구는 eclipse 프로젝트를 주로 사용한다면, 이 역시 서로간에 침범할 수 없는 영역이 될 확률이 높다.)
중요한 것은 사용 편의성과 범용성을 고려하여 가장 효과적인 툴을 사용하는 것이다.
셋. 버전 컨트롤 시스템
버전 컨트롤 시스템의 목적은 소프트웨어 변화의 역사를 기록하는 것이다.
이 기록의 필요성은 분명히도, 용이한 디버깅과, 여러사람의 공동 작업으로 이야기 할 수 있으나,
단순히 소스 관리의 목적만으로도 매우 훌륭하다.
(복사해서 만들어놓은 코드 디렉토리들이 늘어가기 시작하면 그 필요성을 절감한다.)
넷. 버그/이슈 트래킹 툴
버그 트래킹 툴또한 버그의 역사를 기록하는 것이다.
이것은 재생산되는 버그를 줄이고, 한번 나온 이슈를 끝까지 추적하여 해결하며,
흔히 말하는 '저절로 없어진 버그' 즉 '숨은 버그'에 대해서 관리할 수 있도록 한다.
의료 장비 개발시 FDA등의 인증 기관에서는 소프트웨어의 버그 추적 가능성을 필수 항목으로 생각할 정도로
소프트웨어 완성도를 위해서 중요한 사항이다.
다섯. 스펙
프로젝트 관리를 할때, 문서 작업처럼 귀찮은 것이 없다.
형식에 맞춰야 하고, 잘 써야 하고, 항목을 채워야 한다고 생각이 든다.
그러나 대부분의 회사에서 가지고 있는 문서 양식에 있는 항목은 필요한 정보들이며,
사업화를 위해 조사해야 하는 내용들이다.
소프트웨어 역시 마찬가지이다. 그냥 소프트웨어를 짜면 된다고 생각이 들기도 하지만,
'소프트웨어를 어떻게 만들지'에 대해 고민을 먼저 하지 않는다면,
계속해서 수정에 수정을 더하는 소프트웨어가 되며, 계획도 잘 서지 않는다.
소프트웨어를 만들때 대부분 SRS라는 것을 기본으로 작성하지만,
단순화된 소프트웨어 스펙만으로도 계획적으로 소프트웨어를 개발하고 관리하는데 훨씬 도움이 된다.
다음에는 위의 항목들에 대해 더 자세히 써보고자 한다.
