20P by GN⁺ 16시간전 | ★ favorite | 댓글 6개
  • 과거에는 호기심과 탐구심이 독창적이고 혁신적인 도구들을 만들어냈지만, 오늘날 개발 문화는 점차 지표와 수익 중심으로 이동하고 있음
  • 예전의 개발자들은 단순한 호기심으로 쓸모없을 수도 있는 프로젝트를 만들며 순수한 학습과 실험에 몰두했음
  • 현재는 개발자들이 최신 프레임워크와 수치 최적화에 집착하며, 스스로에겐 흥미 없는 문제를 해결하려는 경향이 강해지고 있음
  • 이로 인해 창의성과 주인의식이 사라지고, 개발자는 점차 도구에 의해 정체성이 규정되는 상황에 놓임
  • 저자는 개발자들이 다시금 호기심을 위한 개발과 틈새 혁신에 공간을 마련해야 한다고 강조함

호기심이 길을 이끌던 시절

  • 소프트웨어 개발 분야에서 오랜 경험이 있는 사람이라면, 개발자들이 단순한 호기심이나 학습을 위해 독창적인 제품과 프로젝트를 출시하던 시대를 기억할 수 있음
    • 이러한 호기심과 문제 해결 사고방식이 오늘날에도 사용되는 최고의 도구들, 예를 들어 VLC, Linux, Git, Apache HTTP Server, Docker 등을 탄생시켰음
    • 이러한 도구들은 대기업이나 솔로프레너가 수익 증가를 목적으로 만든 것이 아니라, 독특한 문제를 해결하거나 새로운 것을 배우려는 호기심 많은 개발자들에 의해 창작됨
  • 2000년대(2003-2009)에는 새로운 기술, 프레임워크, 프로그래밍 언어를 탐구하며 밤늦게까지 실험하는 일이 흔했으며, 자신만을 위한 어리석거나 이상한 프로젝트를 만들어 보는 재미를 느꼈음
  • 목적 없는 학습은 특정 결과에 대한 압박 없이 새로운 아이디어와 개념을 탐구할 수 있게 하며, 비최적화된 구현이나 미친 아이디어를 시도할 자유를 제공
    • 여정 끝에 새로운 제품이나 수익을 기대하지 않기 때문에, 더 나은 학습 경험과 만족감을 주며, 이는 초보자부터 경험 많은 개발자까지 모두에게 적용됨
  • 이러한 tinkerers mindset이 소프트웨어 개발 분야에서 서서히 사라지고 있으며, 주변에서 "시간 낭비"나 "커리어에 도움이 안 돼" 같은 반대를 자주 마주침

메트릭과 반짝이는 것들의 시대

  • 지난 10년 동안 개발자 문화에 강한 변화가 일어나며, 호기심과 창작의 즐거움에서 메트릭, 수익 최적화, 가치 제공, 대중 대상 구축으로 초점이 이동함
    • 이 변화가 좋은지 나쁜지는 확신할 수 없으나, 관찰되는 현상으로서 우려스러움
    • 개발자들이 즐기지 않는 기술로 관심 없는 제품을 만들어 이해하지 못하는 청중을 대상으로 하며, 성공을 위해 해야 할 일이라고 믿음
  • 많은 개발자들이 자신을 차별화하거나 스타트업 CTO가 되기 위해 이런 길을 선택하나, 실제로 관심 없는 문제를 해결하려 하면 진정한 성공이 어려움
    • 관심 없는 프로젝트에서 진척감을 느끼지 못하면, 자신을 Next.js 개발자React 개발자, Rust 개발자처럼 도구로 정체성을 규정하게 됨
  • 최신 프레임워크나 아이디어를 쫓는 현상이 두드러지며, 현재 프로젝트를 중단하고 더 나은 스택으로 전환하려는 충동이 자주 발생함
    • 예를 들어 웹앱에서 최신 ReactNext.js 버전을 사용해야 하며, 2023-2024년에는 React server components가 필수처럼 여겨짐
    • Vue.js나 Angular의 새로운 기능, 또는 백엔드에서 GoNode 대신 Rust로 전환하는 사례가 많아짐
  • 자신을 특정 언어나 라이브러리로 규정하며, MMR, ARR, DAU, MAU, SEO 순위, 전환율 같은 메트릭을 최적화하나, 제품이 성공하지 못하는 이유를 이해하지 못함

