AI 시대의 학습 2 - 황금사과를 먹는 사람과 감상하는 사람

시리즈 · AI 시대의 학습

연재글 · 연재 완료

2회 · AI 시대의 학습 2 - 황금사과를 먹는 사람과 감상하는 사람

그렇다면 AI 시대에는 이 공부 방법이 여전히 통용되는 것일까요?

1부에서 공부의 과정은 필요성 인지 → 지식 습득 → 체득 → 응용이라고 정리했습니다. 이 원칙은 AI 시대에도 변하지 않는다고 생각합니다. 다만 AI로 인해 학습 과정은 두 가지 형태로 압축될 수 있습니다.

1. AI를 이용해 원천을 깊숙이 탐구하고, 예전과는 다른 공부 효율을 달성해 AI를 심도 있게 다루는 초전문가가 되는 경우입니다. 필자가 생각하는 미래의 인재상은 이쪽에 가깝습니다.
2. AI를 단순히 이용하면서 체득과 응용은 하지 않고, AI의 결과만 답습하는 단순 AI 프롬프터가 되는 경우입니다. 예전의 단순 코더와 비슷한 위치입니다.

사실 이 현상은 이미 벌어지고 있습니다. 많은 사람이 자신도 모르게 두 번째 형태를 따라가고 있습니다. 답변을 받는 순간 공부가 끝났다고 생각하고, 코드를 실행해 보기도 전에 다음 질문으로 넘어갑니다. 필자는 이런 사용 방식이 사람을 도태시킨다고 생각합니다. 모든 사람은 첫 번째 방식을 택해야 하며, 교육 과정 역시 답을 전달하는 데서 멈추지 않고 원천 탐구·체득·응용으로 이어지는 방향을 취해야 합니다.

이 글에서 말하는 AI 시대 학습법은 AI 활용 학습을 통해 개발자 성장을 돕되, AI 학습법을 답변 복사로 끝내지 않고 지식 응용까지 이어 가는 방식입니다.

1. AI 시대의 공부를 묻는 한 문장

AI가 지식 습득을 빠르게 만든 것은 사실입니다. 하지만 속도가 빨라졌다는 말이 공부의 목적이 사라졌다는 뜻은 아닙니다. 오히려 질문은 더 단순해집니다.

그렇다면 AI 시대에는 이 공부 방법이 여전히 통용되는 것일까?

이 질문에 대한 필자의 답은 “그렇다. 다만 지식 습득의 입구가 달라졌다”입니다. 과거에는 필요한 지식에 도착하는 것 자체가 어려웠고, 이제는 도착한 지식을 정말 자기 것으로 만드는 일이 더 중요해졌습니다. 이 차이를 이해하기 위해 개발자의 학습을 하나의 백화점 이야기로 바꿔 보겠습니다.

2. 구글이라는 백화점에서 신사복을 찾던 개발자

과거의 지식 습득은 구글이라는 거대한 백화점에 들어가는 일과 비슷했습니다. 개발자는 멋진 신사로 변신하고 싶었습니다. 하지만 신사가 어떤 옷을 입어야 하는지, 옷의 카테고리가 무엇인지조차 정확히 몰랐습니다.

마음속에 떠오른 최종 이미지는 이랬습니다.

파란색 중절모, 금태안경, 모자와 완전히 같은 색의 파란 정장, 앞이 뾰족하고 광이 나는 검은 구두, 금색 커프스, 흰 와이셔츠, 작고 검은 나비넥타이, 윤기 나는 짙은 갈색 고목나무 지팡이.

문제는 ‘커프스’라는 단어를 모른다는 데 있었습니다. 중절모와 베레모의 차이도 몰랐고, 정장과 재킷을 어떤 검색어로 구분해야 하는지도 몰랐습니다. 개발자는 백화점의 1층부터 끝까지 돌아다니며 검색창에 아는 단어를 하나씩 넣었습니다.

하루 종일 찾아 헤맨 끝에 손에 넣은 결과는 이랬습니다.

검은 베레모, 안경은 못 찾음, 짙은 파란 정장, 검은 청바지, 흰색 반팔 티셔츠, 시계.

