2018.04.03

애자일 방법론의 어두운 비밀, "IT에서는 거의 사용할 일 없다"

Bob Lewis | CIO
애자일(Agile)은 이제 지나간 옛 노래 정도로 생각하는 사람들도 있을 것이다. 앞서가는 기업들은 모두 데브옵스로 옮겨간 지 오래라고 말이다. 하지만 대다수의 애플리케이션 팀은 애자일 방법론을 도입한 적이 없을뿐더러, 애초에 도입할 수 없다고 생각하고 있다.


Credit: Getty Images Bank

이것이 의외라고 생각할 수도 있지만, 애플리케이션 팀의 업무를 자세히 살펴보면 이해 못 할 것도 아니다. 이들 팀의 목표와 애자일 방법론이 달성할 수 있는 결과 사이에는 공통 부분이 거의 없기 때문이다.

애자일, 그 가운데서도 특히 많은 IT 매니저가 애자일과 동의어라고 생각하는 스크럼(Scrum)은 IT와는 거의 관계없는 새로운 애플리케이션 개발이라는 측면에서 강점을 가지고 있다.

회사 웹사이트와 모바일 앱을 제외하면, IT 부서의 핵심 원칙은 "구매는 할 수 있을 때, 제작은 해야 할 때" 한다는 것이다. 때문에 기업 IT는 새로운 기능의 90% 가까이를 상용 제품(Commercial Off-The-shelf Software, COTS)나 SaaS(Software as a Service) 형태로 허용하고 있으며 전체의 10%만이 인하우스로 개발된 소프트웨어다.

그런데 스크럼, 칸반(Kanban), 린 소프트웨어 개발(Lean Software Development) 등 대부분 애자일 방법론은 이 10%를 겨냥하고 있다는 게 문제다. 게다가 대부분의 경우 개발자는 업무 시간의 70% 이상을 이미 제작 중에 있는 애플리케이션의 유지, 강화에 사용하고 있기 때문에 새로운 애플리케이션을 도입할 시간이 많지 않다.

계산을 해 보자. 애자일은 개발자가 할애할 수 있는 그 30%의 시간 중에서도 10%의 경우에만 유효하다. 즉, IT 애플리케이션 팀 업무 중에 애자일이 유효하게 사용될 수 있는 경우는 3%에 불과하다는 얘기다.

물론 기업에 따라 구체적인 숫자는 조금씩 다를 수도 있지만 어떤 기업이든, 애자일 방법론이 활용되는 비율은 그다지 높지 않을 것이다. 하지만 이런 현실을 바꿀 수 있는 방법도 없지는 않다.

유지, 강화 업무에 애자일 적용하기
쉬운 것부터 해결해 보자. IT 부서 업무의 상당부분을 차지하는 유지, 보수, 강화 업무에 애자일 방법론을 적용할 수는 없을까.

굳이 줄줄이 이어지는 유지, 보수, 강화 업무를 살펴보지 않아도, 이것이 애자일 백로그와 얼마나 닮아 있는지는 어렵지 않게 알 수 있다. 여기에 제품 소유자(Product Owner, PO)를 더하고, 리퀘스트를 사용자 스토리(user story)로 포장해 보자. 그리고 칸반을 적용한다. PO가 우선 순위를 정하고, 개발자가 사용자 스토리를 끝낼 때마다 백로그에서 다음 사용자 스토리를 선택해 작업을 이어간다. 매우 간단할뿐더러 효율적이며, 간접 비용도 거의 들지 않는다.

애자일 COTS
COTS 이행에 애자일 방법론을 적용하는 것은 앞선 경우만큼 간단하지는 않다. 하지만 이는 모두 예상했던 것이다. 대규모 시스템을 도입, 이행하는 것이 일상적인 애플리케이션 유지, 강화 작업과 같을 수는 없기 때문이다.

하지만 COTS에도 애자일 방법론을 적용할 수 없는 건 아니다. 단지 두 가지 중요 포인트를 놓치지만 않으면 된다.

