자동매매 프로그램 제작 — 직접 만들기 vs 외주 기준

"자동매매 프로그램 제작"을 검색하는 사람은 보통 두 부류입니다. 이미 맡기기로 정하고 업체를 찾는 사람과, 직접 만들지 맡길지 아직 안 정한 사람입니다. 이 글은 후자를 위한 것입니다. (이미 외주로 정하셨다면 외주 전 27개 체크리스트가 다음 단계입니다.)

결정을 미루게 만드는 질문은 대개 "파이썬 배우면 되나요?"인데, 이건 답하기 어려운 질문이 아니라 잘못된 질문입니다. 문법은 몇 주면 읽고 쓸 수 있습니다. 문제는 그다음입니다.

1. 직접 만들면 통과해야 하는 관문 8개

아래는 국내 주식 자동매매를 직접 만들 때 순서대로 마주치는 관문입니다. 전략이 무엇이든 거의 동일하게 나옵니다. 각 줄의 오른쪽이 실제로 사람들이 막히는 지점입니다.

2. 실물 세 장 — 여기서 대부분 멈춘다

추상적으로 말하면 감이 안 오니 실제 코드와 응답을 보겠습니다.

① 토큰 — 숫자를 박으면 안 되는 이유

KIS API는 appkey·appsecret으로 access_token을 받습니다. 많이 하는 실수는 "하루짜리니까 24시간마다 갱신"으로 짜는 것입니다. 유효기간은 응답에 담겨 오는 값으로 관리해야 하고, 그래야 정책이 바뀌어도 코드가 버팁니다.

import requests

BASE = "https://openapi.koreainvestment.com:9443"     # 모의투자는 도메인이 다르다
r = requests.post(f"{BASE}/oauth2/tokenP", json={
    "grant_type": "client_credentials",
    "appkey":    APP_KEY,
    "appsecret": APP_SECRET,
}, timeout=10)

tok = r.json()
# {"access_token": "...", "token_type": "Bearer",
#  "expires_in": 86400, "access_token_token_expired": "2026-08-26 09:12:33"}

# ✗ 24시간을 코드에 박는다        → 정책 변경·시각 오차에 그대로 무너진다
# ✓ 응답의 만료 값을 저장하고 여유를 두고 미리 갱신한다

자세한 갱신 패턴은 KIS 접근토큰 만료·갱신에 정리해 두었습니다. 발급 자체가 처음이라면 KIS 개발자 포털에서 앱 등록부터 하게 됩니다.

② 에러 — 코드 버그가 아닌 것들

직접 만들 때 가장 당황스러운 지점입니다. 코드에 아무 문제가 없는데 주문이 실패합니다.

{
  "rt_cd": "1",
  "msg_cd": "EGW00201",
  "msg1": "초당 거래건수를 초과하였습니다."
}

이건 문법 오류가 아니라 호출을 너무 빨리 보냈다는 뜻입니다. 파이썬 강의에서는 배우지 않고, 실계좌에 붙여 본 사람만 압니다. 해결은 재시도가 아니라 호출 간격을 구조적으로 제어하는 것입니다 (EGW00201 초당 거래건수 초과). 키움 REST API 쪽은 같은 상황에서 429가 돌아옵니다.

③ 부분체결 — 평균단가가 틀어지는 자리

10주를 냈는데 3주·4주·3주로 나뉘어 체결되는 일은 드문 사고가 아니라 일상입니다. 이때 체결 건 단위로 집계하지 않으면 평균 매입단가가 틀어지고, 그 값은 손절·익절 계산으로 그대로 흘러 들어갑니다. 키움 REST API에서는 체결번호 cntr_no가 있는 TR을 써야 하는데, 이름이 비슷한 TR이 세 개라 어느 것을 부를지부터 헷갈립니다 (키움 체결내역 조회 — kt00009 부분체결).

3. 판단표 5축

아래 다섯 줄에 각각 어느 쪽인지 표시해 보십시오. 왼쪽이 3개 이상이면 직접, 오른쪽이 3개 이상이면 외주가 대체로 맞습니다.

다섯 축이 갈리는 이유는 하나입니다. 자동매매 프로그램은 만들고 끝나는 물건이 아니라 계속 돌리는 설비이기 때문입니다. 증권사 명세는 바뀌고(키움은 OpenAPI+에서 REST로 축이 옮겨 갔습니다), 시장 제도도 바뀌고(NXT 출범으로 주문이 나가는 거래소가 늘었습니다), 그때마다 손볼 사람이 필요합니다. 유지보수 비용의 현실을 먼저 보시면 이 축의 무게가 실감납니다.

