2024년 11월부터 2025년 1월까지 사이드 프로젝트로 우정 테스트 퀴즈, 찐친고사를 제작하고 배포했습니다.
사이드 프로젝트를 배포하며 느낀 점을 간단히 회고해 보려 합니다.
저는 사이드 프로젝트에서 팀장(기획), 디자인, 프론트엔드, 인프라를 맡아 진행했습니다.
https://github.com/nunsongCookie
Real-Friend-Challenge
ACC SMWU 2nd Member's Project. Real-Friend-Challenge has 4 repositories available. Follow their code on GitHub.
github.com
ACC란?
ACC는 AWS Cloud Clubs의 약자로, AWS의 공식적인 대학생 커뮤니티입니다.
AWS Student Community Day와 같은 세션부터 다른 커뮤니티에서는 겪어보기 힘든 인프라 해커톤까지 함께 하며 큰 발전을 할 수 있었습니다.
이번에 사이드 프로젝트를 함께 할 멤버들도 ACC 숙명여대 지부에서 모집했습니다.
2024년 ACC에서 한 활동들이 궁금하다면 아래 링크를 참고하면 좋을 것 같습니다.
https://www.awscloudclubs.kr/posts/recap-2024/
ACC Korea 2024년 돌아보기 - ACC Korea
ACC Korea는 2024년에 어떤 활동들을 해 왔을까요? 한 해 동안의 여정을 되돌아 보아요.
www.awscloudclubs.kr
기획
사실 초기 기획은 우정 테스트 퀴즈가 아니었습니다.
인프라 해커톤의 주제 중 하나인 채팅 시스템을 살려 일정 반경 내에 있는, 유사한 관심사를 가진 사람끼리 대화가 매칭되는 어플을 만들어 보려고 했었습니다.
하지만 기능 구현 난이도와 관심사의 범위가 넓다는 문제가 발생해 주제를 변경하게 되었습니다.
어떻게 보면 처음에 멤버분들은 취업 사기를 당하신거죠...
해당 아이디어를 논의하던 시점이 10월이었기 때문에, 기말고사를 고려하여 키워드를 새해로 바꾸게 되었습니다.
여러 가지 아이디어가 나왔었습니다.
새해 첫 곡을 새해 다짐과 함께 공유하기, 1년 후의 나에게 편지 쓰기, 사람들이 고른 새해 첫 곡 순위 등...
논의한 아이디어 중 메인 아이디어(프로젝트의 중요 기능)과 서브 아이디어(추가하면 좋을 기능)으로 분류한 뒤, 메인 아이디어 중 투표를 통해 연초-연말 느낌의 우정 테스트 퀴즈로 결정하게 되었습니다.
버려진 아이디어 중 마음에 드는 것도 많아서 내년에 사용할 수 있으면 좋겠네요.
또한 학기 중에는 진행 상황이 루즈해지지 않게 캡틴님께 양해를 구해서 프로젝트 진행 경과에 대해 간단히 발표를 진행했습니다.
https://www.canva.com/design/DAGVgmS2KWk/-ZAwc-dpQ5AGxJRUmlBxVg/edit
이런 식으로 발표를 진행하며 다른 멤버들에게 피드백도 받으며 프로젝트의 완성도를 올릴 수 있었던 것 같습니다.
디자인
저는 미감이라고는 하나도 없는 사람인데, 어떻게 하다가 디자인도 맡게 되었습니다.
일단 키워드가 우정 테스트 퀴즈이고, 제게 고등학생 호적 메이트가 있는 관계로 모의고사 느낌으로 디자인을 해보면 좋지 않을까 생각이 들었습니다.
메인 페이지를 모의고사 느낌으로 제작하고, 채점 결과도 모의고사 가채점 표를 참고하여 디자인을 했습니다.
공유 화면의 경우에는 다른 팀원분께서 귀여운 애니메이션을 제작해 주셔서, 해당 부분을 살리고자 노력했습니다.
Figma
Created with Figma
www.figma.com
디자인이 완성되어야 프론트와 백엔드 작업을 시작할 수 있어 매우 열심히 진행했던 기억이 납니다.
프론트엔드
저희 팀의 구성은 백엔드 2명, 인프라 3명이었습니다.
하지만 프론트엔드 없이 프로젝트 배포 및 실 사용자 유입이 어려울 것 같아 Flutter를 사용해서 간단한 프로젝트를 진행해 본 경험이 있는 제가 프론트엔드를 담당하기로 했습니다.
Flutter도 2주 만에 공부해서 앱을 만들어 이유 모를 자신감이 있던 저는 이번에는 React를 사용해 모바일 웹을 만들어 보기로 (혼자) 다짐했습니다.
그렇게 디렉토리 구조도 어떻게 작성해야 할 지 모르고 API 연결도 해본 적 없는 제가 프론트엔드를 맡았습니다.
비슷한 화면이 많고, 디자인이 단순해 금방 구현할 수 있을 줄 알았는데 생각보다 많은 작업이 필요했습니다.
그리고 API 테스트를 하는 방법을 몰라서 프론트엔드는 VSCode, 백엔드는 IntelliJ에서 실행시키고 MySQL에 테이블을 만드는 방식으로 API를 테스트했습니다.
지금 생각해보면 이 무슨 풀스택이야... 싶네요.
역시 이론 공부도 중요하지만 실전에 닥쳐보는 것이 매우 중요한 것 같습니다.
그리고 오히려 프론트엔드 팀원이 없어서 제 맘대로 코드를 이리저리 수정하고, 에러가 발생하면 혼자 해결하는 과정에서 매우 많이 발전할 수 있었습니다.
그치만 막판에 에러 수정이 전부 프론트에 몰려 있어서 혼자서 모든 에러를 쳐내는 건 좀 힘들었습니다.
특히 iOS... 카카오톡 내장 브라우저... 정말 이슈가 많았습니다.
인프라
프론트엔드를 하느라 정신이 없었지만, 나름 인프라에서도 할 일은 전부 했습니다.
인프라는 기본적인 3-tier 아키텍처를 구현하고, Github Action을 이용한 Blue/Green 자동 배포를 목적으로 진행했습니다.
비용 상의 문제로 프로메테우스는 사용하지 못했지만, Cloudwatch와 CloudTrail을 이용해 콘솔에서 리소스 추적을 진행하고, 디스코드 봇을 이용해서 CPU 사용률에 따라 경보가 오도록 설정했습니다.
서비스 배포
서비스 배포 후 실 사용자 유입을 위한 홍보를 진행했습니다.
ACC 슬랙, 에브리타임, 인스타 등에 홍보를 진행해 약 400명의 사용자를 기록했습니다.
서비스 배포를 하면서 여러 가지를 느꼈습니다.
먼저, 홍보를 하는 것이 매우 어렵다는 것을 알았습니다.
에브리타임에서 글을 올리고, 친구들의 도움을 받아 베스트 게시물에 올랐음에도 생각보다 실 사용자 수가 더디게 늘었습니다.
이 프로젝트를 한 이후로 트위터나 인스타에서 사이드 프로젝트를 배포하면 공유 횟수를 보는 습관이 생겼는데, 좋은 아이디어임에도 불구하고 의외로 공유 횟수는 적었습니다.
프로젝트가 성공하기 위해서는 미리 어떻게 홍보를 할 것인지 타겟층을 제대로 세우고 홍보 수단을 마련하는 것이 중요하다는 것을 느꼈습니다.
그래서 개발자 SNS를 하기 시작했습니다.
다음에는 링크드인, 트위터에서도 홍보를 해 더 많은 사용자가 생기면 좋겠습니다.
또한 앱을 사용하면서 사용자 편의성에 대해서도 생각해 보았습니다.
저희 프로젝트에서는 퀴즈 생성자가 10개의 질문에 대해 각각 3개의 응답을 작성해야 합니다.
따라서 퀴즈를 생성하기 위해서는 총 30개의 문답을 작성해야 하는데, 이것이 생각보다 번거로웠습니다.
프로젝트의 기능과 사용자의 편의성 사이에서 균형을 맞춰야 좋은 프로젝트가 될 수 있는 것 같습니다.
마지막으로, 구현보다 배포 후 에러가 많이 발생합니다.
다음에는 빠른 피드백과 에러 처리를 위해 MVP 기능을 선별하고, 프론트가 조금 허접하더라도 먼저 주변 지인들에게 공유해 피드백 및 오류를 수정하고 완성을 하고 싶습니다.
저희는 일단 급하게 구글 폼을 통해 에러를 수집했지만 사실 사용자들은 에러가 발생한 시점에서 그냥 나가고, 번거롭게 구글 폼까지 작성해주지 않습니다.
이래서 꼼꼼한 테스트가 중요하구나~ 하고 몸소 깨달았습니다.
회고
정말 힘들었습니다.
프론트엔드 혼자 만들고 거의 매일 새벽 3시까지 에러 처리를 했습니다.
진짜 매일 커피 마셔서 위염이 올 뻔 해서 커피랑 차를 번갈아 마시면서 작업했습니다.
하지만 태그하면 빠르게 확인해주고 새벽까지 함께 고생해준 팀원들 덕분에 버틸 수 있었습니다.무엇보다 이번 프로젝트가 실제 사용자를 처음으로 받아본 프로젝트라서 정말 기뻤습니다.ACC에서 50달러 크레딧을 서버 비용으로 지원해줘서 중간에 이슈(...)로 환율이 올랐어도 무사히 서버를 올리고 계속 테스트를 해볼 수 있었습니다.여기까지 좋은 점이었습니다.
하지만 역시 지나고 보니 아쉬운 점이 많이 남습니다.저희의 가장 큰 문제점은 DEV 서버가 없었던 것입니다.DEV 서버 만들 돈이 없어서 그냥 Prod 서버에다 냅다 수정 배포를 진행했는데요, 배포를 할 때마다 애간장이 타들어가는 느낌을 받았습니다.이번 경험으로 확실히 깨달았습니다. 돈이 없어도 Dev 서버는 만들자.
그리고 저희가 원래는 인프라를 Terraform으로 진행하고 싶었습니다.
여러명이서 계속 콘솔 작업하고 노션에 문서 업데이트를 하는 것보다 코드로 작성하고 깃허브에서 공유해서 계속 머지하는 편이 인프라 작업 인원이 다수일 때 깔끔하지 않을까 싶어서 초반에는 Terraform을 사용했는데, 일정 상의 문제와 계속되는 에러로 인해 콘솔로 작업하게 되었습니다.다음에는 꼭 Terraform을 사용해보고 싶습니다.
로깅 부분도 더 다각화해서 모니터링 대시보드를 구축해보고, 프로메테우스를 사용해보면 좋을 것 같습니다.프로메테우스로 로그를 넘기려면 EC2를 추가로 사용해야 하는데, 여기서 또 비용을 추가하기에는 이미 허리띠를 졸라맨 상황이라서 여의치 않았습니다.다음에는 꼭 부하 테스트까지 진행해서 부하 시 로그가 어떻게 튀는지, 오토 스케일링이나 로드 밸런싱이 잘 이루어지는지 확인해보고 싶습니다.