바이브코딩 5편: AI가 고친 코드를 어디부터 읽어야 할까 ::REFUGE HUB

바이브코딩을 조금만 해보면 이런 순간이 꼭 옵니다. AI가 코드를 고쳐줬고, 일단 화면도 뭔가 달라졌는데 정작 무엇이 왜 바뀌었는지는 잘 안 보이는 상태입니다. 초보자 입장에서는 이게 꽤 애매합니다. 실행은 되는데 설명이 흐릿하니, 다음 수정부터는 다시 불안해지기 쉽기 때문입니다.

그래서 어느 시점부터는 "동작하느냐"만 보는 걸로는 부족해집니다. 물론 결과 확인은 중요합니다. 다만 그 다음 단계에서는 어떤 파일이 바뀌었는지, 왜 그 줄이 추가됐는지, 화면에서 어떤 변화로 이어지는지를 조금씩 읽어갈 수 있어야 합니다. 그래야 AI가 만든 결과를 그냥 붙여 넣는 데서 끝나지 않고, 내 프로젝트 안에서 이해 가능한 형태로 받아들이게 됩니다.

이번 글은 바로 그 지점을 위한 내용입니다. AI가 코드를 바꾼 뒤 초보자는 어디부터 읽어야 하는지, HTML과 CSS와 JavaScript는 각각 무엇을 먼저 봐야 하는지, VS Code에서는 어떤 화면부터 여는 게 좋은지, Codex에게는 어떤 식으로 설명을 시켜야 하는지를 실습형으로 정리해보겠습니다.

이번 글에서 먼저 잡아둘 핵심
초보자가 흔히 하는 일	더 좋은 첫 순서	왜 이 순서가 좋은가
파일 전체를 처음부터 끝까지 다시 읽는다	바뀐 파일 이름부터 보고, 추가된 줄부터 본다	읽는 범위를 먼저 줄여야 핵심이 더 빨리 보입니다
AI 설명만 읽고 코드 확인은 건너뛴다	설명을 본 뒤 실제 바뀐 줄을 바로 확인한다	설명과 코드가 연결돼야 다음 수정에서도 덜 흔들립니다
JavaScript만 본다	HTML, CSS, JavaScript를 역할별로 다르게 읽는다	구조, 모양, 동작이 섞여 보이지 않게 나눠볼 수 있습니다

이번 글의 핵심 한 줄
AI가 고친 코드를 읽을 때는 전체를 다 이해하려고 달려들기보다, "무슨 파일이 바뀌었는지 -> 어떤 줄이 새로 생겼는지 -> 화면에서 무엇이 달라졌는지" 순서로 좁혀보는 편이 훨씬 낫습니다.

왜 "동작했다"보다 "무엇이 바뀌었는지"가 더 중요한가

처음에는 결과가 잘 나오기만 해도 충분해 보입니다. 실제로 초반에는 그게 맞습니다. 그런데 프로젝트가 조금만 길어지면, 예전에 바뀐 코드가 다음 수정에서 다시 발목을 잡기 시작합니다. 버튼 하나를 눌렀을 뿐인데 왜 상태 문구까지 같이 바뀌는지, 입력값을 비웠는데 왜 미리보기 카드에는 예전 값이 남아 있는지, 이런 식의 작은 의문이 계속 생깁니다.

이때 필요한 건 문법을 전부 외우는 능력이 아닙니다. 오히려 이번 수정에서 어디가 바뀌었는지 좁혀서 보는 습관이 더 중요합니다. 파일 하나만 바뀐 건지, 세 파일이 같이 바뀐 건지, 화면 구조가 바뀐 건지, 버튼 동작만 바뀐 건지부터 보이기 시작하면 생각보다 많은 문제가 단순해집니다.

AI 설명은 이해한 것 같은데 실제 코드에서 어느 줄이 핵심인지 모르겠다.
전체 파일을 처음부터 끝까지 다시 읽다가 오히려 더 헷갈린다.
화면이 달라진 건 알겠는데, HTML이 바뀐 건지 CSS가 바뀐 건지 JavaScript가 바뀐 건지 구분이 안 된다.

