8장_추상화로_더_잘_살기

8장. 추상화로 더 잘 살기

이 장은 삶으로의 확장이에요. 코드에서 연습한 What/How 분리를 삶 전반에 적용해요.

추상화는 코드만을 위한 기술이 아니에요. 커리어를 설계하고, 새로운 분야를 학습하고, 복잡한 결정을 내릴 때도 같은 원리가 작동해요.

잠깐, 이런 생각 해본 적 있나요?

“달리기를 해야 하는데… 러닝화도 없고, 운동장도 멀고, 1시간은 뛰어야 운동이 되는 거 아니야?”

그래서 결국 시작을 못 하거나, 시작했다가 “제대로 못 했으니 안 한 거나 마찬가지”라고 생각하거나. 이것도 What/How 분리로 풀 수 있어요. 이 장 마지막에서 다뤄요.

이 장에서 다루는 것: - 커리어 설계: 방향(What)과 수단(How)의 분리 - 학습 전략: 개념(What)과 예시(How)의 왕복 - 의사결정: 기준(What)과 선택지(How)의 구분

8.1 커리어 설계: “무엇”과 “어떻게”의 분리

 커리어 고민이 어려운 이유는 지식의 저주 때문이에요. 전문성이 쌓이면 “초보자였던 나”를 상상하기 어려워져요. “프론트엔드 개발자”(How)에 익숙해지면, “무엇을 하고 싶은가”(What)라는 질문이 낯설어져요.

방향과 수단을 혼동하지 마세요

“프론트엔드 개발자가 되고 싶어요”라는 말을 자주 들어요. 하지만 이건 어떻게(How)에 해당하는 말이에요. 진짜 질문은 이거예요:

“무엇(What)을 하고 싶은가?”

프론트엔드는 수단이에요. 그 수단으로 달성하려는 무엇이 있어야 해요. 예를 들면:

•

“사용자가 복잡한 데이터를 쉽게 이해하게 하고 싶다” → 시각화, 대시보드

•

“사람들이 더 편하게 글을 쓰게 만들고 싶다” → 에디터, 노트 앱

•

“팀의 생산성을 높이는 도구를 만들고 싶다” → 내부 도구, 자동화

What이 명확해지면 How는 유연해져요. 프론트엔드로 달성할 수도 있고, 백엔드로 달성할 수도 있고, 아예 개발이 아닌 방식일 수도 있어요.

커리어 추상화 연습

현재 나의 커리어 상태를 추상화해보세요:

1. 내가 지금 하는 일의 What은 무엇인가?
   - 구체적 업무(How)가 아니라 그 업무가 만드는 가치(What)

2. 이 What을 달성하는 다른 How가 있는가?
   - 같은 가치를 다른 방식으로 만들 수 있나?

3. 내가 진짜 원하는 What은 무엇인가?
   - 지금의 What이 아니라, 이상적인 What
Plain Text
복사

예시 — 저의 경우:

대학에서 저널리즘을 전공하고, 부트캠프 교육을 하다가, 지금은 프론트엔드 코칭을 해요. 겉으로 보면 완전히 다른 커리어 같지만, 추상화해보면 일관된 What이 있어요:

“복잡한 것을 명확하게 전달하기”

저널리즘은 사실을 명확하게 전달하는 일이었어요. 교육은 개념을 명확하게 전달하는 일이에요. How가 바뀌었을 뿐, What은 같아요.

이렇게 자기 커리어를 추상화하면 두 가지가 보여요:

일관성: 흩어져 보이던 경험들 사이의 연결고리

방향성: 다음 선택에서 고려해야 할 기준

정체성의 수준: 구현체인가, 인터페이스인가

더 깊이 들어가볼게요. 대부분의 사람들은 구현체 수준에서 정체성을 정의해요.

•

“나는 스타트업 개발자야”

•

“나는 프론트엔드 개발자야”

•

“나는 IC(Individual Contributor)야”

이렇게 정의하면, 구현체를 바꿀 때마다 정체성 위기가 와요.

•

