5장. 계약
#5-1 고정 가격계약
5장. 계약
이번 장에서는 발주사가 IT 개발을 의뢰한 뒤 실제 서비스를 개발하는 상황을 두고, 국내에서 계약을 진행할 때와 해외에서 계약을 진행할 때 근본적으로 차이가 나는 부분에 대해 이야기하고, 계약과 예산 분배 방식에 대해 다루어보겠다.
#5-1 고정 가격계약
'10년, 애자일 전환을 위해 500명 이상의 사람들을 교육하고, 30개 이상의 프로젝트에 애자일 코칭 서비스를 제공했다. 애자일 전환을 위해 여러 가지 노력을 기울였지만 결국 이는 지속되지 않았다. 애자일 전환이 시작된 지 2년 뒤부터 애자일의 불길은 점차 사그라들었다. 방법론이 론칭되고, 사람들에게 활용되기 시작하면서 여러 가지 문제가 발생했다. 여러분들도 비슷한 일을 현장에서 시도하려 한다면, 워터폴 문화환경에서 애자일을 적용할 때 아마도 이제부터 언급할 일들을 유사하게 관찰하게 될 것이다.
* 유연한 문서 템플릿으로 야기된 현장의 혼란
첫 번째로, 정의된 산출물에 대해 불만이 속출했다.
애자일 방법론은 고객 및 사용자와의 대화를 중요시 하기에 “굳이너프(Good Enough:필요한 만큼)”한 만큼의 문서를 만든다. 때문에 방법론에는 최소한의 산출물만 명시하고 그 위에 필요한 것을 프로젝트마다 추가할 수 있도록 하는 콘셉트를 두었다. 유연함을 주면, 더 프로젝트에 적합한 산출물을 작성할 수 있으리라 생각했다. 하지만 반대로 유연함을 추구하는 방식이 더 문제가 되었다.
SI 구축형 사업을 수행하는 프로젝트의 사람들은 방법론에서 정의한 산출물을 그대로 가져다 쓰거나, 기존에 쓰던 문서들을 그대로 쓰고 싶어 했다. 그들은 애자일 방법론에 올라간 문서 템플릿을 보고 현실에서 쓰기에 너무 단순하다는 불만을 터트렸다. 고객에게 제공할 수 있는 품질의 문서가 아니라는 것이다.
일반적으로 SI 구축형 사업을 수행할 때, 회사의 방법론으로 정해진 산출물을 먼저 제안서에 정리하고 사업을 수행하는데, 이 굳이너프 한 방법론은 그대로 복사해 붙일 수가 없었다. 대신 애자일 전문가를 불러 어떻게 산출물을 작성해야 하는지, 현실에 맞는 접근을 해야 하는지 프로젝트 팀이 고민을 해야 했다. 이는 그만큼의 부가적인 시간과 노력을 요구했으며, 이 과정이 불필요하다고 생각한 사람들은 이전 익숙한 방법으로 자연스레 회귀했다.
* 애자일에 대한 이해관계자들의 이해 부족
두 번째로, 이해관계자들은 거의 모두 애자일을 몰랐다.
SI 구축형 프로젝트에는 외부 감리를 받아야 하는 제약이 있다. 하지만, 당시 감리사들도 애자일에 대해서는 거의 모르는 사람들이 많았다. 늘 과거에 작성하던 산출물의 정의와 비슷한 것을 찾고 비슷한 상세 레벨을 요구하는 경우들이 많았다. 객체지향 방법론을 중심으로 소프트웨어를 만드는 경우 각 산출물마다의 논리적인 정합성을 매우 중요하게 생각했다. 산출물 간의 추적성뿐만이 아닌, 산출물 안의 내용에 대한 추적성 또한 검토하는 경우가 많았다.
예를 들어 유스 케이스 정의서를 작성하면, 그 유스 케이스에서 어떠한 엔티티와 속성 값이 나와 화면에 연결되고, 테이블이 만들어지고, 비즈니스 로직으로 연결되는지 등을 검증했다. 화면 정의서의 화면 컴포넌트가 어떠한 요구사항으로 만들어져야 하는지, 이벤트가 어떻게 프로그램과 이어지는지를 산출물들이 설명해야 했다. 이는 소프트웨어가 잘 동작하는 상황에서도, 역으로 산출물의 명세화를 해야 하는 이상한 일하는 패턴들을 만들어냈다. 품질을 프로세스 품질과 프로덕트 품질로 나누어 설명하면 프로덕트의 품질도 중요하나 프로세스의 품질이 매우 중요한 형태로 받아들였다. (애자일은 이 둘 중 프로세스의 품질은 자동화로 검증하고 프로덕트의 품질을 중시한다)
* 기존과 인력 투입 방식 상이
세 번째로, 일하던 방법과 사람을 투입하는 방식도 문제가 되었다.
특히 차세대 사업 같은 경우는 분석/설계자가 명시적으로 분리되어 존재하는 경우가 많았다. 늘 폭포수 방식으로 분석/설계자가 문서를 작성하고 개발자들이 후에 들어와 이 명세화를 기준으로 개발을 수행했다. 때문에 명세화는 반드시 상세하게 작성해야 했으며, 그 뒤에 개발자들은 이를 믿고 개발을 했다.
애자일일 도입할 때 사람을 투입하는 방식이 문제가 되었다. 프로젝트의 비용을 최소화하기 위해, 분석/설계자를 늘 먼저 투입하고 개발 기간이 되면 분석/설계자는 최소한으로 남기고 개발자들을 투입해야 하는 방식을 써왔는데, 애자일 방법론을 쓰면 이렇게 하는 대신에 초기에 개발자들을 함께 투입하고 분석/설계자들을 오래 두어야 했다. 프로젝트 관리자에게 이는 더 많은 원가를 발생시키는 방법이었다. 당시 아래와 같은 그림을 그려 투입공수는 거의 비슷하다는 설득논리를 만들었던 기억이 있다.
개발자의 투입 공수가 크게 차이가 없다고 주장했던 그림* 고객사와 문화와의 충돌
네 번째로, 고객사의 시스템과 문화 또한 문제였다.
대형 프로젝트에는 다양한 이해관계자들이 있었다. 애자일 방식으로 일하려면, 고객과 대화하는 채널이 견고하게 만들어져야 한다. 그리고 실무자가 하고 있는 일에 대한 오너십을 느낄 수 있도록 의사결정권을 필요한 만큼 주어야 한다. 정부사업 같은 경우는, 고객 실무자에게 적당한 의사 결정권이 있더라도 수행사가 원하는 만큼 프로젝트에 자주 참여하지 못하는 고객들이 많았다. 그들은 보통 2~3개 사업을 주로 수행하고 있었고, 당시 일을 수행사에 맡기고 결과만 확인하려는 경향이 강했다.
이들이 책임감이 없기 때문이 아니라 시스템의 문제였다. 예를 들어 정부사업의 고객들 사이에 주기적으로 업무 로테이션을 하는 시스템이 있었다. 어느 순간 의사 결정한 담당자가 바뀌는 경우가 비일비재했다.
그것보다 더 큰 문제가 정부, 금융권, 대기업 가리지 않고 한국의 전통적인 계층 조직구조가 있었다. 실무자가 의사결정을 하더라도, 경영층에서 의사결정을 번복하는 일들이 비일비재했다. 잘못된 의사결정을 바꿀 수 없는 경우도 많았다.
이쯤 되니, 많은 사람들이 이러한 이야기를 하기 시작했다.
“애자일은 우리 회사에서... 아니, 한국에서 안돼”
그리고 애자일 이야기를 하면 절레절레 고개를 흔드는 경영층 또한 생겨나기 시작했다. 점점 애자일에 대한 부정적인 의견이 높아졌다.
* 근본적인 차이는 계약
반면에 해외에서는 애자일 관련된 붐이 점점 커지고 있었다. '12년 필자가 참여한 미국 댈러스에서 열린 애자일 콘퍼런스에서 3000여 명의 IT전문가들이 모여 애자일 관련된 열띤 토론을 벌였다. 일을 잘한다는 회사들은 앞다투어 ‘우리는 애자일을 하고 있다.’라고 말하고 있었다.
'11년 버전원에서 수행한 조사에 따르면, 자신이 근무하는 회사에서 전사 프로세스 자체가 애자일이라는 응답은 이미 60%를 넘었다. 전사 프로세스 적용 회사들이 전체의 60%이라면 일부라도 애자일 기법을 적용하는 회사는 이미 80%가 넘는다는 의미였다. 이 조사는 전 세계를 대상으로 수행한 것이기에 미국만의 이야기도 아니었다. 해외는 이미 국내와 사정이 달랐다.
['11년 VersionOne의 애자일 조사]그렇다면 해와와 국내의 차이는 과연 무엇일까? 무엇이 국내에서의 애자일을 막고 있는 것인가?
이 원인에는 다양한 문화적 차이가 있지만, 필자는 가장 큰 차이를 IT 프로젝트를 수행할 때의 계약 방식이라고 생각한다.
아래 표는 '15년에 글로벌 회사를 상대로 수행한 ‘서비스 퍼포먼스 인사이트’의 계약방식에 관련 설문 조사 결과이다. 이 내용에 따르면, 전체적으로 볼 때 시간 자재계약(Time and Material) 방식의 비율이 고정 가격계약(Fixed time and fixed fee) 보다 많다. 해외 회사의 벤치마킹을 하면서 고정 가격계약의 비율이 어느 정도 되냐고 질문하면 일반적으로 20~30%라 답하는 경우가 많다. 고정 가격계약과 시간 자재계약은 일하는 방식에서 커다란 차이를 만든다.
[SP 인사이트에서 2015년 조사한 글로벌 IT 계약 방식 비율]* 고정 가격계약의 환상
이와 관련하여 필자가 '09년 겪은 에피소드 한 개를 소개하려고 한다. 이전 장에서 언급했던 DaD를 창시한 스캇 엠블러라는 애자일 컨설턴트(현재는 독립 컨설턴트)가 회사에 방문했었다. 그는 그가 생각하는 애자일이 무엇인지에 대한 주제로 회사의 경영진을 상대로 1시간 넘게 강연을 했었고, 많은 사람들이 그의 이야기를 듣기 위해 강연에 참석했다.
사실 강연 자체는 크게 청중을 울리지 못하는 느낌이었다. 영어였기도 했고, 그가 얘기한 엔터프라이즈 애자일 방법론은 당시 먼 나라 이야기 같았다. 하지만 아직까지 또렷하게 기억되는 메시지가 있다. 지금에 와서도 필자가 이를 잘 기억하는 이유를 생각해보면, 그의 의견은 꽤 강했는데, 잘 공감은 되질 않아서였다.
누군가의 질문에 대해 소신껏 답변했는데, 그 자리의 많은 사람들이 혀를 끌끌 차며 ‘너무 이상적이다’라는 반응을 보였고 필자도 마찬가지였다. 그럼에도 불구하고 스캇은 더 강하게 본인의 주장에 목청을 높이며 굽히지 않았다.
[DaD의 Scott Ambler]당시 질문은 다음과 같았다.
“납기가 정해져 있는 고정 가격계약 방식으로 일을 할 때도 과연 애자일이 가능한가요?”
“그것은 애자일을 하건 안하건 관계없습니다. 여러분의 고객이 여전히 고정 가격계약 방식을 고집할 때마다, 여러분이 하고 있는 일이 계속해서 문제가 생길 것이라는 것을 이해하셔야 합니다. 물론 고객은 고정 가격계약 방식으로 일하기를 원하겠지만, 여러분은 곧 이를 시간 자재계약방식으로 전환할 수 있도록 고객을 가르치고 설득해야 합니다. 그렇지 않으면 여러분의 미래는 없습니다.”
그의 말은 단호했다. 강연장 곳곳에서 ‘끄응’ 하는 못마땅해하는 신음 소리가 터져 나왔다. 당시 나도 그랬다.
회사 내 진행되는 거의 모든 프로젝트가 고정 계약방식이었고, 이는 대한민국 전체도 마찬가지였다. 현실의 제약 속에서도 어떻게든 애자일을 해보려고 마음먹은 필자에게도 그의 말은 한국의 현실을 무시한 어이없는 답변이었다.
계약 방식을 바꾼다는 의미는 고객을 설득하는 것뿐만이 아니라, 프로젝트를 수행하는 방식을 넘어 계약이 이루어지는 방식, 고객사부터 회사까지의 전반에 걸친 정책 및 환경의 변화가 필요하다는 말이었다.
이야기를 더 하기 전에, 고정 가격계약방식과 시간 자제 계약방식에 대해 설명해보겠다. 스타트업 DA14의 최고 기술 책임자 드미트리는 두 가지의 차이에 대해 다음과 같이 설명한다. 일반적으로 고정 가격계약은 다음의 상황에 쓰는 것이 바람직하다.
명확한 요구사항과 명확한 데드라인이 있을 때
예산이 제한적이고 부족할 때
MVP를 개발할 때
업무범위가 적은 소규모 프로젝트를 수행할 때
고객 입장에서 고정 가격계약을 수행하면, 관리가 쉽고 예측하기 쉽다. 회사가 전략을 짤 때 일반적으로 명확한 납기를 필요로 하는 경우가 많고, 투자에 대한 결과를 정해진 날짜에 얻고 싶을 때 이 계약방식을 쓰게 된다. 특히 투자자가 수행사를 신뢰하기 어려운 경우 결과에 대해 명확하게 정의하고 이 방법을 쓸 수 있다. 때문에, 주로 1~3개월 정도로 짧은 기간 동안 프로젝트를 수행할 때는 적합한 방법이다.
하지만 프로젝트 기간이 4달 이상이 되면 시장의 변화와 회사 자체의 변화도 예측하기 매우 어렵기 때문에, 명확한 결과를 얻을 수 있다는 가정이 사라지게 된다. 가장 큰 문제는 유연함이다. 정해진 것 외에 다른 것을 하려면 수행사와 어려운 협상의 과정이 있어야 한다. 시장과 회사 전략의 변화에 따라 변경을 요구할 때 대립하는 경우를 자주 찾아볼 수 있다. 또한 프로젝트에 고객으로서 깊게 참여하는 것이 어렵다. 수행사가 고객을 방어적으로 대할 가능성이 높기 때문이다.
반면에, 시간 자재계약 방식은 일반적으로 다음의 경우에 쓴다.
요구사항이 자주 바뀌는 긴 기간의 프로젝트
프로젝트 업무범위가 잘 정해지지 않았을 때
업무 범위나 리소스 변경에 유연함을 얻기 위해
가장 큰 장점은 고객 입장에서 볼 때 개발할 언제나 기능을 변경할 수 있다. 주변 환경의 변화에 따라 유연하게 말이다. 대형 프로젝트 같은 경우, 프로젝트 시작 전에 시간에 따라 변하지 않도록 업무 범위를 명확히 정의하는 것이 거의 불가능하다. 심지어 예산이 얼마나 쓰일지 예측하는 것도 어렵다. 이 계약방식의 경우 고객은 많은 시간 수행사와 이야기해야고 함께 '업'에 대해 이해하는 작업을 해야 한다. 더 많이 관여하여야 고객 입장에서 더 많은 가치를 얻어낼 수 있다.
국내 대부분의 IT서비스 개발방식이 고정 가격계약이라는 것은 매우 발주사, 즉 관리주체에 집중되어 있는 일하는 방식을 선호하는 것이다. 사용자의 만족보다 고객의 일부 이해관계자의 만족에 초점을 맞추고 있다. 궁극적으로 사용자가 불만을 터트리면 그 이해관계자들도 불만을 터트리게 될 것인데도 말이다.
이 내용을 뒷받침하기 위해 소프트웨어 과학자라 불리는 마틴 파울러가 고정 가격계약에 대해 과거 썼던 글을 소개하고 싶다.
[마틴 파울러, 소프트웨어 싸이언티스트]--------------------------
고정 가격계약의 환상(Fixed Price Mirage), 마틴 파울러
“많은 회사들이 고정 가격계약을 선호한다. 이유는 그들 생각에 이 방식이 보다 리스크가 낮기 때문이다. 이 신기루 같은 환상은 원가절감 차원에서 적은 금액을 사용하도록 하기 위한 수단이다. 하지만, 중요한 것은 그들이 만족할만한 소프트웨어를 얻지 못하면, 실제로 원가는 더 쓰게 된다.
내가 과거 독립된 컨설턴트로 일할 때, 난 늘 고객에게 이 환상을 피하라고 조언했다. 이 환상이 이론에서는 그럴듯하게 들리지만, 실제로는 일어나지 않는 일이기 때문이다.
우선, 원가 절감에 초점을 맞춰보자. 당신이 소프트웨어를 만들려는 이유는 당신에게 비즈니스적 가치를 주기 때문이다. 더 단순하게 표현하면, 만드는데 든 비용보다 더 많은 가치를 얻고 싶기 때문이다. 아니라면 왜 굳이 소프트웨어를 만들겠나? 만약 소프트웨어가 우리가 낸 비용만큼 보다도 가치를 못하다면, 우리는 비용을 낭비한 것이고, 프로젝트를 직접적으로 도와준 이들의 공수 또한 낭비한 것이다. (중략)
또 다른 고려해야 할 사항은, 고정 가격 계약이란, 요구사항을 제대로 이해하는 주계약자를 위한 계약방식이라는 것이다. 도메인에 대한 지식이 부족한 경우, 지식이 부족하니 심지어 낮은 금액으로 입찰에 참여하게 되고, 이 경우 변경 때마다 어려운 대화를 고객과 나눠야 하는 경우가 많다.
변경 때마다 비용을 받지 않으면 안 되는 것이다. 심지어 어떤 회사는 얼마나 많은 변경사항을 받아 프로젝트에서 추가 매출을 올리는지가 관심사인 경우도 있다. ”
------------------------------------
범위를 유연하게 만들기(Scope Limbering), 마틴 파울러
“애자일 이야기를 할 때마다 애자일은 변경을 수용해야 하기 때문에, 고정 가격 계약으로 일할 수 없다고 한다. (중략) 수년간 우리는 범위를 유연하게 만들기(Scope Limbering)라는 프랙티스를 통해 고정 가격계약으로 시작하여 애자일 방식으로 프로젝트를 성공시킨 사례가 있다. 동시에 고객이 애자일 방식으로 일한다는 것이 어떤 것인지 이해시키면서 말이다.
이를 말하기 위해, 네비올로(가칭)라는 회사의 예를 이야기하고자 한다. 보통 그렇듯이 이전에 누군가가 딜리버리를 망쳐 놓은 이슈 위에 우리가 투입되어 도움을 줘야 하는 상황이 있었다. 오랜 시간 동안 요구사항을 모으고 명세화했으나, 실제 개발된 것은 없었다. 상세한 요구사항을 만들기 위해 정말 오랜 시간과 비용을 들었지만, 차라리 경쟁사처럼 작은 기능이라도 먼저 딜리버리를 하는 것이 보다 낫지 않나 라는 이야기가 진행되는 상황이었다. 하지만 여전히 그들은 고정 가격계약을 주장했고, 이 계약은 그들이 작성한 상세 요구사항을 기반으로 해야 하는 것이었다.
우리는 그 요구사항을 상세히 보고 업무량을 추정해 보았다. 50억 정도의 비용이 필요했다. 많은 고정 가격계약이 그렇듯, 우리도 버퍼를 좀 넣었다. 사실 이 경우 리스크가 커 100억 정도의 비용을 요청했다. 하지만 이는 원래 계약을 했던 회사보다 여전히 적은 금액이었다. (우리 T사의 컨설턴트들은 보통 다른 회사 엔지니어보다 훨씬 많은 비용을 차지한다. 하지만 우리 컨설턴트들은 매우 생산성이 높아, 결과적으로 적은 비용으로 더 많은 일을 하게 된다.)
우리는 모든 상세 요구사항을 고민하고 정의하는데 많은 시간을 허비하지 않았다. 프로젝트가 시작되자마자 변경이 밀려오기 시작했다. 각 변경에 대해 업무량을 추정하고 공수가 늘어난 것에 대해 확인은 했지만, 우리는 이 변경사항에 대해 고객사에 돈을 청구하지 않았다. 천천히 하지만 꾸준하게 이 변경들은 우리가 사전에 확보한 버퍼를 채워나갔다. 6개월 정도 지나, 우리의 버퍼가 다 채워질 즈음, 우리는 네비올로와 솔직한 대화를 나눴다. 이제는 더 이상의 변경은 받기 어렵고, 이제부터는 추가 비용을 추가해야 할 것 같다고. 6개월 간 우리는 늘 업무 내용을 공유했으며, 이는 우리 사이의 신뢰를 쌓았다. 그들은 50억 예산을 추가로 투자했고, 우리는 150억 규모의 프로젝트를 수행 완료했다.
이후, 네비올로는 고정 가격계약은 신기루라는 것을 이해하고, 보다 유연한 형태로 계약방식을 바꾸는 것에 동의했다.
이 내용의 주제는 고객과 협력하는 형태로 일을 하고, 대립하는 형태로 맞서지 않았다는 것이다. 고정 가격계약의 가장 큰 문제는 변경이 일어나는 순간 늘 고객과 맞서게 된다는 것이다. 변경에 대해 돈을 내라, 안 낸다의 실랑이가 벌어진다. 애자일은 ‘계약된 협상보다 고객과의 협업을 중시한다’라는 말은 위 사례를 이야기한다. (중략) ”
------------------------------------
소프트웨어를 만드는 이유는 사용자의 만족 또는 비즈니스적인 가치 때문이다. 때문에, 여러분이 만드는 소프트웨어는 기본적으로 만들 때 드는 비용보다 가치가 있어야 한다. 많은 국내 SI 구축사업에 선택되는 고정 가격계약은 기본적으로 비용보다 더 나은 가치를 만들기 어려운 계약 방식이다. 철저히 발주사 입장에서 서비스 제공자와 맺는 계약 방식이고, 이 때문에 더 많은 대립이 생길 수 있는 방식이다. 고정 가격계약은 기본적으로 철의 삼각형을 만들어 낸다.
[Iron Triangle, 출처: Scott Ambler의 홈페이지]이 철의 삼각형은 업무 범위(Scope), 납기(Schedule), 공수(Resources)를 적절히 배분하지 않으면 제품의 품질을 지킬 수 없다는 것이다. 이는 실질적으로 “제품의 가치”를 추구하기 어렵게 만든다. 아무리 실력이 좋은 엔지니어라고 해도, 기본적으로 정해진 기간 안에 정해진 것을 만드는데 집중할 수밖에 없고, 더 기능을 가치 있게 만들 수 있는 옵션에 대해 실제 사용자와 이야기할 때에도 수동적일 수밖에 없다. 왜냐하면, 더 가치 있는 기능을 만들 때 쓰는 공수는 전체 계약을 흔들 수 없는 범위 안에서 쓰여야 하거나, 변경 요구로 인해 추가적인 비용의 발생을 야기하는데, 전자는 만드는 이에게, 후자는 발주사에게 일반적으로 받아들여지기 어렵다.
위 상황에서 지속적인 협업을 통해 고객의 “가치"를 추구하려면, 현실적으로 조절할 수 있는 것은 ‘업무 범위’ 뿐이다. 그리고 이를 조절할 때 꽤나 많은 마찰을 경험할 가능성이 많다. 때문에, 가치 있는 소프트웨어를 추구하는 애자일 방식에서는 다른 형태의 삼각형을 추구한다. 애자일 삼각형이라 불리는 아래의 그림은 짐 하인 스미스가 쓴 애자일 프로젝트 관리에서 제안되었다.
[하인 스미스의 애자일 삼각형, 출처: http://jimhighsmith.com/]먼저, 가치(Value)는 소프트웨어 기능의 가치이다. 만들고 사용되지 않을 기능보다 계속해서 사용되고 비즈니스적으로 도움이 될 가치를 끊임없이 추구한다. 또한 이 가치는 언제나 딜리버리가 가능한 상태의 동작하는 소프트웨어 형태여야 한다.
두 번째로, 품질(Quality)이다. 특이한 점은 품질은 현재의 품질과 미래의 품질로 나누는 것인데, 현재의 품질은 현재 이터레이션이나 릴리즈 주기 내에 제대로 된 제품이 만들어지고 있는지에 대한 품질이다. 또한 미래의 품질은 제품이 미래에도 잘 가치를 고객에게 전달할 수 있도록, 변경에 대한 안전장치들이 있느냐이다. 그것은 유연한 아키텍처부터, 테스트 코드 등 다양한 기술적 환경에 대한 내용이다.
세 번째로 제약조건(Constraints)이다. 이들은 전통적인 철의 삼각형에 있던 세 가지 내용과 동일한데, 이들이 중요하긴 하지만, 이들 자체가 목적은 아니라는 게 가장 큰 차이다. 즉 더 나은 가치를 위해서라면, 이들의 변경도 가능하다는 것이다.
고객과의 신뢰관계가 충분하다면, 협업을 통해 가치를 추구할 수 있는 방식으로 주변 환경을 변화시키고 여러분의 고객을 설득해보면 어떨까? 계약은 모든 일의 시작점이다. 늘 해오던 방식인 고정 가격계약을 탈피할 수 있는 방법을 함께 찾아보자.
