본문은 요즘IT와 번역가 Yuna가 함께 웨슬리 웨이(Wesley Wei)의 글 〈AI Slop Is Becoming a Workplace Tax〉를 번역한 글입니다. 필자는 Go 언어와 엔지니어링 실무를 주로 다루는 소프트웨어 엔지니어로, AI가 개발자의 업무 환경에 미치는 영향에 관한 글을 써왔는데요. Medium을 중심으로 활동하며, AI 기술을 비판적 시각으로 살피는 퍼블리케이션 Ai-Ai-OH에도 꾸준히 기고하고 있습니다.

AI 도구가 일상적인 업무 곳곳에 자리를 잡으면서, 직장 내 소통의 방식도 조용히 달라지고 있습니다. 짧은 질문 하나에도 AI가 생성한 장문의 답변이 돌아오는 일이 점점 흔해졌지만, 그 과정에서 정작 필요했던 판단과 맥락은 빠져 있는 경우가 많습니다. 이 글은 AI가 생성한 콘텐츠가 직장 내 커뮤니케이션에 드리우는 보이지 않는 비용, 즉 구성원 모두가 치르게 되는 '소음의 세금'으로서 AI 슬롭 문제를 살펴봅니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

한 팀원이 슬랙에 이렇게 물었습니다. “이 서비스에는 Redis가 맞을까요, Memcached가 맞을까요?” 그러면 5초 뒤, 스레드에는 소제목과 트레이드오프, 각종 주의사항, 그리고 지나치게 균형만 잡느라 정작 결론을 내리지 못한 결론까지 붙은 번듯한 에세이가 올라왔죠. 아무도 문헌 리뷰를 부탁한 게 아니었습니다. 우리에게 필요했던 건 결정 하나였습니다.

이건 AI 시대에 생긴 꽤 낯선 마찰 중 하나입니다. 문제는 AI로 글을 쓰는 일 자체가 아니었죠. 저도 AI를 씁니다. 이 글도 AI의 도움을 받아 초안을 만들고, 거기에 제 문장과 판단을 덧대어 다듬었습니다. 앞으로는 대부분의 사람들이 비슷하게 일하게 될 겁니다. 문제는 무엇을 말해야 하는지 판단하는 일까지 AI에 넘겨버릴 때 시작됐습니다.

2026년 5월 22일, 이런 행동을 다룬 작은 페이지 하나가 Hacker News에 올라왔고 활발한 토론을 불러왔습니다. 제가 그 스레드를 읽었을 때 이미 400포인트를 넘겼고 댓글도 수백 개가 달려 있었죠. 그 페이지는 정말 짧았습니다. 거의 일부러 그렇게 만든 것처럼 보일 정도였죠. 그런데 사람들의 반응은 특정 웹사이트 하나 때문이 아니었습니다. 이미 많은 사람들이 직장에서 익숙하게 겪고 있던 장면이었기 때문입니다. 사람의 짧은 판단이면 충분했을 대화에, 누군가 AI가 쓴 긴 답변을 통째로 붙여 넣는 습관 말입니다.

그 원문이 생산성 손실이나 도입률, 통제된 실험 결과를 제시하는 건 아니었습니다. 그러니 마치 그런 근거가 있는 것처럼 말할 필요는 없었습니다. 다만 이 피로감 자체는 충분히 현실적이었고, 기존의 정보 과부하 연구와도 자연스럽게 이어졌습니다. Microsoft의 2023 Work Trend Index에 따르면, 조사 대상 직장인 중 64%가 “업무를 해낼 시간과 에너지가 부족하다”고 답했습니다. 68%는 “방해받지 않고 집중할 시간이 충분하지 않다”고 했죠. Asana의 2023 Anatomy of Work 보고서에서는 직장인들이 하루의 58%를 핵심 업무보다 조율 업무에 쓰고 있다고 분석했습니다.

여기에 손쉽게 찍어낼 수 있는 AI 장문 답변까지 더해보면 어떨까요? 축하할 일은 아니었습니다. 새로운 사무 노동 하나가 생겼을 뿐이니까요. 바로 누군가가 AI에 돌려받은 답변을 대신 읽어주는 일이었습니다.

