맥락 분류기

2025.08.08

by 김효진
Frame 22.png

이번에 이력서와 포트폴리오를 업데이트하면서, 그동안 정리해두었던 메모들과 머릿속에 흩어져 있던 생각들을 꺼내어 구조화하고, 맥락을 부여해 글로 풀어내는 데 가장 많은 시간을 들였습니다.


이 과정에서 특히 정보를 찾고 분류하는 데 시간이 많이 소요되었습니다.
‘정리해 두었던 메모들과 흩어진 생각들을 꺼낸다’는 작업 안에는 아래와 같은 네 가지 단계가 포함되어 있었기 때문입니다:


1. 포트폴리오와 이력서에 담고자 하는 시기의 자료들을 모두 탐색합니다.

구글 드라이브, 노션 등에서 관련 문서와 파일을 찾습니다.

2. 여기서 두 가지 맥락으로 정보를 탐색합니다.

무엇이 있는지 모르기 때문에 전체를 훑어보는 경우

필요한 정보가 있어서 특정 내용을 찾는 경우

3. 흩어져 있는 자료들 중 하나의 주제로 묶을 수 있는 것들을 선별합니다.

4. 선별된 자료 중에서 이력서나 포트폴리오에 활용하기 적절한 카테고리에 표시를 남겨 둡니다.


표면적 현상이 ‘자료 찾는 데 시간이 너무 오래 걸린다’는 점이고, 원인이 ‘자료가 흩어져 있어서’ 라면, 본질은 ‘정보를 저장할 때 탐색을 전제로 한 구조(=인덱스)가 없었다’는 점일 것입니다.


인간의 기억 방식은 ‘맥락 기반’인데, 도구들은 주로 ‘카테고리 기반’입니다.
예를 들어, “그때 리텐션 문제로 A를 고민하던 중 만든 자료”는 떠오르지만 “2025_A_abtest”는 떠오르지 않습니다. 결국 중요한 건 ‘자료 그 자체’보다 ‘자료에 연결된 의도와 맥락’을 기억할 수 있는 구조인데, 그게 빠져 있었습니다.


그렇다면 정보를 찾고 분류하는 데 많은 시간이 소요된다는 문제를 당장 해결할 수 있는 방법은 없을까?




AI를 활용해 나만의 정리 보조 인덱서(indexer) 만들기

처음 머릿속에 떠오르는 아이디어는 단순했습니다.

1. Notion의 여러 페이지 중 하나에 문서를 모두 작성한 후, 완료 신호를 주면

2. GPT가 사전에 정의된 Property 구조에 맞춰 결과 값을 정리한 뒤,

3. 해당 문서의 각 Property에 자동으로 결과를 입력한다.


좀 더 체계적인 접근방식이 필요했습니다.
우선 하나의 실험용 Notion 페이지를 생성하고, 당장 필요한 자료를 중심으로 실험해보기로 했습니다.


그래서 다음과 같은 실행 플랜을 세웠습니다:

1. Notion에 새로운 페이지를 생성하고, 자동화를 위한 DB 구조와 권한 설정을 설계한다.

2. Notion API로 자동화 툴인 Make와 연동한다.

3. Notion에서 어떤 트리거를 기준으로 자동화 시나리오를 실행할지 결정한다.

4. OpenAI API 키를 발급받아, Make 시나리오 안에 OpenAI 노드를 구성한다.

5. Notion node → OpenAI node로 어떤 데이터를 어떻게 전달할지 정의한다.

6. OpenAI node → Notion node로 결과값을 전달하고, 노션 페이지의 Property에 업데이트한다.




1. Notion DB 구조 설계

추후 검색 + 필터링 + 기억 회상 + 포트폴리오 활용을 고려해 기능적 최소셋 Property를 구성했습니다.

Frame 453.png




3. Notion에서 어떤 트리거를 기준으로 자동화 시나리오를 실행할지 결정

3-1. 노션 유료 플랜을 사용하는 경우

Notion DB에는 Automation 기능이 제공되며, trigger 설정도 포함돼 있습니다.

자동화를 구성할 때 주목해야 할 포인트는, Notion에 있는 DB는 Notion 안에 저장돼 있고, Make.ai는 Notion과는 별개인 외부 AI 도구라는 점입니다.

그렇기 때문에 필요한 게 바로 trigger 입니다.


