[DEX PJ] #2 성공적인 프로젝트의 조건

 

 

DEX Project 진행 시 아쉬운 점

 

약 2주간 블록체인 DEX 프로젝트를 진행했다. 나를 포함한 총 3명의 참여자가 투입된 프로젝트였고, 기간은 2주로 짧은 시간 동안 컨트랙트를 작성하고, 프론트와 백엔드를 붙여서 만들어보는 간단한 프로젝트였다.

 

문제의 시작(소통 부재)

 

 

부트캠프를 참여하면서 이미 3번의 프로젝트를 진행하면서 느낀 부분은 소통이 힘들다는 점이었다. 서비스를 하나 만들기 위해서는 피그마를 통해 만들고자 하는 프로젝트를 시각화하면서 구체적인 기능들에 대한 명세를 세세한 부분들을 사전 정의를 내려야 한다는 점이었다.

프로젝트 기획이 꼼꼼하면 꼼꼼할수록 더 완성도 있는 프로젝트가 만들어진다는 점은 어찌 보면 당연한 일이다. 하지만 개발을 처음 시작하는 우리들 입장에서는 당장 키보드를 두드리고, 화면에 서비스의 형태를 빨리 보고 싶은 마음을 지우기 힘든 것도 사실이다.

프로젝트에 참여하면서 구체적인 파트를 담당하게 되고, 각 파트별로 소통이 필수적이다. 프론트와 백엔드는 API문서에 대한 정의가 당연히 되어야 하고, 백엔드와 컨트랙트 또한 블록체인의 입출력에 대한 논의가 진행되어야 한다.

이번 프로젝트를 참여하면서 느낀점은 소통이 정말 힘들다는 점이다. 팀원 중 한명은 다른 프로젝트를 동시에 진행하고 있는 상황에서 함께 하게 되서 시간이 별로 없어 보였다. 다른 분도 바빠보여서 전체적으로 프로젝트에 집중할 수 있는 절대적인 시간을 내지 못해보였다.

총 3명이서 프론트 + 백엔드 + 컨트랙트 3개의 파트로 분담하게 되었고, 나는 각 파트별로 진행 중인 내용을 명확하게 공유하기 위해 Git Issue + Milestone + Project + 칸반보드를 통해 명시적으로 프로젝트를 관리하자는 의견을 냈고, 다들 동의했다.

하지만, 막상 프로젝트가 진행되고 나서 보니 Git Issue에 실제 업무를 올리는 경우도 거의 없고, 한번 제시된 이슈가 Closing 되는 경우가 없었다.(결국 프로젝트 관리도 안되고 소통도 전혀 안되는 상황). 그냥 회의에만 참여한다고 해서 소통이 되는게 아니다. 내가 봤을 땐 전혀 논의가 진행되고 있지 않은데, 팀원들은 이대로도 충분하다고 생각하는 걸로 보였다. 

매일 2번의 회의를 진행했지만, 누구 하나 다른 사람이 맡고 있는 부분이 어제와 같은 상황이지만 왜 안되는지 어디서 막혀 있는지 물어보는 경우도 없었고, 이에 대한 건설적인 논의가 진행되지도 않았다. 이렇게 회의를 할거면 아예 안하느니만 못한 회의가 계속 진행되었다.

소통이 안되니 자연스레 서비스 내의 데이터 입출력 혼선이 발생하기 시작한다. 백엔드에서 프론트엔드로 보내야 하는 데이터, 블록체인에서 백엔드로 가져와야 하는 데이터 정의가 안된다. 애초에 필요한 데이터는 컨트랙트에서 누락되었고, 백엔드 API 작업은 계속 지연되어 갔다. 

 

마감기한 준수

 

프로젝트는 유한한 시간안에 완성되어야 한다. 따라서 프로젝트 진행 상황에 대해 일정이 관리되어야 하고, 각각 맡은 업무에 대한 작은 단위의 업무들도 완성 시간이 정해져 있어야 한다. 내가 맡은 업무가 지연되면 자연스레 프로젝트 마감기한을 준수하지 못하게 된다.

또한 프로젝트를 완성하는 기간에는 여유 시간을 둬야 한다. 80% 정도 안에 전체적인 코드 작업과 리팩토링이 다 완료되어야 하고, 나머지 시간에는 미비한 부분을 보완하고, 서류작업을 진행할 필요가 있다. 

하지만 이번에는 프로젝트가 끝나기 1일 전 까지도 컨트랙트 부분은 계속 수정되고 있었고, 백엔드와 블록체인을 붙이는 작업이 지연되고 있는 상황에서 에러가 계속 발생했다. 이 컨트랙트가 왜 에러가 나냐고 물어보니 애초에 기획했던 것과 완전히 다른 컨트랙트가 완성되어가고 있었고, 내가 작업했던 대부분의 코드가 사용되지 않는 참사가 발생한다.

