2019.11.28

데브옵스의 어두운 비밀 9가지

Peter Wayner  | CIO
태초에 코드가 있었고 코드를 작성하는 코더가 있었다. 개발자가 모든 것을 책임졌다. 논리를 만들어 냈고 서버에 계속 실행되도록 이런저런 버튼을 눌러야 했다. 그런데 팀이 확장하고 노동 분화가 일어나면서 상황이 달라졌다. 일부 팀원은 코드 작업을 계속했고(개발(devs)) 나머지는 시스템 관리를 담당하게(운영(ops))된 것이다.



최근에는 클라우드 덕분에, 그리고 마이크로서비스가 발달한 덕분에, 소프트웨어는 서로 다른 시스템에서 실행되는 수십 개, 많으면 수천 개에 달하는 구성 요소의 합으로 변모했다. 각자 기술적으로는 독립적이지만 시스템 전체가 함께 작동해야 했다. 이를 보장하기 위한 최선의 수단은 자동화 스크립트다. 이제 데브옵스(DevOps)의 역할이 필요하게 됐다. 데브옵스 팀의 핵심 업무는 이러한 다면적 앱을 세밀하게 조정하는 것이다. 소프트웨어 아키텍처의 깊은 부분까지 다루지 않는다고 해도 모든 부문이 원활하게 실행되는 역할을 한다.

아직 이러한 역할은 새로운 편에 속한다. 책임이 명확하게 정의되거나 부여되지 않은 상태이며 요구되는 기술도 아직 진화하고 있다. 일부 데브옵스 전문가는 양다리를 걸치고 프로그래밍과 운영 작업을 모두 수행하고 있지만, 모든 서버의 원활한 실행을 유지하는 것만으로도 일이 충분히 많다. 서버 구성은 세세한 것에 집중해야 하는 지루한 작업이다. 그 와중에 프로그래밍 팀은 코드를 수정하므로 코드 실행 방식도 달라진다.

디지털 트랜스포메이션을 위해 데브옵스를 도입하는 기업이 늘어나면서 현실적인 관점을 갖는 것이 중요하다. 지금부터 새롭게 부상하는 데브옵스에 대해 숨겨진 진실과 널리 퍼진 오해를 알아보자.

데스옵스의 임무는 프로그래밍이 아니다, 그러나 ...
데브옵스의 임무가 프로그래밍이 아니라는 많은 관리자의 생각은 맞다. 업무는 분화됐고 바이트와 데이터 구조를 다뤄야 하는 복잡한 작업은 추상적인 다른 세계에 살고 있는 코더가 대부분 담당한다. 프로그래머는 복잡한 최신 스택을 신경 쓰느라 정신이 없으므로, 이들이 모든 것을 실행 상태로 유지되도록 하는 책임을 덜어주는 것은 전략적으로도 합리적인 선택이다.

그러나, 현실에서 데브옵스 팀원은 여전히 코드를 작성해야 하고, 숨겨진 데이터 구조에 대해 추상적으로 검토해야 한다. 모든 것을 실행 상태로 유지하려고만 해도 끝없는 명령줄 호출이 필요하므로 보통은 모아서 셸 스크립트로 단순화한다. 이러한 작업에는 함수 호출, 매개변수, 변수 등이 포함돼 있으며 (일부 코딩 순수주의자는 코딩이라고 보지 않겠지만) 결국 실제로 프로그래머가 보유한 것과 같은 종류의 기술이 많이 사용한다.

프로그래머 관리는 힘든 일이다
데브옵스 전문가는 직접 많은 코드를 작성하지 않는다고 해도 프로그래머 관리 역할을 하기 마련이고 그 작업은 코드 작성 못지않게 부담스러운 일인 경우가 많다. 개발자마다 새롭고 아름다운 것을 만들어 내며 이들이 작성한 코드는 예술이다. 각자의 컨테이너를 당장 생산 단계로 이동 시켜 끝내고 싶어 한다. 코드가 원활하게 실행되는가? 그들은 그렇게 생각한다. 혹시 문제가 생기지는 않을까? 코더가 일을 망치지 않도록 하는 것은 데브옵스가 해야 하는 힘든 업무 중 하나다.

