2026년 테크 산업의 현주소: AI 에이전트가 바꾼 것과 바꾸지 못한 것

메타데이터

• 원문 제목: The state of the tech industry in 2026 - LDX3 New York
• 채널: The Pragmatic Engineer
• 발표자: Gergely Orosz
• URL: https://www.youtube.com/watch?v=Ru99FGJ_yuE
• 영상 ID: Ru99FGJ_yuE
• 업로드 날짜: 2026-10-06
• 처리 기준일: 2026-10-07 (Asia/Seoul)
• 영상 길이: 29분 39초
• 자막: YouTube 자동 생성 영어 자막을 바탕으로 정리

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트가 소프트웨어를 만드는 방식과 산업의 속도를 근본적으로 바꾸고 있지만, 팀·기획·테스트·도메인 책임 같은 소프트웨어 조직의 핵심 단위는 사라지지 않았다.==

• 개발자는 직접 코드를 타이핑하기보다 여러 에이전트에게 작업을 맡기고 결과를 조율한다.
• 코드·마이그레이션·이슈·Pull Request의 양은 급증했지만 코드 리뷰의 품질과 소프트웨어 신뢰성은 속도를 따라가지 못한다.
• 앞으로 클라우드 에이전트, Evals, 배포·관측성·장애 대응 인프라가 표준이 되고 AI 긍정성과 깊은 도메인 지식이 채용의 핵심이 된다.

Gergely Orosz는 OpenAI, Anthropic, Cursor, Ramp, Uber, Linear 등을 직접 취재한 사례로 지난 12개월의 변화를 설명한다. AI는 엔지니어의 처리량을 높였지만 팀이 무엇을 만들지 결정하고 결과를 검증하며 운영 책임을 지는 문제를 자동으로 해결하지는 못했다. 코드 양의 폭증, 인프라 부족, 집중력 저하, 엔지니어링 리더의 소진이라는 새 비용도 만들었다.

1. 지난 12개월 동안 바뀐 것

1.1. 코드를 직접 작성하는 일이 예외가 됐다

1. AI 생성 코드가 기본값이 됐다
   1. 2026년 1월 Claude Opus 4.5와 GPT-5.2가 하네스와 결합되자 개발자들이 빠르게 작업 방식을 바꿨다.
   2. 손으로 편집하는 일은 남아 있지만 많은 스타트업에서 엔지니어가 프롬프트한 AI 생성 코드 비율이 100%에 가까워졌다.
   3. 개발자의 역할은 문법 입력에서 에이전트에 맥락·목표를 제공하고 결과를 검토·수정하는 일로 이동했다.
2. 하네스가 생산성을 결정한다
   1. 저장소·테스트·사내 데이터·배포 시스템과 연결하는 하네스가 모델 자체만큼 중요하다.
   2. 개발자는 한 편집기에서 작성하는 사람보다 여러 에이전트를 병렬 운영하는 조정자가 된다.

1.2. 여러 에이전트를 동시에 운용한다

1. Boris Cherny: 로컬에서 터미널 탭 다섯 개와 Claude Code 다섯 개를 실행하고 웹에서도 Claude 세션을 5~10개 사용한다.
2. Dima Zats: 과거의 마우스 하나·키보드 하나·화면 하나라는 물리적 한계가 사라졌다고 말하며 5~10개의 worktree와 에이전트를 동시에 운용한다.
3. Peter Mattis: Cockroach Labs의 공동 창업자 겸 CEO로서 5~10개의 에이전트 세션을 병렬 실행하고 인지 부하를 감수한다.

1.3. 전통적인 IDE가 에이전트 인터페이스로 대체된다

1. Antigravity와 Windsurf의 재브랜딩은 VS Code 포크 중심 흐름의 마지막 큰 사례에 가깝다.
2. OpenAI는 Codex를 위해 VS Code를 포크할지 고민했지만 IDE 없는 Codex가 적절한 시점의 승리였다고 판단했다.
3. JetBrains는 Air라는 에이전트형 하네스로 방향을 틀었고 Cursor도 4월에 에이전트 인터페이스로 전환했다.
4. Cursor 팀은 IDE를 엔터프라이즈 때문에 유지하는 레거시 제품으로 보며 성장하지 않고 축소된다고 설명했다.
5. Kent Beck은 인간 판단에 필요한 맥락이 사라진 것이 아니라 맥락 자체가 바뀌었기 때문에 IDE가 사라지는 것일 수 있다고 말했다.

