전 글 에서 지식을 얻는 것이, 연구방법에서, 탐색할 대상을 탐색하는데 필요한 것임을 생각 해 볼 수 있었다.
여기서는 기술 지식 중, process architecturing 에 대해서 생각해보고자 한다.
흔히 programming problem solving 이라고 불리는 기술이다.
programming 이란 것이 process 를 만드는 것이고,
architecturing 은 해당 process 를 어떠한 목적에 맞게 설계하는것이니,
programming problem solving 은 행위이고, 그 일의 본질은 process architecturing 이라고 생각해볼 수도 있을 것이다.

architecturing 이란것은 건축에서도 쓰는말인데,
건축도 그렇고 패턴이라는 개념과 연관이 있어 보인다.
그도 그럴 것이, 세상의 문제들중 새로운것은 자주 나타나지 않는 경향이 있다
새로움이란 변화가 있어야 나타나는데, 세상은 그렇게 빠르게 바뀌지는 않으니,
그리고 바뀌었던것은 대응이 되어 왔으니, 현재 적립된 패턴들로 포착할 수 있는 문제들이 많을 것이라 생각해볼 수 있다.
패턴은 그러한 역할인것 같다, 변화가 많지 않은 환경에서, 과거의 지혜를 빌리는것이다.
이는 문제의 표현은 바뀌었지만, 문제의 본질은 바뀌지 않았을때, 가능하다.

architecturing 이 패턴이라면, process architecturing 의 패턴은 process 에 있다고 생각해볼 수 있을 것이다.
그러면 process 란 무엇일까?
process 란 컴퓨터에 한정적인 것이 아니다,
그냥 절차인것이다.
절차는, 절차와 절차가 적용될 대상이 있다고 생각할 수 있다.
예를들어 입법을 하기 위한 절차가 각 나라의 정부 마다 있을 것이다.
그리고 입법 대상인 법이 있을 것이다.

컴퓨터에게 있어서는 절차란 program 또는 algorithm 이라 불린다.
절차가 적용될 대상은 data 라고 불린다.
programming 이란 기본적으로 두 패턴의 상호작용으로 볼 수 있다.

절차가 컴퓨터 이전 부터 있던 행위이듯,
programming 역시 실제 세상의 행위의 자동화라고 대강 볼 수 있다.
이러한 관점에서 data 란 실제 세상의 자연개체(natural entity) 들의 representation 으로 볼 수 있다.
그리고 algorithm 이란 실제 세상의 사람의 행위(human behavior) 의 representation 으로 볼 수 있다.

즉 프로그래밍이란, 실제 세상의 자연개체에 대해, 실제 세상의 사람의 행위를, 적용시키는 일로 생각해볼 수 있다.
그러러면 a) 실제 세상의 자연개체에 대한 이해를 명확히 가져가고,
b) 그것에 필요한 사람의 행위를 명확히 이해하는것이 필요하다.

주로 프로그래밍에서는 어떠한 현상이 있다,
그 현상은 실제 세상의 자연개체가 등장 한다,
그러면 우선 그 자연개체가 어떠한 구조화된 데이터로 표현되어야 할지를 생각해볼 수 있다.
자연개체가 한개 등장할 수 도 있고,
자연개체A, 자연개체B, 처럼 여러개가 등장 할수도 있다.

여기서 실제 사람의 행위란, 자연개체를 기반으로 한다,
사람의 행위는 자연개체안에서의, 또는 자연개체와 자연개체간 상호작용으로 생각해볼 수 있다.
행위 그 자체는 말 그대로 그냥 틀로써,
자연개체에서 시작하여 자연개체에서 끝나기 때문에,
사람의 행위는 자연개체가 자기자신 또는 다른 자연개체와 상호작용하는것을 도울 뿐으로 생각해볼 수 있다.

이러한 정의를 빌린다면, process 란, 자연개체가 자기자신 또는 다른자연개체와 상호작용하는것을 돕는 일로써, 자연개체의 변환 작용을 돕는다.
즉 절차란 변환을 시키는것으로 생각해볼 수 있다,

그러면 어떠한 변환을 시켜야 할까?
이건 b) 그것에 필요한 사람의 행위를 명확히 이해하는것 것과 관련이 있을 수 있다.
이때 software engineering 에서, 요구사항 분석이라는 단계를 생각해볼 수 있다.
이건 건축등 다른 분야에서도 비슷하게 있을것 같다.
요구사항 분석은 주어진 현상과 이끌어가야 하는, 목표를 기반으로 생각해 볼 수 있다.
보통 요구사항을 주는 쪽은 치밀하게 고민하지 않는다, 자신이 필요한것만을 이야기 한다.
그래서 요구사항이다, 그래서 추상적일 수 밖에 없다.

b) 그것에 필요한 사람의 행위를 명확히 이해하는것 를 수행하기 위해서는, 추상적인것에서 구체적으로 가는 방향성이 필요할 수 있으며, 각 granularity level (추상성~구체성의 수준) 에서, 해당 level 에서의 단위 행동 (atomic operation) 을 반복적으로 만들어나가는것이 된다. (이러한 관점에서 보면, 각 알고리즘이란, 각 수준의 케이스에 대한, 추상적이고 반복적인 atomic operation 의 집합으로 볼 수 있다.)
즉 각 granularity 수준에 맞는 반복적이고 atomic 한 operation 을 만드는것, 계속 그렇게 뜱어나가는것이 process architecturing 을 연구적으로 수행하는것의 기초가 될 수 있다.

