DevOps 문화 그리고 이야기

들어가며

DevOps를 알게 된 건 AWS 컨퍼런스에 갔다. 알게 되었다. 처음에는 DevOps가 뭔지도 모르고 그냥 가만히 앉아서 기조연설을 듣는데 AWS Container Hero 송주영 님이 나와서 이야기하는데 내용이 정말 재미있고 나중에 더 깊게 들어가 보고 싶었다. 그러한 이유는 보안 관련 내용도 있고 문화에 대한 내용을 말하는데 단순 개발이 아니라 문화와 철학이 있다는 게 정말 신기했다.

DevOps 문화

DevOps가 철학과 방법론이기 때문이다. 해석과 응용이 존재하기 때문이다. 그래도 많은 분들이 DevOps가 도대체 무엇이냐 그러면 도대체 정확한 정의가 무엇이고 무엇을 하는 거냐라는 이야기를 많이 한다. DevOps를 한 단어로 설명하기는 매우 어렵다고 한다. 송주영 님의 강의에 따르면 ‘인간은 포유류다’라는 정의가 잘못된 정의는 아니지만 올바른 정의가 아닌 것과 같은 이치라고 한다. 송주영 님은 이럴 때마다 항상 다섯 가지 단어를 이용해서 설명한다고 한다. DevOps는 문화이고 자동화하는 것이며 항상 측정하고 서로 투명하게 공유하고 이 모든 것들이 축적해 나가는 것이다.

데브옵스는 어떤 요구사항을 효율적으로 만족시키기 위하여 일을 자동화하며 변경 사항 지표들을 측정하고 공유하고 이 모든 결과물을 지속해서 축적해 나가는 문화를 만들어 가는 철학 방법론 기술

철학

문화 (Culture) = DevOps를 통해 하나의 문화를 만들어 나간다.

• 사람 = 팀, 인원, 가치, 의사소통
• 일(Task) = 프로세스, 방법론
• 서비스 = 서비스의 가치, 성격
• 자원 = H/W, S/W, 기술, 도구
• 시간 = 일정, 변경 가능성, 회복탄력성, 예측

자동화 (Automation) = 자동화를 통해 효율성과 빠른 속도를 지향 한다.

• 인프라 및 보안 = 클라우드, 네트워크, 접근제어, 암호화
• 언어 및 도구 = 프로그래밍 및 도구
• 지속적 통합 / 배포 = CI/CD 파이프라인 구성 고려
• 모니터링 = 모니터링 시스템 및 장애대응

측정 (Measurement) = 지표를 측정하여 지속적으로 개선해 나간다.

• 변경사항 발생 시 항상 측정
• 어플리케이션 성능, 개발속도 모니터링
• 지속적으로 나아지고 있는지, 아닌지 측정
• 의사결정 시 추측 배제

공유 (Sharing) = 공유를 통해 함께 발전해 나간다.

• 언제든 접근 가능한 투명한 데이터
• 지식의 공유 OpenMind
• 문제 발생시 함께 해결
• 일의 가속도

축적 (File up & Pile up) = 기록을 축적하여 자신을 만들어 나간다.

문화

우선 문화 이야기를 하자면 문화를 이루는 구성요소에 대해 알아보자면 첫번쨰 사람이 있다. 사람이 모여 팀이 존재하고 인원이 몇명인지 그 팀의 가치가 무엇인지 그리고 사람들 간의 의사소통도 구성요소로 볼 수 있다. 그리고 일이 있다. 일을 위한 프로세스가 있고 방법론등이 있다. 이를 어떤 방식으로 하느냐에 따라서 문화가 완전 달라진다.

서비스의 방향성 혹은 가치에 따라서 문화가 만들어지기도 하고 심지어 하드웨어 소프트웨어 유무형의 기술도 문화의 한 부분이 될 수 있다. 그러한 이유는 기술의 성숙도가 존재하기 때문이라고 한다. 다음은 시간이다. 일정에 따른 변경 가능성 등 주어진 시간에 따른 퍼포먼스로 기업문화가 변화하고 진화한다. 현대의 서비스에서 속도라는 단어가 가장 화두인 이유이기도 하다. 따라서 올바른 기업 문화를 갖는것이 가장 중요하다고 한다. 좋은 문화를 만드는 것은 매우 복잡하고 어렵다.

