brunch

매거진 나에게 맞는 IT 직업 찾기

라이킷 18 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by OurStellar May 26. 2023

28. IT 프로젝트?

프로젝트 속성과 방법론

제법 해외 출장을 다니던 시절, 미국 국내선을 탔는데, 옆 좌석 사람과 이야기를 하게 되었다. 알고 보니 그는 호주 국가대표 경보 선수였다. 당시 경보가 걷는 경기라는 것 이외 아는 것도 없어 긴 대화를 할 수 없었는데, 내가 물어볼 수 있는 것은 이정도 밖에 없었다.

"그렇게 긴 거리를 걸어야 하는데, 매우 힘들 겠네요. 그렇게 오랜 시간 힘들게 걸으면서 무슨 생각을 하나요?"

그는 싱긋이 웃으면서 조용히 내 귓가에 대고 말했다.

"Finish"

그의 대답에 나도 같이 웃었다. 선수로서 일반인이 모르는 뭔가 다른, 고상한 이야기가 나올 줄 알았는데, 너무도 당연한, 그렇지만 누구나 고개를 끄덕이는 답을 했기 때문이었다.

필자도 컨설턴트 시절 프로젝트를 신물 나게 했다. 그것도 가장 힘든 프로젝트를 책임지는 프로젝트 관리자(PM)로서. 프로젝트 시작과 동시에 내가 꿈꾸었던 것도 그 선수처럼 "Finish"였다.

세상이 바뀌면서 프로젝트의 형태도 많이 달라졌고, 또 개발자 같은 프로젝트 구성원들의 일하는 방식도 바뀌었다. 그러나 프로젝트만이 갖는 고유의 속성은 변할 수 없다. 프로젝트라는 것이 워낙 다양하지만, 여기서는 전형적인 프로젝트의 형태를 갖춘 대형 SI사에 의한 대규모 프로젝트를 기반으로 접근하려 한다.

프로젝트란?

일부 업무에 한정되어 쓰던 '프로젝트'라는 용어도 일상 용어가 된 것 같다. 일시적인 일을 완성하는 모든 것에 프로젝트라는 말을 쓰고, 특별한 목적을 가진 일을 달성하는 것 같은 일에 있어 프로젝트 관리 방법을 적용하는 것이 보편화된 것 같다. 요즘 프로젝트가 아닌 '플젝'이라고 불리는 프로젝트가 무엇인지 살펴보자.

｜프로젝트(Project)｜

일정한 기간 안에 일정한 목적을 달성하기 위해 수행하는 업무의 묶음을 말한다. 하나의 프로젝트는 정해진 기간, 배정된 금액, 투입인력 등 일정한 제약조건 하에서 각종 요구사항(requirement)을 수행하는 방식으로 진행된다.(출처:위키백과)

프로젝트에는 반드시 돈과 시간이라는 제한이 있다. 주어진 돈으로 정해진 기간 내에 요구사항을 수행하여야 한다. 요구사항의 수행 결과 즉 산출물을 만들어 내야 한다. 앱 개발 프로젝트는 앱을 개발해서 서비스하도록 해야 하고, 차세대 뱅킹 시스템 구축 프로젝트는 새로운 뱅킹 시스템을 만들어야 한다.

그러면 정해진 돈과 시간 안에 요구사항을 수행하지 못하면 어떻게 될까? 그럴 땐 일이 복잡해진다. 어떻게 해결을 해야 할지 PM은 골머리를 싸매야 한다. 다 못했으니 먼저 시간을 늘려야 한다. 시간을 늘리면 개발자 투입 기간이 늘어나고 돈이 더 들어간다. 그 돈은 누가 대야 하나? 또 현업부서에서는 오픈 일정에 맞춰 마케팅을 하기로 했다면 모든 일정이 변경되어 또 돈이 든다. 그 돈은 누가 보상해야 하나? 정말 일이 복잡해진다. 이것에 대해 나중에 다시 한 번 더 다루기로 하자.

프로젝트 방법론

