AI 시대 개발자는 무엇으로 평가받을까: 스탠포드가 말한 새로운 생존 공식

Posted on by

스탠포드 CS146S ‘The Modern Software Developer’란? 2026년 개설된 스탠포드 대학 강의로, AI 시대 개발자의 역할을 ‘코드 작성자’에서 ‘AI 에이전트 관리자’로 재정의하고, 문제 구조화·검증·운영 능력을 새로운 핵심 역량으로 제시합니다. 강사 Mihail Eric(Stanford NLP 출신, Amazon Alexa·YC 스타트업 Storia AI 경력)이 설계했습니다.

개발자 면접에서 “코딩 테스트”를 보잖아요.

알고리즘 문제 풀고, 시간 복잡도 따지고, 한 시간 안에 얼마나 정확하게 짜는지.

근데 한 번만 생각해봐요.

AI가 그 코딩 테스트를 나보다 빨리 풀면, 그 평가 기준이 아직 의미가 있을까요?

이 질문에 스탠포드가 정면으로 답하는 강의를 만들었습니다. CS146S: “The Modern Software Developer”. 개설 공지 후 수 시간 만에 100명 이상이 몰려 마감됐어요(Stanford ExploreCourses, 2026년).

이건 “AI 도구 쓰는 법” 강의가 아닙니다.

개발자라는 직무 자체를 다시 정의하는 수업입니다.

AI 시대 개발자는 무엇으로 평가받을까: 스탠포드가 말한 새로운 생존 공식

왜 스탠포드가 이 강의를 만들었나

스탠포드 CS학과에서 “소프트웨어 개발”을 가르치는 방식이 바뀐 건 이번이 처음이에요.

강사 Mihail Eric은 스탠포드 자연어처리(NLP) 그룹에서 Christopher Manning, Percy Liang 밑에서 연구하던 사람입니다. Amazon Alexa 엔지니어를 거쳐 YC 스타트업 Storia AI를 공동 창업했고, 지금은 AI 기반 수익 플랫폼을 만드는 스텔스 스타트업의 Head of AI를 맡고 있어요(mihaileric.com, 2026년 3월 확인).

이 사람이 17,000명 넘는 뉴스레터 구독자를 보유하고 있고, Maven 플랫폼에서 프로 과정도 운영 중입니다(2026년 3월 코호트 진행 중).

이 사람이 수업에서 반복하는 핵심 메시지가 하나 있어요.

“개발자는 코드를 쓰는 사람에서, AI 에이전트 인턴을 관리하는 사람으로 바뀌어야 한다.”

인턴이요.

AI를 “슈퍼파워 도구”가 아니라 “인턴”이라고 부른 겁니다.

인턴한테 뭘 시키려면 뭐가 필요한지 아시죠? 명확한 지시, 결과 확인, 수정 피드백. 코드를 직접 짜는 게 아니라 일을 구조화해서 시키고 검증하는 능력이 핵심이 된다는 거예요.

10주짜리 커리큘럼을 보면 이 철학이 선명하게 드러납니다(themodernsoftware.dev):

주차내용핵심 변화
1-2주AI 기초, LLM 메커니즘, 에이전트 아키텍처(MCP)도구 이해
3-5주AI IDE, 개발 환경, 컨텍스트 관리환경 설계
6-7주품질·보안, 테스팅, 디버깅, 코드리뷰검증 능력
8-9주배포, 모니터링, 장애 대응운영 능력
10주소프트웨어 엔지니어링의 미래방향 설정

보세요. “코드 짜는 법”이 아니에요. 코드를 짜게 한 다음 뭘 해야 하는지를 가르치고 있어요.

Cognition, Warp, a16z 같은 업계 리더들이 게스트 스피커로 참여하고 있다는 것도 이 강의가 학계 이론이 아니라 실무 현장의 목소리를 반영하고 있다는 증거입니다.