데브옵스가 서서히 개발 과정을 장악하고 있다
소프트웨어를 한 덩어리도 만들던 시대에는 프로그래머가 모든 통제권을 갖고 있었다. 그러나 이제는 앱 하나가 수십 개, 많게는 수백 개 마이크로서비스로 나뉘어 있는 것이 보통이고, 이들이 얼마나 원활하게 실행되느냐는 데브옵스의 책임이다. 물론, 서비스의 연결 방식을 아키텍트와 프로그래머가 결정하는 경우도 종종 있지만, 점점 더 중요해지고 있는 서비스 연결 방식은 데브옵스 전문가가 담당하는 추세다.

잔돈이 모여 큰 지출이 된다
클라우드 업체가 시간당 1달러 미만의 잔돈 단위로 시스템 가격을 매긴 것은 영리한 결정이었다. 큰 부담이 아닌 것처럼 느껴지기 때문이다. 그러나 클라우드 인스턴스 수가 증가하고 시간이 지나다 보면 잔돈이 쌓여 큰돈이 된다. 30일을 기준으로 하면 한 달은 720시간이고 시간당 비용이 1달러에 '불과한' 거대 시스템에 연간 8,760달러가 들어간다. 어느 순간 직접 사는 게 더 싸겠다는 생각이 드는 것도 무리가 아니다.

충격적인 계산서를 받고 난 후 일부 팀은 데브옵스 감사팀을 만들었다. 복잡한 시스템을 들쑤시고 다니며 돈을 절약할 방법을 찾는 것이 이 팀의 유일한 업무다. 실무 담당자의 결정을 꼼꼼히 들여다보고는 ‘안된다’는 말을 하기 시작한다. 예산에 맞추기 위해 한 푼 단위로 세세하게 금액을 산출하는 것이다.

성능 향상을 위한 수단은 몇 개에 불과하다
클라우드 관리가 어려운 이유는 데브옵스 팀이 활용할 수 있는 수단이 실제로는 몇 개 없기 때문이다. 프로그래머가 코드 작성을 마치고 컨테이너를 구축하고 나면 데브옵스 팀의 임무는 컨테이너가 실행되게 하는 것이다. 느린 듯 싶으면 가상 CPU나 RAM을 늘리고, 그래도 개선되지 않으면 포드(pod)에 시스템을 늘려 부하를 분산시킨다. 사실 이게 전부다.
 
'슬쩍 덮어두는' 경우가 많다
가장 심각한 문제 중 하나는 시스템이 언제나 실수를 슬쩍 덮어둔다는 점이다. 예를 들어 한 때 필자가 담당했던 컨테이너는 몇 시간마다 한 번씩 장애를 일으켰다. 데이터 연결 문제 때문이었을 수도 있고 매개변수 구성이 잘못됐을 수도 있다. 해답은 로그 파일 깊은 곳에 있겠지만 결국 찾아내지 못했다. 다행히 쿠버네티스가 다른 인스턴스를 부팅 시켜 줘 포드는 질의응답 등의 작업을 계속해 나갈 수 있었다. 결국 내부는 엉망이었지만 장애 대비 아키텍처가 훌륭하게 실행됐다.

이처럼 시스템의 표면 아래에서 컨테이너와 인스턴스가 여기저기 장애를 일으키는 경우가 있다. 그러나 사용자와 고객의 작업에 지장만 없다면, 마치 이러한 장애가 없는 것처럼 무시하고 다른 방법을 찾는 것이 더 쉬울 때가 많다.

데이터베이스가 모든 것을 지배한다
데이터 관련해서 자체 개발한 코드를 가지고 법석을 떨고 AJAX니 CSS니 하는 것을 만지작거릴지 모르지만, 결국 모든 데이터는 데이터베이스에서 집을 찾는다. 전통적인 데이터베이스는 여전히 코드가 공전하는 중심의 태양과 같은 역할을 한다.

이것이 유일한 진실이다. 데이터베이스가 계속 실행되면서 질의에 응답하면 할 일을 거의 다 한 것이다. 사용자는 DIV의 정렬이 잘못되거나 새로운 레이아웃이 이상한 것은 참을 수 있어도 손상된 데이터베이스는 참을 수 없다. 한때 필자가 코드를 감사했던 한 팀은 최신 Node.js 패키지를 사용하고 첨단을 유지하기 위해 스택을 끈질기게 업데이트하고 있었다. 그러나 데이터베이스는 10년도 넘은 것이어서, 아무도 건드리고 싶어하지 않았다.

