Go back
✍️ 에세이

세계 최대의 AI 기업은 차세대 엔지니어를 어떻게 교육하는가 — Anthropic x CodePath 커리큘럼 리뷰

들어가며

더이상 코드를 타이핑하지 않는 시대에, 세계 최대 AI 기업이 만든 커리큘럼의 첫 과제는 “AI가 짠 코드에서 버그를 찾아라”이다.

2026년 2월, Anthropic이 CodePath와 파트너십을 발표했다. CodePath는 미국 최대 규모의 대학 CS 교육 프로그램이다. 20,000명 이상의 학생, 그 중 40%가 저소득 가정 출신. CodePath CEO Michael Ellison은 이렇게 말했다.

“We now have the technology to teach in two years what used to take four.” 4년 걸리던 걸 2년에 가르칠 기술이 생겼다.

AI로 수업을 빠르게 돌리겠다는 게 아니다. AI를 도구로 쓰되, AI를 의심하는 훈련을 진행하는 것이다. Claude Code를 만든 회사가 정작 가르치는 건 Claude Code를 의심하는 법을 가르친다? 이 역설이 흥미로워서 커리큘럼을 뜯어봤다.

뭘 배워야 하나? AI 시대에 엔지니어는 어디에 시간을 투자해야 하나? 이 질문에 대한 Anthropic의 답이 이 커리큘럼에 담겨 있다.

CodePath 커리큘럼 뜯어보기

커리큘럼은 3단계, 총 30주+ 과정이다. 각 단계를 주차별로 최대한 상세하게 풀어본다.

주의: 이 커리큘럼은 2026년 여름 정식 런칭 예정이며, Howard University에서는 이미 2026년 봄학기에 학점 과목으로 개설되어 진행 중이다. 아래 주차별 배치와 세부 과제는 공개된 토픽 리스트와 파일럿 사례를 바탕으로 일부 추론하고 분석한 것이며, 실제 커리큘럼과 다를 수 있다.

1단계: Foundations of AI Engineering (10주)

기초 단계인데, “기초”의 정의가 기존 부트캠프와 완전히 다르다.

Week 1-2 는 Python 기반 자료구조, 알고리즘, OOP다. 여기까지는 어디서나 볼 수 있는 구성. 근데 과제가 다르다. Claude Code로 링크드 리스트, 트리를 구현하고 — 여기서 끝이 아니라 — AI가 생성한 코드를 직접 리뷰하고 버그를 찾는다.

첫 주부터 “AI가 짠 코드를 그냥 쓰지 마라”를 훈련시키는 거다. (참고로 커리큘럼은 Claude Code를 중심으로 하되, GitHub Copilot이나 AI 기반 IDE도 함께 활용한다. 도구 하나에 종속되지 않게 설계한 셈이다.)

Week 3-4 가 진짜 핵심이다. AI 생성 코드의 비판적 평가 . 의도적으로 미묘한 버그가 있는 AI 코드를 제공하고 디버깅 + 개선안을 작성하게 한다. 같은 문제를 프롬프트만 바꿔서 3번 생성하고, 결과를 비교 분석하는 리포트도 쓴다.

생각해보면 이게 꽤 영리하다. 프롬프트 3번 바꿔서 결과를 비교하면, “아, AI는 프롬프트에 따라 완전히 다른 코드를 내놓는구나”를 체감하게 된다. 같은 AI인데 질문 방식에 따라 품질이 천차만별이라는 걸.

Week 5 는 알고리즘적 사고 + 프롬프트 체인 설계. 복잡한 문제를 단계별로 분해하고, 각 단계에 맞는 프롬프트 체인을 설계한다. “프롬프트 하나로 해결 vs 3단계 체인”을 비교하는 실험도 있다. 프롬프트 엔지니어링을 단순한 스킬이 아니라, 알고리즘적 사고의 연장으로 가르치는 셈이다.

Week 6 은 ML 리터러시. 수학 없이 개념만. 지도학습, 비지도학습, 생성모델의 use case를 분류하고, 사전 학습된 감정 분석 모델 API를 호출해서 결과를 해석하는 리포트를 쓴다. “모델을 만드는 법”이 아니라 “모델이 뭘 하는지 이해하는 법”에 집중한다.

Week 7-8 이 실전으로 들어가는 구간이다. RAG, 에이전틱 워크플로우, 파인튜닝, 가드레일. PDF 3개로 벡터 DB 구축해서 Q&A 챗봇 만들기, 도구 2-3개 연결한 에이전트 만들기, 챗봇에 “개인정보 노출 방지” 필터 추가 후 레드팀 테스트까지. 1단계 7주차에 이미 가드레일을 가르친다. 프로덕션 관심사를 초기부터 심어두는 거다.