DORA 2025 리포트가 증명한 불편한 진실

“스탠포드가 그렇게 가르친다” — 그래서 현실은 어떤데?

구글의 DORA(DevOps Research and Assessment) 팀이 2025년에 발표한 리포트가 있어요. 전 세계 기술 전문가 약 5,000명을 조사하고, 100시간 이상의 정성적 데이터를 분석한 결과입니다(dora.dev/research/2025).

개발자 90%가 AI 도구를 업무에 사용하고 있고, 80% 이상이 생산성이 올랐다고 답했습니다.

여기까지만 보면 “AI 좋네요!” 끝이잖아요.

근데 문제는 그 다음입니다.

30%는 AI가 생성한 코드를 신뢰하지 않는다고 답했어요.

숫자를 다시 보세요. 10명 중 9명이 AI를 쓰고 있는데, 그 중 3명은 AI가 만든 코드를 믿지 못한다는 거예요. 쓰긴 쓰는데 불안한 거죠.

그리고 DORA가 발견한 더 중요한 사실 하나.

AI 채택률이 높을수록 소프트웨어 배포 안정성은 오히려 떨어지는 상관관계가 나왔습니다.

이게 무슨 뜻이냐면요. AI가 코드를 빨리 만들어주니까 배포 속도는 빨라졌어요. 근데 그 코드가 프로덕션에서 문제를 일으키는 빈도도 함께 올라간 겁니다.

빨리 만들고.

빨리 터지고.

DORA 리포트의 핵심 결론은 한 줄이었습니다:

“AI는 독립적으로 팀을 개선하지 않는다. 기존 조직의 강점과 약점을 증폭할 뿐이다.”

잘하는 팀이 AI를 쓰면 더 잘하고, 못하는 팀이 AI를 쓰면 더 못한다.

이 한 줄이 개발자 평가 기준의 변화를 전부 설명합니다.

“좋은 개발자”의 정의가 이동하고 있다

예전에 좋은 개발자는 이런 사람이었어요:

  • 알고리즘을 빠르게 풀고
  • 깔끔한 코드를 짜고
  • 버그 없이 기능을 구현하고
  • 문서화를 잘 하는 사람

2026년 3월 현재, 이 목록의 상당 부분을 AI가 해냅니다.

그러면 뭐가 남죠?

스탠포드 CS146S와 DORA 2025 데이터, 그리고 제가 직접 에이전트 시스템을 운영하면서 느낀 걸 종합하면, 새로운 평가 축 3개가 보입니다.

1. 문제 정의 능력 — “무엇을 왜 만드는가”

AI한테 “로그인 기능 만들어줘”라고 하면 만들어줍니다.

근데 그게 OAuth인지 SSO인지, 세션 기반인지 토큰 기반인지, 보안 요구사항이 뭔지, 사용자 경험상 어떤 흐름이 맞는지 — 이건 AI가 결정 못 해요.

“뭘 만들어야 하는지”를 정확하게 정의하는 능력이, “어떻게 만드는지”를 아는 것보다 더 비싸진 겁니다.

솔직히 이거 인프라 하는 사람들은 원래 하던 거예요. “이 시스템은 왜 이렇게 설계해야 하는가”를 매일 고민하니까. 코드를 짜기 전에 아키텍처를 설계하고, 장애 시나리오를 그리고, 비용 대비 효과를 따지는 거. 그게 갑자기 개발자 전체에게 요구되기 시작한 거예요.

2. AI 네이티브 워크플로우 — “어떻게 시키고 검증하는가”

Mihail Eric이 말한 “AI 에이전트 인턴 관리”가 바로 이겁니다.

핵심은 이 루프예요:

요구사항 정의 → AI에게 초안 생성 → 검증 체크리스트 → 수정 요청 → 반복

이걸 잘하려면 뭐가 필요할까요?

  • AI한테 뭘 시킬지 구조화하는 능력
  • AI가 만든 결과를 검증하는 기준
  • 문제가 있을 때 정확히 지적하는 능력