프로젝트가 완료되어야 하는 마감날에도 각 dev 브랜치에서 분기한 각 파트별 담당자들이 작업한 코드들은 merge가 되지도 않은 상황이었다. 코드가 완성되지 않으니 당연히 프로젝트를 설명하는 발표자료들 또한 작업이 안되었다. 결국 프로젝트는 완성되지 않은 채로 끝이 났다. 

 

프로젝트 진행 시 유의사항

 

부트캠프를 참여하는 경우 프로젝트를 진행하게 된다. 특정 주제를 가지고 결과물을 내기 위해 여러명의 참여자들과 함께 진행하는 프로젝트에서는 반드시 유의할 점이 있다. 

총 4번의 프로젝트를 진행했고, 프로젝트를 이제 막 참여하고자 하시는 분들에게 꼭 말씀드리고 싶은 부분은 소통이다. 각각 파트를 담당해서 작업을 진행하게 되는데, 프로젝트 진행 부분을 명시적으로 모니터링 할 수 있어야 한다. 파트별로 세부적으로 작업내용을 명시해야 하고, 마감 기한을 정해야 한다.

만약 작업내용을 공유하면서 어제 하고자 했던 작업이 안된 경우, 어디서 막혔고, 솔루션은 무엇인지 언제 끝낼 수 있을지 어떤 부분에 대한 도움이 필요한지 등에 대한 질문에 대답을 못하는 경우 프로젝트의 성공률은 낮아질 수 밖에 없다. 

마감기한을 초과한 작업 내용에 대해서는 어디서 막혔는지, 어떻게 해결할 수 있을지 솔루션을 찾는 일을 한 사람에게만 맡겨놓아서는 안된다. 자유와 책임이 중요하지만 프로젝트를 완성시키는 입장에서는 각각 맡은 분야에 대한 공유는 자유가 아닌 책임의 영역이라는 생각이 강하게 든다.

프로젝트의 기획은 세부적으로 사전 정의되어야 한다. 피그마를 통해 UI를 그려놓는 건 당연한 일이며, 서비스에서 구현해야 하는 기능들에 대해서 섬세한 정의가 진행되어야 할 것이다. 막연하게 NFT 민팅 기능을 구현하기 보다는 어떤 토큰을 사용할 지, 수수료는 얼마로 할지, 트랜잭션은 몇번을 일으킬지 등등 단순하게 NFT 기능에도 여러가지 요구사항을 정의할 필요가 있다.

마감기한을 고려해야 한다. 프로젝트가 끝나기 하루전까지 코드를 수정해야 하는 경우는 최대한 만들지 말아야 한다. 80% 기간 안에 코드 수정은 모두 완료되어야 하고, 나머지 시간은 프로젝트를 설명하는 README나 PPT, 시연연상을 작성하는데 시간을 써야 한다. 

결국 프로젝트라는 건 개개인의 작업물이 유기적으로 모여 만들어져가는 것이다. 만약 한명의 작업 사항이 지연되고, 불통이 된다면 프로젝트는 기울어 갈 것이고, 결국 실패로 이어질 것이다. 

4개의 프로젝트를 진행하면서 농담이라도 "버스를 탄다"라는 말을 하는 참여자도 있었다. 말 그대로 본인의 역량으로 프로젝트에 기여하는 것 보다 다른 사람의 역량에 뭍어가려고 하는 참여자가 있다는게 개인적으로 충격적이었다. 사람이 모일 수록 약해지는 건 조별과제라는 말이 괜히 나오는게 아니라는 걸 실감할 수 있었다. 

사이드 프로젝트를 진행할 때도 가장 힘든 점이 사람을 모으는 일이다. 단순히 역량만 뛰어난 사람을 모셔오는 것도 답은 아니다. 팀원 모두 한곳의 방향을 볼 수 있어야 한다. 쉽게 말해 마음이 맞는 사람을 찾는게 이만큼이나 힘든 일이다. 

프로젝트를 여러개 경험하면서 혼자서 코드만 잘해서는 프로젝트를 성공할 수 없다는 걸 실감할 수 있었다. 프로젝트 일정 관리, README 작성, 컨셉 정의, 요구사항 정의 등 50% 이상 부분은 코드 외적인 부분이 차지하고 있다.

이번 프로젝트 결과가 아쉬운 만큼, 다음번에 프로젝트에 참여하는 경우 참여 자체를 신중하게 결정할 것 같고, 참여를 하더라도 코드 작성과 동일하게 소통, 컨셉 사전 정의 등에 무게를 둘 겉 같다.  

 

 

[Dex PJ] #1 프로젝트 시작