AI 사용자 4유형 Part 2: 빨리 들이는 사람들

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1 에서 두 축을 세우고 자가진단을 했습니다. 이번 편은 위쪽 두 칸, 빠르게 도입하는 사람들 입니다.

flowchart LR
    H0[" "]:::hdr
    H1["결과를 잘 안 본다"]:::hdr
    H2["결과를 의심한다"]:::hdr
    R1["빨리 들인다"]:::hdr
    A["① 순진한 실용가<br/><br/>이번 편"]
    B["② 감별하는 얼리어답터<br/><br/>이번 편"]
    R2["늦게 들인다"]:::hdr
    D["④ 떠밀린 사용자<br/><br/>Part 3"]
    C["③ 신중한 후발주자<br/><br/>Part 3"]
    H0 ~~~ H1 ~~~ H2
    R1 ~~~ A ~~~ B
    R2 ~~~ D ~~~ C
    classDef hdr fill:none,stroke:none,color:#dddddd
    style A fill:#FF9999,color:#000000
    style B fill:#90EE90,color:#000000
    style C fill:#555555,color:#999999
    style D fill:#555555,color:#999999

두 유형은 공통점이 많습니다. 둘 다 호기심이 있고, 둘 다 도구를 빨리 집습니다. 갈리는 지점은 하나입니다. 받은 답을 어떻게 처리하는가.

그리고 그 하나의 차이가 몇 달 뒤에는 되돌리기 어려운 격차를 만듭니다.

① 순진한 실용가 — 가장 흔하고 가장 위험한 칸#

이 유형의 초상#

AI 를 잘 씁니다. 정말입니다. 메일 초안, 회의록 정리, 코드 스니펫, 여행 일정, 보고서 요약 — 손에 익었고 속도도 빠릅니다. 주변에서 “AI 좀 쓰는 사람"으로 통합니다.

문제는 받은 답을 그대로 쓴다는 것 입니다.

특징적인 장면들입니다.

AI 가 준 통계 수치를 출처 확인 없이 슬라이드에 넣습니다
코드가 돌아가면 통과입니다. 왜 돌아가는지는 안 봅니다
“AI 가 그러던데"라는 말을 근거로 씁니다
답이 이상해도 “내가 잘못 물었나 보다” 하고 다시 묻습니다. 답이 틀렸을 가능성은 잘 떠올리지 않습니다

마지막 항목이 이 유형의 핵심입니다. 오류의 귀속 방향이 항상 자기 자신을 향합니다.

왜 이렇게 되는가 — 당신 탓이 아닙니다#

여기서 자책하실 필요는 없습니다. Part 1에서 인용한 실험이 보여 준 것이 있습니다.

Klingbeil 과 동료들이 2024년 Computers in Human Behavior 에 실은 행동 실험에서, 조언이 AI 가 만든 것이라는 사실을 아는 것만으로 과의존이 발생했습니다. 참가자들은 그 조언이 눈앞의 맥락 정보와 배치될 때, 심지어 자기 자신의 판단과 어긋날 때도 AI 를 따랐습니다.

즉 과신은 성격 결함이 아니라 기본 반응 입니다. AI 출력물은 항상 자신 있는 문장으로 오고, 문법이 완벽하고, 형식이 깔끔합니다. 인간은 그런 신호를 신뢰의 근거로 읽도록 오랫동안 훈련되어 왔습니다. 그 훈련이 이번에는 배신합니다.

이 유형이 치르는 대가#

첫째, 잘못된 결과물이 퍼집니다. 확인 안 한 수치가 슬라이드에 들어가고, 그 슬라이드가 다른 사람의 근거가 됩니다. 오류가 발견될 때쯤이면 이미 여러 문서에 복제되어 있습니다. 위 실험이 지적한 “제3자에 대한 부정적 효과"가 이것입니다.

둘째, 판단력이 자랄 기회가 사라집니다. Part 1에서 본 Science 2026 연구를 다시 떠올려 보십시오. 경험이 적은 개발자가 AI 를 더 많이 썼는데(코드의 37% vs 숙련자 27%) 생산성 이득은 숙련자에게만 갔습니다.

이 결과의 무서운 함의는 이겁니다. 초보자에게 AI 를 더 쥐여 주는 것으로는 격차가 좁혀지지 않았습니다. 판별할 수 없는 상태에서 사용량만 늘리면, 늘어난 사용량이 이득으로 전환되지 않습니다. 연구진의 표현대로 AI 는 운동장을 자동으로 평평하게 만들지 않으며 기존 격차를 벌릴 수 있습니다.

셋째, 어느 순간 되돌리기 어려워집니다. 이 부분은 조심해서 말해야 합니다.