어떻게 보면 옷을 입기는 했습니다. 그러나 원하던 신사와는 거리가 멀었습니다. 이 결과를 개발자의 언어로 번역하면 더 선명합니다. 코드는 컴파일되지만 요구사항과 설계가 맞지 않아 언제나 오류가 납니다. 검색 결과에서 조각을 주워 붙였을 뿐, 무엇이 빠졌는지조차 설명할 수 없습니다.

구글이 나빴다는 뜻은 아닙니다. 백화점에는 상품이 많았지만, 손님이 원하는 상품의 이름과 진열 위치를 알아야 했습니다. 개발자가 필요한 지식의 이름을 모르는 순간 검색은 지식의 안내자가 아니라 거대한 진열장이 됩니다.

<구글 백화점에서 흩어진 옷을 찾는 과정과 AI 코디네이터가 맥락을 정리하는 장면 2.1>

3. 백화점 앞에 AI 코디네이터가 서다

이제 같은 개발자가 AI 시대에 백화점을 찾았다고 생각해 봅시다. 이번에는 백화점 입구에 전문 코디네이터가 서 있습니다.

개발자가 조심스럽게 말합니다.

TEXT

개발자: 옷을 좀 예쁘게 입고 싶어요.
AI: 어떤 스타일을 찾으세요?
개발자: 그 영국의 멋진 사람들처럼요. 옷이 마이처럼 생겼던데요.
AI: 영국 신사 스타일이군요. 잠시만요.

AI는 백화점 안에 있는 모든 옷 중에서 가장 유사하게 코디할 수 있는 상품을 찾아옵니다. 파란색 중절모, 금태안경, 파란 정장, 흰 와이셔츠, 검은 나비넥타이, 금색 커프스, 뾰족하고 광이 나는 검은 구두, 짙은 갈색 지팡이가 차례로 놓입니다. 개발자는 처음부터 완벽하게 원했던 조합은 아니었지만, 적어도 이제 자신이 무엇을 입었는지 설명할 수 있습니다. 그는 꽤 마음에 들어 하며 백화점을 나섭니다.

이 장면에서 AI가 한 일은 옷을 무작정 대신 사 준 것이 아닙니다. 개발자가 몰랐던 카테고리와 단어를 먼저 찾아 주고, 흩어진 상품을 하나의 의도에 맞게 연결해 준 것입니다. 개발 문제로 치면 “로그인이 안 돼요”라는 막연한 문장을 세션, JWT, 쿠키, CORS, CSRF, OAuth, 프록시, 만료 정책이라는 탐색 가능한 지도으로 바꾼 일입니다.

TEXT

개발자: 로그인이 잘 안 돼요.
AI: 브라우저 쿠키 기반 세션인가요, Bearer 토큰인가요?
    실패는 로그인 직후인가요, 새로고침 뒤인가요?
    CORS 오류인가요, 401 응답인가요, 서버 로그의 예외인가요?

이 질문은 정답을 대신 내는 것이 아니라 개발자가 몰랐던 카테고리를 만들어 줍니다. 카테고리가 생기면 공식 문서를 찾을 수 있고, 문서에서 계약을 읽을 수 있고, 작은 실험으로 옷이 실제로 맞는지 확인할 수 있습니다. AI의 첫 번째 가치는 답변 문장보다 질문자가 몰랐던 단어를 발견하게 하는 데 있습니다.

4. 코디를 설명해 달라고 묻는 사람과 그냥 돌아가는 사람

이제 우리는 두 가지 선택지 앞에 서 있습니다.

첫 번째 개발자는 AI에게 집요하게 묻습니다.

이 코디를 제안한 이유를 모두 알려 주세요. 상품 종류, 스타일, 선택한 이유, 제품 특징, 가격까지 설명해 주세요.

AI는 각 옷의 이름과 역할을 설명하고, 어떤 조합이 서로 어울리는지, 어떤 상황에서는 바꿔야 하는지, 가격과 품질의 차이는 무엇인지 알려 줍니다. 물론 AI의 답변이 언제나 100% 정확한 것은 아닙니다. 하지만 개발자가 그 답변의 97% 근처까지 따라가며 원문을 확인하고 직접 입어 본다면, 이전보다 훨씬 빠르게 높은 수준에 도달할 수 있습니다. 이것이 AI를 이용해 원천을 깊숙이 탐구하는 초전문가의 방식입니다.

