SOFT GROUND Blog
블로그 목록
SW 개발 연대기

2014년 개발 연대기: 언어와 컨테이너, 플랫폼의 경계가 다시 그려지다

Java 8과 Swift, Docker 1.0과 Kubernetes 공개, HTML5 권고안, Android Studio 1.0과 .NET Core 오픈 소스 계획, 국내 모바일 플랫폼 재편과 ActiveX 대체 흐름으로 2014년의 개발 변화를 살펴봅니다.

2026년 7월 24일약 22분
#2014#Java 8#Swift#Docker#Kubernetes#HTML5#Android Studio#.NET Core#다음카카오#ActiveX#개발 연대기

2014년에는 오래된 플랫폼이 새로운 문법을 받아들이고, 막 등장한 기술이 운영 환경으로 나아갔다. Java 8은 람다 표현식과 Stream API로 Java 코드에 함수형 처리 방식을 들였고, Apple은 Objective-C와 함께 사용할 새 언어 Swift를 공개했다. Microsoft는 .NET Core를 오픈 소스로 개발하고 여러 운영체제로 확장하겠다는 계획을 밝혔다.

서버 쪽에서는 Docker가 1.0에 도달했다. Google은 여러 서버에 걸쳐 컨테이너를 배치하고 관리하는 Kubernetes를 오픈 소스로 공개했다. 둘은 같은 해에 나타났지만 같은 성숙 단계는 아니었다. Docker 1.0은 운영 사용을 선언한 릴리스였고, Kubernetes는 아직 1.0 이전의 매우 초기 프로젝트였다.

웹에서는 수년간 구현과 논의가 이어진 HTML5가 W3C 권고안이 되었다. 국내에서도 ActiveX 같은 비표준 플러그인을 웹 표준 기술로 바꾸려는 가이드와 시범 사업이 추진되었다. 모바일 서비스 시장에서는 다음과 카카오의 합병으로 웹 포털과 모바일 메신저 플랫폼의 결합이 이루어졌다.

2014년을 보여주는 장면

분야주요 변화개발자에게 생긴 의미
JavaJava SE 8 출시람다·Stream·새 날짜와 시간 API를 표준 플랫폼에서 사용
Apple 개발Swift 공개Objective-C와 공존하는 새 정적 타입 언어와 Playgrounds 제공
컨테이너Docker 1.0 출시컨테이너 이미지의 빌드·배포·실행 흐름을 운영 환경으로 확대
오케스트레이션Kubernetes 공개여러 호스트의 컨테이너 배치와 상태 관리를 자동화할 방향 제시
웹 표준HTML5 W3C 권고안문서·멀티미디어·응용 프로그램 API를 포괄한 표준 기준 확정
AndroidAndroid Studio 1.0Gradle 기반 Android 전용 IDE가 안정판에 도달
Microsoft.NET Core 오픈 소스 계획.NET의 일부를 모듈식·크로스 플랫폼으로 재구성하는 전환 시작
국내 플랫폼다음카카오 출범포털의 콘텐츠·검색 자산과 모바일 관계망·서비스 플랫폼 결합
국내 웹ActiveX 대체 정책단일 브라우저 플러그인에서 HTML5·JavaScript 기반 구현으로 이동

Java 8, 컬렉션을 ‘어떻게 반복할지’보다 ‘무엇을 할지’로

Java SE 8은 3월 18일 출시되었다. 가장 눈에 띈 언어 변화는 람다 표현식이었다. 이름 없는 동작을 값처럼 전달할 수 있게 되면서, 하나의 추상 메서드를 가진 함수형 인터페이스를 이전보다 짧게 구현할 수 있었다. 메서드 참조와 인터페이스의 default method도 함께 도입되었다.

List<Integer> years = java.util.Arrays.asList(2012, 2013, 2014);

years.stream()
     .filter(year -> year >= 2013)
     .map(year -> year + "년")
     .forEach(System.out::println);

Stream API는 컬렉션의 요소를 외부 반복문으로 하나씩 조작하는 대신 filter, map, reduce 같은 연산의 흐름으로 표현하게 했다. 스트림은 자료를 저장하는 컬렉션이 아니라 데이터를 처리하는 파이프라인이며, 필요할 때 병렬 실행을 선택할 수 있었다. 병렬 스트림이 모든 작업을 자동으로 빠르게 만드는 것은 아니므로 작업 크기, 공유 상태와 분할 비용을 측정해야 했다.

