AI 코딩, 빨리 많이 찍어내는 대신 천천히 더 좋은 코드 쓰기

• AI 코딩을 ‘대충 돌아가는 코드 왕창 뽑는 기계’로만 보는 건 너무 좁은 해석이라는 글임

  • 글쓴이는 대규모 언어 모델(LLM)이 빠른 코드 생산뿐 아니라, 느리고 꼼꼼한 품질 개선에도 꽤 잘 맞는다고 봄
  • 흔히 말하는 vibe coding이 “수백 줄 PR 던지고 대충 병합” 쪽으로 소비되지만, 반대로 PR을 더 깊게 이해하는 도구로도 쓸 수 있다는 얘기

• 핵심은 AI를 작성자가 아니라 ‘버그 찾는 리뷰어 떼’처럼 쓰는 방식임

  • 글쓴이는 Mythos 사례를 들면서, LLM 에이전트가 코드베이스에 반복 투입되면 사람이 감당하기 어려울 만큼 많은 버그를 찾아낸다고 말함
  • Anthropic과 OpenAI의 최신 공개 모델들도, 충분히 검토되지 않은 코드베이스에서는 미묘한 버그를 꽤 잘 찾아낸다는 경험담을 공유함
  • 문제는 버그를 찾는 능력이 아니라, 그중 뭐가 진짜고 뭐부터 고칠지 판단하는 쪽에 있음

• 글쓴이의 워크플로는 꽤 구체적임
  • Claude 서브에이전트, Codex, Cursor Bugbot을 각각 돌려서 PR의 버그를 critical, high, medium, low로 분류하게 함
  • 이후 각 도구가 낸 결과를 다시 사람이 읽고, 직접 조사해서 환각이나 엉뚱한 지적을 걸러냄
  • 버그의 정의도 팀 기준에 맞게 넣을 수 있음. 예를 들면 KISS, DRY 원칙, 접근성 있는 HTML/JSX, SQL 쿼리 인덱스 사용 같은 기준

sequenceDiagram
    participant 개발자
    participant 클로드
    participant 코덱스
    participant 버그봇
    participant 최종리뷰
    개발자->>클로드: PR 버그 분석 요청
    개발자->>코덱스: 같은 PR 독립 검토 요청
    개발자->>버그봇: 심각도별 버그 탐색 요청
    클로드-->>최종리뷰: 후보 이슈 보고
    코덱스-->>최종리뷰: 후보 이슈 보고
    버그봇-->>최종리뷰: 후보 이슈 보고
    최종리뷰-->>개발자: false positive 제거 후 우선순위 확정

• 결과는 “와 생산성 10배!” 같은 그림이 아님. 오히려 느려질 때가 많음

  • AI 리뷰가 새 PR의 문제만 찾는 게 아니라, 이미 코드베이스에 숨어 있던 기존 버그까지 끌어내기 때문임
  • 그러면 원래 하려던 작업에서 벗어나 유닛 테스트를 쓰고, 오래된 결함을 고치고, 설계 가정을 다시 확인하는 식의 옆길로 빠짐
  • 근데 글쓴이는 이게 나쁜 옆길이 아니라, 코드베이스 건강도를 올리고 낯선 구석을 배우는 과정이라고 봄

• 버그 처리 방식도 “전부 고쳐”가 아니라 꽤 현실적임

  • critical과 high는 에이전트에게 고치게 하되, 해결 방향은 사람이 잡아줌
  • high나 medium이라도 좁은 엣지 케이스 하나 고치려고 100줄이 필요하면 그냥 넘길 수 있음
  • critical이 너무 많이 나오면, 그 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가 코드를 대신 써줬더라도, 최종적으로 운영 중 장애를 맞는 건 팀이라서 개발자가 변경의 구조와 실패 조건을 설명할 수 있어야 해요.