빅데이터와 텍스트마이닝

빅데이터와 테스트 마이닝에 대해서 조금 적으려고 합니다.

빅데이터(Big data)

빅데이터(Big data)는 이제는 설명을 안해도 될 만큼 자료가 많습니다.
구글링을 해서 찾아보시면 되겠지만 너무 많아서 오히려 정리가 안되서 맥락을 이해하기가 어려울 수도 있습니다.

빅데이터는 간단하게 말하면 많은 데이터, 다양한 데이터를 저장, 가공, 처리, 분석하는 것을 통칭해서 말하는 것입니다. 어차피 명확하게 정의하기 어렵고 원래 정의를 만들고 시작한 것도 아닙니다.

사실 이미 빅데이터 리딩그룹쪽에서는 데이터와 관련된 IT기술이나 분석기법은 그 경계나 정의를 명확하게 정하지 않은지가 오래 되었습니다.

텍스트 마이닝 (Text Mining)

텍스트 마이닝은 사람이 써놓은 글을 분석해서 뭔가 쓸만한 것을 뽑는 것입니다.

텍스트 데이터는 특성상 많이 모아야 뭔가 쓸만한 것이 나옵니다. 텍스트 마이닝이 빅데이터에서 언급되고 마치 전부인것 처럼 얘기되기도 하는 이유는 원래 빅데이터의 출발이 IR(Information Retrieval)이 전문인 구글, 야후, 페이스북, 아마존, 넷플릭스등의 온라인 회사에서 시작되었기 때문입니다.  즉 빅데이터 관련 기술을 텍스트 처리에 많이 사용했기 때문입니다.

검색 포털이나 온라인 리테일 회사를 상상하시면 됩니다. 구글, 아마존이 대표적입니다.

이미 아시겠지만 현존하는 텍스트 마이닝의 최강자는 구글입니다. 그리고 그 외의 여러 회사들이 있습니다.

이 회사들의 공통점은 다음과 같습니다.

  1. 온라인 회사이고 많은 접속자가 만들어 낸 로그를 쌓아서 보유하고 있는 데이터가 매우 많다
  2. 대용량 정보처리기술이 회사의 핵심기술이다
  3. 사용자들이 웹사이트에서 행동하는 것을 로그에 쌓아놓고 그것을 다시 가공해서 회사의 서비스를 개선하거나 다른 부가가치를 만들어 낸다

빅데이터와 텍스트마이닝이 혼동되는 이유 중 또 하나는 텍스트데이터는 처리하는데 컴퓨팅 자원이 많이 소모된다는 점도 있습니다.

어찌되었든 텍스트 마이닝을 잘 하려면 필수는 아니지만 빅데이터 기반 기술이 있는 것이 매우 유리하며 그런 경험이 있다면 그렇게 될 수 밖에 없다고 보는 것이 업계 기술자들의 정론입니다.

그렇다고해서 빅데이터를 텍스트 마이닝에만 쓴다는 얘기는 아닙니다. 다시 텍스트 마이닝으로 돌아오면 텍스트 마이닝은 텍스트 데이터를 분석해서 의미, 의도, 경향등을 보는 것을 기본으로 하고 그런 결과물을 다른 데이터와 연동해서 분석하거나 결합해서 부가정보로 쓰게 됩니다. 그 이상을 하려면 텍스트 마이닝 결과물 자체가 비즈니스 모델이 되거나 회사의 이윤을 창출하는 뭔가를 만들어 주어야 하는데 그런것이 많지 않습니다.

텍스트 마이닝이 그 자체로 비즈니스 모델이 되는 것은 기계 번역이나 문서 자동 요약 등과 같은 것이 있습니다.

텍스트 마이닝의 문제점

텍스트 마이닝의 문제점은 상당히 자연어(사람이 쓰는 말, 한국어, 일본어, 독일어, 영어, …)에 영향을 많이 받으며 분석결과물 자체를 그대로 비즈니스 모델에 적용해서 뭔가를 만들어내서 성과를 보기 어렵다는데 있습니다. 자연어처리쪽 분야에 있어서 문제가 있는 분야가 한글 및 한국어의 경우 광학문자판독(OCR, Optical Character Recognition), 음성인식(Speech Recognition), 그리고 감성분석 (Sentimental Analysis)등이 있습니다. 기술적으로 문제라기 보다는 언어를 다루는 문제가 결과물을 보고 품질을 사람들이 쉽게 판단하기 때문입니다.

텍스트 마이닝이 어려운 이유

텍스트 마이닝의 전부가 워크 클라우드가 아니며 데이터를 수집해서 텍스트 마이닝 툴을 사용해서 마우스 클릭을 하면 분석결과가 나오는 것이 아닙니다. 영어권 경우에는 기술적인 진척이 많고 영어의 특성이 분석이 더 쉽다는 것이 없지 않아 잘 되는 것도 있지만 한글 및 한국어에서는 아직은 어렵습니다. 특히 텍스트 마이닝은 자연어처리 도구에 의존성을 매우 큰데, 자연어처리 도구가 그냥 사서 쓰는 소프트웨어가 아니라 사람의 정성스런 손길이 지속적으로 필요한 애물단지입니다. 자체로도 관리가 필요하며 관리가 안되면 쓸모가 없어지는 경우가 많으데다가 관리가 안된 자연어처리 도구를 이용해서 만든 2차 파생물도 함께 엉망이 됩니다.

때문에 사내(in-house)에서 지속적으로 투자하거나 하지 않으면 결과를 보기 어렵고, 당연히 단기 프로젝트에 의한 좋은 결과물은 나오기 어렵습니다. 참고로 자연어 처리 도구는 형태소 분석기, 구문 분석기등과 같은 자연어를 처리하는데 필요한 소프트웨어 라이브러리들입니다. 이것들도 자연어의 특성을 많이 타는 것으로 각 언어별로 다 품질이 다르고 기분석 사전이나 후처리 사전등을 따로 관리해야하는 복잡한 문제가 있습니다.

텍스트 마이닝과 워드 클라우드(Word Cloud)

TV에서 자주 볼 수 있는 화면이 단어들이 둥둥 떠 있고 단어끼리 선을 연결한 시각화 화면이 많은 것입니다. 워드 클라우드라는 시각화 방법입니다.

사실상 텍스트 마이닝의 결과물의 시각화는 워드 클라우드나 워드 클라우드를 변형한 시각화 기법외에는 아직 없습니다

경험이 없는 분들은 어렵게 생각하실지도 모르겠지만 사실 워드 클라우드는 구현하기가 매우 쉽흡니다. 심지어 그냥 오픈 소스 몇개를 붙여서 돌리면 그럴 듯한 것을 만들어서 보여줄 수 있습니다.
문제는 이런것들 돌려서 흥미 위주의 어필 포인트는 되겠지만 결과물이 실제로 도움이 되는 것이 많지 않다는 것이고 그것 때문에 대부분의 일반 기업에서는 빅데이터를 텍스트 마이닝이라고 생각하고 프로젝트를 진행한 뒤에 결과물이 도움이 안되니 빅데이터가 별거 아니고 해봤는데 아니더라고 말하게 된다는 것입니다.

