WAS, Redis, RabbitMQ 이게 먼데? 왜 이걸 꼭 써야 한다는거야? (부제 : 나의 무식함을 알았다)

나는 왜 Redis / RabbitMQ 이야기를 들으면 짜증이 날까 (그리고 그게 나쁜 신호가 아닌 이유)

갑자기 짜증이 났다. 이유는 단순했다.

“왜 다들 그걸 공부해야 할 대상으로 만들지?”
“그게 도대체 뭔데? 왜 필요한데?”

이 감정은 예전에도 똑같이 겪었다. 사람들이 WAS를 공부한다고 난리였을 때였다. 나는 속으로 이 생각을 했다.

“WAS가 뭐길래 난리야…?”
“나는 오라클, 아파치, 톰캣 설치해서 쓰고 있는데…”

나중에 알고 보니, 나는 WAS라는 단어를 몰랐을 뿐 이미 그 세계를 살고 있었다. 오늘 Redis / RabbitMQ 이야기도 그때랑 같은 결이었다.

---

혼자 일하면 생기는 사고 방식

팀에서 일하면 보통 이런 흐름으로 배운다.

• 도구 이름을 먼저 배운다
• 그 도구가 해결하는 문제를 나중에 이해한다

그런데 혼자 오래 일하면 흐름이 반대가 된다.

• 문제를 먼저 본다
• 구조를 직접 만든다
• 나중에 그 구조의 “공식 이름”을 듣는다

그래서 이런 일이 생긴다.

• 사람들은 “이걸 배워야 한다”고 말하는데
• 나는 “그게 무슨 문제를 해결하는데?”부터 묻게 된다
• 그리고 결국 “아… 내가 이미 하던 거네?”로 끝난다

---

나는 큐를 안 쓴 게 아니라, 큐를 만들어 쓰고 있었다

사실 나도 “큐가 필요하겠는데?”라는 상황을 여러 번 겪었다. 그때마다 Redis나 RabbitMQ를 먼저 꺼내기보단, 내가 통제 가능한 방식으로 해결했다.

• DB를 이용하던
• 파일을 이용하던
• TCP로 직접 통신하던
• 어쨌든 만들어서 쓰는 경우가 많았다

대표적인 예가 이거였다.

• 이메일 발송 대상을 “큐 테이블”에 저장
• 크론/워커가 하나씩 가져가서 발송
• 발송이 완료된 항목만 문서 “완료 처리”

당시엔 그냥 “이게 제일 편해서”였다. 지금 와서 보니, 이건 전형적인 구조였다.

그때 내가 한 것	지금 보니
발송 대상 목록 저장	Job Queue
하나씩 실행	Worker
성공한 것만 완료 처리	State Transition
실패 기록 후 재시도	Retry 전략
TCP로 데이터 전달	Message Passing

큰 시스템을 안 쓴 게 아니라, 큰 시스템의 개념을 ‘작게’ 쓰고 있었다.

---

RabbitMQ를 “통신용”으로만 봤던 시절

RabbitMQ도 마찬가지였다. 예전에 나는 RabbitMQ를 이용해서 잡을 보내고, 받는 쪽에서 처리한 뒤 발송 상태를 DB에 저장하는 일을 한 적이 있다. (그리고 그 잡은 다른 서버로도 보낼 수 있었다.)

그때 나는 RabbitMQ를 이렇게 이해했다.

“아, 이건 통신용이구나.”

그런데 지금 와서 보니, 그건 맞지만 일부였다. 더 정확히는 이거였다.

“데이터를 보낸다”가 아니라
“실행해야 할 일을 위임한다(잡을 던진다)”

그리고 실행 결과(상태)는 RabbitMQ가 아니라 DB가 진실을 가진다. 나는 이미 그렇게 쓰고 있었다. 단지 그때는 “이름”을 깊게 생각하지 않았을 뿐이다.

---

그래서 왜 짜증이 나는가

결론적으로 내가 짜증나는 포인트는 이거다.

나는 “이름 붙은 개념”을 먼저 배우는 타입이 아니라
“문제를 풀고 구조를 만든 뒤에”
나중에 그 구조의 이름을 만나는 타입이다.

그런데 세상은 종종 이름부터 던진다.

• WAS
• Redis
• RabbitMQ

그래서 나는 본능적으로 묻게 된다.

“그게 뭔데? 왜 필요한데?”

그리고 대개 결론은 비슷하다.

“아… 내가 이미 하던 거네.”

---

Redis / RabbitMQ는 “필수 전제”가 아니라 “확장판”

여기서 중요한 결론 하나. Redis / RabbitMQ는:

• 없어서 못 쓰는 도구 ❌
• 있어야 시작 가능한 전제 ❌

대신 이쪽에 가깝다.

내가 이미 쓰고 있는 구조가 감당이 안 될 때 꺼내는 확장 도구

그래서 나는 이렇게 가는 게 맞다고 본다.

• 지금은 DB/파일/크론 등 “내가 통제 가능한 방식”으로 시작
• 복잡도/부하/확장 요구가 올라오면 Redis/MQ로 치환
• 핵심은 도구가 아니라 “구조(의도→실행→상태)”

---

마무리

오늘의 짜증은 “배워야 해서”가 아니라, 오히려 반대였다.

이미 알고 있는 것을, 이름만 바꿔서 다시 듣는 피로

그리고 이 결론은 나를 좀 편하게 만든다.

나는 도구를 외워서 쓰는 개발자가 아니라,
구조를 먼저 만들고 나중에 이름을 만나는 개발자다.

다음엔 아마 또 다른 이름을 만나겠지. 그때도 똑같이 물을 것 같다.

“그게 뭔데? 왜 필요한데?”