자동매매 외주 NDA — 상담에서 전략을 어디까지 말하나

1. 견적에 필요한 정보 vs 필요 없는 정보

자동매매 프로그램의 제작 난이도는 "전략이 얼마나 기발한가"보다 "어떤 API를 몇 개, 얼마나 자주 부르는가"에서 갈립니다. 같은 이동평균 교차 전략이라도 KIS REST API로 일봉 한 번 조회하는 봇과, 키움 WebSocket 실시간 체결을 받아 30종목을 동시에 보는 봇은 일의 양이 전혀 다릅니다. 반대로 이동평균 기간이 5일이냐 7일이냐는 코드에서 숫자 하나 차이입니다.

위 다섯 줄만 있으면 견적이 나옵니다. 아래 네 줄은 견적 금액을 거의 바꾸지 않습니다. 플랫폼 고르는 기준은 견적 전에 정할 5가지에 따로 정리했습니다.

2. 첫 메시지는 이 정도면 충분하다 — 실물 예시

실제로 견적이 바로 나오는 첫 상담 메시지 형태입니다. 전략의 "모양"은 보이지만 값은 하나도 없습니다.

[첫 상담 메시지 예시]
- 증권사: 한국투자증권 KIS Open API (REST), 국내주식 KOSPI·KOSDAQ
- 대상: 직접 고른 관심종목 15~20개 (목록은 나중에 제가 입력)
- 데이터: 장중 5분봉 조회 + 체결 통보 (WebSocket)
- 진입: 이동평균 2개와 거래량 조건 조합 (구체 값은 계약 후 전달)
- 청산: 손절 %, 익절 %, 장 마감 전 일괄 정리
- 주문: 지정가 매수, 미체결이면 N분 뒤 취소
- 기타: 텔레그램 알림, 윈도우 PC에서 실행, 모의투자로 먼저 테스트

제작사 입장에서 이 메시지로 알 수 있는 것은 "KIS 토큰 발급(access_token), 분봉 조회 TR, 매수 주문 TTTC0012U, 체결 통보 WebSocket, 호출 제한 처리"라는 작업 목록입니다. 전략의 핵심 — 어떤 이동평균 두 개를 어떤 값으로, 거래량을 몇 배로 볼지 — 는 하나도 드러나지 않았습니다. 그래도 견적은 정확하게 나옵니다. 주문 TR이 무엇인지 미리 알아 두고 싶다면 KIS 주문 tr_id 신·구 비교를, 키 발급은 KIS 앱키 발급 30분 가이드를 보면 됩니다.

반대로 상담에서 말하지 않아도 되는 것도 분명합니다. appkey·appsecret·계좌번호(cano)·비밀번호는 견적 단계에서 전혀 필요 없습니다. 상담 중 누군가 이걸 먼저 달라고 하면 그 자체가 경고 신호입니다(자동매매 사기 예방 가이드).

3. 단계별 공개 범위 — 상담·견적·계약·명세·납품

정보는 한 번에 넘기는 것이 아니라 단계마다 그 단계에 필요한 만큼만 넘깁니다. 알고랩의 진행 순서 기준으로 그리면 이렇습니다.

① 상담 — 무엇을 만드는지

2장의 메시지 수준입니다. 이 단계에서도 알고랩은 이용약관 제9조(기밀 유지)에 따라 고객의 매매 전략·요구사항·개인정보를 제3자에게 공개하지 않습니다. 다만 아직 별도 계약서가 없는 상태이니, 값은 아끼는 것이 합리적입니다.

② 견적 — 얼마나 복잡한지

"지표 3개를 AND로 묶고, 청산 조건이 4가지"처럼 구조의 크기를 알려 줍니다. 조건 분기 수가 늘면 테스트 경우의 수가 늘어 일정이 달라지기 때문입니다.

③ 계약·NDA — 보호 범위를 문서로 특정

NDA를 원하면 이 시점에 맺는 것이 효율적입니다. 견적 전에 NDA부터 요구하면 상담이 길어지고, 명세서 뒤에 맺으면 이미 다 넘긴 뒤입니다. 알고랩 현행 NDA 서식은 보호 대상인 "전략 정보"를 매매 아이디어·진입 및 청산 조건·지표 조합과 조건식·파라미터 설정값·분할 청산 비율·리스크 관리 규칙·백테스트 결과 및 성과 지표로 정의하고, 별지에 그 프로젝트의 구체 목록을 적습니다.

④ 명세서 — 조건식 전체

여기서 처음으로 "무엇을 어떻게 판단하는가"가 문장으로 고정됩니다. 값을 끝까지 숨기기로 했다면 명세서에도 MA_FAST·STOP_PCT 같은 변수 이름만 쓰고 값 칸은 비워 둡니다. 명세서 쓰는 법은 자동매매 명세서 작성 가이드에 있습니다.

⑤ 개발·납품 — 키는 의뢰인이 넣는다

개발은 모의투자 키(KIS 모의 도메인, 키움 mockapi.kiwoom.com, 바이낸스 테스트넷)로 할 수 있고, 실전 appkey·appsecret은 납품 후 의뢰인이 직접 입력합니다. 부득이하게 실전 키를 넘겼다면 납품 후 재발급해 기존 키를 무효화하는 것이 원칙입니다(현행 NDA 서식에도 계정 정보 폐기·재발급 권고가 들어 있습니다). 키 전달 순서는 API 키 보안 글 §7에 있습니다.

4. 파라미터를 끝까지 숨기는 법 — 설정 파일 분리