전체 플로우를 정리하면 다음과 같습니다:

1. Notion DB에 새로운 글을 작성한다면,

2. Notion의 Automation 기능에서 trigger를 설정해둔 상태라면,

3. 이 트리거가 Make.ai로 Webhook 요청을 보낸다.

4. Make.ai는 그 요청을 받고,

5. 전달된 정보(예: 페이지 ID 등)를 통해 다시 Notion에 데이터 요청을 보낸다.

6. 받아온 데이터를 기반으로 → GPT에게 요청한다.

7. GPT가 응답한 결과를 → 다시 Notion 페이지의 Property에 업데이트한다.



3-2. 노션 무료 플랜을 사용하는 경우

저는 노션 무료 플랜을 사용 중이기 때문에, Make에서 “일정한 주기(특정한 시간)을 가지고 확인하는 방식(Polling)” 방식을 사용했습니다. Make는 직접 변경 사항을 감지하는 방식은 지원하지 않기 때문에, 정해진 시간마다 Notion DB를 들여다보며 변화가 있는지를 확인하는 구조로 동작합니다.


전체 플로우를 정리하면 다음과 같습니다:

1. Make가 1분 / 5분 / 1시간에 한 번씩 Polling할 수 있도록 설정한다.

2. Notion DB에서 특정 조건(예: 상태 = '작성 완료')인 문서들만 가져온다.

3. 가져온 문서의 상태를 '분류 중'으로 변경한다.

4. 해당 문서를 GPT에게 전달하고, 응답 결과를 받는다.

5. 결과를 Notion 페이지에 업데이트한다. 이때 상태도 함께 '분류 완료'로 변경한다.


왜 상태값을 여러 단계로 나눴는가?

처음에는 체크박스를 활용해, 문서를 ‘요청됨’ 상태로 표시하는 방식으로 자동화를 시작했습니다.
하지만, 이 방식은 Make가 실행될 때마다 이미 처리된 문서까지 계속 반복해서 가져오는 문제가 생겼습니다.

Frame 465.png Notion DB에 ‘GPT 실행여부’라는 Property 추가


해결 방법: GPT 실행여부에 따른 상태값을 4단계로 나눈다

Frame 466.png

이렇게 하면:

중복 실행을 방지할 수 있고,

현재 문서가 어느 단계에 있는지 명확하게 시각화할 수 있었습니다.


자동화에서 ‘분류 중’ 상태가 필요한 이유

Make를 통해 Notion 데이터를 주기적으로 조회하는 방식으로 자동화를 구현할 경우, 중복 처리 문제가 발생할 수 있습니다.

예시 상황:

첫 번째 Polling

- 문서 A가 작성 ‘완료 상태’로 감지됨

- GPT에게 전달되어 처리 진행 중

두 번째 Polling (1분 후)

- 문서 A는 여전히 ‘작성 완료’ 상태

- 다시 감지되어 중복으로 처리됨

이러한 문제를 방지하려면, Make가 감지한 즉시 상태값을 ‘분류 중’으로 변경해, 다음 실행 주기에서 같은 문서가 다시 처리되지 않도록 하는 것이 효과적이었습니다.




5. Notion → OpenAI로 데이터 전달 정의

Frame 466.png 문제 1


문제 1 : Notion 모듈은 Block 단위로 콘텐츠를 응답한다

의도한 액션

Notion DB에서 updated_at 기준으로 새로 변경된 문서를 감지하고, 해당 문서의 본문 전체를 GPT에 전달해 분류 작업을 수행합니다.


문제 발생 원인

Notion 문서는 특성상 본문이 Block 단위로 구성되어 있으며, 각 Block에는 텍스트뿐 아니라 스타일, 리스트 여부, 체크박스, 헤딩 등 다양한 메타데이터가 포함되어 있습니다. 이러한 구조로 인해 각 Block을 개별적으로 GPT에 전달하게 되면, GPT는 문서 전체 맥락을 이해하지 못한 채 단편적인 정보만을 받아들이게 됩니다. 결과적으로 본문 전체를 기반으로 한 정확한 결과물을 생성하기 어려워지는 문제가 발생했습니다.


해결 방안

Text Aggregator와 같은 병합 모듈을 활용해 여러 Block을 하나의 텍스트로 묶은 후 GPT 요청 → 효율성 개선합니다.



Frame 466.png 문제2

