유니스왑에서 스왑 한 번 하려고 하니 슬리피지·MEV가 나오고, AAVE에서 스테이블코인 빌리려니 LTV·Health Factor·청산가가 따라온다.

이게 또 별 게 아니다 — 다 같은 개념을 다른 동네에서 다른 단어로 부르고 있을 뿐이다.

이 글은 블록체인 용어집에 다 못 담은 DeFi 전문 용어만 따로 묶은 거다. 한 번 정리해두면, 새 프로토콜 보다가 나오는 단어 90%는 여기서 찾아진다.

#1. DeFi란 — 일단 큰 그림

#DeFi (Decentralized Finance, 탈중앙 금융)

은행·증권사가 하는 일을 스마트 컨트랙트가 대신 하는 금융 시스템이다.

• 은행 → 대출 프로토콜 (Aave, Compound, Morpho)
• 증권사 → DEX (Uniswap, Curve, Aerodrome)
• 펀드 → 수익 파밍 프로토콜 (Yearn, Pendle)
• 보험사 → 온체인 보험 (Nexus Mutual)

핵심은 "중간 관리자 없음".

스마트 컨트랙트가 24시간 자동으로 돌고, 누구나 같은 조건으로 쓸 수 있다. KYC도 없고 영업시간도 없다.

#TVL (Total Value Locked)

해당 프로토콜에 묶여 있는 총 자산. DeFi 인기도의 핵심 지표.

"Aave TVL 200억 달러" = "Aave에 사용자들이 200억 달러 어치 자산을 맡겨두고 있다"는 뜻. DeFiLlama가 표준 집계 사이트.

TVL이 크면 무조건 안전한가?

아니다. TVL은 "신뢰가 쌓인 정도"의 지표지, 안전 보증이 아니다. 2022년 Anchor(Terra)의 TVL은 폭락 직전 200억 달러였다.

TVL이 크면 더 큰 표적이 되기도 한다. 해커한테는 한 방에 큰 돈이 보이는 곳이 매력적인 사냥터.

#2. DEX와 거래 — 자동으로 돌아가는 시장

#DEX (Decentralized Exchange)

회사 없이 스마트 컨트랙트가 매매를 처리하는 거래소. 유니스왑, Curve, Aerodrome, Raydium 등.

업비트·바이낸스(CEX) 대비 차이:

#AMM (Automated Market Maker, 자동 시장 조성자)

DEX의 매매 알고리즘. 수식 하나로 자동 가격 결정.

기본 형태: x * y = k. ETH 1,000개와 USDC 200만 개가 있는 풀이라면, 둘의 곱(k = 2,000,000,000)이 항상 일정하게 유지되도록 환율이 자동 조정된다.

#CLOB (Central Limit Order Book)

호가창 기반 매매 방식. 주식 거래소가 쓰는 그 방식이다.

기존 DEX는 거의 다 AMM이었는데, 2024–2026년에 CLOB DEX가 다시 떠오르고 있다. dYdX, Hyperliquid, Dango 같은 곳들. 슬리피지가 작고 MEV가 어려워서 트레이더 친화적이다.

#LP (Liquidity Provider, 유동성 공급자)

풀에 자기 자산을 넣어주는 사람.

ETH/USDC 풀에 ETH 1개 + USDC 2,000달러를 같이 넣어두면 → 다른 사람들이 그 풀에서 거래할 때마다 발생하는 수수료의 일부를 지분만큼 받는다. 보통 거래액의 0.05–1%가 풀에 쌓이고 LP들에게 분배된다.

LP는 왜 자기 돈을 풀에 넣어줄까?

수수료 수익 + 보상 토큰 때문이다.

ETH/USDC 같은 거래량 큰 풀은 연 5–30% 수익이 난다. 거기에 프로젝트가 자기 토큰까지 보상으로 추가로 주면(=유동성 마이닝) 수익률이 더 올라간다.

단, 공짜는 아니다. 다음에 나오는 임퍼머넌트 로스 때문.

#슬리피지 (Slippage)

주문 시 가격 ≠ 체결 시 가격.

풀에서 큰 거래를 하면 그 거래 자체가 풀의 비율을 바꿔서 가격이 움직인다. 풀이 작을수록, 거래액이 클수록 슬리피지가 크다.

DEX에서 거래할 때 "슬리피지 한도 0.5%"를 설정하는 게 그 때문 — 그보다 더 차이 나면 거래 자체가 취소된다.

#MEV (Maximal Extractable Value)

블록 생성자(또는 봇)가 거래 순서를 조작해서 뜯어가는 이익.

대표적인 패턴 두 가지:

• 샌드위치 공격 — 누가 큰 매수 주문 보내면, 봇이 그 앞에 자기 매수 + 뒤에 자기 매도를 끼워서 차익. 피해자는 더 비싸게 사게 됨.
• 프론트러닝 — 누가 좋은 거래 보내면 가스비 더 내고 먼저 끼어들어서 그 자리 차지.

이걸 막으려고 MEV 보호 RPC (Flashbots Protect, MEV Blocker), 인텐트 기반 DEX (CowSwap, UniswapX) 같은 게 등장했다.

#어그리게이터 (Aggregator)

여러 DEX를 동시에 보고 가장 좋은 가격 경로를 찾아주는 서비스.

• 1inch, ParaSwap, Odos — 메이저 어그리게이터
• CowSwap — 인텐트 기반, MEV 방어 자동
• Jupiter — 솔라나의 표준 어그리게이터

직접 유니스왑 가지 말고 어그리게이터 쓰는 게 보통 더 싸다.

#3. 유동성 공급 — LP의 세계

#풀 (Liquidity Pool)

LP들이 자산을 넣는 공동 저금통. 거래자들이 이 풀에 대고 매매하고, 발생한 수수료를 LP들이 나눠 가진다.

대표적 풀:

• ETH/USDC — 가장 거래량 많은 풀
• stablecoin pool (USDC/USDT/DAI) — 변동성 적고 수수료 안정
• 상관관계 풀 (stETH/ETH) — Curve 특화

#임퍼머넌트 로스 (Impermanent Loss, IL)

LP의 가장 큰 리스크.

풀에 넣은 두 토큰의 가격 비율이 변하면, 그냥 들고만 있었을 때보다 금액이 적어지는 현상이다.

예시:

• ETH/USDC 풀에 ETH 1개 + USDC 2,000달러 넣음 (총 4,000달러어치)
• ETH 가격이 2,000 → 4,000달러로 2배 뜀
• 풀 안에서는 자동 매매로 ETH가 일부 USDC로 바뀜 → ETH 약 0.71개 + USDC 약 2,830달러 (총 약 5,660달러)
• 그냥 들고 있었으면? ETH 1개 + USDC 2,000달러 = 6,000달러
• 차액 ≈ -340달러 = IL

이 차액이 LP 수수료 수익보다 크면 손해다.

변동성 큰 페어일수록 IL이 커서, 변동성 큰 알트코인 페어 LP는 손해 보는 경우가 흔하다.

#집중 유동성 (Concentrated Liquidity)

Uniswap v3에서 도입. 특정 가격 구간에만 유동성을 몰아서 자본 효율을 높이는 방식.

• ETH가 $2,000–$3,000 구간에서만 거래된다고 보면, 그 구간에만 자기 유동성을 배치
• 그 구간 안에서 거래되면 수수료를 더 많이 받음
• 가격이 그 구간을 벗어나면 → 한쪽 토큰만 남고 수수료 못 받음

수익률이 더 높은 대신 관리가 필요하다. 가격이 구간 벗어나면 다시 조정해줘야 하니까.

#JIT 유동성 (Just-In-Time)

큰 거래가 들어올 때 그 직전에 유동성을 넣었다가 거래 끝나면 바로 빼는 봇 전략.

일반 LP의 수수료를 빼앗아 가는 효과가 있어서 비판도 많다.

#4. 대출·청산 — 담보 잡고 빌리는 구조

#대출 프로토콜 (Lending Protocol)

자산을 예치하면 이자를 받고, 담보 잡고 빌리면 이자를 낸다.

• Aave, Compound, Morpho, Spark — 메이저 대출 프로토콜
• 예치 금리 (Supply APR) < 대출 금리 (Borrow APR)
• 차익이 프로토콜 수익

#LTV (Loan-To-Value, 담보 비율)

담보 가치 대비 빌릴 수 있는 비율.

ETH 1개(=$3,000) 담보로 LTV 75%까지 자산을 빌릴 수 있다면 → 최대 $2,250 USDC 대출 가능.

#Health Factor (건강 지수)

현재 포지션이 청산까지 얼마나 여유 있는지 한 숫자로 보여주는 지표.

ETH가 떨어지면 담보 가치가 줄어서 HF도 떨어진다. HF가 1.2 아래면 위험 신호.

#청산 (Liquidation)

담보 가치가 임계치 아래로 떨어지면, 누군가가 부채를 대신 갚아주고 담보를 할인된 가격으로 가져간다.

• 보통 담보의 5–10% 페널티 발생 → 청산자가 이걸 가져감
• 청산은 봇이 거의 다 함. 0.1초 단위로 모니터링하다가 즉시 실행
• 청산 봇끼리도 경쟁이라 가스비 전쟁 발생

#플래시 론 (Flash Loan)

한 트랜잭션 안에서 빌리고 갚으면 이자 없이 무한히 빌릴 수 있는 대출.

DeFi의 가장 독특한 기능 중 하나다. 트랜잭션 종료 전에 갚지 못하면 그 트랜잭션 자체가 무효화되는 구조라, 담보 없이도 가능하다.

활용:

• 차익거래(arbitrage) — DEX 간 가격 차이 이용
• 포지션 자동 청산·리파이낸싱
• (나쁜 쪽) 해킹·익스플로잇 — 큰 자본 동원이 필요한 공격에 쓰임

#5. 파생상품 — 영원히 안 끝나는 선물

#Perps (Perpetual Futures, 영구 선물)

만기 없는 선물 계약. DeFi 파생의 표준이다.

만기일이 따로 없고, 포지션은 청산되거나 직접 닫을 때까지 유지된다.

• Hyperliquid, dYdX, GMX, Dango — 메이저 Perps DEX
• 레버리지 보통 5–50배 가능
• 24/7 거래

#펀딩비 (Funding Rate)

영구 선물의 핵심 메커니즘. 롱과 숏의 균형을 맞추기 위해 한쪽이 다른 쪽에 주는 수수료다.

• 펀딩비 양수 (+) — 롱 우세 → 롱이 숏에게 지급 (보통 8시간마다)
• 펀딩비 음수 (-) — 숏 우세 → 숏이 롱에게 지급

펀딩비 자체가 시장 심리 지표이기도 하다. 펀딩비가 비정상적으로 높으면 → 롱 과열 → 단기 조정 신호.

#청산가 (Liquidation Price)

레버리지 포지션이 자동으로 닫히는 가격.

• 10배 레버리지 롱 — ETH 가격이 약 10% 떨어지면 청산
• 30배 롱 — 약 3% 만에 청산

레버리지가 크면 작은 변동에도 박살난다(rekt).

#OI (Open Interest)

아직 청산되지 않고 살아있는 선물 계약 총량.

OI가 높을수록 시장이 과열된 상태일 가능성이 크다. OI 급상승 + 펀딩비 양수 폭증 = 롱 과열 → 청산 폭포 직전 신호.

#6. 수익 농사 — 이자가 이자를 낳는 구조

#일드 파밍 (Yield Farming)

여러 DeFi에 자산을 굴려서 수익을 얻는 행위 전반.

기본 패턴:

1. 풀에 LP로 예치 → LP 토큰 받음
2. 그 LP 토큰을 또 다른 프로토콜에 스테이킹 → 추가 보상 토큰
3. 보상 토큰 매각 또는 재투자

수익률이 높을수록 리스크와 복잡도도 같이 올라간다.

#APR vs APY

• APR (Annual Percentage Rate, 연이율 — 단리) — 1년 보유했을 때 받는 비율 (재투자 X)
• APY (Annual Percentage Yield, 연수익률 — 복리) — 자동 재투자 가정 시 비율

APR 50%여도, 매일 자동 복리하면 APY 64.8%로 표시된다.

두 단어를 헷갈리면 수익률을 과장 또는 과소평가하게 된다.

#오토컴파운드 (Auto-compound)

받은 보상을 자동으로 재투자해주는 기능. Yearn, Beefy 같은 볼트(Vault)가 대표적.

매일 보상 받아서 다시 풀에 넣는 작업을 사람이 직접 하면 가스비만 나간다 → 컨트랙트가 묶어서 한 번에 처리.

#보상 토큰 (Reward Token)

LP 수수료 외에 프로토콜이 자기 토큰을 인센티브로 추가로 주는 것. 유동성 마이닝(Liquidity Mining) 의 보상.

다만 보상 토큰 가격이 떨어지면 표시 APR도 같이 떨어진다. 고APR = 위험 신호 인 경우가 많다.

#베이스 APR vs 보상 APR

합산 APR이 같다면 Base 비중이 높은 풀이 안정적.

#7. 스테이블코인 메커니즘 — 같은 1달러도 다 다른 구조

블록체인 용어집에서 짧게 다뤘지만, 여기선 좀 더 자세히.

#담보형 (Collateral-backed)

진짜 달러나 국채를 보유하면서 토큰 발행. USDT, USDC, PYUSD.

• 가장 안정적, 다만 발행자가 회사라서 검열·동결 리스크 있음
• 미국 국채 보유 → 이자 수익은 발행사가 다 가져감

#CDP형 (Collateralized Debt Position)

암호화폐를 담보로 잡고 스테이블코인을 빌리는 방식. DAI, LUSD, GHO.

• 보통 150% 이상 오버 담보 (ETH $300어치로 $200 빌림)
• 담보 가치 떨어지면 청산
• 회사 없이 컨트랙트만으로 운영 가능

#알고리즘 (Algorithmic)

수학 공식만으로 1달러 유지하려는 방식. 2022년 UST가 폭락하면서 대부분 사라짐.

지금까지 살아남은 알고리즘 스테이블 = 거의 없음. 새로운 모델이 나와도 시장이 신중함.

#RWA형

미국 국채 같은 실물 자산을 토큰화한 뒤 그걸 담보로 발행. USDe, USDS, sDAI 등이 RWA 비중을 늘리고 있다.

• 보유 시 이자 수익까지 받을 수 있음 (sUSDe, sUSDS)
• 사실상 "배당 주는 디지털 달러"
• Apyx 처럼 우선주 배당 기반의 변형도 등장

#디페깅 (Depeg)

스테이블코인이 1달러에서 벗어난 상태.

• USDC가 2023년 SVB 사태 때 일시적으로 $0.87까지 빠짐 → 며칠 후 회복
• UST는 2022년 디페깅 후 회복 못 함

스테이블코인이 1달러에서 멀어지기 시작하면 빠르게 다른 안정적인 코인으로 갈아타는 게 안전.

#8. 브릿지·랩핑 — 체인 사이를 건너는 자산

#브릿지 (Bridge)

다른 블록체인 간 자산을 옮기는 통로. LayerZero, Wormhole, Across, Stargate 등.

• 보통 원본 체인에서 자산을 잠그고, 목적지 체인에서 같은 양의 토큰을 발행
• 브릿지 해킹은 코인 시장 최대 사고 빈도 1위 — 가급적 공식 브릿지 사용

#Wrapped Token (랩핑 토큰)

다른 체인에서 쓰기 위해 한 번 감싼 토큰.

대표 예시:

• wBTC — 이더리움 위에서 쓸 수 있는 비트코인 (1 wBTC = 1 BTC 백업)
• wETH — ERC-20 표준에 맞춘 ETH (DeFi에서는 wETH로 다뤄짐)

#Native vs Wrapped

같은 "USDC" 라벨이라도 둘은 다른 토큰이다. 가격 차이 발생 가능, 변환 시 수수료·시간 추가. Native가 항상 더 안전.

#9. 위험·구조 용어 — 알아둬야 안 당한다

#스마트 컨트랙트 리스크

코드의 버그·취약점 때문에 자산이 빠져나갈 수 있는 위험.

• 감사(audit) 받았다고 100% 안전한 건 아님
• 메이저 프로토콜(Aave, Uniswap)도 한 번씩 사고 났음
• 신규 프로토콜은 무조건 자금 일부만 넣고 테스트

#오라클 리스크

DeFi에서 오라클이 잘못된 가격을 주면 → 부당 청산 발생.

대형 사고 사례:

• 2022 Mango Markets — 오라클 가격 조작으로 $1.1억 탈취
• 2023 Hundred Finance — 오라클 조작 + 대출 익스플로잇

#Composability (구성 가능성)

DeFi의 핵심 강점. 레고처럼 다른 프로토콜과 자유롭게 연결 가능.

stETH (Lido) → wstETH로 감싼 후 → Aave 담보 → USDC 빌림 → Curve LP → ... 이런 식으로 무한 조합 가능.

장점이자 위험. 한 곳이 무너지면 연쇄적으로 영향을 받는다 (composability risk).

#Rehypothecation (재담보)

담보로 받은 자산을 다시 다른 곳에 담보로 사용하는 것.

DeFi 자체는 잘 안 쓰지만, 리스테이킹·LRT 영역에서 비슷한 구조가 형성되고 있다 → 한 자산이 여러 군데 동시에 담보로 잡혀 있을 수 있음.

#10. 신규 트렌드 — 2024–2026 키워드

DeFi에서 최근 빠르게 자리 잡은 영역들. 새 프로토콜·트윗에서 자주 마주치는 단어들이다.

#리스테이킹 (Restaking)

이미 스테이킹된 자산을 다른 프로토콜의 보안에도 다시 활용하는 구조.

• ETH를 Lido에 스테이킹 → stETH 발행
• 그 stETH를 EigenLayer에 다시 예치 → 다른 AVS(Actively Validated Service)의 보안에도 동원
• 그 대가로 추가 보상 + 포인트

기존 스테이킹과 다르게 하나의 자산이 여러 곳에서 동시에 보안 자본으로 쓰임 → 자본 효율 ↑, 다만 연쇄 슬래싱 리스크도 같이 ↑.

#LRT (Liquid Restaking Token)

리스테이킹된 자산을 유동성 토큰으로 받는 방식. Lido(LST) 모델의 리스테이킹 버전.

• EtherFi (eETH), Renzo (ezETH), Kelp (rsETH), Puffer (pufETH) 등이 메이저
• LRT를 들고 있으면 ETH 스테이킹 보상 + EigenLayer AVS 수수료 + 포인트(나중에 토큰 에어드랍 가능성)를 한 번에

2024–2026년 DeFi 신규 TVL의 상당 부분이 이 영역에서 발생했다.

#veToken / Vote Escrow

토큰을 장기 락업하는 대가로 거버넌스 권한과 수익을 받는 구조. Curve가 시작한 모델.

• veCRV — CRV를 최대 4년까지 락업하면 ve(vote escrow)CRV 받음
• 락업 기간이 길수록 더 많은 ve 토큰
• ve 보유자는 어느 풀에 인센티브 줄지 투표 → 프로젝트들이 표를 사기 위해 뇌물 경쟁 = "Curve war"
• Convex, Aerodrome, Velodrome 등이 이 모델을 차용

장기 정렬 + 거버넌스 + 수익을 한 번에 묶는 메커니즘. 다만 토큰을 오래 묶어야 해서 유동성이 떨어진다.

#Account Abstraction (ERC-4337, AA)

스마트 컨트랙트 지갑으로 EOA(일반 지갑)의 한계를 넘어서는 표준.

기존 EOA의 제약:

• 가스비를 ETH로만 결제 가능
• 시드구문 잃으면 끝
• 트랜잭션 1개씩 직접 서명

AA로 가능해지는 것:

• 가스리스 (gasless) — 프로토콜·dApp이 가스를 대신 내줌
• 소셜 로그인 — 시드구문 대신 이메일·구글 계정으로 지갑 접근
• 번들링 — 여러 트랜잭션을 한 번에 묶어 실행
• 세션 키 — 한정된 권한 키로 자동 거래 (게임·트레이딩 봇)

Argent, Safe, Biconomy, Privy 등이 활용 중. 점진적으로 EOA를 대체하는 방향.

#11. 자주 보이는 약어 한 줄 정리

#마무리

DeFi 용어는 결국 "기존 금융을 그대로 옮긴 것" 이라고 보면 80%는 이해된다.

• 대출 프로토콜 = 은행
• DEX = 증권사
• 청산 = 마진콜
• 펀딩비 = 선물 코스트
• TVL = 예금 잔고

다른 점은 24시간 자동, 검열 안 됨, 누구나 같은 조건 정도.

처음엔 단어 폭격 같아도 한 사이클 돌고 나면 다 같은 얘기를 다른 단어로 부르고 있다는 게 보인다. 모르는 단어 마주칠 때마다 이 글에 한 번씩 다시 와서 보면 충분하다.

같이 보면 좋은 글:

• 블록체인 용어집 2026 — 기초 기술 용어
• 코인판 슬랭·약어 사전 — 트위터에서 보는 단어들
• 스테이블코인·가스비·DEX — DeFi 입문 가이드
• Apyx 프로토콜 분석 — 새로운 스테이블코인 모델
• Dango Exchange 분석 — CLOB DEX 사례

"GM ser, WAGMI 🙏" "이번 알트 ape in 했더니 rekt..." "DYOR 하셈" "이거 진짜 알파임" — 단어 절반은 영어 약어이고, 그것도 사전 찾아도 안 나오는 것들이다. 뭘 검색해야 할지조차 막막하다.

근데 막상 알고 나면 별것 없다. 거의 다 감정·태도·정체성을 짧게 줄여 부르는 말이라서, 한 번 정리해두면 그 후로는 "아 또 그 얘기" 하고 넘어가게 된다.

이 글은 2026년 4월 기준으로 코인 트위터·텔레그램·디스코드에서 자주 마주치는 슬랭·약어를 카테고리별로 모아둔 거다. 기술 용어는 블록체인 용어집, DeFi 용어집에 따로 있다.

#1. 인사·호칭 — 코인 트위터의 기본 어휘

#GM / GN

Good Morning / Good Night.

코인 트위터에서 가장 자주 보는 인사다. 아침에 일어나서 "GM 🌞" 한 줄 올리는 게 일종의 의식이고, 자기 전엔 "GN" 하고 닫는다.

근데 단순한 인사가 아니다. "오늘도 시장에서 살아남자" 라는 일종의 결속 표현. 시장이 박살나서 다들 조용해진 다음 날 "GM" 한 줄 올라오면 그게 또 위로가 된다.

#ser

"sir"의 의도적 오타. 친근한 말투다. "hey ser, 이거 알파임" 같은 식.

#anon

Anonymous. 익명. 코인판은 본명·얼굴 안 까고 활동하는 사람이 정상이라, 서로를 "anon"이라고 부르는 게 흔하다.

"NGMI anon" = "당신 못 살아남을 듯".

#fren

"friend"의 코인판식 표기. 친한 사람·동지 호칭.

ser, fren, anon — 이 셋이 코인 트위터의 3대 호칭이다.

#OG

Original Gangster. "옛날부터 있던 사람."

2017년 ICO 붐 이전부터 활동한 사람들을 OG라고 부른다. 이 단어 붙으면 자연스럽게 "그쪽이 더 많이 안다"는 가산점이 붙는다.

#normie

코인 안 하는 일반인. 특별히 비하 의도는 없고 "코인판 밖 사람" 정도.

가족·직장 동료 얘기할 때 "내 normie 친구는 아직 비트코인이 뭔지도 모름" 식으로 쓴다.

#jeet

팔고 나간 사람. "사람들이 다 jeet했다(다 던졌다)" 식으로 쓴다.

대부분 부정적 뉘앙스. "이번엔 jeet하지 마라" = "이번엔 팔지 마라".

#KOL

Key Opinion Leader. 영향력 있는 인플루언서.

보통 트위터 팔로워 수만~수십만 명 단위. 프로젝트들이 KOL한테 토큰을 미리 뿌려서 홍보를 부탁하는 경우가 많다 → 그래서 KOL 트윗은 일정 부분 광고로 봐야 한다.

#2. 가격 심리 — 시장의 감정 사전

코인 가격이 오르내릴 때마다 사람들의 심리가 사이클을 그린다.

그 심리를 한 단어로 박제한 게 이 동네의 진짜 슬랭이다.

#FOMO

Fear Of Missing Out. 놓칠까 봐 무서워서 사는 심리.

남들이 다 돈 벌고 있는데 나만 안 사는 것 같아서 결국 고점에서 산다. "FOMO 매수" 라는 표현이 따로 있을 정도로 흔하다.

99%의 경우, FOMO 매수의 결과는 물리는 것이다.

#FUD

Fear, Uncertainty, Doubt. 가격을 떨어뜨리려고 의도적으로 퍼뜨리는 부정적 정보(또는 그냥 부정적 의견).

"이거 다음 주에 큰 락업 풀린대" 같은 글이 올라오면 "FUD 작렬한다"고 표현한다. 진짜 위험인지 그냥 흔드는 건지 구분하는 게 트레이더의 실력.

#DYOR

Do Your Own Research. "내 말 믿지 말고 직접 알아봐."

추천하면서 끝에 항상 붙는다. 사실상 책임 회피용 멘트다. "이거 알파임, DYOR" 라고 하면 손해 봐도 본인 책임이라는 뜻.

#copium

Cope + Opium. 손실을 직시 못 하고 자기 위로에 빠진 상태.

"이번엔 진짜 분명 다시 오를 거야"를 무한 반복하는 사람의 상태. 보통 이미 -70%인 경우가 많다. "copium 흡입 중" 식으로 쓴다.

#hopium

Hope + Opium. copium보다는 살짝 긍정적인 버전. 근거 없는 희망.

"이번 업데이트 끝나면 분명 100배 갈 거야 🙏" — 이게 hopium.

#diamond hands / paper hands

• diamond hands (💎🙌) — 손이 다이아몬드라서 코인을 절대 안 내려놓는 사람. "DH로 들고 간다" = "절대 안 판다."
• paper hands (📄🙌) — 종이손. 살짝만 떨어져도 패닉 셀하는 사람. 주로 자기를 놀리거나 남을 비하할 때 쓴다.

#bagholder

가방 든 사람. 고점에서 사서 못 팔고 들고 있는 사람.

"나 LUNA bagholder임 ㅠ" 처럼 자기 처지를 스스로 농담거리 삼는 표현.

#3. 가격 움직임 — 차트 위 단어들

#moon / mooning

달까지 간다 = 가격이 폭등한다.

코인판 1세대 슬랭. 차트 그림에 🚀 붙는 이유.

#pump / dump

• pump — 가격 펌핑(급등)
• dump — 매도세로 급락
• pump and dump — 펌핑하고 던진다 = 인위적으로 올리고 빠지는 사기 패턴

#rekt

wrecked의 의도적 표기. 박살남.

레버리지 청산당했거나 큰 손실 본 상태. "오늘 rekt 됐다" = "오늘 폭망했다".

#ATH / ATL

• ATH — All-Time High. 사상 최고가. 가격이 ATH 찍으면 보통 "ATH 갱신!" 하고 트윗 도배됨.
• ATL — All-Time Low. 사상 최저가.

#send it / LFG

• send it — 가즈아. "이거 보내자(가격이 위로 가자)" 같은 즉흥적 외침.
• LFG — Let's Fucking Go. send it보다 더 강한 외침. 발표·런칭 직전에 자주 쓴다.

#bullish / bearish

가격뿐 아니라 의견 표현으로도 쓴다. "이 팀에 bullish하다" = "이 팀 좋게 본다".

#4. 매매 행동 — 들어가고 나오는 표현들

#ape in

원숭이처럼 들어간다. 분석 같은 거 하지 말고 그냥 매수.

"리서치 했지" 같은 거창한 표현 대신 "ape했다" 라고 하면 그게 더 솔직하다. 코인판은 "ape하는 게 정상"이라며 스스로를 놀리는 분위기가 깔려 있다.

#HODL

"Hold on for Dear Life"의 줄임이라는 설이 있는데, 사실은 2013년 비트코인토크 게시글의 HOLD 오타가 밈이 된 거다.

작성자가 술 취해서 "I AM HODLING"이라고 적었고, 그게 그대로 굳어졌다. 의미는 명확 — 팔지 말고 들고 있어라.

#DCA

Dollar Cost Averaging. 분할 매수.

한 번에 사지 말고 시간 분산해서 사는 전략. "매주 BTC 10만 원씩 DCA 중" 처럼 쓴다. 가장 보수적이고 안정적인 매수법.

#TP / SL

• TP — Take Profit. 익절 가격
• SL — Stop Loss. 손절 가격

선물·레버리지 거래에서 진입할 때 같이 설정한다.

#shill

광고·홍보. 좀 부정적 뉘앙스.

"이 사람 토큰 shill 중" = "자기 보유 토큰 홍보 중". KOL이 돈 받고 트윗하면 그것도 shill.

#top tick / bottom tick

• top tick — 정확히 고점에 산 것
• bottom tick — 정확히 저점에 판 것

둘 다 자기 처지를 비웃을 때 쓰는 표현. "또 top tick 했다" = "또 고점에 물렸다".

#alpha

남들이 아직 모르는 정보·기회.

"이거 alpha임" = "이거 아직 사람들이 모르는 좋은 종목·기회". 트위터에서 알파를 발견·공유하는 게 코인판 핵심 활동 중 하나다.

• alpha leak — 알파 정보가 새어 나간 상태
• alpha group — 사적 채팅방·디스코드에서 알파 공유
• 단, "alpha임"이라고 외치는 트윗 90%는 광고(shill)인 경우가 많다

#NFA (Not Financial Advice)

"투자 권유 아님" — DYOR과 짝꿍, 책임 회피용 멘트.