자동화

자동화는 말 그대로 업무를 자동화 하는 것 이다. 자동화를 통해 속도, 안정성 등을 갖출수 있고 프로그래밍 언어와 도구를 통해 자동화를 하고 재사용 가능한 인프라를 만든다. 지속적통홥 및 배포를 통해서 변경에 따른 소요시간을 최소화 하는 것이다.

우리는 변경에 유연하고 탄력적이 서비스를 구축해야한 만다. 그리고 어떠한 사고에 대해서도 예측하고 대응할수 있어야만 한다.

측정

무언가 변경되고 변화 했으면 항상 측정을 하라고 한다. 예측 불가능한 영역을 최대한 예측 가능한 영역으로 바꾸는 것 의미한다. 우리의 방향성에 대해서 항상 깊게 고민하고 의심해야 한다고 한다. 모두가 지속적으로 나아지고 있는지 혹은 문제는 무엇인지 항상 측정 해야 한다. 그러한 측정 지표들은 중요한 의사결정들을 추측이 아닌 예측과 확인으로 만들어 준다. 그래서 반드시 매번 측정 해야 한다고 한다.

공유

이 부분이 가장 공감되면서 많은 기업에서 채택이 될 수 있을까 많은 고민을 하게 되었던 내용이다. 송주영 님이 말하기는 홀로 성장하는 시대는 완전히 끝났다고 한다. 더 이상 그런 시대는 오지 않을 거라고 한다. 절대 오지 않는다고 한다. 구성원 모두가 대부분의 데이터를 언제든지 접근할 수 있고 확인할 수 있어야 한다고 한다.

지식은 각자 배울 수는 있어도 항상 함께 공유해야 한다. 같이 성장해 나가야 한다. 사실 정말 공감이 된 이유가 내 블로그 취지도 배웠으면 나누라는 취지로 만들어졌기 때문이다. 문제는 개인의 문제가 아니고 우리의 문제로 인지 해야 하며 함께 해결해 나가고 그 누구든 해결할 수 있다. 인턴이 CTO가 해결하지 못한 일을 해결 할 수도 있다. 그렇기 때문에 항상 열려 있어야 한다.

축적

조직의 규모와 인원이 커짐에 따라서 일의 속도는 반비례하지 않고 가속도 그래프를 그려야 한다. 팀원들이 함께하고 같이 노력해야 그러한 곡선을 만들 수 있다. 모든 일의 성공과 실패 결과물들은 항상 축적되어야 한다. 송주영 님이 생각할 때 가훌륭한 기업 중 하나는루이비통이라고 한다. 왜냐하면 가장 이상적인 축적을 이룬 기업이라고 한다. IT 기술 회사가 아닌 명품회사를 이야기한다는 것이 엉뚱해 보일 수도 있지만 00년 전 예술가들과 디자이너들이 어떤 생각을 가지고 결과물들을 냈는지 아직도 갖고 있고 서로 공개하고 있다고 한다. 지금까지도 축적은 계속되고 있다고 한다.

결국 DevOps는 어떤 요구사항을 효율적으로 만족시키기 위해서 일을 자동화하며 변경 사항 지표들을 측정하고 공유하고 이 모든 성공과 실패의 결과물들을 지속해서 축적해 나가는 문화를 만들어 나가는 철학, 방법론 내지든 기술이다. 너무 복잡할 수도 있지만 실제로 이루는 건 생각보다 어렵지 않다고 한다. 단지 마음을 움직이기가 어려울 뿐이라고 한다. 우리는 그저 매 순간순간 나의 일이 우리의 일이 올바르게 가고 있는지 방향성만 맞추어서 나가면 된다고 한다.

