Blog

Blog

기계번역, 자동번역기의 현주소

컴퓨터가 발전해 가면서 예전에는 상상도 하지 못했던 일들이 점차 실현 가능해지고 있다. 이제 언제 어디에서 든 사람들은 원하는 정보를 얻을 수 있다. 예전에는 신문이나 티비를 통해서만 접할 수 있는 기사들을 이제는 실시간으로 트위터(Twitter), 페이스북(Facebook) 또는 구글과 같은 검색 사이트를 통해서 바로 알 수 있게 되었다. 이제 우리는 국내뿐만 아니라 지구 반대편에 있는 나라의 사건들도 마찬로 관심을 가질 수 있다. 세계는 점점 더 좁아지고 있다. 하지만 아직 하나로 통합되지 못했다. 통합을 방해하는 요소는 정보 불균형, 무관심 등 여러 가지가 있지만 나는 가장 큰 문제는 언어 장벽이라고 생각한다.

기존에 우리는 언어 장벽이 허물어진 세상을 상상했었다. 조지 루카스(George Walton Lucas)의 영화 스타워즈(Star Wars)에 나오는 로봇 C3PO나 더글러스 애덤스(Douglas Adams)의 은하수를 여행하는 히치하이커를 위한 안내서(The Hitchhiker's Guide to the Galaxy)의 바벨 피쉬(Babel Fish)등이 모든 언어를 번역할 수 있는 능력의 가지고 등장했음을 기억하고 있을 것이다. 하지만 현실에서 이런 일은 아직 불가능하다. 과연 언제쯤 어떻게 언어의 세계가 하나로 통합될 수 있을까?

세상의 언어가 하나였던 시기가 있었다. 바로 고대 바벨탑(Tower of Babel)[1]이 있었던 시기이다. 바벨탑의 정확한 위치는 현재 알려지지 않지만 전승된 기록에 따르면 보시파(Borsippa, 'Tongue Tower”)에 바벨탑의 잔해가 있다는 기록도 있고 에트멘안키(Etemen-an-ki) 즉, 하늘과 땅의 기초가 되는 사원인 현재 유프라테스 강 오른쪽 강둑 근처 남쪽 도시에 위치한다는 기록도 있다. 현재 폐허가 된 이곳 들은 정확히 바벨탑이 어디였는지 알려주지는 않고 있지만 남아있는 기록들로써 바벨탑의 존재는 고고학을 기초로 함을 확신할 수 있다. 언제쯤 창세기(11:1)에 나와 있던 바벨탑 이전의 온 땅의 언어가 하나였던 시절로 돌아갈 수는 없을까? 과연 가능한 일일까?

컴퓨터 공학의 번역 시스템이야 말도 이것을 설명해 줄 수 있는 바로미터(Barometer)라고 생각한다. 하나의 언어로 세계를 통합해 줄 번역 시스템 발전의 현주소를 살펴봄으로 써 시기를 예상해보고자 한다.

자동번역 시스템은 많은 다른 뛰어난 기술들이 그렇듯 처음에는 미국과 러시아의 군사 정보를 수집할 목적으로 개발되었다. 하지만 1966년 ALPAC Report에서 "자동번역 기술은 결코 인간의 번역 능력을 따라잡을 수 없으며, 인간 번역가에 의해 결국 다시 재 작업이 되어야 하므로, 궁극적으로는 인간 번역가에 의해 번역하는 것이 이득이 된다." 라는 보고가 발표된 이후 자동번역의 발전은 침체하였다. 하지만 이후 1980년대 유럽과 일본에서 다시 개발이 시작되었고 도시바(Toshiba), 후지쓰(Fujitsu) 등과 같은 기업들을 중심으로 연구가 진행되었으며 현재 일본은 미국과 함께 세계 수준의 자동번역 기술을 보유하고 있다[2].

자동 번역(Machine Translation)은 크게 통계기반 자동 번역(Statistics-Based Approach)과 규칙기반 자동 번역(Rule-Based Approach)으로 나눌 수 있다. 통계기반 자동 번역은 통계적 분석을 통해 모델의 파라미터를 학습하고 그 모델에 근거하여 입력된 문장을 번역한다. 통계기반 자동 번역은 1949년 Warren Weaver[3]에 처음 소개되었고, 1991년 IBM의 Thomas J. Watson[4]에 의하여 연구가 진행되어 현재 가장 활발히 연구되고 있다. 통계기반 자동 번역은 각 언어의 번역된 결과 통계를 사용하므로 규칙 기반 자동 번역보다 개발 시간을 단축할 수는 있고 특정 언어에 국한되지 않는 시스템을 개발할 수 있다. 하지만 통계 데이터가 충분히 축적돼야 하고 이종 어족언어에 대해서는 규칙기반 자동 번역보다 번역률이 떨어지는 단점이 있다.

규칙기반 자동 번역은 직접 번역 방식(Direct Translation Approach), 간접 변환 방식(Indirect Transfer Approach), 중간 언어 방식(Interlingua Approach) 등으로 세분할 수 있다. 이는 분석 깊이에 기반을 두는 분류 방식이다. 직접 번역 방식은 형태소 분석 등 낮은 단계의 변환을 시작하여 번역하는 방식으로 언어학적으로 유사한 언어에 많이 사용되고 있다. 간접 변환 방식은 문법과 의미 구조를 분석한 후 번역한다. 이는 적은 수의 규칙만으로도 높은 성능을 낼 수 있기 때문에 국내 상용화되고 있는 대부분 번역 시스템이 이 방식을 채택하고 있다. 중간 언어 방식은 언어를 분석하여 언어 독립적인 새로운 언어에 대입하는 방법을 이용한다. 모든 언어가 중간 언어로 새롭게 번역되기 때문에 다국어 번역 시스템에 적합하다는 장점이 있다.

상용화된 프로그램은 대표적으로 SYSTRAN[5]과 구글 번역(Google Translate)[6]이 있다. 규칙기반 번역시스템인 SYSTRAN은 피터 토마(Peter Toma)[7]가 설립한 회사 이름이자 제품 이름이기도 하다. 야후(Yahoo!), 윈도우 라이브, AOL 그리고 예전에 알타비스타(AltaVista)의 바벨피쉬(Babel Fish)같은 서비스들이 이 번역 시스템을 기초로 하고 있다. 2007년에 출시한 구글 번역은 구글 자신이 직접 만든 알고리즘을 통해 통계기반 번역시스템을 사용한다. 실제 통계 데이터가 많이 축적되지 못한 한-영 상호 간 번역보다 한-일, 일-영 데이터가 많이 축적되어 있기 때문에 한-영 번역 품질을 높이기 위해서는 일문을 한번 거치는 것이 품질이 더 좋다고 말하기도 한다.

여러 언어가 속해있는 유럽연합은 이런 번역 시스템의 도입이 절실했다. 유럽연합의 공식 문서는 각기 다른 언어를 가지고 있는 자국의 언어로 다시 발행되고 있는데 이때 SYSTRAN의 번역을 1차로 사용하고 매끄럽지 않은 부분은 이후 사람이 교정해가고 있다. 우리나라와 일본도 출원되는 특허를 영어권의 사용자들이 검색할 수 있는 자동번역 시스템을 제공하고 있다.

자동 번역의 분류 및 현재 발전 상황을 살펴본 결과 완벽한 번역 시스템이 나오기는 더 많은 연구 결과가 필요해 보인다. 아직 완벽하지 않다고 해서 자동번역의 필요성이 없어진 것은 아니다. 최근 소프트웨어 개발 주기가 짧아지고 고객의 대상이 글로벌로 넓어지고 있기 때문에 소프트웨어의 다국어화에서 자동번역 기능을 도입한다면 빠른 개발에 도움이 될 수 있을 것이다. 번역에 높은 품질을 유지하고 위해서 소프트웨어 제품에서 많이 사용하는 단어 또는 문장들 등을 데이터베이스화하는 것도 필요하다. 정부에서는 소프트웨어를 육성하고자 실제 도움이 될지 의심스러운 대책들을 내놓기 보다는 글로벌화(Globalization)을 위해 번역 데이터를 주도적으로 구축해 주는 것이 더 실질적인 도움이 될 것으로 생각한다.


References

[1] (2003). Tower of Babel - Wikipedia, the free encyclopedia. Retrieved September 28, 2013, from http://en.wikipedia.org/wiki/Tower_of_Babel.
[2] (2005). 다국어 자동번역 기술 - ETRI 전자통신동향분석 - 한국전자통신연구원. Retrieved September 28, 2013, from http://ettrends.etri.re.kr/PDFData/20-5_016_027.pdf.
[3] (2004). Warren Weaver - Wikipedia, the free encyclopedia. Retrieved September 28, 2013, from http://en.wikipedia.org/wiki/Warren_Weaver.
[4] (2003). Thomas J. Watson - Wikipedia, the free encyclopedia. Retrieved September 28, 2013, from http://en.wikipedia.org/wiki/Thomas_J._Watson.
[5] SYSTRAN - Online translation, translation software and tools. Retrieved September 28, 2013, from http://www.systransoft.com/.
[6] Google Translate. Retrieved September 28, 2013, from http://translate.google.com/.
[7] (2005). Peter Toma - Wikipedia, the free encyclopedia. Retrieved September 28, 2013, from http://en.wikipedia.org/wiki/Peter_Toma.


진짜 문제는 무엇인가?

컴퓨터 프로그램은 사람이 풀고자 하는 문제를 해결하는 도구이다. 이메일(E-mail)은 정보 교환 및 커뮤니케이션의 문제를 해결 했으며 페이스북(Facebook)은 사람과의 관계에 대한 문제를 해결했다. 구글(Google)은 사람들이 정보를 신속하게 찾기 원하는 문제를 해결했기 때문에 현재 많은 사람들에 의해 사용하고 있다. 이처럼 문제를 해결하는 도구인 소프트웨어를 설계하는 프로그래머들은 문제의 핵심을 파악하고 효과적으로 해결할 수 있어야 한다. 하지만 문제의 핵심을 파악하기란 결코 쉬운 일이 아니며 제대로 해결하기란 더 어려운 일이다.

문제를 해결하기 위해서는 먼저 무엇이 문제 인지를 파악해야 한다[1]. 예를 들어 어느 날 당신의 상사가 모든 인터넷 데이터를 공인인증서[2]로 서명해야만 사용할 수 있도록 변경하라고 지시할지도 모른다. 샵메일(#mail)[3]등을 의무화하는 지금의 우리나라 현실처럼 말이다. 하지만 실제 문제는 안전한 통신을 하기 위함인지 다른 의도가 있는 것인지는 이 지시만을 통해서 알기 어렵다. 우리는 어떤 상황이 닥쳤을 때 진짜 문제가 무엇인지 파악하고자 노력해야 한다. 그리고 그 문제가 누구의 문제인지 문제의 핵심은 무엇인지 또한 파악해야 한다. 문제란 바라는 것과 인식의 차이에서 온다는 말이 있다. 허상의 문제가 진짜 문제일 수도 있는 것이다. 우리는 진짜 문제를 알기 위해서 계속 노력해야 한다.

상사가 제시한 공인인증 시스템을 모두 적용한다고 해서 그 문제는 해결되지 않을 수도 있다. 우리는 이 문제가 보안과 관련된 문제라고 인식하고 외국에서는 지금까지 공인인증서 없이 안전하게 인터넷 뱅킹 등을 사용하고 있다는 사례와 공인인증서를 의무화 한다면 다양한 운영체제에서 사용할 수 없다는 등 때문에 SSL(Secure Socket Layer)[4]만 적용하고 추가로 비교적 간단한 시스템 변경만 해도 충분히 안전하다고 설득하려 할지도 모른다. 하지만 어쩌면 이렇게 간단하게 문제를 해결할 수 있다면 상사는 문제가 해결됐다고 믿지 못할 수도 있다. 거짓말 같지만 정말로 그런 상사가 있다. 어떤 경우에 여러분은 일부러 어려운 일을 한 것처럼 오랜 시간을 끌어 작업을 완료하는 것이 오히려 도움이 된다. 하지만 아직 문제는 해결되지 않았다. 처음 SSL을 적용해야 한다는 느낌을 무시해서는 안 되지만 진짜 문제가 무엇인지 찾으려는 노력은 계속 필요하다.

계속된 설득과 토론 끝에 여러분은 상사 자신이 실제로 우려하는 부분은 보안의 기술적 문제보다는 보안 취약으로 자신의 이메일 등의 내용이 변조되어 본인이 피해 입기를 두려워하고 있기 때문이라는 사실을 발견할 수 있었을지도 모른다. 하지만 문제 해결의 어려운 점은 지금 이것이 여러분 본인의 문제로 생각하기보다는 제삼자의 문제로 생각하고 있다는 것이다. 이런 식으로는 문제를 제대로 해결하기 어렵다. 여러분은 이 문제가 본인의 문제이며 가까운 가족이 피해를 볼 수 있는 문제라고 생각하며 접근해야 문제의 본질에 집중된 해답을 얻을 수 있다. 즉, 당사자가 문제를 직접 느낄 수 있어야 하며, 변화를 위해서는 당사자 본인에게 책임을 지울 수 있어야 한다.

공부를 잘하는 학생들과 못하는 학생들의 차이점은 공부를 잘하는 학생들은 선생님의 의도를 더 잘 파악하고 있다는 것이다. 따라서 시험도 잘 보게 되는 것이다. 문제를 해결하는 것도 마찬가지이다. 나는 예전에 '의도를 파악하라'[5] 라는 글을 쓴 적이 있다. 이 글에서도 언급했지만, 문제의 근원은 대부분 숨겨져 있기 마련이고 잘 드러나지 않는다. 문제를 접한 여러분은 문제가 어디서 부터 비롯된 것인지 근원을 제대로 파악해야 한다.

다시 공인인증서 얘기로 넘어가서 여러분이 공인인증서를 사용하지 않아도 되는 확실한 해결 방법을 상사에게 제시한다고 할지라도 상사는 무조건 공인인증서를 적용하는 시스템으로 변경을 원할지도 모른다. 마치 문제를 해결하는 것은 관심도 없는 것처럼 말이다. 확실하지는 않지만 어쩌면 공인인증서 관련 협력 업체에게서 이미 커미션(Commission)을 챙겼는지도 모른다. 이처럼 문제를 정말로 풀고 싶지 않은 경우도 있다. 실제로 많은 경우가 그렇다.

문제를 파악하고 해결하기 위해서 여러분이 적극적으로 노력했음에도 불구하고 문제를 풀 수 없는 경우도 많은 것이라 예상한다. 또한, 어떤 경우에는 문제를 풀기 위해서 비도덕적인 일을 해야 할지도 모르고 정직하지 못한 방법을 사용할지도 모른다. 성경에 "그러므로 무엇이든지 남에게 대접을 받고자 하는 대로 너희도 남을 대접하라 이것이 율법이요 선지자니라"(마태복음 7:12)라는 구절이 있듯이 여러분이 앞으로 살아가면서 도덕적이고 정직한 대우를 받기를 원한다면 스스로부터 도덕적이고 정직해야 한다. 한번 정직하지 못한 이후에는 마치 물고기는 물을 보지 못하는 것처럼 자신이 지금 어떤 식으로 행동하고 있는지 알지 못할 수도 있다. 마지막으로 다시 한번 말한다. 자신에게 정직하라.


References

[1] (2013). 대체 뭐가 문제야? (신판) | 도서출판 인사이트. Retrieved September 22, 2013, from http://www.insightbook.co.kr/books/individual/%EB%8C%80%EC%B2%B4-%EB%AD%90%EA%B0%80-%EB%AC%B8%EC%A0%9C%EC%95%BC-%EC%8B%A0%ED%8C%90.
[2] (2007). 공인인증서 - 위키백과, 우리 모두의 백과사전. Retrieved September 22, 2013, from http://ko.wikipedia.org/wiki/%EA%B3%B5%EC%9D%B8%EC%9D%B8%EC%A6%9D%EC%84%9C.
[3] (2012). 샵메일 - 위키백과, 우리 모두의 백과사전. Retrieved September 22, 2013, from http://ko.wikipedia.org/wiki/%EC%83%B5%EB%A9%94%EC%9D%BC.
[4] Margaret Rouse (2011). What is Secure Sockets Layer (SSL)? - Definition from WhatIs.com. Retrieved September 22, 2013, from http://searchsecurity.techtarget.com/definition/Secure-Sockets-Layer-SSL.
[5] (2011). 라떼군 이야기 (Mr.Latte Story): 의도를 파악하라. Retrieved September 22, 2013, from http://www.mrlatte.net/2009/09/blog-post_4323.html.


프로그래머 죽이기

어떤 글이 사람들에게 주목을 받기 위해서는 제목이 중요하다. 하지만 너무 자극적인 제목을 사용하면 처음에는 사람들의 관심을 받을 수 있겠지만, 내용이 기대에 못 미친다면 아마 끝까지 읽게 하기는 힘들 것이다. 그렇다고 너무 뻔하고 무난한 제목을 선택한다면 관심조차 받지 못할 것이다. 이처럼 제목의 선정이란 참으로 고민되는 일이다. 짧은 블로그 게시물은 물론이고 많은 노력이 들어간 책의 긴 글의 경우는 더욱 그러하리라 생각한다.

최근 피플웨어(Peopleware)[1]라는 책을 읽었다. 나는 이 책을 읽는 내내 소프트웨어 분야에 종사하는 관리자라면 꼭 읽었으면 좋겠다는 생각이 들 정도로 이 책은 소프트웨어 분야의 명서로 꼽을만하다. 나는 이 책을 읽고 어떻게 하면 소프트웨어 개발자로서 일을 잘할 수 있는지에 대해 글을 써보기로 결심했다. 하지만 제목은 여전히 고민스러운 문제였다. 그런데 이 책의 한 단락에서 아이디어를 얻을 수 있었다. 피플웨어는 내용도 좋지만, 단락의 제목을 짓는 기술이 특히 인상적이다. 수학적 증명 방법에 비교하면 아마 귀납법[2]보다는 간접 증명법[3]에 가까울 것이다. 여기서 아이디어를 얻어서 본 글의 제목을 간접증명법의 "프로그래머 죽이기"로 하기로 결심했다.

Hangman game of Developer by Jong-Ha Ahn

내가 생각하는 프로그래머를 죽이는 방법은 3가지인데 다음과 같다. “짜장과 짬뽕 모두 좋아하는 관리자", “제임스 본드(James Bond)[4] 관리자", “스티븐 잡스(Steven Jobs)[5] 프로그래머"이다. 세 가지 항목 모두 비유를 통해서 의도하는 바를 더 효과적으로 설명하려고 한다.

프로그래머를 죽이는 방법의 첫 번째는 "짜장과 짬뽕 모두를 좋아하는 관리자"가 필요하다는 것이다. 이 관리자는 마치 중국집에서 짜장을 먹을까? 짬뽕을 먹을까? 고민하다가 결정하지 못하고 안절부절못하여 결정이 늦거나 짜장면을 시킨 후에 짬뽕을 먹을 걸 하면서 계속 후회하곤 한다. 실제 업무에서 의사 결정을 할 때도 마찬가지이다. 구글의 래리 페이지(Larry Page)[6]는 빠르고 좋은 결정은 있지만, 느리고 좋은 결정은 없다고 했다. 이런 유형의 관리자는 빠른 결정을 못 함은 물론이고 프로젝트 결정을 진행하고 있는 도중 프로젝트에 대한 성공 여부를 확신하지 못하여 그 프로젝트를 적극적으로 지원해 주지도, 프로젝트 팀원에게 비전도 제시하지도 못함으로써 결국 프로젝트와 참여한 프로그래머들을 망치게 된다.

다음으로 프로그래머를 죽이기 위해서 “제임스 본드 관리자"가 있어야 한다. 007[7] 영화에서 보듯이 제임스 본드는 비밀 작전을 수행하는 요원이다. 그에게 내려진 지령은 엄격한 비밀에 부쳐지고 몇 초 내에 파괴되기도 한다. 실제 프로젝트에서도 마치 자신이 007 요원이나 된 듯이 프로젝트에 대한 정보를 공유하지 않고 비밀로 하는 관리자가 있다. 때로는 어떤 정보는 프로젝트 팀원에게 좋지 않은 영향을 미치는 정보일 수 있다. 하지만 그렇다 하더라도 프로젝트에 관한 모든 정보는 공유돼야 한다. 프로젝트 팀원들은 공유된 정보를 바탕으로 때로는 의욕적으로 또 때로는 위기 상황을 같이 해결하는 단결력과 협동심의 팀워크를 발휘함으로써 프로젝트를 성공적으로 이끌 수 있기 때문이다.

마지막으로 “스티븐 잡스 프로그래머"가 프로젝트 팀에 존재해야 한다. 위 제시한 두 가지 사항은  관리자가 프로그래머를 죽이는 원인이었다면 이 항목은 프로그래머 자신의 문제이다. 스티븐 잡스 같은 프로그래머라니? 스티븐 잡스가 얼마나 성공적으로 애플(Apple)을 이끌었는지, 얼마나 혁신적인 사람이었는지 몰라서 하는 말이 아닐까? 라고 생각할지 모르겠다. 하지만 이것은 스티븐 잡스의 업적을 두고 하는 말은 아니다. 바로 그처럼 일 중독에 걸린 것처럼 일하는 프로그래머를 두고 하는 말이다. 스티븐 잡스는 업무 적으로는 큰 성공을 거뒀지만, 가정과 개인의 삶에는 상대적으로 소홀할 수밖에 없었을 것이다. 비슷한 내용을 다룬 영화 "클릭"[8][9]이 있으니 아직 못 보신 분들이 있다면 보기를 추천한다.

프로젝트 팀에 일 중독의 프로그래머가 많다면 프로젝트는 성공할 수 있을지는 몰라도 결국 프로젝트가 끝나면 프로그래머가 모두 떠나거나 떠나지 않더라도 정신적으로 큰 상처를 받은 상태가 지속될 것이다. 이에 따르는 비용을 계산하면 결국 프로젝트는 실패한 것으로 판단할 수 밖에 없다.

프로그래머는 창의적인 직업이다. 그들은 공학적으로 시스템을 만들고 있지만, 창의적인 아이디어도 역시 필요한 직업이다. 같은 맥락으로 심지어 최근 프로그래머들의 소양 중에 인문학도 포함되고 있지 않은가? 창의적인 아이디어는 매일 몰아치는 업무 속에서는 나올 수 없다. 창의력은 충분한 휴식에서 나온다는 벤자민 베어드(Benjamin Baird)의 연구 결과도 이미 알려진 바 있다. 우리는 구글(Google)의 지메일(Gmail), 파이썬(Python), 최근 깃헙(Github)의 수많은 프로젝트들이 프로그래머들의 잉여 시간으로 탄생하였고 운영되고 있다는 사실에 주목해야 한다. 프로그래머들은 과도하게 업무를 수행하기 보다는 조금 느슨하게 그리고 여유 시간에는 현재 프로젝트의 심도 있는 고민과 새로운 프로젝트를 위한 재창조의 시간으로 보내야 한다.

우리나라 뿐만 아니라 소프트웨어의 선진국이라고 생각되는 미국에서 조차 회사의 조직을 정비하고 프로그래머들이 속해있는 각 조직과 프로젝트를 성공적으로 이끄는 것은 쉽지 않은 문제라는 것을 책 "피플웨어"를 통해 알 수 있었다. 그리고 이 책이 미국의 현실을 바탕으로 쓰여 있긴 하지만 우리나라의 현재 소프트웨어 기업들의 현실과 전혀 다르지 않다는 것도 놀랄만한 일이다.

나는 미국의 프로그래머는 연봉이 10만 달러가 넘는다는 기사를 보고 부러워했던 적도 있다. 하지만 실상 막대한 세금과 기본 생활비를 제외하고 나면 실제 쓸 수 있는 것은 우리나라보다 적을 수도 있다는 사실은 상대적으로 열악한 환경에 있는 우리에게 매우 고무적인 사실로 들린다.

내가 1999년 대학에 처음 입학했을 때 10년 후인 2009쯤 되면 소프트웨어 개발자들이 더 이상 할 일이 없을 만큼 소프트웨어 개발이 자동화 될 것으로 생각했었다. 하지만 지금 현실은 어떠한가? 아직도 대부분의 소프트웨어 개발을 프로그래머가 직접하고 있다. 오히려 1999년 보다 지금이 플랫폼이 다양화되고 스마트 기기가 확산됨으로써 프로그래머가 해야 하는  일들이 오히려 더 많아졌다.

소프트웨어 개발은 사람이 직접 수행하고 그 과정에서 사람과의 관계가 중요할 것은 앞으로 영화 터미네이터(The Terminator)[10]에서 등장했던 스카이넷(skynet)[11]이나 메트릭스(The Matrix)[12]처럼 스스로 코드를 생성해 낼 수 있는 뛰어난 인공지능 컴퓨터가 나오기 전까지는 계속될 것이라고 생각한다. 그리고 지금의 인공지능 발전 속도를 감안하면 아마 내 일생 동안 앞으로 70년 이상은 계속되리라 예상해본다. 결국 앞으로 꽤 오랜 시간 동안 소프트웨어 개발에 있어서는 사람과의 관계는 매우 중요한 요소로 자리 잡고 있을 것이며 이를 어떻게 잘 해결하는 지가 소프트웨어 프로젝트의 성공을 결정할 것이다.

프로그래머를 죽일 수 있는 방법은 본 글에서 제시한 것 외에 훨씬 더 많이 있을 것이다. 우리는 이러한 프로그래머를 죽이는 상황에 처했을 때 이것을 인지할 수 있는 능력을 길러야 한다. 인지할 수 있는 것과 전혀 인지하지 못하는 것은 매우 다르기 때문이다. 인지할 경우 바꿀 수 있는 기회는 아직 남아있다는 뜻이다. 프로그래머들은 지금 또는 앞으로의 상황들을 인지하고 바꾸고자 노력해야 한다. 마지막으로 "피플웨어"에 있는 내용을 하나 인용하면서 글을 마치고자 한다. 이러한 상황에 처했을 때 "우리는 회사를 바꾸거나 우리가 회사를 바꾸거나 둘 중에 하나는 꼭 해야 한다."


References

[1] (2012). Peopleware: Productive Projects and Teams (Second Edition): Tom ... Retrieved September 7, 2013, from http://www.amazon.com/Peopleware-Productive-Projects-Second-Edition/dp/0932633439.
[2] (2007). 수학적 귀납법 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%88%98%ED%95%99%EC%A0%81_%EA%B7%80%EB%82%A9%EB%B2%95.
[3] (2009). 2장 증명. Retrieved September 7, 2013, from http://sungkyul.edu/~choiym/class/Fundamental_Mathematics_for_Multimedia/pdf/media_lecture2.pdf.
[4] (2006). 제임스 본드 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%A0%9C%EC%9E%84%EC%8A%A4_%EB%B3%B8%EB%93%9C.
[5] (2005). 스티브 잡스 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%8B%B0%EB%B8%8C_%EC%9E%A1%EC%8A%A4.
[6] (2007). 래리 페이지 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EB%9E%98%EB%A6%AC_%ED%8E%98%EC%9D%B4%EC%A7%80.
[7] The Official James Bond 007 Website | Home. Retrieved September 7, 2013, from http://www.007.com/.
[8] (2005). Click | Sony Pictures. Retrieved September 9, 2013, from http://www.sonypictures.com/movies/click/.
[9] (2011). 라떼군 이야기 (Mr.Latte Story): 영화 클릭(Click). Retrieved September 9, 2013, from http://www.mrlatte.net/2009/09/click.html.
[10] (2010). 터미네이터 (영화) - 위키백과, 우리 모두의 백과사전. Retrieved September 9, 2013, from http://ko.wikipedia.org/wiki/%ED%84%B0%EB%AF%B8%EB%84%A4%EC%9D%B4%ED%84%B0_(%EC%98%81%ED%99%94).
[11] (2006). 터미네이터 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%ED%84%B0%EB%AF%B8%EB%84%A4%EC%9D%B4%ED%84%B0.
[12] (2003). The Matrix - Wikipedia, the free encyclopedia. Retrieved September 7, 2013, from http://en.wikipedia.org/wiki/The_Matrix.




Subscribe to: Posts (Atom)