머신러닝 프로젝트가 마침내 실행됐다. 그리고 당신은 그것을 버렸다.

한 머신러닝 개발자가 이번 주 익숙한 역설을 설명했다. 프로젝트는 준비 상태가 약 90%에 도달했지만, 정작 핵심 아이디어는 끝내 구현되지 않았다. 의존성은 설치됐고, GPU도 인식됐으며, 모델은 다운로드됐고 첫 명령도 실행됐다. 그러자 흥미가 사라졌다.

이 이야기는 Crypton228이라는 사용자가 올린 Reddit 토론에서 나왔다. 이는 개인적 일화 하나일 뿐, 측정된 업계 추세를 입증하는 증거는 아니다. 그러나 그 반응은 머신러닝 작업에서 흔히 마주치는 긴장을 잘 포착한다.

환경 설정은 모든 문제에 눈에 보이는 해답이 있기 때문에 생산적으로 느껴진다. 누락된 라이브러리는 설치하면 된다. CUDA 충돌은 해결할 수 있다. 모델 체크포인트는 로드되거나 실패한다.

실제 프로젝트는 피드백이 더 모호하다. 목표가 불분명할 수 있고, 데이터가 부족할 수 있으며, 결과는 기대에 못 미칠 수 있다. 터미널이 명확한 오류를 더 이상 내놓지 않기 시작하면 성공의 기준도 정의하기 어려워진다.

이것이 핵심적인 역전이다. 원래는 사전 작업으로 여겨지던 일이 프로젝트에서 가장 만족스러운 부분이 될 수 있다. 스택을 실행시키는 일이 프로젝트 자체가 되고, 처음의 아이디어를 검증하는 일은 선택 사항이 된다.

이는 미완성 주말 실험을 넘어서는 문제다. 같은 유인은 연구 재현성, 사내 프로토타입, 오픈소스 저장소, 기업 AI 파일럿에도 영향을 미친다. 작동하는 환경은 필요하지만, 유용한 시스템이 존재한다는 증거는 아니다.

설정이 곧 산출물이 됐다

이 게시물이 주목할 만한 이유는 기술적인 결승선처럼 보이면서도 프로젝트의 진짜 불확실성은 피하는 지점을 짚어내기 때문이다.

설명된 순서는 현대 머신러닝 실험에서 흔하다. 개발자는 저장소를 고르고, 환경을 만들고, 패키지를 설치하고, 가속기 지원을 확인한 뒤 모델 가중치를 가져온다. 완료되는 각각의 작업은 구체적인 장애물 하나를 없앤다.

이 작업들은 어려울 수 있다. GPU 드라이버는 지원되는 런타임 버전과 맞아야 한다. Python 패키지는 서로 호환되지 않는 요구사항을 부과할 수 있다. 모델 가중치에는 인증, 상당한 저장 공간 또는 특정 로딩 형식이 필요할 수 있다.

이런 문제를 해결하면 역량을 즉시 입증할 수 있다. 성공적인 설치 메시지, 감지된 장치 또는 첫 생성 결과가 보상으로 나타난다. 진전은 눈에 보이고 이분법적이다.

반면 원래 프로젝트는 이런 깔끔한 신호를 거의 제공하지 않는다. 추천 시스템은 기준선보다 나아야 한다. 분류기에는 대표성 있는 평가 데이터가 필요하다. 로컬 어시스턴트는 기존 워크플로보다 반복적인 문제를 더 잘 해결해야 한다.

이 두 번째 단계에서는 판단이 필요하다. 개발자는 무엇이 유용한지 정하고, 기준선을 선택하며, 나쁜 출력을 살펴보고, 어쩌면 원래 전제를 버려야 한다. 패키지 관리자가 이런 질문에 답해줄 수는 없다.

이 차이는 “90% 완료”가 왜 오해를 부를 수 있는지 설명한다. 설정은 알려진 작업의 대부분을 차지할 수 있지만, 프로젝트의 실제 위험은 거의 다루지 못할 수 있다.

로드되는 모델은 통합 검사를 통과한 것이다. 유용성 검사를 통과한 것은 아니다. 설정에 더 많은 시간이 들었더라도 둘은 서로 다른 이정표다.

팀 환경에서도 비슷한 혼동이 나타난다. 프로토타입 시연이 검증을 대체할 때다. 잘 다듬어진 노트북은 API가 응답한다는 점은 보여줄 수 있지만, 정확성·신뢰성·사용자 수요를 확립하지는 못한다.

