[특집] AI가 코드를 거의 다 쓴다면, 소프트웨어 엔지니어링은 어떻게 되는가 — '연필을 내려놓은' 개발자들의 2026년

크게 보기

들어가며: "연필을 내려놓았다"

2026년 9월 23일, 미국 오스틴에서 열린 레일스 월드(Rails World) 2026 개막 키노트. 루비 온 레일스를 만든 DHH(데이비드 하이네마이어 핸슨)가 무대에 올라 이렇게 말했습니다.

"손으로 코드를 쓰는 일은, 대부분의 회사에서 대부분의 프로그래머에게 더 이상 경제적으로 타당한 기술이 아닙니다."

그의 회사 37시그널스(Basecamp, HEY를 만든 곳)는 '연필을 내려놓았다(pencils down)'고 했습니다. 엔지니어는 에이전트에게 원하는 결과를 주고, 에이전트가 구현을 만들고, 사람은 나중에 돌아와 결과를 검토합니다. 손으로 코드를 쓰는 건 이제 예외이고, 그런 일이 생기면 "에이전트 작업 흐름 어딘가를 고쳐야 한다는 신호"로 여긴다고 합니다. DHH 본인은 2026년 8월 한 달에만 약 15만 줄의 운영 코드를 내보냈다고 밝혔습니다.

재미있는 건, 이 사람이 불과 1년 전 여름까지만 해도 팟캐스트에서 "AI가 코드를 직접 쓰게 두지 않는다"고 말하던 사람이라는 점입니다.

이 키노트가 화제가 된 다음 날, 개발자 뉴스레터 「더 프래그머틱 엔지니어(The Pragmatic Engineer)」의 게르게이 오로스(Gergely Orosz)는 2026년 1월에 유료로 발행했던 글 하나의 유료 벽을 풀었습니다. 제목은 「AI가 코드를 거의 다 쓴다면, 소프트웨어 엔지니어링은 어떻게 되는가(When AI writes almost all code, what happens to software engineering?)」. 그는 이렇게 덧붙였습니다. "1월에 우리는 이 일이 업계 전체에서, 생각보다 빨리 일어날 거라고 봤습니다. 좋은 소식은, 우리 대부분이 더 이상 코드를 손으로 쓰지 않더라도 소프트웨어 엔지니어링은 멀쩡히 살아 있다는 겁니다."

이 특집은 그 글을 뼈대로 삼습니다. 그리고 거기에 역사와 논문, 데이터를 덧붙여 세 가지 질문에 답해 보려 합니다.

1. 왜 하필 지금 이런 일이 벌어졌는가?
2. 코드가 거의 공짜가 되면, 무엇의 값이 떨어지고 무엇의 값이 오르는가?
3. 2026년을 사는 개발자와 팀은 무엇을 준비해야 하는가?

휴대폰으로 운영 배포를 하던 날

원문은 오로스 자신의 겨울 휴가 이야기로 시작합니다. 2025년 연말, 그는 몇 달째 미뤄 둔 기능들 — 대기업용 단체 구독 셀프서비스, 뉴스레터 관리자 패널 — 을 AI 에이전트에게 맡겨 봤습니다. Opus 4.5와 GPT-5.2는 중간 크기의 작업을 "놀랄 만큼 잘" 해냈습니다. 그는 프롬프트를 쓰고, 결과를 검토하고, 테스트가 통과하는지(새로 요청한 테스트까지) 확인하고, 조금 더 다듬게 한 뒤 수백 줄의 코드를 운영 환경에 올렸습니다.

더 마법 같은 순간은 그다음이었습니다.

크게 보기

클로드 코드 웹 버전을 깃허브에 연결해 두니, 여행 중에 휴대폰 앱으로 "이거 고쳐 줘, 테스트도 추가해 줘"라고 말하면 클라우드의 에이전트가 코드를 고치고 PR을 만들었습니다. PR은 깃허브 액션을 돌려 에이전트가 직접 못 돌리는 테스트까지 실행했고, 오로스는 이동 중에 휴대폰만으로 PR을 검토하고 머지했습니다.

그는 조심스럽게 단서를 답니다. 위험도가 낮은 작업이었고, 비즈니스 로직이 전부 자동 테스트로 덮여 있었다고요. 이 단서는 이 글 전체를 관통하는 복선이기도 합니다. 테스트가 있었기 때문에 휴대폰으로 머지할 수 있었던 겁니다.

---

1. "아하" 모먼트: 회의론자들이 먼저 돌아섰다

AI 회사 직원들이 "AI 코딩 대단해요"라고 말하는 건 새롭지 않습니다. 2025년 말이 달랐던 건, 팔 물건이 없는 베테랑들이 같은 말을 하기 시작했다는 점입니다.

카파시의 두 달: "슬롭"에서 "규모 9의 지진"으로

가장 극적인 전향은 안드레이 카파시(Andrej Karpathy)였습니다. 오픈AI 공동 창업자이자 테슬라 오토파일럿 책임자 출신이고, AI 도구에 대해 솔직하기로 유명한 사람입니다. 그리고 2025년 2월 '바이브 코딩(vibe coding)'이라는 말을 처음 만든 사람이기도 합니다.

크게 보기

2025년 10월, 그는 드와르케시 팟캐스트에서 이렇게 말했습니다.

"전반적으로 모델은 아직 거기까지 못 왔습니다. 업계가 너무 큰 점프를 하면서 이게 대단한 척하는데, 아닙니다. 슬롭(slop)이에요. … 지금 제 최적점은 자동완성입니다."

그리고 두 달 뒤인 12월 26일.

"프로그래머로서 이렇게 뒤처진 느낌은 처음입니다. 프로그래머가 기여하는 부분이 점점 드물어지면서, 이 직업이 극적으로 리팩터링되고 있어요. 지난 1년 사이 나온 것들을 제대로 엮기만 하면 10배는 강해질 수 있을 것 같은데, 그 부스트를 못 챙기는 건 명백히 실력 문제(skill issue)처럼 느껴집니다.

