콘텐츠로 이동

Weave 점검 항목

Weave는 프로젝트에 이미 저장된 구성과 지난 30일 동안 워크플로가 실행된 기록을 읽고, 발견한 내용을 보고합니다. 예를 들어 배부할 대상이 없는 배부 단계, 저장된 구조에 같은 단계가 두 번 나열된 워크플로, 마지막 실행이 실패한 워크플로, 출력의 행 수가 평소보다 훨씬 적은 단계 등이 있습니다. Weave는 읽기만 합니다. Weave가 보고하는 내용은 단계를 변경하지 않으며, Weave는 워크플로를 실행하지 않습니다.

AI 모델은 사용하지 않습니다. 모든 검사는 고정된 규칙이고 모든 문장은 미리 작성되어 있으므로, 보고서를 아무리 자주 요청해도 생성 비용이 들지 않습니다.

PlaidCloud의 검사 대부분에는 두 가지 답이 있습니다. 구성에 문제가 없거나, 구성이 거부되는 것입니다. Weave에는 세 번째 답이 있으며, 이해해 둘 가치가 있는 것은 바로 이 답입니다.

답 의미
Weave가 발견했습니다 … Weave가 이 항목을 검사했고 문제를 발견했습니다.
(아무 말도 하지 않음) Weave가 이 항목을 검사했고 잘못된 점을 발견하지 못했습니다.
Weave가 검사하지 않았습니다 … Weave가 이 항목을 전혀 판단할 수 없었습니다.

세 번째 답이 있는 이유는 침묵이 모호하기 때문입니다. 배부 단계를 만들 때 PlaidCloud에서는 열 매핑을 채우기 전에도 단계를 저장할 수 있습니다. 아직 만드는 중이므로 저장을 거부하면 작업을 계속할 수 없기 때문입니다. 같은 빈 매핑을 읽는 모니터는 이 단계를 정상이라고 쉽게 보고할 수 있습니다. 하지만 이 단계는 정상이 아니라 완성되지 않은 것이며, 아무도 살펴보지 않았습니다.

그래서 Weave는 그렇다고 말합니다. Weave가 판단할 수 없었던 단계는 이유와 함께 검사되지 않음으로 보고되며, 통과한 것처럼 집계되거나 정렬되거나 색으로 표시되지 않습니다.

Weave가 말할 수 있는 네 번째 내용이 있지만, 이는 단계에 대한 답이 전혀 아닙니다. 바로 Weave에 해당 규칙이 없습니다 … 문구입니다. 이는 Weave에 그런 종류의 항목에 대한 검사가 없고 한 번도 판단하지 않았다는 뜻입니다. “검사하지 않았습니다”와 달리 단계를 어떻게 바꾸더라도 판정이 나오지 않으므로, 둘을 구분해 두는 것이 좋습니다. 검사되지 않은 단계를 완성하면 Weave가 판단하지만, 규칙이 없는 단계는 아무리 변경해도 판단되지 않은 채로 남습니다.

보고서는 자체 분모를 밝히는 요약으로 시작하므로, 보고서가 프로젝트를 얼마나 다루는지 알 수 있습니다.

Weave fully checked 3 of the 417 steps and workflows in "Cost Model", and found 1
problem in the parts it could judge. 1 more it hasn't fully checked.
Weave has no rule for 412 steps and 1 workflow it looked at, so they have not been
judged either way.
Weave noticed the step "Spread Overheads": No driver split value column found. One
driver column must have the role "Split Value".
Weave hasn't checked the step "Regional Split" — its column mapping is empty.

프로젝트에 일정에 따라 기록되는 테이블이나 최신 상태 임계값이 지정된 테이블이 있으면, 첫 줄에서 이를 따로 셉니다. Weave가 “Finance”의 단계 및 워크플로 36개 중 31개와 최신 상태로 유지되어야 하는 테이블 4개 중 3개를 완전히 검사했으며, 판단할 수 있었던 부분에서 문제 2개를 발견했습니다.

첫 줄의 분수는 의도된 것입니다. 단계 3개를 검사해 문제가 없다는 것과 프로젝트에 문제가 없다는 것은 같은 진술이 아니며, 첫 줄은 자체 규모를 함께 담고 있어 규모 없이 인용될 수 없습니다. “판단할 수 있었던 부분에서”라는 표현도 같은 이유로 들어 있습니다. 일부만 판단된 항목이 있으면, 발견된 문제를 첫 줄에서 방금 검사했다고 한 단계의 것으로 단정할 수 없습니다. 두 번째 줄은 Weave에 규칙이 전혀 없는 항목을 밝히고, 그 항목들이 어느 쪽으로도 판단되지 않았다고 분명히 말합니다. 검사가 필요 없었다는 뜻이 아닙니다.

모든 결과 항목 아래에는 Weave가 아는 방법 링크가 있으며, 이 링크를 클릭하면 Weave가 그 결과에 도달한 방법을 보여 주는 패널이 열립니다.

  • 확인 내용 — 규칙이 무엇을 검사하는지 쉬운 말로 설명하며, 개수를 몇 개의 이전 실행과 비교하는지 등 규칙이 사용하는 한도를 함께 보여 줍니다.
  • 근거 — 검사에 사용된 값입니다. 행 수가 바뀐 경우에는 최신 행 수, 이전 실행의 평균, 실행마다 행 수가 보통 변동하는 폭, 그리고 그 범위를 벗어나면 Weave가 보고하는 범위입니다.
  • 출처 — 근거를 읽어 온 실행, 실행 기록, 단계의 저장된 설정, 예약된 이벤트 또는 테이블입니다. 링크로 표시된 항목을 클릭하면 워크플로나 테이블 탐색기처럼 해당 항목을 확인할 수 있는 곳이 열립니다.
  • Weave가 확인하지 않은 내용 — 규칙이 다루지 않는 내용입니다. 이 항목은 비어 있는 경우가 없습니다. 예를 들어 테이블이 제때 기록되었는지 확인하는 검사는 무엇이 기록되었는지는 살펴보지 않습니다.

Weave가 검사할 수 없었던 결과 항목의 경우, 패널에는 검사 내용과 검사를 실행할 수 없었던 이유가 표시되며 근거는 표시되지 않습니다.

패널에는 사용자가 볼 수 있는 항목만 이름으로 표시됩니다. 역할상 숨겨진 단계, 워크플로 또는 테이블은 이름 없이 열 수 없는 항목으로 나열되며, 워크플로의 마지막 실행이 사용자가 열 수 없는 단계에서 실패한 경우 근거에는 해당 단계의 이름 대신 개수가 표시됩니다. 패널을 만드는 데 AI는 사용되지 않습니다.

패널은 Weave 탭과 검토에 나타납니다. 검토의 AI 작성 요약에도 패널이 있으며, AI가 작성했다는 사실, 몇 개의 결과 항목을 바탕으로 했는지, 요약을 보여 주기 전에 Weave가 무엇을 확인했는지를 알려 줍니다. AI 어시스턴트가 PlaidCloud MCP를 통해 실행하는 검토에는 패널이 포함되지 않습니다.

배부 열 매핑. Allocation with Dimension 또는 Allocation Split 단계의 경우, 배부할 숫자 열, 배부 기준이 되는 숫자 드라이버 값, 필요한 경우 계층이 있는지, 그리고 분할의 경우 분자와 소스 테이블에 실제로 있는 열을 지정하는 분모가 있는지 검사합니다. 이는 단계를 저장할 때 실행되는 것과 같은 검사로, 이미 저장된 내용을 읽습니다. 저장 시에는 배정 차원 자체도 검사하여 차원이 존재하는지, 드라이버 속성이 정확히 하나인지 확인하지만 Weave는 이를 검사하지 않으므로, 그 이유로 저장이 거부되는 단계에 대해서는 Weave 결과 항목이 생성되지 않습니다.

