이번에 워낙에 일을 주는 업체 때문에 고생을 해서 지금은 이쪽 내용을 계속해서 고민하고 있다. 아는 형한테 물어 봐서 임금의 경우 어떻게 계산하면 되겠는지 알아 보니 다음과 같은 내용을 알려 줬다. 아래는 일반적인 SI 업체에서 임금 계산할때 사용하는 방법이며, 소프트웨어 진흥원에서 공식적으로 사용할 수 있도록 한 방법이다. 물론 아래에서 누가 초급, 중급, .. 인지도 정의 되어 있을 거라고 생각한다. 나중에 관련 문서를 찾아 봐야 겠다.
중소 기업 같은 곳에서 프로그램 개발을 의뢰 받아서 하다 보면 항상 문제 되는게 제대로된 요구사항이 없고, 마지막에 끝날때 항상 금전적인 문제로 문제가 생기는 것 같다. 아직 몇 번 해본적 없지만, 계속 해서 똑같은 일을 겪게 될것 같아서 여기다 또 몇가지 적어 볼 생각이다.
1. 모든 소프트웨어 개발에 관한 책을 보면 항상 하는 얘기가 요구 사항을 제대로 받는게 프로그래밍의 시작이라고 되어 있다. 현실은 이것과는 다른 양상을 보여 준다. 현실적으로 일을 맡기는 회사들을 보면 자기들이 만들려고 하는걸 아주 추상적으로만 알고 있다. 그냥 "이런거 할 수 있는 프로그램 만들어 주세요" 라고 말하는게 전부이다. 그래서 만들다 보면 각각의 버튼이나 뭘 어떻게 해야 할지 모를때가 많이 생긴다. 이럴 경우 개발자가 편하게 만들면 나중에 검수때 무조건 문제점으로 나온다. 자기들은 이렇게 되야 한다고 생각하는데, 왜 이렇게 만들었는지... 그래서 담 부터 일을 하게 되면 무조건 이런 요구 사항이 어느 정도 확정되고 부터 개발 기간을 책정하는게 좋을것 같다는 생각을 한다. 그리고 정의되지 않은 요구 사항에 대해서는 아무 작동을 하지 않도록 만들고...
2. 일을 받을때 보통은 일을 주는 회사에서 제공해야 하는 것들이 있다. 서버라던지, 필요한 이미지 라던지... 이번에 일의 경우 셋탑 박스와 피씨에서 작동하는 서버가 있어야 했는데... 보통 이미지등은 제공하지 않으면 보통 프로그램 자체가 개발되지 않으므로 가능한 빨리 제공해 주는데, 셋탑 박스 라던지 피씨 서버등은 제대로 작동되지 않는 경우가 많다. 자기들이 그 클라이언트 프로그램 개발을 의뢰해 놓고 셋탑이나 서버의 기능이 제대로 안되는 경우가 더 많은것 같다. 이럴 경우도 아예 계약서에 명시하여 늦어지는 시간 만큼 개발 시간 지연은 당연한 것이고, 어느 시간 이상을 넘어서까지 기능이 제공되지 않는 경우 그 부분은 개발에서 빠진다는 것을 명시해야 할듯 하다. 이번에도 셋탑에서 제공되지 않는 기능이 있는데, 계약서에 그 부분이 들어 있다고 해서 검수가 끝나고 나서도 셋탑에 그 기능이 들어갈때까지 기다렸다가 일을 해줘야 한다고 한다. 담에 계약할 경우 절대적으로 전체 개발 기간의 일정 시간 이내(즉 1/3 정도)에 그 기능을 제공해 주지 않으면 아예 기능을 만들지 않고, 필요한 경우는 다시 돈을 받고 2차로 일을 하는 것으로 확정해야 한다. 계약서에 꼭 명시하자고 할 내용이다. 일이 끝나고 나서도 계속 끌려 다니는 것은 맞지 않다. 프로젝트식으로 일을 하는 사람은 시간이 곧 돈인데, 이렇게 쓸데 없는데 끌려 가는건 제대로 된 것이 아닌 것이다.
3. 검수시에 소스 코드는 절대 주지 말아야 한다. 검수때 소스 코드를 주고 나면 더 이상 내가 뭔가를 요구할 수가 없어 진다. 바이너리 파일로 원하는 모든 기능을 체크할 수 있으므로 굳이 소스 파일을 줄 필요가 없기 때문이다. 그리고 소스 파일은 내가 가질 수 있는 마지막 무기 이므로 돈의 입금이 확정된 다음에 주는 것이다. 그리고 바이너리 파일에 뭔가 장치를 해두는 것도 잊지 말아야 한다. 왜냐 하면 소스 없이 그 바이너리로 업체에서는 실제로 일을 할 수 있기 때문에, 한 시간을 기준으로 해서 프로그램에 창을 띄운다던지, 아니면 날짜로 프로텍트 거는 것도 괜찮은 방법이다. 정해진 기간 이후에는 프로그램을 사용하지 못하게 하는 것이다... 이런 부분을 꼭 처음 계약시에 명시해야 한다.
4. 유지 보수 기간을 3개월로 명시하는게 좋다. 그리고 유지 보수시에 만약 업체에서 소스 코드를 수정한 경우 그 소스에는 손을 대지 않고, 원래 업체에게 제공한 소스 코드를 수정하는 것으로 한다. 이 부분도 계약서에 명시해야 한다. 업체에서 코드를 수정한 후 뭔가 안된다고 하는 경우가 있을 수도 있기 때문에 유지 보수의 소스 코드는 제공한 소스 코드만 수정해서 주는 것이고, 업체에서 손을 댔으면 그 부분은 내가 하는 일과 상관없으므로 유지 보수 내용에 포함하지 않는 것이다. 당연히 계약서에 포함시켜야 하는 부분이다.
지금 만들고 있는 프로그램이 있는데, 윈도우용 프로그램으로 멀티 미디어 관련 프로그램이다. 개발 의뢰 받은 회사로부터 허락을 받지 못해 자세하게 어떤 프로그램인지 적지는 못하지만, 이번에 개발하면서 몇가지 느낀게 있어서 여기에 적어 볼까 한다
첫 번째로 배운 점은 시작할때 정말로 요구 사항을 잘 받아야 한다.
이번에 개발할때 제대로 요구 사항이 있는듯 해서 일을 시작했는데, 실제로는 거의 제대로된 요구 사항이 없었다. 중간에 전체적으로 디자인 한 부분이 정말 많이 바뀌어 버려서 힘들었다. 다음에 일을 하게 되면 가능한한 버튼들 까지 초기에 요구 사항을 받는게 정말 중요하다는 것을 알았다. 개발 프로그램의 기획의 중요성은 아무리 강조 해도 모자라지 않을것 같다.
두 번째로 다른 라이브러리나 소스 코드를 활용할때는 전체적으로 잘 판단해서 시작해야 한다는 점이다. 윈도우용 멀티미디어 개발에서 실제로 내가 맡은 일은 UI와 기존에 있는 라이브러리를 묶는 일인데, 문서화가 제대로 안되어 있고, 하나의 플랫폼만을 위한게 아니라서 코드 자체가 일단 보기가 그렇게 쉽게 되어 있지 않았다. 실제로 개발을 하다보니 여러 가지 문제가 생기기 시작했다. 멀티 미디어 관련 라이브러리가 실제로 플레이어의 코어인데, 이 코어와 같이 붙여서 개발할때는 무조건 Win32 즉 C만 사용해서 개발해야 한다는 단점이 있었다. 때문에 초기에 C++을 이용해서 초기 UI를 만들었는데, 그걸 순전히 C 구조로만 다시 만들어야 해서 개발을 새로 하는 것과 같은 상황이 벌어 진 것이다. 다른 라이브러리나 소스를 가져다 쓸때는 이런 점을 꼭 고려해야 한다는 교훈을 얻었다. 개발 환경부터 시작해서 그 라이브러리의 한계를 잘 결정해야 한다는 점이다.
세 번째로 여러 명이 같이 개발할때는 의사 소통을 할 수 있는 뭔가가 있어야 한다는 점이다. PDA쪽도 플레이어가 있고, 개발 의뢰한 회사에서 네트웍 부분에 꼭 사용하기를 원하는 라이브러리가 있었는데 이런 부분은 다른 개발자가 개발하고, 난 그 개발된 것 위에 연결해서 PC용 플레이어의 UI를 만드는 것이었다. 때문에 다른 개발자와의 의사 소통이 조금 문제가 되었었다. 다른 개발자가 만든 모듈을 이용해서 내가 개발하면 그쪽에서 받아서 필요하면 그 기능을 또 수정해 버리고 해서 내가 다시 고치면서 그쪽이 원하는 기능을 포함하는 것도 여러번 있었다. 때문에 다른 사람과 같이 개발할때는 뭔가 의사 소통하는 툴이 있어야 한다는 점이다.
네 번째로 개발할때 테스트 방식을 미리 지정하지 않은게 또 하나의 치명적인 문제점이었다. 새로운 기능을 추가하고 그 기능이 추가 되었는지 테스트하고 넘겨 주면 예전에 괜찮았던 부분이 문제가 생기고 했는데, 물론 내가 잘못한 부분도 있고 다른쪽에서 잘못해서 나온 것도 있었다. 하지만 PC용 플레이어의 개발은 나의 책임이므로 내가 잘못한것으로 생각된다. 그래서 미리 테스트 시나리오를 만들어서 다른 개발자들과 테스터와 함께 사용한다면 개발을 훨씬 효율적으로 할 수 있을 것이다.
다섯 번째로 이번에 개발 중간에 게시판을 만들었다. 일을 하다보면 중간 중간에 요구 사항이 바뀌거나 추가/삭제 되는 경우가 있다. 실제로 나는 일을 의뢰하는 회사하고는 직접적으로 얘기하는 경우가 거의 없다. 일종의 에이전시처럼 중간에서 이런 일을 해결해 주는 사람이 있는데, 회사와는 그 사람이 접촉해서 필요한 내용을 알려 주곤 한다. 근데 가끔 하다보면 그 전달이 서로간에 이상하게 될때가 있다. 나에게 전달을 했다는데, 나는 기억에 없고... 누구의 잘못을 따지는게 아니고 그런 놓치는 부분을 없게 하기 위해서 필요한 모든 내용을 한군데로 모으기 위해서 만들었다. 아직 게시판 형태가 좋을지 위키 시스템 형태가 좋을지는 좀 더 지켜봐야 할것 같다. 이번 개발에 게시판을 쓰고 있는데 일단 이번 개발을 끝내고 나서 게시판을 이용했을때의 장단점을 비교해봐야 겠다.
여섯 번째로 개발을 하면서 subversion을 이용하여 버전 관리를 하였다. 예전 회사에 있을때 프로젝트 하면서 subversion을 유용하게 잘 사용했는데, 이번에도 상당히 편하게 쓰고 있다. 좀 더 어드밴스한 기능을 쓰기 위해서는 공부를 하기도 해야 하지만, 아직까지는 그 기능까지는 쓸 필요는 없어서 생각만 하고 있는 중이다.
일곱 번째로 이번에 개발하면서 아쉬웠던 점은 지금 사용하고 있는 툴이 Visual Studio 2005 버전이다. 지금 다니고 있는 회사에서 정품을 사줘서 실제 정품을 사용하고 있는데, 이 툴의 사용법을 제대로 모르고 있다는게 많이 아쉬웠다. 툴을 예전에 VS 6.0 사용했던 것처럼 디버깅을 브레이크 포인트 걸고 하는 식으로만 썼는데, 훨씬 많은 기능이 있을듯 하다. 요번에 개발하면서 spy++ 라는 프로그램을 처음 써 봤는데, 생각보다 훨씬 유용한 프로그램이었다. 자신이 아니고 다른 프로그램을 선택하여서 그 프로그램에 posting되거나 sending 되는 모든 메시지를 보여 주는 프로그램으로 나중에 디버깅 하거나 멀티 미디어 라이브러리에서 UI로 보내는 메시지등을 테스트할때 정말 도움이 되었었다. 지금 생각해 보면 이 기능도 어느 정도 툴 안에 포함되어 있을것 같다. 1차 개발이 끝나면 툴에 대해서 좀 더 공부해야 할 필요성을 느꼈다.
지금은 1차 개발을 거의 끝나고 자체 테스트를 하고 있는 중이다. 프로그램이 장시간 플레이하면 문제가 생기는 경향이 있어서 약 2시간 짜리 동영상을 플레이 해서 문제가 없음을 알았고, 다른 PC에서는 4시간 짜리 동영상을 돌리고 있다. 2시간 이상되는 동영상을 찾기가 정말 힘들어서 동영상 두개를 붙여서 4시간 정도 되게 만들어서 사용하고 있다. 이 부분만 넘어 가면 1차 개발은 끝이 날것 같다.
이번 개발에서 윈도우의 리소스 부분에 대해서 정말 고생 많이 했다. 원체 윈도우쪽 프로그래밍을 많이 하지 않은 덕분에 이번에 개발하면서 정말 많이 배웠다. 특히나 리소스 부분은 단순히 책에 나와 있는 부분만 가지고는 실제 개발에서는 많은 문제점을 야기 시킬 수 있다는 점을 배운게 하나의 성과이다. 같이 개발하는 사람이 그쪽에 많은 경험이 있어서 마지막 테스팅등에는 정말 많은 도움이 됐다.
글
댓글을 달아 주세요
댓글 RSS 주소 : http://www.cipher.pe.kr/tt/cipher/rss/comment/40댓글 ATOM 주소 : http://www.cipher.pe.kr/tt/cipher/atom/comment/40