배우면서 바로 글을 씁니다

AI 요약

새로운 기술을 배울 때는 비슷해 보이는 API가 왜 둘이나 있는지, 원하는 작업을 어떻게 수행하는지, 예제와 비슷하게 작성한 코드가 왜 동작하지 않는지와 같은 질문을 마주하게 됩니다. 자료를 찾아보고 도구에 익숙해지면서 답을 알아가지만, 시간이 지나 전문가가 되면 처음에는 답을 찾기 어려웠다는 사실과 그 과정에서 필요했던 검색어·개념·맥락을 잊기 쉽습니다. 이 글은 바로 그 ‘질문을 품은 상태’에서 ‘답을 알고 있는 상태’로 넘어가는 연결 과정을 기록해야 한다고 주장합니다.

■ 초보자와 전문가 사이의 문서 공백

저자는 프로젝트 구조를 익히고, 코드를 읽고, 해당 프로젝트가 상호작용하는 대상을 확인하고, 버그 트래커를 훑어보는 과정을 거친 뒤에야 질문에 답하는 머릿속 모델을 만들었다고 설명합니다. 그런데 일단 모델을 완성하고 나면 그 구조가 이해하기 쉽고 문서에도 설명되어 있다는 사실을 발견하게 됩니다. 전문가는 합리적으로 설계된 모델이라고 생각하지만, 초보자였던 자신은 문서가 이미 존재하는데도 그 모델을 찾지 못했던 것입니다.

저자는 학습 자료가 대체로 초보자용 또는 전문가용으로 나뉘며, 한 단계에서 다음 단계로 이동하는 사람을 위한 자료는 부족하다고 봅니다. 너무 단순한 설명은 세부 사항이 필요할 때 도움이 되지 않고, 전문가가 전문가를 대상으로 쓴 문서는 필요한 용어와 전제를 이미 알고 있어야 읽을 수 있습니다. 이를 두고 접근 가능한 문서조차 ‘전문가가 다섯 살 어린이에게 설명하는 방식’처럼 느껴질 수 있다고 말합니다. 핵심은 정보의 난이도를 무조건 낮추는 것이 아니라, 독자가 다음 개념으로 이동할 수 있도록 중간의 용어와 근거를 연결해 주는 것입니다.

■ KubeJS와 NeoForge를 따라가며 개념을 연결하기

글에서는 Minecraft modding을 배우며 접한 KubeJS 사례를 듭니다. KubeJS는 JavaScript로 Minecraft를 재구성하는 도구이며, 아이템을 태그에 추가하는 예제는 다음과 같습니다.

ServerEvents.tags('item', (event) => { event.add('tag_name', 'item_name') })

이 코드를 처음 본 사람은 ServerEvents가 무엇인지, 왜 작업이 closure 안에서 수행되는지, 그 closure가 즉시 호출되어 단순히 event에 접근할 수 있게 하는 것인지, 플레이어의 행동에 반응하지 않는 코드가 왜 event라고 불리는지 궁금해할 수 있습니다.

저자는 관련 내용을 더 조사한 뒤, KubeJS가 mod loader인 NeoForge와 통합되고 NeoForge가 이벤트를 제공한다는 사실을 설명합니다. 해당 문서의 앞부분에는 ‘개체가 점프하는 경우’처럼 게임 안에서 일어나는 이벤트가 예시로 나오지만, 아래쪽에는 각 모드의 시작 과정에서 한 번 실행되는 lifecycle event가 설명되어 있습니다. registry event에는 NewRegistryEvent, DataPackRegistryEvent.NewRegistry, 각 registry에 대한 RegisterEvent가 포함됩니다.

이 맥락을 파악하고 나면 등록한 closure가 실제로는 event handler라는 점을 이해할 수 있습니다. NeoForge는 월드가 로드될 때 이 이벤트를 전달하고, 처리는 동기적으로 수행합니다. 또한 이것은 일반적인 플레이어 행동 이벤트라기보다 mixin 또는 patch point에 가까운 동작이지만, 동일한 기반 메커니즘을 사용하기 때문에 같은 event라는 이름으로 불립니다. 처음 코드만 봐서는 드러나지 않는 mod loader의 생명주기, 이벤트 전달 시점, 등록 함수의 의미를 연결해야 예제가 설명하는 모델에 도달할 수 있다는 사례입니다.

■ 네트워크를 우연히 배우게 되는 문제

