Chuseok-Power-Outage-Recovery.md 사건(정전 → multipass/k3s 자동 복구 → threat-intel-ai-service Kafka consumer만 영구 다운 → 재시도 로직 부재 발견 → 수정 → livenessProbe도 못 잡던 문제까지 발견해서 수정) 대응을 마치고 나서, 지금까지의 세션 전체를 돌아보며 정리한 자기 점검이다. 기술 부채나 프로젝트 갭이 아니라 작업 방식/습관 쪽 회고이므로, 다른 *-Assessment.md 문서들과 마찬가지로 여기 남겨둔다.
지금까지 추가된 방어선을 시간순으로 나열하면:
ai-health-check.yml 추가/health가 상태와 무관하게 항상 200이라 애초에 이 문제를 k8s가 못 잡았다는 것도 발견 → livenessProbe를 /live로 분리공통점: 전부 사고가 실제로 터진 다음에 방어선이 생겼다. 사고→포스트모템→개선 사이클 자체는 정상적인 엔지니어링 습관이지만, 패턴만 놓고 보면 "이게 실패하면 어떻게 되지?"를 설계·구현 시점에 미리 상상해보는 연습이 상대적으로 약하다는 신호다. Kafka consumer의 connect-retry 같은 건 사실 프로덕션 컨슈머 코드의 기본값에 가까운데, 처음 짤 때는 없었다.
정전 복구 과정에서: "서버가 이상하다", "원인이 배터리 방전이다" 같은 진단과 방향 설정은 본인이 정확히 했다. 하지만 실제로 물리 호스트(macbookair, 100.112.104.24)를 특정하고, SSH로 들어가고, multipass list/kubectl get pods/kubectl rollout restart/argocd.argoproj.io/refresh 같은 명령을 타이핑한 건 전부 AI 세션 쪽이었다.
이 인프라(k3s 3노드 + ArgoCD GitOps + Kafka + Qdrant + 멀티 서비스)를 설계한 사람은 본인인데, 그걸 손으로 직접 운영해본 실습량이 설계·의사결정 역량 대비 상대적으로 적을 수 있다. 포트폴리오/면접에서 "이 클러스터 장애 대응 직접 해보셨어요?"라는 질문에 이번 복구 과정을 스스로 재현할 수 있는지가 실질적인 차이를 만든다.
이번에 추가한 새 코드(run_consumer() 재시도 루프, /live 엔드포인트) 둘 다 테스트를 같이 작성했지만, 그 테스트도 전부 AI 세션이 짰다. "이 코드가 깨지면 어떻게 알아챌까"를 구현 전에 먼저 스스로 묻는 습관이 있었다면, 이번 사고들 중 상당수(특히 재시도 로직 부재, /health가 상태를 반영 안 하는 문제)는 애초에 리뷰/설계 단계에서 걸러졌을 가능성이 크다.