2016.10.18

'성공하는 IT프로젝트는 계약부터 다르다' 어떻게?

Sue McLean | Computerworld UK
IT프로젝트를 성공으로 이끄는 핵심 요건들은 많다. 흔히 협업 담당자 및 IT인력들 간의 원활한 커뮤니케이션과 경영진의 충분한 이해와 지원을 꼽을 것이다. 여기에 하나 더, 필자는 계약서 작성의 중요성에 대해 말하고자 한다. 


Credit: GettyImage

IT프로젝트에서 변호사의 역할은 두 가지다. 하나는 발주기업과 구축회사가 계약서를 제대로 작성했는지 돕는 것이다. 다른 하나는 잘못될 수 있는 것을 찾고, 실패 및 분쟁을 처리할 수 있는 적절한 메커니즘이 계약에 포함되도록 하는 것이다. 많은 기술 프로젝트가 실패한다는 증거가 있기 때문에 두 번째 역할이 특히 중요하다. 변호사는 프로젝트가 지연되거나 예산을 초과하거나 고객의 필요를 충족시키는 기술을 제공하지는 않는다.

그리고 일부 기술 프로젝트의 경우 최근 DAO(Decentralized Autonomous Organization) ‘해킹’에서 보았듯이 극적인 방식으로 실패하기도 한다.

DAO는 이데리움(Ethereum) 블록체인에서 운영되는 대표가 없는 투자 기관의 형태로, 2016년 5월 1억6,800만 달러를 모집하면서 역사상 가장 큰 규모의 크라우드펀딩 프로젝트 중 하나가 되었다.

하지만 출범 직후 DAO는 공격을 받고 6,000만 달러가 빠져나갔다. 여러 전문가들이 이 사건을 '해킹'으로 언급하는 것은 오해라고 말했다. 그들은 공격자가 코드의 디자인 결함을 악용했다고 지적했다. 그들은 이것이 보안 문제가 아닌 디자인 문제라고 주장했다. 요즘은 소프트웨어를 베타 형태로 공개한 이후에 결함을 수정하는 것이 일반적이다. 이런 민첩한 위험 기반의 개발 접근방식이 용인되는 경우가 많다. 하지만 DAO의 경우 엄청난 금액이 관련되어 있었으며 위험이 높은 전략이었던 것으로 보인다.

어쨌든 DAO 사건 덕분에 모든 조직들이 교훈을 얻게 되었다. 새로운 기술이라고 해서 디자인, 시험, 이행에 대한 기준을 완화해서는 안 된다는 것이다.

기업이 기술 개발을 위해 제 3자를 이용할 때 처음에 디자인, 개발, 이행에서 오류가 있을 수 있음을 신중하게 고려하고 계약을 통해 이런 위험을 적절히 예측하고 방어하도록 해야 한다. 실패 및 분쟁 처리를 위한 적절한 해결책을 계약에 포함하는 것 외에 발주회사와 구축기업 당사자들은 처음부터 이런 실패와 분쟁을 피하는 데 도움이 되는 계약서를 작성하는 것을 목표로 삼아야 한다. 주요 초점 영역으로는 요건, 사양, 시험, 이행이 있다.

요건
당사자들 간의 기대치가 일치하지 않거나, 고객의 요건이 너무 복잡하거나 너무 야심 차서 많은 프로젝트가 실패한다. 고객들은 충분한 시간을 갖고 미리 요건을 확인하되 필요한 모든 이해당사자와 사용자를 참여시켜야 한다. 고객들이 요건을 살펴보기도 전에 조달 과정을 시작하는 경우가 너무 많다. 아니면 명확히 달성 가능한 목표에 집중하는 게 아니라 필수 및 '틈새' 기능이 포함된 '쇼핑 목록'형 접근방식을 취한다.

일단 확인된 후 요건을 명확히 기술하는 것이 중요하다. 요건을 수용하기 어렵고 고객의 실제 필요를 파악하지 못하며 고객의 현업 이해당사자와 조언자 및 공급자를 혼동시킬 수 있기 때문에 기술 용어는 피해야 한다.

가능한 조기에 공급자와 요건을 공유해야 한다. 공급자는 계약 전 내용을 분석하고 상당한 주의를 기울여 고객의 요건을 확실히 파악해야 한다. 또한 이후의 분쟁을 방지하기 위해 이런 요건의 명확성 부재, 지나친 욕심 그리고/또는 불필요한 복잡성을 해결해야 한다.

