모바일엔트로피 2023 워크샵 세미나 - DevOps로 일상 속 불편함 개선하기

date

Mar 16, 2023

slug

me-workshop-devops

status

Public

DevOps로 일상의 불편함 개선하기

안녕하세요. 모바일엔트로피의 연구본부 문영채 매니저입니다.

Redmine

다들 Redmine 잘 사용하고 계신가요? 혹시 Redmine에 대해 처음 들어보실 신입 분들을 위해 Redmine에 대한 간단한 소개를 해드리자면, Redmine은 저희 회사에서 사용 중인 프로젝트 이슈 관리 시스템입니다.

그런데 사실 저는 이 Redmine을 쓸 때 불편한 부분이 되게 많았습니다. 로그인도 종종 풀리기도 하고, 매번 이메일로 제보되는 장애 건을 Redmine에 옮겨 적는 것도 귀찮았고, 이슈 번호로 해당 이슈 페이지에 찾아 들어가는 것도 무지 귀찮은 일이었습니다. 이런 불편함이 짜잘하긴 하지만 너무도 귀찮아서, 선배님들에게 투정하면 "원래 그냥 그렇게 하는거야"라고 하시더라구요.

일상의 불편을 줄이기 위한 크롬 확장 프로그램

그래서 이런 일상 속의 불편함을 좀 줄일 수 있는 방법은 없을까 싶었습니다. 그 결과로 Redmine을 편하게 사용할 수 있도록 크롬 확장 프로그램을 만들어서 배포했었죠. 그리고 지금은 운영팀의 대부분의 인원들이 이 확장 프로그램을 사용하고 있습니다. 개발자로써 굉장히 뿌듯한 일이죠. 개발자는 현실세계의 문제를 코드를 통해 해결하는 사람이니까요. 하지만 저는 이런 짜잘한 불편함들이 고작 이것만 존재할 것이라고 생각하지는 않습니다. 그래서 저는 모바일엔트로피에 존재하는 이런 다양한 불편함을 개선하기 위해 많은 생각을 했고, 그 과정에서 DevOps의 철학과 문화에 대해 깊이 고민해보게 되었는데요. 이번 발표에서는 제가 요새 고민하고 있는 이런 DevOps에 대해, 대체 이게 무엇인지 공유하고자 합니다.

DevOps란 무엇인가?

자, 그래서 DevOps란 뭘까요?

Redhat의 DevOps 정의

아주 유명한 회사인 Redhat에서는 DevOps를 다음과 같이 정의하고 있습니다.

DevOps는 신속한 고품질 서비스 제공을 통해 비즈니스 가치와 대응력을 높이기 위한 문화, 자동화 및 플랫폼 설계에 대한 접근 방식입니다. 혹시 이 말을 보고 아, DevOps가 뭔지 딱 알았다! 번뜩였다! 하시는 분 있으실까요?

설명이 너무 어렵다

일단 저는 아닙니다. 너무 어렵네요. 다른 분들도 DevOps에 대해 찾아보실 때, 이런 너무 어려운 설명 때문에 "아! 이건 내가 관심가질 것이 아닌가보다~" 하고 포기하시는 분들이 많았을 것이라 생각합니다.

Roadmap.sh는 어떨까?

그래도 DevOps가 뭔지 알아는 봐야하니 조금 더 찾아보죠. 다들 Roadmap.sh 알고 계신가요? 특정 분야의 개발자가 되려면 뭘 공부해야 할 지 조목조목 알려주는 로드맵 사이트인데요. DevOps 개발자들이 어떤 기술을 쓰는지 한번 눈으로 직접 확인해보시죠!

Roadmap.sh 이미지

어우. 딱 봐도 별로죠. Infrastructure Provisioning, Configuration Mgmt..

이게 다 뭐야?

정말 이 생각 밖에 안 듭니다. 이게 다 뭐야? DevOps에 대해 알아보면 알아볼 수록 이게 뭐하는 거인지 알기가 어렵습니다.

DevOps, 사실은 별 거 아니다!

하지만 이런 DevOps, 사실은 별 거 아닙니다. 한번 다 같이 알아보도록 할게요.

회사에서 어떤 생각하면서 일하시나요?

