철수네 소프트웨어 세상 [본점]

소프트웨어와 관련이 있다면 뭐든지 – I no longer work for Microsoft.

관찰 결과의 검증?

leave a comment »


[아래에 링크된 기사에서 인용된 만화, via http://xkcd.com/882/%5D

연구 논문을 준비하거나 쓴 사람들에게는 익숙한 토픽이겠지만, 연구의 “연(硏)”자도 잘 모르는 우리같은 회사들의 실무자들에게는 어떤 결과를 제대로된 실험으로 도출하는 것은 참 쉽지 않은 일이다. 굳이 실무타령을 하지 않아도 일상에서 온라인 뉴스사이트를 스크롤해가면서 보는 수많은 “과학” 논문을 인용한 괴팍한 기사들 – 뭘 먹으면 뭐에 좋다/안좋다”카더라”라든지 – 을 볼때도 우리 보통 살람들은 그냥 가쉽이라는 생각을 하면서도 “와, 논문!” 하면서 실생활에서 은근히 그런 것들을 적용한다. 그만큼 과학(논문)이라는 것 – 검증된 것으로 가정하는 – 의 권위는 생활 속에서 꽤나 높은 위치에 있다. 심리적으로 아님말고라고 생각해도, 실제로 건강이나 신념같은것이 걸리면 그대로 믿고, 그만큼 “뻥이요”할때 더 분노한다. 그런데, 이런 연구 논문들이 얼마나 믿을만한 것들일까. 물론 논문 대필 사건 같은것이나, 크고 작은 조작도 어제 오늘 일은 아니니까, 그런 것은 뺀다쳐도 많이 인용되는 논문들의 신빙성은 얼마나 될까.

요즘 하는 일 자체는 맨날 가설/실험/검증에 관한 이야기들이 상당수이다보니까 풍월을 읇는 척이라도 하…려는 것은 아니고, 사실 신빙성에 대한 이야기를 하려는 것도 아니지만, 얼마전에 대가분들께서 하던 이야기들이 머릿속에 남아서 정리해보고 싶었다.

“관찰 연구(Observational Study)에 의한 상관 관계(Correlation)는 통제 실험(Controlled Experiment)로 검증 해야지 (그걸 그대로 사용하면 안)된다.”

당연한 이야기지만, 학교에서 교수님이 한 말씀이 아니고 회사에서 이메일을 두고 나온 이야기라 좀 더 흥미롭다. 회사의 박사님이 이런 글을 전달해준다: “Deming, data and observational studies. A process out of control and needing fixing(PDF)”, Significance, September 2011. 요점만 간추리면, “(제안된) 제대로된 검증 프로세스로 잘못 만든 관찰 연구에 의한 허술한 논문들을 거르자.” 돌려서 이야기하면 논문이 관찰 연구만이 가능한 표본(Sample)에 의한 것이라고 하더라도, 설계 오류에 대한 검증이 허술하다는 것이겠다. 물론 이를 인용한 이유는 관찰을 통해서 결론을 내는 것이 얼마나 어려운 것인지에 대한 이야기를 하고 제대로 실험을 하시오…라고 하기 위해서겠다.

이는 상관 관계가 되었건 회귀식(Regression Equation)이 되었건, 긴 시간의 연구가 불가능한 실무자들에게 있어서는 딜레마가 아닐 수 없다. 제안은 했지만, 틀리면 돈을 날리는 상황인데, 반면에 맞으면 돈을 아끼는(뭔가 향상되는) 상황인거다. 후자에 베팅을 하고 고고싱? 물론 회사와 업무의 규모에 따라서 상당히 다른 결론을 내리겠지만, 규모가 있는 경우에는 통제 실험을 위한 설비가 마련되어 있을 가능성이 크니까 전자쪽으로 기울 가능성이 크다. 그렇다해도 하루 이틀만에 검증이 가능한 것이 아니다. 후자의 유혹은 항상 있고, 아쉽게도 수없이 많은 경우 후자를 선택한다. 밑에 수십 수백명을 둔 결정권자(Decision Maker)는 시키기라도 하면 되지만, 밀단들은 늘어난 업무에 책상에 머리박고 있게 되기 마련이다. 물론 좋은(?) 상관을 만나서 “야야, 그거 니 감대로 해…”라고 하면 마음이라도 편하지. 아무튼, 굳이 관찰 “연구”까지는 아니라 그냥 관찰(Observation)이라고 하더라도, 우리는 이런 경우를 수도 없이 많이 만난다.

또한가지 논문에 언급되는 것은 “Replicability”다. 논문이 나왔는데, 다시 똑같은 실험을 해도 논문과 같은 결과가 나오지 않는다면 논문은 틀린 것일게다. 실무에서는 비교적 결과가 빨리 검증될 수 있다. 뭔가 잘못된 결정이었다면 어디선가 손실이 일어날 것이다(물론 Success Criteria 자체가 잘못 설계되어 긍정오류일 수도 있겠지만). 여담이지만, 우리 개발자들에게는 버그를 재현(Reproduce)하는 것과 비슷하게 생각할 수 있다. 짧게 리프로(Repro)라고 하는데, 리프로가 안되면 버그가 아니라고 우기면 되는 것이다. 버그를 발견한 사람의 상황을 그대로 재현해서 오류의 지점을 정확히 파악(Contain)해야하는 것이다.

어떤 사람들에게는 너무나 당연한 이야기일 수도 있지만, 현실은 그렇지 않다. 극단적인 예를 만들어보자면, “앱에 버튼을 다른쪽에 달았더니 매출이 증가했어요.” “어 그래? 그럼 다른 버튼들도…” 하지만, 제대로 된 대답은 “다른 것 때문에 매출이 증가한거 아닐지 생각해보자.”이어야한다는 것이다. 매출이 하루 1억이라면, 사용자 1%가 영향을 받는 상황에서 버튼을 움직이는 것으로 하루 매출 100만원을 바꾸는 것이다. 다시한번 강조하지만 흔치않은 극단적인 예겠다. 하지만, 어떤 의미인지는 전달되었으리라 생각된다. 여러가지 이유 중 위와 같은 이유로 데스크탑/모바일 앱들이 HTML기반으로 만들어지기도 한다. HTML로 만든 경우에는 배포가 용이하기 때문에, 계측(Instrumentation)과 실험(Exprimentation) 또한 쉬워진다. 쉽게 이야기하면, 모든 사용자는 같은 앱을 다운로드 받지만, 사용자의 일부는 버튼을 오른쪽에, 그리고 사용자 일부는 왼쪽에 두고, 그 차이를 측정할 수 있다는 것이다.

어찌되었건, 논문들의 신빙성에 있어서는 바뀐바가 없다. 알 수도 없고, 다르게 이야기할 건덕지도 없으니 또다른 논문에 기반한 가쉽성 기사가 나와도 대화중에 인용하는 일은 계속되리라 생각된다. 실무에 있어서도 검증을 사후에 하는냐, 아니면 검증을 하고 결정을 내리느냐는 것은 과학이 아니라 말그대로 실무다. 상황에 따라, 감(Intuition)에 따라, 실손실 그리고 그 중요성과 비중 등등에 따라 다르다. 모든 것을 검증/실험할 수는 없다. 사실이든 아니든, 덤벨을 새끼 손가락에 힘을 빼고 네손가락으로 들었더니 힘이 조금 더 들어가는 것 같아서 근육이 조금 더 생긴 것 같다고 얼마든지 이야기할 수 있다. 하지만, 어떤 경우든 내가 관찰(Observe)한 것이 맞을 수도 있지만, “틀릴 수도 있다는 것”은 한번쯤은 생각해볼 일인 것 같다. — 어떤 경우에는 “내가 해봐서 아는데”라고 이야기할때도 적용될 수 있겠다.^^

Written by charlz

2012년 6월 24일 , 시간: 오전 3:44

Uncategorized에 게시됨

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: