AI가 거의 모든 코드를 작성하면, 소프트웨어 엔지니어링은 어떻게 될까?

게시일: 2026년 1월 8일 | 원문 작성일: 2026년 1월 7일 | 저자: Gergely Orosz | 원문 보기 (유료)

• • •

이번 겨울 휴가 기간은 개발자들이 일상 업무에서 벗어나 사이드 프로젝트를 시험해볼 기회였어요. 최소한 저는 그랬어요. 2025년 내내 만들고 싶었지만 손대지 못했던 몇 가지 기능들—대기업을 위한 셀프서비스 그룹 구독 기능과 The Pragmatic Engineer를 위한 커스텀 관리 패널—을 AI 에이전트를 활용해 완성할 수 있었거든요.

예상치 못하게, Opus 4.5와 GPT 5.2 같은 LLM들이 제가 할당한 중간 규모 작업들을 놀랍도록 잘 해냈어요. 결국 저는 프로덕션에 몇백 줄의 코드를 푸시하게 되었는데, 이 과정은 단순히 LLM에 프롬프트를 주고, 출력을 검토하고, 테스트가 통과하는지 확인한 다음(제가 프롬프트로 요청한 새 테스트도 통과했어요!), 마지막 조정을 위해 조금 더 프롬프트를 주는 것뿐이었어요.

더 마법 같은 경험도 있었어요. 휴대폰에서 프로덕션 소프트웨어를 만들 수 있게 됐거든요. GitHub에 연결된 Claude Code for Web을 설정하고, Claude 모바일 앱으로 코드 변경과 테스트 추가 및 실행을 지시했어요. Claude는 GitHub Actions를 트리거하는 PR을 만들었고(Claude가 직접 실행할 수 없는 테스트를 GitHub Actions가 실행), 저는 여행 중에 순전히 모바일 기기만으로 새로운 기능이 담긴 PR을 리뷰하고 머지했어요. 물론 위험도가 낮은 작업이었고 모든 비즈니스 로직이 자동화된 테스트로 커버되어 있었지만, 휴대폰에서 코드를 “생성”하고 프로덕션에 푸시하는 스릴은 전에 없던 경험이었어요.

이런 경험은 저만의 것이 아니에요. 많은 다른 사람들도 공유하고 있으며, 이는 소프트웨어 엔지니어링 도구에서 단계적 변화가 진행 중임을 시사해요. 이 글—2026년 첫 번째 글—에서 우리는 현재 상황과 AI가 코드의 대부분을 작성하는 엄청난 변화가 개발자들에게 어떤 의미를 가질 수 있는지 탐구해요.

1. 최신 모델들이 만들어내는 “아하!” 순간들

지난 몇 주 동안, 경험 많은 소프트웨어 엔지니어들이 AI 도구가 그들이 작성하는 대부분의 코드를 생성할 수 있을 만큼 충분히 좋아졌다는 개인적인 “아하!” 순간들을 공유해왔어요.

Google의 수석 엔지니어 Jaana Dogan은 Claude Code가 얼마나 발전했는지에 매우 감명받았어요:

Amp의 소프트웨어 엔지니어 Thorsten Ball은 이렇게 회고했어요:

Vercel의 CTO Malte Ubl:

AI 도구를 판매하는 회사에서 일하는 사람들의 목소리라고 할 수도 있어요. 하지만 어떤 벤더에도 관심이 없는 엔지니어들도 비슷한 관찰을 했어요.

Ruby on Rails의 창시자 David Heinemeier Hansson(DHH)은 개선된 모델로 인해 AI에 대한 입장이 어떻게 바뀌었는지 설명했어요:

Tailwind CSS의 창시자 Adam Wathan은 이렇게 회고했어요:

"AI 슬롭”에서 업계를 뒤흔드는 것으로

널리 회자된 “아하!” 순간 중 하나는 OpenAI의 공동 창업자 Andrej Karpathy에게서 나왔어요. Andrej는 수년간 OpenAI에 관여하지 않았으며, AI 도구에 대한 솔직한 평가와 비판으로 알려져 있어요. 지난 10월, Dwarkesh 팟캐스트5에서 AI 코딩 도구를 과대평가라고 요약했어요:

두 달 후, 그 견해는 완전히 수정되었고, Karpathy는 12월 26일에 이렇게 썼어요:

Claude Code의 창시자 Boris Cherny는 지난달 그의 모든 커밋 기여가 AI가 작성한 것이라고 공유하며 응답했어요:

2. 왜 지금일까?

11월과 12월의 모델 출시가 AI가 코드 생성에서 정말 좋아진 티핑 포인트로 보여요:

• Gemini 3 (Google, 11월 17일): Google의 현재까지 최고의 코딩 모델
• Opus 4.5 (Anthropic, 11월 24일): Claude Code의 기본 모델이 된 회사 최고의 코딩 모델
• GPT-5.2 (OpenAI, 12월 11일): Codex를 구동하며, Opus를 탑재한 Claude Code와 비슷하게 인상적

