이게 정말 맞는 기술 스택인가?

이 글이 기술 스택 선정의 정답을 제시하는 것은 아니지만 그 동안의 경험을 바탕으로 기술 스택을 선택할 때
이런부분도 고민하는구나 하고 생각을 확장하는 의미로 봐주시면 좋을 것 같습니다.

개발자로서 새로운 프로젝트를 시작하거나 기존 시스템을 개선할 때, 어떤 기술 스택을 선택해야 할지  
고민에 빠지게 되는데 이는 수많은 기술 스택 앞에서 '정말 이 선택이 최선일까?' 라는 의문 때문일텐데

저는 아래의 내용처럼 기술 스택 선택 기준을 통해 해당의문을 조금이라도 해소하는데 
그 내용을 공유하려고 합니다.

1. 기술 스택:  왜 나오게 된거야?

최근 기술 스택 논의에서 자주 등장하는 RabbitMQ와 Kafka를 예시로 들어보겠습니다.
분산 환경에서 이벤트 버스 역할을 위해 기술 스택을 선정해야 하는 상황에서,
RabbitMQ와 Kafka는 모두 분산 환경 메시지 브로커로서 주어진 문제 해결에 무리가 없습니다.

하지만 두 기술의 탄생 배경을 살펴보면, 같은 메시지 브로커라도 선택의 방향이 조금 달라질 수 있습니다.

Kafka는 기존 큐 시스템으로는 감당하기 어려웠던 대용량 데이터의 빠른 전송을 위해 탄생했습니다.
Zero-copy, 자체 프로토콜, 분산 환경에서의 스케일 아웃 등 Kafka의 핵심 기술들은 이러한 배경을 뒷받침합니다.

반면 RabbitMQ는 전통적인 비동기 데이터 이동을 위한 메시지 브로커를 목표로 설계되었습니다.
Exchange 기반 라우팅, AMQP 표준 프로토콜 지원, 그리고 다양한 기능 제공은 RabbitMQ의 강점입니다.

물론 환경적 제약이나 비즈니스적 요구사항 등 고려해야 할 요소는 많습니다.
하지만 문제 해결을 위한 기술 스택을 결정할 때, 기술 스택의 탄생 배경은 중요한 가중치가 될 수 있습니다.
기술의 탄생 배경에는 개발 철학과 방향성이 녹아있고, 이는 곧 높은 확률로 기능 확장이나 발전 방향과 연결되기 때문입니다.

그래서 기술 스택을 선택할 때 해당 기술이 왜 나오게 된건지를 한번쯤은 확인 해보시것도 좋은 방향이라고 생각합니다.

2. 성능: 단순 수치가 아닌 그 너머의 균형

성능은 개발자에게 매우 민감한 주제이며, 때로는 불필요한 논쟁이나 오버 엔지니어링으로 이어지기도 합니다.
앞서 얘기한 RabbitMQ와 Kafka 역시 성능 비교에서 자주 언급되는 기술 스택입니다.
일반적으로 특정 조건 하에서는 Kafka가 RabbitMQ보다 뛰어난 성능을 보이는 것은 사실입니다.

두 기술의 아키텍처 차이에서도 이 점은 명확하게 드러납니다.

RabbitMQ는 비교적 단일 노드 중심의 Scale-Up 구조에서 안정적인 성능을 제공하며,
Clustering을 통한 확장도 가능하지만 구조적으로는 Kafka만큼의 수평 확장은 어려운 편입니다.

반면, Kafka는 처음부터 대용량 데이터 전송과 분산 처리를 염두에 두고 설계된 만큼,
Scale-Out 구조에서의 성능과 확장성이 핵심 장점입니다.

그렇다면 성능만을 기준으로 Kafka를 선택하는 것이 항상 정답일까요?
대부분의 고트래픽 상황에서는 Kafka가 더 유리할 수 있지만, 그렇다고 무조건 Kafka를 선택하는 것이 옳다고 단정하기는 어렵습니다.

시스템에 요구되는 성능은 정량적인 지표로 산출 가능하며,
일반적으로 Peak 트래픽 상황을 대비하여 평균 성능의 1.2~1.5배 정도를 확보하는 것이 적절하다고 알려져 있습니다.

1.5배 이상의 성능이 보장된다면, 성능이 좋다는 부분보다는 '성능에 문제가 없다'는 관점으로도 기술 스택을 평가할 수 있습니다.
미래 트래픽 증가에 대한 막연한 기대감으로 단순히 고성능 기술 스택을 선택하는 것은 오히려 오버 엔지니어링으로 이어지거나
시스템의 복잡도를 높이는 등의 기술 스택 선택의 아쉬움으로 남을 수 있고 아래에서도 다시 얘기하겠지만
현재 서비스에서 현실적인 비용적인 문제로 인해
성능상의 문제가 없다면 Kafka 대신 RabbitMQ 또는 RabbitMQ 대신에 SQS를 사용하는 선택을 할 수 도 있어야한다는 의미이긴 합니다.