속도와 효율화

현대의 서비스(S/W)는 너무나도 복잡하다. 앞으로 이 복잡도는 계속 증가할 거라고 한다. 이러한 수많은 복잡한 문제들을 DevOps 철학과 방법론으로 풀어나갈수 있다고 한다. 우리가 DevOps를 배워야 하는 이유이다.

엔지니어의 역할

그렇다면 우리가 가장 궁금한 DevOps 엔지니어의 역할은 무엇일까? 더 나아가 DevOps 엔지니어가 되려면 어떻게 해야 할까 여기서 더 나아가서 훌륭한, 뛰어난, 잘하는 DevOps 엔지니어가 되려면 어떤 기술들을 갖추고 무엇을 공부해야 할까? 정말로 생각보다 많은 분들이 DevOps 엔지니어 커리어에 대해서 질문을 받는다고 한다. 우선 방향성이 정말 중요하다고 한다. 올바른 개념과 많이 쓰이는 기술들을 배우는 게 정말로 정말로 중요하다고 한다.

DevOps 엔지니어 : 올바른 DevOps 문화를 위해 서비스 혹은 S/W LifeCycle 에서 반복적인 일들을 자동화 하고, 기술적 문제 혹은 팀의 차이를 기술적으로 예방하고 해소시키거나 사람

간단하게 이야기하자면 DevOps 엔지니어는 올바른 DevOps 문화를 위해서 서비스 혹은 소프트웨어 라이프 사이클에서 반복적인 이들을 자동화하고 기술적인 문제 혹은 팀의 차이를 기술적으로 기술을 이용해서 예방하고 해소하는 사람을 지칭한다. 방금 말한 내용만 봐도 스펙트럼이 굉장히 넓어 보인다. 그러기 때문에 실제로 하는 일들이 매우 많다.

그리고 다른 직군에 비해서 조금 특이점이 하나 있다 다른 역할들에 비해서 DevOps 엔지니어의 역량에 따라서 할 수 있는 일들이 정말로 많아지고 정해진다고 보시면 될 것 같다. 매우 큰 영향을 끼치기도 한다. 왜냐하면 어떤 기술과 개념들은 다양한 곳에 적용할 수 있기 때문이다.

다시 얘기해 보면 기획팀, 마케팅의 업무를 자동화한 것도 DevOps 엔지니어의 역할이 될 수 있기 때문이다. 물론 DevOps 엔지니어들이 주로 하는 일들이 있다. 파이프라인을 구성한다거나 빌드 자동화를 한다거나 막 그렇게 굉장히 변경되거나 그러지는 않는다. 다시 생각해 보면 공통된 기술을 사용하게 굉장히 효율적이기 때문이다.

굉장히 효율적이기 때문이죠. 그래서 그런 기술들을 다양한 곳에서 적용한다고 보면 된다. 공통된 기술들 DevOps 엔지니어링에 관련된 기술을 다양한 곳에 접목하는 것, 이게 이제 DevOps 엔지니어가 하는 일이다.

소프트 스킬 & 기술적 스킬

소프트 스킬 (Soft Skills)	기술적 스킬 (Technical Skills)
소프트 스킬은 사회 기술, 의사 소통 기술, 성격 또는 성격 특성, 태도, 직업 속성, 소셜 인텔리전스 및 감성 인텔리전스 지수 등의 조합으로, 사람들이 환경을 탐색하고 다른 사람들과 잘 일하는 능력을 이야기 한다. 문제 인식하는 능력, 정확하게 선택과 집중을 구별하는 능력, 결정 및 판단 등을 예로 들 수 있다.	기술적 스킬은 특정한 일을 효과적으로 수행하는 지식과 능력을 이야기 한다. IT 영역에서는 프로그래밍 언어 작성 능력, S/W 디자인, 데이터베이스 및 서버관리 등 특정한 기술의 지식과 수행 능력을 예로 들 수 있다.