“Cursor 잘 쓰는 법”이 아니에요. AI를 쓰더라도 결과의 품질을 판단할 수 있는 눈이 있느냐의 문제입니다.

CS146S에서 6-7주차가 “품질·보안·테스팅·코드리뷰”인 이유가 여기 있어요. AI가 만든 코드를 리뷰하는 능력이 직접 짜는 능력보다 중요해졌으니까.

라쿠텐이 1,250만 줄짜리 코드베이스에서 Claude Code를 돌렸더니 7시간 만에 99.9% 수치 정확도를 달성한 사례가 있어요. 근데 그 결과를 수용할지 말지 판단한 건 사람이었습니다.

3. 프로덕션 레디니스 — “만든 걸 운영할 수 있는가”

DORA 리포트가 발견한 “AI 쓸수록 배포 안정성 하락” 문제. 이걸 해결하는 건 더 좋은 AI가 아닙니다.

운영 역량입니다.

  • 장애 발생 시 원인을 추적하는 능력
  • 배포 전략(카나리, 블루-그린)을 설계하는 능력
  • 모니터링·알림을 세팅하는 능력
  • 보안 취약점을 사전에 차단하는 능력

“서비스를 만들었다”와 “서비스를 운영할 수 있다”는 완전히 다른 레벨이에요. AI가 만드는 건 도와주는데, 운영은 아직 사람 몫이거든요.

CS146S 8-9주차가 정확히 이 부분을 다루고 있습니다. 배포, 모니터링, 인시던트 대응. DORA 리포트에서도 느슨하게 결합된(loosely coupled) 아키텍처와 빠른 피드백 루프를 갖춘 팀만 AI 도입의 실질적 효과를 봤다고 합니다. 인프라와 운영 기반이 없는 상태에서 AI를 붙이면 오히려 역효과가 나는 거예요.

저는 이미 이 전환을 겪었습니다

여기서 제 이야기를 할게요.

저는 IT 인프라 엔지니어입니다. 메인 개발자가 아니에요. 코딩 테스트를 보면 상위권에 들지 못할 수도 있어요.

근데 지금 저는 17개 AI 에이전트와 33개 스킬을 직접 설계해서 운영하고 있습니다.

블로그 3개를 에이전트 팀이 리서치부터 검증까지 자동으로 처리하고, 트레이딩 분석을 에이전트가 매일 돌리고, 노트 정리를 에이전트가 구조화합니다. 각 에이전트에는 메모리 시스템과 목표 프레임워크가 연결되어 있어서, 세션이 바뀌어도 맥락이 유지돼요.

제가 하는 일은 뭐냐면요.

시스템을 설계하고, 에이전트한테 일을 구조화해서 시키고, 결과를 검증하고, 안 되면 고치는 겁니다.

정확히 스탠포드 CS146S가 말하는 “Modern Software Developer”예요. 코드를 직접 짜는 비중은 줄었는데, 만들어내는 시스템의 범위는 훨씬 넓어졌어요.

재밌는 건, 인프라 엔지니어가 이 전환에 오히려 유리하다는 점입니다.

왜냐면 인프라 하는 사람들은 원래 **”직접 만드는 것”보다 “시스템을 설계하고 운영하는 것”**이 본업이었거든요. 서버 프로비저닝, 배포 파이프라인, 모니터링, 장애 대응 — 이 모든 게 “코드를 직접 짜는 것”이 아니라 “시스템이 돌아가게 만드는 것”이었어요.

AI가 코드까지 짜주는 시대가 되니까, 인프라 사람의 스킬셋이 오히려 더 가치 있어진 겁니다. 아이러니하죠.

내가 느낀 점

솔직히 처음엔 불안했습니다.

“나는 메인 개발자가 아닌데, AI 시대에 내가 할 수 있는 게 뭐지?”

