개발 방식을 바꾸는 15가지 기술

개발자 도구 1 : 지속적인 통합(Continuous Integration) 과거에는 리포지토리(Repository)에 코드를 커밋하고 나면 보통 커피를 마시며 한숨 돌리거나 점심을 먹을 여유가 있었다. 하지만 더 이상은 아니다. 오늘날의 리포지토리는 지속적인 빌드 시스템과 밀접하게 연결되어 있기 때문이다. 지속적인 빌드 시스템은 코드를 다시 컴파일하고, 아키텍처를 검사하고, 코드에 수백 가지 테스트를 수행해 오류의 가능성을 표시해 준다. 이 때문에 개발자는 지속적인 빌드 시스템이 보내는 작업 수정 요청 메일과 문자 메시지 때문에 책상에서 1m도 벗어나기 어려울 것이다. 지속적인 빌드 시스템은 개발자에게 늘 새로운 일거리를 던져 줄 것이다.

개발자 도구 2: 프레임워크(Framework) 근래에는 다른 사람의 작업물을 활용하지 않고 온전히 자신의 힘으로만 프로그램 전체를 개발하는 경우는 드물다. 대신 적당한 프레임워크(Framework)를 선택한 다음 API를 조사하고, 원하는 기능에 부합하지만, 서로 호환되지 않는 일부 API를 연결하기 위한 글루(glue) 코드를 개발하는 방식을 선호한다. 이제 누구도 HTML이나 CSS로 웹 페이지를 개발하지 않는다. Ext JS나 ExpressJS 혹은 다른 기반이 되는 프레임워크를 이용한다. 물론, 모든 것을 처음부터 만드는 개척자가 될 수도 있지만, 이는 자살 행위나 다름없다. 다른 사람들이 이미 완성해 놓은 것을 모두 다 처음부터 만들 수는 없는 노릇이다. 개발자는 ‘장인’이 아닌, ‘프레임워크를 조작하는 사람’임을 명심해야 한다. 만약 직접 코드를 개발할 생각을 하고 있다면 당장 멈추고 이미 개발된 프레임워크를 찾아보길 바란다.

개발자 도구 3 : 라이브러리(Library) 루틴(Routine)의 집합소인 라이브러리는 프레임워크의 사촌 격으로, 거의 모든 곳에서 사용되고 있어 이제 라이브러리 없이는 개발이 어려울 정도다. 과연 jQuery 없이 브라우저를 위한 코드 개발이 가능할까? GetElementByID라는 함수가 있다는 것을 기억하는 사람이 있기나 할까? 물론, ‘No’다. 오늘날에는 jQuery 같은 라이브러리가 소프트웨어 스택 전체를 지배하고 있다. 사람들은 자신이 좋아하는 언어에 대해서는 잘 이야기하면서도 어떻게 개발하는지는 좀처럼 이야기하지 않는다. 따라서 개발자를 고용할 때는 라이브러리 지식에 관해 물어볼 필요가 있다. 자바스크립트 개발자라면 jQuery, 아니면 Dojo 쪽인지, 게임 개발자라면 C++에 대해서 보다는 Allegro나 Unity, Corona 등에 대해 알고 있는지를 물어야 한다. 라이브러리에 대한 지식은 언어를 잘 아는 것만큼 중요하다.

개발자 도구 4: API 과거 개발자들은 주로 데이터 구조에 대해 고민했다. 모든 정보를 바이트 블록으로 묶고, 바이트를 하나하나 센 다음 어떤 값이 특정 포인터를 기준으로 정확한 거리에 위치하는지를 확인해야 했다. 다행히 지금은 컴파일러가 이와 같은 작업 대부분을 대신해 준다. 오늘날에는 이보다 훨씬 더 정확한 인터페이스인 API로 작업할 수 있다. API는 보통 완전히 다른 기기에서 서비스되며, 다른 회사에서 제공하는 서비스를 매 호출 시마다 요금을 지불하고 이용할 수도 있다. 주소와 우편 번호를 위도와 경도로 바꾸고 싶을 경우, 비용을 지불한 뒤 원하는 결과를 얻을 수 있는 API를 사용하면 된다. 일반적으로 데이터는 그리 치밀한 구조화가 필요 없다. 바이트의 수를 세는 예전 방식은 JSON이나 XML처럼 파싱이 가능한 데이터 구조로 대체된 지 오래다. 그저 구분 점을 올바른 위치에 찍었는지만 확실히 하면 되며, 이를 처리해 주는 라이브러리도 있다.

