기본을 잘하는 것이 힙한 것이다.

나 또한 Boring Technology에 굉장히 찬성하는 입장이기 때문에, 편파적인 관점이 있다. Boring Technology 자체를 엄청 싫어하는 성향이라면 그냥 지나가도 좋을 것 같다. Boring Technology를 찬성하는 입장일 뿐, 업계의 최근 동향을 반영하는 것이 무조건 나쁘다고 생각하진 않는다. 다만, 불필요한 복잡성을 추가하는 것이 아닌지는 고려할 필요가 있다.

사람이라면 누구나 인정욕구라는 것이 있다. 내가 이 정도는 해낼 수 있다는 역량을 드러내기 위함이라던가 인터뷰에서 걸러지지 않기 위해서 지금 당장 실감이 나지 않는 것이라 할지라도 새로운 개념을 공부해야 겠다는 강박이 생기는 것은 어쩔 수가 없다. 그저 저마다의 생존방식이기 때문에 그러는 것일 뿐이다. 그게 자의에 의한 것이든 타의에 의한 것이든.

학원가라던가 일부 교육 업체에서는 특히 빅테크에서 일하려면 마이크로서비스 아키텍쳐를 알아야 하며, 대규모 트래픽을 감당할 수 있는 실력을 가져야 하는 것처럼 마케팅을 하고, 그런 경험이 없는 사람들에게 FOMO를 안겨주는 것이 마치 당연한 것처럼 관행이 이어져오고 있다. 업계에서 그런 사람들을 원하는 요구사항이 있다면, 교육업계도 그걸 반영하는 것이 어떻게 보면 당연한 일이다.

우리는 정말로 이게 필요한걸까?

한편으로는 의문이 드는 지점이 있다. 우리는 정말 필요해서 이것을 하고 있냐는 점이다. 기술스택을 결정하는데 있어서는 저마다의 사정이 있고, 비즈니스의 관점에서 보았을 때 나름 합리적인 의사결정 과정이 있었을 수 있다. 하지만, 여러 사례들을 관찰해본 관점에서 봤을때, 개인으로서는? 그렇지 않은 경우가 많은 것 같다.

숨겨져 있는 복잡성

가령, 사이드 프로젝트 혹은 포트폴리오를 만들기 위해서 간단한 Todo 앱을 만든다고 가정하자. Todo 앱을 만든다고 하더라도, 웹 개발자로서는 백엔드 쪽으로 역량이 있다는 것을 어필할 수도 있고, 프론트엔드 쪽으로 역량이 있다는 것을 어필할 수도 있다. 혹은 기술을 가리지 않고 프로덕트를 완성하는데 의미를 두는 풀스택 엔지니어(좋게 말하면, Product Engineer)로서 어필할 수도 있을 것이다. 여기에서도 선택과 집중이 필요하다. 누군가는 Github Actions를 끼얹어서 클라우드 서비스를 통해 배포할 수도 있고, 누군가는 EC2에 SSH 접근해서 배포하는 식으로 접근할 수도 있다. 혹은, 리포지토리에 푸시만 넣으면 바로 배포가 되는 PaaS를 이용할 수도 있다.

배포 방식 (혹은 인프라)

먼저, 배포방식에 대해 살펴보자. PaaS가 장사가 잘 되는 이유가 무엇일지에 대해 생각해보자. 그것은 배포를 하는데 드는 인지부하와 불필요한 시간을 줄이고, 핵심적인 비즈니스 로직에 더 집중할 수 있게 보조하는 것에 의의가 있다. 어떤 인프라를 유지보수하고 있다면, 유지보수하는 주체가 조직 내부 구성원이 되거나 혹은 PaaS 업체에 맡기거나로 관점이 나뉠 수 있다. 퍼포먼스를 최대한 쥐어짜내고 인프라 비용을 줄이기 위해서 인프라가 주력이 아닌 조직 내부 구성원이 인프라를 유지보수한다면, 인프라를 AWS EC2에다가 바로 배포하는 방식으로 접근할 수도 있다. 데이터베이스 및 인메모리 캐시까지 같은 서버에서 배포한다면 월 20~40달러 안쪽으로 나올 수도 있을 것이다. 하지만, 비즈니스 로직을 빠르게 개발해서 출시하는 것이 중요하고, 인프라를 관리하는데 드는 시간적 비용을 줄이고 싶다면 PaaS 업체에 인프라 관리를 맡기는 편이 시간도 아낄 수 있기 때문에 더 나을 수 있다.

아키텍쳐

아키텍쳐에 대해서도 알아보자. 빅테크 경험이 없는 입장에서 아키텍쳐를 논하는게 우스울 수도 있겠다. 프레임워크에서 강제하는 아키텍쳐는 제쳐두더라도, 프레임워크에서 강제하지 않는 아키텍쳐로 개발을 한다고 가정했을때 여기서도 트레이드오프가 필요하다. 예를 들어, 소스 코드 파일을 어떻게 구성하고 조직할지, 팀원들의 이해 수준이나 소스 코드의 복잡도가 가져올 인지부하까지 고려해야 한다. 만약 빠른 출시가 최우선이라면, 복잡한 구조보다는 팀이 쉽게 이해하고 작업할 수 있는 단순한 아키텍처가 오히려 더 효과적일 때가 많다. 결국, 중요한 것은 프로젝트의 요구사항에 맞고, 팀이 지속적으로 관리 가능한 구조를 선택하는 것이다.

