by
Jul 21. 2018
개발자는 정리를 잘해야 한다
생각보다 개발자의 기억력은 믿을게 못된다
소프트웨어 회사가 자연과학 연구실도 아닌데 예상외로 실험과 관찰을 할 일이 많다. 내가 속한 시스템 소프트웨어는 다른 무엇보다 성능을 가장 중요한 요구사항으로 본다. 그런데 성능은 언제나 어림짐작 한 수치에서 크게 벗어나는 일이 대부분이다. 그래서 프로젝트를 시작할 때마다 성능을 만족할 수 있을 '것' 같은 몇 가지 후보 구조를 도출하고 빠르게 만들어서 오드로이드, 라즈베리 같은 레퍼런스 보드 위에서 테스트하는 일이 실제 개발과정보다 우선시된다. 측정 결과는 테스트할 때마다 결과가 다를 수도 있기 때문에 3~4회 정도 반복해서 측정해야 하고 측정에 영향을 줄 수 있는 CPU, 메모리 같은 하드웨어 스펙도 알아둬야 한다. 조건에 맞춰 측정한 결과에 따라 요구사항을 만족한 후보 구조를 추려내고 개별로 보안 위험성은 없는지 다른 하드웨어에도 적용될 수 있는지 등등을 검토하는 과정으로 이어진다.
성능 측정이라고 거창하게 말했지만 사실 그리 대단한 일은 아니다. 많은 사람들이 위와 비슷한 작업을 할 것이다. 체육선생님이 교장선생님으로부터 육상 유망주를 발굴하는 임무를 받았다고 생각해보자. 아마 선생님은 얼굴만 보고 주력을 판단할 수 없기 때문에 체력 검정 시간에 전교생의 50m 달리기 시간을 측정한 후 가능성이 보이는 학생들을 먼저 추려낼 것이다. 일회 기록만으로는 주력을 판단할 수 없기 때문에 추려낸 학생들은 3~4회 정도 재측정을 한다. 선생님의 수첩에 꾸준한 기록을 보여주는 학생들이 기록이 뒤죽박죽인 학생들보다는 더 선수가 될 가능성이 높을 것이다. 주력이 좋고 기복 없는 학생들의 부모님께 선생님은 전화를 걸게 될 것이다.
성능을 측정하는 일은 체육 선생님이 육상 유망주를 발굴하는 길과 비슷하다. 그런데 예상외로 실험 결과를 꼼꼼히 정리하지 않아 삽질하는 일이 빈번하다. 너무 단순한 실험이라 얕본 탓이었을까? 아니면 너무 측정할 일이 잦아서 그런 걸까? 미리미리 엑셀에라도 정리했으면 됐을 것을 귀찮다고 자신의 기억력만 믿고 가다 하루를 날리는 일이 꽤 많다. 눈에 보이는 일반 실험과는 달리 컴퓨터는 추상화된 프로그래밍 언어와 바이너리로 이뤄져 있어 머릿속에 잘 남지 않는다. 실험 초반에야 기억력으로 모두 커버할 수 있지만 실험이 4~5회가 넘어가면 '과거에 내가 이렇게 시도했던가?'하며 헷갈리게 되고 결국 자신의 기억을 되살리기 위해 똑같은 실험을 반복하거나 아니면 잘못된 실험 결과를 동료들에게 공유해 팀 전체를 삽질하게 한다. 미리 꼼꼼히 정리해뒀다면 하지 않았을 실수들이다.
생각보다 개발자의 기억력은 믿을 것이 못된다.
성능 측정뿐만 아니라 코드를 분석할 때도 마찬가지다. 생각보다 개발자의 기억력은 믿을 것이 못된다. 야근하며 분석한 코드도 한 달이 지나면 처음 본 코드가 되는 것이 현실이다. 머릿속에 오래 남기고 싶다면 조금 시간이 걸릴지라도 분석한 내용을 적어도 나는 알아볼 수 있을 정도로 문서에 간단히 정리하는 작업이 필요하다. 나는 아래 그림처럼 메모장에다가 분석한 코드를 의사 코드로(pseudo code) 옮기면서 정리한다. 다른 사람들이 보기에는 시간이 좀 걸리겠지만 나는 매번 작성하는 포맷이기 때문에 쉽게 알아볼 수 있고 단순히 메모장에 작성하는 일이라서 시간도 절약할 수 있다. 물론 이렇게 작성한다고 까먹지 않는 것은 아니지만 기록하는 과정 덕분에 머릿속에서 잊히기까지 시간이 길어지고 잊히더라도 작성한 문서 덕분에 쉽게 회복할 수 있다.
분석한 커널 코드를 우분투에서 제공하는 gedit을 이용해서 간단히 정리했다