[한이음 드림업(구.ICT멘토링] Ep.0 진짜 터지지 않는 수강신청 시스템, 가능할까?

1. 들어가며

졸업 전, 나만의 규모 있는 프로젝트를 완성해보고 싶다는 욕심이 늘 있었다. 가능하다면 공모전에도 도전해보고 싶다는 생각도 있었고, 마지막 학년인 지금이 아니면 도전하기 어렵겠다는 마음이 들었다. 그러던 중, 우연히 ‘한이음 드림업 프로젝트’를 알게 되었다.

출처: 한이음 드림업

 

사실 이 프로젝트는 예전부터 선배들에게 “꼭 한 번 해보라”는 추천을 많이 받았던 프로그램이었다. 마침 좋은 주제와 일정이 맞았고, 지금이 기회라는 생각이 들어 본격적으로 도전해보기로 결심했다.

 

한이음 드림업은 기업 전문가와 대학생이 함께 실무형 프로젝트를 수행하는 인력 양성 프로그램이다.

기존에는 주로 학교 동기들과 팀 프로젝트를 해왔지만, 이번에는 현업에서 일하고 있는 멘토님의 피드백과 실무 조언을 받을 수 있다는 점이 큰 매력으로 다가왔다.

 

무엇보다 7개월간 장기적으로 진행되는 프로젝트라는 점, 서버비 130만원 지원, 공모전 기회 제공, 그리고 전문 멘토의 정기적인 피드백이 더해져 “이번에는 정말 제대로 해보고 싶다”는 확신이 들었고, 그래서 도전하게 되었다.

---

2. 어떻게 팀원을 구성했는가?

열심히 홍보했었다..😭

함께 도전할 팀원을 구하기 위해,

우리 학부 모든 학번 톡방에 모집 글을 작성해가며 정말 열심히 홍보했다.

하지만 예상보다 참여율은 저조했다.

특히 제일 함께하고 싶었던 4학년 친구들은 대부분 졸업 프로젝트로 바빠서 참여를 꺼리는 경우가 많았다.

 

지금 돌아보면,

마음이 맞고 함께할 수 있는 팀원을 구하는 일이 사실상 제일 어려웠던 것 같다.

 

다행히도, 평소 교류하던 멋쟁이사자처럼 동아리 친구들에게 함께 해보자고 제안했더니,

흔쾌히 응해주었고,

그렇게 우여곡절 끝에 프론트엔드 2명, 백엔드 2명으로 구성된 팀이 결성되었다.

---

3. 왜 우리가 이 프로젝트를 하게 되었는가?

팀원들과 다양한 주제 중 고민하던 중,

“오픈소스 기반 수강신청 대기열 시스템 개발”이라는 프로젝트가 우리의 눈길을 끌었다.

 

대학생들은 한번씩? 경험하는 현상?

대학생이라면 누구나 수강신청을 해본 경험이 있고,

그때마다 자연스럽게 이런 생각이 들곤 했다.

“어떻게 이렇게 많은 사람의 요청을 동시에 처리할 수 있을까?”

 

마침 나 역시, 스타트업에서 인턴으로 근무하던 당시

QR 기반 대여 시스템을 구축하면서,

하나의 대여기에 여러 사용자가 동시에 요청을 보낼 때 이를 어떻게 비동기적으로 처리할 것인가를 고민하며 설계한 경험이 있었다.

 

그 당시에는 사용자 수가 많지 않아 트래픽 문제를 직접 겪진 않았지만,

“만약 진짜로 수천 명이 동시에 요청한다면, 그건 또 다른 문제 아닐까?” 라는 생각이 들었다.

이런 배경이 자연스럽게 이어지며,

우리는 이 프로젝트 주제가 단순한 기능 구현이 아닌,

진짜 실무에서 마주칠 수 있는 문제를 경험해볼 수 있는 좋은 기회라고 판단했다.

 

😭 하지만, 큰 문제가 있었다.

해당 프로젝트는 단순히 신청한다고 바로 참여할 수 있는 방식이 아니었다.

멘토가 여러 멘티 팀 중에서 직접 팀을 선발하는 구조였던 것이다.

쉽게 말해, 우리가 이 프로젝트를 하기 위해서는 ‘경쟁’을 해야 했다. 😥

 

신청서에는 프로젝트 수행 역량, 지원 동기, 추가 제안사항 등을 자세히 작성해야 했고,

이 내용을 바탕으로 멘토가 팀을 선택한다는 구조였다.

 

무엇보다 쟁쟁한 수도권 대학 팀들과 경쟁해야 한다는 점에서,

지방대생인 나로서는 심리적인 부담이 꽤 컸다.

 

그래서 나는 단순한 스펙보다도 실전 경험을 바탕으로 확실히 어필해야겠다는 생각이 들었고,

스타트업 인턴으로 근무하며 겪었던 실무 경험,

특히 대여 시스템을 직접 설계하고 트래픽 처리까지 고민했던 사례들을 중심으로,

우리 팀이 실질적인 역량을 가진 팀이라는 점을 최대한 강조했다.

 

다행히도,

이런 우리 팀의 경험과 실전 중심의 강점을 멘토님께서 긍정적으로 평가해주셨고,

최종 심의까지 무사히 통과하게 되었다.

 

그렇게 우리는,
7개월이라는 긴 여정을 정식으로 시작할 수 있는 기회를 얻게 되었다.

---

4. 어떻게 이 프로젝트를 수행할까?

이 프로젝트의 핵심은 단순히 “기능을 구현하는 것” 이 아니라,
“실제 트래픽 상황에서 얼마나 안정적으로 서비스가 운영될 수 있느냐” 이다.

 

우리는 단순히 정해진 기능을 만들고 끝나는 프로젝트가 아니라,

실제 수강신청 환경에서 발생할 수 있는 트래픽 문제를 어떻게 해결할지를 핵심 과제로 삼았다.

 

♟️ 목표 단위 애자일 전략

우리는 흔히 말하는 ‘기능 중심’ 개발이 아니라,

“실제 문제를 테스트하고 → 그에 맞는 기술을 도입하며 개선해 나가는 방식”

즉, Outcome-Oriented Agile(목표 기반 애자일) 전략을 채택했다.

참고 링크 : https://www.e-hcg.com/bbs/board.php?bo_table=gallery&wr_id=109

애자일 조직 문화의 실험실, 스포티파이(Spotify) > Insight | HCG

❌ 기능 중심 접근	✅ 목표 중심 접근
“대기열 시스템을 만들자”	“트래픽 병목을 막기 위한 대기열 구조를 설계하자”
“Redis를 적용하자”	“DB 부하를 줄이기 위해 캐시 전략을 실험하자”
“Kafka를 쓰자”	“동시 요청 분산을 위해 이벤트 기반 처리 구조를 검토하자”

 

✏️ 단계 세분화

각 단계는 단순 구현이 아닌, 실제 문제 -> 테스트 -> 개선 흐름으로 연결된다.

단계	에픽	목표	기술
1단계	기본 수강신청 기능 구현	수강신청 기능이 정상적으로 동작하는 MVP 구현	Spring MVC, MySQL
2단계	부하 테스트	성능 한계와 병목 구간 확인	JMeter, Locust, 테스트 로그 수집 및 분석
3단계	대기열 (Polling 기반)	트래픽을 분산시키기 위해 순차 진입 유도	ConcurrentQueue, REST API, Polling 방식
3.5단계	대기열 고도화 (WebSocket 기반)	실시간 대기열 알림 제공 및 서버 부하 감소	ConcurrentQueue, WebSocket, 실시간 이벤트 푸시
4단계	Redis 캐시 도입	여석 정보 실시간 조회 및 DB I/O 병목 해소	Redis (캐싱 및 여석 처리), Redis 락
5단계	Kafka 기반 분산 처리	초고트래픽 환경에서의 안정적인 트래픽 분산	Kafka (Producer-Consumer), Redis, DB 비동기 반영

 

💡 점진적 성능 개선

1️⃣ 먼저 만들어보고

2️⃣ 실제로 부하를 걸어보며 병목을 확인하고

3️⃣ 그때 필요한 기술만 도입해서 개선해나가는 방식이다.

 

처음부터 Kafka나 Redis 같은 고성능 기술을 사용하는 것이 아니라, “터뜨려 보고, 그때마다 고쳐 나가는 실험 중심 구조”이다.

 

💻 협업 방식

Slack

• 팀 내 실시간 커뮤니케이션 및 데일리 공유
• 장애/긴급 이슈 대응
• 회의 요약 및 결정사항 공유

Jira

• 에픽/스토리(Task) 단위 이슈 관리
• 업무 상태 트래킹 (To Do → In Progress → Done)
• 마일스톤, 작업 진척률 시각화

Confluence

• 기술 설계 문서화 (아키텍처, 성능 분석, 회고 등)
• 테스트 로그 및 병목 지점 분석 정리
• 스프린트 전략 및 피드백 관리

---

5. 결론

우리가 만드는 건 단순한 수강신청 기능이 아니다.

실제 서비스 환경에서도 안정성과 확장성을 갖춘, 실전형 시스템을 만드는 것이다.

 

처음부터 복잡한 기술 스택을 도입하기보다는,

직접 만들어보고 → 테스트로 문제를 발견하고 → 필요한 기술만 도입해 개선해 나가는

실험 기반 전략을 택했다.

 

각 단계마다 명확한 목표를 세우고,

회고와 테스트를 반복하며

정말 ‘터지지 않는 수강신청 시스템’을 만드는 여정을 시작한다.

 

⏭️ 다음 글에서는, 우리가 어떻게 프로젝트 초기 아키텍처를 구성하고, 1단계 MVP를 설계했는지 공유할 예정이다.