DevOps 엔지니어가 갖추어야 할 능력에 대해서 두 가지로 정리해 보면. 첫 번째는 소프트 스킬이 있다. 보통 사회기술, 커뮤니케이션, 특성, 직업 속성 소셜 지수 등 이런 다양한 것들의 조합을 이야기한다. 얼마만큼 사람들이랑 결국 잘 지내고 사람들을 잘 다루고 정확히 이해하는지에 대한 능력을 이야기한다 두 번째는 테크니컬 스킬이 있다. 특정 일을 수행하기 위한 지식과 능력을 이야기한다. IT를 예로 들면 프로그래밍 언어 작성 능력 소프트웨어 설계 디자인 서버 매니지먼트 등이 있겠죠. 조금 더 자세히 알아봐야 한다.

Soft skill

• 문제인식 = 문제가 무엇이 있는지, 정확한 원인이 무엇인지 파악해야 한다.
• 선택과 집중 = 문제를 적합한 방법을 통해 해결 하고, 해결의 우선순위를 올바르게 설정 한다.
• 결정 = 수많은 선택지에 대해서, 추측이 아닌 확신을 가지고 빠르게 결정해야 한다.
• 업의 속성 = 제공하는 서비스의 본질과 가치를 이해해야 한다.
• 사용자 = 사용자를 이해하고 요구 사항에 대해서 빠르게 피드백 해야 한다.

소프트 스킬 중 첫 번째는 문제 인식이다. 정확히 문제를 알아야 그에 맞는 해결책을 구현해 낼 수 있기 때문이다. 그리고 눈에 쉽게 보이는 문제도 있지만 정말 찾기 어려운 문제들이 많다 아무리 뛰어난 기술적 능력을 갖춰도 문제가 무엇인지 모르면 예방하는 것도 개선 하기도 굉장히 어렵다 항상 내 관점뿐만이 아닌 다양한 관점에서 문제를 찾아내고 이해하고 가설을 세우며 검증해야 한다.

한정된 시간에서 훌륭한 선택을 내리고 그에 따른 집중을 하는 것도 굉장히 중요하다. DevOps 엔지니어는 항상 바쁘다. 그래서 무엇이 중요한지 선택을 내려야 할 때가 많다. 눈앞에 보이는 문제가 중요할 수도 있지만 때로는 몇 주 몇 개월 이상을 봐야 하는 통찰력도 필요하다. 수많은 선택 지속에서 결정을 내리는 것 지금 해야 할 일과 잠시 하지 말아야 할 일 일의 우선순위를 결정한 것도 굉장히 중요하다. 그러한 안목을 갖추어야 한다. 반드시 내 기준이 아니라 팀의 기준 우리 서비스의 기준으로 결정해야 한다.

결정이 결국 추측이 아니라 예측 관점으로 결정을 내려야 한다. 반드시 결정에 대한 기반 자료가 있어야 한다. 좋은 결정을 내리려면 결국 우리 서비스의 본질과 가치를 알아야 한다. 애초에 우리의 목적이 무엇있는지를 정확히 이해해야 한다. 사용자(고객)이 원하는 게 무엇인지도 알아야 한다.

고객은 자신이 원하는 걸 모르는 경우가 대부분이다. 그 부분을 빠르게 인지하고 빠른 피드백을 보여야 한다. 빠른 피드백 그리고 빠른 적용 실험, 빠른 피드백, 다시 적용 이러한 현재 트렌드가 퍼포먼스가 되었다.

Technical Skill

프로그래밍 = Go, Python 등, 능숙하게 다룰 수 있는 언어는 큰 강점이 된다. ex) Go, Python, Node.js 등

운영체제 = Linux와 같은 운영체제를 능숙하게 다루는 것과 개념을 반드시 알아야 한다. ex) Shell, OS metrics, File system, 7 layers등

서버관리 = 서버를 관리하는 기술과 운영지식을 통해 신뢰할 수 있는 서비스를 구축해야 한다. ex) laC, CI/CD, API, 가용성, 성능 등

