해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 90 - Fighting fire with fire: Why we cannot always prevent technical issues with more tech
1. 무계획적 기술도입과 과잉 엔지니어링
새로운 기능을 개발하거나 버그를 수정해야 할 때, 우리는 종종 계획이나 문서화 단계를 건너뛰고 곧바로 코드를 짜거나 도구를 도입하려는 유혹에 빠진다.
이러한 '일단 만들자' 식의 접근은 초기에는 빠르게 보일지 모르나, 장기적으로는 심각한 부작용을 초래한다.
1-1. 이해할 수 없는 인프라와 전이적 의존성
문서화 없이 즉흥적으로(Ad-hoc) 문제를 해결하다 보면, 우리의 인프라는 마치 아이들의 장난감 블록처럼 변해버린다.
여러 구성 요소가 연결은 되어 있지만, 도대체 어떻게, 왜 연결되어 있는지 아무도 명확히 설명할 수 없는 상태가 되는 것이다.
이 과정에서 우리가 인지조차 하지 못하는 전이적 의존성 문제가 발생한다. 가장 대표적인 사례가 'left-pad' 사건이다.
-
사건 개요: 2016년, 한 개발자가 npm 및 'Kick'이라는 회사와의 이름 분쟁 끝에 홧김에 자신이 만든 패키지들을 npm에서 모두 삭제해버렸다.
-
영향: 그중 'left-pad'라는 패키지는 공백을 포함해 고작 11~12줄짜리 코드에 불과했지만, 수많은 대형 프로젝트들이 이 패키지를 간접적으로 의존하고 있었기에 전 세계 인터넷 서비스들이 줄줄이 마비되는 사태가 벌어졌다.
-
교훈: 내가 직접 사용하지 않더라도 내 프로젝트가 의존하는 도구가 또 다른 도구에 의존하고 있을 수 있다. 문서화와 파악이 되지 않은 의존성은 시한폭탄과 같다.
1-2. 과잉 엔지니어링의 늪
소프트웨어 개발 초기에는 기능적/비기능적 요구사항을 완벽히 알 수 없다.
문제는 원래 해결하려던 문제가 무엇이었는지에 대한 원본 기록이 없을 때 발생한다.
초기의 목적을 잊어버린 채 개발을 진행하다 보면, 단순한 해결책이 존재함에도 불구하고 불필요하게 복잡하고 정교한 솔루션을 만드는 과잉 엔지니어링(Over-engineering)에 빠지게 된다.
이는 시스템의 복잡도를 불필요하게 높여 유지보수를 어렵게 만든다.
1-3. "나한테 물어봐" 문화의 위험성
문서화가 부재한 조직에서 흔히 발생하는 또 다른 문제는 구전에 의존하는 온보딩이다.
팀장이나 시니어 엔지니어는 선의로 "문서는 내 머릿속에 다 있으니 모르는 게 있으면 언제든 물어봐"라고 말한다.
하지만 이는 친절해 보일지 몰라도, 실제로는 주니어 엔지니어나 신규 입사자의 자기 주도성을 뺏는 행위다.
스스로 정보를 찾아 해결할 수 없게 만듦으로써, 사소한 것 하나까지 질문해야 하는 의존적인 환경을 조성하고, 결국 팀 전체의 생산성을 저하시킨다.
2. 문서화 주도 개발의 가치와 전략
프레젠테이션에서는 기술적 문제 해결의 대안으로 문서화 주도 소프트웨어 개발을 제안한다.
문서화는 단순한 기록이 아니라, 비용을 절감하고 비즈니스 연속성을 보장하는 핵심 전략이다.
2-1. 문서화의 비즈니스적 가치
장애는 곧 돈이다.
2017년 영국 항공은 시스템 장애로 인해 약 8,000만 파운드(한화 약 1,300억 원 이상)의 손실을 입었다.
잘 정리된 런북(Runbook)과 장애 대응 문서는 온콜(On-call) 담당자의 스트레스를 줄여주고, 대응 시간을 단축시킨다.
특히 미들 레벨 엔지니어가 야간 장애 대응 시, 언제 시니어를 호출해야 할지 명확한 기준을 제공함으로써 심리적 안정감을 주고 불필요한 호출을 줄여준다.
2-2. 문서의 유형과 작성 전략
문서는 크게 개발자 문서(Developer Documentation)와 사용자 문서(User Documentation)로 나뉜다.
문서를 작성할 때는 독자의 경험 수준과 문서의 목적(설치, 업그레이드, 기능 활용 등)을 반드시 고려해야 한다.
-
튜토리얼/하우투(How-to): 특정 시나리오나 구현을 다루며, 수명이 짧을 수 있다.
-
공식 문서: 여러 유지보수자에 의해 장기간 관리되며, 보다 범용적인 설정을 다룬다.
[추천 프레임워크: Diátaxis]
발표자는 문서 작성의 체계를 잡기 위해 Diátaxis 프레임워크를 추천한다.
이는 문서를 4가지로 구분하여 작성하는 방식이다.
-
튜토리얼(Tutorials): 학습 지향 (직접 따라 하며 배우기)
-
하우투 가이드(How-to Guides): 문제 해결 지향 (특정 목표 달성)
-
설명(Explanation): 이해 지향 (배경 지식 및 개념 설명)
-
레퍼런스(Reference): 정보 지향 (API 명세 등)
2-3. 기술을 활용한 문서화: K8sGPT
문서화에도 기술을 접목할 수 있다.
K8sGPT 같은 도구는 SRE의 지식을 코드로 내재화하고 AI를 활용하여 쿠버네티스 클러스터의 문제를 진단하고 설명해 준다.
이는 마치 살아있는 문서처럼 작동하여, 주니어 엔지니어가 선배에게 묻지 않고도 에러의 원인과 해결책을 파악할 수 있게 돕는다.
3. 카오스 엔지니어링: 알 수 없는 것을 아는 것으로
마지막으로, 문서화와 프로세스의 중요성은 카오스 엔지니어링(Chaos Engineering)에 적용될 때 더욱 빛을 발한다.
카오스 엔지니어링은 시스템에 의도적인 결함을 주입하여 회복 탄력성을 테스트하는 것이다.
3-1. 지식의 4분면과 카오스 엔지니어링의 목표
우리가 시스템에 대해 아는 지식은 네 가지 영역으로 나뉜다.
-
Known Knowns (알고 있는 아는 것): 우리가 인지하고 이해하는 영역. (문서화 대상)
-
Known Unknowns (알고 있는 모르는 것): 문제는 인지했지만 원인은 모르는 것. (예: 스토리지 레이어에 이슈가 있다는 건 알지만 정확한 원인은 모름)
-
Unknown Knowns (모르고 있는 아는 것): 이해는 하고 있지만 인지하지 못한 것. (직관이나 경험적으로 대처 가능하나 명시되지 않음)
-
Unknown Unknowns (모르고 있는 모르는 것): 가장 위험한 블랙박스 영역. 인지조차 못하고 있는 잠재적 위험.
카오스 엔지니어링의 궁극적인 목표는 실험을 통해 Unknown Unknowns(블랙박스) 영역을 발견하고, 이를 실험을 통해 분석하여 Known Knowns(문서화된 지식) 영역으로 옮겨오는 것이다.
3-2. 실험의 프로세스와 사후 분석
성공적인 카오스 엔지니어링을 위해서는 다음과 같은 체계적인 프로세스가 필요하다.
-
매핑(Mapping): 현재 인프라의 상태와 서비스 간의 내/외부 의존성을 시각화하여 파악한다.
-
가설 수립 및 계획: "포드를 삭제하면 레플리카셋이 자동으로 복구할 것이다"와 같은 가설을 세우고, 폭발 반경(Blast Radius)을 최소화하여 실험을 설계한다.
-
실험 실행:
Chaos Mesh,LitmusChaos등의 도구를 활용한다. -
사후 분석(Post-mortem): 실험 후 무엇이 발생했고, 어떻게 대응했는지를 반드시 기록해야 한다. 이는 팀 전체의 학습 기회이자, 미래의 장애를 예방하는 자산이 된다.
(도구:incident.io,Rootly등 활용 가능)
3-3. 결론: "일단 적어라"
기술적 해결책을 찾기 전에 기록하는 습관을 들이라는 것이다.
잘못된 내용을 적는 것이 아무것도 적지 않는 것보다 낫다.
과거에 작동했던 명령어가 지금은 작동하지 않을지라도, 그것은 미래의 팀원에게 훌륭한 단서가 된다.
거창한 문서가 아니더라도, 홈랩(Home lab)이나 개인 학습 노트부터 시작하여 자신이 겪은 문제와 해결 과정을 기록하고 공유하는 것이야말로 진정한 엔지니어링의 시작이다.
4. 정리 및 결론
기술적 부채와 복잡성은 더 많은 도구가 아닌, 명확한 문서화와 체계적인 프로세스로 해결해야한다.
'일단 만들자'는 유혹을 뿌리치고, 우리가 아는 것과 모르는 것을 기록하며 Unknown 영역을 줄여나가는 것이 진정한 엔지니어링이다.
완벽한 문서를 쓰려 하기보다, 사소한 트러블슈팅 과정이라도 기록하고 공유하는 습관을 들여보자.
이러한 기록들이 모여 팀의 리스크를 줄이고, 더 견고하고 회복 탄력성 있는 인프라를 만드는 가장 강력한 무기가 될 것이다.
