AI 시대 팀 리드, 제가 빠졌던 판단 착각 3가지

안녕하세요. 정리하는 개발자 워니즈입니다.

AI가 코드를 대신 짜주면서 리드의 일이 편해졌냐고 물으면, 저는 아니라고 답합니다. 편해진 게 아니라 판단해야 할 자리가 옮겨갔습니다.

그리고 그 자리를 못 따라가면서 저는 몇 번 틀렸습니다. 코드가 틀린 게 아니라 제 판단이 틀렸습니다. 더 곤란한 건, 틀린 순간에는 틀린 줄 몰랐다는 점입니다. 결과물이 그럴듯했으니까요.

AI 도입이 25% 늘면 배포 처리량은 1.5%, 배포 안정성은 7.2% 낮아지는 것으로 추정된다.

— Google DORA, Accelerate State of DevOps Report 2024

같은 조사에서 개인 생산성과 몰입은 올라갔습니다. 개인은 빨라졌는데 전달 성과는 내려간 겁니다. AI 시대 팀 리드가 봐야 할 지점이 개인 산출물에서 시스템 쪽으로 이동했다는 신호에 가깝습니다.

이 글의 결론을 먼저 말씀드리겠습니다. AI가 ‘만드는 일’을 가져가면서, 리드의 일은 ‘만들게 하는 것’에서 ‘만들기 전에 판단 기준을 세우는 것’으로 옮겨갔습니다. 아래에 적는 착각 세 가지는 각각 달라 보이지만 전부 같은 한 문장으로 수렴합니다. 맡기기 전에 “이 결과가 틀렸다면 무엇을 보고 알 수 있는가”에 한 줄로 답하지 못하면, 아직 위임할 준비가 안 된 겁니다.

그러면 본격적으로 정리해보도록 하겠습니다.

1. 착각 하나 — 읽어서 이해되면 검증한 것 같다

제가 가장 자주 저지른 착각입니다. 결과를 받아 읽는데 논리가 이어지고 결론이 그럴듯합니다. 그러면 “확인했다”고 생각하고 넘깁니다.

한 번은 일괄 처리 스크립트를 맡겨서 돌렸습니다. 종료 코드는 0이었고 로그에도 실패가 없어서 성공으로 판단하고 넘어갔습니다. 나중에 보니 처리 대상이 0건이었습니다. 아무 일도 안 하고 정상 종료한 겁니다.

로그를 안 읽은 게 아닙니다. “실패가 없다”를 “성공했다”로 읽은 것이 문제였습니다. 완료 보고는 서술이지 시스템 상태가 아닙니다. 저는 서술을 상태로 착각했습니다.

일반화하면 이렇습니다. 사람의 결과물을 리뷰할 때 우리는 상대의 이력을 같이 봅니다. 평소 어디서 실수하는지를 알고 그만큼 의심합니다. AI 산출물에는 그 이력이 없어서 의심의 근거가 텍스트의 그럴듯함밖에 안 남습니다. 그럴듯함은 지금 도구들이 가장 잘하는 일입니다.

그래서 순서를 바꿨습니다. 결과를 받고 “맞나?”를 묻는 대신, 맡기기 전에 “틀렸다면 어디서 드러나는가”를 먼저 적습니다. AI 시대 팀 리드에게 검증은 결과를 받은 뒤에 하는 일이 아니라 맡기기 전에 기준을 먼저 세우는 일입니다. 이 얘기는 AI 에이전트로 혼자 일하기, 늘어난 건 산출물이 아니라 검증이었습니다에서 더 다뤘습니다.

2. 착각 둘 — 빨라졌으니 더 많이 할 수 있다

두 번째 착각은 방향이 정반대입니다.

만드는 비용이 내려가니 저는 계속 붙였습니다. 도구를 늘리고, 자동화를 늘리고, 규칙을 늘렸습니다. 만드는 데 30분밖에 안 걸리는데 안 만들 이유가 없어 보였거든요.

그렇게 반년을 굴리고 나서 절반을 걷어냈습니다. 늘린 것들이 전부 “만드는 쪽”이었고, 정작 막혀 있던 곳은 “판단하는 쪽”이었기 때문입니다. 만드는 쪽이 빨라질수록 판단할 양만 늘었습니다. 정리 과정은 AI 코딩 하네스, 6개월 굴리고 절반을 걷어냈습니다에 남겨뒀습니다.

여기서 리드의 일에 대한 정의가 흔들립니다.

만드는 비용이 비쌀 때는 비용 자체가 필터였습니다. “그거 만들려면 2주 걸립니다”라는 문장 하나로 절반이 걸러졌습니다. AI가 그 비용을 크게 낮추면 그 필터가 통째로 사라집니다. 반대 논거가 없어지니 전부 통과됩니다.

그래서 만들 수 있는 양이 늘어날수록 안 만들 것을 정하는 일이 더 비싸집니다. 예전에는 견적이 대신 해주던 거절을, 이제는 리드가 근거를 들고 직접 해야 합니다. AI 시대 팀 리드의 산출물은 “얼마나 만들었나”보다 “무엇을 안 만들기로 했나”에 가깝습니다. 그리고 이건 아무도 칭찬해주지 않는 종류의 결정이라 더 밀리기 쉽습니다.

