45장. AI가 만든 코드를 어디까지 믿어야 하는가

AI는 빠르지만, 책임지지는 않는다

AI와 함께 개발하다 보면 놀랄 때가 많다. 분명 방금까지 막막했던 문제가 있었는데, Claude Code나 Codex가 순식간에 파일을 만들고, 함수를 고치고, 에러 원인까지 설명해 준다. 처음 이 경험을 하면 자연스럽게 이런 생각이 든다.

"이 정도면 거의 알아서 다 해 주는 것 아닌가?"

바로 여기서 중요한 경계선이 나온다. AI는 빨리 도와줄 수는 있지만, 결과에 책임을 지지는 않는다. 코드가 배포된 뒤에 로그인 오류가 나도, 남의 글이 수정돼도, 환경변수가 노출돼도, 최종 책임은 도구가 아니라 서비스를 만든 사람에게 있다.

이 말이 AI를 무서워하라는 뜻은 아니다. 오히려 반대다. AI를 잘 쓰려면 먼저 어디까지 믿고, 어디서부터 직접 확인해야 하는지를 알아야 한다. 망치를 잘 쓰는 사람은 망치가 집을 대신 설계해 주지 않는다는 사실을 안다. AI도 마찬가지다. 아주 강력한 도구지만, 판단을 대신 살아 주지는 않는다.

이 장의 핵심은 단순하다. AI가 만든 코드는 출발점으로 믿되, 최종본으로는 검증해야 한다. 이 감각이 생기면 AI를 더 안전하게, 더 오래, 더 강하게 쓸 수 있다.

왜 AI 코드는 더 그럴듯하게 느껴질까

AI가 만든 코드는 자주 그럴듯하다. 들여쓰기도 맞고, 변수 이름도 멀쩡하고, 설명도 자신감 있다. 심지어 내가 직접 짠 코드보다 더 깔끔해 보일 때도 있다. 그래서 초보자는 특히 착각하기 쉽다.

"깔끔하네. 그러면 맞는 코드겠지."

하지만 코드가 그럴듯해 보이는 것과 실제로 안전하게 동작하는 것은 전혀 다른 문제다.

예를 들어 AI는 이런 일들을 꽤 자연스럽게 해낸다.

• 지금 프로젝트 스타일에 맞는 코드처럼 보이게 쓴다.

• 자주 쓰는 패턴을 빠르게 조합한다.

• 에러 메시지에 맞춰 가능성 높은 수정안을 제시한다.

문제는 그다음이다. AI는 맥락을 완전히 이해한 존재가 아니다. 내가 준 파일과 대화 내용을 바탕으로 가장 그럴듯한 다음 답을 만든다. 그러다 보니 코드가 매끈해 보여도 실제 프로젝트 사정과 어긋날 수 있다.

가령 이런 일이 벌어진다. 함수 이름은 멋진데 실제 데이터 구조와 맞지 않을 수 있다. 에러 처리는 넣었지만, 진짜 실패 상황에서는 빠져나가는 구멍이 있을 수 있다. 권한 체크를 했다고 썼지만, 실제로는 클라이언트에서만 검사하고 서버에서는 막지 않을 수도 있다.

즉, AI의 위험은 대놓고 이상한 코드를 내는 데만 있지 않다. 오히려 얼핏 봐서는 맞아 보이는 코드가 더 위험할 때가 많다.

AI가 자주 만드는 실수는 따로 있다

AI가 만드는 실수는 무작위처럼 보이지만, 자주 반복되는 패턴이 있다. 이 패턴을 알아두면 검토 속도가 훨씬 빨라진다.

첫째, 없는 것을 있는 것처럼 말하는 경우가 있다. 존재하지 않는 라이브러리 함수, 프로젝트에 없는 파일, 현재 버전에서는 지원하지 않는 옵션을 자연스럽게 제안할 수 있다. 설명은 자신감 있는데 막상 실행하면 "그런 함수 없습니다"가 나온다.

둘째, 행복한 경로만 맞는 코드를 잘 만든다. 사용자가 정상적으로 입력하고, 네트워크도 멀쩡하고, 권한도 맞고, 데이터도 예상대로 있을 때는 잘 돌아간다. 하지만 로그인 세션이 만료됐을 때, 값이 비어 있을 때, 두 번 연속 클릭했을 때, 다른 사용자가 접근했을 때는 틈이 드러난다.

