brunch

매거진 PM의 일상

라이킷 16 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 진용진 Jul 26. 2020

기획자의 일 - 계약

IT비즈니스의 계약 업무 이해하기

계약 업무는 대부분 기획자에게 해당하는 업무는 아닙니다. 기업에 따라서 기획자가 직접 계약 업무를 담당하기도 하고, 혹은 별도의 제휴 담당자가 존재해서 해당 업무를 대응할 것입니다.

제가 이 글에서 ‘계약'이라 표현하지만, 계약은 큰 틀에서 협상 프로세스 중의 일부입니다. 협상의 완결은 계약서란 형태가 될 것입니다. 그리고 궁금적으로 해당 계약서를 기반으로 계약 당사자가 어떤 형태의 사업개발(예: 콘텐츠 소싱, 제휴 서비스, 공동 마케팅 등)을 하는 것이 목표입니다.

# 기획자가 만날 계약 업무들

IT 기업의 기획자가 맺는 상당수의 계약은 아래와 같은 형태가 다수입니다. 이 밖에도 다양한 형태의 계약이 존재하지만, 큰 틀에서 이와 같은 형태가 다수입니다.

데이터 및 콘텐츠 소싱 계약

계약 당사자 중에서 A가 B에게 콘텐츠를 제공하고, B는 해당 콘텐츠를 자사 서비스에 활용하는 형태입니다. B는 서비스 활용 댓가로 A에게 상응하는 가치를 제공해야 합니다(예: 콘텐츠 사용료, 수익 배분, 트래픽 바터 등)

제휴 마케팅

양사가 각자 진행했을 때보다 더 높은 가치를 기대하고 진행하는 마케팅입니다. 예를 들면 스타트업A가 자사만이 확보하고 있는 콘텐츠(예: 이용권)을 포털기업 B에게 제공하고, 포털기업 B는 자사 서비스의 컨셉에 맞는 제휴 마케팅을 스타트업A사의 경품을 걸고 진행하는 형태입니다.

또는 크로스 마케팅이란 형태로 양사가 보유하고 있는 인벤토리(서비스 영역)을 기반으로 상대방 서비스를 홍보하는 형태도 존재합니다. 과거 스타트업이 많이 이러한 형태의 마케팅을 많이 진행했고, 이를 전문으로 하는 마케팅 플랫폼도 존재하는 것으로 알고 있습니다.

아웃소싱 계약

아웃소싱 계약은 가장 계약 형태가 표준화되었고, 각 기업별로 구매팀에서 관련된 명확한 가이드를 가지고 있는 경우가 대부분입니다. 예시로는 머신러닝을 위한 전처리 과정을 아웃소싱을 맡기거나, 혹은 자사에서 직접 인력을 갖추어 운영하는 것보다 낮은 비용으로 수급이 가능한 데이터 수급을 업무가 이에 해당합니다. 또는 소프트웨어 기업이 스마트 스피커처럼 기존에 보유하지 않은 역량의 사업에 진출할 때, 관련 하드웨어 개발을 아웃소싱을 맡길 수도 있습니다. 아웃소싱 계약에서 가장 주의할 점은 개인적 친분을 내세워 혹은 일정을 단축하기 위해 '갑'인 기업이 '을'에게 선발주, 즉 아웃소싱 계약 체결 전에 업무를 시키는 경우가 있습니다. 이는 부당거래에 해당하기 때문에 엄격하기 금지되어야 할 사항입니다.

체결하는 계약 형태에 따라 기획자로서 챙겨해야할 사항들이 다르지만, 저는 이번 글에서 일반적으로 챙겨야할 계약 포인트와 이와 관련된 절차를 설명하려 합니다.

# 계약 업무 절차

계약서 용어가 주는 무게감 때문에 계약 업무 자체를 두려워했던 기획자 분들을 뵙던 것 같습니다. 보통은 계약이라는 단어가 주는 책임감과 전반적인 절차를 경험해보시지 못했기 때문에 생기는 두려움 같습니다. 저는 이런 분들께 계약의 주요 요구사항이 중요하고, 계약 주요 조건들은 기획자 뿐만 아니라 동료 및 법무 담당자도 함께 검토하기 때문에 모든 것을 책임진다는 부담감은 덜어내시라고 말씀을 드린 적이 있습니다 (물론 이를 법무팀이 다 책임진다로 이해할 수 있는 오해도 있지만...)