개발자 도구 5 : 서비스로 제공되는 플랫폼 과연 지금도 웹 사이트를 직접 구축하는 사람이 있을까? 아마도 다른 웹 사이트에 계정을 만든 다음 커스터마이징하는 방법을 택할 것이다. 웹 서식에 몇 개의 필드를 채우기만 하면 나머지는 웹 사이트가 다 알아서 해주기 때문이다. 이는 유튜브에 고양이 비디오를 올리거나 이베이에서 페즈(Pez) 디스펜서를 입찰하는 것과 다르지 않다. 물론 여기에는 약간의 과장이 섞여 있다. 현존하는 대다수의 PaaS가 웹 서식에 적절한 값을 채우는 데 개발자의 지식이 필요하다. 일례로, 마이크로소프트 애저(Azure)의 경우 웹 사이트의 응답 방식을 정의하려면 몇 가지 자바스크립트 함수를 작성해야 한다. 그러면 애저가 이들 함수를 적절한 라이브러리로 랩핑해 Node.js에서 실행시키는 식이다.

개발자 도구 6 : 브라우저 과거에는 데스크톱, 서버, 혹은 기기에 따라 각각 다른 소프트웨어를 개발했다. 이런 소프트웨어는 사용자와 상호작용하는 나름의 방식을 가지고 있었다. 하지만 지금은 모든 것이 브라우저를 경유한다. 예를 들어, 음악을 저장하기 위한 로컬 파일 서버를 구축할 때 URL로 접속해 웹 사이트에서 작업할 수도 있다. 애플의 데스크톱 위젯 역시 자바스크립트와 HTML로 개발되기 시작한 지 오래며, 많은 크로스-플랫폼 모바일 앱이 아파치 코르도바(Apache Cordova)를 통해 HTML이나 자바스크립트로 개발되고 있다. 물론 기존의 방식을 고집하는 분야도 있다. 예를 들어, 게임 분야에서는 브라우저를 거의 사용하지 않는다. 하지만 스크린 캔버스 객체를 다룰 줄 아는 자바스크립트 개발자가 늘면서 이 분야 역시 변하고 있다. 일례로 앵그리 버드(Angry Birds)는 브라우저에서도 실행할 수 있다.

개발자 도구 7 : 애플리케이션 컨테이너 과거에는 서버를 구축하는 작업은 쉽지 않았다. 먼저 작업을 완료한 개발자는 소프트웨어를 설치할 서버 팀에 메모를 보낸다. 그러면 서버 팀은 정확한 라이브러리를 받는 경우도 있고 그렇지 않은 경우도 있었지만, 어쨌든 결국에는 서버가 동작하게 하였다. 오늘날에는 도커(Docker) 같은 애플리케이션 컨테이너를 이용해 올바른 라이브러리가 모두 포함된 컨테이너를 손쉽게 전달할 수 있다. 테스트 기기에서 잘 동작하는 컨테이너라면 실제 서버에서도 거의 잘 동작한다. 또 모든 것이 묶음으로 제공되기 때문에 데스크톱과 서버 사이의 비호환성 문제도 거의 없다.

개발자 도구 8: 서비스 형태로 제공되는 인프라 서버의 경우, 클라우드 계층으로 흡수됐다. 이제 새로운 프로젝트를 위한 서버를 구축해 달라고 요청하는 개발자는 거의 없다. 대신 IaaS 사이트에 로그인한 다음 버튼만 누르면 운용할 수 있는 서버를 얻을 수 있다. 과거와 비교하면 훨씬 간단하다.

