빌더를 위한 완성형 컴퓨터 과학 로드맵

지도를 다 외울 필요는 없습니다.

필요한 것은 경로입니다.

좋은 컴퓨터 과학 로드맵은 세 가지를 알려줘야 합니다.

1. 무엇을 먼저 배울지.
2. 무엇을 나중으로 미뤄도 되는지.
3. 어떤 프로젝트를 만들면 개념이 실제 실력으로 바뀌는지.

이 로드맵은 빌더를 위한 것입니다. 학문적인 순서가 아니라, 실제 소프트웨어를 만들 때 가장 빨리 효과가 나는 순서입니다.

이 시리즈를 읽는 방법

이 페이지를 중심 페이지로 활용하세요.

배포 관련 내용은 바이브 코더를 위한 배포 가이드와 함께 보면 좋습니다.

로드맵 한눈에 보기

주제가 아니라 단계로 생각하세요.

의존 관계는 단순합니다.

0단계: 방향 잡기

깊게 들어가기 전에 먼저 해야 할 일입니다.

네 동네를 쉬운 말로 설명할 수 있어야 합니다.

• 자료구조: 데이터를 찾고, 바꾸고, 묶고, 연결하기 위해 어떻게 담는가.
• 알고리즘: 프로그램이 어떤 절차를 따르고, 데이터가 늘 때 그 절차가 어떻게 변하는가.
• 시스템 설계: 클라이언트, 서버, API, 데이터베이스, 캐시, 큐, 외부 서비스가 어떤 모양으로 연결되는가.
• 개발 프로세스: Git, 리뷰, 테스트, CI/CD, 부채 관리처럼 소프트웨어를 계속 바꿀 수 있게 만드는 습관.

체크포인트:

• 버그나 느린 기능을 보면 어느 동네 문제인지 대략 짐작할 수 있다.
• 어떤 개념을 배우기 전에 왜 배우는지 설명할 수 있다.
• 배운 것을 적용할 실제 프로젝트가 하나 있다.

1단계: 코드 이해력

여기서 시작하세요. 코드를 읽는 눈이 바로 달라집니다.

배울 것:

• 배열과 리스트.
• 해시맵과 집합(Set).
• 스택과 큐.
• 트리와 그래프.
• Big O.
• 이진 탐색.
• 재귀.

모든 자료구조를 외우려 하지 마세요. 실전 질문을 익히면 됩니다.

이 데이터를 어떻게 담아야 앱이 불필요한 일을 하지 않고 찾고, 바꾸고, 연결할 수 있을까?

실습:

다음 단계로 넘어갈 준비:

• 위험해 보이는 중첩 반복문을 알아볼 수 있다.
• 반복해서 전체를 훑는 것보다 바로 조회하는 구조가 왜 빠른지 설명할 수 있다.
• 흔한 앱 문제에서 배열, 해시맵, 큐, 트리, 그래프 중 무엇을 쓸지 고를 수 있다.
• 코드가 대략 O(1), O(log n), O(n), O(n²) 중 어디에 가까운지 추정할 수 있다.

2단계: 웹앱 기본기

대부분의 빌더에게는 고급 알고리즘보다 이 단계가 먼저 필요합니다.

배울 것:

• HTTP 메서드, 상태 코드, 헤더, 요청 본문, 응답 본문.
• REST(Representational State Transfer, 웹 API를 설계하는 흔한 방식) 기본기와 GraphQL/RPC(Remote Procedure Call, 원격 함수 호출)가 도움 되는 상황.
• JSON(JavaScript Object Notation, 데이터를 주고받는 가벼운 형식)과 기본 직렬화.
• SQL(Structured Query Language) vs NoSQL(Not Only SQL).
• 테이블, 문서, 인덱스, 마이그레이션, 쿼리 구조.
• 인증과 인가.
• 세션, JWT(JSON Web Token), OAuth(외부 로그인·권한 위임 표준), 역할, 권한.
• 비밀값과 환경 변수.

실전 질문:

브라우저 클릭부터 데이터베이스 쓰기, 다시 응답이 돌아오는 흐름을 그릴 수 있는가?

실습:

다음 단계로 넘어갈 준비:

• 요청 흐름을 추측이 아니라 설명으로 그릴 수 있다.
• 비밀값이 어디에 있어야 하고 어디에 있으면 안 되는지 안다.
• 인증과 인가의 차이를 설명할 수 있다.
• 앱이 소유한 주요 테이블/문서를 말할 수 있다.
• 앱에서 위험한 엔드포인트를 찾을 수 있다.

