Machine Learning을 사용하는 International 프로젝트를 처음 경험하다보니 ML에 대한 관점이 많이 바뀌었다.
사실 프로젝트를 하면서 사내에서 쓰는 ML라이브러가 어떻게 돌아가는지 소스코드를 까볼 기회조차 없었고, 심지어 여러 세부 세팅을 조작해볼 기회도 역시 없었다. 그럼 뭘 했나???ㅋㅋㅋ
사실 위와 같이 ML 라이브러리를 살펴볼 필요가 없었다. 대강 어떻게 알고리즘이 돌아가는걸 알고, 이 라이브러리는 잘 돌아갈 것이라 믿으면 그만이다.
ML이 물론 프로젝트 내에서 중요한 부분이기는 하지만, ML은 데이터(features)를 가지고 헨들링 하는것이지.. 세부 알고리즘 세팅을 가지고 하는 작업은 아니기 때문이다.
이런 접근 방법은 블랙박스 모델처럼 보이는 ML을 가장 효과적으로 애플리케이션 내에서 쓸 수 있는 방법이라고 생각한다. 내 경험상 새로운 획기적인 ML 알고리즘을 만들지 않는 이상 알고리즘을 바꿈으로서 얻어지는 성능향상은 거의 없다. 더군다나 특정 알고리즘 설정을 바꾼다고 해서 절대 성능향상은 없다. 만일 있다면, 다른 부분에서 성능저하가 분명히 있을 것이다(공짜 점심은 없다…. ㅋ ). 물론 애플리케이션의 목적에 따라 최적 알고리즘이 있을 수 있긴 하지만, 역시 큰 성능상의 차이는 없다.
사실 ML보다 내가 더 신경을 많이 썼던 부분은 ….. 애플리케이션 개발 능력이였다. 말하자면 코딩, 더 크게 보자면… 알고리즘, 클래스 설계 이런 부분이였다.
요런 규모 정도의 라이브러리 개발 프로젝트를 진행해본 경험이 전무한 관계로… 위 능력들을 빠르게 키우는데 내가 가장 많은 시간을 투자했던 부분이였다. 이 다음으로 많은 시간을 투자한 곳은, 데이터 분석 정도.. 침착하고 냉정을 잃지 않는 …분석…그런거..
Machine Learning이라는 단어가 소프트웨어 개발의 매직 워드로 쓰이는 실정이라는 사실은 부정하기 힘들다. 나역시 그렇게 느껴왔으니까, 하지만, 소프트웨어 개발 전체에서 ML은 그리 단어만큼 매직을 부리는 부분은 아닌듯 싶다. 차라리… 정확하고, 이해하기 편하고, 퍼포먼스 좋게 알고리즘을 설계하거나 코드를 짜는 능력이… 가장 먼저 선행되어야 된다고 생각한다.
나 역시, 내 생각을 코드화 시키는데 큰 문제 없는 개발자 였지만, 프로젝트 수준에 맞게 코드를 작성하는 능력은 부족했었던게 분명했다. 그래서 많은 반성이 필요했다. (프로젝트 수준의 의미는 함께 개발하는 개발자들의 수준과 거의 비슷한 것을 의미한다. 함께 개발 하려면, 당장 능력은 되지 않더라도, 금방 따라갈 수 있는 자질은 갖추어야 할 것이다.)
누군가, ML을 가미한 프로젝트를 한다면, 한번 묻고 싶다. 과연 당신은 비슷한 개발 프로젝트를 충분히 견딜 수 있는 개발자 내공이 있느냐고 말이다.
결국 하고 싶은 말은…
Machine Learning을 주구장창 외치기 전에 개발자로서 프로젝트에 필요한 기반 기술들에 익숙한지 먼저 자문을 해야 할 거란 이야기다(깊은 개발 언어에 대한 이해, 그리고 아키텍처, 디버깅 능력…등등).
이런 프로젝트 개발에 진정 자신이 있을때 적제 적소에 가볍게 Machine Learning 개념을 집어 넣어 주는 센스는 당신이 만드는 애플리케이션을 좀더 빛이 나게 할 수 있을거라 생각한다.
항상 뜨거운 감자님의 글을 잘 읽고 있는데 이번 글은 좀….
예전에 뜨거운 감자님이 포스트 한 글 중에서 코딩한 부분을 보고 신경써야 할 부분이 있다고 의견을 말씀드리니 뜨거운 감자님께서는 알고리즘을 중점적으로 봐 달라고 했는데 이번 글에서는 다시 개발을 잘해야 한다고..쩝..생각이 변할 수도 있지만. 포스트에서 ‘당신’이라 말은 좀..
http://freesearch.pe.kr/1243
아 이번 포스트가 너무 공격적이였다는 생각이 좀 들기는 하네요. 이 부분 양해 부탁드립니다.
음… 전에 포스팅 주소까지 적어주셨는데… 그 부분은 저도 덧글을 보고 책을 살펴보며 찾아본 내용으로 답변을 달아 드린겁니다. 그리고 최신 컴파일러에서는 최적화 작업을 하기 때문에 문제가 없는 코드라 판단했습니다. 물론 방어적인 코딩 방식이 필요한건 사실이지만, 그렇다고 예제 코드 성격의 것을 고칠 필요성은 느끼지 않았구요. 사실 그 부분 코드를 안으로 넣는게 코드를 이해하는데 더 큰 도움이 되기도 하구요….
결국 실제로 수백번 돌려본 결과… 메모리 릭은 없었습니다.
그정도면 충분히 나그네 님의 덧글에 대해서 확인 해봤다고 생각합니다. 나그네 님의 소중한 덧글에 대해서 그냥 지나친게 아님을 알주셨으면 하네요…
그리고 이번 포스팅, 충분한 개발 경험이 없는 사람들에 대한 충고라기 보다는, 저 자신에 대한 충고의 성격이 강한 글입니다. 아마 곳곳에 있는 저의 부족한 부분들에 대한 반성의 부분이 많이 있음을 알 수 있을 거라 생각합니다. 자칫 공격적일 수 있는 그런 제목과 내용의 글이지만, 나름대로 저의 솔직함과 소신, 그리고 경험에서 묻어나온 소중한 글이라는 것을 알아주셨으면 합니다.
이거 아니니 저거다 라고 그렇게 말씀 해주시기 보다는 ‘어느 한명의 개발자가 여러 시행착오와 배움을 통해서 성장해 나가는 구나’ 하는 그런 맥락의 블로그 글들로 봐주셨으면 합니다.
감사합니다. ^^
사실, 제목이 너무 과격해서 딴지 한번 부려 보았습니다. 항상 좋은 글 잘 읽고 있습니다.
오셔서 이렇게 다시 덧글을 작성해 주셔서 감사합니다. ^^
소중한 덧글..항상 너무 감사드립니다.
동의하기 힘든 부분이 있는데 ML의 파라미터 설정 값에 대한 성능 비교를 체계적으로 해보지 않으신 듯 합니다. 어떻게 하든 성능의 변화가 없다 혹은 다른 곳에서 성능 저하가 일어날 것이다 하는 것은 문제의 특성을 배제한채 일반화 할 때의 이야기라 생각됩니다. 특정 어플리케이션을 작성하실 때 애플리케이션이 요구하는 조건과 알고리즘의 이론적 최적 설정을 고려하지 않으신다면 Trade-Off 가 아닌 그냥 낭비가 분명 발생할 수 밖에 없지요~
제가 ML을 이용해 실제 서비스 애플리케이션을 만들면서 쓴 글이여서 최대한 경험 위주로 쓴 포스팅이라 말씀대로 무리한 일반화를 한 측면이 있습니다.
ML을 한다면 반드시 해결하고자 하는 문제의 특성과 알고리즘 특징을 다 알고 시작해야 하는게 맞구요(물론 파라메터 튜닝도 그 일종의 하나지요). 그리고 저의 경험에 빗대해서 가장 빠른 성능향상은 정확한 ML input, output 재확인, 새로운 killer feature 발견이 더 빠른 길이라고 경험한 내용을 적은 것입니다. 이 부분에서 상대적으로 너무 무리한 일반화를 한게 사실이네요. ㅋ
연구가 아니라 실제 서비스를 해야 하는 ML 애플리케이션을 만들다 보니 이런 글을 쓰게 되었다는 점 염두에 두시면 감사하겠습니다.