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와 플랫폼 엔지니어링의 변화는 소프트웨어 개발 및 운영 분야의 지속적인 학습과 적응의 중요성을 강조함. 기술자들은 새로운 도구와 방법론에 대한 학습뿐만 아니라, 비즈니스 요구사항과 기술적 복잡성 사이의 균형을 맞추는 능력을 개발해야 할 것
-
향후 소프트웨어 개발 및 운영 방식은 더욱 유연하고 상황에 맞는 접근법을 채택할 것으로 예상됨. 대규모 조직과 소규모 스타트업이 동일한 방식을 따르는 것이 아니라, 각자의 상황에 맞는 최적의 프로세스와 도구를 선택하는 추세가 강화될 것