Technical Research on Jeongseup Blog

Transformer에서 MCP와 Skill까지: AI 에이전트는 어떻게 생각하고 행동하는가?

Sat, 19 Sep 2026 00:00:00 +0000

요약:
CNN/RNN의 파편화를 끝낸 Transformer의 대통합, “방 안의 뇌"였던 LLM에게 손발을 달아주려다 실패한 1세대 플러그인, 그 한계를 극복한 오픈 표준 MCP(Model Context Protocol), 그리고 토큰 낭비 없이 전문 전술을 주입하는 **스킬(Skill)**의 진화 과정을 실제 통신 패킷과 시각화 아키텍처로 쉽게 풀어봅니다.

1. 프롤로그: 모든 데이터가 하나로 통합되던 순간 (Transformer 혁명)

과거 딥러닝 시절에는 데이터 형태에 따라 완전히 다른 모델과 수학 공식을 써야 했습니다.

이미지: 픽셀 격자 위를 훑는 3×3 필터 행렬 연산 (CNN)
텍스트: 이전 단어의 기억을 다음 상태로 넘기는 재귀 루프 (RNN/LSTM)

하지만 2017년 Transformer의 등장 이후, AI는 세상의 모든 데이터를 단 하나의 포맷, 즉 **‘토큰(Token)’**으로 통일해 버렸습니다.

💡 Example: 서로 다른 데이터가 토큰으로 바뀌는 실제 모습

① 텍스트의 토큰화 (BPE Tokenization)

1

"def calculate(price):" ──► [721, 14205, 7, 4923, 1313]

② 이미지의 토큰화 (Vision Transformer, ViT)

224×224 픽셀 이미지를 16×16 픽셀짜리 바둑판 조각(패치) 196개로 자른 뒤 일렬로 펼쳐 단어처럼 취급합니다.

1

[16x16 픽셀 패치 1개] ──► 1차원 펼치기 (768차원 실수 벡터) ──► [0.24, -0.81, 0.05, ...]

③ 결과: 다차원 공간에서의 “공통 의미 좌표” 수렴

1
2
3


Cosine Similarity( "고양이", "cat" ) ≒ 0.96 (거의 일치)
Cosine Similarity( "고양이", [고양이 털 사진 16x16 패치] ) ≒ 0.91 (의미 일치!)
Cosine Similarity( "고양이", "class Cat(Animal):" ) ≒ 0.88 (코드와도 일치!)

🏛️ Architecture 1: Transformer Multimodal Tokenization & Shared Latent Space

아래 다이어그램은 글자, 이미지 패치, 오디오가 단일 트랜스포머 어텐션 계층을 거쳐 공통 잠재 공간(Shared Latent Space)으로 수렴하는 구조를 보여줍니다.

🔍 인터랙티브 다이어그램 전체화면으로 보기 (줌/팬 & 가이드 뷰 지원)

📷 정적 다이어그램 이미지로 보기

2. “방 안의 천재"에게 손발을 달아주려던 1세대 시도: 플러그인(Plugin)의 실패

똑똑해진 LLM도 혼자서는 방 안을 벗어날 수 없었습니다. 모델은 오직 “텍스트를 받아 다음 텍스트를 출력하는 수학 함수"였기 때문입니다. 이때 등장한 1세대 시도가 **2023년의 ‘ChatGPT Plugins’**였습니다.

💡 Example: 과거 플러그인의 구조적 한계 (`ai-plugin.json`)

1
2
3
4
5


{
 "schema_version": "v1",
 "name_for_model": "autocad",
 "api": { "type": "openapi", "url": "https://api.my-cloud.com/openapi.yaml" }
}

1
2
3
4
5
6
7
8
9


[사용자] "내 맥북에 켜진 AutoCAD에 사각형 그려줘."
 │
 ▼ (1) ChatGPT 클라우드가 플러그인 API 호출 시도
OpenAI Server ──► HTTP POST https://api.my-cloud.com/draw
 │
 ▼ (2) "내 맥북의 로컬 AutoCAD를 어떻게 부르지?"
클라우드 서버는 사용자의 개인 맥북 사설망(192.168.0.x)이나 COM 포트에 접속 불가!
 │
 ❌ 결과: 로컬 PC 제어 불가능 (클라우드 SaaS만 호출 가능)

3. 2세대 표준화 혁명: MCP (Model Context Protocol) — AI의 USB-C

Anthropic이 오픈소스로 공개한 MCP는 도구를 클라우드가 아닌 사용자의 로컬 컴퓨터에서 독립 프로세스로 실행하도록 하여 이 한계를 정면으로 돌파했습니다.

💡 Example: AI와 로컬 앱 사이의 실제 통신 패킷 (JSON-RPC)

① AI ➔ MCP Server (Request):

1
2
3
4
5
6
7
8
9


{
 "jsonrpc": "2.0",
 "method": "tools/call",
 "params": {
 "name": "draw_line",
 "arguments": { "start": [0, 0], "end": [500, 0], "layer": "Wall" }
 },
 "id": 1
}

② MCP Server ➔ 로컬 AutoCAD 실행 후 AI 응답 (Response):

1
2
3
4
5
6
7


{
 "jsonrpc": "2.0",
 "result": {
 "content": [{ "type": "text", "text": "Success: Line Entity #A284 created on 'Wall'." }]
 },
 "id": 1
}

4. 손발이 생겼는데 왜 또 ‘스킬(Skill)‘이 필요할까?

