가상화ㆍ컨테이너 / 개발자 / 애플리케이션 / 클라우드

“과거는 잊어라” 소프트웨어 개발의 본질을 바꾸는 21가지 기술

Peter Wayner | InfoWorld 2017.08.07


코드 검토와 스타일 규칙
과거에는 N명의 프로그래머들이 제작한 대규모 프로그램 코드에는 최소 N개의 뚜렷한 스타일이 존재했고, 정신분열적인 프로그래머들로 인해 그보다 더 많은 스타일이 혼재하는 경우도 흔했다. 지금은 각 프로그래머 팀들은 이디엄과 설계 패턴의 일관성을 지켜 코드를 더 알아보기 쉽도록 하기 위해 균일한 스타일을 강제하는 메커니즘을 개발하고 있어 이러한 스타일의 차이도 차츰 옛날 일이 되고 있다.

그러나 균일한 스타일에 순응해야 하는 것이 달갑지 않은 프로그래머도 있다. 재능이 남달리 뛰어난 프로그래머 또는 자기 주장이 강한 프로그래머는 자신의 기량이 억눌린다고 느끼는 경우가 많다. 코드 검토는 때때로 노골적인 대립으로 이어져 팀원들 간 감정적인 상처와 팀 분열로 이어지기도 한다. 최악의 경우 방향성을 상실하여 죽도 밥도 아닌 결과물을 내놓게 된다.

이와 같은 모든 문제점에도 불구하고 관리자들은 이러한 아이디어를 계속해서 도입하고 있다. 프로그래머의 좋지 않은 습관을 차단하고 불완전한 코드를 걸러내는 유일한 방법이기 때문이다. 소수 천재의 창의성을 좌절시키는 결과를 초래하기도 하지만 그 정도는 감수해야 한다.

전처리기와 린팅(Preprocessors and linting)
과거에는 컴파일러가 사용되지 않는 변수를 발견하기라도 하면 재수가 좋다고 느끼곤 했다. 지금은 논리 또는 스타일에서 오류를 잡아내는 코드 전처리 툴이 넘쳐난다. 변수를 선언하지 않았다면? 더 나쁜 경우로, 공백과 탭의 조합을 잘못 사용했다면?

에어비엔비(Airbnb) 소속 팀은 자바스크립트 코드를 위한 스타일 가이드를 공표하면서 인터넷에서 유명세를 탔다. 이 가이드는 유능한 프로그래머는 더하기 기호의 양쪽 모두에 공백을 넣으며, 그 외의 모든 형태는 나쁘다고까지 명시했다. 이처럼 가혹할 만큼의 균일성이 좋은 것일까? 어쩌면 이 규칙을 만든 이들은 사람들이 난감해 하는 모습을 보며 만족스러운 미소를 짓고 있을지도 모른다. 그러나 최소한 이들은 개발자가 자신의 어리석은 실수를 세상에 내보이기 전에 잡아낼 수 있는 도구를 제공한다.

가상머신
오늘날의 코드 대부분은 실리콘 칩이 이해할 수 있게 변환해 주는 가상머신 위에서 실행된다. 자바 가상머신, C#/.Net 가상머신, 그리고 지금은 자바스크립트 엔진이 코드의 주요 대상이다.

가상 머신의 인기는 소프트웨어 스택 전체를 흡수할 만큼 높아졌다. 과거에는 새로운 언어를 만들 때 전처리기에서부터 레지스터 할당기까지 스택 전체를 개발해야 했다. 하지만 오늘날에는 새로운 언어가 기존의 가상머신 위에 위치한다. Clojoure, Scala, Jython, JRuby 등은 오라클의 일부가 된 썬의 위대한 업적에 편승한 언어들이다.

브라우저 세계에서도 비슷한 현상이 나타나고 있다. 물론 자신만의 브라우저와 언어를 개발할 수도 있지만, 자바스크립트로 크로스컴파일할 수 있게 만들 수도 있다. 이는 CoffeeScript 같은 도구에 사용된 방법이기도 하다. 구글은 자바를 자바스크립트로 변환해 주는 GWT(Google Web Toolkit)를 내놓기도 했다.

API
과거 개발자들은 주로 데이터 구조에 대해 고민했다. 모든 정보를 바이트 블록으로 묶고, 바이트를 하나하나 센 다음 어떤 값이 특정 포인터를 기준으로 정확한 거리에 위치하는지를 확인해야 했다. 다행히 지금은 컴파일러가 이와 같은 작업 대부분을 대신해 준다.

