AI 코딩의 역설

요즘 AI 코딩을 말할 때 대부분의 관심은 속도에 쏠려 있습니다.

몇 분 만에 기능을 만든다.수백 줄짜리 PR을 한 번에 뽑는다.기획서만 넣으면 화면이 나온다.테스트도 자동으로 붙는다.

겉으로 보면 생산성 혁명입니다.

그런데 여기서 중요한 질문이 하나 빠져 있습니다.

그 코드를 정말 이해하고 있습니까?

AI가 만들어준 코드를 읽지 않고 머지한다면, 그것은 생산성이 아니라 부채 생성입니다.코드가 빨리 나오는 것과 좋은 코드가 나오는 것은 전혀 다른 문제입니다.

AI 코딩은 “속도 도구”가 아니라 “검증 도구”로 봐야 합니다

많은 사람이 AI를 코드 생성기로 씁니다.

“이 기능 만들어줘.”“이 컴포넌트 분리해줘.”“이 API 붙여줘.”“이 에러 고쳐줘.”

물론 가능합니다.하지만 이 방식은 AI의 가장 얕은 사용법입니다.

진짜 흥미로운 지점은 그 다음입니다.

AI에게 코드를 짜게 하는 것이 아니라,AI에게 코드를 의심하게 만드는 것.

“이 PR에서 깨질 수 있는 지점을 찾아줘.”“보안상 위험한 부분을 찾아줘.”“성능 병목이 될 수 있는 쿼리를 찾아줘.”“접근성 문제를 찾아줘.”“이 설계가 실패하는 경로를 설명해줘.”

이렇게 쓰기 시작하면 AI는 단순한 코더가 아니라 리뷰 파트너가 됩니다.

Nolan Lawson도 글에서 여러 AI 리뷰어를 PR에 투입해 critical, high, medium, low 수준으로 버그를 분류하게 하고, 이후 사람이 false positive를 걸러내고 최종 판단하는 방식을 소개합니다. 그는 이 과정이 오히려 속도를 높이지 않을 수 있지만, 코드베이스의 건강성을 개선한다고 말합니다. 

중요한 것은 “버그를 찾는 능력”이 아니라 “버그를 다루는 능력”입니다

AI는 생각보다 버그를 잘 찾습니다.

문제는 그 다음입니다.

AI가 말한 모든 것을 고치면 안 됩니다.모든 경고가 같은 무게를 갖지 않습니다.모든 edge case를 처리하는 것이 좋은 엔지니어링은 아닙니다.

어떤 이슈는 반드시 고쳐야 합니다.어떤 이슈는 주석 하나면 충분합니다.어떤 이슈는 지금 고치면 오히려 코드가 복잡해집니다.어떤 이슈는 “이 PR의 방향 자체가 잘못됐다”는 신호입니다.

그래서 AI 시대의 개발자는 더 이상 “코드를 직접 치는 사람”만으로 정의되지 않습니다.

AI가 쏟아낸 이슈 중에서무엇이 진짜 문제인지,무엇을 지금 고쳐야 하는지,무엇을 의도적으로 미뤄야 하는지,무엇 때문에 설계를 되돌려야 하는지 판단하는 사람.

이게 앞으로 더 중요한 개발자입니다.

“10배 생산성”보다 중요한 것은 “10배 많은 질문”입니다

AI 코딩을 잘못 쓰면 이런 흐름이 됩니다.

이건 빠른 개발이 아닙니다.빠른 방치입니다.

반대로 AI를 제대로 쓰면 흐름이 달라집니다.

속도는 느려질 수 있습니다.

하지만 이 과정에서 개발자는 코드베이스를 더 깊이 이해합니다.행복 경로가 아니라 실패 경로를 봅니다.문서에 없는 암묵적 가정을 발견합니다.테스트가 없던 영역에 테스트를 붙입니다.

결국 남는 것은 “더 많은 코드”가 아니라 더 잘 이해된 시스템입니다.

AI가 만든 코드를 이해하지 못하면, 그 코드는 내 코드가 아닙니다

AI 시대에 가장 위험한 개발자는 AI를 쓰는 개발자가 아닙니다.