Week 9 는 Git/GitHub 협업. PR 생성, 코드 리뷰, 머지 컨플릭트 해결. 이걸 9주차에 넣은 건 의도적이라고 본다. “혼자 AI로 만드는 것”에서 “팀으로 AI와 함께 만드는 것”으로 넘어가는 전환점.

Week 10 은 최종 프로젝트. 챗봇, 요약 도구, 문서화 어시스턴트 중 선택. RAG + 가드레일을 통합한 실제 작동하는 결과물을 만든다.

★ 강조 과제: “AI가 짠 정렬 알고리즘 5개 중 틀린 것 찾기”

이 과제가 1단계의 철학을 압축한다. AI가 5개의 정렬 알고리즘 구현을 내놓으면, 학생은 그 중 틀린 것을 찾아야 한다. “AI가 맞다고 가정하지 마라”가 전체 커리큘럼의 첫 번째 원칙이다.

기존 교육이 “정렬 알고리즘을 직접 구현하라”였다면, 이 커리큘럼은 “AI가 구현한 정렬 알고리즘을 읽고 평가하라 ” 로 바뀐 거다. 쓰기에서 읽기로. 생산에서 검증으로. 이 전환이 핵심이다.

2단계: Applications of AI Engineering (10주)

1단계가 기초 훈련이었다면, 2단계는 실전이다. 그리고 난이도가 확 올라간다.

Week 1-2 부터 강렬하다. 실제 오픈소스 프로젝트 — 1만 줄 이상의 코드베이스를 받는다. Claude Code로 구조를 파악하고, 아키텍처 다이어그램을 작성한다.

1만 줄이 많다고? 실무에서는 수십만 줄짜리 레거시를 받아들고 “이거 다음 주까지 파악해”라는 말을 듣는다. 1만 줄은 그 연습인 셈이다.

Week 3-4 는 스펙 기반 구현 + 디버깅이다. CodePath는 이걸 공식적으로 “Spec-driven vibe coding”이라고 부른다. 기능 스펙 문서를 받고 AI로 구현한 다음, 테스트를 통과시킨다. 바이브 코딩이라는 이름을 쓰되, 스펙이라는 조건을 붙인 게 포인트다. 그리고 결정적인 차이가 하나 더 있다. “AI가 못 풀어서 내가 직접 한 부분”을 기록 해야 한다.

Week 5-7 은 고급 기법의 프로덕션 통합이다. 기존 웹앱에 RAG 검색 기능을 추가하고, 에이전트 파이프라인에 에러 핸들링 + 로깅 + 모니터링을 붙이고, 가드레일 정책 설계 문서를 작성한 뒤 구현하고 평가까지 한다. 주목할 건, 신규 개발이 아니라 기존 코드베이스 통합 이라는 점이다. “새로 만들기”는 AI가 잘한다. “기존 코드에 끼워 넣기”는 사람이 해야 한다.

Week 8-9 는 PR 리뷰 훈련이다. 다른 팀의 AI 생성 PR을 리뷰하고, “이 코드가 AI가 짠 건지 사람이 짠 건지” 판별 + 개선 코멘트를 단다. 리뷰 기준 체크리스트도 직접 만든다 — 보안, 성능, 가독성, 테스트 커버리지.

AI가 코드를 짜는 시대에 코드 리뷰 체크리스트를 만들게 하는 거다. 이게 읽기 능력 훈련의 끝판왕이다.

Week 10 은 실제 오픈소스 PR 제출. 2025년 파일럿 기준 GitLab, Puter, Dokploy 같은 프로젝트에 실제로 PR을 내고 메인테이너 리뷰를 받는다.

★ 강조 과제: “1만+ LOC 오픈소스 구조 파악”

코드를 한 줄씩 읽지 말고, AI에게 올바른 질문을 하라. 이게 이 과제의 핵심이다. “이 프로젝트의 진입점이 뭐야?”, “데이터 흐름이 어떻게 되지?”, “이 모듈의 핵심 의존성은?” — 이런 질문을 AI에게 던지면서 거대한 코드베이스를 구조화하는 훈련.

이전 글 “코드를 읽지 않는 시대”에서 말했던 바로 그 능력이다. AI 시대의 코드 읽기는 한 줄씩 따라가는 게 아니라, 구조를 파악하고 핵심 로직을 집중적으로 보는 거다.

