조별 과제를 위해 교내 카페에 앉아서 회의를 하던 G는 지금 자신이 난처한 상황에 처했다는 것을 깨달았다. 난처함의 이유는 하나가 아니었다. 우선, 이번 학기 G가 수강하는 수업 중 하나가 인문학 글쓰기라는 것부터 문제였다. 대학교에 온 이후에 컴퓨터공학 강의만 들어왔던 그에게 ‘인문학’이란 지난 십여 년간 자신을 끊임없이 괴롭혀온 영어나 다를 바 없었다. 들을 때는 무언가 이해가 될 듯하면서도 막상 말을 해야 하는 상황에서는 꿀 먹은 벙어리가 되어버리는 그의 영어 말이다. 마찬가지로 인문학 강의도 들을 때는 뭔가 이해가 되는가 싶다가도 교수님이 자신의 질문에 답을 할 학생을 찾아 눈으로 교실을 훑을 때면, 노트로 고개를 푹 숙이고 필기하는 척 펜을 끄적거리기 십상이었다.
그랬던 G에게 조별 보고서 과제를 해야 한다는 사실은 고통 그 자체였다. ‘조별’도 문제였고 ‘보고서’도 문제였다. 차라리 개인 과제라면 눈 딱 감고 허접한 글을 써 내버리고, 그 글을 읽으실 교수님께는 연민을, 바닥에 깔릴 자신의 학점에게는 애도를 표하면 될 일이다. 하지만 조별과제에서 그렇게 해버리면 다른 학생들에게도 피해를 주게 된다. 내 학점이야 나의 몫이지만 그래도 프리라이더가 되는 것은 그의 자존심이 허락하지 않았다. 그리고 코딩¹ 과제는 내 보았지만 보고서는 써 본 적이 없는 그였기에 글로 된 보고서를 작성해야 한다는 사실도 무시할 수 없었다. 자연어²로 자신의 의견을 표현해야 한다니! G는 두 시간 전에 302동 학식에서 먹은 고추소스 돈가스가 소화가 안 되는 듯한 답답함을 느꼈다.
그래도 G는 이 수업을 드랍할 수 없었다. 어쨌든 졸업을 하려면 교양 필수 학점을 채워야 한다. 지금 드랍하면 고통을 다음 학기로 미루는 것뿐이다, 라고 그는 생각했다. 그리고 다행히 이번 수업은 팀 운이 좋은 것 같았다. 보고서를 같이 쓰게 된 P와 O는 모두 문과였다. 그냥 문과도 아니고 P는 철학과 2학년이었고 O는 정치학과 3학년이었다. 공대생이 막연히 생각하기에 입심으로는 캠퍼스에서 1, 2등을 다투는 전공생이라니. 그들이 어떻게 생각하든 G는 일단 훌륭하신 분들이 버스를 태워줬으면 하는 간절한 바람을 품었다. 그런 마음을 가지고 조별 과제를 위해 카페에 G, P, O 3명이 둘러앉았지만, 상황은 언제나 그렇듯 그가 바란대로 흘러가지는 않았다.

“주제가 대충 정해졌으니, 제 생각에는 이제 다음 주 모임까지 제가 보고서 후반부를 쓰고, P씨가 전반부를 쓰면 될 것 같아요.”
O는 노트에 필기인지 낙서인지 모를 것을 끄적거리며 말을 이었다.
“제 전공이랑도 관련 있고 해서 쓰는 건 어렵지 않을 것 같아요. P 씨는 어떠세요?”
“네 제 생각에도 그렇게 하면 될 것 같네요. 나눠서 쓰면 부담도 좀 덜하고요. 그럼 G 씨는…”
회의 내내 P와 O의 현란한 말발에 감탄하며 얼음만 남은 아이스 아메리카노를 바닥까지 쪽쪽 소리 내어 빨던 G는, P가 자신을 부르자 그제야 정신이 번쩍 든 느낌이었다. 이대로 가면 걱정했던 그대로 프리라이딩이다, 라고 G는 생각했다. ‘선배님 이름은 뺄게요~’라는 어디선가 본 광고 화면이 그의 머릿속을 스쳐 지나갔다. 이대로는 위험해!
“…음 저는 그러면… 선행 자료조사를 좀 하고… 음… 흠…”
P는 G의 답을 인내심 있게 기다리다 미간을 살짝 찌푸리고 말했다.
“음… 제 생각엔 G씨가 중간에서 저희 둘이 쓰신 글을 받아서 종합하는 걸 해주시면 좋을 것 같아요. 아무래도 두 사람이 한 글을 쓰면 문체도 그렇고 맞춰야 할 것도 있을 테니까요. 어떠세요?”
“아, 그게 좋겠네요.”
P와 O의 말에 G는 재빨리 고개를 끄덕일 수밖에 없었다. 그래도 이 정도로 그쳐서 다행이다… G는 그렇게 생각했다. 적어도 그때까지는.

