AI를 사용해 더 나은 코드를 더 천천히 작성하기

2 days ago 3
  • AI 코딩은 저품질 코드를 빠르게 대량 생성하는 방식뿐 아니라, PR을 깊게 검토해 고품질 코드를 천천히 만드는 데도 활용 가능함
  • LLM 에이전트는 코드베이스에서 버그 탐지에 강하지만, 실제 난점은 발견한 항목의 우선순위 지정과 검증에 있음
  • 여러 모델을 함께 쓰는 Claude skill은 Claude sub-agent, Codex, Cursor Bugbot으로 PR을 검토하고 오탐을 줄인 최종 보고서를 만듦
  • 처리 흐름은 critical/high 문제를 반복 수정하고, 비용 대비 이득이 낮은 항목은 건너뛰며, 치명적 문제가 많으면 PR을 포기하는 방식임
  • 이 방식은 속도보다 코드베이스 건강을 중시하며, 실패 모드와 기존 버그를 이해하는 신중한 프로그래밍을 강화함

AI 코딩을 느리게 쓰는 방식

  • AI 코딩을 저품질 코드를 빠르게 대량 생성하는 용도로만 보는 관점은 LLM의 유연성을 과소평가함
  • LLM은 빠른 코드 생성뿐 아니라 고품질 코드를 더 천천히 작성하는 데도 효과적으로 쓸 수 있음
  • slop cannons처럼 미검증 대형 PR을 쏟아내는 방식과 반대로, PR을 더 깊게 검토하고 실패 가능성을 집요하게 확인하는 방식도 가능함

버그 탐지보다 중요한 검증과 우선순위

  • Mythos는 LLM 에이전트가 코드베이스에서 버그를 매우 잘 찾을 수 있음을 보여줌
  • 다른 사례에서도 Mythos가 아닌 모델들이 미검토 코드베이스에서 많은 버그를 찾을 수 있음
  • 최신 공개 Anthropic 및 OpenAI 모델은 미묘한 버그 탐지와 오탐 회피 능력에는 차이가 있지만, 충분히 많은 버그를 찾아낼 수 있음
  • 실제 어려움은 버그 발견 자체보다 우선순위 지정검증에 있음

여러 모델로 PR을 검토하는 Claude skill

  • 여러 모델을 비교·토론시키는 AI 코드 리뷰 접근은 서로 다른 모델을 더 많이 투입할수록 환각이나 잘못된 버그 보고 가능성이 줄어든다는 데 초점을 둠
  • 사용 중인 Claude skill은 PR 검토를 위해 Claude sub-agent, Codex, Cursor Bugbot을 실행함
  • 각 도구는 PR의 버그를 critical/high/medium/low로 등급화하고, 이후 결과를 종합해 오탐을 제거한 최종 보고서를 만듦
  • “버그”의 범위는 프로젝트 기준에 맞춰 넓힐 수 있음
    • KISSDRY 원칙 위반
    • 접근성 있는 HTML/JSX 작성 여부
    • SQL 쿼리에 적절한 인덱스를 사용하는지 여부
    • 그 밖의 프로젝트별 품질 기준

실제 워크플로와 판단 기준

  • 이 방식은 PR에서 많은 버그를 찾고, 오탐률도 거의 0에 가깝게 낮출 수 있음
  • 발견되는 문제는 보안·정확성 관련 치명적 버그부터 성능 문제, “주석이 오해를 부른다” 수준의 낮은 심각도 문제까지 다양함
  • 일반적인 처리 흐름

    • critical과 high 등급은 에이전트가 수정하게 하되, 적절한 해결책은 사람이 안내함
    • critical/high가 없어질 때까지 반복함
    • 수정 비용 대비 이득이 낮은 high/medium 문제는 건너뜀
    • 좁은 엣지 케이스를 고치기 위해 100줄의 코드가 필요한 경우가 대표적임
    • critical 문제가 너무 많아 전체 접근이 잘못됐다고 판단되면 PR을 포기함

생산성보다 코드베이스 건강에 초점

  • 이 기법이 반드시 개발 속도를 높이지는 않음
  • 리뷰 과정에서 PR 이전부터 있던 기존 버그가 발견되어, 단위 테스트 작성과 미묘한 결함 수정으로 이어질 수 있음
  • 흔히 “vibe coding”에서 떠올리는 “10배 생산성”식 개발과는 반대에 가까움
  • 복잡한 아키텍처에서는 정상 경로보다 실패 모드가 더 흥미롭고, 그 실패 지점을 이해하고 고치는 과정이 코드베이스를 익히는 방법이 될 수 있음
  • 전체 코드베이스의 건강을 개선하면서 잘 알려지지 않은 구석을 배우는 데 유용함

느린 vibe coding을 위한 실천법

  • 에이전트로 자신도 완전히 이해하지 못한 수백 줄짜리 PR을 만드는 개발자라면 더 느린 방식을 시도해볼 수 있음
  • 에이전트에게 PR이 어떻게 동작하는지, 어디서 실패할 수 있는지 물어볼 수 있음
  • 필요하면 Mermaid charts가 포함된 Markdown 문서를 작성하게 할 수 있음
  • PR을 처음부터 끝까지 이해할 때까지 Matt Pocock의 /grill-me skill을 사용할 수 있음
  • 코드 줄 수 기준의 “생산성”은 늘지 않을 수 있고, 많은 토큰을 쓴 뒤 처음 계획이 잘못됐다는 결론에 이를 수도 있음
  • 이 방식은 LLM 이전부터 지향하던 신중하고 체계적이며 품질에 집착하는 프로그래밍을 더 강력하게 만든 형태에 가까움
Read Entire Article