날짜와 시간 처리도 크게 개선되었다. java.time 패키지는 Joda-Time의 경험과 JSR 310을 바탕으로 불변 객체, 명확한 날짜·시간대 모델과 비교적 일관된 API를 제공했다. 기존 Date와 Calendar의 가변성과 혼란스러운 월 번호 같은 문제를 줄였다.

Java 8은 오랜 기간 기업 시스템의 기준 버전으로 남게 되지만, 2014년에 모든 현장이 곧바로 전환한 것은 아니다. 애플리케이션 서버와 프레임워크, 빌드 도구의 호환성을 확인해야 했고 기존 Java 6·7 운영 환경도 널리 남아 있었다. 이 해의 변화는 Java가 기존 호환성을 유지하면서 표현력을 크게 넓혔다는 데 있었다.

Swift, Objective-C 생태계 안에서 출발한 새 언어

Apple은 6월 2일 WWDC에서 iOS와 OS X 애플리케이션을 위한 Swift를 공개했다. Xcode 6 베타와 함께 제공된 Swift는 정적 타입과 타입 추론, 제네릭, 클로저, 튜플, 선택 값을 나타내는 Optional 등 현대적인 언어 기능을 내세웠다.

let years = [2012, 2013, 2014]
let recent = years.filter { $0 >= 2013 }
                  .map { "\($0)년" }

Playgrounds는 코드를 입력하면서 결과를 바로 확인하는 대화형 환경을 제공했다. UI나 알고리즘을 작은 단위로 시험하고 언어를 학습하는 과정의 피드백을 빠르게 만들었다. Swift 코드는 기존 Objective-C 코드 및 Cocoa·Cocoa Touch 프레임워크와 함께 사용할 수 있어 기존 프로젝트가 한 번에 전부 다시 작성될 필요는 없었다.

초기 Swift를 완성된 안정 언어로 보면 안 된다. Swift 1.0은 Xcode 6과 함께 9월에 배포되었고, 이후 몇 년 동안 문법과 API가 크게 바뀌었다. 오픈 소스 공개도 2014년이 아니라 2015년 12월이었다. 2014년에는 Apple 플랫폼의 주력 언어를 장기적으로 교체할 방향이 처음 외부에 제시되었다.

Docker 1.0, 실험적인 도구에서 운영 가능한 릴리스로

Docker는 공개 15개월 만인 6월 9일 버전 1.0을 출시했다. 프로젝트는 이 버전을 운영 환경에 사용할 수 있는 단계로 선언하고 상용 지원을 제공하기 시작했다. Docker Hub도 이미지의 검색·공유·자동 빌드를 위한 중심 서비스로 함께 정식 공개되었다.

2014년 3월의 Docker 0.9부터 기본 실행 드라이버는 LXC에서 Docker가 Go로 만든 libcontainer로 바뀌었다. 이를 통해 Docker가 Linux 컨테이너의 실행을 더 직접 제어할 기반을 마련했다. 이미지와 Dockerfile을 이용해 동일한 애플리케이션 구성을 개발·시험·운영으로 전달한다는 생각도 더 설득력을 얻었다.

1.0이라는 번호가 운영의 모든 문제를 해결했다는 뜻은 아니었다. 컨테이너의 로그, 보안 경계, 네트워크, 서비스 발견, 비밀 정보와 영구 데이터는 별도로 설계해야 했다. 한 호스트에서 컨테이너를 잘 실행하는 것과 여러 서버에서 장애를 견디며 서비스를 운영하는 것 사이에는 큰 간격이 남아 있었다.

Kubernetes, 컨테이너를 여러 서버에서 관리하려는 초기 답

Kubernetes의 첫 공개 저장소 커밋은 6월 6일 이루어졌고, Google은 6월 10일 DockerCon에서 프로젝트를 발표했다. Google 내부의 대규모 작업 관리 시스템 Borg에서 얻은 생각을 바탕으로 만들었지만 Borg의 코드를 그대로 공개한 것은 아니었다. 초기 구현은 Go로 작성된 별도의 오픈 소스 프로젝트였다.