계약의 일반적인 절차는 아래와 같습니다.

① 계약 요구사항 협의

서로 협력의 니즈가 있는 기업들이 서로 교류합니다. 2개 기업일 수 있고, 3개 이상일 수도 있습니다. 개인적인 경험으로 3자 이상 넘어가면 서로 이해관계가 복잡해져서, 가능하면 양자 계약 틀 안에 다른 3자가 참여하는 형태가 되는 것을 지향하긴 합니다. 계약 요구사항 협의가 가장 중요한 단계이며, 협상 과정에서 요구사항의 범위가 구체적일 수록 이 후 진행과정이 원활합니다. 요구사항이 모호하게 협의된 상태에서 계약서 검토 단계로 넘어가면, 요구사항을 다시 계약서에 업데이트하고 이를 다시 양사 법무팀이 검토하는 과정에서 상당히 많은 시간과 에너지가 소비됩니다. 만일 초반에 요구사항이 잘 협의되면, 이후 양사 법무팀의 검토과정에서 법률적 해석에 대한 용어 및 주요 권리/의무 관게에 대한 범위로 한정해서 협의하기 때문에 일처리가 빨라집니다.

② NDA (비밀 유지 계약)

제가 NDA를 ② 번으로 별도로 뺐지만, NDA는 위에서 언급드린 ①번 계약 요구사항 단계에서 진행되는 계약 절차입니다. 어떤 기업의 경우 NDA가 계약이냐고 물어보시는 분도 있지만, NDA도 엄밀히 양사가 날인(법인 인감 도장)하는 계약입니다. 서로 협력의 니즈가 있는 양사가 몇 번의 미팅을 하고, 구체적인 협력으로 논의가 발전될 것으로 판단되면 일반적으로 NDA를 체결합니다. 물론 본 계약에서 비밀 유지 조항이 포함되어 있지만, 본 계약이 체결되지 않는 경우가 다수이기 때문에 상호 기밀정보를 외부 업체 또는 언론에 공유될 리스크를 줄이기 위해 NDA 체결은 필수입니다.

③ 텀시트(term sheet)

계약서에 들어갈 주요 조건에 대해여 양 사 담당자가 서로의 요구사항을 구체적인 용어로 의견을 주고 받는 단계입니다. 계약기간, 양사의 책임과 의무, 저작권, 비용 등의 조건에 대하여 의견을 주고 받는 단계입니다. 예를 들면 엑셀과 같은 시트를 통해 주요 조건에 대해 양사 담당자가 상호 코멘트를 주고 받는 방식을 상상할 수 있을 것 같습니다. 이 단계에서 양사 법무 담당자가 참여하는 경우도 있고, 법무 담당자 참여 없이 기획자가 직접 요구사항에 대한 의견을 줄 수 있습니다. 여기서 제가 법무 담당자 참여가 없는 경우를 언급드린 것은 텀시트 자체가 계약적 구속성이 없다는 것을 강조하기 위해서 입니다. 물론 이러한 계약 논의 히스토리는 계약 체결 후, 계약 파기와 관련된 절차에서 자료로 활용될 수 있긴 합니다...

④ 계약서 초안 전달 및 날인

이제 양사의 요구사항이 어느 정도 정리되면 계약서를 본격적으로 작성하는 단계입니다. 보통 특정한 기업이 초안을 먼저 작성합니다. 대부분 큰 기업이 초안을 먼저 작성하고, 스타트업이 해당 초안을 검토하고 의견을 전달하여 업데이트하는 구조입니다. 하지만 개인적으로 스타트업에게 이런 방식으로 일할 것을 권장드리지 않습니다. 아무래도 초안을 작성하는 측이 본인에게 유리한 각종 법률적 장치를 넣기 때문에 이후 계약서 수정 작업에서 초안을 작성한 기업의 의도와 프레임에 따라 변경하는 작업이 진행될 수 밖에 없습니다.

