Notion CLI 사용법 2026 ntn 설치 로그인 API 자동화 적용

2026년 5월 15일 기준 Notion CLI의 실행 명령은 ntn이고, 공식 문서는 설치, 로그인, API 요청, data source, 파일 업로드, Workers를 주요 기능으로 설명한다. 여기서는 공식 문서 흐름에 실제 로컬 적용 경험을 붙여서, 설치 후 어디부터 자동화에 연결할지까지 정리한다.

설치 명령만 보면 아주 짧다. curl -fsSL <https://ntn.dev> | bash 한 줄이면 된다. 그런데 실제 자동화에 붙이기 시작하면 바로 다른 질문이 나온다.

로그인은 어떻게 유지하지. 기존 Notion integration token은 버려야 하나. 데이터베이스와 data source는 뭐가 다르지. 에이전트나 cron에서 돌릴 때 keychain은 믿어도 되나. CLI를 깔았는데 결국 API 호출을 또 직접 짜고 있으면 뭔가 이상하지 않나.

이번 글은 Notion CLI를 처음 설치하는 사람보다, 이미 Notion API나 자동화 스크립트를 조금이라도 쓰고 있는 사람에게 더 맞다. 단순 설치법보다 “기존 자동화를 CLI로 바꿀 때 어디부터 바꿔야 덜 터지는가”에 초점을 둔다.

실제로 2026년 5월 15일에 Obsidian으로 Notion Inbox를 가져오는 notion-inbox-sync 스크립트의 Notion 조회 계층을 ntn 기반으로 바꿔봤다. 결과적으로 전체를 갈아엎을 필요는 없었다. DB 조회와 페이지 블록 읽기만 CLI 백엔드로 빼고, 파일 저장과 중복 방지 로직은 그대로 두는 쪽이 훨씬 안전했다.

먼저 답을 잡으면

Notion CLI를 적용할 때 첫 목표는 “Notion 자동화를 전부 새로 만들기”가 아니다. 기존 Notion API 호출부 중 인증과 요청 조립이 지저분한 부분을 ntn api로 옮기는 것이다.

가장 먼저 바꿀 만한 곳은 읽기 중심 작업이다. users/me 확인, page 조회, block children 조회, database나 data source query처럼 실패해도 원본 데이터가 망가지지 않는 영역부터 시작하면 된다.

반대로 page 생성, property 수정, archive 처리, 파일 첨부, Workers 배포는 한 단계 뒤로 미루는 편이 좋다. 이 작업들은 실패했을 때 Notion 쪽 상태를 실제로 바꿀 수 있다. CLI가 편하다고 바로 쓰기 작업부터 맡기면 자동화가 아니라 원격 손가락이 된다.

이런 상황이면 먼저 볼 만하다

이미 Notion API를 curl, Python requests, Node SDK로 조금이라도 쓰고 있다면 Notion CLI는 바로 검토할 만하다. 특히 스크립트마다 Authorization 헤더, Notion-Version 헤더, JSON body 생성 코드가 반복되고 있다면 효과가 크다.

Obsidian, 블로그 아이디어 DB, 개인 CRM, 회의록 DB처럼 Notion에서 데이터를 가져와 다른 시스템에 저장하는 workflow에도 잘 맞는다. 이 경우 CLI는 Notion 읽기 계층을 담당하고, 로컬 파일 쓰기나 후처리는 기존 스크립트가 맡으면 된다.

팀 환경에서는 조금 다르게 봐야 한다. 개인 로그인으로 ntn login을 해두면 편하지만, 팀 자동화나 CI에서는 개인 keychain에 의존하면 안 된다. 이때는 NOTION_API_TOKEN을 명시적으로 주입하고, token 권한과 보관 위치를 운영 문서에 남겨야 한다.

Notion CLI가 하는 일

Notion CLI는 터미널에서 Notion 인증, Workers 관리, API 요청, data source 작업, 파일 업로드를 처리하는 공식 도구다. 명령 이름은 ntn이다. 공식 overview 문서 기준으로 ntn은 Notion에 인증하고, Notion Workers를 배포/관리하고, 터미널에서 API 요청을 실행하는 용도다.