스타트업에서 대기업으로 가면 → “나는 누구지?”

•

IC에서 매니저가 되면 → “나는 더 이상 개발자가 아닌가?”

•

코칭을 하게 되면 → “개발 안 하면 개발자 아닌 거 아니야?”

반면, 인터페이스 수준에서 정체성을 정의하면 어떨까요?

•

“나는 개발을 잘해지고 싶은 사람이야”

그러면 구현체는 자유롭게 갈아끼울 수 있어요.

구현체	이 구현체만의 효율
스타트업 IC	직접 문제 해결, 빠른 피드백
대기업 시니어	대규모 시스템 경험, 레거시 다루기
코칭/교육	고수의 암묵지 관찰, 언어화 강제, 검증 루프
오픈소스 기여	다양한 코드베이스, 협업 경험

프론트엔드 코칭이라는 구현체도 “개발을 잘해지기”라는 인터페이스를 만족해요. 고수의 암묵지를 관찰하고, 그걸 언어화해야 하고, 수강생 피드백이라는 검증 루프가 있어요. 직접 코딩만 하면 오히려 못 얻는 것들이에요.

구현체가 바뀌어도 정체성은 유지돼요. “나는 그냥 개발자야”라는 인터페이스 수준의 정체성이 있으면, 스타트업이든 대기업이든 교육이든 전부 같은 방향의 다른 경로일 뿐이에요.

8.2 학습 전략: 구조를 훔쳐라

 새 분야 학습이 막막한 이유는 시간 할인 때문이에요. 기초부터 쌓는 “미래 이익”보다 당장 코드 짜는 “현재 이익”이 더 크게 느껴져요. 그래서 구조 전이라는 지름길이 필요해요—이미 아는 것을 활용해서 새로 배울 비용을 줄이는 거예요.

처음부터 배우지 마세요

새로운 분야를 배울 때 흔히 하는 실수가 있어요. 기초부터 차근차근 배우려는 거예요. 물론 기초는 중요해요. 하지만 효율적인 학습은 다른 방식으로 작동해요.

3장에서 다룬 “저크(Jerk)” 훈련법을 기억하시나요? 한 도메인에서 발견한 구조를 다른 도메인에 적용하는 훈련이에요. 학습에서도 같은 원리가 적용돼요.

새 분야의 구조가 기존에 아는 것과 같은 구조임을 발견하면, 학습 시간이 극적으로 단축돼요.

구조 전이의 예시

React 개발자가 Vue를 배울 때:

React 지식                    Vue 대응
-----------                   --------
useState → 상태 관리      →   ref, reactive
useEffect → 부수효과      →   watch, onMounted
props → 부모→자식 전달    →   props (동일)
Context → 전역 상태       →   provide/inject
Plain Text
복사

React를 깊이 이해한 개발자는 Vue를 빠르게 배워요. “상태 관리”, “부수효과”, “단방향 데이터 흐름”이라는 추상적 구조를 이미 알고 있기 때문이에요. 구체적인 API만 다를 뿐, 구조는 같아요.

프로그래밍 → 글쓰기 전이:

프로그래밍 구조              글쓰기 대응
--------------              ----------
함수 분리 → 한 가지 일    →  단락 분리 → 한 가지 주장
추상화 → What/How 분리   →  요약/상세 분리
리팩토링 → 구조 개선      →  퇴고 → 문장 구조 개선
테스트 → 의도대로 작동?   →  검토 → 의도대로 전달?
Plain Text
복사

코드를 잘 짜는 사람이 글도 잘 쓰는 경우가 많아요. 같은 구조적 사고가 다른 도메인에 전이되기 때문이에요.

학습 추상화 연습

새 분야를 배울 때:

1. 일단 훑어봐요 (구체 → 추상)
   - 세부 내용보다 "이 분야의 핵심 개념이 뭐지?"

2. 아는 것과 연결해요 (추상 → 추상)
   - "내가 아는 분야에서 비슷한 구조가 뭐지?"

