규제 기관은 암호화폐 거래소를 어떻게 감사하는가: 무엇을 확인하고 어떻게 준비할 것인가

목차

• 대부분의 거래소가 첫 감사에서 실패하는 이유
• 규제 감사의 네 가지 유형
• AML/KYC 통제: 대부분의 거래소를 침몰시키는 항목
• 준비금 검증과 지급 능력 증명
• 사이버 보안과 침투 테스트
• 운영 통제와 거버넌스
• 기록 보관: 가장 지루하지만 가장 중요한 부분
• 실패하면 어떻게 되는가
• 실제로 효과 있는 사전 감사 체크리스트
• 기술 스택이 감사 성패를 가르는 방식

감사가 실제로 이루어지기 전에 컴플라이언스 요구사항 체크리스트를 통해 심사관이 어떤 구성을 기대하는지 미리 파악할 수 있습니다.

대부분의 거래소가 첫 감사에서 실패하는 이유

조금 긴장될 수 있는 이야기를 하나 해드리겠습니다. 첫 공식 규제 감사를 받는 암호화폐 거래소의 약 60%가 중대한 지적 사항(material findings)을 받습니다. 경미한 관찰 사항이 아닙니다. 라이선스 발급을 지연시키거나 운영을 제한하거나 규제 집행 조치를 촉발할 수 있는 종류의 중대한 지적 사항입니다.

우리는 이런 일이 반복되는 것을 지켜봐 왔습니다. 한 팀이 견고한 트레이딩 플랫폼을 구축하고, 매칭 엔진을 원활하게 돌리고, 마케팅을 시작하고, 심지어 수천 명의 사용자를 확보합니다. 그런데 규제 기관이 첫 검사를 나오면 모든 것이 멈춰 버립니다. 6개월 전의 기본적인 거래 기록을 제출하지 못하거나, 문서상의 AML 정책이 시스템이 실제로 작동하는 방식과 일치하지 않기 때문입니다.

문제는 대개 기술 역량이 아닙니다. 준비입니다. 대부분의 거래소 운영자는 컴플라이언스 문서를 체크박스식 과제로 취급합니다. 라이선스를 통과하기 위해 한 번 작성하고 잊어버리는 것입니다. 반면 규제 기관은 이를 어느 시점에서든 실제 운영을 반영해야 하는 살아있는 시스템으로 봅니다.

간극은 바로 여기에 있습니다. 라이선스 신청서에는 할 계획인 것이 적혀 있습니다. 감사는 실제로 한 것을 확인합니다. 이 두 가지가 일치하지 않으면 문제가 생깁니다.

좋은 소식이요? 흔한 감사 실패는 모두 예방 가능합니다. 그들이 무엇을 찾는지만 알면 됩니다.

규제 감사의 네 가지 유형

모든 감사가 같지는 않으며, 어떤 감사를 앞두고 있는지에 따라 준비 방법이 달라집니다.

1. 라이선스 사전 검사

일부 규제 기관은 라이선스를 부여하기 전에 검사관을 별도로 파견해 신청 내용이 사실인지 확인합니다. 두바이의 VARA는 정식 라이선스를 발급하기 전에 현장 평가를 실시합니다. 싱가포르의 MAS는 기술 리스크 평가를 수행합니다. MiCA에 따른 EU 회원국의 관할 당국도 사전 인가 현장 방문을 점점 더 많이 실시하고 있습니다.

확인 사항: 실제 운영이 신청서에 기술한 내용과 일치하는가? 명시된 인물들이 실제로 이곳에서 근무하는가? 기술 스택이 실재하는가, 아니면 허상인가?

2. 정기 감독 감사

라이선스를 취득한 후에는 대부분의 규제 기관이 정기 감사 일정을 잡습니다. 일반적으로 매년 또는 18개월마다입니다. 프랑스의 AMF, 독일의 BaFin, MAS 모두 정기 감독 검토를 실시합니다.

확인 사항: 라이선스 조건의 지속적인 준수 여부. 약속한 통제를 유지하고 있는가? AML 보고서를 기한 내에 제출하고 있는가? 사고를 적절히 보고했는가?