도구(MCP)만 쥐어준다고 일을 잘하지는 않습니다.
회사 규칙(Git Flow), 커밋 컨벤션(Conventional Commits), 도면 레이어 규칙을 모르면 엉뚱하게 도구를 쓰기 때문입니다.

스킬은 모든 규칙을 시스템 프롬프트에 넣어 토큰을 낭비하는 대신, **필요한 순간에만 전문 매뉴얼(SKILL.md)을 대화 컨텍스트에 동적 주입(Progressive Disclosure)**합니다.

🏛️ Architecture 2: Plugin vs MCP vs Skill 엔드투엔드 워크플로우

아래 다이어그램은 상단의 Skill 주입 흐름, 중앙의 에이전트 판단, 그리고 하단의 **MCP 로컬 실행 (AutoCAD/Figma)**과 Legacy Plugin의 차이를 한눈에 보여줍니다.

🔍 인터랙티브 다이어그램 전체화면으로 보기 (Trace 애니메이션 및 뷰 전환 지원)

📷 정적 다이어그램 이미지로 보기

5. 실제 프롬프트 백엔드에서는 무슨 일이 일어나는가?

사용자가 채팅창에 입력한 글은 단 한 줄이지만, 런타임은 배후에서 스킬을 결합하여 거대한 프롬프트로 확장(Augment)해 LLM에 전달합니다.

사용자가 입력한 것:

“새로운 로그인 기능 커밋하고 PR 올려줘. /git-workflow”

실제 LLM API로 전달되는 HTTP Payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


{
 "model": "claude-3-7-sonnet",
 "messages": [
 {
 "role": "system",
 "content": "당신은 AI 코딩 어시스턴트입니다..."
 },
 {
 "role": "system",
 "name": "injected_skill_instructions",
 "content": "=== [DYNAMIC SKILL LOADED: git-workflow] ===\n1. 커밋 전 반드시 npm test 통과 여부를 검증할 것.\n2. 커밋 메시지는 'feat(auth): ...' 형식을 준수할 것.\n3. main에 직접 푸시하지 말고 feature/ 브랜치를 생성할 것.\n============================================"
 },
 {
 "role": "user",
 "content": "새로운 로그인 기능 커밋하고 PR 올려줘."
 }
 ],
 "tools": [{ "name": "mcp_git_cli", "description": "로컬 git 명령어 실행" }]
}

6. 결론: 2026 에이전트 아키텍처의 완성 공식

$$\text{완전한 AI 에이전트} = \text{Transformer (두뇌)} + \text{Skill (전술/SOP)} + \text{MCP (손발/도구)}$$

Transformer: 텍스트, 코드, 이미지를 단일 토큰 공간에서 해석하는 거대한 만능 두뇌
Skill: 토큰을 낭비하지 않고 필요할 때만 전문가 매뉴얼을 뇌에 주입하는 동적 전술 지침(SOP)
MCP: 내 컴퓨터의 OS, 로컬 파일, CAD, Figma, DB를 직접 조종하는 표준화된 인터페이스 (USB-C)

이 세 요소가 결합될 때 비로소 모델은 단순한 챗봇을 넘어, 현실 세계의 소프트웨어와 엔지니어링 문제를 스스로 해결하는 진정한 에이전트로 진화합니다.

Building a Leverage Position Preview for DeFi on Sui

Fri, 27 Feb 2026 00:00:00 +0000

How I built previewLeverage — a read-only preview engine that calculates leveraged lending position metrics across Suilend, Navi, and Scallop, without executing any on-chain transaction.

Team: curg-13 | SDK: defidash-sdk

Why Preview Before Leverage?

In DeFi lending, leverage means borrowing against your collateral to amplify your position. A 2x leverage on $100 of SUI gives you $200 total exposure — potentially doubling your returns, but also your risk.

Before users click “Confirm”, they need to know:

How much will be borrowed via flash loan?
What’s the liquidation price?
What’s the expected annual return (Net APY)?
How far can the price drop before liquidation?

That’s what previewLeverage computes — entirely off-chain, using real-time protocol data.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


const preview = await sdk.previewLeverage({
 protocol: LendingProtocol.Suilend,
 depositAsset: 'SUI',
 depositValueUsd: 100,
 multiplier: 2.0,
});

// preview.netApy → 2.33%
// preview.liquidationPrice → $0.63
// preview.priceDropBuffer → 33%

Glossary: Lending Protocol Concepts

If you’re a developer without DeFi background, here’s what you need to know. I’m also studying these concepts in depth — check the Lending Protocol Study series for worked examples:

Day 1: DeFi 렌딩의 핵심 개념과 아키텍처 — Pool-based 중개, Share-Based Accounting, Scaled Balance 패턴
Day 2: Compound V2 Deep Dive와 Aave V3 아키텍처 — Fresh 패턴, Mantissa 연산, 비트맵 스토리지 최적화

LTV (Loan-to-Value)

LTV is the maximum percentage of your collateral’s value that you can borrow.

$$\text{LTV} = \frac{\text{Borrowed Value}}{\text{Collateral Value}}$$

If SUI has a 70% LTV on Suilend, depositing $100 of SUI lets you borrow up to $70 of USDC. Each protocol sets different LTV ratios per asset — riskier assets get lower LTV.

Protocol	SUI LTV	XBTC LTV
Suilend	70%	60%
Navi	75%	67%
Scallop	85%	75%

For more details on how Health Factor works with LTV, see Lending Protocol Study Day 1 — the “Share-Based Accounting” section explains why each protocol tracks collateral differently.