"이거 100배 갈 듯, NFA" = "100배 가겠지만 손해 봐도 본인 책임이라는 안전장치." 사실상 트위터 글 끝마다 붙어다닌다.

#5. 운명·예언 — 한 줄로 결판내는 단어들

#WAGMI / NGMI / GMI

"이런 거 묻는 사람은 NGMI" = "이런 기본도 모르는 사람은 못 살아남음" (조롱).

반대로 "이 프로젝트 GMI" = "이건 살아남을 듯".

#probably nothing

직역하면 "별 거 아닐 듯". 근데 실제로는 반어법이다.

"이거 별 거 아닐 듯, probably nothing" = "이거 사실 엄청난 알파임" 의 의미. 코인 트위터의 시그니처 농담 중 하나.

#few understand

"few(소수)만 이해한다"는 뜻.

자기가 들고 있는 종목·내러티브에 자신감 표현할 때 쓴다. "few understand the technology" — 약간 거만한 톤.

#wen

"when"의 의도적 오타. "언제?"라는 질문을 짧게 던지는 슬랭.

• wen moon? — "언제 가격 오름?"
• wen lambo? — "언제 부자 됨?"
• wen TGE? — "언제 토큰 발행?"

답변도 비슷한 톤: "soon™" = "곧 (이라고 1년째 말하는 중)".

#lambo

Lamborghini. 코인으로 부자가 되면 산다는 코인판의 농담.

"wen lambo?"가 클래식 슬랭. 부의 시각적 상징으로 굳어졌다. 실제로 람보를 사는 사람은 극소수지만 단어는 끈질기게 살아남았다.

#6. 정체성·캐릭터 — 코인판 사람 분류표

#degen

Degenerate. "도박꾼". 위험 무시하고 막 들어가는 트레이더.

자기를 놀리는 용도로 더 자주 쓰인다. "이번 주에 degen play 하나 했다" = "이번 주에 도박 한 판 했다". 코인판에선 이게 칭찬 비슷하게 쓰이기도 함.

#whale / shrimp / plebs

"whale 움직임 추적해야 한다" = "고래가 어디 사는지 보자" — 이래서 Lookonchain, Whale Alert 같은 채널이 있는 거다.

#dev / anon dev

• dev — 개발자. 프로젝트 만든 사람.
• anon dev — 익명 개발자. 본명·신원 안 까고 운영하는 사람. 러그풀 위험이 더 크다고 본다.

#chad / virgin / gigachad

밈 캐릭터에서 온 표현.

• chad — 자신감 있고 옳은 선택을 하는 사람. "BTC만 들고 있던 chad".
• virgin — 그 반대. 잡코인 들고 흔들리는 사람.
• gigachad — chad의 강조형. "BTC만 4년 버틴 gigachad" — 알트 던지고 메이저만 끝까지 들고 간 사람을 칭송.

#larp

Live Action Role Playing. 자기 능력·정체성을 과장하는 행위.

• "이 KOL larp 같다" = "자칭 트레이더인데 실력 의심됨"
• 코인판은 익명이라 larp가 흔하다 → DM으로 거짓 자기소개로 사기치는 경우도 많음

#maxi

Maximalist. 한 코인만 절대적으로 신봉하는 사람.

• bitcoin maxi — "비트코인만 진짜 코인", 알트코인 다 부정.
• eth maxi — 이더리움 신봉자.

대부분의 maxi는 다른 진영을 강하게 비판한다 → 트위터 싸움의 단골 소스.

#based

"맞는 말", "동의함."

원래는 "based on truth"에서 출발한 인터넷 슬랭인데, 코인판에선 누가 정확한 의견·강한 입장을 냈을 때 응원·동의 표현으로 쓴다.

• "ETH는 끝났다" → "based" (강한 동의)
• 반대말은 cringe (어색·동의 안 됨)

#7. 토큰 분류 — 자주 보이는 카테고리

#shitcoin

가치·기술 거의 없는 토큰. 대부분의 알트코인을 비하해서 부르는 말이지만, 코인판에선 자기 처지를 놀리듯이 더 자주 쓴다.

"이번 cycle은 shitcoin으로 100배 노린다" = "잡코인으로 큰 수익 노린다."

#memecoin

밈·문화 기반 토큰. 기술적 기능보다 커뮤니티·재미가 핵심.

대표 사례: 도지(DOGE), 시바이누(SHIB), 페페(PEPE), BONK, WIF, POPCAT 등. 2024 cycle은 memecoin이 주류 narrative였다.

shitcoin과 다른 점은 목적성이 명확하다는 것 — "기술 없음"이 그 자체로 컨셉.

#8. 사기·실패 — 알아둬야 안 당한다

#rug / rug pull

개발자가 유동성 들고 도망가는 것. 신생 토큰 사기 패턴 1위.

"rug 당했다" = "내 토큰이 0이 됐다". 이 단어 나오는 토큰은 보통 살리기 어렵다 = 손실 확정.

#exit liquidity

탈출용 유동성. 좀 더 무서운 표현이다.

큰 손이 자기 물량 털기 위해 개미들을 끌어들여서 자기 매도 상대로 삼는 것을 가리킨다.

"우린 exit liquidity일 뿐" = "우린 큰 손이 빠져나갈 때 받아주는 호구일 뿐."

#honeypot

살 수는 있는데 못 파는 컨트랙트. 매수 후 매도 함수가 막혀 있어서 토큰이 갇힌다.

신생 밈코인에서 자주 발견된다. honeypot.is 같은 도구로 사전 점검 가능.

#ponzi

폰지 사기. 새로 들어온 사람 돈으로 먼저 들어온 사람한테 이자 주는 구조.

"이건 ponzi다" 라는 비판이 자주 나오는데, 사실 코인판 상당수가 폰지에 가깝긴 하다 (그래서 "Ponzinomics"라며 스스로 인정하는 농담도 있음).

#9. 자주 보이는 트레이딩 약어

기술적 약어인데 슬랭처럼 쓰여서 같이 정리.

#10. 한국 코인판 슬랭

영어만 슬랭이 있는 게 아니다. 한국 커뮤니티에도 자기들만의 단어가 있다.

#11. 슬랭으로 이어지는 짧은 트윗 해석 연습

GM frens 🌞 어제 ape in한 알트 -40% rekt...
근데 다른 anon이 "이건 진짜 알파다 DYOR" 한 거 하나는 +120% 갔다.
WAGMI ser, 다음 주 토큰 unlock 풀린대 — FUD 살짝 깔리겠지만 결국 GMI일 듯 🙏
이번에도 paper hands는 NGMI, diamond hands는 끝까지 간다.
LFG 🚀

해석:

굿모닝 친구들 🌞 어제 분석 안 하고 매수한 알트가 -40% 폭망함.

근데 다른 익명이 "이건 진짜 미공개 정보다, 직접 알아봐라" 한 거 하나는 +120% 갔다.

우린 다 같이 살아남을 거다, 다음 주 토큰 락업 풀린다는데 부정적 정보가 깔리겠지만 결국 살아남을 듯 🙏

이번에도 패닉 셀하는 사람은 못 살아남고, 끝까지 들고 가는 사람이 이긴다.

가즈아 🚀

읽을 수 있게 되면 코인 트위터의 절반은 이런 톤이라는 게 보일 거다.

#마무리

슬랭은 트렌드처럼 변한다. 2017년에 메인이던 단어들 중 절반은 이미 안 쓰인다.

2026년 4월 기준으로 위 단어들이 메이저인데, 1년 뒤에는 또 새로운 게 자리 잡고 있을 거다. 다 외울 필요는 없다. 코인 트위터·텔레그램에서 모르는 단어 마주칠 때마다 이 글에 와서 찾아보면 된다.

한 번 익숙해지면 그 다음엔 안 보고도 분위기가 잡힌다. 단어를 안다고 돈을 버는 건 아니지만, 적어도 남들이 무슨 얘기 하는지는 알아듣고 시작할 수 있다.

같이 보면 좋은 글:

• 블록체인 용어집 2026 — 기술 용어 정리
• DeFi 용어집 2026 — DeFi 핵심 어휘
• 에어드랍 입문 — 무료 토큰 받는 법
• 코인 처음 할 때 실수들 — 초보자가 흔히 하는 실수

검색하면 STS3 시절(2018~2020) 글이 대부분이라 화면이 다르고 메뉴 위치도 안 맞습니다. 이 글은 STS 4.21 + JDK 17 기준입니다.

#누구한테 필요한 글인가요?

• SI·금융·공기업 신입으로 첫 출근한 분
• 회사가 IntelliJ 라이선스 안 사주고 STS만 강요하는 환경
• 이미 STS 깔아봤는데 한글이 ???로 깨져서 빡친 분
• 사수가 "그냥 알아서 해" 라고 하고 사라진 분

순서대로만 따라가면 막히지 않습니다.

#1단계. STS4 다운로드 (1분)

spring.io/tools 접속 → 자기 OS 골라서 다운로드.

• Windows: .zip (win32.x86_64)
• macOS: .dmg
• Linux: .tar.gz

중요: STS는 Eclipse 기반이라 설치 마법사가 없습니다. 그냥 압축 파일이에요.

왜 설치 프로그램이 없나요?

Eclipse 계열은 "압축 풀면 그게 설치 끝"이라는 철학을 따릅니다. 레지스트리에 뭐 박지도 않고, 시스템 PATH에도 안 건드립니다. 회사 노트북에서 관리자 권한 없이도 동작한다는 게 큰 장점이에요.

#2단계. 압축 풀고 워크스페이스 만들기 (30초)

압축은 C 드라이브 루트 또는 사용자 폴더 하위에 풀어주세요. Program Files 같은 권한 필요한 경로는 피합니다 (나중에 Lombok 설치 때 권한 에러 납니다).

C:\sts-4.21.0.RELEASE\
└── SpringToolSuite4.exe   ← 더블클릭

처음 실행하면 Workspace 경로를 물어봅니다. 기본값 그대로 Use this as the default and do not ask again 체크하고 Launch.

#3단계. JDK 17 매핑 (1분)

Window > Preferences > Java > Installed JREs

1. Add... → Standard VM 선택
2. JRE home에 JDK 17 설치 폴더 지정 (C:\Program Files\Java\jdk-17 등)
3. Finish
4. 추가된 JDK 17 옆 체크박스 클릭 → Default 지정
5. Apply and Close

왜 명시적으로 매핑하나요?

STS는 처음 켜질 때 시스템 PATH에 잡힌 JRE를 자동으로 찾습니다. 그런데 회사 노트북에는 JDK 8과 17이 같이 깔려있는 경우가 많아요. 자동 인식이 JDK 8을 잡으면 Spring Boot 3.x 프로젝트가 통째로 안 뜹니다. 그래서 명시적으로 17을 default로 박아둡니다.

JDK가 아예 없다면 Eclipse Temurin 에서 무료로 받으세요. Oracle JDK는 회사용 라이선스 이슈가 있어서 Temurin이 안전합니다.

#4단계. UTF-8 인코딩 4군데 박기 (★ 핵심, 1분 30초)

이 글에서 제일 중요한 부분입니다. 한글이 ???로 깨져서 회의록 PR에서 사수에게 욕먹는 그 사건, 여기서 막아둡니다.

#4-1. Workspace 전역 인코딩

Window > Preferences > General > Workspace

→ 하단 Text file encoding → Other 선택 → UTF-8

#4-2. Web 파일들 (CSS · HTML · JSP)

Window > Preferences > Web 아래 세 항목 모두:

• CSS Files → Encoding: ISO 10646/Unicode(UTF-8)
• HTML Files → Encoding: ISO 10646/Unicode(UTF-8)
• JSP Files → Encoding: ISO 10646/Unicode(UTF-8)

JSP 안 쓴다고 빼지 마세요. 회사 레거시 프로젝트에서 갑자기 튀어나옵니다.

#4-3. Content Types

Window > Preferences > General > Content Types

• Text > Java Source File 선택 → Default encoding: UTF-8 입력 → Update
• Text > CSS · HTML · JSP 도 동일하게 처리

#4-4. 프로젝트 단위 재설정

전역 설정을 해도 이미 만든 프로젝트는 자동 적용 안 됩니다. 기존 프로젝트가 있다면:

프로젝트 우클릭 > Properties > Resource > Text file encoding > UTF-8

왜 4군데 다 박나요?

Eclipse 계열의 인코딩 설정은 상속 구조입니다. Workspace → Content Type → 파일 타입별 설정 → 프로젝트 설정 순으로 덮어쓰기 됩니다. 한 군데라도 빠지면 그 영역만 시스템 기본값(Windows = MS949)으로 떨어져서, 거기서만 한글이 깨집니다. 그래서 한꺼번에 다 박아두는 거예요.

한 번 깨진 한글은 복구 불가능합니다. 셋팅 먼저, 코딩은 그 다음입니다.

#5단계. Lombok 설치 (1분)

Spring Boot 프로젝트에서 @Getter, @Setter, @RequiredArgsConstructor 같은 어노테이션을 쓰려면 IDE에 Lombok이 인식되어야 합니다.

1. projectlombok.org 접속 → Download 클릭 → 최신 jar 다운
2. 다운받은 폴더로 이동 → lombok-1.18.x.jar 더블클릭
   • 안 열리면 PowerShell에서 java -jar lombok-1.18.x.jar
3. 인스톨러가 시스템 IDE를 자동 검색합니다 → STS4 경로 자동 감지
4. STS 옆 체크박스 ✓ → Install / Update 클릭
5. STS 재시작 (중요!)

왜 별도 설치인가요? Maven 의존성으로 충분하지 않나요?

Lombok은 컴파일 시점에 코드를 자동 생성하는 라이브러리입니다. Maven에 의존성을 추가하면 빌드는 되지만, IDE는 별도로 설정해줘야 빨간 줄이 안 그어집니다. jar 실행은 SpringToolSuite4.ini 파일에 -javaagent:lombok.jar 라인을 자동으로 추가해줘요. 직접 ini 파일 건드리는 것보다 인스톨러가 안전합니다.

설치 후 STS 재시작 안 하면 적용 안 됩니다. 꼭 재시작.

#6단계. Boot Dashboard 켜기 (15초)

Window > Show View > Other > Spring > Boot Dashboard

이게 STS의 진짜 핵심 기능입니다. Spring Boot 앱을 클릭 한 번으로 Run / Debug / Stop / Restart 가능. IntelliJ의 Run 버튼이랑 같은 역할이에요.

여기서 앱을 Run하면 자동으로 활성 프로파일, 포트, PID까지 한눈에 보입니다. 디버그 모드 토글도 바로 가능.

#7단계. 자주 쓰는 단축키 5개

Ctrl + 1 하나만 익혀도 코딩 속도가 두 배가 됩니다. 빨간 줄 그어진 곳에서 누르면 거의 다 해결돼요.

#8단계. 첫 프로젝트 만들고 검증 (1분)

File > New > Spring Starter Project

Next → Dependencies 에서 Spring Web, Lombok 두 개 체크 → Finish.

Boot Dashboard에서 프로젝트 선택 → ▶ Run → 콘솔에 Started Application in X.X seconds 뜨면 성공.

브라우저에서 http://localhost:8080 접속해서 White Label Error Page 뜨면 셋팅 완료입니다. (404 같지만 Spring Boot가 정상 동작 중이라는 뜻)

#자주 막히는 5가지

#"JRE not found" 에러

→ 3단계 누락. Installed JREs에 JDK 17 등록 안 됨. 다시 가서 등록 + Default 체크.

#한글이 ???로 깨짐

→ 4단계 4군데 중 한 군데 누락. 특히 Content Types를 빼먹는 경우가 가장 흔합니다. 프로젝트 단위 설정도 따로 해야 한다는 점 잊지 마세요.

#Lombok @Getter 가 안 먹힘

→ 5단계 후 STS 재시작 안 한 경우. 또는 SpringToolSuite4.ini에 -javaagent 라인이 안 들어간 경우. ini 파일 직접 열어서 확인:

-javaagent:lombok.jar

#Maven 빌드 시 한글이 깨짐

→ IDE 인코딩이랑 별개로 Maven은 자체 설정을 봅니다. pom.xml에 추가:

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <java.version>17</java.version>
</properties>

#Boot Dashboard에 프로젝트가 안 보임

→ Spring Boot 프로젝트로 인식 안 됨. pom.xml에 spring-boot-starter-parent 또는 spring-boot-starter 의존성이 있는지 확인하세요. Maven Update (Alt + F5)도 해보세요.

#이제 진짜 시작입니다

5분 안에 끝났을 거예요. 이제 진짜 코드를 짤 시간입니다.

다음 단계로 풀스택 셋팅(React 연동, Oracle DB, MyBatis)이 궁금하다면 Spring Boot + React + Oracle + MyBatis 셋팅 시리즈에서 이어서 보시면 됩니다.

회사에서 사수가 "왜 IntelliJ 안 쓰냐" 라고 묻거든, "라이선스 사주시면 쓰겠습니다" 라고 답하시면 됩니다. 그 전까진 STS4도 충분히 잘 굴러갑니다.

"리스테이킹"이 뭔지 몰라서 검색하면 "LRT"가 또 튀어나오고, "모듈러"라더니 "DA 레이어"가 따라오고, 갑자기 AI 에이전트 토큰이 시총 상위에 박혀 있다. 분명 한국어로 적혀 있는데도 머리에 안 들어온다.

그래서 정리했다. 2026년 4월 시점에서, 코인판에서 한 번쯤은 마주치는 용어들. 사전식 정의가 아니라 "왜 이 단어가 만들어졌고, 왜 지금 사람들이 얘기하는지" 정도까지.

처음부터 다 외울 필요는 없다. 모르는 단어 마주쳤을 때 한 번씩 와서 보면 충분하다.

#1. 기초 — 블록체인은 결국 뭔가

#블록체인 (Blockchain)

거래 기록을 블록이라는 단위로 묶고, 그 블록을 시간순으로 체인처럼 연결한 장부다. 누가 누구한테 얼마를 보냈는지가 영원히 남고, 한 번 기록되면 못 바꾼다.

은행 장부랑 다른 점은 딱 하나, 관리자가 없다는 거다. 전 세계 컴퓨터 수만 대(노드)가 같은 장부를 들고 있고, 새로운 거래가 일어나면 다 같이 검증해서 다음 블록에 넣는다.

#노드 (Node)

블록체인 네트워크에 참여하고 있는 컴퓨터 한 대 한 대를 노드라고 부른다. 거래를 검증하고, 장부 사본을 갖고 있다. 비트코인은 전 세계에 약 2만 개, 이더리움은 약 1만 개의 노드가 돌고 있다.

노드는 왜 자기 전기·서버 비용 써가며 참여할까?

한마디로 돈이 되니까. PoW 체인(비트코인)에서 노드는 새 블록을 만들면 블록 보상(현재 BTC 3.125개) + 거래 수수료를 받는다. PoS 체인에서는 스테이킹된 코인의 연 3–7% 이자가 들어온다.

그냥 거래 내역만 보관하는 풀 노드(Full Node) 도 있다. 이건 보상 없이 자발적으로 운영되는데, "내가 직접 검증한 장부를 신뢰할 수 있다"는 이념적 동기 + 자기 비즈니스(거래소·지갑) 인프라용으로 돌리는 경우가 대부분.

#합의 메커니즘 (Consensus)

수많은 노드가 "이 거래가 진짜야" 하고 동의하는 방식. 두 가지가 대표적이다.

• PoW (작업 증명, Proof of Work) — 컴퓨터로 어려운 수학 문제를 먼저 푸는 사람이 다음 블록을 만든다 → 비트코인. 전기를 많이 쓴다. 이 일을 하는 사람을 마이너(Miner, 채굴자) 라고 부른다.
• PoS (지분 증명, Proof of Stake) — 토큰을 많이 맡긴(스테이킹) 사람이 검증할 권리를 얻는다 → 이더리움(2022년 9월부터). 전기 소비가 99% 감소. 이 일을 하는 사람을 밸리데이터(Validator, 검증자) 라고 부른다.

왜 이런 복잡한 방식이 필요한가?

"관리자 없이 모르는 사람들끼리 합의하기" 위해서다. 비싼 비용(전기·자금)을 들여야 블록을 만들 자격이 생기게 만들어두면, 부정행위는 그 비용을 잃는 손해로 이어진다. PoW는 전기를, PoS는 락업한 자금을 잃는다(슬래싱). 그래서 정직하게 검증하는 게 더 이득.

#2. 지갑·키·계정

#개인키 (Private Key) / 시드 구문 (Seed Phrase)

지갑의 진짜 비밀번호다. 64자리 16진수 문자열인데, 사람이 외울 수 없으니 12개나 24개 영어 단어로 변환해서 보여주는 게 시드 구문이다.

이걸 가진 사람이 곧 그 지갑의 주인이다. 거래소 계정처럼 "비밀번호 분실하면 본인 확인하고 복구" 같은 게 없다. 종이에 적어서 보관하라는 게 그래서 그런 거다.

#EOA vs 스마트 계정 (Account Abstraction)

지금까지 일반 지갑(메타마스크 등)은 EOA(Externally Owned Account), 즉 개인키 1개로 관리되는 단순한 계정이었다.

**계정 추상화(AA, ERC-4337)**는 지갑을 스마트 컨트랙트로 만드는 표준이다. 2026년 시점에서 이미 메이저 L2 지갑(Base, Optimism)이 적극 채택 중이다. 뭐가 달라지냐면:

• 가스비를 ETH 말고 USDC로 낼 수 있다
• 소셜 복구 가능 (지인 3명이 동의하면 지갑 복구)
• 패스키 / 지문으로 로그인 (시드 구문 없이도 됨)
• 여러 거래를 한 번에 묶어 처리

지갑이 앱처럼 동작하는 시대로 넘어가는 중이다.

#3. L1·L2 — 코인이 사는 동네

#L1 (Layer 1)

자기만의 블록체인을 갖고 있는 메인 네트워크. 비트코인, 이더리움, 솔라나, 아발란체, 수이(Sui) 같은 게 다 L1이다.

#L2 (Layer 2)

L1이 너무 느리고 비싸서, 그 위에 얹어서 거래를 빠르고 싸게 처리하는 보조 체인이다. 결과만 가끔 L1에 정산해서 기록한다.

이더리움 L2가 2026년 기준 가장 활발하다. Base(코인베이스), Arbitrum, Optimism, zkSync, Linea 같은 게 대표적. 가스비가 L1의 1/100–1/1000 수준이라 실질적으로 거의 모든 DeFi가 L2로 옮겨갔다.

#롤업 (Rollup)

L2 중에서도 거래를 모아서(roll up) 압축한 뒤 L1에 한 방에 기록하는 방식. 두 종류가 있다.

• 옵티미스틱 롤업 (Arbitrum, Optimism, Base): 일단 맞다고 가정하고 처리, 이상 있으면 7일 내 이의 제기
• ZK 롤업 (zkSync, Linea, StarkNet): 수학적 증명으로 거래 정합성을 검증

2025–2026년 트렌드는 ZK 우세 쪽으로 기울고 있다. 인출 시간이 짧고(7일 → 거의 즉시) 수학적으로 더 견고해서.

#모듈러 블록체인 (Modular Blockchain)

기존 블록체인은 합의 + 실행 + 데이터 저장 + 결제를 한 체인이 다 했다(모놀리식). 모듈러는 이걸 층층이 분리한다.

• 실행 → L2 (거래 처리)
• 합의·결제 → 이더리움
• 데이터 가용성(DA) → Celestia, EigenDA 같은 전용 레이어

각 층이 자기 역할만 잘하면 되니까 전체적으로 더 빠르고 싸진다. 2024–2026 코인 내러티브에서 가장 큰 축 중 하나.

#앱체인 (App-chain)

한 애플리케이션 전용으로 통째로 만든 블록체인. "다른 앱이랑 공유하는 체인이 답답하니까, 우리 게임/DEX 전용 체인을 만들자"는 컨셉. 그 체인 위에선 그 앱이 가스비 정책·수수료까지 다 정한다.

• dYdX v4 — 자체 Cosmos 앱체인으로 이전
• Avalanche Subnet — 게임·기업 전용 체인 양산
• Polygon CDK / OP Stack — L2 앱체인 키트

#브리지 (Bridge)

다른 블록체인 간 자산을 옮겨주는 통로. 이더리움의 ETH를 솔라나에서 쓰려면 브리지를 거쳐야 한다.

• LayerZero, Wormhole, Across — 메이저 크로스체인 브리지
• Native bridge — L2 공식 브리지 (Base, Arbitrum 등)

브리지는 코인 시장에서 가장 큰 해킹 표적이다. 2022–2023년 사이 Ronin(6억 달러), Wormhole(3.2억 달러) 등 굵직한 사고가 이어졌다. 가급적 공식 브리지, 액수가 크면 여러 번 나눠서 옮기는 게 안전.

#오라클 (Oracle)

블록체인은 외부 정보(주가·환율·날씨)를 스스로 못 본다. 외부 데이터를 온체인으로 가져다주는 인프라가 오라클이다.

• Chainlink — 가격 피드의 표준
• Pyth — 솔라나 기반, 고속 가격 피드
• RedStone — LST/LRT 가격에 강함

DeFi에서 청산·결제·파생상품 가격이 다 오라클 데이터에 의존한다. 오라클이 잘못된 가격을 주면 → 부당 청산 발생 → 실제로 종종 사고가 난다.

#4. 토큰의 종류 — 다 같은 코인이 아니다

코인 시장에서 "토큰"이라고 다 같은 게 아니다. 어떤 역할을 하느냐에 따라 분류가 다른데, 이걸 알아야 토큰을 살 때 "이게 왜 가치가 있는가" 를 가늠할 수 있다.

#유틸리티 토큰 (Utility Token)

특정 서비스를 사용하기 위한 입장권 역할의 토큰이다. 그 토큰을 갖고 있어야 그 네트워크의 기능을 쓸 수 있다.

• FIL (Filecoin) — 분산 스토리지를 빌릴 때 결제 수단
• LINK (Chainlink) — 오라클 데이터 요청할 때 지불
• RNDR (Render) — GPU 자원 빌릴 때 결제
• ETH — 사실 가장 큰 유틸리티 토큰. 이더리움 위에서 뭘 하든 가스비로 필요

가치의 근거가 "이 네트워크를 쓰려는 수요" 에 직결된다.

#거버넌스 토큰 (Governance Token)

프로토콜의 의사결정에 참여할 권리를 주는 토큰이다. 1토큰 = 1표 형태로, 안건을 제안하고 투표할 수 있다.

• UNI (Uniswap) — 거버넌스 토큰의 시초
• AAVE (Aave) — 대출 프로토콜 운영 의결
• COMP (Compound)
• ARB (Arbitrum) — L2 자체 운영 결정
• CRV (Curve) — 대표적인 veToken 모델 (락업 기간 길수록 의결권 ↑)

거버넌스 토큰은 "회사 주식"과 비슷한 면이 있지만, 실제로 의결권 외에 수익 분배가 약하다는 게 비판점이다. 그래서 최근엔 수수료 일부를 토큰 홀더에게 돌려주는 모델(Aave, MakerDAO)이 늘고 있다.

#페이먼트 토큰 (Payment Token)

순수하게 결제 수단으로 쓰이는 토큰. 비트코인이 원조이고, 스테이블코인이 사실상 후계자다.

• BTC — 디지털 금 + 결제
• USDT, USDC — 디지털 달러
• XRP — 국가 간 송금 인프라

#시큐리티 토큰 (Security Token)

증권형 토큰 — 회사 지분, 채권, 부동산 권리 같은 법적 자산을 토큰화한 것. 미국 SEC 같은 금융 당국 규제를 받는다. 일반 거래소엔 거의 안 올라온다(법적으로 못 올림).

RWA 트렌드와 직결되는 개념. BlackRock의 BUIDL이 사실상 시큐리티 토큰 형태.

#밈 토큰 (Meme Token)

커뮤니티와 농담, 내러티브로만 가치가 형성되는 토큰. 펀더멘털이 거의 없거나 의도적으로 만들지 않는다.

• DOGE, SHIB — 1세대
• PEPE, WIF, BONK — 2세대
• GOAT, FARTCOIN — AI 시대 밈

가격이 단기간에 100배 가는 일이 흔한 만큼, 99% 죽는 일도 흔하다. 짧은 사이클로 돈다.

#NFT (Non-Fungible Token)

대체 불가능한 토큰. 1 ETH = 1 ETH지만, NFT는 각각이 고유하다(그림, 게임 아이템, 멤버십 등).

ERC-721이 표준. 2021년 PFP(프로필 사진) 광풍 이후 시들했다가, 2024–2026년에는 티켓·멤버십·게임 아이템 같은 실용적 용도로 자리 잡고 있다.

#5. DeFi 핵심

#DEX / AMM / LP

• DEX(탈중앙 거래소): 회사가 운영하는 게 아니라 스마트 컨트랙트가 자동으로 매매 처리. 유니스왑, 라이덴(Raydium), 이더(Aerodrome) 등.
• AMM(자동 시장 조성자): DEX의 핵심 알고리즘. x * y = k 같은 수식으로 가격을 자동 결정.
• LP(Liquidity Provider, 유동성 공급자): 풀에 자기 자산을 넣어주는 사람. 다른 사람이 거래할 때 발생하는 수수료를 받아 간다.

LP는 왜 자기 돈을 풀에 넣어줄까?

거래 수수료의 일부를 지분만큼 가져가기 때문. 보통 거래액의 0.05–1%가 풀에 쌓이고, 이게 LP들에게 분배된다. 거래량 많은 풀(USDC/ETH 같은)은 연 5–30% 수익이 나기도 한다.

다만 공짜는 아니다. 두 토큰의 가격 비율이 변하면 손실(아래 IL) 위험이 따라온다.

#비영구손실 (IL, Impermanent Loss)