IT에서는 방법론(methodology)이라는 용어를 쓰는데, 일을 처리하기 위해 나름대로 증명된 과학적인 일처리 방식이라고 이해하면 될 것 같다. 프로젝트의 방법론이란 프로젝트를 수행하기 위한 체계적으로 정리한 방법이다.

IT에서는 방법론(methodology), 접근법(approach), 프레임워크(framework), 로드맵(roadmap) 등과 같은 문서나 방안을 많이 활용하는데, 이는 IT일의 특성이 대부분 기존의 것을 하는 것보다 새로운 기술이나 기법을 해야 하는 일이 많다 보니 이런 그 일을 처리하는 방법, 과정을 담은 것 참고문서를 중시하는 경향이 있다.

프로젝트 방법론은 프로젝트를 진행하는 방법으로, 프로젝트라는 것이 IT에서만 하는 것이 아닌 건설현장 같은 곳에서도 더 많이 활용되므로 프로젝트 방법론은 오랫동안 적용된 것이라 할 수 있다. 최근에는 많은 새로운 프로젝트 방법론이 활용되는 것이 약간 유행처럼 되고 있는데, 여기서는 가장 보편적인 두 가지의 방법론에 대해 간단하게 짚고 넘어가겠다.(프로젝트 관리 방법론에 대한 자세한 사항은 여러 전문 서적이 있으니 참고하면 된다.)

｜폭포수(Warterfall) 방법론｜

폭포수 방법론

프로젝트의 각 단계에서 한 단계가 완료되면 다음 단계로 실행하는 선형적이고 순차적인 방법론이다. 쉽게 말해 폭포 물이 내려와 위의 항아리를 채우고 넘쳐서 다음 아래 항아리를 채우는 것처럼, 앞 단계가 끝나고 나면 다음 단계로 넘어간다는 방법론이다.(이것이 뭔 방법론이여~ 당연한 거지~라는 생각이 들 것이다.)

보통 개발 프로젝트는,

요구사항 분석 => 설계 => 개발 => 테스트 => 이행 및 운

의 단계로 진행된다. 폭포수 방법론은 이러한 단계를 하나하나 완료해 나가는 방법이다. 요구사항 분석이 완료되면 설계를 하고 설계가 완료되면 개발하는 식으로 프로젝트를 진행하는 방법이다.

[장점]

프로젝트 시작부터 요구사항이 명확하고, 예산과 기간이 예상이 정확할 때 유리함

프로젝트의 위험 요소를 처음부터 예상할 수 있고, 완화할 시간이 충분함

프로젝트의 과정에서 변동이 적은 경우 유리함

[단점]

계획 단계에서 전체 시간과 비용을 초기에 정해야 함(불확실함)

프로젝트 요구사항이 중간에 발생하면 반영이 쉽지 않음

프로젝트의 기간이 길다면, 프로젝트 완료 후 산출물이 낡은 것이 될 가능성이 있음

폭포수 방법론은 요구사항이 명확하고 일정, 예산을 초기에 잘 예상할 수 있으면 좋지만, 프로젝트의 결과물을 받아 보기에는 프로젝트가 끝나야 하므로 장기간 프로젝트를 하다 보면 시점을 놓치기 쉽다. 은행의 뱅킹 차세대 구축 프로젝트는 적어도 1년 이상 소요되므로, 프로젝트 중에 많은 요구사항이 발생하고, 기술의 변화도 많아 오픈하고 나면 차세대 시스템이 차세대가 아닌 시스템이 되어 버린다는 우스개 소리도 있다.

이러한 단점을 극복하고자 한 방법론이,

｜애자일(Agilel) 방법론｜

애자일 방법론

영어 Agile은 '민첩한, 날렵한'이라는 뜻으로(IT에서는 이 말을 너무 좋아한다. 기업 환경의 변화에 민첩하게 대응한다는 식으로 자사 제품에 Agile단어를 쓰기 좋아한다.) 폭포수 방법론의 유연성 부족을 개선하기 위해 개발되었다.

