21장. 파일을 맡기고 결과를 검토하는 법

AI에게 파일 수정을 맡기면 정말 편합니다. 버튼 하나만 눌러도 화면이 바뀌고, 에러가 사라지고, 새로운 기능이 붙는 것처럼 보이기도 합니다. 그래서 초보자는 아주 쉽게 이런 착각에 빠집니다.

"돌아가네? 그럼 끝난 거 아닌가?"

하지만 여기서부터가 진짜 시작입니다. 작동한다는 것과 괜찮다는 것은 다릅니다. 화면이 일단 열리는 것과, 내가 원한 방식으로 안전하고 읽기 좋게 동작하는 것은 전혀 다른 문제입니다.

이번 장에서는 Claude Code나 Codex가 수정한 파일을 무작정 받아들이지 않고, 무엇이 어떻게 바뀌었는지 읽고 검토하는 기본 습관을 익혀보겠습니다. 이 습관 하나만 잘 들어도 나중에 생길 실수, 버그, 혼란이 눈에 띄게 줄어듭니다.

왜 검토가 꼭 필요할까

AI는 빠릅니다. 하지만 빠르다고 해서 항상 정확한 것은 아닙니다. 특히 여러 파일이 얽힌 작업에서는 겉으로는 잘 되는 것처럼 보여도 안쪽 구조가 어수선해질 수 있습니다.

예를 들어 AI에게 "글 작성 폼을 만들어줘"라고 시켰다고 해봅시다. 결과는 멀쩡해 보일 수 있습니다. 그런데 자세히 보면 기존 버튼 컴포넌트를 재사용하지 않고 비슷한 버튼을 새로 만들었을 수도 있고, 서버 쪽 검증 없이 프론트엔드에서만 입력값을 검사했을 수도 있습니다. 더 심한 경우에는 필요 없는 파일까지 건드리거나, 나중에 다른 기능과 충돌할 수 있는 코드를 슬쩍 넣어두기도 합니다.

초보자일수록 "AI가 해줬으니 맞겠지"라고 생각하기 쉽습니다. 하지만 실제 개발에서는 결과를 믿기 전에 변경 내용을 읽는 습관이 중요합니다. 이 과정은 AI를 의심하기 위한 것이 아니라, 내 서비스를 내가 이해하기 위한 과정입니다.

검토는 코드를 다 해석하는 일이 아니다

여기서 겁먹을 필요는 없습니다. 검토한다고 해서 모든 코드를 줄줄이 분석해야 하는 것은 아닙니다. 처음에는 아주 단순한 질문만 던져도 충분합니다.

이 파일은 왜 바뀌었지? 이 변경이 내가 요청한 기능과 관련 있지? 이전보다 더 복잡해지지 않았나? 혹시 다른 화면까지 영향을 주지 않을까?

초보자의 검토는 "완벽한 코드 리뷰"가 아니라 "이상한 점을 빨리 알아차리는 확인 과정"에 가깝습니다. 즉, 전부 이해하려고 애쓰기보다 방향이 맞는지부터 보는 것입니다.

가장 먼저 볼 것은 바뀐 파일 목록이다

AI가 작업을 마치면 코드 내용보다 먼저 바뀐 파일 목록부터 보세요. 이 습관은 생각보다 강력합니다.

예를 들어 단순히 검색 입력창 디자인만 바꾸려 했는데, AI가 다음과 같이 여러 파일을 수정했다고 해봅시다.

• app/page.tsx

• components/SearchBar.tsx

• components/Button.tsx

• lib/api.ts

• middleware.ts

이 순간 한 번 멈춰야 합니다. 검색창 디자인을 바꾸는 일인데 왜 API 파일과 미들웨어까지 바뀌었을까요? 물론 합당한 이유가 있을 수도 있습니다. 하지만 이유를 설명받지 못했다면 그냥 넘기면 안 됩니다.

파일 목록은 작업의 범위를 보여줍니다. 범위가 예상보다 넓다면, 그 자체로 검토 신호입니다.

AI에게 먼저 설명을 시켜라

검토를 잘하려면 AI에게 바로 "수고했어"라고 하지 말고, 먼저 설명을 요청해야 합니다. 설명을 듣고 나서 코드를 보면 훨씬 잘 보입니다.