1.4. 모든 규모의 회사가 자체 AI 하네스를 만든다

1. Ramp, Stripe, Uber, Block, Shopify, Google, Meta, Amazon, Dropbox, DoorDash, Grab, WorkOS, Monzo, HubSpot, Sierra, Harvey, Bowery 등이 자체 하네스를 구축했다.
2. 하네스는 Codex·Claude Code·OpenCode 위에 만들어지거나 사내 인증·데이터·배포 시스템과 연결된다.
3. 외부 도구에 연결하고 싶지 않은 사내 데이터 소스를 직접 연결할 수 있다는 점이 큰 이유다.
4. OpenAI에서는 Slack에서 Codex를 태그해 구현을 요청하고, Anthropic과 스타트업도 Claude나 자체 Slack 에이전트로 같은 흐름을 만든다. Linear도 Linear bot을 사용한다.

1.5. 에이전트형 소프트웨어 공장이 실제 운영된다

1. OpenAI 구조도의 점선은 에이전트가 입력을 받아 작업한 뒤 Codex로 보내 Pull Request를 만드는 흐름이다.
2. 중요하거나 영향 범위가 큰 변경은 사람이 검토한다.
3. 운영 환경을 감시하고 개선용 Pull Request를 올리는 에이전트 기반 perf factory도 있으며, 계속 반복하지만 아직 완전 자동화되지는 않았다.
4. 에이전트의 역할은 코드 작성에서 성능 개선·운영 모니터링·반복 수정으로 확장된다.

1.6. 대규모 마이그레이션이 수년에서 수개월 또는 수주로 줄었다

1. Anthropic은 Zig에서 Rust로 마이그레이션했고 Bun의 대부분을 작성한 엔지니어 한 명이 중심이었다.
2. OpenAI는 모든 인터페이스가 호출하는 API를 Python에서 Rust로 옮겨 프로덕션 부하 아래 4~5개월 만에 약 90%를 완료했다.
3. Airbnb의 Enzyme→React Testing Library 전환은 6주, Asana의 유사 전환은 약 2주였지만 Asana는 사전에 수년간 준비했다.
4. Uber는 수백만 줄의 JUnit 4→JUnit 5 전환을 4개월 만에 끝냈다.
5. 이들은 단순한 라이브러리 치환이 아니라 사실상 테스트 스위트 전체를 다시 작성한 작업이다.

1.7. 에이전트 이슈·Pull Request·스킬이 폭증했다

1. Linear에서 에이전트 또는 MCB가 만든 이슈가 사람의 이슈를 처음으로 추월했다.
2. 7~8월에는 사람 리뷰가 전혀 없는 에이전트 전용 Pull Request가 급증했다.
3. GitHub 에이전트 생성 Pull Request는 1월 770만 건에서 8월 거의 10배가 됐다.
4. Factory AI의 사용자 AI skills 사용률도 2월 30%대에서 80% 이상으로 올랐다.

1.8. AI 비용은 통제되기 시작했다

1. 5월에는 AI 비용 걱정이 널리 퍼졌고 Uber가 AI 연간 예산을 소진했다는 소식과 Claude Code 비용 상승이 문제였다.
2. 9월 무렵 대기업은 오픈 모델과 똑똑한 모델 라우팅으로 토큰당 비용을 약 50% 낮추면서 전체 비용을 평평하게 유지했다.

1.9. 엔지니어링 전문화가 빠르게 약해졌다

1. OpenAI ChatGPT 엔지니어링 책임자 Solomon Chachere는 전문화가 사라질 것이라 예상했지만 이렇게 빨리 진행될 줄은 몰랐다고 말했다.
2. 지난해에는 iOS와 Android 전문 엔지니어를 따로 찾았지만, 올해는 Codex와 LLM 덕분에 누구나 충분한 수준으로 할 수 있다고 본다.
3. 프런트엔드 엔지니어가 백엔드를 더 맡고 기존 백엔드 엔지니어도 더 넓은 범위를 처리한다.

1.10. 프로젝트는 한두 명이 맡고 팀과 주니어 채용은 줄었다

