02. #바이브코딩 으로 앱 만들기 - 실제 코딩 진행

2025.10.30-01. #바이브코딩 으로 앱 만들기 - 과연 가능할까?

01. #바이브코딩 으로 앱 만들기 - 과연 가능할까?

위의 글 이어서 실제 Renthouse 프로젝트의 바이브코딩 진행 과정 과 내용을 공유합니다.

바이브코딩이 어느정도 프로토타입 개발 경험을 바탕으로 가능한 것을 알았으니, 정말 시제품을 만들고 싶었습니다. 사실 이 RentHouse 아이디어는 개인적으로도 필요하기도 해서 구상하고 있던 프로그램이기 때문에, 출시 이후에도 지속적으로 업그레이드도 할 것 같기도 하고, 어느정도 금액이 나오면 좀더 나은 서비스를 제공할 계획도 있습니다. 나만 쓰더라도 좀 편하게 사용이 안될까.. 하며 아이디어가 계속 나오더라고요.

여하튼, 프로토타입 때, Gemini-flash 가 만든 코드를 경험 했기 때문에, (물론 생각보다 만족스러웠지만, 의외로 만족스럽지 않은 부분도 많았습니다.) 이번에는, 유료이지만 Claude Code를 선택했습니다. 결론부터 말씀 드리자면, 3개월 정도 진행 하였고, 현재 출시까지 원하는 기능 중 1개 제외하고 모두 구현되어 있습니다. 

우선, 많은 개발자분들이 클로드코드가 코딩에 최적화되어 있다고 평가했기 때문입니다. 또한 이번에는 제가 중간에 개입하지 않는 것을 목표로 했습니다. 100% 바이브 코딩으로 진행 하였습니다. 음.. 그러기 위해서.. 제가 이미 잘 아는 언어 대신, 아예 모르는 언어를 선택하였습니다.

멀티플랫폼도 지원해야 한다는 점 때문에, 많은 개발자분들께서 추천하는 Flutter 를 선택하게 되었습니다. Flutter 는 이미 여러번의 버전업을 거치면서 상당히 안정화되었고, 고품질의 결과물을 낼 수 있으며, 또한 개발하기도 편리하다는 평가를 많이 접하게 되었습니다. 또한 실제로 YouTube에서도 최신 Flutter 버전이 충분히 실무에 활용 가능하다며 여러 적용 사례들도 확인할 수 있었고요.
그래서 최종적으로, 이번 프로젝트는 Flutter로 진행하기로 결정했습니다.

프로토타입을 통한 요구사항 만들기 

우선 프로토타입을 전달하여 PRD (제품 요구사항 정의서) 를 만들기로 했습니다. LLM 과 UI 가 뛰어난 ChatGPT 를 활용하였습니다.

 

다음은 ChatGPT 에게 전달받은 개발 검토 및 개선 제안입니다. 4-5번의 수정을 거쳐서 만들어진 내용입니다. 물론 다음과 같이 만들어진 이후, 꽤 많은 수정 작업을 거쳐서 내용에 없는 기능이 추가되었거나, 만들었지만 빠진 내용도 있습니다. 초기에 ai (ChatGPT) 가 검토한 개발 검토 보고서를 공유합니다. 

# RentHouse 1차 개발 검토 & 개선 제안 (건물주 중심 관점 · v2) _작성: 2025-09-09_

## 1) 핵심 사용자(Target)
- **건물주/소규모 임대사업자(Owner/Landlord)** — 10~30 유닛 규모
- 반복 업무(계약·청구·수납·보고서) 자동화와 한눈 현황 파악이 최우선

## 2) 현황 요약
- 구현: 자산/유닛, 임차인, 계약, **청구 관리**, 대시보드, 로컬 DB(Drift)  
- 남은 핵심: **수익관리(수납/영수증/보고서 심화)**, RBAC, 작업주문(유지보수), 설정, 품질/테스트  
- 참고: 1단계 리포트의 기능 요약(로그인/자산/임차인/계약/청구, M3/반응형/라우팅/Drift/대시보드)  
  → 세부 근거는 문서 하단 “참고/근거” 섹션 참조.

---

## 3) 건물주 관점 주요 니즈(요약)
1. **수익/현황을 한눈에** — 월세 수입, 미납, 공실
2. **청구→수납→영수증** 자동화
3. **문서·증빙(PDF)** — 계약서·영수증·점검표 (※ 법적 증빙은 후순위)
4. **유지보수 요청 추적** — 요청→할당→처리→완료
5. **권한 위임(RBAC)** — 관리인/회계사에 제한 권한

---

