비공식 증권 CLI 운영 기준 2026, JSON 조회와 주문 자동화 경계표

2026년 4월 28일 기준, 비공식 증권 CLI는 공식 API가 아니라 개인이 만든 보조 도구로 봐야 한다.

JSON 조회는 대시보드와 로그를 만드는 읽기 작업에 가깝지만, 주문 자동화는 전자금융거래의 거래지시와 계좌 권한을 건드리는 실행 작업이다.

그래서 이 글의 기준은 단순하다.

조회는 제한적으로 검토하고, 주문 자동화는 기본 중단으로 둔다.

무섭게 들리지만 사실 되게 현실적인 말이다.

편한 도구일수록 실계좌 앞에서는 안전벨트가 먼저다.

안전벨트를 귀찮다고 빼면, 그때부터 CLI가 아니라 롤러코스터가 된다.

2026년에 먼저 정해야 할 한 줄

비공식 증권 CLI를 운영 문서에 넣는다면 첫 줄은 이렇게 적는 게 좋다.

이 도구는 공식 증권사 API가 아니며, 읽기 전용 조회와 파일 출력까지만 자동화 후보로 검토한다.

그리고 두 번째 줄은 더 중요하다.

주문, 취소, 정정, 권한 위임, 장시간 세션 보존, 무인 스케줄 실행은 기본 제외한다.

이 두 줄이 있어야 나중에 기능이 늘어나도 기준이 흔들리지 않는다.

도구는 어느 날 갑자기 place order 같은 명령을 지원할 수 있다.

하지만 명령이 생겼다고 운영 허용 범위가 생기는 건 아니다.

자동차에 스포츠 모드가 있다고 매일 골목길에서 눌러야 하는 건 아니잖아.

이번 글이 기존 글과 다른 지점

기존 TECHTAEK 글은 비공식 CLI를 처음 볼 때의 안전 게이트와 TOS 리스크를 설명했다.

이번 글은 그다음 단계다.

개인 시스템이나 팀 문서에 그대로 붙일 수 있는 운영 기준표를 목표로 한다.

그래서 특정 도구 사용법보다 어떤 기능을 어느 lane에 넣을지에 집중한다.

핵심 축은 다섯 개다.

조회
주문
로그
권한
승인

이 다섯 축을 분리하면 토론이 훨씬 쉬워진다.

이거 써도 돼?라는 질문이 어느 lane에 넣을까?로 바뀐다.

그리고 금융 자동화에서는 이 차이가 크다.

1차 분류표: 조회, 경계, 실행

구분	예시	운영 판단	이유
조회 lane	잔고 조회	제한적 검토	계좌 상태를 읽는 작업
조회 lane	보유 종목 조회	제한적 검토	사람이 다시 확인 가능
조회 lane	체결 내역 export	제한적 검토	회계/기록 보조에 가까움
조회 lane	JSON snapshot 저장	제한적 검토	외부 부작용이 파일로 끝남
경계 lane	주문 preview	매우 보수적	주문 흐름 직전 단계
경계 lane	인증 상태 확인	조건부 검토	세션 정보 노출 가능
경계 lane	토큰 refresh	기본 차단 후보	권한 수명 연장 문제
실행 lane	주문 실행	중단	시장과 계좌 상태를 바꿈
실행 lane	주문 취소	중단	이미 주문 권한 lane
실행 lane	주문 정정	중단	가격/수량 변경 리스크
실행 lane	무인 스케줄 주문	중단	반복 손실과 책임 문제가 큼

이 표에서 제일 중요한 줄은 주문 preview다.

preview는 실행은 아니지만 조회도 아니다.

아직 안 샀으니 괜찮지라고 보면 애매해진다.

운영 기준에서는 preview를 주문 lane의 입구로 둬야 한다.

입구를 조회 lane에 넣으면, 다음 사람이 그 문을 너무 쉽게 지나간다.

JSON 조회를 제한적으로 볼 수 있는 이유

JSON 조회가 상대적으로 다루기 쉬운 이유는 결과가 데이터로 끝나기 때문이다.

예를 들면 계좌 잔고를 JSON으로 저장하는 작업은 이런 흐름이다.

CLI가 계좌 정보를 읽는다.

로컬 파일에 스냅샷을 쓴다.

대시보드가 그 파일을 읽는다.

사람이 숫자를 확인한다.

잘못되면 대시보드가 틀린다.

물론 이것도 문제다.

하지만 잘못된 주문이 시장에 들어가는 것과는 등급이 다르다.

조회 자동화의 사고는 대체로 정보 품질 사고다.

주문 자동화의 사고는 바로 계좌 상태 변경 사고다.

이 둘을 같은 자동화로 묶으면 운영 감각이 무뎌진다.

그래도 JSON 조회가 무조건 안전한 건 아니다

