사슬 끊은 쟝고

        ~ 의식의 흐름 ~

 
           옆동네 이야기
  (웹은 나랑 관련 없어.. 없었음 좋겠어..)
              |
              v
        더럽고 지저분한 것
        (더러운 웹쟁이들!)
              |
              v
       +------+-------+
       |              |
  사슬 끊은 쟝고!     기여에 대한 열망
 (웹은 하긴해야겠네)  (번역 기여만 한 얘기)
       |              |
       +------+-------+
              |
              v
    고심끝에 번역하기로 하였습니다.
   (Django 문서 번역을 하기로 합니다)

옆동네 이야기

웹 개발은 꼭 해봐야겠다고 생각한 것 중 하나였다. 단순히 대박 서비스를 만들어서 태평양 어느 섬에서 뒹굴거리겠다는 꿈… 은 아니었고(뜨끔), 밥벌어먹고 살고 있는 분야가 시스템 엔지니어 이다 보니, 바로 인접한 계층에 대한 이해가 필요했기 때문이었다.

SI 에도 참여해보고, 정규 개발 팀에도 들어가보고, 거기서의 보통의 역할은 인프라를 구축하고 관리하는 일이었다. (서류 작업을 제외하면) 주로 개발자 분들이 개발 환경을 요청하는 것 부터가 시작이었는데, 최근에는 가상화가 잘 되어있어서 이는 어려운일이 아니게 되었다. (그리고 동시에 내 밥줄도 매우 위험하게 되었다)

당시에 요청대로 개발 인프라를 맞춰주고, 해당 정보를 전파하면 일단의 일은 마무리 된다. 이후에는 건건히 발생하는 장애나 요구에 대해서 대응하는 식으로 전개된다. 다만, 개발자나 인프라나 둘다 서로의 영역에 대해 너무나 높은 벽이 있었기 때문에, 되는일을 한참 돌아서 가는일이 빈번했다.

인프라에서 풀어도 괜찮을 일을 자체 개발로 해결하려고 한다던가, 개발에서 지원해줘야 하는 일을 인프라에서 무리하게 해결하려고 한다던가.

개인적으로 큰일은 배포와 운영, 튜닝에서 일어났는데, 웹 개발의 절차를 제대로 이해하지 못해서 CI 가 어떻게 연동되고 하는것도 제대로 이해를 못했다. 즉, 개발자들이 젠킨스 구성해주세요, 파일 저쪽으로 자동 배포되게 해주세요, 저장소 구축해주세요, 사용자 인증용 LDAP 구성해 주세요 등등을 요청하면 다 해줬는데, 말 그대로 구성과 설치만 해줬을 뿐 그것이 시스템에 어떻게 녹아들어 묶이는지 이해하지 못했던 것이 인제와서 하는 고백이다.

의미를 모르다보니, 모니터링이나 튜닝이 제대로 될리도 없다. 서비스 레벨의 모니터링은 개발팀에서 알아서 해줬지만, 인프라 입장에서는 nagios 같은 기존의 모니터링 시스템에 통합하고 싶어했다. 개발은 개발대로, 인프라쪽 잇점을 취하지 못한 채 자체 모니터링 서비스를 만들려고 시도하는 문제도 있었다.

튜닝도 문제다. 예를들면 JVM 머신의 적정한 메모리 값은 얼마인가? 고대부터 내려오던 마법의 숫자값을 신봉하면서 따라하는게 대부분이다.

이 모든 문제들이 어째서 일어나는가, 그것에 대한 결론으로 서로의 영역에 대한 이해가 없기 때문에 로 결론내렸고, 시스템 엔지니어이지만 내 인접한 계층의 영역을 한번쯤은 연구해봐야 겠다는 생각을 하게 됐다.

가장 나를 괴롭혔던것은 웹 이었고(미안하지만 DB 는 신경쓸 여력도 없었다), 웹을 구성하는 에코시스템이 더럽고 끔찍하게 여겼으나 곧 나의 오만이었다고 인정할수밖에 없었다. 웹과 관련한 수많은 서비스가 그야말로 쏟아지는 형국이었고, 작은 단위에서는 도무지 쓸 일이 없어보이는 캐시라던가, 부하분산 같은 것들도 일단 사용은 하지만 이게 어떤 원리로 동작하는지에 대해서는 이해가 부족했다. 인접한 계층에 대한 경험을 쌓고 이해하게 되면, 왜 그것이 필요했는지 결국 이해하게 될 것이다, 나는 그렇게 기대했다.

더럽고 지저분한 것