단계 식. 식이 있는 모든 단계에 대해, 사용자가 작성한 모든 식이 대상 열, Subset 절, Secondary Filter 절 중 어디에 있든 여전히 컴파일되는지 검사합니다. 결과 항목에는 어느 항목을 열어야 하는지 알 수 있도록 해당 열이나 절의 이름이 표시되고, Syntax error at line 1, position 280 같은 오류가 함께 표시됩니다. 식 자체는 Weave가 아는 방법 아래에 있으므로, 긴 식 때문에 오류가 묻히지 않습니다. 이는 단계를 저장할 때 실행되는 것과 같은 검사입니다.

Weave가 판단하지 않고 검사되지 않음으로 보고하는 두 가지 경우는 다음과 같습니다.

  • 변수를 읽는 식. 한 단계는 둘 이상의 워크플로에 속할 수 있으며, 각 워크플로는 변수를 서로 다른 값으로 설정하거나 아예 설정하지 않을 수 있습니다. 저장 시 검사는 어느 워크플로에서 저장하는지 알지만 스캔은 알지 못합니다. Weave는 하나를 골라 정상 작동하는 식을 오류로 판정할 위험을 감수하는 대신, 변수가 모든 곳에서 설정되어 있지 않거나 서로 다른 값으로 설정된 경우 단계를 검사되지 않음으로 보고합니다. 역할상 표시되지 않는 워크플로도 같은 방식으로 취급됩니다. Weave는 그 워크플로의 변수도 읽을 수 없으므로 단계가 일치한다고 주장하지 않습니다. 모든 워크플로가 일치하는 경우에는 단계를 정상적으로 판단합니다.
  • 이 검사가 읽지 않는 필터와 열 목록. 일부 단계 유형은 필터나 두 번째 열 목록을 식 검사가 한 번도 읽은 적 없는 양식 부분에 보관합니다. 두 테이블 조인과 Lookup, 배부 분할, Generate Batch, SAP Post Journal Entry가 해당합니다. 이러한 단계를 저장할 때는 항상 해당 필드를 건너뛰었으므로, Weave는 읽을 수 있는 절반만으로 단계를 통과시키지 않고 검사되지 않음으로 보고합니다. 다중 테이블 조인 및 Delete 단계도 같은 방식으로 보고됩니다. 구성이 이 검사가 컴파일할 수 있는 형태가 아니기 때문입니다.

워크플로에 두 번 나열된 항목. 같은 워크플로에 어떤 단계나 중첩된 워크플로도 두 번 이상 나타나지 않는지, 같은 상위 항목을 공유하는 두 폴더가 같은 식별자를 갖지 않는지 검사합니다.

읽는 테이블이 기록되기 전에 실행될 수 있는 단계. 고급 워크플로에서 테이블을 읽는 모든 단계가 캔버스의 커넥터를 통해 같은 워크플로에서 그 테이블을 기록하는 단계 다음에 실행되는지 검사합니다. Weave는 워크플로가 실행된 적이 있는지와 관계없이 이를 검사합니다. 결과 항목에는 그러한 단계 하나와 그 단계가 뒤이어 실행되어야 하는 단계, 그리고 영향을 받는 단계 수가 표시되며, 테이블은 Weave가 아는 방법 아래에 나열됩니다. 캔버스가 이미 너무 일찍 실행하는 단계는 따로 보고됩니다. 단계가 다른 워크플로를 실행하거나 Weave가 추적할 수 없는 테이블을 사용하는 경우 Weave는 워크플로를 검사되지 않음으로 보고하며, 둘 이상의 단계 또는 다른 워크플로도 기록하는 테이블은 판단하지 않습니다. 누락된 커넥터를 검토하고 추가하려면 캔버스에서 종속성 동기화를 사용하십시오. 단계가 이전 실행의 출력을 읽도록 의도된 경우에는 결과 항목을 예상된 항목으로 표시하십시오.

워크플로 실행 방식. Weave는 지난 30일 동안의 각 워크플로 실행을 워크플로별로 가장 최근 실행 최대 20개까지 읽고, 최신 실행을 그 이전 실행과 비교하여 판단합니다. 아래의 월말 및 요일 비교를 위해서는 지난 180일 중 더 오래된 실행도 몇 개 읽습니다. 모든 비교는 다른 워크플로가 아닌 해당 워크플로 자체의 기록을 기준으로 합니다.

  • 마지막 실행 실패. 가장 최근 실행이 실패한 워크플로를 보고하며, 실패 날짜와 함께, 그 이전 실행도 실패한 경우 연속으로 몇 번 실패했는지와 언제부터인지를 알려 줍니다.

  • 평소보다 느린 실행. 완료되었지만 단계 실행 시간의 합이 워크플로의 이전 완료 실행에서 허용되는 범위보다 긴 실행입니다. 즉 그 평균보다 표준 편차의 두 배를 초과하여 길고, 평균보다 5% 이상 긴 경우입니다(빠른 워크플로가 몇 밀리초 차이로 보고되지 않도록 차이는 최소 1초). 시간은 단계 시간을 합한 것이므로, 단계를 병렬로 실행하는 워크플로에서는 실제 경과 시간보다 깁니다. 더 빨리 끝난 실행은 보고되지 않습니다.

  • 평소보다 느린 단계. 해당 워크플로에서 최근 완료된 실행에서 이전 완료 실행보다 오래 걸린 단계로, 느린 실행과 같은 기준으로 판단합니다. Weave는 이렇게 느린 실행의 원인이 된 단계를 밝힙니다. 여러 워크플로에 속한 단계는 각 워크플로에서 따로 판단됩니다. 시간은 단계의 시작부터 완료까지이며, Weave는 단계 자체의 작업 시간과 사용 중인 웨어하우스를 기다리는 시간 같은 대기 시간을 구분하지 않습니다.

  • 점점 느려지는 실행. 지속되는 속도 저하입니다. 느린 실행이 비교 대상 이전 실행의 대부분을 차지하게 되면 느린 실행이 더 이상 특이해 보이지 않으므로, 이 검사는 대신 두 절반을 비교합니다. Weave는 지난 30일 중 워크플로의 최근 실행 20개를 읽고, 완료된 실행만 남긴 다음, 시작 시각을 기준으로 이전 절반과 최근 절반으로 나눕니다. 최근 절반의 중앙값 시간이 이전 절반보다 25% 이상이면서 30초 이상 길고, 최근 실행과 이전 실행의 쌍 중 85% 이상에서 최근 실행이 더 오래 걸린 경우 워크플로를 보고합니다. 시간은 느린 실행과 마찬가지로 단계 시간을 합한 것입니다. Weave에는 최소 14일에 걸친 완료된 실행이 12개 이상 필요하므로, 2주 동안 약 20회를 넘게 실행되는 워크플로는 검사되지 않습니다. 실패하거나 중지된 실행은 계산에 포함되지 않지만, 실패한 단계를 지나 계속 진행된 실행은 포함됩니다. 결과 항목에는 사용자가 열 수 있는 단계 중 중앙값 시간이 가장 많이 늘어난 단계를 최대 3개까지 표시하며, 속도 저하가 지속되는 동안 문장이 바뀌지 않으므로 실행할 때마다 다시 알림을 받지 않습니다.

  • 이전 실행과 다른 대상 행 수. 해당 워크플로에서 마지막 실행 후 출력 테이블의 행 수가 이전 실행 후보다 훨씬 많거나 훨씬 적은 단계로, 같은 기준(그리고 최소 1행 이상의 차이)으로 판단합니다. 행 수는 테이블에 들어 있는 행의 수이므로, 행을 추가하는 단계는 늘어나는 총계를 기준으로 판단됩니다. 여러 워크플로에 속한 단계는 각 워크플로에서 따로 판단됩니다.

  • 평소보다 많은 행을 중복한 조인. 기본 테이블의 행마다 기록한 행 수가 해당 워크플로의 이전 실행 후보다 많은 내부, 왼쪽 또는 오른쪽 조인입니다. 즉 그 평균보다 표준 편차의 두 배를 초과하여 많고, 평균의 5% 이상 많은 경우입니다. 기본 테이블은 내부 또는 왼쪽 조인에서는 Table A, 오른쪽 조인에서는 Table B입니다. 기본 테이블 행당 둘 이상의 행이 기록되었다면 일부 조인 키가 다른 테이블의 둘 이상의 행에 나타난다는 뜻이므로, 그 키를 가진 행이 두 번 이상 기록된 것입니다. Weave는 1.00을 초과하는 수치만, 그리고 그 수치가 조인의 평소 수준보다 높을 때만 보고하므로, 설계상 행마다 여러 행을 기록하는 조인은 그 수치가 올라갈 때만 보고됩니다. 내부 조인의 경우 Table B에서 반복되는 키만 감지됩니다. 기본 테이블의 행 수가 기록된 이전 실행이 4개 미만인 조인은 검사되지 않음으로 보고됩니다.

    집계를 하거나 고유, 슬라이싱(Limit) 또는 Secondary Filter를 사용하는 조인은 각각 행 수 자체를 바꾸므로 검사되지 않음으로 보고됩니다. 뷰처럼 기본 테이블에 기록된 행 수가 없는 조인도 마찬가지입니다. 기본 테이블의 행 수는 해당 테이블이 마지막으로 기록될 때 기록된 값으로, 단계의 필터가 적용되기 전의 값입니다. 실행할 때마다 다른 비율의 행을 남기는 필터도 수치를 움직이므로 보고될 수 있습니다. 다른 방법으로 기본 테이블을 변경하거나 동시에 실행되는 단계가 변경한 경우에는 감지되지 않습니다. 완전 외부 조인, 교차 조인, 다중 테이블 조인은 검사되지 않으며, Lookup은 행을 두 번 이상 기록할 수 없습니다.

  • 이전 실행과 다른 빈 값. 단계의 출력 테이블에서 단계의 이전 실행 후보다 훨씬 크거나 작은 비율의 행이 비어 있는 열입니다. 즉 평소 비율에서 표준 편차의 두 배를 초과하여 벗어나고, 5%포인트 이상 차이가 나는 경우입니다. 단계가 기록하는 각 테이블은 그 테이블의 행을 기준으로 판단됩니다.

  • 가져오기에서 파일을 찾지 못함. 가장 최근에 완료된 실행에서, 읽어 오는 경로에서 파일을 찾지 못한 가져오기 단계입니다. 이 단계는 실패하지 않고 경고와 함께 끝나며, 대상 테이블을 빈 상태로 만들거나 아무것도 로드하지 않으므로 이후 단계는 이 단계로부터 읽을 내용이 없습니다. 결과 항목에는 워크플로와 경로가 표시되며, 이전 실행이 필요 없고, 실행에서 파일을 찾으면 사라집니다. 여러 워크플로에 속한 단계는 각 워크플로에서 따로 판단되며, 사용자가 열 수 없는 워크플로에서는 경로가 표시되지 않습니다. Weave는 의도적으로 비어 있는 폴더와 누락된 파일을 구분할 수 없습니다. 해당 위치에서 빈 폴더가 정상이라면 프로젝트 아키텍트가 결과 항목을 예상된 항목으로 표시할 수 있으며, 그러면 Weave는 경로와 관계없이 해당 워크플로의 해당 단계에 대해 이 결과를 더 이상 보고하지 않습니다. 이 검사가 생기기 전에 기록된 실행에는 경고 문구가 남아 있지 않으므로, 해당 단계는 다시 실행될 때까지 검사되지 않음으로 보고됩니다.