1. Claude 플랫폼 엔지니어링 책임자 Catherine Less는 엔지니어 한 명이 여러 에이전트를 이미 실행하므로 프로젝트 하나에 한두 명보다 많이 배치하기 어렵다고 말했다.
2. 에이전트끼리 서로의 작업을 침범하므로 사람을 더 추가할수록 조율 비용도 커진다.
3. 스타트업에서 한 사람이 프로젝트 전체를 맡는 사례가 흔해졌고, 팀과 중간 관리자의 규모가 줄었다.
4. 주니어·인턴 채용은 급격히 붕괴하지는 않았지만 계속 느려지고 있으며 agentic infrastructure는 독립된 엔지니어링 분야가 됐다.

2. AI가 바꿔도 사라지지 않은 것

2.1. 팀은 여전히 일의 기본 단위다

1. Anthropic에서는 팀이 소프트웨어 일부를 소유하고 온콜(on-call)을 맡으며 2-pizza team 형태가 유지된다.
2. OpenAI도 비슷한 구조를 가진다.
3. 휴가를 가고 서로 에너지를 만들며 높은 기준을 세우고 책임을 묻는 기능은 팀에 남아 있다.
4. ‘두 사람과 에이전트’는 일회성 프로젝트일 수 있지만 소유권과 운영 책임을 나누는 팀을 대체하지 못한다.

2.2. 복잡한 일을 위한 기획은 필요하다

1. Anthropic의 복잡한 인프라 제품은 예전 Stripe 시절과 비교해도 기획 방식이 크게 달라지지 않았다.
2. 구현이 빨라질수록 잘못된 제품을 빠르게 만드는 낭비를 피하는 기획이 중요하다.
3. 인프라 복잡성 정리, 팀 정렬, 고객 소통, 문제 정의와 우선순위 결정은 여전히 팀과 리더의 책임이다.

2.3. 테스트와 검증은 생산 코드만큼 중요하다

1. Anthropic의 Bun 팀에서 일한 Jared는 AI가 코드와 테스트를 거의 모두 작성하지만, AI 이전에도 운영 가능한 소프트웨어에서는 두 작업에 비슷한 시간을 썼다고 말했다.
2. 테스트는 생성된 코드가 제대로 동작한다고 믿게 하는 핵심 수단이다.
3. formal verification 같은 검증 계층도 인기를 얻으며, 코드가 많이 생성될수록 정확성·안전성·운영 적합성 검증이 중요해진다.

2.4. 비엔지니어는 아직 프로덕션 코드를 배포하지 않는다

1. 비엔지니어는 웹사이트를 만들고 Slack에서 버그를 태그하며 봇은 Pull Request를 만들 수 있다.
2. 그러나 이들은 Pull Request를 이해하지 못하는 경우도 있고 엔지니어링 팀에 버그를 알릴 뿐 직접 배포하지 않는다.
3. Linear, Cursor, OpenAI 등 Gergely가 확인한 회사 어디에서도 비엔지니어가 프로덕션 준비 코드를 직접 배포하지 않았다.

2.5. 오래된 설계 원칙이 AI 시대에 다시 쓰인다

1. Matt Pocock은 The Pragmatic Programmer의 tracer bullets를 발견한 뒤 오래된 책을 다시 읽고, A Philosophy of Software Design의 깊은 모듈(deep modules)과 얕은 모듈(shallow modules)을 학습했다.
2. 그는 이런 설계 용어를 AI에게 말하면 더 좋은 코드가 나온다는 사실을 발견했다.
3. 과거의 좋은 설계 원칙은 사람을 교육하는 데뿐 아니라 AI의 구현 방향을 안내하는 프롬프트로도 작동한다.

3. 산업에서 깨진 것

3.1. 코드 양과 코드 리뷰

1. GitHub 데이터에서 3년 기준 Pull Request·커밋·새 저장소가 약 5배 증가했고 최근 2개월 전체 Pull Request는 2배가 됐다.
2. 에이전트 전용 Pull Request는 1월 770만 건에서 8월 거의 10배가 됐다.
3. 익명의 엔지니어는 모두가 리뷰를 하는 척하는 ‘리뷰 극장’을 벌인다고 말했다.
4. 변경량이 너무 많으면 리뷰어는 거의 모든 변경에 “Looks good to me”라고 답하며, Gergely는 이를 zombie code review라고 부른다.
5. Ramp는 중요하지 않은 코드에는 리뷰를 요구하지 않고 엔지니어를 신뢰하는 방향으로 움직인다. 전체 변경의 80%를 실질적으로 검토하지 못하면 의무화만으로 품질을 보장할 수 없다.

