최근 dev.to에서 화제가 된 Sylwia Laskowska의 글 Every Developer Is Lying About Something — And AI Won’t Fix It은 단순한 한탄이 아닙니다. “AI가 코드를 빠르게 만들어 줄 수는 있어도, 우리가 매일 자기 자신과 동료에게 하는 작은 거짓말은 그대로 남는다”는 주장이 핵심입니다.

이 글은 원문을 한국 시니어 개발자 시각에서 다시 읽고, METR 2025 무작위 통제 실험과 Stack Overflow 2024·2025 설문 데이터를 결합해 “AI 도구를 도입한 우리 팀이 정말 빨라졌는가”를 점검할 수 있는 체크리스트로 정리합니다.
1. 원문이 짚은 다섯 가지 ‘거짓말’
저자는 자신과 주변 개발자들이 반복적으로 빠지는 패턴을 다섯 가지로 정리합니다. 각 항목은 도덕적 비난이 아니라 인지 구조의 한계로 읽는 편이 정확합니다.
- 지금 무엇을 하고 있는지 안다고 말하는 것 — 새 코드베이스에 합류한 시점에는 사실상 아무도 전체 그림을 잡고 있지 못합니다.
- 방법을 안다고 말하는 것 — “할 줄 압니다”가 실제로는 “어떻게든 찾아보겠습니다”의 다른 표현인 경우.
- 시간이 있다고 말하는 것 — 시니어·리드일수록 “믿을 수 있는 사람”이라는 정체성에 갇혀 한계를 인정하지 못합니다.
- 걸리는 시간을 안다고 말하는 것 — 추정치는 자주 희망 사항을 숫자로 옮긴 결과물입니다.
- 모든 것을 가장 잘 안다고 말하는 것 — Angular vs React, Java vs Python 같은 종교 전쟁의 뿌리에는 자기 확신 편향이 자리 잡고 있습니다.
저자는 “코드보다 사람이 더 큰 변수”라는 결론을 던지면서, 이 다섯 가지가 AI 코딩 에이전트의 도입으로도 줄어들지 않는다고 지적합니다. 후배님이 본인 팀의 회고를 떠올렸을 때 익숙한 장면이 몇 개나 떠오르는지 한번 세어 보세요.
2. METR 보고서 2025 — 경험 개발자는 AI로 19% 느려졌다