며칠이 지나고 G는 P와 O로부터 거의 동시에 각각 보고서를 첨부한 메일을 받았다. 각각의 파일을 열어서 복사 붙여넣기로 한 파일로 합친 후 G는, 뭔가 이상하다는 사실을 깨달았다. 합쳐진 파일은 아래와 같았다.

P) 대학생은 모름지기 논어를 읽어야 한다. 논어를 읽어야 하는 이유는 다양하다. O) 대학 생활 평가의 기준은 다양하지만 연애를 하는 것이 가장 중요하다.

G는 자신이 비록 공대생이지만 그래도 이 글은 뭔가 문제가 있는 것이 확실하다고 생각했다. 그래서 합쳐진 글을 조원들에게 확인 부탁드린다고 메일로 보냈다. “안녕하세요, 조원분들. 보내주신 글 잘 받았습니다. 글을 합치긴 했는데 제가 잘 모르지만 수정사항이 있을 것 같아 메일 드립니다. 보시고 답장 주세요. 감사합니다. G 드림.”³

그 후 몇 시간 뒤, P로부터 답장이 왔다. “미안합니다. 지금 보니 두 내용이 일관성이 떨어지네요. 이렇게 바꿔 봤습니다. 반영 부탁드립니다.” G는 첨부된 수정본⁴을 받고, 자신이 가지고 있던 원본과 비교해 보았다.⁵

P 수정본) 대학생은 모름지기 논어를 읽어야 한다. 논어를 읽어야 하는 이유는 다양하다다음과 같다. 대학 생활 평가의 기준은 다양하지만 연애를 하는논어를 읽는 것이 가장 중요하다.

나름 내용이 조금은 말이 된다고 생각하던 그때, O가 보낸 메일이 도착한 것을 발견했다. “첨부 파일 확인 바랍니다.” G는 O의 수정본을 받고 이를 P에 적용하려던 차에, 무언가 문제를 발견했다. P와 O가 서로 같은 부분을 수정한 곳이 있었다.

O 수정본) 대학생은 모름지기 논어를 읽어야연애를 해야 한다. 논어를 읽어야연애를 해야 하는 이유는 다양하다. 대학 생활 평가의 기준은 다양하지만 연애를 하는 것이 그중 가장 중요하다.

서로가 서로의 수정본을 보고 작업한 것이 아니기 때문에, 단순히 O의 것으로 P의 것을 덮어쓸 수는 없었다. 그래서 G는 두 사람이 수정한 단어가 겹치는 부분을 찾아서 표시해 보았다.⁶

충돌 표시) 대학생은 < P논어를 읽어야 O모름지기 연애를 해야 > 한다. < P논어를 읽어야 O연애를 해야 > 하는 이유는 < P다음과 같다 O 다양하다 > . 대학 생활 평가의 기준은, < P 논어를 읽는 O 연애를 하는 > 것이 < P O 그중 > 가장 중요하다.

