배경 및 목표
① 레거시 시스템의 한계: 트랜잭션 생성(Maker) → 서명(Signer) → 온체인 전송(Runner) 구조에서, 가스비나 잔고 부족 등 특정 예외 발생 시 SQS에 실패 메시지가 순서 없이 적체됨. 이로 인해 블록체인 네트워크의 핵심 제약인 순차적 논스(Nonce) 처리가 마비되어 전체 파이프라인이 중단되는 블로킹 장애 발생.
② 예외 처리 누락: RPC 노드의 신규 에러 타입(재시도로 해결 가능한 일시적 에러) 누락으로 Unhandled Exception이 발생하고, 비효율적인 재시도 루프가 형성됨.
→ 각 마이크로서비스에 명확한 단일 책임(SRP) 부여, 순환 참조(Cycle) 제거, 오프체인 논스 및 가스비 관리 아키텍처 전면 개편을 통해 장애 상황에서도 끊김 없는 고가용성 온체인 전송 시스템 구축.
역할
시스템 구조 설계 참여 및 주도적 개발
주요 업무 및 성과
① 레거시 파이프라인 리팩터링
- Maker · 논스 정합성과 중복 방지: DynamoDB를 도입하고 지갑 주소(PK)와 Network#Nonce(SK)로 구성된 글로벌 보조 인덱스(GSI) 설계. Conditional Check와 AWS Lambda 동시성 제한을 결합하여 분산 환경에서의 논스 충돌을 원천 방지하는 멱등성 아키텍처 수립.
- Signer · 키 격리와 선제적 가스 대응: Private Key 관리 모듈을 Signer 내부에 격리하고, 외부 API 노출 없이 SQS 통신으로만 동작하도록 설계. 트랜잭션 펜딩(Pending)을 방지하기 위해 EIP-1559 규격에 맞춰 여러 단계의 가스 레벨 서명을 미리 생성하여 Runner로 위임.
- Runner · 상태 머신과 가스비 자동 가속: Prisma/PostgreSQL 기반 상태 머신(REQUESTED ➔ PUSHED ➔ MINED ➔ CONFIRMED)을 구축하고, Redis 분산 락으로 멀티 인스턴스 환경의 데이터 경합 방지. 가스비 상승 시 Signer가 미리 서명해 둔 높은 가스비 트랜잭션으로 자동 오버라이딩(Replacement)하여 재전송.
② 노드 에러 핸들링 고도화 및 폴백(Fallback) 전략 수립
- RPC 노드 변화로 발생하는 신규 에러 타입을 일시적 장애(재시도 가능)와 영구적 장애(잔고 부족 등)로 분류하는 예외 처리 레이어 구축. ALREADY_KNOWN·INSUFFICIENT_FUNDS 등 노드 에러를 세분화해 대응하고, 5분간의 알림 중복 방지 로직을 결합한 Google Hangouts 장애 전파 시스템도 함께 구축.
③ 아키텍처 신뢰성 검증을 위한 벤치마크 및 스트레스 테스트 주도
- RDB vs DynamoDB 비교 실험: 데이터베이스 전환 영향도를 파악하기 위해 두 스토어 간의 자원 사용량 및 트랜잭션 처리 속도 비교 분석.
- 인프라 확장성(Scale-out) 검증: Runner 인스턴스를 1개에서 3개까지 늘려가며 자원 분배율을 트래킹해, CPU 사용량이 분산되고 메모리 점유율이 감소하는 선형적 스케일 아웃 구조 검증.
결과
① 인프라 가용성 극대화: 특정 트랜잭션 실패가 전체 파이프라인 마비로 이어지던 단일 장애점(SPOF)을 제거하고, 장애 상황에서도 순차 전송 무결성을 보장하는 아키텍처 달성.
② 유지보수 비용 감소: Maker - Signer - Runner 간의 순환 참조와 결합도를 제거하여, 신규 비즈니스 트랜잭션 타입이 추가되더라도 Runner 코드 수정 없이 확장 가능.
③ 대량 트랜잭션 고속 처리: 500개의 대량 트랜잭션 부하 상황에서 요청(Requested) 후 평균 2~3분 이내에 온체인 컨펌(Confirmed) 완료, 작업 밀림 없이 총 52개 블록 내에 모든 트랜잭션을 안착시킴. RDB 대비 DynamoDB 환경의 속도 차이는 미미했고, 피크 타임 기준 초당 최대 135 트랜잭션의 처리량을 소화.
회고
이번 프로젝트는 기존 분산 파이프라인의 구조적 한계를 분석하고 완전히 재설계한 경험이었다. SQS 메시지 큐의 한계를 진단하고 DynamoDB GSI(글로벌 보조 인덱스)를 직접 설계·도입해 보며 NoSQL 데이터 모델링 역량을 기를 수 있었고, 대량의 트랜잭션 부하를 시뮬레이션하는 스트레스 테스트를 주도하며 시스템 가용성을 정량적으로 확인하는 안목도 넓혔다.
어려웠던 점
문서화 없이 복잡하게 얽힌 남이 작성한 코드를 파악해야 했다.
→ 코드만 읽기보다 실제 테스트를 구동하고 분산 노드의 로그를 추적하며 데이터의 실시간 흐름을 하나씩 도식화해 나갔고, 이 과정을 통해 구조적 문제점을 스스로 찾아내 아키텍처 개편을 이끌어낼 수 있었다.