[외주] 첫 화면을 만든 뒤, 요구사항이 더 구체화되다 - 3/17

고시원에 들어오게 된 계기와 프로그램 이야기가 자연스럽게 연결되면서, 원장님이 실제로 어떤 기능을 필요로 하시는지도 조금씩 구체적으로 들을 수 있었다. 처음에는 단순히 “고시원 상태를 관리할 수 있으면 좋겠다”는 수준의 이야기였지만, 대화를 나누다 보니 필요한 기능은 크게 두 가지 축으로 정리되었다.

 

 

원장님의 요구사항을 다시 정리해보면

1. 고시원 전체 상태를 한눈에 볼 수 있는 대시보드

원장님은 나에게 고시원 1층부터 6층까지에 해당하는 위에서 내려다본 형태의 도면을 주셨다. 그리고 이 도면을 프로그램 안에 그대로 넣어서, 각 방의 상태를 직관적으로 확인할 수 있으면 좋겠다고 말씀하셨다.

 

즉, 단순히 방 번호만 텍스트로 나열된 화면이 아니라, 실제 고시원의 구조를 반영한 화면이 필요했던 것이다. 각 층의 도면 위에서 방을 클릭하면, 그 방에 현재 누가 살고 있는지, 언제부터 언제까지 거주하는지를 바로 확인할 수 있어야 했다. 반대로 입실자가 없는 방이라면, 해당 방이 현재 빈방인지도 바로 보여줄 수 있어야 했다.

 

이 요구사항을 정리해보면 결국 이런 화면이 필요했다.

• 1층부터 6층까지의 구조를 반영한 도면형 대시보드
• 각 호실을 클릭했을 때 현재 입실자 정보 확인
• 입실 시작일과 종료일 확인
• 빈방 여부를 즉시 파악할 수 있는 상태 표시

 

이 기능은 고시원 운영자 입장에서 굉장히 중요해 보였다. 고시원은 방이 많고, 입실과 퇴실이 계속 바뀌기 때문에 텍스트 목록만으로는 현재 상태를 바로 파악하기 어렵다. 반면 도면 기반의 화면이 있다면, 실제 공간 구조와 함께 상태를 이해할 수 있기 때문에 훨씬 직관적으로 관리할 수 있다.

 

 

2. 입실자 관리 장부 리스트

두 번째로 필요한 기능은 입실자 관리 장부였다. 이 부분은 단순한 조회가 아니라, 운영에 필요한 실질적인 관리 기능에 가까웠다.

 

원장님이 원하셨던 것은 각 방마다 현재 누가 거주 중인지, 언제 입실했고 언제 퇴실 예정인지, 월세는 얼마인지, 그리고 이번 달 월세를 납부했는지를 표 형태로 관리할 수 있는 화면이었다. 특히 월세 납부 여부를 확인할 수 있는 구조가 중요하다고 느껴졌다.

 

즉, 장부 리스트에는 다음과 같은 정보가 포함되어야 했다.

• 방 번호
• 입실자 이름
• 거주 시작일
• 거주 종료일
• 월세 금액
• 이번 달 월세 납부 여부
• 미납 상태 여부

이 기능은 운영자 입장에서 일종의 관리 장부 역할을 한다.

 

대시보드가 “현재 방 상태를 한눈에 보는 화면”이라면, 장부 리스트는 “입실자와 월세 상태를 표로 정리해서 관리하는 화면”에 가깝다. 실제 운영에서는 누가 어디에 사는지만 아는 것으로 끝나지 않고, 계약 기간과 월세 납부 여부까지 함께 관리되어야 하기 때문이다.

 

 

이번 프로젝트의 첫 요구사항은 크게 두 가지였다

이렇게 원장님의 요구사항을 정리해보니, 프로젝트의 핵심은 크게 두 가지로 나뉘었다. 첫 번째는 공간 중심의 관리다. 즉, 1층부터 6층까지의 도면을 기준으로 각 방의 상태를 바로 확인할 수 있어야 한다.

 

두 번째는 입실자 중심의 관리다. 즉, 각 입실자의 거주 정보와 월세 납부 상태를 장부 형태로 관리할 수 있어야 한다. 정리하면 이 프로젝트는 단순한 메모 프로그램이 아니라, 고시원의 공간 정보와 입실자 정보를 함께 관리하는 웹 기반 운영 도구에 가까웠다.

 