여기서 조심해야 한다.

JSON 조회도 계정 세션을 쓰면 보안 문제는 남는다.

로그인 토큰이 파일로 남을 수 있다.

계좌번호나 잔고가 로그에 찍힐 수 있다.

CI 서버나 개인 NAS에 평문 파일이 쌓일 수 있다.

백업 프로그램이 그 파일을 다른 클라우드로 밀어 넣을 수도 있다.

그러니까 이 글은 조회는 아무렇게나 해도 된다는 글이 아니다.

정확히는 이거다.

조회는 운영 기준을 붙이면 검토할 수 있고, 주문은 기본적으로 자동화 후보에서 빼야 한다.

표현이 조금 길지만 안전하다.

금융 자동화 문장은 짧게 멋있기보다 오해가 적어야 한다.

주문 자동화를 멈춰야 하는 첫 번째 이유: 거래지시

전자금융거래법은 전자금융거래를 전자적 장치를 통해 자동화된 방식으로 이용하는 거래로 정의한다.

증권 앱에서 주문을 넣는 행위도 결국 전자적 방식의 거래 흐름 안에 있다.

비공식 CLI가 이 흐름을 흉내 내거나 세션을 재사용해 주문을 넣는다면 문제의 층이 달라진다.

이제 단순 데이터 수집이 아니다.

거래지시의 생성과 전달에 가까워진다.

거래지시는 결과가 파일로 끝나지 않는다.

시장에 호가가 들어간다.

계좌의 현금과 보유 종목이 바뀐다.

체결되면 취소도 불가능한 구간이 생긴다.

잘못 눌렀어요가 통하지 않는 순간이 온다.

CLI는 무심하게 엔터 하나를 받지만, 시장은 꽤 차갑다.

주문 자동화를 멈춰야 하는 두 번째 이유: 접근매체와 세션

전자금융거래에서 접근매체는 거래지시나 이용자 확인에 쓰이는 수단과 정보를 포함한다.

비밀번호, 인증서, OTP, 앱 인증, 세션 토큰은 구현마다 다르지만 모두 민감한 권한 표면이다.

비공식 CLI는 보통 이 권한 표면을 공식 OAuth 앱처럼 잘게 나누지 못한다.

읽기 권한만 줄 수 있는지 불분명하다.

주문 권한만 별도로 차단할 수 있는지 불분명하다.

토큰 만료 시간을 사용자가 통제할 수 있는지 불분명하다.

로그아웃이 실제로 서버 세션까지 끊는지도 불분명할 수 있다.

이런 상태에서 주문 자동화를 붙이면 권한 경계가 흐려진다.

권한 경계가 흐려지면 사고가 났을 때 설명도 흐려진다.

운영 문서에서 가장 피해야 할 문장이 이거다.

아마 읽기만 할 거예요.

금융 계정 앞에서 아마는 너무 약하다.

주문 자동화를 멈춰야 하는 세 번째 이유: 공식 API와 비공식 세션의 차이

공식 API는 보통 명세가 있다.

권한 범위가 있다.

변경 공지가 있다.

장애 안내가 있다.

rate limit이 있다.

감사 로그를 설계할 수 있다.

반면 비공식 CLI는 내부 엔드포인트나 웹 세션 동작에 기대는 경우가 많다.

오늘 되던 필드가 내일 바뀔 수 있다.

응답 포맷이 조용히 달라질 수 있다.

보안 정책 변경으로 갑자기 막힐 수 있다.

그 정도는 조회 대시보드에서는 귀찮은 장애다.

하지만 주문 자동화에서는 금전 사고 후보가 된다.

그래서 공식 API가 아닌 이상 주문 lane은 더 보수적으로 봐야 한다.

돌아간다와 운영해도 된다는 다른 말이다.

이 문장 하나만 기억해도 사고 확률이 꽤 줄어든다.

주문 자동화를 멈춰야 하는 네 번째 이유: 거래소도 알고리즘 거래를 그냥 두지 않는다

한국거래소 규정에는 고속 알고리즘거래와 관련해 회원의 관리 의무, 위험관리, 일괄호가취소 같은 장치가 등장한다.

이건 개인이 비공식 CLI로 자동주문을 하라는 뜻이 아니다.

오히려 반대로 읽어야 한다.

자동으로 주문이 나가는 시스템은 거래소와 회원사 차원에서도 별도 위험관리 대상으로 본다는 신호다.

주문 시스템에는 오류 주문, 과다 호가, 접속 해제, 중복 주문, 자전거래 방지 같은 문제가 따라온다.

개인 CLI가 이 모든 장치를 갖추기는 어렵다.

갖췄다고 주장해도 검증은 또 다른 문제다.

내 계좌 하나라서 작아 보일 수 있다.

하지만 손실은 내 계좌 안에서 100% 현실이다.

