개요

회사에서 AI 활용법을 공부하고 실무에 적용해 온 경험을 바탕으로, 웹과 앱(iOS·Android) 서비스를 혼자 만들고 있습니다. 청약 공고를 한곳에서 찾고, 공고 속 도면을 3D로 둘러볼 수 있는 주거 서비스 "집보다"입니다.

집보다 개발기는 총 3편으로 연재합니다. 기획부터 디자인, 개발까지의 과정과 시행착오를 그대로 정리해, 자신의 서비스를 만들고 싶은 분들이 참고할 수 있도록 작성했습니다. 1편에서는 서비스를 기획한 과정과, 디자이너 없이 AI로 디자인과 디자인 시스템을 만든 방법을 다룹니다.

이 글을 읽고 나면 다음을 할 수 있습니다.
- 서비스 주제를 고를 때 도메인 지식을 기준으로 삼는다.
- 디자이너 없이 AI로 와이어프레임과 디자인 시안을 만든다.
- 웹과 앱이 함께 쓰는 디자인 시스템을 패키지로 구성한다.

왜 도메인 지식에서 시작했나

AI 덕분에 이제는 누구나 서비스를 만들 수 있습니다. 그만큼 "어떻게 만들까"보다 "무엇을 만들까"가 더 중요해졌습니다. 그래서 서비스를 구상할 때 가장 먼저 고려한 것은 기술이 아니라 도메인 지식이었습니다.

도메인 지식이 중요한 이유
AI는 코드를 빠르게 작성하지만, 사용자가 어디서 불편을 느끼는지는 알려 주지 않습니다. 무엇을 만들지 정하는 기준은 결국 그 분야를 직접 겪어 본 사람의 경험에서 나옵니다.

제가 가장 관심이 많고 잘 아는 분야는 "집"이었습니다. 본가가 재개발을 겪는 과정을 가까이에서 지켜봤고, 지금은 전세금을 돌려받지 못하고 있는 상황이라 자연스럽게 청약에 관심을 갖게 되었습니다. 평소 부동산 시장을 꾸준히 지켜봐 온 것도 도움이 되었습니다. 세 가지 경험이 모두 주거로 이어졌기 때문에, 서비스의 주제도 주거로 정했습니다.

문제 정의: 청약 정보는 왜 찾기 어려울까

공공 청약 공고는 LH(한국토지주택공사), SH(서울주택도시공사), IH(인천도시공사), GH(경기주택도시공사)처럼 기관마다 각자의 사이트에서 제공됩니다. 부동산 앱에서는 지도에서 매물을 찾고 사진과 평면도로 집을 비교하는 경험이 익숙하지만, 청약 공고를 그렇게 편리하게 볼 수 있는 서비스는 찾기 어려웠습니다.

- 공고가 기관별 사이트에 흩어져 있어 한곳에서 비교하기 어렵다.
- 공고문과 도면이 PDF 중심이라 필요한 정보를 찾으려면 문서를 직접 읽어야 한다.
- 도면만으로는 실제 집의 크기와 구조를 떠올리기 어렵다.

아이디어: 도면을 읽는 대신 걸어 보게

여기에 회사 경험이 더해졌습니다. 회사에서 R&D로 진행한 프로젝트 중에 모델러분들의 작업을 바탕으로 구축한 WebGL 서비스가 있었습니다. 그 경험을 떠올리며 이런 생각을 했습니다. "공고만 보여 주는 대신, 공고의 도면을 AI의 도움을 받아 3D 모델로 만들고, 그 집 안을 1인칭으로 걸어 다닐 수 있게 하면 어떨까?"

워크스루(Walkthrough)란?
사용자가 1인칭 시점으로 3D 공간 안을 직접 걸어 다니며 둘러보는 기능입니다. 도면에서 본 집을 실제로 걷는 것처럼 경험할 수 있어, 평면도를 읽는 데 익숙하지 않은 사람도 집의 구조를 쉽게 이해할 수 있습니다.

실제로 구현한 1인칭 집구경 화면은 아래 "지금까지 만든 웹"에서 확인할 수 있고, 이 아이디어를 기능으로 만든 과정은 2편에서 자세히 다룹니다.