월말 및 요일. 하루에 최대 한 번 실행되는 워크플로나 단계의 경우, 이러한 검사에서 보고될 실행이라도 지난 180일 중 같은 종류의 날에 있었던 이전 실행 4개 이상과 부합하고, 그 실행들의 변동 폭이 규모 대비 다른 날의 이전 실행보다 크지 않으면 보고에서 제외됩니다. 날의 종류는 월의 마지막 날, 월의 첫날, 그 외에는 같은 요일입니다. 따라서 항상 무거운 월말 로드나 월요일마다 항상 가볍게 실행되는 로드는, 그 실행들이 규모 대비 다른 날보다 안정적이라면 보고되지 않습니다. 달력은 실행을 보고에서 제외하기만 하며, 이러한 검사에서 통과할 실행을 보고하는 일은 없습니다. 날짜는 UTC 기준으로 계산되며, 공휴일과 영업일 달력은 고려되지 않습니다. 하루에 두 번 이상 실행되는 워크플로나 단계는(실패한 실행과 그 재실행 포함) 이전과 같이 이전 실행과 비교됩니다.

기준선에는 이전 실행이 4개 이상 필요합니다. 그보다 적으면 너무 적은 데이터로 판단하는 대신 워크플로는 실행 시간에 대해, 단계는 행 수와 빈 값에 대해 검사되지 않음으로 보고되며, 각각 완료된 실행이 몇 개인지 알려 줍니다. 테이블을 기록하지만 기록된 실행에 빈 값 개수가 없는 단계도 빈 값에 대해 검사되지 않음으로 보고됩니다. 이메일을 보내거나 파일을 내보내는 단계처럼 테이블을 기록하지 않는 단계는 행 수나 빈 값을 검사하지 않습니다. 지난 30일 동안 실행되지 않은 워크플로는 검사되지 않음으로 보고되며, 실행 기록을 읽을 수 없는 워크플로도 마찬가지입니다. 둘 다 정상으로 보고되지 않습니다. 행 액세스가 선언된 프로젝트에서는 읽기가 필터링되는 사용자에게 행 수, 조인, 빈 값, 값 분포 검사가 적용되지 않습니다. 각 검사는 테이블 전체를 대상으로 측정되므로, 결과 항목이 해당 사용자에게 권한 범위를 벗어난 행에 대해 알려 줄 수 있기 때문입니다. 행 수 및 테이블 크기를 참조하십시오.

단계의 마지막 실행이 변경한 내용. 단계의 마지막 실행이 기록한 각 테이블에 대해, Weave는 실행 후의 테이블과 실행 시작 전의 테이블을 비교하므로 이전 실행 기록이 필요하지 않습니다.

  • 마지막 실행 전과 다른 값 분포. 실행 후 값이 범위 전체에 분포한 양상이 실행 전과 매우 다른 열입니다. 결과 항목에는 변화 점수가 표시됩니다. 0은 분포가 바뀌지 않았다는 뜻이고, 0.25 이상은 큰 변화로, 이때 Weave가 보고합니다. 소수를 담은 열만 비교합니다. 정수 열은 보통 계정 번호나 월처럼 코드, 기간 또는 플래그이며, 새 기간이 로드될 때마다 분포가 바뀝니다. 빈 값은 분포에 포함되지 않으며, 위의 빈 값 검사에서 다룹니다.

“실행 전”은 행이 들어 있던 테이블의 마지막 버전입니다. 중간에 실패한 실행으로 인해 비어 있게 된 버전은 건너뛰므로, 실패 후 첫 번째 정상 실행은 마지막 정상 데이터와 비교됩니다.

단계가 기록한 테이블이 다음 중 하나에 해당하면, 해당 단계의 실행은 이유와 함께 검사되지 않음으로 보고됩니다.

  • 열에 행 액세스가 선언되어 있는 경우
  • 실행 전이나 후에 행이 5,000,000개를 넘는 경우
  • 비교하는 데 10초 넘게 걸린 경우
  • 실행 전 버전이 더 이상 보관되어 있지 않은 경우. 일부 Lakehouse는 테이블의 이전 버전을 7일 동안 보관하므로, 일주일에 한 번보다 드물게 다시 기록되는 테이블은 비교할 대상이 없습니다.
  • 해당 실행에서 처음으로 채워진 경우

Lakehouse가 버전 기록을 보관하지 않는 프로젝트는 이 검사에서 전혀 판단되지 않습니다.

