일단 해결하고 나중에 알아보는 사람의 함정

by 그릿 | GROWTH_ESSAY | 2026-04-20

학습 스타일을 물어봤습니다.

"문제가 발생하면 GPT를 돌려서든 구글링을 해서라든지 어떻게든 해결책을 찾아서 에러를 해결하는 방법인 것 같고, 그 후에 이제 좀 알아보는 것 같습니다. 제대로. 왜 이런 문제가 발생했는지."

왜 이렇게 하냐고 물었습니다.

"어떻게든 프로젝트를 돌아가게 만들어야 된다고 생각하기 때문에."

이해됩니다. 합리적입니다. 현업에서도 이 방식이 통하는 순간은 있습니다. 장애가 터졌을 때 원인 분석보다 복구가 먼저입니다. 일정이 급할 때 완벽한 이해보다 작동이 먼저입니다.

"일단 돌아가게 만들고 나중에 공부하겠다."

주니어 개발자에게 가장 흔한 학습 전략입니다.

문제는 "나중에"가 오지 않는다는 겁니다.

"나중에"는 오지 않습니다

에러가 터집니다. GPT에 물어봅니다. 답을 받습니다. 복붙합니다. 돌아갑니다. 해결입니다.

"나중에 왜 그런지 알아봐야지."

다음 기능을 만듭니다. 또 에러가 터집니다. 또 GPT에 물어봅니다. 또 해결합니다.

"이것도 나중에 알아봐야지."

기능이 완성됩니다. 다음 기능으로 넘어갑니다. 또 에러, 또 해결, 또 나중에.

프로젝트가 끝납니다. 돌아가긴 합니다. 완성이긴 합니다.

그런데 "나중에"는 언제 오나요?

프로젝트가 끝나면 다음 프로젝트를 시작합니다. 아니면 취업 준비를 합니다. 아니면 다른 공부를 합니다. 이미 끝난 프로젝트의 에러를 다시 열어보는 사람은 거의 없습니다.

맥락도 잊어버렸습니다. 그때 왜 그 에러가 났는지, 뭘 검색했는지, 뭘 복붙했는지. 기억이 안 납니다. 다시 보려면 처음부터 파악해야 합니다. 귀찮습니다. 안 합니다.

"나중에"는 구조적으로 오지 않습니다.

프로젝트는 완성되는데 개발자는 성장하지 않습니다

이 방식으로 프로젝트는 완성됩니다.

기능이 돌아갑니다. 배포됩니다. 깃허브에 올라갑니다. README도 씁니다.

그런데 끝나고 나면 남는 게 없습니다.

"레디스가 이런 장점이 있으니까 사용하면 좋겠지라고만 생각하고 적용했거든요. 나중에 이력서에 적을 때 그냥 '이런 장점이 있어서 Redis를 사용했어요' 밖에 안 되더라고요."

이력서에 쓸 게 없습니다.

"왜 Redis였나요?" 답을 못 합니다.
"다른 방법은 고려 안 해봤나요?" 답을 못 합니다.
"성능은 얼마나 개선됐나요?" 측정 안 했습니다.

프로젝트는 있는데, 할 말이 없습니다. 돌아가게 만들었는데, 왜 돌아가는지 모릅니다.

프로젝트는 완성됐는데, 개발자는 성장하지 않은 상태입니다.

해결과 이해 사이의 간격

"일단 해결"이 나쁜 건 아닙니다.

급할 때는 해결이 먼저입니다. 장애가 터졌는데 "잠깐, 원인부터 이해하고 고치겠습니다" 하면 안 됩니다. 일단 고치고, 나중에 분석하는 게 맞습니다.

문제는 그 "나중에"까지의 간격입니다.

간격이 5분이면 괜찮습니다. 해결하고, 바로 "왜 이게 답이었지?" 정리합니다. 맥락이 생생할 때 이해합니다. 몸에 붙습니다.

간격이 "나중에"면 안 됩니다. 나중에는 안 오니까요. 맥락은 사라지고, 기억은 희미해지고, 결국 안 합니다.

해결과 이해 사이의 간격을 얼마나 짧게 유지하느냐. 이게 차이를 만듭니다.

5분의 차이

같은 에러를 만났습니다. 같은 방법으로 해결했습니다.

A는 해결하고 바로 넘어갑니다. "나중에 알아봐야지."

B는 해결하고 5분을 씁니다. "왜 이게 됐지? 이 옵션이 뭐지? 다른 방법은 없었나?"

하루에 에러를 3개 만난다고 칩시다. A는 3개 해결하고 0개 이해합니다. B는 3개 해결하고 3개 이해합니다.

일주일이면 A는 0개, B는 21개.
한 달이면 A는 0개, B는 90개.
8주면 A는 0개, B는 168개.

같은 시간을 썼습니다. 같은 에러를 만났습니다. 8주 후에 완전히 다른 사람이 됩니다.

5분입니다. 해결한 직후의 5분. 이게 쌓이면 차이가 됩니다.

맥락이 살아있을 때

왜 해결 직후여야 할까요?

맥락이 살아있기 때문입니다.

에러를 만났을 때, 그 상황이 생생합니다. 뭘 하다가 터졌는지, 어떤 코드를 건드렸는지, 어떤 메시지가 나왔는지. 다 기억납니다.

이 상태에서 "왜?"를 물으면 연결이 됩니다. "아, 이래서 이게 터졌구나. 이 옵션이 이런 의미구나. 다음에는 이렇게 해야겠구나."

일주일 후에 다시 보면요? 맥락이 없습니다. "이게 뭐였더라?" 처음부터 다시 파악해야 합니다. 시간도 더 들고, 연결도 안 됩니다.

해결한 바로 그 순간이 이해할 수 있는 유일한 타이밍입니다. 그 타이밍을 놓치면 다시 안 옵니다.

실용성은 유지하면서

실용적인 접근을 버리라는 게 아닙니다.

일단 해결해야 합니다. 프로젝트는 돌아가야 합니다. 일정은 지켜야 합니다. 완벽하게 이해하고 코딩하겠다고 하면 아무것도 못 만듭니다.

다만 "나중에"를 믿지 마세요.

나중에는 안 옵니다. 해결한 직후 5분이라도 쓰세요. "왜 이게 됐지?" 한 줄이라도 정리하세요.

그 5분이 쌓이면, 프로젝트가 끝났을 때 남는 게 달라집니다. 이력서에 쓸 게 생깁니다. 면접에서 할 말이 생깁니다.

정리하면

"일단 해결하고 나중에 알아본다."

주니어 개발자에게 가장 흔한 학습 전략입니다. 합리적으로 들립니다.

하지만 "나중에"는 오지 않습니다. 해결하면 다음 에러가 오고, 그걸 또 해결하면 다음 기능을 만들어야 합니다. "나중에"가 끼어들 틈이 구조적으로 없습니다.

프로젝트는 완성되는데, 개발자는 성장하지 않습니다. 돌아가게 만들었는데, 왜 돌아가는지 모릅니다.

해결과 이해 사이의 간격을 짧게 유지하세요. 해결한 직후 5분이라도 쓰세요.

"나중에"를 믿지 마세요. 나중에는 오지 않습니다.

해결한 바로 그 순간이, 이해할 수 있는 유일한 타이밍입니다.