--- title: "AI 코딩, 빨리 많이 찍어내는 대신 천천히 더 좋은 코드 쓰기" published: 2026-05-25T23:16:59.000Z canonical: https://jeff.news/article/3229 --- # AI 코딩, 빨리 많이 찍어내는 대신 천천히 더 좋은 코드 쓰기 AI 코딩을 ‘대충 돌아가는 코드 빠르게 뽑는 도구’로만 보면 절반만 보는 거라는 주장이다. 글쓴이는 여러 대규모 언어 모델(LLM) 에이전트를 코드 리뷰에 동시에 투입해 버그를 찾고, 사람이 우선순위와 진짜 버그 여부를 검증하는 느린 워크플로를 소개한다. 생산성 숫자는 덜 화려해도, 코드베이스를 더 잘 이해하고 품질을 끌어올리는 방식으로 AI를 쓸 수 있다는 얘기다. - AI 코딩을 ‘대충 돌아가는 코드 왕창 뽑는 기계’로만 보는 건 너무 좁은 해석이라는 글임 - 글쓴이는 대규모 언어 모델(LLM)이 빠른 코드 생산뿐 아니라, 느리고 꼼꼼한 품질 개선에도 꽤 잘 맞는다고 봄 - 흔히 말하는 vibe coding이 “수백 줄 PR 던지고 대충 병합” 쪽으로 소비되지만, 반대로 PR을 더 깊게 이해하는 도구로도 쓸 수 있다는 얘기 - 핵심은 AI를 작성자가 아니라 ‘버그 찾는 리뷰어 떼’처럼 쓰는 방식임 - 글쓴이는 Mythos 사례를 들면서, LLM 에이전트가 코드베이스에 반복 투입되면 사람이 감당하기 어려울 만큼 많은 버그를 찾아낸다고 말함 - Anthropic과 OpenAI의 최신 공개 모델들도, 충분히 검토되지 않은 코드베이스에서는 미묘한 버그를 꽤 잘 찾아낸다는 경험담을 공유함 - 문제는 버그를 찾는 능력이 아니라, 그중 뭐가 진짜고 뭐부터 고칠지 판단하는 쪽에 있음 > [!IMPORTANT] > 글쓴이가 말하는 좋은 AI 리뷰의 포인트는 “모델 하나를 믿기”가 아니라 “서로 다른 모델 여러 개를 던지고, 사람이 최종 검증하기”임. - 글쓴이의 워크플로는 꽤 구체적임 - Claude 서브에이전트, Codex, Cursor Bugbot을 각각 돌려서 PR의 버그를 critical, high, medium, low로 분류하게 함 - 이후 각 도구가 낸 결과를 다시 사람이 읽고, 직접 조사해서 환각이나 엉뚱한 지적을 걸러냄 - 버그의 정의도 팀 기준에 맞게 넣을 수 있음. 예를 들면 KISS, DRY 원칙, 접근성 있는 HTML/JSX, SQL 쿼리 인덱스 사용 같은 기준 ```mermaid sequenceDiagram participant 개발자 participant 클로드 participant 코덱스 participant 버그봇 participant 최종리뷰 개발자->>클로드: PR 버그 분석 요청 개발자->>코덱스: 같은 PR 독립 검토 요청 개발자->>버그봇: 심각도별 버그 탐색 요청 클로드-->>최종리뷰: 후보 이슈 보고 코덱스-->>최종리뷰: 후보 이슈 보고 버그봇-->>최종리뷰: 후보 이슈 보고 최종리뷰-->>개발자: false positive 제거 후 우선순위 확정 ``` - 결과는 “와 생산성 10배!” 같은 그림이 아님. 오히려 느려질 때가 많음 - AI 리뷰가 새 PR의 문제만 찾는 게 아니라, 이미 코드베이스에 숨어 있던 기존 버그까지 끌어내기 때문임 - 그러면 원래 하려던 작업에서 벗어나 유닛 테스트를 쓰고, 오래된 결함을 고치고, 설계 가정을 다시 확인하는 식의 옆길로 빠짐 - 근데 글쓴이는 이게 나쁜 옆길이 아니라, 코드베이스 건강도를 올리고 낯선 구석을 배우는 과정이라고 봄 - 버그 처리 방식도 “전부 고쳐”가 아니라 꽤 현실적임 - critical과 high는 에이전트에게 고치게 하되, 해결 방향은 사람이 잡아줌 - high나 medium이라도 좁은 엣지 케이스 하나 고치려고 100줄이 필요하면 그냥 넘길 수 있음 - critical이 너무 많이 나오면, 그 PR 자체의 접근이 틀렸다고 보고 버리는 판단도 함 > [!TIP] > AI 리뷰를 붙일 때는 “이 PR이 어떻게 동작해?”보다 “이 PR은 어디서 실패할 수 있어?”를 물어보는 쪽이 훨씬 실전적임. - 글쓴이가 제안하는 느린 vibe coding은 PR을 이해하는 데 AI를 쓰는 방식임 - 에이전트에게 PR의 동작 방식과 실패 모드를 설명하게 함 - 필요하면 Mermaid 차트가 들어간 마크다운 문서를 만들게 해서 구조를 눈에 보이게 함 - Matt Pocock의 `/grill-me` 같은 스킬을 써서, PR을 앞뒤로 완전히 설명할 수 있을 때까지 질문을 받는 방식도 언급함 - 결론은 단순함. AI 코딩을 ‘더 빨리 많이’가 아니라 ‘더 천천히 제대로’ 쓰자는 것 - 토큰을 많이 태운 끝에 “이 접근 자체가 틀렸네”라는 결론만 얻을 수도 있음 - 그래도 그건 실패라기보다, 잘못된 방향의 대형 PR을 병합하기 전에 멈춘 거라서 꽤 비싼 사고를 막은 셈임 - 개발자의 역할은 사라지는 게 아니라, 더 집요한 검토자이자 우선순위 결정자로 이동함 --- ## 기술 맥락 - 이 글의 선택은 AI를 코드 생성기가 아니라 리뷰 파이프라인의 일부로 두는 거예요. 왜냐면 코드 작성 속도보다 병합 이후의 결함 비용이 더 큰 팀에서는, 빠른 생성보다 실패 모드 탐지가 더 값지거든요. - 여러 모델을 동시에 쓰는 이유는 한 모델의 판단을 그대로 믿지 않기 위해서예요. Claude, Codex, Cursor Bugbot이 각각 다른 후보 이슈를 내고, 사람이 겹치는 지점과 근거를 확인하면 환각성 지적을 줄일 수 있어요. - critical, high, medium, low처럼 심각도를 나누는 것도 중요해요. 모든 문제를 다 고치려 하면 리뷰가 끝나지 않으니까, 보안이나 정확성처럼 치명적인 문제부터 처리하고 작은 품질 이슈는 비용 대비 효과를 따져야 하거든요. - Mermaid 문서화나 `/grill-me` 같은 방식은 PR 이해도를 강제로 끌어올리는 장치예요. AI가 코드를 대신 써줬더라도, 최종적으로 운영 중 장애를 맞는 건 팀이라서 개발자가 변경의 구조와 실패 조건을 설명할 수 있어야 해요. ## 핵심 포인트 - AI 코딩의 목표를 속도가 아니라 품질로 잡을 수 있다는 주장 - 여러 모델을 코드 리뷰에 동시에 투입하면 환각성 버그 제보를 줄일 수 있음 - 중요 버그는 에이전트로 고치되, 사람이 해결 방향과 우선순위를 잡는 흐름 - 기존 코드의 숨어 있던 결함까지 드러나서 오히려 개발 속도는 느려질 수 있음 - PR을 이해하지 못한 채 병합하는 vibe coding 대신, PR의 실패 모드를 캐묻는 느린 방식 제안 ## 인사이트 요즘 AI 코딩 논쟁이 ‘몇 줄을 얼마나 빨리 뽑았나’에 쏠려 있는데, 이 글은 반대로 AI를 집요한 리뷰어로 쓰자는 쪽이라 실무 감각이 꽤 좋다. 특히 여러 모델의 결과를 교차 검증하고 사람이 마지막 판단을 한다는 부분이 핵심임.