AI 시대의 비판적 사고 : 5W1H를 통한 탐구

---

AI가 코드를 생성하고, 아이디어를 설계하며, 요청에 따라 그럴듯한 답변을 내놓는 시대에, 인간의 비판적 사고(critical thinking)에 대한 필요성은 그 어느 때보다 커졌습니다. 아무리 똑똑한 자동화 기술이라도, 현재로서는 올바른 질문을 던지고, 가정에 이의를 제기하며, 독립적으로 사고하는 능력을 대체할 수는 없습니다.

이 에세이에서는 소프트웨어 엔지니어와 기술 팀에게 비판적 사고 기술이 왜 중요한지, 고전적인 프레임 워크인 "누가(Who), 무엇을(What), 어디서(Where), 언제(When), 왜(Why), 어떻게(How)"를 사용하여 실용적인 지침을 통해 탐구합니다.

---

요약(tl;dr): AI 증강 팀을 위한 비판적 사고 체크리스트

• Who(누가): AI를 예언자(oracle)로 맹신하지 마십시오. 결과를 검증하십시오.

• What(무엇을): 해결책으로 서둘러 달려가기 전에 진짜 문제를 정의하십시오.

• Where(어디서): 맥락(Context)이 왕입니다. 샌드박스(테스트 환경)에서 작동하는 수정 사항이 프로덕션(운영 환경)에서는 깨질 수 있습니다.

• When(언제): 빠른 휴리스틱(우선순위 분류/Triage)을 사용할 때와 깊이 있는 분석(근본 원인 파악)을 할 때를 구별하십시오.

• Why(왜): "5 Whys(5가지 왜)" 기법을 사용하여 근본적인 원인을 파헤치십시오.

• How(어떻게): 의견이 아닌 증거와 데이터로 소통하십시오.

우리는 이 질문 카테고리들이 AI가 보조하는 세상의 의사결정에 어떻게 적용되는지, 구체적인 예시와 흔한 함정을 통해 깊이 있게 살펴볼 것입니다. 목표는 겸허한 호기심과 증거 기반의 추론이 어떻게 프로젝트를 올바른 궤도로 유지하고 추후 발생할 문제를 예방할 수 있는지 보여주는 것입니다.

---

Who(누가): 적절한 사람과 관점을 참여시키십시오

문제를 정의하거나 해결하는 데 누가 관여하고 있습니까? 기술 프로젝트에서 비판적 사고는 **누가(Who)**인지 식별하는 것에서 시작합니다.

이는 이해관계자(예: 엔지니어, 제품 관리자, 사용자, 도메인 전문가)가 누구인지 알고, 올바른 사람들이 의사결정에 참여하도록 하는 것을 의미합니다. 예를 들어 엔지니어링 문제는 고립된 상태에서 해결되는 경우가 드뭅니다. 사용자에게 영향을 미치고 종종 여러 팀에 걸쳐 있습니다. 비판적 사고를 하는 사람은 이렇게 묻습니다. "누구에게 자문을 구하거나 알려야 하는가? 누가 관련 전문 지식이나 다른 관점을 가지고 있을까?" 다양한 관점을 포함하는 것은 필수적입니다.

그렇지 않으면 팀은 모든 구성원이 같은 아이디어로 수렴하고 반대 의견이 침묵당하는 **집단 사고(Groupthink)**에 빠질 위험이 있습니다. 집단 사고는 팀원들이 자신들의 견해가 좋은 데이터나 건전한 가정에 기초하고 있는지 의심하지 않은 채, 서로 일치된 견해만을 검증하게 만들어 팀을 속일 수 있습니다. 이에 대응하기 위해 유능한 팀은 모든 구성원의 질문을 장려하고, 새로운 시각을 위해 외부인을 참여시키기도 합니다. 요컨대, 누가 회의실에 있는지(그리고 누가 없는지)가 기술적 의사결정의 객관성을 좌우할 수 있습니다.

우리는 누구의 말을 들어야 합니까 – 인간인가 AI인가? AI 어시스턴트의 시대에 우리는 답변이 누구로부터 나오는지도 비판적으로 평가해야 합니다. 그것은 대규모 언어 모델(LLM)의 출력입니까, 아니면 경험 많은 동료의 말입니까? AI는 권위 있게 들리는 답변을 자신 있게 제공할 수 있지만, 그것이 통계적 엔진이라는 점을 기억해야 합니다. 누가 "말했는지"는 중요합니다.

비판적 사고를 하는 사람은 AI의 출력을 예언이 아니라 검토해야 할 또 하나의 입력값으로 취급합니다. 어떤 존재(AI 같은)가 그럴듯하게 들리는 답을 건네주면, 더 깊이 파고들지 않고 이를 받아들이려는 것이 인간의 경향입니다. 이러한 인지적 게으름은 새로운 것이 아닙니다. 쉽고 "좋아 보이는" 해결책을 선택해 진행하려는 것은 일반적인 인간의 약점입니다. 하지만 엔지니어링에서 답변을 맹목적으로 신뢰하는 것은 위험할 수 있습니다. AI 코드 어시스턴트가 코드 스니펫이나 아키텍처를 제안한다면 이렇게 물으십시오. "이 제안은 누가 작성했는가? AI가 우리의 맥락을 실제로 이해하고 있는가?" AI의 출력물은 마치 경험 없는 인턴이 작성한 것처럼 취급하고, 모든 것을 검증하십시오.

