개발자의 기록 습관: 작은 메모가 만든 차이

저는 예전에는 개발 중에 떠오른 생각을 머릿속에 잘 보관한다고 믿었습니다. 변수 이름을 왜 그렇게 정했는지, 특정 함수의 순서를 왜 바꿨는지, 오류가 어떤 조건에서 사라졌는지를 나중에도 기억할 수 있다고 생각했지요. 하지만 며칠만 지나면 그 확신은 쉽게 무너졌습니다. 같은 문제를 다시 만났을 때 저는 처음 보는 사람처럼 자료를 뒤졌고, 이미 한 번 시도했던 방법을 또 적용하면서 시간을 보냈습니다. 결국 작은 메모를 남기는 일이 실력을 과시하는 방법이 아니라, 미래의 저를 돕는 가장 현실적인 방법이라는 사실을 인정하게 됐습니다.

기억에 의존하다가 놓친 것들

처음 기록의 필요성을 크게 느낀 때는 화면에 특정 문자가 들어오면 정렬이 달라지는 문제를 며칠 동안 붙잡고 있었을 때였습니다. 저는 여러 부분을 고치면서도 변경 이유를 적지 않았고, 마지막에는 어떤 수정이 효과가 있었는지조차 구분하지 못했습니다. 다음 날 출근해 코드를 다시 보니 제가 만든 코드인데도 낯설게 느껴졌습니다. 결국 변경한 부분을 하나씩 되돌리며 원인을 찾았고, 실제 원인은 복잡한 문제가 아니라 입력값의 공백을 처리하는 순서였습니다. 그날부터 저는 해결 과정에서 버린 가설까지 짧게 남기기 시작했습니다.

제가 시작한 가장 작은 기록

처음부터 멋진 문서나 긴 회고를 쓰려고 하니 며칠 만에 포기하게 됐습니다. 그래서 작업을 시작할 때 오늘 확인할 것 한 줄, 작업 중에 발견한 사실 한 줄, 끝난 뒤 다음에 조심할 점 한 줄만 적었습니다. 예를 들면 “화면 문제로 보였지만 실제로는 입력 변환 단계에서 값이 바뀐다”, “수정 전 결과와 수정 후 결과를 나란히 비교한다”처럼 제 상황을 구체적으로 적었습니다. 이 방식은 글을 잘 쓰는 능력을 요구하지 않았고, 나중의 제가 당시의 판단을 다시 따라갈 수 있을 정도면 충분했습니다. 기록의 문턱을 낮추자 메모는 부담이 아니라 작업의 일부가 됐습니다.
제가 주로 쓰는 형식은 날짜와 상황, 시도한 방법, 확인한 결과, 남은 의문을 네 줄로 나누는 방식입니다. 특히 결과가 좋지 않았을 때 더 꼼꼼히 적었습니다. 한 번은 화면이 계속 멈추는 현상을 해결하려고 호출 순서를 세 번 바꿨지만 어느 것도 문제를 없애지 못했습니다. 당시에는 실패한 시도라서 지우고 싶었지만, “호출 순서 변경만으로는 해결되지 않음”이라고 남겨 두었습니다. 일주일 뒤 비슷한 현상이 발생했을 때 저는 같은 길로 돌아가지 않았고, 입력 크기와 실행 환경을 먼저 확인했습니다. 실패 기록 하나가 불필요한 반나절을 아껴 준 셈입니다.

메모가 협업에서 바꾼 대화

기록은 혼자 있을 때보다 다른 사람과 함께 일할 때 효과가 더 분명했습니다. 이전에는 문제가 생기면 동료에게 “이 부분이 이상하게 동작한다”고만 설명했습니다. 그러면 상대는 제가 무엇을 확인했는지부터 다시 물어야 했고, 대화가 길어졌습니다. 이후에는 재현 조건, 이미 확인한 범위, 아직 확신하지 못하는 부분을 먼저 적어 전달했습니다. 한번은 특정 운영체제에서만 입력이 다르게 처리되는 문제를 제보하면서 샘플 값과 예상 결과를 함께 보냈고, 동료는 바로 비교 지점을 찾았습니다. 제 메모가 완벽하지 않아도 문제의 모양을 함께 바라보게 해 준다는 점을 그때 배웠습니다.

잘못된 기록도 기록이다

물론 모든 메모가 정확했던 것은 아닙니다. 저는 한동안 원인을 찾기 전에 추측부터 길게 적는 습관이 있었습니다. “아마 이 모듈의 처리 속도 때문일 것”이라고 단정한 뒤 그 방향으로만 살펴보다가 시간을 낭비한 적도 있습니다. 나중에는 추측과 사실을 문장 앞에 구분해 표시했습니다. 확인한 내용은 “확인”, 아직 검증하지 않은 생각은 “가설”이라고 적으니 제 판단이 과하게 굳어지는 일이 줄었습니다. 틀린 기록을 남기지 않는 것보다, 틀렸다는 사실과 그 이유를 나중에 고칠 수 있게 남기는 일이 훨씬 유용했습니다.
기록 장소도 몇 번 바뀌었습니다. 처음에는 종이 수첩에만 적었는데 검색이 어렵고, 필요한 순간에 수첩을 찾지 못하는 일이 잦았습니다. 이후에는 작업 단위별로 짧은 문서를 만들고 제목 앞에 날짜와 주제를 붙였습니다. 다만 너무 많은 규칙을 만들자 제목을 정하는 데 시간이 걸렸고 다시 흐트러졌습니다. 지금은 날짜, 문제 이름, 결론 정도만 사용합니다. 중요한 것은 보기 좋은 정리보다 다시 찾을 수 있는 위치와 당시 상황을 떠올릴 수 있는 내용이었습니다.

시간이 지나야 보이는 변화

몇 달 동안 메모를 쌓은 뒤에는 예전과 다른 변화가 생겼습니다. 저는 문제가 생길 때 무작정 코드를 고치기보다 과거 기록에서 비슷한 조건을 먼저 찾게 됐습니다. 같은 실수를 완전히 없애지는 못했지만, 실수가 반복되는 패턴은 눈에 들어왔습니다. 입력값 확인을 뒤로 미루는 경우가 많았고, 작은 변경을 한꺼번에 여러 곳에 적용한 뒤 원인을 좁히지 못하는 경우도 많았습니다. 기록은 제 성격이나 실력을 갑자기 바꾸지 않았지만, 제가 자주 흔들리는 지점을 보여 주는 거울 역할을 했습니다.

작은 메모를 오래 이어 가는 방법

제가 지금도 지키려는 원칙은 하루에 한 페이지를 채우는 것이 아니라, 나중의 제가 다시 읽을 만한 한 문장을 남기는 것입니다. 해결한 문제만 적으면 기록이 자랑처럼 변하기 쉬워서, 판단이 바뀐 순간과 놓쳤던 조건도 함께 적습니다. 바쁜 날에는 키워드만 남기고 다음 날 문장을 보완하며, 아무 일도 없었던 것처럼 느껴지는 날에도 새롭게 확인한 사실 하나를 기록합니다. 독자 여러분도 거창한 계획보다 오늘의 작업에서 “무엇을 알게 되었는가”를 한 줄 남겨 보셨으면 합니다. 작은 메모는 당장 눈에 띄지 않지만, 어느 날 분명히 과거의 나와 현재의 나를 연결해 주는 실용적인 이정표가 됩니다.