1. 새로운 세금은 주의력으로 치러집니다

직장 내 커뮤니케이션은 원래도 의례가 너무 많았습니다. 상태 공유 회의가 있고, 사전 미팅이 있고, 회의 뒤에는 요약 메일이 따라왔습니다. 정렬 문서가 있었고, 의사결정 로그가 있었고, 티켓 코멘트와 Slack 스레드도 있었죠. 가끔은 안건도 없는 캘린더 초대까지 날아왔는데, 이쯤 되면 거의 조직적인 시간 낭비 아닌가 싶을 때도 있었습니다. AI가 이 혼란을 만든 건 아니었습니다. 다만 속도 제한을 없애버렸죠.

AI 이전에는 단순한 질문에 900단어짜리 답변을 쓰려면 그만한 수고가 필요했습니다. 그 수고가 일종의 마찰로 작동했죠. 정말 중요하게 생각하거나, 정말 헷갈리지 않으면 그 정도로 길게 쓰지 않았습니다. 이제는 텍스트를 생산하는 비용이 거의 0에 가까워졌지만, 읽는 비용은 여전히 그대로였습니다.

이 비대칭이 핵심이었습니다. 제가 20초 만에 답변을 생성해 올렸는데, 그걸 다섯 명이 각자 4분씩 읽어야 한다면 어떻게 될까요? 저는 생산적인 기분이 들 수 있었겠지만, 실제로는 제 일을 팀 전체에 떠넘긴 셈이었습니다. 팀은 총 20분의 주의력 세금을 낸 거죠.

주의력은 추상적인 가치가 아니었습니다. 개발팀에서 주의력은 장애를 디버깅하는 데 쓰였고, 아키텍처를 검토하는 데 쓰였고, 보안 가정을 의심해보는 데 쓰였습니다. 나중에 더 큰 비용으로 돌아올 제품 트레이드오프를 미리 포착하는 데도 결국 주의력이 필요했죠. 그런데 모든 대화가 AI가 뽑아낸 신중한 문장과 경고 문구로 가득한 스크롤 지옥이 되면, 사람들은 점점 꼼꼼히 읽지 않게 됐습니다.

그러면 정말 중요한 경고 한 줄이 일곱 단락짜리 “상황에 따라 다릅니다” 사이에 묻혀버렸죠. 팀 안에서는 텍스트가 많아질수록 오히려 공유된 이해가 줄어들 수 있었습니다.

2. AI는 부족한 판단도 그럴듯하게 포장합니다

이건 조금 불편한 이야기였습니다. AI가 만든 장문 답변은 얼핏 보면 꽤 인상적이었죠. 구조가 잘 잡혀 있었고, 불릿도 정리돼 있었고, 표현도 매끄러웠습니다. 누가 봐도 뭔가 공을 들인 결과물처럼 보였죠.

하지만 직장에서 글이 가치 있는 이유는 길어서가 아니었습니다. 현재 시스템이 어떤 상태인지, 마감이 얼마나 촉박한지, 우리 팀이 어느 정도의 리스크를 감수할 수 있는지, 질문한 사람이 지금 무엇을 결정해야 하는지 알고 있기 때문이었습니다. Redis와 Memcached를 일반론으로 비교하는 건 AI도 잘했습니다. 하지만 실제로 도움이 되는 답변은 “이 프로젝트에서는 무엇을 써야 하고, 왜 그래야 하는가”까지 말해주는 답변이었죠.

예를 들어, 팀 채팅에서 이런 답변은 도움이 되지 않았습니다.

Redis와 Memcached는 모두 널리 쓰이는 인메모리 데이터 저장소였습니다.
Redis는 풍부한 자료구조, 영속성, 복제, pub/sub, 스트림, Lua 스크립팅 등을 지원했습니다.
Memcached는 더 단순했고, 주로 기본적인 캐시 워크로드에 사용됐습니다.
어떤 선택이 맞는지는 지연 시간 요구사항, 운영 복잡도, 메모리 사용량, 영속성 필요 여부, 클러스터링 전략, 팀의 익숙함 등에 따라 달라졌습니다.

