24년, 2월 회고
만드는 사람이 수고로우면 쓰는 사람이 편하다
만드는 사람이 수고로우면 쓰는 사람이 편하고, 만드는 사람이 편하면 쓰는 사람이 수고롭다.
예전에 어디서 보고 많은 생각을 했던 문장인데, 이번에 찾아보니 우형의 문장이었다. 역시 우형은 배울 점이 정말 많다. 아무튼 이번 달은 위 문장과 주저 앉고 싶을 때 딱 한걸음만 더 라는 문장을 정말 많이 떠올렸던 그런 달.
추가로 저번 1월에 여유롭게 지낸 덕분에 이번 달은 몸과 정신 모두 빡세게 고생을 했다. 특히 마지막까지 윤년과 연휴가 세트로 있어 일정도 조금씩 꼬임.
업무
- 암센터
작년 1차 프로젝트를 이어서 진행하는 2차 프로젝트. 작업 내용은 크게 보면 기능 추가이지만 작년과 다르게 새로 만드는 것이 아닌, 기능을 만들고 기존 내용과 충돌이 나지 않으면서 잘 어우러지게 고민하는 것이 중요한 프로젝트. 있어보이는 말로 리팩토링과 아키텍쳐 고민을 많이 해야한다. 물론 섣부른 최적화는 안하는 것만 못하다.
추가로 시각화를 추가하는 과정에서 늘 쓰던 ggplot이 아닌 수상할 정도로 중문 레퍼런스가 많은(?) echarts라는 시각화 라이브러리를 사용했다. (알고보니 Baidu에서 시작해서 Apache로 넘어간 프로젝트였다.)
써보니 당연히 ggplot과는 조금 로직이 다르지만, 전반적인 디자인이 깔끔하고 (아마 기본 ggplot의 theme_gray가 치명적인 탓) 특히나 Interactive visualize로는 ggplot에 plotly를 붙여 쓰는 것보다 더 좋다고 생각한다.
- 면접
우리 회사는 연세대학교 학생 인턴십을 정기로 진행하고, 수시로는 메디컬 (의치한약) 학생들이 어떻게 알고 와서 인턴십을 하는데 연세대학교의 경우 지원자가 꽤 많아서 면접에 참여한다. 그런데 이번에는 ICT 인턴십이라는 것을 진행하게 되었고, (행정적인 내용이라 잘 모르겠음) 마찬가지로 지원자가 많아서 보게 됨.
면접을 보면 볼 수록 스스로의 면접에 대한 관점이 뚜렷해지는 것 같다. 내 경우, 즐기는 자는 노력하는 이길 수 없다. 라는 관점에서 누가 더 이 일을 더 즐겁게 할까를 보려고 하는 편.
업무?
- 책 쓰기
아무튼 엄청 더울때 카페에서 미팅했던 건 기억나는데 작년 8월인가 쓰기 시작한 책의 원고를 드디어 무사히 탈고 했다.
저번과 동일한 생각이지만 나는 떡볶이 어쩌구 책을 쓰는 재능은 없다보니 책을 통해 부를 기대하지는 않고, 다만 내가 했던 노가다들을 정교하게 다듬어서 나중의 내가 쓰는 것이 1목적, 그 다음 다른 사람들도 쓰는 것이 2목적이다.
다행히 주제는 내가 대학원생. 뻥을 좀 보태면 학부생 말년부터 했던 것이다보니 기술적으로, 내용적으로 글을 작성하는 것은 어렵지 않았다. 대신 많이 들었던 생각은 이러했다.
이 내용까지 쓰면 너무 과한 것이 아닐까? (R을 이렇게 까지 쓸 사람이 있을까)
이 정도만 쓰면 이후에 편집자님이 잘 다듬어주겠지? (내용 작성보다는 퇴고할 때마다 고칠 점이 보였는데도 꽤 귀찮았다)
쓰면 쓸 수록 나의 모자람이 드러나는 것 같다. (이렇게 밖에 설명을 못한다고?)
무엇보다 써야하는데 써야하는데…
를 반복하면서 자꾸 원고 작성을 미루고 미루다보니 나중에 마감기한이 다가올때 예전에 학위 논문 쓰던 시절처럼 하루에 12시간씩 워드만 붙잡고 있었다.
나중에 책을 기회가 다시 올 것 같진 않지만, 누군가 책을 쓰게 된다면 아래 내용을 권장한다.
마감 기한을 더 빠듯하게 잡자
내 경우 총 기간이 대충 8월부터 2월까지 반년이었지만 “실제” 글 작성 기간은 한 2개월? 정도 일 듯하다. Deadline-Driven-Development를 신봉하는 사람으로써 더 짧았다면 진작 실물 책이 나오지 않았을까. 물론 본업의 일정과 충돌하면 곤란하기 때문에 4개월 정도로 줄여볼 수 있지 않을까 생각
책에서 사용하는 이미지나 코드 등 파일은 그때 그때 잘 정리해두자
진짜다, 파일 이름을 하나씩 바꾸면서 정리를 열심히 할 껄 하고 후회했다.
출판 형식에 맞춰 글을 쓰자
특히 나처럼 이렇게 근본 없이 글 쓰는 사람들은 문체와 비문이 남발하는데, 온라인 아티클도 마찬가지지만 실물책, 특히 기술서에서는 매우 아쉬운 단점이 된다. 물론 편집자님께서 규칙 가이드라인을 주시지만 글을 일단 쓰고 이 가이드라인에 맞춰 다듬는 것과, 처음부터 이 가이드라인에 맞춰 글을 쓰는 것은 어마어마한 차이가 있다. 이 부분은 AI 툴을 누가 만들어 주면 좋겠다는 생각이 들었다.
평소에 공부를 하자
상황에 따라 다를 수도 있지만 기술서는 워드 기준 300페이지 이상이 필요하다. 아무리 공간을 많이 먹는 “이미지”가 있다고 해도 나무에 미안하지 않으면서 이만큼의 분량을 뽑아내려면 기존에 알던 것만으로 쓰기 보단 나도 새롭게 공부를 하면서 써야하는 내용들이 같이 있어야 한다.
그리고 적어도 기술서는 학위 논문이 아닌 이상, (심지어 학위 논문이라도) 책에 쓰이는 대부분의 내용들이 이미 다른 누군가의 경험과 생각을 기반으로 만들어졌음에도 비용 없이 온라인에 공개 된 내용들이 많기 때문에 지식 공유에 늘 감사하며 살자.
퇴고는 많이 해서 나쁠 것이 없다
다른 출판 관련 서적에서도 많이 언급되는 내용인데, 보통 원고를 한큐에 쭉 이어서 쓰는 경우보단 한 챕터 쓰고, 며칠 쉬다가 한챕터 쓰고 또 며칠 쉬다가… 를 반복하게 된다. 즉, 동일한 저자가 쓰는 원고이지만 그때 그때 맥락이 달라서 문체나 표기 방법 그리고 글의 패턴 등이 달라질 수 밖에 없다. (내 개인의 문제 일 수 도 있다)
그렇기 때문에 원고를 다 쓰고 나서도 처음부터 끝까지 쭉 읽어가며 더 좋은 글을 쓰기 위해 (정말 힘들지만) 고치고 추가하는 퇴고 과정이 필요하다. 나는 게을러서 6번밖에 못했는데, 그럼에도 불구하고 할때마다 오타나 아 이 부분은 이렇게 설명하면 좋았겠다, 이건 이 맥락을 같이 설명해야겠다. 이것도 추가해야겠다. 와 같은 내용들이 꾸준히 튀어나와서 꽤 부끄러웠다.
책은 큰 문제가 없다면 5–6월에 나올 듯. 나중에 나오면 얘기하겠슴
deep daiv
무언가를 내가 직접한 것은 아니지만, 작년 데이터야놀자에서의 일부 발표 내용들을 잘 다듬은 전자책이 텀블벅에 나왔다. 나에게 어떤 이득이 오는 건 아니지만, 내가 발표 했던 내용도 들어가 있어서 짧게 소개.
추가로, 이때 소개했던 webR은 이제 shinylive라는 훨씬 쉬운 방법으로 가능하다. 요건 별도의 짧은 아티클로 쓸 듯 ㅋㅋ
기타
작년의 고민은 어떻게 해야 일을 안하고도 놀면서 먹고 살 수 있을까 였다.
이에 대한 내 답은 “그레이존”의 일을 해서 적게 하고 많이 벌거나, 아니면 일을 내가 하는 것이 아닌 “시스템 혹은 다른 사람”이 하게 하는 것.
이 중 두번째 관점은 결국 대체 가능한 일을 하는 사람이 되어야 된다. 라고 생각한다. 약간 오해의 소지가 있을 수 있는데, 내가 부품으로써 대체 된다 라기보단 내가 하는 일을 대체 할 수 있게 만드는 것, 일종의 자동화 프로세스/매뉴얼화가 주된 목적이 되어야 한다.
그런데 이는 역설적으로 하는 업무의 본질을 이해해야한다. 가령 어떤 흐름으로 어떤 문제를 해결하고, 어떤 부분을 (내가 놀 동안 대신 해줄 다른 것으로) 대체할 수 있고, 이를 위해 어떤 노하우가 필요한 지 등을 경험을 통해 알고 있어야 한다.
심지어 노력을 통해 내가 하던 일을 “다른 사람/시스템도” 할 수 있게 만들고 나면 원하던 대로 내가 굳이 하지 않아도 일은 되지만 동시에 스스로의 필요에 대해 고민이 들기도 한다. 특히나 최근에는 LLM 과 genAI로 인해 나 외에도 많은 사람들이 이러한 고민을 할 수 있다.
그럼에도 일을 대체할 수 있게 만드는 것이 좋다고 생각하는 이유는 세 가지인데,
- 다른 사람도 할 수 있는 것과 다른 사람이 나보다 더 잘하는 것은 다른 문제.
- 하나의 일을 풀어내는 사람은 다른 일도 풀어낼 수 있다.
- 지금 우리가 하고 있는 수많은 것들도 결국 누군가가 풀어낸 일이다. 다시 말해, 어차피 누군가가 대체할 수 있게 풀어낼 것이라면 내가 하는 것이 더 좋지 않나 라는 생각.
물론 반박시 그 말이 맞다 !
올해의 고민은 정하는 중.
