불타오르는 프로그래밍 트렌드 15가지, 그리고 식어가는 트렌드 15가지

프로그래머들은 시시각각 유행이 바뀌는 패션업계를 비웃기 좋아한다. 치마 길이도 올라갔다 내려갔다 바뀌고 색상 유행도 항상 바뀌고, 넥타이도 두꺼워졌다 얇아졌다 항상 바뀌곤 한다. 하지만 기술업계에서는 기술, 엄밀성, 과학, 수학, 정밀성이 유행보다 더욱 중요하다.

그렇다고 해도 프로그래밍에 유행이란게 존재하지 않는 것은 아니다. 차이점이라면 프로그래밍 트렌드는 효율성, 증가된 커스터마이징, 사용 편의성에 의해 주도된다는 정도다. 이런 요소들을 한가지 이상 제공하는 신기술은 이전 세대를 완전히 갈아치운다. 그래서 그냥 엉뚱히 나오는게 아니라 그럴만한 이유가 있는 유행이다.

다음은 요즘 프로그래머들 사이에 지금 떠오르는 유행과 식어가는 유행 목록이다. 여기 소개된 목록에 대해서 모두가 동의하지 않을 수 있다. 하지만 그 점이 바로 빠르게 변하고, 열정적인 토론이 일어나고, 갑자기 재기하기도 하는 프로그래밍이라는 일의 매력이 아닐까?

뜬다: 전처리기
진다: 풀 랭귀지 스택(Full language stacks)

얼마 전까지 만해도 새로운 프로그래밍 언어를 개발하려면 칩에 맞춰 코드를 비트로 바꾸는 모든 것들을 새로 만들어야 했다. 그러던 중에 어떤 이가 이전 작업들 위에 그대로 편승할 수 있다는 점을 알아냈다. 그 결과 이제 똑똑한 아이디어를 가진 사람들은 풍부한 라이브러리와 API를 갖추고 새로운 코드를 예전 형태로 번역하는 전처리기(preprocessor)만 만들면 된다.

그런 식으로 다이나믹 타이핑(dynamic typing)을 좋아하는 이들은 과도하게 엄격한 구두법이 없는 단순한 자바 버전인 그루비(Groovy)를 만들었다. 자바스크립트(JavaScript)를 고치고 싶어했던 이들은 역시 부담스러운 구문법 없이 코딩할 수 있게 해주는 전처리기인 커피스크립트(CoffeeScript)를 만들었다. JVM상에서 실행되는 클로주어(Clojure)나 스칼라(Scala)같은 십여 개의 언어들이 있지만, JVM은 하나뿐이다. 바퀴는 다시 발명할 필요가 없지 않나?

뜬다: 자바스크립트 MV*프레임워크
진다: 자바스크립트 파일

오래 전, 모든 이들은 알림 상자를 띄우거나 이메일 주소에 @ 표시를 포함시키기 위해 자바스크립트를 배웠다. 이제는 HTML AJAX 앱이 아주 정교해져서 맨땅에서 시작하는 사람은 거의 없다. 정교한 프레임워크를 선택해 비즈니스 로직을 실행하는 글루 코드를 조금 작성하는 것이 더 간편하다. 켄도(Kendo), 센차(Sencha), 제이쿼리 모바일(jQuery Mobile), 앵귤러JS(AngularJS), 엠버(Ember), 백본(Backbone), 미티어 JS(Meteor JS)같은 십여 가지 프레임워크가 있는데, 이 모두가 웹 앱과 페이지의 이벤트, 컨텐츠를 잘 처리해 준다.

뜬다: CSS 프레임워크
진다: 제네릭 폭포수 스타일 시트(Generic Cascading Style Sheets)

과거에는 웹 페이지를 화려하게 꾸민다는 것이 CSS 파일을 열어 '폰트 스타일:이탤릭' 같은 명령어를 사용하는 정도였다. 그렇게 힘든 아침 업무를 마치고 파일을 저장한 후 점심을 먹으러 가면 됐다. 그러나 이제 웹 페이지들은 너무나도 세련돼, 그런 단순 명령으로 꾸미는 것이 불가능해졌다. 색깔 하나만 바꿔도 모든 것이 다 엉클어진다. 마치 공동 운명체나 생태계처럼 모든게 연결돼 있다.

그런 부분에서 SASS와 그 사촌격인 컴파스(Compass)같은 CSS 프레임워크의 입지가 탄탄하다. 이들은 실변수, 네스팅 블록, 믹스-인같은 프로그래밍 구조를 제공해 문법에 맞으면서도 안정적인 코딩을 도와준다. 프로그래밍 측면에서는 새롭게 들리지 않을 수도 있지만, 디자인 측면에서는 매우 큰 진보다.

뜬다: 캔버스상의 SVG + 자바스크립트
진다: 플래시

오랫동안 플래시는 사람들을 미치게 만들어왔지만, 아티스트들은 언제나 그 결과물에 만족해했다. 외곽선이 매끄럽게 처리된 렌더링은 매우 훌륭하기 때문에 많은 재능 있는 아티스트들은 세련된 결과물을 얻기 위해 플래시 기술을 폭넓게 사용해왔다.

