빠르게 움직이고, 포기하기

• 1991년 전후의 미완성 Mac 게임을 복구하는 과정에서, 아이디어를 빨리 구현해 보고 재미나 완성 가능성이 부족하면 과감히 접는 개발 방식이 반복됐음
• 당시 목록에는 27개 타이틀이 있었지만 실제 공개작은 5개였고, 나머지는 약 18개월 동안 만든 빠른 프로토타입에 가까웠음
• 스프라이트 기반 게임용 공통 셸 덕분에 새 실험의 비용은 낮아졌고, 사운드·하이스코어·저장 기능은 가능성이 확인된 뒤로 미뤄졌음
• kite-fighting, K-10, Thief of Baghdad 같은 실험은 조작의 재미, 게임의 목적, 1인 개발자가 감당할 아트와 구현량을 기준으로 계속할지 결정됐음
• 버린 프로젝트도 낭비가 아니었고, Fisher–Yates shuffle, 화면 색상 깊이 전환, 충돌 판정, 삼각함수 조회 테이블 같은 코드는 이후 프로젝트에 다시 쓰였음

---

오래된 Mac 게임 프로젝트 복구

• 35년가량 전 작성한 게임 파일을 오래된 하드드라이브에서 복구하면서, 출시작보다 거의 완성되지 못한 실험작들이 더 흥미로운 대상으로 남음
• 과거 공개했던 shareware 게임은 디스크 이미지로 묶어 Soft Dorothy Software — Early Shareware Projects에 올렸음
  • 해당 디스크 이미지는 Basilisk II, Sheepshaver, MiniVMac 같은 68K 또는 PPC Mac 에뮬레이터에 끌어다 놓아 사용할 수 있는 형태임
• Casady & Greene가 1991년에 퍼블리싱한 Glider 4.0 관련 소스와 빌드 도구는 Casady & Greene Projects 디스크 이미지에 들어 있음
• AirBikes는 완성됐다면 미래형 레이싱 게임이 됐겠지만, 실제로는 미완성 상태로 남음

27개 타이틀 중 5개만 출시

• 1991년경 만든 문서에는 각 게임의 creator code, 이름, 상태가 정리돼 있었음
  • creator code는 OS X 이전 Macintosh 시대의 매우 거친 bundle identifier에 가까웠고, 애플리케이션마다 고유해야 했음
• 목록에는 27개 타이틀이 있었고, 그중 출시된 것은 5개였음
  • 나머지는 대부분 빠른 프로토타입이었음
  • 이 프로젝트들은 약 18개월 동안 만들어졌음
  • 목록 작성 시점에는 동시에 3개 타이틀을 작업 중이었던 것으로 남아 있음
• UnMask라는 유틸리티도 공개했지만, 작성에 10분 정도 걸린 도구라 분석 대상에서는 제외할 만한 것으로 취급됨

빠른 프로토타이핑 방식

• 밤늦게까지 매일 코딩하며 많은 실험을 만들었고, 스프라이트 기반 게임을 위한 공통 셸로 새 프로토타입 제작 비용을 낮춤
• 새 게임 스케치에는 주로 MacPaint로 스프라이트와 아트를 만드는 시간이 들어갔고, 고유 입력 방식·게임 메커닉·물리 구현에는 일부 코드가 필요했음
• 사운드, 하이스코어, 저장 게임 같은 기능은 처음부터 만들지 않고, 살릴 가치가 있는 게임에만 나중에 구현하기로 미뤘음
• 핵심은 아이디어가 실제로 재미있는지 빠르게 확인하는 데 있었음
  • 종이에 적힌 아이디어가 재미있어 보이는 것과 실제 플레이가 재미있는 것은 다를 수 있음
  • 조작과 물리만 며칠 안에 구현해도 계속할 가치가 있는지 확인할 수 있었음

재미를 빠르게 확인하는 기준

• kite-fighting 게임은 며칠 안에 날리는 조작과 물리를 구현해 테스트할 수 있음
  • 연을 조종하는 것 자체가 너무 어렵다면 게임을 즐길 사람이 적을 가능성이 큼
  • 전투 요소 없이 연을 날리는 것만으로도 재미있다면 가능성이 있음