서비스 구성 정하기

코드를 작성하기 전에 요구사항정의서, 화면설계서, API 및 인터페이스 정의서를 먼저 만들었습니다. 이 문서들은 이후 AI에게 작업을 맡길 때 기준이 되는 자료가 되었습니다. 그다음 서비스를 저장소 단위로 나눴습니다.

- zipboda-web: 사용자용 웹 (Next.js)
- zipboda-admin: 청약 공고와 콘텐츠를 관리하는 관리자 웹 (Next.js)
- zipboda-app: iOS·Android 앱 (Expo, React Native)
- zipboda-api: 백엔드 API (설계 단계)
- zipboda-design-system: 세 서비스가 함께 쓰는 디자인 시스템

기획한 주요 기능은 청약 공고 통합 검색과 마감 알림, 청약 가점 계산, 3D 평면도와 1인칭 집구경, 가구 쇼핑, 커뮤니티입니다. 현재는 웹을 중심으로 개발하고 있고, 관리자와 앱은 기본 구성만 갖춘 상태입니다.

가장 부족했던 것, 디자인

기획, 백엔드, 프론트엔드는 실무에서 경험해 본 영역이었지만, 저에게 가장 부족한 것은 디자인이었습니다. 처음에는 Claude나 Codex에게 화면 디자인을 바로 요청해 봤습니다. 결과는 기능은 갖췄지만 투박하고, 한눈에 "AI가 만든 것 같은" UI였습니다.

돌아보면 화면의 구조와 시각적인 스타일을 한 번에 맡긴 것이 원인이었습니다. 그래서 디자인을 단계별로 나누고, 각 단계에 맞는 도구를 사용했습니다.

1. Claude와 Figma MCP로 와이어프레임 잡기

먼저 화면설계서를 바탕으로 Claude가 Figma MCP를 통해 Figma에 와이어프레임을 직접 그리게 했습니다. 프로젝트에는 Figma 데이터를 읽는 MCP와 Figma에 직접 그리는 MCP를 함께 연결해 두었습니다. 이 단계에서는 화면에 무엇이 어디에 들어가는지만 정합니다.

1// 와이어프레임 요청 예시
2
3"화면설계서의 '청약 목록' 화면을 Figma에 와이어프레임으로 그려 줘.
4- 1280px 데스크톱 기준
5- 구성: 상단 내비게이션, 검색과 필터, 공고 카드 목록, 지도 영역
6- 회색 박스와 기본 텍스트만 사용하고 색상, 아이콘, 그림자는 넣지 마."

와이어프레임 단계에서는 색과 스타일을 넣지 않습니다. 구조와 스타일을 함께 다루면 다시 "AI가 만든 것 같은" 화면으로 돌아갑니다.

2. Figma Make에 톤앤매너만 전달하기

와이어프레임으로 구조가 정해지면 Figma의 AI 디자인 도구인 Figma Make로 시각 디자인을 만들었습니다. 이때 구조는 다시 설명하지 않고, 서비스가 주어야 할 분위기인 톤앤매너만 전달했습니다.

톤앤매너란?
서비스가 주는 분위기와 인상을 말합니다. 색감, 여백, 모서리, 글꼴의 느낌 같은 시각적 방향을 몇 가지 키워드로 정리한 것입니다.

1// 톤앤매너 전달 예시
2
3"첨부한 와이어프레임의 구조는 그대로 유지하고 시각 디자인만 만들어 줘.
4- 따뜻하고 신뢰감 있는 주거 서비스
5- 부동산 앱처럼 정보가 한눈에 들어오는 화면
6- 카드 중심 레이아웃, 넉넉한 여백, 부드러운 모서리"

구조를 고정한 상태에서 톤앤매너만 전달하니, AI에게 한 번에 맡겼을 때보다 훨씬 서비스다운 디자인이 나왔습니다.

3. Figma MCP로 디자인을 코드로 옮기기

완성된 디자인은 다시 Figma MCP로 읽어 화면을 구현했습니다. Figma MCP는 디자인의 색, 간격, 크기 같은 값을 node 단위 데이터로 전달합니다. 다만 AI는 디자인에 없는 요소를 임의로 채워 넣는 경향이 있어, 이를 막기 위해 Figma 구현 규칙을 따로 만들었습니다.

