AI에게 코드를 부탁하고 나면, 초보자 입장에서는 아주 비슷한 감정이 한 번씩 찾아옵니다. 화면은 일단 뜨고, 버튼도 어느 정도 눌리고, 콘솔 에러도 없어 보이는데 이상하게 마음이 놓이지 않는 순간입니다. “이게 맞는 건가?”, “지금 돌아가는 것 같긴 한데 나중에 더 꼬이는 건 아닐까?” 같은 느낌이 드는 때가 바로 그 지점입니다.

이 감각은 이상한 게 아닙니다. 오히려 자연스럽습니다. AI는 꽤 그럴듯한 코드를 빠르게 만들어주지만, 그 코드가 정말 내가 요청한 범위에 맞는지, 기존 기능을 건드리지는 않았는지, 지금 단계에서 괜히 복잡해진 건 아닌지는 따로 확인해야 하기 때문입니다.

이번 편에서는 그 과정을 다루겠습니다. 핵심은 시니어 개발자처럼 완벽하게 리뷰하는 데 있지 않습니다. 초보자 기준에서 지금 꼭 봐야 할 것부터 확인하고, 무엇이 어긋났는지 정리해서 AI에게 다시 요청하는 법을 익히는 데 있습니다. 이 흐름이 잡히면, AI가 준 답을 무조건 믿거나 무조건 버리는 대신, 조금 더 주도적으로 다룰 수 있게 됩니다.

이번 글에서 먼저 잡아둘 핵심
겉으로 보이는 상태 실제로 봐야 할 것 바로 다음 행동
기능이 일단 돌아간다 정말 내가 요청한 기능만 들어갔는지, 빠진 건 없는지 요청 목록과 결과를 한 번 나란히 비교한다
새 기능이 붙었다 기존에 되던 기능이 같이 깨지지 않았는지 추가, 삭제, 필터 같은 기존 흐름을 다시 눌러본다
코드가 길고 복잡해 보인다 이번 단계 범위를 넘어가는 변경이 들어갔는지 전체 재작성 대신 필요한 부분만 다시 요청한다

이번 글의 핵심 한 줄
AI가 만든 코드를 검토한다는 것은 완벽함을 따지는 일이 아니라, 지금 단계의 목표와 범위에 맞는지 먼저 확인하는 일에 가깝습니다.

왜 검토가 필요한가

초보자가 AI와 같이 코딩할 때 가장 자주 겪는 착각 중 하나는 이것입니다. “에러가 없고 화면이 보이면 일단 맞는 코드다.” 물론 완전히 틀린 말은 아닙니다. 실제로 실행이 된다는 건 중요한 출발점입니다. 하지만 거기서 끝내면 놓치는 것이 많습니다.

예를 들어 검색 기능을 붙여달라고 했는데, 검색은 되지만 기존 필터가 깨질 수도 있습니다. 삭제 버튼을 고쳐달라고 했는데, 삭제는 되지만 summary 문구가 갱신되지 않을 수도 있습니다. 더 심하면 이번 단계에서 필요하지 않은 구조까지 한꺼번에 바뀌어서, 지금은 돌아가도 다음 단계에서 이해하기 어려워질 수도 있습니다.

  • 요청한 기능이 일부만 들어갔는데 겉으로는 된 것처럼 보일 수 있습니다.
  • 새 기능은 붙었지만 기존 기능이 같이 깨질 수 있습니다.
  • 이번 단계에 필요 없는 코드까지 들어와서 구조가 불필요하게 커질 수 있습니다.
  • 설명은 그럴듯하지만 실제 코드와 맞지 않는 경우도 있습니다.

여기서 검토의 의미를 너무 크게 잡을 필요는 없습니다. 지금 단계에서 중요한 건 보안, 성능, 아키텍처를 깊게 따지는 일이 아닙니다. 오히려 내가 요청한 것과 실제 결과가 맞는지, 기존 흐름이 유지되는지, 초보자인 내가 이해 가능한 크기인지를 먼저 보는 편이 훨씬 현실적입니다.

