왜 「AI가 할 수 있다면 맡기면 된다」로 실패하는가

솔직하게 말씀드릴게요. 지난 1년 동안 AI에게 맡길 수 있는 업무량이 엄청나게 늘어났죠. 코드도, 조사도, 문장도, 테스트도, 리뷰까지. 그래서 왠지 모르게 이렇게 생각하고 계시지 않나요? "AI가 할 수 있는 일은 전부 AI에게 맡기는 게 좋다"라고.

저도 처음에는 그렇게 생각했습니다. 하지만 말이죠, 이것만으로는 꽤 높은 확률로 사고가 터집니다.

흔히 발생하는 패턴은 두 가지입니다. 하나는 AI가 할 수 있음에도 "직접 하는 게 더 빨라"라고 말하며 결국 전부 스스로 떠안는 패턴. 다른 하나는 그 반대로, 무엇이든 전부 AI에게 통째로 넘겼다가 운영 데이터베이스를 실수로 망가뜨리거나, 정신을 차려보니 자신의 프로덕트 방향성까지 AI가 결정해 버린 듯한 패턴입니다.

왜 이렇게 되는 것 같나요?

이유는 간단합니다. 판단의 축이 「AI가 할 수 있는가(능력)」가 되어 있기 때문입니다. 하지만 말이죠, 맡길지 말지는 사실 능력으로 결정되지 않습니다. 「자신의 시간을 어디에 써야 하는가」로 결정되는 것이죠. 이것은 경제학에서 비교 우위 (Comparative Advantage)와 기회비용 (Opportunity Cost)이라고 불리는 개념인데, 사실 AI 시대의 업무 분담에 엄청나게 효과적입니다.

이 기사의 목표는 「기합과 기분에 따라 맡길지 직접 할지를 결정하던 상태」를 졸업하여, 6가지 축과 코드로 담담하게 분류할 수 있게 되는 것입니다. 다 읽고 나면, 오늘 밤 당신의 태스크를 하나 분류해 보고 싶어질 것입니다. 그럼 시작해 볼까요.

비교 우위와 기회비용 — 경제학이 가르쳐주는 「맡기는 법」의 정답

먼저, 두 가지만 기억해 주세요. 이것만 제대로 이해하면 나머지는 응용입니다.

첫 번째는 기회비용 (Opportunity Cost)입니다. 이것은 「무언가를 한다는 것 = 다른 무언가를 포기하는 것」이라는, 당연하지만 놓치기 쉬운 이야기입니다. 예를 들어, 당신이 2시간을 들여 정형화된 작업을 했다고 가정해 봅시다. 그 2시간은 「무료」가 아닙니다. 같은 2시간 동안, 당신만이 만들 수 있는 프로덕트의 설계를 할 수도 있었을 것입니다. 그 「포기한 쪽의 가치」가 바로 기회비용입니다.

즉, 스스로 하는 작업의 진짜 비용은 투입된 시간 그 자체가 아니라, 그 시간에 할 수 있었던 가장 가치 있는 업무입니다. 이 점을 놓치면 「직접 하면 0원」이라는 착각에 빠져, 자신도 모르는 사이에 비싼 대가를 치르고 있는 셈이 됩니다.

두 번째는 비교 우위 (Comparative Advantage)입니다. 이것은 조금 흥미로우면서도 직관에 반하는 내용입니다.

흔히 하는 오해는 이렇습니다. "내가 AI보다 잘한다면, 내가 직접 해야 한다". 하지만 아닙니다. 설령 당신이 그 작업에서 AI보다 뛰어나더라도, 당신의 시간을 더 가치 높은 업무에 사용할 수 있다면, 그 작업은 AI에게 맡기는 것이 전체적으로 이득입니다.

가까운 예로 들어볼까요. 실력 있는 요리사가 있다고 합시다. 그 사람은 설거지도 초보자보다 빠르고 깔끔하게 한다고 가정해 봅시다. 하지만 그 사람이 설거지를 하는 동안에는 아무도 요리를 만들 수 없습니다. 그렇다면 설거지는 아르바이트생에게 맡기고, 자신은 요리에 전념하는 것이 가게 전체의 가치를 높이는 길이죠. 이것이 비교 우위입니다. 「절대적으로 못하는 쪽에게 맡기는 것」이 아니라, 「자신의 시간이 가장 빛을 발하는 곳에 자신을 두는 것」이라는 사고방식입니다.

