Claude Code로 반나절 걸릴 스크립트를 빠르게 만든 뒤 찝찝함이 남은 적이 있다. 실행 결과는 정상인데 내가 데이터 흐름을 설명하지 못했다. 다음 오류가 나면 로그를 어디서 확인할지도 몰랐다. 작업 시간은 줄었지만 코드에 대한 내 통제력도 약해졌다.
그 경험만으로 AI가 사고력을 떨어뜨린다고 단정할 수는 없다. 생성형 AI와 비판적 사고를 다룬 연구마다 과제, 참여자와 측정 방식이 다르다. 연구 결과는 사용 금지 규칙보다 작업 순서를 설계하는 자료에 가깝다. 나는 AI 사용량을 세지 않고 가설, 검증과 설명이 결과물에 남았는지 확인한다.
Microsoft 연구가 말한 것과 말하지 않은 것
Microsoft Research와 Carnegie Mellon 연구진은 생성형 AI를 주기적으로 사용하는 지식 노동자 319명의 자기보고 사례를 분석했다. 참여자들은 결과 품질을 확인할 때 비판적 사고를 주로 사용했고, AI에 대한 신뢰가 높을수록 사고 노력은 낮아지는 경향을 보였다. 자기 능력에 대한 확신이 높을수록 비판적 사고가 늘어나는 경향도 있었다.
이 연구는 AI가 지능을 떨어뜨린다는 인과 실험이 아니다. 참여자가 실제 업무 사례를 회고한 설문이고, 사고 노력도 자기보고 값이다. 직종과 과제에 따른 차이를 하나의 수치로 압축하기도 어렵다. 나는 이 결과를 AI 사용량과 사고력을 직접 연결하는 증거로 쓰지 않는다. AI를 신뢰할수록 검증을 건너뛸 가능성이 있으니 검토 시점을 작업 절차에 넣어야 한다는 신호로 읽는다.
MIT 사전 논문을 과장하지 않기
MIT Media Lab 연구진의 Your Brain on ChatGPT는 에세이 작성에서 LLM, 검색엔진, 도구 없는 조건을 비교하고 EEG와 기억·소유감 지표를 살폈다. 첫 세 세션에는 54명이 참여했고 네 번째 세션에는 18명이 참여했다. 연구팀 페이지는 2025년 공개 당시 동료평가를 거치지 않은 사전 논문이며 결과를 예비적으로 다뤄야 한다고 명시한다.
특정한 에세이 과제와 작은 표본에서 나온 결과를 코딩, 조사와 모든 학습 활동으로 일반화할 수는 없다. EEG 차이를 지능 저하나 뇌 손상으로 표현해서도 안 된다. 이 연구에서 내가 가져온 실무 가설은 좁다. 완성된 문장을 먼저 받는 작업 순서가 회상과 소유감에 영향을 줄 수 있으니, 중요한 과제에서는 내 생각을 먼저 기록한다.
작업에 남기는 여섯 가지 습관
1. 프롬프트 전에 가설을 적는다
조사를 시작하기 전에 내가 아는 사실, 추정과 모르는 점을 세 줄로 구분한다. 코딩 과제라면 예상되는 데이터 흐름과 실패 지점을 적는다. 이 기록은 정답을 맞히기 위한 시험지가 아니다. AI가 제시한 관점에 내 판단이 그대로 끌려가지 않도록 기준점을 만드는 장치다.
확인한 사실: 결제 콜백은 중복 수신될 수 있다.
현재 추정: 주문 생성이 멱등하지 않아 중복 행이 생긴다.
모르는 점: 재시도 주체와 최대 재시도 횟수.
AI 답변을 받은 뒤 처음 기록과 비교하면 새로 배운 내용과 근거 없이 바뀐 판단이 드러난다.
2. 주장마다 확인 방법을 붙인다
주장의 종류에 따라 확인 수단이 달라진다. 라이브러리 동작은 공식 문서와 최소 재현 코드로 확인한다. 서비스 장애 원인은 로그, 메트릭과 배포 이력으로 확인한다. 시장 수치는 원본 보고서의 조사 시점, 표본과 정의를 함께 읽는다.
초안 옆에는 출처 URL만 붙이지 않고 어떤 문장을 뒷받침하는지 기록한다. 실행 결과에는 명령어, 입력 조건과 날짜를 남긴다. 출처가 오래됐거나 표본이 좁으면 그 제약도 본문에 쓴다. 확인할 수 없는 문장은 사실처럼 단정하지 않고 가설 상태로 둔다.
3. 반례와 적용 경계를 찾는다
AI에게 찬성 근거를 더 달라고 하면 이미 선택한 방향이 강화되기 쉽다. 나는 다음 요청에서 반례, 실패 조건과 누락된 전제를 따로 받는다. 제안한 캐시가 데이터 정합성을 깨뜨리는 조건, 새 자동화가 수동 처리보다 느려지는 거래량, 설문 결과를 적용하기 어려운 직군처럼 경계를 구체화한다.
반례를 받은 뒤에도 사람이 우선순위를 정한다. 가능성이 낮고 피해가 작은 실패까지 모두 막으면 설계가 무거워진다. 발생 가능성, 영향 범위, 탐지 시간과 복구 비용을 표로 놓고 처리 순서를 정한다.
4. 결과를 내 말로 설명한다
코드 리뷰에서 diff를 외울 필요는 없다. 입력이 어떤 경로로 바뀌는지, 실패 시 무엇이 남는지, 배포를 어떻게 되돌리는지 설명할 수 있어야 한다. 설명이 막히는 부분에는 테스트를 추가하거나 코드를 더 작은 단위로 나눈다.
문서도 같은 기준을 쓴다. 핵심 주장을 세 문장으로 다시 쓰고, 숫자의 분모와 기간을 말할 수 있는지 확인한다. AI가 쓴 표현을 조금 다듬는 수준으로 끝내면 이해 여부가 드러나지 않는다. 빈 화면에서 요약한 뒤 원문과 대조하면 빠진 조건을 찾기 쉽다.
5. 직접 처리한 표본을 남긴다
새로운 업무를 처음부터 전부 자동화하면 입력의 예외와 결과의 품질 기준을 배우기 어렵다. 초기 표본 몇 건은 손으로 처리하면서 판단 과정을 기록한다. 고객 문의라면 분류가 애매한 사례, 답변에 필요한 시스템과 승인 조건을 수집한다. 데이터 정제라면 잘못된 날짜, 중복 식별자와 결측값을 직접 본다.
표본 수는 업무 위험에 맞춘다. 되돌리기 쉬운 개인용 스크립트는 두세 건으로도 충분할 수 있다. 금전, 권한이나 고객 데이터가 걸린 자동화는 더 넓은 표본과 별도 검토가 필요하다. 직접 처리한 사례는 자동화 테스트와 평가 데이터의 출발점이 된다.
6. 주간 회고에서 판단 품질을 측정한다
처리 시간만 보면 AI가 만든 오류를 수정한 시간이 숨는다. 나는 한 주에 한 번 AI 초안 채택률, 근거 없는 주장 수, 재작업 시간과 사람이 발견한 중대 오류를 기록한다. 개별 수치보다 추세와 원인을 본다.
| 기록 항목 | 확인하려는 것 |
|---|---|
| 첫 초안 채택률 | 과제가 충분히 구체적이었는지 |
| 출처 교체 횟수 | 검색 결과의 품질이 낮았는지 |
| 검토 후 발견된 오류 | 평가 기준이나 테스트가 비었는지 |
| 재작업 시간 | 자동화가 실제 시간을 줄였는지 |
| 직접 설명하지 못한 변경 | 이해하지 못한 결과를 넘겼는지 |
오류가 반복되면 프롬프트 문구만 고치지 않는다. 입력 자료, 권한, 테스트, 리뷰 순서 중 어디가 비었는지 찾아 작업 구조를 수정한다.
과제 위험에 따라 AI의 역할을 나눈다
반복 서식, 파일 변환과 이미 이해한 검사는 적극적으로 자동화한다. 새로운 개념을 배우거나 되돌리기 어려운 결정을 내릴 때는 사람이 문제 정의와 검증을 맡는다. 업무를 다음 세 단계로 나누면 검토 강도를 정하기 쉽다.
| 단계 | AI가 맡는 일 | 사람이 남기는 일 |
|---|---|---|
| 낮은 위험 | 형식 변환, 초안 정리, 반복 검사 | 표본 확인 |
| 중간 위험 | 대안 생성, 코드 초안, 자료 분류 | 출처 검증, 테스트, 승인 |
| 높은 위험 | 정보 검색, 시나리오 제안 | 문제 정의, 최종 판단, 이중 검토 |
모든 수고가 학습으로 이어지지는 않는다. 이미 이해한 반복 작업까지 손으로 붙잡으면 중요한 판단에 쓸 시간이 줄어든다. 내가 남기려는 마찰은 가설 작성, 경계 확인, 설명과 검증처럼 판단을 훈련하는 구간이다.
AI 사용량만으로 사고력이 늘거나 줄었다고 말하기는 어렵다. 내 작업에서는 여섯 가지 기록이 더 유용한 기준이 됐다. 가설이 있었는지, 출처를 확인했는지, 반례를 찾았는지, 결과를 설명했는지, 직접 처리한 표본이 있는지, 오류를 다음 절차에 반영했는지를 본다. 이 기록이 남아야 빠른 초안이 내 지식과 재사용 가능한 작업 방식으로 이어진다.