[심층분석] 직접 만들어보면서 배우는 게 진짜다: 'Build Your Own X'가 50만 별을 받은 이유

들어가며: 왜 우리는 "직접 만들어보기"에 끌리는가

혹시 이런 경험 해보셨어요? React를 몇 년째 쓰고 있는데, 막상 "가상 DOM이 어떻게 동작해요?"라는 질문을 받으면 머릿속이 하얘지는 그런 순간이요. 또는 매일 git commit을 치면서도 "근데 .git 폴더 안에서 정확히 무슨 일이 벌어지는 거지?" 하는 의문이 스쳐 지나가는 그런 경험. 저만 그런 건 아닐 거예요.

오늘 이야기할 GitHub 저장소는 바로 그런 갈증을 정확히 짚어내는 프로젝트예요. codecrafters-io/build-your-own-x. 이름 그대로 "네가 좋아하는 기술을 직접 만들어봐"라고 권하는 큐레이션 모음집인데요, 무려 50만 가까이의 스타와 4만 7천 개의 포크를 받으며 GitHub 역사상 손에 꼽히는 인기 저장소가 됐어요.

흥미로운 건 이 저장소가 어떤 새로운 라이브러리나 프레임워크를 제공하는 게 아니라는 점이에요. 그냥 "링크 모음"이거든요. 그런데도 이렇게 많은 개발자들이 별을 누른 이유가 뭘까요? 저는 여기에 우리 업계가 지금 처한 어떤 "피로감"과 "근본으로 돌아가고 싶은 욕구"가 함께 담겨 있다고 봐요.

요즘 개발자들의 일상을 한번 떠올려보세요. AI 어시스턴트가 코드를 자동완성해주고, 프레임워크가 알아서 라우팅해주고, ORM이 SQL을 대신 짜주고, Docker가 환경 설정을 추상화해줘요. 편한데, 어딘가 찜찜하죠. "내가 정말 이걸 이해하고 쓰는 건가?" 하는 의심이 들어요. 그래서 사람들이 이 저장소를 "북마크해놓고 언젠가 꼭 해봐야지" 하면서 별을 누르는 거예요.

'Build Your Own X'는 정확히 뭘 모아놓은 건가요

이 저장소가 표방하는 슬로건은 리처드 파인만의 그 유명한 말이에요. "내가 만들 수 없는 것은 이해하지도 못한 것이다(What I cannot create, I do not understand)." 노벨 물리학상을 받은 천재 물리학자가 칠판에 남긴 이 한 줄을 개발 학습의 모토로 삼은 거죠.

구체적으로 어떤 카테고리들이 있냐면요, 정말 광범위해요. 한번 쭉 보실까요?

• 3D 렌더러 (레이트레이싱, 래스터화 같은 그래픽 엔진의 밑바닥)
• AI 모델 (LLM, 디퓨전 모델, RAG 같은 요즘 핫한 것들)
• 블록체인 / 암호화폐
• BitTorrent 클라이언트 (P2P 파일 공유 프로토콜)
• 데이터베이스 (SQLite 같은 걸 처음부터 만들기)
• Docker (컨테이너 런타임)
• 에뮬레이터 / 가상머신
• 프론트엔드 프레임워크 (React, Vue 같은 걸 직접)
• 게임 엔진
• Git (버전 관리 시스템)
• 메모리 할당기 (malloc을 직접)
• 네트워크 스택 (TCP/IP를 직접)
• 신경망
• 운영체제
• 물리 엔진
• 프로세서 / CPU
• 프로그래밍 언어
• 정규식 엔진
• 검색 엔진
• 셸 (bash 같은)
• 텍스트 에디터
• 웹 브라우저
• 웹 서버

진짜 상상할 수 있는 거의 모든 "기반 기술"이 다 들어 있어요. 각 카테고리 안에는 C++, Python, Go, Rust, JavaScript 등 다양한 언어로 된 튜토리얼들이 정리돼 있어요. 예를 들어 BitTorrent 클라이언트만 해도 C#, Go, Python, Rust, Node.js 버전이 다 있는 식이에요.

왜 "바닥부터 만들어보기"가 다시 주목받을까

이게 사실 새로운 개념은 아니에요. SICP(컴퓨터 프로그램의 구조와 해석)나 "Crafting Interpreters" 같은 고전들도 다 이 철학을 바탕에 깔고 있거든요. 그런데 왜 지금 이 저장소가 이렇게 화제가 되는 걸까요? 몇 가지 흐름이 겹쳤다고 봐요.

1. AI 시대의 역설

AI가 코드를 짜주는 시대가 되면서 오히려 "기본기"가 더 중요해졌어요. 이게 무슨 말이냐면요, AI가 짜준 코드를 검토하고 디버깅하려면 결국 그 코드가 뭘 하는지 이해해야 하잖아요? 표면적인 문법만 알아서는 부족하고, 그 아래에서 뭐가 돌아가는지 알아야 해요.

