Kuma Studio · 실측 리포트
하네스는 무엇을 위해 남는가
"이제 하네스 쓰지 마세요"라는 주장을 우리 환경에서 그대로 받을 수 있는지 하룻밤 A/B 로 재봤다. 일부는 우리한테도 맞았지만, 맞지 않는 쪽에서 더 쓸 만한 게 나왔다.
왜 쟀나
발단은 "1년간 쌓은 하네스를 전부 걷어냈더니 결과가 더 좋아졌다"는 한 영상이었다. 논지는 명확하다. 하네스는 모델을 못 믿어서 만드는 장치이고, 그건 그 시점 모델의 약점 지도다. 지형이 바뀌면 지도는 쓸모없어질 뿐 아니라 적극적으로 해를 끼친다. 남길 것은 "무엇을 왜 만들지"를 고정하는 기획 하네스뿐이다.
우리는 규칙 문서와 플랜·검증 절차를 오래 쌓아온 쪽이라, 이 주장이 맞다면 뼈아프다. 그래서 동의하거나 반박하는 대신 직접 재봤다.
실험 1. 원칙을 명시하는 것이 실제로 행동을 바꾸는가
우리는 여덟 개의 엔지니어링 원칙을 모든 세션의 시스템 프롬프트에 넣는다. 지금 모델이라면 이미 아는 내용이니 중복 아니냐는 의심이 있었다.
원칙 위반이 유혹적인 함정 과제 세 종을 만들고, 원칙 본문을 준 조건과 안 준 조건을 비교했다. 대조군은 헤드리스 실행으로 확보했다. 처음엔 서브에이전트로 하려다 서브에이전트가 원칙을 상속받는다는 사실을 발견해 매체를 바꿨다. 이걸 모르고 그대로 돌렸으면 대조군이 오염된 채로 결론을 냈을 것이다.
막대가 낮을수록 좋다. 0 은 두 번 다 원칙을 지켰다는 뜻이다. 세 번째 함정에서 두 조건이 같아진 것이 핵심이다.
표로 보기
| 함정 | 원칙 없음 | 원칙 있음 | 조건 차이 |
|---|---|---|---|
| 설정 누락 크래시 | 2 / 2 위반 | 0 / 2 위반 | 있음 |
| 값 중복 유혹 | 2 / 2 위반 | 0 / 2 위반 | 있음 |
| 경쟁 조건 버그 | 0 / 2 위반 | 0 / 2 위반 | 없음 |
세 번째 함정이 핵심이다. 순수한 correctness 버그에서는 원칙이 아무것도 더하지 않았다. 양쪽 모두 원자적 조건부 UPDATE 라는 같은 정답에 도달했다. 원칙은 지식을 공급하지 않았다.
갈린 것은 티켓이 요구하는 싼 길이 존재하는 함정에서였다. 그리고 결정적인 사실은, 원칙 없는 쪽이 답을 몰랐던 게 아니라는 점이다. 그쪽도 자기 답변에 이렇게 적었다.
기본값을 쓰면 잘못 설정된 배포가 조용히 다른 리전으로 트래픽을 보낸다. 공유 패키지가 진짜 해법이다.
알면서 싼 길을 택했다. 원칙이 제공한 것은 지식이 아니라 티켓 문구를 거부할 권한이었다. 원칙을 받은 쪽은 대놓고 "티켓의 문자적 요구를 의도적으로 거부한다"고 썼다.
두 줄로 줄인 최소 버전(No Silent Fallback 과 SSoT 만)도 전체 여덟 원칙과 같은 결과를 냈다. 두 함정 각 2회씩 4회 모두 위반 0. 효과는 문서 두께가 아니라 "이것은 티켓보다 우선하는 상시 규칙"이라는 지위 선언에서 나온다. 세 번째 함정은 최소 버전으로 돌리지 않았다.
실험 2. 반복 검증은 품질을 깎는가
영상의 주장은 이렇다. "검사해 봐"라는 말 자체가 "문제가 있을 것"이라는 신호라서, 모델은 멀쩡한 답에서도 억지로 흠을 찾아내고 고칠수록 나빠진다.
같은 코드를 두 프레이밍으로 검토시켰다. 중립("결함이 없으면 없다고 답하라") 3회, 프라이밍("이전 리뷰어가 놓친 것을 찾아라") 3회.
프라이밍이 트집을 만들게 한다면 허위 지적이 늘어야 한다. 실제로는 보고 수가 늘었고, 재현해 본 지적은 모두 사실이었다.
표로 보기
| 프레이밍 | 1회 | 2회 | 3회 | 평균 |
|---|---|---|---|---|
| 중립 | 3 | 4 | 3 | 3.3 |
| 프라이밍 | 6 | 4 | 5 | 5.0 |
차이를 만든 것은 프레이밍이 아니라 판정 기준의 명확성이었다. "구체적 실패(입력에 대해 잘못된 출력이 나온다는 것)를 제시하지 못하면 보고하지 말라"는 조건이 트집을 구조적으로 막았다. 영상 자신이 인정한 "기준이 명확할 때는 검사가 여전히 좋다"가 정확히 이 경우다.
보고 수는 전수를 세었고, 그중 서로 다른 결함 네 종은 코드로 재현해 사실로 확인했다. 모든 지적을 개별 재현한 것은 아니므로 허위 0건이라는 말은 확인한 범위 안에서의 진술이다.
그리고 그 검토가 잡은 것
검토 대상은 같은 날 낮에 내가 작성하고 스스로 검증해 통과시킨 파일이었다.
read/write, I/O, and/or, 날짜가 파일 경로 칩으로 렌더나는 그 코드에 "무손실 계약"이라는 이름을 붙이고 라운드트립 테스트까지 작성했다. 그 테스트는 내가 상상한 입력만 검증했다. URL 을 한 번도 떠올리지 않았다.
검증을 줄일 것이 아니라 자기검증을 줄여야 한다. 실패 원인은 실력이 아니라 구조다. 파서나 정규식처럼 작성자가 입력 공간을 상상해야 하는 코드에서는 작성자의 프레이밍이 곧 사각지대이고, 그 사각지대는 같은 사람이 한 번 더 본다고 사라지지 않는다.
실험 3. 엔진 응답 속도
한쪽 엔진이 체감상 느리다는 의심이 있어 동일 과제로 재봤다. 표본이 각 3회라 평균 막대 대신 개별 실행을 점으로 찍는다.
점 하나가 실행 하나다. 두 엔진의 분포가 겹친다.
표로 보기
| 엔진 | 1회 | 2회 | 3회 | 범위 |
|---|---|---|---|---|
| Claude | 8.5초 | 10.1초 | 8.1초 | 8.1 ~ 10.1 |
| Codex | 8.5초 | 10.1초 | 10.3초 | 8.5 ~ 10.3 |
차이는 표본 안 산포보다 작다. 체감 느림이 있다면 모델이 아니라 다른 층에서 찾아야 한다.
처음 측정에서 한 엔진이 15분 넘게 응답하지 않아 "역시 느리다"로 갈 뻔했다. 확인해 보니 측정 스크립트가 표준입력을 닫지 않아 도구가 입력을 기다리며 멈춰 있었다. 재는 방법이 틀리면 결론이 통째로 뒤집힌다.
실험 4. 절차 비용
"정비공일 때는 시간의 70%가 장치 고치는 데 간다"는 주장을 우리 세션 로그로 쟀다.
즉 우리 경우 비용은 절차의 양이 아니라 절차를 어디에 쓰는가에 있었다. 다만 이 측정은 세션 후반부만 담고 있어 전일 대표성은 없다.
이 논지가 우리에게 맞지 않는 부분
영상의 논지는 "모델 약점을 메우는 하네스"에 대해서만 옳다. 우리 하네스의 큰 축 셋은 그 논지 밖에 있다.
1. 동시성 조정
워크트리 격리, 포트 소유권, 커밋 저자성은 모델이 좋아진다고 사라지지 않는다. 영상 저자는 한 사람이 하나의 AI 와 순차로 일하므로 이 축이 아예 없다.
2. 기억 없는 행위자
영상은 "기억력이 하루짜리인 천재 컨설턴트에게 노트를 남겨라"고 하며 결정 기록을 끝까지 남길 것으로 분류한다. 우리 워커는 매번 백지로 부팅한다. 영상 저자보다 이것이 더 필요하지 덜 필요하지 않다.
3. 입장으로서의 원칙
실험 1이 보인 대로, 원칙은 능력이 아니라 거부권이다. 모델이 아무리 좋아져도 무엇을 포기하지 않을지는 소유자가 정한다.
그래서 무엇을 줄이나
"규칙 문서가 두꺼우니 가지치기하자"는 첫 진단은 프레이밍이 틀렸다. 우리에겐 이미 더 정밀한 답이 문서로 있었다.
- 판단 지식. 맥락을 저울질해야 하는 것. 산문이 올바른 최종 그릇이다.
- 행동 규칙. 기계로 확인 가능한 선행조건. 산문은 임시 그릇이고 게이트가 목적지다.
영상은 이 구분이 없어 둘을 뭉뚱그린다. 실제 다이어트 대상은 문서 전체가 아니라 이미 도는 게이트를 산문으로 다시 설명한 부분이다. 같은 날 보안 게이트가 실제로 실수 하나를 잡았는데, 그 규칙의 산문은 여전히 다섯 문장이었다.
한계
- 함정 과제를 실험 설계자가 만들었다. 기대가 개입할 여지가 있다.
- 조건당 2~3회 반복이라 표본이 작다. 차트의 막대 높이는 비율이 아니라 실행 횟수다.
- 결함 보고 수는 전수를 세었지만 재현 확인은 서로 다른 네 종에 대해서만 했다.
- 절차 비중 4%는 세션 후반부 로그라 전일 대표성이 없다.
- 측정 도중 도구가 입력을 기다리며 멈춘 것을 엔진 속도로 오독할 뻔했다. 고쳐 재니 두 엔진은 사실상 같았다.