Notion으로 프로젝트 관리 DB 만드는 법 (속성·뷰·AI 활용)
할 일 앱에 카드만 쌓이고 “지금 뭐가 막혔는지” 한눈에 안 보이면 프로젝트 관리가 실패한 것입니다. Notion은 만능 메모장이 아니라, 데이터베이스 + 뷰로 같은 데이터를 칸반·표·타임라인으로 바꿔 보는 도구로 쓸 때 힘이 납니다.
이 글은 포스트 22(GTD 할 일 루틴)와 달리 프로젝트·마일스톤 중심 DB 설계에 집중합니다.
준비물
- Notion 계정 (AI는 플랜에 따라 유료)
- 진행 중 프로젝트 1개 (연습용으로 “블로그 개편” 같은 작은 것)
- 소요: DB 뼈대 30~40분
따라 하기: 프로젝트 태스크 DB
1단계 — 데이터베이스 생성
- 새 페이지 →
/database→ Table 선택 - 이름:
Projects Tasks - 기본 Name 속성을
Task로 변경
2단계 — 속성(Property) 설계
| 속성명 | 타입 | 예시/옵션 |
|---|---|---|
| Status | Select | Backlog / Doing / Blocked / Done |
| Priority | Select | P0 / P1 / P2 |
| Project | Select 또는 Relation | 블로그, 앱 v1 |
| Due | Date | 마감일 |
| Owner | Person | 담당자 |
| Estimate | Number | 시간 또는 스토리포인트 |
| Notes | Text | 짧은 메모 |
| Blocked by | Text 또는 Relation | 막힌 이유 |
Relation·Rollup까지 가면 강력하지만, 처음 2주는 위 표만으로도 충분합니다.
3단계 — 뷰 3종
- Board 뷰 — Group by
Status(칸반) - Table 뷰 — filter:
Status ≠ Done, sort: Due - Calendar 또는 Timeline — Due 기준 (마일스톤 있을 때)
Board 뷰 이름 예: Weekly Board
4단계 — 주간 운영 규칙 (팀·개인 공통)
- 월요일: Backlog에서 이번 주 P0·P1만 Doing으로
- 수시: Blocked면 Status를 Blocked로 바꾸고 Notes에 한 줄 이유
- 금요일: Done 확인 후 회고 (포스트 19와 연결 가능)
5단계 — Notion AI 활용 예시 (가능한 플랜)
페이지 또는 DB에서:
이 데이터베이스에서 Status=Blocked 인 항목만 보고,1) 공통 원인 추정2) 이번 주에 풀 수 있는 액션 3개3) 위임 가능한 항목을 짧게 정리해줘. 없는 정보는 있다고 지어내지 마.다른 예:
Project=앱 v1 이고 Due가 이번 주인 일을 우선순위 순으로 요약해줘.위험(마감 임박+ P0)만 따로 표시.템플릿 페이지 구조 (복제용)
# 프로젝트: (이름)## 목표 (1문장)## 성공 기준 (체크 가능한 것 3개)## 마일스톤- [ ] M1 ...## 태스크 DB (링크된 데이터베이스 뷰)## 결정 로그 (날짜 / 결정 / 이유)Before / After
| DB 없이 | 속성+뷰 후 | |
|---|---|---|
| “뭐 하지?” | 채팅·기억 의존 | Board에서 Doing만 보면 됨 |
| 막힘 | 묻히기 쉬움 | Blocked + Notes |
| 주간 공유 | 장문 회의록 | 필터된 표 링크 공유 |
자주 하는 실수
- 속성을 15개 이상 만들기 → 입력 피로로 폐기
- 모든 메모를 Task Name에 쓰기 → Notes·하위 페이지로 분리
- AI 요약만 믿고 Status를 안 고침 → AI는 보조, 상태 값은 사람이 진실의 원천
FAQ
Q. Jira/Linear 대신 Notion만으로 suff 한가요? 소규모·콘텐츠·사이드 프로젝트는 충분. 대규모 엔지니어링 이슈 추적은 Linear/Jira가 유리 (포스트 12).
Q. 무료로 AI 없이 쓸 가치 있나요? 있습니다. 뷰와 속성만으로도 가시성이 올라갑니다.
Q. 모바일에서도 쓰나요? 상태 변경·체크는 모바일, 구조 설계는 데스크톱이 편합니다.
입력 습관을 만드는 필터
Board 뷰에 filter Status = Doing and Owner = Me 를 저장해 두면 “내 일만” 보입니다.
주간 공유 메시지 템플릿
이번 주 P0:- ...Blocked:- ... (필요한 도움)다음 주 예정:- ...실습 체크 (발행 전 본인 확인)
- 글의 명령을 다른 폴더에서 한 번 더 실행해 보았는가
- 독자가 준비물 없이 막히지 않는가
- 관련 글과 역할이 겹치지 않는가
주말 실습: 미니 프로젝트 보드 만들기
- 프로젝트 이름 “개인 포트폴리오 사이트”로 Task DB를 만든다.
- 태스크 8개를 넣는다: 기획, 와이어, 헤더, 본문, 배포, 도메인, 읽기자료, 회고.
- P0 2개만 필터 뷰로 저장한다.
- 하나 이상 Blocked로 두고 Notes에 막힌 이유를 적는다.
- AI에게 Blocked 목록만 붙여 도움 요청 문장을 작성한다(실행은 선택). 성공 기준: 보드 없이도 텍스트만으로 상태를 설명할 수 있음.
실습 체크리스트 (Notion 프로젝트 DB)
- 속성(상태·담당·기한·우선순위)이 최소 세트로 있는가
- 보드·리스트·캘린더 뷰 3종이 있는가
- 주간 운영 규칙(월·수·금)을 한 페이지에 적었는가
- 민감 정보가 AI에 자동 공유되지 않게 설정했는가
- 샘플 태스크 5개로 뷰 필터를 검증했는가
속성 사전 (팀 합의용 초안)
Notion DB가 실패하는 가장 큰 이유는 속성 이름이 사람마다 다르게 쓰이기 때문입니다. 아래처럼 한 줄 정의를 고정하세요.
- 상태: 지금 진행 위치 (감정·우선순위 아님)
- 우선순위: 이번 주 자원 배분 기준 (P0는 주 1~2개 권장)
- 담당: 실행 책임자 1명 (여러 명이면 서브태스크로 쪼갬)
- 기한: 외부 약속이 있는 날짜만 (임의 날짜 남발 금지)
- 근거 링크: 스펙·이슈·슬랙 스레드 URL
뷰를 “보고서”로 쓰지 않기
보드 뷰를 경영 보고용 대시보드처럼 꾸미기 시작하면 입력 비용이 폭증합니다. 보고가 필요하면 주 1회 필터된 링크드 뷰를 공유 페이지에 붙이고, 일상 입력은 최소 속성만 받게 하세요.
Notion AI 안전 수칙
- 고객사명·매출·인사 평가가 있는 페이지에서는 AI 기능을 끄거나 페이지 권한을 분리합니다.
- AI에게 “우선순위를 정해줘”라고 맡기지 말고, “후보 기준 3개만 제안해줘”라고 범위를 제한합니다.
- 자동 생성 태스크는 Inbox로만 보내고, 주간 리뷰 전까지 Next로 올리지 않습니다.
이 글의 DB는 프로젝트 실행용입니다. 개인 잡무 수집은 GTD 글의 흐름을 쓰고, 두 DB를 관계(relation)로만 느슨히 연결하는 편이 장기적으로 유지보수 비용이 낮습니다.
이 글을 끝내면 할 수 있는 것
- 프로젝트 태스크 DB의 속성·뷰·주간 규칙을 직접 만든다.
- Notion AI는 요약·분해 보조로만 쓰고, 일정·우선순위는 사람이 정한다.
- 포스트 22(GTD)와 달리 마일스톤·프로젝트 단위에 집중한다.
속성 설계 실수 줄이기
- 상태는 5개 이하 (Backlog / Doing / Review / Done / Blocked).
- 우선순위는 숫자보다 P0~P2 orth.
- “긴급” 체크박스를 남발하면 보드가 망가집니다. 주간 WIP 한도를 두세요.
주간 운영 시나리오 (예시)
| 요일 | 15분 행동 |
|---|---|
| 월 | 이번 주 Done 정의 3개 확정 |
| 수 | Blocked 원인 한 줄 기록 |
| 금 | Done 이동 + 회고 링크 |
트러블슈팅
| 증상 | 원인 | 해결 |
|---|---|---|
| 보드가 항상 복잡 | 속성 과다 | 속성 7개 이하로 축소 |
| 아무도 안 씀 | 입력 비용 큼 | 필수 속성 3개만 |
| AI 요약이 헛소리 | 태스크 제목 모호 | 제목을 동사+목적어로 |
| 권한 실수 | 공유 범위 과다 | 게스트/팀 권한 점검 |
| 모바일에서 느림 | DB·관계 과다 | 링크된 뷰 분리 |
FAQ 보강
Q. Jira 대신 Notion만으로 개발팀이 되나요? 소규모·콘텐츠·사이드 프로젝트는 충분합니다. 대규모 엔지니어링 이슈·SLA는 Linear/Jira가 유리합니다.
Q. 템플릿을 팔아도 되나요? 이 글 구조는 자유 활용 가능합니다. 다만 Notion 공식 템플릿 마켓 정책은 별도입니다.
Q. AI가 자동으로 기한을 넣어도 되나요? 초안만. 사람 확인 없는 기한 자동 확정은 일정 사고를 만듭니다.
현장에서 바로 쓰는 Notion 프로젝트 DB 운영 노트
이 절은 Notion 프로젝트 DB 본문을 읽은 뒤 다음 영업일 안에 실행할 때 참고하는 운영 메모입니다. 도구 이름보다 중요한 것은 반복 가능한 순서와 실패 기록입니다. 처음 한 주는 완벽한 세팅보다 ‘최소 성공 1회’를 목표로 하세요. 성공 기준을 숫자나 체크박스로 적어 두면 나중에 회고할 때 감이 아니라 데이터로 판단할 수 있습니다.
첫 48시간 실행 계획 (Notion 프로젝트 DB)
- 준비물 절을 보고 계정·설치·권한을 먼저 끝낸다. 본론 중간에서 설치하면 흐름이 끊긴다.
- 본문의 핵심 절차 중 가장 작은 단위 하나만 끝까지 재현한다.
- 트러블슈팅 표에서 해당 증상 행을 찾아 해결을 적용하고, 없으면 새 행을 메모한다.
- FAQ에서 비용·보안·팀 도입 질문을 읽고 내 환경에 해당하는지 표시한다.
- 실습 체크리스트를 인쇄하거나 이슈 한 장에 옮겨 완료 표시를 남긴다.
- 동료가 있다면 5분 데모를 보여 주고, 설명 중 막힌 지점을 문서에 보완한다.
품질을 유지하는 주간 루틴
Notion 프로젝트 DB 관련 설정과 문서는 한 번 만들고 방치하면 금방 낡습니다. 매주 15분만 투자해 다음을 점검하세요. 지난주에 새로 생긴 예외 상황, 팀원이 물은 질문, 실패한 명령, 유료 결제 여부, 보안 정책 변경 여부입니다. 변경이 있으면 본문 요약이 아니라 체크리스트와 트러블슈팅 표를 먼저 고칩니다. 긴 서론을 고치는 것보다 표 한 줄이 다음 독자를 더 많이 구합니다.
혼자 일할 때와 팀에서 쓸 때의 차이
개인 사이드 프로젝트에서는 속도와 실험이 우선일 수 있습니다. 하지만 팀 저장소·고객 데이터·공통 인프라가 걸리면 Notion 프로젝트 DB 사용 방식이 달라져야 합니다. 권한, 감사 로그, 승인 단계, 공유 채널 공지 같은 사회적 절차가 기술적 절차만큼 중요합니다. 모호하면 보수적으로 선택하세요. 막힌 시간을 줄이려다 사고를 키우는 경우가 더 비쌉니다. 팀 합의 문장이 없다면 이 글의 체크리스트를 복사해 ‘우리 팀 버전’ 헤더만 바꿔 공유하는 것으로 충분합니다.
측정 지표 제안
| 지표 | 측정 방법 | 해석 |
|---|---|---|
| 첫 성공까지 시간 | 타이머 | 온보딩 문서 개선 신호 |
| 주간 재사용 횟수 | 간단한 해시 체크 | 습관 정착 여부 |
| 실패 재발 | 같은 증상 메모 | 트러블슈팅 보강 필요 |
| 도움 요청 횟수 | 슬랙/구두 | 문서 공백 위치 |
| 중단 결정 | 2주 후 유지/폐기 | 도구 과잉 방지 |
폐기 기준 (중요)
Notion 프로젝트 DB가 팀에 안 맞을 수도 있습니다. 실패를 인정하는 기준을 미리 정하세요. 예를 들어 2주 동안 핵심 절차를 3회 이상 재현하지 못했거나, 보안 검토에서 막혔거나, 기존 도구 대비 명확한 이득이 없으면 중단이 올바른 결정입니다. 중단할 때도 설정 내보내기·권한 회수·문서 보관 위치를 남겨 두면 다음에 재도전할 때 비용이 줄어듭니다. 생산성 글의 목적은 도구 수집이 아니라 더 적은 마찰로 같은 품질의 결과를 내는 것입니다.
독자가 자주 놓치는 디테일
- 버전을 안 적으면 한 달 뒤 같은 글이 거짓이 됩니다. 환경 절에 버전을 남기세요.
- 스크린샷만 있고 텍스트 명령이 없으면 접근성과 검색성이 떨어집니다.
- 성공 로그만 남기고 실패 로그를 지우면 학습이 사라집니다.
- 다른 글과 주제가 비슷할 때는 이 글의 완료 정의만 다시 읽고 범위를 지키세요.
- 공유 전에 시크릿·사내 URL·고객명이 있는지 검색하세요.
정리
좋은 Notion 프로젝트 관리의 핵심은 예쁜 페이지가 아니라 Status·Priority·Due가 비어 있지 않은 DB입니다. 오늘 Task 표 하나와 Board 뷰 하나만 만들어 보세요.
참고: Notion AI 도움말 · Notion 템플릿
글 공유
이 글이 도움이 되셨다면 다른 사람들과 공유해 주세요!
