스탠퍼드 CS146S로 배우는 AI와 함께하는 소프트웨어 개발

스탠퍼드 CS146S The Modern Software Developer의 2025년 가을 강좌 사이트와 첫 주 실라버스
목차

AI로 코드를 작성해봤다면 다음에는 무엇을 배워야 할까요. 원하는 기능을 설명하는 법, 에이전트에 프로젝트를 이해시키는 법, 만들어진 코드를 검토하는 법까지 궁금한 일이 이어집니다. 스탠퍼드 대학교의 CS146S, The Modern Software Developer는 이 질문들을 한 학기 안에서 다루는 소프트웨어 개발 강좌입니다.

출발은 프롬프트입니다. 이후에는 개발 도구를 연결하고, 작업을 나누고, 테스트와 코드 리뷰를 거쳐, 배포한 서비스의 문제를 살펴봅니다. AI와 함께 작은 기능을 만드는 경험을 개발 과정 전체로 넓혀가는 구성입니다.

공개된 자료로 공부를 시작할 수도 있습니다. 2025년 가을 강좌 사이트의 Syllabus에는 주차별 읽을거리, 슬라이드, 실습과 과제 링크가 연결되어 있습니다. 아래 설명은 이 2025년 가을 과정을 기준으로 합니다. 사이트에서 별도로 안내하는 2026년 가을 과정과는 구분해서 읽어주세요.

어떤 개발자를 위한 수업인가요

CS146S는 스탠퍼드의 정식 교과목 목록에 등록된 수업입니다. AI 도구를 사용해 기능을 구현하는 경험과 함께, 그 결과를 언제 신뢰할 수 있는지 판단하는 일을 다룹니다. 코드를 작성하는 속도뿐 아니라 디버깅, 검토, 유지보수까지 학습 범위에 들어갑니다.

프로그래밍을 해본 분이라면 자신의 작업과 연결해서 읽기 좋습니다. 예를 들어 테스트가 있는 작은 웹 앱을 떠올려보세요. 같은 앱에 기능을 추가하면서 프롬프트를 바꾸고, 필요한 도구를 연결하고, 수정 결과를 검증해볼 수 있습니다. 용어만 따로 외울 때보다 각 기술이 필요한 이유가 분명해집니다.

아래에서는 공식 실라버스의 10주 구성을 따라갑니다. 과제에서 요구하는 내용과 함께, 공부할 때 짚어볼 의미를 풀어 설명했습니다.

1주차 · LLM을 이해하고 프롬프트를 실험하기

출력 규칙만 요청한 프롬프트와 실제 예시를 더한 프롬프트의 비교.

출력 규칙만 요청한 프롬프트와 실제 예시를 더한 프롬프트의 비교. CS146S 강의 슬라이드

첫 주에는 대규모 언어 모델(LLM)의 기본과 프롬프트를 다룹니다. 실습은 Ollama로 모델을 로컬에서 실행하고, 주어진 문제를 풀도록 프롬프트를 조정하는 방식입니다. 모델을 바꾸기보다 요청을 바꿨을 때 결과가 어떻게 달라지는지 확인합니다.

과제에는 예시를 제시하는 K-shot prompting, 단계별 풀이를 유도하는 Chain-of-thought, 도구 호출, 여러 응답을 비교하는 Self-consistency, 검색한 자료를 활용하는 RAG, 결과를 돌아보고 개선하는 Reflexion이 포함됩니다. 이름을 외우기보다 각각 어떤 정보를 모델에 더해주는지 살펴보면 이해하기 쉽습니다.

가령 짧은 메모에서 할 일을 추출한다면, 원하는 출력 예시를 함께 줄 수 있습니다. 외부 문서가 필요한 질문에는 관련 자료를 먼저 찾아 전달할 수 있고요. 요청문만 자세히 쓰는 경우와 예시·자료·도구를 제공하는 경우의 차이를 직접 확인하는 연습입니다.

