[Talk] 개발 일지 작성하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

그냥 기록이라도 해도 좋고 개발 일지나 업무 일지라고 불러도 상관없다. 다른 분야에서도 마찬가지라고 보지만 내가 개발자니까 개발자 입장에서만 봤을 때 자신이 하는 일에 대한 기록을 남기는 것은 큰 도움이 된다고 생각한다.

왜 기록하는가?

이건 취향일 수도 있지만 나는 기록을 남기는 걸 좋아하는 편이다. 이 블로그도 기록을 남기는 것의 일환인데 주로 기술에 대한 이슈만 얘기하다 보니 몇 년 전부터는 생각에 대한 기록을 남기고 싶어졌다. 내가 어떤 사건 혹은 기술을 보는 그 당시의 느낌이나 생각을 스냅 샷으로 만들 수 있다면 참 좋겠다는 생각을 많이 한다. 생각이란 건 다 내 머릿속에 있는 거지만 지나서 보면 아주 단편적인 부분밖에 기억나지 않고 시간이 지난 입장에서는 결과를 알기 때문에 결과를 몰랐을 때 어떤 생각/느낌이었는지 알기가 어렵다. 그래서 생각을 글로 남기는 시도를 여러 번 했지만, 머릿속에 복잡하게 엉켜있는 생각을 글로 풀어쓰다 보면 글의 목적을 알 수 없게 되어서 매번 쓰다가 그만두곤 했다.

예를 들어 2년 전에 Angular.js를 어떤 시각으로 보고 있었는데 Docker를 처음 보았을 때 난 어떻게 생각했는지 하는 건 아주 단편적으로만 기억나고 그 당시의 정확한 느낌은 알지 못한다.(지금은 이미 좋은 인상을 받고 있으므로...) 어떤 이슈를 처리하거나 뭔가 구현하면서 꽤 고생하고 고민을 했더라도 시간이 약간만 지나도 정확히 뭐가 어려웠고 왜 고민했는지 기억이 가물가물하다.(나만 그런가?) 대표적으로 지금은 JavaScript를 어느 정도 다루지만 처음 JavaScript를 배울 때 어디부터 공부했고 뭐가 어려웠는지는 거의 기억나지 않는다. 그래서 누가 "어떻게 공부하나요?"라고 물으면 "그냥 책보고.. 코드 짜보면서.."라는 대답밖에는 하기가 어렵다.

Don't learn to code. Learn to think라는 글의 논지를 좋아하는 편인데 이 글에 나온 대로 프로그래밍은 주로 코드를 짜는 일이지만 좀 더 크게는 문제를 해결하는 일이고 이를 위해서는 생각하는 방법에 대한 것으로 생각하는 편이다. 생각하는 방법도 배우고 발전시킬 수 있으므로 나는 다른 사람이 어떻게 생각하는지 보는 걸 좋아하고 내가 예전엔 어떻게 생각했는지 엿볼 수 있다면 많은 도움이 된다고 생각하고 있다. 그리고 기록이란 건 신기하게도 나중에 찾아보지 않더라도 기록을 한다는 행위만으로도 머릿속에 각인 효과가 생각보다 크다.


Image by jeffrey james pacres via Flickr

무엇을 기록하는가?

무엇을 적을지에 대한 정답은 없을 것이다. 언젠가 개발 관련 교육을 받다가 benelog님이 클린코드 관련해서 아주 오래전에 내가 메일링에서 답변한 내용을 예시로 보여준 적이 있다. 당시 갑자기 내 얘기가 나온 것에 당황하긴 했지만 몇 년 전의 내용을 기록으로 남겨놓은 것을 보고 "저런 내용도 기록해 놓으면 좋겠구나!"싶어서 인상적이었다.
최근에는 다음과 같은 내용을 적는다.