즉 단순히 성능이 우수한 기술 스택을 선정하는것이 아니라 기술 스택을 변경해도 문제가 최소화 될 수 있는
확장성 있는 아키텍처를 구축하고 현재의 상황에서 가장 현실적인 선택을 할 수 있는 것이 중요하다고 생각합니다.

( RDBMS vs Redis 와 같은 극단적인 성능 비교도 같은 맥락에서 생각해 볼 수 있습니다.)

3. 성장과 팀워크의 조화

제가 주니어 개발자 시절에는 최신 기술, '핫'한 기술을 사용하는 것이 최고의 선택이라고 생각했습니다.
새로운 기술 도입을 설득하기 위해 기술의 장점과 트렌디함을 강조했지만, 함께 일하는 구성원에 대한 고민은 부족했습니다.

주니어 레벨에서 최신 기술에 대한 욕심을 갖는 것은 자연스러운 성장 과정입니다.

하지만 시니어 개발자가 되면, 나의 성장뿐 아니라 팀 구성원 전체의 성장을 고려해야 합니다.
해당 기술이 직면한 문제를 해결하는데 이슈가 없는지,
새로운 기술 스택이 구성원들의 커리어에 도움이 될 수 있을지,
구성원들이 해당 기술 스택에 대해 어떤 인식을 가지고 있는지,
새로운 기술에 대한 구성원들의 학습 의지와 성향은 어떠한지 등을 종합적으로 고려해야 합니다.

기술 스택이 다소 생소하고 어렵더라도, 팀원들이 기술에 대한 긍정적인 인식과 성장 의지를 공유한다면,
새로운 기술 스택 도입은 팀워크 향상과 긍정적인 소속감 형성에 크게 기여할 수 있습니다.
( 저의 경험중에는 Mybatis에서 JPA로의 전환이 그랬던것 같습니다.)

4. 비용 무엇보다 민감한 ...

시니어 레벨로 올라갈수록 비용 문제는 더욱 현실적인 고민으로 다가옵니다.
기술 스택 선택 시 총소유비용(TCO)까지 고려하는 것은 어렵더라도,

최소한 기술 스택 선택에 따른 비용은 꼼꼼하게 따져봐야 합니다.
저비용 고효율은 기술 스택 선택에 있어 강력한 설득력을 갖는 최고의 무기입니다.

저는 기술 스택 관련 비용은 크게 다음의 정도로 고려합니다.

4.1] 개발 비용: 기술 스택을 사용하여 개발하는 데 드는 직접적인 비용입니다.

기존 시스템과의 호환성 및 러닝 커브:
기존에 Redis를 캐시 시스템으로 사용하고 있다면, 
분산 락 기능 구현을 위해 Redisson을 고려하는 것처럼, 기존 기술 스택과의 연관성을 고려해야 하며

JPA를 사용하는 환경에서 복잡한 조인이나 동적 쿼리 문제를 해결하기 위해 
Querydsl, kotlin-jdsl 같은 추가적인 기술 도입을 고려하는 경우도 개발 비용에 포함됩니다.

개발자 인력 풀: 
특히 빠르게 성장하는 스타트업 환경에서는 기술 스택 관련 개발자 인력 확보 가능성도 중요한 고려 사항입니다. 
개발 인력 풀이 넓은 기술 스택은 인건비 절감 효과를 가져올 수도 있습니다.

4.2] 유지 비용: 시스템 운영에 필요한 지속적인 비용입니다.

클라우드 인프라 비용: 
MKS(Kafka), AMQ (RabbitMQ) 와 SQS 와 같이 클라우드 환경에서 메시지 큐 서비스를 선택할 때, 비용 차이를 고려해야 합니다.

솔루션 유지보수 비용: 
개발을 하는것보다 솔루션을 사용하는것이 우선은 더 저렴할 수 있습니다. 다만 상용 솔루션을 사용하는 경우,
솔루션 구입비용 외에도 정기적인 유지보수 비용이 발생할 수 있으니 해당 부분도 고려해야합니다.

개발 유지보수 비용 :
회사의 인력의 개발을 얼마나 잘 또는 빠르게 할 수 있느냐에 대한 비용

라이선스:
오픈소스라고 해서 항상 무료는 아닙니다. 라이선스 조건을 꼼꼼히 확인해야 합니다.

기술 스택을 고민할 때 위의 4가지에 대해서 고민을 많이 하는 편인데 본인이 결정에 대한 권한이 없는경우라면 설득을 해야하며
설득을 위한 명분 및 기준으로 위의 내용을 인용해서 자료를 작성하는 편이였고 비용에 대한 부분을 제외하곤
크게 반대의견을 받은 케이스가 없어 아직도 기준으로 생각하는 부분이여 내용을 공유 해보았습니다.

좋은 의견이나 문의는 언제든 환영입니다.