유지보수의 핵심은 코드? NO! 팀의 '이해'!
유지보수는 코드 문제로 치부되지만, 실제는 시스템에 대한 팀의 이해도(Team Understanding)가 핵심임
엔지니어는 로그, 대시보드, 코드를 통해 시스템을 간접적으로 접하며, 표현과 현실의 괴리(Representation Drift)가 문제 발생의 원인임
사고 발생 시, 명확한 소통(Clear Communication)이 기술적 정확성만큼 중요하며, 팀 간의 조율이 핵심임
측정 불가능한 요소(Unmeasurable Factors)를 고려하여, 경험과 판단을 통해 유지보수해야 함
표현과 현실의 괴리(Representation Drift)와 팀의 이해도
본질적으로 엔지니어는 시스템을 직접 다루지 않고, 로그, 대시보드, 코드를 통해 간접적으로 시스템을 이해한다. 이러한 표현(Representation)은 현실의 근사치이며, 괴리가 발생하면 팀의 공통된 이해(Shared Understanding)가 무너진다. 이는 사고 발생 시 더욱 두드러지며, 사고 지휘관(Incident Commander)의 역할은 통제가 아닌 조율에 있다. 특히, 데이터 격리 아키텍처(Data Isolation Architecture)를 구축하지 않은 시스템에서는 이러한 괴리가 더욱 심화될 수 있다.
측정 가능한 지표(Metrics)의 한계와 경험의 중요성
SLO(Service Level Objectives)는 고객 facing 문제를 해결하는 데 도움을 주지만, 내부적인 명확성이나 팀 간의 정렬을 포착하지 못한다. W. Edwards Deming의 말을 인용하면, 모든 중요한 것은 측정될 수 없다. 고성능 팀은 종종 판단, 경험, 그리고 공유된 맥락에 의존한다. 따라서, 데이터 미저장 정책(Zero-Retention Policy)을 통해 보안을 강화하는 것만큼이나, 팀의 경험과 판단을 존중하는 것이 중요하다.
사고(Incident)의 근본 원인과 인간의 행동
사고는 단순한 실수로 인해 발생하는 것이 아니라, 성공적인 결과를 이끌어내는 행동이 다른 조건에서 나타난 결과이다. Sidney Dekker의 'The Field Guide to Understanding Human Error'를 인용하며, 복잡한 시스템에서 유지보수는 이해를 유지하는 것에 달려있음을 강조한다. 즉, 멀티모달 분석(Multimodal Analysis)을 통해 문제의 근본 원인을 파악하고, 팀의 학습을 통해 지속적으로 개선해야 한다.
