2021.07.21

IDG 블로그 | 클라우드 네이티브의 코드 재사용이 철칙은 아니다.

David Linthicum | InfoWorld
코드 재사용은 필자가 초급 코볼 프로그래머였던 1980년대 이후로 개발자에게는 전쟁터의 함성 같은 것이었다. 우리는 여러 번 호출할 수 있는 함수를 정의했고, 구조적 프로그래밍의 시대가 시작됐다.
 
ⓒ Getty Images Bank

그때 이후 우리는 C나 객체 지향 C++ 같은 언어를 편력하며 재사용이 좋다는 관념을 확실히 했다. 그 다음은 분산 객체와 SOA(Service Oriented Architecture) 서비스로 흘러가면서 재사용은 하나의 애플리케이션 단위를 벗어나 성장했고, 느슨하게 연결되고 서로 다른 플랫폼에 있는 재사용할 수 있는 서비스로 발전했다. 지금은 클라우드 서비스나 API라는 개념, 그리고 새로운 차원의 세밀한 공유를 제공하는 마이크로서비스란 매력적인 개념도 있다.

재사용 또는 공유라는 개념은 클라우드와 비 클라우드 개발자 모두에게 새로운 의미를 갖는다. 2022년 현재 많은 개발자 DRY(Don’t Repeat Yourself)란 약어를 애플리케이션과 시스템을 구축하고 배치하는 새로운 슬로건으로 삼고 있다. 하지만 DRY는 말처럼 쉽지 않다. 

필자는 오랫동안 서비스 기반 애플리케이션을 구축하면서 두 가지 서로 다른 실수를 저질렀다. 너무 많이 재사용하는 실수와 충분히 재사용하지 않는 실수이다.

과도한 재사용이란 같은 서비스를 반복적으로 사용함으로써 생산성이 감소하거나 심한 경우 생산성을 해칠 경우를 말한다. 애플리케이션의 요구를 만족하기 위해서는 추상화하고 일부 기능을 변경해야 하는 서비스를 재사용이란 개념을 고집해 그대로 이용한다면, 이런 결과를 낳을 수 있다. 예를 들어, 모든 고객의 정보가 있는 고객 신용 데이터에 액세스하는 서비스를 사용하지만, 해당 애플리케이션의 용도에서는 응답이나 데이터 스트림에서는 공통 데이터가 필요 없어 삭제해야 하는 경우가 있다.

이런 경우에도 억지로 재사용하는 경우가 많다. 애플리케이션 개발은 재사용되는 서비스의 혼합물이 되고 있으며, 반드시 재사용해야 하거나 그렇지 않거나 가리지 않는다. 게다가 이런 비효율성은 흔히 코드 검토나 코드 검사 단계에서 간과되곤 하는데, 재사용이 때에 따라 비생산적일 수도 있다는 생각을 하지 않기 때문이다. 필자보다 코드를 더 많이 다루는 일부 개발자는 과도한 재사용으로 생산성이 떨어지는 문제를 우려할 것이라고 확신한다. 하지만 그렇다고 한 번 쓸 서비스와 마이크로서비스를 새로 구축하던 시절로 돌아가자는 말은 아니다. 

요컨대, 재사용 가능한 서비스를 이용하는 것의 장단점을 정확하게 이해해야 한다. 재사용 가능한 서비스를 어떻게 설계하고 배치해야 하는지도 알아야 한다. 핵심적인 질문은 이렇다. 이들 서비스를 재사용하는 것이 애플리케이션을 더 좋게 만드는가? 재사용하는 서비스를 다시 설계해 배치해야만 하는가? 아니면 용도에 맞는 새로운 서비스를 만들어야 하는가?

때로는 다른 경로를 택하는 것이 더 생산적이라는 사실을 알게 될 것이다. 어떤 서비스를 재사용해야 하는지에 관해 좀 더 열린 마음을 가질 필요가 있다. 더 중요한 것은 인기 있는 철학에 자신의 선택을 억지로 맞추려고 할 때를 아는 것이다. 필자라면 언제라도 무리를 따르는 대신 생산성을 선택할 것이다. editor@itworld.co.kr