첫째로, 온 프레미스이든 SaaS를 통해서이든 COTS 이행은 소프트웨어 개발과 한두 가지 측면에서 다르다는 점을 인식해야 한다. 이런 근본적 차이점으로 인해 스크럼이나 칸반 등의 애자일 방법론은 적합하지 않다.

두 번째는 이미 앞서 한번 언급한 것인데, 세상에는 스크럼과 칸반 이외에도 다양한 애자일 방법론이 있다.

개발의 시작은 데이터 구조 설계, 앱 개발 대 COTS
IT 팀에서 소프트웨어를 개발할 때는 그 기업 전체가 이 소프트웨어를 어디에 어떻게 사용하게 될 것인가를 생각해 봐야 한다. 그리고 이에 대한 대답을 얻었다고 해도, 곧바로 소프트웨어 개발에 착수하게 되는 것은 아니다.

우선은 데이터 구조를 설계해야 한다. 애플리케이션 개발은 그 다음이다. 물론, 기존의 데이터베이스가 새로운 애플리케이션의 니즈를 충족할 수 있는 상황이라면 데이터 구조를 따로 설계할 필요가 없다.

"구매는 할 수 있을 때, 제작은 해야 할 때" 원칙은 근본적으로 다르다. IT가 COTS/SaaS 패키지를 이행할 때 기존의 데이터베이스는 도움이 아니라 방해가 된다. 각 패키지에는 자체적인 데이터베이스가 포함되어 있으며 소프트웨어 벤더가 데이터베이스를 설계할 때는 이미 기업들이 기존에 가지고 있는 데이터베이스를 고려하지는 않기 때문이다. 또한 다른 개발업체들이 설계해 둔 데이터베이스를 고려할 이유도 없다.

따라서 IT가 COTS 패키지를 이행하려면 새로운 애플리케이션이 관리하는 동일한 데이터를 저장하고 있는 모든 기존 데이터베이스를 찾아내야 하며 중복되는 데이터들 간 동기화를 어떻게 하면 좋을지 방법을 찾아야 한다. 데이터 관리 측면에서도, 내부적 개발과 패키지 이행은 완전히 다른 문제다.

소프트웨어의 용도 규정
일단 데이터 구조가 확립됐으면, 이제 소프트웨어 용도를 규정해야 할 차례다. 대부분 애자일 방법론들은 이를 위해 '사용자 스토리'를 사용한다. 사용자 스토리란 보통 다음과 같은 형식을 취한다.

"ㅇㅇㅇ 사용자로서, ㅇㅇㅇ를 위해/ㅇㅇㅇ를 이유로 ㅇㅇㅇ의 목표를 달성하고자 한다(As a <type of user> I want <a goal> so that <good reason>)."

예를 들어, "텔레마케터로서, 다음에 판매할 제품에 관심이 있을 만한 고객에게만 전화를 걸 수 있도록 고객 가정에 대한 정보를 저장하고자 한다"와 같은 식이다.

물론 이 예시는 어디까지나 예시일 뿐이다. 하지만 그게 문제는 아니다. 진짜 문제는 따로 있다. CRM 시스템 이행 시 이런 부분에 있어 고집을 부린다면 모든 사람의 시간을 낭비하고 비즈니스 매니저를 아주 성가시게 만들게 될 뿐이다. 모든 유형의 '고객'에 대한 정보를 저장하지 않는 CRM 패키지를 실행한다면 CRM 패키지를 실행하는 것이라고 말할 수 없다.

COTS나 SaaS 소프트웨어를 실행할 때 흔히 하는 이야기가, 이것저것 더하지 않고 '기본' 소프트웨어를 실행하거나, 아니면 기업의 특수한 니즈와 관행이 맞춰 개별화된 소프트웨어를 실행해야 한다는 것이다. 하지만 이 둘을 대안으로 놓고 이야기하는 것은 아주 바보같은 행동이다.

