Marbox 개인 회고

MarBox(팀 프로젝트) 개인 회고

프로젝트 간략 소개

프로그래머스 백엔드 데브코스에 참여하면서 약 2주간 팀 프로젝트를 진행했다.팀 프로젝트의 주제는 클론 코딩이었다. 우리 팀은 CGV의 예매 API를 클론했다.

 

개인적인 목표

프로젝트를 진행하면서 개인적인 목표를 설정했다.

1. 단순한 기능 구현이 아닌 고민을 통한 기능 구현.
2. 최대한 현업과 비슷한 프로세스로 개발. 그러면서 필요한 기술을 익히고 도입.

 

좋았던 점

단순 기능 구현이 아니라 하나의 기능을 구현하더라도 고민하고 구현했다. 안정적인 개발 프로세스를 위한 기술을 공부하고 도입했다. 그리고 소프트 스킬과 관련한 새로운 인사이트를 얻었다.

 

기능 고도화

프로젝트에서 로그인 기능 구현을 맡았다. 단순히 Jwt 토큰을 발급하고, 발급한 토큰으로 사용자를 인증하는 기능을 개발하고 싶지 않았다. 최대한 고도화 시키고 싶었다.

 

열심히 고민했고, 결과적으로 access token, refresh token과 redis를 사용하는 방식으로 개발했다. 이 과정에서 보안과 관련된 다양한 지식을 습득할 수 있었고, redis도 새롭게 공부했다.

 

개발 프로세스

CI

안정적인 개발 프로세스를 위해 고민했다. 팀 단위 프로젝트기 때문에 공유하는 브랜치(우리는 develop)는 항상 안전하게 관리하고 싶었다. 그래서 develop 브랜치에 merge하기 전 코드 컨벤션과 테스트와 빌드가 성공하는지 확인하고 싶었다.

 

이런 작업을 매번 하기는 비효율적이고 까먹을 수도 있다고 생각해 자동화하고 싶었다. 그래서 여러 자료를 찾다가 CI 개념에 대해 알게 됐고, GitHub Actions를 이용해 팀 프로젝트에 CI를 도입했다.

 

덕분에 develop 브랜치에서는 코드 컨벤션과 테스트 빌드가 정상적으로 실행된 소스 코드만 관리될 수 있게 됐다.

 

Git&GitHub

혼자 공부할 때는 Git과 GitHub의 일부 기능만 활용했다. 이번 팀 프로젝트를 계기로 Git, GitHub의 다양한 기능을 알게 됐고 이를 활용해 팀 프로젝트를 진행했다.

 

이 과정에서 Git, GitHub에 대한 숙련도가 올라간 것 같다.

 

개발 환경 분리

팀원 각자 local에서 개발 후 develop 브랜치에 merge 했다. 이 과정에서 우리의 소스 코드를 같이 테스트할 수 있는 서버가 있으면 좋겠다는 생각이 들었다.

 

AWS EC2, RDS를 활용해 테스트 서버를 구성했다. 덕분에 우리가 개발한 코드를 테스트 서버에서 동시에 여러 사람이 테스트할 수 있었다.

 

이 과정에서 로컬에서 사용할 DB, Redis를 Docker를 활용해 환경을 구성했다. 그리고 스프링의 프로파일 기능을 활용해 로컬환경과 테스트 서버 개발환경을 나누는 경험을 했다.

 

소프트 스킬

협업 방식

애자일 방법론을 도입해 개발하려 노력했다. 스프린트 단위를 1주일로 설정하고, MVP를 정해 개발했다. 또, 매일 팀 스크럼을 통해 팀원 간 어떤 기능을 개발하고 있는지 파악하고, develop 브랜치에 merge 하기 전 코드 리뷰를 통해 서로 피드백을 주고받았다.

 

MVP를 설정하고 개발함으로 목표로 하는 기능에 집중할 수 있었다. 그리고 코드 리뷰와 매일 하는 팀 스크럼을 통해 팀원들이 어떤 기능을 개발하고 있는지 파악할 수 있어 프로젝트의 방향성을 잡는 데 좋았다.

 

