[6] 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식

제가 소속된 동아리인 클라우드 클럽 7기에서 각자 책을 읽고, 짧게 발표 하는 시간을 가졌습니다.

 

그 과정에서 발표를 준비하며 만든 발표 자료를 공유합니다.

 

 

책을 읽으며 중요하다고 생각하거나 흥미로웠던 부분 3가지를 중심으로 정리했고,

필요하다고 느낀 부분은 책에 없는 내용도 일부 보완하여 함께 담아 보았습니다.

 

---

DB의 단편화와 최적화

B+트리는 Root > Branch > Leaf의 트리 구조를 가지며, 균형(Balance)을 유지하는 것이 중요합니다.

데이터 삭제 시에도 이 균형을 유지하기 위해 노드의 재정렬이 필요합니다.

 

삭제된 데이터는 실제로 즉시 제거되지 않고, 해당 공간에 ‘삭제됨’이라는 마크만 남겨 사용이 불가능한 상태로 유지됩니다.

 

 

 

이러한 마킹된 공간이 많아질수록 저장 공간의 단편화가 심해질 수 있습니다.

 

Optimize Table – MySQL 테이블 재구성을 위한 명령어

 

MySQL에서 테이블 단편화가 심해졌거나, 데이터가 비효율적으로 저장되어 성능 저하가 발생할 경우 OPTIMIZE TABLE 명령어를 통해 테이블을 재정렬하고 성능을 개선할 수 있습니다.

 

1. OPTIMIZE TABLE이 하는 일

OPTIMIZE TABLE 명령어는 Primary Key 순서대로 데이터를 재배치합니다. 이 과정에서 인덱스도 함께 정리되기 때문에, 데이터 조회 성능이 향상될 수 있습니다.

 

2. 내부 동작

실제로 OPTIMIZE TABLE은 아래 명령어와 거의 동일하게 작동합니다.

ALTER TABLE 테이블명 ENGINE = InnoDB;

 

즉, 엔진 변경 없이도 테이블을 재구성하는 방식으로 작동합니다.

 

3. ALTER TABLE은 어떻게 작동할까?

MySQL에서 ALTER TABLE 명령은 다음과 같은 단계를 거쳐 수행됩니다.

1. 임시 테이블 생성
2. 기존 데이터를 임시 테이블로 복사
3. 기존 테이블 삭제
4. 임시 테이블을 기존 테이블 이름으로 변경

 

4. 고속 OPTIMIZE 전략

1. Primary Key 외 모든 인덱스를 제거
2. OPTIMIZE TABLE 실행 (또는 ALTER TABLE ENGINE=InnoDB)
3. 인덱스를 다시 생성

이렇게 하면 인덱스 처리 시간이 줄어들고 전체 수행 시간이 크게 단축됩니다.

 

---

메시징 큐 비교하기

 

Kafka보다 RabbitMQ가 더 많은 자원이 필요하다니?!

• 복잡한 라우팅 처리
  • RabbitMQ는 메시지를 어떤 큐로 보낼지 결정할 때, 다양한 규칙(Exchange, Binding 등)을 따릅니다. 예를 들어, 메시지의 키워드나 타입에 따라 큐를 다르게 지정하는 식입니다.
  • 이런 라우팅 처리는 CPU 연산을 많이 필요로 하기 때문에, 메시지 양이 많을수록 CPU 사용률이 높아집니다.
• 메모리 중심 구조
  • RabbitMQ는 기본적으로 메시지를 메모리에 올려놓고 처리합니다. 디스크보다는 메모리를 우선 사용하기 때문에, 큐에 메시지가 많을수록 메모리 사용량도 증가합니다.
  • 반면 Kafka는 디스크 기반으로 설계되어 있어, 메시지를 파일처럼 순차적으로 저장하고 읽는 데 최적화되어 있습니다. 덕분에 대용량 처리에는 더 강점을 가지지만, 구조적으로 자원 사용 방식이 다릅니다.

 

개인적으로는,

• Kafka는 메시지를 빠르게 처리하는 데 중점을 둔 것 같고
• RabbitMQ는 메시지를 어떻게, 누구에게 보낼지 중점을 둔 것 같다고 생각되었습니다.

 

---

트래픽의 증가에 따른 자원 효율 늘리기

 

 

자원 효율이 떨어지는 이유

• IO 대기와 컨텍스트 스위칭에 따른 CPU 낭비
• 요청마다 스레드를 할당함으로써 메모리 사용량이 높음

자원 효율을 높이려면

• 가상 스레드나 코루틴 같은 경량 스레드를 사용
• 논블로킹 또는 비동기 IO사용

 

 

 

코루틴은 함수 실행 상태를 저장하고 재개하면서, 컨텍스트 스위칭 없이 효율적인 비동기 처리를 구현합니다.

 

 

코루틴 자체가 매우 흥미롭게 보이기도 했지만, 아래 말도 매우 중요해 보였습니다.

성능을 높이겠다고 처음부터 비동기 IO로 개발하거나 가상 스레드를 적용하지는 말자.

실제로 IO 성능을 높여야 할만큼 트래픽이 증가하고 있거나
예상되는 트래픽이 높은 경우에만 적용 여부를 고민하자.

주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 中

 

 

제 발표는 여기까지입니다.

 

이번 책을 읽으며, 물론 대규모 트래픽을 감당할 수 있는 구조를 만드는 것이 중요하긴 하지만, 실제로 필요하지도 않은 상황에서 과도하게 기능을 구현하는, 이른바 오버 엔지니어링을 피해야 한다는 점을 다시 한번 생각해보게 되었습니다.

 

해당 발표는 각자가 깊이 있는 내용을 준비하기보다는, 읽은 책을 가볍게 공유해보는 시간이었기에 오히려 서로의 관심사를 알 수 있어 더 유익한 시간이었습니다.

 

비록 얕은 수준의 지식일 수 있지만, 이를 바탕으로 앞으로 더 넓고 깊게 공부해 나가면 좋을 것 같습니다. 😁👍️