"저는 데이터를 활용하는 역량이 뛰어납니다".

많은 사람들은 이 문장을 이력서에 당당히 쓰고 싶어합니다. 그리고 적절한 사례를 같이 첨부하고 싶어하죠.

비단 DA뿐만 아니라, 광고대행사 마케터, MD, 재무기획, 영업, PM. 직군은 다른데 질문은 놀랍도록 같습니다. "분석가가 아닌 내가, 데이터로 인정받으려면 무엇이 필요한가요?"

시장에서는 이 질문에 대한 답을 마치 SQL인 것처럼, 파이썬인 것처럼, 통계인 것처럼 도구를 팔고, 이 도구를 쓸 줄 알면 데이터를 볼 줄 안다고 환상을 심어줍니다.

제가 늘 말하듯 중요한 건 도구가 아닙니다.

쿼리와 계산은 AI가 들어주는 시대가 이미 왔고,

이제는 정말 데이터를 이해하고, 판단하고, 행동하는 능력이 핵심인 시대가 된 듯합니다.

"데이터 리터러시" 혹은 "Data-Driven Decision" 그걸 뭐라고 부르든,

데이터 활용 역량은 도구 활용 능력에 의해 쌓이지 않습니다.

저는 DA가 아니어도 뛰어나게 판단하는 PM, 마케터를 봐왔습니다.

공통적으로 SQL, 파이썬, 통계는 핵심이 아니었습니다.

그들의 핵심은 무엇이었을까요? 그들에게 물어보면 알 수 있을까요?

재밌는 점은 "데이터 리터러시"는 "자전거 타는 법"과 같다는 점입니다.

그냥 페달을 올리면 나아가듯이, 데이터를 보다보니 잘 보게 되었다고 합니다.

그래서 그들은 본인이 데이터를 잘 보는 근원적인 이유를 설명하기 어려워했습니다.

당연한 현상입니다. "데이터 리터러시"는 교과서에 나오는 순차 학습으로 이루어지는게 아니거든요.

그렇다면 어떻게 해야, 데이터를 잘 볼 수 있을까요?

1️⃣ 먼저, 가장 중요한건 '현실의 사례'가 필요합니다. "퍼널을 그리는 법, 코호트 차트를 그리는 법"은 가상사례를 통해 배울 수 있지만, "퍼널을 써서 판단하는 법, 코호트 차트로 판단하는 법"은 실제 현실에서 누군가 부딪힌 문제의 맥락을 통해서 배울 수 있습니다. 보통 이렇게 배울 수 있는 기회는 회사 내부에서 매우 데이터를 잘 보는 사람 옆에서 어깨 너머로 배우게 됩니다. 그리고 이 영역은 AI가 대체하기 매우 힘듭니다.

만약 내가 강의를 통해 이것을 배우려면 다음과 같은 조건을 모두 만족하는 사람을 찾아야합니다.

1. 본인의 접근법을 명료하게 설명할 수 있으면서, (암묵지를 형식지로 바꿀 줄 앎)
2. 그 접근법으로 여러차례 비즈니스 성과를 만들어본 경험이 있으면서, (성공경험)
3. 현실 사례를 말할 수 있도록 회사로부터 동의를 얻은 경우 (법적인 제약이 없음)

앞선 2가지는 세계1등 헤지펀드의 창업자인 레이달리오의 원칙에서 나오는 판단 법이니, 어딜가든 숙지하세요. 성공경험이 없는 사람한테 배우는 것은 스킬뿐입니다. 내가 비즈니스에서 성과를 만드는 방법을 배우고 싶다면, 좋은 회사 출신에게 배우는게 아니라, "비즈니스에서 성과를 만든 사람"을 찾아서 배우세요. 마지막 3번째는 현실적인 제약입니다.

2️⃣ 그 다음, '분석 방법론'이 필요합니다. 이를테면 '퍼널 분석'이 있겠습니다.

그런데 AI가 등장하면서, 분석 방법론을 찾고 적용해보는게 말도 안되게 수월해졌습니다. 따라서, 이제 방법론을 많이 써본건 해자가 되지 못합니다. 그런데 보통은 방법론을 항상 먼저 배웁니다. 그럴 수밖에 없는 이유는, 실제로 '현실의 사례'는 강의로 팔 수 없어도 '분석 방법론'은 팔 수 있기 때문입니다.

