혹시 도무지 이해가 되지 않는 Rails 주제를 만난 적이 있나요?
분명 알고 있다고 생각해서 코드를 작성했는데, 정작 완전히 다른 결과가 나온 경험이 말입니다.
아니면 사실은 잘 모르면서도 어느 정도 아는 척하며 넘어왔는데, 막상 예외 케이스를 처리하다 보면 그 시간에 전문가가 됐을 만큼 많은 시간을 허비한 적은요?
꼭 그럴 필요는 없다면 어떨까요? 그냥 제대로 아는 것. 눈앞의 문제에 대한 탄탄한 멘탈 모델을 갖추는 것. 그래야 올바른 결정을 내리고 올바른 코드를 작성할 수 있습니다.
저도 웹 개발을 처음 배울 때 세션(session)이 바로 그런 존재였습니다. 어느 정도 안다고 생각했지만 사실은 아니었죠. 세션에 대한 잘못된 이해 때문에 버그가 끊이지 않았고, 그로 인해 주변에서 많은 비판을 받기도 했습니다.
곧 깨달았습니다. 세션이 실제로 어떻게 동작하는지 제대로 이해할 시간을 투자해야 한다는 것을요. 세션을 더 이상 신비롭거나 어렵게 느껴지지 않게 만드는 것, 나아가 세션의 동작을 예측하고 그 예측이 실제로 들어맞게 되는 것까지요.
세션만이 제가 깊이 파고든 유일한 주제는 아닙니다. 데이터 모델링, 캐싱, 메타프로그래밍도 마찬가지입니다. 이런 주제들은 '어느 정도' 작동하게 만들기는 쉽지만, 제대로 이해하지 못하면 끝없이 어려운 디버깅 문제에 부딪히게 됩니다.
『Practicing Rails』에서 저는 T자형 학습(T-Shaped Learning)에 대해 이야기한 바 있습니다. 폭넓은 기본기를 갖추되, 필요할 때마다 특정 주제를 깊게 파고드는 방식이죠. 바로 이런 깊은 탐구가 딥 다이브이며, 프로그래밍 커리어 전반에서 큰 문제들을 해결하는 데 큰 힘이 됩니다.
언제 딥 다이브를 해야 할까?
그렇다면 딥 다이브가 필요한 시점인지 어떻게 알 수 있을까요?
먼저, 딥 다이브를 하려면 무엇을 파고들지 명확히 알아야 합니다.
딥 다이브는 단일 주제를 다룰 때 가장 효과적입니다. 한두 단어나 짧은 구절로 설명할 수 있는 구체적인 대상 말입니다. SQL 쿼리 성능, 세션, HTTP 캐싱 같은 것들이죠. 범위가 너무 좁으면 주제를 복잡하게 만드는 요소 간의 상호작용을 놓치게 되고, 너무 넓으면 '프로그래밍'이라는 거대한 주제를 파고드는 꼴이 됩니다. 물론 그것도 엄연한 딥 다이브지만, 평생을 들여야 완주할 수 있는 여정이겠죠.
다음으로, 아래 두 가지 상황 중 하나에 해당한다면 딥 다이브를 시작해야 합니다.
자신이 뭘 하는지 '안다고' 생각했는데, 완전히 예상 밖의 일이 일어날 때. 초록 버튼을 누르면 복도 불이 켜진다는 걸 마음속으로 확실히 아는데, 정작 눌러보니 방이 무너져 내리는 상황입니다.
사실 잘 모른다는 걸 알면서도 그럭저럭 넘어와 왔는데, 이제는 더 이상 안 될 때. 버그를 고치려는데 무엇을 해봐도 해결되는 문제보다 새로 생기는 문제가 더 많아지고, 오래된 버그를 하나 고치면 새로운 버그가 또 하나 생기는 상황입니다.
이 두 상황에는 공통점이 있습니다. 자신이 잘못된 방향으로 가고 있다는 사실을 방금 인식하기 시작했다는 점이죠. 상황을 만회하길 바라더라도, 곧 많은 시간을 허비하며 발버둥 치게 될 것임을 스스로 느끼기 시작하는 겁니다.
두 가지 모두, 현재 진행 방식이 통하지 않는다는 사실을 초기에 감지하도록 돕는 신호입니다.
따라서 다음에 버그를 잡으려고 예외 케이스와 씨름하며 빙빙 돌거나, 직접 작성한 코드가 예상과 전혀 다르게 동작해 얼어붙는 순간이 온다면, 그때 느껴지는 감각을 기억하세요. 그 감각에 민감해지세요. 바로 그 감각이 멈출 시점임을 알려주는 신호입니다. 마음을 가다듬고, 이제야 제대로 이해하지 못한다는 걸 알게 된 그 주제를 깊이 학습해야 할 때입니다.
이제 딥 다이브가 필요하다고 결심했다면, 과연 어떻게 진행해야 할까요?