백엔드 개발자의 첫 1인 개발 도전기 - [캠퍼스클럽]

 

저는 평소 1인 개발을 통해 수익화를 경험해보고 싶은 목표가 있었고 이번에 그 첫걸음을 내디뎠습니다.

개발과 앱 검수 기간을 포함해 이번 3월 한 달 동안 프로젝트를 진행해 앱 하나를 만들어 출시하게 되었습니다.

 

앱 이름은 캠퍼스클럽으로 언제 어디서든 학교 학생이라면 자신의 학교에 모든 동아리를 살펴볼 수 있고

만약 동아리 관리자라면 캠퍼스클럽에서 모집공고를 게시하고 지원자들을 관리할 수 있는 기능을 가진 애플리케이션입니다.

---

캠퍼스 클럽을 만들게 된 계기

 

대학교 커뮤니티 사이트인 에브리타임을 둘러보던 도중 동아리 존재 유무에 대한 질문과 현재 모집하는 동아리가 있는지에 대한 질문들이 자주 올라오는 것을 발견하였습니다.

이런 글이 올라오는 이유를 파악해 보니 대학교 동아리들은 모집 기간에만 모집 공고를 올리기 때문에 모집 기간이 아니라면 학생들은 교내에 어떤 동아리들이 있는지 파악하는 것이 어려웠습니다.

또 모집공고에서도 동아리 관리자들은 구글 폼 등의 외부 툴을 활용하여 지원자를 모집하는 경우가 많아 학생들은 동아리에 지원할 때 매번 자신의 정보를 직접 새로 입력해야 한다는 불편함이 있었고 동아리 관리자들이 지원자 관리하는 것 또한 어렵다는 문제를 발견하였습니다.

이러한 문제를 해결하기 위해 동아리 모집 기간이 아니더라도 언제 어디서든 교내 동아리들을 볼 수 있도록 하고 회원가입 시 입력한 학생 정보를 바탕으로 클릭 1번으로 동아리 지원을 할 수 있으며 동아리 관리자들에게는 모집 공고를 올리고 지원자들을 관리할 수 있는 동아리 관리 기능을 제공하는 어플리케이션인 캠퍼스클럽을 기획 및 개발하게 되었습니다.

 

 

 

---

 

난생처음 해보는 앱 기획

회사에서는 기획자 분들이 어느 정도 기획을 해놓은 틀에 제 생각을 가미한 경험은 있어도 처음부터 앱을 기획하는 건 처음이었습니다.

 

일단 앱이 가진 목표는 모집 기간이 아니더라도 동아리를 볼 수 있게 하는 것으로 명확하니

이 기능을 중심으로 최소 기능 애플리케이션인 MVP 모델을 기획해 보자라고 생각하였습니다.

 

문서화를 해두면 좋겠지만 저는 회사와 학교를 병행하고 있기에 퇴근 이후나 주말 정도가 투자할 수 있는 시간의 전부였습니다.

그래서 시간을 너무 오래 쓰고 싶지는 않았기에 따로 IR 문서 같은 건 만들지 않고 머릿속의 생각을 끄적이며 기능들을 잡아나갔습니다.

 

일단 가장 기본적으로 적용하고 싶은 기능은 아래 3가지였습니다.

 

1. 동아리 CRUD

2. 모집공고 CRUD 및 모집 공고를 통해 동아리 지원 기능

3. 지원자 합불 관리 및 멤버 관리 기능

 

사실 기획하면서 동아리 소개 페이지 꾸미기나 동아리 운영진 관리자 웹페이지 등을 제공하면 좋겠다는 욕심이 생겼지만

MVP 모델이니까 최대한 간단하게 내서 반응을 먼저 보는 걸 우선하자라고 생각해 전부 쳐냈습니다.

 

그리고 에브리타임처럼 학교 바운더리로 나누어 운영하려고 계획하였고 일단 순천향대학교만을 타깃 하여 운영해 보기로 결정하였습니다.

학교 인증은 학교 메일을 통해 인증 코드를 보내고 일치하는지 검사하는 방식으로 구현하기로 계획하였습니다.

 

처음부터 많은 기능을 탑재하지 않고 최소한의 기능만을 개발하는 해커톤에 경험이 있다 보니

이렇게 MVP 기능들을 빠르게 생각해 내고 기획하는 것에 도움이 되었습니다.

---

가장 어려웠지만 의외로 재밌었던 디자인

저는 평소 디자인 감각이 없다고 생각합니다.

색상이나 폰트를 봐도 뭐가 예쁘고 뭐가 좋은 건지 잘 모르겠습니다.

근데 일상생활에서 잘 꾸며진 앱들을 보다 보니 저도 어느 정도는 보는 눈이 생긴 것 같습니다.

앱 디자인을 어디서부터 시작해야 할지 막막했지만 막상 하나하나 시도하고 적용하다 보니 술술 풀리고 또 재미도 있었습니다.

