운영 중인 기관용 트레이딩 플랫폼을 망가뜨리지 않고 확장하는 방법

규제 대상인 핀테크 (fintech) 시스템에서 가장 위험한 행동은 무엇일까요? 실제로 이해하기 전에 이해했다고 가정하는 것입니다.

개발의 제1원칙: 그 어떤 것도 가정하지 마라.

AFSL 라이선스를 보유하고 퍼페추얼 (perpetuals), 현물 (spot), 옵션 (options), 그리고 FX를 처리하는 운영 중인 기관용 트레이딩 플랫폼을 단 한 번의 회귀 (regression) 없이, 매우 면밀한 감시 속에서 프로덕션 (production) 환경에 확장했을 때의 과정은 다음과 같았습니다.

우리는 이미 프로덕션 중인 라이브 시스템에 합류했습니다
이것은 백지 상태에서 시작하는 스타트업이 아니었습니다. 플랫폼은 이미 라이브 상태였으며, 실제 사용자, 실제 거래, 실제 규제 의무가 존재했습니다. 핵심 시스템은 C#/.NET 및 PostgreSQL로 구동되었으며, KYC/AML 및 온보딩 (onboarding)을 처리하는 별도의 컴플라이언스 (compliance) 포털이 있었습니다.

고객사는 세 가지가 필요했습니다: 멀티 채널 알림 시스템, 확장된 API 기능, 그리고 추가 확장을 위한 독립적인 보안 평가였습니다.

그들에게 필요하지 않았던 것은 우리가 만약 직접 만들었다면 어떻게 다르게 만들었을지에 대한 의견을 가지고 나타나는 것이었습니다. 우리의 임무는 시스템을 재구상하는 것이 아니라 확장하는 것이었습니다.

우리는 코드를 작성하기 전에 시스템을 읽는 것부터 시작했습니다
우리가 출시하는 모든 새로운 모듈은 기존에 존재하는 것과 아키텍처 (architecturally) 측면에서 구별할 수 없을 정도여야 했습니다. 단순히 기능적인 수준을 넘어, 구별 불가능해야 했습니다. 우리는 명명 규칙 (naming conventions)을 맞추고, 확립된 패턴을 따랐으며, 어떤 것이 프로덕션에 반영되기 전에 제안(propose) → 승인(approve) → 구현(implement)이라는 엄격한 워크플로우 (workflow)를 준수했습니다.

따라서 누군가 티켓을 열기 전에, 우리는 시스템을 읽었습니다. 우리는 Claude를 포함한 AI 도구를 사용하여 아키텍처 패턴을 매핑하고, 컨벤션 (conventions)을 식별하며, 시스템이 어떻게 진화하도록 설계되었는지에 대한 멘탈 모델 (mental model)을 구축했습니다. 우리는 모든 가정을 문서화했습니다. 구현 전에 모든 제안을 검증했습니다. 우리는 단순히 차이점(diff)만 전달하는 것이 아니라, 설계 근거 (design rationale)를 포함하여 모든 PR (Pull Request)을 제출했습니다.

💡 이것은 대부분의 팀이 납기 압박 속에서 행동하는 방식이 아닙니다. 하지만 당신이 직접 만들지 않은 프로덕션 시스템을 확장할 때 작동하는 유일한 접근 방식입니다.

프로덕션을 안정적으로 유지했던 3가지 요소

구조로서의 테스트 우선 (Test-first as structure). 우리는 100% 유닛 테스트 (Unit Test) 커버리지를 강제했으며, 이는 기능을 완료되었다고 간주하기 전에 모든 실행 경로 (Execution path)를 이해하도록 만들었습니다. 우리는 AI 도구를 사용하여 테스트 케이스를 생성하고 커버되지 않은 경로를 찾아냈습니다. 그 부산물은 단순한 커버리지가 아니라, 시스템의 엣지 케이스 (Edge cases)에 대한 진정한 이해였습니다.

모든 PR에 포함된 문서화 (Documentation in every PR). 무엇을 변경했는지가 아니라, '왜' 변경했는지를 기록했습니다. 설계 결정 (Design decision), 대안, 그리고 트레이드오프 (Tradeoffs)를 포함했습니다. 팀이 성장하고 엔지니어가 교체되는 시스템에서, 이것은 다음 사람이 우리의 실수를 반복하지 않도록 막아주는 장치입니다.

