AI를 잘 쓸수록 내가 병목이 된다, 하네스 엔지니어링이라는 발상의 전환

같은 모델에 같은 요청을 넣었는데, 어제는 서른 번을 되물어야 끝나던 일이 오늘은 한 번에 끝났습니다.

모델은 그대로였습니다. 그사이 제가 손댄 건 모델 바깥의 구조 하나였습니다.

한동안 저는 더 좋은 모델이 나오면 해결되리라 보고 미뤄 뒀습니다. 정작 발목을 잡은 건 그 지능을 어디에 어떻게 배치했느냐였습니다.

프롬프트를 아무리 다듬어도 넘지 못하던 벽이, 일을 시키는 구조를 바꾸자 조용히 사라졌습니다.

이 글은 그 구조에 이름을 붙이는 이야기입니다. 저는 그걸 하네스(harness) 엔지니어링이라고 부릅니다.

AI를 제가 더 잘 쓰는 법에서 한 걸음 나아가, 저 대신 일할 구조를 세우는 일입니다.

프롬프트를 늘려도 무너지던 이유

AI에게 일을 맡겨 본 분이라면 이 장면이 익숙하실 겁니다. 처음엔 마법 같습니다.

그런데 여러 단계를 거치거나 중간에 판단이 필요한 일이 되면 갑자기 무너집니다. 결과를 검증해야 하는 일도 마찬가지입니다.

엉뚱한 걸 만들고 시키지도 않은 일을 벌입니다. 확인 없이 다음으로 넘어가기도 합니다.

여기서 사람들은 보통 프롬프트를 더 길게 씁니다. 저도 그랬습니다.

긴 프롬프트는 증상을 덮을 뿐입니다. 진짜 문제는 한 에이전트에게 탐색·판단·검증·실행을 전부 몰아준 데 있었습니다.

사람으로 치면 신입 한 명에게 기획·결정·QA·배포를 동시에 시킨 셈입니다. 유능해도 무너집니다.

그래서 저는 하네스를 구상하는 일을 조직을 설계하는 일로 봅니다.

이 렌즈를 끼면 많은 게 정리됩니다. 저는 하네스를 경영 문제처럼 위임, 인사, 정보 흐름, 자원 배분으로 나눠 봅니다.

하네스를 회사로 본다

위임

오케스트레이터(전체를 지휘하는 층)는 얇을수록 좋습니다. 손을 덜 댈수록 잘 설계된 것입니다.

처음엔 반직관적입니다. 더 많이 개입하고 더 세세히 지시할수록 잘 굴러갈 것 같지만, 실제로는 반대였습니다.

지휘자가 모든 음을 대신 연주하려 들면 오케스트라는 멈춥니다.

잘 맡길수록 오래가는 세션에서 품질이 덜 무너졌습니다. 저는 이걸 위임의 역설이라고 부릅니다.

인사

서브에이전트는 부서이자 직원이고, 가이드와 프롬프트는 그들의 직무기술서입니다.

탐색하는 에이전트, 판단하는 에이전트, 검증하는 에이전트, 실행하는 에이전트를 따로 둡니다. 앞서 말한 붕괴는 대부분 이걸 나누지 않아서 생깁니다.

만드는 쪽과 검증하는 쪽을 분리하니, 검증자가 만든 쪽의 자기 확신에 오염되지 않았습니다.

정보 흐름

컨텍스트 관리는 임원 보고 체계와 같습니다. 하급자가 겪은 모든 걸 임원이 다 읽을 수는 없습니다.

무엇을 요약해 올리고, 무엇을 압축하고, 무엇을 버릴지 정해야 합니다. 그 규칙이 하네스의 수준을 결정합니다.

저는 "쌓기보다 주입"을 원칙으로 삼았습니다. 대화가 길어지면 누적된 잡음이 판단을 흐리므로, 필요한 것만 그때그때 넣어 줍니다.

자원 배분

