시스템 개선을 위한 REST API 도입?

안내: 이 글은 운영을 중단한 개인 블로그에 2015년 6월 9일 올렸던 글입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다.

어떤 경로나 동기로 찾았는지 지금은 기억나지 않지만, StackOverflow의 REST 관련 질문이 눈에 들어왔다. 인터페이스 계층과 비즈니스 계층 사이에 인터페이스로 API를 두는 것이 바람직한 아키텍처 설계인지 그리고 API 구축에 REST를 채용하는 것이 적절하냐(is it a good architectural design to have an API (web service) as the interface between the interface layer and business layer? Is REST a good “tool” for that?)는 질문이었다.

답한 이는 질문을 둘로 나눠 하나씩 답을 했다. 먼저 인터페이스 계층과 비즈니스 계층사이에 API를 두어야 하느냐는 질문(Firstly, should you use an API between the interface layer and the business layer?)에는 (상황에 따라 판단해야겠지만) 긍정으로 답했다. 본인의 현재 프로젝트도 그러하다며 클라이언트 유형이 복수라면 유효한 방법이며, 향후 버그 수정이나 기능 추가할 때 (1곳만 하면 되니) 이점이 드러나지만 테스트 등이 번거로워지는 점을 고려해야 한다고 설명한다.

질문의 다른 한 부분인 API 구현할 때 REST를 사용해야 하느냐(Secondly, if you implement an API, should you use REST?)에 대해서는 대체로 비판적 의견으로 답했다. 그가 제시한 근거는 REST는 아키텍처일 뿐이라 API  구축을 위해 추가로 고려해야 할 부분이 많은데, 리소스라는 개념을 중심으로 하는 REST 아키텍처는 비즈니스 계층으로 변환하는데는 한계가 있다는 것이다. 반면에 REST API가 적절한 경우는 넷플릭스 등의 경우처럼 OPEN API로 다른 개발자들이 해당 API를 사용하여 빈번하게 개발하는 경우를 들었다.

얼마 전에 모회사 팀장님으로부터 연락을 받아 만난 일이 있는데, 그 자리에서 주고 받은 대화 내용과 꽤 비슷한 듯해서 매우 흥미로웠다. 물론, 컨설팅 의뢰 과정에서 만난 것이라 StackOverflow의 질문과 답변처럼 명확하지는 않았다. 비슷한 점은 그 팀장님의 궁금증도 중의적이었고, REST 효용성을 묻고 있었다는 점이다. 첫번째 미팅 테이블에서 정확한 설명은 어렵기 때문에 느슨하게 답했는데, 여기 좀 더 부연을 기록해둔다. 의뢰인(그 팀장님이란 표현 대신 의뢰인이라 한다)은 회사 시스템 운영 효율성 저하를 해결하기 위한 점진적인 계획의 일환으로 REST API 도입을 고려중이었다. 구체적으로는 (쉽게 수정할 수 없는 동시에 섣불리 걷어낼 수 없는) 주요 레거시 시스템을 대상으로 REST API를 도입하면 효과가 있을 것인가에 대한 질문이었다.  나는(이미 그곳에서 자바로 프로그래밍을 하고 있기 때문에) REST API 대신 Java API를 먼저 도입하라고 권유했다.  점진적인 개선책으로 API를 도입하는 것은 마치 건물을 새로 지을 수 없는 상황에서 리모델링만 하여 쓰는 것에 비유할 수 있다.  과거에 모 프로젝트에서 매뉴얼과 다르게 동작하는 레거시 EAI를 보완하기 위해, EAI 호출부분과 결과 수령부분을 감싸서 잘못된 파라미터나 결과값에 대해 적절한 메시지를 클라이언트에게 던져주는 일을 하는 클래스(Wrapper class)를 만든 일이 있다. 해당 클래스의 오퍼레이션(혹은 메소드)만 호출하는 식으로 레거시와 연계를 하면 결국 레거시를 활용하는 다른 시스템은 해당 클래스의 API에만 의존하게 되어 레거시 시스템을 직접 건드리지 않고도 개선 효과를 낼 수 있다. 더불어 이렇게 구축된 시스템을 운영하면 부차적으로 레거시의 쓰임새에 대한 이해도 높아진다. 결국, 시스템을 단계적으로 이행한다는 시각으로 보면 ‘차세대 딜레마의 대안’이 될 수도 있다고 생각하는데, 이는 다음 기회에 다뤄보도록 하겠다.

아무튼 이런 용도로 API를 추가할 때는 REST를 바로 채용할 이유는 없다. 앞서 예를 든 StackOverflow 답변에서는 엄밀한 용어 사용(we’ve gone for XML over HTTP, because we don’t need the benefits that Rest generally offers)을 예로 들면서 “쓰임새에 맞는 솔루션”을 말한다. 나는 여기에 더해서 점진적 접근의 효과를 말하고 싶다. 바로 REST API를 채용하는 경우는 한번에 다뤄야 할 문제가 켜져 일을 어렵게 만들곤 한다. (실제로 프로젝트에서 이와 같은 이유로 혼선을 겪은 바 있다.) 반대로 Java API로 만들고, 클라이언트가 다른 언어(예를 들면, 닷넷 클라이언트)나 모바일 앱인 경우는  JSON over HTTP로 바꿔가는 접근을 하는 것이 문제를 나누어서 집중하는데 유리하다. 설사, REST 도입이 필요하다고 해도 이렇게 접근한 경우 부가적으로 몇 가지 작업을 추가하면 될 뿐이니까. 문제를 분할하여 해결하는 방법(Divide and conquer)은 인류의 역사를 통해 검증된 방법이고, 소프트웨어 개발이라고 해서 예외는 아니다.