• 모든 RAXXO 도구는 제가 완료라고 부르기 전에 매번 다른 방식이 아닌, 동일한 4단계 체크리스트를 거칩니다.

• 1단계는 '콜드 오픈 (cold-open)' 테스트로, 도구를 어떻게 만들었는지에 대한 기억이 전혀 없는 상태에서 도구를 열어보는 것입니다.

• 3단계는 '망가뜨리기 (break-it)' 단계로, 목표는 성공이 아니라 실패입니다.

• 다섯 가지 서로 다른 제품이 서로 다른 품질 수준으로 느껴지지 않게 유지해 주는 것은 영리함이 아니라 일관성입니다.

"작동한다"는 기준이 결코 충분하지 않았던 이유

오랫동안 제가 출시하는 모든 것에 있어 "작동한다"는 것은 결승선이었습니다. 기능을 만들고, 한 번 클릭해 보고, 원래 의도한 대로 작동하는 것을 확인한 뒤 완료라고 불렀습니다. 그 당시에는 그 기준이 합리적으로 느껴졌습니다. 왜냐하면 그 순간에는 사실이었기 때문입니다. 도구는 제가 우연히 테스트한 그 하나의 경로에서, 그리고 제 컴퓨터가 우연히 처해 있던 그 하나의 상태에서 실제로 작동했습니다.

문제는 나중에, 항상 나중에 나타났습니다. 바로 "나에게는 작동한다"와 "작동한다" 사이의 간극에서 말이죠. Git Dojo를 만들면서 원리부터 다시 배우는 git에 대해 글을 썼을 때, 저는 이 교훈을 가장 혹독하게 배웠습니다. 제가 순서대로 클릭했을 때는 완벽하게 작동했던 레슨이, 누군가 연습 문제 2번을 마치기도 전에 연습 문제 4번으로 건너뛰는 순간 무너졌습니다. 제가 테스트한 것은 사람들이 취할 것이라고 예상했던 경로였을 뿐, 실제로 그들이 취할 경로가 아니었기 때문입니다.

그 간극은 일반적인 의미의 테스트 문제가 아닙니다. 그것은 관점의 문제입니다. 도구를 만든 사람은 그것을 처음 접하는 사람이 보는 방식으로 볼 수 없습니다. 제작자는 이미 모든 버튼이 어디로 연결되는지 알고 있기 때문입니다. 저에게 당연하게 느껴지는 모든 가정은 바로 그것이 저의 것이기 때문에 보이지 않습니다. 저는 제 자신의 판단이 제 사각지대를 포착하는 것에 의존하지 않는 무언가가 필요했습니다. 한 번 당신을 확실히 속이는 사각지대는 반드시 다시 당신을 속일 것이기 때문입니다.

그래서 저는 "작동한다"는 상태를 결승선으로 취급하는 것을 멈추고, 실제 점검을 위한 출발 신호로 취급하기 시작했습니다. 도구가 얼마나 작게 느껴지든, 혹은 제가 얼마나 자신만만하게 임하든 상관없이 매번 동일한 점검을 수행합니다. 5분짜리 위젯과 몇 주가 걸리는 제품에 대해 똑같은 4단계 과정을 실행하는 것이 사소한 작업에는 과하다고 들릴 수도 있습니다. 하지만 그렇지 않습니다. 사소한 작업이야말로 단계를 건너뛰는 것이 가장 안전하다고 느껴지면서도 실제로는 가장 위험한 지점입니다. 왜냐하면 너무 단순해 보여서 재확인이 필요 없을 것 같은 대상은 아무도 다시 확인하지 않기 때문입니다.

매번 순서대로 진행하는 4단계 점검 (The Four Passes)

첫 번째 단계는 콜드 오픈 테스트 (cold-open test)입니다. 저는 모든 것을 닫고, 실제로 가능한 한 머릿속을 비운 뒤, 마치 이 도구를 한 번도 본 적이 없는 것처럼, 그리고 이를 만드는 동안 내렸던 결정들에 대한 기억이 전혀 없는 상태에서 도구를 엽니다. 제가 자랑스러워하는 부분으로 바로 건너뛰지 않습니다. 다음에 무엇을 기대해야 할지에 대한 심리적 메모도 하지 않습니다. 프로젝트 전체에 대한 완전한 맥락을 가진 저에게조차 무언가가 혼란스럽다면, 맥락이 전혀 없는 사람에게는 훨씬 더 혼란스러울 것입니다. 이 단계 하나만으로도 다른 어떤 단계보다 더 많은 실제 문제들을 잡아냈습니다. 왜냐하면 이 단계가 낯선 사람의 첫 5초를 실제로 시뮬레이션하는 유일한 단계이기 때문입니다.

