Blog

출처. 이 글은 Tim Bray의 Comparing Frameworks라는 글을 번역한 것입니다. deepblue님의 웹 프레임워크 비교라는 글을 통해서 원문을 소개 받았습니다.

<br/>

문맥

여기서 다루는 문제는 웹 애플리케이션 개발이다. 그래서 우리는 연산 성능과 같은 일반적인 이슈를 고려하지 않을 것이다. 웹 애플리케이션은 그렇게 많은 계산을 하지 않기 때문이다. 브라우저로부터 어떤 값을 받고, 그 값을 이용해서 데이터베이스로부터 적절한 값을 가져와서 사용자에게 보고한다. 어쩌면 데이터베이스를 업데이트할지도 모른다. 기껏해야 그 정도다.

확장하기

연산을 해야 한다면, 자바가 가장 빠르다는 것은 분명하다. 웹 애플리케이션을 운영하는데 있어, 최대 확장성은 아마도 거의 비슷할 것이다. 왜냐하면 웹 애플리케이션은 연산을 많이 하지 않기 때문이다. 결국 EBay는 자바로 운영되고 있고, 위키피디아나 야후! 프랑스는 PHP 기반이다. 둘 다 "충분히 잘" 확장된다는 것이 분명하다.

웹 애플리케이션의 경우라면 PHP에 가장 높은 점수를 주겠다. 왜냐하면 확장성 있는 PHP를 구축하는 것이 좀 더 쉽다고 생각하기 때문이다. 기본적으로 PHP는 아무것도 공유하지 않는 아키텍쳐를 제공한다. 말인 즉, 데이터베이스가 한계에 부딪히기 전까진 아주 손 쉽게 확장해나갈 수 있다는 뜻이다. 자바는 훨씬 더 풍부한 시스템 (richer system)이고, 여러분이 아무것도 공유하지 않는 아키텍처가 적절한지 여부를 잘 알고 있다고 가정한다. 결국 자바로 PHP와 같은 정도의 확장성을 얻어내려면, 여러분이 좀 더 똑똑해야 한다.

Rails의 경우엔, 자바나 PHP와 마찬가지로 웹 기반의 확장성 있는 애플리케이션을 구축할 수 있으리라 생각한다. 단지, 누구도 그런 일을 해낸 것을 본 적이 없다는 것이 문제이다. 이외에도 Rails에 감점을 줘야 할 이유가 있다. 대부분의 애플리케이션이 결국 약간의 연산을 하게 되기 때문이다. 이런 측면에서 Rail는 다른 대안보다 뒤처져 있다.

역자 노트

Scalability: 확장성. 사용자수의 증대에 유연하게 대응할 수 있는 정도.

개발 속도

문제는 다른 조건이 동일하다면, 얼마나 빨리 웹 애플리케이션을 개발할 수 있느냐?라는 것이다. 나는 Rails가 새로운 기준을 마련했다고 생각한다. 여러분은 몇 년이 아닌 몇 주만에, 또는 몇 달이 아닌 며칠 만에 완성된 애플리케이션에 관한 놀라운 이야기를 계속해서 들어왔을 겁니다.

이미 언급한 바 있듯이, Rails 최고의 성공작인 CRUD 지향적 개발은 매우 잘 알려져 있다. 그러나 여전히 Rails가 다른 프레임워크에게 가르쳐 줄 교훈이 많은 것처럼 보인다. Java EE가 현재 나아가는 방향은 학습이 이뤄지고 있다는 증거라고 나는 생각한다.

PHP가 처음 유명해진 것은 빠르고 더러운 (quick-and-dirty) 방식으로 웹 애플리케이션을 개발할 수 있다는 사실 때문이었다 카펫 바닥에 묻은 오점 하나를 없애려고 애쓰는 것은 아무런 의미도 없는 일이다. 빨리 개발된 상당수의 PHP 애플리케이션은 못 생겼기 짝이 없었다. Rails가 흥미로운 이유 중의 하나는 빠르고 깨끗하게 (quick-and-clean) 개발할 수 있다는 사실이다.

개발 도구

애플리케이션의 개발과 유지는 단거리 경주가 아니라 마라톤이다. 장기적인 관점에서의 성과는 개발 도구의 품질에 영향을 받는다. 행복한 개발자가 곧 생산적인 개발자이다.

당연한 말이지만 Java는 이 항목에서 독보적인 승자이다. Rails에는 TextMate가 있고 PHP에는 Zend 제품군이 있다. 그리고 PHP와 Ruby를 지원하려는 Eclipse 기반의 작업도 있다. 그러나 이 중 어느 것도 Java 개발자가 NetBeans나 Eclipse 또는 Idea로부터 얻는 포괄적이고, 통합되어 있으며, 잘 다듬어져 있으며 신속히 지원되는 환경과는 거리가 멀었다. 나는 최근에 Eclipse나 Idea를 사용해 본 적이 없다. 하지만 최신의 NetBeans 5.5를 살펴보면 웹 애플리케이션 개발을 위한 자동화 지원의 양이 어마어마한 것을 알 수 있다. 만약 내가 Java 대신 NetBeans를 도표에 넣었다면, 개발 속도 면에서 Java가 PHP와 동일하거나 그보다 나은 수준이지 않았을까 생각한다.

유지보수성

좋은 애플리케이션은 한번 개발되고 나면 놀라울 정도로 오랫 동안 제품 라인에 머물러 있기 마련이다. 다시 말해 오랜 기간 동안 유지보수가 이뤄져야 한다. 즉, 유지보수성이 중요하다. 유지보수성은 많은 것이 포함된 개념이다. 그러나 가장 중요한 요소는 객체지향성, MVC 아키텍처, 코드 가독성, 코드 크기(작으면 작을수록 좋다.)라고 생각한다.

