옴니스톤은 STONfi에서 TON 유동성을 어떻게 집계하나요?

2026년 9월 13일 읽는 시간 약 13분

✅ 핵심 요약
🧩 TON의 유동성이 애초에 분산된 이유는 무엇일까요?
🔍 옴니스톤이 실제로 무엇을 집계하는가
⚙️ 단일 요청에 대한 여러 소스별 가격 산정 방식
🤝 RFQ 리졸버가 별도의 경로가 아닌 동일한 비교 항목에 포함되는 이유
🔄 왜 캐시된 가격표가 아닌 실시간으로 처리해야 할까요?
🧭 거래자 입장에서 이것이 실제로 어떻게 보이는지
📊 비교를 위한 간단한 그림 설명
🧭 결론
❓ 자주 묻는 질문
📚 참고 자료 및 추가 읽을거리

TON의 유동성은 거래를 기다리며 한 곳에 모여 있는 것이 아니라, STON.fi 자체 풀, 다른 TON 탈중앙화 거래소(DEX), 그리고 독립적인 리졸버들에 분산되어 있으며, 각 리졸버들은 동일한 자산에 대해 시점마다 미묘하게 다른 가격을 책정합니다. 옴니스톤의 핵심 역할은 바로 이러한 분산을 눈에 띄지 않게 만드는 것입니다.

STON.fi에 접속하여 스왑을 요청하면, 단일 가격처럼 보이는 것이 사실은 백그라운드에서 진행되는 소규모 경쟁의 결과입니다. TON의 DeFi 유동성은 단일 AMM이 암시하는 것처럼 하나의 통합 풀에 존재하는 것이 아니라, STON.fi 자체 계약, 다른 독립적인 TON DEX, 그리고 자체 자본을 보유한 리졸버들에 분산되어 있으며, 각 리졸버는 자체 보유 자산이나 시장 전망에 따라 자산 가격을 책정합니다. 옴니스톤은 바로 이러한 분산된 환경을 하나의 견적, 하나의 경로, 하나의 거래로 통합하여 거래자가 유동성의 출처를 알 필요도 없고 신경 쓸 필요도 없도록 하기 위해 존재합니다.

💭 이 문제의 심각성을 간과하기 쉬운 부분은 실제 문제가 그다지 화려하지 않다는 점입니다. 집계는 눈에 띄는 기능이 아니라, 마치 배관과 같은 기본적인 구조입니다. 하지만 바로 이 배관 구조가 “좋은 가격”이라는 주장이 진짜인지, 아니면 거래 규모가 커지는 순간 무너지는 단순한 헤드라인 수치에 불과한지를 결정짓는 핵심입니다.

✅ 핵심 요약

Omniston은 STON.fi 자체 AMM 풀, 다른 TON DEX, 그리고 독립적인 자본을 보유한 RFQ 리졸버 등 여러 소스에서 유동성을 한 번에 통합합니다.
단일 스왑 요청은 하나의 소스를 통해서만 강제로 처리되는 대신 여러 풀 또는 경로(“청크”)로 분할될 수 있습니다.
RFQ 리졸버는 공개 풀과 동일한 비교 대상에 포함됩니다. 별도의 대체 옵션이 아니라 모든 요청에 대해 평가되는 경쟁 옵션입니다.
경로 결정은 고정된 사전 계산 가격표가 아닌, 현재 보유량과 이용 가능한 견적을 기반으로 요청 건별로 실시간으로 이루어집니다.
거래자는 실제로 관련된 기초 자산의 수와 관계없이 최종 견적과 거래 내역만 보게 됩니다.

🧩 TON의 유동성이 애초에 분산된 이유는 무엇일까요?

파편화는 TON에만 국한된 결함이 아니라, 누구나 풀을 배포할 수 있고 여러 독립적인 탈중앙화 거래소(DEX)가 동일한 거래 쌍을 상장할 수 있는 허가 없는 생태계의 자연스러운 결과입니다. STON.fi는 자체 풀을 운영하고, 다른 TON DEX들도 각자의 풀을 운영합니다. 이들 풀은 서로 가격을 조정할 의무가 없으며, 동일한 거래 쌍에 대해 동일한 거래량을 유지해야 할 의무도 없습니다. 결과적으로, 특정 시점에 자산 A를 자산 B로 교환하는 데 있어 “실질적으로” 가장 좋은 가격은 거래자가 먼저 열어본 풀이 아닌 다른 풀에 있을 수 있습니다.

이 문제를 해결하지 않으면 거래자는 매번 거래 전에 여러 앱을 일일이 확인하고, 시세를 비교하고, 가장 적합한 것을 직접 선택해야 하는 부담을 안게 됩니다. 바로 이러한 불편함을 해소하기 위해 정보 통합 서비스가 존재하는 것입니다.

🔍 옴니스톤이 실제로 무엇을 집계하는가

옴니스톤은 모든 스왑 요청에 대해 세 가지 서로 다른 유동성 범주를 단일 의사 결정 프로세스로 통합합니다.

