Steve Test: 이 작업은 존재할 자격이 있는가?

이번 주 초, 제가 한 작업에서 가장 옳은 선택은 출시하지 않는 것이었어요. 번역 파이프라인은 이 사이트의 콘텐츠를 10개 로캘용으로 Cloudflare D1에 기록해요. 번역 작업 3개가 동시에 속도 제한에 걸렸고, 대체 처리 로직은 그중 6개 로캘에 대해 영어 원문을 “번역”으로 조용히 D1에 써 버렸어요. 그런 다음 체크포인트 해시도 영어 콘텐츠에 맞춰 갱신했어요. 디스크에서는 성공처럼 보였어요. 파이프라인은 “완료”라고 보고했어요. 지표는 10개 로캘이 출시됐다고 말했어요. 모든 자동 검사가 통과했어요.

독일어 독자가 /de/guides/claude-code에 들어오면 독일어 문단 하나, 영어 문단 하나, 다시 독일어 문단 하나, 그리고 영어 섹션 제목을 마주했을 거예요. 전환을 설명하는 표시는 어디에도 없었어요. 페이지는 의도된 것처럼 보였고, 사이트 전체를 믿을 수 없게 만들었어요. 이 제품이라면 원래 해야 하는 다른 일도 아마 제대로 못 할 것 같다는 느낌을 주는 종류의 실패였죠. 제가 계측해 둔 모든 층에서 Jiro Test, 즉 작업은 올바른가?는 통과했어요. 그런데도 그 결과물은 존재할 자격이 없었어요. 겉으로는 제품처럼 보였지만, 실제로는 모욕처럼 작동했어요.

옳은 답은 멈추는 것이었어요. 영어 대체 처리에 걸린 모든 배치를 감사하고, 체크포인트 해시를 정밀하게 지우고, 번역 파이프라인을 한 번에 한 작업씩 실행하고, 로캘별로 검증한 뒤 커밋하고 푸시해야 했어요. 실제 경과 시간으로 약 6시간의 번역 시간, 그리고 재발을 막기 위한 보호 장치 패치 하나가 필요했어요. 디스크 위의 산출물은 그 내내 “작동”하고 있었어요. 프로덕션에 올라간 산출물은 제가 일으킨 피해였어요.

실패의 형태는 산출물이 번역 파이프라인이든, 가입 흐름이든, 기능 토글이든, CSV 내보내기든, 마케팅 페이지든 똑같아요. 모든 자동 검사는 통과해요. 실제 사용자 앞에 놓인 것은 피해예요.

제품에서 기준이 되는 질문은 끝났는가?도, 작동하는가?도 아니에요. 기준이 되는 질문은 이 작업은 존재할 자격이 있는가?예요. 모든 산출물은 출시되기 전에 이 질문에 답해야 해요. 그리고 별도의 정확성 기준도 함께 통과해야 해요. 존재할 자격 없는 정확성은 재고를 만들어요. 작동하고 출시되지만 신뢰를 얻지 못하는 것들이 쌓여요. 정확성 없는 존재 가치는 연극을 만들어요. 맞아 보이지만 깨지는 것들이죠. 두 기준은 모두 통과해야 해요.

제가 쓰는 약칭은 Steve Test예요. 엄밀함과 증거를 위한 Jiro Test 옆에 놓여 있어요. 같은 정신으로 적용하는 서로 다른 두 질문이며, 저는 둘 중 하나라도 실패한 작업은 출시하지 않아요.

한눈에 보기

Steve Test는 모든 산출물이 통과해야 하는 두 번째 기준이에요. Jiro는 작업이 올바른지 묻고, Steve는 그 작업이 당신이 만들고 있는 전체의 일부로 존재할 자격이 있는지 물어요. 이 기준은 추상적이지 않고 구체적이에요. 실제 순간에 놓인 실제 사용자를 기준으로 측정하며, 가장 일관된 결과물은 거절이에요. 저는 범위를 줄여요. 기능을 삭제해요. 남은 것은 제 이름을 걸 수 있어야 해요. 두 기준은 모두 통과해야 해요. Jiro가 실패하면 멈추고 고쳐야 해요. Steve가 실패하면 다시 만들어야 해요. 정직한 재구축은 최대 3번이에요. 그 뒤에도 실패한다면 문제는 상류, 즉 문제 설정에 있어요.

왜 “끝났는가?”는 잘못된 질문인가

대부분의 제품 팀은 “출시할 수 있는가”에 맞춰 움직여요. 측정되는 산출물은 커밋, 배포, 속도 차트, 프로덕션에 무언가 존재한다는 사실이에요. 실패 양상은 예측 가능해요. 팀은 올바르게 작동하는 산출물을 꾸준히 만들고, 사용자의 신뢰를 조용히 써 버려요. 온보딩은 끝나지만 두 번째 사용은 일어나지 않아요. 제품이 해낼 수 있다고 말한 작업 주변에 지원 문의가 몰려요. 이탈 곡선은 핵심 사용자층으로 평평해지지 않고 0을 향해 내려가요.