여러분께 한번 물어보고 싶습니다. 회사에서 어떤 생각을 하면서 일하시나요? 저는 평소에 참~ 이게 궁금했거든요. 그러면 여러분 중 한 분을 뽑아서 물어보려고 하는데요.. 우리 연구본부의 박준화 매니저님께 한 번 물어보도록 하겠습니다. 박준화 매니저님은 회사에서 평소에 일하면서 무슨 생각을 하시나요?

음.. 직원보다 회사가 먼저다?

아! 그렇군요. 직원보다 회사가 먼저다라.. 그렇다고 하기에는 칼퇴를 꼬박꼬박 하시던데..

자, 솔직해져봅시다. 저는요, 이런 생각하면서 일합니다. 편하게 일하고 칼퇴하고 집 가서 쉬고 싶다!

사실 이건 대표님, 이사님, 상무님이라도 똑같은 생각을 하실 것 같아요. 우리 모두의 바람이죠.

우리는 우리의 퇴근을 방해하는 시련에 너무나도 많이 부딪힙니다

하지만 원하는 대로 그렇게 칼퇴가 항상 꼬박꼬박 되던가요? 우리의 칼퇴를 방해하는 시련이 세상에는 너무 많습니다.

배포하려니까 고객사가 밤 늦게 배포해달라 해서 야근을 하게 되기도 하고

분명 내 컴퓨터에서는 잘 돌아갔는데 운영서버에만 배포하니까 안 돌아가기도 하고

장애가 발생하면 에러 로그 뒤지느라 시간을 날리기도 하고 눈도 빠지죠

서버에 사람이라도 몰려 부하가 일어나면 직접 손수 서버를 증설해야 하기도 하구요.

우리의 소망이 뭐라고요?

편하게 일하고 칼퇴하고 집 가서 쉬는 거였죠? 저는, 이 말을 이렇게 바꿔서 부를 수 있을 것 같아요.

서비스를 빠르고 간단하게 개발하고 배포 및 운영하는 것!

그런 당신에게 DevOps가 필요합니다.

그리고 그런! 당신에게 바로 DevOps가 필요합니다. DevOps는요, 서비스를 빠르게 개발하고 배포 및 운영하고자 하는 철학이자 방법론이고, 문화입니다.

이게 무슨 말인지 좀 예시를 들며 자세히 설명해보도록 하겠습니다.

DevOps의 사이클

DevOps는 다음과 같은 4가지 사이클로 이루어져 있습니다.

첫번째로, 어떤 특정한 문제를 발견하고 개선하는 것입니다. 아까 얘기했던 밤 늦게 배포해야해서 야근을 해야 한다는 문제를 예를 들어볼까요. 이 문제를 해결하기 위해, 이제 배포를 자동화해서 예약을 걸면 어떨까요? 라고 생각을 하고 이 문제를 뚝딱뚝딱 노력해서 개선을 했다고 합시다.

두번째로, 이런 배포 자동화를 도입해보고, 얼마나 좋아졌는지를 측정해보는 거죠. 아, 원래 사람이 손수 배포하느라 10분이 걸리던게 이제 버튼 하나만 누르면 되니 1분이면 되네?

그렇다면 이제 이런 좋은 문화를 회사 내에 공유해보는 거죠. 우리가 배포 자동화를 도입해봤는데, 되게 좋더라구요. 다른 팀에도 전파해보는 거죠.

이제 이런 좋은 시스템들이 회사 내에 축적이 되면 그 팀에서도 또 다른 개선을 하게 될 수도 있겠죠.

이런 사이클이 계속해서 반복된다면 어마어마한 효과를 낼 수 있습니다.

DevOps를 통해 시련 깨부수기

그렇다면 이제 앞에서 얘기한 시련들을 DevOps를 통해 해결해볼까요.

매번 밤 늦게 배포하느라 야근을 하게 됐다면, 배포 자동화를 구성해서 예약을 걸면 되겠죠. 해결!

내 컴퓨터에서는 잘 됐다면, 운영 서버에 내 컴퓨터의 환경을 그대로 옮겨오면 되겠죠. 가상 컨테이너 기술인 Docker를 통해 해결!

서버 에러 로그 확인하기 힘들다면, 서버 에러를 시각적으로 예쁘게 보여주는 로그 시각화와 에러나면 알림을 받도록, 에러 모니터링 툴을 도입해서 해결!

