17강: 피드백과 개선
배포 후가 진짜 시작이다
식당 문을 열었으면 손님 반응을 봐야죠
지난 16강에서 드디어 나만의 앱에 URL(인터넷 주소)을 달아주었어요. 이제 전 세계 누구나 내 앱에 접속할 수 있죠. 정말 고생 많으셨어요.
그럼 이제 모든 과정이 끝난 걸까요? 아닙니다. 오히려 지금부터가 진짜 시작이에요.
혼자서 완벽하게 만들었다고 생각해도, 다른 사람이 쓰면 꼭 문제가 생겨요. 우리가 미처 생각하지 못한 불편함이 발견되거든요. 오늘은 배포된 앱을 사용자에게 보여주고, 그 반응을 바탕으로 앱을 진화시키는 방법을 알아볼 거예요.
이건 뭐예요?
피드백과 개선 과정을 '식당 개업'에 비유해 볼게요.
앱을 배포했다는 것은 굳게 닫혀있던 식당의 간판에 불을 켜고 문을 연 것과 같아요. 개업을 했으니 이제 손님(사용자)이 오겠죠. 손님이 음식을 먹고 나면 다양한 반응을 보일 거예요.
"음식이 너무 짜요." "반찬으로 김치가 있으면 좋겠어요." "의자가 너무 불편해요."
이런 손님의 반응이 바로 피드백(feedback) 이에요. 피드백은 "되먹임" 이라는 뜻인데, 쉽게 말하면 "써본 사람이 알려주는 솔직한 의견"이에요. 식당 주인은 이 피드백을 듣고 레시피를 수정하거나 인테리어를 바꾸죠. 이것이 개선이에요.
앱도 똑같아요. 사용자가 써보고 알려주는 불편함을 듣고, 클로드(Claude)에게 코드를 고쳐달라고 부탁하는 거예요.
버전 번호로 성장 기록 남기기
이렇게 조금씩 앱을 고쳐나가는 과정을 버전 관리라고 해요. 소프트웨어는 보통 점(.)으로 구분된 숫자로 버전을 표시해요.
- v1.0: 식당 첫 개업 (우리의 첫 배포 상태예요)
- v1.1: 간 맞추기, 반찬 교체 (작은 버그 수정이나 간단한 개선)
- v1.2: 메뉴판 글씨 키우기, 테이블 배치 조정 (사소한 개선이 쌓인 것)
- v2.0: 완전히 새로운 메뉴판 도입 (아주 큰 기능 추가나 디자인 전면 개편)
점 앞의 숫자(1, 2)가 바뀌면 "큰 변화"가 생겼다는 뜻이에요. 점 뒤의 숫자(0, 1, 2)가 바뀌면 "작은 손질"이 있었다는 뜻이고요. 복잡하게 생각하실 필요는 없어요. 중요한 것은 "한 번 만들고 끝"이 아니라 "계속 좋아진다" 는 사실이에요.
우리는 이렇게 쓰고 있어요
저희 디온웍스도 수많은 피드백과 개선을 반복하고 있어요. 지금 여러분이 보고 계신 이 AI//STUDY 아카이브 사이트도 마찬가지예요.
처음 사이트를 배포했을 때는 글씨가 너무 작다는 의견이 있었어요. 또한 스마트폰으로 볼 때 메뉴가 잘린다는 피드백도 받았죠. 저희는 이 피드백을 모아 클로드에게 전달했어요. 그리고 화면 크기에 맞게 자동으로 변하는 모바일 반응형(화면 크기에 따라 레이아웃이 자동 조절되는 방식)으로 수정했어요.
저희의 사내 앱인 DGHR(근태관리 시스템)도 첫 배포 후 재미있는 일이 있었어요. 초기 버전은 디자인이 아주 깔끔했어요. 그런데 직원들이 "GPS 출퇴근 버튼이 어디 있는지 모르겠어요"라고 하더군요. 디자인에 신경 쓰느라 가장 중요한 버튼이 잘 안보였던거죠.
저는 즉시 클로드에게 요청했어요. "사이드 패널 하단에 색깔을 완전히 구분되도록 해서, 버튼이 잘보이도록 수정해"
클로드가 코드를 수정해 주었어요. 저는 터미널에서 명령어 몇 개를 입력했죠. 놀랍게도 단 5분 만에 수정된 내용이 새롭게 배포되었어요. 16강에서 배웠던 버셀(Vercel)의 자동 배포 마법 덕분이에요. 코드를 깃허브(GitHub)에 밀어 올리기만 하면 버셀이 알아서 새 버전으로 바꿔줘요.
한번 써볼까요?
그럼 우리의 앱도 피드백을 받아볼까요? 세 가지 방법을 추천해요.
방법 1: 동료나 지인에게 URL 보내기
가장 쉽고 빠른 방법이에요. 가족이나 친구에게 카카오톡으로 주소를 보내세요. 그리고 "이거 한 번 써보고 솔직하게 어때?"라고 물어보세요.
이때 구체적으로 질문하면 훨씬 좋은 피드백을 받을 수 있어요.
- "첫 화면 열었을 때 뭘 해야 할지 바로 알겠어?"
- "로그인은 헤매지 않고 할 수 있었어?"
- "스마트폰으로 봤을 때 불편한 점 없었어?"
방법 2: 내가 직접 모바일로 써보기
컴퓨터 화면으로 볼 때와 스마트폰으로 볼 때는 완전히 달라요. 스마트폰 브라우저를 열고 내 앱 주소를 입력해 보세요. 버튼은 누르기 편한지, 글자는 잘 보이는지 하나씩 확인해 보세요.
방법 3: 간단한 설문조사 도구 쓰기
구글 폼(Google Forms) 같은 무료 설문 도구를 이용해 보세요. 사용자가 익명으로 솔직한 의견을 남길 수 있어서 아주 유용해요. "이 앱에서 가장 불편했던 점은?", "추가됐으면 하는 기능이 있나요?" 같은 질문을 3~5개 정도 넣으면 돼요.
피드백이 모이면 분류부터
피드백이 모였다면 이제 분류를 해야 해요. 모든 사람의 말을 다 들어줄 수는 없으니까요.
| 우선순위 | 유형 | 예시 | 대응 |
|---|---|---|---|
| 1순위 | 급한 버그 | "버튼을 누르면 에러가 나요" | 당장 고쳐요 |
| 2순위 | 핵심 불편 | "로그인할 때 화면이 깜빡여요" | 이번 주 안에 고쳐요 |
| 3순위 | 있으면 좋은 기능 | "다크 모드가 있으면 좋겠어요" | 메모해 두고 나중에 해요 |
| 4순위 | 디자인 취향 | "파란색보다는 빨간색이 예뻐요" | 가장 나중으로 미뤄요 |
이렇게 우선순위를 정한 뒤, 6강에서 만들었던 PRD(제품 요구사항 정의서)를 꺼내봐요. 우리가 목표로 했던 '성공 기준'을 만족하는지 점검해요. 가장 핵심적인 기능이 문제없이 돌아간다면, 자랑스럽게 v1.0이라고 부르셔도 돼요.
클로드 코드 터미널에서는 이렇게
이제 모인 피드백을 클로드 코드(Claude Code)에게 전달해서 앱을 고쳐봐요.
터미널을 열고 프로젝트 폴더로 이동해요.
claude를 입력해서 대화창을 열어주세요.
1단계: 피드백을 클로드에게 전달하기
사용자들의 의견을 그대로 클로드에게 전달하면 돼요. 한꺼번에 여러 개를 알려줘도 괜찮아요.
지인들이 앱을 써보고 피드백을 줬어.
1. 스마트폰에서 볼 때 '저장하기' 버튼이 너무 작아서 누르기 힘들대.
모바일 화면일 때는 버튼이 화면 가로 크기에 꽉 차도록 크게 수정해줘.
2. 첫 화면에서 뭘 해야 할지 모르겠다는 의견이 있었어.
메인 화면 상단에 "시작하려면 여기를 눌러주세요" 같은 안내 문구를 추가해줘.
클로드가 파일을 분석하고 코드를 뚝딱뚝딱 수정해 줄 거예요.
2단계: 로컬에서 확인하기
수정이 끝났다면 로컬 서버를 띄워서 확인해 봐요.
클로드 코드 대화창에서 !를 맨 앞에 붙이면 터미널 명령어를 바로 실행할 수 있어요.
# 로컬 개발 서버를 띄워서 수정 결과를 확인해요
# (13강에서 배웠던 명령어예요)
! npm run dev
브라우저에서 localhost:3000에 접속하면 수정된 화면을 바로 확인할 수 있어요.
스마트폰 화면처럼 보려면, 브라우저에서 F12 키를 누르고 모바일 미리보기 아이콘을 클릭하세요.
3단계: 수정 사항을 세상에 반영하기
로컬에서 화면을 확인해보니 버튼이 시원하게 커졌어요. 이제 이 변경 사항을 전 세계에 반영할 차례예요. 버셀과 연결된 깃허브로 코드를 보내면 끝이에요.
# 방금 수정한 모든 파일을 반영할 준비를 해요
! git add .
# 어떤 부분을 수정했는지 이름표를 붙여서 포장해요
! git commit -m "v1.1 모바일 버튼 크기 개선 + 안내 문구 추가"
# 포장된 코드를 인터넷에 있는 깃허브로 쏘아 올려요
! git push
이 세 개의 명령어만 입력하면 우리의 임무는 끝이에요. 이제 1~2분 정도 커피를 마시고 돌아오면 돼요. 버셀이 깃허브의 변경 사항을 눈치채고, 자동으로 새로운 버전을 배포해 두었을 거예요.
4단계: 피드백을 또 받고, 또 고치기
한 번 고쳤다고 끝이 아니에요. 수정된 앱을 다시 지인에게 보여주고, 또 피드백을 받아요. 이 과정을 반복하면 앱이 점점 좋아져요.
지난번에 고친 모바일 버튼 크기, 지인들한테 다시 보여줬더니 이번엔 괜찮대.
근데 새로 발견된 문제가 있어.
로그인 후 첫 화면으로 안 돌아가고 빈 페이지가 뜬대.
로그인 성공 후에 메인 페이지로 자동 이동하도록 고쳐줘.
이것이 바로 피드백 -> 수정 -> 재배포 -> 피드백의 순환 고리예요. 프로 개발자들도 매일 이 과 정을 반복해요. 여러분은 이미 프로와 같은 방식으로 일하고 있는 거예요.
PART 4를 마치며
축하해요! 이것으로 PART 4의 모든 과정이 끝났어요. 우리가 PART 4에서 무엇을 해냈는지 표로 정리해 볼게요.
| 강의 | 제목 | 핵심 내용 | 우리의 달성 목표 |
|---|---|---|---|
| 15강 | 디버깅과 오류 해결 | 에러 메시지 읽기, 클로드에게 물어보기 | 붉은 에러 화면을 두려워하지 않기 |
| 16강 | 세상에 공개하기 | 버셀 배포, 환경 변수, 자동 배포 | 내 앱에 진짜 인터넷 주소(URL) 만들기 |
| 17강 | 피드백과 개선 | 피드백 수집, 우선순위 분류, 재배포 | 사용자 반응을 듣고 앱을 고쳐서 재배포하기 |
우리는 이제 기획부터 코딩, 에러 해결, 배포, 그리고 개선까지. 소프트웨어가 만들어지는 전체 한 바퀴를 모두 경험했어요. 코딩을 1줄도 몰랐던 우리가 해낸 일이에요. 정말 대단하지 않나요?
잠깐, 우리가 걸어온 길을 돌아보면
PART 1에서 바이브 코딩이 뭔지 알았어요. PART 2에서 클로드 코드를 설치하고 기획 서를 만들었어요. PART 3에서 진짜 코드를 만들고 화면을 그렸어요. 그리고 PART 4에서 에러를 고치고, 세상에 공개하고, 사용자 피드백으로 앱을 진화시켰어요.
이 여정을 거치면서 여러분은 이미 네이티브 바이브 코더가 되었어요. 코드를 직접 쓰지 않아도, AI와 대화하면서 소프트웨어를 만들 수 있는 사람이요.
다음은 PART 5: 실전과 확장
다음 PART 5에서는 '실전과 확장'을 다뤄요. 지금까지 만든 서비스를 더 진짜같이, 더 훌륭하게 다듬는 실전 팁을 배울 거예요.
- 18강: 디자인 레벨업 — AI가 만든 티를 벗기고 프로 수준의 UI로 업그레이드하기
- 19강: 자동화 — 매일 반복하는 귀찮은 작업을 컴퓨터에게 맡기기
- 20강: 모바일 앱 — 앱스토어 없이 내 웹사이트를 폰에 설치할 수 있게 만들기
PART 4까지가 "첫 번째 앱을 세상에 내놓는 여정"이었다면, PART 5는 "만든 서비스를 진짜 쓸 수 있는 수준으로 키우는 여정"이에요. 기대하셔도 좋아요.
이번 강에서 기억할 것
- 배포는 끝이 아니라 시작이에요. 진짜 서비스는 사용자 손에 들어간 뒤부터 성장해요.
- 지인에게 URL을 보내서 솔직한 피드백을 받아보세요. 구체적으로 질문하면 더 좋은 답이 돌아와요.
- 모든 피드백을 다 들어줄 필요는 없어요. 급한 버그 > 핵심 불편 > 새 기능 > 취향, 이 순서로 처리하세요.
- 클로드가 코드를 고치면,
git push한 줄로 자동 재배포가 완료돼요. 16강의 버셀 마법이 여기서 빛을 발해요. - 버전 번호는 성장의 기록이에요. v1.0에서 v1.1, v1.2로 조금씩 좋아지는 과정을 즐기세요.
이런 분께 추천해요
- 앱을 인터넷에 올리긴 했는데, 그다음 뭘 해야 할지 막막한 분
- 다른 사람이 내 앱을 보고 흉볼까 봐 두려워서 혼자만 간직하고 계신 분
- 피드백을 받아도 어떻게 다시 배포해야 할지 몰라 헤매는 분
참고 링크
▸개정 이력1건
- v12026-04-13초판
이 글이 도움이 되었나요?