에이전트, 서브에이전트, 프롬프트, 컨텍스트, 메모리, 권한, 도구, 플러그인, 스킬, 훅, MCP, LSP, 슬래시 명령, 워크플로… 익혀야 할 새로운 프로그래밍 가능한 추상화 계층이 생겼습니다. 확률적이고, 틀리기 쉽고, 속을 알 수 없고, 계속 변하는 존재가 갑자기 전통적인 엔지니어링과 뒤섞였어요.

누군가 강력한 외계 도구를 돌렸는데 설명서가 없습니다. 모두가 그걸 어떻게 쥐고 써야 할지 알아내야 하는 와중에, 규모 9의 지진이 이 직업을 흔들고 있어요. 소매를 걷어붙이세요."

이 글에 클로드 코드를 만든 보리스 체르니(Boris Cherny)가 답글을 달았습니다.

"지난달은 엔지니어가 된 뒤 처음으로 IDE를 한 번도 열지 않은 달이었습니다. Opus 4.5가 PR 약 200개를, 한 줄도 빠짐없이 썼어요. 초기 사용자인 우리조차 가장 어려운 건 기대치를 계속 다시 맞추는 겁니다. 그리고 이건 여전히 시작일 뿐이에요."

---

2. 왜 하필 지금인가: 보이지 않는 선을 넘은 두 달

오로스는 2025년 11~12월에 나온 세 모델을 티핑 포인트로 꼽습니다.

모델이 "조금" 좋아졌을 뿐인데 왜 체감은 "완전히" 달라졌을까요? 두 사람의 증언이 힌트를 줍니다.

PDF 라이브러리 PSPDFKit을 만든 20년 차 개발자 피터 스타인버거는 에이전트가 막힐 때 더 강한 모델에게 물어보게 하는 '오라클'이라는 도구를 직접 만들어 쓰고 있었습니다. 그런데 GPT-5.2가 나오자 "오라클에게 물어봐"를 쓰는 횟수가 하루 여러 번에서 일주일에 몇 번으로 줄었다고 합니다. "던지는 건 거의 다 한 번에 해냅니다(one-shots)."

LLM을 가장 냉정하게 관찰하는 독립 개발자로 꼽히는 사이먼 윌리슨은 이렇게 표현했습니다.

"GPT-5.2와 Opus 4.5는 변곡점처럼 느껴집니다. 모델이 점진적으로 좋아지다가 보이지 않는 능력의 선을 넘어서는 순간 말이에요. 갑자기 훨씬 어려운 코딩 문제들이 한꺼번에 열립니다."

왜 '조금 좋아진 것'이 '완전히 달라진 것'이 되는가

이 현상은 확률로 생각하면 쉽게 이해됩니다. 에이전트가 기능 하나를 끝내려면 파일 읽기, 계획 세우기, 코드 쓰기, 테스트 돌리기, 에러 고치기 같은 단계를 수십 번 연달아 성공해야 합니다. 각 단계 성공률이 95%일 때 30단계를 모두 성공할 확률은 0.95^30 ≈ 21%입니다. 그런데 단계당 성공률이 99%로 "고작 4%p" 오르면, 30단계 성공률은 0.99^30 ≈ 74%가 됩니다.

사람의 체감은 "가끔 되는 신기한 장난감"에서 "대부분 되는 동료"로 넘어가는 순간 확 바뀝니다. 윌리슨이 말한 "보이지 않는 선"은 이런 곱셈의 문턱입니다. 여기에 도구 쪽의 발전 — 에이전트가 직접 테스트를 돌리고, 결과를 읽고, 다시 고치는 루프 — 이 겹치면서 체감 성능은 모델 점수보다 훨씬 가파르게 올랐습니다.

오로스 자신의 결론도 비슷합니다. 타입스크립트·Node/Express·리액트·Postgres로 일하는 그에게 "AI가 코드의 90%를 쓴다"는 말은 "충분히 사실"이 됐습니다. 코드가 마음에 안 들면 손으로 고치는 대신 프롬프트를 더 씁니다. 손으로 할 수는 있지만, 그냥 모델에게 맡기는 게 더 빠르기 때문입니다. 레디스를 만든 살바토레 산필리포는 LLM이 C 언어도 꽤 잘 쓴다고 관찰했습니다.

단, 오로스는 이 전망이 가장 먼저 들어맞을 곳을 분명히 짚습니다. 제품-시장 적합성을 찾는 스타트업(버려도 되는 코드가 많은 곳)과 그린필드 프로젝트(이해해야 할 기존 코드베이스가 없는 곳)입니다.

---

3. 이번이 처음은 아니다: '자동 프로그래밍'의 70년

"기계가 코드를 대신 쓴다"는 말, 사실 70년 전에도 있었습니다.

크게 보기

1950년대: 컴파일러의 원래 이름은 '자동 프로그래밍'이었다

1952년 그레이스 호퍼는 A-0라는 시스템을 만들었습니다. 사람이 쓴 기호를 받아 기계어를 만들어 주는, 컴파일러의 조상입니다. 당시 사람들은 이걸 '자동 프로그래밍(automatic programming)'이라고 불렀습니다. 기계어를 손으로 짜던 시절에는, 기계가 기계어를 대신 써 주는 것 자체가 "프로그래밍의 자동화"였으니까요.

1957년 IBM의 존 배커스 팀이 내놓은 포트란(FORTRAN)은 이 흐름을 결정지었습니다. 당시 숙련 프로그래머들은 회의적이었습니다. "컴파일러가 만든 코드가 사람이 손으로 최적화한 어셈블리만큼 빠를 리 없다." 배커스 팀은 그 의심을 이기기 위해 최적화 컴파일러에 사활을 걸었고, 포트란은 필요한 명령문 수를 약 20분의 1로 줄이면서도 쓸 만한 성능을 냈습니다.

