프로그래밍에 철학을 입히다.

난데없이 C 프로그래밍 언어에 대한 기술적인 이야기가 아닌 프로그래밍의 철학이니 아트니 하는 이야기를 하고 싶은 이유를 굳이 말하자면, 대한민국에서 소프트웨어 엔지니어로서 신념을 갖고 살아가는 것이 얼마나 비참하고 힘든 것인지를 조금이라도 표현하고 싶어서... 정도로 해 두겠다.

현재 본인이 하고 있는 과제 중 하나의 파트를 인도인 외부 개발자에게 아웃소싱하였다. 우리가 필요한 스펙과 요구사항을 이야기해 주고 이에 따른 설계와 개발을 맡겼다. (인도사람의 영어발음은 정말 난해하기 그지없었지만, 어쨌든 가능한 모든 수단(?)을 동원해가며 커뮤니케이션을 하는 데에 성공했다.)

그러고 2개월쯤 뒤, D-Day가 다가왔다. 물론 중간중간에도 중간 점검식으로 미팅을 갖고 모여서 개발 사항에 대해서 공유를 한 바 있었지만, 나 또한 내가 맡아 하는 Task가 워낙 정신적인 Load가 많이 걸리는 일이라, 거의 모든 점검을 PM에게 맡기고, 나는 "뭐.. 알아서 잘 했겠지." 모드로 관조적으로 임했었다......................는게 후폭풍이 이리 크게 다가올 줄은 몰랐다. -_-;;;;;;

D-Day 가 되고 나서야 그 인도 사람이 짜 놓은 C++ 프로그램 소스를 조금이나마 자세히 볼 수 있는 여유가 생겼다. 가장 핵심적이라 할 수 있는 부분의 프로그램 소스를 몇줄 보기도 전에 .... 아뿔싸... 하는 불길한 느낌이 확 와닿았다. 이런!!!

그 프로그램 소스는 그냥 하나의 깡통로봇 같았다. 머리를 톡 하고 치면 땡 하고 울리는 그냥 깡통 로봇.

그는 자신이 짜 놓은 프로그램 소스에 대한 데모 또한 시연했다. 얼핏 보았을 때엔 완벽하게 잘 돌아가는 듯 하였다. 하지만 그 프로그램을 만드는 동안 어떠한 고민도 하지 않은 것 같았다. 즉, 자신이 짠 프로그램이 어디에 사용될 것이므로 그곳에서 사용하려면 어떻게 돌아갈 것이니 이러이러한 부분에 대해서는 조금 더 신경을 써야 하고... 뭐 이런 식의 사고는 전혀 하지 않았으며, 그냥 그저 주어진 요구사항을 듣고 기계처럼, 컨베이어 벨트에서 부품을 조립하는 사람처럼 뚝딱뚝딱 만들고 끝내버린 것이다.

이제 본인은 C 프로그래밍에서의 하나의 매우 사소한 예를 들려고 한다. 아래에 예를 들어 놓은 함수의 기능은 간단하다. 주어진 문자열을 받아 그 문자열의 길이를 반환하는 함수이다. (C 표준 라이브러리에도 존재하는 strlen 함수, 그것이다.)

물론 C 표준 라이브러리 내에서 strlen은 충분히 optimized되었고 robust한 함수일 것이다. 하지만 어떤 환경에서 표준 라이브러리를 사용할 수가 없어 수고스럽게 strlen과 같은 기능을 하는 함수를 직접 짜야 한다고 설정을 가정해도 좋다. 어쨌든 예를 보자.

[예 1]

int my_strlen_1( char *s )
{
    int i=0;
    while( *s )
    {
        i++;
        s++;
    }
    return i;
}

[예 2]

size_t my_strlen_1( const char *s )
{
    size_t i=0;
    while( *s )
    {
        i++;
        s++;
    }
    return i;
}

예 1, 예 2를 이용한 결과는 일반적인 경우 정확히 동일하다. 하지만 프로그래머가 보기엔 예 1 은 예 2 보다 왠지 세련되어 보이지가 않다.

뭐.. 결과만을 따진다면 예 1 이나 예 2 나 같은 점수를 받았을 것이다. 아니, 예 2 는 예 1 보다 조금이라도 고민을 더 했을 것이므로, 생산성(?)을 따지면 오히려 예 1 보다 예 2가 더 낮은 점수를 받았을 지도 모른다.

여러분은 이에 동의하는가?

이런 단순한 것을 프로그래밍의 철학에 비유하는 것이 매우 거창할 수도 있겠지만, 이러한 사고가 모이고 모여 거대한 프로그램 결정체가 형성됨을 생각한다면, 뭐.. 철학이라 해도 과언은 아닐 것이다.

하지만... 더욱 중요한 것은... 저 예가 고상하게 철학이나 운운하는 정도의 것이 아니라는 것이다. 즉.. 저 프로그램 코드가 일회성으로 그냥 짜고 사용한 후 버리는 것이라면 모르겠지만, 계속적으로 업데이트를 하고 재사용하는 코드라면 두 예의 차이는 엄청날 수도 있다.

우선 예 1은 인자로 받는 s 의 문자열 내용을 바꿀 수도 있다. 즉, 시간이 지나서 업데이트를 하는 도중에 s 의 문자열 자체를 변경하는 코드를 실수로 은연중에 넣을 경우 엄청난 재앙(?)이 발생할 수도 있다. 또한, 추가적인 코드에 의해 문자열의 길이를 음수로 반환하는 오류도 배제할 수 없다.

예 2는 그러한 우려를 원천적으로 차단한다. 프로그래머가 실수를 범했다 할 지라도 컴파일에서 error 를 알려준다. 이는 규모가 큰 프로그램일 경우 훨씬 더 막강한(?) 힘을 발휘한다.

결국 프로그래밍의 철학은 장기적으로 보았을 때 프로그램의 완성도에 직접적이고 중요한 영향을 미친다.

(하지만 이러한 factor들이 대부분의 경우 제대로 된 평가를 받지 못하고 있다는 것이 불편한 진실이라고나 할까.)

예 2에서 붙은 const 와 size_t 라는 키워드는, 곧바로 정량적으로 보이는 획기적인 향상은 측정할 수 없으나, 중요하고 필요한 것임에는 분명하니.... 이런건 아트라고 해도 되지 않을지...