저는 Opus 4.5와 GPT-5.2 둘 다 사용해봤고, 둘 다 코딩에 매우 유능해 보여요. 이것은 틈새 의견이 아니에요. ~20년 경력의 소프트웨어 엔지니어이자 PSPDFkit의 창시자 Peter Steinberger는 GPT-5.2에 대해 이렇게 인상을 전했어요:

LLM 분야의 독립적인 소프트웨어 엔지니어링 전문가 Simon Willison도 같은 점을 지적했어요:

황당한 예측이 현실이 되다?

저를 포함한 많은 사람들이 회의적이었던 예측이 있어요. Anthropic CEO Dario Amodei가 지난 3월에 한 말입니다:

그런데 12월에 Cherny의 Claude Code 기여 코드 100%가 AI가 작성한 것으로 실현되었어요. 악마의 변호인 역할을 하자면, Claude Code는 비공개 소스이므로 그 주장을 검증하기 어렵다고 할 수 있어요. 물론 Claude Code 같은 것의 창시자는 고성능 기능을 보여주고 싶어하겠죠. 하지만 저는 Boris와 대화해봤고 그를 신뢰해요. 또한 Claude Code 사용에 대한 제 경험도 그와 일치해요: 저도 제가 커밋하는 모든 코드를 Claude Code가 생성하게 해요.

코드가 원하는 대로가 아닐 때는, LLM이 고치도록 더 많은 프롬프트를 해요. Boris처럼, 저도 손으로 코드를 작성하는 것을 그만뒀어요. 해야 할 필요가 없고, 모델이 충분히 능력이 있어 보이기 때문이에요. 여전히 할 수 있지만, 모델에게 맡기는 것이 단순히 더 빨라요.

제 IDE에서 잘 알고 탐색할 수 있는 코드조차도, 에이전트에게 프롬프트하면 제가 직접 하는 것만큼, 아니 더 빠르게 편집을 완료할 수 있다는 것을 알아챘어요. 그럼에도 불구하고, 저는 그 일을 할 수 있다는 것을 알고 싶어서 IDE로 가기도 해요.

제 사용 사례에서, AI가 제가 작성하는 코드의 90%를 생성할 수 있다는 주장은 충분히 사실처럼 느껴져요—제 경우 TypeScript, Node/Express, React, Postgres를 기술로 사용하고 있어요. Go, Rust 및 LLM이 풍부한 훈련 데이터를 가진 다른 인기 언어와 프레임워크에서도 점점 같은 상황이 되고 있다고 이해해요. 흥미롭게도, LLM은 C에서도 꽤 좋은 것 같아요. Redis 창시자 Salvatore Sanfilippo(antirez)가 관찰한 바와 같이.

이 글의 나머지 부분은 AI 코딩 도구가 올해 많은 개발자와 팀에게 코드의 ~90% 이상을 생성할 만큼 충분히 좋아질 것이라고 가정합니다. 이 이정표에 가장 유력한 후보는 제품-시장 적합성3을 찾는 스타트업들—버려지는 작업이 큰 문제가 아닌—과 기존 코드베이스를 수집하거나 이해할 필요 없이 새로운 것을 구축하는 그린필드4 개발 프로젝트로 보여요.

물론, 일부 코드베이스나 컨텍스트에서 충분히 잘 작동하지 않거나, 개발자가 의도적으로 의존하지 않기로 선택하는 경우 등 AI 코딩 도구에 전적으로 의존하는 것이 적합하지 않은 경우도 많을 거예요.

거의 모든 코드가 개발자가 타이핑하는 대신 프롬프트를 통해 AI에 의해 생성되는 환경에서 소프트웨어 엔지니어링 직업이 어디로 갈 수 있는지 탐구할 가치가 있어요. 이것은 직업에 영향을 미치는 큰 변화가 될 것이지만, 어떻게? 잠재적인 부정적인 것부터 시작해서 좋은 것, 나쁜 것, 그리고 불편한 것을 살펴봅시다.

3. 나쁜 것: 전문성 가치의 하락

과거에 가치가 있었던 것들 중 일부는 대부분 AI에 위임될 거예요:

프로토타이핑. Lovable과 Replit 같은 플랫폼은 비기술인들이 소프트웨어를 구축할 수 있는 방법으로 명시적으로 광고하고 있어요. 최근 광고에서 Replit은 전설적인 NBA 스타 Shaquille O’Neal과 팀을 이루어 온라인 역사상 최고의 5,000개 픽업 라인을 얻는 앱 등을 바이브 코딩2했어요.

원문 보기

AI 도구와 함께, 제품 담당자, 디자이너, 비즈니스 사람들이 자신만의 프로토타입을 만들 수 있고, 더 이상 아이디어를 실현하기 위해 개발자가 필요하지 않아요. 이와 함께, 모든 개발자가 컨셉 앱을 빠르게 생성할 수 있어야 한다는 것이 기본 기대가 될 거예요.

