상전벽해··· 소프트웨어 개발의 본질을 바꾸는 21가지 기술

데브옵스 도구
과거의 개발자는 소프트웨어를 서버에 일일이 설치했다. 하지만 지금은 수십, 수백, 많게는 수천 대의 서버를 한 번에 대여하는 시대다. 이들 서버는 대부분 요청과 동시에 새로 생성되어야 하고, 최신 소프트웨어도 설치되어 있어야 하므로 사실상 수작업으로는 불가능한 일이다.

셰프(Chef), 퍼핏(Puppet) 같은 서버 관리 툴을 통해 ‘데브옵스(devops)’로 입문하면 된다. 새로운 소프트웨어를 클라우드에 올리기만 하면 이들 툴은 모든 기기에서 같은 코드를 실행하며, 과거에 한 대의 기기에서 수작업으로 했던 일을 자동화해 준다.

구글 앱 엔진(Google App Engine) 같은 서비스는 이런 자동화 과정을 내부적으로 처리하고 있다. 개발자는 자신이 개발한 앱을 던져주기만 하면 된다. 그러면 자동으로 프로비저닝이 일어난다. 내부적으로 어떤 일이 일어나는지 알 필요도 없다. 그저 사용한 CPU 시간만큼 요금만 납부하면 된다.

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

PaaS
과연 지금도 웹 사이트를 직접 구축하는 사람이 있을까? 아마도 다른 웹 사이트에 계정을 만든 다음 커스터마이징하는 방법을 택할 것이다. 웹 서식에 몇 개의 필드를 채우기만 하면 나머지는 웹 사이트가 다 알아서 해주기 때문이다. 이는 유튜브에 고양이 비디오를 올리거나 이베이에서 페즈(Pez) 디스펜서를 입찰하는 것과 다르지 않다.

물론 여기에는 약간의 과장이 섞여 있다. 현존하는 대다수의 PaaS가 웹 서식에 적절한 값을 채우는 데 개발자의 지식이 필요하다. 일례로, 마이크로소프트 애저의 경우 웹 사이트의 응답 방식을 정의하려면 몇 가지 자바스크립트 함수를 작성해야 한다. 그러면 애저가 이들 함수를 적절한 라이브러리로 랩핑해 Node.js에서 실행시키는 식이다.

플러그인을 판매하는 마켓플레이스
고품질의 그래픽 게임을 개발하기 위해 그래픽 디자이너 또는 개발자를 추가로 고용하거나, 유니티 어셋 스토어(Unity Asset Store) 같은 스토어에서 필요한 플러그인을 모조리 구입할 수도 있다. 유니티 어셋 스토어의 상품 가운데 "모든 규모의 하수구 장면 개발이 가능한 모듈 형태의" 지하 감옥 하수구 타일 키트는 45달러에 판매되고 있기도 하다. 이처럼 저렴한 가격에 그래픽을 구현할 수 있는 상황에서, 개발자나 그래픽 디자이너를 고용하려고 할지 잘 모르겠다.

그 외에도 플러그인이나 확장 모듈, 라이브러리, 다른 부가적인 것들을 판매하는 스토어가 점점 더 많이 생겨나고 있다. 라이브러리나 프레임워크와 마찬가지로 이런 것들도 적절히 잘 구입하면 그만큼 개발 시간과 인력, 비용을 줄일 수 있다.

소셜 미디어 포탈
인터넷 초기에는 웹 사이트를 만든 다음 타인의 방문을 무작정 기다려야만 했으며, 방문자는 해당 웹 사이트의 URL을 기억해야만 했다. 오늘날에는 점점 더 많은 웹이 페이스북이나 세일즈포스 같은 대형 사이트로 흡수되고 있다. 직접 웹 사이트를 구축한다면, 전 세계의 인구가 페이스북이나 세일즈포스를 클릭하는 것을 구경만 해야 할 것이다.

해결책은 당연히 페이스북이나 세일즈포스 앱을 만드는 것이다. 이들 서비스는 어느 정도 플랫폼을 통합할 수 있도록 해줄 것이다. 하지만 플랫폼에 종속될 경우, 언제든지 버림 받을 수 있다는 점을 고려해야 한다. 대형 포털 사이트의 노예가 되거나, 구경만 하거나 둘 가운데 하나를 선택할 수 있는 갈림길에 서 있다.

깃허브와 소셜 코드 공유
오픈소스 시대의 연 것은 코드 공유 사이트라 해도 과언이 아니다. 소스포지 같은 서비스가 있기 전에는 소프트웨어 개발은 ‘혼자’만의 작업일 뿐이었다. 타인의 코드를 보기 위해서는 그들이 기꺼이 코드를 전송해 주기를 마냥 기다려야만 했다.

오늘날, 코드 공유는 일종의 ‘소셜 네트워크’다. 소스포지나 깃허브 같은 사이트는 누구나 모든 코드를 보거나 수정할 수 있게 했다. 더불어 코드를 관리하고, 공유하고, 의논하는 과정이 한 곳에서 이루어질 수 있도록 통합했다. 덕분에 개발자는 하나의 인터페이스를 통해 코드를 보고, 수정을 제안할 수 있다. 불과 일주일 만에 수천, 수만 번 다운로드를 기록하는 프로젝트도 어렵지 않게 찾아볼 수 있다. 하지만 과거에는 절대 불가능한 일이었다.

이제 코드 공유 모델은 소유권이 있는 프로젝트에서도 따르고 있을 정도로 당연한 것이 되었다. 깃허브나 비트버킷(BitBucket) 같은 사이트는 제한된 그룹의 사람들에게만 공유 기능을 제한하는 비공개 코드 저장소를 유료로 제공함으로써 서비스를 유지하고 있다.

성능 모니터링
처음에는 코드의 성능을 추적하기가 수월했다. 코드가 시작될 때의 시간을 출력한 다음 끝날 때 시간을 출력하면 됐다. 좀 더 성실한 개발자는 여기에 시간차를 계산하는 식을 추가하기도 했다.

하지만 이 방법은 더는 쓸 수 없게 됐다. 여러 기기에 걸쳐 많은 문제가 나타나기 때문이다. 과거와 같은 방식의 분석을 적용하더라도, 비정상적인 통신이나 데이터베이스의 지연에 의한 진짜 병목 지점은 찾을 수 없다. 오늘날의 모니터링 도구는 모듈별 성능뿐 아니라 네트워크로 연결된 소프트웨어를 위해 네트워크 호출도 추적한다. 이렇게 해야만 무엇이 정상이고 무엇이 비정상인지 제대로 파악할 수 있다.

이는 한 대의 기기로만 구성된 프로그래밍 모델을 서로 연동이 잘 안될 수도 있는 수많은 도구의 네트워크 형태로 바꾸는 방법 가운데 하나일 뿐이다. editor@itworld.co.kr