소스를 제출했고 작업이 실행 중입니다. 엔진 ID는 202에서 반환되었고, 이제 구성이 채워지고 있습니다. 이 페이지는 결과를 신뢰할 수 있을지 가르는 질문, 즉 **정확히 무엇이 채워지고 있는가?**에 답합니다.
"AI가 내 엔진을 구성했다"는 말은 엔지니어를 경계하게 만들고, 그 경계심은 아주 자연스럽습니다. 들여다볼 수 없는 블랙박스를 뜻할 수도 있고, 어느 로캘에 어떤 레코드가 흩어져 있는지 추적할 수 없는 상태를 뜻할 수도 있습니다. 혹은 에이전트가 빈약한 소스를 읽고도 조용히 거의 아무것도 만들지 않았다는 뜻일 수도 있습니다. 그래서 이 페이지는 이 세 가지를 모두 구체적으로 설명합니다. 에이전트는 세 종류의 구성을 만들고, 각 구성은 예측 가능한 규칙에 따라 로캘에 매핑되며, 작업은 생성한 모든 레코드의 이름이 담긴 요약을 돌려줍니다. 결과물은 읽고 수정할 수 있는 일반 레코드이지, 일단 믿고 받아들여야 하는 판정이 아닙니다.
비동기 프로비저닝이 처음이라면 먼저 Async Provisioning API 개요에서 전체 개념을 잡고, 소스 유형에서 어떤 소스가 제출할 만한 가치가 있는지 확인해 보세요. 이 페이지는 그 반대편에서 무엇이 나오는지에 관한 내용입니다.
이 페이지에서 다루는 내용
세 가지 구성 요소#
에이전트는 크롤링한 페이지든 원시 콘텐츠든 가리지 않고 모두 읽어 세 가지 종류의 엔진 구성을 만듭니다. 이것은 프로비저닝 전용의 새로운 형식이 아닙니다. 원래 엔진에서 직접 만들었을 바로 그 기본 구성 요소들이기 때문에, 에이전트가 만든 모든 항목은 이후에도 대시보드에서 직접 만든 것과 똑같이 읽고 수정할 수 있습니다.
| 구성 요소 | 찾아보는 내용 | 예시 |
|---|---|---|
| 브랜드 보이스 | 톤, 스타일, 격식 수준, 작성 관례 | "격식 있는 독일어(Sie 형식)를 사용하세요. 문장은 간결하고 직설적으로 유지하세요." |
| 용어집 항목 | 제품명, 기술 용어, 브랜드 고유 번역, 번역하지 않는 용어 | "Acme" → 번역 금지, "workspace" → "Arbeitsbereich" (de) |
| 지침 | 서식 규칙, 문화적 관례, 도메인별 가이드라인 | "독일어 번역에서는 날짜를 항상 DD.MM.YYYY 형식으로 표기하세요." |
이 세 가지가 번역을 그저 무난한 표현이 아니라 여러분 제품다운 표현으로 만들어 줍니다. 선택한 격식 수준, 절대 번역하지 않는 이름, 항상 사용하는 날짜 형식이 여기에 해당합니다. 에이전트의 역할은 이런 결정이 소스 어디에 적혀 있든 찾아내어 레코드로 남기는 것입니다.
기대치를 정하는 데 중요하므로 이 점은 분명히 짚고 넘어갈 필요가 있습니다. 에이전트는 암시된 내용을 추출하는 것이 아니라 명시된 내용을 추출합니다. 규칙을 분명히 적어 둔 소스에서는 레코드가 나오지만, 좋은 톤을 보여 주기만 하고 규칙 자체를 말로 적어 두지 않은 소스에서는 추출되는 것이 많지 않습니다. 이것은 엔진의 한계가 아니라 소스의 특성입니다. 소스 유형에서는 규칙이 분명히 드러나는 소스를 어떻게 고를지 설명합니다.
각 항목이 로캘에 매핑되는 방식#
로컬라이제이션 엔진의 구성은 대상 로캘을 기준으로 키가 정해지므로, 레코드는 단순히 규칙이 무엇인지뿐 아니라 그 규칙이 어디에 적용되는지까지 함께 나타냅니다. 에이전트는 예측 가능한 규칙에 따라 각 레코드에 로캘을 할당하며, 출력을 읽기 전에 이해해 둘 만한 핵심은 * 와일드카드입니다.
- 브랜드 보이스와 지침은 모든 언어에 적용될 때
*를 사용합니다. "문장을 간결하고 직설적으로 유지하라" 같은 톤 규칙은 독일어만의 규칙이 아닙니다. 이는 제품이 모든 언어에서 글을 쓰는 방식입니다. 에이전트는 여기에*대상 로캘을 할당하고, 엔진이 번역하는 모든 로캘에 적용되도록 합니다. 반대로 정말로 언어별인 규칙("독일어에서는 Sie 형식을 사용")은 해당 로캘에 할당됩니다. - 용어집 항목은 로캘 쌍별로 생성됩니다. 번역은 언제나 한 언어에서 특정 다른 언어로 옮기는 일이기 때문입니다. "workspace" → "Arbeitsbereich"는 독일어에 대한 사실이며, 오직 독일어에만 해당합니다.
- 번역하지 않는 용어는 예외이며
*를 사용합니다. 절대 번역하지 않는 브랜드명, 예를 들어 "Acme"는 모든 언어에서 번역되지 않으므로 각 로캘 쌍마다 다시 입력하는 대신*에 한 번만 저장됩니다.
따라서 작업이 만든 레코드에서 *를 보더라도, 그것은 플레이스홀더나 누락이 아닙니다. "이 항목은 어디에나 적용된다"는 뜻입니다. 전역 톤 규칙, 전역 지침, 또는 어떤 언어에서도 번역되지 않는 용어를 의미합니다. 반대로 특정 로캘 코드는 이 규칙이 정확히 그 언어에만 적용된다는 뜻입니다.
와일드카드는 덮어써야 할 기본값이 아니라 기능입니다
*를 회의적으로 보면 "에이전트가 이 항목이 어느 로캘에 속하는지 굳이 알아내지 않았다"고 읽힐 수 있습니다. 하지만 실제로는 정반대입니다. 모든 언어에서 맞는 브랜드 보이스나 번역하지 않는 용어는 전역으로 설정되어야 합니다. 이를 한 로캘에만 묶어 두면 다른 로캘에는 조용히 적용되지 않게 됩니다. 와일드카드는 구성에서 "이 내용은 언어와 관계없이 유효하다"고 표현하는 방식이며, 톤 규칙이나 브랜드명은 대개 정확히 그런 성격을 가집니다.
출력 요약#
작업이 완료되면 에이전트가 생성한 모든 항목의 이름이 담긴 요약이 반환됩니다. 말 그대로 영수증입니다. 모든 레코드가 개수와 식별자와 함께 제공되고, 실패한 항목 목록도 함께 돌아옵니다.
{
"brandVoices": {
"count": 3,
"ids": ["bv_A1b2C3d4", "bv_B2c3D4e5", "bv_C3d4E5f6"]
},
"glossaryItems": {
"count": 12,
"ids": ["gi_A1b2C3d4", "gi_B2c3D4e5", "..."]
},
"instructions": {
"count": 5,
"ids": ["ins_A1b2C3d4", "ins_B2c3D4e5", "..."]
},
"errors": []
}각 구성 요소는 생성된 레코드의 count와 ids를 보고합니다. 브랜드 보이스는 bv_, 용어집 항목은 gi_, 지침은 ins_입니다. 이것들은 의미를 알 수 없는 확인 응답이 아니라 엔진에 실제로 존재하는 레코드의 ID입니다. 이 목록에 있는 어떤 gi_든 대시보드에서 열어 보면 에이전트가 정확히 무엇을 추출했는지 읽고 수정할 수 있습니다. 요약은 "AI가 뭔가 했다"를 "AI가 한 스무 가지 구체적인 일이 여기 있다"로 바꿔 주며, 바로 그 점이 블랙박스와 읽고 수정할 수 있는 일반 레코드의 차이입니다.
요약은 작업을 만들 때 설정한 채널로 전달됩니다. 작업이 완료되면 콜백 URL이 받는 webhook 페이로드의 summary 필드에 담겨 도착합니다. WebSocket으로 작업을 지켜보고 있다면, 그것은 상태를 알려 주는 라이브 피드입니다. 크롤링과 구성 진행 상황은 스트리밍하지만, 이 요약 객체 자체를 전달하지는 않습니다. 요약은 완료 webhook과 함께 오고, WebSocket은 언제 가서 그것을 확인하면 되는지를 알려 줍니다.
항목 하나가 실패해도 작업 전체가 실패하는 것은 아닙니다.
레코드 하나를 만들 수 없더라도 나머지까지 모두 무산되지는 않습니다. 실패는 errors 배열에 기록되고, 성공한 레코드는 그대로 엔진에 적용되며, 작업도 완료됩니다. 즉, 빈 엔진과 스택 트레이스를 받는 것이 아니라 부분적으로 구성된 엔진과 다시 확인해야 할 항목의 정확한 목록을 받게 됩니다. 실행 결과에서 활용할 수 있는 내용이 전혀 없을 때만 작업 전체가 실패합니다. 예를 들어 모든 소스의 크롤링이 실패한 경우가 그렇습니다. 이 실패 사례와 해당 provisioning.failed 페이로드는 Webhook delivery에서 다룹니다.
내용이 적은 요약 읽는 법#
요약은 무엇이 생성되었는지만 보여 주는 것이 아니라, 개수를 통해 이번 실행이 얼마나 의미 있었는지도 알려 줍니다. 어떤 구성 요소의 count가 0라고 해서 오류는 아닙니다. 요약은 정상 형식이고 엔진도 존재합니다. 하지만 중요한 신호이긴 합니다. 브랜드 보이스 3개와 용어집 항목 12개라면 구성된 엔진입니다. 반대로 모든 항목이 0이고 errors 배열도 비어 있다면, 거의 빈 상태로 돌아온 엔진이며 에이전트가 추출할 만한 규칙을 거의 찾지 못했다는 뜻입니다.
이럴 때 원인은 거의 항상 상류에 있습니다. 즉, 에이전트가 끌어올릴 만한 구체적인 규칙이 소스에 거의 명시되어 있지 않았다는 뜻입니다. 그 사실을 확인하는 곳은 요약이고, 이를 바로잡는 곳은 소스 유형입니다. 첫 실행에 앞서 가져야 할 솔직한 기대치는 이렇습니다. 영수증은 소스가 실제로 말한 내용만 반영합니다. 요약이 풍부하다면 소스도 풍부했던 것이고, 요약이 얇다면 찾아낼 내용이 많지 않았던 것입니다.
그래서 요약은 엔진만큼 중요합니다. 추측에 기대지 않고 구성을 직접 검증할 수 있게 해 주기 때문입니다. 개수를 확인하고, ID로 몇 개의 레코드를 열어 보고, 에이전트가 기대한 내용을 제대로 포착했는지 확인해 보세요. 그것은 읽고 수정할 수 있는 일반 레코드이고, 무엇을 점검해야 하는지 정확히 알려 주는 영수증도 함께 따라옵니다.