언어 폴리글랏이 되는 것은 아마 덜 가치 있어질 거예요. 여러 언어의 전문가인 엔지니어들은 엔지니어링 팀들이 종종 자신의 스택 전문가를 고용하고 싶어하기 때문에 전통적으로 탐내왔어요. 그래서 Go를 사용하는 팀은 종종 Go 지식을 가진 시니어 엔지니어를 고용하는 것을 선호하고, Rust, TypeScript 등도 마찬가지예요. 일부 진보적인 팀들은 후보자의 특정 언어 전문성을 무시하고 유능한 엔지니어가 언어를 빠르게 익힐 수 있다고 가정한다는 점을 언급해야겠어요.

하지만 AI가 대부분의 코드를 작성하면, 어떤 엔지니어든 어떤 코드베이스에 들어가서 AI에게 기능을 구현해달라고 요청할 수 있을 때 여러 언어를 아는 장점은 덜 중요해질 거예요—그리고 AI는 아마 괜찮은 시도를 할 거예요. 더 좋은 것은, AI에게 코드베이스의 부분을 설명해달라고 요청하고 AI 도구 없이보다 훨씬 빠르게 언어를 익힐 수 있다는 거예요.

언어 전문화와 프론트엔드/백엔드 전문화의 종말? 2000년대 초반에는, 대부분의 구인 광고가 특정 언어에 대한 후보자를 원했던 것을 기억해요: ASP.NET 개발자, Java 개발자, PHP 개발자 등. 2010년대 중반부터, 더 많은 회사들이 스택의 전문화에 기반해 고용하기 시작했어요: 백엔드 개발자, 프론트엔드 개발자, 네이티브 iOS/Android 개발자, 크로스 플랫폼 모바일 개발자. 백엔드에서는, Go 같은 언어를 꽤 잘 아는 개발자가 필요에 따라 TypeScript, Scala, Rust 또는 다른 언어를 익힐 수 있다는 것이 받아들여졌어요. 특정 언어에 대한 역할이 여전히 중요한 곳은 네이티브 모바일이었어요. iOS와 Android 프레임워크가 하나 또는 다른 것에 대한 깊은 전문성을 요구할 만큼 충분히 달랐기 때문이에요.

하지만 오늘날 AI와 함께, 백엔드 엔지니어가 괜찮은 프론트엔드 코드, 크로스 플랫폼 코드, 심지어 네이티브 모바일 코드도 프롬프트할 수 있어요. 이 도구와 함께, 스타트업들이 별도의 프론트엔드와 백엔드 개발자를 고용하는 것을 예상하기 어려워요: 그들은 AI를 사용해 스택 전체에서 스스로를 해제할 것을 신뢰하는 전문가를 고용할 거예요.

잘 정의된 티켓을 구현하는 것은 AI가 점점 더 할 일이에요. 잘 정의된 JIRA나 Linear 티켓—버그 리포트나 작은 기능 요청 같은—을 받아서 구현하는 것이에요. 오늘날에도, Cursor6 팀은 모든 Linear 티켓이 자동으로 Cursor에 전달되어 구현을 원샷으로 하는 자동화를 가지고 있어요. 그러면 개발자가 그것을 머지하거나 반복 작업할 수 있어요. 더 많은 컨텍스트가 전달되고 모델이 더 좋아질수록, 출력이 머지 가능할 가능성이 높아져요.

이것은 큰 변화가 될 거예요, 특히 프로젝트나 제품 매니저가 개발자가 질문 없이 구현할 상세한 티켓을 오래 작성해온 위계적 직장에서!

리팩토링은 아마 점점 더 AI에 위임될 거예요. 이미 리팩토링에 꽤 좋고 도구는 아마 더 좋아질 거예요. 손으로 리팩토링하는 것은 AI에게 어떤 유형의 리팩토링을 원하는지 설명하는 것보다 훨씬 느릴 거예요. 물론, AI 이전 시대에도, 현대 IDE는 함수나 클래스 이름 변경을 전체 코드베이스에 걸쳐 수행하고 함수를 추출하는 것 같은 지루한 작업을 가속화하기 위한 강력한 리팩토링 기능을 제공했어요.

물론, AI가 특히 대규모 리팩토링에서 일을 망칠 위험은 항상 있어요. 이것이 코드를 검증하는 방법이 올해 훨씬 더 중요해질 이유예요.

생성된 코드에 주의를 기울이는 것—일부 경우에는? AI 프롬프트에서 코드를 생성하면 장황한 코드나 추상화를 사용하는 대신 기존 코드의 복제를 초래할 수 있어요. 하지만 개념 증명을 만들거나 프로그램 효율성 같은 주제가 중요하지 않을 때는 이것이 완전히 수용 가능한 경우도 있어요.