오해하기 쉬운 지점
검토는 AI를 믿지 못해서 하는 일이 아닙니다. 다음 단계로 넘어가기 전에 지금 결과를 내가 통제 가능한 상태로 만드는 과정에 가깝습니다.

이번 편에서는 어디까지 볼 것인가

이번 글에서도 범위를 분명하게 잘라두는 편이 좋습니다. 초보자 기준에서 “AI 코드 검토”라고 하면 너무 많은 주제가 한꺼번에 떠오를 수 있기 때문입니다. 그래서 이번 편은 기능이 맞는지 확인하고, 어긋난 부분을 다시 요청하는 흐름에 집중하겠습니다.

이번 편에서 다룰 내용은 아래 정도입니다.

  • 내 요청과 결과가 맞는지 비교하는 기본 방법
  • 기존 기능이 깨졌는지 확인하는 방법
  • 이번 단계 범위를 넘어간 코드를 구분하는 방법
  • AI에게 전체 재작성 없이 다시 요청하는 방법

반대로 이번 글에서는 아래 내용은 깊게 다루지 않겠습니다.

  • 성능 최적화
  • 보안 취약점 점검
  • 대규모 프로젝트 구조 설계
  • 정교한 테스트 자동화

이런 주제들이 중요하지 않다는 뜻은 아닙니다. 다만 지금 연재 흐름에서는 먼저 AI가 준 결과를 읽고, 현재 단계에 맞게 바로잡는 기본기가 더 중요합니다. 입문자에게는 이 단계가 잡혀야, 이후의 디버깅이나 테스트도 덜 막막해집니다.

초보자는 이 네 가지부터 보면 된다

AI가 만든 코드를 처음 검토할 때는 많은 것을 한꺼번에 보려 하지 않는 편이 좋습니다. 초보자에게는 먼저 요구사항, 기존 기능, 불필요한 변경, 이해 가능성 이 네 가지만 보는 습관이 있어도 충분히 큰 도움이 됩니다.

초보자가 먼저 확인하면 좋은 네 가지
확인 항목 무엇을 보나 예시 질문
요구사항 일치 내가 부탁한 기능이 빠짐없이 들어갔는지 검색 기능을 부탁했는데 실시간 반영, 지우기 버튼, 필터 연동까지 모두 들어갔는가
기존 기능 유지 원래 되던 기능이 새 코드 뒤에 깨지지 않았는지 검색을 붙인 뒤 추가, 삭제, 완료 체크, 필터가 그대로 동작하는가
불필요한 변경 이번 단계와 관계없는 구조 변경이 들어갔는지 검색 기능만 필요했는데 저장 방식과 전체 레이아웃까지 한꺼번에 바뀌었는가
이해 가능성 지금 내 수준에서 흐름을 따라갈 수 있는지 함수 이름과 역할이 읽히는가, 설명이 코드와 맞는가

1. 요구사항이 맞는지 먼저 본다

가장 먼저 할 일은 AI가 만든 결과를 보고 감탄하는 게 아니라, 내가 원래 요청한 목록과 하나씩 비교해보는 것입니다. 이 단계가 생각보다 중요합니다. AI는 종종 핵심 기능 하나를 놓친 채 나머지를 그럴듯하게 채워 넣을 수 있기 때문입니다.

2. 기존 기능이 깨졌는지 꼭 눌러본다

개발에서는 새 기능이 붙은 뒤 원래 되던 것이 깨지는 일을 종종 겪습니다. 이걸 흔히 회귀라고 부르는데, 쉽게 말하면 원래 되던 게 새 수정 뒤에 안 되는 상태라고 생각하면 됩니다. 초보자일수록 새 기능만 보고 지나가기가 쉬워서, 이 확인이 더 중요합니다.

3. 범위를 넘어간 변경이 없는지 본다