개발자 도구 9: Node.js와 JavaScript 과거의 웹 서버는 정적인 HTML을 반환하는 역할을 했는데, 그 이후 데이터베이스와 상호작용할 수 있는 동적인 웹 서버를 만드는 방법이 고안됐다. 모든 개발팀에서는 데이터베이스를 프로그래밍할 수 있는 SQL 전문가와 서버 코드를 개발할 수 있는 PHP 혹은 Java 개발자, HTML 템플릿을 디자인할 수 있는 디자이너를 한 명씩 고용했다. 클라이언트 쪽에서 실행되는 AJAX와 JavaScript가 유행하자 이런 언어를 다룰 줄 아는 개발자가 추가됐다. 지금은 모든 것이 자바스크립트로 되어있다. 브라우저는 물론이고, 서버(Node.js)와 데이터베이스(MongoDB, CouchDB) 계층도 마찬가지다. 클라이언트 쪽에서 HTML을 생성해 주는 jQueryMobile이나 EXT JS 같은 프레임워크에서는 종종 HTML까지도 자바스크립트코드로 되어 있다.

개발자 도구 10: 플러그인을 판매하는 스토어 고품질의 그래픽 게임을 개발하기 위해 그래픽 디자이너 또는 개발자를 추가로 고용하거나, 유니티 어셋 스토어(Unity Asset Store) 같은 스토어에서 필요한 플러그인을 모조리 구입할 수도 있다. 유니티 어셋 스토어의 상품 가운데 "모든 규모의 하수구 장면 개발이 가능한 모듈 형태의" 지하 감옥 하수구 타일 키트는 45달러에 판매되고 있기도 하다. 이처럼 저렴한 가격에 그래픽을 구현할 수 있는 상황에서, 개발자나 그래픽 디자이너를 고용하려고 할지 잘 모르겠다. 그 외에도 플러그인이나 확장 모듈, 라이브러리, 다른 부가적인 것들을 판매하는 스토어가 점점 더 많이 생겨나고 있다. 라이브러리나 프레임워크와 마찬가지로 이런 것들도 적절히 잘 구입하면 그만큼 개발 시간과 인력, 비용을 줄일 수 있다.

개발자 도구 11: 가상 머신 오늘날의 코드 대부분은 실리콘 칩이 이해할 수 있게 변환해 주는 가상 머신 위에서 실행된다. Java 가상 머신, C#/.Net 가상 머신, 그리고 지금은 자바스크립트 엔진이 코드의 주요 대상이다. 가상 머신의 인기는 소프트웨어 스택 전체를 흡수할 만큼 높아졌다. 과거에는 새로운 언어를 만들 때 전처리기에서부터 레지스터 할당기까지 스택 전체를 개발해야 했다. 하지만 오늘날에는 새로운 언어가 기존의 가상 머신 위에 위치한다. Clojoure, Scala, Jython, JRuby 등은 오라클의 일부가 된 썬(Sun)의 위대한 업적에 편승한 언어들이다. 브라우저 세계에서도 비슷한 현상이 나타나고 있다. 물론 자신만의 브라우저와 언어를 개발할 수도 있지만, 자바스크립트로 크로스-컴파일할 수 있게 만들 수도 있다. 이는 CoffeeScript 같은 도구에 사용된 방법이기도 하다. 구글에서는 자바를 자바스크립트로 변환해 주는 GWT(Google Web Toolkit)를 내놓기도 했다.

개발자 도구 12: 소셜 미디어 포탈 인터넷 초기에는 웹 사이트를 만든 다음 타인의 방문을 무작정 기다려야만 했으며, 방문자는 해당 웹 사이트의 URL을 기억해야만 했다. 오늘날에는 점점 더 많은 웹이 페이스북이나 세일즈포스 같은 대형 사이트로 흡수되고 있다. 직접 웹 사이트를 구축한다면, 전 세계의 인구가 페이스북이나 세일즈포스를 클릭하는 것을 구경만 해야 할 것이다. 해결책은 당연히 페이스북이나 세일즈포스 앱을 만드는 것이다. 이들 서비스는 어느 정도 플랫폼을 통합할 수 있도록 해줄 것이다. 하지만 플랫폼에 종속될 경우, 언제든지 내던져질 수 있다는 점을 고려해야 한다. 대형 포털 사이트의 노예가 되거나, 구경만 하거나 둘 가운데 하나를 선택할 수 있는 갈림길에 서 있다.

