똥 개발자

똑똑한 사람과 정말 똑똑한 사람의 문제해결 능력에 대해 이야기 할 때, 똑똑한 사람은 남들이 풀지 못하던 난제를 다른 이들이 생각하지 못하는 엄청난 방법으로 풀어내고, 정말 똑똑한 누구나 생각해 낼 수 있는 간단하고 쉬운 방법으로 풀어낸다고 하죠.

사실은 극적인 예시를 위해 왜곡된 이야기라고는 하지만, 가장 유명한 일화 중 하나는 우주에서 사용 가능한 필기구 일 것 같네요.

소련에서 스푸트닉 호를 통해 세계 최초의 우주인을 탄생시키고 , 미국에서 이에 뒤질세라 아폴로를 달에 착륙시키며 양국간 치열한 우주 전쟁을 펼치던 시절에 무중력 상태에서는 볼펜을 사용할 수 없어서 미국은 수백만불을 투자해 우주펜을 개발했고, 소련은 연필을 사용했다고 하죠.

실제 개발자의 유일한? 결과물인 소스코드 또한 이와 마찬가지입니다.

괜찮은 실력의 아키텍트나 시니어가 회사에 들어오면 이것 저것 소스 구조에 수정이 일어나기 시작합니다. 기존보다 더 효율적으로, 더 안정적인 구조로 코드가 변하는데, 문제는 많은 비중을 차지하는 저 같은 똥 개발자들이 그러한 변경에 익숙하지 못합니다.

예를들어 우리 회사의 개발환경은 Java 1.7에서는 Lambda Expression이 지원되지 않습니다. Lambda가 코드 가독성이나 직관성에서 좋은 것은 다 알지만 지원이 안되니 안쓰죠.

그런데 회사에 있었던 상당한 실력의 시니어가 우회적으로 Lambda Expression이 지원되도록 만들어 이곳 저곳에 수정을 했습니다. 다들 좋다고 열광했죠.
그런데 문제는... 코드 자체의 가독성이나 코드 작성시 편의성은 올라갔을지 모르겠지만, 디버깅 상황이 왔을 때 중간에 Lambda Expression을 지원화기 위해 만든 wrapping 함수들이 디버깅 속도를 현저하게 떨어트린다는 것입니다.

제가 입사하기 전에 있었던 또 다른 아키텍트가 만들어 놓은 것 중에 하나는 Java에서 마치 C처럼 preprocessor를 쓸 수 있는 환경을 만들어 놓은 것입니다. 워낙 원빌드 멀티 OEM을 지원하려다 보니 이런 저런 dynamic injection이 많은데, preprocessor로 빌드 타임에 컨트롤 할 수 있는 툴과 annotation을 만들었죠. 빌드 속도에 엄청난 차이가 있기에, 중간중간 마이너 업글 릴리즈를 할 때엔 자주 사용하는데, 이 역시 내부를 파고들어가면 복잡한 구조로 되어있다보니 간혹 잘못된 annotation이 추가되었거나, 빌드 문제가 생기면 찾아내기가 쉽지 않더군요.

오늘 우리 회사에서 1년 넘게 끌고오던 난제 중 하나를 해결하게 되었습니다.
나름 다양한 방법을 통해 자체 검증도 해보고 이리저리 예외적 상황도 만들어 봤지만, 일단은 정상적으로 동작을 하는 것 같네요.

그런데, 전 그다지 훌륭한 개발자는 아니다보니, 남들이 알지 못하는 새로운 방식으로 문제를 휘리릭 푼 것도 아니고, 해결 방법을 보고나면 무릅을 탁! 치게 만드는 방법을 제시하는 것도 아니기에, 그냥... 그냥 해결 했습니다.

추후 디버깅은 차치하고라도 당장 코드 가독성이 어마무시하게 떨어집니다.
복잡한 알고리즘을 적용한 것은 아니지만 단순 비교/정렬/병합이 어마무시하게 많이 발생하는 코드를 만들었고, 그런 코드들이 한 곳도 아니라 수십 곳에 너져분하게 펼쳐지게 되버려서 코드 리뷰를 하는데 우리 팀 시니어들이 상당히 애를 많이 먹더군요. 코드를 보면 직관적으로 딱 이해되는 것은 차치하고 종이에 메모를 해가며 코드 리딩을 해도 몇몇 곳은 잘 이해하기 힘든 복잡한 상호 참조까지 있다보니 결국 코드 리뷰를 할 때 제가 참여해서 하나하나 설명해야 하는 부분도 있었습니다.

다시 개발자라는 커리어로 돌아오기 이전에도 저는 제 스스로를 똥 개발자라고 불렀는데, 5년이 넘는 경력 공백으로 인해 이전보다 굳은 머리에 퇴보한 기술 지식으로 인해 지금은 스스로 묵은 똥 개발자라고 생각합니다.

