“문서 말고 템플릿을 만들어줘”라고 했더니 시작된 Notion 자동화 작업

📝 한줄 요약

커플의 사진과 기억을 함께 정리하는 Notion 템플릿을 AI 에이전트와 만들었습니다. 아이디어와 PRD 작성에서 끝내지 않고, Notion API로 DB·Relation·Formula·View·샘플 데이터를 구축하고 GPT Image 2로 22개 페이지의 비주얼까지 적용했습니다.

바쁘시면 이것만 읽어도 돼요:

• 긴 PRD를 만드는 것과 실제로 동작하는 Notion 템플릿을 만드는 것은 다른 작업이었습니다.

• AI가 요구사항을 잘못 이해했을 때는 문장을 더 길게 쓰기보다 “최종 산출물이 무엇인지”부터 다시 고정하는 것이 효과적이었습니다.

• Notion API가 잘하는 구조 생성과 앱 UI가 필요한 마무리를 분리하니 작업이 안정됐습니다.

• GPT Image 2는 Codex OAuth 전용 플러그인으로 연결해 별도 API 키 없이 사용했습니다.

• 결과를 만들었다는 응답보다, 생성한 객체를 다시 읽어 검증하는 단계가 더 중요했습니다.

🎯 이런 분들께 도움돼요

• Notion 템플릿 아이디어는 있지만 DB 구조에서 막히는 분

• AI에게 긴 기획서를 주면 완성품까지 만들어줄지 궁금한 분

• 코드를 직접 작성하지 않더라도 AI 에이전트로 실제 업무 도구를 만들고 싶은 분

• AI 결과물을 “그럴듯한 데모”가 아니라 재사용 가능한 제품으로 만들고 싶은 분

😫 문제 상황: 사진은 많은데, 이야기는 남지 않았다

휴대전화에는 함께 찍은 사진이 계속 쌓입니다. 그런데 몇 달 지나면 “이날 어디에 갔지?”, “왜 그렇게 웃었지?” 같은 맥락은 사라집니다.

그래서 커플이나 부부가 기억을 함께 쌓고 나중에 우연히 다시 만날 수 있는 Notion 템플릿을 만들기로 했습니다. 이름은 Things We Did · Couples Edition. 핵심 문장은 두 개였습니다.

휴대전화에 흩어진 사진을, 둘이 함께 살아온 이야기로 바꿔준다.

기억 하나를 1분 안에 저장하고, 몇 달 뒤 우연히 다시 만나는 템플릿.

처음에는 Notion AI에 붙여넣을 상세 PRD만 있으면 전체 페이지가 만들어질 것이라고 생각했습니다. 실제로는 여기서부터가 시작이었습니다.

🛠️ 사용한 도구

• AI 에이전트: Hermes Agent

• 모델·인증: OpenAI Codex OAuth

• 이미지 생성: GPT Image 2 (gpt-image-2-medium)

• 워크스페이스: Notion

• 자동화: Notion API, ntn CLI, Python

• 이미지 후처리: Pillow

🔧 작업 과정

1. “아이디어 3번”을 제품 문장으로 바꿨다

시작은 짧았습니다.

3번이 좋은거 같은데, 좀 더 구체화해서 제안해줘

AI와 대화하면서 단순한 커플 다이어리가 아니라 Shared Memory Atlas라는 방향을 잡았습니다. 기억을 날짜순으로만 저장하는 대신, 기억·사람·장소가 서로 연결되는 구조입니다.

원본 DB는 세 개로 제한했습니다.

• Memories: 함께한 일과 앞으로 하고 싶은 일

• People: 우리 둘, 가족과 친구

• Places: 집, 동네, 여행지

하고 싶은 일만 따로 관리하는 Wishlist DB는 만들지 않았습니다. Memories.상태를 하고 싶어요 → 계획했어요 → 함께했어요로 바꾸면 하나의 기억이 계획에서 추억으로 이동합니다.

여기서 배운 첫 번째 포인트는 기능을 추가하는 것보다 데이터가 이동하는 흐름을 먼저 정하는 편이 낫다는 것이었습니다.

2. 1,199줄짜리 PRD를 만들었지만, 결과는 “문서”였다

다음 요청은 Notion AI에 그대로 넣을 수 있는 수준의 명세였습니다.

해당 내용을 기반으로 노션 AI한테 입력해서 전체 페이지를 만들려고 해. 입력 PRD를 복사, 붙여넣기 할 수준으로 가이드를 작성해줘

AI는 Dashboard, DB 속성, Relation, Formula, Rollup, View, 샘플 데이터와 테스트 기준까지 포함한 1,199줄짜리 실행형 PRD를 만들었습니다. 반복해서 쓸 수 있도록 PRD 작성 규칙도 별도 스킬로 정리했습니다.