3.2. 품질·신뢰성과 인프라 용량

1. Spotify와 Substack 등에서 사소한 오류와 불편한 동작(paper cuts)이 반복되며 에이전트가 내놓는 속도와 사람이 검증하는 속도 사이에 격차가 생겼다.
2. GPU는 AI 연구소·추론 회사·AI 스타트업에 부족하고, 메모리 가격도 오르며, 일반 클라우드 워크로드용 CPU도 부족해졌다.
3. Turbopuffer를 비롯한 Anthropic 관련 사례에서 서버와 CPU 백오더는 1~2주에서 최대 6개월로 늘었다.
4. 중간 규모 고객은 어떤 지역에서 CPU를 예약할 수 없고, 일부 회사는 12월 도착 용량을 미리 지불한다.

3.3. 집중력과 생산성

1. Linear의 Dima는 항상 응답을 기다리는 에이전트가 있어 컨텍스트 스위칭이 많아졌다고 말했다.
2. AI 도입 초기에는 동료가 하루 걸리는 일을 한두 시간에 끝내며 더 생산적이라고 느꼈지만, 이제 병렬 작업이 기준이 되어 AI 이전보다 일이 많아졌다.
3. 더 생산적인데 더 지치는 감각은 개인의 실패가 아니라 업계 기준선이 올라간 결과일 수 있다.

3.4. 엔지니어링 리더십의 경력 불안

1. Gergely는 커리어 브레이크를 택했거나 택할 엔지니어링 리더 약 20~25명을 인터뷰했다.
2. 창업자는 팀 절반 해고나 AI로 매출 두 배를 요구하고, 스타트업 손실·파산은 지분 가치와 경력 안정성을 무너뜨린다.
3. AI 워크플로를 채택하지 않는 회사에서 2~3년 더 2022년 방식으로 일하면 경력의 구멍이 생길 수 있다.
4. 팀 축소는 리더와 중간 관리자 수요를 줄였고 뉴욕·샌프란시스코·시애틀의 fractional CTO 일이 늘었다.
5. AI 스타트업은 비AI 스타트업보다 높은 총보상과 현금 보상을 주며 Anthropic은 상장 대기업의 CTO급 인재를 IC나 작은 팀의 리더로 영입한다.
6. 반대로 경험 많은 리더에게는 창업과 VC 자금 조달의 기회가 있고, 일부는 번아웃 때문에 휴식을 택한다.

4. 앞으로 전개될 것

4.1. 클라우드 에이전트와 원격 하네스

1. Ramp는 로컬보다 풍부한 자원, 클라우드에서 더 나은 프런트엔드 도구를 만들 수 있다는 점, 원격 개발 환경을 원했다는 점을 이유로 든다.
2. Linear의 Dima도 로컬 개발을 선호했지만 클라우드는 로컬 머신을 점유하지 않고 더 빠르고 쉬워 미래라고 판단했다.
3. CPU 부족은 장애물이지만 클라우드 중심 방향을 바꾸지는 못한다.

4.2. 코드를 전부 읽지 않는 개발

1. Charity Majors처럼 AI에 회의적인 인물도 코드를 읽고 이해하지 않고 배포하려면 무엇이 필요한지를 논의하며, 이는 일어날지보다 언제의 문제다.
2. Evals는 CI/CD에 포함되고 에이전트는 배포·observability·incident management에 참여한다.
3. 코드 읽기가 줄어들수록 평가 결과·테스트·운영 신호·책임 체계가 이해를 보완해야 한다.

4.3. 리팩터링 물결과 AI 성숙도

1. 리팩터링이 싸고 빨라지면 기술 부채를 갚고 언어·라이브러리·테스트 체계를 바꿀 유인이 커진다.
2. 한 Series A 스타트업은 채용에서 AI positivity를 확인하며 AI로 한계를 넓히려는 사람을 원한다.
3. Lara Hogan은 성숙한 조직이 사업 성과에서 거꾸로 작업해 핸드오프를 줄이고 학습을 늘리며 마찰을 제거하는 팀·회사 수준의 에이전트 시스템을 만든다고 설명했다.
4. 개인 자동화만으로는 부족하며 AI 인프라·평가·데이터 연결·권한 관리가 조직 기반이 된다.