3. 차이점을 학습해요 (추상 → 구체)
   - 같은 구조지만 다른 부분만 집중
Plain Text
복사

이 방식의 핵심은 배우는 양을 줄이는 것이에요. 70%가 이미 아는 구조라면, 30%만 새로 배우면 돼요.

8.3 의사결정: 문제를 다시 정의하세요

 결정이 어려운 이유는 System 2 비용 때문이에요. 여러 프레임을 놓고 비교하려면 의식적으로 “다른 관점에서 보면?”을 시뮬레이션해야 해요. 이건 에너지가 많이 드는 작업이에요. 그래서 뇌는 첫 번째 프레임에 머물려고 해요—비용을 안 내려는 거죠.

같은 상황, 다른 결정

“연봉을 20% 더 주는 회사로 이직할까?”

이 질문에 대한 답은 어떤 프레임으로 보느냐에 따라 달라져요:

프레임	판단
금전적 가치	20% 상승, 이직하자
성장 기회	현재 회사에서 배울 게 더 많다면?
생활 균형	연봉은 높지만 야근이 두 배라면?
장기 커리어	5년 후 어느 쪽이 더 유리한가?

각각의 프레임은 같은 상황의 다른 측면을 비춰요. 문제는 대부분의 사람이 하나의 프레임에 갇혀서 결정한다는 거예요.

프레이밍의 함정

“이 프레임이 최선인가?”라는 질문을 던지기 어려운 이유가 있어요. 프레임은 투명하기 때문이에요. 안경을 쓰고 있으면 안경이 안 보이듯, 프레임 안에 있으면 프레임이 안 보여요.

프레임 안에서의 사고:        프레임 밖에서의 사고:
"이직해야 하나 말아야 하나"   "이직이라는 선택지가 최선인가?"
"A안과 B안 중 뭐가 나아?"     "A, B 외에 다른 선택지는?"
"어떻게 해결하지?"           "이게 진짜 해결할 문제인가?"
Plain Text
복사

 인지과학 박스: 프레이밍 효과 (Framing Effect)

심리학자 Tversky와 Kahneman이 발견한 현상이에요. 같은 정보라도 어떻게 제시하느냐에 따라 결정이 달라져요.

•

“수술 성공률 90%” → 수술하겠다

•

“수술 실패율 10%” → 수술 안 하겠다

똑같은 확률인데, 프레임이 다르면 판단이 바뀌어요. 프레임을 인식하는 것만으로도 더 나은 결정을 내릴 수 있어요.

리프레이밍 연습

결정 앞에서:

1. 지금 어떤 프레임으로 보고 있나?
   - "나는 이걸 OOO 문제로 보고 있다"

2. 다른 프레임으로 본다면?
   - 같은 상황을 완전히 다른 각도에서

3. 어떤 프레임이 더 유용한가?
   - 정답인 프레임은 없어요. 더 유용한 프레임이 있을 뿐이에요
Plain Text
복사

예시 — 버그를 대하는 태도:

프레임 1: "내 코드에 버그가 있다" (방어적)
         → 부끄럽다, 빨리 숨기고 싶다

프레임 2: "시스템에 개선점이 발견됐다" (성장)
         → 좋은 기회다, 제대로 고치자

프레임 3: "테스트에 빈틈이 있었다" (시스템적)
         → 어떻게 하면 다음에 잡을 수 있을까
Plain Text
복사

같은 버그, 다른 프레임, 다른 행동이에요.

8.4 일상의 왕복: 구체와 추상 사이

두 방향 모두 필요해요

4장에서 코드의 “왕복”을 다뤘어요. 구체에서 추상으로 올라가고, 추상에서 구체로 내려오는 움직임이에요. 일상에서도 이 왕복이 필요해요.

추상만 있으면:
- "사용자 경험을 개선하자" (구체적 방법 없음)
- "더 열심히 하자" (무엇을?)
- "코드 품질을 높이자" (어떻게?)

구체만 있으면:
- 버튼 색을 바꿨다, 그래서? (방향 없음)
- 매일 야근했다, 왜? (목적 없음)
- PR을 10개 올렸다, 의미는? (연결 없음)
Plain Text
복사