Liquidation Threshold (LT)

Liquidation Threshold is the LTV level at which your position gets liquidated. It’s always higher than the borrow LTV, creating a safety buffer.

1
2
3


Borrow LTV: 70% → You can borrow up to 70%
Liq. Threshold: 75% → Liquidation triggers at 75%
Safety buffer: 5%

When the market price drops and your position’s actual LTV exceeds the liquidation threshold, a liquidator can repay part of your debt and claim your collateral at a discount.

Liquidation mechanics are a deep topic — the Lending Protocol Study series covers Compound V2’s liquidateBorrowFresh() and Aave V3’s architecture in detail.

Max Multiplier

Derived directly from LTV:

$$\text{Max Multiplier} = \frac{1}{1 - \text{LTV}}$$

With 70% LTV → max 3.33x leverage. With 85% LTV → max 6.67x. This is a hard protocol limit — you physically cannot borrow more than what the collateral factor allows.

Flash Loan

A flash loan is an uncollateralized loan that must be borrowed and repaid within a single atomic transaction. If you don’t repay, the entire transaction reverts as if it never happened.

In our leverage strategy, the flow is:

Flash loan USDC from Scallop
Swap USDC → deposit asset (e.g., SUI)
Deposit all collateral to lending protocol
Borrow USDC from protocol (using deposited collateral)
Repay flash loan

All 5 steps happen in one Sui Programmable Transaction Block (PTB). If step 5 fails, everything reverts.

For more on why Sui’s PTB model is ideal for this — see DefiDash Journal Day 1 where we compare PTB-based atomic leverage vs EVM Flash Loan patterns.

Supply APY & Borrow APY

Supply APY: What you earn by depositing assets. Composed of base interest + reward tokens (e.g., sSUI, DEEP).
Borrow APY: What you pay for borrowing. Some protocols give borrowing incentives (rebates).
Net APY: The leveraged return on your equity.

$$\text{Net APY} = \frac{\text{Total Position} \times \text{Supply APY} - \text{Debt} \times \text{Borrow APY}}{\text{Initial Equity}}$$

With 2x leverage: if supply APY > borrow APY, your returns are amplified. If not, you’re paying more than you earn (negative Net APY).

The interest rate models behind these APYs (JumpRateModel, utilization curves) are covered in Lending Protocol Study Day 1 and Day 2. Especially the Mantissa-based fixed-point arithmetic in Day 2 is directly relevant to how we parse on-chain rate data.

Liquidation Price

The asset price at which your position hits the liquidation threshold:

$$\text{Liquidation Price} = \frac{\text{Total Debt}}{\text{Total Collateral Amount} \times \text{Liquidation Threshold}}$$

For a $100 SUI position at 2x leverage on Suilend (LT = 75%):

Debt = $100, Total collateral = ~52.6 SUI (at $3.80)
Liquidation Price = $100 / (52.6 × 0.75) ≈ $2.53
That’s a ~33% price drop buffer from current price

How It’s Built

Architecture

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


previewLeverage(params)
 │
 ├─ 1. Resolve coin type ('SUI' → '0x2::sui::SUI')
 ├─ 2. Fetch risk params from protocol adapter
 │ └─ getAssetRiskParams(coinType) → { ltv, liquidationThreshold, maxMultiplier }
 ├─ 3. Validate multiplier ≤ maxMultiplier
 ├─ 4. Fetch current price from 7k Protocol aggregator
 │
 ├─ 5. Position calculation
 │ ├─ flashLoanUsdc = equity × (multiplier − 1) × 1.02 buffer
 │ ├─ totalPositionUsd = equity × multiplier
 │ └─ ltvPercent = debt / totalPosition × 100
 │
 ├─ 6. Liquidation calculation
 │ ├─ liquidationPrice = debt / (collateralAmount × LT)
 │ └─ priceDropBuffer = (1 − liqPrice / currentPrice) × 100
 │
 ├─ 7. APY calculation
 │ ├─ Supply APY: base + reward (per protocol adapter)
 │ ├─ Borrow APY: gross − rebate (per protocol adapter)
 │ └─ Net APY = (position × supplyAPY − debt × borrowAPY) / equity
 │
 └─ 8. Swap slippage estimation via 7k DEX aggregator quote

Multi-Protocol Adapter Pattern

Each lending protocol (Suilend, Navi, Scallop) implements the ILendingProtocol interface, and the preview engine queries them through a unified API:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


interface ILendingProtocol {
 getAssetRiskParams(coinType: string): Promise<{
 ltv: number;
 liquidationThreshold: number;
 maxMultiplier: number;
 }>;
 getAssetApy(coinType: string): Promise<{
 supplyApy: number;
 rewardApy: number;
 borrowApy: number;
 }>;
 // ... deposit, borrow, withdraw, etc.
}

The same previewLeverage call works across all three protocols — just change the protocol parameter:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Compare leverage across protocols
for (const protocol of ['suilend', 'navi', 'scallop']) {
 const preview = await sdk.previewLeverage({
 protocol,
 depositAsset: 'SUI',
 depositValueUsd: 100,
 multiplier: 2.0,
 });
 console.log(`${protocol}: Net APY ${(preview.netApy * 100).toFixed(2)}%`);
}

This adapter pattern follows the same principle as Aave V3’s modular architecture — separation of concerns with a thin routing layer. The Day 2 study covers how Aave V3 uses delegatecall + Library pattern to achieve a similar pluggable design.

