Rails 코드 품질의 바닥을 높이는 하네스 엔지니어링

URL: https://www.youtube.com/watch?v=xgPyzfDIrPY 날짜: 2026-10-06 채널: Tech Bridge

메타데이터

• 카드 제목: Rails 코드 품질의 바닥을 높이는 하네스 엔지니어링
• 원문 발행일: 2026-10-05
• 발표자: Joël Quenneville
• 핵심 주제: Rails 개발에서 LLM의 생성 결과를 프롬프트가 아니라 테스트, 린터, 훅, 제너레이터, 리뷰 스킬, 도메인 전용 스크립트로 지속적으로 교정하는 방법

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==LLM에게 더 좋은 프롬프트를 주는 데 머물지 말고, 에이전트(Agent)를 반복 실행·검증·교정하는 루프로 이해하여 Rails 코드의 품질 하한선(floor)을 시스템적으로 높여야 한다.==

• 에이전트는 프롬프트를 받아 코드를 한 번 출력하는 블랙박스가 아니라, 환경을 읽고 행동하며 실패에 반응하는 루프다.
• 판단과 품질 기준을 AGENTS.md 같은 프롬프트에 모두 넣기보다 RuboCop, 테스트, 훅, Rails 제너레이터처럼 결정론적 도구로 옮겨야 한다.
• 결정론적 검증만으로 잡기 어려운 문제는 좁은 범위의 LLM 리뷰 스킬과 도메인 전용 스크립트로 보완하고, 실제로 사람이 개입한 고통을 다음 자동화의 재료로 삼아야 한다.

하네스(harness)는 LLM 호출을 감싸는 Ruby 코드이며, 모델 자체가 할 수 없는 파일 읽기·쓰기, 명령 실행, 테스트 확인, 재시도와 종료 판단을 담당한다. 하네스 엔지니어링(harness engineering)은 이 실행 구조를 이용해 첫 생성물이 완벽하지 않아도 시스템이 스스로 실패를 감지하고 수정하도록 만드는 작업이다.

1. 한 시간의 생성과 이틀의 마무리라는 함정

LLM을 이용하면 생성 속도는 극적으로 빨라지지만, 검토와 품질 보정이 자동화되지 않으면 전체 작업 시간의 이득이 사라진다.

1.1. 두 날짜 작업이 한 시간에 끝난 것처럼 보인 순간

1. LLM 코딩을 본격적으로 시작한 계기

   1. Joël Quenneville은 그해 초부터 대부분의 코드를 LLM으로 작성하는 일을 더 진지하게 시도했다.
   2. 약 2일 분량으로 범위가 잡힌 기능을 에이전트와 함께 세부 범위를 좁히고 필요한 내용을 구체화한 뒤 실행시켰다.

2. 초기 결과가 만든 과도한 기대

   1. 약 한 시간이 지나자 작동하는 결과물이 나왔고, 2일짜리 일을 한 시간에 끝낸 것처럼 보였다.
   2. 내부 품질 문제는 있었지만 조금 다듬어 리뷰에 올리면 팀에서 영웅처럼 보일 것이라고 생각했다.

1.2. 품질 보정이 레버리지를 잠식한 과정

1. 첫날의 반복적인 손질

   1. 점심 무렵까지 몇 차례 다듬었고 결과는 나아졌지만 아직 끝나지 않았다.
   2. 반나절을 쓰고도 2일 분량의 절반을 처리한 셈이어서 여전히 좋은 성과처럼 보였다.

2. 저녁과 다음 날의 역전

   1. 저녁에도 여러 차례 리뷰와 정리를 반복했지만 결과는 아직 충분하지 않았다.
   2. 2일짜리 범위의 일을 하루에 끝냈다는 점은 의미 있었지만, 다음 날에는 매시간 손질할수록 처음의 레버리지(leverage)가 줄어드는 시간과의 경쟁이 시작됐다.
   3. 다음 날 저녁이 되어서야 가까스로 마무리했고, 결과적으로 2일짜리 일을 정확히 2일에 수행했다.

3. 실패 원인의 명명

   1. 한 시간은 코드를 만드는 데 썼고, 나머지 이틀은 AI가 만든 slop과 씨름하는 데 썼다.
   2. 첫 한 시간 뒤 바로 PR을 올려 동료에게 품질 부담을 넘기면 자신은 영웅처럼 보일 수 있지만, 팀에 부담을 전가하는 나쁜 선택이다.
   3. 바람직한 목표는 첫 생성물의 품질 하한선을 높여 이틀짜리 결과를 검토하는 시간을 두 날이 아니라 한 시간 정도로 줄이는 것이다.

