brunch

You can make anything
by writing

C.S.Lewis

by Pearl Mar 10. 2019

사람 잡는 애자일

연구인가 프로젝트인가

시스템 구축 프로젝트를 하다 보면 의례히 초기 계획했던 기능이나 범위가 변경되고 늘어나기 마련이다. 대부분의 고객들은 본인들이 만들고자 하는 시스템의 정확한 기능을 정의할 수 없다. 미리 화면 설계를 다 해놓지 않는 한 설계하는 과정에서 스스로 학습에 의해 또는 외부의 압력에 의해 초기 계획했던 시스템의 목적이 달라지기도 하고, 방향은 맞는데 기능이나 연동 범위가 바뀐다.

그러나 대부분의 시스템 구축 사업은 분석-> 설계-> 개발-> 테스트의 폭포수 방법론에 의해 진행된다. 개발단계에서 새로운 기능이 요구되면 어떻게 되는가? 폭포수 방법론은 이전 단계로 회귀할 수 없다. 이미 떨어진 물을 어떻게 위로 올리는가? 그래서 방법론 이름이 폭포수 방법론이다. 이런 프로세스로 프로젝트를 수행하다 보니 일단 프로젝트는 끝내 놓고 다시 고도화 프로젝트를 진행하는 방식으로 시스템을 보완한다.

요즘은 비즈니스 업무 변화가 빠르기 때문에 IT 시스템도 Agility가 매우 중요한 가치로 대두되고 있다. 그래서인지 조금 부족하더라도 우선 비즈니스 요구에 빠르게 대응하고 사용자의 피드백을 받아서 지속적인 반복으로 시스템을 개선해나가는 애자일 방법론이 주목받고 있다.

사용자와 개발자의 긴밀한 소통과 지속적인 반복으로 시스템의 완성도를 높인다. 얼마나 좋은 개념인가. 그러나 애자일 방법론에 대한 이해가 높지 않은 고객이 일반 시스템 구축 프로젝트에 이런 방법론을 적용하게 되면 어떻게 될까?

고객은 프로젝트를 진행하면서 스스로 학습에 의해 점점 더 높은 요구사항을 낼 수 있게 되는데, 빠르게 개발된 결과물을 보면서 더 좋은 요구사항을 내고, 다시 시스템을 개선하고 확인하고 더 좋은 요구사항을 낼 수 있다니 얼마나 좋은가. 사용자가 개발자가 같은 회사이고, 사내 연구 프로젝트라면 적합할 수 있으나 일반 외주 시스템 구축 프로젝트에 적용하게 되면 문제가 될 수 있다. 외주를 주는 시스템 구축 프로젝트는 간단한 기능을 가진 단위 모듈이 아니다. 간단한 시스템이라면 내부 개발자들이 구축하겠지만 그게 아니니까 외주를 준거다. 시스템 복잡도가 높을 수밖에 없고 시스템 파트 간의 영향도가 높아서 기능 하나가 추가되면 기능만 추가되는 게 아니라 다른 기능이 안 돌아갈 수도 있고, 또 다른 모듈을 수정해야 할 수도 있다. 이렇게 되면 개발자는 개발이 끝난 소스를 다시 열어 수정하고, 또 그것에 영향받는 다른 소스를 수정해야 한다. 1차에 10개 요구사항에 대한 시스템을 개발하고 2차에서 3개 요구사항에 대한 기능을 추가 개발한다고 할 때 실제 개발물량은 3개가 아니라 8개가 될 수 있다.

왜 Component 기반으로 독립성을 유지해서 개발하지 않았냐고?

모든 기능 설계가 되지 않은 상태에서 어떤 게 독립적으로 수행해야 할지 100% 알 수 있기란 매우 힘들다. 초기 10개의 요구사항을 기반으로 최적화된 시스템에 3개의 기능을 추가할 때 기존 소스에 영향을 미치지 않을 수 없다. 그 영향이 10% 될지, 80%가 될지는 모르는 거다.

게다가 새로운 개발 언어로 개발하라고 하면? 개발자 스스로 학습이 되기 때문에 초기 개발 소스를 지속적으로 리팩터링 하게 된다. 하루라도 빨리 리팩터링을 해놔야 재작업을 최소화할 수 있기 때문이다.

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

프로젝트를 해왔던 개발자는 애자일 방법론을 기반으로 일을 할 수 있을까? 못하거나, 매우 어렵다. 개발자들도 성향별로 분류되는데 새로운 기술을 탐색하고 적용해보는 걸 좋아하는 연구 스타일이 있고 프로젝트처럼 끝이 있는 일을 하면서 성취감을 느끼는 스타일이 있다. 프로젝트처럼 정해진 기간 내에 일을 하는 것이 부담스러운 사람은 보통 시스템 운영을 맡게 된다. 유지보수 일을 하면서 계획적인 삶을 살길 원하는 스타일이다.

새로운 언어로 신 기술을 적용하여 기업 내 표준 개발 프레임웍을 만들어 내는 것을 목표로 하는 프로젝트에는 어떤 방법론이 적합한가? 시행착오가 많을 수밖에 없고, 전체 그림이 없어 지속적으로 개선해 나가는 애자일 방법론 적용이 적합하다. 그러나 만약 외주 프로젝트로 발주할 경우 프로젝트에 적합한 개발자들이 대거 투입되어 오로지 프로젝트 종료일을 향해 질주하려고 할 것이다.

계속 바뀌어 가는 요구사항은 의욕을 떨어뜨리고, 계속 소스를 수정해야 하는 반복 작업에 지친 프로젝트 개발자들은 이렇게 외칠 것이다.

아이고~ 애자일이 사람 잡네!

keyword