2024 Q3 Review

이번 분기도 그렇게 생산적인 분기였는지는 모르겠다. 갓생도 아닌 것 같지만 아직까지는 갓생 호소인인데, 갓생을 살아야겠다는 강박을 내려놔야 하지 않나 싶은 생각은 든다. 이젠 그냥 받아들이면서 어떻게든 흘러가는 시스템을 구축하고 그대로 시스템에 몸을 맡기는 식으로 살아가고 있다.

시스템을 만들어놓으니 확실히 분기별 회고는 어떻게든 써지긴 한다.

Timeline

  • 2024-07-27 : PyWeb Seminar에서 django-importmap이라는 라이브러리를 사용한 후기를 발표했다.
    • django-importmap 자체는 rails/importmap에서 영감을 받아서 나온 라이브러리이다.
    • 어쩌다 이런걸 다루게 되었는지에 대해서 설명하자면, 블로그 글을 하나 더 써야할 정도의 분량이다.
      • 대충 요약하자면, javascript 툴체인 자체를 굉장히 혐오하는 Rails 진영에서 자바스크립트 번들러에 대한 의존을 줄이고, 자바스크립트 의존성을 추가하거든 차라리 importmap을 쓰자는 취지에서 나온 물건이다.
      • Rails 진영에는 이미 importmap을 쓰는 것이 사실상 표준이지만, django 진영에는 그렇게 잘 알려져있는 것 같지 않다. 그래서 django-importmap에도 다들 관심이 있지는 않은 것 같아서, 이런 관점이 있다 정도만 소개하고 싶었다.
      • importmap을 사용하는 예시로 Vue.js를 사용하는 예제와 같이 설명했었는데, importmap을 사용해서 그나마 무난하게 개발할 수 있는게 Vue.js 밖에 없기도 했다. Single File Component를 사용하는 방식에선 당연히 importmap과 같이 사용하는 것이 사실상 불가능하다. Options API를 사용하는 방식이면 얘기가 달라진다. Options API를 사용하는 방식은 컴포넌트를 나타내는 JS Object를 나열하고, HTML 마크업을 짜놓고 최종적으로 원하는 위치에 Vue.js 인스턴스를 초기화하면 된다. 이런 방식은 GitLab에서도 비슷하게 사용되는 것12 을 확인한 바가 있다.
      • 개발경험이 견딜만은 하지만 다른 사람들한테 권장하긴 어렵다. 근데… Rails 진영에는 Hotwire라는 심연이 있고, 거기에는 도무지 적응하기 어려워서 어쩔 수 없이 선택한 길이고 지금도 쓰고 있는 방식이다. 자바스크립트 툴체인을 따로 구축하지도 않고 UI를 구성하는 개발을 하는데 있어서는 Vue.js 만한 물건은 없었다.
    • 발표자료는 여기에서 볼 수 있다.
  • 2024-08-05 : vim.kr 디스코드 500명 돌파
    • 내가 만든 커뮤니티가 이렇게 크는게 참 신기하기도 해서 개인적으론 기념하고 싶은 날이다.
  • 2024-08-31 : 한국 연합우주 개발자 모임 첫 스프린트 주관
    • 모임 자체는 이전에 언급했었던 Sprint Seoul의 스프린트 모임 포맷을 벤치마킹해서 진행했다. 각자 모여서 기여하고 싶은 프로젝트들을 들고 와서 각자 모여서 기여하는 모임이다. (용어 자체가 낯설다면, 주제가 정해진 모각코 같은 느낌인데 필요하다면 옆에서 멘토가 붙어서 온보딩을 도와주는 느낌으로 이해하면 될 것 같다)
    • 차세대 음성 AI를 개발하는 리턴제로 쪽 관계자분과 어떻게 연이 닿아서 fedidev.kr 첫 모임이자 첫 스프린트 모임을 쾌적한 사무실에서 진행할 수 있었고, 스프린트 모임의 별미인 피자파티도 할 수 있었다. 제법 괜찮은 경험이었다.
    • 연합우주 자체는 굉장히 많은 가능성을 가지고 있다고 생각하는 편이고, 이와 관련해서 여러 차례 트윗으로 올린 바가 있다. 언젠가는 한번 또 장문의 글을 쓰게 될 것 같다. 연합우주 개발자 모임을 좀 더 잦은 빈도로 열고 싶은데, 어떻게 하면 공감대를 얻고 어떻게 하면 후원을 받을 수 있을지가 고민이다.
    • 모임 기록은 여기에서 볼 수 있다.
  • 2024-09-07 : 튜링의 사과에서 진행하는 미니 컨퍼런스에서 토이프로젝트를 개발한 경험을 각자 설명하는 네트워킹 세션의 진행자를 맡았다.
  • 2024-09-21 : NeovimConf.live에 발표자료 제출했다.
    • 작년에는 루비카이기에서 참여하면서 영어 발음이나 듣기가 잘 안되서 얼탔던 기억이 아직도 선명한데, 이번엔 (스트리밍으로 진행하는 비대면 행사이지만) 해외컨퍼런스에 발표라도 해보겠다라는 마음가짐으로 발표자료를 제출했다. 올해에는 꼭 발표하겠다고 다짐했는데, 실천을 해냈다는 것에는 큰 의미를 두고 싶다.
    • 플러그인을 개발할 필요가 없을 때도 있고, 플러그인을 개발하는 것 자체가 복잡성을 늘릴 수 있기 때문에 가능하면 CLI에 익숙해지는게 낫다라는 취지의 발표다. 발표자료는………. 때가 되면 공개가 될 것 같다. 가능하면 발표자 명단에 들어갈 수 있으면 좋겠다.