2. 에이전트를 프롬프트가 아니라 실행 루프로 이해하기

프롬프트를 개선하는 방식에는 한계가 있으며, 테스트와 환경 상호작용을 하네스의 반복 구조에 넣어야 에이전트가 실패에 반응할 수 있다.

2.1. AGENTS.md와 프롬프트 중심 사고의 한계

1. 프롬프트 개선의 유혹

   1. AGENTS.md에 규칙을 많이 넣으면 더 나은 코드가 나올 것처럼 보인다.
   2. 그러나 규칙을 추가하는 일은 결국 매번 프롬프트 앞에 지침을 붙이는 prompt and pray 방식이다.
   3. 규칙을 따를지는 확률적이며, 컨텍스트가 길어질수록 모든 규칙을 지킬 가능성이 낮아진다.

2. FizzBuzz 사례로 드러난 블랙박스 모델

   1. 가장 단순한 방식은 Anthropic API에 “이 명세를 통과하는 코드를 작성하라”고 보내고 Ruby 래퍼(wrapper)로 호출을 감싸는 것이다.
   2. 모델은 15로 나누어지는 경우를 먼저 처리해야 하는데 3으로 나누어지는 조건을 먼저 실행하는 코드를 만들 수 있다.
   3. 그 결과 15 조건은 절대 실행되지 않는 버그가 생긴다.
   4. “더 좋은 프롬프트를 쓰면 된다”는 대응은 prompt in → code out이라는 블랙박스 정신 모델에 머문다.

2.2. 하네스와 에이전틱 루프의 구조

1. 하네스의 역할

   1. 모델만 놓고 보면 텍스트를 넣고 텍스트를 받는 “병 속의 뇌(brain in a jar)”에 가깝고, 스스로 아무것도 실행할 수 없다.
   2. 하네스는 LLM 호출을 감싸는 코드이며 디스크에서 파일을 읽고 파일을 쓸 수 있다.
   3. Ruby로 작성된 하네스에는 모델 호출 주변에 원하는 동작을 추가할 수 있으므로 테스트, 명령, 환경 조회, 종료 조건을 연결할 수 있다.

2. 사람이 손으로 하던 개발 루프의 자동화

   1. 사람은 명세를 받으면 코드를 한 번 추측해 쓰기보다 테스트를 실행하고, 엣지 케이스를 고치고, 다시 테스트를 실행한다.
   2. 모델은 혼자 코드를 실행할 수 없으므로 사람이 결과를 복사해 프롬프트에 넣으면 되지만, 그 방식은 사람을 기계적 배관(human plumbing)으로 만든다.
   3. 하네스에 반복문을 넣으면 테스트 실행과 결과 전달을 사람이 하지 않아도 된다.

3. 에이전틱 루프(agentic loop)의 작동 방식

   1. 입력 프롬프트는 하네스로 들어가고, 하네스는 모델과 여러 차례 대화할지 결정한다.
   2. 하네스는 환경을 조회하고, 환경 안에서 행동하고, 종료 조건에 도달할 때까지 다시 모델을 호출할 수 있다.
   3. 반복문과 테스트가 실패를 신호로 제공하므로 에이전트는 첫 생성물이 완벽하지 않아도 스스로 치유(self-healing)할 수 있다.
   4. FizzBuzz처럼 대체로 맞지만 조건 순서가 틀린 코드도 테스트를 실행하고 두 번째, 세 번째, 네 번째 생성에서 고칠 수 있다.

2.3. 상용 코딩 하네스에 적용하기

1. 상용 도구의 공통 기반
   1. 테스트에 맞춰 만든 반복문과 같은 일반형 구조가 Cursor, Claude Code, Codex 같은 상용 하네스의 핵심에 있다.
   2. Rails 개발자는 “더 좋은 프롬프트”만 찾기보다 이 도구들이 루프라는 사실을 이용해 코드 품질을 유도해야 한다.

3. 결정론적 도구로 Rails 코드의 품질 하한선 높이기

판단과 검증을 프롬프트에 맡기지 않고 실행 가능한 도구로 옮기면 하네스에 포함된 지능이 줄어도 시스템 전체의 일관성과 지능은 높아진다.