예를 들어, Cursor(AI 코드 에디터)가 버그에 대한 코드 수정안을 제공한다면, 비판적인 엔지니어는 주니어 개발자의 작업을 검토하듯이 그 코드를 철저히 검토하고 테스트할 것입니다. 누가라는 질문은 AI의 개입 여부와 상관없이 책임과 이해는 인간에게 있다는 점을 상기시켜 줍니다.

누가 책임지고 누가 영향을 받습니까? 마지막으로, 비판적 사고는 기술적 결정에 의해 누가 영향을 받을지 인식하는 것을 의미합니다. 임시변통의 빠른(quick-and-dirty) 수정 사항을 배포하면 단기적으로는 관리자를 만족시킬 수 있겠지만, 나중에 그 코드는 누가 유지보수합니까? 시스템이 실패하면 비용은 누가 감당합니까? 최종 사용자입니까, 온콜(On-call) 엔지니어입니까, 아니면 회사의 평판입니까?

인간에게 미칠 영향을 고려하는 것은 문제 해결을 현실에 기반하게 합니다. 이는 **겸손(humility)**을 길러줍니다. 즉, 우리의 결정이 실제 사람들에게 영향을 미치며 우리 자신이 모든 답을 가지고 있지는 않다는 것을 인정하는 것입니다. 훌륭한 엔지니어와 제품 담당자들은 이러한 겸손을 기릅니다. 그들은 배울 것이 항상 더 있으며, 단 한 사람이 전체 그림을 가지고 있을 수 없음을 압니다. 배우려는 자세를 취하고 동료들에게 질문함으로써 지식의 격차를 메우고 실수를 조기에 포착합니다.

실제로는 백엔드 개발자가 프론트엔드 동료와 함께 기능의 영향을 다시 확인하거나("이 API 변경이 모바일 앱을 깨뜨릴 수 있나요?"), "아마 괜찮을 거야"라고 가정하는 대신 보안 팀에 보안 검토를 요청하는 것을 의미할 수 있습니다. 요컨대, 팀 내의 비판적 사고는 사회적 노력입니다. 누가 참여하는지에 서로와 자신에게 기꺼이 질문을 던지는 다양한 사람들이 포함될 때 비판적 사고는 꽃을 피웁니다.

---

What(무엇을): 진짜 문제를 정의하고 증거를 수집하십시오

우리는 실제로 무엇(What)을 해결하려고 합니까? 이것은 아마도 가장 중요한 질문일 것입니다. 엔지니어링의 고전적인 함정은 그것이 올바른 일인지 확인하지 않고 무언가를 해결하려고 서두르는 것입니다.

실제로 하버드 비즈니스 리뷰(HBR)는 문제를 사전에 엄격하게 정의하는 것이 올바른 과제를 해결하고 낭비를 방지한다고 강조했습니다. 실무적으로 이는 요구 사항과 성공 기준을 명확히 하는 데 시간을 할애하는 것을 의미합니다. 한 시나리오를 상상해 봅시다. 제품 관리자가 "사용자 데이터를 요약하는 AI 기능"을 요청합니다. 무엇이 최종 목표인지 묻기 전에 요약 알고리즘 코딩으로 바로 뛰어드는 것은 시기상조입니다. 목표가 사용자가 데이터 추세를 이해하도록 돕는 것입니까? 그렇다면 "진짜 문제"는 사용자가 원시 데이터(raw data)에 압도당하고 있다는 것이며, 해결책은 단순한 요약보다는 더 나은 시각화일 수 있습니다.

비판적 사고는 문제를 명시적으로 설명하고 초기 가정에 의문을 제기하도록 촉구합니다. 우리의 자연스러운 본능은 즉시 **"문제 해결 모드"**로 들어가는 것이지만, 이는 전략적이고 사려 깊은 해결책보다는 빠르고 피상적인 수정으로 이어지는 경향이 있습니다. 다시 말해, 해결해야 할 것이 무엇인지 정의하기 위해 속도를 늦추지 않으면, 증상만 고치거나 제대로 이해하지 못한 문제를 고치는 위험을 감수하게 됩니다. 사려 깊은 엔지니어는 초기에 묻습니다. "우리가 올바른 문제를 해결하고 있다는 것을 어떻게 아는가?" 이 간단한 질문이 엄청난 시간을 절약하고 이후의 골칫거리를 예방할 수 있습니다.

구체적으로, 문제가 무엇인지 정의하는 것에는 증거와 사실 수집이 포함됩니다. 예를 들어, 사용자가 시스템이 "느리다"고 불평한다고 가정해 봅시다. 무작위로 코드를 최적화하는 대신 비판적 사고를 하는 사람은 묻습니다. 정확히 무엇이 느린가? 페이지 로드 시간인가, 특정 쿼리인가, 아니면 전체 앱인가? 우리는 어떤 증거를 가지고 있는가? 로그를 보니 하나의 데이터베이스 쿼리가 5초가 걸린다는 것을 보여줄 수도 있습니다. 그러면 문제는 명확해집니다. 그 쿼리의 성능을 개선하는 것입니다. 마찬가지로 디버깅 시나리오에서, 무언가 고장 났을 때 **"무엇이 변경되었는가?"**라고 묻는 것은 종종 원인(최근 배포 또는 설정 업데이트)을 가리킵니다. 이러한 수사적 사고방식은 첫 번째 추측이 아닌 실제 원인을 해결하도록 보장합니다.