Data Sources

Data	Source	Notes
Asset price	7k Protocol `getTokenPrice`	Real-time DEX aggregated price
LTV / LT	Protocol on-chain state	Suilend `RateLimiterConfig`, Navi `ReserveData`, Scallop `risk_models`
Supply/Borrow APY	Protocol SDK + on-chain query	Includes reward token APY
Flash loan fee	Scallop `FLASHLOAN_FEES_TABLE`	Currently 0% for USDC
Swap slippage	7k Protocol `quote()`	Real-time DEX routing

Challenges & Bugs Fixed

Reward APY showing 3700% instead of 1.46%

Suilend stores reward coin types without the 0x prefix internally (e.g., deeb7a4...::deep::DEEP). When we passed this to the 7k price API, it returned 0. The fallback code then used the deposit asset’s price ($67,987 for LBTC) as a proxy for the reward token (DEEP at $0.027), inflating the reward APY to 3700%.

Fix: normalize the coin type with 0x prefix before price lookup, and skip the reward if price is still unavailable.

1
2
3
4
5
6
7
8


// Before (broken)
const rewardPrice = await getTokenPrice(rewardCoinType); // returns 0
// Fallback: uses LBTC price → 3700% APY

// After (fixed)
const normalizedReward = normalizeCoinType(rewardCoinType);
const fetchedPrice = await getTokenPrice(normalizedReward);
if (fetchedPrice <= 0) continue; // skip this reward

Scallop risk params not accessible via SDK

Scallop’s TypeScript SDK doesn’t expose risk_models data. We had to query the on-chain risk_models dynamic fields directly using suiClient.getDynamicFieldObject() to extract LTV and liquidation threshold values.

Verified Results (2026-02-26, Mainnet)

SUI 2x Leverage

	Suilend	Navi	Scallop
Asset LTV	70%	75%	85%
Liq. Threshold	75%	70%	90%
Max Multiplier	3.33x	4.00x	6.67x
Liq. Price	$0.63	$0.68	$0.53
Price Drop Buffer	33%	29%	44%
Supply APY	2.89%	2.97%	2.98%
Borrow Net APY	3.45%	4.57%	5.80%
Net APY	2.33%	1.37%	0.15%

XBTC 2x Leverage

	Suilend	Navi	Scallop
Asset LTV	60%	67%	75%
Supply APY	3.78%	6.73%	0.00%
Net APY	4.10%	8.88%	-5.80%

The negative Net APY on Scallop XBTC means borrowing costs exceed supply earnings — leverage actually loses money in that case.

What’s Next

leverage() — Actually execute the leveraged position on-chain
deleverage() — Close/reduce a leveraged position (flash loan → repay debt → withdraw → swap → repay)
previewDeleverage() — Preview the unwinding process
Cross-protocol position comparison dashboard

DefiDash Technical Journal Day 1: 프로젝트 킥오프와 Sui 렌딩 생태계 분석

Fri, 27 Feb 2026 00:00:00 +0000

DefiDash 개발 과정을 기록하는 테크니컬 저널 시리즈. Day 1에서는 프로젝트의 동기와 목표, Sui 생태계의 렌딩 프로토콜 현황, 그리고 레버리지 렌딩 어그리게이터의 아키텍처 설계를 다룬다.

Team: curg-13

왜 DefiDash인가

DeFi 렌딩 시장은 이미 성숙해있다. Ethereum에는 Aave, Compound, MakerDAO가 있고, 다른 체인에도 포크된 프로토콜들이 넘쳐난다. 그런데 Sui 생태계는 다르다.

Sui는 Move 기반의 Object-centric 모델을 사용한다. EVM의 Account-based 모델과 근본적으로 다른 패러다임이다. 이 차이는 DeFi 프로토콜 설계에도 영향을 미친다:

Object Ownership: 자산이 계정이 아닌 오브젝트로 관리된다
Parallel Execution: 독립적인 오브젝트 간 트랜잭션은 병렬 실행 가능
PTB (Programmable Transaction Blocks): 하나의 트랜잭션에서 여러 DeFi 연산을 원자적으로 실행

특히 PTB는 레버리지 렌딩에 결정적이다. EVM에서는 Flash Loan으로 여러 트랜잭션을 하나로 묶지만, Sui에서는 PTB로 네이티브하게 복합 연산이 가능하다.

문제는 Sui의 렌딩 프로토콜들이 아직 파편화되어 있다는 것이다. 각 프로토콜마다 다른 인터페이스, 다른 이자율 모델, 다른 담보 비율. 일반 사용자가 최적의 레버리지 전략을 찾는 것은 사실상 불가능하다.

DefiDash는 이 문제를 해결한다. Sui 생태계의 렌딩 프로토콜들을 하나의 인터페이스로 어그리게이트하여, 사용자에게 최적의 레버리지 전략을 제공한다.

프로젝트 구조

curg-13 팀으로 3개의 레포지토리를 구성했다.

1
2
3
4


curg-13/
├── defidash-sdk # 핵심 SDK - 프로토콜 통합 레이어
├── defidash-frontend # 사용자 facing DApp
└── defidash-website # 랜딩 페이지 & 문서

defidash-sdk

프로토콜 어그리게이션의 핵심이다. 각 렌딩 프로토콜의 인터페이스를 추상화하고, 통합된 API를 제공한다.

주요 책임:

각 프로토콜의 온체인 데이터 조회 (이자율, 담보 비율, 유동성)
레버리지 포지션 시뮬레이션
PTB 구성 및 트랜잭션 빌딩
최적 경로 계산 (어떤 프로토콜 조합이 가장 유리한지)

defidash-frontend

일반 사용자를 위한 DApp이다. 복잡한 레버리지 전략을 직관적인 UI로 제공한다.

핵심 UX 목표:

원클릭 레버리지 포지션 오픈/클로즈
실시간 Health Factor 모니터링
프로토콜 간 이자율 비교 대시보드

defidash-website

프로젝트 소개와 문서를 담는 마케팅 사이트다.

Sui 렌딩 생태계 현황

현재 Sui에서 활동 중인 주요 렌딩 프로토콜들을 정리했다.

Protocol	Type	Key Feature
Scallop	Pool-based	Sui 최초의 렌딩 프로토콜, sCoin 모델
NAVI Protocol	Pool-based	Dynamic interest rate, Flash Loan 지원
Suilend	Pool-based	Solend 팀의 Sui 버전, Obligation 기반
Bucket Protocol	CDP-based	BUCK 스테이블코인 발행

EVM 생태계와 비교하면 아직 초기 단계지만, 각 프로토콜이 Sui의 특성을 살린 독자적인 설계를 가지고 있다. 이 차이점이 곧 어그리게이션의 가치다.

아키텍처 설계: 어그리게이션 레이어

레버리지 렌딩 어그리게이터의 핵심은 Protocol Adapter Pattern이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


사용자 → DefiDash Frontend
 ↓
 DefiDash SDK
 ↓
 ┌─────────┼─────────┐
 ↓ ↓ ↓
 Scallop NAVI Suilend ← Protocol Adapters
 Adapter Adapter Adapter
 ↓ ↓ ↓
 └─────────┼─────────┘
 ↓
 Sui Network

각 프로토콜 Adapter는 동일한 인터페이스를 구현한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


interface LendingProtocolAdapter {
 // 프로토콜 상태 조회
 getMarkets(): Promise<Market[]>;
 getInterestRates(market: string): Promise<InterestRate>;
 getUserPosition(address: string): Promise<Position>;

 // 트랜잭션 빌딩
 buildSupplyTx(params: SupplyParams): TransactionBlock;
 buildBorrowTx(params: BorrowParams): TransactionBlock;
 buildLeverageTx(params: LeverageParams): TransactionBlock;
}

이 패턴의 장점은 새로운 프로토콜 추가가 Adapter 하나만 구현하면 된다는 것이다. SDK의 코어 로직이나 프론트엔드를 수정할 필요 없다.

레버리지 렌딩의 원리

일반 사용자를 위해 레버리지 렌딩이 어떻게 작동하는지 정리한다.

기본 개념

담보 예치: 1,000 USDC를 렌딩 프로토콜에 담보로 예치
대출: 담보 대비 700 SUI를 대출 (LTV 70%)
재예치: 대출받은 SUI를 다시 담보로 예치
반복: 이 과정을 반복하면 실효 레버리지가 증가

1
2
3
4
5
6


초기 자본: 1,000 USDC
1차 대출: 700 SUI → 재예치
2차 대출: 490 SUI → 재예치
3차 대출: 343 SUI → 재예치
...
실효 노출: ~3,333 USDC 상당 (약 3.3x 레버리지)

Sui PTB의 이점

EVM에서는 이 과정을 Flash Loan + 여러 컨트랙트 호출로 구현해야 한다. 가스비도 높고 실패 리스크도 있다.

Sui의 PTB에서는 하나의 트랜잭션 블록 안에서 모든 단계를 원자적으로 실행할 수 있다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


const txb = new TransactionBlock();

// 1. 담보 예치
const receipt = txb.moveCall({ target: `${PROTOCOL}::deposit`, arguments: [...] });

// 2. 대출
const borrowed = txb.moveCall({ target: `${PROTOCOL}::borrow`, arguments: [...] });

// 3. 재예치 (대출 결과를 바로 사용)
txb.moveCall({ target: `${PROTOCOL}::deposit`, arguments: [borrowed, ...] });

// 하나의 트랜잭션으로 실행
await client.signAndExecuteTransactionBlock({ transactionBlock: txb });

Flash Loan 없이도 원자적 레버리지가 가능하다. 이것이 Sui에서 렌딩 어그리게이터를 만드는 핵심 이유다.

Day 1 정리

항목	결정 사항
프로젝트명	DefiDash
팀	curg-13
타겟 체인	Sui
핵심 기술	PTB 기반 레버리지 렌딩 어그리게이션
SDK 언어	TypeScript
아키텍처	Protocol Adapter Pattern
첫 통합 대상	Scallop, NAVI, Suilend

Next: Day 2

다음 저널에서는 실제 SDK 개발을 시작한다.

Sui 렌딩 프로토콜 온체인 데이터 구조 분석
Protocol Adapter 구현 (Scallop부터)
PTB 기반 레버리지 트랜잭션 빌딩

DefiDash의 전체 코드는 curg-13 조직에서 확인할 수 있다.

Validator Reward Deep Dive Series

Sat, 03 Jan 2026 00:00:00 +0000

Context & Motivation

This series was originally authored during my tenure at Cosmostation, working with the Validator Team. The primary goal of this research was to provide a technical foundation for developing in-house validator monitoring and reward management tools.

To build robust infrastructure, we needed to go beyond the surface and understand the exact mathematical and programmatic flow of rewards across different blockchain architectures. This series documents that journey, covering Cosmos, Sui, Kaia, and Namada.

