토스증권 자동화 TOS 보안 경계 2026 – 조회 봇과 주문 봇을 가르는 체크리스트

Posted on by

자동화 좋아하는 사람은 여기서 한 번 멈춘다.

내 계좌를 스크립트가 읽는 것과 내 계좌로 스크립트가 주문하는 것은 겉보기엔 비슷해도 실제론 전혀 다른 문제다.

조회 자동화는 편의의 문제다. 주문 자동화는 약관, 세션, 권한, 손실 책임이 한꺼번에 붙는다.

그래서 2026년 기준 토스증권 자동화를 볼 때 제일 먼저 해야 할 질문은 이게 기술적으로 되냐가 아니라 어디까지를 허용 가능한 범위로 볼 거냐다.

100자 요약

  • 토스증권 자동화에서 상대적으로 보수적으로 검토할 수 있는 범위는 조회 자동화다.
  • 주문 자동화는 비공식 웹 세션 재사용, 계좌 권한, 약관 위반 가능성, 실거래 손실이 같이 묶여서 리스크가 훨씬 크다.
  • 특히 비공식 CLI나 내부 API 재사용 계열은 되더라도 바로 돌리면 안 되는 영역으로 보는 게 맞다.
  • 내 기준의 실전 경계선은 이거다.
  • 계좌 조회, 요약, export, JSON snapshot: 제한적 검토 가능
  • 주문 실행, 정정, 취소, 장시간 권한 유지, 무인 반복 실행: 보수적으로 중단

한 줄로 줄이면 이거다.

조회 봇은 읽기 전용 운영 문제고, 주문 봇은 실계좌 권한 문제다. 둘을 같은 선상에 놓으면 안 된다.

원글 먼저 확인

이 글은 토스증권 자동화의 TOS/보안 경계만 깊게 본 후속 글이다. tossinvest-cli의 실제 명령 흐름과 6단계 안전 게이트를 먼저 보려면 비공식 증권 CLI를 실전에 붙이기 전에 봐야 할 것 2026을 같이 보는 편이 빠르다.

먼저 보면 좋은 사람

  • 토스증권 데이터를 개인 대시보드나 에이전트 루프에 붙이고 싶은 사람
  • 조회 자동화와 주문 자동화의 리스크가 왜 다른지 헷갈리는 사람
  • 비공식 CLI나 브라우저 세션 재사용 툴을 보기 전에 기준선부터 세우고 싶은 사람
  • “신기하네”보다 “어디서 멈춰야 하지?”가 더 궁금한 사람

2026년 5월 7일 리프레시 기준

이번 업데이트의 핵심은 글의 결론을 바꾸는 게 아니다.

오히려 기존 결론을 더 딱딱하게 굳히는 쪽이다.

조회는 제한적으로 검토, 주문은 기본 중단이라는 선은 그대로 둔다.

다만 4월 초 버전은 기준표가 조금 짧았다.

그래서 5월 7일 리프레시에서는 세 가지를 더 붙였다.

  • TOS와 보안 경계를 한 표에서 같이 본다.
  • read-only lane과 write lane을 운영 문서 용어로 나눈다.
  • dry-run, 로그, 사람 승인 게이트를 실제 체크리스트로 넣는다.

이런 글은 괜히 멋있게 쓰면 안 된다.

금융 자동화는 시 한 편보다 체크박스 하나가 더 사람을 살린다.

특히 AI 에이전트에 증권 계좌 데이터를 붙일 때는 더 그렇다.

에이전트가 똑똑해졌다고 해서 계좌 권한을 넓게 줘도 되는 건 아니다.

똑똑한 도구일수록 권한은 더 작게 줘야 한다.

3단계 분류표

토스증권 자동화를 검토한다면 기능을 먼저 세 단계로 나누는 게 좋다.

기능 이름보다 외부 부작용이 있는지를 본다.

단계 예시 기본 판단 운영 문장
read-only 잔고 조회, 보유 종목 조회 제한적 검토 읽고 저장하되 주문과 연결하지 않는다
prepare 주문 preview, 후보 주문 생성 매우 보수적 주문 흐름의 입구로 보고 별도 승인한다
write 주문, 취소, 정정 기본 중단 실계좌 상태를 바꾸므로 자동 실행하지 않는다

여기서 함정은 prepare 단계다.

주문 preview는 아직 체결이 아니다.

하지만 주문 구조 안으로 들어간 작업이다.

그래서 조회와 같은 lane에 두면 안 된다.

미리보기니까 괜찮다가 아니라 미리보기부터 주문 권한 근처다로 봐야 한다.

read-only lane을 만들 때의 최소 조건

조회 자동화도 아무렇게나 돌리면 안 된다.

읽기 전용이라는 말은 편하지만, 로그인 세션과 계좌 정보가 들어가는 순간 보안 사고 후보가 된다.

내가 개인 운영 문서에 적는다면 최소 조건은 이렇다.

