지피터스 사례글 1,543개를 Notion에 넣고 내 읽기 순서를 만든 과정

한 줄 요약: 지피터스 23기 사례게시글 1,543개를 Notion DB로 모으고, “주제가 비슷한가?”가 아니라 “내 업무에 어떤 방식을 가져올 수 있는가?”로 읽을 글을 고르는 구조를 만들었습니다.

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

• 23기 스터디 태그 21개에서 게시글 연결 1,578건을 수집했습니다.

• 여러 태그에 걸친 같은 글을 canonical 원문 ID로 합쳐 고유 게시글 1,543개를 만들었습니다.

• 1,293개였던 기존 Notion DB에 실제 신규 글 250개를 추가했습니다.

• URL만 바뀐 기존 글 2개는 중복 생성하지 않고 원래 행을 갱신했습니다.

• 마지막에는 키워드 일치가 아니라 업무 직접성·전이 가능성·근거/검증 가치·산출물 적합성·새로움으로 읽을 글을 선별했습니다.

• 중요한 결론은 이것입니다. DB는 보관함이 아니라, 내 기준으로 질문할 수 있게 만드는 분석 표면입니다.

🎯 이런 분께 도움이 됩니다

• 커뮤니티 사례글이 많아질수록 오히려 무엇을 읽어야 할지 모르겠는 분

• 좋은 글을 북마크만 해두고 실제 업무에는 잘 가져오지 못하는 분

• AI에게 “나한테 맞는 글 골라줘”라고 했지만 제목이 비슷한 글만 추천받은 분

• 사례글을 Notion에 쌓는 데서 끝내지 않고 검색·비교·재사용하고 싶은 분

• AI가 수집한 DB가 빠짐없이 맞는지 확인하는 방법이 궁금한 분

😫 문제 상황: 글이 부족한 게 아니라 너무 많았습니다

시작 요청은 짧았습니다.

23기 스터디 사례 게시글 DB 로 정리해줘

하지만 “게시글을 DB로 정리한다”는 말 안에는 서로 다른 두 문제가 들어 있었습니다.

첫 번째는 수집 문제입니다. 지피터스 23기에는 21개 스터디 태그가 있고, 게시글 목록은 동적으로 더 불러와집니다. 같은 글이 여러 스터디 태그에 걸릴 수도 있습니다. 화면에 보이는 카드만 복사하면 누락이 생기고, 태그별 목록을 그대로 합치면 중복이 생깁니다.

두 번째는 선택 문제입니다. 1,543개를 빠짐없이 모아도 사람이 전부 읽을 수는 없습니다. 최신순이나 좋아요순은 “많이 본 글”을 알려줄 뿐, “내 업무에 옮겨 쓸 수 있는 글”을 알려주지 않습니다.

그래서 목표를 다음처럼 바꿨습니다.

커뮤니티 피드
→ 검증 가능한 사례글 DB
→ 내 업무 기준의 후보 목록
→ 본문을 읽고 판단한 읽기 순서

🛠️ 사용한 도구

• Hermes Agent: 수집·정리·Notion 등록·검증 흐름 실행

• Python: URL manifest, 상세 데이터, canonical ID, 로컬 master 관리

• Notion API / ntn CLI: 속성이 있는 DB와 읽기 좋은 행 본문 생성

• JSON·CSV: Notion과 독립적으로 다시 검증할 수 있는 로컬 원본

코드는 수단이었습니다. 핵심은 데이터를 어떤 단위로 세고, 추천을 어떤 기준으로 판단하느냐였습니다.

🔧 작업 과정 1: 태그별 목록을 합치기 전에 관계부터 보존했습니다

23기 스터디 태그 21개에서 확인된 게시글 연결은 1,578건이었습니다. 하지만 고유 게시글은 1,543개였습니다.

태그–게시글 연결: 1,578건
고유 게시글:       1,543개
차이:                 35건

여기서 35건을 “중복이라 필요 없음”으로 지워버리면 어떤 글이 여러 스터디와 연결됐는지 잃게 됩니다. 반대로 1,578건을 모두 행으로 만들면 같은 글이 여러 번 생깁니다.

그래서 두 층으로 나눴습니다.

1. 수집 단계에서는 태그 → 게시글 URL 관계를 그대로 보존한다.