그린필드 소프트웨어를 구축하는 소프트웨어 엔지니어 Peter Steinberger는 AI가 생성한 코드를 읽는 것을 그만뒀다고 말했어요:

그럼에도, 기존의 성숙한 소프트웨어를 확장하거나 보안 문제를 피해야 할 때 코드 읽기는 여전히 중요할 거예요. 일반적으로, 배포된 코드가 작동하지 않고 비즈니스에 해를 끼치면, 정확성을 위해 테스트하고 리뷰하고 싶을 거예요.

4. 좋은 것: 소프트웨어 엔지니어가 이전보다 더 가치 있어진다

개발자들이 모든 시간을 코딩에 쓰지 않는다는 것은 업계의 공공연한 비밀이에요—적어도 대부분의 직장에서는요. 3,500명의 응답자가 작성한 Atlassian의 State of Developer Experience 2025 보고서는 평균 개발자가 주당 16%를 코딩에, 나머지를 관리 업무에 쓴다고 발견했어요. Microsoft, Skyscanner, Uber 같은 곳에서의 제 시간을 돌아보면, 그 비율은 맞는 것 같아요: 저는 다른 사람들을 돕고, 코드 리뷰를 하고, 설계와 버그에 대해 토론하고, 계획, 팀, 일반 미팅에 참석하고, 채용하고, 다른 사람들과 연락하고 더 많은 일을 했어요.

그래서, AI가 2026년에 모든 코드를 작성한다 해도, 평균 근무 주의 일부만 비울 거예요. 하지만 분명히, AI가 올바른 유형의 코드를 작성하려면 먼저 올바른 프롬프트가 필요해요.

테크 리드 특성은 거의 확실히 더 수요가 있을 거예요. AI가 잘 정의된 티켓을 구현할 수 있을 때, 누가 AI가 올바르게 코드를 만들게 하는 티켓을 작성할까요? “완벽한” 티켓을 작성하려면 다음 둘 다 개요해야 해요:

• 기능적 작업을 위한 사용자 요구사항: 기능이 어떻게 작동해야 하는지, 다양한 엣지 케이스에서 어떤 일이 일어나야 하는지
• 성능, 접근성, 신뢰성 관련 작업 같은 비기능적 요구사항을 위한 기술적 세부사항

비기술적인 사람이 사용자 대면 작업에 대한 상세한 티켓을 작성할 수는 있지만, 비기능적 요구사항을 명확히 하기는 매우 어려울 거예요. 이것이 소프트웨어 엔지니어링 지식이 점점 더 중요해지는 곳이에요. 또한, 사용자와 공감하고 작업을 잘 정의된 작업으로 분해할 수 있는 실무 엔지니어는 이 새로운 세계에서 더 수요가 있을 거예요. 공교롭게도, 이것은 좋은 테크 리드가 이미 가진 능력이에요. 유일한 변화는 신입 엔지니어도 업무의 코딩 부분에서 더 빨리 발전하고 싶다면 이것을 마스터해야 한다는 거예요.

테스트와 테스트 인프라에 능숙해지는 것이 더 중요해질 거예요. 에이전트가 더 효과적이고 환각에 덜 취약하려면, 작업을 검증하는 피드백 루프가 필요해요. 빠르게 실행되는 예시는:

• 코드 컴파일 (컴파일되나요?)
• 정적 분석 실행 (정의된 규칙을 따르나요?)
• 자동화된 테스트 실행 (모든 테스트가 통과하나요?)

개인적으로, 유닛, 통합, 아마도 엔드투엔드 테스트 없이 AI가 생성한 코드를 신뢰하는 것을 상상할 수 없어요. 좋든 나쁘든, AI 에이전트가 타겟팅된 프롬프트 없이 좋은 테스트를 작성하는 데는 아직 그다지 인상적이지 않다고 봐요. 기능 구축을 프롬프트할 때, 보고 싶은 테스트 유형도 프롬프트하고 예상대로 작성되었는지 확인해요.

그러면 테스트가 CI/CD의 일부로 실행되도록 설정되어야 해요. 물론, 시간이 지나면 테스트가 더 큰 코드베이스를 느리게 할 수 있어요. 그런 경우 엔지니어는 소매를 걷어붙이고 테스트 속도를 높이거나 중복 테스트가 있는지 확인해야 해요. 이것은 시니어 소프트웨어 엔지니어에게 기대되던 스킬셋인데, 앞으로는 AI로 많은 코드를 생성하는 모든 소프트웨어 엔지니어의 기본이 될 수 있어요.

더 “제품 마인드”가 되는 것도 더 많은 스타트업에서 기본이 될 수 있어요. AI가 더 많은 코드를 생성할수록, 무엇을 만들지 지정하는 것이 점점 더 중요해져요. 이미 민첩한 스타트업들은 자신만의 작업을 만들고, 미니 프로덕트 매니저와 소프트웨어 엔지니어의 블렌드인 “제품 엔지니어”를 고용하고 있어요.

