1. 기존 추상화 교육의 한계
대부분의 추상화 교육은 좋은 추상화의 정의나 결과에 대해 다루는 데서 그칩니다.
"추상화란 공통점을 뽑아내는 것이다"
"추상화란 불필요한 세부사항을 숨기는 것이다"
이러한 정의는 완성된 추상화가 무엇인지는 설명하지만, 어떻게 추상화를 만드는지는 가르쳐주지 않습니다.
린다 플라워는 『글쓰기의 문제해결전략』에서 이렇게 말합니다.
"나는 작문을 기존의 결과 중심의 수사학에서 과정 중심의 접근방법으로 전환하여 연구하기로 하였다. 잘 조직된 글은 어떠해야 하는지를 정의내리는 대신에 어떻게 글을 구성해 가는지에 대한 과정을 보여주고자 하였다.
추상화 교육도 마찬가지입니다.
"좋은 추상화가 무엇인지"보다 "어떻게 추상화 사고를 하는지"를 가르쳐야 합니다.
더 큰 문제는, 많은 교육이 귀납적 방식만 사용하여 추상화 사고를 가르치려 한다는 것입니다. 많은 사례를 보여주고, 학습자가 스스로 패턴을 발견하고, 일반 원칙을 도출하길 기대합니다. 하지만 이 방식은 외생적 인지부하가 너무 높습니다. 초보자는 "무엇이 중요한지"조차 모르는 상태에서 수많은 사례를 분석해야 하니까요.
2. 토스의 교육 철학: 멘탈모델 직접 전달 + 체계적 훈련
2.1 명확하고 작동 가능한 멘탈모델을 제공한다
우리는 추상화에 대한 명시적 멘탈모델을 직접 전달합니다. 막연한 "공통점 찾기"가 아니라 구체적이고 작동 가능한 프레임워크를 제시하는 것이죠.
1) 핵심 멘탈모델: 추상화는 What과 How의 분리다
코드의 목적(What)과 세부 구현(How)을 분리하여, 사용하는 측에는 필요한 정보만 노출하고, How를 변경하더라도 외부로 변경이 전파되지 않도록 하는 것입니다.
이것만으로도 충분히 구체적이지만, 우리는 더 깊이 들어갑니다.
2) 변경의 마찰을 줄인다 (점착성)
추상화가 왜 중요한가를 설명할 때, 우리는 점착성(Viscosity)이라는 개념을 사용합니다. 점착성이란 코드를 변경할 때 느끼는 "끈적끈적함", 즉 변경이 얼마나 번거롭고 어려운가를 나타냅니다.
목적(What)은 비교적 잘 바뀌지 않고, 세부 구현(How)은 목적에 비해 자주 바뀝니다.
What과 How가 명확히 분리되면, How가 자주 바뀌어도 영향 범위가 작고, What이 바뀌더라도 변경 범위가 명확합니다. 따라서 변경 시 느끼는 마찰이 줄어들고 변경 용이성이 높아집니다.
점착성이 높으면 "귀찮아서 나중에"가 되고 기술 부채가 쌓이지만, 점착성이 낮으면 올바른 방법으로 고치는 것이 쉬워 코드 품질이 유지됩니다.
3) Wishful Thinking: 사고의 순서
멘탈모델을 알았다면, 이제 그것을 어떻게 적용할까요? 우리는 SICP에서 검증된 Wishful Thinking 사고법을 가르칩니다. "이런 게 있으면 좋겠다(What)"를 먼저 상상하고, "어떻게 만들지(How)"는 나중에 생각하는 것입니다.
초보자는 요구사항을 보자마자 "useState 써야지, useEffect로 fetch하고..."라며 구현(How)부터 생각합니다. 전문가는 "제품 목록 보여주는 게 본질이네. 그럼 이런 게 있으면 좋겠다"라며 목적(What)부터 생각합니다. Wishful Thinking은 이 전문가의 사고 순서를 명시적으로 가르칩니다.
4) 일상에서 프로그래밍으로: 능력의 전이
추상화는 새로운 능력이 아닙니다. 사람들은 이미 일상에서 추상화를 합니다.
커피를 주문할 때 "아메리카노 주세요"라고 말하지, 원두가 3번 선반에 있는지 머신 온도가 93도인지 말하지 않습니다. 택시를 탈 때 "강남역으로"라고 하지, 경로를 상세히 지시하지 않습니다.
Prat(2020) 연구가 밝혔듯, 프로그래밍 학습은 수학보다 언어 학습에 가깝습니다. 외국어를 배울 때 어휘(단어)를 배우고 문법(조합)을 배우듯, 추상화도 어휘(추상화 패턴: List, Form, Dialog)를 배우고 문법(조합 방법: IoC, Composition)을 배웁니다.
우리의 전략은 학습자가 이미 가진 일반 추론 능력과 언어 능력을 프로그래밍 영역으로 전이시키는 것입니다.
5) What과 How는 계층적이다 (How in What)
처음 배울 때 학습자들이 가장 헷갈려하는 부분이 있습니다. "요구사항에 적힌 건 다 What인가요?" 아닙니다. 요구사항 자체도 본질(What)과 세부사항(How)이 섞여 있습니다.
예를 들어 아래와 같은 요구사항이 있다고 가정해봅시다.
1.
확인 버튼을 누르면
2.
입력된 정보를 저장하고 alert를 띄운 뒤
3.
3초 뒤에 특정 경로로 페이지 이동
표면적으로는 많은 것을 요구하지만, 본질은 "입력된 정보 저장 후 사용자에게 피드백하고 다음 단계로"입니다. "alert", "3초", "특정 경로"는 세부사항입니다.
이 세부사항은 다시 다음 계층의 What이 됩니다. alert를 보여주는 방식도 여러 가지가 있을 테니까요.
상위 계층의 How가 하위 계층의 What이 되는 것, 이것을 우리는 "How in What"이라고 부릅니다. 추상화는 단일 레벨이 아니라 계층적으로 작동한다는 것을 이해하는 게 핵심입니다.
2.2 전이학습 기반의 단계별 학습 경로
이 모든 멘탈모델을 체계적으로 가르치기 위해, 우리는 기존에 우리가 활용하고 있던 언어능력을 전이하는 방식 기반의 단계별 학습 경로를 설계했습니다.
1단계는 일상 사례로 인식하기입니다.
커피 주문 같은 일상 경험에서 시작해, 학습자가 이미 추상화를 하고 있음을 깨닫게 합니다. 추상화가 먼 개념이 아니라 친숙한 것임을 인식시키는 거죠.
2단계는 일반해 어휘 사전입니다.
List, Form, Dialog, Button, Input, Select 같은 패턴 라이브러리를 갤러리 형태로 보여줍니다. Sweller(1988)의 인지부하 이론에 따르면, 완성된 예시(Worked Examples)를 보는 게 스키마 구축에 더 효과적합니다. 각 패턴의 What(역할)과 사용 시점을 예시와 함께 제시하는 것이죠.
3단계는 번역 연습입니다.
"단계가 많으면 → 한 번에 되면 좋겠다", "반복되면 → 자동으로 되면 좋겠다", "조건이 복잡하면 → 의도만 말하면 좋겠다" 같은 구체적인 번역 공식을 제공합니다. 기획서 문장을 보고 추상화 패턴으로 매핑하는 연습을 반복하면서, "이런 게 있으면 좋겠다"가 자연스럽게 떠오르도록 훈련합니다.
4단계는 What to How입니다.
SICP의 제곱근 예시를 현대 프론트엔드 맥락으로 번역해, Bottom-up(구현부터)과 Top-down(추상화부터)의 차이를 직접 체감하게 합니다. 같은 요구사항을 두 가지 방식으로 구현하며, "세부사항부터"와 "희망사항을 먼저" 사이의 인지부하 차이를 경험합니다.
5단계는 Wishful Thinking 적용하기 실습입니다.
직접 주석으로 "이런 게 있으면 좋겠다"를 적고, 그것을 코드로 구체화하고, 마지막에 구현하는 전체 과정을 체화합니다. 앞서 배운 모든 역량을 실제 코드 작성에서 통합하여 사용하는 것이죠.
2.3 역량의 명시적 분해와 성공 기준
한편 "추상화 잘하기"라는 주제는 너무 모호합니다. 무엇을 훈련해야 하는가? 어떻게 훈련하는가? 잘하는지 어떻게 아는가? 우리는 추상화 능력을 구체적 하위 역량으로 분해합니다.
요구사항 분해 능력에는 고객 언어를 개발 언어로 번역하기, 큰 것을 작은 것으로 나누기, 본질 찾기가 포함됩니다. 일반해 어휘 보유에는 패턴 라이브러리 알기, 상황을 패턴으로 매핑하기, 패턴 조합하기가 있습니다. 인터페이스 설계 감각에는 좋은 인터페이스 판단하기, 사용자 관점 유지하기, 변경 대응 설계하기가 있습니다.
더 중요한 것은, 각 역량마다 측정 가능한 성공 기준을 제공한다는 점입니다.
"List, Form, Dialog를 보고 각각 언제 쓰이는지 설명할 수 있다", "기획서 문장을 보고 3초 안에 해당하는 추상화 패턴을 떠올릴 수 있다", "useProducts() vs fetchAndSetProductsAndNavigate()를 보고 어느 것이 더 좋은 인터페이스인지 근거와 함께 설명할 수 있다" 같은 구체적 기준을 제시합니다.
"추상화를 잘하라"는 막연한 목표가 아니라, 무엇을 훈련하고 얼마나 달성했는지를 명확히 알 수 있습니다. 학습자는 학습 주체로서의 효능감을 느낄 수 있습니다. 스스로 점검하며 주도적으로 학습할 수 있게 되는 겁니다.
2.4 사전 교재와 집중 교육의 결합
이 모든 멘탈모델과 학습 경로를 담은 것이 바로 ‘추상화 교과서’입니다. 토스 프론트엔드 액셀러레이터(Acc) 교육 과정 이전에 사전 교육자료로 제공됩니다.
학습 흐름은 이렇습니다.
•
먼저 학습자는 교과서를 통해 명시적 지식을 습득합니다. What/How 분리가 무엇인지, Wishful Thinking이 무엇인지, 어떤 사고 순서로 추상화를 만드는지를 명확히 이해합니다.
•
그 다음, 3주간의 오프라인 집중 교육 과정에서 실제로 코드를 작성합니다. 이때 코치가 옆에서 사고 과정을 직접 관찰하고 피드백합니다.
◦
"왜 이렇게 분리하셨나요?"라고 물었을 때 "복잡해 보여서요"가 아니라,
◦
"요구사항의 본질이 '목록 보여주기'라서, 여러 분리 방법 중 데이터 페칭을 분리하는 게 변경 비용 대비 효과가 가장 크다고 판단했습니다"라고 답할 수 있어야 합니다.
이런 사고 과정이 명시적으로 드러나고, 그것에 대한 즉각적 피드백이 이루어지는 것이 집중 교육의 핵심입니다.
이것은 단순히 "많이 연습하기"가 아닙니다. 명확한 멘탈모델 위에 다양한 케이스를 붙이고 피드백을 받으면서 스키마를 정교화해가는, 체계적인 장기기억 형성 과정입니다.
3. 다른 곳에서는 왜 이렇게 안 하고 있을까?
이 방식의 효과성은 30년 이상의 인지과학 연구로 뒷받침됩니다. Sweller(1988)의 Worked Examples, Chi(1981)의 전문가 인식 연구, Wiedenbeck(1985)의 Top-down 사고 연구, Prat(2020)의 언어 능력 전이 연구가 모두 우리의 접근을 지지합니다.
그런데 왜 많은 곳에서 이렇게 하지 않을까요?
3.1 교육 철학의 차이
발견 학습(Discovery Learning)을 중시하는 곳이 많습니다. "스스로 깨달아야 진짜 배운다"는 믿음이죠.
반면 우리는 직접 교수(Direct Instruction)와 연습을 결합합니다. 초보자에게는 명시적으로 가르치고 체계적으로 연습시키는 것이 더 효과적이기 때문입니다.
발견 학습이 나쁘다는 게 아닙니다. 다만 초보자가 충분한 스키마 없이 발견하려 하면 외생적 인지부하가 너무 높아진다는 문제가 있을 뿐입니다. 우리는 먼저 명확한 멘탈모델을 제공하고, 그 위에서 다양한 케이스를 경험하게 하는 것이 더 효율적이라고 믿습니다.
3.2 교수자 자신도 명확한 스키마가 없다
"추상화가 뭐예요?"라고 물었을 때 "음... 공통점을 뽑아내는 거?"라고 답한다면, 그것을 명시적으로 가르치기 어렵습니다. 교수자 본인도 막연하면 체계적으로 전달할 수 없습니다.
우리는 먼저 코치들의 멘탈모델을 명확히 정립합니다.
"What/How 분리", "점착성", "How in What" 같은 명시적 개념들을 코치들이 먼저 완전히 이해합니다. 그래야 학습자에게 명확하게 전달할 수 있고, 학습자의 사고 과정을 정확히 평가하고 피드백할 수 있습니다.
3.3 학습과학 연구를 알지 못한다
인지과학 분야의 수많은 연구가 효과적인 학습 방법을 밝혀냈지만, 그것이 실제 교육 현장까지 전파되는 데는 시간이 걸립니다. 많은 교육자들이 이런 연구를 접할 기회가 없거나, 알더라도 실제 커리큘럼으로 구체화하는 방법을 모릅니다.
우리는 연구를 읽고 끝내지 않습니다. Sweller의 Worked Examples 이론을 "일반해 어휘 사전"으로, Chi의 깊은 구조 인식을 "요구사항 분해"로, Prat의 언어 능력 전이를 "커피 주문 비유"로 구체화합니다. 이론을 실천 가능한 교육 콘텐츠로 바꾸어 전달하는 것이죠.
4. 과학적 근거에 기반한, 유효하고 효과적인 교육을 위하여
토스 프론트엔드 교육의 추상화 학습 철학은 다음과 같이 요약됩니다.
•
우리는 명시적 멘탈모델을 직접 전달합니다.
◦
"추상화 = What/How 분리"라는 명확한 정의에서 시작해, How in What, 점착성, Wishful Thinking까지 작동 가능한 프레임워크를 제공합니다. 막연한 정의를 거부합니다.
◦
"추상화 잘하기"라는 모호한 목표를 거부하고, 요구사항 분해, 일반해 어휘, 인터페이스 설계라는 구체적 하위 역량으로 나눕니다. 각 역량마다 측정 가능한 성공 기준을 제공합니다.
•
우리는 Worked Examples를 기반으로 스키마를 효과적으로 발달시킵니다.
◦
귀납적 방식보다 연역적 방식이, 사례를 보고 추론하게 하는 것보다 원칙을 먼저 주고 완성된 예시를 보여주는 것이 초보자에게 더 효과적입니다. 불필요한 인지부하를 최소화합니다.
•
우리는 사고 과정을 가르칩니다.
◦
결과로서의 추상화가 아니라 Wishful Thinking이라는 명시적 사고 순서를, "이런 게 있으면 좋겠다"를 먼저 상상하는 전문가의 방식을 가르칩니다.
•
우리는 능력의 전이를 믿습니다.
◦
추상화는 새로운 개념이 아니라 학습자가 이미 가진 일반 추론 능력과 언어 능력의 확장입니다. 프로그래밍 학습은 언어 학습에 가깝다는 연구를 진지하게 받아들입니다.
•
우리는 학습과학을 존중합니다.
◦
30년 이상 검증된 연구를 기반으로 하며, 직관이 아닌 증거로 교육 방법을 설계합니다.
과학적 근거에 기반한, 유효하고 효과적인 교육. 이것이 토스 프론트엔드 챕터의 교육 철학이자 방향성입니다.
우리는 있으면 좋은 “vitamin”이 아니라, 반드시 문제를 해결하는 필요한 “painkiller” 로서의 교육을 제공하고 싶습니다. 막연한 조언 대신 명확한 방법을, 추상적인 원칙 대신 작동 가능한 프레임워크를, 귀납적 발견 대신 체계적 학습을 제공하고자 합니다.