이런 답변이 더 도움이 됐습니다.

이 서비스에는 Redis를 쓰는 게 맞았습니다.
이유: 다음 분기에는 워커 간 캐시 무효화를 위해 pub/sub가 필요했고, 우리는 이미 운영 환경에서 Redis를 돌리고 있었습니다.
Memcached도 단순 키-값 캐시만 놓고 보면 가능했겠지만, 로드맵 관점에서 보면 얻는 것보다 관리해야 할 서비스만 하나 더 늘어나는 셈이었습니다.

두 번째 쪽이 더 짧았지만, 오히려 더 많은 판단이 담겨 있었습니다. 결정이 있었고, 이유가 있었고, 제약이 있었고, 앞으로의 시사점도 있었습니다. 팀원들이 반박하거나 보완할 출발점이 생겼죠. 반대로 첫 번째 답변은 모두에게 숙제를 던질 뿐이었습니다.

이 차이가 중요했습니다. AI는 성실해 보이는 결과물을 빠르게 만드는 데 탁월했죠. 균형 잡힌 비교도 순식간에 써냈습니다. 하지만 직장에서 정말 필요한 건 대개 더 좁고 더 어려운 일이었습니다. 맥락을 판단으로 바꾸는 일이었죠.

3. 진짜 문제는 형식이 어긋난다는 데 있습니다

저는 이걸 일종의 프로토콜 문제라고 봤습니다. 모든 커뮤니케이션 채널에는 그 채널에 맞는 응답의 크기와 형식이 있었습니다. PR 리뷰 코멘트는 아키텍처 의사결정 문서가 아니었고, 장애 대응 채널은 브레인스토밍 문서가 아니었습니다. Slack 한 줄 질문은 벤더 중립적인 백서를 요청한 게 아니었죠.

그런데 여기에 AI가 만든 긴 답변을 그대로 붙여 넣으면 프로토콜이 어긋났습니다. 그 부담은 읽는 사람이 떠안게 됐죠.

그래서 읽는 사람은 이런 걸 하나하나 다시 해석해야 했습니다.

어디까지가 실제 답변인가
어떤 내용이 우리 시스템 맥락에서 나온 것인가
보낸 사람은 실제로 무엇을 믿고 있는가
이 사람은 결정을 원하는 건가, 리뷰를 원하는 건가, 아니면 칭찬을 원하는 건가
여섯 번째 문단쯤에 숨은 리스크가 있는 건 아닐까

그래서 AI 장문 답변은 사람의 장황함보다 더 피곤하게 느껴졌습니다. 사람이 길게 말하면 적어도 의도가 드러나는 경우가 많았죠. 불확실해서 길어졌는지, 집착하고 있는지, 급한지, 혼란스러운지 어느 정도는 읽혔습니다. 반면 AI 문장은 지나치게 매끈했습니다. 톤은 자신감 있어 보이는데 내용은 애매할 때가 많았죠. 이 조합이 사람을 지치게 했습니다.

유용한 엔지니어링 체크리스트는 의외로 단순했습니다.

AI의 도움을 받은 문장을 보내기 전에는, 이렇게 물어봐야 했습니다.

이 메시지로 어떤 결정이나 행동이 가능해지는가
첫 문장만 읽어도 핵심이 전달되는가
나만 알고 있는 현장 맥락에 의존하는 부분은 무엇인가
결과를 바꾸지 않으면서 덜어낼 수 있는 문장은 무엇인가
내가 이 문장을 직접 하나하나 쳤어도 정말 이 길이로 보냈을까

마지막 항목이 가장 뼈아프기에 더 효과적입니다.

4. 전후를 비교해보면 차이가 더 분명해집니다

현실적인 직장 예시를 하나 떠올려보죠.

나쁜 버전은 이랬습니다.