표시를 하고 G는 머리에 쥐가 나는 느낌이었다. 이제 G혼자서 이 상황을 해결할 수 없다는 것은 더욱 명백해졌다. 하나의 뿌리에서 시작한 글이 두 사람의 손을 거쳐서 누더기가 되었다. 게다가 수정이 이번 한 번만 있을 것도 아니라는 것이 그를 더 두렵게 했다. 앞으로도 몇 번의 수정이 P와 O에 의해 있을 텐데, G가 그때마다 각각에게 의견을 물어보고 문제를 해소할 수도 없는 노릇이다. 더욱이 G가 직접 쓴 글이 아니기 때문에 그가 임의로 글을 완전히 뜯어고칠 수도 없었다. 수정은 결국 P와 O에 의해 되어야 하고, G가 할 수 있는 것은 상식적인 수준의 수정 정도에 지나지 않는다.
G는 불현듯 첫 수업시간에 교수님이 기말 보고서는 인문학 글쓰기를 수강하는 모든 학생이 함께 보고서를 쓴다고 말씀하셨던 것을 떠올렸다. 20명이 같이 한 글을 쓴다고? 그때에도 G가 중간에서 글을 통합하는 역할을 담당한다면, 그가 기말 기간 내내 수면 부족에 시달리리라는 것은 명약관화했다. 지금은 2명의 글이니까 하나하나 표시해서 손댈 수 있지만, 그에게 헤르미온느의 시계가 있는 것은 아니기에 20명일 때에는 비교 표시도 할 수 없을 것이 뻔했다.
시련에 빠진 가련한 G. 지나친 보고서 스트레스에 G는 그날 저녁을 먹고 체하고 말았다. 그날 밤 내내 그는 소화가 되지 않는 배를 움켜잡고 시름시름 앓았다. 잠도 잘 못 자며 새벽까지 천당과 지옥을 몇 번을 오가던 차, 불현듯 G의 머리를 스치고 지나가는 생각이 있었다. ‘지난번 컴퓨터 전공 수업에서 들었던 이 방법을 사용하면 두 사람이 동시에 같은 글을 고치더라도 문제가 생기지 않을 수 있다.’ 그 시간 이후로 G는 자신의 아이디어에 스스로 감탄하며 평온한 미소를 지으며 잠들 수 있었다.
다음 날 아침 날이 밝자마자 그는 조원들에게 메일을 썼다. 그 내용일랑 이랬다.
“두 분이 보내주신 수정사항 잘 받았습니다. 그런데 제가 두 수정사항을 모두 반영하려다 보니 서로 충돌하는 부분이 있었습니다. 그래서 우선 두 수정사항을 일단 보류합니다.⁷ 그리고 다음번부터는, 수정본이 작업을 시작한 버전(P 또는 O)이 지금 제가 가진 최신 버전(G)의 모든 변경 사항을 반영하지 못하면, 제가 서로 다른 부분을 표시해 드릴 테니 문제를 스스로 해결한 뒤에 저에게 다시 보내주시기 바랍니다.”
즉 G가 떠올린 방법은 이랬다. 어차피 그가 스스로 충돌하는 수정사항들을 멋대로 짜깁기하는 것은 불가능하다. 그렇다면 두 사람이 스스로 그 문제를 고치도록 해야 한다. 그런데 두 사람이 공통의 글에서 시작해서 1) 서로 다른 수정사항을 만들고 2) 그 수정사항이 서로 겹칠 때만, 이 상황이 문제가 되는 것이다. 따라서 수정사항이 충돌하는 상황이 왔을 때, 뒤늦게 수정을 공통 합본에 반영하고자 보낸 사람에게 최신 버전 대비 어떻게 다른지를 정확하게 알려주면 그 사람이 알아서 수정할 수 있을 것이다. 그러면 그 사람은 가장 최신 버전에 대한 정보를 알고 수정하는 것이기 때문에 문제가 되지 않는다.

