Claude / ChatGPT / Cursor를 병행해서 사용하다 보면,
대화 로그가 서비스마다 분단되어 있고, 게다가 나중에 찾기도 어렵다. 단말기도 AI 계정도 제각각이다 - 그래서 YouTube의 한 채널에서 소개된 정보를 참고하여, Notion에 'AI 대화 로그' DB를 하나 만들고,
각 AI에서 MCP를 통해 읽고 쓸 수 있도록 했다 - DB 스키마 설계도 레코드 등록도
AI 스스로 하게 하므로, 이쪽에서는 자연어로 부탁하기만 하면 된다 - '어느 AI와의 대화인지'를 열(column)로 가지고 있으면,
AI를 넘나드는 지식의 인계가 가능하다 (Cursor에게 "Claude와 대화한 내용을 Notion에서 읽어줘"라고 부탁할 수 있다)

나는 인프라 중심의 엔지니어로 일하고 있으며,

• 서버(CentOS / Ubuntu, Proxmox VE와 VMware ESXi, AWS 혼재) 운영
• CVE가 나올 때마다의 영향 조사 및 패치 적용 트리아지(Triage)
• AWS 주변 설정, Terraform 등 운영 스크립트 코딩

과 같은 작업을, **Claude / ChatGPT / Cursor(2개 단말, 복수 계정)**를 구분해서 사용하며 진행하고 있습니다.

이 체제로 한동안 지내다 보니 곤란해진 점이 이것입니다.

"그 CVE 조사, 어느 AI와 어디서 이야기했더라?"

• 커널 CVE의 영향 범위는 Claude와 논의했다
• 검증 스크립트는 Cursor로 작성했다
• Postfix 주변 상담은 ChatGPT에서도 Claude에서도 했다

……라는 상태가 되어, 지식이 3개의 서비스에 흩어져 있고, 게다가 횡단 검색할 수단이 없다. 더욱 곤란한 것은, Cursor로 작업하고 있을 때 "Claude와의 대화에서 결정한 방침"을 참조하고 싶은데, 복사해서 붙여넣기(copy-paste) 할 수밖에 없다는 점입니다.

그래서, AI의 외부에 공통의 기억 저장소를 하나 만든다는 방침을 세웠습니다. 그것이 Notion의 「AI 대화 로그」 DB입니다.

구성 방식은 다음과 같습니다.

┌─────────┐ ┌──────────┐ ┌────────┐
│ Claude │ │ ChatGPT │ │ Cursor │
└────┬────┘ └────┬─────┘ └───┬────┘
...

포인트는, Notion 측은 '단순한 DB'일 뿐이라는 점입니다. AI 고유의 메커니즘을 사용하지 않기 때문에, 내일 또 새로운 AI가 추가되어도 그곳에 MCP를 연결하면 같은 범주에 들어올 수 있습니다.

우선 하나의 AI로 작동시켜 봅니다. Claude(Web/데스크톱)의 경우, 설정 → 커넥터(Connector)에서 Notion을 추가하고 OAuth 인증을 하기만 하면 됩니다.

연결이 되었는지 확인하는 것은 이렇게 묻는 것이 가장 빠릅니다.

notion에 접속할 수 있는지 테스트해줘

Claude가 notion-get-users 등을 호출하여 워크스페이스의 사용자 정보를 반환해 준다면 통신 성공입니다.

주의사항 (나중에 반드시 막히는 부분)

Notion 측의 「커넥트 관리(Connection management)」에서 대상 페이지/DB에 해당 인테그레이션(Integration)을 연결해 두어야 합니다. 읽기만 가능하고 쓰기에서 실패한다면, 대부분 구문 문제가 아니라 권한 문제입니다(후술).

이 부분이 가장 편한 점인데, 스키마를 직접 설계해서 하나하나 만들 필요가 없습니다. 목적을 전달하면 제안해 주며, 대략적인 틀을 수동으로 만들어 두면 나중에 AI가 알아서 수정해 줍니다. 직접 만드는 것이 귀찮다면