가장 흔히 볼 수 있는 반응입니다

이것은 잘못 접한 정보와 유도된 상황 때문에 발생하는 착각입니다. 빅데이터와 텍스트 마이닝을 구분하지 못하며 제대로 이해하지 못하기 때문입니다.  경험을 해보지 않으면 제대로 구분하기 어려운 것도 사실입니다만 공부가 부족하기 그것을 모른다고 해서 틀린 것을 말하고 그것이 마치 정설인듯 말하는 것은 정당하지 않습니다. 텍스트 마이닝은 쉽지 않습니다. 그리고 텍스트마이닝이 빅데이터와 동치관계는 아닙니다.

데이터 사이언티스트가 사용하는 도구

저는 기업체를 상대로 솔루션 사업을 하고 있는 회사에서 데이터 사이언티스트로 일하고 있습니다. 대외 미팅 중에 아이스브레이킹(ice breaking)을 하면서 가장 많이 받는 질문이 아래 두가지입니다.

  • 데이터 사이언티스(Data Scientist)가 뭐하는 사람인가요?
  • 데이터 사이언티스(Data Scientist)는 무슨 툴(Tool)을 사용하나요?

첫번째에 대답은 검색을 해보면 여기저기 다 있습니다.

대부분 명확하게 정의는 하지만 그 정보들을 취합해 보시면 서로 다르게 정의하고 있는 영역이 보일 것입니다. 그 정의로는 혼동스럽죠. 쉽게 정의하면

  • 광의적으로 보면 데이터 관련된 일은 뭐든 다 해주는 사람. 비즈니스에서 부터 구현 및 서비스까지

    이쯤되면 수퍼맨입니다

  • 협의적으로 보면 공학기술을 이용해서 데이터 분석을 하고 구현체까지 만들어 주는 사람

    데이터마이닝과 프로그래밍을 같이 하는 사람입니다. 좀더 구체적으로는 개발자와 데이터 분석가의 중간쯤 어디입니다. 예전에는 데이터 엔지니어(Data Engineer) 또는 그냥 엔지니어(Engineer)라고 불렀습니다.

두번째 대답의 답은 뭘까요?

데이터 사이언티스트가 빅데이터를 하는 사람으로 가장 잘 알려져 있어서 보통은 빅데이터와 관련된 것을 뭉뚱그려서 같이 물어봅니다.
엔터프라이즈를 대상으로 제품이든 용역이든 팔아먹는 기업에서 몸담고 있는 사람이라면 이쪽의 대답은 당연히 자신의 소속한 회사의 솔루션과 관련된 답을 하기 마련입니다.

영업하는 사람이 아닐지라도 그럴 수 밖에 없습니다.

여러가지 솔루션을 많이 보유하고 있는 회사라면 이것저것 적절한 조합을 합쳐서 말하게 되고 솔루션이 적은 회사라면 특정 솔루션에 대해 말하고 응용할 수 있는 가능성을 얘기하게 됩니다. 제 경우에도 여기에서 자유롭지 않으며 회사의 솔루션이 R인 까닭으로 R이라고 말합니다. 하지만 제가 근무하는 회사와 상관없이 제 경우를 떠나서 언급되었거나 경쟁하면서 다른 사람들이 말하는 것들을 닥치는 대로 나열해 보겠습니다.

플랫폼으로 가장 많이 언급되는 것이 Hadoop ecosystem쪽 입니다.

  • 배치 프로세싱: Hadoop, Hive, Pig, Impala, …
  • 리얼타임: Storm, Spark, …

더 있는데 생각이 안나네요.

시각화쪽으로는 Spotfire, Tableau, CliqView 등이 있습니다.

구현을 해서 웹기반 툴을 만들어 주기도 합니다.

BI 쪽

  • Micro-strategy, Business Object(SAP 솔루션)같은 BI툴
  • Birt나 Jasper같은 리포팅툴

DW 쪽

  • Teradata, Oracle 솔루션들, SAP 솔루션들, EMC 솔루션을

이제 마지막으로 분석툴인데 질문자들이 데이터 사이언티스트는 뭘 쓰나요 할 때 예상대답으로 원하는 것이 주로 이쪽입니다.

R, SAS, SPSS 등이 있습니다.

SAS직원이거나 파트너사소속이면 아마 SAS 솔루션들을 말할 것이고 IBM쪽이라면 SPSS와 기타 IBM솔루션을 말할 것이고, 그것도 아니라면 R을 얘기합니다.

이것들의 범주는 사실 데이터마이닝 툴이라고 볼 수 있습니다.

이쯤되면 그냥 통합 ISP 인프라 솔루션들을 다 나온다고 보면됩니다. 이 상황은 빅데이터와 데이터 사이언티스와 데이터분석과 기존 데이터관련 솔루션들이 빅데이터 트렌드에 합류하면서 잡탕찌게가 되었기 때문입니다.

데이터 사이언티스트는 사용하는 툴이 정해져 있지 않습니다. 자세히 생각해 보면 아시겠지만 그럴것이면 데이터 사이언티스트가 별로 필요 없습니다. 데이터 사이언티스트가 닥치는대로 다 사용한다고는 하지만 사실 각자 주력으로 사용하는 것은 있습니다. 경향을 볼 때 주로 선정대상은 일반적이며 가격이 높지 않은 것을 선택합니다.

오픈 되어 있는 것이 필요하니 오픈 소스를 쓰고 오픈 소스는 자체로는 가격이 없으니 결국 오픈 소스를 선호하게 됩니다.

특정 회사에서 내근만 한다면 특정 툴로만 하는 것도 무리는 없습니다

물론 가격이 비싸고 훈련이 되어 있거나 훈련을 받아야 합니다.

국외의 상황이구요. 국내는 아직 혼란 상태입니다.

외국의 상황을 보죠.
검색을 해서 외국 사이트의 게재물을 읽어보시면 주로 언급되는 데이터 사이언티스트가 가장 많이 쓰는 도구는
R, Python, Java가 나옵니다.

SQL은 거의 기본입니다. 무조건 합니다. 제 경험으로는 실제로도 그렇습니다.

주로 현재는 Python이 가장 많고 그 다음이 R 그리고 Java입니다.

Python과 Java가 많은 이유는 데이터사이언티스트 중에서 공학에서 시작해서 커리어를 확장했기 때문입니다. 공학에서 넘어온 사람은 Python, Java가 많고
통계에서 넘어온 사람은 R이 많습니다.
비즈니스나 경제학에서 넘어온 사람은 여전히 SAS와 Excel을 씁니다.

SAS, Excel빼고 이것들의 공통점은 컴퓨터 랭귀지라는 것입니다.

SAS도 자체 랭귀지가 있습니다만 그냥 분류상으로 빼겠습니다. 많이 애매해졌습니다.