코드가 어떻게 실행되는지 거의 모른다
오늘날 이용 가능한 모니터링의 수준은 놀라운 정도다. 마치 항해사가 밀려드는 바람을 느끼듯 데이터가 다양한 소프트웨어를 통과하는 것을 감지할 수 있다. 포드의 부하가 밀려왔다가 밀려갈 때면 언제 정확히 실행되고 있으며 언제 부하를 받는지 알 수 있다. 전자상거래 웹 애플리케이션 담당자라면 언제 할인이 적용되는지 제일 먼저 알 수 있다. 앱의 그 부분에서 부하가 급증하기 때문이다.

그러나, 모니터링을 통해 알 수 있는 것에는 한계가 있다. 숫자는 구성 요소의 평균 부담 및 반응 시간을 요약해 보여주지만 그 이유는 알려주지 않는다. 구성 요소 내부에서 무슨 일이 일어나고 있는지 밝히는 것은 프로그래머의 몫이다. 그들은 버그를 찾아 해결책을 찾을 수 있다. 기업 입장에서는 전체 스택을 샅샅이 파악할 수 있는 전지전능한 직원이 있으면 좋겠다고 생각할 것이다. 그런 '초인'이 몇 명 있기는 하지만 현실에서 많은 기업의 프로젝트는 그 규모가 너무 크고 코드는 너무 길다. 오히려 데브옵스와 프로그래머가 협력할 수 있는 방법을 찾는 편이 훨씬 합리적이다.

모두가 약간은 미스터리다
컴퓨터는 완벽히 논리적인 기계일 수 있다. 코드는 예상할 수 있는 정해진 방식으로 실행되고 모든 버그에는 다 이유가 있기 마련이다. 디버거를 끌어내고 로그 파일을 스크롤하면서 코드를 면밀히 검토하면 된다.

문제는 그럴 충분한 시간을 가진 사람이 없다는 점이다. 기술 지원 문제 중 90%는 장치의 전원을 껐다 켜면 해결되는 것처럼 느껴지듯, 데브옵스 작업의 상당 부분도 마찬가지다. 물론, ‘컨테이너’나 ‘인스턴스’ 같은 용어를 사용하고, 상황 추적을 위한 대시보드가 무수히 많기는 하지만, 결국에는 더 빠르고 간단한 방법은 그냥 넘어가는 것이고 아이리스 데멘트(Iris Dement)의 노래 제목처럼 ‘모르는 것은 모르는 채로 두게’ 된다. ciokr@idg.co.kr



2019.11.28

데브옵스의 어두운 비밀 9가지

Peter Wayner  | CIO
태초에 코드가 있었고 코드를 작성하는 코더가 있었다. 개발자가 모든 것을 책임졌다. 논리를 만들어 냈고 서버에 계속 실행되도록 이런저런 버튼을 눌러야 했다. 그런데 팀이 확장하고 노동 분화가 일어나면서 상황이 달라졌다. 일부 팀원은 코드 작업을 계속했고(개발(devs)) 나머지는 시스템 관리를 담당하게(운영(ops))된 것이다.



최근에는 클라우드 덕분에, 그리고 마이크로서비스가 발달한 덕분에, 소프트웨어는 서로 다른 시스템에서 실행되는 수십 개, 많으면 수천 개에 달하는 구성 요소의 합으로 변모했다. 각자 기술적으로는 독립적이지만 시스템 전체가 함께 작동해야 했다. 이를 보장하기 위한 최선의 수단은 자동화 스크립트다. 이제 데브옵스(DevOps)의 역할이 필요하게 됐다. 데브옵스 팀의 핵심 업무는 이러한 다면적 앱을 세밀하게 조정하는 것이다. 소프트웨어 아키텍처의 깊은 부분까지 다루지 않는다고 해도 모든 부문이 원활하게 실행되는 역할을 한다.

아직 이러한 역할은 새로운 편에 속한다. 책임이 명확하게 정의되거나 부여되지 않은 상태이며 요구되는 기술도 아직 진화하고 있다. 일부 데브옵스 전문가는 양다리를 걸치고 프로그래밍과 운영 작업을 모두 수행하고 있지만, 모든 서버의 원활한 실행을 유지하는 것만으로도 일이 충분히 많다. 서버 구성은 세세한 것에 집중해야 하는 지루한 작업이다. 그 와중에 프로그래밍 팀은 코드를 수정하므로 코드 실행 방식도 달라진다.

디지털 트랜스포메이션을 위해 데브옵스를 도입하는 기업이 늘어나면서 현실적인 관점을 갖는 것이 중요하다. 지금부터 새롭게 부상하는 데브옵스에 대해 숨겨진 진실과 널리 퍼진 오해를 알아보자.

