2026년 초, AI가 개발자 생산성에 미치는 영향을 측정하던 연구진은 아주 인간적인 문제와 마주쳤습니다. 일부 개발자들이 AI 없이 해야 할 수도 있는 작업을 더는 맡고 싶어 하지 않았던 것입니다.
연구진은 이를 선택 편향이라고 불렀습니다. 하지만 제게는 작은 고백처럼 들립니다.
얼마 전까지만 해도 AI는 사이드 패널에 머무는 실험적인 기능이었습니다. 자동 완성이 실패하거나 정규 표현식이 슬슬 부담스러워질 때만 열어 보곤 했습니다. 이제 많은 개발자에게 AI는 그저 같은 방 안에 있는 존재가 되었습니다. 아침에 에디터를 열 때도, 몇 년 동안 아무도 손대지 않은 저장소를 넘겨받을 때도, 늦은 밤 테스트가 빨갛게 변할 때도 곁에 있습니다.
패널을 닫을 수 있습니다. 에이전트를 끌 수도 있습니다. 우리는 여전히 코드를 쓸 줄 압니다.
그런데 왜 AI 없이 일하는 것은 벌써 한 손을 잃고 일하는 것처럼 느껴질까요?
AI가 가져간 것은 일이 아니라 멈춤의 순간이었다
AI는 우리를 대체하겠다고 선언하며 소프트웨어 개발에 들어오지 않았습니다. 작은 안도감을 하나씩 건네며 들어왔습니다.
처음에는 우리가 곧 쓰려던 한 줄을 완성해 주었습니다. 그다음에는 미뤄 두었던 테스트를 작성했습니다. 낯선 함수를 설명하고, 스택 트레이스를 평범한 말로 바꾸고, 다시 읽고 싶지 않았던 문서 깊숙한 곳에서 설정 하나를 찾아냈습니다.
그 어느 것도 의존처럼 느껴지지 않았습니다. 앞으로 나아가는 느낌이었습니다.
마지막으로 AI 도우미가 작동하지 않았던 때를 떠올려 보세요. 불안했던 이유는 프로그래밍 언어를 잊어서가 아니었을 겁니다. 첫 행동을 하기 전의 침묵 때문이었습니다. 어디를 찾아볼지 스스로 정해야 했습니다. 불확실함을 혼자 품어야 했습니다. 가설이 생길 때까지 오류를 오래 바라봐야 했습니다.
예전에는 그런 멈춤이 당연했습니다. 이제는 마찰처럼 느껴집니다.
어쩌면 이것이 AI가 가장 깊이 바꾼 부분일지도 모릅니다. 답을 만드는 방식뿐 아니라, 우리가 하나의 질문과 단둘이 머물 수 있는 시간까지 바꾸었습니다.
안도감은 분명 진짜다
AI 의존을 이야기할 때 개발자가 규율을 버리고 게으름을 택했다고 말하기는 쉽습니다. 하지만 그런 설명은 실제 작업 안에서 이 도구가 어떤 의미인지 놓칩니다.
소프트웨어 개발에는 놀랄 만큼 많은 개인적인 부끄러움이 숨어 있습니다. 기본 명령어 문법을 잊은 시니어 엔지니어가 있습니다. 질문을 한 번 더 하면 모두의 의심을 확신으로 바꿀까 두려운 신입이 있습니다. 모국어가 아닌 언어로 일하면서 문제를 정확히 알지만 설명을 빠르게 표현하지 못하는 개발자가 있습니다. 중요한 결정이 모두 다른 사람의 기억 속에만 남아 있는 10년 된 코드베이스에 합류한 사람도 있습니다.
AI는 그들 모두에게 인내심을 보입니다.
같은 질문을 반복해도 한숨 쉬지 않습니다. “그 정도는 이미 알아야지”라고 말하지도 않습니다. 새벽 두 시에도 응답하고, 빈 화면을 적어도 반박할 수 있는 무언가로 바꿉니다. 불완전한 답이라도 하나가 나타나면 시작이 주는 감정적 무게는 달라집니다.
이것은 중요합니다. 생산성처럼 보이는 것이 사실은 안도감일 때가 있습니다. 막힐지 모른다는 두려움이 줄고, 창피함이 줄고, 스스로를 설명해 주지 않는 기계 앞에서 느끼는 외로움이 줄어듭니다.
많은 개발자는 AI 덕분에 자신이 좋아하는 일에 쓸 에너지를 되찾았습니다. 반복 코드와 정형화된 테스트, 마이그레이션 뼈대, 수없이 만들어 온 API 클라이언트를 맡길 수 있습니다. 그러면 흥미로운 문제에 도착했을 때 머리가 덜 지쳐 있습니다.
이를 단순한 지름길로 치부해서는 안 됩니다. 사람에게 더 많이 탐색해 볼 용기를 주는 도구는 분명 가치 있는 일을 합니다.
다만 위안과 의존은 같은 뿌리에서 자랍니다.
완전히 믿지 못하면서도 계속 사용한다
개발자 설문은 늘 같은 묘한 관계를 보여 줍니다. 우리는 AI를 끊임없이 사용하면서도 그 결과를 완전히 신뢰하지 않습니다.
자신감 넘치는 답이 단 하나의 엣지 케이스 앞에서 무너지는 장면을 본 사람이라면 이 긴장을 압니다. 코드는 맞아 보입니다. 이름도 깔끔합니다. 설명은 차분합니다. 세 번째 테스트가 실패하고 나서야 모델이 존재하지 않는 메서드를 만들었거나, 비즈니스 규칙을 잘못 이해했거나, 우리가 가진 문제보다 단순한 문제를 풀었다는 사실을 발견합니다.
그런데도 다음에 막히면 다시 묻습니다.
위선이 아닙니다. 신뢰는 하나의 덩어리가 아닙니다.
최종 결정은 맡기지 못해도 첫 방향은 맡길 수 있습니다. 패치는 믿지 못해도 생각의 매듭을 느슨하게 해 주는 대화는 믿습니다. 답 자체를 의심하면서도 화면에 아무것도 없는 대신 무언가가 나타날 것이라고 기대합니다.
AI는 main 브랜치에 직접 머지할 권한은 절대 줄 수 없지만, 방을 나가는 순간 이상하게 그리워지는 동료가 되었습니다.
다음 발판이 곧바로 나타나기에 우리는 더 빨리 나아간다. 그 발판이 우리의 무게를 견딜지는 여전히 우리가 확인해야 한다.
고생이 사라질 때 함께 사라지는 것
막혀 보아야만 생기는 지식이 있습니다.
AI 이전에는 낯선 오류가 우리를 스택 트레이스에서 호출부로, 거기서 문서로, 그리고 마침내 스스로도 몰랐던 가정으로 데려가곤 했습니다. 비효율적인 길이었습니다. 하지만 그 길을 걷는 동안 코드베이스는 파일 묶음이 아니라 하나의 장소가 되었습니다.
우리는 한때 우리에게 저항했던 시스템을 기억합니다.
오후 한나절을 가져간 버그는 상태가 실제로 어디에 있는지 가르칩니다. 프로덕션 장애는 지루해 보이던 안전장치가 왜 존재하는지 알려 줍니다. 세 번이나 잘못 이해한 라이브러리는 나중에 다른 사람에게 설명할 수 있는 라이브러리가 됩니다.
AI가 저항을 없앨 때, 배움을 오래 남게 하는 이야기까지 함께 없앨 수 있습니다.
낯선 라이브러리를 배우는 개발자를 대상으로 한 초기 연구는 직관적으로 이해되는 차이를 보여 주었습니다. 작업 전체를 위임한 사람은 개념을 질문하고 자신의 이해를 점검하기 위해 AI를 사용한 사람보다 덜 배웠습니다. 중요한 차이는 ‘AI를 쓰느냐 마느냐’가 아니라 도구가 사고를 대체했는지, 사고에 참여했는지였습니다.
주니어 개발자에게는 특히 어려운 문제입니다. 경험 많은 엔지니어가 수상한 추상화를 알아보는 이유는 전에 잘못된 추상화를 직접 만들어 보았기 때문입니다. 정돈된 패치가 시스템에 어울리지 않는다고 느끼는 이유는 그 시스템의 상처를 기억하기 때문입니다. 모든 거친 면이 손에 닿기도 전에 매끈해진다면, 다음 세대는 어디에서 그런 감각을 얻을까요?
멘토링은 답을 전달하는 일만이 아니었습니다. 무엇을 걱정해야 하는지, 언제 멈춰야 하는지, 어떤 타협이 나중에 비싸지는지, 작동하는 해법이 왜 아직 완성은 아닌지를 천천히 전하는 일이었습니다.
AI는 이 모든 것을 설명할 수 있습니다. 하지만 누군가가 우리가 배우는 동안 곁에 남기로 선택했을 때의 감각까지는 아직 재현하지 못합니다.
지름길은 진짜일 수 있다. 그래도 이해는 그 거리를 직접 건너야 한다.
코드에는 한때 작성자의 지문이 남아 있었다
사람과 사람 사이에서 일어나기 때문에 더 측정하기 어려운 변화도 있습니다.
사람이 쓴 코드에는 종종 작성자의 흔적이 남습니다. 특이한 헬퍼 함수에는 그것을 필요하게 만든 장애의 기억이 있을 수 있습니다. 어색한 주석은 누군가 어디에서 확신하지 못했는지 보여 줍니다. 리뷰할 때 우리는 변경만 검사하지 않습니다. 그 뒤의 생각을 다시 구성합니다. 질문하면 그 길을 직접 걸은 사람이 대답합니다.
AI가 생성한 코드는 그 길 없이 도착할 수 있습니다.
세련되고 기술적으로 그럴듯하지만 이상하게 주인이 없는 것처럼 느껴질 수 있습니다. 작성자는 무엇을 요청했는지는 설명해도 결과가 왜 이 모양이 되었는지는 설명하지 못할 수 있습니다. 그러면 리뷰어가 원래 작성자도 나누어 맡았던 일을 떠안습니다. 의도를 다시 만들고, 가정을 확인하고, 아무도 기억하지 못하는 결정의 숨은 가장자리를 찾아야 합니다.
AI가 생성한 pull request를 둘러싼 많은 커뮤니티 논의의 밑바닥에는 이런 불편함이 있습니다. 불만은 단지 코드가 나쁠 수 있다는 데 있지 않습니다. 나쁜 코드는 오래전부터 익숙했습니다. 더 깊은 불안은 사람 사이의 사회적 약속이 달라졌다는 데 있습니다.
한 사람은 몇 분 만에 큰 변경을 만들 수 있습니다. 다른 사람은 그것을 이해하기 위해 여전히 인간의 주의를 써야 합니다. 키보드에서 아낀 시간은 코드 리뷰와 유지보수, 보안 업무, 혹은 시스템이 멈추고 누군가가 생성된 패치의 의도를 설명해야 하는 밤에 조용히 다시 나타납니다.
코드는 늘 커뮤니케이션이었습니다. 생성 비용이 거의 사라질수록 주의가 희소해집니다. 그리고 주의는 사람의 것입니다.
기술은 사라지는 대신 자리를 옮기는지도 모른다
어떤 개발자에게 이 변화는 상실처럼 느껴지지 않습니다. 오히려 늘 원하던 높이에서 일할 수 있게 되었다고 느낍니다.
코드 줄 수는 줄이고 문제의 형태를 잡는 데 더 많은 시간을 씁니다. 하나를 선택하기 전에 여러 설계를 비교합니다. 사용자와 아키텍처, 실패 방식, 에이전트가 넘지 말아야 할 경계를 생각합니다. 기술의 중심이 모든 부품을 직접 만드는 데서 전체를 이끄는 데로 이동합니다.
이는 진짜 진화가 될 수 있습니다. 어셈블리가 기계어를 대체했을 때도, 프레임워크가 손으로 만들던 인프라를 대신했을 때도 우리는 개발자이기를 멈추지 않았습니다. 소프트웨어는 언제나 추상화를 통해 위로 올라왔습니다.
하지만 모든 추상화는 그 아래를 이해하는 누군가에게 의존합니다.
AI를 지휘하는 개발자에게도 안목이 필요합니다. 리뷰어에게도 머릿속 모델이 필요합니다. 아키텍트는 깔끔한 다이어그램이 느린 네트워크, 손상된 메시지, 지친 팀, 불안한 사용자를 만날 때 무슨 일이 생기는지 알아야 합니다.
AI가 구현을 더 많이 작성하더라도 인간의 판단은 덜 중요해지지 않습니다. 오히려 더 쉽게 간과되고 더 어렵게 길러집니다.
희망적인 미래는 개발자의 가치가 줄어드는 미래가 아닙니다. 맥락, 배려, 의심, 책임, 그리고 기술적으로 옳은 답이 이 시스템과 이 사람들에게는 틀렸음을 알아보는 능력처럼 사람만이 짊어질 수 있는 것을 더 의식적으로 지키는 미래입니다.
우리 자신을 남겨 둔 채 AI와 함께 있기
우리는 아직 AI 없이 일할 수 있을까요?
개인으로서는 가능합니다. 내일 패널을 닫으면 됩니다. 하지만 직업으로서의 답은 이미 더 복잡합니다. 기대치는 바뀌고 있습니다. 코드베이스는 생성된 작업으로 채워집니다. 새 개발자는 경력 중간이 아니라 시작부터 AI를 만납니다. 도우미를 한 번도 쓰지 않는 사람조차 AI가 만든 코드를 리뷰하고 유지보수하게 될 것입니다.
AI 이전의 소프트웨어 업계로 혼자 돌아가는 길은 없습니다.
하지만 떠나는 것이 자유를 재는 잘못된 기준일지도 모릅니다. 더 중요한 질문은 도구가 남아 있는 동안 우리도 일 속에 온전히 남아 있을 수 있느냐는 것입니다.
남아 있다는 것은 모든 테스트가 초록색이어도 패치를 읽는 일입니다. 답이 작동한 뒤에도 왜 그런지 묻는 일입니다. 설명할 수 없는 변경을 머지하지 않는 일입니다. 주니어가 씨름하는 시간을 낭비라고 부르지 않고, 그럴듯한 실수로부터 시스템을 지키는 리뷰어의 보이지 않는 일을 인정하는 일입니다.
또 어떤 도우미도 즉시 답하지 않는 순간을 지키는 일이기도 합니다. 순수함을 증명하려는 의식이 아니라 우리 자신의 생각을 다시 듣기 위해서입니다.
우리 대부분은 계속 AI를 사용할 것입니다. 안도감은 진짜입니다. 가능성도 진짜입니다. 불편함과 의존, 우리가 사랑했던 일의 무엇인가가 조용히 사라질지 모른다는 두려움도 진짜입니다.
부정과 항복 중 하나를 고를 필요는 없습니다.
소프트웨어의 미래는 AI가 코드의 몇 퍼센트를 쓰느냐로 결정되지 않습니다. 받아들이기 전에 이해하는지, 답을 전달하기만 하지 않고 가르치는지, 다른 사람의 주의를 지키는지, 생성된 코드가 현실에 닿았을 때도 책임을 맡는지 같은 작은 순간들이 미래를 결정합니다.
AI는 남아도 됩니다.
우리도 반드시 남아 있어야 합니다.