이럴 때는 이렇게 물어보면 좋습니다.

• 어떤 파일을 왜 수정했는지 요약해줘.

• 내가 요청한 기능과 직접 관련된 변경만 구분해서 설명해줘.

• 새로 추가한 코드와 기존 코드를 바꾼 부분을 나눠서 말해줘.

• 내가 특히 확인해야 할 위험한 부분이 있으면 알려줘.

이 질문의 장점은 두 가지입니다. 첫째, AI가 자기 작업을 스스로 정리하게 만듭니다. 둘째, 내가 검토할 순서를 잡기 쉬워집니다.

설명을 들었는데도 "굳이 이 파일까지 바꿔야 했나?" 싶은 부분이 있으면 바로 다시 물어보세요. 초보자에게 필요한 것은 멋진 추측이 아니라 분명한 이유입니다.

검토는 파일 단위로, 큰 것부터 작은 것으로

여러 파일이 바뀌었을 때는 아무 파일이나 열어보면 금방 길을 잃습니다. 먼저 큰 흐름을 잡고, 그다음 세부를 보는 편이 좋습니다.

추천 순서는 이렇습니다.

• 화면에서 가장 직접적으로 보이는 파일

• 그 화면이 호출하는 컴포넌트 파일

• 데이터를 주고받는 함수나 API 파일

• 설정 파일이나 공통 유틸 파일

예를 들어 "글 작성 화면에 카테고리 선택 기능 추가" 작업이라면, 먼저 글 작성 페이지 파일을 보고, 그다음 폼 컴포넌트, 그다음 저장 함수, 마지막으로 타입 정의나 유틸 파일을 보면 됩니다.

이 순서가 좋은 이유는 간단합니다. 사용자의 눈에 보이는 변화부터 따라가면 전체 구조가 머릿속에 더 잘 들어오기 때문입니다.

무엇이 바뀌었는지 볼 때 핵심은 네 가지다

코드를 볼 때 너무 많은 것을 한꺼번에 확인하려고 하면 금방 피곤해집니다. 처음에는 아래 네 가지만 봐도 충분합니다.

요청한 기능과 정확히 맞는가

가장 먼저 확인할 것은 "이 변경이 내가 부탁한 일과 정확히 맞는가"입니다.

예를 들어 내가 원한 것은 "글 목록 상단에 검색창 추가"인데, AI가 필터 기능과 정렬 기능까지 함께 넣었다면 어떨까요? 얼핏 보면 더 좋아 보일 수 있습니다. 하지만 실제로는 검토 범위만 넓어지고, 나중에 버그 원인도 복잡해집니다.

AI는 종종 친절하게 일을 키웁니다. 그런데 초보자에게 필요한 것은 친절한 확장이 아니라, 정확한 실행입니다. 지금 필요한 것만 바뀌었는지 먼저 보세요.

코드가 지나치게 복잡해지지 않았는가

작동은 하지만 너무 복잡해진 코드도 문제입니다. 특히 AI는 짧게 풀 수 있는 문제를 길게 푸는 경우가 있습니다.

예를 들어 버튼 클릭 후 페이지 이동만 하면 되는데, 굳이 상태를 여러 개 만들고 useEffect를 추가하고 별도 함수까지 쪼개 놓을 수 있습니다. 이런 코드는 당장은 멀쩡해 보여도 나중에 수정하기 어려워집니다.

초보자 눈에도 느껴지는 복잡함이 있습니다. 파일 길이가 갑자기 너무 길어졌는지, 비슷한 코드가 여러 번 반복되는지, 이름이 모호한 함수가 늘어났는지 정도만 봐도 충분합니다.

다른 기능을 몰래 건드리지 않았는가

이것도 매우 중요합니다. 내가 글 작성 기능을 수정했는데, 글 수정 화면이나 로그인 화면까지 영향을 받으면 곤란합니다.

AI는 재사용을 시도하면서 공통 컴포넌트를 바꾸는 경우가 많습니다. 그 자체는 좋은 일일 수 있지만, 잘못 바꾸면 여러 화면이 한꺼번에 흔들립니다.

특히 다음과 같은 파일이 바뀌면 조금 더 주의해서 봐야 합니다.

• 공통 버튼, 입력창, 레이아웃 같은 공용 컴포넌트

• 인증, 권한, 라우팅 같은 흐름 제어 파일