두 번째 개발자는 코디가 마음에 들었다는 말만 남기고 집으로 돌아갑니다. 텔레비전을 보다가 며칠 뒤 다시 백화점에 와서 말합니다.

이번에는 캐주얼 스타일로 추천해 주세요.

그는 오늘의 옷을 얻었지만, 왜 어울렸는지 알지 못합니다. 계절이 바뀌거나 장소가 달라지면 다시 코디네이터를 찾아야 합니다. 개발에서 AI가 만들어 준 코드를 복사해 실행만 하고 체득과 응용을 하지 않는 것도 똑같습니다. 잠깐은 빠르지만 버전이 바뀌거나 요구사항이 달라지면 다시 처음 질문으로 돌아갑니다.

기술적으로 보면 첫 번째 개발자는 AI에게 다음을 요청합니다.

1. 이 코드가 해결하는 문제와 해결하지 못하는 문제를 분리합니다.
2. 사용한 클래스·함수·프로토콜의 공식 문서를 확인합니다.
3. 정상 입력·경계 입력·실패 입력을 각각 실행합니다.
4. 대안 설계와 선택 기준을 비교합니다.
5. 30분짜리 최소 구현으로 직접 재현합니다.

TEXT

AI 답변
  ↓ 원문 링크와 전제 확인
  ↓ 최소 재현 코드 작성
  ↓ 실패 입력 추가
  ↓ 내 말로 설계 설명
  ↓ 다른 문제에 변형 적용

이 루프가 지식 습득을 체득과 응용으로 연결합니다. 질문을 한 번 던지고 결과를 받는 것이 아니라, 결과를 다시 질문하고 실행하고 설명하는 과정입니다.

5. 교육은 이제 완전히 AI로 재편해야 한다.

이 문제는 개인의 의지에만 맡길 일이 아닙니다. 교육 과정도 AI가 내놓은 답을 받아 적게 하는 방식에서 벗어나야 합니다. 필요성 인지에서 출발해 AI로 원천을 탐구하고, 손으로 체득하고, 다른 문제에 응용하도록 설계해야 합니다.

Microsoft Research의 2025년 지식 노동자 설문은 생성형 AI 사용에서 인지적 노력이 줄었다고 느끼는 상황과 비판적 검토의 관계를 조사했습니다. 이 연구는 AI가 사람의 사고력을 반드시 떨어뜨린다고 증명한 것이 아니라 자기보고 설문이라는 한계를 가집니다. 다만 AI를 사용할수록 검증을 덜 할 수 있다는 위험 신호를 보여 주므로, 학습자는 결과 검증을 의도적으로 설계해야 합니다. 학습 전략의 근거를 더 확인하려면 Dunlosky 연구진의 학습기법 검토와 retrieval practice 연구도 함께 읽을 만합니다.

<AI의 답을 체득과 응용으로 바꾸는 학습 루프 2.2>

마무리

테슬라의 머스크는 AI의 시대에 인류는 "AI 보다 뛰어난 사람이 되거나 스스로 AI 가 되거나" 라고 이야기 했습니다. 필자는 머스크의 생각이 맞다고 생각합니다. AI는 각종 지표에서 지구에서 가장 뛰어난 인간의 97% 를 달성했다고 합니다. 이는 일부 착시입니다. 지구에서 가장 뛰어난 각 분야의 전문가들의 모든 부분의 97%를 달성했다고 생각해야 합니다. 우리는 AI를 이용해 97%의 인간이 되어야 합니다. 아니면 머스크의 뉴럴링크 안테나를 머리에 박아버리게 되겠죠?

우리는 지금 손에 황금사과를 들고 있습니다. 이 사과를 먹을 것인지, 아니면 거실에 놔두고 계속 바라만 볼 것인지 선택해야 합니다. 명심해야 합니다. 황금사과도 썩습니다. 이 황급사과의 지식을 하루빨리 먹을지 예쁘다고 구경만 할지는 여러분에게 달려있습니다.

오늘 생성된 예제는 라이브러리 버전이 바뀌면 낡고, AI의 답변은 맥락이 사라지면 틀릴 수 있습니다. 그러나 AI가 내놓지 못하는 답변은 이제 인간도 내놓기 쉽지 않습니다. AI 시대에도 공부의 원칙은 변하지 않습니다. 그렇기에 이제 AI를 이용해 필요성을 인지하고, 지식을 습득하고, 체득하고, 응용해야 합니다. 달라진 것은 지식의 문 앞에 AI 코디네이터가 새로 생겼다는 사실 하나입니다.