4.4. 도메인 지식과 리더의 실무 복귀

1. Titus Winters는 성공에 지능(intelligence), 지혜(wisdom), 카리스마(charisma)가 필요하다고 말했다. AI가 ‘어떻게’를 값싸게 만들수록 무엇을 할지 판단하고 사람을 설득하는 능력이 중요해진다.
2. Will Larson은 약 50명 규모 조직에서 지난 15개월 동안 이전 5~10년보다 많은 코드를 프로덕션에 배포했다.
3. 리더는 직접 소프트웨어를 만들고 팀·회사의 마찰을 제거하는 AI 인프라를 구축해야 하며, 중요한 학습을 AI에 전부 외주화하면 안 된다.
4. 당분간 사람 관리의 비중은 줄어들 수 있지만 직접 만드는 실무력은 경력의 안전장치가 된다.
5. Cockroach Labs의 Peter Mattis는 약 600명 조직의 CTO로서 지난 1년 동안 이전 5년보다 더 많이 배웠고, AI가 더 빠르고 타협 없이 만들게 하지만 피곤하면서도 매우 흥미롭다고 말했다.

주요 발언 모음

“예전에는 마우스 하나, 키보드 하나, 화면 하나뿐이어서 물리적으로 한 가지 일보다 더 많이 할 수 없었습니다. 하지만 이제는 그 제한이 사라졌습니다.” — Dima Zats

“개별 프로젝트에는 한두 명보다 많은 엔지니어가 들어가기 어렵습니다. 각 엔지니어가 이미 여러 에이전트를 실행하고 있기 때문입니다.” — Catherine Less

“사람들은 모두 리뷰를 하는 극장을 벌이고 있지만, 변경량이 너무 많아지면 결국 저항이 가장 적은 길을 택합니다.” — 익명의 엔지니어

“지능은 어떻게 하는지 아는 것이고, 지혜는 무엇을 해야 하는지 아는 것이며, 카리스마는 다른 사람들이 그것을 하도록 설득하는 것입니다.” — Titus Winters

“AI가 코드를 쓰게 하지 않는 것이 문제가 아니라 코드를 읽고 이해하지 않고 배포하려면 무엇이 필요한지가 문제입니다. 그것은 일어날지의 문제가 아니라 언제의 문제입니다.” — Charity Majors와의 논의

“저는 무언가를 만드는 것을 좋아해서 소프트웨어 엔지니어가 됐습니다. 이제 AI 덕분에 더 빠르게 만들고 예전의 일부 타협을 하지 않아도 됩니다. 조금 지치지만 매우 흥미롭습니다.” — Peter Mattis

핵심 데이터 & 수치

• AI 생성 코드: 일부 스타트업에서 엔지니어가 프롬프트한 AI 생성 코드가 100%에 가까워졌다.
• 병렬 에이전트: Boris Cherny는 로컬 Claude Code 다섯 개와 웹 Claude 5~10개를 사용하며 Dima Zats와 Peter Mattis도 5~10개 세션을 병렬 운용한다.
• OpenAI Python→Rust: 프로덕션 부하 아래 4~5개월 만에 약 90%가 완료됐다.
• 마이그레이션: Airbnb 6주, Asana 약 2주, Uber의 수백만 줄 JUnit 4→5는 4개월이 걸렸다.
• GitHub 산출물: 3년 기준 Pull Request·커밋·새 저장소가 약 5배 증가했고 최근 2개월 전체 Pull Request는 2배가 됐다.
• 에이전트 Pull Request: 1월 770만 건에서 8월 거의 10배가 됐다.
• AI 스킬 사용: Factory AI 사용자 중 AI skills 사용률이 2월 30%대에서 80% 이상으로 올랐다.
• 토큰 비용: 오픈 모델과 스마트 라우팅으로 토큰당 비용을 약 50% 낮췄다.
• 서버 조달: CPU·서버 백오더가 1~2주에서 최대 6개월로 늘었고 일부 회사는 12월 도착분을 미리 지불한다.
• 리더 이탈: 커리어 브레이크를 고려하거나 택한 리더 약 20~25명이 인터뷰에 포함됐다.

결론 및 시사점

