Super Invention 프로젝트 소개

프로젝트 기획과 팀원 모집

회사에 입사를 한 후 느낀 것은 사용하고 싶은 기술을 모두 사용하기는 어렵다는 점입니다. 기존 프로젝트의 기술 스택을 따라가야 하기도 하고, 추가적으로 적용하는 기술과 기존 기술의 호환성 문제도 따져보아야 하며 적용한 코드를 나만 관리하는 것이 아니기 때문입니다. 그렇기 때문에 신 기술을 익히고 적용하는 최고의 방법은 개인적인 사이드 프로젝트를 통해 개발하고, 적용하며 시행착오를 겪어보는 것이라 생각합니다.

 

이번 프로젝트는 '쓰고 싶은 기술을 다 써보자'라는 마음으로 시작한 프로젝트입니다. 평소에 사용해보고 싶었지만 사용하지 못했던 기술, 배우고 싶었던 기술, 실전에서 쓰기 전 연습이 필요한 기술들을 이 프로젝트를 통해 익히고자 하는 원대한 꿈(?)을 꾸며 시작하였습니다. 회사를 다니며 진행할 사이드 프로젝트였기에 일주일 중 투자할 수 있는 시간은 크지 않았고, 같은 생각을 하는 팀원을 모아 진행하기로 결심하였습니다. 적용해보고 싶은 기술을 리스트업 하며 만든 팀원 모집공고가 이렇게 작성되었습니다.

 

자네 나와 팀을 이뤄보겠나?

 

팀원을 모집할 때 가장 중요하게 생각한 것은 현재 기술 상황도, 경력도 아닌 공부하고자 하는 의지였습니다. 기간을 6개월정도로 넉넉하게 잡아두었기 때문에 매주마다 조금씩이라도 시간을 투자할 수 있는 분을 찾았습니다. 각종 오픈 커뮤니티, 오픈 카톡방, 지인 추천 등을 통해 팀 Task Force가 생성되었습니다.

 

Super Invention 기술 스택

Back-end

- Spring MVC

- JPA

- Kotlin

- MySQL

Front-end

- Vue.js

- vuetify

Infra

- Github Action (CI/CD)

- AWS (RDS, EC2, S3 등)

프로젝트 기획과 진행

프로젝트의 목표

프로젝트의 가장 큰 목표는 '사용해 보고 싶은 기술은 다 써보자' 였기 때문에 어떤 주제를 가지고 만들지는 크게 중요하지 않았습니다. 그렇기 때문에 평소에 생각하고 있었던 모임 커뮤니티 웹 어플리케이션을 제작해보는 것으로 가벼운 마음으로 주제를 정하였습니다. 세세한 비즈니스 로직은 기존 나와있는 애플리케이션에서 모티브를 얻어 제작하고, 개발자들은 기획보다는 개발적인 스킬과 로직 구성에 더 큰 힘을 쏟을 수 있도록 하기로 하였습니다.

 

업무 공유

업무의 배분과 진행 방식의 공유는 Jira와 같은 칸반 보드를 사용해볼까? 라는 생각이 들었습니다. 다만, Jira와 Github를 연동하는 것에 여러 작업이 필요하였고 이미 Github에는 프로젝트 보드를 관리하는 유용한 Github Project 기능이 있었습니다. 개발 진행 공유는 이 기능을 사용하기로 하였습니다.

 

아래 사진은 1주차 스프린트 보드입니다. Github Project의 Project Template 중 하나인 Kanban With Review를 사용하면 아래와 같은 칸반 보드가 생성됩니다. (이걸 스프린트 보드로 사용하기는 했습니다만) 이 보드에 매주 1회 스크럼을 하며 개발할 이슈들을 생성한 후, 프론트와 백엔드에서 각각 이슈에 어떻게 개발할지 댓글을 남기며 조율하였습니다.

이번주에 진행할 업무를 보드에 작성한다

진행할 업무의 이슈화

코드 리뷰

날카로운 코드 리뷰..!!