OAuth callback 이슈 때문에 출시를 미뤄야 하는지 AI 도구에 물어봤습니다.
도구는 고려할 점이 여러 가지라고 했습니다.
한편으로는, 알려진 인증 버그를 안고 출시하면 사용자 신뢰를 해치고, 지원 부담을 늘리며, 보안 우려를 만들 수 있다고 했습니다.
다른 한편으로는, 출시를 미루는 일이 이해관계자의 신뢰와 로드맵 약속에 영향을 줄 수도 있다고 했습니다.
따라서 팀은 심각도, 사용자 영향, 롤백 가능성, 모니터링, 커뮤니케이션 계획을 검토한 뒤 결정해야 한다고 했습니다.

책임감 있어 보였죠. 하지만 막상 읽고 나면 남는 건 별로 없었습니다.

더 나은 버전은 이랬습니다.

출시는 24시간 미루는 게 좋겠습니다.
이유: Safari에서 기존 세션이 있는 사용자에게 OAuth callback이 실패하고 있었고, 지원팀은 아직 로그만으로는 어떤 계정이 영향을 받는지 식별할 수 없었습니다.
계획: 오늘 패치하고, callback 실패를 보는 대시보드를 추가한 뒤, 내일 아침 30분 검증을 돌리고, 오류율이 0.5% 아래로 유지되면 그때 배포하겠습니다.

두 번째 메시지가 AI를 쓰지 말자는 뜻은 아니었습니다. 원한다면 AI로 초안을 잡아도 됐습니다. 메모를 압축하는 데 써도 됐고, 빠진 리스크를 점검하는 데 써도 됐고, 최종 문장을 더 명확하게 다듬는 데 써도 됐죠. 다만 생각의 거품까지 그대로 방에 쏟아놓고, 그걸 협업이라고 부르지는 말자는 얘기였습니다.

바람직한 워크플로는 이렇습니다.

정리되지 않은 맥락
AI 보조 압축
인간의 판단
요청이 분명한 짧은 메시지

반대로 좋지 않은 워크플로는 이렇습니다.

정리되지 않은 맥락
AI 확장
나머지 모두가 뒷정리

한쪽은 팀이 다음 단계로 나아가게 만들었고, 다른 한쪽은 아무도 맡기로 한 적 없는 집단 편집 작업만 남겼죠.

5. 물론 길게 써야 할 때도 있습니다

반론도 진지하게 들어볼 필요가 있었습니다. 어떤 질문은 실제로 깊이 있는 답변이 필요했죠. “Redis가 맞나요, Memcached가 맞나요?” 같은 질문도 어떤 시스템에서는 단순했지만, 다른 시스템에서는 매우 중요한 결정일 수 있었습니다. 마이그레이션 계획, 개인정보 검토, 장애 회고, 데이터베이스 일관성 같은 주제는 충분히 긴 문서가 필요할 수 있었죠.

그러니까 원칙은 “짧을수록 무조건 좋다”가 아니었습니다. 그 또한 다른 종류의 단순화였죠.

원칙은 답변의 크기를 결정의 크기에 맞추는 것이었습니다.결정이 작다면 답을 먼저 주고, 필요하면 링크나 부록을 뒤에 붙이면 됐습니다. 결정이 크다면 담당자, 제약 조건, 선택지, 피드백 기한이 있는 구조화된 문서를 써야 했죠. 탐색적인 대화라면 그것부터 분명히 밝혀야 했습니다. 길더라도 목적이 분명한 글은 문제가 아니었습니다. 답인 척하지만 실제로는 답을 미루는 긴 글이 문제였죠.

그리고 장황한 메시지를 무조건 게으르다고 볼 수도 없었습니다. 문화, 언어, 연차, 성향이 다를 수 있으니까요. 어떤 사람은 정확하게 쓰려고 애쓰느라 길어졌고, 어떤 사람은 자신감이 부족해서 더 많이 설명하게 됐습니다. 어떤 사람은 언어와 직장 문화 사이를 두 번 번역하듯 글을 쓰기도 했죠.

다만 AI 이후에는 전제가 달라진 것도 사실이었습니다. 예전에는 긴 답변이 적어도 시간을 썼다는 신호였는데, 이제는 버튼 한 번 눌렀다는 뜻일 수도 있게 됐으니까요. 그래서 발신자에게는 새로운 책임이 생겼습니다. 판단한 부분을 직접 드러내는 책임이었죠.

