직관과 프로그래밍

직관과 프로그래밍

컴퓨터 소프트웨어라는 것은 수학적으로 잘 짜인 논리 집합체이다. 그래서 프로그래밍이라는 작업은 그 어떤 작업보다 논리적인 작업이다. 그래서 사람들은 그 프로그램을 작성하는 프로그래머들이 프로그램을 작성할 때는 언제나 논리적으로 생각할 것이라고 간주해 버린다. 하지만 정말 논리적인 생각만으로 프로그램을 작성할 수 있을까.

크게 봤을 때 프로그래밍은 당연히 논리적인 작업이 맞다. 알고리즘을 설계한다. 그리고 설계한 알고리즘을 프로그래밍 언어로 바꾸어서 실제 키보드를 두르려 코드를 써낸다. 그 코드를 컴파일 해서 실행파일을 만들어 내는 과정은 논리적 사고와 절차 외에 다른 요소가 끼어들 틈이 없어 보인다.

하지만 위에서 우리가 생각하지 않은 것이 있다. 일반적으로 우리가 생각하고 작성하는 알고리즘과 코드는 처음 알고리즘의 설계할 때의 목표를 달성하지 못한다는 것이다. 아무리 세심하게 주의를 기울여 설계한 알고리즘 혹은 작성한 코드라도 열에 다섯 여섯은 오작동하거나 예상과 다르게 동작한다. 그래서 개발자들은 디버깅을 해야 한다.

디버깅은 크게 두 가지로 나눌 수 있다. 명확히 오류가 보이는 경우를 디버깅하는 것. 그리고 도대체 원인이 뭔지 모르는 경우를 디버깅하는 것이다. 명확히 보이는 오류를 디버깅하는 경우는 잘 알려진 절차를 따르고 도구를 사용해 디버깅한다. 처음부터 끝까지 논리적인 사고로 문제가 되는 코드를 분석하고 수정해서 버그를 없앤다. 역시 논리적 사고 외에 다른 요소가 끼어들 틈이 없다. 문제는 두 번째 경우이다. 아무리 분석적으로 뜯어보고 논리적으로 생각해보고 여러 가지 툴을 사용해도 답이 보이지 않는다. 개발자들은 여기서 직관이라는 것을 끄집어낸다.

직관. 논리의 집합체인 프로그램을 직관을 이용해 만든다고 하면 언뜻 어울리지 않는다는 생각이 든다. "앞의 내용이 이렇고 뒤의 내용이 이러하니 여기는 이렇게 고쳐야해!" 하는 식의 사고가 아니라, "음.. 그냥 여기에 이걸 넣어 볼까?" 혹은 "혹시 이거 아니야?" 하는 식의 사고방식. 즉, 막말로 때려 맞추기 혹은 찍기의 사고방식인 것이다.

그렇다면 실제 프로그래밍 과정에서 직관이 차지하는 비율은 얼마나 될까? 내가 정확히 설문조사를 해본적은 없지만 주변의 개발자들과 많은 대화를 하면서 추정해 보건데 거의 절반에 가까운 비율이 아닐까 싶다. 이것은 나의 경험에 비추어도 거의 같은 비율이 나온다. 특히 프로그램을 최초 작성할 때 보다, 앞서 말한 디버깅 과정에서 직관이 차지하는 비율은 더 높아진다.

얼마 전에 동료 개발자 한명이 나에게 도움을 요청했던 적이 있다. 정확한 코드의 내용은 기억이 나지 않는데 대충 아래와 같은 모양이었다.

if(VERIFY(somefunc(a,b,c))){
	// 어떤작업
}

이 코드가 debug 모드에서는 if 문 블록 안에 들어가 어떤 작업을 수행한다. 하지만, release 모드에서는 if 문을 그냥 통과해 버린다. 즉, 블록에 들어가지 않는다는 것이었다. 프로그램 코드나 로직이 잘못된 것도 아니고 컴파일 모드에 따라서 동작이 다르다는 것에 그 개발자는 원인을 알 수 없어 계속 짜증만 내고 있는 상태였다. 물론 도움을 요청받은 나도 원인을 알 수 없었다. 그때 불현듯 떠오르는 생각 하나가 있었다.