1// .claude/rules/figma-implementation.rule.md 중 일부
2
3D1 디자인 이탈 금지: 색·타이포·간격·크기·레이아웃을 Figma node 데이터 그대로 반영한다
4D2 임의 판단·창작 금지: 디자인에 없는 값·요소·문구·아이콘을 추측하거나 추가하지 않는다
5D3 디자인 토큰 우선: 임의 hex·px 하드코딩 대신 프로젝트 디자인 토큰을 사용한다
6D5 추적성 유지: 구현한 컴포넌트에 출처 node-id를 남긴다 (예: // figma: 23:15)

이 규칙은 항상 읽히지 않습니다. CLAUDE.md에 "Figma node-id로 UI 컴포넌트/화면 구현"처럼 상황별로 읽을 규칙 파일을 표로 정리해 두고, 해당 작업을 할 때만 그 파일을 열도록 했습니다. 웹 저장소에는 이런 규칙이 11개 있으며, 필요한 규칙만 읽기 때문에 토큰도 절약할 수 있습니다.

디자인 시스템: 웹, 관리자, 앱이 함께 쓰는 기준

혼자 여러 저장소를 다루다 보면 화면마다 색과 간격이 조금씩 달라집니다. 그래서 Figma 디자인에서 공통 요소를 추려, 사용자용 웹과 관리자, 앱이 함께 쓰는 디자인 시스템을 별도 저장소로 만들었습니다.

디자인 시스템은 세 개의 패키지로 나눴습니다.

- @zipboda/tokens: 색, 간격, 모서리, 글꼴 같은 디자인 토큰. JSON으로 정의하고 CSS 변수, TypeScript 상수, Tailwind 프리셋으로 변환
- @zipboda/ui-core: 플랫폼과 무관한 공통 로직. 컴포넌트 타입, 배리언트별 토큰 매핑, 클래스 조합 함수
- @zipboda/ui: 웹용 React 컴포넌트 15종 (Button, Badge, Chip, Input, Modal 등)

이렇게 나눈 이유는 앱 때문입니다. 웹과 관리자는 세 패키지를 모두 사용하지만, React Native 앱은 웹용 컴포넌트를 그대로 쓸 수 없습니다. 그래서 앱은 tokens와 ui-core만 가져와 같은 토큰과 같은 클래스 규칙으로 자체 컴포넌트를 만듭니다. 플랫폼이 달라도 디자인의 기준은 하나로 유지됩니다.

아래는 실제 디자인 시스템에 정의된 색, 글꼴, 컴포넌트입니다. @zipboda/ui 컴포넌트와 토큰 프리셋으로 직접 렌더링했습니다.

각 컴포넌트에는 출처가 된 Figma node-id를 주석으로 남기고, 스타일은 ui-core의 클래스 조합 함수로 만듭니다. 디자인이 바뀌면 어떤 컴포넌트를 고쳐야 하는지 바로 찾을 수 있고, 앱도 같은 함수를 쓰도록 구성해 웹과 앱의 스타일이 함께 바뀝니다.

1import React from "react";
2import { badgeClasses, cx, type BadgeVariant } from "@zipboda/ui-core";
3
4export interface BadgeProps extends React.HTMLAttributes<HTMLSpanElement> {
5  variant?: BadgeVariant;
6}
7
8/** Badge — figma `20:136` (디자인시스템 §12) */
9export const Badge = React.forwardRef<HTMLSpanElement, BadgeProps>(function Badge(
10  { variant = "neutral", className, children, ...rest },
11  ref
12) {
13  return (
14    <span ref={ref} className={cx(badgeClasses(variant), className)} {...rest}>
15      {children}
16    </span>
17  );
18});

패키지는 Changesets로 버전을 관리합니다. 변경 사항을 기록해 main에 올리면 GitHub Actions가 빌드와 타입 검사를 거쳐 버전 업데이트 PR을 만들고, 이를 머지하면 GitHub Packages에 배포됩니다.

디자인 시스템을 비공개 레지스트리에 배포하면, 패키지를 설치하는 저장소마다 레지스트리 인증 설정(.npmrc와 토큰)이 필요합니다. 저장소를 처음 구성할 때 함께 준비해 두는 것이 좋습니다.

지금까지 만든 웹

웹은 Next.js 14(App Router), React, TypeScript, Tailwind CSS로 구축했습니다. Tailwind에는 디자인 시스템의 토큰 프리셋을 연결해, 화면에서도 같은 토큰을 사용합니다. 현재 홈, 청약 목록과 상세, 가점 계산기, 3D 집구경, 커뮤니티, 쇼핑, 마이페이지 등 21개 화면을 만들었습니다.

청약 목록은 지도 중심으로 구성했습니다. 카카오 지도 위에 공고를 지역별로 묶어 보여 주고, 지역, 기관, 면적, 모집 상태로 필터링할 수 있습니다.

공고 상세 화면에서는 공고 정보와 위치, 그리고 평형별 2D 평면도를 함께 보여 줍니다. 여기서 3D 보기와 1인칭 집구경으로 바로 이어집니다.

1인칭 집구경을 켜면 도면 속 집 안으로 들어가 직접 걸어 다닐 수 있습니다. 데스크톱에서는 마우스로 시선을 돌리고 WASD 키로 이동하며, 모바일에서는 화면의 조이스틱으로 이동합니다. 오른쪽 위의 미니 도면에서 지금 서 있는 위치를 확인할 수 있습니다.

청약 가점 계산기는 무주택 기간, 부양가족 수, 청약통장 가입 기간을 입력하면 가점을 계산하고, 신청할 수 있는 공고를 함께 보여 줍니다.

아직 실제 API는 연결하지 않았습니다. 공고 정보는 LH·SH 공고를 직접 정리한 데이터로, 나머지 영역은 목 데이터로 화면을 먼저 완성하고 있습니다.

혼자 서비스를 만들며 얻은 것

기획부터 웹 구현까지 진행하면서, 서비스를 만들고 싶은 분들께 공유하고 싶은 네 가지를 정리했습니다.

잘 아는 분야에서 시작합니다. 직접 겪은 불편함이 있으면 문제를 정의하기 쉽고, 기능의 우선순위도 분명해집니다. AI가 대신해 줄 수 없는 부분이 바로 이 도메인 지식입니다.

문서를 먼저 만듭니다. 요구사항정의서, 화면설계서, API 정의서가 있으면 AI에게 같은 설명을 반복하지 않아도 됩니다. 문서가 곧 AI에게 주는 기준이 됩니다.

AI에게 맡길 일을 나눕니다. 구조는 와이어프레임으로, 분위기는 톤앤매너로, 구현은 규칙과 함께 맡깁니다. 한 번에 모든 것을 맡길수록 결과는 평범해집니다.

결정은 기록으로 남깁니다. 진행 중에 바뀐 결정은 질문과 답변 형식의 문서로 남겼습니다. 예를 들어 청약 목록을 지도 중심으로 다시 설계하기로 한 결정도 기록되어 있어, 다음 작업에서 AI와 제가 같은 맥락을 공유할 수 있습니다.

마무리

1편에서는 도메인 지식에서 출발해 서비스를 기획하고, 디자이너 없이 AI로 디자인과 디자인 시스템을 만든 과정을 정리했습니다. 2편에서는 집보다의 핵심 기능인 3D 집구경, 공고 속 도면을 실제로 걸어 볼 수 있는 집으로 만든 과정을 다룹니다.

핵심 정리
- AI로 누구나 서비스를 만들 수 있는 시대에는 무엇을 만들지 정하는 도메인 지식이 경쟁력이다.
- 디자인은 와이어프레임(구조), 톤앤매너(분위기), 구현(규칙)으로 나눠 AI에게 맡긴다.
- AI가 디자인을 임의로 바꾸지 않도록 Figma 구현 규칙을 만들고, 필요할 때만 읽게 한다.
- 디자인 시스템은 토큰, 플랫폼 공통 로직, 웹 컴포넌트로 나눠 웹과 앱이 같은 기준을 쓰게 한다.
- 코드보다 문서를 먼저 만들고, 바뀐 결정은 기록으로 남긴다.