폭포수 방법론이 초기에 요구사항을 정하고 시작하는 것과 달리 애자일은 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 살을 붙이면서 개발하는 과정을 반복하는 방식이다. 즉, 폭포수 방법론이 요구사항 분석=> 설계 => 개발 등의 과정을 완벽하게 순차적으로 단계를 진행하지만(폭포는 물을 거슬러 올라 못 감), 애자일은 요구사항 분석 => 설계 => 개발 => 이행의 과정을 여러 번 반복한다.(프로젝트에 따라 몇 번 반복할 것인지 결정한다.) 따라서 반복할 때마다 새로운 요구사항을 반영할 수 있고, 또 짧은 기간에 개발 결과를 볼 수 있다.

[장점]

프로젝트 초기에 요구사항을 명확하게 할 수 없을 때 유리(일단 시작하면서 요구사항을 구체화함)

프로젝트에 요구사항을 전달하는 현업의 깊은 참여로 현업이 원하는 결과를 만들 수 있음

프로젝트 결과를 짧은 시간에 볼 수 있고, 또 문제점을 빨리 확인할 수 있음

[단점]

예산과 시간의 제약으로 요구사항을 프로젝트 기간 내 달성하지 못할 가능성이 큼

현업 담당자의 참여가 중요한데, 적극적인 참여를 이끌어 내기가 쉽지 않음

계속적인 프로젝트의 과정이 반복되어 개발자를 비롯한 참여자의 피로도가 높음

전통적인 폭포수 방법론의 단점을 개선하기 위해 애자일 방법론 도입이 꾸준히 시도되었다. 최근 어느 정도 IT현장에 적응되는 것 같지만, 여전히 쉽지 않다. 프로젝트라는 것이 요구사항이 네모 모양 두부같은 정도로 명확하지는 않지만, 그래도 어느 정도 윤곽이 있어야 그에 맞는 예산과 기간이 정해지는데, 애자일은 그러지 못하다. 그러다 보니 어느 순간에 프로젝트를 끝내야 하는지, 요구사항이 완료되기도 전에 예산이 동이 나는 등 우왕좌왕할 수 있다.

필자도 애자일 도입 초기 시절 애자일 방법론으로 프로젝트를 했는데(고객이 애자일 방법론으로 프로젝트를 해달라고 했음), 당시 방법론에 대해 SI나 고객이나 다 잘 알지 못한 상태라 겨우 흉내만 냈던 것 같다.(아마 아직도 현장에서는 둘이 결합된 형태로 하지 않을까 싶다.)

애자일이 이론적으로는 좋으나 현실적으로 기업은 어떤 사업을 하기 위해 연초에 예산이 잡혀 있기 때문에 무한정, 또는 미확정 상태로 프로젝트를 추진하기 힘들다. 이런 이유로 모든 것이 미확정인 애자일은 출발부터 쉽지가 않다. 대부분의 기업은 예산 집행이 확정되지 않으면 프로젝트 자체를 추진할 수 없다.

이것 말고도 애자일은 계속적인 과정을 반복하다 보니 개발자의 노동 강도가 폭포수보다 훨씬 높고, 현업의 참여가 절대적인데 현실적으로 현업담당자가 자기 일을 제쳐두고 프로젝트에 올인하기도 힘들다. 애자일에는 더 유능한 개발자가 필요하다. 그런 유능한 개발자 확보도 쉽지 않고, 행여 확보한 개발자도 힘들어 그만둔다든지, 현업은 자기 일이 바빠 프로젝트를 내 몰라라 한다면, 프로젝트는 망가지기 십상이다.

(너무 애자일에 대해 비관적으로 말한 것 같다. 최근 애자일 프로젝트를 잘하고 있는 분이 있다면 답글 바란다.^^)

*애자일 방법론 내에 최근 인기 있는 칸반, 린, 스크럼 등의 방법론이 있다. 관심이 있다면 참고 서적을 찾아보자.