내가 남기고 싶은 개발 기록에 대한 회고

글을 지우는 일을 반복했다

이 글을 처음 쓸 무렵, 블로그에 올려둔 글 세 편을 지웠다. 앞으로 남기고 싶은 글의 방향이 조금씩 선명해지면서 이전 글이 마음에 걸렸기 때문이다. 문제는 이런 선택을 여러 번 반복했다는 점이었다.

2021년 처음 GitHub Pages로 블로그를 운영할 때도 비슷했다. 마음에 드는 템플릿을 찾아 배포한 뒤, 디자인이나 기능이 아쉬우면 다른 템플릿으로 옮겼다. 글을 쓰기 위한 공간을 고치는 데 시간을 쓰면서 정작 기록은 충분히 남기지 못했다.

당시에는 글과 블로그가 만족스러워야 다음 기록을 시작할 수 있다고 생각했다. 돌아보면 완성도를 높이려는 마음이 기록을 이어가는 데 방해가 되기도 했다.

어떤 글을 남기고 싶었나

예전 글을 다시 읽으며 아쉬웠던 점은 두 가지였다. 쉽게 찾을 수 있는 정보를 옮겨 적는 데 그쳐 내 경험이 드러나지 않았거나, 들뜬 감상이 많아 무엇을 전달하려는지 흐려져 있었다.

그래서 앞으로는 직접 부딪힌 문제와 판단을 더 구체적으로 남기고 싶었다. 어떤 상황에서 문제가 생겼는지, 무엇을 시도했는지, 왜 그 방법을 선택했는지, 결과는 어땠는지를 읽는 사람이 따라갈 수 있는 글이다.

공부한 내용을 정리할 때도 같은 기준을 적용할 수 있다. 자료의 설명을 그대로 요약하기보다, 내가 이해하지 못했던 지점과 이를 확인한 과정을 함께 적으면 기록의 목적이 분명해진다.

표현보다 근거에 집중하기

이력서를 작성하면서 “형용사가 들어간 표현을 좋아하지 않는다”는 피드백을 받은 적이 있다. 나를 잘 설명하려고 붙인 표현이 실제 경험을 전달하는 데 얼마나 도움이 되는지 돌아보게 됐다.

이 경험은 기술 글을 쓰는 기준에도 영향을 줬다. 스스로 얼마나 깊게 공부했는지를 강조하기보다, 읽는 사람이 판단할 수 있도록 사례와 근거를 보여주는 편이 낫다고 생각했다.

다만 처음 이 글을 쓸 때 세웠던 “기술 글은 감정이 없어야 한다”는 기준은 지금 돌아보면 지나치게 엄격했다. 궁금했던 이유나 문제를 해결하고 느낀 기쁨도 경험의 일부다. 중요한 것은 확인한 사실, 그 사실에 대한 해석, 개인적인 감상을 구분해 쓰는 것이다.

앞으로의 기록 기준

내가 유지하고 싶은 기준은 다음과 같다.

• 정확하게 적기: 실행 환경과 출처를 남기고, 확인하지 못한 내용은 추측임을 밝힌다. 오류를 발견하면 정정한다.
• 간결하게 적기: 문제와 선택, 결과를 이해하는 데 필요한 내용을 중심으로 쓴다.
• 내 경험을 남기기: 관찰한 것과 판단한 이유를 구체적으로 적고, 감상은 그 경험을 이해하는 데 도움이 되는 만큼 담는다.
• 수정할 수 있는 기록으로 남기기: 지금의 기준에 부족하다는 이유만으로 지우기보다, 시간이 지나 달라진 판단을 덧붙인다.

앞으로도 예전 글이 아쉽게 느껴지는 순간은 있을 것이다. 그때마다 처음부터 다시 시작하기보다, 남겨둔 기록을 고치고 새로운 경험을 이어서 적고 싶다.