AI는 문제를 고치다가 전체 구조를 한 번에 정리하려는 답을 내놓을 때가 있습니다. 이런 정리는 때로 도움이 되지만, 초보자 입장에서는 부담이 커질 수 있습니다. 지금은 검색 기능만 붙이면 되는 단계인데, 함수 이름과 파일 구조가 전부 바뀌면 다음부터 따라가기가 훨씬 어려워집니다.

4. 내가 이해 가능한 크기인지 본다

코드가 돌아간다고 해도, 지금 내 수준에서 전혀 설명이 안 되는 구조라면 바로 다음 단계에서 막힐 가능성이 높습니다. 그래서 검토의 마지막에는 “이 흐름을 내가 다음에도 설명할 수 있을까?”를 한 번 물어보는 편이 좋습니다. 완전히 다 이해할 필요는 없지만, 최소한 어느 함수가 무엇을 하는지는 읽히는 편이 낫습니다.

핵심 포인트
초보자에게 좋은 코드는 가장 멋진 코드가 아니라, 지금 단계 목표를 충족하면서도 다음 수정 요청을 이어가기 쉬운 코드에 가깝습니다.

할 일 앱 예시로 보는 검토 순서

이제 실제 예시로 흐름을 한 번 잡아보겠습니다. 예를 들어 이번 단계 목표가 검색 기능 추가라고 해보겠습니다. 내가 AI에게 부탁한 조건은 아래와 같다고 가정하겠습니다.

[이번 단계 목표]

검색 입력창 추가

입력할 때마다 목록이 바로 줄어들기

검색 지우기 버튼 추가

전체, 진행 중, 완료 필터와 함께 동작하기

[이번 단계에서 아직 하지 않을 것]

검색 기록 저장

정규식 검색

서버 연동

전체 파일 구조 재작성

이제 AI가 결과를 줬다면, 검토는 아래 순서로 하면 됩니다.

  1. 요청한 네 가지 기능이 다 들어갔는지 본다
    검색 입력창이 있는가, 실시간 반영되는가, 지우기 버튼이 있는가, 필터와 같이 움직이는가를 하나씩 확인합니다.
  2. 기존 기능을 다시 눌러본다
    추가, 삭제, 완료 체크, 전체 삭제, 필터 버튼이 여전히 정상 동작하는지 확인합니다.
  3. 이번 단계 밖의 변경이 있는지 본다
    검색만 부탁했는데 localStorage 구조, 수정 기능, 버튼 이름, 전체 레이아웃까지 크게 바뀌었는지 확인합니다.
  4. 코드 흐름을 짧게 설명해보려고 해본다
    searchInput 값이 어디에 저장되고, 어떤 함수가 목록을 다시 고르는지 말로 설명이 되는지 봅니다.

이 과정을 거치고 나면 보통 세 가지 중 하나가 보입니다. 기능이 빠졌거나, 기존 기능이 깨졌거나, 범위를 넘겨서 코드가 커졌거나. 그리고 바로 이 지점에서 다시 요청을 하면 됩니다. 중요한 건 “이상한데 고쳐줘”처럼 다시 넓게 묻지 않는 것입니다. 무엇이 어긋났는지 짧게라도 정리해서 넘겨야 합니다.

예를 들어 이런 식으로 정리할 수 있습니다.

[검토 결과]

검색 입력창과 지우기 버튼은 들어감

입력할 때 목록은 줄어듦

하지만 완료 필터 상태에서 검색하면 결과가 맞지 않음

검색 기능과 관계없는 함수 이름 변경이 너무 많이 들어감

[다시 요청할 핵심]

필터와 검색이 함께 적용되도록 수정

전체 리팩터링은 하지 말 것

현재 구조를 최대한 유지할 것

바뀌는 함수만 설명할 것

이 정도만 있어도 AI는 훨씬 좁은 범위에서 다시 답하게 됩니다. 초보자에게 이 방식이 특히 좋은 이유는, 문제를 “싫은 느낌”이 아니라 “확인된 항목”으로 바꿔서 전달할 수 있기 때문입니다.