COTS 소프트웨어는 많은 경우 해당 소프트웨어를 사용하게 될 비즈니스 부문이 현재 사용하고 있는 버전보다 여러 부분에서 훨씬 뛰어나다. 그러나 반드시 그렇지만은 않은 경우도 많다.

IT 부서는 '내부 고객'들을 만족시켜야 한다며 커스터마이징을 옹호하는 이들은 그럴듯해 보이는 새로운 소프트웨어 도입에 예산을 지출해야 한다고 주장한다. 그렇게 해야 지금까지 해 오던 것처럼 비즈니스를 이끌어 갈 수 있다는 것이다. 이 주장은 비용은 많이 들고, 일은 지금까지 해 왔던 것과 똑같이 해야 한다는 것이다.

또 설령 비즈니스 프로세스가 전혀 다르지 않다는 전제 하에, 아니 다르지 않아야 한다는 전제 하에 기본적인 소프트웨어를 있는 그대로 사용한다고 해 보자.
특정 분야에서 업계 최고를 자랑하는 기업의 경우, 이런 기본적인 소프트웨어 도입을 강제하는 것은 곧 비즈니스의 도태를 전략으로 내세우는 것과 같다.

따라서 '기본 소프트웨어' 대 '개별화된 소프트웨어'라는 대결 구도 자체가 잘못된 것이다. 애초에 이런 프레임을 전제로 의사결정을 해서는 된다.

2단계 COTS
IT가 아닌 기업에서 COTS를 통한 비즈니스 변화를 추구할 때는 보통 두 단계에 걸쳐 변화가 일어난다. 소프트웨어의 강화와 비즈니스 최적화가 그것이다.

첫 번째 단계인 소프트웨어 강화는 잘 알려지지 않은 애자일 방법론인 컨퍼런스 룸 파일럿(Conference Room Pilot, CRP) 방법론을 이용해 해결할 수 있다. CRP는 다음과 같다.

우선 IT가 마스터 데이터를 새로운 패키지의 데이터베이스에 로드한다. 여기서 마스터 데이터는 고객 데이터, 제품 데이터 등을 말한다. 그러면 프로젝트 매니저가 화이트보드와 큰 모니터 등이 구비된 큰 컨퍼런스 룸을 빌린다. 그리고 나서야 비로소 새로운 패키지로 비즈니스 트랜잭션을 처리래 소프트웨어 강화가 이뤄질 수 있게 된다.

이런 비즈니스 트랜잭션은 주의깊게 계획된 테스트 플랜의 결과일 수도 있고, 아니면 그저 지난 달, 혹은 그 전에 프로세스된 것일 수도 있다. 어느 쪽이건 상관은 없다.

그런 후, 다수의 비즈니스 사용자와 애플리케이션 전문가를 불러 컨퍼런스 룸 안에 모아놓고 종종 배가 고프지 않도록 피자와 음료도 시켜준다. 그러면 컨퍼런스 룸 안에서는 어떤 일이 일어날까. 일단 비즈니스 사용자가 트랜잭션을 들고 주어진 소프트웨어로 문제를 해결하려 하다가 포기한 후 전문가에게 이렇게 말 할 것이다.

"이 트랜잭션은 …와 같은 이유로 처리하기 어려울 것 같다"고 말이다. 그러면 개발자는 "…와 같은 이유" 부분을 처리하게 된다. 이 과정을 수 차례 반복하다 보면 트랜잭션 처리를 방해하는 요소들이 모두 제거 될 것이다. 그러면서 자연스럽게 2단계로 넘어가게 될 것이다.

1단계에서 2단계로의 전환은 대화 내용의 변화를 보면 알 수 있다. 1단계에서 비즈니스 사용자들은 트랜잭션을 프로세스할 수 없는 이유에 대해 주로 대화를 나누게 되지만, 2단계에서의 대화는 주로 "만약 소프트웨어가 …하게 된다면, 트랜잭션 프로세싱이 더 쉬워질 것 같다"가 될 것이다. 즉, 더 이상 소프트웨어 강화가 주제가 아니라 프로세스의 효율성 개선, 다시 말해 비즈니스 최적화가 주제가 되는 것이다.