셋째, 프로젝트의 진짜 규칙을 놓치기 쉽다. 우리 서비스에서 "내 글만 수정 가능"이 중요한 규칙이라면, 이 규칙은 단순한 UI 문구보다 훨씬 중요하다. 그런데 AI는 화면에 수정 버튼을 숨기는 것만으로 충분하다고 착각할 수 있다. 사용자는 버튼을 못 보더라도, 직접 요청을 보내면 수정이 될 수도 있다. 이건 겉보기로는 멀쩡하지만 실제로는 위험한 상태다.

넷째, 중복된 코드와 임시방편을 늘릴 수 있다. 당장 문제를 해결하는 데는 성공하지만, 비슷한 코드를 다른 파일에도 복사해서 넣거나, 에러를 조용히 무시하는 방식으로 넘어갈 수 있다. 그러면 나중에 고치기가 더 어려워진다.

다섯째, 보안과 권한을 뒤로 미루는 답을 자주 준다. 일단 동작하게 만드는 데 집중하다 보니, 인증 확인, 입력 검증, 민감 정보 보호, 삭제 범위 제한 같은 중요한 안전장치를 빼먹을 수 있다.

이쯤 되면 감이 온다. AI는 무능해서 위험한 것이 아니라, 일단 답을 빨리 만들기 때문에 위험할 수 있다. 속도는 장점이지만, 바로 그 장점이 검증을 빼먹게 만들기도 한다.

특히 위험한 코드는 따로 있다

모든 AI 생성 코드가 같은 위험도를 가지는 것은 아니다. 어떤 코드는 비교적 편하게 받아들여도 되고, 어떤 코드는 반드시 의심부터 해야 한다.

초보자에게 가장 유용한 기준은 "망가졌을 때 피해가 얼마나 큰가"다.

비교적 믿기 쉬운 영역

화면 문구를 바꾸는 코드, 카드 UI를 정리하는 코드, 버튼 스타일을 맞추는 코드, 목록 정렬 순서를 바꾸는 코드처럼 보여지는 부분은 상대적으로 검토가 쉽다. 물론 이것도 버그가 날 수는 있지만, 보통 피해 범위가 제한적이다.

예를 들어 홈 화면 제목을 바꾸거나, 게시글 카드 간격을 조정하거나, 로딩 스피너를 보여 주는 정도라면 직접 눌러 보며 확인하기도 쉽다.

조심해서 봐야 하는 영역

입력 검증, 검색 조건, 상태 관리, 폼 제출, 로딩과 실패 처리처럼 사용자 흐름에 영향을 주는 코드는 한 단계 더 주의해서 봐야 한다. 얼핏 잘 돌아가도 특정 상황에서만 문제가 날 수 있기 때문이다.

예를 들어 검색은 되는 것처럼 보이는데 대소문자 처리나 빈 문자열 처리에서 이상하게 동작할 수 있다. 제출 버튼도 한 번은 잘 되는데, 두 번 클릭 시 중복 저장이 될 수 있다.

거의 무조건 의심부터 해야 하는 영역

아래와 같은 코드는 반드시 신중하게 봐야 한다.

• 로그인과 세션 처리

• 권한 확인과 작성자 판별

• 데이터베이스의 수정과 삭제

• 관리자 기능

• 결제 관련 로직

• 파일 업로드

• 환경변수 사용

• 외부 API 키 처리

이 영역의 공통점은 분명하다. 한 번 잘못되면 피해가 크고, 눈으로만 봐서는 문제를 놓치기 쉽다.

예를 들어 삭제 코드는 특히 조심해야 한다. "게시글 삭제 기능 추가해 줘"라고 했을 때 AI가 겉보기로는 잘 작동하는 코드를 만들어 줄 수 있다. 그런데 조건이 잘못되면 특정 글 하나만 지워야 할 곳에서 여러 개가 같이 지워질 수도 있다. 초보자는 버튼이 눌러지고 화면이 바뀌면 성공했다고 생각하지만, 실제 데이터는 조용히 망가져 있을 수 있다.

보안은 AI가 자동으로 챙겨주지 않는다

초보자가 가장 많이 오해하는 부분 중 하나가 이것이다.

