리뷰 | 4가지 주요 클라우드 IDE 비교 'PC IDE 부럽지 않다'

2~3차례의 IT 버블이 터지기 오래 전, 세상은 웹 브라우저에서 문서를 편집하는 것이 얼마나 흥미진진한 일인지를 알게 됐다. 초기 제품들은 단순했다. 하지만 오래 지나지 않아 조호(Zoho)와 구글(Google) 같은 회사들이 마이크로소프트 오피스(Microsoft Office)에 필적하는 웹 기반 애플리케이션들을 발표하기 시작했다. 심지어 오늘 날에는 마이크로소프트조차 브라우저 기반의 문서, 스프레드시트, 프레젠테이션 편집 툴을 판매하고 있다. 이제 상상할 수 있는 거의 모든 텍스트 기반 문서를 웹에서 편집할 수 있다.

그러나 한 가지 예외가 있다. 바로 소프트웨어이다. 현업에서 일하는 직원들이 구글 독스같은 온라인 툴을 자유롭게 사용하는 반면 프로그래머들은 클라우드 기반의 간편한 툴조차 쓰지 못하고 있다는 것은 아이러니하다. 통상적으로 프로그래머들은 이런 툴에 있어서 다른 사람들보다 앞서 있는 사람들이기 때문이다. 프로그래머들은 정작 자신의 개발 업무에는 더 어려운 방식으로 일을 하고 있는 것이다.

지난 주 필자는 애플에서 X코드 툴을 오랜 시간을 들여 다운로드해야 했다. 수백 줄의 코드를 연동시키기 위해서 기가바이트의 라이브러리를 개인 장비에 호스팅 해야 하는 것이다. 특히 애플은 2~3주에 한번씩 업데이트를 배포하는데 그 때마다 이들 전체를 다시 다운로드해야 한다.

그러나 이런 아이러니한 공백 상태가 (예상보다 느리기는 하지만) 점점 바뀌고 있다. 많은 개발자들이 클라우드 기반 저장 서비스, 그리고 함께 제공되는 클라우드 기반의 빌드(Build) 관리 툴을 사용할 수 있게 됐다. 대기업 IT 부서들은 이미 허드슨(Hudson)/젠킨스(Jenkins)를 이용해 코드와 메인 트리(Main tree)를 관리하고 있다. 심지어 이들 툴을 서비스로 제공하는 있는 기업들도 일부 있다.

문제는 가장 기본적인 코드 개발 업무조차 가장 기본적인 사업 개발 업무, 마케팅 업무와는 상당한 거리가 있다는 것이다. 프로그래머들은 서서히 이를 따라잡고 있으며 브라우저 기반의 IDE가 하나둘씩 나타나고 있다. 필자는 시장 발전 상황을 알아보기 위해 며칠 동안 많은 클라우드 IDE를 조사했다. 일부 서비스에서 코드를 작성하고 빌드(Build) 버튼을 누르고 결과물을 지켜봤다. 초기의 전신전보 서비스를 테스트하는 것과 같은 느낌이었다.

좋은 소식은 브라우저 기반의 IDE가 훌륭해 보인다는 것이다. 일부 서비스의 경우 한쪽에는 파일 트리, 다른 한쪽에는 편집 창을 배치한 전통적인 IDE 레이아웃을 채택해 마치 이클립스(Eclipse)를 브라우저에 옮겨 놓은 것 같았다.

반면 기존 툴과는 다른 구조를 채택한 IDE도 있었다. 코드를 임의로 수정할 수 있는 웹 기반 마이크로 에디터(Micro-editor)가 대표적으로 상당수가 코드미러(CodeMirror) 같은 오픈소스 프로젝트를 이용했다. 가장 큰 혁신은 브라우저에서 실행되는 언어와 함께 시작되고 있다. 더 이상 비효율적인 방법으로 자바스크립트(JavaScript) 페이지를 개발할 필요가 없다. 브라우저에서 모든 테스트가 가능하기 때문이다. 브라우저가 '코드의 본가'가 되는 것이다.

단 지나치게 긍정적이어서는 곤란하다. 현재 주요 플랫폼 가운데 하는 AJAX이다. 심지어 IDE처럼 보이지 않는 IDE도 있다. 예를 들어, 워드프레스(WordPress)의 에디터 모듈을 이용해 웹 사이트의 PHP와 HTML을 개발할 수도 있다. 실제로 워드프레스는 아주 유용한 툴이다. 간편한 편집기를 쉽게 찾을 수 있기 때문에 매일 HTML 태그를 손보게 될지도 모른다.