G는 이 방법이 글쓰기에 참여하는 조원이 늘어나더라도 유효하다는 점에서 매우 마음에 들었다. 이번 학기 수업에서 가능한 최대 인원은 20명이지만, 이 방법만 잘 지켜지면 수십 명이든 수백 명이든 공통 합본은 항상 충돌 문제가 없는 것이다.
얼마 지나지 않아 P는 자신의 수정사항을 합본에 반영하고자 G에게 다시 보냈다. G는 문제가 없으므로 이를 수용하여 자신의 합본에 반영하였다. 그리고 다음 날, O에게서 저번과 마찬가지의 수정 요청이 들어왔다. 그 메일을 확인한 G는 O에게 이런 메일을 보낼 수밖에 없었다.
“보내주신 수정본은 잘 받았습니다. 하지만 이미 P 씨의 수정본이 합본에 반영되어 있고, 그것이 O 씨가 보내주신 것과 충돌하는 부분이 있기 때문에 바로 반영할 수 없습니다. 현재 최신본과 O 씨의 수정본의 차이를 비교해서 보내드리니 확인 바랍니다.”
잠시 후 O 씨의 약간은 퉁명스러운 듯한 말투의 답장이 도착했다.
“서로 충돌이 나는 지점이 있긴 하네요. 그런데 P씨가 먼저 보냈다고 해서 그걸 먼저 무조건 G 씨의 합본에 반영하는 건 합리적인지 잘 모르겠네요. 제가 쓴 내용까지도 바뀌고 주제도 제 생각과 약간 달라요. 이런 식으로는 팀플이 잘 될지 잘 모르겠네요. 감사합니다. O 드림”
이 답장을 본 G는 다시금 머리를 쥐어뜯을 수밖에 없었다. 모든 것이 잘 해결될 줄 알았는데. 잘되는 조별과제는 서로 비슷하지만, 안되는 조별과제는 모두 저마다의 이유로 안 된다더니. 하지만 O의 항변이 괜한 트집 잡기는 아니었다. G가 생각해보아도 왜 O씨가 심통이 났는지 이해할 수 있었다. 겨우 3명에서 같이 일을 진행하는데 자신의 동의 없이 합본이 바뀌는 상황이 마음에 들지 않을 수 있다, 고 G는 생각했다. 하물며 자신이 쓴 부분까지 수정한다면 더더욱 그럴 수 있다.
그래서 G는 합본에 반영하는 방식을 조금 변경하기로 하였다. 가만히 생각해보면 이런 상황을 막기 위한 방식이 컴퓨터 공학에도 존재했다. 이것을 글쓰기 상황에 맞게 수정해서 다음과 같이 정하였다: 앞으로 합본에 반영하려고 메일을 보낼 때, 항상 다른 팀원을 참조(CC)로 걸도록 한다. 그리고 참조로 걸린 팀원이 OK라고 할 때만, 합본에 합친다. 만약 참조로 걸린 팀원이 불만이 있다면, 그 메일 스레드⁸를 통해 대화하도록 한다. 이 대화를 통해 이 수정본⁹을 반영할지 말지 결정한다.¹⁰
따라서 G는 다시 P의 변경분을 되돌리고 P에게 같은 수정내용을 O에게도 참조를 걸어서 보내달라고 요청했다. P도 상황이 어떻게 돌아가는지 대강 눈치를 채고 바로 그렇게 해 주었다. 그리고 메일 스레드를 통한 대화가 오간 끝에, P의 수정은 합본에 반영되는 데 성공하였다. 그리고 O도 P의 수정이 반영된 그 위에서 자신의 기여를 추가했다. 서로 모두 합의한 사항 위에서 작업이 이루어졌기 때문에, 별문제 없이 보고서는 결국 완성되었다. G, P, O는 완성된 보고서를 뿌듯한 마음으로 제출하는 데 성공하였다.
그리고 시간은 흘러 흘러, 어느새 기말이 되었다. 수업을 수강하는 학생 전원이 참여하는 상황에서 G는 자신의 조율 방법이 충분히 먹힐 것으로 생각했다. 다만 효율성을 위해 조금 손 볼 필요는 있었다. 모든 수정을 반영할 때 모든 사람의 동의를 얻는 것은 비효율적이다. 아무래도 많은 사람이 참여해서 큰 글을 쓰다 보니, 참가자들이 글 전체를 다 읽어야 하긴 하지만 각각 자기가 쓰기로 담당한 부분은 국소적이었다. 그래서 이번에 G는 수정 반영 메일을 자신에게 보낼 때, 수정 요청자와 인접한 부분을 수정하는 사람 2명 이상을 참조로 걸도록 하였다. 그리고 그 사람들이 모두 승인하게 되면 원본에 반영하는 것으로 한 것이다. 참조로 걸린 사람들은 동의와 거부 모두 가능했고, 동의는 +1로, 거부는 -1로 계산되었다. 그래서 총 합이 +2가 되면 원본에 반영되게 되었다.¹¹
거기에 더해 G는 전공을 살려 독특한 아이디어를 더했다. 수정 사항을 합본에 반영하려면 3명의 동의를 얻도록 바꾼 후, 모든 수정 요청에 대해서 가상으로 1명의 참조자를 추가했다. 그리고 수정 반영 메일이 날아왔을 때, 변경된 부분에 대해서 자동으로 맞춤법 검사기를 돌리는 매크로를 만들었다. 수정 메일이 날아오면 그것을 자동으로 복사해서 맞춤법 검사기에 집어넣고, 맞춤법 검사기가 오류를 내면 G가 추가한 가상의 참조자는 거부권을 행사했다. 따라서 총점은 -1에서 시작하게 되는 것이다. 그 수정은 다른 사람들 4명 이상의 동의를 얻지 못하면 통과가 될 수 없었다. 즉, 상당한 수의 사람이 맞춤법 문제에도 불구하고 이것이 반영되어야 한다는 것에 동의할 때에만 합본 글에 들어갈 수 있다.
이 방식을 도입하자 수정을 제출하는 사람은 자신의 수정이 더 빨리 반영되게 하려고 스스로 맞춤법 검사를 돌리고 메일을 보내게 된다. 그러다 보니 글 전체적으로 오타나 비문이 급격하게 감소할 수 있다.¹² G의 이런 아이디어와 수강생들의 노력 끝에, 결국 이번 인문학 글쓰기 수업은 최종 보고서를 다 함께 쓰는 데 성공할 수 있었다. 이 모든 과정에서 G가 제공한 협업 방식이 효과적이라는데 모두가 동의했다. G는 인알못이지만 A+를 받고 교양 수업을 수료했으며, 앞으로도 잘먹고 잘살았다고 한다.