여기서 조사한 내용의 이력을 Notion에서 데이터베이스로 만들어 관리하고 싶어.
프라이빗 영역에 만들어줘. 스키마 안이 있다면 제안해 줘.

실제로 돌아온 안은 이것이었습니다 (거의 그대로 채택). 애초에 나는 지금까지 Notion을 사용해 본 적이 없으므로, 맡겨버렸습니다.

Notion MCP는 SQL 라이크한 DDL로 DB를 만들 수 있어서, AI는 내부적으로 이런 요청을 보내고 있는 모양입니다.

CREATE TABLE (
"제목" TITLE,
"날짜" DATE,
...

나중에 열을 추가하고 싶다면, 이것도 대화로 추가할 수 있습니다 (실제로 "AI" 열이나 "프로젝트" 열은 나중에 추가했습니다).

ADD COLUMN "AI" SELECT('Claude':orange, 'ChatGPT':green, 'Cursor':blue);
ADD COLUMN "프로젝트" RICH_TEXT;

**기록의 입도 (Granularity)**는 「1대화(세션) = 1레코드」로 설정했습니다. 메시지 단위로 하면 너무 세세해서 나중에 찾기 어렵고, 일 단위로 하면 너무 뭉뚱그려지기 때문에 스레드 단위가 딱 적당했습니다.

Claude에는 과거 채팅을 검색하는 도구(`conversation_search` / `recent_chats`)가 있어서,

이 프로젝트에 있는 과거 대화들을 전부 이 DB에 등록해줘

라고 부탁하면, 과거 스레드를 하나씩 레코드로 만들어 줍니다. 제 경우에는 약 40개의 스레드가 (시간이 좀 걸리고 토큰도 소비되지만) 한꺼번에 등록되었습니다.

다만 실제 운용하면서 알게 된 제약 사항이 있습니다.

과거로 거슬러 올라가 등록하기 위해 검색할 수 있는 범위는 「현재 있는 프로젝트의 스코프(Scope) 내」뿐입니다. 다른 프로젝트의 대화는 해당 프로젝트를 열고 동일한 요청을 반복해야 합니다.

• `conversation_search`가 반환하는 것은 **관련도가 높은 파편 (청크 (Chunk))**이지, 완전한 축어록이 아닙니다. 따라서 본문에는 「대화 발췌 (취득 가능한 범위)」라는 설명을 덧붙여 붙여넣는 것이 정직한 방법입니다.

• 드물게 안전 필터(Safety Filter)의 영향으로 내용을 가져올 수 없는 과거 스레드도 있다고 합니다 (제 경우 1건 해당).

여기서부터가 본론입니다. 같은 Notion DB에 다른 AI들도 연결합니다.

Notion 커넥터(또는 MCP 서버 추가)를 통해 동일한 Notion 워크스페이스를 인증합니다. 읽기뿐만 아니라 **쓰기 권한 (Write Permission)**을 허용하는 것을 잊지 마세요.

Cursor는 MCP 설정 파일에 원격 MCP 서버를 작성하기만 하면 됩니다. 프로젝트 직하의 .cursor/mcp.json (또는 글로벌 ~/.cursor/mcp.json)에:

{
"mcpServers": {
"notion": {
...

처음 실행 시 브라우저에서 OAuth 인증이 진행되며, 이후에는 Cursor의 Agent로부터 `notion-search`, `notion-fetch`, `notion-create-pages` 등을 사용할 수 있게 됩니다.

UI나 엔드포인트(Endpoint) 사양은 변경되기 쉬우므로, 실제로 설정할 때는 각 서비스의 최신 문서를 확인하시기 바랍니다 (본 기사는 2026년 7월 기준입니다).

Cursor를 두 대의 단말기에서 서로 다른 계정으로 사용하더라도, Notion 측의 워크스페이스가 같다면 동일한 DB를 보게 됩니다. 「어느 단말기에서 작업했는가」는 본질적으로 중요하지 않으며, 지견(Insight)이 어디에 집약되어 있는가만이 중요합니다. 다만 일단 「Cursor」, 「Cursor2」와 같이 AI 이름을 구분하여 어느 단말기에서 왔는지 알 수 있도록 했습니다.

모든 AI가 동일한 DB에 기록하게 되면 당연히 다음과 같은 상황이 발생합니다.

「이 레코드, 누가 (어떤 AI가) 작성한 거지?」

따라서 판별용 열(Column)을 만듭니다. 저는 최종적으로 이 3종 세트로 결정했습니다.

그리고 각 AI에게 운용 규칙을 한 줄의 커스텀 지시(Custom Instruction)로 넣어둡니다.

대화를 Notion의 「AI 대화 로그」 DB에 등록할 때는,
반드시 「AI」 열에 자신의 이름(Claude / ChatGPT / Cursor / Cursor2)을 입력할 것.

Claude라면 프로젝트의 커스텀 인스트럭션(Custom Instruction), ChatGPT라면 커스텀 지시(Custom Instructions), Cursor라면 .cursorrules / Rules에 적어두면 이후에는 자동으로 채워집니다.

참고로 초기에는 「Cursor: ~」, 「ChatGPT: ~」와 같이 제목 앞에 접두사(Prefix)를 붙여 운용했으나, 제목으로 판별하는 것은 검색이나 필터링에 취약하므로 전용 열로 분리하는 것을 추천합니다.

이 단계까지 오면 당초의 목적을 달성할 수 있습니다.

Cursor로 코드를 작성하고 있을 때:

Notion의 「AI 대화 로그」 DB에서 CVE-XXXX-XXXXX 관련 레코드를 검색해서,
결정된 대응 방침을 바탕으로 검증 스크립트를 작성해줘

Cursor는 Claude와의 대화에서 결정된 방침을 Notion에서 읽어와, 그에 맞춰 코드를 작성합니다. 복사-붙여넣기(コピペ)를 통한 문맥 전달 과정이 필요 없어진 것이 체감상 가장 좋습니다. 기록이 어딘가로 사라져서 여러 AI의 대화 기록을 찾아다닐 필요도 없습니다.

ChatGPT에게 상담할 때:

Notion의 'AI 대화 로그' DB에서, 프로젝트='취약점 대응' 레코드를 전체적으로 읽고,
미완료된 태스크만 목록으로 만들어줘

Claude에게 인계할 때:

Notion의 대화 로그 중, AI=Cursor의 레코드를 보고,
지난주 작성한 스크립트의 다음 부분부터 작업을 하고 싶어

요컨대, Notion DB가 'AI 공통의 장기 기억'이 되고, 각 AI는 그곳에 읽고 쓰는 '단기 기억 워커' 역할을 맡게 되는 것입니다. AI를 교체해도 지식은 남아있다는 의미입니다.

이런 식으로 여러 AI의 대화가 하나의 테이블에 모입니다 (내용은 샘플로 대체했습니다).

'AI' 열에서 색깔로 구분되어 있기 때문에, 어떤 지식을 어떤 AI와 만들었는지 목록으로 추적할 수 있습니다. Notion 측에서는 'AI'로 그룹화한 뷰나, '토픽'으로 필터링한 뷰를 만들어 두면 편리합니다.

insert_content 등의 명령어로 'No approval received' 같은 오류가 발생하면, SQL이나 속성 이름(プロパティ名)을 의심하기 전에 Notion 측의 통합 연결 설정을 확인해 보세요. 제 경우, DB 쪽 설정을 '여러 AI에서 쓰기 가능'으로 변경하니 바로 해결되었습니다.

Notion MCP로 페이지를 만들 때 날짜는 단순히 `