우리가 길에서 잃어버린 것

  • 성공을 위해 최신 기술을 무작정 채택하는 것은 재앙의 레시피이며, 개발자 문화 전체에 악영향을 미침
    • 호기심 많은 개발자, tinkerer, 열정적인 창작자가 사라지는 것을 아쉬워하며, 이 사고방식이 사라지면 좋지 않은 결과가 올 수 있음
  • 여전히 HTMX, Bun, Astro, Zig 같은 혁신적인 사례가 있지만, 이는 드물고 메트릭 추구의 소음에 묻히고 있음
    • 이러한 밝은 예시들은 호기심 있는 개발자가 여전히 존재하지만, 수가 줄고 찾기 어려워짐을 보여줌

세상은 움직이지만, 우리 중 일부는 기억한다

  • 중년의 한탄처럼 들리지 않게 하려 하나, 개발 문화에서 호기심이 줄어드는 패턴이 오랫동안 관찰되어 우려됨
    • 과거 호기심으로 만들어진 도구들이 여전히 사용되지만, 새로운 창작물이 상대적으로 적음
  • 오늘날 사용하는 소프트웨어 중 호기심 많은 개발자가 만든 것들의 나이를 생각해 보면, 현대 소프트웨어는 대기업이나 솔로프레너가 만들거나 매각된 경우가 많음
    • 개발 문화에서 중요한 무언가가 사라지고 있으며, 호기심 있는 개발자가 완전히 사라지기 전에 되찾아야 함
    • 그렇지 않으면 프라이버시 문제, 나쁜 수익화 전략, 부풀어 오른 프레임워크, 소유 의식 없는 소프트웨어의 바다가 될 수 있음

소유권의 죽음은 소비자만의 문제가 아니다

  • 소비자들이 소프트웨어를 소유하지 않고 월 사용료를 지불하는 라이선스 형태로 전환된 것은 잘 알려져 있음
    • Adobe suite, JetBrains IDE, 최신 iPhone이나 Android, Windows 등에서 이런 현상이 나타남
  • 창작자 측면에서 개발자들이 자신의 도구를 진정으로 소유하는지, 아니면 최고 입찰자에게 팔아넘기는지 고려해야 함
    • 사람들은 더 이상 독특한 것을 만들기보다는 대중에게 임대할 SaaS를 구축하려 함
    • 메트릭, 수익, 성장에만 관심을 두는 경향이 강함
  • Linus Torvalds는 Linux를 소유하고 관심을 가지지만, Solomon Hykes는 Docker를, Daniel Ek는 Spotify를, Mark Zuckerberg는 Facebook을 진정 소유하고 관심을 가지는지 의문임
    • 창작자들이 자신의 창작물을 메트릭과 수익 최적화의 노예로 만드는 현상이 나타남
    • 이 질문은 개발 문화의 변화 속에서 점점 더 자주 스스로에게 던져야 할 문제임

호기심과 혁신을 위한 공간 만들기

  • 삶의 일정 속에 개인 실험 시간을 확보해 남의 관심과 무관하게 자신만을 위한 무언가를 만들어 볼 것
    • 야심차거나 어리석어 보이는 아이디어를 추구하며 행복을 느끼는 데 초점을 두기
  • 출시할 수 없는 프로젝트라도, 돈이 되지 않거나 쓸모없어 보이더라도 만들어 보는 것이 학습과 창작의 가치를 제공
    • 여정 자체가 가치 있으며, 목적지가 아닌 과정에서 만족을 찾음
  • 야심차건 사소하건 상관없이, 본인이 원해서 한다는 몰입의 즐거움이 핵심임
  • 소프트웨어 개발은 창의×공학이 균형을 이루는 특이한 공예임
    • 여기에 성급한 마케팅을 끼워 넣으면 본질적 탐구와 장인정신이 약화될 위험이 있음

