DEX 사용자 경험 및 실행 지연 시간에 있어 TON 메시지 체이닝이 중요한 이유

2026년 9월 22일 읽는 시간 약 12분

DEX 사용자 경험 및 실행 지연 시간에 있어 TON 메시지 체이닝이 중요한 이유
🔗 TON은 당신이 예상하는 방식대로 “단 한 번의 거래”를 처리하지 않습니다.
⏱️ 이것이 실제로 체감할 수 있는 지연 현상으로 나타나는 이유
🎨 이것이 특정 UX 결정을 내리게 하는 이유
🌉 진짜 복잡해지는 부분: 크로스체인
🧭 이 모든 것이 TON에서 DEX를 사용하는 방식을 바꿔야 하는 이유
❓ 자주 묻는 질문
📚 참고 자료 및 추가 읽을거리

DEX 사용자 경험 및 실행 지연 시간에 있어 TON 메시지 체이닝이 중요한 이유

TON은 스왑을 한 번에 처리하는 것이 아니라, 계약 간에 메시지를 주고받는 일련의 과정을 통해 처리합니다. 이러한 아키텍처는 STON.fi의 사용 경험 전반에 걸쳐 미묘한 영향을 미칩니다.

STON.fi에서 토큰을 교환하는 대부분의 사람들은 “확인” 버튼을 클릭한 후 토큰이 지갑에 입금될 때까지 어떤 일이 일어나는지 생각해 본 적이 없을 것입니다. 당연한 일이죠. 그럴 필요가 없으니까요. 하지만 그 공백은 비어있는 것이 아니며, 실제로 어떤 일이 벌어지는지 이해하면 TON 교환이 특정 방식으로 작동하는 이유, 특정 사용자 경험 패턴이 존재하는 이유, 그리고 “단일 거래”라는 개념이 이 블록체인에서 교환을 설명하는 데 있어 잘못된 방식인 이유를 많이 알 수 있습니다.

TON의 아키텍처가 실제로 어떻게 작동하는지 자세히 읽어보기 전까지는 이 점을 제대로 이해하지 못했습니다. 이전에는 TON이 제가 사용했던 다른 체인들과 똑같이 작동할 거라고 막연히 생각했었거든요. 알고 보니 제 생각이 중요한 부분에서 틀렸다는 것을 깨달았습니다.

나는 이전에는 모든 버튼 교체를 마치 원자적인 클릭 한 번처럼 생각하고 있었다. 그런데 알고 보니 릴레이 경주와 더 비슷했고, 그제야 여러 가지 사소한 사용자 경험상의 특이점들이 더 이상 무작위적으로 느껴지지 않았다.

🔗 TON은 당신이 예상하는 방식대로 “단 한 번의 거래”를 처리하지 않습니다.

대부분의 블록체인에서는 트랜잭션을 단일 동기 이벤트, 즉 한 번의 호출과 실행으로 처리하는 방식에 익숙합니다. 하지만 TON은 다릅니다. TON은 비동기 샤딩 아키텍처를 기반으로 구축되었기 때문에 STON.fi에서 스왑과 같은 단일 사용자 작업은 한 번의 원자적 단계로 처리되지 않습니다. 여러 스마트 계약 간에 전달되는 일련의 내부 메시지를 통해 처리되며, 각 메시지는 다음 메시지를 트리거합니다.

STON.fi 라우터를 통한 스왑은 일련의 계약들을 거칩니다. 사용자의 지갑이 라우터에 메시지를 보내면, 라우터는 관련 풀 계약에 메시지를 보내고, 풀은 스왑 금액을 계산하여 다시 메시지를 보내고, 최종적으로 그 결과가 사용자의 지갑에 도달합니다. 이 모든 과정은 하나의 명령이 위에서 아래로 순차적으로 실행되는 것이 아니라, 각각의 처리 단계를 거치는 개별적인 메시지입니다.

지갑에서 발송되는 메시지가 라우터 계약을 트리거합니다.
라우터는 해당 요청을 적절한 유동성 풀로 전달합니다.
풀은 AMM 계산을 수행하고 응답 메시지를 보냅니다.
그 응답은 최종 결과가 지갑에 반영될 때까지 계속해서 전달됩니다.

이는 결함이나 나중에 덧붙여진 비효율성이 아니라, TON이 대규모 샤딩을 지원하기 위해 의도적으로 감수한 절충안입니다. 하지만 이는 “내 스왑은 하나의 트랜잭션으로 처리된다”는 사고방식이 애초에 적절하지 않았다는 것을 의미합니다.

⏱️ 이것이 실제로 체감할 수 있는 지연 현상으로 나타나는 이유