★ 강조 과제: “AI가 못 풀어서 내가 직접 한 부분 기록”

이게 AI 시대의 학습 증명 방식이다. AI가 짜준 코드는 내 실력이 아니다. AI가 못 풀어서 내가 디버깅한 부분, 내가 설계를 바꾼 부분, 내가 테스트를 추가한 부분 — 그게 진짜 학습이다.

“AI로 빠르게 만들되, 어디서 AI가 틀렸는지 일지를 써라.” 이 한 줄이면 과제 설계의 핵심이 요약된다.

3단계: AI Open-Source Capstone

마지막 단계는 거의 인턴십이다. 실제 오픈소스 프로젝트에 배정되고, 이슈를 선택하고, Claude Code로 구현하고, PR을 내고, 머지시킨다. 주간 스프린트 리포트를 쓰고, 메인테이너와 소통한다.

최종 산출물? 포트폴리오에 넣을 수 있는 실제 오픈소스 기여 이력.

★ 강조 과제: 실전 오픈소스 기여

토이 프로젝트가 아니다. Todo 앱이 아니다. 실제 사용자가 있는, 실제 메인테이너가 리뷰하는, 실제로 머지되는 PR. 이게 부트캠프 졸업 요건이라는 거다.

2025년 가을 파일럿에 참여한 학생의 말이 인상적이다.

“Claude Code was instrumental in my learning process, especially since I came into the project with very little experience in the programming languages used in the repository [including TypeScript and Node.js].”

Claude Code는 제 학습 과정에서 핵심적인 역할을 했습니다. 특히 저는 해당 레포지토리에서 사용하는 프로그래밍 언어(TypeScript, Node.js 포함)에 대한 경험이 거의 없었기 때문입니다.

— Laney Hood, CodePath student and computer science major at Texas Tech University

TypeScript와 Node.js 경험이 거의 없었는데, Claude Code 덕에 실제 오픈소스 프로젝트에 기여할 수 있었다고. AI가 진입 장벽을 낮춰주고, 그 위에서 실제 학습이 일어난 케이스다.

Anthropic이 바라보는 AI Native Engineer

커리큘럼을 다 보고 나면 패턴이 보인다. Anthropic이 원하는 엔지니어상이 네 가지 키워드로 수렴한다.

비판적 코드 평가. “AI가 맞다고 가정하지 마라”는 전체 커리큘럼의 첫 번째 원칙이다. GPT-6이 나오고, Claude Opus 5가 나와도 마찬가지다. 99%는 맞는다. 근데 나머지 1%가 프로덕션에서 장애를 만든다. 그 1%를 잡아내는 게 사람의 몫이다.

대규모 코드베이스 이해. AI가 코드를 빠르게 짜주는 시대에, 읽기 능력의 가치는 오히려 올라간다. 이상하게 들리지만 사실이다. 생산 속도가 빨라질수록, 검토해야 할 코드의 양도 같이 늘어난다. 코드를 읽지 않는 것과 읽지 못하는 것은 다르다. 전자는 선택이고, 후자는 한계다.

프로덕션 레벨 관심사. “동작하는 코드”와 “프로덕션에 올릴 수 있는 코드”는 다르다. AI가 만든 코드는 대부분 “동작은 하는” 수준이다. 에러 핸들링, 로깅, 보안, 성능 — 이걸 붙이는 건 사람의 판단이다. 1단계 7주차에 이미 가드레일을 가르치는 이유가 여기 있다.

실전 기여 능력. 토이 프로젝트가 아니라 실제 오픈소스. 메인테이너의 리뷰를 받고, 실제로 머지되는 PR. 이게 졸업 요건이라는 건 단순한 과제 설계가 아니다. 실전에서 검증받은 경험을 갖고 나오라는 거다.

그리고 이 네 가지 모두 같은 전제를 깔고 있다.

인풋이 없으면 비판적 읽기가 불가능하다.

자료구조를 모르면 AI가 짠 정렬 알고리즘의 버그를 찾을 수 없다. HTTP를 모르면 AI가 만든 API의 에러 핸들링이 적절한지 판단할 수 없다. 기초가 곧 비판적 사고의 재료다.

그리고 이건 면접에서도 이미 반영되고 있다. CodePath에 따르면, 고용주들은 점점 더 “AI가 생성한 코드를 해석하고, 리뷰하고, 설명하는 능력”을 면접에서 묻기 시작했다. AI 코드 리뷰 능력이 면접 질문이 되는 시대. 커리큘럼이 그걸 준비시키는 거다.

