2018-02-23

좋은 코드를 많이 봐야 한다

 얼마 전 트위터에서 재밌는 이야기를 봤다.

 가짜를 알기 위해서 가짜를 공부할 필요가 없다는 글인데, 이 트윗을 보니 어렸을 때 봤던 갓핸드 테루라는 의료 만화가 떠올랐다. 갓핸드 테루는 신입 의사인 마히가시 테루가 수련을 받으며 명의가 돼가는 과정을 그린 의료만화인데, 그중에서 다음과 같은 에피소드가 나온다.
 주인공 테루가 슬럼프에 빠져 엑스레이 판독을 못 하게 되자 선배 의사가 테루에게 과제를 하나 내준다. 어느 환자의 엑스레이 사진을 주면서 이 환자의 문제가 무엇인지 찾아오라는 것이었다. 테루는 열심히 고민해보지만 결국 문제를 찾지 못하고 문제를 냈던 선배에게 물어보는데, 그 사진은 사실 정상인의 엑스레이 사진이었다. 테루는 슬럼프에 빠진 자신을 놀린 거냐며 시간 낭비했다고 화냈지만, 실제 환자의 엑스레이를 보면서 선배의 의도를 알게 된다. 환자의 엑스레이를 통해 공부하면, 병의 종류에 따라서 다른 엑스레이를 보며 공부해야 하고, 엑스레이 판독을 할 때도 가능한 모든 병을 고려해봐야 한다. 하지만 정상인의 엑스레이에 한 번 익숙해 지면 익숙하지 않은 부분이 문제가 있는 부분이라고 금방 눈치챌 수 있다는 것이다.
 어렸을 때는 이 장면을 그저 만화적 과장이라고 생각했다. 하지만 프로그래머로 일하다 보니 딱히 과장이 아닐 수 있다고 생각하게 됐다.

 흔히들 코딩할 때 정답은 없다고 말한다. 같은 결과를 낼 수 있는 수많은 방법이 있기 때문이다. 하지만 코딩에 오답은 있다. 이는 버그가 있는 코드를 말하는 건 아니다. 버그가 있는 코드는 논할 가치도 없다. 오답은 코드를 수정했을 때 버그가 발생할 확률이 높은 코드다. 수정에 민감한 코드는 아무리 지금 버그가 없어도 오답이다.
 근데 프로젝트를 진행하다 보면 이런 오답 같은 코드들이 많이 보인다. 이런 오답 코드를 작성하는 이유는 보통 제대로 된 방법으로 코딩하면 시간이 많이 들고 귀찮기 때문이다. 그래서 약간의 편법을 쓰면 일을 빠르게 진행할 수 있을 거로 생각하기 때문이다. 뭐 가끔은 프로젝트가 끝날 때까지 아무 문제가 없을 수도 있다. 하지만 어떤 이유로든 코드를 수정하게 되면 큰일이 발생한다.

 그렇다면 오답과 오답이 아닌 코드를 어떻게 구분할 수 있을까? 문제가 됐던 프로젝트를 열심히 분석하면 어떻게 수정할지 알 수 있을까? 문제가 된 프로젝트를 분석하면 무엇이 문제였는지는 알 수 있을 것이다. 하지만 어떻게 수정할지는 알기 어렵다. 아마 다른 오답 코드를 작성할 것이다. 오답이 아닌 코드를 만들기 위해서는 잘 짜여있는 코드를 많이 봐두는 것이 중요하다. 좋은 코드에 충분히 익숙해져 있으면, 오답 코드를 봤을 때 어색함이 느껴진다. 그래서 프로그래머로서 성장하기를 원한다면 참여하고 있는 프로젝트 외에 자신보다 잘하는 사람들이 진행하는 프로젝트의 코드를 꾸준히 보는 것이 가장 중요하다고 생각한다.

 아마 그 어색함이 무엇인지 모르는 사람은 이해하기 어려울 것이다. 사실 나도 그랬다. 한 5년쯤 전이었을 것이다. 같은 회사에서 일했던 뛰어난 프로그래머에게 어떻게 하면 그렇게 할 수 있는지 물어봤던 적이 있다. 그때 그분이 했던 정확한 단어는 기억이 안 나지만 비슷한 느낌의 말을 했었다. 그리고 그때 나의 반응은 정말 '그게 무슨 소리인가요?'였다. 그때 들은 조언이 그냥 코드를 보다 보면 알게 된다는 것이었다. 그리고 지금 생각해보면 그 조언을 더 빨리 따랐으면 좋았을 것으로 생각한다.
 사실 프로그래밍 공부를 할 때, 다른 사람이 짠 코드를 분석하는 것은 가장 재미없는 일이다. 읽을 가치가 있는 좋은 프로젝트는 대부분 많은 코드를 가지고 있고, 읽고 분석하는데 시간이 많이 들기 때문에 귀찮고 하기 싫은 일일 때가 많다. 특히 많은 프로그래머는 다른 사람이 짠 코드를 읽는 것보다 자신의 코드를 작성하고 실제 돌아가는 것을 보는 걸 좋아한다. 하지만 만약 더 이상 실력이 늘지 않는다고 생각한다면, 슬럼프에 빠진 것이 아닌지 걱정된다면, 한 번 유명한 다른 프로젝트를 분석해보는 것을 추천한다. 지금까지 보이지 않았던 다른 것이 보이게 될 것이다.

댓글 없음:

댓글 쓰기