3. 테마별 검토

규제 기관은 때때로 특정 주제를 정해 그 테마에 대해 여러 거래소를 감사합니다. 2025년 말 ESMA는 EU 6개국에 걸쳐 암호화폐 거래소의 고객 자산 분리 관행에 대한 테마별 검토를 실시했습니다. FCA도 금융 프로모션에 대해 유사한 조치를 취했습니다.

확인 사항: 특정 한 분야에 대한 심층 검토. 다른 모든 것을 잘하더라도 그들이 현미경으로 들여다보기로 한 그 하나의 주제에서 타격을 입을 수 있습니다.

4. 사유 발생 조사

무언가가 의심을 촉발한 경우입니다. 고객 불만, 은행이 제출한 이상거래 보고, 시장 감시가 포착한 비정상적인 거래 패턴, 또는 내부고발자 등입니다. 규제 기관은 구체적인 질문을 들고, 훨씬 덜 우호적인 태도로 나타납니다.

확인 사항: 조사를 촉발한 사안 전부. 이러한 감사는 표적화되어 있고, 신속하며, 집행 조치로 이어질 확률이 훨씬 높습니다.

각 관할권이 라이선스에 요구하는 사항에 대한 더 넓은 시각은 암호화폐 거래소 라이선스 가이드를 참조하세요.

AML/KYC 통제: 대부분의 거래소를 침몰시키는 항목

거래소가 감사에서 실패한다면 아마 여기서 실패할 것입니다. AML/KYC는 규제 기관이 가장 많은 경험을 갖고 있고, 기대치가 가장 명확하며, 허점에 대한 관용이 가장 없는 영역입니다.

감사관이 실제로 확인하는 내용은 다음과 같습니다.

고객 신원 확인 및 인증

감사관은 고객 계정 샘플(보통 다양한 리스크 등급에서 20~50개)을 추출해 각 계정을 온볼링 과정 전체에 걸쳐 추적합니다. 필요한 서류를 수집했는가? 검증했는가? KYC 시스템이 이상 징후를 탐지했는가? 인증에 얼마나 걸렸는가? 인증 완료 전에 거래를 시작한 사람이 있는가?

결정타 질문: “온볼링 과정에서 거절된 고객을 보여주고 그 이유를 설명하세요.” 거절 사례를 제시하지 못하면, 감사관은 모든 신청자를 승인하고 있다고 가정합니다. 이는 통제가 작동하지 않는다는 뜻입니다.

거래 모니터링

감사관은 거래 모니터링 규칙을 보고 나서 그것을 테스트하고 싶어합니다. 이렇게 묻습니다. “무엇이 이상거래 알림을 촉발하는가?” 그런 다음 알림 로그를 살펩니다. 그리고 알림을 실제 데이터의 의심스러운 패턴과 대조합니다.

흔한 실패: 문서상의 규칙이 시스템이 실제로 수행하는 것과 일치하지 않는 경우. 정책에는 구조화(structuring, 임계값 회피를 위해 큰 거래를 작은 거래로 쪼개는 행위)를 모니터링한다고 되어 있는데 모니터링 시스템에 실제로 구조화 규칙이 없다면, 그것은 중대한 지적 사항입니다.

SAR 제출 이력

의심거래보고(SAR)를 몇 건 제출했는가? 언제? 무엇이 촉발했는가? 결과는 어떠했는가?

SAR 제출 건수가 0건이라는 것은 위험 신호입니다. 깨끗하다는 뜻이 아니라 들여다보지 않고 있다는 뜻입니다. 의미 있는 거래량을 가진 모든 거래소는 의심스러운 활동을 마주칩니다. 감사관은 이를 압니다. 의심스러운 것을 본 적이 한 번도 없다고 주장하면, 그들은 더 깊이 파고들 것입니다.

강화된 실사(EDD)