그다음 Notion에 PRD 페이지를 직접 생성했습니다. 기술적으로는 성공이었습니다. 하지만 제가 원한 결과는 아니었습니다.

제가 원한 것은 “완성품을 설명하는 문서”가 아니라 “직접 써볼 수 있는 완성품”이었기 때문입니다.

PRD 문서 페이지를 만들라고 하는게 아니라 PRD를 기반으로 전체 완성된 템플릿을 만들어줘

이 한 문장이 작업의 방향을 바꿨습니다.

AI에게 긴 설명을 주는 것보다 최종 산출물의 형태를 한 문장으로 고정하는 것이 중요했습니다.

• 잘못된 목표: 템플릿 구축 방법을 설명하는 PRD 페이지

• 수정한 목표: 실제 데이터를 넣고 View를 전환할 수 있는 Notion 템플릿

3. Notion API가 잘하는 일과 못하는 일을 분리했다

요구사항을 다시 고정한 뒤에는 API 중심으로 구축했습니다.

먼저 메인 Dashboard와 안내 페이지를 만들고, Memories·People·Places DB를 생성했습니다. 각 DB에는 Formula와 Rollup, 양방향 Relation을 넣었습니다. 샘플 데이터도 연결했습니다.

실제 생성 결과는 다음과 같습니다.

• 원본 DB 3개

• 샘플 레코드 14개

• 원본 DB View 15개

• Dashboard Linked View 8개

• Formula 4개

• Rollup 6개

다만 API가 모든 것을 매끄럽게 처리한 것은 아닙니다.

작년 오늘? Formula는 식 자체는 동작했지만, View API가 반환 타입을 unknown으로 판단해 필터 생성을 거부했습니다. 올해의 기억에서 쓰려던 동적 this_year 조건도 지원되지 않았습니다.

이때 AI가 속성 타입을 바꿔 성공한 것처럼 꾸미게 하지 않았습니다. Formula는 Formula로 유지하고, 지원되지 않는 필터만 후속 UI 작업으로 남겼습니다. this_year는 현재 연도의 고정 날짜 범위로 바꿨습니다.

이 과정에서 유용했던 원칙은 두 가지였습니다.

1. API 제한을 만났다고 요구사항을 몰래 낮추지 않는다.

2. 자동화할 수 있는 것과 앱에서 마무리할 것을 분리한다.

그리고 빌드 스크립트에는 체크포인트를 넣었습니다. 중간에 실패해도 이미 만든 DB나 레코드를 다시 생성하지 않고, 실패한 지점부터 이어갈 수 있게 했습니다. AI 자동화에서 멱등성은 어려운 단어지만 뜻은 간단합니다. 같은 작업을 다시 실행해도 복제품이 쌓이지 않는 것입니다.

4. “기능은 되는데 너무 심플하다”에서 이미지 시스템을 만들었다

핵심 구조가 완성된 뒤 Notion 앱에서 화면을 확인했습니다. 기능은 있었지만 상품처럼 보이지는 않았습니다.

각 페이지별로 분위기에 맞는 이미지가 있으면 추가해서 넣어줘. 디자인이 너무 심플한거 같아, 이미지 제작은 gpt image 2 를 활용했으면해

단일 커버 이미지를 모든 페이지에 복사하지 않고, 페이지 역할마다 다른 장면을 만들기로 했습니다. 아트 디렉션은 Soft Film Archive로 정했습니다.

• Cream, Navy, Stamp Red

• 아날로그 필름 그레인

• 부드러운 자연광

• 얇은 contact sheet 여백

• 이미지 속 문자·로고·워터마크 금지

• 식별 가능한 얼굴 배제

스타일을 통일하기 위해 이미지를 한 장씩 따로 생성하지 않았습니다. 먼저 여러 장면이 들어간 contact sheet를 만들고, 각 패널을 분리했습니다. 주요 페이지는 분리한 장면을 1500×600 필름 배너로 다시 구성했습니다.

5. API 키가 없었지만 Codex OAuth 경로를 찾았다

이미지 단계에서 한 번 더 막혔습니다. 일반 OPENAI_API_KEY가 없었고, 처음 확인한 FAL 경로도 인증이 준비돼 있지 않았습니다. 로그인된 ChatGPT 웹을 자동화하려 했지만 기존 Chrome 프로필을 안정적으로 제어하지 못했습니다.

여기서 다른 모델로 바꾸지 않고 인증 경로부터 다시 확인했습니다.

나는 codex 의 OAuth 로 구독하고 있으니깐, gpt image 2 로 진행할수 있도록해줘

Hermes 안에는 image_gen/openai-codex 이미지 생성 플러그인이 있었습니다. 이 플러그인을 활성화하고 provider를 openai-codex, 모델을 gpt-image-2-medium으로 지정하자 별도 API 키 없이 실제 생성이 성공했습니다.