참고로, 이 과정에서 개발자들은 수동적으로 명령을 받아 수행하는 방어적인 입장이 아니다. 어느 때든 자유롭게 "소프트웨어를 이렇게 만들면 상당히 복잡하고 비용도 많이 들 것이다. 이런 기능을 하도록 하는 것이 더 낫지 않겠는가"와 같은 제안을 할 수 있어야 한다.

CRP 방법론을 거치면 기본 소프트웨어 대 개별화된 소프트웨어 논쟁을 거치지 않고도 얼마든지 문제를 해결할 수 있다. 물론 주문할 피자에 소시지를 올릴 것이냐, 페퍼로니를 올릴 것이냐의 논쟁은 있을 수 있겠지만 말이다.

애자일 방법론의 어두운 비밀
대부분의 IT 업무에 적용이 어렵다는 것 외에도, 사실 애자일 방법론에는 어두운 비밀이 하나 더 있다. 애자일 개발은 사실 제품 납품을 위한 방법론이라는 것이다. 스크럼이든, 칸반, 린, 또는 기타 어떤 변종이든, 결국 IT가 소프트웨어 제품을 납품해야만 프로젝트가 끝난다는 건 동일하기 때문이다.

하지만 소프트웨어를 아예 처음부터 제작하기 위해 스크럼 방법론을 채택하든, 아니면 CRP를 채택하든, 제품 납품 자체가 목적인 사람은 없다. 중요한 것은 '이런 소프트웨어를 통해 의도했던 비즈니스 변화가 가능한가'이다. 애플리케이션은 이런 변화를 실현하기 위해 기업이 사용하는 도구일 뿐이다.

CRP 방법론의 2단계는 비즈니스 운영을 더 나은, 기존과 다른 방식으로 하기 위함이다. 비즈니스의 변화는 이 과정에 기본적으로 내장되어 있는 요소다.
애자일 테크닉을 사용해 애플리케이션을 개발하는 것은 결국 비즈니스 변화를 타인의 책임으로 전가해 버릴 수 있다는 리스크가 너무 크다. 스크럼, 칸반 등 애자일 방법론은 기본적으로 제품 납품을 목표로 하고 있기 때문이다. 그렇지 않았더라면 제품 소유자도 없었을 것이며 사용자 스토리 역시 소프트웨어의 목적을 다루지는 않았을 것이다.

지금 기업에게 필요한 것은 비즈니스 운용을 더욱 효율적으로 하기 위한 설계에서부터 시작하는 새로운 방법론이다. 그리고 이런 설계를 사용자 스토리로 전환하고, 여기에 맞는 구체적인 태스크를 백로그에 추가해 기업이 일을 처리하는 방식 자체를 변화시킬 수 있는 방법론이 필요하다.

조금 더 욕심을 내 보자면, 기업의 각 부문이 업무를 처리하고, 반복적이고 점진적인 목표를 애플리케이션 변화와 강화를 통해 달성해 나갈 수 있는 반복적, 점진적 기술이 있다면 가장 이상적일 것이다.

애자일의 단점, 무시했다간 무늬만 성공한 프로젝트
모든 소문이 그러하듯, 애자일의 '어두운 비밀' 역시 알고 보면 그다지 대단한 것은 아니다. 하지만 그럼에도 불구하고 이런 단점을 무시한다면 많은 시간과 노력의 낭비로 이어질 뿐 아니라 불필요한 논쟁을 피할 수 없게 된다.

또한 겉보기에 성공적인 프로젝트라 해도 실질적인 비즈니스 운용이 과거보다 더 나아졌는가 라고 자문해 보았을 때 선뜻 대답할 수 없는, 무늬만 성공적인 프로젝트에서 벗어나기도 어려울 것이다. editor@itworld.co.kr  