Docker가 개별 컨테이너를 이미지로 만들고 한 호스트에서 실행하는 경험을 개선했다면 Kubernetes는 여러 호스트에 컨테이너를 어디에 배치하고, 원하는 수를 어떻게 유지하며, 장애가 난 인스턴스를 어떻게 대체할 것인가를 다루려 했다. 초기에도 Pod의 전신과 복제, 서비스 발견에 관한 핵심 생각이 보였다.

그러나 2014년의 Kubernetes는 매우 거칠었다. 프로젝트 자체의 회고에 따르면 공개 직전까지 Pod가 Task라는 이름이었을 정도였고, 안정판 1.0은 2015년 7월에 나왔다. CNCF도 2015년에 설립되었다. 따라서 이 해는 Kubernetes가 산업 표준이 된 시점이 아니라 컨테이너 오케스트레이션이라는 문제와 공개된 해법이 개발자 앞에 등장한 시점이다.

HTML5, 이미 쓰이던 기술이 권고안에 도달하다

W3C는 10월 28일 HTML5를 권고안으로 발표했다. 이는 HTML5 기능이 그날 갑자기 브라우저에 추가되었다는 뜻이 아니다. 브라우저들은 그보다 앞서 video, audio, canvas, 웹 저장소와 여러 폼 기능을 단계적으로 구현하고 있었고 개발자도 이를 사용하고 있었다.

권고안은 상호 운용 가능한 구현 경험을 바탕으로 표준 문서가 안정된 단계에 이르렀음을 뜻했다. 플러그인 없이 미디어를 재생하고, 문서의 의미를 나타내는 요소를 사용하며, 브라우저를 응용 프로그램 실행 환경으로 활용하는 공통 기준이 더 분명해졌다.

HTML5라는 이름 아래 언급되던 모든 웹 API가 하나의 HTML5 문서에 포함된 것은 아니다. WebSocket, WebRTC, Geolocation 같은 기술은 각기 다른 명세와 진행 단계를 가졌다. 또한 권고안이 나왔다고 오래된 브라우저 호환 문제가 사라지지도 않았다. 개발자는 기능 탐지와 대체 동작을 계속 준비해야 했다.

Android Studio 1.0, 프리뷰를 마치고 공식 개발 환경으로

2013년 초기 프리뷰로 시작한 Android Studio는 2014년 12월 버전 1.0에 도달했다. IntelliJ IDEA 기반의 코드 분석·리팩터링과 Android 전용 레이아웃 도구, Gradle 빌드 시스템을 결합한 첫 안정판이었다.

Gradle 플러그인은 같은 코드에서 무료·유료판이나 개발·운영 환경처럼 여러 build variant를 구성하고, 의존성과 서명 설정을 빌드 정의에 기록할 수 있게 했다. IDE에서 실행하는 빌드와 명령행·지속적 통합 서버의 빌드가 같은 구조를 공유하는 것도 중요했다.

Google은 이후 Android Studio를 Android 앱 개발의 공식 IDE로 삼았다. 하지만 1.0 출시 순간 Eclipse ADT 프로젝트가 모두 즉시 사라진 것은 아니며, 기존 작업 공간과 빌드 절차를 이전하는 시간이 필요했다. 2014년은 Android 개발 도구의 중심이 이동하기 시작한 기준점이었다.

.NET Core, Windows 바깥을 향한 공개 개발

Microsoft는 11월 12일 서버용 .NET Core 스택을 오픈 소스로 공개하고 Linux와 macOS 지원을 추진한다고 발표했다. .NET Framework 전체를 그대로 이식하는 것이 아니라, 필요한 구성요소를 NuGet 패키지로 선택할 수 있는 모듈식 런타임과 프레임워크를 새로 구성하는 접근이었다.

이는 Windows와 Visual Studio 중심이었던 .NET의 개발·배포 모델을 바꾸겠다는 선언이었다. 개발자가 GitHub에서 소스와 설계 논의를 보고 기여하며, ASP.NET 서버 애플리케이션을 여러 운영체제에서 실행하는 방향이 제시되었다.

