모호한 요구사항에서 테스트 가능한 기준으로

스펙은 의견을 테스트로 전환한다

모호한 요구사항("온보딩을 더 좋게 해라", "데이터를 정리해라", "검색 기능을 추가해라")은 완료 시점을 명확히 정의할 수 없기 때문에 전달하거나 검증할 수 없다. 스펙(명세) 은 형용사를 테스트로 대체한다. 누군가 측정할 수 있는 용어로 성공 기준을 명시하고, 솔루션이 반드시 준수해야 하는 제약 조건을 정의한다.

스펙을 실질적인 것으로 만드는 두 가지 요소가 있다:

- 테스트 가능한 성공 기준: 논쟁 없이 통과 또는 실패를 확인할 수 있는 조건. "빠름"은 의견이지만, "초당 200개 요청 시 p95 응답 시간이 400ms 미만"은 테스트다. "더 나은 온보딩"은 의견이지만, "신규 사용자의 80%가 첫 세션에서 3단계까지 완료"는 테스트다.

- 명시적인 제약 조건: 솔루션이 반드시 지켜야 하는 경계: 예산, 마감 기한, 접근할 수 없는 데이터, 변경할 수 없는 시스템, 준수해야 하는 규정. 제약 조건은 장애물이 아니다. 올바른 답의 정의의 절반이다.

유용한 습관입니다. 요청에 포함된 모든 형용어에 대해, 이를 판정할 측정 기준과 이를 제한하는 제약 조건을 기록하세요. 테스트를 작성할 수 없다면, 아직 요청을 충분히 이해하지 못한 것이므로 시작할 수 없습니다.

첫 번째 초안을 생성하는 비용이 저렴할 때, 초안이 좋은지 여부를 알려주는 것은 바로 스펙입니다. 정확한 스펙은 재사용 가능한 판단 기준입니다. 이는 모든 후보 답변을 동일한 방식으로 평가합니다.

독립적이고 검증 가능한 하위 문제

바위를 검증 가능한 돌로 쪼개기

큰 문제는 어느 부분이 잘못되었는지 판단할 수 없기 때문에 평가가 어렵습니다. 분해(Decomposition) 는 각 하위 문제가 자체적으로 검증할 수 있을 만큼 충분히 작도록 문제를 구조화합니다. 좋은 분해는 두 가지 특성을 가집니다.

- 독립성(Independence): 하위 문제들은 가능한 한 겹치지 않아야 하며, 한 부분의 변경이 다른 부분을 은밀하게 깨뜨리지 않도록 해야 합니다. 부분이 독립적일 경우, 병렬로 작업, 테스트, 심지어 자동화할 수 있으며, 실패가 전파되지 않고 국소화됩니다.

- 검증 가능성(Verifiability): 각 하위 문제는 자체적인 성공 테스트를 포함해야 하므로, 전체를 조립하기 전에 해결되었음을 확인할 수 있습니다. 확인할 수 없는 부분은 신뢰할 수 없는 부분입니다.

잘 분해된 문제는 희소한 인간의 판단력을 어디에 집중해야 하는지도 알려줍니다. 대부분의 하위 문제는 일상적이며, 자동화 시스템이나 주니어에게 맡기고 해당 테스트에 대해 확인할 수 있습니다. 하나 또는 두 개는 핵심으로, 불확실성이 높고 결과가 중대하며, 확신에 차서 쉽게 틀릴 수 있는 부분입니다. 이러한 부분이 전문가의 주의를 유지시킵니다.

가짜 분해에 주의하세요: 겉보기에는 분리 가능해 보이지만 숨겨진 의존성을 공유하여 "완성된" 조각들이 작동하는 전체로 조립되지 않는 경우입니다. 분해의 테스트 기준은 각 부분이 검증된 상태로 모두 해결되었을 때, 원래 문제가 실제로 해결되는지 여부입니다.

질문이 답변의 상한선을 설정한다

모호한 질문, 확신에 찬 엉터리 결과

이해관계자, 데이터셋, 또는 자동화 시스템에 질의하든, 질문의 정확성이 답변의 가치 상한선을 결정합니다. 모호한 질문은 크게 실패하지 않습니다. 의도하지 않은 질문에 대해 유창하고, 확신에 차고, 그럴듯한 답변을 반환하며, 그 답변은 마치 완성된 것처럼 보입니다.

모호한 데이터 요청을 생각해 보겠습니다. "우리 최고의 고객 목록을 뽑아줘." 모든 핵심 단어가 정의되지 않았습니다. '최고'의 기준은 무엇입니까: 총 매출, 마진, 재구매율, 성장률, 추천 건수? 기간은 어떻게 됩니까: 전체 기간, 최근 12개월, 이번 분기? 어떤 고객을 포함합니까: 활성 고객만, 이탈 고객 포함, 트라이얼 고객 포함? 데이터셋은 쿼리가 우연히 인코딩한 어떤 버전이든 기꺼이 답변할 것이며, 요청자는 그것이 머릿속에 있던 의도와 같다고 가정하고 행동하게 됩니다.

