2017.06.13

IDG 블로그 | 서버리스 컴퓨팅과 리팩터링의 함정

David Linthicum | InfoWorld
AWS 람다나 마이크로소프트 애저 펑션즈 같은 툴을 사용하면 서버리스 애플리케이션을 개발할 수 있다. 하지만 너무나 많은 개발자가 잘못된 애플리케이션에 사용하고 있다.

Image Credit : GettyimagesBank

서버리스 컴퓨팅이 폭발적인 인기를 구가하고 있다. 물론 충분한 이유가 있다.

- 서버를 직접 프로비저닝할 필요가 없다. 그냥 기능을 작성하면, 필요한 자원이 자동으로 해당 기능에 할당된다.
- 사용한 자원에 대해서만 돈을 낸다. 서버를 계속 구동할 필요가 없으며, 월말에 엄청난 요금 고지서를 받을 필요도 없다.
- 자동으로 확장할 수 있다. 수요에 따라서 어떤 클라우드 서비스를 확장해야 하는지 결정하면 그대로 이루어진다.

아마존 웹 서비스의 AWS 람다나 마이크로소프트 애저 펑션즈는 이런 서버리스 컴퓨팅의 가장 잘 알려진 예로, 두 서비스 모두 이미 몇 년 된 상태이다. 하지만 몇몇 영역에서는 큰 성공을 거두었지만, 아직 손을 봐야 하는 영역도 있다.

서버리스 컴퓨팅과 관련해 부족한 것은 기술이 아니라 사용 방법이다. AWS나 마이크로소프트에 책임을 물을 수 없는 문제이다. 기업 개발부서가 그저 서버리스 컴퓨팅을 적용할 애플리케이션을 잘못 고른 것이다.

예를 들어, 새로운 애플리케이션은 서버리스 컴퓨팅에 잘 맞지만, 오래된 애플리케이션은 잘 맞지 않는 경우가 있다. 그리고 이들 오래 된 애플리케이션을 서버리스 환경으로 이전하는 것은 절감 비용보다 더 많은 작업을 해야 할 수도 있다. 가장 큰 이유는 서비스리스 컴퓨팅 시스템이 모든 프로그래밍 언어를 지원하는 것은 아니기 때문이다.

프로그래밍 언어를 지원한다고 해도 서버리스 컴퓨팅의 장점을 제대로 취할 수 있도록 애플리케이션을 재작성하는 리팩터링(Refactoring) 작업에 엄청난 노력이 투여된다. 이런 리팩터링 작업은 애플리케이션을 여러 기능의 집합으로 되돌리는 것으로, 본질적으로는 애플리케이션을 새로 개발하는 데 가깝다. 서버리스 컴퓨팅의 이점이 이런 리팩터링 작업까지 할 만큼 크지는 않으며, 특히 이 때문에 새로운 애플리케이션을 만드는 일이 지연된다면 최상의 선택은 아니다.

리팩터링에 많은 노력이 투여된다면, 서버리스 컴퓨팅의 가능성은 전혀 얻을 수 없다. 리팩터링은 개발 자원의 어디에 투여할 것인지 우선순위를 정하는 데 나쁜 영향을 미친다. 필자는 서버리스 컴퓨팅의 약속에 이끌려 오래된 애플리케이션을 서버리스 시스템으로 만드는 데 필요한 노력을 과소평가한 나머지 비즈니스 측면에서 더 중요한 미치는 애플리케이션 개발을 뒤로 미루는 경우를 너무나 많이 봤다.

기업 개발 부서는 전에도 이런 실수를 한 적 있다. 바로 모든 것을 컨테이너로 만들겠다는 것이었는데, 잘못된 접근이라는 것이 금방 밝혀졌다. 이유는 여러 가지겠지만, IT 사람들은 새로 떠오르는 기술을 판단할 때마다 이런 과거의 실수를 너무 쉽게 잊어버린다.

기술을 정확하게 적용하는 못하는 능력은 마치 유전자에 새겨진 것처럼 계속 반복된다. 언젠가 “역사로부터 배우지 않으면 그 역사를 반복하게 된다”는 말을 제대로 이해할 날이 올지도 모른다. editor@itworld.co.kr