예를 들어 AI가 Redis 캐싱 코드를 짜줬는데 성능이 이상해요. 이때 "Redis가 내부적으로 어떤 자료구조를 쓰는지", "네트워크 RTT(왕복 시간)가 얼마나 영향을 주는지" 모르면 디버깅이 안 되거든요. 결국 AI가 짠 코드를 잘 다루려면, 역설적이게도 더 깊은 이해가 필요해진 거예요.

2. 추상화 계층의 폭발

요즘 신입 개발자가 처음 배우는 스택을 한번 보세요. Next.js → React → Node.js → V8 엔진 → 운영체제 → 하드웨어. 이 사이사이에 또 Webpack, Babel, ESLint, Prettier, TypeScript 컴파일러 같은 도구들이 끼어 있어요. "Hello World"를 띄우는 데 수십 개의 추상화 계층을 거치는 거죠.

편리하긴 한데, 뭔가 잘못됐을 때 어디를 봐야 할지 모르겠는 상황이 자주 생겨요. 이럴 때 "바닥부터 만들어보기"가 그 추상화의 베일을 한 겹씩 벗겨주는 역할을 해요.

3. 면접과 실무의 변화

빅테크 면접에서 "Redis 같은 인메모리 DB를 직접 만들어보라"거나 "간단한 컴파일러를 작성해보라" 같은 시스템 디자인 문제가 늘고 있어요. 단순히 LeetCode 알고리즘만 풀어서는 통과하기 어려워졌죠. 그래서 사람들이 "기반 기술 직접 만들어보기"에 시간을 투자하기 시작한 거예요.

가장 인기 있는 트랙들을 자세히 살펴볼게요

직접 만드는 Git: 30분이면 "아, 이거였구나" 하게 돼요

Git 만들기 튜토리얼은 이 저장소에서 가장 추천하고 싶은 입문 코스예요. 왜냐면 Git은 우리가 매일 쓰지만 정작 그 내부는 거의 모르고 있거든요.

Git의 핵심을 한 줄로 요약하면 "콘텐츠 주소 지정 파일 시스템(content-addressable filesystem)"이에요. 어렵게 들리죠? 쉽게 말하면, 모든 파일을 그 내용의 해시값(SHA-1)을 이름으로 해서 저장하는 시스템이에요. 같은 내용이면 같은 해시가 나오니까, 중복 저장이 자동으로 방지되고요. 변경 사항을 추적하는 게 사실은 "어떤 해시가 어떤 해시로 바뀌었는지"를 기록하는 일에 불과해요.

직접 만들어보면 .git 폴더 안에 있는 objects/, refs/, HEAD 파일이 왜 그렇게 생겼는지 한순간에 이해돼요. "커밋이 사실은 트리(디렉토리 스냅샷)와 부모 커밋을 가리키는 작은 텍스트 파일일 뿐"이라는 깨달음이 와요.

직접 만드는 데이터베이스: SQL의 마법이 풀리는 순간

SQLite를 클론하는 튜토리얼들이 인기예요. B-Tree(데이터베이스에서 인덱스를 저장하는 자료구조)를 직접 구현하다 보면, "왜 인덱스를 잘못 걸면 쿼리가 느려지는지"가 머리가 아니라 손으로 이해돼요.

예를 들어 WHERE id = 100이 빠른 이유는 B-Tree가 균형 잡힌 트리라서 100만 개 데이터에서도 20번 정도의 비교만 거치면 찾아지기 때문이거든요. 이걸 글로 읽는 거랑, 직접 코드로 짜본 후에 이해하는 건 천지차이예요.

직접 만드는 프로그래밍 언어: 인터프리터의 비밀

"Crafting Interpreters" 같은 책이 안내하는 길인데요, 렉서(lexer) → 파서(parser) → AST(추상 구문 트리) → 인터프리터 이 흐름을 직접 짜보면 모든 언어가 결국 같은 패턴을 따른다는 걸 알게 돼요.

• 렉서: 텍스트를 토큰으로 쪼개는 거예요. let x = 10을 [LET, IDENT("x"), EQ, NUM(10)]처럼요.
• 파서: 그 토큰들을 트리 구조로 만들어요. "x라는 변수에 10을 할당하는 명령문"이라는 의미 구조로요.
• 인터프리터: 그 트리를 따라가면서 실제로 실행해요.

이걸 한 번 짜보면 Python의 GIL(전역 인터프리터 잠금)이 왜 존재하는지, JavaScript의 호이스팅이 왜 일어나는지 같은 게 자연스럽게 이해되기 시작해요.

직접 만드는 LLM: 트랜스포머의 내부 들여다보기

요즘 가장 핫한 트랙이에요. Andrej Karpathy의 "Let's build GPT" 같은 영상과 함께 보면 좋아요. 어텐션 메커니즘(attention mechanism)이라는 게 결국 "문장에서 어떤 단어가 어떤 단어에 더 주목해야 하는지를 행렬 곱셈으로 계산하는 것"이라는 걸 직접 코드로 짜보면 알게 돼요.

비슷한 다른 자료들과 어떻게 다를까

비슷한 콘셉트의 자료들이 꽤 있어요. 한번 비교해볼게요.

