프로덕션 Web3
04 / 12
Cross-chain Swap
같은 체인 swap, 브릿지, cross-chain swap을 하나의 단계형 실행 경험으로 통합했습니다.
- 역할
- Frontend Lead
- 문제
- Source 트랜잭션 성공이 전체 크로스체인 의도 완료를 보장하지 않는 것이 핵심 문제였습니다.
- 전략
- 경로를 먼저 분류하고 필요한 각 단계를 독립 status와 reference로 표현했습니다. 브릿지 observation을 별도 신호로 다뤄 인프라 지연과 실행 실패에 서로 다른 안내를 제공했습니다.
- 성과
- 별도 swap과 브릿지 제품이 필요했던 흐름을 하나로 통합했습니다.
01
문제 정의
왜 이 문제를 해결해야 했는가
Cross-chain Swap은 경로 선택, 선택적 승인, source 실행, 브릿지, target 실행, 복구를 하나의 제품 흐름으로 구성합니다.
사용자와 시스템이 마주한 문제
선택한 경로에 따라 실행 단계의 수와 네트워크가 달라졌습니다.
Source 트랜잭션이 성공해도 브릿지 observer나 target 실행은 대기 중일 수 있었습니다.
사용자는 observer 지연과 실제 브릿지 실패를 구분할 수 있어야 했습니다.
프론트엔드 오너십
프론트엔드 아키텍처를 리드하고 핵심 경로, 실행, 상태, 복구 경험을 프로덕션 운영까지 구현했습니다.
체인, 토큰, pair, 경로 탐색
Swap, 브릿지, cross-chain mode 분류
Approve, source, 브릿지 observer, target 단계
트랜잭션 정보, 오류, analytics, 유지보수
02
해결 전략
프로덕션까지 이어지는 시스템 전략
경로를 먼저 분류하고 필요한 각 단계를 독립 status와 reference로 표현했습니다. 브릿지 observation을 별도 신호로 다뤄 인프라 지연과 실행 실패에 서로 다른 안내를 제공했습니다.
시스템 모델
경로 선택 결과에 따라 선택적 승인, source-chain 실행, 브릿지 observation, target-chain 실행, 완료 또는 복구 안내가 이어집니다.
제품 화면
주요 제품 화면
과거 제품 인터페이스입니다. 화면의 수치는 캡처 당시 UI 상태이며 현재 TVL, APY 또는 성과를 의미하지 않습니다.
주요 구현 결정
선택한 경로에 필요한 단계만 동적으로 구성했습니다.
Source와 target 트랜잭션을 독립적으로 추적했습니다.
브릿지 observer 상태를 on-chain receipt 성공과 분리해 조회했습니다.
사용자 거절을 영구 실패 화면이 아닌 재시도 가능한 상태로 되돌렸습니다.
03
성과
무엇이 달라졌고 무엇을 배웠는가
별도 swap과 브릿지 제품이 필요했던 흐름을 하나로 통합했습니다.
중간 성공을 최종 완료로 축약하지 않고 source와 target 진행을 보여줬습니다.
장기간 네트워크, RPC, 가격 API, 지갑, 보안 변화에 대응했습니다.
배운 점
크로스체인 UX는 부분 성공을 정직하게 모델링해야 합니다. 복구 안내는 예외 부록이 아니라 주요 흐름의 일부입니다.
지금이라면
브라우저 세션을 넘어 유지되는 process ID, 취소·backoff가 가능한 polling, 명시적 partial-success 상태, 정식 복구 액션을 적용하겠습니다.
사용 기술
공개 링크
함께 일하기