AI를 잘 쓸수록 내가 병목이 된다 — 하네스 엔지니어링이라는 발상의 전환
같은 모델에 같은 요청을 넣었는데, 어제는 서른 번을 되물어야 끝나던 일이 오늘은 한 번에 끝났습니다. 바뀐 건 모델이 아니었습니다. 그사이 제가 손댄 건 딱 하나, 모델 바깥의 구조였습니다.
한동안 저는 "더 좋은 모델이 나오면 해결되겠지"라고 미뤄뒀습니다. 정작 발목을 잡은 건 모델의 지능이 아니라, 그 지능을 어디에 어떻게 배치했는가였습니다. 프롬프트를 아무리 다듬어도 넘지 못하던 벽이, 일을 시키는 구조를 바꾸자 조용히 사라졌습니다.
이 글은 그 구조에 이름을 붙이는 이야기입니다. 저는 그걸 하네스(harness) 엔지니어링이라고 부릅니다 — AI를 내가 더 잘 쓰는 법이 아니라, 나 대신 일할 구조를 세우는 일. 핵심 전략은 세 가지입니다. ① 하네스를 '회사'로 생각하기, ② 병목은 사라지지 않고 이동한다는 사실을 받아들이기, ③ 만드는 법보다 만든 것이 살아남는 법에 집중하기.
왜 프롬프트가 아니라 구조인가
AI에게 일을 맡겨본 분이라면 이 장면이 익숙하실 겁니다. 처음엔 마법 같습니다. 그런데 일이 조금만 커지면 — 여러 단계를 거치거나, 중간에 판단이 필요하거나, 결과를 검증해야 하면 — 갑자기 무너집니다. 엉뚱한 걸 만들고, 시키지도 않은 일을 벌이고, 확인 없이 다음으로 넘어갑니다.
여기서 사람들은 보통 프롬프트를 더 길게 씁니다. 저도 그랬습니다. 하지만 긴 프롬프트는 증상을 덮을 뿐입니다. 진짜 문제는 한 에이전트에게 탐색·판단·검증·실행을 전부 몰아준 것이었습니다. 사람으로 치면 신입 한 명에게 기획·결정·QA·배포를 동시에 시킨 셈입니다. 유능해도 무너집니다.
핵심 — 하네스를 구상하는 일은 프롬프트를 쓰는 일이 아니라 조직을 설계하는 일에 가깝습니다.
이 렌즈를 끼면 많은 게 정리됩니다. 그래서 저는 하네스를 네 개의 경영 문제로 나눠서 봅니다.
하네스를 회사로 본다 — 네 가지 축
① 위임 — 손을 덜 댈수록 잘 설계된 것. 오케스트레이터(전체를 지휘하는 층)는 얇을수록 좋습니다. 이게 처음엔 반직관적입니다. 더 많이 개입하고 더 세세히 지시할수록 잘 굴러갈 것 같지만, 실제로는 반대였습니다. 지휘자가 모든 음을 대신 연주하려 들면 오케스트라는 멈춥니다. 위임의 역설 — 잘 맡길수록 오래가는 세션에서 품질이 덜 무너집니다.
② 인사 — 역할을 쪼갠다. 서브에이전트는 부서이자 직원이고, 가이드와 프롬프트는 그들의 직무기술서입니다. 탐색하는 에이전트, 판단하는 에이전트, 검증하는 에이전트, 실행하는 에이전트를 따로 둡니다. 앞서 말한 붕괴는 대부분 이걸 안 나눠서 생깁니다. 만드는 쪽과 검증하는 쪽을 분리하니, 검증자가 만든 사람의 자기 확신에 오염되지 않았습니다.
③ 정보 흐름 — 무엇을 위로 올릴지 정한다. 컨텍스트 관리는 임원 보고 체계와 같습니다. 하급자가 겪은 모든 걸 임원이 다 읽을 수는 없습니다. 무엇을 요약해 올리고, 무엇을 압축하고, 무엇을 버릴지 — 그 규칙이 하네스의 수준을 결정합니다. 저는 "쌓기보다 주입"을 원칙으로 삼았습니다. 대화가 길어지면 누적된 잡음이 판단을 흐리므로, 필요한 것만 그때그때 넣어줍니다.
④ 자원 배분 — 토큰은 자본이다. 깊게 한 번 물어볼 것인가, 얕게 여러 번 나눠 물어볼 것인가. 이건 비용 최적화 문제입니다. 완벽을 목표로 토큰을 무한정 태우는 건 설계 실패입니다. 에이전트의 가치는 100% 완벽이 아니라, 사람 인건비의 몇 분의 일로 80%짜리 결과를 뽑는 데 있습니다. 새 자동화를 들일지 말지도 저는 이 잣대로 판단합니다 — "이 일에 80%면 충분한가?"
병목은 사라지지 않는다 — 옮겨갈 뿐
여기까지가 '어떻게 만드나'라면, 저를 정말 오래 붙든 건 그다음이었습니다.
AI 도구는 병목을 제거하지 않고 이동시킵니다. 코드를 짜는 병목을 없애면, 이번엔 그 코드를 검증하고 배포하고 살려두는 쪽으로 병목이 옮겨갑니다. 더 아픈 진실은 이겁니다 — AI를 가장 잘 쓰는 사람이 오히려 전체의 병목이 될 수 있다는 것. 혼자 열 명 몫을 만들어내면, 그 열 명 몫을 검토하고 책임지는 병목도 혼자가 됩니다.
그래서 저는 질문을 바꿨습니다. "어떻게 만드느냐"가 아니라 "만든 것이 어떻게 살아남느냐." 세컨드 브레인이든 자동화든, 실행→교훈→되먹임의 순환 루프가 없으면 그냥 박제입니다. 만든 순간이 아니라, 내가 안 보고 있을 때도 굴러가는지가 진짜 시험대입니다.
제 경우 이 깨달음은 구조로 굳었습니다. 자동으로 굴러가도 되는 안전한 일은 무인으로 두되, 되돌릴 수 없는 일 — 실제 배포, 데이터 쓰기, 재시작 — 은 일부러 사람 게이트로 병목을 옮겨 놓았습니다. 병목을 없애는 게 아니라, 가장 덜 위험한 곳에 병목을 심는 겁니다.
반드시 챙길 함정
말이 아니라 실제로 데어봐야 아는 것들입니다.
종료 조건 없는 지시. 목표만 던지고 "언제 멈춰라"를 안 적으면, 똑똑한 모델일수록 경우의 수를 탐색하며 토큰을 태웁니다. 밤새 아무것도 아닌 일에 자원이 녹은 적이 있습니다. 지시문에는 항상 멈추는 조건을 박아야 합니다.
'하지 말 것'의 부재. 시키지 않은 멀티에이전트를 스스로 벌이고, 고치라지 않은 걸 리팩터하는 오버엔지니어링. 하고 싶은 일만큼 하지 말아야 할 일을 명세해야 통제됩니다.
게이트 없는 자율. 발견하고 초안 짜는 것까지는 마음껏 맡기되, 우선순위와 배포는 사람이 쥡니다. 자율의 범위를 안 그으면, 자율은 사고의 다른 이름이 됩니다.
교훈 — 좋은 지시문은 goal(목표)·종료 조건·하지 말 것·역할의 원자성, 이 네 가지를 갖춥니다. 하나라도 빠지면 유능한 모델일수록 더 크게 어긋납니다.
정리
- 하네스는 프롬프트가 아니라 조직 설계다 — 위임·역할 분리·정보 흐름·자원 배분.
- 위임의 역설 — 지휘층은 얇을수록 오래간다. 덜 개입할수록 덜 무너진다.
- 병목은 이동한다 — 만드는 법보다 살아남는 법. 되돌릴 수 없는 일에 사람 게이트를 심어라.
- 80%면 충분한가를 물어라 — 완벽이 아니라 비용 대비 가치가 자동화의 기준이다.
다음 글에서는 이 조직에 기억을 붙입니다. 세션이 끝나면 다 잊는 에이전트에게, 어떻게 어제 배운 걸 오늘 기억하게 만들었는지 — 마크다운 파일 한 뭉치가 어떻게 메모리가 되는가를 다룹니다.
결국 하네스 엔지니어링은 제가 더 똑똑해지는 기술이 아니었습니다. 제가 자리를 비워도 무너지지 않는 구조를 세우는, 인내심의 문제였습니다.