LP의 가장 큰 리스크. 풀에 넣은 두 토큰의 가격 비율이 변하면, 그냥 들고만 있었을 때보다 금액이 적어지는 현상이다.

예) ETH/USDC 풀에 절반씩 넣어뒀는데 ETH가 2배 뛰면 → 풀 안에서는 ETH가 자동으로 팔려나간다 → 결국 그냥 ETH 들고 있던 거보다 덜 받게 됨.

수수료 수익이 IL보다 크면 이득이지만, 변동성 큰 알트코인 페어는 수수료 받아도 손해인 경우가 흔하다. "Impermanent(일시적)" 손실이라고는 하지만, 풀에서 빼면 그 손실은 확정된다.

#스테이킹 (Staking)

PoS 체인에서 자기 코인을 락업해서 검증자 활동에 동참하고, 그 대가로 이자(연 3–7% 수준) 를 받는 구조. 이더리움이 대표적.

검증자는 왜 코인을 락업하나?

단순히 이자 때문이지만, 그게 다는 아니다. 락업된 코인은 보증금 역할을 한다. 부정행위(이중 서명, 다운타임)를 하면 락업한 코인의 일부가 슬래싱(몰수) 된다. 즉, "내 돈 걸고 정직하게 검증하겠다"는 약속이 곧 PoS의 보안 모델.

#리퀴드 스테이킹 (LST, Liquid Staking Token)

스테이킹하면 코인이 묶여서 못 쓰는 게 단점이었다. 그래서 락업한 만큼 거래 가능한 토큰을 대신 발행해주는 게 리퀴드 스테이킹이다.

ETH를 Lido에 맡기면 stETH를 받고, 그 stETH는 자유롭게 다른 DeFi에서 쓸 수 있다. mETH(Mantle), rsETH(Rocket Pool) 등도 같은 개념.

#리스테이킹 / LRT

2024년부터 폭발적으로 커진 영역이다. 한 줄 요약: 이미 스테이킹된 ETH를 한 번 더 빌려줘서 추가 보상을 받는 것.

원래 스테이킹된 ETH는 이더리움 보안에만 쓰였다. 그런데 EigenLayer가 이런 아이디어를 냈다 — "이 보안을 다른 프로토콜(롤업, 오라클 등)에 빌려주자. 그 프로토콜이 보안 빌리는 대가로 토큰을 더 줄 거다."

리스테이킹된 자산을 거래 가능한 토큰으로 또 만든 게 LRT (Liquid Restaking Token): ezETH(Renzo), weETH(Ether.fi), rsETH(Kelp) 등.

이자가 이중·삼중으로 쌓이는 구조라 매력적이지만, 리스크도 그만큼 쌓인다는 점은 기억해야 한다.

#인텐트 (Intent) 기반 아키텍처

기존 DEX는 사용자가 "USDC → ETH로 바꾸겠다" 라고 직접 명령했다. 인텐트는 사용자가 의도만 표현하고, 솔버(Solver) 라는 외부 주체가 가장 좋은 경로를 찾아서 실행하는 방식이다.

사용자: "0.5% 슬리피지 안에서 USDC를 ETH로 바꾸고 싶어" 솔버들: 경쟁해서 가장 유리한 경로를 제안 → 가장 좋은 게 채택됨

CowSwap, UniswapX, 1inch Fusion이 대표적. 2026년 들어 거의 모든 신규 DEX가 인텐트 모델을 채택하고 있다.

#6. DAO와 거버넌스

#DAO (Decentralized Autonomous Organization)

탈중앙 자율 조직. 주식회사 같은 전통 조직이 CEO·이사회로 운영된다면, DAO는 토큰 홀더들의 투표로 운영되는 조직이다.

운영 방식이 회사보다 훨씬 단순하다.

1. 누가 안건(프로포절)을 올린다 — "수수료를 0.3%에서 0.25%로 낮추자"
2. 토큰 홀더들이 정해진 기간 안에 투표한다
3. 쿼럼(Quorum, 의결 정족수) 을 넘기고 찬성이 많으면 통과
4. 통과되면 스마트 컨트랙트가 자동으로 집행한다 (사람이 손댈 필요 없음)

대표적인 DAO들:

• Uniswap DAO — 수수료 정책, 신규 체인 배포 의결
• Arbitrum DAO — L2 트레저리(약 35억 달러 규모) 운영
• MakerDAO (현 Sky) — 스테이블코인 DAI/USDS 운영
• Nouns DAO — 매일 NFT 1개 경매 → 수익으로 펀딩

#거버넌스에서 자주 보는 단어

DAO 투표에 왜 시간 쓰며 참여하나?

단순히 이상주의가 아니다. 프로토콜이 잘 굴러가야 → 토큰 가치가 유지·상승 → 곧 자기 자산 가치다. 큰 토큰을 들고 있는 펀드·기관은 풀타임 거버넌스 담당자를 두고 적극 참여한다. 어떤 DAO는 투표 참여 자체에 보상을 주기도 한다.

#DAO의 한계도 알아두자

이상적으로는 모든 토큰 홀더가 평등하지만, 실제로는 고래(큰 손) 몇 명이 결정권을 좌우하는 경우가 많다. 투표 참여율이 5% 미만인 DAO도 흔하다. "탈중앙"이라는 명분과 현실의 운영은 따로 노는 경우가 많다는 점도 기억해두자.

#7. 시장에서 자주 보는 지표

#8. 2026년 메가 내러티브

#RWA (Real World Assets, 실물 자산 토큰화)

미국 국채, 부동산, 회사 채권 같은 현실 자산을 토큰으로 만들어 온체인에서 거래하는 분야. 2024년에 BlackRock의 BUIDL 펀드(이더리움 기반 미국 국채 펀드)가 출시되면서 본격화됐고, 2026년 시점에 온체인 RWA 규모가 100억 달러를 넘었다.

스테이블코인이 "디지털 달러"였다면, RWA는 "디지털 채권·부동산"이다.

#DePIN (Decentralized Physical Infrastructure Network)

개인이 자기 자원(GPU, 스토리지, 와이파이, 차량 데이터)을 제공하고 토큰으로 보상받는 네트워크. 클라우드를 AWS 한 회사가 아니라 수많은 사람들이 분산 제공하는 구조다.

• Helium — 와이파이/5G 핫스팟 공유
• Filecoin — 분산 스토리지
• Render / Akash — GPU 자원 임대 (AI 학습용)
• Hivemapper — 운전자가 도로 매핑하면 토큰

AI 붐과 맞물려 GPU 계열 DePIN이 특히 주목받고 있다.

#AI 에이전트 토큰

2024–2025년에 새롭게 등장한 카테고리. 자율 AI가 자기 명의로 트위터 운영하고, 자기 지갑으로 거래도 하고, 자기 토큰도 발행한다. 인간이 일일이 컨트롤하지 않는다.

• Truth Terminal / GOAT — 첫 "밈코인을 만든 AI"로 화제
• ai16z — AI 에이전트 펀드 컨셉
• Virtuals Protocol (Base 위) — 누구나 AI 에이전트 발행 가능한 플랫폼

기술적으로는 LLM + 지갑 + 자율 의사결정 루프가 합쳐진 형태. 2026년에는 이 카테고리만 시총 수십억 달러 규모가 됐다.

#비트코인 생태계 부활

오랫동안 "BTC는 그냥 디지털 금" 정도였는데, 2023년부터 폭발했다.

• Ordinals (2023): 비트코인에 NFT 새기기
• BRC-20 (2023): 비트코인 위에 토큰 발행 표준
• Runes (2024): BRC-20보다 효율적인 새 토큰 표준
• Bitcoin L2: Stacks, Babylon, B² Network — 비트코인을 담보로 DeFi
• BTCFi: 비트코인을 그냥 들고만 있지 말고 스테이킹·대출 등에 활용

#펌프펀 (pump.fun) / 밈코인 슈퍼사이클

솔라나에 등장한 누구나 5초 만에 코인을 발행할 수 있는 플랫폼. 24시간에 수만 개의 밈코인이 만들어지고 99%는 사라진다. 2024–2026 밈코인 슈퍼사이클의 진앙지.

밈코인은 펀더멘털이 없다. 순수하게 커뮤니티 + 내러티브 + 타이밍의 게임이라 단기 변동성이 극단적이다. 99%는 본전도 못 회복한다는 점은 기억해두자.

#9. 알아두면 좋은 보안 용어

• 러그풀(Rug Pull) — 개발자가 유동성 들고 도망가는 것. 신생 토큰의 가장 흔한 사기 패턴.
• 익스플로잇(Exploit) — 스마트 컨트랙트 취약점을 이용한 해킹.
• 샌드위치 공격 — 누가 큰 거래 보낼 때, 그 앞뒤로 자기 거래를 끼워서 차익을 뜯는 MEV의 한 종류.
• 멀티시그(Multi-sig) — 여러 개인키가 동의해야 거래되는 지갑. 팀·DAO 자금 관리 표준.
• MPC 지갑 — 키를 여러 조각으로 나눠 분산 보관. 한 조각만 유출돼도 안전. 거래소·기관용.
• 슬래싱(Slashing) — PoS 검증자가 부정행위 시 스테이킹된 자산이 일부 몰수되는 것. 리스테이킹할수록 슬래싱 누적 리스크.

#10. 토큰 발행·배포 관련 용어

신규 프로젝트 글에서 자주 보이는 단어들.

• TGE (Token Generation Event) — 토큰 최초 발행 시점. 이때부터 거래 시작.
• 베스팅 (Vesting) — 토큰 락업. 팀·투자자가 받은 토큰을 일정 기간 못 팔게 묶어둠.
• 클리프 (Cliff) — 베스팅 시작 전 완전 잠금 기간. "12개월 클리프 + 24개월 선형 베스팅" = 1년간 0원, 그 후 2년에 걸쳐 풀림.
• 언락(Unlock) — 베스팅 풀리는 시점. 보통 가격 하락 압력 → "클리프 풀리는 날"은 매도 주의 시점.
• 에어드롭(Airdrop) — 무료 토큰 배포. 보통 초기 사용자·테스터에게.
• 화이트리스트(Whitelist, WL) — 사전 등록자. 우선 매수권·에어드롭 자격.
• 시빌(Sybil) — 한 사람이 지갑 100개 만들어서 에어드롭 어뷰징하는 행위. 프로젝트는 시빌 필터링으로 잡아낸다.

프로젝트는 왜 토큰을 공짜로 뿌리나?

마케팅비라고 보면 된다.

(1) 사용자 확보 — 에어드롭 노린 유저들이 미리 써보고 데이터 쌓음.

(2) 거버넌스 분산화 — 토큰이 몇 사람에게 몰리면 "탈중앙"이라는 명분이 깨짐.

(3) 입소문 — 에어드롭으로 큰 돈 받은 사용자가 자연스럽게 홍보.

결국 "공짜로 주는 게 광고비보다 싸다"는 계산.

• 토크노믹스(Tokenomics) — 그 토큰의 발행량·분배·인플레이션 정책 전체를 통칭.
• 메인넷(Mainnet) / 테스트넷(Testnet) — 실제 네트워크 vs 시험 네트워크. 테스트넷 토큰은 가치 없음.
• 포셋(Faucet) — 테스트넷 토큰 무료로 받는 곳.

#11. 시장에서 자주 쓰는 슬랭

코인 트위터·디스코드·텔레그램 보다 보면 한국어 안에 영어 약어가 섞여 나온다.

#마무리

용어집은 한 번 읽고 끝낼 게 아니다.

트위터 글 읽다가, 디스코드에서 토론 보다가, 새로운 프로젝트 글 읽다가 모르는 단어가 튀어나올 때마다 다시 와서 찾아보면 된다. 그러다 보면 자기도 모르게 익숙해진다.

코인 시장은 1년만 안 봐도 새 단어가 산더미처럼 쌓인다. 2026년 4월 기준 위 용어들이 메인이지만, 6개월 뒤엔 또 새로운 게 메이저로 올라와 있을 거다. 그게 이 시장 속도다.

모르는 단어가 나오면 단어부터 알아두자. 단어를 안다고 돈을 버는 건 아니지만, 적어도 남들이 무슨 얘기 하는지는 알아듣고 시작할 수 있다.

내가 넣은 주문 가격이랑 실제 체결 가격이 다르다. 슬리피지다.

또는 뭔가 스왑을 하려는데 트랜잭션이 갑자기 실패하면서 가스비만 날아간다.

더 황당한 건 내 트랜잭션이 블록에 올라가기 직전에 봇이 먼저 끼어들어 가격을 올려놓고 이득을 챙기는 MEV다.

기존 AMM DEX 구조에서 이 문제들은 구조적이다.

근본적으로 고치기 어렵다.

Dango를 처음 봤을 때 "또 DEX냐" 했는데, 들여다보니 접근 자체가 달랐다. AMM을 개선한 게 아니라 아예 버리고 CLOB으로 갔다. 그것도 온체인에서, 자체 Layer 1을 만들어서.

#Dango가 뭔지부터

한 줄 요약: 자체 Layer 1 위에서 완전한 온체인 CLOB을 돌리는 DeFi 슈퍼앱이다.

기존 DEX와 비교해보면 차이가 선명하다.

CEX에서 당연하게 쓰던 기능들 — 지정가 주문, 정확한 체결 가격, 깊은 호가창 — 을 DEX에서 구현하겠다는 거다.

#메인넷 일정 — 지금 어디까지 왔나

Dango는 2025년부터 단계적으로 진행해왔다.

• 2025년 Q1: Testnet 1 공개. 온체인 CLOB 스팟 거래(ETH/BTC/SOL), 패스키 계정 시스템 테스트
• 2025년 중반: Testnet 1.5 → 알림 시스템, 사람이 읽기 좋은 유저네임, 블록 탐색기 추가
• 2025년 Q3~Q4: Testnet 2 → 볼트, 대출, 크로스체인 브릿지(Hyperlane), 고급 주문 타입 추가
• 2025년 5월: Galxe Starboard 참여. 테스트넷 OAT 배포 시작
• 2026년 1월: 메인넷 알파 공개. ETH/USDC 스팟 거래 시작. 실험적 운영 단계
• 2026년 3월: Perps(퍼페추얼) 출시. 온체인 CLOB 방식의 퍼프 거래 지원
• 2026년 3월 31일: 포인트 파밍 캠페인 시작 발표
• 2026년 4월 13일: 포인트/배지 파밍 공식 시작 예정 → 당일 퍼프 익스플로잇 발생, 체인 일시 중단
• 현재: 익스플로잇 해결, 재개 완료 (불안정 구간)

포인트 캠페인 시작일에 하필 익스플로잇이 터진 거라 타이밍이 좀 묘하다. 이 부분은 뒤에서 따로 다룬다.

#Grug 실행 환경 — 이게 왜 중요한가

Dango는 Grug라는 자체 실행 환경 위에 만들어졌다. EVM(이더리움 가상머신)과는 다른 접근이다.

체인 스펙을 보면 생각보다 퍼포먼스가 빠르다.

• 배치 경매 주기: 0.2~0.5초 (주문 매칭이 이 주기로 일어남. 블록타임과는 별개)
• 합의 방식: CometBFT(구 Tendermint) 기반, 약 20개 PoA 검증자
• 즉시 완결성 (파이널리티)
• 검증자 선발: Left Curve Foundation(LCF)이 비용·평판·운영 품질 기준으로 직접 선정

Grug가 가능하게 하는 핵심 기능들이다.

마진 계정 (Margin Account)

사용자는 하나의 계정에 자산을 넣고, 그걸 담보로 여러 활동을 동시에 할 수 있다. 스팟 거래, 퍼페추얼 거래, 대출, 수익 파밍을 하나의 포지션에서 관리한다.

기존 DeFi처럼 "이 프로토콜엔 ETH 넣고, 저 프로토콜엔 USDC 넣고, 또 저기엔..." 이런 자본 분산이 없다. 스팟에서 쓰던 담보를 그대로 퍼프에서도 쓸 수 있다.

지갑리스 계정 시스템

이게 좀 신기하다. Dango에 가입할 때 시드 프레이즈를 따로 발급받지 않는다.

대신 트위터 계정 만들듯이 유저네임을 고른다. 예: @larry. 이 유저네임이 온체인 신원이 되고, 주소 대신 유저네임으로 송금·거래 내역 조회가 가능하다.

인증은 Passkey로 처리된다. Touch ID, Face ID, Windows Hello 등 기기 생체인증을 그대로 쓴다. iCloud·Google 계정으로 자동 동기화되어 기기를 바꿔도 그대로 쓸 수 있다.

MetaMask 같은 브라우저 확장 지갑이 필요 없다. DeFi를 처음 접하는 사람도 진입 장벽이 크게 낮아진다.

서브계정

마스터 계정 아래 여러 개의 서브계정을 만들 수 있다. 전략별 리스크 분리, API·봇 자동화, 팀 트레이딩 시 권한 분리 등에 활용한다.

주기적 배치 경매 (Periodic Batch Auction)

주문을 실시간으로 즉시 처리하는 대신, 짧은 주기로 모아서 한 번에 처리한다.

봇이 트랜잭션 순서를 조작할 틈이 없다. MEV 저항성이 구조적으로 생긴다.

가스비를 USDC로 납부

트랜잭션 수수료를 DNG 토큰이 아닌 USDC로 낸다. 가스비를 내려고 따로 토큰을 준비할 필요가 없다.

이 수수료는 공개 시장에서 DNG를 매입해 소각(burn)하는 데 쓰인다. DNG의 공급이 줄어드는 디플레이션 구조다.

크로스체인 브릿지

체인 간 자산 이동은 Hyperlane 프로토콜로 처리한다. Grug 실행 환경에 직접 통합되어 있다.

#팀과 자금 — 믿을 수 있는 프로젝트인가

새 DeFi 프로젝트를 볼 때마다 "러그풀 아니야?" 먼저 확인하는 습관이 생겼다. Dango에서 확인한 것들이다.

개발사

Left Curve Software 가 개발을 맡고 있다. 소규모 기술 팀이다.

창업자는 larry0x — Cosmos 생태계 베테랑으로, Mars Protocol 개발에도 참여했던 인물이다. 익명이지만 DeFi 개발자로서의 트랙 레코드가 있다.

프로토콜 관리 및 검증자 선발은 Left Curve Foundation(LCF) 이 담당한다.

자금 조달

• 2024년 11월 시드 라운드: 360만 달러
• 리드 투자자: Hack VC, Lemniscap
• 참여: Delphi Labs, Cherry Crypto, Interop, Public Works

Hack VC는 Sui, Aptos, Solana 생태계 투자로 알려진 곳이다.

Delphi Labs는 DeFi 분석으로 업계에서 신뢰받는 리서치+투자사다.

자금 규모는 크지 않지만 투자자 라인업이 검증의 역할을 한다.

보안 감사

출시 전까지 총 5건의 외부 감사를 완료했다.

Sherlock 콘테스트는 외부 보안 연구자들이 버그를 찾는 방식이라 단순 감사보다 범위가 넓다. 보안에 상당히 투자한 편이다.

#4월 13일 익스플로잇 — 포인트 캠페인 당일에 생긴 일

포인트 파밍 전략을 보기 전에 이걸 먼저 짚고 넘어가야 한다.

2026년 4월 13일, 포인트/배지 파밍이 공식 시작되는 그날, 퍼프 컨트랙트에서 익스플로잇이 발생했다.

어떤 버그였나

퍼프 보험 펀드에는 누구나 자금을 기부(donate)할 수 있는 함수가 있었다. 문제는 이 함수가 기부 금액이 양수인지 검증하지 않았다.

공격자는 음수 금액을 넣어서 돈이 들어가는 게 아니라 나오게 만들었다. 결과적으로 $1.9M USDC가 퍼프 컨트랙트에서 빠져나갔다.

어떻게 됐나

• 공격자는 $410K를 이더리움으로 브릿지했고, 나머지 $149만은 Dango 체인 내에 잔류했다
• Dango 팀이 체인을 즉시 중단하고 SEAL-911 보안 팀을 개입시켰다
• Circle, 주요 거래소에 해당 지갑 주소를 통보했다
• 공격자에게 버그 바운티를 제안했고, 공격자는 전액 반환 후 버그 바운티를 수령했다

결론: 유저 자산 피해 없음. 자금 전액 회수.

단, 이 사건으로 포인트 프로그램은 일시 중단됐다. 취약한 기부 로직은 제거됐고, 추가 보안 검토 후 재개 예정이다. 퍼프 컨트랙트 자체의 주문 매칭, PnL 정산, 청산 로직은 이번 버그와 무관했다는 게 팀 입장이다.

#DNG 토큰 — 아직 미발행, 이게 기회

DNG는 아직 공개 시장에 상장되지 않은 미발행 토큰이다. TGE는 2026년 Q4(4분기) 로 예정되어 있다.

총 공급량: 미정 (업데이트됨)

초기에는 30,000개로 발표됐었다. Yearn Finance 런칭 당시의 공급량(30,000개)을 오마주한 제안이었는데, 파운더 larry0x가 직접 "커뮤니티 대부분이 레퍼런스를 이해하지 못해 혼란이 생겼다"며 이 계획을 철회하고 보다 일반적인 공급량으로 출시하겠다고 밝혔다.

구체적인 공급량과 배분 내역은 TGE 전 공식 발표를 통해 확인해야 한다.

DNG 토큰의 역할 (변경 없음)

DNG 토큰의 역할

• 가스비 결제용이 아님 (가스는 USDC로 냄)
• 플랫폼 수수료 전액을 DNG 매입·소각에 사용
• 거래량이 늘수록 소각이 늘어나는 디플레이션 구조

포인트 → DNG 전환 자체는 공식 방향이지만, 포인트 1점당 DNG 몇 개인지는 시즌 종료 전까지 확정되지 않는다.

참여자가 많아질수록 같은 포인트로 받는 DNG가 줄어드는 구조다.

#에어드랍 전략 — 포인트 파밍 완전 분석

익스플로잇 이후 재개된 상태다. 다만 아직 살짝 불안정한 구간이라 모두가 참여하는 분위기는 아니다. 할 사람은 하고 있고, 안 하는 사람은 좀 더 지켜보는 중이다.

재개된 지금, 매주 100만 포인트가 배분되는 구조로 돌아왔다.

배분 구조는 이렇다.

이 100만 포인트를 해당 주에 활동한 모든 참여자가 나눠 갖는다.

내 점유율이 높을수록 더 많이 받는다. 절대량이 아니라 상대 비율이다.

#OAT 부스트 — 테스트넷 참여자 우대

Galxe OAT (On-Chain Achievement Token) 를 보유하면 포인트에 배수가 붙는다.

OAT 1개당 +100% 부스트, 최대 4개까지 = 최대 +400% (4배)

OAT는 테스트넷 기간에 Galxe 퀘스트를 통해 배포됐다. Testnet Trader OAT, Last Hurrah OAT 등 여러 종류가 있었고, 현재는 모든 Galxe 캠페인이 종료된 상태다. 신규로 OAT를 받는 건 불가능하다.

OAT 부스트는 이미 OAT를 보유한 사람에게만 적용된다. 테스트넷부터 참여했다면 그게 지금 실질적인 경쟁 우위다.

단, OAT 부스트는 포인트 캠페인 시작 기준 4주 한정이다. 이미 보유 중이라면 재개 직후 EVM 지갑을 Dango 계정에 연동해서 부스트를 활성화해야 한다.

#전략 1. Perps 거래 — 포인트 파밍의 메인 트랙 (75만/주)

전체 포인트의 75%가 Perps 트레이더에게 간다. 포인트를 가장 많이 쌓으려면 이걸 해야 한다.

Dango 메인넷에서 ETH, BTC, SOL 등 자산의 퍼페추얼 선물을 거래한다.

레버리지를 써서 롱/숏 포지션을 잡는 방식이다.

포인트 배분 원리

75만 포인트를 해당 주에 거래한 모든 Perps 트레이더가 거래량 비중대로 나눠 갖는다.

내 거래량 / 전체 거래량 = 내 포인트 점유율.

거래 수수료 구조 (14일 롤링 거래량 기준)

거래량이 쌓일수록 수수료가 낮아지는 구조다. Maker 주문(지정가)이 항상 Taker보다 저렴하다.

OAT 4개 보유 시 효과

같은 거래량으로 OAT 없는 사람 대비 4배 포인트를 받는다.

경쟁자가 1만 달러를 거래할 때 나는 같은 금액으로 4만 달러어치 포인트를 챙기는 셈이다.

주의할 점

Perps는 레버리지 상품이다. 방향이 틀리면 손실이 난다.

포인트 파밍 목적으로 무작정 포지션을 키웠다가 청산당하면 포인트는 의미가 없다.

작은 레버리지로, 또는 롱/숏을 동시에 열어서 델타 중립 포지션을 유지하는 방법을 쓰는 파머들이 있다. 다만 이 경우 펀딩비 비용이 발생한다.

#전략 2. 볼트 예치 — 안정형 포인트 파밍 (25만/주)

Dango 볼트에 자산을 예치하면 볼트 예치자 풀(주당 25만 포인트)에서 내 점유율만큼 받는다.

왜 볼트인가

• 직접 거래 없이 포인트를 받을 수 있다
• 볼트는 패시브 마켓 메이킹 역할을 한다
• CLOB의 유동성을 높이는 데 기여하고 그 보상을 받는 구조

전체 포인트의 25%만 배분된다. 같은 자금을 넣어도 Perps 거래자 대비 포인트 잠재량이 낮다.

단, 청산 리스크가 없고 단순히 예치만 하면 되기 때문에 거래를 잘 모르는 사람에겐 현실적인 선택이다.

#전략 3. 루트박스 — NFT 획득 경로

포인트와 별개로, 거래량을 쌓으면 루트박스를 받는다.

루트박스를 열면 NFT 1개가 나온다. 희귀도는 Common부터 Mythic까지 랜덤이다.

각 NFT에는 숨겨진 포인트 가치가 있고, 포인트 프로그램이 종료될 때 공개된다. 희귀도가 높을수록 더 많은 포인트로 환산될 가능성이 높다.

볼트 예치만으로는 루트박스가 쌓이지 않는다. 거래량이 있어야 한다.

#전략 4. 리그 시스템 — 랭킹 경쟁

포인트 보유량을 기준으로 매주 순위가 갱신되며, 7개 리그로 분류된다.

공식 문서 기준으로 리그 자체에는 별도 보상이 없다 — "순전히 재미용"이라고 명시되어 있다. 포인트 순위가 에어드랍 배분에 직접 영향을 주는 건 아니다.

#전략 5. 추천인(Referral) — 패시브 포인트 수익

2계층 추천인 구조가 있다.

• 직접 추천: 내가 초대한 사람이 포인트 5점을 벌면 나도 1점 추가 획득 (20%)
• 간접 추천: 내 추천인의 추천인이 포인트 20점을 벌면 나도 1점 추가 획득 (5%)

직접 거래 없이 네트워크 효과로 포인트가 쌓인다. 지인 중 Perps를 활발히 거래하는 사람에게 추천 링크를 전달하면 꾸준한 패시브 포인트 수입이 생긴다.

#전략 6. OAT 연동 — 이미 있다면 지금 바로

Galxe OAT 캠페인은 이미 종료됐다. 지금 새로 받을 수 없다.

테스트넷 때 Dango Galxe 퀘스트에 참여했다면 지갑에 OAT가 남아있을 가능성이 있다. 확인 방법:

• Galxe 앱에서 내 지갑 연결 후 보유 OAT 확인
• Dango 계정 설정에서 해당 EVM 지갑 연동 → 자동으로 부스트 적용

OAT 부스트 유효기간(4주)이 지나기 전에 연동하지 않으면 그냥 날아간다. 보유 중이라면 재개 직후 바로 확인해야 한다.

#전략 7. 포트폴리오 구성 — 현실적 접근

자금 규모별 현실적인 전략을 정리하면 이렇다.

소액 참여자 ($100~$500)

Perps 거래 위주로 가되, 레버리지를 낮게 유지한다. 볼트에 일부 예치.

중간 참여자 ($500~$5,000)

Perps 거래 + 볼트 예치 병행. OAT가 있으면 연동부터.

OAT 4개 × Perps 거래량 = 같은 자금으로 4배 포인트. 볼트엔 일부 예치해서 안전망 확보.

적극적 참여자 ($5,000+)

OAT 풀 부스트 + Perps 거래량 최대화. 루트박스 골드/크리스탈 등급 목표. 델타 중립 전략 고려 (펀딩비 비용 계산 필요).

#락드랍 — 포인트 파밍과는 별개의 DNG 획득 경로

포인트 파밍 외에 DNG를 받을 수 있는 또 다른 공식 경로가 있다. 락드랍(Lockdrop) 이다.

TGE 시점에 Dango의 세 가지 풀 중 하나에 자산을 잠그면 DNG를 받는 구조다.

락업 대상 풀

• AMM 풀
• 마진 풀
• 퍼프 상대방 풀 (Perp Counterparty Pool)

핵심: 락업 기간이 길수록 비선형적으로 더 많이 받는다

단순히 2배 기간 = 2배 토큰이 아니다.

락업 기간이 길수록 받는 DNG 양이 가속적으로 늘어난다. 짧게 잠그면 조금, 길게 잠그면 훨씬 많이. 장기 참여자를 우대하는 구조다.

포인트 파밍은 지금 당장 시작할 수 있고, 매주 거래량과 예치를 통해 꾸준히 포인트를 쌓는 방식이다.

락드랍은 TGE 시점에 한 번에 자산을 잠그는 별도 이벤트다. 둘 다 DNG를 받는 경로지만, 락드랍은 아직 시작되지 않았다.

TGE 날짜와 락드랍 세부 조건이 공식 발표되면 그때 본격적으로 전략을 짜야 한다. 지금은 포인트 파밍을 하면서 락드랍 공지를 놓치지 않는 게 맞다.