분석 방법론이 유의미하려면 '현실의 사례'에서 해당 방법론이 적용되고, 좋은 결과를 얻은 과정을 되짚어볼 필요가 있습니다. 즉 단순히 '퍼널 그리는 법'이 아니라 '문제를 풀기 위해 퍼널 그리는 법'을 배워야합니다.

3️⃣ 그 다음, '문제정의 프레임워크'가 필요합니다. 이를테면, 현실의 문제를 "아, 이건 Precision & Recall 관점의 문제야"라고 정의할 수 있어야합니다. 현실의 문제를 보고서 아 이 문제를 푸는 큰 틀은 Precision & Recall 관점의 사고방식이다. 그러니, 그 하위에 A, B 분석 방법론을 적용해야겠다. 같은 생각을 할 수 있습니다. 즉, 모든 문제에 모든 분석 방법론을 적용하는게 아니라, 문제를 어떤 형태로 정리해내는 틀이 필요합니다. 제가 연재했던 [전략적 생각원칙]이 여기에 해당합니다.

대략,

R1(현재 사실)과 R2(원하는 이상)의 갭을 문제로 정의하고,

"문제가 어디 있는가(Where)"를 물리적 구조(퍼널)와 가능한 원인(세그먼트)으로 쪼개 충분히 좁힌 뒤에야 Why를 찾는 순서.

이걸 잘하는 사람은 DA건, PO건 SQL을 할 줄 알 건, 모르건 데이터를 통해 배움을 얻어서 성과를 만듭니다.

이를테면, 실험 결과 분석에서 "p-value를 보니 가설이 기각되었다"는 러닝이 아니라 실험 결과(그마저도 AI가 해주는) 영역일 뿐이고, 진짜는 "러닝/팀의 다음 액션 방향"임을 이해하고 만들어낼 수 있습니다.

4️⃣ 마지막은, '메타적 사고'입니다. 이 영역은 정의된 용어가 없습니다. 그래서 저는 클래스101 팀원분들께 "데이터를 바라보는 기본 : 정방향, 역방향"이라는 문서를 써서 공유드리고 이 단어로 소통을 합니다.

가령 PAID 마케팅의 전환율은 정방향이고, 구매 유저 중 PAID가 차지하는 비율은 역방향입니다.

이걸 정리하고 팀에 공유함으로써 지금 이 데이터가 어디를 보고 있는지 소통이 원활하게 됩니다.

메타적 사고는 1,2,3 층위를 모두 추상화 시켜서 대화를 가능하게 합니다. 즉, 데이터를 보고 그걸 설득하는 "커뮤니케이션"을 수월하게 만듭니다. 그리고 동시에 내가 단방향만 보고 있는 건 아닌지, 내가 어떤 층위에서 데이터를 보고 있는지 고민하게 합니다.

이 단계는 사실상 그 누구도 신경쓰지 않습니다. 데이터를 잘 보는 사람들 조차도 이 단계까지 생각하는 경우는 거의 없습니다.

사실 '데이터 리터러시'라는 말은 "데이터를 이해하는 것"에만 포커스되어있어서 저는 좋아하지 않습니다. 데이터는 무릇 실행을 만들어야 의미가 있는데, 리터러시는 사실 반쪽짜리 표현이니까요. 결국 우리에게 필요한 건 데이터를 읽고, 실행을 변화시키는 것인데 그건 PM이든, 마케터든, MD든, 그 누구든 똑같습니다.

메타적 사고는 그런 관점에서 실행하는 모두와 소통을 편리하게 하면서, 동시에 스스로가 보는 데이터가 갇혀있지 않은지 점검하는 효율적인 툴이 됩니다.

여기까지, 눈치 채셨을 수도 있겠습니다만, 이 4가지는 Layer입니다.

가장 추상적인 영역이 4️⃣[메타적 사고]이고, 가장 구상적인 영역이 1️⃣[현실의 사례]입니다.

이 4가지 레이어 중에서 만약,

1. 내가 데이터 직군이라면 1~4 그리고 SQL/태블로(도구) 정도가 필요하고,
2. 내가 데이터 직군이 아니라면, 1~4가 필요합니다.

시장에는 70%의 데이터 분석 강의가 도구에 집중하고, 30%의 분석 강의가 '분석 방법론'에 집중합니다. 그마저도 현실의 사례가 없기 때문에 데이터 리터러시를 늘려주지 못합니다. 그게 현실입니다.

