Fable을 이기는 ‘짧은 목줄’ AI 코딩 방법

 (blog.okturtles.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 보안 중요 소프트웨어에서 AI 코딩 에이전트를 쓰려면 자율 실행을 맡기기보다, 개발자가 변경을 계속 통제하는 Short Leash 방식이 필요함
  • 여러 에이전트가 병렬로 코드를 만들고 검토하는 “vibe”식 접근은 코드베이스 이해를 약화시키고, AI가 off the rails 상태가 된 뒤에야 문제를 발견하게 만들 수 있음
  • 핵심 절차는 계획 수립, 단계 분해, 권한 프롬프트의 diff 검토, 잦은 거부와 개입, 하위 작업별 커밋, 마지막 리뷰로 이어짐
  • PR 리뷰에서는 AI와 인간을 함께 써야 실수를 줄일 수 있으며, AI는 흔한 오류를 빠르게 잡고 인간은 더 높은 수준의 문제와 방향을 판단함
  • AI가 작성에 관여한 PR은 제출자가 한 줄씩 직접 검토하고, PR 설명에 사용한 모델을 AI Disclosure로 명시해야 신뢰를 얻을 수 있음

AI 코딩 에이전트를 쓰기 위한 전제

  • 이 방법은 보안 중요 시스템에서 고품질 소프트웨어를 만들기 위한 AI 에이전트 사용 경험을 바탕으로 함
  • 대상은 AI를 학습의 적으로 봐야 하는 초보 개발자가 아니라, 자신의 전문 영역에서 “frontier AI models”보다 뛰어난 전문 개발자임
  • 목표는 AI를 성능 향상 도구로 쓰면서도 소프트웨어 품질을 희생하지 않는 것임
  • 경험의 범위에는 AI 에이전트 한계 탐색, 자체 AI 리뷰 도구 제작, AI 코딩 에이전트 Crush의 커스텀 포크 유지가 포함됨

“vibe”식 접근이 흔들리는 지점

  • AI 에이전트를 쓰는 세션에서는 두 가지 문제가 자주 생길 수 있음
    • 처음 아이디어가 나쁘고 더 나은 접근이 있다는 사실을 뒤늦게 발견함
    • 에이전트가 원하지 않는 방향으로 off the rails 상태가 됨
  • 여러 병렬 에이전트와 오케스트레이터가 동시에 작업하고 개발자가 코딩 과정에서 빠지면, 코드베이스 이해를 직접 쌓기 어려워짐
  • 품질을 신경 쓰지 않는 상황에서는 이런 방식도 괜찮을 수 있지만, 품질이 중요한 경우에는 다른 접근이 필요함
  • Fable 5가 작성하거나 검토한 코드는 동작하더라도 비효율적이고 보기 나쁠 수 있음
  • 모델이 의존할 훈련 데이터가 적은 니치 영역에서는 이런 문제가 더 자주 생길 수 있음
  • 특정 CEO들의 마케팅과 달리, 이 관점에서는 모델이 훈련 데이터 너머로 사고할 수 없음

Short Leash 방식의 작동 방식

  • Short Leash 방식은 아무나 쓸 수 있는 방법이 아니며, 전문 소프트웨어 개발자에게 맞춰져 있음
  • frontier model을 쓰지 않아도 Fable을 이기는 결과를 낼 수 있다는 점이 장점임
  • 작업 전에는 계획 단계에서 과제를 조사하고 계획을 세움
    • 큰 작업은 tasks skill 같은 도구로 진행 상황을 추적하고 단계로 나눔
    • 이 부분은 여러 “vibe engineering” 방식과 공통점이 있음
  • 이후의 핵심은 AI를 계속 짧은 목줄에 묶어두는 것임
    • “YOLO” 모드 또는 “dangerously skip permissions”를 쓰지 않음
    • 사용자가 게임을 하는 동안 AI가 혼자 일하게 두지 않음
    • 권한 프롬프트에서 적용 예정 변경의 diff를 보여주는 코딩 에이전트를 사용함
    • 개발자가 AI가 제안하는 변경을 실제로 분석함
    • 권한 프롬프트의 diff로 코드베이스 이해를 최신 상태로 유지하고 AI를 통제함
    • AI가 원치 않는 작업을 하려 하면 권한을 거부함
    • 필요할 때 자주 개입해 AI가 방향을 잃지 않게 함
  • 하위 작업이 끝날 때마다 커밋을 만들어, AI가 이전 작업을 망치거나 삭제하는 상황을 막음
    • 이런 일이 실제로 발생할 수 있으며, Opus에서 본 사례가 있음
  • 마지막 단계에는 리뷰를 수행함

AI 리뷰는 인간 리뷰를 대체하지 않음

  • 인간만 리뷰하거나 AI만 리뷰한 PR보다, 인간과 AI가 함께 리뷰한 PR이 실수를 더 줄일 수 있음
  • AI는 린터처럼 다룰 수 있음
    • 흔한 실수를 빠르게 잡음
    • 인간은 더 높은 수준의 문제와 방향 변경 필요성을 판단함
  • 모든 PR은 AI 리뷰를 거치는 것이 권장됨
  • AI 리뷰에는 충분한 문맥이 필요함
    • 이슈
    • PR 설명
    • 코드베이스
    • 변경 사항
  • 리뷰에는 사용 가능한 최신 모델을 쓰는 것이 권장됨

AI Disclosure와 제출자 책임

  • PR 작성에 AI가 쓰였다면 PR 설명의 AI Disclosure 섹션에 사용한 정확한 모델을 공개해야 함
  • 이 공개에는 여러 목적이 있음
    • 유지관리자에게 AI 사용 사실을 알림
    • 약한 모델을 썼다면 더 나은 모델을 제안할 수 있게 함
    • AI를 몰래 들여오려는 것이 아니라는 신호를 줌
  • AI를 사용한 PR은 반드시 PR “작성자”가 직접 리뷰해야 함
  • AI 보조 PR은 실제로는 인간 도움을 받은 AI의 PR에 가깝기 때문에, 제출자는 자신이 제출하는 내용을 이해해야 함
  • 제출자는 자신의 PR을 다른 사람의 PR처럼 보고 line-by-line으로 직접 리뷰해야 함
  • 자체 리뷰가 끝난 뒤에는 자신의 승인을 확인하고 유지관리자에게 검토를 요청할 수 있음
  • 이 과정은 제출자가 코드베이스를 이해하고 있음을 만들고 보여주는 역할을 함

okTurtles의 적용 방식

  • okTurtles는 이 방식으로 AI를 사용함
  • 공식 정책은 AI Usage Policy에 정리되어 있음
  • 글 자체는 인간이 작성했고, 게시 전 AI 스타일의 맞춤법 검사만 수행했다는 AI Disclosure가 포함됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 “짧은 목줄” 방식은 보조 도구라기보다 목발처럼 보이고, 처음부터 AI에 문제를 충분히 설명하지 않았거나 출력물을 검토·반복하지 않았다는 신호 같음
    Fable 같은 강한 모델을 구현 단계에서 손잡고 끌고 가는 건 시간 낭비이자 Fable 낭비임. 강한 모델일수록 더 미묘한 설계 논의가 가능하고 예전보다 훨씬 나은 코드를 씀. 설계와 구현을 논의하고, 이상해 보이는 부분을 질문하고, AI 답변을 실제로 읽는 과정 자체가 더 나은 해법을 찾는 데 도움 됨
    예전에 탐욕 알고리즘 풀이를 만들려다 Opus와 논의하는 과정에서 기존 MILP 라이브러리로 문제를 정확히 풀 수 있다는 제안을 받았고, MILP를 들어본 적도 없었지만 최종 구현은 혼자 했을 때보다 더 낫고 단순해졌음

    • 강한 모델과 더 미묘한 논의가 가능하다고 하지만, Claude에게 이해 안 되는 작은 변경을 왜 했냐고 물었더니 코드 경로를 바탕으로 “제1원리부터 추론했다”고 답했음
      그런데 동작하지 않았고, 그 제1원리 추론 단계를 설명해보라고 하자 실제로는 그냥 지어냈다고 답함. 그래서 모델과의 미묘한 논의라는 말은 믿기 어렵다
    • 대체로 동의함
      계획 단계에 충분히 투자했고 프로젝트의 기존 아키텍처와 관례가 탄탄하다면, 여기서 말하는 것만큼 구현 단계에 많은 감독이 필요하지 않을 수 있음
      “초기 아이디어가 멍청했고 더 나은 방법이 있음을 발견할 수 있다”는 건 보통 계획과 아키텍처 단계에서 고수준으로 발견함
      에이전트가 원치 않는 방향으로 “탈선”하는 문제도 예전만큼 나쁘지 않고, 영향 있는 변경에는 최소한의 테스트 커버리지가 있어야 함. 그 테스트가 단지 구현된 동작을 “고정”하는 수준이어도 됨. 마지막 검토 논의는 리뷰나 적대적 리뷰 에이전트가 찾은 것 이상을 확인할 좋은 기회임
    • 정확히 어느 부분에 반대하는지 조금 헷갈림. AI 응답을 읽고 코드를 검토하는 건 결국 같은 방식으로 보임
      MILP 예시는 이 접근법이 막을 일이 아니고, 계획 단계에서 드러났을 것임
      결국 세부가 중요하고, 작업 시작 프롬프트를 어떻게 주느냐가 영향을 줌. 그래도 출력 확인, 모델이 하는 일에 관여, 왜 그렇게 만들려는지 캐묻는 과정은 반드시 필요함
    • 글이 AI를 마이크로매니징하는 느낌임. 주니어 직원처럼 생각하면, 마이크로매니징을 통해 원하는 일을 원하는 방식대로 하게 만들 수는 있음
      하지만 그 직원의 아이디어는 테이블에 올라오지 않고, 장기적으로 팀 전체에 이로울 수 있는 기여도 사라짐
    • 이 방식으로 쓰고 있음
      생성되는 모든 것을 이해하고 코드베이스에 대한 작업 지식을 계속 유지할 수 있게 해줌. 방향 전환도 쉽게 시킬 수 있음

  • 사이드 프로젝트에서 2주 동안 이렇게 했지만 결국 코드베이스에 대한 정신 모델이 없는 상태가 됐음
    직접 만들지 않고는 그 모델을 만들 방법이 없다고 더 확신하게 됨

    • 안타깝게도 AI 이전에도 같은 문제를 겪었음
      망각 곡선 때문에 내 정신 모델은 처음 만들던 기간보다 그리 오래 지속되지 않음. 어떻게 다시 구축할지는 아직 알아내지 못함
    • 큰 프로젝트의 매니저라면 어떻게 모델을 만들까? 직무상 프로젝트 전체를 파악해야 하지만 실제로 코드를 많이 쓰거나 리뷰할 필요는 없는 상황에서 말임
    • 모델에게 코드 설명을 요청하면 됨
    • 잘 모르겠음. 가능은 하다고 보지만, 이해하지 못한 부분을 의도적으로 파고들어야 하고 그게 지침
      다만 직접 작성했을 때처럼 “내가 직접 만들 수 있는 능력”은 잘 쌓이지 않는다는 데는 동의함
      예를 들어 어떤 효과를 얻으려면 어떤 변경을 해야 하는지 알고, 실제로 변경하면 기대한 결과가 나오기 때문에 내 정신 모델이 작동한다는 건 앎. 하지만 비슷한 것을 처음부터 직접 만들라면 못 만들 것 같음. 접근법이 내 손이 닿지 않는 곳에 있는 느낌인데, 설명하기 어렵다
    • 코드 리뷰는 나에게 잘 맞음

  • 실제로 코딩할 줄 아는 사람은 중요한 일에 AI를 쓸 때 다 이렇게 쓰는 줄 알았음
    내가 틀렸나? 요즘 다들 그냥 YOLO 모드로 돌리는 건가?

    • 맞음. 신경 안 쓰는 노트북 하나를 준비해 Claude가 WSL 안에서 마음대로 만지게 해둠
      funemployment의 재미임. 다시 일을 시작하면 꽤 흥미로운 변화가 될 듯함
      지금은 실행시켜 두고, 맥주 마시면서 한 시간쯤 큰 방향의 비평과 자기점검/폐쇄 루프 피드백을 새로 세팅한 뒤, 다시 마음대로 돌리게 하는 식이라 단순함
    • “YOLO 모드”, 즉 “위험하게 권한 건너뛰기”를 쓰지 말라는 게 이걸 말하는 건가?
      Claude를 bypass-permissions 말고 다른 방식으로 어떻게 쓰는지 궁금함. Claude가 쓸 수 있는 도구 목록을 오래 관리해봤지만, 결국 돌아와 보면 한 도구의 출력을 다른 도구로 파이프하려 했고 명시적으로 허용되지 않았다며 멈춰 있는 일이 반복됐음. 그냥 grep 같은 일이었는데도 멈추니 짜증났음
      bypass-permissions에서는 “그냥 동작”함. 물론 기존 코드 분석과 변경 제안에만 쓰고, 뭔가 깨져도 그건 버전 관리가 있는 이유라고 봄

  • 대체로 글쓴이에 동의함. 무엇보다 LLM이 하거나 말하는 어떤 것도 믿지 말라를 덧붙이고 싶음
    오늘 Claude에게 3개 컴포넌트의 동작을 통일하라고 했고, 5번이나 시켰음. 매번 끝에 가면 여전히 맞지 않는 부분이 있었고 Claude는 그걸 합리화할 방법을 찾아냈음
    물어보면 “제 책임입니다”라거나 “의도적인 선택이라고 생각했습니다”라고 답했지만, 먼저 무엇을 해야 할지 질문하거나 문제를 말한 적은 한 번도 없었음. 그러니 짧은 목줄을 잡고, 생각 과정을 보고, 헛짓을 바로잡아야 함. 오늘 Sonnet 5 기준이고, 내일은 더 나아질 수도 나빠질 수도 있음. 오늘 Claude에게 통하는 말투가 내일은 다른 결과를 줄 수 있음

  • “AI로 X 하는 법”류의 글에서 문제는 상황마다 전부 다르다는 것임. 예를 들어 Symfony 프로젝트를 3.1에서 8.1로 올리는 작업은 경로가 명확함
    메이저 버전마다 작성된 마이그레이션 가이드를 따르고, 모든 라우트와 인증 흐름 등을 테스트하면 됨. 이 테스트도 직접 선별할 수 있고 어떤 것은 200, 어떤 것은 302를 반환할 수 있음
    선택적으로 안전망을 먼저 작성해서 수동 테스트를 줄이고, 예를 들어 PHPStan 기준선 등을 둘 수도 있음
    라우트가 종단 간 기능적으로 의도대로 동작하면 끝임. 여기에는 스냅샷 테스트도 쓸 수 있음
    이런 경우 AI를 지켜볼 필요가 없음. 마지막에 코드를 리뷰할 수는 있지만, 중간중간 수동 승인할 필요는 없어서 안전 기능은 꺼둠

    • “AI로 X 하는 법”의 문제라기보다 인터넷 콘텐츠를 받아들이는 방식에 가까움
      대부분은 하나의 관점에서 글을 쓰지만 실제 관점은 넓고, 한 상황에서 통하는 것이 다른 상황에는 통하지 않음. 소프트웨어 엔지니어링 전체가 결국 무엇을 어디에, 언제 적용할지 파악하고 나머지는 무시하려는 일에 가까움
      많은 회사 블로그 글은 모든 경우에 통하는 은탄환이 있는 것처럼 믿게 만들지만 보통 사실이 아님
      결국 늘 소프트웨어 엔지니어링에서 다뤄온 것처럼 “어떤 것은 어떤 상황에서 통한다”에 가깝고, 옳고 그름보다 상황별 실제 적용이 다를 뿐이며 정상임
    • rector는 써봤나?

  • AI는 주니어에서 중급 엔지니어 정도임. 그렇게 대하면 이 모든 편집증 없이도 바이브 코딩과 엄격한 엔지니어링의 장점을 모두 얻을 수 있음
    처음부터 격리된 VM에서 Claude를 YOLO 모드로 돌렸음. 엔지니어에게 자기 노트북을 주는 것과 같음. Claude가 기능을 PR 가능한 지점까지 만들고, 나는 다른 엔지니어처럼 diff를 리뷰한 뒤 적절한 모양으로 다듬고 넘어감
    미숙한 엔지니어도 같은 실수를 함. rm -rf도 본 적 있음, 루트에서 한 건 아니었지만. 모든 권한을 거부한 채 누군가를 마이크로매니징했다면 미쳐버렸을 것 같음

    • 이 관점에 강하게 동의하고, 그래서 이 글이 더 이해가 안 됨. PR이 이미 관문 아닌가? 작업 공간 안에서 에이전트가 뭘 하든 말든, 기여가 git 저장소로 게이트되고 개발에 이상한 프로덕션 접근이 필요하지 않다면 신경 쓰지 않음
      주니어/중급 엔지니어 비유에도 동의하지만 큰 단서가 있음. AI는 배우는 법을 모르는 주니어 엔지니어 같음
      Memento의 주인공과 일하는 것 같음. 매일 LLM이 출근하면 지금까지의 작업에서 아무것도 배운 게 없고, 매일이 첫날임
      물론 Memento 주인공처럼 작업 공간 곳곳에 포스트잇과 알림을 뿌려 도와줄 수는 있음. 노력하면 “학습”이라는 것에 가까워질 수 있는데, 이건 팀의 모든 소프트웨어 개발자에게 말 그대로 가장 중요한 특성임
      하지만 쉽지 않고 도구도 아직 부족함. 내가 해본 최선은 Obsidian 같은 도구로 쓰는 “두 번째 뇌”에 가까웠음. 슬프게도 두 번째 뇌는 첫 번째 뇌의 대체물이 아니라고 봄. 솔직히 AI 에이전트처럼 배우고 성장하지 못하는 엔지니어라면, 내가 일해본 회사 어디서든 첫 달 뒤 해고됐을 것임
      그래도 주요 AI 제공사나 누군가가 앞으로 이 부분을 개선할 거라고 꽤 낙관함. 좋은 메모리와, 문맥에 맞춰 기억을 더 잘 주입하는 잘 설계된 사고 시스템이 결합되고, 감독 없이 실제 학습을 포착할 수 있다면 불가능한 과제처럼 보이진 않음
      이런 문제를 이미 누군가 풀었고 내가 뒤늦게 알아차리기만 하면 되는 상황이길 바라며 이런 글을 읽지만, 지금으로서는 에이전트를 설계하는 능력이 처음보다 조금 나아진 정도임
    • 내 경험도 같음. 나는 아주 똑똑하고 빠른 인턴에 더 가깝다고 봄. 크게 될 게 보이고 여러 면에서 이미 나보다 훨씬 낫지만, 여전히 숙련자의 손길로 방향을 잡아줘야 함
      내 경험칙은 AI를 위해 만드는 특수 프로세스가 사람에게도 타당해야 하며, 그렇지 않다면 가치가 없다는 것임. 좋은 명령줄 도구, 긴 명령 출력 자동 요약, Markdown 문서와 워크플로는 사람에게도 유용함
      실수와 남용을 막으려면 마이크로매니징이 아니라 샌드박스와 범위 제한 권한을 써야 함
      알아내고 싶은 건 AI 에이전트와의 좋은 페어 프로그래밍 워크플로임. 고성능 모델에게 큰 작업을 시킬 수 있고 그건 잘 됨. 저수준 모델을 IDE 보조로 쓸 수도 있고 그것도 잘 됨. 하지만 둘은 별도 워크플로임
      정말 유용한 건 고성능 모델과 키보드를 주고받으며 함께 만드는 방식임. 다만 내 머신에서 완전 YOLO 모드로 돌리는 건 아니어야 함. 이 부분이 인간과 LLM의 차이임. 너무 빠르기 때문에 탈선할 때 키보드를 다시 낚아채기가 어려움
    • Claude에게 실제 노트북을 주면 Linux 블루투스 오디오 문제도 고칠 수 있음 ;)
    • 어떤 VM/프로비저닝을 쓰고 있나?
    • “AI는 주니어에서 중급 엔지니어”라는 말은 이제 사실이 아니고, 그렇게 착각해봤자 도움이 안 됨
      AI는 뭔지 정확히 아무도 모르지만 주니어나 중급 엔지니어는 아님. 도메인 맥락이 없고 5시간마다 기억 없이 깨어나는, 판잣집에 사는 원자력 스태프 엔지니어에 가까움

  • LLM은 여전히 다음 토큰 예측기임. 더 모호한 지시를 줘도 올바른 단계를 찾아낸다고 해서 지능이 있다는 뜻은 아님. 네가 모델 훈련에 쓰인 하네스와 같은 언어를 말하고 있다는 뜻임
    그리고 거기에는 한계가 있음. 개념 증명 수준이나 단순 앱에 머물러 있다면 현재 모델이 여전히 얼마나 제한적인지 모를 수 있음. 그런 곳에서는 작업을 쪼개야지, 그럴듯한 단계를 나열하는 토큰 예측기를 믿으면 안 됨
    어딘가에는 반드시 인간 루프가 있어야 함. 권한 건너뛰기를 시작하면 최선은 대박이지만, 더 가능성 높은 건 차선의 해법과 토큰 낭비임. 정말 무서운 건 모델이 지시를 무시하고 멍청한 짓을 해서 하루를 망치는 경우임
    이건 CNC 기계처럼 날카로움. 유용하지 않은 건 아니지만 위험할 수 있음. 평행주차를 못 한다면 괴물 기계로 나무를 깎으려 하거나 비좁은 동네에 Ferrari를 세우려 들지 않는 편이 낫다

    • 다음 토큰 예측은 알고리즘이 아니라 인터페이스임. “다음 토큰을 예측”하는 과정은 임의로 복잡하거나 단순할 수 있고, 주어진 작업을 수행하는 능력도 얼마든지 높거나 낮을 수 있음
      LLM이 “토큰 예측기”라서 뭔가를 할 수 있다거나 할 수 없다고 말하는 건 범주 오류임. 인터페이스가 단단한 한계는 아님
    • “지능이 아니다”에서 지능을 어떻게 정의하는지 모르겠음
      LLM에는 지능이 없다고 미리 정해두는 공리를 쓰지 않으면서, 언어 모델은 제외하고 인간은 포함하는 정의가 어떻게 가능한지 궁금함
    • 그렇다면 너도 그냥 다음 단어를 말하는 사람임
    • LLM을 “다음 토큰 예측기”라고 부르는 건 완전히 환원적이고 불성실함. 기술적으로는 맞지만 너도 마찬가지임
      보통 이 말로 뜻하는 건 “훈련 데이터, 즉 인터넷의 다음 토큰을 예측할 뿐”이라는 의미인데, 원시 모델에 대해서라면 사실일 수 있음. 하지만 모델은 사후 학습을 거치므로 이 설명조차 더는 맞지 않음
      “지능이 아니다”라는 말은 유용하지도 않고, 내 생각엔 틀렸음. 네 지능 정의에 맞는지 누가 신경 쓰나. 여전히 인상적인 일을 해내고 있고, 네가 암시하는 것보다 훨씬 더 대단한 일도 함
    • 어떤 기준을 넘으면 지능적이라고 부를 건가?

  • 원글은 아직 2025년에 머물러 있는 느낌임
    “AI가 여러 번 탈선하고 실제로 소프트웨어를 써볼 때야 알아차릴 것”이라고 하지만, 이제 그 AI가 직접 소프트웨어를 사용해 버그를 찾고 고칠 수 있으며 새 기능도 추진할 수 있음
    에이전트가 원치 않는 일을 시작하는 일은 있지만 예전보다 훨씬 줄었고, 완전 자율 에이전트 쪽 논거는 약해지는 게 아니라 강해지고 있음
    “사람이 코드베이스를 이해하는 건 인간적으로 불가능하다”는 말도 낡아 보임. 이제 인간이 코드베이스를 이해할 필요가 없어지고 AI가 이끌어가는 방향으로 가고 있다고 봄

    • AI 회사들은 이런 무모한 slopmaxxing을 밀어붙일 동기가 있음. 최종 결과는 네 비즈니스가 그들에게 완전히 의존하고, 제품 가치도 전부 그들에게서 나오게 되는 것임
      많은 사람이 여기에 올라타고 있지만, 나는 어리석은 유행이라고 봄
    • 맞음, 무언가를 이해한다는 건 너무 2025년식임
    • 이 말은 엔터테인먼트나 미디어 같은 비핵심 소프트웨어에는 맞을 수 있음
      하지만 보안 리스크가 큰 시스템에는 절대 맞지 않음. 은행, 항공, 국방 같은 분야에서는 AI가 분명 기여하겠지만, 인간 엔지니어링 이해와 독립적으로 움직이진 못함
    • 효과적인 프로그래밍과 아키텍처에 대한 감각이 충분히 좋은 사람이라면, AI가 직접 소프트웨어를 사용해 버그를 찾고 기능을 만든다는 말에 동의하지 않을 것임
      짧은 목줄 방식은 훈련 데이터 밖에서 작업할 때 좋은 결과를 보장하는 방법임. 평균보다 조금만 나은 프로그래머라도 LLM으로 빠르고 품질 좋은 개발을 보장하는 유일한 방법은 이 방식이라고 봄
      인간이 더는 코드베이스를 이해할 필요가 없다는 말은, AI가 아직 처참하게 서툰 프로그래밍 세계를 모르는 데서 나오는 것 같음. 수동 메모리 관리가 있는 언어들에서 메모리 처리를 자주 망치는 걸 꾸준히 봤음. Valgrind 루프에 넣어두면 되는 정도로 단순하지 않음
    • 완전 자율 에이전트 쪽 논거가 강해진다는 건 못 느끼겠음. 몇 주 전 Claude Code + Opus 4.8로 겪은 일임. 작업은 그리 복잡하지 않았고, 새 API 엔드포인트 4개와 클라이언트에서 웹소켓으로 스트리밍되는 이벤트였음
      API 정의, 요청/응답 모델, 데이터베이스 스키마, 전체 흐름을 여러 번 반복하며 다듬었고, 모순 제거와 문서 수정을 많이 직접 했음. Opus는 계속 탈선했고 최종 문서는 500줄이 넘었음
      API 통합 테스트도 다시 오가야 했음. AI가 문서에서 바로 테스트를 만들지 못해, 먼저 Given-When-Then 주석이 있는 자리표시자를 만들고 손으로 검토·수정한 다음, 두 번째 반복에서 테스트를 구현했음. 리뷰 후 수정한 실수가 많았음
      구현 단계에서는 API 문서, 동작하는 테스트, 수정 차단 훅, 6개 이상의 “모범 사례” 스킬, “러버덕”과 “코드 단순화” 에이전트, 테스트·린터·컴파일 오류 확인용 스크립트를 제공했음. 계획, 실행, 리뷰와 여러 번의 수정을 거쳐 기능은 구현됐고 테스트도 모두 통과했음
      코드 리뷰에서는 평균적으로 코드 20줄당 문제 하나를 찾았음. 코드 스타일은 제외하고도 Kubernetes 서비스에서 인메모리 세마포어 사용, 단일 요청 중 같은 레코드를 갱신하려고 DB 호출 8번 수행, 한 번에 한 컬럼씩 갱신, 트랜잭션 없는 읽기-수정-저장, 비즈니스 로직·복구·인가 실수가 있었음
      결과는 거의 한 주 업무 시간, 토큰 비용 100달러 이상, 그리고 “이 노력이 가치 있었나?”라는 생각뿐이었음. 개발자 2명 팀을 두고 있는데, 방금 한 명의 PR을 리뷰했더니 80%가 슬롭이었음

  • 비슷한 접근을 해봤지만 나에게는 잘 맞지 않았음. 속도 향상이 거의 없었거나 없었음. 생산성을 얻으려면 샌드박스 안에서 어느 정도 YOLO 모드가 필요하다고 봄
    목표는 모델에게 가능한 한 많은 일을 외주화하면서, 그 결과를 이해하고 리뷰하는 데 필요한 노력을 최소화하는 것이어야 함
    예를 들어 모델에게 버그 원인 찾기, X의 개념 증명 만들기, 무언가를 점진적으로 최적화하기, 가이드가 있는 잘 정의된 리팩터링 등을 맡기는 식임
    사람들이 루프를 만든다고 말하는 것도 매우 비슷함. 모델이 하는 일을 최대화하고, 그것을 통제하기 위해 내가 해야 하는 일을 최소화하는 것임

  • 글에 별 내용이 없었음

    • 현재 유행하는 문구를 따라 하는 것뿐임
      작년에는 “AI는 확률적 앵무새일 뿐”이었음
      올해는 “AI가 코드를 쓸 수는 있지만, 인간이 여전히 리뷰해야 한다!”임. 물론 그 리뷰에도 AI를 씀
      1년만 더 지나면 서사는 “코드 리뷰는 AI만 할 수 있고, AI의 리뷰를 리뷰할 수 있는 것도 AI뿐이다. 인간은 의미 있는 감독을 유지하기 위해 AI의 최종 의견만 읽으면 된다”가 될 것임
      골대는 계속 움직이지만 확신은 절대 움직이지 않음
답변달기