📝 사내 그룹웨어 개발 (ai를 활용한 요구사항 정리) — Day 1

프로젝트를 시작하며

sk쉴더스 지능형 애플리케이션 5기 부트캠프에서 한 달 동안 Spring과 React를 학습한 뒤,
10일 동안 팀 프로젝트를 진행하게 되었다.

이번 프로젝트의 주제는 사내 프로젝트 트래킹과 연차 전자결재를 지원하는 그룹웨어 개발이다.
짧은 기간 안에 핵심 기능을 구현해야 하는 만큼, 1일차에는 구현보다 요구사항 정리와 범위 확정에 가장 많은 시간을 썼다.

---

프로젝트 개요

이번 프로젝트는 프로젝트 단위의 업무를 관리하고, 연차 신청과 결재까지 하나의 서비스 안에서 처리하는 그룹웨어를 만드는 것이 목표였다.

기본적인 방향은 아래처럼 잡았다.

• 개발 기간: 10일
• 인원: 5명
• 주요 기능:
  • 프로젝트 관리
  • 업무(Task) 관리
  • 캘린더 및 근태 확인
  • 연차 신청 / 승인 / 반려
  • 진행도 확인

사용자 역할은 크게 두 가지로 나눴다.

• USER: 일반 사용자
• ADMIN: 관리자

처음에는 기능이 많아 보였지만, 실제로 10일 안에 구현 가능한 범위는 훨씬 좁았다.
짧은 프로젝트일수록 기능을 늘리는 것보다, 꼭 필요한 흐름을 명확히 하고 이후에도 수정과 유지보수가 가능한 구조를 만드는 쪽이 더 중요하다고 느꼈다.

---

요구사항을 정리하면서 가장 먼저 막힌 지점

가장 어려웠던 건 기술이 아니라 도메인 이었다.
회사를 인턴으로만 경험해봐서, 그룹웨어에 어떤 기능이 실제로 필요한지 처음부터 명확하게 떠오르지는 않았다.

처음에는 인턴 경험에서 기억나는 흐름을 바탕으로 기능을 적어봤다.
로그인, 프로젝트 관리, 업무 확인, 연차 신청처럼 익숙한 흐름은 비교적 쉽게 나왔지만, 막상 정리해보니 애매한 부분이 많았다.

예를 들면 이런 것들이었다.

• 사용자가 직접 Task를 생성하는 구조가 맞는지
• 관리자는 어디까지 권한을 가져야 하는지
• 근태 기능을 단순 일정 확인까지만 둘지, 출퇴근 기록까지 포함할지
• 연차 결재 흐름에서 반려 사유나 잔여 연차 차감은 어떻게 처리할지

이런 부분은 단순히 기능만 적는다고 해결되지 않았다.
결국 기능 정의는 사용자 역할, 업무 흐름, 권한 구분을 함께 봐야 한다는 걸 느꼈다.

요구사항 정리를 위해 했던 방식

먼저 팀원들이 각자 생각하는 유저 흐름을 적어본 뒤, 이를 하나로 합치면서 초안을 만들었다.
그 다음에는 문서를 Markdown 형태로 정리해서, 기능과 흐름이 섞이지 않도록 기준을 세웠다.

 

조사해본 결과, ChatGPT는 초안을 구조화하고 표현을 다듬는 데, Claude는 긴 Markdown 문서를 기준으로 누락과 충돌을 점검하는 데, Gemini는 기능 구성을 다시 분류하고 전체 흐름을 재검토하는 데 상대적으로 잘 맞는 편이었다. 그래서 요구사항을 정리할 때도 하나의 모델에만 의존하지 않고, 각 모델의 장점에 맞춰 검토 방식을 나눴다.

 

내가 정리한 방식은 아래와 같다.

• ChatGPT
  • 요구사항 초안을 더 읽기 쉬운 구조로 정리
  • 사용자 흐름을 단계별 문장으로 풀어보기
  • MVP 범위에서 불필요하게 넓어진 기능 줄이기 
• Claude
  • Markdown 문서 전체를 기준으로 누락된 흐름이 없는지 점검
  • USER / ADMIN 권한이 서로 충돌하지 않는지 검토
  • 문서 앞뒤 맥락이 어색하지 않은지 리뷰
• Gemini
  • 기능 묶음이 자연스러운지 다시 분류
  • 사용자 흐름과 관리자 흐름이 실제 서비스처럼 이어지는지 점검
  • 레퍼런스와 비교했을 때 빠진 핵심 기능이 없는지 확인

내가 먼저 작성한 초안을 기준으로 누락, 충돌등의 검토하는 역할을 맡겨 더 수월하게 했다.

• “이 요구사항에서 USER와 ADMIN 권한 구분이 자연스러운가?”
• “연차 결재 흐름에 빠진 단계가 있는가?”
• “10일짜리 MVP 기준에서 과한 기능은 무엇인가?”
• “Task 생성 권한을 관리자만 갖는 구조가 어색하지 않은가?”

