[한영자막] Rails에서 하네스 엔지니어링을 활용하는 방법 — Joël Quenneville

한 줄 핵심

Rails에서 AI 코딩의 품질을 높이려면 프롬프트를 다듬는 데 그치지 말고, 에이전트를 ‘루프’로 보고 테스트·정적 검사·제너레이터·후크·리뷰 스킬을 하네스에 심어 스스로 교정하게 만들어야 한다.

시간별 요약

1. 0:00
   AI 코딩의 환상과 현실 LLM으로 이틀짜리 작업을 한 시간에 끝낼 수 있을 것 같지만, 실제로는 생성된 코드의 품질을 두 번, 세 번 되돌려 고치는 데 시간을 더 쓰게 된다. 문제는 생산 속도가 아니라 낮은 품질의 출력을 사람이 대신 정리하는 구조에 있다.
2. 3:02
   에이전트는 프롬프트가 아니라 하네스다 에이전트를 단순한 입력-출력 블랙박스로 보면 agents.md나 더 좋은 프롬프트만 찾게 되지만, 실제 핵심은 모델을 감싸는 하네스와 그 안의 루프다. 테스트를 돌리고 실패를 다시 입력해 재생성하는 구조가 있어야 첫 결과가 완벽하지 않아도 스스로 수렴한다.
3. 9:01
   규칙은 문서보다 결정적으로 강제해야 한다 스타일 가이드나 관례를 agents.md에 길게 적는 방식은 불안정하므로, Rubocop 같은 결정적 도구에 규칙을 맡기고 에이전트는 그 도구를 실행하게 하는 편이 낫다. 더 나아가 hooks를 써서 종료 직전에 검사하고 실패하면 재시도시키면, 품질 기준을 훨씬 안정적으로 강제할 수 있다.
4. 13:02
   생성기와 후크로 잘못된 경로를 막기 마이그레이션처럼 형식이 강한 작업은 규칙을 설명하기보다 Rails generator를 강제하는 편이 훨씬 안전하다. 파일 생성 훅으로 db/migrate 직접 쓰기를 막고 generator를 유도하면, 에이전트가 우회하기 어려운 올바른 경로를 기본값으로 만들 수 있다.
5. 17:00
   후보를 만든 뒤 평가하는 피드백형 제어 코드 리뷰나 휴리스틱은 처음부터 모든 경우를 지시하는 대신, 이미 생성된 구체적인 코드를 대상으로 뒤에서 검사하는 편이 더 강하다. Rubocop, generators, review skills, static docs, nearby source code를 2x2 관점으로 배치해 feed-forward와 feedback, deterministic과 inferential을 나눠 쓰면 에이전트의 판단을 더 효과적으로 조정할 수 있다.
6. 23:01
   도메인별 스크립트와 지속적 개선 LLM이 복잡한 도메인 데이터를 이해하지 못할 때는 도메인 전용 스크립트로 상태를 분류하고 시각화해 더 높은 수준의 개념으로 사고하게 만들어야 한다. 사람이 겪은 실제 불편을 출발점으로 하네스를 계속 개선하면, 에이전트뿐 아니라 팀 전체의 작업 방식도 함께 좋아진다.

실무 인사이트

• 프롬프트 개선에 먼저 매달리기보다, 반복되는 오류를 막는 결정적 도구와 후크를 먼저 붙이면 품질 향상이 더 빠르고 재현 가능하다.
• 에이전트가 자주 실수하는 지점을 발견하면 그 실수를 다시 지시하는 대신, generator나 script로 올바른 경로를 기본값으로 만들어야 한다.
• 장기적으로는 ‘이 오류를 다음에도 막을 수 있는가’를 기준으로 시스템을 고쳐야 하며, 인간이 매번 개입하는 루프를 제거하는 것이 핵심이다.