형식 변환으로 비어 버린 값. Extract 단계가 기록하는 각 열에는 텍스트, 정수, 날짜 같은 형식이 있으며, 단계는 모든 값을 그 형식으로 변환합니다. StarRocks Lakehouse에서는 N/A를 정수 열에 넣는 경우처럼 변환할 수 없는 값이 빈 값으로 저장되며, 실행은 오류 없이 끝납니다. Extract 단계가 StarRocks에서 실행된 후, Weave는 변환으로 값이 손실될 수 있는 각 열에 대해 들어가기 전에 비어 있지 않던 값의 수와 그중 빈 값으로 나온 수를 세고, 그런 값이 하나라도 있는 열을 각각 보고합니다. 결과 항목에는 개수와 열의 형식이 표시됩니다. 각 워크플로에서 단계의 최신 완료 실행을 판단하므로, 이전 실행이 필요하지 않습니다.

  • 들어가기 전에 이미 비어 있던 값은 계산하지 않습니다. 빈 텍스트는 숫자나 날짜 열에 빈 값으로 저장되므로 계산합니다.
  • 정수를 소수 열에 넣는 경우처럼 변환으로 값이 손실될 수 없는 열은 계산하지 않으며, 실행 후 빈 값이 없는 열도 계산하지 않습니다.
  • 계산이 30초 넘게 걸리거나 Weave가 센 행이 단계가 기록한 행과 일치하지 않으면, 해당 실행은 검사되지 않음으로 보고되고 Weave는 다음에 단계가 실행될 때 다시 셉니다.
  • StarRocks의 Extract 단계만 검사합니다. Secondary Filter를 사용하거나 식으로 그룹화하는 단계는 검사되지 않음으로 보고되며, 열의 값이 손실될 수 있을 때 고유 또는 슬라이싱(Limit)을 사용하는 단계도 마찬가지입니다. Weave가 변환 없이 행을 다시 셀 수 없기 때문입니다.
  • 단계가 그러한 값을 비워 두도록 의도된 경우, 프로젝트 아키텍트가 결과 항목을 예상된 항목으로 표시할 수 있습니다.
  • 행 수 및 빈 값 검사와 마찬가지로, 행 액세스로 읽기가 필터링되는 사용자에게는 적용되지 않습니다.

예약된 이벤트. 예약된 이벤트가 있는 워크플로의 경우, Weave는 각 이벤트를 그 이벤트가 시작한 실행 및 이벤트를 실행하는 클러스터의 작업과 비교합니다. 각 시각은 이벤트 자체의 시간대를 기준으로 하며, 작업이 시작될 시간을 주기 위해 실행 예정 시각 15분 후에 판단합니다.

  • 예약된 이벤트 일정이 유효하지 않음. 일정을 읽을 수 없는 활성화된 이벤트입니다.
  • 예약된 실행이 시작되지 않음. 마지막으로 실행을 시작한 이후, 또는 한 번도 시작한 적이 없다면 저장된 이후, 실행 예정 시각이 되었는데도 실행을 시작하지 않은 활성화된 이벤트입니다. 클러스터에서 확인할 수 있는 경우, Weave는 클러스터가 이벤트를 아예 실행하지 않았는지 아니면 실행한 작업이 실패했는지를 덧붙입니다. 결과 항목에는 이벤트가 시작한 마지막 실행 또는 이벤트가 저장된 시각이 표시되므로, 이벤트가 같은 방식으로 고장 나 있는 동안에는 하나의 결과 항목으로 유지됩니다. 실행 예정 시각 이후에 저장된 이벤트는 그 실행에 대해 판단되지 않습니다.
  • 실행 중에 예약된 이벤트의 예정 시각이 됨. 워크플로가 아직 실행 중일 때 예정 시각이 되어 그때 실행이 시작되지 않은 이벤트입니다. 예약된 이벤트는 이미 실행 중인 워크플로의 두 번째 실행을 시작하지 않습니다. 워크플로 실행 시간보다 촘촘한 일정이 아무도 모르게 실행 기회를 잃지 않도록 이 내용을 한 번 보고합니다.
  • 클러스터와 일치하지 않는 예약된 이벤트. 이벤트와 클러스터의 작업이 서로 일치하지 않는 경우입니다. 작업이 없거나 작업이 일시 중지된 활성화된 이벤트, 작업이 일시 중지되지 않은 비활성화된 이벤트, 또는 이벤트에 표시된 것과 다른 일정이나 시간대로 설정된 작업이 해당합니다. 클러스터를 읽을 수 없는 경우 워크플로는 예약된 이벤트에 대해 검사되지 않음으로 보고됩니다.

실행을 더 이상 시작하지 않는 이벤트는 알려 줄 실행 종료가 없으므로, 메시지가 아니라 Weave 탭에 표시됩니다.

일정에 따라 기록되는 테이블. 활성화된 예약된 이벤트가 있는 워크플로가 기록하는 테이블의 경우, Weave는 일정의 마지막 예정 시각 이후 테이블이 기록되었는지 검사합니다. 테이블은 그 테이블을 기록하는 단계가 완료되면 기록된 것으로 간주됩니다. Weave는 테이블의 데이터를 살펴보지 않으므로 프로젝트 단계 밖에서 이루어진 로드는 감지하지 않습니다. 예약된 이벤트 검사와 마찬가지로 각 일정은 해당 이벤트의 시간대로 읽고 예정 시각 15분 후에 판단합니다. Weave는 역할상 볼 수 있는 테이블만 검사합니다. analyze.table.read 역할이 없으면 테이블을 검사하지 않으며, 첫 줄에는 단계와 워크플로만 집계됩니다.

  • 일정에 따라 기록되지 않은 테이블. 테이블을 기록하는 워크플로가 일정상 예정 시각이 된 이후 어떤 단계도 기록하지 않은 테이블입니다. 다른 워크플로의 단계나 사용자가 직접 시작한 실행을 포함하여 어떤 단계의 기록이든 인정됩니다. 결과 항목에는 마지막 기록 이후 경과 시간이 아니라 마지막 기록 시각이 표시됩니다. 실패한 실행은 기록되지 않은 것으로 간주되므로, 실패하는 예약된 워크플로의 테이블은 마지막 실행 실패뿐 아니라 여기서도 보고됩니다.

다음 경우 Weave는 테이블을 기록되지 않음이 아닌 검사되지 않음으로 이유와 함께 보고합니다.

  • 테이블을 기록하는 워크플로가 실행 중이거나 대기열에 있거나, 방금 끝나서 결과가 아직 기록되지 않은 경우
  • 테이블을 기록하는 단계가 일정의 예정 시각 이후 실행에서 자체 조건 때문에, 또는 파일이 변경되지 않은 가져오기처럼 할 일이 없어서 건너뛰어진 경우
  • 테이블을 기록하는 단계가 건너뛴 기록 없이 건너뛰어질 수 있는 경우. 즉 다른 단계로 이동하는 조건이 있는 표준 워크플로에 있거나, 실패 시 다른 단계로 이동하는 단계가 있는 표준 직렬 워크플로에 있거나, 조건이 있는 컨테이너 또는 0회 실행될 수 있는 루프 안에 있는 경우
  • 워크플로가 예정 시각 이후 실행을 완료했지만 그 실행에서 기록 단계의 기록이 누락된 경우
  • 프로젝트의 어떤 단계가 Weave가 값을 알아낼 수 없는 변수로 기록할 테이블을 선택하여, 이 테이블을 기록할 수도 있는 경우
  • 일정이 180일에 한 번보다 드물게 실행되는 경우. 180일은 Weave의 실행 기록이 거슬러 올라가는 최대 기간입니다.
  • 워크플로의 일정이 유효하지 않거나 실행 기록을 읽을 수 없는 경우

다음 경우에는 테이블을 전혀 검사하지 않습니다.

  • 최신 상태 임계값(아래 참조)이 없고, 자체적으로 활성화된 예약된 이벤트가 있는 워크플로가 테이블을 기록하지 않는 경우. 다른 워크플로가 워크플로 실행 단계나 매크로 단계를 통해, 또는 내부에 배치된 워크플로로 실행하는 워크플로는 자체 일정을 통해서만 인정됩니다.
  • 테이블을 기록하는 단계가 모두 비활성화되어 있거나, 비활성화된 컨테이너에 있거나, 중단점 또는 그 이후에 있는 경우
  • 뷰인 경우

