Notion을 쓰다 보면 한 번쯤 이런 상황이 옵니다. 콘텐츠 아이디어는 노션 페이지에, 클라이언트 요청은 이메일에, 수정 피드백은 슬랙에 흩어져서 결국 어디서 뭘 찾는지 모르게 되는 그 상황. 저도 외주 프로젝트를 두세 개 동시에 돌리다 정확히 그 벽에 부딪혔습니다. Notion AI를 붙이고 나서 뭔가 달라졌는데, 일반적으로 'AI 붙이면 다 해결된다'고 알려져 있지만, 실제로 써보니 구조를 먼저 잡지 않으면 AI도 제 역할을 못한다는 게 솔직한 결론입니다.
데이터베이스 구조가 AI 품질을 결정한다
Notion AI를 처음 접하는 분들이 가장 많이 오해하는 부분이 여기입니다. AI 기능 자체보다 그 밑에 깔린 데이터베이스(Database) 설계가 결과물의 품질을 좌우한다는 점입니다. 여기서 데이터베이스란 Notion 안에서 행과 열 구조로 정보를 쌓아두는 공간으로, 엑셀 시트와 비슷하지만 페이지, 관계형 연결, 자동화 트리거까지 얹을 수 있는 확장형 구조입니다.
제가 직접 써봤는데, 에이전트(Agent)에게 아무리 좋은 지시를 줘도 데이터베이스 프로퍼티(Property)가 허술하면 생성 결과가 흐릿하게 나옵니다. 여기서 프로퍼티란 데이터베이스의 각 열 항목, 즉 '상태', '우선순위', '담당자' 같은 필드를 말합니다. 저는 썸네일 관리 데이터베이스를 만들 때 상태 옵션을 처음에 일곱 단계로 잡았다가 실제로 쓰는 단계는 세 개뿐이라는 걸 금방 깨달았습니다. 인디자인(In Design), 라이브(Live), 킬(Kill). 이 세 가지로 줄이고 나서 AI가 상태를 분류하는 정확도가 눈에 띄게 올라갔습니다.
관계형 데이터베이스(Relation Database)도 핵심입니다. 이건 두 개의 데이터베이스를 서로 연결해서 한쪽 항목이 다른 쪽 항목을 참조하게 만드는 기능입니다. 프로덕션 파이프라인(Production Pipeline) 데이터베이스와 썸네일 데이터베이스를 연결해두면 영상 하나를 기준으로 썸네일 제작 현황, 편집 진행 상태, 스폰서 브리프까지 한 화면에서 볼 수 있습니다. 이 구조를 잡아두고 AI에게 지시하니 "프로덕션 파이프라인에 연결해서 만들어줘"라는 말 한 마디로 관계가 자동 설정됐습니다. 솔직히 이건 예상 밖이었습니다.
Notion이 공개한 자료에 따르면 데이터베이스 연결 기능을 활용하는 팀의 워크플로우 완료 속도가 그렇지 않은 팀 대비 유의미하게 향상된다고 밝히고 있습니다(출처: Notion 공식 블로그).
에이전트 퍼스널라이징, 어디까지 해봤나
Notion AI의 에이전트 퍼스널라이징(Agent Personalizing) 기능은 쓸수록 양면이 있다는 느낌을 받습니다. 퍼스널라이징이란 AI 에이전트에게 나만의 목소리, 타겟 독자, 콘텐츠 기둥 같은 정보를 사전에 주입해서 매번 설명하지 않아도 일관된 결과물을 뽑아내게 하는 설정입니다.
일반적으로 에이전트 하나에 모든 걸 담으면 된다고 생각하는 분들도 있는데, 저는 실제로 써보니 에이전트 페르소나를 하나만 운영할 때의 한계가 뚜렷했습니다. 스레드(Threads) 콘텐츠용으로 설정해놓은 에이전트가 썸네일 카피 작업을 하면 톤이 어딘가 어색하게 나옵니다. 클라이언트 YouTube 채널 운영용으로 전환하면 다시 느낌이 달라져야 하는데, 지금은 매번 설정을 바꾸는 데 두세 번 메뉴를 파고들어야 합니다. 직관적이지 않습니다.
저는 이 문제를 Claude에서 퍼포먼스가 좋았던 프로젝트 지시서를 그대로 Notion 페이지로 옮기는 방식으로 우회했습니다. 에이전트 지시 페이지에 에이전트 개요(Agent Overview), 기억과 맥락(Memory and Context), 핵심 기능(Core Functions), 콘텐츠 기둥(Content Pillars)을 구조화해두면 AI가 호출할 때마다 이 페이지를 참조합니다. 이 방식으로 스레드 게시물 20개 생성을 시켜봤을 때 제가 직접 고쳐야 했던 비율이 처음보다 30% 이상 줄었습니다. 경험상 이건 꽤 의미 있는 수치입니다.
자동화(Automation) 설정도 여기서 빛을 발합니다. 자동화란 특정 조건이 충족될 때 미리 정해둔 동작을 자동으로 실행시키는 트리거 기능입니다. 예를 들어 클라이언트가 콘텐츠 아이디어를 '승인(Approve)' 상태로 바꾸면 제 이메일로 알림이 오도록 설정해두면, 클라이언트가 별도로 연락하지 않아도 제가 바로 스크립트 작업에 들어갈 수 있습니다. 구독자 12만 명 채널을 운영하면서 이 자동화 하나로 커뮤니케이션 누락을 거의 없앴습니다.
LLM(Large Language Model) 선택 기능도 주목할 만합니다. LLM이란 대규모 언어 모델, 즉 GPT나 Claude처럼 텍스트를 이해하고 생성하는 AI 모델을 말합니다. Notion AI 안에서 어떤 LLM을 쓸지 고를 수 있어서, 구독 중인 Claude나 ChatGPT 비용을 Notion 하나로 통합할 수 있다는 의견도 있습니다. 저는 Claude를 별도로 유지하는 편이지만, 비용 구조를 정리하고 싶은 분에게는 충분히 고려할 만한 옵션입니다.
한국 환경에서 추가로 챙겨야 할 것들
여기서부터는 영어권 가이드에서 거의 다루지 않는 이야기입니다. 한국어 IME(Input Method Editor) 환경에서 Notion AI를 쓸 때 발생하는 충돌 문제입니다. IME란 한국어, 일본어, 중국어처럼 자모나 획을 조합해서 문자를 완성하는 입력 방식 소프트웨어입니다. 한글은 자음과 모음이 조합되는 과정에서 입력이 완결되기 전 상태가 존재하는데, 이 타이밍에 슬래시 명령이 발동하면 자모가 분리되거나 명령이 오작동하는 현상이 생깁니다.
제가 직접 겪어봤는데, 한글 입력 중에 슬래시(/) 명령을 치려다가 자모 분리 오류가 나서 명령이 깨지는 상황이 반복됐습니다. 영문 환경에서는 전혀 문제없이 작동하는 기능이 한국어 입력 중에는 예상치 못한 충돌을 일으킵니다. 이건 Notion이 아직 한국어 IME 환경을 충분히 고려하지 않은 부분이라고 봅니다.
비슷한 맥락에서 저는 이전 콘텐츠 협업 도구 외주에서 인라인 AI 글쓰기 기능을 설계할 때 이 문제를 직접 다뤘습니다. 처음 설계에서는 고스트 텍스트(Ghost Text) 미리보기 없이 즉시 덮어쓰기 방식을 택했는데, 고스트 텍스트란 AI가 제안하는 내용을 실제 본문에 반영하기 전에 흐릿하게 미리 보여주는 방식입니다. 이 방식으로 갔더니 한 달에 '내가 쓴 내용이 사라졌다'는 컴플레인이 8건이 들어왔습니다.
Tab 수락, Esc 거절 패턴으로 바꾼 후 동일 컴플레인이 0건으로 떨어지고, AI 글쓰기 기능 사용 빈도는 주 3.2회에서 7.5회로 올랐습니다. 그 경험을 바탕으로 외주 4건에 Tab 수락, Esc 거절, Cmd+Z 실행 취소 3종 단축키를 기본값으로 강제하는 가이드를 디자인 시스템 문서에 추가했고, 지금도 재사용 중입니다.
한국 환경에서 Notion AI 혹은 인라인 AI 어시스턴트를 설계하거나 운영할 때 챙겨야 할 핵심 포인트를 정리하면 다음과 같습니다.
- 한국어 자모 조합 중에는 슬래시 명령이 발동하지 않도록 IME 완성 후 활성화 처리
- 고스트 텍스트 미리보기 적용으로 덮어쓰기 방지
- Tab 수락 / Esc 거절 / Cmd+Z 실행 취소 단축키를 기본값으로 고정
- 존댓말과 평어 사이 톤 옵션 제공 (도메인마다 선호 톤이 다름)
국내 생성형 AI 도구 사용률은 꾸준히 올라가는 추세입니다. 한국지능정보사회진흥원(NIA)이 발표한 자료에 따르면 국내 기업의 AI 도입률은 매년 증가하고 있으며 특히 콘텐츠 제작과 업무 자동화 분야에서 활용도가 높아지고 있습니다(출처: 한국지능정보사회진흥원).
Notion AI는 데이터베이스 설계를 잘하면 잘할수록 AI가 더 잘 작동하는 구조입니다. 도구 자체보다 구조 설계에 시간을 더 쓰는 게 맞다는 결론입니다. 한국 사용자라면 여기에 IME 호환성 문제까지 미리 인지하고 들어가야 시행착오를 줄일 수 있습니다. AI가 글을 써주는 시대이지만, 어떤 정보를 어떤 구조로 쌓아두느냐는 여전히 사람의 몫입니다. 그 설계를 먼저 잡고 나서 AI를 올리는 순서가 맞습니다.
참고: https://www.youtube.com/watch?v=ODbTqcor84g