도태냐 적응이냐, 코딩 실력으로 정해지지 않습니다

도태냐 적응이냐, 코딩 실력으로 정해지지 않습니다

전기가 들어오기 전후의 공장은 중앙 동력원과 천장 샤프트, 벨트에 맞춰 설계되어 있었습니다. 그래서 초기 전기화는 '동력원 교체'에 그쳤고, 생산성 폭발은 공장 구조를 다시 짠 뒤에야 왔습니다. 이미지: Wikimedia Commons, Line shaft.jpg, public domain.

적응하는 사람, 비켜서는 사람

요즘 어디를 봐도 AI로 뭐든 만든다는 이야기뿐입니다. 누구는 하룻밤에 앱을 만들고, 누구는 회사 일을 절반으로 줄였다고 합니다. 그 얘기를 들으면 마음 한구석이 불편한 순간이 있습니다. "나는 코드를 모르니 저건 개발자들 얘기지." 혹은 "이미 다들 저만큼 갔는데, 지금 시작하면 너무 늦은 거 아닌가."

솔직히 말하면, 지금 사람들은 천천히 두 부류로 움직입니다. AI에 적응해 일을 키우는 쪽, 그리고 "나는 원래 이런 거 못 해"라며 비켜서는 쪽. 다만 너무 겁먹을 필요는 없습니다. 이 글이 하려는 이야기의 핵심이 따로 있으니까요. 두 부류를 정하는 게 재능도, 코딩 실력도, 남보다 일찍 시작했는지도 아니라는 것. 데이터는 오히려 이렇게 말합니다. 가장 앞서가는 사람은 코딩 천재가 아니고, 자기 분야를 잘 아는 사람일수록 AI로 더 멀리 간다고.

그러니 이 글은 일종의 자가 진단에 가깝습니다. 끝까지 읽으면, 내가 지금 어느 쪽에 서 있는지 — 그리고 적응하는 쪽으로 가려면 오늘 무엇을 하면 되는지 — 어느 정도 감이 올 겁니다. 이야기를 풀려면 130년 전 공장에서 시작하는 게 가장 빠릅니다.

1. 전기는 일찍 왔는데, 30년간 아무 일도 없었다

경제학자 로버트 솔로우가 1987년에 남긴 유명한 한마디가 있습니다. "컴퓨터 시대는 생산성 통계만 빼고 어디서나 보인다(You can see the computer age everywhere but in the productivity statistics)." 기술은 분명히 나왔는데 정작 숫자로는 효과가 안 보이던 시절의 답답함입니다.

스탠퍼드의 경제사학자 폴 데이비드는 1990년 논문 〈The Dynamo and the Computer〉에서 이 역설을 한 세기 전 사건으로 설명했습니다. 바로 전기입니다. 백열전구는 1879년에 나와 1880년에 특허까지 받았습니다. 그런데 1900년에도 전기조명을 쓰는 가정은 전체의 3%, 공장 동력 중 전기모터의 비중은 5%도 안 됐습니다. 기술이 20년 전에 도착했는데 세상은 거의 그대로였습니다.

데이비드가 짚은 지연의 진짜 이유는 허무할 만큼 단순합니다. 공장들이 전기를 들이면서도 일하는 방식은 하나도 안 바꿨기 때문입니다. 그때 공장은 한가운데 거대한 동력원을 두고, 천장의 회전축(샤프트)과 벨트로 그 힘을 작업장 곳곳에 나눠 보내는 구조였습니다. 전기가 들어오자 사람들은 그 가운데 증기기관 자리에 큰 전기모터(dynamo) 하나만 끼워 넣었습니다. 구조는 그대로, 동력원만 교체. 당연히 생산성은 거의 안 올랐습니다.

전환점은 1920년대에 왔습니다. 누군가 **"기계마다 작은 모터를 하나씩 달면 되지 않나?"**를 깨달은 겁니다. 공장들이 이 '유닛 드라이브' 방식을 받아들이자 모든 게 달라졌습니다. 경제학자 할 배리언의 정리를 빌리면, 에너지 효율이 올랐고 **"더 가볍고 모듈화된 단층 공장"**도 지었습니다. 작업자가 자기 기계를 직접 켜고 끄고, 자재가 흐르는 동선에 맞춰 라인을 다시 짰습니다. 그제서야 생산성이 폭발했습니다.

