하네스는 언젠가 짐이 된다 — 그런데 A4 한 장은 끝까지 남는다

AI로 뭔가를 만들어 본 사람이라면 하네스(harness)를 안 만들 수 없다. 모델 혼자 두면 엉뚱한 데로 새니까, 앞뒤로 뭔가를 덧대게 된다. 출력 포맷을 강제하고, 단계를 쪼개고, 검증을 붙이고, 실패하면 다시 부른다. 그렇게 덧댄 것들이 쌓여서 하나의 구조물이 된다.

문제는 이 구조물이 영원히 자산으로 남지 않는다는 점이다. 어떤 하네스는 6개월 뒤에 짐이 되고, 어떤 하네스는 5년 뒤에도 필요하다. 이 둘을 구분하지 못하면, 없어져도 되는 걸 붙들고 유지보수하면서 정작 필요한 건 아무도 안 적어두는 상태가 된다.

구분선은 의외로 단순하다. 모델이 못해서 만든 하네스인가, 우리가 안 정해서 만든 하네스인가.

---

실행하네스 VS 기획하네스

 

실행 하네스: 모델의 부족함을 메우는 것

실행 하네스는 모델의 능력 부족을 보완하려고 만든 것들이다.

• 추론을 유도하려고 "단계별로 생각해보라"고 프롬프트에 박아 넣던 것
• JSON을 안정적으로 받으려고 정규식으로 파싱하고 3번까지 재시도하던 것
• 긴 문서를 못 다루니까 청크로 쪼개서 요약하고 다시 합치던 것
• 도구를 순서대로 못 부르니까 상태 기계를 밖에서 짜서 강제하던 것

이런 것들의 공통점은, 만들 당시엔 반드시 필요했다는 것이다. 그리고 또 하나의 공통점은, 지금은 상당수가 필요 없어졌다는 것이다.

실행 하네스는 모델과 제로섬 관계다. 모델이 잘하게 된 만큼 하네스가 할 일이 줄어든다. 그 줄어든 자리를 정리하지 않으면 하네스는 자산에서 부채로 조용히 넘어간다.

부채가 됐다는 신호는 대체로 이렇게 나타난다.

1. 모델을 바꿀 때마다 하네스를 다시 튜닝해야 한다. 하네스가 특정 모델의 약점에 맞춰 조각되어 있다는 뜻이다.
2. 하네스가 모델보다 똑똑하다고 가정하고 있다. 예전엔 맞는 가정이었다. 지금도 맞는지는 확인해봐야 한다.
3. 왜 이 단계가 있는지 아무도 설명하지 못한다. 만든 사람이 나갔거나, 만든 이유가 사라졌거나, 둘 다다.

그래서 실행 하네스는 만들 때부터 버릴 준비를 하고 만드는 게 맞다. 잘 만든 실행 하네스의 이상적인 미래는 "잘 유지되는 것"이 아니라 "필요 없어져서 삭제되는 것"이다.

---

기획 하네스: 모델이 알 수 없는 것을 채우는 것

기획 하네스는 성격이 완전히 다르다. 이건 모델이 못해서 있는 게 아니라, 애초에 모델의 몫이 아닌 것을 담고 있다.

기획 하네스는 대체로 세 덩어리로 나뉜다.

1) 문제 정의

누가, 언제, 뭘 못해서, 뭘 포기하는가.

이 네 개가 다 채워지지 않은 문장은 문제 정의가 아니라 소망이다. "고객 응대를 자동화하고 싶다"는 소망이고, "상담사가 오후 피크타임에 문의 유형 분류를 못 따라가서, 결국 단순 문의를 먼저 처리하고 복잡한 문의를 다음 날로 넘긴다"는 문제 정의다. 뒤엣것만이 무엇을 만들지 결정할 수 있다.

2) 판단 기준과 제약

세상에 공짜는 없다. 빠르게 하면 거칠어지고, 꼼꼼히 하면 느려진다. 싸게 하려면 뭔가는 포기해야 한다.

이 교환 관계 자체는 모델도 안다. 모델이 모르는 건 우리가 어느 쪽을 택하기로 했는가다. 그리고 이건 정답이 있는 문제가 아니다.

3) 의사결정 기록

"이건 이미 정했고, 이런 이유로 정했다."

이게 없으면 같은 논의가 분기마다 반복된다. 사람끼리도 반복되고, 모델과도 반복된다. 기록되지 않은 결정은 결정이 아니라 그날의 분위기다.

---

"기획 하네스도 언젠가 없어지는 거 아냐?"

당연히 나오는 질문이다. 실행 하네스가 모델 성능에 밀려 사라졌으니, 기획 하네스도 시간문제 아니냐는 것.

그런데 기획 하네스는 성능 곡선 위에 놓여 있지 않다. 네 가지 이유가 있다.

능력의 문제가 아니라 소유의 문제다

모델은 훌륭한 기획서를 쓸 수 있다. 이미 쓴다. 하지만 그 기획이 틀렸을 때 손해를 보는 건 모델이 아니다. 결과를 감당하는 주체와 결정하는 주체가 다르면 그건 위임이 아니라 방치다.