이 Reddit 게시물은 개발자들이 대체로 이 지점에서 프로젝트를 포기한다는 사실을 증명하지는 않는다. 다만 유인 구조를 간결하게 설명한다. 설정은 빠르고 이해하기 쉬운 성공을 만들어내는 반면, 제품 작업은 불확실한 결과를 드러낸다.

따라서 이 행동은 단순한 게으름 이상이다. 개발자는 시스템 통합, 디버깅, 도구 탐색을 진심으로 즐길 수 있다. 이는 타당한 관심사지만, 처음에 이름 붙였던 프로젝트와는 다른 프로젝트를 가리킨다.

애플리케이션을 구성한 뒤 반복적으로 포기하는 사람은 애플리케이션 개발에 실패하는 것이 아닐 수 있다. 자신이 선호하는 활동이라는 사실을 인식하지 못한 채 환경 엔지니어링을 추구하고 있을 수 있다.

이 구분은 명확히 말하는 순간 유용해진다. 개발자가 저장소에 붙은 제품 서사가 아니라, 실제로 무엇을 연습하고 싶은지를 기준으로 프로젝트를 판단하게 해준다.

머신러닝은 이 함정을 유난히 깊게 만든다

머신러닝 환경에는 코드, 데이터, 가중치, 하드웨어, 실행 동작이 모두 포함되므로 설정은 단순한 잡일 하나가 아니다.

일반적인 소프트웨어 프로젝트는 소스 코드와 런타임에 의존한다. 머신러닝 프로젝트에는 모델 아티팩트, 대규모 데이터세트, 가속기 라이브러리, 수치 연산 커널, 실험 구성이 더해진다. 각 계층은 조사해야 할 지점을 하나씩 더 만든다.

하드웨어 지원은 특히 설정 작업을 길게 늘이는 요인이다. 운영체제는 GPU를 올바르게 노출해야 한다. 드라이버, CUDA 구성 요소, 프레임워크, 컴파일된 확장 기능은 실행될 만큼 충분히 긴밀하게 맞아야 한다.

장치 확인에 성공하면 큰 성취처럼 느껴진다. 때로는 실제로 그렇다. 하지만 그것만으로는 프로젝트의 출력이 의도한 문제를 해결하는지 전혀 알 수 없다.

재현성은 또 다른 층을 더한다. PyTorch는 재현성 가이드에서 릴리스, 플랫폼, CPU 및 GPU 실행 환경이 달라지면 완전한 재현성이 보장되지 않는다고 경고한다.

일부 GPU 연산은 비결정적으로 동작할 수 있어, 반복 실행이 동일한 결과를 반환하지 않을 수 있다. 개발자는 지원되는 경우 결정론적 알고리즘을 요청할 수 있지만, 이 선택은 성능을 낮출 수 있다.

따라서 환경 작업에는 정당한 엔지니어링 목적이 있다. 의존성을 고정하고, 시드를 기록하며, 하드웨어를 문서화하고, 구성을 보존하면 취약한 실험을 다른 사람이 검토할 수 있는 것으로 바꿀 수 있다.

위험은 재현할 만한 의미 있는 결과가 생기기 전에 재현성 작업이 시작될 때 나타난다. 개발자는 가설조차 정의되지 않은 실험을 보존하는 데 며칠을 쓸 수 있다.

의존성 그래프 역시 끝없는 최적화를 부추긴다. 언제나 더 새로운 환경 관리자, 더 빠른 추론 라이브러리, 더 깔끔한 컨테이너 이미지, 더 우아한 구성 형식이 있다. 각각은 미래의 문제를 막아주겠다고 약속한다.

그 약속은 불확실성을 통제 가능한 영역으로 옮기기 때문에 매력적이다. 컨테이너를 개선하는 일은 모델이 실제 사례에서 성능이 떨어진다는 사실을 발견하는 것보다 안전하게 느껴진다.

머신러닝 저장소는 여러 시스템을 대상으로 한 설치 지침과 연구 코드를 함께 제공하면서 이 효과를 강화할 수 있다. 개발자는 하나의 호환성 문제를 해결한 뒤 선택적 확장 기능에서 또 다른 문제를 발견할 수 있다.

모델의 이용 가능성은 프로젝트의 심리적 경계도 바꿨다. 기존 모델을 다운로드하면 개발자가 그 주변에 어떤 것도 설계하기 전부터 인상적인 결과가 나올 수 있다.

