프로비저닝은 기존 자료를 읽어 엔진 구성으로 바꿉니다. 결과를 가장 크게 좌우하는 결정은 요청의 sources 배열에 무엇을 넣느냐입니다. 결국 돌아오는 엔진의 품질은 무엇을 입력하느냐에 달려 있기 때문입니다.
각 항목은 두 종류 중 하나입니다. link 소스는 플랫폼이 대신 가져와 크롤링하는 URL이고, content 소스는 직접 전달하는 원시 텍스트나 마크다운입니다. 하나의 요청에 두 유형을 함께 넣을 수 있고, 전체 소스는 최대 10개까지 가능합니다. 이 페이지에서는 두 유형의 차이, 플랫폼이 각각을 어떻게 처리하는지, 그리고 비어 있는 구성이 아니라 실제로 쓸 만한 구성을 만들 수 있는 소스를 어떻게 고를지 설명합니다. sources 필드 자체는 생성 요청에 포함되며, 전체 페이로드와 202 응답은 프로비저닝 작업 만들기에서 확인할 수 있습니다.
두 가지 소스 유형#
모든 소스는 type와 payload를 가진 객체입니다. type가 플랫폼이 payload를 어떤 방식으로 읽을지 결정합니다.
| 유형 | 페이로드 | 이럴 때 선택하세요 |
|---|---|---|
link | 크롤링할 URL | 필요한 컨텍스트가 이미 웹에 있을 때 — 브랜드 페이지, 공개 문서, 게시된 스타일 가이드, 용어집 페이지 등. |
content | 원시 텍스트 또는 마크다운 | 필요한 컨텍스트가 머릿속이나 비공개 문서에 있을 때 — 용어 목록, 톤 규칙, 제품명 표기 규칙, 번역 시 해야 할 것과 피해야 할 것 등. |
{
"sources": [
{ "type": "link", "payload": "https://acme.com/brand-guidelines" },
{ "type": "link", "payload": "https://acme.com/docs/style-guide" },
{
"type": "content",
"payload": "Brand name 'Acme' is never translated. Use formal tone in German (Sie-form). Product names: AcmeFlow, AcmeSync, AcmeVault - always keep in English."
}
]
}같은 배열에 링크 2개와 콘텐츠 블록 1개를 넣은 예입니다. 링크는 이미 필요한 컨텍스트가 담긴 페이지를 가리키고, 콘텐츠 블록은 공개된 곳에는 없는 규칙을 담고 있습니다. 둘 다 같은 추출 단계로 들어갑니다.
플랫폼이 각 소스를 처리하는 방식#
두 유형의 차이는 단 한 단계, 즉 텍스트를 AI 에이전트 앞까지 가져오는 방식에만 있고, 그 이후에는 동일하게 처리됩니다.
link 소스는 분석 전에 먼저 가져와 마크다운으로 변환됩니다. 플랫폼은 링크 소스를 병렬로 크롤링하므로 URL 10개가 순차적인 10번의 왕복 요청을 뜻하지는 않습니다. 동시에 읽은 뒤 텍스트로 에이전트에 전달합니다. 사용자는 URL만 주면 되고, 가져오기와 HTML을 마크다운으로 정리하는 작업은 플랫폼이 맡기 때문에 에이전트는 페이지 마크업이 아니라 실제 본문을 읽게 됩니다.
content 소스는 이 단계를 건너뜁니다. 사용자가 보낸 텍스트가 작성한 그대로 AI 에이전트에 직접 전달됩니다. 크롤링도 없고 변환도 없으며, 사용자 문장과 에이전트 사이에 끼어드는 단계도 없습니다. 그래서 콘텐츠 소스는 이미 알고 있는 규칙을 가장 정확하게 전달하는 방법입니다.
그 이후로는 두 유형 모두 같은 입력이 됩니다. 에이전트는 전체 내용을 읽고 브랜드 보이스, 용어집 항목, 지침을 추출합니다. 여기서 어떤 결과물을 만들고 어떤 요약을 돌려주는지는 별도 주제이므로 AI가 추출하는 내용을 참고하세요.
링크 크롤링은 어디까지 진행되나요?
link 소스는 에이전트가 분석하기 전에 먼저 수집되고 마크다운으로 변환됩니다. 크롤러가 사용자가 제공한 URL을 넘어 추가 링크를 따라가는지, 또 어느 깊이까지 탐색하는지는 여기서 규정하지 않습니다. 특정 페이지 집합을 반드시 분석해야 한다면, 하나의 URL이 알아서 퍼져 나가길 기대하기보다 각 페이지를 개별 link 소스로 나열하는 편이 확실합니다.
의미 있는 신호가 담긴 소스를 고르세요#
프로비저닝을 돌릴 가치가 있는지 결정하는 지점이 바로 여기입니다. 추출 품질은 입력 품질만큼만 좋고, 여기서 생기는 실패는 조용합니다. 부실한 소스로 실행한 작업도 완료되고, 엔진도 생성됩니다. 다만 거의 비어 있는 엔진이 만들어질 뿐이고, 나중에 번역이 당연히 반영됐을 거라 생각한 규칙을 무시할 때서야 그 사실을 알게 됩니다. 완료 알림도 다른 경우와 똑같이 도착합니다. Webhook delivery를 참고하세요. 즉, 이 빈틈을 따로 알려 주는 신호는 없습니다.
의미 있는 소스를 제공하세요
추출된 구성의 품질은 입력 품질에 달려 있습니다. 링크 소스는 유용한 컨텍스트가 담긴 페이지를 가리켜야 합니다. 예를 들어 브랜드 가이드라인, 스타일 가이드, 제품 문서, 용어집 같은 페이지가 좋습니다. 원시 콘텐츠 소스에는 구체적인 용어, 톤 가이드, 번역 규칙이 들어 있어야 합니다. 일반적인 마케팅 페이지나 로그인 화면에서는 유용한 구성이 거의 나오지 않습니다.
이 콜아웃의 핵심은 간단합니다. 에이전트는 명시된 것을 추출하지, 암묵적으로 드러나는 것을 추론해 끌어내지는 않습니다. "우리는 Sie를 사용하고 Du는 절대 쓰지 않는, 친근하면서도 직설적인 독일어로 씁니다"라고 적힌 페이지에서는 브랜드 보이스를 뽑아낼 수 있습니다. "workspace → Arbeitsbereich"처럼 정리된 용어집 페이지에서는 용어집 항목을 추출할 수 있습니다. 반대로 규칙은 하나도 적지 않은 채 좋은 톤만 보여 주는 세련된 랜딩 페이지에서는 거의 아무것도 얻지 못합니다. 끌어올 규칙 자체가 없기 때문입니다. 헷갈릴 때는 에이전트가 알아서 추론하길 기대하는 페이지보다, 규칙을 분명히 써 둔 소스를 택하세요. 많은 경우 그 역할은 직접 문장으로 작성한 content 블록이 더 잘합니다.
약한 소스 하나가 작업 전체를 망치지는 않습니다#
여러 소스를 한 번에 넣으면 자연히 이런 걱정이 듭니다. URL 하나가 죽어 있거나 블록 하나의 내용이 빈약하면 전체 요청이 실패할까요? 그렇지 않습니다. 소스는 각각 독립적으로 읽히며, 항목별 실패는 치명적인 오류가 아니라 기록되는 결과로 남습니다. 죽은 링크나 읽을 수 없는 블록은 건너뛰고, 에이전트는 읽을 수 있었던 내용으로 계속 작업합니다. 작업 전체가 실패하는 경우는 어떤 소스도 전혀 읽지 못해 분석할 내용이 하나도 남지 않았을 때뿐입니다. 이런 결과가 실제로 어떤 형태로 반환되는지, 즉 성공 시 기록되는 항목별 실패와 아무것도 읽지 못했을 때의 실패 페이로드는 AI가 추출하는 내용과 Webhook delivery에서 다룹니다.
즉, 모든 URL을 먼저 일일이 점검하지 않아도 후보군을 넣어 볼 수 있습니다. 강한 소스는 기여하고 약한 소스는 빠지며, 실제로 무엇이 반영됐는지는 출력 요약에서 확인하면 됩니다. 이미 가진 자료를 넣고, 무엇이 돌아왔는지 확인해 보세요.