여기서 제일 실용적인 부분은 ntn api다. 기존에는 curl이나 Python requests로 Authorization 헤더와 Notion-Version 헤더를 직접 붙였다. ntn api를 쓰면 CLI 인증이나 NOTION_API_TOKEN을 사용해 인증 헤더를 처리하고, API path만 넘겨서 요청을 만들 수 있다.

예를 들어 사용자 정보를 확인하는 요청은 이렇게 간단해진다.

ntn api v1/users/me

페이지를 조회할 때도 API path만 넘기면 된다.

ntn api v1/pages/$PAGE_ID

물론 CLI가 모든 코드를 지워주는 마법은 아니다. 응답 JSON을 어떻게 해석할지, 어떤 항목을 저장할지, 실패하면 어디로 fallback할지는 여전히 내 자동화의 책임이다. 그러니까 Notion CLI는 “Notion API를 안 배워도 되는 도구”라기보다 “API 호출과 인증을 덜 지저분하게 만드는 도구”에 가깝다.

설치는 짧지만 위치를 정해야 한다

공식 설치 문서에서 권장하는 설치 명령은 다음과 같다.

curl -fsSL <https://ntn.dev> | bash

macOS와 Linux의 x64, arm64를 지원하고, Windows는 아직 지원 예정으로 안내되어 있다. npm 설치도 가능하다.

npm install --global ntn

다만 npm 방식은 Node.js 22 이상과 npm 10 이상이 필요하다. 이미 Node 버전이 뒤엉킨 개발 환경이라면 설치 스크립트 방식이 더 단순할 수 있다.

회사 노트북이나 권한이 제한된 Mac에서는 기본 설치 경로가 막힐 수 있다. 이럴 때는 사용자 홈 아래에 설치하는 편이 편하다.

curl -fsSL <https://ntn.dev> | NTN_INSTALL_DIR="$HOME/.local/bin" bash

설치 후에는 버전을 확인한다.

ntn --version

이번 로컬 적용에서는 ~/.local/bin/ntn에 설치했고, 버전은 0.14.0이었다. PATH에 ~/.local/bin이 안 들어가 있으면 셸에서 ntn을 못 찾을 수 있다. 자동화 스크립트라면 NOTION_CLI_BIN 같은 환경변수로 CLI 경로를 명시하거나, $HOME/.local/bin/ntn, /usr/local/bin/ntn, /opt/homebrew/bin/ntn 순서로 탐지하게 만드는 것이 안전하다.

로그인은 두 가지 방식으로 나뉜다

일반 사용자는 ntn login으로 로그인하면 된다.

ntn login

이 명령은 브라우저를 열고 Notion 워크스페이스 접근을 승인하게 한다. 공식 인증 문서 기준으로 브라우저에 뜬 verification code와 터미널에 찍힌 code가 일치하는지 확인한 뒤 승인해야 한다. 로그인 토큰은 macOS Keychain이나 Linux Secret Service 같은 OS credential store에 저장된다.

브라우저를 열 수 없는 원격 머신이나 컨테이너에서는 흐름이 조금 다르다. ntn login을 실행하면 URL, verification code, ntn login poll 명령을 출력한다. 사용자는 다른 브라우저에서 URL을 열어 승인하고, 원래 머신에서 ntn login poll을 실행해 토큰을 받아온다.

이번 로컬 실행도 이 방식이었다. 터미널에 출력된 URL을 Chrome에서 열고, verification code가 일치하는지 확인한 뒤 Authorize를 눌렀다. 그다음 ntn login poll을 실행하니 Logged in to workspace JT로 완료됐다.

하지만 스크립트나 CI에서는 매번 브라우저 로그인을 할 수 없다. 이때는 NOTION_API_TOKEN을 쓰는 편이 낫다.

export NOTION_API_TOKEN=ntn_xxx...
ntn api v1/users/me

공식 문서 기준으로 NOTION_API_TOKEN은 keychain에 저장된 로그인보다 우선한다. 그래서 같은 CLI라도 사람의 workspace login과 자동화용 token을 분리해서 쓸 수 있다. 이게 중요하다. 개인 터미널은 ntn login을 쓰고, cron이나 봇은 token을 환경변수로 받게 하는 식으로 나눌 수 있다.

적용 전에는 doctor부터 본다

설치와 로그인이 끝났다면 바로 자동화에 붙이지 말고 ntn doctor를 먼저 보는 편이 좋다. 이 단계에서 CLI, workspace, token 상태를 한 번에 확인해야 뒤에서 이상한 곳을 덜 의심하게 된다.

