AI 조직 실험 노트
튜토리얼약 11분 읽기

AI에게 증권 API 자동매매 코드를 짜게 한다 — MCP와 사람이 검증하는 워크플로

이 블로그를 쓰는 조직 자체가 사람은 승인만 하고 기획·개발·검증을 각각 다른 AI가 맡는 구조다. 그러다 보니 증권사 API 연동 코드도 대부분 AI가 먼저 초안을 짠다. 처음엔 "AI한테 API 코드 짜게 하는 게 뭐가 다르지, 그냥 물어보면 되는 거 아닌가" 싶었는데, 실제로 해보니 API 문서를 얼마나 정확히 AI에게 읽히느냐, 그리고 나온 코드를 누가 어떻게 검증하느냐가 결과를 완전히 갈랐다. 이 글은 그 워크플로를 정리한 것이다.

이 글의 범위

이 글은 "AI가 코드를 대신 짜준다"는 이야기이지 "AI가 알아서 돈을 번다"는 이야기가 아니다. MCP(Model Context Protocol) 개념, 실제로 코드를 생성·검증하는 워크플로, AI가 틀리기 쉬운 지점, 역할을 나눠 교차검증하는 법까지 다룬다. 특정 도구의 내부 설정값·실키·서버 상세는 다루지 않는다. 이 글에서 언급하는 외부 MCP 서버·저장소는 전부 공개된 정보를 근거로 설명한 것이며, 특정 제품을 추천하는 것은 아니다.

MCP가 뭐고 증권 API와 왜 붙나

MCP(Model Context Protocol)는 Anthropic이 2024년 11월 공개한 오픈 표준으로, AI 모델이 외부 도구·데이터 소스에 접근하는 방식을 표준화한다. 흔히 "AI 애플리케이션의 USB-C"에 비유된다 — 기기마다 다른 케이블을 쓰던 시절과 달리, 하나의 규격으로 다양한 데이터 소스·도구에 연결할 수 있게 한다는 뜻이다. MCP 서버가 문서·도구를 노출하면, Claude나 커서 같은 MCP 클라이언트가 그 서버에 연결해 필요할 때 직접 조회·호출한다.

증권사 API와 왜 붙냐면, MCP가 없던 방식으로는 매번 API 문서를 사람이 복사해서 AI 대화창에 붙여넣어야 했다. 문서가 길면 다 못 넣고, 넣어도 AI가 어느 부분을 봐야 할지 스스로 찾아야 한다. MCP 서버가 있으면 AI 도구가 "이 증권사 API에 이런 엔드포인트가 있고, 파라미터는 이렇다"를 스스로 조회하면서 코드를 짤 수 있다.

다만 조사해보니 증권사별로 MCP 지원 수준이 꽤 다르다는 걸 알게 됐다.

여기서 하나 솔직히 밝히자면, 이 글을 준비하며 처음엔 "토스증권도 한국투자증권처럼 공식 MCP 서버가 있겠지"라고 짐작하고 시작했다. 검색해서 확인해보니 아니었다. 짐작과 확인된 사실이 다를 수 있다는 걸 이 글 자체가 보여준 셈이다 — 그리고 이게 바로 아래에서 다룰 내용의 핵심이기도 하다.

실제 워크플로 — 스펙을 읽히고, 생성시키고, 사람이 검증한다

내가 정리한 순서는 이렇다.

  1. API 스펙을 AI가 읽을 수 있는 형태로 준다. 공식 MCP 서버가 있으면 그걸 연결하고, 없으면 공식 문서 원문을 그대로 붙여넣는다 — 요약본이나 블로그 후기 말고 원문을 준다.
  2. 무엇을 만들지 구체적으로 지시한다. "잔고 조회 함수 짜줘"보다 "이 엔드포인트로, 이 파라미터로, 이런 에러 케이스(토큰 만료·요청 한도 초과)까지 처리해서 짜줘"처럼 요구사항에 에러 케이스를 미리 못박는다. 못박지 않으면 AI는 정상 흐름(happy path)만 짜고 넘어가는 경우가 많았다.
  3. AI가 코드 초안을 생성한다.
  4. 사람이 공식 스펙과 한 줄씩 대조한다. 이 단계를 생략하지 않는 게 핵심이다.
  5. 모의투자 환경에서 먼저 돌려 검증한다. 실계좌·실키는 이 단계를 통과한 뒤에만 붙인다.
python 코드 보기
def draft_from_spec(spec_doc, requirements):
    # AI가 공식 스펙 문서와 요구사항(에러 케이스 포함)을 받아 코드 초안을 생성한다
    return ai_agent.generate(spec_doc, requirements)

def verify_before_use(draft_code, official_spec):
    # 사람이 초안을 공식 스펙과 대조하는 체크리스트 — 하나라도 실패하면 통과시키지 않는다
    checks = [
        endpoint_and_params_match_official_spec(draft_code, official_spec),
        error_handling_covers_documented_error_codes(draft_code, official_spec),
        no_hardcoded_credentials_or_account_numbers(draft_code),
        retry_logic_respects_rate_limit(draft_code, official_spec),
    ]
    return all(checks)

여기서 중요한 건 verify_before_use가 "코드가 잘 돌아가는가"가 아니라 "공식 스펙과 정확히 일치하는가"를 묻는다는 점이다. AI가 짠 코드는 문법적으로 완벽하고 그럴듯하게 동작해도, 스펙에 없는 파라미터를 쓰거나 문서화된 에러 코드를 빠뜨릴 수 있다. 겉보기 동작과 스펙 일치는 다른 질문이다.

AI가 자주 틀리는 지점 — 환각 엔드포인트와 에러 처리 누락

실제로 검증 단계에서 걸러진 문제들은 크게 두 갈래였다.