2018.04.03

애자일 방법론의 어두운 비밀, "IT에서는 거의 사용할 일 없다"

Bob Lewis | CIO
애자일(Agile)은 이제 지나간 옛 노래 정도로 생각하는 사람들도 있을 것이다. 앞서가는 기업들은 모두 데브옵스로 옮겨간 지 오래라고 말이다. 하지만 대다수의 애플리케이션 팀은 애자일 방법론을 도입한 적이 없을뿐더러, 애초에 도입할 수 없다고 생각하고 있다.


Credit: Getty Images Bank

이것이 의외라고 생각할 수도 있지만, 애플리케이션 팀의 업무를 자세히 살펴보면 이해 못 할 것도 아니다. 이들 팀의 목표와 애자일 방법론이 달성할 수 있는 결과 사이에는 공통 부분이 거의 없기 때문이다.

애자일, 그 가운데서도 특히 많은 IT 매니저가 애자일과 동의어라고 생각하는 스크럼(Scrum)은 IT와는 거의 관계없는 새로운 애플리케이션 개발이라는 측면에서 강점을 가지고 있다.

회사 웹사이트와 모바일 앱을 제외하면, IT 부서의 핵심 원칙은 "구매는 할 수 있을 때, 제작은 해야 할 때" 한다는 것이다. 때문에 기업 IT는 새로운 기능의 90% 가까이를 상용 제품(Commercial Off-The-shelf Software, COTS)나 SaaS(Software as a Service) 형태로 허용하고 있으며 전체의 10%만이 인하우스로 개발된 소프트웨어다.

그런데 스크럼, 칸반(Kanban), 린 소프트웨어 개발(Lean Software Development) 등 대부분 애자일 방법론은 이 10%를 겨냥하고 있다는 게 문제다. 게다가 대부분의 경우 개발자는 업무 시간의 70% 이상을 이미 제작 중에 있는 애플리케이션의 유지, 강화에 사용하고 있기 때문에 새로운 애플리케이션을 도입할 시간이 많지 않다.

계산을 해 보자. 애자일은 개발자가 할애할 수 있는 그 30%의 시간 중에서도 10%의 경우에만 유효하다. 즉, IT 애플리케이션 팀 업무 중에 애자일이 유효하게 사용될 수 있는 경우는 3%에 불과하다는 얘기다.

물론 기업에 따라 구체적인 숫자는 조금씩 다를 수도 있지만 어떤 기업이든, 애자일 방법론이 활용되는 비율은 그다지 높지 않을 것이다. 하지만 이런 현실을 바꿀 수 있는 방법도 없지는 않다.

유지, 강화 업무에 애자일 적용하기
쉬운 것부터 해결해 보자. IT 부서 업무의 상당부분을 차지하는 유지, 보수, 강화 업무에 애자일 방법론을 적용할 수는 없을까.

굳이 줄줄이 이어지는 유지, 보수, 강화 업무를 살펴보지 않아도, 이것이 애자일 백로그와 얼마나 닮아 있는지는 어렵지 않게 알 수 있다. 여기에 제품 소유자(Product Owner, PO)를 더하고, 리퀘스트를 사용자 스토리(user story)로 포장해 보자. 그리고 칸반을 적용한다. PO가 우선 순위를 정하고, 개발자가 사용자 스토리를 끝낼 때마다 백로그에서 다음 사용자 스토리를 선택해 작업을 이어간다. 매우 간단할뿐더러 효율적이며, 간접 비용도 거의 들지 않는다.

애자일 COTS
COTS 이행에 애자일 방법론을 적용하는 것은 앞선 경우만큼 간단하지는 않다. 하지만 이는 모두 예상했던 것이다. 대규모 시스템을 도입, 이행하는 것이 일상적인 애플리케이션 유지, 강화 작업과 같을 수는 없기 때문이다.

하지만 COTS에도 애자일 방법론을 적용할 수 없는 건 아니다. 단지 두 가지 중요 포인트를 놓치지만 않으면 된다.