ntn doctor

이번 로컬 검증에서는 CLI version, config, default workspace, token valid가 통과했다. Workers는 아직 workspace에서 enabled 상태가 아니라 warning이 떴다. 이건 ntn api 기반 동기화에는 문제가 없었지만, Workers 배포까지 하려면 별도 확인이 필요한 상태다.

이 차이를 구분해야 한다. Notion CLI를 쓴다고 해서 곧바로 Workers까지 쓸 수 있다는 뜻은 아니다. API 요청은 token이 유효하면 잘 돌 수 있고, Workers는 워크스페이스 권한이나 기능 활성화 상태가 따로 걸릴 수 있다.

운영 체크는 이렇게 잡으면 된다.

확인 항목	명령	통과 기준
설치 확인	`ntn --version`	버전 출력
로그인 확인	`ntn doctor`	Token valid 통과
API 확인	`ntn api v1/users/me`	user JSON 출력
워크스페이스 지정	`NOTION_WORKSPACE_ID=... ntn api v1/users/me`	원하는 workspace로 실행
자동화 token 확인	`NOTION_API_TOKEN=... ntn api v1/users/me`	bot/user 응답

자동화에서 가장 좋은 테스트는 작은 GET 요청이다. 페이지 생성이나 삭제 같은 변경 작업보다 v1/users/me나 특정 page 조회로 시작하자. 손가락 운동도 하기 전에 저장 버튼부터 누르면 안 된다. CLI도 마찬가지다.

API 요청 문법은 네 가지 기호만 기억하면 된다

ntn api는 body field, query parameter, header를 inline으로 만들 수 있다. 공식 API requests 문서에서 핵심 문법은 네 가지다.

문법	의미	예시
`path=value`	body string	`parent[page_id]=abc123`
`path:=json`	body JSON type	`archived:=true`
`name==value`	query parameter	`page_size==100`
`Header:Value`	request header	`Accept:application/json`

문자열은 =를 쓴다. boolean, number, array, object, null처럼 JSON 타입을 살리고 싶으면 :=를 쓴다. query parameter는 ==를 쓴다. 이 구분만 기억해도 삽질이 많이 줄어든다.

예를 들어 검색은 이렇게 쓸 수 있다.

ntn api v1/search query=roadmap

페이지를 archive 상태로 바꿀 때는 PATCH와 JSON boolean을 같이 쓴다. 쓰기 작업은 method와 타입이 동시에 맞아야 하므로, 읽기 요청보다 더 엄격하게 확인하는 편이 좋다.

ntn api "v1/pages/$PAGE_ID" -X PATCH archived:=true

중첩된 property를 다룰 때는 bracket notation이 안전하다.

ntn api v1/pages \
  parent[page_id]="$PARENT_PAGE_ID" \
  properties[Name][title][0][text][content]="CLI-created page"

본문이 복잡하면 inline으로 우겨 넣지 말고 JSON 파일이나 stdin을 쓰는 편이 낫다. 특히 page 생성처럼 property 구조가 길어지는 요청은 파일로 빼야 리뷰와 재실행이 쉬워진다.

ntn api v1/pages < create-page.json

ntn api는 body가 있으면 기본적으로 POST로 보낸다. PATCH나 DELETE 같은 다른 method가 필요하면 -X로 명시해야 한다. 이 규칙을 놓치면 “왜 POST로 나갔지?”가 된다. 개발자의 하루가 짧아지는 소리다.

data source는 database와 같은 말이 아니다

Notion API를 예전부터 쓴 사람일수록 여기서 한 번 헷갈린다. 공식 data sources 문서 기준으로 data source는 Notion database 아래에 있는 page table이다. database 아래에 data source가 있고, data source를 query해서 page 목록을 가져오는 구조로 이해하면 된다.

data source ID를 찾는 방법은 두 가지다. 하나는 database를 API로 조회해서 data_sources 배열의 id를 확인하는 방법이다.

ntn api v1/databases/<database-id>

다른 하나는 Notion 앱에서 database settings로 들어가 Manage data sources를 열고, data source 메뉴에서 Copy data source ID를 누르는 방식이다. 자동화 코드에 넣기 전에는 두 방법으로 찾은 ID가 같은 대상인지 한 번 비교해두는 게 좋다.

