실제 협업 과정에서 본 사례를 바탕으로 썼다. 조직, 저장소, 티켓과 사람을 식별할 수 있는 정보는 제외하고 요청의 구조만 남겼다.

AI가 작성한 코드 리뷰 요청을 하나 읽었다.

겉으로는 꽤 잘 만들어져 있었다. 작업 링크, 기준 브랜치, 변경 범위, 자동 테스트 결과, 확인할 리뷰 포인트가 정돈돼 있었다. “AI가 쓴 글이라 내용이 없다”고 말할 수 있는 사례는 아니었다.

그런데 정작 한 가지가 빠져 있었다.

이 변경을 누가, 왜 봐야 하는가?

요청은 넓은 팀을 향했고 AI 리뷰 봇도 호출했다. 그러나 변경 영역의 소유자가 누구인지, 금액 정합성과 UI 노출 조건을 각각 누가 판단할 수 있는지, 아직 확인하지 못한 계약은 무엇인지에 대한 라우팅은 없었다.

AI는 메시지를 매끈하게 만들었다. 사람이 해야 할 판단은 여전히 비어 있었다.

나는 이런 상태를 겉멋 AI라고 불러보고 싶다.

TL;DR

  • 겉멋 AI는 AI를 썼다는 외형은 있지만, 목표·대상·근거·책임에 대한 인간의 판단이 빠진 상태다.
  • 문제는 AI가 글을 썼다는 사실이 아니라, 발신자가 아낀 인지 노동을 수신자에게 떠넘겼다는 데 있다.
  • “사람이 할 수 있는 일에 토큰을 쓰지 말자”는 기준은 너무 넓다. AI가 총 협업 비용을 줄였는가를 물어야 한다.
  • 형식화·요약·검색은 AI에게 맡길 수 있다. 누구에게 무엇을 왜 요청할지는 요청자가 결정해야 한다.
  • AI가 만든 산출물은 길이나 완성도가 아니라, 다음 사람이 곧바로 판단하고 행동할 수 있는지로 평가해야 한다.

내용이 없었던 것은 아니다

처음에는 나도 “AI에게 대강 시켜서 리뷰 요청을 보냈다”고 생각했다. 원문을 다시 읽어보니 그 평가는 정확하지 않았다.

요청에는 다음 정보가 있었다.

  • 작업과 이슈 링크
  • 기준 브랜치
  • 세 화면에 걸친 변경 범위
  • 서버 값을 그대로 표시한다는 구현 방향
  • 타입 검사와 테스트 결과
  • 금액 집계와 미노출 조건이라는 리뷰 포인트
  • 실제 payload 검증이 뒤에 남았다는 사실

정보만 세면 웬만한 리뷰 요청보다 낫다. 여기서 “AI가 작성해서 내용이 부실하다”고 비판하면 사실을 놓친다.

빠진 것은 정보가 아니라 선택이었다.

  • 왜 팀 전체가 받아야 하는가?
  • 금액 집계 코드를 가장 잘 아는 사람은 누구인가?
  • 세 화면의 UI 일관성을 판단할 사람은 누구인가?
  • 서버 payload 검증 전에도 승인 가능한 범위는 어디까지인가?
  • 지금 필요한 것은 코드 승인인가, 데이터 계약 확인인가?
  • 언제까지 어떤 결정을 받아야 하는가?

AI는 주어진 정보를 정리할 수 있다. 하지만 요청자가 이런 질문에 답하지 않은 채 “리뷰 요청을 만들어줘”라고 하면, 모델은 빈 판단 자리를 자연스러운 문장으로 메운다.

메시지는 완성돼 보인다. 협업은 아직 시작되지 않았다.

이미 이름이 있던 현상: workslop

BetterUp Labs와 Stanford Social Media Lab은 workslop이라는 표현을 사용한다. 겉보기에는 괜찮지만 실질적으로 일을 진전시키지 못하고, 동료에게 사고 과정과 정리 비용을 넘기는 AI 산출물을 뜻한다.

2025년 9월 미국의 정규직 사무직 노동자 1,150명을 조사한 결과, BetterUp은 응답자의 40%가 지난 한 달 동안 workslop을 받은 적이 있다고 보고했다. 한 사건을 처리하는 데 평균 2시간이 들었다는 결과도 함께 제시했다. 표본과 조사 방식의 한계는 있지만, “최근 이런 일이 많아졌나?”라는 감각이 개인적인 짜증만은 아니라는 단서는 된다.

