하네스만으로는 부족하다. (Dex Horthy)

masonfe-hyunsu

🧵 1. 개요.

HumanLayer 공동창업자 Dex Horthy가 AI Engineer 행사에서 Harness Engineering is not Enough라는 제목으로 한 발표를 보고 정리했다.
요즘 이런 말을 자주 듣는다. AI에게 일을 더 맡기고, 도구를 더 붙이고, 토큰만 늘리면 알아서 잘 돌아간다. 코드는 안 읽어도 된다.
강연자는 이게 실제 서비스 코드에서는 통하지 않는다고 본다. 이 포스팅에서는 왜 그런지, 대신 뭘 하자는지 옮긴다.

🔥 2. 동기 : 토큰만 늘리면 된다는 말.

강연 초반은 풍자로 시작한다. 루프를 더 돌리고, 토큰을 더 쓰고, 코드 리뷰는 빼도 된다는 그림이다.

lights-out이라는 말도 나온다. 공장 불을 끄듯, 사람은 코드를 안 보고 에이전트만 돌린다는 뜻이다.

말은 그런데, 실제로는 이미 문제가 보인다.

코딩 에이전트 때문에 원래 나지 않을 장애가 난다
Faros AI 보고서 기준, AI 도구를 쓰기 시작한 뒤 PR 리뷰가 대충 되고, 리뷰 없이 머지되는 PR이 늘었다
코드는 3~6개월만 지나도 손대기 어려워진다

말하는 쪽과 실제로 드러나는 쪽은 이렇게 갈린다.

강연자는 HumanLayer에서 lights-out을 직접 돌려 봤다. 결국 사람이 다시 코드를 읽어야 했다고 말한다. 에이전트가 못 고치면, 멈춰 둔 코드를 처음부터 다시 파고들어야 한다.

🗺️ 3. 소프트웨어 팩토리가 뭐냐면.

강연에서 말하는 소프트웨어 팩토리는, 이슈부터 배포까지 일이 컨베이어 벨트처럼 흘러가는 구조다.

2022 팩토리 vs 에이전트 팩토리를 나란히 보면 이렇다. 위는 사람이 구현하고, 아래는 에이전트가 구현한다. 리뷰는 둘 다 병목이다.

예전(2022년) 방식은 이렇다.

Jira, Linear에 일을 넣는다
사람이 코드를 짠다
테스트하고 PR을 올린다
사람이 리뷰하고 배포한다

구현도 며칠, 리뷰도 며칠 걸린다. 그래서 팀은 코딩 전에 무엇을 만들지, 구조를 어떻게 할지 미리 맞춰 두었다. 리뷰에서 싸우는 시간을 줄이려는 쪽이다.

에이전트 팩토리는 2번만 바뀐다. 사람 대신 AI가 코드를 짠다.

짜는 속도는 확 빨라진다
리뷰와 검증은 여전히 시간이 걸린다
그래서 AI 리뷰, AI 테스트, 장애 대응까지 자동으로 돌리는 루프가 붙는다

구현은 빨라져도, 리뷰와 검증은 여전히 길다.

여기서 한 걸음 더 나가면, 일을 더 넣고, 루프를 더 돌리고, 사용자 피드백도 바로 공장에 넣으면 된다는 그림이 나온다. 강연자는 코드 리뷰까지 포기하는 쪽은 실제 서비스에는 통하지 않는다고 본다.

⚠️ 4. 하네스만으로는 부족하다.

강연 제목 그대로다. the harness is not enough, 하네스만으로는 부족하다.

하네스는 AI가 일할 때 쓰는 도구 묶음이다. 파일 읽기, 수정하기, 테스트 돌리기 같은 것들. Claude Code가 빠르게 퍼진 이유 중 하나는, 모델이 이런 도구 루프에 맞춰 학습됐기 때문이라는 설명이 설득력 있다.

그런데 강연자는 이렇게 말한다. 도구를 더 붙이고 루프를 더 돌려도, 코드가 시간이 지나도 깨끗해지지는 않는다.

왜냐하면 AI는 원래 이렇게 평가받기 때문이다.

