AI 바이브코딩 : 비개발자는 코드보다 무엇을 먼저 봐야 할까요?
비개발자가 AI 바이브코딩으로 제품을 만들 때는 코드를 많이 아는 것보다 오류가 코드, 설정, 범위, 환경 중 어디에서 생겼는지 나눠 판단할 수 있어야 합니다. 저는 2026년 8월 여러 실습과 개인 OS 설치 기록에서 오류 여섯 번이 모두 코드 밖에서 난 경험을 하며 이 기준을 익혔습니다. AI PM에게 필요한 코딩 수준은 AI PM 코딩 능력에, 기술을 어디까지 이해해야 하는지는 AI 기획자 기술 지식에 따로 정리했습니다.
비개발자가 AI 바이브코딩을 하며 만난 오류 여섯 번이 모두 코드 문제가 아니었던 이유는 무엇인가요?
실제로 막힌 자리는 코드보다 배포, 환경, 권한, 경로에 있었고 설정과 범위를 바꿔 해결했습니다. 처음에는 화면이 제대로 뜨지 않거나 링크가 이상하면 코드를 먼저 봐야 한다고 생각하기 쉽습니다. 하지만 제가 만난 오류 여섯 번은 모두 코드 밖에 있었습니다. 그래서 비개발자가 AI 바이브코딩을 할 때는 모델 내부를 깊게 아는 것보다 코드, 설정, 범위, 환경 중 어디에서 문제가 생겼는지 나눠 보는 판단 기준을 준비해야 합니다.
예를 들어 브라우저에서 /admin/ 주소로 들어갔더니 파일이 열리지 않고 폴더 안의 목록이 보인 적이 있었습니다. 이때 코드를 새로 만드는 대신 폴더 주소인 admin/을 실제 파일까지 적은 admin/index.html로 바꿨습니다. 이런 오류가 나면 처음부터 코드 문제라고 정하기보다 주소와 설정, 배포 범위, 실행 환경처럼 코드 밖의 자리부터 하나씩 확인해야 합니다.
이 경험 뒤에는 명령어를 얼마나 많이 아는지보다 막힌 자리를 어떻게 나눠 볼지가 먼저라는 기준이 생겼습니다. 어디가 문제인지 나눌 수 있어야 다음에 확인할 자리도 정할 수 있습니다.
비개발자 코딩에서 Vercel 배포 범위를 어떻게 좁혀 문서 노출을 막을 수 있나요?
Vercel에 올릴 폴더를 따로 정하고, 공개되면 안 되는 주소가 실제로 열리지 않는지 확인하면 문서 노출을 막을 수 있습니다. Vercel은 만든 서비스를 인터넷에서 접속할 수 있게 올리는 배포 도구입니다. 저는 처음에 코드 저장소를 Private으로 두면 안에 있는 파일도 밖에서 볼 수 없을 거라고 생각했습니다. 하지만 저장소가 비공개여도 Vercel로 배포한 결과물은 공개될 수 있었습니다. 실제로 접수대장과 안내규정이 주소만 알면 열리는 상태였습니다.
그래서 저는 Vercel이 어느 폴더부터 밖으로 내보낼지를 정하는 Root Directory를 starter로 지정했습니다. 쉽게 말하면 프로젝트 전체를 공개하는 대신, 서비스에 필요한 starter 폴더부터 배포하도록 범위를 줄인 것입니다. 그다음 공개되면 안 되는 /client-docs/ 주소를 직접 입력해 봤습니다. 페이지를 찾을 수 없다는 404가 뜨는 것까지 확인한 뒤에야 문서가 배포 대상에서 빠졌다고 판단했습니다.
이 경험을 통해 비개발자 코딩에서는 서비스가 인터넷에 잘 뜨는지만 보면 안 된다는 것을 배웠습니다. 무엇을 보여 줄지뿐 아니라 무엇은 절대 보이면 안 되는지도 먼저 정하고, 설정을 바꾼 뒤 실제 주소로 다시 확인해야 합니다.
비개발자 코딩에서 같은 기능이 맥과 윈도우에서 다르게 막힐 때 어떻게 확인할 수 있나요?
다른 사람도 쓸 수 있게 만든 것을 공유하려면 맥과 윈도우처럼 서로 다른 운영체제에서 설치 과정을 처음부터 확인하고, 막힌 단계와 해결 방법을 따로 남겨야 합니다. 저는 개인 OS 스타터를 혼자 쓰는 데서 끝내지 않고 다른 사람도 따라 쓸 수 있게 공유하려고 했습니다. 그러려면 제가 쓰는 환경에서 한 번 실행됐다는 것만으로는 부족했습니다. 사용하는 사람이 맥을 쓸 수도 있고 윈도우를 쓸 수도 있어서 두 환경을 모두 고려해야 했습니다.
그래서 2026년 8월 6일 맥과 윈도우에서 개인 OS 스타터 설치를 각각 처음부터 다시 진행했습니다. 같은 스타터를 설치해도 운영체제가 달라지면 같은 단계에서 똑같이 움직이지 않았습니다. 특히 Enter 입력이 사라지는 것처럼 프로그램이 완전히 멈추지는 않지만 결과가 달라지는 문제는 바로 알아채기 어려웠습니다. 저는 이런 증상도 지나치지 않고 어느 단계에서 무엇이 달랐는지 따로 적었습니다.
해결 방법도 한 번 고치고 끝내지 않았습니다. 설치 과정을 다시 밟으면서 만난 문제와 해결 방법을 단계별로 남겼고, Vercel 배포와 GitHub 연결처럼 두 번 이상 반복되는 작업은 절차 문서로 따로 뺐습니다. 처음에는 제 컴퓨터에서 되면 설치가 끝난 것이라고 생각할 수 있지만, 공유하려면 다른 운영체제에서도 어디서 막히는지 확인할 수 있어야 했습니다.
이 경험을 통해 비개발자 코딩에서도 다양한 사용 환경을 미리 생각해야 한다는 것을 배웠습니다. 코드를 더 만드는 것보다 누가 어떤 환경에서 쓸지 생각하고, 각 환경에서 생기는 차이를 직접 확인해 다시 따라 할 수 있는 기록으로 남기는 일이 필요했습니다.
AI PM 코딩에서 모델이 바뀌었을 때 모델명이 적힌 24곳을 어떻게 확인할 수 있나요?
모델 목록이 정상인지 먼저 확인한 뒤 코드 기본값, 주석, `.env`, `.env.example`처럼 모델명이 남은 자리를 함께 찾아 바꿀 수 있습니다. 어느 날 챗봇에서 HTTP Error 404가 났을 때 처음부터 코드를 고치지 않았습니다. 먼저 모델 목록을 조회해 37개가 정상으로 오는 것을 확인했고, 그다음 사용하던 모델이 더 이상 제공되지 않는다는 오류 내용을 확인했습니다.
모델명은 한 군데만 바꾸면 끝나는 상태도 아니었습니다. 코드 기본값, 주석, .env, .env.example 네 곳씩 여섯 단계에 걸쳐 모두 24곳에 모델명이 들어 있었습니다. 특히 .env.example을 그대로 두면 다음에 파일을 복사할 때 이전 모델명이 다시 들어올 수 있었습니다.
AI 바이브코딩에서 LLM 내부 계산을 직접 다루기보다 모델이 바뀌는 자리와 입력, 출력, 토큰, 대화 기록처럼 제품에 영향을 주는 부분을 설명할 수 있어야 합니다. 실제로 모델을 바꾼 뒤 답이 중간에서 잘렸을 때는 출력 길이를 1024에서 2048로 올려 해결했습니다. 모델 내부를 여는 대신 무엇을 넣었고 어떤 결과가 나왔는지 확인하는 방식입니다.
비전공자 취업을 준비하며 AI 바이브코딩 결과물에서 어떤 판단 역량을 보여줄 수 있나요?
결과물 자체보다 할 수 있는 것과 없는 것의 경계, 판단 기준, 예외 상황을 어떻게 확인했는지를 보여줄 수 있습니다. 아이엠 21회차 PM 의사결정 강의에서 강사님께서는 잘하느냐 못하느냐보다 자신이 할 수 있는 것과 없는 것을 객관적으로 아는 것이 먼저라고 설명하셨습니다. 비전공자 취업을 준비할 때도 AI 바이브코딩으로 무엇을 만들었다는 결과만이 아니라 어떤 기준으로 문제를 나눴는지까지 정리할 수 있습니다.
저도 처음에는 여섯 개를 꼭 고쳐야 한다고 판정했지만, 다시 확인하니 실제로 고쳐야 할 것은 두 개였습니다. 기준 없이 있으면 좋을 것 같은 것을 고칠 대상으로 잡았기 때문입니다. 비개발자 코딩을 할 때도 잘하는 것보다 무엇을 할 수 있는지와 없는지, 어떤 경우에는 고치고 어떤 경우에는 보류해야 하는지부터 객관적인 기준으로 나눠야 합니다.
운영 단계에서도 같은 판단이 필요했습니다. 중장년·시니어가 쓰는 서비스에서는 굴착기운전기능사를 포크레인, 지게차를 찍차라고 부르는 경우가 있었습니다. 비개발자가 AI 바이브코딩으로 만든 서비스를 운영할 때는 프롬프트만 고치기보다 같은 대상을 가리키는 표현의 범위를 정하고 운영자가 직접 동의어를 관리할 수 있게 만들 수 있습니다. 저는 넣어도 되는 표현과 다른 자격증처럼 넣으면 안 되는 표현을 화면에 나눠 적고, 실제 사투리 질문으로 동의어 반영 전후를 확인했습니다.
이런 경험은 코드를 얼마나 직접 작성했는가보다 제품이 잘못 움직일 수 있는 경계를 어떻게 찾고 확인했는지를 보여 줍니다. AI PM의 준비 과정에서 어떤 경험을 골라 설명할지는 AI PM 준비하기에서 이어서 확인할 수 있습니다.
AI 바이브코딩에서 비개발자는 코드보다 무엇을 먼저 봐야 할까요?
비개발자는 코드를 바로 고치기보다 문제가 생긴 자리를 나누고, 바꿔도 되는 범위와 실제 결과를 확인하는 기준부터 봐야 합니다. 제가 만난 문제도 배포 범위, 운영체제, 모델 변경, 사용자 표현처럼 코드 바깥에서 갈리는 경우가 있었습니다. 그래서 AI 바이브코딩에서는 무엇을 만들었는지만큼 어디가 문제인지 구분하고, 바꾼 뒤 실제로 해결됐는지 확인하는 과정이 필요했습니다.
AI PM이 코드를 어느 수준까지 알아야 하는지는 AI PM 기술과 데이터에서 확인할 수 있습니다.

