자동매매 봇을 맡길 때, 소스코드는 누구 것인가 — 소유권·에스크로·독소조항 완전 가이드

자동매매 외주에서 사람들이 가장 무서워하는 사고는 "선입금하고 잠수 타는 것"입니다. 그런데 실무에서 더 자주, 더 조용히 사람을 곤란하게 만드는 건 따로 있습니다. 바로 "돈 다 냈는데, 정작 그 봇의 소스코드가 내 것이 아니었다"는 뒤늦은 깨달음입니다. 봇은 잘 돌아가는데 고칠 수도, 남에게 넘길 수도, 회수할 수도 없는 상황 — 이건 사기보다 알아차리기 어렵고, 알아차렸을 땐 이미 늦습니다. 이 글은 코딩을 모르는 의뢰인의 눈높이에서 소스코드 소유권이 원래 누구 것인지 · 계약서의 어떤 문장을 봐야 하는지 · 소프트웨어 임치(에스크로)가 언제 필요한지 · 그리고 계약을 망치는 독소조항이 무엇인지를 하나씩 풀어냅니다.

1. 왜 '소스코드 소유권'이 계약에서 가장 조용한 지뢰인가

자동매매 봇은 한 번 만들고 끝나는 물건이 아닙니다. 살아 있는 동안 반드시 손을 대야 하는 순간이 옵니다. 거래소가 API 정책을 바꿔 어제까지 멀쩡하던 봇이 멈추기도 하고, 전략을 조금 손보고 싶어지기도 하고, 알림 하나를 추가하고 싶어지기도 합니다. 그때 필요한 게 바로 소스코드입니다. 소스코드가 손에 없으면, 이 모든 순간마다 원제작자에게 매달릴 수밖에 없습니다.

문제는 이 종속이 처음엔 전혀 불편하지 않다는 데 있습니다. 봇이 잘 돌아가는 초반에는 소스코드가 누구 것인지 아무도 신경 쓰지 않습니다. 그러다 6개월, 1년이 지나 정작 코드가 필요해지는 순간 — 제작자가 다른 일로 바빠 답이 늦거나, 연락이 끊기거나, 사업을 접었거나, 또는 "그건 추가 비용입니다"라며 부르는 값이 달라졌을 때 — 비로소 "아, 내가 이 코드에 대해 아무 권리가 없구나"를 깨닫습니다. 선입금 잠수 사기는 며칠이면 알지만, 소유권 문제는 몇 달 뒤에야 정체를 드러냅니다.

이 주제는 외주 의뢰 전 27가지 체크리스트에서 계약·법무 항목의 하나로 짧게 다뤘습니다. 이번 글은 그중 소스코드·저작권·임치 하나만 떼어 깊이 파고듭니다. 체크리스트가 '전체 지도'라면, 이 글은 그 지도에서 가장 사고가 잦은 교차로 하나를 확대한 지형도입니다.

2. 실행파일 vs 소스코드 — 완성 요리와 레시피의 차이

먼저 용어부터 편하게 정리합시다. 자동매매 봇을 납품받을 때 손에 쥐게 되는 것은 크게 두 가지입니다.

비유하자면 실행파일은 식당에서 받은 완성된 요리이고, 소스코드는 그 요리의 레시피입니다. 요리만 받으면 오늘 저녁은 먹을 수 있습니다. 하지만 간을 조금 바꾸거나, 재료가 떨어져 대체하거나, 다른 주방에서 똑같이 만들고 싶을 때는 레시피가 없으면 아무것도 못 합니다. 그때마다 원래 요리사를 찾아가야 하고, 그 요리사가 사라지면 그 맛은 영영 재현할 수 없습니다.

자동매매 봇에서 "손을 대야 하는 순간"은 옵션이 아니라 필연입니다. 특히 거래소·증권사 API는 주기적으로 바뀝니다. 봇이 멈추는 대표적 원인과 복구 흐름은 봇 장애·복구 플레이북에서 자세히 다뤘는데, 그 복구의 상당수가 "소스코드를 열어 고치는 일"입니다. 그래서 장기 운영을 염두에 둔다면, 실행파일만으로는 부족하고 레시피(소스코드)에 대한 권리를 어떤 형태로든 확보해 둬야 합니다.

3. 돈을 냈으면 코드도 내 것? — 저작권이 원래 향하는 곳

여기서 대부분의 의뢰인이 오해하는 지점이 나옵니다. "내가 돈 주고 만들라고 했으니 당연히 내 것 아닌가?" — 직관적으로는 맞는 말 같지만, 저작권의 세계에서는 그렇게 단순하지 않습니다.