어떤 증거가 우리의 해결책이나 결론을 뒷받침합니까? 엔지니어링에서의 비판적 사고는 근본적으로 증거 기반의 의사결정입니다. 아이디어가 있는 것만으로는 충분하지 않으며, 데이터나 논리적 추론으로 정당화해야 합니다. 항상 물으십시오. "증거가 이 결론을 뒷받침하는가?" 예를 들어, AI 모델이 버그의 원인을 널 포인터 예외(null pointer exception)라고 제안한다면, 액면 그대로 받아들이지 말고 로그를 확인하거나 단위 테스트를 작성하여 확인하십시오. 성능 테스트가 개선을 나타낸다면, 여러 번의 실행이나 환경에서 결과를 검증하십시오. 현대의 AI 보조 개발 환경에서 이것은 특히 중요합니다.

대규모 언어 모델(LLM)은 종종 맞는 것처럼 들리는 답변을 생성합니다. 그들은 자신감 있게 말하는 데 탁월하며, 이는 숙련된 엔지니어조차 속일 수 있습니다.

"어떤 존재가 당신에게 충분히 좋은 결과를 준다면, 특별한 이유가 없는 한 당신은 그것을 개선하는 데 많은 시간을 쓰지 않을 것입니다. 마찬가지로 AI가 그럴듯하게 말한다면 당신은 그것을 조사하는 데 많은 시간을 쓰지 않을 것입니다. 이것은 분명 약점이지만, AI 자체의 문제라기보다는 인간 인지의 일반적인 약점입니다." — 해커뉴스(Hacker News)

그러나 그럴듯한 답변이 반드시 진실은 아닙니다. LLM의 답변은 "거의 항상" 그럴듯하게 들리지만 정답이라는 보장은 없습니다. 이는 실제 결과에 영향을 미치는 엄청난 결함입니다. 비판적 사고를 하는 사람은 제안된 해결책(AI에서 왔든 동료에게서 왔든)을 사실이 아닌, 테스트해야 할 가설로 취급합니다. 그들은 이를 확인하거나 반박하기 위해 증거를 수집합니다. 여기에는 실험 실행, 지표 수집, 또는 유사한 과거 사례 검색이 포함될 수 있습니다.

AI가 생성한 코드 스니펫을 평가하는 예를 들어봅시다. Cursor가 시간대(timezone) 변환을 위한 솔루션을 제공한다고 가정해 봅시다. 단순히 복사해서 붙여넣고 유효하다고 가정하는 대신, 비판적인 개발자는 다양한 형식과 엣지 케이스(edge cases)에 대해 테스트합니다. 복잡한 오프셋에서 코드가 실패한다는 것을 발견하면, 이 증거는 다음 단계(아마도 전용 라이브러리로 전환하는 것)를 지시합니다. "어떤 데이터가 이것을 뒷받침하는가?"라고 물음으로써 엔지니어는 확증 편향의 함정을 피합니다.

대신 그들은 적극적으로 반증하는 증거를 찾습니다. 기술적 논쟁에서 확증 편향은 누군가가 자신의 초기 설계 선택을 방어하고 대안적인 접근 방식을 무시하게 만들 수 있습니다. 이에 대한 해독제는 당신의 아이디어에 도전하는 데이터나 피드백을 찾는 것입니다. 새로운 기능이 로드 시간을 개선했다고 믿는다면, 성능이 저하된 케이스가 있는지도 살펴보십시오. 우리가 무엇을 느끼느냐가 아니라 우리가 아는 것(그리고 모르는 것)이 결정을 주도해야 합니다. 훌륭한 비판적 사고가는 마치 과학자와 같습니다. 그들은 사실을 수집하고, 테스트를 실행하며, 자아(ego)가 아닌 증거가 나아갈 길을 결정하게 합니다.

---

Where(어디서): 맥락과 범위를 고려하십시오

이 문제는 어디서 발생하며, 해결책은 어디에 적용됩니까? 엔지니어링에서 맥락(Context)은 전부입니다. 한 환경에서 완벽하게 작동하는 수정 사항이 다른 환경에서는 실패할 수 있습니다. 비판적 사고는 우리의 가정이 어디서 참인지 유념하는 것을 의미합니다. 엔지니어는 물어야 합니다. "이 이슈의 경계는 어디인가? 시스템이나 워크플로의 어디에서 효과를 보고 있는가?"