## 4) “원래 계획된 파일 3개”와 가치 연결(요약)
- **임대차 계약서 PDF** — 법적 관계 증빙 (후순위)
- **월별 수익·임차인 현황 보고서 PDF** — 경영 지표
- **입주/퇴실 체크리스트 PDF** — 시설 상태·분쟁 예방

---

## 5) 우선 강화: 수익관리(Revenue Management) — **상세 설계**

### 5.1 데이터 모델(최소 확장)
- `Billing(id, lease_id, yearMonth, issueDate, dueDate, totalAmount, status)`  
  - `status`: `DRAFT | ISSUED | PARTIALLY_PAID | PAID | OVERDUE | VOID`
- `BillingItem(id, billing_id, name, category, quantity, unitPrice, tax, amount, memo)`
- **신규** `Payment(id, tenant_id, method, amount, paidDate, reference, memo)`
  - `method`: `CASH | TRANSFER | CARD | ETC`
- **신규** `PaymentAllocation(id, payment_id, billing_id, amount)`  
  - 부분 수납/여러 청구서에 배분 가능
- **선택** `Adjustment(id, billing_id, type, amount, reason)`  
  - `type`: `DISCOUNT | WRITE_OFF | LATE_FEE | ADJUST_UP/DOWN`
- **선택** `Receipt(id, payment_id, number, pdfUrl/hash)` — 영수증 메타

> **중복 청구 방지**: `(lease_id, yearMonth)` 유니크 인덱스

### 5.2 워크플로우
1) **월초 자동 청구 생성**  
   - 트리거: 사용자가 “청구 생성” 실행(로컬 앱은 상시 백그라운드가 없으므로 _수동/반자동_ 버튼 우선)  
   - 규칙: 계약기간 내 유효한 Lease에 대해 1건씩 생성, 기존 존재 시 스킵  
   - 프레이밍: 보증금·월세·관리비·유틸리티 항목 템플릿 적용
2) **수납(Payment) 등록**  
   - 금액 입력 → **자동 배분**(가장 오래된 미납부터) 또는 수동 배분  
   - 결과: Billing 상태 전이(예: `ISSUED→PARTIALLY_PAID→PAID`)
3) **영수증 발행(PDF)**  
   - Payment 기준 단일/복수 Billing 배분 내역 포함  
   - 고유 번호/일자/금액/납부방법/임차인/세부배분/발행자
4) **연체/가산금(선택)**  
   - `dueDate`+X일 초과 시 `LATE_FEE` Adjustment 추가(비율/정액)  
   - 미납 Aging 산출(0–30/31–60/61–90/90+ 일)
5) **정산/환불**  
   - 초과 입금은 `Credit`(양수 조정) 또는 다음달 상계  
   - 환불은 음수 Payment(또는 별도 Refund)로 기록

### 5.3 계산/검증 규칙
- 금액 단위: **KRW 정수(원)** — 반올림 없는 합산(세금도 원 단위)  
- **일할 계산(Proration)**: 중도 입주/퇴실 시 `월세 × (사용일/월일수)`  
- 증감: **임대료 인상분**이 월 중 발생 시 이월 분리 또는 일할  
- Deposit 전용: 별도 계정으로 관리, 임대료 상계는 명시적 전표(Adjustment)로 처리  
- 데이터 제약: Payment ≤ 미납 합계(단, 크레딧 허용 시 초과 가능)

### 5.4 UI/UX 사양
- **대시보드 KPI**:  
  - 이번 달 _청구/수납/미납_, 공실 수, 연체 비중  
- **청구 리스트**: 상태 배지, 연체 필터, 합계/미납 합계, **대량 선택→대량 발행**  
- **수납 화면**: 자동배분 미리보기, 수동배분 Drag-to-allocate(데스크톱), 빠른 입력(숫자패드)  
- **영수증 PDF**: 로고/사업자 정보/발행자, 항목·배분 테이블, 하단 바코드/QR(선택)  
- **리포트(다운로드)**:  
  - **월별 수익**(청구 vs 수납, 전년동월 대비)  
  - **연체 리포트/에이징**(임차인·유닛별)  
  - **점유율 vs 잠재 수익**(공실 손실 추정)
- **CSV 가져오기(선택)**: 은행 입출금 CSV 업로드 → 키워드/금액 일치로 반자동 매칭

### 5.5 수용 기준(예시)
- (월초) “청구 생성” 실행 시 **중복 0건**, 로그에 건수/스킵 사유 기록  
- 부분 수납 케이스에서 배분 합계 = Payment 금액 **일치**  
- 영수증 PDF **1초 내 생성**, 재현성 있는 번호 체계  
- Aging 리포트 합계 = 미납 합계 **일치**, 필터(기간/자산/유닛/임차인) 동작