한국 저작권법의 큰 원칙은 이렇습니다. 프로그램을 포함한 저작물의 권리는 원칙적으로 그것을 실제로 '창작한 사람'에게 먼저(원시적으로) 생깁니다. 즉 봇을 코딩한 개발자·제작사에게 권리가 먼저 발생합니다. 의뢰인이 제작을 부탁하고 대금을 지급한 것(이른바 도급)은 "결과물을 만들어 달라"는 계약이지, 그 자체로 "코드의 저작권까지 넘긴다"는 뜻이 자동으로 되는 것은 아닙니다.

그래서 실무에서 갈리는 세 가지 개념을 구분하는 게 중요합니다. 사용권(그 봇을 돌려 매매할 권리), 소스코드 인도(코드 파일을 실제로 건네받는 것), 그리고 저작권 양도(그 코드를 수정·복제·양도·2차 활용할 권리 자체를 넘겨받는 것)는 서로 다른 별개의 것입니다. 코드 파일을 받았다고 저작권까지 넘어온 것은 아니고, 사용해도 된다고 해서 마음대로 남에게 팔 수 있는 것도 아닙니다.

양도해도 '전부 내 것'이 되지는 않는 부분 — 공용·오픈소스

한 가지 현실적인 뉘앙스를 더 알아두면 좋습니다. 저작권을 양도받아도, 봇을 이루는 모든 조각이 100% 내 독점 소유가 되는 것은 아닙니다. 요즘의 프로그램은 대개 공개된 오픈소스 라이브러리(누구나 쓰도록 배포된 부품)를 조립해 만듭니다. 이런 부품은 애초에 제작사의 것이 아니라 세상에 공개된 공용 재료이므로, 제작사가 나에게 '양도'할 수 있는 대상이 아닙니다. 다만 이건 문제가 아니라 정상입니다 — 오픈소스는 각자의 이용 조건(라이선스) 안에서 자유롭게 쓸 수 있으니까요.

그래서 정확한 그림은 이렇습니다. "제작사가 새로 창작한 고유한 부분(내 전략·로직)의 권리는 나에게 양도되고, 공용 부품은 각 오픈소스의 이용 조건을 따른다." 실무에서 이 구분이 문제가 되는 경우는 드물지만, 상업적으로 크게 배포·재판매할 계획이 있다면 "이 봇에 쓰인 오픈소스와 그 이용 조건 목록"을 함께 받아두는 게 안전합니다. 이 목록은 뒤(8장)에서 말할 의존성 목록과도 겹칩니다.

4. 소유의 세 가지 형태 — 양도 · 라이선스 · 운영위탁

현실의 자동매매 외주 계약은 대개 다음 세 가지 형태 중 하나로 정리됩니다. 어느 것이 '정답'은 아니고, 봇을 얼마나 오래·독립적으로 운영할지에 따라 맞는 형태가 다릅니다.

① 저작권 양도 — 코드도 권리도 온전히 내 것

가장 강한 형태입니다. 계약서에 "제작된 프로그램의 저작권과 소스코드 일체를 대금 완납 시 의뢰인에게 양도한다"는 취지가 담기면, 이후로는 그 코드를 누구에게 맡겨 수정하든, 다른 개발자에게 넘겨 유지보수를 받든 내 자유가 됩니다. 봇을 오래, 독립적으로 굴리고 싶고, 나중에 제작사와의 관계가 어떻게 되든 흔들리고 싶지 않다면 이 형태가 가장 안전합니다. 대신 제작사 입장에서는 핵심 자산을 통째로 넘기는 것이라, 견적이 다소 올라갈 수 있습니다. 그건 부당한 게 아니라 합리적인 가격 반영일 수 있습니다.

② 소스 인도 + 라이선스 — 코드는 받되 활용에 선을 긋는다

중간 형태입니다. 소스코드 파일 자체는 인도받아 수정·유지보수는 할 수 있지만, "이 코드를 제3자에게 재판매하거나 상업적으로 배포하지 않는다" 같은 조건이 붙습니다. 내가 내 봇을 고쳐 쓰는 데는 문제가 없되, 그걸 상품으로 되파는 것은 막는 것이죠. 개인이 자기 매매에 쓸 목적이라면 이 형태로도 실무상 충분한 경우가 많습니다. 다만 "수정 가능 범위", "다른 개발자에게 맡겨도 되는지"를 명확히 해두는 게 좋습니다.