다만 내가 말하는 겉멋 AI는 결과물의 낮은 품질에만 초점을 두지 않는다.

workslop
  = 그럴듯하지만 실질적인 진전이 없는 AI 산출물

겉멋 AI
  = AI를 사용했다는 외형이
    판단·책임·맥락의 부재를 가리는 사용 방식

결과물이 사실관계와 형식 면에서 괜찮아도 겉멋 AI일 수 있다. 리뷰 요청에 링크와 테스트 결과가 모두 있어도, 대상을 선택하지 않고 책임을 팀 전체에 흩뿌렸다면 협업 비용은 줄지 않는다.

가장 비싼 것은 토큰이 아니라 동료의 주의력이다

“사람이 해도 되는 일을 AI에게 시키며 토큰을 낭비한다”는 말에는 공감할 부분이 있다. 그러나 이것만으로는 좋은 기준이 되기 어렵다. 계산기, 검색, 포매터, 테스트 자동화도 모두 사람이 할 수 있는 일을 컴퓨팅 자원으로 대신한다.

AI를 쓸지 말지는 사람이 할 수 있는가보다 다음 질문으로 판단하는 편이 낫다.

AI를 사용한 뒤 전체 업무 비용이 줄었는가?

비용에는 모델 토큰만 들어가지 않는다.

총 협업 비용
  = 작성 시간
  + 검증 시간
  + 수신자의 해석 시간
  + 잘못된 라우팅으로 생긴 대기
  + 재질문과 재작업
  + 신뢰 하락

AI가 발신자의 작성 시간을 10분 줄였지만, 다섯 명이 “내가 봐야 하나?”, “무엇을 결정해야 하나?”를 각각 3분씩 판단해야 한다면 팀 전체 비용은 오히려 늘어난다.

토큰은 눈에 보이는 사용량이다. 동료의 주의력은 대시보드에 잘 잡히지 않는다. 그래서 겉멋 AI는 생산성처럼 보이기 쉽다.

리뷰 요청에서 인간이 넘기면 안 되는 것

코드 리뷰 요청을 예로 들면 AI가 잘할 수 있는 일이 분명히 있다.

  • PR과 이슈 링크 형식 정리
  • diff에서 변경 영역 요약
  • 실행한 검사와 결과 수집
  • 반복되는 템플릿 작성
  • 긴 설명을 채널에 맞게 압축
  • 잠재적 위험 후보 제시

반면 다음 판단은 요청자가 소유해야 한다.

누가 봐야 하는가

리뷰어는 “지금 온라인인 사람”이나 “팀 전체”가 아니다. 변경한 계약과 실패 위험을 판단할 수 있는 사람이어야 한다.

  • 도메인 정책을 아는 사람
  • 변경한 공용 모듈의 소유자
  • 데이터 계약을 검증할 백엔드 담당자
  • 특정 화면의 회귀를 판단할 프론트엔드 담당자

AI가 코드 소유권과 변경 이력을 바탕으로 후보를 제안할 수는 있다. 최종 라우팅과 요청 책임은 사람에게 남는다.

무엇을 봐야 하는가

“전체적으로 리뷰해 주세요”는 수신자에게 분석 계획부터 다시 세우라는 요청이다. 변경자가 이미 알고 있는 위험을 먼저 좁혀야 한다.

금액 정합성
  → 결제용 합계와 노출용 합계를 분리한 방식

미노출 조건
  → 라벨은 숨겨도 금액에는 반영되는 브랜드 처리

아직 검증하지 못한 것
  → 실제 서버 payload와 화면 금액 대조

AI가 이 목록을 쓰더라도, 무엇이 중요한지 선택하는 근거는 구현자가 제공해야 한다.

어떤 결정을 원하는가

리뷰 요청은 정보 공유가 아니라 의사결정 요청이다.

  • 코드 구조를 승인해 달라는가?
  • 데이터 계약이 맞는지 확인해 달라는가?
  • 배포 전에 실기기 검증이 필요한지 결정해 달라는가?
  • 특정 위험을 감수해도 되는지 판단해 달라는가?

요청받은 사람이 다음 행동을 알 수 없다면 메시지는 완성되지 않았다.