예를 들어, AI 운영 도구가 시스템 지표에서 이상 징후를 감지하면, 대응하기 전에 어디서—어떤 서버, 어떤 모듈인지—를 정확히 파악해야 합니다. 한 마이크로서비스의 CPU 스파이크가 전체 시스템의 실패를 의미하지는 않습니다. 문제가 존재하는 곳이 어디인지 국소화함으로써, 과도하게 일반화하거나 불필요한 전역적 "수정"을 배포하는 것을 피할 수 있습니다. 마찬가지로, 해결책이 어디서 사용될지 고려하십시오. 코드가 사용자의 저사양 스마트폰에서 실행됩니까, 아니면 강력한 클라우드 서버에서 실행됩니까? 맥락에 따라 매우 다른 접근 방식이 필요할 수 있습니다. 비판적 사고를 하는 사람은 항상 환경을 인식합니다. "이 코드는 어디서 실행되는가? 사용자는 어디서 어려움을 겪고 있는가?"

우리 지식의 공백은 어디에 있습니까? "어디서"를 묻는 것은 우리가 더 많은 정보가 필요한 곳을 식별하는 것을 의미하기도 합니다. 분산 시스템을 디버깅 중이라면, 특정 요청이 어디서 실패하는지 모를 수 있습니다. 클라이언트입니까, API 게이트웨이입니까, 아니면 데이터베이스입니까? 이는 실패 위치를 파악하기 위해 더 많은 데이터(예: 다양한 지점에 로깅 추가)를 수집하라는 신호입니다. 마찬가지로 제품 아이디어가 논의 중이라면, 비판적 사고는 이 아이디어가 사용자 여정(User Journey)의 어디에 적합한지 묻게 합니다. 이는 불필요한 문제를 해결하는 것을 방지합니다. 어쩌면 그 "멋진 기능"은 사용자가 거의 방문하지 않는 앱의 일부를 다루고 있을지도 모릅니다. 어디인지를 아는 것은 가장 중요한 곳에 노력을 할당하도록 돕습니다.

예를 들어, 새로운 기능 출시를 위한 실험을 계획한다고 상상해 봅시다. 비판적인 질문은 다음과 같습니다. "우리는 어디서 이것을 테스트할 것인가 – 스테이징 환경에서, 내부 사용자와 함께, 아니면 프로덕션에서 소수 비율의 A/B 테스트로?" 각 맥락에는 장단점이 있습니다. 현실적인 환경(라이브 사용자의 소수 비율 등)에서의 테스트는 고립된 랩(lab) 테스트가 밝혀내지 못하는 문제를 드러낼 수 있습니다. 반면, 어떤 실험은 실제 사용자에게 영향을 주지 않도록 샌드박스에 머물러야 합니다. 실험이 실행되는 곳을 명시적으로 고려함으로써, 엔지니어는 제약 조건을 고려하여 적절한 엄격함으로 테스트에 접근할 수 있습니다. 지저분한 현실 세계에서는 유효하지 않은 완벽한 랩 결과로부터 잘못된 확신을 얻기는 쉽습니다.

마지막으로, "어디서"는 은유적일 수 있습니다. "이 해결책이 어디서 부작용을 일으킬 수 있는가? 이 결정이 어디서 다운스트림(후속) 영향을 미칠 수 있는가?" 몇 단계 앞을 내다보는 것은 노련한 엔지니어의 특징입니다. 예를 들어, 공유 라이브러리를 수정할 때 그 라이브러리가 어디서 또 사용되는지 물어보십시오. 이렇게 하면 파급 효과를 예상하고 문제가 발생하기 전에 해당 위치를 확인하거나 해당 팀에 알릴 수 있습니다. 요약하자면, 공간적, 환경적, 시스템적 맥락 인식은 비판적 사고의 핵심 부분입니다. 이는 터널 시야(tunnel vision)를 방지합니다. 훌륭한 엔지니어는 단순히 문제를 해결하는 것이 아니라, 올바른 장소에서 설정에 대한 완전한 인식을 가지고 문제를 해결합니다.

---

When(언제): 타이밍, 일정, 그리고 깊이 파고들 때

언제 일이 발생했거나 발생할 것입니까? 시간의 차원은 기술 업무에서 매우 중요합니다. 비판적 사고는 문제를 진단할 때와 작업을 계획할 때 모두 **언제(When)**를 묻는 것을 포함합니다. 문제 해결 과정에서 버그가 언제 처음 나타났는지 또는 시스템이 언제 다르게 동작하는지 이해하는 것은 종종 원인을 드러냅니다. ("어젯밤 새벽 3시에 시스템이 충돌했습니다. 그때 무슨 일이 있었나요?" 아마도 야간 작업이나 배포가 충돌과 겹쳤을 수 있습니다.) 숙련된 엔지니어는 습관적으로 묻습니다. "마지막으로 정상 작동한 건 언제인가? 그 이후로 무엇이 바뀌었나?" 이 질문 방식은 맹목적인 추측보다 근본 원인을 찾는 데 훨씬 더 효과적입니다. 이는 증거 수집과 연결됩니다. 배포 타임라인이나 버전 기록은 결함이 있는 코드가 언제 라이브되었는지 정확히 보여줄 수 있습니다.