작은 시스템도 실계좌 앞에서는 진짜 시스템이다.

운영 기준표: 기능별 허용선

기능	기본 상태	자동화 가능 조건	중단 신호
버전 확인	허용	네트워크 없이 가능하면 더 좋음	없음
health check	허용	계정 정보 미노출	계좌번호 출력
로그인 상태 확인	제한	민감정보 마스킹	토큰 값 출력
잔고 조회	제한	read-only 문서화	세션 파일 평문 저장
보유 종목 조회	제한	로컬 암호화 또는 최소 로그	종목별 계좌 식별자 과다 노출
체결 내역 조회	제한	기간 제한	전체 거래내역 무제한 export
JSON snapshot	제한	저장 위치 고정	공유 폴더 자동 업로드
CSV export	제한	파일명에 계좌번호 금지	외부 공유 링크 생성
주문 preview	경계	사람 승인 화면에서만	preview 결과 자동 실행 연결
주문 실행	제외	공식 API와 별도 승인 체계 없으면 제외	비공식 세션 사용
주문 취소	제외	실계좌 자동화 후보 아님	스케줄러 연결
주문 정정	제외	실계좌 자동화 후보 아님	가격 자동 수정
토큰 refresh	제외 후보	짧은 TTL과 수동 승인 필요	무기한 세션 유지
cron 실행	조회만 제한	read-only 명령만 allowlist	주문 명령 포함
에이전트 연결	조회만 제한	tool permission 분리	LLM이 주문 명령 생성 가능

이 표를 저장소에 붙여두면 좋다.

특히 기본 상태 열이 중요하다.

기본값이 허용이면 사람은 계속 넓힌다.

기본값이 제한이면 사람은 근거를 묻는다.

금융 자동화에서는 근거를 묻는 쪽이 낫다.

귀찮지만 계좌는 귀찮음을 좋아한다.

계좌가 말은 못 하지만, 아마 속으로 박수칠 거다.

조회 lane의 운영 조건

조회 lane은 다음 조건을 만족할 때만 검토한다.

명령이 계좌 상태를 바꾸지 않는다.
결과가 JSON, CSV, 로컬 로그 같은 데이터 산출물로 끝난다.
주문, 취소, 정정 명령과 같은 바이너리나 alias를 공유하지 않는다.
저장 파일에 계좌번호, 주민번호, 전화번호, 원문 토큰이 들어가지 않는다.
파일 권한은 기본적으로 본인 계정만 읽을 수 있게 둔다.
로그 보존 기간을 정한다.
외부 클라우드 동기화 폴더에 자동 저장하지 않는다.
대시보드는 참고용으로 표시한다.
대시보드 숫자를 근거로 자동 주문하지 않는다.
실패 시 재시도 횟수를 제한한다.
API 응답 포맷이 바뀌면 조용히 통과시키지 않는다.
스키마 검증 실패는 알림으로 보낸다.
조회 빈도는 사람이 앱을 보는 수준보다 과하지 않게 둔다.
야간 반복 실행은 필요성을 따로 적는다.
계정 잠금이나 이상 로그인 알림이 오면 즉시 중단한다.

이 조건을 다 지켜도 약관 리스크가 사라지는 건 아니다.

다만 최소한 운영자가 무엇을 하고 있는지 설명할 수 있다.

설명 가능한 자동화가 첫 번째 방어선이다.

주문 lane의 중단 조건

주문 lane은 기본적으로 자동화하지 않는다.

특히 아래 조건 중 하나라도 보이면 바로 멈춘다.

비공식 CLI가 웹 로그인 세션을 재사용한다.
주문 권한과 조회 권한을 분리할 수 없다.
주문 명령을 allowlist에서 제외할 방법이 없다.
LLM 에이전트가 명령 문자열을 직접 만들 수 있다.
dry-run과 실제 실행 플래그가 같은 명령에 있다.
preview 결과가 자동으로 place로 이어진다.
수량, 가격, 종목 코드 검증이 별도 모듈이 아니다.
주문 전 사람 승인 기록이 남지 않는다.
주문 후 알림이 실패해도 실행은 계속된다.
취소 실패 시 대응 절차가 없다.
장 마감, 휴장, 시간외 거래 구분이 약하다.
환율, 예수금, 미수, 증거금 체크가 없다.
동일 주문 중복 방지 키가 없다.
네트워크 timeout 후 체결 상태를 재확인하지 않는다.
예외가 나면 다시 주문하는 구조다.

마지막 줄이 특히 위험하다.

예외 처리에서 주문을 재시도하는 순간, 버그가 돈을 두 번 누를 수 있다.

개발자는 retry를 좋아하지만 계좌는 별로 안 좋아한다.

로그 기준표: 무엇을 남기고 무엇을 버릴까