끝남과 존재할 자격은 서로 다른 측정값이에요. 기능은 끝났지만 존재할 자격이 없을 수 있어요. 페이지는 렌더링되지만 독자를 모욕할 수 있어요. 번역은 기술적으로 존재하지만 사실상 거짓말일 수 있어요. 어떤 것이 끝났는지 판단하는 기준은 지정된 동작을 실행하는가예요. 어떤 것이 존재할 자격이 있는지 판단하는 기준은 실제 사용자가 실제 순간에 그것을 출시한 덕분에 더 나아졌는가예요.

제가 최소한의 자격을 갖춘 제품에서 주장한 바는, 실제 현장의 MVP 문화가 두 질문을 하나로 붕괴시켰다는 점이에요. 빨리 배우기는 빨리 출시하기로 퇴화했고, 출시 자체가 중요한 지표가 되었어요.⁷ 처방은 이중 기준이에요. 최소라는 기준은 범위를 줄여요. 자격이라는 기준은 남은 표면을 사용자가 느낄 수 있는 수준까지 끌어올려요. Steve Test는 남은 표면이 그 기준을 넘었는지 판단할 때 쓰는 도구예요.

기준이 되는 질문

이 작업은 존재할 자격이 있는가?

저는 이 질문을 문자 그대로 사용해요. 한 작업을 끝내고 출시할지 결정해야 할 때, 이 질문을 소리 내어 물어요. 답은 분위기가 아니라 판정이에요. 답이 예라면 그 작업은 출시 후보가 되고, 다음 질문은 그것이 정확성에 대한 Jiro Test도 통과하는지예요. 답이 아니라면 그 작업은 다시 만들거나 삭제해야 해요. 답이 아직은 아니지만, 정의된 수정 조치 안에서 그렇게 될 수 있다라면 계속 작업해요.

이 질문은 답이 아니오일 수 있을 때만 작동해요. 눈앞의 결과물을 무조건 승인만 하는 Steve Test는 기준이 아니에요. 이 기준이 실제로 작동하고 있다는 신호는 어떤 작업이 그것을 통과하지 못한다는 점이에요.

사용자 축: 존재할 자격은 추상적일 수 없어요

Steve Test가 고립된 작업에 대한 취향 논쟁이 되는 순간 실패해요. 존재할 자격은 특정 순간의 특정 사용자를 기준으로 측정해야 해요. 제대로 표현한 질문은 이거예요. 이 작업은 이 순간의 이 사용자를 위해 존재할 자격이 있는가?

blakecrosley.com에서 사용자는 Claude Code, Codex, 인프라에 대해 답을 찾지 못한 질문을 들고 검색에서 바로 유입된 독자예요. 순간은 페이지가 로드된 뒤 첫 5초, 아직 페이지가 신뢰를 얻기 전이에요. 빠르게 로드되고, 관점을 읽기 쉽게 제시하며, 검색이 이미 답하지 못한 것을 독자에게 말해 주는 페이지는 기준을 넘은 거예요. 느린 번들, 닫을 수 없는 쿠키 배너, SEO 형식만 갖춘 범용 문장 벽으로 독자를 벌주는 페이지는 Jiro 축에서 아무리 점수가 좋아도 실패한 거예요.

ResumeGeni에서 사용자는 제가 취약한 순간으로 다루는 구직자예요. 초기 대기자 명단의 대부분은 해고 이후이거나 면접 과정 중에 들어왔어요.⁶ 존재할 자격이 있는 버전은 그들을 전환 지표로 취급하지 않아요. 카피는 애매하게 빠져나가지 않아요. 파서는 자신이 찾은 내용을 거짓으로 말하지 않아요. 조언은 사용자가 실제로 행동할 수 있을 만큼 구체적이에요. 제가 출시한 것이 성공 경로뿐이었다는 이유로 흐름이 중간에 사용자를 버리지 않아요.

사용자 축은 Steve Test가 제 개인 취향을 정당화하는 공간이 되지 않게 막는 장치예요. 사용자를 말할 수 없고, 그 순간을 말할 수 없고, 출시된 표면이 어떻게 그들을 존중하고 강화하는지 설명할 수 없다면, 저는 기준을 적용한 게 아니에요. 기준을 주장했을 뿐이에요.

이중 기준: Jiro와 Steve

전체 원칙에는 하나가 아니라 두 개의 기준이 필요해요.¹ 저는 둘 중 하나라도 실패한 것은 출시하지 않아요.