그러고 나서 (필요에 따라 수정된) 요건을 계약서에 포함해 공급자가 계약상 이런 요건을 충족하는 기술을 제공하도록 해야 한다.

---------------------------------------------------------------
프로젝트 관리 인기기사
-> 칼럼 | 솔직히 말하자, 프로젝트 후원자와 관리자가 문제다
-> 프로젝트 리더가 기억해야 할 '사람 우선' 전략 4가지
-> 프로젝트 관리·추적은 이렇게 '7가지 체험 팁'
-> "기대치 조율은 이렇게" 프로젝트 관리 11가지 팁
-> "온라인 협업과 프로젝트 관리에 그만!" 무료 툴 7선
-> 예산•일정•진척도 관리 도와줄 PM툴 5선
-> 폭포수 프로젝트 관리에도 민첩성이 필요하다
-> ‘에이스프로젝트 · 베이스캠프 · 조호 프로젝트’··· PM 툴 3종 비교분석
-> PM이 대비해야 할 흔한 프로젝트 문제 7가지
---------------------------------------------------------------

사양
위에 요건 문서의 맥락에 기재한 동일한 우수 사례가 기술 사양에도 그대로 적용된다. 다시 한 번 말하지만 사양을 미리 작성하고 합의하여 계약서에 포함해야 한다. 안타깝게도 그렇지 않고 프로젝트 초기 단계 중 계약 후에 사양을 작성하는 경우가 너무 많다. 이 접근방식을 피할 수 없는 경우 계약서에 당사자들 사이의 사양 작성 및 합의 방식과 시점 그리고 나머지 계약과의 상호작용 방식에 대해 명확히 확인해야 한다.

변경
계약서 서명 이후의 요건 및 사양 변경이 보편적이기 때문에 계약서에 적절한 변경 과정이 포함되어야 한다. 하지만 이런 과정을 포함하더라도 사전에 적절히 대비해야 한다. 범위 변경을 가능한 제한하는 것이 두 당사자 모두에 유리하다. 범위 변경은 지연, 비용, 논쟁으로 거의 모든 경우에 이어질 수밖에 없다.

시험 및 이행
계약서에 승인 시험, 보고, 이행 측면에서 당사자들의 의무를 명시해야 한다. 계약서 서명 후 세부 계획을 작성한다 하더라도 최소한 계약서에 합의된 방법론, 접근방식, 중요 단계를 명시해야 한다.

IT프로젝트는 거의 예외 없이 지연되기 때문에 당사자들은 현실적인 기간에 합의해야 한다. 고객들은 임의 요소로 프로젝트 기간을 제시해서는 안된다. CIO가 이사회에 프로젝트가 특정 일자까지 완료될 것이라고 말하거나 프로젝트 예산 문서에 측정 완료 일자를 가정했다는 이유만으로 프로젝트에 달성할 수 없는 기한을 할당하는 경우가 너무 많다. 마찬가지로 공급자는 계약을 수주하기 위해 달성할 수 없는 시간표에 맞춰 서명하지 않는다면, 계약 이후 험난한 과정을 방지할 수 있다. 공급자의 데이터와 분석을 기준으로 잡은 일정이 도저히 실현할 수 없다고 판단되는 경우 사전에 논의하는 것이 낫다. 현실적인 기한이 확인되면 당사자들은 경험을 토대로 지연이 발생할 가능성이 있음을 인정하고 어느 정도 불이행 가능성을 고려해야 한다.

또 공급자가 개발하는 기술이 참신하거나 필수적인 경우 고객은 적용하기에 앞서 제 3의 전문가에게 코드 감사/검증 의뢰를 생각해 볼 수 있다.

물론, IT프로젝트가 성공하지 못하는 다른 이유도 많지만 그 중 상당수는 커뮤니케이션, 프로젝트 관리, 거버넌스 실패와 관련되어 있다. 이런 주제의 경우 다른 계약에서 '잘라내어 붙이기'보다는 당사자들이 특정 프로젝트에 적절한 것을 신중하게 고려해야 한다. 실제로 효과가 없는 프로세스와 절차를 계약서에 넣을 이유는 없다.

*Sue McLean은 국제 로펌인 모리슨 앤 포스터(Morrison and Foerster)의 런던사무소 변호사다. ciokr@idg.co.kr
 



