Fact

이번 프로젝트에서 백엔드를 맡아 API 서버 개발, 토큰 발행 및 전송 기능을 구현했다.
팀원이 총 4명이라 프론트 2명, 백 2명으로 역할을 분담했었는데 프론트의 분량이 많아 혼자서 백엔드 작업을 하게 됐다.

Feeling

이번 프로젝트를 시작하면서 처음으로 GraphQL을 접하게 되었다. 그래서 프로젝트 초기에 GraphQL 사용법을 익히느라 시간을 많이 투자했는데, 얼른 개발을 시작해야 한다는 초조함에 스트레스를 많이 받았다. 하지만 GraphQL 사용법을 한번 익히고 나니 매우 편리해 도입하기 잘 했다고 생각한다.
또한 팀원 전원이 프론트엔드에서 작업했을 땐 리팩토링을 하기가 매우 어려웠는데, 혼자서 백엔드 작업을 했더니 파일 분류 구조를 바꾸고 이름을 변경하는게 수월했다. 그렇지만 내가 파일 구조를 잘 짜고 있는지, 좀 더 효율적인 방법을 생각하지 못하고 있지는 않은지 의문이 들 때가 많았다. 만약 다른 팀원과 함께 백엔드 작업을 했다면 의논하면서 브레인스토밍을 했을텐데, 아무래도 다른 팀원들이 전부 프론트엔드 작업을 하느라 바쁘니 백엔드 서버의 구조와 네이밍 등을 의논하기가 어려웠다. 혼자서 개발을 할 때와 여럿이서 개발을 할 때의 장단점을 느낄 수 있었다.
그리고 지난 씨냅스 프로젝트 때 DB를 따로 만들지 않아 이더리움 관련 정보는 모두 이더리움 네트워크에서 조회해야 했기 때문에 데이터 조회가 매우 느렸다. 그래서 이번엔 DB를 만들었는데, 데이터 조회 하는 속도가 개선되어 만족스러웠다.

Future Plan & Finding

프로젝트를 진행하면서 아쉬운 부분을 정리하였다. 이후에 다른 프로젝트를 할 때 다시 참고하려고 한다.

1. 에러 관리 및 해결 방법 정리 누락

씨냅스 프로젝트를 진행하면서 에러 관리의 필요성을 느꼈었는데, 이를 다음 프로젝트를 할 땐 개선을 하자고 결심해놓고 개발을 하면서 에러를 그저 해결하기에 바빠 이번에도 정리하는 것을 깜빡했다.
프로젝트가 끝나고 결과물을 발표하는 시간에 다른 팀에서 에러 관리 문서를 공동으로 관리하면서 에러의 종류와 에러 메시지, 에러를 해결하는데 참고한 레퍼런스를 날짜별로 정리하는 걸 보고 감탄했다.
3차 프로젝트를 진행할 때는 그렇게 해보려고 한다.

2. DB 선택 시 장단점 비교 소홀

냉정하게 말해서 나는 나한테 익숙한 것을 선호하는 안 좋은 습관이 있다.
이번 프로젝트에서 DB를 선택할 때 그 안 좋은 습관이 악영향을 미쳤다.
내가 백엔드를 맡으면서 자연스럽게 DB까지 맡게 됐는데, NoSQL의 다양한 장점을 알면서도 내가 오래 사용했고 또 그래도 잘 아는 DB가 RDBMS라는 이유로 MySQL을 선택했다.
하지만 GraphQL을 배우고 사용하면서 이 선택을 반성했다.
GraphQL도 처음에는 새로 배우는게 어렵고 낯설어 개발 진도를 빼는데 시간이 좀 걸렸지만 좀 익히고 나니 내가 새로운 것을 배웠다는 성취감이 느껴졌고, 다른 API 관리 방식에도 관심이 생겼다.
마치 외국어 하나를 익히면 다른 외국어를 배울 때 장벽이 낮아지는 것처럼, RDBMS가 나의 모국어라고 했을 때 (여기서 내가 SQLD를 한 번에 붙었다고 자랑하고 싶다😉) NoSQL을 제대로 사용하는 방법을 배우고 익혔으면 다른 DB로 넘어가기도 쉬웠을 것이다.
그런데 그걸 배우고 익히기 딱 좋은 부트캠프 프로젝트 기간에 기회를 놓쳐버린 것 같아 아쉽다.
특히 다른 팀에 속한 동기와 DB관련하여 이야기를 나누다 MongoDB Atlas를 사용했더니 괜찮았더란 얘길 듣고 더욱 그런 기분을 느꼈다.
예전에 회사에서 잠깐 MongoDB를 써봤었는데, 이번에 제대로 배울 걸 그랬다.
다음 프로젝트에서 또 내가 DB를 관리하게 된다면 이번엔 MongoDB Atlas를 써보고 싶다.