언제 더 엄격함을 적용해야 하고, 언제 빠른 휴리스틱으로 충분합니까? 모든 결정이 며칠간의 분석을 필요로 하는 것은 아닙니다. 비판적 사고의 일부는 언제 깊이 들어갈지 아는 것입니다. 엔지니어링에서 우리는 항상 철저함과 시간 제약 사이의 균형을 맞춥니다. 프로젝트 마감 기한과 온콜 사고는 빨리 행동해야 한다는 엄청난 압박을 만들 수 있습니다. 스트레스나 촉박한 일정 하에서 인간은 직관과 정신적 지름길, 즉 인지 과학자들이 **휴리스틱(heuristics)**이라고 부르는 것에 의존하는 경향이 있습니다. 이것들은 유용하지만, 편향과 실수의 문을 열기도 합니다.

NASA의 연구에 따르면 엔지니어들이 스트레스를 받거나 시간이 제한적일 때, 숙고할 시간이 있을 때보다 오류가 발생하기 쉬운 더 빠른 결정을 내린다고 합니다. 이것이 우리가 항상 긴급함을 피할 수 있다는 뜻은 아니지만, 위험을 인지해야 한다는 뜻입니다. 시간 압박을 받는 비판적 사고가는 결정의 가장 중요한 측면에서 의식적으로 속도를 늦출 것입니다. 예를 들어, 새벽 2시에 프로덕션 중단을 디버깅하고 있다면 시스템을 가동하기 위해 빠른 수정(휴리스틱, 예: 서비스 재시작)을 사용할 수 있습니다. 그러나 비판적 사고방식은 또한 **"이건 임시방편이다. 아침에 근본 원인을 조사해야 한다."**라고 기록할 것입니다. 즉, 언제 임시 수정을 적용하고 언제 영구적인 해결책에 투자할지 아는 것입니다.

제한된 시간 내에 엄격함으로 접근하는 것은 종종 **우선순위 분류(triage)**를 포함합니다. 어떤 질문이 지금 깊은 답변을 필요로 하고 어떤 것이 나중에 답해질 수 있는지 우선순위를 정하는 것입니다. 유용한 질문은 **"시간 제약을 고려할 때 어떻게 엄격하게 접근할 것인가?"**입니다. 예를 들어, 촉박한 마감 기한 내에 새로운 기능을 계획할 때, 비판적 사고는 팀이 모든 세부 사항을 완벽하게 하려고 하기보다는 가장 위험한 가정을 식별하고 조기에(빠르고 거친 방법으로라도) 테스트하도록 이끌 수 있습니다. 그들은 각 정보가 언제 필요한지에 집중합니다. UI는 나중에 결정해도 괜찮지만 알고리즘 검증은 지금 필수적입니까? 그렇다면 시간은 그에 따라 배분됩니다.

또한 훌륭한 비판적 사고가는 개입의 타이밍에 대한 감각을 기릅니다. 언제 도움을 요청해야 하는가? 일정 시간이 지나도 문제가 해결되지 않으면, 비판적인 엔지니어는 다른 사람의 시각을 빌리거나 더 넓은 팀 논의로 확대할 때라는 것을 압니다. 언제 멈추고 재고해야 하는가? 애자일(Agile)을 실천하는 팀의 경우, 이는 스프린트 경계나 주요 릴리스 전, 즉 본질적으로 올바른 궤도에 있는지 묻기 위해 내장된 "언제"의 체크포인트일 수 있습니다. 그리고 언제 분석을 충분히 했는가? 수확 체감의 법칙이 적용되는 지점이 있습니다.

엄격하다는 것은 분석에 의해 마비되는 것을 의미하지 않습니다. 그것은 당면한 결정에 대해 적절한 양의 사고를 하는 것을 의미합니다. 예를 들어, 문제를 디버깅하는 데 하루가 있다면, 처음 4시간을 체계적으로 데이터를 수집하는 데 쓰는 것은 현명합니다. 완벽한 답을 얻기 위해 23시간을 쓰는 것은 마감 기한을 놓치는 것을 의미할 수 있습니다. 비판적 사고는 자기 인식을 통해 이러한 균형을 맞추도록 돕습니다. 언제 분석 마비에 빠지고 있는지, 언제 결론으로 너무 빨리 비약하고 있는지 아는 것입니다.

---

Why(왜): 동기, 원인, 근거에 대한 질문

우리는 왜 이것을 하고 있습니까? "왜"라는 질문은 동기와 인과관계의 핵심에 닿습니다. 엔지니어링 맥락에서 끊임없이 왜를 묻는 것은 두 가지 큰 목적을 달성합니다. (1) 행동에 대한 건전한 근거를 확보하는 것(단지 "누군가가 시켜서" 하는 것이 아니도록), (2) 증상을 치료하는 대신 문제의 근본 원인을 파고드는 것입니다. 새로운 AI 도구를 도입하는 것과 같은 과제에 직면한 비판적 사고가는 묻습니다. "왜 이 도구가 필요한가? 어떤 문제를 해결할 것이며 그것이 왜 중요한가?"

팀이 가진 최선의 답이 "트렌디하니까" 또는 "경쟁사가 가지고 있으니까"라면 우려해야 합니다. 명확한 왜 없이 유행어를 쫓는 것은 팀이 사용자의 실제 필요를 해결하지 못하는 솔루션에 투자하게 만들 수 있습니다. 반면에 강력한 이유(예: "요약 자동화를 통해 사용자가 데이터를 분석하는 시간을 줄이기 위해")를 분명히 하면 팀은 진짜 목표에 정렬됩니다. 이는 독립적인 사고를 촉진합니다. 왜에 대해 확신을 가진 엔지니어는 구현 과정에서 독립적으로 더 나은 결정을 내릴 수 있습니다. 단순히 명령을 따르는 것이 아니라 최종 목표를 깊이 이해하고 있기 때문입니다.