Series Index

1. Walrus: The Secret of Staking Rewards

Focus: Walrus 프로토콜의 보상 분배 메커니즘, 에포크 변경 및 환율 계산 로직 분석.
Key Insight: initiate_epoch_change와 process_pending_stake를 심층 분석하여 스테이킹 시점과 출금 시점의 환율 차이로 보상이 결정되는 과정을 설명합니다.

2. Sui: How are Epoch Rewards Delivered to Stakers?

Focus: Sui 프로토콜의 네이티브 스테이킹 보상 메커니즘과 sui_system Move 패키지를 통한 에포크 단위 보상 분배.
Key Insight: StakingPool의 환율(Exchange Rate)이 보상을 통해 어떻게 우상향하는지 설명하고, 스테이킹 및 출금 시점의 환율 차이로 보상이 산정되는 원리를 다룹니다.

3. Cosmos: How do Inflation and Fees become Delegator Rewards?

Focus: x/mint, x/auth, FeeCollector, x/distribution, x/staking 모듈 간의 상호작용을 통한 보상 생성 및 분배의 유기적인 과정.
Key Insight: 인플레이션과 수수료가 FeeCollector에 모여 검증인 풀로 이동하고, ‘누적 보상 비율(Cumulative Reward Ratio)‘과 지분(Share)을 기반으로 델리게이터에게 최종 분배되는 F1 모델의 흐름을 설명합니다.

4. Kaia: Staking Rewards in Public Delegation Contract

Focus: PublicDelegation.sol 시스템 컨트랙트와 ERC-20 기반 지분(Share) 토큰을 중심으로 한 스테이킹 보상 메커니즘.
Key Insight: stake() 호출 시 자동 재예치(Auto-compounding)가 발생하여 풀의 총 KAIA가 증가하고, 이로 인해 지분 가치가 상승(Value Accrual)하여 보상이 실현되는 원리를 설명합니다.

5. Namada: PoS Staking and Inflation in Namada

Focus: 나마다(Namada)의 에포크 기반 PoS 인플레이션과 ‘Reward Product’ 방식을 이용한 독창적인 보상 기록 메커니즘.
Key Insight: 매 에포크마다 위임 지분당 보상 비율인 reward_product가 기록되며, 이를 통해 델리게이터의 보상이 위임량 * reward_product의 합으로 산정되는 원리를 설명합니다.

Reflection

Building tools for a top-tier validator team requires a “don’t trust, verify” mindset toward protocol specifications. These articles served as the technical blueprint for our engineering team to ensure reward calculation accuracy and operational excellence.

I hope this archive remains a useful resource for anyone diving deep into the economics of Proof-of-Stake networks.

Validator Reward Deep Dive Series

Sat, 03 Jan 2026 00:00:00 +0000

Context & Motivation

Series Index

1. Walrus: The Secret of Staking Rewards

Focus: The reward distribution mechanism of the Walrus protocol, including epoch changes and exchange rate calculations.
Key Insight: deeply analyzes initiate_epoch_change and process_pending_stake to explain how rewards are determined by the exchange rate difference between staking and withdrawal.

2. Sui: How are Epoch Rewards Delivered to Stakers?

Focus: The native staking reward mechanism of the Sui protocol, driven by epoch changes and the sui_system Move package.
Key Insight: Explains how the StakingPool’s exchange rate tracks the compounding value of SUI rewards, allowing delegator rewards to be calculated based on the rate difference between staking and withdrawal.

3. Cosmos: How do Inflation and Fees become Delegator Rewards?

Focus: The organic interaction of x/mint, x/auth, FeeCollector, x/distribution, and x/staking modules to source, aggregate, and distribute rewards.
Key Insight: Explains the flow from sourcing (inflation/fees) to the FeeCollector, then to validator pools, and finally to delegators via share-based calculation using the ‘cumulative reward ratio’ (F1 Fee Distribution).

4. Kaia: Staking Rewards in Public Delegation Contract

Focus: The staking reward mechanism centered around the PublicDelegation.sol system contract and ERC-20 based share tokens.
Key Insight: Describes how stake() triggers auto-compounding, increasing the pool’s total KAIA while keeping shares constant, thus raising the share value (Value Accrual) which becomes the delegator’s reward.

5. Namada: PoS Staking and Inflation in Namada

Focus: Namada’s epoch-based PoS inflation and the unique ‘Reward Product’ mechanism for tracking rewards.
Key Insight: Explains how the reward_product (reward ratio per stake) is recorded each epoch, allowing delegator rewards to be calculated as the sum of delegated_amount * reward_product over the delegation period.

Reflection

I hope this archive remains a useful resource for anyone diving deep into the economics of Proof-of-Stake networks.

DefiDash 시작 계기: Defi Saver for Sui

Thu, 11 Dec 2025 00:00:00 +0000

CURG 13기 활동 중 DefiDash 프로젝트가 시작된 배경과, 레퍼런스인 Defi Saver를 분석한 기록.

Team: curg-13

1. 프로젝트 히스토리

이 프로젝트는 CURG(Crypto United Research Group)라는 한국 블록체인 스터디에서 출발했다. 퇴사 후 13기로 합류했고, 이번 기수의 활동기간은 2025.10.11부터 2026.3.28이었다. DefiDash는 2025.12부터 본격적으로 개발을 시작한 프로젝트다.

초기 방향 탐색