Gerlich 가 2025년 Societies 에 발표한 연구는 영국인 666명을 대상으로 AI 사용 빈도와 비판적 사고 점수 사이에 유의한 음의 상관 을 보고했고, 인지 오프로딩이 이를 매개한다고 분석했습니다. 젊은 층일수록 의존이 높고 점수가 낮았습니다.

다만 이 연구를 “AI 가 사고력을 떨어뜨린다"로 읽으면 안 됩니다. 상관 연구이므로 인과가 아니고, 비판적 사고가 원래 낮은 사람이 AI 를 더 쓴다는 역방향도 배제되지 않습니다. 측정도 상당 부분 자기보고에 의존합니다. (이 논문은 2025년 9월에 정정도 게재되었습니다.)

그래도 방향성만큼은 진지하게 받아들일 가치가 있습니다. 쓰지 않는 근육이 약해진다는 것은 AI 이전부터 알려진 사실입니다.

처방#

핵심 원칙은 하나입니다. 모든 것을 검증하려 하지 마십시오. 검증할 것만 정하십시오.

전부 의심하면 AI 를 쓰는 의미가 사라지고, 며칠 안에 포기하게 됩니다. 필요한 것은 선택적 검증 입니다.

처방 1 — 되돌릴 수 있는가로 나누십시오#

작업을 두 종류로 가르십시오.

	되돌릴 수 있는 일	되돌릴 수 없는 일
예	아이디어 브레인스토밍, 초안, 개인 메모, 번역 초벌	외부로 나가는 문서, 숫자가 들어간 보고, 코드 배포, 남에게 하는 조언
검증	안 해도 됩니다	반드시

되돌릴 수 있는 일에서는 마음껏 빨리 쓰십시오. 이 유형의 강점이 거기 있습니다. 검증 예산을 되돌릴 수 없는 일에 몰아주는 것 이 목적입니다.

처방 2 — 숫자·고유명사·인용문만 봅니다#

전체를 검증하는 대신 세 종류만 확인하십시오.

숫자 — 통계, 날짜, 금액, 버전
고유명사 — 사람 이름, 제품명, 논문 제목, 법령명
인용문 — “누가 이렇게 말했다”

언어 모델이 가장 그럴듯하게 틀리는 지점이 정확히 이 셋입니다. 이 글을 쓰면서도 실제로 저자명 하나를 잘못 적었다가 교차 확인으로 잡았습니다. 문장의 논리는 대개 멀쩡한데 고유명사와 숫자에서 조용히 어긋납니다.

처방 3 — 질문을 하나 바꾸십시오#

답이 이상할 때 “내가 잘못 물었나?” 대신 “이게 틀렸을 수 있나?” 를 먼저 떠올리십시오.

작은 변화 같지만 이것이 오류 귀속의 방향을 바꿉니다. 그리고 이 유형에게 가장 결정적인 한 문장입니다.

처방 4 — 틀린 사례를 수집하십시오#

AI 가 틀린 것을 발견하면 어딘가에 적어 두십시오. 메모 앱 하나면 됩니다.

목적은 AI 를 불신하는 것이 아니라 자기만의 오류 지도를 만드는 것 입니다. 몇 달 모으면 “이 도구는 이런 종류의 질문에서 흔들린다"는 감각이 생깁니다. Part 1에서 정의한 고검증형의 특징 — 상황에 따라 의심의 강도를 조절하는 능력 — 이 바로 이 지도에서 나옵니다.

꾸준함에 따른 조절#

꾸준한 편이라면 — 위 처방 1~4를 그대로 쓰십시오. 주 1회 10분씩 오류 노트를 돌아보는 루틴을 더하면 충분합니다.

쉽게 질리는 편이라면 — 처방 1과 3만 하십시오. 나머지는 버리셔도 됩니다.

특히 처방 3(질문 하나 바꾸기)은 의지력을 거의 쓰지 않으므로 이 유형에게 가장 남기 쉽습니다. 그리고 오류 노트는 별도 파일을 만들지 마십시오. 새 파일은 사흘 뒤에 잊힙니다. 대신 이미 매일 여는 곳 — 메모 앱 상단 고정, 업무 채널의 나에게 보내는 메시지 — 에 한 줄씩 붙이십시오.

② 감별하는 얼리어답터 — 가장 이득이 크고 가장 지치는 칸#

이 유형의 초상#

빠르게 도입하고 꼼꼼히 봅니다. 새 모델이 나오면 자기만의 테스트 질문 을 던져 봅니다. 답이 이상하면 어떤 종류의 질문에서 그런지 파악합니다. 출처 링크를 실제로 누릅니다.

Science 2026 연구가 말한 “이득을 가져간 쪽"이 구조적으로 이 자리입니다. 축하드립니다. 그런데 이 칸에도 고유한 실패 방식이 있습니다.

이 유형이 치르는 대가#

