견적 받을 때 아이디어를 어디까지 말해야 하나 — 계약 전 정보 보호와 NDA

견적 메일을 쓰다가 커서가 멈추는 지점이 있습니다. 두루뭉술하게 적으면 견적이 안 나올 것 같고, 자세히 적자니 이 문서가 세 군데 네 군데로 돌아다니게 됩니다. 아직 계약 전이라 뭐라 할 근거도 마땅치 않습니다. 그래서 문의를 다음 주로 미룹니다.

"아이디어를 보호받는다"는 표현은 제도가 실제로 작동하는 방식과 어긋나 있습니다.

저작권이 보호하는 것은 아이디어가 아니라 표현입니다. "동네 세차장 예약을 메신저로 받는 시스템"은 구상입니다. 저작권이 붙는 대상은 실제로 짜인 코드, 화면 구성, 문구처럼 형태를 갖춘 결과물입니다. 같은 구상을 듣고 다른 사람이 자기 코드를 짜면 그건 별개의 저작물이 됩니다.

영업비밀은 요건이 셋입니다. 공공연히 알려져 있지 않을 것, 독립된 경제적 가치가 있을 것, 비밀로 관리될 것. 세 번째가 실무에서 다투기 쉬운 요건입니다. 아무 표시 없이 올린 기획서, 링크만 알면 열리는 문서, 단체 대화방에 그냥 던진 파일은 비밀로 관리했다고 주장할 근거가 약합니다. 대외비 표시를 하고 열람 권한을 제한하고 누구에게 언제 줬는지 기록을 남기면 그 근거가 생깁니다. 여기까지는 평소 파일 관리 습관 수준에서 할 수 있습니다.

견적 단계를 직접 겨냥한 조항도 있습니다. 부정경쟁방지법에는 사업 제안이나 입찰 같은 거래 교섭 과정에서 받은 아이디어를 제공 목적에 반해 자기 이익에 쓰는 행위를 부정경쟁행위로 보는 조항이 2018년에 들어왔습니다. 다만 단서가 붙습니다. 제공받을 당시 이미 알고 있었거나 동종 업계에 널리 알려진 아이디어는 빠집니다. "이런 서비스를 만들고 싶다" 정도로 적어 보낸 구상이라면 이 단서에 걸릴 수 있습니다. 조항이 힘을 받는 쪽은 그 업계 사람도 모르던 구체적인 방식을 문서로 넘긴 경우입니다. 특정한 계산 규칙, 처리 순서, 오래 다듬은 판정 기준 같은 것들입니다.

그래서 견적 단계에서 손에 잡히는 대책은 순서입니다. 무엇을 먼저 말하고 무엇을 뒤로 미룰지 정해 두면, NDA 한 장을 받아내는 것보다 실제로 넘어가는 정보량이 줄어듭니다.

견적을 내는 쪽이 먼저 확인하는 건 데이터가 어디서 어떤 형태로 들어오는지, 예외가 몇 갈래인지, 붙일 외부 서비스가 몇 개인지입니다. 무슨 사업인지는 이 셋을 통해서만 금액에 반영됩니다. 회원 500명짜리 학원 관리와 회원 500명짜리 헬스장 관리는 업종이 달라도 화면 수와 규칙 수가 비슷하면 금액도 비슷한 자리에 놓입니다.

왼쪽 항목만으로도 구간 견적은 나옵니다. 오른쪽은 계약 후 작업에 필요한 정보입니다. 실제 고객 명단은 데이터를 옮겨올 때 필요하고, 연동 키는 붙이는 날 필요하고, 단가 산식의 실제 값은 화면을 채울 때 필요합니다. 견적서를 쓰는 시점에는 그 자리에 "규칙 세 종류" 같은 개수만 있으면 공수가 계산됩니다.

치환해서 쓰면 됩니다. "거래처 15곳의 단가표를 넣어 자동 계산"이라고 쓸 자리에 "거래처 10~20곳, 거래처마다 단가가 다름, 계산 규칙 세 종류"라고 적으면 공수 산정에 쓰이는 정보는 그대로 남고 넘어가는 내용만 줄어듭니다. 브랜드도 같은 방식입니다. 미출시 서비스명을 그대로 적는 자리에 "B2C 예약 서비스"라고만 적어도 견적 작업에는 지장이 없습니다. 화면 캡처를 붙일 때는 실제 고객명과 금액이 그대로 찍혀 있지 않은지 한 번 보세요.