3. 좋아요 기능 구현 시 가스비 해결 실패

이번 프로젝트 블로깅을 하면서 가장 부끄럽고 민망한 부분이 토큰 컨트랙트 부분이었다.
스팀잇에서는 사용자A가 사용자B의 글이나 댓글에 voting을 하여 토큰을 전송할 수 있다.
그런데 이 기능을 우리 프로젝트에서 진행하려고 하니 가스비 이슈가 발생했다.
회원가입을 하면 wallet을 새로 생성하여 account를 만들고 그 계정에 토큰을 넣어주는 방식이라 우리가 만든 토큰은 있어도 이더는 없는 텅 빈 계정인데, ropsten 네트워크에 배포하다 보니 사용자 간에 토큰을 전송하는 트랜잭션이 발생하면 가스비를 내야 하는 것이다.
이 가스비를 토큰 컨트랙트를 발행한 계정에서 제공하기 위해 approve를 사용하는 방법을 연구했으나 계속 에러가 발생했고, 적절한 해답을 찾지 못해 스택 익스체인지에 질문도 올렸다. (https://ethereum.stackexchange.com/questions/130916/is-it-possible-send-erc20-token-from-user-to-user-but-server-pays-gas-fee)
이 질문에 대한 답변으로 다른 사용자가 permit을 사용하는 방법을 제안했고, 오픈제플린의 문서를 참고하여 (https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC20Permit) permit으로 가스비를 대신 낼 방법을 찾아 연구했다.
하지만 이 또한 시간 내에 에러를 해결하지 못하고 실패하여 결국 새로운 사용자가 회원가입을 하면 그 계정으로 롭스텐 이더를 1개씩 전송하여 가스비를 낼 때 사용하도록 했다.
이건 정말 말도 안 되는 해결 방식이라 생각해 토큰 전송 기능 구현의 담당자로서 자괴감을 느끼고 다른 팀원들에게 부끄럽고 미안했다.
후에 voting 기능을 구현한 다른 팀은 어떻게 했는지 들어보니, 토큰을 DB에서만 관리하여 실제 트랜잭션은 발생하지 않고 DB에서만 토큰의 갯수를 변경하고 NFT 구매 등 토큰을 사용할 때 토큰 발행 계정에서 트랜잭션을 발생시켜 사용자의 정보를 등록하는 식으로 구현하는 케이스가 있었다.
그렇게 했으면 포스팅이나 좋아요 클릭 후 자신의 토큰 정보가 늦게 조회되지도 않았을 것이고 훨씬 빨랐을텐데 왜 그런 생각을 하지 못했는지 너무 아쉬웠다.
다음 프로젝트에서는 최대한 서버와 DB를 활용하는 쪽으로 진행할 것이다.

마무리

2차 프로젝트도 이렇게 끝났다.
구현이 아쉬운 부분도 있었지만 그래도 정해진 시간 내에 필요한 기능을 구현하고 리팩토링까지 완료했다는 점에 의의를 둔다.
다음 프로젝트는 팀원들끼리 아이디어를 내어 앱을 개발하는 프로젝트인데, 기간이 4주나 돼 규모도 커질 것 같아 걱정스럽다.
하지만 내가 해야 할 과제가 있고, 그 과제를 차근차근 해결하면 곧 근면성실한 삶을 사는 것이 된다는 게 좋다. 얼른 취업해서 내가 개발한 결과물로 수익이 나는 걸 보고 싶다.