3.1. RuboCop과 훅으로 스타일을 강제하기

1. 스타일 가이드를 프롬프트에서 분리하기

   1. 사람이 손으로 지저분한 Ruby를 고치려면 오랫동안 사용해 온 RuboCop 같은 린터(linter)를 이용한다.
   2. RuboCop 결과를 사람이 복사해 프롬프트에 전달하는 방식은 다시 human plumbing을 만든다.
   3. AGENTS.md에는 “Ruby 파일을 변경한 뒤 RuboCop을 실행하라”는 짧은 지시만 두고, 실제 스타일 지식과 판단은 RuboCop이 소유하게 하는 편이 낫다.
   4. 이 방식은 문서에 들어가는 지식의 양을 줄이고 스타일 규칙을 결정론적으로 만든다.

2. 종료 훅(stop hook)의 100%에 가까운 강제

   1. 상용 하네스의 훅(hook)은 특정 생명주기 이벤트가 발생할 때 실행되는 코드다.
   2. Claude가 에이전틱 루프를 끝내려는 stop 이벤트에서 RuboCop을 실행하게 만들 수 있다.
   3. RuboCop이 실패하면 종료를 허용하지 않고 다시 실행하라는 신호를 보내 에이전트가 문제를 고치게 한다.
   4. 훅의 정확한 코드는 하네스마다 계속 바뀌므로 특정 예제보다 “종료 순간에 검증하고 실패하면 루프를 계속한다”는 원리가 중요하다.

3.2. 커스텀 Cop으로 반복되는 Rails 결함 잡기

1. 스타일을 넘어 품질 규칙으로 확장하기

   1. 하네스의 품질 하한선을 단순한 포매팅보다 야심 차게 설정해야 한다.
   2. 여러 품질 문제는 정적 분석기용 Cop으로 표현할 수 있다.

2. 멀티테넌시 버그 사례

   1. 에이전트가 Finder를 적절한 테넌트 범위로 제한하지 않아 멀티테넌트 데이터가 섞이는 버그를 반복해서 만든다고 가정한다.
   2. 이 패턴을 포착하는 커스텀 Cop을 만들면 에이전트가 같은 실수를 만들 때 즉시 잡을 수 있다.
   3. 복잡해 보이는 Cop도 LLM의 도움으로 약 2분 안에 생성할 수 있으며, 예제 Cop은 설정 파일로 검사 대상을 구성하는 일반형으로 만들 수 있다.
   4. LLM의 행동이 불만스러울 때마다 “이 행동을 Cop으로 잡을 수 있는가?”라고 묻고, 가능한 검증은 창의적이고 적극적으로 자동화해야 한다.

3.3. Rails 마이그레이션에는 제너레이터를 사용하기

1. 린터로 해결하기 어려운 파일명 문제

   1. Rails migration은 파일명에 특정 숫자 규칙이 들어가며, 에이전트는 형식을 흉내 내도 그 숫자를 만드는 원리를 제대로 이해하지 못해 자주 틀린다.
   2. 알고리즘과 예시를 AGENTS.md에 길게 적는 방식은 또 다른 prompt and pray다.

2. Rails generator를 정답 경로로 만들기

   1. 사람은 타임스탬프 숫자를 직접 입력하지 않고 Rails generator를 사용하므로 에이전트도 rails generate migration을 사용하게 해야 한다.
   2. AGENTS.md에 항상 generator로 migration을 생성하라는 지시를 넣으면 약 90%의 문제를 해결한다.
   3. 더 높은 보장 수준이 필요하면 새 파일 작성 훅에서 db/migrate 디렉터리에 직접 쓰는 동작을 차단한다.
   4. Ruby 스크립트가 “이 위치에 새 파일을 쓸 수 없다. 대신 generator를 실행하라”는 거부 이유를 함께 전달하면 에이전트의 목표 달성을 막으면서도 올바른 다음 행동을 알려줄 수 있다.
   5. 거부 이유가 없으면 에이전트는 목표를 달성하기 위해 차단을 우회하려고 하지만, 쉬운 경로를 올바른 도구 사용으로 만들어 주면 우회 가능성이 크게 줄어든다.