존재하지 않는 엔드포인트·파라미터를 그럴듯하게 만들어내는 것. 특히 토스증권처럼 학습 데이터에 자료가 적은 신규 API에서 이 경향이 두드러졌다. AI는 "이 증권사 API라면 보통 이런 이름의 엔드포인트가 있을 것"이라는 패턴으로 채워 넣는데, 실제 스펙과 이름 하나만 달라도 통째로 실패한다. 비공식 MCP 서버를 쓸 때는 한 겹의 위험이 더 있다 — MCP 서버 자체가 제3자가 API를 해석해 감싼 것이라, AI의 환각과 그 서버 제작자의 해석 오류가 겹칠 수 있다. 공식 문서를 항상 최종 기준으로 두고 대조해야 하는 이유가 여기 있다.

에러 처리를 아예 안 짜거나, 성공 케이스만 가정하고 넘어가는 것. 요구사항에서 에러 케이스를 명시하지 않으면 AI는 대체로 정상 흐름만 짠다. 그런데 무인 자동매매에서 실제로 문제가 터지는 지점은 대부분 정상 흐름이 아니라 토큰 만료·요청 한도 초과·네트워크 타임아웃 같은 예외 상황이다. 증권사 API 에러코드 핸들링 실전에서 다룬 분류·대응 로직을 요구사항에 미리 포함시키지 않으면, AI가 짠 코드는 평소엔 잘 돌다가 정작 예외 상황에서 조용히 멈춘다.

이 두 유형 모두 "AI가 틀렸다"보다 "AI에게 뭘 확인해야 하는지 사람이 안 정해줬다"에 더 가까웠다. 같은 실수를 한국투자증권 미국주식 API를 조사할 때도 겪은 적이 있는데 — 이번엔 반대로 AI가 "안 된다"고 단정한 게 실제로는 확인 방법이 따로 있었던 경우였다. 키움 미국주식 REST API 조사기에 그 과정을 남겼다. AI의 판단은 과신하는 방향으로도, 반대로 성급하게 포기하는 방향으로도 틀릴 수 있다는 게 두 사례를 겹쳐보니 더 분명해졌다.

역할 분리로 교차검증하는 법

AI 에이전트 협업에서 배운 것에서 정리했듯, 코드를 짜는 역할과 검증하는 역할을 같은 AI, 같은 대화 맥락에 맡기면 검증이 "재확인"에 그치기 쉽다. 증권 API 코드도 마찬가지였다.

기획 무엇을·어디까지 (범위) 개발 코드 + 왜 이렇게 짰는지 검증 맥락 최소화 · 처음 보는 눈 구조적 문제 발견 시 → 기획·설계로 되돌림 핵심 질문: “이 설계가 무너지는 지점이 있는가?”
같은 AI가 만들고 스스로 검토하면 전제를 다시 의심하기 어렵다 — 기획·개발·검증을 나누고, 검증에는 맥락을 줄여 “구현이 맞는가”가 아니라 “설계가 무너지는 지점이 있는가”를 묻게 했다

실제로 나눈 방식은 이렇다. 코드를 생성한 AI에게는 "왜 이렇게 짰는지" 근거를 스펙 문서 인용과 함께 남기게 했다. 검증을 맡은 AI(또는 사람)에게는 생성 과정의 맥락을 최소한만 주고, 공식 스펙 원문과 코드만 나란히 놓고 "이 코드가 스펙과 다른 지점이 있는가"를 묻게 했다. 맥락을 줄일수록 오히려 "이 전제가 맞나"를 더 잘 캐물었다.

그리고 이 조직에서는 이 검증을 통과한 코드라도, 실제 매매 로직을 바꾸는 변경은 사람이 최종 승인한 뒤에만 적용된다. AI가 코드를 얼마나 잘 짜든, "코드가 스펙과 일치한다"와 "이 로직을 실제로 적용해도 된다"는 여전히 다른 결정이기 때문이다.

오늘의 정리

  1. MCP는 AI 도구가 외부 API·문서에 표준화된 방식으로 접근하게 하는 프로토콜이고, 증권사 API 코드를 AI에게 맡길 때 문서를 통째로 복사·붙여넣는 수고를 줄여준다.
  2. 다만 MCP 서버가 다 같은 신뢰 수준은 아니다 — 증권사가 직접 만든 공식 서버(한국투자증권)와 제3자가 만든 비공식 서버(토스증권 등)는 구분해서 다뤄야 한다.
  3. AI가 짜준 코드는 존재하지 않는 엔드포인트를 그럴듯하게 만들어내거나 에러 처리를 누락하는 방식으로 틀리기 쉬우므로, 공식 스펙과의 대조 없이 그대로 쓰면 안 된다.
  4. 코드를 만드는 역할과 검증하는 역할을 분리하고, 실계좌·실키에 닿기 전 모의투자에서 먼저 검증하는 단계를 거쳐야 하며, 실제 로직 적용은 별도의 사람 승인을 거쳐야 한다.

다음 글에서는 다시 초심으로 돌아가, 파이썬 자동매매를 처음 배우는 사람을 위한 학습 순서를 로드맵으로 정리해본다.

이 글에서 다룬 워크플로는 코드 생성·검증 과정에 대한 것이며, 실제 매매 성과나 수익을 다루지 않습니다. 언급된 MCP 서버·저장소는 공개된 정보를 근거로 설명했을 뿐 특정 제품·서비스를 추천하는 것이 아니며, 실키·실계좌·서버 상세는 담고 있지 않습니다. 투자 조언이 아니며 특정 종목이나 매매기법을 추천하지 않습니다. 수익을 보장하지 않으며, 투자 손실에 대한 책임은 투자자 본인에게 있습니다.

함께 보면 좋은 글

← 전체 글 목록