기획은 챗GPT로 개발은 클로드 코드로: 다이어트 앱을 만들고 배포까지 해봤습니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

챗GPT로 기획하고 클로드 코드로 다이어트 앱을 구현·배포한 이 사례는, AI 개발에서 사람이 맡을 핵심이 요구사항 결정과 결과 검증임을 보여준다.

📌 핵심 요점

1. 일반 다이어트 사용자를 대상으로 식사는 지출, 운동은 수입처럼 기록하는 칼로리 가계부를 기획하고, 화면·기능·원칙을 마크다운 문서 11개로 정리했다.
2. 기획 문서를 클로드 코드에 넘겨 구현을 진행했다. 문서가 기획 AI와 개발 AI 사이의 전달 수단이 됐고, 로그인 방식·AI 공급자·구현 범위는 사람이 결정했다.
3. AI는 음식 이름과 양을 해석하고, 영양 수치는 식약처 데이터와 서버 계산을 우선하도록 설계했다. 데이터베이스에 없는 음식에는 출처 배지를 붙인 AI 근사치를 허용했다.
4. 가짜 AI를 사용한 테스트만으로는 실제 연동 결함을 찾지 못했다. 실제 API 호출, 음식 사진 분석, 모바일·데스크톱 브라우저 조작, 회귀 테스트를 거치며 문제를 수정했다.
5. 배포 후에는 서버 실행 지역 때문에 클로드 API가 403을 반환하는 문제가 발생했다. 이를 해결한 뒤 보안 점검까지 진행했으며, 마지막에는 데이터를 남기고 사이트 접근을 닫았다.

🧩 배경과 문제 정의

만들려는 서비스는 먹은 음식과 운동을 가계부처럼 기록하는 일반 사용자용 다이어트 웹앱이다. 음식 사진이나 말로 설명한 식사를 분석해 기록 부담을 줄이고, 결과를 대화형 답변에 그치지 않고 데이터베이스 항목으로 저장하는 것이 목표였다.

제작 과정의 핵심 문제는 기획을 개발 AI에 빠짐없이 전달하는 방법, AI가 해석한 음식과 신뢰할 수 있는 영양 수치를 연결하는 방법, 그리고 로컬에서 작동한 앱을 운영 환경에서도 검증하는 방법이었다. 영상은 기획부터 구현·실제 데이터 연동·디자인 수정·배포·보안 점검·접근 종료까지 따라간다.

🕒 시간순 섹션별 상세정리

1. 칼로리 가계부 구상과 사용자 선택

• 음식 설명을 입력하면 칼로리를 계산해 장부에 넣는 앱을 소개하고, 새벽 1시 42분부터 기획과 제작을 시작했다고 보여준다. [00:22]
• 챗GPT에 식사와 운동을 수입·지출처럼 기록하고, 사진으로 칼로리와 영양 성분을 분석하는 웹앱 기획을 요청한다. [00:55]
• 일반 다이어트 사용자로 대상을 좁혀 화면별 기능을 설계하며, 기록하지 않은 날을 0칼로리 섭취로 처리하지 않는 원칙을 세운다. [01:48]

2. 기술 구성과 문서 기반 인계

• 화면은 Vite·React, 데이터는 SQLite, 배포는 Cloudflare Workers·D1, 파일 저장은 R2로 정하고, 말로 설명한 음식도 분석해 데이터베이스에 저장하도록 요구한다. [02:21]
• 기획 결과를 마크다운 파일 11개로 받아 작업 폴더에 정리한다. [02:48]
• 대화 내용을 사람이 복사하는 대신 다음 AI가 파일 전체를 읽게 하는 방식으로 기획과 구현을 연결한다. [03:12]

3. 클로드 코드의 확인 질문과 구현 계획

• 클로드 데스크톱의 코드 세션에서 문서를 먼저 분석하고 순서대로 구현하라고 지시한다. 자동 실행 모드인 만큼 계획을 먼저 확인하는 중요성을 짚어 본다. [03:49]
• 클로드가 로그인·AI 공급자·구현 범위·소스 위치를 묻고, 사용자는 닉네임 기반 개발용 로그인과 클로드 API, 첫 버전 전체 구현을 선택한다. [04:18]
• 칼로리는 서버가 데이터베이스와 공식으로 계산하고, 버그 수정에는 재현·원인 분석·회귀 테스트를 붙이는 계획을 수락한다. [04:47]

4. 단계별 구현과 첫 화면

• 기반 구조, 로그인과 수동 기록, 문장·음성 분석, 사진 분석, 리포트·설정 순으로 개발하고 마지막에 테스트·빌드·브라우저 검증을 수행하도록 구성한다. [05:14]
• 설치와 데이터 구조 작업을 거쳐 구현 시작 후 약 21분째 닉네임과 목표를 입력하는 첫 대시보드가 나타난다. [05:49]
• 녹화가 끊긴 사이 마지막 구현 단계까지 진행됐고, 자동 테스트가 여러 상황을 확인하는 방식이라고 보여준다. [06:20]

