프로그래머와 수학 2

   프로그래머에게 수학은 필요한가? 하는 질문은 꽤 자주 회자되는 것 중 하나인데, 그에 대한 생각을 프로그래머와 수학에서 말한 바 있다. 지금도 여전히 이에 관한 검색어 유입이 있기에 좀 더 보충하고자 한다.

   나는 GUI 관련된 작업은 거의 HTML 정도의 작업이라 생각한다. 아예 UI 디자인이라면 모를까, 있는 컨트롤들 가져다 쓰는 것은 MSDN만 읽고 이해할 수 있으면 할 수 있는 일이다. CListCtrl의 Report 형식에서 특정 row 만 배경색을 푸른 색으로 하는 등의 일같은 것 말이다. HTML 을 작성하는 것에 있어 수학이 필요하지 않듯이, 따라서, 단순히 컨트롤 가져다 쓰는 등의 작업에 수학이 쓰일리는 만무하다. 수학이, 혹은 수학적 사고방식이 쓰이는 예는 결국 데이터 처리 혹은 방대한 framework 설계 등에서 찾아볼 수 있다.

   개발자, 혹은 프로그래머가 하는 일이 단순히 코딩만은 아니기 때문에 모든 개발자에게 수학적 사고 방식이 필요하다고 하기는 힘들다. Specification 을 작성하거나, multi-threading 환경에서의 전체 구조 설계 등등에 수학이 필요할 수도 있겠지만 내가 그 쪽 경험이 부족하므로 이 글은 우선 '개발', 즉 직접 코딩을 하는 것에 국한시킨다. 특히 데이터 처리하는 것.

   각설하고, 한 예를 들어 보자. 무작위로 번호를 선택하고 싶은데, 그 번호 중 10 이하가 10 이상보다 두 배 정도 많이 나왔으면 좋겠다, 하는 경우가 있을 수 있다. 이렇게 조악하게 표현된 것을 좀 더 잘 표현해 보자면, 특정 분포를 갖도록 무작위 추출을 하고 싶은 것이다. 이 아주 단순한 전환에도 수학적 표현이 들어가 버렸다. 즉, 머릿 속에서 어렴풋하게 떠오르는 생각을 명확하게 표현할 수 있는 방법은 다른 그 무엇보다 수학적으로 표현하는 것이다.

   여기서 약간의 오해가 장애물 역할을 한다. 많은 경우 수학 그 자체가 아니라 '수학적 사고방식'이 필요하다고 생각하기 때문에 수식이 많이 들어간 것은 수학적 사고방식의 필요성을 보여주는데 적합하지 않다고 생각하는 것이다. 간단히 말해, 이것은 수학을 모르기 때문에 하는 말이다. 수학은 기호의 학문이다. 기호는 수학적 표현을 표현하는 아주 극단화되고 표준화된 방법이다. 짧은 문장이라도 그것을 읽는 사람마다 다른 생각을 할 수 있지만 수학적으로 표현된 것은 제대로 이해한 사람의 경우 이해한 것이 정확히 같다. 이것이 핵심이다. 수학적으로 표기된 생각에 대해 모두가 딱 한 가지 해석만을 한다는 것은 그만큼 명확하고 혼동이 개입할 여지가 없이 분명하다는 것이다. 그래서 불분명하거나 애매한 부분이 있는 생각을 수학적으로 표기하면 사람마다 다르게 해석될 우려가 있으며, 이와 같은 것은 수학적으로 올바르다 할 수 없다. 즉, 수학은 기호를 매개로 하여 생각을 정확하고 분명하게 표현할 수 있게 해준다. 기호가 없는 수학은 상상할 수 없다. 많은 수학적 개념이 그러하다. 가령 역함수처럼 표기되곤 하지만 개념은 다른 inverse image의 개념. 따라서 수학적 사고방식의 필요성에 대한 언급에 있어서 수학적으로 표기된 예를 말하지 않는다거나 수학적 개념 없이 그런 예를 말한다는 것은 모순이다.

   예를 들어 보자. 위에서 말한, 특정 분포를 갖도록 무작위 추출을 하려면 어떻게 할까? 통계학 책에 두 줄 정도로 나와 있다. 원하는 확률밀도함수(pdf)의 역함수를 균일분포(uniform distribution)에 넣으면 된다고. 그런데, 이렇게, 원하는 pdf의 역함수를 uniform distrubition에 넣으면 된다, 해버리면 벌써 너무 수학이 많이 들어가서 수학적 사고방식이 아니라 그냥 '수학'의 사용예일까? 아니다. 원래 우리가 접하는 수학이란 결국 어렴풋하고 애매하던 개념들이 서서히 정립/개선되어 명확해진 결과물이다. 마찬가지로, 수학적 사고방식을 가지고 문제를 해결하고자 한다면, 애매하던 것들을 명확하게 개선해야 하고, 그 결과로 얻는 것은 수학적 용어들로 표현된 것이다. 즉, 수학적 사고방식을 이용해 문제를 해결했을 때는 결국 수학의 기호와 개념이 거의 반드시 들어 가게 된다.

   Fisher's discriminant analysis의 원리에 대한 글을 보자. 이 글은 처음에는 너무나도 단순한 문제에서 시작한다. 두 그룹을 잘 분리하고 싶은 것. 그런 '직선'을 찾고 싶은 것. 그래서, 분리를 잘한다, 는 것이 무엇인지 정의하고, 그 값을 크게 하는 co-efficient를 찾는다. 이 글은 처음에는 쉬운, 그냥 우리가 일상적으로 사용하는 단어에서 시작하지만 결국 수식과 수학적 개념을 통해 최종적인 선을 지정하는 co-efficient 를 찾게 된다. 여기서, 암묵적으로 사용된 수학적 개념은 '직선'이란 개념인데, 2차원 평면 상에서 1차원적 속성을 갖는 선만을 사용하는 것이 아니라, N-차원 안에서의 '선'을 사용한다는 것이다. 이것 자체가 이미 '차원' 이라는 수학적 개념을 사용하게 된다. (확장되면 SVM 이란 두 그룹을 잘 분리하는 '선'이 아니라 hyper-plane을 찾는 문제, 가 되는 것이다).

   수학적 용어들을 사용하진 않았지만 일반화가 바로 진행된 예는 주어진 집합의 모든 부분집합을 구하는 이 글에서 볼 수 있다. 이렇게 일반화시키는 작업은 수학에선 너무나도 잦은 일이라 별로 설명하진 않았는데, 이런 류의 방식이 수식 없이 수학적 사고 방식을 사용한 예라면 예일 것이다.

   시덥잖은 글이 되어버리긴 했지만 모든 값이 같은 부호를 갖고 있는지를 판단하기란 글이 수학적 개념이 사용된 또다른 예가 될 수 있고, 가장 좋은 예는 STL의 generic algorithm 중 sort 함수에 사용되는 strict weak ordering 이다. 내가 직접 경험한 버그 중 strict weak ordering 을 제대로 이해해야 해결할 수 있었던/혹은 수월한 경우는 다음과 같다.

