title: "위임은 비용을 없애지 않습니다. 옮길 뿐입니다 (땋기판)"
created: 2026-05-18
modified: 2026-05-18
type: permanent
status: draft
author: Yangha Park
description: "Braided A-variant of the delegation-as-cost-transfer column for A/B comparison: same thesis and citation graph, full National Geographic scene/exposition braid, deferred thesis, image-rhymed close. Reference when comparing register against the baseline version."
class: "[[synthesis]]"
hubs:
  - "[[Columns]]" aliases: - "위임은 비용을 없애지 않습니다. 옮길 뿐입니다 (땋기판)" - "위임은 비용을 없애지 않습니다 (땋기판)" tags: - ai/agent - biz/management - src/article

위임은 비용을 없애지 않습니다. 옮길 뿐입니다

2026-05-18

밤 11시, 한 개발자가 화면을 봅니다. 오후에 "기존 거 참고해서 만들어줘"라는 한 줄을 받았고, 지금 그는 만들고 있지 않습니다. 어느 파일이 기준인지 모르니 폴더를 열었다 닫다 하고, 노션을 뒤지고, 작년 문서가 아직 유효한지 메신저로 묻고 답을 기다립니다. 옆 화면에서는 그가 시킨 AI 에이전트가 같은 일을 더 빠르게 하고 있습니다. 닥치는 대로 파일을 읽고, 컨텍스트 창이 무관한 코드로 차오르고, 그럴수록 답은 흐려집니다. 둘 다 일하는 게 아니라 헤매고 있습니다.

"알아서 해줘." 이 한마디는 자율성을 주는 말처럼 들립니다. 그러나 대개는 일을 넘기는 것이 아니라, 일을 할 수 있게 만드는 비용을 통째로 떠넘기는 말입니다.

같은 시간, 옆 팀 마케터는 "관련 자료 보고 캠페인 방향 정리해줘"라는 한 줄을 들여다보고 있습니다. 자료가 어디 있는지, 어느 것이 최신인지, 누구 말이 기준인지 적힌 데가 없어서, 그는 캠페인을 설계하기 전에 먼저 캠페인을 설계해도 되는 조건을 복원하는 중입니다. 담당자를 찾고, 옛 문서를 뒤지고, "이 방향 맞나"를 세 번째 묻습니다.

개발자도, 에이전트도, 마케터도 실행이 아니라 탐색을 하고 있습니다. 그리고 탐색은 공짜가 아닙니다. 모호한 위임은 사라지지 않습니다. 받는 쪽의 비용으로 이름만 바꿔 그 자리에 남습니다.

_{모호한 위임은 사라지지 않습니다. 받는 쪽의 비용으로 이름만 바꿔 남습니다.}

그러니 일을 잘 맡기는 법은 더 좋은 지시문을 쓰는 기술이 아닙니다. 일을 건네기 전에 한 가지를 묻는 습관입니다. 이 모호함의 비용을, 누가, 무슨 통화로 치르게 되는가. 이 질문에 답하지 못한 채 넘긴 일은 없어진 것이 아니라, 받는 쪽 어딘가에 청구서로 쌓입니다.

깔아 둔 대로 따라 합니다

그 개발자가 다음 날 받은 코드를 엽니다. 에이전트는 중복을 충실히 복제했습니다. 코드베이스에 같은 함수가 세 군데 있었으니, 네 번째를 그 자리에 더 만들었을 뿐입니다. 테스트가 없는 코드였으니 테스트 없이 고쳤고, 임시방편이 많았으니 그것을 이 프로젝트의 관습으로 배웠습니다. AI는 기존 코드베이스를 참고한 게 아닙니다. 그 품질을 그대로 증폭했습니다.

받는 쪽은 깔아 둔 것을 따라 합니다. 사람도 다르지 않습니다. 결정이 문서로 남지 않고, 중요한 말은 회의에서만 오가고, 리뷰 기준이 사람마다 다른 조직에서는, 유능한 사람도 평범한 결과를 냅니다. 특히 새로 합류했거나 다른 팀에서 왔거나 그 프로젝트를 처음 보는 사람은 "우리 방식"을 거의 모른다고 보는 게 맞습니다. 개인이 게을러서가 아닙니다. 시스템이 그 결과를 정확히 그렇게 주문했기 때문입니다.