오픈소스 = 인프라를 이루는 S/W 들을 이해하고, 자동화 도구들을 다룰 수 있어야 한다. ex) nginx, Tomcat, MySQL, Redis, Andivle, Terraform 등

클라우드 = 퍼블릭 클라우드를 능숙하게 다루고, 직접 구축 및 설계를 할 수 있어야 한다. ex) AWS, Azure, GCP, Alibaba 등

실제로 대부분의 엔지니어는 무엇을 할 줄 알아야 할까요? 그리고 어떤 기술을 알고 있어야 할까요? 일단 모든 소프트웨어 관련 엔지니어처럼 프로그래밍 언어에 능숙하면 큰 강점이 된다. 특히 Go, Python 같은 언어가 가장 인기 있고 대표적인 언어이다. 두 언어의 생산성 그러니까 익히기 쉽고 빠른 구현 및 관련 자료가 많기 때문이죠 다양한 OS가 많지만, 그중 리눅스를 알아야 하는 것은 필수라고 할 수 있다.

강사님의 말에 따르면 알아야 한다기보다는 그것을 넘어 생활이 되어야 한다고 한다. 사실 먹고 자는 거 빼고는 해야 하는 게 맞다. 리눅스 OS의 시스템 모니터링을 하는 방법부터 쉘을 다루는 것까지 OS에 굉장히 익숙해져야 한다. 서버를 관리하는 방법 즉, 다수의 서버를 효율적으로 관리하는 방법에 대해서도 알고 있어야 한다.

정말 열거하기도 어려울 정도로 많은 기술들과 용어들을 포함한다. OS, 어플리케이션 성능 모니터링 고가용성 설계, 파이프라인 등 너무나 많은 서버 관련한 기술들이 많이 있다. 지금 당장은 생각하면 너무 배울 게 많다는 생각이 들 수 있는데 사실 이러한 부분은 서버 엔지니어의 생활이다.

공부하는 것도 좋고 더 좋은 건 지속해서 생활하는 것이라고 한다. 계속 관련 자료를 읽고 공부한다기보다는 이거 자체가 라이프스타일이 되는 거죠. 이제 서버를 관리하는 방법을 이해하면 수많은 오픈소스 및 상용 소프트웨어들을 만날 수가 있다. 이런 수많은 소프트웨어의 동작 원리 및 실질적인 사용법 및 사상을 이해해야 한다. 결국 어떤 문제가 생기면 “어떤 소프트웨어 도구들을 사용해서 손쉽게 빠르게 해결할 수 있다.”

“어떤 소프트웨어 도구들을 사용해서 손쉽게 빠르게 해결할 수 있다.” 라는 Tip부터 이런 거를 넘어서 MYSQL 하나만 심도 있게 알아도 특정 분야의 전문가가 되는 것과 같다. 그리고 마지막 클라우드이다. 클라우드 시대이다. 심지어 지금도 계속 초고속으로 성장하고 있다.

세계에서 가장 큰 IT 회사들이 클라우드 산업을 하는 걸 보면 앞으로도 얼마나 성장할 수 있는지 예측할 수 있다. 사실 클라우드가 있었기 때문에 DevOps 철학이 진보되고 유행이 될 수 있었다고 해도 과언이 아니다. 규모가 궁금하다면 4개의 클라우드 회사 AWS, Azure, GCP, 알리바바 네개 회사의 매출과 투자 규모를 여러분들이 검색해 보시면 얼마만큼 크기인지 얼마만큼 엄청난 사업인지를 알 수 있다.

Infrastructure as Code, 코드러써으인프라

Infrastructure as Code, 즉 코드로써의 인프라는 인프라를 이루는 서버, 미들웨어 그리고 서비스 등, 인프라 구성요소들을 코드를 통해 구축하는것 IaC는 코드로써의 장점, 즉 작성용이성, 재사용성, 유지보수 등의 장점을 가진다.