data source를 조회할 때는 ntn datasources query를 쓸 수 있다. 단순 목록 확인이나 제한된 필터 테스트에는 이 전용 명령이 가장 읽기 쉽다.

ntn datasources query <data-source-id> --limit 50

필터가 필요하면 공식 필터 shape을 JSON으로 넘긴다.

ntn datasources query <data-source-id> \
  --filter '{"property":"Status","select":{"equals":"Open"}}'

더 복잡한 정렬, property 제한, pagination이 필요하면 ntn api로 내려가는 편이 낫다. 전용 명령은 빠른 확인용, ntn api는 운영 자동화용이라고 나누면 판단이 편하다.

ntn api v1/data_sources/<data-source-id>/query \
  filter:='{"and":[{"property":"Status","select":{"equals":"Open"}},{"property":"Priority","number":{"greater_than_or_equal_to":2}}]}' \
  sorts:='[{"property":"Priority","direction":"descending"}]' \
  page_size:=25

여기서 중요한 운영 판단이 있다. 기존 자동화가 아직 v1/databases/{id}/query 기반이라면 바로 data source 전용 명령으로 바꾸지 않아도 된다. 먼저 ntn api로 기존 endpoint 호출만 CLI에 태우고, 그다음 database와 data source 모델을 분리하는 것이 안전하다.

실제로 notion-inbox-sync를 바꿀 때도 이 순서를 택했다. 기존 스크립트의 저장 로직, 중복 검사, 파일명 생성, 요약 handoff는 그대로 두고, Notion 조회 부분만 ntn api v1/databases/{id}/query와 ntn api v1/blocks/{page_id}/children로 바꿨다. 이렇게 해야 문제가 생겨도 어디서 깨졌는지 바로 보인다.

기존 자동화에 붙일 때는 백엔드 옵션을 만든다

기존 스크립트를 CLI로 바꿀 때 제일 위험한 방식은 “requests 코드를 다 지우고 ntn으로 교체”하는 것이다. 겉보기엔 깔끔하지만, 로그인 실패나 PATH 문제 한 번에 전체 동기화가 멈춘다.

더 안전한 방식은 백엔드 옵션을 두는 것이다.

--notion-backend auto
--notion-backend ntn
--notion-backend requests

auto는 ntn이 있으면 먼저 CLI를 시도하고, 실패하면 기존 token 기반 requests 방식으로 fallback한다. ntn은 CLI만 강제로 검증할 때 쓴다. requests는 기존 방식으로 되돌릴 때 쓴다.

이번 로컬 적용에서는 이 방식을 썼다. auto 실행 결과 notion_backend: ntn으로 조회가 돌았고, 오늘치 Notion 항목 8개를 확인했다. 새로 저장할 항목은 없어서 saved: 0, 이미 동기화된 항목은 skipped: 8이었다.

이런 출력이 있어야 운영이 편하다.

{
  "mode": "link-note",
  "notion_backend": "ntn",
  "notion_backend_requested": "auto",
  "saved": 0,
  "skipped": 8,
  "checked": 8
}

CLI 전환에서 진짜 중요한 건 “성공했다”보다 “어떤 백엔드로 성공했는지”를 남기는 것이다. 나중에 로그를 보면 ntn을 탄 건지, fallback으로 requests를 탄 건지 바로 알아야 한다. 로그가 없으면 자동화는 조용히 똑똑한 척하다가 조용히 다른 길로 샌다.

파일 업로드는 ntn files로 따로 본다

Notion CLI에는 ntn files도 있다. 공식 file uploads 문서 기준으로 ntn files create는 로컬 파일을 받아 File Upload object를 만들고, 파일 bytes를 보내고, upload를 complete한 뒤 upload ID를 출력한다.

로컬 파일 업로드는 이렇게 한다.

ntn files create < ./photo.png

외부 URL을 import할 수도 있다.

ntn files create --external-url <https://example.com/photo.png>

업로드 목록 확인은 다음 명령이다.

ntn files list

주의할 점은 업로드 자체와 페이지에 첨부하는 작업이 다르다는 것이다. 파일 업로드가 uploaded 상태가 된 뒤, 그 upload ID를 file object로 page, block, page icon, page cover, files property 등에 붙여야 한다. 블로그 이미지나 PDF를 Notion에 붙이는 자동화를 만들 때 이 차이를 모르면 “업로드는 됐는데 페이지에는 안 보이는” 상태가 된다.

