DevOps가 직위가 아니라고?

xgro·2022년 5월 1일
0

DevOps

목록 보기
3/9

📌 DevOps는 직위인가?

  • DevOps는 하나의 역할로 한정되지 않습니다.
  • 애플리케이션 수명 주기 단계에 참여하는 모든 구성원이 DevOps 문화를 포용해야 합니다.
  • 조직에 자동화를 지원하고, 구현 방식을 정의하고, CI/CD 파이프라인을 구현하는 일을 전담하는 담당자 또는 팀이 있는 경우가 있을 수 있습니다. 이러한 역할의 공식 직함이 DevOps 엔지니어 또는 DevOps 스페셜리스트인 경우도 있습니다.

📌 DevOps가 직위가 아니라면, 나는 어떤것을 준비하고 있는것인가?

  • 채용 사이트만 보아도 DevOps 직무를 수행하는 인력을 뽑고 있다. 하지만 DevOps에 대해서 정리하면 할 수록 DevOps는 직무가 아니라고 한다.

  • DevOps에 대해서 보다 정확하게 정의하고, 그 속에서 어떤 역할(Role)을 해야하는지 명확히 해야 될 것 같다.

📌 DevOps 문화로 전환 시 고려 사항

👉 개방형 커뮤니케이션

  • DevOps가 해결하고자 하는 가장 근본적인 과제는 서로 다른 조직 단위의 지식, 경험 및 작업의 사일로화를 막는 것입니다.
  • 코드를 작성하는 프로그래머와 코드를 배포하고 유지 관리하는 시스템 관리자가 소통하지 못하면 비효율적일 가능성이 높습니다.

**사일로화란?

조직 내 각 부서간의 독립성을 가지며 운영되지만 배타적인 특징 때문에 부서이기주의 등을 나타내는 용어**

경영학적 용어로 사일로 효과(Silo Effect)**라는 것이 있는데, 이는 사일로라는 원래의 형태에서 파생된 것으로 높이 솟은 굴뚝 모양의 저장소에 곡물이 차곡차곡 쌓이면 아래로 다 내려갈 때까지 잘 섞이지 않는 특성을 빗대어 가리키는 것


👉 실수할 기회

  • 많은 조직, 팀 및 개인은 실수를 절대로 저지르지 않도록 자신과 서로에게 엄청난 부담을 가하고 있습니다.
  • 실패가 허용되지 않는 경우, 개인이나 팀이 문제를 해결하거나 혁신적인 기능을 개발하기 위해 새로운 접근 방식을 시도할 가능성이 낮습니다.
  • 이 사고 방식은 "평균 복구 시간"(MTTR)보다 "평균 고장 간격"(MTBF)을 더 중요하게 측정했던 과거의 집착에 반영되어 있습니다.
  • MTBF는 "근본 원인" 분석과 같은 도구를 사용하여 고장의 원인을 식별하고 실패가 다시 발생하지 않도록 방지합니다.
  • MTTR은 소프트웨어 애플리케이션을 예측할 수 없는 방식으로 장애가 발생하기 쉬운 복잡한 시스템이라고 보며, 장애가 발생할 경우 신속한 복구에 중점을 둡니다.
  • “비난을 배제한 회고”는 DevOps 문화에서 흔히 볼 수 있는 기능입니다.
  • 스프린트 또는 프로젝트가 끝날 때 팀이 회의를 통해 잘 진행된 부분과 개선할 부분에 대해 개방적이고 안전한 환경에서 논의할 때 결과를 개선할 수 있습니다.
  • 실패에 대해 비난 없는 견해는 실수가 발생한다는 것을 인정하지만 사용자와 조직 모두 학습, 성장, 개선할 수 있다는 가정 하에 운영되는 성장의 사고 방식을 채택하기 때문에 효과적입니다.- Jennifer Davis 및 Katherine Daniels의 "Effective DevOps"
    출처 - https://www.atlassian.com/ko/devops/what-is-devops/devops-culture

DevOps는 단순히 CI/CD 툴만 다룰수 있다고 할 수 있는 것이 아니다.

확실하게 짚고 넘어가야 되는 것은 DevOps"문화"라는 것이다. 지속적인 통합(Continuous Integrate)과 전달(Continuous Delivery)을 통해서 자동화된 배포 환경(Continuous Deploy)을 구축하고, 그안에서 개발팀과 운영팀이 소통하여 제품을 발전시켜 나아가는 업무 방식.

다행히(?)도 DevOps를 위해서는 회사차원에서 문화적인 변화도 있어야 하지만, 이를 구축하기 위한 엔지니어의 역할도 존재한다.

📌 DevOps 엔지니어란 누구입니까?

출처 - https://www.atlassian.com/ko/devops/what-is-devops/devops-engineer

DevOps 엔지니어는 코딩, 인프라 관리, 시스템 관리 및 DevOps 도구 체인을 포함하여 개발 및 운영에 대한 광범위한 지식을 갖춰야 하는 IT 전문가입니다. DevOps 엔지니어는 공동 작업에 더 적합한 환경을 만들기 위해 사일로 전반에서 작업하므로 대인 관계 스킬을 보유해야 합니다.

👉 커뮤니케이션 및 협업

  • DevOps 엔지니어는 팀, 관리자 및 고객과 효과적으로 커뮤니케이션하고 공동 작업해야 합니다. 소위 “소프트 스킬”은 간과되고 저평가되는 경우가 많지만, DevOps의 성공은 전체 가치 흐름에서 피드백의 품질과 양에 크게 좌우됩니다.