제품 엔지니어를 고용하는 스타트업의 예로는 WorkOS—약 80명의 엔지니어에 단 1명의 PM이 있고 모두가 제품 엔지니어—와 처음 몇 년간 프로덕트 매니저가 없었던 Linear가 있어요. 오늘날 그 회사는 제품 엔지니어를 고용해요.

좋은 아키텍처 결정을 내리는 것이 훨씬 더 중요해져요. 더 빨리 더 많은 코드가 생성될수록, 소프트웨어의 구조를 지정하는 것이 중요해요. 모놀리스로 구축하고 있나요, 아니면 독립적이고 테스트 가능한 서비스로? 인터페이스와 경계가 무엇인지, 소프트웨어의 부분을 테스트 가능하게 만드는 방법, 엔드투엔드 테스트, 목, 페이크가 있나요? 목록은 계속돼요.

이것들은 모두 AI가 따르도록 지시해야 하는 결정이지, AI가 꿈꾸는 대로 구조를 정하게 하면 안 돼요. 그렇지 않으면 AI와 함께라도 유지보수하기 어려운 소프트웨어에 갇힐 위험이 있어요.

기술 부채를 추적하고 처리하는 데 더 많은 초점이 맞춰질 거예요. 코드가 많아질수록, 더 많은 기술 부채가 생길 거예요. 추적하고 처리할 것이 많아질 거예요. 경험 없는 엔지니어들은 모든 것을 알아차리지 못할 거예요. 이는 신뢰성 문제, 성능 저하, 더 많은 버그가 스며들고, 코드를 깨지 않고 수정하는 것이 더 어려워질 것을 의미해요.

신뢰성, 성능, 확장성, 보안을 위해 구축할 수 있는 것은 매우 가치 있는 스킬이 될 거예요. 누구나 작동하지 않을 때까지 대충 작동하는 소프트웨어를 생성할 수 있을 때, 항상 예상대로 작동하는 품질 높은 작업을 생산하는 엔지니어에 대한 수요가 더 많아질 거예요.

AI에게 보안적이고 성능 좋은 코드를 만들라고 프롬프트할 수 없어요: 원하는 것이 무엇인지 알고, 비기능적 요구사항을 검증하는 방법, 코드를 설계하고, 그에 따라 AI에게 프롬프트해야 해요. 세부 사항을 제대로 하기 위해 AI를 버리고 손으로 코드나 구성을 작성해야 할 수도 있어요. 기본적으로, 자신의 전문성을 언제 사용해야 하는지 아는 것이 중요해요.

단순한 “코더”가 아닌 탄탄한 소프트웨어 엔지니어가 되는 것이 이전보다 더 찾아질 거예요. 위의 모든 것을 요약하면, 소프트웨어 구축의 엔지니어링 부분이 훨씬 더 중요해져요. 우리는 훨씬 더 많은 코드를 생성할 것이고, 그것이 잘 작동하려면 엔지니어링 접근 방식이 건전하고 피드백 루프가 빡빡해야 해요.

작년에 바이브 코딩이 비기술인들 사이에 빠르게 퍼졌고, 그들 중 많은 사람들이 슈퍼 파워드 AI가 코드를 생성해줬음에도 불구하고 실제로 작동하는 소프트웨어를 만들기가 어렵다는 것을 곧 발견했어요.

원문 보기

5. 불편한 것: 불편한 결과들

더 많은 코드 & 더 많은 리소스 사용 = 더 많은 문제? AI를 사용하는 엔지니어들은 더 많은 풀 리퀘스트와 더 많은 코드를 생성할 것이고, 이미 증거가 있어요. 아래는 Michael Novati의 2024년(적은 AI 사용) 대 2025년(훨씬 더 많은 AI 사용) GitHub 활동입니다. AI 사용으로 풀 리퀘스트가 두 배로 늘었어요.

원문 보기

Michael은 Meta에서 근무하는 동안 가장 생산적인 개발자였고, 회사의 “코딩 머신” 아키타입이 그의 이름을 따 만들어졌어요.

그는 속도를 늦추지 않았어요: 작년에 풀타임 스타트업 플랫폼의 일부로 월 400-600개 커밋(하루 15-25개!)의 속도로 1,500개 이상의 새 기능과 800개 이상의 버그 수정을 커밋했어요.

당연히, 더 많은 코드는 버그, 보안 문제, 기타 문제에 대한 더 많은 기회를 의미해요. 또한 개발자와 팀이 점점 더 복잡한 서비스를 만들고, 더 많은 데이터를 저장하고, 더 많은 컴퓨팅을 사용하는 등으로 인해 더 많은 리소스 사용을 의미할 수도 있어요.

