calmglow (최진호)

이 글을 쓰기에 앞서 우선 나는  REST에 대하여 아주 우호적이며, 국내 어떤 개발자보다 일찍(2003년) REST를 기업에 적용해서 그 장점과 단점을 누구보다 충분히 알고 있다는 것을 언급하고 싶다.

이미 이 글을 여기까지 읽었다면 REST에 대해서 아는 이 일거라 가정하고 좀 더 나의 고민을 풀어가보겠다.

엔터프라이즈 애플리케이션을 비롯하여 대부분의 애플리케이션은 추상화 과정을 통해 그 아키텍처에 계층을 구성하고 이 계층이 많아질 수록 추상화가 높아지며 그 계층이 보통 다음과 같이 세가지 이상의 단계로 구성이 된다.

• Data Access 계층
• Domain 계층
• 서비스 계층
• (Presentation 계층)

이렇게 계층화를 시도하면 서비스 계층에서는 주로 Use case의 비즈니스 관점의 업무로직을 다루게 되어 보다 재사용 가능하고 유연한 구조를 획득하게 된다. 이 서비스에서는 다양한 내부 트랜잭션들을 수행하기 마련이다. 따라서 Data access에서 서비스 계층으로 나아갈 수록 인터페이스는 보다 Coarse grained하게 그 특성이 변하게 된다.

XX은행에서 돈을 '이체한다'라는 서비스는 실제로는 다양한 업무 트랜잭션을 내부에 감추고 있고 이러한 추상화를 통해 개발 생산성 뿐만 아니라 성능적인 문제에 있어서도 훨씬 더 나은 효과를 가져다주기 마련이다.

그런데 Web 2.0시대에 오면서 REST api를 여러 엔터프라이즈 프로젝트나 모바일 관련 프로젝트 등에서 자주 사용되고 있는 것을 접하고는 하는데, 과연 REST의 특성이 이러한 Coarse grained한 업무 서비스 설계에 어울리는 인터페이스인가 하는 진지한 고민을 할 필요가 있다는 게 이 글의 요지이다.

REST는 말 그대로 자원에 대한 접근을 URL과 HTTP method를 통해 허용하는 방식이다. 그러다보니 아무리 서비스스러운 API 설계를 잘한다고 해도 그 근간은 Domain이나 Data 위주일 수밖에 없다. 조금이라도 복잡한 비즈니스 트랜잭션을 수행하려면 자원관점에서는 설계하기 까다로운 상황이 자주 발생하며, 이러한 복합 트랜잭션이나 업무 트랜잭션 처리를 presentation, client 영역에 떠넘기게 되는 상황이 발생하곤 한다.

이게 왜 문제냐면, 이러한 진지한 고민없이 REST를 주요 인터페이스로 프로젝트를 끌고 가다보면 Open직전에 Coarse grained하지 않은 client와 서비스간 잦는 호출 문제로 인하여 성능에 엄청난 악영향을 미치게 되기 때문이다. REST는 아키텍트가 설계하기는 편하지만 여러가지 비즈니스이슈와 성능 및 트랜잭션 이슈등을 무시하게 되는 상황을 만들 여지가 큰 인터페이스인 것이다.

클라이언트 개발자는 REST가 편하다고 엄청나게 많은 비동기 AJAX call을 서버에 때려버리고, 예전같으면 page call 트랜잭션 한번이면 끝날 것을 수없이 많은 fine grained한 call로 성능을 느리게 만들어버린다.

따라서 내가 이야기하고 싶은 결론은, 유행이라고 하여 REST와 AJAX기반의 fine grained한 클라이언트와 서버간 통신을 남발하다가는 프로젝트 말미에 엄청난 고생을 할 여지가 있으니, REST는 꼭 필요한 때에만 사용하는 것이 좋지 않겠는가 하는 것이다.
굳이 꼭 main interface로 써야한다면 REST를 굳이 domain model 관점에서 인터페이스 구성하지 말고 정말 업무로직 관점에서 설계하여 애초에 자원 접근은 막고 업무로직 기반의 Coarse grained한 서비스를 설계하는 자세가 필요할 것이다.