두 번째 단계는 엣지 입력 점검 (edge-input pass)입니다. 저는 아무도 의도적으로 계획하지 않는 입력값들을 도구에 주입합니다. 빈 필드, 터무니없이 긴 텍스트, 특수 문자, 흐름 중간에 누른 뒤로 가기 버튼, 최악의 순간에 새로고침된 페이지 등이 그것입니다. 대부분의 소프트웨어는 해피 패스 (happy path), 즉 개발자가 예상하는 입력값을 대상으로 구축되고 테스트됩니다. 개발자가 작업하는 동안 자연스럽게 도달하게 되는 입력값이기 때문입니다. 실제 사용은 해피 패스에 머물지 않으며, 이 둘 사이의 간극이야말로 진정으로 당혹스러운 버그들이 거주하는 곳입니다.

세 번째 단계는 제가 실제로 가장 즐기는 단계인 '망가뜨리기 (break-it)' 단계입니다. 여기서의 명시적인 목표는 성공이 아니라 실패입니다. 저는 도구가 무언가 잘못된 동작을 하도록 적극적으로 시도하며, 성공할 때마다 이를 진전이라고 간주합니다. 왜냐하면 제가 찾아낸 모든 파괴 방법은 실제 사용자가 직접 찾아내기 전에 미리 발견할 수 있는 방법이기 때문입니다. 이 단계는 앞선 두 단계와는 완전히 다른 사고방식으로 진행됩니다. 첫 번째와 두 번째 단계가 도구를 정상적으로 사용하면서 진행 과정에서 무엇이 잘못되는지 관찰하는 것이라면, 세 번째 단계는 의도적으로 틈새를 찾아내기 위해 목적을 가진 적대적 (adversarial) 접근 방식입니다.

네 번째 단계는 '평이한 언어 (plain-language)' 단계로, 저는 그동안 그 대가를 인지하지 못한 채 수년간 이 단계를 건너뛰어 왔습니다. 저는 도구가 사용자에게 보여주는 모든 텍스트를 소리 내어 읽으며, 각 문장에 대해 간단한 질문을 던집니다. "이 프로젝트에 대해 저와 대화해 본 적이 없는 사람에게도 이 말이 이해가 될까?" 하는 질문입니다. 인터페이스에는 내부적인 약어 (internal shorthand)가 끊임없이 스며듭니다. 몇 주 전 기획 회의에서는 말이 되었던 라벨이, 그 맥락 없이는 아무런 의미도 갖지 못하게 되는 식입니다. 이 단계는 논리가 아닌 단어를 잡아내며, 도구가 실제로 완성되었다고 느껴지게 만드는 데에는 단어가 논리만큼이나 중요하다는 사실을 깨닫게 해줍니다.

재능만으로는 얻을 수 없는 일관성의 가치

제가 실제로 내면화하는 데 가장 오래 걸렸던 부분은 바로 이것입니다. 이 네 단계의 가치는 개별 단계가 얼마나 영리한지에 있는 것이 아닙니다. 그 어떤 단계도 특별한 기술을 요구하지 않습니다. 콜드 오픈 테스트 (cold-open test)는 정교한 기술이 아니라, 출시 결정 이후가 아닌 적절한 시점에 적용되는 규율 (discipline)일 뿐입니다. 가치는 도구가 어떻게 느껴지든 상관없이, 매번 동일한 네 단계를 동일한 순서로 실행하는 데에 온전히 존재합니다.

그러한 일관성이 없다면, 품질 검사 (quality checking)는 조용히 기분에 좌우되는 작업으로 변질됩니다. 무언가에 대해 자신감이 드는 날에는, 자신감이 실제 증거가 아님에도 불구하고 마치 증거인 것처럼 느껴지기 때문에 곧장 빠른 클릭 테스트만 거치고 '이 정도면 충분하다'며 넘어가 버릴 것입니다. 반대로 불확실함을 느끼는 날에는 훨씬 더 철저하게 테스트할 것이며, 이는 책임감 있게 들릴지 모르나 실제 문제는 다음과 같습니다. 도구가 받는 검토의 양은 그날 아침 나의 기분이 어떠한가가 아니라, 도구 그 자체에 따라 결정되어야 합니다. 고정된 프로세스는 방정식에서 나의 기분을 완전히 제거하며, 그것이 바로 프로세스를 갖는 핵심적인 이유입니다.

또한 이것이, 1인 스튜디오에서 만든 다섯 개의 서로 다른 제품이 다섯 개의 개별적인 실험이 아니라 마치 하나의 스튜디오 소속인 것처럼 느껴지는 실제 이유라고 생각합니다. Git Dojo, Statusline Builder, OhNine, 그리고 제가 출시한 다른 모든 것들은 서로 다른 사람들을 위해 서로 다른 문제를 해결하는 서로 다른 도구들이며, 서로 다른 시기에 서로 다른 수준의 자신감을 가지고 만들어졌습니다. 이들이 공유하는 것은 시각적 스타일이나 공유된 코드베이스 (codebase)가 아닙니다. 그것은 제가 완료라고 부르기 전에 모든 제품이 정확히 동일한 네 가지 체크를 통과했다는 점입니다. 이는 도구들 자체는 공통점이 없을지라도, 그 모든 것들의 밑바닥(floor)은 동일하다는 것을 의미합니다.

