GN⁺: DevOps에 대한 추도사
(matduggan.com)DevOps의 개념과 역사
- DevOps는 2007년경 도입된 개념으로, 하드웨어를 관리하는 사람들과 소프트웨어를 작성하는 사람들 간의 구분을 없애는 것을 목표로 함
- 초기에는 NASA의 절차와 아이디어를 모방하여 코드 배포의 안전성을 높이려는 시도였음
- 당시 소프트웨어 배포 과정은 다음과 같았음:
- 개발팀이 서버 소프트웨어의 릴리스를 준비하고, QA 팀이 테스트한 후 고객에게 배포
- 운영팀은 소프트웨어 변경 사항과 문제 발생 시 대처 방법을 포함한 플레이북을 받음
- 데이터 센터 내에서 점진적으로 업데이트를 롤아웃하며 모니터링
- 배포일을 정하고, 배포 후 모니터링
DevOps의 문제점
- DevOps는 매우 노동 집약적이었음
- 개발팀, QA 팀, 기술 작가, 운영팀 간의 협력이 필요했음
- 기능 배포가 느렸고, 중요한 업데이트가 우선시되었음
- 많은 조직들이 DevOps를 도입한 이유는 다음과 같았음:
- 기술 인력을 쉽게 대체할 수 없었음
- 채용이 어렵고 비용이 많이 들었음
- SaaS 벤더들이 복잡성을 줄여주었음
- 클라우드 플랫폼의 장점을 강조했음
- 개발자들이 작은 변경 사항이 배포되기까지 오랜 시간이 걸리는 것에 불만을 가졌음
DevOps의 실제 모습
- DevOps는 개발팀과 운영팀이 하나의 팀으로 통합되는 것을 목표로 함
- QA 팀이 해고되고, 빠른 배포와 피드백을 통해 내부 테스트 기간이 줄어듦
- DevOps는 Google의 SRE와 혼동되기도 하지만, SRE는 더 구조적이고 엄격한 접근 방식을 가짐
- DevOps의 실제 프로세스는 다음과 같음:
- 개발자가 git에서 브랜치를 만들고 기능을 추가
- PR을 열고 팀원이 검토 후 main에 병합
- CI/CD 시스템이 빌드를 시작하고, 컨테이너를 레지스트리에 푸시
- CD 시스템이 서버에 새로운 릴리스를 알리고, 배포 성공 여부를 모니터링
- 릴리스 인식 메트릭스를 통해 배포 후 변화를 모니터링
DevOps의 실패 요인
- 개발자들이 로컬 환경에서 테스트하고, Linux 서버에 배포하면서 작은 차이점이 발생
- 운영팀이 배포를 모니터링하지 않아 문제 해결이 어려웠음
- 개발자들이 시스템 운영에 대한 지식이 부족했음
- 컨테이너의 도입으로 일부 문제는 해결되었지만, 운영의 복잡성은 여전히 존재했음
컨테이너의 도입과 한계
- 컨테이너는 "내 컴퓨터에서는 잘 작동했는데" 문제를 해결했음
- Linux 서버 구성 요소를 단순화했음
- 여전히 남은 문제들
- 운영(Operate): 인프라 유지보수, 업그레이드 등 전문성 요구
- 관찰(Observe): 복잡한 모니터링 시스템 구축 및 관리의 어려움
- 지속적 피드백: 내부 피드백 처리의 미흡
- 발견(Discover): 팀 간 지식 공유 부족
- 계획(Plan): 중앙화된 계획 수립의 어려움
Platform Engineering의 등장
- Platform Engineering은 DevOps의 후속 개념으로, 개발팀이 플랫폼 운영을 이해하고 문제를 해결하는 대신, 플랫폼 팀이 이를 담당함
- 이 접근 방식은 개발팀과 플랫폼 운영의 책임을 명확히 분리하여 역할 분담을 명확히 하지만, 여전히 많은 기술을 요구함
- 개발자와 운영팀 모두 더 많은 작업을 해야 함
결론
- 인프라 공간에서 단순하고 플랫폼에 종속되지 않은 도구를 찾는 경향이 증가하고 있음
- 많은 조직들이 Kubernetes와 같은 복잡한 기술을 포기하고, 간단한 워크플로우로 돌아가고 있음
- Platform Engineering은 만능 해결책이 아니며, 조직은 실제 필요한 것과 불필요한 것을 구분해야 함
- DevOps 접근 방식의 장점을 유지하면서 단순화와 안정성에 초점을 맞춰야 함
GN⁺의 의견
-
DevOps의 진화와 현재 상황은 기술 산업의 트렌드 변화를 잘 보여주는 사례임. 초기의 이상적인 목표와 현실 사이의 간극을 인식하고 실용적인 접근방식을 찾아가는 과정이 흥미로움
-
플랫폼 엔지니어링으로의 전환은 DevOps의 한계를 인정하고 새로운 해결책을 모색하는 시도로 보임. 그러나 이 역시 완벽한 해결책이 아니며, 조직의 규모와 특성에 맞는 맞춤형 접근이 필요할 것
-
클라우드 네이티브 기술과 마이크로서비스 아키텍처의 복잡성이 증가하면서, 단순성과 안정성에 대한 재평가가 이루어지고 있음. 이는 기술 선택에 있어 비즈니스 가치와 운영 효율성을 더욱 중요하게 고려해야 함을 시사함
-
DevOps와 플랫폼 엔지니어링의 변화는 소프트웨어 개발 및 운영 분야의 지속적인 학습과 적응의 중요성을 강조함. 기술자들은 새로운 도구와 방법론에 대한 학습뿐만 아니라, 비즈니스 요구사항과 기술적 복잡성 사이의 균형을 맞추는 능력을 개발해야 할 것
-
향후 소프트웨어 개발 및 운영 방식은 더욱 유연하고 상황에 맞는 접근법을 채택할 것으로 예상됨. 대규모 조직과 소규모 스타트업이 동일한 방식을 따르는 것이 아니라, 각자의 상황에 맞는 최적의 프로세스와 도구를 선택하는 추세가 강화될 것
꽤나 자주
관리자들이
데브옵스라는 개념만 도입하면
노력없이 대단한 혁신이 나타날것이라고
기대하는 (대기업 중소기업을 막론하고)
낡은 기업들의 잘못된 생각
Hacker News 의견
-
"devops cycle" 다이어그램에서 "build, test, deploy"에 집중하는 것이 핵심임
- 속도에 중점을 두었으며, 엔지니어링 우수성은 고려하지 않았음
- 운영 팀을 해고하고 QA를 재구성함
- 모든 팀이 온콜 로스터를 가지게 되었음
- 단기적인 이익을 위해 시스템에 혼란스러운 변화를 주었음
- 몇 달 후에는 변경할 때마다 문제가 발생함
- devops 도구는 유용했지만, 비용이 많이 들고 좌절감을 주었음
- 새로운 개발자들은 devops를 모르지만 컨테이너를 알고 있음
-
devops 팀이 겪은 문제에 기반한 의견임
- 새로운 서비스를 추가하고 인프라를 안전하게 관리할 수 있어야 함
- devops는 표준이 되었으며, 수동적인 시스템 관리자 작업은 필요하지 않음
-
Kubernetes에 대한 비판은 잘못된 것임
- Kubernetes는 훌륭한 소프트웨어 엔지니어링의 예이며, 잘 지원되고 어디서나 실행됨
- 무작위로 bash 스크립트를 사용하는 대신 Kubernetes를 배우는 것이 좋음
-
devops는 소프트웨어 배포를 더 쉽게 만들기 위해 장벽을 제거하는 것임
- 일일 배포는 더 높은 품질의 코드를 배포하는 데 도움이 됨
- 코드가 준비되었을 때만 배포할 수 있는 옵션이 중요함
- 월간 릴리스는 압박감을 주어 비효율적인 선택을 초래할 수 있음
-
devops는 철학이지 방법론이 아님
- 운영을 SDLC에 통합하는 것이 목적임
- 클라우드가 이를 더 쉽게 만들었음
- "DevOps" 팀이 생기면서 본래의 철학이 왜곡되었음
-
리더십의 "사일로를 허물기"는 거의 형식적인 것임
- 책임이 없는 권한은 효과가 없음
- 최고의 devops 인재는 자신을 코드로 대체하는 것을 즐김
- devops 도구는 성숙하고 잘 문서화되어 있음
- Kubernetes를 배우지 않는 개발자는 Linux 명령어를 모르는 개발자와 같음
-
사용자가 테스터가 될 수 있다면 그렇게 해야 함
- 경제적인 문제만 존재함
- 고객이 많으면 사용자가 테스트를 하게 하고, 고객이 적으면 직접 테스트해야 함
-
플랫폼 팀은 대기업에서만 가능함
- 중소기업은 devops 인력이 부족하여 스트레스와 위험을 감수해야 함
- 플랫폼 팀의 부재는 많은 문제를 초래함
-
devops는 철학이지 방법론이 아님
- 사일로 팀에서의 경험이 devops의 필요성을 증명함
- devops는 팀이 프로젝트를 완전히 이해하고 배포할 수 있게 함
-
devops는 좋은 의도를 가지고 있음
- 빠른 피드백 루프가 개발 속도에 중요함
- 조직과 제품에 맞는 최적의 솔루션을 찾아야 함