로그 항목	남길지	이유	주의점
실행 시각	남김	감사 추적	타임존 명시
명령 이름	남김	어떤 기능인지 확인	인자 전체 저장 금지
명령 lane	남김	조회/경계/실행 구분	enum으로 고정
성공/실패	남김	장애 분석	에러 원문 마스킹
응답 스키마 버전	남김	포맷 변경 추적	원문 응답 저장 최소화
파일 경로	제한	산출물 추적	사용자 홈 경로 노출 주의
계좌번호	버림	민감정보	끝 2자리도 가급적 불필요
세션 토큰	버림	접근권한	절대 저장 금지
주문 가격	주문 자동화 제외	실행 lane 정보	글 기준에서는 저장 대상 아님
주문 수량	주문 자동화 제외	실행 lane 정보	글 기준에서는 저장 대상 아님
잔고 원문	제한	디버깅 유혹 큼	필요 시 요약값만
stack trace	제한	장애 분석	토큰 포함 여부 확인

로그는 많이 남길수록 좋은 게 아니다.

금융 계정에서는 로그가 두 번째 데이터베이스가 된다.

두 번째 데이터베이스는 대체로 관리가 덜 된다.

그래서 로그 정책은 나중에 보면 좋겠다가 아니라 나중에 유출돼도 버틸 수 있나로 봐야 한다.

특히 토큰과 원문 응답은 아예 저장하지 않는 쪽이 낫다.

디버깅이 조금 불편해지는 건 감수할 만하다.

실계좌 토큰이 로그에 누워 있는 것보다는 훨씬 낫다.

권한 기준표: read, review, execute를 나눠라

권한 단계	허용 기능	금지 기능	운영 문장
read	잔고, 보유, 체결 조회	주문 관련 명령	읽기 전용 산출물만 생성
export	JSON, CSV 저장	외부 공유 자동 생성	로컬 저장과 마스킹만 허용
review	주문 preview 화면 확인	place 자동 연결	사람이 앱에서 따로 판단
execute	실주문	비공식 CLI에서는 제외	공식 채널과 사람 승인만 사용
admin	세션 삭제, 설정 변경	토큰 장기 보존	짧은 작업 후 닫기

이 표에서 execute를 비워두는 게 포인트다.

많은 자동화 문서는 execute를 어떻게 안전하게 할지부터 고민한다.

하지만 비공식 증권 CLI에서는 먼저 execute를 없애는 게 낫다.

없애고도 글이 되고, 시스템이 되고, 대시보드가 된다.

투자 판단을 자동화하지 않아도 운영 자동화는 충분히 많다.

잔고 백업만 제대로 해도 할 일이 산더미다.

산더미는 싫지만, 주문 사고 산더미보다는 낫다.

승인 기준표: 사람 승인은 어디에 들어가야 하나

단계	사람 승인 필요 여부	이유
설정 파일 생성	필요	저장 위치와 권한 확인
계정 로그인	필요	본인 인증과 세션 생성
read-only 조회 실행	선택	민감도에 따라 결정
export 파일 생성	선택	저장 위치가 민감
외부 전송	필요	데이터 이동 발생
주문 preview	필요	주문 lane 진입
주문 실행	비공식 CLI 자동화 제외	실계좌 변경
주문 취소	비공식 CLI 자동화 제외	실계좌 변경
주문 정정	비공식 CLI 자동화 제외	실계좌 변경
세션 refresh	필요	권한 수명 연장
cron 등록	필요	반복 실행 시작
에이전트 tool 등록	필요	LLM 호출 가능성

사람 승인은 버튼 하나를 누르는 행위가 아니다.

운영에서는 기록이 남는 의사결정이어야 한다.

누가 승인했는지.

언제 승인했는지.

무엇을 승인했는지.

승인 범위가 어디까지인지.

언제 만료되는지.

이 다섯 가지가 없으면 승인은 그냥 기분이다.

기분으로 실계좌를 움직이면 나중에 회고가 매워진다.

매운맛은 떡볶이에서만 충분하다.

에이전트에 붙일 때의 최소 tool contract

AI 에이전트에 비공식 증권 CLI를 붙인다면 tool contract를 먼저 써야 한다.

예시는 이렇게 잡는다.

tool: unofficial_broker_cli
mode: read_only
allowed_commands:
  - account_summary_json
  - positions_json
  - fills_export_json
blocked_commands:
  - order_place
  - order_cancel
  - order_amend
  - token_refresh_unattended
  - browser_session_reuse_for_order
requires_human_approval:
  - login
  - export_to_external_service
  - cron_registration
log_policy:
  redact:
    - account_number
    - access_token
    - refresh_token
    - session_cookie

이 정도라도 있으면 에이전트가 할 수 있는 일과 못 하는 일이 갈린다.

중요한 건 blocked_commands를 문서에만 쓰지 않는 것이다.

