[작성자:] 컴맹 집사

  • 배포한 앱, 어떻게 고치지? 컴맹이 정착한 5단계 수정 루틴

    배포한 앱, 어떻게 고치지? 컴맹이 정착한 5단계 수정 루틴

    작성자: 컴맹 집사

    대표 이미지: 배포한 앱을 처음 고친 사례. 3시간 만에 이름이 “왕립 개집사협회”로 바뀌었다 (출처: 앱의 시기별 화면을 직접 캡처해 비교 이미지로 제작)

    이 글에서 얻는 것

    • 이런 분께 이미 배포한 앱을 안전하게 고치고 싶은 분
    • 핵심 답 한 가지만 정한다 → AI에게 범위를 정해 요청 → 내 컴퓨터에서 먼저 확인 → 커밋·푸시 → 실제 휴대폰으로 확인. 이 다섯 단계로 고친다
    • 바로 쓰는 팁 잘못 고쳐 화면이 망가졌다면 Vercel Deployments에서 잘 되던 이전 배포로 되돌려 두고 천천히 고치자

    배포 전에는 앱을 고쳐도 나만 보면 그만이었다. 배포한 뒤로는 사정이 달라졌다. 내가 푸시하는 순간, 링크를 받은 친구들이 보는 앱도 함께 바뀐다.

    첫 배포 날 친구들이 알려 준 문제는 세 가지였다. 휴대폰에서 글자가 작다, 뒤로 가기를 누르면 처음으로 돌아간다, 그림이 깨진다. 그림 문제는 그날 바로 고쳤고, 나머지 두 가지를 고치면서 배포한 앱을 수정하는 나만의 순서가 생겼다.

    수정 전에 알아 둔 원칙 하나

    AI에게 먼저 물었다. “이미 배포한 앱을 고칠 때 주의할 점이 뭐야?” 여러 답 중 가장 중요한 건 이것이었다.

    인터넷에 있는 앱을 직접 고치는 게 아닙니다. 내 컴퓨터의 파일을 고친 뒤, 그걸 다시 올리는 것입니다.

    당연한 말 같지만 처음엔 헷갈렸다. Vercel 화면 어딘가에서 글자를 고칠 수 있을 거라고 생각했기 때문이다. Vercel은 파일을 보여 주는 곳이지 고치는 곳이 아니다. (출처: Vercel 문서, 배포 개요) 고치는 곳은 언제나 내 컴퓨터의 index.html이다.

    정착한 5단계

    1단계. 한 가지만 정한다

    “오늘은 글자 크기만 고친다.” 수정할 것을 하나만 정한다. 여러 가지를 한꺼번에 고치다 앱이 망가졌던 경험 때문이다.

    2단계. AI에게 범위를 정해 요청한다

    글자 크기 문제는 이렇게 요청했다.

    휴대폰에서 질문 글자가 너무 작다는 의견이 있었어.
    질문 문장과 보기 버튼 글자를 휴대폰에서 읽기 편하게 키워 줘.
    CSS 부분만 고치고, 다른 기능은 건드리지 마. (MDN 웹 문서, CSS: https://developer.mozilla.org/en-US/docs/Web/CSS)
    바뀐 부분만 보여 줘.
    

    마지막 줄 “바뀐 부분만 보여 줘”는 나중에 추가한 요령이다. 파일 전체를 다시 받으면 어디가 바뀌었는지 알기 어렵지만, 바뀐 부분만 받으면 그 줄을 찾아서 교체하면 된다. 다만 초보자에게는 찾아서 교체하는 것도 실수가 잦아서, 자신이 없을 때는 “전체 코드를 다시 줘”라고 했다.

    3단계. 내 컴퓨터에서 먼저 확인한다

    파일을 저장하고 브라우저에서 연다. 크롬에서 F12를 누르고 휴대폰 모양 아이콘(기기 툴바)을 누르면 휴대폰 화면 크기로 볼 수 있다. 작은 화면 기종도 골라서 확인했다.

    이 기능을 알고 나서 “컴퓨터에서는 괜찮았는데 휴대폰에서는 이상해” 하는 일이 크게 줄었다.

    4단계. 커밋하고 푸시한다

    GitHub Desktop에서 커밋 메시지를 적는다. 예: 질문과 보기 글자 크기 키움. 커밋한 뒤 푸시한다.

    5단계. 배포 완료를 확인하고 실제 휴대폰으로 연다

    Vercel의 Deployments 탭에서 새 배포 옆에 Ready가 뜨는지 본다. 보통 1분 안쪽이었다. 그다음 실제 휴대폰에서 링크를 열고 새로고침한다.

    이 다섯 단계에 익숙해지면 10분도 걸리지 않는다.

    두 번째 수정: 뒤로 가기 문제

    뒤로 가기 문제는 글자 크기보다 까다로웠다. AI는 두 가지 방법을 알려 줬다.

    이용 안내를 펼친 앱 첫 화면
    같은 날 오후 두 번째로 고쳐, 이용 순서와 자주 묻는 질문을 펼쳐 볼 수 있게 한 화면
    출처: 왕립 개집사협회 앱 2026년 9월 19일 버전 화면, 직접 캡처
    • 방법 A: 질문마다 인터넷 주소 끝을 바꿔서, 브라우저의 뒤로 가기가 이전 질문으로 가도록 만든다.
    • 방법 B: 화면 안에 “이전 질문” 버튼을 따로 만든다.

    방법 A가 더 완벽하다고 했지만 설명을 들어도 잘 이해되지 않았다. 그래서 초보자에게 쉬운 방법 B를 먼저 적용했다. 질문 2번부터 왼쪽 위에 “← 이전” 버튼이 보이고, 누르면 앞 질문으로 돌아가면서 앞에서 고른 답도 취소되게 했다.

    완벽한 해결은 아니었다. 휴대폰의 뒤로 가기 버튼을 누르는 사람은 여전히 처음으로 돌아간다. 그래서 시작 화면에 “진행 중에는 화면 안의 이전 버튼을 눌러 주세요”라는 짧은 안내도 넣었다. 방법 A는 나중에 웹툰 회차를 만들면서 결국 배우게 되는데, 그 이야기는 뒤에서 하겠다.

    잘못 고쳤을 때: Vercel에서 되돌리기

    어느 날은 결과 설명 문구를 고치고 푸시했는데, 결과 화면이 통째로 하얗게 나왔다. 따옴표 하나가 빠져서 JavaScript 전체가 멈춘 것이었다. 친구들이 보고 있을지도 모르는 상황이라 마음이 급했다.

    이럴 때 쓸 수 있는 방법은 두 가지였다.

    1. Vercel에서 이전 배포로 되돌리기
    Deployments 목록에서 잘 되던 이전 배포를 찾아 오른쪽 점 세 개(⋯) 메뉴를 누르면 이전 배포로 되돌리는 메뉴(Instant Rollback 등)가 있다. 누르면 몇 초 만에 사이트가 그 버전으로 돌아간다. 급한 불을 끄는 데 좋았다.

    2. GitHub에서 커밋 되돌리고 다시 푸시하기
    GitHub Desktop의 History에서 문제 커밋을 Revert 하고 푸시한다. 내 파일과 인터넷의 앱이 같은 상태로 맞춰진다는 장점이 있다.

    나는 1번으로 급한 불을 끄고, 차분히 원인을 고친 뒤 새로 푸시했다. 주의할 점은 Vercel에서 되돌려도 내 컴퓨터 파일에는 여전히 문제가 있다는 것이다. 되돌린 것으로 끝내지 말고, 반드시 파일을 고쳐서 다시 푸시해야 한다.

    수정할 때 헷갈렸던 것

    Q. 고쳤는데 휴대폰에서 그대로다.
    대부분 캐시 문제였다. 새로고침하거나 잠시 뒤 다시 열면 된다. 그래도 그대로라면 Vercel 배포가 끝났는지, 푸시를 했는지 확인하자.

    Q. 푸시했는데 Vercel에 새 배포가 안 생긴다.
    GitHub 웹사이트에 커밋이 올라갔는지 먼저 본다. 올라갔는데도 배포가 안 생기면 Vercel의 Settings → Git에서 연결된 저장소가 맞는지 확인한다.

    Q. 고칠 게 많은데 하나씩 하려니 느리다.
    커밋은 하나씩 따로 하고, 푸시는 여러 개를 모아 한 번에 해도 된다. 대신 푸시 전에 전부 확인해야 한다.

    이렇게 조심해도 피할 수 없는 게 있었다. 배포 자체가 실패하는 오류다. 빨간 글씨로 가득한 화면을 처음 봤을 때의 이야기를 다음 글에 적었다.


    이전 글: 내 앱에 진짜 인터넷 주소가 생긴 날, 첫 배포 성공기
    다음 글: 빨간 글씨 가득한 배포 오류, 겁먹지 않고 해결한 순서

  • 내 앱에 진짜 인터넷 주소가 생긴 날, 첫 배포 성공기

    내 앱에 진짜 인터넷 주소가 생긴 날, 첫 배포 성공기

    작성자: 컴맹 집사

    대표 이미지: 배포 첫날 직접 열어 본 앱 화면 (출처: 직접 캡처한 화면(2026년 9월 19일))

    이 글에서 얻는 것

    • 이런 분께 처음으로 앱을 인터넷에 배포해 보려는 분
    • 핵심 답 배포한 뒤에야 보이는 문제가 있다. 휴대폰으로 직접 열어 보고 친구들 반응을 받으면서 고칠 곳을 찾았다
    • 바로 쓰는 팁 푸시한 뒤에는 Vercel 배포 완료(Ready), 실제 휴대폰에서 새로고침 후 확인, 고치지 않은 부분이 망가지지 않았는지까지 점검하자

    https://kba-butler-app.vercel.app

    Vercel 축하 화면 아래에 이 주소가 떠 있었다. 별것 아닌 영어와 숫자 조합인데 한참을 쳐다봤다. 이 주소를 누르면 전 세계 어디에서든 왕립 개집사협회 앱이 열린다는 뜻이었다.

    코딩을 한 줄도 모르던 사람이 AI와 함께 앱을 만들기 시작한 지 일주일쯤 지났을 때였다.

    제일 먼저 한 일: 휴대폰으로 열어 보기

    컴퓨터 화면으로 주소를 열어 보는 건 이미 해 봤다. 진짜 확인은 휴대폰이었다. 친구들도 컴퓨터가 아니라 휴대폰으로 열 테니까.

    주소를 카카오톡 “나에게 보내기”로 보내고 휴대폰에서 눌렀다. 몇 초 뒤 시작 화면이 떴다. 폐하 정보를 입력하고, 질문 일곱 개를 넘기자 결과로 “발바닥 궁정대신”이 나왔다.

    내 컴퓨터가 아니라 인터넷 어딘가에서 내 앱이 돌아가고 있었다. AI가 처음 코드를 만들어 줬을 때는 “신기하다”였고, 이번에는 “진짜 만들었다”였다.

    친구들에게 링크를 보냈다

    강아지를 키우는 친구 몇 명에게 링크를 보냈다. “강아지가 왕이고 우리가 집사인 앱 만들어 봤어. 집사 작위증 한번 받아 봐.”

    벤치에 앉아 휴대폰을 보는 두 친구
    친구들에게 링크를 보내고 반응을 기다렸다
    사진: chikilino / Pixabay

    반응은 생각보다 좋았다. 결과 화면을 캡처해서 보내 주는 친구도 있었다. “나 간식 협상형 집사래ㅋㅋ 너무 정확한데?” 같은 답장이 오자 괜히 뿌듯했다.

    칭찬만 온 건 아니었다. 오히려 이날 받은 불편 신고가 더 값졌다.

    배포하고 나서야 알게 된 문제들

    1. 휴대폰에서 글자가 너무 작다

    내 휴대폰에서는 괜찮았는데, 화면이 작은 휴대폰을 쓰는 친구는 질문 글자가 너무 작아서 확대해야 읽을 수 있다고 했다. 컴퓨터 창을 줄여서 확인했던 것과 실제 휴대폰은 달랐다.

    2. 뒤로 가기를 누르면 처음으로 돌아간다

    질문 5번쯤에서 답을 잘못 눌러 휴대폰의 뒤로 가기를 눌렀더니 앱이 처음부터 다시 시작됐다고 했다. 이 앱은 한 페이지 안에서 화면만 바꾸는 방식이라, 브라우저의 뒤로 가기가 “이전 질문”이 아니라 “이전 사이트”로 가 버린 것이다.

    3. 사진이 안 나오는 친구가 있다

    작위증 화면에 넣어 둔 기본 강아지 그림이 친구 휴대폰에서는 깨진 아이콘으로 나왔다. 내 컴퓨터에서는 멀쩡했는데 말이다.

    AI에게 물어보니 원인은 뜻밖이었다. 코드에는 그림 파일 이름을 dog.png로 적어 두었는데, 실제 파일 이름은 Dog.png였다. 윈도우는 대문자와 소문자를 구분하지 않아서 내 컴퓨터에서는 문제가 없었다. 하지만 인터넷 서버는 대소문자를 구분하기 때문에 파일을 찾지 못한 것이다.

    파일 이름을 전부 소문자로 바꾸고 다시 푸시하자 해결됐다. 이 일 이후로 나는 파일 이름을 영어 소문자와 하이픈(-)만 써서 짓는다.

    고쳤는데 친구 화면은 그대로였다

    글자 크기를 키우고 푸시한 뒤 친구에게 “다시 해 봐”라고 했다. 친구는 “똑같은데?”라고 답했다.

    Vercel의 Deployments 화면에는 새 배포가 분명히 완료되어 있었다. AI는 캐시(cache) 때문일 수 있다고 했다. (출처: MDN 웹 문서, HTTP 캐시) 브라우저가 속도를 위해 예전에 받은 파일을 저장해 두고, 그걸 다시 보여 주는 것이다.

    • 휴대폰에서는 페이지를 새로고침하거나, 잠시 뒤 다시 열어 보면 대부분 해결된다.
    • 컴퓨터에서는 Ctrl + F5(강력 새로고침)를 누르면 새 파일을 받아 온다.

    친구가 새로고침을 하자 바뀐 화면이 나왔다. 그 뒤로 앱을 고칠 때마다 “새로고침해 봐”라는 말을 붙이게 됐다.

    배포 첫날의 체크리스트

    이날 겪은 일을 바탕으로, 푸시하기 전과 후에 확인할 목록을 만들었다. 지금도 쓰고 있다.

    푸시하기 전
    – [ ] 내 컴퓨터에서 처음부터 끝까지 한 번 해 봤는가
    – [ ] 브라우저 창을 휴대폰 크기로 줄여서 확인했는가
    – [ ] 새로 추가한 파일 이름이 영어 소문자인가
    – [ ] 커밋 메시지에 무엇을 바꿨는지 적었는가

    푸시한 뒤
    – [ ] Vercel Deployments에서 배포가 완료(Ready)됐는가
    – [ ] 실제 휴대폰으로 열어 봤는가 (새로고침 후)
    – [ ] 이번에 고친 부분이 반영됐는가
    – [ ] 고치지 않은 다른 부분이 망가지지 않았는가

    이날 배운 것

    배포는 끝이 아니라 시작이었다. 내 컴퓨터 안에서는 나만 쓰니까 보이지 않던 문제가, 다른 사람 손에 들어가자 하나씩 드러났다. 화면 크기, 뒤로 가기, 파일 이름, 캐시. 배포하지 않았다면 몰랐을 것들이다.

    배포 전의 긴장감도 사라졌다. 문제가 생겨도 고쳐서 다시 푸시하면 된다는 걸 알았기 때문이다. 앱을 완벽하게 만든 다음 배포하려 했다면 아직도 내 컴퓨터 안에만 있었을 것이다.

    이제 남은 과제는 친구들이 알려 준 문제를 고치는 일이었다.

    배포 후 반응으로 정한 다음 계획

    1. 휴대폰 글자 크기와 여백 다듬기
    2. 질문 화면에 “이전 질문” 버튼 넣기
    3. 파일 이름 규칙 정리하기
    4. 강아지 사진을 직접 넣을 수 있게 하기
    5. 결과를 이미지로 저장하고 공유하기

    앞의 세 가지는 바로 고칠 수 있는 것이고, 뒤의 두 가지는 기능 추가다. 처음 기획 때 만든 “나중에 할 것” 목록과 거의 겹쳤다. 사용자가 원하는 것과 내가 처음에 떠올린 것이 크게 다르지 않았다는 뜻이라 조금 안심이 됐다.

    배포 첫날 받은 질문들

    친구들이 물어본 것 중 기억에 남는 것도 적어 둔다. “이거 앱스토어에 있어?”, “우리 엄마 강아지도 해 보라고 보내도 돼?”, “사진은 어디에 저장돼?” 마지막 질문은 나중에 사진 업로드 기능을 만들 때 중요한 기준이 됐다. 사진이 서버로 올라가지 않고 휴대폰 안에서만 처리되도록 만든 이유가 여기에 있다.

    처음 배포를 앞둔 분께

    • 첫 배포는 완성본이 아니어도 된다. 돌아가기만 하면 올려 보자.
    • 반드시 실제 휴대폰으로 열어 보자. 컴퓨터 화면과 다르다.
    • 파일 이름은 영어 소문자로. 윈도우에서 괜찮아도 서버에서는 문제가 된다.
    • 고쳤는데 그대로라면 새로고침부터 해 보자.
    • 믿을 만한 친구 몇 명에게 먼저 보내 보자. 가장 좋은 테스터다.

    이전 글: 깃허브와 Vercel 연결하기, 컴맹이 막혔던 곳 그대로 공개
    다음 글: 배포한 앱, 어떻게 고치지? 컴맹이 정착한 5단계 수정 루틴

    처음부터 따라가기: 코딩 1도 모르는 집사가 강아지 때문에 앱을 만들게 된 사연

  • 깃허브와 Vercel 연결하기, 컴맹이 막혔던 곳 그대로 공개

    깃허브와 Vercel 연결하기, 컴맹이 막혔던 곳 그대로 공개

    작성자: 컴맹 집사

    대표 이미지: Vercel 프로젝트 설정에서 확인한 GitHub 연결 항목 (출처: 직접 캡처한 화면(2026년 9월 18일))

    이 글에서 얻는 것

    • 이런 분께 GitHub 저장소를 Vercel에 연결하다 막힌 분
    • 핵심 답 저장소가 목록에 안 보이면 대부분 권한 문제다. GitHub의 Repository access에서 그 저장소를 허용하면 목록에 나타난다
    • 바로 쓰는 팁 배포한 주소가 404라면 index.html이 어느 폴더에 있는지부터 확인하자

    설명만 들었을 때는 “GitHub 저장소를 Vercel에서 불러와서 Deploy 버튼을 누르면 끝”이었다. 실제로는 한 시간 가까이 걸렸다. 버튼을 누르는 시간보다 화면 앞에서 멈춰 있던 시간이 훨씬 길었다.

    이 글은 매끈한 설명서가 아니라, 내가 멈칫했던 지점까지 담은 기록이다. 같은 곳에서 멈춘 분이 있다면 여기서 넘어갈 수 있으면 좋겠다.

    시작 전 준비 상태

    • GitHub 계정이 있다.
    • 강아지 앱 저장소(kba-butler-app)를 GitHub에 푸시해 둔 상태다.
    • 저장소 맨 바깥에 index.html 파일이 있다.

    마지막 항목이 나중에 중요해진다. 기억해 두자.

    1단계. Vercel 가입, GitHub로 로그인

    vercel.com에 들어가 Sign Up을 누르고, 가입 방법 중 Continue with GitHub를 골랐다.

    GitHub 화면에서 “Vercel이 당신의 GitHub 계정에 접근하도록 허락하겠습니까?”라는 안내가 나왔다. 여기서 한 번 멈칫했다. 내 계정을 남에게 넘겨주는 건가 싶었다.

    AI에게 물어보니, 이건 Vercel이 내 저장소 파일을 읽어 갈 수 있도록 허락하는 절차였다. 이 허락이 있어야 Vercel이 GitHub에서 파일을 가져가 배포할 수 있다. (출처: Vercel 문서, Git 연동) 비밀번호를 넘겨주는 것과는 다르다. Authorize를 눌러 진행했다.

    가입 중에 사용 목적을 묻는 화면이 나오면, 개인 프로젝트는 Hobby를 고르면 된다.

    2단계. 새 프로젝트 만들기

    로그인하면 Vercel 대시보드(관리 화면)가 나온다. Add New… → Project를 누른다. 그러면 Import Git Repository라는 제목 아래에 내 GitHub 저장소 목록이 나와야 한다.

    첫 번째 막힘: 저장소가 목록에 없다

    목록이 비어 있었다. 분명 GitHub에 올렸는데 kba-butler-app이 보이지 않았다.

    원인은 권한이었다. Vercel이 GitHub에 설치될 때 “모든 저장소”가 아니라 “선택한 저장소”에만 접근하도록 설정되었거나, 아직 설치가 덜 된 상태였다.

    해결 방법은 이랬다.

    1. 저장소 목록 아래쪽의 Adjust GitHub App Permissions(또는 GitHub 설정 링크)를 누른다.
    2. GitHub 화면에서 Repository access 항목을 찾는다.
    3. All repositories를 고르거나, Only select repositories에서 kba-butler-app을 추가한다.
    4. Save를 누르고 Vercel로 돌아온다.

    돌아오니 kba-butler-app이 목록에 나타났다. 옆의 Import 버튼을 눌렀다.

    초보자 팁: 저장소가 안 보이면 대부분 권한 문제다. 저장소가 비공개(Private)여도 권한만 주면 Vercel에서 불러올 수 있다.

    3단계. 프로젝트 설정 화면

    Import를 누르면 설정 화면이 나온다. 모르는 항목이 여럿 있었다. 강아지 앱처럼 HTML 파일 위주의 단순한 웹앱 기준으로 정리하면 이렇다.

    항목 뜻 내가 한 설정
    Project Name 프로젝트 이름. 주소에도 쓰인다 kba-butler-app 그대로
    Framework Preset 어떤 개발 도구로 만든 앱인지 Other
    Root Directory 앱 파일이 들어 있는 폴더 위치 ./ 그대로
    Build and Output Settings 앱을 조립(빌드)하는 방법 건드리지 않음
    Environment Variables 비밀 설정값 비워 둠

    Framework Preset에서 두 번째로 멈칫했다. Next.js, React 같은 낯선 이름이 가득했다. AI에게 물어보니 이건 React 같은 개발 도구(프레임워크)를 썼을 때 고르는 항목이다. index.html 하나로 만든 앱은 Other를 고르면 된다. Vercel이 자동으로 Other를 골라 주는 경우도 있다.

    Project Name은 주소가 된다는 걸 나중에 알았다. kba-butler-app으로 두면 주소가 kba-butler-app.vercel.app이 되는데, 이미 누가 쓰는 이름이면 뒤에 글자가 더 붙는다. 앱 이름을 정했다면 여기서 바꿔도 된다.

    4단계. Deploy

    설정을 마치고 Deploy를 눌렀다. 화면에 진행 기록이 주르륵 올라가고, 몇십 초 뒤 축하 화면이 떴다. 폭죽 효과와 함께 앱의 작은 미리보기가 보였다.

    이 순간의 이야기는 다음 글에 따로 적었다. 여기서는 연결 과정에서 한 번 더 막혔던 부분만 적는다.

    두 번째 막힘: 주소를 열었는데 404가 뜬다

    사실 첫 시도에서 나는 축하 화면 다음에 404: NOT_FOUND를 봤다. 배포는 성공했다는데 페이지가 없다니.

    원인은 파일 위치였다. 저장소를 만들 때 kba-butler-app 폴더 안에 app이라는 폴더를 만들고 그 안에 index.html을 넣어 뒀던 것이다. Vercel은 저장소 맨 바깥에서 index.html을 찾는데, 거기엔 아무것도 없었다.

    해결 방법은 두 가지였다.

    • index.html을 저장소 맨 바깥으로 옮기고 다시 커밋·푸시하기
    • 또는 Vercel 설정에서 Root Directory를 app으로 지정하기

    나는 첫 번째 방법을 택했다. 구조가 단순할수록 나중에 덜 헷갈릴 것 같았다. 푸시하자 Vercel이 자동으로 다시 배포했고, 이번에는 앱이 제대로 열렸다.

    초보자 팁: 배포 후 404가 뜨면 가장 먼저 index.html이 어디에 있는지 확인하자. 파일 이름의 대소문자(Index.html)도 문제가 될 수 있다.

    연결 후에 확인한 것

    • Deployments 탭: 배포 기록이 쌓인다. 푸시할 때마다 한 줄씩 늘어난다.
    • Domains: 내 앱의 주소가 적혀 있다.
    • Settings → Git: 어느 GitHub 저장소와 연결되어 있는지 나온다.

    그리고 GitHub Desktop에서 문구 하나를 고쳐 푸시해 봤다. 1분쯤 지나자 Deployments에 새 배포가 생겼고, 주소를 새로고침하니 바뀐 문구가 보였다. 자동 배포가 실제로 동작하는 걸 확인한 순간이었다.

    처음 배포한 앱의 첫 화면
    연결을 마치고 처음 배포한 앱. 주소를 열면 이 화면이 떴다
    출처: 왕립 개집사협회 앱 2026년 9월 19일 버전 화면, 직접 캡처

    이전 글: Vercel이 뭐길래 내 앱에 주소가 생겼을까? 배포 서비스 쉬운 설명
    다음 글: 내 앱에 진짜 인터넷 주소가 생긴 날, 첫 배포 성공기

  • Vercel이 뭐길래 내 앱에 주소가 생겼을까? 배포 서비스 쉬운 설명

    Vercel이 뭐길래 내 앱에 주소가 생겼을까? 배포 서비스 쉬운 설명

    작성자: 컴맹 집사

    대표 이미지: 배포 서비스는 이런 서버를 대신 운영해 준다 (사진: rohitdarbari / Pixabay)

    이 글에서 얻는 것

    • 이런 분께 내 컴퓨터에서만 열리는 앱을 친구도 열 수 있게 하고 싶은 분
    • 핵심 답 Vercel은 GitHub 저장소의 파일을 가져가 인터넷 주소가 있는 웹사이트로 만들어 주는 서비스다. 흐름은 저장(내 컴퓨터) → 푸시(GitHub) → 배포(Vercel)
    • 바로 쓰는 팁 GitHub와 한 번 연결해 두면 푸시할 때마다 Vercel이 파일을 가져가 다시 배포한다

    강아지 앱을 친구에게 처음 보여 주려던 날, 나는 카카오톡으로 index.html 파일을 보냈다.

    돌아온 답은 “이거 어떻게 열어?”였다. 휴대폰에서 파일을 눌러 보니 코드가 글자 그대로 보이거나 아예 열리지 않았다. 내 컴퓨터에서는 멀쩡히 돌아가던 앱이 친구 손에서는 알 수 없는 문서가 되어 있었다.

    그때 필요한 게 링크라는 걸 알았다. 누르면 바로 열리는 인터넷 주소. 그 주소를 만들어 주는 서비스가 Vercel(버셀)이었다.

    “배포”라는 말부터 이해해야 했다

    AI는 “Vercel로 배포하세요”라고 했다. 배포라니, 전단지를 나눠 주는 그 배포인가 싶었다.

    개발에서 배포(deploy)는 내 컴퓨터에 있는 앱을 인터넷에 올려서, 누구나 주소로 접속할 수 있게 만드는 일이다. (출처: Vercel 문서, 배포 개요)

    • 배포 전: 앱이 내 컴퓨터 안에만 있다. 나만 열 수 있다.
    • 배포 후: 앱이 인터넷 서버에 있다. 주소만 알면 누구나 열 수 있다.

    “배포한다”는 말은 가게를 여는 것과 비슷하다. 집 부엌에서만 만들던 음식을 가게에 내놓고 손님이 찾아오게 하는 것이다.

    그럼 서버가 필요한 거 아닌가?

    배포 설명을 듣자마자 겁이 났다. 인터넷에 올리려면 서버가 필요하고, 서버는 비싸고 어렵다고 들었기 때문이다.

    AI의 설명은 이랬다.

    서버를 직접 빌려서 설정할 수도 있지만, Vercel 같은 서비스는 그 과정을 대신해 줍니다. 파일만 주면 알아서 인터넷에 올리고 주소를 만들어 줍니다.

    그러니까 Vercel은 서버 관리를 대신해 주는 배포 서비스다. 나는 서버가 어디 있는지, 어떻게 켜고 끄는지 몰라도 된다.

    내가 이해한 Vercel

    한 줄로 정리하면 이렇다. Vercel은 GitHub에 있는 앱 파일을 가져가서 (출처: Vercel 문서, Git 연동) 인터넷 주소가 있는 웹사이트로 만들어 주는 서비스다.

    Vercel과 GitHub 연결 승인 완료 화면
    Vercel에 GitHub 계정으로 로그인하고 연결을 승인한 화면
    출처: 직접 캡처한 화면(2026년 9월 18일)

    여기서 GitHub가 다시 등장한다. 앞 글에서 GitHub가 필요한 진짜 이유가 따로 있다고 했는데, 바로 이것이다. Vercel은 GitHub 저장소와 연결되어 파일을 가져간다.

    전체 흐름은 이렇게 그려 볼 수 있다.

    내 컴퓨터 (파일 수정·저장)
        ↓ 커밋 + 푸시
    GitHub (파일과 기록 보관)
        ↓ 자동으로 가져감
    Vercel (인터넷에 올리고 주소 생성)
        ↓
    친구 휴대폰에서 링크로 접속
    

    이 그림을 보니 지금까지 배운 것이 하나로 이어졌다. 저장은 내 컴퓨터, 푸시는 GitHub, 배포는 Vercel.

    왜 Vercel이었나

    배포 서비스는 Vercel 말고도 여럿 있다. Netlify, GitHub Pages, Cloudflare Pages 같은 곳들이다. 내가 Vercel을 고른 이유는 다음과 같다.

    • GitHub 계정으로 바로 가입할 수 있다. 계정을 새로 만들 필요가 없었다.
    • 개인 프로젝트는 무료(Hobby 요금제)로 쓸 수 있다.
    • 푸시하면 자동으로 다시 배포된다. 따로 업로드할 필요가 없다.
    • 화면이 비교적 단순해서 초보자도 따라가기 쉬웠다.

    다른 서비스도 비슷한 기능을 제공하니, 이미 익숙한 곳이 있다면 그걸 써도 된다. 중요한 건 GitHub → 배포 서비스 → 링크라는 흐름을 이해하는 것이다.

    참고: Vercel의 무료 Hobby 요금제는 개인적이고 비상업적인 용도를 위한 것이다. 나중에 앱으로 수익을 내게 되면 요금제 조건을 다시 확인해야 한다. 요금제와 조건은 바뀔 수 있으니 시작할 때 공식 사이트에서 확인하자.

    자동 배포가 가장 놀라웠다

    Vercel에서 가장 신기했던 건 자동 배포다. 한 번 연결해 두면, GitHub에 푸시할 때마다 Vercel이 알아서 새 버전을 인터넷에 올린다.

    • 질문 문구를 고친다 → 저장 → 커밋 → 푸시
    • 1분쯤 뒤 → 친구가 보는 앱도 바뀌어 있다

    앞 글에서 “푸시에는 결과가 따른다”고 쓴 이유가 이것이다. 배포를 연결한 뒤로는 푸시가 곧 실제 서비스의 변경이 된다. 그래서 푸시하기 전에 내 컴퓨터에서 한 번 더 확인하는 습관이 생겼다.

    배포 전에 걱정했던 것들

    실제로 해 보기 전에 AI에게 물어봤던 질문들을 정리해 둔다. 같은 고민을 하는 분께 도움이 될 것 같다.

    Q. 주소는 어떻게 생겨?
    기본으로 프로젝트이름.vercel.app 형태의 주소가 무료로 생긴다. 원하면 따로 산 도메인을 연결할 수도 있다.

    Q. 내 컴퓨터를 꺼도 앱이 열려?
    열린다. 앱은 Vercel의 서버에 올라가 있으니 내 컴퓨터와는 상관없다.

    Q. 잘못 올리면 되돌릴 수 있어?
    Vercel은 배포 기록을 남기고, 이전 배포로 되돌리는 기능도 있다. GitHub에서 이전 커밋으로 되돌려 다시 푸시하는 방법도 있다.

    Q. 코드를 전혀 몰라도 설정할 수 있어?
    HTML 파일 위주의 단순한 웹앱은 버튼 몇 번이면 된다. 실제로 막혔던 부분은 다음 글에 그대로 적었다.

    배포 서비스 없이는 안 되나

    처음에는 “카카오톡으로 파일을 보내면 되지 않나?”, “구글 드라이브에 올려서 링크를 주면 되지 않나?”라고도 생각했다. 해 보니 둘 다 안 됐다. 휴대폰은 HTML 파일을 앱처럼 실행해 주지 않고, 드라이브 링크는 파일을 내려받는 링크라서 앱이 열리지 않았다.

    웹앱이 앱처럼 동작하려면 누군가 그 파일을 웹 주소로 제공해야 한다. 이 일을 호스팅이라고 부르고, Vercel이 무료로 그 일을 해 준다. 한 번 막혀 보고 나니 배포 서비스가 왜 필요한지 확실히 알게 됐다.


    이전 글: 깃허브 저장·커밋·푸시, 셋 다 저장 아니었어? 컴맹이 헷갈린 차이 정리
    다음 글: 깃허브와 Vercel 연결하기, 컴맹이 막혔던 곳 그대로 공개

  • 깃허브 저장·커밋·푸시, 셋 다 저장 아니었어? 컴맹이 헷갈린 차이 정리

    깃허브 저장·커밋·푸시, 셋 다 저장 아니었어? 컴맹이 헷갈린 차이 정리

    작성자: 컴맹 집사

    대표 이미지: 저장·커밋·푸시는 포장하고 송장을 붙여 보내는 택배와 비슷하다 (사진: tama66 / Pixabay)

    이 글에서 얻는 것

    • 이런 분께 앱을 고치고 저장했는데 인터넷에 반영되지 않아 답답한 분
    • 핵심 답 저장은 포장, 커밋은 송장을 붙여 접수, 푸시는 배송이다. 푸시까지 해야 고친 내용이 GitHub(인터넷)에 도착한다
    • 바로 쓰는 팁 고쳤는데 그대로라면 저장에서 멈추지 않았는지, 커밋과 푸시까지 했는지부터 확인하자

    나도 처음에는 커밋과 푸시가 같은 말인 줄 알았다. 둘 다 “올린다”는 뜻 아닌가? 게다가 파일은 이미 Ctrl+S로 저장했는데 왜 또 뭘 눌러야 하는지 이해가 안 됐다.

    그 차이를 알게 된 건, 분명히 고쳤는데 아무것도 바뀌지 않은 날이었다.

    고쳤는데 왜 그대로지?

    강아지 앱의 질문 문구를 하나 고쳤다. “산책할 때 어떤가요?”를 “산책할 때 우리 아이는 어떤가요?”로. 메모장에서 저장하고, 내 컴퓨터에서 열어 보니 잘 바뀌어 있었다.

    그런데 GitHub 웹사이트에 들어가 보니 예전 문구 그대로였다. 몇 번을 새로고침해도 마찬가지였다.

    AI에게 물었다.

    파일을 저장했는데 GitHub에는 반영이 안 돼. 왜 그래?

    답은 짧았다. “저장만 하고 커밋과 푸시를 안 하셨네요.”

    세 단계를 택배에 비유하면

    AI가 해 준 택배 비유가 가장 이해하기 쉬웠다.

    단계 하는 일 택배로 비유하면
    저장 (Ctrl+S) 내 컴퓨터의 파일을 고친다 물건을 포장한다
    커밋 (Commit) 바뀐 내용을 설명과 함께 기록한다 송장을 붙이고 접수한다
    푸시 (Push) 기록을 GitHub(인터넷)로 보낸다 택배 기사가 배송한다

    포장만 해 두면 물건은 내 방에 그대로 있다. 접수를 해야 기록이 생기고, 배송이 되어야 상대방에게 도착한다. 나는 포장만 해 놓고 왜 도착을 안 하냐고 묻고 있었던 셈이다.

    조금 더 정확하게

    저장

    메모장이나 코드 편집기에서 Ctrl+S를 누르는 것. 내 컴퓨터 안의 파일 내용만 바뀐다. GitHub는 이 사실을 모른다.

    커밋(commit)

    “지금 이 상태를 하나의 버전으로 기록해 줘”라는 뜻이다. (출처: Pro Git, 변경 사항 기록) 커밋할 때는 커밋 메시지라는 짧은 설명을 적는다. 예: 질문 1번 문구 수정.

    중요한 점은 커밋이 아직 내 컴퓨터 안에서만 남는 기록이라는 것이다. 인터넷에는 아직 올라가지 않았다.

    푸시(push)

    내 컴퓨터에 쌓인 커밋들을 GitHub로 보내는 것. 푸시를 해야 비로소 GitHub 웹사이트에도 바뀐 내용이 보인다.

    GitHub Desktop에서 실제로 누르는 순서

    1. 파일을 고치고 저장한다.
    2. GitHub Desktop을 열면 왼쪽 Changes 탭에 바뀐 파일이 보인다. 오른쪽에는 빨간색(지운 줄)과 초록색(추가한 줄)으로 무엇이 바뀌었는지 표시된다.
    3. 왼쪽 아래 Summary 칸에 커밋 메시지를 적는다. 예: 질문 1번 문구 수정
    4. Commit to main 버튼을 누른다. → 기록 완료
    5. 위쪽의 Push origin 버튼을 누른다. → GitHub로 전송 완료

    맨 처음 한 번은 5번 자리에 Publish repository라는 버튼이 나온다. 아직 GitHub에 이 저장소가 없으니 “처음 올리기”를 하라는 뜻이다. 한 번 올리고 나면 그다음부터는 Push origin으로 바뀐다.

    왜 굳이 커밋과 푸시를 나눠 놨을까

    처음에는 버튼 하나로 합쳐 주면 편할 텐데 싶었다. 앱을 계속 고치면서 나눠 둔 이유를 알게 됐다.

    1. 작은 단위로 기록할 수 있다.
    질문 문구 수정 → 커밋, 버튼 색 변경 → 커밋, 결과 설명 수정 → 커밋. 이렇게 잘게 나눠 두면 나중에 “버튼 색 바꾼 것만 되돌리기”가 가능하다.

    2. 인터넷이 없어도 기록은 남길 수 있다.
    커밋은 내 컴퓨터 안에서 일어나니까, 인터넷이 없어도 할 수 있다. 푸시는 나중에 한꺼번에 해도 된다.

    3. 푸시에는 결과가 따른다.
    나중에 알게 된 가장 중요한 이유다. 앱을 인터넷에 배포한 뒤로는 푸시하는 순간 실제 앱이 바뀐다. 그래서 푸시는 충분히 확인한 다음에 하는 동작이 됐다. 이 이야기는 Vercel 글에서 이어진다.

    커밋 메시지, 이렇게 쓰기로 했다

    처음에는 커밋 메시지를 수정, ㅇㅇ, 1처럼 대충 썼다. 며칠 뒤 되돌릴 버전을 찾으려는데 전부 수정이라 어느 게 어느 건지 알 수가 없었다.

    첫날 남긴 커밋 기록 목록
    개발 첫날인 9월 19일에 남긴 실제 커밋 기록. 한 줄이 커밋 하나다
    출처: 앱 저장소(GitHub)의 실제 기록을 정리해 직접 제작

    그 뒤로 정한 규칙은 이렇다.

    • 무엇을 했는지 한 줄로 쓴다: 결과 화면에 작위 설명 추가
    • 왜 했는지가 중요하면 덧붙인다: 총집사가 안 나오는 문제 수정 - 유형별 작위 연결 조정
    • 한 커밋에는 한 가지 변경만 담는다.

    AI에게 코드 수정을 요청할 때 “이번 수정에 어울리는 커밋 메시지도 써 줘”라고 덧붙이면 알아서 적어 주기도 한다. 꽤 유용했다.

    초보자가 자주 하는 실수

    • 저장을 안 하고 커밋하려 한다. Changes 탭에 아무것도 안 뜨면 먼저 저장했는지 확인하자.
    • 커밋만 하고 푸시를 잊는다. GitHub Desktop 위쪽 버튼에 숫자(↑1 같은)가 떠 있으면 아직 안 보낸 커밋이 있다는 뜻이다.
    • 여러 가지를 한 커밋에 몰아넣는다. 문제가 생기면 전부 같이 되돌려야 한다.

    되돌리기가 필요할 때

    커밋을 잘게 해 두면 되돌리기도 쉽다. GitHub Desktop의 History 탭에서 되돌리고 싶은 커밋을 오른쪽 클릭하면 Revert changes in commit이라는 메뉴가 있다. 그 커밋에서 바꾼 내용만 거꾸로 되돌리는 새 커밋이 만들어진다. 되돌린 뒤에도 푸시를 해야 GitHub에 반영된다는 점은 똑같다.

    처음 이 기능을 쓴 건 작위증 배경색을 바꿨다가 글자가 안 보이게 됐을 때였다. 배경색 변경 커밋만 되돌리고, 그 전에 한 질문 수정은 그대로 살릴 수 있었다. 여러 가지를 한 커밋에 몰았다면 불가능했을 일이다.

    초보자 팁: 오늘 작업을 마칠 때는 GitHub Desktop 위쪽 버튼에 숫자가 남아 있지 않은지 확인하자. 보내지 않은 커밋이 남아 있으면 다음 날 헷갈린다.

    이제는 이렇게 이해한다

    저장은 나를 위한 것, 커밋은 기록을 위한 것, 푸시는 세상에 보내기 위한 것.

    이 순서가 몸에 익고 나니 앱을 고치는 과정 전체가 정리됐다. 고친다 → 확인한다 → 커밋한다 → 푸시한다. 그리고 이 마지막 푸시가, 다음에 배울 Vercel과 연결되는 출발 신호가 됐다.


    이전 글: 깃허브(GitHub)가 뭐길래? 코딩 몰라도 이해되는 앱 타임머신 이야기
    다음 글: Vercel이 뭐길래 내 앱에 주소가 생겼을까? 배포 서비스 쉬운 설명

  • 깃허브(GitHub)가 뭐길래? 코딩 몰라도 이해되는 앱 타임머신 이야기

    깃허브(GitHub)가 뭐길래? 코딩 몰라도 이해되는 앱 타임머신 이야기

    작성자: 컴맹 집사

    대표 이미지: 코드는 여러 파일로 나뉘어 있고, GitHub는 이 파일들을 보관한다 (사진: pexels / Pixabay)

    이 글에서 얻는 것

    • 이런 분께 파일 이름에 ‘최종’, ‘진짜 최종’이 쌓여 가는 분
    • 핵심 답 GitHub는 고칠 때마다 언제, 무엇을, 왜 바꿨는지 기록이 남는 클라우드 폴더다. 파일은 하나만 두고 버전은 GitHub가 기억한다
    • 바로 쓰는 팁 명령어가 어렵다면 버튼으로 쓰는 공식 프로그램 GitHub Desktop부터 설치하자

    index-진짜최종-수정2.html

    앱을 만든 지 사흘째, 내 폴더에 있던 파일 이름이다. 수정할 때마다 혹시 몰라 복사본을 만들었더니 어느새 열 개가 넘었다. 어제 잘 되던 버전이 어떤 파일인지 기억도 나지 않았다.

    AI에게 이렇게 물었다.

    파일 버전이 너무 많아져서 헷갈려. 어떻게 관리해?

    돌아온 답의 첫 단어가 GitHub(깃허브)였다. 이름은 들어 봤지만 개발자들만 쓰는 무언가라고만 생각했던 서비스다.

    처음 들은 설명은 하나도 이해가 안 됐다

    인터넷에서 찾은 첫 설명은 이랬다.

    GitHub는 Git 기반의 분산 버전 관리 시스템을 위한 원격 저장소 호스팅 서비스이다. (출처: GitHub 공식 문서)

    한 문장에 모르는 단어가 다섯 개였다. 그래서 AI에게 다시 부탁했다. “코딩을 전혀 모르는 사람에게 비유로 설명해 줘.”

    그 뒤에 들은 설명이 훨씬 와닿았다.

    내가 이해한 GitHub

    GitHub는 “앱 파일을 위한 기록이 남는 클라우드 폴더”다.

    • 클라우드 폴더: 내 컴퓨터가 아니라 인터넷에 파일을 보관한다. 네이버 MYBOX나 구글 드라이브처럼.
    • 기록이 남는다: 파일을 고칠 때마다 “언제, 무엇을, 왜 바꿨는지”가 기록된다. 예전 상태로 되돌리는 것도 가능하다.

    구글 드라이브와 다른 점은 두 번째다. 드라이브는 파일을 덮어쓰면 끝이지만, GitHub는 수정 이력 전체를 차곡차곡 쌓아 둔다. 그래서 index-최종.html 같은 복사본을 만들 필요가 없다. 파일은 index.html 하나만 두고, 버전은 GitHub가 기억한다.

    Git과 GitHub는 다른 것이었다

    헷갈렸던 부분이 하나 더 있었다. Git과 GitHub가 같은 건 줄 알았다.

    이름 쉽게 말하면
    Git(깃) 파일의 변경 기록을 남기는 도구(프로그램)
    GitHub(깃허브) Git으로 남긴 기록을 인터넷에 보관하는 서비스(웹사이트)

    비유하자면 Git은 “일기 쓰는 방법”이고, GitHub는 “일기장을 보관하는 도서관”이다. 초보자 입장에서는 GitHub 웹사이트와 GitHub Desktop 프로그램만 쓰면 Git을 따로 공부하지 않아도 됐다.

    새로 알게 된 단어, 저장소(repository)

    GitHub에서 가장 먼저 만나는 단어가 repository(레포지토리), 줄여서 레포다. 우리말로는 저장소라고 한다.

    GitHub 저장소 안의 파일 구성
    실제 앱 저장소에 들어 있는 주요 파일과 역할
    출처: 앱 저장소(GitHub)의 실제 기록을 정리해 직접 제작

    저장소는 프로젝트 하나를 담는 폴더라고 생각하면 된다. 강아지 앱 하나가 저장소 하나다. 나중에 다른 앱을 만들면 저장소를 새로 만든다.

    GitHub를 시작한 순서

    실제로 내가 한 순서를 적어 둔다.

    1. 계정 만들기

    github.com에 들어가 Sign up으로 가입했다. 이메일, 비밀번호, 사용자 이름을 정하면 된다. 사용자 이름은 나중에 주소에 들어가니 너무 이상하지 않게 짓는 걸 추천한다.

    2. GitHub Desktop 설치

    GitHub는 원래 명령어로 쓰는 경우가 많은데, 초보자에게는 GitHub Desktop이라는 프로그램이 훨씬 편했다. 버튼을 눌러서 쓸 수 있는 공식 프로그램이다. desktop.github.com에서 내려받아 설치하고, 방금 만든 계정으로 로그인했다.

    3. 기존 앱 폴더를 저장소로 만들기

    GitHub Desktop에서 File → Add local repository를 누르고, 앱 파일이 있는 kba-butler-app 폴더를 골랐다. “이 폴더는 아직 저장소가 아니다”라는 안내가 뜨면, 안내에 있는 create a repository 링크를 눌러 저장소로 만들면 된다.

    4. 정리부터 했다

    저장소를 만들기 전에 폴더 안의 index2.html, index-최종.html 같은 복사본을 전부 지우고, 제대로 돌아가는 index.html 하나만 남겼다. 이제부터는 GitHub가 버전을 기억해 줄 테니까.

    처음엔 “이게 왜 필요하지?” 싶었다

    솔직히 설정을 마친 직후에는 달라진 게 없어 보였다. 파일은 여전히 내 폴더에 있었고, 앱도 똑같이 열렸다. 괜히 복잡한 것만 하나 늘어난 기분이었다.

    GitHub의 진가를 느낀 건 며칠 뒤였다. 결과 화면을 고치다가 앱이 완전히 망가졌는데, GitHub Desktop의 History 탭을 열어 보니 어제 저장해 둔 기록이 그대로 있었다. 거기서 망가지기 전 상태로 되돌리는 데 1분도 걸리지 않았다. 복사본 열 개를 뒤지던 때와는 비교가 안 됐다.

    그때 확실히 알았다. GitHub는 앱을 위한 타임머신이었다. 저장할 때마다 그 순간의 앱을 사진처럼 찍어 두고, 일이 꼬이면 원하는 날짜로 돌아가면 된다. “진짜최종-수정2” 같은 파일 이름과는 이제 작별이다.

    그리고 GitHub가 필요한 진짜 이유는 따로 있었다. 앱을 인터넷에 올리는 서비스(Vercel)가 GitHub에 있는 파일을 가져다 쓴다는 것. 이건 뒤에서 이어서 쓸 예정이다.

    초보자가 알아 두면 좋은 것

    • 저장소를 공개(Public)로 할지 비공개(Private)로 할지 고를 수 있다. 처음 연습하는 앱이라면 비공개로 해도 된다.
    • 비밀번호나 개인 정보가 담긴 파일은 올리지 않는다. 공개 저장소는 누구나 볼 수 있다.
    • GitHub에 올려도 내 컴퓨터의 파일은 그대로 있다. 옮기는 게 아니라 복사본과 기록을 보관하는 것이다.

    GitHub를 쓰기 전과 후

    일주일쯤 써 보고 달라진 점을 비교해 보면 이렇다.

    전 후
    수정할 때마다 복사본 파일 생성 파일은 하나, 버전은 기록으로
    어느 파일이 최신인지 헷갈림 History에서 날짜별로 확인
    망가지면 복사본을 뒤져 복구 이전 기록으로 바로 되돌림
    컴퓨터가 고장 나면 전부 사라질 위험 인터넷에 사본이 있어 안심

    GitHub Desktop을 열자마자 또 모르는 버튼이 보였다. Commit과 Push. 저장만 하면 되는 줄 알았는데, 왜 버튼이 두 개나 더 있을까?


    이전 글: AI에게 “앱 만들어 줘” 했더니 생긴 일, 첫 결과물과 시행착오
    다음 글: 깃허브 저장·커밋·푸시, 셋 다 저장 아니었어? 컴맹이 헷갈린 차이 정리

  • AI에게 “앱 만들어 줘” 했더니 생긴 일, 첫 결과물과 시행착오

    AI에게 “앱 만들어 줘” 했더니 생긴 일, 첫 결과물과 시행착오

    작성자: 컴맹 집사

    대표 이미지: AI에게 처음 만들어 달라고 해서 받은 첫 화면. 이름도 “개집사 작위청”이었다 (출처: 왕립 개집사협회 앱 2026년 9월 19일 첫 버전 화면, 직접 캡처)

    이 글에서 얻는 것

    • 이런 분께 AI에게 처음 “앱 만들어 줘”라고 요청해 보려는 분
    • 핵심 답 첫 결과물에는 잘 된 곳과 어긋난 곳이 섞여 있었고, 첫 수정 요청은 오히려 일을 망쳤다. 요청 문장에 무엇을 담느냐가 결과를 갈랐다
    • 바로 쓰는 팁 수정 요청에는 지금 상태, 원하는 상태, “다른 부분은 건드리지 말고 이 부분만” 범위 제한 세 가지를 꼭 넣자

    엔터를 누르고 기다린 시간은 1분도 안 됐다. 화면에는 영어와 기호가 뒤섞인 긴 글이 쏟아졌다. 그게 내가 처음 받아 본 앱의 코드였다.

    기대와 불안이 반반이었다. 이게 정말 앱이 되는 걸까? 이걸 어디에 넣어야 하지? 이 글에는 그날 한 일과 헤맨 순서를 그대로 적었다.

    받은 코드를 어떻게 여는지부터 몰랐다

    앞 글에서 정리한 요청서에 “파일 하나(index.html)로 만들어 줘”라고 적었기 때문에, AI는 index.html이라는 파일 하나에 들어갈 코드를 줬다. (출처: MDN 웹 문서, HTML 기초)

    문제는 그다음이었다. 이 코드를 어디에 붙여 넣어야 하는지 몰랐다. AI에게 그대로 물었다.

    이 코드를 받았는데, 컴퓨터에서 어떻게 열어 봐?

    알려 준 방법은 생각보다 간단했다.

    1. 바탕화면에 새 폴더를 만든다. (나는 kba-butler-app이라고 지었다)
    2. 메모장을 열고 받은 코드를 전부 붙여 넣는다.
    3. 다른 이름으로 저장 → 파일 이름을 index.html로, 파일 형식은 모든 파일로 바꿔 저장한다.
    4. 저장된 파일을 더블클릭하면 인터넷 브라우저로 열린다.

    여기서 첫 실수를 했다. 파일 형식을 바꾸지 않고 저장해서 이름이 index.html.txt가 됐다. 더블클릭하니 메모장으로만 열렸다. 윈도우 탐색기에서 보기 → 파일 확장명 표시를 켜고 나서야 뒤에 .txt가 붙어 있다는 걸 알았다.

    초보자 팁: 윈도우 탐색기에서 “파일 확장명” 보기를 꼭 켜 두자. 앱을 만드는 동안 파일 이름 끝의 .html, .js, .png를 볼 일이 계속 생긴다.

    나중에는 메모장 대신 코드 편집 프로그램(VS Code)을 쓰게 됐지만, 첫날은 메모장으로도 충분했다.

    처음 열어 본 화면

    브라우저에 “왕립 개집사협회”라는 제목과 시작 버튼이 떴다. 버튼을 누르자 폐하 정보를 넣는 칸이 나오고, 질문이 하나씩 넘어갔다. 일곱 번째 질문에 답하니 “왕실 돌봄근위관”이라는 작위가 나왔다.

    솔직히 조금 소름이 돋았다. 코드는 한 줄도 이해하지 못했는데, 내가 설명한 앱이 실제로 움직이고 있었다.

    잘 된 것과 어긋난 것

    감동은 잠깐이었다. 여러 번 해 보니 아쉬운 점이 보이기 시작했다.

    첫 버전에서 발급된 작위증 결과 화면
    첫 버전의 결과 화면. 작위증은 코드로 그린 단순한 모양이었다
    출처: 왕립 개집사협회 앱 2026년 9월 19일 첫 버전 화면, 직접 캡처

    잘 된 것
    – 화면 순서가 요청서와 똑같았다.
    – 진행도(3/7 같은 표시)가 들어가 있었다.
    – 휴대폰 크기로 창을 줄여도 대체로 괜찮게 보였다.

    어긋난 것
    – 어떻게 답해도 비슷한 작위만 나왔다. 최고 작위인 “왕실 총집사”는 한 번도 나오지 않았다.
    – 작위증 화면이 흰 바탕에 글자뿐이라 “증서” 느낌이 없었다.
    – 폐하 이름 칸을 비워 두고 넘어가도 진행이 됐고, 작위증에 이름 없이 ” 폐하의 집사”라고 떴다.

    첫 번째 문제는 결과를 계산하는 방식 때문이었다. 이건 나중에 “조건문으로 결과를 나누는 방법”에서 자세히 쓸 예정인데, 간단히 말하면 질문의 보기와 집사 유형을 잇는 기준이 한쪽으로 쏠려 있었고, 최고 작위는 아예 결과로 나오지 않게 짜여 있었다.

    수정 요청을 망친 첫 시도

    문제를 발견하자마자 한꺼번에 고쳐 달라고 했다.

    총집사도 나오게 하고, 작위증 예쁘게 만들고, 이름 안 쓰면 못 넘어가게 해 줘.

    AI는 세 가지를 모두 고친 새 코드를 줬다. 그런데 이번에는 질문 화면에서 버튼이 아예 눌리지 않았다. 세 군데를 동시에 바꾸다가 어딘가가 망가졌는데, 어디가 문제인지 나도 AI도 한 번에 찾지 못했다.

    결국 처음 코드로 돌아가서 하나씩 다시 요청했다.

    1. “폐하 이름을 입력하지 않으면 다음으로 못 넘어가게 해 줘.” → 확인 완료
    2. “일곱 문항에 어떻게 답하느냐에 따라 집사 유형 일곱 가지와 작위 다섯 단계가 모두 나올 수 있게 해 줘.” → 확인 완료
    3. “작위증을 오래된 종이 느낌의 테두리가 있는 증서처럼 꾸며 줘.” → 확인 완료

    하나 고칠 때마다 직접 열어서 확인했다. 시간은 더 걸리는 것 같았지만 실제로는 훨씬 빨랐다.

    이날 정한 “AI에게 수정 요청하는 법”

    이 경험 이후로 나는 수정 요청을 할 때 항상 세 가지를 넣는다.

    • 지금 상태: “질문 화면에서 보기 버튼을 눌러도 다음 질문으로 안 넘어가.”
    • 원하는 상태: “보기를 누르면 바로 다음 질문으로 넘어갔으면 좋겠어.”
    • 범위 제한: “다른 부분은 건드리지 말고 이 부분만 고쳐 줘.”

    특히 마지막 문장이 효과가 컸다. 이 말을 안 하면 AI가 친절하게(?) 다른 부분까지 바꿔 버리는 경우가 있었다.

    이날의 가장 큰 고민

    저녁쯤 되자 폴더 안에 index.html, index2.html, index-최종.html, index-진짜최종.html이 쌓였다. 어느 게 제대로 돌아가는 버전인지 헷갈리기 시작했다. 게다가 이 앱은 아직 내 컴퓨터에서만 열린다. 친구에게 보여 주려면 파일을 통째로 보내야 했다.

    • 버전을 어떻게 관리하지?
    • 다른 사람은 어떻게 이 앱을 열지?

    AI에게 이 두 가지를 물었더니, 똑같이 두 단어가 돌아왔다. GitHub와 Vercel. 다음 단계는 이 낯선 이름들을 이해하는 일이었다.

    첫날 알게 된 index.html 안의 세 가지

    코드를 한 줄도 이해하지 못했지만, AI에게 “이 코드가 어떤 부분으로 나뉘어 있는지 큰 덩어리만 설명해 줘”라고 물어봤다. 답은 세 덩어리였다.

    • HTML: 화면에 무엇이 있는지 적는 부분. 제목, 버튼, 입력칸 같은 뼈대.
    • CSS: 어떻게 보이는지 정하는 부분. 색, 글자 크기, 배치 같은 옷.
    • JavaScript: 어떻게 움직이는지 정하는 부분. 버튼을 누르면 다음 질문이 나오는 동작.

    이 구분 하나만 알아도 수정 요청이 달라졌다. 글자색을 바꾸고 싶으면 “CSS 부분에서”, 버튼이 안 눌리면 “JavaScript 부분에서”라고 짚어 줄 수 있었다. AI도 엉뚱한 곳을 건드리는 일이 줄었다.


    이전 글: 앱 아이디어, 한 줄이면 충분했다! 컴맹의 초간단 기획서 쓰는 법
    다음 글: 깃허브(GitHub)가 뭐길래? 코딩 몰라도 이해되는 앱 타임머신 이야기

  • 앱 아이디어, 한 줄이면 충분했다! 컴맹의 초간단 기획서 쓰는 법

    앱 아이디어, 한 줄이면 충분했다! 컴맹의 초간단 기획서 쓰는 법

    작성자: 컴맹 집사

    대표 이미지: 기획은 화면 목록과 순서를 종이에 적는 데서 시작했다 (사진: joshuaworoniecki / Pixabay)

    이 글에서 얻는 것

    • 이런 분께 앱 아이디어는 있는데 AI에게 어떻게 설명할지 모르는 분
    • 핵심 답 한 줄 정의 → 사용자가 거치는 순서 → 화면 목록 → 꼭 필요한 기능 고르기, 네 단계를 거치면 AI가 만들 수 있는 기획이 된다
    • 바로 쓰는 팁 사용자가 앱을 열고 닫을 때까지의 순서를 적어 보면 빠진 단계가 보인다. 이 앱도 ‘폐하 정보 입력’이 빠진 걸 이때 찾았다

    “강아지는 왕, 반려인은 왕의 집사”라는 세계관은 재미있었다. 문제는 그걸 AI에게 어떻게 설명하느냐였다.

    처음에는 “강아지가 왕이고 내가 집사인 앱 만들어 줘”라는 한 문장만 던졌다. 결과는 기대와 달랐다. 질문은 세 개뿐이었고, 결과는 “당신은 훌륭한 집사입니다!” 한 줄이 전부였다. AI가 잘못한 게 아니었다. 내가 원하는 걸 나도 정확히 몰랐던 것이다.

    그래서 코드를 요청하기 전에 머릿속 생각을 종이에 옮기는 과정을 거쳤다. 거창한 기획서가 아니라 초보자도 할 수 있는 네 단계였다.

    1단계. 앱을 한 문장으로 정의하기

    가장 먼저 “이 앱은 무엇인가”를 한 문장으로 적었다. 누가, 무엇을 해서, 무엇을 얻는지가 들어가도록 했다.

    반려인이 우리 강아지 폐하의 정보를 넣고 집사로서 질문 7개에 답하면, 나만의 반려견 왕국과 집사 작위가 적힌 작위증을 받는 웹앱

    이 한 문장을 쓰고 나니 빠진 것들이 보였다. “폐하 정보는 무엇을 받지?”, “집사 유형은 몇 가지?”, “작위는 몇 단계?”, “작위증에는 뭐가 들어가지?” 같은 질문이 저절로 생겼다.

    2단계. 사용자가 거치는 순서 적기

    다음으로 사용자가 앱을 열고 닫을 때까지 어떤 순서로 움직이는지 적었다. 개발에서는 이걸 사용자 흐름(user flow)이라고 부른다고 한다.

    1. 앱을 연다 → 시작 화면이 보인다
    2. 폐하(강아지)의 이름과 성격, 좋아하는 활동과 싫어하는 활동, 왕국 분위기를 고른다
    3. 집사로서 질문 7개에 차례로 답한다
    4. 나의 집사 유형과 작위, 우리 왕국의 이름·표어를 확인한다
    5. 강아지 사진이 들어간 작위증을 받는다
    6. 작위증을 저장하거나 친구에게 공유한다

    순서를 적어 보니 “폐하 정보 입력”이 빠져 있었다. 폐하의 이름과 성격이 없으면 “○○ 폐하의 왕국”을 만들 수도, 작위증에 적을 수도 없다. 이런 구멍은 코드를 받은 뒤에 발견하면 고치기 번거롭다.

    3단계. 화면 목록 만들기

    흐름을 바탕으로 필요한 화면을 나눴다.

    첫 버전 앱의 질문 화면
    기획서의 “질문 7개” 화면이 실제로 만들어진 모습
    출처: 왕립 개집사협회 앱 2026년 9월 19일 버전 화면, 직접 캡처
    화면 들어갈 내용
    시작 화면 앱 제목, 짧은 소개, 시작 버튼
    왕국 만들기 화면 폐하 이름, 집사 닉네임, 폐하의 성격, 좋아하는·싫어하는 활동, 왕국 분위기
    질문 화면 질문 문장, 보기 버튼, 진행도(3/7 같은 표시)
    결과 화면 집사 유형, 작위 이름과 뜻, 왕국 이름·표어
    작위증 화면 사진, 이름, 작위, 발급일이 들어간 증서, 저장·공유 버튼

    손으로 네모를 그려 가며 해도 충분하다. 나는 휴대폰 메모장에 적었다. 중요한 건 예쁘게 그리는 게 아니라 화면마다 무엇이 있어야 하는지 정하는 것이다.

    4단계. 꼭 필요한 기능만 고르기

    화면을 정하다 보니 욕심이 계속 생겼다. 작위별 배경 음악, 친구 왕국과 궁합 보기, 세계관을 보여 줄 웹툰, 쉬는 시간용 게임. 전부 적어 놓고 처음 버전에 꼭 필요한 것과 나중에 할 것으로 나눴다.

    처음 버전(반드시)
    – 폐하 정보 입력
    – 질문 7개와 집사 유형 판정
    – 집사 작위 5단계 (견국 수습집사, 왕실 생활협력관, 왕실 돌봄근위관, 발바닥 궁정대신, 왕실 총집사)
    – 작위증 화면

    나중에(있으면 좋음)
    – 사진 업로드
    – 이미지로 저장
    – 공유하기
    – 이전 결과 다시 보기
    – 웹툰, 미니게임

    개발자들은 이걸 MVP(최소 기능 제품)라고 부른다고 한다. (출처: Wikipedia, Minimum viable product) 핵심 기능만 먼저 돌아가게 만들고 하나씩 붙이는 방식이다. 초보자에게는 이 방식이 특히 중요했다. 한꺼번에 만들면 어디서 문제가 생겼는지 알 수 없기 때문이다.

    AI에게 건넨 첫 요청서

    네 단계를 정리한 뒤 AI에게 보낸 요청은 이런 형태였다.

    반려인을 위한 집사 작위증 웹앱을 만들고 싶어.
    [세계관]
    강아지는 왕(폐하), 반려인은 왕을 모시는 집사. 왕립 개집사협회가 집사에게 작위를 내린다.
    [앱 설명]
    폐하의 이름·성격·좋아하는 활동·싫어하는 활동·왕국 분위기를 입력하고, 집사가 질문 7개에 답하면
    집사 유형을 정하고 그에 맞는 작위와 왕국 이름·표어가 담긴 작위증을 보여 주는 웹앱.
    [화면 순서]
    시작 화면 → 왕국 만들기(폐하 정보) → 질문 7개 → 결과 → 작위증
    [작위]
    견국 수습집사, 왕실 생활협력관, 왕실 돌봄근위관, 발바닥 궁정대신, 왕실 총집사 (5단계)
    [조건]
    - 코딩을 모르는 초보자라서, 파일 하나(index.html)로 만들어 줘.
    - 휴대폰 화면에서도 보기 좋게.
    - 사진 업로드와 공유는 아직 넣지 마.

    처음의 한 문장 요청과 비교하면 결과가 완전히 달랐다. 이 요청으로 받은 첫 결과물과 시행착오는 다음 글에 자세히 적었다.

    기획 단계에서 AI를 활용한 방법

    네 단계를 정리하는 것 자체도 AI의 도움을 받았다. 코드를 요청하기 전에, 기획만 따로 대화했다.

    • “이 아이디어로 앱을 만들 때 사용자 흐름을 짜 줘. 빠진 화면이 있으면 알려 줘.”
    • “처음 버전에 꼭 필요한 기능과 나중에 해도 되는 기능을 나눠 줘.”
    • “반려인이 어떤 집사인지 알아볼 수 있는 질문을 10개 후보로 뽑아 줘. 산책, 목욕, 간식처럼 누구나 겪는 상황으로.”

    특히 마지막 질문이 유용했다. AI가 뽑아 준 후보 중에서 반려인이라면 웃으며 답할 만한 것만 골라 일곱 개로 줄였다. 이 기획은 제미나이와 챗GPT에 번갈아 보여 주며 빠진 점을 확인했고, 마지막으로 클로드에게 검토받았다. 후보를 받고 고르는 일은 내가 하는 것, 이 역할 분담이 기획 단계에서도 잘 맞았다.

    기획서를 파일로 남겨 두니 생긴 장점

    정리한 기획 내용은 기획.txt라는 파일로 저장해 앱 폴더에 같이 넣어 두었다. 생각보다 쓸모가 많았다.

    • AI와 새 대화를 시작할 때 이 파일 내용을 먼저 붙여 넣으면, 앱이 어떤 것인지 다시 설명할 필요가 없었다.
    • 기능을 추가할 때마다 “나중에 할 것” 목록에서 하나씩 지우며 진행 상황을 확인할 수 있었다.
    • 방향이 흔들릴 때 처음 정한 한 문장을 다시 읽으면 중심이 잡혔다.

    기획 단계에서 한 실수

    처음 뽑은 질문 중에는 “폐하의 혈통은?”처럼 보호자가 모르면 답할 수 없는 질문이 있었다. 친구에게 미리 물어보니 “우리 애는 믹스라 모르겠는데”라는 답이 돌아왔다. 누구나 바로 답할 수 있는 행동 중심 질문으로 바꿨다. 기획 단계에서 한두 사람에게 질문만 먼저 보여 주는 것도 좋은 점검 방법이다.

    이 과정에서 배운 점

    • AI는 내가 설명한 만큼만 만들어 준다. 흐릿하게 말하면 흐릿한 결과가 나온다.
    • 기획이라고 해서 어렵지 않다. 한 문장 → 순서 → 화면 → 기능 고르기 네 단계면 충분했다.
    • “나중에 할 것” 목록을 따로 만들어 두니 욕심을 참기 쉬웠다. 실제로 이 목록이 이후 기능 추가의 순서표가 됐다.

    아이디어가 있는데 어디서 시작할지 모르겠다면, 코드를 요청하기 전에 이 네 가지만 먼저 적어 보길 권한다. 10분이면 되는데, 그 10분이 몇 시간의 수정을 줄여 준다.


    이전 글: 앱이랑 웹앱, 뭐가 달라? 앱스토어 없이 앱 만든 컴맹의 깨달음
    다음 글: AI에게 “앱 만들어 줘” 했더니 생긴 일, 첫 결과물과 시행착오

  • 앱이랑 웹앱, 뭐가 달라? 앱스토어 없이 앱 만든 컴맹의 깨달음

    앱이랑 웹앱, 뭐가 달라? 앱스토어 없이 앱 만든 컴맹의 깨달음

    작성자: 컴맹 집사

    대표 이미지: 흔히 말하는 “앱”은 스토어에서 설치하는 네이티브 앱이다 (사진: jeshoots-com / Pixabay)

    이 글에서 얻는 것

    • 이런 분께 앱스토어 앱과 웹앱 중 무엇으로 시작할지 고민하는 분
    • 핵심 답 웹앱은 설치 없이 인터넷 주소로 여는 앱이다. 휴대폰 깊은 기능이 필요 없고 자주 고칠 앱이라 웹앱으로 시작했다
    • 바로 쓰는 팁 “설치까지 해 가며 쓸 앱인가, 알림·블루투스가 꼭 필요한가, 자주 고치게 될까” 세 질문에 답하면 방향이 정해진다

    AI에게 처음 “반려인이 집사 작위증을 받는 앱을 만들고 싶어”라고 했을 때 돌아온 질문은 이랬다.

    네이티브 앱으로 만들까요, 웹앱으로 만들까요?

    나는 그 자리에서 멈췄다. 앱이면 그냥 앱이지, 종류가 있다는 것부터 몰랐다. 이 질문에 답하지 못하면 한 걸음도 나갈 수 없었다. 그래서 코드보다 이 개념부터 공부했다.

    내가 알던 “앱”은 네이티브 앱이었다

    우리가 보통 “앱”이라고 부르는 건 네이티브 앱이다. 구글 플레이나 앱스토어에서 내려받아 설치하는 카카오톡, 은행 앱 같은 것들이다.

    • 휴대폰에 설치해서 쓴다.
    • 안드로이드용과 아이폰용을 따로 만드는 경우가 많다.
    • 카메라, 알림, 위치 같은 휴대폰 기능을 깊게 쓸 수 있다.
    • 스토어에 올리려면 심사를 받아야 한다.

    “네이티브”는 “그 기기 고유의”라는 뜻이다. 안드로이드와 아이폰 각각의 방식에 맞춰 만든 앱이라는 의미다.

    웹앱은 인터넷 주소로 여는 앱이다

    웹앱은 설치하지 않고 인터넷 브라우저(크롬, 사파리 등)로 주소를 열어서 쓰는 앱이다. 겉모습과 쓰는 방식은 앱 같지만, 실제로는 웹사이트처럼 동작한다.

    브라우저 주소창으로 연 웹앱 화면(영어판)
    웹앱은 인터넷 주소만 열면 바로 쓸 수 있다. 영어판을 브라우저로 연 화면
    출처: 직접 캡처한 화면(2026년 9월 20일)

    처음에는 “그럼 그냥 홈페이지 아냐?”라고 생각했다. AI에게 물어보니 차이를 이렇게 설명해 줬다.

    • 웹사이트: 주로 정보를 읽는 곳 (회사 소개, 뉴스, 블로그)
    • 웹앱: 사용자가 무언가를 하는 곳 (질문에 답하고, 결과를 받고, 저장하고, 공유하는)

    집사 작위 진단은 사용자가 버튼을 누르고 답을 고르고 결과를 받는 구조다. 그러니 웹앱이라고 부르는 게 맞았다.

    한눈에 비교해 보기

    구분 네이티브 앱 웹앱
    여는 방법 스토어에서 설치 인터넷 주소(링크) 접속
    만드는 법 기기별로 따로 만드는 경우가 많음 하나로 아이폰·안드로이드·PC 모두
    배포 스토어 심사 필요 인터넷에 올리면 바로 공개
    수정 반영 업데이트 심사 → 사용자가 업데이트 올리면 즉시 모두에게 반영
    비용 개발자 계정 등록비 등 무료로 시작 가능
    휴대폰 기능 거의 모두 사용 일부 제한
    초보자 난이도 높음 상대적으로 낮음

    내가 웹앱을 선택한 이유

    비교표를 보고 나니 선택은 어렵지 않았다.

    1. 하나만 만들면 된다. 친구들 휴대폰은 아이폰과 갤럭시가 섞여 있다. 네이티브 앱이면 두 가지를 만들어야 하지만, 웹앱은 링크 하나로 모두가 쓸 수 있다.
    2. 고치면 바로 반영된다. 초보자는 실수를 많이 한다. 오타 하나 고치는 데 스토어 심사를 기다려야 한다면 지쳐서 포기했을 것이다.
    3. 무료로 시작할 수 있다. 웹앱은 무료 배포 서비스로 인터넷에 올릴 수 있다. 이 부분은 뒤에서 Vercel을 다루며 자세히 쓸 예정이다.
    4. 링크로 공유하기 좋다. 테스트 앱은 결국 “너희 강아지도 해 봐”라며 링크를 보내는 게 핵심이다. 설치하라고 하면 대부분 안 한다. 링크를 누르면 바로 열리는 게 훨씬 낫다.

    그런데 나중에 스마트폰 앱처럼 쓸 수 있을까?

    웹앱을 선택하면서 가장 걱정된 건 “그럼 영영 진짜 앱은 못 만드나?”였다. 알아보니 방법이 있었다.

    즉 웹앱 → PWA → Google Play로 단계적으로 키워 갈 수 있다. 처음부터 어려운 길로 가지 않고, 쉬운 데서 시작해 점점 앱에 가깝게 만드는 계획이 이때 세워졌다. 이 블로그의 전체 흐름도 여기서 나왔다.

    헷갈렸던 비슷한 말들

    앱과 웹앱의 차이를 공부하면서 비슷한 단어가 여럿 나와서 따로 정리해 뒀다.

    • 하이브리드 앱: 겉은 스토어에서 받는 앱인데, 속은 웹 기술로 만든 앱이다. 웹앱을 앱 껍데기로 감싼 형태라고 이해했다.
    • 모바일 웹: 휴대폰 화면에 맞춰 보이는 웹사이트. 웹앱과 거의 같은 뜻으로 쓰이기도 한다.
    • 반응형 웹(responsive design): 화면 크기에 따라 배치가 자동으로 바뀌는 웹. 컴퓨터에서는 넓게, 휴대폰에서는 세로로 길게 보인다. 웹앱을 만들 때 기본으로 챙겨야 하는 부분이다.
    • PWA: 웹앱에 몇 가지 설정을 더해서 휴대폰에 설치하고 앱처럼 쓸 수 있게 만든 것. 이 블로그 후반부의 주인공이다.

    이 단어들을 모두 외울 필요는 없었다. AI가 이런 말을 섞어 쓸 때 “결국 웹 기술로 만든 것이구나” 정도로 알아듣는 것만으로도 대화가 훨씬 수월해졌다.

    웹앱의 단점도 있다

    좋은 점만 있는 건 아니었다. 웹앱으로 정하면서 받아들인 단점도 적어 둔다.

    • 인터넷이 없으면 열리지 않는다. (PWA로 일부 해결할 수 있다고 한다.)
    • 스토어 검색으로 찾아오는 사람이 없다. 링크를 직접 퍼뜨려야 한다.
    • 휴대폰 기능 일부는 쓰기 어렵다. 푸시 알림 같은 기능은 기기마다 지원 정도가 다르다.

    왕립 개집사협회 앱에는 이 단점들이 크게 문제 되지 않았다. 만들려는 앱의 성격에 따라 판단하면 된다.

    결정을 도와준 질문 세 가지

    앱과 웹앱 사이에서 고민하는 분이라면 다음 세 가지를 스스로 물어보면 좋겠다.

    1. 사용자가 설치까지 해 가며 쓸 앱인가, 한 번 눌러 보고 즐길 앱인가?
    2. 알림, 블루투스처럼 휴대폰 깊은 기능이 꼭 필요한가?
    3. 나는 자주 고치게 될까?

    강아지 앱은 “한 번 눌러 보고”, “필요 없음”, “아주 자주”였다. 답이 바로 웹앱을 가리켰다.

    이 단계에서 배운 점

    • “앱”에는 종류가 있고, 무엇을 고르느냐에 따라 난이도가 완전히 달라진다.
    • 초보자에게는 설치 없이 링크로 여는 웹앱이 가장 현실적인 출발점이다.
    • 웹앱으로 시작해도 나중에 PWA와 Google Play로 넓힐 수 있다.

    AI의 첫 질문에 이제는 답할 수 있게 됐다. “웹앱으로 만들어 줘.” 그다음 과제는 머릿속 아이디어를 AI가 알아들을 수 있는 설명으로 바꾸는 일이었다.


    이전 글: 코딩 몰라도 AI로 앱 만들 수 있을까? 컴맹이 직접 해본 솔직 후기
    다음 글: 앱 아이디어, 한 줄이면 충분했다! 컴맹의 초간단 기획서 쓰는 법

  • 코딩 몰라도 AI로 앱 만들 수 있을까? 컴맹이 직접 해본 솔직 후기

    코딩 몰라도 AI로 앱 만들 수 있을까? 컴맹이 직접 해본 솔직 후기

    작성자: 컴맹 집사

    대표 이미지: 코딩을 몰라도 AI에게 말로 설명하며 앱을 만들 수 있을까 (사진: kaboompics / Pixabay)

    이 글에서 얻는 것

    • 이런 분께 코딩을 몰라도 AI로 앱을 만들 수 있을지 망설이는 분
    • 핵심 답 가능하다. 다만 AI가 코드를 써 줘도 무엇을 만들지 정하고 결과를 직접 눌러 확인하는 일은 내 몫이었다
    • 바로 쓰는 팁 한 번에 하나만 부탁하자. 디자인·질문·버튼을 한꺼번에 시키면 어디서 문제가 생겼는지 알기 어렵다

    결론부터 말하면 만들 수 있다. 다만 AI가 다 해 주지는 않는다.

    앱을 만들기 전에 “코딩 몰라도 AI로 앱 만들기”를 한참 찾아봤다. 5분 만에 앱이 뚝딱 나온다는 영상도 있었고, 결국 코딩을 배워야 한다는 글도 있었다. 둘 다 반은 맞고 반은 틀렸다. 왕립 개집사협회 앱을 직접 만들면서 그 사이 어딘가에 진짜 답이 있다는 걸 알게 됐다.

    AI가 정말 잘해 준 것

    1. 화면과 기능의 첫 뼈대
    “질문 7개에 답하면 집사 작위가 나오는 앱을 만들어 줘”라고 하자, AI는 몇십 초 만에 실제로 동작하는 코드를 줬다. 버튼을 누르면 다음 질문으로 넘어가고, 마지막에 결과가 나왔다. 혼자였다면 몇 주가 걸렸을 첫 단계가 한 번에 끝났다.

    2. 용어 설명
    GitHub, 배포, LocalStorage처럼 처음 듣는 말이 계속 나왔다. (출처: MDN 웹 문서, Web Storage API) 검색하면 개발자용 설명만 나와서 더 헷갈렸는데, AI에게 “코딩을 전혀 모르는 사람에게 비유로 설명해 줘”라고 하면 이해할 수 있는 말로 바꿔 줬다.

    3. 오류 해결
    화면이 하얗게 나오거나 버튼이 안 눌릴 때, 오류 메시지를 그대로 복사해서 붙여 넣으면 원인과 고치는 방법을 알려 줬다. 이 과정이 앱 만들기의 절반쯤 됐다.

    그래도 내가 해야 했던 것

    1. 무엇을 만들지 정하는 일
    AI는 시키는 걸 잘한다. 하지만 무엇을 시킬지는 내가 정해야 한다. “재미있는 앱 만들어 줘”라고 하면 평범한 결과가 나왔다. “질문 7개로 집사 유형 7가지를 가르고, 유형에 맞춰 5단계 작위를 주고, 결과 화면에 강아지 사진이 들어간 작위증”처럼 구체적으로 말할수록 결과가 좋아졌다.

    2. 확인하고 판단하는 일
    AI가 “수정했습니다”라고 해도 실제로 고쳐지지 않은 경우가 꽤 있었다. 결국 내가 직접 열어 보고, 눌러 보고, 이상한 점을 다시 말해 줘야 했다. AI는 만들고, 나는 검사하는 역할 분담이 자연스럽게 생겼다.

    3. 최소한의 개념 이해
    코드를 한 줄씩 짤 필요는 없었다. 하지만 파일은 어디에 있고, 어떻게 인터넷에 올라가고, 고치면 어떻게 반영되는지 정도의 큰 흐름은 알아야 했다. 이걸 모르면 AI가 알려 준 방법도 어디에 적용해야 할지 몰라서 헤맨다.

    4. 인내심
    한 번에 되는 일은 거의 없었다. 하나를 고치면 다른 게 망가지기도 했다. 이때 “방금 고친 뒤로 이게 안 돼”라고 차분히 다시 말하는 것이 가장 중요한 능력이었다.

    코딩을 몰라도 가능한 앱, 어려운 앱

    직접 해 보니 초보자가 AI로 만들기 좋은 앱과 어려운 앱이 나뉘었다.

    비교적 쉬운 앱 초보자에게 어려운 앱
    질문에 답하면 결과가 나오는 테스트 앱 회원가입·로그인이 필요한 앱
    계산기, 체크리스트, 메모 앱 여러 사용자가 실시간으로 대화하는 앱
    내 기기 안에만 저장하는 기록 앱 결제 기능이 들어가는 앱
    이미지 만들기·저장 앱 개인정보를 서버에 모으는 앱

    왼쪽은 내 휴대폰(브라우저) 안에서만 동작하는 앱이고, 오른쪽은 서버와 데이터베이스, 보안이 필요한 앱이다. 처음에는 왼쪽에서 시작하는 걸 추천한다. 왕립 개집사협회 앱도 왼쪽에 속한다. 로그인 없이 결과를 저장하는 방법은 뒤에서 따로 다룰 예정이다.

    처음 시작하는 분께 드리는 현실적인 조언

    소파에서 강아지를 안고 휴대폰을 보는 집사 그림
    결국 앱을 쓰는 사람은 휴대폰을 든 반려인이다
    출처: 직접 제작한 앱 그림(이미지 생성 AI 활용)
    • 작게 시작하자. 기능 하나가 제대로 돌아가는 게 기능 열 개가 반쯤 돌아가는 것보다 낫다.
    • 한 번에 하나만 부탁하자. “디자인 바꾸고, 질문 추가하고, 공유 버튼 넣어 줘”라고 한꺼번에 시키면 어디서 문제가 생겼는지 알기 어렵다.
    • AI의 말을 그대로 믿지 말고 직접 확인하자. 눌러 보고, 새로고침해 보고, 휴대폰으로도 열어 보자.
    • 모르는 단어는 그때그때 물어보자. 쌓아 두면 나중에 한꺼번에 무너진다.

    실제로 걸린 시간과 비중

    강아지 앱의 첫 버전(질문, 결과, 작위증까지)을 인터넷에 올리기까지 약 일주일이 걸렸다. 하루 한 시간 정도씩이었다. 시간을 나눠 보면 이랬다.

    • AI에게 요청하고 코드를 받는 시간: 전체의 10~20% 정도로 짧았다.
    • 받은 코드를 열어 보고 확인하는 시간: 약 30%. 눌러 보고, 새로고침하고, 휴대폰으로도 열었다.
    • 문제를 설명하고 고치는 시간: 가장 길어서 40% 가까이 됐다.
    • 처음 보는 개념을 이해하는 시간: GitHub, 배포 같은 것들. 나머지 시간이다.

    “AI가 몇 초 만에 앱을 만들어 준다”는 말은 맞지만, 그건 전체 과정의 일부일 뿐이다. 나머지 대부분은 확인하고 고치는 시간이었다. 이걸 미리 알았다면 처음 며칠 동안 덜 조급했을 것 같다.

    AI에게 질문할 때 효과가 컸던 방식

    • “코딩을 전혀 모르는 사람에게 설명하듯 말해 줘”를 붙인다.
    • 오류가 나면 오류 메시지 전체와 바로 전에 한 일을 함께 보낸다.
    • 방법이 여러 개라면 “초보자에게 가장 쉬운 방법 하나만 알려 줘”라고 한다.
    • 이해가 안 되면 “방금 설명에서 ○○가 무슨 뜻이야?”라고 다시 묻는다.

    시작 전에 알았으면 좋았을 것

    • AI가 준 코드가 한 번에 완벽하기를 기대하지 않는다. 처음 결과는 초안이다.
    • 대화가 길어지면 AI가 앞 내용을 헷갈리기도 한다. 그럴 때는 새 대화를 열고 현재 코드와 기획 내용을 다시 붙여 넣는 편이 낫다.
    • 잘 돌아가는 상태가 되면 그때마다 따로 보관해 둔다. 이 문제는 뒤에서 GitHub로 해결하게 된다.

    그래서, 할 수 있을까?

    할 수 있다. 다만 “AI가 알아서 앱을 만들어 준다”가 아니라 “AI라는 성실한 조수와 함께 내가 앱을 만든다”에 가깝다. 나는 코드를 쓰는 사람이 아니라, 무엇을 만들지 정하고 결과를 확인하고 방향을 잡는 사람이 됐다. 그게 생각보다 재미있었다.

    다음으로 부딪힌 건 뜻밖에도 아주 기초적인 질문이었다. 내가 만들려는 건 “앱”일까, “웹앱”일까?


    이전 글: 코딩 1도 모르는 집사가 강아지 때문에 앱을 만들게 된 사연
    다음 글: 앱이랑 웹앱, 뭐가 달라? 앱스토어 없이 앱 만든 컴맹의 깨달음