Skip to content
←

Split View: AI 도구와 일하는 법을 하나의 기술로 — 위임 기준과 검증 절차

✨ Learn with Quiz
|

AI 도구와 일하는 법을 하나의 기술로 — 위임 기준과 검증 절차

잘 쓴다는 말이 비어 있는 이유

도구를 잘 쓴다는 말은 그 자체로는 정보가 없습니다. 무엇을 맡겼는지, 결과가 맞았는지 어떻게 확인했는지, 틀렸을 때 무엇으로 돌아갔는지가 빠져 있기 때문입니다. 이 세 가지가 빠진 채로는 잘 쓴 것과 운이 좋았던 것을 구별할 수 없습니다.

그래서 이 편은 도구 이야기를 하지 않습니다. 어떤 제품이 어떤 제품보다 낫다는 이야기는 6개월이면 낡고, 낡지 않는 것은 일하는 방식입니다. 다룰 것은 세 가지입니다. 어디까지 맡길지 정하는 기준, 받은 결과를 판정하는 절차, 그리고 그 두 가지를 안 했을 때 생기는 손해입니다.

위임의 선은 난이도가 아니라 검증 비용이 긋습니다

흔한 기준은 쉬운 일은 맡기고 어려운 일은 직접 한다는 것입니다. 이 시리즈의 판별식으로 보면 이 기준은 축을 잘못 잡았습니다. 위임 가능성을 정하는 것은 만드는 비용이 아니라 판정하는 비용입니다.

세 가지를 대 보면 직관이 몇 개 뒤집힙니다.

  • 까다로운 정규식 하나: 만들기는 성가시고 판정은 쌉니다. 예시 열 개면 맞았는지 압니다. 맡기기 좋은 쪽입니다.
  • 설정값 하나 바꾸기: 만들기는 거의 공짜인데 판정은 비쌀 수 있습니다. 잘못된 값은 운영에서 몇 주 뒤에 드러납니다.
  • 데이터 마이그레이션 스크립트: 만들기는 쉬워 보이고 되돌리기는 어렵습니다. 판정 비용이 사실상 최대입니다.

세 번째가 핵심입니다. 되돌릴 수 없는 작업은 생성이 아무리 싸도 위임의 후보가 아닙니다. 되돌릴 수 있느냐는 난이도와 아무 상관이 없고, 그래서 난이도로 선을 그으면 정확히 이 칸에서 사고가 납니다.

맡기기 전에 적는 네 줄

기준을 실제 작업에 적용하는 방법은 단순합니다. 맡기기 전에 네 줄을 적습니다.

예시 — 위임 카드 네 줄

맡길 것:    결제 실패 재시도 로직의 초안
판정 방법:  기존 통합 테스트 + 중복 청구 시나리오 3개를 내가 직접 추가
되돌리기:   기능 플래그 뒤에서 동작. 끄면 이전 경로로 복귀
안 맡길 것: 재시도 상한과 멱등 키 설계. 틀리면 돈이 두 번 나감

네 줄을 적는 데 2분이 걸립니다. 값어치는 두 번째 줄과 네 번째 줄에 있습니다. 판정 방법이 안 써지면 그 작업은 아직 맡길 준비가 안 된 것이고, 안 맡길 것이 비어 있으면 대개 경계를 안 그은 것입니다.

결과를 판정하는 절차

받은 결과를 다루는 데서 가장 흔한 실패는 읽는 순서입니다. 결과를 먼저 읽으면 사람은 그 결과를 기준으로 자기 기대를 다시 만듭니다. 결과가 그럴듯할수록 이 덮어쓰기는 강해집니다.

순서를 바꿉니다. 열기 전에 기대를 세 줄 적습니다. 어떤 파일이 바뀌어야 하는가, 어떤 경계 조건이 다뤄져야 하는가, 무엇이 바뀌면 안 되는가. 그다음 결과를 열고 대조합니다. 목록에 없던 변경이 첫 번째 질문거리입니다.

