결국 선무당이 사람 잡았습니다. T_T

얼마전에 종강한 강의 막판에 간단한 프로그래밍 숙제가 있었습니다. 정해진 형식으로 표현된 임의의 DFA를 입력받아서 최소화시키는 프로그램을 작성하는 문제였는데, 채점하면서 여러가지 이야기거리가 생기더군요. 이 중에서 다른 이야기는 다른 글타래에 따로 쓰기로 하고, 이 자리에서는 제가 일으킨 아주 민망했던 상황에 대한 이야기를 해볼까 합니다.

저희 연구실 연구원들의 수와 구성 상 어쩔 수 없이 제가 수강생이자 수업 조교가 되었습니다. (비리는 절대 없습니다!) 학기말에 가까워졌을 때 갑자기 교수님께서 프로그래밍 숙제를 제안하셨을 때에도, 교수님의 ‘한 마디 제안’을 구체화시켜서 과제물로 공식 등록하는 작업은 당연히 제 몫이었죠.

제 딴에는 수강생들의 부담을 줄이고 각자의 연구 시간을 조금이라도 더 확보할 수 있도록 보호한답시고, 이 구체화 작업에 나름대로 신경을 많이 썼습니다. 즉, 숙제의 요구 명세를 만드는 데에 있어서

• 오해나 중의적인 해석, 자체 모순이 있을 수 없도록 정형적으로,
• 숙제를 가능한 한 간단히 해결할 수 있도록 쓸데없는 부담 상황을 없애면서,
• 숙제의 원래 취지와 의의만큼은 고스란히 경험하고 익힐 수 있도록

저는 당연히 C언어를 공부했고 C언어 자체의 설계나 언어론적 특성들을 이론적으로 파악하고 이해하는 데에는 아무 문제가 없습니다만, 실전에서 공학적 마인드로 (한정된 시간 내에 한정된 비용으로) C라는 도구를 무기로서 사용해본 경험은 거의 없습니다. 학부 때에도 ‘반드시 C를 써야만할 타당한 이유가 없다면’ Python이나 Scheme 등의 고수준 언어로 숙제를 구현하곤 했었죠. 즉, 머리로는 C 등 저수준 언어의 이론을 충분히 이해하고 있다고 생각하지만, 결국 그것이 몸에 익어있지는 않다는 뜻입니다.

이번 숙제도 구현 언어의 제한은 없었습니다. 따라서, 이런 제가 숙제의 프로그램 요구 명세를 만들다보니, 명세를 작성하는 동안 무의식적으로 제가 선택할 후보 언어인 Python이나 Haskell등 고수준 언어로 구현하는 상황을 가정해버리게되었고, 결과적으로 본의 아니게 이런 고수준 언어들로 구현하기에 무척 유리한 명세가 되어버리고 말았습니다. 물론, 절대로 고의는 아니었습니다. 유리하다고 해봤자, 채점 기준과는 거의 상관 없는 ‘명료함’이나 코드의 ‘단순화’, 작업 시간에 유리한 정도였을 뿐이었거든요. 의도적인 비리나 골탕먹이기는 아니었다는 이야기입니다.

하지만 그 유리함의 ‘정도’ 차이는 의외로 무척 커서, 제가 요구한 명세 대로 입력 문자열을 분석하고 자료의 의미를 추출하고 검증하는 등의 작업을 C만으로 구현한 사람들은 생각보다 훨씬 고생하고 골탕을 먹었더군요. 게다가 문제는, 결국 대부분의 수강생들이 당연스럽게 C (혹은 STL 없는 C++)로 구현했다는 점이고, 그나마 명세에 완벽하게 부합하는 프로그램을 완성한 사람도 그다지 많지 않았습니다.

예를 들어, DFA를 문자열로 표현해서 읽어들이고 출력하기로 했을 때, 이 문자열이 취할 수 있는 올바른 구문 형태를 정규표현식으로 확정해두면 명세 자체도 정형화되고 구현하기도 쉬워진다고 생각했습니다. 즉, 이 순간 머리속에 당연스럽게 Python의 re 모듈을 떠올려버린 것이죠. 입력 자료의 파싱과 구문 검증은 단방에 끝낼 수 있겠더군요. 수강생들이 기뻐하리라 생각했습니다. -_-;;;

의미 (semantics) 검증 요구도 사고를 쳤더군요. 구문상 올바른 DFA 표현식이라고 해도, 의미상 그것이 항상 올바른 DFA를 나타낸다고 할 수는 없습니다. (예를 들어 set of final states가 set of states의 부분집합이 아니라거나.) 이걸 검증하라는 요구를 할 때에도 제 머리속에는 Python의 sets 모듈이 떠올라버렸습니다. 5-tuple이 유한오토마타이기 위한 조건들과 유한오토마타가 deterministic하기 위한 조건들을 합해봤자 너댓 가지 뿐이니, 의미 검증도 코드 너댓 줄이면 끝나겠더군요. 수강생들이 싫어하지 않으리라 믿었습니다. (지금 와서 돌이켜보면 수강생들이 가장 좋아했을 요구 명세는 “프로그램의 입력은 항상 올바른 DFA라고 가정합니다. 오류 처리는 필요 없습니다.”였겠죠.)

이 외에도 수강생들이 경악할만한 요구들을 많이 했었더군요. 과제물 이야기가 학기말에 너무 갑작스럽게 나와서 급히 명세를 만드느라 (나름대로 신경 썼다고 썼는데도) 몰랐었는데, 명세를 공지하고나서 룰루랄라 숙제를 하다보니 다른 수강생들이 거품을 물고 있었습니다. 그럴 의도가 아니었는데.... :cry:

결과적으로, Python으로 구현한 제 프로그램의 경우 총 200라인이 조금 넘었을 뿐인데 (그야말로 toy죠), 다른 수강생들의 C 코드를 채점하면서 보니 정말 미안해서 몸 둘 바를 모르겠더군요. 적지 않은 C 코드에 Lex까지 등장했습니다. (아니면 Lex를 쓰는게 더 쉽나요?) 아무튼, 정말로 고의가 아니었습니다. 그저, 제가 워낙 C에 익숙치못해서, 어떤 명세를 C로 실제로 구현할 경우 무슨 사태가 벌어질지 감이 부족했던 것 뿐입니다. T_T

요즘은 학교 복도에서 다른 연구실 수강생들과 마주치면 조용히 눈 깔고 지나갑니다. (_ _; )

PS: “어차피 언어 제한도 없고 불이익도 없는데 기왕이면 다루기 편한 고수준 언어로 짜지 그랬냐”라고 말하는건... 역시 궤변이겠죠? (돌이나 안 맞으면 다행이겠군요.)