고위험 고객(PEP(정치적 노출 인물), 고위험 관할권 출신 고객, 대량 거래자)에 대해서는 문서화된 추가 조사가 있어야 합니다. 감사관은 고위험 고객 목록을 추출해 EDD가 실제로 수행되었는지 확인합니다.

KYC 및 AML 컴플라이언스가 실무에서 어떤 모습인지에 대한 전체 그림은 KYC 컴플라이언스 가이드에서 다루었습니다. 감사 후가 아니라 감사 전에 읽으세요.

제재 스크리닝

OFAC, EU, UN 제재 목록과 대조하여 스크리닝하고 있는가? 목록을 얼마나 자주 업데이트하는가? 일치 항목이 나오면 어떻게 되는가? 일치 사례와 그에 대한 조치를 보여주세요.

제재 스크리닝은 온볼링 시점뿐 아니라 지속적이어야 합니다. 고객이 이미 인증된 후에 제재 목록에 추가되면, 시스템이 이를 포착할 수 있어야 합니다. 컴플라이언스 모듈은 업데이트된 목록에 대해 최소 매일 일괄 재스크리닝을 실행해야 합니다.

준비금 검증과 지급 능력 증명

FTX 사태 이후, 규제 기관은 거래소가 주장하는 자산을 실제로 보유하고 있는지에 깊은 관심을 갖게 되었습니다. 여러 관할권에서 이제 정기적인 준비금 증명(proof-of-reserves) 공증을 요구합니다.

감사관이 확인하는 사항:

• 자산 분리. 고객 자금이 운영 자금과 분리되어 보관되는가? 지갑 수준에서 명확한 분리를 입증할 수 있는가? 대부분의 규제 기관은 고객 자산과 회사 자산에 대해 별도의 핫/콜드 지갑을 보기를 원합니다.
• 1:1 담보. 총 고객 부채(사용자에게 빚진 금액)가 총 자산(실제로 보유한 것)과 일치하는가? 감사관은 내부 장부를 온체인 잔액과 비교합니다.
• 제3자 공증. 일부 관할권은 독립 회계법인의 준비금 증명 감사를 요구합니다. 요구되지 않는 곳에서도 이를 갖추면 앞서 나갈 수 있습니다. Armanino와 Mazars(중단하기 전) 같은 회사들이 주요 거래소를 위해 이런 감사를 수행한 바 있습니다.
• 콜드 스토리지 검증. 감사관은 콜드 스토리지 지갑에서 메시지에 서명하여 통제권을 입증하라고 요청할 수 있습니다. 이를 위한 절차를 미리 준비하세요. 규제 기관 담당자가 사무실에 앉아 있는 동안 하드웨어 지갑 키를 찾아 헤매고 싶지는 않을 것입니다.

흔한 실수:

고객 예치금을 운전 자본으로 사용하는 것. 일시적으로라도요. 나중에 갚을 의도가 있더라도요. 감사관이 고객 BTC가 어떤 이유로든 거래소의 운영 지갑으로 이동한 사실을 발견하면, 그것은 중대한 지적 사항이며 일부 관할권에서는 잠재적으로 형사 사건이 됩니다.

사이버 보안과 침투 테스트

규제 기관은 거래소가 전통 금융 기관에 필적하는 보안 프로그램을 유지할 것을 점점 더 기대합니다. VARA의 기술 평가는 특히 철저합니다. MiCA는 CASP에 “건전한 ICT 리스크 관리”를 요구합니다.

감사관이 보고 싶어하는 것:

• 침투 테스트 보고서. 마지막 펜테스트는 언제였는가? 누가 수행했는가? 무엇을 발견했는가? 무엇을 수정했는가? 연간 펜테스트는 최소 기대치입니다. 일부 규제 기관은 연간 펜테스트에 더해 분기별 취약점 스캔을 보기를 원합니다.
• 사고 대응 계획. 문서뿐만 아니라 테스트된 계획이어야 합니다. 감사관은 마지막 도상훈련(tabletop exercise)이나 심지어 마지막 실제 사고에 대해 물을 수 있습니다. “사고가 없었다”는 답은 안심이 되지 않습니다. 오히려 탐지하지 못하고 있다는 뜻으로 들립니다.
• 접근 통제. 누가 프로덕션 시스템에 접근하는가? 접근 권한은 어떻게 부여되고 회수되는가? 다단계 인증(MFA)이 있는가? 관리자 작업에 대한 감사 로그가 있는가?
• 키 관리. 개인 키는 어떻게 생성, 저장, 교체, 복구되는가? 다중서명(multi-signature) 요건은? 하드웨어 보안 모듈(HSM) 사용 여부는?

