디지털라이프
제공 : 한빛 네트워크
저자 : Simon St. Laurent
역자 : 김동혁
원문 : Writing without knowing
누군가에게 도움이 될 만한 글을 쓰려고 할 때, 우리가 꼭 그 분야의 전문가여야 그럴 자격이 있는 것은 아닙니다. "초심자의 마음으로"는 우리가 그 분야에 조예가 깊어질수록 추상적이고 잊어버리게 되는 것에 지나지 않을 때도 있지요. 바로 이 점 때문에 초보자가 전문가로부터 무언가를 배운다는 것이 마냥 쉬운 일만은 아니라고 생각합니다. 오히려 독자 여러분들이 어떤 분야에 갓 입문한 상태에서, 다른 초심자에게 도움이 되고자 과감히 가이드를 하나 작성하려 한다면 생각과 달리 좀 더 초심자들에게 어필할 수 있는 요소와 관점을 갖고 있다는 것을 깨달을 수 있을 겁니다.
하지만 "전문가로부터 배워보는" 라는 수식어는 형식적이지만 여전히 매력적인 문구임은 틀림없습니다. 아무래도 그 분야의 전문가라면 좀 더 잘 가르칠 것이라는 신뢰가 담겨 있기 때문이죠. 보통 이런 이야기에는 도제법(Apprenticeship)이 함께 등장하곤 합니다. 도제법이란 전문가가 될성부른 제자를 선별하고, 그를 곁에 두고 오랫동안 멘토링 해주며 가르치는 방식을 일컫습니다. 전문 강사로부터 배우는 것과도 일맥상통한다고 볼 수 있지요.
도제법을 통한 학습 모델은 그것만의 이점을 갖추고 있지만, 사실 개인적으로는 "DIY 모델"이라고 줄곧 부르던 학습 모델을 알리는데 개인적인 역량을 쏟아왔습니다. 무엇보다 프로그래머 계열에서 도제법을 기꺼이 하려는 전문가급 프로그래머가 매우 적다는 게 문제입니다. 개구리가 올챙이적 시절을 모른다 듯이, 전문가는 자신과 동급인 사람들과 어울려 대화하고 토론하길 원하지, 새로 들어온 입문자와 대화하는 것을 반겨하는 경우는 드문 것이 사실입니다. 여기서 제가 말하고자 하는 DIY 모델을 간단히 정의 하자면, 앞서 말한 도제법과 같은 형식적인 틀을 벗어 던지고, 우리가 쉽게 접할 수 있는 서적과 동영상 강의, 그리고 간헐적인 강의와 자가 학습만으로 구성된 학습 모델을 일컫습니다.
사실 제가 말한 DIY 학습 모델을 정확히 습득하기는 쉽지 않습니다. 그 이유는 꽤나 간단하게 설명할 수 있습니다. 혹시나 독자 분들 중 실제로 누군가를 가르치는 입장인 분을 빼고는(물론 그건 그것대로 여러모로 힘든 일이지만), 가르치는 입장에서 학생 혹은 청중/독자들이 원하는 것이 무엇인지 예측하는 것이 중요함을 명심해야 합니다. 때문에 보통 글이나 자료를 작성하는 도중 혹은 한 챕터를 끝낸 뒤 리뷰 절차를 통해 피드백 과정이 돌아가죠. 이것을 스스로 습득하기 위해 이 피드백 과정을 벗어나고 나면 "자신도 아직 잘 모르는 것을 써보아라"라는 약간은 이상하게 들릴 법한 것이 필요합니다.
저는 지금까지 DIY 방식으로 공부하는 독자들을 위해 많은 책들을 집필해왔습니다. 대부분의 경우, 제가 스스로 공부한 그 내용 자체로 구성해왔지요. 제가 집필을 처음으로 시작했을 당시에, XML이 막 나오고 있었고 Dynamic HTML은 베타 소프트웨어에 불과한 컨셉만 갖추고 있었습니다. 최근에는 각종 전문가들을 위한 고급 서적이 즐비한 Rails, Erlang 그리고 Elixir와 같은 분야의 글을 써나가고 있습니다. 그런 고급 서적들은 심지어 제가 읽기에도 벅찹니다.
그럼 생각해보죠, 대체 무엇 때문에 제가 전문가가 아닌 영역에 발을 들이밀고 글을 써야 할까요? 저의 간단한 답변은 바로 이겁니다 : 아무도 내가 필요로 하고 원하는 것들을 글로 남겨두지 않아서. 물론 그런 글도 존재할 겁니다. 하지만 인터넷 여기저기에 산재해 있거나 어떤 사람 책상 서랍에 있는 공책에 쓰여 있을지도 모를 일입니다. 어찌되었든 저는 아주 더디게 작업이 진행되더라도, 전문서적들을 쌓아놓고 그들의 이야기를 다시금 좀 더 쉽고, 초심자가 이해하기 쉽게 재구성하는 작업을 하려는 것입니다. 그 결과물은? 물론 제가 느낀 것이 옳다면, 그건 단순히 저 자신을 학습시킨 것 이상으로 많은 것을 가져다 주었습니다. 저는 제 창작물들을 많은 사람들을 위해 활짝 열린 문과 같다라고 일컫고 싶군요.
제 의견이 다소 편향되어 있을 수 있지만, 저는 이 모델을 통해 다양한 장점들을 발견했습니다. 무엇보다 가장 큰 장점은 각 단계에서 저를 괴롭혔던 것을 각 단계 별로 강조할 수가 있습니다. 예를 들면, 복잡하고 얽혀있는 초기 환경 구축은 정말 짜증나고 어려운 것이지만 분명 초보자에게 있어서 아주 중요한 단계입니다. 전문가들은 그냥 설치 리스트를 훑어보고 필요한 것들만 몇 개 이리저리 설치하면 그만이겠지만, 초보자들에게는 대체 내가 따라 하고 있는 설치 과정 속에서 각각이 뭘 위한 것인지 알아야 합니다. 각 조각들이 모여서 어떻게 동작하는지를 이야기해주는 것, 그리고 그 과정에서 무엇을 실수하기 쉬운지 등의 이야기들은 단지 숙련된 전문가들을 위한 것이 아닌, 초심자들에게 가고 있는 길이 어떻게 생긴 것인지 이해하는데 큰 도움을 줄 수 있습니다.
또 하나의 장점으로 꼽을 수 있는 것은 바로, 내가 무엇을 모르는지 알 수 있다는 것 입니다. 물론 가장 어려운 순간은 바로 모르는 게 "모든 것"일 때죠. 그러니 먼저 여러분이 신뢰할 수 있는 사람이나 자료, 서적들을 찾아보는 것이 수순입니다. 또한 최소한 자신이 그 분야의 용어 들을 잘 이해하고는 있는지, 또한 각 정보 조각들을 어떻게 맞춰야 할지에 대한 최소한의 경험은 갖추고 있어야 합니다. 아마도 가장 중요한 것이 될 수 있겠지만 당신이 잘못된 방향으로 나아갈 때 잡아줄 수 있는 리뷰어를 최대한 빨리 곁에 두는 것 역시 없어서는 안 될 요소입니다.
사실 여러분들이 아무리 밑바닥부터 힘들게 시작한다고 해도, 거기가 밑바닥은 아닐 겁니다. 예를 들어, 많은 프로그래밍 환경, 언어는 서로 다르고 또한 학습과정에서 그릇된 방향으로 가는 많은 길이 존재합니다. 하지만 그들을 아우르는 기본 구조는 동일하기 때문에 우리가 시작할 때 어느 정도 가정을 할 수 있고, 실제로도 거기서 크게 벗어나지는 않습니다. 그 분야에 지식이 어느 정도 있냐에 따라 그 정도는 다르겠으나, 정작 글을 쓰기 시작하게 되면 훨씬 더 빈번하게 이러한 점들을 발견하고 깨달을 수 있습니다.
보시다시피 이 접근법을 일반적인 출판 과정에 도입하게 된다면 초장부터 상당히 삐걱거릴 겁니다. 책 표지를 넘기고 서문을 읽는데 저자가 "전 사실 이것에 대해 잘 몰라요"라고 써 놓으면 진행이 잘 될 리 없죠. 저는 예전부터 함께 일 해 왔던 퍼블리셔가 있었기에 이런 작업을 해 올 수 있었고, 제가 작업한 것을 평가해주기도 하였죠. 제가 지금까지 줄곧 말한 관점이 독자들을 위한 대단히 좋은 방법이라 말하고 있지만 분명 장차 책을 쓰고자 하는 분들에겐 확실히 어려운 선택일 겁니다(저 역시도 이 방식을 IT가 아닌 다른 분야에 적용하여 글을 쓸 당시 상당히 골치가 아팠습니다). 한 번 시도해 보고자 할 마음은 있다면, 자신이 설명하고자 하는 주제, 작성 프로세스, 그리고 자기 자신과 더 나아가 독자들을 이해하는데 큰 도움이 될 겁니다. 또한, 아래의 것들을 따라가 보는 것도 좋습니다.
여기서 제가 말한 모든 것은 "작가가 되기 위한" 혹은 "저작권으로 돈을 벌기" 등이 아닙니다. 그럴 가능성은 매우 낮다고 말하고 싶네요. 하지만, 당신은 정말 많은 것을 배울 수 있을 것이고 또한 당신이 걸어왔던 길을 걸어갈 다른 사람들을 행복하게 해줄 수 있을 거라고 확신합니다.
저자 : Simon St. Laurent
역자 : 김동혁
원문 : Writing without knowing
누군가에게 도움이 될 만한 글을 쓰려고 할 때, 우리가 꼭 그 분야의 전문가여야 그럴 자격이 있는 것은 아닙니다. "초심자의 마음으로"는 우리가 그 분야에 조예가 깊어질수록 추상적이고 잊어버리게 되는 것에 지나지 않을 때도 있지요. 바로 이 점 때문에 초보자가 전문가로부터 무언가를 배운다는 것이 마냥 쉬운 일만은 아니라고 생각합니다. 오히려 독자 여러분들이 어떤 분야에 갓 입문한 상태에서, 다른 초심자에게 도움이 되고자 과감히 가이드를 하나 작성하려 한다면 생각과 달리 좀 더 초심자들에게 어필할 수 있는 요소와 관점을 갖고 있다는 것을 깨달을 수 있을 겁니다.
하지만 "전문가로부터 배워보는" 라는 수식어는 형식적이지만 여전히 매력적인 문구임은 틀림없습니다. 아무래도 그 분야의 전문가라면 좀 더 잘 가르칠 것이라는 신뢰가 담겨 있기 때문이죠. 보통 이런 이야기에는 도제법(Apprenticeship)이 함께 등장하곤 합니다. 도제법이란 전문가가 될성부른 제자를 선별하고, 그를 곁에 두고 오랫동안 멘토링 해주며 가르치는 방식을 일컫습니다. 전문 강사로부터 배우는 것과도 일맥상통한다고 볼 수 있지요.
도제법을 통한 학습 모델은 그것만의 이점을 갖추고 있지만, 사실 개인적으로는 "DIY 모델"이라고 줄곧 부르던 학습 모델을 알리는데 개인적인 역량을 쏟아왔습니다. 무엇보다 프로그래머 계열에서 도제법을 기꺼이 하려는 전문가급 프로그래머가 매우 적다는 게 문제입니다. 개구리가 올챙이적 시절을 모른다 듯이, 전문가는 자신과 동급인 사람들과 어울려 대화하고 토론하길 원하지, 새로 들어온 입문자와 대화하는 것을 반겨하는 경우는 드문 것이 사실입니다. 여기서 제가 말하고자 하는 DIY 모델을 간단히 정의 하자면, 앞서 말한 도제법과 같은 형식적인 틀을 벗어 던지고, 우리가 쉽게 접할 수 있는 서적과 동영상 강의, 그리고 간헐적인 강의와 자가 학습만으로 구성된 학습 모델을 일컫습니다.
사실 제가 말한 DIY 학습 모델을 정확히 습득하기는 쉽지 않습니다. 그 이유는 꽤나 간단하게 설명할 수 있습니다. 혹시나 독자 분들 중 실제로 누군가를 가르치는 입장인 분을 빼고는(물론 그건 그것대로 여러모로 힘든 일이지만), 가르치는 입장에서 학생 혹은 청중/독자들이 원하는 것이 무엇인지 예측하는 것이 중요함을 명심해야 합니다. 때문에 보통 글이나 자료를 작성하는 도중 혹은 한 챕터를 끝낸 뒤 리뷰 절차를 통해 피드백 과정이 돌아가죠. 이것을 스스로 습득하기 위해 이 피드백 과정을 벗어나고 나면 "자신도 아직 잘 모르는 것을 써보아라"라는 약간은 이상하게 들릴 법한 것이 필요합니다.
저는 지금까지 DIY 방식으로 공부하는 독자들을 위해 많은 책들을 집필해왔습니다. 대부분의 경우, 제가 스스로 공부한 그 내용 자체로 구성해왔지요. 제가 집필을 처음으로 시작했을 당시에, XML이 막 나오고 있었고 Dynamic HTML은 베타 소프트웨어에 불과한 컨셉만 갖추고 있었습니다. 최근에는 각종 전문가들을 위한 고급 서적이 즐비한 Rails, Erlang 그리고 Elixir와 같은 분야의 글을 써나가고 있습니다. 그런 고급 서적들은 심지어 제가 읽기에도 벅찹니다.
그럼 생각해보죠, 대체 무엇 때문에 제가 전문가가 아닌 영역에 발을 들이밀고 글을 써야 할까요? 저의 간단한 답변은 바로 이겁니다 : 아무도 내가 필요로 하고 원하는 것들을 글로 남겨두지 않아서. 물론 그런 글도 존재할 겁니다. 하지만 인터넷 여기저기에 산재해 있거나 어떤 사람 책상 서랍에 있는 공책에 쓰여 있을지도 모를 일입니다. 어찌되었든 저는 아주 더디게 작업이 진행되더라도, 전문서적들을 쌓아놓고 그들의 이야기를 다시금 좀 더 쉽고, 초심자가 이해하기 쉽게 재구성하는 작업을 하려는 것입니다. 그 결과물은? 물론 제가 느낀 것이 옳다면, 그건 단순히 저 자신을 학습시킨 것 이상으로 많은 것을 가져다 주었습니다. 저는 제 창작물들을 많은 사람들을 위해 활짝 열린 문과 같다라고 일컫고 싶군요.
제 의견이 다소 편향되어 있을 수 있지만, 저는 이 모델을 통해 다양한 장점들을 발견했습니다. 무엇보다 가장 큰 장점은 각 단계에서 저를 괴롭혔던 것을 각 단계 별로 강조할 수가 있습니다. 예를 들면, 복잡하고 얽혀있는 초기 환경 구축은 정말 짜증나고 어려운 것이지만 분명 초보자에게 있어서 아주 중요한 단계입니다. 전문가들은 그냥 설치 리스트를 훑어보고 필요한 것들만 몇 개 이리저리 설치하면 그만이겠지만, 초보자들에게는 대체 내가 따라 하고 있는 설치 과정 속에서 각각이 뭘 위한 것인지 알아야 합니다. 각 조각들이 모여서 어떻게 동작하는지를 이야기해주는 것, 그리고 그 과정에서 무엇을 실수하기 쉬운지 등의 이야기들은 단지 숙련된 전문가들을 위한 것이 아닌, 초심자들에게 가고 있는 길이 어떻게 생긴 것인지 이해하는데 큰 도움을 줄 수 있습니다.
또 하나의 장점으로 꼽을 수 있는 것은 바로, 내가 무엇을 모르는지 알 수 있다는 것 입니다. 물론 가장 어려운 순간은 바로 모르는 게 "모든 것"일 때죠. 그러니 먼저 여러분이 신뢰할 수 있는 사람이나 자료, 서적들을 찾아보는 것이 수순입니다. 또한 최소한 자신이 그 분야의 용어 들을 잘 이해하고는 있는지, 또한 각 정보 조각들을 어떻게 맞춰야 할지에 대한 최소한의 경험은 갖추고 있어야 합니다. 아마도 가장 중요한 것이 될 수 있겠지만 당신이 잘못된 방향으로 나아갈 때 잡아줄 수 있는 리뷰어를 최대한 빨리 곁에 두는 것 역시 없어서는 안 될 요소입니다.
사실 여러분들이 아무리 밑바닥부터 힘들게 시작한다고 해도, 거기가 밑바닥은 아닐 겁니다. 예를 들어, 많은 프로그래밍 환경, 언어는 서로 다르고 또한 학습과정에서 그릇된 방향으로 가는 많은 길이 존재합니다. 하지만 그들을 아우르는 기본 구조는 동일하기 때문에 우리가 시작할 때 어느 정도 가정을 할 수 있고, 실제로도 거기서 크게 벗어나지는 않습니다. 그 분야에 지식이 어느 정도 있냐에 따라 그 정도는 다르겠으나, 정작 글을 쓰기 시작하게 되면 훨씬 더 빈번하게 이러한 점들을 발견하고 깨달을 수 있습니다.
보시다시피 이 접근법을 일반적인 출판 과정에 도입하게 된다면 초장부터 상당히 삐걱거릴 겁니다. 책 표지를 넘기고 서문을 읽는데 저자가 "전 사실 이것에 대해 잘 몰라요"라고 써 놓으면 진행이 잘 될 리 없죠. 저는 예전부터 함께 일 해 왔던 퍼블리셔가 있었기에 이런 작업을 해 올 수 있었고, 제가 작업한 것을 평가해주기도 하였죠. 제가 지금까지 줄곧 말한 관점이 독자들을 위한 대단히 좋은 방법이라 말하고 있지만 분명 장차 책을 쓰고자 하는 분들에겐 확실히 어려운 선택일 겁니다(저 역시도 이 방식을 IT가 아닌 다른 분야에 적용하여 글을 쓸 당시 상당히 골치가 아팠습니다). 한 번 시도해 보고자 할 마음은 있다면, 자신이 설명하고자 하는 주제, 작성 프로세스, 그리고 자기 자신과 더 나아가 독자들을 이해하는데 큰 도움이 될 겁니다. 또한, 아래의 것들을 따라가 보는 것도 좋습니다.
- 여러분이 깊게 이해하고 싶은 주제를 찾아보세요.
- 그 주제에 대해 충분한 설명들이 존재하는지 조사해보세요. 별로라면, 그 자체로 여러분이 글을 써야 할 이유를 제공해주고 있는지도 모릅니다.
- 시도 되지 않았던 새로운 스토리라인을 구성해보세요. 자신이 읽어봤을 때도 따라가고 싶어지는 길 같은 글이라면 만족스러울 겁니다(보통은 서문이 중요합니다, 특히 이 분야에 초심자들을 타겟으로 함을 잊지 마세요).
- 공부 그리고 또 공부. 단순히 책을 읽는 것도 좋고, 영상을 찾아보거나 하는 것이 내용을 채우는데 큰 도움을 줄 겁니다. 꾸준히 메모를 하는 것 역시 중요합니다.
- 흥미를 유발할 수 있는 형태의 초안을 먼저 작성해보도록 하세요.
- 독자가 쉽게 실행하고 이해할 수 있는 형태로 간단히 만들고 설명하세요. 독자들이 당신을 따라오도록 하는 것이 중요합니다.
- 글이 완성되었다면 최대한 빨리 자신의 창작물을 공유하세요
- 피드백은 언제나 중요합니다. 저도 가끔은 그다지 유쾌하지 않은 피드백들에 대해 애써 무시하며 제 방식을 고수한 적이 있습니다. 전문가로부터 받는 것도 중요하지만 몇몇 독자들로부터 돌아오는 피드백도 중요합니다.
- 글의 순서, 목차를 체크해 보세요. 전문서적들의 가장 큰 문제점 중 하나가 정작 저자들은 자신이 무슨 순서대로 지식을 익혔는지를 잊은 듯이 글을 써내려 간다는 점 입니다. 결국 초보자들은 글을 읽다가 정글에서 헤매버리게 되죠. 특히 "이 글을 읽기 전에 필히 읽어야 할 글이나 서적", "중요 참고 서적 및 사이트" 등이 독자들을 정글로 이끄는 이정표의 예입니다.
- 읽어 보고, 고치고, 다시 읽고, 또 고치고… 이미 완성된 글을 피드백을 받아 개선해나가는 과정은 향후 새로운 글을 작성할 때 모멘텀이 되는 중요한 요소입니다.
- 글이 무르익었다 싶으면, 거기서 끝!내세요.
여기서 제가 말한 모든 것은 "작가가 되기 위한" 혹은 "저작권으로 돈을 벌기" 등이 아닙니다. 그럴 가능성은 매우 낮다고 말하고 싶네요. 하지만, 당신은 정말 많은 것을 배울 수 있을 것이고 또한 당신이 걸어왔던 길을 걸어갈 다른 사람들을 행복하게 해줄 수 있을 거라고 확신합니다.
TAG :
최신 콘텐츠