바이브 코딩이란 무엇인가

바이브 코딩은 대충 만드는 방식이 아니라 역할 분담이 바뀐 것입니다. 코드는 AI가 쓰고 무엇을 만들지는 사람이 정합니다. 병목이 구현력에서 머릿속 그림의 해상도로 옮겨 간 이유를 설명합니다.

8분 갱신

코스 소개에서 다섯 동작의 흐름을 보았습니다. 이 글은 그 흐름의 전제인 "바이브 코딩"이라는 말의 실체를 다룹니다. 유행어처럼 들리지만, 실제로 일어난 일은 만드는 사람과 정하는 사람이 분리된 것입니다. 읽고 나면 바이브 코딩이 왜 "대충"이 아닌지, 그리고 사람에게 어떤 일이 남는지 설명할 수 있습니다. 다음 편 도구는 딱 둘에서 실제 도구로 들어갑니다.

핵심 요약

  • 바이브 코딩은 코드를 AI가 쓰고 사람은 무엇을 만들지 정하는 역할 분담입니다.
  • 예전의 병목은 구현력이었지만 지금의 병목은 머릿속 그림의 해상도입니다.
  • 기술 공부는 줄었지만 "내 업무를 정확히 아는 것"의 가치는 커졌습니다.
  • 사람에게 남는 일은 정하기, 증거로 확인하기, 그만둘 때 알기입니다.

"분위기로 만든다"의 실체

바이브 코딩이라는 말은 "코드를 읽지 않고 느낌으로 만든다"는 뉘앙스로 퍼졌습니다. 그래서 오해가 생깁니다. 실체는 다릅니다. Claude Code 같은 에이전트에게 목표를 말로 주면, 도구가 파일을 읽고 계획을 세우고 코드를 쓰고 명령을 실행합니다. 사람은 그 과정에서 코드를 한 줄씩 읽는 대신 결과가 요구를 만족하는지를 봅니다. 즉 "분위기"가 아니라 "검증 지점이 바뀐 것"입니다. 우리 1주차 교재에서 챗봇과 에이전트를 구분하는 이유가 여기에 있습니다. 챗봇은 대답하고, 에이전트는 실제로 파일을 만들고 결과를 보고합니다.

만드는 사람과 쓰는 사람이 분리됐다

예전에는 만드는 사람이 곧 정하는 사람이었습니다. 개발자가 요구를 듣고, 해석하고, 구현하고, 다시 확인받았습니다. 지금은 만드는 쪽이 AI로 넘어갔고, 정하는 쪽만 사람에게 남았습니다. 원구연이 운영하는 이커머스 자동화도 그렇게 만들어졌습니다. 5개 브랜드와 14개 판매 채널의 매출을 합치는 대시보드를 원구연이 직접 코드로 짠 것이 아닙니다. "매일 아침 채널별 매출을 한 표로 모으고, 재고가 기준 아래로 떨어지면 표시해 달라"고 정확히 말했고, 결과가 실제 장부와 맞는지를 확인했습니다. 만드는 일과 정하는 일이 서로 다른 사람의 손에 있는 것, 이것이 바이브 코딩의 구조입니다.

예전과 지금, 뭐가 달라졌나

달라진 것을 세 가지로 정리하면 이렇습니다.

  1. 시작 비용입니다. 예전에는 개발 환경을 갖추는 데만 며칠이 걸렸습니다. 지금은 공식 문서의 설치 명령 한 줄과 로그인으로 끝납니다.
  2. 반복 속도입니다. "이 표에 컬럼 하나 추가"가 예전에는 외주 요청서와 일정 조율이었지만, 지금은 문장 하나입니다.
  3. 검증 방식입니다. 예전에는 코드 리뷰가 검증이었습니다. 지금은 실행 화면과 로그, 즉 증거가 검증입니다.

바뀌지 않은 것도 있습니다. 무엇을 만들지 모르면 아무것도 나오지 않는다는 점입니다. 오히려 이 점은 더 날카로워졌습니다.

병목은 "구현력"에서 "머릿속 그림의 해상도"로

