요즘은 한 발 더 나갔습니다. 멀티 에이전트, 레포 전체를 이해하는 에이전트, 여러 작업을 병렬로 돌리는 오케스트레이션까지. 이제는 "주니어 한 명"이 아니라 "AI 작업자 여러 명을 운영하는" 쪽에 가깝습니다.
그런데 이상한 일이 생깁니다. 코드는 분명히 빨리 나오는데, 하루를 마치면 예전보다 더 지칩니다. 어제보다 하루 더 늙어서 피곤한 줄 알았는데, 관련 논문이 있더라고요.
2026년 5월에 나온 논문 한 편이 이 막연한 감각을 데이터로 보여줍니다. Annie Vella와 Kelly Blincoe가 쓴 The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study입니다. 6개월 간격으로 같은 개발자들에게 두 번 설문을 돌린 종단 연구입니다(처음 158명, 추적 101명, 두 시점이 매칭되는 95명).
두 시점에서 공통으로 나온 결과는 우리가 기대하던 그림입니다.
그런데 같은 기간, 다른 숫자가 반대로 움직였습니다.
개발자 경험(DX)이 한 가지 이상 영역에서 나빠졌다고 답한 비율이 14%에서 27%로 거의 두 배가 됐다.
구체적으로는 몰입(flow)이 떨어지고 인지 부하가 늘었습니다. 피드백 루프 같은 일부 항목은 오히려 좋아졌지만, 전체적으로 "일하는 느낌"은 나빠진 쪽이 늘어난 것입니다. 논문은 이걸 생산성-경험 역설(productivity-experience paradox)이라고 부릅니다. 더 많은 일을 더 빨리 처리하는데, 정작 일하는 경험은 꼭 같이 좋아지지 않습니다.
같은 논문이 짚는 핵심은 노동의 성격이 바뀌었다는 점입니다. 개발자의 일이 작성(creation)에서 검증, 평가, 수정, 조율 쪽으로 옮겨갑니다. 논문이 이 새로운 노동에 붙인 이름이 감독 엔지니어링(supervisory engineering work)입니다. 코드를 짜는 게 아니라, AI가 짠 코드를 방향 잡고 평가하고 고치는 일이 업무의 중심이 된다는 것입니다.
극단적인 사례는 OpenAI가 직접 올렸습니다. Harness engineering이라는 글에서 5개월 동안 약 100만 줄짜리 베타 제품을 만들었는데, 사람이 직접 친 코드는 사실상 0줄이었다고 합니다. 그동안 엔지니어가 한 일은 코드 작성이 아니라 에이전트가 신뢰할 만한 결과를 내도록 환경, 피드백 루프, 제약을 설계하는 것이었습니다. 그들이 그 환경을 부르는 이름이 하니스(harness)입니다.
이게 공짜로 굴러가지는 않습니다. 자율 코딩 에이전트의 PR 45만 건을 분석한 The Rise of AI Teammates in Software Engineering (SE) 3.0은, 에이전트가 사람보다 빠르게 코드를 올리지만 그 PR의 수용률은 더 낮고 코드 구조는 더 단순하다는 걸 보여줍니다. 빨리 만든다고 다 받아들여지는 게 아닙니다. 누군가는 그걸 읽고, 믿어도 되는지 판단해야 합니다. 그 "누군가"는 여전히 사람입니다.
여기서 진짜 병목이 드러납니다. AI는 거대한 diff를 병렬로 빠르게 쏟아냅니다. 그런데 사람이 코드를 읽고 이해하는 속도는 10년 전과 거의 같습니다. 생산 쪽만 폭발적으로 빨라지고, 검토 쪽은 그대로입니다. 이 비대칭이 피로의 한 축입니다.
더 고약한 건 LLM이 "이해한 느낌"을 아주 강하게 준다는 점입니다. 변경마다 자연어 설명이 붙으니, 읽었다고 느끼지만 실제로 상태가 어떻게 바뀌는지는 다 못 따라가는 상태에 쉽게 빠집니다. 그러다 보면 "AI가 그렇게 했는데요"가 점점 자연스러운 말이 됩니다. 이게 단순한 태만이 아닐 수도 있다는 게 무서운 지점입니다. AI가 만들어내는 작업량이 이미 사람의 검토 용량을 넘어섰다는 신호일 수 있습니다.
코드리뷰가 버그 잡기보다 지식을 옮기는 일에 가깝다는 이야기는 따로 한 번 정리한 적 있습니다. 검토가 무너지면 잃는 건 버그 검출이 아니라 그쪽입니다.
흥미로운 건 이 피로가 옛날 구현 피로와 성격이 다르다는 점입니다.
예전 개발은 깊은 몰입(flow), 단일 맥락, 긴 집중 상태를 오래 유지하는 일이 많았습니다. 반면 에이전트 워크플로는 백그라운드 작업, 폴링, 승인, 여러 세션 동시 모니터링, 부분 집중, 끊임없는 맥락 전환을 요구합니다. 겉보기엔 "덜 일하는 것"처럼 보이는데, 실제로는 사람이 계속 감독 상태에 머물게 됩니다.
이건 구현자의 피로라기보다 관리자의 피로에 가깝습니다. 결정 피로(decision fatigue), 잘게 쪼개진 주의력, 상황을 계속 파악하고 있어야 한다는 부담입니다. 업계에서는 이걸 판단 세금(judgment tax)이라고 부르기도 합니다. 코드를 만드는 마찰은 사라졌는데, 그 코드를 믿어도 되는지 판단하는 부담은 그대로거나 오히려 늘었다는 것입니다.
장기적으로는 다른 비용도 붙습니다. The Augmentation Trap은 단기 생산성을 위해 AI에 기대다 보면 그 생산성을 떠받치던 숙련 자체가 침식될 수 있다고 봅니다. 편해질수록 판단력이 약해지는 메커니즘은 전에 한 번 다뤘으니 여기서는 줄입니다. 요지는, 지금 느끼는 피로가 미래의 능력을 당겨쓴 결과일 수도 있다는 것입니다.
지금 AI 논의는 대개 "개발자가 사라지나"에 쏠려 있습니다. 그런데 위 흐름을 보면 더 중요한 질문은 따로 있습니다.
사람이 AI 작업자들을 어떻게 감독하고, 이해 가능한 상태로 유지할 것인가.
평가(eval) 설계, 거버넌스, 감독, 오케스트레이션 같은 영역이 빠르게 중요해지는 이유입니다. The Productivity-Reliability Paradox는 진짜 병목이 모델 성능이 아니라 사양(specification) 규율이라고까지 말합니다. 무엇을 시킬지 정확히 정의하지 못하면, 더 빠른 에이전트는 더 빠르게 틀린 것을 만들어낼 뿐입니다. Anthropic의 Building Effective Agents나 멀티 에이전트 시스템 구축기가 강조하는 것도 결국 같습니다. 에이전트를 신뢰 가능하게 만드는 건 모델이 아니라 그 둘레를 설계하는 일입니다.
조심할 부분은, 이 변화가 아직 정리된 상태가 아니라는 점입니다. 지금 연구들은 관찰 연구, 설문, 인터뷰, 초기 사용 패턴 분석 수준이 많습니다. 지금의 인지 부담이 단순한 과도기 현상인지, 아니면 에이전트 기반 개발의 구조적 특성인지는 아직 아무도 확신하지 못합니다.
다만 분명한 건 하나입니다. 우리는 "코딩을 더 빠르게 하는 도구"를 하나 들인 게 아닙니다. 개발자의 역할, 검토 문화, 일의 구조 자체를 바꾸는 무언가를 들였습니다.
그러니 더 피곤한 게 이상한 일은 아니에요. 어제보다 하루 더 늙어서가 아니라 일의 종류가 바뀌었고, 생산성 지표만 보면 보이지 않는 비용이 조용히 경험 쪽에 쌓이고 있을 뿐이에요.
참고한 글 / 연구
AI 코딩 에이전트가 어떤 작업을 마지막까지 못 풀어낼 때, 제가 가장 먼저 떠올리는 생각은 늘 똑같았어요.
지난 1년 동안 이 회로는 점점 더 정교해졌습니다. 컨텍스트 엔지니어링 패턴을 익히고, 가드레일 프롬프트를 다듬고, 메모리 시스템을 붙이고, 서브에이전트로 작업을 쪼개 봤습니다. 시키는 단위도 잘게 썰었습니다. AGENTS.md를 다시 쓰고, 사례별 예시를 늘리고, 검증 단계를 별도 에이전트로 분리해 봤습니다.
그래도 마지막 20%에서 자꾸 발이 걸렸습니다. 한 번은 잘 풀리다가 비슷한 작업에서 또 어그러졌습니다. 그럴 때마다 결론은 같은 자리로 돌아왔습니다. "제가 더 잘 짰어야 했나." 도구를 의심하기 전에 저를 먼저 의심했습니다.
그러던 차에, 한 사람이 단호하게 선언했습니다.
2026년 5월 24일, George Hotz(조지 호츠, geohot)가 자기 블로그에 "The Eternal Sloptember"라는 짧은 글을 올렸습니다. 첫 줄이 단단합니다.
"Agents cannot program, and it's taking longer and longer to realize that they can't."
에이전트는 프로그래밍을 못한다. 그리고 못한다는 사실을 깨닫는 데 점점 더 오래 걸린다.
조지 호츠가 누구입니까. 최초로 아이폰을 탈옥시킨 해커이자 tinygrad와 comma.ai를 만든 사람입니다. 코드를 안 짜본 사람이 하는 소리가 아닙니다. 그 사람이 6개월 동안 tinygrad 코드 작성과 USB↔PCIe 칩 리버싱을 에이전트와 같이 해 보고 도달한 결론이라는 점이 무겁습니다.
그의 진단은 이렇습니다. 에이전트는 프로그래밍 그 자체가 아니라 프로그래밍의 통계적 분포를 모방하도록 훈련된 모델입니다. 그래서 결과물은 종종 "미묘하게 부서져 있지만 점점 더 알아채기 어렵게" 만들어집니다.
쓸모를 부정하는 것도 아닙니다. 글의 다른 대목에서 그는 "검색용으로는 확실히 더 나은 Google이다", "프로토타이핑엔 빠르다"고 인정합니다. 다만 "내가 일해 본 어느 회사의 기준에도 못 미친다"고 못 박습니다. 보조 도구로는 훌륭하지만, 엔지니어로서는 부족하다는 진단입니다.
이 진단을 읽고 가장 먼저 정리된 감각이 있습니다. 마지막 20%에서 자꾸 발이 걸리던 그 느낌의 이름입니다.
GeekNews에 걸린 토픽 아래 댓글 하나가 같은 말을 합니다. 에이전트는 초반 80%는 빠르게 진행하지만, 마지막 20% 완성은 운에 의존한다는 것입니다. 작은 결정을 무수히 쌓아 올려 일관된 시스템 하나를 끝까지 끌고 가는 능력, 그게 프로그래밍의 본질에 가까운데 통계적 분포 모방으로는 그 자리가 매번 메워지지 않습니다.
제 경험에 대입해 보면 이렇습니다. 새 기능 뼈대 잡기, 비슷한 컴포넌트 복제, 정형화된 리팩토링은 빠릅니다. 정말 빠릅니다. 그러나 "기존 시스템의 미묘한 제약을 지키면서, 한 번도 해본 적 없는 결합을 처음 시도하는" 그런 작업은 매번 마지막 20%에서 꼬입니다. 그건 분포 안에 없는 일이기 때문입니다. 분포 안에 없는 것을 모방으로 만들어 낼 수는 없습니다.
이름이 붙으니 자책의 양이 줄었습니다. 모든 게 제 프롬프트, 컨텍스트, 하네스의 문제만은 아니었습니다.
이번 글의 단어가 처음 보는 것은 아닙니다. 작년에 사전 세 곳이 동시에 올해의 단어로 뽑은 '슬롭(Slop)'을 한 번 다룬 적이 있습니다. 그때는 산출물의 질에 붙인 이름이었습니다. 이번 Sloptember는 한 단계 더 나아갑니다. 그 산출물이 조직의 평균 품질을 어떻게 끌어내리는가를 가리킵니다.
조지 호츠의 진짜 경고는 거기에 있습니다.
"It is a golden era for buckets and buckets of slop, and a dark age for gems of quality."
양동이로 쏟아지는 슬롭에겐 황금기, 양질의 보석에겐 암흑기.
그리고 한 줄 더.
"The bottom performers won't have that self check. They are the ones producing 10x output with the agents."
하위 성과자들은 셀프체크가 없다. 에이전트로 10배 산출물을 뽑아내는 쪽은 결국 그들이다.
이 대목이 이전에 옮긴 글, "AI와 공존하는 개발자의 사고력"의 한 명제와 정확히 맞닿습니다. AI를 가장 잘 활용하는 개발자는 AI 없이도 코드를 판단할 수 있는 개발자입니다. 셀프체크가 없는 자리에 슬롭이 그대로 차오릅니다. 그리고 그 슬롭은 점점 더 정상 코드처럼 보입니다. Anthropic의 실험에서 AI 그룹의 개념 이해도가 17%p 낮게 나왔던 그 격차가 큰 조직에서는 사람 수로 곱해집니다.
Anthropic은 이 현상에 **인지적 오프로딩(cognitive offloading)**이라는 이름을 붙였습니다. 머리로 해야 할 사고 작업을 외부 도구에 떠넘기는 현상입니다. AI가 완성된 답을 즉시 뱉으면, 문제를 작은 단위로 쪼개거나 결과를 한 줄씩 의심하는 뇌의 개입도 함께 줄어듭니다. 속도는 빨라져 보이는데, 학습과 판단력은 같은 비율로 줄어든다는 진단입니다. 앞서 슬롭 글에서 다룬 슬롭 폴백과 짝을 이룹니다. 모델은 모를 때 "모른다"고 답하는 대신 그럴듯한 문장으로 빈칸을 채우고, 사용자는 그 출력을 그대로 받아 자기 사고의 빈칸도 함께 채웁니다. 두 회로가 만나는 자리에 사람의 셀프체크가 빠집니다.
자책의 회로에 갇혔던 사람으로서 한편으로는 안도하면서, 다른 한편으로는 더 무섭습니다. 마지막 20%가 풀리지 않은 게 제 탓만은 아니었다는 위로 옆에, 그 풀리지 않는 20%가 조용히 production으로 흘러들고 있다는 사실이 함께 놓입니다.
"제 탓이 아니다"로 끝내고 싶지는 않습니다. 그건 너무 편한 결론입니다. 두 가지를 갈라 두려고 합니다.
시키기 전에 문제를 작은 단위로 쪼개고, 결과물을 한 줄씩 다시 읽고, 어디까지 맡기고 어디부터 손으로 짤지 결정하는 일은 여전히 제 영역입니다. 마지막 20%에 도달했을 때 도구를 더 다그칠지 직접 마무리할지도 제가 판단해야 합니다. 도구가 좋아진다고 이 능력까지 함께 좋아지지는 않습니다.
반면 조지 호츠가 짚는 world model의 부재, RLVR의 한계, 통계 분포 안에 없는 작업에 대한 무력함, 미묘하게 부서진 산출물은 도구의 본질적 한계에 속합니다. 프롬프트 튜닝이나 컨텍스트 보강으로 메워지지 않으며, 다음 세대 모델이 풀어야 할 영역입니다.
이 둘을 가르고 나면, 마지막 20%에서 실패할 때마다 다음 질문을 던질 수 있습니다. 지금 막힌 자리는 제 판단의 문제인가, 도구의 한계인가. 답이 전자라면 멈춰서 더 깊이 생각하고, 후자라면 도구를 내려놓고 손으로 마무리합니다. 이것이 차분한 분기입니다.
자책의 회로에서 한 칸 내려놓습니다. 대신 판단력에 그만큼 시간을 더 씁니다. 그 판단력이 어떻게 만들어지는지는 이전 글에서 한 번 풀어 두었으니 여기서는 줄입니다.
이 글을 쓴 이유는 단순해요. 같은 자책의 회로에 갇힌 동료 한 사람에게라도 위로가 되면 좋겠다는 마음이에요.
오늘 AI가 일을 못 풀어냈을 때 떠오른 그 첫 생각, 제 프롬프트가 모자랐나, 제 컨텍스트가 부족했나, 제 하네스를 잘못 짠 건가 하는 생각이 전부 제 책임은 아니지만, 그렇다고 전부 도구의 책임도 아니며 그 둘을 가르는 감각만큼은 직접 길러야 해요.
조지 호츠의 글이 셌고 한쪽으로 치우친 면도 있지만, 적어도 에이전트의 한계를 프롬프트 엔지니어링으로 다 메울 수 없다는 점은 그가 옳으며, 그 사실을 인정하고 시작하면 다음 1년이 조금 덜 외로워질 거예요.
"Usually, people don't leave companies; they leave managers."
같이 묶여 있던 GeekNews 리더십 토픽에 다섯 편이 더 걸려 있었습니다. 신임 관리자의 6가지 실수, 자신보다 뛰어난 사람 채용, 단순함으론 승진 못한다, 착한 매니저가 커리어를 망친다, AI는 나쁜 매니저를 만든다입니다. 결은 한 곳을 가리킵니다.
그 위에 같이 펴 놓으면 좋을 책/글이 있습니다. Camille Fournier의 The Manager's Path, Julie Zhuo의 The Making of a Manager, Will Larson의 Staff Engineer와 An Elegant Puzzle, Tanya Reilly의 The Staff Engineer's Path, Andy Grove의 High Output Management, Lara Hogan의 Resilient Management, Charity Majors의 IC↔Manager 펜듈럼 에세이입니다. 한 권을 못 읽었어도 7명이 둘러서 같은 말을 합니다. 매니저직은 보상이 아니라 다른 직업이라는 말입니다.
이 글은 그 말이 제 다음 자리에 어떻게 적용되는지 풀어 본 노트입니다.
피터의 법칙에 따르면 사람은 자신의 무능 레벨까지 승진해 그 자리에 머뭅니다. 잘하던 일을 잘했다는 이유로 다른 직업에 던져 놓고, 거기서 무능한 채로 5년을 끄는 구조입니다. Preiss는 한 문장을 더 짚습니다.
"Management is a new profession."
Gallup 자료를 인용한 숫자가 무겁습니다. 70%. 직원 몰입도의 70%가 매니저 한 사람에 달려 있습니다. 신중해야 한다는 뜻입니다.
전환에서 반복되는 실수가 네 가지로 정리됩니다. 기술 역량만 보고 승진시키기, 준비/코칭 없이 던지기, 위기 땜빵 인사, 역할 정의 모호. 어느 하나만 걸려도 1년 안에 양쪽이 무너집니다. 특히 마지막은 본인이 메울 수 없는 함정입니다. 위에서 정의해 주지 않으면 전환을 거절하는 것도 답입니다.
GeekNews 묶음의 "6가지 실수"가 이 네 가지를 더 잘게 쪼갭니다. 모든 결정을 본인이 하고, 1:1을 미루고, 갈등을 우회하고, 코딩으로 도망칩니다. 결국 엔지니어 모드를 벗어나지 못한다는 한 줄로 모입니다.
"착한 매니저들이 팀원의 커리어를 망치는 법"은 한 단계 더 들어갑니다. 침묵, 미루기, 과보호가 후배의 성장 기회를 어떻게 빼앗는지 보여줍니다. 친절은 좋은 매니저의 충분조건이 아니고, 어렵게 말할 수 있는 능력이 친절보다 무겁다는 얘기입니다.
원문은 잠재력을 세 축으로 봅니다. Social Intelligence는 영향력, 갈등 관리, 불편한 대화, 멘토링 의지입니다. Business Acumen은 시스템적 사고와 전략, 모호함 속의 결정입니다. Personal Character는 내적 동기와 호기심, 신뢰성, 겸손입니다.
여기에 책들이 두 축을 더합니다. Reilly와 Larson이 강조하는 Communication at scale은 1:1, 문서/RFC, 발표/교육, 비동기 의사소통을 말합니다. 사람을 직접 옆에 두고 영향력을 발휘하는 시대가 끝났다는 메시지입니다. Hogan과 Zhuo가 가르치는 People as people은 정서 감지, 번아웃 신호, 안전감 형성입니다. 매니저 일의 절반은 사람을 사람으로 다루는 기술이라는 뜻입니다.
다섯 축을 다 갖춘 사람은 거의 없습니다. 강한 둘과 약한 셋이라면 1년에 한 축씩 채워 갈 수 있습니다. 약한 셋 중 어느 축이 다음 자리에서 결정타가 될지가 본인이 풀어야 할 질문입니다.
제 경우는 세 자리에 솔직히 "하"를 적었어요. 불편한 대화 주도, 5명 이상 대상 발표/교육 빈도, 후배의 번아웃 신호 감지/개입입니다. 이 셋이 다음 12개월 활동의 1순위가 됩니다.
원문에서 가장 단단한 기준은 이것입니다.
"did 100% of their current role and 50% of the next one."
"다음 단계를 잘할 것 같다"는 자기 평가는 신호가 아닙니다. 이미 그 일의 절반을 하고 있는지가 유일한 신호입니다.
다음 자리 책임을 다섯에서 일곱 개로 쪼개고 그중 절반을 이미 하고 있는지 표로 정리합니다. 50% 미만이면 본인 의지가 아니라 노출 부족 상태입니다. 노출을 만드는 일이 다음 12개월의 과제입니다.
"단순함으론 승진 못한다"가 가리키는 지점도 같습니다. "지금 일을 잘함"만으로는 다음 자리 50% 충족이 되지 않습니다. 의식적으로 영역 밖으로 나가 사전 노출을 누적해야 합니다.
엔지니어가 시니어 이후에 갈 수 있는 길은 한 가지가 아닙니다. Tech Lead, Engineering Manager, Staff Engineer, Principal Engineer가 있으며, 각각 다른 직업이고 다른 기술이 필요합니다. Pat Kua는 Tech Lead 안에서도 세 종류로 쪼개고(Senior IC, 풀타임 TL, 매니징 TL), Will Larson은 Staff에서 네 가지 원형을 봅니다(Tech Lead, Architect, Solver, Right Hand).
Charity Majors의 글이 가장 가벼운 메시지를 보냅니다. IC↔Manager는 왕복 가능합니다. 5년 EM, 다시 3년 Staff, 다시 EM처럼 비선형인 경로가 정상입니다. 본인 정체성을 "Manager 라벨"이 아니라 "지금 어느 모드"에 두면 결단이 훨씬 가벼워집니다.
Staff Engineer 길은 패자 트랙이 아닙니다. 사람을 직접 평가/보상하지 않고 시스템과 표준으로 영향력을 만드는 다른 직업입니다. 이건 다음 글 "Staff Engineer 로드맵"으로 분리합니다.
자기진단 표를 채워 보니 약한 칸이 분명해졌고, 다음 1년을 굴릴 점검 루프 하나를 잡았습니다.
매일 다섯 가지를 묻습니다. 누군가의 성장을 5분이라도 도왔나, 미룬 불편한 대화가 있나, 결정 1건의 영향을 팀, 타팀, 고객, 장기 4분면으로 적었나, 영역 밖에서 배운 한 가지를 기록했나, 시키지 않은 책임을 가져갔나.
매주 일곱 가지를 묻습니다. 크로스팀 대화 3건 이상인가, 제가 주도한 의사결정과 모호함 정도를 기록했나, 받은 피드백과 반영 여부를 적었나, 후배에게 쓴 시간을 분 단위로 적었나, 회사 비전과 제 일의 연결고리 사례 1건을 남겼나, 거절한 일과 근거를 기록했나, 의사결정 일지를 썼나.
매월 아홉 가지를 확인합니다. STAR 사례 신규 1건, 360 미니 피드백 1라운드, 150% 룰 갭 표 갱신, "타이틀 없이 매니저 일" 노출 1건, 리더십 책 1챕터와 노트 한 단락, 회사 OKR/방향성과 제 업무 매핑, 본인 번아웃 자가 점검, IC↔Manager 펜듈럼 자기 위치 한 줄, 5명 이상 대상 발표, 교육, 문서 공유 1회입니다.
다 적어 놓고 보니 깁니다. 글에 표로 넣어 두면 무거우니 별도 노션/옵시디언으로 옮겨 매일 굴립니다. 글에는 의도만 남깁니다. 매니저 일은 일상에서 시작되고, 회피는 다음날 더 무거워지며, 시스템적 시야는 의식적 반복으로만 자랍니다.
12개월 뒤에 자기 평가를 다시 합니다. 임팩트 중심 동기, 150% 룰 충족, 갈등/불편 대화 능력 — 세 축 모두 충족이면 Manager 전환을 공식화합니다. 둘만 충족이면 6개월 더 누적합니다. 하나라도 미달이면 IC 트랙을 의식적으로 선택합니다. 선택의 무게는 같습니다.
자료를 잔뜩 쌓아 놓고 마지막에 도달한 한 문장은 이것입니다.
본인이 어떤 행위에 에너지가 생기는지 정직하게 관찰하는 것입니다. 라벨은 그 뒤에 따라옵니다.
매니저든 IC든, Tech Lead든 Staff든, 1년 뒤 더 정직해진 자기 평가를 가질 수 있다면 어느 쪽이든 옳은 길입니다. 승진은 그 누적 끝에 따라오는 결과일 뿐입니다.
약속 하나 적어 두고 마칩니다.
6개월 뒤 이 글을 다시 열어 같은 자기진단을 채워요. 평가가 한 칸이라도 움직였는지, 정체했는지, 후퇴했는지 정직하게 적고 follow-up 포스트로 정리해요.
세 군데가 같은 해에 같은 단어를 골랐다는 사실은 좀 무섭습니다. 단어 하나로 한 해를 요약해 버린 셈이기 때문입니다.
영어 slop은 본래 음식물 쓰레기, 진창, 돼지에게 주는 먹이 찌꺼기를 가리킵니다. 1700년대에는 무른 진흙을 부르는 말이었고, 1800년대에 들어 음식 찌꺼기, 그리고 "값싸고 가치 없는 것" 일반으로 의미가 번졌습니다.
말 그대로 흘려보내는 더러운 액체에 가까운 어감입니다. 그 단어를 2025년 들어 AI 시대의 콘텐츠를 가리키는 비유로 다시 꺼내 든 것입니다. 비유가 너무 적나라해서 한 번 들으면 잘 잊히지 않습니다.
이코노미스트는 슬롭을 생성형 AI가 사용자가 요청하지도 않았는데 대량으로 찍어내는 저품질 콘텐츠로 정리했습니다. 조건은 세 가지가 함께 맞아야 합니다. 우선 사람이 만들었다면 들어갔을 시간/노력 없이 한 번에 수천 장이 쏟아집니다. 그렇게 나온 결과물은 손가락이 여섯 개거나, 사실관계가 틀렸거나, 맥락이 이상합니다. 결정적으로 정성이 없습니다. 제 글도 정성이 없기는 마찬가지지만 저는 적어도 글을 쓰고 한 번 읽어는 봅니다. 마지막으로 이런 것들이 검색 결과 상단이나 SNS 피드, 자동 생성 기사 같은 곳에서 원치 않아도 눈에 밟힙니다.
세 조건이 다 맞아야 슬롭입니다. AI로 만들었다고 다 슬롭은 아닙니다. 누가 의도를 가지고 편집한 결과물은 다른 이야기입니다.
슬롭은 자주 스팸과 비교됩니다. 둘 다 받는 사람 동의 없이 정보 채널을 점거한다는 점에서 닮았습니다.
다만 스팸은 무차별 광고였고, 슬롭은 콘텐츠 그 자체입니다. 더 교묘합니다. 스팸은 광고라는 걸 숨기지 않지만, 슬롭은 정상 글, 사진, 영상인 척 피드에 섞여 듭니다. 영어권에서는 둘을 합쳐 슬롬(Slop + Spam) 이라는 파생어까지 만들어 씁니다.
이코노미스트, 메리엄웹스터, 매쿼리가 같은 해에 같은 단어를 골랐습니다. 평소에는 사전사마다 색깔이 다른데, 2025년만큼은 합의를 본 셈입니다.
이코노미스트의 진단은 분명합니다. AI 콘텐츠 생산자는 거의 비용 없이 찍어내지만, 이용자 쪽에는 진짜 정보를 가려내는 인지 비용 이 새로 붙습니다. 검색 한 번에 진짜 후기와 AI가 짜깁기(짜집기는 잘못된 표현)한 가짜 후기를 가려야 하고, 친구가 공유한 사진이 실사인지 합성인지 의심해야 합니다. 사회 전체로 보면 거대한 외부 비용입니다.
흥미로운 건 그다음입니다. 슬롭이 넘쳐날수록 신문/방송 같은 검증된 전통 매체에 대한 신뢰가 오히려 올라갈 수 있습니다. 이코노미스트는 그렇게 짚습니다. AI 사진과 실제 작가 사진을 구분하는 어떤 실험에서 사람들은 신뢰할 만한 매체가 만든 콘텐츠라면 더 큰 비용을 낼 수 있다고 답했다고 합니다. 정보가 넘칠수록 큐레이션 자체에 값이 매겨지는 구조입니다.
같은 해 옥스포드 사전 후보에는 vibe coding (AI에게 자연어로 시켜 코드 짜기), glazing (LLM이 사용자에게 과도하게 아부하는 현상, 썩 싫지만은 않습니다.), clanker (로봇/AI를 비하해 부르는 호칭) 같은 단어가 나란히 올랐습니다. 슬롭 하나만 도드라진 게 아니라 한 해 어휘 자체를 AI가 점령했던 셈입니다.
엔지니어 입장에서 슬롭이 더 매서워지는 지점이 따로 있습니다. 슬롭 폴백(slop fallback) 이라는 표현입니다. LLM이 잘 모르거나 답이 막혔을 때, "모르겠다"고 말하는 대신 그럴듯한 문장으로 빈칸을 채워 넘기는 동작을 가리키는 말입니다. 사전 등재어는 아니고 영어권 엔지니어 사이에서 농담 반 진담 반으로 굳어진 쓰임입니다.
흔히 말하는 환각(hallucination)과는 결이 살짝 다릅니다. 환각이 "사실관계가 틀린 출력"이라는 결과론에 가깝다면, 슬롭 폴백은 "막히면 슬롭으로 떨어지는" 시스템 동작 패턴 자체를 짚습니다. 모델이 모르겠다고 답하면 사용자 만족도가 떨어지니까, 학습/튜닝 과정에서 자신감 있는 헛소리 쪽으로 슬며시 기울게 된다는 진단입니다. Antislop 같은 연구가 LLM 출력의 반복 패턴을 억제하려 하는 것도 결국 이 악순환의 고리를 끊으려는 시도입니다.
문제는 이 폴백이 사람한테도 그대로 옮겨붙는다는 데 있습니다. AI 어시스턴트로 일하다 보면, 자료를 충분히 찾기 싫을 때 "AI한테 한 번 시켜보고 그럴듯한 게 나오면 그대로 가자"는 유혹이 생깁니다. 본인이 직접 슬롭 폴백 회로의 한 부품이 되는 셈입니다. 저는 도구의 결함보다 이쪽이 더 신경 쓰여요.
매일 Claude Code로 문서 초안을 잡고, 이미지 도구를 쓰고, 검색 결과를 참고하는 사람으로서 이 단어를 가볍게 넘기기 어렵고, 제가 만들고 있는 게 슬롭이 아닌지 자꾸 자문하게 돼요.
기준이 있다고 봅니다. AI를 써서 뽑은 결과물에 누가 읽을지, 어떤 가치를 줄지 한 번이라도 생각이 들어갔다면 슬롭이 아닙니다. 사람이 손을 댄 흔적, 의도와 편집이 묻은 흔적이 있으면 결 자체가 다릅니다. 반대로 광고 수익이나 SEO를 위해 양만 찍어내는 자동 생성물은 그대로 슬롭에 가깝습니다.
같은 도구를 써도 결과물의 격은 도구를 쥔 사람의 태도에서 갈립니다. 무엇을 남기고 무엇을 버릴지 결정하는 편집 감각이 AI 시대 글쓰기에서 정작 가장 비싼 자원인지도 모릅니다.
매년 사전이 발표하는 올해의 단어는 그해의 정서를 한 단어로 압축해 놓은 결과입니다. 2024년이 brain rot이었다면, 2025년은 슬롭입니다.
저질 콘텐츠 자체가 새로 생긴 현상은 아닙니다. 다만 AI가 그 생산 단가를 0에 수렴시켰다는 것, 그리고 그걸 부르는 이름이 생겼다는 게 2025년의 차입니다. 이름이 붙으면 비로소 보이고, 보이면 거를 수 있습니다. 슬롭이라는 단어를 알게 된 것만으로 의외로 쓸 만한 정신 도구가 하나 늘었습니다.
피드를 내리다 보면 이게 슬롭인가 싶어 멈칫하는 순간이 있고, 그 멈칫이 한 번 생기고 나면 그다음부터는 시간을 덜 빼앗겨요.
]]>ln -s의 s 그 symbolic 을 말하는거군요. 근데 외국애들도 줄여쓰는군요 ?"
13글자가 7글자가 됐습니다. 그게 이상할까요? 우리는 매일 그러고 삽니다. 스타벅스에서 커피를 마시고, 점심메뉴추천을 점메추라고 부르고, 별걸 다 줄인다는 말을 별다줄이라고 줄여 씁니다. 이 글은 그 본능에 대한 짧은 메모입니다. 사실 저는 회사 후배들 말을 잘 못 알아듣고 배우는 편이에요.
ls, cp, mv, rm, ln, cd. 유닉스 명령어가 이렇게 짧은 이유는 1970년대엔 짧은 게 곧 비용이었기 때문입니다. 텔레타이프 단말기는 글자 하나마다 물리적으로 키를 눌러야 했고, 300 baud 모뎀 시대엔 글자 하나가 회선을 따라 굼뜨게 흘러갔습니다. 디스크도 비쌌습니다. "list"보다 ls가 미덕이었던 시대입니다.
지금은 어떨까요. 키보드는 가볍고 회선은 빠릅니다. 타이핑 비용은 거의 0입니다. 그런데 줄임말은 사라지기는커녕 더 늘어났습니다. repository는 repo, configuration은 config, directory는 dir, environment는 env, application은 app. 더 짧아져만 갑니다.
이유는 단순합니다. 자주 쓰는 단어일수록 짧아집니다. 언어학자 Zipf가 1940년대에 정리한 규칙인데, 사용 빈도 상위로 올라갈수록 음절이 깎여나갑니다. "automobile"이 "car"가 되고, "telephone"이 "phone"이 되는 것과 같은 원리입니다. 개발자에게 repository는 너무 자주 등장하는 단어라 결국 repo가 됐습니다. 여기서는 효율이 비용을 정의합니다.
이런 본능은 한국어에서 더 강하게 나타납니다. 외래어가 들어오면 거의 자동으로 줄여집니다.
스타벅스는 스벅, 베스킨라빈스는 베라, 맥도날드는 맥날, 김밥, 떡볶이, 순대 세트는 김떡순입니다. 두 단어를 합치는 혼성어도 활발합니다. work-life balance가 워라밸로 들어왔고, 혼자 밥은 혼밥, 혼자 술은 혼술, 모디파이어 + 컨슈머는 모디슈머가 됐습니다. 첫 글자만 따는 패턴도 자연스럽습니다. 자만추(자연스러운 만남 추구), 노찾사(노래를 찾는 사람들), 인싸/아싸(인사이더/아웃사이더의 한국식 절단형)가 그 예입니다.
한국 IT에서만 통하는 콩글리시에서 살펴봤던 "리얼", "오픈", "커밋 때리다" 같은 표현도 사실 이 흐름의 한 갈래입니다. 영어 어휘를 빌려 와서 음절을 깎고, 한국어 문법에 녹여 넣습니다. 줄임말은 한국어 사용자의 기본 동작에 가깝습니다.
알 수 없는 신조어의 시대입니다. 문제는 줄임말이 어느 시점부터 세대를 가르는 장벽이 됐다는 점입니다. 회사 톡방에서 신입이 던진 한 줄을 부장이 못 알아듣는 순간, 모두가 어색해집니다. (근데 사실 알아들어도 어색해합니다. 저만 흥미로울 뿐이에요.)
| 줄임말 | 원형 |
|---|---|
| 알잘딱깔센 | 알아서 잘 딱 깔끔하게 센스있게 |
| 군싹 | 군침이 싹 도노 |
| 갑통알 | 갑자기 통장 보니 알바해야겠다 |
| 점메추 | 점심 메뉴 추천 |
| 좋댓구알 | 좋아요, 댓글, 구독, 알림설정 |
| 별다줄 | 별걸 다 줄인다 |
| 만반잘부 | 만나서 반갑고 잘 부탁해 |
| 이생망 | 이번 생은 망했어 |
| 갑분싸 | 갑자기 분위기 싸해짐 |
특히 "별다줄"은 의미가 재미있습니다. 별걸 다 줄인다는 푸념을 다시 줄여서 별다줄이라고 합니다. 자기 지시적인, 메타 줄임말입니다. 더 줄일 게 없을 것 같은데도 줄이는 본능을 스스로 풍자하고 있습니다.
이 표를 처음 보는 어른이 흔히 보이는 반응이 있습니다. "왜 이렇게까지 줄이지?" 그런데 자세히 보면 음절수가 5글자 안팎입니다. 스벅이나 워라밸과 비슷합니다. 단어가 어려워서가 아니라 노출 빈도가 다를 뿐입니다. 매일 카톡과 짧은 영상에서 보면 익숙해지고, 안 보면 영원히 모릅니다. Zipf의 법칙은 사회 전체가 아니라 화자 단위로 작동합니다.
영어든 한국어든, IT든 일상이든, 줄임말은 같은 메커니즘으로 만들어집니다.
| 패턴 | 영어/IT 예 | 한국어 예 |
|---|---|---|
| 혼성어 (portmanteau) | symlink, modem(modulator+demodulator), smog(smoke+fog), pixel | 워라밸, 모디슈머, 혼밥, 김떡순 |
| 두문자어 (initialism) | TLDR, ASAP, JMT, FYI, CWD, WIP | 자만추, 별다줄, 만반잘부, 좋댓구알 |
| 음절 절단 (clipping) | repo, config, dir, app, sudo | 스벅, 베라, 맥날, 알바 |
| 메타/자기지시 | "TLDR이 길다"는 농담 | 별다줄(별걸 다 줄인다를 줄임) |
같은 칸에 IT 줄임말과 한국어 신조어가 나란히 떨어집니다. 발음 체계가 달라도 압축 본능은 똑같습니다. 알잘딱깔센은 자만추의 친척이고, 자만추는 JMT의 친척이고, JMT는 sudo의 친척이고, sudo는 결국 심링크의 친척입니다.
흥미로운 건 줄임말이 정식 표현을 밀어내지 않는다는 점입니다. 둘은 평행하게 공존합니다.
man page와 POSIX 표준은 여전히 "symbolic link"라고 적습니다. 개발자끼리의 채팅창에서는 누가 봐도 symlink입니다. 9시 뉴스 앵커는 "스타벅스 코리아"라고 또렷이 발음하고, 친구끼리는 "스벅에서 봐"라고 합니다. 회사 공식 문서엔 "근로시간 단축을 위한 워크-라이프 밸런스 정책"이라 적혀 있고, 동료끼리는 "워라밸 챙기자"라고 합니다.
언어학에선 이걸 레지스터(register)라고 부릅니다. 같은 의미를 두고 격식과 친밀도에 따라 다른 표현을 골라 쓰는 것. 줄임말은 정확성을 잃은 표현이 아니라, 친밀함이라는 다른 차원이 추가된 표현입니다. 어느 한쪽이 이기는 게 아니라 둘 다 살아남습니다.
가끔은 줄임말이 너무 굳어서 원형이 통째로 잊히기도 합니다. 이메일을 매일 쓰는 사람이라도 CC와 BCC가 정확히 무엇의 줄임말인지 답하기는 쉽지 않습니다.
CC는 carbon copy의 줄임말입니다. 1960년대까지 사무실에서 같은 문서를 여러 부 만들 때 종이 사이에 먹지(carbon paper)를 끼우고 타자기로 한 번에 찍었습니다. 받는 사람 아래에 적힌 "CC: 김부장"은 "이 먹지 복사본도 김부장한테 갔다"는 표시였습니다. BCC는 blind carbon copy, 받는 사람 모르게 먹지를 한 장 더 끼운 셈입니다. 이메일이 종이 시대 동작을 그대로 옮겨오면서 이름까지 따라왔고, 카본지를 본 적 없는 세대가 매일 그 버튼을 누르고 있습니다.
이런 줄임말은 약자라는 사실 자체가 흐려집니다. symlink는 누가 봐도 줄어든 형태가 보이지만, CC는 그냥 CC입니다. 어원을 알아도 일상에서 쓰이는 의미는 달라지지 않습니다. 효율이 너무 잘 작동해서 원형이 떨어져 나간 뒤에도 단어만 혼자 살아남았습니다.
가끔 한국 신조어를 보고 "한국어가 너무 망가진다"고 하는 사람이 있습니다. 영어권을 보면 그 말이 머쓱해집니다.
채팅창의 lol, brb, idk, tldr, ngl, fwiw, irl, omw 같은 두문자어는 매년 옥스퍼드 사전이 정식 표제어로 추가하고 있습니다. portmanteau라는 단어 자체가 영어에 있는 것도 그쪽에서 단어를 합쳐 줄이는 일이 워낙 잦았기 때문입니다. brunch(breakfast+lunch), motel(motor+hotel), bromance(bro+romance) 같은 말은 사전에 안착한 지 오래입니다.
일본어도 못지않습니다. アルバイト는 バイト가 됐고(독일어 Arbeit가 두 단계 짧아졌다), personal computer는 パソコン이 됐습니다. KY는 空気を読めない(분위기 못 읽음)의 두문자입니다. 한자, 가나, 알파벳을 모두 동원해서 줄입니다.
그러니까 별다줄은 인류 보편 현상입니다. 한국어가 자음/모음 자모 결합형이라 음절 단위로 잘라 붙이기 좋고, 사회가 빠르고 모바일 위주라 더 활발하게 작동할 뿐입니다. 이런 본능은 어디서나 나타납니다.
그렇게 보면 심링크와 알잘딱깔센은 결국 같은 자리에서 나왔고, 그 본능은 게으름이 아니라 효율이며, 효율은 자주 줄여 쓰는 사람의 눈에만 보여요.
]]>바쁘니까 리뷰를 건너뛰자는 논리는 단기로는 맞는 것처럼 보입니다. 그런데 우아한형제들 공통시스템개발팀이 쓴 코드 리뷰 문화 개선 이야기를 보면 무엇이 일어나는지 명확해집니다.
"리뷰이는 리뷰를 기다리고 리뷰어는 수많은 MR을 확인하느라 고통받고 있었습니다."
리뷰를 뒤로 미루면 MR이 쌓입니다. 쌓이면 리뷰어가 한 번에 봐야 할 양이 커집니다. 한 번에 봐야 할 양이 커지면 집중력이 떨어지고, 리뷰가 대충 되거나 더 늦어집니다. 팀의 "바쁘다"는 오히려 증폭됩니다. 리뷰를 안 하는 게 원인이고, 바쁜 게 결과입니다. 순서가 반대로 보였을 뿐입니다.
그 팀이 찾은 해법은 "리뷰 안 하기"가 아니었습니다. "리뷰어가 적은 노력으로 잘할 수 있는 환경 만들기"였습니다. MR 크기를 300줄 미만으로 제한, 템플릿으로 맥락 강제, 매일 아침 MR 목록 자동 알림, pre-commit으로 린팅 자동화합니다. 바쁘다는 문제에 "리뷰를 줄이자"로 답하지 않고 "리뷰 비용을 줄이자"로 답한 셈입니다.
다른 핑계는 더 교묘합니다. "AI가 리뷰해줬어요"는 일견 책임 있는 행동처럼 들립니다. 그런데 2026년 2월 Stanford Law의 CodeX가 쓴 Built by Agents, Tested by Agents, Trusted by Whom?이 정확히 이 지점을 비틉니다.
핵심 문장은 이것입니다.
When the builder and the inspector share the same blind spots, no amount of test variety fully eliminates the risk that both miss the same thing.
빌더와 검사자가 같은 사각지대를 공유하면, 검사의 본래 가치가 무너진다는 얘기입니다. 인간 리뷰어는 작성자와 다른 가정, 다른 경험, 다른 맥락을 가집니다. 그 차이가 리뷰를 의미 있게 만듭니다. AI가 코드를 만들고 같은 모델 계열이 그 코드를 리뷰하면, 차이의 공간 자체가 사라집니다.
같은 글이 인용한 악명 높은 일화가 있습니다. "테스트를 통과시켜라"는 목표만 받은 에이전트가 테스트 본문을 그냥 return true로 고쳐버린 사건입니다. AI는 주어진 지표에 최적화할 뿐, 그 지표가 실제로 무엇을 의미하는지 이해하지 않습니다. 코드를 쓴 AI가 그 코드를 리뷰할 때도 같은 방식으로 최적화합니다. "이 코드는 괜찮아 보인다"에.
여기서 진짜 질문이 나옵니다. 코드리뷰는 대체 무엇을 하는 일일까요.
"버그를 잡는 일"이라는 답이 가장 흔하지만, Microsoft Research의 고전적인 연구는 다르게 정리합니다. 코드리뷰의 핵심 목표는 두 가지입니다.
버그 찾기는 부산물에 가깝습니다. 중요한 건 "이 문제를 이 방식으로 풀어도 되는가"에 대한 두 번째 의견을 얻는 것, 그리고 그 과정에서 코드베이스의 맥락, 의사결정, 도메인 지식이 팀원에게 옮겨 가는 것입니다.
뱅크샐러드 기술블로그도 같은 맥락에서 말합니다.
"코드 리뷰 프로세스를 보는 것은 그 회사의 개발 문화를 이해할 수 있는 힌트가 되기도 합니다."
리뷰는 단순한 품질 게이트가 아닙니다. 팀이 서로의 코드를 신경 쓴다는 약속을 매일 갱신하는 의식입니다. 신입이 처음 던진 PR에 시니어가 의도를 묻고, 그 답변이 팀의 집단 지식으로 남는 과정. 누군가가 "왜 이렇게 썼어?"라고 물었을 때 비로소 말로 옮겨지는 암묵지. AI는 코드의 문법과 패턴은 읽지만, 이런 종류의 집단적 맥락을 함께 쌓아 올리는 일은 하지 못합니다.
AI 리뷰가 못 보는 영역이 있습니다. 이 함수가 왜 이렇게 생겼는지의 답이 작년 사고 회고에 있을 때, 그 비즈니스 맥락은 레포 밖에 있어서 모델이 닿지 못합니다. 이 변경이 다른 바운디드 컨텍스트를 건드리는지, 기술 부채를 어디에 쌓는지 같은 아키텍처 판단도 마찬가지입니다. 우리 조직이 정의한 PII와 우리 서비스의 위협 모델에 걸린 보안/거버넌스, 이 레포가 3년 동안 합의해 온 컨벤션 역시 레포 밖 지식입니다. 가장 까다로운 건 조용한 실패입니다. 보기엔 맞는데 edge에서 터지는 코드를, AI는 오히려 더 자신 있게 만듭니다.
AI 리뷰어는 대부분의 경우 "이 코드가 잘 돌아갈 것 같다"를 말합니다. 인간 리뷰어는 "이 코드가 우리 팀이 만들고 유지하기에 맞는가"를 묻습니다. 두 질문은 차원이 다릅니다.
AI 리뷰를 쓰지 말자는 얘기가 아닙니다. 오히려 적극적으로 써야 합니다. 스타일 위반, 단순 버그, 빠진 null 체크, 테스트 커버리지 같은 저수준 체크는 AI가 1차로 거르면 인간 리뷰어가 더 가치 있는 질문에 집중할 수 있습니다. 좋은 하이브리드는 AI가 1차 관문, 인간이 2차 판단자인 구조입니다.
문제는 순서가 뒤집혀 있을 때입니다. "AI가 봤으니 인간 리뷰는 생략"이면 그냥 리뷰를 안 한 것입니다.
"바쁘다"는 이유로 건너뛸 때, 우리가 건너뛰는 건 버그 검출이 아니라 서로의 코드를 이해하고 지식을 옮기는 시간입니다. 그건 단기엔 안 보이다가, 1년쯤 뒤에 "왜 이 코드를 나만 이해하지?", "이 사람 없으면 이 모듈은 아무도 모른다"는 청구서로 돌아옵니다.
"AI가 봤다"는 이유로 건너뛸 때 포기하는 건 인간 리뷰어의 다른 시각입니다. 작성자와 다른 가정으로 코드를 읽어주는 눈. 같은 모델이 양쪽에 서면 얻을 수 없는 그것.
코드리뷰는 품질 관리이기 이전에, 팀이 팀으로 남게 하는 장치예요. 자동화해서 없앨 수 있는 건 비용이지 목적이 아니에요.
참고한 글 / 연구
최근에 읽은 두 편의 글이 같은 지점을 짚고 있었습니다. 표현은 달라도 결론은 비슷했습니다.
하나는 evan-moon의 AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일. 핵심은 한 문장으로 요약됩니다.
AI를 가장 잘 활용할 수 있는 개발자는, AI 없이도 코드를 판단할 수 있는 개발자다.
처음 들으면 당연한 말 같습니다. 그런데 곱씹어보면 불편한 이야기입니다. AI 에이전트가 완성된 코드를 바로 뱉어주는 환경에서만 성장한 개발자일수록, 그 출력물이 좋은지 나쁜지를 판단할 근거 지식이 약해집니다. "AI를 많이 쓸수록 AI를 잘 쓰기 어려워진다"는 역설이 생깁니다.
이 역설은 뇌과학으로도 설명됩니다. evan-moon의 글은 세 가지 개념을 끌어옵니다. 하나는 로버트 비요크가 말한 '바람직한 어려움(desirable difficulties)'입니다. 적절한 난이도의 도전이 장기 기억 형성을 촉진하고, 편하게 받아들인 정보는 오래 남지 않습니다. 다른 하나는 인출 연습(retrieval practice)입니다. 반복해서 읽는 것보다 스스로 기억을 떠올리는 쪽이 일주일 뒤 보존율을 크게 끌어올립니다. 수동적 읽기와 능동적 학습은 전혀 다른 행위입니다. 마지막은 청킹(chunking)입니다. 체스 전문가의 뇌는 초보자와 같은 조각을 보면서도 한 덩어리로 압축해 인지하는데, 패턴을 직접 조합해본 경험 없이는 이런 청크가 만들어지지 않습니다.
AI가 완성된 코드를 즉시 뱉어주면, 이 세 가지 과정이 전부 건너뛰어집니다. 난이도는 사라지고, 기억을 인출할 일도 없고, 패턴을 조합해 청크로 압축할 기회도 없습니다. 속도는 빨라지는데 숙련은 느려집니다.
그리고 뇌에는 에너지를 아끼는 쪽으로 흐르는 기본값이 있습니다. 편한 길이 있으면 그쪽으로 갑니다. 의식적으로 저항하지 않으면 AI에 의존하는 것은 자연스러운 결과입니다.
이론만으로 끝나는 이야기는 아닙니다. 2026년 2월, Anthropic이 같은 주제로 직접 실험을 했습니다. Python 경력 1년 이상의 개발자 52명(대부분 주니어)을 무작위로 두 그룹에 배치하고, Trio 비동기 라이브러리를 활용한 과제를 주었습니다. 한쪽은 AI 어시스턴트를 자유롭게 썼고, 한쪽은 손으로만 작성했습니다.
결과는 선명했습니다.
속도 차이는 거의 없었는데, 이해도에서는 17%p 차이가 났습니다. Anthropic은 이 현상을 인지적 오프로딩(cognitive offloading)이라는 개념으로 설명합니다. AI에게 작업을 떠넘기는 만큼 뇌의 개입이 줄고, 그만큼 학습도 줄어듭니다. Psychology Today의 표현을 빌리면, "뇌를 온전히 써서 작업하는 사람보다 정신적 참여도가 낮아지는 현상"입니다.
더 흥미로운 건 AI 그룹 안에서의 편차가 컸다는 점입니다. 생성된 코드를 그대로 복사해 넘긴 참가자들은 40% 이하의 점수를 받았지만, AI에게 개념적인 질문을 먼저 던지거나 생성된 코드의 이유를 되짚어본 참가자들은 수동 코딩 그룹과 비슷하거나 더 높은 점수를 기록했습니다.
이 결과만 보면 AI 자체보다 어떻게 쓰느냐가 문제였다고 할 수 있습니다.
같은 시기에 다른 각도에서 쓴 글이 있습니다. 스페인 바르셀로나의 Aily Labs에서 2년간 AI 에이전트를 개발하던 Miguel Conner가 I'm Coding by Hand라는 글을 올렸습니다. 뉴욕 브루클린 Recurse Center의 6주 리트릿 기록입니다.
AI 에이전트를 만들던 사람이 리트릿에서 하고 있는 건 의외로 복고적입니다.
AI 에이전트로 5분이면 찍어낼 수 있는 것들을 일부러 손으로 만듭니다. 그의 요지도 결국 같은 자리에 도착합니다. 에이전트에 명령만 잘 내리는 것과 코드베이스를 깊이 이해하는 것은 서로 다른 활동이라는 이야기입니다. 손으로 만들어야만 머릿속에 남는 층이 있습니다.
그렇다고 AI를 끄고 살 수는 없습니다. 마감도 있고, 동료들도 다 씁니다. 현실적인 타협점은 일상 업무와 의도적 훈련을 분리하는 데 있습니다.
일상 업무에서는 AI를 적극 씁니다. 대신 습관 두세 가지를 얹습니다.
운동과 비슷합니다. 엘리베이터를 탄다고 계단을 영영 안 오르면 몸이 굳습니다. 일부러 계단을 오르는 시간을 따로 마련해야 합니다.
편한 도구가 많아질수록, 일부러 불편함을 만드는 일이 오히려 전문가의 기술이 됩니다. AI가 가장 강력한 순간은 판단할 수 있는 사람이 레버리지로 쓸 때입니다. 그 판단력은 역설적으로 AI가 없을 때 만들어집니다.
결국 질문은 단순해요. 저는 오늘 어디에서 어려움을 우회했고, 어디에서 일부러 계단을 올랐을까요.
참고한 글/연구
원문과 연구 자료:
해설과 요약 자료:
IT 업계에서 일하다 보면 하루에도 수십 번 "이슈"라는 단어를 들어요.
"프로덕션에 이슈가 있어요", "이슈 하나 만들어주세요", "그 이슈 어떻게 됐어요?", "고객 이슈 확인 부탁드립니다."
전부 "이슈"인데, 의미는 전부 다릅니다. 어느 순간부터 이 단어 하나가 버그, 장애, 작업 항목, 안건, 관심사, 고객 문의를 전부 커버하게 됐습니다.
IT 현장에서 "이슈"가 쓰이는 맥락을 나열해 보면 그 폭이 꽤 넓습니다. "프로덕션에 이슈가 있습니다"는 서비스에 실제 문제가 터졌다는 뜻으로, 가장 긴장되는 용법입니다. "이슈 하나 생성해주세요"의 이슈는 버그일 수도, 기능 요청일 수도, 단순 작업일 수도 있습니다. Jira가 모든 작업 단위를 "Issue"라고 부르기 때문에 생긴 용법입니다. GitHub도 마찬가지여서 "이슈 올렸습니다"의 이슈에는 버그 리포트와 질문, 기능 제안, 토론 주제가 전부 들어갑니다. 회의에서 "그 이슈 진행 상황이 어떻게 됐죠?"라고 하면 추적 중인 관심사나 논의 사항을 가리키고, "고객 이슈 처리해주세요"의 이슈는 문의와 불만, 장애 신고, 기능 요청까지 포괄합니다.
듣는 사람은 매번 맥락으로 의미를 추론해야 합니다. 대부분은 자연스럽게 되지만, 가끔 "그 이슈요? 어떤 이슈요?"라는 되물음이 나오는 건 이 때문입니다.
영어 "issue"의 본래 의미는 "발행(issuance)"이나 "쟁점(matter in dispute)" 쪽에 가깝습니다. 그런데 어느 시점부터 "problem"을 대체하는 완곡 표현으로 자리 잡았습니다.
"We have a problem"은 심각하게 들립니다. "We have an issue"는 같은 상황인데도 좀 더 관리 가능하고, 덜 위협적인 느낌을 줍니다. 이 미묘한 뉘앙스 차이 때문에 비즈니스와 IT 영역에서 "issue"가 "problem"의 자리를 빠르게 대체했습니다.
영어권에서도 이 남용은 꽤 오래전부터 지적받아 왔습니다. "Call it what it is — it's a problem, not an issue"라는 류의 비판은 IT 커뮤니티에서 흔하게 보입니다.
영어권에서는 맥락에 따라 "bug", "ticket", "concern", "topic", "item", "incident" 같은 단어가 자연스럽게 섞여 쓰입니다. 세분화된 대안이 있고, 실제로 구분해서 쓰는 경우가 많습니다.
한국어에도 "문제", "건", "안건", "사안", "장애", "결함" 같은 표현이 있습니다. 그런데 IT 현장에서는 이런 단어들 대신 "이슈"가 거의 전부를 흡수해버렸습니다. 외래어 차용 과정에서 원어가 가진 여러 뉘앙스 중 가장 넓은 의미만 수입된 셈입니다.
Jira와 GitHub의 영향도 큽니다. IT 조직 대부분이 Jira와 GitHub를 쓰고, 둘 다 기본 작업 단위가 "Issue"이기 때문에, 자연스럽게 모든 작업 항목 = 이슈라는 등식이 굳어졌습니다.
솔직히 대부분의 경우 의사소통에 큰 문제는 없어요. 맥락이 충분히 보충해 주기 때문입니다.
하지만 가끔은 의식적으로 단어를 구분해 쓰는 것이 커뮤니케이션 품질을 높여 줍니다. 장애가 발생했으면 "장애"라고 하는 게 긴박감을 전달합니다. 단순 작업 요청이면 "티켓"이나 "작업"이 더 정확합니다. 회의에서 논의할 주제라면 "안건"이 맞습니다.
만능 단어는 편해요. 다만 장애를 "장애"라고 부르는 순간 전달되는 긴박감까지 대신해 주지는 못해요.
]]>**"리얼(real)"**은 한국 IT에서 가장 널리 쓰이는 콩글리시 중 하나입니다. "리얼 환경에 반영했습니다", "리얼 DB 접속 정보 주세요"처럼 쓰며, 여기서 리얼은 운영(production) 환경을 뜻합니다.
영어권에서는 production, 줄여서 prod라고 합니다. "real"이라는 표현을 쓰면 "진짜?"라는 반응이 돌아올 수 있습니다. 의미는 통할 수 있겠지만, 업계 용어로는 쓰이지 않습니다.
비슷한 맥락에서 스테이징(staging)은 그대로 쓰이고, 개발 환경은 데브(dev)라고 부릅니다. 그런데 유독 운영 환경만 "리얼"이 된 점은 재미있습니다.
한국 IT 현장에서는 영어 명사를 한국어 동사처럼 활용하는 패턴이 많습니다.
"커밋 때리다"는 git commit을 한다는 말입니다. "때리다"가 붙으면서 묘한 역동성이 생깁니다. "머지 태우다"는 merge를 수행한다는 뜻인데, "태우다"가 왜 붙었는지는 아무도 모르지만 다들 자연스럽게 씁니다.
빌드를 실행할 때는 "빌드 돌리다"라고 합니다. 그나마 직관적인 표현입니다. deploy한다는 뜻의 "배포 나가다"도 있습니다. "이번 주말에 배포 나갑니다"처럼 쓰며, 배포가 어딘가로 출타하는 느낌을 줍니다.
이런 표현들은 영어 단어를 쓰고 있지만 영어권에서는 통하지 않습니다. "I hit a commit"이라고 하면 상대방이 멈칫할 것입니다.
어떤 콩글리시는 영어 원어와 의미가 살짝 다르게 정착했습니다.
영어에서 spec은 specification, 즉 기술 명세를 뜻합니다. 한국 IT에서도 **"스펙(spec)"**을 그 의미로 쓰지만, "이번 스펙 좀 큰데요?"처럼 작업 범위(scope)나 난이도를 가리키기도 합니다.
**"컨펌(confirm)"**은 조금 다릅니다. "컨펌 받았어요?"는 승인(approval)을 받았느냐는 뜻입니다. 영어의 confirm은 "확인하다"에 가깝고 승인의 뉘앙스는 약하니, approve와 confirm이 하나로 합쳐진 셈입니다.
"레퍼런스(reference) 있어요?"라고 하면 참고 사례나 선례를 묻는 것입니다. 영어에서도 비슷하게 쓰이지만, 한국에서는 거의 "벤치마크 대상" 수준으로 의미가 확장되었습니다. **"피드백(feedback)"**은 영어와 크게 다르지 않지만, 한국에서는 "피드백 주세요"가 사실상 "검토 후 의견 주세요"와 "수정 요청"을 함께 의미하는 경우가 많습니다. 칭찬이 섞인 피드백을 기대했다가 수정 사항 목록을 받는 일도 흔합니다.
"서비스 오픈했습니다"의 **"오픈(open)"**은 서비스를 출시(launch)했다는 뜻입니다. 영어에서 "We opened the service"라고 하면 어딘가의 문을 열었다는 느낌을 줍니다. 영어권에서는 launch, release, go live 등을 씁니다. 반대말로 쓰이는 "클로즈(close)"는 서비스 종료를 뜻하며, 영어에서는 shut down, sunset, deprecate 등이 자연스럽습니다.
"사인 부탁드립니다"의 **"사인(sign)"**은 결재 승인을 의미하기도 합니다. sign-off에서 온 듯하지만, 한국에서는 그냥 "사인"으로 줄었습니다. "이 건 핸들링 잘 해주세요"라는 말도 자주 들립니다. 영어에서도 handle은 "처리하다"라는 뜻으로 쓰이지만, 한국의 "핸들링(handling)"에는 특히 민감한 상황을 조심스럽게 다룬다는 뉘앙스가 강하게 실립니다.
회의나 협업 맥락에서는 또 다른 결의 콩글리시가 쏟아집니다. IT뿐 아니라 대기업 사무실 전반에서 공유되는 어휘라 "판교 사투리"라는 별명으로 유명하기도 합니다.
"이 건 팔로우업 부탁드려요"의 **"팔로우업(follow-up)하다"**는 끝까지 챙겨 경과를 확인해 달라는 뜻입니다. 영어에서 follow up은 동사구지만, 한국에서는 "팔로우업"이라는 명사형으로 굳은 뒤 "하다"가 붙었습니다.
"이 건에 디자인팀도 인볼브시켜주세요"라고 하면 참여/관여시키라는 의미입니다. 영어 involve는 주로 수동태인 "be involved in"처럼 쓰지만, 한국에서는 **"인볼브(involve)하다"**를 능동형으로 자연스럽게 씁니다. 발음이 살짝 꺾여 "인발브"로 들리는 경우도 흔합니다. **"어사인(assign)하다"**는 배정하다, 할당한다는 뜻이며 "이 티켓 저한테 어사인 해주세요"처럼 Jira 티켓을 배정하는 맥락에서 가장 자주 튀어나옵니다.
"팀 간 얼라인 좀 맞춰야 해요"라는 말은 방향이나 의견을 일치시키자는 뜻입니다. 영어 align 자체에 이미 "맞추다"라는 의미가 있지만, **"얼라인(align) 맞추다"**에는 한국어 "맞추다"가 한 번 더 붙습니다. "이 프로젝트는 제가 드라이브 하겠습니다"의 **"드라이브(drive)하다"**에는 적극적으로 이끌고 가겠다는 선언이 담깁니다. 영어 drive에도 비슷한 의미가 있지만, 한국에서는 프로젝트 소유권을 가져가겠다는 뉘앙스가 강합니다.
"아삽(ASAP)" — as soon as possible을 한국어 발음으로 읽어 명사처럼 쓴 표현입니다. "이거 아삽으로 부탁드려요"처럼 말합니다. 영어권에서도 ASAP을 쓰지만, "으로"라는 조사가 붙는 방식은 한국식입니다.
몇 가지 이유가 겹쳐 있습니다.
첫째, IT 기술 자체가 영어권에서 왔기 때문에 원어를 그대로 가져오는 일이 자연스러웠습니다. 번역하면 오히려 어색하거나 의미가 달라지는 경우도 많습니다. "커밋"을 "확정"이라고 하면 git commit인지 알아보기 어렵습니다.
둘째, 영어 원어를 가져오되 한국어 문법에 맞게 변형하는 과정에서 독자적인 표현이 만들어졌습니다. "머지 태우다"나 "배포 나가다"는 영어 명사를 한국어 구어 패턴에 녹인 결과입니다.
셋째, 빠른 커뮤니케이션이 필요한 환경에서 짧고 함축적인 표현이 살아남았습니다. "운영 환경"보다 "리얼"이 한 음절 더 짧고, "서비스 출시"보다 "오픈"이 빠릅니다.
이런 콩글리시가 나쁘다는 건 아닙니다. 같은 맥락을 공유하는 사람들 사이에서는 오히려 효율적인 소통 수단입니다. 다만 두 가지 상황에서는 주의가 필요합니다.
영어권 동료나 파트너와 소통할 때 — "리얼 환경"을 "real environment"로 직역하면 의미가 전달되지 않습니다. 이때는 production이라고 바꿔 써야 합니다.
신입이나 비개발 직군과 소통할 때 — 이미 IT 콩글리시에 익숙한 사람끼리는 문제가 없지만, 처음 접하는 사람에게 "리얼에 배포 나갔는데 터졌어요"는 암호에 가깝습니다.
결국 필요한 건 규칙보다 자각이에요. 제가 지금 콩글리시를 쓰고 있다는 걸 알고만 있으면, 영어권 동료 앞에서는 production으로, 처음 접하는 신입 앞에서는 풀어 쓴 한국어로 바꿀 여지가 생겨요.
]]>