오르자 모의투자
앱인토스 화면도 보기
01체결 워커 분리
조회 주기를 줄이자 운영 비용이 늘어났습니다.
지정가 주문과 강제 청산은 사용자가 접속하지 않아도 가격 조건을 계속 확인해야 했습니다.초기에는 주문 API를 실행하던 Vercel 환경에서 이 작업도 처리하도록, Cron과 폴링으로 시세와 대기 주문을 주기적으로 조회했습니다.
하지만 조회 사이에 가격이 바뀌면 다음 실행까지 체결 조건을 확인할 수 없었습니다.이 간격을 줄이려고 더 자주 조회하자, 같은 주문과 포지션을 반복해서 읽으며 Firebase·Vercel 사용량과 비용도 늘어났습니다.
호출 간격만 조정해서는 반복 조회 자체를 줄일 수 없다고 판단했습니다.시세를 계속 받아야 하는 감시 작업을 Railway의 상시 실행 워커로 옮기고, 가격 변화가 들어올 때 체결 후보를 확인하도록 바꿨습니다.
변경 전
- 주기 실행
- 감시 대상 조회
- 가격 조건 확인
변경 후
- 시세 수신
- 메모리에서 후보 탐색
- 상태 재검증·체결
워커는 주문·포지션 인덱스의 변경을 구독하고, 종목별 감시 대상을 메모리에 유지합니다.시세가 들어오면 후보를 찾고, 실제 체결 시에는 트랜잭션으로 최신 상태를 다시 확인합니다.
웹이나 앱을 닫아도 지정가 주문과 강제 청산은 워커에서 계속 처리합니다.
시장가와 워커의 실행 범위
시장가는 API 요청 안에서 가격 조회부터 잔고 검증·체결까지 처리합니다.지정가와 청산은 워커가 조건을 감시합니다.접수 시점에 이미 조건을 만족한 지정가는 API에서 즉시 체결하는 분기도 있습니다.
구조 변경의 운영 비용 절감률과 체결 지연은 아직 측정하지 않았습니다.검사 주기를 체결 완료 시간으로 표시하지 않았습니다.
02자산 조회 최적화
거래 이력을 재사용해 반복 조회를 줄였습니다.
자산 화면을 갱신할 때마다 전체 거래 이력까지 읽으면, 이력이 쌓일수록 조회 부담도 커집니다.잔고·유동성 문서의 변경 버전을 기준으로 이력을 재사용하고, 같은 키의 동시 요청은 하나로 합쳤습니다.
조회 1회당 계측 읽기 수
로컬 통합 테스트 · 거래 이력 20건- 최초 조회
- 44건
- 이력 재사용
- 3건
- 응답 캐시 적중
- 0건
이력 재사용 시 최초 조회 대비 93.2% 감소.거래 후에는 캐시를 무효화해 보유량과 취득 원가를 갱신합니다.
거래가 없으면 기존 이력을 재사용하고, 거래가 발생하면 캐시를 지워 최신 자산을 다시 조회합니다.
측정 조건과 결과의 범위
2026.09.14, 격리된 Firestore 에뮬레이터에서 통합 테스트 3개를 통과했습니다.동일한 거래 20건을 기존·사용자 이력 두 경로에 저장하고, 응답 캐시와 이력 캐시의 상태를 바꿔 비교했습니다.
최초 조회 44건, 응답 캐시만 무효화한 이력 재사용 조회 3건, 응답 캐시 적중 0건을 재현했습니다.거래 실행 후 취득 원가와 보유량 갱신도 검증했습니다.
현재 구현의 캐시 상태별 SDK 읽기 계측값입니다.이전 버전과의 성능 비교나 운영 DB 청구 비용의 93.2% 절감을 의미하지 않습니다.캐시는 인스턴스 단위이므로 다른 인스턴스에는 TTL 범위의 표시 지연이 남습니다.
03거래 상태 검증
주문 취소와 체결이 겹치는 상황을 처리했습니다.
지정가에 도달한 순간 사용자가 주문을 취소할 수 있습니다.메모리에서 찾은 후보만 믿고 체결하면 이미 취소되었거나 처리된 주문을 다시 실행할 수 있어, 트랜잭션 안에서 대기 상태를 확인하도록 했습니다.
- 가격 조건 도달
- pending 상태 재확인
- 잔고·주문·거래 기록 커밋
체결에 필요한 상태 변경을 같은 트랜잭션에 반영하고, 처리 후 감시 인덱스를 제거합니다.청산 역시 현재 잔고와 포지션으로 담보 여력을 다시 계산한 뒤 정산합니다.
화면 갱신에는 캐시를 사용하되, 잔고와 체결 판단에는 최신 거래 상태를 사용합니다.
보장하는 범위와 남은 과제
대기 주문의 상태 재검증은 이미 생성된 지정가 주문의 재처리를 방지하는 장치입니다.신규 주문 API에 같은 요청이 두 번 들어오는 문제는 별도의 멱등성 설계가 필요합니다.
현재 모의 파생거래는 외부 가격 조건에 따른 체결 모델입니다.사용자 주문 간 가격·시간 우선 매칭이나 호가 잔량에 따른 부분 체결은 구현 범위에 포함되지 않습니다.
04주문부터 체결까지
주문 요청부터 체결 결과까지
시장가는 API 요청 안에서 체결을 확정합니다.지정가는 대기 주문을 저장한 뒤, 워커가 가격 조건을 확인해 체결합니다.
주문 요청 안에서 체결까지 처리
- 01단계웹 · 앱
주문 요청
종목, 방향, 수량과 레버리지를 API에 전달합니다.
- 02단계API
체결가 조회
외부 시세에서 거래 방향에 맞는 체결 기준가를 가져옵니다.
- 03단계Firestore
잔고 검증·체결
가용 잔고를 확인하고 주문·포지션·거래 기록을 함께 저장합니다.
- 4단계웹 · 앱
결과 반영
체결 결과를 받고 최신 잔고와 포지션을 화면에 반영합니다.
Binance 지원 종목은 매수 ask·매도 bid를 우선 사용합니다.호가 조회에 실패하면 마크 가격을 대체 기준으로 사용합니다.
운영 중 쌓인 거래 기록
주문 진입부터 포지션 종료·청산까지, 기록된 체결은 6,648건입니다.일별 통계를 월 단위로 모아 거래대금과 체결 건수의 변화를 확인할 수 있도록 정리했습니다.
기록된 전체 기간
1,648.7억 ORZ
2026.05.05–09.13 · 5월과 9월은 부분 기간입니다.
월을 선택하면 해당 기간의 합계를 볼 수 있습니다.
월별 수치와 집계 기준
| 기간 | 체결 | 거래대금 (ORZ) |
|---|---|---|
| 5월 5–31일 | 1,827 | 48,838,716,061 |
| 6월 | 1,700 | 28,552,550,522 |
| 7월 | 1,969 | 38,254,648,030 |
| 8월 | 902 | 43,623,434,255 |
| 9월 1–13일 | 250 | 5,599,472,850 |
저장된 일별 통계 131개를 합산했습니다.
진입·종료·청산을 포함한 모의거래 기록이며, 통계가 없는 날짜를 거래 0건으로 간주하지 않았습니다.
세부 구현과 다음 과제
현재 API와 워커가 사용하는 기준 시세에는 차이가 있습니다.이 기준을 통일하고, 시세 수신부터 체결 완료까지 걸리는 시간과 실제 DB 읽기 수를 측정해 개선 효과를 확인할 계획입니다.
아키텍처·주문 조건·청산·AMM·비동기 UI
주문 종류에 따라 나눈 실행 경로
PC 웹과 앱인토스는 공통 API로 주문을 요청하고, API와 워커는 Firestore의 주문·잔고·포지션을 기준으로 동작합니다.서버가 대기 주문과 감시용 인덱스를 저장하면 워커가 변경을 구독해 종목별 메모리 인덱스에 반영합니다.체결 이후에는 실시간 서비스로 사용자 채널에 이벤트를 발행하고, 화면은 계좌 상태를 다시 조회해 갱신합니다.
시장가 · API 요청 안에서 체결
- 웹·앱에서 주문
- API 인증·입력 검증
- 외부 체결 기준가 조회
- 잔고 검증·거래 커밋
- 결과 응답·화면 갱신
시세 기준과 처리 조건 자세히
시장가 주문은 API 서버의 createOrder에서 처리합니다.Binance 지원 종목은 매수 방향의 ask 또는 매도 방향의 bid를 조회하며, 조회 실패 시 마크 가격을 대체 기준으로 사용합니다.외부 거래소에 실제 주문을 넣는 것이 아니라 내부 모의 계좌에 체결을 기록합니다.
지정가 · 주문 저장과 체결 시점 분리
- API에 지정가 주문
- 증거금·수수료 확보
- 대기 주문·인덱스 저장
- 워커가 가격 조건 확인
- 상태 재검증·체결 커밋
시세 기준과 처리 조건 자세히
대기 주문은 매수 방향이면 수신 가격 ≤ 지정가, 매도 방향이면 수신 가격 ≥ 지정가일 때 체결 후보가 됩니다.현재 워커는 지정가를 체결가로 기록합니다.주문 접수 시 이미 체결 조건을 만족하면 API에서 즉시 체결하는 분기도 있습니다.
강제 청산 · 가격 감지와 최종 정산
- 워커가 시세 수신
- 청산 대상 포지션 탐색
- 현재 잔고로 기준 재계산
- 손익·수수료 정산
- 포지션·관련 주문 정리
시세 기준과 처리 조건 자세히
시세 이벤트마다 조건을 확인하고, 기본 500ms 간격으로 마지막 수신 가격에 대해 후보를 다시 검사합니다.이 간격은 새 시세 수신 주기나 청산 완료 시간의 보장값이 아닙니다.최종 트랜잭션에서 현재 잔고와 열린 포지션 상태를 다시 검증합니다.
기술적 과제와 문제 해결
제목을 누르면 문제 상황과 해결 과정을 읽을 수 있습니다.
운영 경험 · 비용과 실행 구조Cron·폴링의 비용 부담을 계기로 상시 워커 도입
주기적으로 같은 데이터를 조회하던 구조에서, 시세와 감시 대상의 변경에 반응하는 구조로 전환했습니다.
- 문제
- 초기에는 Vercel Cron과 폴링으로 시세와 대기 주문을 반복 확인했습니다.Firebase·Vercel 요금 부담을 겪으면서, 체결·청산을 자주 확인할수록 API 실행과 데이터 읽기가 함께 늘어나는 구조가 문제라고 판단했습니다.
- 해결
- 상시 실행 워커에 Firestore 주문·포지션 인덱스 구독과 종목별 메모리 인덱스를 구성했습니다.Binance WebSocket과 HIP-3 가격 폴링으로 시세를 받아 후보를 검사하고, 체결·청산 시 트랜잭션으로 상태를 확정하게 했습니다.
- 결과
- 매번 전체 감시 대상을 조회할 필요를 줄이고 브라우저 접속과 무관하게 주문을 처리할 구조를 마련했습니다.변경 구독·거래 처리의 데이터베이스 비용과 워커 실행 비용은 여전히 발생하며, 실제 절감률은 별도 측정이 필요합니다.
판단과 배운 점
사용자의 요청을 처리하는 API와 접속 여부에 관계없이 지속해야 하는 감시 작업을 분리했습니다.감시 대상은 메모리에 유지하고, 데이터베이스에서는 변경 사항을 구독하는 방식을 선택했습니다.
실시간성을 높이기 위해 호출 횟수를 늘리기 전에, 어떤 데이터를 계속 보관하고 어떤 변화에 반응해야 하는지부터 설계해야 한다는 점을 배웠습니다.
시장가 · 서버의 체결 책임시장가 주문은 누가 시세를 확인하고 체결할까?
시장가는 API 서버에서 시세 조회부터 잔고 검증, 체결 기록까지 처리합니다.
- 문제
- 사용자가 화면에서 본 가격과 주문 요청이 서버에 도착했을 때의 가격은 다를 수 있습니다.클라이언트가 계산한 가격·수수료·잔고만으로 체결을 확정하면 거래 기록의 기준이 불명확해집니다.
- 해결
- API가 인증과 주문 입력을 검증한 뒤 체결 기준가를 가져옵니다.Binance 지원 종목은 매수 방향의 ask·매도 방향의 bid를 우선 사용하고, 증거금과 수수료를 계산한 다음 Firestore 트랜잭션에서 가용 잔고를 확인해 주문·포지션·거래 내역을 저장합니다.
- 결과
- 시장가 흐름을 사용자 → API → 시세 조회 → 트랜잭션 체결 → 결과 응답으로 정리했습니다.현재 체결 모델은 조회한 가격을 적용하는 모의거래이며, 실제 호가 잔량에 따른 부분 체결이나 시장 충격까지 재현하지는 않습니다.
판단과 배운 점
시장가는 주문 요청에 바로 응답해야 하므로 API 안에서 처리하고, 미래의 가격 조건을 기다리는 지정가 감시를 워커에 맡겼습니다.
화면에 표시할 시세와 거래를 기록할 기준가의 역할을 구분하고, 최종 거래 판단의 책임을 서버에 두었습니다.
지정가 · 조건 감시와 상태 전이가격이 지정가를 지나쳐도 놓치지 않도록 조건 정의
가격의 일치 여부가 아닌 방향별 도달 조건을 검사하고, 대기 주문을 체결 상태로 전환합니다.
- 문제
- 수신 가격이 지정가와 정확히 같을 때만 체결하면, 시세가 지정가를 건너뛰는 경우 주문을 놓칩니다.사용자의 주문 취소와 워커의 체결 시도가 겹치는 상황도 고려해야 했습니다.
- 해결
- 접수 시 증거금과 수수료를 가용 잔고에서 확보하고 pending 주문과 감시 인덱스를 함께 저장합니다.워커는 매수 방향에서 수신가 ≤ 지정가, 매도 방향에서 수신가 ≥ 지정가이면 후보를 처리합니다.트랜잭션에서는 주문이 여전히 pending인지 다시 읽고 지정가를 체결가로 기록하며 포지션과 거래 내역을 갱신합니다.
- 결과
- 가격이 임계값을 통과하는 경우도 처리하고, 이미 취소·체결된 주문은 저장 단계에서 제외합니다.접수 순간 이미 조건을 만족하는 지정가는 API의 즉시 체결 분기로 처리합니다.
판단과 배운 점
주문 접수와 실제 체결 시점을 분리하고, 가격 조건과 주문 상태 조건을 각각 확인하도록 했습니다.
지정가 체결에는 가격 비교뿐 아니라 자금 확보, 대기 상태, 취소와의 경쟁, 체결 후 인덱스 제거까지 이어지는 상태 관리가 필요했습니다.
강제 청산 · 타이밍과 수수료청산 조건 감지와 손익·수수료 정산을 함께 설계
시세 수신 때 후보를 찾고, 현재 담보 여력을 다시 계산한 뒤 청산을 확정합니다.
- 문제
- 가격 확인 간격이 길면 청산 조건을 늦게 발견할 수 있습니다.감시 중 잔고가 변하거나 수동 종료가 먼저 처리될 수 있어, 과거에 계산한 청산 가격만으로 정산해서도 안 됩니다.
- 해결
- 시세 이벤트와 기본 500ms 후보 재검사로 대상을 찾고, 트랜잭션에서 포지션이 open인지 확인합니다.현재 모의거래 규칙은 증거금의 95%와 가용 잔고를 손실 허용액으로 청산 기준가를 계산합니다.조건 충족 시 수신 가격으로 손익을 구하고, 수량 × 청산 가격 × 설정 수수료율을 차감해 잔고와 거래 기록을 함께 저장합니다.
- 결과
- 청산된 포지션의 관련 종료 주문도 취소해 이후 중복 종료를 막습니다.수수료율은 관리자 설정을 읽으며 기본값은 0.5%입니다.현재 청산 기준가 식에는 종료 수수료가 포함되지 않으므로, 수수료까지 고려한 담보 기준과 급격한 가격 변동 상황은 추가 검증 과제입니다.
판단과 배운 점
워커에서 가격 조건을 빠르게 확인하되 최종 판단은 트랜잭션의 최신 계좌·포지션을 기준으로 했습니다.청산 조건, 적용 가격, 손익, 수수료를 별도의 계산 단계로 다뤘습니다.
청산 타이밍은 검사 주기만으로 보장되지 않습니다.시세의 기준과 수신 지연, 최신 잔고 재검증, 체결 후 정산까지 연결해서 봐야 했습니다.
거래 모델 · 구현과 확장 구상가격 조건형 모의체결에서 자체 오더북·AMM으로 확장
기존 모의투자는 외부 가격을 기준으로 체결하고, 런치패드의 자체 토큰 거래에는 AMM을 구현했습니다.
- 문제
- 지정가 감시만으로 사용자 간 매수·매도 주문을 매칭하는 자체 거래소가 완성되지는 않습니다.외부 기준 시세가 없는 자체 토큰에는 가격과 거래 수량을 결정할 방식도 필요합니다.
- 해결
- 런치패드 거래에서 oP·토큰 준비금과 입력 수량을 이용해 수령량을 계산하고, 수수료와 최소 수령량 조건을 검증합니다.풀의 준비금, 사용자 잔고, 거래 내역은 하나의 트랜잭션에서 변경합니다.
- 결과
- 외부 시세 기반 모의체결과 풀 기반 자체 토큰 거래를 각각 구현했습니다.사용자 주문끼리 매칭하는 자체 오더북은 확장 아이디어이며, AMM에도 초기 유동성·거래 규모에 따른 가격 변동을 고려해야 합니다.
판단과 배운 점
자체 오더북으로 확장한다면 가격·시간 우선순위, 부분 체결, 미체결 잔량, 취소 경쟁, 유동성을 추가로 다뤄야 합니다.별도 런치패드에는 풀의 준비금을 기준으로 거래량과 가격을 계산하는 AMM 로직이 구현되어 있습니다.
체결 대상을 감시하는 워커와 가격·수량을 결정하는 거래 모델은 서로 다른 역할입니다.AMM을 선택해도 지정가나 담보 청산의 실행 시점을 감시할 필요까지 없어지는 것은 아닙니다.
추가 개선 사례 · 비동기 UI, 동시성, 캐시, API
프론트엔드 · 비동기 상태 관리화면 전환 뒤 늦게 도착한 응답을 어떻게 처리할까?
화면이 보이는 동안만 폴링하고, 현재 선택에 유효한 응답만 반영하도록 구성했습니다.
- 문제
- 앱인토스의 토큰 상세에서 A 종목을 조회하다 B 종목으로 이동하면, 늦게 도착한 A 응답이 B 화면을 덮어쓸 수 있습니다.일정 간격으로 요청만 보내면 응답이 느릴 때 요청이 겹치고, 보이지 않는 화면도 계속 조회하게 됩니다.
- 해결
- useVisiblePolling 훅에서 요청 완료 후 다음 조회를 예약하고, 탭이 숨겨지면 예약을 멈췄습니다.상세 화면의 열림 상태와 선택 종목을 의존성으로 두고, 응답 시 현재 작업의 유효 여부와 선택 버전을 확인했습니다.목록·상세·잔고는 각각 30초·10초·60초 간격으로 조회합니다.
- 결과
- 화면이 다시 보이면 조회를 재개하고, 닫힌 상세나 이전 종목의 응답은 화면에 반영하지 않도록 했습니다.상세를 보는 동안에는 목록 폴링도 중단합니다.
판단과 배운 점
폴링 주기를 늘리는 것만으로는 응답 순서 문제를 해결할 수 없어, 요청 실행 조건과 응답 반영 조건을 따로 관리했습니다.
비동기 UI에서는 요청을 시작하는 시점뿐 아니라, 응답이 도착했을 때 여전히 필요한 데이터인지 확인하는 기준이 필요했습니다.
데이터 정합성 · 동시성같은 지정가 주문의 중복 체결과 잔고 불일치 방지
주문 상태 재검증과 관련 데이터 변경을 하나의 트랜잭션으로 묶었습니다.
- 문제
- 여러 주문이 같은 잔고를 사용하거나 워커와 보조 작업이 같은 주문을 처리할 수 있습니다.조회한 상태를 그대로 믿고 각각 저장하면 잔고 검증 시점이 어긋나거나 주문과 포지션 중 일부만 반영될 수 있습니다.
- 해결
- 주문 생성 시 트랜잭션 안에서 가용 잔고와 계좌·대회 규칙을 검사하고 잔고와 주문을 함께 저장했습니다.지정가 체결 시에는 주문을 다시 읽어 pending 상태인지 확인한 뒤, 체결 상태·포지션·거래 기록·워커 인덱스를 같은 트랜잭션에서 갱신했습니다.
- 결과
- 이미 처리되거나 취소된 지정가 주문은 재처리하지 않도록 했고, 체결에 필요한 변경은 함께 커밋되도록 구성했습니다.단, 신규 주문 생성 요청 자체의 중복 제출 방지는 별도의 멱등성 설계가 필요한 영역입니다.
판단과 배운 점
화면의 버튼 비활성화로는 다른 실행 경로의 경쟁을 막을 수 없어, 최종 저장 단계에서 현재 상태를 검증하도록 했습니다.
동시성 문제는 요청을 순서대로 보내는 것보다, 어떤 상태에서 어떤 변경을 허용할지 저장 단계에서 정의하는 일이 핵심이었습니다.
성능 · 조회 비용반복 조회를 줄이면서 거래 판단에는 최신 상태 유지
표시용 데이터에만 캐시를 적용하고, 변경된 자산의 캐시를 거래 후 무효화했습니다.
- 문제
- 토큰 목록과 보유 자산을 반복 조회할 때 거래 내역까지 매번 읽으면 데이터가 쌓일수록 읽기 부담이 커집니다.반대로 같은 캐시를 체결 검증에 사용하면 오래된 잔고로 거래를 판단할 수 있습니다.
- 해결
- 동일 키의 진행 중인 요청을 하나의 Promise로 공유하고 목록·상세·포트폴리오에 짧은 TTL을 적용했습니다.거래 이력 캐시 키에는 UID와 Firestore 문서의 updateTime을 포함했고, 거래 커밋 후 관련 캐시를 무효화했습니다.체결 가격·잔고 검증은 조회용 캐시를 사용하지 않습니다.
- 결과
- 변경 없는 자산 조회에서는 거래 이력을 다시 읽지 않고 재사용하며, 거래 후에는 관련 데이터를 다시 조회하도록 했습니다.인스턴스 간에는 캐시가 즉시 동기화되지 않으므로 TTL 범위의 표시 지연은 남아 있습니다.
판단과 배운 점
짧은 지연을 허용할 수 있는 조회와 정확한 현재 상태가 필요한 거래를 구분했습니다.이력은 잔고·유동성 문서의 변경 버전이 같을 때만 재사용하도록 했습니다.
캐시는 보관 시간뿐 아니라 무엇이 바뀌면 버려야 하는지까지 정의해야 했습니다.조회 최적화와 거래의 정확성을 함께 고려한 사례입니다.
외부 API · 장애 대응 설계시세 API 호출이 몰릴 때 재시도가 더 몰리지 않도록 제어
CoinGecko 호출을 공통 진입점에 모으고 요청 속도와 재시도 대기를 함께 관리했습니다.
- 문제
- 여러 화면의 서버 요청이 동시에 외부 시세 API를 호출하면 호출 한도에 걸릴 수 있습니다.각 요청이 독립적으로 재시도하면 429 응답 직후에도 호출이 몰릴 수 있습니다.
- 해결
- 동일 URL의 진행 중 요청을 병합하고 요청 시작 간격과 최대 동시 실행 수를 제한했습니다.429 응답에는 Retry-After를 해석해 공통 대기 시각을 설정하고, 네트워크 오류와 5xx에는 지수 백오프와 작은 무작위 지연을 적용했습니다.타임아웃과 최대 재시도 횟수도 제한했습니다.
- 결과
- 같은 인스턴스에서 중복 호출과 재시도 집중을 완화하는 구조를 마련했습니다.재시도까지 실패하면 저장된 마지막 정상 응답을 반환할 수 있어, 후속 과제로 데이터 기준 시각과 지연 상태를 화면에 더 명확히 표시할 필요가 있습니다.
판단과 배운 점
개별 화면에서 재시도하는 대신, 같은 서버 인스턴스의 요청들이 호출 간격과 대기 상태를 공유하도록 했습니다.
외부 API 연동에서는 정상 응답뿐 아니라 호출 한도, 응답 지연, 실패 시 사용자에게 보여 줄 데이터의 최신성도 설계 대상이었습니다.
운영 수치의 집계 기준
2026.05.05–09.13의 일별 통계 131개 문서를 합산했습니다.진입 3,765건, 종료 2,014건, 강제 청산 869건으로 총 6,648건입니다.진입 후 종료한 거래는 두 이벤트로 집계됩니다.
거래대금은 저장된 모의 명목금액을 ORZ로 표시했습니다.레버리지가 반영된 금액이며, 실제 입금액이나 매출이 아닙니다.별도 런치패드의 oP와 외부 DEX 거래는 합산하지 않았습니다.
저장된 집계 범위의 수치로, 출시일부터의 전체 이력이나 테스트·대회 계좌를 제외한 통계로 해석하지 않습니다.계정 문서 수는 실제 순사용자 수와 달라 대표 수치에서 제외했습니다.
확인일 2026.09.14 · 운영 DB 읽기 전용 조회