이번학기 조교를 하고 있는 프로그래밍 원리 과목의 프로젝트가 시작되었다. 대대로 프로그래밍 원리 과목은 조교가 게임을 제공하고 학생이 AI를 작성하는 전통이 있다. 교수님은 게임이 아닌 대안을 원하지만, 학부 시절 가장 즐거웠던 과제였기에 (그리고 프원 조교로 게임을 만들수 있다는게 중요한 연구실 선택 동기였기에) 게임을 밀어붙였다. 연구고 공부고 재쳐두고 3일째 게임을 기획하고, 문서화하고 실행기를 짜는 중이다. 오늘 밤에 실행기가 끝나고 나면 몇일은 쉴 수 있겠지. 스펙 문서에는 학생을 괴롭히는 악랄한 TA의 음모에 맞서라고 했지만 악랄한 조교는 자기 꾀에 넘어가 제대로 병맛을 보고 있다.
ML로 게임을 짜면서 느낀 것을 몇가지 적어두려고 한다.
1. ML이나 C나 기본은 Divide and Conquer
현실은 수식으로 간단하게 기술되지 않는다. 수학으로 깔끔하게 기술되는 작은 문제와 문제들을 결합하는 부분으로 쪼개서 생각하는 것 밖에 도리가 없다. 때문에, 언어가 자연스럽게 기술할 수 있는 작은 조각들 (문교수님 표현을 쓰면 빌딩블럭) 뿐 아니라, 자연스럽게 기술되지 않는 문제를 작은 문제로 분할하는 그 언어만의 독특한 방법을 배워야, 현실문제를 해결하는 툴로서 활용할 수 있다. 그런데 ML이란 언어를 공부하면서 접하는 예제에 문제가 있다. 초심자들을 ML로 빨아들이는데 집중한 나머지 자신에게 유리한 예제들만 다루고 있다. ML 초심자가 중급자로 넘어가면서 하는 첫 고민은 함수형 언어로 어떻게 큰 프로그램을 짜야 하나 하는 것이다.
게임을 짜면서 ML로 자연스럽게 표현되지 않는 것을 어떻게 짤까 고민하면서 ML에서의 모듈 분할에 대한 통찰이 조금 생겼다. 그리고 그 양상이 C와 조금도 다를바가 없어서 충격을 받고 있다. C에서 Header와 File Scope를 이용해 프로그램에 추상화 계층을 구축하는 것과 정확히 동일한 방법이 ML에서 사용된다. Module과 Signature 라는 것이 있는데 Module이 File Scope이고 Signature가 Header의 역할을 한다.
2. 함수형 언어의 프로그래밍 idiom : State Transition Function
모듈을 자연스럽게 활용하려면 함수형 언어에서 잘 사용하는 몇가지 프로그래밍 Idiom을 익혀야 하는것 같다. 그중 하나가 State Transition Function이다. OOP에서는 객체가 실행 경로를 타고 흘러다니며 변해간다. ML에서는 값에 State Transition Function을 반복 적용하여 같은 짓을 한다. 함수형 언어에서 loop 을 재귀함수로 구현한다는 것은 프로그래밍 조금 한다는 사람은 다 아는 사실이지만, Mutual Recursion과 Exception을 이용해서 Stats Transition Function 이 자연스럽게 구현된다는 사실을 깨닫기가 쉽지 않다. State Transition Function의 인자로 흘러다니는 값은 Reference를 이용해서 변하게 만들어도 전혀 어색하지 않다.
3. 함수형 언어의 프로그래밍 idiom : 메세징을 이용한 병렬 프로그램
프로그램을 State Transition 형태로 기술했다면, 그 안에 메세지 패싱을 밖아넣어서 병렬화할 수 있다. 메세지를 기다리는 동안 블럭되있는 것은 스테이트가 제자리에 머무는 것이고, 메세지를 받아서 움직임이 변하는 것은 스테이트가 전이되는 것이다. 자연스럽다. ML만 쳐다보면서 이해하기는 어렵다. 나는 Erlang의 논문을 읽다가 깨닳았는다. 학부에서 Erlang을 다뤄주기를 기대하기는 어렵고 Prolog를 이용해서 Logic Programming하는 것을 심도있게 다루는 코스가 있다면 센스있는 학생들은 감을 잡고 졸업할수 있지 않을까 한다.
4. ML의 프로그래밍 idiom : 소규모 인터프리터
ML에서만 가능한 또 다른 idiom 이랄까? 쉽게 구현할 수 있고 효과적인 빌딩블럭이 인터프리터다. 원자수준의 단순 작업으로 분해 가능한 일군의 작업이 있다면, 작업을 기술하는 작은 언어와 실행기를 만든 다음에, 해당 언어로 작업을 기술하는 편이 모든 작업을 다 ML로 기술하는 것보다 효율적인 경우가 제법 있다. 학부 프로그래밍 언어 시간에 ML로 인터프리터를 짜 본 경험이 있다면 ML로 소규모 인터프리터를 짜기가 어렵지 않다는데는 수긍할 것이다. 관건은 작업을 기술하는 언어를 만드는 것이 쉬우냐는 것인데, 이 부분은 State Transition Function 처럼 트레이닝을 받는 수 밖에 없다. 사실 PL 지식 학부수준이면 충분한 것 같다. PL 지식보다는 언어를 만들어서 공략하고자 하는 작업에 대해 얼마나 아느냐가 관건이다.
5. 일단락
ML이든 OOP든 Logic Programming이든 큰 규모에서 문제를 공략하는 기법은 동일한듯 하다. 문제가 크다면, 중간 규모의 문제들로 쪼개지고 중간규모의 문제는 다시 작은 규모의 문제로 쪼개질 것이다. 중간 규모의 문제를 합해서 큰 규모의 문제로 조합하는 방식은 언어가 달라도 크게 차이가 없을 것이다. 그 수준에서는 언어보다는 라이브러리의 생김에 의해 프로그래밍 방법론이 결정될 테니까. 언어가 영향을 줄 수 있는 부분은 하위의 두 수준인듯 하다. 작은 규모의 문제를 얼마나 쉽게 만들고 변경할 수 있느냐. 그리고 작은 문제를 조립해서 중간규모의 문제를 해결하는데 어떤 방법론이 존재하느냐. 어린 해커들은 작은 문제를 기술하는데 집중하기 때문에 퀵소트를 짧게 구현할 수 있는 언어가 나올 때 마다 열광한다. 그러나, 객관적으로 볼때 성공하는 언어는 대체로 중간규모의 문제를 효과적으로 해결하는 방법을 제공하느냐에 달려있다. 한 카테고리의 중간규모의 문제만 해결할 수 있어도 살아남을 수 있고, 여러 카테고리를 해결할 수 있으면 번성한다. ML이 일반에 퍼지지 못하는 원인중의 하나는 ML로 중간규모의 문제를 해결하는 방법론이 축적되지 않았기 때문이라 생각한다. 언제까지 ML을 쓸지는 모르지만, 쓰면서 느끼는 것을 이렇게 차곡차곡 정리하는 것도 유익하겠다는 생각이 든다.
Posted by 발당
Trackback URL : http://jbdmk1.upnl.org/tt/trackback/408