핵심 포인트
바이브코딩에서 실력이 붙는 지점은 "AI가 잘 만들어줬다"가 아니라, 바뀐 부분을 내 눈으로 다시 따라갈 수 있게 되는 순간에 더 가깝습니다.

AI가 고친 직후, 1분 읽기 순서부터 고정하자

초보자가 제일 먼저 바꿔야 할 건 읽는 순서입니다. 순서가 없으면 성실하게 보려 할수록 더 많이 헤맵니다. 그래서 AI가 수정한 직후에는 아래 1분 루틴부터 고정해두는 편이 좋습니다.

바뀐 파일 이름만 먼저 본다.
새로 추가된 줄과 바뀐 줄만 먼저 본다.
브라우저에서 어떤 행동이 달라졌는지 바로 눌러본다.
그다음에 HTML, CSS, JavaScript 중 어디를 먼저 읽을지 정한다.
설명이 필요하면 마지막에 Codex에게 좁혀서 묻는다.

이 순서가 좋은 이유는 읽는 범위를 계속 줄여가기 때문입니다. 처음부터 전체 파일을 읽는 게 아니라, 먼저 파일 이름으로 범위를 줄이고, 그다음 바뀐 줄만 보고, 그다음 실제 화면 변화로 연결합니다. 이러면 설명과 코드와 결과가 따로 놀지 않습니다.

1분 읽기 순서
순서	무엇을 보나	왜 먼저 보나
1	바뀐 파일 이름	읽을 범위를 가장 먼저 줄일 수 있습니다
2	추가된 줄, 수정된 줄	이번 턴의 핵심 변화가 보입니다
3	브라우저에서 달라진 행동	코드와 화면을 바로 연결할 수 있습니다

핵심 포인트
AI가 고친 코드는 많이 읽는 것보다 좁게 읽는 순서를 먼저 고정하는 것이 더 중요합니다.

HTML이 바뀌었을 때는 어디부터 볼까

HTML을 읽을 때는 문장을 예쁘게 쓰는 것보다, 무엇이 새로 생겼는지를 먼저 보는 편이 좋습니다. 새 입력창이 추가됐는지, 버튼이 하나 더 생겼는지, 미리보기 영역 안에 새로운 문단이 들어갔는지 같은 구조 변화가 핵심입니다.

특히 아래 세 가지를 먼저 보면 도움이 됩니다.

새로운 id가 생겼는지
새로운 class가 붙었는지
버튼, 입력창, 상태 문구처럼 화면 부품이 추가됐는지

예를 들어 아래처럼 바뀌었다고 해보겠습니다.

<main class="card">
  <h1>프로필 카드</h1>
  <p id="statusText">아직 저장 안 함</p>
  <button id="saveButton">저장</button>
</main>

AI 수정 후 코드가 이렇게 바뀌었다면, 초보자는 일단 예쁜 코드냐 아니냐보다 구조 변화부터 봐야 합니다.

<main class="card">
  <h1>프로필 카드</h1>

  <div class="toolbar">
    <button id="saveButton" class="primary-button">저장</button>
    <button id="resetButton" class="secondary-button">초기화</button>
  </div>

  <p id="statusText" class="status">아직 저장 안 함</p>
</main>

여기서 먼저 읽어야 할 핵심은 이렇습니다.

resetButton이라는 새 버튼이 생겼다
toolbar, primary-button, secondary-button, status 같은 새 클래스가 붙었다
기존 버튼 위치가 달라졌고, 상태 문구도 클래스가 추가됐다

즉, HTML은 "무슨 기능이 생겼나?"보다 무슨 부품이 새로 생겼나?를 먼저 보는 쪽이 더 빠릅니다.

핵심 포인트
HTML을 읽을 때는 문법보다 새 부품, 새 id, 새 class를 먼저 보는 편이 훨씬 낫습니다.

CSS가 바뀌었을 때는 어디부터 볼까