STON.fi 자체 AMM 풀은 플랫폼의 고유 유동성으로, 풀 유형에 따라 표준 고정 가격 또는 스테이블 스왑 공식을 통해 가격이 책정됩니다.
다른 TON DEX 풀 – TON 생태계 전반의 독립 프로토콜에 있는 유동성을 무시하지 않고 STON.fi 자체 보유량과 함께 평가합니다.
RFQ 리졸버는 자체 자본을 보유한 시장 조성자로, 공개된 온체인 공식에 기반한 가격이 아닌 실시간으로 경쟁력 있는 견적을 제시하여 스왑 요청에 응답합니다.

이 세 가지 범주 중 어느 것도 다른 범주가 실패했을 때의 대안으로 간주되지 않습니다. 동일한 요청에 대해 모두 함께 평가되며, 거래자에게 더 나은 결과를 제공하는 범주가 실제로 실행됩니다.

⚙️ 단일 요청에 대한 여러 소스별 가격 산정 방식

견적 산출 과정은 단순히 “몇몇 유동성 풀을 확인하고 가장 큰 금액을 선택하는 것”보다 훨씬 복잡합니다. 옴니스톤의 라우팅 모델은 스왑 거래를 자체 아키텍처에서 “경로”, “단계”, “청크”라고 부르는 여러 단계로 나누어 처리합니다. 이를 통해 단일 거래가 하나의 유동성 소스에만 국한되지 않고 여러 유동성 소스로 분산될 수 있습니다.

이는 특히 대규모 거래에서 중요합니다. 단일 풀의 가격은 해당 풀의 보유량 대비 거래 규모가 클수록 더 크게 변동하는데, 이것이 일반적인 AMM 가격 영향입니다. 옴니스톤은 대규모 주문 전체를 하나의 풀로 보내고 그 영향을 그대로 감수하는 대신, 주문을 여러 부분으로 나누어 각 부분을 가장 효율적으로 처리할 수 있는 풀로 보낼 수 있습니다. 거래자는 여전히 하나의 거래를 제출하고 하나의 통합된 결과를 받게 되며, 이러한 분할 처리는 라우팅 계층 내에서 완전히 이루어집니다.

🤝 RFQ 리졸버가 별도의 경로가 아닌 동일한 비교 항목에 포함되는 이유

AMM 풀을 “기본” 유동성으로, RFQ 리졸버를 특수한 경우를 위한 백업 수단으로 생각하기 쉽지만, 옴니스톤은 그렇게 생각하지 않습니다. 모든 견적 요청에 대해 리졸버는 공개 풀 가격과 동시에 응답해야 하며, 두 가격은 직접 비교됩니다. 즉, 동일한 요청, 동일한 시점에 서로 다른 결과가 나오는 것입니다.

이는 풀과 리졸버가 서로 다른 방식으로 실패하기 때문에 중요합니다. 풀의 가격은 전적으로 자체 보유량에 따라 결정됩니다. 거래쌍의 유동성이 부족하거나 예치금 대비 거래 규모가 큰 경우, 라우팅 로직이 아무리 뛰어나더라도 가격에 미치는 영향이 커집니다. 반면 리졸버는 고정된 온체인 공식에 얽매이지 않습니다. 자체 보유량과 위험 감수 능력에 따라 가격을 책정할 수 있으므로, 퍼블릭 풀이 구조적으로 어려움을 겪는 부분, 즉 유동성이 부족한 거래쌍, 대규모 거래, 또는 아직 충분한 유동성 공급을 확보하지 못한 신규 자산과 같은 상황에서 리졸버가 더 경쟁력이 있을 수 있습니다.

🔄 왜 캐시된 가격표가 아닌 실시간으로 처리해야 할까요?

당연히 드는 질문은 왜 이 비교를 한 번만 계산해서 재사용할 수 없는가 하는 것입니다. 마치 캐시된 환율을 다른 곳에서 사용하는 것처럼 말이죠. 하지만 유동성 상황은 너무 빠르게 변하기 때문에 그런 방식은 통하지 않습니다. 풀 준비금은 모든 거래마다 변동합니다. 리졸버가 가격을 제시할 의향과 제시하는 가격은 리졸버의 재고와 시장 전망에 따라 시시각각 변할 수 있습니다.

옴니스톤의 견적 요청은 이러한 현실을 바탕으로 설계되었습니다. 요청 시 고정된 단일 응답이 아닌 실시간으로 업데이트되는 구독 가능한 가격 스트림을 반환하므로, 견적은 캐시가 마지막으로 갱신된 시점의 스냅샷이 아닌 현재 상황을 반영합니다. 또한 견적에 유효 기간이 있는 이유도 바로 이 때문입니다. 견적은 무기한으로 유효한 사실이 아니라 현재 상황을 기반으로 구축된 실시간 기간 한정 제안입니다.

🧭 거래자 입장에서 이것이 실제로 어떻게 보이는지