Jiro Test는 이렇게 물어요. 이것은 올바르게 만들어졌는가? 여기에는 증거가 필요해요. 경계 사례가 처리되어야 해요. 보이지 않는 디테일이 마무리되어야 해요. 주장은 구체적인 증거를 인용해야 해요. 얼버무림은 안 돼요. 저는 믿습니다는 증거가 아니에요. 테스트는 통과해야 해요. 회귀는 없어야 해요. 증거 관문은 제가 코드 보고서와 에이전트 출력에 적용하는 Jiro Test의 형태이고, Jiro 품질 철학은 더 깊은 설명이에요.

Steve Test는 이렇게 물어요. 이 작업은 존재할 자격이 있는가? 여기에는 존재할 자격이 필요해요. 전체와의 일관성이 필요해요. 드러나는 관점이 필요해요. 표면을 깨끗하게 지키기 위해 무엇을 거절하거나 삭제했는지 명시해야 해요. 독자가 알아볼 수 있는 즐거움 또는 명료함의 장치가 있어야 해요. 두루뭉술한 설명으로 넘길 수 없어요. 자기 이름을 걸 수 있어야 해요.

판정은 단순해요. Jiro가 실패하면 멈추고 고쳐요. 틀린 작업은 출시하지 않아요. Jiro의 거부권은 절대적이에요. Jiro는 통과했지만 Steve가 실패하면 다시 만들어요. 정확하지만 존재할 자격 없는 작업도 출시하지 않아요. 둘 다 실패했다면 문제는 상류, 즉 브리프나 문제 설정이나 범위에 있어요. 둘 다 통과한 작업만 출시 후보가 돼요.

대부분의 출시 문화는 둘 중 하나만 조용히 실행해요. 엔지니어링 주도 문화는 강한 Jiro와 약한 Steve로 움직이는 경우가 많아요. 테스트가 통과하면 제품은 출시되고, 존재할 자격은 다른 부서의 일이 돼요. 디자인 주도 문화는 때때로 강한 Steve와 약한 Jiro로 움직여요. 보기 좋으면 제품은 출시되고, 정확성은 운영 문제가 돼요. 두 실패 양상 모두 알아볼 수 있는 산출물을 만들어요. 아름다운 헛소리. 정확하지만 영혼 없는 작업. 본 적 있을 거예요. 어쩌면 출시해 본 적도 있을 거예요.

두 기준은 나란히 놓여 있어요.

전체 제품 경험: 총체적 경험을 책임지세요

Steve Test는 산출물을 고립된 상태로 판단하지 않아요. 사용자가 만나는 전체 경험의 일부로 판단해요.

처음에 말한 번역 사고는 최근 사례 중 가장 선명한 예예요. 구체적인 실패 구조를 자세히 풀어 볼 가치가 있어요. 함정의 형태를 보여 주기 때문이에요. Claude 하위 프로세스가 속도 제한에 걸렸을 때, 파이프라인의 대체 처리 로직은 영어 원문을 D1에 썼어요. D1 작성기는 그 바이트를 받아들였어요. 바이트였으니까요. 체크포인트 업데이트기는 저장된 콘텐츠를 해시하고 그 해시를 디스크에 썼어요. 저장된 “번역”이 영어 원문과 동일했기 때문에 해시는 정확히 일치했어요. 동일한 바이트가 동일한 해시를 만든 거예요. 다음 --update 실행은 영어 원문 해시를 저장된 해시와 비교했고, 둘이 같다는 것을 확인한 뒤 배치를 변경 없음으로 표시했어요. 각 구성 요소는 고립된 상태에서 자기 Jiro Test를 통과했어요. 결함은 조합 안에 있었어요. 사람이 페이지 하나를 열어 보기 전까지, 사용자는 몇 시간 동안 6개 로캘에서 언어가 섞인 문장을 봤어요.

“우리는 전체 제품 경험을 책임진다”가 규칙이에요. 제품 동작, UX 흐름, 언어, 데이터의 진실성, 지원 시스템, 패키징, 문서 정확성, 프롬프트, 규칙, 메모리, 스킬, 훅, 스크립트, 오케스트레이션, 출력 구조까지요. 가장 최근에 출시한 산출물만이 아니라 전체를 책임져요. 부분적인 승리가 전체의 무결성을 떨어뜨린다면 받아들일 수 없어요. 어떤 표면이 국소적으로는 통과했지만 전체 사용자 경험은 통과하지 못할 때 Steve Test가 작동해요.

삭제: 더하기만 하는 Steve 단계는 거짓이에요

Steve Test가 만들어내는 가장 유용한 결과는 삭제예요.

아무것도 제거하지 않고 끝난 검토는 실제로 실행된 검토가 아니에요. 진짜 복잡성이 있는 표면에 대해 이 작업은 존재할 자격이 있는가?라고 물으면, 거의 항상 자기 자리를 방어하지 못하는 범위, 카피, 기능, 조작 요소가 하나 이상 나와요. 그런 조각을 하나도 찾지 못한 검토는 보통 검토를 실제로 한 것이 아니라 검토하는 척한 경우예요.

