안녕하세요. 코인원 DeFi 탐험 세번째, 이번에는 Yearn Finance를 다뤄보겠습니다.
디파이(DeFi: Decentralized Finance, 탈중앙화 금융) 탐험 시리즈는 매편마다 디파이 서비스를 하나씩 정해 실제로 사용해보면서 하나하나 체험해보는 가이드 컨셉으로 제작되었습니다.

콘텐츠의 특성상 분량이 많아 풀버전을 코인원 기술 블로그에 올려, 더 깊이있게 다뤄보고자 합니다.
코인원은 가상자산 동향 및 디파이 관련 콘텐츠를 코인원 웹사이트 내 코인원 크립토 뉴스에서 꾸준히 다뤄왔으며, 아래 코인원 크립토 뉴스 배너를 클릭해 다른 콘텐츠도 만나보실 수 있습니다.

디파이란 블록체인 위에서 구축된 분산 금융 시스템을 뜻하며, 블록체인 네트워크를 기반으로 운영되는 분산화된 금융 서비스, 기술, 탈중앙화 애플리케이션(DApp) 등 넓은 범위에서 디파이라 불리는 서비스들이 생겨나고 있습니다.
디파이는 스마트 컨트랙트를 기반으로 블록체인 위에 구축되어 있으며, 주로 스마트 컨트랙트를 동작할 수 있는 웹사이트에 지갑을 연결해 스마트 컨트랙트를 실행하는 방식으로 작동합니다.

본 디파이 탐험 콘텐츠는 디파이 서비스를 사용하면서 블록체인에서 실제로 어떤 일이 발생하게 되는가를 한땀한땀 스크린샷을 떠가며 함께 살펴보는 방식으로 구성되어 있습니다.
여러분께서는 본 콘텐츠를 통해 손에 잡히고, 눈에 보이는 블록체인 경험을 간접적으로 해 보실 수 있을 것입니다.

DeFi 탐험 1편에서 다룬 지갑 설정과 트랜잭션 발생과 관련한 상세 설명, 가스에 대한 팁들과 2편에서 다룬 이자농사(Yield Farming)*에 대한 설명은 과감히 생략했습니다.
아래 “준비물”의 “사전 지식”에 해당하는 내용을 이전 편에서 보고 오시면, 본 콘텐츠를 이해하는데 도움이 될 것입니다.

* “Yield Farming”을 DeFi 탐험 2편까지는 ‘일드파밍’으로 표기했지만, 3편부터는 “이자농사”라고 하겠습니다.

DeFi 탐험 계획

세번째 탐험에서 다룰 디파이 서비스는 Yearn Finance(이하 “Yearn”)입니다.
Yearn은 안드레 크론제(Andre Cronje)가 창안한 디파이 프로젝트로, 사용자가 수익을 낼 수 있는 다양한 방법을 제공합니다.
탈중앙화 거래소, 담보대출, 보험, 예금 등 다른 디파이 분야의 프로젝트들을 통합하고 파트너십을 맺으며 영역을 확장하고 있습니다.

* 탐험할 서비스: Yearn Finance (이더리움 블록체인 기반)

* 준비물

• 💻 인터넷이 접속되는 안전한 컴퓨터
• 🌐 크롬 또는 파이어폭스 웹브라우저와 메타마스크 지갑(플러그인)
• 💎 블록체인 전송 수수료로 사용할 소량의 ETH
• 💵 디파이 서비스 입금할 연구 목적의 DAI
• 🧠 사전 지식: DeFi 탐험 1편(Curve)의 DeFi, Metamask, Max slippage, Gas price, Infinite approval, Gas Tracker, TVL, DAO에 대한 내용
  DeFi 탐험 2편(Swerve)의 Yield Farming에 대한 내용

목차

1. DeFi 세상으로 세 발짝
   1.1. 지갑 밖으로 나간 내 자산을 확인하는 방법
   1.2. 지갑의 변화를 푸시받는 방법
2. Yearn이 도대체 뭐길래
   2.1. 시작은 iearn으로부터
   2.2. YFI의 탄생과 역할
   2.3. Yearn으로 모여라
3. Yearn 둘러보기
   3.1. Yield (Vaults, Earn, Zap)
   3.2. Lending
   3.3. Cover
4. Vaults 직접 써보기
   4.1. 지갑 연결
   4.2. Vaults에 DAI 입금하기
   4.3. Vaults에서 DAI 출금하기
5. 마치며

1. DeFi 세상으로 세 발짝

“DeFi 세상으로 n 발짝”은 탐험할 서비스에 들어가기에 앞서 워밍업으로 디파이 관련해 도움될만한 내용을 다루는 코너입니다. 1편의 “DeFi 세상으로 한 발짝”에서는 지갑 설정에 대해 다뤘고, 2편의 “두 발짝”에서는 이자농사(Yield Farming)에 대해 다뤘습니다.
“세 발짝”에서는 DeFi 참여자가 알면 좋을 지갑밖으로 나간 내 자산을 확인하는 방법과 내 지갑의 변화를 푸시받는 방법과 대해 다뤄볼까 합니다.

1.1. 지갑 밖으로 나간 내 자산을 확인하는 방법

일반적인 지갑 서비스나 블록체인 익스플로러에서는 디파이 플랫폼으로 빠져나간 내 자산에 대해 추적이 어려운데, 최근 디파이 자산 뷰어 및 관리 서비스들은 디파이 플랫폼에 예치된 자산, 수령 가능한 자산을 한 곳에 모아 보여줘 편리합니다.
지갑 밖으로 나간 내 자산을 확인하는 몇가지 서비스를 소개해드립니다. 서비스마다 장단점이 있으니, 직접 써보면서 어떤 차이가 있는지 탐험해보시기 바랍니다.

*서비스는 ABC순서입니다.

• DeBank

• Zapper

• Zerion

1.2. 지갑의 변화를 푸시받는 방법

1.2.1. Etherscan TX 메일