해석해 보면

  1. 첫번째 항상 구현만 하는 것은 아니겠지만 뭔가 구현을 하는 경우가 빈번하기 때문이라는 것을 알 수 있습니다. (주력으로 사용하는 도구이므로…)
  2. 두번째 가능한 특정 솔루션에 의존성을 가지지 않아야 하며 솔루션이나 툴이 중요한 것이 아니다라는 것을 알 수 있습니다. 현재는 가장 각광받는 것이 R과 Python 그리고 빅데이터 솔루션입니다.

하지만 데이터 사이언티스트가 사용하는 도구가 뭐냐를 보기 보다는
데이터 사이언티스트라는 사람 그 자체가 도구라는 사실이 숨겨져 있는 것이 함정입니다.

코호트 분석 (Cohort Analysis)

코호트 분석

동질의 세그먼트 중에서 유사한 경험을 한 그룹을 코호트(Cohort)라고 합니다. 흔히 동일한 사회적 경험을 한 그룹이라고 말하기도하는데 동일한 시기에 온라인 매장에 최초 또는다시 접속한 고객 군을 말하기도 합니다.

동일한 시기인 이유는 동일한 시기에 온 사람이면 온라인 사이트에서 진행하는 프로모션 이벤트들 중에서 동일한 것을 보고 왔을 가능성이 크기 때문입니다.  20% 할인행사라든가 1년 동안 10% 할인은 해준다거나 특정 상품을 반값에 해준다거나 하는 행사들입니다.

이렇게 특정 프로모션을 사회적 경험으로 볼 수 있고 각각의 프로모션 이벤트를 통해서 들어온 그룹들은 각각의 특성을 가질 가능성이 큽니다. 사이트에 계속해서 방문한다거나 처음만 접속해서 가입하고 물건을 구매한 뒤에 그 뒤로는 오지 않는다거나 하는 것입니다.

그런 그룹들의 행태를 지켜보다가 향후에 이벤트를 할 때 효과가 좋은 이벤트를 다시  한다거나 이탈률이 높은 그룹에 프로모션을 다시 한다거나 해서 재방문 고객들을 계속 유지해서 비즈니스의 매출을 유지하는 방식으로 이용합니다.

조금 어렵게 말하면 코호트 분석은 서비스 또는 어떤 비지니스에서 중요한 볼륨(양적) 지표의 수치가 증가함에도 불구하고 리키버킷(고객이 새는것)을 관리하지 못해 주 수익이 증가하지 않는 것에 대한 이유등을 분석하기 위한 방법으로 잘 알려져 있습니다.
물론 그 외에도 여러가지를 볼 수 있습니다. 마켓분석에서 쉽게 볼 수 있는 분석 방법이며 특히 고객이탈방지 분석(Churn Analysis)에 사용할 수 있는 분석 방법 중에서 가장 잘 알려진 것 입니다.

코호트 분석 도표화 및 시각화

코호트 분석은 주로 스프레드시트(spread sheet) 표와 다층 케이크 차트를 이용합니다.

Image

엑셀로 하는 코호트 분석입니다.
데이터는 연습용 데이터입니다.
보는 방법은 위에서 아래로 왼쪽에서 오른쪽으로 보는 것이고 진행월별 유지 고객과 유지 비율등을 봅니다.
이외에도 월간지속매출?을 보는 표와 이탈 고객등에 표도 그려주는 것이 좋습니다.
각 표별 시각화는 엑셀로 그려도 되지만 R로 작성된 시각화가 보기 좋으므로 R로 그리는 것이 좋습니다.

Image

R로 시각화한 다층 케이크 (Layer-Cake) 차트입니다.
데이터는 위 엑셀장표의 데이터와는 다른 것을 플로팅한 것으로 단순한 시뮬레이션 데이터입니다.
차트의 꼭대기 부분은 전체 고객들의 수가 됩니다.
각 계층(색으로 구분된 층)은 진입한 월별 고객들의 숫자입니다.
진입하고 첫달에 이탈하는 경우가 많은 것을 알 수 있습니다.
ARPU와 MRR 그리고 고객유치비용등을 같이 봐야 하겠지만 일단 첫달 이탈률이 매우 높아 만약 비즈니스에 문제가 좀 있다는 것을 알 수 있습니다.

코호트 분석에서 볼 수 있는 것들

리키버킷은 사용자 또는 고객이 일정 수가 지속적으로 이탈하는 상태를 말하는 신조어인데, 결국 신규 고객의 유입이 고객의 이탈을 따라잡지 못하거나 각종 리텐션 방법으로 빠져나가는 사용자를 방어하지 못하면 장기적으로 비즈니스를 안정화할 수 없거나 망하게 됩니다.

리키버킷은 물이 새는 양동이라는 뜻입니다

고객유실(고객 이탈)을 완벽하게 막을 수는 없겠지만 최대한 잘 방어하지 못하면 매출이 늘어나도 장기적인 수익률이 증가하지 않는다거나 마케팅 비용을 허비한다거나 하는 문제가 발생하는데 코호트 분석에는 이 부분을 중점적으로 밝히려고 하는 것입니다.  고객유실을 더 이상 줄이지 못한다고 판단되면 고객유치비용을 조절하거나 해야 합니다.
이외에도 코호트 분석을 하는 주된 이유는 고객의 반응은 서비스나 상품이나 서비스에 대해 라이프타임(수명)을 가지고 있는데, 어떤 비즈니스이던 고객의 비즈니스에 대한 라이프사이클을 길게 유지하고 이탈하지 못하도록 방어하는데 필요한 정보를 얻는데 있습니다.
그리고, 신규 고객을 유입시키는 것 보다는 기존 고객의 이탈방지를 하는 것이 비용소모가 더 적고 효율적인 것으로 알려져 있습니다.

고객 유지를 위해서는 현재의 비즈니스가 다음 4가지 중 어느 상황인지 판별을 해야합니다. (이외도 봐야 하는 것들이 상당히 많습니다만 마켓분석이 전문이 아니라서 저도 공부가 굉장히 필요할 것 같습니다)

  1. 매출이 새로운 인입 고객로부터만 발생한다. (제로섬에 가까운 망조)
  2. 매출이 한 사람당 한 번 만 이루어지고 더 이상 발생하지 않는다. (얼리 어댑터 문제로 빨리 망할 징조)
  3. 매출이 기존 고객으로부터만 발생한다. (더 이상 신규고객이 없어 서서히 망해가는 징조)
  4. 매출이 새 인입고객과 기존 고객으로부터 발생한다. (좋은 징조)

여기서 매출은 온라인 서비스라면 페이지뷰(page view)로 생각하면 됩니다. 게임이라면 처음 가입해서 하던 고객이 얼마만에 게임을 그만 두는지가 되겠습니다.
최근 IT기반 스타트업의 마케팅 분석에서 코호트 분석이 많이 쓰입니다. 비즈니스 형태가 코호트 분석을 하기에 잘 맞아 떨어져서 그런것도 같습니다.