### 5.6 테스트 포인트
- 단위: 일할/가산금/배분/상태전이, 유니크 제약  
- 위젯: 수납 배분 UI, 대량 발행  
- 통합: 청구→수납→영수증→리포트 합계 정합성

---

## 6) 우선 강화: **보안/RBAC & 유지보수(Work Order)** — 구현 아이디어

### 6.1 보안 & RBAC (백엔드 전환 전 _프론트 가드_ 전략)
- **역할/권한 모델**: `OWNER, ADMIN, MANAGER, ACCOUNTANT, STAFF, READONLY`  
  - 권한 토글: 모듈×액션(`read/create/update/delete/export/approve`)
- **라우팅 가드**: `go_router.redirect`에서 세션/역할 검사  
- **위젯 가드**: `can('bills.create')` 헬퍼로 버튼/액션 노출 제어  
- **로컬 인증 상태**: 개발 단계에선 **Mock 세션** + 기기 보안 저장소  
  - `flutter_secure_storage`로 토큰/키 저장(키체인/Keystore/DPAPI)  
- **로컬 DB 암호화**(권장): Drift + SQLCipher(or sqlite_crypt)  
  - 암호화 키는 보안 저장소에서 파생, 앱 기동 시 언락  
- **감사 로그(AuditLog)**: 주체·액션·대상·이전/이후 값·시각·클라이언트 정보  
- **PII 최소화/마스킹**: 주민번호 미저장 또는 **마지막 4자리만**, 연락처 마스킹 표시  
- **잠금/재시도 제한**: 로그인 5회 실패 시 일시 락(로컬)  
- **에러/크래시**: `logger` + (선택)`sentry_flutter`, 민감정보 스크럽

> 주의: 프론트 가드는 **UX/사고 예방용**이며, **최종 보안은 서버에서**. 백엔드 도입 시 JWT 스코프/정책 + 서버 권한 재검증으로 승격.

### 6.2 유지보수(Work Order)
**데이터 모델**
- `WorkOrder(id, unit_id?, lease_id?, title, category, priority, status, dueDate, assignee, createdBy, createdAt, updatedAt)`  
  - `status`: `OPEN | ASSIGNED | IN_PROGRESS | ON_HOLD | DONE | CANCELLED`  
  - `priority`: `LOW | NORMAL | HIGH | URGENT`
- `WorkOrderActivity(id, work_order_id, type, comment, createdBy, createdAt)`  
  - `type`: `COMMENT | STATUS_CHANGE | PHOTO | FILE`
- `Attachment(id, ownerType, ownerId, name, mimeType, size, url/hash)`

**플로우**
- 발생(임차인/점검표/관리자) → 접수(카테고리/우선순위) → 할당 → 진행/코멘트/사진 → 완료/평가  
- **SLA**: 우선순위별 목표 기한(초기엔 표시만, 알림은 후순위)

**UI/UX**
- **리스트 + 칸반 보드**(상태별 컬럼), 필터(자산/유닛/우선순위/상태/기간)  
- 상세: 타임라인(활동/사진/파일), 상태 전환, 할당 변경  
- 체크리스트 연계: 체크 항목 “수리 필요” → **워크오더 생성** 바로가기  
- PDF 요약(선택): 완료 보고서(사진/비용/조치 내역)

**수용 기준**
- 상태 전환 규칙 준수(예: `DONE` 이후 재개는 `REOPEN` 기록)  
- 첨부 업로드/미리보기 동작, 20MB 이미지 10장에서도 UI 지연 없음  
- 리스트/칸반 필터·정렬 조합에서 결과 일관성

---

## 7) 단기 실행 플랜(3일)
- **D1**: RBAC 스캐폴딩(라우트/위젯 가드), Drift 암호화 PoC, Audit 로그 테이블  
- **D2**: Payment/Allocation 모델·화면, 수납 배분·영수증 PDF(기본 템플릿)  
- **D3**: Work Order 리스트·상세·상태전환, 칸반 보드(간이), 대시보드 KPI 연동

---

## 8) (후순위) 백엔드 연동 방향 — **3·4차 개발**
- 인증: 폼 로그인 → **JWT(roles/permissions 포함)**, 토큰 갱신/만료 처리(서버)  
- 대량 작업: **청구 대량 발행/보고서 생성**은 **비동기 Job** + 진행상태 폴링  
- 파일: 계약서/영수증/점검표 PDF는 **서버 렌더링** + 버전/감사로그  
- 알림: 이메일/카카오(선택) — 연체/만료/작업 배정 트리거

