“사람이 승인한다”는 코인 거래소 AI, 뜯어보니 ‘설명서 속 부탁’이었다

승인 절차가 있다는 말과 사람이 승인한다는 말은 다르다.

거래소 다섯 곳의 AI 연동 문서를 열어봤다. 확인란에 값을 채우는 쪽이 사람이 아닌 곳이 있었고, 어떤 확인은 코드가 아니라 설명서에 적어 둔 부탁이었다. 승인이 있느냐보다 그 승인이 어느 층에 놓여 있느냐가 갈렸다.

다섯 곳이 같은 말을 했다

거래소들은 하나같이 사람이 확인한다고 말했다. 다섯 곳 모두 출시 자료나 개발자 문서에 그렇게 적어 두었다. 바이낸스(Binance)는 에이전트 OS 출시 공지를 이 문장으로 닫았다.

“바이낸스 에이전트 OS는 자율 거래 시스템이 아니다. 승인과 안전장치, 그리고 당신의 신중한 판단을 대신해주지 않는다.”

빗썸은 자금이 움직이는 스킬에 사용자 확인 단계가 들어 있다고 안내했고, 업비트는 쓰기 작업 전에 사용자가 CONFIRM을 직접 입력하게 했다. 크라켄(Kraken)은 위험한 도구를 부를 때 확인 값을 요구하고, 코빗은 키 권한을 일곱 갈래로 쪼갰다.

여기까지는 전부 사실이다. 다만 확인이라는 말이 다섯 곳에서 같은 뜻으로 쓰이지는 않았고, 무엇이 그 확인을 강제하는지도 제각각이었다.

승인 버튼은 누가 누르나

크라켄부터 보자. 크라켄 MCP 서버는 아무 옵션 없이 띄우면 시세와 계좌 조회, 모의매매만 열고 실거래 도구는 붙이지 않는다. 주문을 낼 수 있게 하려면 사용자가 -s all을 넣어 서버를 다시 띄워야 하니 여기까지는 조심스러운 설계다.

문제는 그다음인데 크라켄 문서는 위험 도구의 확인 절차를 이렇게 적었다.

“위험으로 표시된 도구(주문 접수, 출금, 이체)는 서버가 --allow-dangerous 옵션으로 시작되지 않은 한, 호출하는 에이전트가 도구 입력값으로 acknowledged: true를 전달해야 한다.”

“Tools marked dangerous (order placement, withdrawals, transfers) require the calling agent to pass acknowledged: true in the tool input unless the server was started with –allow-dangerous.”

주문과 출금, 이체에 확인이 붙는다는 설명이다. 그런데 그 확인 값(acknowledged: true)을 넘기는 주체가 호출하는 에이전트다. 사람이 누르는 버튼과는 다르다. AI가 스스로 입력란에 채워 넣는 값이고, 그마저 없앨 수 있다. 같은 문서는 --allow-dangerous를 확인 게이트를 끄는 옵션으로 설명하고, 크라켄 CLI 저장소 문서는 이 상태를 자율 모드라고 부른다. 계단이 셋인 셈이다. 기본값은 조회 전용이고, -s all이 실거래를 열고, --allow-dangerous가 확인을 없앤다. 두 계단 모두 사용자가 의도적으로 올라야 하지만, 다 오른 뒤에는 사람이 다시 등장하지 않는다.

설명서에 적힌 부탁

업비트는 방식이 다른데 업비트 에이전트 스킬 문서에는 쓰기 작업 전 절차가 한 줄로 적혀 있다.

“어떠한 쓰기 작업을 실행하기 전에도, 전체 명령을 보여주고 사용자에게 CONFIRM을 입력하도록 요청하라.”

“Before executing any write operation, show the full command and ask the user to type CONFIRM.”

이 문서를 읽는 주체는 사람이 아니라 AI다. 명령 전문을 보여주고 사용자에게 CONFIRM을 입력받으라는 지시문이어서, AI가 지시를 따르면 사람이 승인하게 되지만 AI가 이를 무시하면 승인 절차 없이 그대로 실행된다. 서버가 내리는 빗장이라기보다 설명서에 적어 둔 부탁에 가깝다. 빗썸도 같은 층에 있다. 빗썸 스킬 문서는 자금이 움직이는 스킬에 확인 단계가 들어 있다고 안내하면서 한 문장을 덧붙였다.

“출금이나 원화 입금처럼 실제 자금이 움직이는 작업이 포함된 스킬에는 사용자 확인 단계가 포함되어 있습니다. 임의로 제거하지 마세요.”

