Claude Code 바이브 코딩, 실제로 어떤 일이 벌어지는가

Claude Code 바이브 코딩, 실제로 어떤 일이 벌어지는가

바이브 코딩(vibe coding)은 결과물의 세부 코드를 직접 작성하지 않고, AI에게 원하는 결과를 말로 설명하여 코드를 생성하는 방식입니다. 개념 자체는 단순하지만, "실제로 AI가 어떤 순서로 무엇을 하는지"를 본 적 있는 분은 많지 않습니다.

이 글에서는 Claude Code에 요청 한 줄을 입력했을 때, 화면에 나타나는 작업 로그를 한 줄씩 따라가며 해설하겠습니다. 실제 시나리오는 "채널 그룹 UI를 좌측 사이드바와 우측 채널 목록 레이아웃으로 바꿔달라"는 요청이었고, Claude Code가 HTML 템플릿 3개, 백엔드 라우터 1개, CSS 스타일과 모바일 반응형까지 자동으로 완성한 과정입니다.

바이브 코딩을 할때 자주보는 장면

 

 

 

 

Claude Code 작업 화면에 등장하는 4가지 도구

Claude Code가 작업을 수행할 때, 터미널 화면에는 Write, Read, Edit, Grep이라는 라벨이 반복적으로 등장합니다. 이 네 가지는 Claude Code가 파일을 다루는 기본 도구이고, 각각 하는 일이 완전히 다릅니다. 비개발자를 위해 일상적인 비유로 정리하면 다음과 같습니다.

 

Write는 새 파일을 처음부터 생성하는 도구입니다. 비유하자면 빈 종이를 꺼내서 처음부터 글을 쓰는 것과 같습니다. 이번 시나리오에서 groups.html(29줄), group_sidebar.html(30줄), group_detail.html(66줄), routers/groups.py(159줄) 등 4개 파일이 모두 Write로 생성되었습니다. 아직 존재하지 않는 파일을 만들어야 할 때 사용됩니다.

 

Read는 이미 있는 파일의 특정 부분을 열어보는 도구입니다. 책꽂이에서 책을 꺼내 특정 페이지를 펴보는 것과 같습니다. 이번 시나리오에서 style.css의 549~578줄, 1081~1090줄을 확인한 것이 Read입니다. Claude Code가 기존 코드의 구조를 파악하거나, 수정할 위치를 정확히 찾기 위해 사용합니다.

 

Edit는 이미 있는 파일의 특정 부분만 수정하는 도구입니다. 교정 펜으로 원고의 특정 문장만 고치는 것과 같습니다. 기존 style.css에 175줄의 레이아웃 스타일을 추가하고, 이어서 23줄의 모바일 반응형 코드를 추가한 것이 모두 Edit입니다. 파일 전체를 새로 쓰는 것이 아니라, 기존 내용을 유지하면서 필요한 부분만 변경합니다.

 

Grep은 파일 내에서 특정 단어나 패턴을 검색하는 도구입니다. 문서에서 Ctrl+F를 눌러 원하는 단어를 찾는 것과 동일한 역할입니다. 이번 시나리오에서 "Small phones"라는 문구를 검색하여 모바일 반응형 CSS를 삽입할 정확한 위치를 찾았습니다. Claude Code가 수백, 수천 줄짜리 파일에서 원하는 지점을 빠르게 찾아낼 때 사용합니다.

 

 
직접 써보니까 이 네 가지 도구를 구분할 수 있게 되면 Claude Code의 작업 로그가 갑자기 읽히기 시작합니다. 마치 외국어 자막이 갑자기 해석되는 느낌이라고 할 수 있습니다. 처음에는 빠르게 지나가는 로그가 무의미해 보이지만, Write/Read/Edit/Grep만 구분해도 "지금 새 파일을 만들고 있구나", "기존 파일을 확인하고 있구나"를 즉시 파악할 수 있습니다.

요청 한 줄이 13단계 작업으로 분해되는 과정

