- 서비스 LINK : https://www.comket.co.kr
- 팀명 : YOYAKSO
- 프로젝트 명 : COMKET
- 2025-1 아주대학교 SW 캡스톤 디자인 프로젝트
현재 협업 환경에서는 다양한 협업 도구가 병렬적으로 사용되고 있습니다. 이 과정에서 정보가 분산되고 맥락이 단절되는 문제가 발생하고 있습니다. 회의, 업무 정의, 자료 정리 등이 각기 다른 플랫폼에서 이루어지다 보니 이슈 누락이나 반복 입력, 담당자 변경 시 배경 파악이 어려워지는 등의 비효율이 생기기 마련입니다. 저희는 이러한 문제를 해결하기 위하여 협업의 모든 흐름을 하나로 이어주는 서비스인 COMKET을 기획하게 되었습니다.
💡 분산된 협업툴 사용으로 인한 흐름 단절
- 프로젝트 관리와 커뮤니케이션을 하나의 통합된 환경에서 제공하여, 논의와 실행 간 단절 없이 협업 흐름이 자연스럽게 이어집니다.
- 수동 복사/전달 없이, 논의 중 생성된 실행 항목을 바로 티켓화하여 맥락 유실을 방지합니다.
💡 맥락 손실로 인한 온보딩·핸드오버 비효율
- AI 기반 스레드 요약 기능을 통해 주요 논의와 결정 사항을 자동 정리하고, 역할별로 핵심 내용을 전달하여 신규 팀원도 빠르게 상황을 파악할 수 있습니다.
- 모든 논의와 실행 히스토리가 기록되어, 재논의 없이 배경을 즉시 확인할 수 있습니다.
💡 책임 소재 및 우선순위의 불투명성
- 대화와 업무 티켓이 분리되지 않고 하나의 티켓 내에서 함께 관리되어, ‘누가 언제 어떤 결정을 내렸는지’에 대한 추적이 용이합니다.
- 논의 내용 분석을 기반으로 후속 작업을 자동 제안하고, 우선순위와 상태를 명확히 표시해 빠른 의사결정을 지원합니다.
프로젝트 관리와 커뮤니케이션이 연결된 협업 플랫폼
- 워크스페이스 > 프로젝트 > 티켓 > 스레드로 이어지는 구조로, 논의에서 실행까지 자연스럽게 연결됩니다.
- 직관적인 계층 관리를 통해 협업의 흐름을 명확하게 유지할 수 있습니다.
- 티켓의 상태, 우선순위, 담당자, 마감기한, 하위 티켓을 한눈에 확인할 수 있습니다.
- 리스트 뷰: 전체 티켓 목록과 상세정보 중심
- 칸반 보드 뷰: 단계별 업무 진행 상황 관리에 최적화
- 미리 정의된 양식을 통해 다양한 유형의 티켓을 빠르고 일관성 있게 생성할 수 있습니다.
- 반복되는 업무 생성 시 효율적으로 활용이 가능합니다.
- 하나의 티켓 안에서 세분화된 작업 단위를 생성할 수 있습니다.
- 상위-하위 티켓 간 연결로 구조적 명확성과 흐름의 연속성 확보가 가능합니다.
- 긴 스레드 논의 내용을 AI가 핵심 위주로 요약하는 기능입니다.
- 눈높이 요약 기능을 통해 PM, 개발자, 디자이너 등 다양한 직군 별 눈높이 요약이 가능합니다.
- “누가, 무엇을, 언제까지” 해야 하는지를 AI가 자동 추출해줍니다.
- 회의록 없이도 곧바로 실행 가능한 업무로 연결할 수 있습니다.
| 워크스페이스 생성 및 참가 |
|---|
  |
| 프로젝트 생성 및 조회 |
|---|
  |
| 티켓 목록 조회 |
|---|
 |
  |
| 티켓 생성 |
|---|
  |
| 티켓 상세 조회 |
|---|
  |
| Backend | Backend | Frontend | Frontend |
|---|---|---|---|
 |
 |
 |
 |
