윈도우 프로젝트 필수 유틸리티
이 책은 SVN에 대해 다룹니다. SVN 에 대해 꽤나 상세하고 쉽게 설명하고 있기 때문에
큰 프로젝트를 하는 여러 개발자들에게 평가가 참 좋은 편이죠. 그 책 내용 일부중 참 마음에
드는 부분이 있어서 긁어왔습니다. 필자는 SVN의 필요성을 강조하려고 작성한 내용이겠지만,
그 필요성에 대한 예제들이 참 가슴에 와닿고, 전부 진짜 있었던 이야기들인 것 처럼 아주
생생합니다 :)
아마도 이 작가분은 소스 프로젝트 관리를 엿같이 하고 퇴사한 전임자 때문에 고생한 사람들에
대한 얘기를 여기저기서 많이 들은게 아닌가 하는 생각이 듭니다. 어쨌든 직접 한번 읽어보세요.
특히 강추하는 부분입니다 (SVN 을 단지 WinMerge 등으로만 이용하고 Trac 이나 심볼 서버
등과의 작업을 병행하지 않으신 분들은 책을 통채로 사서 읽어보시는 것도 추천합니다)
일하기 편한 환경 만들기
("윈도우 프로젝트 필수 유틸리티" 中)
이재홍 (pyrasis) http://www.pyrasis.com
어떤 소프트웨어 개발팀이 있습니다. 물론 전담 테스트 팀도 갖추고 있습니다. 이 개발팀의 환경은 이렇습니다. 소스 코드는 개발자 각자 PC에서 알아서 관리하고, 고객에게 판매되는 제품도 개발자 PC에서 직접 빌드합니다. 그리고 빌드된 exe와 dll 파일을 취합하여 FTP 서버에 업로드합니다. 이제 테스트 팀은 FTP 서버에 접속하여 빌드된 파일을 받아들고 테스트를 시작합니다. 별 문제없이 돌아갈듯한 환경입니다. 모든 구성원이 정신 바짝 차려서 일한다면 말이죠.
이런 환경에서 일을 하다보니 여러가지 문제점이 보이기 시작합니다. 개발자는 개발을 하면서 소스 코드가 든 폴더를 날짜별로 복사해가며 관리를 하기 시작합니다. 그래도 이런 사람은 양반입니다. 어떤 개발자는 그냥 귀찮아서 소스 코드가 든 폴더 하나로 개발을 진행합니다.
테스트 팀은 개발팀에서 전달받은 파일로 테스트를 합니다. 마침내 여러가지 버그를 발견하였고, 버그에 대한 내용을 종합하여 엑셀로 작성한 뒤 개발팀에게 넘겨줍니다. 하지만 정해진 전달 경로가 없기 때문에 메일로 보내기도 하고, 메신저로 보내기도 합니다. 더 나아가서 버그 내용을 말로 전달하고 끝낼 때도 있습니다.
개발 업무에 쫓기는 개발자는 버그 내용을 기록한 엑셀 파일을 자신의 PC 어딘가에 방치한 채 그냥 넘어가기도 하고, 말로 전해들은 버그 내용은 쉽게 잊어버립니다. 이런 일이 반복되면서 제품의 버그는 점점 늘어나기 시작합니다. 결국에는 모든 것을 뒤엎고 새로 개발하자는 말이 나오기도 합니다. 테스트 팀 입장에서는 버그 보고를 해도 함흥차사가 되어버리고, 테스트를 제대로 안해서 제품 질이 떨어졌다는 비난만 받게 되니 일할 의욕을 잃게 됩니다.
그래도 이런 저런 고생 끝에 제품이 출시되었습니다. 이제 기술 지원 파트와 고객 지원 파트를 통해서 여러가지 버그가 보고되기 시작합니다. 그래서 개발팀은 버그를 수정하기 위해 담당자가 누구인지 찾게 되었는데, 버그가 발생한 파일의 담당자는 이미 퇴사를 하여 소스 코드가 다른 사람에게 인수인계된 상태였습니다. 물론 새 담당자가 버그를 처리하면 됩니다. 하지만 문제는 이것이 아니었습니다. 퇴사한 개발자는 소스 코드가 든 폴더 하나로 개발을 진행하던 사람이었고, 새 담당자도 이 소스 코드 폴더 하나만 달랑 받은 상태였습니다. 이미 소스 코드의 구조는 엄청나게 바뀌어 있었고, 하위 호환성도 고려되지 않은 채 개발되었기 때문에 버그를 고치려면 구 버전을 다시 만들어야 하는 상황이 되어버린것입니다.
인수인계 과정에서 소스 코드가 분실되는 경우도 비일비재 합니다. 새 담당자에게 소스 코드를 넘겨 줄 때 모두 넘겨주지 않고 실수로 한 두개 빼먹은 상태로 넘겨주기도 합니다. 사고가 터졌을 때에는 퇴사자의 PC는 이미 회수되어 소스 코드를 찾을 수 없을 때도 있습니다.
빌드된 파일 자체도 관리가 되지 않아 FTP 서버에 보관된 파일은 언제나 최신 버전뿐입니다. 버그가 보고되어도 해당 버전의 파일이 없으니 버그를 재현하는 것도 힘들어집니다.(고객 PC에서 해당 파일을 가져오는 수 밖에 없습니다.) 물론 소스 코드 관리가 제대로 되지 않으니 해당 버전을 빌드해서 만들어내는 것도 쉬운일이 아닙니다. 게다가 심볼(PDB) 파일도 따로 보관을 하지 않는 경우가 많아서 덤프 파일을 입수하여도 분석이 힘들때가 많습니다. 정말 디스어셈블된 코드를 보고 버그를 찾는 것도 한계가 있습니다. 고객에게 판매되는 제품을 개발자 각자가 빌드하다 보니 바이러스에 감염된 파일이 제품에 포함되어 배포되는 사고가 발생하기도 합니다. 정말 믿기지 않는 상황들이지만 필자도 겪은 일들이고, 지금도 어디선가 이러한 일들이 벌어지고 있을것입니다.
이제 엉뚱한 곳에 시간을 빼앗기지 않고 개발에만 집중할 수 있는 일하기 편한 환경을 구축한 개발팀의 일하는 모습을 들여다보겠습니다. 일하기 편한 환경을 구축한 이 개발팀은 소스 코드를 Subversion으로 관리합니다. 그리고 각 개발자는 TortoiseSVN을 사용하여 소스 코드를 체크아웃 및 업데이트하고 수정된 내용을 커밋 합니다. 고객에게 판매되는 제품은 빌드 서버에서 빌드합니다. 파일의 버전도 개발자가 올리지 않고 빌드 서버가 알아서 올려줍니다. 빌드 서버는 빌드된 파일을 버전 별로 차곡 차곡 모아둡니다. 물론 심볼(PDB) 파일도 심볼 서버 형식으로 보관을 해줍니다.
버그 보고는 Trac으로 받습니다. 테스트 팀은 버그를 발견하면 해당 프로젝트의 Trac 사이트에 접속하여 버그에 대한 내용을 자세히 기록한 티켓을 생성합니다. 개발팀은 버그 티켓을 확인하여 버그를 수정한 뒤 버그를 수정했다고 답글을 달아놓습니다. 다음날이 되면 자동빌드가 되어 버그가 수정된 새 버전이 올라와 있을것입니다. (급할때에는 강제 빌드 명령으로 즉시 빌드를 할 수 있습니다.) 테스트 팀은 빌드 서버에 접속하여 버그가 수정된 새 버전을 받아 테스트 한 뒤 버그가 수정된 것을 확인하고 해당 티켓을 닫습니다.
개발자는 버그 보고를 티켓으로만 받기 때문에 Trac 사이트만 잘 확인하면 버그 내용에 대해서 잊어버리고 넘어갈 일은 없습니다. 테스트 팀 또한 버그가 수정되면 버그가 수정되었다는 답글이 달리고, 빌드 서버에서 새 버전을 바로 받아 볼 수 있기 때문에 테스트에만 전념할 수 있습니다.
인수인계 과정에서 생기는 각종 문제점들도 이 개발팀에서는 다른 세상 이야기일 뿐입니다. 모든 소스 코드의 내용과 변경 사항에 대한 이력은 모두 Subversion으로 관리되기 때문에 따로 소스 코드를 넘겨줄 필요가 없습니다. 단지 담당하고 있는 프로젝트의 저장소 URL만 알려주면 끝입니다. 이전 버전에서 버그가 발생하더라도 Subversion을 이용하면 해당 버전의 소스 코드를 그대로 가져 올 수 있습니다. 또한 모든 소스 코드가 Subversion 서버에서 관리되기 때문에 특정 소스 코드를 분실하는 일도 발생하지 않습니다.
빌드된 파일도 버전별로 보관을 하기 때문에 버그가 보고되면 해당 버전을 빌드 서버에서 받아 곧바로 재현해 볼 수 있습니다. 그리고 자동빌드를 하면서 Subversion 저장소 정보를 심볼(PDB) 파일에 기록해놓았기 때문에, 덤프 파일을 열면 디스어셈블된 코드 대신 Subversion 저장소에서 소스 코드를 가져와 에러가 발생한 부분을 표시해줍니다. 또한 심볼 서버 형태로 심볼(PDB) 파일을 보관하므로 개발자가 따로 심볼(PDB) 파일을 보관할 필요가 없습니다.
빌드 서버에서 자동빌드를 하기 때문에 개발자들은 제품을 빌드하고 테스트 팀에 넘겨줄 때 소요되는 시간을 절약할 수 있습니다. 또한 제품의 모든 파일은 빌드 서버에서 빌드되므로 빌드 서버만 잘 관리하면 바이러스에 감염된 파일이 배포되는 일은 발생하지 않습니다.
여러분들은 어떤 개발팀에서 일하고 싶습니까?