<한눈에 보는 클라우드 IDE>


클라우드의 '힘'과 긴 대기시간
'빌드' 버튼을 클릭함과 동시에 브라우저 기반 IDE의 단점 가운데 하나가 드러난다는 것이 '좋지 않은 소식'이다. 브라우저 기반 IDE에는 장점이 많지만 대기시간이 긴 것이 단점이다. 물론 사용하고 있는 인터넷의 속도와 코드 종류에 따라 다를 것이다. 필자의 경우 시간대, 날씨에 따라 차이가 컸다.

일부 클라우드 IDE는 용납할만한 수준의 성능을 보이기도 하낟. 그러나 충분한 컴퓨팅 파워와 램을 지원하는 로컬 장치 IDE에서 작업을 할 때와는 비교할 수 없다. 대부분은 네트워크 지연이 문제다. 클라우드의 경우 CPU를 공유하고 있는 것도 이유다. 분명한 것은 8코어 컴퓨터에서 작업을 할 때보다는 느리다. 항상 그런 것은 아니다. 대부분의 코드 구축 작업은 그다지 복잡하지 않다. 따라서 네트워크 지연 문제를 눈치채기도 쉽지 않다.

대형 프로젝트의 경우 클라우드가 도움이 될 수 있다. 예를 들어 클라우드비스(CloudBees)는 코드 개발을 위한 많은 장치들이 지원한다. 예를 들어 빌드가 동시에 실행될 수 있는 N개의 독립적인 작업으로 구성되어 있다고 가정하자. 여기서 N의 값이 크다면 쿨라우드의 N개 장치에서 N개의 작업이 실행될 확률이 있다. 일반적인 책상 위에 놓여 있는 8코어 장비에서는 불가능한 일이다.

따라서 클라우드 IDE의 장점은 코드 종류와 빌드의 크기에 따라 좌우된다. 브라우저에서 실행되는 웹 애플리케이션 개발자들에게 가장 적합할 것이다. 클라우드의 파일 저장 기능도 중요한 장점 중 하나다. 이런 작업에서는 대기시간이 큰 문제가 되지 않는다.

지리적으로 분산된 개발자들로 구성된 팀이 동일한 파일을 작업하는 경우에도 클라우드 IDE는 매우 유용하다.

스태시(Stash) 등 기트(Git) 호스팅 서비스와 지라(Jira) 같은 이슈 관리 소프트웨어로 잘 알려진 개발 툴 회사인 아틀라시안(Atlassian)은 파이어베이스(Firebase)를 이용해 페어 프로그래밍(Pair Programming, 두 명의 프로그래머가 하나의 워크스테이션에서 협업을 하는 애자일 소프트웨어 개발 기법)을 한다. 이는 서로 떨어진 개발자들의 협업 역량을 확실하게 향상시키는 방법이다. 여기서 IDE는 지리적으로 분산된 페어 프로그래밍 작업을 지원한다. 어떤 의미에서는 페어가 아닌 '트리플'(Triple), '쿼드플'(Quardruple) 프로그래밍이라고 지칭해야 할지 모른다.

반면 루비(Ruby)나 자바(Java) 같은 코드 중점 개발팀이 클라우드 기반 IDE를 도입하기까지는 더 시간이 걸릴 전망이다. 가장 큰 이유는 네트워크 대기시간이다. 필자는 개발-디버깅-수정 작업을 하면서 이클립스의 강력한 기능이 그리웠다. 또 인터넷이 제대로 연결되지 않는 경우도 있었다.

아이패드 같은 장치용 앱을 개발하는 엑스코드(Xcode) 같은 툴은 가장 마지막에 클라우드 기반 IDE를 도입할 것이다. 단 자바스크립트(JavaScript)와 HTML 기반의 모바일 앱을 개발하는 프로그래머들은 예외다. 이들에게 브라우저는 너무나 자연스러운 환경으로, 작업하기에도 더없이 좋은 환경이다.

지금까지 지적한 단점들은 시간이 지나면서 대부분 해소될 것이다. 브라우저 코드가 '스마트'해지고 있고, 로컬 파일, 로컬 데이터, 대용량 라이브러리가 이미 HTML 5 호환 브라우저로 옮겨가고 있기 때문이다. 이들 툴을 만드는 사람들은 향후 자신의 고객들에게 더 많은 기능과 역량을 제공하게 될 것이다. 즉 긴 대기시간 문제가 해결되는 것은 시간문제라는 것이다. 그 속도도 점점 빨라지고 있어 앞으로 2~3년이면 데스크톱 기반 IDE의 상당수가 사라질 것으로 전망된다.