안하면 안된다고 얘기가 나오고 있는 마이크로서비스 아키텍쳐는 또 어떤가? DAU가 300명이 안되고 트래픽 분산이라는게 필요가 없는 규모에서는 모놀리스 아키텍쳐로 운영하는 것이 적당할 수도 있는데, Single Point of Failure 혹은 서비스의 확장성 내지는 Fault Tolerance의 사유를 들 수도 있다. 근데, 그게 마이크로서비스 아키텍쳐 만으로 가능하냐면 모르겠다. 정말 도입을 하는게 필연적인 요구사항이라면 맞을 수도 있을 것 같다.

도입하는 기술 스택

기술 스택에 대해서도 생각해보자. 시간이든 시간안에 쳐낼 수 있는 일의 양이든 모든 자원은 한정되어 있다. 이런 한정된 자원을 적제적소에 스케쥴링하는 것도 엔지니어로서의 역량이다. 핵심적으로 어필해야 하는 것을 제쳐두고, 불필요한 복잡도를 늘리면서 불필요한 곳에 시간을 잡아먹는 것은 지양할 필요가 있다. 요즘은 해석이 다르긴 하지만, “섣부른 최적화는 만악의 근원”이라는 말도 있다. 당장은 내놓은 제품이 느리거나 아키텍쳐적으로 좋지는 않을 수 있다. 근데 빠른 출시를 위해서 어쩔 수 없이 트레이드오프를 한 것이라면 이것도 분명 옳은 선택일 수 있다. 완벽함을 추구하기보다 현재의 요구사항과 리소스에 맞춰 최선의 결정을 내리는 것이 중요하다.

채용공고에서 명시했고, 그에 맞게 과제를 하는 것이라면 분명 실제로 사용되는 규모에 비해 오버엔지니어링이라 할 지라도 좋은 접근 방식일 수 있다. 다만, 제품을 만들때는 일부 기술스택은 우선순위가 그렇게 높지 않을 수도 있다.

우리는 본연에 충실할 필요가 있다

회사에서 제품을 만들든, 남들이 이용하기를 바라는 사이드 프로젝트를 만들든, 어느 정도 경험을 쌓았다면 다들 알게 되는 것이 있다. 기술적인 관점에서 접근하는 것이 전부는 아니라는 것이다. 우리 딴에는 “필요할 것 같은데?” 라고 생각을 하더라도, 고객 입장에서는 그렇지 않은 경우를 숱하게 보곤 한다. 엔지니어로서 우리는 그냥 미션을 해결하면 되는 것인데, 어떤 도구를 사용하고 있는지는 고객에게 그렇게 중요하지 않을 수도 있다.

문제를 해결하는 사람의 관점에서 생각해보자. 우리가 가장 먼저 해결해야 하는 것은 무엇인가? 그것은 바로 눈 앞에 있는 과제를 해결하는 것이다. 고객이 있다면 고객과 충분히 대화하고 고객이 원하는 것을 충족시키는 핵심적인 기능을 만들고 가다듬는 것이다. 문제를 해결하기 위해 사용하는 기술이나 방법론은 단순히 수단일 뿐이지, 그것이 과시하는 것을 드러내거나 혹은 인정을 받기 위한 것이나 다른 목적이 끼여있으면 안 된다. 필요한 지점이 오면 그 때 하는 것이 최선의 방법이다.

엔지니어의 관점에서도 엄청 핫한 기술을 쓰지 않고서도 주어진 미션을 해결하기 위해 엔지니어의 인지부하를 최소한으로 만드는 솔루션도 나오곤 한다. 예시를 두개 정도 들어보고 싶다. 먼저, ssh로 직접 접근해서 배포하는 방식 + 컨테이너를 사용하는 배포방식을 교묘하게 잘 섞은 kamal이라는 솔루션이 있다. PaaS를 쓰는 듯한 경험을 할 수 있으면서도, 누가 인프라를 복잡하게 세팅하지 않고도 서비스를 어렵지 않게 배포할 수 있고, 서버의 자원을 최소화하면서도 격리된 환경으로서의 장점을 동시에 누릴 수 있다.

또 하나의 예시로는 데이터베이스를 메시지 큐로 쓰는 관점이 있다. Postgres의 예시를 들자면 LISTEN/NOTIFY를 활용해서 이벤트를 구독하고, 일정 간격으로 폴링하거나 즉시 알림을 받아 필요한 작업을 트리거하는 것이다. Rails에서는 Solid Queue/Good Job, Django 에서는 Django Q가 대표적인 예시다. 의외로 빠른 출시를 위해서 사용하긴 괜찮은 솔루션이다. Redis/Kafka/RabbitMQ 등 추가적인 인프라를 세팅하지 않고서도 데이터베이스를 세팅하는 것 하나만으로 문제를 해결할 수 있기 때문이다. 심지어, 데이터베이스를 캐시로 쓰는 관점도 있다. 이에 대해서는 Solid Cache를 살펴보면 될 것 같다. 인프라의 가짓수를 줄여서 인프라 관리의 복잡도를 최소화하는 것에 중점을 두는 것이라면 제법 괜찮은 접근이라고 본다.