3. 제너레이터에 조직의 암묵적 패턴 담기

   1. 새 컨트롤러가 기존 코드와 다른 특정 기본 클래스(base class)를 상속해야 한다면 그 규칙을 generator에 넣을 수 있다.
   2. 모든 컨트롤러에 인가(authorization)용 policy object를 함께 생성해야 한다면 generator가 이를 보장할 수 있다.
   3. 전날 Rachel의 발표가 Rails generator의 고급 활용을 깊게 다뤘으며, 녹화가 공개되면 확인할 만한 자료로 언급됐다.

4. 결정론적 도구가 만드는 역설적인 지능 향상

   1. LLM에서 결정론적 도구로 지능과 판단을 옮겼는데도 시스템 전체는 더 똑똑하고 일관되게 동작한다.
   2. Rails generator, RuboCop, 테스트는 에이전트뿐 아니라 사람도 같은 안전한 경로를 사용하게 하므로 개발 경험을 함께 개선한다.

4. LLM 리뷰를 중간 경로의 피드백으로 사용하기

모든 품질 문제를 린터로 표현할 수는 없으므로, 넓은 프롬프트 지침 대신 이미 생성된 구체적인 코드를 좁은 리뷰 스킬로 검사해야 한다.

4.1. 좁은 리뷰 스킬 세 가지

1. 휴리스틱을 AGENTS.md에 넣지 않는 이유

   1. 코드 휴리스틱은 기초 문서보다 AGENTS.md에서 특히 잘 지켜지지 않는 경향이 있다.
   2. 모델에게 가능한 모든 프로그램 중 여러 조건을 만족하는 프로그램을 처음부터 만들라고 하는 일은 너무 어려운 전방 조정(feed-forward) 문제다.

2. Joël이 만든 리뷰 단계

   1. 첫 단계는 구조적 리뷰(structural review)이며, 해결책의 구조가 문제와 잘 대응하는지 폭넓게 본다.
   2. 두 번째 단계는 메서드별 리뷰(method-by-method review)이며, 각 메서드의 동작과 책임을 세밀하게 살핀다.
   3. 세 번째 단계는 마무리(polish)이며, 코드가 읽기 쉽고 문서화되어 있는지 확인한다.
   4. 상용 하네스의 기본 리뷰 기능을 사용하거나 같은 원리의 좁은 커스텀 스킬을 만들 수 있다.

3. 리뷰를 하네스에 자동 연결하기

   1. 모델이 코드를 작성한 뒤 세 리뷰 스킬을 순서대로 호출하면 사람이 직접 복사하고 지시하는 배관 작업이 줄어든다.
   2. 리뷰 스킬은 별도의 sub-agent에서 실행해야 기존 생성 에이전트의 편향을 줄일 수 있다.
   3. 에이전트가 다른 에이전트에게 일을 시키는 순간 오케스트레이션(orchestration)의 영역에 들어간다.
   4. 짧은 스킬 파일로 특정 방식의 sub-agent 호출을 지시하는 간단한 오케스트레이션도 충분히 유용하다.
   5. 더 본격적인 오케스트레이션은 Claude Code의 dynamic workflow, 각 하네스의 내장 기능, 서드파티 도구로 구성할 수 있다.

4.2. “프롬프트와 스킬은 무엇이 다른가?”에 대한 답

1. 출발선 뒤에서 조정하는 프롬프트

   1. AGENTS.md는 가능한 모든 프로그램의 우주에서 여러 조건을 만족하는 하나를 처음부터 뽑도록 모델을 조정한다.
   2. 이는 출발선 뒤에서 전체 경로를 한꺼번에 조종하는 것과 같아 조건이 늘수록 부담이 커진다.

2. 이미 만들어진 코드에서 위반을 찾는 리뷰

   1. 리뷰 스킬은 이미 생성된 구체적인 프로그램을 대상으로 규칙을 역방향으로 적용한다.
   2. 미래에 만들 수 있는 모든 프로그램을 예측하는 것보다 현재 작성된 코드의 위반을 찾는 일이 훨씬 쉽다.
   3. 따라서 리뷰 스킬은 경로의 중간에서 방향을 조정하며, 생성과 검증을 분리한다.

4.3. 에이전트 조정 수단의 2×2 지도

Brigita Bookler가 제시한 정신 모델은 에이전트 조정 수단을 생성 전(feed-forward)과 생성 후(feedback), 계산적·결정론적(computational)과 추론적·LLM 기반(inferential)이라는 두 축으로 나눈다.

