핵심 요약
AI 코딩의 핵심은 코드를 빠르게 많이 찍어내는 것이 아니라, 버그를 찾고 설계를 검증하며 품질을 높이는 데에도 있다.
여러 AI 모델이나 여러 관점의 리뷰를 병렬로 활용하면 환각과 오탐을 줄이고, 사람이 놓친 결함을 발견할 수 있다.
이 방식은 속도를 크게 높이기보다 코드베이스를 더 깊이 이해하고 건강하게 만드는 느린 개발 방식에 가깝다.
AI는 '코드 생산기'가 아니라 '버그 탐지기'로도 강하다
많은 사람은 AI 코딩을 "대충 동작하는 코드를 빠르게 생성하는 도구"로 생각한다.
하지만 LLM은 코드 작성뿐 아니라 코드의 실패 가능성을 찾는 데도 유용하다.
특히 충분히 검토되지 않은 코드베이스에 AI 리뷰를 반복해서 적용하면 보안 문제, 정확성 문제, 성능 문제, 유지보수성 문제까지 폭넓게 드러난다.
즉 AI를 "코드를 더 많이 쓰는 도구"가 아니라 "코드를 더 의심하게 만드는 도구"로 사용할 수 있다.
문제는 발견이 아니라 우선순위와 검증이다
AI는 버그 후보를 많이 찾아낸다.
하지만 모든 지적이 똑같이 중요한 것은 아니다.
어떤 것은 실제 장애로 이어질 수 있는 치명적 문제이고, 어떤 것은 아주 희박한 엣지 케이스이며, 어떤 것은 단순히 주석이 애매하다는 수준일 수 있다.
따라서 핵심 작업은 "AI가 찾은 것을 그대로 믿기"가 아니라, 중요도를 나누고 실제 문제인지 확인하는 것이다.
좋은 리뷰 과정은 탐지보다 판별에 가깝다.
여러 모델을 함께 쓰면 오탐을 줄일 수 있다
한 모델만 쓰면 그 모델의 편향이나 착각에 끌려갈 수 있다.
그래서 원문에서는 Claude, Codex, Cursor Bugbot 같은 여러 도구를 각각 독립적으로 실행한 뒤 결과를 종합하는 방식을 소개한다.
핵심은 서로 다른 시각에서 같은 PR을 보게 하는 것이다.
여러 리뷰어가 비슷한 문제를 지적하면 실제 결함일 가능성이 높아지고, 한 모델만 주장하는 이상한 지적은 걸러내기 쉬워진다.
이는 병원에서 여러 의사에게 2차 소견을 받는 것과 비슷하다.
좋은 AI 리뷰 프롬프트는 기준을 명확히 한다
AI에게 "버그를 찾아줘"라고만 하면 결과가 들쭉날쭉할 수 있다.
더 좋은 방식은 심각도 기준과 코드 품질 기준을 함께 주는 것이다.
예를 들어 치명적, 높음, 중간, 낮음 같은 우선순위를 나누게 할 수 있다.
또 KISS, DRY, 접근성 있는 HTML/JSX, SQL 인덱스 사용, 성능, 보안 같은 팀의 기준을 포함하면 리뷰 품질이 좋아진다.
AI 리뷰도 사람 리뷰와 마찬가지로 "무엇을 중요하게 볼 것인가"를 알려줘야 한다.
느린 워크플로: 고위험 문제부터 반복적으로 제거하기
효과적인 흐름은 단순하다.
먼저 AI 리뷰로 문제를 찾고, 치명적이거나 높은 우선순위의 문제부터 고친다.
그다음 다시 리뷰를 돌려 같은 수준의 문제가 사라질 때까지 반복한다.
중간 이하의 문제는 비용 대비 가치가 낮으면 과감히 미룰 수 있다.
예를 들어 매우 드문 엣지 케이스를 고치기 위해 100줄의 복잡한 코드가 필요하다면, 지금 고치는 것이 오히려 손해일 수 있다.
반대로 치명적 문제가 너무 많이 나온다면, 작은 수정으로 버티기보다 PR의 접근 자체를 버리는 편이 낫다.
AI 리뷰는 숨은 기존 버그까지 끌어낸다
이 방식은 원래 PR의 문제만 찾지 않는다.
리뷰 도중 기존 코드에 숨어 있던 결함이 발견될 수 있다.
그러면 개발자는 새 기능을 빨리 끝내는 대신, 단위 테스트를 추가하고 오래된 설계의 허점을 고치는 길로 빠질 수 있다.
겉으로 보면 생산성이 떨어진 것처럼 보인다.
하지만 장기적으로는 코드베이스의 체력을 올리는 작업이다.
새 기능 하나를 붙이는 대신, 앞으로의 개발자가 덜 다치도록 바닥을 고르는 일에 가깝다.
이해하지 못한 PR은 위험하다
AI가 수백 줄짜리 PR을 만들어줬더라도 개발자가 그 내용을 이해하지 못하면 위험하다.
원문은 AI에게 PR의 동작 방식과 실패 가능성을 설명하게 하라고 제안한다.
필요하면 Markdown 문서나 Mermaid 다이어그램을 만들게 해도 된다.
또 질문을 반복해서 PR의 흐름, 예외 상황, 데이터 구조, 보안 조건을 끝까지 파악해야 한다.
AI가 코드를 썼더라도 책임은 여전히 사람에게 있다.
여러 '관점'을 가진 리뷰어도 유용하다
여러 모델을 쓰는 방식뿐 아니라, 여러 역할을 부여하는 방식도 가능하다.
예를 들어 아키텍트, 테스트 엔지니어, 보안 담당자, 컴플라이언스 담당자, 성능 전문가처럼 각기 다른 관점에서 리뷰하게 할 수 있다.
프론트엔드, 백엔드, 인프라가 섞인 PR에서는 이런 방식이 특히 유용하다.
한 사람에게 모든 것을 보게 하기보다, 여러 전문가가 한 테이블에 앉아 각자의 렌즈로 코드를 보는 구조다.
주니어 개발자에게는 압도적일 수 있다
AI가 많은 문제를 찾아준다고 해서 모두에게 쉬운 것은 아니다.
경험 많은 개발자는 실제 위험과 이론적 위험을 구분할 수 있다.
하지만 주니어 개발자는 "언젠가 문제가 될 수도 있음"과 "당장 고쳐야 하는 버그"를 구분하기 어려울 수 있다.
따라서 AI 리뷰는 학습 도구이면서 동시에 멘토링이 필요한 도구다.
AI가 지적한 문제를 무조건 수용하기보다, 왜 중요한지, 실제로 재현 가능한지, 지금 고칠 가치가 있는지 판단하는 훈련이 필요하다.
인사이트
AI 코딩을 빠른 자동완성 도구로만 보면 품질 저하와 무책임한 PR이 따라오기 쉽다.
반대로 AI를 집요한 리뷰어, 질문자, 실패 모드 탐색기로 쓰면 개발 속도는 느려질 수 있지만 코드 이해도와 안정성은 올라간다.
실천 팁은 간단하다.
큰 PR을 만들었다면 바로 병합하지 말고, 여러 AI 리뷰어에게 독립적으로 검토시키고, 치명적 문제부터 고친 뒤, 자신이 PR을 처음부터 끝까지 설명할 수 있을 때만 병합하라.
Source : Using AI to write better code more slowly | Read the Tea Leaves
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.