처음에는 막연히 “고시원 관리 프로그램”이라고 생각했지만, 요구사항을 하나씩 구체화해보니 결국 필요한 것은 다음 두 화면이었다.

• 도면을 기반으로 현재 상태를 직관적으로 보여주는 대시보드
• 입실자와 월세 납부 상태를 표 형태로 관리하는 장부 리스트

이 두 기능이 이번 프로젝트의 출발점이 되었다.

 

 

어떻게 개발할지에 대한 첫 고민

요구사항을 정리하고 나니, 그다음으로 고민하게 된 것은 “이걸 어떤 방식으로 만들 것인가”였다. 기능 자체는 비교적 명확했다. 도면 기반 대시보드가 있어야 하고, 입실자 장부와 월세 납부 현황을 관리할 수 있어야 했다. 하지만 실제로 만들려고 보면 기술 선택 이전에 먼저 결정해야 할 기준이 있었다.

 

내가 먼저 중요하게 본 것은 크게 세 가지였다.

• 첫째, 어디서든 접속할 수 있어야 한다는 점이다.
  • 이 프로그램은 특정 PC에 설치해서 쓰는 방식보다, 사장님이나 원장님, 총무분들이 각자 필요한 곳에서 바로 접속할 수 있는 형태가 더 적합했다. 결국 자연스럽게 데스크톱 프로그램보다는 웹 기반 서비스가 더 맞다고 판단했다.
• 둘째, 관리 인원이 많지 않다는 점이다.
  • 이 고시원은 대규모 조직이 아니라 사장님, 원장님, 총무 두 분 정도가 운영에 관여하고 있었다. 즉, 엄청나게 복잡한 엔터프라이즈 시스템보다는 소수의 운영자가 안정적으로 사용할 수 있는 가볍고 실용적인 구조가 더 중요했다.
• 셋째, 초기 개발과 운영 부담을 줄여야 한다는 점이다.
  • 이번 프로젝트는 아주 큰 예산이 들어가는 정식 외주가 아니라 월세를 일부 깎아주는 대신 진행하는 형태에 가까웠다. 그렇기 때문에 처음부터 서버, 인프라, 인증, 데이터베이스, 배포 구조를 전부 무겁게 가져가는 것은 오히려 과하다고 느꼈다. 우선은 실제로 운영 가능한 MVP를 빠르게 만드는 것이 중요했다.

 

이 기준들을 놓고 보니, 처음부터 백엔드 서버를 별도로 두고 복잡한 인프라를 운영하기보다는, 가능하면 서버 운영 부담을 줄이고 빠르게 시작할 수 있는 구조가 더 적합하다고 생각했다.

 

왜 굳이 서버를 따로 두지 않는 방향을 먼저 생각했는가

보통 웹 서비스를 만든다고 하면 프론트엔드와 백엔드를 분리해서 생각하기 쉽다. 예를 들어 프론트엔드는 Next.js나 React로 만들고, 백엔드는 Spring Boot 같은 서버를 따로 두는 구조다. 나 역시 평소에는 Spring Boot 기반으로 백엔드를 만드는 데 익숙하기 때문에 이런 구조를 먼저 떠올릴 수 있었다.

 

하지만 이번 프로젝트에서는 그 방식이 꼭 최선은 아니라고 판단했다. 이유는 간단했다. 이 프로젝트의 핵심은 대규모 트래픽 처리가 아니라 운영 정보 관리에 있었다. 즉, 방 상태 조회, 입실자 정보 관리, 월세 납부 여부 체크처럼 비교적 전형적인 CRUD 중심 기능이 대부분이었다. 이런 요구사항에서는 인증, 데이터 저장, 간단한 권한 제어, 배포 편의성이 훨씬 더 중요했다.

 

만약 별도의 서버를 둔다면 다음과 같은 것들을 전부 직접 책임져야 한다.

• 백엔드 서버 배포와 운영
• 데이터베이스 연결과 관리
• 로그인 및 인증 처리
• 권한 제어 로직
• 장애 대응과 유지보수

 

물론 직접 서버를 두면 더 세밀한 제어가 가능하다는 장점이 있다. 하지만 지금 단계에서 중요한 것은 “복잡한 구조를 설계하는 것”보다 “실제로 사용할 수 있는 프로그램을 빠르게 만드는 것”이었다. 그래서 처음에는 BaaS(Backend as a Service) 형태를 적극적으로 검토하게 되었다.

 

