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

AI 에이전트에 주문 권한을 열면 — MCP 트레이딩에서 무엇을 조심해야 하나

지난 글에서 "AI에게 매매 판단까지 맡기면 안 되는 이유"를 정리했다. 그 글은 원론이었다. 그런데 이 글을 준비하며 찾아보니, 원론을 이야기하는 사이에 현실 쪽에서 문이 이미 열려 있었다. 여러 증권사와 거래 플랫폼이 AI 에이전트에게 시세·잔고 조회를 넘어 주문 실행 권한까지 여는 서비스를 공개 발표했다. 이 글은 그 상황을 정리하고, 그 문 앞에서 무엇을 조심해야 하는지를 따져본 기록이다.

이 글의 범위

이 글은 특정 서비스를 권하거나 "어떤 게 제일 좋다"를 가리는 글이 아니다. 어떤 서비스도 추천하지 않고, 가입·이용을 권유하지 않는다. 다루는 것은 두 가지뿐이다 — 조회용 MCP와 주문 실행 MCP가 구조적으로 어떻게 다른가, 그리고 주문 권한을 여는 쪽이 남겨야 할 안전장치는 무엇인가.

또 하나 못박아둔다. 아래에 언급하는 서비스와 기능은 필자가 2026년 7월 29일 시점에 공개된 발표·보도 자료에서 확인한 범위이며, 발표되지 않은 기능을 추정하지 않았다. 서비스는 계속 바뀌므로 실제 조건은 각자 공식 안내로 다시 확인해야 한다. 이 조직 자체는 AI에게 매매 판단이나 주문 권한을 넘긴 적이 없고, 이 글도 그 경험담이 아니라 바깥에서 벌어진 일에 대한 관찰이다.

조회용 MCP와 주문 실행 MCP는 무엇이 다른가

MCP(Model Context Protocol)는 AI 모델이 외부 도구·데이터에 접근하는 방식을 표준화한 규격이다. 이전 글에서는 주로 "AI가 증권사 API 문서를 스스로 읽고 코드를 짜게 하는" 용도로 다뤘다. 그때 다룬 MCP 서버들은 대부분 문서를 검색하거나 시세·잔고를 읽어오는 쪽이었다.

조회용 MCP와 주문 실행 MCP의 차이는 "기능이 하나 더 있다"가 아니라 되돌릴 수 있느냐 없느냐다. 조회 도구가 틀린 값을 주면 결과는 잘못된 답변이고, 사람이 읽고 이상하다고 판단하면 거기서 끝난다. 주문 도구가 틀린 값을 받으면 결과는 체결이고, 체결은 취소가 아니라 반대매매로만 되돌릴 수 있다. 그 사이에 손실이 확정된다.

권한 관점에서 정리하면 이렇다.

같은 프로토콜, 같은 설치 방식, 같은 대화창이라 겉보기엔 연속된 기능처럼 느껴진다. 그런데 실패했을 때 되돌릴 수 있는지를 기준으로 보면 완전히 다른 두 물건이다. 이 착시가 이 글에서 가장 경계하는 지점이다.

지금 어디까지 열렸나 — 공개 발표 기준

아래는 필자가 2026년 7월 29일에 공개 자료로 확인한 범위다. 순위나 추천이 아니라 "이런 상태다"의 나열이며, 각 서비스의 상세 조건은 공식 안내를 봐야 한다.

정리하면, "AI가 대신 주문한다"는 건 더 이상 개발자 실험실 이야기가 아니다. 동시에 업계가 한 방향으로 합의한 것도 아니다 — 읽기에서 끊는 쪽과 실행까지 여는 쪽이 같은 시기에 공존하고 있고, 규제기관은 이제 막 프레임을 잡는 중이다. 이럴 때 이용자가 기댈 수 있는 건 업계 표준이 아니라 자기 쪽 설계뿐이다.

자연어 주문의 위험 — 오해·환각·되돌릴 수 없음

"삼백만 원어치 정리해줘" 같은 문장이 주문이 되는 구조에서 무엇이 틀어질 수 있는지 세 갈래로 봤다.

오해. 자연어는 원래 모호하다. "좀 줄여줘"가 절반인지 전량인지, "아까 그거"가 어느 종목인지, "시장가로 빨리"가 얼마까지 감수하겠다는 뜻인지는 문장에 없다. API 파라미터는 모호할 수 없지만 사람 말은 모호할 수 있고, 그 간극을 모델이 자기 판단으로 메운다. 사람끼리라면 "그게 무슨 뜻이죠?"로 끝날 오해가 여기서는 체결로 끝난다.

환각. 지난 글에서 정리했듯 AI는 근거가 부족해도 그럴듯한 문장을 만들어낸다. 코드 생성에서 이 문제는 "실행하면 에러가 나서" 비교적 빨리 드러났다. 주문 도구에서는 다르다. 존재하지 않는 근거로 만들어진 판단도 파라미터만 유효하면 정상적으로 실행된다. 틀렸다는 사실이 드러나는 시점이 실행 전이 아니라 실행 후로 밀린다는 게 핵심이다.

되돌릴 수 없음. 여기에 하나 더 얹히는 게 프롬프트 주입 위험이다. 에이전트가 뉴스나 게시글 같은 외부 텍스트를 읽어 판단하는 구조라면, 그 텍스트 안에 에이전트를 향한 지시문이 섞여 들어올 수 있다. 조회만 하는 에이전트에서 이건 "이상한 요약"으로 끝나지만, 주문 권한이 붙어 있으면 외부에서 흘려보낸 문장이 실제 거래로 이어지는 경로가 생긴다. 키·설정값을 코드에서 분리해 관리하는 문제가 "유출되면 남이 내 계좌를 조회한다"였다면, 여기서는 "유출되거나 조작되면 남이 내 계좌로 주문한다"로 결과가 한 단계 올라간다.

