"지금 발표하고 있는 내용이 N사와 같은 곳에서만 가능하지 않을까요. SI 프로젝트에서는 힘들다고 생각하는데요. 어떻게 생각하시는지요?".
이와 같은 질문을 받고 나 또한 확신에 찬 답변을 하지 못했다.
"지금 세미나를 하는 것처럼 조금씩 변화시켜 나간다면 언젠가는 할 수 있지 않을까요? 작은 변화이지만 지금부터 만들어 나갔으면 좋겠습니다. 여러분 개개인이 변화하려는 노력을 보여주시면 좋을 것 같습니다."
정 확하게 기억이 나지 않지만 이와 같이 답변을 했던 것으로 기억한다. 나 또한 SI 프로젝트에서 애자일 프로세스를 적용하고 지속적 통합툴(CI)을 사용해본 경험이 없었기 때문이다. 현재 내가 일하고 있는 곳은 계약 관계에 의해서 프로젝트를 진행하는 것이 아니라 프로젝트에 참여하는 모든 구성원들이 같은 회사 사람이기 때문에 개발 프로세스를 선택하거나 개발 환경을 세팅하는 부분에 있어서는 자유로운 부분이 있다. 물론 그렇다고 완전히 자유로운 것도 아니다. 조직이 대규모화되면서 점차 정해진 프로세스에 따라 진행해야하는 부분도 많다. 하지만 계약 관계에 있는 SI 프로젝트보다는 새로운 시도를 해볼 수 있는 환경이 아직까지는 남아 있는 것이 사실이다.(개인적인 생각으로 몇년 이내에 이러한 자유조차 없어질 가능성도 있다.)
세미나가 끝나고 한 동안 다른 업무에 치이면서 잊고 지냈다. 그러던 중 "린 소프트웨어 개발:애자일 실천 도구 22가지 - 애자일 시리즈 003" 책을 다시 읽으면서 위 질문에 대한 해답을 어렴풋하게나마 찾을 수 있었다. 내가 직접 경험한 내용은 아니지만 이 책을 쓴 필자들을 신뢰하고 있기 때문에 충분히 소개할만하다고 생각한다.
SI 성으로 진행하는 국내 대부분의 프로젝트와 포털, 솔루션 개발 업체의 가장 큰 차이점은 계약 관계를 맺고 있느냐 그렇지 않느냐의 차이에 달려 있다. 포털이나 솔루션 개발 업체는 계약관계없이 프로젝트를 진행하는 경우가 대부분이기 때문에 프로젝트에 가장 적합하다고 판단되는 개발 프로세스와 개발 환경을 만들어 프로젝트를 진행할 수 있다. 특히 애자일 프로세스가 가능한 이유는 우선순위에 따라 개발을 진행하는 것이 가능하며, 우선 순위가 낮은 경우에는 다음 버전으로 미룰 수 있는 타협점이 있다는 것이다.
물 론 SI 프로젝트 또한 이 같은 타협점을 찾는 것이 가능하지만 계약관계에 있기 때문에 힘든 것이 사실이다. 특히 국내 소프트웨어 개발 환경에서는 갑의 한마디로 인해 무수히 많은 부분이 한순간에 뒤바뀌어 버릴 수 있다는 것이다. 불합리한 부분이 있음에도 불구하고 주종관계에 있기 때문에 을,병 입장에서는 거절하기 힘든 것이 사실이다. 국내에서 진행하는 많은 SI 프로젝트들이 성공이라는 이름으로 포장을 하고 있지만 뚜껑을 열어보면 80~90% 이상이 실패한 프로젝트일 것이라 생각한다. 물론 근거 자료를 제시하라고 한다면 제시할 근거는 없다. 어디에도 실패했다고 이야기하는 프로젝트를 본적이 없기 때문이다. 그러나 내가 참여했던 많은 프로젝트들이 성공했다고 포장은 했지만 실상은 실패했다고 생각하기 때문이다. 갑과 을이 서로간의 책임을 지지 않기 위하여 성공이라는 이름으로 포장하기 때문에 어쩔 수 없이 발생할 수 밖에 없는 상황이라고 생각한다.
어차피 성공이라는 이름으로 포장을 하지만 프로젝트 오픈후에 무수히 많은 밤을 지세우면서 고생하는 개발자들을 생각하면 마음이 아프다. 또한 1차로 끝나지 않고 2차, 3차, 4차로 이어지는 Never Ending 프로젝트들 또한 발생하고 있는 것이 사실이다.
계약 직 개발자로서 지내던 시간이 생각나 잠시 삼천포로 빠졌다. 다시 본론으로 들어가서 SI 프로젝트에서 애자일 프로세스를 적용하기 위하여 필요한 부분은 현재의 계약 방식을 바꿔야 한다는 것이다. 지금은 프로젝트의 요구사항도 분석하지 않은 상태에서 계약이 이루어지는 경우가 대부분이다. 그러나 이런 상태에서 어떻게 제안을 하고 계약을 맺을 수 있겠는가? 이와 같이 계약이 이루어질 경우 갑은 정해진 기간과 금액 내에서 최대한 많은 기능을 요구할 것이 뻔하며, 을은 갑의 요구사항에 최대한 방어하면서 더 빠른 기간내에 프로젝트를 완료해야 자신의 이익을 증가시킬 수 있는 것은 명백한 사실이다. 이와 같은 상황이기 때문에 프로젝트 PM 능력이 변경 가능성을 최대한 방어하고 고객의 요구사항을 최대한 잘라버릴 수 있는 능력으로 판단되는 경우가 대부분이다. 물론 개발자들을 얼마나 늦게까지 퇴근시키지 않고 최대한 빨아 먹을 수 있을때까지 최대한 빨아 먹을 수 있는 것을 능력으로 생각하는 몰지각한 PM들도 많이 있다. 그런 PM들에게는 엿이나 먹고 떨어지라고 한마디 하고 싶다.
린 소프트웨어 개발 책의 242~264페이지까지 이 책의 마지막 실천 도구인 22번째 계약에 관련한 내용이 나온다. 이 책에서는 계약의 종류를 고정 가격 계약(현재 국내에서 가장 많이 이루어지는 계약 형태), 시간 자재 계약, 단계적 계약, 목표 비용 계약, 목표 일정 계약, 이익 공유 계약으로 분류하고 있다. 이 책을 두번째 읽고 있지만 이렇게 많은 계약의 종류가 있는지 처음 알았다. 사실 첫번째 책을 읽을 때는 계약이 나와 관계 없는 일이라 생각하고 무시하고 넘어갔던 것 같다. 하지만 두번째 읽으면서 세미나 때의 질문에 대한 해답이라는 생각이 들면서 더 관심을 가지면서 읽을 수 있었다.(질문을 주신분께 개인적으로 감사의 말을..)
이 책에서는 애자일 프로세스에서 사용할 수 있는 계약 형태를 다음과 같이 보고 있다.
- 시간 자재 계약은 동시 개발 방법을 쓰며, 가장 우선 순위가 높은 기능을 먼저 개발하고 동작하는 통합 코드를 각 반복 주기에서 전달하여 고객이 범위를 제한함으로써 비용을 쉽게 조정할 수 있게 하는 방법이다.
- 단계적 계약은 주계약을 이용하여 각 반복주기에서 릴리스하게 한다. 동시 개발에서 중점을 두는 것처럼 각 단계에서 높은 우선순위 기능을 먼저 개발하고 동작하는 통합 코드를 각 반복 주기에서 전달하는 방법이다.
- 목표 비용 계약은 양측의 일선 작업자에게 목표 비용을 맞추는 선에서 문제에 대한 해결책을 찾는 데 서로 협력할 수 있는 권한을 부여하고, 비용 안에서 목표를 달성하기 위해 범위를 제한할 자유를 부여하는 것이 기본 메커니즘인 방법이다.
- 이익 공유 계약은 시간이 지남에 따라 상호 이익을 위해서 양측이 하는 일을 수정할 수 있다는 가정 하에 이루어진다.
위 네가지 방법 중에서는 이익 공유 계약이 갑과 을 모두의 이익을 보장할 수 있으며, 프로젝트를 성공으로 이끌 수 있는 것으로 소개하고 있다. 물론 프로젝트의 성격에 따라 달라질 수도 있겠지만서도..위 네가지 계약 형태의 공통점은 모두 범위를 상세하게 결정하지 않은 상태로 계약을 맺는다는 것이다. 이는 돈에 대한 결정을 최대한 늦추는 형태를 가지는 것이다.
국내에서 위와 같은 형태의 계약 방식이 가능할까? 물론 선도적인 기업들은 위와 같은 형태의 계약을 통해서 높은 가치를 발휘하는 소프트웨어를 만들어낼 것이다. 그러나 단기적인 이익에만 집착하는 국내의 대다수 회사들은 꿈도 꾸지 못할 계약 방식일 것이다. 이미 이와 유사한 계약 형태를 한 경험이 있거나 하고 있다면 이 글의 트랙백을 통하여 자랑스럽게 소개하기 바란다. 아마도 국내의 좋은 개발자들이 해당 프로젝트에 지원하지 않을까 생각한다. 현재의 하청 구조의 프로젝트 진행 방식에서는 더더욱 힘든 계약 형태이며, 을에 해당하는 대형 SI(S사, L사, C사 등등) 업체들은 이런 형태의 계약을 하고 싶은 욕심 또한 없는 듯 싶다. 대형 SI 업체들이 그런 변화를 원했다면 국내 개발자들에게도 많은 혜택이 있었을 것으로 생각하나 온라인 상의 어느 곳을 찾아봐도 위와 유사한 계약 사례를 찾아볼 수 없다는 것이 안타깝다.
갑 또한 변화할 필요가 있다. 지금까지의 계약 형태인 고정 가격 계약으로 진행한 프로젝트들에 만족하는가? 아마 대부분 만족하지 못할 것이다. 만족하지 못하는 것은 문제가 있는 형태로 계약이 맺어졌기 때문이다. 자신들이 진정 원하는 소프트웨어를 만들고 싶다면 갑이 나서서 다른 형태의 계약을 하는 것도 좋은 선택이 될 것이다. 그런 변화의 자세없이 기존의 관행을 반복한다면 영원히 만족하는 소프트웨어를 볼 수 없을지도 모른다. 현재 자리를 좀 더 오래 지키고 싶다면 기존의 계약 형태를 바꾸기 위하여 노력해보라. 좋은 소프트웨어 개발을 통한 회사의 효율성 증대는 회사내에서 자신의 생명을 연장시켜 줄 것이다. 지금까지의 관행을 실천하기는 쉬울 것이다. 그러나 회사내에서 그저 그런 사원이 될 것이며, 그저 그런 회사로 남을 수 밖에 없을 것이다. 개떡 같은 소프트웨어를 만들고 싶지 않다면 갑 너 자신부터 변화하는 모습을 보여라.(오해할지 모르지만 현재 나 또한 갑이다. 물론 계약관계를 맺는 경우는 거의 없지만..)
개발 자들이 생각할 부분은 고정 가격 계약으로 맺어진 프로젝트에 섣부르게 애자일 프로세스를 적용하지 마라. 괜시리 적용했다가 모든 책임을 혼자 뒤집어 쓸수도 있다. 개발 환경을 자동화하는 부분에 있어서는 적극적으로 찬성하지만 애자일 프로세스의 적용에서는 다소 소극적인 입장을 취하고 싶다. 개발자들이 피해보는 상황은 만들고 싶지 않기 때문이다. 애자일 프로세스를 적용하고 싶지만 적용하지 못하는 것을 자신의 능력 부족 탓으로 돌리지는 말았으면 좋겠다. 개떡 같은 갑과 개떡 같은 을..그리고 개떡 같은 시대에 태어났기 때문에 겪는 문제이거니 생각하면 좋을거 같다. 하지만 그런 속에서도 지속적으로 변화를 만들어가고자 한다면 조금씩 변화의 모습은 나타나지 않을까? 개발자들이 언젠가는 관리자가 될 것이며, PM이 될 것이며, 갑이 될 수도 있기 때문이다.
개 떡 같은 환경을 탓하는 것도 좋지만 문제에 봉착했을 때 해결하려고 하지 않은 개떡 같은 우리들의 자세 또한 비판해 보기 바란다. 다른 사람들이 변화를 만들어주기 바라기 전에 자기 자신이 변화를 만들어가는 사람들이 많아졌으면 하는 바람이다. 그럼 나는 뭐하고 있냐고? 나 또한 개떡같은 내 자신을 비판하면서 좀 더 적극적으로 변화를 만들어 가려고 노력하고 있다.
PS. 언제나 갑이 될 수는 없을진데, 언제인가는 병이 될 수도 있을진데..오늘 갑과 을을 너무 씹었다. 아무래도 내가 갑의 자리에서 물러날 때는 이 글을 살포시 삭제해야 될까? 이런 글 하나 때문에 나와 같이 일하지 않는다면 나 또한 같이 일하고 싶지 않다. 분명 그네들은 개떡 같은게 아니라 개똥같이 쪼잔한 성격의 소유자들일 것이 분명하기 때문에..
[출처] SI 프로젝트에서도 애자일 프로세스는 가능한가?|작성자 마검린
'java' 카테고리의 다른 글
| Java POI 예제소스 (0) | 2008.08.26 |
|---|---|
| jdbc 1.0 ~ 3.0 (0) | 2008.08.05 |
| HTTPClient 3.0 (0) | 2008.07.25 |
| URLConnection 와 HTTPClient (0) | 2008.07.25 |
| javac 옵션 (0) | 2008.07.09 |
invalid-file