킥오프
Kickoff
관행
프로젝트를 시작할 때 목표와 범위와 역할을 한자리에서 맞춰 두는 회의로, 이후 몇 주간의 되묻기를 줄이려고 엽니다.
등장 배경
프로젝트는 대개 조용히 시작됩니다. 누군가 문서를 하나 쓰고, 개발자 두 명이 배정되고, 디자이너가 시안을 열면 그게 시작입니다. 모인 적이 없으니 각자 머릿속에 다른 그림이 하나씩 들어 있고, 그림이 다르다는 사실은 한참 뒤에야 드러납니다.
드러나는 자리는 보통 3주쯤 지난 첫 리뷰입니다. 페이지덱이 기업 고객용 권한 관리를 만들 때가 그랬습니다. 태오는 관리자가 직접 권한을 고치는 화면으로 알고 만들고 있었고, 수아는 고객사 담당자가 요청하면 지원팀이 대신 바꿔 주는 흐름을 팔고 있었습니다. 둘 다 처음 문서를 읽고 각자 합리적으로 해석한 결과였습니다. 어느 쪽도 틀리지 않았는데 3주가 사라졌습니다.
같은 자리에서 또 하나가 걸립니다. "이거 누가 정해요" 입니다. 결정할 사람이 정해져 있지 않으면 질문이 올라올 때마다 누구에게 물어야 하는지부터 찾아야 하고, 그러는 동안 작업은 멈춥니다. 문서에 코멘트가 스무 개 달린 채 두 주가 지나가는 일이 여기서 나옵니다.
킥오프는 이 두 가지를 시작 전에 한 번에 끝내자는 자리입니다. 뒤로 미룬 합의는 사라지지 않고 이자를 붙여 돌아옵니다. 시작할 때 30분이면 끝날 이야기가, 3주 뒤에는 이미 만든 것을 되돌리는 일까지 끼고 며칠짜리가 됩니다.
진행 순서
안건은 여섯 가지를 순서대로 밟습니다. 모두 "나중에 물으면 늦는 것" 들이고, 순서는 앞의 답이 뒤의 답을 좁히도록 짜여 있습니다.
- 왜 하는지 — 어떤 문제를 풀려고 하는지, 지금 해야 하는 이유가 무엇인지를 먼저 맞춥니다. 이게 흐리면 뒤의 모든 결정에 기준이 없습니다.
- 무엇을 만드는지 — 범위를 정합니다. 만들 것보다 중요한 것이 안 만들 것이라, "이번에는 권한 화면까지만 하고 감사 로그는 다음" 처럼 밖에 두는 것을 말로 못 박습니다. 이 줄이 나중에 스코프 크리프를 막는 근거가 됩니다. 합의 없이 범위가 슬금슬금 늘어나는 현상인데, 무엇이 밖인지 적어 두지 않으면 늘어난 것을 알아채지도 못합니다.
- 무엇을 성공으로 보는지 — 끝났다고 말할 조건을 숫자나 상태로 적습니다. "권한 변경 문의가 주 30건에서 5건 아래로" 같은 식입니다.
- 누가 무엇을 맡는지 — 실행할 사람과 결정할 사람을 따로 적습니다. 여기서 RACI를 꺼내는 팀이 많습니다. 실행·책임·자문·통보로 관여 방식을 나눈 표인데, 항목마다 결정권자를 한 명으로 못 박는 데 쓰입니다.
- 언제까지 무엇이 나오는지 — 최종 날짜 하나만 두지 않고 중간 확인 지점을 둡니다. 마일스톤이 그 지점이고, 여기서 무엇이 보여야 하는지를 같이 적습니다.
- 무엇이 아직 모르는 채인지 — 미결 질문과 위험을 적고 각각 누가 언제까지 답을 가져올지 붙입니다. 이 목록이 비어 있는 킥오프는 대개 이야기를 덜 한 것입니다.
끝나면 이 여섯 가지를 문서로 남기고 참석하지 않은 사람에게도 보냅니다. 회의는 사라지고 문서만 남습니다. 한 달 뒤 합류한 사람이 그 문서 하나로 따라잡을 수 있으면 잘 쓴 것입니다.
참여자와 시점
부르는 사람은 두 부류입니다. 실제로 손을 움직일 사람 전원과, 결정에 영향을 주거나 결과를 받는 이해관계자 중 꼭 필요한 사람입니다. 개발자를 대표 한 명만 부르고 나머지는 나중에 전달받게 하면, 전달 과정에서 빠진 맥락이 그대로 다른 해석이 됩니다.
인원은 여덟 명 안팎이 한계입니다. 열다섯 명이 들어오면 말하지 않는 사람이 절반을 넘고, 말하지 않은 사람은 합의한 것이 아니라 듣기만 한 것입니다. 관련은 있지만 결정에 필요하지 않은 사람은 문서를 받는 쪽으로 돌립니다.
시점은 두 조건이 맞을 때입니다. 무엇을 만들지가 문서로 한 번 정리됐고, 아직 아무도 만들기 시작하지 않은 때입니다. 너무 이르면 정할 것이 없어 잡담이 되고, 늦으면 이미 만든 것 위에서 회의하게 됩니다. 요구사항 문서인 PRD의 초안이 돌기 시작한 시점이 대체로 맞습니다.
회의 전에 그 문서를 미리 보내고 읽고 들어오게 합니다. 읽지 않고 모이면 앞의 30분이 문서 낭독으로 지나가고, 정작 맞춰야 할 이견은 시간이 없어 다음으로 밀립니다. 읽고 왔는지 확인하려고 문서 맨 아래에 읽은 사람 이름을 적게 해 두는 팀도 있습니다.
실무 용례
"다음 주 화요일에 킥오프 잡을게요. PRD 미리 읽고 와 주세요."
정해진 문서를 놓고 이견만 다루겠다는 뜻입니다.
"그건 킥오프에서 범위 밖으로 정한 항목입니다."
새로 들어온 요구를 합의된 기록으로 되돌리는 말입니다.
"킥오프 없이 시작해서 지금 누가 결정하는지 아무도 모릅니다."
역할을 맞추지 않아 결정이 멈춰 있다는 뜻입니다.
페이지덱의 킥오프는 한 시간을 넘기지 않습니다. 지현이 안건 여섯 줄을 미리 적어 보내고, 자리에서는 이견이 있는 항목만 멈춰서 이야기합니다. 권한 관리 건에서는 4번 항목에서 20분이 걸렸습니다. 고객사 요청을 지원팀이 대신 처리할지 말지가 갈렸고, 규원이 그 자리에서 1단계는 관리자 직접 변경만 한다고 정했습니다.
정하지 못한 것은 정하지 못한 채로 적습니다. 그날 미결로 남은 항목은 감사 로그의 보관 기간이었고, 수아가 이틀 안에 고객사 계약서를 확인해 오기로 했습니다. 킥오프의 성과는 모든 것을 정하는 게 아니라 정하지 못한 것에 이름과 날짜를 붙이는 쪽에 가깝습니다.
흔한 오해
킥오프를 형식적인 시작 행사로 여기는 경우가 많습니다. 실제로 많은 킥오프가 발표 한 번과 박수로 끝나니 그렇게 보일 만합니다. 하지만 이 자리의 산출물은 분위기가 아니라 결정입니다. 범위 밖 목록, 결정권자 이름, 미결 질문과 마감이 문서에 남지 않았다면 모였어도 한 게 없습니다. 그렇게 끝난 프로젝트는 3주 뒤에 같은 회의를 다시 열고, 그때는 이미 만든 것을 되돌리는 비용이 얹힙니다.
반대쪽 오해는 킥오프에서 모든 것을 확정해야 한다는 생각입니다. 회의 한 번에 다 정하려 들면 세 시간을 쓰고도 근거 없는 결정이 쌓입니다. 아직 답이 없는 질문은 답이 없다고 적고 누가 언제까지 알아 올지만 정하면 충분합니다. 회의 원칙이 말하는 것과 같습니다. 목적이 결정인 자리에서는 결정할 수 있는 것만 결정합니다.
자주 헷갈리는 용어
| 용어 | 언제 여는가 | 킥오프와의 차이 |
|---|---|---|
| 스프린트 플래닝 | 1~2주짜리 주기가 시작될 때마다 | 프로젝트 전체의 목표와 역할이 아니라 이번 주기에 담을 작업 목록을 정합니다. 킥오프는 한 프로젝트에 한 번, 플래닝은 주기마다 반복됩니다 |
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16