• 아케이드 게임 Joust는 적이 등장하기 전에도 flap 버튼으로 날아다니는 조작 자체가 재미있었음
  • 천천히 날갯짓해야 할 때와 빠르게 상승하려고 정신없이 버튼을 누를 때가 모두 플레이 감각을 만들었음
• 종이비행기가 어질러진 집 안에서 바닥 통풍구를 이용해 양력을 얻는 게임도, 방을 진행하고 토스트 등을 피해야 한다는 목적을 깨닫기 전부터 어느 정도 재미가 있었음
• K-10은 Kansas highway 10에서 이름을 딴 또 다른 레이싱 게임이었지만 프로토타입 단계를 넘지 못함

접을지 계속할지의 판단

• 일부 게임은 초반 구현까지는 됐지만, 이후에 무엇을 해야 할지 분명하지 않았음
  • 목록에는 몇몇 게임에 <no point> 라고 냉정하게 적혀 있었음
• 플랫폼 게임 Thief of Baghdad는 마법 양탄자를 타고 뛰어다니는 부분은 재미있었지만, 그다음 게임의 목적이 불분명했음
• 혼자 개발하는 조건에서는 잠재력이 있어 보여도 완성까지 1년 이상 걸릴 프로젝트를 계속하기 어려웠음
  • Dungeons and Dragons 스타일의 스프라이트 기반 adventure 게임은 매력적이었지만, 플레이어 무기별 동작, 몬스터, 주문 효과, 전투 시스템까지 필요한 작업량이 컸음
  • 검으로 찌르고 막는 동작을 만들고 나면, 철퇴·활·망토 같은 변형까지 추가해야 하는 식으로 아트 부담이 늘어남

다시 꺼내고, 코드도 재활용함

• 미뤄 둔 게임은 완전히 죽은 프로젝트가 아니며, 소스·리소스·프로젝트 파일을 찾을 수 있다면 다시 꺼낼 수 있음
• Thief of Baghdad는 약 18개월 뒤 컬러 버전으로 다시 시작됐고 Scheherazade라는 이름을 얻었으며, 어느 정도 목적도 생기기 시작했음
  • 두 번째 시도에서도 끝내 설명하기 어려운 매력이 충분히 생기지 않아 다시 중단됨
• 보류한 프로젝트의 코드는 이후 작업에 재사용될 수 있었음
  • Fisher–Yates shuffle algorithm
  • 초기 Mac에서 모니터 색상 깊이를 바꾸는 코드
  • polygon-point 충돌 코드
  • 빠른 삼각함수를 위한 sine 조회 테이블
  • dot-product와 cross-product 루틴
• 이런 프로토타입 작업은 낭비로 취급되지 않았음

Apple에서도 이어진 반복 방식

• 1990년대가 진행되며 indie Mac game developer 시대가 끝나가는 듯했고, California로 가서 Apple에서 일하라는 제안을 받자 수락함
• Apple 입사 뒤에는 여가 시간에 비Apple 프로젝트를 할 수 없다고 이해했음
  • 엄밀히는 업무 외 코딩을 하려면 관리자의 서면 허가가 필요했음
  • Apple이 게임 사업을 하지 않았으므로 허가를 받을 수도 있었지만, 요청했다가 거절될 가능성이 부담으로 남았음
• 게임이 아닌 업무 프로젝트에서도 빠른 프로토타이핑 방식은 계속됐음
  • 다른 동료들은 화이트보드에서 설계를 반복하고 코드를 쓰기 전에 신중히 계획했음
  • 본인은 먼저 뛰어들어 컴파일하며 반복하는 방식을 선호했음
• 빠르게 코드를 모아 병목을 빨리 찾고, 필요하면 프로젝트를 거의 처음부터 다시 시작하는 방식이 반복됐음
  • 프로젝트를 세 번쯤 시작했다가 다시 시작한 뒤에도, 신중히 설계한 동료들이 코드를 실행시키는 시점과 비슷한 때에 충분히 좋은 상태에 도달하곤 했음
• 마지막 코드 리비전은 대개 단순화였고, 처음부터 코드를 크게 바꿀 수 있는 상태로 다루면서 어떻게 조직해야 할지에 대한 감각을 얻었음
• Bloom Filter를 권하는 동료에게, 실제 데이터가 너무 작아 성능 이득이 미미하고 코드베이스 복잡도만 늘어 버렸기 때문에 이미 버렸다고 답할 수 있었던 경험도 있었음