실제 wrapper에서 막아야 한다.

문서에 금지라고 써놓고 shell tool이 모든 명령을 받을 수 있으면 금지가 아니다.

그건 소원에 가깝다.

소원은 별똥별한테 빌고, 계좌는 wrapper로 막자.

wrapper 설계 기준

비공식 CLI를 직접 호출하지 말고 얇은 wrapper를 둔다.

wrapper는 명령을 enum으로만 받는다.

사용자가 자유 문자열을 넣지 못하게 한다.

account summary --output json처럼 보이는 명령도 내부 mapping으로만 실행한다.

shell interpolation을 금지한다.

환경변수에 토큰을 넣는다면 실행 후 즉시 지운다.

출력은 schema validator를 통과해야 저장한다.

schema가 다르면 실패로 본다.

실패를 성공처럼 빈 JSON으로 바꾸지 않는다.

빈 JSON은 은근히 위험하다.

대시보드에서는 0원처럼 보일 수 있고, 에이전트는 그것을 사실로 믿을 수 있다.

금융 데이터에서 조용한 실패는 시끄러운 실패보다 나쁘다.

시끄럽게 깨지는 시스템이 차라리 착하다.

저장 파일 기준

저장 파일은 다음 규칙을 둔다.

파일명에 계좌번호를 넣지 않는다.

파일명에 실명을 넣지 않는다.

파일명에 전화번호를 넣지 않는다.

파일명은 날짜와 용도만 쓴다.

예시는 broker-summary-2026-04-28.json 정도면 충분하다.

권한은 600에 가깝게 둔다.

공유 폴더에는 저장하지 않는다.

Git 저장소에는 절대 넣지 않는다.

Obsidian vault에 원문 JSON을 넣는 것도 피한다.

노트에는 요약과 운영 판단만 남긴다.

원문 데이터는 별도 보관하거나 아예 저장하지 않는다.

백업이 필요하면 암호화된 위치를 쓴다.

삭제 주기를 정한다.

삭제 주기가 없는 파일은 언젠가 유물이 된다.

금융 유물은 박물관에 못 보낸다.

알림 기준

조회 자동화에도 알림 기준이 필요하다.

로그인 실패가 2회 이상이면 알림을 보낸다.

응답 스키마가 바뀌면 알림을 보낸다.

잔고 합계가 직전 대비 비정상적으로 바뀌면 알림을 보낸다.

단, 이 알림은 주문 신호가 아니다.

대시보드 갱신 실패도 주문 신호가 아니다.

체결 내역 export 실패도 주문 신호가 아니다.

모든 알림은 확인 요청으로 끝나야 한다.

자동 대응 주문으로 이어지면 안 된다.

자동 대응은 멋있어 보이지만 금융 계정에서는 과하다.

알림은 초인종이다.

초인종이 울렸다고 집이 알아서 이사 가면 곤란하다.

약관을 읽을 때 보는 포인트

약관 전체를 법률가처럼 해석하자는 얘기가 아니다.

운영자는 최소한 다음 문장들을 찾아봐야 한다.

전자금융거래 이용 범위.

온라인 서비스 이용 조건.

서비스 정지 사유.

토스증권 같은 모바일 중심 증권사에서 더 조심할 점

모바일 중심 서비스는 앱 내부의 인증, 알림, 세션, 화면 확인을 전제로 설계되는 경우가 많다.

비공식 CLI는 그 경험을 우회하거나 흉내 낼 수 있다.

조회만 해도 세션 보관 방식이 중요해진다.

주문까지 가면 더 어렵다.

앱에서 보여주는 경고 문구를 CLI가 충분히 전달하는지 확인하기 어렵다.

주문 전 확인 화면을 사람이 실제로 봤는지도 남기기 어렵다.

가격 제한, 시장가 위험, 시간외 거래 안내, 환전 관련 안내가 빠질 수 있다.

이런 경고들은 귀찮은 장식이 아니다.

금융 UI에서는 경고 문구도 안전장치다.

CLI가 예쁘게 한 줄로 줄여버리면 안전장치도 같이 줄어든다.

한 줄 출력은 개발자 마음을 편하게 하지만, 계좌 마음까지 편하게 하진 않는다.

마이데이터와 비공식 CLI를 헷갈리면 안 된다

마이데이터나 금융권 오픈 API는 제도화된 전송 요구, 인증, 중계, 사업자 관리 체계 위에서 움직인다.

금융결제원 마이데이터 중계서비스 설명에도 API 게이트웨이, 통합인증, 토큰 관리, 이상거래 탐지 같은 구성 요소가 나온다.

이런 구조는 개인이 만든 비공식 CLI와 다르다.

둘 다 데이터를 가져온다는 점에서는 비슷해 보일 수 있다.