2. Notion 행은 canonical 원문 ID 하나당 하나만 만든다.

3. 한 글에 연결된 여러 스터디 태그는 multi-select 속성으로 합친다.

작은 설계 차이지만, 나중에 “AI 결과물 검수와 지식관리 양쪽에 걸친 글”을 찾을 수 있게 해줍니다. 중복 제거가 정보를 버리는 작업이 아니게 됩니다.

🔧 작업 과정 2: URL이 아니라 원문 ID를 글의 주민등록번호로 썼습니다

업데이트 전 Notion DB에는 1,293개가 있었습니다. 현재 공개 목록과 비교하니 URL 기준 신규 후보는 252개였습니다.

처음 보면 252개를 모두 추가하면 될 것 같습니다. 실제로 상세 페이지의 canonical 원문 ID를 확인하니 결과는 달랐습니다.

2개는 새 글이 아니라 URL이 바뀐 기존 글이었습니다. URL만 중복 키로 쓰면 같은 글이 두 행으로 생깁니다.

그래서 URL은 “현재 위치”, 원문 ID는 “글의 정체성”으로 다뤘습니다. 새 글 250개만 추가하고, 겹친 2개는 기존 행의 URL과 속성을 갱신했습니다.

이 규칙은 커뮤니티 글뿐 아니라 상품 페이지, 리뷰, 문서 아카이브에도 그대로 적용됩니다. URL은 바뀝니다. 정체성 키가 따로 있어야 합니다.

🔧 작업 과정 3: 표 한 줄보다, 열어서 읽을 수 있는 페이지를 만들었습니다

DB 속성에는 제목, 작성자, 게시일, 스터디 태그, 주차, 요약, 사용 도구, 결과·배움, 반응 수, 원문 URL을 넣었습니다.

하지만 사례글의 가치는 본문에 있습니다. 원문 HTML을 긴 일반 텍스트 한 덩어리로 넣으면, 수집은 완료돼도 읽기는 실패합니다.

각 행의 본문은 다음 순서로 구성했습니다.

💡 한눈에 보기
게시글 정보
원문 링크
원문의 제목·문단·목록·인용·코드·이미지 구조

긴 신규 글 5개를 다시 읽어 확인했습니다. 첫 블록은 모두 💡 한눈에 보기였고, 소제목과 목록이 유지됐습니다. 확인한 글은 최대 97개 구조화 블록으로 저장돼 있었습니다.

“행이 생성됐다”와 “사람이 읽을 수 있다”는 다른 완료 조건이었습니다.

🔧 작업 과정 4: 1,543개 중 ’나한테 맞는 글’을 고르는 기준을 만들었습니다

개인화 추천에서 가장 위험한 지름길은 제목 키워드입니다. 제목에 리서치, Notion, PPT가 있다고 나에게 유용한 것은 아닙니다. 반대로 도메인이 전혀 달라도 검증 방법이나 운영 구조를 그대로 가져올 수 있습니다.

그래서 적합도를 다섯 축으로 나눴습니다.

키워드 검색은 첫 후보를 줄이는 데만 썼습니다. 최종 판단 전에는 요약, 사용 도구, 결과·배움, 본문을 읽었습니다.

등급은 세 개면 충분했습니다.

• Tier A — 지금 읽기: 현재 업무에 바로 적용 가능

• Tier B — 워크플로우 개선: 도메인은 달라도 실행 방식을 가져올 수 있음

• Tier C — 선택적 영감: 흥미롭지만 당장 적용성은 낮음

실제로 높게 본 사례

1) AI 결과물 검수를 위한 워크스페이스 세팅

마지막 답변만 평가하지 않고 원본 자료, 전문가 루브릭, 역할별 에이전트, 중간 검증을 하나의 하네스로 묶습니다. 리서치 결과를 DB나 Wiki에 넣기 전에 어떤 검수 구조가 필요한지 보여줍니다.

가져올 것: 결과물 검수 체크리스트가 아니라 원본 → 주장 → 중간 검수 → 지식 승격 파이프라인.

2) 비개발자가 AI로 업계 리포트를 “제품 실행 과제”로 바꾼 하루

업계 자료를 요약하는 데서 멈추지 않고 출처·해석·액션을 분리합니다. 확인 전 자료는 팀의 확정 지식과 분리하고, 담당자와 완료 기준이 있는 검증 과제로 바꿉니다.

