Stanford CS146S란 무엇인가

Stanford CS146S는 정식으로는 CS146S: The Modern Software Developer라는 수업입니다. 담당 교수는 Mihail Eric이고, 2025년 가을에 처음 개설된 강의입니다. 수업의 공식 개요와 syllabus details는 themodernsoftware.dev에서 확인하는 것이 가장 정확하고, 과제는 mihail911/modern-software-dev-assignments 저장소에 공개되어 있습니다. 공식 사이트는 강의의 overview와 syllabus를 보는 곳이고, GitHub 저장소는 실제 assignments를 확인하는 1차 자료입니다.

Stanford는 실제로 일어나고 있는 변화를 제도화하고 있다

Stanford에는 이제 CS146S: The Modern Software Developer라는 과목이 있습니다. 이것만으로도 이미 꽤 많은 것을 말해줍니다.

오랫동안 그럴듯한 입장은 AI coding을 장난감이나 지름길, 혹은 “진짜 엔지니어링” 위에 얹힌 얇은 생산성 레이어 정도로 보는 것이었습니다. 하지만 이 입장은 이미 빠르게 낡아가고 있습니다.

공개된 과목 설명과 과제 흐름을 보면 CS146S는 prompting, Cursor와 Warp 워크플로, MCP servers, autonomous coding agents, security scanning, AI code review, multi-stack app generation을 다룹니다. 이것은 단지 새로움을 파는 세미나가 아닙니다. 소프트웨어 개발 자체가 모델을 중심으로 재편되고 있다는 사실을 Stanford가 인정한 것입니다.

이 점에서 Stanford는 맞습니다. 현대 소프트웨어 개발자는 어떻게 prompt할지, 어떻게 agents와 협업할지, 어떻게 도구를 연결할지, 어떻게 출력을 점검할지, 그리고 AI를 루프 안에 둔 채 더 빨리 배포할지를 이해해야 합니다. 아닌 척하는 것은 시장보다 뒤처지는 일일 뿐입니다.

문제는 첫 번째 version이 아니었다

하지만 지금의 AI development 담론이 여전히 놓치고 있는 지점이 있다고 봅니다. AI coding은 version one에서 실패하는 경우가 드뭅니다.

Version one은 오히려 쉬운 부분입니다.

login screen은 동작하고, dashboard도 렌더링되고, CRUD flow도 배포됩니다. demo는 박수를 받습니다. 문제는 네 번째, 다섯 번째, 여섯 번째 변경쯤부터 시작됩니다. 팀이 auth provider를 바꾸고, analytics를 교체하고, 초기 styling decision을 풀어내고, 서로 무관한 세 시스템을 건드리지 않으면서 feature 하나를 더해야 할 때입니다.

그 순간 대부분의 AI-generated codebases는 자신의 정체를 드러냅니다. 만들기는 빠르지만 바꾸기는 비싼 시스템이라는 점입니다.

핵심 실패 모드는 모델이 헛소리를 쓰는 것이 아닙니다. 핵심 실패 모드는 생성된 시스템의 boundaries가 약해서, 이후의 모든 변경이 보이지 않는 blast radius를 갖게 된다는 것입니다.

도구에 익숙하다고 구조적으로 안전한 것은 아니다

과목은 prompting, AI IDE 워크플로, MCP, agent automation, Semgrep, Graphite, multi-stack generation을 가르칠 수 있습니다. 이것들은 모두 중요합니다. 하지만 그 어떤 것도 한 달 뒤 결과물인 codebase가 여전히 건전하다고 보장해주지는 않습니다.

팀이 AI-native 워크플로에 매우 익숙해도 다음과 같은 system을 만들 수 있습니다.

  • screens가 implementation details를 직접 import한다
  • generated modules가 vendor APIs를 app code로 leak한다
  • optional services가 hard dependencies처럼 초기화된다
  • 두 번째 LLM review가 verification으로 취급된다
  • 모든 refactor가 archaeological work가 된다

그래서 저는 AI-native development의 결정적 우위가 도구 사용만으로 오지 않는다고 봅니다.

그 우위는 반복되는 변경을 버티는 architecture에서 나옵니다.

빠진 subject는 replaceability다

모든 AI-generated subsystem은 기본적으로 replaceable하다고 다뤄야 합니다.

즉 auth는 interface 뒤에, analytics도 interface 뒤에, storage도 interface 뒤에 둬야 합니다. styling은 contract 뒤에 둬야 합니다. dependency construction은 하나의 composition root에 모아야 합니다. validation은 system edges에서 해야 합니다. deterministic checks는 every commit마다 돌아야 합니다.

나쁜 module을 같은 contract 뒤에서 delete하고 다시 구현할 수 있다면 AI의 speed는 compound됩니다. 생성된 각 part가 다른 모든 part를 건드리게 되면 prompts가 아무리 좋아도 팀은 결국 느려집니다.

저는 이 주제가 더 많은 AI development 대화에서 명시적으로 다뤄지길 바랍니다.

핵심 질문은 단지 “AI가 first version을 더 빨리 배포하게 도와줄 수 있는가?”가 아닙니다.

정말 중요한 질문은 “product reality가 닥쳤을 때, 우리가 틀린 version을 얼마나 싸게 교체할 수 있는가?”입니다.

현대 소프트웨어 개발자에게도 guardrails는 필요하다

지금의 많은 AI 조언은 여전히 taste에 너무 기대고 있습니다.

  • prompt를 더 잘 쓴다
  • review를 더 꼼꼼히 한다
  • 여러 model outputs를 비교한다
  • agent에게 더 많은 맥락을 준다
  • AI reviewer를 하나 더 붙인다

이런 것들은 도움이 됩니다. 하지만 토대가 되지는 않습니다.

사람의 review는 일관되지 않습니다. 모델의 review는 더 일관되지 않습니다. 제가 규모 있게 신뢰하는 유일한 패턴은 이것입니다.

  • AI에게 generate하게 한다
  • deterministic rules가 enforce하게 한다
  • 사람이 specification과 tradeoffs를 판단하게 한다

그래서 저는 계속 같은 것들로 돌아옵니다. contracts, boundary rules, composition roots, contract tests, 그리고 빠르고 양보할 수 없는 checks입니다. 목표는 model을 완벽하게 만드는 것이 아닙니다. 목표는 system을 구조적으로 더 망가뜨리기 어렵게 만드는 것입니다.

Stanford는 맞다. 다음 step은 더 어렵다.

CS146S가 중요한 이유는 업계가 더 이상 무시할 수 없는 진실을 formalize하기 때문입니다. AI-native development는 이미 이 일의 일부가 되었습니다.

하지만 현대 소프트웨어 개발자가 AI tools에 대한 숙련도만으로 정의된다고는 생각하지 않습니다.

다음 기준은 더 높습니다.

현대 소프트웨어 개발자는 AI-generated parts를 constrain하고, verify하고, replace할 수 있는 codebase를 시스템 전체를 rewrite로 끌고 가지 않으면서 어떻게 만드는지도 알아야 합니다.

Stanford는 현대 소프트웨어 개발자를 가르치고 있습니다.

좋습니다.

빠진 수업은 AI-native codebase가 자기 자신의 속도 아래서 무너지지 않게 해주는 아키텍처 규율입니다.