그래서 결과가 나빴을 때 던질 첫 질문은 "누가 못했나"가 아닙니다. "무엇이 이 결과를 주문했나"입니다. 개인 역량 문제가 섞여 있을 수 있습니다. 그러나 시스템 문제는 사람을 갈아 끼워도 같은 자리에서 다시 터집니다.

안 보이면 없는 겁니다

그 마케터가 사흘을 들여 캠페인 방향을 짜 옵니다. 회의에서 한 사람이 말합니다. "그거 작년에 해봤는데 안 됐어요." 그 결론은 어디에도 적혀 있지 않았습니다. 그래서 마케터는 이미 끝난 실험을 처음부터 다시 했고, 그 사흘은 누구의 시간으로도 환불되지 않습니다.

AI에게 보이지 않는 정보는 없는 정보입니다. 사람에게 공유되지 않은 정보도 사실상 없는 정보입니다. "예전에 논의했어요", "다들 아는 내용이에요", "그건 분위기상 안 돼요" — 이런 말이 어디에도 적혀 있지 않으면 새로 온 사람도 모르고, AI는 더더욱 모릅니다. 사람은 그나마 분위기라도 읽지만, AI는 컨텍스트에 없으면 알 방법이 없습니다. 그래서 암묵지를 명시지로 바꾸는 일은 AI를 위한 작업처럼 보여도, 사람에게 똑같이 이득입니다.

그 마케터가 다음 주에 합류한 동료에게 프로젝트를 넘깁니다. 인수인계는 복도에서 이뤄졌습니다. 30분, 구두로. 메모도 없고, 슬랙 스레드도 없고, 문서에 한 줄도 남지 않았습니다. 회의록이라면 참석자라도 물어볼 수 있습니다. 구두 인수인계에는 그것도 없습니다 — 그 맥락은 처음부터 어디에도 존재한 적이 없었던 것과 같습니다. 새 동료에게도 없고, AI 에이전트에게는 더더욱 없습니다. 읽을 것 자체가 없으니까요.

멈출 줄은 사고 전에 매답니다

도요타 공장에는 지도카가 있습니다. 이상이 생기면 기계가 스스로 멈추고, 안돈 보드에 불이 들어와 문제가 즉시 드러나며, 불량은 다음 공정으로 넘어가지 못합니다. 중요한 것은 자동화가 아니라 멈춤이고, 더 중요한 것은 그 멈춤을 가능하게 하는 줄이 사고가 난 뒤가 아니라 작업이 시작되기 전에 미리 매달려 있다는 사실입니다. 멈출 수 있는 통로는 사후에 찾는 것이 아니라, 일을 맡길 때 함께 깔아 두는 것입니다. [1][2]

문제는 대부분의 조직이 그 줄을 매달지 않는다는 데 있습니다. 그 마케터의 팀도 실패를 기록은 합니다. 회고록을 쓰고, 포스트모템을 남기고, "다음엔 잘하자"고 적습니다. 그리고 그 문서는 폴더에서 잠듭니다. 그래서 다음 분기, 다른 사람이 같은 실험을 또 합니다.

Google의 사이트 신뢰성 엔지니어링(SRE)은 그 줄을 매답니다. 포스트모템을 쓰는 데서 끝내지 않고, 검토하고, 조직 저장소에 남기고, 다른 팀이 찾아 배우게 합니다. SRE 책은 그 이유를 한 문장으로 못 박습니다.

Google SRE Book — Postmortem Culture

"An unreviewed postmortem might as well never have existed."
검토되지 않은 포스트모템은, 애초에 존재하지 않은 것이나 다름없다. [3]