이럴 때는 한 문장만으로도 충분했습니다.

AI로 메모를 정리해봤고, 제 판단은 이번에는 Redis를 쓰는 게 맞습니다.

이 정도면 충분했습니다. 도구를 썼다는 사실은 드러내되, 판단과 책임은 여전히 사람에게 있다는 점을 분명히 해줬으니까요.

6. 장황함을 줄이는 것도 제품의 역할입니다

이건 에티켓의 문제만은 아니었습니다. 제품 설계의 문제이기도 했죠.

요즘 협업 도구들은 곳곳에 AI 버튼을 붙이고 있었습니다. 그런데 그 버튼의 기본값이 전부 “생성하기”여야 할까요. 저는 꼭 그렇지는 않다고 봤습니다. 오히려 더 자주 필요한 건 “요약하기”, “결정만 추리기”, “열린 질문 정리하기”, “3문장 답변으로 압축하기” 같은 기능이었죠. 제품은 규범을 만들었습니다. 크고 화려한 작성 버튼은 사람들에게 계속 더 많이 생산하라고 가르쳤죠. 하지만 좋은 협업 도구는 줄이는 방향으로도 사용자를 도와야 했습니다.

이런 장치가 있다면 어떨까요?

활발한 스레드에서 긴 답변을 쓰려 할 때 “결정을 먼저 적어보세요”라고 안내하기
생성된 답변이 질문보다 지나치게 길면 경고하기
“추천안으로 압축하기” 같은 원클릭 기능 제공하기
바쁜 채널에 올리기 전에 “내가 실제로 원하는 것”을 먼저 입력하게 하기
스레드 요약에서 사실, 의견, 결정, 미해결 질문을 구분해서 보여주기

물론 트레이드오프는 있었습니다. 제약이 지나치면 사람들은 금방 피로해졌죠. 글을 쓴다고 혼내는 도구를 좋아할 사람은 없었습니다. 하지만 이런 기본 설정은 분명 도움이 됐습니다. 좋은 인터페이스는 사용자를 민망하게 만들지 않았습니다. 대신 꼭 필요한 말이 먼저 나오도록 도와줬죠.

AI 벤더들은 흔히 글의 양을 생산성으로 포장했습니다. 하지만 협업에서는 분량이 잘못된 지표인 경우가 많았죠. 진짜 중요한 건 적절한 사람들이 충분한 맥락을 공유한 상태에서, 다음 행동에 얼마나 빨리 합의할 수 있느냐였습니다.

7. 결국 직접 말해야 합니다

직장에 필요한 건 더 그럴듯한 문단이 아닙니다. 더 분명한 책임감이었죠. 내가 팀원에게 추천을 물었다면, 중립을 흉내 내달라는 뜻이 아니었습니다. 그 사람이 가진 현장 맥락을 써달라는 뜻이었죠. 본인 생각을 말해달라는 뜻이었습니다. 어떻게 보는지 말해주고, 왜 그렇게 판단하는지 설명해주고, 딱 하나 놓치면 안 되는 주의사항을 짚어주고, 어디까지는 확신하고 어디부터는 불확실한지 보여주면 됐습니다. 그리고 거기서 멈추면 됐죠.

AI는 분명 커뮤니케이션을 더 좋게 만들 수 있었습니다. 하지만 그건 결과물을 부풀릴 때가 아니라, 의도를 더 또렷하게 만들 때만 가능합니다. 제가 바라는 미래는 모든 채팅 메시지가 미니 컨설팅 보고서가 되는 세상이 아니었습니다. 잘 다듬어진 군더더기 속에서 의미를 발굴하느라 시간을 쓰는 대신, 원래 하려던 일을 더 많이 할 수 있는 환경이었죠.

다음에 AI가 뽑아준 답변을 그대로 붙여 넣고 싶어질 때, 기준은 이 정도면 충분했습니다. 내가 직접 판단하지 않은 말로, 다른 사람의 시간을 쓰게 하는 건 옳지 않으니까요.

<원문>

AI Slop Is Becoming a Workplace Tax