제거하지 말라는 당부는 제거할 수 있을 때 나온다. 확인 단계가 스킬 파일 안에 문장으로 들어 있고 그 파일은 투자자가 자기 컴퓨터에 내려받아 둔 텍스트이니, 열어서 지우면 지워진다.

빗썸에는 조회 전용 프로필도 있어서, 설정 파일에서 키를 나눠 두면 주문과 출금이 아예 막힌다. 이쪽은 코드가 막는 층이고, 앞의 확인 단계와는 성격이 다르다. 다만 기본값이 아니라 투자자가 직접 켜는 선택지다.

빗썸은 사후에 확인할 자리도 마련해 두었다. 날짜별 실행 로그가 파일로 쌓이고, 별도 명령으로 최근 작업 내역을 훑어볼 수 있다. 주문이 나가는 순간을 막지는 못해도 무엇이 나갔는지는 남는다. 승인이 사전에만 있지는 않다.

공지에 없던 모드

바이낸스는 자율 거래가 아니라고 못을 박았지만, 제품 설명은 조금 다르다. 테크크런치(TechCrunch)는 사용자가 주문마다 승인을 받게 할지, 아니면 권한을 설정한 뒤 자율 실행을 허용할지 고를 수 있다고 전했다. 영어 원문이 쓴 표현은 자율적으로 거래를 실행한다(execute trades autonomously)이다. 자율 실행이 선택지로 존재하고, 출시 공지에서 부정한 것은 기본값이지 기능이 아니었다.

한도도 매매에는 걸리지 않는다. 같은 보도에 따르면 일반 스왑은 하루 5만달러, 디파이 거래는 10만달러로 묶이지만 현물과 선물 매매에는 별도 상한이 없어서, 하위 계정에 넣어 둔 잔액이 사실상의 한계다.

거래소가 무엇을 보는지는 또 다른 문제다. 제프 리(Jeff Li) 바이낸스 제품 담당 부사장은 같은 인터뷰에서 이렇게 말했다.

“우리는 사용자의 행동(주문)에 담긴 실제 추론 과정을 볼 수 없다.”

“We really cannot see the reasoning of what the user’s action is.”

에이전트가 왜 그 주문을 냈는지 거래소는 보지 못한다. 잘못된 정보 탓인지 누군가의 조작 탓인지도 구분하지 못한다. 자율 모드가 켜지면 판단도 승인도 거래소 시스템 밖에서 끝난다.

두 달 전에 자기가 한 말

같은 회사가 두 달 전에는 다르게 말했다. 바이낸스는 에이전트 OS를 내놓기 전인 6월 11일 가상자산 AI 에이전트 보안 가이드라인을 내고 최소 권한 원칙을 권했다. 가이드라인이 내건 기본 원칙은 권한을 엄격히 관리하고, 결과물을 독립적으로 검증하며, 최종 단계에서 인간이 감독하라는 것이다. 같은 문서는 AI 에이전트가 인간의 의사결정을 대체하는 것이 아니라 지원하는 도구로 쓰일 때 가장 효과적이라고도 적었다.

두 달 뒤 나온 제품에는 인간이 최종 단계에 등장하지 않는 모드가 들어 있다. 가이드라인과 제품이 충돌한다기보다, 가이드라인은 권고이고 제품은 선택지를 열어 둔 쪽에 가깝다. 권고와 기본값과 기능은 각각 다른 자리에 있다.

코빗은 열쇠로 막는다

코빗은 확인 단계를 두지 않았고 코빗 CLI 문서는 키를 이름별로 보관하고 작업할 때 어느 키를 쓸지 지정하게 한다. 조회만 할 키와 주문까지 낼 키를 따로 만들어 두는 방식이고, 개발자센터에서 키를 만들 때 권한이 일곱 종류로 갈린다.

실행 시점에 사람을 부르는 대신 애초에 못 하게 만든다. 문서는 자금을 옮기는 쓰기 요청을 자동으로 재시도하지 않는다고 적었고, 모든 작업을 로컬 저널에 남긴다. 층이 다를 뿐 약한 방식은 아니어서, 키를 잘못 준 사고는 그 키의 권한 안에 갇히고, 키를 지우면 끝난다.

확인이 놓인 층은 거래소마다 다르다.

아무 층도 없는 경우

공식 도구가 권한을 쪼개는 사이, 검색 결과의 윗자리는 다른 것이 차지하기도 한다. 두나무는 AI 접속 서버를 공식으로 낸 적이 없는데도 AI 도구를 모아 소개하는 등록 사이트 글라마(Glama)에는 업비트 이름을 단 서버가 여럿 올라와 있다. 개발자라면 누구나 올릴 수 있고 심사하는 곳은 따로 없다.