즉, 직접 서버를 크게 운영하기보다 프론트엔드 중심으로 빠르게 개발하고, 인증과 데이터 저장은 관리형 서비스의 도움을 받는 방식이 더 현실적이라고 보았다.

 

 

왜 Next.js를 먼저 떠올렸는가

웹으로 만들기로 방향을 잡은 뒤에는 자연스럽게 프론트엔드 프레임워크를 고민하게 되었다. 여기서 나는 Next.js를 우선적으로 고려했다.

 

이유는 몇 가지가 있었다.

1. 첫 번째는 웹 서비스 형태로 빠르게 화면을 만들기 좋다는 점이다.
   1. 이번 프로젝트는 일반적인 관리자 페이지 성격이 강하다. 대시보드, 리스트, 상세 조회, 입력 폼 같은 화면이 중심이기 때문에 React 기반 생태계가 잘 맞는다. 그중에서도 Next.js는 프로젝트 구조를 잡기 쉽고, 라우팅과 배포까지 비교적 정리된 방식으로 가져갈 수 있다.
2. 두 번째는 추후 확장에 유리하다는 점이다.
   1. 처음에는 단순히 방 상태 조회와 장부 관리부터 시작하더라도, 나중에는 권한 분리, 통계 화면, 검색, 필터링, 월별 정산, 알림 같은 기능이 추가될 수 있다. Next.js는 이런 관리자형 웹 서비스가 점점 커졌을 때도 구조를 확장하기 좋다고 판단했다.
3. 세 번째는 배포 선택지가 넓다는 점이다.
   1. Vercel처럼 간단한 플랫폼에 배포할 수도 있고, 필요하면 Node 서버나 Docker 기반으로 옮길 수도 있다. 즉, 초기에는 가볍게 시작하고 나중에 운영 방식이 바뀌더라도 대응할 여지가 있다.

결국 내 입장에서는 Next.js가 빠르게 시작할 수 있으면서도, 나중에 커져도 버틸 수 있는 현실적인 선택지로 보였다.

 

그래서 기술 선택은 두 방향으로 좁혀졌다

이렇게 기준을 세우고 보니, 초기 구조는 크게 두 가지 방향으로 압축되었다.

1. Next.js + Supabase
2. Next.js + Google Drive 연동

둘 다 “웹에서 접근 가능하다”는 요구사항은 충족할 수 있다. 하지만 데이터 구조, 권한 모델, 장부 관리의 복잡성, 이후 확장 가능성까지 고려하면 차이가 분명했다.

 

아키텍처 간단 설계

1. Next.js + Supabase

Supabase는 Postgres 데이터베이스, 인증(Auth), 스토리지(Storage), 실시간 기능(Realtime) 등을 함께 제공하는 플랫폼이다. 이번 프로젝트처럼 데이터를 저장하고, 지정된 사용자만 로그인해 접근하며, 관리 화면을 운영해야 하는 서비스와 잘 맞는다고 판단했다.

 

장점

1. 요구사항이 DB 중심 서비스에 잘 맞는다

• 이 프로젝트는 결국 방, 입실자, 계약 기간, 월세, 납부 여부 같은 데이터를 구조적으로 관리해야 한다. 즉, 관계형 데이터베이스 기반으로 설계하는 것이 자연스럽다.

2. 인증과 권한 설계에 유리하다

• 지정된 사용자만 들어올 수 있어야 한다는 점이 중요했다. 예를 들어 대표님은 전체 보기, 직원은 일부 메뉴만 접근, 일반 사용자는 접근 불가 같은 식의 제어가 필요할 수 있다. Supabase는 Auth를 제공하기 때문에 이런 구조를 설계하기가 훨씬 수월하다.

3. 장부 관리에 적합하다

• 장부는 결국 날짜, 방번호, 입실자, 금액, 메모, 정산 상태 같은 데이터가 쌓이는 구조다. 처음에는 스프레드시트로도 가능해 보일 수 있지만, 수정 이력, 잘못 입력한 내역 복구, 필터링, 집계가 필요해질수록 데이터베이스 기반이 훨씬 유리하다.

4. 어디서든 접속 가능한 구조를 만들기 쉽다

• Supabase와 Next.js 모두 클라우드 기반으로 운영이 가능하기 때문에, 해외든 국내든 웹으로 접속 가능한 형태를 만들기 쉽다.