기본에 충실한 것, 본연에 충실한 것이 무엇인지도 고민해볼 필요가 있다. 기본에 충실하다는 것은 단순히 어디에도 휘둘리지 않고 문제의 본질을 꿰뚫는 통찰력을 갖추는 것이다. 문제를 본질적으로 해결할 수 있는 능력을 키우는 것, 즉, 문제의 핵심을 파악하고 다각도로 깊이 있게 바라보는 능력을 기르는 것이 중요하다. 어떤 지인의 말을 빌리자면, 공부한다는 것은 현상을 바라보는 해상도를 늘리는 것이다. LLM의 도움을 받는다하더라도 아는 만큼 보이기 때문에, 더더욱 중요해졌다. 우리는 그저, 엔지니어의 관점에서 문제를 해결하는 것에 집중하기만 하면 된다.

마치며

다시 돌아가자면, 기본을 잘하는 것이 힙한 것이다. 미션을 잘 수행한다라는 기본을 잘하는 것에 우선순위를 가장 높게 둬야 한다. 스스로에게 복잡성이라는 핸디캡을 주면서 도전적인 일을 할 수는 있겠지만, 미션을 수행하지 못하면 인정받는건 물론이고 신용을 가지기도 어렵다. 최신 기술이나 트렌드에 너무 빠지기보다는, 본질적인 문제 해결에 집중하고, 고객에게 필요한 가치를 제공하는 것이야말로 진정한 의미에서의 “잘하는 것”이고 정말로 “힙한 것”이다. 당사자성이 있는 사람으로서 말하지만, 학습을 하는 입장에서도 마찬가지로 적용할 수 있을 것 같다. 뉴스레터를 접하면서 여러가지 트릭이나 라이브러리 및 도구를 알아보는 것도 분명 좋은 접근이지만, 문제를 본질적으로 파악할 수 있는 시야를 가지는 것이 중요하다. 때로는 고전으로 여겨지는 이론서가 오히려 장기적으로 더 큰 이득을 가져다줄 수 있다.

이런 글을 쓰기로 마음 먹게 된 계기를 말하자면, 의외로 타임라인에서 떠도는 얘기들을 관찰하면서 트리거가 된 것은 아니다. 일상에서 접하는 것들을 마주하면서 문득 떠오른 생각이었다. 요즘은 머신러닝/LLM이 핫하다고는 하지만, 그런 것이 아예 없으면서도 장사가 잘 되는 제품들도 있고, 그런 제품들을 만드는 사람들의 관점들을 보자면 자주 감탄하게 되곤 한다. 언제였는지 기억이 나지는 않는데, 프로덕트헌트에 올라왔던 것 중에 jQuery + php 기반의 스택에다가 구조화가 잘 되어있지 않았음에도 10k 정도의 star가 찍혔던 오픈소스 프로젝트가 있었다.(제대로 기억하는 사람이 있다면 알려주면 좋을 것 같다. 어렴풋이 기억은 하고 있다.) 사진 편집기 어플리케이션이었던 것으로 기억한다. 어떤 스택을 쓰는지는 그렇게 중요하지는 않았고, 프로덕트헌트에서 상위권에 올라갔을 정도면 제품의 퀄리티만으로 인정을 받은 것이다. 이외에도 좋은 프로덕트들을 많이 접하긴 했는데, 좋은 프로덕트를 만드는 것에는 어떤 기술 스택을 선택하는지는 크게 중요하지 않았다는 사실을 깨달았다.

이전에 잘해야 한다는 강박이 얼마나 해로울 수 있는지 개인적인 사례를 들면서 앞서 언급한 적이 있다. 적절하지 않은 비유와 그닥 와닿지 않는 경험이 들어가있을 수도 있겠지만, 요즘 들어서 일관적으로 드는 생각이다. 기술적인 역량으로 인정받고자 하는 것은 엔지니어로서는 당연히 가질 수 밖에 없는 것이겠지만, 정말 적절한 기술인지를 결정하는 것도 엔지니어의 역량 중 하나이며 어떻게 보면 가장 중요한 영역이라고 생각한다.

2024년 11월 19일 NeovimConf.live 2024 에서도 위에서 언급한 주제와 비슷한 주제로(You don’t need plugin, Long live command lines) 발표할 예정이다. 좋아보인다고 플러그인을 덕지덕지 붙여서 불필요한 복잡성을 늘리거나, 바퀴를 재발명할 바에는 터미널에서 Vim 에디터를 사용하는 입장에서 커맨드라인을 잘 사용하는 방법을 익히는 것이 도움이 될 수 있다는 관점으로 발표할 예정이다.