바이브코딩에서 개발을 배운다는 건 논리 흐름을 이해하는 일입니다

AI에게 원하는 기능을 설명하면 몇 분 만에 화면이 만들어집니다. 버튼도 생기고 입력창도 보입니다. 그래서 바이브코딩을 처음 접하면 개발은 AI에게 정확한 프롬프트를 쓰는 일처럼 느껴질 수 있어요.

하지만 실제로 사용하는 소프트웨어를 만들기 시작하면 프롬프트만으로 풀리지 않는 순간이 찾아옵니다.

데이터베이스를 연결했는데 제출 버튼을 눌러도 저장되지 않아요.
내 컴퓨터에서는 되는데 배포한 주소에서는 작동하지 않아요.
AI는 수정했다고 하는데 같은 문제가 계속 생겨요.

이때 필요한 것은 더 그럴듯한 프롬프트 하나가 아닙니다. 원래 어떤 순서로 작동해야 하는지 그리고, 그 흐름이 어디에서 끊겼는지 찾는 사고입니다.

바이브코딩 시대에도 개발의 중요한 부분은 코드를 직접 입력하는 일이 아니라 화면, 서버, 데이터와 사용자의 행동을 하나의 논리적인 흐름으로 연결하는 일입니다. AI가 코드를 작성해도 무엇이 연결되어야 하는지 이해하고 결과를 확인하는 일은 만드는 사람의 몫으로 남습니다.

기능 하나에도 여러 단계가 연결되어 있습니다

신청서를 예로 들어볼게요. 화면에 이름과 연락처를 입력하는 칸을 만들었다고 해서 신청 기능이 완성된 것은 아닙니다.

정상적인 제출은 대략 이런 흐름으로 작동합니다.

사용자가 신청서를 작성합니다.
→ 제출 버튼을 누릅니다.
→ 화면이 입력값을 확인합니다.
→ 서버로 제출 요청을 보냅니다.
→ 서버가 요청을 받아 처리합니다.
→ 데이터베이스에 신청 내용을 저장합니다.
→ 서버가 성공 또는 실패 결과를 돌려줍니다.
→ 화면이 사용자에게 결과를 보여줍니다.

사용자에게는 버튼을 한 번 누르는 일로 보이지만, 내부에서는 여러 경계를 지나갑니다.

개발은 이 흐름을 만드는 일이고, 디버깅은 이 흐름에서 마지막으로 정상 작동한 지점과 처음 실패한 지점 사이를 찾는 일입니다.

데이터베이스를 연결했는데 왜 제출되지 않을까요?

“데이터베이스를 연결했다”는 말은 데이터베이스 주소와 비밀번호를 설정했거나 테이블을 만들었다는 뜻일 수 있습니다. 하지만 연결이 있다는 사실과 신청서가 저장된다는 사실은 다릅니다.

예를 들어 AI에게 다음 두 작업을 따로 요청했다고 해볼게요.

1. 신청서 화면을 만들어줘.
2. 신청 정보를 저장할 데이터베이스를 연결해줘.

화면과 데이터베이스가 각각 존재하더라도 둘 사이에서 제출을 처리하는 서버 로직이 빠질 수 있습니다.

신청 화면          데이터베이스
    │                   │
    └── 제출 로직 없음 ──┘

이 상태에서는 입력창이 잘 보이고 데이터베이스 연결 테스트도 성공할 수 있습니다. 그러나 버튼을 눌렀을 때 데이터를 서버로 보내고 저장하는 코드가 없으므로 아무것도 기록되지 않아요.

이 문제를 만났을 때 “데이터베이스가 안 돼요”라고만 설명하면 AI는 권한, 테이블 이름, 비밀번호와 네트워크 문제까지 넓은 가능성을 한꺼번에 살필 수 있습니다. 먼저 흐름을 나누면 확인할 범위가 작아집니다.

1. 버튼을 눌렀을 때 제출이 시작되는지 확인합니다

버튼이 단순히 화면에만 존재하는지, 클릭 이벤트가 제출 함수와 연결되어 있는지 봅니다. 버튼을 눌러도 아무 변화가 없다면 아직 데이터베이스를 조사할 단계가 아닐 수 있어요.

2. 브라우저가 서버로 요청을 보냈는지 확인합니다