세계는 지금 어떻게 가르치고 있는가

CodePath만 움직이는 게 아니다. 미국 대학들이 AI 시대에 맞춰 커리큘럼을 뜯어고치고 있다. 그 방향이 제각각인데, 그게 오히려 흥미롭다. 아직 아무도 정답을 모른다는 뜻이니까.

Stanford — 같은 학교, 세 갈래 실험

Stanford가 가장 극적이다. 같은 학교 안에서 두 가지 정반대의 접근이 동시에 돌아가고 있다.

CS106A (Programming Methodology, 프로그래밍 입문) — AI 사용 금지. “우리는 AI로 과제를 풀지 않길 원합니다”라고 실라버스에 명시했다. 프로그래밍의 기초 사고력을 AI 없이 직접 키워야 한다는 입장이다. 입문자에게 AI를 허용하면 사고 과정 자체가 형성되지 않는다고 본 거다.

CS146S (The Modern Software Developer, AI 시대의 소프트웨어 개발) — 정반대. AI를 전면 도입한 신규 과목이다. 강사가 Mihail Eric. 에이전틱 엔지니어링을 주제로 한 이전 글에서도 인용한 인물이다. 그가 Stanford에서 이걸 직접 가르치고 있다.

CS146S의 10주 커리큘럼을 보면 CodePath와 겹치는 지점이 많으면서도 결이 다르다.

게스트 강연진도 눈에 띈다. Cognition의 Russell Kaplan, Warp의 Zach Lloyd, a16z의 Martin Casado. 실리콘밸리 현업이 직접 와서 현장의 변화를 전달한다.

Mihail Eric의 핵심 메시지는 이거다.

“Human-agent engineering, not vibe coding.” 바이브 코딩이 아니라, 인간-에이전트 엔지니어링이다.

“LLMs are only as good as you are.” LLM은 당신만큼만 똑똑하다.

“개발자는 AI 에이전트 인턴의 매니저”라는 비유도 쓴다. AI가 일을 하되, 방향을 잡고 검수하는 건 사람이라는 거다. 과제도 GitHub에 공개되어 있다. 실제로 뜯어보면 꽤 흥미롭다.

CodePath와 비교하면 결이 확 다르다. CS146S는 도구 중심이다. Cursor, Claude Code, Warp, Graphite, Semgrep, bolt.new — 현업에서 쓰는 AI 도구를 매주 갈아타면서 직접 다룬다. CodePath는 사고력 중심이다. “AI가 짠 정렬 알고리즘 5개 중 틀린 것 찾기”, “AI가 못 풀어서 내가 직접 한 부분 기록” — 도구보다 판단력에 집중한다.

둘 다 “AI 코드를 사람이 검증한다”는 전제는 같다. CS146S Week 7의 “수동 리뷰 vs AI 리뷰 비교”와 CodePath의 “AI 코드 비판적 평가”는 같은 목적지를 다른 경로로 가는 거다.

같은 Stanford에서 두 갈래. 어느 쪽이 맞는 건 아니다. 학생의 레벨에 따라, 목적에 따라 다른 접근이 필요하다는 걸 Stanford가 실험으로 보여주고 있다.

UW Allen School — “Coding is Dead” 선언

2025년 7월, 워싱턴대(UW) CS학과장 Magdalena Balazinska가 공식적으로 이렇게 말했다.

“Coding — that is, translating a precise design to software instructions — is dead. AI now does that.” 코딩, 즉 정밀한 설계를 소프트웨어 명령으로 변환하는 것은 죽었다. AI가 이제 그걸 한다.

자극적인 말이지만 맥락이 있다. UW는 과제에 GPT 도구 사용을 허용하되, AI를 동료 학생을 인용하는 것과 같은 수준으로 협업자로 인용하도록 요구한다. “AI를 썼으면 어떻게 썼는지 밝혀라.” 금지가 아니라 투명한 활용이다.

CodePath의 “AI가 못 풀어서 내가 직접 한 부분을 기록하라”와 비슷한 철학이다. AI 사용을 전제하되, 그 과정을 기록하고 성찰하게 한다.

UMD — Claude Code를 수업에 도입

메릴랜드대(UMD)는 더 직접적이다. William Pugh 교수가 CMSC 398Z “Effective use of AI Coding Assistants and Agents”라는 과목을 2025년 가을에 개설했다. Copilot, VSCode, Claude Code 같은 CLI 도구를 수업에서 직접 실습한다. 빌드 시스템 자동 호출, 테스트 실행, 에러 수정까지 에이전트를 활용한다.

