빠른 실행보다 판정이 더 중요하다

요즘 일하면서 가장 신경 쓰는 게 하나 있어요. 나에게 할당된 문제를 주어진 대로 구현하지 않는 거예요. 문제를 스스로 재정의해보고, 실측해보고, 진행할지, 폐기할지, 아니면 다른 대안으로 풀지 판정한 다음에 움직이는 것. 저는 이걸 검증 노트라는 습관으로 만들고 있어요.

왜 지금 이게 중요하다고 생각하냐면

방향만 제대로 잡아주면 나 대신 엄청 빠르게, 성실하게, 지치지도 않고 일해주는 에이전트가 사실상 무한으로 있는 시대예요. 구현 속도는 더 이상 병목이 아니에요. 그런데 이 말을 뒤집으면 무서운 얘기가 돼요. 방향이 틀렸을 때 예전에는 내 며칠을 버리는 정도였다면, 이제는 잘못된 방향으로도 엄청 빠르게 달려요. 잘못된 문제를 그 어느 때보다 빠르고 성실하게 풀게 되는 거죠.

그래서 남는 게 뭘까 생각해보면, 나만의 제품 감각과 판단 감각이에요. 무엇을 만들지, 무엇을 만들지 않을지 가르는 감각이요. 이런 시대일수록 이 능력이 더 중요해진다는 생각을 요즘 다시 하게 돼요.

계기가 된 티켓 하나

사내 개밥먹기(dogfooding)에서 나온 의견이 티켓으로 할당됐어요. 우리 광고 플랫폼에는 리드 수집 폼(광고를 본 고객이 연락처를 남기는 폼)의 응답을 구글 스프레드시트로 자동 연동하는 기능이 있는데, 계정 소유자만 연동할 수 있거든요. 운영자 권한도 연동할 수 있게 해주면 좋겠다는 제안이었어요.

부끄러운 고백을 하나 하면, 이 티켓에서 저는 습관대로 코드부터 열었어요. 권한 게이트를 찾고, 구현하고, 푸시하기 직전에야 제안한 분들을 찾아가 물었어요. "정확히 어떤 상황에서 막히셨어요?"

대화를 나눠보니 그림이 달랐어요. 반복해서 겪은 고통이 아니라 "운영자는 왜 안 되지?" 수준의 일회성 아이디어였어요. 관련 CS도 들어온 적이 없었고요. 오히려 운영자마다 각자 연동하면 광고주 하나에 관리할 시트가 여러 개로 쪼개지는 새 문제가 생겨요. 저는 진행하지 않는 이유를 정리해 wontfix로 닫았고, 만들어둔 브랜치는 푸시하지 않고 폐기했어요.

닫고 나서 곱씹어보니, 취소 판정의 근거 중에 구현이 필요한 건 하나도 없었어요. 필요했던 건 질문 하나와 CS 검색 한 번. 판단력이 없었던 게 아니라 판단이 구현 뒤에 온 거예요. 이 순서를 뒤집으려고 쓰기 시작한 게 검증 노트예요.

검증 노트: 구현 전에 쓰는 네 줄

티켓을 받으면 In Progress로 옮기기 전에 첫 코멘트로 이걸 써요. 단, 문제의 존재가 이미 증명된 인입(장애, 재현 로그가 있는 버그)은 1번과 4번만 써요.

문제 재정의 — 남이 정의해준 문제를 그대로 받아들이지 않고, 당사자에게 경험과 의도를 확인하고 그것에 기반해서 내 언어로 다시 써요. 다시 쓴 진술에는 주체(누가), 장면(언제), 고통(무엇이 곤란한지)이 담겨야 해요. 시스템이 그렇게 동작한다는 사실에서 멈추면 아직 재정의가 아니에요.
기준선 선언 — 실측하기 전에 먼저 적어요. Volume(규모)과 Impact(심각도) 관점에서 어느 수준이 되어야 진행할 만한지, 승격과 기각을 가르는 수치 기준을요. 숫자를 본 뒤에 기준을 정하면 직감이 기준을 자기 편한 쪽으로 재해석하기 쉬워서, 이 순서만은 지키려고 해요.
실측 — 정했던 기준선 안에 실제 숫자가 들어오는지 실제 데이터로 확인해요.
판정과 근거 — 진행, 폐기, 대안 셋 중 하나로 판정하고 근거를 남겨요. 진행이면 무엇이 얼마나 변하면 성공인지 지표를, 폐기면 "언제 다시 볼지" 재검토 트리거를, 대안이면 방향 한 줄을 함께 적어요. root cause를 파고 해법을 설계하는 건 진행 판정이 난 다음, 스펙의 일이에요.

실제 예시: 계기가 된 티켓의 검증 노트

계기가 된 그 티켓을 이 틀로 다시 쓰면 이렇게 돼요. 수치는 설명을 위해 각색한 값이에요.

문제 재정의: 원래 요청은 "운영자 권한도 시트를 연동할 수 있게 해달라"(해법 형태). 당사자에게 경험을 확인해보니, 여러 명이 한 계정에서 리드폼 광고를 운영하는데 시트 연동은 소유자만 할 수 있어 리드를 확인하려면 매번 소유자를 거쳐야 했다는 것. 이를 문제로 다시 쓰면 — "여러 명이 함께 운영하는 광고 계정에서 운영자의 리드 데이터 접근이 소유자 한 명에게 종속되어 있어, 운영자는 리드를 확인할 때마다 소유자에게 요청해야 한다."
기준선: 이 문제에 노출된 집단은 "운영자를 두고 시트 연동을 쓰는 광고주". 리드폼 광고주 중 운영자를 둔 계정이 30% 이상이거나, 운영자도 시트를 연동하고 싶다는 CS가 월 5건 이상이면 진행. 둘 다 미달이면 폐기.
실측: 당사자 확인 결과 반복 고통이 아니라 일회성 아이디어. 리드폼 광고주 중 운영자를 둔 계정은 약 8%, 그중 시트 연동까지 쓰는 계정은 약 3%. 관련 CS 0건. 수용 시 비용은 시트 파편화와 토큰 관리 복잡도 증가.
판정: 폐기(wontfix). 노출 집단이 작고(8%·3%) 자발적 호소도 없어(0건) 기준선 미달. 문제는 성립하나 수용 시 생기는 새 비용이 더 큼. 근거를 티켓에 남기고 브랜치 폐기. 재검토 트리거는 동일 요청 CS 재인입.

정리

검증 노트를 쓰는 데 걸리는 시간은 길어야 반나절이에요. 그 반나절이 막아주는 건 잘못된 방향의 구현 전체고요.

구현은 이제 에이전트가 대신해줄 수 있어요. 그런데 문제를 다시 정의하고, 기준을 선언하고, 판정하는 일은 대신해달라고 할수록 내 감각이 늘지 않는 영역이에요. 판단 감각은 타고나는 게 아니라 판정을 기록하고 틀린 걸 확인하는 반복에서 온다고 믿어요. 그래서 요즘은 In Progress 버튼보다 노트를 먼저 열어요.