450ms 리트라이 간격이 카프카 리밸런스를 촉발하다

{

"deep_dive": [

{

"content": "이 사건은 암묵적 지식(Tacit Knowledge)과 명시적 지식(Explicit Knowledge)의 본질적 차이를 보여준다. Mark는 RabbitMQ Erlang VM의 GC 사이클을 이해한 엔지니어로, 450ms라는 숫자 뒤에 2주간의 부하 테스트(Load Testing)와 아키텍처 분석이 생략된 채 AI Skill에 전달되었다.\n\n• 문맥 의존성(Context Dependency): 450ms는 RabbitMQ 환경에서만 유효한 값이며, 코드의 주석(Note)에도 "450ms matches RabbitMQ GC window. Do not reuse outside this context"라고 명시되어 있었으나 마이그레이션 문서에는 미포함됨\n\n• AI Skill의 지식 구조: 312개 시나리오에서 패턴 매칭(Pattern Matching) 방식으로 진단을 수행하였으나, 인프라 변경( RabbitMQ → Kafka)을 감지하거나 전제 조건(Precondition)의 변화를 인식할 수 없었음\n\n• 유효성 검증 재실행(Re-validation) 부재: 플랫폼 리드(Platform Lead)가 모니터링 스택을 재구축한 후 유효성 검증 재실행 미시행으로 인해 AI Skill의 컨텍스트 무효화가 감지되지 않음\n\n결과적으로 AI Skill은 \"과거에 대한 정답\"을 저장한 시스템이지, \"현재 상황에 맞는 답\"을 생성하는 시스템이 아니었다는 점이 핵심 교훈이다."

}

]

}

RabbitMQ에서 Kafka로 마이그레이션하는 것은 많은 기업이 겪는 레거시 전환 패턴에 해당한다. 이 과정에서 생기는 지식 격차를 관리하기 위한 실무적 접근법은 다음과 같다.

이 사례에서 기업은 "12년 경력을 시스템에 담았다"고 생각했지만, 실제로는 기술적 결정의 이유까지 담아내지 못했다.

AI Skill 도입의 의사결정에는 명백한 비용 절감 효과와 함께 검토해야 할 비기능적 요구사항(Non-functional Requirements)이 존재한다. 이 사건에서 확인되는 핵심 트레이드오프는 다음과 같다.

따라서 AI Skill 도입 전, "이 시스템이 현재 인프라를 이해하고 있느냐"가 아니라 "이 시스템이 인프라 변경을 감지할 수 있느냐"를 질문해야 한다.

Mark의 450ms 리트라이 간격이 RabbitMQ에서 유효했던 것은 Erlang VM의 가비지 컬렉션 동작 방식과 밀접한 관련이 있다. RabbitMQ는 Erlang 프로세스 모델 기반으로 동작하며, 메시지 처리가 légères 프로세스(Lightweight Processes) 간 전달 방식으로 이루어진다.

이 두 시스템의 아키텍처적 차이를 인식하지 못한 채 "정답"을 복사한 것이 실패의 근본 원인이다.