Steve Test가 구체적으로 찾는 것은 이런 것들이에요.

• 제 자리를 얻었기 때문이 아니라 넣어 두면 안전해 보였기 때문에 존재하는 표면.
• 실제 주장을 해야 하는 부담을 피하려고 애매하게 빠져나가는 카피.
• 이전 버전에서 넘어왔지만 현재의 약속에는 더 이상 기여하지 않는 기능.
• 현재 범위에서는 실제로 일어나지 않는 경계 사례를 처리하려고 추가된 조작 요소.
• 만든 사람이 내려야 할 결정을 사용자에게 떠넘기는 설정 옵션.
• 제품이 더 이상 하지 않는 동작을 설명하는 문서.
• 삭제해야 할 코드를 덮고 있는 테스트.

삭제는 취향과 축적을 가르는 행위예요. 존재할 자격이 있는 표면은 아무도 질문하지 않았다면 출시했을 버전보다 작아요. 저는 출시한 제품에서 무언가를 제거한 일을 후회한 적이 없어요. 남겨 둔 것은 자주 후회했어요.

거절을 주된 행위로 삼기

삭제와 관련되어 있고, 더 강한 개념이 있어요. Steve Test는 무엇이든 만든 뒤가 아니라 만들기 전에 작동하는 경우가 많아요. 취향의 핵심 행위는 거절이에요. 애초에 그것을 만들지 않기로 하는 결정이죠.

여기서 중요한 Steve Jobs의 말은 2006년 BusinessWeek가 Apple의 제품 규율을 다룬 표지 기사에서 보도한, “우리가 하는 일만큼, 하지 않는 일도 자랑스럽다”라는 문장이에요.⁵ 사람들이 이 말을 자주 인용하는 이유는 특정한 기술적 의미에서 그것이 사실이기 때문이에요. 출시된 모든 제품의 주변에는 출시를 거절한 제품들의 보이지 않는 후광이 있어요. 그 후광이 실제 관점이에요. 백로그가 아니라 사람이 결정을 내렸다는 증거예요.

blakecrosley.com에서 스택은 제가 쳐낸 것들의 기록이에요. React를 검토했고 거절했어요. Tailwind를 검토했고 거절했어요. 재구축 첫 2주 동안 번들러도 선택지 위에 있었지만 잘라냈어요. 저장소 어디에도 node_modules/가 없다는 사실은 디자인 선택이 아니에요. 기본 도구가 끌어당기는 힘에 맞서 시간이 지나도 계속 유지하는 거절이에요. 이런 거절은 어떤 포함보다 작업의 형태를 더 강하게 만들어요. 제가 무엇을 기준으로 삼을 의지가 있었는지 정의해요.

ResumeGeni에서는 검증 결과가 좋았어요. 이메일 가입 340건, 직접 문의 12건, 초기 이용권에 돈을 내겠다는 자발적 제안 3건이 있었어요.⁶ 그 수요가 드러낸 백로그는 컸어요. 템플릿, 팀 협업, 분석 대시보드, LinkedIn 통합, Indeed 통합, 버전 기록, 여러 내보내기 형식, 모바일 앱까지요. 저는 첫 출시 버전에서 그 전부를 거절했어요. 거절할 수 없었던 것은 정확한 파싱, 정직한 격차 평가, 직무 설명에 맞는 구체적 재작성, Word에서 깨끗하게 열리는 내보내기, 취약한 사용자가 안전하다고 느끼게 하는 흐름이었어요. 거절된 것들이 영원히 사라진 것은 아니에요. 존재할 자격이 있는 첫 표면이 마련된 뒤에야 다룰 일로 기다리고 있어요.

아무것도 거절하지 않는 표면은 관점이 없는 표면이에요. 팀이 아무것도 거절하지 않았다면 범위가 잘못된 거예요.

가짜 성공은 일찍, 먼저 자기 것부터 가려내세요

거절과 삭제는 기준이 거짓 성공을 실제로 이름 붙일 수 있을 때만 작동해요. Steve Test는 허튼 성공을 허튼 성공이라고 불러야 해요. 그것도 빠르게요. 대상은 이런 것들이에요.

• 가짜 진척. 진척처럼 보이지만 아무것도 만들지 않는 움직임.
• 오염된 증거. 잘못된 이유로 통과한 테스트. 사실이 아니라 증명하고 싶었던 것을 증명하는 통계.
• 허영 지표 세기. 커밋 수, 출시 산출물 수, 속도 차트. 모두 존재하지만 모두 핵심에서 벗어나 있어요.
• 일관성 없는 시스템. 고립된 상태에서는 깨끗하게 출시되지만 조합되면 서로를 망치는 시스템. 위의 번역 사고가 여기에 속해요.
• “모든 것이 계획대로입니다” 보고. 아무도 내리지 않은 결정을 덮어 버리는 보고예요. Steve Test는 이런 보고의 적이에요.
• 낮은 가치의 기계 활동. 컴퓨터가 할 수 있기 때문에 하는 일이지, 출력물이 자기 자리를 얻었기 때문에 하는 일이 아니에요.

