▲

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

 (nolanlawson.com)
40P by GN⁺ | ★ favorite | 댓글 2개
  • 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⁺   [-]
Hacker News 의견들

  • AI로 작업하다 보니 이제 단순한 한 번의 과정이 아니라 긴 왕복 리뷰 루프가 됨
    중간 규모의 여러 영역에 걸친 기능은 먼저 AI로 구현 설계를 잡고 세부사항을 검토한 뒤, 느리지만 결과가 좋은 Claude 4.7 Max로 구현함
    이후 구현을 검토하고 Codex GPT 5.5 xhigh fast로 다시 리뷰시키면 거의 항상 경계 조건을 찾아냄. 수정은 Claude가 하게 하는데, Codex는 버그 찾기와 리뷰에는 강하지만 코드가 과설계되거나 지름길이 섞이는 반면 Claude는 더 직관적이고 유지보수 가능한 코드를 잘 씀
    그다음 새 Claude/Codex 인스턴스로 staged 변경사항을 재검토시키고 피드백을 반영한 뒤 테스트까지 씌움. 수동으로 짜는 것보다 여전히 빠르지만, 대부분의 시간은 리뷰와 경계 조건 처리에 쓰게 되고 결과적으로 v1 기능이 이미 여러 번 반복된 v3 같은 구현처럼 느껴짐

    • 구현 전에 AI와 문제를 질릴 만큼 논의하는 구간이 잘 맞음
      생산적인 느낌이 들고 AI 결과도 좋으며, 코드도 대체로 이해한 채로 남음. 하루 종일 로봇과 설계와 아키텍처를 두고 논쟁하다 보니, 이 부분이야말로 AI 혁명이 나를 더 나은 엔지니어로 만든 지점이라고 느낌
    • 정확히 그렇다고 봄. 너무 많은 사람이 AI에게 복잡한 작업을 한 번에 처리시키고는, 급하게 시킨 주니어처럼 행동한다고 놀람
      내 방식은 연구/계획/테스트 계획을 5라운드 돌리고, 중요한 결정마다 내가 루프에 들어감. 큰 형태에서 시작해 세부로 내려가며, 계획만 내 시간으로 2~3일 걸릴 수 있고 구현 에이전트(Opus 4.7)는 여러 시간 걸림
      구현은 여러 단계/커밋으로 나뉘고 각 단계마다 코드 리뷰 수정 루프가 있음. 마지막 깊은 코드 리뷰도 1~2시간 걸릴 수 있으며, PR을 열면 Gemini가 리뷰하고 그 내용을 읽어 해결함
      프로젝트는 여전히 며칠이나 몇 주 걸리지만, 전부 혼자 하는 것보다는 5배 빠름
      추가: 그 skill은 https://github.com/scosman/vibe-crafting에 있음
    • AI로 코딩할 때 내 흐름도 꽤 비슷하지만, 잘해도 직접 짜는 것과 시간이 비슷하게 걸리는 경우가 많음
      어떤 경우에는 AI가 만든 걸 버리고 그냥 직접 했음. 이건 사람들이 배워야 할 기술이라고 봄. 어느 지점에서는 손절할 줄 알아야 함. 특히 단순한 변경에서 동료들이 LLM과 계속 말싸움하며 뭔가를 시키려는 걸 본 적이 있음
    • 비슷한 접근이지만, 다른 시스템과 일관되게 맞추고 읽기도 쉽게 하려고 기본적인 수동 아키텍처/상위 계약/스텁 설정까지 먼저 해둠
    • 그러다 Anthropic에 장애가 나면 그냥 커피 마시며 기다리나?
      AI들을 계속 돌봐가며 조금 빨라지는 대신, AI가 뭘 했는지에 대한 지식과 통제력은 줄어드는 것 아닌가

  • LLM들이 서로의 코드 리뷰를 비평하게 한 글[1], magpie 도구[2], Cloudflare의 최근 코드 리뷰 스택 글[3]은 꽤 설득력 있음
    나는 AI에 회의적이지만 “작동하느냐”보다 “세상에 좋은가” 쪽이 이유임. 이런 리뷰 작업은 드물게도 사고를 외주화하거나 노동자의 역량을 떨어뜨리지 않는 사례처럼 느껴짐. AI가 코드를 쓰게 하거나, AI가 찾아낸 문제를 AI가 고치게 하는 것과는 같은 경보가 울리지 않음. 물론 환경 문제와 다른 윤리적 우려는 여전히 크게 남아 있음
    최근 AI 코드 리뷰 품질에는 인상받았지만, GitHub PR에서 AI 리뷰어 3개와 따로 상호작용하는 경험은 끔찍함. 더 로컬 지향이고 jj/rebase를 이해하는 리뷰 라운드가 있으면 좋겠음
    맥락: 꽤 큰 PHP/Laravel 백엔드와 Vue 프런트엔드
    [1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
    [2]: https://github.com/liliu-z/magpie
    [3]: https://blog.cloudflare.com/ai-code-review/

  • LLM 리뷰/수정 루프에 쓰는 시간이 평균적으로는 직접 손으로 코드를 쓰는 것보다 더 오래 걸림
    내가 흐름을 타면 아주 빠르게 코드를 쓰고, 때로는 생각보다 코드가 더 빨리 쏟아지기 때문이기도 함. 또 LLM이 처음 몇 번 내놓는 코드는 대체로 정말 별로임
    그래도 흥미로운 건, 직접 검토하고 여러 번 리뷰와 수정을 지시하면 평균적으로 내가 같은 시간에 썼을 코드보다 품질이 더 높아지는 결과가 나온다는 점임. 남의 코드가 여러 번 반복되는 걸 보면, 몰입 상태에서 튀어나온 결과물보다 내가 달성하려는 목표를 더 전체적으로 이해하게 되는 것 같음

    • AI가 나쁜 코드를 쓴다면 AI를 바꿔야 함. 현재 고급 AI라면 나쁜 코드를 만들면 안 됨

  • 이 글은 AI로 코드를 작성하는 이야기가 아니라 코드 리뷰만 다룸
    에이전트형 코딩에서 내가 겪는 문제는 프로그래밍하면서 수많은 미시적 아키텍처 결정을 내린다는 점임. 처음부터 완전한 명세가 있는 경우는 거의 없고, 쓰는 것을 보며 명세를 만들어 감
    Claude Code나 Codex를 쓰면 그 과정이 사라짐. Claude Code는 목표 지점에 도달하려는 의욕이 너무 강해서, 함께 코딩하는 경험이 열병 같은 꿈처럼 느껴짐. 결국 경계 조건이나 프로젝트의 아키텍처/설계 목표에 얼마나 맞는지 자신이 낮아짐
    게다가 나는 프로그래밍, 리버스 엔지니어링 등을 즐김. LLM이 어떤 문제를 풀거나 기능을 전달할 수는 있어도 그 재미를 빼앗는 느낌임. 자신 있게 쓸 수 있는 흐름을 찾으려고 노력 중이지만, 결국 그 흐름은 채팅, 검색, 그리고 내 생각의 러버덕 역할 정도일까 봐 걱정됨

  • 반대로 어떤 회사들은 엔지니어가 사람 피드백을 루프에 넣은 자가 평가 에이전트 파이프라인을 견고하게 만들어, 에이전트가 프로덕션 코드 대부분을 쓰게 해야 한다고 밀고 있음
    Creao의 CEO는 올해 1월에 전체 프로덕션 시스템을 2주 만에 재아키텍처링했다고 말함. 에이전트들이 너무 많은 기능을 너무 빠르게 구현해서 사업 개발 쪽이 따라오기를 기다려야 했다고도 주장함
    AI로 산출을 100배 늘리는 선택지와, AI로 자신의 기량을 발전시키는 선택지를 어떻게 평가할 수 있을지 궁금함
    한편 AI의 생산성 향상은 실제임. 예를 들어 Snowflake의 한 엔지니어링 조직은 회사 역사상 처음으로 1분기에 모든 OKR을 조기 달성했음. 보통 계획된 OKR의 70%를 달성해도 성과로 여겨졌는데, 이런 결과를 본 엔지니어들이 느낄 스트레스가 상상됨

  • 이 글 제목은 더 깊이가 있을 것처럼 보였고 실제 코드 예제를 기대했음
    하지만 다른 의견 글과 비슷함. 글쓴이에게 통하는 프롬프트, 즉 AI에게 버그를 찾으라고 시키는 방식을 제안하고 모두에게 그렇게 하라고 권하는 수준임
    업무와 개인 사이드 프로젝트에서 이런 도구를 쓰고 있어서 보고 배우길 기대했지만, 예제 없는 의견 글은 이제 너무 많음

    • 제안한 흐름을 직접 시도해봤는지 궁금함. 나는 유용한 흐름이라고 보고, 이미 비슷한 흐름을 찾지 못했다면 이런 포인터를 고맙게 여겼을 것임
      글쓴이가 이를 위한 코드 하네스를 만들거나 빠르게 엮어낼 수도 있겠지만, 지금 그런 도구화는 실무자인 당신 쪽 영역에 가까워 보임. 자동화해서 실험하고 싶다면 원하는 것을 직접 명세하는 편이, 그의 코드를 다루는 것보다 솔직히 더 빠를 가능성이 큼

  • 이걸 읽는 동안 꽤 빽빽한 기능을 작업 중인데, 상당한 반복이 필요했음
    최종 결과는 중간쯤에 있던 코드보다 오히려 훨씬 적은 코드가 됨. 그래서 AI가 실제로 도움이 됐는지 의문이 들었음. 반복에 들인 시간만큼이면 직접 코드를 쓸 수도 있었을 테니까
    하지만 AI 덕분에 마음에 들지 않는 기능 변형 4개를 빠르게 대충 만들어볼 수 있었고, 그만큼 빠르게 버리는 것도 부담이 없었음

    • AI를 쓰며 얻은 가장 큰 개선 중 하나가 바로 이 점임
      예전에는 새 기능 구현에 들어가기 전에 계획을 정말 많이 고민해야 했고, 기존 코드와의 부조화는 구현을 꽤 많이 쓴 뒤에야 발견하곤 했음. 이제는 AI에게 상세 구현 계획을 요청해서 이런 자잘한 세부 문제를 몇 시간, 아니면 그보다 더 짧은 시간 안에 찾을 수 있음
    • 그래서 결론은? 할 만했나?

  • 지난 몇 년 동안 흥미로웠던 건 내 코딩 게으름의 경계를 추적하는 일이었음
    코더로서 나는 보일러플레이트 코드를 싫어함. 쓰기도 싫고 유지보수도 싫음. 그래서 그런 선호를 중심으로 설계와 아키텍처를 잡곤 했고, 때로는 현명했지만 때로는 아니었음. 어쨌든 내 선호였고, 내가 하기 어려운 일을 피했음
    몇 년 전 LLM이 코딩에 어느 정도 쓸모 있어지기 시작했을 때, 사실상 보일러플레이트에는 아주 뛰어나고 2023년 무렵에는 거의 그것만 잘한다는 걸 알게 됨. 그러면서 설계와 시스템 아키텍처에서 우리가 함께 일하는 사람들의 강점과 약점을 암묵적으로 이해하고 얼마나 많은 배려를 해왔는지 생각하게 됨
    최신 모델은 인간과 비교해 매우 다른 강점과 약점을 갖고 있고, 이를 배치하는 일은 다른 종류의 아키텍처와 엔지니어링 기술을 요구하는 흥미로운 훈련임. 즐겁게 하고 있고 계속 그랬으면 함

    • 보일러플레이트는 좋은 라이브러리나 프레임워크가 있으면 선택 사항이 되거나 자동으로 작성됨
      LLM에 프롬프트를 던져 무엇이 나올지 모르는 것보다 django-admin startproject, npm init, meteor create로 결정적 출력을 얻는 편이 훨씬 좋음
      성숙한 웹 생태계에서는 보일러플레이트가 최소화됨. 이제 이 작업을 LLM에 넘겼으니, startproject류 CLI와 좋은 기본값을 만드는 개발 노력이 줄어들까 걱정됨

  • 마음에 듦. 나도 비슷한 ralph-loop 접근을 씀
    승인된 계획에서 시작해 코디네이터에게 넘기고, 단순화하면 빌드와 리뷰라는 2개 세션에 걸쳐 처리하며 각 세션에는 별도 모델을 붙임

  • 코딩 에이전트를 쓰는 데 나에게 걸림돌은 유료 외부 서비스에 의존해야 한다는 점임
    코딩에 쓸 만큼 괜찮은 로컬 모델이 있나?

    • 이번 달 기준으로는 Qwen3.6(27B 또는 35B-A3B)이나 Gemma 4가 자주 거론됨
      이것도 도움이 될 수 있음: https://hnup.date/hn-sota
      Qwen 모델은 이번 주 내 일상용 모델임
답변달기
▲
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로의 포팅 스레드 같은 경우임
      이 글도 그건 비판하고 있음
답변달기