그냥 이런 평범한 개발자로 만족하며 사는 것도 좋을 수 있지만, 사람 욕심이라는 것이 그렇지 못하다 보니, 성과나 실력에 대한 욕심을 계속 갖게 되곤 하죠. 하지만 문제해결 능력이라는 것이 어디 하루아침에 생기는 것도 아니고, 제가 발버둥을 치며 따라간다고 생각하면 저보다 앞에 있던 친구들은 그보다 더 멀리 치고 나가 있었습니다.

그래서 회사 생활에서 나름 승부수가 필요하다고 생각되는 시점이 오면, 저는 아래 공식을 생각하며 도전을 하곤 합니다.

실력² x 시간 = 성과

정확히 이 공식이 맞는지는 모르겠지만, 지금까지 제 경험상 나름 높은 성공률을 보인다고 자부합니다. 실력은 제곱이 되기에 영향력이 크지만, 당장 승부처가 눈앞에 왔을 때에는 제가 그 값을 조절할 수 없습니다. 그래서 1주~1달 정도 단기간을 놓고 보면 변수라기 보다는 상수에 가깝죠.

그래서 저는 시간을 많이 투자합니다.

이렇게 승부처가 찾아왔을 때 벼락치기 시험공부마냥 시간 투자를 급격히 늘릴 때에는 저만의 몇 가지 규칙이 있습니다.

먼저 적절한 시간 투자 대상을 잡아야 합니다.
문제점이나 개발 요구사항들 중에 덩어리가 작은 녀석들은 아무리 많이 해결해 냈다 해도 그다지 임팩트가 없습니다. 어느 회사건 SW 회사라면 묵은지 마냥 몇 달 째, 혹은 몇 년 째 해결하지 못하고 이런저런 work around를 통해 대응해 가는 문제들이 있습니다. 평소에 그런 문제점들을 유심히 살펴보고 연구하다가 어느정도 시간을 투자하면 혼자서 해결을 할 수 있을만한 문제점을 시간 투자 대상으로 선정합니다.

그리고 본격적인 시간 투자가 이루어 질 때에는 분산이 되지 않도록 해야 합니다.
개발자 업무 특성상 단 한가지의 요구사항이나 문제점만 집중적으로 연구하고 수정하는 것은 쉽지 않습니다. 항상 여러 곳에서 다양한 문제가 터져 나오고, 서로 1순위 문제라고 주장하죠. 하지만 제곱의 효과가 있는 실력이 이미 정의된 상태에서 시간만으로 승부를 해야하기에 1분 1초라도 분산이 된다면 성과가 떨어지거나 안나올 수 있습니다.
정말 크리티컬한 문제고 스스로 자신이 있으며 대략적인 해결방안에 대해 회사 내부에 공유하고 메니져에게 당분간은 이것만 할 것이라고 공언을 하는 것도 하나의 방법일 수 있습니다. 문제의 심각성이 조금 낮거나 잠재적 심각성은 크지만 실제 심각한 클레임이 없는 경우라면 잠재적인 심각성이 얼마나 우려할 만한 수준인지 먼저 이야기 하는 것도 좋습니다.

주유소 습격사건의 무대포 처럼 이렇게 한 놈만 패는 것은 개발자의 정신적 안정이나 체력 문제로 인해 제한적일 수 밖에 없지만, 간혹 승부수가 필요 할 때 손오공의 원기옥 처럼 한 번 씩 사용하는 것은 나름 좋은 결과를 가져오는 것 같습니다.

하지만 이런 방법은 중장기로 봤을 때 썩 좋은 방법은 분명 아닙니다.

저도 최근에 한 2 달 정도 간격을 두고 이 필살기를 2회나 사용했더니 건강에 적신호 까지는 아니더라도 노란불이 들어온 것 같네요.

정말 승부처에 필살기를 쓰기 위해 개발자도 항상 운동을 하며 체력을 다져놔야 하고, 또 이런 필살기가 필요 없이 꾸준히 항상 인정받는 사람이 되기 위해서는 실력을 항상 다져 놓는 것이 더 좋은 방법일 것 같습니다.

아... 오늘 마무리 지은 승부수를 마지막으로 내년 여름 연봉 조정 기간 직전까지는 더 이상 원기옥 소환을 하지 않으려고 생각 했지만, 조만간 제가 시장문제 팀에서 신규 개발팀으로 소속을 옮기게 될 예정이라 새로운 동료들과 새로운 메니져에게 저의 뻥튀기 전투력을 보여주려면 몇 달 내에는 다시한번 승부수를 던져야만 할 것 같네요.

전에는 그렇게 신규팀이나 re-architecture 팀으로 그리도 가고싶어 했지만, 참 타이밍이... 절묘하게 최악인 것 같네요. 이렇게 조직 변경이 될 줄 알았으면 오늘 끝낸 이 문제점은 그냥 못 본척 사뿐히 즈려밟고 넘기는 것 이였는데, 조금 안타깝습니다. ㅠㅠ

저 같은 뻥튀기 말고 진짜 실력자 분들... 정말 부럽습니다.