1. 이 챕터를 학습하고 나면
이 챕터를 열심히 공부하고 나면 여러분에게는 아래와 같은 변화가 생길거에요.
코드를 볼 때:
"이 함수 뭔가 복잡하고 안 읽힌다…" → "…”
코드를 쓸 때:
"상위에서 데이터 만들어서 내려주면 편하겠지" → "위에서 한번에 이 데이터가 최종적으로 어디서 쓰이지? 사용처 가까이 모아두자. 그 뒤에 다시 생각해보는거야.”
동료와 소통할 때:
"…?" → "…”
2. 학습 목표
•
환원적 사고
3. 학습 콘텐츠 목차
좋아, 이전 자료들을 찾아서 비교해볼게!좋아, IoC 자료를 찾았어. 이제 비교해볼게!
공통 패턴 (템플릿)
Level 1: 최상위 구조
1. 학습 후 변화 (Before → After)
- 3가지 상황별로 보여줌
- 코드 볼 때
- 코드 쓸 때
- 동료와 소통할 때
2. 학습 목표 (측정 가능하게)
- ~을 설명할 수 있다
- ~을 감지/판단/선택할 수 있다
- ~을 작성할 수 있다
3. 학습 콘텐츠 (3-4개 대섹션)
- 문제 상황
- 개념 설명
- 적용 방법
- 연습/실무
Plain Text
복사
Level 2: 세부 구조 (IoC에서 발견)
문제 상황 섹션:
- 구체적 사례 (ProductCard)
- 점진적 악화
- 일반적 시도들 (실패)
- "선배들은 어떻게?"
Plain Text
복사
개념 설명 섹션:
- 용어 인정 ("어려워 보이죠?")
- 같은 코드, 다른 해석 (초보 vs 숙련)
- 단어 해체
- 비유 확장 (구체 → 추상 → 구체)
- 핵심 반복
Plain Text
복사
적용 방법 섹션:
- 다양한 방법들
- 각 방법마다:
* 코드 예시
* "X를 모른다"
* 재사용 시나리오
- 선택 기준
- 성공 판단 기준
Plain Text
복사
2번 챕터는 어디에 위치?
1번: 얽힘 감지 (진단)
"이 코드 얽혀있네"
↓
2번: 이상 떠올리기 (방향) ← 여기
"어떻게 되어야 하지?"
↓
3번: 일반해 표현 (도구)
"Form, List를 조합해서 만들자"
↓
4번: IoC (조립)
"이 컴포넌트는 제어권을 넘기도록 하면 좋을거 같아"
Plain Text
복사
2번 챕터가 다른 점
IoC와 얽힘 감지는:
•
명확한 "무엇" (IoC가 뭔지, 얽힘이 뭔지)•
명확한 "방법" (어떻게 적용)2번 챕터는:
•
"사고 과정" 자체를 가르침•
Wishful Thinking (메타인지)•
일반해 어휘 습득 (학습 방법)•
요구사항 분해 (분석 기술)다른 챕터들보다 한 단계 위의 메타 레벨
일관성 vs 차별성
일관성 유지할 것:
1. 학습 후 변화 (Before → After)
2. 학습 목표 (측정 가능)
3. 3-4개 대섹션
- 문제
- 개념
- 방법
- 연습
Plain Text
복사
차별성 둘 것:
- 문제: "얽힘 감지했는데, 어떻게 고치지?" 막막함
- 개념: Wishful Thinking (사고법)
- 방법: 요구사항 분해 + 어휘 습득 + 변환 공식
- 연습: 역량 트리 체크리스트
Plain Text
복사
요구사항을 분석한다는게 뭐지?
이상적인 형태를 떠올린다는게 뭐지?
박문철 1화의 예시 그대로 쓸까?
•
우리는 복잡해 보이는 부분을 보고 냅다 코드를 고치기 시작할 때가 많다
◦
리팩토링의 목적은? 무엇을 향해서? 리팩토링의 성공 조건은?
◦
요구사항을 먼저 파악한 뒤 → 그것을 달성하기 위한 가장 간단한 형태를 떠올리기 (Wishiful Thinking)
◦
프론트엔드 개발자 입장에서 코드 읽기에 대한 복잡도를 낮출 수 있는 가장 핵심적인 실천은, 요구사항과 코드가 인지적으로 1:1 매칭되도록 코드를 작성하는 것이다.
▪
기획서(or 디자인)와 코드가 별도의 용어나 단위로 존재하지 않고 일치할 수 있다면 시각적으로 이해한 내용을 통해 코드를 예측하면서 읽을 수 있고, 이는 협업 과정에서의 커뮤니케이션 비용을 줄일 수 있는 방법이기도 하다.
▪
각 코드를 유효한 '인지단위'로 묶기 위해서는 '모듈화'에 대한 전문성이 필요하다. → 다음 챕터에서 다룰 예정
•
좋은 모듈은 독립적이면서, 정해진 규약에 따라 쉽게 결합할 수 있다.
•
이는 높은 응집, 낮은 결합을 통해 달성될 수 있으며, 이미 이러한 좋은 속성을 가진 일반해(ex. 웹 표준)를 학습하면 좋은 인터페이스에 대한 기준을 보다 쉽게 잡을 수 있다.
•
wishful thinking (SICP 1.1.7절)
"We can see that wishful thinking is a powerful tool for building abstractions. In fact, this is how large systems are designed. We name something and then explore its use, assuming that it exists, before we implement it."
(희망적 사고는 추상화를 구축하는 강력한 도구입니다. 실제로 대규모 시스템은 이렇게 설계됩니다. 무언가에 이름을 붙이고, 구현하기 전에 그것이 존재한다고 가정하고 사용법을 탐색하는 것입니다.)
•
미루기
•
what과 how의 분리
•
interface와 representation의 분리
•
요구사항에 대한 분석: 추상화 = 일반화 + 분해 → 복잡성 관리를 위해서
◦
분해 / 분석(analysis): 복잡한 시스템을 구성요소로 나누는 행위 (뭘로 만들어져 있지?)
◦
환원(reduction): 불필요한 층위를 제거하고 본질만 남기는 사고 (”어떤 요소나 조건이 반드시 유지되어야 하나?”) → reduce + -tion: 차원을 줄이기…!
◦
과정
▪
문제 현상 기술: 표면적 복잡성 전체를 묘사 “이 시스템이 지금 하는 일은 무엇인가?”
▪
변수 식별: 영향을 미치는 요인 모두 나열 “어떤 요인들이 결과를 바꾸는가?”
▪
불변성 찾기 (Invariants): 요인 중 변해도 본질이 유지되는 부분 찾기 “무엇이 변해도 이 시스템은 여전히 성립하는가?”
▪
핵심 제약 도출: 최소한의 필요조건 2~3개로 축소 “이게 깨지면 전체가 무너지는 요소는?”
▪
모델 표현: 핵심 구조를 간결한 다이어그램/함수/패턴으로 표현 “이것을 하나의 규칙, 또는 패턴 문장으로 요약할 수 있는가?”
문제의 본질적 차원을 찾아가기
◦
문제의 본질을 찾기 위해 이상적인 형태 떠올리기 → HDD, Wishful Thinking
추상화를 가르칠 때 가장 중요한 요소
•
환원적 사고: 구체적인 세부사항을 덜어내고 꼭 필요한 핵심, 본질만 남겨서 사고하기, 어떤 대상을 분해/조립하기
•
추상과 구체를 오가며 연결시키기: 추상을 일상적인 비유, 구체적인 동작 메커니즘과 그 뒤에 숨어 있는 원리를 이어주기, 시각화 시켜주기
•
정적인 결과나 규칙을 전달하기보다는 메타적인 개념을 발견해나가는 과정을 다양한 사례로 보여주기
•
프로그래밍에서의 추상화가 수학능력보다는 일반인지(추론, 작업 기억)와 언어능력에 의존하고 있으므로, 기존에 가지고 있던 능력을 프로그래밍 추상화 능력 습득에 전이시키기
으아아아아아
todoc.alpha-i.toss.bz → 전문성 관련 연구 요약 문서
•
(4) 새로운 의미 수준 발견하기: 기존 코드에서 앞서 학습한 내용을 기반으로 추상화 가능한 단위를 식별하고 분리하는 과정을 설명.
오히려 대단한 개념이 아닌 걸 작게 작게 여러번 발견하는 예시를 만들고 싶다