처음 도입 단계에서는 files 기능을 뒤로 미뤄도 된다. Inbox sync나 page 조회 자동화부터 안정화한 뒤, 이미지 업로드가 필요한 workflow에서 ntn files를 붙이는 것이 낫다.

언제 Workers까지 볼까

Notion Workers는 TypeScript로 만든 작은 프로그램을 Notion에 붙여 sync, tool, webhook 같은 확장을 만드는 기능이다. 공식 overview에는 ntn workers new, ntn workers deploy, ntn workers list가 핵심 명령으로 나온다.

ntn workers new
ntn workers deploy
ntn workers list

다만 모든 Notion CLI 도입이 Workers 도입으로 이어져야 하는 것은 아니다. 로컬 파일 시스템에 Obsidian 노트를 쓰거나, 개인 PC의 cron으로 Notion Inbox를 가져오는 정도라면 로컬 스크립트가 더 단순하다.

Workers는 Notion 안에서 실행되는 확장이 필요할 때 검토하는 편이 맞다. 예를 들어 Notion webhook에 반응해서 특정 작업을 실행하거나, Notion workspace 안에서 tool처럼 호출되는 흐름이 필요하면 Workers가 후보가 된다.

이번 notion-inbox-sync 전환에서는 Workers를 쓰지 않았다. 이유는 단순하다. 목표가 Notion 안에서 무언가를 실행하는 것이 아니라, Notion에서 가져온 자료를 로컬 Obsidian vault에 저장하는 것이었기 때문이다. 로컬 파일 쓰기와 no-focus 운영 원칙을 유지해야 하므로, CLI 백엔드 전환만으로 충분했다.

적용 순서 체크리스트

처음부터 모든 기능을 쓰려고 하면 복잡해진다. 순서를 나누면 부담이 확 줄어든다.

ntn --version으로 설치 확인
ntn login 또는 NOTION_API_TOKEN으로 인증 준비
ntn doctor로 token valid 확인
ntn api v1/users/me로 작은 GET 요청 확인
기존 자동화의 Notion 호출부만 찾기
requests 백엔드를 남긴 채 ntn 백엔드 추가
auto|ntn|requests 옵션으로 비교 실행
실행 로그에 실제 사용 백엔드 기록
data source 전환은 별도 단계로 분리
Workers와 files는 필요 workflow가 생겼을 때 추가

이 순서의 핵심은 “CLI를 붙이는 것”과 “업무 구조를 바꾸는 것”을 분리하는 데 있다. CLI 설치는 하루에 끝난다. 하지만 자동화 운영 기준은 한 번 꼬이면 오래 간다.

특히 개인 자동화에서는 fallback이 중요하다. ntn이 로그인 문제로 실패해도 기존 NOTION_TOKEN 방식으로 동기화가 계속되면 하루 작업이 멈추지 않는다. 반대로 --notion-backend ntn을 강제로 실행하면 CLI만 검증할 수 있다. 둘 다 필요하다.

자주 생기는 실수

첫 번째 실수는 ntn login만 하면 모든 자동화가 안정된다고 보는 것이다. 로컬 터미널에서는 맞을 수 있지만, cron, CI, 원격 서버에서는 keychain 접근이 다르게 동작할 수 있다. 자동 실행은 NOTION_API_TOKEN 방식까지 같이 설계하는 편이 낫다.

두 번째 실수는 database ID와 data source ID를 섞는 것이다. ntn datasources query에는 data source ID가 필요하다. database URL에서 바로 보이는 ID를 넣었는데 안 되면, 먼저 database를 조회해서 data_sources 배열을 확인해야 한다.

세 번째 실수는 inline syntax에서 =와 :=를 섞는 것이다. 문자열은 =, boolean이나 number 같은 JSON 타입은 :=를 쓴다. archived=true와 archived:=true는 같은 마음으로 쓴 명령처럼 보여도 API body에서는 다르게 해석될 수 있다.

네 번째 실수는 body가 들어간 요청이 기본 POST로 바뀐다는 점을 잊는 것이다. 기존 page를 수정하려면 -X PATCH를 명시해야 한다. 이걸 빼먹으면 endpoint에 따라 엉뚱한 method로 나가거나 실패한다.