첫 출력은 모델의 기본 예시에서 곧바로 나온 것일지라도 완성처럼 느껴질 수 있다. 이후 프로젝트는 자신이 초기에 보여준 장관과 경쟁해야 한다.

바로 이 지점에서 원래 목표가 중요하다. 목표가 스택의 작동 방식을 배우는 것이었다면, 실행 성공은 정당한 마무리일 수 있다. 목표가 사용자를 돕는 것이었다면, 실행은 출발선일 뿐이다.

짧은 프로젝트 계약서를 작성하면 이 차이를 드러낼 수 있다. 여기에는 입력 하나, 예상 출력 하나, 사용자 한 명, 그리고 결과가 추가로 한 주를 투자할 가치가 있는지 판단할 테스트 하나가 담겨야 한다.

그 계약서가 기술 작업을 없애지는 않는다. 기술 작업이 성공의 정의를 조용히 바꿔버리는 일을 막을 뿐이다.

재현성은 도움이 되지만, 회피 수단이 될 수도 있다

재현 가능한 환경은 가치 있는 작업을 보호하지만, 완벽한 환경만으로 가치를 만들 수는 없다.

더 나은 설정을 지지하는 근거는 충분하다. 한 대규모 연구는 Harvard Dataverse의 재현 패키지 2,091개를 조사했다. 연구진은 문서화, 구성, 실행 가능한 코드에서 큰 편차를 발견했다.

이들의 연구 코드 조사는 많은 패키지에 의존성 및 런타임 요구사항을 담는 일반적인 파일이 없다고 보고했다. 이런 누락은 나중의 실행을 더 어렵게 만든다.

이 증거는 신중한 환경 관리를 뒷받침한다. 하지만 프로젝트의 핵심 주장을 검증하기 전에 여기에 무제한의 시간을 쓰는 일을 뒷받침하지는 않는다.

올바른 질문은 재현성이 중요한지 여부가 아니다. 추가 재현성 작업이 또 한 번의 실험, 사용자 테스트 또는 오류 분석 세션보다 언제 더 가치 있는지가 핵심이다.

일회성 탐색과 공개된 연구 아티팩트에는 서로 다른 기준이 필요하다. 탐색에는 신뢰할 수 있는 결정을 내릴 만큼의 구조가 필요하다. 아티팩트에는 다른 사람이 그 결정을 반복하고 검토할 수 있을 만큼의 세부 사항이 필요하다.

모든 주말 실험에 출판 기준을 적용하면 학습 비용이 올라간다. 반대로 프로덕션이나 공개 연구에 주말 실험 기준을 적용하면 취약한 시스템과 검증 불가능한 주장이 나온다.

컨테이너는 그 격차를 줄일 수 있다. NVIDIA는 AI Workbench 환경을 구성 파일이 코드와 함께 이동하는 격리된 프로젝트 컨테이너로 설명한다. 해당 환경 문서는 의존성 격리와 반복 가능한 구성을 강조한다.

GitHub는 개발 컨테이너를 통해 관련 접근법을 제공한다. 저장소는 공유 도구, 런타임, 확장 기능 및 관련 설정을 정의하는 devcontainer.json 파일을 저장할 수 있다.

dev container 모델은 설정 지식을 버전 관리되는 프로젝트 자료로 바꾼다. 이는 반복적인 수동 설치를 줄이고 온보딩의 일관성을 높일 수 있다.

그러나 컨테이너가 판단을 없애지는 않는다. 누군가는 어떤 의존성을 내부에 넣을지, 어떤 버전을 고정할지, 어떤 하드웨어 가정이 이미지 밖에 남는지를 결정해야 한다.

컨테이너는 잘못된 것을 보존할 수도 있다. 평가 스크립트가 오염된 데이터세트를 사용한다면, 재현 가능한 실행은 같은 방법론적 결함을 재현할 것이다.

실용적인 기준은 환경이 식별된 다음 행동을 뒷받침하는지다. 변경이 다른 기여자가 실험을 실행하게 해준다면, 이는 결과물 제공을 지원한다. 단지 선호를 만족할 뿐이라면 우선순위는 덜 분명하다.

팀은 이 기준을 명시적으로 만들 수 있다. 모든 설정 작업은 네 가지 결과 중 하나와 연결돼야 한다. 첫 실행, 신뢰할 수 있는 평가, 협업 또는 배포다.

