이제는 노션을 배우는 게 아니라, 일할 AI 조직을 설계하는 시대

치과의사신문 + 덴탈위키 공동기획 「치과병의원 노션 AI 에이전트 팀 구축법」 ④

1. 공부한 다음 도입하는 시대는 끝났다

치과에 노션을 도입하는 순서는 지금까지 한결 같았다.

메뉴 구조를 익히고, 블록과 데이터베이스 사용법을 배우고, 관계형·롤업·수식 함수를 공부한 다음, 그렇게 확보한 배경지식과 조작능력으로 비로소 치과 업무에 적용했다. 문제는 이 학습곡선을 끝까지 견디는 사람이 드물다는 것이다. 대부분 함수 앞에서 멈춘다. 이제 순서를 뒤집어야 한다. 노션은 공부한 뒤에 쓰는 도구가 아니라 AI에 시켜서 쓰는 도구가 되었다. 노션에 대한 포괄적 배경지식을 먼저 쌓는 대신, 무엇을 누구에게 시킬지 정의하는 능력을 먼저 갖추면 된다.

2. 노션 AI의 네 가지 층위

그런데 정작 노션 AI 진입을 가로막는 새로운 장애물이 생겼다. 노션 AI가 하나의 챗봇이 아니라 여러 층위로 나뉘어 있다는 점이다. 정리하면 네 층이다.

• 총괄비서 AI : 워크스페이스 전반의 질의응답을 담당하는 상시 대화 상대. 개인화 지침을 부여한다.
• Main-Agent(팀장): 업무 단위 책임자. 하위 에이전트를 호출하고 결과를 취합한다.
• Sub-Agents(팀원): 작성·검수처럼 단일 기능을 수행하는 행동대장.
• 속성 Agent: 데이터베이스 행 단위에서 특정 자동화만 담당하는 전담 인력.

이 층차를 구분하지 못하면 ‘노션 AI는 생각보다 별로다’라는 결론에 이르기 쉽다. 실제로는 시킬 대상을 잘못 고른 것이다.

3. 총괄비서에게는 개인화 지침을, 에이전트에게는 최적화 지침을

노션 AI 개인화 화면에서는 총괄비서의 이름과 지침을 설정한다. 필자는 이 이름을 MediCurator로 두었다. 여기 들어가는 내용은 호칭·말투·용어·산출물 형식처럼 모든 대화에 공통 적용되는 규칙, 곧 개인화 지침이다.

반면 에이전트 지침은 성격이 다르다. 특정 업무 한 가지를 어떤 순서로 어떤 형식으로 처리할지 규정하는 최적화 지침이다. 총괄비서에게 “SOP는 이런 구조로 써라”를 넣어도 소용없고, 에이전트에게 “항상 존댓말을 써라”만 넣어도 일이 되지 않는다. 두 지침이 섞이는 순간 결과물이 흔들린다. 층위를 나누는 실익이 여기서 나온다.

4. Main-Agent와 Sub-Agents : 실제 구성 사례

필자의 워크스페이스에는 여섯 개의 에이전트가 두 팀으로 편성되어 있다.

• SOP 팀: SOP Builder(팀장)- SOP Writer(작성)- SOP Reviewer(검수)
• HTML 팀: HTML Builder(팀장)- HTML Writer(작성)- HTML Reviewer(검수)

팀장인 SOP Builder의 지침에는 기본 흐름이 명시되어 있다. 작성(Writer) 후 사람이 최종 반영하는 것이 기본이고, 검수(Reviewer)는 조건부로만 실행한다. 검수를 매번 돌리면 크레딧 소모가 배로 늘기 때문이다. 에이전트 팀 설계는 품질 설계인 동시에 비용 설계다.

에이전트마다 트리거(언제 실행할 것인가)와 도구·사용 권한(어떤 데이터베이스와 웹 도메인에 접근할 것인가)을 따로 지정한다. 권한을 좁게 주는 것이 곧 안전장치다.

5. AI Orchestration : 팀장이 팀원을 조율한다

AI Orchestration은 Main-Agent가 Sub-Agents를 조율하는 개념이다. 사용자는 팀장 한 명에게만 지시한다. “데스크 신입용 전화응대 SOP 초안”이라고 던지면 Builder가 Writer를 호출해 표준 구조로 초안을 만들고, 리스크가 높은 항목일 때만 Reviewer를 추가로 호출한 뒤 결과를 정리해 올린다. 직원 여러 명에게 각각 지시하는 대신 실장에게 맡기는 것과 같은 구조다. AI를 쓰는 능력이 이제 사람 조직을 운영하는 능력과 같은 문법을 쓴다.

6. 속성 Agent : 데이터베이스 행 단위 자동화

네 번째 층위인 속성 Agent는 데이터 베이스의 속성 하나가 통째로 자동화 담당자가 되는 방식이다. SOP 데이터베이스에 요약 속성을 두면, 행이 추가될 때마다 본문을 읽어 세 줄 요약을 채우고, 리스크 등급 속성은 내용을 판별해 등급을 부여한다. 사람이 채우던 열을 에이전트가 채우는 것이다. 대화형 에이전트가 프로젝트 단위로 일한다면, 속성 에이전트는 레코드 단위로 상시 대기한다. 데이터가 쌓일수록 효과가 커지는 쪽은 후자다.

7. 설계는 클로드에서, 운영은 노션에서

SOP나 직원 직무교육 온보딩처럼 체계를 처음부터 기획해야 하는 작업은 클로드가 편하다. 부서·직책 체계를 잡고, 코드 규칙을 정하고, 데이터베이스 속성 구조 초안을 설계하는 긴 호흡의 작업에서 강점을 보인다. 클로드에 노션 커넥터(MCP)를 연결하면 별도의 코드 삽입 없이 노션 워크스페이스를 직접 제어하며 데이터베이스를 생성할 수 있다. 반대로 생성된 데이터베이스를 다듬고, 뷰를 최적화하고, 에이전트를 붙여 상시 운영하는 단계는 노션이 낫다. 설계는 클로드, 운영은 노션. 이 역할 분담이 현재로선 가장 효율적이다.

8. 도입 시 반드시 지켜야 할 원칙

• 권한 최소화: 에이전트에 부여하는 데이터베이스와 웹 접근 권한은 업무에 필요한 범위로만 제한한다.
• 사람의 최종 검토(HITL): 에이전트 산출물은 초안일 뿐이다. 특히 보험청구·환자 문서·인사·재무 관련 기록은 담당자가 검토·수정한 뒤 확정한다.
• 비용 설계: 검수 에이전트는 조건부 호출로 두어 크레딧 소모를 통제한다. 층위를 나누는 목적의 절반은 비용이다.
• 지침의 버전 관리: 지침을 고칠 때마다 무엇을 왜 바꿨는지 남긴다. 에이전트 조직에서는 지침이 곧 시스템이다.

직원을 뽑아 가르치고, 역할을 나누고, 결재선을 세우는 일을 이제 AI에게도 똑같이 해야 한다. 노션 AI 에이전트 팀 구축은 도구 사용법의 문제가 아니라 조직 설계의 문제다.