왜 또 알고리즘을 하는가?

벌써 25년 전이네요.  그때 대학생일 때... 우연히 접하게 된 Robert Sedgewick 교수의 "Algorithms in C" 책에 빠져 한동안 헤어나오질 못했습니다.   지금도 헤어져 누더기가 된 이 책이 집에 있을텐데,  구석에 쳐박혀 있어 찾질 못하겠군요.

심지어 군대에 있을때도 이 책을 들고 들어가 짬짬이 보았던 걸로 기억납니다.  왜 그렇게 알고리즘에 천착했을까라고 생각해보니... 그것은 그냥 지적 호기심이었던 같습니다.

C나 C++과 같은 프로그래밍 언어의 테크닉은 책으로 경험으로 익힐 수 있지만, Heap Sort니, Red-Black Tree니, Backtracking이니 하는 용어들은 마치 블랙박스처럼 속을 들여다 볼수도 이해할 수도 없는 것들 이었습니다.   당시에 꽤나 프로그래밍을 한다고 알려진 저로서는 자존심에 큰 상처를 주는 것들이었습니다.

그래서 컴퓨터공학과도 아닌 제가 그 과의 필수 과목인 알고리즘과 자료구조 등의 과목을 수강했더랬습니다.  그런데 사실 교수님으로부터 배운 것 보다는 이 책을 통해 배운게 더 많은 것 같습니다.

지적호기심에 대한 추억으로 남아있는 이 알고리즘을 다시 꺼내어 볼려고 구글링을 좀 해보니...  이제 이게 어린 학생들의 입시를 위한 하나의 방편으로,  소프트웨어 분야 대기업 혹은 외국기업의 입사 시험을 위한 것으로 약간은 세속화(?) 되었더군요.  더 이상 지적호기심을 충족시키기 위한 순수한 열정을 기대하기는 어렵게 된 것 같습니다.

TopCoder니 ACM-ICPC니 하는 등의 알고리즘 풀이 능력을 계량화 하고자 하는 노력들도 보이던데... 어느 정도는 그럴 수 있을지 모르나, 이 역시 문제 은행의 한계로 점수만 높아지고 실력은 하향하는 이상한 귀결로 가지 않을까 하는 걱정이 되기도 합니다.   이건 마치 "퍼즐을 잘 푸는 사람일 수록 업무를 더 잘 할까?"라는 의문과 같습니다.

저는 IT분야에서 이제 한물 간 세대에 속하고,  젊은 친구들의 팽팽 돌아가는 두뇌를 따라갈 수는 없지만... 다시 또 알고리즘을 파고 들려고 합니다.  현업은 알고리즘 퀴즈와 달리 문제가 명쾌하지도 단순하지도 않습니다.  주어진 사양에서 우선 돌아가는 코드를 만들어 일정을 맞추고,  이후 그것을 최적화 해야 하며,  다른 사람이 수정할 수 있도록 읽기 쉬운 코드를 만드는 것이 더 중요합니다.

이런 관점에서 알고리즘 분야를 할아버지가 손자에게 옛날 이야기를 들려주듯 되도록 재미있게 풀어보고자 하는게 지금 생각입니다.  물론 이 생각이 흐지부지 될지도 모릅니다.  때때로 여유가 날 때마다 들여다보고 글로 정리해 보도록 하겠습니다.