Cloudflare Clairic 추출 모델, 생성 텍스트가 필요 없는 작업 겨냥
Cloudflare가 Cloudflare Clairic 추출 모델을 공개하며, 소프트웨어가 AI에 값을 요청할 때마다 생성 텍스트가 필요하다는 통념에 도전장을 던졌다. 10월 19일 발표된 Workers AI 미리보기는 추출, 계산, 추정, 예측을 겨냥한다. Cloudflare는 이를 System One 모델, 즉 긴 생성형 응답이 아니라 빠르고 범위가 제한된 답변을 위해 설계된 모델이라고 설명한다.
직접적인 비교 대상은 개발자들이 이미 문서를 구조화된 레코드로 전환하는 데 사용하는 범용 언어 모델이다. 이러한 모델은 한 번의 상호작용에서 정보를 추출하고 그 답변을 설명할 수 있다. Clairic은 값 생성 작업과 글쓰기 작업을 분리해, 각 워크플로에 실제로 필요한 기능이 무엇인지 개발자가 선택하도록 한다.
이 구분은 특정 챗봇을 위협하기보다 애플리케이션 설계에 더 직접적인 압력을 가한다. TypeSafe의 Jev는 소프트웨어 내부의 의사결정을 위해 구축된 특화 모델이라는 점에서 유용한 기준점이다. Clairic은 개발자가 사전에 열거할 수 없는 값의 영역으로 Cloudflare식 접근을 확장한다. 검증, 예외 처리, 사람의 검토가 추가된 뒤에도 특화가 전체 워크플로를 개선하는지가 관건이다.
Cloudflare Clairic 추출 모델은 텍스트 생성 과정에서 값을 분리한다
Cloudflare의 추출 모델 미리보기는 Workers AI를 통해 @cf/cloudflare/clairic 형태로 Clairic을 제공한다. 회사는 이 모델이 토큰을 생성하지 않고 유형화된 값을 반환한다고 밝힌다. 유형화된 값은 숫자나 날짜처럼 선언된 형식을 따르므로, 애플리케이션 코드는 예측 가능한 종류의 답변을 받는다.
이 변화는 모델과 애플리케이션 사이의 출력 계약을 달리한다는 의미다.
소프트웨어에는 대체로 유용한 응답보다 더 구체적인 것이 필요하기 때문에 이 계약은 중요하다. 송장 처리 애플리케이션에는 공급업체 식별자, 지급 기한 또는 금액이 필요하다. 대화형 설명은 이러한 필드를 보완할 수는 있어도 대체할 수는 없다. 애플리케이션이 계속 진행되려면 각 필드가 올바른 목적지에 입력되어야 한다.
예시로 매입채무 워크플로를 생각해 보자. 문서가 도착하면 애플리케이션이 관련 필드를 식별하고, 검토자가 승인 전에 불일치를 해결한다. 최종 목적지가 데이터베이스라면 중간 응답의 문장 품질은 기여도가 낮다. 중요한 것은 올바른 정보를 검토 가능한 충분한 근거와 함께 올바른 필드에 전달하는지다.
값을 중심으로 구성된 모델 인터페이스는 이 요구사항을 명시적으로 드러낸다. 개발자는 애플리케이션이 산문에서 정보를 다시 추출하도록 두는 대신, 필요한 것을 직접 명시해야 한다. 이는 모호성이 드러나는 지점을 바꾼다. 정의가 부실한 필드는 모델 품질 문제가 되기 전에 애플리케이션 설계 문제다.
예를 들어 “지급일”은 송장 마감일, 약속된 이체일 또는 예상 정산일을 뜻할 수 있다. 모두 유효한 날짜일 수 있다. 레코드에 어떤 의미가 들어가야 하는지는 애플리케이션 소유자만 정할 수 있다. 예측 가능한 형식은 소프트웨어가 답변을 수용하도록 돕고, 명확한 정의는 올바른 질문을 하도록 돕는다.
이 때문에 Clairic 구조화 추출은 범주명 이상의 주목을 받을 만하다. 요청된 정보를 중심 인터페이스로 다루는 방식을 제시한다. 이 모델은 모든 것을 설명해야 하는 어시스턴트가 아니라, 정의된 필드를 채우는 역할을 맡는 구성 요소가 된다.
그렇다고 Clairic이 모든 문서 워크플로에 가장 적합한 구성 요소라는 뜻은 아니다. 기존 시스템도 문서 처리, 언어 모델, 일반 코드를 결합할 수 있다. 이번 출시는 또 하나의 아키텍처 선택지를 만든다. 그 가치는 다른 곳의 오류를 감추지 않으면서 실제 애플리케이션을 단순화하는지에 달려 있다.
구매자에게 실질적인 결과는 더 구체적인 도입 검토 질문이다. 어떤 모델이 전반적으로 가장 똑똑한지를 묻는 대신, 어떤 구성 요소가 정의된 작업을 가장 신뢰성 있게 처리하는지 물을 수 있다. 작업과 실패 조건이 명확하다면 이처럼 좁은 질문이 평가하기 더 쉽다.
추출 비중이 큰 애플리케이션은 더 구체적인 구매 결정을 마주한다
가장 직접적인 영향을 받는 팀은 지저분한 정보를 반복적으로 레코드로 전환하는 애플리케이션을 구축하는 팀이다. 이들의 과제에는 모델 선택뿐 아니라 문서 준비, 검증, 예외 처리, 통합도 포함된다. 특화 모델은 이 결합된 프로세스를 개선할 때에만 자리를 얻는다.
가치의 관련 단위는 신뢰하기 위해 필요한 작업을 포함한, 수용된 레코드다.
저렴한 모델 응답도 비용이 큰 워크플로를 만들 수 있다. 검토자는 불명확한 필드를 해결하거나, 원본 근거를 찾거나, 일치하지 않는 레코드를 수정하는 데 시간을 쓸 수 있다. 반대로 응답 시간이 더 오래 걸리더라도 후속 개입을 줄인다면 가치가 있을 수 있다. 모델 호출만 평가하면 이러한 상충 관계는 보이지 않는다.
이는 모든 작업에 범용 생성을 기본 중간 단계로 쓰는 팀에 압력을 만든다. 이제 글쓰기와 정보 전달을 구분할 이유가 생겼다. 애플리케이션이 생성된 응답을 한 번도 표시하지 않는다면, 팀은 생성이 그 단계에 어떤 기여를 하는지 살펴봐야 한다.
답은 달라질 수 있다. 일부 문서는 의미가 일관된 단순 필드를 포함한다. 다른 문서는 상충하는 진술을 조정하거나, 예외를 해석하거나, 어느 출처에 권한이 있는지 결정해야 한다. 추출 인터페이스는 원본의 모든 불일치를 자동으로 해결하지 않고도 목적지 필드를 표현할 수 있다.
이 차이는 조직이 업무를 분담하는 방식에 영향을 준다. 특화 구성 요소는 일상적인 레코드를 처리하고, 더 광범위한 모델은 특이 사례를 검토할 수 있다. 또는 다른 구성 요소가 필드를 채우기 전에 언어 모델이 관련 문서 맥락을 식별할 수 있다. 합리적인 경계는 특정 모델 범주에 대한 선호보다 작업을 따른다.
엔터프라이즈 구매자는 입증 가능한 동작과 아키텍처적 약속도 구분해야 한다. 깔끔한 응답 형식은 소규모 테스트에서 관찰할 수 있다. 변화하는 문서 레이아웃 전반에서의 신뢰성 있는 성능에는 더 폭넓은 근거가 필요하다. 운영 비용 절감에 관한 주장은 이를 유지하는 데 필요한 노력을 포함한 주변 프로세스의 근거를 필요로 한다.
지식 근로자에게도 유사한 구분이 있다. 구조화된 레코드는 정보를 더 쉽게 필터링하고, 비교하고, 재사용하게 할 수 있다. 그러나 간결한 필드는 중요한 단서를 제거할 수 있다. 회의록에서 추출한 프로젝트 마감일은 다른 곳에 언급된 미해결 결정에 좌우될 수 있다.
검색 가능한 지식 베이스를 구축하는 팀에는 유용한 설계 질문이 생긴다. 어떤 사실은 필드가 되어야 하고, 어떤 사실은 주변 맥락이 필요한가? 검색과 구조화 추출은 관련된 목적을 수행하지만 원본 자료의 서로 다른 측면을 보존한다.
따라서 단기적인 압력은 애플리케이션 소유자와 통합 담당자에게 가해진다. 이들은 각 단계에 왜 선택한 모델이 필요한지 설명해야 한다. 업계 전반의 대안과 비교해 Clairic의 순위를 매길 독립적인 근거가 충분히 쌓이기 전에도, 이는 구체적인 구매 및 엔지니어링 결정이다.
Clairic 대 언어 모델은 생성이 어디에 필요한지에 관한 문제다
Clairic 대 언어 모델 비교의 가장 설득력 있는 형태는 범용 시스템이 이미 제공하는 기능을 인정한다. Anthropic의 구조화된 출력 문서는 선언된 데이터 구조에 제한된 응답, 즉 스키마 제약 응답을 설명한다. 이러한 기능은 이미 많은 형식화 및 파싱 문제를 해결한다.
Clairic의 경쟁력 주장은 소프트웨어가 파싱할 수 있는 데이터를 반환하는 수준을 넘어야 한다.
응답의 허용된 구조와 유형을 정의하는 스키마는 생성형 모델에 더 좁은 출력 목표를 제공한다. 이는 구조화 생성이 중요한 비교 기준이 되게 한다. 특화 추출기를 제약 없는 산문 요청과만 비교하면 이미 확립된 대안을 놓치게 된다.
아키텍처적 차이는 여전히 중요하다. Cloudflare는 Clairic이 토큰 생성 없이 값을 반환한다고 설명한다. 범용 모델은 필드를 채우는 일을 넘어서는 기능을 제공하면서 응답을 생성한다. 비교는 양쪽 모두 명확히 정의된 작업을 받을 때 각 접근 방식이 무엇을 기여하는지 검토해야 한다.
문서 워크플로는 왜 이것이 중요한지 보여준다. 주문 식별자를 읽는 일과 고객 응답을 작성하는 일은 서로 다른 작업이다. 전자는 원본에서 구체적인 목표를 가진다. 후자는 문구, 어조, 고객에게 어떤 정보가 필요한지에 관한 판단을 요구한다.
한 번의 호출로 이 작업들을 결합하는 것은 편리할 수 있다. 분리하면 각 단계를 더 쉽게 검토할 수 있다. 그러나 인계 과정에는 자체적인 책임이 따르므로 어느 쪽도 자동으로 승리하지 않는다. 애플리케이션은 올바른 맥락을 보존하고 중간 값을 의심할 여지 없는 진실로 취급하지 않아야 한다.
TypeSafe의 System One 모델 출시는 이러한 분업의 선행 사례를 제공한다. 창립자 Diogo Almeida는 Jev를 소프트웨어 내부의 구조화된 의사결정을 위한 모델로 소개했다. 그 역할은 개방형 값을 추출하는 것과 다르지만, 두 접근 방식 모두 애플리케이션 로직이 직접 활용할 수 있는 출력을 강조한다.
유용한 업계 변화는 더 폭넓은 구성 요소 선택지다. 애플리케이션은 필드 추출, 의사결정, 글쓰기를 서로 다른 시스템에 맡길 수 있다. 이는 개발자가 모델 역량을 어디에 투입할지 더 많이 통제하게 하는 동시에, 단계 사이의 명확한 인터페이스 중요성을 높인다.
범용 모델에 더 큰 역할을 유지해야 한다는 타당한 주장도 있다. 예외가 자주 발생하는 워크플로는 문서를 해석하고 불일치를 함께 설명하는 데 이점을 얻을 수 있다. 이 프로세스를 지나치게 쪼개면 애플리케이션이 더 광범위한 모델이 이미 보유한 맥락을 다시 구축해야 할 수 있다.
따라서 올바른 비교에는 통합 복잡성도 포함된다. 단독으로 잘 작동하는 모델도 배포 시 추가 라우팅, 저장소 또는 모니터링이 필요할 수 있다. 더 광범위한 모델은 일상적 요청에서 불필요한 작업을 수행하면서도 통합하기는 더 쉬울 수 있다. 이는 서로 경쟁하는 운영 비용이다.
Clairic 대 언어 모델은 워크로드 문제로 다루는 것이 가장 적절하다. 생성이 필수적인지, 유용한지, 부수적인지는 작업이 결정한다. 이 관점은 특화 모델이 범용 시스템을 없앨 것이라는 잘못된 예측을 피한다. 또한 익숙한 채팅 인터페이스가 모든 자동화 프로세스에 들어가야 한다는 가정도 피한다.
Clairic 구조화 추출은 원본 근거를 인터페이스의 일부로 만든다
Clairic 모델 참고 문서는 텍스트 및 이미지 입력, 신뢰도 정보, 타입이 지정된 필드 정의를 문서화합니다. 추출된 텍스트에는 입력 내 위치를 식별하는 문자 오프셋이 포함될 수 있습니다. 또한 이 참고 문서는 필드 정의가 상태와 함께 들어맞지 않을 때 병렬 처리를 설명합니다.
운영상의 기회는 반환된 값을 더 쉽게 검토하고 분류할 수 있게 만드는 데 있습니다.
검토자에게 답변과 그 출처 위치는 서로 다른 목적을 수행합니다. 답변은 시스템이 무엇을 선택했는지 보여 줍니다. 위치는 그 선택이 왜 적절할 수 있는지 검토자가 살펴보는 데 도움이 됩니다. 둘 다 유지하면 이견을 더 쉽게 해결할 수 있습니다.
원래 배송 주소와 변경 배송 주소가 포함된 지원 메시지를 상상해 보세요. 둘 다 원문에 실제로 존재하는 텍스트입니다. 필드에는 정확히 복사된 주소가 담길 수 있지만, 현재 요청에 맞지 않는 주소를 선택할 수도 있습니다. 검토에는 고객의 의도와 애플리케이션 규칙에 관한 맥락이 필요합니다.
이 지점에서 Clairic의 구조화 추출은 단순한 형식 논의를 넘어섭니다. 유용한 레코드에는 다음 조치를 뒷받침할 만큼 충분한 정보가 담겨야 합니다. 애플리케이션에 따라 원본 문서, 필드 정의 또는 검토 상태가 여기에 포함될 수 있습니다. 모델의 답변은 그 레코드를 구성하는 한 부분입니다.
개발자는 또한 “도출된”이라는 말의 여러 의미를 구분해야 합니다. 명시된 수량을 읽는 일은 합계를 계산하는 일과 다릅니다. 미래 결과를 예측하는 일은 이 둘과도 다릅니다. 공통 인터페이스는 이러한 출력이 비슷해 보이게 할 수 있지만, 그 근거는 서로 다릅니다.
추출된 마감일은 계약서의 문장과 대조할 수 있습니다. 계산된 마감일은 올바른 시작일과 규칙에 따라 달라집니다. 예상 완료일은 미래 행동에 관한 가정에 의존합니다. 애플리케이션은 결과를 사용자에게 제시할 때 이러한 차이를 보존해야 합니다.
그렇지 않으면 공통 데이터 형식의 편리함이 근거 없는 확신을 만들 수 있습니다. 표시된 날짜는 어떤 방식으로 얻었는지와 관계없이 정확해 보입니다. 검토자는 출처 진술을 확인하는지, 계산을 점검하는지, 예측을 평가하는지 알아야 합니다.
이는 제품 설계에도 영향을 줍니다. 인터페이스는 추출된 사실을 원래 맥락과 함께 보여 주는 한편, 추정치는 불확실한 계획 입력값으로 제시할 수 있습니다. 이러한 차이는 사용자가 적절한 수준의 검토를 적용하도록 돕습니다. 또한 예측이 문서화된 사실을 기대하는 시스템에 조용히 들어가는 일을 막습니다.
같은 원칙은 정보가 도구 사이를 이동할 때도 적용됩니다. 불확실한 값이 상태 정보 없이 후속 레코드에 들어가면, 이후 사용자는 이를 확립된 사실로 취급할 수 있습니다. 필드의 의미를 보존하는 일은 데이터 타입을 보존하는 일만큼 중요합니다.
모델 인터페이스는 이 과정을 위한 구성 요소를 제공합니다. 애플리케이션 팀은 어떤 근거를 보존할지, 불확실성을 어떻게 보여 줄지, 언제 검토가 필요한지를 결정할 책임이 있습니다. 이러한 결정은 전문화가 사용자 경험을 개선할지 좌우할 것입니다.
유효한 필드로도 산술, 모호성, 예측 문제는 해결되지 않습니다
Cloudflare의 Clairic 출시 분석은 이 엔드포인트를 초기 단계의 이정표라고 설명합니다. 회사는 다단계 산술과 집계의 약점을 지적하고, 예측 기능은 기초적이라고 설명하며, 익숙하지 않은 데이터에서는 불확실성 구간이 지나치게 좁아질 수 있다고 경고합니다. 또한 오픈 웨이트는 이미 공개된 것이 아니라 공개가 예정되어 있다고 밝혔습니다.
유효한 결과는 형식을 확립할 뿐이며, 정확성에는 별도의 근거가 필요합니다.
Cloudflare의 추출 모델 제한 사항은 이러한 구분을 명확히 합니다. 문서는 타입과 제약 조건이 정답을 보장하지 않는다고 설명합니다. 또한 입력이 거의 정보를 제공하지 않아도 추정과 예측이 결과를 반환할 수 있다고 경고합니다.
이러한 주의 사항은 출시를 해석할 수 있는 범위를 좁힙니다. 전문화된 인터페이스가 근본 작업의 불확실성을 제거하지는 않습니다. 애플리케이션이 결과를 더 예측 가능한 방식으로 받을 수 있게 할 뿐이며, 그 결과가 무엇을 정당화하는지 결정하는 책임은 개발자에게 남습니다.
산술은 특히 명확한 사례를 제공합니다. 애플리케이션에 신뢰할 수 있는 수량과 정의된 공식이 있다면 일반적인 코드로 검토 가능한 계산을 할 수 있습니다. 입력이 정돈되지 않았을 때 모델에게 결과 추론을 요청하는 것은 유용할 수 있습니다. 그러나 입력이 식별된 뒤에는 정확한 계산을 별도로 다뤄야 합니다.
더 어려운 질문은 올바른 입력값이 선택되었는지 여부인 경우가 많습니다. 문서에는 최초 금액, 수정 금액, 크레딧이 함께 있을 수 있습니다. 잘못된 조합으로 완벽하게 산술을 수행해도 결과는 여전히 틀립니다. 평가는 해석과 계산을 독립적으로 검토해야 합니다.
예측은 또 다른 층위를 더합니다. 모델은 운영상 의사 결정을 뒷받침할 만큼 강한 근거 없이도 깔끔하게 형식화된 예측을 반환할 수 있습니다. 구매자는 어떤 정보가 예측을 바꾸는지, 오류가 의도된 사용에 어떤 영향을 미치는지 물어야 합니다.
예를 들어, 예시적인 인력 예측은 근무를 직접 배정하지 않고도 계획 논의에 정보를 제공할 수 있습니다. 같은 예측도 직원 일정을 자동으로 변경하면 더 중대한 결과를 낳습니다. 출력은 바뀌지 않았지만, 애플리케이션에 요구되는 보증 수준은 달라졌습니다.
신뢰도 점수도 비슷한 주의가 필요합니다. 보정이란 보고된 불확실성이 유사한 사례 전반에서 관찰된 결과와 합리적으로 일치한다는 뜻입니다. 하나의 데이터세트에서 설득력 있는 점수가 나왔다고 해서 문서 형식, 언어 또는 비즈니스 조건이 바뀐 뒤에도 동등한 동작이 보장되는 것은 아닙니다.
이 기사를 위해 확인한 독립적인 Clairic 평가는 그러한 조건 전반의 성능을 입증하지 않습니다. 현재 이용 가능한 공식 자료는 제품과 의도된 동작을 설명합니다. 그러나 구매자의 전체 문서 파이프라인에서 어떤 성능을 보일지는 확정하지 못합니다.
이는 억지로 논란을 만들지 않으면서도 낙관론과 회의론이 공존할 여지를 남깁니다. 전문화된 추출은 식별 가능한 소프트웨어 문제를 다룹니다. 해결되지 않은 질문은 배포 후 그 문제 중 얼마나 사라지고, 얼마나 필드 설계·평가·검토로 옮겨 가는가입니다.
따라서 Cloudflare Clairic 추출 모델을 고려하는 팀은 더 깔끔한 인터페이스와 입증된 신뢰성을 구분해야 합니다. 둘 다 중요하지만 서로 다른 근거가 필요합니다. 시연은 인터페이스를 즉시 보여 줄 수 있습니다. 운영 신뢰성은 대표성이 있고 독립적으로 검증된 레코드에 반복 적용하면서 드러납니다.
독립 평가, 오픈 웨이트, 프로덕션 사용을 지켜보세요
가장 유용한 다음 신호는 독립 테스트, 약속된 웨이트 공개, 배포된 애플리케이션의 근거입니다. 각각은 호스팅된 프리뷰와 확립된 인프라 선택지 사이의 서로 다른 간극을 다룹니다. 함께 보면 이 모델 범주가 실질적 이점을 제공하는지 보여 줄 수 있습니다.
다음 근거는 모델의 동작을 애플리케이션이 실제로 완료해야 하는 업무와 연결해야 합니다.
먼저 독립 평가가 필요합니다. 유용한 테스트는 전문화된 추출과 구조화된 생성 시스템에서 동등한 작업을 비교해야 합니다. 필드 정의, 문서 조건, 채점 규칙을 드러내야 합니다. 그렇지 않으면 비교가 동일한 요청에 대한 서로 다른 해석에 보상을 줄 수 있습니다.
평가는 쉬운 레코드와 모호한 레코드도 구분해야 합니다. 전체 정확도는 실패가 중요한 필드에 집중되는지를 숨길 수 있습니다. 문서 제목을 대체로 정확히 읽는 시스템이라도 수정된 마감일이나 상충하는 금액에서는 어려움을 겪을 수 있습니다. 구매자에게는 실제 노출 위험을 반영하는 결과가 필요합니다.
낯선 문서에서 강력한 성능을 보인다는 근거는 더 폭넓은 도입의 근거를 강화할 것입니다. 성과가 제한된 레이아웃에 의존한다는 근거는 더 제한적인 역할을 뒷받침할 것입니다. 어느 결과든 개발자가 모델에 적절한 경계를 정하는 데 도움이 됩니다.
약속된 오픈 웨이트 공개가 다음 신호입니다. 오픈 웨이트는 라이선스 및 기술적 요구 사항에 따라 원래 호스팅 서비스 외부에서 배포할 수 있도록 하는 다운로드 가능한 모델 파라미터입니다. 공개되면 독립적인 검토와 실험을 위한 추가 기회가 생깁니다.
중요한 세부 사항에는 라이선스, 하드웨어 요구 사항, 배포 도구, 호스팅 버전과의 일치성이 포함됩니다. 단순한 이용 가능성만으로는 독립적으로 모델을 운영하는 것이 실용적이라는 점을 입증하지 못합니다. 이러한 주변 조건이 어떤 조직이 이를 의미 있게 활용할 수 있는지 결정합니다.
명확한 문서와 함께 공개된다면 이 범주의 접근성은 강화될 것입니다. 장기간 지연된다면 평가는 호스팅된 엔드포인트에 더 의존하게 됩니다. 어느 결과도 그 자체로 추출 품질을 결정하지는 않지만, 누가 이를 조사할 수 있는지에는 영향을 미칩니다.
마지막 신호는 프로덕션 사용입니다. 가장 강력한 사례는 어떤 워크플로가 바뀌었는지, 검토를 어떻게 처리했는지, 예외 상황에 어떤 일이 일어났는지를 설명할 것입니다. 또한 수신 문서가 변경될 때 필드 정의를 유지하는 데 필요한 노력도 포함할 것입니다.
처리 시간 단축 보고는 수용된 레코드와 검토자 노력에 관한 근거가 함께 제시될 때 더 설득력이 있습니다. 다른 곳에서 수정 작업이 늘어난다면 더 빠른 중간 응답은 중요성이 떨어집니다. 반대로 수동 개입이 일관되게 줄어든다면 전문화의 실질적 가치를 뒷받침합니다.
개발자에게 다음 단계는 예상 답변과 실패 결과가 명확한 제한된 워크플로를 식별하는 것입니다. 전문화된 추출을 애플리케이션에서 이미 사용할 수 있는 구조화된 생성 방식과 비교하세요. 평가에 대표적인 어려운 문서를 포함하고, 이견을 조사할 수 있도록 충분한 출처 맥락을 보존하세요. 구매자는 공급업체에 모델 주장과 수용된 레코드, 검토 노력, 예외 처리의 연관성을 제시해 달라고 요청해야 합니다. Cloudflare Clairic 추출 모델은 출력 인터페이스의 선택을 더 명확히 하지만, 그 선택에는 여전히 주변 시스템의 근거가 필요합니다. 애플리케이션이 값이 필요한 지점, 설명이 필요한 지점, 그리고 이 역할들이 함께 속하는지를 검토하세요. 최종 결과의 신뢰도를 떨어뜨리지 않으면서 더 좁은 범위의 모델이 도움이 될 단계는 어디일까요?