"요즘 AI가 똑똑하니까 보안도 알아서 신경 쓰겠지?"

아쉽지만 그렇지 않다. AI는 보안을 고려한 답을 줄 수도 있지만, 그렇지 않을 수도 있다. 그리고 더 중요한 점은, 보안은 코드 몇 줄의 문제가 아니라 습관과 기준의 문제라는 것이다.

예를 들어 AI가 다음과 같은 실수를 유도할 수 있다.

클라이언트 코드에 비밀 키를 직접 넣는다. 브라우저에서 누구나 볼 수 있는 곳에 민감한 값을 두는 셈이다. 화면에서는 잘 동작하더라도, 공개되면 안 되는 정보가 그대로 노출된다.

권한 확인을 화면에서만 한다. 수정 버튼을 안 보이게 했다고 해서 권한 검사가 끝난 것이 아니다. 서버나 데이터베이스 쪽에서도 실제로 막아야 한다.

입력값을 그대로 믿는다. 사용자가 보내는 값은 언제든 비어 있을 수 있고, 이상한 형식일 수 있고, 의도적으로 잘못된 값일 수도 있다. "정상 사용자만 쓸 테니까 괜찮다"는 생각은 서비스가 공개되는 순간 쉽게 깨진다.

에러 메시지를 너무 자세히 노출한다. 개발 중에는 편하지만, 운영 중에는 내부 구조를 드러내는 힌트가 될 수 있다.

여기서 중요한 사실은 하나다. 보안은 AI가 추가해 주면 좋은 옵션이 아니라, 사람이 먼저 요구해야 하는 기본 조건이다.

숨은 버그는 대개 잘되는 순간에 숨어 있다

버그라고 하면 보통 빨간 에러 화면을 떠올린다. 하지만 실제로 더 무서운 것은 조용한 버그다. 앱이 멈추지도 않고, 버튼도 눌리고, 겉보기에는 되는 것처럼 보인다. 그런데 내부에서는 이상한 일이 일어난다.

예를 들어 글 작성이 성공했다고 메시지가 떴는데 실제 저장은 안 됐을 수 있다. 목록은 갱신됐는데 예전 데이터가 캐시로 남아 있을 수 있다. 수정 버튼은 잘 보이는데 다른 사람 글도 수정 가능할 수 있다. 로그인 직후에는 잘 되다가 새로고침 후 세션 처리가 꼬일 수도 있다.

이런 문제는 특히 AI가 만든 코드에서 자주 보인다. 이유는 간단하다. AI는 주로 대표적인 흐름을 기준으로 코드를 조합하기 때문이다. 하지만 실제 서비스는 대표적인 흐름보다 예외 상황에서 더 많이 흔들린다.

초보자에게 가장 필요한 감각은 이것이다.

"한 번 됐다고 끝난 게 아니다."

정상 입력, 빈 입력, 잘못된 입력, 로그인한 상태, 로그아웃한 상태, 내 글, 남의 글, 느린 네트워크, 두 번 클릭 같은 상황을 나눠 생각해야 한다. AI가 낸 답은 보통 첫 번째 상황에는 강하지만, 나머지 상황은 비어 있을 수 있다.

AI 코드 신뢰도는 초록불, 노란불, 빨간불로 나눠 보자

매번 모든 코드를 같은 강도로 검토하면 너무 피곤하다. 초보자에게는 위험도에 따라 검토 강도를 달리하는 방식이 현실적이다.

초록불: 비교적 가볍게 확인해도 되는 코드

UI 문구 변경, 단순 스타일 수정, 마진 조정, 아이콘 교체, 정적인 안내 문구, 가벼운 레이아웃 변경은 초록불에 가깝다. 이 경우에는 직접 브라우저에서 보며 확인하는 것만으로도 상당 부분 검토가 가능하다.

물론 완전히 자동 통과는 아니다. 그래도 "잘못되면 큰 사고가 나는 코드"는 아니라는 뜻이다.

노란불: 꼼꼼히 읽고 직접 여러 번 눌러봐야 하는 코드

폼 제출, 검색, 정렬, 상태 변경, 에러 처리, 로딩 처리, 페이지 이동, 데이터 표시 조건 같은 코드는 노란불이다. 사용자가 체감하는 핵심 흐름에 들어가므로, 여러 상황을 상상하며 확인해야 한다.