더 조잡한 코드. AI를 사용해 더 많은 코드를 생성하는 대부분의 팀에서 품질 기준이 올라가지 않을 것이라고 예측할 수 있어요—적어도 처음에는. 엔지니어들이 더 많고 더 큰 풀 리퀘스트를 더 적고 더 작은 것과 같은 표준으로 리뷰하는 것은 비현실적이에요.

초기 데이터는 프로덕션에 푸시된 코드가 더 낮은 품질임을 보여줘요: Cortex 2026 벤치마크 보고서는 50명 이상의 엔지니어링 리더를 조사했고, 변경 실패율(아웃에이지나 롤백을 유발하는 배포의 비율)이 30% 증가했음을 발견했어요.

약한 소프트웨어 엔지니어링 관행이 더 빨리 문제가 돼요. 자동화된 테스트 문화가 없거나, 코딩 가이드라인을 따르지 않거나, 관찰 가능성이 부족한 팀은 더 많은 회귀가 프로덕션에 배포되고, 아마도 더 많은 아웃에이지도 볼 거예요. 배포 속도가 빨라지면 나쁜 것들이 더 자주, 더 빠르게 프로덕션에 도달할 것이기 때문이에요.

소프트웨어 엔지니어가 아닌 “코더”들은 수요가 줄어들 수 있어요. 개발자가 복잡한 프로젝트를 분해하고, 테스트 가능성과 관찰 가능성을 위해 설계하고, 확장성과 신뢰성을 위해 구축하는 소프트웨어 엔지니어링 스킬을 가져오지 않는다면, 고용을 찾기가 더 어려울 수 있어요. 비기술적인 사람이 AI를 사용해 코드를 생성할 수 있을 때, 개발자는 단순히 코드를 작성하는 것 이상의 스킬이 필요해요. 분명히 AI가 이미 그것을 할 수 있기 때문이에요.

더 어려운 워라밸? 2026년에는 가상 샌드박스에서 원격으로 실행되는 AI 에이전트가 큰 것이 될 것 같아요. 이것은 개발자로서 작업 노트북 없이 웹 브라우저나 휴대폰에서 코드를 프롬프트하고, 검증하고, 배포할 수 있게 된다는 것을 의미해요. 이 변화는 Slack 같은 커뮤니케이션 도구가 모바일로 갔을 때와 비슷할 거예요: 개발자들은 이제 언제든지 연락받을 수 있고 인터넷 연결이 있는 어디서든 버그 수정을 할 수 있어요.

전 Datadog 엔지니어 Donovan Dicks가 언급한 것처럼, 이것은 문제가 될 수 있어요:

주니어들이 빠르게 시니어가 되어야 할 압박? AI로 대부분의 코드를 생성하는 소프트웨어 엔지니어에 대한 새로운 기대는 다음과 같아요:

• 작업을 더 작은 조각으로 잘 분해한다
• 스택 전체에서 작업한다: 백엔드부터 프론트엔드, 심지어 모바일까지
• 제품 마인드가 있다: 고객과 대화하고, 요청받지 않아도 버그를 고치고, 제품 제안을 가져온다
• 아키텍처 결정을 일찍 생각하고, 소프트웨어 구조화에서 실용적인 선택을 한다
• AI 출력을 검증하는 데 능숙하다
• 자동화된 테스트 & 관찰 가능성에 실무적이다
• 기술 부채를 따라잡는다

이것들은 탑티어 회사의 시니어나 스태프 레벨 엔지니어의 기본이었고, 이제 신입 엔지니어의 기본 기대가 될 거예요. 그러나 AI 이전에는, 신입 엔지니어들이 몇 년간 많은 코드를 작성하고, 더 경험 많은 개발자들과 일하며 배우면서 이 스킬들을 익혔어요.

이 변화가 신입들을 더 빨리 “성숙”하게 밀어붙일까요: (AI가 잘하는) “코딩” 부분을 건너뛰고 바로 소프트웨어의 엔지니어링 부분으로 점프? 그리고 그렇다면, 이것이 반드시 나쁜 건가요? 제 경험상, 신입들은 매우 유능하고 열심히 배우는 사람들이에요. 그래서 많은 사람들이 더 오래 근무한 개발자들의 전유물이던 역할을 맡는 데서 성공할 것이라고 예상해요.

신입 채용에 컴퓨터 과학 교육이 점점 더 필요? 신입을 채용하려는 채용 매니저라면, “시니어 레벨” 개념을 이해하는 사람이 필요할 거예요. 0년의 산업 경험으로 들어와서 소프트웨어 아키텍처 패턴, 자동화된 테스트, 기술 부채의 개념과 중요성에 대해 알아야 해요. 아, 그리고 아마도 팀의 일원으로 프로젝트를 구축하는 데 AI 도구를 사용한 경험이 있어야 해요. 다 엄청 어려운 요구 같아요.

