StudyPot
FrontendAI 팀장이 운영을 보조하는 스터디 그룹 관리 플랫폼
StudyPot · SSAFY 최우수상
스터디장에게 몰리는 운영 부담과 팀원 간 의사결정·합의 병목을 줄이기 위해, AI 팀장이 커리큘럼·회고·규칙 운영을 대신 챙겨주는 스터디 관리 플랫폼입니다.
프로젝트 개요
- 목표
- 스터디장에게 집중되는 운영 업무와 팀원 간 의사결정 부담을 줄이는 스터디 관리 플랫폼을 구현했습니다.
- 배경
- 일정·커리큘럼 관리, 참여 확인, 회고와 규칙 운영이 메신저와 수작업에 흩어져 있으면 운영 부담이 스터디장에게 집중됩니다.
- 주요 기능
- 그룹 생성과 초대 코드 참여부터 온보딩(스터디 목표·세부 키워드 설정)까지 스터디 개설 흐름을 하나로 연결했습니다.
- 커리큘럼 Todo, 회고, AI 팀장 답변(마크다운 렌더링) 등 스터디 운영을 AI가 관리하도록 구성했습니다.
- 그룹 규칙과 위반 관리, 알림·운영 로그, 그룹 스페이스(게시판·마이페이지)까지 운영에 필요한 기능을 갖췄습니다.
- FSD(pages/entities/features/shared/widgets) 레이어로 도메인 경계를 설계해 팀원 간 작업 충돌을 줄였습니다.
역할·팀 구성
팀 내 역할 분담 · 2인 팀
- Frontend Lead · 본인, 1명
- 서비스 기획과 Vue 기반 프론트엔드 구조·화면, API 연동
- Backend, 1명
- Spring 기반 API, 인증·인가 및 MySQL 데이터 처리 담당
담당 역할
Frontend Lead (기획 · FE 설계)
2인 팀에서 서비스 기획과 프론트엔드 설계·구현 전반을 맡고, API 계약을 먼저 정리해 백엔드 개발과 병렬로 진행했습니다.
FE 구조·컨벤션 설계
- FE 구조 설계·구현 총괄
프론트엔드 리드로 FE 구조 설계와 구현 담당
- FSD 레이어 구조 설계·적용
FSD 아키텍처의 레이어 구조 설계 및 팀 전체 컨벤션 적용
- 협업 컨벤션 문서화
ESLint/Prettier, PR·이슈 템플릿, 코드·커밋 컨벤션을 문서화해 협업 방식 표준화
MSW 기반 선행 개발로 일정 단축
- MSW 기반 선행 개발
미구현 도메인의 API 타입·함수·MSW 핸들러를 먼저 정리해 BE 연동 전에 UI와 로직 개발 완주
- 개발 기간 단축 성과
이 선행 작업으로 전체 개발 기간 약 30% 단축
핵심 화면 구현
- 쿠키 세션 인증
쿠키 세션 인증 화면 구현
- 그룹 생성·초대 코드 참여
그룹 생성과 초대 코드 참여 화면 구현
- 온보딩
온보딩 화면 구현
- 커리큘럼 투두
커리큘럼 투두 화면 구현
- 회고·AI 팀장
회고와 AI 팀장 화면 구현
- 알림·운영 로그
알림과 운영 로그 화면 구현
- 그룹 스페이스
그룹 스페이스 화면 구현
사용 기술 & 이유 & 구현
Vue 3 · TypeScript
- 선택 이유
- 스터디 운영 흐름을 컴포넌트로 나누고 API 계약을 타입으로 표현하기 위해 사용했습니다.
- 구현 내용
- 그룹·온보딩·커리큘럼·회고 화면과 쿠키 세션 기반 인증 연동을 구현했습니다.
FSD
- 선택 이유
- 인증, 그룹, 스터디 운영 기능의 경계와 의존 방향을 명확하게 관리하기 위해 적용했습니다.
- 구현 내용
- pages, widgets, features, entities, shared 레이어로 코드를 배치하고 팀 컨벤션에 반영했습니다.
MSW
- 선택 이유
- 백엔드 API가 완성되기 전에 실제 요청 형태로 화면과 로직을 개발하기 위해 사용했습니다.
- 구현 내용
- API 타입·함수와 목 핸들러를 먼저 구성해 연동 대기 없이 프론트엔드를 구현했습니다.
Pinia · Axios
- 선택 이유
- 공유 상태와 API 요청 처리를 화면 코드에서 구분하기 위해 사용했습니다.
- 구현 내용
- Vue의 공유 상태와 HTTP 요청 계층을 구성하고 인증·그룹 운영 API를 연결했습니다.
문제 해결 사례
사례 1API 계약과 MSW로 백엔드 연동 대기 해소
1. 오류 분석
- 문제 현상
- 2인 팀에서 프론트엔드가 미구현 API를 기다리면 화면 개발과 기능 검증까지 순차적으로 밀리는 병목이 있었습니다.
- 원인
- 화면과 사용자 흐름이 서버 응답 형태에 의존해 실제 API 없이는 기능을 이어서 구현하기 어려웠습니다.
- 추가 확인 사항
- 목 응답이 실제 API 계약과 달라지지 않도록 요청·응답 타입과 함수를 함께 정리해야 했습니다.
2. 개선 과정
- 1.미구현 도메인 정리
- 2.API 계약 합의
- 3.요청·응답 타입 작성
- 4.MSW 핸들러 구성
- 5.UI·로직 선행 개발
- 6.실제 API 연동
미구현 도메인의 API 타입과 호출 함수, MSW 핸들러를 먼저 정리했습니다. 같은 요청 경로로 목 응답을 받아 UI와 로직 개발을 진행한 뒤 실제 서버에 연동했습니다.
3. Before & After 비교
| 항목 | Before | After |
|---|---|---|
| 개발 흐름 | API 구현 후 화면 연동 | API 계약 기반 병렬 개발 |
| 개발 중 응답 | 미구현 API 응답 대기 | MSW 핸들러로 선행 검증 |
| 개발 기간 | 기존 진행 방식 기준 | 약 30% 단축 |
개발 기간 단축률은 기존 프로젝트 기록 기준이며, 별도의 작업 시간 측정 로그는 제시하지 않습니다.
해결 결과
프론트엔드 UI와 로직 개발을 백엔드 연동 전에 마치고, 2인 팀에서 전체 개발 기간을 약 30% 줄였습니다.
프로젝트 성과 및 결과
- 2인 팀에서 서비스 기획과 프론트엔드 구조·핵심 화면 구현 주도
- API 타입·MSW 기반 선행 개발로 전체 개발 기간 약 30% 단축
- 그룹 생성부터 커리큘럼·회고·규칙 관리까지 스터디 운영 흐름 구현
StudyPot · SSAFY 최우수상
프로젝트 회고
기술적 한계와 개선 방안
- 한계·아쉬운 점
- 목 API로 정상 흐름을 확인해도 실제 서버의 쿠키·권한·예외 처리는 별도로 검증해야 합니다.
- 개선 방향
- API 계약 변경 시 목 핸들러도 함께 갱신하고 로그인 → 그룹 참여 → 운영 기능까지 Playwright 시나리오로 확장할 계획입니다.
- 한계·아쉬운 점
- 기능 완성만으로 스터디장의 실제 운영 부담이 얼마나 줄었는지 설명하기 어렵습니다.
- 개선 방향
- 그룹 개설 완료율과 운영 기능 사용 흐름을 측정해 사용자 행동을 기준으로 개선 우선순위를 정할 계획입니다.