Pugh 교수의 코멘트가 인상적이다. “장기적으로 학부 CS 커리큘럼 전체를 AI 코딩 도구의 존재에 맞춰 업데이트할 계획이다.” 한 과목이 아니라 전체 커리큘럼을 바꾸겠다는 거다.

Harvard CS50 — 가장 보수적인 접근

반대편 끝에는 Harvard가 있다. CS50은 자체 AI 러버덕(CS50.ai)을 구축해서 수업에 통합했다. AI를 교육 도구로 쓰는 거다. 근데 일반 과제에서는 외부 AI(ChatGPT, Copilot 등) 사용을 금지한다. 파이널 프로젝트에서만 허용하되 “본질은 본인 것이어야 한다”는 조건을 건다.

“AI 코딩 도구 활용법”을 직접 가르치진 않는다. AI는 학습을 돕는 도구일 뿐, 학습의 주체는 학생이라는 입장이다.

UC San Diego + Google — 글로벌 컨소시엄

UC San Diego는 Google.org의 180만 달러 지원을 받아 GenAI in CS Education Consortium을 출범했다. University of Toronto와 공동 운영하며, 6개의 턴키 코스를 개발하고 있다. “업계가 이제 신입 엔지니어에게 AI 도구 유창성을 기대한다”는 게 출발점이다.

Andrew Ng — “Product Engineer의 황금기”

이 흐름을 가장 명확하게 정리한 사람이 Andrew Ng이다. Stanford CS230 Autumn 2025 Lecture 9: Career Advice in AI 강의에서 그가 한 말들이 인상적이다.

Ng은 지금이 AI로 무언가를 만드는 사람에게 **“역사상 최고의 시기”**라고 말했다. AI가 처리할 수 있는 태스크의 복잡도가 7개월마다 두 배가 된다는 연구를 인용하면서.

근데 그가 강조한 건 코딩 속도가 아니었다. 병목이 바뀌었다는 거다. 코드를 짜는 속도가 AI 덕에 폭발적으로 빨라지면서, 진짜 병목은 “무엇을 만들지 결정하는 것”으로 옮겨갔다. 실리콘밸리에서 PM(프로덕트 매니저)과 엔지니어의 비율이 전통적으로 1:4~8이었는데, 지금은 1:1로 수렴하거나 아예 역할이 합쳐지는 추세라고 했다.

코드를 짤 수 있는 건 더 이상 차별화 요소가 아니다. 사용자와 대화하고, 공감하고, 무엇을 만들지 결정할 수 있는 엔지니어가 가장 가치 있는 인재가 됐다.

게스트 강연자 Laurence Moroney(Arm AI Director)는 더 직설적이었다. 세 가지 생존 조건을 제시했다.

  1. 깊이 있는 이해(Understanding in Depth) — 하이레벨 API만 쓸 줄 아는 게 아니라, 그 밑에서 뭐가 돌아가는지 이해해야 한다.
  2. 비즈니스 포커스 — “쿨한 것”을 만드는 시대는 끝났다. 비즈니스 가치와 직결되는 것을 만들어야 한다.
  3. 딜리버리에 대한 집착 — 아이디어는 싸다. 실제로 프로덕션 레벨로 배포할 수 있는 능력이 차별화다.

Moroney는 바이브 코딩이 만드는 “기술 부채”도 경고했다. LLM으로 앱 전체를 생성할 수 있지만, 그렇게 만든 코드는 거대한 기술 부채를 안고 있다고.

Ng이 학생들에게 던진 마지막 조언도 기억에 남는다. “회사 브랜드가 아니라 팀을 보고 선택하라.” 유명한 AI 회사에 들어갔는데 백엔드 결제 시스템 Java 팀에 배치된 학생 사례를 들면서, 작지만 좋은 팀에서 배우는 게 화려한 로고보다 낫다고 했다.

기초의 재정의 — 사고력은 AI가 대신 키워주지 않는다

카네기멜론 수학 교수 포쉔로(Po-Shen Loh)가 한 말이 있다.

“Using AI to do your writing homework is the same as driving a car instead of running a mile for exercise.” AI로 글쓰기 숙제를 대신하는 건, 운동 대신 차를 타는 것과 같다.

몸은 목적지에 도착한다. 하지만 체력은 키워지지 않는다.

포쉔로는 이제 교육이 바뀌어야 한다고 말한다. 숙제를 “하는 법”이 아니라 “채점하는 법”을 가르쳐야 한다고. CodePath 커리큘럼이 1주차부터 AI 코드 오류를 찾게 하는 이유가 정확히 이거다. AI가 짠 것을 채점하려면, 먼저 정답이 뭔지 알아야 한다.