브라우저 개발자 도구의 네트워크 탭을 보면 요청이 발생했는지, 어느 주소로 보냈는지, 어떤 상태 코드가 돌아왔는지 확인할 수 있습니다.

요청 자체가 없음
→ 화면의 버튼과 제출 함수부터 확인

요청은 있지만 404
→ 요청한 주소와 서버 경로 확인

요청은 있지만 500
→ 서버 로그에서 처리 중 발생한 오류 확인

상태 코드가 낯설더라도 외울 필요는 없습니다. 화면을 캡처하거나 내용을 복사해 AI에게 각 항목이 무엇을 뜻하는지 설명해달라고 하면 됩니다.

3. 서버에 제출 처리 로직이 있는지 확인합니다

요청을 받는 서버 경로가 존재하는지, 받은 입력값을 검사하는지, 데이터베이스 저장 명령을 실행하는지 순서대로 봅니다. 이 단계에서 서버 제출 로직이 누락됐다는 사실을 찾을 수 있습니다.

4. 데이터베이스에서 실제 저장 결과를 확인합니다

화면에 “신청이 완료되었습니다”라고 표시됐다는 이유만으로 저장에 성공했다고 판단하면 안 됩니다. 데이터베이스에서 새 행이 생겼는지 직접 확인해야 합니다.

반대로 데이터베이스에는 저장됐는데 화면이 계속 로딩 중일 수도 있어요. 이때 문제는 저장이 아니라 서버가 결과를 돌려주거나 화면이 그 결과를 처리하는 마지막 구간에 있습니다.

중요한 것은 가능한 원인을 많이 떠올리는 능력이 아닙니다. 어디까지 정상인지 확인해 다음 조사 범위를 줄이는 능력입니다.

로컬에서는 되는데 배포하면 왜 안 될까요?

내 컴퓨터의 localhost에서 잘 작동하는 기능이 실제 배포 주소에서는 실패하는 일도 같은 방식으로 살펴볼 수 있습니다.

먼저 로컬과 배포 환경은 같은 화면처럼 보여도 서로 다른 조건에서 실행된다는 점을 이해해야 합니다.

로컬
내 컴퓨터의 현재 파일
→ 내 컴퓨터의 환경변수
→ 개발용 서버
→ 로컬에서 접근하는 외부 서비스

배포
GitHub에 올라간 커밋
→ 배포 서비스의 환경변수
→ 빌드와 배포 서버
→ 실제 도메인에서 접근하는 외부 서비스

로컬에서 된다는 것은 현재 내 컴퓨터의 코드와 설정 조합이 작동한다는 뜻입니다. 그 코드가 GitHub에 올라갔는지, 배포 서비스가 그 커밋을 사용했는지, 같은 환경변수가 배포 설정에도 있는지까지 보장하지는 않습니다.

코드의 버전이 같은지 확인합니다

로컬에서 잘 된 변경을 커밋하지 않았거나 커밋은 했지만 GitHub에 push하지 않았을 수 있습니다. 배포가 실패한 것이 아니라 배포 서비스가 아직 이전 코드를 정상적으로 보여주고 있는 상황일 수도 있어요.

로컬에서 확인한 파일
→ 필요한 변경을 커밋
→ GitHub에 push
→ 배포가 최신 커밋으로 완료

이 흐름의 각 단계에서 같은 변경이 이어지는지 확인해야 합니다.

환경변수가 배포 환경에도 있는지 확인합니다

데이터베이스 주소나 API 키는 보안을 위해 코드 파일이 아니라 환경변수에 저장하는 경우가 많습니다. 내 컴퓨터의 .env 파일은 일반적으로 GitHub에 올리지 않으므로 배포 서비스가 자동으로 가져갈 수 없습니다.

내 컴퓨터의 환경변수 있음
≠
배포 서비스의 환경변수 있음

로컬에서는 데이터베이스에 연결되지만 배포한 버전에서는 연결되지 않는다면, 배포 서비스에 필요한 환경변수가 등록됐는지와 변수 이름이 정확히 같은지 확인해야 합니다. 값을 새로 등록한 뒤에는 다시 배포해야 적용되는 서비스도 있어요.

외부 서비스가 실제 도메인을 허용하는지 확인합니다