겉멋 AI가 반복되는 패턴

1. 형식은 자동화했지만 판단은 하지 않는다

링크, 제목, 체크리스트와 이모지는 반듯하다. 정작 왜 이 일이 필요한지, 무엇이 위험한지는 없다.

2. 넓게 보내면 누군가 보겠지

AI가 메시지 작성 비용을 낮추면 방송 비용도 낮아진다. 특정한 두 사람에게 정교하게 요청하는 대신 큰 채널이나 팀 그룹을 호출한다. 발신자는 빨라지지만 수신자들의 분류 비용이 늘어난다.

3. AI가 만든 것을 다른 AI에게 넘긴다

AI가 코드를 만들고, AI가 PR 본문을 만들고, AI가 리뷰 요청을 만들고, 리뷰 봇이 이를 다시 읽는다. 각 단계에 인간의 판단이 없다면 자동화가 길어질수록 근거가 생기는 것이 아니라 같은 가정이 반복될 수 있다.

4. 길이가 품질처럼 보인다

AI는 짧은 요청도 섹션과 목록이 있는 문서로 만들 수 있다. 내용의 밀도보다 형식적 완성도가 먼저 보이면 “준비가 잘됐다”는 착시가 생긴다.

5. AI 사용 자체가 성과가 된다

문제가 얼마나 빨리 해결됐는지보다 AI를 얼마나 많이 연결했는지가 앞에 나온다. 도구 사용이 목적이 되면 굳이 자동화하지 않아도 되는 전달 작업까지 토큰과 동료의 주의력을 소비한다.

없애려면 프롬프트보다 요청 계약이 필요하다

“프롬프트를 더 잘 쓰자”만으로는 부족하다. 모델은 빈 입력에서 책임 있는 판단을 만들어낼 수 없다. 먼저 사람이 채워야 할 최소 요청 계약이 필요하다.

목적
  이 리뷰로 어떤 결정을 받을 것인가?

대상
  누가 그 결정을 할 수 있으며, 왜 그 사람인가?

범위
  어느 파일·화면·계약이 바뀌었는가?

위험
  틀리면 어떤 사용자·데이터·운영 문제가 생기는가?

근거
  무엇을 테스트했고 어떤 결과를 확인했는가?

미확인
  아직 증명하지 못한 것은 무엇인가?

기한
  언제까지 어떤 형태의 응답이 필요한가?

AI는 이 입력을 받아 메시지를 압축하고, 누락을 경고하고, 적절한 형식으로 바꿀 수 있다. 필수 항목이 비어 있다면 그럴듯하게 완성하는 대신 요청자에게 되물어야 한다.

예를 들어 리뷰 요청 자동화의 성공 조건은 “메시지 생성 완료”가 아니다.

잘못된 성공 조건
  → Slack 메시지가 전송됐다

더 나은 성공 조건
  → 적절한 리뷰어가 선택됐다
  → 리뷰 위험과 미확인 범위가 전달됐다
  → 수신자가 추가 해석 없이 다음 행동을 알 수 있다

AI는 일을 대신해야지 책임을 전달하면 안 된다

AI를 쓰지 말자는 이야기가 아니다. 나는 코드 검색, 문서 요약, 테스트 실행, 리뷰 후보 탐색과 반복 작업에 AI를 적극적으로 사용한다.

그럴수록 사용 기준은 더 엄격해야 한다.

AI가 반복 작업을 대신했다면 좋은 자동화다. AI가 근거를 더 많이 모아줬다면 좋은 보조다. AI가 내가 해야 할 선택을 동료에게 넘기기 좋은 문장으로 포장했다면 겉멋 AI다.

그래서 AI 산출물을 보내기 전에 세 가지를 확인하려 한다.

  1. 내가 내려야 할 판단을 AI 문장 뒤에 숨기지 않았는가?
  2. 이 결과가 수신자의 해석 시간을 실제로 줄이는가?
  3. AI를 사용하지 않았을 때보다 팀 전체의 일이 줄었는가?

토큰을 썼다는 사실은 중요하지 않을 수 있다. 그 토큰으로 누구의 일을 줄였는지가 중요하다.

AI 생산성은 내가 얼마나 빨리 보냈는지가 아니라, 다음 사람이 얼마나 적게 다시 생각해도 되는지로 측정해야 한다.

함께 읽기