개발자 커뮤니티를 보면 다들 코딩 실력 얘기만 하잖아요. 알고리즘, 자료구조, 클린코드. 저는 그 대화에서 항상 한 발 빠져 있었어요.

근데 에이전트 시스템을 직접 만들어보고 나서 깨달은 게 있어요.

“코드를 잘 짜는 것”과 “시스템을 잘 만드는 것”은 다른 스킬이다.

그리고 AI 시대에 더 희소한 건 후자입니다. 코드를 짤 줄 아는 사람은 넘치는데, 여러 에이전트를 조율해서 하나의 파이프라인을 만들고 운영할 수 있는 사람은 아직 드물거든요.

솔직한 마음

그래도 찝찝한 건 있어요.

“결국 AI가 더 발전하면 운영까지 다 하는 거 아니야?”

맞아요. 언젠가는 그렇게 될 수도 있어요.

근데 DORA 리포트가 보여준 것처럼, 2026년 3월 현재 AI가 잘하는 건 “만드는 것”이지 “판단하는 것”이 아닙니다. 코드를 생성하는 건 잘하는데, 그 코드가 프로덕션에 나가도 되는지 판단하는 건 아직 인간의 영역이에요.

그리고 한 가지 더.

AI가 실수했을 때 책임지는 건 결국 사람입니다.

EU AI Act가 인간 감독 의무화, 제품 책임 확대 방향으로 가고 있는 이유가 이거예요. “AI가 짰으니 저는 몰라요”가 법적으로 안 통하는 시대가 온다는 겁니다.

그래서 저는 이렇게 정리합니다.

코드를 짜는 능력의 가치는 내려가고 있다.

코드를 판단하는 능력의 가치는 올라가고 있다.

이 격차가 벌어지는 동안이 기회입니다.

앞으로 할 것들

이 글을 읽고 “그래서 나는 뭘 해야 하는데?”라고 물을 분들을 위해 구체적으로 정리합니다.

지금 당장 (이번 주)

  1. 내 개발 워크플로우를 한 줄로 적어보세요. “직접 구현 중심”인지, “AI 초안 + 내가 검증” 중심인지. 현재 위치를 알아야 이동할 수 있어요.
  2. 자주 하는 작업 하나를 골라서 에이전트식으로 바꿔보세요. 요구사항 정리 → AI 초안 → 검증 체크리스트 → 수정. 이 루프를 한 번만 돌려보면 감이 옵니다.

이번 달

  1. CS146S 커리큘럼을 참고해서 자기 학습 로드맵을 만들어보세요. 10주짜리 강의 구조가 themodernsoftware.dev에 공개되어 있어요. 전체를 따라갈 필요는 없지만, 6-7주차(품질·보안)와 8-9주차(배포·운영) 파트는 직군 관계없이 강화해야 할 영역입니다.
  2. AI가 만든 코드를 리뷰하는 연습을 시작하세요. 코드를 짜는 연습이 아니라 읽고 판단하는 연습. “이 코드에서 보안 취약점은?” “이 아키텍처의 병목은?” 이 질문을 던지는 습관이 새로운 실력이에요.

3개월 안에

  1. 작은 에이전트 시스템을 하나 만들어보세요. 거창할 필요 없어요. 매일 하는 반복 작업 하나를 AI 에이전트에게 시키고, 결과를 검증하는 구조를 만들어보는 거예요. “이게 진짜 돌아가네?”하는 순간이 올 겁니다. 그 순간부터 관점이 바뀝니다.

FAQ

Q1. 코딩을 아예 안 배워도 되나요?

아닙니다. AI가 만든 코드를 검증하려면 코드를 읽을 줄은 알아야 해요. 다만 “처음부터 끝까지 직접 짜는 능력”보다 “읽고 판단하는 능력”의 비중이 커졌을 뿐입니다. 스탠포드 CS146S도 코딩 자체를 빼지 않았어요. 다루는 방식이 바뀐 거예요.