로그인, 결제나 외부 API는 허용된 주소를 따로 관리하기도 합니다. localhost는 등록되어 있지만 실제 도메인이 빠져 있다면 코드가 같아도 배포 환경에서만 실패할 수 있습니다.

배포 환경의 로그를 확인합니다

로컬 터미널에 나타나던 서버 메시지는 배포 후에는 배포 서비스의 로그에 기록됩니다. 배포한 사이트의 문제를 찾으면서 로컬 터미널만 보고 있다면 서로 다른 실행 환경을 관찰하고 있는 셈입니다.

로컬에서는 되는데 배포하면 안 될 때 확인할 순서에서 커밋, push, 배포 커밋과 환경변수를 단계별로 더 자세히 확인할 수 있습니다.

문제를 논리적으로 좁히는 다섯 단계

데이터 제출, 로그인, 결제와 배포는 서로 다른 기능이지만 문제를 찾는 기본 순서는 같습니다.

1. 정상 흐름을 문장으로 적습니다

코드부터 열기 전에 사용자의 행동부터 결과까지 어떤 순서로 이어져야 하는지 적습니다.

로그인 버튼 클릭
→ 인증 요청
→ 사용자 확인
→ 로그인 정보 저장
→ 원래 화면으로 이동

완벽한 기술 용어를 몰라도 괜찮습니다. 내가 기대하는 순서를 일상적인 말로 적는 것만으로 빠진 단계가 보일 수 있습니다.

2. 문제를 같은 방법으로 다시 만듭니다

어쩌다 한 번 실패한 상황과 계속 실패하는 상황은 다릅니다. 어떤 화면에서 무엇을 입력하고 어떤 버튼을 눌렀을 때 문제가 생기는지 다시 확인합니다.

3. 추측보다 증거를 먼저 모읍니다

화면의 오류 메시지, 브라우저 네트워크 요청, 서버 로그, 배포 로그와 데이터베이스의 실제 행을 확인합니다. AI에게도 “가능한 원인을 말해줘”보다 현재 확인한 증거를 전달하는 편이 좋습니다.

신청서 제출 문제를 조사하고 있어.

- 버튼을 누르면 POST /api/apply 요청은 발생해.
- 응답 상태는 500이야.
- 데이터베이스에는 새 행이 없어.
- 아래는 같은 시각의 서버 로그야.

아직 코드를 수정하지 말고,
어느 구간까지 정상인지와 다음에 확인할 한 가지를 설명해줘.

4. 처음 끊긴 경계를 찾습니다

데이터베이스에 값이 없다는 사실만으로 데이터베이스 문제라고 결론 내리지 않습니다. 서버가 저장 명령을 실행하기 전에 입력값 검사에서 멈췄을 수도 있어요.

가장 마지막으로 성공한 지점과 가장 처음 실패한 지점을 찾으면 조사해야 할 범위가 작아집니다.

5. 한 가지를 바꾸고 같은 행동으로 다시 검증합니다

AI가 제시한 여러 해결책을 한꺼번에 적용하면 무엇이 원인이었는지 알기 어렵고 다른 문제가 생겨도 되돌리기 어렵습니다.

가장 가능성이 높은 한 가지를 수정한 뒤 처음과 같은 입력과 행동으로 다시 테스트합니다. 화면만 보지 말고 요청, 로그와 데이터 저장까지 확인해야 합니다.

정상 흐름 그리기
→ 문제 재현하기
→ 증거 확인하기
→ 끊긴 경계 찾기
→ 하나만 수정하기
→ 같은 방법으로 다시 검증하기

이 순서를 반복하면 AI의 답을 무작정 믿는 대신 AI와 함께 문제를 조사할 수 있습니다.

무작정 따라 만든 프로젝트에서는 이 흐름을 배우기 어렵습니다

정해진 영상을 보며 강사와 똑같은 화면을 만드는 방식은 도구의 기본 사용법을 익히는 데 도움이 됩니다. 그러나 모든 사람이 같은 예제와 설정을 사용하면 예상하지 못한 문제를 만날 기회가 적습니다.

예제를 따라 만드는 수업과 개인 프로젝트를 만드는 수업의 차이를 비교하면 수업 중 결과물뿐 아니라 수료 뒤 혼자 만들 수 있는지를 왜 확인해야 하는지 알 수 있습니다.