과제는 최종 프롬프트와 출력 결과를 남기도록 합니다. 나중에 다시 쓸 수 있도록, 잘된 요청과 실패한 요청의 차이도 함께 적어보세요. 한 번 그럴듯한 답을 얻는 것과 여러 입력에서 원하는 결과를 얻는 것을 구분하는 데 도움이 됩니다.

2주차 · 코딩 에이전트가 일하는 구조 이해하기

사용자, 코딩 에이전트, 언어 모델, 도구가 연결되는 구조.

사용자, 코딩 에이전트, 언어 모델, 도구가 연결되는 구조. CS146S 강의 슬라이드

두 번째 주의 강의 주제는 에이전트의 구성 요소, 도구 사용, 함수 호출, MCP입니다. 에이전트가 코드를 읽고 수정하려면 어떤 기능이 필요한지 다룹니다. 모델의 응답이 실제 파일 변경이나 프로그램 실행으로 이어지는 과정을 이해하는 단계입니다.

주차 과제에서는 Cursor를 사용해 메모에서 할 일을 추출하는 앱을 확장합니다. FastAPI와 SQLite로 만든 기본 앱에 LLM 기반 추출 기능을 더하고, 여러 입력을 검증하는 단위 테스트를 작성합니다. 코드 구조를 정리하고 API와 화면을 연결한 뒤 README도 만듭니다.

여기서 단위 테스트는 작은 기능이 예상대로 동작하는지 확인하는 코드입니다. 메모가 비어 있거나 문장 형식이 달라도 처리되는지 검사할 수 있습니다. 에이전트가 기능을 추가했다면, 그 변경을 이런 검사와 실제 화면으로 확인하는 경험이 함께 필요합니다.

이 과제에서는 사용한 프롬프트와 사람이 직접 고친 내용도 기록합니다. 완성된 앱만 보면 보이지 않는 작업 과정을 남기는 셈입니다. 어떤 요청은 한 번에 처리됐고 어떤 부분은 추가 설명이 필요했는지 비교해볼 수 있습니다.

3주차 · 프로젝트 맥락을 정리하고 MCP로 도구 연결하기

목표와 변경 파일, 테스트 등 에이전트에 전달할 작업 명세의 항목.

목표와 변경 파일, 테스트 등 에이전트에 전달할 작업 명세의 항목. CS146S 강의 슬라이드

세 번째 주에는 AI 개발 환경에서 프로젝트를 이해시키는 방법을 다룹니다. 컨텍스트는 모델이 작업할 때 참고하는 코드, 문서, 대화 등의 정보입니다. 어떤 기능을 만들지 설명한 제품 요구사항 문서(PRD)도 여기에 포함됩니다.

예를 들어 검색 기능을 맡긴다면 검색 대상, 정렬 순서, 결과가 없을 때의 화면을 정리해둘 수 있습니다. 관련 파일과 실행 방법까지 알려주면 에이전트가 확인해야 할 범위가 더 분명해집니다. 프로젝트 전체를 무조건 전달하기보다 이번 작업에 필요한 정보를 고르는 연습으로 접근해보세요.

과제는 실제 외부 API를 감싼 MCP 서버를 만드는 일입니다. MCP(Model Context Protocol)는 AI 애플리케이션이 도구와 데이터를 연결해 사용하는 규격입니다. 과제에서는 최소 두 개의 도구를 제공하고, 입력 항목과 오류 처리 방식을 설계합니다.

날씨 서비스를 예로 들면 현재 날씨를 가져오는 도구와 예보를 가져오는 도구를 나눌 수 있습니다. 요청이 실패하거나 결과가 없거나 응답이 늦을 때도 클라이언트가 상황을 이해할 수 있어야 합니다. 로컬 실행과 원격 실행 중 방식을 고르고, 설치·실행 안내와 실제 호출 예시를 남기는 것까지 과제에 들어갑니다.

4주차 · 반복 작업을 자동화하고 에이전트 역할 나누기

