A를 공부했더니 B가 필요해지는 사람

by 그릿 | GROWTH_ESSAY | 2026-04-09

멘토링에서 한 분이 자기 학습 방식을 부끄러워하며 말했습니다.

"체계적으로 공부한 게 아니에요. 그냥 블로그를 만들었는데, 단순하게 AWS에 올리는 게 아니라 보안을 생각하니까 SSL이 필요하더라고요. 서버를 두 대 올리면 하나가 다운되더라도 트래픽을 이동시켜야 하잖아요. 근데 그걸 하려면 어디로 보내줄지 결정해주는 애가 필요하더라고요. 그래서 Nginx를 쓰게 됐고요. 서버가 두 개면 세션이 A서버에서 B서버로 갔을 때 로그인이 풀리면 안 되잖아요. 그래서 Redis라는 게 있구나, 알게 됐어요."

그리고 이렇게 덧붙였습니다.

"A를 공부하고 B를 공부하고, 이게 아니라 A를 공부하고 나면 A 때문에 B가 더 필요한 거예요. 그 흐름대로 공부하는 게 재미있었어요. 근데 이게 맞는 방법인지 모르겠어요."

저는 말했습니다.

"그게 가장 건강한 학습입니다."

로드맵의 함정

학습 로드맵이 넘쳐나는 시대입니다.

"백엔드 개발자 되려면 이거 순서대로 배워라."
"Java → Spring → JPA → MySQL → Redis → Kafka → Kubernetes."

친절합니다. 순서가 정해져 있습니다. 따라가기만 하면 됩니다.

그런데 이걸 따라간 사람 중에 진짜 실력 있는 개발자가 얼마나 될까요?

로드맵대로 다 배웠는데, 막상 문제가 생기면 못 푸는 사람. Java도 알고, Spring도 알고, Redis도 아는데, 왜 Redis를 써야 하는지는 모르는 사람. 기술은 다 아는데 연결이 안 되는 사람.

왜 이런 일이 생길까요?

로드맵형 학습 vs 필요 기반 학습

두 가지 학습 방식이 있습니다.

로드맵형 학습은 이렇습니다.

A를 끝내고, B를 시작하고, B를 끝내고, C를 시작합니다. 직렬 구조입니다. 체크리스트를 채웁니다. A 완료, B 완료, C 완료.

뿌듯합니다. 진도가 나갑니다. 그런데 A와 B가 왜 연결되는지 모릅니다. B와 C가 어떤 관계인지 모릅니다. 지식이 따로따로 떠 있습니다. 섬처럼 고립되어 있습니다.

필요 기반 학습은 다릅니다.

A를 하다 보니 막힙니다. "이걸 해결하려면 뭐가 필요하지?" B가 필요합니다. B를 배웁니다. B를 적용하니까 또 막힙니다. "이 문제는 뭐로 풀지?" C가 보입니다. C를 배웁니다.

A 때문에 B가 필요해지고, B 때문에 C가 필요해집니다. 지식이 연결됩니다. 그물처럼 엮입니다.

처음에 말한 멘티가 바로 이 방식이었습니다. SSL을 알게 되니 로드밸런싱이 필요해지고, 로드밸런싱을 하려니 Nginx가 필요해지고, 서버가 두 대가 되니 세션 관리를 위해 Redis가 필요해지는 구조.

본인은 체계적이지 않다고 부끄러워했지만, 사실 이게 가장 본질에 가까운 학습입니다.

왜 연결이 중요한가

AI 시대에 이 연결 감각이 더 중요해졌습니다.

AI는 A도 알고 B도 알고 C도 압니다. 물어보면 다 대답합니다. Redis가 뭔지, Nginx가 뭔지, SSL이 뭔지. 다 알려줍니다.

하지만 AI가 못 하는 게 있습니다.

"A를 하고 있는 내 맥락에서 왜 B가 필요한지"를 판단하는 것.

지금 내가 풀고 있는 문제가 뭔지, 그 문제를 풀려면 뭐가 막혀 있는지, 그 막힌 걸 뚫으려면 뭘 알아야 하는지. 이건 맥락을 아는 사람만 판단할 수 있습니다.

