회의실 예약, 티켓팅처럼 공평하게.

Klüme(클룸)은 부트캠프 현장에서 반복적으로 발생했던
회의실 선착순 구두 예약의 불편함과 비효율성을 해결하기 위해 만든 조직 기반 회의실 예약 서비스입니다.

0xAM 팀원 소개

강지륜	김민지	김진호	배태용	정유진	허창훈

---

1. 프로젝트 소개

🔎 Klüme는 어떤 서비스인가?

Klüme은 다음과 같은 실제 문제 상황을 해결하기 위해 기획되었습니다.

❌ 기존 회의실 예약 문제

• 선착순 구두 예약 → 줄서기, 혼잡
• 매니저 출근 전까지 자리확보 대기
• 가위바위보로 자리 배분 → 운에 따른 불공정
• 예약 현황 확인이 어려움
• 공지가 디스코드 등 여러 곳으로 흩어져있음

✅ Klüme가 제공하는 해결책

• ⏱ 정확한 예약 오픈 시간 + 자동 활성화 버튼(티켓팅 방식)
• ⚡ 여러 명 클릭 시 서버 단에서 단 1명만 예약 성공 처리
• 📅 일/주/월 달력 기반 예약 현황 제공
• 🏢 조직/그룹 단위로 예약 환경 관리
• 💬 실시간 관리자–멤버 채팅
• ⚠️ 패널티 기반 질서 유지(노쇼 방지, 인증 사진 업로드)

기술 요약

🌆 DevOps

🌿 FrontEnd

🗝️ Backend

🗂️ DB

🔧 Tools

📡 Real-time Communication

---

2. 설계 문서

WBS

WBS

요구사항 명세서

요구사항 명세서

회원 정보

조직

회의실

예약

공지사항, FAQ

채팅

DDD

DDD

조직 공지사항

조직관리

회원

알림

회의실 예약

채팅

FAQ

예약 이후 회의실 이용

---

3. 와이어 프레임

🎨 Figma 바로가기

와이어 프레임

---

4. DB 모델링

🗂️ ERD 바로가기

ERD

---

5. 주요 기능 시연

👤   회원가입 및 로그인

  회원가입

  로컬 로그인

  구글 로그인

👤   조직 생성 및 가입

  조직 페이지

  조직 생성

  조직 코드로 가입

👤   조직

  공지사항 등록

  회의실 등록

  회의실 예약 등록

  회의실 예약

  회의실 이용

  예약 취소

  그룹 생성

👤   채팅

  유저 채팅방 생성 및 사진 전송

  관리자 채팅 담당 및 전송

  실시간 채팅

---

6. 테스트

  Member 테스트

  Room 테스트

---

7. 시스템 아키텍처

---

8. 배포

  jenkins 파이프라인

  docker hub 업데이트

---

9. 개인 회고

강지륜

📚 프로젝트에서 맡은 역할

• 프로젝트 기본 세팅
• 조직 관련 전반적인 기능 구현
  • 조직 및 그룹 생성 / 수정 / 삭제 기능 구현
  • 조직 초대 코드 발급 및 가입 기능 구현
  • 조직 멤버 수정 / 제거 등 관리 기능 구현
• 회의실 예약 기능 구현

🏆 잘한 점

• 프로젝트 초기 세팅을 담당하며 팀원들이 동일한 환경에서 작업할 수 있도록 기반을 마련했다.
• 서비스 클래스에서는 메소드 책임을 최소화해 추상화 수준을 통일하려고 노력했고 메소드 이름만 보고도 기능을 파악할 수 있도록 코드를 작성했다.
• 코드 리뷰를 통해 팀원들의 피드백을 반영하여 오류를 개선하고 코드 품질을 높일 수 있었고 다른 팀원들의 코드를 리뷰하면서 전반적인 코드에 대한 이해도도 높였다.

🤨 아쉬운 점

• 동시성 제어를 프로젝트 후반부에 도입하다보니 충분히 학습하지 못한 상태에서 적용하여 코드가 제대로 구현되었는지에 대한 확신이 부족했다.
• 백엔드 기능 구현에 집중하느라 프론트 개발에 충분한 시간을 투자하지 못했다.
• 기능 구현을 우선하다 보니 테스트 코드를 병행해 작성하지 못했다.

🎯 배운 점