그런데 그 줄에는 전제가 하나 있습니다. 사람들이 실패의 진짜 경위를 말해야 한다는 것입니다. 회고가 범인을 찾는 자리가 되는 순간, 사람들은 사고의 진짜 경위를 숨깁니다. 그리고 숨겨진 경위 위에서는 어떤 시스템도 같은 자리에서 다시 부러집니다. Etsy의 존 올스포가 2012년 "Blameless PostMortems and a Just Culture"에서 짚은 지점이 이것입니다. 비난 없는 회고는 착해서가 아니라, 그래야 신호가 위로 올라오기 때문입니다. [4]

핵심은 "실패를 적었는가"가 아니라 "그 실패가 다음 체크리스트·기준·자동화·지표를 바꿨는가"입니다.

flowchart LR
    F["실패 발생"] --> Q{"무엇을 하는가?"}
    Q -->|"그냥 넘긴다"| W["같은 실수 반복<br/>빨라 보이는 비싼 반복 · 낭비"]
    Q -->|"구조를 바꾼다"| L["체크리스트 · 기준 · 지표가 바뀜<br/>학습"]

빈 선반은 누군가의 야근입니다

구조를 바꾸는 것이 실패 뒤의 학습이라면, 구조를 미리 세우는 것은 그 실패가 필요 없게 만드는 일입니다. 속도가 그 준비를 앞지를 때 무슨 일이 벌어지는지, 한 거대 유통업체가 보여 줍니다.

Target은 "2013년 말까지 캐나다에 124개 매장"이라는 공격적 목표로 진출했습니다. 124라는 숫자는 분명한 지시였습니다. 그러나 그 매장을 지탱할 공급망과 재고 시스템은 일이 시작되기 전에 준비되지 못했습니다. 매장은 빠르게 늘었고, 빈 선반과 재고 불일치, 그리고 미국 가격을 기대한 소비자가 마주한 더 높은 가격이 고객 경험을 무너뜨렸습니다. [5]

매장을 몇 개 열었는지는 성과가 아닙니다. 그 매장을 시스템이 지탱했는지가 성과입니다. 빠른 실행은 준비 부족을 잠깐 가릴 뿐, 그 자리를 메워 주지 않습니다. 그리고 그 준비 부족의 비용은 사라지지 않았습니다. 빈 선반 앞에서 발길을 돌린 고객과, 엉킨 재고를 수습하느라 매대 뒤에 남은 직원의 하루로 옮겨갔을 뿐입니다.

누군가 이상하다고 느낄 때만 멈춥니다

이 멈춤 장치에는 함정이 하나 있습니다. 누군가 아직 그것을 문제로 인식하고 있을 때만 작동한다는 것입니다. 규격을 벗어난 무언가를 한 번 받아들이고, 별일 없자 또 받아들이면, 어느새 그것은 예외가 아니라 정상으로 보입니다. 사회학자 다이앤 본은 이것을 일탈의 정상화라고 불렀습니다. [6]

1986년 챌린저호가 그 끝에 있었습니다. 로저스 위원회는 기술적 원인을 추운 날씨에 탄성을 잃은 O링 파손으로 지목했지만, 더 무거운 것은 조직적 원인이었습니다. 사이오콜 엔지니어들은 저온 발사를 우려했지만, 계약사 경영진이 막판 회의에서 발사 권고로 입장을 뒤집었고, 잠재적 문제는 위로 올라가기보다 내부에서 봉합됐습니다. [7] 신호가 없어서가 아닙니다. 규격 이탈이 너무 오래, 너무 자연스럽게 정상으로 취급돼서, 그것을 멈춰야 할 신호로 보는 사람이 남지 않았던 것입니다.

이것이 도요타의 줄과 SRE의 회고가 끝내 답하지 못하는 지점입니다. 멈추는 줄도, 회고도, 누군가 "이건 이상하다"고 느껴야 당겨집니다. 그 감각이 마모되는 것을 막으려면, 규격 이탈을 위로 강제로 끌어올리는 통로를 — 그것이 정상으로 굳기 전에 — 위임의 일부로 미리 설계해 두어야 합니다. 에이전트 시스템에서는 이 마모가 사람보다 훨씬 빠르게 일어납니다.

챗봇이 지어낸 답의 청구서