기술 자체보다 더 큰 변화는 작업 배치와 흐름을 다시 짜는 데서 나왔습니다. 1913년 포드 조립 라인은 '새 동력'보다 '새 공정'이 생산성을 바꾼다는 점을 보여주는 좋은 장면입니다. 이미지: Wikimedia Commons, public domain.

데이비드가 덧붙인 한 줄이 핵심입니다. 이 전환에는 "새 방식에 익숙한 공장 설계자와 전기 기술자들의 층(cadre)을 길러 내는" 시간이 걸렸다는 것. 30년의 격차를 만든 건 전기라는 기술이 아니라, 그 기술에 맞춰 일하는 법을 새로 익힌 사람들이었습니다.

💡 경제학자 브린욜프슨은 이걸 '생산성 J커브'라 부릅니다. 전기·AI 같은 범용기술은 도입 직후엔 오히려 생산성이 잠깐 꺼지는 것처럼 보입니다(J의 아래쪽). 새 프로세스·일하는 법·사람의 숙련 같은 '눈에 안 보이는 투자'를 사람들이 먼저 쌓아야 하기 때문입니다. 그 무형자산이 임계점을 넘는 순간 곡선이 위로 솟습니다. 우리는 지금 AI J커브의 어디쯤에 있을까요.

2. 지금이 정확히 그 '30년의 초입'이다

흥미로운 건, 지금 AI도 능력 곡선이 잠깐 숨을 고른다는 점입니다. 모델을 키울 고품질 학습 데이터가 바닥을 보이고(이른바 '데이터 월'), 파라미터만 키워 얻는 이득도 점점 줄어듭니다. 모델이 다음 도약을 준비하며 잠시 멈춰 선 사이, 사람들의 활용 숙련도는 한참 뒤처집니다. 저는 이 시차를 '인식의 쉼'이라고 부릅니다. 전기는 들어왔는데 아직 아무도 공장을 다시 안 짠, 바로 그 1900년의 초입입니다.

이게 남 얘기가 아니라는 신호는 이미 곳곳에 있습니다. 2022년 말, AI 연구자 안드레이 카파시는 이런 트윗을 남겼습니다. "코파일럿이 내 코드의 80%를 써준다. 정확도도 80% 정도다. 난 사실 코딩을 안 한다. 프롬프트하고, 고친다(I don't even really code, I prompt. & edit)." 그땐 별난 얘기였습니다. 3년이 지난 지금은요? 이제 다들 그렇게 일합니다. 다른 게 있다면, 누가 그 80%를 더 잘 끌어내느냐가 격차를 만든다는 점입니다.

3. 앞서가는 사람은 천재가 아니라 '먼저, 계속' 쓴 사람

여기서 가장 안심할 만한 데이터가 있습니다. 2026년 여러 기관의 조사가 공통으로 짚은 결론은, 앞서가는 사람들이 남에게 없는 무언가를 가진 게 아니었다는 겁니다.

격차의 크기 자체는 분명 큽니다. OpenAI의 분석에서 AI 파워유저와 평범한 사용자 사이에 약 6배의 생산성 차이가 났고, 특히 코딩 같은 작업에선 상위권(95번째 백분위)이 중간값 사용자를 십수 배 앞섰습니다. 마이크로소프트의 2026년 조사에서 앞서가는 '프런티어 전문가'의 **80%가 "작년엔 못 했을 일을 해냈다"**고 답했는데, 전체 사용자에선 그 비율이 58%였습니다.

그런데 그 격차의 입구가 무엇이냐가 진짜 핵심입니다. 조사들이 공통으로 짚은 건, 앞선 사람들은 특별한 접근권이나 재능이 있어서가 아니라 **"이미 모두에게 있는 도구를 그냥 먼저 쓰기 시작해서, 될 때까지 계속 쓴 사람"**이라는 점입니다. 회사가 정해준 도구를 받아 쓴 사람보다, 자기가 직접 도구를 고른 사람이 약 두 배(35% vs 18%) 더 크게 변했습니다.