그가 말한 또 하나의 키워드가 있다. “세상을 시뮬레이션하는 능력.” 공감과 다양한 경험을 바탕으로, 아직 일어나지 않은 미래를 머릿속에서 전개하는 힘. 이건 AI가 가져갈 수 없는 인간의 영역이다. AI는 과거 데이터로 패턴을 찾는다. 시뮬레이션은 사람이 한다.

Stanford CS106A가 AI를 금지하고, CS146S가 AI를 쓰면서도 “바이브 코딩이 아니라 인간-에이전트 엔지니어링”이라고 못 박는 이유. Andrew Ng이 “깊이 있는 이해”를 생존 조건 첫 번째로 꼽는 이유. Laurence Moroney가 “하이레벨 API만 쓸 줄 아는 건 부족하다”고 한 이유. 다 같은 곳을 가리킨다.

기초 없이 AI만 쓰면 공중에 뜬다.

이미 할 줄 안다면 10x, 100x로

솔직히 말하면, 나는 AI의 수혜를 가장 크게 받는 사람 중 하나다.

지난 두 달, 1847커밋을 찍었다. 혼자서 백엔드, iOS, 웹, 인프라를 동시에 굴렸다. TDD로 짜고, 아키텍처를 설계하면서. 이전에 같은 걸 혼자 하려면 몇 배의 시간이 걸렸을 거다. 코드 작성 속도만이 아니라, 커버할 수 있는 영역의 폭 자체가 달라졌다.

10배는 됐다. 어쩌면 그 이상.

근데 여전히 사람 손이 가는 게 있다. 무엇을 만들지 결정하는 것. 어떻게 만들지 설계하는 것. 최종 결과물이 괜찮은지 검증하는 책임. AI는 내가 지시한 대로 만든다. “뭘 지시할지”는 내가 안다.

Andrew Ng이 말한 “병목이 구현에서 결정으로 옮겨갔다” 는 게 정확히 이 경험이다. 만드는 건 빠르다. 뭘 만들지, 어디까지 만들지, 이게 정말 필요한 건지 — 그 판단이 병목이다.

기초가 있는 사람은 AI와 함께 10배, 100배 간다. 기초가 없는 사람은 AI가 틀린 것도 모르고 넘어간다. 두 사람이 같은 AI를 써도 결과물이 다른 이유다.

멘토링 경험 — AI 대화록을 리뷰하다

올해부터 멘토링 방식을 바꿨다. 멘티들의 코드가 아니라 AI 대화록을 공유받기 시작했다. 165개 대화를 분석해서 5가지 기준 프레임워크를 만들었다. 질문의 깊이, 맥락 제공 수준, 자기 가설 포함 여부, 검증 요청 방식, 후속 질문의 연결성.

존(가명) 이야기를 해야겠다. 꽤 오랜시간 프로그래밍을 해왔지만(존은 비전공자이다.) 프로그래밍 실력이 몇 달째 제자리였다. AI 대화록을 보니 이유가 바로 보였다.

“이거 어떻게 해?"
"코드 짜줘."
"무슨 말인지 모르겠다.”

AI는 답을 준다. 존은 그걸 복사한다. 생각을 하지 않는다. 학습이 일어나지 않는다.

반면 같은 시기에 빠르게 성장한 멘티의 대화록은 달랐다.

“트랜잭션이란 건 모두 성공 또는 모두 실패인데, @Async는 다른 쓰레드를 사용하니까 트랜잭션 범위를 벗어나는 것 같은데, 이 가설이 맞나요?”

자기 가설을 세우고, AI한테 검증을 요청한다. AI가 답을 주더라도 그 답을 자기 이해 안에 통합한다.

CodePath 커리큘럼이 영리한 건 이 문제를 구조적으로 해결한다는 거다. “AI가 짠 정렬 알고리즘 5개 중 틀린 것 찾기” — 이 과제는 자기 가설 없이 불가능하다. ‘이 알고리즘은 이렇게 동작해야 해’라는 기준이 머릿속에 있어야, 틀린 걸 찾을 수 있다. 커리큘럼이 억지로 비판적 사고를 유도하는 구조다.

커리큘럼에 대한 추가 코멘트

