# AI 시대의 비판적 사고 (Critical Thinking) > Clean Markdown view of GeekNews topic #24743. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24743](https://news.hada.io/topic?id=24743) - GeekNews Markdown: [https://news.hada.io/topic/24743.md](https://news.hada.io/topic/24743.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-01T10:31:01+09:00 - Updated: 2025-12-01T10:31:01+09:00 - Original source: [addyo.substack.com](https://addyo.substack.com/p/critical-thinking-during-the-age) - Points: 48 - Comments: 0 ## Summary AI가 코드를 짜고 설계를 제안하는 지금, 이 글은 **비판적 사고를 실제 작업 과정에서 어떻게 구현할 수 있는지**를 구체적으로 보여줍니다. **Who·What·Where·When·Why·How** 여섯 가지 질문을 통해 문제를 단계적으로 점검하고, AI의 답변을 “그럴듯한 초안”이 아닌 **검증해야 할 대상**으로 다루는 방식을 설명합니다. 특히 **문제 정의·맥락 파악·근거 검증** 같은 단계가 왜 사람의 역할로 남아 있는지, 그리고 이것이 어떻게 팀의 품질을 결정짓는지 사례와 함께 풀어냅니다. 최근 이런 주제의 글이 더 자주 보이는 건, 빠르게 변하는 흐름 속에서 우리가 **다시 균형을 찾아보려는 움직임**이 커지고 있어서일지도 모릅니다. ## Topic Body - AI가 코드와 설계, 답변을 만들어주는 환경에서도 **올바른 질문을 던지고 가정을 의심하는 비판적 사고**가 엔지니어와 팀의 성과를 좌우하는 핵심 역량임 - 문제 해결 전 과정에서 **Who·What·Where·When·Why·How** 여섯 가지 질문을 활용해 사람·문제·맥락·타이밍·원인·실행 방식을 체계적으로 점검해야 함 - AI의 답변은 **인턴이 제안한 초안처럼 검증 대상**으로 다루고, 실제 문제 정의·증거 수집·맥락 파악·원인 분석·의사소통은 사람이 책임지는 구조가 필요함 - 시간 압박·편향·그럴듯한 AI 답변 때문에 **성급한 결론과 땜질식 해결책**으로 흐르기 쉬우며, 이를 막기 위해 5 Whys·실험·데이터 검증 등 **증거 기반 사고**를 반복해야 함 - 비판적 사고는 **겸손한 호기심과 증거를 중시하는 팀 문화**에서 강화되며, AI가 아무리 발전해도 “옳은 문제를, 옳은 이유로, 옳은 방식으로 푸는 것”은 여전히 인간의 고유한 장점임 --- ### AI 시대 비판적 사고 개요 - AI가 코드·디자인·답변을 만들어주는 시대에 **사람의 비판적 사고 능력**이 예전보다 더 중요해지고 있음 - 자동화가 아무리 정교해져도, 올바른 질문을 던지고 가정을 의심하며 독립적으로 사고하는 역할은 사람 몫으로 남아 있음 - 잘못된 질문과 잘못 정의된 문제 위에 쌓인 AI 출력은 프로젝트를 더 빠르게 잘못된 방향으로 밀어붙이는 결과로 이어질 수 있음 - 비판적 사고를 위해 **Who·What·Where·When·Why·How** 프레임워크를 사용해 구체적인 실천 지침을 제시함 - 각 질문은 문제 정의, 이해관계자, 맥락, 타이밍, 원인 분석, 실행·커뮤니케이션 방법을 점검하는 도구로 활용됨 - AI 보조 환경에서 이 여섯 가지를 놓치지 않는 것이 프로젝트 실패를 줄이고 다운스트림 문제를 예방하는 핵심임 ### tl;dr: AI 팀을 위한 비판적 사고 체크리스트 - **Who:** AI를 **전지적 존재가 아닌 검증이 필요한 입력**으로 간주하고, 누가 답을 내고 있는지 항상 확인해야 함 - LLM의 답변을 사람의 견해와 동일시하지 않고, 출처와 책임 소재를 분리해 보는 시각이 필요함 - **What:** 솔루션으로 달려가기 전에 **진짜 문제 정의와 성공 기준**을 분명히 해야 함 - 표면적인 요구사항 대신, 사용자 경험과 데이터를 바탕으로 실제로 풀어야 할 문제를 명확히 규정해야 함 - **Where:** 해결책이 적용될 **맥락과 환경(샌드박스·프로덕션·사용자 기기 등)** 을 고려해야 함 - 한 환경에서 잘 작동하는 해결책이 다른 환경에서 부작용을 낳을 수 있음을 항상 염두에 두어야 함 - **When:** **간단한 휴리스틱으로 충분한 상황과 깊이 있는 분석이 필요한 상황**을 구분해야 함 - 응급 땜질과 근본 원인 분석의 시점을 나누어, 시간 제약 속에서도 최소한의 엄밀함을 확보해야 함 - **Why / How:** **5 Whys로 근본 원인**을 추적하고, **의견이 아닌 데이터·증거** 중심으로 커뮤니케이션해야 함 - 주장보다 근거, 직감보다 실험·측정 결과를 우선하는 태도가 필요함 ### Who: 참여 주체·책임·영향 범위 - 문제를 정의하고 해결에 참여하는 **사람과 관점의 구성(누가 포함되고 누가 빠져 있는지)** 이 비판적 사고의 출발점임 - 엔지니어·PM·사용자·도메인 전문가 등 이해관계자를 파악하고, 의사결정 과정에 적절히 포함해야 함 - 문제는 대부분 여러 팀과 사용자에게 영향을 미치므로, “누구와 상의해야 하는가, 누구에게 알려야 하는가”를 먼저 묻는 태도가 필요함 - 한 목소리로만 의견이 모이는 **groupthink(집단사고)** 위험을 줄이기 위해 다양한 시각을 의도적으로 끌어들여야 함 - 반대 의견이나 다른 관점을 가진 사람을 배제하면, 데이터와 가정의 타당성 검증 없이 정답처럼 굳어지는 위험이 커짐 - 외부 시각이나 팀 밖 사람을 불러 “새 눈”으로 문제를 보게 하는 것도 객관성을 높이는 방법임 - AI가 등장한 뒤에는 **“누구의 답인가, 인간인가 AI인가”** 를 분리해서 보는 시각이 필수임 - LLM은 통계적 엔진에 불과하므로, **“누가 말했다”보다 “무엇을 근거로 말했는가”** 를 따져야 함 - AI 코드를 인턴의 코드처럼 취급해, 리뷰·테스트·맥락 적합성 검증을 사람이 책임져야 함 - 최종적으로는 **책임과 영향 범위(누가 책임지고, 누가 영향을 받는가)** 까지 포함해 생각해야 함 - 급한 패치가 당장은 관리자 요구를 충족해도, 이후 유지보수·장애 대응 부담은 다른 엔지니어나 사용자에게 돌아올 수 있음 - API 변경이 모바일 앱·다른 마이크로서비스에 미치는 영향처럼, “누가 이 결정의 결과를 떠안게 되는가”를 항상 함께 고려해야 함 ### What: 진짜 문제 정의와 증거 수집 - 비판적 사고의 핵심은 **“무엇이 실제 문제인가”를 정확히 정의하는 일**임 - “AI 요약 기능을 넣자” 같은 요청이 오면, 먼저 목표가 데이터 이해 향상인지, 피로도 감소인지, 다른 것인지를 따로 물어야 함 - 사용자가 느끼는 어려움이 데이터 과잉인지, 시각화 부족인지, 설명 부재인지에 따라 솔루션이 전혀 달라질 수 있음 - Harvard Business Review 등에서 강조하듯 **문제 정의에 충분한 시간을 쓰면 잘못된 문제에 자원을 쓰는 위험**을 줄일 수 있음 - 요구사항과 성공 기준을 명시적으로 적고, “어떤 상태가 되면 문제가 해결된 것인가”를 합의하는 과정이 필요함 - “문제 해결 모드”로 바로 뛰어드는 **plunging-in bias(성급하게 뛰어드는 편향)** 을 의식적으로 경계해야 함 - 증상보다 구체적 사실을 모으는 **증거 기반 문제 정의**가 중요함 - “서비스가 느리다”라는 말은 모호하므로, 어느 페이지·어떤 쿼리·어떤 요청이 느린지 데이터를 통해 좁혀야 함 - “무엇이 느린가, 무엇이 언제부터 달라졌는가, 무엇이 최근에 변경되었는가” 같은 질문으로 로그·메트릭 등을 확인해야 함 - 솔루션이나 결론에 대해 **“이 결론을 뒷받침하는 증거는 무엇인가”** 를 반복해 확인해야 함 - AI가 null pointer를 원인으로 지목하면, 로그·테스트·재현 실험으로 이를 직접 검증해야 함 - 성능 개선이라고 주장할 때는 여러 환경·여러 실행에서 일관된 지표 향상이 있는지 확인해야 함 - LLM의 답변은 대부분 **그럴듯해 보이지만, 정확성 보장은 없는 가설**로 다루어야 함 - 사람은 “충분히 그럴듯해 보이는 답”을 들으면 추가 탐색을 멈추는 경향이 있어, 이 조합이 특히 위험함 - 비판적 사고는 AI·동료·본인의 아이디어를 모두 “테스트해야 할 가설”로 취급하고, **틀릴 수도 있다는 전제**에서 시작함 ### Where: 맥락·환경·범위 인식 - 해결하려는 문제와 솔루션이 **어디에서 발생하고, 어디에 적용되는지(맥락)** 를 파악하는 것이 중요함 - 특정 마이크로서비스의 CPU 스파이크가 전체 시스템 장애로 오인되는 일을 막기 위해, 이슈가 발생하는 정확한 위치를 찾아야 함 - 사용자 스마트폰·에지 디바이스·클라우드 서버 등 실행 환경에 따라 같은 코드도 전혀 다른 제약 조건을 갖게 됨 - 디버깅 시에는 **요청 흐름·컴포넌트 간 경계를 따라 “어디에서 실패가 발생했는가”** 를 좁혀 가야 함 - 클라이언트·API 게이트웨이·백엔드·데이터베이스 중 어떤 지점에서 문제가 생기는지 로그와 모니터링으로 분리해야 함 - 기능 아이디어 논의 시에도, 사용자 여정 중 어느 단계에 영향을 주는지, 사용 빈도가 어느 구간에 집중되는지 같이 보는 것이 필요함 - 실험과 배포에서도 **어디에서 시험해 볼 것인가**가 중요한 결정 요소임 - 스테이징·사내용 환경·프로덕션 일부 트래픽 등 실험 위치에 따라 얻을 수 있는 신뢰도와 리스크가 달라짐 - 실사용자 일부에 A/B 테스트로 노출하면 실세계 이슈를 빨리 발견할 수 있지만, 영향 범위를 제한하는 방어 장치도 필요함 - “어디에서 부작용이 생길 수 있는가, 어디까지 파급될 수 있는가”를 미리 상상하는 것이 숙련된 엔지니어의 특징임 - 공용 라이브러리 변경 시, 이를 사용하는 다른 서비스·팀을 목록화하고, 릴리즈 전에 알림·테스트 계획을 세워야 함 - 특정 모듈의 최적화가 다른 모듈의 복잡도 증가·데이터 포맷 변경을 요구하는지 등 시스템 전반의 파장을 함께 검토해야 함 ### When: 시간 축과 깊이 선택 - 문제 발생 시점·행동 시점 등 **“언제”에 대한 정보**가 원인 분석의 핵심 단서가 됨 - “마지막으로 정상 동작하던 때가 언제인지, 그 이후 무엇이 변경되었는지”를 타임라인으로 정리하면 원인을 빠르게 좁힐 수 있음 - 새 배포·야간 배치·설정 변경 등 특정 시간대 이벤트와 장애 발생 시간을 연결해 보는 습관이 중요함 - 의사결정에서 **언제 깊게 파고들고, 언제 휴리스틱으로 충분한지**를 구분하는 것이 비판적 사고의 한 축임 - 모든 문제에 완전한 분석을 시도하면 일정과 리소스를 감당할 수 없으므로, 리스크와 영향도에 따라 분석 깊이를 조절해야 함 - 심야 장애 대응에서는 서비스 재시작 같은 단기 완화 조치로 복구한 뒤, 일과 시간에 루트 원인을 탐구하는 방식이 현실적인 전략임 - NASA 사례에서처럼 **스트레스와 시간 압박 속에서 인간의 판단 오류 가능성이 급격히 높아짐**이 지적됨 - 빠른 판단이 필요한 상황일수록, 오히려 “어디까지는 임시 조치, 어디부터는 반드시 재검토해야 하는 지점인지”를 미리 표시해두는 것이 중요함 - “지금은 임시 해결이고, 나중에 반드시 원인 분석과 근본 조치를 한다”는 메모·티켓을 남겨두는 것만으로도 장기적인 품질에 도움이 됨 - 제한된 시간 안에서 엄밀함을 유지하기 위해 **우선순위와 삼각 측량(트리아지)** 을 활용해야 함 - 가장 위험한 가정을 먼저 시험하고, 덜 중요한 결정은 이후로 미루는 방식으로 시간을 배분해야 함 - 새 기능 설계에서 알고리듬의 타당성과 리스크가 더 크다면, UI 세부보다 알고리듬 검증에 시간을 먼저 쓰는 식의 선택이 필요함 - 비판적 사고는 **“도움을 청할 타이밍”과 “멈추고 재고할 타이밍”** 을 인식하는 능력과도 연결됨 - 일정 시간 이상 진전이 없으면 다른 사람의 시선을 끌어들이고, 스프린트 마감·릴리즈 전 등 의도적으로 멈춰 검토하는 지점을 설정해야 함 - 분석 마비와 성급한 결론 사이에서, 현재 결정에 충분한 정보가 있는지 스스로 체크하는 습관이 중요함 ### Why: 동기·원인·근거 파고들기 - “왜 이 일을 하는가”를 반복해서 묻는 것은 **무의미한 유행·모방을 걸러내고, 실질적 가치에 집중하는 필터 역할**을 함 - 새로운 AI 도구 도입·기능 추가 요청 등에서, 경쟁사 따라잡기인지, 실제 사용자 문제 해결인지 명확히 구분해야 함 - “왜 중요한가”에 대한 설득력 있는 답이 있어야, 구현 과정에서 수많은 세부 의사결정이 일관성을 가질 수 있음 - 문제가 발생했을 때는 **5 Whys 기법**으로 표면적 원인에서 더 깊은 원인까지 내려가는 과정이 중요함 - 모델 정확도 하락을 예로 들면, 데이터 분포 변화·새 데이터 소스 추가·검증 부재·모니터링 부족 등 연쇄 원인을 한 단계씩 추적해야 함 - 최종 원인이 데이터 파이프라인 검증 부족·모니터링 부재라면, 재학습만으로는 문제를 근본적으로 해결할 수 없다는 점이 드러남 - “왜” 질문에서 인간은 **확증 편향·성급한 결론**에 빠지기 쉬움 - 예전에 겪은 메모리 누수처럼 익숙한 원인에 생각이 고정되면, 새로운 설정 변경·데이터 변경 같은 다른 가능성을 무시하기 쉬움 - 처음 떠오른 설명에 안주하지 않도록, 스스로 “다른 가능한 원인이 있는가, 이를 부정하는 증거는 없는가”를 묻는 태도가 필요함 - 과거 기업 사례처럼 **잘못된 “왜” 이해**는 시장점유율 하락·전략 실패를 오랫동안 고치지 못하게 만드는 요인이 될 수 있음 - 외부 요인 탓으로만 돌리고 내부 프로세스·품질·문화 문제를 보지 못하면, 엉뚱한 처방을 반복하게 됨 - 좋은 엔지니어는 **겸손한 호기심으로 “왜”를 묻고, 자신의 가정이 틀릴 수 있음을 열어두는 태도**를 유지함 - 아이디어가 성공할 것이라고 믿을 때도 “왜 그렇게 생각하는지, 데이터인지 직감인지”를 분리해서 본다음 검증 방향을 잡음 - 의사결정 후에는 이유를 문서화·공유해, 나중에 상황이 바뀌었을 때 근거부터 다시 점검할 수 있게 함 ### How: 실천 방법과 커뮤니케이션 - 비판적 사고를 일상에서 실천하는 방법은 **질문 방식·증거 검증·커뮤니케이션 구조화** 세 가지 축으로 정리됨 - 막연한 “좋냐·나쁘냐” 대신, “어떤 사용자 니즈를 어떻게 다루며, 어디에서 실패할 수 있는가” 같은 구체적·개방형 질문을 던져야 함 - 알고 있는 것과 모르는 것을 목록으로 분리하고, 모르는 것을 어떻게 실험·측정할지 계획하는 습관이 중요함 - 증거를 다룰 때는 **대안 해석 가능성·편향 유입 여부**를 함께 확인해야 함 - 한 번의 성능 테스트 결과가 우연인지 반복 가능한지, 다른 지표와 모순되지는 않는지 교차 검증해야 함 - 자신의 이론을 뒷받침하는 데이터뿐 아니라, 반박할 수 있는 데이터도 일부러 찾는 태도가 필요함 - 팀 차원에서는 **프리모텀(premortem)** 같은 기법으로 미리 실패 시나리오를 가정해 보는 방식도 소개됨 - 프로젝트가 실패했다고 가정하고 그 이유를 적어보면, 계획 단계에서 간과했던 리스크와 숨은 가정을 드러낼 수 있음 - 해결책을 전달할 때는 **문제 정의(What·Why) → 제안 솔루션(How) → 근거 데이터·가정** 순서로 논리를 구성하는 것이 효과적임 - 전제와 트레이드오프를 명시하면, 다른 사람들이 아이디어를 검증·보완하기 쉬워지고, 스스로도 논리의 구멍을 발견하기 쉬움 - “페이지 로드 시간이 대시보드 기준 평균 25% 개선되었다”처럼 **의견보다 계량적 사실**을 우선 제시하는 태도가 신뢰를 높임 - 비판적 사고가 잘 작동하는 환경에서는 **질문과 반론을 환영하는 커뮤니케이션 문화**가 형성됨 - 제안 뒤에 “이 논리에서 빠진 부분이 없는지, 우려되는 점이 있는지”를 동료에게 적극적으로 물으며 아이디어를 다듬음 - 일방적 발표가 아니라, 여러 사람이 함께 논리를 검증하는 과정 자체가 솔루션의 품질을 끌어올리는 장치가 됨 - 개인 차원에서는 **회고와 학습을 통한 지속적인 사고 개선**이 중요함 - 서둘러 내린 결정으로 버그가 생겼다면, 이후 “어디서 무엇을 놓쳤는지, 다음에는 무엇을 다르게 할지”를 정리하는 미니 회고를 수행해야 함 - 다른 회사의 포스트모텀·인지 편향 자료를 읽으며, 미래에 피해야 할 사고 함정을 미리 학습하는 것도 도움이 됨 ### 결론: 인간 고유의 장점으로서의 비판적 사고 - AI 활용도가 높아질수록, **비판적 사고는 선택이 아니라 필수 역량**으로 자리 잡고 있음 - Who·What·Where·When·Why·How를 통해 사람·문제·맥락·타이밍·원인·실행 방식을 체계적으로 점검해야 함 - 건강한 팀 문화에서는 **독립적인 사고와 질문하는 태도**가 당연한 것으로 받아들여짐 - “이게 진짜 해결책인지, 땜질인지”, “사용자가 정말 이 기능을 원하는지”, “데이터가 정말 개선을 보여주는지”를 누구나 물어볼 수 있어야 함 - 비판적 사고는 **빠른 땜질식 해결책의 유혹**에서 팀을 보호하는 역할을 함 - 당장 문제를 덮는 대신, 근본 원인을 확인하고 검증한 뒤 행동하는 것이 장기적으로 시간과 비용을 절약하는 길임 - AI와 자동화가 반복 작업과 초안을 담당하는 시대에도, **“옳은 문제를 옳은 이유로 옳은 방식으로 푸는 일”은 인간의 역할**로 남아 있음 - **겸손한 호기심과 증거 중심 사고**를 유지하는 팀이 **AI 시대에도 꾸준히 좋은 결과를 내는 팀**이 될 것 ## Comments _No public comments on this page._