시리즈 전체 회차

1. 1회 AI 시대의 학습 1 - 지식은 어떻게 내 것이 되는가
2. 2회 AI 시대의 학습 2 - 황금사과를 먹는 사람과 감상하는 사람 (현재 글)

AI 시대의 학습 1 - 지식은 어떻게 내 것이 되는가

시리즈 · AI 시대의 학습

연재글 · 연재 완료

1회 · AI 시대의 학습 1 - 지식은 어떻게 내 것이 되는가

필자는 개발자라는 직군은 평생을 공부해야 하는 운명을 가졌다고 생각합니다. 아니, 모든 사람들 특히 전문직군은 자신의 전문성의 신선함을 유지하기 위해 끊임없이 공부해야 합니다. 여기서 고민이 생깁니다. 공부란 무엇일까요? 나이가 먹어 갈수록 질문은 점점 단순해지는 듯합니다. 이런 질문에는 정답이 없으니, 이 글은 필자의 개인적인 생각으로 읽어 주시면 좋겠습니다. “그렇게도 생각할 수 있겠구나” 하는 정도로 편하게 봐 주셔도 충분합니다.

공부란 필요성 인지 → 지식 습득 → 체득 → 응용의 과정이다.

이 네 단계는 따로 떨어진 목록이 아니라 하나의 학습 사이클입니다. 먼저 왜 필요한지 알아야 공부가 시작되고, 지식을 얻은 다음에는 직접 해 보며 체득해야 합니다. 체득한 원리는 다른 문제와 플랫폼에 응용할 수 있습니다. 이 사이클이 반복되면 자주 다루는 언어와 기술에 주종목이 생기고, 주종목의 원리를 다른 언어와 플랫폼으로 옮기는 과정에서 풀스택 역량이 만들어집니다. 1부는 이 흐름을 차례대로 따라가고, 2부는 AI가 그 흐름의 어디를 압축하는지 살펴봅니다.

이 과정을 필자는 지식 체득이라고 부릅니다. 읽고 들은 내용을 직접 다시 만들고, 실패 원인을 설명할 수 있을 때 비로소 지식 체득이 일어납니다.

여기서 말하는 개발자 학습법은 자료를 많이 소비하는 요령이 아닙니다. 필요한 지식을 골라 자기 것으로 만들고, 다시 써먹을 수 있는 소화력으로 바꾸는 절차입니다.

1. 첫 단계는 필요성 인지다

공부의 첫 단계는 책을 펴는 행위가 아닙니다. “이걸 알아야 내 문제가 풀린다”는 필요성을 알아차리는 순간입니다. 필요성이 없으면 강의 목록을 저장하고 책을 사도 실제 학습은 시작되지 않습니다.

개발자는 문제를 만나면서 공부를 시작합니다. 서버가 배포되지 않거나, 데이터 모델이 꼬이거나, 화면과 API의 계약이 어긋날 때 비로소 어떤 지식이 필요한지 질문이 선명해집니다. 좋은 학습은 막연한 호기심을 없애는 것이 아니라, 해결해야 할 문제를 더 정확한 질문으로 바꾸는 데서 출발합니다. 공부의 갈증은 다양하겠지만 갈증없이는 한모금의 물도 마실수 없습니다.

TEXT

문제 상황
  ↓
왜 막혔는가? → 필요한 개념·API·도구를 이름 붙이기
  ↓
학습 범위를 한 문장으로 제한하기

필요성 인지는 학습의 방향뿐 아니라 깊이도 정합니다. “웹을 공부한다”는 너무 넓지만, “이번 주에는 인증 토큰의 생성·검증·만료를 직접 구현한다”는 실행 가능한 목표입니다. AI에게 질문할 때도 이 문장이 있으면 답변을 모으는 대신 학습 단위를 설계할 수 있습니다.

2. 두 번째 단계는 지식 습득이다

책을 읽거나, 공식 문서를 확인하거나, 강의와 동영상을 보는 것은 모두 지식 습득의 과정입니다. 다만 화면을 재생한 시간과 지식이 내 머릿속에 남은 시간은 같지 않습니다. 흘러들어온 지식은 흘러나가기 쉽습니다.