• discards qualifiers 에러 : STL의 map의 [] 연산자의 반환값
• vector를 sort 한 이후 문제가 생길 때
• no match for ‘operator<’ in ‘__x < __y’

또한 edge 객체를 구현해서 STL의 set 이나 map 에 집어 넣기 위해서도 strict weak ordering 을 알아야 하겠지(그 글). 사실 STL 자체가 abstract algebra의 programming version 이라 해도 될만큼 STL에는 수학적 개념들이 잘 녹아들어가 있다^[각주:1].

   생각을 명확하게 해준다는 것과 더불어, 수학적으로 표현하게 되면 왜 맞는지에 대한 보다 확실한 이유를 알 수 있게 된다. 즉, 수학적으로 증명된 것은 '그냥 맞을 것 같은 코드'와는 비교할 수 없을만큼 정확하다. 코딩을 하다 보면 물론 수학적으로 증명된 것을 어떻게 구현하느냐에 따라 제대로 구현이 안 될 수도 있기는 한데, 그렇기는 하지만 '그냥 왠지 맞을 것 같은' 코드보다 더 정확한 것은 변하지 않는다.

   정리해 보자면, 수학적 사고 방식은 결국 수학적 표기법과 개념들로 표현되고, 그것은 사고를 명확하고 분명하게 해주는 역할을 하며, 또한 틀리지 않는다는 증명 역시 가능하게 해준다. 즉, 수식이 들어간 것과 수학적 사고 방식을 따로 떼어서 생각하지 말아야 한다. 어차피 수학적 사고 방식은 수식과 수학적 개념으로 표현되어야 하니까 말이다. 그리고 이것이 우리에게 주는 것은 효율성과 '확실함'이다. TDD가 물론 있기는 하지만 수학적 확실함이 주는 확실함은 버그와 싸워야 하는 개발자에게는 커다란 이득이다. 또한, STL과 같이 잘 추상화된 예에서 알 수 있듯이 전체 설계 역시 수학적 개념들을 적절히 사용하면 깔끔한 설계가 가능하다.

   마지막으로, 페르마의 마지막 정리가 증명되었을 때나 푸앵카레 가설이 증명되었을 때도 우리는 별다른 감흥 없이 살아 왔던 것처럼, 누군가는 수학을 잘 알아 그것을 프로그래밍에 잘 사용하며 살아간다고 해도 우리는 그냥 그런 것 없이 코딩하며 그냥저냥 살아갈 수는 있다. 물론, 그렇게 하다 보면 '수식은 일단 넘어 뛰고', 가 되겠지. 반대로, 수학에 거부감이 없을 경우, '일단 수식부터'가 되지만, 왜냐 하면, 백마디 말보다 수식을 보면 무엇을 말하고 싶은지 분명하고 명확하게 알 수 있으니까. 선택은 자유다, 선택의 결과는 자유가 아니지만.

1. 실제로 어떤 STL 책의 저자는 독자에게 기회가 되면 abstract algebra를 배워보라고 하기도 한다. [본문으로]