#리스크 — 이것도 반드시 읽어야 한다

#1. 메인넷 알파 + 실제 익스플로잇 경험

지금 Dango는 알파 상태다. 그리고 이번에 실제로 익스플로잇이 터졌다.

다행히 전액 회수됐고 유저 피해는 없었다. 지금은 재개된 상태지만 아직 완전히 안정됐다고 보기는 어렵다. 알파 체인이라는 전제를 잊지 말고, 잃어도 괜찮은 금액으로 참여하는 게 맞다.

#2. Perps 거래 청산 리스크

포인트 파밍 목적으로 Perps 포지션을 키우다가 시장이 반대로 움직이면 청산된다.

포인트는 쌓였을지 몰라도 원금이 사라진다. DNG 에어드랍 가치가 원금 손실을 보상할 것이란 보장은 없다.

#3. DNG 토큰 가치 불확실성

현재 DNG는 시장에서 가격이 형성되지 않았다. 에어드랍을 받아도 실제 토큰 가치가 기대에 못 미칠 수 있다.

TGE 이후 초기 물량이 시장에 쏟아지면 가격이 급락하는 경우가 허다하다.

#4. 포인트 전환 비율 불확실성

포인트를 쌓기 위해 실제 자산을 쓰고 있다 (거래 수수료, 펀딩비 등).

시즌 종료 시점에 총 포인트 합산에 따라 전환 비율이 결정된다. 참여자가 많아질수록 내 포인트 가치가 희석된다.

#5. 재개 후 불안정 구간

지금은 재개됐지만 여전히 불안정한 구간이다.

할 사람은 하고 있고, 지켜보는 사람도 있다. 어느 쪽이 맞다고 할 수 없다. 본인이 감수할 수 있는 금액 안에서 판단하면 된다.

#6. 규제 리스크

레버리지 DEX는 규제 기관이 관심을 가질 여지가 있다. 특히 특정 국가에서의 접근이 제한될 수 있다.

#참여 방법 — 단계별 정리

1. dango.exchange 접속
2. 계정 생성 (유저네임 선택, Passkey 또는 지갑 연결)
3. USDC 또는 ETH를 브릿지해서 입금 (이더리움, Base, Arbitrum, Polygon 지원) — 최소 $10 이상 입금해야 계정이 활성화된다
4. 테스트넷 OAT 보유 여부 확인 (Galxe 앱에서 내 지갑 확인)
5. OAT가 있으면 Dango 계정에 EVM 지갑 연동 → 부스트 활성화 (4주 한정)
6. Perps 거래 시작 (낮은 레버리지부터, 현재 재개 후 불안정 구간임을 감안)
7. 볼트 예치 (일부 자금)
8. 주간 거래량 목표 설정해서 루트박스 쌓기

정리하면 이렇다.

AMM의 구조적 한계를 Layer 1 + 온체인 CLOB으로 풀려는 시도 자체는 DeFi에서 오랫동안 이야기된 방향이었다. 거기에 지갑리스 계정, 크로스콜래터럴 마진, MEV 저항성을 하나의 앱에 묶었다.

Hack VC + Delphi Ventures가 투자한 프로젝트고, 메인넷이 돌고 있다.

익스플로잇이 터졌다. 전액 회수됐다. 팀 대응은 나쁘지 않았다.

지금은 재개됐고, 살짝 불안정한 상태에서 할 사람들은 이미 하고 있다. 초기라 경쟁이 적은 구간이기도 하다.

불안하면 더 지켜봐도 된다. 들어가기로 했다면 OAT 연동부터 확인하고, 낮은 레버리지로 시작하는 게 맞다.

본 글은 투자 권유가 아닙니다. 모든 투자 결정과 그 책임은 본인에게 있습니다.

USDT, USDC, DAI, FRAX, LUSD... 스테이블코인 세상에 이미 스테이블코인이 넘친다. 이름도 비슷비슷해서 나중에는 구분이 안 된다. 그냥 "달러인 척하는 코인들" 정도로만 기억하게 되는 구간이 온다.

근데 Apyx는 구조가 달랐다. 들여다보다가 "이거 진짜 처음 보는 방식인데?" 했다.

#기존 스테이블코인들이 하는 짓

• USDT/USDC: 달러 예치하고 영수증 발행. 당신 돈으로 이자 챙기고 당신한테는 0% 줌. 이게 무려 수십억 달러 규모로 굴러감.
• DAI: ETH 담보로 달러 빌려줌. 오버콜래터럴이라 자본 효율이 살짝 아쉬움.
• UST: 알고리즘으로 달러 유지한다고 했다가 루나와 함께 역사의 뒤안길로... (명복을 빕니다)

Apyx는 이런 구조들이랑 다르다. 상장된 우선주의 배당금으로 돌아간다.

#Apyx가 뭔지부터

#은행 예금 이야기로 시작해보자

당신이 은행에 100만원을 예치하면 어떻게 되는지 아는가. 은행은 그 돈을 굴려서 수익을 낸다. 기업에 대출해주고, 채권을 사고, 온갖 방법으로 이자를 번다. 그리고 당신한테는 연 3-4% 준다. 나머지는 은행이 챙긴다.

USDT, USDC 같은 기존 스테이블코인도 똑같이 한다. 당신 달러를 받아서 미국채 등에 투자하고 수익을 낸다. 테더(Tether)는 2023년에 이렇게 72억 달러 순이익을 냈다. 직원 100명짜리 회사가. 그 돈 다 어디서 났을까 — 당신 USDT다.

Apyx의 아이디어는 이거다: 그 수익을 사용자에게 돌려준다면?

#Apyx가 실제로 하는 것

한 줄 요약: 배당금 기반 스테이블코인(DBS) (Dividend-Backed Stablecoin) 프로토콜이다.

구체적으로 어떻게 돌아가는지 단계별로 보자.

1단계: 자금 수집

사용자가 달러(USDC 등)를 넣으면 Apyx가 그걸 모은다.

2단계: 우선주 매입

모인 달러로 DAT 기업 (Digital Asset Treasury)의 우선주 (Preferred Stock)를 산다. 구체적으로는:

• STRC — Strategy Inc.(구 MicroStrategy)의 우선주. 연 11.50% 배당 (가변금리, 매월 조정).
• SATA — Strive Inc.의 우선주. 연 13.00% 배당 (가변금리, 매월 조정).

잠깐, Strategy Inc.가 뭐냐고? 마이클 세일러가 만든 회사인데, 지금까지 비트코인을 78만 개 이상 사들인 곳이다 (2026년 4월 기준 약 780,897 BTC). 비트코인 최대 기업 보유자. 이 회사가 자금 조달을 위해 우선주를 발행하고, 우선주 보유자에게 매달 배당금을 준다.

3단계: 배당금 수취

이 우선주에서 매달 배당금이 들어온다. 비트코인 가격이 오르든 내리든, 코인 시장이 죽어있든 간에 배당금은 계약상 의무다. 예측 가능한 현금 흐름이 매달 프로토콜로 들어온다는 뜻이다.

4단계: 배당금을 사용자에게 분배

여기서 핵심이 나온다. 이 배당금을 프로토콜이 독식하지 않고 apyUSD 보유자에게 돌려준다.

사용자 달러 → Apyx → STRC/SATA 우선주 매입 → 매달 배당금 수취 → apyUSD 보유자에게 분배

#왜 하필 우선주냐

"그냥 미국채 사면 되지 않나"라고 생각할 수 있다. 미국채는 안전하지만 수익률이 연 4-5% 수준이다. STRC, SATA 우선주는 연 11-12% 수준이다. 수익률이 두 배 이상 높다.

단, 높은 수익률엔 이유가 있다. 미국채와 달리 우선주는 기업 신용을 바탕으로 한다. 기업이 망하면 배당도 없다. 그래서 리스크가 더 높고, 그만큼 수익률도 높다. (이 부분은 리스크 섹션에서 더 자세히 다룬다.)

#현실적으로 얼마나 버냐

지금 apyUSD의 기본 수익률은 약 연 11-12% APY다. 이걸 DeFi 전략과 결합하면 실질 수익률이 더 올라간다.

비교해보면:

• 은행 예금: 연 3-4%
• USDC(Circle): 이자 없음 (수익은 Circle이 가짐)
• Aave에 USDC 예치: 연 5-6%
• apyUSD 기본 보유: 연 11-12%

물론 이게 공짜는 아니다. 리스크가 있고, 환매에 30일이 걸리고, DeFi 특유의 복잡함이 있다. 하지만 수익률 자체는 DeFi에서도 꽤 경쟁력 있는 숫자다.

#두 개의 토큰

Apyx는 토큰을 두 가지로 쪼갰다. 처음에 "왜 복잡하게 두 개야" 싶었는데 나름 이유가 있다.

apxUSD — 수익 없는 합성 달러

쉽게 말해 "DeFi에서 굴리는 용 달러"다. Curve, Morpho 같은 프로토콜에 예치하거나 담보로 쓸 수 있다. 수익은 없지만 그 대신 유동성이 있다. "일단 달러가 필요해"일 때 쓰는 버전.

apyUSD — 수익이 붙는 스테이블코인

apxUSD를 잠그면 받을 수 있다. 우선주 배당금이 여기로 흘러들어온다. ERC-4626 구조라 토큰 개수는 그대로인데 시간이 지나면서 환율이 오르는 방식으로 수익이 쌓인다. 리베이스 없음. (리베이스 싫어하는 사람들 환호)

단점 하나: 환매 쿨다운이 약 30일이다. "환매"라는 말이 생소하면 그냥 출금이라고 생각하면 된다. apyUSD를 달러로 바꿔서 빼고 싶다 → 요청하고 → 30일 기다림 → 그때서야 달러가 내 지갑으로 온다. 쿨다운 중엔 수익도 안 붙는다. "장기 홀더 우대, 단기 투기꾼 비우대" 정책이라고 보면 된다.

#APYX 거버넌스 토큰 — 아직 안 나왔는데 이게 핵심

아직 출시 전인데 토크노믹스가 꽤 마음에 들었다.

• 총 공급량: 1억 개 고정, 추가 발행 없음
• VC (Venture Capital) 할당 없음 — 이게 진짜 중요하다. VC 물량 락업 풀리면 매도 폭탄 맞는 거 한 번이라도 겪어본 사람은 알 거다.

스테이킹하면 월간 준비금 성장의 50%를 배당받는다. apxUSD 또는 APYX로 수령 선택 가능. 나머지 50%는 준비금으로 쌓여서 프로토콜 담보 비율을 강화한다. 선순환 구조다.

#이 프로젝트 믿어도 되나 — 팀과 현황

새로운 DeFi 프로젝트가 나올 때마다 "이거 러그풀 아니야?"가 먼저 나오는 건 당연하다. 한 번이라도 당해본 사람은 안다. 그래서 확인한 것들을 정리한다.

#팀 배경

Apyx를 만든 팀은 DeFi Development Corp. (Nasdaq: DFDV)를 만든 팀이다. 나스닥 상장사다. 익명 개발팀이 아니라는 얘기다. 공개 시장에서 책임을 지는 구조다.

#자금 조달

• 2026년 1월 시드 라운드: 밸류에이션 7,000만 달러
• 이후 전략적 라운드: 밸류에이션 3억 달러
• 총 조달액: 300만 달러 (밸류에이션 대비 적은 이유는 VC를 일절 배제했기 때문)

VC가 없다는 게 단순한 마케팅 문구가 아니다. 실제로 모든 투자자가 전략적 투자자(Strategic)로만 구성됐다. 락업 풀리면 덤핑하는 VC 물량이 없다.

#현재 규모

• apxUSD 총 발행량: 4,300만 달러+
• apyUSD 잠금 규모: 2,100만 달러+
• 런칭 시점이 2026년 2월임을 감안하면 두 달 만에 이 수치다.

#기관 파트너십

BitGo가 apxUSD의 수탁(custody) 지원을 공식 추가했다. BitGo는 전 세계 수십억 달러 규모의 디지털 자산을 수탁하는 업계 최대 적격 수탁 기관 중 하나다. BitGo 인프라에 올라가는 자산은 보안, 컴플라이언스, 운영 적합성 심사를 통과해야 한다. apxUSD가 그 심사를 통과했다는 뜻이다.

Kraken & xStocks와도 파트너십을 맺고 토큰화 주식(tokenized equity) 확장을 추진 중이다.

#투명성

• 담보 구성 매일 NAV 공개
• 제3자 감사 기관의 월간 증명 리포트 발행
• 프로토콜 담보 비율 실시간 대시보드 제공

"믿어라"가 아니라 "직접 확인할 수 있게 열어뒀다"는 구조다.

#에어드랍 전략 — Apyx Pips

지금 시즌 1 포인트 프로그램이 돌고 있다. 이름은 Pips.

운영 조건: 12주 또는 apxUSD 공급량이 10억 달러에 도달할 때까지. 둘 중 먼저 오는 것 기준.

포인트는 APYX 토큰으로 전환된다. 공식 확정 사항이다. Apyx 팀은 총 공급량 1억 개 중 5%인 500만 APYX를 시즌 1 참여자에게 에어드랍한다고 명시했다. 추측이 아니라 오피셜이다.

포인트 산식은 이렇다.

Pips = USD 금액 × 배수 × 일수

$1,000 넣고 20x 전략 쓰면 하루에 20,000 Pips. 12주(84일)면 총 1,680,000 Pips다.

#활동별 배수 전체 테이블

레퍼럴: 추천인 포인트의 +5% 추가 (상한: 내 포인트의 100%)

#전략별 상세 분석 — 내 상황에 맞는 걸 골라라

#전략 1. YT-apxUSD 보유 (32x) — 공격형

YT(Yield Token)는 Pendle에서 살 수 있다. 개념이 처음에 낯선데, 이렇게 이해하면 쉽다.

"만기까지 apxUSD가 만들어낼 수익을 통째로 미리 사는 것"

예를 들어 apxUSD가 연 10% 수익을 내고 만기가 6개월 남았다면, 그 6개월치 수익(약 5%)을 지금 할인된 가격에 살 수 있다. 실제로는 100달러짜리 수익 권리를 3-4달러에 사는 식이다.

왜 32x냐면 — 3달러로 100달러짜리 수익을 샀으니까 레버리지 효과가 극대화된다. 포인트도 마찬가지로 실제 투입 금액 대비 포인트가 폭발적으로 쌓인다.

Pips 계산 주의사항

YT는 액면가의 3-4%에 거래된다. $500을 써서 YT를 사면 노셔널(notional) 기준으로는 $12,000-$16,000짜리 포지션이 생기는 구조다. Pips가 실제 지출액 기준으로 붙는지, 노셔널 기준으로 붙는지에 따라 숫자가 완전히 달라진다. 공식 문서에 명확히 나와있지 않으므로, 실제 Pips 예상치는 앱에서 직접 포지션을 시뮬레이션해보고 확인하는 것을 권장한다.

배수(32x) 자체는 다른 전략 대비 압도적으로 높다는 것은 변함없다.

단점: 만기가 다가올수록 YT 가격이 0에 수렴한다. 만기 전에 팔거나 포인트 전환 타이밍을 잡아야 한다. "묻어두고 잊는" 전략에는 어울리지 않는다. 타이밍을 신경 쓸 수 있는 사람한테 맞는 전략이다.

#전략 2. LP in apxUSD Pendle market (24x) — 공격형 + 수수료 수익

Pendle의 apxUSD 풀에 유동성을 공급하는 것이다. YT를 사는 것과 달리 LP는 포지션이 상대적으로 안정적이다.

왜 좋냐면

포인트 24x는 두 번째로 높으면서, Pendle 거래 수수료까지 추가로 받는다. 포인트 + 수수료 이중 수령이다.

시뮬레이션

$1,000 넣고 84일 → 24x → 2,016,000 Pips. 같은 금액으로 Commit(20x)했을 때보다 400,000 Pips 더 쌓인다.

단점: 비영구적 손실(IL) 리스크가 있다. apxUSD는 스테이블코인이라 IL이 크지 않지만 아예 없진 않다. 또 Pendle 풀은 만기가 있어서 만기 이후에는 포지션을 재설정해야 한다.

#전략 3. Commit apxUSD (20x) — 안정형 고효율

가장 직관적인 전략이다. apxUSD를 Apyx에 직접 커밋하면 된다. 복잡한 개념 없이 "넣으면 포인트"다.

시뮬레이션

$1,000 커밋 → 20x → 하루 20,000 Pips → 84일 후 1,680,000 Pips

주의할 점: 14일 해제 기간이 있다. 지금 당장 빼려고 해도 14일은 기다려야 한다는 뜻. 급하게 출금할 일 없는 자금을 넣어야 한다.

#전략 4. Curve LP apxUSD/USDC + commit (12x) — 균형형

Curve apxUSD/USDC 풀에 유동성을 공급하고, 거기서 받은 LP 토큰을 다시 커밋해야 12x가 적용된다. 두 단계 필요.

왜 괜찮냐면

• Curve 수수료 수익
• Curve 리워드 (있는 경우)
• Apyx Pips 12x

세 가지를 동시에 받는다. 배수가 낮아 보여도 실제 총 수익률은 상위 전략과 경쟁할 수 있다.

스테이블코인끼리 풀이라 IL 리스크가 거의 없다. apxUSD와 USDC 둘 다 달러 페그 자산이니까. "가장 리스크 낮게 괜찮은 포인트 받고 싶다"면 여기가 답이다.

#전략 5. Morpho Borrow (5x) — 레버리지 전략의 시작점

Morpho에서 apxUSD를 담보로 apyUSD를 빌린다. 배수는 5x로 낮아 보이지만, 이걸 기반으로 레버리지를 만들 수 있다.

레버리지 루프 예시

1. $1,000 apxUSD → Morpho에 담보로 넣음
2. apyUSD 빌림 (예: $700)
3. 빌린 apyUSD → apxUSD로 교환
4. 교환한 apxUSD → 다시 Morpho에 담보
5. 반복

이렇게 하면 실제 자금은 $1,000이지만 포지션은 훨씬 커진다. 당연히 청산 리스크도 같이 커진다. 레버리지 경험이 있는 사람에게만 권한다.

#전략 6. 포트폴리오 분산 — 가장 현실적인 접근

솔직히 하나에 몰빵하는 것보다 나눠 담는 게 심리적으로도, 리스크 관리로도 낫다.

예시: $3,000이 있다면

YT 포지션은 노셔널 기준 계산 여부에 따라 Pips가 크게 달라지므로 앱에서 직접 확인 필요. LP/Commit/Curve 기준으로만 합산해도 84일 후 4,200,000 Pips. 단순 보유(10x)만 했을 때의 2,520,000 Pips 대비 1.7배 이상이다.

#레퍼럴 — 알아두면 쓸모 있는 구조

레퍼럴 구조는 간단하다. 누군가 내 링크로 가입해서 포인트를 쌓으면 그 5%를 내가 추가로 받는다. 자본을 더 쓰지 않고 포인트를 늘릴 수 있는 방법이다.

상한이 있다. 추천인 포인트 합산이 내 자체 포인트의 100%를 넘을 수 없다. 그래서 레퍼럴만으로 포인트 폭탄을 만들기는 어렵고, 본인이 열심히 할수록 레퍼럴 한도도 같이 올라가는 구조다.

셀프 레퍼럴도 된다. 지갑을 두 개 쓰면 가능하다. 지갑 A로 레퍼럴 링크를 만들고, 지갑 B로 그 링크를 통해 가입하면 지갑 A가 B 포인트의 5%를 추가로 받는다. 소소하지만 알아두면 나쁠 건 없다.

이 글의 레퍼럴 링크: https://app.apyx.fi/join/iPG09WN

솔직히 말하면 이 링크로 들어오면 나도 포인트 5% 추가로 받는다. 부담 없이 본인 판단대로 쓰면 된다.

#리스크 — 이것도 반드시 읽어야 한다

좋은 것만 쓰면 광고글이다. Apyx에는 진짜 리스크가 있다. 구체적으로 짚는다.

#1. 우선주 신용 위험 — 가장 현실적인 리스크

Apyx의 수익 원천은 STRC, SATA의 배당금이다. 이 배당금은 기업이 주는 것이다. 만약 해당 기업이 재무 상황 악화로 배당을 삭감하거나 중단하면 어떻게 될까.

apyUSD 수익률이 직격탄을 맞는다. 투자자들이 이탈하면 apxUSD 수요가 줄고, 프로토콜 전체가 흔들릴 수 있다. 이건 "DeFi 리스크"가 아니라 기업 신용 리스크다. DeFi에서 처음 마주치는 종류의 리스크다.

실제로 얼마나 현실적인가: STRC는 Strategy Inc.(구 MicroStrategy)의 우선주다. 마이클 세일러가 비트코인을 대량 보유한 회사. 비트코인이 폭락하면 이 회사 주가가 흔들리고, 극단적으로는 우선주 배당도 위태로울 수 있다.

#2. DAT 사망 나선 — 극단적이지만 이해해야 할 시나리오

비트코인이 50% 이상 급락하는 상황을 가정해보자.

1. DAT 기업(Strategy Inc. 등) 주가 급락
2. 이 기업의 우선주(STRC, SATA) 가격도 하락
3. Apyx의 담보 가치 감소
4. apxUSD 오버콜래터럴 비율이 위험 구간으로 진입
5. 프로토콜이 담보를 청산하기 시작
6. 청산 물량이 시장에 나오면서 추가 하락 압력

루나-테라의 알고리즘 사망 나선과 구조는 다르지만, 비슷한 피드백 루프가 생길 수 있다는 걸 알고 있어야 한다. 개발팀도 이 리스크를 문서에 명시하고 있다.

#3. apxUSD 페그 리스크 — 눈에 잘 안 보이는 위험

apxUSD는 $1에 완전 고정된 게 아니다. 시장에서 수요/공급에 따라 $0.99-$1.01 사이를 오간다. 평소엔 무시할 수 있는 수준이지만, 시장이 패닉 상태에 들어가면 페그가 더 크게 벗어날 수 있다.

실제 시나리오: 갑자기 대형 홀더가 대량 환매를 요청한다. 30일 쿨다운이 있어서 즉시 청산은 못 하지만, 시장에서 apxUSD를 팔기 시작한다. apxUSD 가격이 $0.97까지 떨어진다. 이때 들고 있으면 3% 손실.

소액이면 무시할 수 있지만 큰돈이면 이야기가 다르다.

#4. 환매 쿨다운 — 급할 때 진짜 문제가 된다

"환매(換買)"라는 단어가 낯설 수 있다. 펀드나 금융 상품에서 쓰는 용어인데, 쉽게 말하면 "내 돈 돌려줘" 요청이다. apyUSD를 달러로 교환해서 출금하고 싶을 때 하는 절차다.

문제는 이게 즉시 처리가 안 된다는 거다.

실제 절차를 따라가보자

1. 나: "apyUSD 1,000개 환매 요청합니다" → 클릭
2. 시스템: "접수했습니다. 약 30일 후에 달러로 받을 수 있어요"
3. 그 30일 동안: 내 apyUSD는 잠김 상태, 수익도 안 붙음
4. 30일 후: 달러 1,000달러 + 알파가 지갑으로 도착

은행 예금과 비교하면, 은행 정기예금을 중도해지하면 이자를 덜 주는 것처럼 여기서는 30일 대기 + 그 기간 수익 없음이라는 패널티가 있다. 단, 원금 자체를 깎지는 않는다.

왜 이런 구조냐

Apyx 입장에서 이유가 있다. 프로토콜은 당신 달러로 STRC, SATA 우선주를 매입해서 보유 중이다. 누군가 갑자기 대규모 출금을 요청하면 그 우선주를 팔아서 달러를 마련해야 한다. 우선주는 주식 시장에서 매도해야 하고, 시간이 걸린다. 패닉 매도가 나오면 담보 가치가 훼손된다.

30일 쿨다운은 이걸 방지하는 완충 장치다. 바꿔 말하면 뱅크런(bank run, 대규모 동시 인출 사태)을 구조적으로 막는 설계다.

왜 리스크냐

시장이 갑자기 무너지는 상황을 상상해보자. 비트코인이 하루에 30% 폭락한다. "지금 당장 달러로 빼야 해"라고 생각해도 클릭 한 번으로는 안 된다. 30일을 기다려야 한다. 그 30일 동안 다른 기회를 잡을 수도 없고, 시장이 더 나빠질 수도 있다.

게다가 한 사람당 미결제 요청은 하나만 허용된다. 1,000달러 환매 요청을 넣은 상태에서 추가로 500달러를 더 빼고 싶어도, 처음 요청이 완료될 때까지는 새 요청을 넣을 수 없다.

apyUSD에 자금을 넣을 때는 "이 돈은 최소 30일은 없는 돈"이라고 생각하고 들어가야 한다. 급한 자금은 절대 넣지 말 것.

#5. 스마트 컨트랙트 리스크 — 코드는 항상 틀릴 수 있다

Quantstamp, Certora, Zellic 세 곳에서 감사를 받았다. 업계에서 인정받는 곳들이다. 하지만 감사를 받은 프로토콜도 해킹당한다. 2022년 Nomad Bridge 해킹($190M), 2023년 Euler Finance 해킹($197M)도 감사를 받은 프로토콜이었다.

"감사 완료 = 안전"이 아니라 "감사 완료 = 그나마 검증됨" 정도로 이해해야 한다.

#6. 규제 리스크 — 스테이블코인은 규제 타깃 1순위

스테이블코인은 전통 금융 시스템에 직접적인 영향을 미친다. 미국 SEC나 각국 규제 기관이 스테이블코인 규제를 강화하면 apxUSD/apyUSD 운영이 제약을 받을 수 있다. 현재는 미국, EU, EEA 거주자 접근이 불가하다는 것 자체가 규제를 이미 의식하고 있다는 신호다.

#7. APYX 토큰 전환 불확실성 — 에어드랍 사냥의 근본 전제

지금 포인트(Pips)를 쌓는 이유는 나중에 APYX 토큰으로 전환될 것이라는 기대다. 에어드랍 자체는 공식 확정됐다 — 총 공급량의 5%(500만 APYX)를 시즌 1 참여자에게 배분하는 것은 명시된 사항이다. 하지만 Pips 1개당 APYX가 몇 개 배분되는지(전환 비율)는 시즌 종료 시점의 총 Pips 합산에 따라 결정되므로 현재는 확정되지 않았다. 참여자가 많아질수록 같은 Pips로 받는 APYX 양이 줄어든다.

에어드랍 자체는 공식 확정됐지만, 전환 비율(Pips 1개당 APYX 몇 개)은 시즌 종료 시점의 총 Pips 합산에 따라 결정된다. 참여자가 많아질수록 같은 Pips로 받는 APYX 양은 줄어든다. 포인트를 쌓기 위해 실제 자산을 잠그는 것이니까, 전환 비율이 기대보다 낮게 나올 가능성은 있다.

#참여 방법

1. Apyx 앱 접속 — 레퍼럴 링크 (들어오면 나도 포인트 5% 추가로 받음, 이건 솔직하게 말하는 게 맞다)
2. 지갑 연결 (이더리움 또는 베이스 네트워크)
3. apxUSD 민팅 또는 DEX에서 구매
4. 위 전략 중 본인 성향에 맞는 것 선택
5. 12주 버티기 (진짜로 이게 제일 어렵다)

정리하면 이렇다.

VC 오버행 없는 고정 공급 토큰, 실제 현금 흐름 기반 수익, 시즌 1 포인트 진행 중. 세 가지가 동시에 맞아떨어지는 경우가 흔하지 않다. 나는 들어가 있다.

단, 리스크 섹션에서 설명한 것들을 이해하고 들어가는 것과 모르고 들어가는 건 완전히 다른 얘기다. 특히 DAT 사망 나선과 쿨다운 리스크는 본인 자금 규모에 따라 치명적일 수 있다.

포인트 → 토큰 전환 공식 발표 나오면 그때는 이미 늦다. 발표 나오면 다들 몰려들고, 배수 한도부터 차기 시작한다.

관심 있으면 지금이다.

본 글은 투자 권유가 아닙니다. 모든 투자 결정과 그 책임은 본인에게 있습니다.

기능은 완성했고, 테스트도 통과했는데 — 코드 리뷰에서 조용히 질문이 달린다. "이 분기문이 상태 추가될 때마다 여기 찾아서 고쳐야 하지 않나요?", "이 DTO 파일 왜 이렇게 긴 거예요?" 같은 것들. 틀린 코드는 아닌데 뭔가 아쉽다는 느낌. 그 "아쉬움"이 뭔지 한동안 잘 몰랐다.

그때부터 필요해지는 것들이 있다. 입문서에는 잘 안 나오는데 실무에선 당연하게 쓰이는 패턴들. 아래는 그중에서 내가 직접 써보고 "이게 맞다" 싶었던 것들이다.

#Enum 은 상수 모음이 아니다

처음에 Enum을 이렇게 배웠다. 상수 묶음. 타입 안전한 값.

public enum OrderStatus {
    PENDING, APPROVED, REJECTED, SHIPPED, DELIVERED
}

여기까진 다들 안다. 문제는 그 다음이다. 보통 이 Enum을 쓰는 코드가 이렇게 된다.

if (order.getStatus() == OrderStatus.APPROVED) {
    sendApprovalEmail(order);
} else if (order.getStatus() == OrderStatus.REJECTED) {
    sendRejectionEmail(order);
} else if (order.getStatus() == OrderStatus.SHIPPED) {
    sendShippingNotification(order);
}

상태가 하나 추가될 때마다 이 분기문을 찾아서 고쳐야 한다. 서비스 어딘가에 숨어있으면 진짜 못 찾는다. 놓치면 그냥 버그다.

