막장개발자의 블로그

프로그램 쪽으로 밥을 먹고 살다 보면 많이 듣게 되는 용어들이 있다.  오늘 포스트의 주제인 '가독성'도 그 중 한가지인데 그에 대한 이야기를 해보고자 한다.


가독성 있는 Code
전직장에서 있었던 일이다.  새로 오신 과장님 한 분과 Project를 하나 같이 진행했었는데 재미있는 일이 하나 생겼다.  그분 왈, 필자가 짠 Query는 도무지 알아볼수가 없으며 실력을 자랑하기 위해 일부러 어렵게 짠, 일명 잘난 체하는 Query라는 것이다. 모름지기 모든 Code와 Query는 가독성이 우선이란다.

필자가 일하고 있는 공장자동화 분야 중 상위시스템에서 다루는 데이터들은 년단위로 쌓이면 수백만~수천만건은 금방이다.  그런 다량의 데이터를 다룰 때 프로그래머는 본인이 작성한 SQL이 하는 일을 정확하게 알고 Control해야 함에도 불구하고, 현실은 그렇지 못하다. 동적쿼리가 이리저리 날라다니는 건 기본, History성 데이터여서 Index를 반드시 타야하는데도 Full Scan 실행계획으로 수행되는 일도 다반사다. 그러다보니, 사용자가 조회 버튼을 누른 후 멍하게 기다리는 것이 싫어 동료들이랑 커피 마시러 가거나, 화면 Loading에만 몇 분이 걸려 그 화면을 아예 안 쓰는 경우도 발생한다.

사용자가 프로그램이 죽은 건지 계속 실행되고 있는건지 궁금해하는 상황에서 가독성만 있는 Query가 무슨 소용인가?  그때 필요한 것은 가독성만 있는 Query도 아니고, 프로그램이 죽지 않았다는 걸 알리기 위한 ProgressBar도 아니며 그러한 문제를 해결할 수 있고 빠른 시간에 응답을 줄 수 있는 Query뿐이다.

필자도 가독성의 중요성을 부인하지 않으며, 일부러 어렵게 짜서 분석하는 사람이 어려워 하는 걸보고 기쁨을 느끼는 변태-_-도 당연히 아니다.  물론 Static하면서 부분범위처리를 하기 위한 기법, 카테시안 Product 등이 섞인 Query를 그런 개념을 모르는 사람이 보면 가독성이 없다고 느낄만 하다고 생각한다.  하지만 그런 부분은 이미 널리 알려진 기법들이며 넉넉잡아 6개월만 노력하면 능숙하게 쓸 수 있는 단계의 SQL일 뿐이다. 
자신이 이해하지 못한다고 해서 가독성이 없다고 단정지어서야 되겠는가?

필자는 그 사실에 분개했다.

그런데, 이런 가독성에 대한 논란들은 SQL에 대한 부분뿐만 아니라, 다른 곳에서도 자주 볼 수 있었다. 
예를 들자면 Design Pattern 혹은 Interface을 사용한 Program이 분석하기 복잡하니 Dialog 하나 및 Class 한두개에 모든 Logic을 넣기를 바란다거나.  아니면 회사에 있는 C++ Template 혹은 STL을 모르는 개발자의 가독성을 위해 나머지 개발자들이 검증된 STL을 포기하라는 요구를 받는다거나. (필자의 경험으로 볼때 그 이야기를 하는 사람은 STL이 C++ 표준이라는 걸 모르거나 한 번도 사용해본 적이 없다는 데에 내 한달치 술값을 걸겠다.)


왜 이런 논란이 발생하는 것일까.
가독성이라는 표현이 굉장히 애매모호한 표현이기 때문이며, "리더쉽"처럼 뭔가 언듯 들으면 좋은 말처럼 들리기 때문이다.
사장의 리더쉽과 말단 직원의 리더쉽이 같을 수 없듯이 가독성이라는 표현도 대상이 누구냐에 따라 다르게 표현된다.
따라서, 가독성을 이야기할 때는 어떤 대상를 기준으로 할지가 정의되어야 한다. 즉, 신입사원도 다 이해할 수 있는 Code를 말하는 것인지 아니면 사내 Coding 표준이나 SQL 작성 Guide에 맞는 것을 가독성이 있다고 할 것인지를 정해야 한다.
그런데도 몇몇 사람들은 그 애매모호함을 이용하여 악의적인 발언을 서슴치 않는다.
또한, 성능이나 유연성 혹은 검증된 방식이라는 이야기는 모두 뺀 채로 가독성!! 이라는 한가지만 물고 늘어진다.
(물론 본인이 모르는 개념이라는 걸 인정하기 싫다거나 새로운 걸 배우고 싶지 않다거나 하는 이야기도 하지 않는다.)