두 번째는 통과를 근거로 삼지 않는 것입니다. 4편에서 초록불은 그 자체로 아무것도 뜻하지 않는다고 했습니다. 여기서는 더 그렇습니다. 결과물과 그것을 검사할 테스트를 같은 곳에서 받으면 판정 대상과 판정 기준이 같은 출처에서 나옵니다. 경계 조건 하나는 반드시 손으로 넣어야 합니다.

세 번째는 설명을 요구하되 증거로 세지 않는 것입니다. 왜 이렇게 했는지에 대한 매끄러운 답은 언제나 나오고, 매끄러움과 정확성의 상관은 약합니다. 설명은 어디를 확인할지 정하는 데 쓰고, 확인 자체는 실행과 로그로 합니다.

오히려 느려지는 자리

체감은 이 영역에서 특히 못 미덥습니다. METR이 2025년 7월에 공개한 무작위 대조 실험이 그 예입니다. 자기 오픈소스 저장소에 익숙한 개발자 16명이 246개 작업을 수행했고 작업마다 도구 사용 허용 여부가 무작위로 배정됐습니다. 허용된 쪽이 19퍼센트 더 오래 걸렸고, 참가자들은 사전에 24퍼센트 빨라질 것이라 예상했으며 실험 후에도 20퍼센트 빨라졌다고 믿었습니다.

일반화하면 안 됩니다. 연구진 스스로 이 결과가 대부분의 개발자가 느려진다는 증거는 아니며, 다른 환경이나 더 숙련된 사용에는 적용되지 않을 수 있다고 밝혔습니다. 표본은 16명입니다. 다만 조건 하나는 눈에 띕니다. 참가자들은 자기가 오래 다룬 저장소에서, 품질 기준이 높은 상태로 일했습니다. 검증 비용이 원래 높은 환경이었다는 뜻입니다.

Stack Overflow가 2025년에 공개한 개발자 설문도 같은 쪽을 가리킵니다. 가장 큰 불만으로 거의 맞지만 정확히는 맞지 않은 해답을 꼽은 응답이 66퍼센트였고, 45.2퍼센트가 생성된 코드의 디버깅에 시간이 더 든다고 답했습니다. 정확성에 대해서는 어느 정도 이상 불신한다는 응답이 45.7퍼센트로 신뢰한다는 32.7퍼센트보다 많았습니다. 설문은 체감의 기록이지 성과의 측정이 아니므로, 읽을 수 있는 것은 사람들이 어디에 시간을 쓴다고 보고하는지까지입니다.

여기서 반복되는 패턴을 정리하면 네 가지입니다. 검증 비용이 높은 영역에 위임을 늘리는 것, 거의 맞는 결과를 고치는 시간을 과소평가하는 것, 이해를 건너뛰고 넣은 코드가 몇 달 뒤 디버깅 대상이 되는 것, 그리고 생산량이 팀의 검토 용량을 넘어서는 것입니다. 마지막 것이 가장 조용하게 진행됩니다.

아직 정해지지 않은 것

정직하게 적자면 이 영역에서 확실한 것은 많지 않습니다. 확실한 쪽은 두 가지입니다. 생성 비용이 크게 떨어졌다는 것, 그리고 검증 비용이 같이 떨어지지는 않았다는 것입니다.

나머지는 열려 있습니다. 어떤 종류의 작업에서 순이득이 나는지, 숙련이 쌓이면 결과가 뒤집히는지, 조직 차원에서 무엇이 달라지는지는 아직 답이 정해지지 않았습니다. 이 자리에서 확신에 찬 문장을 파는 쪽은 대개 무언가를 팔고 있거나 겁을 주고 있습니다.

그래서 개인이 할 수 있는 가장 합리적인 일은 자기 기록을 갖는 것입니다. 자기 작업에 대해서는 표본이 자기 자신이고, 그 표본은 남의 평균보다 자기에게 정확합니다.