토큰은 자본입니다. 깊게 한 번 물어볼지, 얕게 여러 번 나눠 물어볼지는 비용 최적화 문제입니다.

완벽을 목표로 토큰을 무한정 태우는 건 설계 실패입니다. 에이전트의 가치는 사람 인건비의 몇 분의 일로 80%짜리 결과를 뽑는 데 있습니다.

새 자동화를 들일지 말지도 저는 이 잣대로 판단합니다. "이 일에 80%면 충분한가?"

병목은 옮겨 갈 뿐

여기까지가 어떻게 만드느냐의 이야기라면, 저를 정말 오래 붙든 건 그다음이었습니다.

AI 도구가 병목을 옮깁니다. 코드를 짜는 병목을 없애면, 이번엔 그 코드를 검증하고 배포하고 살려 두는 쪽으로 병목이 넘어갑니다.

더 아픈 사실도 있습니다. AI를 가장 잘 쓰는 사람이 오히려 전체의 병목이 될 수 있습니다.

혼자 열 명 몫을 만들어 내면, 그 열 명 몫을 검토하고 책임지는 사람도 혼자입니다.

그래서 질문을 바꿔, 만든 것이 어떻게 살아남느냐를 묻습니다.

세컨드 브레인이든 자동화든 실행, 교훈, 되먹임의 순환 루프가 없으면 박제가 됩니다. 진짜 시험대는 제가 안 보고 있을 때도 굴러가느냐입니다.

제 경우 이 깨달음은 구조로 굳었습니다. 자동으로 굴러가도 되는 안전한 일은 무인으로 둡니다.

되돌릴 수 없는 일, 그러니까 실제 배포와 데이터 쓰기와 재시작은 일부러 사람 게이트를 거치게 했습니다. 병목을 가장 덜 위험한 자리에 심어 둔 셈입니다.

데어 보고 알게 된 함정

실제로 데어 봐야 아는 것들입니다.

종료 조건 없는 지시

목표만 던지고 언제 멈출지를 안 적으면, 똑똑한 모델일수록 경우의 수를 탐색하며 토큰을 태웁니다.

밤새 아무것도 아닌 일에 자원이 녹은 적이 있습니다. 지시문에는 항상 멈추는 조건을 적어야 합니다.

'하지 말 것'의 부재

시키지 않은 멀티에이전트를 스스로 벌이고, 고치라고 하지 않은 걸 리팩터하는 오버엔지니어링이 생깁니다.

하고 싶은 일만큼 하지 말아야 할 일을 명세해야 통제됩니다.

게이트 없는 자율

발견하고 초안 짜는 것까지는 마음껏 맡기되, 우선순위와 배포는 사람이 쥡니다.

자율의 범위를 긋지 않으면 자율은 사고의 다른 이름이 됩니다.

그래서 지시문을 쓸 때는 목표(goal), 종료 조건, 하지 말 것, 역할의 원자성을 챙깁니다. 하나라도 빠지면 유능한 모델일수록 더 크게 어긋납니다.

새 자동화를 들이기 전에 묻는 것

• 이 일을 한 에이전트에게 몰아주고 있지 않은가. 위임, 역할 분리, 정보 흐름, 자원 배분 가운데 비어 있는 칸을 봅니다.
• 지휘층이 너무 두껍지 않은가. 덜 개입할수록 덜 무너졌습니다.
• 병목이 어디로 옮겨 가는가. 되돌릴 수 없는 일 앞에는 사람 게이트를 둡니다.
• 이 일에 80%면 충분한가. 비용 대비 가치로 자동화를 정합니다.

돌아보면 하네스 엔지니어링은 제가 자리를 비워도 무너지지 않는 구조를 세우는 인내심의 문제였습니다.

다음 글에서는 이 조직에 기억을 붙입니다. 세션이 끝나면 다 잊는 에이전트가 어제 배운 걸 오늘 기억하게 만든 방법, 마크다운 파일 한 뭉치가 메모리가 되는 과정을 다룹니다.