보안 아키텍처는 감사에 바로 사용할 수 있는 문서를 산출해야 합니다. 그렇지 않다면 감사 때마다 몇 주씩 수작업으로 문서를 취합하게 될 것입니다.

강력한 보안 태세가 어떤 모습인지에 대한 기술적 세부 사항은 보안 아키텍처 심층 분석에서 구체적으로 다룹니다.

감사 추적(audit trail) 질문:

플랫폼에서의 모든 작업(관리자 작업이든 아니든)은 로그에 기록되어야 합니다. 감사관은 특정 이벤트에 대한 로그를 요청할 것입니다. “지난 30일간 핫 지갑의 접근 로그를 보여주세요.” “이 사용자 계정에 대한 모든 관리자 작업을 보여주세요.” “수수료 구성의 변경 로그를 보여주세요.”

이런 로그를 제시하지 못하면, 감사관은 아무 일도 없었던 것인지, 일어난 일에 대한 기록이 없는 것인지 알 수 없습니다. 최악을 가정할 것입니다.

관리자 대시보드가 여기서 최전선입니다. 타임스탬프, 사용자 신원, IP 주소, 그리고 모든 변경의 전후 상태를 포함하여 모든 작업을 로깅해야 합니다.

운영 통제와 거버넌스

규제 기관은 거래소가 명확한 책임과 감독 체계를 갖춘 유능한 사람들에 의해 운영되고 있음을 보기를 원합니다.

이사회 및 경영진 구조:

• 컴플라이언스에 대한 최종 책임자는 누구인가? 이름을 대세요.
• 이사회(또는 이에 준하는 감독 기구)가 정기적인 컴플라이언스 보고를 받는가?
• 컴플라이언스 이슈에 대한 문서화된 보고(에스컬레이션) 경로가 있는가?
• 경영진 중 과거에 규제 조치를 받은 사람이 있는가? (그들은 확인합니다.)

정책 및 절차:

감사관은 전체 정책 묶음을 요청할 것입니다. 최소한 다음이 필요합니다.

• AML/CFT 정책
• KYC 절차
• 리스크 관리 프레임워크
• 사고 대응 정책
• 업무 연속성/재해 복구 계획
• 민원 처리 절차
• 이해상충 정책
• 시장 남용/감시 정책
• 데이터 보호/개인정보 정책

각 정책에는 버전 번호, 담당자, 최종 검토일, 그리고 직원 교육 증빙이 있어야 합니다. 2년 전에 작성된 후 한 번도 업데이트되지 않은 정책은 위험 신호입니다.

변경 관리:

마지막 감사 이후 새로운 상품이나 기능을 출시했는가? 감사관은 출시 후가 아니라 출시 전에 컴플라이언스 영향을 평가했음을 보기를 원합니다. “6개월 전에 마진 거래를 추가했습니다”라는 말 뒤에 컴플라이언스 검토에 대한 침묵이 이어지면, 그것은 지적 사항입니다.

기록 보관: 가장 지루하지만 가장 중요한 부분

기록 보관은 거래소 구축 단계에서 가장 적은 관심을 받지만, 감사에서 가장 많은 문제를 일으킵니다. 무엇을 얼마나 오래 보관해야 하는지 정리합니다.

거래 기록: 모든 거래, 입금, 출금, 내부 이체. 대부분의 관할권은 5~7년의 보관을 요구합니다. MiCA는 5년을 명시합니다. VARA는 8년을 원합니다. MAS는 사업 관계 종료 후 5년을 요구합니다.

