Book
제목이 꽤 매력적이지 않은가? “최고의 결정”이라니… 거기에 호황과 불황을 모두 포함해서 50년을 경험한 사람이라니, 연달아 두 팀을 리딩해본 리더의 입장에서는 꽤나 솔깃했던 제목이었다. 물론 “최고”를 결정하는 기준이 나와 같을지는 고민해보면서 말이다. 경제 전문가라고 적혀있는 만큼 도메인 경험으로 인한 차이에 대한 불신이 있었기 때문이었다. 결론부터 이야기하면 정말 많은 사건과
Business
Summary * Delivery Time Prediction은 Regression 문제이기도 하지만 Result가 분단위 정도로 나눠진다고 하면 Classification 문제로 간주할 수도 있다. * 비즈니스 관련 Cost Sensitive Rule을 고려하기 위해서 Regression Tree를 사용하되, 성능을 끌어올리기 위해 Random Forest를 고려했고, 예측값이 정규분포가 아닐 가능성을 고려하여 Quantile로 나눠서 예측, 최종 모델은 Quantile Random Forest (for Regression)을 하였다.
Team
지금 회사 입사 이후에 깨달은 사실 중 하나였고, 데이터 조직도 예외는 아닌 하나의 사실로 남은 교훈이 있는데, 바로 팀의 목표는 회사의 비전으로부터 시작해야 한다였다. 최근에는 OKR이 나오면서 과거 대비 익숙할지 모르겠지만, 이전에 기술조직은 사업의 마치 하청조직인 것마냥, 사업계획보다는 운영계획의 형태로 비용계획을 수립하고, 백오피스의 역할이 강했다. 하지만 과거와 달리 지금은 모든
Team
데이터 프로덕트를 만들 때는 보통 두가지 경우가 있다. 하나는 주도적으로 프로덕트를 구성하는 경우, 그리고 다른 하나는 외부 요청에 의해 프로덕트를 구성할 때가 있다. 전자의 대표적인 케이스는 추천시스템이다. 데이터가 가장 중요하고 데이터 없이는 운영이 불가능한 데이터 주도로 시스템을 구축하는 전형적인 케이스다. 이보다 더 오너십이 뚜렷한 데이터 프로덕트는 찾기 어렵다. 하지만 오늘
Causal Inference
Positivity Assumption * Formal 하게 말하면 관심 있는 모든 계층 및 노출 수준에 대해서 공변량을 조건부로 하였을 때 특정 수준의 노출이 있을 확률이 0보다 크고 1보다 작아야 한다는 것이 Positivty Assumption * 쉽게 말하면 어떤 두 집단을 비교한다고 할 때, Treatment를 받을 수 있거나, 받지 못할 수 있는, 또는 받게될 표본집단을 반드시
Devonthink
Background * Devonthink를 쓰면서 Bookmark가 계속 늘어나고 있고 있다., 이 Bookmark를 모두 읽었는지 잘 모르기 때문에 Labeling을 하고 있다. 아래는 실제 내 노트북에서 내가 Labeling하는 색을 가지고 온 것이다. 이건 논문을 보면서도 항상 하는 습관 중의 하나인데, Label이 Bookmark를 추가할 때 작은 아이콘으로 보여서 자꾸 놓치고 Add를 한다. 그래서 이번 기회에
Team
얼마전 저녁을 위해 피자를 포장하러 밖에 다녀올 일이 있었다. 아내가 고른 피자 2판을 픽업하기 위해 기다리면서 메뉴들을 훑어보는데 메뉴이미지와 실제 메뉴의 모습이 다르다라는 생각이 떠올랐다. 순간적으로 동일한 경우가 어디 있겠나라는 생각이 들었는데, 이게 리더인 내 삶와 정보의 관점에서 다시 생각해보니 좀 생각할 꺼리가 있다는 생각이 들었다. 정보는 생산자와 소비자간의 상호작용을
Book
사실 크게 그렇게 기대하고 읽은 책은 아니었다. 어떠한 컨텐츠로 그가 돈을 벌고 있는지도 모르고 있었고, 지속가능한 것인가에 대해서도 모르는 상황이었기 때문에 그다지 궁금하게 보지는 않았던 까닭이다. 그래서 궁금해서 이 책을 보게 된 것같다. 특히 직전에 읽은 책이 최인아님의 “내가 가진 것을 세상이 원하게 하라”였다보니 더욱 더 “드로앤드류”라는 채널의
Dev
Summary MSA(Micro Service Architecture) * 각각을 마이크로하게 나눈 독립적인 서비스를 연결한 구조 * 시스템 전체의 중단 없이 필요한 부분만 업데이트·배포가 가능 * 유연한 대응이 가능→ 실시간으로 요구사항을 반영할 수 있어 급격히 성장한 기업들이 많이 택한 방법 * 각각 독립적인 서비스로 이루어져 있기 때문에 모듈의 인터페이스를 신중하게 처리해야 하고 제약들도 많음 * 분산된 서비스마다
Data
Summary * First Step Analysis란 Markov Chain을 해결하기 위한 간단한 방법 * Markov Property를 이용해서 변수들의 특성을 빠르게 파악하는 방법 Prerequisite * Absorbtion, Transition 개념 이해 필요함. * Absorbtion Status에 들어가게 되면 그 이후로는 이제 Status가 변하지 않는다. Example * 다음과 같은 전이행렬이 있따고 가정할 때 Absorbtion Status에 도달하기까지의 시간과 확률, 그리고 평균 기대시간을 구한다고
Data
정답은 비즈니스 목적을 달성하기 위해서 기존의 방안에서 답이 없다고 판단할 때이다. 보통 조직들은 팀을 신설하고 데이터과학자나 엔지니어를 채용한다. 그리고 바로 실적이 나오길 기대한다. 이 때 기다려줄 수 있는 관점은 철저히 비즈니스 관점에서 사업계획에 예정된 일자일 경우가 많다. 다시 말해서 기타 비즈니스 요인은 고려되지 않은 경우가 많다. 데이터 조직이 생기고 프로세스가
Data
created: 2023-05-11 19:54 modified: 2023-05-11 19:54 title: Write Here tags: (default: []) * tag1 * tag2 featured: false published: false 복잡한 모델 또는 기술이 능사는 아니다. 비즈니스는 그런걸 신경쓰지 않는다. 비즈니스 부서들은 모델의 디테일따위 관심이 없다. 당신이 Naive Bayes를 쓰던 Random Forest를 쓰던 비즈니스 목표를 달성만 해주면 된다. 우선 빠른게 좋다.
Data
* 해당 내용은 Causal Inference Study 때 발표(2023/05/03)한 내용으로 Introduction 성격으로 짜집기된 내용임을 밝힌다.
Data
Summary Motivation * Transformer는 성능은 매우 좋으나 내부 구조의 복잡함으로 인해서 계산비용이 기하급수적으로 증가하는 문제가 있다. 이 부분에 대한 개선은 Dot Product를 이용해서 지속해서 개선해왔으나, 여전히 개선이 필요한 분야이다. * 연구분야는 1)크게 메모리사용량을 줄이기 위한 방안을 찾는 부분과 2)Sequence Length를 늘려서 맥락을 최대한 이해할 수 있게 하려는 부분인데 계산량 자체를
Team
더 빠르게, 더 빠르게 프로덕트를 만들면 어떨까? 매 스프린트에서 만들어야 하는 산출물의 사이즈를 줄이고 줄이면서 속도를 맞출 수 있겠지만, 사이즈를 줄이지 않고 어떻게든 납기일을 맞춘다면 어떻게 될까? 프로덕트는 만들 수 있겠지만, 경직되고 확장에 대한 유연성은 낮추고 그 문제만을 풀기 위해 디자인 될 것이다. 그렇다면 프로덕트를 만들 때마다, 확장은 어렵고, 새롭게
Team
이전에 존잡생각에서 "회사에서 본인을 빠르게 성장시키는 방법"에 관한 글을 본 적이 있다. 구체적으로 내용이 기억나지는 않지만, 거기서 나오는 그래프는 기억이 난다. 스타트업 초기에 회사의 성장과 개인의 성장은 비례를 한다. 하지만 어느 시점부터 회사가 규모의 경제의 변곡점에 도달하면 개인의 성장과 회사의 성장의 기울기는 크게 벌어지기 시작한다. 개인은 정체하고