첫째, 검증 비용이 이득을 잡아먹습니다.

검증에는 시간이 듭니다. 그리고 이 유형은 검증하지 않아도 되는 것까지 검증하는 경향 이 있습니다. 개인 메모의 표현을 다듬는 데 출처를 확인하고, 브레인스토밍 결과를 사실 검증합니다.

어느 순간 이런 계산이 성립합니다. “이럴 바엔 내가 직접 하는 게 빠른데.” 그리고 그 계산이 실제로 맞을 때가 있습니다. 그때 이 유형은 조용히 AI 사용을 줄입니다.

둘째, 도구가 늘어나기만 합니다.

빠르게 도입하는 성향과 꼼꼼히 보는 성향이 결합하면 도구를 버리지 못합니다. 각각의 장단점을 정확히 알기 때문에 “이건 이걸 잘하고 저건 저걸 잘하니 둘 다 필요하다"가 됩니다.

결과는 구독료 명세서와, 어떤 도구에서도 깊어지지 않는 숙련도 입니다.

셋째, 번아웃이 옵니다.

이 분야는 6~12개월이면 판이 바뀝니다. 모든 새 모델을 평가하고 모든 새 기능을 시험하는 것은 취미가 아니라 부업 이 됩니다. 그리고 부업은 지칩니다.

균형 감각을 위한 한 가지 사실#

이 유형이 특히 새겨 둘 만한 사례가 있습니다.

METR 은 2025년 7월, 숙련 오픈소스 개발자들이 AI 를 쓸 때 오히려 19% 느려졌다 는 결과를 냈습니다. 널리 인용된 연구입니다.

그런데 2026년 2월, METR 자신이 후속 데이터를 내놓으며 부호가 뒤집혔다 고 밝혔습니다. 원래 코호트는 약 18% 빨라졌습니다. 그리고 METR 은 심각한 선택 편향 — 시급 50달러를 줘도 AI 없이 일하기를 거부한 개발자가 많았고, 참가자의 30~50%가 AI 가 필요한 과제를 아예 제출하지 않았습니다 — 을 이유로 실험 설계 자체를 폐기했습니다.

교훈은 “AI 가 빠르다"도 “느리다"도 아닙니다. AI 의 생산성 효과는 아직 정밀하게 측정되지 않았습니다. 그러니 이 유형이 자기 검증 루틴의 정당성을 숫자로 확인하려 애쓸 필요는 없습니다. 그 숫자는 아직 없습니다.

처방#

핵심 원칙은 하나입니다. 검증을 줄이지 말고, 검증의 배분을 바꾸십시오.

처방 1 — 검증 등급을 세 단계로 나누십시오#

이 유형의 문제는 검증을 켜고 끄는 스위치 로 다룬다는 것입니다. 다이얼로 바꾸십시오.

등급	대상	검증 방식	시간
상	외부 공개, 숫자가 근거가 되는 것, 배포 코드	1차 출처 확인, 교차 검증	무제한
중	팀 내부 공유, 참고용 정리	숫자·고유명사만 확인	5분 이내
하	개인 메모, 초안, 발상	검증 안 함	0

“하” 등급을 만드는 것이 이 처방의 핵심입니다. 검증하지 않기로 명시적으로 결정한 영역이 없으면, 이 유형은 모든 것을 “중” 이상으로 처리하게 됩니다.

처방 2 — 도구를 세 개로 제한하십시오#

주력 하나, 보조 하나, 실험용 하나. 새로운 것을 넣으려면 하나를 빼야 합니다.

실험용 슬롯을 만들어 두는 것이 중요합니다. 그래야 호기심을 억누르지 않으면서 주력 도구의 숙련도를 지킬 수 있습니다. 이 유형에게 “새 도구를 쓰지 마십시오"는 지켜지지 않는 조언입니다.

처방 3 — 평가를 배치 처리하십시오#

새 모델이 나올 때마다 즉시 평가하지 마십시오. 월 1회, 시간을 정해 놓고 몰아서 하십시오.

그리고 그때 쓸 자기만의 고정 테스트 세트 를 만들어 두십시오. 자기 업무에서 실제로 나오는 질문 5~10개면 충분합니다. 매번 즉흥적으로 평가하는 것보다 훨씬 적은 시간으로 훨씬 정확한 비교가 됩니다.

처방 4 — 검증을 위임하십시오#

모든 검증을 사람이 할 필요는 없습니다.

코드는 테스트와 린터, 타입 체커에 맡기십시오
사실 확인은 다른 모델에게 교차 질의 하십시오
자주 하는 검증은 체크리스트로 만들어 프롬프트에 넣으십시오. 출력과 함께 검증 항목을 같이 내놓게 하는 방식이 있습니다

