환원적 사고란?
불필요한 세부를 제거하는 사고 방식
오, 좋은 아이디어네요. 예시를 "주는" 게 아니라, **어떻게 생각하는지 그 과정 자체**를 보여주는 거죠.
## 환원적 사고 과정을 보이기
### 시작: 프론트엔드 실무 문제
```jsx
function OrderPage() {
const user = useUser();
if (!user.profile.address.zipCode) {
// ...
}
}
Plain Text
복사
```
•
*첫 질문: "왜 이게 문제처럼 느껴지지?"**
→ 뭔가 "너무 깊이 들어가는" 느낌. 하지만 정확히 뭐가 문제인지 말로 하기 어려워요.
### 환원 1단계: 구체적 불편함 찾기
"뭐가 불편한지 더 구체적으로 말해볼까?"
•
`user`가 바뀌면 여기도 바꿔야 해
•
`address` 구조가 바뀌면 여기도 바꿔야 해
•
테스트할 때 `user.profile.address.zipCode` 전체 구조를 만들어야 해
•
*패턴 발견:** "바꾸면... 바꿔야 해"가 계속 나와요.
### 환원 2단계: 더 단순한 용어로
"'바꾸면 바꿔야 한다'를 더 단순하게 말하면?"
→ A가 B에 **의존**한다
"그럼 문제는 뭐지?"
→ **의존하는 게 너무 많다**
"왜 많은 게 문제지?"
→ 하나 바꿀 때마다 여러 곳을 고쳐야 하니까
•
*본질 도출:** 문제 = 과도한 의존성 = 변경의 파급효과
### 환원 3단계: 일상으로 단순화
"의존성이 많아서 변경이 어려운 상황... 일상에서는?"
•
*사고 과정을 소리내어 말하기:**
•
"회사에서 보고서 쓸 때... 상사가 내 워드 파일을 직접 열어서 폰트 크기까지 확인한다면?"
•
"그럼 내가 폰트 바꿀 때마다 상사한테 말해야 하네"
•
"아, 이게 '의존성'이구나"
"반대로 잘 되는 경우는?"
•
"카페에서 커피 주문할 때는 바리스타가 머신 바꿔도 난 몰라"
•
"왜 몰라도 돼지? 나는 '주문'이라는 방법만 알면 되니까"
•
"아하, 나는 커피 '만드는 방법'에 의존하는 게 아니라 '주문 방법'에만 의존하는구나"
•
*개념 연결:**
•
주문 방법 = Interface
•
만드는 방법 = Representation
•
나는 interface에만 의존 → representation이 바뀌어도 영향 없음
### 환원 4단계: 다시 코드로
"그럼 코드에서 '주문 방법'에만 의존하려면?"
```jsx
// Before: representation에 의존
user.profile.address.zipCode
// After: interface에 의존
user.getZipCode()
```
•
*질문으로 확인:**
•
"이제 zipCode가 어디 저장되어있는지 알아야 해?" → 아니요
•
"address 구조가 바뀌면 OrderPage 코드를 고쳐야 해?" → 아니요
•
"테스트할 때 뭘 mock해야 해?" → `getZipCode()` 하나만
## 이걸 교육에 적용하면
•
*학습자에게 보여줄 것:**
1. **"왜 불편하지?" 질문하는 장면**
- 느낌을 언어화하는 과정
- 막연한 불편함 → 구체적 문제
2. **"더 단순하게 말하면?" 반복**
- 프로그래밍 용어 → 일반 용어
- 복잡한 상황 → 핵심 원리
3. **"일상에서는 어떨까?" 탐색**
- 비슷한 패턴 찾기
- 이미 아는 것과 연결
4. **"다시 코드로 돌아오면?" 적용**
- 깨달은 원리를 코드에 매핑
- 구체적 해결책 도출
## 메타인지 촉진 질문들
학습자가 스스로 할 수 있도록:
•
"이 코드를 보고 느껴지는 불편함을 말로 해보세요"
•
"그 불편함의 핵심을 한 단어로 줄이면?"
•
"비슷한 불편함을 겪은 일상 경험이 있나요?"
•
"그때는 어떻게 해결했나요?"
•
"그 해결 방법을 여기에 적용하면?"
•
*사고 과정 자체**가 transferable skill이 되는 거죠.