항목 기준 이유
세션 저장 위치와 만료 시간을 문서화 세션 파일이 곧 계좌 접근 표면이 될 수 있음
출력 범위 필요한 필드만 저장 잔고, 계좌번호, 거래내역 노출을 줄여야 함
저장 위치 로컬 암호화 또는 접근 제한 폴더 대시보드 편의보다 유출 피해가 큼
실행 주기 사람이 이해 가능한 간격 불필요한 반복 조회는 리스크와 노이즈를 키움
주문 연결 기본 금지 읽기 결과가 바로 실행으로 이어지면 lane이 깨짐

이 조건을 못 적겠다면 아직 자동화할 때가 아니다.

코드가 짧은 것과 운영이 단순한 것은 다르다.

한 줄짜리 스크립트도 계좌 세션을 들고 있으면 운영 문서가 필요하다.

주문 lane은 왜 따로 빼야 하나

주문 lane은 결과가 바로 바깥세상에 남는다.

잔고 조회가 틀리면 화면이 틀린다.

주문이 틀리면 계좌가 바뀐다.

이 차이는 꽤 크다.

특히 AI 에이전트나 스케줄러가 붙으면 사고 모양이 더 피곤해진다.

사람이 한 번 잘못 누르는 사고는 한 번으로 끝날 수 있다.

하지만 자동화가 잘못 돌면 같은 실수를 반복한다.

시장가 주문, 중복 주문, 취소 실패, 네트워크 재시도 같은 조합은 생각보다 빨리 커진다.

그래서 주문 lane에는 최소 네 가지 문장이 있어야 한다.

  1. 주문 실행은 기본 비활성화한다.
  2. 주문 preview는 주문 실행과 같은 승인 그룹에 둔다.
  3. 모든 주문 후보는 사람 확인 후에만 실행한다.
  4. 무인 스케줄 주문은 별도 법무, 보안, 손실 한도 검토 전까지 금지한다.

이 문장이 답답해 보이면 정상이다.

금융 자동화에서 답답함은 비용이 싼 보험이다.

dry-run은 장난감이 아니라 계약서다

dry-run은 한 번 테스트해보자가 아니다.

운영에서는 실행 권한을 주기 전 계약서에 가깝다.

dry-run 로그에는 최소한 아래 정보가 남아야 한다.

로그 항목 남겨야 하는 이유
실행 시각 나중에 어떤 자동화가 움직였는지 추적
입력 데이터 잘못된 잔고, 낡은 가격, 누락된 종목 확인
생성된 행동 어떤 주문 후보가 만들어졌는지 확인
차단 사유 왜 실제 주문으로 가지 않았는지 확인
승인자 사람이 마지막으로 봤는지 확인

이 표가 없으면 dry-run이 아니라 분위기 테스트에 가깝다.

분위기는 블로그 제목에는 좋지만 계좌 자동화에는 별 도움이 안 된다.

AI 에이전트에 붙이기 전 승인 게이트

AI 에이전트가 들어오면 기준은 더 보수적으로 잡는 게 맞다.

에이전트는 빠르다.

빠른 도구가 잘못된 권한을 받으면 빠르게 틀린다.

그래서 아래 게이트를 통과하지 못하면 주문 계열 도구를 열지 않는 쪽이 낫다.

게이트 질문 실패하면
범위 에이전트가 읽을 수 있는 계좌 정보가 어디까지인가 읽기 범위 축소
권한 주문 함수가 도구 목록에 노출되어 있는가 주문 도구 제거
승인 사람이 마지막 버튼을 누르는가 human approval 추가
로그 입력, 판단, 후보 행동이 남는가 로그 스키마부터 작성
복구 잘못 실행됐을 때 멈추는 방법이 있는가 kill switch 작성

여기서 제일 중요한 건 권한이다.

프롬프트로 주문하지 마라고 쓰는 것보다 도구 목록에서 주문 함수를 빼는 게 더 강하다.

말로 막는 것보다 구조로 막는 게 낫다.

지금 결론

질문 내 판단
계좌 요약을 JSON으로 저장해도 되나 기술적으로는 가능할 수 있어도 TOS와 보안 경계를 먼저 봐야 함
조회 전용 봇은 바로 써도 되나 읽기 전용이라도 계정 세션을 만지는 순간 보수적으로 접근
주문 자동화는 더 위험한가 훨씬 위험함
이유가 보안 때문인가 보안 + 약관 + 세션 + 실손실 책임이 다 붙음
에이전트에 바로 연결해도 되나 조회도 최소 권한, 주문은 사람 승인 없으면 멈추는 쪽 권장

핵심은 단순하다.

조회 자동화는 데이터 파이프의 문제지만, 주문 자동화는 권한 위임의 문제다.

왜 조회 봇과 주문 봇을 따로 봐야 하나

이 둘을 같이 보면 감각이 무너진다.

조회 봇이 하는 일은 보통 이렇다.

  • 계좌 잔고 읽기
  • 포트폴리오 비중 읽기
  • 체결 내역 백업
  • 시세 데이터 모으기
  • CSV나 JSON으로 저장

여기서는 실수의 결과가 대체로 틀린 대시보드, 낡은 스냅샷, 로그 누락이다.