이 결과들에 속하지 않는 작업이 자동으로 낭비인 것은 아니다. 다만 기술적 필수 사항이라는 뒷문으로 들어오기보다 제품 작업과 공개적으로 경쟁해야 한다.

같은 원칙은 문서화에도 적용된다. 최종적으로 작동한 명령을 기록하는 일은 가치 있다. 프로젝트가 사용자 세션 하나를 견뎌내기도 전에 완전한 운영 매뉴얼을 작성하는 일은 정당화하기 더 어렵다.

좋은 설정은 다음 실험의 비용을 낮춘다. 설정을 위한 설정은 현재의 멈춤을 더 정교하게 만들 뿐이다.

진짜 상대는 정의된 진전과 편안한 진전이다

핵심 갈등은 코딩과 미루기 사이가 아니다. 결과와 연결된 진전과, 눈앞의 잡일로 정의된 진전 사이의 갈등이다.

모든 우회를 미루기라고 부르면 설정 속에 숨어 있는 유용한 작업을 놓치게 된다. 개발자는 설치 문제를 해결하며 프레임워크를 배우는 경우가 많다. 또한 하드웨어 한계, 문서화되지 않은 가정, 부실한 저장소 유지보수도 발견한다.

유용한 학습은 회피와 공존할 수 있다는 점이 문제다. 어떤 작업은 기술 지식을 늘려 주면서도, 해당 프로젝트에서 가장 중요한 유일한 검증을 미룰 수 있다.

명확하게 정의된 진척은 관찰 가능한 결과에서 시작된다. 로컬 문서 어시스턴트라면 고정된 문서 모음에서 인용 구절과 함께 열 개의 질문에 답하는 것이 그 예가 될 수 있다.

편안한 진척은 도구에서 시작된다. 질문을 정의하기 전에 어떤 벡터 데이터베이스, 오케스트레이션 라이브러리, 모델 형식 또는 인터페이스를 설치해야 하는지 묻는다.

첫 번째 접근법은 빠르게 실패할 수 있게 한다. 두 번째 접근법은 제안된 제품 아래의 플랫폼을 계속 확장하면서 실패를 미룰 수 있다.

이 차이는 버려진 리포지토리에 정교한 아키텍처가 일찍부터 등장하는 이유를 설명한다. 아키텍처는 해결 가능한 여러 하위 문제를 만든다. 사용자 가치는 불편한 질문 하나를 만든다.

기업 AI 파일럿도 더 큰 규모에서 같은 패턴을 마주한다. 팀은 애플리케이션이 개선해야 할 의사결정에 합의하기 전에 인프라, 보안 통제, 검색 구성 요소, 모니터링 시스템을 선택하는 데 몇 달을 쓸 수 있다.

특히 기밀 데이터나 규제 대상 프로세스가 관련된 경우, 그러한 준비의 일부는 필수다. 그렇더라도 거버넌스 요구사항이 측정 가능한 사용자 결과의 필요성을 없애지는 않는다.

개발자 연구 역시 도구 사용의 마찰이 실제 문제임을 보여 준다. Stack Overflow의 2024년 설문조사에서 전문 개발자의 63%는 기술 부채를 주요 업무상 불만으로 꼽았다.

같은 개발자 설문조사에 따르면 61%는 답이나 해결책을 찾는 데 매일 30분 이상을 썼다. 복잡한 빌드 및 배포 스택도 또 다른 두드러진 불만이었다.

이 결과는 취미 프로젝트가 아니라 전문 업무에 관한 것이다. 환경 마찰을 줄이는 데 투자할 이유를 보여 준다. 하지만 모든 로컬 설정 선택이 배포 성과를 높인다는 뜻은 아니다.

신뢰할 수 있는 환경은 재사용할 수 있을 때 레버리지를 만든다. 팀원이 이를 물려받고, 자동화 테스트가 이를 검증하며, 향후 실험이 같은 기반을 활용할수록 가치는 커진다.

두 번째 실행 계획이 없는 1인 프로토타입은 계산식이 다르다. 정교한 설정은 교육적일 수 있지만, 개발자는 이를 제품 개발이 아니라 학습 인프라라고 명명해야 한다.

이렇게 재분류하면 불필요한 죄책감이 사라진다. 또한 미완성 작업의 원인을 더 쉽게 진단할 수 있다.

목표가 CUDA 패키징 학습이라면 환경을 문서화한 뒤 멈추고 프로젝트를 완료로 선언하라. 목표가 사용 가능한 애플리케이션이라면 첫 성공적 실행을 완료로 간주할 수 없다.

