프로그램 프로젝트를 성공시키기 위해서

안녕하세요. 명월입니다.

 

 오늘 개발 현장에서 프로젝트 코디네이터와 아깐의 의견 충돌이 있어 그것에 대한 느낀 점을 정리해 볼까 합니다.

 우리가 흔히 프로그램 프로젝트의 실패라는 말은 자주합니다. 프로젝트 실패란 말은 프로그램을 못 만들었다는 의미가 아닙니다. 그것은 프로그램이 엔드 유저 또는 고객의 요구사항대로 만들어내지 못했거나 약속했던 기한 내에 프로그램이 완성되지 못했다는 의미입니다. 프로젝트가 실패되더라도 프로그램은 완성시켜야 합니다. 그렇지 않으면 배상금 물어줘야 합니다.

 그럼 프로젝트가 왜 실패하는 것일까 고민을 해 봤습니다.

내 경험으로 프로젝트의 실패 원인은 외부적인 요인 30%이고 자신의 요인이 70%이라고 생각합니다.

 

 먼저 외부적인 요인에서 가장 큰 이유가 말도 안 되는 일정 제시입니다. 이건 100% 외부적 요인이라고 할 수는 없는 것이 애초에 말도 안 되는 일정으로 시작하면 안 됩니다. 그러나 월급쟁이 개발자들은 현실적으로 이것을 조정하기가 힘들다. 특히 한국은 까라면 까는 문화가 있으니... 그러나 누구도 프로젝트를 실패하고 싶지 않기 때문에 안건을 제시하는 고객들도 자기들 생각에 어느 정도면 될 거 같다고 제시하는 경우가 많습니다. 그래서 잘 들어보면 틀린 말은 아닙니다. 가끔 이상한 사람들 빼고는 대부분 사람은  프로젝트를 성공 싶어 하지 일부러 실패하는 프로젝트를 하고 싶어 하진 않습니다. 그래서 들어보면 나름대로 합리적인 생각으로 제시합니다. 그러나 많은 엔드유저나 고객들은 프로그램 프로젝트 공정이나 개발 방법 등을 모르는 게 대부분입니다. 그래서인지 설계와 개발시간은 계산한 것 같은데 테스트에 대해서는 시간을 빼고 생각하는 경우가 많습니다. 이런 부분은 자신이 합리적으로 다시 계산해서 제시하면 일정이 조정되는 경우가 많습니다. 테스트나 기타 작업하는 데 시간을 제시하면 됩니다. 그럴 경우 이상한 사람이 아니고서야 합리적인 제안을 했을 때 대부분 수용합니다.

 그러나 애초에 자신이 공수계산과 일정 계산이 안 되거나 스케줄 설계가 안되면 불가능합니다. 그래서 이것이 100% 외부요인이라고 말하기 어려운 이유입니다.

 

 둘째는 잦은 사양 변경요청입니다. 한번은 이런 적도 있었습니다. 프로젝트를 받아서 일정계산하고 작업을 착수했는데 고객이 어떤 부분을 수정해달라고 요청해 왔습니다. 개발 중에 사양변경은 항상 있는 일이니 어렵지는 않습니다. 그런데 그 다음 날 그 부분을 다시 생각해봤는데 원래 것이 맞다고 수정요청이 왔습니다. 그래서 알았다고 했는데.. 다음 날 다시 같은 부분 수정이 왔습니다. 이런 식으로 한 부분 수정만 한 달 동안 한 적도 있습니다. 이렇게 되면 프로젝트를 진행할 수 없습니다. 그런데 이런 경우가 간혹 발생하는 것이 아니고 상당히 많습니다. 그래서 각 모듈을 독립적 개발을 해야 하고 폭포수 개발 공정보다는 애자일 공정을 선호하는 이유입니다. 이런 부분은 업무협조 간에 패널티를 설정해서 해결하는 경우도 있습니다. 패널티란 한번 수정협조에 개발 기간 일주일 연장이라던가 금액적인 부분이던가. 그러면 고객도 신중히 요청이 옵니다.

 

 여기까지가 외부적인 요인이고 제가 진짜 하고 싶은 이야기는 자신의 이유입니다.

 

 첫째, 프로젝트 공정 설계와 운용 경험부족입니다. 이는 많은 사람들이 어쩔 수 없다고 하는 경우가 많습니다. 그런데 내 경험으로 봤을 때는 어쩔 수 없는 것이 아니고 공부 부족인 경우가 대부분입니다. 주변에 개발자들 보면 10년 차 20년 차여도 경험이 거의 없는 사람이 있는가 하면 3년차만 되도 웬만한 프로젝트는 뚝딱 만드는 사람이 있습니다. 프로젝트라는 것은 꼭 많은 사람과 협업해야만 하는 것만은 아닙니다. 혼자서 필요한 프로그램을 만들어 낼 수도 있고 오픈 소스에 참여하는 방법도 있습니다. 아무리 사이즈가 작은 프로젝트라도 완성(성공, 실패 모두)하면 느끼는게 정말 많습니다. 데이터베이스 설계를 쓸데없이 복잡하게 했다던가. 프로그램 언어의 이해 부족이라던가 디자인 패턴 이해부족이라던가.. 이런 경험들이 쌓이면 분명 큰 프로젝트에서도 적용됩니다.

 

 둘째도 어떻게 보면 경험이 쌓이면 느끼는 부분이긴 한데 바로 개발 방식입니다. 여기서 이야기하는 개발 방식은 폭포수나 애자일 같은 프로젝트 공정이 아니고 자신이 개발하는 방식입니다. 프로젝트 공정 선택도 프로젝트의 성패에 영향이 없는 건 아니지만 프로젝트를 잘 이끄는 사람은 어떤 공정에 맡겨도 성공으로 이끕니다. 내가 이야기하는 개발하는 방식은 프로젝트를 어떻게 해야겠다는 계획에 가깝습니다. 실제로 많은 사람이 초반에는 엄청 적극적으로 하다가 나중에는 결과가 시시해지는 용두사미적인 프로젝트도 많습니다. 예를 들면 전체 개발이 1년이라고 할때 폭포수 같은 경우는 설계만 반년하고 애자일은 환경설정만 반년 합니다. 그리고 설계는 그렇게 화려한데 정착 작업은 후다닥으로 엉망인 경우가 많습니다. 후반부로 갈수록 시간 압박에 테스트도 제대로 되지 않는 경우가 많습니다. 개인 프로젝트나 오픈 소스의 경우는 설계만 하고 포기하는 경우도 많습니다. 내 경험으로는 이런 식으로 실패하는 경우를 정말 많이 봤습니다. 실제 초년생때는 나도 이렇게 실패를 많이 했습니다. 이게 왜 그럴까 생각해보면 처음에는 프로젝트 고민도 많이 하고, 하고 싶은 것이 많아 처음부터 엄청나게 디테일하게 작업합니다. 그러다 보면 전체사양을 잊어버리는 경우도 많고 눈으로 보기에도 진도가 나가지 않아 지쳐버립니다. 그러나 내 방식은 화면이면 화면, 내부 컨트롤이면 컨트롤을 정말 빠르게 만들어 냅니다. 아니 버그 등도 무시하고 일단 만들어냅니다. 빨리 하는 방식도 여러 번 해보면 요령이 생깁니다. 일단 빨리 만들고 나서 테스트와 리펙토링으로 완성도를 올리는 방식입니다. 1년 개발 기간이면, 설계 한 달 코딩 두 달 나머지는 테스트 리펙토링. 또 넣고 싶은 사양이 있으면 추가하면 됩니다. 이렇게 하다 보면 리펙토링시에 설계의 잘못된 점이 보이고 이것이 경험이 됩니다. 이런 방식을 해서 프로젝트 100% 성공 보장은 못 하지만 내 경우는 성공률이 꽤 높았습니다.

 

 셋째는 표준 개발 방식과 디자인패턴, 알고리즘 학습입니다. 앞에 이야기하는 빨리 만들고 반복적인 리펙토링을 이야기했습니다. 그럼 어떻게 빨리 만들까입니다.

 

