Steve Vinoski의 ‘Convenience Over Correctness‘라는 글에 대한 글이다.
Steve Vinoski는 CORBA Guru라고 불리우고 대형 CORBA 벤더 중 하나였던 IONA의 수석 아키텍트 (chief architect and fellow)였으며 CORBA 분야에선 바이블이라고 볼 수 있는 Advanced CORBA Programming with C++의 저자 중 한명이다. 현재는 CORBA와 같은 approach에 회의를 느끼고 IONA를 그만두었으며 최근에 그의 블로그를 보면 REST에 특히 관심을 보이고 있다.
예전에 A Note on Distributed Computing라는 제목의 페이퍼에 관해 요약한 적이 있다. 당시에 Sun RPC나 CORBA 등의 예를 들어 이 문제를 논해주면 좋겠다고 언급했었는데, ‘Convenience Over Correctness’가 바로 그런 글이다.
RPC 시스템의 본질
RPC-oriented systems generally represent remote services using the same abstractions and facilities used to represent local services, thus letting developers stay conveniently within the comfortable confines of their programming languages.
RPC 시스템의 본질은 A Note on Distributed Computing에서 언급된 문제들 – partial failure 등과 같은 문제를 가지고 있음에도 불구하고 프로그래머의 편이성을 얻기 위한 시스템이란 것이다.
RPC 시스템의 문제점들
그는 이어서 ‘A Note…’에서 언급된 문제 이외의 문제를 얘기하는데, 첫번째는 ‘Impedance Mismatch’ 문제로, CORBA IDL을 CORBA가 지원하는 여러 언어들로 mapping할 때 발생하는 문제를 얘기하고 있다. 두가지 이상의 언어를 대상으로 RPC 시스템을 만들어본 사람이라면 금방 이해할텐데, 서로 다른 언어의 타입 등을 mapping하기란 쉽지 않고, 설령 mapping이 가능하더라도 그것이 그 언어에 자연스럽지 않다는 것이다.
두번째 문제는 ‘Scalability Concerns’ 문제다. 분산된 시스템은 흔히 performance나 scalability를 위해 캐싱이나 필터링, 모니터링, 로깅 등을 관장하는 intermediary 시스템을 두는데, 이를 RPC 시스템에서 표현하기 위해서는 RPC call을 위한 정보 이상의 정보 즉, 메타데이터가 필요하다. 이를 위해서 현대의 RPC 시스템에서는 Java나 C# 등에서 지원하는 annotation을 이용하는데, 이러한 접근은 transparency라는 환상을 위해 복잡성을 추가할 뿐이라는 것이다.
이 문제에 있어서, Steve는 REST를 대안으로 내세운다. 네트워크의 영향을 시스템이 인지하면서도 깔끔한 layering과 separation of concerns를 유지한다는 것이다. REST를 다시 programming language 아래로 숨기려는 시도들을 비판하고 있다.
그는 RPC 시스템이 개발자의 편이성을 위해서 그 문제를 정확히 인지하고 있음에도 불구하고, 취약한 abstraction layer들과 임시 방편(bandages)들을 쌓아 올린 것에 불과하다고 본다. 그리고, distributed computing과 programming languages의 역사가 distributed computing의 necessary complexity를 너무 어려운 문제로 보고 프로그래머의 편이성을 위해 제대로 동작하지 않는 시스템을 만들어냈다고 비판한다.
대안
그는 RPC 시스템 대신 message queing 시스템이 발전했어야 한다고 강조하며, message queuing 시스템이 상용 제품에서도 대단히 비싸고 OSS 제품들도 최근의 XMPP나 AMQP 구현 외에는 없다는 점에 대해서 유감을 표하며, Facebook Thrift나 Cisco Etch가 XMPP/AMQP를 지원하거나 RESTful HTTP에 기반해야 하지 않겠냐는 의견을 피력한다.
결론
결론은 Steve의 글을 인용하는 것으로 마무리 하겠다.
(Facebook Thrift and Cisco Etch); perhaps both cases are instances of those not knowing history being doomed to repeat it.
It’s time for RPC to retire. I won’t miss it.
의견
한마디로 말하자면, Steve의 의견은 ‘Convenience가 정말 중요하고 실재하는 것인가? 오히려 Correctness가 중요하지 않은가?’인데, 내 생각은 ‘Convenience의 이익은 생각보다 크고 Correctness보다 Convenience가 중요할 때도 있다.’라는 것이다.
그럼에도 불구하고 Steve의 생각들은 구구절절 옳기 때문에, 주어진 문제에 따라서 접근 방법을 다르게 해야한다고 생각한다. 이를테면, intermediation이 많이 게재되거나 게재될 가능성이 있는 시스템에서는 애초에 RPC 접근을 하기 보다는 MQ 접근을 한다든가, RPC 시스템을 만들더라도 완벽한 transparancy에 목매지 않는 것이 그것이다.
기술이 항상 옳은 방향으로 발전하는 것은 아니지만, 실제적인 프랙티스로 반영되지 않는 것은, 그 기술의 방향이 옳지 않다는 것 이외의 다른 이유들 – 그런 기술을 수용하기 위한 기반 기술들이 마련되지 않았다라든가 – 이 있을 수 있다고 보는 편이다. 아직은 MQ/RESTful HTTP는 실험적이다. 하지만, 이들을 주시하고 지켜볼 일이다.