재료
- 오류가 난 화면과 경로, 배포 설정, 운영체제별 설치 기록, 모델 목록과 환경 파일
순서
- 오류가 났을 때 코드 문제라고 먼저 정하지 않고 코드·설정·범위·환경으로 나눕니다.
- 배포 문제라면 Root Directory와 실제 접속 경로를 확인합니다.
- 환경 문제라면 맥과 윈도우에서 설치 과정을 처음부터 다시 밟아 차이를 기록합니다.
- 모델 오류라면 모델 목록이 정상인지 확인한 뒤 모델명이 남은 파일과 설정을 함께 찾습니다.
- 값을 바꾼 뒤에는 실제 주소, 화면, 답변으로 문제가 해결됐는지 다시 확인합니다.
여기서 대개 틀어집니다
오류가 나자마자 코드 문제라고 확신하면 배포 범위, 환경, 모델 변경처럼 코드 밖의 원인을 놓칠 수 있습니다.
- 「코드가 아닌 자리에서 막히는 것들」 - 오류 여섯 번이 코드 문제가 아니었던 경험, Vercel 배포 범위, 맥·윈도우 설치 기록, 경로 수정
- 「하면 안 되는 것의 경계를 먼저 안다」 - 할 수 있는 것과 없는 것의 기준, 6개에서 2개로 바뀐 판정, 보류 기준
- 「쓰는 사람의 말로 알아듣게 만들기」 - 포크레인·찍차 동의어와 운영자가 관리하는 말 바꾸기 화면
- 「LLM 을 어디까지 알아야 하나」 - 모델 목록 37개 확인, 모델명이 적힌 24곳, 출력 길이 1024에서 2048로 변경한 경험
비개발자가 AI 바이브코딩을 하며 만난 오류 여섯 번이 모두 코드 문제가 아니었던 이유는 무엇인가요?
실제로 막힌 자리는 코드보다 배포, 환경, 권한, 경로에 있었고 설정과 범위를 바꿔 해결했습니다.
비개발자 코딩에서 Vercel 배포 범위를 어떻게 좁혀 문서 노출을 막을 수 있나요?
저장소 공개 여부만 볼 것이 아니라 Root Directory와 실제 접속 경로를 확인해 배포되는 범위를 줄일 수 있습니다.
비개발자 코딩에서 같은 기능이 맥과 윈도우에서 다르게 막힐 때 어떻게 확인할 수 있나요?
운영체제마다 설치 과정을 처음부터 다시 밟고, 눈에 잘 띄지 않는 증상까지 단계별로 기록해 차이를 확인할 수 있습니다.
AI PM 코딩에서 모델이 바뀌었을 때 모델명이 적힌 24곳을 어떻게 확인할 수 있나요?
모델 목록이 정상인지 먼저 확인한 뒤 코드 기본값, 주석, `.env`, `.env.example`처럼 모델명이 남은 자리를 함께 찾아 바꿀 수 있습니다.
비전공자 취업을 준비하며 AI 바이브코딩 결과물에서 어떤 판단 역량을 보여줄 수 있나요?
결과물 자체보다 할 수 있는 것과 없는 것의 경계, 판단 기준, 예외 상황을 어떻게 확인했는지를 보여줄 수 있습니다.
AI 바이브코딩에서 비개발자는 코드보다 무엇을 먼저 봐야 할까요?
비개발자는 코드를 바로 고치기보다 문제가 생긴 자리를 나누고, 바꿔도 되는 범위와 실제 결과를 확인하는 기준부터 봐야 합니다.