측정 기준도 같이 흔들립니다. AI 도입 효과, 코딩 속도를 재면 답이 안 나옵니다에서 숫자로 정리했지만, 요지는 빨라진 구간을 재면 항상 좋아 보인다는 것입니다.

안 만들 것을 정하는 일도 결국 기준을 세우는 일입니다. 판단할 기준이 없으면 만들 수 있다는 사실 자체가 만들 이유가 됩니다.

3. 착각 셋 — 사람에게 쓰던 위임 기준이 그대로 통한다

세 번째가 제일 늦게 알아차린 것입니다. 사람에게 일을 맡길 때 저는 속도만 보고 정하지 않았습니다. 의식하지 않았을 뿐 여러 축을 같이 계산하고 있었습니다.

사람에게 맡길 때 같이 보던 것	AI에 맡길 때
이 일을 하면서 뭔가 남는가	남지 않는다
다음에 같은 일이 오면 더 빨라지는가	매번 처음이다
막히면 스스로 물어보는가	묻지 않고 진행한다
애매한 지점에서 판단을 보류하는가	그럴듯하게 채워 넣는다

이 축들이 전부 빠지면 남는 기준은 “빠른 쪽”뿐입니다. 그리고 빠른 쪽만 보고 나누면 단위가 커집니다. 어차피 금방 끝나니까요.

저도 그렇게 했습니다. 서로 다른 작업 두 개를 한 번에 묶어서 맡겼습니다. 사람에게라면 절대 그렇게 안 묶었을 겁니다. 중간에 끊겼고, 결과물은 0이었고, 브리프 쓴 시간만 남았습니다.

그래서 위임 단위를 다시 정했습니다. 기준은 속도가 아니라 “실패했을 때 무엇이 남는가”입니다. 실패해도 앞부분이 남으면 묶고, 끊기면 전부 날아가면 쪼개고, 되돌리는 데 사람 손이 필요하면 승인 지점을 앞에 둡니다. 되돌리는 비용으로 권한을 나누는 얘기는 AI 에이전트 권한 설계 — ‘되돌릴 수 있다’는 착각에서 따로 정리했습니다.

한 가지 덧붙이면, 사람에게 위임할 때 계산하던 축은 대부분 미래에 관한 것이었습니다. 다음번에 더 나아지는가, 이 일이 누군가의 실력이 되는가. AI 위임에는 그 축이 없고 매번 현재값만 있습니다. 그래서 기준을 새로 세우지 않으면 리드의 판단은 자동으로 단기 최적화 쪽으로 굴러갑니다. 아무도 그렇게 결정하지 않았는데 그렇게 됩니다.

위임의 단위도 결국 기준이 정합니다. 틀렸을 때 무엇을 보고 알 수 있는지를 먼저 적어두면, 쪼갤지 묶을지는 거기서 따라 나옵니다.

4. AI 시대 팀 리드의 일은 기준을 먼저 세우는 것

읽어서 이해되는 것과 검증한 것은 다르다. AI 산출물에는 의심할 이력이 없어 그럴듯함이 유일한 근거가 된다
완료 보고는 서술이지 시스템 상태가 아니다. “실패가 없다”를 “성공했다”로 읽으면 아무 일도 안 한 성공이 통과된다
비용이 내려가면 견적이 대신 해주던 거절이 사라진다. 안 만들 것을 정하는 일이 리드에게 통째로 넘어온다
빨라진 구간만 재면 언제나 좋아 보인다. 개인 생산성이 오르는 동안 전달 성과는 내려갈 수 있다
사람 위임의 기준을 그대로 쓰면 단위가 커진다. 기준은 속도가 아니라 실패했을 때 남는 것이어야 한다

당장 해보실 수 있는 것 하나를 남기겠습니다. 다음에 무언가를 맡기기 전에 이 문장을 먼저 적어보세요.

이 결과가 틀렸다면, 나는 무엇을 보고 알 수 있는가?

한 줄로 답이 나오면 맡겨도 됩니다. 답이 “읽어보면 안다”라면 그건 위임이 아니라 일을 뒤로 미룬 것에 가깝습니다.

세 가지 착각의 공통점은 하나였습니다. 저는 계속 “만드는 쪽”을 보고 있었고, 문제는 전부 “만든 뒤”에서 났습니다. 도구가 좋아질수록 이 간격은 더 벌어집니다. AI 시대 팀 리드의 일이 어려워진 게 아니라, 어려운 쪽만 남은 것에 가깝습니다.

그래서 결론은 처음에 말씀드린 한 문장으로 돌아옵니다. AI가 ‘만드는 일’을 가져가면서, 리드의 일은 ‘만들게 하는 것’에서 ‘만들기 전에 판단 기준을 세우는 것’으로 옮겨갔습니다. 맡기기 전에 “이 결과가 틀렸다면 무엇을 보고 알 수 있는가”에 한 줄로 답하지 못하면, 아직 위임할 준비가 안 된 겁니다.

읽어주셔서 감사합니다. AI를 쓰는 팀에서 판단 기준을 어떻게 바꾸고 계신지 궁금합니다.