이 중 두 번째는 실행되는 루프 안에서는 적용되지 않습니다. 루프는 비활성화되어 있거나, 비활성화된 컨테이너에 있거나, 중단점 또는 그 이후에 있는 단계까지 포함해 루프 안의 모든 단계를 실행합니다.

마지막 예정 시각 이후에 저장된 예약된 이벤트는 다음 예정 시각이 될 때까지 판단되지 않습니다.

실행 시간이 일정 간격보다 긴 워크플로는 실행 중에 예정 시각이 된 실행을 건너뛰므로, 실행과 실행 사이에 테이블이 기록되지 않음으로 보고될 수 있습니다. 실행 중에 예약된 이벤트의 예정 시각이 됨 결과 항목이 그 원인을 보고합니다.

테이블을 마지막으로 기록한 단계가 사용자가 액세스할 수 없는 단계인 경우, 결과 항목에는 “액세스할 수 없는 단계”라고 표시되며 기록 시각은 그대로 표시됩니다. 결과 항목의 “180일”은 Weave의 실행 기록이 거슬러 올라가는 기간이며, 테이블에 대한 사실이 아닙니다.

최신 상태 임계값이 있는 테이블. 최신 상태 임계값은 테이블 기록 사이에 지날 수 있는 최대 시간으로, 1시간부터 4,320시간(180일)까지 지정할 수 있습니다. 임계값이 있는 테이블은 그 테이블을 기록하는 워크플로의 일정 대신 임계값을 기준으로 판단됩니다. 이를 통해 일정보다 느슨하거나 엄격한 기준을 설정할 수 있고, 예약된 워크플로가 기록하지 않는 테이블도 검사할 수 있습니다. 일정과 마찬가지로 테이블은 그 테이블을 기록하는 단계가 완료되면 기록된 것으로 간주됩니다.

  • 설정된 시간 안에 기록되지 않은 테이블. 임계값보다 오랫동안 어떤 단계도 테이블을 기록하지 않았습니다. 결과 항목에는 마지막 기록 시각과 임계값이 표시됩니다.

다음 경우 Weave는 임계값이 있는 테이블을 기록되지 않음이 아닌 검사되지 않음으로 이유와 함께 보고합니다.

  • 테이블을 기록하는 워크플로가 실행 중이거나 대기열에 있거나, 방금 끝나서 결과가 아직 기록되지 않은 경우
  • 테이블을 기록하는 워크플로가 임계값이 지난 후 실행을 시작하여 완료했지만, 그 실행에서 기록 단계의 기록이 누락된 경우
  • 프로젝트의 어떤 단계가 Weave가 값을 알아낼 수 없는 변수로 기록할 테이블을 선택하여, 이 테이블을 기록할 수도 있는 경우
  • 직접 로드하는 테이블처럼 프로젝트의 어떤 단계도 테이블을 기록하지 않아, Weave가 기준으로 삼을 기록이 없는 경우
  • 실행 기록을 읽을 수 없는 경우

건너뛴 단계는 임계값이 있는 테이블을 검사되지 않음으로 만들지 않습니다. 테이블이 임계값보다 오랫동안 기록되지 않은 것은 여전하기 때문입니다. 뷰에는 임계값을 지정할 수 없으며, 테이블을 뷰로 만들면 임계값이 지워집니다. 테이블의 복사본이나 테이블의 스냅샷에서 만든 테이블은 임계값 없이 시작합니다.

임계값을 설정하려면 프로젝트의 테이블 목록에서 테이블을 선택하고 테이블 세부 정보 보기/편집을 선택하십시오. 최신 상태 아래에서 Warn if this table isn’t written for more than을 선택하고 시간을 입력한 다음 Update를 클릭하십시오. 임계값을 제거하려면 확인란을 선택 취소하십시오. 임계값이 설정되지 않은 동안 이 상자에는 테이블 판단 기준이 되는 일정을 가진 예약된 워크플로가 표시되거나, 사용자가 열 수 있는 워크플로 중 일정에 따라 이 테이블을 기록하는 워크플로가 없다고 표시됩니다. 뷰나 만들고 있는 테이블에는 최신 상태가 나타나지 않고, analyze.workflow.read 역할이 없어도 나타나지 않으며, 이를 변경하려면 analyze.table.write가 필요합니다.

PlaidCloud MCP를 통해 연결된 AI 어시스턴트에게 테이블의 최신 상태 임계값을 설정하도록 요청하거나(도구는 table_upsert이며 freshness_max_age_hours를 사용합니다), 플랫폼 API를 호출할 수도 있습니다.

PUT /rest/v1/analyze/weave/freshness
{"project_id": "<project>", "table_id": "<table>", "freshness_max_age_hours": 24}

임계값을 지우려면 숫자 대신 null을 보내십시오. 그러면 테이블은 다시 기록 워크플로의 일정을 기준으로 판단됩니다. GET /rest/v1/analyze/weave/freshness?project_id=<project>&table_id=<table>는 임계값과, 임계값이 없을 때 테이블 판단 기준이 되는 일정을 가진 예약된 워크플로인 scheduled_writers를 반환합니다. 임계값을 읽으려면 analyze.table.read 및 analyze.workflow.read 역할이 필요하고, 설정하려면 analyze.table.write 및 analyze.workflow.read가 필요합니다. 임계값은 역할상 볼 수 있는 테이블에만 설정할 수 있으며, 프로젝트가 잠겨 있는 동안에는 설정할 수 없습니다.

워크플로가 읽은 후 다른 워크플로가 기록한 테이블. 다른 워크플로가 기록하는 테이블을 읽는 워크플로의 경우, Weave는 워크플로가 테이블을 마지막으로 읽은 이후 다른 워크플로가 그 테이블에 기록하지 않았는지 검사합니다. 테이블은 그 테이블을 입력 또는 출력으로 지정하고 실행에서 완료된 단계에 의해 읽히거나 기록된 것으로 간주됩니다. Weave는 테이블의 데이터가 아니라 실행 기록에 기록된 내용을 읽습니다.

  • 마지막으로 읽은 후 기록된 테이블을 읽음. 워크플로가 자신의 실행 중 하나에서 테이블을 마지막으로 읽었는데 그 이후 다른 워크플로가 그 테이블에 기록하여, 결과가 최신이 아닐 수 있습니다. 결과 항목에는 테이블을 마지막으로 읽은 실행과 테이블에 기록한 워크플로가 표시됩니다. 활성화된 예약된 이벤트가 있는 워크플로, 또는 그러한 이벤트가 있는 다른 워크플로가 실행하는 워크플로는 기록 이후 자신을 실행하는 일정의 예정 시각이 된 다음에만 보고되며, 일정에 따라 실행되지 않는 워크플로는 즉시 보고됩니다.

다음은 이후 기록된 것으로 간주하지 않습니다.

  • 워크플로 자체의 기록. 워크플로: 실행, 워크플로: 반복 또는 워크플로: 조건부 실행 단계를 통해 워크플로가 실행하는 워크플로가 실행 중에 한 기록을 포함합니다.
  • 스테이징 테이블처럼 워크플로가 실행에서 어떤 단계가 읽기 전에 기록하는 테이블. 단, 테이블의 다른 행을 유지하는 테이블: 추가 또는 테이블: 업서트 단계나 필터가 있는 테이블: 제자리 삭제 단계가 기록한 경우는 예외입니다.
  • 기록한 단계가 마지막으로 저장되기 전에 이루어진 기록. 그 당시에는 단계가 다른 테이블에 기록했을 수 있기 때문입니다.