1. AI 코딩은 실험이 아니라 개발의 기본 운영체제가 됐으며 하네스와 내부 시스템이 경쟁 우위를 만든다.
2. 생성과 마이그레이션이 빨라질수록 기획, 테스트, 평가, 관측성, 배포 책임이 중요해진다.
3. 팀은 사라지지 않는다. 소프트웨어 소유권, 온콜, 우선순위, 품질 기준에는 팀이 필요하다.
4. 코드 리뷰 의무화만으로는 부족하며 자동 평가와 운영 신호를 품질 체계에 연결해야 한다.
5. 클라우드 에이전트와 에이전트형 CI/CD가 확산되므로 CPU·메모리·GPU와 비용 최적화가 기술 전략이 된다.
6. 리더는 직접 프로덕션에 배포하고 팀·회사 수준의 AI 인프라를 만들어야 한다.
7. 구현 방법이 흔해질수록 도메인 지식, 판단하는 지혜, 설득 능력이 차별화 요소가 된다.
8. 2026년의 테크 산업은 더 빠르고 생산적이지만 더 많은 조정·검증·집중력 비용도 감당해야 한다.

핵심 요약 (20줄)

1. 2026년 개발자는 코드를 직접 타이핑하기보다 AI 에이전트에게 작업을 맡기고 결과를 조율한다.

2. Claude Opus 4.5와 GPT-5.2가 하네스와 결합되면서 스타트업의 AI 생성 코드 비율이 100%에 가까워졌다.

3. Boris Cherny와 Dima Zats는 로컬과 웹에서 5~10개의 에이전트 세션을 병렬로 운용한다.

4. 전통적인 IDE는 엔터프라이즈용 레거시 제품이 되고 Cursor와 JetBrains는 에이전트 인터페이스로 이동한다.

5. Ramp, Stripe, Uber, Google, Meta 등은 사내 데이터와 개발 시스템을 연결한 자체 AI 하네스를 구축했다.

6. OpenAI의 에이전트형 소프트웨어 공장은 에이전트가 작업하고 Codex가 Pull Request를 만들며 사람이 중요한 변경을 검토한다.

7. Anthropic의 Zig-to-Rust와 OpenAI의 Python-to-Rust 전환은 과거 수년 걸릴 마이그레이션을 수개월로 줄였다.

8. Airbnb, Asana, Uber도 AI 지원으로 테스트 라이브러리와 수백만 줄 규모의 테스트 코드를 빠르게 전환했다.

9. 에이전트가 만든 Linear 이슈와 GitHub Pull Request는 사람이 만든 산출물을 추월하며 폭증하고 있다.

10. 대기업은 오픈 모델과 스마트 라우팅으로 토큰 비용을 약 50% 낮추고 전체 비용을 통제하기 시작했다.

11. AI는 iOS·Android·프런트엔드·백엔드 같은 엔지니어링 전문화의 경계를 빠르게 약화시켰다.

12. 프로젝트는 한두 명의 엔지니어와 여러 에이전트가 맡고 팀과 주니어 채용 규모는 줄어드는 추세다.

13. 팀은 여전히 소프트웨어 소유권과 온콜을 담당하는 기본 작업 단위이며 에이전트가 팀을 대체하지는 못한다.

14. 복잡한 인프라 프로젝트에서는 잘못된 것을 빠르게 만들지 않기 위한 기획과 고객·팀 정렬이 여전히 필요하다.

15. AI가 코드와 테스트를 모두 작성해도 검증과 신뢰성 확보에 필요한 시간의 비율은 줄지 않았다.

16. 코드 양의 폭증은 코드 리뷰를 형식적인 좀비 리뷰로 만들고 Spotify와 Substack의 품질 저하를 키웠다.

17. GPU·메모리뿐 아니라 CPU도 부족해져 서버 조달 기간이 1~2주에서 최대 6개월로 늘었다.

18. 병렬 에이전트가 생산성 기준을 높이면서 개발자는 더 많은 컨텍스트 스위칭과 업무량을 감당한다.

19. 앞으로 클라우드 에이전트와 AI 기반 CI/CD·배포·관측성·장애 대응 인프라가 표준이 된다.

20. AI 시대에는 직접 만드는 실무력과 깊은 도메인 지식, 판단하는 지혜, 사람을 설득하는 능력이 중요해진다.