Notice
Recent Posts
Recent Comments
Link
«   2024/09   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
Tags
more
Archives
Today
Total
관리 메뉴

마로의 개발일지

프로덕트 빌딩 - 1 본문

프로토콜 캠프

프로덕트 빌딩 - 1

maro0201 2023. 10. 9. 22:02

프캠이 시작되고 4주가 지나 팀빌딩이 끝난 후 프로덕트 빌딩이 가장 최우선 과제가 되었다. 프로덕트 빌딩에 관한 현재 상황과 목표, 지금까지의 개발 현황과 앞으로의 계획을 대략적으로 기록할 예정이다. 3년 차 주니어 개발자가 나름의 최선을 다해 프로덕트를 개발한 내용을 기록할 예정이니 감안하고 봐주길 바란다.

 

 현재 쿠키독의 프로덕트는 MVP 앱이 개발되어 있는 상태다. MVP 앱은 리액트 네이티브와 Firebase(DB, OAuth 등)를 이용해서 개발되어 있고 서버가 따로 존재하지 않아 인앱 결제나 지갑 로그인 같은 것들은 솔루션을 사용하고 있다. 말 그대로 백엔드 자체가 구축되어 있지 않아 0에서 1을 만들어야 하는 상황이다. 내가 해야 하는 일들을 대략적으로 나열해 보자면 다음과 같다.

- 언어 및 프레임 워크 습득(TypeScript/Nest.js)

- 기존의 프론트 호출을 대체할 api 생성(CRUD)

- 추가 기능 구현

- 인프라 구성

- 스마트 컨트렉트 연동 & Web3 솔루션 적용

각각에 대한 세부사항과 진행정도를 나열해보자면

 

언어 및 프레임 워크 습득(TypeScript/Nest.js)

 Web3는 프론트에서 스마트 컨트렉트를 직접 호출해서 사용하기 때문에 JavaScript 기반의 생태계가 잘 구성되어 있다. 스마트 컨트렉트가 Web3에서의 백엔드 역할을 대체하기 때문에 당연한 일일 것이다. 하지만 지금 우리 서비스는 Web3가  아닌 Web2.5와 유사하기 때문에 백엔드가 필요하다. 서버와 스마트 컨트렉트를 원활하게 연동하기 위해서는 JavaScript 기반의 언어와 프레임워크로 개발하는게 적절하다고 판단했고 기존에 사용하던 Java/Spring이 아닌 TypeScript/Nest.js로 개발을 하기로 했다. 그래서 TypeScript와 Nest.js를 팀 빌딩 기간동안 공부했고 지금은 해당 기술들을 이용해 서비스를 개발하고 있다.

 

기존의 프론트 호출을 대체할 api 생성(CRUD)

 기존의 프론트 호출은 Firebase의 NoSQL DB를 활용해서 단순한 CRUD만 처리하고 있었다. 그래서 해당 기능들을 서버로 옮기려면 우선 RDB 테이블을 설계하고, Nest.js를 이용해 기본적인 개발 환경 구성을 진행한 뒤 각각의 기능에 맞는 API를 개발해야 했다. 지금까지 진행한 내용은 테이블 설계를 진행했고(아래 이미지 참고) Nest.js를 이용해 기본적인 개발 환경 구성을 진행하는 중이다. Exception Filter, Swagger, TypeOrm 설정, Logger 등을 구현했고 프론트에서 Firebase의 auth 기능을 이용하고 있기 때문에 해당 기능을 서버에서도 활용해서 인증, 인가를 처리할 수 있도록 개발 중이다. 이후 복잡한 로직을 제외하고 당장의 우선순위에 따라 Entity를 생성하고 CRUD API를 개발할 예정이다.

 

추가 기능 구현

 MVP앱에서 기존에는 백엔드 서버가 존재하지 않아 구현하지 못했던 기능들이 있다. 보안상의 문제나 로직의 복잡성으로 인해 구현하지 못했었는데 이번에 내가 합류하면서 그러한 기능들을 개발할 수 있게 되었다(아마도?). NFT 자동 민팅이라던가 USDC를 이용한 빠른 정산, 인앱 결제 내재화 같은 기능들이 필요했고 우선적으로 빠른 정산에 대한 경험을 제공해주고 싶기에 해당 기능을 우선적으로 개발하기로 했다. 일단 CRUD API에서 당장 필요한 항목들만 생성한 후 해당 기능을 우선적으로 개발할 예정이다. 기능 자체는 간단할 것 같지만 돈이 연관되어 있다 보니 보안적인 측면을 좀 더 신경 써야겠다.

 

스마트 컨트렉트 연동 & Web3 솔루션 적용

 Web2 서비스와 Web3 서비스의 큰 차이라면 역시 스마트 컨트렉트일 것이다. 그리고 아마 우리 같은 Web2.5 서비스의 가장 큰 어려움은 서버와 스마트 컨트렉트를 연동하는 작업일 것이다. 대부분의 Web3 서비스들은 프론트엔드에서 지갑을 연동해서 사용자가 해당 지갑을 이용해 컨트렉트를 호출한다. 하지만 우리는 사용자가 지갑의 여부를 알지 못하고 서버에서 가스비를 대납해 주는 형태로 구성되어 있기 때문에 해당 기능에 대한 이해와 적용이 필요하다.

 이해와 적용을 하기 위해 공식 문서를 참고하고 여러 튜토리얼들을 진행했다. 해당 튜토리얼들은 시간이 된다면 정리해서 공유해 보도록 하겠다.

- 서버에서 컨트렉트 호출 -> 호출 자동화

- AA(Account Abstraction)와 AA의 PayMaster(Alchemy GasManager)를 이용해서 컨트렉트 호출 -> 가스비 대납

- OpenZeppelin의 Relayer를 이용해 private key 없이 서명 -> private key 보호

추가적으로 개발을 위해 알아봐야 할 항목들은 아래와 같다.

- 0xPass 연동 및  Paymaster 호출: 지갑 솔루션 연동 및 가스비 대납

- Arweave 이미지 저장 호출: NFT의 이미지를 탈중앙화된 저장소에 저장

 당장은 정산 기능에 필요한 0xPass 연동 및  Paymaster 호출 정도면 진행할 예정이며 이후 필요한 기능이 있다면 공식 문서와 튜토리얼을 통해 학습하고 적용할 예정이다.

 

인프라 구성

 인프라는 지금 생각하고 있는 건 AWS Lightsail을 이용해보려고 한다. 사용량에 제한이 있지만 월마다 정해진 금액을 지불하면 된다는 점이 매력적이고 우리 같은 소규모 서비스에 적합하다고 생각했다. 당장 필요한 항목들은 서버를 띄울 인스턴스, DB, 저장소, DNS 주소, ApiGateway 및 VPC 구성 정도이고 정산 기능 구현이 끝나는 대로 구성해 볼 예정이다.

 

개인적인 생각

 프로덕트를 처음부터 빌딩 하고 싶었던 나에겐 지금 주어진 상황이 아주 만족스럽다. 하고 싶었던 Web3 서비스 개발도 하고 인프라 구성도 처음부터 해볼 수 있기에 쿠키독에 오길 잘했다는 생각이 든다. 물론 할 일이 정말 많지만... 내가 한 만큼 성장한다는 생각을 하고 있기 때문에 오히려 좋다고 생각한다.

Comments