타운홀과 올핸즈는 모두 전사 구성원이 정보를 공유하고 질문하는 자리를 가리키며, 회사에 따라 같은 뜻으로 쓰기도 합니다. 실무에서는 올핸즈를 정기적인 지표·우선순위 동기화, 타운홀을 중요한 경영 맥락과 질의응답에 무게를 둔 전사 대화로 구분할 수 있습니다. 킥오프는 프로젝트 시작 전 정렬, 랩업은 종료 시 결과·교훈·후속 조치를 남기는 회의입니다.
다만 이 구분은 법률이나 국제표준이 아니라 조직의 운영 관행입니다. Atlassian은 전사 업데이트와 질문을 다루는 자리를 all-hands라고 설명하면서 자사의 유사한 회의를 global town hall이라고도 부릅니다. Trello는 전원이 참여하는 공개 질의응답 자리를 Town Hall로 운영했고, GitLab은 전사 회의에 Assembly라는 별도 이름을 사용합니다. 따라서 이름을 외우기보다 회사가 정한 목적·입력·산출물을 확인해야 합니다.
네 가지 회의는 무엇이 다른가요?
| 회의 | 주된 목적 | 열어야 하는 시점 | 핵심 참석자 | 사전 입력 | 종료 후 남길 산출물 |
|---|---|---|---|---|---|
| 타운홀 | 중요한 경영 맥락을 설명하고 구성원의 질문을 다룸 | 전략 변화, 조직 개편, 중요한 성과·이슈처럼 설명과 대화가 필요할 때 | 전사 구성원, 경영진, 질문에 답할 책임자 | 결정 배경, 공개 가능한 자료, 사전 질문 | 답변 기록, 미답변 항목의 담당자·답변기한, 확정된 결정 |
| 올핸즈 | 전사가 같은 지표와 우선순위를 보도록 정기적으로 동기화 | 정해진 주기 또는 여러 팀이 함께 알아야 할 변화가 생겼을 때 | 전사 구성원, 지표·과제 책임자 | 핵심 지표, 팀별 주요 변화, 우선순위 | 변경된 우선순위, 팀 간 의존사항, 후속 조치 |
| 킥오프 | 프로젝트의 목표·범위·역할·의사결정 방식을 시작 전에 맞춤 | 새 프로젝트 시작, 중대한 범위 변경, 재시작 시점 | 프로젝트팀, 의사결정자, 주요 이해관계자 | 목표, 범위, 성공 기준, 일정, 역할, 위험 | 프로젝트 운영 기준, 결정사항, 첫 실행 항목과 담당자 |
| 랩업 | 계획과 실제 결과를 비교하고 교훈·인수인계·남은 일을 정리 | 프로젝트 또는 주요 단계 종료 시점 | 프로젝트팀, 결과 인수자, 필요한 이해관계자 | 목표 대비 결과, 변경 이력, 미해결 항목, 회고 자료 | 결과 요약, 교훈, 인수인계 자료, 후속 조치와 기한 |
같은 이름이라도 위 항목이 다르면 실제로는 다른 회의입니다. 반대로 이름이 달라도 목적과 산출물이 같다면 회의를 둘로 나눌 실익이 크지 않습니다.
타운홀과 올핸즈는 꼭 따로 운영해야 하나요?
반드시 나눌 필요는 없습니다. 전사 규모가 작고 정기 업데이트 안에서 충분한 질의응답이 가능하다면 하나의 전사 회의로 운영해도 됩니다. 구분이 필요한지는 이름이 아니라 다음 조건으로 판단하세요.
| 운영 상황 | 권장 방식 | 이유 |
|---|---|---|
| 정기 지표와 팀별 우선순위를 짧게 맞추면 충분함 | 올핸즈 하나로 통합 | 반복 정보와 후속 조치를 한 주기로 관리할 수 있음 |
| 조직 변화나 민감한 경영 판단에 긴 설명과 질의응답이 필요함 | 별도 타운홀 | 정기 업데이트와 다른 준비·진행·답변 책임이 필요함 |
| 두 회의의 발표자료와 참석자가 거의 같고 산출물도 같음 | 하나로 통합 | 이름만 다른 중복 회의일 가능성이 큼 |
| 정기 공유는 문서로 충분하고 질문·결정도 거의 없음 | 동기식 회의 축소 | 읽을 수 있는 업데이트를 다시 발표하는 시간을 줄일 수 있음 |
Atlassian의 all-hands 운영 사례도 전사에 같은 정보를 전달하는 기능과 리더십 질의응답을 함께 다룹니다. Trello의 town hall 사례 역시 전사 업데이트, 질문, 회의 기록을 한 흐름에 둡니다. 두 사례는 타운홀과 올핸즈에 보편적인 경계가 있다기보다 조직이 회의의 목적을 명시해야 한다는 점을 보여줍니다.
회의명보다 먼저 정할 운영 기준은 무엇인가요?
캘린더 제목만으로 참석자가 준비 수준을 알기는 어렵습니다. 반복 회의마다 아래 다섯 가지를 한 문서에 고정해 두세요.
회의 목적: 이 자리에서 함께 이해하거나 결정할 한 가지
참석 기준: 반드시 참여할 역할과 참고만 하면 되는 역할
사전 입력: 미리 읽을 자료, 검증할 숫자, 제출할 질문
진행 규칙: 발표·질문·결정에 배정한 시간과 결정권자
종료 산출물: 결정, 담당자, 기한, 미답변 항목, 공개 범위예를 들어 분기 타운홀이라면 목적을 분기 실적 발표로만 적지 않습니다. 실적 차이의 원인과 다음 분기 우선순위를 설명하고, 구성원 질문에 책임자가 답한다처럼 회의에서 필요한 대화까지 밝혀야 합니다. 숫자는 기간·단위·확정 여부를 표시하고, 질문에 답하지 못했다면 담당자와 답변기한을 남깁니다.
킥오프에서는 무엇을 결정해야 하나요?
킥오프는 프로젝트 소개 발표가 아니라 실행 중 판단 기준을 맞추는 자리입니다. Atlassian의 프로젝트 킥오프 사례도 목표, 우선순위, 지표와 상충관계를 팀이 함께 이해하는 데 초점을 둡니다.
킥오프가 끝날 때는 최소한 다음 항목이 확정돼 있어야 합니다.
- 목표와 성공 기준: 무엇이 달라지면 프로젝트가 성공인지 정합니다.
- 범위와 제외 범위: 이번 프로젝트가 해결할 일과 다루지 않을 일을 나눕니다.
- 역할과 결정권: 실행 담당자, 승인자, 자문자와 공유 대상자를 구분합니다.
- 일정과 주요 의존성: 마일스톤, 선행 업무, 외부 회신과 검토 일정을 연결합니다.
- 위험과 상충관계: 일정·비용·품질 중 무엇을 우선하고 어디까지 조정할 수 있는지 정합니다.
- 다음 실행: 첫 작업, 담당자, 완료기한을 기록합니다.
목표를 공유했다는 문장만으로는 부족합니다. 예를 들어 비용 절감 프로젝트라면 절감 대상, 기준 기간, 제외 비용, 품질 저하를 막을 지표를 함께 정해야 이후 결과를 같은 기준으로 비교할 수 있습니다.
랩업에서는 무엇을 남겨야 하나요?
랩업은 잘한 점을 발표하고 끝내는 행사가 아닙니다. 프로젝트 결과를 인수할 사람이 현재 상태를 이해하고, 다음 프로젝트가 같은 판단을 다시 하지 않도록 자료를 남기는 절차입니다.
Project Management Institute의 lessons learned 가이드는 교훈을 프로젝트 종료 때만 모으지 말고 진행 중에도 식별하며, 식별·문서화·분석·저장·재사용하는 흐름으로 관리하라고 설명합니다. 랩업 문서에는 다음 항목을 남기는 편이 좋습니다.
- 목표와 실제 결과의 차이
- 일정·범위·비용이 바뀐 이유와 결정자
- 잘 작동한 방식, 문제가 된 방식, 다음에 바꿀 방식
- 완료하지 못한 일과 남은 위험
- 운영 조직에 넘길 문서·권한·연락처
- 후속 조치별 담당자, 완료기한, 확인 방법
Keep / Problem / Try는 대화를 정리하는 한 가지 형식으로 사용할 수 있습니다. 다만 Try를 아이디어 목록으로만 남기지 말고 실행 담당자·기한·성공 기준을 붙여야 다음 프로젝트에서 확인할 수 있습니다.
경영지원·재무 담당자는 어떤 자료를 확인해야 하나요?
전사 회의의 숫자는 의사결정과 구성원의 기대에 영향을 줍니다. 경영지원·재무 담당자는 모든 회의를 주관할 필요는 없지만, 숫자와 실행 조건이 등장하는 구간의 책임을 분명히 해야 합니다.
| 확인 항목 | 회의 전 | 회의 후 |
|---|---|---|
| 지표 | 기준 기간, 단위, 산식, 원천자료, 잠정·확정 여부 확인 | 발표 수치의 정정 여부와 기준 변경 기록 |
| 예산·인력 결정 | 금액·인원·적용 기간과 승인 상태 구분 | 결정사항을 예산·채용 계획과 연결하고 담당자 지정 |
| 공개 범위 | 개인정보, 계약조건, 고객정보 등 공유 제한 검토 | 배포본과 제한 자료를 분리해 보관 |
| 후속 조치 | 실행에 필요한 비용·권한·의존성 확인 | 담당자·기한·승인 경로를 결정 기록에 반영 |
회의에서 마케팅 투자를 늘린다고 정했다면 구호만 기록하지 않습니다. 적용 시점, 예산 변경 범위, 승인자, 성과를 다시 볼 날짜를 남겨야 실행과 재검토가 가능합니다. 숫자와 관련 없는 회의까지 재무 의제로 바꿀 필요는 없습니다.
회의 주기는 어떻게 정해야 하나요?
타운홀은 분기, 올핸즈는 주간처럼 고정된 정답은 없습니다. 정보가 바뀌는 속도, 함께 내려야 할 결정의 빈도, 참석 비용으로 정하세요.
- 공유할 내용이 거의 바뀌지 않으면 주기를 늘리거나 문서 업데이트로 전환합니다.
- 여러 팀의 우선순위가 자주 충돌하면 짧은 동기화 주기가 필요할 수 있습니다.
- 질문과 결정 없이 발표만 반복된다면 회의 목적을 다시 검토합니다.
- 시차나 교대근무로 전원 참여가 어렵다면 사전 자료와 사후 기록의 공개 범위를 먼저 정합니다.
회의 시간이 짧다는 이유만으로 효율적인 것은 아닙니다. 참석자가 왜 필요한지 알고, 검증된 입력을 바탕으로 결정하며, 끝난 뒤 누가 무엇을 언제까지 할지가 남아야 합니다.
확인한 운영 자료
확인일: 2026년 7월 13일
