Publish blog post 2024-11-01

src/_drafts/braindump.md

@@ -274,75 +274,3 @@ Stack은 특성상 가장 맨 뒤에 진열된 위젯이 가장 위에서 보이
 
 
 
-2024-10-26
-
-
-----
-
-
-
-# 기본을 잘하는 것이 힙한 것이다
-
-
-> 나 또한 Boring Technology에 굉장히 찬성하는 입장이기 때문에, 편파적인 관점이 있다. Boring Technology 자체를 엄청 싫어하는 성향이라면 그냥 지나가도 좋을 것 같다. Boring Technology를 찬성하는 입장일 뿐, 업계의 최근 동향을 반영하는 것이 무조건 나쁘다고 생각하진 않는다. 다만, 불필요한 복잡성을 추가하는 것이 아닌지는 고려할 필요가 있다.
-
-사람이라면 누구나 인정욕구라는 것이 있다. 내가 이 정도는 해낼 수 있다는 역량을 드러내기 위함이라던가 인터뷰에서 걸러지지 않기 위해서 지금 당장 실감이 나지 않는 것이라 할지라도 새로운 개념을 공부해야 겠다는 강박이 생기는 것은 어쩔 수가 없다. 그저 저마다의 생존방식이기 때문에 그러는 것일 뿐이다. 그게 자의에 의한 것이든 타의에 의한 것이든.
-
-학원가라던가 일부 교육 업체에서는 특히 빅테크에서 일하려면 마이크로서비스 아키텍쳐를 알아야 하며, 대규모 트래픽을 감당할 수 있는 실력을 가져야 하는 것처럼 마케팅을 하고, 그런 경험이 없는 사람들에게 FOMO를 안겨주는 것이 마치 당연한 것처럼 관행이 이어져오고 있다. 업계에서 그런 사람들을 원하는 요구사항이 있다면, 교육업계도 그걸 반영하는 것이 어떻게 보면 당연한 일이다.
-
-## 우리는 정말로 이게 필요한걸까?
-
-한편으로는 의문이 드는 지점이 있다. **우리는 정말 필요해서 이것을 하고 있냐**는 점이다. 기술스택을 결정하는데 있어서는 저마다의 사정이 있고, 비즈니스의 관점에서 보았을 때 나름 합리적인 의사결정 과정이 있었을 수 있다. 하지만, 여러 사례들을 관찰해본 관점에서 봤을때, 개인으로서는? 그렇지 않은 경우가 많은 것 같다.
-
-
-### 숨겨져 있는 복잡성
-
-가령, 사이드 프로젝트 혹은 포트폴리오를 만들기 위해서 간단한 Todo 앱을 만든다고 가정하자. Todo 앱을 만든다고 하더라도, 웹 개발자로서는 백엔드 쪽으로 역량이 있다는 것을 어필할 수도 있고, 프론트엔드 쪽으로 역량이 있다는 것을 어필할 수도 있다. 혹은 기술을 가리지 않고 프로덕트를 완성하는데 의미를 두는 풀스택 엔지니어(좋게 말하면, Product Engineer)로서 어필할 수도 있을 것이다. 여기에서도 선택과 집중이 필요하다. 누군가는 Github Actions를 끼얹어서 클라우드 서비스를 통해 배포할 수도 있고, 누군가는 EC2에 SSH 접근해서 배포하는 식으로 접근할 수도 있다. 혹은, 리포지토리에 푸시만 넣으면 바로 배포가 되는 PaaS를 이용할 수도 있다.
-
-
-
-
-채용공고에서 명시했고, 그에 맞게 과제를 하는 것이라면 분명 좋은 접근 방식일 수 있다. 다만, 제품을 만들때는 일부 기술스택은 우선순위가 그렇게 높지 않을 수도 있다.
-
-#### 배포 방식 (혹은 인프라)
-
-먼저, **배포방식**에 대해 살펴보자. PaaS가 장사가 잘 되는 이유가 무엇일지에 대해 생각해보자. 그것은 배포를 하는데 드는 인지부하와 불필요한 시간을 줄이고, 핵심적인 비즈니스 로직에 더 집중할 수 있게 보조하는 것에 의의가 있다. 어떤 인프라를 유지보수하고 있다면, 유지보수하는 주체가 조직 내부 구성원이 되거나 혹은 PaaS 업체에 외주 주거나로 관점을 바뀔 수 있다. 퍼포먼스를 최대한 쥐어짜내고 인프라 비용을 줄이기 위해서 조직 내부 구성원이 인프라를 유지보수한다면, 인프라를 AWS EC2에다가 바로 배포하는 방식으로
-
-#### 아키텍쳐
-
-**아키텍쳐**에 대해서도 알아보자. 빅테크 경험이 없는 입장에서 아키텍쳐를 논하는게 우습긴 하지만, 프레임워크에서 강제하는 아키텍쳐는 제쳐두더라도, 프레임워크에서 강제하지 않는 아키텍쳐로
-
-마이크로서비스 아키텍쳐는 또 어떤가? DAU가 300명이 안되고 트래픽 분산이라는게 필요가 없는 규모에서는 모놀리스 아키텍쳐로 운영하는 것이 적당할 수도 있는데, Single Point of Failure 혹은 서비스의 확장성 내지는 Fault Tolerance의 사유를 들 수도 있다. 근데, 그게 마이크로서비스 아키텍쳐 만으로 가능하냐면 모르겠다. 정말 도입을 하는게 필연적인 요구사항이라면 맞을 수도 있을 것 같다.
-
-
-#### 도입하는 기술 스택
-
-시간이든 시간안에 쳐낼 수 있는 일의 양이든 모든 자원은 한정되어 있다. 이런 한정된 자원을 적제적소에 스케쥴링하는 것도 엔지니어로서의 역량이다. 핵심적으로 어필해야 하는 것을 제쳐두고, 불필요한 복잡도를 늘리면서 불필요한 곳에 시간을 잡아먹는 것은 지양할 필요가 있다.
-
-### 우리에게 정말로 필요한 것
-
-문제를 해결하는 사람의 관점에서 생각해보자. 우리가 가장 먼저 해결해야 하는 것은 무엇인가? 그것은 바로 눈 앞에 있는 과제를 해결하는 것이다. 고객이 있다면 고객과 충분히 대화하고 고객이 원하는 것을 충족시키는 핵심적인 기능을 만들고 가다듬는 것이다.
-
-필요한 지점이 오면 그 때 하는 것이 최선의 방법이라고 본다.
-
-## 우리는 본연에 충실할 필요가 있다
-
-회사에서 제품을 만들든, 남들이 이용하기를 바라는 사이드 프로젝트를 만들든, 어느 정도 경험을 쌓았다면 다들 알게 되는 것이 있다. 기술적인 관점에서 접근하는 것이 전부는 아니라는 것이다. 우리 딴에는 "필요할 것 같은데?" 라고 생각을 하더라도, 고객 입장에서는 그렇지 않은 경우를 숱하게 보곤 한다.
-
-
-이전에 [잘해야 한다는 강박이 얼마나 해로울 수 있는지](/posts/2024-08-02-do-not-try-unncecessary-hard-things) 앞서 언급한 적이 있다.
-
-
-
-엔지니어로서의 자세에 대해
-
-## 마치며
-
-이런 글을 쓰기로 마음 먹게 된 계기를 말하자면, 의외로 타임라인에서 떠도는 얘기들을 관찰하면서 트리거가 된 것은 아니다. 일상에서 접하는 것들을 마주하면서 문득 떠오른 생각이었다.
-
-2024년 11월 19일 [NeovimConf.live 2024](https://neovimconf.live) 에서도 위에서 언급한 주제와 비슷한 주제로(You don't need plugin, Long live command lines) 발표할 예정이다. 좋아보인다고 플러그인을 덕지덕지 붙여서 불필요한 복잡성을 늘리거나, 바퀴를 재발명할 바에는 터미널에서 Vim 에디터를 사용하는 입장에서 커맨드라인을 잘 사용하는 방법을 익히는 것이 도움이 될 수 있다는 관점으로 발표할 예정이다.
-
-
-
-
-