복잡한 견적 툴 대신, 도면 실측에 집중한 Room Planner 토이프로젝트를 만든 이유

이번 토이프로젝트는 "무엇을 더 넣을까"보다 "무엇을 덜어낼까"에서 시작한 작업이었다.
평소 도면 관련 작업을 하다 보면 아키스케치처럼 이미 잘 만들어진 서비스들이 많다. 다만 이런 서비스들은 대체로 견적, 인테리어 제안, 자재 선택, 3D 시각화, 고객 커뮤니케이션까지 넓은 흐름을 함께 다룬다. 실제로 현업이나 상용 서비스 관점에서는 당연히 필요한 기능들이다.

그런데 내가 필요했던 것은 훨씬 단순했다.
방 크기를 빠르게 입력하고, 문 위치를 표시하고, 평면 형태로 정리해서 결과 이미지를 확인하는 정도면 충분했다. 다시 말해 "견적 플랫폼"이 아니라 "도면 실측 정리 도구"가 필요했던 것이다.

이 글에서는 Room Planner를 왜 만들게 되었는지, 그리고 처음부터 어떤 범위로 문제를 정의했는지를 회고 형태로 정리해보려고 한다.

1. 왜 새로 만들었나

[ 문제는 기능 부족이 아니라 기능 과잉이었다 ]

처음에는 기존 서비스를 그대로 써도 되지 않을까 생각했다.
하지만 실제로 써보면 필요한 작업보다 먼저 만나게 되는 것이 너무 많았다.

프로젝트 생성과 분류
견적 항목 관리
여러 단계의 설정
시각화 중심 UI
내가 당장 필요하지 않은 부가 정보

물론 이런 기능은 서비스 완성도를 높여준다. 다만 단순히 실측값을 정리하고 방 배치를 확인하려는 입장에서는 오히려 진입 비용이 된다.

예를 들어, 내가 하고 싶은 일은 아래 정도였다.

집 단위를 하나 만든다.
그 안에 도면을 만든다.
방 이름과 가로, 세로, 높이, 문 위치를 넣는다.
화면에서 방을 배치해본다.
결과를 이미지로 저장한다.

이 다섯 단계만 매끄럽게 돌아가도 목적은 충분히 달성된다.
결국 이 프로젝트는 "기능을 늘리는 개발"이 아니라 "핵심 작업만 남기는 개발"에 가까웠다.

[ 내가 원한 것은 측정 중심 워크플로우였다 ]

Room Planner의 전체 흐름은 실제 코드에서도 꽤 단순하게 잡혀 있다.

집 선택 -> 도면 선택 -> 방 측정 -> 평면 편집 -> 결과 보기

이 구조가 중요한 이유는 사용자가 지금 무엇을 해야 하는지 헷갈리지 않기 때문이다.
처음 들어오면 집을 고르고, 그 다음엔 도면을 고르고, 그 다음엔 실측값을 넣는다. 이후에야 배치와 출력이 등장한다.

즉, 편집 도구를 만들었지만 시작점은 어디까지나 "입력"이었다.
이 프로젝트는 캔버스 드래그 경험보다도, 실측값을 얼마나 빠르게 정리할 수 있느냐를 더 중요하게 둔 셈이다.

2. 어떤 범위까지 만들기로 했나

[ 토이프로젝트일수록 범위를 먼저 잘라야 했다 ]

처음부터 모든 것을 넣기 시작하면, 작은 프로젝트도 금방 무거워진다.
그래서 이번 작업에서는 일부러 아래 범위만 우선 구현 대상으로 잡았다.

집 단위 워크스페이스
도면 단위 작업 분리
방 실측값 입력
문 위치와 스윙 방향 설정
방 배치 편집
결과 이미지 출력

반대로 일부러 넣지 않은 것들도 있다.

인테리어 견적 계산
가구 배치 시뮬레이션
3D 뷰
협업 기능
고급 CAD 수준의 정밀 편집

여기서 중요한 점은 "못 해서 뺀 것"이 아니라 "지금 문제를 푸는 데 필요 없어서 뺀 것"이라는 점이다.
토이프로젝트에서는 이 구분이 생각보다 중요하다. 기능을 줄이면 초라해 보일 수 있지만, 실제로는 문제 정의가 더 또렷해진다.

[ 데이터 단위도 의도적으로 단순화했다 ]

이번 프로젝트는 "집"과 "도면"을 분리했다.
이 구조는 언뜻 보면 당연해 보이지만, 실제로는 작업 단위를 나누는 기준이 된다.

home: 작업 묶음
floorplan: 실제 편집 대상

이렇게 나누면 한 집 아래에 여러 도면을 둘 수 있다.
예를 들어 같은 집 안에서 기본 구조안, 수정안, 비교안 같은 흐름도 자연스럽게 만들 수 있다.