그렇게 아래와 같이 여러 디자인들을 뽑아내며 최종적인 컨셉 색상과 디자인 패턴들을 완성하였습니다.

---

설계와 디자인을 토대로 개발하기

개발 스택은 최대한 빠르게 개발하기 위해 익숙한 기술 스택들을 사용하였습니다.

• 앱 (ios, aos) : 크로스 플랫폼인 React Native 사용
• API 서버 : Python - FastAPI
• 인프라 : AWS EC2, S3, VPC, Load Balancer 등등

크게 어렵고 복잡한 기능들은 없었기 때문에 API 서버를 개발하는 것에는 크게 어려움이 없었습니다.

대신 인프라 영역에 어려움이 있었는데 익숙하지 않다 보니 인프라 아키텍처를 어떻게 설계하고 비용을 최소로 유지하기 위해 어떻게 해야 할지 등이 대한 고민이 많았습니다.

 

여러 검색과 고민들을 반복한 결과 가상 머신 하나를 빌려 API 서버와 DB, Redis 등을 몰아넣는 게 비용적으로나 관리적으로 가장 효율적이라고 판단했습니다.

DB로 RDS를 연결할까도 생각했지만 RDS의 비용을 한 달로 계산했을 때 무서운 비용이 발생했고

EC2 하나에 몰아넣어도 학교 전교생의 트래픽 정도는 감당이 가능했기 때문에

굳이 비용을 더 들여가며 서버를 여러 대 두고 싶지는 않았습니다.

 

설계한 인프라 아키텍처의 구조를 도식화하면 아래와 같습니다.

 

인프라를 구축하는 과정에서 인바운드 트래픽 포트를 잘못 열어서 503 화면만 몇 시간 동안 보기도 하고

도커에 올린 DB 관리를 위해 GUI 툴을 사용하려 했는데 연결이 계속 안 돼서 몇 시간 날리기도 하는 등 우여곡절이 정말 많았습니다.

 

인프라 영역은 오류가 어디서 나는지 찾기가 정말 어려워서

내 인프라 구조가 어떤 식으로 구축되어 있는지 정확히 이해하고 에러 가능성이 있는 부분들을 하나하나 찾아 해결을 시도하는 게 가장 좋은 것 같다고 느꼈습니다.

 

앱 배포를 위해 스토어 검수 과정도 쉽지만은 않았는데

플레이스토어는 신규 앱을 배포하려면 20명 이상의 테스터가 2주 이상 앱을 테스트해야만 프로덕션 환경에 올릴 수 있는 조건이 있었고

애플의 앱스토어는 심사 자체가 악명이 높았습니다.

 

결국 안드로이드는 20명 이상의 테스터를 모으다가 전부 관리하기가 너무 까다로워

결국 크몽에서 심사를 대행해 주는 업체를 사용하였고

iOS는 8번의 리젝을 경험하였는데

다른 건 모두 이해가 갔지만 계속해서 회원가입 시 전화번호와 생년월일 정보를 삭제하라는 것 때문에 리젝을 당했습니다.

이유는 동아리 관리 앱에서 해당 정보들이 필요 없다는 것이었는데

동아리 관리자들이 지원자들의 나이와 연락처를 알아야 했기에

이유를 설명하기 위해 문의도 계속 넣어보고 메모에 계속 이유를 남겨놨지만 보지 않는 것 같았습니다.

 

심사도 사람이 하는 것이다 보니 앱 각각의 특징을 고려하지 않고 심사 매뉴얼대로 리젝을 하는 것 같았고

따로 문의를 넣고 사유가 인정되어야지 해당 통과가 되었습니다.

 

---

운영되고 있는 지금 느낀 점

프로젝트 개발이 완료되고 현재는 순천향대학교에서 실제 운영이 되고 있는데

마케팅이 참 어렵고 유저를 모으는 게 정말 어렵다는 것을 느꼈습니다.

 

에브리타임에 홍보를 해도 효과가 저조하여 모집 공고를 통해 각 동아리 운영진에게 직접 연락을 하였습니다.

많은 분들이 긍정적으로 응답해 주셨지만 연락을 안 보는 경우도 많았고 퉁명스럽게 답해주신 분들도 있어 속상한 일도 있었습니다.

 

그리고 크게 느낀 것이 유저는 귀찮은 것을 극도로 싫어한다는 점입니다.

처음 기획했을 때 동아리 운영진들이 자발적으로 앱 내에서 동아리를 생성하고 관리하는 방향으로 기획했는데

최대한 간단한 프로세스로 개발했음에도 동아리 생성까지 도달하는 것이 너무 어려웠습니다.

 

그리고 학교 인증을 하는 것도 너무나 큰 진입장벽이 되어 유저 유입이 막히는 경우가 많았어서

초기 서비스 운영을 하려면 최대한 유저의 손이 안 타도록 만드는 게 중요하다는 것을 느꼈습니다