2017.06.13

IDG 블로그 | 서버리스 컴퓨팅과 리팩터링의 함정

David Linthicum | InfoWorld
AWS 람다나 마이크로소프트 애저 펑션즈 같은 툴을 사용하면 서버리스 애플리케이션을 개발할 수 있다. 하지만 너무나 많은 개발자가 잘못된 애플리케이션에 사용하고 있다.

Image Credit : GettyimagesBank

서버리스 컴퓨팅이 폭발적인 인기를 구가하고 있다. 물론 충분한 이유가 있다.

- 서버를 직접 프로비저닝할 필요가 없다. 그냥 기능을 작성하면, 필요한 자원이 자동으로 해당 기능에 할당된다.
- 사용한 자원에 대해서만 돈을 낸다. 서버를 계속 구동할 필요가 없으며, 월말에 엄청난 요금 고지서를 받을 필요도 없다.
- 자동으로 확장할 수 있다. 수요에 따라서 어떤 클라우드 서비스를 확장해야 하는지 결정하면 그대로 이루어진다.

아마존 웹 서비스의 AWS 람다나 마이크로소프트 애저 펑션즈는 이런 서버리스 컴퓨팅의 가장 잘 알려진 예로, 두 서비스 모두 이미 몇 년 된 상태이다. 하지만 몇몇 영역에서는 큰 성공을 거두었지만, 아직 손을 봐야 하는 영역도 있다.

서버리스 컴퓨팅과 관련해 부족한 것은 기술이 아니라 사용 방법이다. AWS나 마이크로소프트에 책임을 물을 수 없는 문제이다. 기업 개발부서가 그저 서버리스 컴퓨팅을 적용할 애플리케이션을 잘못 고른 것이다.

예를 들어, 새로운 애플리케이션은 서버리스 컴퓨팅에 잘 맞지만, 오래된 애플리케이션은 잘 맞지 않는 경우가 있다. 그리고 이들 오래 된 애플리케이션을 서버리스 환경으로 이전하는 것은 절감 비용보다 더 많은 작업을 해야 할 수도 있다. 가장 큰 이유는 서비스리스 컴퓨팅 시스템이 모든 프로그래밍 언어를 지원하는 것은 아니기 때문이다.

프로그래밍 언어를 지원한다고 해도 서버리스 컴퓨팅의 장점을 제대로 취할 수 있도록 애플리케이션을 재작성하는 리팩터링(Refactoring) 작업에 엄청난 노력이 투여된다. 이런 리팩터링 작업은 애플리케이션을 여러 기능의 집합으로 되돌리는 것으로, 본질적으로는 애플리케이션을 새로 개발하는 데 가깝다. 서버리스 컴퓨팅의 이점이 이런 리팩터링 작업까지 할 만큼 크지는 않으며, 특히 이 때문에 새로운 애플리케이션을 만드는 일이 지연된다면 최상의 선택은 아니다.

리팩터링에 많은 노력이 투여된다면, 서버리스 컴퓨팅의 가능성은 전혀 얻을 수 없다. 리팩터링은 개발 자원의 어디에 투여할 것인지 우선순위를 정하는 데 나쁜 영향을 미친다. 필자는 서버리스 컴퓨팅의 약속에 이끌려 오래된 애플리케이션을 서버리스 시스템으로 만드는 데 필요한 노력을 과소평가한 나머지 비즈니스 측면에서 더 중요한 미치는 애플리케이션 개발을 뒤로 미루는 경우를 너무나 많이 봤다.

기업 개발 부서는 전에도 이런 실수를 한 적 있다. 바로 모든 것을 컨테이너로 만들겠다는 것이었는데, 잘못된 접근이라는 것이 금방 밝혀졌다. 이유는 여러 가지겠지만, IT 사람들은 새로 떠오르는 기술을 판단할 때마다 이런 과거의 실수를 너무 쉽게 잊어버린다.

기술을 정확하게 적용하는 못하는 능력은 마치 유전자에 새겨진 것처럼 계속 반복된다. 언젠가 “역사로부터 배우지 않으면 그 역사를 반복하게 된다”는 말을 제대로 이해할 날이 올지도 모른다. editor@itworld.co.kr


X