이런 상황이 문제가 되는 또다른 이유는 결정권자들이 그런 뻔한 음해성 거짓말을 믿는 경우가 생기기 때문이다. 
결정권자들은 그런 세부사항에 대해 잘 모르며, 그들도 그런 Code 혹은 Query는 본 적이 없을 수도 있다.  또, 이런 현상은 어려운 Code를 짰다고 지목당한 사람과 다른 사람들의 기술적인 수준의 편차가 심할 수록 자주 나타나는데, 그런 상황에 처한 회사는 추후 이 사람이 다른 프로젝트로 이동하거나 퇴사했을 때도 누군가가 수정할 수 있는 코드를 원하는 것이 당연하다.


어쨋든 서로가 서로를 이해하기 힘든 상황이라는 것은 분명하다. 
필자는 그런 일을 겪고 업무에 대한 정열이 사그라들었으며, 그 사람의 말만 믿고 나를 '나름 똑똑하긴 하지만 데리고 일하기는 힘든' 직원으로 보는 경영진의 판단에 변명할 의욕마저 없어졌다. 필자가 회사에 있던 기간 동안 어느 누구보다도 많은 사내 교육과 Seminar를 진행했으며 알고 있는 내용을 나누고자 했던만큼, 그만큼 더 서운했다.

회사를 떠난 후 전해들은 소식에 의하면 지금은 하나의 SQL로 처리할 문제를 몇개~몇십개의 SQL로 알아보기 쉽게 나누고 SQL로 해결안되는 부분은 프로그램으로 어떻게든 짜지만 어떻게 실행되는지는 아직도 아무도 모르고 있다고 하며, STL을 사용한 Code들도 SQL 가독성 문제를 제기한 분의 문제제기로 결국은 다 새로 짜고 있다고 한다.
(회사를 나온 것은 그 일 때문은 아니다. 물론 전혀 관련이 없진 않았겠지만.)


이제 아무도 새로운 것을 배우지 않아도 되며 누구든 Code를 고칠 수 있다. 모두 행복해졌다.



이런 일을 겪고 있다면
그런 사내 분위기에 시달리고 있는 사람이 있다면 한가지 충고를 해주고 싶다.  본인이 옳다고 생각하는 길을 버리지 말고 계속 실력을 쌓아라.  언젠가 여러분의 실력을 인정해주는 상사 혹은 회사를 반드시 만나게 될 것이다.

물론 막연히 기다리기만 한다고 해서 그런 환경이 오지는 않는다.  본인이 가진 걸 주변 사람들에게 나누고, 회사가 안심하고 그 방법을 선택할 수 있도록 여건을 만들어야 한다.
먼저 주변의 준비 안된 사람들을 위해 사내교육이나 세미나를 시작하라. 본인의 수준까지 한번에 올라오기를 기다리지 말고 SQL이라면 Parameter Binding의 잇점부터, STL의 문제라면 Template에 대한 이해를 도와라. 말이 쉽지 생각보다 지루한 기간일 것이다.
그리고, 여러분의 실력과 당당함에 꿀려 발악하는 그 가여운-_- 사람은 그러려니 하고 좀 토닥여주라.  속으로는 '저런 멍청한 놈이 있나' 싶겠지만, 그 사람이 멍청하다는 것을 증명해봐야 달라지는 것은 아무것도 없다.


이런 사람을 고용하고 있다면
회사의 입장에서는 조금 불안할 수도 있을 것이다. 하지만 위에 나온 상황과 같은 실력의 하향평준화가 정말 회사가 원하는 상황인가를 한번 생각해보라.  이 기회를 전체 직원들의 수준을 올릴 수 있는 기회로 삼는 것은 어떨까?  그리고, 당장 결과가 나오지 않더라도 좀 더 기다려주라.  사람들의 실력향상은 기본실력과 재능에 따라 사람마다 편차가 있으며 몇 주 안에는 쉽게 오르지 않는다.

이 포스트는 새로운 개념이나 방법론의 도입을 무조건적으로 찬양하기 위해서 쓴 글은 아니며, 또 회사에 없던 개념을 도입하는 것이 꼭 올바른 정의의 편이라는 것을 의미하는 것은 아니다. 다만, 자기개발을 꾸준히 하는 사람이 회사내의 여론몰이에 휘말려 오히려 역적이 되는 상황이 안타까웠을 뿐이다.

직원들 비싼 돈 들여가며 사외교육을 보내고 있는 회사라면 지금이라도 주위를 둘러보라.
의외로 파랑새는 옆에 있을 수도 있다.