90-90 규칙과 DevOps: 스프린트의 마지막 10%가 모든 것을 좌우하는 이유
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
DevOps
대상자
- DevOps 엔지니어, 소프트웨어 개발자, 프로젝트 매니저
- 난이도: 중간 (복잡한 시스템 설계와 DevOps 파이프라인 이해 필요)
핵심 요약
90–90 규칙은 "첫 90%의 코드는 90%의 개발 시간을 소모하고, 나머지 10%의 코드는 나머지 90%의 시간을 차지한다"는 관찰로, DevOps 파이프라인에서의 복잡성과 예상치 못한 문제를 설명- "최종 10%"는 보안 검토, IAM 감사, 환경 간 YAML 드리프트, 상태 비가역성, 파이프라인의 관찰성 부족 등 비코드 요소로 인해 발생
- DevOps 성공을 위해서는
- 관찰성 및 테스트 가능성으로부터 설계
- 인프라 코드화 및 버전 관리
- "완료"의 정의 확장 (문서, 모니터링, 가용성 테스트 포함)
- 서로 다른 팀 간 커뮤니케이션 강화
섹션별 세부 요약
1. 90-90 규칙의 기원 및 의미
- 90-90 규칙은 파레토 원칙과 호프스타터의 법칙과 연관됨
- 호프스타터의 법칙: "예상보다 항상 더 오래 걸린다"
- 실제 프로젝트에서의 경험을 기반으로 한 규칙으로, 복잡한 시스템의 예측 불가능성을 강조
2. DevOps에서의 "최종 10%"의 영향
- CI/CD 파이프라인 완료 후 추가 필요한 작업
- 보안 검토, 규제 준수 체크리스트, IAM 감사, 운영 팀 피드백, 비용 추정 검토, 비밀 관리 문제
- 자동화 파이프라인의 유지보수
- 환경 간 YAML 드리프트, 매개변수 불일치, 상태 비가역성, Terraform destroy 명령의 예기치 못한 동작
- 관찰성 시스템의 복잡성
- 로깅, 분산 트레이싱, 대시보드, 알림 임계값 설정
3. 생산성에서의 예상치 못한 문제
- 로컬에서 통과한 함수가 프로덕션에서 실패할 수 있는 사례
- 메모리 누수, 하중 시 확장성 문제, 에지 케이스의 정적 실패, 주간 비즈니스 로직 변경
- DevOps의 핵심은 단순히 코드 실행이 아닌
- 모니터링, 업데이트, 패치, 문서화, 검증, 퇴출 전략
4. 실무에서의 핵심 진실
- "알지 못하는 알지 못한 것"(unknown unknowns)이 주로 후반에 발생
- 통합 과정의 복잡도는 지수적 성장
- 코드 작성은 쉬우나, 유지보수는 어렵다
- "완벽함"은 규제 산업에서는 "충분히 좋다"의 적대자
5. 실무 적용을 위한 5가지 전략
- 관찰성 및 테스트 가능성으로부터 설계
- 모니터링, 로깅, 분산 트레이싱을 초기 설계에 포함
- 인프라 코드화 및 버전 관리 강화
- CI/CD 파이프라인 코드와 동일한 테스트 수준 유지
- "완료"의 정의 확장
- 문서, 알림, 메트릭, failover 테스트 포함
- 혼돈 공학(Chaos Engineering) 적용
- 제어된 환경에서 프로덕션 문제를 조사하여 의존성 파악
- 크로스펑셔널 팀 간 커뮤니케이션 강화
- 개발자(기능), 운영자(가용성), 보안팀(위험) 간 협업 필수
결론
- 90-90 규칙을 극복하려면
- 관찰성과 테스트 가능성으로부터 설계
- 인프라를 코드로 관리하고 버전화
- 혼돈 공학과 실시간 모니터링 도구 활용
- "완료"는 단순한 코드 배포가 아닌, 지속 가능한 시스템 설계로 확장되어야 한다.