2016.10.18

'성공하는 IT프로젝트는 계약부터 다르다' 어떻게?

Sue McLean | Computerworld UK
IT프로젝트를 성공으로 이끄는 핵심 요건들은 많다. 흔히 협업 담당자 및 IT인력들 간의 원활한 커뮤니케이션과 경영진의 충분한 이해와 지원을 꼽을 것이다. 여기에 하나 더, 필자는 계약서 작성의 중요성에 대해 말하고자 한다. 


Credit: GettyImage

IT프로젝트에서 변호사의 역할은 두 가지다. 하나는 발주기업과 구축회사가 계약서를 제대로 작성했는지 돕는 것이다. 다른 하나는 잘못될 수 있는 것을 찾고, 실패 및 분쟁을 처리할 수 있는 적절한 메커니즘이 계약에 포함되도록 하는 것이다. 많은 기술 프로젝트가 실패한다는 증거가 있기 때문에 두 번째 역할이 특히 중요하다. 변호사는 프로젝트가 지연되거나 예산을 초과하거나 고객의 필요를 충족시키는 기술을 제공하지는 않는다.

그리고 일부 기술 프로젝트의 경우 최근 DAO(Decentralized Autonomous Organization) ‘해킹’에서 보았듯이 극적인 방식으로 실패하기도 한다.

DAO는 이데리움(Ethereum) 블록체인에서 운영되는 대표가 없는 투자 기관의 형태로, 2016년 5월 1억6,800만 달러를 모집하면서 역사상 가장 큰 규모의 크라우드펀딩 프로젝트 중 하나가 되었다.

하지만 출범 직후 DAO는 공격을 받고 6,000만 달러가 빠져나갔다. 여러 전문가들이 이 사건을 '해킹'으로 언급하는 것은 오해라고 말했다. 그들은 공격자가 코드의 디자인 결함을 악용했다고 지적했다. 그들은 이것이 보안 문제가 아닌 디자인 문제라고 주장했다. 요즘은 소프트웨어를 베타 형태로 공개한 이후에 결함을 수정하는 것이 일반적이다. 이런 민첩한 위험 기반의 개발 접근방식이 용인되는 경우가 많다. 하지만 DAO의 경우 엄청난 금액이 관련되어 있었으며 위험이 높은 전략이었던 것으로 보인다.

어쨌든 DAO 사건 덕분에 모든 조직들이 교훈을 얻게 되었다. 새로운 기술이라고 해서 디자인, 시험, 이행에 대한 기준을 완화해서는 안 된다는 것이다.

기업이 기술 개발을 위해 제 3자를 이용할 때 처음에 디자인, 개발, 이행에서 오류가 있을 수 있음을 신중하게 고려하고 계약을 통해 이런 위험을 적절히 예측하고 방어하도록 해야 한다. 실패 및 분쟁 처리를 위한 적절한 해결책을 계약에 포함하는 것 외에 발주회사와 구축기업 당사자들은 처음부터 이런 실패와 분쟁을 피하는 데 도움이 되는 계약서를 작성하는 것을 목표로 삼아야 한다. 주요 초점 영역으로는 요건, 사양, 시험, 이행이 있다.

요건
당사자들 간의 기대치가 일치하지 않거나, 고객의 요건이 너무 복잡하거나 너무 야심 차서 많은 프로젝트가 실패한다. 고객들은 충분한 시간을 갖고 미리 요건을 확인하되 필요한 모든 이해당사자와 사용자를 참여시켜야 한다. 고객들이 요건을 살펴보기도 전에 조달 과정을 시작하는 경우가 너무 많다. 아니면 명확히 달성 가능한 목표에 집중하는 게 아니라 필수 및 '틈새' 기능이 포함된 '쇼핑 목록'형 접근방식을 취한다.

일단 확인된 후 요건을 명확히 기술하는 것이 중요하다. 요건을 수용하기 어렵고 고객의 실제 필요를 파악하지 못하며 고객의 현업 이해당사자와 조언자 및 공급자를 혼동시킬 수 있기 때문에 기술 용어는 피해야 한다.

가능한 조기에 공급자와 요건을 공유해야 한다. 공급자는 계약 전 내용을 분석하고 상당한 주의를 기울여 고객의 요건을 확실히 파악해야 한다. 또한 이후의 분쟁을 방지하기 위해 이런 요건의 명확성 부재, 지나친 욕심 그리고/또는 불필요한 복잡성을 해결해야 한다.