여태까지 조별과제 상황을 통해서 컴퓨터 공학에서의 협업 방식을 살짝 엿보았다. 엄청나게 간략화된 제시이지만, 원래의 복잡한 과정도 결국 여기에 나온 내용의 확장에 지나지 않는다. 몇 만명이 동시에 수정하는 수십억줄 짜리 구글이라는 ‘글’도 위와 같은 방식으로 공동 작성된다. 실제로는 G가 하는 역할은 모두 자동화된 프로그램으로 대체되며¹³, 모든 과정에서 사람이 직접 들여다보고 토론하는 것을 제외하면 모든 것이 자동화 플랫폼으로 운영된다. 즉, 프로그램을 작성하는 사람은 자신의 변경사항을 만들고, 충돌 보고서가 오면 그것을 읽어보고 수정하고, 다른 사람이 참조(정확한 명칭은 리뷰)를 걸면 그것에 대해서 승인/거부만 해주면 된다. 다른 모든 귀찮은 일들은 컴퓨터에 의해 자동으로 이루어진다.
이런 방식은 조별과제 상황을 넘어선 협업이 가능하도록 한다. 즉 서로 모르는 사람끼리도 협업이 가능하다. 위 프로세스만 따르면, 수업 교실에서 서로 알던 사람들끼리 하던 프로젝트에 뜬금없이 싱가포르에 사는 K씨가 뛰어든다고 해도 문제가 없다. 똑같이 수정, 참조, 승인을 받으면 제 3자가 익명으로 프로젝트에 기여할 수도 있는 것이다. 그 덕분에 오늘날 우리가 상상할 수 없을 정도로 많은 프로그램은 익명의 기여자에 의해 만들어진다. 서로 이름도 얼굴도 나이도 알 필요 없이, 그저 수정사항이 말이 되기만 하면 그 프로젝트에 그 사람이 기여하는 것이 가능하다. 소스 공개 프로그램 중에서 1000명이 넘는 사람들이 협업한 사례를 찾는 것은 어려운 일이 아니다.¹⁴ 가령 요즘 많이 쓰이는 크롬 브라우저를 수정 하고 싶다면, 이 글을 읽는 본인이 능력만 된다면 지금 당장이라도 할 수 있다.¹⁵ 구글, 페이스북, 마이크로소프트, 아마존, 네이버, 카카오 모두 이런 식으로 공개 운영하는 프로그램을 가지고 있으며, 서로의 공개 프로그램을 사용하고 기여한다. 그리고 이런 프로젝트에 기여하는 것을 낙으로 삼고 살아가는 은둔 고수들도 있으니, 그 사람이 실제로 누구인지는 아무도 모르더라도 닉네임만으로 회자되기도 하는 등 컴퓨터 세계의 협업은 지금도 상당히 이상적인 형태로 이루어지고 있다.
그리고 단순히 협업 과정이 잘 정의되었다는 것을 넘어서는 이점도 있다. 이 시스템은 작성자 간 의사소통에서 상당한 이득을 준다. 협업 과정에서 사용하는 개념들이 잘 정의되어 있기 때문에, 프로그래머끼리 소통할 때 간단한 단어만으로도 말이 통할 수 있다. 예를 들어 이런 식이다: “이 commit merge 해봤는데 B commit이랑 conflict가 나서 보고 있어요.” 이것만으로 복잡한 버전 상황을 간단히 줄여서 표현할 수 있다. 전 세계적으로 같은 용어를 사용하기 때문에, 국적과 관계없이 협업도 가능하다. 삼성에서는 얼굴도 보지 못한 미국, 인도, 그리고 베트남에 있는 프로그래머와 내가 한 팀이 되어서 프로그램을 만든다. 내가 지금 하는 프로젝트는 우리 팀 몇 명과 캐나다에 있는 몇 명이 공동으로 진행하고 있다. 위와 같은 방식을 잘 따르면 굳이 화상통화로 회의를 할 필요 없이, 얼굴도 모른 채 같이 일하는 것이 가능하다(실제로 캐나다 협업자는 화상으로 얼굴도 아직 못봤다). 실리콘밸리부터 한국까지 모두 같은 방식으로 의사소통이 이루어지며, 모두가 의사소통 방식에 대한 지식을 공유한다는 것은 협업을 하는 데에 충분히 도움이 된다.
주위에서 있을 법한 사례를 통해 컴퓨터 공학 방법을 이용한 협업적 글쓰기가 어떻게 이루어질 수 있는지 약간 맛을 보았다. 하지만 모든 경우에 있어 이런 방법을 거치는 것이 효율적인 것은 아니다. 가령 앞서 보았던 G의 사례는 이런것 저런것 다 필요없이 단톡방에서 이야기만 잘 해도 해결될 수 있다. 쉽게 설명하려다보니 너무 간단한 예시를 들 수밖에 없었기 때문이다. 그러나 참여자의 규모가 작더라도 글의 수정 내역이 수년간 쌓이게 되면, 그 복잡도가 충분히 높아지기 때문에 협업 시스템을 활용할 필요가 커지므로, 규모가 작다고 해서 반드시 효과가 없는 것도 아니다. 결국 이 방법은 규약을 어느 정도는 강제해서, 추후에 더욱 복잡하고 해결할 수 없는 상황이 벌어지지 않도록 보장하는 역할을 함으로써 문제를 예방하고자 하는 것을 목표로 한다. 그렇기에 협업 방법론을 얼마나 어디까지 적용할지는 사례에 따라 다르며, 적용하는 사람의 판단에 달려 있는 것이다. 프로젝트가 커지면 커질수록, 글이 길어지면 길어지고 복잡해질수록, 그리고 글의 역사가 오래될수록 컴퓨터 공학적 협업 방법은 번거로움이라는 추가비용(overhead)을 무시할 수 있을 정도로 효율적이기에, 도입을 고려해볼만한 방법이 된다.