AI에게는 이렇게 다시 요청하면 된다

재요청의 핵심은 단순합니다. 무엇이 맞았는지, 무엇이 어긋났는지, 이번에는 어디까지만 고칠지를 같이 적는 것입니다. 이 세 가지가 들어가면 “다시 만들어줘”보다 훨씬 안정적인 답이 나옵니다.

1. 누락된 기능만 다시 요청하는 방식

전체적으로는 괜찮은데 몇 가지가 빠졌다면, 범위를 다시 넓히지 말고 빠진 것만 집어서 요청하는 편이 좋습니다.

방금 제안한 코드에서

검색 입력창과 실시간 반영은 잘 들어갔어.

다만 아직 두 가지가 빠져 있어.

검색 지우기 버튼을 누르면 입력값이 비워져야 해

완료 필터 상태에서도 검색이 함께 적용돼야 해

전체 구조를 다시 쓰지 말고,
이 두 부분에 필요한 수정만 제안해줘.

답변은 아래 순서로 줘.

무엇이 빠졌는지 요약

어느 함수나 요소를 고쳐야 하는지

필요한 코드만 제시

내가 확인할 테스트 순서

2. 기존 기능이 깨졌을 때 다시 요청하는 방식

새 기능은 됐는데 예전 기능이 깨졌다면, 이건 꽤 중요한 신호입니다. 이런 경우에는 “기존 기능 유지”를 분명하게 다시 걸어주는 편이 좋습니다.

검색 기능은 동작하는데,

추가한 뒤에는 기존 전체 삭제 버튼이 반응하지 않아.

이번 수정의 목표는

검색 기능은 그대로 유지하고

전체 삭제 버튼 동작만 다시 살리는 것
이야.

검색 기능과 관계없는 구조 변경은 하지 말고,
이 문제가 생긴 가장 가능성 큰 원인부터 설명해줘.
그다음 최소 수정 코드만 보여줘.

3. 범위를 너무 넓게 바꿨을 때 다시 요청하는 방식

초보자에게 특히 유용한 방식입니다. AI가 한 번에 너무 많은 걸 바꿨다면, 정중하지만 분명하게 범위를 줄여야 합니다.

지금 답변은 검색 기능을 추가하는 것보다

전체 구조를 너무 많이 바꿔버렸어.

이번 단계에서는

현재 파일 구조 유지

기존 함수 이름 최대한 유지

검색 기능과 직접 관련된 부분만 수정
이 기준으로 다시 제안해줘.

리팩터링은 지금 하지 말고,
검색 상태 저장과 목록 필터링 흐름만 보정해줘.

4. 설명이 부족할 때 다시 요청하는 방식

코드는 받았는데 왜 그렇게 바꿨는지 감이 안 잡히면, 설명을 다시 받는 것도 중요합니다. 특히 초보자는 이 단계를 건너뛰면 다음 수정 요청이 더 어려워집니다.

코드는 이해했는데,

왜 currentSearchQuery를 따로 두는지와
getFilteredTodos가 어떤 순서로 조건을 적용하는지가 아직 헷갈려.

초보자 기준으로 아래 형식으로 다시 설명해줘.

각 상태값이 무엇을 뜻하는지

목록이 다시 그려질 때 어떤 순서로 조건이 적용되는지

이 구조가 필요한 이유

내가 직접 바꿔보면 좋은 작은 연습 2개

이런 재요청 방식의 장점은 분명합니다. AI를 다시 쓰는 것이 아니라, 내가 원하는 수정 방향을 더 좁게 지정하는 것이기 때문입니다. 그러면 결과도 훨씬 덜 흔들립니다.

핵심 포인트
재요청은 실패의 표시가 아닙니다. 처음 답을 바탕으로 범위를 더 정확하게 좁혀가는 과정이라고 보는 편이 맞습니다.

자주 하는 실수와 체크리스트