이 연결 감각이 없으면 AI한테 뭘 물어야 하는지조차 모릅니다. "Redis 알려줘"라고 물으면 Redis 설명이 나옵니다. 그런데 그게 지금 내 문제와 무슨 상관인지 모릅니다. 연결이 안 되니까요.

연결 감각이 있으면 다릅니다. "세션이 서버 두 대에서 공유가 안 되는데, 이걸 해결하려면 뭐가 필요해?" 이렇게 물을 수 있습니다. AI가 Redis를 알려주면, 왜 그게 필요한지 바로 이해합니다. 내 문제와 연결되니까요.

"뭘 공부해야 하나요?"라는 질문

자주 받는 질문이 있습니다.

"지금 뭘 공부해야 하나요?"

이 질문 자체가 로드맵형 사고입니다. 누군가가 정해준 다음 단계를 기다리는 거니까요.

더 나은 질문이 있습니다.

"지금 내가 만들고 있는 것에서 막히는 지점이 어디인가?"

막히는 지점이 다음 학습 주제입니다.

배포를 하려는데 서버가 자꾸 죽습니다. 왜 죽는지 모릅니다. → 로그 보는 법을 배워야 합니다.
로그를 봤더니 메모리 문제입니다. → 메모리 관리를 배워야 합니다.
메모리를 최적화했더니 이번엔 동시 접속이 문제입니다. → 동시성 처리를 배워야 합니다.

이렇게 막히는 지점을 따라가면, 다음에 뭘 배워야 하는지 자연스럽게 알게 됩니다. 누가 정해주지 않아도요.

지식의 총량이 아니라 연결의 밀도

실력은 뭘까요?

아는 것의 총량이 아닙니다. 연결의 밀도입니다.

기술 10개를 따로따로 아는 것보다, 기술 5개가 왜 연결되는지 아는 게 낫습니다. 10개를 알아도 연결이 안 되면 써먹을 수가 없습니다. 5개만 알아도 연결이 되면 문제를 풀 수 있습니다.

면접에서도 이게 드러납니다.

"Redis 써보셨네요. 왜 썼어요?"

연결이 없는 사람: "로드맵에 있어서요." "다들 쓰길래요."

연결이 있는 사람: "서버가 두 대로 늘어나면서 세션 공유 문제가 생겼어요. 인메모리 저장소가 필요했고, Redis가 적합했습니다."

같은 기술을 알아도, 면접관이 받는 인상은 완전히 다릅니다. 후자는 왜 그 기술이 필요했는지 맥락을 압니다. 다른 상황에서도 비슷한 판단을 할 수 있다는 신뢰를 줍니다.

부끄러워할 필요 없습니다

처음에 말한 멘티처럼, "체계적으로 공부하지 않았다"고 부끄러워하는 분들이 있습니다.

로드맵대로 안 했으니까. 순서대로 안 했으니까. 뭔가 제대로 안 한 것 같으니까.

아닙니다.

A를 공부했더니 B가 필요해지고, B를 공부했더니 C가 필요해지는 구조. 이게 가장 건강한 학습입니다. 지식이 연결됩니다. 맥락이 생깁니다. 써먹을 수 있는 앎이 됩니다.

로드맵은 참고만 하세요. 따라가지 마세요.

내 문제를 따라가세요. 막히는 지점을 따라가세요. 그러면 다음에 뭘 배워야 하는지 자연스럽게 알게 됩니다.

정리하면

로드맵형 학습은 체크리스트를 채우지만, 지식이 연결되지 않습니다.

필요 기반 학습은 A 때문에 B가 필요해지고, B 때문에 C가 필요해지는 구조입니다. 지식이 그물처럼 엮입니다.

AI 시대에는 이 연결 감각이 더 중요합니다. AI는 다 알지만, "지금 내 맥락에서 왜 이게 필요한지"는 사람만 판단할 수 있습니다.

"뭘 공부해야 하나요?"라고 묻지 마세요. "지금 막히는 지점이 어디인가?"를 물으세요. 막히는 지점이 다음 학습 주제입니다.

실력은 지식의 총량이 아닙니다. 연결의 밀도입니다.

그리고 그 연결은 로드맵이 아니라, 자기 문제를 풀어가는 과정에서만 생깁니다.