Books

  • 스마트 브레비티
    • 스마트 브래비티의 핵심은, “앞에서 요점을 간략하게 말하고 뒤에서 덧붙이는 식으로 읽는 사람의 시간을 아끼는 것이다”
    • 하나하나 읽기도 시간이 부족할 정도로 정보가 넘쳐나는데, 어떻게 하면 이목을 끄는 글쓰기를 할 수 있을지에 대한 내용이 담겨져 있다. 책을 써내려가는 과정 내내 스마트 브래비티 방법론을 쓰면서 설명하고 있기 때문에 직관적으로 읽을만 하다.
    • 손가락 한뼘 정도 크기에 250쪽 정도 되는데 1.5시간~3시간 정도 투자하면 금방 읽을 수 있으니, 한번쯤은 읽어보는 것도 권장한다.

일 때문에 정신없어서도 있고, 이것저것 벌려놨던 일들을 수습하느라 책을 읽을 시간을 확보하긴 어려웠다.

Highlights

프론트엔드 개발에 집중하는 생활

프론트엔드는 좋든 싫든 작은 IT 회사를 다닌다면 피해갈 수 없는 숙명이다. 백엔드만 하고 싶어도 사람이 없으면 프론트엔드를 해야 한다. 누군가는 자진해서 프론트엔드를 하기도 하지만, 누군가는 그냥 짬처리때문에 어쩔 수 없이 하는 것이다. 아마 반대로도 마찬가지일 수 있다.

외주 위주로 개발을 해보면서 느끼는 것이지만, 제품을 고객에게 내놓으려면 어떻게든 모양을 깎아내서 전달해야 하기 때문에 프론트엔드는 불가피하다. 백엔드는 사실상 옵션인 것 같다. 백엔드 수요가 외주 시장에 올라오긴 하지만, 체감상 백엔드 쪽 수요보다 프론트엔드 쪽 수요가 많았다. 백엔드가 있는 곳은 프론트엔드가 있다. 프론트엔드만 있는 곳도 있다. 외주마다 기술스택이 천차만별이지만, 프론트엔드 쪽이 그나마 각자 다른 스택 간 지식의 전이가 수월하기도 했다.

체감상으로는 프론트엔드가 고객에게 다가가서 돈을 벌어오는 기술인 것 같다. 고객에게 어떤 기능이 있는지 보여져야 하며, 매력적인 외형으로 다가가야 하며, 기능을 이용하는데 어려움이 없게 해야 한다. 이런게 내가 느끼는 프론트엔드의 역할이다. 프론트엔드를 하는 것 단독으로도 돈벌이가 될 수 있다. 어떤 것을 포장하는지만 다를 뿐이다. (firebase 같은 백엔드가 붙을 순 있겠지만) 프론트엔드만 개발해서 광고비를 쓸어담고, 서버비를 전혀 부담하지 않고도 돈을 버는 사례들을 숱하게 봐왔다. 프론트엔드의 중요성은 계속해서 실감하고 있다.