첫째로, 온 프레미스이든 SaaS를 통해서이든 COTS 이행은 소프트웨어 개발과 한두 가지 측면에서 다르다는 점을 인식해야 한다. 이런 근본적 차이점으로 인해 스크럼이나 칸반 등의 애자일 방법론은 적합하지 않다.

두 번째는 이미 앞서 한번 언급한 것인데, 세상에는 스크럼과 칸반 이외에도 다양한 애자일 방법론이 있다.

개발의 시작은 데이터 구조 설계, 앱 개발 대 COTS
IT 팀에서 소프트웨어를 개발할 때는 그 기업 전체가 이 소프트웨어를 어디에 어떻게 사용하게 될 것인가를 생각해 봐야 한다. 그리고 이에 대한 대답을 얻었다고 해도, 곧바로 소프트웨어 개발에 착수하게 되는 것은 아니다.

우선은 데이터 구조를 설계해야 한다. 애플리케이션 개발은 그 다음이다. 물론, 기존의 데이터베이스가 새로운 애플리케이션의 니즈를 충족할 수 있는 상황이라면 데이터 구조를 따로 설계할 필요가 없다.

"구매는 할 수 있을 때, 제작은 해야 할 때" 원칙은 근본적으로 다르다. IT가 COTS/SaaS 패키지를 이행할 때 기존의 데이터베이스는 도움이 아니라 방해가 된다. 각 패키지에는 자체적인 데이터베이스가 포함되어 있으며 소프트웨어 벤더가 데이터베이스를 설계할 때는 이미 기업들이 기존에 가지고 있는 데이터베이스를 고려하지는 않기 때문이다. 또한 다른 개발업체들이 설계해 둔 데이터베이스를 고려할 이유도 없다.

따라서 IT가 COTS 패키지를 이행하려면 새로운 애플리케이션이 관리하는 동일한 데이터를 저장하고 있는 모든 기존 데이터베이스를 찾아내야 하며 중복되는 데이터들 간 동기화를 어떻게 하면 좋을지 방법을 찾아야 한다. 데이터 관리 측면에서도, 내부적 개발과 패키지 이행은 완전히 다른 문제다.

소프트웨어의 용도 규정
일단 데이터 구조가 확립됐으면, 이제 소프트웨어 용도를 규정해야 할 차례다. 대부분 애자일 방법론들은 이를 위해 '사용자 스토리'를 사용한다. 사용자 스토리란 보통 다음과 같은 형식을 취한다.

"ㅇㅇㅇ 사용자로서, ㅇㅇㅇ를 위해/ㅇㅇㅇ를 이유로 ㅇㅇㅇ의 목표를 달성하고자 한다(As a <type of user> I want <a goal> so that <good reason>)."

예를 들어, "텔레마케터로서, 다음에 판매할 제품에 관심이 있을 만한 고객에게만 전화를 걸 수 있도록 고객 가정에 대한 정보를 저장하고자 한다"와 같은 식이다.

물론 이 예시는 어디까지나 예시일 뿐이다. 하지만 그게 문제는 아니다. 진짜 문제는 따로 있다. CRM 시스템 이행 시 이런 부분에 있어 고집을 부린다면 모든 사람의 시간을 낭비하고 비즈니스 매니저를 아주 성가시게 만들게 될 뿐이다. 모든 유형의 '고객'에 대한 정보를 저장하지 않는 CRM 패키지를 실행한다면 CRM 패키지를 실행하는 것이라고 말할 수 없다.

COTS나 SaaS 소프트웨어를 실행할 때 흔히 하는 이야기가, 이것저것 더하지 않고 '기본' 소프트웨어를 실행하거나, 아니면 기업의 특수한 니즈와 관행이 맞춰 개별화된 소프트웨어를 실행해야 한다는 것이다. 하지만 이 둘을 대안으로 놓고 이야기하는 것은 아주 바보같은 행동이다.