이런 질문을 던지고, 각 모델의 답변을 비교하면서 요구사항을 조금씩 다듬었다.

 

활용 예시 / gpt(왼) claude(오)

---

정리 과정에서 나온 주요 논의

초안을 합치는 과정에서 몇 가지 포인트를 집중적으로 봤다.

1. Task 생성 주체

처음에는 “본인 업무 등록”이라는 표현이 모호했다.
사용자가 직접 Task를 만드는 구조인지, 관리자가 업무를 배정하고 사용자는 상태만 바꾸는 구조인지 의견이 나뉘었다.

논의 끝에는 Task 생성은 관리자만 가능하도록 정리했다.
이렇게 해야 권한 구조가 단순해지고, 프로젝트 관리 기능과도 더 자연스럽게 연결된다고 봤다.

2. 근태 기능 범위

캘린더와 근태 관리는 넣고 싶었지만, 실제 출퇴근 기록까지 확장하면 범위가 커질 가능성이 컸다.
그래서 1일차 기준으로는 기본적인 일정 확인 중심으로 열어두고, 상세 범위는 추후 다시 보기로 했다.

3. 인증 방식

로그인 기능에서 JWT 인증을 사용할지, Refresh Token까지 포함할지에 대한 논의도 있었다.
하지만 일정이 짧았기 때문에, 1일차에는 인증 구조를 깊게 파기보다는 핵심 기능 흐름 정리를 우선으로 두었다.

최종 MVP 범위

여러 번 요구사항을 줄이고 다시 보면서, 10일 안에 구현 가능한 MVP 범위는 아래처럼 정리했다.

• 회원가입 / 로그인
• 프로젝트 CRUD
• Task 생성 및 상태 변경
• 연차 신청
• 연차 승인 / 반려
• 진행도 확인

처음에는 넣고 싶은 기능이 더 많았지만, 결국 중요한 건 다양한 기능 보다 사용자 흐름이 끊기지 않는 것이라고 판단했다.

유저 플로우

요구사항을 정리한 뒤에는 사용자와 관리자 흐름을 따로 정리했다.

사용자 플로우

회원가입 → 로그인 → 프로젝트 / 업무 조회 → 업무 상태 변경 → 캘린더 확인 → 연차 신청 → 신청 내역 확인

관리자 플로우

로그인 → 권한 부여 → 업무(Task) 배정 → 연차 내역 조회 → 승인 / 반려

연차 결재 흐름

사용자: 연차 신청
→ 관리자: 신청 내역 확인
→ 승인 또는 반려(사유 작성)
→ 승인 시 잔여 연차 자동 차감

이 부분은 나중에 ERD나 API 명세를 작성할 때 기준점이 될 것 같아서, 1일차에 최대한 명확하게 잡아두려고 했다.

 

 

 

https://evernote.com/ko-kr/ai-diagrams/ai-diagram-generator

AI 다이어그램 생성기

 

정리한 유저 플로우는 Evernote AI 다이어그램 생성기를 활용해 다이어그램 형태로 옮겼다. 텍스트 설명을 순서도나 마인드맵으로 구조화해 주는 방식이라, 초기 흐름을 빠르게 시각화하는 데 도움이 됐다.

---

1일차 회고

같은 그룹웨어를 생각하더라도 팀원마다 떠올리는 흐름이 조금씩 달랐고, 차이를 맞추는 데 생각보다 시간이 걸렸다.

특히 나는 실무를 인턴으로만 경험해봐서, 그룹웨어 기능을 처음부터 구조적으로 정리하는 과정이 가장 어려웠다.

그래서 인턴 경험을 바탕으로 먼저 초안을 적고, 레퍼런스를 찾아보며 보완했다.

그리고 Markdown으로 정리한 요구사항 문서를 기준으로, 모델별 검토 역할을 나눠 누락된 흐름과 권한 충돌을 다시 점검했다.

이 과정을 거치면서 느낀 건, 요구사항를 정확하게 설계해야하는것 같다.

누가, 언제, 무엇을 할 수 있는지를 명확히 해야 나머지 설계, 개발 할때도 수월한 것 같다.

 

또 하나 느낀 점은, 짧은 프로젝트일수록 기능을 잘 더하는 것보다 잘 덜어내는 것이 더 중요하다는 점이었다. 
욕심을 내기보다, 실제로 끝까지 구현할 수 있는 흐름을 남기는 게 더 중요했다.

다음 할 일

• DB 설계 및 ERD 작성
• API 명세 초안 작성
• 와이어프레임 작업 시작

1일차는 기획을 명확하기 위해 회의가 정말 길었지만 이후 개발의 방향을 정하는 데 가장 중요한 날이었다고 느꼈다.
다음 글에서는 요구사항을 바탕으로 정리한 ERD와 API 초안을 남겨보려고 한다.