5. 추후 확장 가능성이 좋다

• 처음에는 단순 조회와 장부 관리만 하더라도, 이후 알림, 권한 세분화, 통계, 검색 기능 등으로 확장하기가 좋다.

 

2. Next.js + Google Drive 연동

Google Drive API를 활용해서 구글 드라이브나 구글 시트와 연동하는 방식도 후보였다. 특히 초기 MVP를 아주 빠르게 만드는 데는 꽤 매력적인 선택지라고 느꼈다.

 

장점

1. 기존 구글 생태계와 연결하기 쉽다

• Google Drive API는 Drive 연동, 공유 드라이브 지원, 파일 변경 이력, 푸시 알림 같은 기능을 제공한다.

2. 익숙한 도구를 그대로 활용할 수 있다

• 대표님이나 직원분들이 이미 구글 드라이브나 구글 시트에 익숙하다면, 학습 비용이 낮다.

3. 초기 MVP 속도가 빠를 수 있다

• 구글 로그인, Drive/Sheets API 연동, 시트 데이터 읽기, 방 상태 표시, 시트 입력 정도까지는 비교적 빠르게 구현할 수 있다. 즉, “일단 돌아가는 것”을 만드는 속도만 보면 꽤 유리하다.

 

단점

1. Drive는 운영 DB로 쓰기엔 한계가 있다

• 구글 드라이브나 시트는 문서 협업 도구로는 훌륭하지만, 업무 시스템의 핵심 데이터를 저장하는 주 데이터이스로 보기에는 구조적 한계가 있다.

2. 권한 모델이 애매하다

• 파일 공유 권한은 줄 수 있어도, 앱 내부에서 역할별로 세밀한 접근 제어를 하려면 불편해질 수 있다.

3. 장부가 커질수록 유지보수가 어렵다

• 월별 집계, 특정 입실자 기준 정산, 계약 만료 필터, 미납 체크, 수정 로그 관리처럼 요구사항이 늘어날수록 스프레드시트 중심 구조는 점점 불편해질 가능성이 크다.

 

결론

정리해보면, Google Drive 연동 방식은 초기 MVP를 아주 빠르게 만드는 데는 장점이 있다. 하지만 이번 프로젝트는 단순 문서 정리가 아니라, 입실자 정보와 월세 상태를 지속적으로 관리하는 운영 시스템에 가깝다. 결국 Google Drive 방식의 단점을 Supabase 기반 구조가 대부분 보완할 수 있다고 판단했다. 그래서 최종적으로는 Next.js + Supabase 방향이 더 적합하다고 결론 내렸다.

 

첫 개발 진행

현재 고시원 프로젝트는 다음과 같이 화면이 구성되어 있다. 데이터는 가짜 데이터다.

1. 대시보드 화면 → 도면을 통해 한 번에 볼 수 있는 페이지

 

2. 입실자 관리인 장부 리스트

 

 

간단한 화면을 만든 뒤, 사장님과 다시 요구사항을 맞췄다

원장님께 들었던 요구사항을 바탕으로, 우선은 큰 흐름을 확인할 수 있는 화면을 간단하게 만들어보았다. 핵심은 처음 정리했던 두 가지였다.

• 도면을 기반으로 현재 방 상태를 한눈에 볼 수 있는 대시보드
• 입실자 정보와 월세 납부 현황을 관리할 수 있는 장부 리스트

 

이 두 방향으로 화면을 구성한 뒤, 다음 미팅에서는 처음 만났던 원장님이 아니라 실제 운영을 총괄하시는 사장님께 직접 보여드리게 되었다. 여기서 흥미로웠던 점은, 같은 “고시원 관리 프로그램”을 이야기하더라도 원장님과 사장님이 중요하게 보는 지점이 조금 달랐다는 것이다.

 

원장님은 현재 운영 상태를 확인하고 관리하는 실무적인 화면을 중요하게 보셨다면, 사장님은 여기에 더해 시간의 흐름에 따라 각 방의 운영

현황을 볼 수 있는 기능을 원하셨다.

 

즉, 단순히 “지금 누가 어느 방에 살고 있는가”를 넘어서, 연 단위로 각 호실의 입실 현황을 시각적으로 보고 싶다는 요구가 추가된 것이다.

 

 

사장님이 추가로 말씀하신 요구사항