아끼면 견적이 안 나오는 항목이 하나 있습니다. 데이터의 실제 형태입니다. "엑셀로 받습니다"와 "거래처마다 양식이 다른 엑셀을 매달 수십 개 받습니다"는 작업 자체가 달라집니다. 앞은 파일 하나를 읽어 넣으면 되고, 뒤에는 양식 판별과 예외 처리와 사람이 확인하는 화면이 붙습니다. 양식이 제각각이라는 사실 자체는 비밀이 아니니 이건 먼저 말하는 편이 낫습니다. 견적을 받고 난 뒤에 이 사실이 드러나면 금액이 다시 올라가는데, 그 시점에는 이미 다른 업체와의 비교 기준이 흐트러진 뒤입니다.

비밀정보 정의가 "본 건과 관련하여 알게 된 일체의 정보" 한 줄로 끝나 있다면, 다툼이 붙었을 때 무엇이 비밀정보였는지 특정하는 데서 막힙니다. 넓게 적을수록 강해 보이지만 판단하는 쪽에는 범위를 잡을 기준이 없습니다. 조항을 늘린다고 실효가 생기지도 않습니다. 아래 네 가지가 들어 있느냐로 갈립니다.

첫째는 대상 특정입니다. 대외비 표시를 한 서면, 구두로 말한 뒤 며칠 안에 서면으로 확인한 내용처럼 판별 기준이 있어야 합니다. 회의에서 말로 흘린 내용까지 비밀정보로 넣고 싶다면 그 확인 절차를 조항에 적어 두어야 나중에 주장할 수 있습니다.

다음은 목적 외 사용 금지입니다. 누설 금지만 적힌 NDA라면 제3자에게 넘기지 않고 자기가 쓰는 행위는 조항에 걸리지 않습니다. 견적 단계에서 걱정하는 게 정확히 그 행위입니다. "제공 목적 외의 용도로 사용하지 아니한다"는 한 줄이 있어야 여기까지 덮입니다.

파기 시점도 봐야 합니다. 견적만 받고 계약이 안 됐을 때 넘긴 자료를 어떻게 할지가 적혀 있는지 확인하세요. 계약 체결을 전제로 쓰인 양식은 이 경우를 다루지 않고 끝나기도 합니다. 파기 기한과 파기 사실 통지까지 넣어야 실제로 실행됩니다.

마지막은 위반했을 때 무엇을 하느냐입니다. 비밀 유출은 손해액 입증이 까다로워서 배상 예정액을 미리 정해두기도 합니다. 다만 예정액이 부당히 과다하면 법원이 감액할 수 있으니, 겁주는 숫자보다 프로젝트 금액에 비춰 설명이 되는 금액이 낫습니다.

규모도 맞춰야 합니다. 수십만 원짜리 반복 업무 자동화 문의에 다섯 장짜리 NDA부터 보내면 규모에 비해 절차가 무겁습니다. 이럴 땐 문서 첫 장의 대외비 표시와, 메일 본문의 "본 자료는 견적 산정 목적으로만 사용해 주십시오" 한 줄로 시작해도 비밀로 관리했다는 근거는 남습니다. NDA는 상세 자료를 넘기는 2차 단계에서 꺼내도 늦지 않습니다.

서너 곳에 견적을 돌리는 건 정상적인 비교 절차입니다. 다만 전부에게 같은 상세본을 주면 노출 면적이 업체 수만큼 늘어납니다. 계약은 한 곳과 하고, 나머지 업체의 메일함과 서버에는 상세본이 그대로 남습니다.

2단으로 나누세요. 1차는 요약본 한 장입니다. 만들 것 한 문단, 기능 목록, 데이터 규모 구간, 연동 대상, 희망 시점, 예산 구간. 저희가 받는 문의 기준으로는 여기까지면 구간 견적이 나옵니다. 2차에서 후보를 두세 곳으로 줄인 뒤 NDA를 주고받고 상세 자료를 넘깁니다.

요약본만으로는 못 내겠다는 답이 오면 무엇이 더 필요한지 되물어 보세요. "예외 케이스가 몇 가지인지", "기존 데이터를 옮겨와야 하는지"처럼 되묻는 항목이 구체적이면 그 업체에는 상세본을 줄 만합니다. 질문 없이 "일단 전부 보내주세요"만 오면 판단할 근거가 없습니다. 이 되묻기는 노출을 줄이는 절차이면서 업체를 거르는 절차이기도 합니다. 어차피 계약 후에 요구사항 정리를 같이 해야 하는데, 그 대화가 되는 곳인지 미리 확인하는 셈입니다.