데스옵스의 임무는 프로그래밍이 아니다, 그러나 ...
데브옵스의 임무가 프로그래밍이 아니라는 많은 관리자의 생각은 맞다. 업무는 분화됐고 바이트와 데이터 구조를 다뤄야 하는 복잡한 작업은 추상적인 다른 세계에 살고 있는 코더가 대부분 담당한다. 프로그래머는 복잡한 최신 스택을 신경 쓰느라 정신이 없으므로, 이들이 모든 것을 실행 상태로 유지되도록 하는 책임을 덜어주는 것은 전략적으로도 합리적인 선택이다.

그러나, 현실에서 데브옵스 팀원은 여전히 코드를 작성해야 하고, 숨겨진 데이터 구조에 대해 추상적으로 검토해야 한다. 모든 것을 실행 상태로 유지하려고만 해도 끝없는 명령줄 호출이 필요하므로 보통은 모아서 셸 스크립트로 단순화한다. 이러한 작업에는 함수 호출, 매개변수, 변수 등이 포함돼 있으며 (일부 코딩 순수주의자는 코딩이라고 보지 않겠지만) 결국 실제로 프로그래머가 보유한 것과 같은 종류의 기술이 많이 사용한다.

프로그래머 관리는 힘든 일이다
데브옵스 전문가는 직접 많은 코드를 작성하지 않는다고 해도 프로그래머 관리 역할을 하기 마련이고 그 작업은 코드 작성 못지않게 부담스러운 일인 경우가 많다. 개발자마다 새롭고 아름다운 것을 만들어 내며 이들이 작성한 코드는 예술이다. 각자의 컨테이너를 당장 생산 단계로 이동 시켜 끝내고 싶어 한다. 코드가 원활하게 실행되는가? 그들은 그렇게 생각한다. 혹시 문제가 생기지는 않을까? 코더가 일을 망치지 않도록 하는 것은 데브옵스가 해야 하는 힘든 업무 중 하나다.

데브옵스가 서서히 개발 과정을 장악하고 있다
소프트웨어를 한 덩어리도 만들던 시대에는 프로그래머가 모든 통제권을 갖고 있었다. 그러나 이제는 앱 하나가 수십 개, 많게는 수백 개 마이크로서비스로 나뉘어 있는 것이 보통이고, 이들이 얼마나 원활하게 실행되느냐는 데브옵스의 책임이다. 물론, 서비스의 연결 방식을 아키텍트와 프로그래머가 결정하는 경우도 종종 있지만, 점점 더 중요해지고 있는 서비스 연결 방식은 데브옵스 전문가가 담당하는 추세다.

잔돈이 모여 큰 지출이 된다
클라우드 업체가 시간당 1달러 미만의 잔돈 단위로 시스템 가격을 매긴 것은 영리한 결정이었다. 큰 부담이 아닌 것처럼 느껴지기 때문이다. 그러나 클라우드 인스턴스 수가 증가하고 시간이 지나다 보면 잔돈이 쌓여 큰돈이 된다. 30일을 기준으로 하면 한 달은 720시간이고 시간당 비용이 1달러에 '불과한' 거대 시스템에 연간 8,760달러가 들어간다. 어느 순간 직접 사는 게 더 싸겠다는 생각이 드는 것도 무리가 아니다.

충격적인 계산서를 받고 난 후 일부 팀은 데브옵스 감사팀을 만들었다. 복잡한 시스템을 들쑤시고 다니며 돈을 절약할 방법을 찾는 것이 이 팀의 유일한 업무다. 실무 담당자의 결정을 꼼꼼히 들여다보고는 ‘안된다’는 말을 하기 시작한다. 예산에 맞추기 위해 한 푼 단위로 세세하게 금액을 산출하는 것이다.

성능 향상을 위한 수단은 몇 개에 불과하다
클라우드 관리가 어려운 이유는 데브옵스 팀이 활용할 수 있는 수단이 실제로는 몇 개 없기 때문이다. 프로그래머가 코드 작성을 마치고 컨테이너를 구축하고 나면 데브옵스 팀의 임무는 컨테이너가 실행되게 하는 것이다. 느린 듯 싶으면 가상 CPU나 RAM을 늘리고, 그래도 개선되지 않으면 포드(pod)에 시스템을 늘려 부하를 분산시킨다. 사실 이게 전부다.
 