여기서 아키텍처는 추상적인 다이어그램을 넘어 실제로 스왑이 진행되는 동안 로딩 스피너를 바라보면서 느끼는 감정에 영향을 미치기 시작합니다. 메시지 체인의 각 메시지는 다음 메시지가 실행되기 전에 블록에 포함되어야 합니다. 체인에 메시지가 많을수록 최종 결과를 보기까지 거쳐야 하는 단계가 많아집니다. 이는 시스템에 문제가 있어서가 아니라, 인과 관계가 전달되는 과정이 그만큼 복잡해지기 때문입니다.

STON.fi에서 간단한 단일 풀 스왑의 경우, 메시지 체인은 비교적 짧고 일반적으로 빠르게 처리되므로 사용자는 홉이 발생하는 것을 의식적으로 인지하지 못합니다. 그러나 스왑이 여러 풀을 거쳐야 하거나, 더 나아가 Omniston의 크로스체인 메커니즘을 통해 여러 체인 간의 조정이 필요한 경우, 메시지 체인은 의미 있게 길어지고, 이 추가 길이는 단순히 기술적인 도표에 숨겨진 것이 아니라 사용자가 실제로 체감할 수 있는 지연 시간으로 이어집니다.

솔직히 말하자면, TON이 느린 게 아닙니다. 멀티홉 스왑은 싱글홉 스왑보다 실제로 더 많은 순차 작업을 처리하는데, 이를 부인하는 건 사용자 경험 측면에서 좋지 않은 설명이 될 뿐입니다.

🎨 이것이 특정 UX 결정을 내리게 하는 이유

사실 저는 이 부분이 가장 흥미롭습니다. 왜냐하면 그렇지 않으면 임의적으로 보일 수 있는 디자인 선택들을 설명해 주기 때문입니다. 스왑이 즉시 완료되는 것이 아니라 일련의 메시지를 통해 해결되는 경우, 인터페이스는 정확히 두 가지 정직한 선택지를 갖습니다. 즉시 완료되는 것처럼 가장하여 사용자를 오도할 위험을 감수하거나, 진행 중인 상태를 명확하게 전달하는 것입니다. STON.fi를 포함한 TON의 훌륭한 DEX 인터페이스는 두 번째 옵션을 선호합니다. 왜냐하면 “확인됨”과 “실제 완료됨” 사이의 차이를 사용자가 처음 알아차리는 순간부터 신뢰가 무너지기 때문입니다.

그래서 특정 패턴이 지속적으로 나타나는 것을 볼 수 있습니다.

클릭과 완료 사이에 아무런 표시도 없는 인터페이스 대신, “대기 중” 상태를 명확하게 표시합니다.
메시지가 실제로 전파됨에 따라 업데이트되는 트랜잭션 상태이며, 성공/실패라는 이진 플래그 하나만 제공하는 방식이 아닙니다.
최종 확인은 첫 번째 메시지가 전송되는 순간이 아니라 전체 메시지 체인이 완전히 해결된 후에만 명시적으로 이루어집니다.

이 모든 것은 장식이 아닙니다. “제출됨”과 “완료됨”이 실제로는 서로 다른 시점이며, 때로는 눈에 띄게 차이가 나는 아키텍처를 솔직하게 보여주는 인터페이스입니다. 이러한 구분을 모호하게 만들면 사용자는 처음에는 아무 일도 일어나지 않았다고 생각하고 두 번이나 전환하게 되는 결과를 초래합니다.

🌉 진짜 복잡해지는 부분: 크로스체인

TON 자체 내에서의 메시지 체이닝은 별개의 문제입니다. 하지만 옴니스톤의 크로스체인 스왑 기능을 추가하면 체인이 단순히 길어지는 것을 넘어, 서로 전혀 알지 못하는 시스템들을 연결하게 되면서 근본적으로 다른 종류의 복잡성이 발생합니다.

옴니스톤을 통한 크로스체인 스왑은 TON 측 메시지가 완전히 별개의 블록체인에서 이루어지는 HTLC 정산과 연동되는 과정을 포함합니다. 이 별개의 블록체인은 자체적인 블록 생성 시간, 확인 규칙을 가지고 있으며, TON의 존재 자체를 전혀 인식하지 못합니다. TON 측 메시지 체인은 결국 완전히 독립적인 체인에서 발생하는 확인과 동기화되어야 하는데, 이러한 동기화 과정은 TON 자체의 메시지 전달 시스템 내에서만 해결하는 것보다 훨씬 더 오랜 시간이 걸릴 수밖에 없습니다.