능력이 아무리 올라가도 소유권은 자동으로 이전되지 않는다.

기획은 능력이 아니라 정보의 문제다

모델은 인터넷에 쓰인 거의 모든 것을 읽었다. 그런데 우리 팀이 작년에 그 기능을 왜 접었는지는 모른다. 영업팀이 어떤 요청에 유독 예민한지도, 특정 고객사가 어떤 단어를 싫어하는지도 모른다.

이건 컨텍스트 창이 좁아서가 아니다. 그 정보가 애초에 어디에도 쓰인 적이 없기 때문이다. 검색의 문제가 아니라 기록의 문제이고, 기록은 사람이 한다.

취향은 성능으로 안 풀린다

A안과 B안이 둘 다 합리적일 때가 있다. 데이터로도 안 갈린다. 이때 하나를 고르는 건 정답을 찾는 행위가 아니라 정체성을 선언하는 행위다.

온보딩을 3단계로 할지 1단계로 할지, 기본값을 보수적으로 둘지 공격적으로 둘지 같은 선택들. 모델은 두 선택지의 장단점을 완벽하게 정리해준다. 그리고 정확히 거기까지가 모델의 일이다.

책임은 위임이 안 된다

사고가 났을 때 사과문에 서명하는 건 사람이다. 배포 버튼도 사람이 누른다. 책임을 질 수 없는 주체에게 결정을 넘기면, 책임은 사라지는 게 아니라 그냥 나중에 더 비싸게 청구된다.

정리하면 이렇다.

실행 하네스는 모델의 부족함을 메운다. 부족함은 시간이 해결한다. 기획 하네스는 모델이 알 수 없는 것을 채운다. 그건 시간이 해결하지 않는다.

---

그래서 남기는 것: A4 한 장

여기서 흔한 오해가 하나 생긴다. "기획 하네스가 중요하다"를 "기획 문서를 두껍게 쓰자"로 읽는 것.

반대다. 기획 하네스도 두꺼워지면 똑같이 짐이 된다. 30페이지 기획서는 아무도 안 읽고, 안 읽히는 문서는 없는 문서와 같다. 심지어 "있다고 착각하게 만든다"는 점에서 더 나쁘다.

모델이 스스로 채울 수 없는 최소한만 남긴다. 분량으로는 A4 한 장이면 충분하다.

① 맨 위 — 문제 한 문단

두 문장이면 된다.

• 누가, 언제, 뭘 못해서, 뭘 포기하는가
• 이게 해결되면 뭐가 달라지는가

두 번째 문장을 못 쓰겠다면, 그건 아직 만들 때가 아니라는 신호다.

② 판단 기준 5줄

형식은 "A보다 B다. 왜냐하면 —" 하나로 통일한다.

• 완결성보다 응답 속도다. 왜냐하면 사용자가 대기 중에 이탈하기 때문이다.
• 신규 기능보다 기존 데이터 정합성이다. 왜냐하면 한 번 깨진 신뢰는 기능으로 못 메우기 때문이다.

5줄로 제한하는 게 핵심이다. 10줄이 되는 순간 그건 기준이 아니라 희망 목록이 되고, 정작 충돌하는 순간에 아무것도 판단해주지 못한다. 기준은 무엇을 포기할지 알려줄 때만 기준이다.

③ 제약 목록

바꿀 수 없는 것들. 예산, 마감, 이미 쓰기로 한 스택, 법적 요건, 건드리면 안 되는 레거시.

제약은 창의성을 죽이는 게 아니라 탐색 범위를 줄여준다. 제약이 안 적혀 있으면 사람도 모델도 실현 불가능한 안을 열심히 만들어 온다.

④ 결정 기록 (ADR)

한 건당 세 줄이면 된다.

• 무엇을 정했나
• 왜 정했나
• 무엇을 포기했나

세 번째 줄이 제일 중요하고, 제일 자주 빠진다. 포기한 걸 적어두지 않으면 6개월 뒤에 누군가 "이거 왜 안 했지?"라며 똑같은 길을 다시 걷는다.

---

하네스 점검 질문 하나

가지고 있는 하네스를 하나씩 놓고 물어보면 된다.

"이건 모델이 못해서 있는 건가, 우리가 안 정해서 있는 건가?"

• 모델이 못해서 있는 것 → 만료일을 정해두고, 모델이 바뀔 때마다 없애도 되는지 확인한다.
• 우리가 안 정해서 있는 것 → 코드가 아니라 종이에 적는다. A4 한 장 안에.

실행 하네스를 줄이는 건 기술의 진보에 올라타는 일이고, 기획 하네스를 남기는 건 진보와 무관하게 남는 몫을 인정하는 일이다. 둘을 섞어두면 둘 다 짐이 된다.

모델은 '어떻게'를 점점 더 잘하게 된다. 하지만 '왜 하는가'와 '무엇을 포기할 것인가'는 처음부터 모델에게 물어본 질문이 아니었다.