바퀴를 다시 발명하라 - Reinvent the Wheel
(endler.dev)- "바퀴를 다시 발명하지 말라" 는 조언은 창의성과 탐구심을 억누르는 부정적 영향을 줌
- 새로운 바퀴, 즉 기존 도구나 기술을 재창조하는 과정에서 깊은 이해와 배움을 얻음
- 단순하거나 익숙해 보이는 기초 구성 요소도 실제로는 복잡성과 다양한 트레이드오프를 포함함
- 자신만의 바퀴를 발명해봄으로써 성장, 문제 해결, 실험에 대한 역량이 강화됨
- 기존 결과물을 활용하는 것과 재창조하는 것 사이에서 목적에 따라 균형 있게 선택할 필요성 강조됨
Reinvent the Wheel
- "바퀴를 다시 발명하지 말라"는 말은 의도는 좋지만, 두 부류에서 나온 조언임
- 직접 바퀴를 만들어보고 그 어려움을 체험한 사람들
- 시도해본 적 없이 기존 조언을 맹목적으로 따르는 사람들
- 이러한 조언이 반복되면 호기심과 탐구정신이 위축되는 분위기 조성임
- 만약 이 조언을 모두가 따랐다면, 많은 현대적 편의와 발전을 이루지 못했을 것이라는 점 강조임
- 실제로 바퀴는 초기 발명 이후에도 여러 번 재창조되어 발전을 거듭해왔음
참고: 여기서 '바퀴'는 어떤 도구, 프로토콜, 서비스, 기술, 기타 창작물로 대체해서 생각할 수 있음
바퀴를 직접 발명해보는 것이 곧 배움임
"내가 만들 수 없는 것은 이해했다고 할 수 없다"
— 리처드 파인만
- 무언가를 진정으로 깊이 이해하기 위해서는 작은 버전이라도 직접 구현해보는 경험이 필요함
- 결과물이 완벽하지 않아도, 심지어 활용하지 않아도 구현해보는 과정 자체가 중요함
- 컴퓨터 과학의 여러 개념—프로토콜, 암호화, 웹서버 등—은 어렵게 느껴질 수 있으나, 실제로는 누구나 시도해볼 수 있음
- 더 많은 사람들이 직접 만들어보는 경험을 통해 기존 기술의 구조와 본질을 이해하는 기회가 생김
모든 것은 끝없는 탐구 과정임(Rabbit Hole)
- 우리가 당연하게 여기는 기본 구성 요소—예를 들어 문자열, 파일 경로 등—도 실제로는 매우 복잡함
- 자신만의 문자열이나 경로 라이브러리 구현 시도는 많은 배움의 계기가 됨
- 이 과정을 통해 다음과 같은 사실을 깨달음
- 일상적인 것에도 무한에 가까운 복잡성이 존재함
- 다른 사람에게 유용한 무언가를 만드는 것은 겸손함을 배울 기회임
- 모든 추상화는 인간이 만들었으며, 완벽하지 않고 자신만의 (다른) 트레이드오프도 가능함
- 구현 도중 정확성, 단순성, 성능, 확장성, 이식성 등 수많은 선택지와 문제에 직면함
- 자신이 만든 해결책은 일부 영역에서 뛰어날 수 있지만, 모든 사용자/상황에 맞지는 않음
- 기존 솔루션에도 한계가 있고, 내 문제에 맞지 않을 수도 있음
- 하나의 문제에 끝까지 파고드는 경험은 엔지니어로 성장하는 과정임
- 만약 프로젝트를 자주 이리저리 옮기기만 한다면 의미 있는 학습은 얻을 수 없음
바퀴를 다시 발명해야 하는 이유
- 기존보다 더 나은 바퀴를 만들고자 함(‘더 나은’의 정의는 다양함)
- 바퀴가 어떻게 만들어지는지 학습하는 목적임
- 다른 사람에게 바퀴의 원리를 가르치는 교육적 목적
- 바퀴의 발명 과정을 탐구하면서 새로운 깨달음을 얻음
- 고장났을 때 직접 수리 또는 개선할 수 있는 능력 배양
- 바퀴를 만드는 데 필요한 다양한 도구와 기술을 습득하게 됨
- 복합 시스템(예: 자동차 등)의 일부로서 바퀴의 역할 이해
- 특정한 필요에 맞는 아주 특별한 바퀴를 만들기 위한 시도(예: 휠체어, 스케이트보드, 도자기용 바퀴 등)
- 자신이 만든 바퀴가 원래 목적과 달리 전혀 다른 용도로 더 잘 쓰일 수도 있음
- 세상에는 틀에 박히지 않은 새로운 발상이 중요한 역할을 할 수 있음
Reuse vs Reinvent
- 다른 사람의 결과물을 무시해서는 안 되며, 그들의 작업을 연구하고 적절히 활용할 필요가 있음
- 단순히 불신이나 무지로 기존 것을 버리고 새로 만들지 않도록 주의해야 함
- 그러나 직접 구현하거나 실험해보지 않으면 해당 분야의 핵심 이해와 발전이 어려움
- 소프트웨어 엔지니어링에서는 작은 실험과 프로토타입 제작이 쉽고 빠르므로 개인 문제 해결에 효과적임
- 작게 시작해 단순하게 구현하고 반복하는 과정을 추천함
- 그래서 마지막 나의 조언은
- 통찰(insight) 을 원한다면 직접 재발명에 도전
- 영향력(impact) 을 원한다면 이미 검증된 솔루션을 재사용
"Reinvent for insight. Reuse for impact."
"통찰을 위해 재발명하고, 영향력을 위해 재사용하세요"
"소 잃고 외양간 고친다"가 미래를 준비하지 말라는 말이 아니듯,
"바퀴를 다시 발명하지 말라"가 통찰을 얻는데 시간을 투자하지 말란 말은 아니라고 봅니다.
어떤 상황에서 이러한 말이 나왔는지 앞뒤 자르면 본 뜻은 왜곡됩니다.
최근 경험이지만, 최근에 저만의 아주 특별한 바퀴를 하나 만들었어요.
Nuxt에 1000페이지짜리 앱을 빌드하는데 7분이 걸렸는데,
자동화 몇가지를 포기하고 다시 짜올린 결과 20초 빌드에 성공했거든요.
어디까지 재발명하고, 어디까지 외부 의존성에 기댈 건가 의사결정하는 게 어려운데요.
어떤 경우건, 내가 이걸 스스로 만들 수 있는 데 시간을 아끼려고 그 의존성을 선택하는 것과, 그 의존성이 없으면 서비스를 만들 수 없어서 의존성에 묶이는 건 완전히 다른 이야기 입니다.
모든 코드에 대해서 가능하진 않겠지만(운영체제라던가) 최대한 전자 쪽으로 나아가도 노력하는 게 시스템을 이해하는데 도움이 될겁니다.
속담에는 담겨진 뜻이 있는 건데 단어로만 해석하는 사람들이 많아짐
저런 주장 유행 타면 또 아무렇지도 않게 회의실 난장판됨
페이퍼워크 쟁이들 신나서 날뛰고 같은 실패를 매년 또 반복함
Hacker News 의견
-
나는 특정 분야에서 내 스스로 바퀴를 새로 만든 경험을 가짐. 처음부터 그렇게 하려고 했던 건 아니고, 기존 기술이 잘못되었다고 생각해서였음. 보통 불가능하다고 하는 문제를 분할 정복 방식으로 접근함. 운이 좋았고, 고집이 셌기에 결국 성공함. 내 바퀴가 그 분야에서 압도적으로 뛰어난 성능을 보임. 실험해 보니 기존엔 불가능하다고 생각된 일들도 매우 쉽게 할 수 있게 됨. 시간이 지나면서, 그 분야의 다른 사람들도 내 바퀴를 사용하기 시작함. 처음에는 모두 어리둥절해 하지만, 한 번 익히고 나면 다시는 이전으로 돌아가지 않음. 전 세계에서 이상한 사용 사례와 워크플로에 대한 버그 리포트와 기능 요청을 받음. 나를 직접 만날 리 없던 똑똑한 사람들과 깊은 기술적 대화를 나눔. 내가 만든 바퀴로 남들이 상상하지 못한 성과를 이루는 것들을 목격함. 밤잠을 설치게 만드는 새로운 발견을 하게 됨. 내 동료들이 내 바퀴의 기능을 설명받고 머리가 얼어버리는 걸 보는 재미도 있음. 바퀴를 새로 만드는데 두려움 가질 필요 없음. 어떤 미친 길로 굴러갈지 아무도 모름
- 이 바퀴가 뭔지 너무 궁금함
-
기존 바퀴를 더 좋게 만든다는 것 말고, 정말 중요한 이유가 하나 빠졌다고 생각함. 바로, 나한테 꼭 맞는 바퀴를 만들 수 있고 또 그 상태로 계속 쓸 수 있다는 점임. 사람들이 '똑같은 바퀴를 재발명하지 말라'며 종종 자동차 바퀴를 자전거에 억지로 끼려는 걸 자주 봄. 내 시스템의 모든 부분이 잘 맞게 직접 만들면 생각보다 큰 이득을 얻을 수 있음
-
바퀴를 다시 만드는 중요한 이유 중 하나는 쓸모없는 의존성들로 인해 복잡함이 불필요하게 추가되는 걸 피하고자 함
-
이 말에 완전 공감함. 유명한 라이브러리는 다양한 상황에 문제를 해결해주기 때문인데, 그래서 오히려 불필요한 코드가 잔뜩 포함된 경우가 많음. 중요한 건, 내가 짧은 시간 내에 필요한 기능을 만들 수 있다면, 직접 만드는 편이 사용성에도 좋고 의존성도 최소화됨. 단, 암호화 라이브러리만큼은 직접 만드는 거 절대 비추함
-
내가 바퀴를 다시 만드는 가장 큰 이유임. 의존성에는 원하지 않는 여러 기능이 같이 딸려옴. 난 단순히 동네 슈퍼 다녀올 정도의 기능만 필요함. 그리고 개인적으로는 투명하지 않은 코드를 믿지 않음. 의존성을 써도, 내가 직접 하루만 투자하면 만들 수 있는 수준이고, 검토도 가능해야 함. 소스 코드를 볼 수 없는 실행 파일은 돈을 주고 사지 않는 한 쓰지 않음. 무료라면 반드시 소스 코드가 공개돼야 함
-
나는 DAG(방향 비순환 그래프) 기반 태스크 러너 라이브러리를 직접 만듦. 태스크는 큐에 속할 수 있도록 함. 데모를 웹 브라우저에서 실행하고 싶어 IndexedDB 백엔드를, Electron 앱에서는 SQLite를, 멀티유저 서버 환경에는 Postgres 백엔드를 각각 구현함. 그리고 속도 제한용 limiter도 추가함. 이외에도 그래프 처리나 태스크 처리 등 여러 바퀴를 직접 만들어야 했음. 완전 의존성 없이 만들려면 정말 할 일 많음. 하지만 TypeBox로 태스크 입출력 스키마를 만들고 검증하는 브랜치를 따로 두고 있음. 결국 핵심에 또 다른 의존성이 추가될 수도 있을 것 같음
-
또 다른 이유는, 새로운 걸 발명하거나 연구하는 능력을 연습으로 단련할 수 있기 때문임. 이미 풀린 문제로도 충분히 연습 가능함
-
때로는 불필요한 추상화나 모듈화 같은 복잡성을 피하려고 바퀴를 다시 만듦
-
-
같이 고민해볼 만한 좋은 에세이였음. 나도 비슷한 경험을 했는데, 파이썬과 넘파이만 써서 PyTorch 스타일의 머신러닝 라이브러리(ml-by-hand)를 처음부터 만들었음. 작은 autograd 엔진으로 시작해서, 레이어, 옵티마이저, 데이터로더 등 단계적으로 직접 구현함. 순수하게 기본 원리를 배우고 싶어서 시작함. 직접 만든 이 라이브러리로 고전적인 컨볼루션 신경망(cnn example)부터 간단한 GPT-2(gpt2 example)까지 따라 만들어봄. PyTorch나 TensorFlow의 추상화 없이 머신러닝이 내부적으로 어떻게 동작하는지 훨씬 잘 이해하게 됨. 내가 다시 만든 바퀴로 또다시 자동차까지 스스로 만들어본 셈임
-
“바퀴를 다시 만들지 말라”는 말을 주로 하는 사람은 두 부류라는 말에 덧붙이자면, 실은 세 번째, 훨씬 흔한 부류가 있다고 생각함. 바로, 바퀴 재발명의 고충을 실제로 알고 그 과정을 겪어도 굳이 직접 해볼 가치가 전혀 없다고 판단하는 사람임. 교육적이든 뭐든 직접 해볼 가치가 없다고 여김
- 나는 이런 부류가 더 현실적으로 다가옴. 이들은 기존 방식이나 현상 유지를 무작정 신뢰하기보다는 오히려 기존 방식을 두려워하는 경향이 있음
-
바퀴를 새로 만드는 게 최고의 학습 방법임. 하지만 그건 학습 맥락에서만 그렇다고 생각함. 나도 뭔가에 깊이 파고드는 걸 좋아하지만 회사에서 마감이나 다른 제약을 지켜야 하기에 탐구를 맘껏 못하는 상황이 많음. 만약 만든 바퀴를 실제로 서비스에 쓸 거라면 기존 것보다 정말 뛰어나야 쓸 수 있다고 봄
-
직장에서 바퀴를 다시 만드는 사람들 중 99%는 기존 바퀴가 어떻게 만들어지는지, 왜 그런 타협 구조를 갖는지조차 제대로 모르는 경우가 대부분임
-
직접 만드는 게 꼭 최고의 학습법은 아님. 시간과 비용이 많이 들기 때문임. 잘 정리된 문서와 실험 환경이 있으면 충분히 배울 수 있음. 지식 전달의 명확성 자체가 별도의 숙제임. 굳이 전체를 바닥부터 또 만들 필요는 없음
-
-
정부 시스템을 글로벌하게 새로 구현하는 실험을 하는 중임. 실제 정부와는 다름. 예를 들면 ua.gov-ai.co, ua.ai-gov.co, ng.gov-ai.co, ng.ai-gov.co 등이 있음. 현재까지 CBER와 DDP의 진척도가 가장 높음. 현재 422개 기관까지 진행함. Juneteenth까지 끝내고 싶음. 이런 식으로 기초를 다시 만들면서 근본적인 원리 이해에 도움 얻고 있음. 실제로 뭔가 결과물이 나오지는 않을 것을 알지만, 본질이 변할 때마다 내 생각을 재정립하는 데 유익함. 바퀴를 다시 만들어 보는 실험은 언제나 의미 있다고 봄
-
스타트업에서 일한다면 이런 조언은 가급적 무시해야 한다고 생각함. (단, 새로 만드는 바퀴가 내 서비스의 핵심 성능이라면 예외임.) 그렇지 않으면 한정된 자원만 낭비해서 사업이 시작도 못 하고 끝날 가능성 높음
-
그럼에도 스타트업에는 바퀴를 직접 만들어 본 경험이 있는, 즉 제대로 바퀴를 만들 줄 아는 사람들과 함께하는 게 중요하다고 봄. 오픈소스나 개인 프로젝트로라도 경험이 있어야 함
-
이런 조언은 직업적으로가 아니라, 개인적 학습 목적의 바퀴 실험을 위한 것 같음
-
-
친구가 해준 명언이 생각남. “바퀴를 다시 만드는 이유는 더 많은 바퀴가 필요해서가 아니라 더 많은 발명가가 필요해서다.” 새로운 개념을 배우기 위해 직접 만들어 보는 과정에서 머리도 마음도 안정감을 얻었던 경험이 많음. 파인만의 “내가 만들 수 없으면 내가 이해한 게 아니다”라는 명언을 접하면서 이런 경험과 신념이 더욱 강해짐. 바퀴를 다시 만드는 과정마다 처음 개념에 대한 직관이 더 강해지고, 전혀 몰랐던 내용도 새롭게 배움
-
중복을 지나치게 배척하는 분위기가 우리 시대의 문제라고 봄. 모두 똑같아지고, 같은 음식 먹고, 비슷한 직업에 종사하며, 비슷한 필요에 따라 움직임. ‘바퀴 재발명 금지’ 같은 메시지를 극단까지 밀어붙이면, 결국은 특정 부자 몇 명의 특화된 요구를 맞추기만 하는, 아무것도 모르는 사람이 되는 게 최종 지향점일 수도 있음. 더 이상 요리도, 농사도, 사랑조차도 배우지 않는 삶임
- 그렇다고 “바퀴를 다시 만들지 말라”는 말이 무비판적이거나 항상 쉽게 가라는 뜻은 아님. 예를 들어 자동차 타이어가 펑크 나면, 바퀴에 대한 다양한 선택지를 충분히 고려해야 함. 바퀴를 굳이 다시 만들 필요는 없음. 스페어 타이어가 제공되는 것도 다 이유 때문임. 제조사의 것보다 내가 직접 급하게 만든 바퀴가 더 나을 가능성은 거의 없음