이 발표를 2014년에 완성된 현대 .NET의 출시로 적어서는 안 된다. 당시에는 .NET 2015 Preview와 초기 .NET Core 계획 단계였고, .NET Core 1.0 정식 출시는 2016년이었다. 기존 .NET Framework와 Windows 데스크톱 기술도 계속 별도로 존재했다.

국내: 다음카카오, 포털과 모바일 플랫폼의 결합

다음커뮤니케이션과 카카오는 5월 26일 합병 계약을 발표했고, 합병 절차를 마친 다음카카오는 10월 1일 공식 출범했다. 다음은 검색·뉴스·지도·메일·카페와 광고 자산을, 카카오는 카카오톡의 관계망과 게임·콘텐츠 유통 플랫폼을 갖고 있었다.

개발 생태계의 관점에서는 사용자를 모으는 경로가 PC 포털에서 모바일 메신저와 플랫폼으로 이동하고 있음을 보여준 사건이었다. 카카오 계정, 친구 관계, 메시지와 게임 유통을 활용하는 서비스가 빠르게 성장했고 다음의 콘텐츠·검색·지도 기술이 결합될 여지가 생겼다.

합병 발표가 곧 모든 서비스와 API의 기술 통합을 뜻한 것은 아니다. 서로 다른 계정, 데이터, 조직과 인프라를 연결하는 작업은 이후에 이어졌다. 외부 개발사에도 플랫폼 의존의 기회와 위험이 함께 있었다. 큰 사용자 기반에 접근할 수 있었지만 정책·노출·수익 배분의 변화가 서비스 성과에 직접 영향을 줄 수 있었다.

국내: ActiveX를 웹 표준으로 바꾸려는 구체적인 안내

미래창조과학부와 한국인터넷진흥원은 9월 ‘인터넷 이용환경 개선 가이드라인’을 보급했다. 인증·결제·보안·게임·멀티미디어 등에서 ActiveX와 다른 비표준 플러그인으로 구현하던 기능을 HTML5와 JavaScript 기반 기술 또는 여러 운영체제를 지원하는 방식으로 전환하는 방안을 제시했다.

당시 국내 주요 웹사이트는 Internet Explorer와 ActiveX에 대한 의존이 여전히 높았다. 그 결과 다른 브라우저나 macOS·모바일 기기에서 핵심 기능을 이용하기 어려웠고, 설치된 플러그인의 취약점과 업데이트도 보안 문제가 되었다. 정부와 KISA는 대체기술 개발 시범 사업과 웹 솔루션 전시·설명회를 함께 추진했다.

HTML5 권고안과 국내 가이드라인이 같은 해에 나온 것은 상징적이지만, ActiveX가 2014년에 제거되었다는 뜻은 아니다. 공인인증, 키보드 보안, 파일 전송과 문서 출력처럼 여러 제품과 규제가 얽힌 기능은 전환에 시간이 걸렸다. 개발자는 단순히 플러그인을 다른 실행 파일로 바꾸는 것과 브라우저 표준만으로 서비스를 다시 설계하는 것을 구분해야 했다.

2014년의 의미

2014년에는 언어와 플랫폼이 기존 기반을 버리지 않으면서 새 방향을 열었다. Java 8은 호환성을 지키며 함수형 표현과 현대적인 날짜 API를 받아들였고, Swift는 Objective-C와 공존하는 방식으로 Apple 개발의 다음 세대를 시작했다. .NET Core의 공개 개발 계획은 Microsoft 플랫폼과 Windows의 결합을 느슨하게 만들 첫 단계였다.

Docker 1.0은 컨테이너를 실제 운영 선택지로 끌어올렸고 Kubernetes는 여러 컨테이너를 자동으로 관리하는 문제를 공개했다. HTML5 권고안과 Android Studio 1.0은 이미 진행되던 웹·모바일 개발 방식에 안정된 기준점을 제공했다.

국내에서는 다음카카오의 출범이 모바일 플랫폼 중심의 서비스 재편을 드러냈고, ActiveX 대체 가이드라인이 웹 호환성을 구체적인 개발 과제로 만들었다. 2015년에는 ECMAScript 2015, React Native, Kubernetes 1.0, TensorFlow, Windows 10과 HTTP/2가 이 흐름을 언어·모바일·클라우드·인공지능·웹 전송 계층으로 더 확장하게 된다.

참고 자료

블로그 목록으로 돌아가기