서버에 부하가 걸리면 자동으로 서버 용량을 증설하도록, 오토 스케일링을 도입해서 해결!

우리의 시련이 이 뿐일까요?

그런데, 우리가 가지고 있는 시련이 이런 기술적인 것들 뿐일까요?

매주 업무 주간보고 해야 하는데 업무 정리하는게 오래 걸리는게 귀찮을 수도 있고

팀원들끼리 코딩 컨벤션이 안 맞아서 누구는 탭으로 하고, 누구는 스페이스바 2개를 치고, 포맷이 뒤죽박죽되는 불편함도 있을 수도 있고

등등등.. 우리의 앞에는 우리가 깨부술 수 있는 많은 일상 속 불편함이 존재합니다.

시련을 깨부쉈다면, 공유합시다.

이런 문제점들을 하나씩 해결해서 '개선'했다면 이제는 DevOps의 두 번째 단계인, '공유'할 차례입니다.

우리가 시련을 개선했다면, 그 노하우를 내 머리 속에만 저장해두는 것이 아니라, 시련을 헤쳐낸 노하우와 프로세스를 문서화해서 추후에 다른 팀원들이 참고할 수 있도록 공유해야 합니다.

우리가 개선한 사항을 우리 팀만 편하게 꿀 빨아야지가 아니라 다른 팀원들에게 공유하고 발표해서 회사에 전파해야 합니다.

또한 문제를 해결했다면 회고하고, 추후 재발을 방지하기 위해 개선해야겠죠.

→ 개선과 도입, 그리고 축적과 공유가 있다면 우리는 좋은 개발 문화로 유명한 네카라쿠배처럼 훨씬 높은 곳으로 나아갈 수 있다고 생각합니다.

연구본부는 이런 DevOps의 힘을 믿습니다.

그리고 저희 연구본부는 이런 DevOps의 힘을 강하게 믿고 있고, 이를 위해 다양한 일들을 하고 있는데요.

프로젝트 대시보드 도입하여 서버 부하 확인

저희 본사랑 연구소에 이렇게 모니터로 깜빡깜빡하는거 다들 보신 적 있으시죠? 이게 그 서버 모니터링툴입니다. 서버에 문제가 생기면 언제든 바로 시각적으로 알 수 있도록 구성을 해두었습니다.

SonarQube를 통한 소스코드 정적 분석

저희 프로젝트에 코드를 커밋하면 바로바로 SonarQube라는 친구가 저희의 코드를 분석해서 우리 코드의 문제점을 이렇게 리포팅해줍니다. 그러면 리포팅 해 준 문제점을 해결해나가는 과정에서 장애 발생 빈도도 줄이고, 유지보수하기 쉬운 코드를 작성할 수 있겠죠.

Sentry를 통한 에러 모니터링

또한 에러 모니터링 툴인 Sentry도 도입하였는데요. 장애가 발생하면 이 에러 모니터링 툴을 통해 즉각즉각 에러를 감지하고, 눈으로 보기 쉽게 리포팅해주기 때문에 장애에도 더 기민하게 반응할 수 있습니다.

연구 본부는 더 먼 곳을 바라보고 있습니다.

연구 본부는 우리 회사의 일상 속 불편함이 이것들뿐이라고 생각하지 않습니다. 더 편하게 알림을 받아볼 수 있도록 이슈 트래킹, 코드 리뷰, 테스트 자동화 등등 다양한 노력을 해나가고 있습니다. 하지만 이런 노력은 비단 저희 팀만 해야 한다는 것은 아니죠. 우리 회사의 다른 팀. 개발팀, 운영팀, GIS 팀 등등에서도 또 자발적으로 문제점을 개선하고 공유하는 것이 반복된다면 회사 입장에서 어마어마한 효과를 낼 수 있습니다.

다시 한번 묻겠습니다. DevOps란 무엇일까요?

말이 길었습니다. 다시 원래 주제로 돌아와서요. 그래서 DevOps란 무엇일까요?

저는 이렇게 한 문장으로 DevOps를 정리하면서 발표를 마무리하도록 하겠습니다.

DevOps란 그저 개발자들이 편하게 일하고 퇴근을 빨리 하기 위한 몸부림이었다!

감사합니다.

발표 들어주셔서 감사합니다.