특히 개발자는 직접 찾아 읽는 과정을 건너뛰면 나중에 문제를 재현하지 못합니다. 검색 결과의 요약이나 영상의 설명은 출발점이지 계약서가 아닙니다. API 문서의 입력·출력 조건, 예외, 버전, 권한을 원문에서 확인해야 “왜 이 코드가 동작하는지”를 설명할 수 있습니다.

Dunlosky 연구진의 학습기법 검토는 연습 테스트와 분산 학습처럼 스스로 꺼내 보는 방식이 단순 재독보다 유용할 수 있다고 정리합니다. Karpicke와 Roediger의 retrieval practice 연구도 기억에서 답을 꺼내는 행위 자체가 장기 학습에 중요한 역할을 한다고 보고했습니다. 개발자식으로 번역하면 문서를 읽은 직후 탭을 닫고, 방금 본 API를 보지 않고 설명하거나 작은 코드를 다시 작성해 보는 일입니다.

3. 세 번째 단계는 체득이다

지식을 습득했다면 반드시 체득 단계로 넘어가야 합니다. 체득은 “알고 있다”가 아니라 “처음부터 다시 만들 수 있고, 실패 원인을 좁힐 수 있다”는 상태입니다. 개발자에게 가장 좋은 체득 도구는 거대한 사이드 프로젝트가 아니라 작고 끝나는 미니 프로젝트입니다.

예를 들어 인증을 공부한다면 다음 정도면 충분합니다.

1. 로컬 데이터베이스에 사용자를 저장합니다.
2. 로그인 요청에서 짧은 수명의 access token을 발급합니다.
3. 보호된 API에서 토큰의 서명·만료·권한을 검증합니다.
4. 잘못된 토큰, 만료된 토큰, 권한이 부족한 토큰을 각각 테스트합니다.

이 과정에서 화면은 단순해도 됩니다. 중요한 것은 서버를 직접 띄우고, 데이터 모델을 만들고, 요청을 보내고, 로그와 실패 응답을 읽는 것입니다. 코드를 복사해 실행만 했다면 아직 체득한 것이 아니라 관찰만 한 것입니다.

<필요성 인지에서 응용까지 이어지는 개발자 학습 루프 1.1>

4. 네 번째 단계는 응용이다

응용은 기존 코드를 다른 곳에 붙여 넣는 일이 아닙니다. 한 문제에서 얻은 원리를 새로운 제약에 맞게 다시 설계하는 일입니다. HTML로 웹 화면을 만들던 개발자가 모바일 앱을 추가하면서 Flutter를 접할 때, 단순히 문법을 새로 외우는 것이 아니라 상태·이벤트·네트워크·배포라는 구조를 새 플랫폼의 문법으로 옮기게 됩니다. 당연히 연관된 백엔드의 새로 생겨난 예외사항들이 끊임없이 괴롭힐 것입니다. 이 과정이 응용력이 확장되는 과정입니다.

체득이 있으면 플랫폼이 바뀌어도 질문이 달라집니다. “버튼을 어떻게 그리지?”에서 “상태가 어디에 있고, 이벤트가 어떤 경계를 넘어가며, 실패를 어떻게 복구하지?”로 관심이 이동합니다. 반대로 체득 없이 응용을 시도하면 프레임워크의 기본 예제를 조합하는 수준에서 멈추고, 작은 요구사항 변화에도 전체를 다시 검색하게 됩니다.

5. 사이클의 반복이 언어와 주종목을 만든다

필자가 말한 필요성 인지 → 지식 습득 → 체득 → 응용의 사이클은 한 번 돌고 끝나지 않습니다. 개발자는 여러 프로젝트에서 이 과정을 반복하면서 자주 호출하는 언어와 기술을 발견합니다. 어떤 사람은 Java와 데이터 모델·쿼리 최적화에 강해지고, 어떤 사람은 JavaScript·TypeScript와 UI 상태·접근성에 강해지며, 또 다른 사람은 C++와 메시지 큐·분산 시스템을 주종목으로 삼습니다. 주종목은 처음부터 정하는 직함이 아니라 반복해서 해결한 문제의 흔적입니다.

