기술 워크숍에서 팀이 가장 빨리 합의하는 것은 사용할 기술이고, 가장 늦게 합의하는 것은 해결할 문제인 경우가 많습니다. 같은 팀 안에서도 “AI 추천 서비스”, “클라우드 대시보드”라는 말은 같지만, 실제 고객과 성공 장면을 각자 다르게 상상합니다. 구현은 시작되지만 API, 화면, 발표는 서로 다른 제품을 향하게 됩니다.
Working Backwards를 적용한 이유는 아이디어를 예쁘게 포장하기 위해서가 아닙니다. 구현 전에 누구의 어떤 장면을 바꿀 것인지, 그리고 데모에서 무엇을 사실로 증명할지를 팀의 공통 계약으로 만들기 위해서였습니다.
네 개의 문서를 하나의 판단 흐름으로 쓴다
워크숍에서는 문서를 많이 만들기보다 서로 다른 질문에 답하는 네 가지 산출물을 연결합니다.
- Today statement — 지금 고객이 어느 장면에서 무엇 때문에 실패하는가
- Press release — 해결 뒤 고객의 하루에서 무엇이 달라지는가
- FAQ — 그 약속을 깨뜨릴 수 있는 제품·기술·운영 가정은 무엇인가
- Demo contract — 제한된 시간 안에 어떤 흐름 하나를 실제로 증명할 것인가
Today statement에는 솔루션 이름을 넣지 않습니다. “AI가 분석해 준다”가 아니라 “야간 운영자가 여러 dashboard를 오가느라 원인 후보를 정리하는 데 40분을 쓴다”처럼 관찰 가능한 장면을 씁니다. 문제와 솔루션을 분리해야 나중에 기술 선택을 바꿔도 고객 문제는 유지됩니다.
Press release는 미래의 홍보문이 아니라 완료 조건입니다. 고객이 누구인지, 어떤 순간에 서비스를 쓰는지, 기존 방식보다 무엇이 달라지는지를 짧게 씁니다. 문장이 모호하면 기능 목록도 계속 늘어납니다.
FAQ는 질문 모음이 아니라 위험 등록부입니다. 데이터가 없으면 어떻게 되는지, 모델이 틀리면 누가 판단하는지, 비용·지연·권한은 어떤 경계를 갖는지 묻습니다. 이 답이 architecture와 backlog의 우선순위를 만듭니다.
Demo contract는 모든 기능을 보여 주는 계획이 아닙니다. 입력 → 핵심 처리 → 고객의 결정이라는 한 흐름이 고객 약속을 증명하도록 범위를 줄입니다.
Listen, Define, Invent, Refine의 전환점을 설계한다
워크숍은 보통 네 단계로 진행하지만, 단계 이름보다 전환 조건이 중요합니다.
Listen에서는 참가자의 아이디어보다 고객이 실제로 겪은 장면을 모읍니다. “불편하다”를 언제, 어디서, 어떤 작업이 지연됐는지로 바꿉니다.
Define에서는 고객을 한 명으로 좁히고, 문제의 빈도·영향·현재 우회 방법을 정리합니다. 사용자, 관리자, 운영자를 동시에 첫 고객으로 두면 한 데모가 세 개의 목적을 떠안게 됩니다.
Invent에서는 기능을 발산하되, 각 기능이 Today statement의 어느 마찰을 줄이는지 표시합니다. 연결되지 않는 기능은 나쁜 아이디어가 아니라 이후 후보로 보류합니다.
Refine에서는 데모와 FAQ를 기준으로 구현 범위를 다시 줄입니다. “이 기능이 없으면 고객 약속을 증명할 수 없는가”에 답하지 못하면 첫 iteration에서 제외합니다.
이 흐름은 선형 체크리스트가 아닙니다. FAQ에서 위험이 드러나면 문제 정의로 돌아가고, 데모가 고객 변화를 보여 주지 못하면 press release를 다시 씁니다. 문서는 진행 보고서가 아니라 서로를 검증하는 장치입니다.
아키텍처는 고객 약속에서 거꾸로 그린다
기술 워크숍에서 architecture diagram은 종종 아는 서비스를 많이 넣는 경쟁이 됩니다. Working Backwards에서는 반대로 데모의 한 흐름에 필요한 책임을 먼저 나눕니다.
예를 들어 “장애 원인 후보와 근거를 운영자에게 보여 준다”는 약속이라면 다음 질문이 component보다 먼저 나옵니다.
- 어떤 signal이 사건을 시작하는가
- 어떤 source가 원인 주장을 뒷받침하는가
- source가 비면 결과에 어떻게 표시되는가
- 사람은 어디서 수정하거나 보류하는가
- 어떤 기록이 다음 incident에 남는가
이 질문에 답한 뒤에야 event intake, storage, analysis, UI, notification 같은 책임을 배치합니다. 각 박스는 고객 약속이나 FAQ의 위험 하나와 연결돼야 합니다. 그렇지 않은 component는 첫 데모의 필수 범위가 아닐 수 있습니다.
퍼실리테이터는 아이디어보다 연결을 검토한다
퍼실리테이터가 정답을 제시하면 팀은 빠르게 움직이지만, 그 답의 조건을 이해하지 못한 채 구현할 수 있습니다. 그래서 피드백은 “좋다/나쁘다”보다 문서 사이의 연결을 확인하는 질문으로 줍니다.
- 이 문제를 겪는 첫 고객은 정확히 누구인가
- 고객이 지금 쓰는 우회 방법은 무엇인가
- 이 기능이 성공하면 어떤 행동이나 시간이 달라지는가
- 데모의 어느 장면이 그 변화를 증명하는가
- FAQ의 어떤 위험이 architecture에 반영됐는가
- 이번 일정에서 의도적으로 만들지 않을 것은 무엇인가
중간 점검도 완성도 평가가 아니라 정렬 확인에 가깝습니다. 화면은 예쁘지만 문제와 연결되지 않거나, architecture는 복잡하지만 데모가 약속을 증명하지 못하면 구현을 더하기 전에 범위를 다시 맞춥니다.
팀마다 진행 속도가 다르므로 모든 팀에 같은 답을 요구하지 않습니다. 대신 같은 질문과 같은 산출물 계약을 사용합니다. 이 방식이면 기술 수준이 다른 팀도 자신들의 결정을 비교하고 설명할 수 있습니다.
워크숍 뒤에는 기능 목록이 아니라 결정 기록이 남아야 한다
좋은 워크숍의 산출물은 발표 자료만이 아닙니다. 첫 고객, 문제 장면, 성공 기준, 핵심 가설, 보류한 기능, 데모 범위, 기술 위험과 다음 실험이 한 흐름으로 남아야 합니다.
팀은 이 기록을 첫 sprint planning에 그대로 사용할 수 있습니다. Today statement는 scope 기준이 되고, FAQ는 risk backlog가 되며, demo contract는 acceptance criteria가 됩니다. 구현 중 새로운 요구가 생겨도 “좋아 보이는가”가 아니라 기존 고객 약속과 어떤 관계인지 판단할 수 있습니다.
Working Backwards는 기술을 늦게 고르는 방법이 아닙니다. 기술을 선택할 이유를 먼저 만드는 방법에 가깝습니다. 이후의 각 사례 글에서는 이 공통 방법을 반복 설명하지 않고, 행사마다 실제로 달랐던 한 가지 운영 문제와 그때의 산출물에 집중합니다.
댓글