README.md 파일 단 하나(505줄), 그 안에 "데이터베이스를 밑바닥부터 만드는 법", "Git을 직접 구현하는 법", "3D 렌더러를 짜는 법" 같은 튜토리얼 링크 359개가 30개 카테고리로 분류돼 있다.
GitHub 트렌딩 순위표에 누적 129번 오른, 역사상 가장 많이 트렌딩된 저장소이기도 하다.
이 문서는 저장소를 직접 클론해 실제 파일 구성·항목 수·언어 분포·거버넌스까지 뜯어보고, 그보다 중요한 질문 — "왜 코드 한 줄 없는 링크 모음이 10년째 상위권인가", 그리고 "이걸 어떻게 써야 실력이 느는가" — 에 답한다.
(저장소: codecrafters-io/build-your-own-x · 순수 마크다운 · CC0 퍼블릭 도메인 · 최신 커밋 2026-07-14 · TrendShift Daily #4)
"당신이 매일 쓰는 기술을 밑바닥부터 다시 만들어보는 튜토리얼 359개를, 만들 대상별로 분류해 놓은 큐레이션 저장소."
이름 build-your-own-x의 x는 변수다. x 자리에 Database, Git, Docker, Shell, Web Server, Neural Network, Programming Language, Operating System 같은 것이 들어간다. 즉 "당신만의 ___를 만들어보라"는 문장 틀이고, README는 그 빈칸을 채운 30가지 목록이다.
대부분의 프로그래밍 강의는 운전면허를 준다. React 쓰는 법, PostgreSQL 쿼리 짜는 법, Docker로 배포하는 법 — 도구를 사용하는 훈련이다. 이걸로 취업도 되고 제품도 만든다.
그런데 왜 이 쿼리가 느린지, 왜 컨테이너가 이런 식으로 격리되는지는 설명하지 못한다. 그건 분해해 본 사람만 안다.
build-your-own-x는 분해 정비 매뉴얼 모음이다. "Docker를 500줄 Go 코드로 직접 만들어보기"를 한 번 하면, Docker가 사실 리눅스 커널의 namespace·cgroup을 묶은 얇은 껍데기라는 게 지식이 아니라 감각으로 남는다.
| 지표 | 값 | 의미 |
|---|---|---|
| GitHub 트렌딩 등재 | 누적 129회 | Trendshift 집계 전체 저장소 중 1위. 2위 lobehub(81회)와 격차가 크다 |
| TrendShift Daily | #4 (2026-07-18) | 10년 된 저장소가 오늘 나온 신작들 사이에 껴 있다 |
| 수록 튜토리얼 | 359개 | 상단 목차 링크 30개를 제외한 순수 항목 수 |
| 카테고리 | 30개 + 미분류 62개 | 3D 렌더러부터 프로세서(Verilog)까지 |
| 저장소 파일 수 | 4개 | README.md, ISSUE_TEMPLATE.md, 배너 png, .gitattributes |
| README 크기 | 505줄 / 46.7KB | 이게 저장소의 사실상 전부다 |
| 최근 1년 커밋 | 30개 | 월 2~3건. 느리지만 끊기지 않는 큐레이션 |
| 라이선스 | CC0 | 저작권 포기(퍼블릭 도메인 헌정). 복제·재배포 자유 |
흥미로운 대목은 다시 뜨는 시점이다. AI 코딩 에이전트가 코드를 대신 짜주는 게 당연해진 2026년에, "밑바닥부터 직접 만들어보라"는 저장소가 트렌딩 상위에 오른다.
AI가 코드를 써 주면 코드를 타이핑하는 능력의 값어치는 떨어진다. 반대로 AI가 내놓은 코드가 맞는지 판단하는 능력의 값어치는 올라간다.
"이 스키마 설계가 왜 문제인지", "이 락(lock) 처리가 왜 데드락을 부르는지"를 판단하려면 원리를 알아야 한다. 그런데 원리는 AI에게 물어서 얻는 설명보다, 직접 만들다 깨져 본 경험으로 훨씬 단단하게 박힌다.
실제로 README 미분류 섹션에는 build-your-own-x-vibe-coding(BYOX 튜토리얼을 AI 코딩용으로 재구성한 프로젝트)이 등록돼 있다 — 저장소 자체가 AI 시대에 맞춰 재해석되는 중이다.
| 저장소 | 분류 축 | 차이 |
|---|---|---|
| build-your-own-x | 만들 대상별 | "무엇을 만들까"에서 출발. 목표가 구체적이고 완주 판정이 쉽다 |
| project-based-learning | 언어별 | "이 언어로 뭘 해볼까"에서 출발. 언어를 이미 정한 사람에게 유리 |
| free-programming-books | 책·문서 | 읽는 자료 중심. 손을 움직이는 강제력이 약하다 |
| system-design-primer | 설계 이론 | 큰 시스템을 설계하는 관점. 구현 디테일은 다루지 않는다 |
| ossu/computer-science | 학위 커리큘럼 | 강의 수강 순서. 이론이 두껍고 기간이 길다(수년) |
즉 build-your-own-x의 자리는 "이론서는 지루하고, 튜토리얼 따라치기는 남는 게 없을 때"의 중간 지대다. 항목 하나가 대체로 주말 하나~2주 분량이라 완주 성공률이 높다.
아니다. 클론해도 나오는 건 README 하나다. 여기서 얻는 건 어디로 갈지 알려주는 지도이지 도착지 자체가 아니다. 실제 학습은 링크된 외부 블로그·책·저장소에서 일어난다.
그래서 "스타만 눌러두고 안 보는 북마크"가 되기 아주 쉽다. 대응책은 8번 섹션에 정리했다.
원저자는 Daniel Stefanovic(2016년 시작), 현재 유지관리는 CodeCrafters, Inc.가 맡고 있다. CodeCrafters는 "Redis를 직접 만들어보기", "Git을 직접 만들어보기" 같은 유료 챌린지를 파는 회사다.
큐레이션의 방향성과 회사 상품이 같은 축에 있다. 나쁘게 볼 일은 아니지만 — README 상단 배너가 광고라는 점, 무료 링크만으로도 충분히 학습 가능하다는 점을 알고 쓰면 된다. 라이선스가 CC0라 누구든 포크해 자기 버전을 만들 수도 있다.
이 저장소에는 백엔드도, 프론트엔드도, 인프라도, 빌드 시스템도 없다. 클론해서 확인한 실제 구성은 이게 전부다.
| 계층 | 실제 내용 |
|---|---|
| 백엔드 | 없음. 서버 코드 0줄 |
| 프론트엔드 | 없음. GitHub의 마크다운 렌더러가 곧 UI |
| 인프라 | 없음. github.com 호스팅에 전적으로 의존 |
| 빌드/CI | 없음. .github/ 디렉토리 자체가 존재하지 않는다 |
| 테스트 | 없음. 링크 유효성 검사 자동화조차 없다 |
| 패키지 매니저 | 없음. package.json·requirements.txt 등 일절 없음 |
| 있는 것 | README.md, ISSUE_TEMPLATE.md, codecrafters-banner.png, .gitattributes |
50만 스타짜리 프로젝트의 "기술 스택"이 텍스트 파일 하나라는 사실 자체가 배울 점이다.
가치는 코드의 양이 아니라 정리된 판단에서 나온다. 어떤 튜토리얼이 좋은지 고르고, 어떤 카테고리로 묶을지 정하고, 10년간 그 기준을 유지하는 것 — 자동화할 수 없는 일이 이 저장소의 본체다.
README에서 **언어**: 태그를 추출해 집계한 결과(슬래시 복수 표기는 분리해 카운트):
| 순위 | 언어 | 빈도 | 주로 등장하는 영역 |
|---|---|---|---|
| 1 | Python | 73 | 신경망, AI 모델, 검색엔진, 인터프리터 |
| 2 | JavaScript | 55 | 프론트엔드 프레임워크, 게임, 봇, 템플릿 엔진 |
| 3 | C | 50 | 운영체제, 셸, 에뮬레이터, 메모리 할당기 |
| 4 | C++ | 33 | 3D 렌더러, 물리 엔진, 데이터베이스 |
| 5 | Go | 23 | Docker, 웹서버, 블록체인, DB |
| 6 | Rust | 17 | OS, 텍스트 에디터, 인터프리터 |
| 7 | Node.js / C# | 15 / 15 | 봇·CLI / 게임(Unity)·AR |
| 9 | Ruby | 13 | 인터프리터, 웹 프레임워크 |
| 10 | Java | 10 | 프로그래밍 언어, 게임 |
| 11~15 | Nim(9) · Haskell(6) · TypeScript(5) · PHP(5) · any(4) | — | — |
실무 인기 순위였다면 TypeScript가 훨씬 위에 있어야 한다. 그런데 여기선 C(50)가 TypeScript(5)의 10배다. "밑바닥"을 파려면 결국 메모리·시스템콜과 직접 만나는 언어로 내려가야 하기 때문이다.
거꾸로 말하면 — 이 저장소를 제대로 쓰려면 C를 읽을 줄 아는 정도의 근력이 큰 무기가 된다.
| 카테고리 | 개수 | 카테고리 | 개수 |
|---|---|---|---|
| Programming Language | 41 | Git | 7 |
| Game | 34 | Physics Engine | 7 |
| Blockchain / Crypto | 21 | Shell | 7 |
| Operating System | 19 | Augmented Reality | 6 |
| Neural Network | 17 | Docker | 6 |
| Bot | 15 | Search Engine | 6 |
| Front-end Framework | 14 | Text Editor | 6 |
| Database | 13 | BitTorrent Client | 5 |
| Emulator / VM | 13 | Template Engine | 5 |
| 3D Renderer | 11 | Network Stack | 4 |
| Web Server | 11 | AI Model | 3 |
| Command-Line Tool | 9 | Visual Recognition | 2 |
| Regex Engine | 9 | Web Browser | 2 |
| Distributed Systems | 1 | Memory Allocator | 1 |
| Processor | 1 | Voxel Engine | 1 |
| Uncategorized | 62 | 합계 | 359 |
분포에서 읽히는 것: Programming Language(41)와 Game(34)이 압도적이다. 인터프리터/컴파일러 제작은 "밑바닥 학습"의 고전이고, 게임은 결과가 눈에 보여서 완주 동기가 강하다. 반대로 Distributed Systems가 단 1개인 건 — 분산 시스템은 주말에 만들어볼 크기가 아니라는 뜻이기도 하다.
콘텐츠를 복사해 담지 않고 링크만 건다. 덕분에 저장소는 46KB로 유지되고, 원저작자의 저작권 문제도 피한다. 대신 원본 사이트가 사라지면 항목이 죽는 링크 부패(link rot)를 떠안는다.
이 저장소는 링크 체커 자동화가 없어서, 죽은 링크는 사용자 이슈 제보로만 발견된다. 359개 링크를 사람이 지켜보는 구조다.
파일을 카테고리별로 쪼개지 않고 README 하나에 몰아넣은 뒤, 상단 목차에서 #build-your-own-database 같은 앵커(anchor)로 점프시킨다. 정적 사이트 생성기도, 검색 인덱스도 필요 없다 — 브라우저의 Ctrl+F가 곧 검색 기능이다.
가장 최근 커밋(2026-07-14)이 바로 "AI Model 섹션의 앵커 링크 오류 수정"이라는 점이 이 구조의 취약점을 보여준다. 헤더 텍스트를 바꾸면 앵커가 조용히 깨진다.
모든 항목이 예외 없이 같은 틀을 지킨다. 이 일관성이 사람 눈에도, 스크립트에도 파싱 가능한 사실상의 데이터베이스를 만든다.
* [**C++**: _Introduction to Ray Tracing_](https://www.scratchapixel.com/...)
* [**Python**: _A Large Language Model (LLM)_](https://github.com/rasbt/LLMs-from-scratch)
* [**C#**: _AR App Tutorial with Vuforia and Unity 3D_](https://youtube.com/...) [video]
구조: * [ + **언어** + : _제목_ + ](URL) + 선택적 [video]. 언어가 여럿이면 **C# / TypeScript**처럼 슬래시로 잇는다. 3절의 언어 통계도 이 규약 덕분에 grep 몇 줄로 뽑을 수 있었다.
클론해서 확인한 사실: CONTRIBUTING.md도 .github/도 존재하지 않는다. CI, 링크 체커, 자동 라벨링 전부 없다. 있는 건 ISSUE_TEMPLATE.md(카테고리 체크리스트)와 README의 ## Contribute 문단뿐이다.
월 2~3건 커밋 규모라면, CI 파이프라인을 짜고 유지하는 비용이 사람이 직접 보는 비용보다 크다. "규모에 맞는 최소 도구"를 고른 것에 가깝다.
다만 링크 체커만큼은 있는 편이 나았을 것이다. 359개 외부 링크 중 몇 개가 죽어 있는지 아무도 모르는 상태이기 때문이다 — 이건 8번 섹션의 실습 과제로 만들어 두었다.
미분류 항목이 6분의 1이나 된다. 분류 체계가 새 항목의 유입 속도를 못 따라가고 있다는 신호다. 좋은 자료가 이 더미에 묻혀 발견되지 않을 수 있으니, 훑어볼 때 Uncategorized 섹션을 일부러 뒤져보는 것이 오히려 남는 장사다.
| 배울 것 | 구체적 교훈 |
|---|---|
| 큐레이션의 가치 | 코드 0줄로 50만 스타. 정보 과잉 시대에 골라내는 일이 만드는 일만큼 가치 있다 |
| 포맷 규약 설계 | 359개 항목이 같은 문법을 지키니 grep 한 줄로 통계가 나온다. 규약은 스키마다 |
| 최소 도구주의 | 월 2~3커밋 프로젝트에 CI를 붙이지 않는 판단. 도구는 규모에 맞춰야 한다 |
| 링크 부패 관리 | 참조형 콘텐츠의 숙명. 자동 검사 없이 버티면 어떻게 되는지 관찰할 수 있는 사례 |
| CC0 선택 | 라이선스를 없애다시피 해서 확산을 극대화한 전략 |
Shell(7개)부터 시작한다. fork()·exec()·파이프만 이해하면 200줄로 동작하는 셸이 나온다. 프로세스가 무엇인지 몸으로 안다.
다음 Docker(6개). "500줄 Go로 만드는 컨테이너"류 튜토리얼을 하면 컨테이너 = namespace + cgroup + chroot의 조합이라는 게 드러난다. 셸에서 익힌 프로세스 감각이 그대로 쓰인다.
마지막 OS(19개). 부트로더·인터럽트·페이징. 난이도가 급격히 오르지만 앞의 둘을 했으면 용어가 낯설지 않다.
Regex Engine(9개)이 최고의 입문이다. 정규식 엔진은 작지만 토크나이저 → 파서 → 실행기라는 컴파일러의 3단 구조를 그대로 갖고 있다. 하루~이틀이면 된다.
그 다음 Programming Language(41개) — 저장소 최다 카테고리. Crafting Interpreters 같은 정평난 자료가 여기 있다. 트리 순회 인터프리터 → 바이트코드 VM 순으로 간다.
여유가 되면 Emulator/VM(13개). CHIP-8 에뮬레이터가 관문이고, 여기서 명령어 디코딩·레지스터·메모리 맵을 익히면 컴퓨터 구조 과목이 통째로 이해된다.
Database(13개): "sqlite를 밑바닥부터"류로 B-tree·페이지·WAL을 만난다. 인덱스가 왜 그렇게 동작하는지 영원히 잊지 않게 된다.
Search Engine(6개): 역색인(inverted index)·TF-IDF. RAG 시스템의 검색 파트가 사실 이것의 확장이다.
Neural Network(17개) → AI Model(3개): 역전파를 직접 구현(예: SlowTorch — 순수 파이썬으로 PyTorch 재구현)한 뒤, 2026-02 신설된 AI Model 섹션의 LLMs-from-scratch로 넘어간다. 2026-06에는 "PyTorch 내부를 34단계로 재구현"하는 자료도 추가됐다.
loss.backward() 한 줄이 무엇을 하는지 완전히 달라 보인다.저장소를 읽는 데는 브라우저 하나면 된다. 문제는 각 튜토리얼을 실제로 할 때다. 카테고리별 대략적인 요구 사양을 정리했다.
| 카테고리 | 요구 환경 | 주의점 |
|---|---|---|
| Shell / CLI / Git | 리눅스·맥(또는 WSL). 사양 무관 | 윈도우 네이티브에선 fork()가 없어 막힌다 → WSL 권장 |
| Docker | 리눅스 커널 필수(WSL2 가능) | 맥은 가상머신 위라 namespace 실습이 그대로 안 된다 |
| Operating System | QEMU 등 에뮬레이터. RAM 8GB+ | 실기기 부팅은 하지 말 것 — 에뮬레이터로 충분하다 |
| 3D Renderer / Voxel | GPU는 선택. 레이트레이싱은 CPU로도 가능 | 렌더 시간이 길 수 있다. 해상도를 낮춰 시작 |
| Neural Network | CPU로 충분(MNIST 수준) | from scratch 구현은 대체로 작은 데이터셋을 쓴다 |
| AI Model (LLM) | GPU 권장 (VRAM 8GB+) | 여기만 진입 장벽이 뚜렷하다. 클라우드 GPU 시간 단위 대여가 현실적 |
| Blockchain | 사양 무관 | 실제 체인에 연결하지 말고 로컬 테스트넷에서 |
| Processor (Verilog) | 시뮬레이터(Verilator 등). FPGA는 선택 | FPGA 보드 없이도 시뮬레이션으로 완주 가능 |
| Augmented Reality | Unity + 카메라 달린 기기 | 설치 용량이 크다(수십 GB) |
359개 중 GPU가 꼭 필요한 항목은 AI Model 계열 몇 개뿐이다. 나머지는 5년 된 노트북으로도 전부 가능하다. Programming Language(41개)·Game(34개)·Database(13개) 같은 알짜 카테고리는 사양 요구가 사실상 없다.
이 저장소에 없는 바로 그 자동화를 직접 만든다. README를 파싱해 359개 URL을 뽑고, 각각에 HTTP 요청을 보내 상태 코드를 기록한다.
# 1) 항목 파싱 — 4-2의 포맷 규약을 이용
grep -oE '\* \[\*\*[^]]+\]\(([^)]+)\)' README.md | \
grep -oE 'https?://[^)]+' > urls.txt
# 2) 상태 확인 (동시 20개, 타임아웃 10초)
cat urls.txt | xargs -P 20 -I{} \
curl -s -o /dev/null -w "%{http_code} {}\n" -L --max-time 10 {}
배우는 것: 정규식 파싱, 병렬 처리(xargs -P), HTTP 상태 코드. 확장: 결과를 마크다운 표로 만들고, 404가 나온 항목은 실제로 이슈를 등록해 보라 — 오픈소스 첫 기여로 이상적이다.
README를 {카테고리, 언어, 제목, URL, 영상여부} 구조의 JSON/CSV로 변환하고, 언어별·카테고리별 필터가 되는 단일 HTML 페이지를 만든다.
배우는 것: 반정형 텍스트를 구조화 데이터로 바꾸는 ETL의 축소판. 이 저장소가 이미 이 문서의 3절·5절 통계를 만들어 낸 방식 그대로다.
확장: "Python으로 할 수 있는, 영상이 아닌, 데이터베이스 튜토리얼"처럼 3중 필터를 걸어보라. CC0 라이선스라 결과물을 공개해도 문제없다.
., *, ^, $ 정도만 지원하는 최소 정규식 엔진을 짠다. Rob Pike의 30줄 버전이 고전 출발점이다.
배우는 것: 토크나이저 → 파서 → 매칭 실행기라는 컴파일러의 3단 구조를 가장 작은 규모로 체험. 재귀와 백트래킹 감각.
완주 판정: 자기 엔진과 언어 내장 정규식의 결과를 무작위 입력 500개로 비교해 전부 일치하면 성공.
"sqlite를 밑바닥부터"류 튜토리얼을 따라 REPL → SQL 파서 → B-tree 인덱스 → 디스크 영속화 순으로 쌓는다.
배우는 것: 페이지·B-tree·커서, 그리고 영속성(durability). "인덱스를 걸면 왜 조회는 빨라지고 쓰기는 느려지는가"에 스스로 답할 수 있게 된다.
확장: WAL(Write-Ahead Log)을 붙여 프로세스를 강제 종료해도 데이터가 살아남게 만들어 보라.
2026-02 신설된 AI Model 섹션의 LLMs-from-scratch 경로. 토크나이저 → 임베딩 → 어텐션 → 트랜스포머 블록 → 학습 루프를 직접 쌓는다.
배우는 것: 어텐션의 QKV 연산, 위치 인코딩, 학습률 스케줄. GPT류 모델이 "다음 토큰 확률 분포"를 계산하는 기계일 뿐이라는 게 손끝으로 이해된다.
현실 조언: 처음부터 큰 모델을 노리지 말 것. 셰익스피어 텍스트로 학습하는 수백만 파라미터급 장난감 모델이면 원리 학습에는 충분하고, 노트북 CPU로도 몇 시간이면 돌아간다.
359개를 다 할 수는 없다. 아래는 서로 지식이 이어지도록 고른 8주 경로다. 주당 8~10시간 기준.
| 주차 | 주제 | 만들 것 | 얻는 감각 |
|---|---|---|---|
| 1주 | Shell | 파이프·리다이렉션 되는 미니 셸 | 프로세스, fork/exec, 파일 디스크립터 |
| 2주 | Regex Engine | 최소 정규식 엔진 | 토크나이저·파서·실행기 3단 구조 |
| 3~4주 | Programming Language | 트리 순회 인터프리터 | AST, 스코프, 클로저, 재귀 평가 |
| 5주 | Emulator | CHIP-8 에뮬레이터 | 명령어 디코딩, 레지스터, 메모리 맵 |
| 6주 | Web Server | HTTP/1.1 서버 (소켓부터) | TCP, 요청 파싱, 동시성 모델 |
| 7주 | Database | B-tree 인덱스 + 디스크 저장 | 페이지, 인덱스, 영속성 |
| 8주 | Docker | 미니 컨테이너 런타임 | namespace, cgroup, chroot |
1주 셸에서 익힌 프로세스 개념이 8주 컨테이너에서 그대로 다시 쓰인다. 2주 정규식의 파서 구조가 3~4주 인터프리터의 뼈대가 된다. 5주 에뮬레이터의 명령어 해석은 인터프리터의 저수준 버전이다.
즉 앞 주차가 뒤 주차의 사전 학습이 되도록 배치했다. 순서를 섞으면 각각이 고립된 취미 프로젝트가 되기 쉽다.
| 관심 방향 | 다음 카테고리 | 목표물 |
|---|---|---|
| 저수준·시스템 | Operating System(19) → Processor(1) | 부팅되는 커널, RISC-V CPU(Verilog) |
| 언어·컴파일러 | Programming Language(41) 심화 | 바이트코드 VM, GC, JIT |
| AI·데이터 | Neural Network(17) → AI Model(3) | 역전파 직접 구현 → 미니 LLM |
| 그래픽스 | 3D Renderer(11) → Physics Engine(7) | 레이트레이서, 강체 충돌 시뮬레이션 |
| 웹 내부 | Front-end Framework(14) → Web Browser(2) | 가상 DOM, HTML 파서·렌더링 엔진 |
| 용어 | 뜻 |
|---|---|
| build-your-own-x | "당신만의 ___를 만들어보라"는 문장 틀. x 자리에 Database·Git·Docker 등이 들어간다 |
| from scratch | 라이브러리 없이 밑바닥부터 구현. 제품이 아니라 원리 이해가 목적 |
| 큐레이션 저장소 | 코드가 아니라 골라 정리한 링크가 결과물인 저장소 |
| 링크 부패 (link rot) | 참조한 외부 URL이 시간이 지나며 죽는 현상. 링크 기반 큐레이션의 숙명 |
| 앵커 (anchor) | #헤더-이름 형태로 같은 문서 내 특정 위치로 점프하는 링크. 헤더 텍스트가 바뀌면 조용히 깨진다 |
| CC0 | 저작권을 포기해 퍼블릭 도메인에 헌정하는 라이선스. 출처 표기 의무조차 없다 |
| namespace / cgroup | 리눅스 커널 기능. 각각 프로세스가 보는 세계를 격리(namespace)하고 자원 사용량을 제한(cgroup)한다. 이 둘이 컨테이너의 실체 |
| fork / exec | 프로세스를 복제하고(fork), 그 자리에 다른 프로그램을 덮어씌우는(exec) 시스템 콜. 셸의 심장 |
| B-tree | 디스크 기반 데이터베이스가 인덱스에 쓰는 균형 트리. 한 노드가 디스크 페이지 하나에 대응해 읽기 횟수를 줄인다 |
| WAL (Write-Ahead Log) | 실제 데이터를 고치기 전에 "무엇을 고칠 것인가"를 먼저 로그에 적는 기법. 중간에 죽어도 복구 가능하게 만든다 |
| 역색인 (inverted index) | "단어 → 그 단어를 포함한 문서 목록" 방향으로 뒤집어 저장한 자료구조. 검색엔진의 핵심 |
| 역전파 (backpropagation) | 신경망의 오차를 출력에서 입력 쪽으로 거꾸로 전파하며 가중치 수정량을 계산하는 방법 |
| AST (추상 구문 트리) | 소스 코드를 문법 구조에 따라 트리로 표현한 것. 인터프리터·컴파일러의 공통 중간 산출물 |
| 바이트코드 VM | 소스를 가상 기계용 명령어(바이트코드)로 컴파일한 뒤 그것을 실행하는 방식. 트리 순회 인터프리터보다 빠르다 |
| CHIP-8 | 1970년대 가상 기계. 명령어가 35개뿐이라 에뮬레이터 제작 입문의 정석 |
| Uncategorized | 이 저장소의 미분류 섹션(62개). 분류 체계가 유입 속도를 못 따라간 흔적이자, 숨은 보물 창고 |