[CS] Code-on-Demand가 잘 쓰이지 않는 이유는 무엇일까? (aka 유일한 optional 원칙 in REST API)

REST API 6원칙 중 유일한 Optional, Code on Demand

REST API에는 6가지 원칙이 있다.
그중에서 유일하게 optional 한 원칙이며, 현재는 잘 사용되지 않는 녀석이 있는데, 바로 code on demand 원칙이다.

Code on Demand 원칙이란

Code-on-demand 원칙이란 RESTful 웹 서비스에서 서버가 클라이언트에게 실행 가능한 코드를 다운로드하여 실행할 수 있는 기능을 제공하는 것을 의미한다. 이 기능은 시스템에 유연성과 확장성을 제공할 수 있다는 장점이 있다.

Code on Demand가 잘 지켜지지 않는 이유

1. 보안 문제

가장 큰 이유로써, 서버에서 실행 가능한 코드를 클라이언트로 전송하는 것은 보안 문제를 야기할 수 있다는 점이다. 클라이언트 측에서 실행되는 코드는 서버 측의 컨트롤을 벗어나기 때문에 악용될 수 있는 위험이 존재한다. 따라서, 상당수의 서비스가 보안을 위해 code-on-demand 기능을 비활성화한다.

2. 호환성의 문제

서버에서 생성된 코드가 클라이언트 플랫폼에 따라 호환되지 않을 수 있다는 문제가 있다. RESTful 웹 서비스는 다양한 클라이언트와 상호 작용해야 하는데, 서버 측에서 실행 가능한 코드가 만일 특정 플랫폼에 종속되게 된다면 해당 API의 활용도가 떨어지게 될 것이다. 그래서 요즘 Code-on-demand 원칙으로 직접 실행가능한 코드를 클라이언트 측에서 실행하는 대신, 서버로부터 반환되는 데이터를 기반으로 클라이언트 애플리케이션에서 필요한 로직을 직접 구현하는 방식을 선호한다.

3. 성능 이슈

RESTful 웹 서비스는 캐싱을 활용하여 성능을 향상시키는 것이 중요하다. 하지만 코드 on demand를 지원하면 서버에서 반환되는 코드는 동적이므로 클라이언트에서 캐싱이 어렵다. 클라이언트 측에서 실행 가능한 코드가 자주 변경된다면 캐싱을 적용하기 어렵고, 매번 코드를 다운로드해야 하므로 성능에도 영향을 미칠 수 있다. 점점 하나의 서비스에서 다루는 데이터의 크기가 커지면서 캐싱의 중요성이 더욱 부각되는 최근의 트렌드와 견주어보면, code-on-demand의 편의성은 아무래도 후순위가 될 수 밖에 없다.

4. 코드 유지보수의 복잡성 증가

code-on-demand를 사용하면 클라이언트 애플리케이션의 복잡성이 증가할 수 있다는 어려움이 있다. 클라이언트에게 서버에서 실행 가능한 코드를 다운로드하고 관리하는 추가적인 작업이 필요하기 때문이다. 특히, 다양한 플랫폼에서 동작하는 클라이언트 애플리케이션을 개발해야 하는 경우 code-on-demand를 구현하고 유지 보수하는데 있어서 어려움을 초래할 수 있고, 점점 복잡해지고 있는 클라이언트 단의 개발환경을 고려한다면 code-on-demand 사용은 '굳이?' 라는 생각이 들게 한다.

번외) Code-on-demand 원칙의 등장에 대한 이해

위에서 살펴본 이유로, 사실상 code-on-demand 원칙은 REST API를 만들 때 요즘 거의 사용되고 있지 않다. 그렇다면 어쩌다 이러한 원칙이 끼어들게 된거지? 하는 궁금증이 든다.

그 궁금증에 대한 해답을 찾기 위해서는 로이 필딩이 REST 원칙에 대해 논문을 내던 시절을 살펴보면 된다. 당시에는 웹이란 대부분 정적 document들이었고, 웹 클라이언트 라는 것도 브라우저 그 자체였던 시절이다. 과거에는 클라이언트 단에서 필요한 로직을 구현하기에 충분하지 않았던 환경이었기 때문에 그랬던 건가 싶다.