"어린 시절의 컴퓨팅" - 제약이 만든 진짜 학습에 대한 회고

느린 컴퓨터가 오히려 좋은 선생이었다

Susam Pal이라는 개발자가 자신의 블로그에 쓴 "Childhood Computing"이라는 글이 잔잔한 공감을 일으키고 있어요. 이 글은 인도에서 자란 한 개발자가 1990년대 후반~2000년대 초반, 변변치 않은 컴퓨터 한 대로 프로그래밍을 익혔던 시절을 회고하는 내용입니다. 단순한 추억담이 아니라, "왜 그 시절의 제약이 오히려 더 깊은 학습을 가능하게 했는가"라는 질문을 던지고 있어요.

저자는 어릴 때 인터넷도, 스택오버플로우도, 유튜브 튜토리얼도 없는 환경에서 컴퓨터를 만났습니다. 가진 거라곤 286이나 386 PC 한 대, DOS 운영체제, 그리고 동네 도서관이나 친척 집에서 어렵게 빌려온 책 몇 권이 전부였대요. 그 환경에서 GW-BASIC, QBasic, 그리고 나중에는 Turbo C까지 손으로 더듬어가며 배웠다고 합니다.

제약이 학습 방식을 바꾼다

글에서 특히 인상적인 대목은 "검색할 수 없으니 읽을 수밖에 없었다"는 회고예요. 요즘은 에러 메시지를 그대로 복사해서 검색창에 붙여넣으면 5초 안에 답이 나오잖아요. 그런데 그 시절에는 그게 불가능했으니, 컴파일러가 뱉어내는 에러 메시지의 의미를 직접 추적해야 했어요. 변수 선언부터 다시 보고, 메모리 모델 설정을 확인하고, 헤더 파일을 한 줄씩 읽어가며 원인을 찾아야 했죠.

이게 비효율적으로 보일 수도 있는데, 저자는 오히려 이 과정이 "시스템 전체를 이해하는 감각"을 길러줬다고 이야기합니다. 예를 들어 C에서 포인터를 잘못 다뤄서 시스템이 멈춰버리는 경험을 직접 하고 나면, 메모리가 어떻게 배치되어 있는지, 스택과 힙이 뭔지, 세그멘테이션 폴트가 왜 생기는지 같은 개념이 추상적인 지식이 아니라 살아있는 경험으로 남거든요.

또 하나 흥미로운 대목은 "모든 기능을 직접 만들어봐야 했다"는 부분이에요. 라이브러리가 풍부하지 않았으니, 문자열 처리 함수도 직접 짜고, 정렬 알고리즘도 손으로 구현하고, 간단한 그래픽 루틴도 픽셀 단위로 그려야 했습니다. 요즘이라면 npm install 한 번이면 끝날 일이지만, 그땐 모든 걸 처음부터 만들어야 했죠. 그 덕분에 알고리즘과 자료구조가 머릿속에 자연스럽게 새겨졌다고 합니다.

그리고 도서관의 책 한 권

저자가 가장 애틋하게 회상하는 건 한 권의 책을 몇 달 동안 반복해서 읽었던 경험이에요. 책이 흔하지 않으니 한 권을 정말 "닳도록" 읽었고, 그러다 보니 저자의 사고방식까지 흡수하게 됐다고 합니다. 요즘처럼 30분짜리 유튜브 영상을 1.5배속으로 흘려보는 학습법과는 완전히 다른 깊이죠.

이 부분이 댓글에서도 가장 큰 공감을 얻고 있어요. "K&R(The C Programming Language)을 열 번도 넘게 정독했다", "Petzold의 Windows Programming 책으로 6개월을 보냈다" 같은 비슷한 경험담이 줄을 잇고 있습니다. 한정된 자료를 깊이 파고드는 학습이 오히려 더 견고한 기초를 만들어줬다는 거죠.

풍요로움의 역설

그렇다고 "옛날이 좋았다"는 단순한 향수에 빠지는 글은 아닙니다. 저자는 분명히 인정해요. 지금의 풍부한 자료와 도구는 분명히 축복이고, 더 많은 사람에게 프로그래밍의 문턱을 낮춰줬다고요.

다만 한 가지 짚는 게 있습니다. "빠르게 답을 얻는 것"과 "깊이 이해하는 것"은 다르다는 점이에요. ChatGPT나 Copilot에게 물어보면 코드가 바로 나오지만, 그 코드가 왜 그렇게 작동하는지 모른 채로 넘어가면 결국 응용력이 길러지지 않아요. 풍요로움이 오히려 깊은 학습을 방해할 수도 있다는 역설입니다.

한국 개발자에게 주는 시사점

이 글이 한국 개발자들에게도 울림이 있는 이유는, 우리 역시 비슷한 세대 차이를 경험하고 있기 때문이에요. 90년대에 도스에서 한메타자교사로 시작해 QBasic을 만지작거리다가 Turbo C로 넘어간 세대가 있는가 하면, 처음부터 VS Code와 Copilot으로 시작하는 세대도 있죠. 둘 사이의 학습 깊이가 다른 건 분명한데, 그게 누구의 잘못은 아닙니다. 환경이 다른 거니까요.

실무 관점에서 우리가 가져갈 수 있는 교훈은 두 가지인 것 같아요. 첫째, 가끔은 일부러 "제약 있는 환경"을 만들어보는 게 좋습니다. 예를 들어 일주일에 하루는 AI 어시스턴트 없이 코드를 짜본다든가, 라이브러리 의존성을 최소화한 토이 프로젝트를 만들어본다든가. 이런 "수련" 같은 시간이 기초 체력을 길러줍니다.

둘째, 한 권의 책을 깊이 읽는 경험을 의식적으로 만들어보는 거예요. 요즘은 책 한 권을 끝까지 읽는 사람이 드물잖아요. 운영체제든, 컴파일러든, 네트워크든, 한 분야의 정통 교과서 하나를 골라 6개월 동안 천천히 정독해보는 것. 검색으로는 절대 얻을 수 없는 체계적인 이해를 줍니다.

마무리

도구가 풍부해진 시대일수록, 오히려 도구 없이 사고하는 훈련이 더 중요해지는 것 같아요. 빠른 답이 깊은 이해를 대체하지는 못하니까요.

여러분의 "첫 컴퓨터"는 무엇이었나요? 그리고 그 시절의 제약이 지금의 개발자로서의 여러분에게 어떤 흔적을 남겼다고 생각하시나요?