Build what you Can’t Ship

  • 아무도 쓰지 않거나 돈이 되지 않을 프로젝트라도 출시하지 못할 프로젝트로서 과감히 시작해 보고, 만들고, 만지작거리며 배워보길 권함
    • 결과의 유용성보다 호기심에 따른 탐구 학습 자체에 가치를 둘 것
  • 완성물이 대중 출시가 어렵더라도 공유를 망설이지 말고, 타인의 무반응을 두려워하지 말 것
    • 목적지보다 여정, 출력물보다 과정 중심 가치에서 의미를 찾기
  • 개인적 문제의식이 의외로 확산될 수 있으며, 독특한 해법이 타인에게 영감을 주는 파급 효과를 낳을 수 있음
    • Linux, VLC, Git 같은 사례는 개인의 집요한 호기심에서 출발했음
  • 당시 SVN이 표준이던 시절 분산 버전관리라는 발상은 무모해 보였으나, Git은 오늘날 사실상의 표준이 되었음
    • 기존 합리성의 기준에 맞지 않아도 실험이 축적되면 패러다임이 전환될 수 있음

결론

  • 개발 문화는 변하고 있고, 생계와 현실적 요구가 존재하지만 호기심이라는 불씨를 잃어서는 안 됨
  • 독창적이고 창의적인 시도가 사라진다면 소프트웨어는 수익 지향적이고 창의성 없는 제품만 남을 위험이 있음
  • 독자들에게 다시 한 번 호기심 많은 개발자로서의 정신을 되찾기를 권유함

프레임워크의 저주. 특히 웹에서 이런 경향이 지배적인듯. 특정 프레임워크가 개발자의 본질을 좌지우지한다면 이것은 분명 문제다. 퇴행이다

제 생각은 세계적으로 예민해진 경제 생황이랑 새로운 주니어 개발자 유입이 감소해서라고 봄. 기존 시니어들은 나이 먹으니 힘둘고 아니면 육아나 가정 돌보느라 바쁘고 등등의 이유가 있지 않을까 함.

바이브 코딩, SNS랑 유튜브 뜨는것만 봐도 그냥 뭔가 고민을 하기보다는 진짜 최소 동작 코드를 빠르게 붙이고 붙이고 붙여서 아 다했다 이거인것같음.

JetBrains IDE는 년간 구독하면 년간 구독했을 당시 해당 버전 영구 라이센스를 지급하는 걸로 아는데, 끝났었던가요?

여전히 지급합니다. 본문은 아마 jetbrain이 소프트웨어 구독 모델의 선구자라서 언급한 것 같네요