위의 내용은 STON.fi 인터페이스에서 직접 볼 수 없으며, 이는 의도적인 것입니다. 거래자가 실제로 경험하는 것은 다음과 같습니다.

제공하는 자산에 대한 입력 필드 하나, 요청하는 자산에 대한 입력 필드 하나가 있습니다.
제시된 출력 금액은 어떤 풀과 리졸버 조합을 사용했을 때 가장 좋은 결과가 나온 값을 이미 반영하고 있습니다.
거래가 STON.fi 자체 풀을 통해 완전히 정산되었는지 여부와 관계없이, 하나의 확인과 하나의 거래가 여러 TON DEX에 분산되거나, 리졸버를 통해 처리되거나, 또는 이 세 가지 방식이 혼합되어 처리됩니다.

여러 소스를 비교하고, 대규모 주문을 여러 부분으로 나누고, 실시간 상황에 따라 다시 견적을 내는 복잡한 작업들이 모두 단 하나의 간단한 동작으로 처리됩니다. 이것이 바로 거래자들이 매번 수동으로 비교 작업을 하도록 하는 대신 집계 레이어를 구축하는 근본적인 이유입니다.

📊 비교를 위한 간단한 그림 설명

이를 구체적으로 설명하자면, 한 트레이더가 중간 규모의 USDT를 GRAM으로 교환하고 싶어한다고 가정해 보겠습니다. STON.fi 자체 풀은 현재 보유량을 반영한 가격을 제시할 수 있습니다. 또 다른 TON DEX는 해당 거래쌍에 대해 더 많은 풀을 보유하고 있어 약간 더 나은 가격을 제공할 수 있습니다. 한편, 자체 GRAM 재고를 보유한 리졸버는 어느 풀의 가격 산정 방식에도 구애받지 않기 때문에 두 곳 모두보다 더 나은 가격을 제시할 수도 있습니다. 옴니스톤은 트레이더에게 세 곳 모두를 확인하도록 요구하지 않습니다. 세 곳의 소스에서 동시에 견적을 요청하고, 수수료와 예상 가격 변동을 고려한 후 결과를 비교하여 가장 유리한 순이익을 제공하는 곳을 선택합니다. 거래 규모가 충분히 크다면, 위에서 설명한 라우팅 섹션처럼 단일 소스를 선택하는 대신 여러 소스의 결과를 조합하여 최적의 가격을 제시할 수도 있습니다.

🧭 결론

옴니스톤의 TON 유동성 통합은 단 하나의 영리한 방법이 아니라, 여러 가지 메커니즘이 유기적으로 협력한 결과입니다. STON.fi 자체 풀, 다른 TON DEX, RFQ 리졸버들을 동일한 요청에 대한 동등한 경쟁자로 참여시키고, 대규모 거래를 여러 경로, 단계, 청크를 통해 분산 처리하며, 고정된 가격에 의존하는 대신 지속적으로 가격을 재호가합니다. TON DeFi 생태계 전반에 걸친 분산 현상이 사라지는 것이 아니라, 스왑을 시도하는 사용자에게 부담을 지우는 대신 라우팅 계층에서 이를 흡수하는 것입니다.

❓ 자주 묻는 질문

옴니스톤은 STON.fi 자체 유동성 풀만 사용하나요? 아닙니다. 옴니스톤은 STON.fi 자체 풀뿐만 아니라 다른 TON DEX 및 독립적인 RFQ 리졸버의 풀도 통합하여, 스왑 요청 시 단일 소스를 기본값으로 사용하는 대신 모든 풀을 비교합니다.

왜 하나의 풀만 사용하지 않고 여러 풀로 나누어 거래할까요? 분할 거래는 대규모 거래에 미치는 가격 변동폭을 줄여줍니다. 단일 풀의 가격은 보유 자산 대비 거래 규모가 클수록 더 크게 변동하기 때문에, 주문을 여러 개의 작은 단위로 나누어 각기 다른 풀로 보내는 것이 전체 거래를 하나의 풀로 처리하는 것보다 더 나은 가격 균형을 만들어낼 수 있습니다.

RFQ 리졸버는 풀에 유동성이 부족할 때만 사용되는 건가요? 꼭 그렇지는 않습니다. 리졸버는 모든 요청에 대해 풀 가격과 함께 평가되며, 단순히 대안으로만 사용되는 것은 아닙니다. 특히 유동성이 부족한 페어나 대규모 거래의 경우 리졸버가 유리한 경우가 많지만, 비교 과정은 페어나 거래 규모와 관계없이 이루어집니다.

옴니스톤이 최적의 가격을 캐시하고 일정 기간 동안 재사용할 수 없는 이유는 무엇일까요? 풀 예약량과 리졸버의 견적 제공 의지가 끊임없이, 때로는 몇 초 만에 변하기 때문입니다. 캐시된 가격은 실제 실행 가능한 조건을 빠르게 반영하지 못하게 되므로, 견적은 고정된 재사용 가능한 값이 아닌 자체 유효 기간을 가진 실시간 스트림으로 제공됩니다.