만들기 전에 스스로를 말리는 순간
개발자라면 한 번쯤 겪는 장면이 있어요. 뭔가 만들고 싶은 아이디어가 떠올랐는데, 검색해 보니 이미 비슷한 게 있어요. 그것도 훨씬 잘 만들어져 있고 사용자도 많아요. 요즘엔 여기에 핑계가 하나 더 붙었죠. ‘이거 AI한테 시키면 10분이면 나오는데 내가 굳이?’ 그렇게 브라우저 탭을 닫고, 아이디어는 조용히 사라져요.
개발자 조엘 오터(Joel Otter)가 쓴 ‘Fuck it, make it anyway’는 바로 이 순간을 정면으로 다루는 글이에요. 제목이 곧 결론이에요. 이미 있든, 더 잘 만든 게 있든, 기계가 더 빨리 만들든, 그냥 만들라는 거죠. 거친 제목이지만 던지는 질문은 꽤 진지해요. ‘만든다’는 행위의 가치가 결과물의 희소성에서 나오는 거냐, 아니면 다른 데서 나오는 거냐 하는 질문이거든요.
우리가 만들기 전에 멈추는 세 가지 이유
첫째, ‘이미 있어요’. 할 일 관리 앱, 정적 사이트 생성기, 마크다운 에디터. 세상에 없는 도구를 찾는 게 더 어려워요. 그래서 ‘바퀴의 재발명’이라는 말이 욕처럼 쓰이죠.
둘째, ‘나보다 잘하는 사람이 있어요’. 오픈소스 세계에선 어떤 분야든 그 분야에 10년을 쏟은 사람이 있어요. 그 사람 코드를 보고 나면 내 코드가 초라해 보여요.
셋째, ‘AI가 더 빨리 만들어요’. 이건 최근 2~3년 사이에 생긴 새 핑계예요. 코딩 에이전트에게 설명만 하면 프로토타입이 나오니까, 내가 손으로 짜는 시간이 낭비처럼 느껴져요.
이 세 가지는 겉보기엔 합리적이에요. 근데 공통점이 있어요. 전부 ‘결과물’만 보고 판단한다는 거예요. 만드는 과정에서 생기는 것들은 계산에 안 넣어요.
만들어서 얻는 건 결과물이 아니에요
이게 뭐냐면, 뭔가를 직접 만들면 결과물 말고 세 가지가 남아요.
이해가 남아요. HTTP 서버를 라이브러리로 쓰는 것과 소켓부터 직접 짜 보는 건 완전히 달라요. 책으로 열 번 읽어도 안 잡히던 게, 직접 짜다 막히는 순간 딱 잡히거든요. ‘Build your own X’ 류의 저장소가 꾸준히 사랑받는 이유가 그거예요. 이미 있는 걸 다시 만드는 게 목적이 아니라, 만들면서 머리에 구조가 생기는 게 목적이에요.
취향이 남아요. 직접 설계 결정을 내려 보면 ‘왜 저 유명한 도구는 저렇게 만들었지?’가 보이기 시작해요. 그 결정에 동의하거나 반대할 수 있게 돼요. 남의 코드를 읽기만 하면 이게 안 생겨요.
내 것이라는 감각이 남아요. 아무리 작아도 내가 끝까지 만든 물건은 내 이름표가 붙어요. 이걸 포트폴리오라고 부르든 자존감이라고 부르든, 개발자로 오래 버티는 데 꽤 중요한 연료예요.
AI 시대에 이 말이 더 무거워진 이유
AI가 코드를 뽑아주는 시대엔 ‘내가 만든다’의 의미가 달라져요. 두 가지 방향으로요.
하나는 문턱이 확 낮아졌다는 거예요. 예전엔 ‘하고 싶은데 못 하는’ 게 많았다면, 지금은 설명만 잘하면 뭐든 초안이 나와요. 그러니까 만들지 않을 핑계가 오히려 줄어든 셈이에요. 도구가 좋아졌으니 더 많이 만들면 되는 거죠.
다른 하나는 반대로, 직접 짜는 경험이 더 희귀해졌다는 거예요. 요즘 흔히 말하는 ‘바이브 코딩’ 방식으로 결과물은 얼마든지 뽑을 수 있어요. 근데 생성된 코드를 읽고 판단할 수 있는 사람과 없는 사람의 격차는 오히려 벌어져요. 판단력은 직접 만들어 본 경험에서 나오거든요. AI를 잘 쓰기 위해서라도, 한 번쯤은 손으로 만들어 본 사람이 유리해요.
그래서 ‘AI가 있는데 왜 만들어?’와 ‘AI가 있으니까 만들어야지’는 같은 사실에서 정반대 결론을 뽑는 거예요. 제목이 어느 편인지는 분명하죠.
이미 있는 걸 다시 만들어서 세상을 바꾼 것들
업계 역사를 보면 ‘이미 있는데 왜 만들어’를 무시한 프로젝트가 주류가 된 경우가 넘쳐요.
리누스 토르발스가 리눅스를 처음 공개할 때 쓴 문장이 유명하죠. ‘그냥 취미로 하는 거고, GNU처럼 크고 전문적이진 않을 거예요.’ 이미 유닉스도 미닉스도 있던 시절이었어요. Git도 마찬가지예요. 버전 관리 도구는 이미 SVN이 있었고 BitKeeper도 있었는데, 몇 주 만에 다시 만들었죠.
최근 사례도 있어요. 웹팩이 사실상 표준이던 시절에 Vite가 나왔고, Node.js가 멀쩡히 있는데 Bun이 나왔어요. C가 50년째 쓰이는데 Zig가 나왔고요. 전부 ‘이미 있잖아’라는 말을 들었던 프로젝트예요. 이 프로젝트들의 공통점은 처음부터 세상을 바꾸려고 시작한 게 아니라는 점이에요. 만든 사람이 자기 불편함을 해결하려고, 혹은 그냥 궁금해서 만들었어요.
물론 대부분의 사이드 프로젝트는 아무도 안 써요. 그래도 만들라는 게 이 제목이 하는 말이에요. 세상을 바꾸는 건 부산물이고, 만든 사람에게 남는 건 확실하니까요.
한국 개발자에게 주는 시사점
한국 개발 문화엔 특히 이 얘기가 필요해요. 포트폴리오 압박이 크다 보니 ‘남들이 인정할 만한 결과물’에 집착하기 쉬워요. 그래서 ‘이미 있는 걸 왜 만들었어요?’라는 면접 질문이 무섭죠. 근데 이 질문의 좋은 답은 ‘없어서요’가 아니라 ‘이걸 만들면서 이런 걸 배웠고, 이 결정은 이렇게 했어요’예요. 면접관이 보고 싶은 건 희소성이 아니라 판단 과정이거든요.
클론 코딩도 다시 볼 필요가 있어요. 강의 따라 치기만 하면 ‘만들었다’는 느낌은 들지만 남는 게 적어요. 대신 강의 없이, 원하는 도구를 스스로 설계 결정을 내리면서 만들어 보세요. 작게, 끝까지, 공개하는 게 핵심이에요. 완성도가 낮아도 README 한 장 붙여서 올리면 그 순간 그게 ‘내 것’이 돼요.
실무 팁 하나만 덧붙이면, 매일 쓰는 도구 중 하나를 골라서 최소 기능만 직접 구현해 보세요. 라우터, 캐시, 태스크 큐, 뭐든 좋아요. 주말 하루면 충분하고, 그 도구를 쓸 때 보이는 게 달라져요.
정리
한 줄 요약: 이미 있어도, 남이 더 잘 만들어도, AI가 더 빨리 만들어도, 직접 만든 사람에게만 남는 이해와 취향이 있으니 그냥 만들어라.
여러분은 최근에 ‘이미 있는데’라는 이유로 접은 아이디어가 있나요? 반대로 그냥 만들어 봤다가 예상보다 많이 배운 경험이 있다면 어떤 거였는지 궁금해요.
🔗 출처: Hacker News