일반적으로 gcc의 경우 컴파일러 최적화 옵션을 높게 주면 소스코드 안에서 많은 부분을 자체적으로 수정한다. 그러다 보면 개발자가 의도하지 않은 오동작을 일으키는 경우가 가끔 생긴다. 이번 경우는 gcc가 아니라 vc를 이용한 개발이었다 하지만 기본 원리는 같을 것이란 생각이 들었다. 그래서 빌드 옵션에서 "컴파일러 최적화 안함"을 선택하고 다시 빌드해 보라고 했다. 그렇게 빌드하고 테스트하니 의도한대로 동작하였다.

위 이야기에서 내가 갑자기 떠올린 컴파일러 최적화 옵션을 통한 디버깅은 직관적 사고일까 논리적 사고일까. 사람들마다 해석의 차이가 있을 수 있겠지만 나는 직관이라고 생각한다. 'gcc에서 컴파일로 최적화 옵션에 따라 동작이 바뀌는 현상이 있으니 이번 것도 그럴 것이다.' 라는 사고 과정은 논리적이지 않느냐 라고 반문하는 하는 사람도 있을 것이다. 그렇다 그 과정은 논리적인 사고 과정이다. 하지만 그 생각을 떠올린 것 자체는 그야말로 직관에 의존한 것이다. 왜냐하면 컴파일러 최적화 옵션이라는 것을 떠 올리기까지 과정에서 그 생각이 도출되는 연역적 근거가 없기 때문이다.

다른 예를 하나 더 들어 보겠다. 역시 내가 예전에 어떤 프로그램을 만들면서 겪었던 일이다. 중복실행을 막아 놓은 데몬을 만들었던 적이 있다. 그리고 그 데몬에 맞물려 돌아가는 클라이언트 프로그램도 작성하였다. 문제는 데몬이 떠 있으면 클라이언트 프로그램이 실행이 되지 않는 것이다. '도대체 어디가 잘못된 것인가' 하고 디버거 등으로 소스코드를 한 줄씩 실행해보고 커널 시스템 콜 호출을 캡춰해서 추적해보는 등 별짓을 다 해봐도 답이 나오지 않았다.

그때 혹시나 싶어서 클라이언트 프로그램을 먼저 동작시키고 데몬을 띄워 보았다. 정상적인 프로그램 동작 상황이라면 데몬이 클라이언트보다 먼저 떠 있어야 했다. 그래서 당연히 데몬을 띄워 놓은 상태에서 데몬과 클라이언트를 테스트 했었다. 그런데 반대로 하면 어떻게 되나 싶어서 데몬을 나중에 띄워 본 것이다. 결과는 역시 데몬이 뜨지 않았다.

순간 머릿속을 지나가는 것이 있었다. 그것은 데몬과 클라이언트에 중복실행을 방지하기 위해 넣어놓은 뮤택스 관련 코드의 내용이었다. 데몬을 작성하면서 먼저 만들어 놓은 중복실행 방지 코드를 그대로 클라이언트에 넣은 것이 화근이었다. 데몬에서 잘 동작하였으므로 그 동작이 검증되었다고 생각하고 아무 생각 없이 클라이언트 코드에 긁어 넣은 것이다. 하지만 문제는 그 코드 안에서 뮤택스 이름을 수정하지 않은 것이었다. 그대로 긁어 붙이기만 하고 두 프로그램의 뮤택스 이름을 다르게 해야 한다는 사실을 잊은 것이다. 그래서 두개의 프로그램이 모두 뮤택스 이름이 같게 된 것이다. 결국 하나가 떠 있으면 다른 하나가 동작하지 않은 것이다. 서너 시간 동안 이리저리 디버깅해 가며 나를 괴롭혔던 문제였지만 달랑 문자열 하나 바꾸는 것으로 해결되었다.

위 경우에도 역시 "프로그램 실행순서를 바꿔 보면?" 하는 직관에 가까운 의문이 먼저 떠 올랐다. 그리고 그렇게 했을 때 데몬이 뜨지 않을 것을 보고 "아! 뮤택스" 하며 문제를 한 번에 찾았다. 그것 역시 논리적인 사고라기 보다는 직관에 가까운 사고라고 볼 수 있다. 마찬가지로 연역적 근거 없기 때문이다. 혹시나 싶어 프로그램을 반대로 실행해 보고 다른 디버깅 수단 없이 그냥 동작의 결과만 보았다. 그리고 뮤택스가 문제가 아닐까 하고 떠올린 것이기 때문이다. 원인은 뮤택스 이름이라는 결과에 도달하기 까지 논리적 사고 절차는 없었다.