CSS를 볼 때는 속성 하나하나를 다 외우려고 하기보다, 어떤 선택자가 새로 생겼는지와 그 선택자가 HTML의 어떤 부분과 연결되는지를 먼저 보는 편이 좋습니다. 초보자가 CSS를 읽다 길을 잃는 가장 흔한 이유도 여기입니다. 값은 바뀌었는데, 도대체 어느 요소를 위한 수정인지 연결이 안 되기 때문입니다.

예를 들어 아래처럼 바뀌었다고 해보겠습니다.

.card {
  padding: 24px;
  border-radius: 18px;
}

AI 수정 후 CSS가 이렇게 바뀌면, 단순히 줄이 많아졌다고 보면 안 됩니다.

.card {
  padding: 24px;
  border-radius: 18px;
}

.toolbar {
  display: flex;
  gap: 10px;
  margin-top: 16px;
}

.primary-button,
.secondary-button {
  padding: 12px 14px;
  border-radius: 12px;
}

.status {
  margin-top: 14px;
  color: #6b7280;
}

@media (max-width: 640px) {
  .toolbar {
    flex-direction: column;
  }
}

이때 먼저 읽어야 할 건 아래입니다.

toolbar가 새로 생겼다 → HTML에서 새 div 구역이 추가됐을 가능성이 크다
primary-button, secondary-button가 생겼다 → 버튼 역할이 나뉘기 시작했다
status가 생겼다 → 상태 문구 표현이 바뀌었다
@media가 생겼다 → 모바일 화면도 의식한 수정일 가능성이 높다

즉, CSS는 "무슨 값을 넣었지?"보다 "어떤 요소를 위해 새 선택자를 만들었지?"부터 보는 편이 훨씬 현실적입니다.

핵심 포인트
CSS를 읽을 때는 속성 이름보다 선택자와 연결 대상을 먼저 보는 편이 더 좋습니다.

JavaScript가 바뀌었을 때는 어디부터 볼까

JavaScript를 읽을 때는 조금 더 분명한 기준이 필요합니다. 여기서는 보통 아래 세 가지를 먼저 보면 됩니다.

어떤 요소를 찾는가
어떤 순간에 반응하는가
결과로 무엇을 바꾸는가

예를 들어 원래 코드가 아래처럼 단순했다고 해보겠습니다.

const nameInput = document.querySelector("#nameInput");
const applyButton = document.querySelector("#applyButton");
const previewName = document.querySelector("#previewName");

applyButton.addEventListener("click", function () {
  previewName.textContent = nameInput.value;
});

AI 수정 후 코드가 이렇게 바뀌었다면, 초보자는 길어졌다는 사실보다 바뀐 역할부터 봐야 합니다.

const nameInput = document.querySelector("#nameInput");
const applyButton = document.querySelector("#applyButton");
const previewName = document.querySelector("#previewName");
const statusText = document.querySelector("#statusText");

applyButton.addEventListener("click", function () {
  const nextName = nameInput.value.trim() || "이름을 입력해보세요.";

  previewName.textContent = nextName;
  statusText.textContent = "미리보기에 반영했습니다.";

  nameInput.value = "";

  setTimeout(function () {
    statusText.textContent = "다시 입력해보세요.";
  }, 2000);
});

여기서 먼저 읽어야 할 건 아래 네 줄입니다.

statusText를 새로 찾고 있다 → 화면에서 상태 문구도 같이 바뀌기 시작했다
trim()과 기본 문구가 들어갔다 → 빈 입력 처리 로직이 추가됐다
nameInput.value = ""; → 버튼 뒤에 입력창을 비우는 동작이 생겼다
setTimeout(..., 2000) → 2초 뒤에 다시 한 번 상태 문구를 바꾸는 흐름이 생겼다

이렇게 읽으면 전체 코드가 아니라 이번 수정에서 새로 생긴 의도가 먼저 보입니다. 그리고 그 의도를 브라우저에서 다시 확인해보면 됩니다. 버튼을 누른 뒤 이름이 들어가는지, 상태 문구가 바뀌는지, 입력창이 비워지는지, 2초 뒤 문구가 다시 바뀌는지를 차례로 보는 식입니다.

