말은 결과를 만들어야 한다.

연쇄긍정마

“위 코드의 버그를 조심하라. 올바르다고 증명하기만 하고 실행해 보지는 않았다.”
“Beware of bugs in the above code; I have only proved it correct, not tried it.”   
도날드 E 크누스(Donald E. Knuth)

명언카드 만들기 - android

1.

개발자들과 대화를 하다보면 “숨넘어간다”라는 표현을 하는 사람들이 적지않다. 그들(내겐 우리들)과 대화를 하다보면 2개의 난제를 경험하게 되는 데,  첫번째는 “한국말 같은데 무슨 말을 하는 지 모르겠다” 이고 두번째는 “왜 문제가 있다는 것이지?”라는 점이다.

첫번째의 경우, 개발자만의 문제는 아니라고 본다. 어느분야나 자신의 업무를 다른 도메인(분야)의 사람들에게 설명하는 것은 고된 노동이자 어려운 작업이기 때문이다. 하물며 IT 업종에서조차 최종 난이도의 끝판왕 개발자들과 “인간의 대화”로 협업하고자 한다는 것자체가 큰 실수였다고 본다. 전세계를 둘러보아도 가장 훌륭한 개발자를 찾는 덕목 1순위가 “대화가능한…”인 것만 보더라도 소프트웨어 상식이 없는 상태로 대화를 시도했다는 것 자체가 무리였다고 본다. 그러나 이 부분은 학습이 되면 대화에 전혀문제가 되지 않는다.

문제는 두번째이다.    

2.

프로그래밍은 “맥락(Context)”를 중시한다. 그래서 프로그래밍 용어에는 Context라는 것이 존재하며 그것을 code화 시켜 사용하는 언어들도 적지않다. Context에 맞지않은 상태에서 메모리를 액세스(변수처리, 연산)하다보면 오류를 일으키며 프로그램은 종료된다. 더 쉽게 이야기하자면 “정의되지 않거나 올바르지 못한 정보를 가지고 하라말라를 미리 코딩했다면 실행 중 종료”가 되는 것이다. 이를 전문용어로 런타임 에러라고 하는데 “코딩 시에는 발견되지 않는다”. 즉 “말은 그럴 듯 하더라도 실행될 때 문제점이 발견”되는 것이다.  

3.  

개발자 영역의 사람들은 “대화에서 오류”를 잡아내는 습성이 있다. 상대가 요구하는 내용을 분석하고 머리 속에 빠르게 시뮬레이션을 한다. 그리고 그의 말에서 Context에 위배되는 내용을 찾게된다. 그렇기 때문에 “이거 간단하잖아요? 왜 못해요?”라고 말할 때마다 “안되는 이유를 수십개넘개 전광석화처럼 설명을 한다” 그러다보니 개발자와 대화하기는 개발자가 개발도구와 대화하는 것처럼 깝깝할 때가 많다. 개발자도 개발IDE가 던져대는 오류메시지를 읽어가면 닝겐인 내가 참아야 지 라는 생각을 할 때가 많다.

개발자들은 언제나 자신의 코드(글)를 개발도구(IDE)에게 까인다. 뭐가 문제다. 뭐가 문제다. 그러면서 친절하게 가르쳐주지도 않는다.

4.

개발자 문화를 떠나, 평범한 일상에서도 “그럴 듯한 말”이 넘치는 경우가 많다. 사실 그런 말에 토달고 싶은 생각은 1도 없다. 누구나 인정하는 좋은 말인데 왜 토를 달아야 하는가? 문제는 “말처럼 된다면”을  결과만 내놓으면 되는 것이다. 그런데 증명도 안하고 결과도 없고 단지 강요하는 것이다. 결국 그런 말들은 “머리 속 시뮬레이션”만으로 맹신하다보니 결과물인 현실은 “정신승리”로만 끝나게 된다.

아무리 괜찮은 생각과 말이라도 결과를 내놓지 못한다면 “버그(bug)”가 존재하는 것이다. 버그는 트레이싱(사상검증)을 통해 fix가 가능하다.

이런 이유로 리누스 토발즈의 명언을 붓펜으로 쓰고 책상 옆에 붙이고 산다.

극동아시아의 성격파탄자 개발자가 핀란드의 디아블로급 성격파탄자의 명언을 가훈으로 삼고있다.

자신이 뱉은 말의 검증과 결과를 두려워한다면 그건 자신의 말에 오류가 있음을 알리는 “에러메시지”이다. 개발자 문화는 이런 문화이다. 이런 문화의 긍정적인 점은 "개구라 왕눈이(=구라쟁이)"로 변태됨을 막을 수 있는 확률이 높다는 것이다. 자신이 얼마나 나약한 존재임을 깨닫는 직종이 개발자이기에 알아도 아는 척하기 힘들다. 

틀림은 문제가 아니다.
틀림은 일상이고 자연스러움이다.
문제는 틀림을 인정하지 않고 반복하는 것이다. 
변화가 없고 생각은 멈추게 된다. 
결국, 결과물은 쓰레기가 된다.