개발자 도구 13: 데브옵스 도구 과거의 개발자는 소프트웨어를 서버에 일일이 설치했다. 하지만 지금은 수십, 수백, 많게는 수천 대의 서버를 한 번에 대여하는 시대다. 이들 서버는 대부분 요청과 동시에 새로 생성되어야 하고, 최신 소프트웨어도 설치되어 있어야 하므로 사실상 수동으로는 작업이 불가능하다. 쉐프(Chef), 퍼핏(Puppet) 같은 서버 관리 도구를 통해 ‘데브옵스(devops)’로 입문하면 된다. 새로운 소프트웨어를 클라우드에 올리기만 하면 이 도구들은 모든 기기에서 같은 코드를 실행하며, 과거에 한 대의 기기에서 수동으로 했던 작업을 자동화해 준다. 구글 앱 엔진(Google App Engine) 같은 서비스는 이런 자동화 과정을 내부적으로 처리하고 있다. 개발자는 자신이 개발한 앱을 던져주기만 하면 된다. 그러면 자동으로 프로비저닝이 일어난다. 내부적으로 어떤 일이 일어나는지 알 필요도 없다. 그저 사용한 CPU 시간만큼 요금만 납부하면 된다.

개발자 도구 14: 깃허브(GitHub), 소스포지(SourceForge) 등을 통한 소셜 코드 공유 오픈소스 시대의 연 것은 코드 공유 사이트라 해도 과언이 아니다. 소스포지 같은 서비스가 있기 전에는 소프트웨어 개발은 ‘혼자’만의 작업일 뿐이었다. 타인의 코드를 보기 위해서는 그들이 기꺼이 코드를 전송해 주기를 마냥 기다려야만 했다. 오늘날, 코드 공유는 일종의 ‘소셜 네트워크’다. 소스포지나 깃허브 같은 사이트는 누구나 모든 코드를 보거나 수정할 수 있게 했다. 더불어 코드를 관리하고, 공유하고, 의논하는 과정이 한 곳에서 이루어질 수 있도록 통합했다. 덕분에 개발자는 하나의 인터페이스를 통해 코드를 보고, 수정을 제안할 수 있다. 불과 일주일 만에 수천, 수만 번 다운로드를 기록하는 프로젝트도 어렵지 않게 찾아볼 수 있다. 하지만 과거에는 절대 불가능한 일이었다. 이제 코드 공유 모델은 소유권이 있는 프로젝트에서도 따르고 있을 정도로 당연한 것이 되었다. 깃허브나 비트버킷(BitBucket) 같은 사이트는 제한된 그룹의 사람들에게만 공유 기능을 제한하는 비공개 코드 저장소를 유료로 제공함으로써 서비스를 유지하고 있다.

개발자 도구 15: 성능 모니터링 처음에는 코드의 성능을 추적하기가 수월했다. 코드가 시작될 때의 시간을 출력한 다음 끝날 때 시간을 출력하면 됐다. 좀 더 성실한 개발자는 여기에 시간차를 계산하는 식을 추가하기도 했다. 하지만 이 방법은 더는 쓸 수 없게 됐다. 여러 기기와 기기에 걸쳐 많은 문제가 나타나기 때문이다. 과거와 같은 방식의 분석을 적용하더라도, 비정상적인 통신이나 데이터베이스의 지연에 의한 진짜 병목 지점은 찾을 수 없다. 오늘날의 모니터링 도구는 모듈별 성능뿐 아니라 네트워크로 연결된 소프트웨어를 위해 네트워크 호출도 추적한다. 이렇게 해야만 무엇이 정상이고 무엇이 비정상인지 제대로 파악할 수 있다. 이는 한 대의 기기로만 구성된 프로그래밍 모델을 서로 연동이 잘 안될 수도 있는 수많은 도구의 네트워크 형태로 바꾸는 방법 가운데 하나일 뿐이다. 이미지 출처 : flickr/ billsophoto