왜 이런 일이 발생했습니까? 무언가 잘못되었을 때(혹은 잘되었을 때), "왜"를 반복해서 묻는 것은 피상적인 대답을 넘어설 수 있는 입증된 기법입니다. 실제로 근본 원인 분석(Root Cause Analysis)에서의 5 Whys(5가지 왜) 기법은 본질적으로 제도화된 비판적 사고입니다. 첫 번째 설명에 뛰어들지 않고 인과관계를 층층이 벗겨내는 것이 핵심입니다.

예를 들어, 머신러닝 모델의 정확도가 갑자기 떨어졌다고 상상해 봅시다. 순진한 반응은 **"모델이 나쁘니 재학습시키자"**일 수 있습니다. 비판적 접근 방식은 묻습니다. "왜 정확도가 떨어졌는가? 입력 데이터 분포가 바뀌었기 때문이다." 왜 그런 일이 발생했는가? 아마도 새로운 데이터 소스가 추가되었기 때문일 것입니다. 왜 그것이 고려되지 않았는가? 데이터 파이프라인에 분포 변화에 대한 검증이 없었기 때문일 수 있습니다. "왜"를 다섯 번(또는 필요한 만큼) 묻고 나면, 훨씬 더 명확한 그림을 갖게 될 것입니다. 어쩌면 진짜 근본 원인은 데이터 드리프트(drift)를 조기에 포착하지 못한 결함 있는 모니터링 프로세스였을 수 있습니다.

차이는 큽니다. 빠른 수정은 모델을 재학습시키는 것(일시적으로 낮은 정확도라는 증상을 해결)일 수 있지만, 5 Whys 접근 방식은 모니터링 시스템을 개선하여 문제가 재발하는 것을 방지하도록 이끌 수 있습니다. 5 Whys에 대한 가이드가 설명하듯이, 이 방법은 "단순히 표면적인 증상을 해결하는 것이 아니라 문제의 핵심에 도달하는 것을 목표로 하여" 팀이 임시방편을 넘어 지속 가능한 해결책으로 나아가도록 장려합니다.

그러나 주의하지 않으면 왜는 양날의 검이 될 수 있습니다. 인간은 이유를 답할 때 편향에 취약합니다. 흔한 함정 중 하나는 **확증 편향(confirmation bias)**입니다. 우리는 우리의 선입견에 맞는 편리한 설명에 매달려 조사를 멈출 수 있습니다. 예를 들어, 엔지니어는 **"서버가 메모리 누수 때문에 충돌했다. 전에도 그랬으니까."**라고 가정하고, 메모리 누수가 자신의 멘탈 모델에 부합한다는 이유만으로 새로운 설정 변경과 같은 다른 원인을 고려하지 않을 수 있습니다. 메모리 누수 가설을 반증할 증거를 찾지 않는다면, 진짜 원인을 놓칠 수 있습니다.

앞서 언급한 **뛰어들기 편향(plunging-in bias)**은 또 다른 "왜"의 함정입니다. 이는 문제를 완전히 이해하기도 전에 해결책으로 돌진하는 경향입니다. 연구에 따르면 이러한 편향(결론으로 비약하고 미리 결정된 해결책을 강요하는 것)은 실패한 의사결정의 약 절반에서 근본 원인이 아닌 증상을 다루게 만들었습니다. 다시 말해, 충분히(또는 올바르게) "왜"를 묻지 않는 것은 프로젝트를 침몰시킬 수 있습니다. 1980년대 할리데이비슨(Harley-Davidson)은 시장 점유율을 잃는 이유를 잘못 진단하여 외부 요인을 탓하고 잘못된 해결책을 실행했으나, 실제 문제는 내부 관행에 있었습니다. 그들이 궤도를 수정하는 데는 수년이 걸렸으며, 이는 진정한 "왜"를 파악하지 못하는 것이 얼마나 고통을 연장시킬 수 있는지 보여주는 사례입니다.

훌륭한 비판적 사고가들은 왜에 대해 끈질기게 호기심을 갖습니다. 그들은 겸허한 호기심을 유지합니다. 이는 자신의 초기 가정이 틀렸음을 알게 되는 것에 대한 개방성입니다. 그들은 다음과 같이 질문합니다. "왜 우리는 이 접근 방식이 효과가 있을 것이라고 믿는가? 실제 데이터 때문인가, 아니면 우리의 직감인가? 왜 사용자는 이 기능을 요청하는가 – 기저에 깔린 니즈는 무엇인가?" 이유를 파고듦으로써 그들은 종종 논리적 허점을 포착하거나 숨겨진 요구 사항을 발견합니다. 중요하게도, 그들은 결정 뒤에 있는 왜를 다른 사람들에게 전달하여 팀이 정렬되고 결함을 발견하도록 돕습니다. 특정 기술적 결정이 내려진 이유를 명확히 설명할 수 없다면, 그것은 적신호입니다. 결정에 확실한 근거가 없거나 그 근거가 공유되지 않았다는 뜻이기 때문입니다(둘 다 위험합니다). 반대로 모든 사람이 근거(왜)를 이해하면, 새로운 상황 전개가 여전히 그 근거를 뒷받침하는지 아니면 재검토가 필요한지 독립적으로 확인할 수 있습니다.