그리고 그건 강사가 악랄해서가 아닙니다. 현실의 사례를 있는 그대로 알려줄 수 있는 강사는 없습니다. 현실의 구조가 그렇습니다.

다만, 데이터를 활용하는 능력이 4 Layer에는 있지도 않은 '도구'에 집중하게 만든 것은 안타깝습니다. 나머지 Layer(프레임워크 / 메타적사고)의 존재조차 알려주지 않는 것도 매우 안타깝습니다.

Q1. 분석을 시작하기 전, 질문은 어떻게 세팅하나요?

"데이터를 분석하기 전에 어떻게 질문들을 세팅하시나요? 어디서부터 데이터를 봐야 할지 모를 때, 시작점을 어떻게 찾는지 궁금합니다."

앞서 설명드린 레이어중 [3️⃣ 문제정의 프레임워크]가 필요하고, 그걸 [1️⃣ 현실의 사례]에서 배워야합니다.

이 문제의 시작점은 데이터가 아니라 목표입니다.

어떤 분석이든 목표 Y가 분명해야 하므로, R2(원하는 이상)를 먼저 정리합니다.

그다음 R1(현재 사실)과 R2의 갭을 보고, 그 갭을 물리적 구조(퍼널)와 가능한 원인의 분류(세그먼트)로 쪼갭니다. 여기에 정방향 view와 역방향 view를 적용해 훑으면, 어디서부터 봐야 할지가 저절로 정해집니다.

R1·R2로 문제를 정의하는 것이 문제정의 프레임워크의 일이고, 정방향·역방향으로 지금 내 시선이 어디를 보고 있는지 점검하는 것이 메타적 사고의 일입니다. 두 층위가 같이 돌 때 시작점이 정해집니다.

거꾸로 말하면, "어디서부터 봐야 할지 모르겠다"는 상태는 대개 R2가 없는 상태입니다. 목표 Y가 불분명하면 행동 X도 불분명해집니다. 데이터를 먼저 열지 말고, 원하는 이상부터 적으세요.

이 내용은 전략적 생각원칙이라는 제가 써놓은 글에서 확인하실 수 있습니다. 글의 최하단에 연관 컨텐츠로 넣어두었습니다.

Q2. 드릴다운은 어디까지 하고, 언제 실험으로 넘어가나요?

"가설 검증 과정에서 드릴다운을 계속 하다 보면 끝이 없다고 느껴지는데, 실무에서는 어느 시점에서 '이 정도면 충분하다'고 판단하고 실험 단계로 넘어가시는지 궁금합니다."

좋은 질문입니다.

[1️⃣ 현실의 사례]가 빈약할 때 주로 이런 경험을 합니다. (+ [3️⃣ 문제정의 프레임워크]가 필요합니다)

제 오랜 기준은 하나입니다.

내가 메커니즘을 설명할 수 있을 때. 결국 얼마나 해상도가 높으냐의 문제입니다. 숫자가 더 잘게 쪼개졌느냐가 아니라, "왜 이런 일이 일어나는가"를 남에게 납득 가능하게 말할 수 있느냐가 종료 조건이에요.

드릴다운의 목적은 무한 세분화가 아니라, 상상이 개입할 여지를 줄이는 것입니다. 문제를 충분히 좁힌 지점에서 Why를 찾아야 의미 있는 가설이 됩니다. 좁혀야 상상을 덜 하고, 뇌피셜이 없어집니다. 그게 달성되었다면 멈춰도 됩니다.

덧붙이면, 질문하신 상태는 제가 말하는 '전략의 딜레마'와 비슷합니다. 실행해본 경험이 없으면, 어디서 멈춰야 할지에 대한 확신도 생기지 않거든요. 그래서 뒤에서 말할 "감당 가능한 비용이면 실행이 낫다"는 원칙과 짝을 이룹니다.

Q3. 분석이 끝난 뒤, 인사이트는 어떻게 뽑아내나요?

"데이터 분석 후에 인사이트를 얻는 노하우가 있을까요?"

출발점은 이 문장입니다.

데이터를 많이 보는 것은 데이터 드리븐 디시전과 아무 상관이 없습니다.

인사이트는 데이터를 더 오래 들여다본다고 나오지 않아요.

[1️⃣ 현실의 사례] + [3️⃣ 문제정의 프레임워크]