오늘날에는 이보다 훨씬 더 정확한 인터페이스인 API로 작업할 수 있다. API는 보통 완전히 다른 디바이스에서 서비스되며, 다른 업체에서 제공하는 서비스를 매 호출 시마다 요금을 지불하고 이용할 수도 있다. 주소와 우편번호를 위도와 경도로 바꾸고 싶을 경우, 비용을 지불한 뒤 원하는 결과를 얻을 수 있는 API를 사용하면 된다.

일반적으로 데이터는 그리 치밀한 구조화가 필요 없다. 바이트의 수를 세는 예전 방식은 JSON이나 XML처럼 파싱이 가능한 데이터 구조로 대체된 지 오래다. 그저 구분 점을 올바른 위치에 찍었는지만 확실히 하면 되며, 이를 처리해 주는 라이브러리도 있다.

새로운 사용자 인터페이스
‘사용자 인터페이스(User Interface)’라는 용어는 한때 명령줄, 또는 클릭 가능한 그림 및 아이콘으로 구성된 GUI, 둘 중 하나를 결정하는 의미로 사용됐다. 지금은 텔레비전도 웹사이트를 열고 모든 전화기에 시리나 코타나 같은 개인 비서가 있는 “스마트”한 시대다. 곧 모든 부엌과 거실에는 누군가 불러 주기를 상시 기다리는 마이크가 존재하게 된다. 텔레파시가 구현될 날이 머지않은 듯이 느껴진다.

다양한 구조와 메타포를 사용하는 새로운 라이브러리와 툴을 익혀야 하는 프로그래머들에게 이런 현상은 모두 과제다. 새로운 영역은 곧 프로그래머가 차용하거나 기반으로 삼을 정립된 방식이 거의 없다는 것을 의미한다. 모든 것을 처음부터 새로 만들어야 한다. 다만 이 새로운 길에서는 프로그래머가 해야 할 작업이 간소화될 수 있다. 사용자가 단순히 온도를 알고 싶어 한다면, 굳이 온전한 앱이나 멋진 사용자 인터페이스를 만들 이유가 없기 때문이다. 그냥 음성으로 숫자를 말해주면 끝이다. 작은 앱 하나를 만들기 위해 몇 기가바이트나 되는 용량의 애플 엑스코드(Xcode)를 오후 내내 다운로드했던 경험이 있는 사람에게 이 단순함은 생소하기까지 하다.

브라우저
과거에는 데스크톱, 서버, 혹은 디바이스에 따라 각각 다른 소프트웨어를 개발했다. 이런 소프트웨어는 사용자와 상호작용하는 나름의 방식을 가지고 있었다. 하지만 지금은 모든 것이 브라우저를 경유한다. 예를 들어, 음악을 저장하기 위한 로컬 파일 서버를 구축할 때 URL로 접속해 웹 사이트에서 작업할 수도 있다. 애플의 데스크톱 위젯 역시 자바스크립트와 HTML로 개발하기 시작한 지 오래며, 많은 크로스 플랫폼 모바일 앱이 아파치 코르도바(Apache Cordova)를 통해 HTML이나 자바스크립트로 개발되고 있다.

물론 기존의 방식을 고집하는 분야도 있다. 예를 들어, 게임 분야에서는 브라우저를 거의 사용하지 않는다. 하지만 스크린 캔버스 객체를 다룰 줄 아는 자바스크립트 개발자가 늘면서 이 분야 역시 변하고 있다. 일례로 앵그리 버드(Angry Birds)는 브라우저에서도 실행할 수 있다.

도커와 컨테이너
과거에는 서버를 구축하는 작업이 쉽지 않았다. 먼저 작업을 완료한 개발자는 소프트웨어를 설치할 서버 팀에 메모를 보낸다. 그러면 서버 팀은 정확한 라이브러리를 받는 경우도 있고 그렇지 않은 경우도 있었지만, 어쨌든 결국에는 서버가 동작하게 했다.

오늘날에는 도커(Docker) 같은 애플리케이션 컨테이너를 이용해 올바른 라이브러리가 모두 포함된 컨테이너를 손쉽게 전달할 수 있다. 테스트 기기에서 잘 동작하는 컨테이너라면 실제 서버에서도 거의 잘 동작한다. 또 모든 것이 묶음으로 제공되기 때문에 데스크톱과 서버 사이의 비호환성 문제도 거의 없다.

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.