방임이 아니라 위임 — AI 하네스를 짜다가
멈춰 선 자리
AI 오케스트레이션 하네스를 짜고 있었다. instructions, MCP, skills, hooks, sub-agents, 그런 것들. 손은 움직이는데 머리는 한 자리에서 멈춰 있었다.
이 하네스의 좋고 나쁨을 무엇으로 가릴 것인가.
기능 목록을 늘리는 건 평가가 아니다. "동작한다"도 평가가 아니다. 도구가 도구로서 쓸 만한지를 가리려면 도구를 보지 말고, 그 도구로 일하는 방식을 봐야 한다.
되물음에서 출발했다
질문이 어디서 왔는지부터 말해야 정직하다.
AI 오케스트레이션 — 그런 걸 짜야 한다고 생각해서 제안을 들고 갔다. 제어장치, 흐름의 구획, 단계의 경계. 이런 게 있어야 하지 않나?
실무자 분들의 답이 내 예상과 정확히 어긋났다. "지금도 잘 동작하는데, 자율성을 더 줘도 되지 않을까요?" 흐름을 정해 버리는 순간 그 흐름대로만 움직인다는 것이었다. 정해진 길 밖의 답은 생각조차 할 수 없게 된다고.
생각해 본 적 없는 각도였다. 곱씹어 보니 그 말도 맞았다. 그러면서도 — 그래도 가드레일이 필요하지 않나? 흐름은 좀 잡고 가야 하지 않나? 양쪽이 다 맞아 보이는데 어디서 어떻게 조율할지가 잡히지 않았다.
제약이 자율을 죽이는가. 자율이 제약 없이도 굴러가는가. 둘 다 틀린 질문이라면 맞는 질문은 무엇인가.
답이 안 세워져서, 글을 쓰기 시작했다.
두 축으로 줄어든 질문
며칠 머문 끝에 질문은 두 개로 줄었다.
- AI가 잘 동작하는가 — 결과의 품질, 일의 진척, 사람이 기대한 것에 도달하는 빈도.
- 그 안에서 우리가 컨트롤할 수 있는가 — 관찰·중단·교정·롤백·책임 추적.
흔히 trade-off로 등장하지만 그래선 안 된다. 한쪽을 깎아 다른 쪽을 사는 설계는 임시방편이다. 좋은 하네스는 둘이 같은 방향으로 자란다.
사분면 — 함정은 우상단
두 축을 그려보면 이렇다.
동작
안 함
함정은 우상단이다. 결과가 좋기 때문에 모두가 만족하고, 아무도 안을 들여다보지 않는다. 그러다 어느 날 무너진다. 사후 회의의 단골 문장이 거기서 나온다 — "운영되고 있는 줄 알았는데."
좌하단은 다르다. 처음 구조를 잡을 때는 어쩔 수 없이 마이크로매니징부터 시작한다. 하나하나가 동작하는지 살피고, 동작하면 이어붙여서 그 묶음이 동작하는지 보고, 그러면 점점 더 큰 범주가 위로 올라간다. 위임은 그 위에 비로소 얹힌다.
방임과 위임의 차이
손을 떼는 모양은 똑같다. 그러나 본질은 정반대다.
- 방임은 AI가 알아서 하길 바라며 자리를 비운다. 결과가 좋으면 좋은 줄, 나쁘면 그제야 안다.
- 위임은 권한과 범위를 명시적으로 넘기되, 보고 라인·중단 권한·교정 루프는 사람이 쥔다. 들어가야 할 때 들어갈 수 있다.
핵심은 HITL — human in the loop이다. 사람이 루프 밖으로 나가면 방임, 루프 안에 남아 있으면 위임. 코드를 짠 사람이 항상 모든 줄을 다시 읽지는 않지만, 들어가야 할 때 들어갈 수 있는 자리에 머물러 있다 — 그 자리값이 위임의 본질이다.
그래서 위임은 가장 비싼 행위 중 하나다. 한가해지는 일이 아니다. 신뢰가 필요한 일이다 — 내가 아닌 누군가에게 손을 떼어 맡기는 거니까. (나는 자주 농담처럼 "뉴럴링크라도 해서 내가 여러 명이 됐으면 좋겠다"고 말한다. 위임은 결국, 내가 아닌 존재를 나의 연장으로 받아들이는 훈련이다.) 그 비싼 일을 안 하려고 사람들은 자주 방임으로 미끄러진다.
통제는 상시 개입이 아니다. 언제든 들어갈 수 있는 가능성이다. 그 가능성을 유지하는 비용을 안 내려고 손을 놓는 순간 위임은 방임이 된다.
한때 나는 아무것도 모르면서 "위임해야 돼"를 외치고 다녔다. 지금 보면 그건 위임이 아니라 방임의 다른 이름이었다. 위임은 다 파악한 사람이 할 수 있는 최선의 행위다 — 어디까지 권한을 줄지, 어디서 멈출지, 어떤 신호로 다시 들어갈지를 그릴 수 있어야 비로소 형태가 성립하기 때문이다.
그러면 모르는 채로 손을 뗄 길은 아예 없는가. 하나 있다 — 신뢰를 같이 얹는 것. 파악으로 못 채운 자리를 신뢰가 메운다. 위임은 파악 또는 신뢰, 둘 중 적어도 한 축이 받쳐줘야 성립한다. 둘 다 빠진 자리에서 정확히 방임이 발생한다.
방임의 청구서 — 회사 단위로도 같은 일이 일어난다
이건 추상이 아니다. 2026년 5월 조선일보 위클리비즈가 정리한 조사에 따르면, 미국 HR 컨설팅 커리어마인즈가 인사 담당자 600명에게 물었더니 — 지난해 "AI 때문에" 인력 구조조정을 단행한 기업 중 68.3%가 이미 해고했던 직원을 다시 고용했다. 35.6%는 감원 인원의 절반 이상을 되불렀다. "그 결정을 그대로 가져가겠다"는 곳은 8.4%뿐이었다.
이름이 붙은 사례들 —
- 클라르나 — 5,500명을 3,400명으로 줄이고 1,000만 달러를 아꼈다고 자랑했지만, 고객만족도 급락을 맞고 인간 상담원을 다시 들이는 중이다. CEO 본인의 말: "인건비 절감을 위해 AI 기술을 너무 성급하게 도입했다."
- 맥도날드 — 미국 100개 매장 드라이브스루에 AI 주문 시스템을 깔았다가, 버터를 잔뜩 붓고 시키지도 않은 상품을 끼워 넣는 오류가 이어지자 철수.
- 버라이즌 — AI로 대체했던 상담원 자리에 사람을 다시 들이고 있다. 소비자 40%는 여전히 사람과 직접 대화하길 원했다.
응답한 인사 담당자 55%는 "AI를 쓰는 데 예상보다 더 많은 인간의 통찰력이 필요했다" 고 답했다. 포레스터는 그 재고용 비용이 원래 해고에 든 비용의 1.27배라고 추산하고, 가트너는 2027년까지 AI 감원 기업의 절반이 재고용에 들어갈 거라고 본다.
이건 사분면의 우상단이 회사 단위로 청구되는 모습이다. AI가 결과를 내는 것처럼 보이는 동안 통제 라인을 끊었더니, 라인을 다시 잇는 비용이 끊었을 때 아낀 돈보다 컸다. 위임이 비싸다고 방임으로 미끄러진 결정을, 시장과 고객이 청구서로 돌려보낸 셈이다. 그 청구서에는 한 줄이 더 따라온다 — "운영되고 있는 줄 알았는데."
끝그림이 1번이다
위임에 필요한 것 세 가지를 꼽으라면 — 끝그림·권한 경계·중단 조건. 이 셋 중 가장 먼저, 그리고 가장 자주 빠지는 것이 끝그림이다.
끝그림이 없으면 위임 자체가 성립하지 않는다. 비교할 대상이 없어서 잘잘못도 못 가린다. 권한 경계와 보고 라인은 다 그다음이다. 끝그림이 없으면 그 모든 장치는 빈 방의 가구다.
그리고 끝그림은 "이래도 되고 저래도 되고"여서는 안 된다.
모호한 끝그림은 끝그림이 없는 것과 같다. 받는 쪽(사람이든 AI든)은 자기 편한 쪽으로 해석해 버린다. "둘 다 괜찮다"가 진짜라면, 그건 선택지가 좁혀진 끝그림("A 또는 B, 단 C는 아님")이지 비워둔 자리가 아니다. 둘은 다르다.
이건 bootstrap에 썼던 "끝그림과 최소 스펙 사이"와 같은 축이다. 끝그림이 있어야 최소 스펙이 보이고, 부트스트랩이 시작된다. 끝그림 없는 부트스트랩은 그냥 헤매기다.
자기 점검 질문 하나 — 지금 내가 AI에게 주는 지시가 "이래도 되고 저래도 되고"인가? 그렇다면 결과를 평가할 권리도 잃는다.
그래서 — 이 하네스의 끝그림
자기 점검은 나에게도 한다. 내가 쥐고 있는 끝그림은 한 줄이다.
게임개발도, 메이플스토리월드도 잘 모르는 사람이 — 쉽게 입문해서, 재미를 느끼고, 계속 진행해서, 자기 게임을 완성하고, 그 게임으로 수익을 낼 수 있게 한다.
순서가 중요하다. 만드는 일이 먼저, 수익화는 그 위에. 돈을 벌게 해주는 도구로 들리면 본질이 뒤집힌다 — 우리는 만들 수 있게 돕는 도구를 짜고 있고, 만들어진 것이 비로소 팔릴 수 있게 잇는다. 이 순서가 바뀌면 끝그림은 그 자체로 미끄러진다.
한 줄에 여섯 칸이 그어져 있다 — 모름 → 입문 → 재미 → 진행 → 완성 → 수익. 어느 한 칸이 비어도 끝그림이 닫히지 않는다. "입문은 쉬운데 재미가 안 붙더라", "진행은 하는데 완성에 못 닿더라", "완성은 했는데 수익으로 안 이어지더라" — 어느 자리에서 흐름이 끊기든, 끊긴 자리가 곧 하네스가 아직 못 한 일이다.
그러니 첫 단락의 질문 — "이 하네스의 좋고 나쁨을 무엇으로 가릴 것인가" — 은 이렇게 답이 닫힌다. 모르는 사람이 어디에서 막히고, 어디에서 다시 움직이고, 어디서 첫 게임이 완성되고, 그 다음 어디서 첫 결제가 발생하는가. 그 여섯 칸 사이의 마찰이 줄어드는 정도가 곧 하네스의 평가 함수다.
이 끝그림이 있으니까 비로소 하위 질문들이 답을 가질 수 있는 형태로 정렬된다. 어떤 instruction을 쥐여줘야 모르는 사람의 첫 질문이 살가운 답으로 돌아오는가, 어떤 sub-agent에 어디까지 맡겨야 "재미"와 "진행" 사이가 안 끊기는가, 어떤 hook이 수익 전환의 마찰을 미리 잡아내는가. 끝그림 없이 이 질문들을 풀려고 하면 그건 그냥 기능 카탈로그가 된다.
"Harness"라는 말
처음에 이 단어가 자꾸 걸렸다.
Harness는 마구(馬具)다. 멈추게 하는 도구가 아니라 달리게 하면서 방향을 잡는 도구. 굴레와 안장과 고삐가 모두 harness의 일부다.
가두는 도구라면 새장(cage)이라 했을 것이고, 막는 도구라면 가드레일(guardrail)이라 했을 것이다. 그런데 우리는 마구를 짜고 있다. 사람과 AI가 짝을 이뤄 같이 일하기 위한 형식.
어휘가 결정되면 톤이 결정된다. 하네스를 짜는 일은 AI를 작게 만드는 일이 아니다. 같이 멀리 가기 위해 모양을 잡아주는 일이다.
AI 얘기인 줄 알았는데
그 주에 전혀 다른 회의에 들어갔다. AI 이야기가 아니었다. 시범서비스 오픈을 앞두고, 한 영역을 다른 팀에 넘기는 작업 분장 안건이었다.
분장을 먼저 하자는 안과, 기획·명세를 먼저 정리한 뒤에 분장하자는 안이 있었다. 나는 후자 쪽 입장을 적어 보냈다 — "기획·명세가 정리된 상태에서 작업 분장을 진행하는 편이 협업 효율이 높을 것."
회의를 마치고 나오면서 알았다. 이건 똑같은 얘기다.
명세 없는 분장은 "이래도 되고 저래도 되고"의 분장이다. 한쪽은 "그건 너희가 알아서"라고 생각하고, 다른 쪽은 "이렇게 줄지 몰랐지"라고 생각한다. 같은 일에 대해 서로 다른 끝그림을 가지고 분장된다. 그건 위임이 아니라 방임의 분장이다.
위임의 3종 세트 — 끝그림·권한 경계·중단 조건 — 중에 끝그림이 먼저라는 원리는 AI에 한정된 이야기가 아니었다. 사람도 똑같다. 더 정확히는 — 우리가 AI 하네스에서 이제 막 발견하고 있다고 생각한 원리는, 사람을 움직이는 일에서 이미 알려져 있던 원리다.
AI 하네스가 어려운 이유 한 자락은 거기에 있다. 새로운 문제처럼 보이지만 사실 우리는 인간 위임의 오래된 원리를 도구의 언어로 다시 쓰고 있는 중이다.
여기에 출처가 있다. 내가 이 원리를 깊이 이해하게 된 건 결국 사람과 일하면서였다 — 다른 사람의 기획을 받아 구현해 보고, 내 기획을 다른 사람이 구현하는 걸 받아보고, 끝그림이 어긋난 자리에서 무엇이 무너지는지를 여러 번 겪고서야. R&R을 어떤 식으로 짜야 실제로 굴러가는지를 그렇게 한 줌씩 배워왔다 — 어디까지 명세를 명시해 두고, 어디는 비워두며, 어느 자리에 보고 라인을 걸어 두어야 들어가야 할 때 들어갈 수 있는지. 그 배움이 없었으면 AI 하네스의 어디가 비어 있는지를 알아보지도 못했을 것이다. 그리고 같은 배움이, AI agent에게 일을 넘길 때 그대로 굴러간다. 위임의 감각은 도구가 바뀐다고 새로 만들어지는 게 아니다. 사람과 사람 사이에서 익혀온 그 감각이, 사람과 AI 사이에서도 그대로 일하는 자산이 된다.
라벨이 아니라 일감
조직 사이의 R&R도 같은 자리에 있다. "A팀이 제작 영역을 맡는다"는 R&R이 아니라 R&R의 라벨이다. 진짜 R&R은 셋이 같이 있어야 비로소 존재한다.
- Input — 어떤 명세·자산·결정을 받아야 시작할 수 있는가
- Output — 어떤 형태의 산출물·합격 기준·납기로 다음에 넘기는가
- Negative scope — 무엇은 하지 않는가
이 셋이 비어 있으면 라벨만 남는다. 라벨만 있는 R&R은 자동으로 방임으로 미끄러진다. 그래서 다들 라벨만으로 R&R을 정하려고 한다 — 명세를 구체화하는 비용이 비싸기 때문이다. 위임이 비싸다는 자리와 정확히 같은 자리다. 라벨만 정하면 합의된 것처럼 보이고, 일이 안 풀릴 때 누구 책임인지 모호한 것을 모두가 묵계할 수 있다.
오해를 막아 두자. 라벨이 불필요하다는 말이 아니다. 순서가 중요하다 — 라벨이 먼저, 명세가 그 다음. "A팀이 제작 영역을 맡는다"는 라벨이 있어야 비로소 그 안에서 Input·Output·Negative scope를 채워 넣을 자리가 생긴다. 라벨 없이 명세부터 채우려 하면 누구의 일인지 떠 있는 명세가 만들어진다. 잘못된 것은 라벨에서 멈춘 것이지 라벨 자체가 아니다.
AI 하네스 안에서 에이전트끼리의 R&R도 똑같다. "이 에이전트가 검수를 맡는다"는 라벨이다. 진짜 R&R은 어떤 입력 형태로 받아 어떤 판정과 어떤 신호를 다음 단계로 넘기는지의 명세다.
그런데 — 우리에게는 이미 끝그림이 있다. 동작하는 시범 빌드가 그것이다.
전통적인 순서가 아니다. 보통은 기획서 → 명세 → 작업 분장 → 구현인데 이번에는 그 반대가 일어났다. 만들어둔 것이 모호하던 부분을 구체화해 버렸다. 즉 그 자체가 동작하는 기획서(executable spec) 다. 종이 위 명세보다 덜 거짓말한다 — 실제로 굴러가니까 해석의 여지가 줄어들어 있다.
문제는 그다음이다. 시스템 안에만 있는 끝그림은 만든 사람만 읽을 수 있다. 다른 유닛에 넘기려면, 그 끝그림이 판독 가능한 형태로 추출되어야 한다. 이걸 역명세화(reverse-specification)라 부르고 싶다 — 동작하는 결과로부터 일감 단위의 명세를 꺼내는 일.
이게 빠지면 "직접 보면 알아" 모드의 분장이 된다. 동작은 하고 있지만 명시가 안 되어 있는 위임. 그건 잠재적 방임이다.
좋은 하네스의 산출물에는 두 갈래가 있다.
- 실행 결과 — 시스템이 무엇을 했는가
- 읽을 수 있는 명세 — 그래서 그것이 무엇이었는지
동작하는 기획서는 끝그림을 증명한다. 일감은 끝그림을 전달한다. 둘 다 필요하다. 하나만 가지고 위임하면, 그건 다시 방임으로 미끄러진다.
닫음
위임은 비싸다. 끝그림 한 줄을 쓰는 일, 권한 경계를 그리는 일, 중단 조건을 정의하는 일, 그 모두가 비싸다.
그런데 방임은 더 비싸다. 결과가 좋을 때는 안 보이고, 결과가 무너질 때 한꺼번에 청구된다.
AI 하네스를 짜는 일은 결국 — 사람이든 AI든 — 위임의 비용을 제때, 분산해서, 보이게 치르는 형식을 만드는 일이다.
끝그림 한 줄을 쓰는 데 드는 시간이, 결국 가장 적게 드는 시간이다.
아직 포스트잇이 없어요. 첫 자리를 남겨보세요.