• Build Your Own X: 큐레이션이 광범위하고, 외부 튜토리얼 링크를 모아둔 "포털" 같은 느낌이에요. 무료고요.
• CodeCrafters.io: 같은 회사에서 운영하는 유료 플랫폼이에요. 자동 채점이 되는 인터랙티브 챌린지를 제공해요. "Redis 만들기", "Git 만들기" 같은 챌린지가 단계별로 잘게 나뉘어 있어서 막히지 않게 도와줘요.
• The Odin Project / freeCodeCamp: 이건 "쓸 수 있는 개발자"를 만드는 데 초점이에요. 즉, 프레임워크를 잘 쓰는 법을 가르치죠. 반면 Build Your Own X는 "왜 그렇게 동작하는지 이해하는 개발자"를 지향해요.
• MIT OCW, CS50: 학문적 정확성과 깊이가 있지만 진입 장벽이 높아요. Build Your Own X는 더 캐주얼하고 "주말에 한번 해보자" 정도의 느낌이에요.

한국 개발자에게 주는 실질적 조언

자, 그래서 이걸 어떻게 활용하면 좋을까요? 몇 가지 시나리오를 제안해볼게요.

1. 주니어 개발자: "한 분기에 하나씩" 챌린지

매일 야근하느라 지쳐 있는 주니어분들도 많을 텐데요, 한꺼번에 다 하려고 하지 마세요. 분기에 하나씩, 즉 1년에 4개 정도면 충분해요. 추천 순서는 이래요.

1. 1분기: 직접 만드는 Git (10~15시간 정도면 돼요. 매일 쓰는 도구라 임팩트가 커요.)
2. 2분기: 직접 만드는 셸 또는 CLI 도구 (운영체제와 시스템 콜에 대한 감을 잡을 수 있어요.)
3. 3분기: 직접 만드는 웹 서버 (HTTP 프로토콜을 소켓 레벨에서 이해하면 백엔드 디버깅이 달라져요.)
4. 4분기: 직접 만드는 인터프리터 (언어가 어떻게 동작하는지 알게 되면 어느 언어를 만나도 두렵지 않아요.)

2. 시니어 개발자: 팀 스터디로 활용

주니어들과 함께 하는 사내 스터디 주제로 정말 좋아요. "이번 달엔 다 같이 직접 Redis 만들어보기"처럼요. 페어 프로그래밍이나 코드 리뷰를 곁들이면 멘토링 효과도 있고요.

3. 이직 준비생: 포트폴리오 차별화

또 다른 todo 앱 클론보다 "내가 직접 만든 미니 데이터베이스"가 면접관 눈에 훨씬 매력적이에요. GitHub README에 "왜 만들었고, 어떤 점을 배웠고, 어떤 한계가 있는지"를 잘 정리해놓으면 기술 면접에서 풀어낼 이야기가 풍부해져요.

4. 주의할 점

다만 함정도 있어요. "바닥부터 만들기"에 너무 빠지면 "바퀴 재발명 강박"에 걸릴 수 있거든요. 학습용으로 만든 것과 프로덕션에 쓸 것은 명확히 구분해야 해요. 회사 코드에 "제가 직접 만든 ORM이에요"라고 들고 가면 안 돼요.

또 하나, 모든 튜토리얼이 다 좋은 건 아니에요. 일부는 오래됐거나 깊이가 얕아요. README 별점이나 마지막 업데이트 날짜를 꼭 확인하세요.

마무리: "이해"라는 사치를 부리는 시간

솔직히 말하면, 회사에서 일할 때 "바닥부터 이해하는 시간"을 갖기는 어려워요. 마감이 있고, 스프린트가 있고, 일단 돌아가게 만들어야 하니까요. 그래서 이런 "바닥부터 만들기" 학습은 어떤 의미에선 사치예요. 당장의 생산성에는 도움이 안 되거든요.

그런데 길게 보면 이 사치가 결국 우리를 더 멀리 가게 해줘요. 5년차, 10년차가 됐을 때 후배가 "이거 왜 이렇게 동작해요?"라고 물었을 때 "음, 그게 내부적으로는 이렇게 돼 있어서..."라고 대답할 수 있는 사람이 되느냐, 아니면 "나도 잘 모르는데 그냥 이렇게 쓰면 돼"라고 대답하는 사람이 되느냐의 차이가 여기서 갈리거든요.

AI가 코드를 짜주는 시대일수록, 역설적으로 "진짜 이해하는 사람"의 가치는 올라가요. 누구나 표면적인 코드는 만들 수 있지만, 그 코드가 왜 그래야 하는지를 설명할 수 있는 사람은 적거든요.

여러분은 어떠세요? 한 번이라도 좋아하는 기술을 바닥부터 만들어본 경험이 있나요? 있다면 어떤 깨달음을 얻으셨어요? 아직 없다면, 올해 안에 하나 정도는 도전해보시는 거 어떨까요? 댓글로 "나는 이걸 만들어보고 싶다" 하는 거 적어주시면, 비슷한 관심사를 가진 분들끼리 연결될 수도 있을 것 같아요. 같이 고민하고 같이 만들어가는 게 결국 커뮤니티의 매력이니까요.