오토프로그17강: 피드백과 개선
사용자의 말로 한 번 더 고쳐요
오늘 끝나면 이런 걸 갖게 돼요. 공개한 앱에서 피드백 하나를 골라 고치고, 확인한 뒤 다시 배포하는 흐름을 익혀요.
1단계: 사용자에게 URL 보내기
16강에서 만든 URL(인터넷 주소)을 동료나 지인에게 보내세요. 이 앱을 쓸 사람에게 먼저 부탁하세요. “어때?”보다 아래처럼 구체적으로 물어야 고칠 지점을 찾기 쉽습니다.
- 첫 화면에서 무엇을 해야 할지 알겠나요?
- 로그인하면서 막힌 곳이 있나요?
- 스마트폰에서 누르기 어렵거나 읽기 힘든 곳이 있나요?
내 스마트폰에서도 직접 열어 보세요. 버튼을 누르고 로그인한 뒤, 핵심 기능을 끝까지 써 봅니다.
구글 폼(Google Forms, 온라인 설문 도구)을 써도 좋아요. “가장 불편했던 점”과 “추가됐으면 하는 기능”처럼 질문은 3~5개면 충분합니다.
URL을 보내고 답을 받는 일만 직접 하시면 나머지는 클로드가 해요.
2단계: 고칠 것 하나 고르기
피드백을 받았다고 모두 반영할 필요는 없어요. 식당 주인이 손님 의견을 듣되, 음식이 상했다는 말과 접시 색이 아쉽다는 말을 다르게 다루는 것과 같아요.
| 순서 | 피드백 | 예시 |
|---|---|---|
| 1 | 급한 버그 | 버튼을 누르면 에러가 나요 |
| 2 | 핵심 불편 | 로그인을 마쳐도 빈 화면이 나와요 |
| 3 | 있으면 좋은 기능 | 다크 모드가 있으면 좋겠어요 |
| 4 | 디자인 취향 | 파란색보다 빨간색이 좋아요 |
받은 의견을 클로드에게 보여 주고 분류를 부탁하세요. 아직 코드는 고치지 않게 하는 것이 중요해요.
아래는 사용자에게 받은 피드백이야.[받은 의견을 여기에 붙여 넣기]급한 버그, 핵심 불편, 있으면 좋은 기능, 디자인 취향으로 나눠 줘.6강에서 만든 PRD의 목표와 성공 기준도 함께 확인해 줘.지금은 코드를 고치지 말고, 가장 먼저 고칠 항목 하나와 그 이유만 제안해 줘.확인에 필요한 정보가 부족하면 먼저 질문해 줘.
클로드의 제안이 사용자가 실제로 막힌 지점과 맞는지 읽어 보세요. 이번 실습에서는 가장 중요한 항목 하나만 고릅니다.
3단계: 피드백 하나를 수정해요
문제를 들은 그대로 적고, 원하는 결과와 건드리지 않을 범위를 함께 알려 주세요. 예를 들어 모바일의 저장 버튼이 작다는 의견을 받았다면 이렇게 말합니다.
스마트폰에서 '저장하기' 버튼이 너무 작아 누르기 어렵다는 피드백을 받았어.모바일 화면에서는 버튼이 화면 가로 폭에 맞게 커지도록 고쳐 줘.컴퓨터 화면의 배치와 다른 기능은 건드리지 마.먼저 관련 파일과 수정 계획을 보여 주고 내 확인을 받아 줘.수정한 뒤에는 앱을 열어 내가 확인할 화면과 동작을 알려 줘.
계획에 요청하지 않은 기능이나 파일이 들어가면 빼 달라고 하세요. 내용이 맞으면 “계획대로 고쳐 줘”라고 답합니다.
수정이 끝나면 컴퓨터와 스마트폰에서 같은 기능을 다시 써 보세요. 버튼이 잘 눌리는지, 저장한 내용이 그대로 남는지 확인합니다.
브라우저의 모바일 화면 도구를 쓰고 싶다면 Chrome 개발자 도구 - 모바일 화면으로 보기(Device Mode)를 참고하세요.
4단계: 저장하고 다시 배포해요
수정이 잘 되면 현재 상태를 저장하고 깃허브에 올려 달라고 하세요. 직접 입력할 Git 명령어는 없어요.
방금 고친 기능을 다시 확인해 줘.문제가 없으면 지금 상태를 저장하고 깃허브에 올려 줘.저장 이름에는 수정한 내용을 짧게 적어 줘.비밀번호나 인증 정보가 포함되지 않았는지 먼저 확인하고,실행 전에 어떤 파일을 저장하고 무엇을 할지 보여 줘.
클로드가 보여 주는 파일과 저장 이름을 확인한 뒤 승인하세요. 깃허브 로그인이나 브라우저 권한 승인이 나오면 이것만 직접 하시면 나머지는 클로드가 해요.
버셀(Vercel, 깃허브의 코드를 웹에 배포하는 서비스)이 변경을 감지하면 보통 1~2분 뒤 같은 URL에 새 버전이 나타나요. 공개 주소를 직접 열어 고친 기능을 한 번 더 확인하세요.
배포한 화면이 더 이상할 때만 펼쳐 보세요
버셀 프로젝트 첫 화면의 Production Deployment에서 Instant Rollback을 누르면 직전 배포로 돌아갈 수 있어요. 돌아갈 배포를 고르고 Continue, Confirm Rollback 순서로 승인합니다.
무료 요금제에서는 바로 직전 배포 하나로만 되돌릴 수 있어요. 왼쪽 Deployments 목록에서 해당 배포의 점 세 개(⋮) 메뉴를 열어도 같은 기능이 있습니다.
되돌린 뒤에는 자동 배포가 잠시 꺼져요. 문제를 고친 다음 같은 자리의 Undo Rollback을 누르고, 다시 사용할 배포를 고른 뒤 Confirm까지 눌러야 이후 변경이 반영됩니다.
클로드가 방금 한 수정만 취소하고 싶다면 먼저 변경 내용을 보여 달라고 한 뒤 되돌려 달라고 하세요. 자세한 방법은 Claude Code 공식 문서 - 체크포인트와 되돌리기(/rewind)에서 볼 수 있어요.
5단계: 같은 사람에게 다시 보여 주세요
처음 의견을 준 사람에게 같은 URL을 보내고 문제가 해결됐는지 물어보세요. “버튼이 이제 누르기 편한가요?”처럼 바뀐 부분을 정확히 짚어 묻습니다.
새 문제가 나왔다면 다시 분류하고 하나씩 고치면 돼요. 이 흐름이 피드백 → 수정 → 재배포 → 피드백의 개선 사이클입니다.
식당도 개업한 날의 메뉴를 계속 다듬어요. 앱도 공개한 뒤 사용자의 반응을 보며 좋아집니다.
버전 번호로 변화를 남겨요
작은 수정이 쌓이는 과정을 버전 번호로 남길 수 있어요.
v1.0: 첫 배포v1.1,v1.2: 작은 버그 수정이나 개선v2.0: 큰 기능 추가나 디자인 전면 개편
숫자를 꼭 붙일 필요는 없어요. “한 번 만들고 끝”이 아니라, 확인하면서 고친다는 흐름만 기억하면 됩니다.
디온웍스의 근태관리 앱 DGHR도 같은 과정을 거쳤어요. 처음에는 GPS 출퇴근 버튼이 잘 보이지 않는다는 의견이 나왔고, 버튼 색을 구분해 5분 만에 수정·재배포했습니다.
PART 4를 마치며
15강에서는 오류를 찾고, 16강에서는 서비스를 공개했어요. 이번 강에서는 사용자 반응을 받아 다시 고쳤습니다.
우리는 기획부터 코딩, 에러 해결, 배포, 개선까지 한 흐름으로 경험했어요. 다음 PART 5에서는 지금 만든 서비스를 더 쓰기 편하게 다듬습니다.
이런 분께 추천해요
앱을 공개한 뒤 무엇을 해야 할지 막막한 분께 알맞아요. 받은 의견 가운데 무엇부터 고칠지 어렵거나, 수정과 재배포를 명령어 없이 이어가고 싶은 분도 따라 할 수 있습니다.
참고 링크
- Vercel 배포 가이드 (버셀 공식 문서)
- Vercel 즉시 되돌리기 가이드 (Instant Rollback)
- Chrome 개발자 도구 - 모바일 화면으로 보기(Device Mode)
- Claude Code 공식 문서 - 체크포인트와 되돌리기(/rewind)
- GitHub Issues 가이드 (깃허브로 해야 할 일 관리하기)
- 구글 폼 만들기 가이드 (무료 설문조사 만들기)
다음 강
18강: 디자인 레벨업에서는 원하는 스타일을 구체적으로 설명해 화면을 더 자연스럽게 다듬어요.