5년간의 핀테크 X Rails 실천에서 배우는 기본에 충실한 운영으로 구축하는 미래 시스템

5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム / ohbarye - Kaigi on Rails 2025

작성자
Kaigi on Rails
발행일
2025년 11월 25일

핵심 요약

  • 1 핀테크 규제 산업에서 5년간 Rails를 활용하여 신뢰성 높은 시스템을 구축하고 운영한 경험과 노하우를 공유합니다.
  • 2 PCI DSS, 자금이동업 등 핀테크 특유의 규제를 준수하기 위한 아키텍처 설계, 개발 및 운영상의 구체적인 접근 방식을 제시합니다.
  • 3 장애 예방, 신속한 탐지, 효율적인 해결을 위한 모니터링, SLI/SLO, 배치 관리, 알림 트리아지, 런북 등 체계적인 운영 전략을 소개합니다.

도입

발표자는 스마트뱅크의 오오바(大葉)로, 5년간 핀테크 분야에서 Rails를 활용하여 결제 및 잔고 관리 시스템을 개발하고 운영해 온 경험을 공유합니다. 본 발표는 규제 산업의 특성상 요구되는 높은 신뢰성과 보안을 달성하기 위한 개발 및 운영상의 노력을 다루며, 이러한 노력이 비즈니스를 가능하게 하는 핵심적인 요소임을 강조합니다. 특히, 가계부 앱 '원뱅크(OneBanc)'와 신용카드 유사 서비스를 운영하며 겪었던 실제 사례를 바탕으로, 핀테크에 국한되지 않고 일반적인 소프트웨어 개발 및 운영에도 적용 가능한 시사점을 제공하고자 합니다.

핀테크 규제 및 품질 특성

핀테크 서비스는 자금이동업, PCI DSS, 국제 브랜드(Visa, Mastercard) 등 엄격한 규제를 준수해야 합니다. 이에 따라 시스템은 거래 데이터의 확실한 보존, 자금 손실 방지, 카드 정보 암호화 및 접근 제한, 높은 가용성, 이상 탐지 및 보고 체계 등을 필수적으로 갖춰야 합니다. 이러한 요구사항은 소프트웨어의 신뢰성(Reliability)과 보안(Security)을 최우선 품질 특성으로 설정하게 합니다.

운영을 고려한 개발상의 노력

  • 아키텍처 설계:
    • PCI DSS 준수 환경을 위해 카드 정보를 다루는 시스템 컴포넌트를 핵심 기능과 분리하여 개별 애플리케이션으로 구현하고 엄격하게 관리합니다.
    • 자금이동업의 반사회 세력 거부 의무를 위해 별도의 반사회 세력 DB 컴포넌트를 구축하여 사용자 검증에 활용합니다.
    • 대부분의 코드는 모놀리식 Rails(Core API)에 집중되어 있으며, 특정 기능만 주변 컴포넌트로 오프로드하는 ‘DH가 내려오는 패턴(DH’s Down the Pattern)’을 채택합니다.
  • 모놀리식 내부 모듈화:
    • 구독, 후불 결제 등 기능별로 네임스페이스를 분리하고, concern과 같은 Rails 기능을 활용하여 클래스 및 객체의 역할을 명확히 정의합니다. 이는 코드의 책임 영역을 명확히 하여 운영 시 문제 발생 시 담당 팀 및 인력 식별에 용이합니다.
  • 기타 개발 기법:
    • 금융 사고 대책: 중복 요청에도 데이터가 한 번만 생성되도록 보장하는 멱등성(Idempotency) 키 헤더를 도입했습니다.
    • 안전한 기능 배포: 이벤트 소싱, 비동기 처리, 피처 플래그(Feature Flags)를 활용하여 프로덕션 환경에 기능을 안전하게 출시합니다.
    • 테스트 전략: 테스트 시간을 12분에서 5분 이내로 단축하여 장애 발생 시 핫픽스(Hotfix) 배포 시간을 줄이고 평균 수리 시간(MTTR) 단축에 기여합니다.
    • 문서화: OpenAPI 문서, YARD 주석 등을 통해 코드베이스에 대한 이해도를 높여 1차 조사 및 문제 해결에 활용합니다.

