※ 해당 포스트는 http://www.itworld.co.kr/news/89977?page=0,1 를 참조했습니다.
문제가 있을 시 삭제하겠습니다.
개발자의 마음을 차지하기 위한 전쟁 10가지
인간의 본능인지, 사회 형성의 불가피한 산물인지 몰라도 우리 삶의 많은 부분이 이원론을 통해 규정된다. 공산주의 대 자본주의. 세이보리 대 설탕. 패스 대 드리블. 어디를 보든 대립은 끝이 없다. 그래서 둘 중에 어느 편에 서는가로 우리 스스로를 정의할 수 있는 경우도 무수히 많다.
컴퓨터 업계에서는 이러한 현상이 더욱 두드러진다. 각종 기술들이 (사람들의 마음과 돈을 차지하기 위해 경쟁하면서) 경쟁 솔루션과 다른 고유한 장점을 통해 스스로를 정의한다. 한 편에 X가 있고, 그 반대편에는 X가 아닌 것이 있다. 그 뒤로 팬보이들이 줄을 서서 상대편을 조롱하고 깎아 내린다. 이러한 대립이 없다면, 치열한 논쟁과 선택권이 없다면 아마 오래 전에 코드 저장소는 하나로 통합되고 사람들은 사이 좋게 잘 지내게 되었을 듯하다. 다만 혁신도 그만큼 줄었을 것이다.
다음은 현재 개발자들 사이에서 볼 수 있는 가장 흥미로운 10가지 대립이다. 새로운 프로젝트를 수행할 때마다 우리는 이러한 기술이 갖는 차이점의 기저가 되는 근본적인 질문들에 직면한다. 간단함과 정확성 중 무엇을 선호하는가? 오픈소스냐, 기업 지원이냐? 대괄호냐, 공백이냐? 이러한 질문들은 마치 음과 양처럼 기업 개발자들 사이의 균형을 이룬다.
개발자 기술 대결 1: PHP 대 Node.js
컴퓨터 과학자들은 좋아하지 않는 PHP는 웹 사이트에 소소한 지능을 추가하고자 했던 사람들 사이에서 처음 도입됐다. 이들 덕분에 워드프레스(WordPress), 드루팔(Drupal), 줌라(Joomla)와 같은 빼어난 프레임워크들이 나왔다. 웹은 대부분 PHP를 기반으로 한다.
그런데 이 모델에 균열이 생겼다. 젊은 개발자들은 자바스크립트로 프로그래밍된 서버 측 메커니즘인 Node.js에 심취해 있다. 어느 순간부터 프로그래머들은 클라이언트 또는 서버에서 실행되는 코드를 작성할 수 있게 됐다. 두 개의 언어를 따로 배울 필요가 없어졌다. Node.js에도 나름의 단점은 있지만, 강력한 PHP 스택과 대등할 정도의 기능을 제공하는 뛰어난 프레임워크들이 이미 나와 있다.
다음 세대는 자바스크립트만 쓰면 되는 간편함을 수용할까? 아니면 HTML 내에 손쉽게 코드를 내장하는 편을 택할까? 자바스크립트를 좋아한다면 거의 확실히 Node로 가게 될테고, 워드프레스 또는 드루팔과 같이 PHP의 안정적인 스택을 사용하고자 하는 사람은 Node.js 바람을 계속 피할 것이다.
개발자 기술 대결 2: MySQL 대 PostgreSQL
두 개의 뛰어난 오픈소스 데이터베이스가 거의 20년째 대결 중이고 끝날 기미도 없다. MySQL은 설치 및 구성의 용이함에 힘입어 기본적인 웹 워크로드의 대부분을 차지했다. PostgreSQL은 자잘한 문제에도 불구하고 데이터 보호를 위한 우수한 트랜잭션 메커니즘을 오랜 기간 제공해왔다. 이 둘은 서로의 영역으로 확장하면서 현재 MySQL은 트랜잭션 기능을 개선했고 PostgreSQL은 시작 절차를 간소화했다.
오래 전에 존재했던 차이점이 지금도 여전히 둘 사이를 가른다. PostgreSQL은 더 "안정적"인 데이터베이스로, MySQL은 더 "빠른" 데이터베이스로 인식되지만 이러한 구분은 실제보다는 허상에 가깝다. 오랜 습관을 고치기는 어렵다는 점을 감안하면 이 두 패키지의 대결은 아마 앞으로도 20년 동안 더 지속될 것이다. 다만 최신 기술을 쫓는 해커와 오라클을 싫어하는 사람들 덕분에 최근 PostgreSQL이 힘을 받고 있다.
개발자 기술 대결 3: 스위프트 대 오브젝티브-C
C와 객체 지향 프로그래밍의 깔끔한 조합인 오브젝트-C 뒤에는 항상 애플이 있었다. 그러나 시대가 바뀌었고 이제는 스위프트가 지금까지 애플 플랫폼을 위한 코딩을 어렵게 만들었던 불편함을 상당수 해결한 현대적인 구문을 제공한다. 물론 일찍부터 C를 배운 사람들은 아스테릭스와 여러 파일에 개의치 않지만 파이썬과 루비, 자바를 배우며 자란 새로운 세대에겐 골치 아픈 부분이다.
스위프트의 깔끔한 구문이 애플 개발자들의 마음을 살까? 파이썬과 루비 개발자가 iOS로 몰려들어 전통의 오브젝티브-C 해커들을 수에서 압도하게 될까? 아니면 이미 오랜 검증을 거친 오브젝티브-C 프로그래머들의 놀라운 효율성이 세계를 지배하게 될까? 새로운 라이브러리와 기능이 스위프트나 오브젝티브-C에 적용될까? 애플은 공개적으로 두 가지가 공존할 수 있다고 말했다. 따라서 개발자들은 자신이 익숙한 쪽을 고수할 가능성이 높다. 파이썬이나 자바를 선호하는 사람들은 스위프트로 이동하고, C와 함께 자란 사람들은 오브젝티브-C에 머물 것이다.
개발자 기술 대결 4: 파이썬 대 루비
오래 전, 스크립팅 언어는 소프트웨어의 껌과 같았다. 큰 프로그램들을 서로 연결해야 할 경우 OS에서 간단한 코드를 작성해서 원하는 결과를 얻을 수 있었다.
시간이 지나면서 이러한 간단한 언어에 매료된 사람들이 유용한 큰 프로그램들도 만들기 시작했다. 루비는 레일스(Rails) 프레임워크와 결합하면서 폭발적으로 성장했다. 이 조합은 단 몇 줄의 코드만으로 정교한 프론트 엔드를 데이터베이스에 연결할 수 있도록 했다.
한편 파이썬은 과학 분야에서 자리를 잡아 현재 많은 연구실에서 빈번하게 사용된다. 모든 기업 환경에서 통계 분석이 사용되면서 비즈니스 분야의 데이터 과학 "연구실"에서도 파이썬이 기세를 높이고 있다.
다음 세대는 공백으로 코드를 프레임하는 파이썬의 간소함에 끌릴까? 루비는 레일스 너머로 확장될까? 파이썬의 내장 함수가 루비의 "블록"보다 더 나은 선택일까? 과학자들 편에 서는 것과 웹 해커 편에 서는 것 중 어느 쪽이 더 멋지게 보일까? 웹 고수들은 레일스를, 과학자들은 파이썬의 라이브러리를 고수하는 이 전선은 아마 앞으로도 영원히 지속될 것이다.
개발자 기술 대결 5: SQL 대 NoSQL
한쪽에는 우리들의 할아버지 세대가 사용했던 데이터베이스가 있다. 데이터는 매끄럽게 테이블에 저장되며 데이터베이스는 쿼리를 실행하여 테이블을 대조하고 정확한 행을 찾아낸다. 반대쪽에는 속도와 병렬성에 대한 원대한 약속을 앞세우지만 가끔 엉뚱하거나 비일관적인 대답을 내놓는 문제점을 가진 신흥 주자인 NoSQL이 있다.
전통적인 트랜잭션 보호를 가진 데이터베이스의 안정적인 접근 방법이 좋을까, 아니면 클러스터로 효과적으로 부하를 분산하는 더 빠르고 저렴하면서 더 현대적인 도구가 좋을까? 물론 은행에게는 일관성과 정확성이 중요하겠지만 인터넷의 온갖 잡다한 정보들로 꽉 찬 테이블이라면? 데이터 과학자가 제공할 수 있는 최선의 보호가 과연 모든 곳에 필요할까? 대부분의 경우 답은 은행, 항공사과 같이 절대적인 일관성이 필요하다면 실제 트랜잭션이 있는 전통적인 SQL이 맞고, 그 외의 모든 사람에게는 더 빠르고 더 간단하고 확장성 높은 NoSQL이 더 좋다는 것이다.
개발자 기술 대결 6: 자바스크립트 대 다트/고(또는 구글 자체)
구글 사무실 내에서도 아마 자바스크립트 팬들이 있겠지만 어쨌든 구글은 자바스크립트를 대신할 것들을 끊임없이 내놓고 있다. 가장 먼저, 자바를 자바스크립트로 바꿔주는 똑똑한 크로스 컴파일러인 GWT(구글 웹 툴킷)가 있었다. 지메일을 비롯한 구글 제품의 코드 스택을 살펴보면 자바스크립트를 사용해 수작업으로 만들어진 것이 아님을 알 수 있다. 이후 구글은 언젠가 브라우저의 자바스크립트를 대체할 수 있는 두 언어인 다트와 고를 만들었다.
다트와 고 모두 적절한 쓰임새가 있다. 두 언어는 자바스크립트와 브라우저 스택의 눈에 띄는 큰 문제점들을 수정해주지만 대부분의 사람들은 별 관심을 갖지 않는다. Node.js 덕분에 서버 영역에서 자바스크립트가 폭발적으로 성장 중이다. 자바스크립트 외의 무언가가 필요할 일이 없다.
구글이 아무리 강한 힘을 가졌다 해도, 오래 전부터 자바스크립트를 배웠고 이제 서버 스택을 자바스크립트로 다시 작성하고자 하는 프로그래머 군단을 상대하기는 버겁다. 관성에 맞서 싸우기란 어려운 법이다. 그러나 다트와 고의 깔끔한 구문과 간소화된 모델에 대한 얼리 어댑터들의 극찬은 무시하기 어려운 요소가 될 수 있다.
개발자 기술 대결 7: 셰프(Chef) 대 퍼펫(Puppet)
과거의 회사는 서버실에 몇 대의 서버를 운영했고 새 소프트웨어를 설치하는 일은 간단했다. 이후 클라우드가 폭발적으로 성장했고 모든 웹 사이트가 지속적 운영이 필요한 시스템 클러스터에서 실행되기 시작했다. 이는 실수 없이 N개의 서버에 N번 작업해야 함을 의미했다. 셰프와 퍼펫은 관리자가 클라우드 머신을 구성하기 위한 어셈블리 라인을 실행하는 데 도움이 되는 도구들이다.
셰프에 심취한 데브옵스 전문가들은 루비로 머신 생성 명령을 작성할 수 있게 해주는 유연성을 높게 평가한다. 이들은 "루비의 힘을 공짜로 얻는 것"이라고 말한다. 퍼펫도 클러스터를 구성하는 기능을 하지만 JSON과 비슷한 언어로 작성되는 명령은 한 가지 일을 잘 해내는 데 집중한다. 퍼펫의 최근 버전에서는 루비도 소폭 허용되지만 기본 언어가 여전히 주도적인 지위를 갖고 있다. 작업을 위해 맞춤형 구문을 만드는 것과, 널리 공개된 범용 언어의 힘(그리고 위험)을 부여하는 것 중 무엇이 더 나을까?
개발자 기술 대결 8: 허드슨(Hudson) 대 젠킨스(Jenkins)
연속적 통합이라는 개념은 리포지토리에 제출되는 모든 코드를 자동으로 테스트하고 배포하기 위한 방편이었다. 이 개념이 제대로 작동하기 시작하자 사람들은 그 유산을 두고 다투기 시작했다.
다툼의 한쪽에는 허드슨이 있다. 공식적으로 이클립스 재단에 속하며, 썬에서 이 코드를 상속받은 오라클의 많은 직원들이 운영한다. 안정적인 기업용 도구 구축을 위한 최고 수준의 품질을 제공한다. 반대쪽에는 실험을 좋아하는 원조 해커들의 고향인 젠킨스가 있다. 거의 매주 새로운 버전이 나오는 등 훨씬 더 빠르게 진화하는 듯 보인다.
허드슨과 젠킨스의 대결은 신중한 테스트와 안정적인 코드에 대한 꾸준한 노력이냐, 아니면 빠르게 진화하는 기능과 빠른 버그 수정, 개발자 커뮤니티의 전체의 의견 반영이냐는, 개발자들 사이에서 진행 중인 더 큰 논쟁을 잘 보여주는 한 사례다.
개발자 기술 대결 9: MySQL 때 MariaDB
오라클이 지원하는 프로젝트를 둘러싼 전선을 이야기할 때 MySQL에 대한 MariaDB의 독립을 빼놓을 수 없다.
오라클이 MySQL을 인수했을 당시 오픈소스 지지자들은 강력한 독점 소프트웨어를 기반으로 하는 회사가 무슨 일을 벌일지 걱정했다. 이들의 걱정은 대부분 사실무근으로 드러났다. 그러나 MySQL의 창시자 중 한 명인 몬티 와이드니어스는 거기서 그치지 않고 직접 자기만의 것을 만들었다. MariaDB는 MySQL과 거의 비슷한 구문과 기능을 제공하지만 속도가 조금 더 빠른(적어도 MariaDB를 좋아하는 사람들 눈에는 그렇게 보임) 몇 가지 새로운 기능과 스토리지 엔진을 사용한다.
시장은 산만한 새로운 분기를 선택할까, 아니면 오랜 시간 충실히 자신의 역할을 수행해온 지배적인 코드 베이스를 고수할까? 세계는 뒤죽박죽인 소규모 혁신가 그룹을 선택할까, 안정성에 집중하는 견고한 기업을 선택할까?
개발자 기술 대결 10: 컴파일 대 스크립트
지금 컴파일된 코드와 스크립트 코드의 구분은 JIT(Just-In-Time) 컴파일러와 최적화기가 등장하기 전만큼 뚜렷하지는 않다. 코드를 이리저리 주무르고 최적화하고 단순한 기계 코드로 변환하는 방식과, 컴퓨터가 런타임에 코드를 해석하고 가끔은 코드가 스스로를 수정하도록 허용하기도 하는, 더 편안한 접근 방식 중 어느 쪽이 승리하게 될까?
한쪽에서는 C, 자바와 같은 고전적인 언어들을 정교한 개발 도구들의 지원을 받아 사용한다. 다른 한쪽에는 파이썬, 루비, 자바스크립트와 같은 비교적 단순한 스크립팅 언어를 텍스트 편집기에서 만들어 가벼운 런타임 인터프리터로 바로 푸시한다. 게다가 자바 가상 머신에서 실행되며 다양한 런타임 최적화를 스스로 수행하는 스크립트 스타일의 그루비(Groovy)와 같이 두 가지를 혼합한 솔루션으로 인해 전선은 더욱 복잡해진다. 어쩌면 두 가지의 구분은 서서히 사라지는 중인지도 모른다. 그러나 컴파일러의 꼼꼼한 기능이 그에 필요한 모든 노력을 감수할 만큼의 가치가 있는지 여부에 대한 사람들의 논쟁은 앞으로도 계속될 것이다. editor@itworld.co.kr