[Techeer] Schoolvery

🗺️ Overview

배달비 공유 서비스 입니다.

▫️ 서비스 소개

👿 문제점/배경

당시 배달 비용에 대한 문제가 대두되기 시작한 시점이었다. 격차가 있긴 했지만 거리가 먼 지역은 배달비만 6,000원이 넘는 곳도 있었다.

배달 비용 뿐만 아니라 최소 주문 금액으로 인해 필요 이상의 음식을 주문하는 것에 대한 문제도 있었다.

특히 학생들의 경우 안정적이고 많은 수입이 있거나 금전적인 여유가 있지 않은 경우가 많아 이에 부담을 느낀다는 불편함을 소호하는 사람들이 많았다.

근거리에 있는 사람들과 동일한 가게에서 음식을 주문할 경우 배달비를 분할함으로써 배달비에 대한 부담도 줄일 수 있고 최소주문 금액에 대한 걱정도 줄어들 수 있다고 생각했다.

🫠 해결 방안

따라서 함께 주문할 수 있는 플랫폼 서비스를 기획하였다.

해당 서비스를 통해 함께 배달 주문할 사람들을 모집하는 것이 메인 기능이었다.

에타나 다른 플랫폼에서도 모집할 수 있지만, 우리 서비스에서는 음식 카테고리 별, 가게별로 모아볼 수 있는 차별점을 통해 사용자들이 더욱 편리하게 사용할 수 있도록 하였다.

▫️ 서비스 데모

모집 글 확인하기(카테고리 별, 가게 검색) / 모집 상세페이지

모집 글 등록하기 / 채팅페이지

로그인 / 회원가입

마이페이지

▫️ 프로젝트 운영

개발자 커뮤니티 Techeer에서 팀원을 구성해 진행한 사이드 프로젝트다.

6개월 간 진행했으며, 백엔드 3명, 프론트 1명, 인프라 1명으로 구성되었다.

나는 해당 프로젝트에서 리더와 백엔드를 맡았다.

프로젝트를 시작 전 팀구성을 완료하고 고민을 많이 했다.

처음 리더를 해보는 것이라 어떻게 해야 모든 팀원들이 애정을 가지고 참여할까 생각했다. 해당 프로젝트는 사이드 프로젝트로 처음의 기세를 마지막까지 유지해서 서비스를 완성 시키는 것에 1차 목적이 있었다.

(많은 사이드 프로젝트를 보고 해봤지만 외부의 강압이나 마감, 압력이 없는 상황에서 끝까지 완성도 있게 서비스를 만드는 것이 생각보다 쉬운 일이 아니였다. 다들 학업이나 회사라는 본업이 있었기 때문에 자연스레 사이드 프로젝트의 우선순위가 밀리기 쉬웠기 때문이다. )

1️⃣ 당시 내가 내렸던 답은 리더인 내가 제일 열심히 하는 것이였다. '나 먼저 잘하자', '나나 잘하자'가 지금도 그렇지만 그때도 내 기저에 있는 생각이었고, 내가 열정을 가지고 하면 팀원들도 같이 열심히 해줄거라 믿고 있었다.

2️⃣ 두 번째로 팀원들이 개발하기 편한 환경, 개발만 할 수 있는 환경을 만들어주자였다. 그 이유는 다들 개발 자체는 좋아하는 사람들이었으므로, 개발을 막상 하면 열심히 잘 하는 사람들이었다. 그래서 내가 생각한 것은 하기 싫다라거나 귀찮다거나, 시작하기 싫은 그 초반의 허들을 낮추고 줄이는 것이었다. 그래서 문서 정리, 기획 문서, 역할 분담, 일정 조절, 구현 기능 리스트 정리 등 귀찮은 일들은 시간을 내서 최대한 하려고 노력했다.

3️⃣ 세 번째로 모든 팀원들의 의견을 적극적으로 반영하려고 노력했다. 미팅을 진행할 때 기획이든, 기능이든, 기술적인 부분이든 모든 팀원들의 의견을 물어보고 토론을 통해 함께 결정하고 최대한 개개인의 생각을 반영하려고 노력했다. 이유는 개인의 자율성과 적극성을 최대한 발휘할 수 있도록 하기 위해서였다. 부트캠프 멘토를 하며 다른 사람들이 결정하는 것을 수동적으로 받아들이고 시키는 것을 하기만 하는 사람들을 많이 보았는데, 사실 그래도 프로젝트를 완성시키는 데에는 겉보기에 문제가 없지만 내가 지향하는 방향은 자율성과 적극성, 주인의식을 가지는 것에 있었기에 위와 같은 노력을 하였다.