근데 Enum이 메서드를 가질 수 있다는 걸 알고 있었나? 처음 이걸 알았을 때 좀 충격이었다. 클래스처럼 각 값마다 동작을 정의할 수 있다.

public enum OrderStatus {
    PENDING {
        @Override
        public void notify(Order order, NotificationService svc) {
            svc.sendPendingNotice(order);
        }
    },
    APPROVED {
        @Override
        public void notify(Order order, NotificationService svc) {
            svc.sendApprovalEmail(order);
        }
    },
    REJECTED {
        @Override
        public void notify(Order order, NotificationService svc) {
            svc.sendRejectionEmail(order);
        }
    },
    SHIPPED {
        @Override
        public void notify(Order order, NotificationService svc) {
            svc.sendShippingNotification(order);
        }
    };
 
    public abstract void notify(Order order, NotificationService svc);
}

abstract 가 붙어있으니 각 상태값이 반드시 notify() 를 구현해야 한다. 빠트리면 컴파일 에러가 난다. "실수하면 컴파일러가 잡아준다" — 이게 핵심이다.

호출하는 쪽은 이렇게 된다.

order.getStatus().notify(order, notificationService);

if-else가 한 줄로 줄었다. 새 상태가 생기면 Enum에만 추가하면 된다. 더 이상 분기문 찾아다니지 않아도 된다는 게 처음엔 조금 해방감 같은 느낌이었다.

필드랑 생성자도 넣을 수 있다. 관련된 값들을 묶어두는 데 쓴다.

public enum HttpStatus {
    OK(200, "OK"),
    NOT_FOUND(404, "Not Found"),
    INTERNAL_SERVER_ERROR(500, "Internal Server Error");
 
    private final int code;
    private final String message;
 
    HttpStatus(int code, String message) {
        this.code = code;
        this.message = message;
    }
 
    public int getCode()       { return code; }
    public String getMessage() { return message; }
}

HttpStatus.NOT_FOUND.getCode() 하면 404가 나온다. 숫자를 상수로 따로 관리하다가 어디서 쓰는지 모르게 되는 것보다 훨씬 낫다.

#Record 쓰면 DTO 파일 절반으로 줄어든다

솔직히 Java로 DTO 만들 때마다 조금 짜증났다. 필드 3개짜리 클래스인데 파일이 40줄이 넘는다.

public class UserDto {
    private final String name;
    private final String email;
    private final int age;
 
    public UserDto(String name, String email, int age) {
        this.name = name;
        this.email = email;
        this.age = age;
    }
 
    public String getName()  { return name; }
    public String getEmail() { return email; }
    public int getAge()      { return age; }
 
    @Override
    public boolean equals(Object o) { ... }
 
    @Override
    public int hashCode() { ... }
 
    @Override
    public String toString() { ... }
}

생성자 만들고, getter 만들고, equals/hashCode/toString 만들고... 실제 데이터는 3개인데 코드 길이는 왜 이렇게 긴 거야. 이걸 Java 개발자들이 오래 불만으로 가져왔는데 Java 16에서 record 가 정식으로 들어왔다.

public record UserDto(String name, String email, int age) {}

이게 전부다. 생성자, getter, equals(), hashCode(), toString() 전부 컴파일러가 자동으로 만들어준다. 처음 봤을 때 "이게 뭐야" 싶었는데, 한 번 쓰고 나서 이전 방식으로 돌아가기 싫어졌다.

한 가지 다른 점이 있다. getter가 getName() 이 아니라 name() 형태다. 헷갈리는 부분이니 기억해두면 좋다.

유효성 검사가 필요하면 이렇게 추가할 수 있다. public UserDto { ... } 형태가 record 전용 생성자 블록인데, 여기에 검사 로직을 넣으면 된다.

public record UserDto(String name, String email, int age) {
    public UserDto {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("이름은 필수입니다.");
        }
        if (age < 0 || age > 150) {
            throw new IllegalArgumentException("나이가 유효하지 않습니다: " + age);
        }
        name = name.trim();
    }
}

API 응답 객체, 커맨드 객체처럼 "데이터를 담아서 전달하는" 용도에 딱 맞는다. Record는 불변이라서 한번 만들면 필드 값을 바꿀 수 없다. 그래서 안심하고 여기저기 넘길 수 있다.

JPA Entity에는 쓰지 않는 게 좋다. JPA는 기본 생성자가 필요하고 내부적으로 필드를 바꾸는 경우가 있는데, Record의 불변성과 충돌한다. 처음에 Entity를 record로 만들려다가 삽질한 기억이 있다.

#자원 닫는 코드, 더 이상 직접 쓰지 않아도 된다

파일을 열거나, DB 커넥션을 맺거나, 소켓을 열면 — 반드시 다 쓰고 나서 닫아야 한다. 안 닫으면 메모리 누수가 생기거나 커넥션 풀이 고갈된다.

예전엔 finally 블록에서 직접 닫았다.

BufferedReader reader = null;
try {
    reader = new BufferedReader(new FileReader("data.txt"));
    String line;
    while ((line = reader.readLine()) != null) {
        process(line);
    }
} catch (IOException e) {
    log.error("파일 읽기 실패", e);
} finally {
    if (reader != null) {
        try {
            reader.close(); // 여기서도 예외가 날 수 있다
        } catch (IOException e) {
            log.error("파일 닫기 실패", e);
        }
    }
}

finally 안에서 또 try-catch를 써야 한다. 처음 이걸 봤을 때 "이게 맞나?" 싶었다. 실수할 포인트가 너무 많고, 피로하다.

Java 7에서 try-with-resources 가 나왔다. try (...) 안에 자원을 선언하면, 블록이 끝날 때 자동으로 close() 가 호출된다. 정상 종료든, 예외가 터지든 상관없이.

try (BufferedReader reader = new BufferedReader(new FileReader("data.txt"))) {
    String line;
    while ((line = reader.readLine()) != null) {
        process(line);
    }
} catch (IOException e) {
    log.error("파일 읽기 실패", e);
}

훨씬 낫다. 자원이 여러 개면 세미콜론으로 구분하면 된다. 마지막에 선언한 것부터 역순으로 닫힌다.

try (
    Connection conn = dataSource.getConnection();
    PreparedStatement stmt = conn.prepareStatement(sql);
    ResultSet rs = stmt.executeQuery()
) {
    while (rs.next()) {
        // 처리
    }
}

직접 만든 클래스도 이 기능을 쓸 수 있다. AutoCloseable 인터페이스를 구현하고 close() 메서드를 정의하면 된다. "닫을 수 있는 자원"이라고 JVM에게 알려주는 셈이다.

public class HttpClient implements AutoCloseable {
    private final CloseableHttpClient client;
 
    public HttpClient() {
        this.client = HttpClients.createDefault();
    }
 
    public String get(String url) throws IOException {
        // HTTP 요청 처리
    }
 
    @Override
    public void close() throws Exception {
        client.close(); // try 블록이 끝나면 이게 자동으로 호출됨
    }
}
 
try (HttpClient client = new HttpClient()) {
    String response = client.get("https://api.example.com/data");
    process(response);
}

#Generic 클래스 한 번쯤은 직접 만들어봐야 한다

List<String>, Map<String, Integer> 처럼 꺽쇠 안에 타입을 넣는 건 누구나 쓴다. 그런데 저 꺽쇠를 내가 직접 만드는 건 처음엔 어색하다. 왠지 어렵고 고급진 느낌이라 손이 잘 안 간다.

핵심 개념만 먼저 짚고 가자. <T> 는 "어떤 타입이든 여기에 넣을 수 있어요" 라는 표시다. T 는 Type의 약자고 이름은 아무거나 써도 되는데 관례적으로 T, E, K, V 같은 걸 쓴다.

예를 들어 API 응답 포맷을 통일하고 싶다고 하자. 그냥 짜면 이렇게 된다.

public class UserApiResponse {
    private boolean success;
    private String message;
    private UserDto data;      // 유저 조회 응답
}
 
public class OrderApiResponse {
    private boolean success;
    private String message;
    private OrderDto data;     // 주문 조회 응답
}

success, message 는 똑같은데 data 타입만 달라서 파일이 두 개다. API가 10개면 파일이 10개. Generic을 쓰면 하나로 통일된다.

public class ApiResponse<T> {          // T 자리에 어떤 타입이든 들어올 수 있다
    private final boolean success;
    private final String message;
    private final T data;              // 실제 응답 데이터
 
    private ApiResponse(boolean success, String message, T data) {
        this.success = success;
        this.message = message;
        this.data = data;
    }
 
    public static <T> ApiResponse<T> ok(T data) {
        return new ApiResponse<>(true, "OK", data);
    }
 
    public static <T> ApiResponse<T> fail(String message) {
        return new ApiResponse<>(false, message, null);
    }
}

컨트롤러에서는 이렇게 쓴다. ApiResponse<UserDto> 라고 쓰면 T 자리에 UserDto 가 들어간다.

@GetMapping("/users/{id}")
public ResponseEntity<ApiResponse<UserDto>> getUser(@PathVariable Long id) {
    UserDto user = userService.findById(id);
    return ResponseEntity.ok(ApiResponse.ok(user));
}

extends 로 "이 타입의 자식만 받겠다" 는 제한도 걸 수 있다.

// T가 Number를 상속한 타입이어야만 이 메서드를 쓸 수 있다
// Integer, Double, Long은 가능하지만 String은 컴파일 에러가 난다
public <T extends Number & Comparable<T>> T max(List<T> list) {
    return list.stream()
        .max(Comparator.naturalOrder())
        .orElseThrow(() -> new IllegalArgumentException("빈 리스트"));
}

? 와일드카드는 "타입이 뭔지 아예 모르거나 신경 안 써도 될 때" 쓴다.

// 어떤 타입의 리스트든 출력만 하면 되니까 ? 로 충분
public void printAll(List<?> list) {
    list.forEach(System.out::println);
}
 
// Number 자식 타입이면 다 받겠다 — 읽기만 하고 추가는 안 됨
public double sum(List<? extends Number> numbers) {
    return numbers.stream().mapToDouble(Number::doubleValue).sum();
}

이걸 처음 보고 "왜 이렇게 만들어놨지?" 싶었는데, 나중에 내가 비슷한 중복 코드를 만들고 있는 걸 발견했다. 그때서야 Generic이 왜 필요한지 체감이 됐다.

#메서드 이름이 거짓말을 하고 있을 때

이름은 "조회"인데 내부에서 카운트를 올리고 로그를 남기고 알림까지 보내는 메서드를 본 적이 있다. 아마 처음엔 작은 기능이었는데 거기에 계속 뭔가를 붙이다 보니 그렇게 됐을 거다. 이런 코드는 보는 순간 피로감이 온다.

public User getUser(Long id) {
    User user = userRepository.findById(id).orElseThrow();
    user.setViewCount(user.getViewCount() + 1);  // 조회수 올리기
    userRepository.save(user);
    auditLog.record("USER_VIEW", id);             // 감사 로그 남기기
    return user;
}

getUser 라는 이름에서 "조회수 올리기"와 "감사 로그"는 전혀 예상이 안 된다. 이게 왜 문제냐면:

• 테스트하기 어렵다. "그냥 유저 조회하는 테스트"를 쓰고 싶은데 카운트까지 올라가버린다.
• 재사용이 안 된다. 다른 곳에서 유저를 조회할 때 카운트를 올리면 안 되는 상황이 오면 새 메서드를 또 만들어야 한다.
• 이런 게 쌓이면 비슷하게 생긴 메서드가 여러 개 생기고 어디서 뭘 써야 할지 모르게 된다.

책임을 쪼개야 한다. 각 메서드가 딱 한 가지 일만 하게.

public User getUser(Long id) {
    return userRepository.findById(id)
        .orElseThrow(() -> new UserNotFoundException(id));
}
 
public void recordUserView(Long id) {
    userRepository.incrementViewCount(id);
    auditLog.record("USER_VIEW", id);
}

파라미터 개수도 신경 쓰인다. 3개까지는 봐줄 만한데 4개 넘어가면 파라미터 객체를 고민해봐야 한다. 인수가 6개 나란히 있으면 솔직히 읽기 싫다.

// 이게 뭔지 한눈에 파악이 안 된다
public Order createOrder(Long userId, Long productId, int quantity,
                         String address, String couponCode, boolean expressDelivery) { ... }
 
// Record로 묶으면 이름이 생긴다
public record CreateOrderRequest(
    Long userId, Long productId, int quantity,
    String address, String couponCode, boolean expressDelivery
) {}
 
public Order createOrder(CreateOrderRequest request) { ... }

sendEmail(user, true) 처럼 Boolean 파라미터를 넘기는 것도 마찬가지다. 저 true 가 뭘 의미하는지 메서드 시그니처를 직접 열어봐야 알 수 있다. 실제로 열어봤을 때 "이게 뭐지" 한 적이 한두 번이 아니다.

// true 가 뭘 의미하는 건지 알 수가 없다
sendEmail(user, true);
 
// 이름이 있으면 바로 이해된다
sendEmail(user, EmailType.WELCOME);
sendWelcomeEmail(user);

#테스트 짜기 어려운 코드가 나쁜 코드다

테스트를 쓰다 보면 "이게 왜 이렇게 짜기 어렵지?" 하는 순간이 온다. 그때 짜증을 테스트 탓으로 하지 말고 코드 탓을 해야 한다. 테스트가 어려운 건 대부분 설계가 잘못됐다는 신호다. 이걸 알고 나서 오히려 테스트가 좋아졌다.

JUnit 5 + Mockito 기본 구조다. 처음 보는 분들을 위해 빠르게 설명하면:

• @Mock — 진짜 DB 대신 가짜 Repository를 만든다
• @InjectMocks — 테스트할 서비스에 저 가짜 객체들을 주입한다
• given(...) — 가짜 객체가 어떻게 동작할지 미리 정의한다

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
 
    @Mock
    private OrderRepository orderRepository;   // 진짜 DB 대신 가짜
 
    @Mock
    private NotificationService notificationService;
 
    @InjectMocks
    private OrderService orderService;         // 진짜 서비스, 위 가짜들이 주입됨
 
    @Test
    @DisplayName("주문 승인 시 알림이 발송되어야 한다")
    void approveOrder_shouldSendNotification() {
        // given: 이 상황을 가정한다
        Long orderId = 1L;
        Order order = Order.builder()
            .id(orderId)
            .status(OrderStatus.PENDING)
            .build();
 
        given(orderRepository.findById(orderId)).willReturn(Optional.of(order));
 
        // when: 이 동작을 한다
        orderService.approve(orderId);
 
        // then: 이 결과가 나와야 한다
        then(notificationService).should().notify(any(Order.class));
        assertThat(order.getStatus()).isEqualTo(OrderStatus.APPROVED);
    }
 
    @Test
    @DisplayName("존재하지 않는 주문 승인 시 예외가 발생해야 한다")
    void approveOrder_whenNotFound_shouldThrow() {
        given(orderRepository.findById(anyLong())).willReturn(Optional.empty());
 
        assertThatThrownBy(() -> orderService.approve(999L))
            .isInstanceOf(OrderNotFoundException.class)
            .hasMessageContaining("999");
    }
}

given / when / then 구조로 나눠두면 나중에 읽기 편하다. @DisplayName 에 조건과 기대 결과를 문장으로 쓰는 게 습관이 되면 테스트 코드가 스펙 문서 역할을 한다. 6개월 뒤에 이 테스트를 열었을 때 고마워지는 게 이 부분이다.

여러 케이스를 한 번에 검증하고 싶을 때 @ParameterizedTest 를 쓰면 같은 테스트 구조를 여러 데이터로 돌릴 수 있다.

@ParameterizedTest
@CsvSource({
    "PENDING,   true",   // 대기 상태 → 취소 가능
    "APPROVED,  false",  // 승인됨 → 취소 불가
    "REJECTED,  false",
    "SHIPPED,   false"
})
@DisplayName("대기 상태인 주문만 취소 가능하다")
void isCancellable(OrderStatus status, boolean expected) {
    Order order = Order.builder().status(status).build();
    assertThat(order.isCancellable()).isEqualTo(expected);
}

커버리지 숫자보다 중요한 건 핵심 비즈니스 로직이 테스트되고 있느냐다. 100%를 채우려고 getter 테스트 만드는 건 솔직히 시간 낭비다.

#멀티스레드 버그는 재현하기도 어렵다

동시성 버그는 특이하다. 개발 환경에서는 아무 문제 없다가 트래픽이 몰리면 갑자기 나온다. 재현하려고 하면 또 안 된다. 원인 찾는 동안 진짜 멘붕이 오는 케이스 중 하나다.

기본적인 것만 알고 있어도 흔한 실수는 피할 수 있다.

public class Counter {
    private int count = 0;
 
    public void increment() {
        count++;
    }
}

이게 왜 위험하냐면 — count++ 은 한 줄이지만 실제로 CPU 입장에서는 세 단계다.

1. count 값을 읽는다
2. 1을 더한다
3. 저장한다

두 스레드가 동시에 같은 값(예: 5)을 읽으면, 둘 다 6을 저장한다. 원래는 7이 되어야 하는데. 이런 게 수천 번 반복되면 카운트가 조용히 틀려진다. 단일 스레드 테스트에서는 절대 잡히지 않는다.

synchronized 를 붙이면 한 번에 한 스레드만 들어올 수 있게 잠근다.

public class Counter {
    private int count = 0;
 
    public synchronized void increment() {
        count++;
    }
 
    public synchronized int getCount() {
        return count;
    }
}

단순한 정수 연산이라면 AtomicInteger 가 더 낫다. synchronized 는 잠금을 걸고 푸는 과정이 있어서 오버헤드가 있는데, AtomicInteger 는 그보다 가벼운 방식으로 원자성을 보장한다.

import java.util.concurrent.atomic.AtomicInteger;
 
public class Counter {
    private final AtomicInteger count = new AtomicInteger(0);
 
    public void increment() {
        count.incrementAndGet(); // 읽기-증가-저장을 원자적으로 처리
    }
 
    public int getCount() {
        return count.get();
    }
}

volatile 이라는 것도 있다. 이건 좀 다른 문제를 해결하는데 — 여러 CPU 코어가 각자 캐시에 값을 가지고 있을 때, 한 스레드가 값을 바꿔도 다른 스레드가 못 보는 경우가 있다. volatile 은 항상 메인 메모리에서 읽고 쓰도록 강제해서 이 문제를 해결한다.

// 스레드 종료 플래그처럼 "쓰는 건 하나, 읽는 건 여럿"인 단순한 경우에 적합
private volatile boolean running = true;
 
public void stop() {
    running = false; // 이 변경이 다른 스레드에서 즉시 보임
}

주의할 점은 volatile 은 가시성만 보장한다. count++ 처럼 "읽고 → 더하고 → 쓰는" 복합 연산은 여전히 위험하다. 그런 경우는 AtomicInteger 를 써야 한다. 처음에 이 차이를 제대로 몰라서 volatile 붙이고 안심했다가 낭패 본 적이 있다.

동시성 코드는 직접 구현하는 것보다 java.util.concurrent 의 검증된 구현체를 활용하는 편이 훨씬 낫다. ConcurrentHashMap, CopyOnWriteArrayList, BlockingQueue 같은 것들이 있다.

#Stream, filter/map 그 이상

filter, map, collect 는 이제 기본인데 그 이상은 막히는 경우가 있다. groupingBy 같은 걸 처음 봤을 때 "이런 게 있었어?" 싶었다.

부서별로 직원을 그룹화한다고 하면 for 루프 짜지 않아도 된다. groupingBy 는 "이 기준으로 묶어줘"다.

// employees 를 getDepartment() 값 기준으로 묶는다
Map<String, List<Employee>> byDepartment = employees.stream()
    .collect(Collectors.groupingBy(Employee::getDepartment));
 
// 부서별 평균 연봉 — groupingBy 두 번째 인수로 집계 방식을 지정할 수 있다
Map<String, Double> avgSalaryByDept = employees.stream()
    .collect(Collectors.groupingBy(
        Employee::getDepartment,
        Collectors.averagingInt(Employee::getSalary)
    ));

flatMap 은 "리스트 안에 리스트" 를 하나로 펼칠 때 쓴다. map 이랑 자꾸 헷갈리는데 — map 은 각 요소를 변환하고, flatMap 은 각 요소를 리스트로 변환한 다음 그걸 하나로 합친다.

// orders 가 [주문A, 주문B] 이고
// 주문A.getProducts() 가 [상품1, 상품2] 라면
// flatMap 으로 [상품1, 상품2, 상품3, ...] 처럼 하나의 리스트로 만들 수 있다
List<Product> allProducts = orders.stream()
    .flatMap(order -> order.getProducts().stream())
    .collect(Collectors.toList());

Stream은 게으르다(lazy). filter, map 같은 중간 연산은 collect, findFirst 같은 최종 연산이 호출되기 전까지 아무것도 실행하지 않는다. 파이프라인을 조립만 해두고 실행은 나중에 한다고 보면 된다.

Optional<User> first = users.stream()
    .filter(u -> u.getAge() > 30)
    .map(User::toDto)
    .findFirst(); // 여기서야 실행 시작, 조건 맞는 첫 번째 찾으면 바로 멈춤

findFirst() 같은 경우 조건을 만족하는 첫 번째 요소를 찾는 순간 멈춰버린다. 리스트 전체를 다 처리하지 않아도 된다. 데이터가 많을 때 성능 차이가 꽤 난다.

#Optional, 잘못 쓰면 더 복잡해진다

Optional 은 "이 값이 있을 수도, 없을 수도 있다"는 걸 코드로 표현하는 방법이다. null 을 직접 다루는 대신 Optional 로 감싸서 처리한다.

처음 배우고 나서 뭔가 모든 곳에 쓰고 싶어지는 시기가 온다. 나도 그랬다. 근데 그러면 안 된다.

써야 할 때: 메서드 반환값이 없을 수 있을 때. 특히 DB 단건 조회가 대표적이다.

Optional<User> findByEmail(String email);
 
// orElseThrow 로 없으면 예외를 던지도록 처리
User user = userRepository.findByEmail(email)
    .orElseThrow(() -> new UserNotFoundException("이메일: " + email));

쓰면 안 되는 경우를 정리하면:

// 1. 필드에 쓰지 말 것 — 직렬화가 안 되고 메모리도 낭비됨
public class User {
    private Optional<String> phoneNumber; // 그냥 null 허용 String 으로 쓰면 됨
}
 
// 2. 메서드 파라미터로 쓰지 말 것
// 호출할 때 Optional.of(name) 을 만들어서 넘겨야 하는게 더 불편하다
public void update(Long id, Optional<String> name) { }
 
// 3. 컬렉션을 감싸지 말 것 — 없으면 빈 리스트를 반환하면 된다
Optional<List<User>> findAll(); // List<User> 가 낫다, 없으면 Collections.emptyList()

파라미터에 Optional 을 쓴 API를 처음 봤을 때 뭔가 이상하다는 느낌이 들었는데, 막상 왜 이상한지 설명하기 어려웠다. 호출하는 쪽을 써보니까 바로 알게 됐다.

체이닝 패턴은 알아두면 편하다. null 체크를 if 중첩으로 하지 않아도 된다.

// order 가 null 일 수도, address 가 null 일 수도, city 가 null 일 수도 있는 상황
// Optional 체이닝으로 null 체크 없이 안전하게 꺼낼 수 있다
String zipCode = Optional.ofNullable(order)
    .map(Order::getAddress)
    .map(Address::getCity)
    .map(City::getZipCode)
    .orElse("00000"); // 중간에 하나라도 null 이면 "00000" 반환

#Interface를 무조건 만들지 않아도 된다

경험이 쌓이면 역설적으로 과도한 설계를 하게 되는 시기가 온다. Interface를 만들고, Factory를 만들고, Strategy 패턴을 넣는다. 뭔가 구조적으로 설계된 것 같고 좋아보인다. 실제로 나도 그 시기가 있었다.

구현체가 하나뿐인데 Interface가 있는 경우가 그렇다.

public interface UserFinder {
    User findById(Long id);
}
 
public class UserFinderImpl implements UserFinder {
    @Override
    public User findById(Long id) { ... }
}

UserFinderImpl 말고 다른 구현이 생길 가능성이 없다면 이 Interface는 없애도 된다.

"테스트할 때 Mock 만들려면 Interface가 있어야 하지 않냐" 는 생각도 있는데, Mockito는 구현 클래스도 바로 Mock할 수 있다. Interface가 없어도 @Mock UserFinderImpl 이 된다. 나중에 이런 코드들을 정리하면서 "내가 왜 이걸 만들었지" 하며 웃었다.

설계 원칙은 현재의 문제를 해결하기 위한 도구다. "나중에 혹시 쓸 것 같으니까" 미리 만들어두는 게 아니다.

// 5줄짜리 로직을 위해 Helper 클래스를 따로 만들 필요 없다
// 같은 클래스 안에 private 메서드로 충분하다
private String formatDisplayName(User user) {
    return user.getLastName() + " " + user.getFirstName();
}

코드를 줄이는 것 자체가 가치다. 지금 요구사항을 가장 단순하게 구현하면서 변경이 쉬운 구조를 만드는 게 좋은 설계다.

지금까지 쓴 게 한꺼번에 머리에 들어올 필요는 없다. Enum 짤 때 "동작을 넣을 수 있지 않을까?", DTO 만들 때 "Record로 할 수 있지 않을까?", 자원 쓸 때 try-with-resources — 이것만 자연스럽게 나오기 시작해도 코드 리뷰에서 받는 질문의 색깔이 달라진다.

그때 기분이 나쁘지 않다.

관련 글

• Java 신입 개발자가 꼭 알아야 할 실무 팁 10가지
• 신입 백엔드 때 진짜로 혼났던 것들 — JPA, 트랜잭션, 예외처리

이 글은 계정 만들기부터 실제 데이터 꺼내 쓰는 것까지 따라만 하면 바로 동작하는 앱이 나오도록 순서대로 정리했습니다. 개념 설명보다는 실제 쓰는 코드 위주로 갑니다.

#🤔 왜 이 조합인가

Next.js만 쓰면 DB가 없고, Firebase 쓰면 SQL이 그리워지고, 직접 서버 올리자니 귀찮습니다. Supabase는 PostgreSQL 기반이라 SQL 쿼리를 그대로 쓸 수 있고, JavaScript 클라이언트 라이브러리도 잘 만들어져 있습니다.

Next.js App Router와 궁합이 특히 좋은 이유는 Server Component에서 Supabase 클라이언트를 직접 써도 된다는 점입니다. API 라우트 없이 DB 결과를 컴포넌트에서 바로 렌더링할 수 있어서 코드가 훨씬 단순해집니다.

#🚀 1. 프로젝트 세팅

Node.js 18 이상이 설치된 환경이라면 지금 바로 시작할 수 있습니다.

#Next.js 앱 생성

npx create-next-app@latest my-app --typescript --app
cd my-app

실행하면 몇 가지를 물어봅니다. 취향대로 골라도 되지만 한 가지만 꼭 지켜야 합니다.

Would you like to use App Router? › Yes  ← 반드시 Yes

이 글 전체가 App Router 기준입니다. Pages Router를 선택하면 뒤에 나오는 코드가 전혀 맞지 않습니다. ESLint, Tailwind CSS, src/ 디렉터리 여부는 프로젝트 성격에 맞게 자유롭게 선택하면 됩니다.

⚠️ 흔한 실수 — --app 플래그를 붙였는데도 설치 중 App Router 선택지에서 No를 누르면 Pages Router로 생성됩니다. 플래그보다 대화형 선택이 우선이니 주의하세요.

#Supabase 패키지 설치

npm install @supabase/supabase-js @supabase/ssr

두 패키지를 동시에 설치하는 이유가 있습니다.

• @supabase/supabase-js — Supabase의 핵심 클라이언트입니다. DB 쿼리, Auth, Realtime 등 실제 기능이 여기 있습니다.
• @supabase/ssr — Next.js App Router처럼 SSR 환경에서 쿠키 기반 세션을 다루기 위한 래퍼입니다. 이게 없으면 서버 컴포넌트에서 로그인 상태를 유지하기가 복잡해집니다.

⚠️ 주의 — 예전에는 @supabase/auth-helpers-nextjs를 많이 썼는데 지금은 deprecated 됐습니다. 검색하면 이 패키지 기준 글이 아직 많이 나오니 헷갈리지 않도록 주의하세요. 새 프로젝트라면 반드시 @supabase/ssr로 시작하세요.

#Supabase 프로젝트 생성 및 키 발급

supabase.com에서 계정을 만들고 새 프로젝트를 생성합니다. 프로젝트 이름과 DB 비밀번호, 리전(Region)을 설정하면 1분 안에 프로비저닝이 끝납니다.

리전은 Northeast Asia (Seoul)을 선택하면 국내 사용자 기준으로 응답 속도가 가장 빠릅니다.

프로젝트가 생성되면 Settings → API 메뉴로 이동합니다. 여기서 세 가지 값을 확인할 수 있습니다.

이 중 Project URL과 anon key만 .env.local에 넣으면 됩니다.

NEXT_PUBLIC_SUPABASE_URL=https://xxxxxxxxxxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

NEXT_PUBLIC_ 접두사가 붙은 변수는 브라우저에서도 읽을 수 있습니다. anon key는 원래 공개되어도 되는 키로, 실제로 어떤 데이터에 접근할 수 있는지는 Row Level Security(RLS) 가 제어합니다.

반면 service_role 키는 RLS를 전부 우회하는 관리자 키입니다. 서버 전용 환경변수로만 쓰고 절대 클라이언트에 노출하면 안 됩니다.

.env.local은 .gitignore에 이미 포함되어 있으니 Git에 올라갈 걱정은 안 해도 됩니다. Vercel에 배포할 때는 Settings → Environment Variables에 동일하게 등록해줘야 합니다.