이 단계에서는 이렇게 질문해 보면 좋다.

• 실패하면 메시지가 보이는가

• 중복 클릭을 막는가

• 값이 없을 때도 안전한가

• 새로고침해도 이상 없는가

빨간불: 사람이 이해할 때까지 그냥 넘기면 안 되는 코드

인증, 권한, 삭제, 결제, 비밀 키, 관리자 페이지, 데이터베이스 쓰기, 파일 업로드 같은 코드는 빨간불이다. 이 영역은 이해하지 못한 채 병합하거나 배포하면 안 된다고 생각하는 편이 맞다.

여기서는 "동작하네"가 통과 기준이 아니다. 왜 이렇게 작성됐는지, 어떤 조건에서 허용되는지, 무엇을 막는지까지 이해해야 한다.

이 신호등 기준만 머리에 넣어도, AI를 대하는 태도가 훨씬 건강해진다. 모든 코드를 무서워할 필요는 없지만, 같은 신뢰도로 대하면 안 된다.

이해 안 되는 코드는 아직 내 코드가 아니다

AI와 협업하다 보면 이런 순간이 있다. 분명 서비스는 돌아가는데, 내가 코드를 읽어도 잘 모르겠다. 그러면 은근히 이런 유혹이 생긴다.

"어쨌든 되니까 그냥 두자."

하지만 이 습관은 나중에 큰 비용으로 돌아온다. 지금 이해하지 못한 코드는, 버그가 났을 때도 고치기 어렵고, 기능을 붙일 때도 겁나고, AI에게 다시 맡길 때도 설명이 어려워진다.

초보자에게 중요한 원칙 하나를 꼭 기억하자.

이해 안 되는 코드는 아직 빌린 코드다.

빌린 코드가 나쁘다는 뜻은 아니다. 처음에는 당연히 많이 빌린다. 다만 빌렸으면, 적어도 어느 정도는 내 것으로 바꾸는 과정이 필요하다. 그 방법은 어렵지 않다.

AI에게 코드 설명을 다시 요청하면 된다. 함수별 역할을 풀어 달라고 해도 좋고, 한 줄씩 설명해 달라고 해도 좋다. 더 쉬운 버전으로 다시 써 달라고 할 수도 있다. 복잡한 로직을 더 단순한 구조로 바꾸게 할 수도 있다.

중요한 것은 체면이 아니다. 모르면 넘어가는 것보다, 모른다고 다시 묻는 편이 훨씬 안전하다.

AI가 만든 코드를 검토할 때 꼭 던져야 할 질문

AI가 만든 코드를 받을 때마다 모든 걸 처음부터 끝까지 의심하는 것은 비효율적이다. 대신 몇 가지 핵심 질문을 습관처럼 던지면 좋다.

이 코드는 정확히 무엇을 바꾸는가

가장 먼저 바뀐 범위를 알아야 한다. UI만 바꾸는지, 서버 요청 방식까지 바꾸는지, 데이터 저장 규칙까지 건드리는지 확인해야 한다. 바뀐 범위를 모르면 검토 범위도 흐려진다.

실패할 때 어떻게 되는가

성공 흐름만 보면 대부분 괜찮아 보인다. 하지만 실패했을 때 메시지가 보이는지, 로딩 상태가 풀리는지, 사용자가 다시 시도할 수 있는지 확인해야 한다.

입력값을 너무 쉽게 믿고 있지 않은가

빈 값, 이상한 값, 긴 값, 예상 밖의 값이 들어와도 괜찮은지 봐야 한다. 초보자는 종종 "내가 그렇게 입력 안 하면 되지"라고 생각하지만, 실제 서비스는 사용자가 아니라 상황이 예상을 깨뜨린다.

권한은 어디서 검사하는가

버튼을 숨기는 것과 실제 접근을 막는 것은 다르다. "내 글만 수정 가능"이라면 화면뿐 아니라 서버나 데이터 정책에서도 같은 규칙이 살아 있어야 한다.

민감한 정보가 노출되지 않는가

API 키, 비밀 키, 내부 URL, 민감한 에러 정보가 브라우저에 노출되지 않는지 확인해야 한다. 이 부분은 나중에 9부에서 더 자세히 다루겠지만, 지금도 감각은 미리 가져가야 한다.

