▲

확장하지 않는 것을 하라, 그리고 정말 확장하지 마라

 (derwiki.medium.com)
3P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • Paul Graham의 “확장되지 않는 일 하기” 아이디어에서 출발해 GPT 보조 개발 환경으로 인해 이제는 정말 소규모로 일을 마무리할 수 있음
  • 이제는 소규모 또는 개인을 위한 간단한 프로젝트를 만들고, 더 이상 꼭 성장이나 비즈니스로 발전시킬 필요가 없음
  • 실제 사례로 슬랙 커뮤니티나 포스트카드 메일러, 정해진 시간 알림 앱 등을 개인 혹은 소규모 집단을 위해 만들어 만족감과 효용을 경험함
  • AI 도구의 발전으로 소규모, 맞춤형 소프트웨어 제작이 비용·속도 면에서 매우 쉬워졌으며, 소규모 자체가 오히려 목적임
  • 확장 강박에서 벗어나 작고 유용하며 내게 딱 맞는 무언가를 만들고 거기서 멈추는 자유를 누릴 수 있음

배경: ‘확장되지 않는 일 하기’와 시대 변화

  • 10여 년 전 Paul Graham은 “Do things that don’t scale”(확장되지 않는 일을 하라)라는 개념을 주창함
  • 이 아이디어는 초기에 수작업 위주의 작은 실험, 개인적 접근으로 시작하고, 점차적으로 확장 방법을 찾으라는 취지였음
  • 그러나 최근 GPT 기반 도구로 인해, "초기작업"만 하고 멈춰도 충분하며, 오히려 그게 최선임
  • 프로젝트를 시작하는 데 드는 비용과 시간이 매우 낮아졌고, 모든 아이디어가 비즈니스로 커져야 할 필요가 사라짐
  • 스스로 또는 소중한 소수만을 위한 서비스라도 충분한 목적성 지님

더 커지면 안 되는 Slack

  • 필자는 약 100명의 사용자가 있는 Slack 워크스페이스를 운영 중임
    • 실제로 일주일에 적극적으로 대화하는 사람은 15~20명 정도임
    • 친밀함과 사적인 분위기가 유지되며, 트위터 등 공공 플랫폼보다 깊은 소통 가능함
  • 더 크게 만들 수는 있지만, 확장하면 곧 분위기가 깨지고 친밀함 사라짐
    • 1,000명까지도 필요 없음
    • 이름을 모르는 사람이 늘고, 누가 듣는지 모르면 대화량도 줄어듦
  • 작기 때문에 가능한 것이 있음

PostcardMailer: 작게, 그리고 단순하게

  • 몇 년 전, 본인이 Instagram에 사진을 올리면 엄마에게 엽서를 보내주는 작은 사이트(PostcardMailer)를 만듦
    • 사진과 설명을 가져와 우편 API로 엄마에게 발송함
  • Instagram API 정책 변화로 방식이 막혀, 사진 업로드 방식으로 재구현함
    • 친구와 일부 Orange Site(Hacker News) 사용자가 활용함
    • 이후 스팸 및 악용 우려와 함께 계정 관리를 제한함
    • Heroku의 서비스 종료로 사이트 유지 중단, 최종적으로 이메일 기반 서비스로 전환함
  • 지금은 iPhone에서 이메일을 통해 mom@postcardmailer.us로 사진을 보내면 엄마에게 엽서 발송됨
    • 비공개, 로그인·비밀번호 없음
    • 시중에 엽서 사이트는 많지만, 딱 원하는 방식으로 동작하는 것은 이 서비스 하나임

Landline Pill Reminder: 엄마만을 위한 알림 앱

  • 엄마가 정해진 시간에 약을 먹어야 하는 상황이 있었음
    • 엄마는 스마트폰이 없고, 대부분 폴더폰마저 꺼두는 생활임
  • 신뢰할 만한 연락수단은 우편이나 집전화뿐임
  • 그래서 Twilio API로 음성전화를 하루 3번 걸어주는 작은 앱을 만듦
    • “약 먹으실 시간입니다”라는 녹음된 음성 전달
    • 10분 후 한 번 더 전화해 확인 요청
  • 제작비용 거의 없음, 며칠 만에 완성함
    • 확장하려면 타인 지원, 책임, 법적 불안까지 발생하나, 엄마만을 위한 솔루션이 가장 안전하고 효율적임