가장 어렵고 가장 꾸준히 유용한 버전의 규칙은 이거예요. 자기 출력물부터 허튼 성공이라고 부르세요. 이 글의 앞부분에 나온 번역 사고가 정확히 그 사례예요. 파이프라인은 성공을 보고했어요. 로그는 깨끗했어요. 제가 계측해 둔 모든 지표가 통과했어요. 그 작업은 허튼 성공이었고, 사용자가 그렇게 부르기 전에 제가 먼저 그렇게 불러야 했어요. 자기 작업에서 허튼 성공을 막는 태도는 이 기준을 정직하게 유지하는 규율이에요. 예의는 진실을 막는 방패가 아니고, 바쁨은 가치의 대체물이 아니에요.

표면별 강도: 통과 기준 조정하기

Steve Test는 하나의 문턱만 가진 단일 통과 기준이 아니에요. 되돌리기 어려운 표면일수록 통과 기준도 더 강해야 해요.²

질문은 같아요. 답에 요구되는 엄격함은 영향 범위에 따라 커져요. 채팅 답변은 다음 턴에 고칠 수 있어요. 큰일은 나지 않아요. Steve Test에 실패한 프로덕션 배포는 몇 달 동안 얻은 사용자 신뢰를 태워 버리고, 수정 비용은 원래 출시 결정이 아낀 비용보다 더 커져요.

실무적 결론은, 되돌리기 어려운 표면으로 갈수록 출시 속도는 느려져야 한다는 거예요. 되돌릴 수 있는 정도가 매우 다른 표면들을 같은 속도로 출시하는 팀은 이 기준이 달라진다고 생각하지 않는다는 신호를 보내고 있어요. 보통 그런 팀은 기준 실행을 멈춘 상태예요.

취향은 기질이 아니에요

Steve Test에는 하나의 구분이 더 필요해요. 가장 자주 잊히는 구분이기도 해요. Steve를 이야기한다는 것은 그의 취향을 이야기한다는 뜻이지, 그의 기질을 이야기한다는 뜻이 아니에요.

이 원칙은 다음을 명시적으로 금지해요.³

• 잔인함.
• 모욕.
• 연극적인 경멸.
• 비전가 코스프레.
• 판단의 대체물로 쓰는 공격성.
• 원한 섞인 연극.
• 기준으로 오해된 드라마.

Steve 단계가 실제로 작동하고 있다는 신호는 차분한 거절이에요. “아니요, 이 작업은 아직 존재할 자격이 없어요”라고 판정으로 말하고, 그 뒤에 구체적인 수정 조치를 제시하는 것이죠. 연기가 아니에요. 존재할 자격 없는 버전을 만든 사람, 많은 경우 자기 자신을 모욕하는 것도 아니에요. 팀을 향한 눈에 보이는 경멸도 아니에요. 내가 더 높은 기준을 가졌다고 방송하는 것도 아니에요. 작업은 기준을 넘거나 넘지 못해요. 그 기준은 엄격해 보이는 미학이 아니에요.

이 구분이 중요한 이유는 희화화된 Steve Jobs가 기질을 중심에 두기 때문이에요. Steve를 연기하는 사람에게 관리받아 본 사람이라면 무슨 말인지 알 거예요. 잔인함은 작업을 더 좋게 만들지 않아요. 일터를 더 나쁘게 만들고, 판단 대신 연극을 넣기 때문에 출시되는 작업도 더 나쁘게 만들어요.

당신이 Steve의 취향 층에 있는지, 아니면 Steve의 기질을 흉내 내는 상태에 있는지 가르는 작동 기준은 테스트의 출력이 구체적인 기술적 조치인가예요. “이 작업은 존재할 자격이 없다”는 결론이 아니에요. 질문의 시작이에요. 답은 실패한 축, 수정 조치, 다음 테스트를 말해야 해요. 무엇이 그것을 존재할 자격 있게 만들지 말하지 않은 채 “작업이 나쁘다”에서 검토가 끝난다면, 그 검토는 연기였어요.

재구축 상한과 마비 방지 조항

멈춤 규칙이 없는 높은 기준은 회피가 돼요. 저는 모든 간단하지 않은 작업에 정직한 재구축 3번이라는 상한을 적용해요.

정직한 시도란 실패한 축을 식별하고, 구체적인 수정 조치를 말하고, 접근 방식을 실질적으로 바꾸고, 두 기준에 맞춰 작업을 다시 평가했다는 뜻이에요. 같은 다듬기 단계를 3번 반복한 것은 3번의 시도가 아니에요. 그것은 실패한 시도 하나를 3번 반복한 거예요.