'슬쩍 덮어두는' 경우가 많다
가장 심각한 문제 중 하나는 시스템이 언제나 실수를 슬쩍 덮어둔다는 점이다. 예를 들어 한 때 필자가 담당했던 컨테이너는 몇 시간마다 한 번씩 장애를 일으켰다. 데이터 연결 문제 때문이었을 수도 있고 매개변수 구성이 잘못됐을 수도 있다. 해답은 로그 파일 깊은 곳에 있겠지만 결국 찾아내지 못했다. 다행히 쿠버네티스가 다른 인스턴스를 부팅 시켜 줘 포드는 질의응답 등의 작업을 계속해 나갈 수 있었다. 결국 내부는 엉망이었지만 장애 대비 아키텍처가 훌륭하게 실행됐다.

이처럼 시스템의 표면 아래에서 컨테이너와 인스턴스가 여기저기 장애를 일으키는 경우가 있다. 그러나 사용자와 고객의 작업에 지장만 없다면, 마치 이러한 장애가 없는 것처럼 무시하고 다른 방법을 찾는 것이 더 쉬울 때가 많다.

데이터베이스가 모든 것을 지배한다
데이터 관련해서 자체 개발한 코드를 가지고 법석을 떨고 AJAX니 CSS니 하는 것을 만지작거릴지 모르지만, 결국 모든 데이터는 데이터베이스에서 집을 찾는다. 전통적인 데이터베이스는 여전히 코드가 공전하는 중심의 태양과 같은 역할을 한다.

이것이 유일한 진실이다. 데이터베이스가 계속 실행되면서 질의에 응답하면 할 일을 거의 다 한 것이다. 사용자는 DIV의 정렬이 잘못되거나 새로운 레이아웃이 이상한 것은 참을 수 있어도 손상된 데이터베이스는 참을 수 없다. 한때 필자가 코드를 감사했던 한 팀은 최신 Node.js 패키지를 사용하고 첨단을 유지하기 위해 스택을 끈질기게 업데이트하고 있었다. 그러나 데이터베이스는 10년도 넘은 것이어서, 아무도 건드리고 싶어하지 않았다.

코드가 어떻게 실행되는지 거의 모른다
오늘날 이용 가능한 모니터링의 수준은 놀라운 정도다. 마치 항해사가 밀려드는 바람을 느끼듯 데이터가 다양한 소프트웨어를 통과하는 것을 감지할 수 있다. 포드의 부하가 밀려왔다가 밀려갈 때면 언제 정확히 실행되고 있으며 언제 부하를 받는지 알 수 있다. 전자상거래 웹 애플리케이션 담당자라면 언제 할인이 적용되는지 제일 먼저 알 수 있다. 앱의 그 부분에서 부하가 급증하기 때문이다.

그러나, 모니터링을 통해 알 수 있는 것에는 한계가 있다. 숫자는 구성 요소의 평균 부담 및 반응 시간을 요약해 보여주지만 그 이유는 알려주지 않는다. 구성 요소 내부에서 무슨 일이 일어나고 있는지 밝히는 것은 프로그래머의 몫이다. 그들은 버그를 찾아 해결책을 찾을 수 있다. 기업 입장에서는 전체 스택을 샅샅이 파악할 수 있는 전지전능한 직원이 있으면 좋겠다고 생각할 것이다. 그런 '초인'이 몇 명 있기는 하지만 현실에서 많은 기업의 프로젝트는 그 규모가 너무 크고 코드는 너무 길다. 오히려 데브옵스와 프로그래머가 협력할 수 있는 방법을 찾는 편이 훨씬 합리적이다.

모두가 약간은 미스터리다
컴퓨터는 완벽히 논리적인 기계일 수 있다. 코드는 예상할 수 있는 정해진 방식으로 실행되고 모든 버그에는 다 이유가 있기 마련이다. 디버거를 끌어내고 로그 파일을 스크롤하면서 코드를 면밀히 검토하면 된다.

문제는 그럴 충분한 시간을 가진 사람이 없다는 점이다. 기술 지원 문제 중 90%는 장치의 전원을 껐다 켜면 해결되는 것처럼 느껴지듯, 데브옵스 작업의 상당 부분도 마찬가지다. 물론, ‘컨테이너’나 ‘인스턴스’ 같은 용어를 사용하고, 상황 추적을 위한 대시보드가 무수히 많기는 하지만, 결국에는 더 빠르고 간단한 방법은 그냥 넘어가는 것이고 아이리스 데멘트(Iris Dement)의 노래 제목처럼 ‘모르는 것은 모르는 채로 두게’ 된다. ciokr@idg.co.kr

X