가져올 것: 리서치 DB의 각 행을 사실 / 해석 / 다음 행동으로 나누는 속성 설계.

3) 주장 17개 중 믿을 수 있는 건 2개였습니다

원본 25건에 출처·품질·시점·검증 필드를 붙인 뒤, 주장 17개 중 독립 출처로 교차 확인된 것은 2개였다고 기록합니다. 같은 보도자료를 두 매체가 옮긴 것은 독립된 두 근거가 아니라는 점도 분리합니다.

가져올 것: 출처 개수보다 독립 출처인가, 언제의 사실인가, 교차 확인됐는가를 필드로 강제하는 방식.

4) AI가 네이버에 막혔을 때 오히려 신뢰가 생긴 이유

접근할 수 없는 사이트를 억지로 우회하거나 데이터를 지어내지 않고, 막힌 경계를 공개한 뒤 확인 가능한 공식 자료로 전환합니다. 결과물도 브라우저에서 검색과 필터를 직접 검증합니다.

가져올 것: 수집 실패, 대체 출처, 재확인 필요를 정상적인 상태값으로 남기는 운영 방식.

이 네 글의 주제는 서로 다릅니다. 하지만 공통 메커니즘은 같습니다.

원본을 남긴다
→ 사실과 해석을 분리한다
→ 확인하지 못한 상태를 숨기지 않는다
→ 다음 행동으로 연결한다

이것이 제목 키워드보다 강한 “나와의 적합성”이었습니다.

🧩 막혔던 점: Notion은 맞았는데 검증 자료가 틀렸습니다

신규 글 등록은 250개 모두 성공했습니다. 그런데 최종 검증기를 돌리자 다음 오류가 났습니다.

KeyError: '주차'

원인은 미묘했습니다. Notion에 등록할 때는 주차 분류기가 실행됐지만, 검증기가 읽는 업데이트 후보 JSON에는 같은 파생 필드가 저장되지 않았습니다.

Notion 화면만 보면 문제가 없어 보입니다. 하지만 로컬 증거물과 Notion이 같은 값을 가진다는 보장은 깨진 상태였습니다.

해결은 새 규칙을 하나 더 만드는 것이 아니었습니다. Importer가 쓰는 동일한 주차 분류기를 후보 252개에 적용했습니다. 그 뒤 검증기를 다시 실행해 252개 모두 주차가 채워졌고, 전체 1,543개의 주차·판정 근거 누락이 0개임을 확인했습니다.

여기서 배운 것은 단순합니다.

생성 코드와 검증 코드가 같은 파생 규칙을 공유하지 않으면, 둘 중 하나는 언젠가 다른 진실을 말합니다.

✅ 결과

숫자만 맞춘 것이 아니라 다음 집합도 대조했습니다.

• Notion의 고유 원문 ID 1,543개 = 로컬 master의 원문 ID 1,543개

• 현재 공개 목록의 URL 집합 = 로컬 master의 URL 집합

• 신규 등록 결과 250개 = 실제 신규 canonical ID 250개

Notion DB는 여기에서 확인할 수 있습니다.

• 23기 스터디 사례게시글 DB

💬 이번 작업에서 배운 팁

효과적이었던 것

1. 행 수와 ID 집합을 둘 다 확인하기

   1,543개와 1,543개가 같아도 서로 다른 글이 섞일 수 있습니다. canonical ID 집합까지 같아야 합니다.

2. URL을 정체성으로 쓰지 않기

   URL은 바뀔 수 있습니다. 원문 ID가 겹치면 새 행이 아니라 갱신 대상입니다.

3. 추천 전에 사용자 기준을 짧게 쓰기

   역할, 반복 산출물, 검증 요구, 선호 도구, 현재 관심사를 먼저 적어야 추천 근거가 생깁니다.

4. 키워드는 검색에만, 판단은 본문으로 하기

   제목은 후보를 찾는 데 좋습니다. 전이 가능한 방법은 본문을 읽어야 보입니다.

5. ’가져올 한 가지’를 적기

   좋은 글이라는 평보다 검증 필드, 게이트, 프롬프트, DB 속성처럼 재사용할 것을 하나 고르는 편이 유용합니다.

이렇게 하면 안 됩니다