저는 혼자서 무언가를 만드는 거의 모든 과정에서 일관성 (consistency)이 영리함 (cleverness)에 비해 과소평가되어 있다고 믿게 되었습니다. 영리한 일회성 검사는 제가 그것을 실행할 생각을 하는 날에는 더 많은 것을 잡아낼 수도 있습니다. 하지만 지루하고, 반복적이며, 화려하지 않은 4단계 루틴은 제품을 출시하는 1년 내내 더 많은 것을 잡아냅니다. 왜냐하면 그것은 매번 제가 새로운 생각을 해야 하는 것에 의존하지 않기 때문입니다. 그것은 실제로 실행하는 것 외에는 아무것에도 의존하지 않으며, 이는 신뢰성 있게 통과하기 훨씬 더 낮은 문턱입니다.

프로세스가 여전히 실패하는 지점, 그리고 제가 대처하는 방법

이 방식의 한계에 대해 솔직해지고 싶습니다. 4단계 루틴이 완벽한 보증 수표는 아니며, 이를 보증처럼 취급하는 것 자체가 또 다른 실수가 될 수 있기 때문입니다. 콜드 오픈 테스트 (cold-open test)는 동일한 도구에 반복해서 실행할수록 그 효과가 약해집니다. 진정한 제로 컨텍스트 (zero-context)는 단 한 번만 가능하기 때문입니다. 동일한 기능을 세 번째 또는 네 번째 라운드에서 테스트할 때, 저는 더 이상 완전히 백지 상태로 접근하는 것이 아니라, 기억이 전혀 없는 상태가 아닌 '희미해진 기억'을 가진 채 접근하게 됩니다. 그리고 희미해진 기억조차도 제가 무엇을 주목하고 무엇을 지나칠지를 여전히 결정합니다.

제가 사용하는 해결책은 완벽하지는 않지만 도움이 됩니다. 일정이 허락하는 한, 빌드 (building)와 테스트 (testing) 사이에 실제 시간이 흐르도록 두는 것입니다. 가능하다면 하루 정도, 여의치 않다면 몇 시간이라도 간격을 둡니다. 노력하는 것보다 물리적인 거리감을 두는 것이 진정으로 새로운 시각을 확보하는 데 더 효과적입니다. 방금 무엇을 했는지 잊으려고 아무리 의식적으로 노력하더라도, 빌드 직후에 테스트하는 것은 여전히 컨텍스트 (context)가 따뜻한 상태에서 테스트하는 것이며, 따뜻한 컨텍스트야말로 콜드 오픈 단계에서 제거하려고 노력하는 바로 그 요소입니다.

또 다른 솔직한 한계는, 한 사람이 네 번 수행하는 것은 결국 한 사람의 판단을 네 번 반복하는 것일 뿐, 네 명의 서로 다른 사람이 각 한 번씩 판단하는 것이 아니라는 점입니다. 저는 실제 팀이 하는 것처럼 저의 사각지대를 확인해 줄 제2의 시각을 가지고 있지 않으며, 1인 프로세스가 그 간극을 완전히 메울 수 있는 것처럼 가장하지도 않을 것입니다. 이 프로세스가 하는 역할은, 비록 하나의 관점과 여러 관점 사이의 간극을 메울 수는 없을지라도, 혼자서 실제로 메울 수 있는 간극, 즉 '부주의함'과 '주의 깊음' 사이의 간극을 메우는 것입니다. 프로세스가 할 수 없는 것이 무엇인지 정확히 아는 것은 그것이 할 수 있는 것을 아는 것만큼이나 유용합니다. 왜냐하면 이는 도구가 기술적으로 테스트를 통과한 후에도, 그 도구에 대해 어디까지 겸손함을 유지해야 하는지를 알려주기 때문입니다.

결론 (Bottom Line)

4단계(Four passes), 콜드 오픈(cold-open), 엣지 입력(edge-input), 망가뜨려 보기(break-it), 쉬운 언어(plain-language)를 제가 출시하는 모든 것에 예외 없이, 아주 사소한 것이라도 반드시 이 순서대로 실행합니다. 이 네 가지 중 어느 하나도 개별적으로는 영리하지 않습니다. 이 방식이 가치를 갖는 이유는, 제가 얼마나 자신감을 느끼며 시작하든 상관없이 모든 도구에 대해 매번 실행하기 때문입니다. 왜냐하면 자신감은 무언가가 준비되었다는 실제적인 증거가 결코 아니었기 때문입니다.

진정한 변화는 새로운 테스트 기법을 배우는 것이 아니었습니다. 그것은 "작동한다"라는 말이 도구 자체에 대한 판결이 아니라, 도구를 통과하는 하나의 경로에 대한 설명일 뿐이라는 점을 받아들이는 것이었습니다. 그리고 그 두 가지 사이의 간극이야말로 제가 만든 무언가에 대해 낯선 이가 처음으로 겪게 되는 실제 경험이 어긋나는 바로 그 지점입니다. 지루하고 반복적인 프로세스는 막판의 번뜩이는 영리함보다 그 간극을 훨씬 더 효과적으로 메워주며, 이것이 바로 제가 몇 년 전보다 지금 제가 출시하는 것들을 더 신뢰하는 이유입니다.