사장님이 새롭게 말씀하신 요구사항은 크게 세 가지로 정리할 수 있었다.

 

 

1. 연 단위 호실 현황을 막대 그래프로 보고 싶다

가장 핵심적인 추가 요구사항은 각 호실의 입실 현황을 연별 막대 그래프 형태로 시각화하는 기능이었다. 예를 들어, 현재 날짜가 3월 20일이라면 그래프도 3월 20일까지의 상태가 반영되어 있어야 한다. 그리고 각 방에 대해 입실 시작일과 종료일이 기간 형태로 보이면 좋겠다고 하셨다.

 

즉, 이 화면은 단순 리스트가 아니라 다음과 같은 정보를 함께 보여주는 형태를 의도하고 있었다.

• 각 호실별 거주 기간
• 입실 시작일과 종료일
• 현재 어느 기간까지 운영 현황이 채워져 있는지
• 방별 월세 정보
• 입실자의 이름
• 입실자의 나이

 

결국 이 요구사항은 “현재 상태 조회”보다 한 단계 더 나아가서, 시간 축 위에서 방의 사용 현황을 보는 화면에 가까웠다.

 

2. 캘린더는 1월 1일부터 시작하는 연 단위 구조가 필요하다

사장님은 캘린더도 월 단위가 아니라 연 단위 기준으로 보고 싶다고 하셨다. 즉, 특정 달만 보는 방식보다는 1월 1일부터 시작해서 한 해 전체 흐름 안에서 각 방의 사용 현황을 파악할 수 있는 구조가 필요하다는 의미였다.

 

이 요구사항을 듣고 나서, 처음 생각했던 단순 대시보드와는 조금 다른 성격의 화면이 필요하다는 점이 분명해졌다. 운영자 입장에서는 단순히 오늘의 상태만 보는 것이 아니라, 올해 전체 기준으로 어떤 방이 언제 사용 중이고 언제 비는지 흐름을 보고 싶었던 것이다.

 

3. 층별 필터링이 가능해야 한다

고시원은 1층부터 여러 층으로 구성되어 있기 때문에, 전체를 한 번에 보는 것만으로는 오히려 복잡할 수 있다. 그래서 사장님은 1층, 2층, 3층, 4층처럼 층별로 필터링해서 볼 수 있는 기능도 필요하다고 말씀하셨다.

이 요구사항은 생각보다 중요했다. 방 수가 늘어날수록 한 화면에 모든 호실을 다 보여주는 방식은 가독성이 떨어질 수 있기 때문이다. 층별 필터가 있으면 필요한 정보만 빠르게 좁혀서 볼 수 있고, 실제 운영에서도 훨씬 실용적이다.

 

요구사항이 조금 더 명확해졌다

처음 원장님과 이야기했을 때는 이 프로젝트가 “현재 상태를 확인하는 관리 도구”에 가까워 보였다. 하지만 사장님과 이야기를 나누고 나니, 이 서비스는 단순 조회를 넘어서 운영 흐름을 시각적으로 파악할 수 있는 도구가 되어야 한다는 점이 드러났다.

 

정리하면 요구사항은 기존의 두 화면에서 한 단계 더 확장되었다.

기존에는

• 현재 방 상태를 보는 대시보드
• 입실자와 월세 납부 상태를 보는 장부 리스트

가 핵심이었다면, 사장님과의 미팅 이후에는 여기에 더해

• 연 단위로 각 호실의 사용 현황을 볼 수 있는 캘린더/타임라인형 화면
• 입실 기간을 막대 그래프로 보여주는 시각화
• 층별 필터링 기능

까지 필요하다는 것이 분명해졌다.

 

이번 미팅을 통해 느낀 점

이번 미팅에서 느낀 점은, 처음 요구사항을 들었을 때 바로 구현에 들어가는 것보다 간단한 화면이라도 먼저 만들어서 보여드리는 과정이 정말 중요하다는 것이었다.

 

말로만 들을 때는 “방 상태 관리 프로그램”처럼 보였던 요구사항이, 실제로 화면을 보면서 이야기를 나누니 “연간 호실 운영 현황을 시각적으로 보고 싶다”는 더 구체적인 니즈로 드러났기 때문이다.

 

결국 요구사항은 문서에서 완성되는 것이 아니라, 화면을 함께 보면서 점점 선명해진다는 것을 다시 느꼈다.