또 방 입력도 복잡한 객체 모델보다 실측 중심으로 풀었다.

방 이름
방 종류
가로 / 세로 / 높이
문이 붙는 벽
문 시작 위치 기준
문 폭
문 열림 방향

결국 "방 하나를 측정해서 기록한다"는 현실 작업 흐름을 그대로 데이터 구조에 옮기려고 했다.

3. 만들면서 특히 중요했던 기준

[ 즉시 보이는 피드백 ]

실측 도구에서 가장 답답한 순간은 입력한 값이 어떤 모양인지 바로 확인되지 않을 때이다.
그래서 이 프로젝트에서는 실측값을 입력하면 우측 미리보기에 바로 반영되도록 구성했다.

이 접근은 단순해 보이지만 체감 차이가 크다.

숫자를 입력했을 때 비율이 맞는지 바로 확인할 수 있다.
문 위치가 벽 밖으로 나가지 않았는지 빠르게 판단할 수 있다.
입력 단계와 결과 단계의 간극이 줄어든다.

즉, 폼과 도면 미리보기를 분리하지 않고 한 흐름으로 묶는 것이 중요했다.

[ 결과물을 남길 수 있어야 했다 ]

실측 정리는 결국 다른 사람과 공유하거나 나중에 다시 보는 일이 많다.
그래서 최종 결과 화면에서는 단순히 편집 상태를 보여주는 것이 아니라, 출력용 평면도처럼 정리된 화면을 따로 만들었다.

이 프로젝트에는 두 가지 결과 모드가 있다.

치수 요약 표시 모드
클린 출력 모드

전자는 내부 확인용에 가깝고, 후자는 좀 더 깔끔한 이미지 공유에 적합하다.
즉, 같은 데이터라도 "편집 화면"과 "전달용 결과물"은 다르게 보여주는 것이 필요했다.

[ 저장은 사용자가 의식하지 않도록 ]

도면 정리 작업은 생각보다 자주 수정이 발생한다.
그래서 저장 버튼을 계속 누르게 만들기보다 자동 저장 흐름을 두는 편이 더 자연스러웠다.

이 부분은 사용성 측면에서도 중요하지만, 토이프로젝트답게 구현 부담과 효과의 균형도 좋았다.
사용자는 편집에 집중하고, 시스템은 일정 시간 간격으로 문서를 저장한다. 이 단순한 구조만으로도 작업감이 꽤 좋아졌다.

4. 이번 프로젝트에서 얻은 생각

[ 작아도 목적이 분명하면 도구가 된다 ]

이번 프로젝트를 만들면서 가장 크게 느낀 점은, 작은 기능 묶음도 사용 목적이 분명하면 충분히 유용한 도구가 된다는 점이었다.

기존 서비스와 비교하면 Room Planner는 분명히 단순하다.
하지만 단순하다는 것이 곧 부족하다는 뜻은 아니다. 오히려 내가 실제로 자주 반복하는 작업만 남겼기 때문에, 더 빠르고 덜 피곤하게 느껴지는 면이 있었다.

[ 토이프로젝트에서도 사용자 관점이 중요했다 ]

개발할 때는 종종 "기술적으로 구현 가능한가"에 먼저 시선이 간다.
하지만 이번에는 "실제로 내가 다시 쓸 것인가"를 더 자주 기준으로 삼았다.

그 기준으로 보면 아래 질문들이 계속 중요해졌다.

첫 화면에서 무엇을 해야 하는지 바로 이해되는가
방을 입력할 때 헷갈리는 값이 없는가
편집 화면이 지나치게 복잡하지 않은가
최종 결과를 바로 저장할 수 있는가

결국 이 프로젝트는 새로운 기술 실험이라기보다, 불필요한 기능을 덜어내는 연습에 더 가까웠다.

5. 정리

정리하면, Room Planner를 만든 계기는 기존 견적/인테리어 서비스가 부족해서가 아니라, 내 사용 목적에 비해 너무 넓고 복잡했기 때문이다.
필요했던 것은 견적 전체 흐름이 아니라, 방 실측과 간단한 평면 정리였다.

그래서 이번 토이프로젝트는 처음부터 범위를 좁게 잡았다.
집과 도면을 분리하고, 방 실측 입력과 배치 편집, 결과 출력까지의 짧은 흐름만 남겼다. 이 선택 덕분에 프로젝트의 성격도 분명해졌다.

결국 중요한 것은 기능 개수가 아니라, 어떤 문제를 얼마나 덜 복잡하게 해결하느냐이다.
다음 글에서는 이 흐름을 실제 코드에서 어떻게 풀었는지, 상태 관리와 렌더링 구조를 중심으로 정리해보려고 한다.

1. Room Planner