하지만 운영 책임과 통제 장치는 다르다.

제도권 API가 있다는 사실이 비공식 세션 자동화를 정당화하지 않는다.

오히려 반대로 봐야 한다.

금융 데이터 이동에는 원래 인증, 권한, 기록, 이상거래 탐지가 붙어야 한다.

그 장치가 없는 비공식 조회는 더 좁게 써야 한다.

주문 자동화는 더더욱 멈춰야 한다.

개인용이라고 괜찮다는 착각

개인용 자동화는 작아서 안전해 보인다.

하지만 사고가 작아지는 건 아니다.

내 계좌에서 잘못 주문되면 손실은 내 계좌에 온다.

회사 시스템이 아니라고 로그가 없어도 되는 건 아니다.

팀 서비스가 아니라고 권한 분리가 필요 없는 것도 아니다.

개인용일수록 오히려 더 단순해야 한다.

조회만 한다.

로컬에만 저장한다.

토큰은 남기지 않는다.

주문은 앱에서 사람이 한다.

이 네 줄이면 개인 운영 기준으로 충분히 강하다.

화려하지 않아도 된다.

계좌 운영 문서는 힙합 가사가 아니라 체크리스트다.

비공식 CLI를 평가하는 20개 질문

공식 API 문서가 있는가.
없으면 어떤 엔드포인트나 세션에 기대는가.
조회 권한과 주문 권한을 분리할 수 있는가.
토큰 저장 위치를 사용자가 정할 수 있는가.
토큰 만료 시간을 확인할 수 있는가.
로그에 민감정보가 찍히는가.
JSON 스키마가 문서화되어 있는가.
응답 포맷 변경을 감지하는가.
주문 명령을 빌드에서 제거할 수 있는가.
주문 명령을 runtime allowlist에서 막을 수 있는가.
preview와 execute가 분리되어 있는가.
execute가 기본 off인가.
dry-run 결과와 실제 실행 결과가 명확히 구분되는가.
스케줄러 실행 예시가 주문을 포함하는가.
에러 발생 시 재시도 정책이 있는가.
재시도가 주문 중복을 만들 수 있는가.
계정 잠금이나 이상 로그인에 대응하는가.
유지보수자가 보안 이슈를 처리하는 절차가 있는가.
약관 변경이나 서비스 변경을 추적하는가.
이 도구 없이도 같은 목적을 더 안전하게 달성할 수 있는가.

20번 질문이 제일 얄밉다.

하지만 제일 중요하다.

자동화는 목적이 아니라 수단이다.

목적이 포트폴리오 기록이면 수동 export로 충분할 수 있다.

목적이 리밸런싱 검토면 스프레드시트로 충분할 수 있다.

목적이 실시간 매매라면 비공식 CLI가 아니라 공식 인프라부터 봐야 한다.

운영 문서에 넣을 수 있는 정책 문안

아래 문안은 그대로 가져다 써도 된다.

### 비공식 증권 CLI 운영 정책

- 본 도구는 공식 증권사 API가 아닌 보조 도구로 분류한다.
- 허용 범위는 read-only 조회, JSON/CSV export, health check로 제한한다.
- 주문 실행, 주문 취소, 주문 정정, 무인 스케줄 주문은 자동화 대상에서 제외한다.
- 로그인 세션, access token, refresh token, session cookie는 로그와 산출물에 저장하지 않는다.
- 조회 결과는 투자 판단 참고 자료가 아니며, 자동 주문 조건으로 사용할 수 없다.
- CLI 출력 오류, 스키마 변경, 인증 실패가 발생하면 자동 복구보다 중단과 알림을 우선한다.
- 권한 변경, cron 등록, 외부 전송은 사람 승인과 기록을 요구한다.
- 약관 또는 서비스 정책 변경이 확인되면 사용 범위를 재검토한다.

이 문안의 장점은 execute를 열어두지 않는다는 점이다.

처음부터 닫아두면 나중에 누군가 열 때 이유를 적어야 한다.

운영 기준은 바로 그 순간을 만들려고 쓰는 것이다.

왜 열었지?를 묻게 만드는 문서.

그게 좋은 문서다.

대시보드에 붙일 때의 안전 구조

비공식 CLI를 대시보드에 붙인다면 구조는 이렇게 둔다.

CLI는 조회만 한다.

조회 결과는 임시 JSON으로 저장한다.

validator가 스키마를 확인한다.

마스킹 모듈이 민감정보를 제거한다.

대시보드는 마스킹된 요약만 읽는다.

대시보드에는 주문 버튼을 넣지 않는다.

대시보드에서 증권사 앱 딥링크를 자동 호출하지 않는다.

대시보드 알림은 확인 필요까지만 한다.

리밸런싱 제안이 필요하면 별도 메모로 만든다.

그 메모에도 투자 조언 아님을 명시한다.