위의 상황중 어느 상황에 해당하는지를 확인하기에 가장 좋은 것 중 하나가 코호트 분석이라고 알려져 있습니다.
최근 온라인 서비스들은 깔때기 분석(Funnel Analysis), 코호트 분석 (Cohort Analysis), 대조군 테스트 (A/B test, 버킷 테스트라고도 합니다)에 대해서 잘 알아야 한다고 말합니다.
이중에서 제가 생각할 때 가장 중요한 것은 버킷테스트(A/B test) 입니다. (이것은 예전 블로그에서도 설명한 적이 있습니다만)
기술적으로는 코호트 분석은 집단을 테스트나 비즈니스로의 진입 시작 시점으로 구분해서 통계지표를 나누어 확인하는 것으로 복잡한 알고리즘이 사용되는 것은 아닙니다.

물론 원천데이터의 형태에 따라 집계는 다소 컴퓨터 연산자원이 필요하거나 복잡할 수 있습니다.

구체적으로 예를 들어 설명하면 월별로 가입한 사람들을 따로 분류(segmentation)해서 월별 흐름에 따른 주요 지표의 추이를 보는 것입니다. 이렇게 나누는 것이 유용한 이유는 시대를 함께 겪은 그룹끼리는 사회적으로 공감대나 어떤 특성등을 가지게 되고 그것들이 고객행위의 라이프사이클에 각각 다르게 영향을 끼친하는 것입니다. 즉 월별로 진입한 사람들은 뭔가의 영향에 동질감을 가지게 되어 있어서 그게 뭔지 알아야 한다는 것입니다. 그리고 좀더 자세히 분석하기 위해서 데이터를 드릴다운(drill down)해서 특별히 더 세분화된 그룹을 본다거나 개별 고객을 확인해 본다거나 하는 것도 추가로 해 볼 수 있습니다.

 

R과 SAS 비교

이 포스트를 올린 이유가 일을 하다보면 초등학생 질문처럼 “호랑이랑 사자가 싸우면 누가이겨요?” 라고 물어보는 분들이 많기 때문입니다.

비교라기보다는 외국의 커뮤니티들에서 몇 년 동안 지속적으로 논쟁중인 내용의 댓글과 반박글을 중요한 것만 뽑아 정리한 것입니다.
중복되거나 비슷한 내용은 한꺼번에 몰아 넣었습니다.
이 논쟁은 어차피 결론이 안 날 것 같습니다만 쭉 한 번 읽어보면 R과 SAS 중 하나를 선택 하는데 도움이 될 것이라고 생각합니다.
밑에 요점 정리들 해 두었으므로 읽을 시간이 없으시면 그냥 요점으로 넘어가셔도 됩니다.
요점은 제 의견이 들어 있습니다. 어디까지나 제 의견입니다.

SAS가 낫다는 의견들 모음

  • R이 가지고 있는 메모리 사용 제약은 실제로 문제가 된다. 인메모리(in-memory) 기반인 R은 한 번에 다룰 수 있는 데이터셋(dataset)의 행과 열(rows와 column) 수의 제약을 가지고 있는데 (메모리의 제약으로 인해), 이 문제가 금방 해결될 것이라고는 보지 않는다

어차피 SAS도 인메모리(in-memory) 방식이기 때문에 SAS가 우위에 있다고 보기 힘들다는 반론이 있습니다. 다만 SAS가 보조도구를 지원하는 것이 있어서 어쨌든 사용성 관점에서는 더 낫다는 재반론적인 의견도 있습니다. R의 in-memory제약에 대한 해결 부분은 다른 의견에서 반박 의견이 더 있습니다. 물론 R로 인터페이싱만 하고 Hadoop에서 map/reduce같은 것으로 실행하면 해결되는 알고리즘도 있지만 상당히 많은 통계, 분석, 데이터마이닝 알고리즘들은 분산 컴퓨팅용으로 바꾸기가 어렵습니다. 추가로 R의 행과 열의 제한은 메모리가 충분함에도 불구하고 언어 자체에서 제한해 놓은 것 때문인데 지금은 그 제약이 없어 졌습니다.

  • 내가 보기에는 실제 대학에서는 R을 사용해서 강의를 많이 하거나 엑셀(Excel) 데이터를 SAS로 빨리 전환해서 분석하는 것을 가르치는 두 가지 타입이 많은 듯 하다. 많은 미국대학에서는 SAS를 무료로 사용할 수 있다. 하지만 대부부의 대학 교수들은 SAS보다는 R을 선호하는데 그 이유는 그 사람들이 R을 기본으로 학습 받았기 때문이다. SAS를 왜 안가르치는지 모르겠다.

젊은 교수들이 R밖에 쓰지 못하기 때문에 학생들에게도 R을 가르치고 그래서 시장에서 원하는 SAS 사용자가 최근에는 안 늘고 있다는 투덜거림입니다. 최근 추세를 보면 그런것도 같습니다. 제 생각에는 학교에서 굳이 비싼 상용툴로 학생들을 괴롭힐 이유가 없다고 봅니다.

  • SAS는 구인시장(Job Market)에서 아직도 가장 유용하고 뜨겁다 (hot). 지금까지 가장 많이 분석업무에 적용되어 왔으며 사례(case)가 많다. 하지만 R은 아직 성공사례(success story)가 많지 않다.

여기에 대해서는 R의 구인시장에서 리쿠르팅이 빠르게 증가하고 있다는 반박의견이 있습니다. 출처가 있었는데 놓쳐 버려서 찾을 수가 없군요. 어쨌든 아직은 SAS와 관련된 인력을 구인하는 곳이 많은 것으로 보입니다.  성공사례를 찾기는 어렵지만 실패사례도 없으며 미국 공공기관에서도 R을 도입해서 사용하고 있습니다.

  • 데이터 분석에서 80%가 지저분한 데이터(dirty data)를 깔끔한 데이터(clean data)로 바꾸는 등의 데이터 전처리(data manipulation) 작업 인데 R은 많은 데이터 전처리 기능을 제공하지 않으며 R과 SQL은 이런 일에 그리 유용하지 않다고 본다.

R의 강점이 data manipulation인데 왜 유용하지 않다고 하는 것이냐는 반박의견이 있습니다만 R의 문법이 SAS에 비해서 다소 어렵고 SAS쪽에서는 다른 GUI기반의 보조 제품들이 있기 때문에 한 말 같습니다. 데이터 분석 작업에서 시간이 소요 되는 작업의 80%는 데이터를 전처리하는 wrangling 또는 munging이라는 작업입니다. (제 생각도 그렇습니다) 이 부분을 어떻게든 빠르게 할 수 있으면 좋겠지만 많이 이 부분에 시간이 소요된다는 것에 대해서는 반론이 없습니다.이 부분은 숙련도의 차이라고 생각합니다. 또 SAS의 SQL 기능만 쓰는 사람도 많습니다.

  • 아카데미에서 SAS에 비해서 R을 많이 가르치지 않는 것은 구직 문제 때문이다. 많은 구직 오퍼가 여전히 SAS에 대한 것이기 때문이다.