• 오늘 새로 배운 내용: 아주 간단한 함수 사용법부터 라이브러리까지 기록한다. 새로 배웠다고 해서 거창하게 아니라 새로 알게 된 도구나 처음 알게 된 함수의 사용방법 등을 적는다. 공개적인 글이 아니므로 내가 나중에 이해할 수 있을 정도면 (가능하면 코드와 함께) 적는다. 그냥 뭔가 몰랐다가 알게 된 건 다 적으려고 한다.
• 고민한 내용: 개발하다 보니 고민하는 일이 많다. 오늘 A를 구현하는데 막혔던 부분, B의 방법으로 해결하기는 했는데 찝찝했던 부분이나 예상되는 문제들. 내가 그렇게 구현하기로 한 이유 등을 적는다. 현재 해결책이 있든 없든 상관없이 지금 보는 시각을 그대로 적는다.
• 참고할 만한 내용: 주로 개발 관련을 적기는 하지만 인터넷을 발견하거나 다른 사람과 얘기하다가 나중에 참고할만하다 싶으면 적어놓는다. 좋은 글귀나 나중에 발표에 써먹을 수 있을 것 같은 코딩 개그, Stackoverflow에서 본 괜찮은 질문이나 답변을 소감과 함께 적는다.(단순 링크는 북마킹 도구가 훨씬 편하므로 그런 내용은 적지 않는다.)
• 회고: 프로젝트를 수행하거나 어떤 단위의 일을 했을 때 회고를 적는다. 퍼블릭한 글이 아니니까 생각나는 소감을 모두 적을 수 있다. 세미나 같은 걸 참여했을 때 내용 정리와 소감도 적어놓는다.(전에는 이렇게 적은 내용을 바탕으로 후기를 적었지만 언젠가부터는 블로그에 세미나 후기는 많이 올리지 않는 편이다.)
• 개발일지: 이건 지금 사내 스타트업을 하면서 시작한 거지만(그전에는 간단한 업무로그 정도만 적었다) 현재 하는 경험이 아주 소중한 경험이라고 생각하기 때문에(개발 외에 하게 되는 것도 많고...) 매일 앞에 적은 카테고리처럼 배운 거, 고민한 내용, 생각과 처리한 일등을 적고 있다.
• 윗사람에 대한 생각: 이건 신입 때부터 적었으면 정말 좋았을 텐데 하는 부분 중 하나인데 조직 내에서 생활을 하면서 윗사람에 대한 생각을 적는다. 내가 싫은 부분, 좋은 부분, 윗사람이 했으면 하는 일, 하지 않았으면 하는 일등을 생각날 때마다 적고 이 부분의 특성상 느껴지는 감정을 적나라하게 적으려고 하는 편이다.(프로젝트나 회사 상황 같은 건 뒤에 가면 기억이 나지 않을 테니 관련한 부분도 함께 적고 있다.) 얼마나 도움이 될지는 모르지만 언젠가 시간이 지나 지금보다 높은 위치에 가게 되면 예전의 입장을 잊지 않는 데 도움이 되지 않을까 한다.
• 프로젝트 아이디어: 간간이 불편하거나 이런 게 있었으면 좋겠는데 하는 걸 간단히 적고 있다. 나중에 프로젝트를 하거나 아이디어가 필요할 때 참고해 볼 만하지 않을까 해서... 꼭 서비스용 아이디어만 적는 게 아니라 생각나는 건 모두 휘갈겨 적고 있다.
  

어디에 적는가?

사실 어디에 적는지는 크게 상관이 없다. 편하게 자주 적을 수 있고 나중에 찾아볼 수만 있으면 된다. 처음에는 자주 사용하는 에디터를 이용해서 마크다운으로 작성을 하다가 중간에 evernote의 인기가 매우 좋아서 한번 써볼까 해서 evernote로 갈아탔다. evernote를 잘 써보려고 했는데 내 취향에는 좀 맞지 않았고 특히 난 대부분 마크다운으로 작성하는데 evernote는 마크다운이 되지 않는 부분이 제일 불편했다. 그러다가 일기 애플리케이션인 DayOne으로 갈아탔다. DayOne은 Mac과 iOS만 지원하지만 나는 이 환경이 주 환경이므로 크게 문제가 될 건 없었고 인터페이스도 깔끔하고 마크다운 지원이 훌륭해서 사용하고 있다. 현재도 DayOne을 쓰는데 검색도 잘되고 태그기능도 있어서 아주 만족스럽게 쓰고 있다.(유일한 불만은 글이 많아지니 Mac 앱에서 랙이 자주 걸리는 부분뿐이다.)

My Comment..
해당 글을 보니 나도 해당 블로그를 사용하는 패턴을 생각해보게 된다.. 햄의 글이 괜찮거나 나에게 도움이 되는 글을 갖고 오기도 하지만 내 취미를 올릴 때도 있고, 심리적인 변화라던지 기타 내용들에 대해서 올릴 때도 있다.. 조금 더 전문성을 갖으면 좋겠지만 글쎄.. 그건 좀 희망사항 같은..?? 부분이고.. 나의 목표라면 꾸준하게 해보고 싶다.. 무엇이됬건 하다가 중간에 멈추지 말고 꾸준하게.. 그리고 위 글처럼 기록도 어떤 기록이라도 좋으니 중간 중간 좀 해보자.. ㅎㅎㅎ..