💡 격차의 문이 'IQ'가 아니라 '시작과 지속'이라면, 이건 위협이 아니라 초대장에 가깝습니다. 1900년의 공장으로 돌아가 보죠. 아직 대부분은 모터를 가운데 한 대만 답니다. 지금 작은 모터를 기계마다 달기 시작하는 사람이 1920년대를 가져갑니다. 늦은 게 아니라, 아직 아무도 본격적으로 안 바꿨을 뿐입니다.

4. 진짜 반전 — 잘하는 사람일수록 더 멀리 간다

가장 희망적인 대목은 따로 있습니다. AI가 모두를 똑같이 평준화하는 게 아니라, 원래 자기 일을 잘 아는 사람일수록 더 큰 이득을 본다는 것입니다. 이걸 데이터로 보여준 게 2026년 6월 Anthropic이 발표한 보고서 〈Agentic coding and persistent returns to expertise〉입니다. 약 40만 건의 에이전트 코딩 세션(이용자 약 23.5만 명)을 분석한 연구입니다.

Anthropic은 2025년 10월부터 2026년 4월까지 Claude Code 사용에서 fixing/building 비중은 줄고, operating·writing·data analysis 같은 주변 업무가 늘었다고 분석했습니다. 평균 작업 가치 추정치도 약 27% 올랐습니다. 이미지: Anthropic, 〈Agentic coding and persistent returns to expertise〉.

이 보고서가 그린 사람과 AI의 관계는 한 문장이면 충분합니다. "사람은 무엇을 만들지 정하고, 에이전트는 어떻게 만들지 정한다(People decide what to build, and the agent decides how to build it)." 실제로 사람은 기획 결정(무엇을·어떤 방향으로)의 약 70%를 쥐고, Claude는 실행 결정(어떤 코드를·어떤 명령을)의 약 80%를 맡았습니다. AI가 점점 가져가는 건 '구현'이고, 사람에게 남는 건 '방향'입니다.

사람은 기획 결정의 대부분을, Claude는 실행 결정의 대부분을 맡습니다. 이 글의 핵심인 '코딩 손기술보다 방향 감각'을 데이터로 보여주는 장면입니다. 이미지: Anthropic, 〈Agentic coding and persistent returns to expertise〉.

그렇다면 성공을 가른 결정적 변수는 무엇일까요. 놀랍게도 코딩 실력이 아니라, 풀려는 문제를 얼마나 정확히 이해하느냐였습니다. 보고서가 말하는 전문성은 직함이나 일반적 능력과 다른, '그 과제에 한정된(task-specific)' 이해입니다.

"러스트를 처음 물어보는 시니어 엔지니어는 러스트에선 초보다. 반대로 파이썬을 한 번도 써본 적 없는 회계사라도, 정산 스크립트가 지켜야 할 규칙을 정확히 지시하고 월말 마감 때 그것이 놓친 예외를 잡아낸다면, 그 과제에서는 전문가다."
— Anthropic, 〈Agentic coding and persistent returns to expertise〉

이 차이는 숫자로도 선명합니다. 초보로 분류한 세션은 프롬프트 하나에 Claude가 약 5개 행동·600단어를 내놨지만, 전문가 세션에선 12개 행동·3,200단어 — 산출량이 다섯 배에 달했습니다. 같은 도구인데, 문제를 아는 사람이 쥐면 한 번의 지시로 다섯 배의 일을 끌어냅니다. 검증된 성공률도 초보 15%에서 중급 이상 28~33%로 두 배 넘게 뛰었습니다.

사용자의 과제 전문성이 높을수록 Claude의 행동 수와 출력량이 함께 늘어납니다. 같은 AI라도 더 정확한 지시를 받으면 더 멀리 갑니다. 이미지: Anthropic, 〈Agentic coding and persistent returns to expertise〉.