시험 문제 하나를 푸는 건 잘한다
그런데 몇 달 뒤에도 코드를 편하게 고칠 수 있게 만드는 건 어렵다

유지보수성이란, 한 부분을 고칠 때 다른 부분이 같이 깨지지 않게 유지하는 능력이다. AI가 짠 코드는 여기서 자주 문제가 난다.

이유를 더 풀면 이렇다. AI 실력을 재는 벤치마크(시험) 대부분이 테스트 통과에 맞춰져 있다. 테스트만 통과하면 점수를 준다. 그러면 AI는 테스트만 통과하면 되니까, 타입을 억지로 맞추거나 테스트를 주석 처리하는 식의 쓸데없는 코드(slop) 를 남기기 쉽다.

설계가 나빠지는 문제는 몇 달 뒤에야 드러난다. 그때는 이미 AI가 "이건 잘못됐다"고 배울 타이밍을 놓친 뒤다.

벤치마크가 보는 것과, 우리가 나중에 겪는 것은 다르다.

리뷰 봇을 붙이거나 토큰을 더 써도, 최저선은 올릴 수 있어도 한계를 뚫기는 어렵다.

당장 할 수 있는 건 벤치마크를 기다리는 게 아니라, 사람이 코딩 전에 맞춰 두는 것에 가깝다.

📐 5. 코딩 전에 맞추기.

강연이 제안하는 해법은 루프를 더 돌리는 게 아니다. 코드를 다시 읽고, 코딩 전에 맞춘 뒤 AI를 돌리는 쪽이다.

큰 일은 코딩 전 맞추기 → AI 구현 → 사람 확인 순서를 탄다. 작은 일은 AI에 바로 맡겨도 된다.

맞추기를 네 단계로 나누면 이렇다.

제품 리뷰 — 무슨 문제를 풀지, 사용자에게 어떻게 보일지
아키텍처 — 큰 덩어리를 어떻게 나눌지, 데이터는 어떻게 둘지
프로그램 설계 — 함수 이름, 타입, 누가 누구를 호출할지 (그림만 그리고 끝내기엔 부족하다는 지적)
vertical slice — 어떤 순서로 짤지, 중간에 어떻게 확인할지

강연에서는 앞의 30분을 맞추면 리뷰가 몇 시간 줄어든다고 말한다. PR이 많다고 잘 도는 건 아니다. 고칠 게 많은 PR이 많다는 뜻에 가깝다. 앞에서 맞춰 두면 리뷰는 "우리가 얘기한 대로네"에 가까워진다.

AI는 이 맞추기 문서를 빠르게 잡는 데 쓸 수 있다. 맞추기를 없애라는 게 아니라, 한 번에 정보를 모으는 데 쓰라는 쪽이다. (오케스트레이션과 플래닝도 같은 층을 다뤘다.)

🔀 6. PR과 코드 소유권.

강연 마무리도 분명하다.

역할을 나누면 이렇다.

코드 한 줄 한 줄을 읽을 수 있어야 진짜로 빨라진다
코드 책임은 사람에게 남는다
AI 도구는 쓰되, 코드를 안 읽는 세계는 아직 오지 않았다

리뷰에서 20%만 고쳐도 리뷰어와 작성자 모두 부담이 크다. 앞에서 맞춰 두면 짜는 건 AI가 하고, 리뷰는 확인에 가까워진다.

🧭 7. 정리.

하네스(도구 묶음)는 필요하다. 다만 도구와 루프만 늘린다고 팩토리가 잘 도는 건 아니다
짜는 속도는 빨라져도, 코드를 오래 쓸 수 있게 만드는 것과 코딩 전에 맞추는 것이 병목이다
제품 리뷰, 아키텍처, 프로그램 설계, vertical slice로 앞에서 맞추면 리뷰 부담이 줄고, 코드를 읽을 여지가 생긴다
코드를 안 읽는 방식은 당분간 현실적이지 않다. AI를 더 쓸수록 사람이 읽고 책임지는 구간을 더 분명히 해야 한다

에이전트에 어디까지 맡길지(AI에게 인프라 권한까지 넘기기)와 짝지어 볼 만하다. 도구는 필요하고, 그 위에 코딩 전에 맞추기가 없으면 팩토리만 커진다.