신뢰성 확보를 위한 운영상의 노력

핀테크 가이드라인은 장애 0건을 요구하지 않으며, 장애 발생을 전제로 한 대비, 신속한 탐지, 빠른 해결 체계를 강조합니다.

  • 예방 (Prevention):
    • 비즈니스 데이터 모니터링: 데이터 불일치(예: 거래는 발생했으나 잔액 미변동) 등 비즈니스 로직상의 이상 징후를 SQL 쿼리 등을 통해 선제적으로 감지합니다.
    • 퍼포먼스 미팅 (パフォミ): New Relic, Sentry, AWS Performance Insights 등 다양한 시스템 메트릭스를 주간 단위로 확인하며 시스템 현황을 공유하고 잠재적 문제를 논의합니다.
    • SLI/SLO 도입: 결제 응답 시간과 같은 핵심 지표에 대한 SLI/SLO를 설정하고, 이를 초과할 경우 성능 튜닝을 진행하여 비즈니스 영향을 최소화합니다.
    • 배치 작업 관리: 모든 배치 작업에 대한 문서화(사용 설명서)를 의무화하고, 최대 예상 처리 시간을 설정(SLO)하여 장기 실행 시 Slack 알림을 통해 신속하게 대응합니다. 또한, 실행 시간 추이를 분석하여 잠재적 문제를 예측합니다.
  • 탐지 (Detection):
    • 알림 트리아지(Triage) 최적화: Sentry와 같은 버그 트래커 도구에서 발생하는 과도한 알림을 줄이고, 특정 모듈의 에러를 해당 팀에 자동 할당하여 필요한 알림만 즉시 대응할 수 있는 환경을 구축합니다. 소유권이 불분명한 에러에 대해서는 적극적인 전사적 공유를 통해 해결합니다.
  • 해결 (Resolution):
    • 장애 대응 플로우(Flow) 정비: PagerDuty의 인시던트 응답 문서를 참고하여 장애 심각도 판단 기준 및 대응 절차를 수립하고, 금융청 보고 등의 규제 준수 사항을 플로우차트로 명확히 합니다.
    • 역할 분담: 인시던트 커맨더(Incident Commander), 커뮤니케이션 담당자, 조사 담당자 등 역할을 명확히 분담하여 효율적인 장애 대응을 가능하게 하고, 일상 업무의 중단을 최소화합니다.
    • 런북(Runbook) 정비: 개별 사례 및 운영 절차에 대한 매뉴얼인 런북을 작성하여 암묵지를 형식지로 전환합니다. 이는 신규 인력이나 해당 영역에 익숙하지 않은 사람도 장애 대응을 가능하게 하며, 반복적인 수동 작업의 자동화 우선순위를 결정하는 데 활용됩니다. Slack 이모지 리액션을 통한 런북 추천 기능으로 활용도를 높입니다.

결론

발표자는 핀테크라는 규제 산업에서 시작된 이러한 개발 및 운영 노하우가 결국 '우리의 비즈니스를 가능하게 하는 것이 무엇인가?'라는 본질적인 질문에서 출발하며, 이는 일반적인 소프트웨어 시스템에도 적용될 수 있는 보편적인 원칙임을 강조합니다. 시스템의 규모와 기능이 지속적으로 증가하는 상황에서도 장애 건수가 감소 추세를 보이는 것은 이러한 개발 및 운영 노력의 결과이며, 높은 신뢰성을 갖춘 시스템을 구축하는 데 기여했음을 시사합니다. 자신들의 여정이 아직 진행 중임을 밝히며, 다른 개발자들도 각자의 비즈니스에 맞는 신뢰성의 정의와 측정 지표를 고민하고, 기본적인 노력을 꾸준히 쌓아갈 것을 제안합니다.

댓글 0

로그인이 필요합니다

댓글을 작성하거나 대화에 참여하려면 로그인이 필요합니다.

로그인 하러 가기

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!