GPT 모델에 대해서는 질의에 대해서 상관사실에 대한 것은 대부분 답변으로 해결이 가능함. 

그렇지만 상관정보에 대해서는 GPT 모델은 기본적으로 의존하는 Schema 가 있고 그러한 상관됨의 정보를 인식하는 일에 대해서는 정보단위에 대해서 불가능함. 

그런데 AI 의 발달로 인해서, IT System 에 대해서는 그것이 Data dispatcher 로써의 Coding 은 MVC 모델에 의해서 필요로 하지않게 되었음. 

Model 에 대해서 상관성의 정보모델은 구축에 대해서 Stakeholder 의 Specific story 가 끼여있어야 하는데 View, Controller 등에 대해서는 

Back/Front 의 Coding 으로 나뉘어져 있고, 

Dispatcher 에 대한 Concepts 는 Back 에 대해서 Spring Framework 로 질의가 가능할 정도로 공식화가 되었음. 

Front Coding 에 대해서는 View Page Interaction 에 대해서 가능한 Story 를 구축한다면 세부적으로 그에 해당하는 Object 를 GPT 는 추론할 수 있고 이러한 Story 는 Layout position 을 제외한다면 View page 에 대해서 "Activation set" 과 "Displaying property set" 을 지정할 수 있음. 

그렇지만 Position 값에 대해서는 Figma 등의 Layout definition 도구가 있어서 포괄적으로 그저 가능하기에 GPT 의 Object recognition(객체인식기술) 에 의해서 Request 가 가능하고 있음.

그런데 Model 에 대한 Concerning space 에 대한 상관관계에 대한 Format 에 대해서는 Stakeholder 의 Specific story 에 대해서 List 를 받아서 When 을 기준으로 Concerning Factor 에 대한 Information 을 구축할 수 있음. ㅇㅇ; 

이에 대해서는 GPT 모델에 대해 질의를 통해서 구축할 수도 있지만 이해관계의 사고의 판단이 더 정확하고 Stakeholder 를 기준으로 하는 Specification 이 When 에 대해서 사리판단에 대해서 잣대가 맞게 됨. 

결과적으로 IT 기업은 대부분의 이런 의미에서 독자적 성격이 Stakeholder 에 대해서 이뤄지기 때문에 Concerning Factor 에 대한 Cloud API 유지보수 회사로 남을 것이게 될 가능성이 98% 쯤 됨.

그렇지만, 일의 성격이 난이도가 적을 것을 생각하고 API 의 표준성을 생각하면 정부 기조 하의 공공사업부가 될 가능성이 많음. 

abcd9999