WardOnWikiAndProgramming
워드가 말하는 위키와 프로그래밍의 닮은 점
워드 커닝햄은 위키를 만든 사람이고 CRC 카드와 패턴을 만든 사람이다. 2008년 컴퓨터 역사박물관 대담 ↗에서 그는 위키와 프로그래밍을 같은 자리에서 이야기했다. 아래는 그가 한 말이다.
읽는 깊이는 읽는 사람이 고른다
객체지향의 성취를 말한 직후, 그는 위키를 같은 것이라고 했다.
객체지향의 진짜 성취는 메서드를 읽을 때 그 안에서 보내는 메시지의 구현을 읽지 않아도 된다는 것입니다. 즉 아주 빠르게 읽을 수 있습니다. (…) 메서드를 작성할 때는 그것이 무엇을 할지 정말로 알아야 하고, 어떻게 동작하는지 깊이 이해해야 합니다. 하지만 코드를 읽을 때는 그럴 필요가 없습니다. 여러 번에 나눠서(in passes) 읽으면 됩니다.
위키에서도 정확히 똑같습니다.
예를 들어 YAGNI가 있습니다. (…) 글을 읽다가 "잊지 마, 어차피 필요 없을 거야…"라는 링크가 나와도 아무도 클릭하지 않습니다. 이미 논의된 것이고 그 단어는 어휘 안에 있으니까요.
다만 새로 온 사람은 다릅니다. "이게 무슨 뜻이지? 필요 없을 거라니? 이 사람은 설계에 반대하는 건가?" 하고 그 링크를 클릭해 그 역사를 가져갑니다.
만약 링크를 클릭했더니 "당신은 레벨 2 마스터가 아니므로 알려주지 않겠다"고 한다면 — 그러면 영원히 레벨 2 마스터가 되지 못할 사람만 잔뜩 생길 뿐입니다.
없는 것을 먼저 가리킨다
위키 이전에, 하이퍼카드로 만든 사내 데이터베이스에서 이미 그 동작이 나왔다.
대신 검색 기능을 썼습니다. 어떤 단어를 클릭하면 그 단어를 검색합니다. 못 찾으면 그냥 삑 소리가 나고, 찾으면 그 카드로 갑니다. 그런데 누르고 있으면, 그 카드가 없더라도 카드를 생성합니다. 그래서 이런 식이 됐습니다 — 단어를 클릭하면 "삑, 그건 모르겠는데." 그럼 "나는 그것에 대해 알지" 하며 더 세게 누르면 카드가 나타납니다.
여기서 위키를 만들어봤거나 다뤄본 분? 이거 익숙하지 않나요? 정확히 그 메커니즘입니다.
페이지를 렌더링해 화면에 올릴 때 링크가 될 수 있는 모든 단어를 조회해서, 그 페이지로 가는 링크로 만들거나 편집 페이지로 가는 링크로 만드는 겁니다. (…) 요컨대 "나는 모르니 당신이 말해달라"는 뜻입니다.
이 방식은 하향식 편집(top-down editing) 을 가능하게 하는데, 경계가 어디인지 모르는 대상 — 계속 뻗어나가서 결국 자기 관심으로 어디서 멈출지 정해야 하는 대상 — 을 서술하기에 잘 맞습니다.
무엇이 되고 싶어 하는지 알아차린다
기계를 공부하던 태도가 그대로 프로그램에, 그리고 위키에 갔다.
그런 믿음 — 어떤 시스템이든 특정한 방식이 되고 싶어 하며, 설계자는 그것이 무엇이 되고 싶어 하는지 알아차려야 한다는 믿음 — 은 온갖 컴퓨터를 공부하면서, 인덱스 레지스터를 넣은 사람들이 우리가 그걸로 무엇을 하길 기대했는지 알아내려 애쓴 데서 왔습니다. (…) 하지만 먼저 시스템이 작동하고 싶어 하는 방식을 이해해야 합니다. 그걸 이해하고 나면 마음껏 몰아붙일 수 있습니다.
최초의 위키를 만든 일도 그에게는 같은 작업이었다.
제가 진짜로 한 일은 그것들을 뜯어보는 것이었습니다. 브라우저는 무엇을 브라우징하고 싶어 하는가, 웹 서버는 무엇을 서빙하고 싶어 하는가, 파일 시스템은 무엇을 저장하고 싶어 하는가, 그리고 펄은 이 모두를 어떻게 붙들고 싶어 하는가.
이름을 지으면 어휘가 된다
패턴은 같은 책임을 반복해 적다가 나왔다.
카드에 책임(responsibility)을 적다 보니 같은 책임을 계속 반복해서 쓰고 있다는 걸 알았습니다. "한 열 개쯤 되겠구나, 그걸 목록으로 만들면 설계가 훨씬 쉬워지겠다."
위키에서 벌어진 일도 같았다.
제 위키에서 다루는 프로그래밍은 실무자들 사이에서 매우 복잡한 경험이라 자기가 하는 일을 말할 새로운 단어가 필요했습니다. 사람들은 새 단어를, 늘 어구(phrase) 형태로 정의했습니다. 자기가 중요하게 여기는 것을 담은 어구를 정의하고, 그 어구에 대한 짧은 토론이 붙고, 그러면 그 어구가 어휘(vocabulary)로 편입됩니다.
고칠 수 있어야 참여한다
위키의 씨앗은 사내 하이퍼카드 스택 앞에서 사람들이 보인 반응이었다.
그러면 저는 "그럼 고치세요"라고 했습니다. "아, 그래도 돼요?" 하면서 사람들은 카드의 정보를 고쳤습니다. 그리고 그걸 정말 좋아했습니다. 자기가 관심 있는 무언가에 대한 서술이 있는 공간을 돌아다니다가, 뭔가 틀린 걸 발견했을 때 바로 그 자리에서 고칠 자유가 있다는 것 — 그건 마법 같았습니다.
혼자서는 못 배운다
리스프를 이야기하다 나온 말인데, 위키를 만든 이유이기도 하다.
학습자들의 공동체 안에 있지 않고서는 리스프를 정말 잘 배우는 게 불가능하다고 생각합니다. (…) 혼자서는 코드를 충분히, 충분히 빨리 읽어낼 수 없습니다. "오, 이거 봐, 이거 해봐", "그건 나도 막혔어", "사실 그건 나쁜 코드야" 라고 말해주는 사람들이 있는 공동체가 필요합니다.
씨름하는 것이 배우는 것이다
그 씨름은 더 나은 해법에 도달하려는 시도인 동시에 엄청난 양의 경험을 굳히는 과정입니다. 그게 학습 과정입니다. (…) 사람들이 문제와 씨름하고 선택지를 모두 거쳐 결과를 보게 하지 않으면 (…) 통찰은 생기지 않습니다.
닮은점
| 닮은점 | 프로그래밍에서 | 위키에서 |
|---|---|---|
| ReadingInPasses | 메서드 구현을 안 읽고 넘어간다 | 아는 링크는 안 누르고 넘어간다 |
| NameBeforeItExists | TDD — 아직 없는 클래스를 테스트에서 먼저 부른다 | 없는 문서로 링크한다 |
| WhatItWantsToBe | 프로그램이 어떻게 구성되고 싶은지 듣는다 | 사람들이 무엇을 하고 싶어 하는지 본다 |
| NamingMakesVocabulary | 패턴에 이름을 붙인다 | 어구를 정의하면 어휘가 된다 |
| FreedomToFix | 남의 코드를 고칠 수 있다 | 남의 글을 고칠 수 있다 |
| CommunityTeaches | 공동체가 언어를 가르친다 | 위키가 그 공동체를 만든다 |
| WrestlingIsLearning | 설계 논쟁 | 토론 페이지 |