개중에는 이용자에게 출금 권한이 붙은 API 키를 넣으라고 요구하는 것도 있다. 확인 절차가 코드에 있느냐 설명서에 있느냐를 따지기 전에, 아예 어느 층에도 없는 경우다. 만든 사람이 누구인지도, 키가 어디로 가는지도 확인할 방법이 없다. 거래소가 만들지 않은 도구에는 거래소가 넣은 확인 절차도 없다. 설치 명령은 거래소 공식 문서에 적힌 것만 쓰는 편이 안전하다.

그러면 설계가 잘못됐나

여기까지 읽으면 거래소가 허술하게 만들었다는 인상을 받기 쉽지만, 그렇게 보기는 어렵다. 기본값이 대체로 보수적이다. 크라켄 MCP는 옵션 없이 띄우면 실거래 도구가 붙지 않고, 위험한 도구를 열려면 사용자가 두 번 움직여야 한다. 크라켄의 확인 값도 효과가 없지는 않아서, AI가 위험한 도구를 부를 때 별도 값을 채우게 하면 대부분의 AI 앱이 그 호출을 화면에 띄우고 사람이 끼어들 자리가 남는다.

승인 말고 다른 층에 힘을 준 곳도 있다. 업비트는 전략을 시험하는 백테스트 도구를 실거래 도구와 아예 분리해 계정 정보나 API 키를 요구하지 않는다. 권한이 없으니 승인할 일도 없는 설계다. 크라켄이 내놓은 페이퍼 트레이딩은 문서에 계정도 실제 돈도 필요 없다고 적혀 있고, 코빗은 실서버와 같은 인터페이스를 로컬에 띄우는 샌드박스를 뒀다. 주문을 내기 전에 걸러내는 층이다.

거래소가 투자자 컴퓨터 안을 통제할 권한도 없다. 설명서를 내려받아 고치는 것도, AI 앱 설정을 바꾸는 것도 투자자 영역이어서, 거래소가 할 수 있는 일은 기본값을 안전하게 두고 문서에 적어 두는 데까지다.

문제는 설계가 아니라 공지다. 자율 거래 시스템이 아니라는 문장은 기본값을 설명할 뿐인데, 읽는 쪽은 그런 기능이 아예 없다고 받아들인다. 무엇이 기본값이고 무엇이 선택지인지 갈라 적었다면 오해가 줄었을 자리다.

스위치는 거래소 밖에 있다

층을 몇 겹 쌓아도 마지막 실행은 투자자 컴퓨터에서 일어난다. 거래소가 게으른 탓은 아니다. 표준이 그렇게 짜여 있다.

MCP(Model Context Protocol) 규격은 도구 실행을 모델이 주도하는 구조로 정의하면서, 안전을 위한 요구를 서버가 아니라 애플리케이션 쪽에 걸어 두었다. 규격 문서의 문장은 이렇다.

“신뢰와 안전 및 보안을 위해, 도구 호출을 거부할 수 있는 권한을 가진 인간이 항상 프로세스에 개입(Human-in-the-Loop)해야 한다[권고사항].”

“For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.”

여기서 볼 것은 조동사(SHOULD)다. 규격은 이것을 의무로 적지 않았고, 그렇게 하는 편이 좋다는 권고로 두었다. 권고를 받는 쪽도 거래소 서버가 아닌 투자자의 AI 앱이다. 같은 문서는 민감한 작업에 사용자 확인을 띄우라는 항목도 클라이언트의 권고 목록에 넣었다. 그 앱들에는 확인을 매번 묻지 않게 하는 모드가 있다. 클로드 코드(Claude Code)에는 권한 확인을 건너뛰는 --dangerously-skip-permissions 옵션이 있고, 앤트로픽(Anthropic)은 이 옵션을 대신할 자동 모드를 따로 설계해 공개했다. 건너뛰기가 그만큼 널리 쓰인다는 신호다.

거래소가 만든 확인 절차는 이 앱을 통과한 뒤에야 작동한다. 앱에서 묻지 않기로 해 두면 남는 것은 설명서에 적힌 부탁뿐이다. 거래소가 층을 몇 겹 쌓았는지와 무관하게, 마지막 한 겹은 투자자가 직접 켜고 끈다.

승인이 있느냐를 묻는 것으로는 부족하다. 승인이 어느 층에 있느냐를 물어야 한다. 지금 그 층은 거래소가 아니라 투자자 책상 위에 있다.