2024년 6월 22~23일 AWS 서울 오피스에서 수도권 ICT 이노베이션스퀘어 클라우드 직무 마스터리 챌린지를 진행했습니다. 참여자는 40명이었고, 프로젝트 경험과 직무 준비를 연결해야 하는 이틀짜리 프로그램이었습니다.
이 사례의 핵심 문제는 아이디어 부족이 아니었습니다. 팀이 사용자, 관리자, 기업, 취업 준비생처럼 여러 대상을 한 번에 고객으로 두면서 프로젝트가 계속 커지는 것이었습니다. 그래서 모든 팀에 같은 기능을 제안하는 대신 첫 고객 한 명을 선택하는 일을 공통 과제로 뒀습니다.
넓은 주제를 한 장면으로 바꾸기
팀이 처음 가져온 문장은 “중소기업을 위한 클라우드 서비스”, “구직자를 위한 AI 플랫폼”처럼 넓었습니다. 이 문장으로는 어느 기능이 핵심인지 결정하기 어렵습니다. 고객도 문제도 복수형이기 때문입니다.
워크숍에서는 먼저 가장 자주 관찰한 고객 한 명을 골랐습니다. 그 사람이 어느 순간에, 어떤 정보를 갖고, 무엇을 결정하지 못하는지를 Today statement로 바꿨습니다.
누구나 편리하게 쓰는 플랫폼
→ 첫 클라우드 배포를 맡은 주니어 개발자가
장애 직후 비용과 상태를 한 화면에서 설명하지 못한다이렇게 바꾸면 팀의 대화가 “무슨 기능이 멋진가”에서 “이 장면을 바꾸려면 어떤 정보가 필요한가”로 이동합니다.
여러 고객을 보류하는 결정도 산출물이다
첫 고객을 고르는 일은 다른 사용자를 포기하는 선언이 아닙니다. 이번 iteration에서 누구의 문제를 먼저 검증할지 정하는 일입니다. 관리자용 통계나 기업용 권한 기능이 중요해도, 첫 데모가 구직자의 선택을 검증한다면 별도 backlog로 이동했습니다.
보류 목록을 남긴 이유는 범위를 줄이는 과정이 아이디어 삭제로 느껴지지 않게 하기 위해서였습니다. 각 항목에는 “어떤 고객 조건이 확인되면 다시 검토할 것인가”를 함께 적었습니다. 구현하지 않은 기능도 판단 기록이 됩니다.
이 기준은 기술 선택에도 영향을 줬습니다. 첫 고객의 한 행동을 증명하는 데 필요하지 않은 실시간 처리, 복잡한 권한 모델, 여러 cloud 연동은 초기 architecture에서 제외할 수 있었습니다. 기술을 덜 쓰는 것이 목적이 아니라, 각 component가 고객 약속에 답하도록 만드는 것이 목적이었습니다.
데모는 약속 하나를 검증했다
데모 범위는 화면 수가 아니라 고객 행동의 변화로 정했습니다. 입력이 들어오고, 핵심 처리가 일어나고, 고객이 이전보다 빠르거나 더 정확하게 한 결정을 내리는 흐름 하나면 충분했습니다.
중간 점검에서는 다음 세 문장이 연결되는지 확인했습니다.
- 고객은 지금 무엇 때문에 실패한다.
- 이 서비스는 어떤 정보를 어떤 순간에 제공한다.
- 데모에서는 고객이 어떤 결정을 다르게 내리는지 보여 준다.
세 문장 사이가 끊기면 기능을 더 구현하지 않고 문제나 데모를 다시 썼습니다. 발표 자료 역시 architecture 설명으로 시작하지 않고 고객 장면 → 약속 → 검증한 흐름 → 남은 위험 순서로 구성했습니다.
프로젝트 설명을 기술 목록에서 판단 기록으로 바꾸기
부트캠프 프로젝트는 이력서와 포트폴리오로 이어집니다. 이때 사용한 서비스와 구현 기능만 나열하면 팀이 어떤 불확실성을 다뤘는지 드러나지 않습니다.
워크숍 뒤에 남긴 문서는 다음 질문에 답하도록 했습니다.
- 왜 이 고객을 먼저 선택했는가
- 어떤 관찰로 문제를 좁혔는가
- 무엇을 첫 데모에서 제외했고 왜 제외했는가
- 어떤 기술 가정이 아직 검증되지 않았는가
- 다음 iteration에서 어떤 지표를 볼 것인가
이 사례에서 Working Backwards가 한 일은 모든 팀을 같은 서비스로 만드는 것이 아니었습니다. 서로 다른 프로젝트가 첫 고객, 첫 약속, 첫 검증이라는 같은 구조로 자신의 결정을 설명하게 만든 일이었습니다.
댓글