컴퓨터 프로그래밍에 대해서는 어느정도 디자인이 가능해서 많은 곳에서 대규모 처리 혹은 대규모 관리에 대해서 Enterprise (엔터프라이즈) 급의 시스템이 가능하다는 것은 

대부분 잘 알 것임. 

이에 대해서는 전공자에 해당한다면 기본적으로 컴퓨터라는 것이 Inputing 에 대해서 Memory 의 CRUD 에 대한 Return by 가 When?/What? 에 의해서

시행되는 것이 기본적으로 프로그램이라는 것을 알기는 할 것임. (메모리 수준의 프로그램을 포함해서..) 

그렇다면 시스템 단위의 대규모 프로그램에 대해서는 그것이 When?/What? 에 대해서 그것 자체도 CRUD 가 이뤄지는 것에 대한 스케일이 Enterprise 급의 시스템이

된다는 것을 쉽게 알 수가 있을 것이라고 봄. 

ㅇㅅㅇ.. 

그래서 Dispatcher 단위로 Data 수준에서 Reference (참조) 에 대해서 CRUD 가 이뤄지는 스케일의 시스템 프로그램이 스케일에 대해서 Enterprise 급이 되는데, 

Enterprise 스케일의 프로그램 묶음에 대해서는 그것이 Yes or No 에 대해서, When?/What? 의 질의문(Query) 에 대한

시스템 단위의 유지보수가 대부분의 프로그래머의 일이 된다는 것을 알 수 있음. 

(일해보면 알 것임..)

그래서 프로그래머의 일이 나타날 수가 있는 영역에 대해서는 Enterprise 스케일에서는 거의 CRUD 의 Media 에 대한 Image 가 되는데, 

Yes or No 의 값이 중요한 것이 되니까, 

Yes or No 의 When?/What? 에 대해서 Text 등을 포함한 Token or Range 에 대해서 알림의 Transaction 이 있는 일에 대해서 공개용과 내부용으로 나뉘는 것에 의해서 

Dispatcher 가 있게 됨. (사업분과를 말함..)

그래서 Enterprise 의 프로그래머에 대해서는 이러한 Dispatcher 에 관해 Memory 의 CRUD 에 대해서 When?/What? 이 CRUD 로 이뤄지는 것에 대한 

Symbol 을 다루면서 유지보수 및 대응을 하게 됨.

ㅇㅅㅇ.. 

그리고 프로그래밍 기술스택을 관리를 하는 것도 프로그래머의 관리직 쯤의 일인데 이것에 대해서도 When?/What? 이 CRUD 로 있는 것에 대해서 Symbol 의

참조(Reference) 에 대한 CRUD 를 정보체계로 관리를 할 수도 있음..

(When?/What? 의 CRUD 에 대한 Reference 가 이것저것에 대해서 변경사항으로 달라질 수 있음..) 

IT 업계에서 사고가 터지는 것에 대해서는 대부분 이러한 CRUD 에서의 When?/What? 에 대해서 Reference 의 변동이 문제인 것이기도 하는 것임. 

(해커가 이를 악용하기도 할 것임..) 

그래서 프로그래머에 대해서는 Yes or No 의 When?/What? 에 대한 것이 가장 중요하다고 볼 수가 있고 Enterprise 스케일에서는 알림의 Transaction 에 대한

CRUD 에 대해서, When?/What? 의 Yes or No 를 주관하는 업체가 된다고 볼 수 있다고 봄. 

Enterprise 수준에서의 프로그램의 느낌에는 이러한 고유의 System image 의 관리가 있게 된다고 봄.. ㅇㅅㅇ.. 

프로그래밍이라는 것은 실무 수준에서는 CRUD 에 대한 Yes or No 에 관한 When?/What? 의 Token or Range 에 대한 관리직이라고 봄. 

프로그래머는 이런 느낌이라고 봄. ㅇㅅㅇ..