결정을 보존하고 싶은 개발자는 코드베이스를 확장하는 대신 짧은 실험 로그를 남길 수 있다. 검색 가능한 엔지니어링 지식 베이스는 모든 실험이 제품이 될 것처럼 가장하지 않으면서도 명령어, 실패, 결론을 보존할 수 있다.

가장 중요한 산출물은 멈춘 이유를 명확히 하는 것일 수 있다. “모델이 목표 기기에서 너무 느렸다”는 말은 거의 완성으로 표시된 채 손대지 않은 리포지토리보다 더 많은 것을 가르쳐 준다.

따라서 정의된 진척에는 의도적인 취소도 포함된다. 프로젝트는 배포, 반증된 가설 또는 문서화된 학습 결과를 통해 끝날 수 있다. 포기는 어떤 결정도 순환을 마무리하지 못했다는 점에서 다르다.

더 작은 결승선이 프로젝트를 바꾼다

가장 좋은 대응책은 더 많은 동기가 아니라, 설정이 남은 호기심을 소진하기 전에 도달할 수 있을 만큼 작은 결승선이다.

머신러닝 프로젝트는 가장 작은 엔드투엔드 단위부터 시작해야 한다. 그 단위에는 실제 입력, 모델 호출, 눈에 보이는 출력, 그리고 하나의 평가 규칙이 포함된다.

선호하는 인터페이스가 필요하지는 않다. 완전한 자동화도 필요하지 않다. 아이디어가 더 많은 작업을 할 가치가 있는지 드러낼 만큼의 구조만 있으면 된다.

분류기의 경우, 그 단위는 수작업으로 라벨링한 평가 세트와 간단한 명령줄 스크립트로 구성될 수 있다. 검색의 경우, 구현 전에 작성한 열 개의 질문과 작은 문서 폴더를 사용할 수 있다.

이미지 생성의 경우, 고정된 프롬프트 세트와 결과를 비교할 수 있다. 로컬 추론의 경우, 대표 작업 하나가 메모리에 들어가고 허용 가능한 지연 시간 안에 끝나는지 측정할 수 있다.

목표는 제품의 불확실성을 일찍 마주하는 것이다. 좁은 수직 슬라이스는 데이터 품질, 출력 품질, 지연 시간, 사용성을 같은 논의 안으로 끌어들인다.

그러면 설정 작업의 우선순위를 정하기가 쉬워진다. 해당 슬라이스에 필요한 것만 설치하라. 실행에 실질적인 영향을 주는 버전은 기록하라. 평가가 필요성을 드러낼 때까지 선택적 서비스는 미뤄라.

유용한 체크포인트는 첫 번째 비가역적 사용자 대면 결정이다. 목표 작업을 선택하거나, 평가 세트를 정의하거나, 다른 사람에게 출력을 사용해 보게 하는 일이 될 수 있다.

그 시점 전까지 프로젝트는 정교한 샌드박스로 남을 수 있다. 그 선을 넘으면 기술 활동은 반박 가능한 주장으로 바뀐다.

또 다른 방법은 탐색과 프로덕션을 명시적으로 분리하는 것이다. 아이디어를 검증하기 위한 일회용 브랜치나 노트북을 하나 만들고, 평가를 통과한 부분만 승격하라.

이렇게 하면 프로덕션 관련 우려가 첫 번째 검증을 지배하지 못한다. 또한 탐색 단계의 편법이 더 오래 유지되는 시스템에 조용히 들어가는 것도 막는다.

시간 제한은 의사결정과 연결될 때 도움이 된다. “GPU 지원에 두 시간을 쓰고, 그다음에는 CPU나 호스팅 런타임을 사용한다”는 “CUDA 설정을 끝낸다”보다 낫다.

첫 번째 규칙에는 출구가 있다. 두 번째 규칙은 설정에는 언제나 또 다른 해결책이 있을 수 있기 때문에 끝없는 조사를 부른다.

개발자는 설정 예산도 정의할 수 있다. 프로젝트는 엔드투엔드 결과를 요구하기 전에 환경 파일 하나, 실행 명령 하나, 문서화된 대체 수단 하나를 허용할 수 있다.

예산이 경직된 의식이 되어서는 안 된다. 커스텀 커널을 다루는 연구 프로젝트는 프롬프트 라우팅 실험보다 실제로 더 많은 인프라가 필요하다.