---

How(어떻게): 엄격함을 적용하고 명확하게 소통하십시오

"누가, 무엇을, 어디서, 언제, 왜"를 탐구한 후 마지막 질문은 **"어떻게(How) 실제로 매일 비판적 사고를 실천할 것인가?"**입니다. 이는 방법과 사고방식에 관한 것입니다. 어떻게 문제를 엄격하면서도 효율적으로 접근하고, 어떻게 명확한 소통을 통해 해결책을 실행할 것인가 하는 점입니다. 훌륭한 비판적 사고가들은 체계적인 접근 방식을 갖는 경향이 있습니다. 그들은 질문을 명확하게 공식화하고, 증거를 검증하며, 해결책을 논리적으로 소통합니다. 이를 분석해 보겠습니다.

문제를 체계적으로 접근하는 방법: 종종 더 나은 질문을 던지는 것에서 시작됩니다. 모호한 질문 대신, 그들은 통찰력으로 이어지는 구체적이고 개방형인 질문을 던집니다. 예를 들어 "이 디자인이 좋은가?"보다는, 비판적 사고가는 "이 디자인이 사용자의 주요 니즈를 어떻게 해결하며, 어떻게 실패할 수 있는가?"라고 물을 수 있습니다. 우리가 이미 생각하고 있는 것을 확인만 해주는 유도 질문이나 편향된 질문을 피하는 것이 중요합니다. 열린 마음을 유지하고 세부 사항을 **탐색(probing)**하는 것이 훨씬 더 유용한 정보를 낳습니다. 실용적인 습관은 아는 것과 모르는 것을 나열한 다음, 후자를 어떻게 테스트하거나 알아낼지 계획하는 것입니다. 과학자처럼 생각하십시오. 가설(예: "데이터베이스가 병목이다")이 있다면, 그것을 증명하거나 반증할 방법(프로파일링이나 쿼리 시간 확인 등)을 찾으십시오. 문제에 대한 이러한 구조적 심문은 비판적 사고의 핵심입니다.

증거를 검증하고 편향을 피하는 방법: 데이터나 답변을 얻었다면, 비판적 사고가는 이를 검증합니다. 데이터가 실제로 결론을 뒷받침하는가, 아니면 대안적인 해석이 있는가? 이는 두 소스의 지표를 교차 확인하거나, 우연이 아님을 확인하기 위해 테스트 환경에서 버그를 재현하거나, 당신이 한 가정에 대해 코드 리뷰를 받는 것을 의미할 수 있습니다. 또한 자신의 편향을 인식하는 것을 의미합니다. 논의했듯이, 설명에 너무 빨리 끌린다면 잠시 멈추고 물으십시오. "나는 모든 증거를 고려하고 있는가, 아니면 내 이론을 확인해 주는 부분만 보고 있는가?" 하나의 전략은 모순되는 증거를 적극적으로 찾는 것입니다. 새로운 기능이 유지율(retention)을 개선했다고 생각한다면, 유지율이 개선되지 않은 코호트(집단)를 살펴보십시오. 그곳은 무엇이 다릅니까? 부정적인 데이터를 환영함으로써 당신은 자신을 속이지 않게 됩니다. 이것은 본질적으로 사고에 적용된 품질 보증(QA) 마인드셋입니다. 코드를 테스트하듯 아이디어의 견고함을 테스트하십시오. 또한 프레임워크와 체크리스트는 엄격함을 유지하는 데 도움이 될 수 있습니다. 예를 들어 어떤 팀들은 사전 부검(premortem) 운동(프로젝트가 실패한 미래를 상상하고 그 이유를 적어보는 것)을 사용하여 처음에는 고려하지 않았던 잠재적 문제와 가정을 드러냅니다. 이러한 기법은 계획이 실행되기 전에 더 비판적인 평가를 강제합니다.