표준 개발 방식은 변수 명명법. 함수 선언법. 주석 달기 등이 정의되어 있습니다. 그 뜻은 우리가 변수명을 어떻게 쓸까, 함수는 어떻게 만들까를 고민할 필요가 없습니다. 그냥 정해진 가이드로 만들기만 하면 됩니다.

 

또 클래스 선언하는 방식이나 메모리 관리도 디자인 패턴대로 만들면 순식간에 만듭니다. 경험으로 디자인 패턴이 적용 안 되는 업무를 아직 본적이 없습니다. 그 뜻은 대부분의 프로젝트는 적용된다는 의미입니다. 물론 디자인 패턴 적용이 프로젝트 운용에 옳다 나쁘다는 갑론을박이 많습니다. 하지만 개발 속도를 상당히 올린다는 데는 다들 이견이 없습니다.

 

다음은 알고리즘이다. 가장 많이 사용되는 알고리즘은 역시 list와 cache이지만, 그 외의 알고리즘도 업무 개발하는데 많은 도움을 줍니다. 끝없는 변수선언보다 map이나 list로 작성이 되면 그만큼 가독성도 좋고 개발이 빠릅니다. 나는 이런 학습도 매우 중요하게 봅니다. 왜냐하면 나는 내가 만든 소스도 두달만 지나도 잊어버립니다. 그런데 가독마저 되지 않는다고 하면 애초에 빠른 개발, 리펙토링이 되질 않습니다.

 여기까지 프로젝트를 성공으로 이끄는 방법을 이야기했습니다. 여기서 이야기하는 방법이 반드시 성공으로 이끄는 건 아니고 분명 사람마다 느끼는 경험차이가 있으므로 반드시 옳은 건 아닙니다. 그러나 내 경우는 항상 이런 생각과 목표로 개발을 했을 때 많은 성공을 이루어 냈습니다. 그래서 많은 개발자가 참고가 되었으면 합니다.