내 지경을 세계로 넓히기 |
| 개인적인 경험들을 중심으로… |
 |
 김도형 dynaxis@alticast.com
양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다.
2008년 12월 09일
|
|
|
|
이번 칼럼은 정확히 열한 번째이자 마지막 칼럼이다. 마지막 칼럼을 준비하던 중 마침 JSR 272가 최종 릴리스됐다는 메일이 날아 왔다. 2005년 4월부터 근 2년 간 활발하게 참여했던 규격이 드디어 TCK(Technology Compatibility Kit) 작업과 그에 따른 마지막 자잘한 수정을 거쳐 완결된 것이다. 이렇게 생각해 보니 일천하나마 자바 초기에 해외 커뮤니티에서 도움을 주고 받았던 경험이나 JCP(Java Community Process)를 포함해 몇몇 DTV, DMB 관련 표준화 단체에서 소프트웨어 규격 작업을 했던 경험, 업무상 외국 업체들과 소통했던 경험을 공유해 보는 것도 나쁘지는 않겠다 싶다.
물론 국내에서도 ITU, ISO 등에서 회사, 국가 간 이해 관계가 첨예하게 갈리고 특허나 금전적인 득실에 따라 이합집산하는 상황에서 고군분투하는 사람도 많고, OMA(Open Mobile Alliance)나 JCP에도 국내 기업이 활발히 참여하는 경우도 많지만, 소프트웨어 분야에서 개발자 관점에서 이런 소통 경험이 일반적으로 공유된 경우는 별로 없는 것 같다. 아파치 MINA 프로젝트로 유명한 이희승 님이 오픈 소스 프로젝트 참여에 대한 발표를 한 것이 있고 2004년 월간 마이크로소프트웨어에 기고한 내용이 있을 뿐이다. 게다가 개인적으로 꼼꼼히 살펴 보는 편인 JCP의 경우 영어는 필자보다 훨씬 나은데도 국내 참여자의 소통 기술이나 기여된 문서, 결과물의 수준이 그다지 만족스럽지 못한 경우가 꽤 있다.
이런 관점에서 통상 영어 공부에 큰 시간을 할애하지 않아왔고 국내에서 학교를 나온 전형적인 공대생인 필자의 개인적인 경험과 느낀 점을 함께 나눠보고자 한다. 비단 표준화 같은 특이한 업무 외에도 다양한 측면에서 도움이 될 만한 부분이 있을 것이다. 단, 필연적으로 나오는 영어에 관련된 개인적인 생각을 비롯해 모든 내용은 소프트웨어 개발자라는 독자를 전제로 한 것임을 양지해 주길 바란다. 이 글은 개발자에 의한 개발자들을 위한 글이다.
인터넷의 잠재력을 깨닫다
1993년 모자익(Mosaic)의 등장으로 인터넷이 대중에게 알려지기 전인 1990년대 초 이미 대학에서 인터넷을 경험할 수 있었다. 여담이지만 모자익을 처음 본 것이 병역을 위해 휴학하기 직전이었다. 당시 인터넷 상황을 생각할 때 어마어마하게 비효율적이던 HTTP 1.0을 사용해 그림 따위를 주고 받는 모자익을 처음 보고는 그딴 걸 누가 쓰겠냐고 무시했고, 그 탓에 복학 후 과제에 필요한 파일을 올려 놨다며 조교가 써 놓은 ‘ftp://ftp.bbb.ac.kr/pub/...’ 형태의 URL을 이해 못해 난감해 했던 나다. FTP가 뭔지는 알고 학교 내 호스트 이름도 알겠는데 합쳐 놓으니 모르는 게 문제였다. 알량한 자존심에 누구한테 묻지도 못하고 야후 같은 웹 검색 엔진도 아닌 Archie 서비스로 무명 FTP 사이트 내 URI에 대한 RFC 문서를 찾아 읽었을 정도니 참으로 격세지감이다.
하여튼 일찌감치 인터넷을 통해 IRC나 뉴스그룹을 접할 수 있었던 환경에 있었지만 초기에는 그저 Archie로 멀리 미국에 있는 대학의 논문을 검색해 찾아 읽으면서 어렴풋이 인터넷의 잠재력에 눈을 뜨고 있었을 뿐이다.
본격적으로 인터넷을 통해 해외와 접촉을 시작한 것은 웹이 일반화되기 시작하고 자바가 나오면서부터다. 1995년 10월경 자바를 처음 들여다보기 시작했는데 이 당시만 해도 자바 규격도 알파 버전이었고 썬이 공개한 불완전한 온라인 문서 외에는 아무 자료도 없었다. 그래서 뉴스그룹을 두드리기 시작했다. 지금은 많은 서브 그룹이 생겼지만 당시 막 시작한 comp.lang.java에 질문을 올리기 시작했는데, 구어체가 많고 여러 국적인 사람들이 글을 올렸던 터라 생각 외로 글이 술술 읽히지 않아 고생했던 기억이 있다.
재미있는 것은 자바가 처음 공식 발표된 것이 1995년 5월(자바 역사 참고)이었던 탓인지 솔직히 제대로 된 답변을 얻은 적은 거의 없었고 하나 둘씩 다른 사람 질문에 답변을 달아 주다 보니 대부분의 시간을 질문에 대한 답변을 적고 토론에 참여했다. 웹 이전에 벌써부터 일반화된 뉴스그룹과 웹을 통해 내 지경을 넓히는 수단으로 인터넷에 대해 비로소 눈을 떴다. 초기 자바 관련으로 잡지에 기고할 때는 당시에는 얻기 힘들던 자바 응용 사례를 찾기 위해 뉴스그룹에 글을 올리고 NASA를 포함해 많은 사례를 찾아 원고를 완성하기도 했다.
인터넷은 인간이 협업하고 지식을 공유하는 데 획기적인 변화를 가져 왔다. 이메일, 게시판, 실시간 메시지, 웹 사이트 등 시간과 공간의 한계를 뛰어 넘는 다양한 소통 방식을 만들어냈고 텍스트뿐 아니라 그림, 동영상, 음성 등 다양한 정보를 교환할 수 있다. 당장 전화통을 붙들고 유창한 영어를 할 필요도 없고 비행기를 타고 먼 타국에 가서 유창한 영어로 열띤 토론을 할 필요도 없다. 메신저를 쓰는 게 아니면 문장을 작성하는 데 10초가 걸리든 1분이 걸리든 그저 내 효율의 문제일 뿐이다. 기본 표현 능력만 있으면 개발자로서 내 지경을 얼마든지 해외로 넓힐 수 있다.
왜 내 지경을 해외로 넓혀야 하나?
뻔한 이야기지만 왜 국내에만 갇혀 있지 말라고 하는지에 대해 간략히 언급해 보고자 한다.
다양성을 통한 상승 작용을 꾀할 수 있다
우리와 다른 문화에서 자라나고 다양한 교육을 받고 다양한 경험을 가진 사람과 협업을 해 보면 새로운 아이디어를 얻을 수 있고 일하는 방식도 많은 참고가 된다. 게다가 어떤 분야에 정점이란 없다. 제 아무리 최고의 전문가라도 다른 사람에게 지식적으로나 경험적으로 듣고 배울 게 있는 법이다.
수요와 공급이 많으면 더 많은 정보가 나돈다
소프트웨어 분야의 많은 책은 수입 원서나 번역서로 찾아 봐야 한다. 물론 자바, 유닉스 등 많은 소프트웨어의 본고장이 해외인 탓도 있지만, 우리나라만 놓고 봐서는 수요는 물론이고 공급이 충분하지 않기 때문이기도 하다. 이 같이 더 큰 집단의 일원이 되면 더욱 양질의 정보를 더 많이 접할 수 있다.
기술의 원류에 가까이 갈 수 있다
미국이나 유럽의 프로그래머가 낫다는 이야기가 아니다. 일례로 필자의 경우 1995년 후반부터 자바 프로그래밍을 시작했는데 2000년도까지는 분야와 관계 없이 거의 모든 자바 규격을 읽었다. 게다가 전공 탓에 JVM 내부에 대한 일에도 꽤 많이 관여를 해 왔다. 당연하지만 그래도 썬 본사 엔지니어들, 특히 표준 미팅을 다닐 정도의 엔지니어들과 일하다 보면 나름 배울 점도 많고 내가 접할 수 없는 정보를 접할 수 있는 경우도 많았다.
더 많은 기회와 넓은 인맥을 가질 수 있다
여기서 기회는 여러 의미인데 업무적인 기회이기도 하고 단순히 날 향상시킬 수 있는 기회이기도 하다. 그리 쉽지는 않지만 직업적인 제안을 받는 경우도 있고 좀처럼 해 보기 힘든 경력을 쌓는 기회가 되기도 한다. 예를 들어 국내에서 소프트웨어 표준 규격 작업을 해 볼 기회가 얼마나 있겠는가? 사실 애먼 자격증 하나 갖추는 것보다는 표준 규격 작업에 참여해 보는 편이 경력 관리에는 더 낫다(물론 쉬운 일은 아니다). 인맥 부분은 조금 애매한데 특정 분야에서 어지간히 지속적으로 활동하지 않으면 사실 인맥 관리가 쉽지는 않다. 게다가 우리도 외국 사람 이름이나 얼굴을 잘 기억하지 못하는 것처럼 외국 사람도 우리 이름이나 얼굴을 잘 기억하지 못한다. 여담인데 회사 초기에 같이 다녔던 회사 동료 한 분은 어렸을 때 미국으로 이민 갔던 재미 교포였는데 같이 출장 다니다 보면 그 분은 한국 기업 직원 이름을 곧잘 잊어 버리고 필자는 미국이나 유럽 쪽 사람들 이름을 곧잘 잃어 버려 서로 물어봐야만 했다. 하지만 적절한 활동을 통해 지속적으로 관계를 지속하면 업무적인 부분이나 개인적 경력 부분에서 유용한 인맥을 쌓을 수도 있다.
자, 인터넷의 등장 등으로 국경이 허물어지고 있다. 혹자는 “제 주변에는 그럴 기회가 없습니다”라고 말할지도 모르겠다. 하지만 뜻밖에 많은 소프트웨어 회사가 국제 표준을 모니터링해야 하는 입장에 있고 내 업무도 마찬가지일 수도 있다. 또 JCP 같은 일부 활동에는 개인도 무료로 참여할 수 있고, 비교적 특허나 기타 이권으로 얼룩지지 않아, 사견이지만 소규모 전문가들과 심도 있는 활동을 할 수 있어 좋다. 그뿐 아니라 버그 리포트나 버그 패치로 시작해 오픈 소스 프로젝트에 참여해 볼 수도 있을 것이다. 해외 협업 건에 무조건 끼어들려고 노력할 필요는 없지만 그렇다고 내 지경을 너무 좁게 사내나 국내로 스스로 좁히지는 말자.
영어 장벽부터 허물어 보자
한국어가 세계 공통어이면 좋으련만 불행히 인터넷에서 살아 남으려면 그래도 영어 몇 마디는 구사할 줄 알아야 하는 게 현실이다. 대기업이나 중소기업을 막론하고 개발자 중에서 영어 문제로 해외 출장 가서 영어가 가능한 동료가 오면 “이렇게 이메일 써 달라”, “이렇게 말해 달라”라고 하는 사람이 비일비재한 것이 현실이다. 그뿐인가? 오픈 소스를 포함해 인터넷 커뮤니티 활동에 인색한 것의 가장 큰 이유로 꼽는 것이 바로 영어다. 특히 영어가 취직 전선의 주무기가 아닌 개발자는 특히 언어가 약하기 마련이다. 게다가 요즘 신세대는 다르다고 듣기는 했지만 여전히 우리 교육 시스템은 읽기에만 익숙하고 ‘듣고 말하고 쓰기’에는 젬병인 사람을 양산한다. 자, 그럼 현실은 이렇게 암울하기만 할까?
필자의 경험을 이야기해 보자. 솔직히 아직 어디서 내세우기에는 턱없이 부족한 영어 실력이지만 그래도 업무 이메일 잘 적고 마케팅 자료도 직접 영어로 쓰고 미리 속으로 한두 번 읽어보면 대본 없이 영어 발표도 한다. 물론 간혹 회의에 들어가면 말이 한없이 꼬이기도 하지만 그래도 무던히 회의도 하고 더 어렵기는 하지만 아쉬운 대로 전화 회의도 들어간다. 어디 학원이라도 열심히 다니고 공부를 열심히 한 건 아니고 실전을 통해 한 10여 년 동안 조금씩 나아진 결과다. 제대로 영어 공부에 시간을 썼더라면 더 나아졌겠지만 최소 실제 영어를 써야 하는 상황에서 의식적으로 노력을 하기는 했다. 게다가 이른바 개발자 평균치고는 나쁘지 않은 영어 실력이라고 생각하지만 뭔가 내 지경을 넓히는 데는 시원찮은 필자의 영어 실력보다 더 못해도 충분하다.
얼굴에 철판 깔자
당장 개발자가 지경을 해외로 넓히지 못하는 주된 이유는 불필요하게 완벽하려고 하기 때문이다. 흔히 말하기가 늘지 않는 이유로 한국인 특유의 완벽한 문장 구사에 대한 강박관념을 들기도 하는데 개발자로서 영어라는 장벽을 허무는 데도 이 강박관념을 허물어야 한다고 생각한다.
1999년 필자가 맡은 팀이 3개월 간 미국 LA에 파견을 갔을 때다. 회사 초기라서 오판이 잦았다. 원래 해외 파트너와 접촉해야 하는 일이 많을 것으로 생각하고 미국 사무실을 설립하면서 따라 나간 것인데, 나가보니 개발만 해야 할 뿐 아이러니하게도 현지인과 회의를 하거나 의사 소통을 할 일이 별로 없었다. 게다가 사무실에는 우리 말이 가능한 매니저 한 사람이 있었고 또 한 사람은 교포였는데, 교포 분은 우리 말이 서투르기도 했고 우리도 영어가 서툴러 바로 옆에서도 서로 이메일을 교환하는 상황이었다. 그뿐 아니다. 사무실 밖이라고 해 봐야 숙소, 식당, 교회 정도 밖에 갈 곳이 없다. 게다가 LA에는 한국 식당과 한인 교회가 많다. 거길 벗어나서 몰이나 패스트푸드점에 가도 들어가서 “콤보 메뉴(세트 메뉴) 몇 번”이라고 말하면 그저 “여기서 먹을 거냐?(For here? To go?)”라고 묻는 게 고작이다. 물론 이 단순한 대화에서도 “콤보 넘버 파이브(5번 메뉴요)”라고 이야기했더니 “애플 파이”를 돌려받은 팀원도 있었지만 말이다(아마 파이브라는 발음을 파이라고 들었던 모양이다).
재미있었던 것은 재미교포도 한국어를 잘못하면 창피하게 생각해서 말을 잘 안 하더라는 것이다. 그리고 더 재미있는 것은 별로 영어를 쓸 일이 없었음에도 3개월 파견을 마치고 돌아 왔을 때는 그래도 말하기가 수월해졌다는 점이다. 상황이 상황이니만큼 영어 실력이 늘었을 리는 만무하고 그저 얼굴이 좀 더 두꺼워졌을 뿐이다. 이처럼 얼굴에 철판 까는 일은 내 지경을 넓히기 위한 제 1단계다. 중국에서는 ‘리양’이라는 사람의 ‘미친 영어’라는 학습법이 유명한데 역시 체면을 버리는 것을 첫째 계명으로 하고 있다.
다른 일화를 들어보자. 솔직히 일본 사람들과 협업한 경험이 많지도 않고 일본 내 상황을 잘 몰라서 일반화의 오류를 범할 수는 있지만 전시회에 나가서 일본 회사 스탠드로 가 보거나 일본 사람이 필자의 스탠드로 왔을 때 이야기를 해 보면 일본에서 직접 출장 나온 사람들의 영어 실력은 대체로 참혹하다. 몇 마디 더듬더듬 질문하고 답을 듣고도 거꾸로 내가 질문을 던지면 도망 가는 경우도 비일비재했다. 그 밖에도 간혹 일본 회사와 이메일을 주고 받아보면 그래도 내 문장은 양반이라는 생각이 든다. 하지만 일본 사람들은 인터넷에서 상당히 활발한 활동을 하고 있다.
루비 언어를 만든 사람은 잘 알겠지만 유키히로 마쯔모토(Yukihiro Matsumoto)라는 일본인이다. 직접 만나보지 않아서 이 사람이 얼마나 영어에 익숙한지는 모르겠지만 루비 사용자 가이드는 그 사람이 일본어로 적고 다른 사람이 영어로 번역했다. 그 외에 루비 성능 향상을 위해 만들고 있는 YARV(Yet Another Ruby VM) 개발자 역시 일본인이다. YARV 페이지에 가 보면 RubyConf에서 발표한 영문 자료가 있는데 한번 읽어 보기 바란다. ‘주의!’라는 제목의 슬라이드에 첫 문장으로 ‘I can’t speak English well’이라고 써 놨다. 자기가 이상한 영어를 쓰면 슬라이드를 읽으라면서 슬라이드의 영어도 그리 아름답지 않다. 그래도 영어가 모국어인 사람들이 그 사람의 발표를 경청한다. 날 위해 의사 소통이 더 나아지도록 노력할 필요는 있지만 주눅이 들어 소통 자체를 포기하지는 말자. 최소 영어 실력으로 회사 들어가고 밥 벌어 먹는 사람이 아닌 개발자라면 절대 그래서는 안 된다.
남의 글을 많이 읽고 흉내내자
그럼 듣고 말하기부터 해야 하나? 결론부터 이야기하면 그럴 필요는 없다고 생각한다. 개인적으로 인터넷 시대에 개발자가 가져야 하는 첫 번째 소양은 읽기이고 그 다음은 잘 쓰기다. 개발자로 영어에 익숙해지는 가장 좋은 방법은 영어를 쓸 수밖에 없는 상황을 만드는 것이다. 업무적이든 개발자로서 취미든 일단 읽고 쓸 수밖에 없는 상황을 만들어 보자. 다소 껄끄럽더라도 기술 관련 영문 뉴스라도 읽고 관심 분야 포럼에 들어가서 글을 읽으면 시작으로는 나쁘지 않다. 그 다음이 중요한데 분명 개발자 일을 하다 보면 취미든 업무든 인터넷 포럼에 글을 올리거나 이메일을 적을 일이 있을 것이다. 온라인 영어 사전이라도 띄워 놓고 남의 글을 흉내내면서 얼굴에 철판 깔고 많이 적는 게 중요하다.
필자의 경우 앞서 언급했던 대로 뉴스그룹에 글을 쓰면서 처음으로(그렇다. 정말 처음이었다) 영어 문장을 제대로 써 보기 시작했는데 지금 검색해서 예전 써 놓은 것을 보면 끔찍할 정도다. 하지만 자바 관련 정보를 얻는 게 중요하고 필요했기 때문에 마냥 써야 했다. 질문을 던지면서 ‘Thanks in advance(미리 감사드립니다)’라고 덧붙이거나 답을 쓰면서 ‘Hope this helps(도움이 되길)’ 같은 표현을 덧붙이는 것도 마냥 따라 했다. 시제나 단, 복수 표현, 관사를 틀리는 건 당연하고 어떤 웹 페이지에 ‘a personal port of JDK’라고 써 놓은 것을 보고 해당 페이지를 뉴스그룹에 소개하면서 ‘It’s a personal port’라고 말을 그대로 옮겼다가 ‘그 JDK를 네가 포팅한 거냐?’라고 질문을 받기도 했다. 웹 페이지 주인이야 비공식으로 개인이 포팅을 한 것이지만 그대로 옮기면 졸지에 내가 포팅한 셈이 되니 문제였다.
그렇게 흉내 내고 끊임 없이 고치다 보면 조금씩 나아진다. 하지만 거듭 명심할 것은 내가 영어를 잘못하는 건 당연하다는 것이다. 게다가 더 다행인 것은 내 분야의 이야기를 주로 할 때 내가 알아야 하는 표현이나 낱말은 그리 많지 않다. 뒤에 설명하겠지만 오픈 소스 프로젝트에 주도적으로 참여하거나 표준화 작업에 가서 문서에 기여하려고 꼭 완벽한 영어 문장을 만들어낼 필요는 없다. 누군가의 도움을 받더라도 내가 기여할 수 있는 것이 명확하기만 하면 된다. 물론 각자 자신의 처지에 맞게 노력을 경주해야 하지만 그래도 이런 시작이 실력 향상에 동기 부여를 하고 도움도 된다는 것을 잊지 말자.
참고로 요즘은 시대가 좋아 표현이 어색하다는 느낌이 들 때 구글에 넣어 보면 최소한 남도 쓰는 표현인지는 알 수 있다. 게다가 다음 사전은 표현을 넣으면 예문과 구어/문어, 사적/공적인 경우를 나눠 사용 빈도까지 표시해 준다.
본격적인 활동에서 명심할 점
제도권 표준화 단체에서 활동하는 사람들이나 오픈 소스 쪽에서 명성을 얻은 사람들에 비해 필자의 경험이 별 것 아닐 수도 있겠다. 그래도 사내에서는 끊임 없이 해외 업체나 해외 법인의 현지인들과 대화를 하고 문서를 교환해야 하며, 국제 표준 쪽으로는 두 개의 JSR과 DMB 관련 표준화 작업에 활발히 참여했고 가끔 DTV 관련 표준화 작업에도 참여하고 있다. 앞서 언급했던 JSR 272에서는 주요 API 중 일부를 설계하고 규격을 작성했으며 다른 멤버가 작성한 부록 장의 내용을 고쳐 쓰고 편집했다. 그리고 DMB 쪽은 교정 작업에서 경험 많은 사람들의 도움을 받기는 했지만 100페이지가 넘는 규격의 대부분을 작성해 해외 표준 단체에 제출하기도 했다. 그 외 수시로 기타 표준 단체 활동을 위해 리포트를 작성한다.
비록 표준화 작업을 할 경우는 대기업에 있더라도 그리 흔하지만은 않겠지만 업무적인 것이나 개발자로서 커뮤니티에 참여하는 경우에 필자의 경험이 도움이 되리라고 생각하면서 몇 가지 언급해 보려고 한다.
항상 중요한 것은 내 실력이다
표준화가 됐든 사업적인 일이든 내가 끼어 들어야 한다면 그 이유는 내 영어 실력이나 회사에서 내 위치가 아니라 내 지식과 역할 때문이어야 한다. 앞서 루비의 예를 들었지만 내가 줄 것이 있고 상대방이 받을 것이 있으면 아쉬운 것은 저 쪽이다. 또 그 때문에 날 인정해 준다.
불행히 항상 그런 것은 아니지만(구체적으로 아닌 예도 알고 있다) 국내 기업이 JCP에 활동을 할 때 정작 규격 작업을 할 만큼 기술적으로 충분한 수준이 아닌 사람들, 즉, 해당 분야 경험 없이 이미 관리 역할로 넘어 갔거나 이른바 표준 전담 인력인 경우를 많이 봤다. 해당 JSR 내에 대다수의 전문가들이 다 이해하는 개념을 혼동해서 애먼 이슈를 문제 삼거나 심한 경우는 어떻게 해당 JSR이 JCP 임원회(Executive Committee)를 통과했는지 의심스러운 경우도 있다. 설익은 논리나 추측성 발언, 존재를 과시하기 위한 어설픈 발제는 신뢰를 떨어뜨린다.
최소 내 수준에 맞는 기여를 하려고 노력하라
어느 집단에서든 이른바 Read-Only 멤버가 되면 언젠가는 볼멘 소리를 듣기 마련이다. 이런 측면에서 기술적인 숙련도를 갖추고도 용기 있게(영어를 잘한다고 쓰지 않았다) 표준화나 사업과 관련된 커뮤니티에 참여할 수 있는 인력이 없는 탓에 국내 기업은 Read-Only가 되기 십상이다. 통상 작은 기업일수록 상황이 더 안 좋은데, 예를 들어 표준화에 참여해야 하지만 참여할 수 있는 인력이 소수면 해당 인력들이 부담이 되어 결국 자연히 Read-Only 회사가 되어 버린다. 충분한 모멘텀이 있다면 내가 아니라도 해당 표준화나 커뮤니티는 굴러간다. 하지만 곧 시장 평판이나 결정 과정에서 배제 등의 직간접적인 역풍을 맞을 가능성이 높아진다.
또한 개인적으로 봤을 때도 어떤 커뮤니티에 들어가서 그저 듣기만 하는 사람이 되기 십상이다. 정말 기여할 게 없느냐를 보면 사실 그렇지도 않다. 최소한 사용자로서 버그를 발견하기도 하고 오픈 소스라면 급한 대로 이유를 찾아 고쳐 쓴 경험도 있을 것이다. 최소한의 시간을 들여 기여하면 자신도 성장하고 커뮤니티도 성장한다.
다시 말하지만 ‘영어’는 여러 방법으로 해결 가능하다
본격적으로 참여하면 설사 일차적인 두려움을 극복했더라도 영어가 문제가 될 것이다. 하지만 뜻만 통하면 영어 문제는 어떻게든 해결된다 특히 개발자라면 더욱 그렇다. 일례로 필자가 참여했었던 유럽 쪽 표준화 단체인 DVB에서는 영어를 ‘모어(母語)’로 쓰는 사람이 편집자로 자원하기를 제안하는 경우를 많이 봤다. 그럼 대체로 미국, 영국 중에서 자원한다. 그렇다고 표준화 단체에 미국, 영국 사람 판이냐를 보면 그렇지 않다. 독일 사람이 의장이고 기여자의 대다수는 영어를 모어로 쓰지 않는다.
또 다른 일화를 들어보자. 필자가 독일 뉘른베르크에 있는 모 연구소에서 열린 DMB 관련 회의에 참석해 이렇게 이야기한 적이 있다. “난 영어가 모어가 아니지만 규격 작성에 최대한 기여하겠다.” 그러자 대여섯 명뿐인 소그룹 내 다른 멤버들이 다음과 같이 말하면서 웃더라. “나도 영어가 모어가 아니다.” 그 사람들은 다 독일 사람이었다. 웃기지 않는가? 세상에는 영어를 모어로 쓰지 않는 사람이 훨씬 많다.
충분한 시간과 여력을 확보하라
필자 개인적으로는 회사 업무로 진행하는 표준화나 기타 활동에 어느 정도 기여를 해 놓고도 끝까지 마무리를 못 짓는 경우가 많다. 이는 앞서 이야기했듯이 인원 부족이나 표준화나 커뮤니티 생태계 규칙에 대한 이해 부족 때문에 표준화나 기타 활동을 주 업무로 취급하지 않기 때문이다. 또 개인들 역시 자신이 투자해야 하는 시간을 간과하고 야심만 앞서고 결과만 바라보기 때문이다.
회사에서 하는 표준화라면 사실상 바쁜 관리자나 개발자가 통상적인 업무를 맡은 상태에서 부업으로 할 수 있는 분량의 일이 아니다. 문서 작업이나 전화 회의, 그리고 필수는 아니지만 가끔은 필요한 회의 참석 등을 고려해 해외 대부분의 회사와 여력이 닿는 국내 대기업은 표준화 전담 인원을 둔다. 앞서 이야기했지만 더 많은 개발자가 자신의 업무 연장선에 있는 표준화나 커뮤니티 활동에 용기 있게 참여해 부담이라도 나눠져야 한다. 개인의 경우라면 간단한 일부터 참여해 가면서 자신의 생활 패턴이나 여건을 생각해 조금씩 범위를 넓혀 나가야 한다. 한 가지 말할 수 있는 건 모든 일이 그렇지만 자신이 생각한 것보다 훨씬 더 노력이 필요하다는 점은 명심하자.
법률적인 부분에 관심을 가지자
흔히 한국 사람들이 국제적인 활동에서 간과하는 부분은 법률적인 부분이다. 특히 특허나 저작권, 라이선스 조항 등에 관심을 가져야 한다. 어떤 단체에 참여하거나 규격, 소스 코드 등을 얻을 때는 라이선스 동의서나 저작권 조항에 어떤 내용이 있는지는 관심을 가지고 봐야 한다. 통상 계약서나 라이선스 동의서는 일반인들이 읽기에 껄끄럽기는 하지만 유명한 오픈 소스 계약서는 요약해 놓은 해설도 많고 비교적 라이선스 동의로 쉽게 받을 수 있는 명세서나 소스 코드에 적용되는 라이선스에 대해서는 FAQ 등에 기본 내용이 요약되어 있는 경우도 많다.
필자의 경우 이 분야에 있어 화려한 전적을 가지고 있는데 학창 시절이었던 1990년 후반에는 원고 적는 데 필요한 조언을 해 주고 내 의견을 업무적으로 반영해 주겠다고 이야기한 해외 기업에 근무하던 분의 이야기를 우쭐해서 원고에 인용했다가 그 분이 매우 난처한 일을 겪은 일도 있었다(아직도 얼굴이 화끈거린다). 사실 일차로는 필자의 잘못이었고 해당 매체도 경솔한 면이 있었다. 여하튼 알아야 할 것은 뭘 밖으로 내든 도의적으로나 법률적으로도 항상 정보의 원천을 신경을 써야 한다는 것이다.
또 예전 JSR 작업을 할 때는 전문가 그룹 내부에서 의견을 교환하다가(사실 그렇게 중요한 내용도 아니었는데 너무 구체적으로 몰입한 것 자체가 실수였다) 무심코 자바 AWT 소스 코드의 특정 코드 부분 다섯 줄 가량을 인용해 설명한 적이 있다. 그리고 즉각 JVM을 하는 해외 유명 회사 소속의 멤버에게 심한 항의 메일을 받았는데 이유인즉 짧아서 별 문제가 안 될지는 모르겠지만 JDK에 포함되어 있는 표준 자바 API 소스 코드는 참조 목적이고 자바 자체를 제품으로 하는 자신들이 보면 상황에 따라서는 법률적으로 문제가 될 수도 있다는 것이었다. 그 회사는 클린룸 구현을 하는 회사는 아니라서 별 문제는 되지 않는 것으로 알지만 그만큼 국제적인 사업을 하는 회사들은 회사 크기를 막론하고 법률적인 부분에 민감하다. 이는 오픈 소스 쪽도 예외는 아니다.
또 다른 일화는 저작권에 관련된 일인데 역시 JSR 작업을 할 때였다. 규격을 작성하면서 무심코 멤버 회사가 작성한 다른 JSR 규격의 앞 부분(몇 문장 정도)을 비슷하게 썼는데 다른 부분이 완전히 다름에도 불구하고 항의를 받아서 다른 멤버들, 특히 스펙 리드(spec lead)에게 미안했던 적이 있다. 즉시 문장을 다시 적었고 해당 항의는 스펙 리드들이 적절히 무마했다(여담이지만 정확히 어떻게 무마했는지는 스펙 리드들만 안다).
일단 기본 법칙은 개인적인 일이든 회사 일이든 회사의 자산인 정보에 대한 회사 정책을 명확히 알고 있어야 하고, 일단 내가 만들어낸 것이 아니면 공유할 때 신중을 기해야 한다. 특히 아무리 복잡한 절차나 지불 없이 다운로드가 가능하더라도 상업 회사가 공개한 정보에는 한번 더 주의를 기울일 필요가 있다. 특히 변호사의 천국인 미국과 일을 할 때는 비교적 이런 이슈에 익숙지 않은 우리 개발자 입장에서는 더욱 조심해야 한다.
소통의 기술은 어디서나 필요하다
흔히 영어 교육에 대해 이야기할 때 식견이 있는 사람이라면 일단 국어로 생각하고 말하고 쓰고 표현할 줄 알아야 영어로도 잘하는 것인데 이런 소통의 기본은 무시하고 영어만 강조하니 문제라고 하는 이야기를 많이 하는데 백 번 옳은 말씀이다. 국내든 국외든 가장 중요한 것은 결국 내 생각을 효과적으로 전달하는 것이다. 깨진 영어라도 잘 정리된 개념과 도면, 핵심을 전달하는 간결한 표현(세련된 표현이 아니다)이면 어디서나 효과를 발휘한다.
마치면서
마지막 글이랍시고 어줍잖게 몇 자 적어 봤다. 에피소드 위주로 적었으니 그나마 일천한 경험이라도 비교적 생생히, 재미있게 전달되었기를 바란다. 거듭 말하지만 국경이 허물어지는 것은 이제 불가항력이다. 그래서 그렇게 “영어, 영어”하는 거 아니던가? 조금만 생각을 달리하면 이력서에 영어 실력에 항상 찔리면서 (중)을 적어 넣는 개발자도, 늘 자료가 없고 생각을 나눌 사람이 부족한 개발자도 돌파구를 찾을 수 있을 것이다.
이 문서 북마킹 하기
 [지난 developerWorks Column 보기]
|