지금까지 이야기 해본것에서 몇까지 꼭지를 정리/확장 하자면 다음이 포함될 수 있다:

• programming 은 process architecturing 이다.
  • 따라서 programming 적 결과물은 꼭 컴퓨터 뿐 아니라 일반적 일 처리에도 사용될 수 있다.
  • 반대로 일반적 일 처리에서의 처리 방식도 programming 에 적용할 수 있다.
• process architecturing 은, 기본적으로, 일을 처리 하기 위해, 단일 또는 여러개의 자연개체 (natural entity) 의 개체내 또는 개체간 상호작용을 하는 인간적인 방법을 정의하는것이다.
• 주어진 추상적인 상황 또는 요구상황으로 부터 이러한 일을 처리하는 방법 (algorithm) 을 정의하기 위해서는, 그 사이의 granularity level 의 gap 을 매워야 한다.
  • 이를 매우는데 있어서 단계적 접근을 취할 수 있다.
  • 주어진 추상적인 상황에서 한단계 더 낮은 (fine-grained) 수준으로 인간 활동을 정의 한다 (what 으로 되어 있는 부분을 how 로 바꿀 수 있다. 두 리스트간 곂치는 데이터 확인 하기 -> 각 배열을 set 으로 만들어 intersect 하기 처럼. 즉 declarative programming 으로 되어 있는 부분을 보다 imperative programming 형태로 바꾸는것으로도 볼 수 있겠다)
    -> 즉 프로그래밍은 문제 설명을 변환 하는 것으로 부터, 즉 자연어로 부터 시작 하는것이 맞아 보인다.
    -> 이를 반복 하다 보면, 사용하는 프로그래밍 언어가, 지원하는 graularity 와 (보통 문제의 수준보다 많이 낮은 수준이다) 같은 수준으로 정의한 인간 활동의 수준이 내려온다. -> 그러면 그것이 solution 이 된다.
• 이렇게도 말해볼 수 있지 않을까? 프로그래밍은 컴퓨터에 국한된것이 아니며 보다 일반적인 개념일 수 있다. 프로그래밍은 자연개체간 상호작용을 돕기 위한 인간적 활동을 정의하는 것으로, 확인한 현상 및 문제 상황에 대한 선언적 텍스트 설명을 한단계씩 낮은 단계의 보다 명령적(imperative) 텍스트 설명으로 변환하는 작업, 즉 컴퓨터 실행환경과 granularity level 이 맞도록 구체화 시키는 작업을 뜻한다.
  • 이 구체화된 작업을 얻어내는것이 programming 이라는 process architecturing 의 목적으로 볼 수 있다.
  • 즉 process architecuring 은 새로운 프로세스를 만드는것이 아니라, 자연개체간 상호작용을 돕기 위한 인간적 활동을 구체화 시키는것으로, 확인한 현상 및 문제 상황에 대한 선언적 텍스트 설명을 한단계씩 낮은 단계의 보다, operatinal (atomicity 와 repeatitiveness 를 가진) 명령적(imperative) 텍스트 설명으로 변환하여, 컴퓨터 실행환경과 인간적 활동의 granularity level 이 맞도록하는것을 뜻한다고 생각해 볼 수 있다. 이때 자연개체의 형질도 그 종류가 무한하지 않음으로 데이터구조라는 패턴을 보게 되고, 인간적 활동도 그 종류가 무한하지 않음으로 알고리즘이라는 패턴을 보게 된다. 따라서 현실적으로는 패턴들이라는 일종의 선행 연구를 참고하여 문제도 풀게 된다.
    • 컴퓨터 실행 환경이 아니라, 공장 생산 과정 환경일 경우 일종의 공장의 생산 과정에 대한 프로그래밍이 된다.
    • 직조기가 실행 환경일 경우, 그것은 카페트 등의 생산과정에 대한 프로그래밍이 된다. 그리고 실제로 이것은 프로그래밍의 시작으로 여겨지고 있다.

todo 로써,,

• 실제 상기와 같은 관점에서 각종 컴퓨터 프로그래밍 더 나아가 각종 과정에 대한 프로그래밍에 대해 고민해볼 수 있겠다.
• 또한 머신러닝의 경우 상기에서 언급한 ‘자연개체간 상호작용을 돕기 위한 인간적 활동’ 구체화 시키는 작업을 일반적으로 gradient descent 등의 최적화 방법으로 자동으로 푸는것을 목적으로 한다. 이러한 방법은 특히 자연개체가 연속적 표현을 가져서, 사람의 지혜가 로직의 형태로 (심볼의 형태로) 나타내기 어려울때 더 효과적이다.
  • 따라서 프로그래밍은 해결하려는 task 에 따라서 크게 일반 프로그래밍과 머신러닝으로 나뉠 수 있다.
  • 이 문서에서는 일반 프로그래밍 위주로 논의 했는데, 머신러닝에서 ‘자연개체간 상호작용을 돕기 위한 인간적 활동’ 을 어떻게 잘 만들 수 있을지에 대해 각종 학습 메커니즘들을 살펴보며 생각해보는것도 재미있는 일이 될 것으로 생각한다.