Skip to content

Commit eb3cca6

Browse files
committed
docs(blog): AI 시대 학습법 글 추가
실습, 이론, 다시 실습으로 이어지는 학습 루프를 정리한 글을 추가했어요. 정반합 회고와 실제 사례, 리스트 미리보기용 메타데이터, 썸네일을 함께 반영했어요.
1 parent db66a2d commit eb3cca6

3 files changed

Lines changed: 310 additions & 0 deletions

File tree

Lines changed: 296 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,296 @@
1+
> "기초를 다 닦은 뒤에 시작하라"는 말보다
2+
> "일단 만들고, 왜 돌아가는지 끝까지 파고들라"는 말이 더 크게 와닿을 때가 있어요.
3+
4+
AI 시대에는 답을 빨리 찾는 것보다 질문을 만들고 검증하는 순서가 더 중요해졌어요.
5+
6+
최근에 읽은 글 하나가 오래 남았어요.
7+
고졸 출신으로 OpenAI 연구원이 된 가브리엘 피터슨의 이야기였어요.
8+
9+
제가 더 크게 본 건 화려한 커리어보다 학습 순서였어요.
10+
기초를 완벽하게 쌓은 뒤에 움직이기보다, 일단 프로젝트를 만들고, 막히는 개념을 끝까지 파고들고, 다시 구현으로 돌아와 이해를 확인하는 방식이었거든요.
11+
12+
돌아보면 저도 꽤 오래 비슷하게 배워왔어요.
13+
지금은 그 흐름을 조금 더 또렷하게 설명할 수 있어요.
14+
15+
- 먼저 실습해요.
16+
- 그다음 이론으로 기준을 붙잡아요.
17+
- 다시 실습으로 돌아가 이해를 검증해요.
18+
19+
이 글에서는 이 세 단계가 왜 제 학습의 중심이 됐는지, 왜 AI 시대에 더 강해졌는지, 실제로 어떤 장면에서 돌아가는지 정리해보려고 해요.
20+
21+
---
22+
23+
## AI 시대에는 학습 순서가 더 중요해졌어요
24+
25+
예전에는 모르는 걸 찾는 일 자체가 큰 비용이었어요.
26+
지금은 AI가 초안도 주고, 개념도 설명하고, 구현 방향도 제안해줘요.
27+
28+
문제는 여기서부터예요.
29+
답이 빨라질수록 무엇을 먼저 묻고, 어디까지 믿고, 어떤 방식으로 다시 확인할지가 더 중요해져요.
30+
31+
같은 도구를 써도 누군가는 훨씬 빠르게 자기 것으로 만들고, 누군가는 그저 소비하고 끝나요.
32+
저는 그 차이가 답변의 속도보다 질문의 순서에서 나온다고 생각해요.
33+
34+
저한테 학습은 단순히 모르는 걸 채우는 일이 아니에요.
35+
이미 가진 감각으로 먼저 부딪혀보고, 문서와 질문으로 흔들어보고, 다시 더 단단한 방식으로 묶어내는 과정에 가까워요.
36+
37+
그래서 중요한 건 더 많이 아는지가 아니에요.
38+
제가 이미 알고 있는 것을 어디까지 의심해보고, 어떻게 다시 제 것으로 묶어내느냐가 더 중요해요.
39+
40+
**정리: AI 시대에는 답을 빨리 받는 능력보다 질문과 검증의 순서를 설계하는 능력이 더 중요해요.**
41+
42+
---
43+
44+
## 먼저 만들면서 질문을 드러내요
45+
46+
저는 배울 때 준비가 다 끝날 때까지 기다리지 않아요.
47+
대신 결과물부터 만들어요.
48+
49+
그래야 제가 뭘 모르는지 바로 드러나거든요.
50+
어디서 막히는지, 무엇이 애매한지, 어떤 판단이 비어 있는지가 손에 잡혀요.
51+
52+
[`기술 블로그를 일주일 만에 만들 수 있었던 것`](/blog/blog-system-building)도 같은 흐름이었어요.
53+
처음부터 설계 원칙과 렌더링 전략을 완벽하게 이해한 상태로 시작한 건 아니었어요. 먼저 원하는 화면과 흐름을 정했고, 그다음 Next.js, MDX, 렌더링 구조, 스타일 시스템을 만들면서 하나씩 붙잡아 갔어요.
54+
55+
중요했던 건 속도 자체가 아니었어요.
56+
"실제로 움직이는 걸 먼저 만든 뒤, 그 구조를 이해한다"는 순서가 저한테 더 잘 맞았어요.
57+
58+
결과물이 생기면 질문도 선명해져요.
59+
60+
- 왜 이 구조에서는 빌드 타임이 안정적일까요?
61+
- 왜 이 컴포넌트는 서버에서 처리하고, 저건 클라이언트에서 처리할까요?
62+
- 왜 같은 UI라도 구현 방식에 따라 유지보수 난이도가 달라질까요?
63+
64+
이런 질문은 책 한 권 읽는다고 바로 생기지 않아요.
65+
직접 만들다가 막히고, 고치고, 설계를 다시 만져볼 때 비로소 생겨요.
66+
67+
그래서 저한테 실습은 단순한 출력 단계가 아니에요.
68+
좋은 질문을 만드는 장치에 더 가까워요.
69+
70+
**정리: 먼저 만들면 배워야 할 범위가 막연한 관심사에서 구체적인 질문으로 바뀌어요.**
71+
72+
---
73+
74+
## 공식 문서로 기준을 붙잡아요
75+
76+
질문이 생긴 뒤에야 이론이 오래 남아요.
77+
그때부터는 "왜 이게 이렇게 돌아가지?"를 설명할 수 있어야 하거든요.
78+
79+
저는 그 지점에서 강의보다 공식 문서로 들어가요.
80+
읽기 어렵더라도 결국 기준이 되는 문장은 공식 문서 안에 있다고 믿기 때문이에요.
81+
82+
물론 처음부터 술술 읽히진 않아요.
83+
그래서 그냥 읽고 지나가지 않아요. 번역하고, 다시 풀어쓰고, 제 언어로 재구성해요.
84+
85+
문서를 읽다가 막히면 거기서 멈추지 않아요.
86+
모르는 단어를 다시 찾고, 관련 개념을 옆으로 넓히고, 예제를 복기하면서 문장을 제 것으로 바꿔요.
87+
88+
Redis나 Flink처럼 실무에서 자주 마주치거나 앞으로 더 깊게 써야 할 기술은 특히 이런 방식으로 붙잡아요.
89+
작동은 시킬 수 있어도, 왜 그렇게 동작하는지 설명하려고 하면 말이 막히는 순간이 오거든요.
90+
91+
그 간격을 메울 때 AI도 큰 도움이 돼요.
92+
다만 저는 AI를 정답지보다 해설가에 가깝게 써요. 문서에서 읽은 추상 개념을 더 잘 이해하도록 질문을 던지는 도구로 써요.
93+
94+
> 이해가 흐릿한 채로 넘어가고 싶지 않아요.
95+
> 읽고 끝내지 않고, 번역하고 정리하면서 제 언어로 다시 만들어요.
96+
97+
> **Tip. AI에게 끝까지 묻는 방식**
98+
>
99+
> - "왜 이 코드가 작동하지? 원리가 뭐지?"
100+
> - "어떤 선택지가 있었고, 왜 이 방법을 선택한거지?"
101+
> - "중간 과정은 어떻게 변하는거지?"
102+
> - "하드웨어 수준까지 연결해서 설명해"
103+
> - "내가 12살이라고 생각하고 현실 세계의 사물 기준으로 설명해"
104+
105+
저는 이 질문을 반복하면서 문서에서 읽은 추상 개념을 실제 이해로 바꿔가요.
106+
107+
누가 잘 정리한 강의를 듣는 것도 분명 도움이 돼요.
108+
그런데 저한테는 직접 문서를 번역하고 구조화하는 과정이 훨씬 오래 남아요.
109+
110+
**정리: 공식 문서는 정보를 많이 읽는 곳이 아니라, 판단 기준을 붙잡는 곳이에요.**
111+
112+
---
113+
114+
## 다시 만들어 보면서 이해를 검증해요
115+
116+
문서를 읽고 나면 끝난 것처럼 느껴질 때가 있어요.
117+
그런데 읽었다와 이해했다 사이에는 늘 간격이 남아요.
118+
119+
그래서 다시 결과물로 돌아가요.
120+
정말 제 것이 됐는지는 다시 만들어보면 바로 드러나거든요.
121+
122+
이론을 읽은 뒤에 구현으로 다시 들어가면 처음에는 보이지 않던 구조가 보여요.
123+
예전에는 "일단 돌아가니까 됐다"에서 멈춘 적이 많았는데, 지금은 그 상태를 오래 두지 않으려고 해요.
124+
125+
왜 이렇게 설정해야 하는지, 다르게 바꾸면 어떤 문제가 생기는지, 어디까지가 도구의 책임이고 어디부터가 제 책임인지까지 확인하려고 해요.
126+
127+
이 단계에서는 질문이 꼬리를 물어요.
128+
129+
- 이 선택이 왜 맞는지 다시 물어요.
130+
- 대안은 무엇인지 확인해요.
131+
- 데이터나 상태가 중간에서 어떻게 바뀌는지 봐요.
132+
- 같은 목적을 더 단순하게 달성할 수 있는지도 따져봐요.
133+
134+
이렇게 해야 비로소 제 코드가 돼요.
135+
그냥 붙여 넣은 코드는 제 경험으로 남지 않아요.
136+
137+
> **주의. AI가 답해도 검증은 제가 해요**
138+
>
139+
> AI는 이해 속도를 크게 올려줘요.
140+
> 하지만 정확성, 책임, 최종 판단까지 대신해주진 않아요.
141+
> 그래서 저는 AI를 지름길보다 해설가에 가깝게 써요.
142+
143+
**정리: 이해는 읽을 때 끝나지 않고, 다시 만들 때 비로소 검증돼요.**
144+
145+
---
146+
147+
## 넓게 밟아본 시간도 지금은 강점이 돼요
148+
149+
돌아보면 저는 오랫동안 실무를 먼저 배웠어요.
150+
UIUX, 디자인, 프론트엔드, 백엔드, 데이터, 인프라를 두루 건드렸지만 어느 하나를 학교 커리큘럼처럼 체계적으로 깊게 밟아온 건 아니었어요.
151+
152+
그 시기에는 이게 종종 약점처럼 느껴졌어요.
153+
넓게는 아는데, 왜 그런지 설명하려고 하면 허전한 구간이 보였거든요.
154+
155+
그런데 AI가 생긴 뒤 이 경험의 의미가 달라졌어요.
156+
여러 영역을 조금이라도 밟아본 사람은 문제의 좌표를 빨리 잡아요. 이게 디자인의 문제인지, 구조의 문제인지, 데이터 흐름의 문제인지, 운영 방식의 문제인지 감을 빠르게 잡을 수 있거든요.
157+
158+
AI는 바로 그다음 단계에서 큰 힘을 발휘해요.
159+
이미 밟아본 지형 위에서 빠진 이론과 세부 개념을 훨씬 빠르게 메워주기 때문이에요.
160+
161+
그래서 지금의 경쟁력은 단순히 많이 아는 데서만 나오지 않는다고 생각해요.
162+
여러 영역의 조각을 연결하고, 부족한 이론을 빠르게 보강하는 능력에서도 나와요.
163+
164+
이건 "제너럴리스트가 무조건 좋다"는 얘기를 하려는 건 아니에요.
165+
넓게 경험한 시간이 더 이상 애매한 이력으로만 남지 않는다는 이야기예요.
166+
167+
**정리: 넓게 밟아본 시간은 약점으로 끝나지 않아요. AI 시대에는 연결 감각과 탐색 속도로 다시 힘을 얻어요.**
168+
169+
---
170+
171+
## 글쓰기도 같은 방식으로 익혀요
172+
173+
요즘은 글쓰기 자체도 이 루프로 다시 배우고 있어요.
174+
글맛이 좋다고 느껴지는 글을 만나면 그냥 "잘 쓴다"에서 멈추지 않아요.
175+
176+
어디서 독자의 질문을 붙잡는지, 어디서 글의 범위를 먼저 잡아주는지, 왜 중간 요약과 비유가 끝까지 읽게 만드는지 구조를 뜯어봐요.
177+
최근에는 테오의 연재 글을 읽으면서 그 패턴이 더 선명하게 보였어요.
178+
179+
독자 질문으로 문을 열고, 프롤로그로 범위를 잡고, 초반에 로드맵을 깔고, 예시와 비유로 설명한 뒤, 중간 요약과 마지막 질문으로 글을 회수하더라고요.
180+
181+
그걸 보면서 글맛이 좋다는 건 결국 문장이 예쁜 것만은 아니라는 생각도 했어요.
182+
독자가 길을 잃지 않게 계속 안내하는 힘, 그래서 끝까지 읽게 만드는 구조가 함께 있어야 하더라고요.
183+
184+
저도 이걸 그대로 흉내 내기보다, 제 글에 맞는 방식으로 배우고 적용해보려고 해요.
185+
소제목은 목차 역할을 하게 두고, 질문은 본문 안에서 독자와 호흡을 만드는 데 쓰는 쪽이 저한테 더 잘 맞는다고 느껴요.
186+
187+
> **Tip. 글맛이 좋은 글을 읽을 때 제가 보는 기준**
188+
>
189+
> - 첫 화면에서 독자의 질문을 바로 붙잡는지 봐요.
190+
> - 초반에 이 글의 범위와 흐름을 먼저 알려주는지 봐요.
191+
> - 추상적인 개념을 비유나 사례로 내려주는지 봐요.
192+
> - 중간마다 `정리:` 같은 표지판으로 길을 다시 보여주는지 봐요.
193+
> - 마지막에 독자에게 다시 말을 걸며 생각을 남기는지 봐요.
194+
195+
좋은 글을 읽고 구조를 분해하고, 제 글에 다시 적용해보면서 이해를 검증하는 일도 결국 같은 학습이라고 느껴요.
196+
197+
**정리: 글쓰기도 결과물을 읽고, 구조를 이해하고, 다시 제 방식으로 적용해보는 학습이에요.**
198+
199+
---
200+
201+
## 실제로는 이렇게 돌아가요
202+
203+
추상적으로만 말하면 그럴듯하게 들릴 수 있어요.
204+
그래서 이번에는 실제로 제 학습 루프가 어떻게 돌았는지, 두 장면으로 나눠서 적어볼게요.
205+
206+
### 사례 1. 기술 블로그를 만들 때
207+
208+
기술 블로그를 만들기 전부터 머릿속에는 원하는 화면이 있었어요.
209+
신문처럼 차분한 분위기, 오래 읽어도 피곤하지 않은 레이아웃, 코드와 글이 자연스럽게 섞이는 구조 같은 것들이었어요.
210+
211+
그런데 그걸 구현하는 방법을 처음부터 다 알고 있진 않았어요.
212+
Next.js App Router를 어떤 경계로 나눌지, MDX 콘텐츠를 어떻게 읽어올지, 목차와 읽기 진행도를 어떤 식으로 붙일지, 전부 손으로 부딪히며 알아갔어요.
213+
214+
이 지점에서 먼저 꺼내 쓴 건 프론트엔드 감각이었어요.
215+
어떤 화면이 읽기 편한지, 어떤 인터랙션이 과한지, 어떤 디자인이 글의 집중을 깨는지는 경험적으로 어느 정도 알고 있었거든요.
216+
217+
하지만 감각만으로는 오래 못 가요.
218+
그래서 공식 문서와 레퍼런스를 다시 읽고, AI에게 계속 반문했어요.
219+
220+
- MDX 기반 블로그 시스템을 SSG로 구현하려고 하는데 구조를 어떻게 잡아야 하지?
221+
- `meta.json`을 굳이 분리한 이유는 뭐지?
222+
- TOC를 자동 생성하려면 어떤 방식이 가장 낫지?
223+
- 이 코드는 지금 동작은 하는데, 성능까지 괜찮다고 볼 수 있나?
224+
225+
이렇게 질문을 던지다 보면 처음에 막연했던 감각이 설명 가능한 판단으로 바뀌어요.
226+
예쁜 블로그를 만들고 싶다는 욕심이, 유지보수 가능한 시스템을 설계하자는 목표로 바뀌는 순간이 와요.
227+
228+
그래서 이 블로그는 단순히 빨리 만든 결과물이 아니에요.
229+
이미 알고 있던 것과 새롭게 검증한 판단을 다시 묶어서 만든 학습 결과물에 더 가까워요.
230+
231+
### 사례 2. 공식 문서를 번역하고 시리즈로 이어갈 때
232+
233+
Redis나 Flink처럼 실무에서 계속 마주치는 기술은 이상하게도 "쓴다"와 "안다" 사이에 큰 간격이 있어요.
234+
작동은 시킬 수 있는데, 왜 그렇게 동작하는지 설명하려고 하면 갑자기 말이 막히는 순간이 오거든요.
235+
236+
예전에는 그 간격을 적당히 넘기고 지나간 적도 많았어요.
237+
하지만 지금은 그 구간을 그냥 두면 결국 다시 돌아오게 된다는 걸 알아요.
238+
239+
그래서 공식 문서로 내려가요.
240+
개념을 읽고, 번역하고, 제 언어로 다시 정리하고, 필요하면 시리즈 글로 이어가요.
241+
242+
여기서 중요한 건 읽고 끝내지 않는 거예요.
243+
왜 이런 제약이 생기는지, 다른 선택지는 왜 덜 적합한지, 운영 환경에서는 어떤 기준으로 판단해야 하는지를 끝까지 물어요.
244+
245+
이 과정을 거치면 문서 내용이 지식으로만 남지 않아요.
246+
실무에서 겪었던 장면과 문서 속 설명이 서로 연결되기 시작해요.
247+
248+
완전 정복 시리즈를 쓰는 이유도 결국 여기에 있어요.
249+
배운 걸 정리하려는 목적도 있지만, 제가 정말 이해했는지를 끝까지 확인하는 검증 단계이기도 해요.
250+
251+
**정리: 실제 사례를 넣으면 학습법이 주장으로만 남지 않아요. 어떤 장면에서 어떻게 작동했는지가 함께 보여요.**
252+
253+
---
254+
255+
## 돌아보면 이건 정반합의 리듬이었어요
256+
257+
한동안은 이걸 그냥 제 성향이라고 생각했어요.
258+
일단 만들어보고, 막히면 끝까지 파고들고, 다시 손으로 확인하는 습관 말이에요.
259+
260+
그런데 블로그를 만들고, 공식 문서를 번역하고, 완전 정복 시리즈로 이어가다 보니 그 흐름이 조금 더 또렷하게 보였어요.
261+
늘 같은 순서가 반복되고 있었거든요.
262+
263+
먼저 제가 이미 알고 있는 감각과 경험이 나와요.
264+
어떤 화면이 읽기 편한지, 어떤 구조가 오래 버틸지, 어디가 위험한지 먼저 짐작해보는 단계예요. 이게 제 학습의 ``이에요.
265+
266+
그다음에는 그 감각을 그냥 믿고 밀어붙이지 않아요.
267+
문서를 읽고, AI에게 반문하고, 리뷰를 받고, 다른 선택지를 늘려봐요. 제가 맞다고 생각한 걸 일부러 흔들어보는 단계예요. 이게 ``이에요.
268+
269+
마지막으로는 둘 중 하나를 버리지 않아요.
270+
몸으로 익힌 감각과 검증된 기준을 다시 묶어서 더 나은 구현과 더 단단한 설명으로 가져가요. 이때 비로소 결과물이 제 것이 돼요. 이게 ``이에요.
271+
272+
생각해보면 저는 새로운 걸 배울 때마다 이 리듬을 반복해왔어요.
273+
먼저 만들고, 질문하고, 다시 만들고, 그 과정을 글로 남기면서요.
274+
275+
정반합은 거창한 철학이라기보다, 제가 배울 때 늘 손으로 밟아온 순서에 더 가까워요.
276+
277+
**정리: 정반합은 따로 붙인 개념이 아니라, 제가 배우는 순서를 뒤에서 설명해주는 이름에 가까워요.**
278+
279+
---
280+
281+
## 마무리
282+
283+
AI 시대의 경쟁력은 더 많이 아는 사람보다, 끝까지 연결하는 사람에게 간다고 생각해요.
284+
285+
결과물을 만들며 질문을 만들고, 공식 문서와 반문으로 자기 감각을 흔들어보고, 다시 손으로 구현하며 더 나은 합으로 가는 사람 말이에요.
286+
287+
지금 붙잡고 있는 기술 하나를, 당신만의 정반합으로 끝까지 밀어본 적이 있나요?
288+
289+
돌아보면 이 반복은 결국 제가 아는 것에서 출발해, 그걸 흔들어보고, 더 나은 형태로 다시 묶어내는 과정이기도 해요.
290+
291+
앞으로도 저는 이 순서를 반복할 거예요.
292+
실습, 이론, 다시 실습.
293+
294+
이 단순한 루프가 지금까지 저를 가장 멀리 데려갔어요.
295+
296+
요즘 여러분은 어떤 질문을 끝까지 붙잡고 있나요?
Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
{
2+
"title": "AI 시대, 탑다운 방식으로 익히는 야생형 학습",
3+
"slug": "ai-wild-learning-style",
4+
"description": "공식 문서를 번역하고 결과물을 뜯어보며, 실무 감각과 이론을 연결하는 나만의 학습 과정을 정리하고 소개합니다.",
5+
"date": "2026-03-11",
6+
"category": "Tech",
7+
"image": "/images/posts/ai-시대-학습법/thumbnail.png",
8+
"tags": [
9+
"AI",
10+
"Career",
11+
"Work"
12+
],
13+
"featured": false
14+
}
1.96 MB
Loading

0 commit comments

Comments
 (0)