AMM과 유동성 풀: 주문서 없이 가격이 만들어지는 원리

AMM은 매수·매도 주문을 서로 맞추는 대신 스마트 계약의 유동성 풀과 가격 함수로 즉시 견적을 계산합니다. 대표적인 상수곱 풀에서는 두 자산 준비금의 곱을 유지하도록 교환량이 정해지며, 거래가 클수록 준비금 비율이 더 움직여 가격 영향이 커집니다.

호가 대신 준비금 곡선을 상대한다

주문서 거래는 특정 가격에 사고팔겠다는 주문을 모아 교차시킨다. AMM은 두 토큰이 예치된 계약에 가격 함수를 적용한다. 상수곱 모델 x·y=k에서 한 토큰 x가 풀로 들어오면 다른 토큰 y가 나가고, 수수료를 반영한 뒤 곱의 제약을 만족하도록 수량이 계산된다.

Uniswap v2 Core whitepaper는 pair 계약이 LP 자금을 보관하고 상수곱 공식을 사용하는 구조를 설명한다. 함수는 외부의 ‘정답 가격’을 알지 못한다. 현재 준비금 비율과 거래가 만든 이동만 반영한다.

풀의 현물 가격이 외부 시장과 벌어지면 차익거래자가 싼 쪽을 사고 비싼 쪽을 팔아 비율을 되돌린다. 따라서 AMM 가격 정렬은 오라클 선언이 아니라 거래자의 경제적 행동에 의존한다.

표시 가격과 평균 체결 가격은 다르다

거래 전 풀의 순간 가격은 아주 작은 추가 거래의 한계 가격에 가깝다. 실제 주문은 곡선을 따라 여러 가격점을 이동하므로 평균 체결 가격이 달라진다. 주문 규모가 준비금에 비해 클수록 차이가 커진다.

price impact는 자신의 주문이 풀 가격을 얼마나 움직이는지이고, slippage는 견적 시점과 실제 포함 시점 사이의 불리한 변화까지 포함하는 실행 결과 차이다. 인터페이스의 최소 수령량은 슬리피지 한도로 계산되므로 세 값을 같은 용어로 부르면 판단이 흐려진다.

수수료는 LP 지분 가치에 누적된다

상수곱 풀은 입력 토큰 일부를 수수료로 남겨 준비금을 늘릴 수 있다. LP는 풀 지분 토큰이나 포지션으로 준비금의 일정 몫을 청구한다. 수수료율과 프로토콜 몫은 버전·풀마다 다르므로 고정 숫자를 외우기보다 계약과 UI에서 확인한다.

높은 거래량이 곧 높은 순수익은 아니다. 가격 변화로 두 자산 구성 비율이 달라지고, 가스·재조정 비용과 비영구적 손실이 수수료보다 클 수 있다. APY 표시는 관측 기간과 토큰 가격 가정에 따라 변한다.

같은 토큰쌍에도 여러 풀이 존재한다

수수료 등급, 집중 유동성 범위, DEX 버전, 체인에 따라 같은 토큰쌍 풀이 여러 개 생긴다. 라우터는 한 풀 또는 여러 풀을 거치는 경로를 선택한다. 토큰 기호가 같아도 계약 주소가 다른 위조 토큰일 수 있다.

스왑 전 토큰 주소, 풀 주소, 준비금·TVL, 수수료 등급, 경로를 확인한다. 경로가 길면 각 풀 수수료와 가격 영향, 중간 토큰 위험이 더해진다. 승인 대상이 라우터인지 임의 계약인지도 확인한다.

• 토큰 계약 주소와 체인 확인
• 풀 주소·버전·수수료 등급 확인
• 예상 수령량과 최소 수령량 비교
• price impact와 경로별 풀 깊이 확인
• 승인 금액과 승인 대상 계약 확인

풀 가격을 오라클로 쓸 때 생기는 조건

한 블록의 순간 준비금 비율은 큰 거래나 플래시론으로 움직일 수 있다. 대출 계약이 이를 담보 가격으로 그대로 쓰면 공격자가 가격을 왜곡해 과도하게 빌릴 수 있다. 시간 가중 평균 가격은 여러 시점의 누적값을 이용해 순간 조작 비용을 높인다.

관측 창이 길면 조작 저항은 커질 수 있지만 빠른 시장 변화에 늦게 반응한다. 풀 유동성이 얕으면 긴 창도 충분하지 않을 수 있다. 어떤 풀과 기간을 쓰는지, 보조 피드와 편차 제한이 있는지 소비 계약에서 확인한다.

AMM은 가격을 발견하는 기계이면서 그 가격을 움직이는 주문을 동시에 받아들이는 풀이다.

JOBCOIN 해설

탐색기에서 스왑 한 건을 복원하는 법

거래 영수증의 Swap 이벤트에서 실제 입력·출력 수량을 읽고, 거래 직전과 직후 Sync 또는 준비금 상태를 비교한다. 라우터를 거쳤다면 내부 호출과 각 풀 이벤트를 순서대로 펼쳐 중간 토큰을 확인한다.

수수료와 토큰 decimals를 반영하지 않으면 계산이 맞지 않는다. fee-on-transfer나 리베이스 토큰은 표준 ERC-20 가정과 다르게 움직일 수 있다. 공식 라우터가 이를 지원하는지 문서를 확인한다.

견적 당시 블록과 체결 블록이 다르면 그 사이 다른 거래로 준비금이 바뀔 수 있다. 비교 기록에는 견적 시각·블록, 체결 블록, 실제 수량, 최소 수령량을 함께 남긴다.

풀의 준비금 숫자만 볼 때는 프로토콜 수수료가 켜졌는지와 실제 토큰 잔액이 내부 reserve 변수와 일치하는지도 확인한다. 누군가 토큰을 계약에 직접 보내면 balance와 기록된 reserve가 잠시 다를 수 있고, sync·skim 같은 함수가 이를 조정할 수 있다. 탐색기 잔액 하나만으로 즉시 교환 가능액을 계산하지 않는다.

자주 묻는 질문