특히 인상적인 건 막혔을 때입니다. 일이 꼬였을 때 초보 사용자의 19%는 코드 한 줄 못 건지고 포기했지만, 나머지는 그 비율이 5~7%에 그쳤습니다. 보고서의 해석이 이 글의 주제와 정확히 맞닿습니다. "전문성의 가치 일부는 에이전트를 옳은 방향으로 모는 능력에 있다."

초보에서 중급으로 넘어가는 순간 성공률이 크게 올라가고, 막혔을 때 포기하는 비율은 크게 내려갑니다. '통달'보다 '어느 정도 제대로 아는 상태'가 더 큰 분기점입니다. 이미지: Anthropic, 〈Agentic coding and persistent returns to expertise〉.

그래서 결과가 의외였습니다. 코드를 만든 세션에서 10대 직업군 모두가 소프트웨어 엔지니어와 7%포인트 이내로 붙었고, 검증된 성공률이 **가장 높은 직군은 개발자가 아니라 경영직(management)**이었습니다. 보고서는 조심스럽게 덧붙입니다. "에이전트를 지휘하는 데 경영 능력이 그대로 옮겨오는 것일 수 있다." 가장 빠르게 늘어난 비개발 직군도 경영·영업·법무였습니다. 자기 분야를 깊이 아는 사람이 AI를 쥐자 가장 멀리 갔습니다.

코드를 만든 세션에서도 주요 직군의 성공률은 소프트웨어·수학 직군과 큰 차이가 나지 않았습니다. Anthropic은 경영직의 검증 성공률이 오히려 가장 높게 나타났다고 보고했습니다. 이미지: Anthropic, 〈Agentic coding and persistent returns to expertise〉.

더 반가운 건, 이 이득을 누리는 데 '통달'까지는 필요 없다는 점입니다. 보고서는 "이득의 대부분은 숙달이 아니라 능숙함에서 나온다 — 그 분야를 어느 정도 손에 쥐면 혜택의 대부분을 가져간다"고 말합니다. 전문가가 될 필요는 없고, 자기 일을 '제대로 아는' 정도면 됩니다.

보고서의 마무리 문장이 이 글이 하고 싶은 말을 대신합니다.

"그런 (자기 분야에 대한) 장악력을 가진 사람은, 어떤 분야에 있든, 이전엔 할 수 없던 기술적인 일을 이제 해낸다. 반대로 그런 전문성이 전혀 없는 사람은 같은 도구로도 훨씬 적은 것밖에 얻지 못한다."

5. 그래서, 무엇을 해볼 수 있을까

"방향을 아는 사람이 이긴다"는 말은 멋지지만 손에 잘 안 잡힙니다. 정답을 안다기보다, 제가 해보면서 도움이 됐던 것 몇 가지를 적어 둡니다. 사람마다 일이 다르니 그대로 따라야 할 목록이라기보단 참고에 가깝습니다. 적어도 저는 거창한 것부터 하려다 매번 미뤘고, 작게 시작했을 때 오히려 감이 왔습니다.

① 질문보다 '명령'에 가깝게. AI가 못 알아듣는 경우, 제 경험상 모델이 멍청해서라기보다 제 요청이 모호했던 적이 더 많았습니다. "좋은 보고서 써줘"는 동료에게 "코드 좀 봐줘"라고만 던지는 것과 비슷한 듯합니다. 맥락·목적·읽을 사람·이미 시도한 것을 같이 주면 결과가 달랐습니다. 흥미로운 건, 이렇게 또박또박 시킬 줄 알게 되는 것 자체가 내가 그 일을 제대로 이해했다는 신호 같다는 점입니다.

② 일마다 '맡기는 깊이'를 달리해 보기. 전부 맡기거나 전혀 못 맡기거나의 문제는 아닌 듯합니다. 저는 흔하고 틀에 박힌 일(정형 문서, 표 정리)은 요구사항만 던지고, 까다로운 일은 방향과 원인까지 짚어 줍니다. 다만 과정을 안 시키는 것과 결과를 안 보는 건 다르더군요 — 검토만큼은 끝까지 제 몫으로 뒀습니다.