③ 운영위탁 — 코드는 제작사가 갖고, 나는 결과만 쓴다

제작사가 소스코드를 보유·관리하며 월 운영비를 받고 봇을 돌려주는 형태입니다. 의뢰인은 코드를 직접 손에 쥐지 않습니다. 뒤(9장)에서 다루겠지만 이 형태가 무조건 나쁜 것은 아닙니다. 다만 이 경우 "제작사가 사라지면 내 봇은 어떻게 되나"라는 위험이 가장 큽니다. 그래서 이 형태를 택한다면 다음 6장의 임치(에스크로)를 반드시 함께 고려해야 합니다. 참고로 앞서 소개한 제작 비용·견적 가이드에서도 운영위탁은 별도 월 비용이 붙는 구조로 설명한 바 있습니다.

5. 계약서에서 반드시 확인할 세 문장

계약서 전체를 법률가처럼 읽을 필요는 없습니다. 소스코드와 관련해서는 딱 세 가지 문장만 있는지, 그리고 모호하지 않은지 확인하면 됩니다.

세 문장 모두 "대금 완납 시"라는 조건과 묶는 게 일반적입니다. 즉 잔금까지 다 치르면 권리가 넘어오는 구조죠. 이건 제작사에게도 공정합니다 — 돈을 다 받기 전에 코드를 다 넘기라는 건 제작사에게 무리한 요구니까요. 그래서 실무에서는 "중도금·잔금 단계에 맞춰 산출물을 단계적으로 인도"하는 방식도 많이 씁니다.

6. 소프트웨어 임치(에스크로) — 안 주지도, 못 받지도 않는 절충안

여기서 많은 사람이 처음 듣는 개념이 나옵니다. 소프트웨어 임치(software escrow, 기술자료 임치)입니다. 이름은 낯설지만 아이디어는 단순합니다.

제작사 입장에서 소스코드는 먹고사는 핵심 자산입니다. 그래서 선뜻 통째로 넘기기 어려울 수 있습니다. 반대로 의뢰인 입장에서는 "제작사가 사라지면 내 봇이 죽는" 위험을 감수하기 어렵습니다. 이 둘의 이해가 충돌할 때, 믿을 수 있는 제3의 공식 기관에 소스코드를 맡겨두는 것이 임치입니다.

임치의 핵심은 '해제 조건(release condition)'을 계약서에 미리 정해두는 것입니다. 평소에는 코드가 임치기관에 잠들어 있고, 계약서에 적힌 특정 사건 — 예컨대 제작사의 폐업·파산, 합의된 유지보수 의무 불이행, 일정 기간 이상의 연락 두절 등 — 이 실제로 발생했을 때에만 의뢰인이 코드를 받을 수 있습니다. 이렇게 하면 제작사는 평상시 코드를 지킬 수 있고, 의뢰인은 "최악의 경우에도 봇이 영영 멈추지는 않는다"는 안전판을 갖습니다.

임치가 특히 어울리는 경우는 ③ 운영위탁 형태이거나, 봇에 걸린 자금·중요도가 커서 중단 리스크를 감당하기 어려운 경우입니다. 반대로 개인이 소액으로 자기 봇을 굴리는 정도라면, 정식 임치보다 "소스코드를 그냥 인도받아 안전한 곳에 백업"하는 편이 더 간단하고 실용적일 수 있습니다.

7. 계약을 망치는 독소조항 10가지

이제 가장 실전적인 부분입니다. 계약서에 이런 문구가 보이면 멈추고 질문해야 합니다. 하나하나가 나중에 소스코드·유지보수·비용에서 발목을 잡을 수 있는 독소조항입니다. (모두 '무조건 사기'라는 뜻은 아니고, 반드시 이유를 확인하고 넘어가야 할 신호라는 뜻입니다.)