• 첫 화면에 보이는 글만 모으고 전체 23기라고 부르기

• 여러 태그의 행 수를 고유 게시글 수로 보고하기

• URL 후보 수를 실제 신규 글 수로 보고하기

• Notion 생성 성공 로그만 보고 완료라고 말하기

• 제목이 비슷하다는 이유만으로 개인 추천하기

• AI가 쓴 적합도 점수를 근거 없이 정밀한 숫자처럼 공개하기

🌍 다른 업무에 적용한다면

이 구조는 사례게시글에만 쓰이지 않습니다.

• 경쟁사 벤치마크: 모델 URL 대신 고유 모델 ID를 두고, 중복 SKU와 리뉴얼 URL을 분리

• VOC 분석: 리뷰를 수집한 뒤 내 상품 의사결정에 연결되는 문제·상황·근거 수준으로 선별

• 논문 아카이브: 인기 논문보다 현재 연구 질문으로 옮길 수 있는 방법·데이터·평가 기준을 우선

• 시장 리포트: 사실·해석·권고를 분리하고, 각 주장에 시점과 독립 출처 상태를 기록

• 팀 위키: 많이 저장한 문서가 아니라 다음 업무에서 재사용된 문서를 높은 가치로 판단

핵심은 같습니다. 먼저 원본 집합을 정확히 만들고, 그 위에서 개인 기준을 적용해야 합니다. 수집과 추천을 한 번에 하면 누락과 편향을 구분하기 어렵습니다.

🚀 다음 계획

현재 개인 적합도 분석은 로컬 프로토타입입니다. 아직 1,543개 행 전체에 Tier와 판정 이유를 Notion 속성으로 일괄 반영하지 않았습니다.

다음 단계에서는 다음 속성을 추가할 수 있습니다.

• 나와의 적합도: Tier A / B / C

• 판정 이유: 직접성 / 전이성 / QA / 산출물 / 새로움

• 가져올 한 가지: 체크리스트, 프롬프트, 스키마, 검증법

• 읽기 우선순위: 지금 / 이번 주 / 보류

• 판정일·프로필 버전: 어떤 기준으로 언제 판단했는지

• 내 피드백: 유용함 / 보통 / 아님

마지막 내 피드백이 중요합니다. 추천은 한 번에 완성되는 점수가 아니라, 실제로 읽은 뒤 기준을 고치는 루프에 가깝습니다.

📋 재사용 프롬프트

1. 커뮤니티 글을 검증 가능한 DB로 만들기

[커뮤니티/기수]의 사례게시글을 전체 범위로 수집해 Notion DB로 만들어줘. 먼저 현재 태그와 수집 범위를 확인하고, 태그별 URL 관계를 보존해. 행은 canonical 원문 ID 기준으로 중복 제거하되 복수 태그는 유지해. 제목·작성자·게시일·요약·사용 도구·결과·원문 URL을 속성으로 만들고, 본문은 제목·문단·목록·인용·코드·이미지 구조를 유지해. 완료 후 행 수뿐 아니라 원문 ID 집합, 필수 속성 누락, 중복, 실패 목록을 다시 읽어 검증해줘.

2. 나에게 맞는 글 선별하기

이 DB에서 내 현재 업무에 맞는 글을 골라줘. 먼저 역할, 반복 산출물, 근거·검증 기준, 주로 쓰는 도구, 현재 관심사를 5줄 프로필로 정리해. 후보는 업무 직접성 35%, 워크플로우 전이성 25%, 근거·재현성 20%, 산출물 체계 적합성 15%, 새로움 5%로 판단해. 키워드는 후보 검색에만 쓰고, 최종 추천 전에는 본문이나 충분한 요약을 읽어. Tier A/B/C로 나누고 각 글마다 ’왜 맞는지’와 ’가져올 한 가지’를 적어줘. 인기나 최신성을 적합도로 착각하지 마.

3. 추천을 실제 업무로 옮기기

Tier A 글 각각에서 재사용 가능한 메커니즘 하나를 뽑아줘. 내 현재 업무에 적용할 때 필요한 입력, 처리 단계, 산출물, 검증 기준, 실패 조건으로 바꾸고, 이번 주에 실행 가능한 최소 실험 하나를 제안해줘. 원문이 보여준 사실과 네가 제안한 적용 아이디어를 구분해 표시해.