개요
•
이 영상은 OKR(Objectives and Key Results) 관리 시스템을 노션으로 구축하는 실제 컨설팅 세션 소개 영상
•
기존 레몬베이스에서 사용하던 OKR 데이터를 노션으로 이식하면서 Objective → Key Result → Initiative → Task의 4단계 계층 구조 설계 및 각 단계별 데이터 입력·트래킹·시각화 방법 구현 과정 설명
•
상위 계층에서 버튼을 클릭해 관계형을 자동으로 맺으면서 하위 데이터를 생성하는 버튼 기반 계층적 데이터 생성과 최상위 Objective 완료 시 연결된 모든 KR과 Initiative를 자동으로 비활성화하는 활성화 필드 기반 일괄 상태 관리를 핵심 설계 원칙으로 사용하는 시스템
•
노션 AI를 활용해 회의 내용을 바탕으로 태스크를 자동 생성하고, 지침을 통해 AI 행동을 제어하는 실제 활용 사례 소개
•
측정 방식(합산/평균/순차) 설정, KR 트래킹 로그 관리, 팀 속성을 통한 다중 필터링, 개인/팀/전사 레벨 대시보드 구성, 기한 경과 항목 자동 표시까지 포함하는 포괄적인 OKR 운영 시스템 구축 방법론 정리
주요 학습 포인트
•
4단계 OKR 계층 구조: Objective → Key Result → Initiative → Task로 이어지는 관계형 데이터 구조 설계 방식
•
버튼 기반 계층적 데이터 생성: 상위 항목에서 버튼 클릭 시 관계형 자동 연결 및 하위 데이터 생성 구조
•
활성화 필드를 통한 일괄 상태 관리: Objective 완료 시 연결된 KR/Initiative 자동 비활성화 구조
•
측정 방식의 전략적 설정: KR 특성에 따라 합산(매출), 평균(객단가), 순차(마일스톤) 방식으로 구분하는 설계 기준
•
노션 AI의 실무 활용: 회의 내용 기반 태스크 자동 생성 및 지침 학습을 통한 행동 제어 방식
요약
1. OKR 데이터 구조와 계층적 입력 시스템
•
4단계 계층 구조 정의
◦
Objective: 최상위 목표 계층
◦
Key Result: 측정 가능한 핵심 결과 계층
◦
Initiative: 목표 달성을 위한 실행 계획 계층
◦
Task: 실제 업무 단위 계층
계층 | 역할 |
Objective | 최상위 목표 |
Key Result | 측정 가능한 핵심 결과 |
Initiative | 실행 계획 |
Task | 구체적 업무 |
•
버튼 기반 데이터 생성 원칙
◦
Objective 입력 후 입력완료 버튼 클릭 후 하위 KR 생성 버튼 사용 원칙
◦
KR 생성 시 버튼을 클릭한 사람을 기본 담당자로 자동 지정하는 구조
◦
추가 담당자는 생성 이후 수동 추가 처리 방식
◦
관계형 연결 보장을 위해 데이터베이스 하단의 "새로 만들기" 버튼 사용 금지 원칙
입력 흐름:
[Objective 입력] → [입력완료 클릭] → 하위 섹션으로 이동
↓
[KR 생성 버튼] → KR 데이터 생성 (담당자 자동 지정)
↓
[Initiative 생성 버튼] → Initiative 데이터 생성
↓
[Task 생성 버튼] → Task 데이터 생성
Plain Text
복사
핵심 원칙: 계층 간 관계형 연결은 상단에 설계된 버튼을 통해서만 이루어지는 구조
•
자주 발생하는 실수 패턴
◦
데이터베이스 하단의 "새로 만들기" 버튼을 사용해 관계형이 끊어진 페이지를 생성하는 실수
◦
입력완료 체크박스를 데이터 흐름과 무관하게 수동으로 체크해 단계 구분을 흐리는 실수
◦
상위 버튼이 아닌 하위 뷰에서 직접 페이지를 생성해 연결이 누락되는 구조적 오류
2. 측정 방식과 KR 트래킹 시스템
•
측정 방식 3가지 유형 정의
◦
합산 방식: 시간이 지날수록 누적되는 지표용 방식 (예: 연매출 200억, 신규가입 고객 2만명)
◦
평균 방식: 비율·평균값 지표용 방식 (예: 객단가 20% 상승, 에센셜 매출 비율 30%)
◦
순차 방식: 단계별 달성·마일스톤 기반 진행 상황 표현용 방식
•
KR 트래킹 입력 프로세스
◦
상위 KR 상세 페이지에서 KR Tracking 버튼 클릭으로 트래킹 레코드 생성
◦
기본값으로 오늘 날짜 자동 입력, 필요 시 과거 입력분 보완용 날짜 수정 허용
◦
해당 날짜의 실제 달성 수치 입력
◦
입력완료를 통해 로그 고정 및 다음 입력으로 이동
•
트래킹 데이터 활용 목적
◦
시간 흐름에 따른 KR 진척률 시각화
◦
KR별 달성 추이 분석 및 패턴 파악
◦
목표 대비 현재 위치와 속도 진단
•
KR 설정 체크리스트
측정 방식(합산/평균/순차) 사전 결정
목표 숫자와 단위 정의
지표 단위(%, 명, 건 등) 명시
담당자 지정 및 책임 범위 설정
기간 설정 및 Objective와의 정합성 점검
3. 노션 AI 실무 활용과 지침 관리
•
노션 AI 자동 데이터 입력 사례
◦
회의록 기반 태스크 입력을 AI에게 요청할 때 관련 데이터 자동 생성 사례 발생
◦
일부 상황에서 입력완료 체크박스까지 자동 체크되어 예기치 않은 단계 이동 발생 사례 존재
•
지침(Instructions)을 통한 AI 행동 제어 방식
◦
원치 않는 행동이 반복될 때 "지침에 추가"라는 형태로 제한 조건 명시
◦
예시 문구: "태스크의 모든 데이터베이스에서 입력완료 체크박스는 사람이 직접 클릭할 것이므로 AI는 변경하지 않는 규칙"
◦
지침 업데이트를 통해 이후 동일 실수 재발 방지
지침 추가 예시:
"태스크의 모든 데이터베이스에서 입력완료 체크박스는
사람이 직접 클릭할 것이므로 AI가 건들지 않도록 설정"
Plain Text
복사
•
AI 활용 가능성 정리
◦
회의 내용을 기반으로 태스크를 자동 입력하는 워크플로우 설계 가능성
◦
담당자 자동 배정 및 반복 입력 자동화 가능성
◦
데이터 입력·정리 영역에서 휴먼 에러를 줄이고 속도를 높이는 자동화 도입 가능성
핵심 원칙: 노션 AI는 지침을 읽고 행동하는 시스템, 원하지 않는 행동은 지침에 명시적으로 제한사항을 추가하는 방식으로 제어
4. 팀 속성 설계와 다중 필터링
•
팀 필드 추가 배경
◦
KR 단계에서부터 여러 팀이 함께 관여하는 구조 발생 가능성
◦
팀 리더가 소속 팀원 전체의 OKR 진행 상황을 한 번에 파악해야 하는 요구
◦
팀 미팅 시 현황 공유용 자료로 활용할 수 있는 팀 단위 뷰 필요
•
팀 속성이 필요한 데이터베이스 범위
◦
Key Result: 담당 팀 지정용 다중 선택 속성 필요
◦
KR Tracking: 상위 KR의 팀 정보를 자동 상속하는 구조 필요
◦
Initiative, Task: 실행 주체 기준 팀 정보 포함 필요
•
팀 속성 자동 상속 구조
◦
KR 생성 시 지정한 팀 정보를 KR Tracking, Initiative, Task에 순차 전파하는 구조 설계
◦
상위 계층에서 팀 정보 변경 시 하위 레코드에서 일관된 필터링 가능 상태 확보
•
팀 데이터 입력 예시
KR | 담당 팀 | |
연매출 200억 | 디자인, 마케팅, 생산 | |
신규가입 고객 2만명 | 마케팅, 웹비주얼 | |
객단가 20% 상승 | 생산, 디자인, 마케팅 | |
에센셜 매출 비율 30% | 디자인, 마케팅, 생산 |
5. 활성화 필드를 통한 일괄 상태 관리
•
활성화(Activation) 필드 역할 정의
◦
Objective의 진행 여부를 표현하는 체크박스 역할
◦
조건: 오늘 날짜가 Objective 기간 내에 존재하고 상태가 완료가 아닐 때 활성화 상태 유지
◦
Objective 완료 시 연결된 KR, Initiative의 활성화 필드를 자동으로 끄는 일괄 비활성화 구조
•
활성화 조건 로직 정리
활성화 = TRUE 조건:
1. 오늘 날짜가 Objective 기간 내 존재
2. 상태가 "완료"가 아닌 상태
활성화 = FALSE 조건 (둘 다 충족):
1. 날짜가 Objective 기간을 초과
2. 상태가 "완료"로 변경된 상태
Plain Text
복사
•
계층별 활성화 연동 구조
◦
Objective 활성화 필드를 기준으로 KR·Initiative의 활성 상태를 연동
◦
Task와 KR Tracking은 개별 업무 단위 특성상 독립적으로 완료 처리
•
설계 의도 요약
◦
날짜만 지났다는 이유로 미완료 OKR이 자동으로 사라지지 않도록 보호하는 구조
◦
잘못된 완료 처리나 날짜 변경 상황에서도 명시적인 완료 버튼 클릭 없이는 비활성화되지 않는 설계
핵심 원칙: 활성화는 "날짜 경과"와 "완료 상태" 두 조건이 모두 충족될 때만 꺼지는 보호 장치 역할
6. 대시보드 구성과 현황판 설계
•
대시보드 구성 요소 정의
◦
Objective: 개수가 적어 고정 표시용 표 뷰 구성
◦
Key Result: 고정 표시 + 진척률 시각화용 차트 뷰 병행 구성
◦
Initiative: 복잡성 관리를 위해 토글 하위에 배치하는 구조
◦
Task: 필요 시 토글 또는 별도 섹션으로 분리하여 노출
•
대시보드의 보기 전용 원칙
◦
현황판에서는 생성·상태 변경 버튼 제거로 보기 전용 환경 유지
◦
입력·수정 작업은 개인 페이지 또는 원본 DB에서만 허용
◦
실수로 인한 데이터 변경·구조 파괴 리스크를 최소화하는 설계
•
뷰 형식 선택 가이드
데이터 유형 | 권장 뷰 | 이유 |
Objective | 표 | 개수가 적고 상세 정보 확인 목적 |
Key Result | 표 + 차트 | 진척률 시각화 필요 |
Initiative | 표 | 깔끔한 구조와 일관성 유지 |
Task | 표 또는 보드 | 상태별 그룹화 필요 시 보드 뷰 활용 |
일정 확인 | 타임라인 | 기간 시각화 목적 |
•
보드 뷰 vs 표 뷰 결정 기준
◦
보드 뷰는 상태별 그룹화에 유리하지만 시각적으로 복잡해질 위험 존재
◦
표 뷰는 정보 밀도가 높고 일관된 사용자 경험 제공에 유리
◦
최종적으로 대부분의 관리 뷰를 표 뷰 중심으로 통일하는 전략
7. 개인 페이지 설계와 OKR 관점
•
개인 페이지 기본 구성 요소
◦
Objective: 전사 공통 목표를 동일하게 표시하는 섹션
◦
Key Result: 전사 공통 KR을 달성률 확인용으로 노출하는 섹션
◦
Initiative: 담당자(PIC)가 나인 항목만 필터링해 보여주는 섹션
◦
Task: 담당자 기준 나에게 할당된 태스크만 필터링해 보여주는 섹션
◦
타임라인: 내 태스크 일정을 시각화하는 뷰
•
개인 페이지에서의 버튼 활용
◦
대시보드와 달리 개인 페이지에서는 트래킹 입력·태스크 상태 변경 등 버튼 사용 허용
◦
본인의 데이터만 직접 수정하는 구조로 책임 범위 명확화
•
프로젝트 개인 페이지와의 통합 가능성
◦
OKR 개인 페이지와 프로젝트 개인 페이지를 통합한 전역(Global) 개인 페이지 설계 가능성
◦
여러 시스템에서 참조하는 공통 개인 허브 페이지를 두고 한 곳에서 수정 시 전체 반영되는 구조
통합 개인 페이지 구조 예시:
├── 프로젝트 섹션
│ ├── 아이템
│ ├── 태스크
│ └── 타임라인
└── OKR 섹션
├── Objective (전사 공통)
├── Key Result (전사 공통)
├── Initiative (내 것만)
├── Task (내 것만)
└── 타임라인
Plain Text
복사
8. 팀 페이지 설계와 권한 구조
•
팀 페이지 목적 정의
◦
팀장이 소속 팀원들의 OKR 진행 상황을 한눈에 파악할 수 있는 뷰 제공
◦
분기별 업무 피드백 및 평가 자료로 재사용 가능한 구조 설계
◦
향후 AI 기반 정량·정성 피드백 자동화를 위한 데이터 기반 준비
•
팀 페이지 구현 방식
◦
개인 페이지와 동일한 구조를 사용하되 필터만 "팀 = 해당 팀"으로 변경하는 방식
◦
자동 생성 대신 팀별 별도 페이지를 수동으로 생성해 성능 저하 방지
•
인사 담당자용 특수 대시보드 구조
◦
개인별 OKR 현황을 조회할 수 있는 전사 관점 대시보드 별도 구축
◦
전역 DB에서 데이터를 참조하고 권한 설정을 통해 접근을 제한하는 구조
•
기술적 한계와 해결책
◦
"나" 필터는 로그인 사용자 기준 자동 적용 기능으로 개인 뷰 구성에 사용
◦
타인 데이터 조회는 사람 선택용 속성·필터 UI를 통해 구현
적용 질문 예시•
우리 조직에서 OKR을 누가 어떤 주기로 리뷰하는지에 대한 정의
•
팀장이 팀원 OKR을 확인하는 경로와 빈도
•
개인 페이지에서 프로젝트와 OKR을 통합해 볼 필요성 여부
9. Initiative와 Task의 생존 정책
•
Initiative 생존 정책 정의
◦
완료된 Initiative를 분기 동안 계속 표시할지 여부에 대한 의사결정 필요
◦
결정: 분기 동안 상태와 무관하게 모든 Initiative를 표시 유지하는 정책
◦
이유: 어떤 계획이 진행되었고 무엇이 완료되었는지 전체 맥락 파악을 위한 정보 보존 필요
◦
전제: Initiative 개수가 7–8개 수준으로 관리 가능한 범위일 때 유효한 정책
•
Task 생존 정책 정의
◦
Task는 개별 업무 단위로 완료 여부를 직접 처리하는 원칙
◦
Objective 완료 시에도 Task는 자동으로 사라지지 않고 담당자가 수동으로 완료 처리
•
Objective 완료 시 계층별 동작 정리
항목 | Objective 완료 시 | 이유 |
Key Result | 자동 비활성화 | 활성화 필드 연동 구조 |
Initiative | 자동 비활성화 | 활성화 필드 연동 구조 |
Task | 유지 (수동 완료) | 개별 책임 명확화 목적 |
KR Tracking | 유지 | 히스토리 보존 목적 |
10. 타임라인 뷰와 기한 경과 알림
•
타임라인 뷰 활용 방식
◦
Task 기간 분포를 한눈에 파악하기 위한 시각화 도구로 활용
◦
Initiative별 그룹화를 통해 어떤 계획 하위의 Task인지 구조적으로 확인
◦
드래그앤드롭으로 일정 조정이 가능한 운영 인터페이스 제공
•
타임라인 그룹화 옵션
◦
Initiative별 그룹화로 상위 계획 기준 Task 묶음 관리
◦
상태별 그룹화로 시작 전/진행 중/완료 상태를 구분해 집중 관리
•
기한 경과 알림 시스템 설계
◦
별도 섹션에서 기한 경과 항목만 필터링해 보여주는 경고용 뷰 구성
◦
조건: 종료일이 오늘 이전이고 상태가 완료가 아닌 항목
기한 경과 필터 조건:
- 종료일이 비어있지 않은 상태
- 종료일 < 오늘 날짜
- 상태 ≠ 완료
Plain Text
복사
•
타임라인 뷰에서의 완료 처리 흐름
◦
미완료 탭에는 진행 중인 Task만 표시
◦
Task 완료 시 타임라인 미완료 뷰에서 자동 제거
◦
Objective 완료 시 해당 Objective 관련 타임라인 전체를 비활성화하거나 별도 섹션으로 이동하는 정책 적용 가능
11. 날짜 입력 팁과 UI 조작법
•
종료일 설정 권장 방법
◦
방법 1: 시작일 클릭 후 Shift + 종료일 클릭으로 범위 선택
◦
방법 2: 종료일 토글을 끄고 시작일부터 끝까지 드래그로 범위 지정
◦
비권장 방법: 종료일 토글을 켜고 시작일·종료일을 각각 입력하는 방식 (혼선 가능성 증가)
•
페이지 내 불필요한 블록 삭제 방법
◦
마우스로 블록 영역을 드래그해 선택
◦
ESC 키로 블록 선택 모드 전환
◦
Delete 키로 일괄 삭제
•
데이터베이스 하위 페이지 생성 주의사항
◦
페이지 내부에서 생성된 하위 페이지는 상위 마스터 DB와 관계형이 연결되지 않는 구조
◦
반드시 상단에 설계된 지정 버튼을 사용해 하위 페이지를 생성하는 원칙
◦
"3 페이지" 등 자동 생성된 임시 페이지는 삭제 후 버튼 기반으로 재생성하는 방식 권장
12. 향후 개발 로드맵과 통합 계획
•
OKR 시스템 완성 일정
◦
현재 세션에서 기본 구조 및 데이터 입력 완료 상태 목표
◦
다음 주 월요일에 최종 점검 및 질의응답 세션 진행 계획
◦
개인·팀 페이지 제작 작업은 컨설턴트 단독 진행 범위로 설정
•
프로젝트 시스템과의 통합 계획
◦
개인 페이지를 전역(Global) 페이지로 전환해 여러 시스템에서 참조하는 구조 구축
◦
OKR과 프로젝트 데이터를 한 페이지에서 통합 조회하는 관점 제공
◦
한 곳에서 수정 시 모든 참조 위치에 반영되는 단일 소스 구조 유지
•
스프린트 시스템 추가 가능성
◦
1–2개월 단기 팀 프로젝트 관리용 스프린트 시스템 도입 가능성
◦
표준화된 프로젝트 템플릿 제공 및 OKR 시스템과의 연동 가능성
◦
개인 대시보드에 스프린트 정보를 자동 연동하는 구조 설계 가능성
•
추천 학습 자료 정리
◦
노션다움 멤버십 내 3시간 분량 노션 AI 특강 콘텐츠
◦
AI 활용 템플릿 및 지침 설정 예시 자료
◦
지침 기반 AI 행동 제어 및 자동화 설계 방법론
참고 주제•
OKR 방법론과 실무 적용 사례
•
노션 관계형 데이터베이스 설계 기초
•
노션 AI 지침 설정과 자동화 활용 전략