4️⃣ 네 번째로는 유머러스하고 라이트하면서도 서비스 개발에서는 진지하고 책임감 있는 분위기를 만드는 것이었다. (이건 의도하거나 계산하고 행동한 것은 아니고 그냥 자연스럽게 되는데 나의 원초적인 성격인 것 같다.) 사실 비즈니스적으로만 접근하여 딱딱한 분위기를 만드는 것도 할 수 있었고, 어떠한 상황에서는 그런 환경이 효과가 있을 수도 있다. 하지만 위에서 언급했듯이 본업이 각자 따로 있는 바쁜 상황에서의 사이드 프로젝트였으므로, 가볍게 들어와서 같이 개발적인 부분이나 서비스적인 부분이나 얘기를 수다 떨듯 하면서 재미를 느끼게 하고싶었다. 잘하고 열정도 있는 사람들이라 일단 시작하면 피곤감도 잊고 물 흐르듯이 서비스에 대한 이야기나 개발을 할 수 있었다. 가뜩이나 빡빡한 일정에 이것까지 해야된다는 부담감이나 하기 싫다는 거부감을 줄이고 싶었다. 그리고 개그 코드 맞는 팀원들과 함께 개발한다는 것은 눈에 보이는 것 말고 그 이상으로 좋은 긍정적인 에너지를 가지고 있고 이것은 생각보다 더 좋은 시너지를 낼 수 있다. 이것은 밸런스 게임처럼 극과극의 선택지가 있는 것은 아니고 상황, 환경, 사람에 따라 정도를 조절하는 것이라고 생각한다.

5️⃣ 마지막으로 개발적인 지식을 많이 공유하는 것이었다. 아무리 사이가 좋고 분위기가 좋아도 모두의 목적은 당시 좋은 서비스를 만들고 원하는 회사에 합격하는 것이었기 때문에 가장 우선순위가 높은 것은 개발적인 실력 성장과 서비스의 퀄리티였다. 사실 나는 개발적인 역량이나 자질이 엄청 뛰어난 것은 아니였으므로, 이를 충족하기 위해 책도 읽고 강의도 듣고 또 여러 외부 스터디나 커뮤니티에 참여하여 다양한 정보와 지식들을 쌓았다. 그 중 하나다 우아한 스터디였다.


🥅 Goal

  • 서비스 출시 및 실제 서비스 운영


🛠️ Tech Stack

  • Spring Boot, Java, QueryDSL, SLF4J, Docker, MySQL, Github Action, AWS EC2, AWS Route 53


🏛️ Architecture


📕 Contributions

  • Leader

    • 2주 단위의 스프린트를 작성 및 관리하고, 역할 분담 및 전반적인 프로젝트 매니징 담당

    • Github PR 규칙, Commit Convention, Code Style 문서화 및 적용

  • 모집 게시글 올리기

    • Spring Data JPA를 사용하여 모집 게시글 도메인에 해당하는 RESTful API를 개발

    • 동적인 쿼리 작성을 위해 QueryDSL을 도입하여 Pagination, Searching 기능 추가

    • 협업 및 테스트 용이성 증대를 위해 Swagger를 사용하여 API 문서화

  • DevOps

    • 컨테이너 환경 구축을 위한 Docker 세팅 및 Github Action을 사용한 CI/CD 파이프라인 작성

    • Prometheus/Grafana를 사용한 메트릭 시각화 및 해당 대시보드를 통한 AWS EC2 상태 모니터링


🎖️ Achievements

  • 팀원들 다들 취업 성공.

  • 여러 대학교에서 서비스 운영.


🔥 Challenge

  • 정산

  • 모집 위치


🔗 Github


📒 회고

  • 총 5명의 팀원들이 있었는데, 당시 4명이 학생, 1명이 회사원이었다. 프로젝트 이후 4명 다 회사에 취직하거나 나는 소마에 붙었다. 가끔 모이면 스쿨버리 도움이었다고 하는데 뿌듯하고 자랑스럽고 기분이 좋았다.

  • 프로젝트가 끝난 이후에도 팀원들과 계속해서 슬랙으로 소통하며 스터디 및 이런 저런 개발 얘기들을 공유했다.

Last updated