AI 시대의 소프트웨어 엔지니어를 위한 크리티컬 싱킹

AI가 코드, 설계, 문서를 빠르게 만들어 주는 시대지만, “무엇을 만들지, 왜 그렇게 해야 하는지, 이게 정말 맞는지”를 판단하는 일은 여전히 인간의 몫이다. 이 글은 소프트웨어 엔지니어와 기술 조직이 AI와 함께 일할 때 필요한 크리티컬 싱킹을 Who / What / Where / When / Why / How 관점에서 정리한 개인적 메모다.

Who: 누가 관여하고, 누가 말하고 있는가

• 문제 정의와 해결에 누가 참여해야 하는지부터 따져본다. 엔지니어, PM, 도메인 전문가, 실제 사용자 등 다양한 이해관계자가 빠지면 팀은 쉽게 그룹싱크에 빠지고, 자기들이 보고 싶은 데이터만 보게 된다.
• AI가 내놓은 답변도 “출처가 불분명한 주니어의 제안” 정도로 취급하고, 컨텍스트를 이해했는지, 실제 코드/시스템에 안전한지 반드시 검증해야 한다.
• 빠른 핫픽스, 아키텍처 결정, 성능 타협이 “누구에게 비용과 리스크가 돌아가는지”를 항상 의식하면, 의사결정은 자연스럽게 더 겸손해지고 장기 유지보수를 고려하는 방향으로 움직인다.

What: 진짜 문제는 무엇인가

• 엔지니어링의 고전적인 함정은 “먼저 해결부터 하고, 나중에 문제를 정의하는 것”이다. 따라서 먼저 “우리가 실제로 풀어야 하는 문제는 무엇인지, 성공 기준은 무엇인지”를 분명히 해야 한다.
• “시스템이 느리다”라는 피드백이 오면, 페이지 로드인지, 특정 API인지, DB 쿼리인지, 언제부터 느려졌는지 등 구체적인 증거를 모아야 한다. 이 과정에서 “무엇이 바뀌었는지(What changed?)”를 묻는 습관이 실제 원인을 빠르게 좁혀준다.
• LLM이 내놓은 그럴듯한 설명과 코드도 하나의 가설로만 취급하고, 로그, 테스트, 실험으로 검증함으로써 “플로우가 맞아 보이지만 사실은 틀린” 답에 속지 않도록 한다.

Where: 문제와 해법의 컨텍스트

• 동일한 해결책이라도 “어디에서 발생하는 문제인지, 어디에서 실행될 코드인지”에 따라 완전히 다른 영향을 준다. 로컬에서 잘 된다고 프로덕션에서 안전하다는 보장은 없다.
• 분산 시스템, 마이크로서비스, 복잡한 사용자 여정을 다룰 때는 “요청이 정확히 어디에서 실패하는지, 사용자 입장에서 어디에서 불편을 느끼는지, 이 변경이 어디까지 파급될지”를 먼저 지도처럼 그려 보는 것이 중요하다.
• 실험과 배포 역시 “어디에서 테스트할 것인가(스테이징, 내부 사용자, 일부 트래픽)”를 명시적으로 선택함으로써, 샌드박스의 거짓된 안도감과 전체 롤아웃의 과도한 리스크 사이를 균형 있게 조절할 수 있다.

When: 타이밍과 깊이의 수준 조절

• 장애 분석이든 기능 설계든 “언제부터 문제가 발생했는지, 언제 무슨 변경이 있었는지”를 타임라인 기준으로 추적하면, 감에 의존한 추측보다 훨씬 빠르게 원인에 접근할 수 있다.
• 하지만 현실에는 마감과 새벽 장애 콜 같은 시간 압박이 있다. 이때는 휴리스틱(서비스 재시작 같은 빠른 밴드에이드)과 근본 원인 분석을 명확히 분리하고, 나중에 반드시 리팩터링·재조사를 하기 위한 후속 작업을 남기는 것이 크리티컬 싱킹의 일부다.
• “언제 더 깊이 파고들 것을 멈출지”에 대한 감각도 중요하다. 제한된 시간 안에서 가장 리스크가 큰 가정부터 검증하고, 덜 중요한 의사결정은 나중으로 미루는 식의 우선순위화가 필요하다.

Why: 동기와 근본 원인에 집요하게 집착하기

• 기능도, 도구 도입도, 아키텍처 변경도 “왜 하는지”에 대한 답이 허약하다면(트렌드, 경쟁사 따라 하기 등), 나중에 팀이 방향을 잃기 쉽다. 엔지니어가 Why를 깊이 이해하고 있을수록, 세부 구현에서 더 좋은 독립적인 결정을 내릴 수 있다.
• 문제 해결에서는 “5 Whys”처럼 여러 번 왜를 묻는 방식으로 표면 증상 뒤에 숨은 프로세스·모니터링·조직 구조의 문제까지 파고든다. 이렇게 해야 단기적인 증상 완화 대신 재발 방지 구조를 만들 수 있다.
• 다만 인간은 자기 가설을 강화하는 확인 편향과, 충분히 이해하기 전에 바로 해결로 뛰어드는 “plunging-in bias”에 취약하므로, 의도적으로 자신과 팀의 가설을 깨 줄 반례와 데이터를 찾는 습관이 필요하다.

How: 일상에서 크리티컬 싱킹을 실천하는 방법

• 문제 접근: 막연한 질문 대신 “이 설계가 사용자의 핵심 니즈를 어떻게 충족시키고, 어디에서 실패할 수 있는지” 등 구체적이고 개방적인 질문을 던지고, 알고 있는 것과 모르는 것을 분리해 검증 계획을 세운다.
• 증거 검증: 한 번 나온 데이터나 설명에 안주하지 않고, 다른 소스와 환경에서 재검증하고, 반례와 실패 케이스를 의도적으로 찾아서 아이디어 자체의 내구성을 테스트한다. 프리모텀(premortem) 같은 기법으로 “미리 실패했다고 가정하고 이유를 찾는 연습”도 도움이 된다.
• 커뮤니케이션: 문제(What, Why), 제안된 해결책(How), 근거(증거, 트레이드오프)를 명확히 구조화해 공유하고, 동료들이 빈틈을 찌를 수 있도록 피드백을 적극적으로 요청하는 문화가 있을 때 팀의 사고 품질은 자연스럽게 올라간다.
• 개선: 프로젝트 회고처럼, 중요한 의사결정이 끝난 뒤 “어디에서 더 나은 질문을 할 수 있었는지, 어떤 편향에 걸렸는지”를 되짚어 보는 습관이 장기적으로 사고력을 성장시킨다.

마치며

AI와 자동화는 점점 더 많은 구현·문서화 작업을 대신해 주겠지만, “어떤 문제를 어떤 맥락에서, 언제, 왜, 어떻게 풀지”를 판단하는 크리티컬 싱킹은 여전히 인간의 핵심 역량이다. 엔지니어링 팀이 Who / What / Where / When / Why / How라는 단순한 질문 세트를 일상화한다면, AI의 도움을 받으면서도 잘못된 전제와 성급한 결정을 피하고, 더 안정적이고 의미 있는 제품을 만들어 갈 수 있다.

원문: Addy Osmani – “Critical Thinking during the age of AI”
링크: https://addyo.substack.com/p/critical-thinking-during-the-age

출처 Critical Thinking during the age of AI - Elevate | Addy Osmani https://addyo.substack.com/p/critical-thinking-during-the-age