그 후 무슨 일이 벌어졌을까요? 프로그래머가 사라졌을까요? 정반대입니다. 프로그래밍할 수 있는 사람과 프로그래밍할 가치가 있는 문제가 폭발적으로 늘었습니다. 어셈블리 전문가의 희소성은 줄었지만, "무엇을 계산할지 정하는 사람"의 수요는 비교할 수 없이 커졌습니다.

그 뒤로도 계단은 계속 이어졌습니다. 고급 언어, 라이브러리와 프레임워크, 오픈소스 패키지 생태계, IDE의 자동 리팩터링과 자동완성. 계단을 한 칸 오를 때마다 사람이 손으로 하던 일의 일부가 기계로 넘어갔고, 사람은 그만큼 더 높은 층의 문제를 붙잡게 됐습니다. 오로스가 원문 끝에서 "자동완성 없는 텍스트 편집기로 코드를 쓰는 게 비현실적이 된 것처럼, IDE에서 코드를 손으로 치는 것도 그렇게 될 수 있다"고 쓴 건 바로 이 계단의 다음 칸 이야기입니다.

카파시는 이 흐름에 이름을 붙이기도 했습니다. 2017년 신경망 가중치가 코드를 대신하는 '소프트웨어 2.0', 그리고 2025년 자연어 프롬프트가 곧 프로그램이 되는 '소프트웨어 3.0'. 그가 12월에 말한 "새로운 프로그래밍 가능한 추상화 계층"은 이 계단의 가장 최근 칸입니다.

1986년: 은총알은 없다 — 본질과 우발

하지만 이번 계단은 이전과 다른 점이 있습니다. 그 차이를 가장 잘 설명하는 도구는, 역설적으로 40년 전 논문입니다.

『맨먼스 미신』의 저자 프레드 브룩스는 1986년 논문 「은총알은 없다(No Silver Bullet)」에서 소프트웨어의 어려움을 두 가지로 나눴습니다.

크게 보기

• 우발적 복잡성(accidental complexity): 문제 자체가 아니라 도구 때문에 생기는 어려움. 문법, 메모리 관리, 보일러플레이트, 빌드 설정, API 사용법 같은 것들.
• 본질적 복잡성(essential complexity): 문제 자체에 들어 있는 어려움. 무엇을 만들어야 하는지, 개념들이 어떻게 맞물려야 하는지, 예외 상황은 무엇인지.

브룩스는 고급 언어 같은 발전이 우발적 복잡성을 크게 줄였지만, 본질적 복잡성은 어떤 도구도 한 방에 없앨 수 없다고 주장했습니다. 그리고 이런 문장을 남겼습니다.

"소프트웨어 시스템을 만드는 데서 가장 어려운 단 하나의 부분은, 정확히 무엇을 만들지 결정하는 것이다."

2026년의 AI 코딩 에이전트는 역사상 가장 강력한 우발적 복잡성 제거기입니다. 문법, 보일러플레이트, 낯선 언어, 반복 리팩터링 — 이런 일은 거의 공짜가 됐습니다. 그런데 그 결과로 남는 건 무엇일까요? 브룩스가 말한 본질입니다. 무엇을 만들지, 어떤 제약이 있는지, 맞게 만들었는지 어떻게 증명할지. 오로스의 글에서 "가치가 오르는 기술"로 꼽힌 것들이 모두 이 본질 쪽에 있다는 건 우연이 아닙니다.

---

4. 16%의 역설: 코딩이 공짜가 되어도 일주일은 크게 줄지 않는다

오로스는 흥미로운 숫자 하나를 꺼냅니다. 아틀라시안의 「개발자 경험 현황 2025」 보고서(응답자 3,500명)에 따르면, 개발자가 일주일 중 실제로 코딩에 쓰는 시간은 평균 16%입니다. 나머지는 회의, 리뷰, 설계 논의, 버그 조사, 채용, 동료 돕기 같은 일입니다. 마이크로소프트·스카이스캐너·우버를 거친 오로스도 "그 비율이 맞다고 느낀다"고 했습니다.

크게 보기