👉 시스템 관리

  • DevOps 엔지니어는 서버 프로비저닝 및 관리, 데이터베이스 배포, 보안 모니터링, 시스템 패치 적용, 내부 및 외부 네트워크 연결 관리와 같은 시스템 관리 경험을 갖게 됩니다.

👉 DevOps 도구 관련 경험

  • DevOps 관행에는 올바른 도구를 사용하는 것이 필수이므로, DevOps 엔지니어는 다양한 도구를 이해하고 사용할 수 있어야 합니다. 이 도구는 인프라 및 구축부터 제품 또는 서비스 모니터링 및 운영에 이르기까지 DevOps 수명 주기 전반에 걸쳐 있습니다.

👉 구성 관리

  • DevOps 엔지니어는 Chef, Puppet, Ansible과 같은 하나 이상의 구성 관리 도구와 관련된 경험을 쌓아야 하는 경우가 많을 것입니다. 많은 조직에서는 새로운 시스템을 배포하거나 이미 실행 중인 시스템에 보안 패치를 적용하는 등 시스템 관리 작업을 자동화하기 위해 이 도구 또는 비슷한 도구를 채택하고 있습니다.

👉 컨테이너 및 컨테이너 오케스트레이션

  • Docker가 널리 보급한 기술인 컨테이너화를 사용하면 애플리케이션 코드와 런타임 환경을 동일한 이미지에 번들로 제공합니다. 따라서 기존 구성 관리 도구의 필요성이 줄어듭니다. 동시에, 컨테이너 관리에는 자체적인 어려움이 있으며 “컨테이너 오케스트레이터"(예: Docker Swarm 또는 Kubernetes)라고 알려진 도구와 관련된 경험은 DevOps 엔지니어에게 필요한 스킬이 됩니다.

👉 지속적 통합 및 지속적 배포

  • 지속적 통합 및 지속적 배포(CI/CD)는 소프트웨어 개발에 대한 DevOps 접근 방식의 핵심 관행이며 사용 가능한 여러 도구를 통해 지원됩니다. CI/CD 도구 또는 도구 세트의 가장 기본적인 기능은 소프트웨어 구축, 테스트 및 배포 프로세스를 자동화하는 것입니다.
  • DevOps 엔지니어는 일반적으로 하나 이상의 CI/CD 도구를 구성하고 배포하는 경험이 필요하며, 일반적으로 이 도구가 효과적으로 사용될 수 있도록 나머지 개발 조직과 긴밀하게 협력해야 합니다.

👉 시스템 아키텍처 및 프로비저닝

  • DevOps 엔지니어는 온프레미스 또는 클라우드에서 컴퓨터 에코시스템을 설계, 프로비저닝 및 관리할 수 있어야 합니다.
  • DevOps 소프트웨어 개발에서 클라우드 인프라 리소스의 관리에 이르는 모범 사례를 적용하는 IaC(Infrastructure as Code)라는 IT 관리 프로세스를 이해하는 것이 중요합니다.
  • DevOps 엔지니어는 Amazon Web Services(AWS), AWS CloudFormation 또는 Terraform을 사용하여 클라우드에서 시스템 인프라를 모델링하는 방법을 이해해야 합니다.

👉 코딩 및 스크립팅에 익숙

  • 많은 기존 시스템 관리자는 반복 작업을 자동화하기 위해 셸 스크립트를 작성한 경험이 있습니다.
  • DevOps 엔지니어는 자동화 스크립트 작성에 그치지 않고 고급 소프트웨어 개발 관행과 코드 검토 및 소스 제어 사용과 같은 애자일 개발 관행을 구현하는 방법을 이해해야 합니다.

👉 공동 작업 관리 스킬

  • 교차 팀 공동 작업은 특정 조직 구조와 관계없이 효과적인 DevOps 전략의 기본적인 구성 요소입니다.
  • 엔지니어링 팀이 역할로만 구분된 그룹이든 또는 기능 개발, 품질 보증, DevOps 등을 위한 별도의 팀이 있든 관계없이, DevOps 엔지니어는 다양한 구성원과 함께 코치 및 동료로서 조직 전체에서 일해야 합니다.
  • DevOps에 투자에서 얻는 가장 가치 있는 효과는 개발자에게 더 빠른 피드백을 제공하는 기능입니다.
  • DevOps 엔지니어는 테스트 방법론의 속도, 효율성 및 결과를 개선하기 위해 QA(수동 테스터 또는 테스트 자동화를 작성하는 개발자 모두)와 협력해야 하는 경우가 많습니다.
  • 동시에 개발자는 애플리케이션 코드를 만들고 배포하는 프로세스를 개선하기 위해 작업할 때 DevOps 엔지니어의 지원이 필요할 수 있습니다.
profile
안녕하세요! DevOps 엔지니어 이재찬입니다. 블로그에 대한 피드백은 언제나 환영합니다! 기술, 개발, 운영에 관한 다양한 주제로 함께 나누며, 더 나은 협업과 효율적인 개발 환경을 만드는 과정에 대해 인사이트를 나누고 싶습니다. 함께 여행하는 기분으로, 즐겁게 읽어주시면 감사하겠습니다! 🚀

0개의 댓글