KYC 기록: 모든 신분 서류, 인증 결과, EDD 파일, 지속적 모니터링 기록. 보관 기간은 거래 기록과 동일합니다.

커뮤니케이션 기록: 고객 지원 상호작용, 내부 컴플라이언스 커뮤니케이션, 그리고 의심 활동 조사와 관련된 모든 커뮤니케이션. 네, 지원 티켓과 내부 채팅 로그를 아카이빙해야 한다는 뜻입니다.

시스템 로그: 접근 로그, 오류 로그, 변경 로그, 보안 이벤트 로그. 최소 2년, 하지만 5년이 더 안전합니다.

형식도 중요합니다. 기록은 검색 가능해야 하고 합리적인 기간 내에 제출 가능해야 합니다. “전부 데이터베이스에 있지만 추출에 2주가 걸립니다”는 용납되지 않습니다. 감사관은 요청 후 24~48시간 이내에 특정 기록을 제출할 것을 기대합니다.

기록 보관 정책은 첫날부터 시스템 아키텍처에 내재화하세요. 매년 데이터를 삭제해 온 상태에서 소급하여 5년 보관을 구현하는 것은… 규제 기관과 나누기 좋은 대화가 아닙니다.

실패하면 어떻게 되는가

감사 결과는 일반적으로 네 가지 범주로 나뉩니다.

1. 관찰 사항이 포함된 적정 의견. 통과했습니다. 감사관은 개선할 부분을 몇 가지 지적했지만 즉각적인 조치가 필요한 것은 없습니다. 조용히 축하하고 다음 감사 전에 관찰 사항을 해결하세요.

2. 중대한 지적 사항이 포함된 한정 의견. 대체로 통과했지만 요구사항을 충족하지 못하는 특정 영역이 있습니다. 각 지적 사항에 대해 보통 30~90일의 시정 기한이 주어집니다. 기한을 지키지 못하면 결과가 따릅니다.

3. 부적정 의견. 실패했습니다. 복수의 중대한 지적 사항, 어쩌면 시스템적인 문제가 있습니다. 규제 기관은 시정이 완료되고 검증될 때까지 운영을 제한할 수 있습니다(신규 고객 온볼링 금지, 거래량 축소). 가속화된 후속 감사를 받게 될 가능성이 높습니다.

4. 라이선스 취소 또는 정지. 최악의 경우입니다. 지적 사항이 너무 심각해서 규제 기관이 운영 지속 자격 자체에 의문을 품는 경우입니다. 특히 고객 자산이 위험에 처한 극단적인 경우, 규제 기관은 즉각적인 정지를 강제할 수 있습니다.

추이도 중요합니다. 첫 감사에서 지적 사항이 3건이었는데 두 번째 감사에서 5건이라면 나쁜 추세입니다. 규제 기관은 시간이 지남에 따른 개선을 보기를 원합니다. 악화된다는 것은 경영진이 컴플라이언스를 진지하게 받아들이지 않는다는 뜻입니다.

실제로 효과 있는 사전 감사 체크리스트

감사 6주 전, 여기서 시작하세요.

6~5주 전: 문서 검토

• 모든 정책 문서를 꺼내세요. 버전 번호와 최종 검토일을 확인하세요
• 12개월 이상 된 정책은 업데이트하세요
• 정책이 실제 시스템 동작과 일치하는지 확인하세요(문서만 읽지 말고 실제로 테스트하세요)
• 필요한 모든 정책이 존재하는지 확인하세요(위의 운영 통제 목록 참조)

4~3주 전: 시스템 테스트

• 자체 거래 모니터링 규칙을 샘플 데이터에 대해 실행하세요. 올바르게 작동하는가?
• 무작위로 30개의 고객 계정을 추출해 KYC 과정을 추적하세요
• SAR 제출 로그가 완전하고 최신인지 확인하세요
• 임의의 기간에 대한 거래 기록을 24시간 이내에 제출할 수 있는지 확인하세요
• 관리자 대시보드의 감사 추적을 테스트하세요. 지난 6개월간의 모든 관리자 작업을 보여줄 수 있는가?