정직한 재구축을 3번 했는데도 존재할 자격 있는 작업이 나오지 않는다면, 문제는 거의 절대 기량이 아니에요. 문제는 상류, 즉 문제 설정, 범위, 브리프, 팀 구성에 있어요. 표면을 계속 다시 만들지 말고 전제를 보세요. 때로는 현실적으로 기준을 지킬 수 있는 범위보다 약속이 너무 컸던 거예요. 때로는 검증이 생각보다 약했던 거예요. 때로는 문제가 제품 문제가 아닐 수도 있어요.

재구축 상한은 서로 반대되는 두 실패 양상을 동시에 해결해요. 약한 작업에 통과 도장을 찍지 않고, 정교화가 숨는 행위가 되는 것도 막아요. 출시하지 않는 것이 본질적으로 고결한 것은 아니에요. 완벽을 추구한다며 끝없이 다시 만드는 것도 자체적인 실패 양상이에요. 용기 없는 장인정신이죠. 목표는 완벽이 아니에요. 목표는 존재할 자격이 있고 출시된 것이에요. 순수하지만 영원히 대기 중인 것이 아니에요.

같은 표면을 네 번째로 다시 만들고 있다면, 당신은 제품을 만드는 일을 멈추고 프로젝트를 숨을 장소로 쓰기 시작한 거예요.

관찰 가능한 징후: 기준이 실제로 실행됐나요?

Steve Test는 주장하기 쉽고 실제로 실행하기 어려워요. 규율은 이 기준이 무엇을 만들어냈는지 구체적으로 말하는 데 있어요.

간단하지 않은 작업을 완료했다고 말하기 전에, 저는 다음 질문들에 모두 답할 수 있는지 확인해요.⁴

1. 사용자는 누구인가요? 페르소나 유형이 아니에요. 실제 상황에 놓인 실제 사람이에요.
2. 이 표면은 어떤 관점을 담고 있나요? 말할 수 없다면 관점은 없고 백로그만 있는 거예요.
3. 깨끗하게 유지하기 위해 무엇을 거절하거나 제거했나요? 삭제는 기준이 실행됐다는 증거예요.
4. 이것은 전체 제품 경험에 어떻게 기여하나요? 이 조각은 다른 모든 조각과 일관되어야 해요. 전체를 망치는 부분 승리는 승리가 아니에요.
5. 그것이 탄탄하다는 증거는 무엇인가요? Jiro 축이에요. 검증이 실행됐고, 주장이 뒷받침되어야 해요.
6. 왜 존재할 자격이 있나요? 분명하게 말해야 해요. 답이 흐리면 기준은 실행되지 않은 거예요.
7. 망설임 없이 제 이름을 걸 수 있나요? 취향의 최종 판단 기준이에요. 판단이 불확실할 때 기준 체계에서 작동하는 질문이에요.

일곱 가지 모두에 구체적으로 답할 수 없다면, 저는 원칙을 적용한 것이 아니라 주장한 거예요. 작업을 되돌려 보내요.

실제 예시: 한 표면에 일곱 가지 징후 적용하기

번역 사고 이후 출시한 특정 표면 하나에 이 징후들을 적용해 볼게요. 번역 파이프라인에 작성한 동시 실행 보호 장치예요. 다른 번역 프로세스가 이미 실행 중이면 guide_bootstrap.py나 blog_translate_batch.py를 시작하지 않도록 막는 약 100줄의 Python예요.

1. 사용자는 누구인가요? 2주 뒤 번역 실행을 시작하는 저예요. 그때 저는 6개 로캘을 망가뜨린 정확한 속도 제한 실패 양상을 잊어버렸을 거예요. 그리고 향후 작업 맥락에서 두 스크립트 중 하나를 호출하는 모든 에이전트도 사용자예요.
2. 이 표면은 어떤 관점을 담고 있나요? 동시 번역 실행은 결코 맞는 도구가 아니에요. 이 보호 장치는 다음 호출자가 그것을 기억하지 않아도 되도록 그 판정을 코드에 새겨요.
3. 깨끗하게 유지하기 위해 무엇을 거절하거나 제거했나요? 저는 보호 장치를 경고로 만들기를 거절했어요. --force처럼 짧고 편한 오버라이드 플래그를 주는 것도 거절했어요. 유일한 오버라이드는 환경 변수 I18N_ALLOW_CONCURRENT=1이고, 실수로 입력하기에는 충분히 길어요.
4. 이것은 전체 제품 경험에 어떻게 기여하나요? 번역 파이프라인, D1 작성기, 대체 처리 로직은 각각 올바르게 작동해요. 보호 장치는 이들이 조합되어 조용한 손상을 만드는 전체가 되지 않게 막는 조각이에요.
5. 그것이 탄탄하다는 증거는 무엇인가요? 저는 두 가지 수동 검사로 보호 장치를 검증했어요. 하나는 다른 번역 작업이 없을 때 깨끗하게 반환되는지였어요. 다른 하나는 실제 guide_bootstrap.py 하위 프로세스가 살아 있을 때 0이 아닌 종료가 나는지였어요. 두 검사는 모의 객체가 아니라 실제 스크립트를 대상으로 실행됐어요.
6. 왜 존재할 자격이 있나요? 6개 로캘을 손상시킨 동일한 동시 실행 경쟁 조건은 이 보호 장치가 있는 동안 언어가 섞인 D1 행을 만들 수 없어요. 모든 경우를 막는 장치는 아니에요. 이 원칙이 막 배운 특정 실패 양상을 막는 장치예요.
7. 제 이름을 걸 수 있나요? 네. 하나의 일, 깨끗한 오버라이드 의미, 그리고 미래 작업 맥락이 이 보호 장치가 존재하는 이유를 물려받도록 메모리에 문서화된 이유가 있어요.