이번 시나리오에서 사용자가 입력한 것은 "채널 그룹 UI를 좌측 사이드바 + 우측 채널 목록 레이아웃으로 바꿔달라"는 한 줄뿐이었습니다. 그런데 Claude Code는 이 한 줄을 받아서 총 13단계의 작업을 스스로 설계하고 실행했습니다. 이 과정을 크게 3단계로 나눌 수 있습니다.

1단계: 설계 판단. Claude Code는 코드를 작성하기 전에 먼저 프로젝트의 현재 상태를 분석했습니다. "이 기능은 이미 백엔드에 구현되어 있습니다(채널 그룹 CRUD). UI만 바꾸면 됩니다."라는 판단을 내린 것이 핵심입니다. 사용자는 "UI를 바꿔달라"고만 했는데, Claude Code는 백엔드 코드를 확인한 뒤 "백엔드는 이미 있으니 프론트엔드(화면)만 수정하면 된다"는 결론을 먼저 내렸습니다. 이것은 단순한 코드 생성이 아니라, 프로젝트 구조를 이해한 위의 판단입니다.

 

2단계: 새 파일 생성. 판단이 끝나면 Write 도구로 필요한 파일을 차례로 만들었습니다. 메인 페이지 템플릿(groups.html), 사이드바 부분 템플릿(group_sidebar.html), 상세보기 템플릿(group_detail.html), 그리고 백엔드 라우터(routers/groups.py)까지 4개 파일을 순서대로 생성했습니다. 각 파일의 역할이 명확히 분리되어 있다는 점이 중요합니다. 하나의 거대한 파일에 모든 것을 몰아넣지 않고, 템플릿 3개와 라우터 1개로 나누어 생성한 것입니다.

 

3단계: 기존 파일 수정 및 보강. 새 파일 생성이 끝나면 기존 파일을 수정하는 단계로 넘어갑니다. 여기서 Read, Edit, Grep이 함께 동작합니다. 먼저 Read로 기존 style.css의 내용을 확인하고, Edit로 175줄의 레이아웃 스타일을 추가합니다. 그다음 Grep으로 "Small phones"라는 문구를 검색하여 반응형 CSS가 들어갈 위치를 찾고, 다시 Read로 해당 위치 주변을 확인한 뒤, Edit로 23줄의 모바일 반응형 코드를 추가합니다. 이 과정이 바로 "기존 코드를 망가뜨리지 않으면서 새로운 기능을 끼워넣는" 작업입니다.

 

 
이 3단계 구조(판단, 생성, 수정)는 사실 숙련된 개발자가 작업하는 순서와 거의 동일합니다. 프로젝트 상태를 먼저 파악하고, 없는 것을 만들고, 있는 것은 고치는 흐름입니다. Claude Code가 이 순서를 스스로 결정했다는 점이 바이브 코딩의 핵심입니다.

 

Claude Code가 단순 코드 생성기가 아닌 이유

"AI가 코드를 짜준다"고 하면, 많은 분이 빈 파일에 코드를 주르륵 작성하는 장면을 떠올립니다. 하지만 이번 시나리오를 자세히 보면, Claude Code는 코드를 생성하는 것보다 판단하는 시간이 더 많습니다. 구체적으로 어떤 판단을 했는지 정리하겠습니다.

 

첫째, 무엇을 만들고 무엇을 수정할지 구분했습니다. 백엔드 라우터가 필요하다는 것을 스스로 판단하고 새로 만들되, CSS는 기존 파일을 수정하는 방식을 선택했습니다. 이미 있는 style.css를 무시하고 새 CSS 파일을 만들 수도 있었지만, 기존 프로젝트 구조를 유지하는 방향을 택한 것입니다.

 

둘째, 수정 위치를 정밀하게 탐색했습니다. style.css가 1,000줄이 넘는 파일이었는데, 그 안에서 정확히 어디에 새로운 스타일을 넣어야 하는지를 Read와 Grep을 번갈아 사용하며 찾았습니다. 549~578줄을 먼저 확인하고, "Small phones"라는 키워드로 반응형 CSS 영역을 검색한 뒤, 1081~1090줄 근처에 모바일 코드를 삽입했습니다. 이 과정은 기존 코드의 구조와 컨벤션(관례)을 파악하고, 그에 맞춰 작업한 것입니다.

 

