왜 이 일을 시작했나요?
음식 배달 서비스의 점주님용 앱을 운영하는 동안 꾸준히 같은 피드백이 들어왔습니다.
"메뉴 등록이 너무 어려워요. 더 쉽게 해주세요."
문제는 옵션과 사이즈, 토핑, 기간 한정 등 고려해야 할 사항이 많은 메뉴 등록은 그 자체가 본질적으로 복잡하다는 점입니다. 따라서 '기능은 풍성하게, 화면은 단순하게'라는 모순을 풀어야 했습니다. 전통적인 방식대로 진행한다면 사양서 작성 → 설계 → 개발 → 수정의 비용이 상당합니다. 요구 사항이 정교해질수록 문서의 길이는 길어지고, 개발과 수정을 오가는 사이에 시장의 트렌드는 바뀝니다.
그래서 전략을 바꿨습니다. 생성형 AI를 이용해 '작동하는 데모'를 빨리 만들어 보고, 이를 보면서 고치는 방식으로 접근했습니다. 목표는 이전에는 한 달이 걸렸던 과제를 5일 안에 구현하는 것입니다. '완벽한 정답'을 찾기보다 '충분히 괜찮은 해답'을 빠르게 만들어 검증하는 루프를 구성하는 것입니다.
- 한 줄 요약: 한 번에 정답을 찾기보다는 일단 빨리 만들고 이를 반복하면서 정답에 가까워지자.
전체 흐름 한눈에 보기
처음에는 '음식점 메뉴를 등록하는 모바일 앱을 만들어 주세요'라는 한 문장으로 지시했습니다. 그렇게 몇 차례 받은 결과물들은 디테일이 부족했고, 제가 원했던 방향과는 다른 방향의 결과물들이었습니다. 이런 결과는 대부분 지시(프롬프트)가 모호했기 때문인데요. 지시 사항을 처음부터 완벽하게 작성하는 것은 그 자체로 쉬운 일이 아니죠.
그래서 전략을 바꿨습니다. 전체 작업을 5단계로 쪼개고 각 단계 산출물을 다음 단계 입력으로 넘기는 짧은 프로세스를 만들었습니다.
이 프로세스에서는 마음에 들지 않으면 질문을 조금씩 손봐서 다시 요청하거나, 세세한 부분은 직접 수정합니다. 그렇 게 해서 완성된 앱이 마음에 들지 않으면 다시 1단계로 돌아가도 됩니다.
전통적인 방식에서는 '처음으로 되돌아가기'를 선택하려면 큰 결심이 필요합니다. 우선 명세서를 고치는 일 자체가 어렵고(합의, 영향 분석 필요), 한 번 작성해 굳어진 화면과 데이터 구조를 수정하기도 어렵습니다. 이전에 해 둔 테스트가 쓸모 없어진다는 문제도 있습니다.
반면, AI를 활용한 이 방식에서는 'AI가 만들어 준 산출물'을 사용하므로 언제든 재작업을 요청해도 부담이 되지 않습니다. AI는 같은 지시를 여러 번 바꿔 보내도 화내지 않습니다. 오히려 반복을 통해 맥락이 축적되면서 결과물의 품질이 꾸준히 올라갑니다.
그럼 이 새로운 방식으로 어떻게 작업을 진행했는지 단계별로 살펴보겠습니다.
1단계: 요구 사항, 도메인 정리
- 소요 시간: 1시간
- 사용 도구: 메모장
AI에게 처음 알려 줄 요구 사항은 되도록 단순하게 정리합니다.
- 무엇을 만들려고 하는지: 앞으로 세부 내용이 계속 추가될 것이므로 한 줄 요약으로 충분합니다.
- 최우선순위 한두 가지: 우선순위가 많으면 산출물의 방향이 모호해지므로, 꼭 중요한 것만 뽑습니다.
- 데이터 구조: 데이터 구조에 따라 화면이 작성되기 때문에 이 부분은 가능한 한 사실에 가깝게 정리합니다.
정리된 산출물은 아래와 같습니다. 참고로 이하 등장하는 프롬프트와 결과 발췌 내용에서 초록색으로 홑화살괄호(<>)로 묶인 부분은 이해를 돕기 위해 추가한 설명으로 실제 프롬프트나 결과 내용이 아닙니다.
|
<1단계 산출물> 요구 사항 - 음식 배달 서비스에서 음식 메뉴 등록 작업을 쉽게 조작할 수 있는 점주님용 모바일 앱 화면 작성 - 다시 강조하지만 !쉽게 등록!이 최우선 메뉴 등록에 사용되는 필드 - 상품명(필수) - 상품 이미지 - 상품 설명 <그 외 총 15가지 필드를 정의했으나 이 글에서는 생략> |
- 팁: 여기서 너무 많은 것을 정리하려고 하지 마세요. 너무 많은 것을 정해 두는 일은 앞으로 나올 멋진 아이디어를 제한하는 일이 될 수도 있습니다.
2단계: 솔루션 후보 선정
- 소요 시간: 1시간
- 사용 도구: ChatGPT
- ChatGPT 호출 횟수: 10회 미만
여기서는 최대한 다양한 방향성을 확보하는 것이 핵심입니다. 따라서 아래와 같이 입력해 10개의 아이디어를 얻습니다. 10가지 후보를 뽑으면 현실성이 떨어지는 아이디어도 섞일 수 있지만, 그와 같은 엉뚱한 발상이 새로운 힌트가 되기도 합니다. 이때 장단점을 함께 제시하도록 주문하면 실무에서 선택할 때 참고할 수 있는 기준을 세울 수 있습니다.
|
<프롬프트> 음식 메뉴 등록 작업을 쉽게 조작할 수 있는 모바일 앱 화면 후보 10가지를 제안해 줘. 각 후보마다 장단점도 써줘 |
원하는 결의 답변이 나올 때까지 프롬프트를 미세 조정하며 여러 번 요청합니다. '좋은 답이 나올 때까지 프롬프트를 미세 조정한다'는 이 방식이 의외로 강력합니다. 제안된 10가지 중 현실성이 낮은 것은 버리고, 겹치는 아이디어는 합치고, 일부는 섞어서 최종 후보 5개를 만듭니다.
- 팁: 이 단계에서 너무 오래 머무르지 마세요. 끝까지 만들어 보고 다시 돌아오는 편이 훨씬 효과적입니다. 완성물이 최고의 디버거입니다.
아래 표는 최종 선정한 다섯 가지 솔루션을 정리한 것입니다. 참고로 표에서 왼쪽이 ChatGPT의 결과물입니다. 오른쪽 이미지는 이해를 돕기 위해 추후 공유할 4단계 결과물의 일부를 발췌해 가져온 예시 화면이므로 오해 없으시길 바랍니다.
| 최종 선정한 다섯 가지 솔루션 | Cursor를 이용해 일부 시각화한 예시 화면 |
|---|---|
1안: 스텝퍼형 마법사(순차 입력)
|  |
2안: 라이브 미리보기형(Quick Add 연동)
|  |
3안: 템플릿/복제 선택 화면
|  |
4안: 채팅 입력
|  |
5안: 기존 메뉴판 사진 촬영
|  |
3단계: 와이어 프레임 설계
- 소요 시간: 1일
- 사용 도구: ChatGPT
- ChatGPT 호출 횟수: 5개 솔루션 각 10회 미만, 총 50회 미만
이제 각 솔루션이 실제로 어떤 화면 흐름으로, 각 화면은 어떤 요소로 구성될지 구체화할 시점입니다. ChatGPT에게 각 솔루션별로 필요한 화면 수와 화면 요소를 정리하도록 요청합니다. 다섯 가지 후보를 각각 별도로 진행하며, 진행 시에는 마음에 드는 대답이 나올 때까지 반복해서 질문하거나 세세한 부분은 직접 다듬습니다.
|
<프롬프트> 아래와 같은 앱을 만들 건데, 필요 화면 수와 화면 요소를 정리해 줘. <1단계 산출물 입력> - 음식 배달 서비스에서 음식 메뉴 등록 작업을 쉽게 조작할 수 있는 점주님용 모바일 앱 화면 작성 <이하 생략>
<2단계에서 생성된 5개 솔루션 중 1개 입력> 스텝퍼형 마법사(순차 입력) - 개념: 초보 점주는 '어디서부터 입력해야 하는지' 막막하다 → 마법사형 단계 진행이 유리할 수 있다. 메뉴명 → 가격 → 사진 → 옵션/토핑 → 노출/품절 → 미리보기 순으로 단계별 진행 <이하 생략> |
|
<결과 중 일부 발췌> 전체 화면 구성 공통 UI 패턴(모든 단계) ⸻ 8단계 상세 설계 1단계: 기본 정보 목표: 메뉴의 뼈대를 10초 안에 만든다 2단계: 카테고리 <이하 생략> |
결과 확인 후 빠진 기능이 있다던가 우선순위 조정 등 프롬프트 작성 시 놓친 부분이 발견된다면 프롬프트를 수정해 재요청합니다. 혹은 프롬프트 대신 결과물 자체를 직접 수정하는 것도 가능합니다.
|
<프롬프트 수정 예시> 아래와 같은 앱을 만들 건데, 필요 화면 수와 화면 요소를 정리해 줘. - <1단계 산출물 입력> - <2단계에서 생성된 5개 솔루션 중 1개 입력> - 첫 화면에서는 상품명을 먼저 입력할 수 있게 해야 해 <새로 추가한 부분> - 임시 저장이 들어가야 해 <새로 추가한 부분> |
- 팁: 클릭 몇 번으로 검증 가능한 간단한 화면은 이 단계를 건너띄고 바로 다음 단계로 진행해도 괜찮습니다.
4단계: 앱 코드 작성
- 소요 시간: 2일
- 사용 도구: Cursor
- Cursor 호출 횟수: 5개 솔루션 각 10회 미만, 총 50회 미만
이제 Cursor를 이용해 본격적으로 구현을 시작합니다. Cursor는 입력된 프롬프트로 코드를 작성해 주는 툴입니다. Flutter는 단일 코드베이스로 iOS/Android를 동시에 다룰 수 있어 초기 실험의 속도를 끌어올려 줍니다.
먼저 각 솔루션을 얹을 공통 뼈대를 만듭니다. 이후 이 뼈대 위에 각 솔루션을 하나씩 구현할 것입니다. 한꺼번에 만들어도 되지만, 이렇게 나누면 중간중간 결과를 확인하며 마음에 들지 않는 화면은 쉽게 재생성할 수 있습니다.
|
<프롬프트> 아래와 같은 Flutter 모바일 앱을 작성해 줘. <1단계 산출물 입력> - 음식 배달 서비스에서 음식 메뉴 등록 작업을 쉽게 조작할 수 있는 점주님용 모바일 앱 화면 작성 <이하 생략>
메인 화면에 메뉴 생성 버튼 클릭 시 5가지 타입의 진입점을 만들고 클릭 시 빈 화면이 뜨도록 해. - 스텝퍼형 마법사 - 라이브 미리보기형 - 템플릿/복제 선택 화면 - 채팅 입력 - 기존 메뉴판 사진 촬영 <이하 생략, 2단계에서 생성된 5개 솔루션 모두 입력> |
프롬프트('Flutter 모바일 앱을 작성해 줘')가 의외로 간단해서 의아하실 수 있는데요. 지금은 기능 위주의 화면만 검토하는 데모 단계이기 때문에 한 줄이면 충분합니다. 코드가 마음에 들어 계속 확장하고 싶다면 이후 '상태 관리는 Riverpod로 바꿔 줘', '데이터 저장은 SQLite에 해 줘'처럼 점진적으로 하나씩 요구를 추가해 나가면 됩니다. 사람이 직접 코드를 작성할 때는 보통 테크 스택을 먼저 정하지만, 이 방식에서는 반대로 데모를 먼저 만들고 스택은 이후에 붙이는 게 더 빠릅니다.
위 프롬프트로 생성된 산출물은 아래와 같습니다.
| 파일명 | 설명 |
|---|---|
| model.dart | 1단계에서 정의한 모델들을 구현한 클래스입니다. |
| main_screen.dart | 메인 화면으로, 이곳에서 버튼을 클릭해 앞으로 구현할 각 각의 화면으로 이동할 수 있습니다. |
|
type1_screen.dart type2_screen.dart type3_screen.dart type4_screen.dart type5_screen.dart | 각 솔루션을 구현할 파일로 현재는 빈 화면입니다. |
다음으로 각 솔루션을 한 후보씩 붙여가며 코드 작성을 지시합니다.
|
<프롬프트> 아래와 같은 Flutter 모바일 앱을 작성해 줘. - 메뉴 구조는 model.dart를 모델로 사용할 것 <4단계에서 생성된 파일> - 화면은 type1_screen.dart에 구현할 것 <4단계에서 생성된 파일>
<1단계 산출물 입력> - 음식 배달 서비스에서 음식 메뉴 등록 작업을 쉽게 조작할 수 있는 점주님용 모바일 앱 화면 작성 <이하 생략>
<2단계에서 생성된 5개 솔루션 중 1개 입력> 스텝퍼형 마법사(순차 입력) - 개념: 초보 점주는 '어디서부터 입력해야 하는지' 막막하다 → 마법사형 단계 진행이 유리할 수 있다. 메뉴명 → 가격 → 사진 → 옵션/토핑 → 노출/품절 → 미리보기 순으로 단계별 진행 <이하 생략>
<3단계에서 생성된 답변 입력> 전체 화면 구성 - 주요 단계 화면: 총 8개 <이하 생략> |
- 팁: 결과물이 마음에 들지 않는다면 재생성할 수 있습니다. 다만 '에이, 첫 번째 결과가 제일 나았는데..."라고 생각하게 되는 상황이 생각보다 자주 올 수 있으니 중간중간에 철저히 백업해 두세요. 이때 백업은 Git에 브랜치를 만들어 두는 정도면 충분합니다.
대략적인 수준을 확인하실 수 있도록 이 단계에서 생산된 산출물 몇 가지를 가져왔습니다.
5단계: 실행해 보기(리뷰 및 미세 조정)
- 소요 시간: 2일
- 사용 도구: Cursor
- Cursor 호출 횟수: 5개 솔루션 각 20회 미만, 총 100회 미만
완성된 데모를 직접 사용해 보고 코드도 함께 살펴보며 세밀하게 다듬습니다. 디테일이 부족한 부분은 구체적인 지시로 수정 요청합니다.
|
<프롬프트 예제> - 메뉴 아이템 리스트 셀은 한 줄에 하나씩 나오게 하고, 셀 높이는 100으로 해. - 메뉴 임시 저장이 제대로 안 되고 있는데, 이유를 찾아 수정해 줘. - 에러 메시지는 토스트가 아닌 대화 상자로 띄워 줘. |
- 팁: 첫 단추가 잘못 끼워졌다고 판단되면 과감히 1단계로 되돌아가 재시작하세요. 이 방식의 강점은 되돌림 비용이 낮다는 것입니다. 각 단계의 산출물은 AI가 만들어 준 것이므로 프롬프트만 손봐 다시 재생성을 요청하면 됩니다.
프로세스 요약
다음은 각 단계별 내용을 정리한 표입니다. 참고로 Cursor의 경우 컨텍스트의 캐시 리드(cache read) 때문에 토큰 수가 수십만 단위로 집계되는 경우가 많습니다. 따라서 사용 토큰 수는 제외하고 요청(request) 횟수만 표기했습니다.
| 작업 | 사용 도구 | 소요 시간 | 요청 횟수 | |
|---|---|---|---|---|
| 1단계 | 요구 사항 정리 | 메모장 | 1시간 | - |
| 2단계 | 솔루션 후보 선정 | ChatGPT | 1시간 | 10회 |
| 3단계 | 와이어 프레임 설계 | ChatGPT | 1일 | 50회 |
| 4단계 | 코드 작성 | Cursor | 2일 | 50회 |
| 5단계 | 코드 미세 조정 | Cursor | 2일 | 100회 |
맺음말
이번 실험을 한 문장으로 정리하자면 '5일 만에 움직이는 데모를 만들었지만 프로덕션 기준으로는 실패'라고 할 수 있겠습니다. 우선 도메인 모델이 미흡했고, 기본적인 안전장치(누가 사용할지 정하고, 무엇을 했는지 남기고, 잘못되면 되돌릴 수 있는)와 보안 점검이 없어 대폭 재작성해야 했습니다. 그럼에도 얻은 것이 있다면 점주가 실제로 막히는 지점을 더 정확히 파악할 수 있었고, 마법사형 흐름이나 OCR 보조 입력, 임시 저장 같은 유효한 아이디어 및 다음 라운드에 무엇을 먼저 해야 할지 우선순위를 정할 수 있었습니다.
다음은 이번 작업에서 얻은 몇 가지 인사이트를 정리한 것입니다.
- 움직이는 구현체는 최고의 토론 준비물입니다. 머릿속 상상만으로 기획하는 대신 모두 함께 작동하는 화면을 보고 토론하며 즉시 수정할 수 있습니다.
- AI가 모르는 것을 마법처럼 메워주지는 않았습니다. AI는 '정답 제조기'가 아니라 아는 만큼만 빠르게 만들 수 있는 '속도 증폭기'였습니다.
- 심리적 비용이 낮아졌습니다. 동일 요청을 여러 번 바꿔도 AI는 화내지 않습니다. 이제는 '일단 시키고, 보고, 고친다'가 실무에서도 충분히 통합니다. 작동하는 데모로 현실 검증을 빠르게 하고, 내가 더 많은 생각을 할 수 있게 해 줍니다.
- 곧장 상용 투입은 금물입니다. Cursor는 빠르게 코드를 만들지만 그렇게 작성된 코드에는 보안/데이터/성능 측면에서 여러 위험이 섞여 있을 수 있습니다. 예를 들어 고객의 정보를 외부로 유출하거나 서버의 데이터를 대량으로 지우는 코드가 섞여 들어갈 수도 있습니다. 따라서 작업 시 개발자의 꼼꼼한 리뷰와 안전장치 설정은 필수입니다.
이 글이 여러분의 다음 과제를 조금 더 빠르고 즐겁게 만들 작은 힌트가 되기를 바라며 이만 마치겠습니다. 읽어주셔서 감사합니다.