마지막 주문은 사람이 공식 앱이나 공식 채널에서 한다.

이 구조가 답답해 보일 수 있다.

하지만 답답함이 안전장치일 때가 있다.

금융 자동화에서 마찰은 버그가 아니라 기능일 수 있다.

LLM이 붙으면 위험이 커지는 이유

LLM은 자연어를 명령으로 바꾸는 데 능하다.

그래서 더 조심해야 한다.

사람이 AAPL 조금 줄여도 될까?라고 물었을 때, 에이전트가 주문 명령을 만들 수 있으면 위험하다.

의도 해석이 틀릴 수 있다.

종목 코드가 헷갈릴 수 있다.

수량 계산이 틀릴 수 있다.

환율과 예수금 조건을 빠뜨릴 수 있다.

프롬프트 인젝션으로 명령이 오염될 수 있다.

대화 맥락에 있던 예시 주문을 실제 주문으로 착각할 수도 있다.

그래서 LLM tool에는 읽기 권한만 줘야 한다.

주문은 tool 목록에 없어야 한다.

없으면 호출할 수 없다.

이 단순함이 꽤 강하다.

보안에서 가장 좋은 권한은 주지 않은 권한이다.

주문 자동화가 꼭 필요하다면

이 글의 기준에서는 비공식 CLI 주문 자동화를 멈추라고 본다.

그래도 어떤 사람은 자동 주문이 꼭 필요하다고 말할 수 있다.

그 경우에도 답은 비공식 CLI가 아니다.

공식 API 제공 여부를 확인한다.

증권사의 약관과 API 이용 조건을 확인한다.

모의투자 환경을 먼저 쓴다.

주문 한도와 종목 제한을 둔다.

kill switch를 둔다.

중복 주문 방지 키를 둔다.

감사 로그를 둔다.

사람 승인 단계를 둔다.

법률/준법 검토가 필요한 규모라면 전문가에게 묻는다.

여기까지 읽고 피곤하다면 정상이다.

주문 자동화는 원래 피곤해야 한다.

안 피곤하면 어딘가 안전장치를 빼먹었을 가능성이 크다.

작은 팀에서 정할 수 있는 RACI

작은 팀이나 개인 프로젝트라도 역할을 나눠 적으면 좋다.

항목	Responsible	Accountable	Consulted	Informed
CLI 설치	운영자	계정 소유자	보안 검토자	팀원
조회 명령 allowlist	운영자	계정 소유자	개발자	팀원
로그 마스킹	개발자	운영자	보안 검토자	계정 소유자
cron 등록	운영자	계정 소유자	개발자	팀원
외부 전송	계정 소유자	계정 소유자	보안 검토자	팀원
주문 자동화 요청	요청자	계정 소유자	준법/법률	팀원
주문 자동화 승인	비공식 CLI에서는 승인하지 않음	계정 소유자	준법/법률	팀원

이 표의 마지막 줄이 핵심이다.

승인 절차가 있다고 다 승인해야 하는 건 아니다.

절차는 거절을 정당하게 만들기 위해서도 필요하다.

좋은 운영 문서는 안 돼를 덜 어색하게 해준다.

장애 시나리오별 대응표

시나리오	자동 대응	사람 대응
로그인 실패	중단	계정 알림 확인
스키마 변경	중단	CLI 업데이트 여부 확인
잔고 급변	알림	공식 앱에서 직접 확인
파일 저장 실패	중단	디스크 권한 확인
토큰 파일 발견	중단	세션 폐기와 비밀번호 점검
계정 잠금	중단	증권사 고객센터/앱 확인
주문 명령 호출 시도	차단	wrapper 로그 검토
cron에서 주문 명령 발견	차단	cron 제거
외부 전송 감지	중단	공유 범위 확인
대시보드 0원 표시	중단	원문 재조회 전 표시 차단

여기서 자동 대응은 거의 다 중단이다.

멋진 복구 루프를 만들고 싶겠지만, 금융 계정에서는 중단이 훨씬 낫다.

자동 복구는 상태를 더 복잡하게 만든다.

복잡한 상태는 회고를 어렵게 만든다.

회고가 어려우면 같은 사고가 반복된다.

그러니 조회 자동화도 실패하면 일단 멈추자.

멈추는 시스템은 생각보다 품격 있다.

투자 조언과 운영 자동화를 분리하기

이 글은 투자 조언이 아니다.

어떤 종목을 사거나 팔라는 글도 아니다.

자동매매 전략 추천도 아니다.

오히려 반대다.

투자 판단과 운영 자동화를 분리하자는 글이다.

대시보드는 현재 상태를 보여줄 수 있다.

리포트는 지난 거래를 정리할 수 있다.

로그는 장애를 설명할 수 있다.

하지만 이 셋이 자동으로 매수 버튼을 누르면 안 된다.