이 실제 예시의 핵심은 각 징후에 구체적인 답이 있다는 점이에요. 그 답을 만들 수 없으면 기준은 아직 실행되지 않은 거예요.

실패는 어떻게 보이는지도 대비해 볼게요. 동시 실행 보호 장치를 초안으로 만들었을 때, 3번 징후에 대한 첫 답은 이랬어요. “과하게 만들지 않기로 했어요.” 이 문장은 괜찮게 들리지만 아무 말도 하지 않는 종류의 답이에요. 과하게 만들지 않았다는 말은 제가 검토하고 거절한 구체적인 것을 하나도 말하지 않아요. 그것은 자세이지 거절이 아니에요. 그래서 저는 진짜 답을 쓰도록 스스로 밀어붙였어요. 보호 장치를 경고로 만들지 않았고, 편한 오버라이드 플래그 이름을 거절했고, 프로세스 목록을 볼 수 없을 때 보호 장치가 실패 시 통과시키는 동작도 거절했어요. 이것들은 결정이에요. 첫 버전은 원칙을 연기한 것이었어요.

핵심 요점

창업자와 1인 빌더에게: - 어떤 표면을 존재할 자격이 있다고 부르기 전에 실제 순간의 실제 사용자를 말하세요. 추상적 자격은 쓸모가 없어요. - 출시된 모든 표면에는 눈에 보이는 거절이 하나 이상 있어야 해요. 아무것도 제거하지 않았다면 범위가 잘못된 거예요. - 표면별 강도를 적용하세요. 프로덕션 배포는 초안보다 더 강한 통과 기준이 필요하고, 마케팅 주장은 가장 강한 기준이 필요해요.

제품 리더와 PM에게: - 출시 주기마다 거절과 삭제가 몇 번 있었는지 세어 Steve Test가 실제로 실행되고 있는지 측정하세요. 0이면 이상 신호예요. - 자기 검토 체크리스트에서 “작동한다”와 “존재할 자격이 있다”를 분리하세요. 독립된 축으로 다루세요. - 재구축 예산을 보호하세요. 정직한 시도는 3번이고, 그 뒤에는 상류로 올려야 해요. 완벽주의가 숨기가 되게 두지 말고, 마감 압박이 기준을 죽이게 두지도 마세요.

엔지니어링 리드에게: - 팀이 출시하는 모든 표면에 Jiro 기준과 Steve 기준을 명명하세요. 둘 다 통과해야 해요. - 보이지 않는 디테일에 투자하세요. 정확함과 존재할 자격의 차이는 보통 틈에 있어요. - 기질은 거절하세요. 차분한 거절이 신호예요. 엄격함을 연기하는 것은 실패 양상이에요.

디자이너에게: - 관점은 장식이 아니에요. 제품을 알아볼 수 있게 만드는 장치예요. - 존재할 자격이 있는 표면은 눈에 보이게 무언가를 거절해요. 무엇을 잘라냈는지 말하는 것도 당신의 일에 포함돼요. - 애매할 때 작동하는 기준은 이것이에요. 이 결정에 망설임 없이 자기 이름을 걸 수 있나요?

마무리: 제 이름을 걸 수 있을까요?

제품에서 기준이 되는 질문은 이 작업은 존재할 자격이 있는가?예요. 판단이 불확실할 때 기준이 되는 질문은 이 체계에서 가장 단순한 질문이에요.

망설임 없이 제 이름을 걸 수 있을까요?

답이 예라면 그 작업은 출시 후보예요. 답이 “아직은 아니지만, 정직한 재구축 3번 안에 그렇게 될 수 있다”라면 계속 작업하세요. 답이 아니오이고, 정직한 시도 3번 뒤에도 아니오라면 표면이 아니라 브리프를 다시 만드세요.

저는 매번 이 기준을 실행해요. 코드에, 카피에, 커밋 메시지에, 문서에, 제품 표면에, 그리고 이 글에도요.