정확한 질문은 네 가지를 고정시킵니다: 정확한 양 또는 엔티티, 대상 집단, 시간 창, 그리고 동점 처리 기준 또는 임계값. 동일한 원칙은 사람에게도 적용됩니다("최고라고 할 때, 올해 가장 이익이 많은 고객을 의미합니까, 아니면 재계약 가능성이 가장 높은 고객을 의미합니까?") 그리고 자동화 시스템에도 적용되며, 여기서 불완전하게 지정된 프롬프트는 잘못된 질문에 대한 확신에 찬 답변을 생성합니다.

전문적인 기술은 답변이 도착하기 전에 모호함을 알아차리는 것입니다. 왜냐하면 확신에 찬 잘못된 답변은 사후에 발견하는 데 비용이 많이 들기 때문입니다. 질문의 정확성은 사후 수정보다 저렴합니다.

지금 당신의 레버리지가 있는 곳

초안은 저렴하지만, 프레이밍과 판단은 그렇지 않다

실마리를 하나로 묶어보겠습니다. 거의 모든 것의 그럴듯한 첫 번째 버전을 요구 즉시 생성할 수 있을 때, 가치를 지니는 작업은 자동화 시스템이 대신할 수 없는 작업입니다: 어떤 문제를 해결할 가치가 있는지 결정하는 것, "정확함"이 무엇을 의미하는지 명시하는 것, 검증할 수 있도록 문제를 분할하는 것, 질문을 정확하게 하는 것, 그리고 반환된 답변이 실제로 사양을 충족하는지 판단하는 것.

모호한 작업에서 단일 초안을 생성하기 전에 이 프레이밍 체크리스트를 항상 가지고 가세요:

- 문제: 표면적인 증상은 무엇이며, 근본적인 문제는 무엇인가? 잘못된 문제를 해결하는 데 드는 비용은 얼마인가?

- 성공: "완료되고 정확하다"는 것을 검증할 수 있는 기준은 무엇인가? 두 사람이 각 기준이 충족되었는지에 대해 의견이 다를 수 있는가? 만약 그렇다면 기준을 더 명확히 하라.

- 제약 조건: 솔루션이 반드시 준수해야 하는 경계는 무엇인가: 예산, 마감일, 데이터, 시스템, 규칙?

- 범위: 의도적으로 범위에 포함되지 않는 것은 무엇인가?

- 분해: 이 문제는 독립적이고 개별적으로 검증 가능한 하위 문제로 어떻게 나뉘는가? 그 중 어떤 것이 인간의 판단에 있어 핵심인가?

- 질문: 사람, 데이터셋, 또는 시스템에 대한 모든 쿼리에 대해, 지표, 대상 집단, 시간 창, 그리고 동점 처리 규칙이 명확히 고정되어 있는가? 어떤 모호성이 확신에 찬 잘못된 답변을 반환할 수 있는가?

- 판단: 답변이 도착했을 때, 그것이 단순히 유창한 것이 아니라 정확하다는 것을 알려주는 테스트는 무엇인가?

이 시대의 전문가는 초안을 가장 빠르게 생산하는 사람이 아니다. 문제를 그렇게 잘 정의하여 좋은 답변은 검증 가능하게 하고, 잘못된 답변은 눈에 띄게 만드는 사람이다.

당신이 앞으로 가져갈 것

기억해 둘 두 문장

증상과 문제를 분리하고, 명시적인 제약 조건을 갖춘 검증 가능한 성공 기준을 작성하며, 문제를 독립적으로 검증할 수 있는 부분으로 분해하고, 자신감 있는 오답이 반환되지 않도록 질문을 날카롭게 다듬는 연습을 했습니다. 이 네 가지 동작은 하나의 기술, 즉 프레이밍(Framing)입니다.

잘못된 문제를 잘 해결하는 것은 지식 노동에서 가장 비싼 실수이며, 이는 성공처럼 보이기 때문입니다. 그리고 질문의 정밀도는 사람, 데이터셋, 또는 자동화 시스템에서 오는 모든 답변의 가치 상한선을 결정합니다.

첫 번째 초안을 만드는 것은 이제 저렴해졌고, 점점 더 저렴해지고 있습니다. 전문성의 레버리지가 존재하는 곳은 문제를 프레이밍하고, 스펙을 작성하며, 결과를 판단하는 데 있습니다. 체크리스트를 지니고 다니세요. 더 날카로운 질문을 하세요. 시작하기 전에 '완료'를 정의하세요.