• 코드 리뷰를 통해 내가 놓쳤던 부분들을 발견하고 개선하면서 코드 품질을 높이는 과정의 중요성을 배웠다.
• 동시성 제어과 같은 사전 지식이 필요한 기능인 경우 단순히 구현한 것보다 왜 그렇게 구현해야 하는지 동작 원리를 이해하는 과정이 중요하다는 점을 배웠다.

💡 다음 프로젝트에 적용하고 싶은 점

• 백엔드와 프론트엔드 개발을 각각 개발이 아닌 동시에 병행해서 진행하고 싶다.
• 기능 구현과 함께 테스트 코드를 병행하여 작성하고 싶다.
• 동시정 제어가 필요한 기능이 있을 경우, 충분히 학습한 후 구현해보고 싶다.

---

김민지

📚 프로젝트에서 맡은 역할

• 기능 명세화
• UI 디자인 설계
• 배포 환경 구성
  • Docker 이미지 생성
  • GitHub Webhook + Jenkins 자동 빌드 파이프라인 구축

🏆 잘한 점

• Docker, Jenkins, Webhook 환경을 직접 구축하며 DevOps 역량을 쌓을 수 있었다.

🤨 아쉬운 점

• DevOps 개념이 낯설어서 적응하는 데 시간이 오래 걸렸고, 그 때문에 ArgoCD까지 적용하지 못한 점이 아쉽다.
• DevOps 관련 문제 해결 경험이 많지 않아 트러블슈팅 속도가 느렸던 부분이 있었다.

🎯 배운 점

• CI/CD 흐름의 전체 구조(Docker → Jenkins → 배포)를 직접 구축하면서 DevOps 기본기를 명확히 이해하게 되었다.
• Webhook, 빌드 자동화, 이미지 버전 관리 등 실제 서비스 운영에서 필요한 요소들을 경험할 수 있었다.

💡 다음 프로젝트에 적용하고 싶은 점

• GitHub Actions 같은 더 고도화된 CD 자동화 도구를 도입해보고 싶다.

---

김진호

📚 프로젝트에서 맡은 역할

• 프로젝트 전반 기획 참여
• ERD 및 전체 모델링 설계
• 웹소켓 기반 채팅 기능 구조 및 전반 관리(STOMP, SockJS 포함)
• 프론트·백엔드 간 API 및 데이터 구조 조율
• 채팅 기능 UI/UX 개발 및 수정
• 형상관리(GitHub) 브랜치 전략·PR 규칙 관리 및 팀원 코드 리뷰 참여

🏆 잘한 점

이전에 경험해보지 않았던 웹소켓·STOMP·SockJS와 같은 실시간 통신 기술과 몽고DB 같은 NoSQL 기술들을 직접 학습하고, 왜 해당 기술들을 사용해야 하는지 구조적·기능적 관점에서 스스로 고민하고 문서화시켜 팀원들과도 공유하고 적용했다는 점이 큰 성취였다. 특히 메시지가 브로커를 통해 어떻게 라우팅되는지, 구독/발행 구조가 어떻게 동작하는지, 폴백이 필요한 이유가 무엇인지 등을 이해하며 실시간 기능을 안정적으로 구현했고, 이러한 학습 과정을 팀원들과도 공유하며 프로젝트 품질을 높일 수 있었다. 또, MVP를 먼저 구현한 뒤 채팅 플로팅 띄우기, 채팅 담당하기, ui/ux 개선등 점진적으로 기능을 확장하는 방식으로 개발해 리스크를 줄이고 빠른 검증을 할 수 있었던 점도 스스로 좋은 선택이었다고 느낀다. 또한 GitHub 브랜치 전략, 커밋 규칙, PR 리뷰 프로세스 등 팀이 합의한 형상관리 원칙과 코딩 컨벤션을 일관되게 지키며 협업 효율을 높이고, 팀 전체 코드가 동일한 스타일과 흐름을 유지하도록 신경 쓴 점도 좋았다.

🤨 아쉬운 점

설계 단계에서 최대한 자세하고 명확히 하려고 노력했지만 구현 단계에서 많이 바뀌고 재설계 단계를 거쳐서 시간이 다소 지연된것 같다. SSE 기반의 실시간 알림 기능을 완성하지 못한 점이 아쉽다. 웹소켓과 실시간 통신에 대한 깊은 이해보다는 시간에 쫓겨 구현에만 급급한 모습이 있었던 것 같다.

🎯 배운 점

