3주차 들어오면서 프로젝트 방향 자체가 꽤 많이 바뀌었다.
처음에는 솔직히 “AI가 알아서 다 해주는 구조”를 만드는 쪽에 더 가까웠다.
AI가 업무 인터뷰를 진행하고, PARA 기준으로 분류하고,
적절한 DB를 찾고, 프로젝트와 Task를 생성하고, 노션 relation까지 연결하고, 필요한 문서를 자동으로 만들어주는 흐름.
거의 “딸깍 자동화” 같은 그림을 생각하고 있었다.
근데 실제로 노션 AI를 붙여서 계속 테스트해보니까 생각보다 문제가 굉장히 많이 나왔다.
인터뷰 없이 바로 문서 생성, 노션 운영 흐름 무시, 노트 DB 대신 새 페이지 생성, 너무 빨리 “정리해줄게” 모드 진입, JSON 기반 질문 출력, 설문조사처럼 행동, “1번~4번 중 골라주세요” 같은 UX 흐름, 설명형 챗봇처럼 움직이는 문제 같은 것들이 계속 발생했다.
특히 느꼈던 건 AI가 업무를 이해하려고 하기보다 “문서를 빨리 생성하는 것”에 더 집중한다는 점이었다.
나는 “현재 운영 구조 안에서 어떻게 움직여야 하는가”를 중요하게 생각하고 있었는데,
AI는 계속 결과물을 빨리 만들어주는 쪽으로 움직이려고 했다.
그래서 3주차 들어와서는 방향 자체를 다시 잡기 시작했다.
핵심은 “완전 자동화”보다 “노션을 더 잘 활용하게 만드는 구조” 쪽으로 이동한 거였다.
여기서부터는 외부 AI가 노션을 강하게 제어하는 구조보다,
노션 안에서 현재 페이지와 연결 문서, 권한 범위 안의 컨텍스트를 활용해서 업무를 보조하는 방향이 훨씬 현실적으로 느껴졌다.
그래서 실제로 “노션 스킬 모음” 구조를 만들기 시작했다. AREA 안에 스킬 영역을 따로 만들고, 지식_인터뷰.md, 개요서_생성_스킬.md, PARA_분류_아키텍처.md, 워크플로우_오케스트레이터.md, 회의록.md, 회고.md, QA정리.md 같은 문서들을 계속 축적하기 시작했다.
그리고 여기서 중요했던 건, 이걸 단순 프롬프트 저장소처럼 쓰는 게 아니라 “실행 문서”처럼 동작하게 만드는 것이었다. 예를 들면 회의를 했다면 @회의록.md, 업무 회고를 하고 싶다면 @회고.md, 개요서를 만들고 싶다면 @개요서_생성_스킬.md 같은 식으로 필요한 순간에 필요한 스킬 문서를 노션 AI 컨텍스트에 붙여서 사용하는 방향이다.
근데 여기서 또 새로운 문제가 나왔다. AI가 문서를 “실행 규칙”으로 읽는 게 아니라 계속 “설명 문서”처럼 읽기 시작한 거다. “이 문서는 이런 목적입니다”, “원하시는 작업이 무엇인가요?”, “1번~4번 중 선택해주세요” 같은 식으로 움직였다. 즉 내가 원한 건 “실행형 인터뷰 프로토콜”에 가까웠는데, 실제로는 “UX 가이드형 챗봇”처럼 움직여버린 것이다.
그래서 이 시점부터는 기능 추가보다 “가드레일 추가” 비중이 훨씬 커졌다. 설명 모드 금지, 옵션 제안 금지, 번호 선택 UX 금지, JSON 질문 금지, 인터뷰 전 구조화 금지, 충분한 정보 전 결과물 생성 금지, “정리해줄게” 모드 금지 같은 것들을 계속 추가하기 시작했다.
3주차 들어와서 가장 많이 고민한 건 결국 “무엇을 하게 만들까?”보다 “무엇을 못하게 막을까?”에 가까웠던 것 같다. 그리고 여기서 느낀 건, AI 자동화는 단순 기능 구현 문제가 아니라 거의 “행동 제약 설계”에 가까운 영역이라는 점이었다.
이번 주에는 실제로 “개요서 생성 스킬” 인터뷰 테스트도 진행했다. 핵심 목표는 개요서를 바로 생성하는 것이 아니라, 개요서를 만들기 위한 맥락을 인터뷰 방식으로 수집하는 것이었다. 실제로 노션 AI와 테스트를 해보니까 생각보다 인터뷰 흐 름 자체는 꽤 자연스럽게 동작했다.
누가 보는 문서인지, 어떤 결과물이 필요한지, 어떤 DB에 저장되는지, Task DB 구조가 어떻게 되는지, 우선순위와 상태는 어떻게 시작하는지, 일정은 어떤 기준으로 보는지 같은 걸 계속 질문하면서 운영 구조까지 같이 수집하는 흐름이 만들어졌다.
특히 여기서 재미있었던 건 단순히 “문서를 작성한다” 수준이 아니라 “현재 팀 운영 체계를 어떻게 쓰고 있는가”까지 인터뷰가 들어가기 시작했다는 점이었다. 예를 들면 기획서는 어디에 생성되는가, 어떤 속성값이 기본인가, 명료화 기본값은 무엇인가, 작업자는 자동 지정인가 직접 지정인가 같은 운영 규칙들까지 같이 정리되기 시작했다.
그래서 여기서부터는 “수집한 정보를 실제 생성 흐름으로 어떻게 연결할 것인가”를 고민하기 시작했다. 그 과정에서 만든 게 “분류를 위한 인터뷰 및 생성기” 구조였다. 핵심은 단순 생성기가 아니라 이 업무가 Task인지, 프로젝트인지, 노트인지 먼저 판단하고 현재 PARA 구조 안에서 어디로 연결해야 하는지를 결정하게 만드는 방향이었다.
즉 생성 전에 먼저 @영역, @자원, @프로젝트, @노트 같은 것들을 읽게 하고, 현재 운영 체계가 어떤 프리픽스를 쓰는지, 어떤 제목 규칙을 쓰는지, 프로젝트를 어떻게 만드는지, 노트를 어디에 저장하는지 같은 걸 먼저 파악하게 만드는 방향으로 바뀌기 시작했다.
그리고 생성 흐름도 “바로 생성”이 아니라 “제안 → 승인 → 생성” 구조로 다시 설계하기 시작했다. 예를 들면 “현재 기준으로는 프로젝트 생성 + 관련 Task 생성 흐름이 적절해 보인다”처럼 먼저 제안하고, 유저 승인 이후 실제 생성 흐름으로 들어가게 만드는 방식이다.
그리고 이 시점부터는 “설명형 AI”를 계속 막기 시작했다. 왜냐면 실제 테스트를 해보면 AI가 너무 쉽게 “이 문서는 ~입니다”, “원하는 작업을 골라주세요”, “1번~4번 중 선택해주세요” 같은 방향으로 빠졌기 때문이다.
근데 내가 원했던 건 대화형 인터뷰 프로토콜에 가까웠다. 즉 설명하는 AI가 아니라, 업무를 이해하기 위해 계속 질문을 이어가는 구조를 원했던 것이다. 그래서 설명 금지, 선택지 금지, JSON 금지, 인터뷰 즉시 시작 같은 규칙들을 계속 추가하게 됐다.
그리고 후반부에는 실제로 더미 데이터 기반 테스트까지 진행했다. 가정은 “개요서가 없는 상태에서, 추상적인 업무 메모만 존재하는 상황”이었다. 예를 들면 “업무 일지 작성해야 됨”, “내일 컨펌 받아야 함” 정도만 적혀 있는 메모를 던져놓고, AI가 얼마나 자연스럽게 인터뷰 → 분류 → 생성 흐름으로 들어가는지 테스트한 것이다.
생각보다 일정 수집이나 작업자 지정 같은 흐름은 꽤 자연스럽게 동작했다. 문제는 그 다음이었다. 원래 의도는 인터뷰 → draft 상태 유지 → 승인 → 실제 수정 흐름이었는데, 실제로는 질문 → 값 수집 → 바로 수정으로 움직여버렸다.
즉 인터뷰 단계인데도 AI가 실제 수정 권한 상태로 들어가버린 것이다. 예를 들면 “상태를 진행 중으로 바꿔뒀어요”, “작업자를 반영했어요”처럼 바로 실행해버리는 문제가 발생했다.
그래서 여기서부터는 “인터뷰 설계”보다 “실행 권한 제어”가 훨씬 중요하다고 느끼기 시작했다. 단순히 생성 금지, 수정 금지, 저장 금지 정도로는 부족했고, 이제는 draft_state, execution_state, 승인 전 실행 금지, 최종 승인 전 수정 금지, “반영했어요” 표현 금지 같은 상태 머신 개념 자체를 프롬프트 안에 넣기 시작했다.
결국 3주차 들어오면서 가장 크게 바뀐 건 이것 같다. 처음에는 “AI가 알아서 노션을 자동화해주면 좋겠다”였다면, 지금은 “노션 AI를 활용해서 업무 인터뷰와 구조화를 더 잘하게 만들자” 쪽으로 방향이 바뀌고 있다. 그리고 지금 단계에서는 오히려 이 방향이 훨씬 현실적이라는 느낌이 들고 있다.