검토와 재요청 과정에서 초보자가 특히 자주 하는 실수가 몇 가지 있습니다. 이 부분만 의식해도 답변 품질이 꽤 달라집니다.

검토와 재요청에서 자주 하는 실수
실수 왜 문제가 되나 어떻게 바꾸면 좋은가
“뭔가 이상해요”만 말한다 무엇이 어긋났는지 범위가 너무 넓다 빠진 기능, 깨진 기능, 불필요한 변경 중 무엇인지 먼저 정리한다
다시 전체를 새로 짜달라고 한다 문제가 더 커지고 기존 맥락도 사라질 수 있다 최소 수정 원칙을 먼저 걸어둔다
새 기능만 보고 기존 기능은 안 눌러본다 원래 되던 기능이 깨져도 놓치기 쉽다 추가, 삭제, 필터처럼 기존 핵심 흐름을 다시 확인한다
설명을 이해 못 했는데 그냥 넘어간다 다음 수정 요청에서 더 크게 막힐 수 있다 상태값, 함수 흐름, 변경 이유를 다시 풀어달라고 요청한다

실전에서는 아래 체크리스트 정도만 기억해도 충분히 도움이 됩니다.

  • 내가 요청한 기능 목록과 결과를 하나씩 비교했는가
  • 새 기능 뒤에 기존 기능을 다시 눌러봤는가
  • 이번 단계 범위를 넘는 변경이 들어갔는가
  • 내가 이해 안 되는 함수나 상태값이 남아 있는가
  • 재요청할 때 전체 재작성 대신 최소 수정 범위를 적었는가

이 다섯 가지만 반복해도, AI와의 작업은 꽤 달라집니다. 처음부터 완벽한 결과를 받는 것보다, 결과를 읽고 필요한 만큼 바로잡는 습관이 붙기 시작하기 때문입니다.

마무리

지금까지 흐름을 이어서 보면, 이 연재는 단순히 프롬프트 문장을 예쁘게 쓰는 법을 다루는 게 아닙니다. 역할을 정하고, 요청 구조를 잡고, 작업을 나누고, 현재 상태를 전달하고, 이번 편에서는 AI가 준 결과를 검토하고 다시 요청하는 법까지 왔습니다. 이쯤 되면 이미 “아무 말이나 던지고 결과를 기다리는 방식”과는 꽤 멀어졌다고 볼 수 있습니다.

초보자에게 가장 중요한 변화도 바로 여기 있습니다. AI가 코드를 만든다는 사실보다, 내가 그 결과를 읽고 다음 요청으로 연결할 수 있는가가 훨씬 중요합니다. 그래야 한 번 잘 나온 답에만 기대지 않고, 어긋난 부분도 스스로 좁혀가며 다룰 수 있게 됩니다.

다음 편은 이 기초 연재의 마지막으로, 막혔을 때 질문하는 법: 디버깅 요청의 기본으로 이어가면 흐름이 가장 자연스럽습니다. 지금까지 배운 요청 구조, 작업 분해, 상태 전달, 검토와 재요청이 결국 디버깅에서 한 번에 모이기 때문입니다.

'바이브코딩 > 기초' 카테고리의 다른 글

[번외-0] 매번 처음부터 쓰지 마세요: 바이브 코딩에 바로 쓰는 프롬프트 템플릿 모음  (0) 2026.04.21
[기초-5] 막혔을 때 이렇게 물어보세요: 초보자를 위한 AI 디버깅 요청의 기본  (0) 2026.04.14
[기초-3] AI가 엉뚱하게 답하는 이유: 코드·에러·화면 상태를 제대로 전달하는 법  (0) 2026.03.31
[기초-2] 한 번에 다 시키지 마세요: 바이브 코딩에서 큰 요청을 잘게 나누는 법  (0) 2026.03.24
[기초-1] 좋은 요청의 기본 구조: 목표·맥락·제약·출력 형식 쉽게 잡는 법  (0) 2026.03.17