패턴(교훈)

  • 본인에게 의미 있는 니즈를 발견함
  • 가장 작고 단순한 솔루션을 구축함
  • 확장 욕구를 최대한 억제함
  • 완성된 솔루션을 즐김
  • 과거에는 확장이 중심이었으나, 지금은 ‘작음’ 자체가 목적이 될 수 있음
    • AI 등 보조 도구로 인해 개인 맞춤형 소프트웨어 제작 비용·노력이 크게 절감됨
    • 1명 또는 소수 사용자를 위한 서비스가 최적의 선택이 될 수 있음

결론: ‘작음’의 가치

  • 오늘날 도구와 환경의 진짜 사치/혜택은 속도, 비용, AI가 아니라, 멈춰도 된다는 자유임
  • 본인만의 ‘작고 유용하며 딱 맞는 것’을 완성하고, 무리한 성장을 추구하지 않아도 충분함
  • 확장에 집착하는 시대에서 적당히 만족하고 멈추는 조용한 만족감이 새로운 가치임
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • 어느 정도까지 커질 수 있을까 궁금함은 있음, 하지만 어떤 시점——아마도 1,000명 이전쯤——에서 분위기가 깨진다는 느낌임, 친밀감이 사라지고, 더 이상 이름이 익숙하지 않음, 누가 글을 보는지 알기 힘들어서 대화도 줄어듦, 성장 자체가 오히려 안 좋은 영향을 주는 셈임, 소규모라서 잘 작동하는 것 같음, 이것은 Facebook 같은 소셜 네트워크에서도 마찬가지라고 생각함, 2005~2010년경 Facebook은 주로 대학, 고등학교, 회사 친구들이 모여서 자유롭게 생각을 공유하고 흥미로운 링크를 나누던 시기였음, 그런데 지인들이 점점 늘어나고 친하지 않은 사람들이 친구 목록에 추가되면서 분위기가 전혀 달라짐, 어느 순간엔가 가까운 사이도 아닌 사람이 자신의 게시물에 불쾌해하거나 의견 충돌을 겪고 나면 공유를 점점 덜 하게 된다는 경험이 누구나 있음

    • Facebook에서 그리 심한 내용도 아닌데 욕설 하나 썼더니 할머니가 메시지로 삭제해달라고 했던 기억이 있음, 대신 할머니를 차단했음, 명절에만 뵙는 게 차라리 더 좋았음, 정작 할머니는 이 사실을 눈치채지도 못한 듯함
    • 이 현상에는 'Context Collapse'라는 용어가 실제로 존재함, 이는 소셜 미디어가 모든 사회적 상황(예: 직장, 학교, 가족 등)에서 각각 다른 자신을 보여주는 게 아니라, 한 가지 온라인 페르소나를 강제함을 설명함, 관련 링크
    • 친구들 중 제일 마지막으로 Facebook에 가입했던 기억이 있음, IRC에서 자란 올드스쿨 인터넷 유저로서 실명과 사진을 허술해보이는 PHP 사이트(그것도 하버드 출신의 누군가가 만든 것)에 기입한다는 게 무척 이상하게 느껴졌음, 그런데 여자애들이 다 쓰고 있길래, 결국 다들 따라간 셈임. 그게 역사가 되는 순간임
    • 어느 순간부터 Facebook이 더 이상 뭔가를 공유하는 곳이 아니라, 경쟁의 장이라는 걸 모두가 한 번에 알아차린 듯한 시점이 있었음, 그때 다들 공유를 멈추고 대신 '큐레이션'을 시작하게 됨
    • 2008년 무렵 Facebook은 정말 괜찮았음, 현실 친구들과 어울리는 느낌이었음, 그런데 가족들이 합류하면서 확장된 가족과의 식사자리 같은 분위기로 변했음

  • 스스로를 위해 무언가를 만드는 과정은 재미있는 일임, 나도 그렇게 함, 다만 원래 글은 창업자——즉 회사를 만드는 사람——을 위한 글이라는 점은 짚고 싶음

    • 특정 유형의 회사, 특히 tech startup에 관한 이야기임, 스타트업처럼 성장에만 집착하면서 적자를 감수하는 게 아니라, 가능한 빨리 수익을 내는 ‘회사’를 만드는 시각이 더 필요함을 말하고 싶음, 반드시 성장하지 않아도 수익을 내는 회사를 만들어야 한다고 생각함
    • 맞음, 원글의 조언 자체가 창업가(Founder) 중심이었던 것 인정함, 나도 이 멋진 문구를 조금 비틀어보고 싶었음, 활용 가치가 높음
    • 자신의 문제를 해결하려고 무언가를 만들다가, 그게 남들도 겪고 있고 그들이 시도하다 실패한 문제라면 수요가 생길 수 있음, 충분히 불편한 문제라면 돈을 낼 가치도 있다고 봄, 사실 이런 문제는 B2C보다 B2B에서 더 자주 발견됨, 개인의 문제가 B2B로 확장될 때가 많음
    • 'Startup'이라는 단어는 종종 ‘빠르게 성장하기 위해 설계된 소규모 회사’로 정의됨

  • Robin Sloan이 몇 년 전에 비슷한 주제로 적은 글이 있음, 누구든 프로그래밍 언어나 지식 없이도 소소한 무언가를 만들어 즐거움을 느낄 수 있게 된 것이 최근 가장 긍정적인 변화 중 하나라고 생각함, 굳이 대단히 혁신적이지 않아도 좋음, 관련 글

  • Claude Code를 이용해서 롤플레잉 게임용 헥스맵을 만드는 작은 웹앱을 만들었음, 비슷한 사이트가 많고 대부분 무료임, 심지어 내 앱에서 없는 기능을 갖춘 곳도 많음, 그런데 내 앱은 내가 원하는 방식대로 동작함, 강과 숲을 타일 지형 위에 얹는 식의 수정, 다양한 정착지 아이콘, 언덕/산의 더 많은 변형 등 내가 원한 요소가 반영됨, 듣고 싶은 기능이 생기면 그냥 추가하면 됨, 남의 앱을 보면서 "어쩔 수 없네" 할 이유가 없음, 내 개인 용도라서 확장성이나 보안, 수익화 등에 신경쓸 필요가 없음, 실제 개발엔 한두 시간 정도만 쓰면 됨, 그마저도 이틀에 나눠서 AI로 작성함

  • “Do things that don’t scale”이라는 스타트업 격언이 있음, Airbnb나 Y Combinator 초창기부터 쓰였던 것 같음, 며칠 전에도 HN에 다시 올라왔었음 관련글

    • 재밌는 타이밍임, 지난 주말에 이 글 썼는데 이번 주엔 HN을 거의 못봄
    • 구글 검색에 첫 번째로 뜨는 글이라서 원글의 신뢰도엔 좀 손상이 있다고 느껴짐

  • 꼭 모든 것이 커질 필요 없다는 생각에 동의함, 하지만 ChatGPT와 이번 주제 사이에는 굳이 접점이 있다고는 못 느끼겠음

    • 이전엔 사출성형만 가능했는데 이제는 3D 프린터가 생긴 것 같은 비유임
    • 실제로 글에 들어간 예시조차 LLM(대형 언어 모델) 이전의 이야기임
    • 아마도 ChatGPT로 코딩해본 적이 없는 듯함

  • Robin Sloan의 "앱도 가정식 요리처럼 만들 수 있음"이라는 글 추천함 관련 링크

  • 이 글 정말 공감함, 이런 이유로 소프트웨어 컨설팅 일을 그만뒀음, 앞으로는 LLM에게 필요한 모든 것을 써달라고 요청하면 됨, 기술 스택, 호스팅, 통합까지 알아서 챙김, "Discord 대안 찾기"가 "나와 친구들을 위한 Discord 클론 만들어줘"로 변하는 세상임, 코드 퀄리티는 중요하지 않아짐, 이제 수백만 유저가 쓰지 않을 것이니까

    • 여기에 동의하지 않음, 이런 경험은 LLM 이전에도 가능했음, 대부분의 제품에는 이미 오픈소스 대체재가 존재했고, 설치와 배포도 LLM보다 쉬울 때가 많음, 게다가 업데이트 등도 받을 수 있음, 다만 사람들이 인스톨, 배포, 보안 유지에 책임지기 싫어서 그런 서비스에 소액 지불하는 편이 훨씬 낫다고 느끼는 것임, 문제는 코드 작성이 아니었음

  • Maciej Ceglowski의 명작 “Barely Succeed: It’s Easier”가 떠오름 관련 유튜브 링크

  • 본질적으로 '확장'이 그렇게 중요한 목표였던가 의문임

답변달기