COTS 소프트웨어는 많은 경우 해당 소프트웨어를 사용하게 될 비즈니스 부문이 현재 사용하고 있는 버전보다 여러 부분에서 훨씬 뛰어나다. 그러나 반드시 그렇지만은 않은 경우도 많다.

IT 부서는 '내부 고객'들을 만족시켜야 한다며 커스터마이징을 옹호하는 이들은 그럴듯해 보이는 새로운 소프트웨어 도입에 예산을 지출해야 한다고 주장한다. 그렇게 해야 지금까지 해 오던 것처럼 비즈니스를 이끌어 갈 수 있다는 것이다. 이 주장은 비용은 많이 들고, 일은 지금까지 해 왔던 것과 똑같이 해야 한다는 것이다.

또 설령 비즈니스 프로세스가 전혀 다르지 않다는 전제 하에, 아니 다르지 않아야 한다는 전제 하에 기본적인 소프트웨어를 있는 그대로 사용한다고 해 보자.
특정 분야에서 업계 최고를 자랑하는 기업의 경우, 이런 기본적인 소프트웨어 도입을 강제하는 것은 곧 비즈니스의 도태를 전략으로 내세우는 것과 같다.

따라서 '기본 소프트웨어' 대 '개별화된 소프트웨어'라는 대결 구도 자체가 잘못된 것이다. 애초에 이런 프레임을 전제로 의사결정을 해서는 된다.

2단계 COTS
IT가 아닌 기업에서 COTS를 통한 비즈니스 변화를 추구할 때는 보통 두 단계에 걸쳐 변화가 일어난다. 소프트웨어의 강화와 비즈니스 최적화가 그것이다.

첫 번째 단계인 소프트웨어 강화는 잘 알려지지 않은 애자일 방법론인 컨퍼런스 룸 파일럿(Conference Room Pilot, CRP) 방법론을 이용해 해결할 수 있다. CRP는 다음과 같다.

우선 IT가 마스터 데이터를 새로운 패키지의 데이터베이스에 로드한다. 여기서 마스터 데이터는 고객 데이터, 제품 데이터 등을 말한다. 그러면 프로젝트 매니저가 화이트보드와 큰 모니터 등이 구비된 큰 컨퍼런스 룸을 빌린다. 그리고 나서야 비로소 새로운 패키지로 비즈니스 트랜잭션을 처리래 소프트웨어 강화가 이뤄질 수 있게 된다.

이런 비즈니스 트랜잭션은 주의깊게 계획된 테스트 플랜의 결과일 수도 있고, 아니면 그저 지난 달, 혹은 그 전에 프로세스된 것일 수도 있다. 어느 쪽이건 상관은 없다.

그런 후, 다수의 비즈니스 사용자와 애플리케이션 전문가를 불러 컨퍼런스 룸 안에 모아놓고 종종 배가 고프지 않도록 피자와 음료도 시켜준다. 그러면 컨퍼런스 룸 안에서는 어떤 일이 일어날까. 일단 비즈니스 사용자가 트랜잭션을 들고 주어진 소프트웨어로 문제를 해결하려 하다가 포기한 후 전문가에게 이렇게 말 할 것이다.

"이 트랜잭션은 …와 같은 이유로 처리하기 어려울 것 같다"고 말이다. 그러면 개발자는 "…와 같은 이유" 부분을 처리하게 된다. 이 과정을 수 차례 반복하다 보면 트랜잭션 처리를 방해하는 요소들이 모두 제거 될 것이다. 그러면서 자연스럽게 2단계로 넘어가게 될 것이다.

1단계에서 2단계로의 전환은 대화 내용의 변화를 보면 알 수 있다. 1단계에서 비즈니스 사용자들은 트랜잭션을 프로세스할 수 없는 이유에 대해 주로 대화를 나누게 되지만, 2단계에서의 대화는 주로 "만약 소프트웨어가 …하게 된다면, 트랜잭션 프로세싱이 더 쉬워질 것 같다"가 될 것이다. 즉, 더 이상 소프트웨어 강화가 주제가 아니라 프로세스의 효율성 개선, 다시 말해 비즈니스 최적화가 주제가 되는 것이다.