직접 해보기

이번 주에 맡긴 작업 세 개를 고르고, 각각에 대해 결과가 맞는지 확인하는 데 실제로 몇 분을 썼는지 적어 보세요. 만드는 시간이 아니라 판정하는 시간입니다. 이 숫자가 자기 위임의 선을 알려 줍니다. 판정에 만드는 시간보다 오래 걸린 작업이 있다면, 그 종류는 다음부터 직접 하는 편이 빠릅니다.

  • 하네스 엔지니어링 RPG — 모델은 고정 입력으로 두고 그 주위의 도구·정지 조건·권한·평가자를 설계하는 27개 시나리오입니다. 약한 평가자가 그 아래 모든 것의 상한이 된다는 것을 디브리핑으로 확인하게 됩니다. 이 글의 판정 절차와 같은 구조입니다.
  • 논리법 훈련소 — 필요조건과 충분조건을 가르고 남의 논증을 정확히 재구성하는 연습입니다. 그럴듯한 설명을 증거로 세지 않는 훈련에 가장 가깝습니다.

안 통하는 경우도 적어 둡니다. 지금 배우고 있는 영역에서는 이 기준을 반대로 써야 합니다. 판정이 싸서 맡겨도 되는 작업이라도, 그것이 자기가 지금 익히려는 기술이라면 직접 하는 편이 낫습니다. 3편에서 적었듯 읽고 쓰는 연습 기회는 저절로 생기지 않고, 위임은 그 기회를 가장 먼저 가져갑니다.

이어서 읽기

비싸게 남는 기술 시리즈

참고 자료

  • Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 2025-07-10 — 개발자 16명, 작업 246개의 무작위 대조 실험. 19퍼센트 지연, 사전 예상 24퍼센트 단축, 사후 체감 20퍼센트 단축, 그리고 이 결과가 대부분의 개발자에게 일반화되지 않는다는 저자들의 명시적 단서가 여기서 나옵니다. 2026-08-15 확인.
  • Stack Overflow Developer Survey 2025 — AI — 거의 맞는 해답 66퍼센트, 디버깅 시간 증가 45.2퍼센트, 정확성 불신 45.7퍼센트 대 신뢰 32.7퍼센트. 2026-08-15 확인.
  • 위임 카드 네 줄, 판정 절차의 세 단계, 느려지는 네 가지 패턴은 위 자료에 나오는 것이 아니라 이 글에서 정리한 것입니다.

Working With AI Tools as a Skill — Where the Delegation Line Sits and How to Verify

Why "Good With the Tools" Is an Empty Phrase

Saying someone is good with the tools carries no information on its own. What was delegated, how the result was checked, and what they fell back to when it was wrong are all missing. Without those three, being good at it and being lucky are indistinguishable.

So this part is not about tools. Which product beats which product goes stale in six months; what does not go stale is a way of working. Three things are in scope: the criterion for how far to delegate, the procedure for judging what comes back, and the cost of skipping both.

The Line Is Drawn by Verification Cost, Not Difficulty

The common criterion is: delegate the easy things, keep the hard ones. By this series' discriminant that criterion has the wrong axis. What determines whether something can be delegated is not the cost of producing it but the cost of judging it.

Hold three tasks against that and some intuitions flip.

  • A gnarly regular expression: annoying to produce, cheap to judge. Ten examples tell you whether it is right. Good to hand over.
  • Changing one configuration value: nearly free to produce, potentially expensive to judge. A wrong value surfaces in production weeks later.
  • A data migration script: looks easy to produce and is hard to reverse. Its verification cost is effectively at maximum.

The third is the point. Irreversible work is never a delegation candidate no matter how cheap the generation is. Reversibility has nothing to do with difficulty, which is exactly why drawing the line by difficulty causes the accident in this square.

Four Lines Before You Hand It Over

Applying the criterion is simple: write four lines before delegating.

Example — a four-line delegation card