문서 관리는 두 가지면 됩니다. 첫 장에 대외비 표시와 작성일, 수신처를 적으세요. 업체마다 수신처를 다르게 적어 두면 자료가 돌아다닐 때 어디서 나갔는지 추적할 단서가 남습니다. 표지를 떼고 내용만 옮기면 거기까지는 못 잡지만, 파일이 통째로 도는 경우에는 확인이 됩니다. 그리고 메일은 개별 발송하세요. 참조에 여러 업체를 묶으면 경쟁 업체끼리 서로의 존재와 주소를 알게 됩니다. 숨은참조도 답장 과정에서 드러나는 일이 있으니 그냥 따로 보내는 편이 낫습니다.

이 항목은 견적을 받는 쪽 시선으로 적습니다.

개발사가 남의 사업 구상을 직접 운영하려면 영업, 고객 응대, 운전자금이 새로 필요합니다. 개발과는 다른 업종이고, 개발 인력으로 구성된 조직이 그 업종으로 옮겨 가는 일은 구조적으로 잘 굴러가지 않습니다. 구상 자체를 통째로 가져가 실행하는 그림은 이 구조 때문에 성립하기 어렵습니다.

이어서 실제로 다툼이 생기는 지점을 적습니다. 하나는 코드 재사용입니다. 하나는 코드 재사용입니다. 앞 프로젝트의 모듈을 다음 고객 프로젝트에 넣는 일 자체는 개발에서 정상적인 방식입니다. 로그인, 권한 관리, 파일 업로드처럼 어디에나 들어가는 부분을 매번 새로 짜면 기간과 비용만 늘어납니다. 선이 걸리는 지점은 발주자의 업무 규칙이 녹아 있는 부분입니다. 가격 산정 규칙, 배차 순서, 재고 차감 로직, 등급 판정 기준처럼 그 회사가 오래 다듬어 온 것들입니다. 이 부분이 넘어가면 경쟁사가 같은 규칙으로 돌아가는 시스템을 갖게 됩니다.

다른 하나는 데이터입니다. 테스트용으로 넘긴 고객 명단이나 거래 내역은 검수가 끝났다고 자동으로 지워지지 않습니다. 개발사 노트북, 개발 서버, 스테이징 DB, 백업본까지 따로 지워야 없어집니다. 고의로 남기는 것과 정리를 안 해서 남는 것은 결과가 같습니다. 그래서 파기 조항은 대상을 "제공한 데이터 및 그 사본"으로 적고 개발 서버와 백업까지 포함한다고 못 박아 두는 편이 낫습니다. 애초에 실데이터 대신 가명 처리한 표본을 주는 방법도 있습니다. 이름과 연락처를 바꿔 놓아도 자릿수, 형식, 예외 케이스는 그대로 남아서 개발과 테스트에는 지장이 없습니다.

발주자에게 불리한 말도 하겠습니다. "일체의 코드 재사용 금지"를 요구하면 견적이 올라갑니다. 로그인, 권한 관리, 결제 연동처럼 어디에나 들어가는 부분까지 새로 짜야 하기 때문입니다. 범용 모듈과 오픈소스를 제외하고 우리 업무 규칙이 들어간 부분으로 범위를 좁히면, 견적을 올리지 않고도 걱정하던 지점을 막습니다.

아래 문장을 기준 삼아 기간만 채우면 초안이 됩니다. 금액대가 크거나 개인정보가 오가는 건이면 서명 전에 변호사 검토를 한 번 거치는 편이 낫습니다.

목적 외 사용 금지 — "을은 본 계약의 이행 목적 외의 용도로 갑이 제공한 정보를 사용하거나 제3자에게 제공하지 아니한다."

비밀정보의 특정 — "비밀정보란 갑이 대외비 표시를 하여 서면 또는 전자문서로 제공한 자료와, 구두로 제공한 후 ○일 이내에 서면으로 비밀임을 통지한 정보를 말한다."

업무 규칙 재사용 제한 — "을은 본 프로젝트에서 갑의 업무 규칙을 반영하여 개발한 부분을 타 고객사 프로젝트에 사용하지 아니한다. 다만 을이 본 계약 체결 이전부터 보유한 범용 모듈 및 오픈소스는 제외한다."

자료 파기 — "을은 검수 완료 또는 계약 해지일로부터 ○일 이내에 갑이 제공한 데이터 및 그 사본을 개발 서버와 백업본을 포함하여 파기하고 그 결과를 서면으로 통지한다."

견적 단계에서 확인할 것들입니다.

판단이 안 서면 요약본 한 장만 보내고 무엇이 더 필요한지 되물어도 됩니다. 저희도 그 순서로 견적을 냅니다.