5. 실제 AI 연결로 발견한 결함

• 기존 테스트가 가짜 AI를 사용했음을 밝히고, 실제 클로드 API 키를 설정해 기획서의 품질 테스트 문장 여섯 개를 분석한다. [06:42]
• 운동 강도 덮어쓰기, 밥 칼로리의 합계 누락, 분석 이유 중복을 발견해 수정하고 회귀 테스트를 추가한다. [07:03]
• 파이썬으로 그린 음식 이미지를 분석에 넣고, 이미지에 숨긴 엉뚱한 명령에 대한 방어도 확인한다. [07:17]

6. 브라우저 사용성 검사와 신체 정보 기능

• AI가 조작하는 브라우저로 모바일 화면에서 가입·목표 설정·음식 입력·분석 초안 선택·저장을 수행한다. [07:48]
• 화면을 직접 누르는 사용성 검사에서 거슬리는 점 아홉 개를 찾아 수정하고, 넓은 화면에서도 다시 확인한다. [08:34]
• 나이·키·체중·성별을 입력받아 기초대사량, BMI, 하루 유지 칼로리를 계산하는 기능을 추가 요청한다. [08:49]

7. 식약처 데이터 연결과 음식 단위 보정

• AI는 음식 이름과 양을 해석하고 영양 수치는 식약처 데이터베이스에서 가져오는 방침을 보여준다. 브라우저가 API 명세를 확인하고 클로드가 연결 코드를 작성한다. [09:33]
• 로그인과 본인 인증은 사용자가 직접 처리한다. 실제 데이터 연결 뒤에는 바나나 검색 오류, 닭가슴살 검색 품질 저하, 비빔밥 중복 문제가 드러난다. [10:09]
• 검색 패턴의 길이 문제를 수정하고 실제 음식 사진으로 검사한다. 밥 한 공기를 100g으로 해석한 오류를 고치며 신체 정보 계산 화면도 확인한다. [10:47]

8. 데이터 출처 재점검과 AI 근사치 도입

• 기록의 출처를 조사하자 식약처 데이터는 일부였고 나머지는 개발용 근사값이었다. 식약처를 우선하되 없는 음식에는 AI 근사치 배지를 붙이도록 바꾼다. [11:35]
• 엄마표 잡탕을 잡탕밥에 잘못 연결한 사례를 확인하고, AI 근사치 선택과 오류 재시도 처리를 보완한다. [12:02]
• 검색 후보 범위와 판정 규칙을 개선하고 근사치를 저장해 재사용한다. 같은 음식 기록의 응답 시간이 11.5초에서 6.8초로 줄었고 테스트는 105개가 된다. [12:53]

9. 디자인 개편과 미기록 상태 수정

• 오픈 소스 디자인 스킬을 프로젝트에만 설치하고 출처를 기록한다. 검사용 계정에는 일주일치 기록과 의도적으로 비운 하루를 준비한다. [13:45]
• 디자인 검사 실패 아홉 건과 경고 17건을 확인하고 파스텔 스타일과 하루 예산 막대를 선택한다. 개편 중 빈 화면 문제는 개발 서버를 다시 실행해 해결한다. [14:41]
• 작은 단위 글씨와 주간 차트를 고치고, 미기록 날짜를 0칼로리 막대로 표시하던 문제를 수정한다. 디자인 검사 실패는 0건이 된다. [15:24]

10. 검색 마무리와 클라우드 배포

• 흰우유 검색에서 엉뚱한 항목이 먼저 나오는 문제를 고친다. 새벽 작업 후 7시간 20분을 쉬고 낮에 배포를 재개한다. [15:57]
• Workers·D1·R2를 운영 환경에 구성한다. R2 활성화를 위한 결제 수단 등록은 사용자가 직접 처리한다. [16:46]
• 처음 선택한 접근 제어 방식이 설정·요금제 조건에 막히자 앱 내부 접속 코드 방식으로 변경하고, 테스트 117개를 통과한 뒤 배포한다. [17:19]

11. 운영 환경의 지역 오류와 첫 기록 저장

• 배포 주소에서 음식 분석이 실패한다. 운영 기록과 로그를 확인해 서버가 홍콩에서 실행되면서 클로드 API 요청이 403으로 차단됐음을 찾는다. [18:04]
• 서버 실행 위치를 서울 근처로 지정해 재배포한다. 분석 결과에서 식약처 데이터와 AI 근사치가 배지로 구분되고, 양을 수정한 식사가 410kcal로 저장된다. [18:45]
• 전체 경과 시간은 11시간 7분 45초로 제시한다. 휴식은 7시간 20분, 나머지는 약 3시간 48분이며 녹화 시간은 2시간 49분이었다고 보여준다. [19:08]

