좋은 코드

기준과 현실

좋은 코드에 대한 다양한 기준이 있지만, 나는 좋은 코드를 논할 때 가장 기본이 되어야 하는 것은 문제 해결의 여부라고 생각한다. 문제를 정의한 다음 해결을 위한 방법을 논한 프로그램의 구조와 구현에 대해서 논해야 한다. 그렇지 않으면 단순한 코드의 미에 대한 평가 그 이상은 힘들다.

문제를 해결 못하는 코드가 나오는 대표적인 이유 중 하나는, 문제 정의가 부실하기 때문이다. 책이나 과제와 달리, 현실에서는 문제 정의가 없거나, 부분만 되어 있거나, 문제가 변하는 속도를 고려하지 않거나, 협업자들이 같은 정의를 공유하지 못하는 일 들이 생긴다.¹ 구조를 만들고 코드를 짜기 전에 문제와 주어진 조건은 어떤 것인지 충분히 질문하고 목표를 고정해야 하지만, 욕심이 앞서 있거나, 질문에 실패했거나, 경험이 부족하거나, 현재가 불안한 이들은 문제 해결을 위한 목표 대신 자신을 위한 목표나 자신이 할 수 있는 것을 담는다. 조건보다 과한 오버 테크놀로지, 지적 과시를 위해 과하게 축약된 코드, 확장성이 보장되지 않아 수정을 위해서 처음부터 다시 작성해야 하는 1회성 코드, 필요한 성능이 안 나오는 설계는 이렇게 나온다.

또 다른 이유는 지루함과의 싸움에 잘못된 접근이다. 문제 해결 과정의 대부분은 지루하고, 지루함은 눈치채지 못하는 사이 쌓여 커뮤니케이션의 부족과 번아웃으로 이어진다. 그러니 지루함과의 싸움은 중요하다. 다만, 지루함과의 싸움이 문제 해결보다 앞서면 문제가 된다. 개발자들이 지루할 때 하는 가장 대표적인 행동은 혁신이나 고성능 같은 다양한 말을 동반해서 기술이나 방법론을 도입하는 것이다.² 문제 해결을 위해 충분히 검토된 다음 적용되는 적합한 기술과 방법론이면 문제없지만, 단순히 지루하기 때문에 도입되는 경우 그리고 그 기술이나 방법론이 충분히 성숙하지 못한 경우 운에 기대게 된다. 새로움은 지루함을 날려주지만, 미성숙한 부분은 모두의 발목을 잡는다. 예상되지 않은 리소스를 필요로 하는 정도면 다행이고, 근본적으로 문제를 해결하는데 필요한 기능을 제공하지 않아 처음부터 재작업해야 하는 경우도 생긴다. 이렇게 되면 매일 같은 수준에 머물며 모두가 하루하루 더 지루해지고, 문제 해결도 멀어진다. 어떤 이들은 미성숙함에도 불구하고 미래에 대비하기 위한 필수적인 요소라고 말한다. 그러나 현재의 문제를 해결 못하면 어차피 미래는 없다. 미래는 그렇게 함부로 파는 것이 아니다. 미성숙한 기술/방법론의 도입에는 충분한 대비가 필요하고, 오지 않은 미래를 위해 현재를 희생할 때는 철저한 제한이 필요하다. 사실 그런 이들이 말하는 미래는 자기 자신의 경력과 미래이다.

목적을 만족하지만 나쁜 코드는 읽고 고치면 그만이다.³ 하지만, 목표에 다다르지 못한 코드는 지적 유희에 지나지 않는다. 유희성이 기준인 분야⁴도 있으나, 그것은 순전한 취미나 예술의 영역이고, 전문적인 영역의 코드의 평가에서 유희성은 배제되어야 한다.

내 인생의 코드

내가 지금까지 작성한 코드 중에 어떤 것이 가장 만족스러웠냐고 물으면, 나는 주저 없이 약 15년 전에 작성했던 프로그램을 말할 것이다. 사실, 프로그램이라고 부르기에는 그냥 스크립트 묶음에 가깝고, VBA를 배워가며 만든 코드라 지금 다시 보면서 고치라고 하면 도망가겠지만, 고칠 일이 없는 일이라서 더 그렇다.

