[개발일지] WingITs #2 - 기능은 어떻게 정했을까?

개발을 결심한 건 좋았지만, 막상 만들려고 보니 머릿속이 하얘졌습니다.

“그래서… 이걸 뭐부터 만들어야 하지?”

📌 기능 목록은 어디서 나왔을까?

시작은 아주 단순했습니다.
실제 업무 중 겪은 수리 요청 절차의 불편함을 ‘어떻게 하면 시스템화할 수 있을까’에서 출발했기 때문이죠.

그래서 처음엔 그냥 내가 자주 들었던 말들을 적어봤습니다.

• "선생님, 제 노트북 수리 요청하고 싶은데요."
• "담당자분 누구셨어요?"
• "수리 맡긴지 오래됐는데 지금 어디 있는지 모르겠어요."
• "어떤 학생 노트북이 고장나서 다른 노트북으로 교환했는데 지금 누가 사용하고있는지 모르겠네요."

이런 대화 속에서 필요한 기능들이 자연스럽게 떠올랐습니다.

🎯 최소 기능 목록

• 학생
  • 수리 요청 등록
  • 내가 맡긴 수리 내역 확인
• 관리자
  • 수리 요청 목록 보기
  • 요청 상태 변경 (접수됨 / 수리 중 / 완료 등)
  • 수리 이력 관리

우선은 이 정도만 있어도 “입력 → 처리 → 이력 확인”의 흐름이 가능하다고 생각했습니다.

🔁 기능을 정하면서 고민했던 점들

처음엔 기능이 아주 단순할 거라고 생각했지만, 실제로 만들다 보니 하나하나에서 고민할 게 정말 많았습니다.

1. 수리 요청은 누구나 할 수 있을까?

→ 아니다. 로그인한 학생만 가능해야 했고, 중복 요청은 방지해야 했습니다.
→ 그래서 상태가 '처리 중'인 요청이 있을 땐, 새 요청을 막는 로직을 넣었습니다.

2. 관리자 권한은 어떻게 나눌까?

→ 그냥 다 admin이면 될 줄 알았는데, 관리자도 중간 관리자 / 최고 관리자로 나눠야 했습니다.
(관리자 인원이 증가할수록 수동으로 사용자를 변경하는 기능을 모든 관리자가 할 수 있다면 잘못 설정하는 일이 발생할 수 있다고 생각이 들었습니다.)

3. 수리 요청 상태는 어떻게 설계할까?

→ '요청됨 → 수리 중 → 수리 완료'처럼 간단해보이지만, 학생들이 요청서를 잘못 적는 경우도 있기 때문에 실제로는 '반려됨'같은 예외 상태도 필요했습니다.

→ 그래서 enum으로 RepairStatus를 설계하고, 뷰에서도 한눈에 상태별 UI를 바꿔줄 수 있도록 처리했습니다.

🧠 흐름도와 ERD의 시작

처음에는 아주 단순한 흐름만 그렸습니다.

• 수리 요청 흐름: 학생 → 요청 등록 → 관리자 확인 → 처리
• 화면 구성: 로그인 → 메인 → 내역 확인 (학생) / 전체 요청 관리 (관리자)

ERD도 초안은 금방 그렸지만, 개발을 진행하면서 기능이 늘어나고 흐름이 바뀌며 구조도 계속 수정됐습니다.

그래서 이 글에서는 구체적인 ERD보다는, 어떤 기능을 어떤 흐름으로 구현했는지에 초점을 맞춰 정리해보려 합니다.

🤔 정리하며

‘기획’이라고 해서 거창한 게 필요한 건 아니었습니다. 오히려 내가 겪은 불편함을 적어보는 것부터 시작하니 그 안에서 자연스럽게 기능들이 나왔습니다.

무조건 많이 만들기보다는, 실제로 필요한 흐름을 작동시킬 수 있는 최소한의 기능에서 부터 출발하는 게 정말 중요하다고 느꼈습니다.

다음 글에서는...

✅ 개발 중 가장 복잡했던 "학생과 관리자, 로그인은 같지만 권한은 다르게"
인증 방식과 권한 분리, 그리고 로그인 흐름 설계에 대해 자세히 풀어보려 합니다.