2021.07.21

IDG 블로그 | 클라우드 네이티브의 코드 재사용이 철칙은 아니다.

David Linthicum | InfoWorld
코드 재사용은 필자가 초급 코볼 프로그래머였던 1980년대 이후로 개발자에게는 전쟁터의 함성 같은 것이었다. 우리는 여러 번 호출할 수 있는 함수를 정의했고, 구조적 프로그래밍의 시대가 시작됐다.
 
ⓒ Getty Images Bank

그때 이후 우리는 C나 객체 지향 C++ 같은 언어를 편력하며 재사용이 좋다는 관념을 확실히 했다. 그 다음은 분산 객체와 SOA(Service Oriented Architecture) 서비스로 흘러가면서 재사용은 하나의 애플리케이션 단위를 벗어나 성장했고, 느슨하게 연결되고 서로 다른 플랫폼에 있는 재사용할 수 있는 서비스로 발전했다. 지금은 클라우드 서비스나 API라는 개념, 그리고 새로운 차원의 세밀한 공유를 제공하는 마이크로서비스란 매력적인 개념도 있다.

재사용 또는 공유라는 개념은 클라우드와 비 클라우드 개발자 모두에게 새로운 의미를 갖는다. 2022년 현재 많은 개발자 DRY(Don’t Repeat Yourself)란 약어를 애플리케이션과 시스템을 구축하고 배치하는 새로운 슬로건으로 삼고 있다. 하지만 DRY는 말처럼 쉽지 않다. 

필자는 오랫동안 서비스 기반 애플리케이션을 구축하면서 두 가지 서로 다른 실수를 저질렀다. 너무 많이 재사용하는 실수와 충분히 재사용하지 않는 실수이다.

과도한 재사용이란 같은 서비스를 반복적으로 사용함으로써 생산성이 감소하거나 심한 경우 생산성을 해칠 경우를 말한다. 애플리케이션의 요구를 만족하기 위해서는 추상화하고 일부 기능을 변경해야 하는 서비스를 재사용이란 개념을 고집해 그대로 이용한다면, 이런 결과를 낳을 수 있다. 예를 들어, 모든 고객의 정보가 있는 고객 신용 데이터에 액세스하는 서비스를 사용하지만, 해당 애플리케이션의 용도에서는 응답이나 데이터 스트림에서는 공통 데이터가 필요 없어 삭제해야 하는 경우가 있다.

이런 경우에도 억지로 재사용하는 경우가 많다. 애플리케이션 개발은 재사용되는 서비스의 혼합물이 되고 있으며, 반드시 재사용해야 하거나 그렇지 않거나 가리지 않는다. 게다가 이런 비효율성은 흔히 코드 검토나 코드 검사 단계에서 간과되곤 하는데, 재사용이 때에 따라 비생산적일 수도 있다는 생각을 하지 않기 때문이다. 필자보다 코드를 더 많이 다루는 일부 개발자는 과도한 재사용으로 생산성이 떨어지는 문제를 우려할 것이라고 확신한다. 하지만 그렇다고 한 번 쓸 서비스와 마이크로서비스를 새로 구축하던 시절로 돌아가자는 말은 아니다. 

요컨대, 재사용 가능한 서비스를 이용하는 것의 장단점을 정확하게 이해해야 한다. 재사용 가능한 서비스를 어떻게 설계하고 배치해야 하는지도 알아야 한다. 핵심적인 질문은 이렇다. 이들 서비스를 재사용하는 것이 애플리케이션을 더 좋게 만드는가? 재사용하는 서비스를 다시 설계해 배치해야만 하는가? 아니면 용도에 맞는 새로운 서비스를 만들어야 하는가?

때로는 다른 경로를 택하는 것이 더 생산적이라는 사실을 알게 될 것이다. 어떤 서비스를 재사용해야 하는지에 관해 좀 더 열린 마음을 가질 필요가 있다. 더 중요한 것은 인기 있는 철학에 자신의 선택을 억지로 맞추려고 할 때를 아는 것이다. 필자라면 언제라도 무리를 따르는 대신 생산성을 선택할 것이다. editor@itworld.co.kr


X