---

## 9) 결론
- 본 v2는 건물주가 당장 가치 체감하는 **수익관리**와 **보안/RBAC·유지보수**를 구체화  
- 백엔드 연동은 후순위로 미뤄도, 프론트/로컬 중심으로 충분히 **운영 가능한 스코프** 확보  
- 차기 스프린트는 “청구→수납→영수증→리포트”와 “워크오더 기본 흐름” 완성이 목표

---

## 참고/근거
- 1단계 완료 리포트: **로그인/자산/임차인/임대/청구 구현**, M3/반응형/라우팅/Drift/대시보드 등 현황  
- 남은 작업(우선순위): **결제(수납), Work Order, RBAC, 보고서 강화** 명시

 

위의 내용처럼, 개발 프로세스 중, 단순한 코드 생성을 넘어, 기획 단계부터 AI가 깊숙이 관여 시켰습니다. 화면설계도 요청했었고요. 답변은 wireframe 으로 전달 받았으며, 이 wireframe 을 통해 화면 요구사항은 초기에 끝났습니다. 물론 이후 필요한 기능들이 추가되면서 조금씩 변경은 되었지만, ChatGPT 가 전달 해준 wireframe 의 화면 설계와 구현 가능한 디자인 설계도는 이후 Claude-code 와 협업 씨 많은 토큰?을 아낄 수 있었습니다.

ChatGPT 가 만들어준 대시보드의 wireframe 파일과 설명서

 AI 툴들과 와 함께 구상한 설계가 구체화된 후, 본격적인 '바이브 코딩'이 시작되었습니다. 저는 해결해야 할 문제나 구현할 기능들.. 즉 '목표' / '요구사항' 을 제시했고, AI는 그 목표를 달성하기 위한 계획과 최적의 코드를 제안했습니다. 다음은 앱내 알림 서비스를 구현하면서 전달한 요구사항을 가지고 to-do 리스트를 만든 후, 제 피드백을 받고, 하나씩 진행하는 화면입니다.

todo 를 계획하고 하나씩 완료해 가는 claude-code : 세션 리밋이 넘 빨리 걸렸음.

위의 화면에서는, 당연히 todo 리스트는 제가 정리해서 공유한 요구사항 내용을 가지고 만든 리스트이지만, 간혹 과제를 던져주면 알아서 과제내에서 wbs 를 만들어 진행전에 저와 계획을 공유하며 리뷰/피드백을 받고 진행하였습니다. 최근 admobs 를 활용한 광고 배너를 모바일에 추가하는 작업을 진행하였는데 꽤 수월하게 진행되었습니다. 개발 완료 후, 진행 사항 내용을 보여주는 화면입니다. 토큰 때문에 오류외 피드백은 잘 안하는 편이지만, 이번만큼은 별다른 오류나 실수 없이 한번에 진행되어서 피드백을 주었습니다. -- ai 도 좋아하는 표현을 좀 적극적으로 하면 더 할텐데 말이죠. ㅋㅋ

코드 작업 후, 테스트 피드백을 주며 ai 와 대화하는 화면

물론 버그는 있습니다. 코딩 작업 이후엔 바로바로 빌드 테스트를 진행하였지만, 실제 화면 테스트는 어느정도 시나리오의 흐름 때문에 활용 가능한 데이터를 기다려야 하는 경우도 있었고, 가상으로 만들어 진행 하기도 했습니다.

최근 해결한 '월별 수익 보고서의 자산 필터' 문제가 좋은 예시입니다.

문제 제기 (나): "보고서의 월별 수익 화면에 자산 필터가 있는데, 특정 자산을 선택해도 금액이 바뀌지 않아. 원인을 분석하고 해결책을 제안해 줘."

이 문제를 듣고 AI는 reports_screen.dart, reports_controller.dart, reports_repository.dart 등 관련된 여러 파일을 스스로 분석했하였고, UI의 선택 값이 데이터 조회 로직까지 전달되지 않는다는 근본 원인을 정확히 찾아냈습니다. 그리고 단순히 UI 코드만 수정하는 것이 아니라, 데이터 흐름 전체를 개선하는 구조적인 해결책을 제시했습니다. 데이터베이스 쿼리부터 컨트롤러, UI까지 각 계층에서 수정해야 할 부분을 진행전에 명확히 알려주었습니다. 제안한 코드를 제가 최종 검토하고 프로젝트의 일관성을 해치지 않는지 확인한 후 적용되었습니다.

