농구 골대가 크다는 것을 알고난 후 생긴 변화
저는 어릴 때부터 농구를 좋아했습니다. 하지만 잘 하지는 못했어요. 공을 던져서 높이 있는 골대에 넣는다는 것은 너무 어려운 일처럼 보였습니다. 그래서 슛을 많이 던지고, 많이 실패 할 때마다, “원래 공은 골대에 잘 안 들어가는 거구나” 라던가, “나는 슛을 못한다” 라는 식으로 생각했었죠.
그러던 어느 순간, 슛 능력이 갑자기 올라간 계기가 있었습니다. 바로 농구골대는 농구공 2개가 들어갈 만큼 크다 라는 사실을 알게 된 것이죠. 그 전에 슛을 쏘는 위치에서 봤을 때, 골대는 너무나 작아보였습니다. 하지만 그것은 관점이 만들어낸 착시일 뿐이었습니다.
슛을 쏘는 위치에서, 농구골대는 그렇게 커보이진 않습니다.
위에서 내려다보면, 사실 농구골대는 농구공 두 개는 들어갈 만큼 크다는 것을 알 수 있습니다.
이 사실을 알고 나서, 제 슛 능력은 비약적으로 올라갔습니다. 물론 이 사실을 알았다는 사실만으로 슛이 잘 쏴질리는 없지요. 달라진 것은 제 마음가짐이었습니다. “농구골대가 이렇게 큰데, 안 들어가는 것은 이상하다”라는 생각을 하고 나니까, “그런데 내 슛은 왜 안 들어갈까?”라는 의문이 생기고, 그 결과 “슛이 어려운 것이 아니라, 내가 뭔갈 잘못 하고 있는 거겠다. 뭘 잘못하고 있는건지 알아야겠다” 라는 결론에 도달했습니다. 그 결과 “슛의 기초를 다시 차근차근 공부”했고, 그러다보니 기존에 제가 잘못하고 있던 요소들이 눈에 들어오기 시작했습니다. 그런 요소들을 하나씩 고치기 시작하니, 마법처럼 슛은 척척 들어가기 시작했습니다. 여태까지 어떻게든 한 골이라도 넣어보려 아둥바둥 했던 제가 우스워질 만큼이요.
프로그래밍도 비슷한 측면이 있다고 생각합니다. 아마 처음 프로그래밍을 배우시는 분들, 경우에 따라서는 몇 년동안 프로그래밍을 업으로 삼으셨던 분들 중에서도 프로그래밍을 어렵다고 느끼시는 분들이 많이 있을 것이라고 생각합니다. 하지만 그렇다고 해서 “프로그래밍은 어려운 일이다”라는 생각을 갖는 것은 위험하다고 생각해요. 만약 뭔가 잘 안 풀리는 일이 생겼을 때, “그렇지, 프로그래밍은 어려운 일이지. 원래 그런거지” 라는 생각을 하게 된다면, 그 어려운 상황을 개선 할 수 있는 방법을 찾기 보다는 그 상황을 받아드리고 체념하게 될 가능성이 큽니다. 프로그래밍은 쉬운 일이라고 생각하고 있다면, 그렇게 안 풀리는 일이 생겼을 때, “어라? 이게 이렇게 안 풀릴 일이 아닌데? 분명 내가 뭔갈 놓치고 있는 걸꺼야” 라는 생각을 하게 되고 그 놓쳤던 걸 하나 씩 찾아가게 되며 더 성장 할 수 있는 여지가 생기게 된다고 생각합니다.
프로그래밍이 쉬운 이유
하지만 이렇게 말해도, 프로그래밍이 쉽다는 문장에 쉽사리 공감 할 수 없는 분들이 많을 것 같아요. 그런데 프로그래밍은 객관적으로 다른 많은 분야에 비해 익히기 아주 쉬운 분야입니다. 더 정확히는 익히는데 드는 시간과 비용이 상대적으로 매우 적어요.
뭔가를 배우는 일은, 끊임없이 실패하는 일입니다. 실패하지 않고 뭔갈 배울 수는 없어요. 그런데 대부분의 분야는 이 실패의 과정이 오래걸리고, 또 비용도 많이 듭니다. 요리를 예로 들어볼까요? 요리를 하려면 아무리 간단한 요리를 준비하려 해도 재료 준비, 재료 손질, 조리 등 복잡하고 긴 과정이 걸립니다. 라면을 끓여도 5분은 걸려요. 제대로 된 요리를 한다면 2~30분은 훌쩍 소모됩니다. 그렇게 2~30분 동안 정성껏 요리를 했는데, 실패했다면? 어쩔 수 없이 그 실패한 음식을 우리는 먹어야 하거나, 너무 심하게 실패했다면 버려야 합니다. 그럼 이렇게 실패한 음식을 먹거나 처분한 다음에, 우리는 다시 시도해 봐야겠죠? 다시 시도하는데는 또다시 2~30분의 시간으 소모되고 또 그 만큼의 재료비가 소모됩니다. 맛없는 음식을 먹어야 하는 괴로움도 적지 않은 비용이겠죠.
이런 방식으로 하루에 몇 번이나 실패 할 수 있을까요? 요리마다, 또 사람마다 다르겠지만 그렇게 많이 실패해 볼 순 없을 겁니다. 실패 할 수 있는 횟수가 적다는 것은 그 만큼 실패에서 배울 수 있는 기회가 적다는 뜻이기도 합니다. 그 많은 실패를 겪어 내고 탄생한 “비법 양념”을 만들어낸 소수의 맛집에 사람들이 줄을 서는 이유이기도 하겠죠. 그렇게 많은 실패를 감수 할 수 있는 식당은 얼마 되지 않을테니까요.
하지만 프로그래밍은 어떻습니까? 내가 뭔갈 잘못하면 대부분 컴파일러가 몇 초만에 알려줍니다. 처음에는 컴파일러가 뱉어내는 에러메시지들이 무서워보이기도 합니다. 읽을 엄두가 안 날 수도 있지요. 하지만 결국 에러메시지들은 여러분의 편입니다. 두려움을 걷어내고 그 메세지들을 차근차근 읽어가다 보면 어떤 문제가 발생했는지, 왜 발생했는지, 해결 하려면 어떤 문서를 봐야 하는지, 최소한 어떤 키워드로 검색해야 하는지를 알아낼 수 있을 겁니다. 무엇보다도, 이렇게 “망친 코드”를 작성해서 돌려보고 그것이 문제라는 것을 인식하고 고칠 방법을 알게 될 때 까지, 여러분은 “시간” 외에는 실질적으로 아무 비용도 지출하지 않습니다! 실질적으로 하루에 수 백번도 실패 할 수 있습니다. 이렇게 부담없이 빠르게 많은 실패를 할 수 있는 분야는 얼마 없습니다. 그림을 그려도 망치면 종이값 물감값이 나가고, 자전거를 타다 실패하면 무릎이 나갑니다. 그에 비하면 프로그래밍의 실패 비용은 실질적으로 제로입니다. 프로그래밍의 이런 성질을 적극 이용해야 합니다.
거꾸로 얘기해서, 프로그래밍을 빠르게 배우려면 “빠르게 실패하고 컴퓨터로부터 피드백을 받을 수 있는 환경”을 구축해야 합니다. 만약 특정 버그를 고치기 위해 코드를 수정하고, 몇 분에 걸쳐 빌드해서, 화면을 여러 번 손가락으로 눌러서 깊숙히 숨겨져 있는 화면으로 이동해서, 버그가 고쳐졌는지를 확인하는 방식을 쓰고 있었다면, “실패->실패여부파악->분석”의 사이클에 걸리는 시간이 아주 길다고 할 수 있습니다. 이 사이클을 어떻게든 단축해서 짧은 기간 더 많이 실패하는 방법을 고민하는 것이 중요합니다. 예컨대 빌드시간을 줄이던가, 또는 그 화면을 별도의 샘플앱에서 돌린다던가, 자동화된 UI테스트를 구축한다던가 등을 고민 할 수 있겠죠. 이렇게 “빠르게 실패 할 수 있는 환경 구축”을 위한 노력은 자연스럽게 모듈화된 코드, 관심분리의 원칙이 잘 적용된 코드로 이어지기도 합니다.
만약 프로그래밍이 어렵다고 생각하고 계셨다면, 뭔가를 놓치고 있지는 않았는지 꼭 뒤돌아보세요. 제가 농구를 하면서 그랬듯, 단순한 기초 지식 하나가 프로그래밍에 대한 여러분의 인식을 완전히 뒤바꿔 버릴 수도 있습니다.
사족
혹시 프로그래밍 기초를 어디서부터 다져야 할지 모르겠다면, 다음의 링크들을 확인해 보세요!