하지만 알고 보니, 일부 대학 프로그램은 이미 이것을 제공해요. 3-5년에 걸쳐 이론과 실습을 가르치고 그룹 프로젝트를 조직해요. 한편 Harvard 같은 선도적인 곳은 LLM 관련 과정을 제공해요. 다른 대학들도 곧 따라잡을 거예요.

코드 작성이 덜 가치 있지만 소프트웨어 엔지니어링의 다른 모든 부분이 더 가치 있는 세계에서, 소프트웨어 엔지니어링과 컴퓨터 과학에 초점을 맞춘 학문적 교육이 업계 진입을 위한 협상 불가능한 장벽이 될 수 있어요. 대학은 또한 “스팸 필터” 역할도 해요: AI 지원서가 직접 채용 프로세스를 막히게 할 때, 지역 대학과 직접 파트너십을 맺으면 고용주가 후보자가 진짜인지에 대해 더 확신을 가질 수 있어요.

누군가가 책임져야 하는 코드와 소프트웨어의 대폭발. 위에서 다룬 것처럼, 우리는 거의 확실히 더 많은 코드 생성, 더 많은 소프트웨어 배포, 훨씬 더 많은 유지보수를 볼 거예요! 이것은 모두 클라우드 비즈니스 같은 인프라 제공업체, 인프라 도구, 소프트웨어의 정확성을 검증하는 도구에 확실한 혜택이 될 거예요.

그리고 모든 프로덕션 소프트웨어에서, 일이 잘못됐을 때 어딘가에서 책임을 져야 해요. 이것이 비기술적인 사람이 될 것이라고 기대하지 않아요. 오히려 이 AI 도구가 생성한 소프트웨어를 이해하고 유지보수할 수 있는 전문 소프트웨어 엔지니어, 그리고 프롬프트에 기반해 프로덕션에 배포된 코드에 책임을 질 스킬과 지식을 가진 사람이어야 해요.

6. 제품 관리 vs 소프트웨어 엔지니어링: 합병인가 분리인가?

저는 여러 프로덕트 매니저들이 이 변화에 꽤 흥분하는 것을 봤어요. 사양에 맞는 코드를 생성하는 AI가 프로덕트 매니저들이 소프트웨어 엔지니어 없이 소프트웨어를 만들 수 있다는 것을 의미할 수 있기 때문이에요. 하지만 실제로는 그렇게 되지 않을 것이라고 생각해요: 대신, 소프트웨어 엔지니어링과 제품 관리가 이전보다 훨씬 더 겹칠 수 있어요:

• 소프트웨어 엔지니어들이 훨씬 더 제품 마인드가 되고 고객과 더 가까이 있게 돼요. 예를 들어, 고객이 보고한 버그를 프로덕트 매니저의 분류나 입력 없이 빠르게 고칠 수 있어요
• 프로덕트 매니저들이 훨씬 더 실무적이 되어 고객에게 보여줄 프로토타입을 만들고, 아마도 엔지니어링 입력 없이, 가끔은 엔지니어가 머지할 버그 수정을 제출할 수도 있어요

저는 또한 엔지니어링 팀이 과거의 더 형식적인 핸드오프—프로덕트 매니저가 새 기능 구축을 위해 엔지니어링 팀에 제품 요구사항 문서(PRD)를 공유하는 것 같은—와 대조적으로 더 작고 효율적이 될 것으로 예상해요.

Linear 공동 창업자 Karri Saarinen은 이 변화를 코드 작성—예전에는 오래 걸렸던—이라는 “중간 소프트웨어 작업”의 소멸로 표현했어요:

한 가지 확실한 것은, 더 유능한 AI 코딩 도구와 함께 소프트웨어 엔지니어링이 진화하면, 제품 관리도 진화할 거라는 거예요.

결론

AI가 많은 팀에서 코드의 90% 이상을 작성할 것이라는 이 글 상단의 주장에 반박하는 것은 공정해요. 실제로, 저는 개발자들이 일반적으로 매우 적은 코드를 작성하고, 복잡성이 그것 주변의 모든 것에 있었던 대형 테크 조직에서 일한 적이 있어요! 그런 환경에서는 AI가 많이 도움이 되거나 큰 영향을 미칠 가능성이 낮아요.

제 자신의 “아하! 순간”도 좋은 엔지니어링 관행(모든 것에 대한 테스트)을 가진 간단한 코드베이스에서, 그리고 꽤 위험도가 낮고 실험하기 쉬운 제품에서 작업할 때 왔어요.

그래도, 최신 AI 도구들은 “내가 직접 작성했을 것만큼 좋은 코드”라는 제 품질 기준을 통과했고, 이것은 큰 일이에요!

초기 단계 스타트업들이 프롬프트를 통해 AI에게 모든 코드를 작성하도록 맡기는 것을 예상할 수 있어요. 적어도 제품-시장 적합성을 찾을 때까지. 이 글은 이 접근 방식이 퍼지면 어떤 일이 일어나는지, 자동완성이 없는 텍스트 에디터에서 코드를 작성하는 것이 비현실적이 된 것처럼 IDE에서 코드를 타이핑하는 것이 시간과 노력 낭비가 될 때 무슨 일이 일어나는지 물어봤어요.