그래서 제일 처음 접근했던것은 오랜 전통의 CGI 였다. 이 과정에서 Apache 웹 서버의 동작에 대해 알아볼 수 있었고, CGI 를 이용해 어떻게 동적인 웹을 구현했는지, 그 비효율을 FastCGI 는 어떻게 극복했는지, 각 언어 진영에서 내세운 OSGI, WSGI, PSGI, Rack 같은 다양한 웹서버 인터페이스를 보았다. 아쉽게도 누군가에게 설명할 정도로 이해하지는 못했지만, 적어도 이런게 있고, 어떻게 deploy 해야할지는 알았다. 그것만 해도 개인적으로는 큰 소득이었다.

그 과정은 정말 행복했다. 그동안 블랙박스처럼 쓰던것의 내부를 직접 만져보면서 알게되는것은 카타르시스를 느끼게 하는 것이었다. 의미없이 전승되어 내려오는 마법같던 값들의 의미를 알게되는것은 큰 의미였다. (그리고 더불어 더이상 필요없다는걸 깨닫고 바로 쓰레기통에 버렸다: deprecated)

더럽고 지저분하게 느껴지던 수없이 난립하는 표준들이 조금 덜 더럽게 느껴졌다. 개체 발생은 계통 발생을 반복한다”는 말은 진화론에서는 더 이상 성립하지 않게 되었지만, 적어도 이 말은 전산에서 여전히 통한다고 생각한다. 전산에서는 문제를 추상화의 겹겹으로 해결하려고 하기에, 고도로 추상화된 현대의 전산환경을 보면 이것이 대체 어쩌다가 튀어나왔는가 하고 고민할수밖에 없다. 이 과정을 역으로 따라 올라가 hard way 방법으로 고생하다보면, 현대의 상황이 조금은 납득이 되곤 하는 것이었다. “이야, 이거 없었음 우리 죽었겠네.”

그 과정의 이야기도 블로그에 남겼어야 하지만, 이 블로그의 모토인 적자니 어설프고, 안적자니 까먹겠고 에 따라, 적자니 부끄러울 정도로 어설퍼서 적지 않았다. (좀더 이해하면 적어야지- 를 몇번 반복하고 나니 까먹게 되더라.)

사슬 끊은 쟝고!

파이선은 그동안 혼자서 조금씩 공부했기에, 문법정도는 이해할 수 있다. 파이선도 django 나 flask 같은 훌륭한 웹 프레임워크가 있기 때문에, 여기를 시작점으로 삼으려고 했다. 그런데 왠걸, 웹 프레임워크의 세계는 적어도 내 입장에서는 전혀 직관적이지가 못했다.

django 공식 홈페이지에서 제공하는 튜토리얼만 따라했을 뿐인데, 금새 녹초가 되었다. 사실 영어가 눈에 잘 안들어와서 치라는것, 채우라는것, 입력하라는 것들만 눈치껏 보고 훌렁훌렁 지나간 탓이 크다. 튜토리얼을 끝내고, 간단한 웹앱이 눈앞에 나오긴 했는데, 단순히 copy-paste 의 결과다 보니 이게 무슨 의미가 있는가.

웹 프레임워크가 참 기괴하게 느껴졌던건 수많은 관례들(conventions) 이었다. 웹 프레임워크는 일종의 틀을 제공하여, 누가 만들더라도 그 규칙을 따르게끔 강제한다. 따라서 단체 작업에서도 코딩 스타일이나, 자원을 사용하는 방법과 규칙에 대해서 프로젝트 전체에 일관성을 보장할 수 있다. 또한, 웹 개발에 필요한 도구들을 일관적인 형태로 제공함으로써 의존성이 난잡해질 수 있는 위험을 줄일 수 있다. 그러나 거기에는 한가지 단서가 따르는데, 웹 프레임워크가 제안하는 규칙들을 외워야 한다는 점이다.

웹 프레임워크 에서 제공하는 도구들을 통해 기본적인 골격(skelton) 을 만들고, 거기에 빈칸 채우기 하듯 내용을 채워넣으면 나머지는 웹 프레임워크의 규칙대로 동작하는데, 이 규칙을 모르면 이게 도대체 왜 동작하는지 모르는 마법같은 현상이 일어난다.

이름을 이렇게 지으면 디비에 이렇게 연결되는 규칙이 있습니다, 이런 이름의 메소드는 이런 이름의 파일을 참조합니다.

줄어든 코드의 길이는, 대신 수많은 관례와 규칙을 기억하고 있어야 했다. 코드가 줄어든것은 공짜가 아니었고, 관례와 규칙이 그 줄어든 만큼을 채우고 있다. 하지만 인간이 비집고 들어갈 부분을 최소화 함으로써 실수를 최대한 줄일 수 있기에 일관성을 가지려면 이렇게 강제하는 접근이 옳다고 생각했다.