| 이태경 (팀장) | 조민현 | 원해연 | 오유민 |
| Tech | Description |
|---|---|
| React | React는 웹 애플리케이션 개발에서 가장 널리 사용되는 프레임워크 중 하나로, 가상 DOM을 활용해 빠른 렌더링 성능을 제공하며, 컴포넌트 기반 구조를 통해 재사용성과 유지보수성이 뛰어나다. SEO가 주요 고려사항이 아닌 내부 페이지 중심의 COMKETt에서는 SPA 기반의 빠른 화면 전환이 큰 장점으로 작용하며, 복잡하지 않은 라우팅 구성과 생산성 높은 개발이 가능해 React를 채택하였다. Next.js와 같은 SSR 프레임워크도 고려했지만, 팀 내 대부분이 SPA 기반 개발 경험만 있었기 때문에 러닝커브와 설정 복잡성을 줄이는 방향으로 결정하였다. |
| TypeScript | TypeScript는 변수, 함수, 객체 등에 타입을 명시함으로써 컴파일 단계에서 오류를 사전에 확인할 수 있으며, 개발자 간 협업 과정에서 의도된 데이터 구조와 계약을 명확히 할 수 있는 장점이 있다 . 프론트와 백엔드 간 API 계약이 많고, 팀원이 동시에 여러 기능을 작업하는 구조에서 런타임 오류를 사전에 방지하고, 타입 추론을 통해 생산성과 안정성을 높이기 위해 도입하였다. |
| Styled-components | COMKET은 다양한 인터랙션과 컴포넌트 단위 스타일이 요구되는 협업 툴로, 스타일의 일관성과 유지보수성이 중요했다. 초기에 Tailwind CSS도 검토했으나, 팀원 다수가 Tailwind의 유틸리티 클래스 구조가 직관적이지 않다고 느꼈고, 특히 테마 기반 커스터마이징이 어려운 점에서 한계를 느꼈다. 반면 styled-components는 기존 CSS 문법을 그대로 활용할 수 있고, props를 활용한 동적 스타일링, 전역 테마 적용이 훨씬 명확하게 동작해 선택하게 되었다. |
| Axios | Axios는 요청 인터셉터와 응답 가공, 에러 처리 등 고급 기능을 기본 제공하며, API 호출 구조를 간결하게 작성할 수 있어 유지보수가 쉽다. 특히 acce ss token, refresh token 기반 인증 처리와 같이 보안이 요구되는 통신에도 안정적으로 대응 가능하며, 프론트엔드에서 백엔드 API와의 상호작용이 빈번한 ComKet에 적합한 HTTP 클라이언트로 판단되어 선택하였다. |
| Tanstack-Query | COMKET은 실시간 티켓, 댓글, 프로젝트 상태 등의 정보가 자주 변경되고, 최신 상태를 유지해야 하는 특성상 서버 상태 관리가 매우 중요하다. React Quer y는 별도의 상태 관리 없이도 API 호출, 캐싱, refetch, 로딩/에러 상태 관리를 선언적으로 처리할 수 있어 코드 복잡도를 줄이고 사용자 경험을 향상시킨다. 또한, 네트워크 요청을 줄이고 데이터 일관성을 유지할 수 있는 장점이 있어 도입하였다. |
| Zustand | Redux도 고려했지만, 설정이 복잡하고 보일러플레이트가 많아 팀의 개발 속도와 맞지 않았다. 반면 Zustand는 가볍고 직관적이며, 리렌더링 제어도 쉬워 대시보드 같은 화면에 유리하다다. 초기 설정이 거의 없고, 필요할 때만 가져다 쓰는 방식이어서 빠르게 적용할 수 있을 것 같다. 특히 리렌더링 제어가 용이하여 성능 최적화가 중요한 대시보드 화면에서 유용하다. 상태를 컴포넌트 외부에서 선언하고 직접 가져와 사용할 수 있어 직관적인 상태 관리를 할 수 있으며, 다양한 컴포넌트 간 데이터 공유가 필요한 ComKet에 적합하다 판단되어 채택하였다. |
| Tech | Description |
|---|---|
| Java 21 | COMKET의 백엔드는 Java 21을 기반으로 구현되며, 전체 서버 사이드 애플리케이션의 로직을 담당한다. Java는 타입 안정성과 객체지향 구조를 바탕으로 복잡한 비즈니스 로직을 명확히 구조화할 수 있으며, 최신 LTS 버전인 Java 21은 성능과 안정성이 검증되어 장기적인 운영 환경에 적합하다. 비교 대상으로 Node.js도 검토되었으나, 자유도가 높은 만큼 팀 내 개발 스타일 차이가 발생할 수 있고 구조화된 코드 관리를 어렵게 만들 수 있다고 판단하였다. 이에 따라 일관된 코드 품질과 유지보수를 고려해 Java를 선택하게 되었다. |
| Spring Boot | Spring Boot는 COMKET의 백엔드 서버를 구성하는 프레임워크로, API 라우팅, 서비스 계층, 데이터 처리 등 전반적인 서버 로직의 기반을 제공한다. 내장 서버 실행, 자동 설정, 통합 테스트 환경 지원 등 초기 개발 속도를 높이는 기능들이 내장되어 있으며, DI 기반 계층 설계를 통해 기능 분리가 용이하다. Express.js와 같은 경량 프레임워크도 고려되었으나, 복잡도가 높은 서비스 구조에서는 명확한 설계 기반을 갖춘 Spring Boot가 더 적합하다고 판단하여 채택하였다. |
| Spring Security + JWT | 사용자 인증 및 인가 처리는 Spring Security와 J WT 조합으로 구성된다. Spring Security는 세밀한 권한 제어와 인증 정책 설계가 가능하며, JWT 기반 인증 방식을 통해 서버 사이드 세션 없이도 사용자 인증을 유지할 수 있다. |
| Spring Data JPA | 데이터베이스 접근은 Spring Data JPA를 통해 ORM 방식으로 처리된다. 도메인 모델과 테이블 구조를 일치시켜 객체 중심으로 데이터를 다룰 수 있으며, 쿼리 자동 생성과 트랜잭션 처리 등에서 생산성과 안정성을 높일 수 있다. MyBatis도 검토 대상이었으나, 반복되는 SQL 작성의 부담과 테스트 효율성을 고려해 JPA의 높은 추상화 수준과 유지보수 편의성을 선택 기준으로 삼았다. |
| JUnit 5 | 백엔드의 핵심 로직은 JUnit5를 통해 유닛 테스트 및 자동화 테스트로 검증된다. Spring과의 호환성이 우수하며, 다양한 assertion, mo cking, 조건부 실행 기능을 제공하여 TDD 기반의 테스트 작성에 용이하다. TestNG 등 다른 대안도 존재하나, JUnit은 공식 Sprin g 문서와 연동 사례가 풍부하고 백엔드 개발 인원들도 JUnit을 활용해본 경험이 있어 선택하게 되었다. |
| Tech | Description |
|---|---|
| Git | 분산 버전 관리 시스템으로 협업 시 코드 변경 이력을 명확하게 추적할 수 있고, 브랜치 전략을 통해 기능 단위의 독립적 개발이 용이하다. |
| GitHub | 코드 리뷰, 이슈 관리, PR 기반 협업이 가능한 생태계가 잘 갖춰져 있으며, GitHub Actions 등 CI/CD 도구와의 연동이 자연스럽다. 대표적인 원격 저장소 및 코드 협업 플랫폼으로서 자연스럽게 선택되었다. |
| GitHub Actions | 빌드, 테스트, 배포 과정을 커스텀 워크플로우로 자동화하여 CI/CD 파이프라인을 구성 및 자동화 해주는 툴이다. 초기 설정이 간편하고, GitHub과 직접 통합되어 사용할 수 있다는 점에서 높은 연동성과 편의성을 제공하여 선택하였다. |
| Docker | 개발/운영 환경의 불일치를 방지하고, 컨테이너 단위의 배포로 어플리케이션 이식성과 확장성을 확보할 수 있다. 경량화된 실행 환경으로 MVP 서비스 구성에 적합하다. |
| Prometheus | Metric 기반 모니터링 시스템으로 실시간 데이터 수집 및 저장이 가능하다. 자원 사용량과 이상 패턴 탐지를 위한 기초 인프라로 도입하였다. |
| Grafana | Prometheus와 연동하여 모니터링 지표를 시각화하며, 운영중 주요 지표(RPS, 에러율 등)의 빠른 파악과 대시보드 기반 상태 확인이 가능하다. |
| Tech | Description |
|---|---|
| Google OAuth API | COMKET의 소셜 로그인 기능은 Google OAuth API 를 기반으로 구성된다. 보안이 검증된 인증 인프라를 활용할 수 있으며, 자체 로그인 로직을 직접 구현하지 않아도 되어 개발 효율성이 높다. Google은 글로벌하게 가장 널리 사용되는 계정 플랫폼 중 하나로, 이를 통해 로그인 진입 장벽을 낮추고 사용자 커버리지를 극대화할 수 있다는 장점이 있다. ComKet은 로그인 과정에서 보안성과 접근성을 모두 고려해야 했기 때문에, 가장 넓은 사용자 기반을 지원하는 Google OAuth가 안정적인 선택지로 판단되었다. |
| Firebase Clou d Messaging (FCM) | 사용자에게 실시간 알림을 제공하기 위해 Firebase C loud Messaging을 도입하였다. FCM은 모바일 및 웹 환경 모두에서 통합된 푸시 알림 시스템을 제공하며, 초기 구축 비용 없이 빠르게 적용 가능하다. 자체 푸시 시스템 구축도 고려했으나, 초기 서비스 단계에서는 운영 부담을 줄이고 실시간성 확보가 용이한 FCM이 가장 현실적인 대안이었다. |
| OpenAI Chat GPT API | COMKET의 AI 기반 요약 기능은 OpenAI GPT API를 통해 구현된다. 티켓 내 스레드 메시지를 요약하거나 실행 항목으로 자동 전환하는 데 활용되며, 별도 모델 학습 없이도 높은 자연어 처리 품질을 제공한다. 여러 차례 테스트를 하였으나 모델 별 큰 차이가 없는 것으로 확인하여, 가장 대표적인 생성형 AI 모델인 OpenAI ChatGPT API를 활용하기로 하였다. |
feat: 새로운 기능 개발
fix: 일반적인 버그 수정(핫픽스X)
hotfix: 운영에 긴급한 문제 발생
ref: 기존 코드 리팩토링, 성능 개선
test: 성능 테스트, A/B 테스트, QA 용도
docs: README, API 문서 등
| 파트 | 규칙 |
|---|---|
| Front-end | 기능 개발 시, 브랜치는 feat/iteration 내 task 번호/기능명 형식으로 생성한다. 작업 완료 후 코드 리뷰를 거쳐 develop 브랜치로 병합한다. 이후 별다른 문제가 없다면 develop 브랜치에서 main 브랜치로 PR을 올려 병합하고, 이를 통해 배포가 진행된다. |
| Back-end | 기능 개발 시, feat/{기능} branch를 생성하여 작업을 진행한다. 기능 개발이 완료된 후 dev branch에 병합하여 PR 및 테스트를 진행한다. 테스트가 완료되고 배포가 가능한 상태라면 main branch에 병합하여 배포한다. |
| 파트 | 규칙 |
|---|---|
| Front-end | Pn Rule을 통해 코멘트의 중요도를 명확하게 표현한다. •P1: 반드시 반영해야 합니다. (Request changes) • P2: 적극적으로 반영해 주세요. (Request changes) • P3: 가능하면 반영해 주세요. (Comment) • P4: 반영해도 좋고, 넘어가도 무방합니다. (Approve) • P5: 단순한 개인 의견입니다. (Approve) |
| Back-end | PR 작성 시 다음 사항을 반드시 포함해야 합니다:• PR 유형: 기능 추가 / 수정 / 리팩터링 / 버그 수정 등 명확한 분류• 작업 내용: 주요 변경 사항, 영향 범위 등 구체적 기술• Check List: 테스트 여부, API 문서 반영 여부 등 사전 확인• Reviewer 요청 사항: 확인이 필요한 부분이나 리뷰어에게 전달할 맥락 명시코드 리뷰 시에는 가독성, 일관성, 예외 처리, 트랜잭션 처리 등을 중점적으로 확인합니다. |