운영 자동화는 기록과 확인을 돕는 쪽에 머물러야 한다.

투자 판단은 사람의 책임으로 남겨야 한다.

이 경계가 흐려지는 순간, 글의 주제도 흐려지고 계좌도 흐려진다.

흐린 계좌는 날씨 앱에도 안 나온다.

실무 체크리스트

[ ] 이 CLI가 공식 API인지 확인했다.
[ ] 공식 API가 아니라면 운영 문서에 비공식 도구로 표시했다.
[ ] 조회 명령과 주문 명령을 분리했다.
[ ] 주문 명령은 wrapper에서 차단했다.
[ ] LLM tool 목록에 주문 명령이 없다.
[ ] cron에는 조회 명령만 있다.
[ ] JSON 파일 저장 위치를 정했다.
[ ] JSON 파일에 민감정보가 남지 않게 했다.
[ ] 로그에 토큰이 남지 않게 했다.
[ ] 로그 보존 기간을 정했다.
[ ] 스키마 검증 실패 시 중단한다.
[ ] 로그인 실패 시 중단한다.
[ ] 계정 잠금 알림이 오면 중단한다.
[ ] 외부 전송은 사람 승인을 받는다.
[ ] 주문 preview도 주문 lane 입구로 분류한다.
[ ] 주문 실행은 공식 앱이나 공식 채널에서 사람이 한다.
[ ] 약관 변경 시 재검토한다.
[ ] 출처 링크를 운영 문서에 남긴다.
[ ] 이 글을 투자 조언으로 쓰지 않는다.
[ ] 자동화의 목적이 기록인지 실행인지 다시 확인한다.

체크리스트는 길어 보인다.

하지만 대부분 한 번 정하면 반복해서 쓸 수 있다.

처음에 귀찮고 나중에 편한 게 좋은 운영이다.

처음에 편하고 나중에 무서운 건 그냥 빚이다.

기술 부채도 싫은데 계좌 부채까지 만들 필요는 없다.

FAQ

JSON 조회만 하면 약관 문제는 전혀 없나

아니다.

조회만 해도 서비스 이용 방식, 세션 보관, 개인정보 처리, 접근매체 관리 이슈는 남을 수 있다.

그래서 이 글은 조회를 무조건 허용한다고 말하지 않는다.

주문 자동화보다 낮은 위험의 검토 후보라고 보는 게 정확하다.

주문 preview는 조회인가 주문인가

운영 기준에서는 주문 lane의 입구로 둔다.

실제 체결은 아니어도 주문 의사결정 구조에 들어가기 때문이다.

preview 결과가 자동으로 execute에 연결될 수 있다면 더더욱 주문 lane이다.

공식 API가 있으면 주문 자동화가 괜찮아지나

공식 API가 있으면 검토 출발점은 달라진다.

하지만 승인, 로그, 한도, 중복 방지, 장애 대응, 약관 확인은 여전히 필요하다.

공식 API는 만능 면허가 아니다.

운전면허가 있어도 안전거리 안 지키면 사고 나는 것과 비슷하다.

개인 계좌 하나만 쓰는데 이렇게까지 해야 하나

계좌가 하나면 더 단순하게 하면 된다.

조회만 자동화하고 주문은 하지 않는 방식이 제일 단순하다.

규모가 작다고 주문 사고가 장난감이 되지는 않는다.

작은 사고도 내 돈이면 크게 느껴진다.

LLM에게 매수 후보만 고르게 하는 건 괜찮나

이 글의 범위에서는 매수 후보 추천도 투자 조언 영역에 가까우므로 조심해야 한다.

LLM은 데이터 정리, 로그 요약, 누락 확인 정도에 머무르는 게 낫다.

종목 판단과 주문 실행은 분리한다.

특히 자동 주문과 연결하지 않는다.

참고 자료/공식 출처

마지막 기준

비공식 증권 CLI를 쓰는 목적이 기록과 확인이라면 JSON 조회는 제한적으로 검토할 수 있다.

하지만 목적이 주문 실행이라면 멈추는 쪽이 맞다.

특히 공식 API가 아니고, 권한 분리가 약하고, 세션 저장 방식이 불분명하고, 사람이 마지막 승인하지 않는 구조라면 더 그렇다.

운영 기준은 기술을 금지하려고 쓰는 게 아니다.

기술이 계좌를 너무 쉽게 움직이지 못하게 하려고 쓰는 것이다.

그래서 2026년 기준 내 답은 이렇다.

비공식 증권 CLI는 조회, export, JSON snapshot, 로그 점검까지.

주문, 취소, 정정, 무인 스케줄 실행은 멈춤.

이 선이 조금 답답해 보여도 괜찮다.

금융 자동화에서 답답함은 종종 최고의 보안 기능이다.