이 2가지가 핵심입니다. 특히 Q2에서 언급한 전략의 딜레마를 깨본 경험이 있어야 해요.

순서가 있습니다. R1과 R2를 먼저 정하고 그 갭을 문제로 정의한다, "문제가 어디 있을까(Where)"를 물리적 구조와 가능한 원인 두 관점으로 쪼갠다, 충분히 좁혀진 지점에서 Why를 찾는다. 그때 나온 가설이 의미 있는 가설이고, 내러티브는 바로 그 "이 영역은 왜 차이가 날까"에서 개입합니다.

그리고 산출물의 기준은 러닝입니다.

"p를 보니 가설이 기각되었다"는 러닝이 아니라 실험 결과예요. 인사이트란 고객과 문제에 대한 납득 가능한 이해이고, 그게 없으면 분석은 "so what?"으로 끝납니다.

마지막으로, 데이터에 갇히지 마세요.

항상 데이터만 보고 의사결정하는 건 한쪽 눈을 가리고 게임하는 것과 같습니다. 어떤 결정은 유저 리서치로 푸는 게 맞습니다.

Q4. A/B테스트가 어려운 환경입니다. 전후비교·준실험 경험도 유효한가요?

"회사 업종 특성과 분위기상 A/B테스트를 시도하기 어려운 상황입니다. 이런 환경에서 전후비교, 인과추론 같은 준실험계획을 하는 것도 유효한(인정받을 수 있는) 경험이 될까요?"

오히려 질문자님께 유리한 답을 드릴 수 있습니다.

첫째, 제게 실험의 목적은 두 가지뿐입니다. 러닝을 얻거나, 리스크가 있거나. 이 둘이 없으면 실험 자체가 불필요합니다. 실제로 저는 PM의 UI 변경 실험을 세팅 단계에서 반려한 적이 있어요. 이 모수면 p-value가 나오기까지 몇 주가 걸리는데 러닝도 리스크도 없고, 이 정도 MDE 문제면 몇십 % 차이가 나야 하는데 그건 시계열로도 관측 가능하니, 실험 공수 빼고 그냥 배포하시라고요. 즉 A/B테스트가 아니어도 시계열 전후 관측이 정당한 방법이 되는 조건이 있고, 저는 그 조건을 실무에서 그대로 씁니다.

둘째, 감당 가능한 비용이면 실행이 무조건 낫습니다. 엄밀한 인과 식별이 안 되는 상황이라도, 비용의 하방이 막혀 있으면 실행하고 배우는 쪽이 낫습니다.

셋째, 평가받는 건 기법이 아니라 러닝입니다. 준실험이든 A/B든, 고객과 문제에 대한 납득 가능한 이해를 만들어냈다면 그게 분석가의 산출물입니다.

결국 A/B테스트는 [2️⃣ 분석 방법론] 층위의 일입니다. 거기에 갇히는 순간 A/B테스트가 불가능한 회사는 마치 아무것도 할 수 없는 회사가 되고, 이런 상황에 갇힌 DA는 주로 '인과추론' 영역으로 떠납니다. 그리고 그 영역에 도달했을 때, 실무에 적용하는게 거의 불가능이라는 점을 깨닫고 돌아옵니다.

(전략 코칭 프로그램 수강생 분이 남겨주신 실제 의견)

따라서, A/B테스트가 안 되는 상황이라면 [4️⃣ 메타적 사고]를 통해 팀의 언어를 결집하고 소통의 비용을 줄여 설득하는 과정이 필요합니다.

Q5. 쓸 수 있는 데이터 자체가 적은 도메인(금융권 등)에서는 어떻게 보완하나요?

"금융권의 경우 활용할 수 있는 데이터가 교과서와 다르게 적은데, 이를 보완할 수 있는 방법이 궁금합니다."

첫째, 근거 소스는 데이터만이 아닙니다. 저는 데이터 분석, 유저 리서치, 시장 리서치, 그리고 행동경제학처럼 오래 살아남은 이론, 이 네 가지 근거 소스의 교차검증을 강조합니다. 직군이 나뉘어 있다 보니 다들 하나씩만 보는데, 네 소스가 하나의 방향을 가리킬 때 진리의 위계가 높아집니다. 데이터가 없는 순간은 항상 오고, 그때 다른 소스로 채우는 능력이 차이를 만듭니다. (저는 이런 관점을 [4️⃣ 메타적 사고]라고 부릅니다. [2️⃣ 분석 방법론]에 갇히지 마세요. 더 높은 층위에서 사고하세요)