Hacker News 의견
  • 나는 이 글에 공감하지만, 내가 1990년대 이 모든 일이 시작될 때와는 인생의 다른 지점에서 바라보고 있는 건 아닌지도 나 자신을 돌아보게 됨. 그때는 젊고 책임도 별로 없고, 자유시간도 많았음. 지금은 아빠이고, 주택담보대출이 있고, 지역 정치에도 관심이 높아짐—'더 나은 세상을 남기고 싶음' 때문임. 그래도 시간이 지나면서 변화가 있었음은 분명함. 오픈소스가 급부상하던 시절에 자라서 정말 멋졌음. 우리는 세상을 바꿨다고 생각함. 점점 소프트웨어가 주류가 되고, PG의 스타트업 글 같은 선의의 아이디어도 결국 돈을 향한 흐름으로 바뀌기 시작함. 이론적으로는, 해커에게 F U 머니가 있으면 기업 일걱정 없이 학습과 호기심을 추구할 수 있다고 하겠지만, 현실적으로 그 정도 부를 이루는 사람은 아주 드뭄. 지금은 기업 권력이 너무 집중되고 있음. LLM이 개발 역량의 핵심이 되면 이 현상은 더 심화될 위험이 있음. 어쩌면 새로운 방향이 필요할 시기임. 내 나이에는 그 변화를 주도하진 못하겠지만, 변화를 이끌 사람들이 있다면 열정적으로 응원할 것임

    • 이 기사에는 상당히 의심이 듦—딱 '옛날이 좋았다' 식 생각으로 보임 [Good Old Days]. IT가 엄청나게 성장한 건 맞지만, 뭘 하든 크게 흥미 없어 하는 사람은 언제나 일정 비율 있었음. 예를 들어 1998년쯤, 한 동료가 IDE 없이는 컴파일러를 쓸 줄 몰라서 충격을 받았던 기억이 있음. 그런 사람은 그때도 많았을 것임. 그리고 '쓸 만한 새로운 게 없다'는 얘기는 좀 순진해 보임. Hacker News만 봐도 매일 멋진 프로젝트가 나오고 있음. 폭넓게 쓰이지 않을 뿐이지, 앞으로 어떻게 될지는 모르는 일임. 예전에도 Linux가 바로 주류가 된 건 아니었음. 그리고 기업 권력도 결국 흥망성쇠 반복임—Data General, Compaq, DEC, 한때 Microsoft가 최대의 적이었던 시절도 있었음. 덧붙여 말하자면, 지루하고 별 볼일 없는 것도 많이 나오지만, 대부분 잊힐 것임—Sturgeon's law처럼 "모든 것의 90%는 별 볼일 없는 것"임

    • 나는 컴퓨터 프로그래밍이 취미였고, 그걸 하면서 돈을 받는 게 진흙탕에서 노는 돼지처럼 행복했음. 어린 나이에 그렇게 일해서 돈도 받고 정말 신났음. 하지만 90년대 말 컴퓨터 사이언스 전공으로 같이 공부하던 친구들은 거의 다 돈을 목적으로 왔었음. 그때도 대부분 프로그래머들이 돈을 위해 일했음

    • 이런 얘기가 나올 때마다 항상 언급하지만, 내 생각엔 포화 현상 때문임. 언젠가부터 컴퓨터 분야가 '좋은 직업'이 되었고, 그 이후로는 진정으로 호기심 있는 소수만이 눈에 띄게 되어버림. 대부분 그냥 안정적인 월급을 원해서 이 바다에 들어온 것임

    • 아이러니하게도 LLM은 목적 없는 호기심과 학습을 자극하는 존재임. 트위터만 봐도, 사람들이 챗봇을 이상한 상태로 만들고, 새로운 시스템을 실험하거나, 탈옥을 시도하는 걸 자주 봄. 그냥 게임하듯이 재미로 하는 것임. 이런 기술의 경이로움과 호기심을 계속 유지하면서 동시에 위협적인 존재로만 바라볼 순 없다고 여김

    • 예전과 지금의 유일한 차이점은, 이미 해결된 문제가 훨씬 많아졌다는 점임. 그만큼 열정적인 개발자가 실력을 펼칠 수 있는 '빈 공간'이 줄었음. 그래도 나는 예전에 lisp나 Haskell 등에 관심을 갖고 한동안 파본 적 있음. 그리고 아직도 주류 밖에는 해결되지 않은 문제가 많이 남아있음

  • 나는 여전히 여기 있고, 예전만큼이나 호기심이 많음. 정말 호기심 많은 사람에게는 기회가 점점 더 커지고 있음. 예전(2000년 즈음)에 개발자 중 집에 컴퓨터도 없는 사람과 일할 때 한탄했던 기억이 있음. 나는 배우고 싶은 책으로 가득한 책장과, 아이디어만 잔뜩인 하드디스크가 있었는데, 일부 동료들은 퇴근하면 코딩 걱정은 끝, 그걸로 충분함. 25년 지난 지금도 그런 친구 몇 명 알고 있음. 일부는 소프트웨어로 커리어를 쌓기도 했지만, 호기심은 없었음. 그저 수단일 뿐이었음. 나는 그들을 탓하지 않음. 하지만 내 자신은 끊임없이 배우고 성장하고 뭔가를 만들고 싶은 유형임. 내가 요즘 가장 실망하는 점은, 소프트웨어 동료들이 Jira 상태만 바꾸며 출중한 소프트웨어를 만들 생각은 하지 않는 사람 너무 많다는 점임. 엔지니어, 매니저, 임원 모두에서 이런 현상 봄. 나는 정말 유용하고 좋은 소프트웨어를 배포할 때 자기실현 느낌을 받음. 하지만 그들은 그저 바빠 보이는 데에서 만족함. 실제로 가치를 내는 것 같지 않은데, 캘린더만 가득함. 이 현상은 여러 산업에서 전염병처럼 퍼지고 있음. 생산적인 척하면서 실제로는 생산적이지 않은 문화임. 제조업, 농업, 학계 사람들과 얘기해 봐도 다들 비슷한 이야기를 함. Stein's law에 따르면 언젠가는 이 '생산성 연극'도 끝날 것임. 그날이 아름답지 않을까봐 두려움

    • 소프트웨어 동료들이 Jira 상태 업데이트 외에는 대단한 걸 만들 생각을 안 하는 요즘 현상, 사실 새삼스러운 일은 아님. Dilbert 같은 만화가 80년대부터 이런 걸 풍자했음

    • 나는 1996년 첫 직장에 들어갈 때 이미 10년간 취미로 컴퓨터를 만지고 대학도 졸업한 상태였음. 22살의 솔로로 도시로 이사하고, 쓸 수 있는 용돈도 있었던 내게 하루 종일 일하고 퇴근해서 또 컴퓨터 앞에 앉을 생각은 1도 없었음. 30년 개발하면서 자발적으로 코딩한 적은 거의 없음—자선단체 약간 도운 게 전부임

    • "우리가 헤엄치는 바다가 더 크고 깊어졌다"에 동의함. 2000년대엔 소프트웨어 개발이 지금보다 훨씬 작은 분야였고, 초점은 '호기심의 연못' 같은 공간이었음. 그곳에서 모든 개발자가 소소하게 장난치며 놀았음. 지금은 소프트웨어 분야가 거대한 바다로 확장됐고, 저자는 연못이 아닌 바다만 보고 있는 듯함

    • "지금이 훨씬 나아졌다"에 완전 동의함. 나 역시 AI와 짧은 허니문을 거쳤고, 이제 어떤 주제에 대해 AI가 정말 유용한 툴이라는 걸 체감함. 한 달에 $20만 투자하면 원하는 주제를 얼마든지 깊이 파게 해주는 놀라운 경험임. 공부하고 싶은 게 너무 많아서 걱정이지만, 요즘처럼 흥미로운 시대는 없다고 느낌

    • 낮에는 개발하고 집엔 같은 플랫폼의 컴퓨터가 없었던 적도 있음. 어릴 적 집엔 한때 Commodore 64, Tandy, UNIX 워크스테이션 등이 있었지만, 회사에선 Windows NT, Solarix, HP/UX에서 개발했음. 또 다른 도시로 이사하고 회사에서 내부 전용 플랫폼(다시 Windows NT)이랑 Solaris 타깃으로 개발했던 경험도 있음. 예전엔 헤더 파일과 라이브러리가 모두 프로프라이어터리라, 회사가 1인당 라이선스 비용을 어마어마하게 지불해야 했음

  • 전반적으로 동의하지만, 한 가지 반박하자면: 20년 전에는 호기심이 강제적이었음. 코드 저장하는 도구가 필요했는데 마땅한 게 없으면, 주말 동안 Git 같은 걸 만들어야 했음. 지금은 수많은 호기심 많은 개발자 덕분에 정말 멋진 툴이 넘쳐나서, 0에서 1로 만드는 발견은 좀체 쉽지 않음. 여전히 새로운 프론티어를 개척하는 사람은 있음. 내가 크립토를 좋아하진 않지만, 호기심 많은 개발자가 상당수 거기서 보금자리를 찾았음. AI는 진입 장벽이 높지만, 여전히 발견이 이루어지고 있음. 호기심 많은 개발자는 사라지지 않았고, 그저 수많은 월급형 개발자 틈에 가려져 찾기 더 어려워졌을 뿐임—옛날엔 다 호기심 많았다고 느끼는 것도, 결과만 보고 뒤돌아보니 그렇게 보이는 착시 효과라고 생각함

    • 이건 약간 미화임. 20년 전에도 소스 컨트롤, 현대적 도구는 충분히 있었음. 예를 들면 TFS가 2005년에 Microsoft 진영에 나왔음

    • 회사 환경에서 0-1 마인드셋은 사실상 쓸모없음. 대부분의 경우, 그런 혁신은 사장되고 다시 쓰이는 일도 없음. 어떤 신생 인재가 5~6년 뒤 다시 꺼내 쓸지도 모르지만. 우린(즉, 안전망이 없는 사람들은) 90년대처럼 실험하고 탐구할 여유가 없었음. '부자와 영향력 있는 사람들만이 누릴 수 있는 사치'가 돼버림. 물가와 인플레이션은 훨씬 더 높아졌고, 민간 건강보험 같은 미국 시스템에 묶여 있음. 아프면, 실직하면, 진짜 큰일임. 이제 "호기심"의 리스크는 예전보다 훨씬 높아진 상황임

    • 지금은 유행하는 주제(예: AI)에만 호기심을 갖는 개발자도 많아졌음

  • 호기심 많은 개발자가 완전히 사라졌다거나, 유기적이고 비영리적인 웹이 소멸했다는 생각엔 동의하지 않음. 하지만 돈만 보고 배운 개발자들 틈에 진짜 열정 있는 개발자는 눈에 잘 띄지 않게 되었음. 마찬가지로, 순수 열정으로 만든 인디 웹사이트는, 이윤만 추구하는 수많은 사이트에 묻혀 잘 보이지 않음. 한때 소프트웨어 개발자는 기업에서 딱히 높은 대우도 아니었고, 그냥 8비트 오락용 컴퓨터로 게임 개발하며 노는 이상한 취미였음. 정말 컴퓨터 다루는 호기심 많은 사람이 주로 하는 일이었음. 그리고 해커가 영웅 취급받고 천문학적 부를 축적하던 '황금기'가 왔고, 그때 많은 해커들이 성공했음. 그런데 이 흐름이 바로 문화 변질의 계기가 됨—돈을 목적으로 한 사람이 대량 유입됐고, 그 사람들도 실력은 있지만, 동기 구조가 다르기 때문에 문화도 변했음. 지금은 프로그래밍도 목수나 간호사처럼 잘 보상받는 숙련직이 됨. 다시 해커 문화가 그립다면, 별로 잘나가지 않고 돈도 못 벌지만 신기하게 끌리는 마이너한 분야를 찾으라고 조언하고 싶음

    • 일하는 회사의 오너가 아니라면, 회사의 이익을 위한 호기심 따위 필요 없다고 생각함. 과거엔 내 호기심 때문에 밤을 새워서 체크아웃 과정을 개선해 수익이 대폭 올라갔는데, 돌아오는 건 아무것도 없었음. 다른 팀의 앱이 랜덤하게 크래시 나는 걸 해결해 수백만 계약을 성사시켰지만, 고작 감사 인사만 받았음. 호기심은 내 프로젝트에만 쓰길 권장함. 회사엔 최소한만 할 것임

    • 저자가 사실상 웹 개발자라는 걸 드러냄. 새로운 JS 프레임워크 혁신 없다고 혁신과 창의성이 사라진 건 아니라 봄

  • 저자에게 동의함. 핵심 원인은 전체적으로 심리적 안전감 상실임. 안전하다고 느낄 때 사람들은 시간 낭비해도 별 위험 없다고 생각하면서 장난치고 실험하게 됨. 지금의 기후, 경제, 정치 상황을 고려하면 대부분이 불안한 시대임. 미국에서 혁신의 분위기가 절정이었던 시기는 베를린 장벽 붕괴 이후, 9/11 이전의 90년대였다고 생각함. 기술에 대한 흥이 최고였던 시점임. 물론 요즘에도 모두가 넷플릭스, 드라마, 책 읽기 등 시간 낭비를 많이 하지만, 그건 세상에서 '도피'하려고 쓰는 시간과, 창의적으로 세상과 '연결'돼 쓰는 시간은 다름

    • 이 이론을 반박하자면, 60~80년대 정치·경제 상황이 훨씬 더 나빴을 때도 컴퓨팅 혁신의 쓰나미가 있었음. 그때도 기후 문제(대기•수질오염) 심각했음

    • 90년대는 단지 70~80년대 누적된 기술 열정의 정점이었음. 예전에도 베트남전, 석유파동, 냉전, 그래도 다들 열심히 버텼던 시절임

  • 나 자신은 오히려 반대임, 시니어 엔지니어로서 요즘 더 많은 사이드 프로젝트 해보고 있고, 게다가 대부분 완성도 보고 있음. 이제는 새 프로젝트 시작도 더 자신감 있게 하게 됨—최소한 MVP까지는 만든다는 확신이 있어서임. 상업 목적 없이 그저 내가 불편했던 부분을 만지는 게 대부분임. 이유는 3가지임: vibe coding이 덕분에 예전엔 피하던 UI나 CSS 같은 부분까지 덤벼볼 수 있게 해줌, Gemini가 예전엔 골치 아팠던 devops 문제를 쉽게 해결해줌, 그리고 Postgres, docker, node, ollama 같은 오픈소스 스택이 너무 잘 작동함. AI가 이런 고민을 덜어주니, 재미있는 부분에 더 집중할 수 있음. 그래서 예전보다 UI도 멋있게 나오고, 친구나 가족에게 공유할 자신감도 커짐

    • 나도 이 말에 완전 동의함. dev culture 전체가 예전보다 호기심이 줄었을 순 있지만, 전체 호기심 많은 개발자의 절대 수는 오히려 많아졌다고 생각함. 그 장점을 살릴 방법도 분명 있음—다만 노력이 필요할 뿐임. 사실 20년 전에도 tech 분야에서 살아남으려면 노력 필요했을 것임—그 시절 사람들은 단지 젊어서 더 여유가 있었을 수도 있음. 나는 28살임
  • 내 친구는 구글에서 15년 일하다 해고를 당했는데, 지금 40대 중후반임. 최근에 임베디드 시스템과 하드웨어 컨트롤러, Haskell, Erlang 등 완전히 새로운 분야를 파고 있음—웹스케일 DB 아키텍처와는 완전히 다른 영역임. 인생에서 내가 본 중에 가장 행복해 보임. 순수한 호기심을 따라 가는데, 진흙에서 노는 돼지처럼 기뻐함

    • 15년 동안 구글에서 일했다면, 아마 경제적으로 충분히 여유로워서 뭐든 원하는 걸 할 수 있는 상황일 것임

    • 15년 구글 다녔다면 이제 생계 걱정 안 해도 되고, 가족과도 편안히 살 수 있을 정도일 것임. 이런 안정감이 큰 행복의 원인일 듯함

    • 소프트 엔지니어링 역사 통틀어 지금이 장난치기 가장 좋은 시대일 수 있음

  • 지난 50년 동안 소프트웨어는 취미에서, 괴짜 소집단에서, 그리고 지금은 1조 달러 이상의 산업으로 변신함. 이 변화는 소프트웨어 개발자 커뮤니티 내의 구성도 엄청나게 뒤섞이게 했음: 2025년의 평균적인 개발자가 들어오는 이유와, 2015년 개발자, 2005년 개발자의 동기는 많이 다름. 요즘도 호기심 많은 개발자 숫자는 많아졌을 수 있지만, 컵케익에서 그들의 조각은 작아졌을 수 있음

    • 소프트웨어가 원래 순전히 취미 영역이었던 것도 PC와 홈 컴퓨터 덕이었음. 그 전엔 대기업이나 정부만 하는 일이었음—IBM, Burroughs, DEC의 메인프레임과 미니컴퓨터 시절. 완전 다른 시대였음
  • ㅋㅋ 오케이. 호기심 많은 개발자는 여전히 호기심이 넘치지만, 그 주변 문화가 점점 열정을 쥐어짜는 분위기임

  • 이제 중간 개발자는 대개 돈 때문에 이 업계에 들어온 사람이 됐음. 성장산업/기회를 찾기 어려운 구조의 부작용임

    • 나는 컴퓨터를 좋아하지만 솔직히 힘듦. 하루 종일 stand-up, Scrum, SAFE에 시달리고, 여러 팀의 마이크로서비스 이어붙이며 폭발만 안 나게 끝내고 퇴근하고 싶음. 직장에서 장난칠 여유도 없고, 밤에 또 코딩할 에너지도 없음. 내 취미를 직업으로 삼았고, 결국 취미가 죽는 경험임

    • 주거 인플레이션 역시 모두를 용병같이 만드는 데 한몫함

    • 돈이 진짜 핵심임. 80년대 처음 컴퓨터에 빠질 때는, 모두가 호기심 넘치고 기술적으로 열정적이었음. 그 당시 컴퓨터 분야의 첫 성장 무대는 월스트리트와 은행권이었음. 월스트리트가 개발자에게 큰 보너스를 주기 시작했고, 소프트웨어가 큰돈을 벌 수 있다는 게 분명해졌음. 그다음엔 전혀 기술에 열정 없는 사람들도 돈을 좇아 유입됨. 닷컴 붐과 버블, 그리고 소셜 미디어, FAANG, 천문학적 기업가치와 터무니없는 연봉 패키지 시대로 오면서 이런 현상은 더 심해짐. 그 결과 호기심 많고 열정적인 개발자는 여전히 있지만, 숫자상 희석된 것임. 이런 곳에서만 간신히 비슷한 열정을 찾을 수 있음

    • 개발자만의 문제는 아님. 모든 테크 회사가 FAANG 방식 따라 가치 입증과 경쟁을 강요함. 이제 “종신고용”이라는 개념은 완전히 사라졌다고 느껴짐. 학계의 “publish or perish”가 그대로 이 직장 문화에 들어왔고, 다들 자기 자리 지키려 게임처럼 시스템을 잘 활용하는 모양임

    • "다른 성장 경로가 없기 때문"이라는 말은 100% 사실 아님. 미국 사회 자체가 지난 30~40년간 대학 진학을 지나치게 밀고, 고소득 약속을 포장함. 그 결과 대학 졸업장은 넘쳐나고, 그에 따른 빚도 쌓였음. 사실 괜찮은 수입을 얻을 길이 대학을 안 가도 많음. 다들 "돈 많이 벌기"만 목표로 몰았던 게 아니라, 정말 자기가 원하는 게 뭔지 찾고, 그에 맞는 경로 모색을 했어야 했음