⚠️ 트러블슈팅 — 환경변수를 추가했는데 undefined가 뜬다면, 개발 서버를 재시작했는지 확인하세요. .env.local 변경 사항은 서버를 껐다 켜야 반영됩니다.

#🔧 2. Supabase 클라이언트 만들기

App Router에서는 서버용과 클라이언트용 인스턴스를 반드시 분리해서 만들어야 합니다. 같은 파일로 통일하고 싶은 마음이 들 수 있는데, 서버에선 쿠키를 직접 다뤄야 하기 때문에 구조가 다릅니다.

서버용 (utils/supabase/server.ts)

import { createServerClient } from '@supabase/ssr'
import { cookies } from 'next/headers'
 
export async function createClient() {
  const cookieStore = await cookies()
 
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll()
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) =>
            cookieStore.set(name, value, options)
          )
        },
      },
    }
  )
}

클라이언트용 (utils/supabase/client.ts)

import { createBrowserClient } from '@supabase/ssr'
 
export function createClient() {
  return createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
  )
}

⚠️ 흔한 실수 — 서버 컴포넌트에서 utils/supabase/client.ts를 import하면 빌드 에러가 납니다. createBrowserClient는 window 객체에 의존하기 때문입니다. 서버 컴포넌트에는 반드시 server.ts를 쓰세요.

#📦 3. Server Component에서 DB 조회

이게 이 스택의 핵심입니다. async 컴포넌트 안에서 DB 데이터를 바로 꺼내 쓸 수 있습니다.

// app/posts/page.tsx
import { createClient } from '@/utils/supabase/server'
 
export default async function PostsPage() {
  const supabase = await createClient()
  const { data: posts, error } = await supabase
    .from('posts')
    .select('id, title, created_at')
    .order('created_at', { ascending: false })
    .limit(10)
 
  if (error) return <p>불러오기 실패</p>
 
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

fetch 따로 없고, useEffect 없고, 상태 관리도 없습니다. 그냥 읽어서 렌더링합니다.

⚠️ 트러블슈팅 — data가 빈 배열로 오거나 error에 permission denied가 뜬다면 RLS 문제입니다. Supabase 대시보드에서 Authentication → Policies 메뉴로 이동해 해당 테이블에 SELECT 정책을 추가해주세요. 개발 중에 빠르게 테스트하고 싶다면 임시로 Enable read access for all users 정책을 켜도 됩니다. 다만 프로덕션에선 반드시 세분화된 정책을 설정해야 합니다.

#✏️ 4. 데이터 삽입 — Server Action 활용

Next.js의 Server Action을 쓰면 API 라우트를 따로 만들지 않아도 서버에서 데이터를 쓸 수 있습니다.

// app/posts/new/actions.ts
'use server'
 
import { createClient } from '@/utils/supabase/server'
import { redirect } from 'next/navigation'
 
export async function createPost(formData: FormData) {
  const supabase = await createClient()
  const title = formData.get('title') as string
  const content = formData.get('content') as string
 
  const { error } = await supabase
    .from('posts')
    .insert({ title, content })
 
  if (error) throw new Error(error.message)
  redirect('/posts')
}

// app/posts/new/page.tsx
import { createPost } from './actions'
 
export default function NewPostPage() {
  return (
    <form action={createPost}>
      <input name="title" placeholder="제목" />
      <textarea name="content" placeholder="내용" />
      <button type="submit">저장</button>
    </form>
  )
}

폼을 제출하면 Server Action이 실행되고, 완료 후 /posts로 리다이렉트됩니다. 전통적인 HTML 폼처럼 보이지만 Next.js가 뒤에서 다 처리합니다.

⚠️ 트러블슈팅 — insert에서 new row violates row-level security policy 에러가 나면, 해당 테이블에 INSERT 정책이 없는 겁니다. 로그인한 사용자만 삽입 가능하게 하려면 Supabase 대시보드에서 아래 정책을 추가하세요.

CREATE POLICY "로그인한 사용자만 삽입 가능"
ON posts FOR INSERT
TO authenticated
WITH CHECK (true);

#🔐 5. 인증 연동

Supabase Auth는 이메일/비밀번호, OAuth(Google, GitHub 등)를 지원합니다. 세션을 모든 요청에서 자동으로 확인하려면 미들웨어에 설정을 추가해야 합니다.

미들웨어 (middleware.ts)

import { createServerClient } from '@supabase/ssr'
import { NextResponse, type NextRequest } from 'next/server'
 
export async function middleware(request: NextRequest) {
  let supabaseResponse = NextResponse.next({ request })
 
  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll()
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          )
          supabaseResponse = NextResponse.next({ request })
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          )
        },
      },
    }
  )
 
  const { data: { user } } = await supabase.auth.getUser()
 
  // 로그인이 필요한 페이지 보호
  if (!user && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
 
  return supabaseResponse
}
 
export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

로그인 처리는 Server Action으로 간단하게 만들 수 있습니다.

// app/login/actions.ts
'use server'
 
import { createClient } from '@/utils/supabase/server'
import { redirect } from 'next/navigation'
 
export async function login(formData: FormData) {
  const supabase = await createClient()
  const { error } = await supabase.auth.signInWithPassword({
    email: formData.get('email') as string,
    password: formData.get('password') as string,
  })
  if (error) throw new Error(error.message)
  redirect('/dashboard')
}

⚠️ 트러블슈팅 — 로그인 후 서버 컴포넌트에서 여전히 user가 null로 뜬다면, 미들웨어가 세션 쿠키를 갱신하지 못하고 있는 겁니다. middleware.ts가 프로젝트 루트에 있는지, matcher 패턴이 해당 경로를 포함하는지 먼저 확인하세요. 미들웨어가 실행되지 않으면 쿠키 갱신 자체가 안 됩니다.

#⚡ 6. 실시간 기능 (Realtime)

Supabase는 PostgreSQL 변경 사항을 WebSocket으로 실시간 스트리밍해줍니다. 채팅, 알림, 실시간 업데이트 같은 기능에 쓸 수 있습니다.

이건 클라이언트 컴포넌트에서만 동작합니다.

'use client'
 
import { createClient } from '@/utils/supabase/client'
import { useEffect, useState } from 'react'
 
type Message = { id: string; content: string }
 
export default function ChatFeed() {
  const [messages, setMessages] = useState<Message[]>([])
  const supabase = createClient()
 
  useEffect(() => {
    // 기존 메시지 초기 로드
    supabase
      .from('messages')
      .select('*')
      .order('created_at')
      .then(({ data }) => {
        if (data) setMessages(data)
      })
 
    // 실시간 구독 등록
    const channel = supabase
      .channel('messages')
      .on('postgres_changes', {
        event: 'INSERT',
        schema: 'public',
        table: 'messages',
      }, (payload) => {
        setMessages((prev) => [...prev, payload.new as Message])
      })
      .subscribe()
 
    return () => { supabase.removeChannel(channel) }
  }, [])
 
  return (
    <ul>
      {messages.map((msg) => (
        <li key={msg.id}>{msg.content}</li>
      ))}
    </ul>
  )
}

INSERT 이벤트가 발생할 때마다 상태가 자동으로 업데이트됩니다.

⚠️ 트러블슈팅 — 구독을 설정했는데 이벤트가 아무것도 안 온다면, Supabase 대시보드에서 Database → Replication 메뉴를 확인하세요. 해당 테이블의 Realtime이 비활성화되어 있으면 이벤트가 전송되지 않습니다. 토글을 켜주면 바로 동작합니다.

#✅ 마무리

처음엔 서버 클라이언트/브라우저 클라이언트를 분리하는 게 헷갈릴 수 있는데, 한 번 손에 익으면 별거 아닙니다. "서버에서 읽고, 서버에서 쓰고, 실시간만 클라이언트" 이렇게 기억해두면 됩니다.

이 글의 코드는 전부 실제로 동작하는 코드입니다. 위에서부터 순서대로 따라오면 오늘 안에 데이터를 읽고 쓰는 앱 하나를 완성할 수 있습니다. 백엔드 서버 없이 이 정도 기능을 갖춘 앱을 만들 수 있다는 게 아직도 조금 신기합니다. 사이드 프로젝트 빠르게 띄우기엔 이만한 조합이 없는 것 같습니다. 🙌

ICO 붐도 겪었고, DeFi 여름도 살아남았다. NFT 광풍도 봤고, 루나 폭락도 현장에서 지켜봤다.

그러다 보니 주변에서 "코인 뭐 하면 되냐"는 질문을 정말 많이 받는다.

몇 년 전에는 지인이 카톡으로 이런 메시지를 보내왔다.

"야, 유니스왑에서 갑자기 내 지갑에 400달러가 들어와 있는데 이게 뭐야?"

그 친구는 DEX가 뭔지도 몰랐다. DeFi라는 말도 들어본 적 없었다. 그냥 내가 한번 써보라고 해서 클릭 몇 번 해본 게 전부였다.

근데 그게 에어드랍이었다.

유니스왑이 2020년 9월 UNI 토큰을 출시하면서, 과거에 자기네 서비스를 한 번이라도 써봤던 모든 지갑에 400 UNI를 그냥 뿌렸다. 발표 당일 UNI 가격은 약 3달러. 400개면 1,200달러다. 최고가(44달러)에는 17,600달러였다.

그 친구는 클릭 몇 번으로 1,200달러를 받았다.

이게 에어드랍이다.

#에어드랍이 뭔지부터

에어드랍(Airdrop)은 블록체인 프로젝트가 조건을 충족한 사용자 지갑에 토큰을 무료로 배포하는 이벤트다.

말 그대로 하늘에서 코인이 떨어지는 것이다.

대신 아무한테나 주는 게 아니다. 자기네 서비스를 써본 사람, 혹은 일정 조건을 만족한 사람에게 준다.

왜 줄까?

프로젝트 입장에서 초기 사용자는 무엇보다 귀하다. 아직 인지도도 없고 유동성도 없을 때 먼저 써준 사람들이 있어야 서비스가 돌아간다. 그 보답으로 토큰을 나눠주는 것이다.

동시에 토큰을 받은 사람들은 자연스럽게 그 프로젝트의 주주가 된다. 토큰 가격이 올라야 본인도 이익이니 자연스럽게 홍보하고 응원하게 된다. 프로젝트와 사용자가 함께 이익을 보는 구조다. 윈-윈이다.

#역사가 증명한 에어드랍들 — 이 정도 규모였다

이게 그냥 소소한 이벤트가 아니다. 9년 동안 봐온 에어드랍들 중 임팩트가 컸던 것들만 골라봤다.

#Uniswap — UNI (2020년 9월)

DEX의 대명사 유니스왑이 첫 토큰을 발행하면서 과거 사용자 전원에게 400 UNI를 지급했다.

배포 당일 가격 기준 약 1,200달러, 최고가 기준 약 17,600달러였다.

조건은 단순했다. 2020년 9월 1일 이전에 유니스왑에서 스왑을 한 번이라도 해봤을 것. 트랜잭션 하나로 1,200달러를 받았다.

#dYdX — DYDX (2021년 8월)

탈중앙화 영구선물 거래소 dYdX가 토큰을 발행하면서 과거 트레이더들에게 대규모 에어드랍을 진행했다.

거래량에 따라 달랐는데, 평균적으로 수백에서 수천 달러 수준이었고 활발하게 거래했던 사용자 중에는 수만 달러를 받은 케이스도 있었다.

#Optimism — OP (2022년 5월, 1차)

이더리움 레이어2 체인 옵티미즘의 1차 에어드랍. 대상 기준이 복잡했는데, DAO 참여자, L2 사용자, Gitcoin 기부자 등을 포함했다.

지갑당 최소 264 OP에서 시작했고 당시 가격 기준 약 600달러 수준이었다. 이후 2차, 3차 에어드랍이 추가로 진행됐다.

#Arbitrum — ARB (2023년 3월)

이더리움 레이어2 최강자 아비트럼의 에어드랍. 역대 레이어2 에어드랍 중 가장 컸다.

625 ARB부터 시작해서 활동량에 따라 최대 10,250 ARB까지 지급됐다. 발행 당시 약 1.2달러였으니 평균적으로 약 750달러-12,000달러 범위였다.

아비트럼에서 스왑하고, 브릿지 써보고, 유동성 공급해본 사람이면 대부분 받았다. 단 몇 달러 가스비에 얼마가 돌아온 셈이다.

#Hyperliquid — HYPE (2024년 11월)

2024년 최고의 에어드랍으로 꼽힌다.

Hyperliquid 퍼포인트(Points) 시스템 참여자들에게 HYPE 토큰을 배분했는데, 초기 참여자 중에는 수만 달러에서 수십만 달러를 받은 사람도 나왔다. HYPE 가격이 출시 후 급등했기 때문이다.

이게 포인트 시스템 에어드랍이 얼마나 강력한지를 보여준 사례다.

#Blur — BLUR (2023년 2월)

NFT 마켓플레이스 Blur가 NFT 트레이더들에게 토큰을 배포했다.

오픈씨보다 수수료가 낮아서 트레이더들이 많이 쓰던 곳이었는데, 그 사용 이력을 기반으로 에어드랍을 진행했다. 활발하게 거래했던 트레이더들 중 일부는 수천 달러 이상을 받았다.

#에어드랍 종류, 네 가지면 끝

#소급형 (Retroactive)

가장 대표적인 형태다. 프로젝트가 서비스를 먼저 운영하다가, 어느 시점에 토큰을 발행하면서 과거에 써본 사람들에게 소급 지급한다.

미리 공지 없이 진행되는 경우가 대부분이다. 그래서 받을 줄 몰랐던 사람이 갑자기 지갑에 코인이 들어와 있는 경험을 하게 된다.

위에서 소개한 유니스왑, 아비트럼이 다 이 방식이다.

이 방식의 핵심은, 에어드랍 받으려고 특별히 뭔가를 하지 않아도 된다는 점이다. 그냥 서비스를 진짜 써보면 된다.

#포인트형 (Points System)

2024년 이후로 가장 많이 쓰이는 방식이다.

서비스를 쓸수록 포인트가 쌓이고, 나중에 TGE(Token Generation Event, 토큰 발행)가 되면 포인트 비율에 따라 토큰으로 전환해 준다.

MetaMask Rewards, Hyperliquid 포인트 시스템이 이 방식이었다.

포인트를 더 많이 쌓으려면 더 많이, 더 자주 써야 한다. 꾸준함이 핵심이다.

#태스크형 (Task-Based)

트위터 팔로우, 리트윗, 디스코드 참여, 설문 응답 같은 간단한 미션을 수행하면 받는 방식이다.

주로 소규모 신규 프로젝트들이 쓴다. 조건이 가장 쉬운 대신, 받는 양도 적고 가치가 낮은 경우가 많다. 그리고 이쪽에 사기가 가장 많다. 각별히 주의가 필요하다.

#유동성형 (Liquidity Mining)

DEX(탈중앙화 거래소)에 유동성을 공급하면 수수료 수익과 함께 토큰도 보상으로 받는 방식이다.

Meteora 시즌 2가 이 방식인데, 내가 공급한 유동성에서 발생한 수수료가 많을수록 더 많은 MET 토큰을 받는다.

수익은 가장 높을 수 있지만 임시손실(Impermanent Loss) 개념을 이해해야 하고 리스크도 있다. 초보에겐 추천하지 않는다.

#2026년 현재 주목할 프로젝트들

#MetaMask (MASK 토큰) 🔴 미확정

크립토 하는 사람이라면 모르는 사람이 없는 지갑. 공동창업자가 공식적으로 "예상보다 빨리 나올 것"이라고 언급한 적 있다.

MetaMask Rewards 포인트 시스템이 이미 돌아가고 있다. MetaMask로 스왑, 브릿지, 영구선물 거래를 하면 포인트가 쌓인다.

단, MetaMask는 이미 Linea(자체 레이어2) 생태계를 통한 에어드랍을 한 차례 진행한 바 있다. 앞으로 MASK 토큰이 나올지, 어떤 기준으로 줄지는 아직 공식 발표가 없다.

이미 MetaMask를 쓰고 있다면? 그냥 계속 쓰면 된다. 특별히 더 할 게 없다.

#Base 네트워크 🔴 미확정

코인베이스가 만든 이더리움 레이어2 체인. 팀이 공식적으로 "베이스 네트워크 토큰을 검토 중"이라고 밝혔다. 확정은 아니다.

코인베이스가 상장사라 규제 이슈가 복잡하게 엮여있어서 언제, 어떤 형태로 나올지 예측하기 어렵다.

그래도 Base 위에서 활동하는 건 나쁠 게 없다. Aerodrome에서 스왑하거나, 베이스 도메인(.base.eth) 이름을 민팅하거나, Aave나 Uniswap의 Base 버전을 써보면 된다.

#Polymarket 🔴 미확정

예측 시장 플랫폼. 2026년 2월에 $POLY 상표를 등록했다. 토큰 발행이 임박했다는 신호로 읽히지만, 공식 발표는 아직 없다.

대선, 스포츠, 경제 지표 등 다양한 예측 마켓에서 꾸준히 거래하면서 X(트위터) 계정을 연동해두면 참여 기록이 남는다.

#Hyperliquid (2차 배분) 🔴 미확정

이미 2024년에 HYPE 토큰 에어드랍을 했던 Hyperliquid. 전체 토큰의 38.88%가 아직 미래 배분용으로 묶여 있다.

언제, 어떻게 배분할지는 팀만 알고 있다. 레버리지 트레이딩, 스테이킹, 유동성 공급으로 계속 활동 기록을 쌓아두는 것 정도가 할 수 있는 전부다.

#LayerZero (2차 시즌) 🔴 미확정

크로스체인 메시징 프로토콜. 전체 ZRO 공급량의 약 30%가 아직 미래 배분용으로 남아 있다.

CEO가 직접 에어드랍 파밍을 하지 말라고 경고했는데, 역설적으로 이건 다음 시즌을 준비 중이라는 신호로 읽힌다.

Stargate 브릿지를 이용하거나, LayerZero를 지원하는 dApp을 실제로 사용하면 된다. 단, 진짜 사용 목적 없이 반복만 하면 시빌로 걸린다.

#Variational 🔴 미확정

영구선물 DEX. 공식적으로 "전체 공급량의 50%를 커뮤니티에 배분"하겠다고 밝혔다. 퍼포인트 프로그램이 진행 중이다.

퍼페추얼 거래를 하거나 친구를 초대하면 포인트가 쌓인다. TGE 시점은 미발표.

#Pacifica 🔴 미확정

솔라나 기반 퍼페추얼 DEX. 오프체인 매칭 + 온체인 결제 방식으로 속도와 탈중앙화를 동시에 잡은 구조다.

창업자는 전 FTX COO 컨스탄스 왕(Constance Wang). FTX 이후 이름을 버리지 않고 새로 시작했다는 점에서 커뮤니티 신뢰를 얻었다. Hyperliquid처럼 VC 투자 없이 자체 자금으로만 운영 중이다.

2025년 9월 메인넷 출시 이후 솔라나 퍼프 DEX 1위 자리를 유지하고 있다. 2026년 1월 21일 누적 거래량 1,000억 달러를 돌파했으며, 2026년 4월 기준 일 거래량은 10억 달러 이상이다. TVL은 약 3,800만~4,000만 달러 수준이다.

포인트 시스템: 2025년 9월 4일부터 운영 중이며, 매주 목요일 00:00 UTC 스냅샷 후 24시간 이내에 배분된다. 포인트는 해당 주 전체 플랫폼 거래량 대비 내 거래량 비율로 계산된다. 초기 주당 50만 포인트였다가 2025년 10월 30일 20배 증가해 현재 주당 1,000만 포인트를 배분한다. 시즌 1이 완료됐고 현재 시즌 2(Boost Windows)가 진행 중이다. Boost Windows는 매주 특정 자산군을 선정해 해당 기간 포인트 효율을 높이는 방식이며, 약 1주 전 공식 X와 디스코드를 통해 사전 공지된다. 5일 이상 연속 거래 시 최대 23% 추가 포인트가 붙는 Streak 보너스도 있다. 레퍼럴은 누적 거래량 $10,000 달성 후 활성화된다.

워시 트레이딩이 탐지되면 포인트를 소급 삭감한다. 멀티 지갑은 이점이 없다.

단, 현재 초대 코드 기반 클로즈드 베타로 운영 중이다. X(트위터)나 디스코드 커뮤니티에서 초대 코드를 구해야 참여할 수 있다.

공식 토큰이나 TGE 일정은 아직 발표되지 않았다.

#Dango 🔴 미확정

퍼페추얼 거래에 특화된 레이어1 앱체인. "Grug" 실행 환경 기반으로 설계됐으며, 약 20개 노드로 구성된 허가형 검증 구조를 취하고 있다.

일반 DEX와 차별화된 기능들이 있다. 마진 계정(Margin Accounts)으로 포지션 간 증거금을 공유하고, 스마트 계정 기능으로 생체인식(지문, 페이스아이디)과 패스키 로그인을 지원한다. 크론 잡(Cron Jobs)으로 자동화 전략도 가능하다. 오더북은 CLOB(중앙화형 한도 주문서) 방식이다.

토큰 티커는 DNG, 총 공급량 3만 개로 고정되어 있다. 수수료는 USDC로 수납해 DNG를 매입 후 소각하는 디플레이션 구조다. 시드 투자는 Lemniscap, Hack VC, Delphi Labs가 참여했으며 총 360만 달러 규모다.

포인트 프로그램: 4월 13일 론칭 예정이었다. 38주간 운영하며 Q4 2026 네이티브 토큰 출시와 함께 전체 공급량 약 50%를 에어드랍할 계획이었다. 매주 100만 포인트를 배분하며 퍼프 거래(3/4), DLP 예치(1/4), 레퍼럴로 나뉜다. OAT 보유자는 EVM 지갑 연동 후 4주간 최대 400% 부스트를 받을 수 있고, 거래량에 따라 루트박스(브론즈 $25k, 실버 $100k, 골드 $250k, 크리스탈 $500k)를 얻는 구조다.

#OpenSea 🔴 미확정 · 지연

NFT 마켓플레이스의 원조. SEA 토큰 발행을 공식 예고했으나 2026년 Q1 출시 약속을 번복하고 시장 상황을 이유로 연기했다.

NFT 거래 이력이 긴 계정, Pudgy Penguins 같은 주요 컬렉션 보유자가 유리할 것으로 예측된다. 언제 나올지 여전히 미정이다.

#최근 완료된 에어드랍들 — 어떻게 됐나

에어드랍이 항상 성공하는 건 아니다. 최근 완료된 것들을 보면 명암이 뚜렷하다.

#Backpack — BP (2026년 3월)

솔라나 기반 거래소 Backpack이 2026년 3월 23일 BP 토큰을 발행했다. 전체 공급량의 25%(2억 5천만 BP)를 커뮤니티에 배분했는데, 포인트 보유자(24%)와 Mad Lads NFT 홀더(1%)가 대상이었다.

상장 직후 가격이 크게 뛰었지만 이후 빠르게 조정됐다.

커뮤니티 반응은 엇갈렸다. 고거래량 유저에게 너무 치우쳐 있다는 불만, 시빌 필터링이 과도했다는 지적이 많았다.

#EdgeX — EDGE (2025~2026년)

이더리움 레이어2(StarkEx) 기반 영구선물 DEX. Amber Group이 인큐베이팅한 프로젝트로, Hyperliquid에 이어 수수료 기준 2위 퍼프 DEX였다.

전체 공급량의 40%(4억 EDGE)를 트레이더, 유동성 공급자, 얼리 어답터에게 배분했다. 거래량, LP 포지션, 파워 트레이더 여부 등 6개 티어로 나눠서 지급했다.

#Based

Hyperliquid L1 위에서 운영되는 Web3 슈퍼앱이다. 퍼페추얼·스팟 거래, 밈 콘텐츠 예측 마켓(Internet Opinion Markets), 실물 Visa 카드(포트폴리오 잔고로 결제, 최대 8% 캐시백), 런치풀, AI 트레이딩 에이전트 등 여러 기능을 하나의 앱에 묶었다. 출시 8개월 만에 누적 거래량 400억 달러, 가입자 10만 명을 넘겼고 2026년 2월 Pantera Capital 주도로 1,150만 달러 시리즈 A 투자를 유치했다.

토큰: $BASED, 총 공급량 10억 개 고정.

에어드랍 경과:

• 시즌 1·2 제네시스: 전체 공급량의 23.5%(2억 3,500만 개)를 2026년 3월 30일 TGE 시점에 Hyperliquid Core 지갑으로 자동 지급했다. XP(시즌 1)·Gold(시즌 2)·$PUP·BasedPal NFT 보유자가 대상이었다. 2월 8일 이전 약관 동의 기록이 있어야 수령할 수 있었다.
• 시즌 3 (Diamonds): 2026년 1월 5일~5월 4일 진행 중이며 전체 공급량의 5%(5,000만 개) 배분 예정이다. 퍼프·스팟 거래량에 비례해 Diamonds가 적립되고, 2026년 5월 11일 클레임 가능하다(베스팅 없음).

스테이킹: TGE 당일 론칭. OG / Based / Normie 3개 티어로 나뉘며 선착순으로 상한이 채워진다(OG·Based 티어 각 4,000만 개 한도). APR은 동적이라 초기 참여자일수록 유리하다. 3일 언스테이킹 대기 기간이 있다. 스테이킹 시 거래 수수료 할인, Visa 카드 한도 상향, 런치풀 접근 등 혜택이 추가된다.

토큰 가격: 출시 당일(3월 30일) $0.1549로 ATH를 찍은 뒤 4월 초 $0.05 근처까지 조정됐다. 투자자·기여자 물량은 2027년 3월까지 락업된다.

시즌 3가 아직 진행 중이므로 Based에서 거래 활동을 이어가면 5월 클레임 물량을 추가로 받을 수 있다.

#Starknet — STRK (2024년 2월)

출시 가격 5달러였던 STRK는 에어드랍 이후 91% 이상 폭락했다.

이유는 두 가지였다.

첫째, 대규모 고거래량 클레이머들이 상장 즉시 전량 매도했다. 둘째, 시빌 필터링이 허술해서 GitHub 계정을 조작한 봇 어드레스들이 대규모로 청구했다.

에어드랍 이후 활성 주소 수가 38만 개에서 8,300개로 98%나 급감했다.

실제 사용자보다 토큰 목적의 참여자가 훨씬 많았다는 방증이다.

#LayerZero — ZRO (2024년)

ZRO는 기술적으로는 성공했지만 방식이 논란이었다.

에어드랍을 받으려면 토큰당 0.1달러를 이더리움 Protocol Guild에 기부해야 했다. 완전 무료가 아니었던 것이다.

"이게 에어드랍이냐, ICO냐"는 논쟁이 붙었고 커뮤니티 반발이 심했다.

그래도 가격 방어는 상대적으로 잘 됐다. STRK나 ZK에 비해서는 양호했는데, 강력한 시빌 필터링 덕분이었다.

#에어드랍이 항상 좋은 건 아니다

솔직히 말하겠다.

에어드랍 받았다고 무조건 돈을 버는 시대는 지났다.

2020~2022년에는 에어드랍 받으면 그냥 돈이었다. 유니스왑처럼 받자마자 최소 수백 달러였고, 뭘 받아도 오르는 시절이었다. 그때는 참여만 해도 됐다.

지금은 다르다.

ZKsync(ZK)는 2024년 에어드랍 당일 수백만 개 주소에 토큰을 뿌렸는데, 상장 직후부터 지속적으로 하락해서 장기 보유자 대부분이 손해를 봤다.

Starknet(STRK)은 이미 위에서 말했다. 91% 폭락.

Backpack(BP)는 많은 기대를 받았지만 상당수 유저들이 "이 정도 받으려고 몇 달을 썼나" 싶은 반응이 나왔다.

왜 이렇게 됐을까.

이유는 간단하다.

에어드랍 파밍 인구가 너무 많아졌다. 수백만 명이 토큰만 받으려고 서비스를 쓰는 척하면서, 받자마자 전량 매도한다. 프로젝트 입장에서는 진짜 사용자가 아닌 사람들한테 토큰을 뿌린 셈이다.

그래서 요즘 프로젝트들은 시빌 필터링을 강화하고, 배분량을 줄이고, 조건을 까다롭게 만들고 있다.

그렇다면 에어드랍을 하면 안 되냐? 그건 아니다.

다만 기대치를 조정해야 한다. 에어드랍은 서비스를 써보는 김에 혹시 받을 수도 있는 보너스로 생각하는 게 맞다.

에어드랍 자체를 목적으로 삼으면 실망이 크다. 진짜 쓸만한 서비스를 쓰다 보면 어느 날 지갑에 코인이 들어와 있는 것이다.

#어떻게 시작하나 — 5단계

#1단계: 지갑 만들기

거래소 계정(업비트, 빗썸, 바이낸스)으로는 에어드랍을 받을 수 없다. 직접 키를 관리하는 셀프커스터디 지갑이 있어야 한다.

• EVM 계열 (이더리움, Base, Arbitrum 등): MetaMask
• 솔라나 계열: Phantom

둘 다 크롬 확장 프로그램으로 설치하면 된다.

처음 설치할 때 시드 구문(12-24개 영어 단어) 이 나온다. 이게 내 지갑의 열쇠다. 절대 디지털 기기에 저장하지 말고, 종이에 적어서 물리적으로 보관한다. 이걸 잃어버리거나 노출되면 지갑 안의 모든 자산이 사라진다.

#2단계: 리스트 확인하기

• airdrops.io — 검증된 에어드랍 모음
• CoinGecko — 업커밍 에어드랍 리스트
• dropstab.com — 활성화된 에어드랍 및 포인트 캠페인 정리
• 각 프로젝트 공식 트위터, 디스코드