지우거나 덮어쓰는 범위가 너무 넓지 않은가

특히 delete, update, upsert 같은 동작은 대상이 정확히 제한돼 있는지 꼭 봐야 한다. 한 건만 수정해야 하는데 조건이 흐리면 사고가 커진다.

내가 이 코드를 한 문단으로 설명할 수 있는가

이 질문은 의외로 강력하다. 내가 설명할 수 없다는 것은 아직 구조를 충분히 이해하지 못했다는 뜻일 가능성이 크다.

우리 풀스택 프로젝트에서 특히 검증이 필요한 지점

이 책의 실습 프로젝트를 기준으로 보면, AI가 만든 코드 중 반드시 조심해서 봐야 할 지점이 비교적 분명하다.

로그인과 회원가입

가입은 되는데 세션 저장이 어설플 수 있고, 로그인은 되는데 로그아웃 후 상태 정리가 안 될 수 있다. 페이지 이동은 되지만 실제 사용자 정보가 제대로 반영되지 않을 수도 있다. 인증은 겉보기보다 훨씬 섬세한 흐름이다.

글 작성, 수정, 삭제

가장 흔한 착각은 "버튼이 있으니 기능도 안전하다"는 것이다. 실제로는 작성자는 맞는지, 수정 대상은 정확한지, 삭제 범위는 좁은지, 실패 시 사용자에게 제대로 알려 주는지까지 봐야 한다.

내 글과 남의 글 구분

이 부분은 35장에서 권한의 기본 감각을 익혔다. 여기서는 한 걸음 더 나아가야 한다. AI가 만든 코드가 작성자 비교를 어디서 하는지, 그 검사가 화면에서만 끝나는지, 데이터 접근 규칙에도 반영되는지 꼭 봐야 한다.

검색과 목록 표시

겉으로는 단순해 보여도 숨은 버그가 많다. 빈 결과 처리, 대소문자 처리, 특수문자 처리, 로딩 상태, 오래된 데이터 표시 같은 문제가 숨어 있을 수 있다.

파일 업로드와 외부 서비스 연결

이 부분은 특히 위험하다. 파일 형식 제한, 크기 제한, 업로드 실패 처리, 공개 URL 노출 범위, 외부 서비스 키 보관 방식까지 확인해야 한다. 화면에서 업로드가 되기만 한다고 안심하면 안 된다.

AI에게 코드를 맡길 때부터 검증 가능하게 시켜야 한다

검토는 결과를 받은 뒤에만 하는 것이 아니다. 사실 더 중요한 것은 처음 요청할 때부터 검증하기 쉬운 형태로 시키는 것이다.

예를 들어 이렇게 요청하면 위험하다.

"로그인 기능 다 만들어 줘."

이 말은 범위가 너무 넓다. AI는 편한 방식으로 넓게 바꿀 수 있고, 무엇을 기준으로 검토해야 하는지도 흐려진다.

반대로 이런 요청은 훨씬 좋다.

"로그인 페이지에서 이메일과 비밀번호 입력 후 로그인 버튼을 누르면 Supabase 인증을 호출하도록 구현해 줘. 성공 시 /posts로 이동하고, 실패 시 사용자에게 에러 메시지를 보여 줘. 기존 UI 구조는 유지하고, 환경변수 값은 코드에 직접 넣지 마. 변경한 파일과 이유를 함께 설명해 줘."

이렇게 하면 좋은 점이 많다. 작업 범위가 분명하고, 금지선이 있고, 검토 포인트도 함께 생긴다. AI를 잘 쓰는 사람은 많이 시키는 사람이 아니라, 검토 가능한 단위로 시키는 사람이다.

또 하나 좋은 습관은, 코드 생성과 함께 아래 내용도 같이 요구하는 것이다.

• 변경된 파일 목록

• 핵심 로직 설명

• 내가 직접 확인할 수동 체크리스트

• 위험할 수 있는 부분 경고

• 되돌리기 쉬운 작은 단위 변경

이렇게 하면 AI가 단순히 코드를 뱉는 도구가 아니라, 검토를 돕는 보조자로 바뀐다.

"설명해 줘"보다 "검토 관점으로 설명해 줘"가 더 좋다

