웹앱 기획할 때 관리자 화면을 놓치면 생기는 일 — 1인 개발에서 꼭 고려할 것

강사 일정관리 웹앱을 기획할 때, 처음엔 단순하게 생각했다. 사용자가 일정을 보고 신청하면 끝이라고. 그런데 관리자 화면을 설계하기 시작하면서 그게 얼마나 순진한 생각이었는지 바로 알게 됐다.

다른 디자인 업무를 병행하면서 틈틈이 진행한 프로젝트였는데, 생각보다 훨씬 오래 걸렸다. 기능 자체가 복잡해서가 아니라, 처음 기획이 관리자 입장을 전혀 고려하지 않아서였다. 1인으로 기획과 개발을 같이 하다 보면 빠지기 쉬운 함정이었다.

사용자 화면만 기획했다 — 관리자를 생각 못했다

처음 기획할 때 사용자 흐름은 꼼꼼하게 잡았다. 로그인 → 일정 확인 → 신청 → 완료. 깔끔했다. 그런데 막상 관리자 화면을 설계하려고 앉았을 때 막막했다.

관리자는 사용자가 신청한 내용을 어떻게 확인하는가? 승인/거절은 어떻게 처리하는가? 취소 요청이 들어오면? 일정이 변경되면 신청자들에게 어떻게 알리는가? 사용자 화면에서 한 줄로 끝났던 "신청"이 관리자 입장에서는 수십 가지 케이스로 쪼개졌다.

예외 케이스가 기능보다 많았다

기능 자체는 단순했다. 문제는 예외 케이스였다. 예를 들어 "일정 취소" 하나만 해도 이런 경우들을 다 고려해야 했다.

• 1 신청자가 취소하는 경우
• 2 관리자가 강제 취소하는 경우
• 3 일정 자체가 없어지는 경우
• 4 취소했다가 다시 신청하는 경우
• 5 마감된 일정에 취소 요청이 들어오는 경우

이 케이스들을 하나하나 따지다 보니 처음에 잡았던 데이터 구조가 맞지 않아서 중간에 구조를 바꿔야 했다. 이미 만들어진 코드를 뜯어고치는 시간이 새로 만드는 것보다 더 오래 걸렸다.

사용자와 관리자 로직이 연결되는 지점이 제일 어려웠다

사용자가 "신청 완료" 상태를 보는 것과 관리자가 "신청 목록"을 보는 것은 같은 데이터를 다른 방향에서 보는 것이다. 이 두 화면이 같은 데이터를 바라보면서도 각자 다르게 동작해야 했다. 사용자 쪽 상태가 바뀌면 관리자 쪽에도 반영돼야 하고, 관리자가 처리하면 사용자 화면도 달라져야 했다.

이 연결 지점을 처음부터 설계에 반영하지 않았던 게 가장 큰 실수였다.

💡 1인 기획에서 관리자 화면을 먼저 그려봐야 하는 이유 사용자 화면은 보기 좋게 단순하게 만들 수 있다. 하지만 그 단순함을 만들어내는 건 관리자 쪽의 복잡한 로직이다. 기획 초반에 관리자 화면을 함께 그려보면 데이터 구조와 예외 케이스를 미리 파악할 수 있다. 나중에 뜯어고치는 것보다 훨씬 낫다.

1인으로 웹앱을 기획할 때 사용자 화면만 먼저 설계하면 나중에 관리자 구현에서 막히기 쉽다.
기능이 단순해 보여도 관리자 입장에서는 예외 케이스가 훨씬 많고, 사용자와 관리자 로직이 연결되는 지점을 미리 설계에 반영해야 한다.
기획 초반에 관리자 화면을 함께 그려보는 것이 시간을 아끼는 방법이다.
이 프로젝트는 기획부터 UI 설계, 개발, 배포까지 1인으로 완성했다. 돌아보면 가장 많은 시간을 잡아먹은 건 코드가 아니라 기획이었다.