여기서 AI를 「설거지 아르바이트생」에 대입하면 이렇게 됩니다. 당신의 비교 우위, 즉 「당신만이 낼 수 있는 가치」는 무엇인가. 그것을 파악하여 그곳에 자신의 시간을 집중한다. 그 외에는 AI에게 흘려보낸다. 이것이 AI 시대 업무 분담의 가장 기초가 되는 원리입니다.

그렇다면 당신의 비교 우위는 무엇일까요? 대략 이 정도일 것입니다. 무엇을 만들 것인가·왜 만드는가에 대한 결정. 유저나 동료와의 관계성. 취향·미학·최종적인 판단. 다시 말하자면, What과 Why는 인간이 쥐고, How는 AI에게 맡기는 방식입니다.

「맡길 것인가/직접 할 것인가」를 판정하는 6가지 축

원리는 이해했습니다. 하지만 실무에서는 「그래서 이 태스크는 어떻게 하지?」라는 질문이 매번 나옵니다. 그래서 판정을 6가지 축으로 분해합니다. 각 축을 0~3점으로 대략 점수화하기만 하면 됩니다. 완벽한 숫자가 아니어도 괜찮습니다. 나열해서 비교할 수 있으면 충분합니다.

이 중에서도 특히 효과적인 것이 verifyCost (검증 비용)와 reversibility (가역성)입니다. 생소한 용어이므로 설명해 드리겠습니다.

검증 비용 (verifyCost)이란 AI가 내놓은 결과물이 옳은지 확인하는 데 드는 수고를 말합니다. 예를 들어 "이 함수의 테스트 코드를 작성해줘"라고 한다면, 테스트가 통과하는지만 보면 되므로 즉시 확인할 수 있습니다. 즉, 검증 비용이 낮습니다. 하지만 "이 긴 글의 사실관계가 전부 맞는지 확인해줘"라고 한다면, 하나씩 사실 확인(fact-check)을 해야 하므로 검증 비용이 매우 높습니다. 검증이 무거운 태스크는 AI에게 맡겨도 결국 당신의 시간을 잡아먹게 됩니다.

가역성 (reversibility)이란 실수했을 때 얼마나 쉽게 되돌릴 수 있는지를 의미합니다. 코드 변경은 git으로 되돌릴 수 있으므로 가역성이 높습니다. 하지만 운영 데이터베이스(production database) 삭제, SNS 게시물 공개, 결제 처리 등은 한 번 실행하면 되돌릴 수 없습니다. 가역성이 제로(0)인 셈입니다.

이 6가지 축을 바탕으로 태스크를 4가지 목적지로 분류합니다.

• KEEP (직접 수행): myEdge (나의 비교 우위)가 높거나, AI에게는 아직 벅찬 일. 자신의 시간을 여기에 쓰는 것이 가장 리턴(return)이 높습니다.
• DELEGATE (위임): AI가 잘하며, 실수하더라도 저렴하게 되돌릴 수 있는 일. 기분 좋게 통째로 맡깁니다.
• DELEGATE_WITH_GATE (위임하되 인간 게이트 설치): AI에게 시키되, 되돌릴 수 없거나 확인 작업이 무거우므로 마지막 실행 버튼은 인간이 누릅니다.
• AUTOMATE (자동화): 특기 × 반복 × 안전. 절차를 시스템화하여, 미래의 내가 두 번 다시 손대지 않도록 만듭니다.

코드로 판정을 흔들리지 않게 만들기 (TypeScript + YAML 장부)

축이 결정되었다면 판정 로직을 코드로 만들어 버립시다. 머릿속으로만 생각하면 그날의 기분에 따라 판정이 흔들리기 마련입니다. 코드로 만들어 두면 자신과 AI 모두에게 동일한 기준을 전달할 수 있습니다.

먼저 판정 로직 본체입니다. 0~3 사이의 스코어를 받아 목적지를 반환하는 단순한 함수입니다.

// 태스크 하나를 "어떻게 다룰 것인가"를 판정하는 최소 단위의 함수.
// 스코어는 0(낮음)~3(높음) 사이의 주관적 평가로 충분함. 완벽한 수치보다는 "나란히 놓고 비교하는 것"이 목적.
type Score = 0 | 1 | 2 | 3;
...