1. 네 사분면과 사례

   1. 피드백-결정론적 영역에는 RuboCop이 들어간다. 생성된 코드의 측정 가능한 속성을 검사한다.
   2. 피드포워드-결정론적 영역에는 Rails generator가 들어간다. 올바른 구조를 처음부터 생성한다.
   3. 피드백-추론적 영역에는 에이전틱 리뷰가 들어간다. 생성된 코드에 사람이 가진 품질 이론을 적용한다.
   4. 피드포워드-추론적 영역에는 프롬프트와 AGENTS.md가 들어간다.

2. 각 영역에 배치할 수 있는 Rails 도구

   1. RuboCop 외에 Reek, Flog, Code Climate 같은 폭넓은 코드 품질 휴리스틱과 보안 스캐너를 피드백-결정론적 도구로 활용할 수 있다.
   2. 테스트, 로그 확인, Playwright로 브라우저를 여는 검증도 에이전트가 자신의 작업을 확인하는 피드백 신호가 된다.
   3. generator, setup script, template은 올바른 구조를 앞에서 만드는 결정론적 도구다. 발표자는 template을 특히 좋아하며 별도 대화를 권했다.
   4. 에이전틱 리뷰와 에이전틱 분석은 피드백-추론 영역에 놓인다.
   5. 프롬프트, 정적 문서(static docs), 가까운 위치의 소스 코드는 피드포워드-추론 영역에 놓인다. Kinsey의 발표는 소스 코드를 조정 수단으로 쓰는 방법을 깊게 다룬 사례로 언급됐다.

3. AGENTS.md의 바람직한 크기

   1. 판단을 피드포워드-추론 사분면에 계속 쌓기보다 나머지 세 영역으로 옮기는 편이 좋다.
   2. AGENTS.md는 개발자의 모든 지식을 담은 저장소가 아니라 도구를 호출하는 얇은 라우팅 계층이어야 한다.

5. 과도한 측정과 도메인 전용 스크립트

에이전트를 조정하는 도구는 충분한 자율성을 남겨야 하며, 복잡한 업무에는 도메인의 흐름을 표현하는 스크립트가 모델과 사람 모두에게 공통 언어를 제공한다.

5.1. Goodhart의 법칙과 에이전트의 우회

1. 측정값을 목표로 만들 때 생기는 문제

   1. Goodhart의 법칙은 측정값이 목표가 되는 순간 좋은 측정값으로서의 성격을 잃는다는 명제다.
   2. 사람을 관리하기 위해 발전한 이 법칙은 에이전트에도 적용된다.

2. 느슨한 여유 공간의 필요성

   1. 에이전트를 지나치게 많은 제약으로 묶으면 에이전트는 사용자의 진짜 의도보다 제약을 만족하는 우회책을 찾기 시작한다.
   2. Code Climate 점수의 최대치를 너무 엄격하게 지정하면 점수는 맞추지만 사람이 원하는 품질은 충족하지 않는 코드가 나올 수 있다.
   3. 에이전트에게 약간의 breathing room을 주는 편이 더 좋은 결과를 만든다.

5.2. 5% 자동화율에서 출발한 문서 처리 문제

1. 도메인 작업의 상황

   1. 한 프로젝트는 많은 문서를 가져와 처리하고, 시스템 안의 다른 데이터와 연결한 뒤 내부에 게시해야 했다.
   2. 이 업무의 자동화율은 약 5%에 불과했고 결과도 좋지 않았다.

2. 원시 데이터만 본 LLM의 한계

   1. LLM은 데이터베이스의 한 조각, 문서 일부, 소스 코드 일부를 따로 보면서 전체 그림을 놓쳤다.
   2. 근본 원인을 찾으라는 질문에 명확한 설명을 내놓지 못했고, 여러 번 질문할수록 서로 모순되는 답변을 내놓았다.

5.3. 새는 퍼널(leaky funnel)을 표현하는 스크립트

1. 사람의 정신 모델을 실행 가능한 모델로 바꾸기

   1. 사람은 데이터가 한 단계에서 다음 단계로 이동하다가 여러 이유로 중간 탈락하는 퍼널이라는 정신 모델로 혼란을 정리할 수 있다.
   2. 문서 집단을 파이프라인에서 얼마나 진행했는지, 어느 지점에서 탈락했는지에 따라 분류하는 도메인 전용 스크립트를 작성했다.
   3. LLM에게 원시 테이블과 코드 조각을 직접 보여주는 대신 이 스크립트를 먼저 사용하고 근본 원인을 찾으라고 지시했다.

