Notion → Action Hub Master Prompt
이 프롬프트는 v0, Lovable, Bolt, Replit Agent, Google AI Studio 같은 앱 빌더와 Claude Code, Codex, Cursor, Windsurf, GitHub Copilot Agent 같은 코딩 에이전트에서 사용할 수 있도록 작성되었다.
아래의 [DOMAIN]만 원하는 용도로 바꿔서 사용해라.
예:
NEAR Builder
Security Learning
Job Search
Hackathon Tracker
Content OS
Web3 Research
Zealy Contributor
AI Learning
Project Management
- ROLE
너는 단순히 UI를 생성하는 디자이너가 아니다.
너의 역할은 실제 데이터를 읽고, 실제 상태를 변경하고, 실제 배포까지 가능한 production-ready 개인용 웹 애플리케이션을 설계·구현·검증하는 senior full-stack engineer다.
내가 만들고 싶은 것은:
"[DOMAIN] Action Hub"
이다.
가장 중요한 목표는 예쁜 대시보드를 만드는 것이 아니다.
사용자가 앱을 열었을 때
"그래서 지금 뭘 해야 하지?"
라는 질문에 3초 안에 답할 수 있어야 한다.
- PRODUCT CONCEPT
Notion과 양방향 동기화되는 개인용 "[DOMAIN] Action Hub" 웹앱을 만들어라.
기본 구조는 다음과 같다.
Notion
→ Source of Truth / Data Layer
Server API
→ Secure Integration Layer
Action Hub
→ Execution Layer
사용자가 매번 복잡한 Notion 페이지를 직접 탐색할 필요가 없어야 한다.
Notion은 데이터를 저장하고 관리하는 역할을 한다.
Action Hub는 그 데이터를 다시 정리해서
Data
→ Priority
→ Action
→ Progress
흐름으로 보여준다.
즉,
Notion을 더 잘 보여주는 앱이 아니라
Notion에 저장된 정보를 실제 행동으로 전환하는 앱을 만든다.
- NON-NEGOTIABLE RULES
다음 조건은 절대 생략하지 마라.
정적 UI mockup만 만들지 마라.
실제 Notion API 연동을 구현한다.
실제 READ 기능을 구현한다.
실제 WRITE 기능을 구현한다.
장식용 버튼을 만들지 마라.
존재하는 모든 버튼과 링크는 실제로 동작해야 한다.
Notion Token을 client에 노출하지 마라.
API 연결 실패를 정상 상태처럼 숨기지 마라.
Demo Data와 실제 Notion Data를 혼동시키지 마라.
테스트하지 않은 기능을 "완료"라고 보고하지 마라.
기존 프로젝트가 있다면 구조를 먼저 분석하고 함부로 덮어쓰지 마라.
사용자의 실제 Notion 데이터를 임의로 삭제하거나 schema를 변경하지 마라.
화면만 존재하는 것과 기능이 작동하는 것을 절대 혼동하지 마라.
3. ENVIRONMENT DETECTION
코드를 작성하기 전에 현재 실행 환경을 먼저 확인한다.
기존 프로젝트가 있다면:
Framework
Runtime
Package Manager
Existing API structure
Existing authentication
Existing environment variables
Existing design system
Deployment target
을 먼저 확인한다.
기존 구조가 정상적이면 이를 최대한 유지한다.
Greenfield 프로젝트라면 현재 도구가 가장 안정적으로 지원하는 full-stack stack을 선택한다.
우선적으로 다음 조합을 고려한다.
Next.js
TypeScript
Server Routes / Server Actions
Vercel
하지만 특정 AI 개발 플랫폼의 native full-stack stack이 더 안정적이라면 그것을 사용해도 된다.
중요한 것은 특정 framework가 아니다.
반드시 지원해야 하는 것은:
Server-side API execution
Secret / Environment Variable 관리
Notion API READ
Notion API WRITE
Responsive Web UI
Production deployment
Error handling
Authentication 또는 Write protection
이다.
Framework 때문에 핵심 기능을 mock으로 대체하지 마라.
4. CORE UX
사용자가 앱을 열었을 때 가장 먼저 보여야 하는 정보는 다음과 같다.
지금 해야 할 일
가장 우선순위가 높은 Action
오늘 마감되는 Action
진행 중인 Action
전체 진행률
다음 추천 Action
Notion 데이터 전체를 첫 화면에 던지지 마라.
정보량보다 Decision Clarity를 우선한다.
사용자가 앱을 열고 3초 이내에 다음 행동을 선택할 수 있어야 한다.
5. MAIN NAVIGATION
최소 다음 영역을 구성한다.
HOME / NOW
가장 중요한 실행 화면이다.
표시:
Next Best Action
Today Actions
P0 / P1 Actions
Due Soon
Currently In Progress
Quick Complete
가장 중요한 Action 하나는 다른 요소보다 명확하게 강조한다.
ACTION QUEUE
상태별 Action을 관리한다.
기본 상태:
시작 전
진행 중
완료
가능하면 다음 기능도 제공한다.
Priority filter
Category filter
Due date filter
Search
Sort
사용자는 이 화면에서 Status를 변경할 수 있어야 한다.
PROGRESS
다음을 보여준다.
전체 Action
완료 Action
진행 중 Action
남은 Action
완료율
주요 Milestone
가짜 숫자를 만들지 마라.
실제 Notion 데이터에서 계산한다.
RESOURCES
다음을 지원한다.
공식 문서
학습 자료
영상
Guide
Repository
External Link
모든 Resource 버튼은 실제 URL을 사용한다.
URL이 존재하지 않으면 클릭 가능한 버튼처럼 표시하지 마라.
예:
Watch Video
Read Guide
Open Docs
Open Repository
등은 실제 href가 있을 때만 활성화한다.
외부 링크는 안전하게 처리한다.
SETTINGS / SETUP
Notion 연결과 상태를 관리한다.
표시:
Notion Connection Status
Selected Data Sources
Property Mapping
Last Successful Sync
Authentication Status
Diagnostics
6. NOTION API INTEGRATION
Notion API는 반드시 server-side에서 호출한다.
브라우저에서 직접:
https://t.co/KsL6hDHBDJ
을 호출하지 마라.
Notion Token을 JavaScript bundle이나 HTML에 절대 포함하지 마라.
환경변수를 사용한다.
예:
NOTION_TOKEN=
선택:
NOTION_VERSION=
NOTION_ACTIONS_DATA_SOURCE_ID=
NOTION_RESOURCES_DATA_SOURCE_ID=
AUTH_MODE=
HUB_ACCESS_KEY=
HUB_ACCESS_KEY를 사용하는 경우에도 절대 NEXT_PUBLIC 등의 client-side 환경변수로 노출하지 마라.
- NOTION API VERSION
구현을 시작하기 전에 가능하다면 공식 Notion API documentation을 확인하고 현재 지원되는 API version을 사용한다.
이 프롬프트 작성 시점의 최신 Notion API version은:
2026-03-11
이다.
하지만 API version을 여러 파일에 하드코딩하지 마라.
하나의 config 또는 environment variable에서 관리해 향후 변경하기 쉽게 만든다.
공식 SDK를 사용하는 경우에도 현재 지원 API와 SDK 버전 호환성을 확인한다.
- NOTION CAPABILITIES
기본 Action Hub에는 최소:
Read Content
Update Content
권한이 필요하다.
새로운 Action이나 Resource를 Notion에 생성하는 기능까지 구현하는 경우에만:
Insert Content
권한을 추가한다.
필요 이상의 Notion 권한을 요청하지 마라.
- DATA SOURCE DISCOVERY
사용자가 가능하면 Data Source ID를 직접 찾아 복사하지 않아도 되게 만들어라.
Setup 과정에서 Notion Search API를 이용해 현재 Integration과 공유된 Data Source를 찾는다.
가능하면:
object = data_source
기준으로 검색한다.
검색 결과를 사용자가 선택할 수 있게 한다.
예:
Select Actions Data Source
Select Resources Data Source
단, Notion API는 Integration과 공유되지 않은 Data Source를 볼 수 없다는 것을 고려한다.
아무것도 발견되지 않으면 단순히:
"No data found"
라고 표시하지 마라.
다음과 같이 원인을 설명한다.
"이 Notion Integration과 공유된 Data Source를 찾지 못했습니다. Notion 페이지의 Connections에서 이 Integration을 추가했는지 확인하세요."
- MANUAL FALLBACK
자동 Data Source Discovery가 실패하더라도 전체 앱 사용이 막히면 안 된다.
Manual Setup을 제공한다.
사용자가 직접:
Actions Data Source ID
Resources Data Source ID
를 입력할 수 있게 한다.
우선순위는:
Auto Discovery
→ Manual Setup
이다.
- SCHEMA MAPPING
Notion Property 이름이 예제 schema와 정확히 같다고 가정하지 마라.
예를 들어 사용자는 다음처럼 사용할 수 있다.
Name
Title
제목
Task
모두 실제로는 같은 역할일 수 있다.
따라서 App Field와 Notion Property 사이에 Mapping Layer를 만든다.
예:
Title
→ Name
Status
→ 진행상태
Priority
→ 중요도
Due Date
→ 마감일
Setup 화면에서 실제 Data Source schema를 읽은 뒤 사용자가 mapping을 확인하거나 변경할 수 있게 한다.
가능하면 property type도 검증한다.
예:
Title → title property
Status → status 또는 select
Priority → select
Due Date → date
URL → url
Type이 맞지 않으면 crash하지 말고 명확한 경고를 표시한다.
- DEFAULT SCHEMA
기본적으로 다음 schema를 지원한다.
Actions
Title
Status
Priority
Due Date
URL
Category
Order
선택적으로:
Outcome
Notes
Progress
Resources
Resource
Type
Track
Level
Status
Priority
URL
Outcome
Time
Order
하지만 [DOMAIN]을 분석해서 필요한 경우 추가 field를 제안할 수 있다.
불필요하게 schema를 복잡하게 만들지 마라.
- DOMAIN ADAPTATION
[DOMAIN]에 맞게 UI 용어와 추가 기능을 자연스럽게 조정한다.
예를 들어:
Security Learning이면:
Lab
Challenge
Concept
Practice
같은 구조를 고려한다.
Job Search이면:
Company
Position
Application Status
Deadline
Next Follow-up
같은 구조를 고려한다.
Hackathon이면:
Deadline
Submission
Build
Team
Prize
Next Milestone
등을 고려한다.
하지만 Core Architecture:
Data
→ Priority
→ Action
→ Progress
는 유지한다.
- READ FLOW
Notion → Action Hub
최소 다음 데이터를 읽는다.
Actions
Resources
Status
Priority
Due Date
URL
Category
Order
Notion 데이터를 가져온 뒤 frontend가 이해하기 쉬운 internal model로 normalize한다.
UI 컴포넌트가 Notion API raw response에 직접 강하게 의존하지 않게 한다.
예:
Notion API
→ Adapter / Mapper
→ Application Model
→ UI
구조를 선호한다.
- WRITE FLOW
Action Hub → Notion
최소 다음 변경을 지원한다.
Action 완료
Status 변경
Priority 변경
Notion page property 업데이트 API를 사용한다.
Update를 수행하기 전에:
page가 현재 허용된 Data Source에 속하는지
변경하려는 property가 allowlist에 있는지
입력값이 허용된 값인지
검증한다.
클라이언트가 임의의:
page ID
property name
data source ID
를 전달해 아무 Notion 데이터나 변경할 수 있는 구조를 만들지 마라.
- OPTIMISTIC UI
사용자 경험 향상을 위해 optimistic update를 사용할 수 있다.
하지만 Notion API 업데이트가 실패하면:
UI 상태를 이전 값으로 rollback
실패 메시지 표시
필요하면 서버 상태 재조회
를 수행한다.
사용자에게 성공한 것처럼 보여준 뒤 실제 Notion에는 저장되지 않는 상황을 방지한다.
17. CACHE / FRESHNESS
Write 이후 stale data가 계속 표시되지 않게 한다.
사용 중인 framework에 맞게:
revalidation
cache invalidation
refetch
no-store
등을 적절히 사용한다.
Write 성공 이후 server state를 다시 확인하는 것을 권장한다.
lastSyncedAt은 마지막 성공한 Notion API synchronization 시각을 의미해야 한다.
단순히 페이지를 연 시간을 표시하지 마라.
- SYNC STATUS
다음 상태를 명확하게 구분한다.
CONNECTED
OFFLINE
DEMO
SYNCING
ERROR
"NOTION LIVE" 같은 표현은 실제 실시간 synchronization을 구현한 경우에만 사용한다.
단순 fetch / refresh 방식이라면:
NOTION CONNECTED
또는
SYNCED
처럼 실제 동작과 맞는 표현을 사용한다.
실제로 구현하지 않은 기능을 marketing copy로 과장하지 마라.
- DEMO MODE
Demo Data를 사용할 수 있다.
하지만 명시적으로:
DEMO_MODE=true
인 경우에만 사용한다.
Notion API가 실패했다고 자동으로 seed data를 실제 데이터처럼 표시하지 마라.
Demo Mode에서는 화면에 반드시:
DEMO MODE
라고 표시한다.
- ERROR HANDLING
Notion 연결 오류를 하나의 일반적인:
"Something went wrong"
으로 처리하지 마라.
가능한 경우 원인을 분류한다.
예:
TOKEN_MISSING
NOTION_UNAUTHORIZED
NOTION_FORBIDDEN
DATA_SOURCE_NOT_SHARED
DATA_SOURCE_NOT_FOUND
PROPERTY_MISSING
PROPERTY_TYPE_MISMATCH
RATE_LIMITED
NOTION_API_ERROR
NETWORK_ERROR
WRITE_FAILED
각 오류에는 사용자가 다음에 무엇을 해야 하는지 설명하는 actionable message를 제공한다.
- HEALTH CHECK
다음과 같은 health endpoint 또는 동등한 server diagnostic 기능을 구현한다.
예:
/api/notion/health
검사:
NOTION_TOKEN 존재 여부
Notion API 접근 가능 여부
Data Source 접근 가능 여부
필요한 property 존재 여부
Property type 호환 여부
READ capability 여부
WRITE 가능 여부
Secret 값 자체는 response에 포함하지 마라.
예:
{
"connected": true,
"tokenConfigured": true,
"actionsDataSource": true,
"resourcesDataSource": true,
"schemaValid": true
}
처럼 상태만 반환한다.
- RETRY
429 Rate Limit 또는 일시적인 5xx 오류는 제한적으로 retry할 수 있다.
Exponential Backoff 또는 Retry-After가 제공되면 이를 고려한다.
하지만 다음 오류는 무작정 retry하지 마라.
401
403
잘못된 Data Source ID
잘못된 schema
잘못된 Token
이러한 오류는 사용자가 수정해야 한다.
- SECURITY
Notion Token은 server-only secret이다.
절대:
localStorage
client bundle
NEXT_PUBLIC_*
browser console
HTML
API response
에 노출하지 마라.
.env.example에는 변수 이름만 작성하고 실제 secret을 넣지 마라.
.env* secret file이 Git에 commit되지 않도록 확인한다.
Server log에도 Token 전체 값을 출력하지 마라.
- WRITE API PROTECTION
Production에서 누구나 Action Hub URL에 접속해 Notion 내용을 수정할 수 있게 만들지 마라.
다음 중 환경에 적합한 방식을 선택한다.
Existing authentication
OAuth / Auth provider
Platform authentication
Private deployment
Secure server-side access-key session
단순 access key 방식을 사용하는 경우에도 key 자체를 frontend bundle에 넣지 마라.
사용자가 입력한 key를 server에서 검증하고 secure / httpOnly / sameSite cookie 기반 session 등 안전한 방식으로 처리한다.
Public Demo에서는 기본적으로 WRITE 기능을 비활성화하는 것도 가능하다.
- INPUT VALIDATION
모든 write request를 server에서 다시 검증한다.
가능하면 schema validator를 사용한다.
예:
Zod
또는 현재 stack의 동등한 validation library.
Client validation만 믿지 마라.
- UI DESIGN
기본 디자인 방향:
Mission Control
Command Center
Developer Tool
Dark UI
높은 정보 명확성
큰 핵심 텍스트
명확한 CTA
적절한 monospace accent
상태를 빠르게 구분할 수 있는 hierarchy
하지만 과도한:
Glow
Gradient
Glassmorphism
Animation
Decoration
으로 실제 정보를 가리지 마라.
멋있어 보이는 것보다:
무엇을 해야 하는지 바로 알 수 있는 것
을 우선한다.
- RESPONSIVE
Desktop뿐 아니라 mobile에서도 사용할 수 있어야 한다.
Mobile 첫 화면에 최소:
Next Best Action
Today Actions
Progress
중 핵심 정보가 바로 보여야 한다.
Horizontal overflow와 작은 터치 영역을 피한다.
- ACCESSIBILITY
최소한 다음을 고려한다.
Keyboard navigation
Visible focus states
Semantic buttons
Accessible labels
Readable contrast
상태를 색상 하나에만 의존하지 않는 UI
- EMPTY STATES
데이터가 없는 경우 빈 화면만 보여주지 마라.
예:
"No Actions yet"
"Notion은 연결되어 있지만 현재 표시할 Action이 없습니다."
"Add an Action in Notion"
등 사용자가 다음 행동을 알 수 있게 한다.
- LOADING STATES
Notion 데이터를 읽는 동안 skeleton 또는 적절한 loading state를 표시한다.
빈 화면이나 갑작스러운 layout shift를 최소화한다.
- IMPLEMENTATION PROTOCOL
한 번에 전체 앱을 생성하고 바로 "완료"라고 선언하지 마라.
다음 단계대로 진행한다.
PHASE 1 — DISCOVER
현재 프로젝트와 환경을 확인한다.
기존 코드를 분석한다.
중복 구현을 피한다.
PHASE 2 — ARCHITECTURE
구현 전에 내부적으로 다음을 정의한다.
App Architecture
Notion Data Flow
Environment Variables
Authentication Strategy
Data Source Mapping
Error Strategy
Deployment Strategy
PHASE 3 — CONNECTION
Notion Token 연결을 구현한다.
Health Check를 먼저 통과시킨다.
PHASE 4 — DISCOVERY
공유된 Data Source 검색과 선택을 구현한다.
Manual fallback도 구현한다.
PHASE 5 — READ
실제 Notion 데이터를 읽는다.
실제 데이터가 UI에 표시되는지 확인한다.
Mock data로 성공했다고 판단하지 마라.
PHASE 6 — WRITE
실제 Status / Complete 변경을 구현한다.
Notion에 실제 변경이 반영되는지 확인한다.
PHASE 7 — APPLICATION UX
다음을 구현한다.
Home / Now
Action Queue
Progress
Resources
Settings / Setup
PHASE 8 — RESILIENCE
다음을 구현한다.
Loading
Empty
Offline
Demo
Unauthorized
Forbidden
Schema Error
Rate Limit
Write Failure
PHASE 9 — RESPONSIVE
Desktop과 Mobile을 확인한다.
PHASE 10 — VERIFY
모든 기능을 실제로 검증한다.
검증이 끝나기 전에는 완료라고 보고하지 마라.
- VALIDATION PROTOCOL
각 핵심 기능에 대해 다음 형식으로 검증한다.
EXPECTED
ACTION
ACTUAL
RESULT: PASS / FAIL
예:
EXPECTED
Complete 버튼 클릭 시 Notion Status가 "완료"로 변경되어야 한다.
ACTION
지정된 테스트 Action의 Complete 버튼 클릭.
ACTUAL
Notion API 성공 response 확인.
해당 page를 다시 조회.
Status가 "완료"인지 확인.
RESULT
PASS
이 과정을 실제로 수행하지 않았다면:
NOT VERIFIED
로 표시한다.
- REVERSIBLE WRITE TEST
실제 Notion credentials와 테스트 가능한 row가 있는 경우 최소 한 번의 end-to-end write test를 수행한다.
안전한 방식:
기존 Status 저장
→ 테스트 Status로 변경
→ Notion에서 변경 확인
→ 원래 Status로 복원
→ 복원 확인
사용자 데이터를 영구적으로 변경하는 destructive test는 하지 마라.
- CODE QUALITY CHECK
환경이 지원한다면 완료 전에 다음을 실행한다.
Build
Type Check
Lint
Tests
발견된 오류를 가능한 범위에서 수정한다.
Build가 실패하는데 프로젝트가 완료됐다고 보고하지 마라.
- BUTTON AUDIT
화면에 존재하는 모든:
Button
CTA
Navigation
Resource Link
Watch Video
Read Guide
Open Docs
Settings
Complete
Status Control
을 확인한다.
각 요소는:
실제 동작하거나
disabled 이유가 표시되거나
제거되어야 한다.
아무 기능 없는 decorative button을 남기지 마라.
- DEFINITION OF DONE
다음 조건이 모두 충족되어야 완료로 판단한다.
Navigation 작동
Notion READ 작동
Notion WRITE 작동
Status update 작동
Complete action 작동
Resource links 작동
Data Source discovery 작동
Manual setup 작동
Schema mapping 작동
Health Check 작동
Unauthorized state 작동
Offline state 작동
Empty state 작동
Demo state 구분
Mobile layout 정상
Secret client 미노출
Build 성공
핵심 기능 검증 완료
검증되지 않은 항목이 있다면 숨기지 말고 명시한다.
- README
README를 반드시 작성한다.
비개발자도 따라할 수 있게 작성한다.
최소 다음 내용을 포함한다.
이 앱이 무엇인지
Notion Integration 만드는 방법
필요한 Notion capability
Notion 페이지 / Data Source에 Integration 연결하는 방법
Environment Variable 설정
Local 실행 방법
Vercel 또는 선택한 host에 배포하는 방법
Data Source 자동 연결 방법
Manual Data Source 설정 방법
Property Mapping 방법
Health Check 사용법
Authentication 설정
Troubleshooting
Demo Mode 사용법
자주 발생하는 Notion API 오류 해결법
- ENV EXAMPLE
.env.example을 만든다.
예:
NOTION_TOKEN=
NOTION_VERSION=2026-03-11
NOTION_ACTIONS_DATA_SOURCE_ID=
NOTION_RESOURCES_DATA_SOURCE_ID=
AUTH_MODE=
HUB_ACCESS_KEY=
DEMO_MODE=false
실제 Secret은 절대 .env.example에 작성하지 마라.
현재 선택한 architecture에서 불필요한 변수는 제거해도 된다.
- TROUBLESHOOTING GUIDE
최소 다음 문제를 설명한다.
Integration은 만들었는데 Data Source가 안 보임
Token이 있는데 Unauthorized 발생
Data Source ID를 찾을 수 없음
Database는 있는데 Search에 안 나옴
Property 이름이 달라 데이터가 표시되지 않음
Complete 버튼을 눌렀는데 Notion이 변경되지 않음
Vercel에서는 동작하지 않지만 localhost에서는 동작함
Environment Variable 변경 후 반영되지 않음
Demo Data만 표시됨
Resource 버튼이 열리지 않음
- FINAL SELF-AUDIT
작업을 끝내기 전에 스스로 전체 구현을 다시 검토한다.
다음 질문에 답한다.
실제 Notion인가, mock인가?
READ가 실제로 되는가?
WRITE가 실제로 되는가?
Secret이 browser에 노출되는가?
모든 버튼이 작동하는가?
Notion이 끊기면 사용자가 알 수 있는가?
Demo와 Production이 구분되는가?
다른 이름의 Notion properties도 mapping 가능한가?
다른 [DOMAIN]에서도 재사용 가능한가?
Mobile에서 실제로 사용할 수 있는가?
README만 보고 비개발자가 설치할 수 있는가?
하나라도 NO라면 가능한 범위에서 수정한 후 완료한다.
- FINAL REPORT
구현 완료 후 다음 형식으로 간단하게 보고한다.
IMPLEMENTED
실제로 구현된 기능.
VERIFIED
실제로 테스트해서 성공한 기능.
NOT VERIFIED
환경 또는 credential 부족으로 테스트하지 못한 기능.
USER ACTION REQUIRED
사용자가 직접 해야 하는 것.
예:
Notion Integration 생성
Token 입력
Notion Data Source에 Integration 연결
Vercel Environment Variable 추가
KNOWN LIMITATIONS
현재 남아있는 한계.
테스트하지 않은 기능을 VERIFIED로 표시하지 마라.
- MOST IMPORTANT PRINCIPLE
최종 결과물은:
"AI가 보기 좋은 화면 하나 만들어준 데모"
가 되어서는 안 된다.
목표는:
실제 Notion 데이터를 기반으로
사용자가 오늘 해야 할 행동을 결정하고
웹에서 그 행동을 처리하면
Notion에도 실제로 반영되는
재사용 가능한 Action Hub
이다.
다시 말하면:
Notion = Source of Truth
Server = Secure Integration Layer
Action Hub = Execution Layer
그리고 전체 제품 흐름은:
DATA → PRIORITY → ACTION → PROGRESS
여야 한다.
UI를 만드는 것으로 끝내지 말고,
실제로 연결하고, 실제로 실행하고, 실제로 검증해라.