초보자는 AI에게 설명을 부탁할 때도 넓게 물어보는 경우가 많다.

"이 코드 설명해 줘."

물론 이것도 도움이 된다. 하지만 실전에서는 더 좋은 방식이 있다.

"이 코드에서 보안상 위험할 수 있는 부분을 중심으로 설명해 줘." "권한 처리 관점에서 틀릴 수 있는 부분이 있는지 봐 줘." "예외 상황에서 깨질 수 있는 지점을 먼저 짚어 줘." "내가 직접 검증해야 할 시나리오를 5개만 뽑아 줘."

이런 질문은 AI의 답을 훨씬 실용적으로 만든다. 왜냐하면 우리는 백과사전식 설명이 아니라, 지금 당장 사고를 줄여 줄 검토 포인트가 필요하기 때문이다.

AI는 질문의 방향에 따라 품질 차이가 커진다. 그냥 설명을 요청하면 친절한 해설이 오고, 검토 관점으로 요청하면 훨씬 실무적인 답이 온다.

초보자를 위한 현실적인 검증 순서

막막할 때는 순서가 필요하다. AI가 만든 코드를 받았을 때, 초보자가 가장 무리 없이 따라갈 수 있는 검증 순서는 아래와 같다.

1단계: 무엇이 바뀌었는지 먼저 본다

파일이 몇 개 바뀌었는지, 어느 부분을 건드렸는지, 기존 구조까지 바꿨는지 살펴본다. 여기서 예상보다 범위가 크면 일단 경계해야 한다.

2단계: 코드를 읽고 한 문장으로 요약해 본다

"이 함수는 로그인 요청을 보내고, 성공하면 이동시키는 역할이다"처럼 한 문장으로 설명해 본다. 요약이 안 되면 아직 읽기가 덜 된 것이다.

3단계: 정상 흐름을 직접 눌러 본다

먼저 기본 경로가 되는지 본다. 로그인, 글 작성, 수정, 삭제처럼 기대한 행동이 되는지 확인한다.

4단계: 실패 흐름을 일부러 만들어 본다

빈 값 입력, 잘못된 비밀번호, 권한 없는 접근, 네트워크 오류 비슷한 상황을 가정해 본다. 이 단계에서 숨은 버그가 많이 보인다.

5단계: 위험한 부분은 더 좁게 본다

삭제 조건, 사용자 ID 비교, 환경변수 사용, API 호출 위치 같은 부분을 집중해서 본다. 특히 "누가 무엇을 할 수 있는가"를 다루는 코드는 꼭 다시 확인한다.

6단계: 작은 커밋으로 남긴다

검토가 끝나면 한 덩어리로 크게 커밋하기보다 의미 단위로 남기는 편이 좋다. 나중에 문제가 생겼을 때 되돌리기 쉽다.

이 순서는 단순해 보이지만 강하다. 중요한 것은 화려한 검증 도구보다, 의심해야 할 순서를 몸에 익히는 것이다.

이런 신호가 보이면 바로 멈춰서 다시 봐야 한다

AI가 만든 코드에서 몇 가지 신호가 보이면 그냥 넘어가지 않는 편이 좋다.

먼저, 내가 요청한 것보다 훨씬 많은 파일이 바뀌었다면 다시 봐야 한다. 작은 수정 하나를 부탁했는데 폴더 구조까지 대거 바뀌었다면, 문제 범위를 통제하기 어려워진다.

또, 설명은 그럴듯한데 실제 코드가 너무 복잡해졌다면 멈춰야 한다. 초보자에게 좋은 코드는 마법 같은 코드가 아니라 읽을 수 있는 코드다.

그리고 any 남발, 광범위한 예외 무시, try/catch 안에서 아무 처리도 하지 않기, 실패 시 조용히 넘어가기, 민감 값 하드코딩, 클라이언트에서만 권한 검사하기 같은 패턴이 보이면 반드시 다시 검토해야 한다.

마지막으로, "왜 이렇게 했는지 모르겠지만 일단 됩니다"라는 상태가 되면 멈추는 편이 낫다. 그 문장은 편안해 보여도, 실제로는 다음 문제를 미루는 문장인 경우가 많다.

AI와 협업할수록 사람의 기준이 더 중요해진다

