AI가 대부분의 코드를 생성하는 시대에 소프트웨어 엔지니어링의 역할, 기회, 위험, 그리고 제품 관리와의 관계가 어떻게 바뀔지 살펴봅니다.
이 글은 원래 유료 글이었습니다. 2026년 9월 23일 DHH가 Rails World 기조연설에서 37Signals가 “연필을 내려놓고” 모든 코드를 생성한다고 밝히며 큰 화제를 일으킨 뒤, 2026년 9월 24일 유료 장벽을 없앴습니다. 1월에는 이것이 업계 전반에서 예상보다 빠르게 일어날 것임을 확인했습니다. 좋은 소식은 코드를 손으로 작성하지 않더라도 소프트웨어 엔지니어링은 여전히 건재하다는 점입니다.
The Pragmatic Engineer를 구독하세요. 이런 글을 받은편지함으로 받아 보고, 업계가 향하는 방향을 널리 논의되기 수개월 전부터 계속 파악할 수 있습니다.
이번 겨울 휴가는 개발자들이 일상 업무에서 한발 물러나 사이드 프로젝트를 만져볼 기회였습니다. 여기에는 AI 에이전트로 어설프게 시작했거나 미완성인 아이디어를 보강하는 일도 포함됩니다. 적어도 저는 그랬습니다. 2025년 동안 만들려 했지만 하지 못했던 몇 가지 기능을 작업했습니다. 더 큰 회사를 위한 셀프서비스 그룹 구독, 그리고 The Pragmatic Engineer를 위한 제가 직접 만든 관리 패널과 관련된 기능들이었습니다.
뜻밖에도 Opus 4.5와 GPT 5.2 같은 LLM은 제가 맡긴 중간 규모 작업을 훌륭하게 해냈습니다. LLM에 프롬프트를 주고, 결과물을 검토하고, 테스트가 통과하는지 확인하고(제가 새 테스트도 작성하라고 프롬프트한 뒤 그것도 통과하는지 확인했습니다!), 마지막 조정을 위해 조금 더 프롬프트하는 것만으로 수백 줄의 코드를 프로덕션에 배포하게 되었습니다.
마법 같은 느낌을 더한 것은, 그다음에는 휴대폰으로 프로덕션 소프트웨어를 만들 수 있었다는 점입니다. GitHub에 연결해 Claude Code for Web을 설정했고, 이를 통해 Claude 모바일 앱에서 제 코드를 변경하고 테스트를 추가·실행하라고 지시할 수 있었습니다. Claude는 당연히 테스트를 실행하는 GitHub 액션을 트리거하는 PR을 만들었고(Claude가 실행할 수 없는 테스트를 실행했습니다), 저는 이동 중에 모바일 기기만으로 새 기능이 담긴 PR을 검토하고 병합했습니다. 물론 위험도가 낮은 작업이었고 모든 비즈니스 로직은 자동화 테스트로 커버되어 있었지만, 휴대폰에서 코드를 “만들어” 프로덕션에 푸시하는 짜릿함을 이전에는 느껴본 적이 없었습니다.
많은 사람이 공유한 이 경험은 소프트웨어 엔지니어링 도구에 단계적 변화가 진행 중임을 시사합니다. 이 글은 이 매체의 2026년 첫 글로서, 우리가 어디에 와 있는지, 그리고 AI가 코드의 대부분을 작성하는 거대한 변화가 개발자들에게 무엇을 의미할지 살펴봅니다.
오늘 다룰 내용은 다음과 같습니다.
**최신 모델이 “아하” 순간을 만듭니다.**AI 공급업체에서 일하는 개발자들뿐 아니라 독립 소프트웨어 엔지니어들도 훨씬 더 유능해진 모델을 알아차렸습니다.
**왜 지금일까요?**11월과 12월의 모델 출시, 즉 Opus 4.5, GPT-5.2, Gemini 3가 전환점이었던 것으로 보입니다.
**나쁜 점: 전문성의 가치 하락.**앞으로는 프로토타이핑, 여러 언어에 능통함, 특정 스택 전문성이 훨씬 덜 가치 있어질 가능성이 큽니다.
좋은 점: 소프트웨어엔지니어**는 이전보다 더 가치 있어집니다.**테크 리드 특성의 수요가 늘고, 스타트업에서는 더 “제품 중심적”인 태도가 기본 요건이 되며, 단순한 “코더”가 아닌 탄탄한 소프트웨어 엔지니어가 더 많이 요구될 것입니다.
**추한 점: 불편한 결과.**생성되는 코드가 많아지면 문제가 더 늘고, 약한 소프트웨어 엔지니어링 관행은 더 빨리 고통을 초래하며, 개발자의 일과 삶의 균형도 더 어려워질 수 있습니다.
**제품 관리 대 소프트웨어 엔지니어링: 융합인가 분리인가?**제품 관리자는 이제 더 적은 엔지니어만으로 목표를 실현할 수 있을 정도로 쉽게 소프트웨어를 생성할 수 있지만, 소프트웨어 엔지니어 역시 제품 관리가 덜 필요해집니다. 두 직업은 이전보다 더 많이 겹치게 될 것입니다.
지난 몇 주간 일부 경력 많은 소프트웨어 엔지니어들은 AI 도구가 자신이 작성하는 코드 대부분을 생성하는 데 쓸 만큼 충분히 좋아졌다는 개인적 “아하” 순간을 공유했습니다.
Google의 수석 엔지니어 Jaana Dogan은 Claude Code가 얼마나 발전했는지에 매우 깊은 인상을 받았습니다.
“농담도 아니고 웃긴 일도 아닙니다. 우리는 작년부터 Google에서 분산 에이전트 오케스트레이터를 구축하려고 해왔습니다. 선택지는 여럿이고, 모두가 합의한 것도 아닙니다. Claude Code에 문제 설명을 줬더니, 우리가 지난해 만든 것을 한 시간 만에 생성했습니다.
완벽하지는 않고 계속 다듬고 있지만, 지금 우리는 이 지점에 와 있습니다. 코딩 에이전트에 회의적이라면 이미 여러분이 전문가인 도메인에서 써보세요. 결과물을 스스로 판단할 수 있는 복잡한 것을 처음부터 만들어 보세요.”
Amp의 소프트웨어 엔지니어 Thorsten Ball은 회고했습니다 (강조는 원문):
“15년 넘게 저는 코드를 작성하는 것을, 손으로 코드를 타이핑하는 것을, 그리고 Gary Bernhardt가 한때 ‘타이핑의 리듬’이라 부른 것을 좋아한다고 생각했습니다. 에디터 앞에 앉아 손가락으로 키보드를 딸깍거리며 치는 일이요.
이제는 잘 모르겠습니다.
2025년은 제가 프로그래밍과의 관계를 깊이 재고한 해였습니다. 이전에도 가끔 ‘Lisp 하는 사람이 될까?’라는 생각은 했습니다. 하지만 ‘나는 코드를 타이핑하는 것 자체를 좋아하기는 하는가?’라는 질문은 아니었습니다.
한 해 동안 제가 배운 것은 이제 손으로 코드를 타이핑하는 일이 저를 좌절시킨다는 점입니다.”
Vercel의 CTO Malte Ubl은 이렇게 말했습니다.
“정신없는 연휴 기간이었습니다. 대형 오픈소스 프로젝트 두 개를 만들었습니다. 하나는 아직 공개하지 않았고, 다른 하나는 AI 에이전트가 사용하도록 TypeScript로 만든 bash 환경의 완전한 구현입니다.
책을 쓰기 시작했습니다
다른 여러 가지도 고쳤습니다
지금은 Opus 4.5의 세계에 들어왔고, 이것들은 그것 없이는 절대로 가능하지 않았을 겁니다. 이제 Opus + Claude Code는 그냥 무엇을 하라고 말하면 해내는 시니어 소프트웨어 엔지니어처럼 행동합니다. 어려운 작업에는 여전히 감독이 필요하지만, 피드백에 매우 잘 반응하고 그다음에는 제대로 해냅니다.
너무 극적으로 말하고 싶지는 않지만, 여러분은 기존의 전제를 버려야 합니다. 소프트웨어 생산 비용은 0을 향해 가고 있습니다.”
오랜 독자는 Malte가 Google에서 보낸 11년을 포함한 소프트웨어 엔지니어링 20년 회고로 기억할 수 있습니다.
위 목소리들은 AI 개발 도구를 판매하는 회사에서 일하므로 이 주제에 이해관계가 있다고 주장할 수도 있습니다. 하지만 특정 공급업체에 끌릴 이유가 없는 엔지니어들도 비슷한 관찰을 했습니다.
Ruby on Rails의 창시자 David Heinemeier Hansson(DHH)은 개선된 모델 때문에 AI에 대한 자신의 입장이 바뀌었다고 설명했습니다.
“저질 결과물과 민망함 때문에 AI의 경이로움을 부정해서는 안 됩니다. 이는 컴퓨터를 인터넷에 연결한 뒤 우리가 컴퓨터로 해낸 일 중 가장 흥미로운 일입니다. 2025년을 AI에 비관적이거나 회의적으로 보냈다면, 2026년은 낙관과 호기심으로 시작해 보는 건 어떨까요?
불과 지난여름 저는 Lex Fridman과 AI가 어떤 코드도 직접 작성하게 하지 않는 것에 관해 이야기했습니다. 하지만 이 저항의 일부는 당시 모델이 충분히 좋지 않았다는 사실에 기반한 것이었음이 밝혀졌습니다! 처음부터 했다면 걸렸을 시간보다 AI가 작성한 것을 다시 작성하는 데 더 많은 시간을 썼습니다. 이제는 상황이 뒤집혔습니다.”
Tailwind CSS의 창시자 Adam Wathan은 회고했습니다.
“이제 정밀한 문법을 손으로 타이핑해야 할 때마다 [AI를 쓰는 대신] 너무 지루한 잡일처럼 느껴집니다. 놀랍고도 다행스럽게도 프로그래밍은 여전히 재미있고, 아마 [LLM과 함께라면] 더 재미있습니다.
지금 제 가장 큰 문제는 생산성 향상을 온전히 활용할 만큼 가치 있는 아이디어를 충분히 떠올리는 것입니다.”
널리 퍼진 “아하” 순간 하나는 OpenAI 공동창업자 Andrej Karpathy에게서 나왔습니다. Andrej는 수년간 OpenAI에 관여하지 않았고 AI 도구에 대한 평가와 비판을 솔직하게 하기로 유명합니다. 지난 10월 그는 Dwarkesh 팟캐스트에서 AI 코딩 도구가 과대평가되었다고 요약했습니다(강조는 원문).
“전반적으로 모델은 아직 거기에 도달하지 못했습니다. 업계가 너무 큰 도약을 하고 이것이 놀랍다고 가장하려는 것 같은데, 그렇지 않습니다.
형편없는 결과물입니다.
그들은 이를 직시하지 않고 있습니다. 어쩌면 자금을 조달하려는 것일 수도 있습니다. 무슨 일이 벌어지는지 잘 모르겠지만, 우리는 이 중간 단계에 있습니다. 모델은 놀랍습니다. 하지만 여전히 많은 작업이 필요합니다.
지금으로서는 자동완성이 제게 가장 잘 맞는 지점입니다. 다만 가끔, 특정 유형의 코드에는 LLM 에이전트를 사용합니다.”
두 달 뒤 이 견해는 완전히 수정되었습니다. Karpathy는 12월 26일 글을 올렸습니다 (강조는 원문):
“프로그래머로서 이만큼 뒤처진다고 느낀 적이 없습니다.
프로그래머가 기여하는 비트가 점점 희소해지면서 이 직업은 극적으로 재구성되고 있습니다. 지난 약 1년간 उपलब्ध해진 것들을 제대로 연결하기만 하면 10배 더 강력해질 수 있다는 느낌이 듭니다. 그 향상을 얻지 못하는 것은 명백히 역량의 문제처럼 느껴집니다.
에이전트, 하위 에이전트, 프롬프트, 컨텍스트, 메모리, 모드, 권한, 도구, 플러그인, 스킬, 훅, MCP, LSP, 슬래시 명령, 워크플로, IDE 통합을 비롯한 통상적인 계층에 더해 마스터해야 할 새로운 프로그래밍 가능한 추상화 계층이 생겼습니다. 또한 근본적으로 확률적이고, 오류를 내며, 이해하기 어렵고, 변화하는 존재들이 예전의 전통적 엔지니어링과 갑자기 뒤섞이는 상황에서 그 강점과 함정에 대한 포괄적 정신 모형을 세워야 합니다.
분명 강력한 외계 도구가 돌고 있는 셈입니다. 다만 설명서는 없고, 규모 9의 지진이 이 직업을 뒤흔드는 동안 모두가 그것을 쥐고 조작하는 법을 알아내야 합니다.
뒤처지지 않으려면 소매를 걷어붙이세요.”
Claude Code의 창시자 Boris Cherny는 응답하며, 지난달 자신이 커밋한 기여분 전부가 AI가 작성한 것이라고 공유했습니다.
“지난달은 엔지니어로서 IDE를 전혀 열지 않은 첫 달이었습니다. Opus 4.5가 모든 줄을 포함해 약 200개의 PR을 작성했습니다. 소프트웨어 엔지니어링은 급진적으로 변하고 있으며, 우리 같은 초기 도입자와 실무자에게도 가장 어려운 부분은 계속 기대치를 재조정하는 일입니다. 그리고 이것은 여전히 시작일 뿐입니다.”
앞서 Boris와 팀의 다른 창립 멤버들을 만나 Claude Code가 어떻게 만들어졌는지 심층적으로 다뤘습니다.
11월과 12월의 모델 출시는 AI가 코드 생성에 정말로 능숙해진 전환점처럼 보입니다.
Google의 Gemini 3(11월 17일): 지금까지 Google의 최고 코딩 모델
Anthropic의 Opus 4.5(11월 24일): Claude Code의 기본 모델이 된, 회사 최고 코딩 모델
OpenAI의 GPT-5.2(12월 11일): Codex를 구동하며, Opus를 탑재한 Claude Code만큼 인상적입니다
저는 Opus 4.5와 GPT-5.2를 모두 사용해 봤고 코딩에 매우 유능해 보였습니다. 이는 틈새 의견이 아닙니다. 약 20년 경력의 소프트웨어 엔지니어이자 PSPDFkit 창시자인 Peter Steinberger는 GPT-5.2에 대한 인상을 전했습니다.
“GPT 5/5.1에서 5.2로의 단계는 엄청났습니다. GPT 5.2가 나온 이제는 [에이전트가 막혔을 때 풀어 주기 위해 만든 ‘oracle’이라는 자체 CLI 에이전트]가 필요한 상황이 훨씬 적습니다. 연구에는 가끔 [GPT 5] Pro를 직접 쓰지만, 모델에게 ‘oracle에게 물어봐’라고 요청했던 경우는 하루 여러 번에서 주 몇 번으로 줄었습니다.
이것이 아쉽지는 않습니다. ‘oracle’을 만드는 일은 무척 재미있었고 브라우저 자동화, Windows에 관해 많이 배웠으며, 한동안 이 생각을 일축했지만 마침내 스킬도 살펴보게 됐습니다. 다만 이것은 5.2가 실제 코딩 작업 다수에서 얼마나 좋아졌는지를 보여 줍니다. 제가 던지는 거의 모든 것을 한 번에 해냅니다.”
제가 주목하는 LLM 분야 독립 소프트웨어 엔지니어링 전문가 Simon Willison도 같은 점을 지적했습니다.
“제게는 11월의 GPT-5.2와 Opus 4.5가 진정한 변곡점처럼 느껴집니다. 모델이 조금씩 나아지다가 보이지 않는 역량의 선을 넘는 순간 중 하나입니다. 갑자기 훨씬 더 어려운 코딩 문제들이 대거 열립니다.
Gemini 3 Pro도 그 그룹에 포함해야 할 가능성은 있지만, 다른 두 모델에서 보이는 것과 같은 수준의 놀라움 섞인 반응을 노련한 소프트웨어 엔지니어들로부터는 아직 그 모델에 대해 보지 못했습니다.”
사상 첫 The Pragmatic Engineer Podcast 에피소드는 적절하게도 Simon과 함께한 과장 없는 소프트웨어 엔지니어용 AI 도구였으며, Simon은 계속 그 정신에 부합하고 있습니다.
저를 포함해 많은 사람이 회의적으로 봤던 예측 하나는 Anthropic CEO Dario Amodei가 지난 3월 말한 내용입니다.
“AI가 코드의 90%를 작성하는 지점에 3개월에서 6개월 안에 도달할 것이라고 생각합니다. 그리고 12개월 뒤에는 AI가 본질적으로 모든 코드를 작성하는 세계에 있을지도 모릅니다.”
그러나 12월, Cherny가 Claude Code에 기여한 코드 100%가 AI 작성 코드였을 때 이는 현실이 되었습니다. 반대 입장에서 보면 Claude Code는 비공개 소스이므로 이 주장을 검증하기 어렵다고 지적할 수 있습니다. 물론 Claude Code 같은 것의 창시자는 높은 성능 역량을 보여 주고 싶을 것입니다. 하지만 저는 Boris와 이야기해 봤고 그를 신뢰합니다. 또한 Claude Code를 쓴 제 경험도 그의 경험과 일치합니다. 저는 결국 커밋하는 모든 코드를 Claude Code가 생성하게 합니다.
코드가 제가 원하는 방식이 아니면 LLM이 고치도록 더 프롬프트합니다. Boris처럼 저도 더는 코드를 손으로 작성하지 않습니다. 그럴 필요가 없고, 모델은 충분히 유능해 보이기 때문입니다. 여전히 할 수는 있지만, 단순히 모델에 맡기는 편이 더 빠릅니다.
잘 알고 IDE에서 탐색할 수 있는 코드조차, 에이전트에 프롬프트하면 제가 직접 하는 것만큼 빠르거나 더 빠르게 수정할 수 있음을 알게 되었습니다. 그럼에도 제가 작업을 _할 수 있다_는 것을 알고 싶어서 IDE로 가게 됩니다.
제 사용 사례에서는 TypeScript, Node/Express, React, Postgres를 기술로 쓸 때 AI가 제가 작성하는 코드의 90%를 생성할 수 있다는 주장이 충분히 사실처럼 느껴집니다. LLM이 훈련 데이터를 풍부하게 보유한 Go, Rust와 다른 인기 언어 및 프레임워크에서도 이 말이 점점 사실인 것으로 이해합니다. 흥미롭게도 Redis 창시자 Salvatore Sanfilippo가 관찰했듯이 LLM은 C도 꽤 잘하는 듯합니다.
이 글의 나머지 부분은 올해 AI 코딩 도구가 많은 개발자와 팀을 위해 코드의 약 90% 이상을 생성할 정도로 좋아질 것이라는 전제를 둡니다. 이 이정표에 가장 가까운 후보는 제품-시장 적합성을 찾는 스타트업, 즉 버릴 작업이 큰 문제가 아닌 곳, 그리고 새로 만들기 전에 기존 코드베이스를 가져오거나 이해할 필요가 없는 그린필드 개발 프로젝트일 것입니다.
물론 일부 코드베이스나 맥락에서는 도구가 충분히 잘 작동하지 않거나, 개발자가 의도적으로 이에 의존하지 않기로 선택해서 AI 코딩 도구에 완전히 의존하는 것이 말이 안 되는 경우도 많을 것입니다.
개발자가 타이핑해 작성하는 대신 프롬프트를 통해 AI가 거의 모든 코드를 생성하는 환경에서 소프트웨어 엔지니어링이라는 직업이 어떤 방향으로 갈 수 있을지 살펴볼 가치가 있습니다. 이는 직업에 영향을 미치는 거대한 변화일 텐데, 어떻게 될까요? 잠재적 부정적 측면부터 좋은 점, 나쁜 점, 추한 점을 따져보겠습니다.
과거에 가치 있던 일 중 일부는 대부분 AI에 위임될 것입니다.
프로토타이핑. Lovable과 Replit 같은 플랫폼은 비기술 직군이 소프트웨어를 만들 수 있는 방법으로 자신들을 명시적으로 광고합니다. 최근 광고에서 Replit은 전설적인 NBA 스타 Shaquille O’Neal과 협업했고, 그는 다른 것들과 함께 온라인 역사상 최고의 작업 멘트 5,000개를 얻는 앱을 바이브 코딩했습니다.
개발 경험 없이 바이브 코딩하는 Shaq. 앱들은 잘해야 프로토타입이었습니다. 출처: Replit
그렇지만 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 티켓을 받아 구현하는 일입니다. 오늘날에도 Cursor 팀에는 모든 Linear 티켓을 자동으로 Cursor에 전달해 한 번에 구현하는 자동화가 있습니다. 개발자는 이를 병합하거나 반복 개선할 수 있습니다. 더 많은 맥락이 전달되고 모델이 좋아질수록 결과물을 병합할 수 있을 가능성이 커집니다.
이는 특히 프로젝트 관리자나 제품 관리자가 오랫동안 개발자에게 질문 없이 구현하라고 상세 티켓을 작성해 온 위계적 직장에서 큰 변화가 될 것입니다!
리팩터링도 아마 AI에 더 많이 위임될 것입니다. 이미 리팩터링을 꽤 잘하고, 도구는 더 좋아질 가능성이 큽니다. 손으로 리팩터링하는 것보다 원하는 리팩터링 유형을 AI에 설명하는 편이 훨씬 빠를 것입니다. 물론 AI 이전 시대에도 현대적 IDE는 함수나 클래스 이름을 바꾸는 지루한 작업을 전체 코드베이스에 걸쳐 수행하고, 함수를 추출하는 등 강력한 리팩터링 역량을 제공했습니다.
물론 특히 대규모 리팩터링에서 AI가 일을 망칠 위험은 언제나 있습니다. 그렇기에 코드를 검증할 방법을 갖추는 일은 올해 더 중요해질 것이 분명합니다.
생성된 코드에 세심한 주의를 기울이는 일은, 어떤 경우에는? AI 프롬프트로 코드를 생성하면 장황한 코드가 나오거나 추상화를 사용하는 대신 기존 코드를 중복할 수 있습니다. 하지만 개념 증명을 만들거나 프로그램 효율성 같은 주제가 중요하지 않을 때처럼 이것이 완전히 허용되는 경우도 있습니다.
그린필드 소프트웨어를 만들고 있는 소프트웨어 엔지니어 Peter Steinberger는 AI가 생성한 코드를 읽지 않게 되었다고 말했습니다.
“요즘은 코드를 많이 읽지 않습니다. 스트림을 보고 가끔 핵심 부분을 살피지만, 솔직히 말해 대부분의 코드는 읽지 않습니다. 구성 요소가 어디에 있고, 사물이 어떻게 구조화되어 있으며, 전체 시스템이 어떻게 설계되었는지는 알고 있습니다. 보통 필요한 것은 그것뿐입니다.
요즘 중요한 결정은 언어/생태계와 의존성입니다. 제가 주로 쓰는 언어는 웹 작업에는 TypeScript, CLI에는 Go, macOS 기능을 사용해야 하거나 UI가 필요하면 Swift입니다. 불과 몇 달 전만 해도 Go는 조금도 생각하지 않았지만, 결국 만져 보니 에이전트가 Go를 정말 잘 작성한다는 것을 알았습니다. 단순한 타입 시스템 덕분에 린팅도 빠릅니다.”
그렇다 해도 성숙한 기존 소프트웨어를 확장하거나 보안 문제를 피해야 할 때 코드 읽기는 중요하게 남을 것입니다. 일반적으로 배포한 코드가 작동하지 않아 비즈니스에 피해를 준다면, 정확성을 위해 테스트와 검토를 모두 하고 싶을 것입니다.
개발자가 시간을 전부 코딩에 쓰지는 않는다는 것은 공공연한 사실입니다. 적어도 대부분의 직장에서는 그렇습니다. 3,500명의 응답자가 참여한 Atlassian의 State of Developer Experience 2025 보고서에 따르면 평균 개발자는 근무 주간의 16%를 코딩에 쓰고 나머지는 관리 업무에 씁니다. Microsoft, Skyscanner, Uber 같은 곳에서 보낸 시간을 떠올리면 이 비율은 맞는 듯합니다. 다른 사람을 돕고, 코드 검토를 하고, 설계와 버그를 논의하고, 계획·팀·전체 회의에 참석하고, 채용하고, 다른 이들과 연락하는 등 여러 일을 했습니다.
그러므로 AI가 2026년에 코드 전부를 작성하더라도 평균 근무 주간의 일부만 비워 줄 것입니다. 하지만 AI가 올바른 유형의 코드를 작성하려면 먼저 정확한 프롬프트가 필요합니다.
테크 리드 특성은 거의 확실히 더 수요가 많아질 것입니다. AI가 잘 정의된 어떤 티켓이든 구현할 수 있다면, AI가 코드를 정확히 만들게 하는 티켓은 누가 쓸까요? “완벽한” 티켓을 작성하려면 다음 둘 다를 개괄해야 합니다.
기능적 작업을 위한 사용자 요구사항: 기능이 어떻게 작동해야 하는지, 다양한 예외 상황에서 무엇이 일어나야 하는지
성능, 접근성, 신뢰성과 관련된 작업 같은 _비기능 요구사항_을 위한 기술 세부사항
비기술 직군도 사용자 대상 작업을 위한 상세 티켓은 작성할 수 있지만, 소프트웨어 엔지니어링 지식이 점점 중요해지는 비기능 요구사항을 표현할 가능성은 매우 낮습니다. 또한 사용자에게 공감하고 작업을 잘 정의된 과업으로 쪼갤 수 있는 실무 엔지니어도 이 새로운 세계에서 더 수요가 많아질 것으로 예상합니다. 공교롭게도 이는 이미 좋은 테크 리드가 가진 능력입니다. 유일한 변화는 주니어 엔지니어도 업무의 코딩 부분에서 더 빨리 발전하고 싶다면 이를 익혀야 한다는 점입니다.
테스트와 테스트 인프라를 잘하는 일은 더 중요해질 것입니다. 에이전트가 더 효과적이고 환각을 덜 일으키려면 자기 작업을 검증하는 피드백 루프가 필요합니다. 빠르게 실행할 수 있는 예로는 다음이 있습니다.
코드 컴파일하기(컴파일되는가?)
정적 분석 실행하기(정의된 규칙을 따르는가?)
자동화 테스트 실행하기(모든 테스트가 통과하는가?)
개인적으로는 단위, 통합, 그리고 어쩌면 엔드투엔드 테스트 없이 AI 생성 코드를 신뢰하는 것은 상상할 수 없습니다. 좋든 나쁘든, 저는 여전히 AI 에이전트가 목표를 명확히 한 프롬프트 없이는 좋은 테스트를 작성하는 데 그리 인상적이지 않다고 봅니다. 기능을 만들라고 프롬프트할 때도 보고 싶은 테스트 유형을 프롬프트하고, 기대한 대로 작성되었는지 확인합니다.
그런 다음 테스트는 CI/CD의 일부로 실행되도록 설정해야 합니다. 물론 시간이 지나면 테스트는 큰 코드베이스를 느리게 할 수 있습니다. 그 경우 엔지니어는 소매를 걷어붙이고 속도를 높이는 방법이나 중복 테스트가 있는지를 살펴야 합니다. 이는 과거에는 시니어 소프트웨어 엔지니어에게 기대하던 역량이었지만, 앞으로는 AI로 많은 코드를 생성하는 모든 소프트웨어 엔지니어의 기본 요건이 될 수 있습니다.
더 “제품 중심적”인 태도 역시 더 많은 스타트업에서 기본 요건이 될 수 있습니다. AI가 더 많은 코드를 생성할수록 무엇을 만들지 명시하는 일이 점점 중요해집니다. 이미 민첩한 스타트업은 스스로 할 일을 만들 수 있고 작은 제품 관리자와 소프트웨어 엔지니어의 혼합형인 “제품 엔지니어”를 채용하고 있습니다.
제품 엔지니어를 고용하는 스타트업의 예에는 엔지니어 약 80명당 PM이 한 명이고 모두가 제품 엔지니어인 WorkOS, 그리고 초창기 몇 년간 제품 관리자가 없었던 Linear이 있습니다. 오늘날 이 회사는 제품 엔지니어를 채용합니다.
좋은 아키텍처 결정을 내리는 일은 더욱 중요해집니다. 더 많은 코드가 더 빠르게 만들어지므로 소프트웨어 구조를 명시하는 것이 중요합니다. 소프트웨어를 모놀리스로 만들 것인가, 독립적이고 테스트 가능한 서비스로 만들 것인가? 인터페이스와 경계는 무엇이며, 소프트웨어 일부를 어떻게 테스트 가능하게 만들 것인가? 엔드투엔드 테스트, 목, 페이크는 있는가? 목록은 계속됩니다.
이 모든 것은 AI가 스스로 상상할 수 있는 아무 구조나 만들어 내게 두기보다는 AI가 따르도록 지시해야 할 결정입니다. 그렇지 않으면 AI가 있더라도 유지보수하기 어려운 소프트웨어에 갇힐 위험이 있습니다.
기술 부채를 추적하고 해결하는 일에 더 집중하게 될 것입니다. 코드가 많을수록 기술 부채도 많아지므로 추적하고 해결할 일이 많아질 것입니다. 경험이 부족한 엔지니어는 모든 것을 알아차리지 못해 신뢰성 문제, 성능 저하, 더 많은 버그가 스며들고, 무언가를 망가뜨리지 않고 코드를 수정하기도 더 어려워질 것입니다. 기술 부채 상환 가이드는 AI로 많은 코드를 생성할 때 더욱 적용됩니다!
신뢰성, 성능, 규모, 보안을 고려해 만들 수 있는 능력은 매우 귀한 역량이 될 것입니다. 누구나 어느 순간까지는 대충 작동하는 소프트웨어를 생성할 수 있을 때, 기대한 대로 항상 작동하는 양질의 작업물을 만드는 엔지니어의 수요가 더 커질 것입니다.
AI에 안전하고 성능 좋은 코드를 만들라고 프롬프트만 할 수는 없습니다. 무엇을 원하는지, 비기능 요구사항을 어떻게 검증할지 알아야 하며, 코드를 아키텍처로 구성하고 그에 맞춰 AI에 프롬프트해야 합니다. 세부사항을 제대로 맞추려면 AI를 버리고 직접 코드나 설정을 손으로 작성해야 할 수도 있습니다. 요컨대 자신의 전문성을 언제 써야 하는지 아는 것이 이득입니다.
단순한 “코더”가 아니라 탄탄한 소프트웨어 엔지니어인 사람은 이전보다 더 많이 찾게 될 것입니다. 위 내용을 요약하면, 소프트웨어를 만드는 데서 엔지니어링 부분이 훨씬 중요해집니다. 우리는 훨씬 더 많은 _코드_를 생성하게 될 것이고, 코드가 잘 작동하려면 엔지니어링 접근법이 건전하고 피드백 루프가 촘촘해야 합니다.
지난해 바이브 코딩은 비기술 직군 사이에 빠르게 퍼졌고, 많은 사람이 초강력 AI가 코드를 생성해 주었는데도 실제로 작동하는 소프트웨어를 만드는 일이 어렵다는 것을 곧 발견했습니다. 6개월 전 저는 이에 관한 밈을 만들었습니다.
코드를 빠르게 작성하는 일은 양질의 소프트웨어를 만드는 병목이 아닙니다
더 많은 코드와 더 많은 리소스 사용량 = 더 많은 문제? AI를 쓰는 엔지니어는 더 많은 PR과 코드를 생성할 것이며, 이미 증거가 있습니다. 아래는 Michael Novati의 2024년 GitHub 활동(적은 AI 사용)과 2025년 활동(훨씬 많은 AI 사용)의 비교입니다.
Michael은 Meta 재직 당시 가장 생산적인 개발자였고, 회사의 “Coding Machine” 원형은 그를 본떠 만들어졌습니다. 우리는 Michael과 팟캐스트 에피소드를 진행했습니다.
그는 이후에도 속도를 늦추지 않았습니다. 지난해 자신이 전일제로 일하는 스타트업 플랫폼의 일부로 1,500개가 넘는 새 기능과 800개 이상의 버그 수정을, 한 달 400~600회 커밋(하루 15~25회!) 속도로 커밋했습니다. 더 자세한 요약도 공유했습니다.
분명히 코드가 많아지면 버그, 보안 문제, 기타 문제의 기회도 늘어납니다. 개발자와 팀이 점점 더 복잡한 서비스를 만들고, 더 많은 데이터를 저장하고, 더 많은 컴퓨팅을 쓰는 등 리소스 사용량도 늘 수 있습니다.
더 엉성한 코드. AI로 더 많은 코드를 생성하는 대부분 팀에서 품질 기준은 적어도 처음에는 올라가지 않을 것이라 예상할 수 있습니다. 엔지니어가 점점 더 많고 큰 PR을, 더 적고 작던 PR에 적용하던 것과 같은 수준으로 검토하는 것은 비현실적입니다.
초기 데이터는 프로덕션에 푸시되는 코드의 품질이 낮음을 보여 줍니다. Cortex 2026 Benchmark Report는 50명 이상의 엔지니어링 리더를 조사했고, 변경 실패율(장애 또는 롤백을 일으키는 배포 비율)이 30% 증가했다고 밝혔습니다.
약한 소프트웨어 엔지니어링 관행은 더 빨리 고통을 일으킵니다. 자동화 테스트 문화가 없거나, 코딩 가이드라인을 따르지 않거나, 적절한 관측 가능성 체계가 없는 팀은 더 많은 회귀를 프로덕션에 배포하고, 장애도 더 많이 겪을 수 있습니다. 배포 속도가 빨라지고 나쁜 결과가 프로덕션에 더 자주, 더 빨리 도달하기 때문입니다.
소프트웨어 엔지니어가 아닌 “코더”의 수요는 줄어들 수 있습니다. 개발자가 복잡한 프로젝트를 분해하고, 테스트 가능성과 관측 가능성을 고려한 아키텍처를 만들며, 규모와 신뢰성을 고려해 구축하는 등의 소프트웨어 엔지니어링 역량을 제공하지 못한다면 고용을 찾기가 더 어려울 수 있습니다. 비기술 직군이 AI를 써서 코드를 생성할 수 있는 상황에서는, AI가 이미 코드를 작성할 수 있다는 것이 명백하므로 개발자에게 단순 코드 작성 이상을 넘어서는 역량이 필요합니다.
더 어려운 일과 삶의 균형? 2026년은 가상 샌드박스에서 원격으로 실행되는 AI 에이전트가 큰 일이 되는 해가 될 것 같습니다. 이는 개발자가 업무용 노트북 없이 웹 브라우저나 휴대폰에서 코드를 프롬프트하고, 검증하고, 배포할 수 있음을 의미합니다. 이는 Slack 같은 커뮤니케이션 도구가 모바일로 옮겨갔을 때와 비슷한 변화일 것입니다. 이제 개발자는 언제든 연락받을 수 있고 인터넷 연결만 있으면 어디서든 버그를 고칠 수 있습니다.
전 Datadog 엔지니어 Donovan Dicks가 지적했듯이, 이는 문제가 될 수 있습니다.
“모바일 경험 개선이 직원의 개인 생활과 직업상 책임 사이의 경계를 더 침식할 수 있다는 점이 걱정됩니다. 많은 사람은 이미 기기에 Slack, Teams 등을 설치하고 고용주가 24시간 연중무휴로 연락할 수 있게 하라는 압박에 시달립니다. 그러면서 근무 시간 외에 한 일에 대한 추가 보상은 전혀 받지 못합니다. AFK 상태에서도 엔지니어가 더 많은 일을 할 수 있게 만들면 고용주에게 더 많이 착취당할 위험도 커집니다.
미국의 연봉제 직원으로서 저는 심야 장애 해결, 통근 중 답한 메시지, 정상 근무 시간 밖에서 한 다른 업무에 대해 추가 보상을 받아 본 적이 없습니다. 특히 휴일에 직업적 책임이 개인 시간을 더 침범하는 것에 맞서는 몇 안 되는 방어 수단 중 하나가 AFK입니다. 모바일 코딩 워크플로가 실현 가능해지고 흔해지면 이 방어 수단은 사라질 수 있습니다.
도구의 발전은 흥미롭고 개인 코딩 프로젝트에서 실험하는 것은 즐기지만, 이를 제 직업적 워크플로에 도입하는 일에는 더 신중합니다. 이것이 업계에 어떤 영향을 미칠지 궁금합니다.”
주니어가 빠르게 시니어가 되도록 밀려날까? AI로 코드 대부분을 생성하는 소프트웨어 엔지니어에게 새로 기대되는 사항은 다음과 같습니다.
작업을 더 작은 조각으로 잘 분해하기
백엔드부터 프론트엔드, 심지어 모바일까지 스택 전반에서 일하기
제품 중심적으로 행동하기: 고객과 대화하고, 요청받지 않아도 버그를 고치며, 제품 제안을 제시하기
아키텍처 결정을 일찍 고민하고 소프트웨어 구조에 실용적 선택을 하기
AI 출력을 잘 검증하기
자동화 테스트와 관측 가능성을 직접 다루기
기술 부채를 관리하기
이들은 과거 최고 수준 회사에서 시니어 또는 스태프급 엔지니어의 기본 요건이었고, 이제는 신입 엔지니어의 기본 기대치가 될 것입니다. 그러나 AI 이전에 신입 엔지니어는 몇 년간 많은 코드를 작성하고, 더 경험 많은 개발자와 일하고 그들에게 배우며 이런 역량을 습득했습니다.
이 변화는 신입 졸업자가 더 빠르게 “성숙”하도록 만들까요? AI가 잘하는 “코딩” 부분을 건너뛰고 소프트웨어의 엔지니어링 부분으로 바로 뛰어들게 될까요? 그렇다면 반드시 나쁜 일일까요? 제 경험상 신입 졸업자는 매우 유능하고 배우려는 의지가 강하므로, 이전에는 더 오래 근무한 개발자의 영역이었던 역할을 맡으며 많은 사람이 잘해낼 것이라 봅니다.
신규 채용에 컴퓨터 과학 교육이 점점 더 필요해질까? 제가 신입 졸업자를 채용하려는 채용 관리자라면, “시니어급” 개념을 이해하는 사람이 필요할 것입니다. 업계 경력 0년으로 입사하면서 소프트웨어 아키텍처 패턴, 자동화 테스트, 기술 부채의 개념과 중요성을 알아야 합니다. 아, 팀의 일부로 프로젝트를 구축하며 AI 도구도 써봤어야 할 것입니다. 상당히 높은 요구처럼 보입니다.
하지만 일부 대학 프로그램은 이미 이를 제공합니다. 3~5년에 걸쳐 이론과 실습을 모두 가르치고 그룹 프로젝트를 조직합니다. 한편 Harvard 같은 선도 기관은 LLM 관련 강의를 제공합니다. 다른 대학도 곧 따라잡을 것입니다.
코드 작성의 가치는 낮아지고 _소프트웨어 엔지니어링_의 다른 모든 부분은 더 가치 있어지는 세계에서, 소프트웨어 엔지니어링과 컴퓨터 과학에 초점을 맞춘 학문 교육은 업계 진입에 협상 불가능한 장벽이 될 수 있습니다. 대학은 또한 “스팸 필터” 역할도 합니다. AI 지원서가 직접 채용 과정을 막아서는 상황에서, 지역 대학과 직접 협력하면 고용주는 후보자가 진짜라는 확신을 더 얻을 수 있습니다.
누군가는 책임져야 할 코드와 소프트웨어의 대규모 폭발. 위에서 다뤘듯이, 생성되는 코드는 거의 확실히 훨씬 많아지고, 배포되는 소프트웨어도 늘며, 해야 할 유지보수도 크게 늘어날 것입니다! 이는 클라우드 사업, 인프라 도구, 소프트웨어 정확성을 검증하는 도구 같은 인프라 제공업체에 분명 호재가 될 것입니다.
그리고 어떤 프로덕션 소프트웨어든 문제가 생겼을 때 책임은 어딘가에서 끝나야 합니다. 저는 이것이 비기술 직군일 것이라고 보지 않습니다. 오히려 이 AI 도구들이 생성한 소프트웨어를 이해하고 유지보수할 수 있으며, 자신의 프롬프트를 바탕으로 프로덕션에 배포된 코드에 책임질 역량과 지식을 지닌 전문 소프트웨어 엔지니어일 것입니다.
AI가 명세에 따라 코드를 생성하면 제품 관리자가 소프트웨어 엔지니어 없이 소프트웨어를 만들 수 있다는 뜻일 수 있어, 이 변화를 매우 반기는 제품 관리자를 몇 명 봤습니다. 하지만 실제로 일어날 일은 그것이 아니라고 생각합니다. 대신 소프트웨어 엔지니어링과 제품 관리는 이전보다 더 많이 겹칠 수 있습니다.
소프트웨어 엔지니어는 훨씬 더 제품 중심적으로 변하고 고객과 더 가까이 지냅니다. 예를 들어 제품 관리자의 분류나 입력 없이도 고객이 보고한 버그를 빠르게 고칠 수 있습니다.
제품 관리자는 훨씬 더 실무적으로 변해 엔지니어링 입력 없이도 고객에게 보여 줄 프로토타입을 만들고, 때로는 엔지니어가 병합할 버그 수정도 제출할 수 있습니다.
또한 제품 관리자가 새 기능을 만들기 시작할 엔지니어링 팀에 제품 요구사항 문서(PRD)를 전달하는 과거의 더 공식적인 핸드오프와 달리, 엔지니어링 팀은 더 작고 효율적이 될 것이라 예상합니다.
Linear 공동창업자 Karri Saarinen은 이 변화를 표현하며, 오랫동안 걸리던 코드 작성, 즉 “중간 소프트웨어 작업”이 사라진다고 말했습니다.
“순수 코딩 에이전트 워크플로는 이제 목표, 맥락, 작업에서 작동하는 코드를 만들어 낼 수 있습니다. 이들은 더 독립적으로 작동하며, 여러분이 코드를 덜 만지고 IDE에 덜 의존하게 합니다. IDE는 작성 도구라기보다 코드 뷰어가 됩니다.
이 시스템이 개선될수록 이 중간 부분은 더 얇아집니다. 의도를 구현으로 수동 번역하는 데 쓰는 시간이 줄어듭니다.
실제로 무엇을 만들어야 하는지는 여전히 중요한 질문입니다. (...)
이런 의미에서 [소프트웨어] 설계는 산출물이나 도구에 관한 것이 아닙니다. 아이디어, 탐색, 조사, 논의를 통해 의도의 명확성을 형성하고 다듬는 일입니다. 무엇이 중요한지, 어떤 제약이 적용되는지, 어떤 트레이드오프가 수용 가능한지를 결정하는 일입니다. 좋은 제품 작업은 무엇이 이 실행을 실제로 의미 있게 만들지에 관한 명확성을 찾는 일입니다.
이 시대에는 에이전트 작업을 지휘하고 관리하는 일이 기술이 됩니다.
코드를 작성하는 일은 해결책을 구성하는 것이라기보다 좋은 해결책이 나타날 조건을 설정하는 것에 가까워집니다.”
한 가지는 확실해 보입니다. 더 유능한 AI 코딩 도구와 함께 소프트웨어 엔지니어링이 진화하는 만큼 제품 관리도 진화할 것입니다.
이 글 상단의 많은 팀에서 AI가 코드의 90% 이상을 작성할 것이라는 주장에 반론을 제기하는 것은 타당합니다. 실제로 저는 개발자가 일반적으로 이미 코드를 아주 적게 작성하고, 복잡성은 그 주변의 모든 것을 헤쳐 나가는 데 있는 대규모 기술 조직에서 일했습니다! 그런 환경에서 AI가 크게 도움이 되거나 큰 영향을 미칠 가능성은 작습니다.
제 자신의 “아하 순간”조차 좋은 엔지니어링 관행(모든 것에 대한 테스트)이 있는 단순한 코드베이스, 위험도가 꽤 낮고 실험하기 쉬운 제품을 작업할 때 왔습니다.
그래도 최신 AI 도구는 “내가 작성했을 법한 만큼 좋은 코드”라는 제 품질 기준을 넘었고, 이는 큰일입니다!
초기 스타트업이 적어도 제품-시장 적합성에 도달할 때까지 프롬프트를 통해 AI에 모든 코드를 작성하게 맡기는 모습을 예상할 수 있습니다. 이 글은 이 접근법이 퍼져 IDE에서 코드를 타이핑하는 것이 자동완성 없는 텍스트 에디터에서 코드를 작성하는 것처럼 시간과 노력의 낭비가 되면, 혹은 될 때 무슨 일이 벌어질지를 물었습니다.
좋은 소식은 팀이 AI에 더 의존해 코드를 생성할수록 소프트웨어 엔지니어링 기초가 더 중요해져야 한다는 점입니다. 코드가 많아지면 더 많은 문제가 생기고, 이를 더 일찍 포착해 체계적으로 처리해야 합니다. 이것이 좋은 소프트웨어 엔지니어링의 핵심이며, 언제나 그래 왔습니다.
AI가 사람들에게 검증(AI를 진정으로 신뢰할 수는 없으므로), 관측 가능성(실제로 프로덕션에서 작동하는지 검증), 아키텍처(더 많은 코드를 더 빨리 생성하므로 정리되어야 함), 제약(더 빨리 배포하면 리소스 사용량, 성능, 신뢰성 등의 제약에 더 빨리 부딪힘)을 생각하게 할 것이라는 점을 긍정적으로 봅니다.
나쁜 소식은 변화가 아마 빠를 것이라는 점입니다. Boris Cherny의 머릿속에서 Claude Code라는 아이디어가 태어난 지 겨우 1년인데, 이미 OpenCode, Codex, Factory, Amp, Cursor 같은 유사 도구와 더 유능한 에이전트가 소프트웨어 작성 방식을 바꾸고 있습니다. 변화는 늘 기술 업계에서 일하는 일부였지만, 이토록 빠르거나 업계 전체에서 동시에 일어난 것은 기억나지 않습니다!
슬픔도 있습니다. 앞으로 AI가 제가 프로덕션에 배포하는 제 코드 대부분을 작성할 확률이 높다는 사실을 받아들이고 있습니다. 이미 더 빠르고, 제가 직접 타이핑했을 때와 비슷한 결과를 냅니다. 제가 덜 익숙한 언어/프레임워크에서는 저보다 더 잘합니다.
무언가 가치 있는 것이 갑자기 빼앗기는 느낌입니다. 코딩을 잘하게 되고 작동하는 코드를 작성하는 법, 복잡한 코드를 읽고 이해하는 법, 코드가 기대대로 작동하지 않을 때 디버깅하고 고치는 법을 배우는 데는 많은 노력이 들었습니다. 대학교에서 처음 들은 “진짜” 프로그래밍 수업(C 배우기)이 얼마나 벅찼는지, 복잡한 코드베이스가 있는 첫 직장에서 얼마나 막막했는지, 다른 개발자·책·블로그에서 배우며 기술을 더 잘 익히는 데 수년의 연습이 걸렸는지도 여전히 기억합니다. 꽤 잘하게 되면 작동하는 코드를 작성해 쉽게 검증할 수 있는, 가치 있는 능력을 갖게 됩니다!
소프트웨어를 만든 제 최고의 기억 중 일부는 코딩에 관한 것입니다. 몇 가지 아이디어의 균형을 맞추며 타이핑하고 완전히 몰입했던 일, 그 뒤 코드를 컴파일하고 실행하여 “그래!” 기대한 대로 작동하는 것을 보는 일 말입니다.
복잡한 코드를 작성하는 데 필요한 집중력의 양을 생각하면, 공정하게 말해 애증의 관계였습니다. 그리고 시간 추정이 일으킨 갈등도 있습니다. 몰입해서 어려운 문제를 풀 때는 시간이 다르게 흐릅니다.
이제 그 모든 것은 과거가 될 듯합니다.
복잡한 코드를 작성하는 일이 _어렵다_는 사실에서 여전히 같은 만족감을 얻을 수 있을지 궁금합니다. AI는 편리하지만, 상실도 있습니다.
아니면 AI 에이전트와 함께라면 “몰입”의 상태가, 더 복잡한 코드를 작성하도록 지시하면서 더 높은 수준의 문제를 생각하는 일로 옮겨갈까요?
어떤 경우든 지각 변동은 새로운 기회가 많기에 흥미롭기도 합니다. 큰 변화가 진행되는 동안 그것이 일어나고 있음을 알면서 경험해 본 적은 없습니다. 이번에는 2026년에 제 코딩 방식이 극적으로 바뀌고 연쇄 효과도 많을 것이라고 확신합니다.
변화는 더 나은 경력 기회를 만들고 성공으로 가는 새 길을 열 수 있으며, 많은 흥분과 불안을 함께 가져옵니다. AI가 만드는 소프트웨어 양의 폭발 덕분에 부분적으로는, 5년 뒤 소프트웨어 전문가 수요가 오늘보다 더 높을 것이라 생각합니다. 이 새롭고 더 유능한 도구와 함께 우리는 이 미래에서 세계적 수준의 소프트웨어 엔지니어링이 무엇을 의미할지 알아가고 있습니다.
더 유능한 AI 도구와 함께 우리 직업에 닥칠 수 있는 변화에 대해 어떻게 생각하시나요? 아래에 댓글을 남겨 주세요.
게시물 없음
