nbdev 사용을 그만둔 이유

프로그래머들은 최고의 도구를 찾았다고 선언하길 좋아합니다. Paul Graham은 Lisp를 자신의 "비밀 무기"라고 불렀고, DHH는 Ruby를 "내 사고방식에 딱 맞는 마법 같은 장갑"이라고 표현했습니다. Pieter Levels는 바닐라 PHP와 jQuery만으로 수백만 달러짜리 제품을 만들어냅니다.

이런 선언은 사실 언어 자체에 대한 이야기가 아닙니다. 자신의 사고방식에 맞는 도구를 찾았을 때의 경험에 대한 이야기입니다. 도구가 딱 맞아떨어지면, 속도가 붙습니다.

저에게도 그런 경험이 있었습니다. 바로 nbdev, 문학적 프로그래밍(literate programming)을 위한 개발 환경이었는데, 저는 이 프로젝트의 개발과 유지보수에 직접 참여했습니다¹. nbdev로 수백 개의 프로젝트를 만들었고, 가장 열성적인 지지자 중 한 명이었습니다.

지금은 더 이상 사용하지 않습니다. AI 코딩 도구가 트레이드오프의 균형을 바꿔놓았기 때문입니다.

AI와의 충돌

nbdev의 매력은 워크플로에 있습니다. 코드, 문서, 테스트를 하나의 원천(source of truth)인 Jupyter 노트북에 작성합니다. 이후 이 노트북이 Python 라이브러리와 문서화 웹사이트로 변환(transpile)됩니다.

이 워크플로는 독특합니다. 방대한 양의 일반적인 소스 코드로 학습된 AI 코딩 도구는 이런 구조에서 혼란을 겪습니다. 노트북을 편집하는 것과 최종 소스 코드를 편집하는 것을 제대로 구분하지 못합니다. AI와 협업하는 것이 아니라, AI와 싸우는 느낌이 듭니다.

저는 코드를 작성하려고 소프트웨어를 만드는 게 아닙니다. 문제를 해결하려고 만듭니다. AI가 최대한 제 역할을 잘 해낼 수 있는 환경에서 일하고 싶습니다. nbdev에서는 물살을 거슬러 올라가는 격이었습니다.

AI 도구가 안일한 사고를 조장한다는 주장도 있습니다. 가드레일이 없으면 개발자들이 문제를 단계별로 분해하는 힘든 과정을 건너뛴다는 것입니다. 하지만 단계적 사고는 사람의 역량입니다. 노트북이 깔끔한 코드를 강제하지 않듯, AI 도구도 신중한 사고를 강제하지 않습니다. 훈련(discipline)은 환경이 아니라 개발자 자신에게서 나옵니다.

도구의 중요성은 생각보다 크지 않았다

문학적 프로그래밍의 핵심 약속 중 하나는 더 나은 문서화입니다. 코드와 문서를 한곳에 두면 내용이 낡아질 가능성이 줄어든다는 논리입니다.

그런데 이상하게도, 제 기준에서 충분한 문서화가 갖춰진 nbdev 프로젝트는 많지 않았습니다. 때로는 이 덕분에 문서에 기여하면서 코드베이스를 익힐 수 있었지만, 때로는 그저 답답할 뿐이었습니다. 좋은 문서는 도구가 아니라 노력에서 나온다는 확신이 더 강해졌습니다.

이 워크플로의 매력도 이제는 예전 같지 않습니다. AI는 문서가 없어도 코드베이스를 읽고 즉석에서 개요를 제공합니다. 코드와 분리된 문서를 유지보수할 때도 번거로운 작업을 AI가 대신 처리할 수 있습니다. 코드와 문서를 한곳에 두는 것이 더 이상 과거만큼 강력한 이점이 아닌 셈입니다.

협업과 채택

nbdev는 개발자에게 기존과 다른 시스템을 받아들이도록 요구합니다. 개발자가 이미 서 있는 곳에서 출발하지 않습니다. Cursor가 성공한 이유는 익숙한 환경을 제공하면서, 첫날부터 새로운 워크플로를 강요하지 않고 습관을 천천히 바꿀 수 있게 했기 때문입니다.

예전에는 협업 문제를 크게 신경 쓰지 않았습니다. 하지만 이제 AI와의 협업은 기본 중의 기본입니다. 사람과의 협업을 방해하는 요소는, AI와의 협업도 마찬가지로 방해하는 경향이 있습니다.

오늘날 개발자들은 점점 더 넓은 영역을 다룹니다. 백엔드 개발자가 프론트엔드를 하고, PM이 프로토타입을 직접 만듭니다. 누구나 더 많은 언어를 넘나듭니다. 이런 상황에서 독특한 프레임워크는 팀으로부터의 고립을 그 어느 때보다 심화시킵니다. 한때 독특한 도구에는 숨겨진 장점이 있었습니다. 특정 유형의 기여자를 걸러내는 필터 역할이었죠. 하지만 지금은 오히려 부담이 된다고 생각합니다.

지금 사용하는 도구

nbdev에 수천 시간을 투자해왔기에, 제가 원하는 결과에 더 나은 도구가 있다는 사실을 인정하기가 쉽지 않았습니다. 하지만 자존심은 내려놓아야 합니다².

지금 주로 쓰는 도구는 Amp, Cursor, Claude Code입니다. 노트북도 여전히 좋아하지만, 데이터 분석이나 머신러닝 같은 탐색적 워크플로, 즉 반복적이고 시각적인 특성이 빛을 발하는 작업에서만 사용합니다.

더 중요한 변화는, AI 덕분에 "모든 것을 Python으로" 하던 사고방식에서 벗어났다는 점입니다. 이제는 작업에 맞는 언어를 선택합니다. 웹 개발에는 Next.js 스택을 선호합니다. 노트북으로 웹 개발을 하는 것은(전용 도구가 있더라도) 저에게는 불필요한 복잡성을 더할 뿐입니다.

이건 단순한 취향이 아닙니다. AI는 특정 도메인에 학습 데이터가 풍부한 코드에서 가장 잘 동작합니다. 최근 GitHub에서 TypeScript가 Python과 JavaScript를 모두 제치고 1위에 올랐는데, 타입이 있는 언어가 AI 생성 코드의 프로덕션 안정성을 높여준다는 점도 한 요인입니다³. OCaml 중심 인프라로 유명한 Jane Street조차 머신러닝과 데이터 작업에는 Python을 도입했습니다.

즐거움의 자리

독특한 도구가 쓸모없다는 뜻은 아닙니다. Lisp, Haskell, APL은 각각 컴퓨팅에 대해 다른 것을 가르쳐줍니다. AI 지원이 부족하더라도, 즐거움은 언어를 선택하는 충분한 이유가 됩니다. 다만 지금 제 초점은 거기에 있지 않습니다. 저의 즐거움은 문제를 해결하는 데 있고, 레버리지를 극대화할 도구를 원합니다. 그 목적에는 주류 도구가 이깁니다.