다음 경우 Weave는 워크플로를 뒤처짐이 아닌 검사되지 않음으로 이유와 함께 보고합니다.

  • 워크플로가 실행 중이거나, 방금 끝나서 결과가 아직 기록되지 않은 경우
  • 테이블을 읽는 단계가 기록 이후 실행에서 건너뛰어진 경우
  • 워크플로를 실행하는 일정이 유효하지 않은 경우
  • 다른 워크플로가 테이블에 기록했거나 기록했을 수 있는데, 최근 실행 중 테이블 읽기를 완료한 실행이 없는 경우
  • 테이블을 읽는 단계가 마지막으로 성공한 실행이 시작된 이후 저장되어, Weave가 그 실행이 테이블을 읽었는지 알 수 없는 경우. 단계가 읽는 내용을 전혀 바꾸지 않는 저장도 포함하여 모든 저장이 해당됩니다.
  • 단계 중 하나가 AI: LLM 단계, Report 단계, 실행: 원격 Python 단계, 또는 테이블: 중복 제거 유니온이나 테이블: 전체 유니온 단계처럼 여러 테이블을 읽으면서 그중 하나를 검색으로 찾는 단계와 같이 Weave가 단계 설정에서 알아낼 수 없는 테이블을 읽거나, 변수로 테이블을 선택하거나, 둘 이상의 테이블이 가진 이름으로 테이블을 지정하거나, 뷰를 읽거나, 다른 프로젝트의 테이블을 읽는 경우
  • 워크플로가 읽는 테이블에 Weave가 실행을 볼 수 없는 매크로가 기록하거나, 이후 실행된 다른 워크플로의 단계 중 변수로 기록할 테이블을 선택하거나, 둘 이상의 테이블이 가진 이름으로 테이블을 지정하거나, Weave가 알아낼 수 없는 테이블에 기록하는 단계가 기록하는 경우
  • 실행 기록을 읽을 수 없는 경우

지난 30일 동안 실행되지 않은 워크플로는 이 방식으로 검사하지 않습니다.

이 검사에서 감지하지 못하는 내용:

  • Weave가 읽는 실행 기록(지난 30일, 워크플로별 최근 실행 20개)보다 오래된 읽기 및 기록
  • 테이블을 확인하는 단계 조건. 이는 테이블을 읽는 것으로 간주되지 않습니다.
  • 워크플로가 같은 실행에서 행을 추가한 후 읽는 테이블에 다른 워크플로가 한 기록. 단, 테이블: 추가 또는 테이블: 업서트 단계로 행을 추가하는 경우는 예외입니다.
  • 워크플로의 다른 단계가 같은 테이블을 더 최근에 읽은 경우, 한 단계의 이전 읽기
  • 변수로 테이블을 선택하거나 Weave가 알아낼 수 없는 테이블에 기록하는 단계가 매크로 안에서 한 기록
  • 기록 단계가 마지막으로 저장되기 전에 이루어진 기록. 저장이 기록 대상을 전혀 바꾸지 않았더라도 해당 워크플로가 다시 실행될 때까지는 감지되지 않습니다.

analyze.table.read 역할이 없으면 어떤 워크플로도 이 방식으로 검사되지 않습니다. 기록했거나 읽힌 워크플로 또는 테이블이 사용자가 액세스할 수 없는 항목인 경우, 결과 항목에는 개수 없이 “액세스할 수 없는 워크플로” 또는 “액세스할 수 없는 테이블”이라고 표시됩니다.

Weave에 규칙이 없는 유형의 단계는 문제없음이 아니라 다루지 않음으로 보고됩니다.

실패한 실행에 의존하는 테이블. 워크플로의 마지막 실행이 테이블을 기록하는 단계가 완료되기 전에 실패하면, 그 테이블에는 이전 데이터가 그대로 남아 있거나 새 데이터의 일부만 들어 있습니다. Weave는 프로젝트의 워크플로 전반에 걸쳐 그 테이블을 읽는 단계와 그 단계가 기록하는 테이블을 따라가며, 그 테이블에 의존하는 항목을 보고합니다.

  • 실패한 실행이 완료하지 못한 테이블을 읽음. 워크플로가 그 테이블, 또는 몇 단계를 거치든 그 테이블에서 만들어진 테이블을 읽습니다. 결과 항목에는 워크플로가 읽는 테이블, 실패한 실행이 완료하지 못한 테이블, 실패한 워크플로와 그 실행의 시작 시각이 표시됩니다.
  • 실패한 실행이 완료하지 못한 테이블을 표시함. 대시보드에 그 테이블이거나 그 테이블에서 만들어진 게시된 테이블, 또는 그러한 테이블을 읽는 SQL 데이터 세트에 기반한 차트가 있습니다. Weave는 SQL 데이터 세트의 템플릿 로직을 태그를 제거한 상태로 읽으므로, 한 번도 실행되지 않는 분기에 있는 테이블도 포함될 수 있습니다. 이 결과 항목은 대시보드에 관한 것이며, 대시보드 차트가 표시하는 테이블이 있는 각 프로젝트의 Weave 탭에 나열됩니다.

Weave가 대시보드 “Board Pack”에서 문제를 발견했습니다. 이 대시보드는 테이블 “Sales”에서 만들어진 테이블 “Margin”을 표시하는데, 워크플로 “Import Sales”가 10월 27일 09:15 UTC의 마지막 실행에서 “Sales” 기록을 완료하지 못했으므로 차트에 오래되었거나 불완전한 데이터가 표시될 수 있습니다

실패한 각 워크플로는 별도의 결과 항목이 되며, 해당 워크플로의 마지막 실행이 더 이상 실패하지 않으면 사라집니다. 실패한 워크플로 자체는 여기서 자신의 실행에 대해 알림을 받지 않으며, 이는 해당 워크플로의 마지막 실행 실패 결과 항목이 다룹니다.

다음은 실패한 실행이 완료하지 못한 테이블로 간주하지 않습니다.

  • 조건이 충족되지 않은 단계, 비활성화된 단계, 이미 로드한 파일을 건너뛴 가져오기처럼 단계가 의도적으로 건너뛴 테이블
  • 실행이 건너뛸 수 있는 단계의 테이블. 고급 워크플로가 아닌 워크플로에서는 조건의 goto 또는 직렬 워크플로에서 실패한 단계의 goto가 모든 단계에 해당합니다. 고급 워크플로에서는 조건을 검사하는 실행 컨테이너 안이나 그 이후의 단계, 그리고 루프 안의 단계가 해당합니다.
  • 실패한 실행이 시작된 후 다른 워크플로가 행을 추가하지 않고 전체를 교체한 테이블
  • 워크플로의 경우, 테이블을 읽은 마지막 실행에서 읽기 전에 워크플로 자체가 교체한 테이블

실행 중인 워크플로는 실행이 끝날 때까지 판단되지 않습니다. 실행 기록을 읽을 수 없으면 Weave는 이러한 항목을 문제없음이 아닌 검사되지 않음으로 보고합니다.

이 검사에서 감지하지 못하는 내용:

  • 서버가 중지된 실행처럼 어떤 단계도 실패를 기록하지 않고 끝난 실행, 그리고 누군가 중지한 실행
  • 단계가 변수로 선택하거나, 둘 이상의 테이블이 가진 이름으로 지정하거나, 뷰를 통해 읽거나, 다른 프로젝트에서 읽는 테이블
  • 저장된 쿼리에 기반한 대시보드 차트, 또는 템플릿 로직을 제거하면 Weave가 SQL을 읽을 수 없는 SQL 데이터 세트에 기반한 차트
  • 템플릿이 이름을 만드는 테이블
  • SQL 데이터 세트가 스키마 없이 지정하는 테이블. 단, 데이터 세트 자체의 스키마가 프로젝트의 보고 스키마인 경우는 예외입니다.
  • Snowflake 또는 Databricks 웨어하우스에 있는 프로젝트의 모든 SQL 데이터 세트
  • 게시되지 않은 테이블 및 Panel 앱
  • Weave가 읽는 실행 기록(지난 30일, 워크플로별 최근 실행 20개)보다 오래된 실행

대시보드의 결과 항목은 사용자가 열 수 있는 대시보드에 대해서만 표시됩니다. analyze.table.read 역할이 없으면 두 검사 모두 실행되지 않습니다.

비정상적인 지표 합계. Weave는 매일 프로젝트의 지표를 읽고, 최근 완료된 기간의 값이 평소와 크게 다른 지표를 보고하며, 그 변화의 원인이 된 고객이나 공장 같은 항목을 밝힙니다. 비정상적인 지표 합계를 참조하십시오.