다섯 번째 실수는 CLI 전환과 구조 개편을 한 번에 하는 것이다. database query를 data source query로 바꾸고, 저장 포맷도 바꾸고, 파일 업로드까지 붙이면 어디서 깨졌는지 찾기 어렵다. 먼저 ntn api로 기존 endpoint를 그대로 호출하고, 그다음 구조를 옮기는 편이 낫다.

FAQ

Notion CLI를 쓰면 기존 Notion API token은 필요 없나

항상 그렇지는 않다. 개인 터미널에서는 ntn login으로 keychain 기반 인증을 쓸 수 있다. 하지만 CI, cron, 서버 자동화에서는 NOTION_API_TOKEN이 더 적합한 경우가 많다. 공식 문서도 unattended use에는 personal access token을 권장하는 흐름으로 설명한다.

Windows에서도 바로 쓸 수 있나

공식 설치 문서 기준으로 macOS와 Linux의 x64, arm64를 지원하고, Windows 지원은 coming soon으로 안내되어 있다. Windows 환경에서는 npm 설치나 WSL 같은 우회 흐름을 따로 확인해야 한다.

database query와 data source query 중 무엇을 써야 하나

새로 만드는 자동화라면 data source 개념을 기준으로 설계하는 편이 좋다. 다만 기존 자동화가 이미 database endpoint로 안정적으로 돌고 있다면, 먼저 ntn api로 기존 endpoint를 CLI에 태우고 이후 data source 전환을 별도 단계로 나누는 것이 안전하다.

Workers부터 배워야 하나

아니다. Notion CLI의 첫 실용 포인트는 ntn api다. Notion 안에서 실행되는 확장, webhook, tool 형태가 필요해질 때 Workers를 보면 된다. 로컬 Obsidian vault나 파일 시스템으로 가져오는 자동화라면 Workers 없이도 충분히 시작할 수 있다.

안전하게 첫 테스트를 하려면 무엇부터 하나

ntn --version, ntn doctor, ntn api v1/users/me 순서가 좋다. 그다음 읽기 전용 page 조회나 data source query를 실행한다. 수정, 삭제, archive, 파일 첨부는 로그와 fallback을 만든 뒤에 진행하는 편이 낫다.

이어서 묶을 주제

이 글은 Notion CLI 자체보다 “기존 자동화에 어떻게 붙일까”에 초점을 둔 글이다. 다음 단계로는 Obsidian Inbox sync, Notion data source 설계, Notion Workers, AI 에이전트용 CLI 인증 패턴을 따로 나눠볼 수 있다.

특히 Obsidian을 같이 쓰는 사람이라면 ntn api로 Notion Inbox를 읽고, 로컬에서는 no-focus 방식으로 markdown 파일을 쓰는 구조가 잘 맞는다. Notion 앱을 열지 않아도 되고, Obsidian 포커스를 빼앗지 않으며, 실패해도 로컬 로그로 추적할 수 있다.

마무리

Notion CLI는 Notion 자동화를 더 깔끔하게 만드는 도구다. 설치는 짧고, ntn api는 꽤 편하다. 특히 인증 헤더와 API version 처리를 CLI에 맡길 수 있다는 점이 좋다.

하지만 Notion CLI를 적용할 때 제일 먼저 볼 것은 새 기능 목록이 아니다. 기존 자동화에서 Notion API 호출 경계가 어디인지, 실패했을 때 fallback할 길이 있는지, 사람 로그인과 봇 token을 어떻게 나눌지다.

내 기준에서 첫 적용 범위는 명확하다. DB 조회, page 조회, block children 조회처럼 읽기 중심의 API 호출부터 ntn으로 옮긴다. 그다음 data source 전용 명령을 검토한다. 파일 업로드와 Workers는 정말 필요한 workflow가 생겼을 때 붙인다.

이렇게 가면 Notion CLI는 “새 장난감”이 아니라 운영 도구가 된다. 그리고 운영 도구는 화려할 필요가 없다. 어제 돌던 자동화가 오늘도 돌고, 실패했을 때 어디서 실패했는지 보이면 된다.

Notion CLI 사용법 2026 – ntn 설치부터 자동화 적용까지 막히는 지점 7가지