delegate:      first draft of the payment-failure retry logic
how to judge:  existing integration tests + 3 double-charge scenarios I add myself
reversibility: runs behind a feature flag. flag off returns to the previous path
keep in-house: the retry ceiling and the idempotency key design. wrong = charged twice

Two minutes to write. The value is in the second and fourth lines. If the judging line will not write, the task is not ready to hand over; if the keep-in-house line is empty, you usually have not drawn a boundary at all.

The Procedure for Judging What Comes Back

The most common failure in handling a result is the order you read it in. Read the result first and you rebuild your expectations around it. The more plausible the result, the stronger that overwrite.

Change the order. Before opening it, write three lines of expectation: which files should change, which edge cases should be handled, what must not change. Then open the result and compare. Any change that was not on your list is your first question.

Second, do not treat passing as grounds. Part 4 argued that a green build means nothing by itself. Here it means even less: take the artifact and the tests that check it from the same origin and the thing being judged and the standard judging it share a source. At least one edge case has to go in by hand.

Third, ask for an explanation but do not count it as evidence. A smooth answer to "why did you do it this way" is always available, and smoothness correlates weakly with correctness. Use the explanation to decide where to look; do the looking with execution and logs.

Where It Goes Slower Instead

Perceived speed is especially unreliable here. The randomized controlled trial METR published in July 2025 is the example. Sixteen developers experienced in their own open-source repositories worked through 246 issues, with AI tool use randomly allowed or disallowed per issue. The allowed condition took 19% longer, while participants had forecast a 24% speedup beforehand and still believed they had been sped up by 20% afterward.

Do not generalize it. The authors state explicitly that this is not evidence that AI slows down most developers, and that the result may not carry to other settings or to more skilled use. The sample is sixteen people. One condition does stand out, though: participants were working in repositories they knew well, held to high quality standards. That is an environment where verification was already expensive.

The Stack Overflow developer survey published in 2025 points the same direction. The top frustration, at 66%, was AI solutions that are almost right but not quite, and 45.2% said debugging AI-generated code is more time-consuming. On accuracy, 45.7% expressed some level of distrust against 32.7% who trust it. A survey records perception, not performance, so what it supports is a claim about where people report spending their time — nothing further.

Four recurring patterns come out of this: increasing delegation in areas where verification is expensive, underestimating the time to fix an almost-right result, shipping code you skipped understanding and meeting it again months later as a debugging target, and output that exceeds the team's review capacity. The last one progresses the most quietly.

What Is Genuinely Unsettled

Honestly stated, not much here is certain. Two things are. Generation got dramatically cheaper, and verification did not get cheaper alongside it.

The rest is open. Which categories of work show a net gain, whether the result flips as skill accumulates, and what changes at the organizational level are not settled questions. Anyone selling confident sentences in this space is usually selling something else too, or trading on fear.

Which makes the most rational individual move keeping your own record. For your own work you are the sample, and that sample is more accurate about you than somebody else's average.

Try It This Week

Pick three tasks you delegated this week and write down, for each, how many minutes you actually spent confirming the result was right. Not producing time — judging time. That number tells you where your own delegation line sits. If any of them took longer to judge than it would have taken to build, that category is faster done yourself next time.

  • Harness Engineering RPG — twenty-seven scenarios where the model is a fixed input and you design the tools, stopping rules, permissions, and evaluator around it. The debrief shows you that a weak evaluator caps everything below it. Same structure as the judging procedure in this post.
  • Logical Reasoning Trainer — separating necessary from sufficient conditions and reconstructing someone else's argument accurately. The closest available drill for not counting a plausible explanation as evidence.

Where this does not apply: in an area you are currently learning, invert the criterion. Even when a task is cheap to judge and therefore safe to hand over, if it is the skill you are trying to acquire, do it yourself. As part 3 noted, practice at reading and writing does not arise on its own, and delegation takes that practice first.

Further Reading

What Stays Expensive series

Sources