이 얘기에 대해서 필드에서 오래된 숙련가 한 사람은 최근에 대학에서는 R을 베이스로 가르치는 곳이 훨씬 더 많다고 말합니다. 온라인상에서도 오픈된 여러 교재들을 보면 최근에는 R을 베이스로 가르치는 학교가 더 많아 보입니다. 말한 사람이 협소한 정보를 가지고 있는 것 같습니다.

위와 관련되어서 다른 얘기로 유럽의 많은 학교에서는 R을 베이스로 가르치기 때문에 오히려 이들에게 SAS를 훈련시키는 비용이 꽤 소모된다는 반론이 있습니다.

참고자료: http://bigcomputing.blogspot.com/2011/07/figuring-out-number-of-r-users-in.html
다만 R과 SAS를 단순 비교하기 어려운 것은 SAS는 R이 지원하지 않는 많은 것들을 지원한다는데 있다는 것(사용성이 좋은 기능들과 기타 여러가지 부수 제품들이야기입니다. 비용은 별개이구요) 이고 R은 통계 및 분석의 좋은 기초 환경이라는 차이가 있다고 말하고도 있습니다.

다시 위에 대한 반론으로 과연 SAS는 가지고 있지만 R은 가지고 있지 않은 기능이 뭔지에 대한 나열이 필요하다는 의문제기가 있습니다. 기능적인 이야기인지 제공하는 알고리즘의 이야기인지에 대한 것을 포함해서입니다. 모호하고 개인적으로 기준이 다를 수 있어 왜곡의 여지가 있습니다만 SAS가 역시 사용하기 편리하다는 의견은 많은 것 같습니다. 일단 GUI방식의 JMP(SAS사에서 판매하는 GUI기반 분석툴) 얘기가 많이 나옵니다. R은 좋은 GUI frontend가 별로 없습니다.  R의원형이 splus라는 아주 오래된 랭귀지이고 그 당시에는 그걸 생각할 겨를이 없었기 때문입니다. GUI가 필요하다면 R은 유리하지 않습니다.

  • SAS의 문제는 비용이 든다는 문제가 있고 R의 문제는 케이스에 따라 문제 해결의 난이도가 다르다는 문제가 있다. R은 문제해결을 위해서 많은 패키지들 설치해야 하고 때로는 패키지를 직접 고쳐야 한다. 특히 SAS로는 간단히 해결할 수 있는 몇가지 것들도 R로는 복잡하게 해야 한다. 적어도 잘 알려진 문제 해결과 처리 속도의 관점에서는 SAS가 낫다. SAS는 사용자친화적(user friendly)하지만 R은 아니다.

익숙함의 차이가 있을 수도 있겠습니다만 아주 틀린 말은 아니라고 생각합니다. R은 진입장벽이 조금 높습니다.  그리고 문제가 발생해도 징징거릴 수 있는 대상이 없습니다.

  • R의 패키지가 5300개가 넘는데 개인개발자(contrbutor)들이 만든 것들이라 대부분 테스트가 충분히 된것이 아니고 지원도 결국 만든 사람이 해야 해서 위험하다는 의견입니다.

반대 의견으로 SAS에서는 그럼 개인 개발자들이 알고리즘이나 패키지들을 만들어서 필요한 것들을 공급할 수 있는가를 묻는 것들이 있습니다. 필요한 것이 있는데 SAS에 없으면 못쓴다는 얘기가 되는데 그럼 어떻게 할 것인가? 라는 말입니다. 그리고 모든 R패키지들이 같은 상태로 관리가 안되거나 하지 않고 패키지들의 중요에 따라 잘 되는 것도 있고 아닌 것도 있다는 의견입니다. 후에 이 의견에 대한 재반박의견으로 IML을 이용하면 만들수는 있다는 의견이 있습니다.
더불어 말씀드리면 R의 패키지들을 만드는 사람들 중에는 이름 모를 사람들도 많지만 유명한 통계학자들도 많습니다. 패키지의 품질이 떨어지고 버그가 있는 것은 패키지와 만드는 사람에 따라 달라지는 문제이지 R패키지가 모조리 다 그런것은 아닙니다.

  • SAS는 Marix연산에 있어서 다중쓰레드(multi-thread)를 지원하고 많이 테스트되어서 안정적이다.

이 말을 한 사람은 SAS 세일즈맨이 틀림없다고 비꼬며, R은 안될 것이라고 생각해서 말했겠지만 R에서도 당연히 된다는 반론이 있습니다. (네 당연히 됩니다)

  • 혹시라도 SAS가 지원을 끊는다면 지속되기 어렵다는 문제가 있지만 오픈소스는 그렇지 않다. Windows XP의 경우를 빗대어 보더라도 그렇다.

이 의견에 대해서 30년동안 이 계통에서 일을 해왔지만 Windows XP를 예로든 것은 맞지 않다고 보며, SAS와 R이 대체 뭐가 다른지 모르겠고 분석 시스템의 문제는 IT operater와의 커뮤니케이션 문제이고, 또 단지 테크니칼 문제일 뿐이다라고 일축하고 있습니다.
SAS가 좋고 R이 좋고하는 분석과 상관없는 얘기라는 것인데요. 구축과 소프트웨어의 유지도 회사의 자체 문제라서 관점에 따라서는 맞는 얘기이지만 도입하는 입장에서는 이 사람 얘기는 안 맞는 얘기라고 봅니다. R이 분석 시스템을 구축하는데 다소 유리하다는 말에 대해 다소 SAS를 옹호하는 입장의 말입니다. 제가 해석을 잘 못 했을 수도 있겠구요.

  • 원숭이는 SAS와 SPSS를 쓸 수 있지만 R을 사용하기 위해서는 전문가가 필요하다. 대부분의 회사들은 한 무리의 원숭이들이 전문가의 관리하에서 일하는 구조이므로 SAS와 SPSS같은 툴을 쓸 수 밖에 없다.

SAS쪽에 대해 안좋게 얘기하는 것 같아 보이지만 결국 SAS를 선택할 수 밖에 없는 중요한 이유 중에 하나라고 생각되서 이쪽으로 분류했습니다. 무슨 뜻인지는 아실 것이라고 생각합니다. 물론 저는 SAS를 사용하는 사람이 원숭이라고 말하고 싶지 않습니다. 그냥 R을 사용하지 않는 분석가들을 업신여기면서 징징거리고 있습니다만 결국 현실은 SAS를 써야 하는 경우가 많다는 말을 하고 있습니다.

R이 낫다는 의견들 모음

  • R은 가장 성공한 오픈소스프로젝트(open-source proejct) 중 하나이며 계속 발전해 나갈 것이라는 것은 자명하며 커뮤니티에 의해서 스탠다드로 계속 유지될 가능성이 높다.