바로 이런 이유 때문에 크로스체인 스왑은 동일체인 스왑보다 시간이 훨씬 오래 걸리는 것이며, 좋은 인터페이스는 사용자가 로딩 중인 것을 알면서도 아무 반응 없이 기다리게 하는 대신 이러한 지연 시간을 명확하게 알려주는 것입니다. 이러한 지연은 옴니스톤 설계의 결함이 아니라, 애초에 서로 직접 통신하도록 설계되지 않은 두 시스템을 연동하는 과정에서 발생하는 자연스러운 현상입니다.

처음으로 크로스체인 스왑을 시도했는데, 뭔가 잘못된 줄 알았어요. 하지만 아무 문제도 없었죠. 두 블록체인이 어떤 것에 대해 합의하는 데 매번 실제 시간이 걸린다는 사실을 그때는 미처 이해하지 못했던 거예요.

🧭 이 모든 것이 TON에서 DEX를 사용하는 방식을 바꿔야 하는 이유

이 모든 설명은 TON이 더 단순하고 동기적인 실행 방식을 사용하는 샤딩 체인보다 나쁘다는 것을 암시하려는 것이 아닙니다. 이는 진정한 아키텍처적 절충안이지 결함이 아닙니다. TON 규모의 샤딩에는 이러한 비동기 메시지 전달 설계가 필수적이며, 둘 중 하나를 포기할 수는 없습니다. 하지만 이러한 점을 이해하고 나면 실제로 적용해 볼 만한 몇 가지 실질적인 습관이 달라집니다.

단일 풀 스왑은 빠르게 처리될 것으로 예상되며, 멀티홉 또는 크로스체인 스왑은 실제로 시간이 더 오래 걸릴 수 있습니다. 이는 문제가 아니라 아키텍처가 실제 순차적인 작업을 수행하는 과정입니다.
거래가 느려 보인다고 해서 바로 다시 제출하지 마세요. 아무런 반응이 없다는 이유만으로 실패라고 단정짓기보다는 실제 상태를 확인하세요.
“대기 중” 상태는 “실패” 및 “완료” 상태와 의미 있게 다른 상태로 취급해야 합니다. 특히 TON 환경에서는 중간 상태인 “대기 중”이 다소 오래 지속될 수 있기 때문입니다.
STON.fi에서 크로스체인 경로에 더 긴 예상 시간이 표시되는 것은 실제 메시지 체인 길이를 정확하게 반영하는 것이며, 예상치를 부풀리는 것이 아닙니다.

메시지 체이닝을 이해한다고 해서 스왑 실행 속도가 빨라지는 것은 아닙니다. 하지만 대기 시간을 이해할 수 있게 해주고, 이전에는 설명할 수 없는 지연처럼 느껴졌던 것을 실제로 추론할 수 있는 시스템으로 바꿔줍니다.

❓ 자주 묻는 질문

STON.fi 스왑이 예상보다 오래 걸리는 이유는 무엇인가요? TON 스왑은 단일 단계로 즉시 처리되는 것이 아니라, 계약 간의 내부 메시지 체인을 통해 해결됩니다. 여러 스왑 풀을 사용하거나 Omniston을 통한 크로스체인 스왑과 같이 복잡한 경로는 더 긴 메시지 체인을 필요로 하며, 이는 자연스럽게 순차적으로 처리되는 데 더 많은 시간이 소요됨을 의미합니다.

대기 시간이 길어진다고 해서 반드시 문제가 발생한 것은 아닙니다. TON의 비동기식 샤딩 아키텍처로 인해 스왑이 완전히 완료되기까지 메시지가 여러 단계를 거쳐야 합니다. 예상보다 대기 시간이 길다고 해서 실패라고 단정짓기보다는 실제 트랜잭션 상태를 확인해 보세요.

STON.fi에서 크로스체인 스왑이 동일체인 스왑보다 시간이 더 오래 걸리는 이유는 무엇인가요? 옴니스톤(Omniston)을 통한 크로스체인 스왑은 TON 측 메시지 체인이 완전히 별개의 블록체인(자체 블록 생성 시간 및 규칙 적용)에서 이루어지는 확인과 동기화되어야 하므로, TON 내에서만 해결하는 것보다 근본적으로 느린 조정 과정이 필요합니다.

메시지 체이닝은 속도뿐 아니라 스왑 안전성에도 영향을 미치나요? 이는 안전성보다는 주로 지연 시간 및 사용자 경험(UX) 측면의 고려 사항입니다. TON의 아키텍처는 이러한 메시지 전달 모델을 대규모로 처리하도록 설계되었습니다. 표준 안전성 확보 방안(호가 확인, 최소 출력, 슬리피지)은 체인 길이와 관계없이 여전히 유효한 보호 조치입니다.