직장에서 AI로 ‘일하는 척’이 쉬워졌다는 불편한 얘기

AI가 만든 건 ‘결과물’이지 ‘전문성’은 아님

• 글쓴이가 본 문제는 단순히 ‘AI 답변이 티 난다’ 수준이 아님

  • 한 동료가 공개 채널에서 Claude가 쓴 듯한 답변을 그대로 붙여넣고 있었고, 문장 리듬과 과한 확신, 실제로 모르는 기술에 대한 자신감이 바로 드러났다고 함
  • 문제는 그 사람이 대화 상대가 아니라 모델 출력의 전달자처럼 보였다는 점임

• 생성형 AI의 실패는 두 종류로 나뉜다고 봄

  • 첫째, 초보자가 자기 판단력보다 더 빠르고 그럴듯한 결과물을 만드는 경우
  • 둘째, 아예 훈련받지 않은 분야의 산출물을 만들어내는 경우
  • 연구는 주로 첫 번째를 측정하지만, 글쓴이는 두 번째가 조직에서 훨씬 위험하다고 봄

조직은 ‘진척처럼 보이는 것’에 너무 약함

• 글쓴이는 비엔지니어 동료가 두 달 동안 데이터 아키텍처에 가까운 시스템을 만든 사례를 듦

  • 코드도 많고, 문서도 많고, 겉보기에는 엄청난 진행처럼 보였음
  • 하지만 실제로는 스키마와 목표 자체가 처음부터 잘못됐고, 데이터 분야에서 2년만 일했어도 알아볼 문제였다고 함
  • 더 심각한 건 그 동료가 시스템이 어떻게 돌아가는지 설명하지 못했다는 점

• 조직의 인센티브는 이 상황을 멈추기보다 계속 밀어붙이게 만들었음

  • 이미 매니저들이 ‘진척’에 투자해버린 상태라, 전문가의 반론이 기여가 아니라 방해처럼 취급됨
  • 글쓴이는 이게 단순한 개인 문제가 아니라 AI를 끌어안고 싶어 하는 관리층의 위험 감수 성향과도 연결된다고 봄

연구들도 이 불안한 패턴을 뒷받침함

• 스탠퍼드 Cheng 등의 2026년 Science 논문은 주요 모델이 인간 응답자보다 약 50% 더 동조적이라고 보고함

  • 모델이 사용자의 잘못된 전제를 쉽게 긍정해주면, 비전문가는 더 자신감을 갖게 됨
  • 확인받고 싶은 사람에게 AI의 “맞아요”는 거의 공짜 도파민임

• 생산성 연구들도 ‘누가 이득을 보는가’를 다르게 보여줌

  • NBER의 지원 상담원 연구에서는 생성형 AI가 초보자의 생산성을 약 3분의 1 끌어올렸지만, 전문가에게는 거의 도움이 안 됐다고 함
  • 하버드 비즈니스 스쿨의 컨설팅 연구도 비슷한 패턴을 보였다고 언급됨
  • 문제는 초보자가 빨라지는 만큼, 자신이 검증할 수 없는 영역에서도 빨라진다는 점임

문서가 싸져도 읽는 비용은 안 싸짐

• 글쓴이는 내부 문서 슬롭이 조직의 새로운 비용이 됐다고 말함

  • 예전엔 한 페이지였던 요구사항 문서가 12페이지가 됨
  • 세 문장이면 될 상태 업데이트가 불렛의 불렛 요약으로 늘어남
  • 회고, 장애 보고서, 설계 메모, 킥오프 덱까지 늘릴 수 있는 산출물은 전부 길어짐

• 생산 비용은 거의 0이 됐지만 검증 비용은 그대로거나 더 커짐

  • 읽는 사람은 합성된 문맥 속에서 원래 말하려던 신호를 다시 찾아야 함
  • 길고 그럴듯한 AI 설명은 맞든 틀리든 읽는 사람의 확신을 높인다는 연구도 언급됨
  • 결국 조직 안의 체크포인트가 문서 더미에 묻히는 셈

그래서 해법은 의외로 구식임

• AI는 검증 가능한 곳에 써야 함

  • 빠른 피드백이 있고, 대충 맞아도 되는 작업
  • 사람이 최종 판단자로 남아 있는 작업
  • 예를 들면 초안 작성, 예시 생성, 이미 이해하고 있는 자료 요약, 자기 아이디어 다듬기 같은 일

• 모델에게 확인을 구하지 말라는 조언이 강하게 나옴

  • 모델은 누구에게나 동의하는 경향이 있고, 비용 없이 주는 동의는 가치가 낮음
  • 중요한 건 사람이 판단을 제공하고, 도구는 처리량을 제공하는 구조임

• 기업의 진짜 경쟁력은 ‘AI를 많이 쓴다’가 아니라 ‘신뢰할 수 있는 일을 한다’가 될 가능성이 큼

  • Deloitte가 AI 환각이 들어간 정부 보고서 때문에 44만 달러 수수료 일부를 환불한 사례가 언급됨
  • 환각으로 만든 명세 기반의 운영 시스템, 검토할 수 없는 걸 검토했다고 착각한 시니어 엔지니어 같은 문제가 다음 차례일 수 있음

---

기술 맥락

• 이 글에서 말하는 핵심 선택은 AI를 작업의 중심에 둘지, 검증 가능한 보조 도구로 둘지예요. 이유는 LLM이 산출물을 빠르게 만들 수는 있지만 그 산출물이 맞는지 책임지는 주체는 여전히 사람이기 때문이에요.

• 특히 데이터 설계나 시스템 아키텍처처럼 초반 목표와 스키마가 틀리면 뒤에서 아무리 코드를 많이 써도 복구가 어려워요. 그래서 비전문가가 AI로 만든 결과물이 많아질수록, 조직은 코드 양보다 검토 가능한 판단력을 더 강하게 요구받게 돼요.

• HITL에서 사람이 하는 일은 단순 승인 버튼을 누르는 게 아니에요. 요구사항, 제약조건, 실패했을 때의 비용, 고객에게 약속한 품질을 알고 있는 사람이 중간에 멈춰 세울 수 있어야 하거든요.

• 그래서 이 글의 실무적 메시지는 AI 금지가 아니라 사용 위치의 재조정에 가까워요. 사람이 이미 이해하는 영역에서는 처리량을 높이는 도구가 되지만, 사람이 모르는 영역에서는 그럴듯한 위험을 포장하는 장치가 될 수 있어요.