스탠포드에서 빅테크로 조용히 퍼지는 개발자 생존법
미하일 에릭(Mihail Eric)의 ‘The Modern Software Developer’ 강의가 말하는 AI 시대 개발자의 진실
출처: EO 한국채널 — “스탠포드에서 빅테크로 조용히 퍼지는 개발자 생존법, 대부분 모릅니다 | 미하일 에릭” (2026. 3. 8.)
강사 소개: 미하일 에릭(Mihail Eric) — 샌프란시스코 AI 스타트업 AI 총괄, 스탠포드 대학교 CS146S ‘The Modern Software Developer’ 강의 담당 교수. 이전에는 Amazon Alexa 기술 리드로 조직 내 최초의 LLM을 개발했으며, YC(와이콤비네이터) 투자를 받은 AI 코딩 스타트업을 창업했고, 2022년 인수합병된 머신러닝 교육 스타트업 Confetti AI의 공동창업자이기도 하다. 스탠포드 AI 대학원을 졸업한 이 강의의 설계자는 “SDLC(소프트웨어 개발 생명주기) 전반에 걸쳐 AI를 다루는 최초의 대학 강의”를 만들었다고 소개한다.
들어가며: 낯선 언어를 말하는 개발자들이 등장하기 시작했습니다
소프트웨어 개발의 세계에 지금 조용하지만 거대한 지각변동이 일어나고 있다. 표면적으로는 단순히 AI 코딩 도구가 등장해 개발자들이 조금 더 빠르게 코드를 짜는 정도로 보일 수 있지만, 미하일 에릭이 진단하는 본질은 훨씬 더 깊은 곳에 있다. 그는 새로운 종류의 엔지니어 계층이 등장하고 있다고 말한다. 바로 ‘AI 네이티브 엔지니어(AI-native engineer)’다.
그에 따르면 AI는 단순한 도구가 아니라 새로운 언어다. 과거 세대의 개발자들이 C, Java, Python을 배워 그것으로 사고하고 소통했다면, 이제 등장하는 새로운 세대는 AI를 언어로 삼아 소통하고 구축한다. 이 새로운 언어에 원어민처럼 익숙한 개발자, 즉 AI 네이티브가 바로 지금 막 노동시장에 진입하기 시작한 주니어 개발자 세대가 될 것이라는 전망이다.
미하일 에릭이 스탠포드에서 강의를 개설하겠다고 발표하자마자 100명이 넘는 학생이 몰렸다는 사실은 이 주제가 얼마나 절박하게 받아들여지고 있는지를 단적으로 보여준다. 단순히 AI 툴 사용법을 배우는 것이 아니라, AI 시대에 개발자로서 ‘어떻게 살아남을 것인가’에 대한 답을 찾으려는 갈망이 그 열기의 정체다.
Lesson 1. 주니어 개발자들에게 지금 벌어지고 있는 일들
퍼펙트 스톰: 세 가지 힘이 동시에 충돌하다
미하일 에릭은 현재 주니어 개발자들이 처한 위기를 ‘퍼펙트 스톰(perfect storm)’이라 부른다. 서로 다른 방향에서 오는 세 가지 거대한 힘이 정확히 같은 시점에 충돌하며 역사상 유례없는 어려운 취업 환경을 만들어 냈다는 것이다.
첫 번째 힘은 팬데믹 이후의 과잉 고용과 그에 따른 대규모 정리해고다. 2021년 전후, 수많은 테크 기업들이 미래를 낙관하며 경쟁적으로 직원을 늘렸다. Meta, Google, Amazon 같은 빅테크 기업들은 2019년에서 2022년 사이 사실상 인력을 두 배 가까이 늘렸다. 그러나 이후 많은 기업들이 자신들이 지나치게 많은 인력을 채용했다는 사실을 깨달았고, 20~30%에 달하는 감원이 이어졌다. 이로 인해 숙련된 경력자들이 대거 취업 시장에 쏟아져 나왔고, 이들은 주니어 자리마저 경쟁하게 됐다.
두 번째 힘은 컴퓨터공학 전공자 수의 폭발적 증가다. 지난 10 ~ 15년 사이 CS 관련 전공 졸업생 수는 2~3배 이상 늘어났다. 미하일 에릭이 졸업하던 시절에 비해 매년 CS 졸업생 수가 두세 배 가까이 증가했다는 것이다. 수요는 줄어드는데 공급은 폭발적으로 늘어난 전형적인 공급 과잉의 상황이 펼쳐지고 있다.
세 번째 힘이 바로 AI의 대두다. AI 코딩 도구가 등장하면서 많은 고용주들이 더 이상 많은 인원을 채용할 필요를 느끼지 않게 됐다. 채용 담당자들의 셈법이 바뀐 것이다. ‘인원이 부족하면 더 뽑으면 된다’는 논리에서 ‘AI 네이티브 인재를 몇 명 뽑으면 그 인원으로 훨씬 더 많은 것을 해낼 수 있다’는 논리로 전환이 일어났다.
냉혹한 데이터가 말하는 현실
이 세 가지 힘의 충돌이 만들어 낸 결과는 통계로도 확연히 드러난다. 2024년 기준 주요 15개 빅테크 기업의 신입 채용은 전년 대비 25% 감소했으며, 2022년에서 2024년 사이 엔트리 레벨 포지션 채용 공고는 무려 60% 급감했다. 하버드 경제학자들이 62만 개의 미국 기업과 6,200만 명의 근로자를 대상으로 진행한 연구에서는, AI를 도입한 기업에서 AI 도입 후 6분기 내에 주니어 고용이 9~10% 감소한 반면, 시니어 고용은 거의 변화가 없었다는 결과가 나왔다. 미국 컴퓨터공학 전공 졸업생의 실업률은 7.5%로, 예체능 전공자의 실업률(7.4%)과 비슷한 수준까지 치솟았다. 컴퓨터공학 학위가 곧 취업을 보장하던 시대는 조용히 끝나가고 있다.
미하일 에릭이 인터뷰에서 언급한 UC 버클리 졸업생의 사례는 이 상황을 생생하게 보여준다. 그 학생은 무려 천 개의 회사에 지원했지만, 단 두 곳에서만 연락이 왔다고 했다. 면접을 거쳐 최종 합격한 것이 아니라, 그저 연락이 온 것이 두 곳이었다는 것이다. 이것이 오늘날 주니어 개발자들이 직면한 현실이다.
이 세대가 짊어진 이중의 과제
이 상황에서 지금 노동시장에 진입하는 주니어 개발자 세대는 역사상 처음으로 이중의 과제를 짊어지게 됐다. 알고리즘, 시스템 설계, 프로그래밍 언어에 대한 탄탄한 기초 역량은 여전히 필수다. 그러나 이제는 여기에 더해 ‘AI 네이티브’로서의 역량까지 갖추어야 생존할 수 있다. 미하일 에릭은 이것이 선택 사항이 아닌 생존을 위한 필수 조건이 되었다고 단언한다. 이 둘 중 하나라도 빠지면 이 시장에서 경쟁력을 갖추기 어렵다는 것이다.
Lesson 2. 상위 1% AI 네이티브들이 에이전트를 다루는 방법
AI 네이티브 엔지니어의 정체
미하일 에릭이 정의하는 AI 네이티브 엔지니어는 단순히 ChatGPT나 Cursor 같은 AI 도구를 잘 쓰는 사람이 아니다. 전통적 프로그래밍, 시스템 설계, 알고리즘적 사고라는 탄탄한 기반 위에 에이전틱 워크플로우(agentic workflows)를 능숙하게 활용할 수 있는 능력을 함께 갖춘 사람이다. 이 두 가지가 합쳐졌을 때 비로소 진정한 AI 네이티브 엔지니어가 된다.
그리고 그 역량의 정점에 있는 것이 바로 멀티 에이전트 오케스트레이션이다. 미하일 에릭은 이를 게임의 ‘라스트 보스(last boss)’에 비유한다. 여러 AI 에이전트를 동시에 능숙하게 다룰 수 있는 사람은 오늘날에도 상위 0.1~1%에 불과하다는 것이다.
에이전트는 ‘열의 넘치는 인턴’이다
미하일 에릭이 멀티 에이전트 워크플로우를 설명할 때 사용하는 가장 핵심적인 비유가 있다. 바로 “에이전트는 열의 넘치는 인턴들”이라는 것이다. 이 비유는 단순한 수사가 아니라 AI 에이전트의 특성을 정확하게 포착한다.
인턴들은 열심히 일한다. 빠르게 코드를 작성하고, 터미널에서 부지런히 작업을 처리한다. 하지만 가끔 막히기도 한다. 방향을 잃기도 하고, 지시가 불명확하면 잘못된 방향으로 엄청난 에너지를 쏟기도 한다. 따라서 이들을 제대로 활용하려면 관리자로서의 역량이 필요하다. 무엇을 해야 하는지 명확히 알고, 각자에게 맞는 작업을 배분하고, 중간에 점검하고, 막혔을 때 방향을 잡아주는 능력 말이다.
에이전트를 단계적으로 추가하라: ‘피스밀(piecemeal)’ 원칙
많은 사람들이 저지르는 실수 중 하나는 처음부터 여러 에이전트를 동시에 돌리는 것이다. 인터뷰에서 누군가 “Anthropic의 Boris는 10개의 에이전트를 동시에 운영한다고 했으니 나도 그렇게 해야겠다”는 식의 접근을 언급했는데, 미하일 에릭은 이것이 완전히 잘못된 출발점이라고 단언한다.
그가 제시하는 올바른 접근법은 ‘피스밀(piecemeal)’, 즉 조각별로 쌓아 올리는 방식이다. 먼저 에이전트 하나로 복잡한 소프트웨어를 구축하는 능력을 완전히 익혀야 한다. 하나의 에이전트 워크플로우를 충분히 숙달했다는 확신이 섰을 때, 비로소 두 번째 에이전트를 추가한다. 두 번째 에이전트가 잘 작동하고 자신이 그 흐름을 자신 있게 관리할 수 있다는 확신이 섰을 때, 세 번째를 추가한다. 이처럼 단계적으로 역량을 쌓아가는 것이 핵심이다.
또한 추가되는 에이전트에게는 반드시 고립된(isolated) 작업을 맡겨야 한다. 예를 들어 메인 코드를 작성하는 에이전트가 있다면, 두 번째 에이전트는 로고를 수정하는 작업처럼, 세 번째 에이전트는 헤더 카피를 업데이트하는 작업처럼, 서로 독립적이고 겹치지 않는 영역을 담당해야 한다. 작업 간의 경계선(lines between items of work)을 명확히 파악하고, 그 경계 안에서 각 에이전트가 움직이도록 설계하는 것이 멀티 에이전트 워크플로우의 핵심 설계 원칙이다.
컨텍스트 스위칭: 상위 1%를 가르는 진짜 능력
멀티 에이전트 워크플로우에서 가장 어려운 도전은 기술적인 설정이 아니다. 바로 ‘컨텍스트 스위칭(context switching)’이다. 에이전트 1이 핵심 로직을 작성하다 막혔고, 에이전트 2는 다른 기능을 개발 중이며, 에이전트 3은 또 다른 작업을 처리하고 있는 상황에서, 개발자는 세 가지 흐름 사이를 오가며 각각의 맥락을 기억하고 의미 있는 방향으로 각 에이전트를 계속 밀고 나가야 한다.
이것은 인간에게도 어려운 일이다. 어제 어느 에이전트가 어디까지 진행했는지, 어떤 문제에 부딪혔는지, 다음에 어느 방향으로 가야 하는지를 전환할 때마다 빠르게 재인식하고 판단을 내려야 한다. 미하일 에릭은 이 컨텍스트 스위칭 능력이 뛰어난 멀티 에이전트 워크플로우의 핵심 스킬이라고 말한다.
흥미로운 점은, 이 능력이 사실 훌륭한 인간 팀 관리자의 능력과 정확히 같다는 것이다. 여러 인간 개발자가 서로 다른 작업을 병렬로 처리하는 팀을 이끌며 각각의 진행 상황을 파악하고, 막혔을 때 방향을 잡아주고, 우선순위를 조정해 온 경험이 있는 사람이라면 멀티 에이전트 관리에 훨씬 수월하게 적응한다는 것이 실제로 관찰된 패턴이다. 인간 팀의 좋은 관리자가 AI 에이전트의 좋은 관리자가 되는 셈이다.
에이전트 친화적 코드베이스: 에이전트가 살 수 있는 환경을 만들어라
미하일 에릭이 강의에서 특별히 강조하는 개념이 있다. 바로 ‘에이전트 친화적 코드베이스(agent-friendly codebase)’ 또는 ‘에이전트 퍼스트 개발 생태계(agent-first development ecosystem)’다.
핵심 질문은 이것이다. 에이전트가 지금 당신의 코드베이스에 투입된다면, 그 에이전트는 지금 무슨 일이 일어나고 있는지 이해할 수 있을까?
이 질문에 자신 있게 “예스”라고 답할 수 없다면, 에이전트를 투입했을 때 오히려 혼란이 가중되고 코드베이스는 엉망이 될 가능성이 높다. 에이전트 친화적 코드베이스를 만들기 위한 원칙들은 다음과 같다.
첫째, 테스트 커버리지는 에이전트에게 보내는 계약서다. 에이전트는 명시적으로 정의된 계약(contracts), 즉 테스트를 기반으로만 작동할 수 있다. 충분한 테스트 커버리지가 없다면 에이전트는 자신이 만든 변경이 올바른지 검증할 방법이 없다. 전통적인 개발에서 테스트가 부족하면 디버깅이 어려워지는 정도였지만, 에이전트 개발에서 테스트 부족은 올바름 자체를 정의할 수 없는 상태를 의미한다. 에이전트가 코드를 수정한 후 테스트를 돌리고, 실패한 테스트가 즉각적인 피드백을 제공해 에이전트가 스스로 방향을 수정할 수 있는 환경이 이상적이다.
둘째, README와 코드의 일관성을 유지하라. 개발자라면 누구나 알지만, README는 코드와 금방 따로 놀기 시작한다. 코드는 기능 A를 구현하고 있는데 README는 기능 B를 설명하고 있는 상황은 흔하다. 인간 개발자라면 혼란스러워하면서도 코드를 직접 분석해 실제 동작을 파악할 수 있지만, 에이전트는 이 두 가지 불일치한 정보를 동등하게 받아들이고 어느 것이 진실인지 알 수 없어 잘못된 판단을 내릴 수 있다.
셋째, 에이전트는 에러를 기하급수적으로 복리(compound)시킨다. 에이전트의 가장 위험한 특성 중 하나는 오류를 증폭시키는 능력이다. 1단계에서 하나의 오해가 생기면, 에이전트는 그 오해를 다시 보고 2단계에서 그 오해를 바탕으로 또 다른 오류를 만들어낸다. 스파게티 코드는 대부분 이 복리 오류 증폭의 결과다. 따라서 에이전트가 처음 보게 될 코드, 즉 코드베이스의 첫 번째 버전이 설계 측면에서, 테스트 측면에서, 빌드 파이프라인 측면에서 완전히 견고하고 자기 일관성(self-consistent)을 갖추어야 한다. 에이전트를 투입하기 전에 기초 공사를 완전히 마치는 것이 핵심이다.
넷째, 일관된 디자인 패턴을 유지하라. 코드베이스의 어떤 곳에서는 특정 객체를 생성할 때 API A를 사용하고, 다른 곳에서는 같은 객체를 생성할 때 API B를 사용한다면, 에이전트는 어떤 것을 따라야 할지 알 수 없다. 이것은 인간 개발자에게도 혼란스러운 상황이다. 새로 합류한 개발자라면 “어느 방식을 써야 하나요?”라고 동료에게 물어볼 것이다. 하지만 에이전트는 그 질문을 명시적으로 던지지 못하고, 잘못된 선택을 하거나 일관성 없는 코드를 만들어낼 가능성이 높다. 코드베이스 전반에 걸쳐 일관된 프로그래밍 패턴을 유지하는 것은 에이전트 친화적 코드베이스의 중요한 요소다.
Lesson 3. 단순한 소프트웨어와 좋은 소프트웨어의 차이
기능하는 소프트웨어 vs. 탁월한 소프트웨어
스탠포드 강의에서 모든 학생들은 요구 조건을 충족하는 소프트웨어를 만들 수 있었다. 다섯 개의 플로우를 구현하라는 과제를 주면 모두들 다섯 개의 플로우를 구현했다. 그러나 탁월한 학생들은 거기서 멈추지 않았다. 요구 조건을 충족한 이후에도 계속해서 기능을 확장하고, 더 견고하게 만들고, 더 많은 가능성을 열었다. 미하일 에릭은 이 ‘마지막 마일(last mile)’에서 소프트웨어 취향(taste)이 만들어진다고 말한다.
취향은 단순히 타고나는 것이 아니다. 요구 조건을 충족했을 때 멈추는 것이 아니라, 그 이상으로 밀고 나가는 행동의 반복에서 길러진다. 좋은 소프트웨어를 만들기 위해 더 고민하고, 더 실험하고, 더 다듬는 과정에서 취향이 형성된다. 점수를 받기 위해 과제를 하는 사람과 문제를 진짜로 풀고 싶어서 밤을 새우는 사람의 차이, 바로 그 차이가 탁월한 엔지니어와 평범한 엔지니어를 가른다.
Anthropic 팀도 매주 Claude를 다시 만든다
미하일 에릭이 강의에서 공유한 매우 흥미로운 일화가 있다. Anthropic의 Boris가 강의에 게스트 스피커로 참여했을 때 나눈 이야기인데, Anthropic의 Claude 개발팀 역시 사실상 매주 또는 격주로 Claude 자체를 Claude를 이용해 다시 작성하고 있다는 것이다. 세계 최고의 AI 기업의 개발팀조차 자신들이 만든 소프트웨어로 자신들의 소프트웨어를 끊임없이 다시 쓰고, 실험하고, 반복하고 있다. 심지어 Claude를 만드는 그들도 무엇이 작동하고 무엇이 작동하지 않는지 여전히 발견해 나가는 과정 중에 있다.
이 일화가 전하는 메시지는 명확하다. 지금 AI 기반 소프트웨어 개발에 있어서는 세계 최고의 팀도 모든 정답을 알고 있지 않다. 따라서 실험(experimentation)을 자신의 워크플로우에 내재화하는 것이 AI 네이티브 소프트웨어 개발자가 되는 가장 중요한 길이다.
실험을 워크플로우에 내재화하라
미하일 에릭이 학생들에게 반복해서 강조한 것은 바로 실험 정신이다. 어떤 도구를 써야 하고, 어떤 방식이 좋다는 조언은 줄 수 있다. 하지만 결국 스스로 머리를 박아가며 실험해보고, 무엇이 자신에게 맞고 맞지 않는지 직접 발견해야 한다. 실험하고, 해킹하고, 반복하는 것 자체를 새로운 소프트웨어 개발 방식의 핵심으로 만들어야 한다는 것이다.
강의에서 가장 뛰어난 성과를 보인 학생들은 수업이 끝난 후에도 자신의 프로젝트를 계속 발전시켜 스타트업으로 키워나가고 있었다. 성적을 받기 위한 프로젝트가 아니라, 진짜 문제를 풀고 싶은 욕구에서 시작한 프로젝트였기 때문에 수업이 끝나도 멈추지 않은 것이다. 이것이 탁월한 엔지니어들의 사고 방식이다.
Lesson 4. 여전히 세상이 주니어 개발자를 필요로 하는 이유
시니어 개발자의 저항과 주니어의 유연성
아이러니하게도, AI 도구에 가장 저항적인 세대는 시니어 개발자들이다. 20년 동안 자신만의 방식으로 개발해온 사람들은 AI 도구가 등장해도 “내가 하던 방식이 맞아”라는 확신에서 쉽게 벗어나지 못한다. Vim을 고집하는 개발자처럼, 이미 깊이 내재화된 습관과 도구에서 벗어나는 것은 매우 어렵다.
반면 주니어 개발자들은 스펀지와 같다. 아직 모든 것이 새롭고, 세상이 얼마나 어려운지 아직 깊이 각인되지 않았다. 헬스케어 분야가 얼마나 복잡한지, 특정 산업의 규제가 얼마나 복잡한지를 아직 내면화하지 않았기 때문에, 오히려 두려움 없이 그 문제를 향해 달려들 수 있다. 이 ‘좋은 순진함(good naivety)’이 스타트업 창업자에게 완벽한 자질이며, 새로운 스킬을 가장 빠르게 습득하는 힘의 원천이다.
컴퓨터 과학이 가르치는 것의 본질
미하일 에릭은 소프트웨어 개발을 배운다는 것의 본질이 사실 코드를 쓰는 것이 아니라고 말한다. 그것은 복잡한 시스템을 디지털 수단으로 구축하는 방법에 대해 생각하는 법을 배우는 것이며, 알고리즘을 사용해 문제를 해결하는 방법을 배우는 것이다. 이것은 코딩이라기보다 수학에 가까운 사고 방식이다.
CS 전공자들이 갖게 되는 가장 강력한 자질은 어떤 문제에 직면했을 때 포기하지 않고 내부를 파고드는 능력이다. 시스템이 작동하지 않을 때 “잘 안 되네, 다른 걸 써야겠다”고 포기하는 것이 아니라, “왜 이렇게 됐을까? 내부를 파고들어 봐야겠다”는 태도다. 미하일 에릭은 이것을 ‘개발자의 오만함(arrogance of a developer)’이라고 부른다. 어떤 문제든 소프트웨어로 풀 수 있다는 자신감, 자신이 알고 있는 도구로 이것을 해결해 보겠다는 확신. 이것이 AI 시대에도 여전히 가장 강력한 개발자의 자질이다.
주니어를 채용하지 않으면 시니어도 없어진다
Stack Overflow의 2025년 개발자 설문에서는 AI 도구 사용률이 사상 최고를 기록했지만, 그 결과물에 대한 신뢰도는 급격히 하락했다는 역설적인 결과가 나왔다. Salesforce CEO 마크 베니오프는 2025년 엔지니어링 신규 채용을 제로로 선언했고, Klarna는 AI 도구만으로 운영하겠다고 선언했다가 결국 다시 인간 개발자를 고용해야 했다. 이 모든 것이 단기적 비용 절감의 유혹이 얼마나 위험한지를 보여준다.
오늘 주니어 개발자를 채용하지 않으면 3~5년 후에는 미드 레벨 개발자가 사라지고, 그 후에는 시니어 개발자도 사라진다. 기술 생태계는 신규 인재의 지속적인 유입을 통해서만 유지된다. 기초 훈련 없이는 AI가 만든 코드를 검증할 사람도, AI가 놓친 보안 취약점을 찾아낼 사람도 사라진다. 이것이 세상이 여전히 주니어 개발자를 필요로 하는 가장 근본적인 이유다.
에필로그: ‘Vibe Coding’의 함정과 진짜 생존법
영상 말미에 등장하는 미래 예고 장면에서 다음 강사는 이런 경고를 던진다. AI에게 “이것 만들어줘, 저것 추가해줘”를 반복하다 보면 한 달이 지나 엄청나게 정교하고 과도하게 엔지니어링된 소프트웨어가 완성된다. 그리고 출시하면 아무도 원하지 않는다. 이것이 ‘Vibe Coding’의 가장 위험한 함정이다.
AI가 있으면 무엇이든 빠르게 만들 수 있다. 하지만 무엇을 만들어야 하는지, 그리고 만들어진 것이 올바른지 판단하는 것은 여전히 인간의 몫이다. 미하일 에릭의 강의가 던지는 가장 핵심적인 메시지도 결국 여기에 있다. AI 에이전트를 관리하는 능력은 기술적 능숙함을 넘어 판단력, 취향, 그리고 진짜 문제를 볼 수 있는 눈에서 나온다. 이것은 코딩 튜토리얼로 배울 수 없는 것이다. 계속해서 실험하고, 실패하고, 다시 구축하는 과정에서만 길러지는 능력이다.
AI 시대의 생존법은 AI를 두려워하거나 무시하는 것도 아니고, AI에 전적으로 의존하는 것도 아니다. 에이전트를 이해하고, 설계하고, 관리하고, 검증할 수 있는 인간이 되는 것. 그것이 스탠포드에서 빅테크로 조용히 퍼지고 있는, 대부분이 아직 모르는 개발자 생존법이다.
작성 일자: 2026-03-08