• 형상관리 규칙과 코드리뷰를 팀 전체가 일관되게 지키는 것의 중요성을 체감했다.
• HTTP API와는 전혀 다른 방식으로 동작하는 웹소켓 기반 실시간 기능을 STOMP 프레임 구조, 메시지 라우팅, 세션·구독관리등을 직접 설계·구현하면서 이해하게 되었다.
• MongoDB를 사용하면서 문서 기반 저장의 장점, 쿼리 방식, 데이터 모델링의 관점을 새롭게 익힐 수 있었다.
• 새롭게 배우게 되는 기술에 대한 막연한 두려움이 없어지고 "하면 되겠지"라는 자신감을 얻을 수 있었다.

💡 다음 프로젝트에 적용하고 싶은 점

초기에 MVP를 빠르게 완성하고 그 위에 기능을 자연스럽게 확장해가는 방식을 더 체계적으로 적용하고 싶다. 실시간 통신 기능을 다시 구현한다면 웹소켓뿐 아니라 SSE 기반 알림 시스템, Redis Pub/Sub, 메시지 큐, 읽음 처리·오프라인 메시지 관리 등 실서비스에 더 가까운 구조를 적용하고 싶다. 또한 프론트와 백엔드가 더 빠른 템포로 협업할 수 있도록 API와 이벤트 문서화를 정착시키고, 초반 단계에서 end-to-end 흐름을 빠르게 검증하는 방향으로 진행하고 싶다.

---

배태용

📚 프로젝트에서 맡은 역할

• 회원가입(로컬, Google OAuth) 기능 개발

• Spring Security 기반 로그인 인증·인가 처리

• 공통 컴포넌트(header, sidebar, button, input) 제작

• Front-End 요구사항에 맞춘 Back-End DTO 추가 및 API 구조 정리

이번 프로젝트는 회원 도메인을 중심으로 전체 인증 흐름을 책임졌고, 클라이언트 개발과의 연결도 꽤 밀접하게 진행했다.

🏆 잘한 점

• Spring Security를 활용한 인증/인가 구축

이번 프로젝트에서 내가 가장 많은 시간을 투자한 부분이었다. Spring Security는 여전히 난이도가 높은 영역이라 처음 구조를 잡는 과정부터 시행착오가 많았다. 수업 때는 따라가기 바빴지만, 실제로 프로젝트에서 직접 구현하면서 구조를 이해할 수 있었고, 인증 흐름을 내 손으로 제대로 구성해볼 수 있었다는 점이 가장 큰 성취였다. 특히 Local 회원가입뿐 아니라 Google OAuth까지 확장하면서 단순히 API 연동이 아니라,

• Spring Security 필터 구조
• OAuth2 클라이언트 설정
• 사용자 정보 매핑
• 회원 테이블과 OAuth 사용자 정보 동기화

등 여러 포인트를 경험할 수 있어서 실제 서비스 구성에 한 발 더 다가간 느낌을 받았다. 처음엔 어려웠지만 결국 완성해서 팀 전체가 안정적으로 사용할 수 있었다는 점이 꽤 뿌듯했다. 😎

🤨 아쉬운 점

Google OAuth에 이어 카카오/네이버 같은 국내 OAuth를 적용하지 못한 점은 개인적으로 많이 아쉬웠다. OAuth 구조 자체는 비슷하지만, Provider별로 인증 방식이나 반환 데이터가 달라 실제로 붙여보는 경험을 해보고 싶었다. DevOps 프로젝트였지만, 실제 개발에서는 DevOps 역할을 많이 맡지 않아 CI/CD, 인프라 구성 등에 깊게 관여하지 못했다. 수업을 들은 것과 실전 프로젝트에서 직접 다뤄보는 것은 차이가 크기 때문에, DevOps 실전 경험을 쌓지 못한 점이 지금 돌아보면 아쉽다.

🎯 배운 점

• Redis 활용 능력 향상

이번에도 회원가입 인증 이메일 발송 후 인증 제한 시간을 관리하기 위해 Redis를 사용했다. 지난 프로젝트에서는 다른 팀원이 개발해 설치된 Redis를 그냥 사용하는 수준이었다면, 이번에는 직접 회원가입 기능을 맡으면서 TTL 설정, key/value 구조 설계, 인증 번호 관리 로직 등을 더 깊이 있게 이해하고 사용할 수 있었다.