Always Be Iterating

• 은퇴할 즈음 Apple에서 기여하는 직원이자 동료였다고 느끼게 됨
• 혼자 밤새 코딩하던 시절과 달리, 함께 일한 엔지니어들이 Apple 근무에서 가장 좋은 부분이었음
  • 함께 일한 사람들 중에는 본인보다 한 자릿수 이상 뛰어난 프로그래머도 있었음
• 본인은 가장 빠른 프로그래머 중 하나였다고 느꼈고, 그 주 회의 데모용 프로토타입이 필요하면 두 가지 버전을 만들 수 있는 사람에 가까웠음
• 딸들에게 반복해 말한 문장은 A.B.I. 였음
  • “Always”
  • “Be”
  • “Iterating”
  • 즉 “Always Be Iterating”
• 출시되지 못한 게임들의 프로젝트, 소스, 도구는 디스크 이미지로 정리돼 GitHub에 공개됨
  • Soft Dorothy Software: Unfinished Tales (Vol. 1)
  • Soft Dorothy Software: Unfinished Tales (Vol. 2)
• Volume 3도 예정돼 있지만, 각 프로젝트를 “release” 가능한 상태로 정리하는 작업이 있어 공개 시점은 약속되지 않음

[GN⁺]

Hacker News 의견들

• 1989년쯤 프로그래밍을 시작한 뒤로 방치한 프로젝트가 적게는 십여 개, 많게는 백 개쯤 있고 대부분은 게임. 대부분 Mac Plus나 Mac LC용으로 만들었고, 글에 나온 것들과 비슷한 메커닉이나 아트 스타일도 많았음
  출시했거나 참여했던 몇 안 되는 프로젝트는 나라는 사람의 그림자처럼 느껴짐. 이력서와 경력도 마찬가지임. 초기에 성공을 쌓아 올릴 기회가 없어서 현실화되지 못한 꿈의 삶을 살던 온전한 존재의 지문 같음. 그래서 기본소득이 인간 잠재력을 10배나 100배 키워, 서비스 경제에서 주체성과 자아실현으로 넘어가고 각자 잔여소득을 만들게 해줄 수 있다고 봄. 그리고 Pararena를 정말 많이 했음

  • 다른 생각을 갖고 있고, 팬데믹 때 나와 친구들 주변에 기본소득 비슷한 상황이 생기면서 그렇게 보게 됨. 더 이상 일할 필요가 없어진 사람들은 계속 일한 사람들에 비해 꽤 빨리 우울해졌고, 그게 기본소득에 대한 관점을 바꿨음
    당신 주변은 달랐거나, 당신 나라에서는 그런 접근을 하지 않았을 수도 있겠음. 여러 게임을 작업하는 것과 하나에 집중해서 끝내는 것의 차이는 무엇인지 궁금함. 기본소득이 있다면 완성된 프로젝트가 나올 만큼, 그것도 잠깐이 아니라 계속 이런 것들을 할 수 있을까? 부모가 되는 시기나 어린 시절 같은 어떤 생애 단계에서는 기본소득이 말이 되지만, 자신을 찾아가는 시기에는 책임이 도움이 된다고 봄
  • 기본소득은 작동하지 않을 것임. 우리나라에는 거의 구현돼 있음. 일하지 않아도 월 600유로와 여러 복지 혜택을 받을 수 있는데 결과는 EU권 최고 공공적자, 세계 최고 수준 세율, 만연한 범죄, 그 세금 때문에 일해서 돈 벌기 어려움, 교육받은 사람들이 대거 해외로 나감 등임
  • 최저임금도 잘 안 됐다면, 일하지 않는 사람에게 돈을 주는 비슷한 시스템이 작동한다고 믿게 하는 지표가 무엇인지 모르겠음
    이런 사고방식은 정말 이해하기 어렵다. 마법 같은 기본소득은 일하지 않는 대중을 위한 최저임금이 될 텐데, 그게 어떻게 지속 가능하거나 좋을 수 있겠나
  • 우리는 서로 다른 삶을 살고 있음. 나는 제품을 차라리 버렸어야 했던 프로젝트들에만 참여했음. 게임은 아니었지만, 출시된 상태가 그랬다는 뜻임
    이론적으로는 제대로 완성하는 선택지도 있었겠지만, 그렇게 하려 했다면 조직이 파산했을 것이므로 어디까지나 이론적인 선택지였음. 내가 일하며 쓰고 사적으로도 어쩔 수 없이 쓰는 소프트웨어 상태를 보면 주변 모두가 이런 삶을 사는 듯함. 다행히 사용자에게는 선택권이 없어서, 형편없는 걸 사거나 아예 아무것도 사지 않아야 함. 우리는 형편없는 걸 팔아도 안전함
  • 완성 안 된 것들은 그냥 연구라고 부름. Unreal Engine 4/5 프로젝트가 여럿 있고 절대 끝내지 못하겠지만, 게임 메커닉 테스트, 리깅과 애니메이션, 셰이더 개발, 3D 애셋 제작 같은 관점에서는 재미있었음