여기서 컴퓨터 과학의 고전 하나가 등장합니다. 1967년 IBM의 진 암달이 발표한 암달의 법칙(Amdahl's law)입니다. 원래는 "프로그램의 일부만 병렬화하면 전체가 얼마나 빨라지는가"를 계산하는 공식인데, 구조는 이렇습니다.

$$\text{전체 속도 향상} = \frac{1}{(1-p) + \dfrac{p}{s}}$$

여기서 $p$는 빨라지는 부분의 비중, $s$는 그 부분이 빨라지는 배수입니다. 코딩 비중 $p = 0.16$을 넣으면, AI가 코딩을 무한히 빠르게 해도($s \to \infty$) 일주일 전체는 $1/0.84 \approx$ 1.19배밖에 빨라지지 않습니다. 직접 움직여 보세요.

이 계산은 두 가지를 말해 줍니다.

첫째, "AI가 코드를 다 쓰니 개발자가 필요 없다"는 결론은 산수부터 맞지 않습니다. 코딩은 개발자 일의 일부일 뿐입니다. 오로스는 "AI가 2026년에 모든 코드를 쓴다 해도, 평균적인 한 주의 일부만 자유로워질 것"이라고 씁니다. 그리고 곧바로 덧붙입니다. "물론 AI가 올바른 코드를 쓰려면, 먼저 올바른 프롬프트가 필요합니다."

둘째, 검증 비용이 절약분을 잡아먹을 수 있습니다. 2025년 비영리 연구소 METR의 무작위 대조 실험에서, 자기 오픈소스 저장소에 익숙한 숙련 개발자 16명은 AI 도구를 쓸 때 과제를 19% 더 느리게 끝냈습니다. 정작 본인들은 실험 후에도 "20% 빨라졌다"고 믿었습니다. 이 실험은 2025년 초 도구 기준이라 지금과 조건이 다르지만, "빨라진 느낌"과 "빨라진 결과"가 다를 수 있다는 교훈은 여전합니다. (자세한 내용은 저커버그의 고백 특집을 참고하세요.)

그러니 진짜 질문은 "AI가 코딩을 얼마나 빨리 하나"가 아니라, "나머지 84%와 늘어난 검증 부담을 어떻게 다룰 것인가"입니다. 여기서부터 오로스의 좋은 소식, 나쁜 소식, 불편한 소식이 시작됩니다.

---

5. 나쁜 소식: 값이 떨어지는 전문성

먼저 예측 게임부터 해 봅시다. 아래 기술 각각이 AI가 코드를 거의 다 쓰는 세상에서 가치가 오를지 내릴지 골라 보세요.

이제 오로스가 "가치가 떨어진다"고 본 것들을 하나씩 살펴보겠습니다.

① 프로토타이핑: 이제 모두의 일

러버블(Lovable)과 리플릿(Replit)은 대놓고 "비개발자도 소프트웨어를 만든다"를 광고합니다. 리플릿은 NBA 전설 샤킬 오닐을 광고에 기용했는데, 개발 경험이 전혀 없는 그가 "온라인 역사상 최고의 작업 멘트 5,000개" 같은 앱을 바이브 코딩으로 만드는 장면이 나옵니다.

크게 보기

결과물은 오로스 표현대로 "기껏해야 프로토타입"입니다. 하지만 요점은 그게 아닙니다. 이제 PM, 디자이너, 사업 담당자가 개발자 없이 아이디어를 눈에 보이게 만들 수 있다는 겁니다. 개발자에게 프로토타입 제작은 더 이상 차별점이 아니라, "누구나 빠르게 콘셉트 앱을 뽑을 수 있어야 한다"는 기본값이 됩니다.

② 언어 폴리글랏과 스택 전문화의 퇴조

오로스는 채용 공고의 변천사를 기억합니다. 2000년대 초에는 "ASP.NET 개발자", "자바 개발자", "PHP 개발자"처럼 언어로 뽑았습니다. 2010년대 중반부터는 "백엔드", "프런트엔드", "iOS/안드로이드"처럼 스택으로 뽑았습니다. Go를 잘하는 백엔드 개발자는 필요하면 타입스크립트나 러스트도 배울 수 있다고 여겨졌죠.

이제 백엔드 엔지니어가 AI로 쓸 만한 프런트엔드 코드를, 크로스플랫폼 코드를, 심지어 네이티브 모바일 코드를 뽑아냅니다. 낯선 코드베이스는 AI에게 설명해 달라고 하면 됩니다. 오로스는 "스타트업이 프런트엔드와 백엔드 개발자를 따로 뽑는 모습이 잘 상상되지 않는다"고 씁니다. 대신 AI로 스택 전체의 막힌 곳을 스스로 뚫을 거라 믿을 수 있는 사람 한 명을 뽑을 겁니다.

앞서 본 스타인버거의 선택도 상징적입니다. 그는 몇 달 전까지 생각조차 안 하던 Go를 CLI 도구의 기본 언어로 쓰게 됐습니다. 이유는 "에이전트가 Go를 정말 잘 쓰고, 단순한 타입 시스템 덕에 린트가 빠르기 때문"입니다. 언어 선택의 기준이 "내가 잘 아는가"에서 "에이전트가 잘 다루고 검증이 빠른가"로 옮겨 가고 있습니다. DHH가 "러스트는 훌륭해요, 내가 절대 직접 볼 일이 없다면"이라며 HEY 2.0의 백엔드를 러스트로 다시 짓는다고 한 것도 같은 맥락입니다.

③ 잘 정의된 티켓의 구현

버그 리포트나 작은 기능 요청처럼 잘 정의된 지라·리니어 티켓은 점점 AI가 구현합니다. 커서(Cursor) 팀은 이미 모든 리니어 티켓을 에이전트에 자동으로 넘겨 원샷 구현을 받아 보고, 개발자는 머지하거나 다듬습니다. 오로스는 이게 특히 "PM이 상세한 티켓을 쓰고 개발자는 묻지 않고 구현하던" 위계적인 조직에 큰 변화가 될 거라고 봅니다.

④ 리팩터링과 ⑤ 코드 한 줄 한 줄 읽기

리팩터링은 "어떤 리팩터링을 원하는지 설명하는 것"이 손으로 하는 것보다 빨라졌습니다. 물론 큰 리팩터링은 AI가 망칠 위험이 있고, 그래서 검증 수단이 더 중요해집니다.

코드 읽기도 달라졌습니다. 그린필드 소프트웨어를 만드는 스타인버거는 솔직하게 말합니다. "요즘은 코드를 별로 안 읽습니다. 스트림을 지켜보다가 핵심 부분만 가끔 봐요. 대신 컴포넌트가 어디 있고, 구조가 어떻고, 전체 시스템이 어떻게 설계됐는지는 압니다. 보통은 그거면 충분해요."

단, 오로스는 선을 긋습니다. 성숙한 소프트웨어를 확장할 때, 보안이 걸려 있을 때, 코드가 틀리면 사업이 다칠 때는 여전히 테스트하고 읽어야 합니다.

---

6. 좋은 소식: 엔지니어는 오히려 더 귀해진다

"AI가 잘 정의된 티켓을 다 구현한다면, 그 티켓은 누가 쓰는가?" 오로스의 좋은 소식은 이 질문에서 출발합니다.

① 테크 리드의 역량이 모두의 기본기로

AI가 제대로 구현할 "완벽한 티켓"에는 두 가지가 들어가야 합니다.

• 기능 요구사항: 기능이 어떻게 동작해야 하고, 여러 엣지 케이스에서 무슨 일이 일어나야 하는가.
• 비기능 요구사항: 성능, 접근성, 신뢰성 같은 기술적 조건.

비개발자도 사용자에게 보이는 기능은 꽤 상세히 쓸 수 있습니다. 하지만 비기능 요구사항을 말로 풀어내기는 어렵습니다. 여기가 소프트웨어 엔지니어링 지식이 결정적인 지점입니다. 사용자에게 공감하면서 일을 잘 정의된 작은 조각으로 쪼개는 능력 — 원래 좋은 테크 리드의 능력 — 이 이제 신입에게도 요구됩니다. 이 주제는 설계 문서 특집에서 더 깊이 다뤘습니다.

② 테스트와 테스트 인프라: 에이전트의 눈

에이전트가 환각을 덜 일으키고 제대로 일하려면 자기 작업을 검증해 주는 피드백 루프가 필요합니다.

크게 보기

오로스는 단호합니다. "단위·통합·엔드투엔드 테스트 없이 AI가 생성한 코드를 믿는 건 상상할 수 없다." 게다가 AI는 구체적인 지시 없이는 좋은 테스트를 잘 못 쓴다고 봅니다. 그래서 그는 기능을 요청할 때 원하는 테스트의 종류까지 함께 요청하고, 그 테스트가 기대대로 쓰였는지 확인합니다.

이 경고를 생생하게 보여 주는 사례가 원문 댓글에 있습니다. 한 개발자(매트 코르)는 클로드로 오래된 사이프러스 테스트를 리액트 컴포넌트 테스트로 바꾸다가, AI가 만든 테스트 몇 개가 정상 경로와 에러 경로에서 똑같은 단언(assertion)을 하고 있었다는 걸 발견했습니다. 즉 아무것도 검증하지 않는 테스트였죠. 더 무서운 건, 그걸 본인이 아니라 동료 리뷰어가 찾아냈다는 점입니다. 그는 이렇게 씁니다. "AI가 시니어 엔지니어처럼 일했다고 믿는 게, 결과물을 비판적으로 읽는 것보다 훨씬 편합니다. 그리고 그럴 때 문제가 새어 나갑니다. 앞으로는 AI 도구에 대한 건강한 회의가 과소평가된 기술이 될 겁니다."

테스트가 CI/CD에서 돌도록 만들고, 코드베이스가 커져 테스트가 느려지면 속도를 높이고 중복을 찾아내는 일 — 예전엔 시니어의 몫이던 이 일이 AI로 코드를 많이 만드는 모든 엔지니어의 기본기가 됩니다.

③ 프로덕트 감각: '프로덕트 엔지니어'의 부상

무엇을 만들지 정하는 일이 중요해지면서, 스타트업은 '프로덕트 엔지니어' — 작은 PM과 엔지니어를 섞은 사람 — 를 뽑고 있습니다. 워크OS(WorkOS)는 PM 1명당 엔지니어가 약 80명이고 모두가 프로덕트 엔지니어입니다. 리니어(Linear)는 창업 후 몇 년간 PM이 아예 없었고, 지금도 프로덕트 엔지니어를 뽑습니다.

④ 아키텍처 판단, ⑤ 기술 부채 관리

코드가 더 빨리, 더 많이 만들어질수록 구조를 먼저 정하는 일이 결정적입니다. 모놀리스인가 독립적으로 테스트 가능한 서비스인가, 인터페이스와 경계는 어디인가, 테스트를 위한 목(mock)과 페이크(fake)는 어떻게 두는가. 오로스는 이걸 AI에게 "지시할" 결정이라고 표현합니다. 그러지 않으면 AI가 제멋대로 구조를 꿈꾸게 되고, AI가 있어도 유지보수하기 어려운 소프트웨어에 갇힙니다.

그리고 코드가 많아지면 기술 부채도 많아집니다. 경험이 적은 엔지니어는 다 알아채지 못하고, 그사이 신뢰성 문제·성능 저하·버그가 스며들며 코드를 건드리기 점점 어려워집니다.

⑥ 신뢰성·성능·확장성·보안

오로스의 문장 중 가장 자주 인용될 만한 문장이 여기 있습니다.

"안전하고 성능 좋은 코드를 만들어 달라고 AI에게 프롬프트할 수는 없습니다. 무엇을 원하는지 알고, 비기능 요구사항을 어떻게 검증할지 알고, 코드를 설계하고, 그에 맞게 프롬프트해야 합니다. 때로는 AI를 내려놓고 세부를 맞추기 위해 직접 코드나 설정을 써야 할 수도 있습니다."

누구나 "어느 순간까지는 대충 돌아가는" 소프트웨어를 만들 수 있게 될수록, 항상 기대대로 돌아가는 소프트웨어를 만드는 사람의 값은 오릅니다.

⑦ '코더'가 아니라 '엔지니어'

이 모든 것을 한 문장으로 줄이면 이렇습니다. 코드 생성이 흔해질수록, 소프트웨어를 만드는 일의 '엔지니어링' 부분이 훨씬 중요해진다. 2025년 비개발자 사이에서 바이브 코딩이 빠르게 퍼졌지만, 많은 사람이 곧 깨달았습니다. AI가 코드를 다 써 줘도, 실제로 제대로 돌아가는 소프트웨어를 만드는 건 어렵다는 것을요. 오로스가 그 무렵 만든 밈이 이것입니다.

크게 보기

---

7. 불편한 진실: 코드가 늘면, 문제도 는다

좋은 소식만 있다면 특집으로 다룰 이유가 없겠죠. 오로스는 "추한(ugly)" 결과들도 숨기지 않습니다.

① 코드의 홍수

메타에서 가장 생산적인 개발자였고, 메타의 '코딩 머신(Coding Machine)'이라는 엔지니어 원형(archetype) 자체가 그를 본떠 만들어졌다는 마이클 노바티. 그의 깃허브 기여 기록을 AI를 거의 안 쓰던 2024년과 많이 쓴 2025년으로 비교하면 이렇습니다.

크게 보기

기여 횟수가 6,090회에서 11,479회로 약 1.9배가 됐습니다. 그는 스타트업에서 일하며 1년간 새 기능 1,500개 이상, 버그 수정 800개 이상을 커밋했고, 월 400~600회, 하루 15~25회의 커밋 속도를 냈습니다.

인상적인 숫자입니다. 하지만 오로스는 뒷면을 봅니다. 코드가 많아지면 버그, 보안 문제, 기타 문제가 생길 기회도 많아집니다. 더 복잡한 서비스, 더 많은 데이터, 더 많은 컴퓨팅 — 자원 사용량도 늘어납니다.

② 품질의 하락: 데이터가 말하기 시작했다

오로스가 인용한 코텍스(Cortex)의 「AI 시대의 엔지니어링: 2026 벤치마크 리포트」는 엔지니어링 리더 50여 명의 조사와 조직들의 개발 지표를 분석했습니다.

변경 실패율(change failure rate)은 배포 중 장애나 롤백을 일으킨 배포의 비율입니다. 구글의 DORA 연구가 소프트웨어 전달 성과를 재는 핵심 지표로 쓰는 값이죠. 속도는 빨라졌지만 품질은 떨어지고 있다는 뜻입니다. 코텍스는 이를 "AI는 기존의 엔지니어링 관행을, 좋은 것이든 나쁜 것이든 가리지 않고 증폭한다"고 요약했고, 공식 AI 사용 정책을 가진 조직은 45%뿐이었습니다. DORA의 2025년 보고서 역시 AI를 "증폭기(amplifier)"라고 불렀습니다. 강한 팀은 더 강하게, 약한 팀의 약점은 더 크게 만든다는 거죠.

왜 이런 일이 생길까요? 오로스의 설명은 단순합니다. 더 많고 더 큰 PR을 예전과 같은 기준으로 리뷰하는 건 현실적으로 불가능합니다. 사람의 주의력은 AI처럼 두 배로 늘지 않으니까요.

크게 보기

아래 모델로 직접 확인해 보세요. PR 양만 두 배로 올리면 무슨 일이 생기는지, 그리고 리뷰 시간을 늘리는 것과 자동 테스트를 늘리는 것 중 어느 쪽이 더 확장성 있는지.

③ 약한 관행은 더 빨리 아프다

자동 테스트 문화가 없고, 코딩 가이드라인을 따르지 않고, 관측 가능성(observability)이 부족한 팀은 더 많은 회귀 버그와 장애를 운영에 내보내게 됩니다. 나쁜 것이 운영에 도달하는 빈도도, 속도도 함께 올라가기 때문입니다. AI 코딩을 도입하기 전에 테스트와 모니터링부터 챙겨야 하는 이유입니다. (측정의 함정은 AI 코딩을 잘못 측정하는 12가지 방법에서 따로 다뤘습니다.)

④ '코더'의 수요 감소

일을 쪼개고, 테스트와 관측을 고려해 설계하고, 규모와 신뢰성을 위해 만드는 능력 없이 코드를 쓰는 능력만 가진 개발자는 일자리를 찾기 더 어려워질 수 있습니다. 비개발자도 AI로 코드를 생성할 수 있는 세상에서, 코드를 쓰는 것 이상의 무언가가 필요합니다.

⑤ AFK가 사라진 세상

오로스는 2026년이 원격 가상 샌드박스에서 도는 AI 에이전트의 해가 될 거라고 봤습니다. 실제로 그렇게 됐죠. 노트북 없이 브라우저나 휴대폰으로 프롬프트하고, 검증하고, 배포합니다. 슬랙이 모바일로 넘어왔을 때 개발자가 언제든 연락받게 된 것처럼, 이제는 언제 어디서든 버그를 고치고 배포할 수 있게 됩니다.

크게 보기

데이터독 출신 엔지니어 도노반 딕스의 우려는 뼈아픕니다.

"미국의 연봉제 직원으로서 저는 밤늦게 장애를 처리하거나, 출퇴근길에 메시지에 답하거나, 근무 시간 밖에 한 일로 추가 보상을 받아 본 적이 없습니다. 자리에 없다(AFK)는 것은 제 개인 시간을 침범하는 업무 책임에 맞설 수 있는, 몇 안 남은 방어선 중 하나입니다. 모바일 코딩이 일상이 되면, 그 방어선은 사라질 수도 있어요."

오로스가 휴대폰으로 PR을 머지하며 느낀 전율과, 딕스가 느끼는 불안은 같은 기술의 양면입니다.

⑥ 주니어는 곧바로 시니어가 되어야 하는가

AI로 코드 대부분을 만드는 엔지니어에게 새로 요구되는 것들을 모아 보면 이렇습니다.

오로스의 지적대로, 이건 원래 최상위 회사에서 시니어나 스태프 엔지니어의 기본값이었습니다. 그런데 이제 신입의 기본값이 되려 합니다. 문제는 예전 신입들은 몇 년간 코드를 많이 써 보면서 선배 곁에서 이 능력들을 익혔다는 겁니다.

크게 보기

이 걱정은 추상적이지 않습니다. 스탠퍼드 디지털 경제 연구소의 브린욜프슨·찬다르·천이 미국 최대 급여 처리 회사 ADP의 데이터를 분석한 논문 「탄광 속 카나리아?(Canaries in the Coal Mine?)」에 따르면, 22~25세 소프트웨어 개발자의 고용은 2022년 말 정점 대비 2025년 7월까지 약 20% 줄었습니다. 같은 기간 경력자의 고용은 안정적이었습니다. 연구진은 AI가 교과서로 배울 수 있는 "책 지식"을 대체하기 쉽고, 경험에서 오는 "암묵지"는 대체하기 어렵기 때문이라고 해석합니다.

산업 심리학에는 이 문제를 40년 전에 예견한 고전이 있습니다. 1983년 리산 베인브리지의 논문 「자동화의 아이러니(Ironies of Automation)」입니다. 핵심은 이렇습니다. 자동화가 일상 업무를 가져가면 사람은 그 업무를 할 기회를 잃고 숙련도가 떨어집니다. 그런데 자동화가 실패하는 가장 어렵고 예외적인 순간에는 바로 그 사람이 개입해야 합니다. 쉬운 일을 기계에게 넘긴 결과, 어려운 일을 해낼 사람이 자라지 못하는 역설이죠. AI가 코드를 쓰는 시대의 주니어 교육은 정확히 이 아이러니 위에 서 있습니다.

그래도 오로스는 비관하지 않습니다. "경험상 신입들은 매우 유능하고 배우려는 의지가 강하다. 많은 이들이 예전엔 긴 경력자만 맡던 역할에서 오히려 두각을 나타낼 것"이라고 봅니다.

⑦ 컴퓨터 과학 교육이 다시 입장권이 될까

신입 채용 담당자라면, 경력 0년인데 아키텍처 패턴·자동 테스트·기술 부채를 알고, 팀 프로젝트에서 AI 도구로 뭔가 만들어 본 사람을 원하게 됩니다. 무리한 요구 같지만, 일부 대학 프로그램은 3~5년에 걸쳐 이론과 실습, 팀 프로젝트를 이미 가르칩니다. 하버드는 LLM 관련 과목을 열었고요.

오로스는 여기에 한 가지 관점을 더합니다. AI가 쓴 지원서가 채용 과정을 막아 버리는 시대에, 대학은 "스팸 필터" 역할도 합니다. 지역 대학과 직접 협력하면 지원자가 진짜라는 확신을 얻을 수 있다는 거죠.

⑧ 누군가는 책임져야 한다

더 많은 코드, 더 많은 소프트웨어, 더 많은 유지보수. 이건 클라우드·인프라 도구·소프트웨어 정확성 검증 도구 회사에게는 호재입니다. 그리고 운영 중인 소프트웨어에 문제가 생기면 책임은 어딘가에서 멈춰야 합니다. 오로스는 그게 비개발자가 아니라, AI가 생성한 소프트웨어를 이해하고 유지할 수 있으며 자기 프롬프트로 배포된 코드에 책임질 수 있는 전문 엔지니어일 거라고 봅니다.

1985년 튜링상 수상자 피터 나우르는 「이론 구축으로서의 프로그래밍(Programming as Theory Building)」이라는 에세이에서, 프로그램의 진짜 실체는 코드가 아니라 그걸 만든 사람들 머릿속에 있는 '이론' — 이 코드가 왜 이렇게 생겼고, 세상의 어떤 문제에 어떻게 대응하는지에 대한 이해 — 이라고 했습니다. 코드를 AI가 쓰더라도, 그 이론을 가진 사람이 없으면 아무도 그 소프트웨어를 책임질 수 없습니다.

---

8. PM과 엔지니어: 합쳐질까, 갈라질까

AI가 명세대로 코드를 만들어 준다면, PM이 엔지니어 없이 소프트웨어를 만들 수 있지 않을까요? 실제로 이 변화에 들뜬 PM도 많습니다. 하지만 오로스는 다르게 봅니다. 두 직업은 대체가 아니라 겹침으로 갈 거라고요.

크게 보기

• 엔지니어는 훨씬 더 프로덕트 지향적이 되고 고객 가까이에 머뭅니다. 고객이 보고한 버그를 PM의 분류나 지시 없이 바로 고칩니다.
• PM은 훨씬 더 손을 쓰게 됩니다. 고객에게 보여 줄 프로토타입을 엔지니어 없이 만들고, 가끔은 엔지니어가 머지할 버그 수정도 제출합니다.
• 팀은 더 작고 효율적이 되고, PM이 요구사항 문서(PRD)를 넘기면 엔지니어링 팀이 만들기 시작하는 식의 형식적인 인수인계는 줄어듭니다.

리니어 공동 창업자 카리 사리넨은 이를 "중간 소프트웨어 작업의 소멸"이라고 표현했습니다.

"순수한 코딩 에이전트 작업 흐름은 이제 목표, 맥락, 과업만으로 동작하는 코드를 만들어 냅니다. IDE는 쓰는 도구라기보다 코드를 보는 도구가 됩니다. 의도를 구현으로 번역하는 '중간'이 점점 얇아집니다.

그래도 무엇을 만들어야 하는가는 여전히 중요한 질문입니다. 이런 의미의 설계는 산출물이나 도구가 아닙니다. 아이디어, 탐색, 조사, 논의를 통해 의도의 명료함을 형성하는 일이고, 무엇이 중요한지, 어떤 제약이 있는지, 어떤 트레이드오프를 받아들일지 정하는 일입니다.

이 시대에는 에이전트의 작업을 지휘하고 관리하는 것이 곧 기술(craft)이 됩니다. 코드를 쓰는 건 해법을 짓는 것이라기보다, 좋은 해법이 떠오를 조건을 만드는 것에 가까워집니다."

브룩스가 1986년에 말한 "정확히 무엇을 만들지 결정하는 것"과, 사리넨이 2026년에 말한 "의도의 명료함"이 정확히 같은 곳을 가리키고 있다는 게 흥미롭지 않나요?

---

9. 2026년 9월, 우리는 어디쯤 와 있나

예언은 얼마나 맞았나

오로스가 1월에 "올해 많은 개발자와 팀에서 AI가 코드의 90% 이상을 쓰게 될 것"이라고 가정했을 때, 그건 과감한 가정이었습니다. 아홉 달 뒤 DHH의 키노트는 그 가정이 적어도 일부 회사에서는 조직 단위의 운영 방식이 됐음을 보여 줬습니다.

동시에 반응이 모두 뜨거웠던 건 아닙니다. 해커 뉴스에서 키노트 관련 글은 첫 24시간 동안 비교적 조용했고, 레일스 애플리케이션들의 일상도 당장 바뀌지는 않았습니다. 오로스 자신도 원문 결론에서 인정합니다. 개발자가 원래 코드를 거의 안 쓰고, 복잡성이 코드 주변을 헤쳐 나가는 일에 있는 대형 조직에서는 AI의 효과가 크지 않을 수 있다고요. 그의 "아하" 모먼트도 테스트가 전부 갖춰진 단순한 코드베이스, 위험도가 낮은 제품에서 나왔습니다.

싸지면, 더 많이 만든다: 제번스의 역설

그렇다면 개발자의 미래는 어두운 걸까요? 오로스의 결론은 의외로 낙관적입니다. "5년 뒤에는 지금보다 소프트웨어 전문가 수요가 더 높을 것이다. AI가 만들어 내는 소프트웨어 양의 폭발 덕분에."

이 전망의 뒤에는 1865년 경제학자 윌리엄 스탠리 제번스가 『석탄 문제(The Coal Question)』에서 관찰한 역설이 있습니다. 증기기관의 석탄 효율이 좋아지자 석탄 소비는 줄어든 게 아니라 오히려 늘었습니다. 석탄으로 할 수 있는 일이 싸지니, 석탄을 쓰는 곳이 폭발적으로 늘어난 겁니다.

크게 보기

소프트웨어도 같은 길을 걸을 수 있습니다. 소프트웨어를 만드는 비용이 떨어지면, 예전엔 "개발비가 안 나와서" 못 만들던 수많은 소프트웨어 — 동네 병원의 예약 시스템, 중소기업의 사내 도구, 한 사람만을 위한 앱 — 가 만들어집니다. 그리고 그 모든 소프트웨어는 누군가 설계하고, 연결하고, 운영하고, 책임져야 합니다. 1950년대 컴파일러가 프로그래머를 없애지 않고 오히려 폭발적으로 늘린 것처럼요.

물론 제번스의 역설이 자동으로 모두를 구해 주지는 않습니다. 늘어나는 수요는 "코더"가 아니라 "엔지니어"를 향할 가능성이 큽니다. 그리고 주니어 사다리 문제처럼, 그 수요에 닿기 위한 경로가 좁아지는 문제는 별개로 풀어야 합니다.

---

10. 그래서, 무엇을 준비할 것인가

원문의 논지를 2026년 9월 시점에서 실천 목록으로 정리해 보면 이렇습니다.

---

맺으며: 몰입의 자리는 한 층 위로 옮겨 갈까

오로스의 원문에서 가장 오래 남는 대목은 분석이 아니라 고백입니다.

"AI가 제가 운영에 내보내는 코드 대부분을 쓰게 될 가능성이 높다는 사실을 받아들이는 중입니다. 이미 더 빠르고, 제가 직접 친 것과 비슷한 결과를 냅니다. 익숙하지 않은 언어라면 저보다 낫고요.

뭔가 소중한 것을, 갑자기 빼앗기는 느낌입니다. 코딩을 잘하게 되기까지 정말 많은 노력이 들었습니다. 대학에서 C를 처음 배우던 수업이 얼마나 막막했는지, 첫 직장에서 복잡한 코드베이스 앞에서 얼마나 길을 잃었는지 아직 기억합니다.

코드를 만들던 최고의 기억들은 대부분 코딩에 관한 것입니다. 몰입해서 여러 생각을 동시에 저글링하며 타이핑하다가, 컴파일하고, 실행하고, '그래!' 하고 기대대로 동작하는 걸 보던 순간들요. 이제 그 모든 게 역사가 될 것 같습니다."

그리고 그는 질문을 남깁니다. "어쩌면 AI 에이전트와 함께라면, '몰입'은 더 높은 층의 문제를 생각하면서 더 복잡한 코드를 지시하는 쪽으로 옮겨 가는 건 아닐까?"

70년 전 어셈블리를 손으로 최적화하던 프로그래머들도 포트란 컴파일러 앞에서 비슷한 상실감을 느꼈을 겁니다. 레지스터 하나, 명령어 하나를 아껴 가며 짜던 장인의 즐거움은 분명히 사라졌습니다. 하지만 그 대신 사람들은 달 착륙 궤도를 계산하고, 전 세계 항공권을 예약하고, 인터넷을 만들었습니다. 몰입의 자리가 한 층 위로 옮겨 간 겁니다.

카파시가 말한 "설명서 없는 외계 도구"를 어떻게 쥐어야 하는지는 아직 아무도 완전히 모릅니다. 하지만 이 특집에서 따라온 모든 근거 — 브룩스의 본질적 복잡성, 암달의 16%, 코텍스의 변경 실패율, 베인브리지의 아이러니, 나우르의 이론, 제번스의 역설 — 는 한 방향을 가리킵니다.

코드는 싸졌습니다. 하지만 "무엇을 만들지 정하고, 그게 맞다는 걸 증명하고, 그 결과에 책임지는 일"은 그 어느 때보다 비싸졌습니다. 오로스의 말처럼, 그게 원래부터 좋은 소프트웨어 엔지니어링이 하던 일입니다.

---

참고 자료

• Gergely Orosz, When AI writes almost all code, what happens to software engineering?, The Pragmatic Engineer, 2026-01-07 (2026-09-24 무료 공개)
• DHH, Rails World 2026 Opening Keynote, 2026-09-23 · Pencils down: what DHH actually said at Rails World 2026
• Cortex, Engineering in the Age of AI: 2026 Benchmark Report
• Atlassian, State of Developer Experience Report 2025
• Brynjolfsson, Chandar, Chen, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence, Stanford Digital Economy Lab, 2025
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025
• Google Cloud DORA, State of AI-assisted Software Development, 2025
• Frederick P. Brooks, "No Silver Bullet — Essence and Accident in Software Engineering", 1986
• Gene Amdahl, "Validity of the single processor approach to achieving large scale computing capabilities", AFIPS, 1967
• Lisanne Bainbridge, "Ironies of Automation", Automatica, 1983
• Peter Naur, "Programming as Theory Building", 1985
• John Backus, "The History of FORTRAN I, II, and III", ACM SIGPLAN History of Programming Languages, 1978
• William Stanley Jevons, The Coal Question, 1865
• Andrej Karpathy, "Software 2.0", 2017 · 드와르케시 팟캐스트 인터뷰, 2025-10 · X 게시물, 2025-12-26