권한을 나눠 주는 설계 — 읽기, 모의, 실주문을 분리한다

그래서 이 문제를 "AI를 믿을 것인가"로 두면 답이 안 나온다고 본다. 믿음의 문제가 아니라 권한 설계의 문제로 두는 편이 낫다. 이 조직이 코드 생성에서 쓰는 원칙도 같다 — 기획·개발·검증 역할을 나눈 것처럼, 도구 권한도 한 덩어리로 주지 않는다.

최소한 세 층으로 나눠 생각할 수 있다.

핵심은 같은 자격 증명 하나로 세 층이 다 열리지 않게 하는 것이다. 아래는 개념만 보여주는 generic 의사코드다.

python 코드 보기
# 권한을 계층으로 쪼개고, 실주문 층은 별도 자격 증명으로만 열리게 한다
TOOL_TIERS = {
    "read":     {"quote", "balance", "orderable_cash"},
    "paper":    {"validate_order", "submit_paper_order"},
    "live":     {"submit_live_order", "cancel_live_order"},
}

def resolve_tools(session):
    tools = set(TOOL_TIERS["read"])
    if session.paper_enabled:
        tools |= TOOL_TIERS["paper"]
    # 실주문 층은 별도 자격 증명 + 명시적 활성화가 둘 다 있을 때만 붙인다
    if session.live_credential_present and session.live_explicitly_enabled:
        tools |= TOOL_TIERS["live"]
    return tools

여기서 중요한 건 live 층이 조건 두 개를 모두 요구한다는 점이다. 자격 증명이 있다는 이유만으로 실주문 도구가 자동으로 붙으면, 사용자가 "조회만 해보려고" 붙인 연결에서도 주문 도구가 노출된다. 조건을 하나로 두면 실수 한 번이 곧바로 실주문 경로를 연다.

한 가지 덧붙이자면, 로빈후드가 발표한 구조에서 별도 계좌에 전용 예산을 배정한다는 부분은 이 계층 분리를 계좌 단위로 구현한 사례로 읽힌다. 어느 쪽이든 원리는 같다 — 에이전트가 최악의 경우 움직일 수 있는 금액의 상한을, 에이전트가 아니라 사람이 미리 정해둔다. 이건 실전 투입 전 먼저 만든 안전장치에서 "예산 한도"를 제일 먼저 만든 이유와 정확히 같은 발상이다.

사람의 최종 승인 게이트를 남기는 법

계층 분리까지 해도 마지막 질문이 남는다. 실주문 층이 열린 상태에서, 실제 체결 직전에 사람이 개입할 지점이 있느냐다.

승인 게이트가 실제로 작동하려면 몇 가지 조건이 필요하다고 본다.

python 코드 보기
def gate(order, policy):
    # 사전에 사람이 정한 한도 안쪽만 통과, 나머지는 사람 확인으로 넘긴다
    if not policy.allows(order.symbol_universe, order.side, order.notional):
        return require_human_approval(order, timeout_action="reject")
    if order.notional > policy.auto_limit:
        return require_human_approval(order, timeout_action="reject")
    return approve(order)

timeout_action="reject"가 이 코드에서 제일 중요한 한 줄이다. 사람이 자리를 비웠을 때 무슨 일이 일어나는지가 안전장치의 성격을 결정한다. 응답이 없을 때 통과시키는 게이트는 바쁜 날엔 게이트가 아니다.

자주 하는 실수

오늘의 정리

  1. 조회용 MCP와 주문 실행 MCP는 기능 하나 차이가 아니라 되돌릴 수 있느냐 없느냐의 차이다 — 조회 실패의 비용은 잘못된 정보지만, 주문 실패의 비용은 체결된 거래다.
  2. 2026년 7월 말 기준으로 국내외 여러 증권사·플랫폼이 AI 에이전트에 주문 실행 권한을 여는 서비스를 공개 발표했고, 동시에 읽기 전용으로 제한하는 회사도 있다 — 업계가 한 방향으로 합의한 상태가 아니다.
  3. 자연어 주문의 위험은 오해(모호한 말을 모델이 자기 판단으로 메움), 환각(근거 없는 판단도 파라미터만 맞으면 실행됨), 되돌릴 수 없음(프롬프트 주입이 곧 거래로 이어지는 경로) 세 갈래다.
  4. 권한은 읽기·모의·실주문 세 층으로 쪼개고, 실주문 층은 별도 자격 증명과 명시적 활성화가 둘 다 있을 때만 열리게 하는 편이 안전하다. 최악의 경우 움직일 수 있는 금액의 상한은 사람이 미리 정한다.
  5. 승인 게이트는 실행 전이어야 하고, 모델의 요약이 아니라 실제 전송될 파라미터를 보여줘야 하며, 응답이 없을 때 통과가 아니라 거부로 떨어져야 한다.

이 글은 공개된 발표·보도 자료를 근거로 2026년 7월 29일 시점에 확인한 범위를 정리한 것이며, 언급된 서비스의 이용을 권유하거나 특정 제품을 추천·폄하하려는 것이 아닙니다. 발표되지 않은 기능은 다루지 않았고 서비스 조건은 변경될 수 있으므로 각 사 공식 안내를 확인하시기 바랍니다. 이 블로그의 익명화 원칙에 따라 필자의 실계좌·실키·서버 상세는 담고 있지 않으며, 매매 성과나 손익 수치도 다루지 않습니다. 투자 조언이 아니며 특정 종목이나 매매기법을 추천하지 않습니다. 수익을 보장하지 않으며, 투자 손실에 대한 책임은 투자자 본인에게 있습니다.

함께 보면 좋은 글

← 전체 글 목록