이더스캔(https://etherscan.io/)은 지갑의 잔고나 트랜잭션(Transaction, 줄여서 TX) 확인 등에 많이 사용하는데, 회원가입 후 와치리스트(Watch List) 기능으로 TX를 이메일로 푸시받을 수 있습니다.
이 기능을 활용하면, 실시간으로 내 지갑이나 궁금한 지갑의 활동을 감시할 수 있습니다.

이더스캔에 가입 후, 프로필 화면에서 와치리스트를 관리할 수 있습니다.

와치리스트를 추가할 때, 구분하기 쉽게 “Description” 칸에 지갑의 이름을 적으면 됩니다. 필자가 실험해본 바에 따르면 한글로 적으니 이메일에서 글자가 깨지네요. 영문으로 적으시기 바랍니다.

“Please select your notification method below”와 “Other Options”에서는 원하는 방식과 옵션을 선택할 수 있습니다. 필자는 “Notify on Incoming & Outgoing Txns”를 선택하고, “Also Track ERC20 Token Transfers”를 체크했습니다. 이렇게 하면, 해당 지갑으로 들어오고 나가는 모든 TX와 ERC-20 토큰의 이동을 모두 감시할 수 있습니다.

TX 이메일은 [Address Watch Alert] 말머리로 거의 실시간으로 받게됩니다. 스마트폰의 이메일 앱의 푸시를 받게되면, 거의 실시간으로 지갑을 감시할 수 있습니다.

*다만, 해당 서비스 상태, 이메일 앱의 문제, 이더리움 네트워크 상황 등 다양한 변수로 인해 원하는 푸시를 못받게될 수도 있으니, 이 점 참고하시기 바랍니다.

1.2.2. Zerion 앱 푸시

지갑 또는 자산 뷰어 & 관리 앱에 와치리스트로 주소를 등록하면, 푸시를 해주는 앱도 있습니다.
앞서 소개드린 Zerion도 트랜잭션을 앱 푸시로 보내줘서, 편하게 푸시 내역을 확인할 수 있습니다. 꼭 지갑을 연결할 필요 없이 와치리스트로 주소만 등록해도 푸시를 받을 수 있습니다.

2. Yearn이 도대체 뭐길래

Yearn에 대해 얘기하면, 많은 분들이 “Yearn이 도대체 뭐길래, YFI가 그렇게 비싼가?” 이런 궁금증을 많이 품고 있을 것 같습니다.
이런 궁금증의 해결을 위해 Yearn의 시작과 YFI가 어떻게 생겨났는지, YFI의 역할은 뭐고, 현재 Yearn이 어떤 디파이 생태계에서 일을 벌이고 있는지 가볍게 살펴보겠습니다.

2.1. 시작은 iearn으로부터

Yearn의 시작은 iearn이었습니다. 공식 트위터, 깃허브, 미디엄 등 계정 아이디를 살펴 iearn인 것을 발견할 수 있습니다.
YFI 토큰이 나오기 이전인 2020년 상반기에는 토큰 없이 제품만 있었던 시기가 있었습니다.
당시 URL은 iearn.finance 이었고, 토큰을 예치하면 이자를 벌어주는 아주 심플한 서비스였습니다.

잠시 과거로 돌아가볼까요?

위 스크린샷은 2020년 2월쯤 찍었습니다. “Earn interset. Simple.” 정말 심플하죠?

지갑을 연결하면, 이렇게 입금 할 수 있는 잔고가 떴습니다. 이 목록은 현재는 v1으로 Yearn의 “earn” 메뉴에 남아있습니다.
저 earn에 토큰을 예치하면, y*** 토큰 — 예를 들어 “yDAI”라는 “DAI를 찾을 수 있는 권리”에 해당하는 토큰을 받게되고, 추후 이자와 함께 원금을 회수하거나, 이 토큰을 다시 커브(Curve) 등에 유동성을 제공하는 식으로 재투자할 수 있었습니다. 이 방식은 현재에도 통용되는 방식이기도 합니다. (해당 풀이 커브의 y 풀입니다.)

너무 옛날 이야기같네요. 아무튼 Yearn은 이렇게 시작했습니다.

이후 2020년 하반기에 iearn은 yearn으로 리브랜딩 되었으며, YFI라는 거버넌스 토큰이 출시되고, 다양한 디파이 프로젝트와 파트너십을 맺으며 생태계를 확장하고 있습니다.

*여담으로 필자는 iearn이 어떻게 yearn이 되었는지 커뮤니티에서 역사를 수집하였습니다. 초기 iearn이었을 때, yearn의 창시자 안드레 크론제(Andre Cronje)는 iearn — I Earn을 원했지만, yearn의 코어 개발자 banteg가 yearn — You Earn을 원했고, 그들은 죽음에 맞서 싸웠고 마침내 banteg가 이겨서 yearn이 되었다고 합니다.

2.2. YFI의 탄생과 역할

YFI 토큰은 Yearn의 거버넌스 토큰입니다. 수량이 매우 적은 편이라, 현재 가격으로만 보면 비트코인과 비슷할만큼 높은 가격이 형성되어 있습니다.
YFI 토큰의 탄생 과정과 역할을 살펴보며, 이 토큰이 왜 디파이 분야에서 이토록 유명세를 탔는지 알아보겠습니다.

• YFI 소개 — https://docs.yearn.finance/yfi-and-ytokens

2.2.1. YFI 토큰의 탄생 과정

작년 여름, 디파이 대출 플랫폼 컴파운드(Compound)가 거버넌스 토큰인 COMP 토큰을 공개했습니다. 컴파운드 프로토콜 내에서 공급과 대출을 하면 COMP 토큰을 받을 수 있어, 디파이 참여자들은 본인이 보유한 토큰을 공급하고, 빌리면서 이자보다 높은 COMP 토큰을 받아갔습니다. 유동성 채굴(Liquidity Mining) — 이자농사(Yield Farming)라는 용어가 이때쯤 생겨났습니다.

COMP가 공개되고 약 한달 후, Yearn의 창시자 안드레 크론제(Andre Cronje)는 개인 블로그를 통해 최적화된 이자농사(Yield Farming)를 만들겠다 발표했고, YFI를 순차적으로 채굴할 수 있는 1, 2, 3번 풀(Pool)을 공개했습니다.(참고: https://medium.com/iearn/pool-3-meta-yield-governance-58f68e6d2f19) 디파이 참여자들은 이 때부터 마치 게임처럼 공개된 규칙에 따라 본인이 보유한 자산을 가지고 1, 2, 3번 풀에서 YFI를 채굴하기 시작합니다. 단계적인 채굴 과정을 통해 당시 디파이 참여자들이 블록체인 위에서 다양한 체험을 하게 되었고, Curve의 풀, AMM(Automated Market Maker) 등을 이해하는 계기가 되었습니다.*

*필자의 개인적인 견해가 포함되어 있습니다.

YFI 토큰의 가치는 무(無)에서 시작해 참여자가 늘어나고 알려지면서 점점 올라갔고, APY(년수익률)는 몇 천%까지 올라갔습니다. 여기에다 제한적인 수량 — 총 공급량 3만개 발행 이후 더 발행하지 않기로 결정되면서, 가격은 9월 중순에 당시 믿기 어려울만큼 높은 가격이 형성되기도 했습니다.

이후 YFI 이름을 딴 수많은 이자농사 토큰들이 생겨났고, 농작물과 과일, 음식 이모지를 단 다양한 토큰들이 이자농사 방식으로 생겨났습니다. 그야말로 이자농사의 대유행이 시작되었고, 이로 인해 이더리움 가스값이 예전 ICO 대유행 당시 수준으로 올라가기도 했습니다.

이렇게 YFI 토큰은 이자농사 대유행을 이끈 장본인이자, 초기 투자자 없이 정해진 규칙과 커뮤니티의 참여에 의해서만 가치가 형성된 DAO(Decentralized autonomous organization) 거버넌스 토큰으로 빠르게 성장해 오늘날에 이르렀습니다.

2.2.2. YFI 토큰의 역할

YFI 토큰은 거버넌스 토큰으로 Yearn Finance의 중요 의사결정에 대한 투표 권리로 쓰입니다.
거버넌스 포럼에 YIP(Yearn Improvement Proposal)라는 제안이 올라오고, 이후 거버넌스 사이트에서 온체인 투표 또는 스냅샷 투표를 통해 YFI 토큰 보유자는 YIP에 대해 의사결정을 할 수 있습니다.

• Yearn 거버넌스 포럼

• Yearn 거버넌스 스냅샷

• Yearn 거버넌스 웹사이트(스테이킹, 온체인 투표)

2.3. Yearn으로 모여라

Yearn Finance는 다양한 디파이 프로젝트를 통합하고, 파트너십을 맺으며 생태계를 확장하고 있습니다.
앞으로 본격적으로 다뤄야볼 내용이 너무 많다보니 자세한 설명보다는 참고할 수 있는 링크를 공유해 지면을 아끼도록 하겠습니다.

• Yearn Finance 공식 블로그 — https://medium.com/iearn
• Yearn Partner Roundup 뉴스레터 블로그 — https://medium.com/yearn-partner-roundup
• Yearn Community Aggregator 웹사이트 — https://ycosystem.info/

3. Yearn 둘러보기

Yearn을 전반적으로 간단히 둘러보겠습니다.
본 콘텐츠를 작성하는 동안 Yearn의 웹사이트가 v2로 업데이트 되었습니다.(참고: YFI Pulse 1.17 — Yearn Redesign)
다만, 일부 기능은 Yearn v2에서 없어, v1으로만 보여드리려고 합니다.

• yearn.finance — Yearn v2

• v1.yearn.finance — Yearn v1

3.1. Yield

자산으로 수익을 낼 수 있는 기능들을 제공합니다.
일부 기능(Earn)은 현재 v1에서만 접근 가능합니다.

3.1.1. Vaults

볼트(Vaults)는 직역하자면 ‘금고’입니다. 다양한 디파이 서비스에서 ‘볼트’는 자금을 이체받아 스마트 컨트랙트로 짜여진 전략으로 자산을 불려주는 예치 서비스 정도로 이해하시면 되겠습니다.
Yearn의 볼트는 줄여서 yVaults라고도 부릅니다. 최근 Yearn이 v2로 업데이트되면서, Vaults v2를 출시했습니다.

3.1.1.1. Vaults 전략

사용자가 볼트에 자산을 입금하면, 해당 볼트의 컨트랙트 주소에 자산이 모이게 되며, 스마트 컨트랙트로 짜여진 전략에 따라 자동으로 운용됩니다.
Vaults 전략에 따라 저장소에 모인 자산이 어떻게 운용될지 — 빌리고 갚을지, 이자농사를 어디서 지을지, 어디서 자산을 판매하고 되살지 등 — 결정되며, feel-the-Yearn(https://feel-the-yearn.vercel.app/)에서 현재 구현된 전략을 확인할 수 있습니다.

• feel-the-Yearn

• 전략 스마트 컨트랙트 예시

Vaults 전략은 커뮤니티 참여자 누구나 포럼에 게시할 수 있으며, 구매 / 판매 / 이자농사와 현재 APY 등을 자세하게 공유해야합니다.

포럼에 올라온 전략이 Yearn Vaults로 제품에 올라갈만한 가치가 있는지는 Yearn의 거버넌스 토큰 — YFI 를 보유한 유권자들이 거버넌스 투표를 통해 서비스에 출시할지를 결정하고, YFI 유권자들의 결정에 따라 다중 서명(multi-sig)지갑을 소유한 구성원이 지갑으로 서명해 서비스에 구현하게 됩니다.
다중 서명 구성원은 YFI 보유자의 투표로 정해졌으며, 향후 거버넌스 투표로 변경될 수 있습니다. 멀티시그 서명자의 구성은 FAQ — The list of the multisig signers에서 확인할 수 있습니다.

Vaults에 전략이 구현되면 전략의 작성자가 일정 부분 대가를 받게됩니다. 이러한 과정을 통해 커뮤니티에서 더 높고 안정적인 수익을 내는 전략을 만들도록 동기부여하고, 선순환이 이루어 집니다.

3.1.1.2. Vaults — Production

Vaults는 Yearn v2부터 Production과 Experimental로 나누어졌습니다.
일반 사용자는 제품으로 안정적인 상태인 Production에 자산을 예치해 수익을 낼 수 있으며, 조금 더 실험적인 참여자는 Experimental을 살펴보고 실험에 참여할 수 있습니다.

3.1.1.3. Vaults — Experimental

아직 제품(Production)이 아닌 실험적인(Experimental) 볼트를 확인하고, 사용해볼 수 있습니다.
실험적인 볼트인 만큼, 아직 확인되지 않은 리스크가 있을 수 있습니다.

3.1.2. Earn

언(Earn)은 Yearn 초기부터 있었던 기능으로 탈중앙화 거래소에 유동성을 공급하고, 수수료를 얻는 방식의 자산 예치 풀(Pool)입니다. 현재 v2 웹사이트 “YIELD → Earn”을 클릭하면, v1 웹사이트의 “Earn”으로 이동합니다.
언(Earn)에 특정 자산을 예치하면 y로 시작하는 토큰을 받습니다.(예를 들어 DAI를 예치해 yDAI를 받음) y토큰은 정해진 풀(pool) 안에 보관됩니다. 아래 스크린샷의 토큰 목록 상단에 v1, y.curve.fi, busd.curve.fi 탭을 볼 수 있는데, 여기 선택된 곳이 자산이 예치될 풀입니다.
풀에 보관된 자산은 해당 풀과 연계된 탈중앙화 거래소를 통해 이용자가 풀의 토큰간 교환을 하게되면(예를들어 DAI를 USDT로 교환), 소정의 수수료가 쌓이게 됩니다. 이 수수료로 풀의 자산이 늘어나는 방식으로 언(Earn) 이용자가 돈을 벌 수 있습니다.

• Earn — Yearn v1

3.1.3. Zap

잽(Zap) — 은 강하고 빠르게 가격하는(?) 느낌의 단어죠. 디파이에서 잽은 보통 “사용자가 원하는 복잡한 트랜잭션을 쉽고 빠르게 한 번에 해결해주는 방법” 정도로 많이 쓰입니다.
Yearn에서는 보유중인 토큰을 커브 LP에 넣는다거나, 커브 LP의 토큰을 원하는 토큰으로 출금하는 기능을 수행할 수 있습니다.

현재 잽 기능은 v1에서만 지원하며, v1 웹사이트 “yield → zap”으로 접근할 수 있습니다.

• Zap — Yearn v1

3.2. Lending

렌딩(Lending)은 크림 파이낸스(C.R.E.A.M. Finance)와 파트너십 이후 생긴 기능으로 담보대출 기능입니다.

현재 렌딩 기능은 v1에서만 지원하며, v1 웹사이트 “lending”으로 접근할 수 있습니다.

• Lending — Yearn v1

3.3. Cover

커버(Cover)는 커버 프로토콜(Cover Protocol) 합병 이후 제공되는 보험 기능입니다.

• Cover — Yearn v2

*Yearn은 생태계를 확장하고 있고, v1에서 v2로 전환하는 과정에 있어, 계속 기능과 화면이 변경될 수 있습니다.
이 점 유의하시고, 대략 위와 같은 다양한 기능을 제공한다 정도로 참고해주시면 되겠습니다.

4. Vaults 직접 써보기

계속해서 본 콘텐츠를 통해 디파이 서비스를 원활하게 탐험하려면, 아래 내용을 꼭 확인하는게 좋습니다.

• DeFi 탐험 1편의 “메타마스크 지갑 설정”
• 이전 편에서 이미 다뤘던 지갑 연결, 트랜잭션 수수료 설정, Approve 등에 대한 내용은 깊게 다루지 않겠습니다.

이전 편과 마찬가지로 3,000 DAI와 수수료로 사용할 1 ETH를 준비했습니다.

4.1. 지갑 연결

Yearn 웹사이트(https://yearn.finance) 접속 후, 우측 상단의 “CONNECT WALLET” 버튼을 클릭해 지갑을 연결합니다.

4.2. Vaults에 DAI 입금하기

상단 메뉴의 “YIELD → Vaults”로 이동합니다.
DAI v2 볼트에 준비한 3,000 DAI가 보이네요.

3,000 DAI를 모두 DAI v2 볼트에 입금해보겠습니다. 수익률(GROWTH)을 확인하고, 수량을 입력하고 “Deposit” 버튼을 클릭합니다.
*GROWTH로 표시된 수익률(스크린샷의 17.89%)은 변동될 수 있습니다.

DeFi 탐험 이전 편을 보고 오셨다면, 이쯤에서 어떤 트랜잭션이 발생하는지 눈치채셨죠?
Yearn에서 DAI 토큰 취급을 허용할지 “Approve” 트랜잭션, 이후 실제 전송에 해당하는 “Deposit” 트랜잭션이 발생합니다.

트랜잭션이 컨펌나면, DAI가 볼트로 전송되고, yDAI 토큰이 지갑으로 들어옵니다. yDAI 토큰은 Yearn에서 DAI를 되찾을 때 증표 역할을 합니다.

Approve와 Deposit 트랜잭션도 살펴보겠습니다.

3,000 DAI는 DAI Vaults v2 컨트랙트로 전송되었고, yDAI 토큰이 0x000…000 주소에서 생성되어 지갑에 들어온 것을 블록체인 위에서 확인할 수 있습니다.

• 기다림의 시간

이제 이자가 발생하는 동안 기다립니다. 이더리움 트랜잭션 수수료를 고려해 얼마나 기다려야 손해가 아닌지 판단해 기다림의 시간을 결정합니다.

4.3. Vaults에서 DAI 출금하기

이번 콘텐츠에서는 출금까지 완전히 보여드리기는 어려움이 있을 것 같습니다.
최근 이더리움 수수료가 매우 높아져서, 현재 예치된 3,000 DAI를 수익 상태로 출금하려면 오랜 시간이 걸리기 때문입니다.
따라서, 스크린샷으로 출금 방법만 간단히 알려드리겠습니다.

출금은 입금한 같은 볼트에서 Withdraw 버튼 옆에 출금할 수량을 입력하고, “Withdraw”을 클릭합니다.

*아래 스크린샷에는 입금 수량인 3,000 DAI가 그대로 적혀있지만, 시간이 흘러 이자가 쌓였다면 이자가 포함된 숫자가 “Vault balance”에 표시될 것입니다.

출금시 아래와 같이 “Withdraw” 트랜잭션을 컨펌하면, 지갑에 있던 yDAI가 소각되고, DAI가 이자와 함께 지갑으로 돌아옵니다.

위 이미지는 예시로 보여드리는 트랜잭션 화면입니다. 지갑에 보유중인 yDAI가 0x000…000 주소로 전송되며 소각되며,
지갑으로 이자와 원금 DAI 가 돌아오게 됩니다.

5. 마치며

DeFi 탐험 3편을 작업하면서 이번에는 수익을 내는 모습을 보여드리고 싶었지만, 현실적으로 3,000 DAI로는 수익을 내는 주기가 너무 길어져 출금 및 정산 과정은 생략했습니다.
현재 이더리움 수수료를 고려했을 때, 수수료와 수익의 손익분기를 넘기는데 까지 많은 시간이 소요되어 아쉽게 되었습니다.

다소 부족했지만, Yearn이 어떤 DeFi인지 알아가는 시간이 되었으면 합니다.

감사합니다.

*코인원 크립토 뉴스(https://coinone.co.kr/talk/)에서 코인원의 업계 뉴스부터 전문가의 트레이딩 분석, 디파이 관련 리서치까지 다양하게 만나보실 수 있습니다.

DeFi 탐험 유의사항

• 본 게시물은 DeFi의 다양한 서비스를 소개하는 취지에서 작성되었습니다.
• 본 게시물에 수록된 내용은 자료 작성자가 신뢰할 수 있는 자료 및 정보로부터 얻은 것이나 오차가 발생할 수 있으며, 당사는 어떠한 경우에도 정확성이나 완벽성을 보장하지 않습니다.
• 본 게시물에 나타난 모든 의견은 자료 작성자의 개인적인 견해로, 외부의 부당한 압력이나 간섭 없이 작성되었습니다.
• 본 게시물은 투자를 유도하거나 권장할 목적이 아닙니다.
• 본 게시물의 내용은 원본 손실의 가능성이 존재하며, 게시물에 표시된 수익률은 변동성이 있으며 당사는 이를 보장하지 않습니다.
• 본 게시물의 이미지에 표시된 스크린샷 화면은 실제 웹사이트 화면과 언제든지 일부 또는 전체가 변경될 수 있으며 당사는 이를 보장하지 않습니다.
• 본 게시물에 따라 투자를 진행하더라도 사용자의 사용 미숙, 실수, 복구키 유실 등 여러가지 이유로 자금의 원본을 전부 손실할 가능성이 있습니다.
• 본 게시물은 어떠한 경우에도 고객의 투자 결과에 대한 법적 책임 소재의 증빙 자료로 사용될 수 없습니다.
• 본 게시물의 저작권은 코인원에 있고, 어떠한 경우에도 코인원의 허락없이 복제, 대여, 재배포될 수 없습니다.
• 당사는 본 게시물의 해당 DeFi 서비스와 아무 관련이 없습니다.
• 당사는 본 게시물의 내용에 의거하여 행해진 일체의 투자 행위에 대하여 어떠한 책임도 지지 않습니다.

[DeFi 탐험 #3] Yearn Finance was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요. 코인원 DeFi 탐험 두번째, 이번에는 Swerve Finance(이하 “스워브”)를 다뤄보겠습니다.
디파이(DeFi: Decentralized Finance, 탈중앙화 금융) 탐험 시리즈는 매편마다 디파이 서비스를 하나씩 정해 실제로 사용해보면서 하나하나 체험해보는 가이드 컨셉으로 제작되었습니다.

콘텐츠의 특성상 분량이 많아 풀버전을 코인원 기술 블로그에 올려, 더 깊이있게 다뤄보고자 합니다.
코인원은 가상자산 동향 및 디파이 관련 콘텐츠를 코인원 웹사이트 내 코인원 크립토 뉴스에서 꾸준히 다뤄왔으며, 아래 코인원 크립토 뉴스 배너를 클릭해 다른 콘텐츠도 만나보실 수 있습니다.

디파이란 블록체인 위에서 구축된 분산 금융 시스템을 뜻하며, 블록체인 네트워크를 기반으로 운영되는 분산화된 금융 서비스, 기술, 탈중앙화 애플리케이션(DApp) 등 넓은 범위에서 디파이라 불리는 서비스들이 생겨나고 있습니다.
디파이는 스마트 컨트랙트를 기반으로 블록체인 위에 구축되어 있으며, 스마트 컨트랙트를 동작할 수 있는 웹사이트에 지갑을 연결해 스마트 컨트랙트를 실행하는 방식으로 작동합니다.

본 디파이 탐험 콘텐츠는 디파이 서비스를 사용하면서 블록체인에서 실제로 어떤 일이 발생하게 되는가를 한땀한땀 스크린샷을 떠가며 함께 살펴보는 방식으로 구성되어 있습니다.
여러분께서는 본 콘텐츠를 통해 손에 잡히고, 눈에 보이는 블록체인 경험을 간접적으로 해 보실 수 있을 것입니다.

DeFi 탐험 1편에서 다룬 지갑 설정과 트랜잭션 발생과 관련한 상세 설명, 가스에 대한 팁들은 생략했습니다.
1편을 아직 보지 않았다면, 보고 오시면 본 콘텐츠를 보는데 도움이 될 것입니다.

DeFi 탐험 계획

두번째 탐험에서 다룰 디파이 서비스는 스워브입니다.
스워브는 “100% 커뮤니티가 소유하고 관리하는 포크”(A fork that’s 100% community owned and governed.)라는 취지로 커브(Curve)를 포크해 만들어진 디파이 프로젝트입니다.

탐험할 서비스: Swerve Finance (이더리움 블록체인 기반)

준비물
💻 인터넷이 접속되는 안전한 컴퓨터
🌐 크롬 또는 파이어폭스 웹브라우저와 메타마스크 지갑(플러그인)
💎 블록체인 전송 수수료로 사용할 소량의 ETH
💵 디파이 서비스 입금할 연구 목적의 DAI
🧠 사전 지식: DeFi 탐험 1편(Curve)의 DeFi, Metamask, Max slippage, Gas price, Infinite approval, Gas Tracker, TVL, DAO에 대한 내용

목차

1. DeFi 세상으로 두 발짝
   1.1. Yield Farming
2. Swerve 둘러보기
   2.1. swerve.fi
   2.2. SWRV
   2.3. SWERVE APP
   2.4. POOLS
   2.5. SWUSD(Pool)
   2.6. DAO
   2.7. Risks
3. Swerve를 써보자
   3.1. 지갑 연결
   3.2. Pool Deposit
   3.3. Gauge Deposit
   3.4. 기다림의 시간
4. 정리: Gauge Withdraw, SWRV Claim, Pool Withdraw
   4.1. Gauge Withdraw
   4.2. SWRV Claim
   4.3. Pool Withdraw
   4.4. 최종 잔고 비교

1. DeFi 세상으로 두 발짝

전편의 “DeFi 세상으로 한 발짝”에서는 지갑 설정에 대해 다뤘는데, 이번에는 이 부분을 과감하게 생략하겠습니다. 지갑 설정을 해본적없이 본 콘텐츠를 처음 접한다면, 1편을 보시기를 권장드립니다. “DeFi 세상으로 n 발짝”은 탐험할 서비스에 들어가기에 앞서 워밍업으로 디파이 관련해 도움될만한 내용을 다뤄볼까 합니다. 이번에 다뤄볼 내용은, 일드파밍이라는 용어와 일드파밍 관련 랭킹 사이트입니다.

1.1. Yield Farming

코인원 크립토 뉴스나 코인니스 등 크립토 분야 소식을 접해왔다면, “이자농사”(Yield Farming)이라는 말을 많이 들어보셨을 겁니다. 한글로 발음대로 읽어서 “일드파밍”이라고도 부르는데요. 본 콘텐츠에서는 영어발음 그대로 “일드파밍”으로 부르겠습니다.

코인원 x 엘립티 DeFi 파헤치기 “디파이 이자농사”편(https://coinone.co.kr/talk/clip/detail/906)에서 일드파밍에 대해 구체적으로 다루니 참고하셔도 좋을 것 같습니다.

엄밀히 말하자면, 일드파밍은 농사나 수확과는 거리가 있습니다. 비유적인 표현일 뿐이죠. 일드파밍을 정확히 풀어 써보면, 스마트 컨트랙트로 내 자산을 묶어 활용하게 해주는 대신 그 대가로 (이자에 상응하는) 디파이 토큰을 시간이 지남에 따라(더 정확히는 매 블록마다) 할당받고, 할당 받은 디파이 토큰을 ‘Mint’ 해서 얻는 것을 의미합니다. 내 자산을 묶어두어 활용하게 해주는 것이 해당 디파이 생태계에 기여한다는 취지에서 디파이 토큰을 보상으로 주는 것으로 이해하면 됩니다. 이렇게 정확하게 표현하는게 어려우니, 일드파밍이라는 쉬운 단어가 널리 쓰이고 있습니다.

1.1.1. Yield Farming 랭킹 사이트

일드파밍도 시가총액 랭킹처럼 랭킹 사이트가 존재하며, 이 랭킹 사이트에서 디파이 서비스들의 풀(Pool)별 수익률과 기타 사항들을 참고해 일드파밍 참여를 고려해볼 수 있습니다.
대표적인 일드파밍 랭킹 사이트를 두 가지 소개합니다.

*아래 소개드리는 사이트에 표시된 이율은 장래 변동할 수 있습니다.

• CoinGecko: Farms

코인게코(CoinGecko)의 게코는 우리말로 도마뱀붙이로, 코인게코는 웹사이트 곳곳에서 도마뱀을 발견할 수 있습니다.
코인게코의 메뉴에서 “Farms”로 들어가면, 디파이 일드파밍 풀(Pool) 목록이 개별 풀당 Value Locked 기준으로 나열됩니다.

코인게코 Farms의 특징은 디파이 서비스별로 묶어서 보여주는게 아니라 개별 풀을 기준으로 보여주다보니, 풀이 다양해서 Value Locked가 높은 서비스와 풀의 개수는 적지만 개별 풀의 자산이 많은 서비스가 공평하게 랭킹 경쟁을 한다는 점입니다. 단일 풀임에도 돈이 많이 모인 곳을 찾아낼 수 있죠.

또, “Degen” 모드를 켜면… 1000%가 넘는 풀만 표시됩니다. (하이리스크 하이리턴이니, 이런 모드는 주의하시기 바랍니다.)

• CoinMarketCap: Yield Farming

코인마켓캡(https://coinmarketcap.com/)은 너무 유명해서 많이 알고계실텐데, 디파이이가 한창 주목받을 때 코인마켓캡에서도 일드파밍 랭킹을 다루는 페이지가 생겼습니다.

코인마켓캡 일드파밍은 코인게코와 다르게 서비스 전체의 Total Value Locked, TVL을 기준으로 랭킹을 표시합니다.
상대적으로 풀이 적은 서비스는 불리할 수 있으며, 다양한 자산을 다루는 서비스일수록 더 유리할 수 있습니다.

서비스 명 아래에 표시된 “Based on Ethereum”에서 짐작할 수 있듯, 다양한 체인의 서비스를 다룹니다.
현재 이더리움, 트론, BSC 기반 디파이 서비스가 랭킹에 표시됩니다.

또, 눈여겨 봐주셨으면 부분은 “Impermanent Loss”입니다. 약자로 “IL”이라고 하며, “비영구적 손실”로 해석할 수 있습니다.
비영구적 손실에 대해서는 본 콘텐츠에서 자세하게 다루기에는 다소 어려운 부분이 있습니다. 요약하여 설명하자면, 비영구적인 손실은 거래 쌍의 가격 변동성으로 인해 풀에 유동성을 공급하는 참여자가 마주할 수 있는 손실을 의미합니다.

코인마켓캡에서는 IL을 “High”, “Medium”, “Low”, “None” 등 여러 단계로 나눠 표시하고 있습니다.

• High, Medium: 다른 종류의 가상자산으로 묶인 LP
• Low: 같은 종류의 가상자산으로 묶인 LP (예: 스테이블-다른 스테이블, 랩드BTC-다른 랩드BTC)
• None: 단일 자산 LP

1.1.2. Swerve의 발견

본 콘텐츠에서 다뤄볼 스워브(Swerve)는 작성일(2020년 11월 10일) 기준 코인마캣켑: 일드파밍에 11위로 랭크되어 있지만, 본 콘텐츠의 기획과 순서를 확정짓던 시기에는 Swerve가 커브에서 갓 포크되어 나온 시기로, Uniswap에서 UNI를 출시하기 전 시기여서, 커브를 재치고 1위를 하고 있었습니다.

필자는 코인마캣캡: 일드파밍의 랭킹을 보다가 1위에 랭크된 Swerve를 발견하였고, 이 서비스를 처음 둘러보게 되었고, 커브의 포크라는 점에서 앞서 1편에서 다룬 커브와 많은 유사점이 있었고, 빠른 시간에 상당히 많은 자금이 모였다는 점을 고려해 두번째 콘텐츠 소재로 삼게 되었습니다.

일드파밍 랭킹 사이트에서 디파이 서비스를 발견하는 방법은 비교적 쉽게 돈이 어디로 몰리는지, 어떤 디파이 서비스가 인기가 있는지 동향을 파악할 수 있습니다. 물론, 더 다양한 방법으로 새로운 서비스들을 발굴해낼 수도 있겠지만, 현실적으로 그러기에는 많은 시간과 노력이 필요합니다.

계속해서 본 콘텐츠를 통해 디파이 서비스를 원활하게 탐험하려면, 아래 내용을 꼭 확인하는게 좋습니다.

• 커브 1편의 “메타마스크 지갑 설정”

2. Swerve 둘러보기

2.1. swerve.fi

스워브 웹사이트에 접속하면, 간략한 소개와 “SWERVE APP”으로 이동하는 버튼과 몇개의 링크가 있습니다.
서비스 이름 바로 아래 줄의 문구가 눈에 들어 오는데요. “A fork that’s 100% community owned and governed.” 이 문구에는 스워브 출생의 비밀이 숨겨져 있습니다.

“A fork that’s 100% community owned and governed.”
“100% 커뮤니티가 소유하고 관리하는 (Curve의) 포크입니다.”

2.1.1. Why We Built Swerve

별로 링크처럼 보이지 않는 “Why We Built Swerve”는 사실 https://swerve.fi/swerve/ 페이지로 이동하는 링크이며, 그 페이지 안에 “A fork that’s 100% community owned and governed.” 문구에 대한 상세한 내용이 기술되어 있습니다.

글의 앞 문단에서 스워브는 커뮤니티가 100% 소유한 커브(Curve)의 포크를 출시했다고하며, 이름을 스워브(Swerve)로 지었다고 합니다.
스워브의 사전적인 의미까지 친절하게 외부 링크(Urban Dictionary)를 달아놔 왜 스워브로 작명했나 알아보려고 했으나, 안타깝게도 TOP 정의에 욕설이 난무하여 심의상 그대로 옮겨오기를 포기하고, 사전적인 의미인 “방향을 휙 틀다”, “바른 길에서 벗어나다”, “빗나가게 하다” 정도의 뜻만 가져와봅니다. “방향을 틀다”라는 뜻의 “커브” 포크로 적절한 이름같죠?

둘째 문단부터는, 포크한 프로젝트에 대한 비판과 토큰 분배 수량과 기간 등이 적혀있고, 맨 마지막 문단에서는 스워브의 목표에 대해 적혀있습니다.
스워브의 목표는 인센티브가 고갈 된 후에도 살아남는 커뮤니티를 구축하는 것이라고 하네요.

자세한 내용은 본 콘텐츠에서 다루기에는 어려움이 있어 링크에서 직접 살펴보시기 바랍니다.

2.1.2. Swerve App: 특이한 URL

“SWERVE APP” 버튼을 클릭하면, 복잡한 문자열과 ~.ipfs.dweb.link로 끝나는 특이한 주소로 넘어갑니다.
버튼 아래로 Backup IPFS Gateway, via ENS Link, via swere.fi, via MetaMask 모두 다른 링크로 접속합니다. 웹을 분산화했다고 볼 수 있겠습니다.
탈중앙화에 대한 고민을 대문에서부터 해놓은게 스워브의 독특한 특징입니다.

“Swerve is proudly hosted on IPFS, the peer to peer distributed web.”
“Swerve는 P2P 분산 웹인 IPFS에서 자랑스럽게 호스팅됩니다.”

• IPFS: InterPlanetary File System의 약자로 기존 웹의 중앙화 문제에 대한 해결책으로 제시된 분산형 파일 시스템입니다.
• ENS Link: 이더리움 네임 서비스(Etheream Name Service, 약자 ENS) 링크입니다. 웹사이트를 IPFS에 업로드하고 ENS로 도메인을 만들어 연결하면, 탈중앙화된 웹사이트를 구축할 수 있습니다.

2.2. SWRV

SWRV는 Swerve DAO Token으로 스워브에서 통용되는 거버넌스 토큰입니다.
이 토큰은 스워브 서비스 전반에서 다양한 역할을 하며, 참여자에게는 보상으로 주어지며, 보유자에게는 거버넌스에 영향을 미칠 수 있는 권한을 부여합니다.

2.3. SWERVE APP

스워브는 커브의 포크라 그런지, UI에서 커브와 거의 모든면에서 동일합니다.

스워브 앱에 접속하면, “POOLS” 메뉴가 표시됩니다.
(커브와 마찬가지로) 스워브의 핵심 기능인 거래 기능을 첫 화면에 보여주는 것인데, 그 아래로 스워브 풀의 목록, TVL, 일간 거래량 등 현황이 표시됩니다.

“SWERVE APP”의 GNB(Global Navigation Bar) 메뉴는 아래와 같으며, 순서대로 간단히 살펴보겠습니다.

• (햄버거 메뉴): 지갑변경, (지갑에서)로그아웃
• POOLS: 스워브 전체 풀을 활용한 스왑 거래, 풀 목록, TVL, 일간 거래량 현황
• DAO: 스워브의 DAO로 이동
• SWUSD: swUSD풀(Pool)로 이동
• RISKS: 스워브 주의사항, 위험 고지
• ?: 컨트랙트 주소, 유니스왑 링크, 깃허브(Github) 링크

2.4. POOLS

현재까지는 Pools에 하나의 풀만 존재합니다.

각 풀(Pool)은 풀에 들어온 여러 자산간 스왑을 지원하여 탈중앙화된 교환소 역할을 수행합니다.

• [DAI, USDC, USDT, TUSD]: 풀에서 입출금, 스왑을 지원하는 가상자산의 종류입니다.
• POOL APY: 풀의 거래 수수료로 발생하는 예상 년간 수익률입니다.
• SWRV APY: 풀에 자산을 예치하고 받은 LP 토큰을 DAO에 스테이킹해서 얻게되는 SWRV 토큰의 현재가 기준 예상 년간 수익률입니다.

2.5. SWUSD(Pool)

“POOLS”메뉴의 “SWERVE POOLS” 목록에서 “[DAI, USDC, USDT, TUSD]”풀을 선택하거나, 메뉴의 SWUSD를 클릭하면, SWUSD 풀에 들어올 수 있습니다.
개별 풀에 들어오면, GNB의 메뉴가 아래와 같이 바뀝니다.

• [swUSD]: 현재 풀의 이름(현재는 풀이 1개 뿐이지만, 추후 풀이 추가되면 풀을 변경할 수 있을듯)
• POOLS: 스워브 풀 목록으로 돌아감(SWERVE APP 첫 화면)
• DAO: 스워브 DAO로 이동
• BUY AND SELL: 풀 안에서 자산간 스왑 거래
• DEPOSIT: 풀에 자산을 예치
• WITHDRAW: 풀에서 자산을 출금
• ?: 컨트랙트 주소, 유니스왑 링크, 깃허브(Github) 링크

2.5.1. BUY AND SELL

개별 풀의 첫 화면은 “BUY AND SELL”이며, 풀에서 지원하는 자산간 거래를 할 수 있습니다. 거래는 블록체인상에 트랜잭션을 발생시키면서 진행됩니다.
하단의 리저브에서 풀의 자산별 잔고와 비중이 표시되며, 자신이 보유한 swUSD 유동성 풀 토큰(LP 토큰)에 해당하는 자산별 수량, 풀에서 차지하는 비중을 확인할 수 있습니다.

2.5.2. DEPOSIT

풀에서 지원하는 자산을 풀에 예치할 수 있습니다. 예치방식은 커브와 동일하게 풀에서 지원하는 토큰을 입금할 수 있는데, 입금이 되면 위 스크린샷의 아래 박스 “CURRENCY RESERVES”에 자산이 예치되고, 해당 풀에 대한 지분을 증명하는 LP 토큰을 받게됩니다.

2.5.3. Withdraw

풀에 예치한 자산을 출금할 수 있습니다. 다만, “WITHDRAW % IN”의 기본 설정이 “COMBINATION OF ALL COINS”이므로 위 스크린샷의 아래 박스 “CURRENCY RESERVES” 비중대로 받는게 기본값입니다.
원하는 자산을 정해 100%로 출금하기 위해서는 원하는 가상자산 종류를 선택해야합니다. 다만, 이 과정에서는 슬리피지(Slippage)가 발생할 수 있습니다.

2.6. DAO

“DAO”는 “Decentralized Autonomous Organization”의 약자로 “탈중앙화된 자율조직”으로 해석할 수 있습니다.
스워브의 DAO는 스워브가 작동하기 위한 탈중앙화된 자율조직으로 볼 수 있겠습니다.

아래 스크린샷은 “DAO” 메뉴의 홈 화면입니다.

위에서부터 VOTING POWER IN DAO, SWUSD LIQUIDITY GAUGE, GAS PRICE가 표시됩니다.
DAO에서 사용자가 할 수 있는 가장 기본적인 기능들을 모아 나열해 두었다고 보면 되겠습니다.

• VOTING POWER IN DAO
  스워브의 DAO 토큰, 거버넌스 토큰인 SWRV를 일정 기간 잠그는 계약을 하고, 보팅파워(투표 권한이 있는 토큰) veSWRV 토큰을 받을 수 있습니다.
  이 작업을 “CREATE LOCK”으로 진행할 수 있습니다. 다만, 잠겨있는 기간동안 빼낼 수 없습니다.
• SWUSD LIQUIDITY GAUGE
  스워브의 SWUSD 풀의 유동성 게이지(Gauge)가 표시되며, 연결된 지갑의 SWUSD LP 토큰의 수량, 게이지에 입금한 수량, 받을 수 있는 SWRV 토큰 등이 표시됩니다.
  여기에 SWUSD LP 토큰을 입금해, SWRV — 스워브 거버넌스 토큰을 얻을 수 있으며, 현재가 기준으로 APY 년간수익률이 표시됩니다.
  락업한 veSWRV 만큼 Boost의 배수가 증가하게 됩니다.
• GAS PRICE
  유동성 게이지에 LP 토큰을 입금하거나, 출금하거나, SWRV 토큰을 클레임(Claim)할 때 사용할 이더리움 가스 가격(Gwei)를 설정합니다.

2.6.1. Voting

DAO의 핵심 기능인 거버넌스에 올라온 제안에 대한 투표를 여기서 할 수 있습니다.

2.6.2. Calc

풀의 내 입금액, 총 유동성 기준으로 내 SWRV를 얼마 기간동안 락업했을 때 몇 veSWRV를 받고, 유동성 게이지의 부스트 배수가 얼마가 되는지 계산해볼 수 있습니다.

2.6.3. ?

“?” 메뉴에서는 그 외 기능에 대한 ‘더 보기’ 메뉴입니다.

• Gauge Weight Vote

Locker에 잠겨있는 veSWRV 만큼, 원하는 유동성 게이지에 투표하여 SWRV 인플레이션 비중에 영향을 미칠 수 있습니다.

• Locker

보유중인 SWRV 토큰을 일정 기간 잠궈서 보팅 파워에 해당하는 veSWRV 토큰을 내 지갑에 할당받습니다.(지갑으로 전송되지는 않습니다.)
veSWRV의 ve는 “Vote-escrowed”의 약자입니다.

• Swerve APY

DAO 홈 화면과 동일합니다. 스워브 유동성 게이지의 목록을 확인하며, 유동성 게이지 참여시 보상으로 받게되는 SWRV의 APY(년간 수익률)을 확인할 수 있습니다.

• Contracts

스워브 DAO 관련 컨트랙트 주소를 확인할 수 있습니다.
*해당 컨트랙트 주소로 토큰을 전송하면 절대 안됩니다.

2.7. Risks

스워브 서비스 전반의 주의사항이 적혀 있습니다.

잠깐! 본 콘텐츠 작성 시점의 캡쳐 화면과 게시 시점의 화면이 다를 수 있습니다.
스워브 공식 트위터에서 UI 업데이트 예고가 있었는데, 화면이 비록 바뀌더라도 내용은 크게 다르지 않을테니 이 점 참고부탁드립니다.
https://twitter.com/SwerveFinance/status/1317153254409523200

3. Swerve를 써보자

스워브의 전반적인 화면들을 살펴봤으니, 이제 직접 써보겠습니다.
DeFi 탐험 전편인 Curve와 마찬가지로 1 ETH와 3,000 DAI를 탐험의 초기 잔고로 시작하겠습니다.

1 ETH는 일부 수수료로 사용할 것이며, 3,000 DAI는 풀에 맡긴 다음 SWRV를 마이닝해보겠습니다.

3.1. 지갑 연결

스워브 앱으로 접속해 지갑과 연결합니다. 본 탐험에서 사용할 지갑은 메타마스크입니다.
메타마스크 설정은 DeFi 탐험 1편을 참고해주세요.

3.2. Pool Deposit

풀(Pool)에 입금(Deposit)을 위해 swUSD 풀에 진입해 보겠습니다. 작성일 기준, swUSD 1개 풀만 있습니다.
스워브 홈의 GNB 메뉴에서 “SWUSD”를 클릭하거나, “SWERVE POOLS”에서 [DAI, USDC, USDT, TUSD] 풀을 선택합니다.

swUSD 풀의 “Deposit” 메뉴로 이동합니다.

“Deposit” 화면에서 swUSD 풀에 DAI 3,000개 입금해보겠습니다.

• Currencies: 풀에서 취급하는 자산, 보유량의 100% 자동 입력됨(위 화면에서는 3,000 DAI)
• Infinite Approval 체크함 (이후 같은 컨트랙트 실행시, Approve 트랜잭션 생략함)
• Gas Price: Fast (기본값)
• Max Slippage 1% (기본값)

입력과 설정이 완료되었으면 “DEPOSIT” 버튼을 클릭합니다.

Approve와 유동성 추가, 두 트랜잭션을 순서대로 승인합니다.

*메타마스크에서 트랜잭션을 승인하는 자세한 과정과 수수료 가스에 대한 설명은 DeFi 탐험 1편 커브(Curve)에 자세히 나와있으니, 이 과정에 대해 모르겠으면 전 편을 참고하실 수 있습니다.

이더스캔 지갑 주소 화면에서 ERC-20 토큰 목록에 swUSD 토큰의 잔고가 잡힌 것을 확인할 수 있습니다.

이더스캔 지갑 — ERC 토큰 목록의 swUSD 토큰을 클릭하면, 해당 지갑주소로 필터된 전송내역과 토큰 잔고 확인이 가능합니다.
여기서 보시면, swUSD 토큰은 0x000…주소에서 신규 생성되어 지갑으로 전송된 것을 확인할 수 있습니다.

이더스캔에서 TXID를 살펴보면, 3천개의 DAI와 0개의 USDC, USDT, TUSD가 풀에 전송되고, swUSD 토큰 약 2,996개가 0x000…에서 전송되었음을 확인할 수 있습니다.
해당 풀에서 취급하는 자산이 DAI, USDC, USDT, TUSD 총 4종인데, 잔고가 없는 항목까지 0개로 전송된 토큰에 표시되어 있네요.
0x000…에서 전송된 토큰은 신규로 생성(Mint)되었다고 보시면 되겠습니다.

3.3. Gauge Deposit

LP 풀 토큰인 swUSD 토큰이 생겼으니, 이제 이 풀 토큰을 DAO SWUSD Liquidity Gauge에 전송해서 스워브 DAO 토큰(거버넌스 토큰)인 SWRV 토큰을 마이닝해보겠습니다.

스워브 DAO 홈 화면에 표시된 swUSD 유동성 게이지(아래 스크린샷)에서 수량을 입력하고, “Infinite Approval”과 가스 등을 상황에 맞게 설정하고, “DEPOSIT”을 클릭하면 유동성 게이지로 LP 토큰이 전송되어 SWRV 토큰의 마이닝이 시작됩니다.

• SWRV APY에 표시된 수익률 확인
• Amount: 최대 (Balance 숫자 클릭해서 소수점 모두 입력)
• Infinite Approval 체크 (기본값)
• Gas Price: Fast (기본값)

“DEPOSIT”을 클릭하면, 총 2개의 트랜잭션이 발생합니다. 하나는 Approve에 대한 트랜잭션이고, 나머지 하나가 게이지로 토큰을 전송하는 트랜잭션입니다.

아래 스크린샷은 전송이 완료된 상태로, LP 토큰 출금할 수 있는 기능이 입금 우측에 표시됩니다.

잔고에서 swUSD 토큰이 거의 다 빠져나갔고, 극소량의 swUSD가 남아 목록에는 0으로 표시되고 있습니다.

DAO 입금 트랜잭션입니다. swUSD 토큰이 “swUSD Gauge”로 전송되었음을 확인할 수 있습니다.

시간이 지나면, Claim 가능한 SWRV 발생하기 시작합니다.
이제 스워브 디파이에 유동성을 제공한 것에 대한 보상으로 SWRV 토큰을 받게되었고, ‘기다림의 시간’ 이후 모두 출금을 진행해보겠습니다.

3.4. 기다림의 시간

20일의 시간이 흘렀습니다. SWRV 32개정도 쌓였네요.
이제 유동성 게이지에서 LP 토큰 — swUSD 토큰을 출금하고, 쌓인 SWRV를 Claim하고, swUSD 토큰에서 DAI를 출금해오겠습니다.

4. 정리: Gauge Withdraw, SWRV Claim, Pool Withdraw

4.1. Gauge Withdraw

스워브 DAO의 swUSD 유동성 게이지에서 입금된 swUSD 토큰 출금합니다.
해당 트랜잭션이 발생한 뒤로는 SWRV가 더이상 쌓이지 않게됩니다.

swUSD Gauge에서 swUSD 토큰이 지갑으로 전송되었습니다.

4.2. SWRV Claim

다음으로 Gauge에서 LP 토큰을 빼냈으니, 더이상 쌓이지 않는 SWRV 토큰을 Claim 하겠습니다.
Claim 버튼을 클릭하면, “Mint” 트랜잭션이 발생합니다.

Mint 트랜잭션이 승인되면, SWRV 토큰이 0x000…주소에서 생성되어 지갑으로 전송됩니다.

4.3. Pool Withdraw

이제 지갑으로 돌아온 swUSD 유동성 풀 토큰에서 DAI를 처음처럼 빼오겠습니다.
최초에 3,000개 DAI를 swUSD 풀에 입금했었죠. 이 풀에서 디파이 서비스 이용자들에 의해 거래(스테이블 토큰 스왑)가 발생하면, 소정의 수수료를 풀의 유동성 제공자는 얻게됩니다.
그래서 풀에 오래 두면, 처음 넣었을 때보다 풀 안의 자산은 수수료 증가분만큼 장기적으로 늘어나게 됩니다.
다만, 리저브의 비율이 정해져있고, 비율대로 출금하지 않고 이번처럼 DAI로 다 빼오려면, 자산간 스왑거래가 이뤄지면서 슬리피지가 발생할 수 있습니다.(아래 스크린샷의 왼쪽)

결과적으로 풀에서 취급하는 모든 자산 중에 출금할 때 선택한 DAI만 지갑으로 돌아왔습니다.
지갑에 있던 swUSD 풀 토큰은 0xa746… 컨트랙트로 보내졌다가 0x000… 주소로 전송되며 소각되었습니다.

돌아온 수량은 처음 3,000개 DAI보다 많아졌네요. 3,011개입니다.

4.4. 최종 잔고 비교

최종 잔고를 비교하며 마치겠습니다.
SWRV를 일드파밍하며 기다린 시간은 총 20일 5시간, 그 사이에 이더리움의 가격변동이 심했기 때문에 수익률을 단순히 평가금액으로 비교하기엔 무리가 있습니다.
다행히 저번 1편보다 수수료로 들인 ETH의 수량은 적은데, ETH의 가격이 많이 올라서, 파밍으로 얻은 수익으로 ETH 개수를 맞췄을 때 수익률은 스워브에 표시된 수익률보다는 떨어집니다.
자세한 계산은 생략하고, 수익이 난 DAI와 SWRV를 시세에 정리해서 ETH와 DAI를 시작할 때 수량으로 맞출 경우, SWRV가 절반정도 남게됩니다. 어쨓든 이번 편은 손실은 안봤고, 작지만 수익이 발생했네요.

DeFi 탐험, 스워브 편은 이렇게 마무리하겠습니다.
계획적으로 수수료와 시세, 예치 기간 등 여러가지 변수를 고려해야한다는 점을 잊지 마시기 바랍니다.

감사합니다.

*코인원 크립토 뉴스(https://coinone.co.kr/talk/)에서 코인원의 업계 뉴스부터 전문가의 트레이딩 분석, 디파이 관련 리서치까지 다양하게 만나보실 수 있습니다.

DeFi 탐험 유의사항

• 본 게시물은 DeFi의 다양한 서비스를 소개하는 취지에서 작성되었습니다.
• 본 게시물에 수록된 내용은 자료 작성자가 신뢰할 수 있는 자료 및 정보로부터 얻은 것이나 오차가 발생할 수 있으며, 당사는 어떠한 경우에도 정확성이나 완벽성을 보장하지 않습니다.
• 본 게시물에 나타난 모든 의견은 자료 작성자의 개인적인 견해로, 외부의 부당한 압력이나 간섭 없이 작성되었습니다.
• 본 게시물은 투자를 유도하거나 권장할 목적이 아닙니다.
• 본 게시물의 내용은 원본 손실의 가능성이 존재하며, 게시물에 표시된 수익률은 변동성이 있으며 당사는 이를 보장하지 않습니다.
• 본 게시물의 이미지에 표시된 스크린샷 화면은 실제 웹사이트 화면과 언제든지 일부 또는 전체가 변경될 수 있으며 당사는 이를 보장하지 않습니다.
• 본 게시물에 따라 투자를 진행하더라도 사용자의 사용 미숙, 실수, 복구키 유실 등 여러가지 이유로 자금의 원본을 전부 손실할 가능성이 있습니다.
• 본 게시물은 어떠한 경우에도 고객의 투자 결과에 대한 법적 책임 소재의 증빙 자료로 사용될 수 없습니다.
• 본 게시물의 저작권은 코인원에 있고, 어떠한 경우에도 코인원의 허락없이 복제, 대여, 재배포될 수 없습니다.
• 당사는 본 게시물의 해당 DeFi 서비스와 아무 관련이 없습니다.
• 당사는 본 게시물의 내용에 의거하여 행해진 일체의 투자 행위에 대하여 어떠한 책임도 지지 않습니다.

[DeFi 탐험 #2] Swerve was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요. 코인원에서 이번에 새롭게 디파이(DeFi: Decentralized Finance, 탈중앙화 금융) 탐험 시리즈를 기획해 여러분께 공유드립니다.
이번에 기획한 디파이 탐험 시리즈는 여러 디파이 서비스들을 실제로 사용해보면서 하나하나 체험해보는 가이드 컨셉으로 제작되었습니다.

콘텐츠의 특성상 분량이 많아 풀버전을 코인원 기술 블로그에 올려, 더 깊이있게 다뤄보고자 합니다.

코인원은 암호화폐 동향 및 디파이 관련 콘텐츠를 코인원 웹사이트 내 코인원 크립토 뉴스에서 꾸준히 다뤄왔으며, 아래 코인원 크립토 뉴스 배너를 클릭해 다른 콘텐츠도 만나보실 수 있습니다.

디파이란 블록체인 위에서 구축된 분산 금융 시스템을 뜻하며, 블록체인 네트워크를 기반으로 운영되는 분산화된 금융 서비스, 기술, 탈중앙화 애플리케이션(DApp) 등 넓은 범위에서 디파이라 불리는 서비스들이 생겨나고 있습니다.
디파이는 스마트 컨트랙트를 기반으로 블록체인 위에 구축되어 있으며, 스마트 컨트랙트를 동작할 수 있는 웹사이트에 지갑을 연결해 스마트 컨트랙트를 실행하는 방식으로 작동합니다.

본 디파이 탐험 콘텐츠는 디파이 서비스를 사용하면서 블록체인에서 실제로 어떤 일이 발생하게 되는가를 한땀한땀 스크린샷을 떠가며 함께 살펴보는 방식으로 구성되어 있습니다.
여러분께서는 본 콘텐츠를 통해 손에 잡히고, 눈에 보이는 블록체인 경험을 간접적으로 해 보실 수 있을 것입니다.

DeFi 탐험 계획

첫 탐험에서 다뤄볼 디파이 서비스는 커브 파이낸스(Curve Finance, 이하 “커브”)입니다.
커브는 2020년 1월 생겨난 이더리움 기반 디파이 서비스로, TVL(Total Value Locked, 예치 자산 합계) 기준으로 손에 꼽힐만큼 많은 자산이 예치되어 있습니다.
커브는 디파이 서비스로 유동성 풀을 통해 자산간 교환을 할 수 있도록 지원하거나, 자산을 유동성 풀에 넣어 이자를 얻을 수 있는 플랫폼을 제공합니다.

탐험할 서비스: Curve Finance (이더리움 블록체인 기반)

준비물
💻 인터넷이 접속되는 안전한 컴퓨터
🌐 크롬 또는 파이어폭스 웹브라우저와 메타마스크 지갑(플러그인)
💎 블록체인 전송 수수료로 사용할 소량의 ETH
💵 디파이 서비스 입금할 연구 목적의 DAI

목차

1. DeFi 세상으로 한 발짝
   1.1. Why DeFi?
   1.2. 지갑 설정하기
   1.3. 지갑으로 코인 전송하기
2. Curve 둘러보기
   2.1. 커브 Home 둘러보기
   2.2. 커브 Pool 둘러보기
3. Curve 이제 진짜 써보자
   3.1. Curve 웹사이트에 지갑 연결
   3.2. 커브 컴파운드 풀에 Deposit 하기
4. Curve DAO에 LP 토큰을 Deposit 해보자
   4.1. Curve DAO가 뭔가요?
   4.2. Curve DAO 간단히 살펴보기
   4.3. Curve DAO 웹사이트에 지갑 연결하기
   4.4. Gauge에 LP 토큰 Deposit 하기
   4.5. 기다림의 시간
5. 정리: Gauge Withdraw, CRV Claim, Pool Withdraw
   5.1. Gauge Withdraw
   5.2. CRV Claim
   5.3. Pool Withdraw
   5.4. 최종 잔고 비교
6. 마치며

1. DeFi 세상으로 한 발짝

디파이(DeFi)는 시파이(CeFi: Centralized Finance, 중앙화 금융) 밖 세상입니다.
시파이에서 한 발짝 내딛으면 디파이 세상이 나옵니다.

1.1. Why DeFi?

왜 디파이를 하는 걸까요? 필자는 디파이를 왜 하는가, 왜 해야하는가에 대해 “필연적”이기 때문이라 말씀드리고 싶습니다.
블록체인은 비트코인이 탄생한 이후, 오늘날에 이르기까지 우여곡절이 있었지만 블록체인 생태계는 고도화를 꾸준히 이뤄왔습니다.
이제는 블록체인 위에 올라간 가치를 다양한 방법으로 활용하는 단계에 와있습니다. 이는 다분히 필연적입니다.

“필연적”이라는 말이 다소 추상적이네요. 그렇다면 디파이를 하는 이유는 무엇일까요?
디파이에 참여하는 대부분의 일반 투자자들은 “탈중앙화 금융을 통해 중앙화 금융보다 더 큰 수익을 낸다”는 목표를 갖고 있을 것입니다. 그게 아니면 굳이 디파이를 할 필요가 없으니까요.
디파이로 수익을 낼 수 있다/없다에 대한 부분은 본 콘텐츠에서 확답드리기 어렵습니다. 너무 다양한 변수가 있기 때문에 수익을 보장할 수 없기 때문입니다.
수익에 대한 부분은 여러분의 몫으로 남겨두겠습니다. 본 콘텐츠로 디파이 관련 지식이 늘어나 수익에 도움이 되길 바랍니다.

1.2. 지갑 설정하기

블록체인은 다양한 형태와 이름으로 이 세상에 존재하며, 이번 탐험에서 다뤄볼 서비스는 이더리움 블록체인을 활용하고 있습니다.
먼저 이더리움 지갑을 컴퓨터에 설치하는 작업부터 시작해보겠습니다.

이더리움 공식 사이트에서 여러 이더리움 지갑들을 확인하실 수 있습니다.(https://ethereum.org/ko/wallets/)
DeFi 탐험에서는 다양한 디파이 서비스에서 이미 널리 지원하고 있고, 이더리움 공식 웹사이트의 지갑 페이지에서 가장 먼저 언급되는 메타마스크(https://metamask.io/)를 사용해보겠습니다.

1. 메타마스크 공식 웹사이트(https://metamask.io/)에 접속합니다.
우측 상단의 “Download” 버튼을 클릭해 다운로드 페이지로 이동해, 웹 브라우저용 메타마스크 플러그인을 설치해야합니다.

2. 웹 브라우저는 크롬과 파이어폭스를 지원합니다. 본 콘텐츠에서는 크롬만 다뤄보겠습니다.
“Install MetaMask for Chrome”을 클릭합니다.

3. 크롬 웹 스토어에서 메타마스크 플러그인을 “Chrome에 추가” 버튼을 클릭해 설치하세요.

4. “Chrome에 추가”를 클릭해 뜬 팝업에서 “확장 프로그램 추가”를 클릭하면, 메타마스크 플러그인이 설치됩니다.

5. 크롬 우측상단 플러그인 아이콘을 클릭해, 확장 프로그램을 고정(핀 모양 아이콘)하면, 편리하게 이용할 수 있습니다.

6. 플러그인 설치 및 고정 했다면, 메타마스크 플러그인 아이콘을 클릭해, 지갑을 생성해야 합니다.
크롬 우측상단의 메타마스크 플러그인 아이콘을 클릭해 “시작하기” 버튼을 클릭합니다.

7. “지갑 생성하기” 버튼을 클릭해 지갑 생성을 시작합니다.

8. 메타마스크 개선을 도울지 말지 설명을 확인하고 직접 결정해서 “No Thanks” 혹은 “I agree”를 클릭하세요.

9. 비밀번호를 생성해야합니다. 이 비밀번호는 지갑 사용을 위해 메타마스크의 잠금을 푸는데 필요한 암호입니다.
최소 8자 이상의 강력한 비밀번호를 정해 설정해주시고, 입력칸 아래 체크 박스 항목의 “사용 지침”을 확인 후 체크하고, “생성” 버튼을 클릭하세요.

10. 비밀번호 생성만으로 지갑은 만들어집니다. 다만, 메타마스크 플러그인 유실 또는 웹 브라우저 초기화시 지갑을 복원할 수 있도록 “비밀 백업 구문”을 별도 보관하는 과정이 남아있습니다. 이 비밀 백업 구문은 나중에 지갑을 되살릴 때 사용할 수 있습니다.
화면에 표시된 비밀 백업 구문을 별도로 보관하셨다면, “다음”을 클릭하세요. (단어를 마스킹 처리했습니다.)

11. 별도로 백업해둔 비밀 백업 구문을 보고, 아래 버튼을 클릭해 순서대로 나열하세요.
모든 단어를 나열하고, “승인” 버튼을 클릭하세요.(단어를 마스킹 처리했습니다.)

12. 이제 지갑을 사용할 준비가 거의 다 되었습니다. “안전하게 시드 구문을 보관하는 팁”을 꼭 참고해주시고, “모두 완료” 버튼을 클릭해 지갑 생성 완료하세요.

13. 지갑 생성을 완료하면, 웹 브라우저의 메타마스크 플러그인 아이콘을 클릭해 지갑의 잔고를 확인할 수 있습니다.

1.3. 지갑으로 코인 전송하기

이제 방금 생성한 따끈따끈한 새 지갑으로 코인을 전송해볼 차례입니다.
이번 디파이 탐험에서 사용할 코인은 1 ETH와 3000 DAI로 정했습니다.
필자가 좋아하는 숫자로 정한 임의의 수량일 뿐, 꼭 이정도 필요하다는 최소 수량도 권장 수량도 아님을 밝힙니다.

• ETH는 이더리움 블록체인을 이용하기 위한 수수료로 사용되기 때문에 소량 필요합니다.
  본 콘텐츠에서 1개의 이더리움을 수수료로 전부 소진할 일은 없습니다만, 가스 가격에 따라 수수료의 필요 수량이 변동성이 있어 넉넉하게 준비했습니다.
• DAI는 블록체인 기반 스테이블 코인으로 디파이 서비스 Curve에 예치 가능한 다양한 토큰 종류 중 하나로, 예시로 정한 것입니다.
  수량 또한 예시로 정한 임의의 수량입니다.

실제로 디파이 서비스를 이용해보는 사용자 관점에서는 지출되는 이더리움 수수료와 디파이 서비스의 수익률을 고려해 초기자본을 산정하시기 바랍니다.
DAI는 ERC-20 토큰이기 때문에 이더리움 주소로 전송받을 수 있습니다.

1. 먼저 지갑으로 코인을 전송하기 위해서는 메타마스크에서 지갑 주소를 복사해야 합니다.
메타마스크 플러그인을 실행해, 주소 부분을 클릭하면, 입금주소가 복사됩니다.

2. 복사한 주소를 이더리움 블록체인 익스플로러 서비스에서 검색해 제대로 복사되었는지 확인해볼 수 있습니다.
본 콘텐츠에서는 가장 널리 쓰이는 이더리움 블록체인 익스플로러로 이더스캔(Etherscan)을 사용하겠습니다.

3. 복사한 주소로 앞에서 정한 두 종류의 코인(ETH, DAI)을 전송해 보겠습니다.
코인 전송은 사용하시는 거래소에서 지갑으로 진행하면 됩니다.

지갑으로 전송이 완료되면, 메타마스크 지갑에 1 ETH가 표시됩니다.
DAI는 처음에 표시되지 않을 수 있는데, 토큰을 추가해 표시할 수 있습니다.
토큰을 추가하는 방법은 “Assets” 탭에서 “토큰 추가” 버튼을 클릭하고, 종목을 검색해(“DAI” 입력) 토큰을 추가할 수 있습니다.

*다시 한번 강조드리지만, 지갑으로 전송한 1 ETH와 3000 DAI는 예시로 정한 수량일 뿐, 최소 수량이나 권장 수량이 아닙니다.

4. 이더리움 블록체인 익스플로러인 이더스캔에서도 입금된 자산을 확인할 수 있습니다.

2. Curve 둘러보기

지갑에 코인을 준비해뒀으니, 이제 디파이 서비스인 커브(Curve)로 이동해, 커브가 어떤 곳인지 둘러보겠습니다.
먼저, 커브 웹사이트의 최상단 메뉴를 살펴보며 어떤 기능을 제공하는지 확인하고, 차례로 “Home”(홈)과 커브의 주요 기능인 “Pool”(풀)을 둘러보도록 하겠습니다.

• (가로 세 줄 아이콘) 메뉴 버튼: 커브의 개별 풀을 이동할 수 있습니다.
• “Home”: 커브 홈으로 이동합니다.
• “DAO”: Curve DAO 메뉴로 이동합니다.
• “Use CRV”: 커브를 ‘사용’할 수 있는 메뉴로, CRV 토큰 스테이킹과 관련된 메뉴입니다.
• “Trade”: 커브의 여러 풀에서 발생한 거래 차트를 확인하고, 풀의 토큰간 교환이 가능합니다.
• “Stats”: 커브 풀의 상태를 표시합니다.
• “Pay”: Curve Pay 메뉴로 이동합니다.
• “Risks”: 커브 사용에 대한 위험 안내 페이지입니다.
• “?”: 컨트랙트 주소, 가이드 등 다른 메뉴로 이동할 수 있습니다.

2.1. 커브 Home 둘러보기

1. 홈의 첫번째 섹션은 “Swap using all Curve pools”입니다.
커브에는 다양한 풀(이하 ‘풀’로 부릅니다.)이 있는데, 모든 풀에 예치된 자산간 “Swap”(교환)이 가능하도록 지원하고 있습니다.

사용자는 Swap 과정에서 수수료를 커브 풀에 지불하게되며, 이 수수료가 커브 풀에 예치한 자산들에게 제공되는 기본적인 수익이라고 보시면 되겠습니다.
다만, 개별 풀마다 수익을 만드는 방법에는 차이가 있을 수 있습니다.

정리하면, 이 “Home” 화면의 최상단 섹션은 커브 서비스가 제공하는 핵심적인 Swap 기능을 표시한 화면이라고 보시면 되겠습니다.

2. 홈 화면의 두번째 섹션은 커브에서 지원하는 여러 풀의 전체 목록이 표시된 “Curve pools”입니다.
각각의 풀은 취급하는 자산이 정해져 있으며, 사용자가 예치한 자산으로 구성됩니다.

이 화면에서는 각 풀의 취급 자산, 년간 수익률(CRV 마이닝 포함), 거래량 등 상세 정보를 표시합니다.

3. “Curve pools”에 표시된 첫번째 풀인 “0. Compound”를 예시로 살펴보겠습니다.

• 0. Compound: 해당 풀의 순번과 풀의 이름입니다.
  여기서 Compound는 컴파운드 디파이 서비스(https://compound.finance/)를 의미합니다.
  각 커프풀에 대한 자세한 내용은 커브 가이드 “Understanding Curve”(https://resources.curve.fi/base-features/understanding-curve)를 참고하세요.
• [ (c)DAI, (c)USDC ]: 해당 풀에서 취급하는 자산, (c) 표시는 cDAI와 DAI, cUSDC와 USDC를 지원한다는 의미입니다.
  “Buy and sell”(Swap 기능), “Deposit”(입금) 화면에서 “~ wrapped” 체크박스를 클릭하면, cDAI나 cUSDC같은 wrapped(감싸진) 토큰을 입금하거나 교환할 수 있습니다.

• APY: 해당 풀의 연간 유효 이자율 “Annual Percentage Yield”의 약자입니다.
  첫 줄에 표시된 “2.10%”는 앞서 언급한 풀 운용에 따른 “기본적인” 이자에 해당합니다.
  그 아래 줄의 “+23.47% to 58.68% CRV”는 해당 풀 토큰을 Curve DAO에 예치해, CRV(Curve DAO token)를 받았을 때의 예상 수익률입니다.
• Vol: “Volume”의 줄임말로, 해당 풀의 최근 24시간 거래량입니다.

4. 세번째, 네번째 섹션은 “veCRV stats”과 “Total pool deposits and daily volume”입니다.

• “veCRV stats”은 베스팅 CRV 토큰인 veCRV의 상태에 대해 표시됩니다.
  veCRV에 대해 궁금하신 분은 커브의 가이드 “What are veCRV?”(https://resources.curve.fi/faq/vote-locking-boost#what-are-vecrv )를 참고하시기 바랍니다.
• “Total pool deposits and daily volume”에는 현재 모든 풀에 입금된 자산의 총 금액과, 일간 거래량이 표시됩니다.

2.2. 커브 Pool 둘러보기

커브 홈을 가볍게 살펴봤으니, 이제 커브의 핵심 기능인 Swap(교환)을 가능하게 해주는 개별 풀을 살펴보며 좀 더 서비스를 깊이있게 살펴보겠습니다.
커브에서 제공하는 다양한 풀의 구조는 대부분 비슷합니다. 여러 풀 중 대표로 첫번째 풀인 컴파운드 풀을 선택했습니다.
커브 홈의 좌측 상단 메뉴에서 컴파운드 풀로 이동합니다.

컴파운드 풀 상단 막대의 메뉴는 아래와 같습니다.

• “[Compound]”: 현재 들어와 있는 풀의 이름이 표시됩니다. 클릭하면, 풀을 바꿀 수 있는 메뉴가 뜹니다.
• “Root”: 커브 홈으로 이동합니다.
• “DAO”: Curve DAO 메뉴로 이동합니다.
• “Buy and sell”: 컴파운드 풀에 예치된 자산을 활용한 교환을 할 수 e있습니다.
• “Deposit”: 컴파운드 풀에서 취급하는 자산을 예치할 수 있습니다.(예치시 컴파운드 풀 토큰을 받게됩니다.)
• “Withdraw”: 컴파운드 풀 토큰을 반납하고, 컴파운드 풀에서 취급하는 자산을 출금할 수 있습니다.
• “Stats”: 풀의 상태를 표시합니다.
• “Profit”: 해당 풀에 관련된 내 자산의 입출금 및 수익을 확인합니다.
• “Pay”: Curve Pay 메뉴로 이동합니다.
• “?”: 컨트랙트 주소, 가이드 등 다른 메뉴로 이동할 수 있습니다.

2.2.1. Buy and Sell

1. 처음 컴파운드 풀에 들어오면, 바로 “Buy and sell”로 들어옵니다.
“Buy and sell”에서는 컴파운드 풀에 예치된 자산들을 이용해 풀에서 지원하는 자산간 Swap(교환)을 할 수 있습니다.
커브에서는 이 교환을 “Sell”로 표시하고 있습니다.

2. “Buy and sell”의 회색 배경 섹션을 살펴보겠습니다. 이 섹션에서 Swap(교환)을 할 수 있습니다.

• “From”과 “To”에 교환을 원하는 자산의 종류를 선택하고, 수량을 입력할 수 있습니다.
• “Infinite approval”을 체크하면, 이후 동일한 자산 취급시, 별도의 Approve 트랜잭션 단계를 생략할 수 있습니다.(Approve 트랜잭션은 이후 실제 트랜젝션을 발생시킬 때 더 알아보겠습니다.)
• (앞에서 잠깐 언급하기도 했는데) “Swap wrapped”를 클릭하면 Compound 디파이 서비스에 자산을 예치하고 받을 수 있는 Wrapped 자산인 cDAI와 cUSDC를 교환할수도 있습니다.
• “Advanced option”을 펼치면, “Max slippage”와 “Gas price”를 설정할 수 있습니다.

• “Max slippage”: 요청 가격과 실제 체결 가격의 차이가 몇 %까지 거래를 허용하겠느냐에 대해 미리 정해두는 수치입니다. 기본값은 1%입니다.
• “Gas price”: 이더리움 블록체인에 지불할 가스의 가격을 정할 수 있습니다. 기본값은 “Fast”이며, 숫자의 단위는 “gwei”입니다.
  대부분의 블록체인은 거래량과 전송 횟수가 늘어났을 때 전송 수수료가 증가하게 됩니다. 이유는 블록체인 블록에 태울 수 있는 트랜잭션 수는 한정되어 있으나, 블록의 크기는 제한되기 때문입니다. 채굴자 입장에서는 더 높은 비용을 지불하겠다는 트랜잭션을 선택해 블록에 태우게 되기 때문에 블록체인 네트워크에 트랜잭션이 많아지면 가스 값이 올라가 전송 수수료가 증가합니다.대부분의 디파이 서비스는 적정 가스 가격을 책졍해 제시하지만, 블록체인 네트워크가 과부하되었을 때는 빠르게 컨펌을 진행하기 위해 가스 가격을 높이 입력해야할 때가 있습니다.가스 트래커(Gas Tracker) 서비스를 이용해 적정 가스 가격을 찾고, 즉시 컨펌이 날만한 가스의 가격(gwei)을 확인할 수 있습니다.
• “Sell” 버튼은 위에서 정한 대로 트랜잭션을 발생시킵니다.
• “Estimated tx cost”는 가스 가격(gwei)를 고려한 예상 트랜잭션 수수료입니다.

3. 하단의 파란 배경 섹션은 “Currency reserves”가 표시되며, 컴파운드 풀에 예치된 전체 자산과 비중 등 상태를 확인할 수 있습니다.
이 섹션은 풀의 전반적인 상태라 여러 메뉴에서 자주 등장합니다.

2.2.2. Deposit

“Deposit” 메뉴를 살펴보겠습니다. 단어 그대로 풀에 자산을 입금하기 위한 기능을 제공합니다.

• “Currencies”에서 입금 가능한(컴파운드 풀에서 취급하는) 자산의 종류를 표시하고, 수량을 입력할 수 있습니다.
• “Gas price”에서 트랜잭션 발생에 사용할 가스 가격을 설정합니다. 4개의 체크박스가 있는데, 하나씩 알아보겠습니다.
• “Add all coins in a balanced proportion”: 회색 섹션 하단의 “Currency reserves”에 적힌 자산 비중과 동일한 비율로 예치 수량이 입력됩니다. (기본값: 체크 안함)
• “Use maximum amount of coins available”: 입력칸에 가능한 모든 자산의 수량이 자동으로 입력됩니다. (기본값: 체크 함)
• “Infinite approval — trust this contract forever”: (Buy and sell에서도 언급했지만) 디파이 서비스에서 대부분의 컨트랙트 트랜잭션 발생에는 “Approve” 트랜잭션을 해야, 다음 단계인 실제 전송(컨트랙트 실행)을 진행할 수 있습니다. 한번의 승인으로 이후 동일한 컨트랙트에 대해 Approve를 생략하려면, 이 체크를 하고 입금을 진행하면 됩니다. (기본값: 체크 안함)
• “Deposit wrapped”: 체크하면 해당 풀에서 취급하는 wrapped 자산으로 입력칸이 바뀝니다. (기본값: 체크 안함)
• “Deposit” 버튼은 컴파운드 풀에 입력한 수량만큼의 토큰을 입금하는 기능입니다. “Deposit” 진행시, 이 컨트랙트 실행이 최초이거나, 이전에 “Infinite approval”을 하지 않았다면, Approve 트랜잭션을 하고, 실제 컨트랙트 트랜잭션을 발생시킵니다.
  즉, 총 2번의 트랜잭션이 순차적으로 발생하게 됩니다.(2번의 TX: Deposit에 대한 Approve TX → Deposit TX)
• “Deposit & stake in gauge” 버튼은 입금과 같이 DAO gauge에 해당 풀 토큰을 예치하는 버튼입니다. “Deposit & stake in gauge” 진행시, “Deposit”과 마찬가지로 Approve 트랜잭션과 같이 진행해야하는데, 이번엔 “Stake in gauge” 트랜잭션도 같이 발생해야하므로, 총 4번의 트랜잭션이 순차적으로 발생하게 됩니다.(4번의 TX: Deposit에 대한 Approve TX → Deposit TX → Stake in gauge에 대한 Approve TX → Stake in gauge TX)
• “Risks of using compound pool”은 해당 풀의 위험성에 대한 페이지입니다.
• “You’ll receive minimum ~”은 입금시 예상 수령 compound LP token과 해당 토큰의 가격 등의 정보가 표시됩니다.
• “Advenced option”은 (“Buy and sell”의 설명과 마찬가지로) 슬리피지를 설정하는 칸입니다.
• “Bonus(plus pricing)”은 회색 섹션 하단의 “Currency reserves”에 표시된 해당 풀의 취급 자산 중 비중이 적은 자산을 입금할 때 주어지는 가격 혜택입니다.

2.2.3. Withdraw

“Withdraw”는 단어 그대로 해당 풀에서 내 자산을 출금하는 기능입니다. 풀 토큰을 돌려보내고, “Currencies”에 표시된 자산을 출금할 수 있습니다.

• “Share of liquidity” 입력칸에서 %로 출금할 비율을 정할 수 있습니다.
• “Currencies”에는 출금될 자산의 수량이 표시됩니다.
• “Withdraw wrapped”를 체크하면, wrapped 자산(컴파운드에서는 cDAI, cUSDC)로 출금할 수 있습니다.(기본값: 체크 안함)
• “Withdraw $ in”에서는 자산을 섞어 출금할지(해당 풀의 자산 비율대로 출금), 특정해서 출금할지를 정할 수 있습니다.
• “Donate dust”는 자산의 먼지를 기부하는지에 대한 옵션이며, 툴팁 도움말에서는 이 기능의 사용시 전송 수수료가 줄어들 수 있다고 나옵니다.(기본값: 체크 함)
• “Gas price”에서 가스 가격을 정할 수 있습니다.
• “Infinite approval — trust zap contract forever”을 체크하면, 다음번엔 Approve를 없이 동일한 컨트랙트를 바로 실행할 수 있습니다.(기본값: 체크 안함)
• “Withdraw” 버튼으로 트랜잭션을 발생시킵니다.
  (위 스크린샷에 표시되어있지는 않지만) DAO gauge에 풀 토큰을 예치했다면 회수가능한 CRV가 생기는데, CRV(Curve DAO 토큰)의 Claim(회수) 기능, DAO gauge에서 언스테이킹 기능도 여기서 할 수도 있습니다.

2.2.4. Stats

“Stats”에서는 해당 풀의 상태 — 유동성 제공자의 수익률 변화, 일간 APY의 변화 등을 확인할 수 있습니다.

2.2.5. Profit

“Profit”은 해당 풀의 내 자산 상태를 확인할 수 있습니다.

3. Curve 이제 진짜 써보자

커브 서비스를 간략하게나마 살펴본 것 같습니다.
여기까지 따라오셨다면, 대략적으로 커브 서비스가 어떻게 구성되어 있고, 어떤식으로 작동하는지 자세하게는 아니지만 대략적으로는 파악이 되었을 것입니다.

이제 커브 서비스에 직접 자산을 입금해 LP(Liquidity Provider: 유동성 공급자) 토큰을 민팅(Minting: 자산을 발행한다는 의미)하는 과정을 진행해보겠습니다.
여러분들이 콘텐츠를 이해하고 참고하기 유용하도록 본 콘텐츠에서 사용하는 용어는 가급적 커브의 화면에 쓰인 용어를 영어 그대로 사용하겠습니다.

3.1. Curve 웹사이트에 지갑 연결

1. 커브 웹사이트(https://www.curve.fi/)로 이동해, 지갑을 연결해 보겠습니다.
먼저, 웹사이트에 접속하면 지갑을 연결하라고 “Select a Wallet” 창이 뜨는데, 앞서 코인을 모아둔 지갑인 메타마스크로 접속합니다.

2. 연결할 지갑을 선택하고, 웹사이트에서 요청하는 권한을 확인하고 “연결”합니다.

• 메타마스크 플러그인 좌측 상단에서 “Connected”를 클릭하면, 연결 상태를 확인할 수 있습니다.

3.2. 커브 컴파운드 풀에 Deposit 하기

이제 커브에서 지원하는 풀 중 하나인 컴파운드 풀을 예시로 “Deposit” 메뉴에서 실제 자산(DAI)을 커브 컴파운드 풀에 입금하는 트랜잭션(TX)를 발생시켜보겠습니다.
이 작업에는 실제 DAI와 수수료용 ETH가 사용되며, 블록체인 위에서 실제로 어떻게 기록이 남는지는 트랜잭션을 살펴보도록 하겠습니다.

1. 커브 컴파운드 풀의 “Deposit”(https://www.curve.fi/compound/deposit)으로 이동합니다.
(컴파운드 풀은 예시로 정한 것이며, 여러분들께서는 시장상황을 고려하여 선택하시기 바랍니다.)

필자는 이 입금 컨트랙트에 대해 다음번에는 “Approve” 트랜잭션을 추가로 하지 않기 위해 “Infinite approval”을 체크해서 “Deposit”을 진행하겠습니다.

잠깐! 트랜잭션을 실제로 발생시키는 작업에 앞서, 이더리움 블록체인 네트워크의 상태를 확인해 지금의 가스 가격이 트랜잭션을 발생시키기에 적절한 시기인가를 가늠해보는 것이 좋습니다. 이더리움 가스 가격은 참여자들이 어떤 트랜드에 따라 블록체인을 사용하는가에 따라 차이가 아주 크고, 너무 과도하게 가스 가격이 높으면 수수료를 터무니없이 많이 내야합니다.

필자가 가스 가격 상태를 확인하는데 사용하는 서비스 몇 곳을 소개해 드리겠습니다.

• “이더스캔”의 “Gas Tracker”(https://etherscan.io/gastracker)
  가스 가격의 Low, Average, High 값과 평균 컨펌 시간과 가스 가격의 차트를 확인할 수 있습니다.

• “이더리움프라이스”(https://ethereumprice.org/gas/)의 최근 7일간의 가스 가격(gwei) 차트
  가스 가격의 추세를 파악하기 좋습니다.

• “이더리움프라이스”(https://ethereumprice.org/gas/)의 최근 7일간의 요일별/시간대별 분포(히트맵)
  최근 요일/시간대별 가스 가격을 통해 최적의 요일과 시간대를 파악하기 좋습니다.

2. 필자는 작성 시간 기준으로 “High”에 해당하는 96 gewi 보다 약간 더 높게 100 gwei 정도로 진행해보겠습니다.
High 보다 높게 수수료를 정하면, 거의 최우선 순위로 트랜잭션이 컨펌나게 됩니다.

*가스 가격은 네트워크 상황에 따라 계속 변하므로, 본 콘텐츠에서 작성한 가스 가격은 집필 당시 상황에 맞게 작성한 가격일 뿐, 그대로 따라하지 마십시오.

3. “Deposit” 버튼을 누르기 전에, 다시 한번 값이 똑바로 입력되어 있는지 두번 세번 확인합니다.
블록체인 위에서 거래는 “불가역적”(되돌릴 수 없음)이기 때문에 늘 실수하지 않게 늘 주의해야합니다.

• “Currencies”: 미리 지갑에 준비해둔 DAI 3000개 (“Use maximum amount of coins available”이 체크되어 있기 때문에 자동으로 입금 가능 자산이 전량 입력됩니다.)
• “Gas price”: 100 Fast(단위: gwei) (가스 가격은 매 순간 실시간으로 달라질 수 있습니다. 여기서 정하더라도, 지갑에서 컨펌할 때 변경 가능합니다.)
• “Infinite approval — trust this contract forever” 체크했습니다.(본 체크박스는 선택사항이며, 필자는 다음에 같은 컨트랙트를 작동할 때, Approve 트랜잭션을 발생하지 않아도 되서 나중에 수수료 절약 효과가 있기 때문에 체크한 것입니다.)
• (“Advanced options”의) “Max slippage”는 기본값인 1%로 그대로 진행하겠습니다.

4. “Deposit”을 클릭합니다.

5. 메타마스크에서 “Allow ~” 알림창이 뜹니다. 이 과정이 앞서 계속 말씀드렸던 “Approve 단계”입니다.
이 알림창에서 내가 진행중인 거래가 맞는지 정확히 확인해야합니다.

자세하게 알아보자면, 이더리움 블록체인에서 컨트랙트를 실행하기 전에 해당 컨트랙트를 허용하겠다는 의사표명을 블록체인 위에다 해야, 그 다음 컨트랙트 사용을 할 수 있습니다. 일종에 안전장치로 이렇게 설계되어있다고 보시면 되겠습니다. 이 Approve 단계는 실제로 트랜잭션을 이더리움 블록체인 네트워크 위로 보내야하며, 그 과정에서 “Approve”에 대한 데이터가 담긴 트랜잭션을 발생시키므로 소정의 ETH 수수료가 필요합니다.

처음이니 만큼, 이 트랜잭션 요청에 대해서 더 자세하게 살펴보겠습니다.

• 메타마스크 알림창의 최상단에 표시된 “1~ 의 2”는 두개의 트랜잭션 중 한개(첫번째)를 의미합니다.
• 그 아래로 내 지갑의 주소와 어떤 네트워크인지(이더리움 메인넷) 표시됩니다.
• 큰 글자로 표시된 요청의 제목이 표시되는데, 한번 읽어보겠습니다. “Allow Https://www.curve.fi to spend your DAI?”
  (앞서 메타마스크 지갑과 연결한) 커브 웹사이트에 당신의 DAI를 보내는 것을 허용하겠냐 정도로 읽으면 되겠네요.
• 그 아래로 보이는 “Edit Permission”(권한 편집)버튼을 클릭해보겠습니다. “Unlimited”와 그 숫자가 무한대 수준(1.157…62e+59)으로 깨진 상태로 표시되어 있네요. 이유는 앞에서 “Infinite approval”을 체크했기 때문입니다. 만약 앞에서 “Infinite approval”을 체크하지 않으면 “Unlimited”와 3000개만 표시됩니다.
  정리하면, “Edit Permission”에서는 해당 컨트랙트에 몇 개까지 자산을 취급을 허용하겠는가에 대한 권한을 정의한다고 볼 수 있습니다.
  이미 웹에서 설정이 된 상태로 지갑으로 요청이 들어오기 때문에 특별히 설정을 바꿀 필요는 없습니다.

• “Transaction Fee”의 “Edit”도 살펴보겠습니다. 실제 트랜잭션 진행할 때, 꽤 자주 들어가는 화면입니다.
  웹에서 이미 가스 가격을 정해서 들어오더라도, 시시각각 변하는 가스 가격을 파악해 원하는 시간 내에 컨펌이 발생하도록 가스 가격을 조정해줄 수 있습니다.
  “가스 설정”의 “Basic” 탭에서는 자체적으로 “느림”, “평균”, “빠름”으로 실시간으로 온체인 데이터를 받아와 클릭가능한 버튼으로 제공해주며, “고급” 탭에서는 직접 가스 가격을 입력할 수 있습니다. (빠른 트랜잭션 컨펌을 위해 High 보다 높게 책정해줄 때, 이 화면에서 직접 가스 가격을 입력합니다.)

• 마지막으로 “View full transaction details”를 클릭해 펼쳐보면, 이 트랜잭션 요청의 상세정보를 파악할 수 있습니다.
  “Permission”(권한)에서는 “어느 만큼의 자산을 어떤 컨트랙트 주소에 보내기를 허용하는가”를 요청하는 것이며, “Data”에서는 “컨트랙트 상에 정의된 Function(기능)이 무엇이며, 무슨 데이터를 블록체인에 보낼 것인가”가 표시되어 있습니다.

6. 이제 이 첫번째 트랜잭션인 “Approve” 트랜잭션을 진짜로 발생시켜보겠습니다.
“Allow Https://www.curve.fi to spend your DAI?” 알림창에서 “승인”을 클릭합니다.

7. “Allow ~” 메타마스크 창의 “승인” 클릭 즉시, 커브 웹 화면에서는 우측 상단에 “Your transaction has started” 알림이 표시되고, 다음 트랜잭션 “ADD_LIQUIDITY” 메타마스크 창이 뜹니다.

“ADD_LIQUIDITY” 트랜잭션은 영어 뜻 그대로 유동성을 제공하는 트랜잭션입니다.
블록체인 위에 올라갈 데이터가 “Approve” 트랜잭션보다 복잡하기 때문에 다소 많은 수수료가 필요하다고 표시됩니다.
다만, 표시된 수수료는 예상값으로 실제로 발생하는 수수료는 보통 더 적습니다.

“승인” 버튼을 클릭하면, “ADD_LIGUIDITY” 트랜잭션이 발생합니다.

이 트랜잭션 요청에서 표시되는 “자산”은 ETH 수수료가 전부인 것처럼 보이지만, 실제로 트랜잭션이 발생하게되면 커브 컴파운드 풀에 DAI가 전송되게 됩니다.
자세한 내용은 실제로 발생한 트랜잭션 이더스캔에서 살펴보며 확인해보겠습니다.

3.2.1. Deposit 트랜잭션 확인하기

1. 트랜잭션을 발생시키면, 트랜잭션 내역이 메타마스크의 “Activity” 탭의 목록에 쌓이는 것을 확인할 수 있습니다.
(수수료를 낮게 책정하여 컨펌이 되지 않을 때는 이 화면에서 수수료를 상향시키거나 거래를 취소시키도록 이미 발생한 트랜잭션을 업데이트할 수 있습니다.)

2. 트랜잭션을 자세히 살펴보겠습니다.
메타마스크에서 “Activity”의 트랜잭션 항목을 클릭하면, 트랜잭션의 세부사항을 확인할 수 있으며, (아래 두번째 스샷에 빨간 박스로 표시한) 우상향 화살표 버튼을 클릭하면 이더스캔에서 트랜잭션을 확인할 수 있습니다.

3. 블록체인 익스플로러 이더스캔에서 앞서 발생한 두개의 트랜잭션 “Approve DAI spend limit”과 “Add_liquidity” 트랜잭션을 살펴보겠습니다.

• “Approve DAI spend limit” 트랜잭션

자산의 전송은 없고, “Approve” 요청에 대한 데이터 전송에 따른 트랜잭션 수수료만 빠져나가는 트랜잭션입니다.
“Input Data”를 보시면, 어떤 Function(기능)인지 기록된 데이터로, 어떤 트랜잭션인지 확인이 가능합니다.
이더스캔에서는 해당 트랜잭션이 어떤 역할을 수행하는지 “Transaction Action”에 요약하여 표시해줍니다.

• “Add_liquidity” 트랜잭션

트랜잭션을 확인해보면, 꽤 복잡한데 결과적으로는 지갑에서 3000 DAI가 컨트랙트 주소로 넘어간 뒤 여러번의 이동이 있었던 것을 확인할 수 있습니다.
“Input Data”는 “Approve” 트랜잭션 정도의 길이지만, “Tokens Transferred”의 자산 전송 내역이 많기 때문에 수수료가 많이 나갔습니다.

3.3. Deposit 결과, 커브 “Profit”에서 확인하기

Deposit 트랜잭션이 모두 컨펌되었다면, 커브에서도 입금한 내용을 확인해보겠습니다.
커브 컴파운드 풀의 “Profit” 메뉴에서 입금된 자산을 확인할 수 있습니다.

• “Show in USD [Virtual profit]”에서는 달러 환산 금액으로 표기되며, “Show in tokens”를 체크하면, 토큰 기준 수량으로 확인할 수 있습니다.
• “Daily profit(unstable)”에서 하루 예상 수익이 표시되는데, 이 수익은 커브 컴파운드 풀의 “기본적인” 수익률이라고 볼 수 있습니다.
  앞서 커브 “Home”과 “Pool” 둘러볼 때 잠깐 언급했던 거래(Swap) 수수료와 풀 자체 특성(컴파운드라면 대차풀에 이용됨)에 의해 발생하는 예상 수익이 여기에 표시됩니다.
• 이후 진행할 과정인 CRV 마이닝을 진행하게 되면, “Pending CRV”, “Minted CRV”에도 금액 또는 수량이 표시되게 됩니다.
• “Total profit”에는 풀의 기본적인 수익과 CRV 마이닝 수익이 합산되어 표시됩니다.
• “CRV price”는 CRV 토큰의 현재가입니다.

3.4. Deposit 하고 받은 LP 토큰 확인하기

1. 커브 풀에 자산을 "Deposit"하면, 그 증표로 커브 LP(Liquidity Provider: 유동성 공급자) 토큰인 "compound LP token"을 받게됩니다.
유동성 풀에 제공한 내 자산에 대해 소유권을 주장할 수 있는 토큰이라고 보시면 되겠습니다.

2. 이더리움 블록체인 익스플로러 "이더스캔"에서 커브 컴파운드 풀에 DAI를 제공하고 받은 compound LP token인 "Curve.fi cDAI/cUSDC" 잔고가 잡힌 것을 확인할 수 있습니다.

• 이더스캔 주소 화면

• 이더스캔 “Curve.fi cDAI/cUSDC” 토큰 화면 — FILTERED BY TOKEN HOLDER

4. Curve DAO에 LP 토큰을 Deposit 해보자

여기까지 오는 길이 상당히 멀었죠. 수고했다는 말씀 전합니다. 다음 과정은 더 어렵습니다만, 이제부터 디파이의 진짜 시작이라 할 수 있으니 잘 따라와주세요.

커브에서 Minting(발행)한 LP 토큰을 Curve DAO(Decentralized autonomous organization: 탈중앙화된 자율조직)에 Deposit 하여, 커브 DAO에 기여하는 대가로 얻게되는 CRV 토큰(Curve DAO Token)을 일드파밍(Yield Farming: 이자농사)해보겠습니다.

앞서 예시로 DAI를 컴파운드 풀에 “Deposit”해서 LP 토큰인 “compound LP token”를 받았으니, 이어서 “compound LP token”를 Curve DAO에 직접 Deposit해보도록 하겠습니다.

4.1. Curve DAO가 뭔가요?

커브는 “Curve 둘러보기”에서 어떤 서비스인가 어느정도 이해하셨을텐데, 또 다른 생소한 용어가 나왔습니다.
“DAO”는 “Decentralized Autonomous Organization”의 약자로 “탈중앙화된 자율조직”으로 해석할 수 있습니다.
즉, “Curve DAO”는 커브의 탈중앙화된 자율조직입니다.

Curve DAO는 CRV(Curve DAO token) 토큰을 중심으로 작동되는데, CRV는 Curve DAO에서 통용되는 거버넌스(governance) 토큰입니다.
CRV는 거버넌스 운영에 있어 필요한 의사결정 사항을 제안하거나 이미 만들어진 제안에 투표하는 등의 권리를 가지는 토큰입니다.

4.2. Curve DAO 간단히 살펴보기

1. Curve 웹사이트의 “DAO” 메뉴를 클릭하면, “Curve DAO” 웹사이트(https://dao.curve.fi/)로 이동합니다.

2. “Curve DAO”는 커브 웹사이트의 서브 도메인으로 주소는 “https://dao.curve.fi" 입니다.
메뉴가 “Curve.fi”보다 더 많기 때문에 더 어려워 보이는데, 실제로도 어렵습니다.

본 콘텐츠로 모든 것을 알아보기에는 스크롤의 한계가 있어서, 메뉴별 간단히 살펴보겠습니다.

• (가로 세 줄 아이콘) 메뉴 버튼: 커브의 개별 풀을 이동할 수 있습니다.
• “Home”: Curve DAO 홈 화면입니다. 전반적인 “Gauge” 상태 확인과 CRV 및 LP 토큰 관련 기능을 작동할 수 있습니다.
  Curve DAO에서 “Gauge”(게이지, 직역하면 ‘계측기’)란 아주 간단하게 풀어 쓰자면, “Curve DAO에 커브 LP 토큰을 스테이킹하는 장소” 정도로 볼 수 있겠습니다. 이 게이지의 비중에 따라 CRV 토큰의 인플레이션이 결정됩니다.
  자세한 내용은 커브 가이드 “Understanding Gauges”(https://resources.curve.fi/base-features/understanding-gauges)를 참고하세요.

• “Curve”: Curve 웹사이트(https://www.curve.fi/)로 이동합니다.
• “DAO”: 커브 DAO에 올라온 제안서와 투표현황 등을 확인하고, 참여할 수 있습니다.

• “Gauge weight vote”: Gauge 비중 투표 관련 화면이 표시됩니다.

• “Calc”: “Gauge Boost Calculator”가 표시됩니다.

• “Locker”: CRV 토큰을 잠궈서(Lock) veCRV로 바꾸고, DAO에서 쓰이는 보팅 파워를 얻을 수 있습니다.

• “Minter”: Gauge별 CRV 인플레이션 비율에 해당하는 “Gauge relative weight” 비중을 확인하고, 연결된 지갑에서 Gauge로 Deposit된 LP 토큰의 비중도 확인할 수 있으며, 풀(Pool)별 Gauge에 LP 토큰을 스테이킹/언스테이킹하고, Gauge에서 CRV 토큰을 Claim(회수)를 통해 Mint(발행)할 수 있습니다. (Home 화면과 동일)

• “Vesting”: 초기 참여자에게 베스팅으로 지급된 CRV 토큰의 현황을 확인하고, Claim(회수)할 수 있습니다. (초기 참여하지 않았다면, 차트에 가로선만 보입니다.)

• “Stats”: CRV의 APY, 각 Gauge별 상태 및 비중 등의 그래프를 확인할 수 있습니다.

• “Contracts”: Curve DAO와 관련된 컨트랙트 주소를 확인할 수 있습니다.(주의: 절대 이 주소로 토큰을 직접 전송하면 안됩니다.)

• “Audits”: 컨트랙트 감사(Audit)에 대한 정보를 확인할 수 있습니다.

• “?”: 그 외 정보, 커뮤니티 링크 등을 확인할 수 있습니다.

4.3. Curve DAO 웹사이트에 지갑 연결하기

1. Curve DAO 웹사이트(https://dao.curve.fi)에 접속하면, 지갑을 연결하라는 Curve 웹사이트와 마찬가지로 “Select a Wallet” 팝업이 뜹니다.
Curve DAO 웹사이트는 Curve 웹사이트와 도메인이 다르기 때문에(DAO가 서브도메인) 다른 웹사이트로 취급하며, 지갑을 또 연결해야합니다.
메타마스크를 선택해 지갑을 연결해 보겠습니다.

2. 먼저 비밀번호를 입력해 메타마스크 잠금을 풉니다.

3. 메타마스크의 “1 of 2” 알림창에서 연결하려는 인터넷 주소와 메타마스크에 표시된 주소가 맞는지 확인하고, 연결하려는 지갑을 체크하고 “다음” 버튼을 클릭합니다.
“2 of 2”에서는 “이 사이트에 무엇을 허용해줄지” 체크박스의 내용을 확인하고 “연결”을 클릭합니다. (별도로 체크를 할 필요는 없음)

4. 지갑 연결이 완료되면 Curve DAO 웹사이트의 “Home” 화면이 표시됩니다.

4.4. Gauge에 LP 토큰 Deposit 하기

Curve DAO 둘러보기 과정에서 “Gauge”에 대해 간략히 소개드렸는데요.
Gauge는 커브 LP 토큰이 담기는 게이지, 가상의 공간 정도로 볼 수 있습니다.

이 Gauge는 각 풀(Pool)별로 있으며, “Gauge relative weight”의 비중에 따라 CRV 인플레이션이 정해지게 됩니다.
더 자세한 내용은 본 콘텐츠에서 다루기엔 너무 어려울 수 있어 이정도만 설명드리겠습니다.

앞의 과정에서 DAI를 Curve의 Compound 풀(Pool)에 입금해서 LP(Liquidity Provider: 유동성 공급자) 토큰인 “compound LP token”를 받았었는데요.
이제 “compound LP token”을 Curve DAO의 Compound Gauge에 “Deposit”하는 과정을 진행해보겠습니다.

LP 토큰의 “Deposit”이 완료되면, 거버넌스 토큰인 CRV(Curve DAO token)가 쌓이며, 이를 Claim(회수)함으로써 Mint(발행)할 수 있게 됩니다.
차근차근 진행해보겠습니다.

1. Curve DAO의 “Minter” 메뉴로 이동합니다. (“Home”과 화면구성은 같지만, 정확한 기능의 메뉴에서 작업을 수행하겠습니다.)
Minter를 직역하면 ‘발행자’인데, Gauge에 LP 토큰을 입금해 Curve의 거버넌스 토큰인 CRV를 발행하는 기능을 이 메뉴에서 수행할 수 있습니다.

2. 스크롤을 조금 내려서, “compound Liquidity gauge”까지 내려옵니다.
앞의 과정에서 컴파운드 LP 토큰을 만들었기 때문에 컴파운드 LP 토큰의 Gauge에서 작업을 이어서 진행해야 합니다.

“compound Liquidity gauge” 간단히 살펴보겠습니다.

• “CRV APY”: Gauge에 LP 토큰을 입금해 받게되는 CRV 토큰의 현재 시세 기준 예상 년수익률입니다.
• “Gauge relative weight”: CRV 전체 인플레이션 중에 이 compound Liquidity gauge가 차지하는 비중입니다.
• “Minted CRV from this gauge”: 이 Gauge에서 Mint(발행)된 CRV 수량입니다.(접속한 지갑 기준)
• “Boost”: 부스트 배수로 Curve 웹사이트의 “Use CRV”에서 관련 내용을 확인할 수 있습니다. 기본값은 1입니다.
• “Balance”: 해당 Gauge에 아직 “Deposit”되지 않은 LP 토큰 잔고가 잡히는 것을 확인하실 수 있습니다.
  밑줄친 잔고를 클릭하면, 아래 “Amount” 칸에 정확한 전체 잔고가 입력됩니다.
• “Amount”: “Deposit”할 잔고 수량을 입력하는 칸으로, 기본값으로 전체 수량이 입력되어 있습니다.
  입력칸 아래 퍼센트(%) 슬라이더를 조절하거나 직접 입력해 수량을 변경할 수 있습니다.
• “Infinite approval”: 이 트랜잭션도 앞서 풀(Pool) Deposit과 마찬가지로 “Approve” 트랜잭션이 있어야 합니다.
  이 항목을 체크하고 “Deposit”하면, 이후 동일한 Gauge에 한해 “Approve” 트랜잭션을 추가로 할 필요가 없습니다.

3. 필자는 이제 여기서 compound LP token 전체를 compound Liquidity gauge에 “Deposit”하려고 합니다.
“Amount”에 자동으로 입력된 숫자가 정확한지 두번 세번 확인해보고 “Deposit”을 진행해보겠습니다.
블록체인 위의 모든 거래는 불가역적이라 실수를 번복할 수 없고, 잘못된 트랜잭션조차 수수료가 나가기 때문에 숫자 입력은 특히 주의를 기울여 작업해야합니다.

잠깐! 숫자가 너무 정확하게 끊어지면 의심을 해봐야합니다.
필자는 “Balance”의 밑줄친 수량을 직접 클릭해 정확한 Amount를 입력했습니다.
잔고에 없는 숫자가 입력된 상태로 트랜잭션을 발생시키면 에러나게되며, 이더리움 수수료는 수수료대로 나갈 수 있습니다.

4. “Gas price”는 “Instance”를 체크해 진행하겠습니다. 가스 가격은 메타마스크 지갑에서 트랜잭션 발생 직전에도 수정할 수 있습니다.

*가스 가격은 이더리움 네트워크 사정에 따라 수시로 달라질 수 있으니, 표시된 숫자는 예시로 보시기 바랍니다.

5. “Deposit” 트랜잭션을 발생시키기 직전, 모든게 완벽한지 확인합니다.
적당한 가스 가격인지, 정확한 수량인지, Infinite approval은 체크할건지, CRV APY가 적당한지까지 최종적으로 판단하고 “Deposit”을 진행하면 됩니다.

*Infinite approval 체크는 선택사항이며 필수가 아닙니다.

6. “Deposit”을 클릭하는 즉시, 예상 전송 수수료와 메타마스크 알림창이 뜹니다. 앞서 진행했던 풀(Pool) Deposit과 크게 다르지 않습니다.
메타마스크 알림창에 표시된 내용을 확인하고, 수수료를 정하고, “Allow~” 트랜잭션(“Approve” 트랜잭션)을 “승인”합니다.

7. 이어서 실제 토큰이 이동하는 “DEPOSIT” 트랜잭션에 대한 메타마스크 알림창이 뜹니다.
표시된 수수료를 확인하고, 변경이 필요하다면 편집하고, “승인”을 클릭합니다.

만약 트랜잭션이 너무 오래 “펜딩”(Pending, 지연) 된다면, “속도 향상”을 할수도 있습니다.
“속도 향상”을 클릭하면 수수료를 변경해 트랜잭션을 덮어쓸 수 있습니다.

8. “Approve”와 “Deposit” 두 트랜잭션이 모두 컨펌났습니다.
메타마스크의 “Activity”에서 완료된 트랜잭션을 확인할 수 있습니다.

9. Curve DAO에는 어떤 변화가 생기는지 살펴보겠습니다.

“Minter” 또는 “Home” 메뉴에 “Gauge allocation”이라는 새로운 그래프가 하나 등장합니다.
allocation을 직역하면 할당량 또는 배당량인데요. 연결된 지갑에 할당된 Gauge의 비율이라고 보시면 되겠습니다.
현재는 하나의 Gauge에만 LP 토큰이 입금되어 있기 때문에 원 하나만 덩그러니 있는데, 더 다양한 Gauge에 LP토큰을 예치하게되면 그래프에 다른 조각들이 생기게 됩니다.

또한, “compound Liquidity gauge”에는 좌우로 칼럼이 나뉘고, Deposit된 LP 토큰의 수량과 Withdraw(출금)할 수 있는 Amount(수량)칸과 “Withdraw” 버튼이 생겨있습니다.
맨 아래에 드디어 “Claim 0.01 CRV” 버튼이 생겼네요. 드디어 이 Gauge에 Claim(회수) 가능한 CRV가 쌓였습니다!

4.4.1. Curve DAO Deposit 트랜잭션 살펴보기

블록체인 위에서는 어떻게 기록이 남았나 지갑과 트랜잭션을 이더스캔에서 살펴보겠습니다.

• 지갑 살펴보기

1개로 시작한 ETH는 이제 약 0.89개입니다. 전체 거래에서 ETH의 전송은 없었고, 트랜잭션 수수료로 사용되었습니다.
“Token”이 1종류 있는데 가치가 0으로 표시됩니다. 기존 LP 토큰은 소수점 아주 적은 숫자만큼 남았습니다. (0.000000000000330678개)
“Curve.fi: cCrv”로 시작하는 트랜잭션 2개가 신규 생성되었습니다. 하나가 “Approve”, 다른 하나가 “Deposit” 입니다.

• “Approve” 트랜잭션

전송된 토큰은 없고, “Function: approve”에 대한 데이터와 소량의 ETH 수수료가 사용되었습니다.
“Transaction Action”을 보면, 이 트랜잭션을 통해 Curve DAO의 compound Liquidity gauge에서 cDAI+cUSD에 해당하는 compound LP token의 “Trade”가 허용되었음을 알 수 있습니다.

• “Deposit” 트랜잭션

“Tokens Transferred”를 보면, compound LP token이 compound Liquidity gauge 주소로 이동한 것을 확인할 수 있습니다.
거래 수수료는 앞서 발생한 “Approve”보다 비싼 약 0.01 ETH가 소모되었습니다.

4.5. 기다림의 시간

여기까지 따라오느라 수고많으셨습니다. 이제 기다림의 시간이 남아있습니다.

기다리면 Curve DAO에 입금된 LP 토큰에 상응하는 CRV 토큰이 Claim 가능한 상태로 누적됩니다.
사용자는 “Claim”(회수) 버튼을 클릭해 CRV를 Mint(발행)해 받아갈 수 있습니다.

어느 시점에 어느 주기로 Claim 할지, 회수한 CRV를 홀딩할지 매도할지 모든게 사용자가 의사결정해야할 부분입니다.

5. 정리: Gauge Withdraw, CRV Claim, Pool Withdraw

정리 순서는 앞에서 벌려둔 것의 역순이라고 보시면 됩니다.

(1) Curve DAO의 Liquidity Gauge에 Deposit(입금)해둔 LP 토큰을 “Withdraw”하고, (2) Liquidity Gauge에 생긴 CRV 토큰을 “Claim”하고, (3) 지갑으로 돌아온 LP 토큰을 Curve Pool에서 “Withdraw” 해서 원래 입금했던 토큰으로 빼오는 과정을 진행하겠습니다.

필자는 앞에서 말씀드린 “기다림의 시간”을 본 게시물의 빠른 작성을 위해 아주 짧게 정해, 정리를 진행하는 점 참고부탁드립니다.

5.1. Gauge Withdraw

Liquidity Gauge에서 LP 토큰을 출금해보겠습니다.

*참고로 LP 토큰의 Gauge Withdraw(출금)을 CRV Claim(회수)보다 먼저 진행하는 이유는, CRV 자투리가 생기지 않게하기 위함입니다.
매 블록마다 Gauge에 Deposit(입금)된 LP 토큰을 기준으로 CRV 보상이 발생하므로, CRV 자투리 없이 완전히 정리하기 위해서는 Gauge의 LP를 먼저 출금해야합니다.
(만약, LP 토큰은 그대로 Gauge에 두고, 발생한 CRV만 수시로 정리하고 싶다면 Claim만 진행하면 됩니다.)

1. Curve DAO — “Minter”(https://dao.curve.fi/minter/gauges) Gauge에 입금한 LP 토큰을 “Withdraw” 합니다.
LP 토큰 입금과 마찬가지로 수량을 정확히 입력하고(“Balance:”에 밑줄쳐진 잔고 클릭), “Withdraw” 버튼을 클릭해 출금하세요.

2. “WITHDRAW” 트랜잭션이 메타마스크 알림창으로 뜹니다. 수수료 등을 확인하고 “승인”을 진행합니다.

3. 트랜잭션이 완료되면, 지갑으로 LP 토큰이 돌아온 것을 확인할 수 있습니다.

• “WITHDRAW” 트랜잭션

“Token Transferred”를 확인해보면 “Curve.fi: cCrv Gauge”에서 지갑주소로 LP 토큰이 전송된 것을 확인할 수 있습니다.

5.2. CRV Claim

Gauge에서 LP 토큰을 빼왔으니, 더이상 CRV 토큰이 생기지 않습니다.
이제 CRV 토큰을 Claim(회수)해보겠습니다.

1. Curve DAO “Minter”(https://dao.curve.fi/minter/gauges) 페이지의 Gauge에서 CRV를 회수해 보겠습니다.
“Gauge” 섹션의 하단에 “Claim 00 CRV” 버튼을 클릭하면 회수할 수 있습니다.

2. “MINT” 트랜잭션이 메타마스크 알림창으로 뜹니다. 수수료 등을 확인하고 “승인”을 진행합니다.

3. 트랜잭션 승인 완료 후, 커브 DAO Minter 화면을 새로고침 해보면 “Minted CRV from this gauge”에 CRV가 Mint(발행)된 수량이 표시된 것을 확인할 수 있습니다.

또한, 지갑으로 CRV 토큰이 입금된 것을 확인할 수 있습니다.

• “MINT” 트랜잭션

“Interacted With(To)”를 확인해보면 “Curve.fi: Token Minter” 계약이 실행되었으며, “Token Transferred”를 보면, 0x0000…주소에서 CRV 토큰이 지갑으로 전송된 것을 확인할 수 있습니다.
0x0000…주소(https://etherscan.io/address/0x0000000000000000000000000000000000000000)는 주인이 없는 토큰 발행용(또는 소각용) 주소라고 보시면 되겠습니다.

5.3. Pool Withdraw

이제 Curve DAO에서 할 일은 다 끝났습니다.
나머지는 Curve.fi의 개별 풀(Pool)에서 LP 토큰을 제거(Remove)하여 처음에 Deposit했던 토큰을 빼오는 과정이 남았습니다.
이 과정을 커브에서는 Pool에서의 “Withdraw”라고 합니다. (다른 디파이 서비스에서는 Pool에서의 LP 토큰 “Remove”라고도 부릅니다.)

1. 이제 Curve 웹사이트의 커브 풀(Pool)의 “Withdraw”(https://www.curve.fi/compound/withdraw)에서 LP 토큰으로 묶여있는 원래 토큰을 빼오겠습니다.

• “Share of liquidity”에서 보유 LP 토큰의 몇 % 비중으로 출금할지 정할 수 있습니다.
• “Withdraw % in”에서 리저브(Reserves, 해당 풀의 보유잔고)의 비중 그대로 출금하거나(Combination of all coins: 기본값), 원하는 토큰 종류로 선택할 수 있습니다.
  본인이 거래하기 수월한 토큰 한 종류로 출금하는게 유리하다면, 직접 선택해야 합니다.
• “Withdraw” 버튼을 클릭하면, LP 토큰을 보내주고, 풀(Pool) 안에 든 토큰을 꺼내올 수 있습니다.
  (Curve DAO에서 진행가능한 “Claim”, “Unstake from gauge” 트랜잭션도 Curve의 “Withdraw” 메뉴에서 진행할 수 있습니다.)

2. 리저브의 비중대로 출금할수도 있겠지만, 사용자의 필요에 맞게 토큰 한 종류를 선택하여 출금할 수 있습니다.
본 콘텐츠에서는 최초에 입금을 진행한 토큰인 DAI이기 때문에, 아래 스크린샷 처럼 “Withdraw % in”에서 DAI를 선택해 출금을 진행해 보겠습니다.
(그 외 “Max slippage”와 “Infinite approval”을 시장상황이나 앞으로 투자 계획 등에 따라 기본 설정을 변경했습니다.)

3. “Withdraw”를 클릭하면, 총 2개의 트랜잭션이 순서대로 발생합니다.
첫번째는 LP 토큰에 대한 “Approve” 트랜잭션이며, 두번째는 “REMOVE_LIQUIDITY_ONE_COIN”이라는 트랜잭션입니다.

4. 두 트랜잭션을 순서대로 승인하면, 커브 풀에서 DAI가 출금되어 지갑으로 돌아옵니다.
다만, 처음 입금한 수량과는 차이가 발생했는데, 이는 DAI 외에 다른 자산이 섞인 풀에서 DAI로만 회수하는 과정에서 slippage 영향을 받아서입니다.

• “Approve” 트랜잭션

이제 몇 번의 “Approve” 트랜잭션을 봤으니, 조금은 익숙해졌을 것입니다.
이 지갑에 있는 LP 토큰인 “cDAI+cUSDC”에 대한 컨트랙트 거래를 승인한다는 내용의 트랜잭션입니다.

• “REMOVE_LIQUIDITY_ONE_COIN” 트랜잭션

트랜잭션이 꽤 복잡해 보이고, 수수료도 꽤 높은 편입니다.
“Transaction Action”을 살펴보면, 컴파운드에 공급한 DAI와 USDC로부터 발생한 컴파운드 거버넌스 토큰 COMP를 각각 Collected 했고, 컴파운드에서 DAI를 출금했습니다.
“Tokens Transferred”에는 무려 9번의 전송이 포함되는데, 이 내용이 “Transaction Action”의 전송을 풀어놓은 내역이라 이해하시면 됩니다.

결과적으로 LP 토큰을 커브의 컴파운드 풀로 돌려보내고, 커브 컴파운드 풀에서는 돌려받은 LP 토큰 만큼에 해당하는 잔고가 컴파운드를 거쳐 최종적으로 사용자가 요청한 토큰인 DAI로 출금되었습니다.

5.4. 최종 잔고 비교

이렇게 실제 전송을 통해 CRV 토큰의 Claim과 LP 토큰의 출금까지 모두 알아봤습니다.
이제 최종 잔고를 비교해보며 디파이 탐험을 마무리짓겠습니다.

• ETH 수수료: 약 0.1734 ETH 지출 (약 75,000원) / 총 8회 트랜잭션, 1회당 평균 약 0.02 ETH (약 8,600원) (ETH 시세: 작성시점 43만원 기준)
• DAI는 LP에서 출금되면서 슬리피지(slippage)로 인해 일부 원금 손실 — 약 0.047%
• CRV 발행(Mint)량 19.137개로 약 11,000원 — Curve DAO Gauge에 LP 예치한 기간 7일에 대해 APY로 환산하면 약 16%로 진입시 CRV APY와 유사한 값이 나왔습니다.

정리하자면, 이번 디파이 탐험을 통해 짧은 기간(7일) 예치하다보니 고정비용으로 볼 수 있는 ETH 트랜잭션 수수료가 CRV 발행으로 얻은 수익을 상회하여 일부 손실이 났습니다. 다만, ETH 트랜잭션 수수료는 기간이 늘어남에 따라 증가하는 값이 아니며, CRV 발행량은 시간이 지남에 따라 증가하게되므로 이 부분을 참고해주시면 되겠습니다.

*CRV의 시세와 발행량에 의한 Gauge의 CRV APY 또한 계속 변동하기 때문에 확정적으로 수익이 날 것이라고 말씀드리기 어렵습니다.

6. 마치며

디파이 탐험을 함께해주신 여러분의 블록체인에 대한 관심과 열정에 박수보냅니다.
블록체인을 이렇게 글과 그림으로 살펴보는 것과 실제로 해보는 것은 엄청난 차이가 있습니다. 분명히 헤맬 것이고, 어렵고, 어색할 것입니다.
하지만, 도전과 경험을 통해 블록체인과 디파이에 대해 알아가다보면, 어느새 블록체인 생태계의 일원이 되실 수 있습니다.

본 콘텐츠가 어떠셨는지요? 어떻게 와닿을지 무척 궁금합니다.
코인원의 디파이 탐험 콘텐츠는 시리즈로 준비했으니, 재밌게 보셨다면 다음편도 많은 기대와 관심 부탁드립니다.

감사합니다.

*코인원 크립토 뉴스(https://coinone.co.kr/talk/)에서 코인원의 업계 뉴스부터 전문가의 트레이딩 분석, 디파이 관련 리서치까지 다양하게 만나보실 수 있습니다.

DeFi 탐험 유의사항

• 본 게시물은 DeFi의 다양한 서비스를 소개하는 취지에서 작성되었습니다.
• 본 게시물에 수록된 내용은 자료 작성자가 신뢰할 수 있는 자료 및 정보로부터 얻은 것이나 오차가 발생할 수 있으며, 당사는 어떠한 경우에도 정확성이나 완벽성을 보장하지 않습니다.
• 본 게시물에 나타난 모든 의견은 자료 작성자의 개인적인 견해로, 외부의 부당한 압력이나 간섭 없이 작성되었습니다.
• 본 게시물은 투자를 유도하거나 권장할 목적이 아닙니다.
• 본 게시물의 내용은 원본 손실의 가능성이 존재하며, 게시물에 표시된 수익률은 변동성이 있으며 당사는 이를 보장하지 않습니다.
• 본 게시물의 이미지에 표시된 스크린샷 화면은 실제 웹사이트 화면과 언제든지 일부 또는 전체가 변경될 수 있으며 당사는 이를 보장하지 않습니다.
• 본 게시물에 따라 투자를 진행하더라도 사용자의 사용 미숙, 실수, 복구키 유실 등 여러가지 이유로 자금의 원본을 전부 손실할 가능성이 있습니다.
• 본 게시물은 어떠한 경우에도 고객의 투자 결과에 대한 법적 책임 소재의 증빙 자료로 사용될 수 없습니다.
• 본 게시물의 저작권은 코인원에 있고, 어떠한 경우에도 코인원의 허락없이 복제, 대여, 재배포될 수 없습니다.
• 당사는 본 게시물의 해당 DeFi 서비스와 아무 관련이 없습니다.
• 당사는 본 게시물의 내용에 의거하여 행해진 일체의 투자 행위에 대하여 어떠한 책임도 지지 않습니다.

[DeFi 탐험 #1] Curve was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

들어가며

안녕하세요. 코인원 Platform Engineer 허민입니다. Amazon의 EKS 한국 region 오픈 후 코인원은 자사의 핵심 서비스들을 EKS로 이전하는 작업을 진행하였습니다.

그러던 중에 Ingress controller 구성 과정에서, Nginx controller와 AWS ALB를 지원하는 AWS ALB Ingress Controller에서의 선택에 대해 아래와 같은 고민을 하게 되었습니다.

• 실제 서비스에서 별다른 문제 없이 동작할 수 있을까?
• 기존에 사용하던 LB구성을 EKS 환경에서도 그대로 사용 할 수 있는가?
• 구성 가이드 및 사용 예제에 대한 자료가 충분한가?

결국 최종 결정은 AWS 환경에 구성과 운영 이점이 있는 ALB Ingress controller를 선택하게 되었습니다.

이번 글에서는 ALB Ingress Controller를 구성하면서 경험했던 이슈들과 활용 팁을 소개하고자 합니다.

ALB Ingress Controller Architecture

ALB Ingress Controller를 구성하기 전에 먼저 동작을 이해해 보도록 하겠습니다.

해당 내용은 AWS Open Source Blog의 내용에서 발췌하였습니다.

1. Ingress Contriller는 API 서버로 부터 ingress event를 감시합니다. ingress 자원이 확인되면 AWS에 리소스를 생성합니다.
2. Ingress 리소스에 대해 ALB가 생성 됩니다.
3. Ingress 리소스에 할당된 백엔드에 대해 Target Group이 생성 됩니다.
4. Ingress 리소스에 지정된 모든 포트에 대해 Listener가 생성됩니다. 포트를 지정하지 않으면 기본값으로 80 또는 443이 사용됩니다.
5. 각각의 Ingress 리소스에 지정된 Path에 따라 Role이 생성 됩니다. 이후에는 특정 경로로 트래픽이 TargetGroup으로 라우팅 됩니다.

또한 ALB Ingress Controller는 Instance mode와 IP mode의 두가지 traffic mode를 지원하며, kubernetes에서 Ingress 생성할 때 annotations 항목에 alb.ingress.kubernetes.io/target-type을 선언하여 명시적으로 지정할 수 있습니다.

• Instance mode: 외부에서 수신된 트래픽은 ALB를 거쳐 서비스 용으로 열린 NodePort에 도달합니다. (라우팅 되기 위한 어플리케이션의 서비스 타입을 NodePort로 지정해애 됨)
• IP mode: 외부에서 수신된 트래픽은 ALB를 거쳐 클러스터 내의 컨테이너 포트로 직접 도달합니다. 이 모드를 사용하려면 Kubernetes 클러스터의 네트워킹 플러그인이 ENI의 보조 IP 주소를 사용할 수 있어야 합니다.

ALB Ingress Controller 배포

ALB Ingress Controller를 사용하기 위해서는 kubernetes 환경에 해당 pod를 생성해야 합니다. pod는 helm chart를 이용해 간편하게 설치가 가능합니다.

설치에 앞서 AWS와 kubernetes의 리소스에 접근하기 위해 아래와 같이 role을 생성 및 적용해 주어야 합니다.

• IAM Role 생성 ( iam-policy.json 적용 )
• EKS worker node에 위에서 생성한 IAM policy 적용
• kubernetes RBAC Role 적용

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.0.0/docs/examples/rbac-role.yaml

• ALB Ingress Controller helm chart 설치

helm install --name ingress-controller \
    --namespace kube-system \
    --set awsRegion=<Region_Name> \
    --set awsVpcID=<Cluster_VPC_ID> \
    --set clusterName=<EKS_CLUSTER_NAME> \
    --set extraArgs."feature-gates"='waf=false' \
    incubator/aws-alb-ingress-controller

이 때, aws상에서 waf를 사용하지 않을 경우에는 extraArgs로 ‘waf=false’ 옵션을 추가해 주어야 합니다.

Ingress 정의

Ingress Controller의 설치가 완료되면 Ingress annotation을 정의하는 것으로 ALB를 관리할 수 있습니다.

코인원의 경우 서비스별로 ingress를 생성하지 않고 internal과 external 역할을 하는 ingress만 각각 생성하여 서비스 역할에 맞게 host 라우팅을 추가하였습니다.

또한, target type을 instance로 지정하여 각 worker node에 node port가 할당되고 해당 host와 node port로 라우팅이 되도록 설정하였습니다.

apiVersion: extensions/v1
kind: Ingress
metadata:
  name: "external-ingress"
  labels:
    app.kubernetes.io/name: "external-ingress"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/subnets: subnet-02xxxxxx,subnet-0dxxxxxx
    alb.ingress.kubernetes.io/target-type: instance
 
spec:
  rules:
    - host: "a.coinone.co.kr"
      http:
        paths:
          - path: /*
            backend:
              serviceName: "coinone-a"
              servicePort: 80
    - host: "b.coinone.co.kr"
      http:
        paths:
          - path: /*
            backend:
              serviceName: "coinone-b"
              servicePort: 80  
    - host: "c.coinone.co.kr"
      http:
        paths:
          - path: /*
            backend:
              serviceName: "coinone-c"
              servicePort: 80

다만, 이 때 kubernetes namespace에 대한 제약사항이 있기 때문에 ALB를 이용해 접근해야 되는 서비스는 namespace 마다 Ingress를 생성해야 합니다.

위의 구성을 적용하면 ALB와 target group은 생성이 됩니다. 하지만 어떤 서비스들은 health check가 되지 않아 worker node의 target port가 unhealthy 상태 일 수 있습니다.

이를 해결하기 위해서는 각 service에 healthcheck-path annotation을 추가해야 합니다.

apiVersion: v1
kind: Service
metadata:
  name: "coinone-a"
  labels:
    app: "coinone-a"
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /healthy
spec:
  type: "NodePort"
  ports:
    - name: "http"
      port: 80
      targetPort: 80
      protocol: TCP

추가적인 Ingress 정의

위의 설정으로 ALB를 이용한 서비스 구성은 완료가 되었습니다만, ALB Ingress Controller를 좀 더 잘 사용하기 위해 아래 설정을 추가하도록 합니다.

공통 security-group 지정

위의 구성에서는 ingress가 생성되면 해당 worker node에 임의의 security group이 생성이 됩니다. 그런데 ingress가 계속 늘어나게 되면 어느순간 EC2 instance에 할당된 security group limit에 도달하게 됩니다.

위와 같은 문제를 방지하면서 불필요한 security group 생성을 막기위해 아래와 같은 공통 security-group annotation을 생성하고 Ingress annotation에 추가합니다.

apiVersion: extensions/v1
kind: Ingress
metadata:
  name: "external-ingress"
  labels:
    app.kubernetes.io/name: "external-ingress"
  annotations:
    kubernetes.io/ingress.class: alb
    ...
    alb.ingress.kubernetes.io/security-groups: sg-0f00000000000

SSL Certificate 지정

AWS Certificate Manager를 사용하고 있다면 아래 설정으로 ALB Controller에 SSL 인증서를 지정할 수 있습니다.

apiVersion: extensions/v1
kind: Ingress
metadata:
  name: "external-ingress"
  labels:
    app.kubernetes.io/name: "external-ingress"
  annotations:
    kubernetes.io/ingress.class: alb
    ...
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx:certificate/xxxxxxx
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-2016-08

Redirection 지정

ALB의 redirection 기능을 사용하기 위해서는 아래와 같이 action annotation 설정과 host rule을 지정해야 합니다.

apiVersion: extensions/v1
kind: Ingress
metadata:
  name: "external-ingress"
  labels:
    app.kubernetes.io/name: "external-ingress"
  annotations:
    kubernetes.io/ingress.class: alb
    ...
    alb.ingress.kubernetes.io/actions.redirect-www: '{"Type": "redirect", "RedirectConfig": { "Host": "www.coinone.co.kr", "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
spec:
  rules:
    - host: "coinone.co.kr"
      http:
        paths:
          - path: /*
            backend:
              serviceName: redirect-www
              servicePort: use-annotation

또한 Protocol Rule을 사용한 redirection도 가능한데, 가장 많이 사용하는 https redirect의 경우에는 아래와 같이 설정이 가능합니다.

apiVersion: extensions/v1
kind: Ingress
metadata:
  name: "external-ingress"
  labels:
    app.kubernetes.io/name: "external-ingress"
  annotations:
    kubernetes.io/ingress.class: alb
    ...
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
  hosts:
    - host: "coinone.co.kr"
      paths:
        - path: /*
          backend:
            serviceName: ssl-redirect
            servicePort: use-annotation
        - path: /*
          backend:
            serviceName: coinone-aml
            servicePort: 80

마무리하며

Kubernetes 환경에서는 NGINX Ingress Controller를 선호하시는 분들이 많으실꺼라 생각이 됩니다.

코인원에서는 ALB의 가장 큰 이점인 호스트 기반 또는 경로 기반 라우팅을 이용하기 위해서 ALB Ingress Controller를 선택하기는 했지만, 저희가 EKS 서비스를 구축할 당시에도 ALB Ingress Controller는 third party project에서 정식 버전으로 넘어온 지 얼마 되지 않아서 프로덕션에서의 안정성을 보장할 수 없었습니다. 실제 저희가 겪은 문제 중에도 ALB Ingress controller에서 에러가 발생하면서 pod의 메모리 사용량이 계속 증가하는 것을 목격하였고 이를 해결하기 위해 고생했던 기억이 있습니다.

그럼에도 불구하고 AWS 서비스 환경에서 ALB가 주는 편리한 옵션들 (security group 설정, health check 설정, SSL 인증서 지정 등)과 지속적으로 업데이트 되는 신규 추가 기능(로드밸런싱 알고리즘 지정, EKS Fargate mode IP 지원)의 이점을 얻을 수 있는 ALB Ingress Controller는 좋은 선택지라 생각이 됩니다.

AWS EKS에서 ALB Ingress Controller 활용기 was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

코인원이 정의하는 ‘일하기 즐거운 환경’ 두번째! feat. 랩터 프로젝트.​

2019년 3월 11일. 그러니까 일 년 전 작년 이맘때 즈음 코인원은 창립 이래 역사상 큰 프로젝트를 성공적으로 마치게 됩니다. 이 프로젝트가 진행되는 약 2달여의 시간 동안은 밤/낮, 주말/공휴일 없이 모든 에너지를 쏟아냈던 기간이었다고 하는데요.

도대체 어떤 이유에서였을까요?

코인원은 2014년 2월 설립된 스타트업입니다. 올해로 창립 6주년을 맞이했고요. 가상자산(암호화폐) 시장이 급속도로 커가면서 코인원의 이용자 수도 빠르게 증가했습니다. 이와 함께 여러 문제들도 발견되기 시작했는데요. 빠른 해결이 필요했습니다.​

무엇보다 가장 시급한 이슈는 바로 코인원의 심장 ‘엔진’의 성능을 강화하는 것이었습니다. 사실 코인원은 엔진 개발의 중요성과 필요성을 오래전부터 인지하고 있었고, 실제로 서버 엔진 전문기업 아이펀팩토리와 ‘코인원코어(Coinone Core)’를 공동 개발하기도 했습니다.

하지만 정작 코인원 거래소의 적용은 이런저런 이유로 계속 미뤄지게 됩니다. 더 이상 늦출 수 없었습니다. 그렇게 코인원은 2019년 첫 프로젝트 시작합니다. 코인원 거래소에 차세대 엔진 코인원코어를 심는, 이름하여 ‘랩터(Raptor)TF’. TF 규모는 약 30여 명. 가용할 수 있는 범위 내에서 최대한의 리소스를 투입했습니다. 그만큼 랩터TF는 중요했기 때문입니다.

“왜 TF 이름을 ‘랩터’로 결정했나요?”

조PM: 차세대 엔진이 적용된 이후 사용자가 서비스를 이용하며 가장 크게 체감할 수 있는 부분은 ‘속도’라고 판단했습니다. 당시 제 첫째 아들이 동물도감에 푹 빠져있었는데요. 동물도감에서 말하기를 지구상에서 가장 빠른 동물로 ‘랩터’를 지칭하고 있습니다. 저희 TF 성격과 딱 맞아 떨어지더라고요.

​구CO: 전투기 중에서 가장 빠른 기종을 ‘랩터’라고 부릅니다. 랩터 전투기는 최신 기술의 총 집합체이며, 아주 정교하고 정밀하게 만들어졌다고 하네요. 차세대 엔진을 가장 잘 표현하는 단어라고 생각했습니다.

랩터 이야기 더보기​

자, 그렇다면 랩터TF에 의해 장착된 차세대 엔진은 어떤 성능을 자랑할까요?

코인원코어는 초당 300만 건 이상의 거래 체결 처리가 가능한 고성능 엔진입니다. 수백 대의 서버로 수평 확장이 가능한 분산시스템을 갖추고 있는데요. 서비스 중단 없이 거래 엔진의 확장과 신규 가상자산(암호화폐) 상장도 가능해졌습니다. 또한 예상치 못한 장애 상황에서도 별도의 점검 없이 실시간으로 대응할 수 있게 되었고요.

엔진의 성능만 끌어올리고 끝낼 프로젝트는 아니었습니다. 서비스를 안정적으로 제공할 수 없다면 그 어떤 성능도 애초에 쓸모없을 터이니까요. 랩터TF는 서비스 안정성을 높이기 위해 서비스들의 마이크로화라는 아키텍처 수준의 처방을 내렸습니다. 기존의 모놀리스 코드 베이스를 한땀 한땀 분리하는 작업이 고통스러울 것은 자명했지만, 보다 쉬운 유지보수와 좀더 효과적인 최적화, 그리고 무중단 서비스 제공이 가능케 될 것이라는 기대를 가지고 용감하게 추진했습니다.​

새로운 아키텍처는 운영 방식의 혁신도 필요로 했습니다. 마이크로 서비스 아키텍처에 가장 어울리는 운영 방식은 역시 컨테이너화였고, 이에 쿠버네티스(Kubernetes)를 오케스트레이션 도구로 선택하고 아마존 EKS 플랫폼에 환경을 구축했습니다. 더불어 뉴렐릭(Newrelic)을 도입하여 모니터링도 강화했습니다.

컨테이너 오케스트레이션이란? 개별 구성 요소와 애플리케이션 계층의 작업을 정리하는 과정을 의미합니다.

아마 한국 리전에 ‘Amazon EKS(Kubernetes Management Service)’가 오픈한 뒤, 이를 가장 빠르게 도입한 국내 기업이 바로 코인원일 겁니다. 배포와 운영에 관련된 대부분의 작업을 코드화하여, 기존에는 GUI를 통해 반복적으로 수동으로 작업해야 했던 불편함과 실수 가능성을 없앨 수 있었습니다.

이렇게 성능과 안정성이라는, 트레이드-오프 관계에 있는 토끼 두 마리를 동시에 잡으려는 랩터TF의 무쌍함은 결국 현재의 쾌적하고 신뢰할 수 있는 코인원 서비스를 탄생시켰습니다.

여기에 한 마리의 토끼를 더 잡아야 했습니다. 바로 팀워크. 랩터TF는 PM, 개발자, 디자이너 등 코인원 인력의 ⅓. 약 30여 명이 모인 대규모 프로젝트였습니다. 단기간 내에 결과물을 만들어 내야 했기 때문에 말 그대로 물 흐르듯 프로젝트가 진행되어야 했는데요. 효율적인 의사소통을 바탕으로 빠른 결정을 해야만 했습니다.

그래서 도입한 ‘데일리 스탠드업 미팅’. 말 그대로 매일 랩터TF 전체인원이 모여 서서 진행하는 미팅으로, 각자 현재 어떤 업무를 수행 중인지, 진행 상황은 어떠한지, 늦어지고 있다면 왜 늦어지는지 등을 빠르게 공유하고, 결정이 필요한 사항에 대해서는 신속하게 의사결정을 내려 모두가 같은 호흡으로 TF가 가동될 수 있게끔 했습니다.​

결과적으로 데일리 스탠드업 미팅은 서로 투명하게 소통하고 적절한 피드백을 제안함으로써 랩터TF가 삐그덕거림없이 전진할 수 있도록 도와줬는데요. 수평적인 협업은 같이의 가치를 느끼게 해줬고 적재적소의 훌륭한 피드백은 창의적이면서도 효율적인 업무가 가능할 수 있도록 해줬습니다.

랩터TF의 성공적인 종료는, 어려운 과제도 함께 머리를 맞대고 나아가면 해낼 수 있다는 믿음과 이를 통해 서로에 대한 신뢰가 두터워졌으며, 특히, 우리 결과물에 대한 자부심과 책임감이 더욱 강해졌는데요. 실제로 코인원은 랩터TF 이후 더 단단해진 서비스를 만들어내고 있습니다.

그리고 코인원은 우리와 함께할 개발자를 찾고 있습니다.

코인원이 정의하는 ‘일하기 즐거운 환경’ was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Angular를 포함한 많은 Front End Framework는 Browser상에서 구현하기 힘든 복잡한 로직들을 쉽게 구현합니다. 만약 Framework 없이 개발을 한다고 가정해볼까요? Framework를 사용했을 때 신경쓰지 않았던 부분들을 하나하나 살펴봐야하고 개발 시간이 더 늘어날 것입니다. 이렇게 저를 포함한 많은 프론트엔드 개발자 분들은 편안함에 익숙해져있습니다. ‘프레임워크가 알아서 해주겠지.’라고 생각하고 넘어가는 것들이 있죠. 그 중 하나가 바로 성능 최적화입니다.

예를 들어, React 같은 경우 vdom을 사용하면 그냥 DOM을 건드리는 것보다 평균적으로 빠르다고 React 문서에도 적혀 있으며 많은 컨퍼런스에서 이야기합니다. 그러나 아래 GIF와 같이, 가장 빠른 프론트엔드 프레임워크는 ‘NO’ 프레임워크라는 것을 알 수 있습니다.

물론 소프트웨어를 만들 때 성능 말고도 중요한 것은 많습니다. XSS를 Framework단에서 알아서 핸들링 해주는 것과 같은 보안, 많은 개발자들이 서로 공감할 수 있는 커뮤니티, 개발할 때의 즐거움, 발전하게 하는 개발환경 등등 중요한 요소가 많다고 생각합니다.

이러한 이유로 프레임워크가 상대적으로 속도가 느리더라도 큰 규모의 회사들이 전부 사용하는 것이죠. 그래도 성능은 어느 개발 환경에서도 무시할 수 없는 요소입니다.

이번 글에서는 코인원에서 사용하고 있는 FrontEnd Framework인 Angular 환경에서 Change Detection의 성능 최적화 방법을 알아보도록 하겠습니다. Change Detection에서 성능적으로 문제가 될 수 있는 부분은 두 가지가 있습니다.

1) Change Detection이 불필요하게 많이 실행되는 부분
2) Change Detection 한번 실행될 때 사용되는 CPU 부분

위 두 가지 케이스를 최적화하고 Change Detection으로 발생하는성능 저하를 전체적으로 최적화해보겠습니다.

최적화 방법 1 : ChangeDetection 횟수 최소화

Change Detection은 Framework 별로 불리는 방식이 다르지만 (React에서는 Reconciliation이라고 합니다.) Angular뿐 아니라 대부분의 Front End Framework에서 성능적으로 항상 문제인 DOM manipulation 최소화를 위해 사용하는 방식입니다.

Change Detection을 한 줄로 요약하자면 ‘DOM을 업데이트할지 체크하는 것’이라고 할 수 있습니다.

위 한 줄 요약 문장에서 ‘체크’라는 단어를 강조해서 다시 요약하겠습니다.

“Change Detection은 DOM을 Update 하는 역할을 하는 것이 아니고 오로지 Update 할지 체크만 하는 것입니다. (강조: 체크, 체크, 체크)”

사실 체크만 하는 과정인데, 과연 최적화가 필요할지 생각하기도 했습니다. 그러나 이 ‘체크'라는 과정은 정말 빈번하게 발생합니다.

이 섹션에서는 간단한 예제를 통해 최적화가 되어있지 않을 경우, Change Detection이 얼마나 많이 발생하는지 살펴보고 최적화를 하겠습니다.

간단한 예제로 아래의 `parent` 컴포넌트를 구현했습니다.

`parent` 컴포넌트는 Angular가 Change Detection을 실행할 때마다 콘솔에 `0 Parent ChangeDetection` 이라고 로그를 찍어 주고 있습니다.

또한 클릭 이벤트가 바인딩된 버튼이 하나 있고 (하지만 아무 기능을 하지 않습니다) 자식 컴포넌트로 `child-one`과 `child-two` 컴포넌트를 가지고 있습니다.

(`’’.log(0, ‘Parent ChangeDetection’)`과 `’’.noop()`이 이상해 보일 수 있는데요, 이 부분은 Angular Template에서 window를 직접적으로 접근할 수 없지만 String Prototype은 접근을 할 수 있기에 String Prototype에 Template에서 직접 쓸 기능을 정의했습니다. 그 이유는 Component에 method를 정의하지 않고 Template에만 집중하기 위해서입니다.)

`child-one` 컴포넌트와 `child-two` 컴포넌트는 다음과 같이 구현했습니다.

위 두 Child 컴포넌트도 Parent 컴포넌트와 같이 Change Detection이 발생할 시, 콘솔에 로그를 찍어 주며 클릭이벤트가 바인딩된 버튼을 가지고 있습니다. 또한 어느 컴포넌트에서 Change Detection이 일어났는지 구분 가능하도록 컴포넌트 별로 서로 다른 로그를 찍어 주도록 구현했습니다. 이제 위 코드를 아주 간단한 스타일과 함께 브라우저에서 실행시키면 다음과 같이 보입니다.

옆에 구현된 그림에서 한번 짚고 넘어갈 것은 `child-one` 컴포넌트와 `child-two` 컴포넌트는 `parent` 컴포넌트의 자식으로 들어가는 것과 `child-one` 컴포넌트와 `child-two` 컴포넌트는 서로 형제 컴포넌트라는 것을 강조하고 이제 위처럼 간단하게 구현된 컴포넌트들의 Change Detection 주기로 일어나는 성능적인 문제점을 보도록 하겠습니다.

위 그림에서 보이는 바와 같이 앱이 처음 실행될 때 Change Detection은 컴포넌트 별로 두 번씩 돌아가고 있습니다. 상식적으로 생각해보면 처음 컴포넌트가 render 될 때 어떤 값들이 있나 체크를 한번 하는 것이 옳은 것이라고 볼 수 있습니다. 하지만 Angular에서는 기본적으로 하나의 컴포넌트에서 Change Detection이 돌면 아무 상관이 없는 컴포넌트들도 Change Detection을 돌립니다.

아마도 AngularJS (Angular 1) 시절 디자이너도 쉽게 개발할 수 있게 Black Magic이라 홍보하던 것을 그대로 이어받아, 처음 Angular를 접하시는 분들이 쉽게 Angular를 사용할 수 있게 하기 위한 배려가 아니었나 싶습니다. 이런 전체적인 Change Detection은 위 처음 앱이 실행될 때가 아닌 아래처럼 Event가 생겼을 때도 발생합니다.

위 그림처럼 이벤트가 어느 컴포넌트에서 발생했는지와 상관없이 모든 컴포넌트의 Change Detection이 실행되는 것을 볼 수 있습니다.특히 이상하게 생각되는 두 가지 부분이 있습니다.

첫 번째로, Child 컴포넌트가 아닌 상위의 Parent Component의 이벤트가 발생을 하더라도 Event Bubbling과 아무 상관없는 Child 컴포넌트의 Change Detection이 돌아간다는 것입니다.

두 번째로, ChildOne 컴포넌트에서 Event가 발생했는데 형제 컴포넌트인 ChildTwo 컴포넌트의 Change Detection이 돌아가는 것입니다.

위 두가지 경우는 정말 말도 안 되는 경우라 생각합니다. Angular도 그렇게 생각했는지 위 두개의 경우는 아주 쉽게 해결할 수 있는 옵션을 제공하고 있습니다. 이름하여 Change Detection Strategy!

Change Detection Strategy

위에서 말씀드린 것처럼, Angular에서는 Change Detection이 말도 안 되는 상황에 실행되는 것을 쉽게 바꿀 수 있게 인터페이스를 제공하고 있습니다. 그 인터페이스 사용방법은 모든 컴포넌트 decorator의 `changeDetection` prop에 아래처럼 `ChangeDetectionStrategy.OnPush`로 값을 지정해주면 됩니다.

Angular에서는 `ChangeDetectionStrategy`의 값들로 `OnPush`와 `Default`가 있습니다. `changeDetection` 옵션을 컴포넌트 데코레이터에 설정을 안 해줄 경우 기본 값은 `ChangeDetectionStrategy.Default`로 자동 설정됩니다. 우선 ChangeDetectionStrategy를 OnPush로 바꾸고 아래와 같이 다시 한번 앱을 실행하겠습니다.

위와 같이,; 앱을 실행 시 Default Change Detection Strategy일 때 컴포넌트별로 2번씩 실행되던 Change Detection이 onPush Change Detection Strategy로 바꾸자 올바르게 컴포넌트 별로 한 번씩만 실행되는 것을 볼 수 있습니다. 그렇다면 onPush Change Detection Strategy를 사용한 상태에서 Event는 어떻게 핸들링하는지 보도록 하겠습니다.

onPush Change Detection Strategy를 사용을 하니 Parent 컴포넌트에서 이벤트가 발생했을 시 오로지 자기 자신의 Change Detection만 돌아갑니다. 자식 컴포넌트에서 이벤트가 발생하면 자기 자신의 Change Detection과 Parent 컴포넌트의 Change Detection이 실행되는 것을 볼 수 있습니다.

다행히도 onPush Change Detection Strategy는 하나의 컴포넌트에서 이벤트가 발생하면 존재하는 모든 컴포넌트의 Change Detection을 실행시키는 말도 안 되는 행동은 하지 않지만 아직 부족한 부분이 있는 것 같습니다. Change Detection이 돌아가는 이유는 유저들에게 보여주는 View가 바뀌었을 거 같을 때 돌아가야 한다고 생각합니다.

지금 같은 경우 Event가 발생했고 심지어 그 Event가 아무런 행동도 하지 않고 있는데, Change Detection을 이벤트가 발생한 컴포넌트 포함 그 위의 모든 컴포넌트에 실행을 시킨다는 것은 비효율적이라 생각합니다.

일단 onPush Change Detection Strategy는 무조건 사용하는 게 옳다고 생각합니다. onPush가 아닌 Default Change Detection Strategy를 사용할 경우 보신 바와 같이 하나의 컴포넌트에서 발생하는 이펙트들이 아무 관계없는 모든 컴포넌트에 영향을 주는 것은 정말 말도 안 되는 행동이기 때문입니다. 그래서 많은 글에서도 Change Detection을 일단 onPush로 하는 것을 권장하고 있습니다. onPush Change Detection인 상황에서도 위 Event를 포함 최적화해야 하는 부분들도 많이 있기에 onPush CD stategy로 바꾼 지금부터가 최적화 시작입니다.

일단 지금 까지 긴 글이 있었는데 결국에는 최적화를 하기 위해 무엇보다 첫 번째로 해야 하는 것은 간단하게 “ChangeDetectionStrategy.onPush를 사용하세요”입니다. 이제부터는 모든 컴포넌트에 ChangeDetectionStrategy.onPush을 반영했다는 가정하에 최적화 방법을 하나하나 보도록 하겠습니다.

이벤트로 인한 불필요한 Change Detection 고치기

위 예제에서 보신 바와 같이 onPush Change Detection Strategy를 사용후 Angular에서 제공하는 `(click)` property로 event binding을 하면 Click Event 발생시 현 컴포넌트를 포함 상위 컴포넌트의 Change Detection들이 실행됩니다.

그 이유는 Angular가 제공해주는 `(click)` Property로 binding을 하면 Zone이라는 곳에서 로직을 돌리게 되고 그 Zone에서 로직이 돌아갈 시 Angular가 Change Detection이 필요할 것 같은 Component들의 Change Detection을 돌리기 때문입니다.

이것을 우회하기 위해 Angular Zone 밖에서 Event를 바인딩해주면 Angular는 Event가 바인딩되어 있다는 것을 모르게 되며 그렇게 될 시 불필요한 Change Detection 실행은 안하게 됩니다. 이런 상황을 제현하기 위해 Angular Zone 밖에서 Event Binding 하는 것을 아래의 ChildOne 컴포넌트에 구현해 보았습니다.

코드에서 보는 바와 같이, Angular에서 재공 하는 `(click)` 이벤트 바인딩 인터페이스를 사용하지 않고 RxJS에서 제공하는 `fromEvent` operator를 사용하여 이벤트를 바인딩하면 Angular는 이벤트가 바인딩되어 있는지 알 수가 없게 됩니다.

즉 Angular Zone에 `(click)`이 바인딩돼있다는 것을 모르게 하는 효과를 가지게 됩니다.

위 코드 수정후 아래와 같이 앱을 구동해 본 결과 기존의 ChildOne Button을 클릭 시 ChildOne과 Parent 컴포넌트에서 돌던 Change Detection이 더 이상 돌지 않는 것을 볼 수 있습니다.

이제 상식적으로 이해가 안 되던 (또는 초보자 배려를 위한) 불필요한 ChangeDetection은 없앤 것 같습니다. 다음 최적화로 넘어가기 전에 이렇게 Angular Zone 밖에서 Event 바인딩을 하게 될 시 주의해야 되는 부분을 보도록 하겠습니다. 아래 코드를 보시면 CHILD ONE BUTTON을 클릭 시 `count` property가 1씩 증가할 것 같은 코드를 볼 수 있습니다;

위 코드를 실행해보면 ChildOne Component 코드는 Event가 생성되어도 Change Detection은 실행되지 않기에 component property인 count 값은 업데이트되어 console log에서 확인할 수 있지만, Template에 바인딩되는 count값은 업데이트되지 않는 것을 아래에서 볼 수 있습니다.

Change Detection은 이제 event의 생성으로 실행되지 않습니다. 불필요한 Change Detection은 없앴지만, template에 값이 바인딩될 때는 Change Detection을 실행시켜줄 필요가 있습니다. 이런 상황을 대비하여 Angular에서는 `async` pipe을 제공해 주고 있습니다.

`async` pipe와 Change Detection

`async` pipe은 template에서 사용하는 것으로 컴퍼넌트의 Observable 값에 subscribe하여 그 Observable이 값을 쏴줄때마다 Change Detection을 실행시킵니다.

`async` pipe 자체도 성능적 문제가 있다는 것을 아래 섹션에서 보겠지만, 우선 `async` pipe의 행동을 보도록 하겠습니다. 아래 코드는 위 예제에서 template이 제대로 업데이트 안 되는 상황을 Observable과 async pipe를 사용하여 작동되도록 수정한 코드입니다.

위 코드를 보시면 template에 `async` pipe를 쓰고 있는 것을 볼 수 있습니다. 또한 기존에 number type이었던 `count` property가 BehaviorSubject인 `count$`로 변경이 되었고 `count$` 의 값은 `count$.next(value)`로 업데이트됩니다.

이렇게 `async` pipe를 사용하여 Subscribe 되어 있는 Observable이 값을 쏘게 되면 (예: `count$.next(value)`) Angular는 현제 컴포넌트와 모든 상위 컴포넌트들에 MarkForCheck를 하게 됩니다.

결국 현재 컴포넌트의 Change Detection과 모든 상위 컴포넌트의 Change Detection이 아래와 같이 실행되는 효과를 가지게 됩니다.

보시는 바와 같이 ChildComponent에서 `count$.next()`를 하는 순간 ChildComponent와 그 상위 컴포넌트인 ParentComponent의 Change Detection이 돌아가는 것을 볼 수 있습니다. async pipe는 상위 컴포넌트가 없거나 상위 컴포넌트의 Change Detection이 실행되어도 성능적으로 문제가 되지 않을 때 편의상 쓰면 좋다는 결론을 내릴 수 있습니다.

결국 성능적으로 최고의 행동은 ChildOne 컴포넌트의 값이 변했을 때 오로지 ChildOne 컴포넌트의 Change Detection만 실행되는 행동이라 할 수 있습니다. 값이 변한 컴포넌트의 Change Detection만 돌리는 제가 아는 방법은 오로지 한 가지입니다. 바로 ChangeDetectorRef의 detectChanges 메서드!

ChangeDetectorRef의 detectChanges Method로 가능한 효율적 수동 Change Detection

아래 코드는 위 `async` pipe의 문제인 ChildOne Component의 변화에 불필요하게 Parent Component의 Change Detection까지 실행되는 것을 detectChanges Method를 사용하여 수정한 코드입니다.

위 코드에서 바뀐 점은 기존의 문제가 되었던 `async` pipe을 없애고 number type의 count 프로퍼티를 사용하고 있다는 것과 `ChangeDetectorRef`를 주입하여 `detectChanges` 메서드를 count 프로퍼티 값을 변경 후 불러주고 있는 것입니다. 위 코드를 아래와 같이 실행시켜 보았습니다.

ChildOne의 count 값이 바뀐 후 ChangeDetectorRef의 detectChanges 메서드를 부르면 ChildOne의 Change Detection만 실행되고 기존에 문제가 됐던 Parent 컴포넌트의 Change Detection이 실행되지 않는 것을 볼 수 있습니다.

이렇게 하여 하나의 컴포넌트 안에서 Event와 local state change의 변화로 일어나는 Change Detection의 횟수를 최적화해 보았습니다.

마지막으로 다룰 Change Detection 횟수 최적화는 컴포넌트 안에서 일어나는 행동으로 인한 Change Detection이 아닌 Parent Component가 Child Component에게 값을 전달할 때 불려지는 Change Detection의 문제점과 최적화의 대하여 알아보겠습니다.

Props로 Primitive 값을 받았을때 실행되는 Change Detection

컴포넌트의 Change Detection은 위에서 보셨던 경우들 말고도 돌아가는 경우가 하나 더 있습니다. 바로 Parent로부터 기존에 받았던 reference 값이 지금 받아온 reference 값과 다를 때입니다. 아래 예제와 함께 설명해 보겠습니다.

위 왼쪽에 있는 코드는 Parent 컴포넌트로 2초마다 `countFromParent` 라는 프로퍼티에 0의 값을 지정해 주고 Parent의 Change Detection을 실행시킵니다. 그리고 이 `countFromParent` 의 값은 2초마다 ChildOne 컴포넌트의 `count` Input (이하 props 라 하겠습니다)로 넘겨집니다. Angular 에서는 props 로 넘어오는 값이 같은지 다른지 strict equality (`===`)를 사용해 결정합니다.

지금 같은 경우 ChildOne의 `count` Input (또는 props)으로 받아오는 값은 항상 0 이며 `0 === 0` 은 true 이기에 받아오는 값이 달라지지 않는 것을 Angular는 확인하고 ChildOne의 Change Detection은 아래와 같이 실행되지 않습니다.

위 그림처럼 `countFromParent` 의 값이 ChildOne의 `count` props로 2초마다 넘겨지고 있지만 항상 같은 값인 0을 넘겨받기에 ChildOne 컴포넌트의 Change Detection은 실행되지 않고 Parent 컴포넌트의 Change Detection이 실행되는 것을 볼 수 있습니다.

반대로 Parent Component에서 항상 다른 값을 ChildOne 컴포넌트로 넘겨주면 아래와 같이 Child Component의 Change Detection도 실행되는 것을 볼 수 있습니다.

(변경된 코드는 Parent Component에서 `this.countFromParent = 0` 부분을 `this.countFromParent = this.countFromParent + 1` 밖에 없어 코드 설명은 생략하겠습니다.)

위 그림에서 보시는 바와 같이 ChildOne의 `count` props로 받아오는 reference 값이 기존에 받아왔던 reference값과 다르기 때문에 ChildOne의 Change Detection도 실행되는 것을 볼 수 있습니다.

위 예제 같은 경우 별문제 없이 필요한 경우에 Change Detection이 실행되고 있습니다. 그 이유는 JavaScript에서 number와 같은 primitive는 pass by value이기 때문입니다. 문제는 props로 받아오는 값이 number나 string 같은 primitive data structure가 아닌 Object나 Array 같은 complex data structure일 때 생기게 됩니다.

Props로 Complex Data Structure를 받았을때 실행되는 Change Detection

설명을 위해 Complex Data Structure중 하나인 JavaScript Object를 ChildOne 컴퍼넌트 Props로 넘기는 예제를 아래와 같이 만들었습니다.

위 왼쪽 Parent 컴포넌트의 `countFromParent` 는 더 이상 number type이 아닌 Object type입니다. 또한 timer안에서 바뀌는 값(`this.countFromParent = { value: 0 }`)은 모양이 기존의 값과 똑같지만 reference value는 완전히 다른 새로운 Object입니다.

ChildOne 컴포넌트는 이 Object를 2초마다 받게 되고 값이 같은지 다른지 strict equality (===)로 체크를 합니다. Object와 같은 Complex Data Structure는 pass by reference이기 때문에 `{value: 0} === {value: 0}` 는 `false`의 값을 가지게 되고 Angular는 값이 바뀐 것으로 간주하여 ChildOne 컴포넌트의 Change Detection은 아래와 같이 매번 실행되는 것을 볼 수 있습니다.

위에서 보시는 바와 같이, 결국 template에 사용되는 받아온 Object (`{value: 0}`) 안의 value property의 값은 변하지 않았지만 ChildOne의 Change Detection이 실행되는 것을 볼 수 있습니다. 위 같이 컴포넌트로 받아오는 props가 Object이나 Array일 때 모양은 같아도 reference가 다를 경우 실행되는 Change Detection을 최소화하는 방법은 두 가지가 있다고 생각합니다.

첫째, Immutable.js나 Immer와 같은 Structural Sharing을 하는 Immutable Data Structure를 사용하는 것

둘째, Input으로 들어오는 값의 “다름”의 기준을 strict equality (===)가 아닌 다른 방식의 수동 체크를 사용하는 것

두 번째 방법은 native DOM을 건드리는 3rd Party Library를 사용할 때 유용한 방법이지만 복잡하여 스킵하겠습니다.

Immutable 라이브러리로 핸들링하는 Complex Data Structure

위에서 보이던 문제의 해결 방법으로 Immutable.js나 Immer같은 Structural Sharing / Immutable 라이브러리를 사용하는 방법이 있습니다. 그중 요즘 트렌드인 immer를 사용하여 아래처럼 구현해 보았습니다.

위 왼쪽의 Parent 컴포넌트는 `produce`라는 immer library에서 제공하는 함수를 사용하였습니다. 보통 Immutable 하게 개발을 하다 보면 비효율적으로 Object나 Array를 복사해야 되는 경우가 있습니다. 이런 경우를 효율적으로 바꾸기 위해 보통 Immutable Library들은 Structural Sharing이라는 방법을 사용합니다.

Structural Sharing은 이론적으로는 아주 간단합니다. 기존에 있던 Object의 값들을 최대한 제사용 하여 복사할 필요 없는 상황을 만드는 것 이 Structural Sharing의 궁극적인 목표입니다. 위 예제를 토대로 말씀드리면, `this.countFromParent`라는 JavaScript Object를 사용하여 `produce`라는 함수는 필요시에만 새로운 Object을 생성하여 return 하고 새로운 Object를 만들 필요가 없다면 인자로 받은 Object (위 예제의 `this.countFromParent`)를 그대로 return 합니다.

지금 같은 경우 `draft.value = 0`부분을 보시면 기존의 `this.countFromParent`라는 Object의 값이 이미 {value: 0}이기 때문에 기존의 Object에 변화를 주지 않습니다. 이렇게 변화가 없는 경우 새로운 Object을 만들지 않고 기존에 있던 Object을 그대로 넘겨줍니다. 즉 `produce`함수로 나온 Object는 기존에 있던 `this.countFromParent` Object와 reference가 같은 값을 return 합니다.

그리하여 ChildOne 컴포넌트가 `count` Input으로 받아오는 Object가 변했는지 {value: 0} === {value: 0}로 체크를 할시 같은 메모리에 위치한 Object이기 때문에 true의 값을 가지게 되고 ChildOne의 Change Detection은 아래와 같이 실행되지 않습니다.

위 그림처럼 Parent 컴포넌트의 Change Detection만 실행이 되고 ChildOne의 Change Detection은 불필요하게 실행되지 않는 것을 볼 수 있습니다.

물론 값이 변했을 때는 Change Detection이 돌아야 되니 immer가 저희가 원하는 대로 작동하는지 체크할 겸 Object에 매번 다른 `value` property값을 아래처럼 넣어 줘 봤습니다.

위 코드에서 달라진 점은 Parent의 `timer`안에서 `draft.value`를 increment 해주는 게 다이고 ChildOne 컴퍼너너트는 달라진 것은 없습니다. 위 코드를 아래와 같이 실행해보겠습니다.

위 그림처럼 immer Library는 Object의 값이 바뀔 시 새로운 Object를 생성해 주며 ChildOne 컴퍼넌트는 새로운 Object를 받아 Change Detection을 실행해주는 것을 볼 수 있습니다.

개인적인 의견으로 복잡한 Data Structure를 다루는 개발이라면 Immutable.js나 immer의 사용은 성능적인 면에서 봤을 때 필수라 생각합니다.

이렇게 하여 Change Detection 횟수 최소화를 시킴으로써 성능 최적화하는 방법을 보았습니다. 위 예제에서 Change Detection이 실행될 때 그리 많이 CPU를 사용하지 않는 (사용자 입장에서 봤을 때) console에 log만 했었습니다.

하지만 Change Detection이 돌아갈 때 간단한 console의 log가 아닌 CPU를 엄청나게 많이 쓰는 로직이 돌아간다면 앱이 잠시 멈추는 등 사용자가 느낄 수 있을 정도의 영향을 줄 수 있습니다.

다음 섹션은 이런 Change Detection시 무거운 로직이 돌아가는 경우 최적화하는 방법에 대하여 알아보겠습니다.

최적화 방법 2: ChangeDetection 무게 최소화.

위 섹션에서 Change Detection 횟수를 최소화하는 방식으로 최적화를 해보았습니다. 이번 섹션에서는 Change Detection이 실행될 때 불필요한 CPU 사용을 최적화하는 방법을 보도록 하겠습니다. 설명을 위해 아래 예제를 만들어 보았습니다.

위 왼쪽 Parent 컴포넌트의 button을 클릭 시 Parent 컴퍼넌트는 ChildOne 컴포넌트에 Object를 전달합니다. Object의 값은 의미가 없으며 오로지 ChildOne 컴포넌트의 Change Detection을 실행시키기 위함입니다.즉, Parent 컴포넌트의 Button을 클릭 하면 ChildOne 컴포넌트의 Change Detection이 실행됩니다.

ChildOne 컴포넌트의 template을 보시면 `progress` 태그가 있습니다.

이 `progress` 태그는 애니메이션이 반영되어 있으며 서비스를 사용하는 유저가 앱의 성능적 문제로 인해 UI가 멈추는 것을 보여주기 위해 존재합니다.

ChildOne 컴포넌트의 메서드로 `heavyCalc` 라는 메서드가 있습니다. 이 `heavyCalc` 메서드는 template에 바인딩되어 있으며 Change Detection이 실행될 때마다 불리게 됩니다.

`heavyCalc` 메서드 안의 로직을 보면 for 문을 인자로 받은 숫자만큼 돌리고 난 후 인자를 반환한다는 것을 볼 수 있습니다. for문을 많이 돌려 CPU를 많이 쓰는 상황을 재현한 것입니다. 위 코드를 실행시키면 다음과 같이 실행됨을 볼 수 있습니다.

위 보시는 바와 같이 처음 앱이 실행될 때 `heavyCalc` 가 실행되어 rendering을 블록 하는 것을 볼 수 있습니다.

또한 Parent 컴포넌트 버튼을 클릭할 때마다 UI thread를 블록 하여 progress bar가 멈추는 것을 볼 수 있습니다. UI thread가 블록 되면 브라우저의 scroll과 같은 기능들도 멈추게 됩니다. 이제 위에서 보이는 문제점들을 고쳐 최적화를 해보도록 하겠습니다.

Memoize기능을 사용한 부분을 최적화

위에서 보이는 문제점은 Change Detection이 돌아갈 때마다 CPU를 많이 쓰는 로직이 돌아간다는 것입니다.

그렇다면 memoize와 같은 방법으로 `heavyCalculation` method를 memoize 한다면 처음에는 느리겠지만 추후 함수 인자가 같다면 CPU를 많이 사용하는 로직을 돌릴 필요 없이 기존에 반환한 값을 그대로 반환하면 됩니다.

여기서 주의하여야 할 점은 이 `heavyCalculation`이라는 함수가 pure 함수여야 한다는 점 입니다. 즉 인자가 같으면 반환되는 값도 같아야 된다는 것 입니다. Angular에서 제공하는 pipe는 이런 부분적 memoize기능을 사용하고 있습니다. 다음은 pipe를 만들어 CPU intensive 한 로직을 꼭 필요할 때만 실행되도록 구현해 보았습니다.

위와 같이 ChildOne 컴포넌트에 있던 `heavyCalculation` 메서드를 따로 pipe로 구현하여 template에 바인딩(`{{ 6000 | heavyCalculation }}`) 하였습니다.

이렇게 할 경우 heavyCalculation Pipe에 있는 `transform` 메서드의 인자가 기존에 실행된 값과 같다면 그 안의 로직들 (for 문 등)이 실행되지 않고 넘어가게 됩니다. 위 코드를 아래와 같이 실행해 보았습니다.

위 그림에서 보이듯 처음 앱 실행될 시 rendering이 블록 되는 것은 해결되지 않았습니다. 하지만 Parent button을 클릭할 때 멈추던 것은 해결이 된 것을 볼 수 있습니다.

지금과 같은 경우, Parent Button을 클릭하면 ChildOne 컴포넌트의 Change Detection은 실행되지만 heavyCalculation pipe의 transform 메서드가 받은 인자의 값은 변하지 않았기 때문에 heavyCalculation안의 로직들은 다시 실행되지 않는 것을 볼 수 있습니다.

결국 문제는 무슨 방법을 쓰던 최소한 처음 rendering 할 때 heavyCalculation은 첫 값을 인자로 받아 돌아가는 상황은 꼭 있고 다른 값을 인자로 받는 경우로 인해 heavyCalculation이 돌아가는 상황은 빈번하다는 것입니다.

그래서 memoize와 같은 기능도 좋지만 결국은 UI thread를 block 하는 로직은 최소한 한 번은 돌아간다는 것은 그 어떤 방법을 써도 변함이 없다고 가정할 수 있습니다. 이렇게 heavyCalculation안의 로직을 한 번쯤은 꼭 실행해야 된다면 UI thread를 block하지 않고 실행을 하면 문제는 해결됩니다.

CPU intensive 로직을 Web Worker Thread로

많은 분들이 브라우저 JavaScript환경은 single thread라고 알고 있지만 엄밀히 따진다면 UI thread (사용자의 input을 받고 사용자에게 output을 보여주는 thread)만 Single thread이고 계산을 위한 또는 Caching을 위한 thread는 따로 생성할 수 있습니다.

위 예제의 문제를 해결하기 위해 UI thread에 영향을 주지 않는 Web Worker를 아래와 같이 구현해 보았습니다.

위 왼쪽 코드는 ChildOne 컴포넌트로 주목해야 되는 부분은 ngOnInit부분입니다. ngOnInit은 ChildOne 컴포넌트가 처음 생성이 되는 시기에 새로운 Web Worker thread를 한번 생성합니다. 이렇게 처음 생성된 Web Worker thread를 ChildOne 컴포넌트의 `worker` property에 저장하여 언제든 재사용할 수 있도록 구현하였습니다.

ChildOne의 `heavyCalculation`이라는 method가 template에 바인딩되어 있음으로 Change Detection이 실행될 때마다 `heavyCalculation`이라는 method는 실행이 되고 `heavyCalculation` 메서드는 인자로 받아오는 값을 Web Worker로 보내고 난 후 바로 `heavyCalculationResult` property를 반환해줍니다.

즉, template에 `heavyCalculation`을 실행시키는 부분은 `heavyCalculationResult`라는 property의 값으로 기다림 없이 바로 바인딩 되게 됩니다. Main thread로 부터 `loopCount`의 값을 받은 Web Worker (위 오른쪽 코드 ChildOne Worker)는 `heavyCalculation` 로직을 실행 시킵니다.

위 오른쪽에 있는 ChildOne Worker 로직을 보시면 `memoLoopCount`라는 HashMap에 loopCount라는 키가 있는지 확인을 하고 만약에 없다면 CPU를 많이 쓰는 로직을 돌립니다. 이때 이 CPU intensive 로직은 UI thread에 영향을 안주는 별계의 thread에서 실행된다는 게 중요한 포인트입니다.

CPU intensive 로직을 실행시키고 나온 값을 `memoLooopCount`에 저장하여 다음에 똑같은 인자를 받아올 시 불필요하게 CPU intesive로직을 실행하지 않고 반환을 해줄 수 있게 구현하였습니다.

계산 결과 값을 찾은 ChildOne Worker는 값을 다시 Main UI thread (ChildOne 컴포넌트)에 넘겨줍니다. 이때 값을 받아오는 로직은 위 오른쪽 ChildOne 컴포넌트의 `this.worker.onmessage` 부분입니다.

무한 Change Detection loop을 방지하기 위해 `this.worker.onmessage`로 받아온 ChildOne Web Worker의 결과 값을 기존에 받아온 결과 값과 같은지 체크를 한 후 다를 시에만 Change Detection을 다시 돌리게 구현되어있습니다.

이렇게 구현을 하면 아래에서 보이는 바와 같이 rendering은 물론 UI thread는 단 한순간도 블록 되지 않는 것을 확인할 수 있습니다.

위 그림에서 보이는 바와 같이 CPU Intensive 계산은 web worker에서 완료를 하는 것을 console log에서 볼 수 있습니다. 추가적으로 개선할 것이 있다면 `heavyCalculation`을 실행시키는 순간 Spinner와 같은 계산 중이라는 UI를 넣어 주면 위에서 6000이라는 숫자가 갑자기 나타나는 것을 더 자연스럽게 표현할 수 있을 것 같습니다.

Web Worker는 지금 것 Front End Framework에서 가장 Under utilized 된 기능인 것 같습니다. Web Worker를 쓰면서 “redux환경에서 rootReducer 로직을 webworker에서 실행시키면 어떨까?”와 같은 생각이 들 정도로 WebWorker를 잘 사용한다면 그 아무리 CPU intensive 한 로직이라도 핸들링할 수 있을 것 같다 생각 들었습니다.

허나 Web Worker를 처음 생성하는데 걸리는 시간은 40ms정도가 되고 Web Worker로 넘어가는 보통 Front End 개발자가 쓰는 data structure들은 전부 복사가 되서 넘어간다는것등 고려해야 하는게 조금 있기는 합니다. (참고: https://hacks.mozilla.org/2015/07/how-fast-are-web-workers/).

(아마도 다음 블로그는 React에서 Web Worker를 최대한 활용하기가 되지 않을까 싶습니다. )

마무리하며

이렇게 하여 Angular의 Change Detection 부분의 최적화하는 방법을 알아보았습니다. Change Detection이 기본 세팅에서는 얼마나 자주 돌아가는지 보았고 이것을 최소화시켜 보았습니다. Change Detection이 실행될 때 CPU intensive 한 로직은 Web Worker로 뺌으로 인하여 유저들 입장에서 봤을 때 더 최적화되어 보이게 구현도 해봤습니다.

끝으로 제 생각을 말씀드리자면 최적화는 하면 할수록 더욱 진행하고 싶은 부분입니다. 최적화는 끝이 없는 것이기에 MVP를 구현하고 어느 정도 유저들이 불편 없이 사용할 수 있게 완성하여, 배포 후 문제가 될 시 하는 게 옳다고 생각합니다. 또한 진행하면서 데이터를 측정하시는 것을 추천드립니다.

처음부터 최적화를 하시지 말고, 마지막에 필요할 때 진행하는 것과 정확한 최적화 측정을 위한 Profiler 사용을 추천드리며 이 글을 마치겠습니다.

Change Detection 중심 Angular 최적화 방법 was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요, 코인원 CTO Lab의 개발 인턴 강주현입니다. 코인원 인턴 생활이 5개월 차에 접어든 시점에서 새로운 블록체인 검증 방식을 소개하려고 하는데요, 바로 생소하지만 혁신적인 주제인 ‘영지식증명’입니다. 조금은 어려운 주제이기도 하지만, 현재 블록체인 네트워크 기술의 수면 위로 떠오르고 있는 증명 방식인 만큼 쉽게 풀어내어보려고 합니다.

영지식증명의 정의와 특성

영지식증명(Zero-Knowledge Proof)은 단어가 의미하는 대로 ‘지식 없이 하는 증명’입니다. 이 증명에는 두 가지 역할자가 존재하는데, 각각 증명자(Prover)와 검증자(Verifier)라고 부릅니다. 증명자는 어떠한 정보가 참이라는 것을 증명하는 역할자이며, 검증자는 해당 정보가 참이라는 것을 검증하는 역할자입니다. 따라서 영지식증명은 증명자가 자신이 알고 있는 정보를 공개하지 않으면서 정보를 알고 있다는 사실을 검증자에게 증명하는 과정입니다.

이해를 빠르게 돕기 위해, 간단히 알리바바의 동굴의 예시를 들겠습니다.

스미스와 찰리라는 사람이 있습니다. 또한 입구에서 두 갈래로 나뉘다가 각자의 끝이 마법의 문으로 서로 이어진 동굴이 있다고 가정합니다. 마법의 문은 비밀의 단어를 외쳤을 때 열리는 문입니다. 여기서 찰리는 비밀의 단어가 무엇인지 알고 있습니다.

찰리 : “너에게 비밀의 단어가 무엇인지는 말해주지 않겠지만, 내가 비밀의 단어를 알고 있다는 사실을 증명하고 싶어!”

스미스는 찰리가 두 갈래 중 한 길을 택해서 문에 다다를 때까지 동굴 밖에서 기다립니다. 그리고 찰리가 문에 도착했을때 쯤, 스미스는 동굴 입구로 가서 이렇게 말합니다.

스미스 : “네 증명이 맞는지 검증해볼게. 지금 나는 동굴 입구에 있고, 너는 왼쪽 갈래길로 나와봐.”

찰리가 스미스가 지시한 갈래로 나왔을 때, 찰리는 두 가지 가능성을 생각합니다. 첫 번째 가능성은 “오른쪽 갈래로 들어가 왼쪽 갈래로 나왔다 (비밀의 단어를 알고 있다)” 이며, 두 번째 가능성은 “왼쪽 갈래로 들어가 왼쪽 갈래로 나왔다 (비밀의 단어를 알고 있거나 모르고 있다)”는 것이 됩니다. 스미스가 확실하게 비밀의 단어를 알고 있다고 검증하기 위해서는 해당 검증 절차를 여러 번 반복하여 “비밀의 단어를 알고 있을 확률”을 높이는 것입니다.

이렇게 검증 절차를 거치고 난 뒤, 찰리는 스미스가 알고 있는 비밀의 단어에 대한 정보를 알지 못해도, 스미스가 그 단어를 알고 있는지 없는지에 대한 검증을 할 수 있습니다.

위와 같은 영지식증명 과정이 만족하는 3가지 조건이 있습니다. 각각 완전성(Completeness), 건전성(Soundness), 그리고 영지식성(Zero-Knowledge)이라고 지칭합니다.

완전성(Completeness): 어떠한 정보가 참일 경우에 정직한 증명자는 정직한 검증자에게 그것을 납득시킬 수 있어야 한다.

건전성(Soundness): 어떤 정보가 거짓일 경우에 부정직한 증명자는 거짓말을 통해 정직한 검증자에게 그것이 ‘참’임을 절대 납득시킬 수 없어야 한다.

영지식성(Zero-Knowledge): 검증자는 어떤 정보가 참 혹은 거짓이라는 사실 이외에는 아무것도 알 수 없어야 한다.

영지식증명의 발전: zk-SNARK

영지식증명을 통한다면 어떤 사실을 알지 못해도 그것이 참이라는 것을 증명할 수 있습니다. 그러나 위에 소개된 알리바바의 동굴과 같은 예시는 증명자와 검증자 간에 항상 통신이 가능한 상태여야 합니다. 검증될 때까지 서로 메시지를 교환하면서 증명을 하는 방식은 증명의 사이즈가 클수록 주고받아야 하는 메시지 양이 늘어나고 시간 소모가 커지기 때문에 비효율적일 수 있습니다. 그 점을 보완하기 위해서 2013년, zk-SNARK(zero-knowledge Succinct Non-interactive ARguments of Knowledge)가 소개되었습니다.

zk-SNARK는 발전된 영지식증명입니다. 영지식증명을 기반으로 간결하고(Succinct) 비상호적인(Non-interactive) 지식 논의를 하는 것이 zk-SNARK 라고 볼 수 있습니다.

비상호성(Non-interaction): 증명자와 검증자의 온라인 여부에 관계없이 증명 및 검증이 가능하다.

간결성(Succinctness): 증명 사이즈가 수 1/1000 초 안에 검증될 정도로 작고 간결하다.

기존 검증 방법이 여러 번 메시지 교환을 통한 방식이라면, zk-SNARK는 사전 정의된 함수와 매개 변수를 이용하여 단 한 번만 검증하는 방식입니다. 조금 더 말을 풀어보자면, 증명자가 증명에 필요한 매개 변수와 증인 변수(정보를 증명하기 위해 필요한 비밀 입력값)를 증명 함수에 넣고 증명 데이터를 생성한다면, 검증자는 검증에 필요한 매개 변수와 증명 데이터를 검증 함수에 넣고 증명이 유효한지 아닌지를 판별합니다.

블록체인에 zk-SNARK를 접목하다

일반적으로 블록체인 네트워크에는 수신자, 송신자 및 전송 금액 등의 거래 내역 정보가 공개 및 기록되어 있습니다. 개인정보를 보호하고 보안을 강화해야 하는 필요성이 늘어남에 따라 여러 블록체인 프로젝트에서 zk-SNARK를 접목하는 시도를 하고 있습니다. 대표적으로 영지식증명을 사용하는 암호화폐로써 지캐시(Zcash)가 있으며, 익명성을 보장하는 거래를 구현하였습니다. 이와 같은 비공개 거래는 일반적인 블록체인 네트워크에 기록되지만, 잔고와 송금 금액 등의 정보를 공개하지 않은 채 거래 내역이 기록됩니다.

또한 zk-SNARK를 이용한 증명 사이즈와 검증 과정은 증명해야 하는 정보의 양에 상관없이 일정한 속도와 시간을 요구합니다. 이더리움 창시자 비탈릭 부테린은 이더리움 의 확장성을 증대시키기 위해서 zk-SNARK를 도입할 계획이 있음을 밝혔습니다. 이를 통해 최대 500 TPS의 성능까지 끌어올리고, 스마트 컨트랙트 내부에 영지식검증 알고리즘을 돌아가게 하여 과포화 상태의 이더리움 네트워크를 개선하는 등 구체적인 청사진을 그리고 있는 것으로 알려졌습니다.

마무리하며

시간이 지날수록 블록체인 기술이 발전함에 따라서 다양한 기술을 도입 및 적용하고 있습니다. 영지식증명 또한 현재까지도 안정적이며 확장성 있는 증명 방식이 되기 위해 개선 및 발전을 이루고 있습니다. 한층 더 나아가는 블록체인의 발전을 기다리며, 영지식증명에 대한 소개를 마칩니다.

영지식증명, 새로운 블록체인 검증 방식의 등장 was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요, 코인원 QA셀의 CO를 맡고 있는 구자현입니다. QA는 과연 어떤 역할을 하고 있을까요? 여러 개발 직군에 몸담고 계신 분들이 저에게 QA(Quality Assurance)와 관련해 반문하는 경우가 적지 않습니다. 대부분 QA팀을 테스트 역할만 하는 팀으로 인식하는 경우가 많습니다.

오늘은 기술블로그에 이러한 현실을 조금이나마 정리해서 말씀드리려고 합니다. 제가 작성하는 글은 전문적인 기술요소가 아닌 개념설명에 초점을 맞추고 있습니다. 개인적인 의견이 주가 됩니다. 다른 QA 직군 종사자분과 의견이 다를 수 있으니 참고해주시기 바랍니다. 그럼 이제 시작하겠습니다!

‘어느날 코인원 아이유(a.k.a 기술블로그 담당자)님의 DM이 도착했습니다.’

과연 QA에 대해 어떤 내용을 작성해야 여러분의 궁금증을 아주 일부라도 시원하게 긁어드릴 수 있을지 고민했습니다. “조금은 무거운 기술 내용을 담고 있는 기술 블로그에 뭔가 맛깔 난 글을 쓸 수는 없을까?” 하고 말이죠. 그래서 아주 단순하지만 많은 분이 착각(?)하고 있는 내용을 다룰까 합니다. 많은 분이 저에게 QA는 무엇인지에 대해 질문을 하곤 합니다. (Q&A 아닙니다…?) 문득 한가지 생각이 들었습니다. 과연 나는 QA 절차를 잘 지켜 일하는지, 코인원은 이상적인 QA 활동을 하고 있는지, 2017년 12월 입사하고 나서 다짐했던 것들을 잘 이행하고 있는지!

“QA 해주세요!” 코인원에 있으면서 가장 많이 들었던 말 중 하나입니다. 사실 여기서 우리는 큰 오류를 범하고 있습니다. 단지 ‘QA = TESTer’ 라고 생각하고 요청을 하셨다는 생각이 듭니다. QA는 매우 어렵고 전문적인 활동입니다. 프로덕트 QA를 위한 하나의 방법으로 ‘테스트’가 있고, QA 활동의 극히 일부의 영역입니다. 테스트는 품질을 향상하기 위한 행위 중 하나입니다. 테스트만 잘된다고 해서 프로덕트의 품질이 높아질 수는 없습니다. 때때로 발견된 결함도 상황에 따라 수정 없이 넘어가는 경우도 많습니다. 먼저 품질 목표를 설정하고 그에 따른 효율적인 개발 방안을 설정하는 것이 소프트웨어 품질 향상에 도움이 됩니다. 테스트에 몰두하는 것이 능사는 아니라 생각합니다.

자, 여러분은 테스트가 무엇이라 생각하시나요?

테스트는 개발 완료 단계에서 기능의 정상 동작이나 확인하는 그런 단순한 업무를 의미하는 것이 아닙니다. 테스트는 전반적인 개발 단계에 걸쳐 수행되어야 합니다. 기획/요구사항 분석 및 리뷰, 기술 명세 리뷰, 리스크 분석, 테스트 아키텍처, 테스트 환경 구축, 테스트 설계 및 수행, 테스트 스크립트 작성, 성능 테스트 등 많은 작업이 테스트 활동에 포함되어 있습니다. (자세한 설명을 하기에는 광범위하여 다음에 다루도록 하겠습니다)

그럼 코인원의 QA셀은 왜 QA를 할 수 없을까요?

대부분 QA 부서라고 하면 가장 먼저 개발이 완료되고 난 후, 완료된 프로그램을 다양한 환경에서 테스트를 수행하고 고객에게 전달하는 부서로 생각합니다.

지금까지 ISTQB Syllabus에 QA와 테스팅에 대한 이야기가 없었는데 2018년 버전에 추가되었습니다. 1.2.2 Quality Assurance and Testing을 참고하시면 됩니다. 하지만 여러분은 뭔가 부족함을 느끼실 거라 생각됩니다.
(링크: https://www.istqb.org/downloads/send/51-ctfl2018/208-ctfl-2018-syllabus.html)

QA는 ‘Quality Assurance’의 약자로 제품이 일정 수준의 품질을 가질 수 있도록 제품의 기획부터 개발 그리고 릴리즈까지 모든 과정에서 함께합니다. 고객에게 최고의 품질을 서비스 할 수 있도록 최선의 노력을 합니다. 하지만 쉽지가 않죠. 가장 큰 이유 중 하나는 짧은 스프린트로 돌아가는 코인원의 목적조직에는 어울리지 않기 때문입니다.

스프린트 안에 발생하는 명세에 대한 분석 및 설계가 정상적인 범위에 수행되었다 해도 테스트 단계에서 이슈라는 벽에 부딪히기 마련입니다. 리그레션 테스트의 무한루프(테스트 > 결함수정 > 사이드이펙트 > 테스트)에 빠지는 경우가 발생할 수 있기 때문입니다. 다행스럽게도 코인원 QA의 힘은 강합니다. (네 정말 다행입니다. 저는 이것만으로 QA의 목적의 70%는 달성했다고 봅니다.) 아닌걸 아니라고 할 수 있으니 말이죠. (너무 당연한건데…)

코인원은 변화무쌍한 암호화폐 시장의 요구사항을 모두 충족시키기 위해 노력합니다. 그러다보니 어쩔수없는 D-Day(배포일정이 미리 확정된)가 있어 많은 제약사항이 발생할 수 밖에 없는 환경입니다. 그렇기 때문에 우리가 바라는 이상적인 QA활동을 하기 힘들 수 있습니다. 하지만 우리는 강합니다. 코인원 QA 셀은 각 상황에 따른 대응 매뉴얼을 만들고 수행하며, 각 상황별 QA플랜을 명시하고, 크루 개개인의 R&R을 확실하게 정/부로 나누어 운영하여 중간에 새로운 업무가 발생해도 바로 백업이 가능하도록 준비되어 있습니다.

물론 이것이 답은 아닐 수 있습니다…!

하지만 다른 회사의 프로세스가 아무리 잘 운영이 되고 있다고 해도 코인원에 맞는 운영법은 따로 있다고 생각합니다. 가장 좋은 예시로 많은 회사에서 도입하다 실패하는 `애자일`의 예를 듭니다. 그래서 코인원만의 프로세스를 만든것이죠.

간단히 코인원의 QA 활동을 나열해 볼까 합니다.

코인원의 QA는 정의된 요구사항에 누락 및 중복된 것이 없는지 검증하는 과정을 거칩니다. 모호한 요구사항은 담당자와 협의하여 정의하는 단계를 거쳐 요구사항을 테스트 관점에서 재정의하여 케이스를 도출합니다. 이렇게 정의된 요구사항은 추후 변경에 대하여 반영하고 이력을 관리합니다. 테스트에 대한 요구사항은 설계자 및 담당자에게 공유하고 검증하며 개발 단계별로 테스트 프로시저 및 테스트 케이스 도출에 대해 담당자와 협의를 합니다. 보통 V모델을 기준으로 진행하며 각 분석, 설계단계 별로 테스트케이스 및 프로시저를 준비할 수 있습니다.

품질 목표를 세우고 품질 목표에 기반하는 테스트계획을 세우고 분석 결과를 토대로 케이스를 작성하며 테스트 케이스는 ISO/IEC 25010 품질 특성을 기반으로 작성하려 노력합니다. 때로는 자원과 시간이 부족할 수 있습니다. 그럴 경우 리스크분석을 하는 것이 좋습니다.

코인원은 테스트케이스 수행을 최소화하고 있습니다. 추가된 신규기능에 대한 테스트케이스를 수행하며 그 외의 기능은 기본기능(필수) 체크리스트 및 API 테스트케이스(스크립트)를 수행함으로써 테스트 시간을 단축합니다.
(메이저 버전의 업데이트에 한하여 전체 테스트케이스를 수행하며 일정에 따라 전사 배포를 프리징 시키기도 합니다)

자동화가 필요한 영역(자주 사용되고 UI의 변화가 없는)은 자동화를 진행 중이며 변경 사항에 대한 성능 테스트도 진행합니다. 성능에 영향을 줄 수 있는 api 또는 websocket과 같은 변경사항은 변경 전과 변경 후의 성능 측정 결과를 비교합니다.

테스트 환경은 Dev — QA — Stage — Real로 구성이 되어있으며 dev는 개발자의 영역이며 QA 환경부터 테스트가 진행됩니다. (QA 테스트 완료 > Stage 테스트 완료 > 배포 > Real 테스트)

코인원은 자신이 개발한 내역을 배포 전 한번더 확인을 위해 Dev환경에서 개발자 테스트 수행을 필수로 하고 있습니다. 테스트 내용과 테스트 결과를 jira에 명시하도록 되어 있으며 Dev 환경에서 Pass가 되지 않은 내역은 QA환경에서 테스트 진행을 하지 않습니다.

이렇게 완료된 테스트 결과를 기준으로 리뷰하고 내부 정의한 이슈 심각도 기준에 따라 배포 가능 여부를 결정합니다. 기준을 충족하면 배포를 진행하며 배포가 완료되면 리얼환경에서 추가 테스트 진행과 모니터링을 진행합니다. (오늘도 무사히🙏)

코인원의 QA 셀은 항상 이야기합니다. 완벽한 테스트는 불가능하며, 테스트는 결함이 없다는 것을 밝히는 활동이 아닌 결함의 존재를 증명하는 행위라고 말합니다. 또한 테스트로 인해 발생할 수 있는 기업의 이익에 대하여 말합니다. 초기에 발견된 결함이 수정에도 용이하며 추후 발생하는 문제점 대응에도 수월해 집니다. 늦을수록 들어가는 금액과 결함발견 및 수정에도 많은 시간이 소요되며, 성급한 테스트와 부족한 시간은 좋은 소프트웨어의 품질을 보장하기 쉽지 않기 때문에 각 상황에 맞는 리소스 분배를 진행합니다.

지금까지 코인원의 QA 셀이 QA를 할 수 없는 이유와 그것을 해결하기 위한 행동을 알아봤습니다.

QA와 테스트는 전혀 다른 활동입니다. 같은 활동으로 착각하지 않으셨으면 좋겠습니다. 두 활동은 목적과 목표가 전혀 다릅니다. 테스터는 제품이 고객에게 전달되었을 때 결함이 발생할 확률을 낮추기 위한 행동을 합니다. 그러나 QA는 그 제품을 사용자가 감탄을 자아내게 하는 행동을 하기 위해 노력합니다. 가장 좋은 그림은 QA 조직과 테스트 조직을 분리하여 고객에게 결함이 적고 감동을 줄 수 있는 서비스를 유지하는 것입니다. 아직 코인원의 QA가 가야 할 길은 멉니다. 현재 진행 중인 테스트 자동화 및 케이스 고도화 등 해야 할 일이 많죠.

언제나 그랬듯이 우리는 삽질을 할 것이고, 삽질 끝에 결과를 만들어 낼것입니다. 코인원 QA셀 화이팅입니다!

바쁘다고 일정 픽스하고 던지기 있기? 없기?

다음 편에서는 개발 전반에 숨어있는 QA 활동(테스트)은 어떤 것이 있을지 알아보는 시간을 가질 예정입니다. 감사합니다!

코인원 QA셀이 하는 일 was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

지난 글에 이어서 이번에는 코인원에서 Prometheus를 어떻게 활용하는지에 대해서 이야기해보고자 합니다. 주로 Prometheus의 데이터들을 grafana에서 어떻게 활용하는지에 대한 이야기가 될 듯합니다.

리소스 상태를 한눈에 볼 수 있는 대시보드를 만들자!

코인원의 차세대 엔진 프로젝트가 마무리 단계에 접어들며 저희는 성능에 대한 테스트를 진행해야 했었습니다. 우선은 가장 기본적인 CPU, Memory, Network에 대한 usage를 확인하는 것으로 범위를 잡았고, Prometheus의 Web UI Console에서 관련 metric 정보들이 있는지 확인하였습니다.

Web UI Console을 사용해보신 분들은 아시겠지만, Prometheus의 metric naming은 체계적으로 잘 정의되어 있어서 query 입력창을 통해 손쉽게 확인이 가능했습니다.

최종적으로는 아래 query로 usage metric을 산출하였고, 이를 grafana의 대시보드에 구성하였습니다.

Prometheus의 query (PromQL)의 기본적인 사용법과 function의 종류, 예제들은 Prometheus 공식 문서를 참고하였습니다.

Query에서 변수 처리된 부분은 grafana에서 variable로 지정된 값으로 치환이 됩니다.

다만, pod는 매번 생성과 삭제가 반복되기에 지정된 pod_name 설정이 어렵습니다. 그래서 kube_deployment_metadata_generation query를 이용하여 grafana의 variable에 label_values로 지정을 해줍니다.

Usage metric에 대한 구성이 완료된 이후에는 해당 대시보드를 대형 모니터에 띄워서 모든 Application 대한 리소스 사용량 변화 추이를 한눈에 볼 수 있게 구성하였습니다.

다만, 이때는 모니터의 화면 사이즈에 대한 제약이 있어서 꼭 필요한 metric만 선별해야 했습니다.

그래서 위의 Usage 외에 Pod의 수량과 상태 정보, Node의 Memory 및 Disk Usage와 해당 Node에서 실행되는 Pod 개수, Uptime 정보 정도만 선별하여 아래 query로 Prometheus에서 산출하였습니다.

최종적으로 Pod와 Node의 grafana 대시보드를 구성한 모습은 아래와 같습니다.

상단의 드롭다운 박스에서 kubernetes의 namespace와 deploy 된 pod를 선택하면, row 단위로 그래프가 나타납니다.

Node 또한 해당 node를 선택하면 row 단위로 그래프가 나타나도록 대시보드를 구성하였습니다.

장애 증상 탐지와 Alert Notification

한 번은 저희 사이트 기능이 간헐적으로 문제가 생기는 이슈가 발생했습니다. kubectl에서 확인했을 때, 해당 서비스의 Pod들은 멀쩡히 running 상태로 운영이 되고 있었습니다.

그래서 Prometheus의 최근 데이터를 확인해보니, 아래와 같이 특정 Pod의 Memory 사용률이 급격히 올라가는 것을 확인하게 되었습니다.

그런데 해당 이슈를 수정하고, 검증하는데는 많은 시간이 필요로 하다는 피드백을 받게 되었습니다.

문제는 저희의 서비스가 24시간으로 운영이 되고 있는데, 어느 순간에 해당 문제가 발생할지도 알 수가 없었습니다.

한가지 확실한 것은 평상시에는 Memory의 사용량이 일정하다는 것이었습니다. 그래서 Grafana에서 해당 Rule을 아래와 같이 만들고, 저희 Slack으로 Notification을 받을 수 있도록 지정했습니다.

참고로 Grafana를 세팅할 때 한가지 문제점이 있는데, Alert를 추가하고자 하는 대시보드의 Prometheus Query에서 variable을 사용하게 되면 Alert를 생성할 수가 없습니다.

그래서 저희는 모니터링 Alert 전용 대시보드를 별도로 만들고, 해당 Prometheus Query는 variable 지정된 부분을 고정값으로 넣어 해결을 했습니다.

물론 Prometheus-alertmanager를 이용해서도 구성이 가능합니다. 저희의 경우에는 Grafana에서 언제 문제가 발생했고 알람을 보냈으며, 해결되었는지 확인이 되어 좋았습니다.

Worker Node 현황을 한눈에 보자!

kubernetes의 운영 초기에 Pod를 Deploy 하다 보면 Worker Node의 CPU나 Memory의 resource가 부족하여 pending으로 멈춰 있던 경우가 종종 있었습니다.

그래서 Node에 대한 리소스 현황을 한눈에 볼 수 있는 대시보드가 있었으면 좋을 듯하여, 아래와 같이 Grafana에서 하나의 대시보드로 만들어서, 부족한 자원이 발생하면 다른 Node로 배포하던가 Node를 증설하는데 참고하였습니다.

위 metric에 대한 정보는 아래의 prometheus query로 산출을 하였습니다.

위의 query에서 변수 처리 된 부분은 grafana에서 variable로 지정된 값으로 치환이 됩니다. 일부 변수는 화면에서 숨김처리 되었습니다.

Worker node의 전체 현황을 보여주는 대시보드 외에도 개별 worker node에서 어떤 pod가 생성되었고, 얼마만큼의 리소스를 사용하고 있는지도 모니터링할 수 있도록 아래와 같이 대시보드를 만들었습니다.

참고로 해당 대시보드는 위에서 언급된 query들을 응용하여 구성했습니다.

마무리하며

두 편의 글을 통해 실무에서 Prometheus를 활용하는 법을 소개하였습니다.

저희도 아직은 사용 초기 단계라서 어찌 보면 너무 기초적인 내용일 수 있지만, 저희도 처음에는 Prometheus에 대해 아무것도 모르는 상태에서 이것저것 만져가며 저희에게 맞는 것만 간추린 거라 볼 수 있습니다.

또한, 처음 접하시는 분들이 방대한 metric에 바로 손을 놓으시기보다는 기본적인 것들로 하나씩 구성하여, 최종적으로는 자신들에게 맞는 모니터링 시스템을 구축했으면 합니다.

Prometheus 모니터링 실무 적용기 2탄 was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요, 코인원 Platform Engineer 허민입니다. 인프라 플랫폼을 운영하면서 서버, 네트워크, Application의 상태를 모니터링 하는 것은 매우 중요한 일입니다. 의사가 아픈 사람에게 청진기나 엑스레이를 사용하여 증상을 파악하는 것처럼 엔지니어도 인프라 플랫폼의 상태를 파악하고, 나아가서는 추이 분석을 통해 장애를 대비하기 위한 모니터링 구성을 지속적으로 해야 합니다.

모니터링 시스템은 불과 몇 년 전만 해도 zabbix나 cacti 외에는 별다른 선택지가 없었습니다. 최근에는 new relic이나 datadog의 상용 솔루션은 물론이고 오픈소스 형태의 많은 프로젝트가 생겨났습니다.

코인원은 베어메탈이나 클라우드는 물론이고 컨테이너 환경(특히 kubernetes)을 도입하며 다양한 인프라 플랫폼을 아우를 수 있는 모니터링 시스템 구축을 필요로 했습니다. 이 일환으로 Prometheus와 Grafana의 조합으로 통합 모니터링 시스템 구축을 검토하게 되었습니다.

이번 글에서는 모니터링 시스템을 구축하면서 겪었던 다양한 경험과 실무에서의 적용까지 이야기해보려고 합니다.

왜 Prometheus인가?

코인원에서는 올해 초 코인원코어라는 차세대 거래 엔진 프로젝트를 진행하면서 기반 인프라 환경을 kubernetes로 구축하게 되었습니다. 그러면서 kubernetes의 리소스를 모니터링 하는 것과 기존의 시스템도 통합할 수 있는 솔루션을 필요로 했습니다.

리서치를 해보니 kubernetes 모니터링 솔루션은 선택지가 그렇게 많지는 않았는데, 그중에서 Prometheus가 사실상의 표준 모니터링 솔루션으로 자리 잡고 있었습니다.

kubernetes 리소스 모니터링 솔루션에 대한 자료는 kubernetes 공식 문서를 참고 했습니다.

Prometheus를 도입했을 때의 장점은 아래와 같습니다.

1) kubernetes 환경에서 간편하게 설치

저희는 kubernetes 안의 모든 어플리케이션을 helm을 이용해 관리하고 있었습니다. Prometheus 역시 helm을 이용해서 설치했습니다.

실제로 설치부터 helm chart를 이용해 간단히 설치를 했고, 각종 metric도 별다른 설정 없이 손쉽게 수집이 가능했습니다.

helm chart는 https://github.com/helm/charts/tree/master/stable/prometheus를 사용했습니다.

위의 helm chart를 이용해서 설치를 진행하면 alertmanager, kube-state-metrics, node-exporter, pushgateway, server에 대한 pod가 일괄로 생성됩니다.

helm chart에서 저희가 수정한 부분은 server에서 data가 저장되는 Persistent Volume의 사이즈와 data의 저장 주기를 늘려주는 것 뿐이었습니다.

2) 다양한 metric exporter의 제공

또한 Linux나 Windows 등의 OS metric 뿐만 아니라 각종 Third-party exporter를 제공하고 있어서, 향후에는 다양한 플랫폼을 모니터링 할 수 있는 솔루션으로도 발전시킬 수 있다고 판단이 되었습니다.

Third-party exporter에 대한 자세한 내용은 https://prometheus.io/docs/instrumenting/exporters/ 참고하시기 바랍니다.

3) 장기간의 데이터 유지와 추이 확인

그 밖의 장점으로는 metric의 수집을 server에서 pull 방식으로 수집하고 있어서 Agent node에 특별한 부하를 유발시키지 않는다는 점, 데이터 저장소가 시계열 데이터(time-series) 저장소로 구성이 되어 있어서 많은 양의 변경 내용을 빠르게 검색할 수 있다는 점을 들 수 있습니다.

더불어 grafana에서 prometheus의 db를 손쉽게 연결할 수 있어서 상황에 맞는 대시보드를 손쉽게 제작할 수 있습니다.

Prometheus 도입 이후 문제점은 없었나?

아래는 저희가 약 3개월 정도의 Prometheus를 운영한 내용입니다. AWS m5.2xlarge 인스턴스에 pod를 올렸고 특별히 리소스 제한은 주지 않았습니다.

가급적 필요한 정보만 선택하도록 대시보드를 만들기는 했지만, Prometheus가 리소스를 많이 사용하지 않았다는 것을 알 수 있습니다. 특히 metric을 가져오는 주기가 1분 단위이고, Pod의 수가 280개 정도인 상황에서도 데이터양은 크게 늘지 않았습니다.

다만, 위에서도 언급한 데이터 보관 주기를 처음에는 지정하지 않아서 기본값 15d로 운영이 되었고, 15일이 지난 metric 데이터는 자동으로 삭제가 되는 문제가 있었습니다.

또한 helm으로 설치를 하다 보니 재설치를 진행했을 때, persistent volume도 같이 삭제되어 metric 데이터를 모두 유실한 적도 있었습니다. 이를 방지하기 위해서 아래와 같이 Reclaim Policy를 Retain으로 변경하여, helm chart 삭제 후에도 persistent volume은 유지되게 하였습니다.

아직 3개월 정도의 시간밖에 운영을 하진 않았지만, Prometheus로 kubernetes 환경의 모니터링을 하기에는 큰 부족함은 없었습니다. 특히 grafana의 연동으로 누구든 시스템의 현황을 손쉽게 확인할 수 있었습니다.

또한, metric 데이터가 쌓이면서 서비스의 리소스 사용량과 임계치 설정으로 시스템 운영의 최적화 및 이상징후 탐지가 가능했습니다.

마무리하며

지금까지 코인원의 Prometheus 도입 배경과 실제 사용기에 관해 이야기를 해보았습니다. 확실히 container 서비스 환경과 kubernetes는 서비스의 도입을 쉽고 빠르게 해주는 장점이 있습니다.

다만, 이렇게 빠르게 도입되는 서비스에 대해서 안정적인 운영을 하기 위해서는 Prometheus와 같은 모니터링 솔루션은 반드시 구축되어야 하며, 이를 사용하는 방법도 조직 내에 지속해서 학습이 되어야 한다고 봅니다.

그럼 다음 편에서는 실제로 metric 데이터를 활용하는 방법에 대해 소개하도록 하겠습니다.

Prometheus 모니터링 실무 적용기 1탄 was originally published in Coinone Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.