비동기 소통

팀 프로젝트 초기에는 비동기 소통을 잘 활용하지 못했다. 팀 간 의논 사항이 있으면 비동기 소통보다는 자주 미팅을 진행했다. 이 과정에서 팀원 모두 생산성이 떨어진다는 느낌을 받았다. 그래서 비동기 소통을 활용하자는 의견이 나왔다.

 

바로 해결돼야 하는 문제는 미팅을 진행했다. 그 외 문제는 슬랙을 이용해 비동기 소통을 활용했다. 덕분에 미팅 횟수가 줄어들고, 개인의 작업에 집중할 수 있어서 팀 생산성이 향상됐다.

 

PR 주의점

develop 브랜치에 기능을 merge 하기 전 코드 리뷰를 통해 2명이 approve 하면 merge 되도록 브랜치 전략을 세웠다. 덕분에 다른 분의 코드를 읽는 경험을 할 수 있었다. 이 과정에서 깨달은 것이 있었다.

 

코드 리뷰를 해보니, 많은 리소스가 투입되는 부분은 PR을 보낸 팀원의 문맥을 이해하는 부분이었다. 이를 통해서 내 PR 메시지를 통해 문맥을 파악하기 쉬운지, PR 단위는 적절한지에 대해 고민했다. 그리고 PR 단위는 이슈 단위로, PR 메시지는 문맥을 정확하게 설명할 수 있게 작성하려 노력했다.

 

아쉬웠던 점

역시 아쉬운 점도 있었다.

 

부족한 기능

기간이 짧고, 많은 시행착오를 거치다 보니 많은 기능을 개발하지 못했다. 이번 프로젝트를 진행하면서, 기능 개발, 기능 고도화, 새로운 기술 도입에 균등하게 리소스를 사용하려고 노력했다.

 

하지만 돌이켜 보면 기능 고도화, 새로운 기술 도입에 많은 리소스를 투자해 기능 개발에는 많은 리소스를 투자하지 못한 것 같다. 다음 프로젝트를 할 때는 기술 고도화와 새로운 기술 도입에는 러닝 커브를 생각하고 목표치를 설정해야겠다.

 

테스트 작성

테스트를 작성하려고 노력했다. 하지만 Spring Security 부분의 단위 테스트는 숙련도가 높지 않아 테스트를 작성하는데 생각보다 많은 시간이 들었다. 단위 테스트는 작성했지만, 통합 테스트는 최소한의 테스트만 작성했다. 이 부분이 아쉽다.

 

추가로 테스트를 작성했지만, 테스트 커버리지는 측정하지 못했다. 이 부분도 아쉬움이 남는 부분이다. 이는 다음에 Jacoco를 도입해 테스트 커버리지 측정할 수 있을 것 같다. 추가로 CI에 테스트 커버리지를 추가하면 더 안정적으로 프로젝트를 관리할 수 있을 것 같다.

 

성능 최적화

성능 측정도 하고, 최적화하는 과정도 도전하고 싶었는데 하지 못했다.

 

진행한 프로젝트에 성능적으로 튜닝할 부분이 많은 것 같다. 프로덕션 코드에는 트렌젝션 단위 또는 쿼리 튜닝이 있다. 테스트 코드에는 자주 사용되는 스프링 컨텍스를 통일하면 좀 더 빠른 테스트를 작성할 수 있을 것 같다.

 

이 부분도 추후 팀원들과 상의해 도전해야겠다.

 

마무리

나름 스스로 도전 거리를 만들어 해결해 갔다. 하지만 짧은 시간인 만큼 하고 싶었는데 못한 부분도 많고, 개선할 부분이 많이 보인다. 그래도 2주간 좋은 경험을 한 것 같다.

 

부족한 부분은 추후 팀원들과 논의해 보완해 나가야겠다.