운영 리스크

운영 리스크와 예방 설계

이 장은 KSC(ieum) SaaS를 운영하면서 발생할 수 있는 비기술적·운영상의 리스크와 이를 어떻게 구조적으로 방지하는지를 설명합니다.

KSC는 다음 전제를 기반으로 설계되었습니다.

대부분의 사고는 “해킹”이 아니라 운영 과정에서의 오해·절차 누락·책임 불명확성에서 발생한다.

---

이 장을 읽어야 하는 대상

• 은행 실무자 (발행·정산 담당)

• 신탁사 실무자 (담보·승인 담당)

• 내부 감사 / 리스크 관리 조직

• PoC 이후 실서비스 전환을 검토하는 의사결정자

---

KSC가 정의하는 운영 리스크의 범위

KSC에서 말하는 **운영 리스크(Operational Risk)**는 다음을 포함합니다.

• 잘못된 발행 판단

• 승인 절차 누락

• 수량 단위 오해

• 책임 주체 혼동

• 기록 누락 또는 해석 오류

• 사후 감사 대응 불가 상태

👉 즉, 기술 장애 이전 단계의 리스크입니다.

---

주요 운영 리스크 유형

1. 발행 한도 오판 리스크

리스크 설명

• 입금이 발생했으나 담보 승인 전 발행을 시도

• Issuance Limit를 오해하고 발행 요청

실제 현장에서의 결과

• 발행 실패

• “시스템 오류”로 오해

• 불필요한 QA·커뮤니케이션 발생

KSC의 방지 설계

• Deposit ≠ Collateral 명확히 분리

• Pending / Approved 상태 시각화

• Issuance Limit 실시간 계산

---

2. 담보 승인 책임 혼선

리스크 설명

• 누가 담보를 승인했는지 불명확

• 승인 기준·시점 기록 누락

감사 시 문제

• “누가 승인했는가?”에 답하지 못함

• 내부 통제 취약 판정 가능

KSC의 방지 설계

• 모든 담보 승인에 승인자·시점·상태 기록

• 승인 이력은 변경 불가 로그로 유지

• 승인 전/후 상태 명확히 구분

---

3. 수량 단위 오해 (가장 빈번)

리스크 설명

• KRW 원 단위

• BNK 최소 단위(6 decimals)

• 프론트 표시 단위 혼동

실제 발생 사례 (PoC)

• 0이 여섯 개 중복 적용

• Burn 후 수량이 두 배로 줄어든 것처럼 보임

KSC의 방지 설계

• SaaS 저장 값은 항상 최소 단위 string

• 프론트는 표시 전용 변환만 수행

• 문서·API·UI에서 단위 명시

---

4. 실행 주체 오해 리스크

리스크 설명

• “SaaS가 발행을 실행한다”는 오해

• 사고 발생 시 책임 소재 혼란

KSC의 방지 설계

• 실행(App Backend)과 기록(SaaS) 완전 분리

• SaaS는 실행 권한 없음

• 실행 결과만 record

---

5. Delta(차이) 오해 리스크

리스크 설명

• Delta ≠ 0 → 즉시 오류로 판단

• 정상적인 승인 대기 상태를 사고로 인식

KSC의 방지 설계

• Delta는 경고(signal)로 정의

• Delta 발생 사유를 화면에서 설명 가능

• 정상/주의/점검 대상 구분

---

운영 리스크를 줄이는 핵심 원칙

KSC의 모든 운영 설계는 다음 원칙을 따릅니다.

---

원칙 1. 실행과 판단을 분리한다

• 실행: 자동화

• 판단: 사람 + 정책

👉 사람이 개입하는 지점은 항상 기록으로 남긴다.

---

원칙 2. “안 되는 상태”를 숨기지 않는다

• 발행 불가 상태

• 승인 대기 상태

• 제어 플래그 OFF 상태

👉 모두 화면에 그대로 노출 (운영자가 우회하지 못하도록)

---

원칙 3. 설명 불가능한 상태를 만들지 않는다

• 모든 숫자는 근거가 있음

• 모든 상태 변화는 로그가 있음

• 모든 판단에는 책임 주체가 있음

---

실무자를 위한 운영 주의사항 (요약)

은행 실무자

• Deposit과 Issuance Limit를 혼동하지 말 것

• 발행 실패 시 먼저 담보 승인 상태 확인

• Delta 발생 시 즉시 오류로 판단하지 말 것

---

신탁사 실무자

• 승인 전/후 상태 차이를 명확히 인지

• 승인 로그가 곧 감사 로그임을 인식

• 인센티브/일반 담보 계정 혼동 주의

---

공통 주의사항

• 수량 단위(6 decimals)는 항상 문서 기준 확인

• 프론트 표시와 실제 저장 값은 다를 수 있음

• “시스템이 이상하다” 판단 전에 상태를 먼저 볼 것

---

이 장의 핵심 메시지

KSC는 사고를 막기 위해 “신뢰를 요구하지 않는다”. 대신 구조로 실수를 막는다.

운영 리스크는 제거할 수는 없지만, 설명 가능하게 만들 수는 있다.

KSC는 그 지점을 목표로 설계된 시스템입니다.