실제 프로젝트에서는 사람마다 흐름이 다릅니다.

누군가는 고객 신청을 저장합니다.
누군가는 엑셀 업무를 자동화합니다.
누군가는 로그인과 결제가 있는 서비스를 만듭니다.
누군가는 외부 API에서 데이터를 가져옵니다.

각자 다른 프로젝트를 만들면 다른 지점에서 막힙니다. 이때 강사가 정답 코드를 대신 입력해주는 데서 끝나면 수업이 끝난 뒤 같은 문제가 생겼을 때 다시 멈출 수 있어요.

필요한 것은 다음 질문을 함께 반복하는 일입니다.

• 원래 어떤 순서로 작동해야 하나요?
• 지금 직접 확인한 사실은 무엇인가요?
• 마지막으로 정상인 지점은 어디인가요?
• 로컬과 배포 환경에서 달라진 것은 무엇인가요?
• 수정한 뒤 같은 행동으로 다시 확인했나요?

뚝딱에서는 문제를 해결하는 사고 순서를 연습합니다

뚝딱은 강사의 완성 화면을 무작정 따라 만드는 대신 수강생이 각자 필요한 소프트웨어를 만드는 강남 오프라인 바이브코딩 강의입니다. 업무 자동화 도구, 모바일 앱, 창업 MVP와 프로토타입처럼 사람마다 다른 프로젝트를 4주 동안 진행합니다.

수업 중 문제가 생기면 강사가 결과만 고쳐주는 것이 아니라 수강생의 실제 화면과 로그를 함께 보며 정상 흐름을 다시 그립니다. 그리고 어느 단계까지 작동했는지, 다음에는 무엇을 확인해야 하는지, 수정 후 어떤 행동으로 검증해야 하는지를 함께 확인합니다.

답을 바로 알려주는 대신 흐름을 설명하게 하거나 다음 확인 지점을 되묻는 것도 같은 훈련입니다. 뚝딱 강사가 수강생 질문에 바로 답하지 않는 이유에서 실제 수업의 질문 방식을 더 자세히 설명했습니다.

오프라인에서 같은 화면을 보는 이유도 여기에 있습니다. 입문자는 에러 메시지 자체보다 어떤 화면, 네트워크 요청과 로그를 보여줘야 하는지부터 막힐 수 있기 때문입니다. 강사와 함께 조사 과정을 반복하면서 다음에는 혼자서도 AI에게 필요한 정보를 전달하고 원인을 좁힐 수 있게 합니다.

뚝딱이 바이브코딩 강의를 오프라인으로 진행하는 이유에서도 수업 방식과 온라인 학습의 차이를 자세히 설명했습니다.

수업의 목표는 에러가 없는 프로젝트가 아닙니다

소프트웨어를 만들면서 에러를 완전히 피할 수는 없습니다. 익숙한 개발자도 새로운 기능과 환경을 만나면 계속 문제를 조사합니다. 차이는 에러가 생겼을 때 멈추느냐, 확인할 순서를 세우고 다음 행동을 정할 수 있느냐에 있습니다.

뚝딱의 목표는 4주 동안 강사의 도움으로 프로젝트 하나만 완성하는 데서 끝나지 않습니다. 수업이 끝난 뒤 새로운 아이디어를 만났을 때도 다음과 같이 생각할 수 있도록 돕는 것입니다.

내가 만들려는 흐름은 무엇인가?
→ 지금 어디까지 작동하는가?
→ 어느 경계에서 끊겼는가?
→ 무엇을 보면 사실을 확인할 수 있는가?
→ 하나를 고친 뒤 어떻게 검증할 것인가?

AI가 코드를 작성해주는 시대에는 코드를 모두 외우는 능력보다 전체 흐름을 설명하고, 끊긴 지점을 찾고, 결과를 검증하는 능력이 더 중요해집니다.

개발을 배운다는 것은 모든 정답을 기억하는 일이 아닙니다. 처음 보는 문제 앞에서도 흐름을 따라 다음 확인 지점을 찾을 수 있게 되는 일입니다.

현재 과정과 일정은 뚝딱 오프라인 바이브코딩 강의에서 확인할 수 있습니다.