가장 위험한 개발자는AI가 만든 코드를 이해하지 못한 채 배포하는 개발자입니다.

코드가 돌아간다고 끝이 아닙니다.

왜 이 구조인지 설명할 수 있어야 합니다.어디서 깨질 수 있는지 말할 수 있어야 합니다.장애가 났을 때 어느 레이어를 봐야 하는지 알아야 합니다.리뷰어가 질문했을 때 “AI가 그렇게 만들었습니다”라고 말하면 안 됩니다.

그 순간 책임은 사라지지 않습니다.오히려 더 선명해집니다.

AI는 코드를 만들 수 있지만,운영 책임은 사람이 집니다.

좋은 AI 코딩 루프는 이렇게 바뀌어야 합니다

이제 AI 코딩의 질문을 바꿔야 합니다.

예전 질문은 이랬습니다.

“얼마나 빨리 만들 수 있나?”

이제 질문은 이래야 합니다.

“이 코드를 얼마나 깊이 이해했나?”“실패 경로를 얼마나 검토했나?”“AI 리뷰어들이 찾은 문제를 어떻게 우선순위화했나?”“이 PR을 머지하지 말아야 할 이유는 없는가?”“다음 개발자가 이 코드를 더 쉽게 이해할 수 있는가?”

AI가 속도를 올려줄수록, 사람은 더 느리게 생각해야 합니다.

이건 역설처럼 보이지만, 실제로는 균형입니다.

생성은 빨라졌습니다.그러니 검증은 더 강해져야 합니다.

팀 단위로 보면 더 중요합니다

개인 개발자가 AI로 빠르게 기능을 만드는 것은 당장 좋아 보입니다.

하지만 팀에서는 문제가 달라집니다.

한 사람이 이해하지 못한 코드는다른 사람에게 유지보수 비용으로 넘어갑니다.

한 사람이 빠르게 만든 복잡한 구조는운영팀에게 장애 대응 부담으로 넘어갑니다.

한 사람이 AI로 만든 대형 PR은리뷰어에게 해석 비용으로 넘어갑니다.

그래서 팀의 AI 코딩 원칙은 단순해야 합니다.

AI로 작성한 코드는 더 엄격하게 리뷰한다.큰 PR보다 작은 PR을 선호한다.AI 리뷰어를 붙이되, 최종 판단은 사람이 한다.critical/high 이슈가 많으면 구현을 고치는 것이 아니라 방향을 다시 본다.이해하지 못한 코드는 머지하지 않는다.

이 정도 규칙만 있어도 AI 코딩은 “속도 경쟁”이 아니라 “품질 루프”가 됩니다.

결국 AI 코딩의 성숙도는 속도가 아니라 태도에서 갈립니다

AI를 쓰면 누구나 코드를 많이 만들 수 있습니다.

하지만 좋은 팀은 코드를 많이 만드는 팀이 아닙니다.좋은 팀은 나쁜 코드를 덜 남기는 팀입니다.

AI가 만들어준 코드가 많아질수록우리에게 필요한 능력은 더 분명해집니다.

천천히 읽는 능력.의심하는 능력.실패 경로를 상상하는 능력.버릴 줄 아는 능력.고칠 가치가 있는 문제와 그렇지 않은 문제를 구분하는 능력.

AI 시대의 개발 역량은 “프롬프트를 잘 치는 능력”에서 끝나지 않습니다.

진짜 역량은 이것입니다.

AI가 만든 결과물을 내 판단으로 다시 소유하는 능력.

마무리

AI로 더 빨리 코딩하는 시대는 이미 왔습니다.

하지만 그 다음 질문이 더 중요합니다.

빠르게 만든 코드를천천히 읽고,집요하게 의심하고,필요하면 버리고,더 좋은 방향으로 고쳐낼 수 있는가.

앞으로 좋은 개발자는 AI를 덜 쓰는 사람이 아닙니다.AI가 만든 속도에 휩쓸리지 않는 사람입니다.

코드는 빨리 나올 수 있습니다.하지만 이해는 여전히 시간이 걸립니다.

그리고 좋은 소프트웨어는 빠른 생성이 아니라 느린 이해 위에 쌓입니다.

[원문]

https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/