"애자일 방식으로 개발하자!"라고 말을 하면 누군가는 이렇게 말합니다.
"계약부터가 애자일하지 않은데, 어떻게 애자일하게 합니까?"라고요.
인하우스 제품이나 직접 서비스하는 기업이 아닌 소프트웨어 개발과 운영 자체를 다른 기업에게 제공하는 회사라면....(흔히 SI라고 부르죠.). 소프트웨어의 개발의 시작점은 바로 계약입니다.
계약이 애자일과 다른 사상과 신념 체계로 이루어진다면 계약 이후 과정을 애자일로 시도한다고 해도 쉽지 않을 겁니다.
그럼 도대체 왜 기존의 계약이 애자일을 어럽게 하는지, 그렇다면 우리가 어떤 방식의 계약을 추구해야 하는지 같이 생각해보도록 하겠습니다.
아래 있는 글들은
slideshare.net에 올라와 있는 provaglio의 발표와 SAFe의 Agile Contract, 그리고 국내에서 SI에서 애자일 계약으로 업무를 진행하셨던 SI 기반읜 작은 기업의 대표와의 인터뷰를 기반으로 작성하였습니다.
왜 계약이 중요한가?
먼저 계약이 무엇인지 어떤 내용들을 담고 있는지 생각해 보겠습니다.
소프트웨어 산업에서의 계약은 표면적으로 이런 것들을 대상으로 합니다.
| 동작하는 프로세스/배포와 인수/지불 주기/ 각자의 책임/ 리스크 관리 |
하지만 그 이면을 자세히 들여다 보시면 표면적으로 나타나고 있는 것들이 아래의 것들을 바라보고 있다는 것을 알수 있습니다.
| 희망, 공포(특히나!!), 협업, 신뢰 |
정말 중요한 것들은 이면에 숨겨진 것들입니다. 희망, 공포, 협업, 신뢰 같은 것들을 중요한 요소이지만 눈에 보이지 않는 것들이기 때문에 관리할 수가 없습니다. 그래서 대신 눈에 보이는 요소들을 관리하려 합니다.
계약이 정말 중요한 이유는 이것이 프로젝트 문화와 서로 영향을 주고 받기 때문입니다.
계약 방식은 앞으로 진행하게 될 업무 방식과 문화를 규정하게 됩니다.
계약을 통해 지불 주기/ 배포 인수/ 프로세스 등이 확정되면 공급자는 합의된 방식을 준수하기 위해서 업무에 해당 제약사항들을 적용합니다. 따라서 그 방식으로 공급자는 업무를 진행하고 그것이 그 팀의 문화가 됩니다. 그리고 공급자는 그때의 경험을 바탕으로 다음 계약도 진행하려 합니다.
이렇게 계약이 프로젝트의 문화를 디자인이 하게 되는 것입니다.
다시 말해 애자일 개발 문화를 만들기 위해서는 그에 맞는 계약이 이루어져야 합니다.
위계적인이고 완변성을 추구하는 개발 문화가 필요하다면 역시 그에 맞는 계약이 이루어져야 합니다.
현재의 계약 방식과 영향
그럼 이제 현재의 계약 형태와 그에 따른 영향을 살펴보겠습니다.
먼저 현재 주로 이룰어지는 계약의 형태입니다.
위 그림에서 보실수 있는 것처럼 현재의 계약은 크게 두가지로 나누어 볼 수 있습니다. 정해진 개발 범위(스펙)을 기반으로 하는 Firm Fixed Price(이하 FP)계약과 기간과 리소스의 고정을 기반으로 하는 Time Material(이하 TM) 계약이 있습니다. 그리고 그 사이에 두 안을 절충한 몇가지 계약이 더 있습니다.
새로운 제품을 개발할 때는 주로 FP계약 방식이 사용됩니다. 그리고 시스템에 대한 운영과 유지보수 업무를 주로 하게 되는 경우는 TM 계약 방식을 취하는 것이 일반적입니다.
문제는 FP이건 TM이건 고객과 개발팀 둘 중의 하나의 희생을 기반으로 한다는 것입니다. 그래서 실제 계약과 조금 다르게 운영하거나 계약서에 명시된 몇가지 요소들을 무시하는 경우도 발생합니다. 하지만 여기서는 계약서 중심으로만 이야기를 해보겠습니다.
요구사항을 고정하는 Firm Fixed Price 방식
Firm Fixed Price 계약은 고객의 요구사항의 구체성이 떨어져 추가 요구사항이 만들어지거나 개발팀(이후 공급자로 표현하겠습니다.)이 요구사항의 업무량을 잘못 산정하게 되면 리스크가 발생합니다. 그리고 주로 그 리스크는 공급자가 감다하게 됩니다.
이런 위험을 피하기 위해서 공급자는 아래와 같은 방어적인 전략을 사용합니다.
첫번째, 업무량를 최대한 부풀려라.
두번째, 제품을 최대한 늦게 보여주어 피드백 루프를 차단하라.
첫번째 항목은 구매자도 충분히 예상할 수 있는 전략이기에 구매자도 업무량 산정을 신뢰하지 않습니다. 따라서 공급자가 수용한 요구사항보다 최대한 많은 요구사항을 넣기 위해 노력하죠. 현재 주류 프로세스(워터폴)에서는 초반의 요구사항을 확정하는 것을 기본으로 합니다. 결국 개발팀과 구매자는 어떤 선에서 합의를 해야만 합니다. 이때 어느 선에서 합의를 이루었느냐에 따라서 개발팀이든 구매자든 피해자가 발생하게 됩니다. 왜냐하면 미지의 제품에 대한 완벽한 요구사항에 대한 정의와 산정은 현실적으로 불가능하니까요.
두번째 항목을 보겠습니다. 현재의 SI 계약의 주류 프로세스는 워터폴타입입니다. 제품을 볼수 있는 시기가 개발 막바지입니다. 구매자의 기대보다 조금만 인도 시기를 늦추면 두번째 항목도 달성할수 있습니다. 구매자는 그때 보게되는 제품의 대부분을 수용할수 밖에 없는 경우가 발생합니다. 이때는 워터폴이라는 프로세스가 개발팀을 돕는 것처럼 보입니다.
승자와 패자가 있는 제로섬의 게임처럼 보입니다. 이 계약안에서 공급자와 구매자는 경쟁적인 관계로 만들지게 됩니다. 누가 승자고 누가 패자인지보다 중요한 것은 경쟁적인 관계로 인해 비즈니스 기회를 놓치게 된다는 것입니다.
기간과 리소스를 고정하는 Time Material 방식
어떤 애자일 전문가들은 애자일한 개발을 위해서는 Time Material 계약을 하라고 합니다. 옳은 말입니다. 이 방식의 개발은 공급자에 상당히 많은 자율권을 보장하기 때문에 애자일 방식으로 공급자가 개발하는 것이 가능해집니다.
하지만 비즈니스 도메인에 있는 구매자를 개발에 참여시키지 못하기 때문에 피드백을 받고 피봇팅을 하는 부분에서 여전히 부족한 점이 있습니다. 그리고 TM계약 방식은 절대적으로 공급자에게 유리한 방식입니다. 따라서 공급자를 신뢰하는 구매자가 아니라면 절대 받아들일 수 없는 계약 방식입니다.
신제품이나 서비스를 개발할때는 구매자는 이 방식의 계약을 하지 않을 겁니다. 이 계약 방식이 운영이나 유지보수에서만 사용되는 이유는 운영이나 유지보수는 어느 곳에서 어떤 문제가 나타날지 예측할수 없다고 생각하기 때문이죠. 실제로도 그렇구요.
그 사이의 계약들
위 그림에 있는 두 계약 사이에 존재하는 계약들도 FP또는 TM계약 방식의 문제를 고스란히 가지고 있습니다.
계약 방식에 따라 공급자와 구매자를 경쟁적으로 만들거나 구매자가 받아들일 수 없는 방식이라는 이야기입니다.
그래서 보통 새로운 제품이나 서비스에 대한 개발을 할때는 FP 계약만이 이루어지고 있습니다.
그리고 앞에서 설명드린 것처럼 이 방식은 공급자와 구매자를 경쟁자로 만들로 서로의 신뢰를 막는 장애물이 됩니다.
현재의 계약 방식이 생겨난 이유들
그럼 왜 이렇게 중요한 계약이 현재와 같은 방식으로 굳어졌을까요?
그 이유는 "기존 계약 방식의 차용, 계약서는 법률 전문가가 작성한다"와 같은 이유가 있습니다.
기존 계약 방식의 차용
전통적인 계약 방식은 프로세스와 마찬가지로 소프트웨어 개발을 건축이나 제조업처럼 가정하고 만들어졌습니다.
그래서 아래와 같은 몇가지 가정들을 가지고 있죠.
| 건축이나 제조업에서 생각하는 가정들 - 프로젝트는 상대적으로 예측 가능하다. - 전체 기간을 통해서 만들거나 그렇지 않거나...둘중 하나다 - 피드백은 부실하다.(중요하지 않다) - 프로젝트가 완성되기 전에 끝나면 심각한 낭패를 볼수 있다. - 지불 주기는 길~다. - 재작업은 불가능하거나 최소한 경제적으로 유용하지 않다. |
그래서 소프트웨어 개발에는 적합하지 않습니다.
| 소프트웨어 개발은 서비스다.(건축이나 제조업이 아니다.) - 소프트웨어는 상품의 일시적인 모습이다. - 양쪽 모두 탐색적인 학습 프로세스 위에 있는 것이다. - 예측은 정확하지 않다. |
계약서는 법률 전문가가 작성한다.
법률 전문가의 목적은 하나입니다. "고객을 보호한다."
이 목적을 달성하기 위해서 아래에 있는 것들을 다루게 됩니다.
| 책임의 제한, 보증, 비용, 지적 재산권, 종료, 보증, 서비스 레벨, 지불, 배포/인수, 기밀유지 등 |
하지만 법률가들은 아래 것들에 대해서는 훈련되지 않았습니다.
| 소프트웨어 개발의 특성, 애자일 원칙, 시스템 싱킹 |
따라서 그들이 만드는 계약 방식은 소프트웨어 개발에는 적합하지 않고 특정 입장에서 방어적으로 만들어 지게 됩니다.
그래서 현재의 계약방식의 결론은!!!
이런 법률 전문가들과 소프트웨어 산업에 적합하지 않은 계약의 가정들이 어우러지고 "신뢰의 부족"이 더해지면 소프트웨어 개발 계약서는 잘못된 방향을 작성되게 마련입니다. 그리고 이 계약서의 문제점은 제품을 잘못된 방향으로 나아가게 합니다.
애자일 계약은 애자일 프로세스를 기반으로 해야 한다.
현재의 계약방식으로는 애자일 프로세스를 적용하여 개발을 해나아가기 어려울 뿐만 아니라 기존의 개발 방식(워터폴)에서도 공급자와 구매자의 신뢰를 구축하는 것을 방해합니다. 따라서 소프트웨어 산업의 특성과 애자일 프로세스를 기반으로하는 계약 방식으로 나아가며 하며 그것을 이제 애자일 계약이라고 부르기로 합니다.
그럼 애자일 계약이 담고 있어야 하는 것들은 무엇이어야할까요?
| 애자일 계약이 담고 있어야 하는 것들 - 협력과 신뢰의 프레임워크를 만들어라. - 주기적이고 짧은 기간의 피드백을 만들어라. - 고객이 모든 것을 미리 알수 없다는 것을 수용해라. - 실용적인 방식으로 일하라. - 고객과 계약자가 배포와 품질에 집중하게 만들어라. |
그리고 애자일의 추구하는 투명성,피드백, 가치 중심 배포를 중심으로 생각하면 시간이 지남에 따라 구매자와 공급자의 신뢰가 구축되어 계약구조가 더욱 단순화 될수 있습니다.
애자일 계약의 모습은...
현실적으로 가능한 몇가지 애자일 계약 방식을 간략하게 소개합니다.
아래 세가지 계약방식은 Provaglio에 의해서 소개된 방식입니다.
| Capped T&M With Iteration - 예산 최대치를 편성하고 이터레이션마다 고정된 비용을 가진다. - 목표를 설정하지만 범위는 변화될 수 있고 기간도 고정되지 않는다. - 각각의 이터레이션마다 움직이는 소프트웨어를 배포한다. - 고객은 이터레이션 결과물에 대한 지불을 거절하 수 있고 계약 유지를 포기할 수도 있다. |
| Fixed Price per Story Point - 초기에 스토리 포인트 전체 노력에 대해서 대략 산정한다. - 고객이 제품 백로그의 우선순위를 정한다. - 최대 예산 결정을 통해서 스토리 포인트에 대한 고정된 가격을 뽑아낸다. - 우선 순위에 따라서 각 이터레이션마다 스토리를 배포한다. 스토리 포인트에 대해서 지불한다. - 개발되고 있는 것을 제외하고 고객은 스토리를 바꿀 수 있다. |
| Money For Nothing, Change for Free - "Fixed Price per Story Point"와 유사한 방식 - 고객은 남은 일이 20%에 해당하는 비용을 지불하고 완료 전에 떠날 수 있다. |
다음은 인터뷰 했던 e사 계약서의 몇가지 특징적인 부분입니다.
| 국내 e** SI Agile 계약 방식 - 구매자는 킥오프 미팅에 참여하여 최초 요구사항을 공급자와 함께 탐색한다. - 요구사항은 미리 받지 않고 일주일 단위로 전달한다. - 매주 제품을 인도하고 구매자는 언제든 계약을 종료시킬수 있으며 이를 최소 5일전 통보해야 한다. - 시간 당으로 비용을 계산한다. |
여기서 소개된 계약 방식은 모두 불확실성을 기반으로 빠르고 잦은 배포와 피드백을 기본으로 합니다. 그를 통해 구매자와 공급자의 신뢰를 강화시켜 나갑니다. 또한 구매자에게 조기 종료 권한을 부여하여 시작부터 잘못된 프로젝트의 비용 낭비를 줄일 수 있는 방안도 마련되어 있습니다.
구매자에게 너무 유리한 계약 방식으로 생각되기 쉽지만 제품을 만들기로 결정한 구매자에게는 프로젝트를 조기 종료하는 것은 어려운 결정입니다. 그리고 계약 종료 사전 통보 일정을 최소 몇달 전으로 합의하면 공급자도 충분히 보호할 수 있습니다.
공급자 입장에서도 초반에 많은 약속을 할 필요가 없기에 업무의 부담이 줄어들고 중요한 것에 집중할 수 있는 환경이 마련됩니다. 바로 애자일에서 추구하는 것들 입니다.
정교한 애자일 계약 방식 SAFe Managed-Investment Contracts
SAFe(Scaled Agile Framework)에서의 계약 방식은 SAFe에서 소개하는 다른 프랙티스가 그러하듯이 매우 디테일한 가이드를 제공하고 있습니다.
자세한 설명은 SAFe 홈페이지(https://www.scaledagileframework.com/agile-contracts/)에서 확인 부탁드리며 여기서는 간단하게 실제 계약전에 이루어지는 활동인 Pre-Commitment만 살펴보겠습니다.
SAFe의 애자일 계약에서는 Pre-Commitment라는 기간을 두게 됩니다. 이 기간 동안 공급자와 구매자는 계약의 기초가 되는 것들을 함께 작업합니다. 구매자, 공급자의 책임을 명확히 하며 동시에 공동의 책임을 명시하여 Pre-Commitment기간 동안 공급자와 구매자가 공동의 이해를 수립하도록 돕습니다. 기존에 경제적 프레임워크(https://www.scaledagileframework.com/economic-framework)- 비즈니스 관점에서의 프로젝트 평가- 는 구매자의 영역이었습니다. 하지만 Pre-Commitment 기간동안 공급자도 구매자와 함께 참여하며 공동으로 수립하게 됩니다. 이 과정을 통해 상호 신뢰를 구축하고 제품에 대한 이해를 양쪽 모두 향상시키게 됩니다.
Pre-Commitment기간 책임들
| 구매자의 책임 - SAFe를 배운다. - 계약에 대해서 약속한다. - 프로그램의 미션을 정의한다. |
공동의 책임 - 초기 비전과 로드맵을 확정한다. - 고정된 그리고 변경가능한 솔루션의 목표를 정의한다. - 경제적 프레임워크를 수립한다. - 계약의 범위와 책임을 확정한다. - P1플래닝 백로그를 확정한다. - MVP를 결정한다. |
공급자의 책임 - 계약에 대해서 약속한다. - 초기 범위와 기능을 정의한다. - 가능한 리소스 계획을 수립한다. |
Pre-Commitment이 완료되고 계약이 체결되면 그 이후에 개발 일정을 명확히합니다. 그리고 SAFe는 이 과정동안 구매자가 참여해야 하는 단계와 수준을 명시하여 구매자도 개발에 참여하도록 만듭니다. SAFe는 기본적으로 반복적이고 점증적인 개발방식을 채택하고 있으며 이를 통해 피드백과 변경 사항들이 반영하게 됩니다.
SAFe가 앞서 살펴보았던 몇가지 계약 방식과 동일한 점입니다.
그럼 이제 모두 애자일로 계약하는 겁니다?
이렇게 설명을 들었다고해서 한번에 애자일 계약으로의 전환이 이루어지는 것은 아닙니다.
변화에는 항상 저항이 따르기 마련입니다.
그럼 그런 저항이 무엇이며 우리는 어떻게 대응해야 할까요?
| 변화에 대한 저항들 - 애자일 프로세스에 대한 무지 - 멘탈 모델 - 새로운 방식에 대한 공포(혁신에 대한 책임, 클라이언트를 보호하지 못함) - 숨겨진 진짜 목적(고객이 돈을 쓰게 한다. 리스크를 줄이고, 이익을 최대화한다.) |
이러한 것들은 실재로 현장에서 나타나는 저항들입니다. 모르거나 기존의 자신의 믿었던 것과 다르기도 합니다. 숨겨두었던 진짜 목적으로 인해 받아들일수 없을 때도 있고 책임을 지어야 하는 것이 두려울 수도 있습니다.
이런 것들을 인정하면 할수 있는 것이 많지 않을 수도 있습니다.
먼저 준비를 하고 그들이 변화 될수 있도록 돕는 것, 그것이 우리가 할수 있는 전부입니다.
| 우리가 할 수 있는 것 - 우리가 한 사인과 계약서에 책임을 진다. - 애자일 계약을 하기전에 애자일해진다. - 변화에 대한 고객의 저항을 인식하고 존중한다. - 그들을 위해 고객과 법률전문가가 애자일을 이해하도록 돕는다. - 투명성, 피드백, 가치 중심 전달을 통해 협업 문화를 만든다. - 배포에 집중하고 법적 리스크에 관한 관리는 두번째로 생각한다. - 창조적으로 생각한다. |
마치며...
소프트웨어 산업에서의 계약이 구매자와 공급자를 적으로 만들고 서로 경쟁하게 만들었다면
앞으로는 애자일 계약을 통해 구매자와 공급자가 하나의 목표를 가진 팀으로 일했으면 좋겠습니다.
"애자일 방식으로 개발하자!"라고 말을 했을때 누군가는 이렇게 말했으면 합니다.
"우리는 이미 준비가 되었습니다. 그리고 이제 고객도 참여하실겁니다."라고요...
감사합니다.
- 채드-
'Agile' 카테고리의 다른 글
| SAFe 4.6 국문 용어집(SAFe 4.6 Glossary) (0) | 2020.01.03 |
|---|---|
| 스포티파이의 조직 모델(Spotify Model) (0) | 2019.12.03 |
| SAFe(Scaled Agile Fraemwork 4.6) (0) | 2019.09.18 |
| 홀라크라시와 애자일 (0) | 2019.04.05 |
| Jira에서 이슈를 단어을 사용해서 검색하기 (0) | 2018.07.10 |
