고성능 프로그래머의 습성

10년차 프로그래머 기준, 생산성이 가장 좋은 그룹과 낮은 그룹의 프로그래머의 생산성 차이는 40배가 넘는다는 조사 결과가 있습니다.

실제로 대형 프로젝트를 진행하다 보면, 프로젝트가 복잡할 수록, 유지보수 및 향후 재사용까지 고려하면 40배 수준이 아니라, 더 큰 차이가 발생할 수 있다고 생각합니다.

'일반인'들은 수긍하기 힘들수 있겠습니다만, 

자신이 '잘하는 이' 에 들어봐야 '정말 잘하는 이'들이 보이고, '정말 잘하는 이'들에 들어봐야 '따라잡을 수 없는 이'가 있다는 것을 비로소 알 수 있습니다. 분야를 막론하고 말이죠.

어떤 차이가 동일한 시간을 숙련했는데도 불구하고, 이런 차이를 만들게 될까요?

상위 1%, '그들'의 습성을 세가지만 들여다 보겠습니다. 특정 언어나, 분야에 종속적이지 않은 특성으로요.

프로그래밍이란것이, 문제가 주어지면 문제를 분석해서 식을 만드는 일입니다.

문제를 명확히 주는 경우도 있지만, 모호한 미션이 주어지더라도 여러가지 상황을 고려해서, 문제를 형상화 해서 구현하는 능력이 중요합니다.

두가지 예를 들어보지요.

• 소수를 출력하는 함수를 작성하라.
• 다음은 함수의 결과이다. 1, 2, 3, 5, 7, 11… 의 결과를 내는 함수를 작성하라.

둘 다 같은 말이지요. 좋은 개발자는 2번문항을 보고 이거 소수네 하고 추론해 낼 수 있어야 합니다. 소수를 배우지 않았더라도 '1과 자신을 제외하고 다른 정수로 나누어지지 않는 수'를 빠르게 도출해 낼 수 있어야 합니다. 

문제를 두번째처럼 주는 사람이 잘못 아니냐구요? 아닙니다. 개발자가 해야 합니다. 실제 요구사항은 명확하게 정의되지 않고 주어지니까요.

여담이지만, 이런 문제 본적이 많지 않나요? 네. 온갖 종류의 IQ테스트 문제로 이런 식의 문제가 많이 나옵니다. IQ테스트 문제는 개발자가 만든거 아닐까 싶을 정도로 개발뇌를 만들기 좋은 훈련도구입니다.

훈련을 통해 어느정도 극복 가능하겠습니다만, 문제는 그들은 생활 속에서 이런 훈련들을 항상 하고 있다는게 문제입니다. 

특히 다른사람의 s/w를 사용하다 문제점을 발견했을때, 증상을 살펴보고, 동일한 증상을 잘 끌어내곤 합니다. 어떤식으로 짰을지 머리속으로 그려봤기 때문이죠. 구현 방법도 대게는 큰틀에서 맞습니다. 그리고, 틀렸을 때 더 좋아 합니다. '이렇게도 할 수 있구나! 쩔어!' 하고...

엘리베이터 버튼을 누르더라도, 어떤 규칙으로 동작하는구나 하는것을 파악하고 있습니다. 행여 다른 방식으로 동작하는 엘리베이터라도 만나면 왜 이따위로 동작하는지, 논리의 차이를 분석하고 있지요.

'공부'해서는 따라잡기 힘들어요. 공부 이야기는 뒤에 한번 더 언급하겠습니다.

2. 사고의 넓이가 다릅니다.

중대형 프로젝트를 진행해 보면 알 수 있습니다만, 그들은 자신이 참여하고 있는 프로젝트의 코드를 모두 알고 있습니다. 어떤 코드는 정확한 논리 루틴까지 알고 있기도 하며, 적어도 S/W에 어떤 영향을 주는지를 파악하고 있습니다. 그래서 가끔은 결정을 하는데 어려움을 겪기도 합니다. 내가 짜는 코드가 수십만 라인을 넘어설지 모르는 전체 코드에 어떤 영향을 줄지를 판단하느라… 