얼마 전에는 스탠포드에서 더이상 프로그래밍 언어를 가르치지 않는다는 가짜 뉴스로 SNS에서 호들갑이 있었다. AI가 확실히 발전했으니 그럴법도 하다. 그런데 재밌는건 원래 CS 커리큘럼에서 프로그래밍 언어 문법을 가르치지 않는다. 내가 지난 학기 프로그래밍 입문을 파이썬으로 배워도 그건 프로그래밍 원리와 사고력, 문제 해결력을 배우는 과목이지 파이썬 문법을 배우는 과목이 아니다. 다음 학기 자료 구조 수업을 수강하는데 언어가 자바라면 수강 전에 열심히 기본 문법 정도는 독학을 해서 가야한다.

미국 대학에서 교육을 어떻게 하는가? 사이언스 아담 채널에 한글 더빙으로 올라온 하버드 CS 입문 교육이 있으니 한번 들어보길 권한다. 단순히 커리큘럼으로 설명되지 않는 강의의 퀄리티를 느낄 수 있을 것이다. (모든 교육 과정은 공개되어 있으니 공부를 해보는 것도 좋다.)

하버드 CS50 교수 David Malan의 실제 강의를 보면 이 철학이 명확해진다. 첫 수업에서 그는 이렇게 말한다. “AI가 코딩을 다 해주는 시대인데 왜 배우냐고? 이 수업은 단 한 번도 코딩 기술을 가르치는 수업이었던 적이 없다. 생각하는 방법을 가르치는 수업이다.”

Malan은 GitHub Copilot으로 학생들이 15시간 걸려 짠 C언어 과제(해시 테이블 기반 맞춤법 검사기)를 수초 만에 생성해 보인다. 그리고 묻는다. “이걸 보고 15시간이 헛됐다고 생각하나요?” 답은 아니다. 15시간 동안 고생하며 쌓은 “코드를 볼 줄 아는 눈”이 없으면 AI의 환각 — 존재하지 않는 라이브러리를 자신 있게 사용하는 코드, 문법은 완벽한데 논리가 틀린 코드 — 을 구별할 수 없다.

CS50이 2023년부터 도입한 AI 러버덕도 같은 원리다. GPT 기반이지만 정답을 직접 알려주지 않는다. 시스템 프롬프트로 “소크라테스처럼 학생이 스스로 깨우치도록 유도하라”고 설정했다. AI를 학습 도구로 쓰되, 사고 과정은 학생이 직접 거치게 만드는 거다.

Malan이 강의 마지막에 한 말이 기억에 남는다. “세미콜론 전문가(벽돌)에서 시스템 설계자(건축가)로 진화하라.” AI가 벽돌을 쌓아주는 시대에, 건축가의 눈을 가진 사람만이 AI를 도구로 쓸 수 있다. 그 눈은 기초를 직접 쌓아본 사람에게만 생긴다.

이게 CodePath 커리큘럼이 1주차부터 “AI가 짠 코드에서 버그를 찾아라”로 시작하는 이유이기도 하다. 벽돌을 쌓아본 사람만이 잘못 쌓인 벽돌을 알아본다.

아쉬운 점 — 커리큘럼이 안 가르쳐주는 것

커리큘럼이 좋다고 해서 다 있는 건 아니다. 솔직히 빠진 게 보인다.

설계와 아키텍처 사고. 이건 교육으로 단기간에 심기 어렵다. 수십 번 잘못된 설계를 경험하고, 그게 왜 잘못됐는지 사후에 분석하는 과정이 필요하다. 커리큘럼은 구현 중심이다. 설계의 실패와 반성을 체계적으로 가르치지는 않는다.

프랑켄슈타인 함정. AI 시대의 새로운 위험이다. 코드 생산 속도가 빨라지니까, 불필요한 기능까지 다 만들게 된다. ‘어차피 빠르게 만들 수 있으니까’라는 생각으로. 결과물이 뾰족한 솔루션이 아니라 괴물이 된다. 기능은 많은데 정작 뭘 하는 제품인지 모르겠는 상태.

“무엇을 안 만들지”가 더 중요한 판단이다. 근데 AI는 그 판단을 해주지 않는다. 시키는 대로 만든다. Laurence Moroney가 경고한 “바이브 코딩의 기술 부채”도 같은 맥락이다. 빠르게 만들 수 있다는 건 빠르게 망가뜨릴 수도 있다는 뜻이다.

AI는 내 생각을 편향시킨다. 이건 개인적으로 경험한 함정이다. AI한테 물어보면 내 방향과 비슷한 답이 나온다. 내가 이미 생각하는 걸 정교하게 다듬어준다. 다른 관점이 보이지 않는다. 실제 사용자의 피드백, 타인의 객관적인 시각이 없으면 에코 챔버에 갇힌다. AI 시대에 다양한 피드백 루프가 더 중요해진 이유다.