---

첨언

이미지를 추가로 첨부했습니다. 실제로 어떤 식으로 오픈소스가 운영되는지 엿볼 수 있습니다.

tensorflow_overview 는 실제 공유 저장소가 어떻게 생겼는지 볼 수 있습니다.
tensorflow_git_history 는 변경내역이 어떻게 관리되는지 볼 수 있습니다.
tensorflow_issue 는 변경내역이 받아들여지기 위해서 어떤 과정을 거쳐야 하는지 알 수 있습니다. 이건 좀 길어서 캡처로 표현하기 어려워, 링크도 첨부합니다. https://github.com/tensorflow/tensorflow/issues/37
코드리뷰의 실제 양상 https://github.com/tensorflow/tensorflow/pull/19136

수업시간에 다 다루지 못한 논의거리들

1. 글의 주제가 불명확하다

글에 두 가지 의도가 섞여 있어서 글의 주제가 불명확한 부분이 있습니다. 하나는 글쓰기에 새로운 방법론을 도입하면 효과적이라는 것이고, 다른 하나는 이러한 방법론이 널리 쓰이고 있고 효율적이다라는 것입니다. 정확하게는 두번째 주장이 첫번째 주장을 뒷받침하는 근거로 사용됩니다. 하지만 제가 글을 쓰다보니, 그리고 소개를 하려는 욕심이 많다 보니, 명시적인 주제는 새로운 방법론을 글쓰기에 도입하자는 것이지만 실제 글은 방법론의 소개에 치중한 면이 없지 않습니다. 이 부분을 자각하고 수정할 시 첫번째 주장을 보다 부각시키고, 그 한계까지 논하는 것이 필요할 것 같습니다.