그러고 나서 (필요에 따라 수정된) 요건을 계약서에 포함해 공급자가 계약상 이런 요건을 충족하는 기술을 제공하도록 해야 한다.

---------------------------------------------------------------
프로젝트 관리 인기기사
-> 칼럼 | 솔직히 말하자, 프로젝트 후원자와 관리자가 문제다
-> 프로젝트 리더가 기억해야 할 '사람 우선' 전략 4가지
-> 프로젝트 관리·추적은 이렇게 '7가지 체험 팁'
-> "기대치 조율은 이렇게" 프로젝트 관리 11가지 팁
-> "온라인 협업과 프로젝트 관리에 그만!" 무료 툴 7선
-> 예산•일정•진척도 관리 도와줄 PM툴 5선
-> 폭포수 프로젝트 관리에도 민첩성이 필요하다
-> ‘에이스프로젝트 · 베이스캠프 · 조호 프로젝트’··· PM 툴 3종 비교분석
-> PM이 대비해야 할 흔한 프로젝트 문제 7가지
---------------------------------------------------------------

사양
위에 요건 문서의 맥락에 기재한 동일한 우수 사례가 기술 사양에도 그대로 적용된다. 다시 한 번 말하지만 사양을 미리 작성하고 합의하여 계약서에 포함해야 한다. 안타깝게도 그렇지 않고 프로젝트 초기 단계 중 계약 후에 사양을 작성하는 경우가 너무 많다. 이 접근방식을 피할 수 없는 경우 계약서에 당사자들 사이의 사양 작성 및 합의 방식과 시점 그리고 나머지 계약과의 상호작용 방식에 대해 명확히 확인해야 한다.

변경
계약서 서명 이후의 요건 및 사양 변경이 보편적이기 때문에 계약서에 적절한 변경 과정이 포함되어야 한다. 하지만 이런 과정을 포함하더라도 사전에 적절히 대비해야 한다. 범위 변경을 가능한 제한하는 것이 두 당사자 모두에 유리하다. 범위 변경은 지연, 비용, 논쟁으로 거의 모든 경우에 이어질 수밖에 없다.

시험 및 이행
계약서에 승인 시험, 보고, 이행 측면에서 당사자들의 의무를 명시해야 한다. 계약서 서명 후 세부 계획을 작성한다 하더라도 최소한 계약서에 합의된 방법론, 접근방식, 중요 단계를 명시해야 한다.

IT프로젝트는 거의 예외 없이 지연되기 때문에 당사자들은 현실적인 기간에 합의해야 한다. 고객들은 임의 요소로 프로젝트 기간을 제시해서는 안된다. CIO가 이사회에 프로젝트가 특정 일자까지 완료될 것이라고 말하거나 프로젝트 예산 문서에 측정 완료 일자를 가정했다는 이유만으로 프로젝트에 달성할 수 없는 기한을 할당하는 경우가 너무 많다. 마찬가지로 공급자는 계약을 수주하기 위해 달성할 수 없는 시간표에 맞춰 서명하지 않는다면, 계약 이후 험난한 과정을 방지할 수 있다. 공급자의 데이터와 분석을 기준으로 잡은 일정이 도저히 실현할 수 없다고 판단되는 경우 사전에 논의하는 것이 낫다. 현실적인 기한이 확인되면 당사자들은 경험을 토대로 지연이 발생할 가능성이 있음을 인정하고 어느 정도 불이행 가능성을 고려해야 한다.

또 공급자가 개발하는 기술이 참신하거나 필수적인 경우 고객은 적용하기에 앞서 제 3의 전문가에게 코드 감사/검증 의뢰를 생각해 볼 수 있다.

물론, IT프로젝트가 성공하지 못하는 다른 이유도 많지만 그 중 상당수는 커뮤니케이션, 프로젝트 관리, 거버넌스 실패와 관련되어 있다. 이런 주제의 경우 다른 계약에서 '잘라내어 붙이기'보다는 당사자들이 특정 프로젝트에 적절한 것을 신중하게 고려해야 한다. 실제로 효과가 없는 프로세스와 절차를 계약서에 넣을 이유는 없다.

*Sue McLean은 국제 로펌인 모리슨 앤 포스터(Morrison and Foerster)의 런던사무소 변호사다. ciokr@idg.co.kr
 

X