모든 코드는 팀원들의 동의가 있어야만 개발 서버에 머지할 수 있도록 만들어두었습니다. 이 과정에서 꼼꼼한 코드 리뷰를 통해 여러가지 긍정적인 장점을 기대할 수 있었습니다.

 

1. 서로의 코드를 모두 읽기 때문에 각 코드에 모르는 부분이 현저하게 줄어듭니다
2. 모르고 있던 이슈나, 발생 가능한 오류를 미리 캐치할 수 있습니다
3. 새로 익히는 기술에 대한 파일럿 코드를 작성한 후, 팀원에게 설명해줄 수 있습니다. 팀원은 이해하지 못하면 코드를 머지하지 않으며 서로의 코드가 이해될 때 코드를 머지합니다

API의 문서화

Front-end를 개발하는 팀원들과 url 엔드포인트를 항상 공유하기는 번거롭고 어렵습니다. 그렇기 때문에 Rest docs를 제작하여 모든 엔드포인트에 대해 문서화를 진행하기로 하였습니다. Back end와 Front end 모두 이 문서를 통해 소통을 진행합니다.

 

추가적인 엔드포인트 요청은 이렇게 진행하였다

새로운 엔드포인트 요청이 필요할 때는 이슈 생성을 통해 소통하였습니다. 변수명의 변경 요청, 새로운 엔드포인트 생성 요청 등 모든 소통을 문서를 기반으로 진행하게 되니 불필요한 커뮤니케이션 리소스가 줄어들었습니다. 회의 또한 주당 1회의 스크럼으로 충분해졌고 전달이 잘못되어 발생하는 혼란을 최소화할 수 있었습니다.

 

CI / CD

Gitgub Action을 사용하여 CI/CD를 모두 구성해보기로 하였습니다. 젠킨스에 비해 구성하기도 편리하였고 제일 좋았던 점은 별도의 CI/CD 서버를 구성하지 않아도 된다는 점이었습니다. 구성한 액션은 총 두 개입니다.

 

1. 코드 무결성 체크

팀원들이 Pull Request를 날릴 때 빌드, 테스트를 진행하여 코드의 무결성을 체크합니다. 테스트가 실패하거나 빌드가 실패하면 그 즉시 Pull Request에 실패를 알려줍니다. 빌드만 진행하고 개발서버 등 배포를 진행하지 않는 액션입니다.

 

2. 개발서버로 배포

개발서버로의 배포는 원버튼 배포 방식을 채택하였습니다. 브랜치에 머지시 CD를 진행하기에는 Rest Docs와 여러 빌드 루틴으로 인해 프로젝트의 빌드가 꽤 느렸고, 리뷰를 하고 머지를 하는 과정에서 한 번에 여러 PR이 동시에 빌드되기도 하는 문제점이 있었기 때문입니다. 배포하기 원버튼 클릭으로 develop 브랜치에 있는 코드가 개발서버로 바로 배포됩니다. (github action은 참 편리합니다)

 

앞으로의 진행 계획

지금까지 진행한 스프린트 보드

벌써 프로젝트를 시작한지 3개월이 지났습니다. 1주당 8시간 정도의 개발 시간을 가지고 진행하는 프로젝트인 만큼 속도가 빠르지는 않지만, 탄탄하게 계획을 잡고 사용해보고 싶은 여러 기술들을 사용해보니 개발에 '재미'를 붙이고 할 수 있는 것 같습니다. 개발이 더 진행되면 AWS 서버를 새로 하나 생성한 후, 실제로 접속하여 실행할 수 있도록 엔드포인트를 개방해 둘 계획입니다. 

 

프로젝트에서 사용하는 여러 기술들과 진행상황에 대해 리뷰할 생각입니다. 프로젝트 팀장을 하며 배운 점도 많고 새롭게 알게된 점도 많은데 이를 꼭 공유해보고 싶습니다.

 

그리고 기회가 된다면 다른 분들께도 꼭 사이드프로젝트를 진행해보라고 권유드리고 싶습니다. 하고 싶은 개발을 하며 개발자의 가장 큰 적인 번아웃을 예방할 수 있고 꾸준한 자기 계발을 통해 성장할 수 있기 때문입니다.