처음에는 Sui Stack(Walrus, Seal, Nautilus, DeepBook 등)을 활용해서 재미있는 것들을 만들어보려 했다. 하지만 팀원들과 나 모두 Sui Stack 자체에 크게 흥미를 잃었다.

간단히 써본 결과, 해당 스택은 커머셜한 Web2 비즈니스를 Web3화하는 방향에 초점이 맞춰진다고 느꼈기 때문이다.

EVM 생태계에서는 필요한 인프라를 유저(커뮤니티)가 직접 개발하고 비즈니스화하면서 상호작용하는 반면, Sui에서는 필요한 인프라를 재단 레벨에서 미리 구상하고 생태계 툴로 자리잡아둔 구조다. 블록체인을 구축하고 개발자를 유치하는 전략적 차이라고 생각한다.

방향성 좁히기

이후 팀원들과의 회의를 통해 초기 방향을 아래 3가지로 좁혔다.

Pendle to Sui + Lucky Gaming — 기존에 Walrus Haultout 해커톤에서 Sui random module을 활용해 나간 경험을 확장
Defi Saver to Sui — Sui에 렌딩 프로토콜이 여럿 있으니 이를 aggregation 하는 것으로 출발
Academic Research in Sui — 오픈소스 Move DeFi 컨트랙트를 분석하면서 EVM과 MoveVM 차이를 비교

약 2주간의 논의를 거쳐, 2025.12.11 시점에 Defi Saver for Sui로 방향을 결정지었다.

2. Defi Saver 분석

Defi Saver란?

Defi Saver를 간단히 말하면, crypto portfolio dashboard + leverage yield farming(looping) 플랫폼이다. 추후 포지션 규모가 크면 자동으로 포지션을 조절해주는 기능도 제공한다.

가령 담보로 맡긴 BTC가 급락하는 경우, liquidation을 방지하기 위해 leverage multiplier를 자동으로 줄여준다는 뜻이다.

Defi Saver 말고도 비슷한 crypto asset dashboard 서비스는 다양하다.

특장점

Safe(Gnosis) Smart Wallet 사용: 처음 접속 시 유저에게 Smart Wallet을 생성하도록 한다.
- Automation 기능 지원을 위해서이며, execTransaction 같은 여러 트랜잭션을 하나로 묶어서 실행하기 위함이다.
- 이걸 보고 Sui에서는 PTB가 네이티브하게 지원되니까 오히려 만들기 편하겠다는 생각을 했다.
Looping 레버리지: 유저가 BTC를 맡기면 LTV에 따라 최대 레버리지까지 USDC를 빌려서 → 그 금액으로 BTC를 다시 사서 → 재예치하는 looping 방식을 지원한다.
직관적인 UX: Liquidation price, 여러 리스크 팩터 등이 한눈에 보인다. 처음에는 별것 아닌 것 같았지만, 막상 만들어보니 이런 디테일한 정보를 잘 관리하고 UX로 풀어내는 게 쉽지 않다는 걸 뒤늦게 알게 되었다.

Defi Saver 직접 사용해보기

아래는 직접 써본 예시다.

가격이 변동함에 따라, 담보 자산(여기선 cbBTC) 상승 시 레버리지 효과를 가질 수 있게 된다.

기본적으로 내 EOA(MetaMask 지갑 주소)에서 호출한 컨트랙트 메소드는 다음과 같다. 해당 rollup tx 안에는 여러 로직이 포함되어 있는 구조다.

1
2
3
4
5


Function: execTransaction(
 address to, uint256 value, bytes data, uint8 operation,
 uint256 safeTxGas, uint256 baseGas, uint256 gasPrice,
 address gasToken, address refundReceiver, bytes signatures
)

Net Transfer로 보면 로직이 보다 명확해진다.

실제 트랜잭션: basescan.org/tx/0x0869a6…

참고로 Defi Saver에서는 Flash Loan으로 빌린 금액의 0.25%를 서비스 수수료로 받는 비즈니스 모델을 가진다.

포지션을 다음과 같이 preview 형태로도 제공해준다.

포지션을 종료하면 기존 로직을 역행하는 과정을 거친다. 기본적으로 looping 과정에서 Morpho Flash Loan을 사용한다.

Close position tx: basescan.org/tx/0xe04ccb…

3. 구조 분석

Leverage Max Multiplier

최대 레버리지 배수는 다음과 같이 결정된다.

$$\text{Max Multiplier} = \frac{1}{1 - \text{LTV}}$$

Leverage 내부 트랜잭션 구조

롤업된 트랜잭션을 의미별로 구조화하면 3가지 컴포넌트로 나뉜다.

Flash Loan — 레버리지에 필요한 초기 자금 확보
Swap — 빌린 스테이블코인을 담보 자산으로 교환
Deposit & Lending — 렌딩 프로토콜에 담보 예치 및 대출

4. DefiDash 프로젝트 구상

위 분석을 바탕으로, 이번 13기 과정에서는 leverage, deleverage(포지션 on/off) 정도만 지원하는 MVP를 만들기로 했다.

각 컴포넌트별로 Sui 생태계에서 사용할 프로토콜을 매핑하면 다음과 같다.

Flash Loan

레버리지 루핑에 필요한 스테이블코인을 어디서 빌려올 것인가?

Scallop
NAVI

Swap (Aggregator / DEX)

Flash Loan으로 빌려온 스테이블코인을 최적 비율로 담보 자산으로 교환할 곳은?

Aftermath
Cetus
7k Protocol

Deposit & Lending