이밖에 기획자 입장에서 계약서 초안은 어떻게 작성하는지 궁금하신 분들이 많으실 것 같습니다. 일부 대기업은 기획자가 요구사항을 전달하면 법무팀에서 초안을 다 작성해주는 경우도 있지만, 대부분 기업들은 표준계약서라는 것이 존재합니다. 표준 계약에 대부분 법률적 용어가 정의되어 있고, 본인이 진행하는 사업개발에 맞춰 양사의 R&R 및 계약 기간 및 종료 조건, 저작권과 관련된 부분을 수정하면 됩니다.

계약 초안이 작성되고, 양사가 주요 조건에 대해 수정하는 절차를 진행할 것입니다. 대기업은 법무팀이 기획자에게 의견을 전달할 것이고, 스타트업은 외부 법무법인이 관련해서 의견을 전달할 것입니다. 이렇게 양 사가 계약서 내용에 대해 합의가 완료되면 날인 절차를 진행하게 됩니다.

날인 절차는 양사의 법인 인감을 찍어 본 계약이 효력이 있다는 것을 증명하는 것입니다. 그리고 계약서가 여러 장일 경우 '간인'이란 것을 통해 두 장의 문서에 걸쳐 법인 인감 도장을 찍습니다. 요즘은 전자 서명 방식이 확산되기 때문에 이러한 날인 절차도 변경될 것으로 예상됩니다. 그리고 외국계 기업과 전자 서명을 진행할 때, 외국계 기업은 책임자의 서명으로 전자 서명을 진행할 경우가 있습니다. 국내 기업은 대표의 서명 또는 법인인감을 유효한 것으로 내부 프로세스를 잡는 경우가 많지만, 해외기업은 주요 임원 또는 책임자의 서명으로 이러한 계약 날인을 진행하니 참고하시면 좋을 것 같습니다.

# 계약 검토 주요 사항

계약에서 주요하게 검토할 사항에 대해 설명드리겠습니다. 아마도 계약 업무를 담당한 기획자는 어떻게든 해당 계약을 체결하고 싶은 마음이 클 것입니다. 하지만 계약 주요 조건에 대해 구체적으로 검토하지 못했을 경우에 계약 체결 후 곤란한 상황을 겪을 수 있습니다. 아래는 몇 가지 주요 포인트를 설명드립니다.

① 계약기간

계약기간? 그냥 계약 시작일과 종료일을 정하면 되는 것이 아닌가? 라고 생각하시는 분들께서 많으실 것입니다. 하지만 계약 당사가가 장기적 관계를 고려하고 있다면 계약기간 관련해서 서로 구체적으로 논의하는 것이 필요합니다. 계약 기간과 고려할 사항들은 아래와 같은 범위들이 있습니다.

자동연장, 재계약, 계약종료, 계약종료 후 대응

자동연장이 중요한 이유는 만일에 비용지급이 이루어지는 계약의 경우에 자동연장에 따라 양사 별도 협의 없이 기존 조건 그대로 계약 연장이 이뤄지기 때문입니다. 만일 콘텐츠 소싱의 계약의 경우 B사가 A사에게 콘텐츠를 제공하고 일정 금액을 받기로 계약이 되었는데, A사의 요구사항 혹은 서비스 성장에 따라 B사에서 해당 콘텐츠 소싱을 위한 추가 리소스(인력 및 설비) 투입이 필요한 경우 자동연장이 이뤄지기 전에 재계약과 관련되어 추가 비용 지급에 대한 협상을 요청할 수 있는 구조의 조항을 넣어야 합니다.

보통 자동연장 계약 조항은 양사가 별도 협의가 없으면 1년씩 연장되는 경우가 일반적입니다. 대기업 입장에서 이러한 자동연장이 계약종료 시점에 매번 계약조건을 협의하지 않고, 기존 조건대로 갱신할 수 있어 유리하기 때문일 것입니다.