물론 이것은 PHP의 아킬레스건이다. 그렇다, 깔끔하고 객체지향적이고 모듈화된 MVC 구조의 PHP 애플리케이션을 작성할 수는 있다. 그러나 대부분의 사람들은 그렇게 하지 못 한다. 내가 보아 온 대부분의 애플리케이션은 스파게티 HTML에 스파게티 SQL이 들어있고, 또 그것을 스파게티 PHP 코드가 감싸고 있었다. 뿐만 아니라, 객체지향과 MVC 그리고 유지보수성을 제대로 이해하는 많은 사람들은 오히려 Java나 Rails를 사용하고 있다.

나는 Rails의 코드가 Java보다 훨씬 짧기 때문에 Rails가 더 낫다고 본다. 코드의 유지보수 비용은 코드의 크기와 매우 연관성이 있다. 분명히, Java의 훌륭한 개발 도구는 중요하다. 그러나 여전히 이것 또한 Ruby와 Rails가 소프트웨어 산업계의 나머지 영역에 교훈을 주는 대목이라고 생각한다.

빼먹은 것들

Djang를 비롯한 Python 프레임워크와 .Net은 다루지 않았다. 유감스럽게도 나는 이 프레임워크들을 직접 다뤄본 적이 없다. 그리고 .NET은 오픈소스가 아니다. 왜 우리가 .NET을 사용해야 한단 말인가?

짜증나는 것들 (Irritants)

이미 여러 사람이 내게 화를 냈었다. 그들은 내가 PHP가 Java보다 빠르다라고 말했다고 생각하기 때문이다. (나는 그렇게 말한 적 없다.) 내가 Rails가 PHP보다 개발 속도도 빠르고 유지보수하기도 쉽다.라고 말했기 때문에 화를 내는 사람도 있다. (나는 그렇게 말했었고, 입장에는 변함이 없다.)

물론 예외적인 경우가 있다. Rails가 다른 것보다 빠르게 실행된다던가, Java 애플리케이션이 가장 빨리 개발된다던가, 어떤 종류의 애플리케이션에선 압도적으로 우수한 PHP 개발 도구가 있다던가, 아니면 미친듯이 복잡하게 아키텍처가 구성되어서 도저히 유지보수하기 어려운 Java 프레임워크 덩어리가 있을 수 있다.

역자 노트

Irritants: 사전에는 의학 용어로써 자극제 등의 뜻을 가진다고 나와 있다. 그러나 여기서는 짜증나게 하는 것 또는 사람을 칭하는 것으로 해석해야 한다고 생각한다.

중요한 것들

Java, PHP, 그리고 Rails 중 무엇이 최고인가?는 정말 바보 같은 질문이다. 다른 기술 영역의 질문과 마찬가지로, 이에 대한 대답도 경우에 따라 다르다이다. 내 개인적인 의견은 대부분의 웹 애플리케이션의 경우에 확장성은 훌륭한 선택의 근거가 아니라는 점이다. 만약 깔끔한 아키텍처를 구현한다면 확장성도 손에 넣을 수 있다. 깔끔한 아키텍처가 없다면 확장성도 없다.

최근 몇 년 동안 PHP나 Rails 등은 우리가 생각했던 것보다 개발 속도가 중요하다는 사실을 깨우쳐 주었다. Agile/XP는 기능(function)을 좀더 빨리 전달하는 것의 사업적 가치를 가장 높게 평가하는 관점 중 하나이다. 이 관점은 특성(feature) 구현을 마치기 전까진 그 특성을 제대로 이해한 것이 아니며, 따라서 특성을 빨리 구현할수록 이해도 빨라진다고 말한다.

개발 도구의 품질은 위험을 무릅쓰고서라도 무시할 수 있는 것이 아니다. 애플리케이션 개발과 유지보수는 끊임없이 연마되어야 한다. NetBeans나 Eclipse와 같은 도구를 사용해야 장기적인 관점에서 여러분의 직장 생활이 보다 행복해질 것이다.

어쩌면 내가 반백의 25년 차 베테랑이기 때문일지도 모르지만, 나는 현실 세계에서, 그리고 장기적인 관점에서 유지보수성은 아무리 강조해도 모자랄 정도로 중요한 일이라고 생각한다.

Web 2.0이라는 거친 야생의 바깥 세상에서는 어쩌면 빨리 개발하는 것이 제일 중요한 문제일지도 모른다. 일단 시장에서 승리하기만 한다면, 야후!와 같은 기업으로 투자 받은 돈으로 모든 것을 재구축하면 되기 때문이다. 그렇지만 기업 환경에서, 개발 비용의 대부분은 제품이 출시된 후부터 발생한다는 사실을 명석한 개발자와 똑똑한 관리자가 알고 있을지 조금 의심스럽다.

어쨌든 간에 애플리케이션의 종류, 비즈니스, 그리고 인력 제약 (people constraints)에 기반하여 결정을 내려야 한다. 그것은 논쟁의 여지가 없는 사실이다.

추신: 통합

여기까지가 이야기의 절반이다. 나머지 절반은 통합에 관한 것이다. 동일한 기술로 개발된 것이나, 서로 다른 프레임워크를 네트워크 상에서 내부적으로 통합하는 것도 문제이다. 이 부분이 사실은 가장 흥미로운 대목이다.

• Author Details

Author Details

최 재훈

Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.

https://twitter.com/andromedarabbit

plaintext@andromedarabbit.net