3단계: 안전한 작업 흐름

이 단계는 다른 사람과 일하거나, 미래의 나와 일하기 위한 단계입니다.

배울 것:

• Git 브랜치, 커밋, 풀 리퀘스트(PR), 병합, 되돌리기.
• 위험을 줄이는 장치로서의 코드 리뷰.
• 단위 테스트, 통합 테스트, E2E(End-to-End, 사용자 흐름 전체) 테스트.
• 모킹과 테스트 데이터.
• CI/CD 기본기.
• 롤백까지 고려하는 사고.
• 기술 부채 추적.
• 모듈, 계층, 경계, MVC(Model-View-Controller)식 분리 같은 기본 코드 구조화.

실전 질문:

이 앱을 바꿔도 다음 변경이 더 어렵거나 더 위험해지지 않는가?

실습:

다음 단계로 넘어갈 준비:

• 작은 브랜치 단위로 프로젝트를 바꿀 수 있다.
• 위험한 흐름 주변에 테스트가 있다.
• 잘못된 변경을 되돌리거나 롤백하는 방법을 안다.
• 기억에 의존하지 않고 부채 목록을 관리한다.
• AI에게 코드 생성만이 아니라 PR 리뷰를 요청할 수 있다.

4단계: 프로덕션 준비

데모는 한 번만 잘 되면 됩니다.

프로덕션 앱은 사용자, 데이터, 비용, 실패가 늘어도 계속 버텨야 합니다.

배울 것:

• 배포 기본기: 빌드, 환경 변수, 도메인, 로그, 롤백.
• 컨테이너, 서버리스, 관리형 서비스를 실용적인 수준에서 이해하기.
• 캐싱, 백그라운드 작업, 큐, 재시도, 멱등성.
• 로깅, 지표, 추적, 알림.
• 성능 프로파일링과 측정.
• 느린 쿼리 로그와 쿼리 계획.
• 호출 제한과 API 할당량.
• 보안 기본기: OWASP(Open Web Application Security Project) Top 10, 입력값 검증, XSS(Cross-Site Scripting), CSRF(Cross-Site Request Forgery), SQL injection(SQL 삽입 공격), 의존성 위험.
• AI 특화 운영 위험: 토큰 비용, 모델 지연 시간, 호출 제한, 재시도, 프롬프트 인젝션, 데이터 유출.

실전 질문:

사용자, 데이터, AI 호출이 10배 늘면 무엇이 먼저 깨질까?

실습:

다음 단계로 넘어갈 준비:

• 직접 클릭하지 않아도 앱이 건강한지 알 수 있다.
• 어떤 엔드포인트, 작업, AI 호출이 가장 먼저 실패할지 짐작할 수 있다.
• 기본 로그, 지표, 알림이 있다.
• 의도적으로 배포하고 롤백할 수 있다.
• 예측 가능한 운영 실패를 잡는 자동 검사가 있다.

5단계: 더 깊은 컴퓨터 과학

여기서부터 지도는 넓어집니다.

한 번에 다 공부하지 마세요. 프로젝트가 필요를 만들 때 고르면 됩니다.

30일 스타터 플랜

첫 달은 작동하는 감각을 만드는 기간입니다.

90일 빌더 로드맵

다음 두 달은 앱을 더 안전하고 명확한 운영 가능한 상태로 만드는 기간입니다.

90일이 끝나면 최소한 이런 프로젝트가 있어야 합니다.

• 인증과 권한.
• 영속적인 데이터.
• 위험한 흐름 하나 이상의 테스트.
• 의도적인 배포 경로.
• 기본 로깅 또는 모니터링.
• 기술 부채 목록.
• 프로덕션 가드레일 하나.

6개월 로드맵

실전 깊이를 만드는 경로입니다.

목표는 6개월 안에 컴퓨터 과학을 끝내는 것이 아닙니다. 머릿속에 찾아볼 색인을 만드는 것입니다. 무언가 깨졌을 때 어디를 봐야 할지 아는 상태가 목표입니다.

프로젝트 사다리

프로젝트가 로드맵을 몸에 붙입니다.

프로젝트 하나를 고르세요. 같은 프로젝트를 단계별로 계속 개선하세요. 매주 새 튜토리얼을 시작하는 것보다, 하나의 앱을 더 현실적인 제약까지 밀고 가는 편이 더 많이 배웁니다.

언제 깊게 들어갈까

막히는 지점을 학습의 신호로 삼으세요.

지금은 건너뛰어도 되는 것

