▲

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

 (nolanlawson.com)
5P by GN⁺ | ★ favorite | 댓글 1개
  • 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로 등급화하고, 이후 결과를 종합해 오탐을 제거한 최종 보고서를 만듦
  • “버그”의 범위는 프로젝트 기준에 맞춰 넓힐 수 있음
    • KISS와 DRY 원칙 위반
    • 접근성 있는 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 이전부터 지향하던 신중하고 체계적이며 품질에 집착하는 프로그래밍을 더 강력하게 만든 형태에 가까움

함께 보면 좋은 글 β

▲
GN⁺   [-]
Lobste.rs 의견들

  • 내 직장에서는 AI로 더 빨리 움직이겠다는 꿈은 포기했음. 우리 경우에는 코딩이 병목이 아니기 때문임
    그래도 코딩 에이전트가 좋은 건, 항상 되고 싶었던 엔지니어처럼 일하게 해준다는 점임
    예를 들면 코드를 조금 더 밀어붙일 수 있는 제대로 된 테스트 하네스를 만들고, 생성 코드가 원본과 맞는지 검증하는 CI 단계를 추가하고, 변경 배포를 제대로 모니터링하는 일들임
    예전 같으면 GitLab CI 매뉴얼을 읽고 조건을 맞추는 법과 우리 회사의 꼬인 방식을 파악해야 해서 일정상 감당 못 했을 일들인데, 이제는 가능해졌고 이게 미래라고 봄

  • LLM을 API를 아는 스파이크 파트너나 기계적 리팩터링 장치로 쓰면 꽤 성공적이었고, 특히 타입이 강한 언어에서 효과가 큼. 테스트 작성에도 좋지만, 그 테스트가 실제 제약력을 갖는지 확인하는 다층 절차가 있어야 함
    변이 테스트가 꽤 도움이 됐고, 원문이 제안한 것처럼 여러 번의 검토도 필요함
    예전에는 LLM에 훨씬 부정적이었고, 돌아보면 비합리적일 정도였지만, 대부분은 LLM이 쏟아내던 저품질 소프트웨어 때문이었음
    직접 파고들어 보니 판지 프로토타이핑 도구이자 훨씬 빠른 타자수처럼 다루는 게 맞았음. 예를 들어 “이 Lean 프로젝트의 모든 정리에서 이 패턴을 찾아 저 패턴으로 바꾸고, 바로 안 되는 곳은 표시해서 남은 목록을 달라”고 하면, 내가 vim, sed, awk와 임시방편을 섞어 첫두 번 시도할 시간에 100개 넘는 정리를 청크 단위로 고쳐줌
    Lean은 언어 특성과 내가 하는 작업상 “컴파일됨”과 “동작함” 사이 간격이 좁아서 특히 좋고, Rust에서도 좋은 테스트 스위트와 변이 테스트를 붙이면 비슷한 느낌을 받음
    이 도구들의 긴 꼬리는 “버튼 누르면 제품 나옴”이 아니라, 좋은 엔지니어가 이를 받아들여 중요한 일에 에너지를 집중하고, 예전의 잡일 상당 부분을 기계에 위임하는 쪽이라고 봄

    • 나도 처음에는 LLM을 매우 부정적으로 봤지만, 이제는 방해보다 도움이 되는 수준까지 좋아졌다고 생각함
      예시가 흥미로운데, 예전에 JavaScript 프레임워크 팀에서 일할 때 업그레이드나 마이그레이션 같은 일을 위해 직접 코드모드를 작성했음. AST를 고치는 고된 작업이었음
      요즘이라면 LLM에게 맡겨서 90%쯤은 도달할 수 있을 것 같음

  • 이런 관점이 좋음. 도구가 유연하고 꼭 저품질 결과물을 만들 필요는 없다는 건 당연해 보이지만, 찬성하는 쪽과 거부하는 쪽 모두 이 관점을 자주 무시함
    아직 LLM으로 코드 리뷰를 해보진 않았지만 할 일 목록에 넣어봐야겠음. 지금까지는 아이디어 생성, SQL이나 VimScript 도움 정도로 쓰고 코드는 직접 작성함
    한 가지 위험은 코드 리뷰도 기술이라서 모델에 너무 기대면 그 능력이 퇴화할 수 있다는 점임. 다만 상업 환경에서 최고의 코드 리뷰조차 보통 “적당한 시간”과 “이 사람을 신뢰하는가”의 조합이지, 수학적 정확성에 가까운 건 아님

    • 그 말도 맞지만, 이 작업 흐름은 오히려 내 코드 리뷰 능력을 늘려준다고 느꼈음. “버그”가 실제로 가능한지 아니면 이론적인지만 따져야 하고, 고칠 가치가 있는지, 다음 PR로 넘겨야 하는지도 판단해야 하기 때문임
      복잡한 버그는 직접 끝까지 생각해보는 편인데, 1) 환각이 아직 섞여 들어오고, 2) 어차피 시스템을 종단 간으로 이해할 가치가 있기 때문임

  • 메타 얘기지만 이 글에 붙은 플래그가 이해가 안 됨. 주제 벗어남 1개, 스팸 3개라니 이상함
    첫 페이지 최상단 글도 LLM 사용에 관한 글이고, 일반 글쓰기에 대한 글이라 코딩에 초점을 둔 이 글보다 오히려 주제성이 약해 보이는데 플래그가 없는 듯함

    • 아마 자기 홍보로 보고 스팸 플래그가 붙는 것 같음

  • Lobsters에서 이런 관점을 보니 신선함. 일괄적인 반AI 정서는 점점 피곤해짐. 저품질 결과물을 좋아하는 사람은 없다는 데는 모두 동의할 수 있을 것임
    하지만 AI를 완전히 보이콧하고 독선적인 태도를 택한 사람들은, 더 실용적인 태도를 택한 사람들보다 미래를 받아들이기 어려울 것임
    처음부터 AI는 전동 공구의 발명과 비슷하다고 말해왔음. 손 렌치로 타이어를 갈고 싶다면 괜찮지만, 임팩트 드릴이 나왔을 때 정비공들이 보이콧하진 않았음. 글 맥락상 최고의 비유는 아니지만 여전히 그렇다고 봄
    문서를 읽을 때보다 AI를 쓰며 더 많이 배웠음. 문서에는 추가 맥락, 설명, 예시가 필요할 때 질문할 수 없기 때문임. “뭔가 만들어, 실수하지 마”라고 할 수도 있지만, 실제로 배우기 위해 느린 접근을 선호함

    • 여기서 일괄적인 반AI 정서는 못 봤음. 예시를 링크해줄 수 있음?
      내가 본 건 LLM으로 수백만 줄 코드를 한 번에 바꾸고, 인간 리뷰 없이 배포하는 변화에 대한 비판이었음. 구체적으로는 Bun의 Zig에서 Rust로의 포팅 스레드 같은 경우임
      이 글도 그건 비판하고 있음
답변달기