핵심은 복잡성이 제자리를 얻도록 만드는 것이다. 추가되는 모든 구성 요소는 측정된 제약을 제거하거나, 알려진 요구사항을 보호하거나, 명시된 테스트를 가능하게 해야 한다.

프로젝트에는 눈에 보이는 완료 기록도 필요하다. 짧은 데모 영상, 평가 보고서, 태그된 릴리스 또는 문서화된 부정적 결과가 마무리를 만든다.

마무리는 중요하다. 버려진 리포지토리는 모호함을 보존하기 때문이다. 원래 아이디어에 관한 증거는 제공하지 않으면서도 상상 속의 모든 개선점을 계속 살아 있게 둔다.

완료된 부정적 결과가 더 유용하다. 모델은 정상적으로 로드됐지만 지연 시간 목표를 충족하지 못했거나, 정확도가 부족했거나, 개발자가 확보할 수 없는 데이터를 필요로 했다고 말할 수 있다.

그 결론은 설정 경험을 전이 가능한 지식으로 바꾼다. 또한 다음 프로젝트가 같은 불확실성을 반복하지 않고 시작할 수 있게 한다.

이것이 공감 가는 글 이상임을 무엇이 증명할까

다음 신호는 또 하나의 고백이 아니라, 개발자와 팀이 첫 실행과 검증된 결과 사이의 거리를 측정하는지 여부다.

먼저 살펴볼 것은 원래 논의 안에서의 후속 실행이다. 참여자들이 완료된 산출물, 실패 보고서 또는 재현 가능한 중단 규칙을 공유한다면, 대화는 단순한 공감을 넘어선다.

두 번째 신호는 개발 플랫폼의 제품 설계다. Dev container, 재현 가능한 워크스페이스, 관리형 모델 환경은 반복되는 설정을 줄이지만, 그 가치는 이후에 무엇이 일어나는지에 달려 있다.

유용한 플랫폼은 리포지토리 클론부터 평가된 결과까지 걸리는 시간을 줄여야 한다. 첫 실행까지의 시간만 측정하면 이 글에서 설명한 바로 그 혼란을 부추긴다.

세 번째 신호는 AI 코딩 에이전트가 균형을 어떻게 바꾸는지다. 에이전트는 패키지를 설치하고, 오류를 해석하며, 설정 파일을 만들 수 있다. 이는 일상적인 환경 작업을 줄여야 한다.

하지만 새로운 리포지토리를 시작하는 일까지 거의 수고 없이 만들면, 쉬워진 설정은 더 많은 버려진 프로젝트를 만들 수 있다. 시작 비용이 낮아진다고 완료율이 자동으로 높아지는 것은 아니다.

에이전트는 사용자가 성공을 정의하기도 전에 세련된 스캐폴딩을 생성함으로써 함정을 더 깊게 만들 수도 있다. 완성된 것처럼 보이는 디렉터리는 증거 없이도 자신감을 줄 수 있다.

따라서 결정적인 지표는 얼마나 많은 프로젝트가 시작되는지가 아니다. 사용자 테스트, 벤치마크, 문서화된 기각 또는 유지되는 릴리스에 도달하는 프로젝트가 얼마나 많은지다.

개별 개발자도 같은 기준을 즉시 적용할 수 있다. 또 다른 설정 가이드를 열기 전에, 현재 프로젝트를 계속할 가치가 있게 만들 단 하나의 결과를 적어라.

그다음 가장 단순하게 사용할 수 있는 스택으로 그 결과를 만들 마감 시점을 정하라. 환경이 이를 막는다면 장애물을 문서화하고 대안을 사용하라. 아이디어가 실패한다면 이유를 기록하고 의도적으로 마무리하라.

원래 Reddit 게시물이 공감을 얻는 이유는 많은 기술 인력이 어려운 스택을 협력하게 만드는 즐거움을 알아보기 때문이다. 그 즐거움은 실제이며, 그것 자체가 취미가 될 수도 있다.

프로젝트에 솔직한 이름을 붙이면 선택은 더 분명해진다. 도구를 만들고 있는가, 가설을 검증하고 있는가, 아니면 환경을 탐색하고 있는가?

결과 하나를 선택하고 관찰 가능하게 만들어라. 그다음 다음 의존성이 그 결과에 가까워지게 하는지, 아니면 그저 또 하나의 만족스러운 해결 과제를 주는지 물어라.