혹시 최근 Slack이나 메일에서 유난히 매끈한데 어딘가 붕 뜬 문장을 받아본 적 있으신가요? “AI;DR(AI; didn’t read)”이라는 표현이 요즘 화제입니다. 뉴스레터 저자 Rick Manelius는 “다듬지 않은 AI 산출물을 그대로 보내면 저는 읽지 않겠다”는 새 원칙을 선언했어요(rickmanelius.com, 2026년 8월 17일 게시). TL;DR(너무 길어서 안 읽음)이 소셜미디어 시대의 반응이었다면, AI;DR은 생성형 AI 시대의 새로운 반응인 셈이죠.
이 흐름, 남 얘기가 아니에요. PR 설명, 기술 문서, 커밋 메시지까지 AI로 초안을 만드는 게 당연해진 지금, 동료가 “이거 다시 읽을 필요가 있나?”라고 느끼는 순간 우리의 커뮤니케이션과 평판에도 영향을 미치기 때문입니다. 다듬지 않은 AI 슬롭을 그대로 보내는 습관이 개발자 커리어에도 조용히 흔적을 남기고 있어요.
AI;DR, 이제 아무도 안 읽는다는 뜻이에요
Manelius는 자신의 새 정책을 이렇게 요약합니다. “리뷰하고 다듬을 만큼 신경 쓰지 않았다면, 나도 읽어줄 만큼 신경 쓰지 않겠다”는 것이죠. 고객 지원처럼 100% AI 산출물이 자연스러운 영역도 있지만, 동료와의 Slack 대화나 팀 뉴스레터처럼 “내 이름을 걸고” 보내는 글은 다르다는 지적입니다.
TL;DR(too long; didn’t read)이 소셜미디어를 위한 해법이었다면, AI;DR(AI; didn’t read)은 AI 슬롭을 위한 해법이다.
Rick Manelius
우리 팀 Slack과 PR에도 이미 일어나고 있어요
후배님도 한 번쯤 겪어보셨을 거예요. 팀 채널에 누군가 AI가 만든 듯한 장문을 붙여넣고, 아무도 반응하지 않는 상황이요. 발신자 의도와 무관하게 받는 사람은 그걸 “성의 없음”으로 해석하는 경우가 많습니다.
PR 설명도 마찬가지예요. 변경 이유·영향 범위·롤백 방법이 다 들어있어 보이지만, 정작 리뷰어가 질문했을 때 작성자가 제대로 답하지 못하면 신뢰는 오히려 깎입니다. “잘 쓴 글”과 “이해하고 쓴 글”은 다르다는 걸, 이제 동료들도 구분하기 시작했어요.
문제는 ‘이해 없는 산출물’이에요
이 글 아래 달린 반응 중 눈에 띄는 지적이 있었어요. AI 덕분에 몇 분 만에 그럴듯한 기술 스펙이나 전략 문서를 만들 수 있지만, 정작 작성자가 그 안의 전제·엣지 케이스·실행 난이도를 이해하지 못하는 경우가 늘고 있다는 겁니다. 산출물의 정교함과 작성자의 이해도가 점점 벌어지는 거죠.
코드 리뷰에서도 똑같이 나타나요. 커밋 메시지는 그럴듯한데, “왜 이렇게 짰나요?”라고 물으면 대답을 못 하는 경우 말이에요. 이런 산출물이 쌓이면 결국 팀 안에서도 ‘AI 슬롭’으로 분류되고, 리뷰어는 그 사람의 PR 전체를 더 의심하게 되어 리뷰 시간이 오히려 늘어나는 역설이 생깁니다.
숫자로 보는 신뢰 문제
Stack Overflow 2025 Developer Survey에 따르면 개발자의 84%가 AI 도구를 이미 사용 중이거나 사용할 계획이라고 답했습니다. 같은 설문에서 46%는 “AI 산출물의 정확성을 신뢰하지 않는다”고 답했고, 같은 조사에서 66%는 “AI 답변이 얼추 맞지만 완전히 맞지는 않다”고 느낀다고 응답했어요. 같은 서베이 기준 45%는 AI가 만든 코드를 디버깅하느라 상당한 시간을 썼다고 밝혔습니다(survey.stackoverflow.co/2025/ai). 사용은 늘어나는데 믿음은 줄어드는 역설, 이게 AI;DR이 나온 배경이에요.
국내 채용 시장은 정반대로 움직입니다
흥미롭게도 채용 시장 반응은 좀 달라요. 원티드랩이 국내 기업 153곳 인사 담당자를 대상으로 진행한 ‘2026 채용 트렌드 서베이’에 따르면, 2026년 가장 중요한 역량 중 AI·데이터 활용 역량이 24.2%로 4위를 차지했습니다(전자신문, 2025년 12월 8일 보도). 같은 조사에서 개발 직군에 대한 채용 수요는 28.1%로 전체 직군 중 가장 높았고요.
즉 기업은 “AI를 쓸 줄 아는 사람”을 원하지만, 그게 “AI가 쓴 걸 그대로 베끼는 사람”을 뜻하지는 않는다는 걸 후배님도 눈치채셨을 거예요. 채용 담당자가 정말 보고 싶은 건 AI 산출물을 검증하고 책임질 수 있는 판단력이거든요.
시니어는 이렇게 걸러내고, 팀은 이렇게 대응해요
리뷰어 입장에서는 산출물의 매끈함보다 “왜 이렇게 했는지” 설명 가능한지를 먼저 봐야 해요. PR 설명이 아무리 길고 정돈돼 있어도, 다음 질문에서 막히면 다시 봐야 할 신호입니다.
- 이 선택의 대안은 무엇이었고, 왜 지금 방식을 골랐나요?
- 이게 실패하면 어떤 일이 벌어지나요?
- 이 부분, 직접 실행하거나 검증해보셨나요?
팀 차원에서도 AI 슬롭으로 보이지 않도록 리뷰 규칙을 정하는 게 좋아요. 세 가지만 챙겨도 충분히 달라집니다.
PR 템플릿에 AI 사용 여부 표시
AI로 초안을 만들었는지, 어디까지 직접 검증했는지 한 줄이라도 남기면 리뷰어가 어디를 더 꼼꼼히 봐야 할지 판단하기 쉬워집니다.
코드 리뷰에 ‘이해도 확인’ 질문 관행화
“왜 이 방식을 택했나요?” 한 줄만 리뷰 코멘트에 습관적으로 추가해도, 이해 없이 붙여넣은 코드를 걸러내는 효과가 큽니다.
공유 전 최소 1회 직접 다듬기
Slack 공지든 기술 문서든, 보내기 전 한 번은 스스로 읽고 손을 대야 해요. 그 한 번이 AI;DR로 분류되느냐 아니냐를 가릅니다.
지금 점검해보세요
내 산출물이 AI 슬롭으로 읽히고 있지 않은지, 아래 네 가지로 점검해보세요.
- 이번 주 보낸 PR 설명 중, 질문받았을 때 바로 답할 수 없는 부분이 있었나요?
- 팀 Slack에 올린 AI 산출물을 발행 전 직접 다듬었나요?
- 우리 팀 PR 템플릿에 ‘AI 사용 여부’ 항목이 있나요?
- 면접이나 자기소개서에서 “AI 산출물을 어떻게 검증하는지” 설명할 수 있나요?
관련 글
AI 시대의 코드 리뷰와 커리어 신호를 더 살펴보고 싶다면 아래 글도 참고해보세요.
- AI 코드 리뷰 도구가 바뀌면 리뷰 문화도 함께 바뀝니다 — AI 코드 리뷰 방식이 바뀐다, Zed Delta가 던지는 질문
- AI 산출물을 어떻게 평가할지 고민이라면 이 글이 도움이 됩니다 — LLM Evals가 뜨는 이유, 개발자 커리어에 던지는 신호
- 빠른 AI 모델 교체 주기가 채용시장에 주는 신호도 함께 보세요 — AI 모델 업데이트 속도, 개발자 채용시장에 던지는 신호
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요