한 사람이 여러 에이전트의 작업을 관리하는 구성.

한 사람이 여러 에이전트의 작업을 관리하는 구성. CS146S 강의 슬라이드

네 번째 주에는 사람이 에이전트의 자율성을 어떻게 조절하고 협업할지 다룹니다. 매번 긴 요청을 다시 쓰는 대신, 자주 하는 작업을 일정한 절차로 만들어보는 단계입니다.

과제에서는 Claude Code의 사용자 정의 명령, 프로젝트 지침 파일, 역할별 하위 에이전트, MCP 연결 등을 활용해 최소 두 가지 자동화를 만듭니다. 테스트 실행, 문서 갱신, 코드 구조 개선처럼 개발 중 반복되는 작업이 대상입니다. 만든 자동화는 제공된 앱을 실제로 개선하는 데 사용합니다.

역할을 나누는 예로는 코드를 수정하는 에이전트와 테스트를 확인하는 에이전트를 둘 수 있습니다. 이때 각 역할이 받을 입력, 만들 결과, 다음 역할에 넘길 내용을 정해두면 작업 흐름을 설명하기 쉽습니다. 여러 에이전트를 쓰더라도 누가 최종 변경을 검토할지는 별도로 정할 수 있습니다.

제출 문서에는 실행 방법, 예상 결과, 안전하게 되돌리는 방법과 자동화 전후의 차이를 적습니다. 자동화를 만들었다는 사실보다, 반복하던 일을 어떻게 바꿨는지 확인하는 과제입니다.

5주차 · 터미널에서 여러 작업 조율하기

IDE, 터미널, 채팅처럼 익숙한 개발 환경에 AI 기능을 연결하는 관점.

IDE, 터미널, 채팅처럼 익숙한 개발 환경에 AI 기능을 연결하는 관점. CS146S 강의 슬라이드

다섯 번째 주에는 Warp를 사용해 터미널 중심의 개발을 연습합니다. 터미널은 명령을 입력해 프로그램을 실행하고 결과를 확인하는 환경입니다. 여기서는 그 환경 안에서 프롬프트와 규칙을 재사용하고 여러 에이전트의 작업을 조율합니다.

과제는 저장된 프롬프트·규칙·MCP 연결 중 하나 이상을 사용하고, 여러 에이전트가 독립된 작업을 동시에 수행하도록 요구합니다. 제공된 앱에서 두 개 이상의 작업을 고르고, 각각 어떤 자동화를 사용했는지 기록합니다.

함께 공부한다면 한 작업은 문서를 정리하고 다른 작업은 별도 기능의 테스트를 작성하도록 나눠볼 수 있습니다. 두 작업이 같은 파일을 수정해야 한다면 순서를 정하거나 변경을 합치는 단계를 마련해야 합니다. 작업을 많이 시작하는 것만으로는 최종 결과가 정리되지 않기 때문입니다.

보고서에는 자율성 수준과 감독 방법, 역할 분담, 동시 작업에서 얻은 이점과 실패를 남깁니다. 도구를 바꿨을 때 자신의 개발 절차 중 무엇을 그대로 사용할 수 있고 무엇을 다시 설계해야 하는지 비교해볼 만합니다.

6주차 · AI가 만든 코드의 보안 문제 확인하기

소스 코드와 바이너리를 검사하는 정적 보안 분석(SAST)의 설명.

소스 코드와 바이너리를 검사하는 정적 보안 분석(SAST)의 설명. CS146S 강의 슬라이드

여섯 번째 주에는 테스트와 보안을 다룹니다. 기능이 실행된다는 확인에 더해, 입력을 처리하는 방식이나 데이터 접근에 문제가 없는지 살펴보는 단계입니다.

과제에서는 Semgrep으로 제공된 앱을 분석하고 최소 세 가지 보안 문제를 수정합니다. 정적 분석은 프로그램을 실행하지 않고 코드의 구조와 패턴을 검사하는 방법입니다. 검사 결과를 읽고 어떤 문제를 먼저 고칠지 판단한 뒤, AI 코딩 도구를 사용해 수정합니다.