근데…. 프론트엔드 너무 어렵다. 그나마 개선되긴 했지만, 퍼블리싱은 아직도 약점인 부분이다. CSS도 알면 알 수록 심오한 부분이 많다. UI를 깎는 심미적인 능력도 중요하지만, 어떤 UX를 제공해줘야 하는지나, 어느 정도 발전하면 사용성/접근성에도 신경을 써줘야 하는데… 아직까지는 접근성을 신경쓰는 영역까지 다가가진 못했던 것 같다.

백엔드 개발은 어떻게든 잘 되긴 하지만, 프론트엔드 개발이 속도가 영 나오지를 않아서 당분간은 프론트엔드 쪽에 계속 집중하게 될 것 같다.

도구를 잘 사용하기

프론트엔드 작업하는 데 있어서 나에게 가장 고통스러웠던 부분 중 하나가 퍼블리싱 쪽인데, 1px 어긋나거나 색상코드가 미묘하게 다른걸 뒤늦게 발견해서 하나하나 바꿔준다거나 그럴 일도 적지 않게 있다. 퍼블리싱하는 것 자체가 정말 신경쓸 요소가 많다. 개인적으로 개발할때는 눈대중으로 보고 개발하는 것이 편하지만, 제품을 납품할 때는 그런거 없다. 텍스트 크기는 얼마 정도인지, 폰트는 뭘 쓰는지, 배경색상은 뭘 쓰는지, 불투명도는 몇퍼센트인지 피그마 켜놓고 마우스 올려대고 컨텍스트 스위칭하는게 불가피한데, 컨텍스트 스위칭 자체가 병목이라는 판단이 들었다.

결국 Figma 유료 플랜을 질렀다. 확실히 퍼블리싱하는데 드는 인지부하는 눈에 띄게 줄었다. 매년마다 통장에서 144 달러가 나가는건 아프지만 말이다.

이미 수많은 사람들이 언급한 주제이기도 하지만, 요즘 시대에는 인공지능 기반의 도구를 잘 사용하는 것도 게임 체인저가 된다고 본다. 나도 이미 그 효과를 실감하고 있기 때문이기도 하다.

(어쩔 수 없이) 개인적으로 사용하고 있는 개발환경도 좀 특이한 케이스인데, Rails로 html 템플릿을 뿌려주고 그 위에 Vue.js 인스턴스를 초기화해주는 방식으로 개발하고 있다. 서버 프레임워크에서 제공해주는 유틸리티 기능도 최대한 활용하면서, 동적인 UI 요소를 구현하려다보니 도달하게된 종착지다. erb 템플릿에다가 vue.js를 섞어쓰는 입장에서는 Options API를 활용해서 개발을 하는 것이 불가피한데, vue.js와 관련된 리소스들은 가능하면 Composition API 중심으로 설명을 하고 있는 곳들이 많다. Modal, Carousel 등등 UI 요소를 모아놓은 라이브러리들은 많은데, 이도 역시 대다수는 Vue.js Composition API를 사용하는 것을 전제하고 있는 곳들이 많다.

그렇다면 선택지는? Options API를 그대로 활용하면서, HTML/CSS/Vanilla JS 만으로 UI 요소들을 직접 구현하는 것이다. 그렇다. 하나하나 바퀴 재발명해야 하는 것이다. 물론, 이러다가 시간 다 가고 마감맞추기 어려울 수 있는 것도 자명한 사실이다. 혼자 힘으로는 말이다.

요즘은 인공지능 기반의 개발 도구도 잘 나와있는 것들이 많다. 그 중 하나가 Make Real이다. 사용방법은 아주 간단하다.

  1. 찍어내고 싶은 화면의 스크린샷을 찍는다.(와이어프레임만 적당히 짜서 던져줘도 상관없다)
  2. 하단에 텍스트 박스 넣어서 어떤 UI를 원하는지 프롬프트를 넣어준다
  3. Make Real 버튼을 누른다
  4. HTML/CSS/JS 코드가 자동으로 생성된다 PROFIT

당연히 돈을 내고 쓰는 물건이다. 혼자서 이것저것 찾아보면서 몇시간 들여서 만드는 것보다 훨씬 빠르다. 심지어 돈도 크게 들지 않는다. 이렇게 써놓고 한달에 10달러를 넘지는 않았던 것 같다. 어차피 잘 모르는거 삽질하면서 납기기한까지 아슬아슬하게 하루살이처럼 개발하는 것보다는 AI가 자동으로 생성해주는 코드가 적당히 퀄리티 만족해주는지 검증이 끝나면, 내가 몰랐던 부분을 배워가고 빠르게 반복적인 피드백 루프를 만들면 된다.