저자는 예전에 Web이 어떻게 동작하는지 몰랐을 때, 많은 글이 ‘컴퓨터가 0과 1을 Google에 보내고 Google이 0과 1을 돌려준다’는 식으로 설명했다고 회고합니다. 그러나 그 설명만으로는 데이터가 Google에 어떻게 도달하는지 알 수 없습니다. 저자는 이후 Ethernet에서 패킷 시작을 나타내는 특정 비트 시퀀스가 사용된다는 점, IP 주소가 ARP를 통해 MAC 주소로 해석된다는 점, HTTP와 cryptography가 어떻게 관련되는지를 알게 되었습니다. 다만 패킷 경계를 학교 교사의 설명으로, ARP를 Wireshark에서 패킷을 관찰하다가 알게 되는 등 여러 내용을 계획된 학습 경로가 아니라 우연히 습득했다고 말합니다.

HTTPS가 연결을 안전하게 만든다는 말을 들은 사람이 HTTPS의 Wikipedia 문서에서 출발해, 사전 지식 없이 Diffie–Hellman까지 어떻게 도달할 수 있는지도 같은 문제의 예입니다. HTTPS의 보장이 비대칭 암호화에 크게 의존한다는 전제와 그 전제를 설명하는 용어를 모르면, 단순한 개요에서 다음 개념으로 넘어갈 경로가 보이지 않습니다. 저자는 자신이 운영하는 블로그를 기초적인 지식만 가진 사람이 흥미로운 주제에 접근할 수 있도록 가르치는 공간으로 시작했다고 설명합니다. 대중과학 잡지처럼 독자를 단순히 기준선보다 조금 높은 수준으로 올리는 데 그치지 않고, 자신의 수준까지 끌어올리는 것을 목표로 합니다.

■ 해결한 직후에 쓰는 기록

저자는 문서를 작성할 때도 high-level API마다 그 아래에서 사용되는 low-level 세부 사항을 언급하려고 합니다. 예를 들어 어떤 알고리즘을 기반으로 하는지 알려 주어 독자가 관련 개념을 따라가며 스스로 학습할 수 있게 하려는 방식입니다. 하지만 전문가가 된 뒤에는 과거 초보자였을 때 어떤 부분에서 혼란을 겪었는지, 어떤 검색어를 떠올렸는지를 완전히 기억하기 어렵습니다. 문제를 며칠 동안 붙잡고 있다가 마침내 해결한 직후에야, 혼란과 검색 과정을 해결책과 함께 기억할 가능성이 높습니다.

따라서 저자는 문제를 해결했다면 성공 사례뿐 아니라 실패 사례도 글로 남기라고 권합니다. 블로그나 소셜 네트워크 등 형식은 무엇이든 가능하며, 친구들만 읽더라도 같은 문제를 겪는 사람에게 유용할 수 있습니다. 해결 과정이 길었는데 결론은 단순하더라도 그것은 학습자의 잘못이라고만 볼 일이 아닙니다. 간단한 결론에 도달하는 일이 지나치게 어려웠다는 사실 자체가 해당 정보나 문서가 접근하기 어렵다는 신호가 될 수 있습니다. 유지보수자는 이런 누락과 불명확한 표현을 발견할 수 있고, 유지보수자가 즉시 반응하지 않더라도 이후 같은 문제를 만나는 다른 사람들에게 기록이 남습니다.

■ Lobsters 반응

• @david_chisnall — 100% 동의합니다. Cambridge에서는 강의 외에도 학생들이 ‘supervisions’라고 부르는 소그룹 수업을 받습니다. 보통 학생 두 명으로 진행합니다. 연구에서는 세 명이 최적의 수라고 하지만, 그 연구는 Oxford에서 수행되었기 때문에 무시합니다. 이 수업은 PhD 학생, postdoc, faculty가 섞여 진행합니다. 학생들은 이 수업을 맡은 주니어 PhD 학생들에 대해 가장 좋은 보고서를 작성하는 경우가 많습니다. 그들은 아직 자료를 이해하지 못했던 때를 생생하게 기억하기 때문입니다. 같은 내용을 여러 번 가르친 senior academic도 다양한 오해를 접해 왔기 때문에 자주 좋은 설명을 합니다. 제 첫 책인 Xen 책의 초기 서평 중 하나는 제가 해당 주제에 접근하는 초보자의 사고방식을 잘 포착했다고 평가했습니다. 그렇게 할 수 있었던 것은 무언가를 배우고 나서 바로 그 내용에 대해 글을 쓰는 방식으로 작업했기 때문입니다. 두 번째 책은 쓰기 시작하기 전부터 잘 알고 있던 주제였고, 그래서 결과가 덜 좋았습니다.

원문: purplesyringa.moe / 번역·요약: Trawling