주류가 될 것이긴 하지만 오픈소스가 대부분 그러하듯이 발전속도가 느려서 엔터프라이즈 시장의 요구에 빠르게 만족하지 못할 가능성이 크다는 반박 의견이 있습니다. 오픈 소스 프로젝트들 중에는 발전속도가 빠른 것도 있고 느린 것도 있습니다. 빨랐다가 중간에 느려진 것도 있구요. R은 이미 주류에 접어들었습니다. 오픈소스 중에 R을 대체할 만한 것이 현제는 python의 scipy 정도입니다마 상당한 차이가 있습니다.

  • 시장에서 통계분석을 매출액 증가의 목적으로 사용하거나 후에 회사 자체를 판매하기 위해서라면 R로 복잡한 시스템을 구축하는데 노력을 소비하기 보다는 잘 알려진 대중화된 툴을 선호하기 마련이다. 결국 SAS나 SAP등을 사용하게 되지 R이나 Excel with VBA로 복잡하게 구현된 것을 쓰려고 하지 않는다.

연구를 위한 기반기술로는 R을 유행이고 연구 목적의 기반으로 쓰겠지만 엔터프라이즈에서 분석 시스템을 구축할 때는 결국 SAS나 Matlab같은 것들을 쓰게 될 가능성이 여전히 크다는 의견입니다. 회사를 팔든 합병을 하든 매출액을 증가시키든 목적에 잘 부합하는 잘 알려진 것을 쓰라는 얘기입니다. 즉 협업이나 기존의 기득권 세력과 같이 작업을 하려면 SAS를 써야 한다는 말입니다.

하지만 R도 패키징을 통해서 구조화를 할 수 있기 때문에 큰 문제가 아니라는 반론이 있습니다. 회사의 비즈니스 유형에 따라 달라질 문제로 보여집니다.

  • R은 단순히 행렬처리를 위한 랭귀지라고 생각하지만 사실상 대부분의 데이터타입을 가지고 있는 full-set 랭귀지이고 속도 문제에 있어서는 rScaler같은 외부 패키지들을 사용할 수 있어서 해결할 수 있고 single thread에 대한 제한 문제도 동일한 방법으로 (패키지를 사용해서) 해결할 수 있다고 말합니다.

이 것은 R이 병렬처리가 안되고 속도가 느리다는 어떤 의견에 대한 반론입니다. 위에서 SAS 옹호론에 있는 얘기에 대한 반박글입니다.

  • SAS는 테스트가 잘 되어 있어서 버그가 없다는 말은 조크다. 실제로 이상한 코드를 SAS client에서 SAS server로 보내면 아무 메세지 없이 행이 걸리는데 6개월 동안 안고쳐지고 있다.

지금은 이 버그가 고쳐졌는지 모르겠지만 어느 소프트웨어나 버그는 있다는 얘기입니다. SAS가 버그가 없다고 주장하는 것은 완전 조크다라는 얘기입니다. SAS 손을 들어 주는 사람들이 버그가 적고 로버스트(robust)하다는 의견을 많이 제시한 것에 대한 반론입니다.

  • IBM에서 일하고 있는데 SPSS와 R, Python은 연동이 정말 잘 된다.
    > 묻어가기 스타일로 제품 홍보를 하고 있는 의견입니다. 이 내용과는 상관없지만 SPSS가 R연동을 선택한 것은 잘 한 일이라는 의견이 있습니다.

저도 그렇게 생각합니다.

  • R은 45000개의 펑션이 내장되어 있고 SAS는 15000개의 펑션이 내장되어 있는데 SAS는 지독하게 비싸면서도 너무 오만해서 도움도 잘 주지 않는다. 현재 학교에서 학생들은 R을 통해서 더 많은 지식들을 쌓아가고 있고 R 진영에도 상용 개발버전을 제공하는 회사가 있고 그런 회사들이 만든 R기반의 분석도구는 스케일러블(scalable)하고 로버스트(robust)하다.

결국 비싼 SAS를 써야할 이유가 별로 없다는 얘기로 보입니다.  하지만 R 상용화 도구도 아주 싸지는 않습니다.

SAS함수가 15000개라고 했는데 세어보니 1100개 정도라는 말이 있습니다. 하지만 분석외의 4GL기능이나 기타를 다 합치면 그 정도 된다는 군요. 하여튼 제공하는 기능에 비해서 너무 비싸다고 말하는 듯 합니다. (정말 비쌉니다)

반대 의견으로 나는 SAS에 있는 1000개로도 충분히 분석 잘 할 수 있고 지금까지 잘 살아왔다는 얘기도 있습니다.

  • SAS가 너무 느리게 procedure들을 추가해 주는 것 때문에 비난 받아온 것은 사실인데 사실 R은 오픈소스이고 커뮤니티 구성원중에 자신들이 만든 것을 공유하는 사람들이 많이 있는 반면에 SAS는 그렇지 않기 때문에 그런점에 있어서 SAS의 procedure가 더 적고 최신 알고리즘이 없다고 생각한다.

SAS IML로 충분히 새 알고리즘을 만들 수 있지만 잘 공유하려 하지 않기 때문에 다른 사람이 쉽게 얻을 수 없다는 것이네요. SAS의 알고리즘 지원 속도가 느린 것은 IML로 할 수도 있다라는 것 외에는 반론이 거의 없습니다.

  • R은 클라우드 서비스도 제공한다. 가격도 싸다.

SAS도 클라우드가 있다고 들었는데 사실 확인을 안해서 모르겠습니다. 다른 시스템에 연동하기에는 SAS 보다는 R이 더 유연한 것이 맞습니다. 안되면 뜯어 고쳐서라도 붙일 수가 있으니까요. 하지만 이 부분은 시스템 구축 적인 측면이지 분석적인 측면은 아닙니다. 미국 사람들은 분석 시스템과 분석 업무를 많이 구분하지 않는 것으로 보입니다.

모호한 의견들

  • R을 사용하려면 프로그래밍과 통계분석을 할 수 있는 사람이 필요하고 SAS는 엔지니어와 매니저만 있어도 사용할 수 있다. 하지만 SAS는 비용문제가 있고 만약 통계분석을 할 수 있는 사람이라면 R은 공짜다.

이 부분은 너무 잘 알려진 내용입니다. SAS의 JMP(이것도 따로 구매하는 유료 패키지인 것으로 아는데 확실치 않습니다)등을 이용하면 프로그래머의 도움없이 구축까지도 가능해서 매우 편리하다는 얘기가 있습니다. R을 사용하기를 원하는 커스터머는 주로 많은 프로그래머(IT인력)을 가지고 있지만 소프트웨어를 구매할 예산은 없는(또는 구매하고 싶어하지 않는) 고객이라는 얘기도 함께합니다. (경험상 이 이야기는 맞는 것 같습니다). 그리고 앞으로도 이런 고객들이 크게 늘 가능성이 많다고 주장합니다. 프로그래머는 싸고 소프트웨어 버짓은 점점 줄고 있다고 생각하는 의견 인데 미국쪽 커뮤니티 분위기를 살펴보면 이 경향은 맞는 것 같습니다.

  • SAS가 여전히 선호되고 있지만 이것은 너무 많이 알려져 있고 사람들이 보통 잘 알려진 브랜드가 좋다는 선입견과 오만을 가지고 있어서라는 선호하는 것이 아니냐는 의견이 있습니다. 때문에 사람들이 익숙한 것을 계속쓰고 그것으로 자신들의 문제를 쉽게 해결할 수 있으며 그것으로도 충분하다면 다른 것을 도입하는 것을 방해한다고 본다.