내가 뮤택스의 이름을 고쳐서 프로그램의 버그를 수정한 것이 논리적 사고의 결과라면 나는 이것저것 다른 헛된 시도를 하지 않았을 것이다. 그저 처음부터 버그를 잡기까지 전 과정에 걸쳐 일관되고 효율적인 절차와 수단으로 디버깅을 했을 것이다. 하지만 그것이 직관의 결과이기 때문에 다른 과정을 건너뛰고 바로 뮤택스 부분에 관심을 둘 수 있게 된 것이다.

결과적으로 뮤택스 이름을 수정해서 문제를 해결 했지만, 사실 뮤택스가 원인이 아닐 수도 있었다. 나는 충분히 실패를 할 수도 있었다. 내가 논리적인 사고를 거쳐서 뮤택스의 이름이 잘못되었다는 결론에 도달했다면 문제의 원인은 무조건 뮤택스의 이름이어야 한다. 하지만 어떻게 생각하면 내가 운이 좋기 때문에 직관적 사고를 통해 뮤택스의 이름이 원인인 것을 알아낸 것이다. 그것이 원인이 아니었다면 나는 또 다른 시도를 하며 그 뒤로도 몇 시간을 더 보냈을 것이다.

그렇다면 직관은 단순히 그냥 운인 것인가? 운이 좋은 사람은 직관적 사고를 통해서 더 쉽게 원인을 찾을 수 있고 결과적으로 디버깅을 포함한 프로그래밍 전체 작업을 운이 나쁜 사람보다 더 잘 해낼 수 있는 것인가? 결론부터 말하자면 경험이 비슷한 두 개발자가 같은 상황이라면 운이 좋은 사람이 문제를 더 잘 해결할 수 있다. 하지만 경험에 차이가 있다면 운은 경험을 이기지 못한다.

앞서 두 개의 예를 보면 나는 분명 직관적 사고를 통해서 문제를 해결 했다. 하지만 그 직관적 사고를 이끌어 내기 위해서 나는 여러 가지 많은 시도를 했다. 그리고 그 과정에서 나는 나의 경험속의 비슷한 예를 끊임없이 검색한다. 물론 그 검색과정은 의식적으로 이뤄지는 것이 아니다. 나도 모르게 이뤄지는 것이고 그 검색의 결과는 나에게 직관이라는 수단으로 전달되는 것이다.

실제로 경험 많은 개발자와 경험이 적은 개발자가 동일한 문제를 해결하는 것을 보면 작업의 순서는 비슷하다. 디버거를 이용해서 문제가 되는 부분을 찾고 눈에 보이는 몇 가지 코드를 이리저리 고쳐 본다. 하지만 결국 문제는 보통 경험 많은 개발자를 통해서 이루어진다. 경험이 적은 개발자는 경험이 많은 개발자가 어떻게 문제를 해결했는지 보고 들으며 그것을 자신의 경험으로 쌓는다.

프로그램을 만들면서 생기는 여러 가지 문제를 해결하기 위해서 이것저것 해보는 과정을 속된 말로 삽질이라고 표현한다. 위에서 경험이 많은 개발자와 경험이 적은 개발자는 둘 다 삽질을 했다. 하지만 경험이 많은 개발자는 자신의 경험을 통해서 삽질을 빨리 끝냈고, 경험이 적은 개발자는 끝내 삽질을 끝내지 못했다. 다만 경험을 많은 개발자로 부터 이런 문제는 어떤 식으로 해결하는지를 배웠다. 이제 그 개발자는 다음에 비슷한 문제를 접하게 되면 지금의 경험을 바탕으로 문제를 해결할 수 있을 것이다.

프로그래밍은 논리적인 작업이다. 그러면서 동시에 논리적인 작업이 아니다. 어쩌면 세상의 그 어떤 작업보다도 직관에 크게 의존하는 작업일지도 모른다. 하지만 그 직관은 태어나면서 부터 주어지거나 운이 아니다. 그 직관은 곧 경험이다. 경험은 많은 삽질을 통해 얻어진다. 그래서 이제 막 프로그래미에 입문하거나 개발자의 길을 걸으려는 후배들에게 말을 하고 싶다.

"삽질을 두려워하지 말라. 오늘의 삽질은 내일의 무기가 될 것이다."