흥미로운 점이 있다. AI가 약할 때는 사람이 많이 직접 코드를 짠다. 그래서 검토도 자연스럽게 많이 하게 된다. 그런데 AI가 강해질수록 코드는 더 빨리 생기고, 사람은 오히려 덜 읽게 된다. 바로 그 순간이 위험하다.

속도가 빨라질수록 더 필요한 것은 기술적 자존심이 아니라 판단 기준이다.

무엇을 AI에게 맡길지, 무엇은 내가 꼭 읽어야 할지, 무엇은 이해할 때까지 배포하지 말아야 할지 기준이 있어야 한다. 이 기준이 없으면 생산성이 올라가는 것이 아니라, 실수의 속도만 빨라진다.

그래서 좋은 AI 협업자는 "AI를 많이 쓰는 사람"이 아니라, AI가 만든 결과를 위험도에 따라 다르게 다루는 사람이다.

믿지 말라는 뜻이 아니라, 검증하며 믿으라는 뜻이다

여기까지 읽으면 AI를 너무 경계해야 하는 것처럼 느껴질 수 있다. 하지만 이 장의 메시지는 "AI를 믿지 마라"가 아니다. 그랬다면 이 책 전체가 성립하지 않는다.

정확히는 이렇게 이해하면 된다.

AI는 믿을 수 있는 도구가 될 수 있다. 다만 그 신뢰는 자동으로 주어지는 것이 아니라, 검증을 거치며 쌓이는 것이다.

처음에는 작은 UI 수정부터 맡기고, 잘 검토하며 감을 잡는다. 그다음에는 폼 처리, 목록 정리, API 연결처럼 조금 더 중요한 영역으로 넓힌다. 인증, 권한, 삭제, 배포, 보안 같은 영역은 더 천천히, 더 엄격하게 검토한다. 이런 식으로 신뢰의 범위를 조절해 가면 된다.

결국 핵심은 맹신도 아니고 불신도 아니다. 통제된 신뢰다.

오늘부터 바로 적용할 나만의 기준 만들기

이 장을 읽고 바로 실천할 수 있는 가장 현실적인 변화는, AI 코드에 대한 개인 기준을 하나 만드는 것이다. 거창할 필요 없다. 예를 들어 이런 규칙이면 충분하다.

• UI 변경 코드는 직접 확인 후 병합한다.

• 데이터 저장과 삭제 코드는 반드시 조건을 읽고 테스트한다.

• 인증과 권한 코드는 이해할 때까지 설명을 다시 요청한다.

• 환경변수와 키가 들어가는 코드는 복붙하지 않고 위치부터 확인한다.

• 이해 안 되는 코드는 그대로 두지 않고 단순화하거나 설명을 받는다.

이 정도만 지켜도 AI와의 협업 품질이 크게 달라진다. 초보자에게 필요한 것은 완벽한 보안 전문가의 시선이 아니라, 그냥 넘어가지 않는 습관이다.

이 장의 핵심 정리

AI가 만든 코드는 빠르고, 유용하고, 자주 놀라울 만큼 그럴듯하다. 하지만 그럴듯함은 정답의 증거가 아니다. AI는 코드를 제안할 수는 있어도, 그 코드가 내 서비스에서 안전하고 적절한지 책임져 주지는 않는다.

그래서 우리는 신뢰의 기준을 세워야 한다. UI처럼 비교적 가벼운 코드는 빠르게 검토하고, 폼 처리와 상태 변경은 꼼꼼히 눌러 보고, 인증·권한·삭제·보안처럼 위험한 코드는 이해할 때까지 멈춰서 확인해야 한다. 특히 보안, 권한, 민감 정보, 데이터 수정 범위는 "되는가"보다 "왜 이렇게 되는가"를 봐야 한다.

결국 AI 시대의 개발 실력은 단순히 코드를 많이 만드는 능력이 아니다. 어떤 코드를 믿고, 어떤 코드를 의심하고, 어떤 코드는 끝까지 확인할지 판단하는 능력이다. 이 기준이 생기면 AI는 불안한 마법이 아니라, 믿고 함께 일할 수 있는 강력한 동료가 된다.

그리고 마지막으로, 이 문장만은 꼭 기억하자.

AI는 빠르지만 책임지지 않는다. 최종 책임은 늘 만드는 사람에게 있다.