제가 방향을 제시하고, AI가 제 의도를 이해할 때까지 설명하여, 실제 개발자처럼 움직일 수 있도록 하여 원하는 결과물을 만들어 내었던 재미난 경험이었습니다.

이번 바이브크딩 프로젝트 통해 AI 툴 (ChatGPT, Gemini-CLI, Claude-Code) 들은 단순 코더가 아니었습니다. 비록 역할별로 다른 AI 툴들을 넘나들며 활용하였지만, 바이브코딩은 다음과 같은 이유로 가능했습니다.

1. 복잡하게 얽힌 코드들 속에서 문제의 근본 원인을 찾아냈습니다. (Claude-Code, Gemini-CLI)
2. 비효율적인 로직 대신, 성능과 구조를 고려한 더 나은 아키텍처를 제안했습니다. (Claude-Code, Gemini-CLI)
3. 제가 요청하면, 방금 수정한 내용에 대한 기술 문서를 Markdown 형식으로 깔끔하게 정리하여 docs 폴더에 저장해 주었습니다. (ChatGPT, Gemini-CLI, Claude-Code)

단순히 3개의 Tool 로만 진행하였지만, 결과물은 무척 만족스럽습니다. 

물론 '바이브 코딩'이 항상 순탄했던 것은 아닙니다. '요구사항'의 상세함이 결과물의 품질을 결정한다.. 입니다. 즉 "대충 만들어줘"라는 식의 모호한 요구사항은 결과물의 품질을 보장할 수 없었습니다. 초기 기획 단계에서 PRD와 와이어프레임을 상세하게 정의했던 것처럼, 풍부하고 구조화된 '요구사항'을 제공할수록 AI 파트너는 더 정확하고 뛰어난 결과물을 만들어냈습니다.

최종 결정과 책임은 인간의 몫.. 저의 몫이였습니다.: AI는 놀랍도록 정확했지만, 프로젝트의 전체적인 방향성이나 최종 사용자 경험의 미묘한 차이까지 책임져 주지는 않습니다. 제안된 코드를 비판적으로 검토하고 최종 결정을 내리는 것은 여전히 저의 가장 중요한 역할이었습니다.

이 프로젝트를 통해 얻은 가장 큰 교훈은, AI는 개발자를 대체하는 것이 아니라, 개발자의 능력을 증폭시키는 강력한 도구(Force Multiplier)라는 것입니다. AI 덕분에 저는 혼자서 기획, 분석, 개발, 문서화까지, 마치 작은 팀처럼 일할 수 있었습니다.

결론: 새로운 개발 패러다임, 바이브 코딩
'Renthouse(가제)' 프로젝트는 AI와의 협업이 더 이상 먼 미래의 이야기가 아님을 증명하고 있습니다. 개발자의 역할은 모든 코드를 한 줄 한 줄 작성하는 것에서, AI라는 강력한 파트너에게 명확한 '요구사항'을 제시하고 전체적인 품질을 책임지는 '아키텍트' 또는 '오케스트라의 지휘자'로 변화하고 있습니다.

아직 AI와의 협업을 시도해보지 않으셨다면, 여러분만의 '바이브'를 가지고 작은 프로젝트부터 시작해보시길 강력히 추천합니다. 아마 코딩하는 방식에 대한 생각이 완전히 바뀌게 될지도 모릅니다.

마지막으로, 가트너에서 발표한 10가지 2025년의 주요 기술 트랜드라는 글을 ChatGPT 를 통해 번역하여 블로그에 올린 기억이 있습니다. 이때만 해도 ChatGPT 는 기존 검색엔진보다 "말 많은 검색 툴" 로만 여겼었지요. 하지만 2025년 한해간 급격히 많은 업그레이드가 되었고, 많은 AI 툴들이 만들어져서 서비스화 되었습니다. 2025 년은 ai 의 해라고 해도 과언이 아닐것 같네요.

AI를 의사결정 에이전트로 전환 가트너는 에이전틱 AI가 향후 2~3년 내에 등장할 것으로 예상하며, 정보 요약과 같은 작업을 넘어 개인을 대신해 실제로 행동을 취하는 능력을 갖출 것으로 보고 있습니다. 사용자에게 옵션을 제시하는 대신, 허가를 받으면 사용자에게 최적의 옵션을 선택할 수 있게 될 것입니다
출처:
https://yobine.tistory.com/605
[#Yobine:티스토리]

2025 년 #가트너 (#Gartner) 에서 발표한 10가지 주요 전략 기술 트렌드 :: #Yobine

2025 년 #가트너 (#Gartner) 에서 발표한 10가지 주요 전략 기술 트렌드