• 소스코드는 어떤 경우에도 제공하지 않는다 — 대안(임치 등)조차 없이 못 준다고만 하면 강한 종속 신호.
• 저작권 귀속에 대한 언급이 아예 없다 — '침묵'은 대개 제작사에 유리하게 작동합니다. 빠졌다면 채워 달라고 요청.
• 납품물 = 실행파일로만 규정 — 소스코드·문서·설정값이 인도 범위에서 빠져 있음.
• 유지보수는 원제작사만 할 수 있다(타사 위탁 금지) — 코드를 받아도 남에게 못 맡기게 묶는 조항.
• 수익의 일정 %를 계속 지급한다(레버뉴 셰어) — 제작 대가와 별개로, 성과에 지속 과금. 자동매매에서 특히 주의(성과는 보장 대상이 아님).
• API 키·계정을 제작사가 보유·관리한다 — 내 자산에 접근하는 열쇠를 남이 쥐는 구조. 키는 반드시 내가 통제.
• 봇을 특정 서버에서만 돌릴 수 있다(이전 불가) — 제작사 서버에 묶여 나갈 수 없게 만드는 잠금.
• 계약 해지 시 산출물·데이터 반환 조항이 없다 — 관계가 끝나면 내 데이터·설정을 못 돌려받음.
• '수익 보장'을 계약서에 적어준다 — 안심시키는 문구 같지만, 오히려 위험 신호. 검증 없는 보장은 지켜질 수 없습니다.
• 비밀유지·경업금지가 의뢰인에게만 과도하게 걸린다 — 한쪽에만 무겁게 기운 조항은 균형을 확인.

반대로, 건강한 계약서에는 오히려 이런 문장이 들어 있습니다: "대금 완납 시 소스코드·문서 일체 인도 및 저작권 귀속", "30일 무료 하자보수 및 범위 명시", "API 키는 의뢰인이 직접 발급·보관", "계약 해지 시 산출물·데이터 반환", "제작사는 동일 코드를 제3자에 재판매하지 않음". 좋은 조항의 존재가 나쁜 조항의 부재보다 더 확실한 신호입니다. 참고로 "API 키를 제작사가 보유·관리"가 왜 위험한지, 그리고 출금 권한을 끈 안전한 키를 만드는 법은 API 키를 넘겨도 될까 — 계좌를 지키는 5가지 안전장치에서 따로 자세히 다뤘습니다.

8. 코드를 받아도 못 쓰는 경우 — 열쇠는 있는데 설명서가 없다

"소스코드만 받으면 끝"이라고 생각하기 쉽지만, 함정이 하나 더 있습니다. 코드 파일은 받았는데 그걸 돌리는 방법을 모르는 경우입니다. 이건 열쇠는 손에 쥐었는데 어느 문을 여는 열쇠인지, 어떻게 돌리는지 설명서가 없는 상태와 같습니다. 다른 개발자에게 유지보수를 맡기려 해도, 이 상태면 그 개발자도 처음부터 코드를 해독해야 해서 시간과 비용이 크게 듭니다.

그래서 소스코드는 반드시 다음 세 가지를 한 세트로 받아야 합니다.

또 하나 놓치기 쉬운 것이 외부 의존성입니다. 봇이 특정 유료 데이터 서비스나 제작사만 아는 외부 도구에 묶여 있으면, 코드를 통째로 넘겨받아도 그 부분은 그대로 못 돌립니다. 마치 레시피에 "우리 가게에서만 파는 비밀 소스 3스푼"이라고 적혀 있는 것과 같죠. 그래서 인계 시 "이 봇이 외부의 무엇에 의존하는지, 그게 내게도 이전 가능한지"를 반드시 확인해야 합니다.

9. "코드를 안 주는 게" 합리적인 경우도 있다

여기까지 읽으면 "무조건 소스코드를 받아내야 한다"고 결론 내리기 쉽지만, 정직하게 균형을 잡겠습니다. 코드를 내주지 않는 운영위탁 형태가 오히려 합리적인 경우도 분명히 있습니다.

• 전략 노하우 보호: 제작사가 오랜 기간 다듬은 고유 전략이 코드에 담겨 있다면, 그것을 통째로 넘기지 않는 대신 '운영해 주는' 모델은 정당한 사업 방식입니다.
• 유지보수의 안정성: 코드를 받아도 스스로 관리할 역량·의지가 없는 의뢰인이라면, 차라리 전문가가 계속 관리해 주는 편이 봇을 더 오래 살립니다.
• 복잡도가 높은 봇: 다거래소·차익거래처럼 손이 많이 가는 봇은, 코드를 넘겨받아도 혼자 운영이 사실상 불가능해 위탁이 현실적입니다.

중요한 건 "코드를 주느냐"가 아니라 "그 관계가 투명하고 빠져나갈 길이 있느냐"입니다. 건강한 운영위탁이라면 다음 세 가지를 갖춥니다.

즉 운영위탁 자체가 나쁜 게 아니라, 빠져나갈 문이 없는 운영위탁이 나쁜 것입니다. 계약 전에 딱 한 가지만 물어보세요. "만약 제가 나중에 다른 곳에서 유지보수를 받고 싶어지면, 그때는 어떻게 되나요?" 이 질문에 대한 답이 명료하고 합리적이면 좋은 파트너, 얼버무리거나 불이익을 강조하면 종속 구조입니다.