수정 내용에는 무엇이 위험했는지와 변경이 그 위험을 어떻게 줄이는지 설명해야 합니다. 도구가 표시한 항목 중 실제 문제가 아니라고 판단한 내용도 이유를 기록합니다. 검사 결과를 전부 그대로 받아들이기보다, 코드와 실행 조건을 함께 읽는 연습입니다.

수정 후에는 보안 검사를 다시 실행하고 앱과 기존 테스트가 계속 동작하는지도 확인합니다. 보안 문제를 해결하는 과정에서 원래 기능을 깨뜨리지 않았는지까지 보는 것입니다.

7주차 · 사람의 코드 리뷰와 AI 리뷰 비교하기

짧은 판정과 이유·개선 방향을 담은 코드 리뷰 의견의 비교.

짧은 판정과 이유·개선 방향을 담은 코드 리뷰 의견의 비교. CS146S 강의 슬라이드

일곱 번째 주에는 코드 리뷰를 중심으로 개발 결과를 검토합니다. 코드 리뷰는 변경 내용을 읽고 정확성, 유지보수성, 빠진 검사 등을 확인하는 과정입니다.

과제에서는 기능별 브랜치를 만들고 AI 도구로 변경을 구현합니다. 사람이 먼저 코드를 한 줄씩 검토한 뒤, 변경을 합치기 위한 요청인 풀 리퀘스트(PR)를 작성합니다. 이어서 Graphite의 AI 리뷰를 받아 자신의 검토 내용과 비교합니다.

PR에는 해결하려는 문제, 접근 방법, 테스트 명령과 결과, 한계 등을 설명합니다. 리뷰를 받는 사람이 코드만 보고 작업 의도를 추측하지 않아도 되도록 맥락을 정리하는 연습이기도 합니다.

비교할 때는 댓글 수보다 지적한 내용을 살펴보면 좋습니다. 사람이 발견한 오류를 AI도 찾았는지, AI가 추가로 찾은 문제는 실제로 수정할 필요가 있었는지 확인해보세요. 과제 역시 구체적인 사례를 들어 어느 상황에서 AI 리뷰를 신뢰할지 돌아보도록 합니다.

8주차 · 같은 앱을 세 가지 기술 구성으로 만들기

앱 제작 강의에서 소개하는 WebContainer와 브라우저 실행 환경.

앱 제작 강의에서 소개하는 WebContainer와 브라우저 실행 환경. CS146S 강의 슬라이드

여덟 번째 주에는 UI와 앱 제작을 다룹니다. 과제는 같은 기능을 갖춘 웹 앱을 서로 다른 세 가지 기술 구성으로 만드는 일입니다. 적어도 하나는 bolt.new를 사용하고, 하나는 프런트엔드나 백엔드에 JavaScript 이외의 언어를 포함해야 합니다.

앱에는 데이터를 만들고, 읽고, 수정하고, 삭제하는 기능이 필요합니다. 저장 기능과 기본적인 입력 검사, 오류 처리, 주요 흐름을 사용할 수 있는 화면도 갖춰야 합니다. 화면이 생성된 뒤 실제 사용 과정까지 연결하는 과제입니다.

예를 들어 메모 앱을 고르면 세 버전 모두에서 같은 메모를 작성하고 수정하는 흐름을 확인할 수 있습니다. 기능을 같게 유지하면 프레임워크 차이와 AI 도구의 결과를 비교하기 쉬워집니다. 어느 버전에서 요구사항을 더 자세히 설명해야 했는지, 생성 후 어떤 부분을 직접 고쳤는지도 기록해볼 수 있습니다.

제출물에는 각 버전의 코드와 실행 안내, 알려진 문제, 수동으로 수정한 내용을 남깁니다. 새로운 기술을 접할 때도 결과를 직접 실행하고 설명할 수 있어야 한다는 기준을 적용합니다.