레버리지 포지션의 유지 비용(Supply APR - Borrow APR)이 가장 저렴한 곳은?

Suilend
NAVI
Scallop
Bluefin

Flash Loan 출처가 Scallop이라고 해서 렌딩 프로토콜도 반드시 Scallop일 필요는 없다. 각 컴포넌트는 독립적으로 최적의 조합을 선택할 수 있다.

5. 프로젝트 목표 정의

목표: 3개 렌딩 프로토콜(Suilend, NAVI, Scallop)을 통합하는 leverage lending protocol aggregator 만들기.

최종 워크플로우

PTB 하나에 다음 5단계를 원자적으로 실행한다.

1
2
3
4
5


1. Flash Loan ← Scallop
2. Swap ← 7k Aggregator
3. Deposit ← Lending Protocol (Suilend / NAVI / Scallop)
4. Borrow ← 같은 Lending Protocol
5. Repay ← Scallop (Flash Loan 상환)

각 컴포넌트를 TypeScript SDK 레벨로 먼저 만들어보고, 필요하다면 컨트랙트도 파헤쳐보는 것으로 방향을 잡았다.

프로젝트 완성 후에는 실제 레버리지 포지션을 통해 서비스 이용의 수익성을 검증할 계획이다.

다음 글에서는 실제 SDK 개발에 착수한다. Sui 렌딩 프로토콜의 온체인 데이터 구조를 분석하고, Protocol Adapter 패턴을 설계한 과정을 다룬다.

DefiDash Journal Day 1: 프로젝트 킥오프와 Sui 렌딩 생태계 분석

DefiDash의 전체 코드는 curg-13 조직에서 확인할 수 있다.

Technical Research on Jeongseup Blog

Transformer에서 MCP와 Skill까지: AI 에이전트는 어떻게 생각하고 행동하는가?

1. 프롤로그: 모든 데이터가 하나로 통합되던 순간 (Transformer 혁명)

💡 Example: 서로 다른 데이터가 토큰으로 바뀌는 실제 모습

① 텍스트의 토큰화 (BPE Tokenization)

② 이미지의 토큰화 (Vision Transformer, ViT)

③ 결과: 다차원 공간에서의 “공통 의미 좌표” 수렴

🏛️ Architecture 1: Transformer Multimodal Tokenization & Shared Latent Space

2. “방 안의 천재"에게 손발을 달아주려던 1세대 시도: 플러그인(Plugin)의 실패

💡 Example: 과거 플러그인의 구조적 한계 (ai-plugin.json)

3. 2세대 표준화 혁명: MCP (Model Context Protocol) — AI의 USB-C

💡 Example: AI와 로컬 앱 사이의 실제 통신 패킷 (JSON-RPC)

① AI ➔ MCP Server (Request):

② MCP Server ➔ 로컬 AutoCAD 실행 후 AI 응답 (Response):

4. 손발이 생겼는데 왜 또 ‘스킬(Skill)‘이 필요할까?

🏛️ Architecture 2: Plugin vs MCP vs Skill 엔드투엔드 워크플로우

5. 실제 프롬프트 백엔드에서는 무슨 일이 일어나는가?

사용자가 입력한 것:

실제 LLM API로 전달되는 HTTP Payload:

6. 결론: 2026 에이전트 아키텍처의 완성 공식

Building a Leverage Position Preview for DeFi on Sui

Why Preview Before Leverage?

Glossary: Lending Protocol Concepts

LTV (Loan-to-Value)

Liquidation Threshold (LT)

Max Multiplier

Flash Loan

Supply APY & Borrow APY

Liquidation Price

How It’s Built

Architecture

Multi-Protocol Adapter Pattern

Data Sources

Challenges & Bugs Fixed

Reward APY showing 3700% instead of 1.46%

Scallop risk params not accessible via SDK

Verified Results (2026-02-26, Mainnet)

SUI 2x Leverage

XBTC 2x Leverage

What’s Next

Links

DefiDash Technical Journal Day 1: 프로젝트 킥오프와 Sui 렌딩 생태계 분석

왜 DefiDash인가

프로젝트 구조

defidash-sdk

defidash-frontend

defidash-website

Sui 렌딩 생태계 현황

아키텍처 설계: 어그리게이션 레이어

레버리지 렌딩의 원리

기본 개념

Sui PTB의 이점

Day 1 정리

Next: Day 2

Validator Reward Deep Dive Series

Context & Motivation

Series Index

1. Walrus: The Secret of Staking Rewards

2. Sui: How are Epoch Rewards Delivered to Stakers?

3. Cosmos: How do Inflation and Fees become Delegator Rewards?

4. Kaia: Staking Rewards in Public Delegation Contract

5. Namada: PoS Staking and Inflation in Namada

Reflection

Validator Reward Deep Dive Series

Context & Motivation

Series Index

1. Walrus: The Secret of Staking Rewards

2. Sui: How are Epoch Rewards Delivered to Stakers?

3. Cosmos: How do Inflation and Fees become Delegator Rewards?

4. Kaia: Staking Rewards in Public Delegation Contract

5. Namada: PoS Staking and Inflation in Namada

Reflection

DefiDash 시작 계기: Defi Saver for Sui

1. 프로젝트 히스토리

초기 방향 탐색

방향성 좁히기

2. Defi Saver 분석

Defi Saver란?

특장점

Defi Saver 직접 사용해보기

💡 Example: 과거 플러그인의 구조적 한계 (`ai-plugin.json`)