핵심 포인트
JavaScript는 문법 시험처럼 읽는 게 아니라, 요소 찾기 - 반응 시점 - 화면 변화 순서로 보는 편이 훨씬 낫습니다.

VS Code에서는 어떤 화면부터 열어야 할까

이제 중요한 건 "어디서 이 변경을 보느냐"입니다. 초보자가 가장 많이 놓치는 부분도 여기입니다. 바뀐 코드가 있다는 말은 들었는데, VS Code에서 정확히 어느 화면을 열어야 바뀐 줄만 바로 볼 수 있는지가 흐릴 때가 많기 때문입니다.

기본 동선은 단순합니다.

Source Control 화면으로 갑니다.
변경된 파일 목록만 먼저 봅니다.
파일을 클릭해서 변경 비교 화면을 엽니다.
추가된 줄과 바뀐 줄만 먼저 읽습니다.

이 흐름이 좋은 이유는 VS Code가 변경 파일과 diff editor를 이미 한 세트처럼 묶어서 보여주기 때문입니다. 즉, "전체 파일 다시 읽기"보다 변경 줄 먼저 보기가 훨씬 쉬운 도구가 이미 있는 셈입니다.

두 파일을 따로 비교하고 싶다면 Explorer 쪽에서도 비교 흐름을 쓸 수 있습니다. 이때는 한 파일을 먼저 선택하고, 다른 파일에 비교를 거는 방식으로 열 수 있습니다. 초보자에게는 이 기능도 꽤 유용합니다. AI가 "이전 버전과 지금 버전을 비교해보세요"라고 했을 때, 무식하게 두 파일을 따로 열어 놓고 눈으로만 비교하지 않아도 되기 때문입니다

VS Code에서 먼저 여는 화면
상황	먼저 여는 화면	왜 이쪽이 좋은가
방금 바뀐 줄만 보고 싶다	Source Control → 변경 파일 클릭	diff editor로 바로 넘어가서 추가/수정 줄만 볼 수 있습니다
두 파일을 직접 비교하고 싶다	Explorer에서 Compare 흐름 사용	눈으로 덩어리 비교하는 것보다 훨씬 정확합니다

핵심 포인트
VS Code에서는 전체 파일보다 변경 파일 목록과 diff editor부터 보는 습관을 들이는 편이 훨씬 좋습니다.

Codex에게 설명을 시킬 때와 수정을 맡길 때를 나누자

AI가 이미 코드를 고친 뒤라면, 그다음부터는 Codex를 "다시 또 고치는 도구"처럼만 쓰지 않는 편이 좋습니다. 특히 초보자일수록 먼저 시켜야 하는 건 수정이 아니라 설명입니다. 지금 바뀐 파일이 무엇이고, 새로 생긴 줄이 어떤 역할인지부터 다시 말하게 하면 훨씬 도움이 됩니다.

또 한 가지 알아둘 점이 있습니다. Codex의 review pane은 "Codex가 바꾼 줄만" 따로 보여주는 단순 창이 아니라, 현재 Git 저장소의 변경 상태를 바탕으로 보여주는 쪽에 가깝습니다. 즉, Git 저장소 안의 프로젝트여야 이 흐름이 자연스럽게 작동합니다.

먼저 설명이 필요할 때는 이렇게 물어보는 편이 좋습니다.

이번 수정에서 바뀐 파일 이름만 먼저 정리해줘.
각 파일이 왜 바뀌었는지도 한두 줄씩 같이 설명해줘.
새로 추가된 줄과 기존 줄을 수정한 부분도 나눠서 말해줘.

JavaScript 쪽 핵심 줄만 뽑고 싶다면 이렇게 줄일 수 있습니다.

@script.js
지금 변경에서 내가 직접 읽어봐야 할 핵심 줄 5개만 골라줘.
왜 중요한지도 같이 적어줘.
설명만 먼저 하고, 코드는 아직 다시 수정하지 마.

VS Code에서 로그를 어디에 찍어야 할지 막힐 때는 이렇게 묻는 편이 좋습니다.