로드맵은 무엇을 배울지 정하는 도구이기도 하지만, 그보다 더 중요하게는 아직 배우지 않아도 되는 것을 걸러내는 도구입니다.

모든 기술을 미리 배울 필요는 없습니다. 그 기술이 필요한 문제가 실제로 나타나기 전까지는 미뤄도 괜찮습니다.

• 배포나 확장 문제가 생기기 전의 Kubernetes.
• 팀이나 도메인 복잡도가 생기기 전의 마이크로서비스.
• 그래프 문제가 생기기 전의 고급 그래프 알고리즘.
• 분산 시스템을 운영하기 전의 분산 합의.
• 언어와 런타임 동작이 중요해지기 전의 컴파일러 내부 구조.
• 검증된 라이브러리 대신 직접 만드는 암호화/인증.
• 측정하기 전의 성능 최적화.
• 실제 사용자나 사용량이 없는 상태에서 끝없이 보는 튜토리얼.

AI로 공부하는 방법

AI는 코드를 만들게 할 때보다 개념을 설명하게 할 때 로드맵을 더 빨리 익히게 해줍니다.

이 루프를 따라가세요.

1. 만들다가 막히는 지점까지 갑니다.
2. 막히는 지점에 이름을 붙입니다.
3. 지도 위 어디인지 찾습니다.
4. 그 문제를 설명하는 가장 작은 개념을 배웁니다.
5. 바로 적용합니다.
6. 결과를 측정하거나 리뷰합니다.
7. 배운 것을 내 말로 기록합니다.

튜토리얼을 몰아보는 것보다 느려 보이지만, 훨씬 잘 쌓입니다.

자주 묻는 질문

개발을 위해 컴퓨터 과학을 배우는 데 얼마나 걸리나요?

모든 것을 배울 필요는 없습니다. 대부분의 빌더는 30일에서 90일의 집중적이고 프로젝트 중심 학습으로 실무 기초를 다룰 수 있습니다.

무엇부터 배워야 하나요?

먼저 프로젝트에서 느끼는 고통과 맞닿은 자료구조와 알고리즘부터 시작하고, 앱에 사용자가 생기면 시스템 설계와 프로세스로 확장하세요.

고급 알고리즘을 배워야 하나요?

실제로 그것이 필요한 문제가 생기기 전까지는 필요하지 않습니다. 대부분의 프로덕션 앱은 고급 알고리즘보다 자료구조 선택, API 설계, 데이터베이스 쿼리에서 병목이 생깁니다.

튜토리얼 과잉을 어떻게 피하나요?

지금 만들고 있는 프로젝트와 연결되지 않은 튜토리얼은 그만 보세요. 현재 막힘을 제거하는 가장 작은 개념만 배우고 바로 적용한 뒤, 다음 개념을 찾으세요.

프레임워크와 컴퓨터 과학 중 무엇을 먼저 배워야 하나요?

둘을 함께 배우세요. 프레임워크로 만들다가 성능, 구조, 프로세스 문제를 만나면 그 문제를 설명하는 컴퓨터 과학 개념을 그때 배웁니다.

최소 컴퓨터 과학 체크리스트

AI 코딩 도구로 만든다면 이 체크리스트를 가까이 두세요.

• 배열, 해시맵, 큐, 트리, 그래프를 예시로 설명할 수 있다.
• 위험해 보이는 중첩 반복문을 알아볼 수 있다.
• 반복해서 전체를 훑는 것보다 바로 조회하는 구조가 왜 빠른지 설명할 수 있다.
• 브라우저 → API → 서버 → 데이터베이스 요청 흐름을 그릴 수 있다.
• 인증과 인가의 차이를 안다.
• 비밀값이 어디에 있어야 하는지 안다.
• 백그라운드 작업이나 큐가 언제 필요한지 안다.
• Git 브랜치와 커밋을 의도적으로 쓴다.
• 위험한 로직 주변에 어떤 테스트가 필요한지 안다.
• 의도적으로 배포하고 롤백할 수 있다.
• 배포 후 기본 로그, 지표, 오류를 찾을 수 있다.
• 기술 부채를 기억에 의존하지 않고 추적한다.
• AI에게 코드만 요구하지 않고 개념, 위험, 트레이드오프 설명을 요구한다.

핵심 정리

컴퓨터 과학을 끝내야 하는 것이 아닙니다. 루프가 필요합니다.

막힐 때까지 만듭니다. 막힘에 이름을 붙입니다. 지도 위에 둡니다. 가장 작고 유용한 개념을 배웁니다. 적용하고, 측정하고, 기록합니다. 반복합니다.