2. 결과가 개선된 세 가지 이유

   1. 안정적인 정의가 생겨 서로 다른 문서 집단을 비교할 수 있게 됐다. 이전에는 파이프라인을 성공적으로 빠져나갔다는 정의조차 일관되지 않아 에이전트의 설명이 충돌했다.
   2. 모델이 사고할 수 있는 상위 언어가 생겼다. 개별 테이블 컬럼과 소스 코드 한 줄 사이의 패턴을 찾는 대신 bucket, pipeline, exit point 같은 단위로 추론할 수 있게 됐다.
   3. 분류 자체가 유용한 시작점을 제공했다. 비슷한 이유로 실패한 문서 bucket에서 조사를 시작하면 더 깊은 원인 분석으로 들어가기 쉽다.

3. 사람에게도 유용한 도구

   1. 도메인 전용 스크립트는 에이전트뿐 아니라 개발자에게도 업무를 이해할 수 있는 공통 언어를 제공한다.
   2. 더 나은 generator와 RuboCop이 에이전트와 사람 모두의 개발 경험을 개선하는 것처럼, 스크립트는 팀에 흩어진 암묵지(tacit knowledge)의 사각지대를 드러낸다.
   3. 스크립트의 결과를 visualizer에 전달하면 어느 시점의 파이프라인 상태, 실패 지점, 더 조사할 가치가 있는 영역을 한눈에 볼 수 있다.

4. Rails가 제공하는 구현 경로

   1. Rails는 rake를 통해 도메인 작업용 명령을 쉽게 추가할 수 있다.
   2. Rails shebang script를 사용하면 프레임워크가 제공하는 필요한 기능에 접근하면서 별도의 업무 스크립트를 작성할 수 있다.

6. 실제 고통을 다음 자동화로 바꾸는 지속적 개선

하네스는 한 번에 모든 기능을 도입하는 프로젝트가 아니라, 사람이 실제로 개입한 순간을 관찰하고 같은 개입이 다시 필요하지 않도록 바꾸는 지속적 개선 과정이다.

6.1. lived pain에서 시작하기

1. 모든 도구를 한꺼번에 넣지 않기

   1. RuboCop, Cop, generator, 훅, 리뷰 스킬, 도메인 스크립트를 모두 한 번에 도입하면 관리 대상과 실패 원인이 불필요하게 커진다.
   2. 실제 작업에서 발생한 고통(lived pain)을 기준으로 다음 자동화 대상을 선택해야 한다.

2. 사람의 개입을 시스템 개선으로 전환하기

   1. LLM을 직접 고쳐야 할 때마다 “이것이 마지막이 되려면 어떻게 해야 하는가?”를 묻는다.
   2. 다음번에는 사람 없이 에이전트가 스스로 교정하도록 하네스에 도구와 신호를 추가한다.
   3. 사람이 값을 복사해 프롬프트 사이를 오가는 human plumbing이 보이면 LLM이 도구에 직접 읽기·쓰기 권한을 가질 수 있는지 확인한다.

6.2. 하네스를 점검하는 질문

1. 개입과 신호 점검

   1. 작업 중 사람이 개입한 지점은 어디였는가?
   2. 에이전트가 판단하기 위해 필요했지만 빠져 있던 신호는 무엇이었는가?
   3. 사람이 수동으로 복사해 오간 데이터가 있었는가?

2. 문서와 대화 구조 점검

   1. AGENTS.md에 적힌 내용 중 결정론적 도구가 더 잘 처리할 수 있는 것은 무엇인가?
   2. 대화가 길어지며 품질이 저하됐다면 여러 대화로 나눌 수 있었는가?
   3. 같은 실수가 반복해서 발생했는가?

6.3. Retro 스킬로 세션을 되돌아보기

1. 자동 회고 도구

   1. Joël은 긴 LLM 세션이 끝난 뒤 대화 기록을 분석하고 적용 가능한 자동화를 제안하는 retro 스킬을 만들었다.
   2. 이 스킬은 GitHub의 JoelQskills에서 확인할 수 있다고 소개됐다.