10. 실전 시나리오 — 같은 봇, 다른 계약, 다른 결말

추상적인 이야기를 하나의 장면으로 묶어 봅시다. 똑같은 성능의 봇을 두 사람이 비슷한 값에 맡겼는데, 계약서의 세 줄이 달라 8개월 뒤 완전히 다른 결말을 맞은 이야기입니다. (특정 인물이 아닌 전형적 패턴을 재구성한 예시이며, 수익·성과와는 무관합니다.)

8개월 뒤, 거래소가 인증 방식을 바꿔 두 봇이 같은 날 멈췄습니다. 코드로 치면 몇 줄만 손보면 되는 변경이었습니다. 여기서 두 사람의 길이 갈립니다.

A 사장은 손에 소스코드와 인수인계 문서가 있었습니다. 마침 원제작사가 다른 일로 바빴지만, A는 다른 개발자에게 문서와 코드를 넘겨 반나절 만에 수정을 받았습니다. 문서에 "인증 관련 설정은 여기"라고 적혀 있어 새 개발자도 헤매지 않았죠. 봇은 다음 날 정상 복귀했습니다. A에게 이 사건은 '반나절짜리 유지보수'였습니다.

B 사장은 달랐습니다. 고칠 코드가 자기 손에 없어 원제작사에만 매달려야 했는데, 하필 그 제작사가 응답이 느렸습니다. 다른 개발자에게 부탁하려 해도 넘길 코드가 없었습니다. 게다가 API 키를 제작사가 쥐고 있어, 급한 마음에 계정을 정리하고 싶어도 무엇이 어떻게 연결돼 있는지 파악조차 어려웠습니다. 결국 B는 봇을 처음부터 다시 만드는 견적을 받아야 했습니다. B에게 이 사건은 '재제작'이었습니다.

11. 나는 어떤 형태가 맞나 — 상황별 선택

정답은 사람마다 다릅니다. 아래 표로 내 상황에 맞는 형태를 가늠해 보세요. 어디까지나 일반적 가이드이며, 개별 계약은 위에서 강조한 대로 전문가 확인을 권합니다.

이 판단은 결국 "나는 이 봇을 얼마나 오래, 얼마나 독립적으로, 얼마나 스스로 다룰 것인가"로 귀결됩니다. 시작 규모·비용 감각이 아직 흐릿하다면 최소 자본금·수수료·손익분기 글로 운용의 현실 감각을 먼저 잡고 오시는 것도 좋습니다. 또 "내가 직접 할지 맡길지"부터 헷갈린다면 코딩 없이 자동매매 어디까지 되나가 그 갈림길을 정리해 줍니다.

12. 맡기기 전, 이 세 줄만 요청하세요

복잡해 보였지만, 실제 의뢰인이 해야 할 일은 계약 전에 이 세 줄을 확인·요청하는 것이 전부입니다. 코딩을 몰라도, 법을 몰라도 이 세 문장이면 대부분의 사고를 막습니다.

이 세 가지를 물었을 때 상대가 반응하는 태도가 그 자체로 훌륭한 판별기입니다. 좋은 제작자는 "당연히 그렇게 해드립니다"라며 오히려 명확하게 문서로 정리해 줍니다. 반대로 정당한 이유 없이 회피하거나 불쾌해한다면, 그건 실력이 아니라 관계의 균형에 문제가 있을 가능성이 큽니다. 이 감별의 큰 틀은 외주 27가지 체크리스트와 함께 보면 완성됩니다. 매매 규칙 자체를 어떻게 문서로 정리하는지는 자동매매 명세서 작성 가이드가 도와줍니다.

13. 한 장으로 요약

길게 읽으셨으니 핵심만 접어 드립니다.

마지막으로 한 번 더 강조합니다. 자동매매 외주에서 진짜 큰 손해는 대개 '요란한 사기'가 아니라 '조용한 종속'에서 옵니다. 봇이 잘 돌아가는 초반엔 아무 문제가 없어 보이기 때문에 더 위험합니다. 계약서에 서명하기 전, 딱 세 줄만 확인하세요. 소스코드가 누구 것인지, 무엇을 함께 받는지, 문제가 생기면 어떻게 빠져나오는지. 이 세 줄이 몇 달 뒤의 당신을 지켜줍니다.

자주 묻는 질문