당시 나는 작은 공장에서 일하고 있었는데, 주어진 업무는 대충 주문관리, 자재관리, 품질관리, 출하에 해당하는 업무들이었다. 출근을 하면 주문을 정리하고, 생산에 필요한 자재들을 챙겨서 각 파트에 나눠 준 다음, 출하에 필요한 라벨과 출력물 및 품질 리포트를 작성하고, 생산이 끝나면 주문에 맞춰 제품을 포장해서 출하하면 하루 일이 끝났다.

업무시간의 대부분은 제품에 필요한 출력물을 만드는 것이었다. 주문 들어온 제품과 발주처에 따라서 필요한 것이 달랐기 때문에, MS office 삼 형제⁵를 이용해 주문에 맞춰 라벨, 속지, 품질 리포트를 작성하고 출력해야 했다. 이 작업은 시간도 많이 들고 실수를 하기도 쉬웠다. 그리고 가장 큰 문제는 단순 반복이라 지독하게 재미가 없었다는 것이다.

그래서, 주문만 정리해서 입력하면 각 제품별로 일렬 번호를 발급하고 데이터를 만들고 필요한 라벨, 속지, 리포트까지 출력물까지 모두 자동으로 만들도록 코드를 작성했다. 엑셀에 주문을 정리해서 입력하면 각종 숫자들을 계산하고 보여진 다음 나머지는 자동으로 진행된다. 계산된 라벨지 수에 맞게 프린터에 종이를 넣고, 계산된 수 많큼 부품을 챙기면 되었다. 일종의 미니 ERP였다.⁶

이 프로그램을 지금까지 최고로 뽑는 건 주어진 환경에 맞추어 문제를 해결했기 때문이다. 우선, 기존에 있던 하드웨어와 소프트웨어를 활용해서 제작했기 때문에, 시스템에 추가로 들어간 비용이 없었다. 프로그램 도입 전에 6시간씩 걸렸던 일은 10분 수준으로 줄었고.⁷ 실질 근무시간은 8시간에서 1~2시간으로 줄었다. 자재부족이나 오타 같은 자잘한 실수가 사라져서 재작업을 하느니라 낭비했던 시간도 사라졌다. 계산이 정확해지니 재고 파악도 전반적으로 쉬워져서, 재고 관리나 부품 발주도 더 정확해졌다. 대부분을 대화와 기억으로 처리해왔기 때문에 필요했던 커뮤니케이션 시간도 줄어들고 전반적 생긴 여유 때문에 커뮤니케이션이 부드러워진 건 덤이다.

또 최고로 뽑는 두 번째 이유는 그 결과가 내 인생에 영향을 주었기 때문이다. 그렇게 번 시간의 일부는 위에서 언급한 대로 기존의 업무를 편하게 하는 데 사용했지만, 남는 시간은 창고에 앉아, 이런저런 코드를 짜고 이직 준비를 하는 데 사용했었다. 그중 하나는 모 블로그 서비스를 백업하는 오픈소스 프로젝트였는데, 덕분에 또 오픈소스 프로젝트 참여로 이어졌고, 이직도 하고, 많은 사람들을 만나고, 많은 것들을 경험할 수 있었다. 그 시간을 벌지 못했다면, 내 인생은 좀 다르게 흘러갔을 터이다.

세 번째는 고객이 만족했다. 회사 말고 나. 회사는 무엇을 하는지 감도 못 잡았다. :)

마무리

이야기를 다 적고 나니 아주 예전에 들었던 이야기가 생각났다. 어느 조직에서 코드 개선 작업에 들어갔는데, 코드 작성자는 모두 떠났고 요구사항이 사람마다 날짜마다 다른 수준으로 중구난방이라 개발이 힘든 상황이었다고 한다. 우선, VCS를 도입하고 코드를 여러 브랜치로 쪼갠 뒤 결과를 요구사항에 맞춰서 각각 보여주는 것으로 별이 하나인 사람도 둘인 사람도 셋인 사람도 만족하는 코드를 작성했다는 이야기.⁸ 그 이야기를 들었을때 사람들이 얼마나 감동했는지, 모두가 일어나 기립박수를 쳤었다. 좀 특이한 경우지만, 문제 정의와 해결이 잘 된 경우라고 하겠다.⁹

모든 좋은 선택이 그렇지만, 좋은 코드는 인생에 영향을 준다. 코드를 통한 문제 해결을 경험하고 그 과실을 얻어 본 이들은 문제에 집중하고 문제를 해결하고 그다음 미학을 추구한다. 다시 말하면 “Done is better than perfect”라고 하겠다.¹⁰