물론 내가 짜는 코드가 다른 함수들에 영향을 광범위하게 미치는 코드는 좋은 코드는 아닙니다만, 현실적으로 *수없이* 미친듯한 사이드 이펙트가 발생할 수 있습니다.

일례로, 누가 어떤 함수를 수정했다는 로그를 확인하였다면, 이미 수많은 생각이 머리를 스칩니다. 이 함수의 수정은 어떤 식으로 잘 못 짜기 쉽고, 만약에 그렇다면 어떤 영향을 미칠건데, 확인해 봐야겠다. 하는 의식의 흐름이 자연스럽게 이루어집니다. 의식적으로 하는게 아니라, '수정됨' 한줄 읽고 거기까지 생각이 그냥 나는겁니다.

          보통개발자와 '그들'의 코딩 과정 차이를 살펴보겠습니다.

• 보통: 솔루션을 찾는다. -> 짠다.
• 그들: 솔루션'들'을 찾는다. / 사실 대부분의 솔루션은 머리속에 '대충 이런 방법이 있지'라는 사실을 이미 써 봤거나, 알고 있거나, '당연히 있겠지.' 라고 생각하고 있습니다. '당연히 있겠지.'가 중요한데, 막연히 있겠거니 하는게 아니라, 사용하는 라이브러리의 수준과, 유사한 기능을 가지는 다른 내가 알고있는 라이브러리의 상황이나, 라이브러리에서 제공을 해야할만한 당위성을 추측해서 판단하는거지요.

다음으로, 솔루션들을 머리속에 그려보고, 추가로 내가 아직 모르는 방법이 있을지 구글링 해 보고 아래 사항들,

• 요구사항
• 코드 간결성
• 품질과 리소스
• 코드의 지향성
• 현재 프로그램 상황 （기 사용중인 라이브러리 등）
• 발생할 사이드이펙트의 심각성과 대응 비용
• 유지보수 비용
• 향후 확장성
• 해당 방법에 대한 숙련도

등을 고려해 결정합니다.

심지어, 비프로그래밍적인 방법까지 잘 고려합니다. （예를들어, 데이터를 잘 정제하는것이 더 좋은지에 대한 판단）

확신이 들지 않는다면 가코드 만들어 성능 테스트도 수행합니다. 

그래야 다음에 더 확실하게 결정 할 수 있으니까.

두가지 예시를 너무 극단적으로 들었습니다. 아무것도 고려 안하고 구글링 해서 나온거 바로 코딩하고 덮어버리는 사람이 많지는 않겠지요. 중요한건, '그들'은 수많은 고려사항을 종합해 판단하는 것을 의식해서 하는게 아니라, 그냥 합니다. 

상황이 복잡하고 중대한 사항일수록 오히려 개발 속도가 느리기도 합니다. 물론, 고려사항을 줄인다면 당장 함수 하나 짜는 시간은 줄 수 있겠지만, 전체 개발기간으로 따지면 더 느리거나, 영원히 개발이 끝나지 않을 수 있습니다.

3. 공부하는 자세가 다릅니다.

새로운 문법이나 기술이 등장하면 의무감에 공부하는 사람이 많겠습니다만, '그들'은 새로운 기술에 대한 컨셉을 들으면서 자신들이 짜왔던 코드를 어떻게 바꿀 수 있으며, 어떤식으로 사용할지에 대해 생각하며 정신 없습니다. 너무 멋져서요! 

그리고 나서 자세한 내용을 들여다 보며 머리속에 그렸던 작동방식과 동일한지, 예측한 사용처에 진짜로 적합한지. '확인'합니다.

그들이 하고 있는것은 공부가 아니라 재미있는 놀이입니다.

천재는 노력으로 만들어지는게 아니라, 습관으로 만들어지는겁니다.

사람이 노력할 수 있는것은 한계가 있어요. 한달, 두달, 일년, 이년은 노력 할 수 있지만, 평생 노력하며 산다는 것은 거짓말입니다. 

특히나 프로그래머가 되려 하거나, 막 된분들에게 부탁드리는 말씀입니다. 

노력하지 말고 습관을 들이세요. 습관! 생활!