참고로, 이 과정에서 개발자들은 수동적으로 명령을 받아 수행하는 방어적인 입장이 아니다. 어느 때든 자유롭게 "소프트웨어를 이렇게 만들면 상당히 복잡하고 비용도 많이 들 것이다. 이런 기능을 하도록 하는 것이 더 낫지 않겠는가"와 같은 제안을 할 수 있어야 한다.

CRP 방법론을 거치면 기본 소프트웨어 대 개별화된 소프트웨어 논쟁을 거치지 않고도 얼마든지 문제를 해결할 수 있다. 물론 주문할 피자에 소시지를 올릴 것이냐, 페퍼로니를 올릴 것이냐의 논쟁은 있을 수 있겠지만 말이다.

애자일 방법론의 어두운 비밀
대부분의 IT 업무에 적용이 어렵다는 것 외에도, 사실 애자일 방법론에는 어두운 비밀이 하나 더 있다. 애자일 개발은 사실 제품 납품을 위한 방법론이라는 것이다. 스크럼이든, 칸반, 린, 또는 기타 어떤 변종이든, 결국 IT가 소프트웨어 제품을 납품해야만 프로젝트가 끝난다는 건 동일하기 때문이다.

하지만 소프트웨어를 아예 처음부터 제작하기 위해 스크럼 방법론을 채택하든, 아니면 CRP를 채택하든, 제품 납품 자체가 목적인 사람은 없다. 중요한 것은 '이런 소프트웨어를 통해 의도했던 비즈니스 변화가 가능한가'이다. 애플리케이션은 이런 변화를 실현하기 위해 기업이 사용하는 도구일 뿐이다.

CRP 방법론의 2단계는 비즈니스 운영을 더 나은, 기존과 다른 방식으로 하기 위함이다. 비즈니스의 변화는 이 과정에 기본적으로 내장되어 있는 요소다.
애자일 테크닉을 사용해 애플리케이션을 개발하는 것은 결국 비즈니스 변화를 타인의 책임으로 전가해 버릴 수 있다는 리스크가 너무 크다. 스크럼, 칸반 등 애자일 방법론은 기본적으로 제품 납품을 목표로 하고 있기 때문이다. 그렇지 않았더라면 제품 소유자도 없었을 것이며 사용자 스토리 역시 소프트웨어의 목적을 다루지는 않았을 것이다.

지금 기업에게 필요한 것은 비즈니스 운용을 더욱 효율적으로 하기 위한 설계에서부터 시작하는 새로운 방법론이다. 그리고 이런 설계를 사용자 스토리로 전환하고, 여기에 맞는 구체적인 태스크를 백로그에 추가해 기업이 일을 처리하는 방식 자체를 변화시킬 수 있는 방법론이 필요하다.

조금 더 욕심을 내 보자면, 기업의 각 부문이 업무를 처리하고, 반복적이고 점진적인 목표를 애플리케이션 변화와 강화를 통해 달성해 나갈 수 있는 반복적, 점진적 기술이 있다면 가장 이상적일 것이다.

애자일의 단점, 무시했다간 무늬만 성공한 프로젝트
모든 소문이 그러하듯, 애자일의 '어두운 비밀' 역시 알고 보면 그다지 대단한 것은 아니다. 하지만 그럼에도 불구하고 이런 단점을 무시한다면 많은 시간과 노력의 낭비로 이어질 뿐 아니라 불필요한 논쟁을 피할 수 없게 된다.

또한 겉보기에 성공적인 프로젝트라 해도 실질적인 비즈니스 운용이 과거보다 더 나아졌는가 라고 자문해 보았을 때 선뜻 대답할 수 없는, 무늬만 성공적인 프로젝트에서 벗어나기도 어려울 것이다. editor@itworld.co.kr  


X