즉 익숙한 것으로 충분하다면 굳이 다른 것으로 전환하는 소모와 위험을 안으려 하지 않는다는 얘기입니다. 그냥 변화를 싫어하는 사람들이 많아서 생긴 문제라고 보는 것 같네요.

  • 회사환경에서 코드와 개발 기반의 시스템을 운영할 수 있는 역량이 된다고 볼 때 SAS의 정형화된 리포트나 분석방법이 아닌 다른 분석방법이나 커스터마이징된 것을 원한다면 R이 더 낫다

반대의 경우라면 SAS가 낫다는 얘기입니다. 즉 회사가 엔지니어(개발자)베이스인지 아닌지에 따라 다르고 원하는 자유도와 내재된 역량에 따라 달라 질 수 밖에 없다는 의견입니다.

  • SAS도 R처럼 확장을 만들어서 제공할 수 있다 하지만 R과 같이 중앙에서 관리하는 것은 없다.

http://www.ats.ucla.edu/stat/sas/code/ 같은 코드 공유 사이트를 충분히 운영할 수 있다고 이야기하고는 있지만 CRAN(R 패키지 제공 사이트)처럼 체계적으로 관리하지는 않다고 말합니다. 즉 SAS의 코드 신규 펑션이나 확장체를 구할 수 없는 것은 커뮤니티의 문제인데 R진영이 훨씬 잘하고 있다는 의견입니다. R을 조금 더 낫다고 말하는 듯 한 뉘앙스입니다.

  • 둘 다 써야 한다. SAS는 성숙해 있고 R은 다른 시스템과 통합하는데 유리하다. 특히 빅데이터 분석에서는 통합하기 쉬운 R이 더 유리하지만 그렇다고 해서 SAS가 불필요해진다고 보기에는 매우 어렵다. 결국은 기술적인 문제와 사용자에 따라 선택은 달라지게 마련이다.
  • 상용 소프트웨어와 오픈소스 중 어떤 것이 더 버그가 많은지는 수정과 코딩에 기울인 노력에 따르다. 버그에 대해서라면 어떤 것이라도 안전하지 않다.

SAS가 상용이고 개발 회사가 책임지므로 버그가 없다라던가 R이 오픈소스이기 때문에 오픈된 소스를 여러 사람이 지적하고 피드백을 주기 때문에 낫다는 의견을 한꺼번에 지적하는 이야기입니다. R쪽에 조금 유리한 의견이네요. 오픈 소스와 상용 소프트웨어의 비교에서 늘 나오는 얘기입니다.

  • 지긋지긋하다. 이 논쟁을 몇 년이나 계속 해야 하나?

어차피 이 논쟁은 아직 결말을 낼 수 없기 때문에 투덜거리는 얘기도 많이 있습니다. 별로 신경쓰지 않는 부류입니다. 둘 다 잘하는 사람이겠죠.

위의 내용 요약

어차피 결론이 안날 내용이고 계속 맴도는 내용입니다만 요약을 해보면 이렇습니다.

  • 개발과 분석을 동시에 할 수 있는 인적 자원이 있고 SAS비용문제가 크리티컬하고, 다양한 분석, 새로운 분석방법을 여러가지로 적용해 보고 싶으면 R을 선택한다.

IT 기반의 회사들이거나 IT개발 능력이 충분한 젊은 인력들 위주의 회사들에 대한 얘기입니다. 특히 스타트업이나 벤처 쪽이지요.

  • 위와는 환경이 다르고 다소 비용이 소요되더라도 안정적이고 기존부터 운영되어 왔던 토대에서 분석 시스템을 운영하고 싶으면 SAS를 선택한다.

주로 IT베이스가 아닌 전통적인 엔터프라이즈에 대한 얘기로 보여집니다. 그리고 비용문제가 해결된 경우입니다.

  • 가장 좋은 것은 둘 다 하는 것다.

어쨌든 둘 다 하면 좋지만 둘 다하기에는 SAS 라이센스 비용과 훈련 비용이 모두 소모되는 문제가 발생할 수도 있고, 반대로 잘 하면 둘의 장점을 합칠 수 있다라는 얘기입니다. 둘 다 하는 경우는 대부분 나중에 R로 넘어가는 경우가 많다고 알려져 있습니다.

정리

위의 논쟁들은 미국 상황이라 국내 환경과는 다소 거리감이 있습니다. 결론적으로는 아직 SAS의 우세이고 R이 기반을 장악해 나가는 추세입니다. 물론 완전히 대체하거나 한쪽이 끝판왕 되거나 소멸되거나 하지는 않을 것입니다.
사실 미국의 분위기를 보면 R을 사용하는 것에 대해 큰 거부감이 의외로 없습니다. (너는 너, 나는 나)
그렇다고 해서 SAS를 몽땅 R로 바꿀것이야 라고 말하지도 않습니다.
아래 의견은 저의 개인적인 의견입니다.

이제 경험에 비추어서 국내 환경을 정리해보면 국내 환경은 주로 SAS가 차지하고 남은 지위를 다른 분석 솔루션들이 차지하다가 최근에 조금씩 흔들어가는 모양새입니다. 그래서 주로 SAS를 다른 것으로 바꿀 수 있는가?에 대한 얘기가 많습니다.

국내 닷컴 컴퍼니

국내 인터넷 컴퍼니들 즉, 포털 및 웹서비스 업체들은 별 문제가 없어 보입니다. 특성상 되든 안되든 어차피 in-house로 해결하려 는 특성이 강합니다. SAS를 쓰고 있는 곳들은 계속 쓸 테고 구축은 SAS보다는 돈 안드는 오픈소스 쪽을 쓰려고 할 것입니다. 운영에 포커싱하는 경우가 많습니다. 역량도 충분한 곳이 많습니다. 물론 업체에 따라 전혀 아닌 곳도 있습니다.

여긴 그냥 R을 써야 합니다. 이유는 SAS가 너무 비싸고 자유롭게 다른 오픈소스와 연동하기 너무 어렵기 때문입니다. 특히 분석모듈을 어떤 플랫폼에 임베디드해야 하는 상황에서는요. 구현체를 구축해서 서비스 앞단 까지 바로 붙이고 테스트하고 전혀 새로운 모형을 만들어내고 하는 일을 빈번하게 해야하는데 자유도가 높은 것이 더 유리할 것입니다.

국내 일반 기업들

국내 엔터프라이즈쪽은 각각의 산업(industry)에 따라 조금 복잡해지는데, 이 기업들은 대부분 SAS를 이미 가지고 있습니다. 년간 라이센스를 지속적으로 지불하고 있는 곳들인데요. 산업에 따라 크게 2계통으로 나누고 R을 도입하는데 있어서 어프로치(approach)를 달리해야 하는 회사라고 할 수 있습니다.

서비스업 계통