좋은 소식은 팀이 코드 생성에 AI에 더 의존할수록 소프트웨어 엔지니어링 기본이 더 중요해져야 한다는 거예요. 더 많은 코드는 더 일찍 잡히고 체계적으로 처리되어야 하는 더 많은 문제로 이어져요. 이것이 좋은 소프트웨어 엔지니어링이 하는 것이고, 항상 그래왔어요.

AI가 사람들에게 검증(결국 AI를 진정으로 신뢰할 수 없으니까), 관찰 가능성(그것이 프로덕션에서 실제로 작동하는지 확인), 아키텍처(더 빨리 더 많은 코드를 생성할 것이고, 정리되어야 해요), 그리고 제약(더 빨리 배포하면 리소스 사용, 성능, 신뢰성 등에서 더 빨리 제약에 부딪혀요)에 대해 생각하도록 밀어붙이는 것을 긍정적으로 봐요.

나쁜 소식은 변화가 아마 빠를 거라는 거예요. Claude Code의 아이디어가 Boris Cherny의 머리에서 태어난 지 겨우 1년이 됐는데, 벌써 OpenCode, Codex, Factory, Amp, Cursor, 더 유능한 에이전트 같은 비슷한 도구들이 소프트웨어 작성 방식을 바꾸고 있어요. 변화는 항상 테크에서 일하는 것의 일부였지만, 이렇게 빠르거나 전체 업계에서 동시에 일어나는 것을 기억할 수 없어요!

슬픔도 있어요. AI가 앞으로 프로덕션에 배포하는 내 코드의 대부분을 작성할 가능성이 높다는 것을 받아들이고 있어요. 이미 더 빠르게 하고, 제가 타이핑했을 것과 비슷한 결과물을 내놓아요. 제가 덜 익숙한 언어/프레임워크에서는, 저보다 더 잘해요.

뭔가 가치 있는 것을 갑자기 빼앗기는 느낌이에요. 코딩을 잘하기까지, 작동하는 코드를 작성하는 방법을 배우기까지, 복잡한 코드를 읽고 이해하기까지, 그리고 코드가 예상대로 작동하지 않을 때 디버그하고 고치기까지 많은 노력이 들었어요. 대학에서 첫 “진짜” 프로그래밍 수업(C 배우기)이 얼마나 어려웠는지, 복잡한 코드베이스가 있는 첫 직장에서 얼마나 헤맸는지, 그리고 다른 개발자들, 책, 블로그로부터 배우면서 기예를 더 잘하기까지 몇 년의 연습이 걸렸는지 여전히 기억해요. 꽤 잘하게 되면, 작동하는 코드를 작성해서 검증하기 쉬운 가치 있는 무언가를 갖게 돼요!

소프트웨어를 만드는 제 최고의 추억 중 일부는 코딩에 관한 것이에요. “몰입” 상태에서 여러 아이디어를 균형 잡으면서 타이핑하고, 존에 있다가, 코드를 컴파일하고 실행하면서 “예!” 기대대로 작동하는 것을 보는 것!

사실 복잡한 코드를 작성하는 데 필요한 집중력 때문에 애증의 관계였어요. 그리고 시간 추정이 일으킨 모든 갈등: 어려운 문제에 몰입해서 작업할 때 시간이 다르게 흘러요.

이제 그 모든 것이 역사가 될 것 같아요.

복잡한 코드를 작성하는 것이 어렵다는 사실에서 여전히 같은 만족감을 얻을 수 있을지 궁금해요? 네, AI는 편리하지만, 상실도 있어요.

아니면 AI 에이전트와 함께, “존에 있는 것”이 더 복잡한 코드가 작성되도록 지시하면서 더 높은 수준의 문제에 대해 생각하는 것으로 바뀔까요?

어쨌든, 지각변동 같은 변화도 새로운 기회 때문에 흥미로워요. 진행 중인 것을 알면서 큰 변화를 경험한 적이 없어요. 이번에는 2026년에 제 코딩 방식이 급격히 바뀔 것이 확실하고, 많은 연쇄 효과가 있을 거예요.

변화는 개선된 경력 기회와 성공에 대한 새로운 경로를 만들 수 있고, 많은 흥분과 두려움도 가져와요. 저는 5년 후에 소프트웨어 전문가에 대한 수요가 오늘보다 더 높을 것이라고 생각해요. 부분적으로는 AI가 만들어내는 소프트웨어 양의 폭발 덕분이에요. 이 새롭고 더 유능한 도구와 함께, 우리는 이 미래에서 세계적 수준의 소프트웨어 엔지니어링이 무엇을 의미할지 알아가고 있어요.

• • •