💡 다음 프로젝트에 적용하고 싶은 점

단위 테스트 코드 작성 습관 개선 기능을 완성한 후 수동 테스트에만 의존하다 보니 리팩토링 시 불안함이 있었고, 이번 경험을 통해 테스트 코드의 필요성을 다시 체감했다. 다음 프로젝트에서는 인증/인가, 레포지토리, 서비스 레이어 중심으로 단위 테스트를 적극적으로 작성하고 싶다.

디자인 패턴 활용 능력 향상 이번에 인증 관련 로직을 구현하면서 중복 코드가 생기거나 확장성 있는 구조를 만들지 못한 부분이 조금 아쉬웠었다. 이 다음 최종 프로젝트 때엔 전략 패턴, 템플릿 메서드 패턴 등 상황별로 적용해볼 수 있는 패턴들을 더 적극적으로 고민해보고 싶다.

---

정유진

📚 프로젝트에서 맡은 역할

• 관리자의 예약 가능 시간 관련 기능 구현
  • 예약 가능 시간 생성 / 수정 / 삭제 기능 구현
  • 특정 일자의 예약 수정 / 삭제 기능 구현
• 관리자메뉴

🏆 잘한 점

예약 가능 시간 기능을 맡으면서 여러 테이블이 연동되고, 생성·삭제에 따른 제약 조건들이 많아 생각해야 할 부분이 매우 복잡했지만 이러한 상황 속에서 다양한 케이스를 고려하며 구현해내는게 쉽지 않았지만, 기능이 모두 맞물려 정확하게 동작하는 모습을 확인했을 때 큰 보람을 느꼈다.

🤨 아쉬운 점

프론트와 연결하는 과정에서, API 요청에 필요한 데이터를 충분히 고려하지 않은 채 백엔드를 먼저 구현한 탓에 마지막에 DTO를 급하게 수정해야 했던 부분이 아쉬웠고, 또한 프론트 개발에 충분한 시간을 투자하지 못해, 백엔드에서는 정상 동작하는 기능이 마지막에 프론트에서는 제대로 작동하지 않았던 것이 너무 아쉬웠다.

🎯 배운 점

• 두 번의 프로젝트를 거치며 MyBatis와 스프링 부트에 한층 더 익숙해졌고, 이전보다 더 깔끔하고 구조적인 코드를 작성할 수 있게 되었다.
• 예약 가능 시간 생성/수정/삭제, 특정 날짜 예약 수정/삭제 등은 테이블 간 연관관계도 많고 복잡한 조건들도 있었는데 이 기능을 구현하면서 요구사항을 논리적으로 쪼개고 순서를 정리하는 능력이 향상되었다.

💡 다음 프로젝트에 적용하고 싶은 점

• 백엔드와 프론트 중 한쪽에만 시간을 과도하게 쏟지 않고, 전체적인 균형을 맞추어 양쪽 모두에 충분한 시간을 배분하며 개발하고 싶다.
• 기능 구현 전에어떤 화면에서 어떤 데이터가 필요할지, 어떤 형태로 전달해야 프론트가 편할지를 미리 고려하고 진행하고 싶다.

---

허창훈

📚 프로젝트에서 맡은 역할

• 요구사항명세서 정리
• 회의실 CRUD 구현 및 화면 연동

🏆 잘한 점

요구사항 → API 계약으로 빠르게 전환하여 명세서에 API 규격을 초기에 고정하여, 프론트와의 핑퐁을 줄였다. 화면에서 사용자 흐름을 매끄럽게 하여 사용자의 UX 경험을 개선했다.

🤨 아쉬운 점

충분한 시간이 있음에도 불구하고 일정관리를 제대로 하지 못해 디테일을 살리지 못한 부분이 매우 컸다.

🎯 배운 점

• PM의 중요성을 깨닫게 되었다.
• UI/UX는 데이터 흐름의 거울로 응답 상태·에러 메시지·필드별 검증을 일관되게 내려주면 프론트는 자연스럽게 좋은 UX를 만들 수 있다는 것을 배웠다.

💡 다음 프로젝트에 적용하고 싶은 점

• 단위테스트 코드를 작성하는 습관을 들여 테스트하는 시간을 줄이고 싶다.
• 디자인패턴을 적극 활용하여 중복된 코드를 줄이고 기능확장을 생각하여 프로젝트의 퀄리티를 높이고 싶다.

---