언어는 단순한 문법 목록이 아닙니다. 하나의 언어를 오래 다루면 그 언어의 모듈링 방식, 예외 처리, 동시성, 스트림, 테스트 습관, 생태계의 설계 관례가 몸에 밴다는 뜻입니다. 반복된 체득이 쌓이면 “문법을 안다”를 넘어 “이 언어로 이 문제를 어떻게 설계하는지를 안다”는 수준에 도달합니다. 이것이 주종목의 실력입니다.

여기서 중요한 점은 주종목과 시야를 맞바꾸지 않는 것입니다. 한 분야를 깊게 파되, 다른 분야의 언어와 실행 환경을 조금씩 만져야 설계의 선택지를 비교할 수 있습니다. 미니 프로젝트를 여러 번 끝낸 사람은 “이 기능을 어디에 넣을까”뿐 아니라 “이 기능을 이 경계에 넣는 것이 맞나”를 묻게 됩니다.

6. 주종목의 깊이가 풀스택으로 이어지는 과정

주종목이 생겼다고 해서 다른 분야를 닫아 버리는 것은 아닙니다. 다양한 프로젝트를 반복하면 개인적인 지식의 양이 늘고, 분야를 가리지 않고 조금씩 찍먹한 체득이 생깁니다. 이때 한 언어와 주종목의 모듈링·아키텍처링은 극도로 발전하고, 디자인 패턴·아키텍처·스레딩·스트림 같은 핵심 코어 이해력이 설계에 자유롭게 응용됩니다.

핵심은 설계가 언어에 묶이지 않는 순간입니다. 아키텍처와 설계가 특정 언어의 문법에서 벗어나면, 다른 언어의 간단한 문법을 이용해 비슷한 패턴을 구현할 수 있습니다. HTML로 웹사이트를 만들던 개발자가 Flutter로 앱을 추가할 때도 마찬가지입니다. 문법은 갈아 끼우지만 상태, 이벤트, 데이터 경계, 오류 처리라는 설계의 뼈대는 옮겨 갑니다.

같은 설계가 언어별로 어떻게 대응되는지 확인해 보겠습니다. 예시는 소셜 로그인 provider입니다. SocialSession은 로그인 결과의 공통 계약이고, SocialContract<T>는 특정 provider가 반환할 세션 타입을 제한합니다. AuthProviderFactory<T>는 공통 로그인 흐름을 감싸고, Google 구현은 GoogleSession만 반환하도록 컴파일 단계에서 보장합니다.

Java에서는 T extends SocialSession과 인터페이스 구현으로 이 관계를 표현합니다.

JAVA

interface SocialSession {
    String accessToken();
}

interface SocialContract<T extends SocialSession> {
    T login(String authorizationCode);
}

abstract class AuthProviderFactory<T extends SocialSession> {
    protected abstract SocialContract<T> contract();

    public T login(String authorizationCode) {
        return contract().login(authorizationCode);
    }
}

record GoogleSession(String accessToken) implements SocialSession {}

final class GoogleProviderFactory
        extends AuthProviderFactory<GoogleSession> {
    @Override
    protected SocialContract<GoogleSession> contract() {
        return code -> new GoogleSession("google:" + code);
    }
}

TypeScript에서는 extends 제약과 구조적 타입을 사용합니다. 런타임에는 제네릭이 사라지지만, 컴파일할 때 Google provider가 GoogleSession을 반환하는지 검사합니다.

TYPESCRIPT

interface SocialSession {
  accessToken: string;
}

interface SocialContract<T extends SocialSession> {
  login(authorizationCode: string): T;
}

abstract class AuthProviderFactory<T extends SocialSession> {
  protected abstract contract(): SocialContract<T>;

  login(authorizationCode: string): T {
    return this.contract().login(authorizationCode);
  }
}

type GoogleSession = SocialSession & { provider: "google" };

class GoogleProviderFactory extends AuthProviderFactory<GoogleSession> {
  protected contract(): SocialContract<GoogleSession> {
    return {
      login: (code) => ({
        accessToken: `google:${code}`,
        provider: "google",
      }),
    };
  }
}

C#에서는 where T : ISocialSession 제약으로 같은 설계를 표현합니다.

CSHARP

public interface ISocialSession
{
    string AccessToken { get; }
}

public interface ISocialContract<T> where T : ISocialSession
{
    T Login(string authorizationCode);
}

public abstract class AuthProviderFactory<T> where T : ISocialSession
{
    protected abstract ISocialContract<T> Contract { get; }