국내 업체의 경우 SAS를 R 바꾸거나 또는 신규 도입시 R을 도입하려는 이유는 대부분 비용 때문이고 주도를 하는 곳은 IT쪽입니다. 분석 현업에서는 이미 도입되어 있고 적응이 되어 있는 SAS를 버리고 R로 바꾸려는 위험을 안고 싶어하지 않습니다. 위험한 해석일 수도 있지만 밥그릇 문제도 있겠구요. 대부분 IT쪽과 현업쪽이 충돌하거나 반발하게 되서 R을 도입하는 것은 슆지 않습니다. 결국 IT부서가 하는 것이 아니라 분석 현업이 SAS를 쓰든 R을 쓰든 해야 하기 때문입니다. 써야 하는 사람들이 일단 거부하기 때문에 강제를 하지 않으면 안되는 것인데 무작정 강제로 할 수는 없으므로 SAS와 R을 비교해와라는 지시를 내리고 지시받은 사람들은 업체에 시켜서 자료를 받은 다음 보고합니다. 보통 순서가 R의 단점을 부각시키며 위험성을 어필해서 SAS를 고수하는 사례가 많습니다.
R의 단점은 위의 논쟁들에서 나오긴 했지만, 어차피 공짜이므로 그냥 스스로 써도 되는데요. 아예 쓰면 안 될 도구처럼 표현하는 경우가 많습니다.

비즈니스 규모가 크고 IT역량이 충분하다면 R을 선택해 합니다. 이유는 비용때문입니다. 서비스규모가 커지면 분석 시스템도 커져야 하는데 그 비용이 상상을 초월하게 됩니다.

그렇다고 있는 SAS를 한꺼번에 버리면 충격이 크겠지요. 그럴 수는 없습니다.  긁어서 부스럼을  만들필요가 없지요.

그리고 비용문제가 없어도 R을 써야합니다. 이유는 연동 때문입니다. 특히 분석 모듈을 어딘가에 임베디드해야 하는 상황이거나 루즈하게 연동해서 당장 돌아가게 만드는 상황이 많다면 R을 쓰는 것이 아주 좋습니다.

비즈니스 규모가 작다면 Excel을 쓰세요. Excel 매우 훌륭합니다.

제조업 계통

하지만 복잡한 분석을 하지 않는 산업에서는 변화가 이루어지고 있습니다. 보통 제조업쪽입니다. 이런 SAS를 사용하고 있더라도 SAS의 많은 기능을 다 활용하지 않기 때문이고 분석 자체를 수행하지 않는 곳이 많습니다. SAS외에 제조 공정 관리에 더 적합한 분석 도구를 쓰는 곳도 많습니다. 사실 데이터 사이즈만 작으면 엑셀로도 충분히 가능한 곳도 많습니다.

SPC를 많이 하지 않거나 분석을 많이 하지 않을 것이라면 SAS를 그냥 써야 합니다.  안정적이고 검증되어 있고 좋습니다. 비용문제가 있다면 R이 아닌 다른 것으로 바꿔야 합니다. SPSS라든가 Matlab이라던가 인더스트리에 적합한 소프트웨어들이 많이 있습니다. 그래도 비용문제가 여전히 있다면 그때는 R이나 다른 것으로 바꿔야합니다. 하지만 최선의 선택이라고 말하기 어려울 것 같습니다.

계통을 초월한 대기업 그룹사

설명하기에는 복잡도가 최대입니다. 처음에는 설명을 안드리겠다고 적었지만 요청이 있어서 추가로 적어봅니다.

비용문제가 없다면 SAS를 써야합니다. 이유는 국내 대기업의 분석 조직 구성원들의 관성과 반발때문입니다. 대기업은 분석가들이 대부분 이미 SAS에 적응한 상태이며, SAS를 R로 바꾼다면 연습이 필요한데 그 반발이 상당하며, 또 SAS를 배워서 다른 회사에 그 특기로 입사한 사람들도 상당히 많습니다.
그 때문에 R로 전환하려는 노력을 잘 하지 많으며 R로 전환하려고 하면 밥그릇 문제로 전혀 협조를 하지 않습니다. 그래서 R 전환하는 프로젝트가 실패로 남거나 하는 시늉만 하기 일수입니다.
일부는 SAS로 하던것을 R로 하려는 사람들도 있지만 일부일 뿐이며 반발 세력의 파워를 이기지 못합니다. 이유는 대부분의 경우 SAS로 분석하나 R로 분석하나 결과 대부분 똑같기 때문입니다. 분석결과의 차이는 소프트웨어 차이가 아닌 분석기술의 차이입니다. 사람의 차이인 것이지요. R로 전환하려면 R로 바꿔서 더 좋은 분석결과가 나왔다를 증명해야 하는 선행프로젝트를 아마도 하게 될텐데 대부분 차이점이 별로 안 나옵니다. 이런 경우 비용절감외에는 프로젝트 성공 요건을 맞추기가 어렵습니다.

비용문제가 있어도 SAS를 써야합니다. 어차피 SAS의 대부분의 기능중 아주 일부만 사용하는 경우가 대부분이며 생각보다 많은 라이센스가 필요하지 않습니다. 라이센스를 줄이면 됩니다. (잘 살펴보세요. DB툴과  Excel로도 할 수 있는 것이 대부분인 경우도 많습니다) 그리고 R을 사용하겠다고 실무자가 진행한다고 해도 어차피 보장해 줄 제조사가 유명회사가 아니면 결정권자가 선택하지도 않습니다.  워런티가 안되지 않습니까. 좀 더 솔직하게 말씀드리면 제 경험으로 볼 때 아이러니하게도 중소기업보다도 R을 사용할 수 있는 환경적 기반이 안되는 회사가 대부분입니다.

R을 사용해야 하는 이유

위의 커뮤니티글에서는 가격이니 버그이니 이런말이 많지만 사실 그보다는 더 결정적인 이유가 있다고 생각합니다. R언어가 알파벳 R을 사용한 이유중 하나로 Research가 있습니다. 연구쪽에서 발전시켜왔고 그쪽 특화된 면이 없지 않습니다.그래서 그런지 R은 최신 알고리즘, 모형, 방법론, 연구논문에 대한 실제 코드 등이 매우 빠른 속도로 제공되고 계속해서 업데이트 됩니다.  이런 패키지와 문서의 분량이 너무 방대해서 감당할 수 없을 정도입니다.  IT관련 패키지들이 아닌 모형, 분석 방법론, 알고리즘, 실험에 대한 자료들 얘기입니다.

[컨퍼런스] 데이터사이언티스트가 말하는 빅데이터 분석 사례

(데이터솔루션)[http://www.spss.co.kr/main/main.asp]이 주최하는 빅데이터 세미나입니다.

  • 사이트 주소: http://www.datasolution.kr/imgs_job/marketing/2014/bigdata_01.html
  • 장소: 엘타워 그레이스 1홀
  • 날짜: 2014년 3월 25일 화요일
  • 시간: 13:30 – 17:30

0.5일 오후만 진행하네요.
주로 SPSS를 이용한 사례 중심 발표로 보여집니다.

관심있는 분들은 참여해 보세요.