도구를 최대한 활용하면서 개인 생산성을 늘리는 방법을 계속해서 리서치해볼 계획이다.

쉴 때는 쉬어야지…

책을 읽어야 겠다는 강박도 내려놨다. 자기 전에 책을 읽거나 코딩하는걸 가능하면 안 하려고 하고 있다. 휴식이 필요해서 그런지는 모르겠다. 자기전에 뉴스레터를 빠르게 슥 읽기는 한다. 자기 전에 넷플릭스나 라프텔 키고 쿠소애니3 보면서 잠들곤 했었는데, 컨텐츠는 슬슬 고갈되는 것 같아서 이젠 컨텐츠 소비의 방향을 게임으로 돌렸다. n년간 듀오링고를 하면서 일본어에는 어느 정도 익숙해진 것 같아서 일본어로 된 게임을 해보는 걸로 도전하고 있다. 아직은 실패다. 지금 당장은 한자가 제대로 읽혀지질 않는다. 다음에 혹시 일본에 가서 발표하게 되거나 혹은 네트워킹하게 될 일이 있다면 가능하면 얼타지 않는게 목표다.4

이젠 게임 중독이 되었다는건 비밀…….

Conclusion

아무튼, 요즘 들어서 본의 아니게 프론트엔드 쪽 전문성을 키워가는 쪽으로 노선을 틀었다. 내 커리어 이젠 나도 어떻게 되는지는 모르겠다. 요즘은 PostHog 같은 곳에서는 Product Engineer라는 표현을 즐겨서 사용하고 있다. 제품에 주인의식을 가지고 주도적으로 의사결정을 하고 사용자 중심의 제품을 만든다. 이건 백엔드 쪽이 해야할 일, 이건 프론트엔드 쪽이 해야할 일 같은 경계라는게 없다. 사용자에게 제공되는 기능과 가치를 중심으로 생각한다. 어떻게 보면 맞는 얘기이기도 한 것 같다. 나쁘게 말하면 잡부일 수도 있겠지만, 좋게 말하면 나는 프로덕트 엔지니어다 라고 적당히 MSG 치면서 얘기하고 다닐 것 같다.

도구의 중요성도 실감하고 있다. Neovim으로 영광을 되찾고, CLI 도구의 쓸모를 재발견하면서도 도구를 어느 정도 알고 있느냐에 따라 속도전에서 경쟁 우위가 결정된다는 것 쯤은 직감하고 있었다. 이젠 코드를 짜는 것을 넘어서 코드를 짜는 수고를 덜고, 코드를 짜기 위해서 고민하는 시간도 덜어야 한다. 의식의 흐름대로 제품을 찍어낼 수 있는 속도전이 되어야 한다. 그리고 더 중요한 것에 신경을 쏟아부을 수 있어야 한다. 몇몇 스크립트 언어 및 프레임워크들이 생산성이 뛰어나다고 자랑하는 것도 이런 이유다. 언어/프레임워크를 넘어서서, 다음 스텝으로 넘어가는데 드는 레이턴시도 최소화할 수 있어야 하는데 인공지능 기반의 도구들이 그 역할을 잘 해주는 것 같다.

다만, 인공지능 기반의 도구에 지나치게 의존하는 것 역시 경계하고 있다. 제대로 된 후보군을 제시하고 있는건지 제대로 생성된 결과물인지는 내가 그만큼 잘 알아야 판단이 가능하기 때문이다. 인공지능이 만들어준 결과물을 수습하는 것도 내가 통제할 수 있는 범위여야 가능한 것인데, 아무것도 모르는 상태에서 방향을 제대로 못 짚고 시간을 허비한 적이 있었어서 실감하고 있다. 빠르게 피드백 받고 학습하고 다음 단계로 빠르게 나아가기 위한 목적으로서는 인공지능 기반의 도구가 괜찮은 것 같다.

그리고… 쉴 땐 제대로 쉬어야겠다. 어떻게 하면 제대로 쉬는 것인지는 아직 모르겠다.

  1. vue.js 컴포넌트가 마운트될 마크업 ↩

  2. 마크업 위에 vue.js 컴포넌트가 마운트되는 방식을 정의 ↩

  3. 내용이 엉망진창인 애니메이션 ↩

  4. 개인적으론 일본에서 열리는 VimConf에 참여해보고 싶기도 하고, PyConJP도 언제 한번 참석해보고 싶다. ↩

Buy me a coffeeBuy me a coffee