그냥 말 그대로 일을 할때는 e가 어떤 컨텍스트에서 나온지 알필요가 없다는거임
e를 \lim_{x\to \infty} (1+1/x)^x 로 정의하는지
\sum_{i=1}^\infty \frac{1}{n!} 가 성립하는지 알필요가 없다고
진짜 끽해봐야 glm 돌리고 있어서 logistic regression하면 coefficient가 logit에 대한 거라서 해석할때 조심해야된다 정도겠지
mle도 마찬가지임 수업에서야 log likelihood 열심히 계산하고 미분해보고 convex인지 확인해보고 하겠지
통계이론이든 수통이든 결국엔 마지막에 하는게 mle의 consistency랑 asymptotic normality 증명이기도 하고
근데 사실 일을 할때는 mle인지 least square estimator인지 걔네의 이론적인 성질이 뭔지가 생각보다 덜 중요하다고
걍 mle를 썼더니 퍼포먼스가 어떻게 되고 glm을 썼더니 퍼포먼스가 어떻게 됐다까지가 끝이지
이게 canonical 링크라 어쩌구가 안중요함 걍 어떻게든 결과가 나왔고 퍼포먼스가 좋은면 장땡이지
나도 대기업은 아니지만 이 분야 사람들은 이름 무조건 들어봤을 회사에 잠깐 있는데
뭐 존나 큰 회사는 뭐가 다를지 모르겠는데
아예 raw data 밑바닥부터는 아니어도 어느정도 데이터 전처리도 해야되고,
model evaluation하고 visualization해서 문과생들이랑 커뮤니케이션하는게 일의 큰 부분중 하나인데
이런거 할때는 수학적 지식을 쓸일은 엥간하면 잘 없음 걍 문제해결 능력이지
이론공부가 잘 쓰일수 있는건 예를 들어서 ml context에서 모델이 어떻게 바뀌면 mle를 쓰고 싶으면 loss가 어떻게 바껴야하는지 이런거 계산할때 쓰는거지
다른쪽에 포커스를 두고 있는 사람들은 저런걸 알 필요는 없다고
뭐 '진짜 데이터 사이언티스트'는 그런거 안하고 수학적 모델링해야죠~ 라고 말하면 나도 어느정도는 공감하는데
그냥 여기서 데싸라고 하고 월급 말도 안되게 받는 사람들이 애초에 저런 지식을 잘 안쓴다고 ㅋㅋ 내가 본 현실은 그럼
그리고 당연히 그렇다고 통계 전공인데 이런걸 몰라도 된다고 하는게 아님 통계/수학 전공인데 e가 뭔지 모르면 당연히 그 말 듣자마자 탈락이지
강한 통계 백그라운드가 장점이 되는것도 맞아서 당연히 데싸 취업하고 싶으면 공부하는게 유리한건 맞는데
강한 코딩 백그라운드나 특정업계 경력처럼 걍 장점이지 필요조건은 아닌거 같다고 말하고 싶었음
뭘 말하고싶은건지 사실 이해는 됐었는데 나도 업계에 있다보니 답답한 상황을 많이 겪긴한다. C레벨 보고나 임원보고로 갈때는 수식이나 수학적 지식은 필요없다는거는 많이 느꼈고.. 그냥 여기서 데싸라고 하고 월급 말도 안되게 받는 사람들이 애초에 저런 지식을 잘 안쓴다고 ㅋㅋ 내가 본 현실은 그럼 이거는 많이 공감했고 그냥 본인 하고싶은 말은 뭔지 알고
그냥 e를 몰라도 된다는게 공격당할 여지가 너무 많은 댓글이었고 여기 갤 특성상 석박하고 있는 애들 많이 들어오니 업계 sense로 얘기하는게 한계가 있긴함. 졸립다.. 출근이나 합시다
참고로 난 전직장이 통신사였음 (슼트) 그때 mle 얘기했을때 피곤하게 사는 놈이란말 들어봤네.. 나도 날잡고 industry와 academy 의 괴리에 대한 글이나 써야겠다
ㅇㅇ 이 컨텍스트는 공감함. 나도 현업 있으면서 깊게 쓸 일이 흔하지는 않음. 근데 현업과 아카데믹과의 괴리가 있는 건 회사의 문제지 개인 문제는 아닌 것 같음. 적어도 분석으로 밥먹는 사람은 알고 있어야 하고, 대놓고 e나 MLE나 이런거 안 나와도 어떤 상황에서 아 이건 MLE 쓸 수 있겠다라던지... 사리분별은 돼야 한다 생각함. - dc App
소양으로 알고 있지만, 우리나라 여건 상 현업이라는 데서 잘 쓰지는 않겠지만, 그러나 언젠가 쓸 수도 있을 때 이 아이템을 아냐 모르냐가 실력을 가를 거 같다. 하다못해 세밀하게는 라이브러리 내 함수들도 파라미터 보면 method="MLE"나 "CSS-MLE" 이런 옵션들 있잖아. - dc App
그럼 백엔드 개발자랑 다른게 뭐임 - dc App
백엔드 엔지니어가 낫지 왜냐면 딱 저정도 수준에서는 백엔드는 프로덕트 만드는데 도움이라도 되지 데싸는 사실상 그럴듯한 결과를 가져와서 입터는 역할이거든 - dc App
댓글 쭉 보면 cs쪽을 많이 선호하네..나중에 FANG 쪽으로 한번 와봐요 cs랑 ds 롤이 명확하게 분리되어 있고 statistical, mathmatical 한 부분이 도움이 됨..국내에서는 ds를 BI업무를 주니깐 입턴다는 표현을 쓰는건가
전 오히려 아카데미 루트를 밟으면서 인더스트리로 빠지는 길도 열어두고 있는 케이스라 엔지니어링 쪽에서 부족함을 느끼거든요. Faang은 사실상 논외라고 보는게 거기는 사실상 researcher 느낌인 직군이 많아서 - dc App
나름 공감되는 부분도 있어서 그만 얘기할까 했는데 하나만 물어볼게. 데이터에서 임산부의 흡연이 기형아 출산율을 낮춘다는 결과가 나온다면 본인이 정책이나 의사결정을 내릴 때 어떻게 할거임? 데이터를 보니 그럴듯한 결과도 있는데?
임산부에게 담배를 권하는 캠페인을 할거야 말거야? 주변에 어떤 인력 Pool이 있는지 모르겠는데...나는ds도 개발능력이 필요하다는거에는 동의하나 백엔드 엔지니어가 낫지 라는 말은 동의를 못하겠네
너무 유명한 예시인걸 알아서 구구절절 설명하고 싶지 않음… - dc App
cuasal sense로 봐야하는거도 이해하고 있는거 같은데 왜케 개발자를 선호하는거야? 글을 보현 이미 well train된 사람같은데.. 각자 롤이 다른거자나...
좀 답답해서 그래 예전 회사에서도 ds랑 cs의 파워게임에 진저리가 났거든..암튼 나중에 본인이 팀장이나 더 위로가면 통계쟁이를 위한 업무환경을 만드는데 힘써줘..
말을 좀 너무 일반화되게 써서 오해의 소지가 다분한데 엔지니어>ds 이런 주장을 하려는건 전혀 아니고 딱 저정도 일을 하기위해서 필요한 능력보다 백엔드 엔지니어가 되기위한 능력이 더 커보인다는 말이었음 - dc App
나도 사실상 ds쪽인 입장에서 내가 알고 있는 지식은 써먹을 일이 거의 없고 진짜 가끔 부수적인 텍스트로나 쓰게되서 리서치할거 아니면 진짜 걍 코딩이라도 ㅈㄴ 잘하는게 나을거 같다는 생각이 자꾸 들어서 그럼 - dc App
개발자 친구들이 회사에서 보면 퍼포먼스 잘 내니깐.. 나도 그런 고민한적 있음..