다시 누군가가 화면 앞에 있습니다. 이번엔 한 항공사 고객입니다. 그는 사별 할인 운임을 챗봇에 물었고, 챗봇은 실제 정책에 없는 "먼저 결제하고 90일 안에 소급 환불받을 수 있다"는 답을 지어냈습니다. 그는 그 말을 믿고 항공권을 샀습니다.

에어캐나다는 고객 응대를 웹사이트 챗봇에 맡겼습니다. 환불은 거부됐고, 회사는 챗봇이 "별개의 법적 실체"라 그 말에 책임질 수 없다고 다퉜습니다. 2024년 브리티시컬럼비아 민사재결심판소(CRT)는 이를 "주목할 만한 주장"이라 부르며 일축했고, 정적 페이지든 챗봇이든 자사 웹사이트의 모든 정보에 회사가 책임진다고 판단했습니다(배상 등 약 812캐나다달러). [8]

검증 통로 없이 맡긴 일의 비용도 사라지지 않았습니다. 처음에는 잘못된 답을 믿은 고객이, 다음에는 배상과 평판으로 회사가 치렀습니다. AGENTS.md도, 사실 확인 단계도, "이 답을 검증한 사람이 있는가"라는 멈춤 줄도 없는 위임 — 그 개발자의 야근, 그 마케터의 사흘과 정확히 같은 구조입니다. 받는 쪽만 바뀌었을 뿐, 비용은 같은 길로 옮겨갑니다.

두 세계, 같은 법칙

여기서 잠깐 멈춰서, 두 세계를 나란히 놓아 봅니다. 한쪽에는 프롬프트와 컨텍스트 창과 코드베이스가 있고, 다른 쪽에는 업무 지시와 시간과 조직 관행이 있습니다. 표면은 전혀 다른데, 빈칸이 생겼을 때 벌어지는 일은 같습니다.

여기가 이 글의 경첩입니다. 처음에는 AI에게 일 시키는 법과 사람에게 일 시키는 법이 별개의 기술처럼 보였습니다. 아닙니다. 하나의 법칙이 두 표면에서 같은 모양으로 나타날 뿐입니다. 빈칸을 비워 두면 AI도 사람도 그 칸을 상상으로 채웁니다. 물론 양쪽이 완전히 같지는 않습니다. 사람에게는 경력과 평판이 걸려 있어 나쁜 소식을 숨길 동기가 있고, AI에게는 그 동기가 없는 대신 분위기를 읽어 빈칸을 메울 능력도 없습니다. '비난 없는 회고'가 사람 쪽에서 작동하고 AI 쪽에서는 말 자체가 무의미한 이유가 거기서 갈립니다. 그러니 표가 말하는 것은 동일성이 아니라 같은 법칙입니다.

그 한마디가 정답일 때

여기서 가장 강한 반론을 정면으로 세웁니다. 때로는 "알아서 해줘"가 정확히 옳은 말입니다. 노련한 사람에게 목표·맥락·기준·권한·검증을 다 못 박아 건네는 것은 그의 판단력을 죽이는 일입니다. 시니어가 자기 방식으로 길을 내는 자유, 정의되지 않은 빈칸을 스스로 메우며 성장하는 자유 — 그 모호함은 비용이 아니라 신뢰와 성장에 대한 의도된 투자입니다. 좋은 리더는 모든 것을 명세하지 않고 일부러 비워 둡니다. 과잉 명세는 사람을 지시 대기자로 만들고, 결국 스스로 판단하지 못하는 의존을 길러 냅니다. 이 반론은 약하지 않습니다. 실제로 많은 유능한 사람이 과잉 관리 아래서 시들고, 적당한 모호함 속에서 자랍니다.