• 내가 일했던 많은 회사가 이런 식으로 돌아감. 엔지니어들은 번쩍이는 새 기능을 만들고, 출시되고, 모두가 행복해함. 몇 달 뒤에는 버그가 잔뜩 쌓임
  원래 만든 사람들은 이미 다른 팀에 가 있음. 명분은 “사일로 깨기”지만 실제로는 “모두를 대체 가능하게 만들기”에 가까움. 프로젝트를 물려받은 엔지니어들은 또 다른 팀이 넘겨받을 때까지 유지보수하고 버그를 고쳐야 함. 끔찍함

  • 최소 기능 제품을 올바른 제품 개발 방식으로 널리 받아들이면서 우리가 스스로 만든 지옥도임. 우리는 멍청한 물건이 탄탄하거나 유지보수 가능한지가 아니라, 기능 목록으로 실행 가능성을 판단함
    게다가 “최소한으로 실행 가능”은 “실행 불가능”에서 한 걸음 떨어져 있을 뿐임. 모든 프로젝트가 이카로스처럼 되어, 날개가 녹기 전까지 태양에 얼마나 가까이 날 수 있는지 시험하게 됨
  • Series A 이후의 모든 스타트업 채용공고는 제품-시장 적합성 이전 단계의 “영웅들” 뒤처리를 위해 Viscera Cleanup Detail[1]을 하라는 것 같다고 자주 농담함
    [1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
  • 회사를 규정하는 기능의 원작성자였는데, “사일로를 깨야 한다”는 말을 듣고 빠진 뒤 몇 년 동안 내 작업물이 망가지는 걸 봤기에 전적으로 동의함
    물려받은 사람들은 결정을 내릴 자격이 부족했고, 내 큰 구상은 밀려났으며, 그 기능을 관리하는 무능을 지켜보는 건 견디기 힘들었고 아직도 멍청한 버그가 나올 때마다 짜증이 남. 특히 충분히 조정할 시간이 있을 때 경고했는데도 그랬음. 그래도 중요한 교훈을 얻었고, 다음에는 고집 센 사람으로 보이더라도 물러서지 않고 싸울 것이라고 확실히 말할 수 있음
  • 완전히 맞는 말이지만, 원글이 말하려는 지점이나 글의 의도는 그게 아니라고 봄. 글은 여러 가지를 시도해 보고, 기술적으로 가능한지와 고객에게 흥미로워 보이는지 감을 잡은 뒤 그걸 밀어붙이라는 권장에 가깝다
    인디 개발자에게도 잘 맞고, 어느 정도는 대기업에도 적용 가능함. 이 철학은 의미 있는 시간을 쓸 기능이나 제품을 식별하는 데 좋음. 오히려 당신이 묘사한 상황은 원글이 제안하는 방식을 따르지 않은 직접적 결과라고도 볼 수 있음
  • 당신이 묘사한 건 이 글과 별 관련이 없어 보임

• 요즘 레트로 개발로 돌아가 작업하고 있음. 처음 프로그래밍을 배웠던 68K Macintosh용 소프트웨어를 만들고 있음
  오래된 책, comp.sys.mac.programmer 글, Soft Dorothy와 GliderPro 같은 소스 코드를 많이 뒤졌음. 오래된 코드를 새 눈으로 보는 건 묘한 경험임. 예전 Mac이 왜 그렇게 많이 죽었는지, 단순히 “메모리 보호가 없었다”는 설명 너머의 이유도 보임. 글쓴이가 말한 것처럼 1비트 아트도 좋아해서, 1비트 아트를 올리는 Twitter 계정 목록을 관리하고 있음. 빠진 사람이 있으면 알려주면 좋겠음: https://twitter.com/i/lists/1578111923324944397
  제한된 시스템용으로 프로그래밍하는 좋은 점은 선택지를 제한해 준다는 것임. 적절한 라이브러리만 끌어오면 뭐든 할 수 있는 현대적 경험에서 벗어나는 좋은 휴식이 됨. 가끔 계산 능력이 얼어붙고, 잘 이해된 시스템을 위한 소프트웨어만 점점 더 좋아지는 세계를 상상함. Mac 68K 같은 오래된 시스템은 하드웨어 발전 속도가 너무 빨라 어지러울 정도였음. 68020이나 80386 같은 새 프로세서가 나오면, 그 잠재력을 제대로 쓰는 무언가를 만들 시간은 길어야 몇 년뿐이었음. 너무 늦으면 새 하드웨어 세대를 위한 새 소프트웨어와 경쟁해야 했음

  • 30년 넘는 뒤늦은 시야로 내 코드를 다시 보면 리팩터링하고 싶고, 창 이벤트 응답 같은 흔한 잡일을 단순화하고 싶어짐
    Handle 등을 다루는 래퍼 함수도 만들고 싶음. 그래도 말한 대로, 현대 운영체제에 비하면 Toolbox가 얼마나 단순했는지 놀랍다. 다시 레트로 개발을 해보는 게 정말 재미있게 느껴짐
  • 제한된 플랫폼인 Playdate용 1비트 아트를 함. Macintosh Plus만큼 제한적이진 않음. Twitter에서는 @gingerbeardman이고 예시는 여기 있음: https://blog.gingerbeardman.com/2024/07/14/shibuya-pixel-art...
  • 68k Mac의 디더링 이미지들 때문에 1비트 아트를 좋아함. 컴퓨터 배경화면용으로 가진 사진 일부도 디더링해 둠

• 블로그 전체가 멋짐. 둘러볼 만한 흥미로운 내용이 많음
  무언가를 버려도 괜찮고, 버린 프로젝트에서도 배울 수 있으며 일부를 재사용할 수도 있음. 나에게 돌파구가 된 순간은 끝낼 수 있을 만큼 작게 만들기로 결심했을 때였음. 끝내는 기술을 기르는 데 도움이 됐고, 이건 별도의 기술이며 배우기 어려움. 너무 길고 힘든 과정의 끝에서만 일어나기 때문에 거의 거기까지 못 가기 때문임. 비디오게임을 만드는 내 친구들은 모두 자기 엔진부터 쓰기 시작하고, 레벨 편집기를 만들 즈음 번아웃됨. 도구 제작 같은 건 많이 배우는데, 공교롭게도 이미 할 줄 알던 것과 비슷하고, 정작 게임은 만들지 못함. 대성당을 지으면서 석공술을 배우는 것과 같아서 끝을 보지 못할 것임. 실패할 수 없을 만큼 작게 시작한 뒤 점점 더 큰 프로젝트로 올라가야 함

  • “비디오게임을 만드는 내 친구들은 모두 자기 엔진부터 쓰기 시작한다”는 건 나도 몇 번 겪어 봄. 기존 도구를 쓰기로 해도, 끝없이 깊은 복잡성의 웅덩이에 쉽게 빠질 수 있음
    지금 Unity 프로젝트를 작업 중인데, RTS 스타일 건물 배치 시스템을 어떻게 가장 잘 만들지 고민하다가 애를 먹고 있었음. 평소처럼 바로 뛰어드는 대신, 플레이어가 건물을 배치할 필요 자체가 없도록 게임 콘셉트를 고치기로 했음. 실험해 보니 내가 만들려던 것에는 오히려 더 나은 사용자 경험이었음. 처음에는 “다음 반복에서 건물 시스템을 추가하자”고 합리화했지만, 이제는 아마 안 할 것 같음
    덜어내는 것이 거의 항상 더 낫다. 작은 시작점을 실제로 완성하는 것은 다음 반복을 위한 니트로메탄 같음. 100%에 도달해야 다음 차례가 훨씬 좋아짐. 80%에서 멈추면 바위를 다시 언덕 위로 밀어 올려야 한다는 느낌만 남음
  • 개인 프로젝트를 단 하나도 끝낸 적이 없는 것 같음. 적어도 나에게는 그게 가장 기르기 어려운 기술임
  • 개인 프로젝트를 실제로 끝낼 수 있을 만큼 줄이는 데 집중하는 것이 지금 나에게 딱 필요한 일일 수 있겠음
  • 최근 프런트엔드 개발에서 접근성 쪽으로 옮겼음. 몇 년 전에는 여러 정적 사이트, 템플릿, 디자인 프로젝트를 만들었지만 결국 여러 이유로 방치했음
    접근성 일을 하게 된 뒤 그중 많은 것을 다시 꺼내 접근 가능하게 다시 만들었음. 몇몇은 아주 오래된 Bootstrap 버전을 쓰고 있어서, 최신 Bootstrap으로 업그레이드하는 작업도 같이 했음. 오래된 디자인을 접근 가능하게 고치는 것만으로도 정말 많이 배웠음. 사이트와 애플리케이션을 평가할 때 무엇을 봐야 하는지에 대해 훨씬 나은 관점을 얻었다고 느낌. 내가 만들었던 것들이 얼마나 접근성이 없었는지 깨닫는 계기도 됐음
  • 시작한 것을 끝내는 기술은 생산성 논의에서 빠져 있는 것처럼 느껴짐. 더 자세히 설명하는 블로그 글이나 기사가 있는지 궁금함

• John의 게임들은 어릴 때 Mac에서 프로그래밍을 처음 익히던 나에게 영감이었음. Glider를 많이 했고 Pararena는 더 많이 했음. 아직도 그 울림 있는 시작 샘플이 머릿속에 박혀 있음
  ResEdit로 그 게임들의 리소스 포크를 뒤적이는 데도 아마 훨씬 더 많은 시간을 썼을 것임. 많이 끝내지는 못했지만, 작은 셰어웨어 게임 몇 개는 완성해서 AOL에 올렸음. 몇 달 뒤 먼 캘리포니아에서 수표가 우편함에 도착했을 때 정말 놀랐음
  초기 Mac 시절은 정말 특별한 시간이었고, 혼자 개발하는 사람이 창의력과 시간만 있으면 무언가를 만들어 세상에 내놓을 수 있다는 느낌이 있었음. 이런 글을 써서 추억 속으로 보내줘서 고맙고, 은퇴를 즐기고 있기를 바람

  • 내 다른 글들이나 디스크 이미지 저장소의 README를 읽었을지도 모르겠음. 그 시절은 특별했음
    초기 컴퓨터 사용자이자 초기 개발자였던 우리에게 모든 것이 새로웠기 때문에 특별했을까? 아니면 그때 공기 중에 뭔가 다른 게 있었을까. 내가 만든 작은 게임들을 좋아했다니 기쁨. 캘리포니아에서 온 그 수표가 지금의 커리어가 무엇이든 그 길로 밀어 넣은 계기였는지도 궁금함

• 이 글의 목표가 프로젝트를 버리는 일을 정상화하는 것이라면 좋은 생각인지 잘 모르겠음. 다른 걸 다 제쳐도 엄청난 시간 낭비가 될 수 있고, “그래도 배운 게 있다”는 말만으로는 정당화할 수 없음. 끝내면서도 배워야 하는 것 아닌가

  • Smarter Every Day의 훌륭한 에피소드에서 Destin이 유리공예 작업장과 함께 부서진 프린스 루퍼트의 방울을 레진 블록 안에 넣는 작업을 함
    아무도 해본 적 없는 일이라 진행하면서 방법을 찾아가고, 도중에 꽤 많은 실수를 함. 영상에서 강조하는 점 중 하나는 이런 일이 생겼을 때 팀이 그냥 멈추고 같은 걸 다시 시도하지 않는다는 것임. 계속 진행해서 완전히 망가뜨리고, 재료로 마음껏 실험하는 기회로 삼음
    그는 이게 얼마나 훌륭한지 길게 이야기함. 완성되고 다듬어진 제품을 만드는 경로 위에 있었다면 하지 않았을 시도를 자유롭게 해볼 수 있으므로, 다루는 재료의 거동을 더 배울 수 있는 비할 데 없는 기회를 활용하는 것임. 이미 쓰레기가 된 것을 더 망치기는 어렵기 때문에, 더 이상 위험을 감수한다고 보기도 애매함
    성공만을 중시하기보다 학습과 실험을 중시하는 사고방식이 자신이 하는 일에서 정말 뛰어나지는 최고의 방법 중 하나라는 지적은 맞다고 봄
  • 그는 실제로 완성한 것도 있음. 핵심은 분석 마비를 피하고 계속 생각만 하는 대신 “일단 해보는 것”임. 행동 편향이자 매몰비용을 거부하는 태도임
  • 그건 글을 잘못 읽은 것임. 글은 빠른 반복적 프로토타이핑을 통한 발견에 더 가깝고, 치명적 결함을 초기에 빠르게 발견하는 것도 포함
  • 제목이 별로라고 봄. 교훈은 “생각나는 건 전부 작업하되, 준비되기 전에는 아무것도 출시하지 말라. 어떤 프로젝트는 영영 준비되지 않을 수 있지만 괜찮다. 30년 뒤에 추억 삼아 GitHub에 올릴 수 있다”에 더 가까움
    ChatGPT는 “빠르게 만들고, 절대 출시하지 말라. 출시할 때까지는”이라고 요약함
  • 프로젝트가 죽는 건 건강하다고 봄. 틀에 갇혀 있는 대신 다른 프로젝트를 시작할 시간을 풀어줌
    가끔 아무 데도 가지 않는 프로젝트를 붙잡고, 충분히 노력하면 어디론가 갈 거라고 생각하지만 재미도 없고 새로 배우는 것도 없는 상태가 됨. “끝내야 해, 끝내야 해”라는 생각으로 스스로를 몰아붙이다가 “왜?”라고 물어보면 보통 끝내지 못하는 것에 대한 두려움 때문이거나, 어쩌면 힘든 구간과 실패한 프로젝트 구간을 구분하지 못할까 봐 두려운 것임. 어느 쪽이든 실패했을 때 해방감을 느낀 적이 너무 많음. 다시 시작할 기회가 됨

• 스크린샷의 픽셀 아트 몇몇은 정말 멋짐

• 개인적으로는 작은 것을 출시한 다음 반복하거나 버리면서 훨씬 더 많이 배우고 벌었음

• 이 방식은 마음에 들고 흥미롭지만, 조직 수준에서는 더 까다로워 보임. 프로젝트와 기술에 대해 우리가 발견하는 많은 것들은 실제 프로젝트가 동작하는 규모에서의 실현 가능성과 관련돼 있고, 작은 실험에서는 꼭 드러나지 않음
  때로는 기술 문제가 아니라 “여기 대부분의 개발자가 이 방식으로 하는 걸 이해하게 만들 수 있는가” 같은 문제이기도 함. 그렇다고 이런 시도를 더 하지 말자는 뜻은 아님. 작은 프로젝트를 시도하면서 배울 수 있는 것들은 있음. 다만 큰 규모에서도 작동한다는 보장은 아님

• 내 문제는 그냥 시간임. 퇴근해서 집에 오면 컴퓨터 앞에 앉는 게 제일 하기 싫음
  일주일에 이틀 쉬는 날도 집안일로 채워야 해서, 여전히 컴퓨터 화면 앞에 앉고 싶지 않음

  • 나는 주니어이고 지금 인턴십과 그다음 직장을 구하려고 하는 중임
    당신처럼 할 수 있는 사람이 부러움. 지금 업계는 기술과 프로그래밍을 인생 전체로 삼는 사람만 찾는 컬트처럼 느껴짐. 요구사항 자체가 싫은 건 아니고, 직업윤리도 있고 잘하고 싶지만, 기대치는 그 어느 때보다 높아 보임
    화면을 쳐다보지 않아도 되는 취미를 가질 만큼 직업 안정성이 생기길 기대하고 있음. 곧 금속 가공을 해보고 싶음