이 유형은 검증 능력이 이미 있습니다. 부족한 것은 그 능력을 자동화하려는 발상 입니다.

꾸준함에 따른 조절#

꾸준한 편이라면 — 처방 1~4를 전부 쓰십시오. 다만 분기에 한 번은 “지난 3개월간 검증해서 실제로 오류를 잡은 비율” 을 돌아보십시오. 그 비율이 아주 낮은 영역이 있다면 등급을 내려도 됩니다.

쉽게 질리는 편이라면 — 처방 2(도구 3개 제한)를 최우선으로 하십시오. 이 유형에서 쉽게 질리는 성향이 결합하면 도구를 계속 갈아타면서 검증 루틴만 남는 최악의 조합이 나옵니다. 도구가 바뀌면 축적된 감각이 초기화되는데, 검증 습관은 남아서 비용만 계속 나갑니다.

그리고 처방 3의 월 1회 평가는 캘린더에 반복 일정으로 박아 두십시오. 기억에 의존하면 안 하게 되거나, 반대로 매일 하게 됩니다.

두 유형에게 공통으로 드리는 말#

빠르게 도입하는 사람들이 자주 놓치는 것이 하나 있습니다.

속도는 이 두 유형의 자산이지만, 자산이라는 이유로 방치하면 부채가 됩니다.

①은 속도가 검증을 밀어낸 경우이고, ②는 검증이 속도를 잡아먹은 경우입니다. 방향은 반대지만 원인은 같습니다. 둘 다 “얼마나 확인할지"를 명시적으로 정하지 않고 그때그때 반응했습니다.

Part 1에서 인용한 옥스퍼드·베를린 연구에서 Naïve Pragmatists 와 Cautious Adopters 를 가른 것이 이 지점이었습니다. 전자는 신뢰가 기본값이었고, 후자는 매번 이득과 위험을 저울질했습니다. 저울질은 성격이 아니라 절차입니다. 절차는 만들 수 있습니다.

정리#

① 순진한 실용가

과신은 성격 결함이 아니라 기본 반응입니다. AI 라는 사실을 아는 것만으로 과의존이 발생한다는 실험 결과가 있습니다.
가장 큰 위험은 틀린 결과물의 확산과, 판단력이 자랄 기회를 잃는 것 입니다.
처방은 선택적 검증 입니다. 되돌릴 수 없는 일에만, 숫자·고유명사·인용문만 확인하십시오.
가장 값싸고 효과가 큰 한 가지: “내가 잘못 물었나?” 대신 “이게 틀렸을 수 있나?”

② 감별하는 얼리어답터

구조적으로 가장 유리한 자리입니다. 다만 검증 비용, 도구 과잉, 번아웃 이라는 고유한 실패 방식이 있습니다.
처방은 검증을 줄이는 것이 아니라 등급을 나누는 것 입니다. 특히 검증하지 않기로 정한 “하” 등급을 만드십시오.
도구는 세 개(주력·보조·실험용)로 제한하고, 새 모델 평가는 월 1회 배치 처리 하십시오.
검증 능력은 이미 있습니다. 부족한 것은 그것을 자동화하려는 발상 입니다.

Part 3에서는 아래쪽 두 칸 — ③ 신중한 후발주자와 ④ 떠밀린 사용자 — 를 다루고, 네 유형 모두에게 적용되는 공통 원칙으로 마무리하겠습니다.

References#

2026년 자료

Daniotti, S., Wachs, J., Feng, X., & Neffke, F. (2026, January 22). Who is using AI to code? Global diffusion and impact of generative AI. Science. doi:10.1126/science.adz9311 — 수치는 연구 수행 기관인 Complexity Science Hub 공식 보도자료로 확인했습니다.
METR. (2026, February 24). We are Changing our Developer Productivity Experiment Design. https://metr.org/blog/2026-02-24-uplift-update/
Gerling, C., Teubner, T., & Braesemann, F. (2026, January 28). Who uses general-purpose AI? A typology of ChatGPT early adopters. Electronic Markets. doi:10.1007/s12525-025-00853-0

비교·배경 자료 (발표 연도를 함께 적습니다)

Klingbeil, A., Grützner, C., & Schreck, P. (2024). Trust and reliance on AI — An experimental study on the extent and costs of overreliance on AI. Computers in Human Behavior, 160, 108352. doi:10.1016/j.chb.2024.108352 — 2024년 자료입니다.
Gerlich, M. (2025). AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking. Societies, 15(1), 6. doi:10.3390/soc15010006 — 상관 연구이며 인과를 입증하지 않습니다. 자기보고 기반이고 2025년 9월 정정이 게재되었습니다.
METR. (2025, July 10). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. — 위 2026년 후속 발표로 결론이 뒤집힌 연구입니다. 비교를 위해 함께 적습니다.