③ '앱'보다 내 일의 불편 하나. 저도 대단한 걸 만들려다 시작을 못 한 적이 많습니다. 돌아보면 거창한 앱이 아니라 '내 반복 업무를 줄이는 작은 도구' 하나로 충분한 경우가 대부분이었습니다. 그 정도면 스토어 심사나 개발자 계정 연회비도 없이 됩니다. 작게 만들어 매일 써보는 데서 감이 오더군요.

④ 리서치가 '계속 돌아가게'. 한 번 몰아서 공부하고 끝내기보다, 내 분야의 새 흐름이 정기적으로 흘러들어오게 두는 편이 저한텐 맞았습니다. 관심 분야 뉴스레터·깃허브 트렌딩·업계 블로그를 정해 두고 정해진 시간에 자동 요약이 오도록 스케줄을 걸어 둡니다. 숙련은 몰입보다 꾸준한 노출에서 오는 것 같습니다.

⑤ 해본 걸 밖으로 꺼내 나눠 보기. 사실 지난 몇 년간 AI로 할 수 있는 일이 이만큼 늘어난 데에는, 사람들이 각자의 시도와 사례를 서로 공유한 몫이 큽니다. 누군가 릴스나 스레드에 "AI로 이런 것도 되더라"를 올리면, 그걸 본 다른 사람이 "어, 그럼 내 일에도?" 하고 따라 해 봅니다. 그렇게 '저게 가능하구나'를 알게 되는 사람이 늘수록 전체 생산성도 같이 올라갔습니다. 앞서 말한 '인식의 쉼', 그 격차를 메우는 게 결국 이 공유였던 셈입니다. 그러니 거창하지 않아도 좋으니 자기 시도를 한 번 나눠 보시길 권합니다. 저는 만든 결과물을 오픈소스로 공개하는 편인데, 꼭 코드가 아니어도 됩니다. 일하면서 정리한 팁이나 작업 흐름을 한 장짜리 PDF로 묶어 링크드인에 올려 보는 정도면 충분합니다. 받는 사람도 얻고, 머릿속에만 있던 노하우를 남이 읽게 정리하다 보면 내 이해도 한 번 더 또렷해지더군요.

다섯 가지의 공통점이 있다면, 어느 것도 "코드를 잘 짜라"가 아니라는 점입니다. 전부 무엇을 시킬지 알고, 결과가 옳은지 가늠하고, 꾸준히 반복하는 쪽에 가깝습니다.

6. 정리하며

기술은 사람보다 먼저 도착해 잠깐 멈춰 서서 기다리는 듯합니다. 적어도 전기가 그랬습니다. 그 멈춘 구간의 격차를 가져간 건 재능 있는 소수라기보다 일하는 법을 먼저 바꾼 사람들이었고요. AI도 비슷하다면, 다행인 건 이 도구가 내가 이미 잘하는 것을 지우기보다 지렛대로 쓰는 쪽이라는 점입니다.

코드로 옮기기 어려운 판단, 자기 분야에서 몸으로 익힌 감각 — 철학자 폴라니가 "우리는 말할 수 있는 것보다 더 많이 안다"고 했던 그 암묵지 — 은 애초에 AI의 학습 데이터에 잘 없습니다. 그래서 오히려 그게 사람의 자리를 남겨 두는 것 같습니다. 지금 필요한 건 코드를 치는 손이라기보다, 무엇을 만들지 알고 그 결과가 옳은지 가늠하는 눈에 가깝지 않을까요.

그래서 저는 이 FOMO를 불안보다는 한 번 해볼 만한 신호로 읽는 편입니다. 전기가 막 들어온 1900년의 공장 주인에게 누군가 이렇게 귀띔했다면 어땠을까 싶습니다. "30년 뒤엔 많은 게 달라질 텐데, 그 30년은 재능보다 지금 모터를 어디에 달지 고민한 사람의 것이더라."

저는 지금이 그 1900년에 가깝다고 봅니다. 코드는 몰라도 괜찮을지 모릅니다. 잘 아는 분야 하나를 골라 AI에게 방향을 잡아 시켜 보는 것 — 저는 거기서 시작했습니다. 물론, 이것도 제 경험일 뿐입니다.