원문이 지나가듯 언급한 “AI 도구가 오히려 개발자를 느리게 만들었다는 연구”는 METR(Model Evaluation & Threat Research)이 2025년 7월에 공개한 무작위 통제 실험을 가리킵니다. arXiv 사전출판 논문 Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity에 전체 방법과 데이터가 정리돼 있습니다.
- METR 발표 기준 참여 개발자 16명, 평균 해당 프로젝트 경험 5년, 총 246개 실제 오픈소스 작업이 무작위로 AI 허용/금지 조건에 배정됐습니다.
- METR 보고서에 따르면 AI 허용 조건의 평균 완료 시간은 금지 조건 대비 19% 더 길었습니다. 즉 도구가 평균적으로는 생산성을 깎았다는 결과입니다.
- METR 측정에 따르면 같은 참여자들이 실험 전에는 AI가 시간을 24% 줄여 줄 것이라고 예상했고, 실험 후 자체 평가에서도 20% 단축됐다고 답했습니다(METR 측정 기준). 같은 보고서 객관 데이터와는 약 40%p 차이가 벌어진 셈입니다.
METR은 둔화 원인으로 “AI 출력의 낮은 신뢰도”와 “검토·재작업 비용”을 지목합니다. 즉 모델이 그럴듯한 코드를 빠르게 내놓더라도, 시니어 입장에서는 원래 코드베이스 규칙과 어긋난 부분을 확인하고 다시 다듬는 시간이 더 들었다는 뜻입니다. 이는 원문에서 말한 “방법을 안다고 말하는 거짓말”이 AI를 매개로 더 빠르게 누적되는 구조와 정확히 맞물립니다.
한 가지 단서. METR 본문은 결과의 일반화를 경계합니다. 표본이 성숙한 오픈소스의 경험 개발자에 한정돼 신규 프로젝트나 주니어 비중이 높은 팀에서는 결과가 달라질 수 있습니다. “우리 팀에서 같은 측정을 해 본 적이 있는가?”라는 질문으로 받아들이는 편이 안전합니다.
3. Stack Overflow 설문 — 사용률은 오르고 신뢰는 내린다
Stack Overflow 2024 Developer Survey에 따르면 전 세계 응답자의 76%가 AI 도구를 이미 사용 중이거나 사용 예정이라고 답했고, 이는 전년 70%에서 6%p 증가한 수치입니다. 같은 설문 기준 “현재 사용” 응답률만 보면 44%에서 62%로 18%p 늘었습니다.
그런데 같은 보고서에서 AI 도구에 “호의적·매우 호의적”이라고 답한 비율은 72%로, 전년 77%에서 5%p 떨어졌습니다. 후속 Stack Overflow 2025 Developer Survey 기준으로는 사용·사용 예정 응답이 84%까지 올라갔지만, 호감도 지표는 계속해서 사용률 곡선과 벌어지고 있습니다.
요약하면 “많이 쓰지만 점점 덜 좋아한다”는 패턴입니다. 이는 METR의 객관 둔화 데이터와 자연스럽게 맞물립니다. 도구 자체가 나빠진 것이 아니라, 처음의 기대치가 너무 부풀어 있었고 실무에서 비용이 더 또렷하게 보이기 시작한 결과로 해석할 수 있습니다.
4. 한국 IT 팀에서 더 무겁게 작용하는 변수
4-1. 체면과 위계가 ‘모르겠습니다’ 비용을 키운다
원문이 “질문하기 두려운 분위기”를 글로벌 공통 문제로 짚었지만, 한국 팀에서는 호칭·연차·평가 구조가 이 비용을 더 키웁니다. 시니어가 먼저 “이 부분은 저도 정확히 모르겠습니다”라고 말하지 않으면, 주니어가 동일한 발화를 꺼내는 비용은 훨씬 더 큽니다. AI 코딩 도구가 도입돼도 “AI가 시켜서 짰는데 왜 안 되는지는 모르겠다”는 보고가 만들어지기 어려운 분위기는 그대로입니다.
4-2. AI 활용률 격차가 직군 안에서도 크다
잡코리아가 2025년에 발표한 직무별 AI 활용 조사 기준 기술·개발·데이터 직군은 마케팅·홍보(27.4%)에 이어 21.1%로 두 번째 상위 사용 직군입니다. 다만 같은 개발 직군 안에서 “매일 AI로 코드를 쓴다”는 인원과 “전혀 안 쓴다”는 인원이 양극단으로 갈리고, 사용 빈도가 다른 동료끼리 짝코딩·리뷰를 하면 추정과 실력에 대한 “거짓말”이 더 쉽게 발생합니다.
4-3. 추정·회고 문화의 미성숙
원문의 네 번째 “걸리는 시간을 안다고 말하는 거짓말”은 한국에서 더 위험합니다. 추정은 평가에 직결되고, 회고는 종종 “누가 지연시켰는가”를 찾는 자리로 변질됩니다. METR 결과를 그대로 옮긴 “AI를 도입하면 시간이 줄어든다”는 가정이 PM·PO에게 강한 압력으로 작용하면, 개발자는 추정을 더 낙관적으로 부풀리고 실제 결과는 더 자주 거짓말이 됩니다.
5. 시니어 입장에서 줄일 수 있는 비용