상승과 하강

상승(구체 → 추상): “이것들의 공통점이 뭐지?”

•

여러 버그 리포트 → 공통 패턴 발견

•

여러 피드백 → 핵심 문제 추출

•

여러 경험 → 원칙 형성

하강(추상 → 구체): “이걸 어떻게 적용하지?”

•

“코드 품질” → 구체적 린트 룰 설정

•

“더 나은 UX” → 특정 버튼 위치 변경

•

“효율적 학습” → 매일 30분 코딩

고비용 구현체 착각

도입부에서 던진 질문으로 돌아가볼게요.

“1시간 못 뛰었으니 운동 안 한 거야”
“책 한 권 다 못 읽었으니 독서 안 한 거야”
“포트폴리오 없으니 이력서 쓴 게 아니야”

이 생각의 함정은 고비용 구현체만 인터페이스를 만족한다고 착각하는 거예요.

“달리기를 해야지” → 고비용 구현체(1시간 트랙 인터벌)를 떠올림 → “지금은 그럴 시간/장비/체력이 없어” → 시작 못 함

하지만 퇴근길 1분 뛰기도 “심폐 자극”이라는 인터페이스를 만족해요.

활동	인터페이스 (본질)	고비용 구현체	저비용 구현체 (v0.001)
달리기	심폐 자극	1시간 인터벌	퇴근길 1분 뛰기
독서	외부 지식 내부화	2시간 정독	목차만 훑기
이력서	나를 뽑으라고 설득	포트폴리오	“저를 뽑아주세요” 한 줄
관계 유지	연결 신호 보내기	만나서 식사	카톡 이모티콘

v0.001도 인터페이스를 만족해요. 효율은 다르지만, 본질적 역할은 동일해요.

“오늘 당장 절대 실패할 수 없는 수준의 달리기 약속을 하라”고 하면, 정답은 “집 앞에서 10초 제자리 뛰기”일 수 있어요. 시작의 문턱을 낮추는 것. 이것이 추상화가 주는 실용적 통찰이에요.

왕복 연습

일상에서의 왕복:

상승 연습:
- 오늘 한 일들의 공통점은?
- 최근 불편함들의 패턴은?
- 반복되는 실수의 원인은?

하강 연습:
- "건강해지자"의 내일 첫 행동은?
- "더 나은 개발자"의 이번 주 목표는?
- "팀 기여"의 오늘 할 일 하나는?
Plain Text
복사

8.5 정리

추상화는 코드를 넘어서요.

영역	추상화 적용
커리어	What(방향)과 How(수단)를 분리하고, What을 먼저 명확히 해요
정체성	구현체 수준이 아닌 인터페이스 수준에서 정의하면 유연해져요
학습	새 분야의 구조가 아는 것과 같음을 발견하면 학습이 빨라져요
의사결정	프레임을 인식하고 바꿀 수 있으면 더 나은 결정을 내려요
일상	구체와 추상 사이를 오가며 방향과 실행을 연결해요

핵심 통찰

고비용 구현체만 진짜가 아니에요 — v0.001도 인터페이스를 만족해요

구현체는 갈아끼울 수 있어요 — 상황에 따라 다른 구현체를 선택할 수 있어요

본질을 보면 시작이 쉬워져요 — 문턱을 낮출 수 있어요

정체성도 추상화할 수 있어요 — 인터페이스 수준에서 정의하면 변화에 유연해져요

체크리스트

지금 내가 생각하는 “해야 하는 것”은 인터페이스인가, 특정 구현체인가?

이 구현체 말고 같은 인터페이스를 만족하는 더 낮은 비용의 구현체는 없는가?

내 정체성은 구현체 수준인가, 인터페이스 수준인가?

다음 장에서는 한 걸음 더 나아가, 추상화 자체를 추상화하는 메타인지를 다뤄요. “지금 내가 어떻게 추상화하고 있는지”를 인식하는 능력이에요.