해결책과 추론을 소통하는 방법: 아무리 훌륭한 해결책이라도 팀에 의해 소통되고 구현되지 못하면 가치가 없습니다. 비판적 사고는 해결책이 설명되는 방식에서 빛을 발합니다. 훌륭한 엔지니어는 설명을 논리적으로 구성합니다. 문제 정의(무엇과 왜)로 시작하여, 제안된 해결책(어떻게)을 명시하고, 이를 뒷받침하는 증거와 추론을 제공합니다. 그들은 가정을 명시적으로 만들고 고려된 트레이드오프(trade-offs)를 설명합니다. 이러한 종류의 소통은 다른 사람들이 제안을 이해하도록 도울 뿐만 아니라, 사고하는 사람을 위한 최종적인 자기 점검 역할도 합니다. 명확하게 설명할 수 없다면, 아마도 당신의 생각이 아직 명확하지 않은 것일 수 있습니다. 중요하게도, 비판적 사고가는 과장이나 의견보다는 사실과 데이터를 사용하여 소통을 뒷받침합니다. 한 엔지니어링 리더십 기사가 언급했듯이, 겸손한 엔지니어는 의견보다 사실을 선호합니다. 그들은 자랑 섞인 주장을 하기보다 데이터를 인용할 것입니다("이 변경으로 대시보드상 로드 시간이 25% 개선되었습니다"). 이러한 접근 방식은 신뢰를 구축합니다. 이는 당신이 증거에 의해 인도되고 있음을 보여주며, 동료와 이해관계자가 해결책을 신뢰하기 쉽게 만듭니다. 게다가 명확한 소통은 경청과 피드백 초대를 포함합니다. 비판적 사고가는 독백하지 않습니다. 그들은 다른 사람들이 허점을 찌르고 질문하도록 장려합니다. 그러한 검증이 아이디어를 입증하거나 개선하는 데 도움이 되기 때문입니다. 회의에서 이것은 다음과 같을 수 있습니다. "이것이 제가 제안하는 것이고 그 이유입니다. 이 추론에 틈이 보이거나 우려되는 점이 있는 분 계신가요?" 열린 대화를 조성함으로써 그들은 목소리 큰 사람이 이기는 것이 아니라, 해결책이 견고하고 합의되도록 보장합니다.

마지막으로, "우리의 비판적 사고를 지속적으로 개선하려면 어떻게 해야 합니까?" 이 메타 질문은 생각해 볼 가치가 있습니다. 답은 연습과 성찰입니다. 프로젝트에 대한 회고(retrospective)를 하듯, 결정에 대한 미니 회고를 하면 사고 기술이 날카로워질 수 있습니다. 예를 들어, 서두른 결정이 버그로 이어졌다면 팀은 분석할 수 있습니다. 어떻게 놓쳤으며, 다음에는 어떻게 그런 것을 포착할 수 있을까?

시간이 지남에 따라 엔지니어는 교훈의 정신적 라이브러리(예: "X를 확인하는 것을 잊지 말자. 저번에는 가정했다가 낭패를 봤으니까")를 구축합니다. 많은 최고 수준의 엔지니어들은 다른 회사의 실패 사례(post-mortem)를 읽거나 인지 편향을 공부하여 자신이 빠질 수 있는 함정에 익숙해지는 습관을 기릅니다. 비판적 사고는 한번 하고 마는 체크박스가 아닙니다. 호기심을 유지하고, 겸손하며, 증거 주도적인 태도를 유지하는 지속적이고 커리어 전반에 걸친 훈련입니다.

---

결론

AI 사용이 점점 늘어남에 따라, 비판적 사고는 선택이 아니라 필수입니다.

우리는 누가(Who) 참여해야 하는지, **무엇(What)**이 진짜 문제인지, 맥락은 **어디(Where)**에 있는지, 언제(When) 더 깊이 파고들어야 하는지, 왜(Why) 어떤 일이 행해지는지, 그리고 어떻게(How) 제대로 할 것인지를 물어야 합니다. 이 고전적인 프레임워크를 실용적으로 사용함으로써, 기술 팀은 명확성을 가지고 복잡성을 헤쳐나갈 수 있습니다.

이는 독립적인 사고가 가치 있게 여겨지는 문화를 의미합니다. 팀원들이 제안된 해결책에 대해 질문하고("이것이 임시방편이 아니라 진짜 해결책이라는 것을 어떻게 아는가?"), 가정을 도전하며("사용자가 이 기능을 원한다고 왜 확신하는가?"), 증거를 요구("데이터가 실제로 개선을 보여주는가, 아니면 우리가 보고 싶은 것만 보고 있는가?")하는 데 안전함을 느끼는 문화입니다. 경험이 아무리 많아도 무언가를 놓칠 수 있다는 생각인 **겸허한 호기심(humble curiosity)**을 받아들이는 것은 엔지니어가 확증 편향이나 과신에 빠지는 것을 막아줍니다.

또한 비판적 사고는 빠른 수정(quick fixes)의 유혹으로부터 우리를 보호합니다. 문제를 대충 때우고 넘어가고 싶은 유혹은 이해할 만하며, 특히 압박 속에서는 더욱 그렇습니다. 하지만 우리가 보았듯이, 빠른 수정에 대해 비판적으로 생각하지 않으면 나중에 같은 문제가 재발하거나, 더 나쁘게는 엉뚱한 것을 고치게 될 수 있습니다. 사전에 어려운 질문을 던지고 행동하기 전에 검증함으로써, 우리는 장기적으로 시간과 수고를 실제로 절약하게 됩니다. 코드가 작성되기 전에 설계 결함을 발견하든, 고객에게 도달하기 전에 AI 출력의 오류를 깨닫든, 상류(upstream)에서 문제를 포착함으로써 하류(downstream)의 문제를 피할 수 있습니다.

결론적으로, AI와 자동화가 계속 진화하여 더 많은 일상적인 업무를 처리하더라도, 비판적 사고는 인간만의 고유한 강점으로 남습니다. 이것이 바로 우리가 올바른 이유로, 올바른 방식으로, 올바른 문제를 해결하고 있음을 보장하는 방법입니다.