검토는 워크플로를 신뢰하기 전에 그 워크플로 하나를 검사합니다. 검토는 워크플로와 그 단계(워크플로가 실행하는 다른 워크플로의 단계 포함)에 대해 Weave의 검사를 실행하고, Weave가 검토에서만 실행하는 세 가지 검사를 추가로 실행합니다. 이 세 가지 검사는 Weave 탭이 열릴 때마다 읽기에는 너무 많은 내용을 읽기 때문입니다.

  • 자신의 입력으로 되돌아가는 배부. 워크플로가 실행하는 각 배부 단계에 대해, 그 단계가 기록하는 내용이 어떤 단계를 거치든, 어떤 워크플로에서든 배부하는 테이블이나 드라이버 테이블로 다시 흘러 들어가는지 검사합니다. 그렇다면 단계가 배부하는 양이나 배부 방식이 이전 실행에서 배부한 내용에 따라 달라집니다. Weave는 루프가 거치는 단계를 밝히고 루프가 의도된 것인지 확인하도록 요청합니다. 추가 대상 테이블을 읽는 증분 로드처럼 배부 단계를 거치지 않는 루프는 보고되지 않습니다.
  • 배부 드라이버 테이블 및 열. 배부 단계가 사용하는 드라이버 테이블이 존재하는지, 그리고 단계가 그 테이블에서 읽는 모든 열이 있는지 검사합니다. 단계가 상수나 식으로 채우는 드라이버 열은 찾지 않습니다. 다른 곳에서 만들어진 드라이버 테이블은 현재 상태 그대로 검사됩니다. 이 워크플로의 단계가 드라이버 테이블을 만드는 경우에는 그 단계가 실행될 때까지 열을 알 수 없으므로, Weave는 배부를 통과가 아닌 검사되지 않음으로 보고합니다. 단계가 변수나 폴더 경로로 드라이버 테이블을 선택하는 경우, 워크플로가 매크로인 경우, 역할상 테이블을 볼 수 없는 경우에도 배부를 검사되지 않음으로 보고합니다.
  • 이름이 바뀐 열의 행 수준 보안. 워크플로가 기록하는 각 테이블에 대해, 행 수준 보안 속성이 사용하는 차원으로 태그가 지정되었지만 그 속성의 이름을 따르지 않은 열이 있는지 검사합니다. 행 수준 보안은 속성 이름을 딴 열에서만 필터링하므로 그런 열에서는 필터링하지 않습니다. 이 검사에는 프로젝트의 아키텍트 역할이 필요합니다. 다른 사용자의 경우 검토에서 검사하지 않았다고 표시되며, 워크플로가 변수나 폴더 경로로 지정하는 테이블에 대해서도 마찬가지입니다.

검토는 무엇을 발견했는지, 워크플로의 어느 범위에 걸쳐 발견했는지를 말하는 것으로 시작하며, 결코 문제없음이라는 판정으로 끝나지 않습니다.

Weave found 2 problems in the workflow "Q3 Close". It couldn't finish checking 1
of its 8 steps (listed below), so it may have missed problems in those. See below
for what these checks don't cover.
Weave noticed the step "Allocate rent": it uses the column "sq_ft" from its driver
table "Floor space", which doesn't have that column. Pick a column the table has,
or add "sq_ft" to it.
Weave noticed the step "Allocate IT cost": its output flows back into its driver
table "IT driver" through "Build IT driver", so how it spreads what it allocates
depends on what it allocated on an earlier run. Check whether that loop is
intended.
Weave hasn't checked the step "Allocate IT cost" — whether its driver table
"IT driver" has the columns it uses: the step "Build IT driver" builds that
table, so its columns aren't known until that step runs.

역할상 볼 수 없는 단계는 총계에 포함되며, 검토에서 해당 단계를 검사하지 않았다고 표시됩니다.

검토는 검사하지 않는 항목을 나열합니다. 검토에서는 테이블에 대한 Weave의 검사, 즉 일정에 따라 기록되는 테이블이 늦었는지, 워크플로가 읽는 테이블에 이후 다른 워크플로가 기록했는지는 실행하지 않습니다. 이러한 검사는 프로젝트 전체를 읽으며 Weave 탭에서 실행됩니다. 배부 단계가 있는 워크플로의 경우, 배부되는 모든 금액에 일치하는 드라이버 행이나 차원 멤버가 있는지, 소스 테이블과 드라이버 테이블의 수치가 같은 세부 수준인지, 그리고 SQL 안에서 또는 변수로 테이블을 지정하는 단계를 거치는 루프는 검사하지 않습니다.

워크플로를 검토하려면 캔버스나 단계 그리드에서 워크플로를 열고 검사를 선택하십시오. 이 버튼은 워크플로를 편집하고 프로젝트의 테이블을 읽을 수 있는 사용자에게 표시됩니다. Weave 검사 창에는 다음이 순서대로 표시됩니다.

  • 검토의 첫 줄
  • 검토에 요약이 있는 경우 요약(AI 작성)
  • 검토의 문제, 그다음 검사할 수 없음 항목. 요약이 가리키는 문제에는 요약 내 표시가 붙으며, 단계의 결과 항목 옆에 있는 이동을 클릭하면 검사를 선택한 위치에서 해당 단계가 선택됩니다.
  • 항상 마지막에 이 검사에서 다루지 않는 항목

검사를 다시 선택하면 같은 창에서 새 검토가 실행됩니다.

PlaidCloud MCP를 통해 연결된 AI 어시스턴트에게 워크플로 검토를 요청하거나(도구는 workflow_review입니다), 플랫폼 API를 호출할 수도 있습니다. 검토에는 프로젝트의 단계, 워크플로, 테이블에 대한 읽기 액세스가 필요합니다. 위의 세 가지 검사는 Weave 탭에 나타나지 않으며, Weave는 검토에서만 이를 실행합니다.

Weave 검사 창과 플랫폼 API에서는 문제를 발견한 검토에 PlaidCloud 기본 제공 AI가 작성한 한두 문장의 요약과, 먼저 살펴볼 문제가 최대 3개까지 함께 제공됩니다. AI에는 검토의 문제만 제공됩니다. 요약이 반환되기 전에, 요약이 가리키는 문제는 검토 자체의 문제여야 하고, 요약이 인용하는 모든 이름과 쓰는 모든 숫자는 그 문제에 나타나야 하며, “다른 문제 없음” 같은 문구를 사용해서는 안 됩니다. 이 조건을 충족하지 못한 요약은 삭제되며 검토는 요약 없이 반환됩니다. 문제가 없는 검토에는 요약이 없습니다. AI 어시스턴트를 통한 검토에는 요약이 없으며, 어시스턴트가 결과 항목을 직접 읽습니다.

워크플로 실행이 끝나면 Weave는 해당 워크플로를 살펴보고 각 문제의 소유자(결과 항목에 소유자 지정 참조)에게, 그 워크플로와 실행, 단계의 저장된 구성에 대해 보유한 문제 중 소유자가 프로젝트의 Weave 탭에서 아직 읽지 않은 문제를 앱 내 메시지로 알립니다. 소유자가 없거나 소유자가 더 이상 볼 수 없는 문제는 실행의 소유자, 즉 실행을 시작한 사람이나 예약된 실행의 경우 일정을 마지막으로 저장한 사람에게 전달됩니다. 각 문제는 한 번만 언급됩니다. Weave 탭에서 읽지 않은 동안에는 이후 실행에서 다시 언급되지 않으므로, 여러 워크플로를 실행하는 Workflow Loop가 화면을 반복 알림으로 채우지 않습니다. Weave 버튼의 개수에는 읽을 때까지 그 문제가 계속 포함됩니다.

메시지는 30초 동안 화면에 표시되며 Weave 열기 링크가 있습니다. 이 링크를 클릭하면 실행된 워크플로에 관한 결과 항목이 표시된 상태로 프로젝트의 Weave 탭이 열립니다. 메시지의 다른 곳을 클릭하면 메시지가 닫힙니다.

