Kafka를 배우면서 가장 힘들었던 점 – 개념이 아니라 ‘맥락’이었다

1. 개념은 이해했는데, 왜 확신이 생기지 않았을까

Kafka의 기본 개념 자체는 난이도가 아주 높다고 느끼지는 않았다.
문제는 자료의 성격이었다.

같은 질문이라도

• A 관점에서 물으면 A가 정답처럼 보이고
• B 관점에서 물으면 B가 또 정답처럼 보였다.

둘 다 틀렸다고 말할 수는 없는데,
어느 쪽이 “지금 상황에서의 사실”인지는 판단하기 어려웠다.

AI를 통해 학습하면서 이 현상은 더 강해졌다.
답변은 항상 논리적으로 맞는 것처럼 보였지만,
그 답이 전제 조건을 포함한 답인지,
아니면 일반론인지 구분하기가 쉽지 않았다.

결과적으로

이해는 한 것 같은데, 확신은 전혀 생기지 않는 상태
에 머물렀다.

---

2. Kafka 자체보다 더 무거웠던 것은 ‘사용되는 맥락’

Kafka를 사용하는 대부분의 사례는
대규모·대용량 데이터를 전제로 한다.

내가 다루던 업무 역시
데이터 유실이 단 한 건도 허용되지 않는 상황이었다.

개인적으로 데이터에 특별한 애착이 있는 것은 아니었지만,
업무 특성상

• “한 번 날아가도 다시 만들 수 있는 데이터”가 아니었고
• “나중에 보정하면 되는 데이터”도 아니었다.

이 때문에
Kafka 설정 하나하나가 단순한 옵션 선택이 아니라
리스크를 선택하는 행위처럼 느껴졌다.

---

3. 생각보다 방대한 세계 – 옵션이 아니라 ‘산맥’들

처음에는 이렇게 생각했다.

“코드 구현이 많지 않으니,
옵션 조합만 잘 맞추면 되겠지.”

하지만 실제로는 달랐다.

Kafka의 옵션들은

• on / off
• a, b, c 중 선택

이런 수준이 아니었다.

하나의 옵션은
**수많은 전제와 동작 방식을 포함한 ‘산맥’**에 가까웠다.

A 옵션도 하나의 산맥이고,
B 옵션도 또 다른 산맥이었다.

React에서 JSX나 props가 처음 어려웠던 경험이 있지만,
그때와는 급이 다른 복잡함이었다.

---

4. 가장 힘들었던 지점: 눈에 보이지 않는 진짜 원인

에러는 발생했다.
예를 들어 “테이블의 ID를 찾을 수 없다”는 식의 에러였다.

처음에는

• 컬럼이 없나?
• 매핑이 틀렸나?

라고 생각했지만,
실제 원인은 스키마에서 기본적으로 소문자 id가 존재하고,
내가 설정한 ID와 대소문자 구분 충돌이 발생한 것이었다.

이 문제를 해결하기 위해

• 스키마 off를 시도했지만 로직이 맞지 않아 동작하지 않았고
• 결국 스키마 구조를 평탄화하고
• 소문자 id를 제거한 뒤 SEQ 기반 컬럼으로 변경하여 해결했다.

이 과정에서 느낀 점은 이것이었다.

하나의 문제를 풀기 위해
주변의 여러 맥락을 전부 이해해야 하는 경우가 있다.

추정 원인들이

• 하나만 맞는 것도 아니고
• 전부 다 원인인 경우도 있었으며
• 서로 강하게 연결되어 있었다.

결국
다 알아야 하나가 풀리는 문제였다.

---

5. 그래서 Kafka가 어려웠던 이유

Kafka가 어려웠던 이유는

• 개념이 난해해서도 아니고
• 문서가 부족해서만도 아니었다.

맥락 의존적인 판단을 요구하는 기술이었기 때문이다.

이 경험은
앞으로 Kafka를 다룰 때뿐 아니라
다른 분산 시스템을 바라보는 기준도 바꾸어 놓았다.

 

이 경험 이후로 Kafka 설정을 볼 때
“이 옵션이 무엇을 하는가”보다
“이 옵션이 어떤 전제를 요구하는가”를 먼저 보게 되었다.

정답을 찾기보다
지금 시스템의 조건에서
허용 가능한 리스크가 무엇인지를 먼저 정의하는 쪽으로
사고 방식이 바뀌었다.