저희는 먼저 Infrastructure as Code를 살펴볼 건데요 먼저 한다는 건 그만큼 중요하기 때문 입니다. Infrastructure as Code, 줄여서 IaC 코드로서의 인프라를 이야기 합니다. 즉, 인프라를 이루는 서버, 미들웨어, 서비스 들은 코드를 통해 구축하는 것을 이야기 합니다. 그러기 떄문에 실제 코드로서의 장점을 다 가지고 있습니다.

즉, 작성하는 것도 빨라지고 처음에는 불편할 수 있는데 익숙해지면 코드로 만든게 훨씬 빠르고 쉽습니다. 코드는 언제든지 재사용 할 수 있고 유지 보수 하기도 쉽죠 문서화 하기도 쉽고요 이외에도 수많은 장점이 있기 때문에 사실 이제 더이상 IaC는 선택이 아니라 필수 입니다. 그리고 코드이기 때문에 프로그래밍 하는 것처럼 반드시 정확히 이해하고 심도 있게 고민해서 코드를 만들어야 합니다.

Terraform by Hashicorp

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently 테라폼은 인프라를 만들고, 변경하고, 기록하는 IaC를 위해 만들어진 도구로써, 문법이 쉬워 빅교적 다루기 쉽고 사용자가 매우 많아 참고할 수 있는 예제가 많다. AWS, Azure, GCP 같은 퍼블릭 클라우드 뿐만이 아닌 다양한 서비스들 역시 지원한다.

테라폼은 현재 가장 많이 쓰이는 IaC 도구인데요. 해쉬코드 회사에서 개발을 헀습니다. 코드로 인프라를 만들고 변경하는데 있어서 굉장히 배우기 쉽고 사용자가 많아서 참고할 수 있는 샘플코드가 굉장히 많습니다. AWS, Azure, GCP 같은 포블릭 클라우드 이외에도 지원하는 Provider들이 굉장히 많다.

시작 방법

막상 공부를 하려고 할떄 무엇부터 시작해야할지 모르는 분들이 많다고 한다. 많은 분들이 송주영 님 에게 이러한 질문을 한다고 한다. “공부를 도대체 어떻게 해야 될지 모르겠어요 도대체 무엇부터 해야 하나요 뭐 이런 강의를 듣는 것도 방법이 될 수 있는데 제게 많은 대학생분들 그리고 초년차 엔지니어 분들이 물어 볼 때 전 항상 똑같은 질문에 대해서 똑같은 답변을 합니다.”

무엇을 할지 모르겠다면 개발자, 엔지니어들 커뮤니티부터 가입하는걸 추천 드립니다. 인기가 있는 기술은 반드시 커뮤니티가 생성되고, 사람이 모이게 되어있습니다. 지식공유는 개발자들한테 그 무엇보다 중요한 것중 하나입니다. (Sharing) AWS 공부를 어떻게 해야할지 모르겠다면, AWS 커뮤니티를 찾아서 가입하고 모임을 참석하세요. 그리고 질문하세요. 많은 고민들을 담아서 진중한 질문을 하면 반드시 답변이 돌아옵니다.

마무리 하며

DevOps에 입문하려고 하는데 생각보다 DevOps에 관한 정보다 많이 없었다. 뭐부터 해야 할지 전혀 감이 오지 않아서 컨퍼런스에서 본 송주영 AWS Hero님이 생각이 났다. 그래서 영상과 강의를 찾아보면서 앞으로 어떻게 무엇을 해야 할지 알아보고 정리했다. 이렇게 정리하다 보니까 어느 정도 감은 온 거 같다. DevOps는 단순 개발이 아니라 전체적인 문화가 있는 거 같다. 보면 볼수록 재미있다. 사실 영상을 보고 가져온 내용이기 때문에 많이 겹치는 건 사실이다. 만약 이 글이 문제가 된다면 바로 글을 내리도록 하겠습니다. 감사합니다.

참고문서

https://www.youtube.com/watch?v=QAj3fsttKM4&t=187s

https://www.youtube.com/watch?v=OL_DqAiC57I&t=10s

맨 위로 올라가기