그래서 튜토리얼을 한번 마치고 난 후, 아무것도 머리에 들어온것이 없었기에 접근방법을 달리 하였다. 공식 문서를 그야말로 한줄씩 뜯어서 보는 것으로, copy-and-paste 가 아닌, 직접 내 머리로 입력하는 것으로.

그 과정에서 눈여겨 봤던건 번역이었다.

기여에 대한 열망

아주 오래전부터 꿈이 있었던것이, 어느 오픈소스라도 좋으니 뭔가에 기여하고 싶다는 욕망이었다. 혹자는 공명심이라고도 하지만, 뭐 좋다. 이름 남기는걸 싫어할 이유는 전혀 없다. 돈도 안받는데 그거라도 챙겨야지.

그러나, 그것보다 더 큰 이유는 하나의 목표를 향한 모두의 노력이 조직적으로 이루어지는, 회사와 얼핏 비슷하지만 그것과는 확연히 다른 목표를 지향하는, 그 거대한 흐름에 나 또한 동참하고 싶다는 이유였다. 이 아름다운 프로그램에 나의 노력이 조금이라도 들어있다면 그 자체만으로도 감동이 말할 수 없을 것이다.

코드를 멋지게 수정해서 남기는 것만을 기여(contribution) 이라고 생각했지만, 사실 기여의 방법은 엄청나게 많았다.

사소하게는 버그 리포팅을 남기는 것부터, 문서를 작성하는것, 문서를 번역하는 것 까지 다양한 방법이 있었다. 안타깝게도 코드쓰는 일과는 거리가 먼 탓에, 사소하게 버그리포팅이나 문서를 작성하는 곳부터 시작했다.

문서 번역 작업은 다른 기여 못지 않게 굉장히 큰 의미가 있다.

1. 자신의 공부가 된다.
   한줄 한줄 읽어가며 번역하는 자체가 엄청난 공부가 된다. 단순히 한번 읽어보는 차원과는 다른 느낌을 받는다. 정말이다.
2. 다른 이들의 진입장벽을 낮춘다.
   외국인이 아니라는 태생적인 원죄(?) 로 인해, 중고등학교 12년을 영어를 끼고 살지만 사실 부담되는건 사실이다. 원어로 번역된 자료는 진입장벽을 낮추는데에 크게 기여할 수 있다.

안타깝게도, 한국어 기여는 오픈소스에서 많지 않다. 동아시아에서 가장 활발한 기여는 중국어와 일본어, 예전에는 일본어, 중국어 순이었지만, 이제는 중국어 일본어 순이 되었다. 그 장면을 보면 항상 부끄럽고, 부럽다. 리눅스 저장소 제공만 해도 일본의 저장소와 단순 숫자 비교를 하면 터무니 없이 차이가 난다. 이것이 사회에서 오픈소스를 어떻게 바라보고 어떻게 지원하고 있는가를 명확하게 구분하는 기준이 된다고 생각한다.

단순히 오픈소스가 무료라서 뺏어쓰는 형태는 인제 벗어날 때도 되지 않았나, 뒷사람들을 위해서, 좀더 넓게는 국가적인 투자가 될 수도 있을 것이다. 국가주의를 싫어라 하긴 하지만, 국가간 기여의 차이가 극심한 몇 장면들을 보면 마음 아픈게 사실이다.

그러나, 그 와중에도 번역 기여나 문서 기여에 활발하신 분들이 많다. 그 분들의 덕을 나도 많이 보았고, 직접 참여해보니 얼마나 어려운지도 잘 알겠다. 그분들의 노력과 기여는 뒤따르는 한 사람이라도 더 끌어당겼을 원동력이 되었다. 한글화 작업물을 보면 항상 감사하는 마음을 가져야 하겠다. 그리고 계기가 된다면, 그 이유가 개인적인 차원이든 무엇이든- 받은 것을 다시 되돌려 줄 수 있음을 영광스럽게 생각하는 문화가 되었으면 한다.

가장 처음 했던 기여는 (위키피디아에 대한 환상에 가까운 동경이 있어서) 미디어위키 엔진에 대한 한글화였다. 위키의 설명서 부분과 메뉴얼을 수정했었는데, 사실 영어를 잘하는 편은 아니라 오역이 엄청났다. (그거 잡느라 고생하신 다른분들께 죄송하다는 말씀을..)

이후에도 기회가 될 때마다 번역 기여는 참여하려고 노력했는데, 위키피디아의 아티클을 업데이트 하는것도 포함했다. 개인적으로 공부도 많이 되고, 즐거운 일이었지만, 검증을 거쳐야 하고, 정제된 언어로 작성해야 했기 때문에 큰 어려움이기도 했다.