2. 유사한 공개 스킬

   1. Matt Poke가 같은 이름의 Retro 스킬을 최근, 발표 시점 기준 지난주에 공개했다는 언급이 있었다.
   2. Matt Poke의 스킬을 이미 사용한다면 다음 AI 세션 뒤에 바로 같은 회고 기능을 사용할 수 있을 가능성이 있다.

주요 발언 모음

“A model can't run code on its own. Ideally, we would want something else to do this automatically.”

“The loop plus the tests are what are going to steer the agent to the right choice.”

“Agents.md is really just another form of prompt and pray.”

“Anytime you're feeling frustrated by something that LLM does and you want it to stop that behavior, ask yourself, is there a way to catch that using a cop?”

“Agents want to take the easy path.”

“It's much easier to steer from the middle of the path.”

“When a measure becomes a target, it ceases to be a good measure.”

“Anytime you have to correct an LLM, ask yourself, how could this be the last time?”

“No more prompt and pray. Instead, remember that an agent is a loop.”

“Don't just fix the mistake. Don't just prompt for a better fix, but instead try to fix the system so that the next time it doesn't make that mistake again.”

핵심 데이터 & 수치

• 2일 → 1시간의 초기 기대: 약 2일로 잡힌 기능이 첫 실행 약 1시간 뒤 작동하는 결과를 냈다.
• 2일 → 2일의 최종 현실: 품질 손질과 리뷰에 첫날 반나절·저녁 및 다음 날까지 사용해 결국 2일이 걸렸다.
• 약 2분: LLM을 활용하면 반복되는 멀티테넌시 결함을 잡는 커스텀 Cop을 약 2분 만에 만들 수 있다는 경험적 제안이다.
• 약 90%: AGENTS.md에서 Rails generator 사용을 지시하는 방식만으로 migration 문제를 해결한 경험적 비율이다.
• 약 5%: 문서 수집·처리·연결·게시 업무의 기존 자동화율이다.
• 3단계 리뷰: 구조적 리뷰, 메서드별 리뷰, 가독성·문서화를 보는 polish 리뷰로 구성된다.
• 2×2 사분면: feed-forward/feedback과 computational/inferential 두 축으로 에이전트 조정 수단을 분류한다.

결론 및 시사점

1. 에이전트를 한 번의 프롬프트로 코드를 뽑는 모델이 아니라 환경을 읽고 행동하며 실패하면 다시 도는 루프로 이해해야 한다.
2. 테스트와 반복 루프를 하네스에 연결하면 첫 생성물이 완벽하지 않아도 사람 개입 없이 self-correction을 수행할 수 있다.
3. 스타일 규칙은 AGENTS.md에 길게 쓰지 말고 RuboCop과 커스텀 Cop으로 이동해야 한다.
4. migration처럼 형식과 생성 절차가 중요한 문제는 Rails generator를 정답 경로로 만들고, 훅으로 직접 파일 쓰기를 차단해야 한다.
5. 차단할 때는 거부 이유와 올바른 다음 명령을 함께 알려 에이전트의 쉬운 경로가 올바른 경로가 되게 해야 한다.
6. 결정론적 도구로 잡기 어려운 품질은 좁은 LLM 리뷰 스킬로 이미 생성된 코드를 뒤에서 검사해야 한다.
7. AGENTS.md는 개발자의 암묵지를 모두 담는 문서가 아니라 generator, 검사기, 리뷰 스킬을 호출하는 얇은 라우팅 계층이어야 한다.
8. Code Climate 같은 측정값을 지나치게 엄격한 목표로 만들면 에이전트가 점수만 맞추는 우회 행동을 하므로 적절한 자율성을 남겨야 한다.
9. 도메인 전용 스크립트는 복잡한 데이터 흐름을 bucket, pipeline, exit point 같은 안정적인 언어로 바꿔 LLM의 추론과 사람의 협업을 함께 개선한다.
10. Rails의 rake와 shebang script는 프레임워크의 맥락을 유지한 채 이런 도메인 도구를 만들기 좋은 기반이다.
11. 도구를 한꺼번에 도입하기보다 실제로 사람이 반복 개입한 지점에서 “다음에는 어떻게 마지막으로 만들 것인가?”를 물어야 한다.
12. 오류를 고치는 데서 멈추지 않고 오류가 다시 생기지 않도록 시스템을 고치는 일이 하네스 엔지니어링의 핵심이다.