비공식 증권 CLI 운영 기준 2026 — JSON 출력은 써도 주문 자동화는 멈춰야 하는 이유

Posted on by

비공식 증권 CLI를 처음 보면 보통 두 갈래로 반응한다.

  • 와, JSON으로 뽑히네. 대시보드 붙이기 좋겠다.
  • 오, 주문도 되네. 그럼 자동매매까지?

문제는 두 번째에서 사고가 나기 쉽다는 거다.

조회와 export는 데이터 파이프라인에 가깝다. 주문은 실계좌 제어에 가깝다.

둘은 같은 “CLI 기능”처럼 보여도 운영 기준은 완전히 달라져야 한다.

Quick Answer

  • 비공식 증권 CLI에서 내가 상대적으로 허용 가능한 범위로 보는 건 JSON 출력, 조회, export, doctor 같은 읽기 전용 표면이다.
  • 반대로 place, cancel, amend, 권한 부여, 위험 플래그가 붙는 경로는 운영상 멈추는 쪽이 맞다.
  • 핵심 기준은 간단하다.
  • 결과가 파일/로그로 끝나면 검토 가능
  • 결과가 시장/계좌를 건드리면 중단

JSON은 데이터고, 주문은 행동이다. 비공식 툴에서 이 둘을 같은 기준으로 보면 안 된다.

이 글이 필요한 사람

  • 비공식 CLI의 유용함은 인정하지만 실계좌 자동화는 찜찜한 사람
  • 에이전트나 대시보드에 붙일 수 있는 안전한 경계선을 찾는 사람
  • 조회용으로만 쓰자를 실제 운영 기준으로 어떻게 적어야 할지 고민하는 사람

지금 결론

기능 운영 판단
doctor, version, auth status 상대적으로 안전
account summary --output json 상대적으로 안전
portfolio, orders list, export csv/json 제한적 사용 가능
order preview 경계 구간
order place/cancel/amend 운영상 중단 권장
스케줄러 + 실거래 결합 멈추는 쪽 권장

이 표 하나면 거의 다 설명된다.

왜 JSON 출력은 써도 된다고 보나

정확히 말하면 “무조건 써도 된다”가 아니라 검토 가능한 범위가 여기까지라는 뜻이다.

JSON 출력이 상대적으로 괜찮은 이유는 세 가지다.

1. 결과가 파일/메모리로 끝난다

시장에 직접 주문을 넣지 않는다.

2. 사람이 다시 볼 수 있다

대시보드에 붙이든 로그로 남기든, 재검토 지점이 있다.

3. 사고가 나도 주로 데이터 품질 문제다

불편하고 귀찮을 수는 있어도 실손실로 직결될 가능성은 주문보다 훨씬 낮다.

그래서 비공식 증권 CLI를 본다면 대부분의 사람은 여기까지만 해도 충분하다.

왜 주문 자동화는 멈춰야 하나

여기선 얘기가 달라진다.

주문 자동화가 붙는 순간 같이 딸려오는 게 있다.

  • 주문 권한
  • 확인 토큰
  • TTL
  • 미리보기
  • 취소/정정 책임
  • 세션 보존

즉 명령 하나가 아니라 권한이 붙은 외부 부작용이 된다.

이 지점부터는 CLI 편의성보다 운영 책임이 먼저다.

내가 쓰는 운영 기준 문장

이런 도구를 시스템 문서에 적는다면 나는 대충 이렇게 쓴다.

비공식 증권 CLI는 조회, export, JSON snapshot까지를 실험 범위로 본다.
주문, 취소, 정정, 권한 grant, 위험 플래그를 요구하는 경로는 자동화 범위에서 제외한다.

이 문장이 좋은 이유는 짧기 때문이다. 운영 기준은 멋있기보다 기억나야 한다.

체크리스트: 계속 써도 되는 경로 vs 멈춰야 하는 경로

신호 계속 검토 가능 멈춰야 함
출력 JSON, CSV, 요약 로그 주문 실행 결과
부작용 로컬 저장 시장/계좌 상태 변경
확인 단계 사람이 후속 검토 가능 실시간 실행 압박 큼
권한 read 중심 grant/execute 필요
실패 결과 데이터 누락 금전 손실 가능

이 표가 사실상 운영 기준의 핵심이다.

실전에서 제일 위험한 착각

많은 사람이 이렇게 생각한다.

place만 안 쓰면 preview 정도는 괜찮지 않나?

그럴 수도 있다. 근데 preview는 이미 주문 lane 안에 발을 들인 상태다.

그래서 내가 보기엔 preview는 조회 자동화의 연장이 아니라 주문 자동화 직전 단계로 봐야 한다.

즉 분류를 이렇게 해야 덜 헷갈린다.

  • 조회 lane: list, summary, export, json
  • 경계 lane: preview, auth-related status
  • 실행 lane: place, cancel, amend, dangerous flags

운영 문서에 꼭 넣어야 하는 5줄

  1. 비공식 증권 CLI는 공식 API로 취급하지 않는다.
  2. 조회용 명령과 실행용 명령을 capability로 분리한다.
  3. JSON 출력은 허용 후보, 주문 실행은 제외 후보로 본다.
  4. 사람 승인 없는 실거래 스케줄링은 막는다.
  5. 세션/로그 저장 위치와 만료 정책을 별도 문서화한다.

이 정도만 있어도 팀이나 개인 시스템에서 선이 훨씬 선명해진다.

실수 TOP 4

1. JSON 출력이 잘 되니까 주문도 비슷하게 보면 된다고 생각하는 실수

이 둘은 등급이 다르다.

2. 비공식 툴인데도 운영 기준 없이 그냥 “개인용”으로 시작하는 실수

그게 제일 흔한 사고 루트다.

3. preview를 읽기 전용처럼 오해하는 실수

preview는 주문 lane 경계선이다.

4. 한 번 잘 됐다고 스케줄러에 바로 얹는 실수

자동화는 성공보다 반복 실패 비용을 먼저 봐야 한다.

FAQ

Q. JSON 출력도 TOS 문제는 남지 않나

남는다. 그래서 “허용”이 아니라 “상대적으로 덜 위험한 검토 범위”라고 보는 게 맞다.

Q. 주문 자동화를 무조건 금지해야 하나

적어도 비공식 CLI와 실계좌 조합이라면 보수적으로 멈추는 쪽이 낫다.

Q. 이 기준은 다른 금융 CLI에도 적용되나

거의 그대로 적용된다. read lane과 action lane 분리가 핵심이다.

다음에 읽을 글

출처와 전제

  • 이 글은 비공식 증권 CLI 원글의 게이트 설계를 운영 기준 문장으로 다시 풀어쓴 후속이다.
  • 특정 서비스 약관 해석의 법적 결론이 아니라, 실계좌 자동화에 대한 보수적 운영 기준 정리다.