Claude Code는 모호한 요청을 받으면 추측으로 채웁니다. "고객 관리 시스템 만들어 줘"라고 하면 어떤 시스템이든 나옵니다. 문제는 그것이 여러분의 업무와 맞지 않는다는 점입니다. 반대로 "고객명, 연락처, 유입경로, 관심상품, 상담내용, 진행상태, 마지막 상담일, 다음 액션, 담당자, 중요도 열 항목을 가진 표에서 마지막 상담일이 30일 지난 고객만 뽑아 달라"고 하면 바로 쓸 수 있는 것이 나옵니다. 두 요청의 차이는 코딩 실력이 아니라 그림의 해상도입니다. 우리 4주차 교재의 고객 DB 표준 10항목이 정확히 이 해상도를 올리는 도구입니다. 구현은 AI가 하므로, 성과는 "내 업무를 얼마나 정확히 아는가"에서 갈립니다.

그래도 남는 일

사람에게 남는 일은 세 가지입니다.

첫째, 정하는 일입니다. 누가 쓰는가, 어떤 화면에서 만지는가, 결과가 어떤 형태로 나가는가는 AI가 정할 수 없습니다. 이 코스의 8편과 9편이 여기에 해당합니다.

둘째, 증거로 확인하는 일입니다. AI가 "완료했습니다"라고 말해도 실행 화면이나 로그를 보기 전에는 끝난 것이 아닙니다. 우리 수업의 정지 규칙이 "증거"인 이유입니다.

셋째, 되돌릴 기준점을 만드는 일입니다. 큰 수정 전에 커밋을 남기고, DB를 바꾸기 전에 백업을 뜨는 것은 도구가 아니라 사람의 습관입니다. Claude Code에는 편집 전에 계획만 세우는 plan 모드가 있어서, Shift+Tab으로 전환하면 파일을 고치기 전에 계획을 먼저 받아 볼 수 있습니다. 습관을 도구가 받쳐 주는 구조입니다.

해 보기

Claude Code를 켜고 아래 두 요청을 차례로 던져 보십시오. 결과의 차이를 눈으로 확인하는 것이 목적입니다.

이 폴더의 파일을 정리해 줘.
이 폴더의 파일을 종류별로 하위 폴더에 나눠 정리해 줘.
옮기기 전에 어떻게 정리할지 계획을 먼저 보여 주고, 내가 승인하면 실행해.

두 번째 요청에서 "계획을 먼저 보여 주고 승인하면 실행"이라는 문장이 그림의 해상도이자 검증 지점입니다. 이 문장 하나가 코스 전체에서 반복됩니다.

정리

  • 바이브 코딩은 검증 지점이 코드에서 결과로 옮겨 간 방식입니다.
  • 만드는 사람은 AI, 정하는 사람은 여러분입니다.
  • 병목은 구현력이 아니라 그림의 해상도이므로 자기 업무를 아는 사람이 유리합니다.
  • 남는 일은 정하기, 증거로 확인하기, 되돌릴 기준점 만들기입니다.

자주 묻는 질문

바이브 코딩은 대충 만드는 방식인가요?

아닙니다. 코드를 읽지 않는 대신 결과를 검증하는 방식입니다. 대충이 되는 순간은 검증을 건너뛸 때이고, 그것은 코드를 직접 쓰던 시절에도 똑같이 사고로 이어졌습니다. 이 코스는 검증 게이트를 어디에 두는지를 계속 이야기합니다.

예전 개발과 지금은 무엇이 달라졌나요?

시작 비용, 반복 속도, 검증 방식이 달라졌습니다. 설치는 한 줄, 수정 요청은 문장 하나, 검증은 실행 화면과 로그입니다. 바뀌지 않은 것은 "무엇을 만들지 정하는 일"이 여전히 사람의 몫이라는 점입니다.

기술 공부는 필요 없나요?

문법 공부는 필요 없습니다. 다만 용어를 알아듣는 공부는 필요합니다. 커밋, 푸시, 브랜치 같은 단어를 서류 비유로라도 이해해야 AI의 보고를 읽을 수 있습니다. 2편에서 필요한 단어를 다섯 개로 줄여 드립니다.

그래도 사람이 해야 하는 일은 무엇인가요?

누가 언제 어떻게 쓰는지 정하는 일, 결과를 증거로 확인하는 일, 큰 변경 전에 되돌릴 기준점을 만드는 일입니다. 이 셋은 AI가 대신할 수 없고, 이 코스의 뒷부분 대부분이 이 세 가지를 다룹니다.

바이브 코딩역할 분담Claude Code비개발자

팀에 클로드코드를 도입하려면 실제 업무에 맞춘 설계가 필요합니다. 무료 상담 신청 →