← 블로그

· 프로젝트

Court-Kok: 정글 0주차 미니 프로젝트

[3박 4일 프로젝트 회고] 🏀 '같이 농구 할 사람?'이라는 질문에서 시작된 Court-Kok 개발기

Prologue. 모든 것은 하나의 질문에서 시작되었다

"오늘 농구하고 싶은데...", "우리 말고 다른 사람들은 언제 농구하지?"

농구를 좋아하지만, 같이 할 사람을 모으는 건 늘 어려운 일이었습니다. 즉흥적으로 하고 싶을 땐 더더욱 그랬죠. 이 단순하지만 가장 본질적인 불편함에서 아이디어를 얻었습니다. 흩어져 있는 정글의 농구인들을 연결하고, 원하는 시간에 함께 운동할 팀원을 쉽게 찾을 수 있는 직관적인 플랫폼.

그렇게 정신없이 몰입했던 3박 4일의 여정 끝에, 실시간 농구 매칭 서비스 **Court-Kok(코트콕)**을 만들게 되었습니다.


📌 프로젝트 소개

구분내용
프로젝트명Court-Kok (코트콕)
개발 기간2025.09.01 ~ 2025.09.04
팀원권동민, 권동하, 유선목
사용 기술Flask, MongoDB, Docker, AWS, WebSocket

저희는 짧은 기간 동안 핵심 기능에 집중했습니다. 사용자가 실시간으로 예약 현황을 확인하고, JWT 기반으로 안전하게 로그인하며, WebSocket을 통해 모든 변동 사항을 즉시 알림 받을 수 있도록 만들었습니다.


💡 기술적인 고민과 해결 과정

TIL을 쓰듯, 프로젝트 과정에서 마주했던 문제와 해결하며 얻었던 깨달음을 정리해 봤습니다.

1. "만약 여러 명이 동시에 예약 버튼을 누르면 어떡하지?" - 동시성 문제와의 싸움

  • 어려웠던 점: 여러 사용자가 0.1초 차이로 마지막 한 자리를 동시에 예약하면 어떡하지? 라는 고민이 있었습니다. 이러다 데이터가 꼬이면서 누군가는 예약에 실패했는데도 성공한 것처럼 보일 수 있겠다고 생각했죠. 말 그대로 Race Condition, 누구 먼저랄 것 없이 달려드는 상황이었습니다.
  • 해결 및 배운 점: 팀원들과 이야기하다 MongoDB의 find_one_and_update라는 기능을 알게 됐습니다. 여러 요청이 동시에 들어와도 데이터베이스가 알아서 순서를 보장하며 하나씩 처리해주는 덕분에 데이터의 정합성을 지킬 수 있었습니다. 이 경험을 통해 동시성 문제가 단순히 이론으로만 아는 것과, 직접 마주하고 해결하는 것의 깊이가 얼마나 다른지 다시 한번 느꼈습니다.

2. "새로고침은 이제 그만!" - 실시간 동기화의 필요성

  • 어려웠던 점: 누군가 예약을 취소했는데, 다른 사람이 새로고침하기 전까지는 그 자리를 볼 수 없다면 사용자 입장에서 정말 불편할 것 같았습니다. 이건 꼭 해결하고 싶었죠.
  • 해결 및 배운 점: WebSocket을 도입해 서버와 클라이언트 간의 통로를 열어두었습니다. 덕분에 데이터가 변경될 때마다 서버가 즉시 모든 사용자에게 "자리가 났어!"라고 알려줄 수 있게 됐죠. 사용자가 아무것도 하지 않아도 최신 정보를 볼 수 있게 되면서, 서비스의 완성도가 한 단계 올라간 느낌이었습니다.

3. "세션이 WebSocket이랑 안 맞는구나" - 인증 시스템의 전환

  • 어려웠던 점: 처음에는 익숙한 Session 기반으로 인증을 구현했습니다. 그런데 실시간 통신을 위해 WebSocket을 도입하고 나니 문제가 생겼습니다. 웹소켓은 일반적인 HTTP 요청과 달라서, 세션 정보를 담은 쿠키가 제대로 전달되지 않는 경우가 많았습니다. 한마디로, 서버가 사용자를 알아보지 못하는 상황이 벌어진 거죠.
  • 해결 및 배운 점: 팀원들과 이 문제를 이야기하다가, 웹소켓 통신에는 매번 인증 정보를 담아 보내는 방식이 더 적합하다는 걸 알게 됐습니다. 그래서 JWT로 전환하게 되었습니다. 사용자 스스로가 "나 인증된 사람이야"라는 토큰을 들고 다니는 방식이라, 웹소켓 연결이 새로 맺어질 때마다 이 토큰만 확인하면 됐습니다. 이걸로 확장성을 확보한 것은 물론, 기술을 선택할 때는 각 기술 스택 간의 궁합을 반드시 고려해야 한다는 점을 몸소 체험할 수 있었습니다.

🤔 "기능은 되는데, 마음이 끌릴까?" - UI/UX에 대한 고민

프로젝트 막바지에 팀원들과 다 같이 모여서 이야기를 나누었습니다. "기능은 다 돌아가는데, 과연 이게 최선일까? 사용자가 쓰기 편한가?"

단순히 '작동하는' 서비스를 넘어, 사용자가 '편리하고 즐겁게' 머물다 갈 수 있는 서비스를 만들고 싶다는 욕심이 생겼습니다. 그래서 사용자의 입장에서 처음부터 서비스를 이용해보며 두 가지 큰 개선을 이뤄냈습니다.

1. 사용자를 위한 작은 안내서, 'Indicator'

처음 방문한 사용자는 텅 빈 시간표 앞에서 뭘 해야 할지 막막할 수 있겠다고 생각했습니다. 그래서 "모임을 만들거나 참여해 보세요!" 라는 안내 문구를 추가했습니다. 이 작은 변화만으로도 사용자가 "아, 저 시간표를 누르면 되는구나"라고 직관적으로 인지할 수 있게 됐습니다.

2. 농구의 재미를 더하는 '미니게임'

캘린더와 시간표만 있는 페이지는 조금 허전한 느낌이었습니다. '농구'라는 저희 서비스의 정체성을 더 살리고 싶었죠. 그래서 과감히 레이아웃을 수정하고, 비어있는 공간에 농구를 주제로 한 간단한 미니게임을 넣었습니다. 이 미니게임은 단순한 재미를 넘어, 사용자가 서비스에 머물며 농구라는 도메인에 더 몰입하게 만드는 역할을 했습니다.

이 과정은 사용자 중심적 사고의 중요성을 다시 한번 깨닫게 된, 정말 기억에 남는 경험이었습니다.


3박 4일을 돌아보며

정신없이 몰입했던 3박 4일이었습니다. 이번 프로젝트에서 가장 크게 배운 건, 역시 '함께'의 가치였습니다. '같이 일하고 싶은 사람'이 되는 것이 얼마나 중요한지, 동료들과의 건강한 소통과 피드백이 프로젝트를 얼마나 단단하게 만드는지 배울 수 있었습니다.

특히 저희가 기능 구현을 넘어 UI/UX까지 깊게 고민했던 과정을 코치님께서 알아봐 주셨을 때, 정말 큰 보람과 감사를 느꼈습니다. 단순히 '만드는 것'에 그치지 않고, '사용자'를 생각하는 저희의 노력이 인정받은 것 같아 무척 기뻤습니다.

짧은 시간이었지만 치열하게 고민하고, 막힐 때마다 서로에게 든든한 버팀목이 되어준 동민님, 선목님에게 정말 고맙다는 말을 전하고 싶습니다.