2. 코드에는 되지만 글쓰기에는 적용하기 어려운 이유에 대한 생각

제가 생각했을때 일반적인 글쓰기에서 이러한 방법을 적용하기 어려운 것은, 대부분의 글이 혼자 쓰거나 협업을 해봤자 몇명에 그치기 때문일 것입니다. 그리고 보통 글들은 한 번 최종본을 제출하게되면 그대로 끝이고, 추가적인 수정 자체가 불가능한 상황이 있습니다. 이런 조건 때문에, 글쓰기에 번잡한 방법론을 적용하는 것이 너무 추가비용이 크다고 생각할 수 있습니다.
그러나 이러한 글쓰기의 제한적 조건 때문에 위와 같은 방법론을 적용을 못한다고 말할 수 있는지는 의문입니다. 왜냐하면 역으로 생각해 볼 때, 일반적인 글쓰기에 이런 구조적 방법론이 없기 떄문에, 여태까지 협업을 해 봤자 몇명이 쓰는데 그쳤던게 아닌가라는 생각이 들기 때문입니다. 그러니까 인과가 반대인것 같다는 추측입니다. 충분히 많은 참가자를 효율적으로 조율할 방법론이 없어서 협업적 글쓰기가 어려웠기 때문에, 대부분의 글쓰기는 제한적 조건으로만 이루어져왔던 것은 아닐까요? 5명이상이 동시에 글을 쓰는게 실제적으로 불가능하다고 생각했기 때문에, 기존의 글들을 쓰려는 계획을 세우는 단계에서부터 한 둘에 의해서만 글을 쓰도록 항상 생각하는 것은 아닐까요? 원래 프로그램도 예전에는 한 명이 다 쓰는 게 일반적이었습니다. 하지만 현대에(그래봤자 컴퓨터공학이 처음 발생한 것이 70년대입니다만) 이르러 이런 방법론들을 점차적으로 발전시켜, 지금은 대규모 협업이 가능하게 된 것입니다. 70년대 엔지니어에게 코드를 여럿이서 짤수 있냐고 묻는다면, 불가능하다고 답할 것 같은 직관에서 시작한 의문입니다.

---