"계약을 해도 값만은 아무에게도 보여주고 싶지 않다"는 요청도 실제로 처리할 수 있습니다. 로직은 변수로만 짜고, 값은 코드 밖 파일에서 읽게 하는 구조입니다. 제작사는 예시 값 파일로 개발·테스트하고, 의뢰인은 납품받은 뒤 같은 이름의 파일에 진짜 값을 넣습니다.

bot/
├─ main.py                         # 로직 — 값이 하나도 없다
├─ strategy_params.example.json    # 제작사가 쓰는 예시 값 (납품물에 포함)
├─ strategy_params.json            # 의뢰인 PC에만 존재 — 납품물·저장소에 없음
├─ .env                            # KIS_APPKEY / KIS_APPSECRET — 의뢰인 PC에만
└─ .gitignore                      # strategy_params.json, .env 제외

# strategy_params.example.json — 형식만 맞춘 예시 값
{
  "ma_fast": 5,
  "ma_slow": 20,
  "volume_mult": 2.0,
  "stop_pct": -3.0,
  "take_pct": 6.0,
  "max_positions": 5
}

import json, os, sys
from pathlib import Path

BASE = Path(__file__).parent
REQUIRED = {"ma_fast": int, "ma_slow": int, "volume_mult": float,
            "stop_pct": float, "take_pct": float, "max_positions": int}

def load_params():
    path = BASE / "strategy_params.json"            # 실제 값 (의뢰인)
    if not path.exists():
        path = BASE / "strategy_params.example.json" # 없으면 예시 값 (개발용)
        print("[경고] 예시 파라미터로 실행 중 — 실계좌 주문 금지", file=sys.stderr)
    p = json.loads(path.read_text(encoding="utf-8"))
    for k, t in REQUIRED.items():                   # 이름·타입만 검사, 값은 로그에 안 찍는다
        if k not in p:
            raise SystemExit(f"strategy_params에 {k} 없음")
        p[k] = t(p[k])
    p["_is_example"] = path.name.endswith("example.json")
    return p

PARAMS = load_params()
APPKEY = os.environ["KIS_APPKEY"]                    # 키도 코드에 없다

핵심은 세 가지입니다. ① main.py에 숫자 상수가 없다. ② 실제 값 파일이 없으면 예시 값으로 돌되 경고를 띄우고 실계좌 주문을 막는다 — 예시 값으로 실전 주문이 나가는 사고를 막는 장치입니다. ③ 로그에 값을 찍지 않는다 — 오류 로그를 제작사에 보내 줄 때 값이 따라 나가지 않게 하려는 것입니다.

이 방식의 대가도 있습니다. 실제 값으로만 생기는 문제는 제작사가 재현할 수 없습니다. 예를 들어 ma_slow가 120이라 장 초반에 데이터가 모자라 신호가 안 나는 경우, 예시 값 20으로는 그 현상이 보이지 않습니다. 실제 값으로 백테스트(CAGR·MDD 검증)를 맡기려면 값을 넘겨야 합니다. 그래서 보통은 "개발은 예시 값, 문제가 생기면 그때 해당 값만 NDA 범위 안에서 공유"로 정합니다. 검증만 먼저 맡기는 방법은 백테스트만 먼저 의뢰하기에 정리했습니다.

5. NDA가 막는 것, 못 막는 것

NDA는 받은 정보를 계약 목적 밖으로 쓰거나 남에게 공개하지 못하게 하고, 어기면 책임을 묻는 계약입니다. 금고가 아니라 약속이라는 점을 알고 쓰면 기대치가 맞습니다.

왼쪽과 오른쪽을 가르는 선이 중요합니다. "이동평균 교차"는 누구나 쓰는 공개 기법이라 보호 대상이 아니지만, 의뢰인이 고안한 지표의 조합 방식·조건식·파라미터·타임프레임 구성·분할 청산 규칙은 공지 정보가 아니므로 보호 대상입니다. 그래서 NDA 별지에 "무엇이 내 전략인가"를 구체적으로 적어 두는 것이 실제 효력을 좌우합니다.

참고로 「부정경쟁방지 및 영업비밀보호에 관한 법률」 제2조 제2호는 영업비밀을 공공연히 알려져 있지 않고(비공지성), 독립된 경제적 가치가 있으며(경제적 유용성), 비밀로 관리된(비밀관리성) 정보로 정의합니다. 2019년 개정으로 "합리적인 노력에 의하여 비밀로 유지된"이 "비밀로 관리된"으로 바뀌어 요건이 완화됐지만, 실무에서는 여전히 비밀관리성이 가장 많이 다퉈진다고 합니다. 의뢰인 쪽에서 전략 문서를 아무 데나 공유해 왔다면 NDA가 있어도 보호가 약해질 수 있다는 뜻입니다. 조문 원문은 국가법령정보센터에서 확인하고, 구체적 분쟁은 변호사와 상의하십시오 — 이 글은 법률 자문이 아닙니다.

정리하면 이렇습니다. 첫 상담에서는 API·시장·빈도·주문 방식만 말하고, 조합의 윤곽은 견적 직전에, 조건식 전체는 NDA 뒤 명세서에서, 값은 끝까지 설정 파일에 두어도 됩니다. 이 순서면 견적 정확도는 그대로이고, 노출 범위는 필요한 만큼으로 줄어듭니다. 이 글은 계약 체결 절차와 공개 범위를 설명할 뿐 특정 전략이나 수익을 권하지 않습니다.

6. 자주 묻는 질문