단, 공식 채널이 아닌 곳에서 온 에어드랍 링크는 절대 클릭하지 않는다.

#3단계: 프로토콜 써보기

찾은 프로젝트의 서비스를 실제로 사용한다. 어떤 행동이 에어드랍 대상이 될지는 프로젝트마다 다르지만 보통 이런 것들이다.

• DEX에서 토큰 스왑 (예: Uniswap에서 ETH → USDC 교환)
• 브릿지로 다른 체인에 자산 이동 (예: 이더리움 → Base로 ETH 이동)
• 스테이킹 또는 유동성 공급
• 테스트넷 참여
• 거버넌스 투표

금액이 적어도 괜찮다. 얼마를 거래하느냐보다 거래했다는 온체인 기록이 더 중요한 경우가 많다.

#4단계: 꾸준히 반복하기

2026년 에어드랍 트렌드에서 가장 중요한 키워드는 일관성이다.

하루에 대규모로 몰아서 하는 것보다, 주 1~2회씩 꾸준하게 쓰는 사람이 훨씬 유리하다.

프로젝트 팀들이 활동 패턴을 분석해서 진짜 사용자와 봇 계정을 구분하기 때문이다. Linea 에어드랍에서는 전체 신청자 130만 명 중 약 51만 7천 명(40%)이 봇 의심으로 탈락했다.

하나의 지갑으로, 자연스러운 패턴으로, 꾸준히. 이게 전부다.

#5단계: 클레임하기

에어드랍이 발표되면 공식 사이트에서 지갑을 연결하고 클레임 버튼을 누르면 된다.

반드시 공식 트위터, 디스코드에서 확인한 링크만 사용한다. 피싱 사이트는 공식 사이트와 픽셀 단위로 똑같이 생겨있고, 지갑을 연결하는 순간 안에 있는 코인을 전부 빼간다.

#절대 하면 안 되는 것들

에어드랍에서 실수하면 내 코인이 통째로 사라진다. 9년 동안 이걸로 피해 본 사람을 수도 없이 봤다.

코인을 먼저 보내라고 하면 100% 사기다.

진짜 에어드랍은 절대 먼저 뭔가를 요구하지 않는다. "10 USDT 보내면 100 토큰을 돌려준다"는 건 세상에 없다.

"지금 당장 클레임하지 않으면 없어져요"

급박감을 조성해서 판단력을 흐리는 수법이다. 진짜 에어드랍의 클레임 기간은 보통 몇 달이다. 급할 이유가 없다.

여러 지갑으로 나눠서 하면 다 막힌다.

AI 기반 온체인 분석 도구(Trusta Labs 등)가 같은 IP, 같은 행동 패턴, 같은 타이밍을 전부 잡아낸다. Linea 에어드랍 때 130만 명 중 40%가 이렇게 탈락했다.

시드 구문은 절대 입력하지 않는다.

어떤 사이트도, 어떤 사람도, 어떤 이유로도 시드 구문을 물어볼 이유가 없다. 물어본다면 사기다.

#솔직하게 말할게

에어드랍이 무조건 돈이 되는 건 아니다.

열 개를 해서 실제로 의미 있는 금액이 되는 건 한두 개 정도다. 나머지는 시간 낭비처럼 느껴질 수도 있다.

위에서 소개한 2026년 프로젝트들도 마찬가지다. 에어드랍이 나올지 안 나올지, 나온다면 얼마나 줄지, 언제 줄지 — 아무것도 확정된 게 없다.

하지만 반대로 생각해보면, 지금 MetaMask로 스왑 한 번 해보는 건 10분이면 되고 비용은 가스비 몇 달러다. Base에서 유니스왑 써보는 것도 마찬가지다.

그 몇 달러와 10분이 나중에 수백, 수천 달러가 될 수도 있고 아닐 수도 있다.

확실한 건 하나다. 안 하면 0%이고, 하면 확률이 생긴다.

지인이 카톡으로 "야 갑자기 돈이 들어왔어"라고 보내왔을 때, 나는 그 친구한테 이렇게 말했다.

"그러니까 내가 써보라고 했잖아."

에어드랍 참여 시 항상 공식 채널을 확인하고, 시드 구문과 개인키는 절대 공유하지 마세요. 이 글은 투자 권유가 아닙니다.

거래소에서 코인 사고, 지갑으로 옮기고, 필요하면 다시 보내고. 이게 전부인 줄 알았다. 근데 코인이 조금씩 쌓이기 시작하면서 어느 순간 이런 생각이 든다.

"이거 진짜 안전한 건가?"

그냥 지나칠 수도 있는 질문인데, 한 번 떠오르면 이상하게 신경이 쓰인다. 뉴스에서 "해킹으로 수십억 증발"이라는 기사를 볼 때마다 특히 그렇다. 남의 얘기 같지만, 막상 내 지갑 들여다보면 찜찜한 기분이 사라지질 않는다.

그 찜찜함이 괜한 게 아니다. 코인 지갑은 은행 계좌랑 다르다. 해킹 당해도, 실수로 잘못 보내도, 누군가 빼가도 — 돌려받을 방법이 없다. 그래서 어디에, 어떻게 보관하느냐가 생각보다 중요한 문제다.

이 글은 그 찜찜함을 갖고 있는 사람들을 위해 쓴다.

#소프트웨어 지갑 — 편리하지만 구조적 한계가 있다

소프트웨어 지갑은 PC나 폰에 설치하는 앱 또는 브라우저 확장 프로그램이다.

가장 많이 쓰이는 건 MetaMask, OKX 월렛, Rabby 세 가지다. 각각 성격이 조금씩 다른데, 어떤 걸 쓰느냐에 따라 경험이 꽤 달라진다.

#MetaMask

크립토 생태계의 사실상 표준 지갑이다.

2016년부터 운영해온 만큼 레퍼런스가 압도적이다. DeFi, DEX, NFT 할 것 없이 대부분의 서비스가 MetaMask 연결을 기본으로 지원한다. 처음 지갑을 만들 때 MetaMask를 쓰는 이유가 바로 이것이다. 어디서 막혀도 검색하면 답이 나온다.

2025~2026년 사이에 대규모 업데이트가 있었다. 기존에는 이더리움 계열(EVM) 네트워크만 됐는데, 이제 비트코인, 솔라나, 트론까지 같은 지갑에서 관리할 수 있다. 멀티체인 지원이 크게 넓어진 것이다. 거기에 트랜잭션 승인 전에 사람이 읽을 수 있는 형태로 내용을 미리 보여주는 기능도 추가됐다. 예전 MetaMask와는 꽤 달라진 셈이다.

심지어 MetaMask Card도 나왔다. 지갑 잔액으로 Mastercard 가맹점 어디서나 결제할 수 있는 카드다.

기능이 많아진 만큼 "그냥 지갑"이라기보다 하나의 금융 플랫폼에 가까워지고 있다. 다만 기능이 늘어날수록 복잡해진다는 단점도 있다. 처음 쓰는 사람 입장에서는 여전히 UI가 직관적이지 않다는 말이 나온다.

#OKX Wallet

거래소 OKX에서 만든 지갑이다. 멀티체인 지원이 핵심 강점이다.

이더리움, 솔라나, 비트코인, 트론을 포함해 130개 이상의 체인을 하나의 지갑에서 관리할 수 있다. 체인마다 지갑을 따로 설치하고 관리하는 번거로움이 없다. 지갑 내부에 내장 DEX도 있어서 앱을 이동하지 않고도 바로 스왑이 된다.

2026년 3월에는 OKX Agentic Wallet을 출시했다. AI 에이전트가 직접 온체인 트랜잭션을 실행할 수 있는 기능이다. 아직 초기 단계지만, AI와 지갑의 결합이라는 방향성을 보여주는 업데이트다.

모바일 앱 완성도도 높아서, PC보다 폰으로 코인을 관리하는 사람에게 특히 편하다.

다만 OKX라는 중앙화 거래소 브랜드와 연결되어 있다는 점이 거슬리는 사람이 있다. 소프트웨어 지갑이니까 탈중앙화 지갑이긴 한데, "거래소가 만든 지갑"에 대한 신뢰 문제는 개인마다 받아들이는 방식이 다르다. MetaMask만큼 dApp 지원이 넓지 않아서 일부 서비스에서 연결이 안 되는 경우도 있다.

#Rabby

DeBank 팀이 만든 지갑으로, "MetaMask보다 안전하게"를 슬로건으로 내세운다.

가장 차별화되는 기능은 트랜잭션 시뮬레이션이다. 서명 버튼을 누르기 전에 "이 컨트랙트를 승인하면 내 지갑에서 실제로 뭐가 나가는지"를 미리 보여준다. 그냥 "Approve"만 뜨는 게 아니라, 예상 결과를 눈으로 확인하고 승인할 수 있다.

예를 들어 DEX에서 ETH를 USDC로 스왑하는 트랜잭션을 승인하려 할 때, Rabby는 "0.5 ETH 나가고 1,200 USDC 들어온다"는 식으로 미리 결과를 보여준다. 이게 예상과 다르면 그냥 취소하면 된다. 악성 컨트랙트가 지갑을 통째로 Approve 해가는 것도 이 단계에서 잡힌다.

여기에 피싱 사이트 감지 기능도 있다. 알려진 피싱 주소나 의심스러운 도메인에 연결하려 할 때 경고를 띄운다. 지갑 주소가 여러 개라면 멀티 주소 관리도 편하다. 각 주소의 자산을 한 화면에서 볼 수 있고, 체인별로 묶어서 보여주기 때문에 자산 파악이 MetaMask보다 직관적이다.

DeFi를 자주 쓰다 보면 한 번쯤은 의심스러운 컨트랙트 승인 창을 마주치게 된다. 그 순간 이게 안전한 건지 판단이 안 서는데, Rabby는 그 판단을 조금 더 쉽게 만들어준다. 보안에 신경 쓰는 사람들 사이에서 점점 쓰는 사람이 늘고 있는 이유다.

iOS와 안드로이드 모바일 앱도 있다. PC 브라우저 확장 프로그램만 있는 줄 알고 지나치는 사람이 많은데, 폰에서도 같은 시뮬레이션 기능이 동작한다.

단점은 MetaMask에 비해 검증된 역사가 짧다는 것, 그리고 일부 오래된 dApp에서 연결이 안 되는 경우가 있다는 것이다. 지원 체인 수도 MetaMask나 OKX에 비해 많지 않아서, 이더리움 계열 위주로 쓰는 사람에게 맞는 지갑이다.

#셋 다 가진 공통적인 한계

MetaMask를 쓰든, OKX를 쓰든, Rabby를 쓰든 — 결국 인터넷에 연결된 기기 위에서 돌아간다는 사실은 같다.

개인키가 암호화되어 있지만, PC 어딘가에 저장되어 있다는 의미다.

PC가 악성코드에 감염되거나, 피싱 사이트에 속아서 시드 문구를 입력하거나, 브라우저 확장 프로그램이 해킹되면 — 그 순간 지갑 안의 코인은 전부 사라진다.

더 무서운 건 속도다. 해커가 지갑에 접근하면 몇 초 안에 전부 빼간다. 은행처럼 "이상 거래 감지"로 막아주는 시스템이 없다. 알았을 때는 이미 늦다.

#하드웨어 지갑이 다른 이유

하드웨어 지갑은 USB처럼 생긴 물리적인 장치다.

렛저(Ledger), 트레저(Trezor) 같은 제품이 있다. 생긴 건 평범한데 작동 방식이 근본적으로 다르다.

핵심은 하나다. 개인키가 절대로 인터넷에 나오지 않는다.

소프트웨어 지갑은 서명(트랜잭션 승인)을 PC나 폰에서 처리한다. 하드웨어 지갑은 서명을 장치 내부에서만 처리한다. PC에 악성코드가 심어져 있어도, 피싱 사이트에 연결하더라도, 개인키 자체는 장치 바깥으로 나오지 않는다.

즉, 해킹이 일어나려면 장치를 물리적으로 빼앗아야 한다.

현실에서 해커가 집 문을 따고 들어와서 렛저를 훔쳐가는 시나리오는 인터넷 해킹보다 훨씬 어렵다. 그리고 PIN 번호를 모르면 장치를 가져가도 쓸 수가 없다.

이 차이가 생각보다 크다.

#렛저를 쓰는 이유

하드웨어 지갑 중에서도 렛저를 많이 쓰는 이유가 있다.

지원하는 코인 수가 압도적이다. 렛저는 5,500개 이상의 코인과 토큰을 지원한다. 이더리움 기반 토큰은 물론이고, 비트코인, 솔라나, 폴카닷, 코스모스 등 메이저 코인은 거의 다 된다. Ledger Wallet(2026년 1분기에 Ledger Live에서 리브랜딩)이라는 공식 앱에서 잔액 확인, 전송, 스테이킹까지 할 수 있다. 여러 체인 자산을 앱 하나에서 관리할 수 있어서 따로 지갑을 오갈 필요가 없다.

MetaMask와 연동된다. 렛저를 갖고 있어도 DEX나 DeFi를 쓸 수 있다. 렛저를 MetaMask에 연결하면 트랜잭션을 승인할 때 렛저 장치에서 직접 버튼을 눌러야 한다. 화면에서 클릭만으로 서명되지 않는다. 악성코드가 있어도 장치 없이는 승인이 안 된다. 즉, DeFi의 편리함을 유지하면서 보안 수준은 하드웨어 지갑 수준으로 올릴 수 있다.

보안 칩이 다르다. 렛저는 신용카드나 여권에 쓰이는 보안 칩(SE, Secure Element)을 탑재한다. 일반 마이크로컨트롤러가 아니라 물리적 해킹 시도에 저항하도록 설계된 칩이다. PIN을 3번 틀리면 장치가 초기화되어 개인키를 추출할 수 없게 된다.

제품 라인업이 다양하다. 가장 기본 모델인 Nano S Plus는 약 $79, 블루투스 지원 Nano X는 약 $149다. 2025년 10월 출시된 Nano Gen5($179~199)는 2.8인치 E Ink 터치스크린을 탑재해 Nano X보다 사용이 편리하고 현재 가성비 추천 모델이다. 더 상위로는 Flex($249), Stax($399)가 있다. 보안 수준은 모든 모델 동일하며 차이는 편의성이다.

검증된 역사가 있다. 2014년부터 운영해온 프랑스 회사다. 전 세계 600만 개 이상 판매된 점에서 신뢰도를 가늠할 수 있다. 처음엔 가격이 비싸 보이지만, 지키려는 코인의 금액이 기기값보다 크다면 충분히 투자할 만하다.

#렛저라고 100% 안전하지는 않다

솔직하게 써야 할 부분이 있다.

2020년 고객 데이터 유출. 렛저 쇼핑몰 DB가 해킹되면서 이름, 이메일, 전화번호, 배송 주소 약 27만 건이 유출됐다. 코인 자체는 안전했지만, 이후에 고객들에게 피싱 문자와 이메일이 쏟아졌다. 심지어 "렛저 공식 업데이트"처럼 위장한 가짜 기기를 우편으로 보내는 사기도 있었다. "렛저 직원입니다"라며 시드 문구를 요청하는 전화 사기도 여럿 보고됐다. 기기 보안은 훌륭한데 회사 보안은 별개였던 셈이다.

2023년 Ledger Recover 논란. 렛저가 시드 문구를 세 조각으로 분리해 서로 다른 서버에 암호화 백업해주는 유료 서비스를 발표했다. 시드 문구를 잃어버렸을 때 복구할 수 있도록 하는 취지였지만, 크립토 커뮤니티의 반응은 차가웠다. "개인키가 장치 밖으로 절대 나오지 않는다"는 렛저의 기존 원칙과 정면으로 충돌하기 때문이다. 렛저 측은 "선택 사항이며 강제가 아니다"라고 해명했지만, 이 기능 자체가 존재한다는 사실이 불신의 씨앗이 됐다. 이후로 트레저(Trezor)나 콜드카드(Coldcard) 같은 경쟁 제품으로 갈아탄 사람들도 나왔다.

2023년 Connect Kit 공급망 해킹. 렛저가 배포하는 JavaScript 라이브러리(Connect Kit)가 해킹되어 악성 코드가 심어진 적이 있다. 이 라이브러리를 사용하는 DeFi 앱들이 일시적으로 영향을 받았고, 실제 자금 피해도 발생했다. 기기 자체는 안전했지만, 렛저 생태계에 연결된 소프트웨어가 공격 벡터가 될 수 있다는 걸 보여준 사건이다.

이런 부분을 알고 쓰는 것과 모르고 쓰는 건 다르다. 장치 자체의 보안은 여전히 소프트웨어 지갑보다 훨씬 낫다. 다만 "렛저를 갖고 있으면 무조건 안전하다"는 생각은 위험하다. 어떤 회사도 완벽하지 않고, 기기 보안과 회사 보안은 별개라는 걸 인식하고 쓰는 게 맞다.

#정리 — 어떻게 나눠 쓸까

실제로 많은 사람들이 두 가지를 같이 쓴다.

• 소프트웨어 지갑(MetaMask / OKX / Rabby) — 자주 쓰는 소액, DEX 연결, DeFi 활동
• 하드웨어 지갑(렛저) — 한동안 안 건드릴 코인, 큰 금액

은행에서 체크카드 쓰듯이 소프트웨어 지갑을 쓰고, 큰돈은 금고에 넣듯이 하드웨어 지갑에 옮겨두는 개념이다.

얼마부터 하드웨어 지갑을 써야 하느냐는 사람마다 다르다. 딱 정해진 기준은 없다. 다만 "이 코인 날리면 좀 많이 아프겠다"는 생각이 드는 시점이 오면, 그때가 고민해볼 타이밍이다.

보안을 귀찮게 여기다가 한 번 당하면 돌이킬 방법이 없다. 코인 세계에서 그게 가장 잔인한 규칙이다.

MetaMask 지갑을 처음 만드는 방법은 MetaMask 지갑 세팅 완전 가이드에 정리해뒀다. 거래소에서 지갑으로 코인 보내는 방법은 MetaMask로 코인 받는 방법에서 확인할 수 있다.

여기까지 했다면 솔직히 꽤 한 거다. 처음엔 이것만 해도 뭔가 대단한 일을 한 것 같은 기분이 든다.

근데 딱 이 시점부터 머릿속이 다시 복잡해지기 시작한다.

거래소 앱 보다가 USDT가 눈에 밟힌다. "이게 달러랑 같은 건가?" 싶은데 물어보기도 애매하다. ETH 전송 누르면 수수료가 어떤 날은 500원이고 어떤 날은 3만 원이 뜬다. 왜 이렇게 들쭉날쭉한지 이해가 안 된다. 어디선가 "유니스왑에서 샀다"는 말을 듣는데, 유니스왑이 뭔지는 또 모른다.

이 세 가지 질문이 거의 동시에 온다. 그리고 알고 보면 서로 연결되어 있다.

#스테이블코인 — 코인인데 가격이 안 변한다고?

코인 시장에 오래 있다 보면 USDT, USDC를 쓸 일이 생각보다 많이 생긴다.

처음엔 별 관심이 없다. 가격도 안 변하고, 차트도 재미없고, 딱히 살 이유를 모르겠어서 그냥 넘긴다.

근데 코인을 좀 하다 보면 어느 순간 이게 왜 필요한지가 보이기 시작한다.

시장이 갑자기 무너질 것 같은 분위기가 온다. 들고 있는 알트코인을 팔고 싶은데, 원화로 출금하자니 거래소 수수료에 입출금 시간도 걸리고 번거롭다. 이럴 때 그냥 USDT로 바꿔두면 된다. 코인 생태계 안에 머물면서도 시장 등락에서 벗어날 수 있다.

일종의 대피소 같은 역할이다.

스테이블코인이란 1달러의 가치를 유지하도록 설계된 암호화폐다. 가격이 오르거나 내리지 않고, 항상 1달러 근처에 고정되어 있다. 그래서 '스테이블(stable, 안정적인)코인'이라고 부른다.

비트코인도 시황이 안 좋을 때는 하루에 5~10% 빠지는 날이 있고, 알트코인은 그보다 심하게 움직이는 경우도 흔하다. 코인으로만 자산을 들고 있으면 오늘 내 돈이 얼마인지 아침저녁이 다르다. 스테이블코인은 그 불안함에서 잠시 벗어나는 수단이다.

#USDT vs USDC, 진짜 다른 건 뭔가

둘 다 1달러짜리 스테이블코인이다.

쓰는 입장에서는 거의 똑같다고 느껴지는데, 발행하는 곳이 다르고 철학이 조금 다르다.

USDT는 Tether라는 회사에서 만들었다. 시장에 가장 많이 풀려있고 거래소, DEX 어디서든 지원한다. 유동성이 압도적이라 교환이 빠르고 슬리피지(원하는 가격과 실제 체결 가격의 차이)가 적다. 다만 과거에 한 가지 논란이 있었다. "달러를 실제로 1:1로 갖고 있냐"는 의혹이 제기된 적이 있었는데, 당시에 꽤 시끄러웠다. 지금은 어느 정도 정리됐지만 그 이미지가 아직 남아 있는 사람들이 있다.

USDC는 Circle이라는 회사가 발행한다. 미국 금융 당국의 규제를 받고, 준비금 감사 보고서를 공개하는 방식으로 투명성을 어필한다. 기관 투자자나 DeFi 프로토콜 쪽에서 선호하는 편이다.

일반 사용 입장에서는 크게 고민할 필요 없다. 어디서 쓰느냐에 따라 지원 여부가 다를 수 있으니 그냥 상황에 맞게 쓰면 된다.

#스테이블코인도 100% 안전하지는 않다

한 가지만 알아두면 좋다.

2022년에 UST(테라USD) 라는 스테이블코인이 하루아침에 1달러에서 거의 0원에 가깝게 무너진 사건이 있었다. 코인 역사에서 가장 충격적인 사건 중 하나였고, 수십조 원이 증발했다.

USDT나 USDC는 달러를 실제로 담보로 갖고 있는 방식이라 UST 같은 알고리즘 기반 스테이블코인과는 구조가 다르다. 리스크가 훨씬 낮다. 하지만 "스테이블코인이니까 무조건 안전하다"는 생각은 조심해야 한다.

발행 주체가 망하거나 문제가 생기면 담보도 의미가 없어질 수 있다. 그 가능성이 높다는 게 아니라, 코인 시장에서 "절대 안전"은 없다는 얘기다.

#가스비 — 왜 내 돈 보내는 데 또 돈이 드나

MetaMask에서 처음 전송을 시도하면 수수료 항목에 숫자가 붙어 있다.

어떤 날은 몇백 원이고, 어떤 날은 몇만 원이다. 같은 금액을 보내는데 왜 이렇게 다른지 이해가 안 된다.

이게 가스비(Gas Fee) 다.

처음엔 진짜 황당하다. 내 돈을 내 지갑에서 다른 지갑으로 보내는 건데 왜 수수료를 내야 하나. 은행 이체도 요즘은 무료인데.

원리를 알면 납득이 된다. 이더리움 블록체인은 전 세계에 분산된 수천 대의 컴퓨터가 돌아가면서 거래를 처리하고 검증한다. 이 작업에는 전기도 들고 연산도 든다. 그 비용을 내는 게 가스비다. 은행이나 카드사 같은 중간 기관이 없는 대신, 네트워크를 유지하는 참여자들에게 직접 보상이 돌아가는 구조다.

#왜 들쭉날쭉한가

가스비는 고정 금액이 아니다. 네트워크가 얼마나 바쁘냐에 따라 실시간으로 달라진다.

이더리움 네트워크는 한 번에 처리할 수 있는 트랜잭션 수가 정해져 있다. 수요가 몰리면 자리 경쟁이 생기고, 가스비를 더 많이 낸 트랜잭션이 먼저 처리된다. 급한 사람일수록 더 많이 내게 되는 구조다.

시장이 크게 움직이는 날 — 비트코인이 급락하거나 급등하는 날 — 모두가 동시에 뭔가를 하려고 한다. 팔거나, 헷지하거나, 다른 코인으로 옮기거나. 이럴 때 가스비가 평소의 수십 배까지 튄다.

10달러짜리 ETH를 보내려는데 가스비가 30달러가 나오는 상황이 생긴다. 그 순간 진짜 허탈하다.

NFT 민팅 날도 마찬가지다. 인기 있는 프로젝트 민팅이 열리면 수천 명이 동시에 트랜잭션을 날린다. 더 황당한 건, 그렇게 비싼 가스비를 내고 민팅에 실패해도 가스비는 돌려받지 못한다는 거다. 처리를 시도했다는 것 자체에 비용이 붙으니까.

반대로 새벽에 네트워크가 한산할 때는 가스비가 몇 센트 수준으로 내려가기도 한다. 급하지 않은 전송이라면 이 시간대를 노리는 것도 방법이다.

#레이어2 — 가스비 문제의 현실적인 해답

이더리움 메인넷에서만 쓰다가는 가스비에 치이는 날이 반드시 온다.

그래서 나온 게 레이어2(Layer 2, L2) 다.

쉽게 설명하면 이더리움 위에 올라탄 고속도로 같은 것이다. 트랜잭션을 한꺼번에 묶어서 처리하고, 그 결과만 이더리움에 기록한다. 이더리움의 보안성은 그대로 쓰면서 처리 비용을 대폭 낮춘다.

대표적인 게 Arbitrum, Base, Optimism이다.

이더리움 메인넷에서 ETH 전송 한 번에 5달러가 든다면, Arbitrum에서는 0.05달러도 안 든다. 같은 코인, 같은 지갑, 같은 화면인데 네트워크만 바꿨을 뿐이다.

요즘 유니스왑 같은 DEX나 DeFi 서비스들은 레이어2를 대부분 지원한다. 자주 트랜잭션을 날리거나 소액으로 뭔가를 해보고 싶다면 레이어2 네트워크를 먼저 세팅해두는 게 낫다. MetaMask에서 네트워크를 추가하는 방법은 MetaMask 지갑 만들기 가이드에 정리해뒀다.

#DEX — 거래소 없이 코인을 바꾼다는 게 어떤 의미인가

업비트, 빗썸, 코인원. 이런 거래소를 CEX(중앙화 거래소) 라고 부른다.

회사가 있고, 서버가 있고, 고객센터가 있다. 내가 계좌를 만들고 코인을 맡기면 거래소가 대신 보관하고 거래를 처리해준다. 익숙한 구조다.

DEX(탈중앙화 거래소) 는 이 중간 회사가 없다.

스마트컨트랙트라는 코드가 알아서 거래를 처리한다. 내 지갑에서 바로 이뤄지고, 회원가입도 신분 인증도 없다. 지갑 연결 하나로 끝이다.

가장 많이 쓰이는 게 유니스왑(Uniswap) 이다. 이더리움 생태계에서 가장 큰 DEX고, 하루 거래량이 수조 원이 넘는다.

#CEX가 있는데 DEX를 왜 쓰나

처음엔 "그냥 업비트 쓰면 되는 거 아닌가" 싶다. 편하고 익숙하고 고객센터도 있는데.

이유는 두 가지다.

첫 번째, 업비트에 없는 코인은 살 수 없다.

CEX는 상장 심사를 거친 코인만 거래된다. 관심 있는 프로젝트 토큰이 국내 거래소에 없는 경우가 생각보다 많다. DEX에서는 이더리움 네트워크 위에 배포된 토큰이라면 뭐든 교환할 수 있다. 상장 심사 같은 게 없으니까. 새로운 프로젝트들은 CEX에 올라오기 훨씬 전에 DEX에서 먼저 거래된다.

두 번째, 내 코인이 진짜 내 것이다.

CEX에 코인을 맡기면 그건 거래소 서버에 기록된 숫자다. 거래소가 망하거나, 해킹당하거나, 출금을 막으면 내가 어떻게 할 수 없다.

2022년 FTX 사태를 기억하는 사람이라면 이게 단순한 가능성의 문제가 아니라는 걸 안다. 세계 2위 거래소가 며칠 만에 파산했다. 출금 요청이 밀렸고, 많은 사람이 자산을 돌려받지 못했다. 규모가 크고 유명한 곳이라고 무조건 안전한 게 아니라는 게 그때 확실히 증명됐다.

DEX는 내 지갑에서 직접 거래가 이뤄진다. 플랫폼이 어떻게 되든 내 자산은 내 지갑에 있다.

#유니스왑 처음 써보기

처음 들어가면 생각보다 단순하다.

app.uniswap.org 에 접속하면 스왑 화면이 바로 나온다. Connect 버튼으로 MetaMask 연결하면 준비 끝이다. 위에 내가 갖고 있는 코인을 선택하고, 아래에 받고 싶은 코인을 선택한다. 금액을 입력하면 예상 수령량, 가스비, 슬리피지가 표시된다. 확인하고 Swap 누르면 MetaMask 승인 창이 뜨고, 거기서 한 번 더 확인하면 끝이다.

처음엔 뭔가 거창할 것 같은데, 막상 해보면 은행 이체보다 간단하다고 느끼는 사람도 있다.

다만 한 가지는 꼭 챙겨야 한다.

유니스왑 사칭 피싱 사이트가 생각보다 많다. 구글에서 "유니스왑"을 검색하면 광고 영역에 가짜 사이트가 올라와 있는 경우도 있었다. 주소창에 직접 입력하거나, 공식 북마크를 쓰는 습관이 중요하다.

#DEX에서 조심해야 할 것들

편한 만큼 책임이 전부 본인한테 있다.

CEX는 상장 심사가 있고, 사기성 짙은 프로젝트는 걸러진다. DEX는 코드를 배포하는 순간 바로 토큰이 생긴다. 쓰레기 토큰도, 러그풀(개발자가 갑자기 유동성 빼버리는 사기)도 아무 제약 없이 올라온다.

