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편에서 적었듯 읽고 쓰는 연습 기회는 저절로 생기지 않고, 위임은 그 기회를 가장 먼저 가져갑니다.

이어서 읽기

이 블로그의 관련 글: AI 코딩 도구와 잘 일하는 다섯 가지 습관

비싸게 남는 기술 시리즈

참고 자료

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 확인.
위임 카드 네 줄, 판정 절차의 세 단계, 느려지는 네 가지 패턴은 위 자료에 나오는 것이 아니라 이 글에서 정리한 것입니다.