호기심과 장인정신에서 메트릭·수익 중심으로 이동한 개발자 문화의 변화를 성찰하고, 잃어버린 창의성과 주인의식을 되찾자고 제안한다.
읽는 데 12분
2025년 9월 18일 목요일
만지작거리던 팅커러에서 메트릭 추구자로: 개발자 문화의 변화가 혁신과 창의성에 미치는 영향
개발 문화 팟캐스트
혁신 전략 컨설팅
소프트웨어 개발을 꽤 오래 해온 사람이라면, 개발자들이 단지 호기심과 학습 욕구, 혹은 어떤 주제에 대한 개인적인 관심만으로 독특하고 혁신적인 제품과 프로젝트를 내놓던 시절을 기억할 것이다.
이러한 호기심과 문제 해결 마인드는 오늘날까지도 우리가 사용하는 최고의 도구들을 탄생시켰다. VLC, Linux, Git, Apache HTTP Server, Docker(논쟁의 여지는 있지만) 등 수없이 많다.
디자인 씽킹 워크숍
소프트웨어 개발 과정
이 도구들은 대기업이나 MMR이나 ARR를 늘리려는 1인 기업가가 만든 것이 아니었다. 자신이 가진 독특한 문제를 해결하고 싶거나 그냥 새로운 것을 배우고 싶었던 호기심 많은 개발자들이 만들었다.
2000년대(2003-2009) 내가 새로운 기술, 프레임워크, 프로그래밍 언어를 만지작거리며 보냈던 밤들을 아직도 기억한다. 종종 밤늦게까지 깨어 있으면서 호기심과 소프트웨어 개발이라는 공예 자체를 더 배우고 싶은 욕구에 이끌렸다. 나만을 위한, 어리석어 보이는 프로젝트와 기묘한 지름길을 만들곤 했다. 단지 할 수 있으니까, 될지 안 될지 보고 싶어서였다. 설령 나 말고는 아무에게도 쓰이지 않더라도, 그저 재미있었기에 만들었다.
혁신 전략 컨설팅
소프트웨어 개발 과정
분명한 목적이나 목표, 심지어 여정 끝의 보상을 기대하지 않고 배우는 데에는 나름의 가치가 있다. 특정 결과물을 반드시 내야 한다는 압박 없이 새로운 아이디어와 개념을 탐험하게 해주기 때문이다. 최적이 아닌 구현이나 다소 엉뚱하고 무모한 해결책도 마음껏 만지작거릴 수 있게 해준다.
여정의 끝에서 “수동 소득을 낳을 제품/서비스를 만들지 못했다”거나 “수십만 명이 쓰지 않는다”는 실망이 기다리지 않는다. 애초에 그런 기대를 하고 시작한 게 아니기 때문이다. 그냥 호기심이 생겨, 심지어 타깃 사용자가 오직 자기 자신뿐이더라도 무언가를 만들고 싶어서 시작했을 뿐이다.
디자인 씽킹 워크숍
이런 방식은 오히려 더 나은 학습 여정과 더 풍성한 경험을 준다. 특정 결과를 내야 한다는 제약이나 기대에 묶이지 않으니, 자신의 속도와 방식으로 탐험하고 배울 수 있다. 이것이 신입이나 주니어에게만 해당한다고 오해하지 말자. 모든 개발자, 가장 숙련된 이들에게까지 해당되는 이야기다.
개인적으로 나는 소프트웨어 개발 분야에서 꽤 경험이 있다고 생각한다. 2003년에 C++을 배우기 시작했고, 2008년에 소프트웨어 개발자로 첫 직장을 얻었다. 시간이 흐를수록 내가 모르는 게 더 많다는 사실을 절감한다. 배울 것도, 탐구할 것도 끝이 없고, 새 기술이든 오래된 기술이든 끊임없이 만지작거리게 된다. 배움은 새롭고 번쩍이는 기술만을 의미하지 않는다. 때로는 어셈블리, 시스템 설계, 마이크로컨트롤러, 임베디드 같은 것들이기도 하다.
소프트웨어 프로젝트 템플릿
소프트웨어 개발 과정
이건 정말로 간단히 말해 팅커러의 사고방식이고, 이런 마인드가 소프트웨어 개발 분야에서 천천히 사라지고 있다고 믿는다. 같은 생각을 가진 사람은 점점 줄고, “그런 데 시간 낭비하지 마. X, Y, Z에 집중해야지.”라거나 “그건 경력에 도움이 안 돼.”, “수동 소득을 낳거나 수십만 명이 쓰는 제품을 만드는 데 집중해야지.” 같은 반발만 더 자주 들려온다.
지난 10여 년 사이 개발자 문화가 크게 바뀌었다고 느낀다. 메트릭, 매출 최적화, ‘가치’ 제공, ‘대중을 위한 빌드’ 쪽으로 강하고도 우려스러운 이동이 있었다. 좋은 변화인지 확신할 수는 없지만, 분명 일어나고 있다.
소프트웨어 개발 과정
개발 문화 팟캐스트
초점이 호기심, 학습, 멋진 것을 만드는 즐거움에서 메트릭과 관측 지표, 니치 오디언스를 위한 문제 해결로 옮겨간 듯하다.
여가 시간에 즐겁지도 않은 기술을 써서, 관심도 없는 제품을, 이해하지 못하는 대상에게 만들고 있는 개발자들을 정말 많이 본다. 그게 소프트웨어 개발자로서 성공하거나 업계에서 진지하게 인정받기 위해 “해야 할 일”이라고 믿기 때문이다.
많은 이들이 이렇게 하면 남들과 차별화될 거라고, 자신은 임시로 좌절한 스타트업 CTO/창업자라고, 혹은 다음 세상을 뒤흔들 큰 무언가를 만들고 있어 동료들의 명성과 존경을 얻게 될 거라고 믿는다.
소프트웨어 프로젝트 템플릿
하지만 정작 자신이 신경도 쓰지 않는 것을 어떻게 거대한 것으로 키우겠는가? 해결하려는 문제가 자신에게조차 문제도 아니거나, 더 나쁘게는 아예 관심조차 없다면 말이다.
여기서 더 깊은 문제가 드러난다. 만들고 있는 것에 애정이 없으면, 진척과 성취, 심지어 정체성을 다른 데서 찾기 시작한다. 자신을 Next.js 개발자, React 개발자, Rust 개발자 등으로 규정한다. 문제를 어떻게 푸는지, 무엇을 창조하는지가 아니라, 사용하는 도구로 자신을 규정하기 시작한다.
여기까지 읽으며 공감한 부분이 있다면, 스스로에게 솔직히 물어보자. 제품이나 프로젝트를 하다가 “방금 나온 저 프레임워크/라이브러리/모듈/플러그인이 훨씬 낫다. 지금 쓰는 것 대신 그걸 써야 한다. 스택을 최신으로 업그레이드해야 한다. 나는 언젠가 수십만 명이 쓰게 될 것을 만들고 있으니 성장을 막을 이유가 없다. 뒤처질 위험을 감수할 필요가 없다.”라고 생각해 본 적이 얼마나 자주 있는가?
자연스럽게도 웹앱은 최신 최적화가 들어간 React나 Next.js를 써야 한다. 1년 전쯤(2023-2024)에는 그게 React 서버 컴포넌트였다.
혹은 새 버전의 Vue.js나 Angular로 갈아타야만 했을 수도 있다. 삶을 편하게 해주거나 앱을 더 빠르고 확장 가능하게 해 준다는 새 기능 때문에.
또는 유틸리티나 백엔드를 Go, Node, C#으로 썼다면, 이제는 Rust로 옮겨야 한다고 느꼈을 수도 있다. 정말 엄청 빠르고 메모리 효율적이니까. 그걸 마다할 수 있겠는가?
그래서 자신을 현재 쓰는 언어, 프레임워크, 라이브러리 이름으로 호명하기 시작한다. 더 이상 ‘소프트웨어 개발자’가 아니라, 자신의 분야 ‘스페셜리스트’인 Next.js 개발자가 된다.
소프트웨어 프로젝트 템플릿
그리고 반짝이는 새것마다 쫓으며, 그 반짝이는 것으로 제품이나 서비스를 만들고 MMR, ARR, DAU, MAU, SEO 순위, 전환율 등 온갖 지표를 최적화한다. 그런데 왜 제품이나 서비스가 뜨지 않는지, 아무도 쓰지 않는지, 왜 모멘텀이 생기지 않는지 의아해한다.
이상하지 않은가? 써야 할 ‘정답’ 기술을 썼고, 최적화해야 할 ‘정답’ 지표를 최적화했으며, 책에 나온 대로 모두 했다. 그런데 왜 작동하지 않는 걸까?
영감도 주지 않고 애정도 없는 최신·최고를, 그저 성공하려면 그래야 한다고 믿어서 채택하는 관성은 재앙의 레시피다. 개인에게만이 아니라 개발자 문화 전체에.
개발 문화 팟캐스트
과장하고 싶지는 않지만, 아무도 관심 갖지 않아도 그저 멋진 무언가를 만들고 싶어 하던 호기심 많은 개발자, 팅커러, 집요한 크리에이터의 부재를 애도한다.
우리는 이 마인드를 서서히 죽이고 있다. 문화에서 천천히 사라지는 중이다. 그게 좋을지 나쁠지는 시간이 말해 주겠지만, 내게 묻는다면 아주 나쁜 일이라고 말하겠다.
간혹 반짝이는 혁신과 창의의 불꽃이 있다. HTMX, Bun, Astro, Zig 등이 떠오른다. 드물지만 여전히 호기심 많은 개발자들이 있음을 보여준다. 다만 찾기 어려워졌고, 숫자는 줄어들고, 메트릭 추구와 수익 최적화의 소음에 묻히고 있다.
디자인 씽킹 워크숍
개발 문화 팟캐스트
변화하는 세상을 한탄하는 중년 남성처럼 들리고 싶지는 않다. 세상은 변하고, 나이를 먹을수록 냉소도 커진다는 걸 안다. 하지만 이건 그런 이야기가 아니다. 한동안 관찰해 온 패턴이고, 그래서 걱정스럽다. 호기심 많은 개발자들이 만든 도구와 프로젝트는 여전히 존재하고 사용되지만, 예전과 견주면 순수한 호기심과 열정에서 나온 새것은 상대적으로 적다.
가끔은 불꽃이 일지만, 예전 같지는 않다.
지금 당신이 쓰는 놀라운 소프트웨어들을 떠올려 보라. 그중 얼마나 ‘말도 안 되게’ 호기심 많은 개발자들이 만들었는지, 그것들이 얼마나 오래되었는지(언제 나왔는지) 생각해 보라. 그리고 더 현대적인 소프트웨어들을 떠올려 보라. 그중 얼마나 대기업이나 1인 기업가가 만들었는지, 혹은 그냥 사들여졌거나 팔려나갔는지 생각해 보라.
우리 문화에서 매우 중요한 무언가를 잃어가고 있다고 생각한다. 늦기 전에 다시 찾을 수 있기를 바란다. 호기심 많은 개발자가 영영 사라지고, 프라이버시는 안중에도 없고, 끔찍한 수익화 전략과 비대한 프레임워크/라이브러리, 소유 의식은 사라진—소비자에게도, 창작자에게도—소프트웨어의 바다만 남기 전에.
흐름이 바뀐 건 모두가 본 바다. 소비자는 더 이상 소프트웨어를 소유하지 않는다. 최신 Adobe 제품군이나 JetBrains IDE, 최신 아이폰이나 안드로이드, 심지어 최신 윈도우를 사더라도 소유하는 게 아니다. 언제든 빼앗길 수 있고, 그저 월 구독료를 내고 ‘빌려’ 쓸 뿐이다. 소유가 아니라 사용 라이선스를 가진 것이다.
하지만 창작자의 소유권 상실에 대해서는 얼마나 생각해 보았나? 이 도구와 소프트웨어를 만든 개발자, 호기심 많은 팅커러, 집요한 크리에이터들 말이다. 그들은 소유하는가? 아니면 가장 높은 값을 부르는 이에게 임대하거나, 가장 큰 기업에 팔아버리는가? 사람들은 여전히 자신만의 고유한 것을 만들고 싶어 하는가, 아니면 대중에게 임대할 최신·최고의 SASS를 만들고 싶어 하는가?
그들이 만드는 소프트웨어를 정말로 아끼는가, 아니면 메트릭·매출·성장만을 신경 쓰는가?
Linus Torvalds는 리눅스를 소유하고, 리눅스 커널을 아낀다고 말할 수 있다. Jean Baptiste Kempf는 VLC를 소유하고, VLC를 아낀다고 말할 수 있다. Solomon Hykes는 Docker를 소유하고, Docker를 아낄까? Daniel Ek는 Spotify를 소유하고, Spotify를 아낄까? Mark Zuckerberg는 Facebook을 소유하고, Facebook을 아낄까?
그들은 자신이 만든 제품의 진정한 ‘주인’인가, 아니면 자신의 창조물의 ‘임차인’이 되어 메트릭과 매출 최적화의 노예가 되었는가?
다시 말하지만 과장하려는 건 아니다. 하지만 우리 모두가 스스로에게 던져야 할 중요한 질문이다. 세상이 바뀌고 개발자 문화가 메트릭과 매출 최적화로 기우는 것을 보며, 나 자신도 이 질문을 점점 더 자주 던지고 있다.
부디 삶 속에서 호기심과 창의성을 위한 시간을 마련하자. 그냥 만들기 위해 만드는 것, 만지작거리는 것에 시간을 쓰자. 아무도 관심을 갖지 않아도, 오직 자신의 문제만 해결하더라도 좋다. 멋진 것을, 유일한 것을 만들어라. 남의 시선을 신경 쓰지 말고, 스스로를 위해 만들어라. 만들고 싶고, 만들 수 있으니까 만들어라.
세상이 무엇을 해야 한다, 무엇을 만들어야 한다, 무엇을 써야 한다고 말하도록 두지 말자. 남들에게 아무리 야심 차거나 멍청해 보이더라도 상관없다. 하고 싶어서, 행복해져서, 살아 있음을 느끼게 해 주니까 하자.
소프트웨어 개발은 독특한 공예다. 창의와 공학이 반반 섞여, 서로 반대되는 힘이 합쳐질 때 진정 놀라운 것을 만들어낼 수 있다. 여기에 마케팅을 끼워 넣어 공예를 희석하려는 유혹과 싸우자.
늘 마음에 품고 있던 프로젝트가 있는가? 아무도 쓰지 않을 것 같아서, 돈이 되지 않을 것 같아서, 그래서 해볼 이유가 없다고 느꼈던가? 그래도 하라. 만들어라. 만지작거려라. 거기서 배워라. 대중에게 출시할 수 없으면 어떠랴. 쓸모없으면 어떠랴. 그냥 만들어라. 무(無)에서 유(有)를 창조하라. 그저 만들 수 있으니까.
이게 앞서 한 말과 모순된다고 느낄지 모르지만, 전혀 아니다. 당신의 작업을 공유하라. 당신의 창작물을 나눠라. 다른 이들을 당신의 세계로 초대하라. 아무 반응이 없더라도 상관없다. 당신은 만들었다. 무에서 유를 창조했다. 어쩌면 가치는 목적지가 아니라 여정에 있을지 모른다. 결과가 아니라 배움에 있을지 모른다. 제품이 아니라 과정에 있을지 모른다.
그리고 누가 아는가. 당신의 독특한 문제가 사실 다른 이들의 문제일지, 당신의 독특한 해결책이 누군가에게 영감을 줘서 전혀 새로운, 유일한 무언가를 만들어내게 할지. 당신의 호기심이 누군가에게 불씨가 되어, 정말 놀라운 걸 창조하게 만들지.
불가능한 일은 아니다. 리눅스에도 그랬고, VLC에도 그랬다. 심지어 Git에도 그랬다.
SVN이 잘 정착되어 널리 쓰이던 시절에, 분산 버전 관리 시스템이라는 발상이 얼마나 터무니없는 아이디어였는지 상상해 보라. 제정신인 누가 그게 좋은 생각이라고 했겠는가? 그런데 지금 우리는 소프트웨어 개발에서 버전 관리의 사실상 표준으로 Git을 쓴다.
이 글은 우리 개발자 문화에서 호기심의 불꽃이 사라져 가는 것을 애도하기 위해 썼다. 누군가를 비판하거나 심판하기 위해서가 아니다. 세상은 변하고, 우리는 생계를 꾸리고, 청구서를 지불해야 한다는 사실을 안다. 하지만 동시에 소프트웨어 개발을 독특하고 특별한 공예로 만드는 본질을 잃지 않아야 한다고 믿는다.
여기까지 읽어준 당신에게 진심으로 감사한다. 내 글 중에서도 긴 편인데, 시간을 내어 읽어줘서 고맙다. 이 글이 당신 안에 무언가를 일깨웠기를, 소프트웨어 개발자로서 자신의 여정을 돌아보게 했기를, 다시금 호기심과 창의성을 품게 했기를 바란다.