프로젝트에 관한 Weave 메시지가 화면에 표시되어 있는 동안 같은 프로젝트에 관한 새 메시지가 오면, 새 메시지는 아래에 나타나지 않고 기존 메시지에 합쳐집니다. 메시지에는 가장 최근 문장과 그 뒤에 이 프로젝트에 2개 더 있습니다. 같은 줄이 표시되며, 가장 최근 메시지부터 30초 동안 화면에 표시됩니다. 메시지가 서로 다른 워크플로에 관한 것이면 Weave 열기는 Weave 탭 전체를 엽니다. 따라서 짧은 간격으로 연달아 실패한 워크플로들에 대해 각각이 아니라 하나의 메시지를 받습니다. 준비 상태 알림은 항상 별도로 표시됩니다.

문제를 읽은 후에는 그 내용이 바뀔 때만 다시 언급됩니다. 실행 결과 항목은 해당 실행의 날짜, 시각, 개수를 설명하므로, 매일 밤 실패하는 워크플로는 마지막 결과를 읽은 후 다음 실패 시 다시 언급됩니다. 구성 문제는 실행마다 같은 내용을 말하므로, 한 번 읽으면 실행할 때마다 반복되지 않습니다.

중지된 실행은 누가 중지했든 아무것도 보내지 않습니다. Macro Run 또는 Macro Concurrent 단계가 실행한 워크플로는 자체적으로 아무것도 보내지 않으며, 그 호출은 워크플로의 실행으로 계산되지 않습니다. 워크플로 실행 또는 Workflow Loop 단계가 시작한 워크플로는 다른 실행과 마찬가지로 해당 워크플로의 실행입니다. Weave가 검사할 수 없었던 항목은 이 방식으로 전송되지 않으며, 일정에 따라 기록되는 테이블에 관한 결과 항목이나, 워크플로가 읽은 후 다른 워크플로가 기록한 테이블에 관한 결과 항목도 전송되지 않습니다. Weave는 이러한 항목을 실행 사이에 알려 줍니다. 실행 사이에 알림 받기를 참조하십시오.

알림을 받는 것은 읽는 것과 같지 않습니다. 알림은 Weave 탭에서 결과 항목을 읽음으로 표시하지 않으며, 알림의 Weave 열기 링크를 따라가도 마찬가지입니다.

메시지가 알려 주는 각 문제는 헤더의 Weave 버튼 개수에 추가됩니다. 헤더의 Weave 버튼을 참조하십시오.

일부 문제는 아무것도 실행되지 않을 때 나타납니다. 일정에 따라 또는 최신 상태 임계값 안에 기록되지 않은 테이블, 시작되지 않았거나 워크플로가 아직 실행 중일 때 예정 시각이 된 예약된 실행, 마지막으로 읽은 후 다른 워크플로가 테이블에 기록한 워크플로, 실패한 실행이 완료하지 못한 테이블에 의존하는 워크플로나 대시보드가 그렇습니다. 실행 종료로는 이러한 문제를 알려 줄 수 없으므로, Weave는 한 시간마다 각 프로젝트에서 이러한 문제를 검사하고 각 문제의 소유자에게 앱 내 메시지로 알립니다(결과 항목에 소유자 지정 참조).

시간별 검사는 몇 번의 검사에서 발견되든 각 문제를 한 번만 알려 주며, 프로젝트에 대한 첫 검사에서는 얼마나 오래되었든 이미 있는 문제를 알려 줍니다. 문제가 사라졌다가 다시 나타난 후, 또는 문제를 읽은 후 그 내용이 바뀐 경우(예: 이후의 예약된 실행도 시작되지 않은 경우)에만 다시 알려 줍니다. 일정 문제는 워크플로 자체 검사에도 포함되지만, 시간별 검사에서 한 번 알린 후에는 문제를 읽을 때까지 워크플로의 다음 실행이 끝날 때의 메시지에서 반복되지 않습니다. 실행이 끝날 때 알림 받기를 참조하십시오. 한 프로젝트의 여러 문제는 하나의 메시지로 전달되며, 메시지는 문제의 개수를 세고 첫 번째 문제를 인용합니다.

Weave가 프로젝트 “Finance Close”에서 문제 3개를 발견했습니다. 첫 번째는 테이블 “Sales Daily”입니다. 단계 “Load Sales”가 10월 14일 06:00 UTC에 마지막으로 기록했으며, 워크플로 “Nightly Load”는 그 이후 일정에 따라 실행될 예정이었습니다

둘 이상의 워크플로가 기록하는 테이블에는 누군가 소유자를 지정할 때까지 소유자가 없습니다. 이러한 테이블이 일정에 따라 기록되지 않은 경우, Weave는 그 테이블을 기록할 예정이었지만 기록하지 않은 각 워크플로의 소유자에게 알립니다. 소유자가 없는 그 밖의 문제는 전송되지 않고 프로젝트의 Weave 탭에 나열됩니다.

검사는 각 소유자의 권한으로 실행되므로, 메시지에는 역할상 볼 수 있는 항목만 이름으로 표시됩니다. 역할상 프로젝트의 단계와 워크플로를 볼 수 있는 활성 멤버인 경우에만 알림을 받으며, 테이블에 대해서는 테이블을 읽을 수 있는 경우에만 알림을 받습니다.

메시지는 30초 동안 화면에 표시되며 Weave 열기 링크가 있습니다. 이 링크는 프로젝트의 Weave 탭을 열며, 메시지의 모든 문제가 같은 워크플로에 관한 것이면 해당 워크플로가 표시된 상태로 엽니다. 메시지는 로그인한 동안에만 표시되지만, 메시지가 알려 주는 각 문제는 헤더의 Weave 버튼 개수에 추가되므로 놓친 문제도 그곳에 계속 집계됩니다. 알림을 받는다고 결과 항목이 읽음으로 표시되지는 않습니다.

각 결과 항목에는 ID가 있으며, 결과 항목을 읽음으로 표시하면 더 이상 새 항목으로 나타나지 않습니다. 프로젝트의 Weave 탭에서 카드의 읽음으로 표시를 클릭하십시오(결과 항목을 읽음으로 표시 참조). ID는 결과 항목 자체에서 파생되므로, 근본 문제가 바뀌면 해제했던 결과 항목이 새 항목으로 다시 나타납니다. 예를 들어 열 하나를 수정한 후 읽음으로 표시한 단계는 나중에 다른 열에 문제가 생기면 다시 나타납니다.

읽음 상태는 사용자 본인에게만 적용됩니다. 결과 항목을 읽음으로 표시해도 프로젝트의 다른 사용자에게는 읽음으로 표시되지 않습니다.

늦은 테이블을 기록하는 워크플로가 실행 중인 동안 Weave는 대신 그 테이블을 검사되지 않음으로 보고합니다. 그동안 어떤 결과 항목을 읽음으로 표시했는데 실행이 테이블을 기록하지 않고 끝나면, 해당 결과 항목은 새 항목으로 다시 나타납니다.

한 워크플로에 두 번 나열된 서로 다른 두 단계는 두 개의 결과 항목이므로, 하나를 읽음으로 표시해도 다른 하나는 읽지 않은 상태로 남습니다. 이름이 없는 워크플로는 “이름 없는 워크플로”로 표시되며, 실행할 수 없었던 검사는 “마지막 실행 실패”처럼 제목으로 표시됩니다.

다이제스트는 같은 보고서를 아직 읽지 않은 내용으로 줄인 것으로, 같은 어조로 작성됩니다. 언제든지 다이제스트를 요청할 수 있으며, 프로젝트의 Weave 탭으로 이동하는 Weave 열기 링크가 포함된 앱 내 알림으로 받을 수도 있습니다.

Weave가 검사할 수 없었던 결과 항목도 다른 항목과 마찬가지로 다이제스트에 포함됩니다. 이를 조용히 빼 버리는 다이제스트는 세 번째 답이 막으려는 바로 그 안심시키는 침묵이 될 것입니다.