반면 주문 봇은 다르다.

  • 실수로 잘못된 종목 주문
  • 잘못된 수량/가격
  • 취소/정정 실패
  • TTL 없는 권한 유지
  • 사람 확인 없이 반복 실행

여기서는 실수의 결과가 바로 돈이다.

그래서 같은 “자동화”라는 단어를 써도 실제 운영 설계는 완전히 달라져야 한다.

내가 선 긋는 허용 범위

이건 법률 자문이 아니라 실무 운영 기준이다. 내가 개인 시스템을 굴린다면 대충 이렇게 자른다.

사용 범위 판단 이유
계좌 요약 조회 제한적 가능 읽기 전용이지만 세션 보호 필요
포지션/체결 export 제한적 가능 백업/로그 성격
JSON 출력 후 대시보드 적재 제한적 가능 외부 실행보다 데이터 정리 목적
주문 preview 매우 보수적 이미 실거래 직전 단계
주문 place/cancel/amend 사실상 중단 외부 부작용이 바로 발생
스케줄러로 무인 주문 반복 금지에 가까움 사고 범위가 너무 큼

여기서 제일 중요한 줄은 마지막 둘이다.

조회 자동화는 검토 대상일 수 있어도, 무인 주문 자동화는 “편하다”보다 먼저 “왜 이걸 꼭 자동화해야 하지?”를 물어야 한다.

TOS와 보안 경계는 왜 같이 봐야 하나

많은 사람이 약관은 법무팀 문제, 보안은 엔지니어 문제처럼 분리해서 본다. 실계좌 자동화에선 그게 잘 안 통한다.

비공식 CLI나 웹 세션 재사용 구조를 보면 보통 이런 질문이 같이 나온다.

  • 공식 API인가
  • 브라우저 세션을 재사용하는가
  • 로그인/토큰이 어디에 남는가
  • 장시간 권한이 유지되는가
  • 서비스 제공자가 예상한 사용 방식인가

즉 약관 리스크와 보안 리스크가 같은 문장 안에서 붙는다.

기술적으로 된다고 해서 운영 허용 범위가 자동으로 생기지 않는다. 오히려 금융 계정은 그 반대다. 기술적으로 될수록 더 보수적으로 봐야 할 때가 많다.

체크리스트: 여기서부터는 멈춰라

아래 신호가 보이면 조회 자동화조차 한 단계 뒤로 물러나는 게 낫다.

1. 로그인 세션을 장시간 파일로 저장한다

세션이 살아 있는 한 리스크도 같이 살아 있다.

2. dangerous, skip, force 류 플래그가 주문 경로에 있다

이런 이름은 괜히 붙은 게 아니다. 도구 제작자가 “여긴 위험 구간”이라고 직접 써붙인 셈이다.

3. TTL 없는 권한 유지가 가능하다

짧게 열고 닫아야 할 권한이 계속 남으면 사고 범위가 커진다.

4. preview 없이 바로 execute로 간다

주문 직전 검증이 없는 자동화는 생각보다 쉽게 망한다.

5. 사람이 마지막 확인을 하지 않는다

계좌 자동화에서 사람이 없어지는 순간, 편의는 늘고 사고 비용도 커진다.

실전 운영 기준으로 다시 쓰면

내가 이걸 개인 시스템 규칙으로 적는다면 이렇게 쓴다.

  1. 조회 자동화와 주문 자동화를 다른 capability로 분리한다.
  2. 조회 자동화는 read-only lane으로 묶는다.
  3. 주문 관련 명령은 기본 off로 둔다.
  4. 세션 저장 위치와 만료 시간을 문서화한다.
  5. preview 없는 실행은 막는다.
  6. 외부 부작용이 있는 행동은 사람 승인 없이 스케줄링하지 않는다.

이 여섯 줄이면 글은 짧아도 운영 기준은 꽤 단단해진다.

실수 TOP 4

1. 조회 봇도 자동화니까 주문 봇이랑 비슷하다고 보는 실수

아니다. 읽기와 실행은 같은 등급이 아니다.

2. 기술적으로 되니까 운영상 허용된다고 착각하는 실수

실계좌 시스템에선 제일 위험한 착각이다.

3. 비공식 툴을 “개인용이니 괜찮겠지”로 넘기는 실수

개인용이어도 계좌는 계좌다.

4. 편의성 때문에 승인 루프를 지우는 실수

금융 자동화에서 귀찮음은 종종 안전장치다.

FAQ

Q. 조회 전용이면 안전한 건가

상대적으로 덜 위험할 뿐이다. 세션과 약관 경계는 여전히 본다.

Q. 주문 preview도 하지 말아야 하나

preview는 실행보다 낫지만, 이미 주문 흐름 가까이에 들어간 단계라 보수적으로 봐야 한다.

Q. 공식 API가 나오면 달라지나

많이 달라진다. 그래도 승인, 로그, 권한 TTL은 남겨야 한다.

Q. 에이전트에 붙일 땐 뭐가 제일 중요하나

read-only lane과 human approval lane을 분리하는 거다.

관련 글

참고 자료/공식 출처