4. 세 번째 선택지 — 경계를 나눠 맡기기

실제로 가장 많이 선택되는 형태는 전부 직접도 전부 외주도 아닙니다. 바뀌지 않는 부분과 자주 바뀌는 부분을 갈라 놓는 것입니다.

이 구조가 되려면 제작 단계에서 경계를 요구해야 합니다. 전략 조건이 코드 곳곳에 흩어져 있으면 나중에 숫자 하나 바꾸는 데도 의뢰가 필요합니다. 견적을 받을 때 "전략 조건을 설정 파일이나 별도 함수로 분리해 주시나요?"를 물어보십시오. 이 한 문장이 이후 1년의 운영 비용을 가릅니다.

5. 어느 쪽이든 먼저 정해야 할 것

직접 만들든 맡기든, 먼저 확정해야 답이 나오는 것이 세 가지 있습니다. 이게 안 정해진 상태에서 견적을 받으면 금액이 아니라 범위가 흔들립니다.

1. 어느 증권사·어느 API인가. 국내 주식이면 키움 REST API·한국투자증권 KIS가 주 선택지이고, 증권사마다 지원 범위와 제약이 다릅니다 (국내 증권사 API 비교). 해외주식·코인이면 아예 다른 갈래입니다.
2. 규칙이 문장으로 적히는가. "적당히 오르면 판다"는 코드가 되지 않습니다. 무엇을 언제 얼마나 사고파는지 숫자로 적히지 않으면 제작 자체가 불가능합니다 (자동매매 명세서 작성법).
3. 소스와 키는 누가 갖는가. 소스 코드를 못 받으면 다른 곳에서 이어받을 수 없습니다. 증권사 API 키는 본인이 발급해 본인 서버에 두는 것이 원칙입니다 (소스 코드 소유권·에스크로).

그리고 어느 쪽을 고르든 실계좌에 바로 넣지 마십시오. 모의투자 → 소액 실계좌 → 정상 운영의 단계를 밟는 것이 직접 만들기와 외주 모두에서 손실을 가장 크게 줄이는 절차입니다.

6. 자주 묻는 것

노코드 툴로는 안 되나요?

조건이 단순하고 툴이 지원하는 범위 안이면 됩니다. 다만 지원 범위를 벗어나는 순간(증권사 고유 주문 유형, 부분체결 처리, 자체 리스크 규칙) 우회가 아니라 벽이 됩니다. 툴이 지원하는 주문 유형과 조건식의 목록을 먼저 확인하고, 내 전략이 그 안에 들어가는지부터 대조해 보십시오.

AI에게 코드를 짜 달라고 하면 되지 않나요?

초안을 만드는 데는 확실히 도움이 됩니다. 문제는 증권사 API 명세가 자주 바뀌고, 학습 시점 이후의 변경은 반영되지 않는다는 점입니다. 실제로 키움은 OpenAPI+(OCX·32bit)에서 REST로 축이 옮겨 갔고, 이전 방식 기준으로 짜인 코드는 그대로 동작하지 않습니다. 생성된 코드를 공식 문서와 대조할 수 있는 사람에게는 좋은 도구이고, 대조할 수 없는 사람에게는 틀린 것을 맞다고 믿게 만드는 도구입니다.

먼저 백테스트부터 해 봐도 되나요?

권합니다. 오히려 그게 순서입니다. 다만 백테스트가 잘 나온다고 실전이 같지 않습니다 — 수수료·세금·슬리피지·부분체결이 빠져 있기 때문입니다. 백테스트와 실전의 괴리를 먼저 보고 기대치를 조정한 다음 제작 여부를 정하는 편이 좋습니다.

이 글의 API 항목·에러 코드는 2026-08-25 시점 각 증권사 공식 문서 기준이며, 코드는 구조 이해를 돕기 위한 예시입니다. 증권사 명세와 정책은 예고 없이 바뀌므로 실제 적용 전 공식 문서로 대조하십시오. 또한 이 글은 제작 방식에 대한 판단 기준을 다룰 뿐 특정 전략의 수익성이나 시장 방향을 말하지 않습니다.