문제 2 : 상태 변경에 대한 조건 미지정

의도한 액션

Notion DB에서 updated_at 기준으로 변경된 문서를 감지하고, ‘작성 완료’ 상태의 문서를 Notion 모듈이 가져오는 동시에 해당 문서의 상태를 자동으로 ‘분류 중’으로 업데이트합니다.



문제 발생 원인

Watch 모듈에 조건 필터를 설정하지 않아 ‘작성 완료’ 상태 외에 ‘작성 중’ 상태의 문서까지 모두 감지되면서 불필요한 문서까지 포함되는 문제가 발생했습니다.

작성 완료 상태의 문서를 Notion 모듈이 감지하여 불러오는 것까지는 정상적으로 작동했지만, 해당 문서의 상태를 자동으로 ‘분류 중’으로 업데이트하는 구조가 누락되어 있었습니다.

Frame 466.png 문제 2의 해결 방안

해결 방안

불필요한 데이터 호출을 막기 위해 Watch 모듈 자체가 아닌 Edge에 조건 필터(상태 ≠ 작성 완료)를 설정, 정확한 문서만 선별해 가져오도록 개선합니다.

감지된 문서의 상태값을 자동으로 ‘분류 중’으로 변경하기 위해, 특정 row을 업데이트할 수 있는 Update a Database Item 모듈을 추가하여 설정합니다.




6. OpenAI node → Notion node로 결과값 전달, 노션 페이지의 Property 업데이트 + 상태값 변경


의도한 액션

OpenAI 노드가 생성한 결과를 Notion 노드가 해당 문서의 각 Property에 자동으로 입력하고, 상태값 역시 ‘분류 완료’로 함께 업데이트합니다.


문제 1 : OpenAI node에서 받은 결과는 기본적으로 "텍스트”이다

문제 발생 원인

OpenAI 노드는 응답을 단일 텍스트 문자열(string) 형태로 반환합니다. 하지만 Notion의 각 Property는 구조화된 개별 필드로 구성되어 있기 때문에, 해당 텍스트를 그대로 넣을 경우 각 Property에 자동으로 분리되어 매핑되지 않았습니다.


Frame 466.png 문제 1의 해결 방안

해결 방안

OpenAI에게 응답을 단순 텍스트가 아니라, 각 항목이 명확하게 key-value로 나뉜 JSON 구조로 작성하라고 프롬프트에 명시합니다.



문제 2 : OpenAI의 결과값은 텍스트 덩어리에 불과하다

문제 발생 원인

OpenAI 노드가 반환하는 결과는 구조화된 JSON처럼 보이지만, 실제로는 단순한 텍스트 덩어리에 불과해 Notion의 각 Property와 직접 매핑할 수 없었습니다.


Frame 466.png 문제 2의 해결 방안

해결 방안

중간에 Set 또는 Text Parser/JSON 파서 모듈을 추가하여, OpenAI 응답 텍스트에서 필요한 필드를 개별적으로 추출하고 Notion의 각 Property에 매핑되도록 설정합니다.



최종 결과 테스트

최종 테스트를 위해 Notion DB에 본문 4개를 추가한 뒤 자동화를 실행했습니다. 그 결과, 모든 Property가 정확하게 채워졌고, 상태값 역시 모두 ‘분류 완료’로 정상 처리되었습니다.




7. 마무리

이번 작업을 통해 자동화 플로우를 직접 설계하고 구현해보는 과정을 경험했습니다.

비개발자 입장에서 자동화 툴에 대한 기초 지식이나 동작 원리에 대한 이해가 부족해 처음에는 많이 헤맸지만, 흐름을 따라가며 직접 테스트해보니 구조가 점차 눈에 들어오기 시작했습니다.

무엇보다 좋았던 점은, 머릿속에만 있던 아이디어가 실제로 동작하는 형태로 구현되는 것을 보며 가능성을 확인할 수 있었다는 것입니다.

작업을 마무리하면서 또 다른 아이디어들도 떠올라 현재는 새로운 자동화 작업을 실험 중입니다. 이번 경험을 계기로 앞으로 더 많은 시도를 해볼 수 있을 것 같아 기대가 됩니다.


끝으로, 제 글을 읽어주신 모든 분들께 감사합니다 :)


keyword
작가의 이전글사용자의 불편함을 외면하지 않을 용기