2025-02-13-TIL

2025-02-13-TIL

Today I Learned

Why?

엔지니어는 모든 기술에 대해서 왜? 필요한지에 대한 목적성과 부합성을 따져보아야하며, 그 기술의 등장 배경도 이해하는것이 중요하다.

아키텍쳐 확장

현대의 소프트웨어 아키텍처가 복잡해진 과정에서 크게 두 가지 관점에서 이해하면 받아들이기가 수월하다. 첫 번째는 성능의 측면이다. 트래픽이 늘어남에따라 서버의 안정성과 신뢰성, 그리고 회복성을 최대화하기위한 노력으로 클라우드, K8S, 도커 등의 클라우드 엔지니어링이 발전해왔다. 두 번째는 사용자 경험(UX)의 극대화이다. 현재의 애플리케이션은 점점 성능이 좋아짐에 따라 사용자의 눈높이도 매우 높아졌다. 그리고 비즈니스의 요구사항도 매우 복잡해졌다. 따라서 사용자의 경험에 안 좋은 영향이 가지않도록 많은 노력을 했고, 이는 성능의 개선과 장애 발생 시 파급력 최소화를 위한 각종 기술의 발전으로 이어졌다. 프론트엔드, SSR, 백엔드, MSA 등이 그것이다.

서버의 대수를 늘리거나(scale out) 하드웨어 스펙을 업그레이드(scale up)하는 시점과 기준은 무엇일까? 우선 scale관련 변경은 사용자의 수(트래픽)의 영향으로 확장되거나 업그레이드 된다. 단순한 전통적인 모놀리식 웹 서버에서는 트래픽이 늘어나면 서버의 대수나 스펙을 업그레이드 하곤했다.

하지만 현대의 웹 애플리케이션에서는 변경사항의 유연한 적용 등을 이유로 프론트엔드와 백엔드 서버가 보통 따로 존재하고, 프론트엔드 단에서 발생하는 트래픽과 백엔드 서버에서의 부하를 분리할 수 있게되었다.

그리고 백엔드 서버를 좀 더 들여다보면, 동기 방식으로 처리되는 단순한 API로는 모든 요구사항을 실시간 응답하기 어려운 경우가 생긴다. 그래서 엔지니어들은 비동기 방식으로 응답을 먼저 하고, 내부적으로는 처리를 하는 등의 비동기 메서드를 구현한다.

이 비동기 메서드의 기능이 갈수록 하나의 서버에서 담당하기에 벅찬 경우가 생긴다. 사용자의 입장에서 사용성을 고려하면 바로 응답을 받고 처리되는 경과만 알기를 원할때가 많다. 그런데 이때 처리과정이 복잡하고 오래걸린다면 별도의 무거운 처리를 수행할 서버를 분리할 수도 있다.

이 과정에서 별도의 서버로 비동기 방식의 메시지 전달이 필요하게 되는데, 이를 위해 구현된 메시지 전달을 해주는 메시지 브로커(RabbitMQ, Kafka)가 존재한다. 메시지 브로커는 단순히 메시지를 전달하는게 아니라 메시지를 줄 세우고(큐, Queue), 유실되지않게 메시지의 신뢰성을 보장하는 등 다양한 기능을 수행한다.

이렇게 비동기로 통신하는 서로 다른 두 개 이상의 서버가 계속 늘어나게 되면서, 각 서비스는 각자도생 하면서도 만약에 일부 서버가 다운되었을 때 사용자는 그 충격을 최소한으로 받도록 할 방법에 대해서 고민하게 되었다. 그래서 사용성과 복구에 대한 민첩한 대응 등을 목적으로 MSA 개념이 등장하였다.

-> 인프라 및 클라우드 관점에서, 코드 관점에서, 서버 관점에서 아키텍처의 발전과정을 정리해보았다.

채용 공고를 보고 느낀점

내가 원하는 회사와 직무의 채용공고를 보고, 내가 어떤 기술이나 장점을 이미 가지고 있고 어떤 기술을 학습해야할지를 정리해보았다.

내가 주로 수행한 업무에서는 MySQL 8.0, Spring Boot 3.6.6, Java 21, Docker, AWS EC2로 구성된 서비스를 개발 및 운영했다. 하지만 B2C의 성격이 강한 프로젝트가 많지 않아서 유효하면서 TPS도 최대 100hits/s을 채 넘지않는 서비스였다. 그래서 Product의 많은 트래픽을 감당해야하는 서비스를 개발 및 운영해보고 싶다고 생각했고, MSA나 이벤트 기반 아키텍쳐 등의 서버 아키텍쳐 컨셉이 유의미한 효과를 보이는 것을 체감해보고 싶었다.

따라서 이번에는 B2C에서 정말 유효한 트래픽을 안정성있게 관리하는 일을 해보고싶었고, 이런 요구사항에 맞는 회사와 직무는 토스증권의 Product 서버 개발자, 그리고 토스 계열사의 각 Product 서버 개발자 직군이 있다.

그렇다면 내가 해당 직군에 지원하기 위해서 갖추어야할 역량과 기술은 무엇일까?