2~1주 전: 인력 준비

• 예상 질문과 증빙 요구사항에 대해 컴플라이언스 담당자를 브리핑하세요
• 직면할 수 있는 사이버 보안 질문에 대해 CTO/기술 리드를 브리핑하세요
• 감사 기간 동안 핵심 인력이 대기할 수 있도록 하세요(휴가 금지)
• 주제별로 정리된 문서가 담긴 데이터 룸(물리적 또는 가상)을 준비하세요

당일:

• 감사관의 요청을 관리하는 지정된 담당 창구를 두세요
• 데이터 요청에 신속하게 응답하세요. 속도는 역량을 보여줍니다
• 질문에 대한 답을 모른다면 그렇게 말하세요. 추측하지 마세요. “오늘 안으로 회신드리겠습니다”가 틀린 답변보다 낫습니다
• 감사관이 묻는 모든 것을 기록하세요. 그들의 질문은 그들이 무엇에 집중하고 있는지를 알려줍니다

기술 스택이 감사 성패를 가르는 방식

충분히 말해지지 않는 사실이 하나 있습니다. 거래소 소프트웨어는 감사 통과 여부를 결정하는 가장 큰 단일 요인입니다. 컴플라이언스 팀도 아니고(물론 중요하지만), 정책도 아닙니다(그것도 중요하지만). 바로 기술입니다.

왜일까요? 감사관은 정책에 무엇이 적혀 있는지 신경 쓰지 않기 때문입니다. 시스템이 무엇을 하는지를 신경 씁니다. 그리고 시스템에서 데이터를 추출하여 검증합니다.

기술 스택이 지원해야 하는 것:

• 내장된 감사 추적. 모든 사용자 작업, 관리자 작업, 시스템 이벤트, 구성 변경이 불변하게 로깅되어야 합니다. 거래소 소프트웨어가 관리자 작업을 로깅하지 않으면 거버넌스를 입증할 수 없습니다.
• 온디맨드 보고. 감사관은 거래 보고서, KYC 현황 보고서, SAR 제출 이력, 시스템 접근 로그를 요구할 것입니다. 보고서 생성에 수일의 엔지니어링 작업이 필요하다면 곤란합니다. 좋은 거래소 소프트웨어는 컴플라이언스 보고가 내장되어 출시됩니다.
• KYC/AML 통합. 신원 인증, 거래 모니터링, 제재 스크리닝은 플랫폼에 통합되어 있어야 하며, 사후에 덧붙인 것이어서는 안 됩니다. 감사관은 통합 지점에서 허점을 찾습니다.
• 인프라 수준의 자산 분리. 지갑 아키텍처는 정책이 아니라 설계에 의해 고객/운영 자금 분리를 강제해야 합니다. 사람의 실수로 자금이 우발적으로 혼합될 수 있다면, 그것은 설계 결함입니다.
• 구성 가능한 컴플라이언스 규칙. 관할권마다 임계값, 보고 요건, 모니터링 기대치가 다릅니다. 시스템은 맞춤 개발 없이 이러한 설정을 구성할 수 있어야 합니다.

감사를 가뿐하게 통과하는 거래소들은 기술 스택이 정상적인 운영의 부산물로서 컴플라이언스 증빙을 생성하는 거래소입니다. 팀이 감사 증빙을 수작업으로 취합해야 한다면, 아키텍처에 문제가 있는 것입니다.

---

출처 및 추가 읽을거리

• FATF 가상자산 리스크 기반 접근법 지침 — Financial Action Task Force
• MiCA 규정 — 제V편: CASP 의무 — European Parliament
• VARA 컴플라이언스 및 리스크 관리 규칙서 — Dubai Virtual Assets Regulatory Authority
• MAS 기술 리스크 관리 지침 — Monetary Authority of Singapore
• 암호자산 거래 플랫폼 관련 이슈, 리스크 및 규제 고려사항에 대한 IOSCO 보고서 — IOSCO