이 블로그는 NFT 거래 서비스를 만들며 겪은 시행착오와 해결과정을 정리한 내용입니다.
-
의욕은 넘치지만 아직 배우는 과정인 신입 개발자가 쓴 글이기 때문에, 틀리거나 더 좋은 방법이 있을 수 있습니다. 틀린 내용이 있거나 더 좋은 방법이 있으면 댓글로 알려주시면 감사하겠습니다..
-
이 글에서 노드(Node), 블록체인 서버(BlockChain), 메인넷(Mainnet)은 같은 의미로 사용됩니다.
-
저희 회사의 블록체인의 합의 알고리즘은 위임지분증명(rdPoS)입니다.
2022년 11월, 내가 회사에 입사한 지 일주일만에 첫 미션으로 주어졌다. 블록체인 기반의 토큰(TRC721)인 NFT를 만들어 거래할 수 있는 서비스를 개발하는 일이었다. (백엔드 인력이 부족했고 중간 개발자가 없었다..) 🥲
처음 맡은 프로젝트였기 때문에 설레는 마음도 있었지만, 백엔드 1명(나) + 블록체인 1명 + iOS 2명 + 안드로이드 2명 + 프론트 엔드 1명 + 기획자 2명으로 구성된 개발 인원 중에서 나 혼자 돈과 관련된 백엔드 서버를 개발해야 한다는 부담감도 느꼈다.
개발 전 마음가짐
1어떤 프로젝트든 처음 개발하는 사람이 코드를 어떻게 짜느냐에 따라 리팩토링 기간과 유지보수 기간이 기하급수적으로 늘어나거나 줄어들기 때문에 신중하게 개발해야 한다는 생각으로 시작했다.
또한 블록체인 서비스를 개발하기 위해선 블록체인 서비스들이 어떤 식으로 동작하는 이해하고 사용자 관점에서 봐야한다고 생각해서 Opensea.io나 Pala.io같은 유명한 NFT 거래소를 사용하기로 생각했다.
프로젝트를 진행하면서 나는 블록체인 개발자, 프론트 엔드 개발자, 앱 개발자, 기획자 모두와 소통을 가장 많이 해야되기 때문에 협업을 잘하는 방법에 대한 원티드 컬럼도 읽어봐야겠다.
당시 나의 머릿 속 🥲
- 도메인은 어떤 것들이 있고 도메인을 어떻게 작성해야 유지보수가 쉬울까?
- 어떻게 테스트코드를 작성해야 빠르고 무결한 테스트를 할 수 있을까
- 블록체인의 느린 처리속도를 어떻게 개선할 수 있을까?
이러한 생각들을 가지고 서비스 개발을 시작했다.
첫 번째 이슈
TRC721 기반 토큰을 생성하는 로직이 완성되고 토큰을 만들어봤는데 소요시간이 평균적으로 30초 ~ 1분 사이였다.
만약 여러 명이 동시에 요청한다면 클라이언트에서 Timeout이 발생할게 뻔했다.
우리 회사의 메인넷은 설명하기 힘든 사유로... 비교적 상당히 느린 속도를 가지고 있다.
블록체인 개발자는 아니지만 이더리움 ERC721 기반의 토큰(NFT)을 생성할 때도 속도가 매우 느린것을 보면 원래 그런건지도..
아래는 NFT가 가지는 상태를 간단히 정리한 표 입니다.
| 상태 | 설명 |
|---|---|
| ISSUE | 컬렉션 최초 발행 |
| MINTED | NFT의 최초 발행 |
| LISTING | NFT 판매등록 |
| LISTING CANCEL | NFT 판매 등록 취소 |
| SALE | NFT 거래 |
| TRANSFER | NFT의 소유권 이전 |
여기서 MINTED | SALE | TRANSFER 작업은 꽤 많은 시간이 소요된다.
우선 NFT 발행을 구현하기 위한 방법들을 생각했다.
1️⃣ 일반적인 민팅
순서
- NFT 메타데이터에 필요한 정보들의 유효성을 검사한다.
- 클라이언트의 지갑을 오픈해서 충분한 가스비(수수료)가 들어있는지 확인한다.
- 작품 명과 사진, 가격 정보를 취합해서 메인넷에서 컴파일 할 수 있는 스크립트를 생성하고 컴파일한다.
- NFT를 메인넷에 등록해준다.
- NFT 발행이 완료되면 NFT의 컨트랙트 ID와 정보들을 데이터베이스에 저장하여 캐싱한다.
장점
- 구현이 어렵지 않고 즉시 Contract ID를 확인할 수 있다.
단점
- 느린 속도 때문에 클라이언트 UX가 저하되고 클라이언트의 Timeout을 길어져 이후 로직에 차질이 생길 수 있다.
다 좋은데 단점이 너무 치명적이다. 앱팀에서 timeout을 60초로 늘렸는데도 문제가 생긴다고... 🥲
그래서 생각해낸 방법은 지연 민팅이다.
2️⃣ 지연 민팅
순서
- NFT 메타데이터에 필요한 정보들의 유효성을 검사한다.
- 데이터베이스에 저장하여 캐싱한다.
-- 3번부터는 LISTING, TRANSFER 등 다른 이벤트가 발생하면 실행한다. - 작품 명과 사진, 가격 정보를 취합해서 메인넷에서 컴파일 할 수 있는 스크립트를 생성하고 컴파일한다.
- NFT를 메인넷에 등록해준다.
다른 점이 없어보이지만 3,4번 작업은 판매등록, 판매등록취소 작업이 일어나면 실행돼서 발행 자체는 시간이 오래 걸리지 않는다.
장점
- 발행 시간이 비교적 빠르다.
- 발행 시 가스비가 들지 않는다.
단점
- 어차피 판매 시점이 되면 (1)번 방법과 같은 발행 시간이 필요하다
- 실제 발행된 것이 아니기 때문에 트랜잭션이 남지 않는다.
내가 생각하는 2번 방법의 가장 좋은 점은 가스비가 들지 않기 때문에 NFT에 관심은 있으나 돈은 쓰기 싫은 사용자들의 유입을 기대할 수 있다는 점이다.
3️⃣ 민팅 큐(Queue) 생성
순서
- NFT 메타데이터에 필요한 정보들의 유효성을 검사한다.
- 데이터베이스에 요청 자체를 저장한다.
- 유저의 지갑에서 중간 지갑으로 가스비 만큼 옮긴다.
- 클라이언트에 컨트랙트 ID를 제외한 모든 정보를 리턴한다.
- 우선순위 대로 공용지갑에서 민팅을 진행하고 사용자에게 소유권을 이전 시킨다. 사용자의 민팅 요청이 완료되면 푸시 알림을 보낸다.
장점
- 서비스 사용자가 일으킨 트랜잭션이 소실될 위험이 없다.
- 속도가 빠르다.
- 발행시간을 기다리지 않아도 지갑에서 NFT를 확인할 수 있다. (거래는 불가)
- 민팅에 대한 응답을 기다리지 않아도 푸시 알림으로 발행 성공 시점을 정확하게 확인할 수 있다.
단점
- 데이터베이스에 저장을 먼저 하는 만큼 민팅을 실패했을 떄 로직이 복잡해지거나 꼬일 수 있다.
- 민팅을 실패했을때 필요한 송금(대리 발행을 위해 옮긴 비용) 가스비는 법인에서 부담해야된다.
내가 3번 방법을 선택한 이유는 서비스 시작이 비교적 늦은 우리 회사는 트랜잭션 하나 하나가 중요하고 트랜잭션이 많이 쌓일 수록 가스비가 많아진다.
2번에 경우 발행만 하고 LISTING, TRANSFER를 하지 않는다면 발행이 되지 않아 트랜잭션도 쌓이지 않지만 3번 방법는 Queue에 삽입된 이상 트랜잭션이 보장되기 때문이다.
결론은 개발자와 기획자의 시각에서 예상치 못한 실패로 인한 가스비 손실보다 2번에서 트랜잭션이 일어나지 않은 비용 이 더 중요하다고 생각했다.
신규 유입이 없는 서비스인 만큼 사용자가 쌓아주는 트랜잭션 하나하나가 중요했기 때문이다.
더 좋은 방법을 생각하기 위해서 회의 시간마다 팀원들과 사내 카페에서 몇 시간씩 회의했다는..
몇 자 끄적이다보니 글이 너무 길어져 다음 포스트에서 이어 써야겠다..
