거래소 API 보안 & 리스크 완화: 트레이딩 봇 인프라 보호
트레이딩 봇은 단일 인터페이스를 통해 운영됩니다: 거래소 API. 모든 주문, 모든 잔액 확인, 모든 포지션 쿼리는 생성한 API 자격 증명을 통해 흐릅니다. 그 자격 증명이 잘못 설정되거나, 손상되거나, 오해되면, 결과는 무단 거래에서 완전한 계정 고갈까지 다양합니다.
이 가이드는 기본 보안 위생을 넘어(기초 보안 가이드 참조), 전문 봇 운영자를 아마추어와 구분하는 운영 보안 프레임워크를 다룹니다. 권한 아키텍처, 네트워크 수준 액세스 제어, 자격 증명 수명 관리, 거래소 실패 처리 및 완전한 사고 대응 플레이북을 다룹니다.
Key Takeaways
- API 키에는 4가지 권한 수준이 있습니다 — 읽기, 현물 거래, 선물 거래, 출금. 봇 연결에 출금은 절대 활성화되어서는 안 됩니다.
- IP 화이트리스트는 도난당한 API 키를 쓸모없게 만듭니다. 모든 거래소에서 구성하세요 — Binance, Bybit, OKX 모두 지원합니다.
- 다운타임 없는 절차를 사용하여 90일마다 API 키를 순환하세요: 새 키 생성 → 봇 업데이트 → 검증 → 이전 키 삭제.
- 서브계정 격리는 폭발 반경을 제한합니다: 손상된 봇은 전체 포트폴리오가 아닌 서브계정의 자본에만 영향을 미칠 수 있습니다.
- 거래소가 거래 중 다운되면, 미체결 주문은 주문장에 지속되며, 봇은 재연결 후 상태를 조정해야 합니다.
- 속도 제한 위반(Binance: 1,200/분, Bybit: 120/5초)은 일시적 IP 차단을 초래합니다 — 봇은 요청을 사전 조절해야 합니다.
API 키 권한 수준: 최소 권한의 원칙
모든 주요 거래소는 API 키에 대한 세분화된 권한 시스템을 구현합니다. 원칙은 간단합니다: 봇이 필요한 권한만 정확히 부여하고 더 이상은 부여하지 마세요. 각 수준이 제어하는 것은 다음과 같습니다:
권한 아키텍처
| 권한 수준 | 허용하는 것 | 봇이 필요한가? | 손상 시 리스크 |
|---|---|---|---|
| 읽기 전용 | 잔액, 주문 내역, 시장 데이터 보기 | ✅ 항상 | 낮음 — 공격자가 계정 데이터 확인 |
| 현물 거래 | 현물 시장가/지정가 주문 발주 및 취소 | ✅ 현물 봇용 | 중간 — 공격자가 거래 실행 가능 |
| 선물 거래 | 레버리지 포지션 열기/닫기, 증거금 설정 | ✅ 선물 봇용 | 높음 — 레버리지 손실 가능 |
| 출금 | 외부 지갑으로 자금 이체 | ❌ 절대 안 됨 | 치명적 — 총 자금 손실 |
| 내부 이체 | 서브계정 간 자금 이동 | ⚠️ 드물게 | 중간 — 자금 재할당 |
출금 권한이 킬 스위치인 이유
출금이 비활성화되어 있으면, 손상된 API 키의 최악 시나리오는 다음과 같습니다: 공격자가 나쁜 거래를 발주합니다. 자본이 타격을 받지만 거래소에 머무릅니다. 회복할 수 있습니다.
출금이 활성화되어 있으면, 최악의 경우는 총 손실입니다. 공격자가 몇 초 안에 계정을 자신의 지갑으로 고갈시킵니다. 암호화폐 거래는 되돌릴 수 없습니다. 충전금 환불 없음, 회복 없음.
수학은 엄격합니다. Binance에 $50,000이 있다고 가정합니다:
- 출금 비활성화, 키 손상: 공격자가 불규칙한 거래를 발주합니다. 현실적 손실: 키를 알아채고 취소하기 전 슬리피지와 나쁜 체결로 $2,000-$10,000. 남은 자본: $40,000-$48,000.
- 출금 활성화, 키 손상: 공격자가 $50,000을 자신의 지갑으로 보냅니다. 남은 자본: $0.
어떤 합법적인 봇 플랫폼도 — Freya Finance를 포함하여 — 출금 권한을 요구하지 않습니다. 플랫폼이 그것을 요청한다면, 그 플랫폼은 무능하거나 악의적입니다. 즉시 떠나세요.
거래소별 권한 설정
Binance: 계정 → API 관리 → API 생성으로 이동. "API 제한"에서 "Spot & Margin Trading 활성화"만 활성화하세요. "Withdrawals 활성화"와 "Internal Transfer 활성화"는 체크 해제로 두세요. 선물 봇의 경우 "Enable Futures"도 체크하세요.
Bybit: 프로필 → API 관리 → 새 키 생성으로 이동. 권한에서 현물 전용(또는 필요한 경우 파생상품)에 "Read-Write"를 활성화하세요. "Withdraw" 토글은 OFF로 유지되어야 합니다.
OKX: 프로필 → API 키 → API 키 생성으로 이동. "권한"에서 "Trade"만 선택하세요. OKX는 API 인증을 위해 추가 패스프레이즈가 필요합니다 — 이를 키와 시크릿과 함께 비밀번호 관리자에 저장하세요.
IP 화이트리스트: 네트워크 수준 액세스 제어
IP 화이트리스트는 도난당한 API 키에 대한 가장 효과적인 단일 방어입니다. 공격자가 API 키와 시크릿을 얻더라도, 사용할 수 없습니다 — 거래소는 화이트리스트된 IP 주소에서 비롯되지 않은 모든 요청을 거부합니다.
IP 화이트리스트 작동 방식
봇 서버 (IP: 34.85.123.45) → 거래소 API → ✅ 화이트리스트됨 → 주문 실행
공격자 서버 (IP: 192.168.0.99) → 거래소 API → ❌ 화이트리스트 없음 → 요청 거부
거래소는 각 API 키에 대한 IP 주소의 허용 목록을 유지합니다. 모든 들어오는 API 요청의 소스 IP는 처리하기 전에 이 목록과 대조됩니다. 화이트리스트되지 않은 IP의 요청은 API 키와 서명이 유효하더라도 인증 오류로 거부됩니다.
협상 불가능한 이유
IP 화이트리스트 없이, API 자격 증명을 얻은 사람은 누구든 세계 어디에서나 사용할 수 있습니다. IP 화이트리스트로, 공격자는 봇 플랫폼의 서버 인프라도 손상시켜야 합니다 — 극적으로 더 어려운 목표.
플랫폼별 설정
Binance:
- API 관리에서 키를 선택하고 "제한 편집"을 클릭하세요
- "IP 액세스 제한"에서 "신뢰할 수 있는 IP에만 액세스 제한"을 선택하세요
- 각 IP 주소를 별도 줄에 입력하세요 (Binance는 키당 최대 30개 IP 지원)
- 저장하고 2FA 검증을 완료하세요
- 참고: Binance는 IP 화이트리스트 변경 후 5분 전파 지연을 강제합니다
Bybit:
- API 관리에서 API 키를 편집하세요
- "IP 액세스"에서 "수정"을 클릭하세요
- 플랫폼의 서버 IP를 입력하세요 (Bybit는 최대 20개 IP 지원)
- IP 제한이 없는 키는 Bybit에서 90일 후 자동 만료됩니다
- 저장하려면 2FA 검증을 완료하세요
OKX:
- API 관리 패널에서 API 키를 편집하세요
- "IP 주소" 필드에 IP 주소를 추가하세요 (OKX는 최대 20개 IP 지원)
- OKX는 화이트리스트를 강력히 권장합니다 — 제한되지 않은 키는 더 낮은 속도 제한을 가집니다
- 저장하고 2FA로 확인하세요
Freya Finance는 API 키 연결 흐름 동안 서버 IP 주소를 표시합니다. 이를 거래소의 IP 화이트리스트에 직접 복사하세요. 플랫폼의 IP가 변경되면(드물게, 일반적으로 인프라 마이그레이션 동안), 새 주소와 함께 알림을 받게 됩니다.
일반적인 IP 화이트리스트 실수
| 실수 | 결과 | 수정 |
|---|---|---|
| 봇 서버 IP 대신 집 IP 사용 | 키가 노트북에서 작동하지만 봇에서는 작동하지 않음 | 플랫폼의 게시된 서버 IP 사용 |
0.0.0.0 또는 광범위한 범위 화이트리스트 | 실제 보호 없음 — 모든 소스 수락 | 특정 IP만 사용 |
| 플랫폼 마이그레이션 후 업데이트 잊음 | 봇이 조용히 거래 중지 | 연결 오류 모니터링, IP 최신 상태 유지 |
| 순환하는 VPN IP 추가 | 간헐적 실패 | 정적 IP 또는 플랫폼 IP 사용 |
API 키 순환: 90일 수명 주기
API 키는 비밀번호처럼 다루어져야 합니다: 유통 기한이 있습니다. 키가 더 오래 존재할수록, 로그 파일, 지원 티켓, 스크린샷 또는 메모리 덤프를 통해 노출되었을 확률이 더 높습니다. 전문 운영자는 고정 일정으로 키를 순환합니다.
권장 순환 주기
| 시나리오 | 순환 빈도 |
|---|---|
| 정상 운영 | 90일마다 |
| 손상 의심 후 | 즉시 |
| 플랫폼 보안 사고 후 | 즉시 |
| 플랫폼에서 액세스 취소 후 | 즉시 |
| 팀원 퇴사 후 | 즉시 |
다운타임 없는 순환 절차
키 순환은 거래 중단을 일으켜서는 안 됩니다. 이 순서를 따르세요:
1단계: 거래소에서 새 API 키 생성 이전과 동일한 권한과 IP 화이트리스트 설정으로 새 키를 생성하세요. 현재 날짜로 라벨을 붙이세요 (예: "Freya Bot — 2026년 5월").
2단계: 봇 플랫폼을 새 키로 업데이트 봇 플랫폼 설정에 새 API 키와 시크릿을 입력하세요. 대부분의 플랫폼은 봇을 중지하지 않고도 자격 증명을 업데이트할 수 있습니다.
3단계: 연결 확인 새 키가 작동하는지 확인하세요: 플랫폼이 성공적인 연결을 표시하고, 잔액이 올바르게 표시되며, 테스트 거래(가능하다면)가 실행됨을 확인합니다.
4단계: 거래소에서 이전 키 삭제 새 키가 작동함을 확인한 후에만, 거래소의 API 관리 페이지에서 이전 키를 삭제하세요.
5단계: 순환 문서화 순환 날짜, 새 키 라벨, 성공적인 전환 확인을 기록하세요.
이전 키와 새 키가 모두 존재하는 짧은 시간(2-4단계) 동안, 둘 다 유효합니다. 이 중복은 다운타임 없는 순환에 필요하며 이전 키가 몇 분 내에 삭제되기 때문에 안전합니다. 이 시간을 가능한 짧게 유지하세요.
서브계정 격리: 폭발 반경 제한
거래소 서브계정은 주 계정 아래의 별도 거래 계정입니다. 각 서브계정은 자체 잔액, 자체 API 키, 자체 거래 내역을 가집니다. 이는 사이버 보안의 네트워크 세분화의 거래소 등가물입니다.
서브계정이 중요한 이유
이 시나리오를 고려하세요: BTC DCA 봇, ETH 그리드 봇, SOL 모멘텀 봇 등 세 개의 봇을 실행하며, 모두 총 $30,000 자본으로 주 계정에 연결되어 있습니다.
서브계정 없이: 손상된 하나의 API 키가 $30,000을 노출합니다. 오작동하는 봇은 빠르고 불규칙한 거래를 통해 전체 잔액을 고갈시킬 수 있습니다.
서브계정으로: 각 봇은 $10,000과 함께 자체 서브계정에서 운영됩니다. 손상된 키는 $10,000만 노출합니다. 오작동하는 봇은 할당된 자본에만 영향을 미칠 수 있습니다. 다른 $20,000은 손댈 수 없습니다.
거래소별 서브계정 설정
| 기능 | Binance | Bybit | OKX |
|---|---|---|---|
| 최대 서브계정 | 200 (VIP 의존) | 20 (표준) | 5 (표준), VIP로 더 많음 |
| 별도 API 키 | ✅ 서브계정당 | ✅ 서브계정당 | ✅ 서브계정당 |
| 별도 잔액 | ✅ 격리됨 | ✅ 격리됨 | ✅ 격리됨 |
| 내부 이체 | ✅ 즉시, 무료 | ✅ 즉시, 무료 | ✅ 즉시, 무료 |
| 별도 거래 내역 | ✅ 완전 격리 | ✅ 완전 격리 | ✅ 완전 격리 |
| KYC 필요 | 주 계정 KYC 사용 | 주 계정 KYC 사용 | 주 계정 KYC 사용 |
권장 서브계정 아키텍처
세 개의 봇에 걸쳐 $30,000 포트폴리오:
주 계정 (마스터)
├── 서브계정 A: BTC DCA 봇 — $10,000
│ └── API 키 A (현물 거래 + 읽기, IP 화이트리스트)
├── 서브계정 B: ETH 그리드 봇 — $10,000
│ └── API 키 B (현물 거래 + 읽기, IP 화이트리스트)
├── 서브계정 C: SOL 모멘텀 봇 — $10,000
│ └── API 키 C (현물 거래 + 읽기, IP 화이트리스트)
└── 예비: $0 (주 계정 보유, 필요에 따라 이체)
각 서브계정은 자체 API 키, 자체 IP 화이트리스트를 가지며 자체 자금에만 액세스할 수 있습니다. 거래 권한이 없는 주 계정 키는 필요에 따라 서브계정 간 자금 이체를 처리합니다.
거래소가 거래 중 다운될 때
거래소 중단이 발생합니다. Binance, Bybit, OKX 모두 다운타임을 경험했습니다 — 때로는 계획된(유지보수), 때로는 계획되지 않은(DDoS 공격, 인프라 실패, 부하 급증을 일으키는 극도의 시장 변동성). 봇은 이를 우아하게 처리해야 합니다.
중단 동안의 미체결 주문
발주한 미체결 지정가 주문은 API에 접근할 수 없을 때에도 거래소의 주문장에 남아 있습니다. 매칭 엔진은 API 게이트웨이와 별개입니다. API 중단 동안에도 주문이 계속 체결될 수 있습니다.
이는 다음을 의미합니다: BTC에 대해 $99,500의 지정가 매수가 있고 API가 다운되면, 그 주문은 여전히 활성입니다. BTC가 $99,500로 떨어지면, 봇이 거래소와 통신할 수 없어도 체결됩니다.
봇 재연결 및 상태 조정
API가 다시 온라인이 되면, 잘 설계된 봇은 내부 상태를 거래소의 실제 상태와 조정해야 합니다. 이 프로세스에는 다음이 포함됩니다:
- 모든 미체결 주문 쿼리 — 어느 주문이 여전히 활성인지, 어느 것이 체결되었는지, 어느 것이 부분적으로 체결되었는지, 어느 것이 취소되었는지 확인
- 내부 기록과 비교 — 봇이 예상한 것에 대해 거래소 상태 매칭
- 불일치 해결 — 실제 체결을 기반으로 내부 포지션 업데이트
- 정상 작동 재개 — 조정된 상태에서 전략 실행 계속
Freya는 이 조정을 자동으로 처리합니다. 봇과 거래소의 연결이 끊어졌다가 다시 연결되면, Freya가 거래소와 포지션을 다시 대조하여 중단 동안 발생한 불일치를 바로잡으므로, 전략이 정확한 상태에서 재개됩니다.
부분 체결
부분 체결은 주문의 일부만 중단 전에 실행되거나(또는 유동성 부족으로 인해) 발생합니다. 예시:
- BTC에 대해 $100,000에 0.5 BTC 지정가 매수 발주 ($50,000 주문)
- API 연결이 끊어지기 전 0.3 BTC 체결 ($30,000)
- 봇이 재연결되면, 포지션에 0.3 BTC와 0.2 BTC 여전히 미체결을 발견
견고한 봇은 다음을 통해 이를 처리합니다:
- 부분 체결을 인식하고 포지션 크기 업데이트
- 남은 0.2 BTC 주문을 활성으로 유지할지 취소할지 결정
- 의도한 0.5 BTC가 아닌 실제 포지션 크기(0.3 BTC)를 기반으로 익절 및 손절 수준 조정
거래소 중단 동안 무엇을 해야 하는가
| 상황 | 작업 |
|---|---|
| 계획된 유지보수 발표 | 유지보수 윈도우 전 봇 일시 정지; 후 재개 |
| 예상치 못한 중단, 미체결 포지션 없음 | 대기 — 봇이 자동으로 재연결됩니다 |
| 예상치 못한 중단, 미체결 포지션 있음 | 거래소 상태 페이지 모니터링; 패닉으로 수동 거래하지 마세요 |
| 고변동성 중 중단 | 거래소 웹사이트(액세스 가능한 경우)를 통한 수동 개입 고려 |
| 장기 중단 (>1시간) | 다시 올라올 때 거래소 앱/웹사이트를 통해 포지션 검토 |
속도 제한: 거래소 경계 존중
거래소는 인프라가 압도되는 것을 보호하기 위해 속도 제한을 강제합니다. 모든 API 호출 — 모든 주문 배치, 모든 잔액 확인, 모든 시장 데이터 요청 — 은 속도 제한 예산에서 계산됩니다.
거래소 속도 제한
| 거래소 | 요청 제한 | 윈도우 | 위반 처벌 |
|---|---|---|---|
| Binance | 1,200 요청 | 분당 | 일시적 IP 차단 (2-10분) |
| Binance (주문 특정) | 10 주문/초, 200,000/일 | 계정당 | 주문 거부, 잠재적 차단 |
| Bybit | 120 요청 | 5초당 | 일시적 IP 차단 |
| OKX | 60 요청/초 (엔드포인트별 다양) | 초당 | 429 상태 코드, 조절 |
봇이 속도 제한을 관리하는 방법
전문 봇은 여러 속도 제한 관리 기법을 구현합니다:
요청 큐잉: API 호출을 즉시 발사하는 대신, 요청은 제어된 속도로 그것들을 해제하는 큐에 들어갑니다. Binance의 경우, 1,200/분 제한 이하로 잘 유지하기 위해 초당 20 요청을 초과하지 않습니다.
가중치 기반 예산: 일부 거래소(특히 Binance)는 다른 엔드포인트에 다른 "가중치"를 할당합니다. 간단한 잔액 확인은 1 가중치 비용이 들 수 있지만, 복잡한 주문 내역 쿼리는 20 비용이 듭니다. 봇은 한도를 적중하지 않기 위해 누적 가중치를 추적합니다.
지수 백오프: 봇이 속도 제한 오류(HTTP 429)를 받으면, 다시 시도하기 전에 점진적으로 더 오래 기다립니다: 1초, 그다음 2, 그다음 4, 그다음 8. 이는 재시도의 폭발이 상황을 더 나쁘게 만드는 것을 방지합니다.
REST보다 WebSocket: 시장 데이터의 경우, WebSocket 연결은 REST 엔드포인트를 폴링하는 것보다 훨씬 더 효율적입니다. 단일 WebSocket 연결은 속도 제한 예산을 소비하지 않고 실시간 가격 업데이트를 제공합니다. 잘 만들어진 봇은 데이터에 WebSocket을 사용하고 주문 관리에만 REST를 사용합니다.
같은 API 키에서 여러 봇을 실행하면 모든 봇에 걸쳐 속도 제한 예산을 공유합니다. 5개의 봇을 각각 50 요청/초로 하나의 키에서 실행하면, Binance의 한도를 즉시 적중합니다. 독립적인 속도 제한을 얻기 위해 봇당 별도의 API 키(이상적으로는 서브계정)를 사용하세요.
거래소 카운터파티 리스크: FTX 교훈
2022년 11월, FTX — 세계 3위의 암호화폐 거래소 — 가 일주일도 안 되어 붕괴했습니다. 80억 달러의 고객 자금이 사라졌습니다. 전체 거래 자본을 FTX에 가진 사용자는 API 키가 얼마나 안전했는지 또는 봇이 얼마나 잘 수행했는지에 관계없이 모든 것을 잃었습니다.
교훈: 거래소 자체가 실패하면 API 키 보안은 무관합니다.
카운터파티 리스크 유형
| 리스크 유형 | 설명 | 역사적 예 |
|---|---|---|
| 지급 불능 | 거래소가 예금을 충당할 충분한 자산이 없음 | FTX (2022) |
| 규제 압수 | 정부가 거래소를 폐쇄하거나 동결 | Bitzlato (2023) |
| 해킹/침해 | 거래소 핫 월렛 손상 | Mt. Gox (2014), Bitfinex (2016) |
| 출금 동결 | 거래소가 위기 동안 출금 중단 | 시장 폭락 동안 여러 거래소 |
| 기술적 실패 | 거래 손실을 일으키는 장기 중단 | 다양, 극도의 변동성 동안 |
다중 거래소 다각화
완화는 간단합니다: 모든 거래 자본을 단일 거래소에 보관하지 마세요. 2-3개의 주요한, 독립적으로 운영되는 거래소에 분산하세요.
$60,000 총 자본에 대한 예시 할당:
| 거래소 | 할당 | 실행 봇 |
|---|---|---|
| Binance | $25,000 (42%) | BTC DCA, ETH 그리드 |
| Bybit | $20,000 (33%) | SOL DCA, AVAX 모멘텀 |
| OKX | $15,000 (25%) | BTC 그리드, 다중 거래쌍 DCA |
어느 단일 거래소가 실패하면, 자본의 최대 42%를 잃습니다 — 고통스럽지만 살아남을 수 있습니다. $60,000을 FTX에만 가지고 있었다면, 100%를 잃었습니다.
카운터파티 리스크에 대해 무엇을 모니터링해야 하는가
- 준비금 증명 보고서 — 정기적으로 게시되나요? 평판 있는 회사에서 감사받나요?
- 출금 처리 시간 — 출금의 갑작스러운 지연은 조기 경고 신호입니다
- 소셜 미디어와 뉴스 — 거래소 임원이 불규칙하게 행동, 비정상적인 기업 변경
- 규제 발전 — 주요 시장의 소송, 규제 조치 또는 라이선스 취소
- 자체 출금 능력 — 자금에 액세스할 수 있는지 확인하기 위해 정기적으로 출금 테스트
활성 거래 자본만 거래소에 보관하세요. 장기 보유와 예비는 자체 보관 지갑(Ledger 또는 Trezor 같은 하드웨어 지갑)에 있어야 합니다. 합리적인 지침: 언제든 총 암호화폐 포트폴리오의 30-40% 이상을 거래소에 두지 마세요.
사고 대응 체크리스트
보안 사고가 발생할 때 — 또는 의심될 때조차도 — 대응 속도가 결과를 결정합니다. 이 체크리스트를 순차적으로 따르세요:
1단계: 의심되는 API 키 즉시 비활성화
거래소에 직접 로그인(URL을 수동으로 입력, 링크 클릭하지 마세요). 손상된 키를 삭제하거나 비활성화하세요. 이는 30초가 걸리고 모든 무단 액세스를 즉시 차단합니다.
2단계: 모든 미체결 주문 확인 및 취소
거래소의 모든 미체결 주문을 검토하세요. 발주하지 않았거나 인식하지 못하는 모든 것을 취소하세요. 봇이 사용하는 것뿐만 아니라 모든 거래쌍을 확인하세요 — 공격자가 선택하지 않을 거래쌍을 거래할 수 있습니다.
3단계: 출금 내역 확인
지난 24-48시간의 출금 내역을 확인하세요. 모든 출금이 당신에 의해 승인되었는지 확인하세요. 무단 출금을 보면, 즉시 거래소 지원에 연락하고 거래 해시를 문서화하세요.
4단계: 거래소 비밀번호 변경
비밀번호를 새로운, 무작위로 생성된 문자열로 재설정하세요(비밀번호 관리자 사용). 공격자가 더 광범위한 계정 액세스를 가지고 있었다면, 이전 비밀번호가 손상되었습니다.
5단계: IP 화이트리스트가 있는 새 API 키 생성
최소 필수 권한과 엄격한 IP 화이트리스트로 새 API 키를 생성하세요. 손상된 키의 설정을 재사용하지 마세요.
6단계: 봇 설정 업데이트
봇 플랫폼에 새 API 자격 증명을 입력하세요. 거래를 재개하기 전에 연결성과 올바른 작동을 확인하세요.
7단계: 액세스 로그 감사
검토:
- 친숙하지 않은 IP 주소에 대한 거래소 API 액세스 로그
- 무단 세션에 대한 거래소 로그인 내역
- 무단 액세스 또는 전달 규칙에 대한 이메일 계정
- 무단 설정 변경에 대한 봇 플랫폼 계정
8단계: 사고 보고
발견 사항으로 거래소의 공식 보안 팀에 연락하세요. 자금이 도난당했다면, 지역 법 집행과 국가의 금융 범죄 당국에 신고하세요.
보안 감사 체크리스트: 모든 봇 운영자가 검증해야 할 10개 항목
이 체크리스트를 매월 검토하세요. 각 항목은 1분 미만으로 확인됩니다:
| # | 감사 항목 | 검증 방법 | ✅ / ❌ |
|---|---|---|---|
| 1 | 모든 API 키에서 출금 권한 비활성화됨 | 거래소 API 관리 페이지 | |
| 2 | 모든 API 키에서 IP 화이트리스트 활성화됨 | 거래소 API 관리 페이지 | |
| 3 | 거래소 계정에 2FA 활성화됨 (SMS가 아닌 인증 앱) | 거래소 보안 설정 | |
| 4 | 봇 플랫폼 계정에 2FA 활성화됨 | 플랫폼 보안 설정 | |
| 5 | 지난 90일 이내에 순환된 API 키 | 키 생성 날짜 확인 | |
| 6 | 거래소에 안티 피싱 코드 설정됨 | 거래소 보안 설정 | |
| 7 | 불필요한 API 키 없음 (이전/사용되지 않은 키 삭제됨) | 거래소 API 관리 페이지 | |
| 8 | 의도된 할당 한도 내의 서브계정 잔액 | 거래소 잔액 개요 | |
| 9 | 최근 검증된 거래소 준비금 증명 | 거래소 투명성 페이지 | |
| 10 | 비상 대응 계획 검토 (키 취소 위치 알기) | 멘탈 워크스루 |
이 체크리스트를 검토하기 위해 매월 1일에 캘린더 알림을 설정하세요. 10분이 걸리고 취약성이 되기 전 설정 드리프트, 잊혀진 이전 키, 그리고 만료된 보안 설정을 잡습니다.
모두 합치기: 심층 방어
어떤 단일 보안 조치도 충분하지 않습니다. 전문 봇 운영자는 단일 계층의 실패가 침해로 이어지지 않도록 여러 방어를 계층화합니다:
| 방어 계층 | 보호하는 것 | 구현 |
|---|---|---|
| 권한 범위 (출금 없음) | 키 손상에서 총 자금 손실 | 거래소 API 설정 |
| IP 화이트리스트 | 도난당한 키의 원격 사용 | 거래소 API 설정 |
| 키 순환 (90일) | 장기 키 노출 | 예정된 절차 |
| 서브계정 격리 | 봇 간 오염, 폭발 반경 | 거래소 서브계정 설정 |
| 2FA (인증 앱) | 비밀번호 도난으로 인한 계정 인수 | 거래소 + 플랫폼 설정 |
| 안티 피싱 코드 | 이메일 피싱 공격 | 거래소 보안 설정 |
| 다중 거래소 다각화 | 거래소 지급 불능/실패 | 포트폴리오 아키텍처 |
| 월간 보안 감사 | 설정 드리프트, 잊혀진 키 | 예정된 검토 |
각 계층은 독립적입니다. 공격자가 IP 화이트리스트를 우회한다면(봇 서버를 손상시켜서), 여전히 권한 범위(출금 없음), 서브계정 격리(제한된 자본 노출), 그리고 사고 대응 절차에 직면합니다.
자주 묻는 질문
IP 화이트리스트 추가를 잊으면 어떻게 되나요?
IP 화이트리스트 없이, API 키는 전 세계 어디 IP 주소에서나 작동합니다. 누군가 키를 얻으면(데이터 침해, 우발적 노출 또는 피싱을 통해), 자체 인프라에서 사용할 수 있습니다. Bybit에서는 IP 제한이 없는 키가 90일 후 자동 만료됩니다 — 안전망. Binance와 OKX에서는 무기한 활성 상태로 유지됩니다. 지금 IP 화이트리스트를 추가하세요; 2분이 걸립니다.
여러 봇에 같은 API 키를 사용할 수 있나요?
기술적으로 네, 그러나 나쁜 관행입니다. 하나의 키를 공유하는 여러 봇은 속도 제한을 공유하여 속도 제한 위반을 쉽게 트리거합니다. 또한 모든 봇에 영향을 미치지 않고 하나의 봇에 대한 액세스를 취소할 수 없다는 의미입니다. 봇당 하나의 API 키를 사용하세요(이상적으로는 별도의 서브계정과 함께).
API 키가 손상되었는지 어떻게 알 수 있나요?
경고 신호로는: 인식하지 못하는 거래가 내역에 나타남, 예상치 못한 잔액 변경, 봇이 유휴 상태일 때 속도 제한 오류(다른 사람이 키를 사용하고 있음을 시사), 또는 친숙하지 않은 IP에서 로그인 알림. 이러한 것 중 하나를 본다면, 즉시 키를 삭제하고 사고 대응 체크리스트를 따르세요.
거래소가 IP 화이트리스트 요구사항을 변경하면 어떻게 되나요?
거래소는 가끔 IP 화이트리스트 시스템을 업데이트합니다. 일반적으로 이메일 알림을 받게 됩니다. 봇이 갑자기 거래 실행을 멈추면, 거래소가 API 인증 요구사항을 변경했는지 확인하세요. 이는 드뭅니다 — 주요 거래소는 하위 호환성을 목표로 합니다 — 그러나 모니터링할 가치가 있습니다.
봇을 하나만 실행해도 서브계정을 사용해야 하나요?
네. 서브계정은 봇의 거래 자본과 예비 자금 사이에 명확한 경계를 만듭니다. 봇 하나로도, 서브계정은 오작동하는 봇(또는 전략의 버그)이 명시적으로 할당된 자본에만 영향을 미칠 수 있도록 보장합니다. 설정 비용이 없고 의미 있는 보호를 추가합니다.
속도 제한 위반이 내 거래에 어떻게 영향을 미치나요?
속도 제한 위반은 API 요청의 일시적 거부를 초래합니다. 차단 기간 동안(일반적으로 2-10분), 봇은 주문을 발주하거나, 잔액을 확인하거나, 포지션을 관리할 수 없습니다. 변동성 시장에서, 5분 동안 잠겨 있는 것은 손절 트리거 또는 수익성 있는 진입을 놓치는 것을 의미할 수 있습니다. 적절한 속도 제한 관리는 선택사항이 아닙니다 — 신뢰할 수 있는 봇 운영에 필수적입니다.
다중 거래소 다각화가 복잡성의 가치가 있나요?
물론입니다. 2-3개 거래소에 걸쳐 봇을 관리하는 것은 약간 더 많은 관리 노력을 필요로 하지만, 리스크 감소는 엄청납니다. FTX 붕괴는 단일 플랫폼에 자본을 집중시킨 트레이더를 쓸어버렸습니다. 다각화는 어떤 양의 API 키 보안이나 IP 화이트리스트도 방지할 수 없는 이벤트로부터 보호합니다: 거래소 자체가 실패하는 것.