12. 추가 기능과 보안 점검, 사이트 접근 종료

• 치즈버거 사진 분석과 칼로리의 체중 환산 기능을 추가하고, 배포와 GitHub 저장소 업로드를 함께 지시한다. [19:35]
• 운영 API 키 교체에서는 마지막 입력을 사용자가 맡는다. 보안 공격 시험 36개 중 처음에는 29개가 통과해 보안 헤더와 접속 시도 횟수 제한을 보완한다. [19:58]
• 재시험을 통과한 뒤 배포하고 사이트 접근을 닫는다. 주소는 404를 반환하지만 데이터는 남겨둔다. [20:12]

13. 남은 산출물과 사람의 역할

• 최종 산출물로 기획서 11개와 테스트 125개를 제시한다. [20:19]
• 사용자가 한 일을 무엇을 만들지 말하기, 결과를 의심하기, 결제처럼 직접 해야 하는 일 처리하기로 정리한다. [20:34]
• 기다리는 동안 무엇을 의심할지 궁리하는 일이 개발의 한 모습이라고 돌아보며, 정작 앱을 만드느라 자신의 운동 기록은 비어 있다는 농담으로 마친다. [20:50]

🧾 결론

• 기획 문서 11개와 최종 테스트 125개가 남았으며, 앱이 운영 환경에서 음식 기록을 저장하는 장면까지 확인됐다.
• 영상이 제시한 전체 경과 시간은 11시간 7분 45초다. 휴식 7시간 20분이 포함됐고, 나머지 약 3시간 48분도 대부분 기다리는 시간이었다는 설명이므로 이를 순수 작업 시간으로 해석하면 안 된다.
• 사람의 역할은 무엇을 만들지 정하고, AI의 결과와 데이터 출처를 의심하며, 본인 인증·결제·키 입력처럼 직접 처리할 일을 맡는 데 집중됐다.
• 완성 판단에는 기능 구현뿐 아니라 실제 데이터의 출처, 미기록 상태의 표현, 운영 환경 오류, 보안 점검까지 포함됐다.

📈 투자·시사 포인트

• AI 개발 도구의 활용 가치는 코드 생성뿐 아니라 기획 문서 인계, 브라우저 검증, 외부 API 연결, 배포와 수정 과정을 얼마나 연결하는지에서도 드러난다.
• 영양 정보처럼 숫자의 근거가 중요한 서비스에서는 데이터 출처 표시와 근사치 구분이 제품 신뢰를 좌우하는 설계 요소가 된다.
• 외부 AI API와 클라우드를 결합하면 로컬 테스트에서 드러나지 않은 실행 지역·접근 제어·계정 설정 문제가 운영 단계의 변수가 된다.
• 이 영상은 한 앱의 제작 사례이며, 개발 도구의 수익성이나 특정 기업의 투자 매력을 판단할 비용·매출·이용자 지표는 제시하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 자막에는 모델명, 중간 테스트 개수, 일부 칼로리 수치의 표기가 불명확하다. 해당 값은 정확한 사양이나 성능 비교의 근거로 삼기 어렵다.
• 식약처 데이터라도 음식 이름과 실제 음식의 연결, 섭취량과 단위가 틀리면 결과가 달라진다. 영상에서도 잡탕과 잡탕밥의 오인 연결, 밥 한 공기의 중량 오류가 발견됐다.
• AI 근사치 배지와 재사용 기능은 구현됐지만, 근사치의 정확도나 잘못 저장된 값의 장기적인 수정 방식은 확인되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 대상 사용자, 화면별 기능, 미기록 처리 원칙을 기획 파일에 적고 개발 AI가 먼저 읽도록 한다.
• 영양 수치가 식약처 데이터인지 AI 근사치인지 저장 기록과 화면 양쪽에서 확인한다.
• 실제 API와 음식 사진을 사용해 음식 매칭·양·단위·합계를 검증하고, 발견한 결함은 회귀 테스트에 추가한다.
• 모바일과 데스크톱에서 신규 사용자 흐름을 실행하고, 기록 없는 날이 0칼로리로 표시되지 않는지 확인한다.

❓ 열린 질문

• 비슷한 이름의 음식 후보가 여러 개일 때, 어떤 기준으로 자동 선택하고 언제 사용자 확인을 요청해야 할까?
• 저장해 재사용하는 AI 근사치가 틀렸을 때, 기존 기록과 이후 분석에 수정 내용을 어떻게 반영할까?
• 개인용 접속 코드 방식에서 이용자가 늘어나면 인증과 데이터 접근 권한을 어떻게 바꿔야 할까?