• 환경설정이나 전역 상태 파일

이런 파일은 한 군데 바뀌어도 영향 범위가 넓습니다.

읽고 고치기 쉬운 상태인가

이번 장의 중요한 메시지는 단지 버그를 잡는 데 있지 않습니다. 나중의 나를 돕는 데도 있습니다.

지금 AI가 만든 코드가 너무 난해하면, 며칠 뒤의 나는 그 코드를 다시 읽다가 멈추게 됩니다. 결국 "건드리면 망가질까 봐 무서운 파일"이 생깁니다. 그런 파일은 서비스가 커질수록 점점 부담이 됩니다.

그래서 검토할 때는 이렇게 생각해보세요.

"이 코드를 다음 주의 내가 다시 읽을 수 있을까?"

이 질문에 자신 있게 "네"라고 답하기 어렵다면, 지금 조금 더 정리하는 편이 낫습니다.

화면 검토와 코드 검토를 같이 해야 한다

AI의 결과물은 코드만 봐서는 부족하고, 화면만 봐서도 부족합니다. 둘을 함께 봐야 합니다.

예를 들어 화면은 멀쩡해 보이는데 코드 안에는 필요 없는 상태값이 남아 있을 수 있습니다. 반대로 코드는 깔끔해 보이는데 실제 화면에서는 모바일에서 버튼이 잘릴 수도 있습니다.

그래서 검토는 보통 다음 흐름으로 하면 좋습니다.

먼저 바뀐 파일 설명을 듣습니다. 그다음 화면에서 직접 눌러보고, 입력해보고, 이동해봅니다. 그리고 마지막으로 관련 파일을 열어 바뀐 부분을 읽습니다.

즉, 눈으로 한 번 보고, 손으로 한 번 써보고, 코드로 한 번 확인하는 것입니다. 이 세 단계를 거치면 놓치는 것이 크게 줄어듭니다.

"잘 된다"를 확인하는 가장 쉬운 테스트

초보자는 테스트라고 하면 거창하게 느낄 수 있습니다. 하지만 지금 단계에서는 실제 사용자처럼 써보는 것만으로도 훌륭한 검토입니다.

예를 들어 글 작성 기능을 AI가 수정했다면 최소한 아래는 직접 해봐야 합니다.

• 제목과 내용을 정상적으로 입력해 저장되는지 보기

• 아무것도 입력하지 않았을 때 어떻게 되는지 보기

• 너무 긴 글이나 특수문자를 넣었을 때 이상이 없는지 보기

• 저장 후 목록과 상세 화면에서 잘 보이는지 보기

• 내가 작성한 글을 수정하거나 삭제할 때 흐름이 자연스러운지 보기

이런 확인은 겉보기에 단순하지만, 실제로는 많은 문제를 잡아냅니다. AI는 보통 "성공하는 경로"를 중심으로 코드를 짭니다. 하지만 실제 사용자는 실수도 하고, 빈칸도 남기고, 뒤로 가기도 누릅니다. 검토는 그런 현실을 코드에 들이대는 일입니다.

AI가 바꾼 내용을 이해하기 어려울 때

코드를 열어봤는데 도무지 무슨 말인지 모르겠을 수 있습니다. 괜찮습니다. 이럴 때는 이해한 척하지 말고 다시 설명을 받으면 됩니다.

이때 좋은 질문은 아주 구체적이어야 합니다.

"이 함수는 이전과 무엇이 달라졌어?" "이 상태값은 왜 필요한 거야?" "이 부분을 더 단순하게 바꿀 수 있어?" "초보자 기준으로 각 줄이 무슨 역할인지 설명해줘."

핵심은 막연하게 "설명해줘"라고 하지 않는 것입니다. 어디가 이해 안 되는지 짚어주면 AI의 답도 훨씬 쓸모 있어집니다.

그리고 정말 중요하지 않은 부분까지 모두 이해하려고 애쓸 필요는 없습니다. 내가 바꾸려는 기능과 직접 연결된 부분부터 이해하면 됩니다.

위험 신호를 알아두면 검토가 쉬워진다

코드 실력이 아직 부족해도, 이상한 냄새를 맡는 능력은 충분히 기를 수 있습니다. 다음과 같은 경우는 한 번 더 확인해보는 것이 좋습니다.