    public T Login(string authorizationCode)
        => Contract.Login(authorizationCode);
}

public sealed record GoogleSession(string AccessToken) : ISocialSession;

public sealed class GoogleProviderFactory
    : AuthProviderFactory<GoogleSession>
{
    protected override ISocialContract<GoogleSession> Contract
        => new GoogleContract();

    private sealed class GoogleContract : ISocialContract<GoogleSession>
    {
        public GoogleSession Login(string code)
            => new($"google:{code}");
    }
}

세 언어의 문법은 다르지만 구조는 같습니다. 세션 계약, 제네릭 provider 계약, 공통 factory, Google 구현이라는 설계가 그대로 이동합니다. 이것이 주종목의 경험이 다른 언어로 전이되는 실제 모습입니다.

이 경험이 쌓이면 새로운 프레임워크, 언어, 컴파일 시스템을 접해도 완전히 낯선 세계처럼 느끼지 않게 됩니다. 처음부터 모든 것을 아는 것이 아니라, 이미 체득한 설계 원리를 새로운 환경에 번역할 수 있기 때문입니다.

<주종목의 설계를 다른 플랫폼으로 옮기는 응용의 모습 6.1>

7. 풀스택은 기술 목록이 아니라 기술전이 능력

국내에서 풀스택은 보통 프론트엔드와 백엔드를 함께 개발한다는 뜻으로 쓰입니다. 그 정의는 실무적으로 유용하지만, 더 무거운 의미의 풀스택은 언어 목록이 아니라 낯선 기술을 빠르게 응용 레벨까지 끌어올리는 전이 능력에 가깝습니다. 사실 풀스택 개발자라고 모든 기술을 모두 꿰다시피 외우는건 불가능 합니다.

필자는 풀스택 개발자를 “세상의 모든 기술을 아는 사람”이 아니라, 새로운 기술을 2주 안팎의 집중 실험으로 업무에 연결할 수 있는 숙련자라고 봅니다. 이 말은 모든 기술을 2주 만에 마스터한다는 뜻이 아닙니다. 공식 문서에서 핵심 계약을 찾고, 작은 실행 환경을 만들고, 실패를 기록하고, 기존 설계와 비교해 사용할 수 있다는 뜻입니다.

이런 수준은 단기간의 요령으로 생기지 않습니다. 필자는 빠르면 5년, 꾸준하지만 느린 속도로 가도 15년 정도면 비슷한 전이 능력에 도달할 수 있다고 믿습니다. 중요한 것은 연차를 채우는 일이 아니라, 그 시간 동안 필요성 인지부터 응용까지의 사이클을 실제 프로젝트에서 몇 번이나 제대로 반복했는가입니다.

TEXT

새 기술
  ├─ 핵심 개념 3개 찾기
  ├─ 최소 실행 예제 만들기
  ├─ 실패 사례 2~3개 재현하기
  ├─ 기존 주종목의 설계와 비교하기
  └─ 실제 문제에 작은 범위로 적용하기

이 전이 능력은 다음 회차에서 더 중요해집니다. AI는 지식 습득의 속도를 크게 높이지만, 체득과 응용까지 자동으로 대신해 주지는 않기 때문입니다.

마무리: 공부의 단위는 결과물이 되어야 한다

개발자의 학습은 필요성 인지에서 시작해 지식 습득, 체득, 응용으로 이어집니다. 문서를 읽고 영상을 보는 것은 필요한 과정이지만, 작은 서버·화면·데이터 모델·테스트를 직접 끝내야 지식이 개인의 도구가 됩니다. 반복된 체득이 주종목을 만들고, 주종목의 원리를 다른 언어와 플랫폼으로 옮길 수 있을 때 풀스택 전이 능력이 생깁니다.

다음 2부에서는 이 구조가 AI 시대에 어떻게 압축되는지, AI를 답안 자동판매기가 아니라 원천 지식을 파고드는 학습 파트너로 쓰려면 어떤 질문과 검증 루프가 필요한지 살펴보겠습니다.

시리즈 전체 회차

1. 1회 AI 시대의 학습 1 - 지식은 어떻게 내 것이 되는가 (현재 글)
2. 2회 AI 시대의 학습 2 - 황금사과를 먹는 사람과 감상하는 사람