최근에 했던 유익한 번역중 하나는 moodle 프로젝트의 번역이었는데, 10년전 선배님들이 작업하신 이후로 지금까지 맥이 끊겨, 이 좋은 오픈소스 도구를 제대로 사용하지 못하게 되었다. 학교에서 써보려고 열심히 삽질하다가 지금은 멈춰있지만, 어떻게든 다시 살려서 사용했으면 좋은 프로젝트다. 이것도 나중에 블로그에 정리해서 사람들을 모아봐야지…

이제 새로 부딪힌 과제는 Django 의 공식문서의 번역이다. 중국어 일본어는 있는데 한국어만 없어!! 왜! 어째서!!

그런 이유로-

고심끝에 번역하기로 하였습니다.

Django 튜토리얼을 눈으로만 따라간 죗값은 매우 컸다. copy-and-paste 를 한 자신의 눈은 속일 수 없으리라, 되긴 되는데 이게 왜 되는지 모르는 극한의 형벌속에서 괴로워 했다.

Django 를 번역에 기여하는 방법을 찾는것도 한나절이었다. 찾아서, 개인 환경에 개발환경을 구축해놓는것 까지 해놓고 하나씩 번역하기 시작했다.

번역의 멋진점은, 일단 좋건 싫건 문장 자체를 꼭꼭 씹어 이해하지 못하면 번역 자체가 안된다는 점이다. 자연스럽게 공부가 될 수밖에 없다. 그리고 논리적인 전개를 연결시킬 정도로 이해하지 못하면 번역물은 괴상한 결과가 된다. (번역작업을 몇번 하다보니, 책을 고를때 자연스럽게 역자가 누군지를 면밀하게 보게 된다)

예를 들어, settings, configuration, preference 의 차이를 구분하여 번역하려면 어떻게 할까, 단순히 “설정”, “환경” 같은 단어로 대체하기에는 미묘한 늬앙스의 차이가 존재한다. install 과 setup 의 차이는 어떨까, edit 는 “편집” 일까 “수정” 일까?, commit 이라는 단어는 어느 상황에서 쓰이는가, 어째서 이 단어를 썼는지 매달리지 않을 수 없는 지경에 몰아넣는다.

사물을 이해하기 위해 먼저 그 이름을 붙였다 라는 접근법처럼, 이 단어가 어디서 왔는지 민감해질 수밖에 없다. 또한, 언어마다 표현을 위한 구조가 조금씩 다르다. 언어마다 표현 못할것은 없겠지만, 표현이 쉬운 부분이 있고 어려운 부분이 있었다. 직역하면 외국어 냄새가 나는것도, 그 언어 구조를 곧바로 한국어로 번역한 탓에 발생하는 어색함이라고 생각한다. 제대로 이해해서, 머릿속에서 분해한 다음, 한국어투에 맞게 조립해서, 글로 구조화 하면 자연스럽지만, 작가의 의중을 제대로 반영하지 못하기 때문에 의역은 피해야 한다고 주장하는 이들도 있다.

하지만 기술 서적은 대개 정보를 전달하는 역할에 국한되기 때문에, 의역은 큰 문제가 되지 않는다고 생각한다. 가능한한 정확한 지식을, 이해하기에 가장 부담없는 어투로, 자연스럽게 전달하는것이 중요하다고 생각된다.

짧게 말하자면, Django 의 공식 문서의 아주 일부분을 이틀에 걸쳐 진행했다. 기존에는 번역 플랫폼상에서 간편하게 작업하다가, 다소 다른 방식으로 작업하는것은 처음이라 아직 손에 익지는 못했다. 이 방식이 올바른 방식인지도 잘 모르겠으나, 안내하는 표준적인 방식을 따르며, 개선할 수 있는 부분은 아직 있다.

가장 큰 소득은 역시 개인적인 것인데, 그동안 눈으로만 흝을때는 보지 못했던 행간의 의미나, 세부적인 부분을 하나도 놓치지 않고 볼 수 있었다는 것에 있었다. 덕분에 한장 번역하는데 몇시간이 걸리긴 하였으나, 이 결과물이 나 뿐 아니라 새로 진입하는 사람들에게도 도움이 될 수 있으니 그것도 나름대로의 의미가 있다.

다만, 절대로 혼자서 작업을 완료할 분량은 아닌지라, 공동의 자산으로 옮겨야(=떠넘겨야) 할 것 같다. 어느정도 기반을 마련하고 연락을 돌려야 할 것 같고, 그 전에 그동안 했던 작업을 정리하는 차원에서 블로그에 간단하게 글을 남긴다.

사실 이 글에는 뭘 어떻게 찾았는지 하나도 안썼는데, 그냥 일기 쓴 것이니 그려러니 해 주시길.