포인트는 가장 먼저 myEdge (나의 비교 우위)를 체크한다는 점입니다. 능력이 아니라 "나만이 낼 수 있는 결과인가"를 먼저 살핍니다. 이 순서가 오늘 가장 강조하고 싶은 부분입니다.

다음으로, 판정한 태스크를 장부 파일에 쌓아 나갑니다. 이것을 AI에게도 읽게 하면, AI가 멋대로 "직접 쥐고 있어야 할 일"에 손을 대지 않게 됩니다. 소소하지만 효과적입니다.

# delegation-ledger.yml
# "무엇을 맡기고 무엇을 직접 할 것인가"를 인간과 AI가 공유하는 장부.
tasks:
...

마지막으로 기회비용을 숫자로 확인하는 함수도 하나 추가합니다. 이것이 있으면 "직접 하는 게 더 빠르다"라는 착각에서 벗어날 수 있습니다.

// 기회비용: 해당 작업을 직접 수행할 때의 "진정한 비용"은,
// 같은 시간 동안 할 수 있었던 가장 가치 있는 일(=포기한 것).
interface DoItYourself {
...

"직접 하면 실질적으로 공짜"가 아니라, "직접 하면 20의 가치를 버리고 있다"라고 보이게 되면 판단이 달라질 것입니다.

DELEGATE_WITH_GATE를 시스템으로 강제하고 싶은 분들에게 (GitHub Actions 예시)

인간 게이트는 "주의하자"라는 다짐만으로는 부족합니다. CI(지속적 통합)로 강제하십시오. 위험 라벨이 붙은 PR(Pull Request)은 인간의 승인 없이 머지(merge)할 수 없도록 만드는 예시입니다.

# .github/workflows/delegation-gate.yml (예시)
on: pull_request
jobs:
...

AI에게 "위임 방법"을 상담하는 3가지 프롬프트

판정 자체를 AI에게 도움받을 수도 있습니다. 단, 중요한 규칙이 하나 있습니다. 최종 판단은 인간이 내립니다. AI에게는 "재료를 준비하는 역할"을 맡기고, 결정은 우리가 합니다. 특히 되돌릴 수 없는 작업은 AI가 자동으로 결정하게 해서는 안 됩니다. 이것만은 꼭 지켜주세요.

첫 번째는 태스크를 6가지 축으로 추산하게 하는 위임 트리아지 (delegation triage) 프롬프트입니다.

당신은 태스크 위임 설계를 돕는 리뷰어입니다. 단정적인 결론이나 최종 결정은 내리지 마십시오.
다음 태스크에 대해, 아래 6가지 축을 각각 0~3 사이로 추산하고 그 근거를 한 줄씩 덧붙여 주세요.
- aiCapability (현재 AI가 얼마나 잘 수행할 수 있는지)
...

두 번째는 기회비용을 언어화하는 프롬프트입니다. "직접 하면 무엇을 포기하게 되는가?"를 솔직하게 출력하도록 합니다.

나는 이 태스크를 직접 수행하려고 합니다: "{태스크}". 직접 수행하면 약 {N}시간이 소요됩니다.
내가 지금 가장 시간을 투입해야 할 최우선 과제는 "{최우선 태스크}"입니다.
다음 내용을 출력해 주세요.
...

세 번째는 검증 비용 (Verification Cost) 자체를 낮추는 프롬프트입니다. "확인이 번거로워서 맡길 수 없다"를 "확인을 가볍게 만들어 맡길 수 있다"로 바꾸는 방법입니다. 이것이 은근히 가장 효과적입니다.

저는 이 태스크를 AI에게 맡기고 싶지만, 출력이 올바른지 확인하는 과정이 번거로워 완전히 맡기지 못하고 있습니다:
"{태스크}".
"검증 비용 (Verification Cost)을 최대한 낮출 수 있는 검증 방법"을 설계해 주세요.
...

세 번째 프롬프트의 이면에 있는 사고방식이 꽤 본질적입니다. 맡기지 못하는 이유가 "검증 비용의 높음"이라면, 검증을 시스템으로 가볍게 만듦으로써 맡길 수 있는 범위를 넓힐 수 있습니다. 능력이 부족한 것이 아니라, 확인 설계 (Verification Design)가 부족한 경우가 많기 때문입니다.

빠지기 쉬운 함정과 철수 라인

이 방식에도 빠지기 쉬운 함정이 분명히 있습니다. 미리 알고 있으면 사고를 줄일 수 있으므로 솔직하게 나열하겠습니다.

그리고 일단 맡긴 후의 철수 라인 (Withdrawal Line)도 정해둡시다. 맡겨만 두고 그대로 방치하는 것이 가장 위험하기 때문입니다.

• 검증 과정에서 2회 연속으로 사고가 발생한 종류의 태스크는 DELEGATE에서 DELEGATE_WITH_GATE로 되돌린다.
• 맡긴 결과, 자신이 내용을 전혀 설명할 수 없게 된 핵심 영역 (Core Domain)은 다시 직접 쥐어야 한다 (학습 가치가 높은 곳이었다는 뜻).
• "확인하는 데 시간이 더 걸린다"고 느껴지면, 검증 하네스 (Verification Harness)에 투자하거나 일단 다시 직접 쥐어야 한다.

역할 분담을 한 장으로 정리하면 다음과 같습니다. 고민될 때는 이 표로 돌아오세요.

세로로 보면 알 수 있듯이, 인간 측은 전부 "판단 (Judgment)"입니다. AI 측은 전부 "실행 (Execution)"입니다. 경계선을 여기에 그으면 대체로 틀리지 않습니다.

요약: 쥐어야 할 것을 결정하면, 맡기는 것이 두렵지 않다

내용이 길어졌으니 핵심만 요약하겠습니다.

맡길지 말지는 "AI가 할 수 있는가"로 결정되지 않습니다. "자신의 희소한 시간을 어디에 써야 하는가"로 결정됩니다. 이것이 기회비용 (Opportunity Cost)의 발상입니다. 그리고 설령 자신이 더 잘하더라도, 자신의 시간이 더 가치 있게 쓰일 곳이 있다면 맡기는 것이 이득입니다. 이것이 비교우위 (Comparative Advantage)의 발상입니다. 이 두 가지를 토대로 6개 축에 따라 KEEP / DELEGATE / DELEGATE_WITH_GATE / AUTOMATE로 분류하고, 그 판정을 코드와 장부에 기록합니다. 맡기는 것에 대한 상담은 AI에게 해도 되지만, 최종 판단과 위험한 조작에 대한 승인은 인간이 쥐어야 합니다.

여기서 잠시 삶에 대한 이야기를 해보겠습니다. 가용 시간이 적은 사람일수록 사실 기회비용이 높습니다. 1시간의 무게가 다르기 때문입니다. 그렇기에 더욱 쥐어야 할 것을 좁히고, 나머지는 과감하게 AI에게 흘려보내는 의미가 있습니다. 쥐어야 할 것, 즉 자신의 비교우위는 무엇을 만드는가, 왜 만드는가, 취향, 관계성, 판단입니다. 여기에 자신을 둡니다. 반복되는 작업은 시스템화하여 미래의 자신이 다시는 건드리지 않아도 되는 상태로 만들어 둡니다. 이것은 내일의 나에게 주는 작은 선물입니다.

마지막으로 하나 더. 맡기는 것이 두렵다는 감각, 다들 있으시죠? 하지만 그것은 아마 "쥐어야 할 것이 모호하기 때문"일 것입니다. 자신이 무엇을 쥐고 있는지를 명확히 결정하면, 그 외의 것들은 안심하고 내려놓을 수 있습니다. 쥐어야 할 것을 결정하는 작업은, 내려놓기 위한 작업이기도 합니다.

오늘 밤의 첫걸음은 이것만으로 충분합니다. 당신의 태스크를 하나 떠올리고, 6개 축에 대해 0~3점으로 점수를 매겨 4가지 중 어디에 속하는지 결정해 보세요. 30분도 걸리지 않을 것입니다. 내일의 당신이 "미리 해줘서 고마워요"라고 말할 만한 것이 아마 이것일 겁니다. 시작해 볼까요.

참고 링크

• David Ricardo, "On the Principles of Political Economy and Taxation" (비교우위의 원전): https://www.econlib.org/library/Ricardo/ricP.html
• Investopedia, "Opportunity Cost" (기회비용 입문): https://www.investopedia.com/terms/o/opportunitycost.asp
• Anthropic, "Building effective agents" (인간과 AI의 분업·위임 설계): https://www.anthropic.com/research/building-effective-agents
• GitHub Docs, "About required reviews for pull requests" (인간 게이트 구현): https://docs.github.com/en/pull-requests

Discussion