셋째, 모바일 반응형까지 자발적으로 추가했습니다. 사용자는 "레이아웃을 바꿔달라"고만 요청했지, "모바일에서도 잘 보이게 해달라"고는 말하지 않았습니다. 하지만 Claude Code는 레이아웃 변경 후 모바일 반응형 CSS가 필요하다는 것을 스스로 판단하고 추가했습니다. 이것은 단순히 지시받은 코드를 생성하는 것을 넘어, 완성도 있는 결과물을 만들기 위한 자발적인 판단입니다.
 

 
이런 판단 능력 때문에 바이브 코딩이 "코드를 대신 써주는 도구" 이상의 가치를 가집니다. 프로젝트의 맥락을 이해하고 적절한 결정을 내리는 능력은, 단순 코드 생성과는 차원이 다른 기능입니다.

 

 

입문자가 이 작업 화면에서 배울 수 있는 것

이번 시나리오 화면을 처음 보면 "코드를 하나도 모르는데 이걸 봐서 뭘 알 수 있지?"라는 생각이 들 수 있습니다. 하지만 코드를 전혀 읽지 못하더라도 이 화면에서 중요한 것들을 배울 수 있습니다.

가장 먼저 배울 수 있는 것은 작업의 흐름 감각입니다. Write가 연속으로 나오면 "지금 새로운 파일들을 만들고 있구나", Read와 Edit가 번갈아 나오면 "기존 파일을 확인하고 수정하고 있구나"라는 것을 알 수 있습니다. 코드의 내용을 읽지 못해도, 작업의 종류와 순서는 파악할 수 있는 것입니다. 이 감각이 있으면 Claude Code가 작업 중일 때 "지금 어디쯤 진행되고 있는지"를 대략 가늠할 수 있습니다.
다음으로 배울 수 있는 것은 요청의 구체성이 결과를 결정한다는 점입니다. 이번 시나리오의 요청은 "채널 그룹 UI를 좌측 사이드바 + 우측 채널 목록 레이아웃으로 바꿔달라"였습니다. 단순히 "UI를 예쁘게 바꿔줘"가 아니라, "좌측 사이드바 + 우측 채널 목록"이라는 구체적인 레이아웃 구조를 명시했기 때문에 Claude Code가 정확한 방향으로 작업할 수 있었습니다. 바이브 코딩에서 사용자의 역할은 코드를 쓰는 것이 아니라, 원하는 결과를 정확하게 설명하는 것입니다.
마지막으로 배울 수 있는 것은 하나의 요청이 여러 종류의 작업으로 분해된다는 사실입니다. "레이아웃을 바꿔달라"는 한 문장이 HTML 3개 + Python 1개 + CSS 수정 2회 + 검색 1회 = 총 13단계로 분해되었습니다. 이것은 소프트웨어 개발이라는 작업의 본질적인 특성입니다. 겉으로 보기에 하나의 기능이 실제로는 여러 파일, 여러 기술의 조합으로 구현됩니다. Claude Code의 작업 로그는 이런 소프트웨어 개발의 구조를 눈으로 확인할 수 있는 가장 직관적인 창구입니다.
 

 
Claude Code의 작업 화면을 반복해서 관찰하다 보면, "개발"이라는 것이 마법이 아니라 논리적인 단계의 연속이라는 것을 자연스럽게 체감할 수 있습니다. 바이브 코딩의 진짜 가치는 코드를 대신 써주는 편리함이 아니라, 소프트웨어가 만들어지는 과정을 투명하게 보여준다는 점에 있습니다. 그 투명한 과정을 읽는 첫 번째 단계가 바로 Write, Read, Edit, Grep 네 가지 도구를 구분하는 것입니다.