둘째, 데이터가 없으면 만듭니다. 제가 이력서 리뷰에서 극찬했던 사례가 정확히 이것이었어요. 회원가입 전환율이 낮은데 로깅이 없자, 유저 인터뷰로 인증 방식 문제를 발견하고 로깅을 재설계해 퍼널을 확인 가능하게 만든 케이스. 데이터가 없을 때 데이터를 만든 부분이 가장 인상적이었습니다.

셋째, 그래도 없으면 피팅합니다. 토스 DA 7개월 차 시절, 원천 데이터가 없는 질문을 받고 하루 이틀 고민한 끝에 로그와 시점 정보로 유저 여정을 피팅해 정확도 90% 이상의 답을 준 적이 있습니다. 없다고 멈추지 않는 것 자체가 역량입니다.

Q6. 세일즈가 메인인 회사에서, 분석가는 무엇을 분석해야 하나요?

"프로덕트가 아닌 세일즈가 메인인 회사일 때, 분석가 입장에서 대시보드 외에 어떤 통계기법을 써서 어떤 분석을 해볼 수 있을까요? 최적의 컨택시간 같은 것 외에 깊이 있는 분석 주제가 생각나지 않습니다."

재밌네요. 최근에 Sales-Led Growth를 하는 회사의 DA 리드분과 컨설팅 겸 이야기를 나눌 일이 있었는데, 먼저 드리고 싶은 말은 이겁니다. 통계라는 틀에서 벗어날 필요가 있습니다. "어떤 통계기법을 쓸까"에서 출발하면 컨택시간 최적화 같은 국소적인 주제만 남아요. 즉, 질문이 분석 방법론 층위에 묶여 있는 겁니다. 한 층위 올라가야 답이 보입니다.

이런 상황일수록 [3️⃣ 문제정의 프레임워크]가 더더욱 중요합니다.

신기하게도, 시리즈가 꽤 오래된 회사들조차 회사 전체의 구조가 불명확한 경우가 많습니다. 그래서 순서는 이렇습니다. 첫째, 회사 전체의 매출(보통 IR용이자 기업가치 평가용으로 MRR을 많이 쓰죠)이 어떻게 만들어지는지부터 그립니다. 둘째, 그 하위 스트림이 구성되면 각 스트림을 움직이는 게 뭔지를 찾습니다. 셋째, 이것들이 조직 안에서 합의되는 것. 저는 이 합의가 제일 중요하다고 생각합니다.

세일즈 기반 그로스라도 결국 재계약(넷 달러 리텐션)의 중요성은 변하지 않습니다. 재계약이 차지하는 향후 5년간의 볼륨, 신규가 차지하는 볼륨, 이런 것들이 나눠져야겠죠. 대시보드 너머의 깊이는 기법이 아니라 이 구조 분해에서 나옵니다.

Q7. 다른 회사의 데이터 활용은 어떻게 벤치마킹하나요?

"다른 회사들이 데이터를 어떻게 활용하는지 벤치마킹하고 싶은데, 현업에서 실제로 참고하시는 채널이나 방법이 있으신지 궁금합니다."

범위가 되게 넓은 질문입니다. 제 답의 뼈대는 이겁니다. 데이터 밸류 체인의 각 단계(발생→입수→정제/마트→분석→인사이트→가치 창출)에 따라, 어떤 회사를 어떻게 벤치마킹할지가 전부 달라져요. "데이터 활용"이라는 한 덩어리로 물으면 답이 안 나옵니다. 다들 '분석' 단계에만 집중하지만 진짜 승부처는 맨 끝, 가치 창출(의사결정에 대한 영향)입니다. 벤치마킹도 내가 지금 어느 단계가 약한지를 먼저 짚고, 그 단계를 잘하는 회사를 봐야 합니다.

덧붙여 "데이터 업계 동향은 어디서 보시나요"라는 질문에는 도발적으로 답한 적이 있습니다. 데이터 업계라는 컨셉이 실질적으로 존재하는 개념인지 모르겠다고요. 방법론과 신도구 소식 위주의 정보는 문제를 푸는 힘이 아니라 도구 적응도만 올려줘서, 저는 잘 보지 않습니다. 채널을 늘리는 것보다 무엇을 위해 보는지가 먼저입니다.