9주차 · 배포 후 서비스 상태 살펴보기

운영 중인 서비스 사이의 의존 관계를 보여주는 Resolve.ai 화면.

운영 중인 서비스 사이의 의존 관계를 보여주는 Resolve.ai 화면. CS146S 강의 슬라이드

아홉 번째 주에는 모니터링, 관측 가능성, 장애 대응을 다룹니다. 관측 가능성은 로그와 지표 같은 단서를 사용해 시스템 내부에서 무슨 일이 일어나는지 파악하는 능력입니다. 배포한 서비스가 계속 잘 동작하는지 확인하는 데 필요합니다.

예를 들어 특정 시간부터 요청이 느려졌다고 가정해보세요. 최근 배포 시점, 오류 로그, 응답 시간 변화를 함께 확인하면 원인을 좁힐 수 있습니다. 에이전트에 자료 정리와 원인 후보 비교를 맡기더라도, 어떤 근거로 판단했는지 확인할 수 있어야 합니다.

이 주차의 주제를 공부할 때는 읽기와 변경을 나눠보면 좋습니다. 로그를 요약하는 작업과 운영 설정을 바꾸는 작업은 결과가 다릅니다. 조사 결과를 먼저 받고, 실제 복구 조치는 영향과 되돌릴 방법을 확인한 뒤 실행하는 흐름을 설계해볼 수 있습니다. 이 예시는 실라버스의 장애 대응 주제를 자신의 서비스에 적용해보기 위한 연습입니다.

10주차 · 앞으로 개발자가 맡을 일 생각하기

개발 팀과 에이전트의 역할 변화를 설명하는 4주차 강의의 도식.

개발 팀과 에이전트의 역할 변화를 설명하는 4주차 강의의 도식. CS146S 강의 슬라이드

마지막 주에는 소프트웨어 개발 역할의 변화와 새로운 AI 코딩 방식, 산업의 전망을 다룹니다. 앞선 실습을 돌아보며 사람이 계속 판단해야 할 일이 무엇인지 생각해볼 수 있습니다.

자신이 만든 앱을 기준으로 정리해보세요. 요구사항을 정할 때 어떤 설명이 필요했는지, 생성된 코드에서 무엇을 직접 고쳤는지, 테스트와 리뷰에서 어떤 문제를 발견했는지 적는 방식입니다. 도구 이름만 나열하는 것보다 자신의 개발 과정에서 달라진 일을 구체적으로 볼 수 있습니다.

앞으로의 변화를 모두 예측할 필요는 없습니다. 다음 프로젝트에서도 유지할 작업 기준을 골라보는 것부터 시작할 수 있습니다. 작은 단위로 일을 맡기기, 변경 이유를 남기기, 실행 결과로 확인하기처럼 실제로 도움이 된 절차를 정리해보세요.

공개 자료로 시작해보기

처음부터 한 학기 분량을 모두 따라가려 하면 준비할 도구가 많게 느껴질 수 있습니다. 우선 공개 과제 저장소에서 첫 주의 프롬프트 실험을 읽어보세요. 이미 AI로 기능을 만들고 있다면 6주차의 보안 검사나 7주차의 코드 리뷰 비교부터 자신의 작업과 연결해볼 수도 있습니다.

과제 안내에는 당시 수업에서 사용한 도구와 학생용 이용 조건도 포함되어 있습니다. 실습을 시작할 때는 현재 설치 방법과 계정 조건을 확인해주세요. 공개 자료를 읽으며 공부하는 것과 정식 수강·학점 취득은 구분됩니다.

작은 기능 하나를 골라 요청문, 변경한 코드, 검증 결과를 함께 남겨보세요. CS146S의 여러 주제가 실제 개발 과정에서 어떻게 이어지는지 확인하는 출발점이 될 수 있습니다.

댓글

0

아직 공개된 댓글이 없습니다.