그러나 이 반론은 한 가지를 숨기고 있습니다. 그것이 옹호하는 것은 모호한 위임이 아니라 명확한 위임 안의 넓은 해결 자유입니다. 노련한 사람에게 맡길 때 비워 두어야 하는 칸은 "어떻게 풀 것인가"이지, "무엇이 달라져야 하는가"나 "무엇이 기준인가"가 아닙니다. 목표·기준·검증을 분명히 한 채 해결 방식을 통째로 맡기는 것 — 그것이 바로 신뢰 투자이고 성장의 공간입니다. 반대로 목표가 흐리고 기준이 사후에 바뀌는 모호함은 신뢰가 아니라 방치입니다. 그 안에서 시니어가 키우는 것은 판단력이 아니라, "이 방향 맞나"를 묻고 다니는 정치적 감각입니다. 신뢰 투자라는 말은 옳습니다 — 단, 무엇을 비우고 무엇을 못 박을지 정확히 알 때만. 비울 칸과 비워선 안 될 칸을 구분하지 못한 채 던지는 "알아서"는 투자가 아니라, 이 글 내내 보아 온 그 청구서입니다.

자율을 뺏는 게 아니라 추측을 줄입니다

그래서 자세히 지시하면 상대의 자율성을 빼앗는 것 같다는 흔한 불안은 절반만 맞습니다. 대부분의 경우 필요한 것은 자율성을 거두는 일이 아니라 불필요한 추측을 거두는 일입니다. 그 개발자가 밤 11시에 쓴 에너지는 문제를 푸는 데가 아니라, 어느 파일이 기준인지 추측하는 데로 샜습니다. 좋은 지시는 그 추측을 거둘 뿐, 자유를 없애지 않습니다.

나쁜 자유는 받는 쪽이 어디서부터 봐야 할지, 누구 말이 기준인지, 어떤 문서가 최신인지, 어디까지 손대도 되는지, 나중에 어디서 혼날지를 전부 알아서 판단해야 하는 자유입니다. 이건 자율이 아니라 방치에 가깝습니다. 좋은 자유는 목표가 분명하고, 제약이 분명하고, 성공 기준이 분명하고, 참고할 것이 정리돼 있고, 그 안에서 해결 방식은 온전히 맡기는 자유입니다.

창의성은 경계가 없을 때가 아니라 경계가 분명할 때 나옵니다. 무엇이 고정이고 무엇이 열려 있는지 모르는 사람은 새것을 만들지 못합니다. 열린 자리가 어디인지 아는 사람만이 거기에 힘을 모을 수 있습니다. 좋은 위임이 줄이는 것은 창의의 공간이 아니라, 창의에 닿기도 전에 추측으로 새어 나가는 비용입니다.

다섯 기둥을 미리 세웁니다

_{지시는 한 줄이면 되지만, 시스템은 이 다섯 기둥을 미리 세워야 합니다.}

여기까지의 장면들은 모두 시스템이 없을 때 무슨 일이 벌어지는지를 보여 줍니다. 그 장면들을 그대로 뒤집으면, 일을 맡기기 전에 깔아 두어야 할 목록이 됩니다. 목표가 빠지면 "무엇을 만들지"는 채워도 "무엇이 달라져야 하는지"가 비어 바쁘기만 합니다. 맥락이 빠지면 받는 쪽이 실행 전에 최신본부터 탐색합니다 — 그 마케터의 사흘처럼. 기준이 빠지면 성공이 일 끝난 뒤에 정의되고, 피드백이 함정이 됩니다. 권한이 빠지면 결정마다 멈춰 묻거나, 묻지 않고 잘못 갑니다. 검증이 빠지면 문제가 정상으로 굳을 때까지 아무도 줄을 당기지 않습니다 — 챌린저호처럼, 그 챗봇처럼.

이론은 단순한데 현장은 늘 같은 데서 미끄러집니다. 그래서 두 개의 실물 도구를 둡니다. 하나는 일을 맡길 때, 하나는 실패한 다음에.

나쁜 요청 — 받는 쪽이 탐색부터 해야 합니다

• "관련 자료 보고 캠페인 방향 정리해줘."

• "기존 거 참고해서 제안서 만들어줘."

• "AI한테 맡겨서 초안 뽑아봐."

좋은 요청 — 탐색할 것이 거의 남지 않습니다

"이번 목표는 신규 고객의 첫 구매 전환율을 높이는 것입니다. 타깃은 최근 30일 내 가입했지만 구매하지 않은 사용자입니다. 참고 자료는 A와 B이고, C는 예전 방향이라 배경용으로만 보면 됩니다. 성공 기준은 클릭률이 아니라 구매 전환율입니다. 금요일 오전까지 메시지 가설 3개와 각 가설의 리스크를 정리해 주세요. 수요일에 방향만 먼저 확인합시다."

실패한 다음, 순서대로 묻습니다

1. 무슨 결과를 기대했고, 실제 결과는 무엇이었는가?

2. 실패를 뒤늦게 알았는가, 중간에 알 수 있었는가?

3. 목표·타깃·기준·권한·일정 중 무엇이 불명확했는가?

4. 자료나 컨텍스트에 최신이 아닌 것이 섞여 있었는가?

5. 이번 실패에서 다음에 재사용할 학습은 무엇인가?

6. 체크리스트·템플릿·리뷰 기준·자동화·지표 중 무엇을 바꿀 것인가?

7. 그 변화가 결과를 실제로 개선했는지 어떻게 확인할 것인가?

AI에게 일을 잘 시키는 법은 프롬프트를 예쁘게 쓰는 기술에서 좋은 하네스를 짓는 일로 옮겨가고 있습니다. 사람에게 일을 잘 시키는 법도 정확히 같은 궤적입니다. 좋은 리더는 말을 잘하는 사람이 아니라, 상대가 좋은 판단을 할 수 있는 환경을 미리 깔아 두는 사람입니다.

닫으며

다시 밤 11시입니다. 다른 개발자가 화면을 봅니다. 오늘 그가 받은 것은 한 줄이 아니라, 무엇이 달라져야 하는지·어느 문서가 기준인지·어디까지 손대도 되는지·금요일 전에 무엇을 검증할지가 적힌 한 문단입니다. 폴더를 열고 닫는 대신, 그는 곧장 문제로 들어갑니다. 옆 화면의 에이전트도 더 이상 컨텍스트 창을 잡음으로 채우지 않습니다 — 무엇이 기준인지 이미 적혀 있으니까. 같은 시각, 같은 책상, 같은 한 줄이 들어갈 자리. 달라진 것은 그 자리에 무엇을 깔아 두었는가 하나뿐입니다.

그러니 다음에 누군가에게 — AI든 사람이든 — "알아서 해줘"라고 말하기 전에, 한 번만 물으십시오. 이 모호함의 비용을, 누가, 무슨 통화로 치르게 되는가.

참고자료

[1] Toyota Motor Corporation, "Toyota Production System." https://global.toyota/en/company/vision-and-philosophy/production-system/
[2] Toyota Motor Manufacturing UK, "Jidoka." https://www.toyotauk.com/toyota-in-the-uk/how-we-manufacture/jidoka
[3] Google SRE Book, "Postmortem Culture: Learning from Failure." https://sre.google/sre-book/postmortem-culture/
[4] John Allspaw, "Blameless PostMortems and a Just Culture," Etsy Code as Craft, 2012. https://www.etsy.com/codeascraft/blameless-postmortems
[5] Joe Castaldo, "The Last Days of Target Canada," Canadian Business, 2016. https://canadianbusiness.com/ideas/the-last-days-of-target-canada/ (재수록: Maclean's https://macleans.ca/economy/economicanalysis/off-target-how-a-u-s-retail-giant-misread-the-canadian-market/)
[6] Diane Vaughan, The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, University of Chicago Press, 1996.
[7] Report of the Presidential Commission on the Space Shuttle Challenger Accident (Rogers Commission), 1986 — Vol. I, Ch. IV "The Cause of the Accident"(O링 물리적 원인, https://www.nasa.gov/history/rogersrep/v1ch4.htm) 및 Ch. V "The Contributing Cause of the Accident"(조직적 의사결정 결함, https://www.nasa.gov/history/rogersrep/v1ch5.htm).
[8] Moffatt v. Air Canada, 2024 BCCRT 149, British Columbia Civil Resolution Tribunal, 2024-02-14 — 웹사이트 챗봇의 잘못된 안내에 회사가 책임진다고 판단(과실 부실표시, 약 812캐나다달러). https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html · 보도: CBC News, 2024-02-16 https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416