이 글은 초안을 시작할 때 필요하다고 생각했던 3개 섹션을 잘라냈어요. Jobs에 대한 긴 전기적 섹션, “우주에 흔적을 남긴다”라는 문구에 대한 입문 설명, 그리고 이 원칙이 추상 개념 대신 실제 사람의 이름을 쓰는 이유에 대한 변론이었어요. 그 어느 것도 제가 쓰고 있던 사용자를 섬기지 않았어요. 그 사용자는 확신이 서지 않는 표면을 출시할지 결정하려는 빌더였어요. 삭제 덕분에 글은 더 작고 더 정직해졌어요. 그리고 이 글을 여는 번역 실패는 수정 외에 하나의 영구 산출물을 남겼어요. 이제 번역 파이프라인에는 다른 번역 작업이 이미 실행 중이면 시작을 거절하는 동시 실행 보호 장치가 있어요. 거절된 작업은 규칙을 바꾸었어요. 원칙은 학습했어요.

Steve는 통과해요. Jiro도 통과해요. 그래서 출시해요.

FAQ

Steve Test란 무엇인가요?

Steve Test는 실제 순간의 실제 사용자를 위해 어떤 작업이 존재할 자격이 있는지 묻는 기준이에요. 이것은 Jiro 품질 철학 옆에 놓여 있어요. Jiro는 정확성, 증거, 경계 사례를 확인하고, Steve는 존재할 자격, 일관성, 거절, 취향을 확인해요.

Steve Test는 Jiro Test와 어떻게 다른가요?

Jiro는 작업이 올바르게 만들어졌는지 물어요. Steve는 올바른 작업이라도 애초에 출시해야 하는지 물어요. 기능은 테스트를 통과하고도 사용자, 제품, 또는 그 표면 뒤의 관점에 실패할 수 있어요.

팀은 언제 Steve Test를 실행해야 하나요?

되돌리기 어려운 표면을 출시하기 전에 실행하세요. 공개 배포, 마케팅 주장, 온보딩 흐름, 가격 페이지, 문서, 사용자 신뢰를 형성할 제품 기능이 여기에 해당해요. 가벼운 작업에는 부드러운 통과 기준을 쓸 수 있지만, 공개 표면에는 엄격한 기준이 필요해요.

이 기준은 무엇을 만들어내야 하나요?

기준은 구체적인 결정을 만들어내야 해요. 출시, 재구축, 삭제, 거절 중 하나예요. 진짜 통과는 사용자, 순간, 관점, 증거, 그리고 전체를 지키기 위해 팀이 제거한 것 하나 이상을 말해요.

Steve Test가 완벽주의가 될 수 있나요?

네. 그래서 이 원칙에는 재구축 상한이 필요해요. 정직한 재구축은 3번이면 충분해요. 그 뒤에는 보통 문제가 브리프, 범위, 팀, 전제 같은 상류에 있어요.

검토 템플릿

이것을 메모장, PR 설명, Notion 페이지, 또는 커밋 메시지 맨 위에 붙여 넣으세요. 간단하지 않은 작업이 끝났다고 선언하기 전에 채우세요. 어떤 행에도 구체적인 답을 넣을 수 없다면 기준은 아직 실행되지 않은 거예요.

Steve Test: 검토 기록

사용자:        [페르소나 유형이 아니라 실제 상황에 놓인 실제 사람]
순간:          [사용자가 작업을 만나는 구체적인 순간]
관점:          [이 표면이 주장하는 것, 그리고 하지 않겠다고 거절하는 것]
거절:          [제가 검토한 뒤 잘라낸 것, 또는 아예 만들지 않기로 한 것]
전체 경험:     [이것이 제품의 인접한 모든 조각과 어떻게 일관되는지]
증거:          [Jiro 축: 검증이 실행됐고, 주장이 뒷받침된다는 구체적 증거]
자격 판정:     [예 / 아니오 / 정의된 재구축 N번 안에 아직 가능]
서명:          [망설임 없이 제 이름을 걸 수 있는가? 아니라면 멈출 것]

이 템플릿의 일은 정확히 하나예요. 테스트하는 사람이 모든 행에 구체적인 답을 만들게 하는 것이에요. 흐릿한 답은 기준을 넘지 못해요. “과하게 만들지 않기로 했어요”는 거절이 아니에요. “편한 오버라이드 플래그와 실패 시 통과시키는 경로를 거절했어요”는 거절이에요. “사용자에게 도움이 됩니다”는 전체 제품 경험에 대한 답이 아니에요. “지난 사고를 일으킨 특정 조합의 틈을 닫습니다”는 답이에요. 어떤 행이 구체성을 거부한다면 작업은 준비되지 않은 거예요. 그 저항이 재구축이 어디로 가야 하는지 알려 주는 기준의 신호예요.

이 템플릿은 이 글의 운영 산출물이에요. 이 페이지의 나머지 전부는 왜 이 행들이 존재하는지에 대한 설명이에요.

참고 문헌