.jpg)
머신 러닝 알고리즘 통한 솔루션 개발, 기존 개발과 크게 달라
기존 머신 러닝 플랫폼들 가격 너무 비싸 대체품들 서서히 나오기 시작
[보안뉴스 문가용 기자] 머신 러닝만 사용하면 솔루션 개발에 있어 커다란 발전이 있을 거라고 다들 말한다. 소프트웨어 제품의 생애주기에도 변혁이 있을 것이라는 기대감도 충만하다. 텍스트를 기반으로 한 사용자 인터페이스가 챗봇으로 대체되면서 데이터 처리도 더 깔끔해질 것이라고 한다.
다행히 머신 러닝을 이용한 소프트웨어 개발의 경험이 누적되면서, 위와 같은 약속들을 좀 더 객관적으로 볼 수 있게 되었다. 머신 러닝을 통한 개발 및 관리를 해본 전문가들은 좋거나 나쁜 점을 말하기 전에, “머신 러닝을 활용한 소프트웨어 개발은 전통의 개발과는 확실히 다르다”고 말한다.
머신 러닝 엔지니어들은 실험용 모델을 만들고, 이를 적은 데이터 샘플에 적용시켜 돌린다. 그리고 이 모델들을 도메인 전문가 및 데이터 과학자들과 공유해 피드백을 받는다. 이 때 사용하는 툴이 주피터(Jupyter) 혹은 제플린(Zeppelin)이다.
이렇게 해서 개발을 더 진행해도 되겠다는 결정이 내려지면, 데이터를 입수하고, 정리해, 중복 제거하는 일이 진행된다. 데이터는 훈련용과 확인용으로 구분된다. 훈련용 데이터는 실험용 모델을 정교하게 다듬는 데 활용되고, 확인용 데이터는 그렇게 다듬어진 모델이 올바른 방향으로 훈련되고 있는지를 확인하는 데 사용된다.
머신 러닝 엔지니어들은 자신들의 모델에 엄청나게 많은 분량의 데이터를 주입시킨다. 이 과정에 걸리는 시간을 단축하기 위해 많은 프로세서들에서 훈련 과정을 동시에 진행한다. 그리고 각 훈련 과정이 끝날 때마다 결과물을 합친다. 이 과정은 반복적이고 기계적일 수 있으며, 오류가 발견된다면 모델을 수정하고, 훈련을 처음부터 재개할 수도 있다.
또한 훈련 과정은 모델을 업데이트 하거나 문제 등이 발생해 대대적인 변화를 줬을 때 다시 시작해야 한다. 이 때 모델만 처음으로 되돌리는 게 아니라 데이터를 수집하는 것부터 다시 시작해야 할 때가 많다. 전통적인 소스코드 제어 체제 아래에서는 매우 힘들어지는 부분이다.
모델을 충분히 훈련시켰다면 어떤 문제를 주고, 그 결과를 실제 값(확인용 데이터)과 비교한다. 정확도를 파악하기 위함이다. 충분히 만족할 만한 성과가 나왔다면 이 모델은 애플리케이션과 합쳐져 인프라를 통해 배포되기 시작한다. 모델의 유형에 따라 인프라 환경이나 배포 시스템을 달리 해야 한다.
머신 러닝 소프트웨어의 또 다른 특징이라고 하면, 전통의 소프트웨어들보다 훨씬 섬세하고 민감하며, 부서지기 쉽다는 것이다. 머신 러닝 알고리즘은 비결정적인 특성을 가지고 있어, 주입되는 데이터의 유형이나 질에 그 성능이 크게 좌지우지 된다. 데이터가 온전치 않으면 머신 러닝 알고리즘은 부정확한 결과를 만들어낼 것이며, 다른 모델에 의해 교체가 불가피해진다.
또 기존 소프트웨어보다 머신 러닝 소프트웨어가 ‘부서지기 쉬운’ 이유는 모든 과정이 밀접하게 연결되어 있기 때문이다. 즉 일부 요소에만 작은 변화를 가한다는 게 불가능하다. 하나의 변화는 통째 변화를 의미한다.
그래서 많은 엔지니어링 팀들이 현존하는 오픈 소스 툴들을 가지고 이리 저리 조합해 자신만의 머신 러닝 운영 환경을 만들기 시작했다. 이 때 사용되는 툴들이 아까 말한 주피터를 포함해 에어플로우(AirFlow), 도커(Docker), 큐버네티스(Kubernetes) 등이다. 그러나 이러한 환경을 조성하는 것은 비용이 지나치게 높을 수 있어, 모든 조직들이 다 시험해볼 만한 건 아니다. 그래서 대체품들이 생겨나기 시작했는데, 그 중 대표적인 것들은 다음과 같다.
1) 아마존 세이지메이커(Amazon SageMaker) : 개발자들이 머신 러닝 모델들을 쉽게 만들고 훈련시키고 구축할 수 있도록 해주는 플랫폼이다.
2) 야트 사이언스옵스(Yhat ScienceOps) : 종단간 플랫폼으로 머신 러닝 API를 실시간으로 개발, 구축, 관리할 수 있도록 해준다.
3) 파키덤(Pachyderm) : 머신 러닝 파이프라인의 개발에 있어 모든 단계들을 자동화시켜주는 환경이다.
이 세 가지 제품들은 머신 러닝 알고리즘의 개발과 구축 과정을 크게 간소화시켜준다. 하지만 무조건 써보기 전에 다음과 같은 질문을 해보는 것이 좋다. “우리에게 정말 필요한가? 회사 내에 도입한다고 하면, 사용이 가능한가? 자동화 소프트웨어 툴을 지금의 개발 공정이나 업무 과정에 도입하는 게 가능한가?
또한 위 세 가지 제품들은 아직 검증을 충분히 거치지 못한 ‘새 것’들이다. 모든 새 제품들이 그렇듯 안정성이나 퍼포먼스와 같은 측면에서 조금 더 확인할 부분들이 존재한다. 그러므로 시험에 시험을 거치고 확신이 선 후에 도입을 실행하는 것을 추천한다. 요즘 머신 러닝 알고리즘은 굉장히 인기가 많은 분야이기 때문에 비슷한 성능의 오픈소스를 구하는 게 그리 어렵지 않다. 가능하다면 무료 버전을 구해 최대한 실제와 비슷하게 실험하는 게 좋다.
확신이 선 후 위 제품들 중 하나 혹은 일부를 도입하기로 했다면, 그리고 충분한 실력을 갖춘 기술자가 있어 잘 활용할 수 있다면, 아마 생산 속도는 크게 향상될 것이다. 그러나 장점 뒤에는 반드시 단점이 따라온다. 새로운 공정과 절차가 도입된 때문에 다른 놓치는 것들이 있을 것이다. 초반엔 이런 부분에 늘 신경 쓰고 주의를 기울여야 한다.
글 : 모시 크랭크(Moshe Kranc), Ness Digital Engineering
[국제부 문가용 기자(globoan@boannews.com)]
기존 머신 러닝 플랫폼들 가격 너무 비싸 대체품들 서서히 나오기 시작
[보안뉴스 문가용 기자] 머신 러닝만 사용하면 솔루션 개발에 있어 커다란 발전이 있을 거라고 다들 말한다. 소프트웨어 제품의 생애주기에도 변혁이 있을 것이라는 기대감도 충만하다. 텍스트를 기반으로 한 사용자 인터페이스가 챗봇으로 대체되면서 데이터 처리도 더 깔끔해질 것이라고 한다.
[이미지 = iclickart]
다행히 머신 러닝을 이용한 소프트웨어 개발의 경험이 누적되면서, 위와 같은 약속들을 좀 더 객관적으로 볼 수 있게 되었다. 머신 러닝을 통한 개발 및 관리를 해본 전문가들은 좋거나 나쁜 점을 말하기 전에, “머신 러닝을 활용한 소프트웨어 개발은 전통의 개발과는 확실히 다르다”고 말한다.
머신 러닝 엔지니어들은 실험용 모델을 만들고, 이를 적은 데이터 샘플에 적용시켜 돌린다. 그리고 이 모델들을 도메인 전문가 및 데이터 과학자들과 공유해 피드백을 받는다. 이 때 사용하는 툴이 주피터(Jupyter) 혹은 제플린(Zeppelin)이다.
이렇게 해서 개발을 더 진행해도 되겠다는 결정이 내려지면, 데이터를 입수하고, 정리해, 중복 제거하는 일이 진행된다. 데이터는 훈련용과 확인용으로 구분된다. 훈련용 데이터는 실험용 모델을 정교하게 다듬는 데 활용되고, 확인용 데이터는 그렇게 다듬어진 모델이 올바른 방향으로 훈련되고 있는지를 확인하는 데 사용된다.
머신 러닝 엔지니어들은 자신들의 모델에 엄청나게 많은 분량의 데이터를 주입시킨다. 이 과정에 걸리는 시간을 단축하기 위해 많은 프로세서들에서 훈련 과정을 동시에 진행한다. 그리고 각 훈련 과정이 끝날 때마다 결과물을 합친다. 이 과정은 반복적이고 기계적일 수 있으며, 오류가 발견된다면 모델을 수정하고, 훈련을 처음부터 재개할 수도 있다.
또한 훈련 과정은 모델을 업데이트 하거나 문제 등이 발생해 대대적인 변화를 줬을 때 다시 시작해야 한다. 이 때 모델만 처음으로 되돌리는 게 아니라 데이터를 수집하는 것부터 다시 시작해야 할 때가 많다. 전통적인 소스코드 제어 체제 아래에서는 매우 힘들어지는 부분이다.
모델을 충분히 훈련시켰다면 어떤 문제를 주고, 그 결과를 실제 값(확인용 데이터)과 비교한다. 정확도를 파악하기 위함이다. 충분히 만족할 만한 성과가 나왔다면 이 모델은 애플리케이션과 합쳐져 인프라를 통해 배포되기 시작한다. 모델의 유형에 따라 인프라 환경이나 배포 시스템을 달리 해야 한다.
머신 러닝 소프트웨어의 또 다른 특징이라고 하면, 전통의 소프트웨어들보다 훨씬 섬세하고 민감하며, 부서지기 쉽다는 것이다. 머신 러닝 알고리즘은 비결정적인 특성을 가지고 있어, 주입되는 데이터의 유형이나 질에 그 성능이 크게 좌지우지 된다. 데이터가 온전치 않으면 머신 러닝 알고리즘은 부정확한 결과를 만들어낼 것이며, 다른 모델에 의해 교체가 불가피해진다.
또 기존 소프트웨어보다 머신 러닝 소프트웨어가 ‘부서지기 쉬운’ 이유는 모든 과정이 밀접하게 연결되어 있기 때문이다. 즉 일부 요소에만 작은 변화를 가한다는 게 불가능하다. 하나의 변화는 통째 변화를 의미한다.
그래서 많은 엔지니어링 팀들이 현존하는 오픈 소스 툴들을 가지고 이리 저리 조합해 자신만의 머신 러닝 운영 환경을 만들기 시작했다. 이 때 사용되는 툴들이 아까 말한 주피터를 포함해 에어플로우(AirFlow), 도커(Docker), 큐버네티스(Kubernetes) 등이다. 그러나 이러한 환경을 조성하는 것은 비용이 지나치게 높을 수 있어, 모든 조직들이 다 시험해볼 만한 건 아니다. 그래서 대체품들이 생겨나기 시작했는데, 그 중 대표적인 것들은 다음과 같다.
1) 아마존 세이지메이커(Amazon SageMaker) : 개발자들이 머신 러닝 모델들을 쉽게 만들고 훈련시키고 구축할 수 있도록 해주는 플랫폼이다.
2) 야트 사이언스옵스(Yhat ScienceOps) : 종단간 플랫폼으로 머신 러닝 API를 실시간으로 개발, 구축, 관리할 수 있도록 해준다.
3) 파키덤(Pachyderm) : 머신 러닝 파이프라인의 개발에 있어 모든 단계들을 자동화시켜주는 환경이다.
이 세 가지 제품들은 머신 러닝 알고리즘의 개발과 구축 과정을 크게 간소화시켜준다. 하지만 무조건 써보기 전에 다음과 같은 질문을 해보는 것이 좋다. “우리에게 정말 필요한가? 회사 내에 도입한다고 하면, 사용이 가능한가? 자동화 소프트웨어 툴을 지금의 개발 공정이나 업무 과정에 도입하는 게 가능한가?
또한 위 세 가지 제품들은 아직 검증을 충분히 거치지 못한 ‘새 것’들이다. 모든 새 제품들이 그렇듯 안정성이나 퍼포먼스와 같은 측면에서 조금 더 확인할 부분들이 존재한다. 그러므로 시험에 시험을 거치고 확신이 선 후에 도입을 실행하는 것을 추천한다. 요즘 머신 러닝 알고리즘은 굉장히 인기가 많은 분야이기 때문에 비슷한 성능의 오픈소스를 구하는 게 그리 어렵지 않다. 가능하다면 무료 버전을 구해 최대한 실제와 비슷하게 실험하는 게 좋다.
확신이 선 후 위 제품들 중 하나 혹은 일부를 도입하기로 했다면, 그리고 충분한 실력을 갖춘 기술자가 있어 잘 활용할 수 있다면, 아마 생산 속도는 크게 향상될 것이다. 그러나 장점 뒤에는 반드시 단점이 따라온다. 새로운 공정과 절차가 도입된 때문에 다른 놓치는 것들이 있을 것이다. 초반엔 이런 부분에 늘 신경 쓰고 주의를 기울여야 한다.
글 : 모시 크랭크(Moshe Kranc), Ness Digital Engineering
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