생성이 아닌 이해를 위한 AI (AI for comprehension, not generation). 우리는 대규모 코드베이스를 읽기 위해 AI를 활용했습니다. 패턴 인식, 일관성 검사, 그리고 변경 사항이 기존 동작과 비자명한 방식으로 상호작용할 수 있는 지점을 포착하는 데 사용했습니다. 그 결과 더 나은 제안을 얻을 수 있었고 예상치 못한 상황은 줄어들었습니다.

💡 우리의 목표는 빠르게 움직이는 것이 아니라, 올바르게 움직이는 것이었습니다. 결과적으로 그것이 더 빠르다는 것이 밝혀졌지만, 즉각적으로 나타나지는 않았습니다.

컴플라이언스 포털에서 31개의 보안 취약점이 발견되었습니다
컴플라이언스 (Compliance) 포털은 고장 난 상태가 아니었습니다. KYC/AML, 온보딩 (Onboarding), 그리고 문서 관리를 문제없이 처리하고 있었습니다. 외부에서 보기에는 경고를 보낼 만한 것이 아무것도 없었습니다.

하지만 우리는 '정상 작동하는 것'과 '안전한 것'이 같지 않다는 것을 알고 있었습니다. 평가되지 않은 컴플라이언스 포털 위에서 기관 비즈니스를 확장하는 것은 단순한 기술적 리스크가 아니라 전략적 리스크입니다. 그래서 우리는 고객이 기관 고객 기반을 더 확장하기 전에 독립적인 평가를 실시했습니다.

우리는 다양한 심각도 수준에 걸쳐 31개의 발견 사항 (Findings)을 찾아냈습니다. 그중 몇 가지는 치명적이었습니다. 개인정보 보호, 액세스 제어 (Access control), 그리고 금융 데이터 처리와 같은 영역이었는데, 이는 실패했을 때 단순한 지원 티켓(Support ticket)을 생성하는 수준이 아니라 규제 사건 (Regulatory event)을 촉발하는 바로 그 영역들이었습니다.

우리는 고객이 확장을 진행하기 전에 이를 해결할 수 있도록 구조화된 교정 로드맵 (Remediation roadmap)을 전달했습니다. 그것이 핵심이었습니다. 문제를 지적하는 것이 아니라, 그들에게 명확한 전진 경로를 제공하는 것이었습니다.

💡 "잘 작동하고 있다"는 것은 보안 태세 (Security posture)가 아닙니다. 그것은 단지 실패가 발생하기 전의 모습일 뿐입니다.

이번 프로젝트가 성공적이었던 이유
성공의 요인은 크게 세 가지로 설명할 수 있습니다.

개선하기 전에 이해하라. 시스템이 오늘날 우리가 설계할 방식이 아니라, 실제로 어떻게 작동하고 있는지에 대한 진정한 멘탈 모델 (Mental model)을 구축하는 데 보낸 시간은 나중에 발생할 값비싼 실수를 방지해 준 시간이었습니다. 우리는 일정이 촉박할 때조차 그 학습 단계를 보호했습니다.

서로 다른 스택, 서로 다른 리스크 프로필 (Risk profiles). 핵심 트레이딩 플랫폼과 컴플라이언스 포털 (Compliance portal)은 같은 종류의 시스템이 아닙니다. 우리는 단일한 리스크 표준을 보편적으로 적용하지 않았습니다. 어떤 데이터에 접근하느냐에 따라 한 맥락에서의 중간 수준 (Medium-severity) 발견 사항이 다른 맥락에서는 치명적 (Critical)일 수 있습니다.

비판적인 피드백은 데이터다. 핀테크 (Fintech) 검토는 설계 단계부터 까다롭습니다. 우리는 증거와 일관된 판단력으로 대응했으며, 단순한 벤더 (Vendor)가 되는 것을 멈췄습니다. 우리는 그들이 민감한 사항을 믿고 맡길 수 있는 파트너가 되었습니다.
규제 대상인 핀테크 산업에서 신뢰는 곧 제품입니다. 규율은 그 신뢰를 얻는 방법일 뿐입니다.

**운영 중인 규제 대상 시스템을 물려받으셨나요?
👉 이곳에서는 "빠르게 움직이기 (Move fast)\