fos-blog/study
01 / 홈02 / 카테고리
01 / 홈02 / 카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • langgraph 페이지로 이동
    • agents.md
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code를 5주 더 쓴 결과 — 스킬·CLAUDE.md를 키워가는 방식
    • Claude Code를 11일 동안 쓴 결과 — 데이터로 본 나의 사용 패턴
    • Claude Code 멀티 에이전트 — Teams
    • AI 에이전트와 디자인의 새 컨벤션 — DESIGN.md, Google Stitch, Claude Design
    • 하네스 엔지니어링 실전 — 4인 에이전트 팀으로 코딩 파이프라인 구축하기
    • 하네스 엔지니어링 — 오래 실행되는 AI 에이전트를 위한 설계
    • 멀티모달 LLM (Multimodal Large Language Model)
    • AI 에이전트와 함께 MVP 만들기 — dooray-cli 사례
  • ai 페이지로 이동
    • agent 페이지로 이동
  • algorithm 페이지로 이동
    • live-coding 페이지로 이동
    • 분산 계산을 위한 알고리즘
  • architecture 페이지로 이동
    • [초안] 시니어 백엔드를 위한 API 설계 실전 스터디 팩 — REST · 멱등성 · 페이지네이션 · 버전 전략
    • [초안] API Versioning과 Backward Compatibility: 시니어 백엔드 관점 정리
    • 캐시 설계 전략 총정리
    • [초안] CJ푸드빌 커머스/F&B 도메인 설계 면접 대비 — 슬롯 경험을 주문·결제·쿠폰·매장 상태 설계로 번역하기
    • [초안] 커머스 Spring 서비스에 Clean/Hexagonal Architecture를 실용적으로 적용하기
    • [초안] 커머스 주문 상태와 데이터 정합성 기본기 — CJ푸드빌 면접 대비
    • [초안] 쿠폰/프로모션 동시성과 정합성 기본기 — 선착순·중복 사용 방지·발급/사용/복구
    • [초안] DDD와 도메인 모델링: 시니어 백엔드 관점의 전술/전략 패턴 실전 가이드
    • [초안] Decorator & Chain of Responsibility — 행동을 체인으로 조립하는 두 가지 방식
    • 디자인 패턴
    • [초안] 분산 아키텍처 완전 정복: Java 백엔드 시니어 인터뷰 대비 실전 가이드
    • [초안] 분산 트랜잭션과 Outbox 패턴 — 왜 2PC를 피하고 어떻게 대신할 것인가
    • 분산 트랜잭션
    • [초안] e-Commerce 주문·결제 도메인 모델링: 상태머신, 멱등성, Outbox/Saga 실전 정리
    • [초안] F&B 쿠폰·프로모션·멤버십·포인트 설계
    • [초안] F&B · e-Commerce 디지털 채널 도메인 한 장 정리 — CJ푸드빌 디지털 채널 백엔드 면접 대비
    • [초안] F&B 주문/매장/픽업 상태머신 설계 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] F&B 이커머스 결제·환불·정산 운영 가이드
    • [초안] Hexagonal / Clean Architecture를 Spring 백엔드에 적용하기
    • [초안] 대규모 커머스 트래픽 처리 패턴 — 1,600만 고객과 올영세일을 버티는 설계
    • [초안] 레거시 JSP/jQuery 화면과 신규 API가 공존하는 백엔드 운영 전략
    • [초안] MSA 서비스 간 통신: Redis [Cache-Aside](../database/redis/cache-aside.md) × Kafka 이벤트 하이브리드 설계
    • [초안] Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식
    • [초안] Outbox / Inbox Pattern 심화 — 분산 메시징의 정합성 문제를 DB 트랜잭션으로 풀어내기
    • [초안] 결제 도메인 멱등성과 트랜잭션 재시도 기본기
    • [초안] 시니어 백엔드를 위한 Resilience 패턴 실전 가이드 — Timeout, Retry, Circuit Breaker, Bulkhead, Backpressure
    • [초안] REST API 버저닝과 모바일 앱 하위 호환성 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] Strategy Pattern — 분기문을 없애는 설계, 시니어 백엔드 인터뷰 핵심 패턴
    • [초안] 시니어 백엔드를 위한 시스템 설계 입문 스터디 팩
    • [초안] 템플릿 메서드 패턴 - 백엔드 처리 골격을 강제하는 가장 오래되고 가장 위험한 패턴
    • [초안] 대규모 트래픽 중 무중단 마이그레이션 — Feature Flag + Shadow Mode 실전
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야 할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • [초안] JPA N+1과 커머스 조회 모델: 주문/메뉴/쿠폰 도메인에서 살아남기
    • [초안] MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
    • [초안] MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • observability 페이지로 이동
    • [초안] 커머스/F&B 채널 장애 첫 5분과 관측성 기본기
    • Envoy Proxy
    • [초안] F&B / e-Commerce 운영 장애 대응과 모니터링 — 백엔드 관점 정리
    • Graceful Shutdown
  • finance 페이지로 이동
    • industry-cycle 페이지로 이동
    • investing 페이지로 이동
    • stock-notes 페이지로 이동
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • [초안] AI 서비스 팀 경험 기반 시니어 백엔드 면접 질문 뱅크 — Spring Batch RAG / gRPC graceful shutdown / 전략 패턴 / 12일 AI 웹툰 MVP
    • [초안] CJ푸드빌 디지털 채널 Back-end 커피챗 준비
    • [초안] CJ푸드빌 디지털 채널 — Part 2: ivips.co.kr SRE 외부 진단
    • [초안] CJ푸드빌 디지털 채널 — Part 3: 5/18 사전 커피챗 D-5 준비
    • [초안] CJ푸드빌 디지털 채널 Back-end 개발자 직무 분석
    • [초안] CJ푸드빌 디지털 채널 Back-end 면접 답변집 — 슬롯 도메인 경험을 커머스/F&B 설계로 번역하기
    • [초안] F&B / e-Commerce 운영 모니터링과 장애 대응 인터뷰 정리
    • Observability — 면접 답변 프레임
    • [초안] 시니어 Java 백엔드 면접 마스터 플레이북 — 김병태
    • [초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업
  • java 페이지로 이동
    • concurrency 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • [초안] Java 동시성 락 정리 — 커머스 메뉴/프로모션 정책 캐시 갱신 관점
    • [초안] JVM 튜닝 실전: 메모리 구조부터 Virtual Threads, GC 튜닝, 프로파일링까지
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node 백엔드 운영 패턴 — Streams 백프레셔, pipe/pipeline, 멱등성 vs 분산 락
    • Node.js
    • npm vs pnpm — 어떤 기준으로 선택했나
    • `setImmediate()`
  • kafka 페이지로 이동
    • [초안] Kafka 기본 개념 — 토픽, 파티션, 오프셋, 복제
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • [초안] Kafka 실전 설계: 파티션 전략, 컨슈머 그룹, 전달 보장, 재시도, 순서 보장 트레이드오프
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • rabbitmq 페이지로 이동
    • [초안] RabbitMQ Basics — 실전 백엔드 관점에서 정리하는 메시지 브로커 기본기
    • [초안] RabbitMQ vs Kafka — 백엔드 메시징 선택 기준과 실전 운영 관점
  • security 페이지로 이동
    • [초안] 시니어 백엔드를 위한 보안 / 인증 스터디 팩 — Spring Security, JWT, OAuth2, OWASP Top 10
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
  • testing 페이지로 이동
    • [초안] 시니어 Java 백엔드를 위한 테스트 전략 완전 정리 — 피라미드부터 TestContainers, 마이크로벤치, Contract까지
  • travel 페이지로 이동
    • 오사카 3박 4일 일정표: 우메다 쇼핑, USJ, 난바·도톤보리, 오사카성
  • web 페이지로 이동
    • [초안] HTTP / Cookie / Session / Token 인증 기본기 — 레거시 JSP와 모바일 API가 공존하는 백엔드 관점
FOS-BLOG · FOOTERall systems normal·v0.1 · 2026.04.27·seoul, kr
Ffos-blog/study

개발 학습 기록을 정리하는 블로그입니다. 공부하면서 기록하고, 기록하면서 다시 배웁니다.

visitors
01site
  • Home↗
  • Posts↗
  • Categories↗
  • About↗
02policy
  • 소개/about
  • 개인정보처리방침/privacy
  • 연락처/contact
03categories
  • AI↗
  • Algorithm↗
  • DB↗
  • DevOps↗
  • Java/Spring↗
  • JS/TS↗
  • React↗
  • Next.js↗
  • System↗
04connect
  • GitHub@jon890↗
  • Source repositoryjon890/fos-study↗
  • RSS feed/rss.xml↗
  • Newsletter매주 1 회 · 한 편의 글→
© 2026 FOS Study. All posts MIT-licensed.
built with·Next.js·Tailwind v4·Geist·Pretendard·oklch
fos-blog/task/블록체인 입출금 시스템 구현기
system

블록체인 입출금 시스템 구현기

진행 기간: 2022.09 2022.10 소속: 더퓨쳐컴퍼니 --- 게임 내 블록체인 자산의 입금/출금 처리 시스템이다. 서비스의 주력 코인은 Solana(SOL) 이며, BTC·ETH·USDT도 함께 지원했다. 사용자가 외부 지갑에서 게임 계정으로 코인을 보내거나, 반대로 게임 자산을 외부로 출금하는 흐름 전체를 NestJS 데몬 서비스가 처리한다. 입금...

2026.03.23·6 min read·58 views

진행 기간: 2022.09 ~ 2022.10 소속: 더퓨쳐컴퍼니


무엇을 만들었나

게임 내 블록체인 자산의 입금/출금 처리 시스템이다. 서비스의 주력 코인은 Solana(SOL) 이며, BTC·ETH·USDT도 함께 지원했다.

사용자가 외부 지갑에서 게임 계정으로 코인을 보내거나, 반대로 게임 자산을 외부로 출금하는 흐름 전체를 NestJS 데몬 서비스가 처리한다. 입금은 블록체인을 주기적으로 폴링해서 감지하고, 출금은 요청을 DB에 쌓아두고 배치로 처리하는 방식이다.


핵심 흐름

plaintext
유저 가입
  └── 유저 전용 입금 주소 발급 (코인별 1개)
 
입금 흐름
  └── 데몬: 주기적으로 블록체인 API 폴링 (Solana → Alchemy, BTC/ETH → CryptoAPIs)
        └── 플랫폼 지갑 또는 유저 주소의 트랜잭션 조회
              └── 수신 주소 → 유저 매핑
                    └── 이미 처리된 시그니처(txId)인지 확인 (멱등성)
                          └── 신규이면 유저 잔액 증가 + 입금 이력 저장
 
출금 흐름
  └── 유저 출금 요청 → Pending 상태로 DB 저장
        └── 데몬: 주기적으로 Pending 출금 조회
              └── 블록체인 API로 실제 전송
                    └── txId(signature) 저장, 상태 Complete/Failed 갱신

1. 유저별 전용 입금 주소 발급

유저마다 코인별 전용 입금 주소를 하나씩 발급한다. 공용 주소를 쓰면 누가 보냈는지 구분할 수 없기 때문이다.

plaintext
유저 A → SOL 입금 주소: AbCD...XyZ  /  BTC 입금 주소: bc1q...
유저 B → SOL 입금 주소: EfGH...WvU  /  BTC 입금 주소: bc1p...

Solana는 각 유저에게 독립된 keypair에서 파생된 주소를 발급한다. BTC·ETH는 HD Wallet(m/44'/0'/0'/0/N) 경로에서 인덱스 N을 늘려가며 주소를 파생시킨다. 어느 방식이든 플랫폼이 발급된 주소와 유저를 DB에서 매핑해두는 것이 핵심이다.

typescript
interface UserWallet {
  userId: string;
  symbol: 'SOL' | 'BTC' | 'ETH' | 'USDT';
  depositAddress: string;  // 유저 전용 입금 주소
  balance: Decimal;
}

2. Solana 입금 감지 — Alchemy로 트랜잭션 추적

Solana 트랜잭션 추적에는 Alchemy를 사용했다. Alchemy는 Solana RPC 노드를 직접 운영하지 않아도 REST/WebSocket API로 블록체인 데이터를 조회할 수 있는 서비스다.

주소별 트랜잭션 시그니처 조회

Solana에서 트랜잭션을 추적하는 기본 패턴은 getSignaturesForAddress다. 특정 주소에 관련된 트랜잭션 시그니처 목록을 최신순으로 반환한다.

typescript
// Alchemy Solana API: 주소에 연관된 트랜잭션 시그니처 목록 조회
const response = await alchemy.core.getSignaturesForAddress(
  depositAddress,
  { limit: 50 }
);
// response: [{ signature, slot, blockTime, confirmationStatus, ... }, ...]

시그니처 목록을 받은 뒤, 각 시그니처로 트랜잭션 상세 내용을 조회한다.

typescript
const tx = await alchemy.core.getTransaction(signature);

입금액 계산 — 잔액 변화로 판단

SOL 입금은 트랜잭션의 preBalances / postBalances 차이로 계산한다. Solana 트랜잭션에는 변경된 모든 계정의 전후 잔액이 포함되어 있어서, 특정 주소의 잔액이 얼마나 늘었는지 직접 계산할 수 있다.

typescript
function extractSolDeposit(tx: SolanaTransaction, depositAddress: string): Decimal | null {
  const accountIndex = tx.transaction.message.accountKeys
    .findIndex(key => key.toString() === depositAddress);
 
  if (accountIndex === -1) return null;
 
  const pre = tx.meta.preBalances[accountIndex];   // lamports
  const post = tx.meta.postBalances[accountIndex]; // lamports
  const diff = post - pre;
 
  if (diff <= 0) return null;  // 입금이 아닌 경우
  return new Decimal(diff).dividedBy(1e9);  // lamports → SOL
}

SPL 토큰(USDT-SPL 등) 처리

SOL 네이티브 코인이 아닌 SPL 토큰(Solana의 ERC-20 격)은 preTokenBalances / postTokenBalances에서 읽는다.

typescript
function extractSplDeposit(tx: SolanaTransaction, depositAddress: string, mint: string) {
  const pre = tx.meta.preTokenBalances
    .find(b => b.owner === depositAddress && b.mint === mint);
  const post = tx.meta.postTokenBalances
    .find(b => b.owner === depositAddress && b.mint === mint);
 
  const preAmount = new Decimal(pre?.uiTokenAmount.uiAmountString ?? '0');
  const postAmount = new Decimal(post?.uiTokenAmount.uiAmountString ?? '0');
  const diff = postAmount.minus(preAmount);
 
  return diff.greaterThan(0) ? diff : null;
}

3. 데몬 서비스 — 코인별 폴링 스케줄러

NestJS @Cron으로 코인마다 독립된 스케줄러를 돌린다. 인터벌을 다르게 설정해 API 요청이 동시에 몰리지 않도록 한다.

typescript
@Injectable()
export class DepositScheduler {
  @Cron('0 */5 * * * *')   // 5분마다 — 메인 코인
  async detectSolDeposits() { ... }
 
  @Cron('0 */7 * * * *')   // 7분마다
  async detectBitcoinDeposits() { ... }
 
  @Cron('0 */8 * * * *')   // 8분마다
  async detectEthereumDeposits() { ... }
 
  @Cron('0 */9 * * * *')   // 9분마다
  async detectUsdtDeposits() { ... }
}

각 스케줄러는 유저 지갑 주소 목록을 DB에서 읽어, 각 주소에 대해 최신 트랜잭션을 조회하고 입금 여부를 판단한다.

typescript
async processAllSolDeposits() {
  const wallets = await this.userWalletRepo.findAllBySymbol('SOL');
 
  for (const wallet of wallets) {
    const signatures = await alchemy.core.getSignaturesForAddress(
      wallet.depositAddress,
      { limit: 50 }
    );
 
    for (const { signature } of signatures) {
      await this.handleSolDeposit(wallet, signature);
    }
  }
}

4. 멱등성 보장 — 같은 트랜잭션을 두 번 처리하지 않는다

폴링 방식의 가장 큰 위험은 같은 트랜잭션을 중복 처리하는 것이다. Solana의 트랜잭션 식별자는 시그니처(signature) 다. 이 값을 이미 처리된 입금 이력에서 확인해 중복을 막는다.

typescript
async handleSolDeposit(wallet: UserWallet, signature: string): Promise<void> {
  // 이미 처리된 시그니처인지 확인
  const exists = await this.depositRepo.existsBySignatureAndWallet(
    signature, wallet.id
  );
  if (exists) return;
 
  const tx = await alchemy.core.getTransaction(signature);
  if (!tx || tx.meta?.err) return;  // 실패한 트랜잭션 스킵
 
  const amount = extractSolDeposit(tx, wallet.depositAddress);
  if (!amount) return;  // 이 주소로 들어온 금액이 없으면 스킵
 
  // 잔액 증가 + 입금 이력 저장 (DB 트랜잭션으로 묶음)
  await this.dataSource.transaction(async manager => {
    wallet.balance = wallet.balance.plus(amount);
    await manager.save(wallet);
    await manager.save(new Deposit({ wallet, amount, signature, txTimestamp: tx.blockTime }));
  });
}

Solana 시그니처는 전 세계적으로 유일하기 때문에, signature + walletId 조합으로 충분한 멱등성 키가 된다.


5. 출금 처리

출금은 요청과 실행을 분리한다. 유저가 출금 요청을 하면 즉시 블록체인에 전송하지 않고 Pending 상태로 DB에 저장한다. 데몬이 주기적으로 Pending 건을 가져와 실제 전송을 처리한다.

plaintext
출금 요청 API
  └── 잔액 차감 + Withdrawal(status=Pending) 저장
 
출금 데몬 (@Cron 30분마다)
  └── status=Pending인 Withdrawal 조회
        └── Alchemy (SOL) / CryptoAPIs (BTC·ETH)로 전송 요청
              ├── 성공: signature(txId) 저장, status=Complete
              └── 실패: status=Failed, 잔액 환불

요청과 실행을 분리하면 블록체인 API 장애 시 요청이 유실되지 않고, 실패한 건을 재처리하거나 관리자가 개입할 수 있다.


배운 것

Solana 트랜잭션 구조는 EVM 계열과 다르다

ETH 트랜잭션은 from → to의 단순한 구조다. Solana는 하나의 트랜잭션이 여러 계정의 잔액을 동시에 변경할 수 있고, 토큰 전송은 별도의 Token Program 명령으로 처리된다. 처음에는 어디서 입금액을 읽어야 할지 파악하는 데 시간이 걸렸고, preBalances / postBalances 차이를 계산하는 방식으로 해결했다.

Alchemy 덕분에 노드 운영 없이 Solana 데이터를 다룰 수 있었다

Solana 노드를 직접 운영하면 고성능 서버와 고속 SSD가 필요하고 운영 복잡도가 높다. Alchemy의 Solana API를 사용하면 getSignaturesForAddress, getTransaction 같은 RPC 메서드를 REST로 호출할 수 있어서 인프라 부담 없이 개발에 집중할 수 있었다.

블록체인 입금은 "이벤트 수신"이 아니라 "폴링"으로 구현했다

웹훅으로 트랜잭션 알림을 받는 방식도 있지만, 웹훅은 전달 실패 시 유실 위험이 있다. 폴링 방식은 느리지만 데몬이 살아있는 한 반드시 처리된다는 신뢰성이 있다. 입금 누락이 서비스 신뢰에 직결되는 도메인에서는 이 트레이드오프가 중요하다.

멱등성이 가장 중요한 설계 원칙이다

폴링 간격마다 같은 트랜잭션이 반복 조회된다. Solana 시그니처를 고유 키로 사용해 중복 처리를 막지 않으면 유저 잔액이 무한정 늘어날 수 있다. 금융 도메인에서 멱등성은 선택이 아닌 필수다.

요청과 실행을 분리하면 장애에 강해진다

출금을 즉시 처리하지 않고 DB에 Pending 상태로 저장하면, 블록체인 API 장애나 네트워크 오류 시 요청이 유실되지 않는다. 재처리, 관리자 개입, 감사 로그 모두 이 구조에서 자연스럽게 따라온다.


기술 스택

NestJS TypeScript TypeORM PostgreSQL Alchemy (Solana RPC) CryptoAPIs (BTC·ETH) @nestjs/schedule

on this page
  • 01무엇을 만들었나
  • 02핵심 흐름
  • 031. 유저별 전용 입금 주소 발급
  • 042. Solana 입금 감지 — Alchemy로 트랜잭션 추적
  • 주소별 트랜잭션 시그니처 조회
  • 입금액 계산 — 잔액 변화로 판단
  • SPL 토큰(USDT-SPL 등) 처리
  • 053. 데몬 서비스 — 코인별 폴링 스케줄러
  • 064. 멱등성 보장 — 같은 트랜잭션을 두 번 처리하지 않는다
  • 075. 출금 처리
  • 08배운 것
  • Solana 트랜잭션 구조는 EVM 계열과 다르다
  • Alchemy 덕분에 노드 운영 없이 Solana 데이터를 다룰 수 있었다
  • 블록체인 입금은 "이벤트 수신"이 아니라 "폴링"으로 구현했다
  • 멱등성이 가장 중요한 설계 원칙이다
  • 요청과 실행을 분리하면 장애에 강해진다
  • 09기술 스택

댓글 (0)