결국 제가 데이터 활용 능력을 4 Layer로 나누게 된 것 역시 더 많은 사람들이 데이터를 뛰어나게 활용하게 만들기 위해서였거든요.

Q8. 인상 깊었던 분석 사례를 들려주실 수 있나요?

"사소해 보이지만 인상 깊었던 분석 사례가 궁금합니다..!"

이 질문이 사실 첫 번째 층위, 현실의 사례에 대한 이야기입니다. 가장 중요한 층위이면서, 구조적으로 가장 알려드리기 어려운 층위라고 했던 그곳이요.

분석 사례는 대부분의 회사에서 NDA(비밀유지협약)가 걸리기도 하고, 맥락이 매우 중요합니다. 제 경험상 맥락 없는 비현실 상황에서의 분석을 배우는 건 그다지 도움이 되지 않았어요. 그래서 아무 사례나 여기에 나열하지는 않으려 합니다.

대신 두 가지 경로를 안내드립니다. 첫째, 제 멤버십에서는 회사와 협의해 최대한 실제의 상세한 내용을 다루고 있습니다. 둘째, 비밀유지에 무관한 사례는 이 채널에서 풀버전으로 정리하고 있고, 이미 실사례가 올라가 있습니다. [1️⃣ 현실의 사례]를 얻을 수 있는 사실상 유일한 경로죠.

맺으며

여덟 문답의 결론은 처음의 한 문장으로 돌아갑니다. 데이터를 많이 보는 것은 데이터 드리븐 디시전과 아무 상관이 없습니다. 목표를 먼저 정하고, 문제를 좁히고, 납득 가능한 러닝을 만드는 것. 그게 방법론의 전부입니다.

그리고 눈치채셨을지 모르겠습니다. 질문의 상당수가 도구와 기법의 언어로 왔는데, 여덟 개의 답 어디에도 도구는 없었습니다.

데이터를 잘 보는 사람들은 자전거 타듯 배워서, 정작 본인이 왜 잘 보는지 설명하기 어려워한다고 했죠.

이 여덟 문답은 그 설명을 층위 위에 올려서 대신 해보려는 시도였습니다.

연관 컨텐츠

[1️⃣ 현실의 사례]

1. [⭐️실전사례] 실패한 실험으로부터 배우기 (feat. 클래스101 환불 방어 실험)
2. [⭐️실전사례] 실험에서 러닝을 얻는 데이터 리터러시 (feat. 클래스101의 Disco CRM 실험)
3. [⭐️ 실전 분석 케이스] 이 정도 분석은 1분이면 생각해야죠. (feat. 휴대폰 점유인증과 CRM)

[2️⃣ 분석 방법론]

1. [그로스모델] 모델링했다고 주장하는 대부분의 것들을 쳐다볼 가치도 없는 이유
2. [방법론 /🔥실전 프롬프트 포함] 아무나 할 수 있는데, 아무도 안 해서 손해보는 분석 스킬 (Feat. Log UT)

[3️⃣ 문제정의 프레임워크]

1. [전략적 생각 원칙] 시리즈
2. #1. 지적 게으름을 벗어나라. : https://buly.kr/CWvFqML
3. #2. 모든 문제는 맥락 속에 존재한다. : https://buly.kr/2JpIx2t
4. #3. ‘R2’를 찾아야만, 문제를 정의할 수 있다 : https://buly.kr/G3EPSgU
5. #4-1. 세 가지 프레임워크로 문제를 정확하게 정의하라(1) : https://buly.kr/1vSn2C
6. #4-2. 세 가지 프레임워크로 문제를 정확하게 정의하라(2): https://buly.kr/CqGJBH
7. #5. 언제든 처음으로 돌아갈 용기를 가져라 : https://buly.kr/44yybOa

1. [기초] 생각 Framework : Precision & Recall

[4️⃣ 메타적 사고]

1. [분석 지표] Caring Capacity는 약간 허상이 많다(?)고 하셨는데 이유가 궁금합니다!
2. [AI] AI가 나를 대체하는게 두렵습니다.

(모든 멤버십 전용 글들은 클래스101의 실제 사례를 다루고자 노력하고 있습니다. 글들이 주로 커버하는 영역 위주로 표기하였으며, 여러 레이어에 걸친 생각들을 다룹니다)