모르는 토큰을 살 때는 컨트랙트 주소를 직접 확인하는 게 필수다. 이름이 같아도 주소가 다르면 전혀 다른 토큰이다. 이더스캔(etherscan.io)에서 프로젝트 공식 주소를 확인하고 그걸 유니스왑에 직접 붙여넣는 방식이 안전하다.

그리고 중요한 게 하나 더 있다.

가스비는 그 네트워크의 기본 코인으로 낸다.

이더리움 메인넷과 Arbitrum, Base 같은 L2에서는 ETH로 낸다. Polygon이면 POL, BSC면 BNB다. 네트워크마다 다르다.

문제는 USDT만 들고 있다가 스왑하려고 하면 막힌다는 거다. ETH가 없으면 이더리움/L2 네트워크에서는 가스비를 낼 수 없어서 트랜잭션 자체가 안 된다. 유니스왑을 쓰려면 ETH를 조금은 갖고 있어야 한다. 처음에 이걸 몰라서 당황하는 경우가 있다.

#세 개가 이렇게 연결된다

각각 따로 이해하면 잘 와닿지 않는다. 실제 흐름으로 보면 이렇다.

업비트에서 ETH를 산다 → MetaMask로 옮긴다 → 가스비를 내고 유니스왑에서 원하는 토큰으로 스왑한다 → 시황이 흔들릴 것 같으면 USDC로 바꿔서 대기한다 → 다시 기회가 왔다 싶으면 다른 토큰으로 교환한다

이게 DeFi의 기본 사이클이다.

스테이블코인은 대피소, 가스비는 통행료, DEX는 환전 창구다. 이 세 가지를 이해하면 이더리움 생태계에서 할 수 있는 것들의 폭이 달라진다.

처음엔 "이걸 왜 이렇게 복잡하게 해야 하나" 싶다. 근데 한 번 흐름이 익으면 오히려 거래소를 거치는 게 번거롭게 느껴지기 시작한다.

#마무리

이 세 가지를 머리로만 이해하는 것보다 직접 한 번씩 해보는 게 훨씬 빠르다.

소액으로 좋다. USDT 5달러어치를 USDC로 스왑해본다. 레이어2 네트워크로 바꿔서 가스비가 얼마나 다른지 본다. 이 과정에서 가스비가 왜 저렇게 뜨는지, ETH가 왜 있어야 하는지가 자연스럽게 이해된다.

설명을 열 번 읽는 것보다 한 번 해보는 게 낫다. 코인 공부는 결국 그렇다.

MetaMask 처음 만들기는 MetaMask 지갑 처음 만들기 완전 가이드에,
거래소에서 지갑으로 보내는 법은 코인 사서 내 지갑으로 보내기에 정리해뒀다.

유튜브에는 "이 코인 지금 사야 함" 류의 영상이 넘쳐났고, 주변에서는 "나는 몇 배 벌었다"는 얘기만 들렸다. 다들 수익 인증만 하지, 얼마나 잃었는지는 아무도 얘기 안 했다.

그러다 직접 해보니까 생각보다 잃을 포인트가 너무 많았다. 코인 자체의 등락 말고도, 그냥 기본 개념을 몰라서 날리는 경우가 생각보다 훨씬 많더라.

이 글은 투자 조언이 아니다.

그냥 "처음에 이걸 몰라서 당황했다" 는 얘기다. 코인 자체보다 이런 기본기부터 알고 시작했으면 훨씬 덜 헤맸을 텐데 싶어서 쓴다.

#1. 네트워크 잘못 선택해서 코인이 사라진 것처럼 되는 경우

이게 진짜 초보한테 가장 흔한 사고다.

거래소에서 USDT를 출금할 때 이런 화면이 나온다.

출금 네트워크 선택
> ERC20  (이더리움)
> TRC20  (트론)
> BEP20  (BNB 스마트체인)
> Polygon

처음 보면 그냥 아무거나 누르고 싶은 충동이 생긴다. 어차피 같은 USDT 아닌가 싶어서.

근데 이게 결정적으로 중요하다.

쉽게 설명하면 이렇다. 같은 1만 원짜리 지폐라도, 한국 은행 계좌가 있어야 입금이 된다. 미국 달러 계좌로는 원화 입금이 안 되는 것처럼, 코인도 어떤 네트워크로 보내냐에 따라 받을 수 있는 지갑이 다르다.

MetaMask 기본 설정은 이더리움 메인넷이다. 여기서 TRC20 네트워크로 USDT를 보내버리면 MetaMask에서 아무리 찾아도 안 보인다.

없어진 게 아니라 다른 네트워크에 들어가 있는 것인데, 처음엔 그냥 사라진 것처럼 느껴진다. 멘탈이 흔들리는 순간이다.

복구가 아예 불가능한 건 아닌데, 과정이 꽤 복잡하고 잘못하면 진짜로 날릴 수도 있다. 처음부터 맞는 네트워크로 보내는 게 답이다.

기본 원칙 — 보내는 네트워크와 받는 지갑의 네트워크가 반드시 같아야 한다.

MetaMask 기본 세팅이면 이더리움(ERC20) 또는 Polygon 네트워크로 받으면 된다. 폴리곤 네트워크 추가 방법은 MetaMask 지갑 만들기 가이드에 정리해뒀다.

#2. 주소 하나만 틀려도 코인은 돌아오지 않는다

은행 계좌번호를 잘못 치면 고객센터에 전화해서 취소할 수 있다. 코인은 그런 게 없다.

한 번 전송하면 블록체인에 기록되고 끝이다. 존재하지 않는 주소로 보내도, 실수로 다른 주소로 보내도 — 취소나 환불이 구조적으로 불가능하다. 관리 주체가 없으니까.

처음엔 주소가 너무 길어서 앞뒤 몇 글자만 대충 보고 "맞겠지" 하고 보내는 경우가 있다.

0xAb5801a7D398351b8bE11C439e05C5B3259aeC9

이 주소에서 중간 글자 하나가 달라도 완전히 다른 지갑이다. 내가 보낸 코인은 영영 찾을 수 없다.

주소를 항상 복사-붙여넣기로 처리하고, 전송 전에 앞 5자리, 뒤 5자리만큼은 눈으로 직접 비교하는 습관을 들이는 게 좋다.

그리고 클립보드를 바꿔치기하는 악성코드가 실제로 존재한다.

복사한 주소가 붙여넣는 순간 몰래 다른 주소로 바뀌는 방식이다. 황당하게 들리지만 실제로 이것 때문에 코인 날린 사례가 있다. 출처 모를 프로그램을 설치했거나 의심스러운 링크를 클릭한 PC에서는 특히 조심해야 한다.

#3. 가격이 싸다고 좋은 코인이 아니다

처음 코인 살 때 이런 생각을 했다.

"비트코인은 너무 비싸다. 100원짜리 코인이 100배 오르면 훨씬 낫지 않나."

이게 함정이다.

코인 가격 그 자체는 사실 별 의미가 없다. 중요한 건 시가총액(Market Cap) 이다.

시가총액 = 코인 가격 × 발행된 총 수량

예를 들어 1원짜리 코인이 1조 개 발행되어 있으면 시가총액은 1조 원이다.

100만 원짜리 코인이 100만 개만 있어도 시가총액은 똑같이 1조 원이다.

둘 다 같은 규모의 코인인데, 가격만 보면 전혀 다르게 느껴진다. 그래서 "싸 보인다"는 착각이 생기는 거다.

오히려 발행량이 무지막지하게 많고 가격이 낮은 코인일수록 세력이 물량으로 흔들기 쉽고, 한 번 빠지기 시작하면 회복이 거의 안 되는 경우가 많다.

시가총액은 코인마켓캡(coinmarketcap.com)이나 코인게코(coingecko.com)에서 확인할 수 있다. 코인을 살 때 가격보다 시가총액 순위를 먼저 보는 습관을 들이면 좋다.

#4. 차트를 모르면 읽기 전에 당한다

코인 처음 하면 차트를 그냥 직관으로 해석하게 된다. "올라가고 있으니까 사야지", "내려가니까 팔아야지."

근데 차트에는 최소한 알아야 할 개념들이 있다.

거래량은 그날 얼마나 많이 사고팔렸는지를 보여준다. 가격이 오를 때 거래량도 같이 늘어야 진짜 상승이다. 가격은 오르는데 거래량이 없다면 신뢰하기 어렵다.

봉차트(캔들)는 일정 시간 동안의 시가, 고가, 저가, 종가를 한눈에 보여준다. 빨간 봉은 그 시간 동안 내렸다는 뜻이고, 파란(또는 초록) 봉은 올랐다는 뜻이다. 이것만 알아도 차트가 좀 다르게 보인다.

처음엔 차트가 너무 복잡해 보여서 그냥 넘기게 되는데, 최소한 이 두 가지 개념은 익히고 시작하는 게 낫다.

#5. FOMO — 다들 오른다고 할 때 샀더니 그게 고점이었다

FOMO는 Fear Of Missing Out, 나만 기회를 놓치는 것 같은 불안함이다.

코인판에서는 이게 유독 강하게 온다.

단톡방, 유튜브, 트위터(X)에서 "지금 오르고 있다", "이거 지금 안 사면 후회한다" 는 분위기가 만들어지면 뭔가 급하게 사야 할 것 같은 기분이 든다. 이미 오른 걸 보면서 "나만 못 탄 것 같아서" 쫓아 들어가는 거다.

근데 그 분위기가 가장 뜨거울 때가 대체로 고점 근처다.

모두가 관심을 갖기 시작할 때는 이미 많이 오른 뒤다. 그 시점에 사면 오래 물려 있거나, 크게 빠지는 걸 고스란히 맞게 된다.

이건 솔직히 막기가 진짜 어렵다. 머리로는 알아도 감정이 먼저 반응하니까. 그나마 도움이 됐던 건 이 생각이었다.

"지금 안 사면 끝이야" 라는 생각이 드는 순간이 오히려 가장 위험한 타이밍일 수 있다.

조급함이 느껴질 때 잠깐 멈추는 것만으로도 꽤 많은 실수를 막을 수 있다.

#6. 거래소에만 두는 것도 리스크다

코인을 샀으면 그냥 거래소 앱에 두면 되는 거 아닌가 싶었다. 편하긴 하다.

근데 거래소는 내 코인을 대신 보관해주는 곳이다. 내 지갑이 아니다.

거래소가 해킹당하거나, 운영 문제가 생기거나, 갑자기 출금을 막아버리면 내 코인에 접근하지 못하는 상황이 생길 수 있다.

이게 먼 나라 얘기가 아니다.

2022년 FTX라는 세계 2위 거래소가 갑자기 파산했다. 수많은 사람이 거래소 안에 있던 자산을 그대로 날렸다. 당시 한국 사용자들도 피해를 입었다. 거래소가 크다고 무조건 안전한 게 아니라는 게 그때 확실히 증명됐다.

금액이 크지 않고 단기 트레이딩 목적이라면 거래소에 두는 것도 현실적으로 괜찮다. 다만 장기 보유 목적이거나 금액이 의미 있는 수준이 됐다면, MetaMask 같은 개인 지갑으로 옮기는 걸 진지하게 고려해볼 필요가 있다.

개인 지갑으로 옮기면 거래소가 어떻게 되든 내 코인은 내 손에 있다.

MetaMask 세팅이 처음이라면 MetaMask 지갑 만들기 가이드를,
거래소에서 내 지갑으로 보내는 법은 코인 사서 내 지갑으로 보내기에 정리해뒀다.

#7. 시드 문구(복구 구문)를 대충 보관했다가 지갑을 잃는다

MetaMask를 처음 만들면 12개 단어로 된 시드 문구가 나온다.

w***h  c*******e  p*******e  f**d  s***e  o**n  d*****r  c***k  r**d  a***n  i*e  l***t

(실제 단어는 본인 지갑에서만 확인해야 한다. 절대 외부에 노출하지 말 것.)

이게 지갑의 마스터 열쇠다. 이 12개 단어를 순서대로 입력하면 어느 기기에서든 내 지갑을 그대로 복구할 수 있다.

핸드폰을 잃어버렸을 때, 앱을 실수로 삭제했을 때, 새 기기로 바꿨을 때 — 이게 있으면 모든 게 해결된다.

반대로 이걸 잃어버리면 지갑 안에 아무리 많은 코인이 있어도 영영 꺼낼 방법이 없다. MetaMask 고객센터도, 경찰도, 아무도 도와줄 수 없다. 그냥 없어지는 거다.

그래서 보관 방법이 중요하다.

• 스크린샷 저장 — 절대 안 된다. 갤러리가 클라우드에 자동 백업되면 끝이다.
• 메모장이나 노트 앱 저장 — 위험하다. 기기가 해킹당하면 같이 털린다.
• 카카오톡이나 메신저로 자신에게 전송 — 절대 안 된다. 계정이 털리는 순간 지갑도 같이 털린다.

가장 안전한 방법은 종이에 직접 적어서 물리적으로 보관하는 거다. 디지털이 하나도 없으니 해킹으로 털릴 방법이 없다. 오래된 방식처럼 보이는데 이게 진짜 기본이다.

두 군데 이상 나눠서 보관하면 더 좋다.

#8. 검증 안 된 사이트에서 지갑 연결했다가 탈탈 털리는 경우

이건 경험하고 나면 너무 허탈한 케이스다.

"에어드랍 받으려면 지갑 연결하세요", "이 NFT 무료로 민팅하세요" 같은 링크를 눌러서 MetaMask를 연결했다가 지갑 안에 있는 자산이 전부 사라지는 사고가 실제로 자주 일어난다.

지갑을 연결할 때 서명 요청이 오는데, 그 내용을 제대로 읽지 않고 "승인"을 누르면 내 지갑에 대한 권한을 악의적인 스마트컨트랙트에 넘기게 된다. 그러면 그쪽에서 내 코인을 마음대로 가져갈 수 있다.

규칙은 간단하다.

• 공식 사이트 주소를 항상 직접 입력하거나 북마크에서 열 것
• 출처 모를 링크로 들어간 사이트에서는 지갑 연결 자체를 안 하는 게 낫다
• 서명 요청이 왔을 때 내용을 이해 못 하겠다면 그냥 거절할 것

공짜라는 말에 끌려서 지갑을 연결하는 순간이 가장 위험하다.

#마무리

여기 쓴 것들이 전부 대단한 내용은 아니다.

그냥 "이거 모르면 당할 수 있다" 는 것들이다. 코인 시장 자체의 리스크랑은 별개로, 기본 개념을 몰라서 날리는 건 사실 좀 억울하지 않나.

투자 판단은 각자 알아서 하는 거고, 오를지 내릴지는 아무도 모른다. 그래도 이 정도는 알고 시작하면 최소한 기본적인 실수는 피할 수 있다.

그러다 코드 리뷰에서 조용히 코멘트가 달리기 시작했다. "이거 N+1 터집니다", "여기 트랜잭션 범위 다시 확인해보세요", "Entity 그대로 반환하면 안 됩니다" — 다 아는 말 같은데 왜 내 코드가 문제인지 처음엔 잘 몰랐다.

아래는 그때 지적받고 나서야 이해한 것들이다.

#JPA N+1 — 모르면 운영서버에서 알게 된다

처음에 N+1이 뭔지 설명을 들어도 와닿지 않았다. 직접 겪기 전까진.

이름 자체가 좀 생소한데, 일단 이렇게 생각하면 된다.

주문 목록을 조회했더니, 각 주문마다 주문한 사람 정보를 따로 또 DB에 물어보는 상황

코드로 보면 이렇다.

List<Order> orders = orderRepository.findAll(); // 쿼리 1번
 
for (Order order : orders) {
    // 루프 돌 때마다 getMember() 할 때마다 쿼리가 1번씩 더 나간다
    System.out.println(order.getMember().getName());
}

주문이 100개면 쿼리가 총 101번 나간다. 주문 목록 가져올 때 1번, 루프 돌면서 각 주문 주인 조회할 때 100번.

왜 이런 일이 생기냐면, JPA가 연관된 엔티티(여기선 Member)를 기본적으로 필요할 때 가져오도록 설정되어 있기 때문이다. order.getMember() 를 호출하는 그 순간 "아, 멤버가 필요하구나" 하고 그때서야 DB에 쿼리를 날린다. 이걸 지연 로딩(Lazy Loading) 이라고 한다.

개발할 때는 데이터가 5~10개라 전혀 모르고 넘어간다. 운영에서 주문이 수천 건 쌓이고 나서야 슬로우쿼리 알람으로 알게 된다.

해결은 단순하다. 처음부터 같이 가져오면 된다.

// JPQL fetch join — "주문 가져올 때 멤버도 같이 JOIN해서 가져와"
@Query("SELECT o FROM Order o JOIN FETCH o.member")
List<Order> findAllWithMember();

이렇게 하면 쿼리 1번에 주문 + 멤버 정보를 한 번에 가져온다.

-- fetch join 시 실제로 나가는 쿼리 (1번)
SELECT o.*, m.*
FROM orders o
INNER JOIN member m ON o.member_id = m.id

@EntityGraph 를 쓰는 방법도 있다. JPQL 직접 안 쓰고 어노테이션으로 해결할 수 있어서 간단한 경우엔 이게 더 편하다.

@EntityGraph(attributePaths = {"member"})
List<Order> findAll();

한 가지 주의할 점은 fetch join 과 페이징을 같이 쓰면 경고가 뜬다. HibernateJpaDialect: firstResult/maxResults specified with collection fetch; applying in memory 이 로그가 보이면 페이징이 메모리에서 처리되고 있다는 뜻이다. 데이터 많으면 OOM 난다. 이때는 @BatchSize 나 쿼리 분리로 풀어야 한다.

#@Transactional 붙이면 다 해결된다는 착각

트랜잭션이 중요하다는 건 알겠는데, 처음엔 그냥 서비스 메서드마다 다 붙이면 되는 거 아닌가 싶었다.

@Service
public class UserService {
 
    @Transactional // 일단 다 붙이고 보자
    public void createUser(UserDto dto) { ... }
 
    @Transactional // 조회인데도 붙임
    public UserDto getUser(Long id) { ... }
 
    @Transactional // private 메서드에도 붙임 — 이건 아예 동작 안 함
    private void sendWelcomeEmail(User user) { ... }
}

문제가 몇 가지 있다.

조회에 쓰기 트랜잭션을 열면 불필요한 비용이 생긴다. 읽기만 하는 메서드엔 @Transactional(readOnly = true) 를 쓰는 게 맞다. DB 입장에선 읽기 전용으로 최적화할 수 있고, 실수로 영속성 컨텍스트에서 변경이 일어나도 flush가 안 된다.

private 메서드에 @Transactional 은 아무 효과가 없다. Spring 트랜잭션은 프록시 기반이라 외부에서 호출되는 public 메서드에서만 동작한다. 이걸 모르고 같은 클래스 내에서 @Transactional 붙은 메서드를 내부 호출하면 트랜잭션이 적용되지 않는다.

@Service
public class OrderService {
 
    public void placeOrder(OrderDto dto) {
        validate(dto);
        saveOrder(dto); // 이 호출은 트랜잭션 없이 실행됨
    }
 
    @Transactional // 의미없음 — 내부 호출이라 프록시 거치지 않음
    private void saveOrder(OrderDto dto) { ... }
}

의도한 대로 트랜잭션이 걸리길 원하면, 해당 로직을 별도 빈으로 분리하거나 placeOrder 자체에 트랜잭션을 걸어야 한다.

#Entity를 API 응답으로 그냥 반환하면 생기는 일

처음에 Controller에서 이렇게 짜면 편하긴 하다.

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id).orElseThrow();
}

근데 이게 쌓이면 나중에 꽤 골치 아파진다.

일단 Entity에 @JsonIgnore 같은 어노테이션이 생기기 시작한다. 비밀번호 필드는 내보내면 안 되니까. 양방향 연관관계가 있으면 JSON 직렬화하다가 무한 루프로 StackOverflowError 가 터지기도 한다. 그리고 나중에 API 스펙을 바꾸려고 하면 DB 구조랑 응답 구조가 엮여있어서 꼼짝을 못 하게 된다.

// 이렇게 분리하는 게 맞다
@GetMapping("/users/{id}")
public UserResponse getUser(@PathVariable Long id) {
    User user = userService.findById(id);
    return UserResponse.from(user);
}
 
// 응답 전용 DTO
public record UserResponse(Long id, String name, String email) {
    public static UserResponse from(User user) {
        return new UserResponse(user.getId(), user.getName(), user.getEmail());
    }
}

처음엔 클래스가 늘어나는 게 번거롭게 느껴지는데, 한 번 경험하고 나면 당연하게 쓰게 된다.

#예외처리 — 그냥 터지게 두거나, 모든 걸 잡거나

초반에 예외 처리 방식이 둘 중 하나였다.

// 방법 1 — 그냥 터지게 둠
public User findUser(Long id) {
    return userRepository.findById(id).get(); // NoSuchElementException
}
 
// 방법 2 — 무조건 잡고 로그만 남김
try {
    process();
} catch (Exception e) {
    e.printStackTrace(); // 이게 운영 코드에 있으면 안 됨
}

둘 다 문제다.

.get() 은 값이 없을 때 NoSuchElementException 을 던지는데 어디서 왜 터졌는지 알기 어렵다. Exception 을 통으로 잡고 e.printStackTrace() 만 하면 로그 수집 시스템에 안 찍히는 경우가 많고, 예외가 삼켜지면 호출부에서 정상 처리된 것처럼 흘러간다.

실무에서 많이 쓰는 패턴은 커스텀 예외 + 전역 핸들러 조합이다.

// 커스텀 예외
public class UserNotFoundException extends RuntimeException {
    public UserNotFoundException(Long id) {
        super("사용자를 찾을 수 없습니다. id=" + id);
    }
}
 
// 서비스
public User findUser(Long id) {
    return userRepository.findById(id)
        .orElseThrow(() -> new UserNotFoundException(id));
}
 
// 전역 예외 핸들러
@RestControllerAdvice
public class GlobalExceptionHandler {
 
    @ExceptionHandler(UserNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleNotFound(UserNotFoundException e) {
        log.warn(e.getMessage());
        return ResponseEntity.status(404).body(new ErrorResponse(e.getMessage()));
    }
}

이렇게 구조를 잡으면 예외가 터졌을 때 어디서 뭐가 문제인지 바로 보인다. 그리고 Controller마다 try-catch를 반복할 필요도 없어진다.

#테스트 없이 배포하는 습관

이건 기술 문제가 아닌데 넣는 이유가 있다.

신입 때 "일단 배포해보고 문제 생기면 고친다" 는 생각을 은근히 했다. 빠르게 치고 나가고 싶은 마음도 있었고, 테스트 짜는 시간이 아깝게 느껴지기도 했다.

근데 운영 서버에서 오류가 나면 디버깅하는 시간이 테스트 코드 짜는 시간보다 훨씬 길다. 특히 다른 사람 코드를 건드린 경우는 더 그렇다.

최소한 서비스 레이어 핵심 로직에는 테스트를 붙이는 게 낫다.

@Test
void 사용자_생성_성공() {
    // given
    UserCreateRequest request = new UserCreateRequest("홍길동", "test@example.com");
 
    // when
    UserResponse response = userService.createUser(request);
 
    // then
    assertThat(response.name()).isEqualTo("홍길동");
    assertThat(response.email()).isEqualTo("test@example.com");
}

given/when/then 구조로 짜면 나중에 읽을 때 뭘 테스트하는지 바로 보인다. 처음엔 어색하지만 한 달만 해보면 없는 게 더 불안해진다.

#마무리

솔직히 위에 적은 것들은 다 "들어봤다"에서 끝나지 않고 직접 겪어야 제대로 느껴진다.

그래도 미리 알고 있으면 최소한 어디서 막혔을 때 "아, 이거 그 얘기구나" 하고 빠르게 연결이 된다. 그게 있는 것과 없는 것의 차이가 꽤 크다.

JPA나 트랜잭션 쪽은 특히 Spring Boot 프로젝트라면 거의 반드시 마주치는 주제니까, 한 번씩 직접 실험해보는 걸 추천한다.

시리즈 목차

• 1편: 개발 환경 준비
• 2편: Spring Boot 프로젝트 생성 & Oracle 연결
• 3편: MyBatis 설정 & CRUD API 만들기
• 4편: React 프로젝트 생성 & Spring Boot API 연동 ← 지금 여기

#React 프로젝트 만들기

터미널을 열고 프로젝트를 만들 상위 폴더로 이동 후 실행합니다.

npm create vite@latest frontend -- --template react
cd frontend
npm install

왜 Vite인가요? 예전엔 create-react-app을 많이 썼는데, 빌드 속도가 너무 느립니다. 요즘은 Vite가 표준입니다. 개발 서버 시작이 1~2초면 됩니다.

#폴더 구조 정리

기본 생성된 파일 중 불필요한 것을 정리합니다.

frontend/
├── src/
│   ├── api/           ← 새로 만들기 (API 호출 모음)
│   ├── components/    ← 새로 만들기 (재사용 컴포넌트)
│   ├── pages/         ← 새로 만들기 (페이지 컴포넌트)
│   ├── App.jsx
│   └── main.jsx
├── index.html
└── package.json

src/App.css, src/assets/react.svg 등 기본 파일은 삭제해도 됩니다.

#axios 설치

API 호출에 axios를 씁니다.

npm install axios

#API 설정 파일 만들기

src/api/api.js 생성:

import axios from 'axios';
 
const api = axios.create({
  baseURL: 'http://localhost:8080/api',
  headers: {
    'Content-Type': 'application/json',
  },
});
 
export default api;

baseURL을 여기서 한 번만 설정하면, 이후에는 /members처럼 경로만 쓸 수 있습니다.

#회원 API 함수 만들기

src/api/memberApi.js 생성:

import api from './api';
 
// 전체 조회
export const getMembers = () => api.get('/members');
 
// 단건 조회
export const getMember = (id) => api.get(`/members/${id}`);
 
// 등록
export const createMember = (data) => api.post('/members', data);
 
// 수정
export const updateMember = (id, data) => api.put(`/members/${id}`, data);
 
// 삭제
export const deleteMember = (id) => api.delete(`/members/${id}`);

#회원 목록 페이지 만들기

src/pages/MemberList.jsx 생성:

import { useEffect, useState } from 'react';
import { getMembers, deleteMember } from '../api/memberApi';
import MemberForm from '../components/MemberForm';
 
export default function MemberList() {
  const [members, setMembers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [showForm, setShowForm] = useState(false);
  const [editTarget, setEditTarget] = useState(null);
 
  // 목록 불러오기
  const fetchMembers = async () => {
    try {
      const res = await getMembers();
      setMembers(res.data);
    } catch (err) {
      console.error('목록 조회 실패:', err);
    } finally {
      setLoading(false);
    }
  };
 
  useEffect(() => {
    fetchMembers();
  }, []);
 
  // 삭제
  const handleDelete = async (id) => {
    if (!window.confirm('정말 삭제하시겠습니까?')) return;
    try {
      await deleteMember(id);
      fetchMembers(); // 목록 새로고침
    } catch (err) {
      alert('삭제 실패');
    }
  };
 
  // 수정 버튼
  const handleEdit = (member) => {
    setEditTarget(member);
    setShowForm(true);
  };
 
  // 폼 닫기
  const handleFormClose = () => {
    setShowForm(false);
    setEditTarget(null);
    fetchMembers();
  };
 
  if (loading) return <p>불러오는 중...</p>;
 
  return (
    <div style={{ padding: '24px', maxWidth: '800px', margin: '0 auto' }}>
      <div style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'center', marginBottom: '16px' }}>
        <h1>회원 목록</h1>
        <button
          onClick={() => setShowForm(true)}
          style={{ padding: '8px 16px', background: '#4a90d9', color: 'white', border: 'none', borderRadius: '6px', cursor: 'pointer' }}
        >
          + 회원 등록
        </button>
      </div>
 
      {showForm && (
        <MemberForm
          editTarget={editTarget}
          onClose={handleFormClose}
        />
      )}
 
      <table style={{ width: '100%', borderCollapse: 'collapse' }}>
        <thead>
          <tr style={{ background: '#f0f0f0' }}>
            <th style={thStyle}>ID</th>
            <th style={thStyle}>이름</th>
            <th style={thStyle}>이메일</th>
            <th style={thStyle}>전화번호</th>
            <th style={thStyle}>등록일</th>
            <th style={thStyle}>관리</th>
          </tr>
        </thead>
        <tbody>
          {members.length === 0 ? (
            <tr>
              <td colSpan={6} style={{ textAlign: 'center', padding: '24px', color: '#888' }}>
                등록된 회원이 없습니다.
              </td>
            </tr>
          ) : (
            members.map((m) => (
              <tr key={m.memberId} style={{ borderBottom: '1px solid #eee' }}>
                <td style={tdStyle}>{m.memberId}</td>
                <td style={tdStyle}>{m.userName}</td>
                <td style={tdStyle}>{m.email}</td>
                <td style={tdStyle}>{m.phone || '-'}</td>
                <td style={tdStyle}>{m.regDate}</td>
                <td style={tdStyle}>
                  <button onClick={() => handleEdit(m)} style={btnStyle('#f0a500')}>수정</button>
                  {' '}
                  <button onClick={() => handleDelete(m.memberId)} style={btnStyle('#e53935')}>삭제</button>
                </td>
              </tr>
            ))
          )}
        </tbody>
      </table>
    </div>
  );
}
 
const thStyle = { padding: '10px 12px', textAlign: 'left', fontWeight: '600' };
const tdStyle = { padding: '10px 12px' };
const btnStyle = (bg) => ({
  padding: '4px 10px', background: bg, color: 'white',
  border: 'none', borderRadius: '4px', cursor: 'pointer', fontSize: '12px',
});