재계약과 계약종료는 보통 계약종료 전에 몇 개월 이전부터 양사가 협의를 시작하는 것으로 명시합니다. 여기서 주의할 점은 계약 양방의 협의인지 일방의 협의인지 여부입니다. 계약 종료가 계약 체결한 양 당사자 합의가 조건이라면, 계약을 종료하고 싶어도 상대방이 협의해주지 않으면 자동으로 계약이 연장되거나 계약 종료를 위한 별도 손해배상을 대응해야 합니다. 혹은 계약종료 조건이 일방 통지에 따라 명시되어 있다면 재계약 관련해서 특정 당사자의 이해관계에 끌려갈 수 밖에 없습니다.

이밖에 계약종료 후 대응은 계약 종료 후에도 유지보수 및 서비스 품질에 대해 일정 기간 품질을 보장한다는 조항이다. 제휴 서비스 같은 경우에 이미 사용자에게 해당 서비스가 배포된 상태이기 때문에 서비스 종료 후 C/S에 대해 일정 기간의 버퍼가 필요하기 때문입니다.

② 당사자의 책임과 의무

계약 이해관계자의 R&R을 정의하는 것입니다. 만일에 콘텐츠 제공 계약이라면, 해당 콘텐츠를 API로 제공할 것인지 파일 형태로 납품할 것인지 정의해야합니다. 그리고 해당 콘텐츠를 제공하는 측에서 관련 제공 방식에 대한 품질, 데이터 갱신주기 및 장애에 대한 책임과 의무를 정의해야합니다. 반대로 해당 콘텐츠를 받는 업체 측은 해당 콘텐츠를 서비스의 어떤 영역에서 활용할 것인지, 얼만큼의 빈도(API 호출수, 데이터 수집 주기 등)로 사용할 것인지 정해야합니다.

이밖에 사용자 C/S가 발생했을 경우에 이에 대한 대응을 어떤 프로세스로 진행할 것인지 사전에 협의되어야할 것입니다.

③ 저작권

예를 들면 A라는 기업이 B라는 기업에게 본인들이 촬영한 사진 데이터를 제공한다고 가정할 수 있습니다. 이때 A라는 기업은 1차 결과물인 사진 데이터에 대한 저작권을 주장할 수 있습니다. 그리고 B가 해당 사진 데이터를 통해 만들어낸 인사이트, 예를 들면 B서비스의 사용자는 이러한 유형의 사진을 좋아한다는 2차 결과물에 대해서는 B사의 저작권으로 인정하는 계약을 체결할 수 있습니다.

# 마지막으로

계약은 글 초반에 밝혔듯이 협상의 일부이다. 양사의 요구사항과 이와 관련된 좋은 결과를 이끌어내는 것이 중요하고, 계약서는 이에 대한 후속 절차로 중요한 결과물인 것입니다.

보통 계약은 계약 당사자가 윈윈하는 구조를 지향합니다. 하지만 실제 계약 업무를 진행하면 한쪽이 일부 양보를 해야하는 경우가 다수입니다. 보통은 해당 계약이 간절한 쪽이 양보하는 구조입니다. 하지만 규모가 큰 회사가 가진 자의 여유를 보여주기 보다 일정 부분에 있어 계약조건을 양보하는 자세도 필요하지 않을까 싶습니다. 규모가 작은 스타트업은 계약 협상 과정에 투입되는 리소스 자체가 큰 비용이기 때문일 것입니다.

마지막으로 기획자는 계약업무에 대해 블랙박스처럼 일하고 싶은 유혹이 있을 수 있습니다. 물론 대부분 회사들이 이를 절차적으로 보완하고 있습니다. 그럼에도 불구하고 딜(deal)을 만들겠다는 욕심으로 딜 구조(deal structure)를 투명하게 내부에 공유하지 않고 진행하는 경우도 있습니다. 물론 딜 자체가 보안 유지가 필요한 경우도 있지만, 충분한 논의를 거치지 않은 계약은 그에 따른 후속 댓가가 클 가능성이 높습니다.

이미지 출처: https://pxhere.com/ko/photo/1436407

keyword