그러나 이제 자바스크립트 레이어도 그 정도를 지원하게 되면서, 브라우저 제조사와 개발자들은 플래시의 종말을 기대할 수 있게 됐다. 이들은 SVG(Scalable Vector Graphics)같은 새로운 포맷은 DOM 레이어와 더 깊게 통합된다. SVG와 HTML은 하나의 큰 태그 파일을 구성하는데, 이는 웹 개발자들이 쓰기에 더 간편한 경우가 많다. 또한, 캔버스(Canvas) 객체에 세밀한 그림 그리기가 가능한 API들이 많고 비디오 카드의 지원도 받을 수 있다. 이들을 사용하면 더는 플래시를 쓸 이유가 없다.

뜬다: 거의 빅 데이터(하둡 없는 분석)
진다: 빅 데이터(하둡과 함께)

누구나 대학에서 중요한 인물이 되고 싶어한다. 그러나 상황이 여의치 않다면 자신이 충분히 돋보일 수 있는 적당한 수준의 대학을 찾게 된다. 마찬가지다. '빅 데이터'라는 단어가 중역 회의실에서 처음 흘러나오기 시작했을 때 이들이 마치 요트를 사거나 초고층 빌딩을 짓는 것처럼 가장 강력한 빅데이터 시스템을 찾는 일이 놀라운 것은 아니다.

재미있는 점은, 많은 문제가 빅 데이터 솔루션이 필요할 만큼 그리 큰 일이 아니라는 사실이다. 물론 구글이나 야후같은 기업들은 우리의 모든 웹 브라우징을 추적하고, 페타바이트나 요타바이트급 데이터 파일들을 보유하고 있다. 하지만 대부분의 회사들은 기본 PC의 RAM 정도면 충분할 만한 작은 데이터세트를 가지고 있다. 필자는 16GB RAM이 장착된 PC에서 지금 기사를 쓰고 있는데 이는 상당량의 바이트와 수십억 개의 이벤트를 담기에 충분하다. 대부분의 알고리즘에서 데이터를 SSD에서 스트리밍하기 때문에 메모리에 읽힐 필요가 없다.

병렬로 실행되는 하둡 클라우드 내의 십여 대의 기계의 빠른 응답시간을 필요로 하는 인스턴스들이 있겠지만, 대부분은 협업이나 커뮤니케이션을 신경 쓰지 않고 단일 기기상에서의 플러깅만으로도 충분할 것이다.

뜬다: 게임 프레임워크
진다: 네이티브 게임 개발

한때 게임 개발은 C에 있어서 모든 것을 백지에서부터 시작할 수 있는 개발자들을 충분히 채용하는 것을 의미했다. 물론 엄청난 돈이 들지만 보기에는 좋아 보이니까. 그러나 이제 어느 누구도 커스텀 코드를 감당할 만큼 사치를 부릴 수가 없게 되었다. 대부분의 게임 개발자는 오래 전에 자존심을 버리고 유니티(Unity), 코로나(Corona), 립GDX(LibGDX)같은 라이브러리를 활용해 개발하기 시작했다. 이들은 라이브러리의 인스트럭션만큼 C 코드를 작성하지 않는다. 우리의 즐기는 게임들이 자존심을 걸고 제작되지 않고 똑같은 엔진을 달고 찍혀나왔다는데 실망해야 할까? 오히려 대부분의 개발자는 그 세부내역과 씨름하지 않아도 돼서 한숨 돌리고, 게임 플레이, 나레이션, 캐릭터, 아트 부분에 집중할 수 있게 됐다.

뜬다: 단일-페이지 웹 앱
진다: 웹사이트

웹 페이지가 고정 텍스트와 이미지로 가득 찼던 시절을 기억하는가? 모든 정보를 웹 사이트라고 불리는 별개의 웹 페이지의 네트워크 안에 모두 담는 게 얼마나 간편하면서도 진기한 일인가. 새로운 웹 앱들은 컨텐츠로 채워진 대규모 데이터베이스의 얼굴이다.

웹 앱이 정보를 원할 때는, 그 정보를 데이터베이스에서 끌어와 로컬 몰드에 쏟아 붓는다. 웹 페이지를 구축하는데 필요한 모든 웹 기타요소들로 데이터를 교정 볼 필요도 없다. 데이터 레이어는 프레젠테이션과 포매팅 레이어와 완전히 별개다. 여기에다 모바일 컴퓨팅의 부상 역시 또 하나의 요소다: 앱처럼 작동하는 단일의 호응적으로 설계된 웹페이지는 앱스토어의 모든 혼잡으로부터 벗어나기 안성맞춤이다.

뜬다: 모바일 웹 앱
진다: 네이티브 모바일 앱

어떤 모바일 컨텐츠에 대해 훌륭한 아이디어가 있다고 가정해보자. 그 아이디어를 기반으로 iOS, 안드로이드, 윈도우 8, 어쩌면 블랙베리 OS까지 별개 버전으로 개발할 수 있을 것이다. 그 각 OS마다 다른 언어로 작업하는 별개의 팀이 필요하다. 그리고 각각 플랫폼의 앱스토어마다 앱이 사용자들에게 모습을 드러낼 수 있게 되기까지 엄청난 노력이 들어간다.

아니면 그냥 하나의 HTML 앱을 만들고 이를 모든 플랫폼에서 실행되도록 웹사이트에 올려도 된다. 만약 변경사항이 있더라도 앱스토어로 가서 빠른 검토와 버그 수정을 요청할 필요도 없다. 이제 HTML 레이어가 더 빨라지고 있으며 더 빠른 칩에서 실행됨에 따라, 이런 접근방식은 더 복잡하고 상호 소통적인 앱에서도 네이티브앱과 경쟁할 수 있게 되었다.