2018년 소프트웨어 개발 전망 10가지

4. 특정 분야에 전문성을 띈 실용적 머신러닝 앱의 등장
머신러닝은 이제 과거의 추상적인 데이터 과학의 영역에서 주류 애플리케이션 개발 영역으로 넘어오고 있다. 유명 플랫폼들이 제공하는 사전 제작된 모듈의 가용성이 높아지고, 또 이들 모듈이 대규모의 데이터 세트를 분석할 때 아주 유용하다는 것이 증명되었기 때문이다. 머신러닝 기술에서 가장 가치 있고 중요한 인사이트는 맥락 정보가 있을 때 얻을 수 있다. 맥락 정보란 사용자의 과거 행적, 예전에 했던 질문들, 다른 사람들의 행위 패턴, 정상적 활동과 변칙적 활동의 구분 등을 말한다.

그러나 머신러닝 기술이 효용성을 갖기 위해서는 특정 전문 분야에 국한시킨 환경에서 교육과 조정 과정을 거쳐야 한다. 이런 학습 환경에는 머신러닝 기술이 분석하게 될 데이터 세트와 답하게 될 질문들도 포함되어야 한다. 예컨대 보안 애널리스트가 사용하는 머신러닝 애플리케이션은 변칙적인 사용자 행위 패턴을 식별해 내는 것을 목적으로 할 것이다. 반면 공장형 로봇의 운영 효율을 최적화 하기 위한 머신러닝 애플리케이션은 보안 목적의 애플리케이션과는 아주 다를 것이고, 이는 마이크로서비스 기반 애플리케이션의 의존도 맵핑을 하기 위한 머신러닝 애플리케이션과도 다를 수밖에 없다.

따라서 개발자들은 이러한 머신러닝 애플리케이션의 분야별 사용례를 숙지하고 있어야 할 것이다. 그래야만 어떤 데이터를 수집하고, 어떤 머신러닝 알고리즘을 적용할 것이며, 어떤 질문들을 던져야 할 지 알 수 있을 것이기 때문이다. 또한 특정 분야의 SaaS나 애플리케이션 패키지가 특정 프로젝트에 잘 맞는 것인지를 판단할 수 있어야 한다. 머신러닝 교육에 방대한 양의 교육 데이터가 필요하다는 사실을 고려한다면 말이다.

개발자들은 이제 머신러닝 기술을 이용하여 추천을 하거나 결과를 예측하고, 또 자동화 된 의사결정을 내려 줄 지능적 애플리케이션을 제작할 수 있게 될 것이다.

5. 데브옵스에서 노옵스로
개발자들의 신규 애플리케이션 및 기능 개발을 촉진하고, 품질 및 퍼포먼스 수준을 유지하는 데브옵스의 중요성은 이제는 보편적으로 받아들여지고 있다. 하지만 데브옵스라는 직무를 수행함에 있어 기존 개발 업무에 소요하던 시간 자원의 60% 가량을 운영 업무에 투입하게 되며, 결과적으로 개발 역량이 저하된다는 부분은 해결이 필요한 문제로 꾸준히 지적되어 왔다.

개발자에겐 다양한 지속적 통합 및 지속적 전달(CICD, Continuous Integration and Continuous Delivery) 도구들을 통합하고 그 통합 수준을 유지하며, 새로운 기술의 개발에 발맞춰 CICD 툴 체인을 지속적으로 업데이트하는 노력이 요구된다. CICD 중 CI(지속적 통합)는 모두가 신경 쓰고 있는 주제지만, CD(지속적 전달)까지 신경 쓰는 개발자는 많지 않은 것이 현실이다. 2018년 현업의 개발자들은 자신들의 ‘개발' 직무를 도와줄 조력자로 클라우드 서비스에 의지할 것이며, 진정한 CICD를 위한 더 많은 자동화가 요구될 것이다.

도커(Docker)는 사용자에게 패키징, 휴대성, 그리고 애자일 개발을 가능하게 하는 역량을 보장해주지만, 이러한 도커의 방식을 받아들이기 위해선 CD가 선행적으로 요구된다. 예를 들어 컨테이너를 사용 중인 상황에서 깃(Git)으로 코드 변경을 실행할 경우, 구축된 기본 구조는 새로운 코드 버전을 포함하는 도커 이미지가 되어야 한다. 나아가, 이 이미지는 자동적으로 도커 레지스트리 안으로 푸시되어야 하며, 해당 이미지로부터 배치된 컨테이너 역시 개발-테스트 환경 안으로 푸시 돼야 한다.

QA 테스팅 이후의 생산 배치, 조정, 보안 및 컨테이너 조정 과정은 모두 개발자의 관리 하에 놓여야 하는 과정이다. 개발자에게 더 빠르게 새로운 혁신을 요구하는 비즈니스 책임자라면, 개발 업무에 더 많은 시간을 보장해줄 수 있는 새로운 데브옵스 모델을 고민해야만 할 것이다.

6. 서비스형 모델이 주도하는 오픈소스 수요 확대
오픈소스 모델은 여전히 혁신의 가장 강력한 엔진이라 할 수 있지만, 이러한 혁신을 실제로 실행하고 유지하는 것은 보기보다 까다로운 일이다. 예를 들면 다음과 같은 과제들이 있다.

- 스트리밍 데이터/이벤트 관리 플랫폼이 필요해 카프카(Kafka)의 도움을 받고자 한다. 그러나 카프카를 이용하려면 부가적인 카프카 노드를 설정하고 카프카 클러스터를 로드해야 하며, 새로운 카프카 릴리즈가 나올 때마다 이들 클러스터를 업데이트하고, 또 이 서비스를 나머지 환경에 통합까지 해야 한다.

- 컨테이너 오케스트레이션에 쿠버네티스가 필요하다고 하자. 쿠버네티스 클러스터의 업그레이드, 백업, 저장 및 패치를 직접하는 대신 플랫폼에 이런 작업들을 맡겨버리면 된다. 쿠버네티스는 6주마다 릴리즈되기 때문에 플랫폼에 배치와 자체 치유가 필요하다.

- NoSQL 데이터베이스에 카산드라가 필요하다. 플랫폼 관리를 위해서는 카산드라 클러스터의 (점증적인, 또는 스케줄에 맞춘) 백업과 패칭, 클러스터링, 스케일링, 그리고 높은 가용성을 필요로 하게 될 것이다.

개발자들은 오픈소스에서 이러한 빠른 혁신을 실행하고, 운영 및 관리 측면에서 이들 기술을 관리하기 위해 점차 클라우드 서비스에 의존하게 될 것이다.