첫째, 내가 요청하지 않은 파일이 너무 많이 바뀐 경우입니다. 둘째, 같은 코드가 여러 파일에 복붙된 경우입니다. 셋째, 이름만 봐도 무슨 역할인지 알기 어려운 함수나 변수가 늘어난 경우입니다. 넷째, 에러를 제대로 처리하지 않고 그냥 숨겨버린 경우입니다. 다섯째, 화면은 되는데 저장이나 권한 같은 중요한 로직 설명이 빈약한 경우입니다.

이런 신호가 보이면 바로 "이 부분은 왜 이렇게 했는지 설명해줘"라고 물어보세요. 개발에서 이상한 냄새를 그냥 지나치는 습관은, 나중에 큰 문제로 돌아오기 쉽습니다.

되돌릴 수 있어야 안심하고 검토할 수 있다

검토가 중요한 이유 중 하나는, 수정 결과를 받아들일지 말지 선택해야 하기 때문입니다. 그리고 선택하려면 되돌릴 수 있어야 합니다.

그래서 AI가 바꾼 결과를 확인할 때는 항상 이런 태도가 필요합니다.

"이건 최종본이 아니라 검토본이다."

이 생각을 가지면 마음이 편해집니다. 마음이 편해야 검토도 차분하게 할 수 있습니다. 커밋을 자주 남기고, 작업 단위를 나누고, 마음에 들지 않으면 이전 상태로 돌아갈 수 있어야 합니다. 이미 앞 장에서 배운 Git 습관이 여기서 빛을 발합니다.

되돌릴 수 없는 작업은 검토를 무섭게 만들고, 되돌릴 수 있는 작업은 검토를 일상으로 만듭니다.

초보자를 위한 실전 검토 순서

이 장의 내용을 실제 작업 흐름으로 정리하면 다음과 같습니다.

• AI에게 작업 후 변경 파일 목록과 이유를 먼저 설명하게 한다.

• 바뀐 범위가 내가 요청한 범위와 맞는지 본다.

• 화면에서 직접 눌러보고 입력해보며 기본 흐름을 확인한다.

• 관련 파일을 열어 큰 구조부터 읽는다.

• 이해되지 않는 부분은 다시 질문해 더 단순한 설명이나 대안을 받는다.

• 마음에 들지 않으면 수정 요청을 하거나 되돌린다.

• 괜찮다고 판단되면 그때 커밋한다.

중요한 것은 이 순서를 완벽하게 지키는 것이 아니라, 무작정 수용하지 않는 습관을 몸에 익히는 것입니다.

좋은 검토자는 빠르게 승인하는 사람이 아니다

초보자는 종종 검토를 "빨리 끝내야 하는 귀찮은 일"로 여깁니다. 하지만 좋은 검토자는 빠르게 승인하는 사람이 아니라, 필요한 질문을 하는 사람입니다.

특히 AI와 일할 때는 더 그렇습니다. AI는 불평하지도 않고, 다시 질문해도 짜증내지도 않습니다. 그런데 사람은 종종 괜히 미안해서, 혹은 귀찮아서 그냥 넘어갑니다. 바로 그 지점에서 문제가 생깁니다.

질문을 많이 하는 것은 초보의 약점이 아닙니다. 오히려 서비스를 진짜 내 것으로 만드는 과정입니다.

이번 장의 핵심 문장

AI가 바꾼 파일은 결과물이 아니라 제안서처럼 다뤄야 합니다.

제안은 받아들일 수도 있고, 고칠 수도 있고, 거절할 수도 있습니다. 중요한 것은 내가 무엇을 받아들이는지 알고 선택하는 것입니다. 그래야 서비스가 우연히 돌아가는 상태가 아니라, 이해 가능한 상태로 자랍니다.

작동한다는 말에 만족하지 마세요. 괜찮은지, 읽을 수 있는지, 다시 고칠 수 있는지까지 보는 사람이 결국 끝까지 서비스를 완성합니다.

다음 장에서는 이 검토를 더 쉽게 만들기 위해, 왜 작업을 한 번에 크게 시키지 말고 잘게 나누어 맡겨야 하는지 살펴보겠습니다. 작은 단위는 AI를 위한 배려가 아니라, 결국 내 검토를 위한 설계이기도 합니다.