@script.js
이 코드에서 이벤트가 들어오는지,
입력값이 제대로 들어오는지,
화면에 넣기 직전 값이 맞는지 확인할 수 있게
console.log()를 최소한으로 3개만 넣어줘.
각 로그를 왜 그 위치에 넣는지도 설명해줘.

즉, Codex에게는 "전체를 다시 고쳐줘"보다 무엇을 설명할지, 어디까지만 손댈지를 먼저 자르는 편이 훨씬 낫습니다.

핵심 포인트
Codex는 수정 도구이기도 하지만, 초보자에게는 먼저 변경 이유를 다시 설명하게 만드는 도구로 쓰는 편이 훨씬 도움이 됩니다.

5분 실습: 직접 바뀐 코드를 읽어보는 연습

이제부터는 아주 작은 예제로 직접 확인해보겠습니다. 이 구간이 들어가야 독자가 "바뀐 코드를 읽는 법"을 머리로만 이해하는 데서 끝나지 않고, 실제로 브라우저와 VS Code를 같이 보는 감각까지 가져갈 수 있습니다.

실습은 어렵지 않습니다. 먼저 정상 동작 코드를 보고, 그다음 AI가 조금 더 편하게 바꿔줬다고 가정한 코드를 보겠습니다. 그리고 무엇이 실제로 새로 생겼는지 체크리스트처럼 읽어보면 됩니다.

1) 먼저 기존 코드를 봅니다

const nameInput = document.querySelector("#nameInput");
const applyButton = document.querySelector("#applyButton");
const previewName = document.querySelector("#previewName");

applyButton.addEventListener("click", function () {
  previewName.textContent = nameInput.value;
});

2) 그다음 AI가 고친 코드를 봅니다

const nameInput = document.querySelector("#nameInput");
const applyButton = document.querySelector("#applyButton");
const previewName = document.querySelector("#previewName");
const statusText = document.querySelector("#statusText");

applyButton.addEventListener("click", function () {
  const nextName = nameInput.value.trim() || "이름을 입력해보세요.";

  previewName.textContent = nextName;
  statusText.textContent = "미리보기에 반영했습니다.";

  nameInput.value = "";

  setTimeout(function () {
    statusText.textContent = "다시 입력해보세요.";
  }, 2000);
});

3) 이제 아래 순서대로 읽어봅니다

새 요소를 찾는 줄이 늘어났는가 → statusText가 새로 생겼습니다.
원본 값을 가공하는 줄이 생겼는가 → trim()과 기본 문구 처리가 추가됐습니다.
화면에 반영되는 대상이 늘어났는가 → previewName 말고 statusText도 바뀝니다.
이벤트 뒤 후속 동작이 생겼는가 → 입력창 비우기와 2초 뒤 문구 변경이 추가됐습니다.

이제 브라우저에서 실제로 눌러보면 됩니다. 버튼을 누른 뒤 이름이 들어가는지, 상태 문구가 바뀌는지, 입력창이 비워지는지, 2초 뒤 문구가 다시 바뀌는지를 하나씩 확인해보면 됩니다.

이 실습에서 중요한 건 코드량이 아닙니다. 새로 생긴 줄이 어떤 행동으로 이어지는지를 코드와 화면으로 바로 연결해보는 데 있습니다.

핵심 포인트
실습에서는 "전체를 이해한다"보다 새로 생긴 줄이 화면에서 어떤 행동으로 이어지는지를 확인하는 쪽이 훨씬 중요합니다.

저작자표시 비영리 변경금지 (새창열림)

'바이브코딩 > 실습' 카테고리의 다른 글

바이브코딩 7편: Git은 버전 관리보다 체크포인트라고 이해하면 편하다 (0)	2026.03.16
바이브코딩 6편: 오류가 났을 때 어디부터 봐야 할까 (0)	2026.03.15
바이브코딩 4편: JavaScript로 버튼 클릭과 입력 반응 붙이기 (0)	2026.03.13
바이브코딩 3편: VS Code와 Codex로 자기소개 페이지 만들기 (1)	2026.03.12
바이브코딩 2편: VS Code 터미널과 Codex 확장, 여기서부터 실습이 시작된다 (0)	2026.03.11