2018.08.29

IDG 블로그 | 테스트 자동화 없이는 클라우드 데브옵스도 없다

David Linthicum | InfoWorld
저녁 8시 새로운 클라우드 네이티브 애플리케이션을 만들기 위한 스트린트를 완료하고자 한다. 데드라인은 정했다. 하지만 애플리케이션을 테스트 그룹에 보내는 데는 2주가 더 걸리고, 그 이후에 배치를 하고 운영팀에 넘겨야 한다. 아이디어에서 운영팀에 넘겨지는 데까지 걸린 시간을 고려하면 애자일 개발이 그다지 민첩하지 않은 것 같다.



뭐가 잘못됐을까? 오늘날의 문제는 클라우드 네이티브 애플리케이션의 테스트와 배치를 위한 자동화가 충분하지 않다는 것이다. 그래서 이 까다로운 사람들이 테스트 과정에서 개입해야만 하고, 이 때문에 작업은 더뎌지고 오류도 더 많아질 가능성이 크다. 게다가 클라우드 네티이브 애플리케이션의 테스트는 어떠해야 하는지 제대로 이해하고 있는 테스터도 충분하지 않아서 테스트를 위해 접근법이나 메커니즘을 파악하는 데도 시간이 지체된다.

클라우드 네이티브 암호화나 ID 및 액세스 관리 시스템을 사용해 애플리케이션의 안정성을 판단하는 역량을 예로 들 수 있다. 아니면 클라우드 네이티브 자동 확장 서비스를 사용해 6대의 서버 인스턴스를 확장하는 것이 충분한 규모인지를 파악하는 역량도 필요하다. 이들 역량은 특정 클라우드 서비스 업체에 특화된 것이다.

많은 전문가가 클라우드 네이티브 애플리케이션을 이렇게 테스트하라고 한다. 이를 통해 클라우드 네이티브란 무엇이고 어떤 것인지, 베스트 프랙티스는 무엇인지, 좋은 클라우드 네이티브 애플리케이션과 그렇지 않은 애플리케이션은 무엇인지 등에 대해 더 많은 것을 알 수 있다는 것.

하지만 필자의 조언은 이런 모든 것을 한꺼번에 없애 버리라는 것이다. 대신 책임을 클라우드 네이티브 애플리케이션 개발자에게 다시 맡겨 테스트를 자동화하는 스크립트를 포함한 테스트 계획까지 수행하도록 한다. 물론 플랫폼을 어떻게 설정하고 애플리케이션이 어디서 실행되는지를 클라우드 서비스 업체에 알려주는 IAC(infrastructure as code)도 맡겨야 한다.

필자가 지금 설명하고 있는 접근법은 데브옵스 컨퍼런스에서 파워포인트 발표는 정말 잘 된다. 하지만 정작 현실에서는 제대로 받아들여지지 않고 있다. 데브옵스와 클라우드 컴퓨팅을 사용하는 대부분 기업에서 ‘끊어진 고리’로 남아 있다. 실제로 필자는 클라우드 네이티브 애플리케이션 테스트 프로세스가 계속 대부분 수작업 프로세스로 남아 있고 일부 자동화가 보조하는 것으로 추정한다.

우리가 원하는 환경은 아니다. 클라우드 네이티브 애플리케이션의 테스트 자동화는 사람이 필요 없는 환경이다. 테스트 대부분은 애플리케이션을 만든 개발자가 정의한 방식으로 자동으로 진행된다. 게다가 오늘날의 데브옵스에서 보이는 지연을 줄이는 효과도 가져다주며, 심지어 배치 전에 애플리케이션을 더 잘 테스트할 수 있다. 그리고 결과적으로 운영팀과 사용자도 훨씬 더 행복해진다.  editor@itworld.co.kr


2018.08.29

IDG 블로그 | 테스트 자동화 없이는 클라우드 데브옵스도 없다

David Linthicum | InfoWorld
저녁 8시 새로운 클라우드 네이티브 애플리케이션을 만들기 위한 스트린트를 완료하고자 한다. 데드라인은 정했다. 하지만 애플리케이션을 테스트 그룹에 보내는 데는 2주가 더 걸리고, 그 이후에 배치를 하고 운영팀에 넘겨야 한다. 아이디어에서 운영팀에 넘겨지는 데까지 걸린 시간을 고려하면 애자일 개발이 그다지 민첩하지 않은 것 같다.



뭐가 잘못됐을까? 오늘날의 문제는 클라우드 네이티브 애플리케이션의 테스트와 배치를 위한 자동화가 충분하지 않다는 것이다. 그래서 이 까다로운 사람들이 테스트 과정에서 개입해야만 하고, 이 때문에 작업은 더뎌지고 오류도 더 많아질 가능성이 크다. 게다가 클라우드 네티이브 애플리케이션의 테스트는 어떠해야 하는지 제대로 이해하고 있는 테스터도 충분하지 않아서 테스트를 위해 접근법이나 메커니즘을 파악하는 데도 시간이 지체된다.

클라우드 네이티브 암호화나 ID 및 액세스 관리 시스템을 사용해 애플리케이션의 안정성을 판단하는 역량을 예로 들 수 있다. 아니면 클라우드 네이티브 자동 확장 서비스를 사용해 6대의 서버 인스턴스를 확장하는 것이 충분한 규모인지를 파악하는 역량도 필요하다. 이들 역량은 특정 클라우드 서비스 업체에 특화된 것이다.

많은 전문가가 클라우드 네이티브 애플리케이션을 이렇게 테스트하라고 한다. 이를 통해 클라우드 네이티브란 무엇이고 어떤 것인지, 베스트 프랙티스는 무엇인지, 좋은 클라우드 네이티브 애플리케이션과 그렇지 않은 애플리케이션은 무엇인지 등에 대해 더 많은 것을 알 수 있다는 것.

하지만 필자의 조언은 이런 모든 것을 한꺼번에 없애 버리라는 것이다. 대신 책임을 클라우드 네이티브 애플리케이션 개발자에게 다시 맡겨 테스트를 자동화하는 스크립트를 포함한 테스트 계획까지 수행하도록 한다. 물론 플랫폼을 어떻게 설정하고 애플리케이션이 어디서 실행되는지를 클라우드 서비스 업체에 알려주는 IAC(infrastructure as code)도 맡겨야 한다.

필자가 지금 설명하고 있는 접근법은 데브옵스 컨퍼런스에서 파워포인트 발표는 정말 잘 된다. 하지만 정작 현실에서는 제대로 받아들여지지 않고 있다. 데브옵스와 클라우드 컴퓨팅을 사용하는 대부분 기업에서 ‘끊어진 고리’로 남아 있다. 실제로 필자는 클라우드 네이티브 애플리케이션 테스트 프로세스가 계속 대부분 수작업 프로세스로 남아 있고 일부 자동화가 보조하는 것으로 추정한다.

우리가 원하는 환경은 아니다. 클라우드 네이티브 애플리케이션의 테스트 자동화는 사람이 필요 없는 환경이다. 테스트 대부분은 애플리케이션을 만든 개발자가 정의한 방식으로 자동으로 진행된다. 게다가 오늘날의 데브옵스에서 보이는 지연을 줄이는 효과도 가져다주며, 심지어 배치 전에 애플리케이션을 더 잘 테스트할 수 있다. 그리고 결과적으로 운영팀과 사용자도 훨씬 더 행복해진다.  editor@itworld.co.kr


X