이 순간이 가장 인상적이었습니다. “키가 없으니 불가능하다”에서 멈추지 않고, 사용 중인 구독 방식에 맞는 공식 경로를 코드와 설정에서 찾아 실제 결과로 검증했기 때문입니다.

6. 완료 메시지보다 Read-back을 믿었다

생성된 이미지는 다음 위치에 적용했습니다.

• 주요 페이지와 DB 커버 8개

• Memory 샘플 6개

• Place 샘플 6개

• People 샘플 2개

총 22개 Page Cover입니다. 여기에 Memories.사진, Places.장소 사진, People.사진 Files 속성 14개도 연결했습니다.

중요한 것은 “업로드에 성공했다”는 로그가 아니었습니다. Notion 객체 22개를 API로 다시 읽어 임시 업로드가 실제 file 커버로 변환됐는지 확인했습니다.

• Page/Database Cover Read-back: 22/22 통과

• 이미지 Files 속성: 14/14 통과

• 실패 객체: 0개

• Notion 앱 렌더링: 통과

AI 에이전트가 “완료했습니다”라고 말하는 것과 실제 시스템이 완료된 것은 다를 수 있습니다. 이번 작업에서는 생성 → Read-back → 앱 렌더링 확인을 완료의 조건으로 삼았습니다.

✅ 결과

Before vs After

ALT

Google 검색 페이지의 스크린샷

현재 남은 과제

핵심 구조와 이미지 시스템은 구축됐지만, 아직 “최종 판매 버전”이라고 부르지는 않으려고 합니다.

• 작년 오늘 View Formula 필터의 UI 마무리

• 빠른 기록 Button 3개

• Database Template 2개

• 모바일 실사용 검수

• 실제 커플 사용자 테스트

이 항목까지 검증한 뒤 Starter와 Complete 버전으로 나누는 것이 다음 단계입니다.

추천 이미지

• 문제 상황: 휴대전화 사진은 많지만 맥락이 없는 모습을 보여주는 이미지

• PRD와 실제 결과의 차이: Things We Did · Build PRD 페이지와 실제 Dashboard 비교 화면

• 작업 과정: Memories·People·Places Relation 구조 화면

• 디자인 개선: 이미지 적용 전 Dashboard와 적용 후 Dashboard 비교

• 결과: Gallery 카드와 Soft Film Archive 마스터 contact sheet

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 최종 산출물을 한 문장으로 고정하기
   “PRD를 작성해줘”와 “PRD를 기반으로 실제 템플릿을 만들어줘”는 완전히 다른 요청이었습니다.

2. API와 UI의 역할을 분리하기
   반복 가능한 DB·속성·Relation·데이터 생성은 API로, 지원되지 않는 UI 요소는 앱에서 마무리하는 편이 안정적이었습니다.

3. 실패 지점을 체크포인트로 남기기
   긴 자동화는 한 번에 성공하지 않습니다. 재실행할 때 복제품이 생기지 않게 만드는 것이 중요했습니다.

4. 사용 중인 인증 방식을 정확히 말하기
   “OpenAI를 쓰고 있다”보다 “Codex OAuth 구독을 쓰고 있다”가 훨씬 유용한 정보였습니다.

5. 결과를 다시 읽어 검증하기
   성공 로그만 보지 말고 실제 객체·속성·화면을 다시 확인해야 합니다.

이렇게 하면 안 돼요

1. 긴 PRD만 주면 AI가 완성품의 의미까지 알아서 판단할 것이라 기대하기

2. API가 지원하지 않는 기능을 비슷한 다른 속성으로 바꿔 완료한 것처럼 처리하기

3. 이미지를 한 장씩 무작정 생성해 페이지마다 스타일이 달라지게 만들기

4. AI가 출력한 숫자와 상태를 Read-back 없이 사례글에 쓰기

5. 아직 검증하지 않은 시간 절감이나 사용자 효과를 만들어내기

🌍 다른 업무에 적용한다면?

이 방식은 커플용 기억 템플릿에만 한정되지 않습니다.

• 가족의 연간 기억 아카이브

• 아기의 첫 1년 기록

• 장거리 커플의 만남과 다음 계획

• 여행지·사람·사진이 연결되는 여행 아카이브

• 제품 리서치의 근거·브랜드·인사이트 DB

구조는 비슷합니다. 핵심 객체를 3개 안팎으로 정하고, 객체 사이의 관계를 먼저 만든 다음, Dashboard는 “입력”보다 “다시 발견”에 초점을 맞추면 됩니다.

🚀 앞으로의 계획

1. 남은 Button·Database Template·Formula 필터 마무리

2. 모바일에서 기억 하나를 1분 안에 기록할 수 있는지 테스트

3. 실제 커플 사용자에게 일주일 동안 사용하게 하고 불필요한 필드 제거

4. Family, Friends, Travel Edition으로 동일 구조 확장

5. Starter와 Complete 상품 구성 및 사용 가이드 정리