저자는 “마법 같은 해결책은 없다”고 인정하면서도, 본인이 효과를 본 한 가지로 “공개적으로 모른다고 말하는 것”을 꼽습니다. 한국 팀에 옮길 때는 발화 자체보다 그것을 가능하게 하는 구조가 더 중요합니다.
- 리더가 먼저 모름을 선언 — 시니어 본인이 회의 첫 발화로 “이 부분은 제가 정확히 이해 못 했습니다”를 1회 이상 의도적으로 사용합니다. 후배님께도 같은 발화의 허용 비용이 크게 떨어집니다.
- 추정 후행 데이터 기록 — 스토리 단위 “예상 시간 vs 실제 시간” 차이를 4주 단위로 측정. AI 도입 전후 비교가 가능해야 METR류 결과가 우리 팀에서도 재현되는지 알 수 있습니다.
- AI 출력 검토 비용 분리 기록 — 코드 리뷰 시간 중 “AI 생성 코드 정정”에 쓴 시간을 별도 태그로 기록. METR이 지목한 둔화 요인을 자체 측정으로 확인하는 출발점입니다.
- 회고에서 사람 비난 분리 — “누가”보다 “어떤 정보가 빠져서 결정이 어긋났는가”로 질문을 옮기면 다섯 가지 거짓말 중 두 개(시간·방법) 비용이 줄어듭니다.
네 가지 모두 도구가 아니라 의례입니다. 더 비싼 모델로 바꾸기 전에 “우리 팀 추정 정확도”라는 단일 지표를 4주만 측정해도 둔화 비용은 빠르게 드러납니다.
6. 도입 점검 체크리스트
AI 코딩 도구를 새로 들이거나 갱신하기 전에 다음 항목을 한 번씩 확인하면, 다섯 가지 거짓말이 도구를 매개로 증폭되는 시나리오를 어느 정도 사전 차단할 수 있습니다.
- 지난 4주 사내 측정 자료 기준으로 “예상 시간 vs 실제 시간” 오차가 30% 이내인 스토리 비중이 얼마나 됩니까?
- 최근 두 번의 회고에서 시니어가 “잘 모르겠습니다” 또는 “제 판단이 틀렸습니다”를 1회 이상 발화한 적이 있습니까?
- AI 생성 코드의 정정·재작성 시간을 별도 태그로 측정한 데이터가 1주 이상 누적돼 있습니까?
- METR 보고서가 짚은 “성숙 오픈소스 + 경험 개발자” 조건과 우리 팀이 얼마나 다른지 1줄로 설명할 수 있습니까?
- AI 도입 의사결정의 KPI가 “속도”인지 “리뷰·운영 비용 절감”인지 합의돼 있습니까?
한 항목이라도 “확인 안 됨”이라면, 도구 라이선스 비용을 늘리기 전에 측정 체계부터 정비하는 편이 우선입니다. METR 표본은 16명이지만, 같은 결과가 우리 팀에서 재현되는지는 우리만 답할 수 있습니다.
7. 관련 글
이 글에서 다룬 “도구 도입 vs 사람·운영 비용” 관점은 최근 발행한 다른 글들과 자연스럽게 이어집니다. 함께 읽으면 도입 의사결정 기준이 더 명료해집니다.
- AI 워크플로를 직접 자체호스팅으로 들이는 의사결정은 n8n 워크플로 자동화 — 한국 백엔드 자체호스팅 도입 체크리스트에서 운영 비용 관점으로 정리했습니다.
- 에이전트가 점점 더 많은 결정을 가져갈 때 백엔드 팀이 무엇을 지켜야 하는지는 헤드리스 SaaS 전환 — 에이전트 시대 백엔드 방어력 점검에서 다뤘습니다.
- 사람 사이의 점수·평판 시스템이 만드는 왜곡은 Obsidian 플러그인 스코어 논쟁 — 오픈 에코시스템 거버넌스 점검에서 다른 각도로 조명했습니다.
마지막으로 다시 짚어 둡니다. METR 보고서가 보여 준 19% 둔화는 “AI를 끄자”는 결론이 아니라, “우리 팀의 둔화율을 모른 채로 도입을 늘리지 말자”는 신호로 읽는 편이 정확합니다. 다섯 가지 거짓말은 AI 이전에도 있었고, 측정 없는 도입은 그 비용을 더 빠르게 누적시킵니다.
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요