팀 협업과 커뮤니케이션. Git 협업을 9주차에 가르치는 건 좋다. 근데 “무엇을 만들지”를 결정하는 과정, 팀 안에서 의견을 조율하고 방향을 맞추는 능력 — 이건 커리큘럼에서 명시적으로 다루지 않는다. Andrew Ng이 말한 것처럼 PM과 엔지니어의 역할이 합쳐지는 추세라면, 사용자와 대화하고 공감하는 능력이 코딩보다 더 중요해진다. AI가 코드를 짜줘도, 방향을 결정하는 과정은 사람들 사이에서 일어난다.

도메인에 대한 관심. 의료, 법률, 교육, 금융 — 도메인 전문가가 AI와 결합했을 때 임팩트가 가장 크다. 코딩을 잘 아는 사람보다, 도메인을 깊이 아는 사람이 AI를 써서 무언가를 만들 때 더 날카로운 결과가 나온다. 커리큘럼은 AI 엔지니어링 기술에 집중하느라 도메인 사고를 기르는 부분이 빠져 있다.

한국 부트캠프와의 비교. 국내 N주 부트캠프는 대부분 “기초 문법 → 미니 프로젝트 → 팀 프로젝트 → 포트폴리오” 구조에서 벗어나지 못한다. CodePath 커리큘럼과 가장 큰 차이는 기존 코드베이스와의 접점이다. 1만 줄짜리 오픈소스 프로젝트를 받아서 파악하고, 거기에 PR을 넣는 경험. 이게 실무와 가장 가까운 훈련이다.

나가며

채용 시장이 어려워지는 건 여러 이유가 있지만 결국 AI Native Engineer 는 이제 이전의 소프트웨어 엔지니어와는 다른 자질을 요구하기 때문이다. “코드 작성 능력”이라는 해자가 사라졌기 때문에 “코드 작성 능력” 은 이제 경제적 가치가 없어졌다. 신입보다 시니어를 선호하는 것도 시니어들의 “코드 작성 능력”이 뛰어나서가 아니다. 그들의 도메인 독해 능력, 비즈니스 모델에 대한 이해, 사용자 요구 사항을 적정기술로 풀어내는 그들의 경험이 AI와 함께 증폭이 되는 것이다. 이러한 경험을 통한 “암묵지”는 쉽게 얻어지는게 아니다. 그렇기 때문에 이 커리큘럼의 오픈소스 PR 기여는 그 간극을 메우는 그나마 그 “암묵지” 모델에 가까운 과제가 아닌가 싶다.

그럼에도 불구하고 기초는 중요하다. 순서가 중요하다. 기초가 먼저다. AI는 그 위에 올라탄다. 기초가 없으면 AI는 날개가 아니라 무게가 된다. 빠르게 만들 수 있지만, 뭘 만드는지, 잘 만드는지 알 수가 없다. 인간의 사전 학습(기초, 경험)이 AI 활용 능력을 증폭시킨다는 건 Claude Code를 직접 만드는 Anthropic이 어쩌면 더 뼈저리게 느끼고 있는 부분이 아닐까.

AI 모델도 사전 학습량과 파라미터로 성능이 달라지듯이, 인간도 사전 학습에 따라서 성능이 천차만별일 것이다.

AI 시대에 진입 장벽은 낮아졌다. 확실히. 코딩을 전혀 모르는 사람도 뭔가를 만들어낼 수 있다. 근데 천장은 오히려 높아졌다. AI를 잘 쓰는 사람과 못 쓰는 사람의 격차가 이전의 “코딩 잘하는 사람 vs 못하는 사람”보다 훨씬 크다.

CodePath 커리큘럼이 가는 방향이 맞을까? 세상이 너무 빨리 변하고 있기 때문에, 커리큘럼은 계속 변할 것이다. 하지만 AI를 맹신하지 않는 훈련, 기존 코드베이스를 읽고 통합하는 훈련, 실전에 기여하는 훈련. 이 세 가지는 AI 시대에도, AI 이후에도 변하지 않는다.

그리고 이전 시대에도 일을 잘하는 사람이 AI 시대에도 일을 잘한다는 명제는 모두가 동의할 것이다.

References

함께 읽으면 좋은 글

Share this post on:
Share this post via WhatsAppShare this post on FacebookShare this post on ThreadsShare this post on XShare this post via TelegramShare this post on PinterestShare this post via email

댓글

Next Post
2026년 1, 2월을 보내며 - 회고 아님