Q2. 스탠포드 CS146S 강의를 어디서 들을 수 있나요?

정규 강의는 스탠포드 재학생 대상이지만, 커리큘럼과 과제가 themodernsoftware.dev에 공개되어 있습니다. GitHub에 과제 저장소(mihail911/modern-software-dev-assignments)도 있어요. Mihail Eric은 Maven 플랫폼에서 프로 과정도 운영 중이에요(2026년 3월 코호트 진행 중).

Q3. 주니어 개발자는 이제 필요 없나요?

아닙니다. 이 강의의 메시지는 “주니어가 필요 없다”가 아니라 **”입문 루트가 바뀐다”**입니다. 반복 구현 역할은 줄지만, 문제 정의·맥락 정리·검증·품질 판단을 배울 사람은 여전히 필요합니다. 시작점이 “코드 짜기”에서 “시스템 이해하기”로 이동하는 거예요.

Q4. 비개발자(PM, 디자이너)에게도 해당되나요?

네. 2026년 2월 BetaNews 보도 기준으로 비개발자 ‘시티즌 빌더’가 전통 개발자를 4:1로 넘어설 전망이에요. AI 도구가 코딩 장벽을 낮추면서 PM, 디자이너도 직접 프로토타입을 만드는 시대입니다. “문제 정의 + 검증”이라는 핵심 역량은 직군 관계없이 적용됩니다.

Q5. AI 에이전트를 운영하려면 어떤 도구부터 시작하면 되나요?

Cursor IDE + Claude 조합이 진입장벽이 가장 낮아요. MCP(Model Context Protocol)를 활용하면 외부 도구와의 연결도 가능합니다. CS146S에서도 1-2주차에 MCP를 다루고 있어요. 처음부터 멀티 에이전트를 만들 필요 없고, 하나의 반복 작업을 AI에게 위임하는 것부터 시작하면 됩니다.

Q6. DORA 리포트에서 “AI가 안정성을 떨어뜨린다”고 했는데, 그러면 AI를 안 쓰는 게 낫나요?

아닙니다. DORA가 말한 건 “AI 자체가 나쁘다”가 아니라 **”AI 없이도 불안정했던 팀이 AI를 쓰면 더 불안정해진다”**입니다. 90%의 조직이 이미 플랫폼을 도입했고, 고품질 내부 플랫폼을 갖춘 조직만 AI의 실질적 효과를 봤다는 게 핵심이에요. AI 도입 전에 배포 파이프라인, 테스트 커버리지, 모니터링 같은 기반을 먼저 갖추라는 거예요.

결론: 개발자의 가치는 코드 밖에 있다

스탠포드 CS146S가 전하는 메시지는 단순합니다.

코드를 짜는 건 AI가 한다.

개발자는 “무엇을, 왜, 어떻게 만들지”를 판단하는 사람이 되어야 한다.

이건 개발자에게 위기가 아니라 재정의예요. 코딩 속도로 평가받던 시대에서, 판단의 질로 평가받는 시대로 넘어가는 겁니다.

재밌는 건, 이 변화가 “코드를 잘 짜는 사람”보다 “시스템을 이해하는 사람”에게 유리하다는 점이에요. 인프라 엔지니어, 시스템 아키텍트, 운영 경험이 있는 사람들 — 원래부터 “직접 짜기”보다 “설계하고 운영하기”가 본업이었던 사람들이 이 전환에 더 자연스럽게 적응하고 있습니다.

“나는 개발자가 아니니까”가 아니라, **”나는 원래부터 시스템을 만드는 사람이었고, 이제 AI가 코드까지 짜주니까 내가 만들 수 있는 시스템의 범위가 넓어진 것”**으로 보는 게 맞아요.

AI가 코드를 짜주는 시대에, 개발자의 가치는 코드 밖에 있습니다.

참고 자료