Eric ‘ESR’ Raymond의 JUG 강연에서 나온 프로그래밍 언어, 오픈 소스, 코딩 표준, 경력에 관한 통찰.
(이 글 아래에 YouTube에 있는 ESR 발표 전체 영상이 있습니다)
저는 Philadelphia Area Java Users’ Group의 회장을 12년째 맡고 있습니다. 예상하실 수 있듯이 일반적인 모임은 Java 관련 주제를 깊이 있게 다루는 슬라이드 자료를 갖춘 발표자를 중심으로 진행됩니다. 사례 연구, 도구 설명, 프로그래밍 효율성 향상을 위한 팁 등을 들을 수 있습니다. JUG는 제가 2000년에 그룹을 설립한 이래 이 방식을 따라왔고, 대부분의 모임에는 75~150명의 참석자가 모입니다.
지난달에는 완전히 다른 모임을 열었습니다. 저는 오픈 소스 소프트웨어 운동의 리더이자 The Cathedral and the Bazaar의 저자로 가장 잘 알려진 Eric Raymond(일명 ‘ESR’)에게 그룹에서 발표할 의향이 있는지 연락했습니다. ESR은 일반적으로 Java와 연관되지는 않지만, 그룹 구성원들이 잘 알려지고 존경받는 엔지니어가 한 주제에 대해 이야기하는 것을 들을 기회가 될 것이라고 생각했습니다. ESR은 메모나 슬라이드 없이 자유 형식으로 발표하고, 청중의 질문을 즉흥적인 발표 소재로 삼겠다고 제안했습니다. 약 150명의 엔지니어가 참석한 가운데 ESR은 함수형 언어부터 오픈 소스 라이선스, 코딩 표준에 이르기까지 상당히 폭넓은 질문에 답했습니다.
그렇다면 제가 왜 이 글을 JobTipsForGeeks에 올리는 걸까요? 채용 담당자로서 저는 엔지니어 인맥으로부터 경력 조언을 자주 요청받습니다. 제가 드리는 답변은 기술 자체의 실현 가능성보다는 여러 기술을 둘러싼 시장 동향(수요와 공급)과 ‘화제성’에 훨씬 더 기반합니다. 예를 들어, 저는 제 지역의 소프트웨어 회사들이 특정 언어를 채택하는 현황에 대해서는 충분히 이야기할 자격이 있지만, 기술적 관점에서 그러한 채택 선택의 장기적 실현 가능성을 논의할 자격은 훨씬 덜합니다.
ESR이 제가 자주 받는 질문 중 일부를 받았기에, 그의 답변과 통찰은 청중이 제가 개인들에게 제공하는 시장 기반 조언에 대한 ‘기술적 근거를 갖춘’ 반대 의견 또는 뒷받침하는 증거를 들을 기회라고 생각했습니다. 함수형 프로그래밍 언어와 채택률에 관계없이 이를 배울 가치에 관한 그의 구체적인 논평은 모든 수준의 엔지니어에게 통찰력 있는 조언이라고 생각했습니다. 또한 코딩 표준과 오픈 소스에 대해 경영진의 ‘동의’를 얻는 방법에 관한 그의 견해는 다른 곳만큼 기술 친화적이지 않을 수 있는 회사에서 헤쳐 나가기 위한 훌륭한 팁입니다. 이것들이 모두 구체적으로 ‘취업 팁’은 아니지만, 소프트웨어 경력에서 어떤 방향을 택할지 결정할 때 이러한 견해를 읽는 것은 분명 어느 정도 가치가 있다고 믿습니다.
아래 인용문은 주제별로 정리한 ESR의 질문 답변입니다.
PYTHON에 관하여
“네, 저는 Python을 정말 좋아합니다. 아주 구체적인 이유로 좋아합니다. 제가 사용해 본 모든 언어 중 Python은 장기 유지보수의 용이성을 가장 극대화하는 언어이기 때문에 좋아합니다. 다시 말해, 6개월 뒤에 자신의 코드를 읽을 수 있는 용이성입니다. 프로그래밍을 오래 할수록, 이것이 단연코 언어의 가장 중요한 척도라는 확신이 커집니다… 요즘 제가 하는 프로그래밍 대부분은 Python이나 C로 합니다.”
JAVA에 관하여
“저는 실제로 Java로 수백 줄 이상의 프로그램을 작성할 만큼 Java를 잘 배우지는 못했습니다. Java를 싫어하지는 않지만, 약간 지나치게 장황하고 다소 무거워졌다고 생각합니다. 그래서 제 첫 번째 선택은 아니지만, Java로 무언가를 작성해야 한다면 ‘으악’ 하지는 않을 겁니다.
C++에 관하여
“C++는 제가 Python에서 언급한 장점과 정확히 반대되는 문제가 있습니다. C++ 코드의 장기 유지보수성은 끔찍합니다.”
PERL에 관하여 (위의 C++ 답변에서 이어지는 답변)
“좋습니다. 이에 대해 제가 말할 수 있는 최선은 Perl만큼 나쁘지는 않다는 것입니다. 하지만 그것은 칭찬이라기보다 못마땅한 칭찬에 해당할까 봐 걱정됩니다. 저는 여전히 Perl을 괜찮게 여기고 가끔 사용하지만, 프로그램이 25줄을 넘지 않을 때에 한해서입니다.”
GOOGLE GO에 관하여
“저는 Google의 새 언어인 Go에 조심스럽게 발을 담그는 중입니다… 제가 정말 만족하는 동시성 관련 한 가지를 말씀드리겠습니다. 저는 1971년쯤부터 왜 아무도 Hoare의 통신 순차 프로세스 모델을 이어받아 발전시키지 않았는지 궁금했습니다. 매우 우아하고 아름다우며 추론하기 좋았는데, 40년 후 Go 사람들이 그것을 이어받아 발전시켰습니다. 그것이 제가 Go를 살펴보는 한 가지 이유입니다. CSP는 그 언어의 동시성 모델의 기반이며, 그것만으로도 더 살펴보고 싶을 만큼 충분한 동기가 됩니다.”
JVM이 더 범용화되는 것에 대한 생각
“저는 대체로 괜찮습니다. JVM은 워드 길이와 관련해 몇 가지 결함이 있고 수치 체계에는 심각한 문제들이 있다고 생각합니다… 정말 견고한 플랫폼이 되려면 약간의 작업이 필요합니다. 좋기는 하지만, 필요한 만큼 좋지는 않습니다.”
RUBY에 관하여
“Ruby를 조금 접해 보았습니다. 제가 작업하던 프로젝트에서 Ruby 코드를 일부 수정해야 했던 적이 있어서, 그 언어를 약간은 이해한다고 생각합니다. 아마 숙련자 수준은 아닐 겁니다. Ruby에 대한 제 인상은 Python과 거의 같은 장점과 같은 문제를 지녔다는 것입니다. 바꾸고 싶은 유혹이 들 수도 있지만, 충분히 다르지 않습니다. 물론 기능적으로 말하는 것이고, 미학적으로는 온갖 사소하고 이상한 차이가 있습니다. 하지만 Python에서 벗어날 만큼 충분히 다르지는 않다는 것이 제 인상입니다.”
SCALA에 관하여
“배울 언어 목록에 있습니다. 제가 신뢰하는 판단력을 가진 친구가 매우 좋은 설계라고 말했으며, 그것만으로도 제가 살펴볼 충분한 이유가 됩니다.”
오픈 소스 라이선싱/GPL에 관하여
“…이것은 제 의견 중 좀 더 논쟁적인 것 중 하나입니다. 저는 이제 GPL이 필요 없다고 생각합니다… 제 일반적인 태도는 허용적 라이선스를 사용하고, 바이러스성 조항은 그만두자는 것입니다…”
오픈 소스에 관하여
“회사 내부에 오픈 소스를 들여오는 관점에서 생각하고 있다면, 이미 실패한 것입니다. 통제와 안전장치의 부재, 훌륭한 코드 검토 외에는 안전장치가 없는 상태에서 번성하는 프로세스를 어떻게 통제하고 안전하게 만들지 고민하고 있기 때문에, 그것은 이미 잘못된 방향으로 생각하는 것입니다. 회사 내부에 오픈 소스를 어떻게 들여올지 생각하는 대신, 올바른 질문은 ‘우리 회사에 이익이 되는 오픈 소스 프로젝트를 어떻게 시작하고, 커뮤니티를 구축한 뒤, 그다음에 상사에게 이를 어떻게 팔 것인가?’입니다. 관료제를 다루는 철칙 중 하나는 _‘허락을 받는 것보다 용서를 구하는 편이 쉽다’_이기 때문입니다… 상사에게 흥미를 끌 만한 오픈 소스 프로젝트를 어떻게 시작하고, 실행 가능하게 만든 다음, 상사가 볼 수 있는 이점이 생긴 뒤 어떻게 그들에게 팔 것인가?…이점을 보여 주십시오. ‘눈에 보이는 물리적 성과 없이 n시간을 쓰도록 허락해 주시면 이 멋진 일을 할 수 있습니다’라고 말하지 마십시오. 관리자는 언제나 그런 말에 ‘안 된다’고 할 것입니다. 해야 할 일은 이점을 보여 주는 것입니다. 예를 들어, 비즈니스 문제 해결에 상당히 근접한 기존 오픈 소스 소프트웨어를 찾아 상사에게 ‘이것은 이미 작동하고 사용자 커뮤니티도 있으며, 어디에 배포되어 있는지도 보여 드릴 수 있습니다. 50시간만 주시면 우리 문제도 해결할 수 있는 것으로 바꾸겠습니다’라고 말하는 편이 훨씬 효과적입니다. 그 시점에서는 훨씬 더 나은 제안이 됩니다. 그것은 관리자가 익숙하게 생각하는 종류의 절충안이기 때문입니다.”
사내 개발 제품을 오픈 소스화하는 것에 관하여
“그럴 때 통하는 보편적인 주장은 ‘상사님, 유지보수 비용을 줄이고 싶지 않으신가요?’라고 말하는 것입니다. 다른 사람들이 작업을 맡게 해서 예산에서 비용이 나가지 않도록 하십시오. 그것이 사내 개발된 것을 오픈 소스화하는 이유입니다. 그 근거는 비용 분산과 위험 분산입니다. 그리고 정확히 그렇게 말해야 합니다. ‘보세요, 손익 비용을 줄이겠습니다.’”
코딩 표준의 장단점
“제 첫 번째 포괄적 관찰은, 언어 자체가 어느 정도 강제하는 일관된 스타일이 있어서 코딩 표준이 필요 없는 언어를 선택하는 것이 할 수 있는 가장 현명한 일이라는 것입니다. 네, Python을 염두에 두고 있습니다. Go도 이 특성이 있으며, Go에서는 들여쓰기 스타일의 변형을 갖기가 매우 어렵습니다… 다른 모든 조건이 같다면, 코딩 표준 전쟁이 절대 일어나지 않을 언어를 선택하는 것이 할 수 있는 가장 현명한 일입니다. 그것이 높은 효용을 지닌 이유는 당연히 코딩 표준의 목적이 코드의 가독성과 장기 유지보수성을 극대화하는 것이기 때문입니다. 그리고 네, 저는 그것이 매우 중요하다고 생각합니다… 특히 C로 작성한다면, 코딩 표준을 정하되 그것에 지나치게 집착하지 마십시오. 코딩 표준의 모든 사소한 항목 준수를 강제하는 데 드는 노력이 유지보수 비용 절감으로 얻는 가치보다 더 큰 고통과 간접비를 유발하는 지점이 옵니다.”
LISP/함수형 프로그래밍에 대한 생각
“그건 복잡한 이야기입니다. 이와 관련해 여러분이 저에 대해 가장 먼저 알아야 할 것은 제가 오래된 Lisp 애호가라는 점입니다… 저는 사실 APL로 처음 프로그래밍을 배웠습니다… 제가 처음 배운 두 언어의 결과로, 저는 프로그래밍 언어의 점착성에 대한 정신적 척도를 갖게 되었습니다. 프로그래밍 언어는 여러분의 뇌에 달라붙고, 더 점착성 높은 언어가 아니면 뇌에서 밀려나지 않는 정도에 따라 점착성을 가집니다. 저는 먼저 APL을 배웠고, 그다음 Lisp를 접했습니다… 제 첫 질문은 ‘실용적인 의미에서 어느 쪽이 더 강력한가?’였습니다. 네, 네, 둘 다 Turing 등가라는 것은 압니다… 그래서 저는 장난감 구현 두 개를 작성해 이 질문을 시험하기로 했습니다. Lisp로 만든 APL 인터프리터 하나와 APL로 만든 Lisp 인터프리터 하나였습니다… 그것이 제가 Lisp로 전환한 이유이고, Lisp가 APL보다 점착성이 높아서 제 뇌에서 APL을 밀어냈다는 것을 발견했습니다. 그 어떤 것도 제 뇌에서 Lisp를 밀어내지 못했습니다. Lisp보다 더 점착성 높은 언어는 만나지 못했습니다. 그렇다고 제가 Lisp를 아주 많이 사용한다는 뜻은 아니지만, 여전히 제가 프로그래밍에 관해 생각하는 방식을 지배한다는 뜻입니다.”
HASKELL에 관하여
“Haskell에 발을 조금 담가 보았고, 언젠가는 Haskell로 의미 있는 프로젝트를 해야 할 것입니다. 하지만 아직 그때는 아닙니다. 제가 이미 사용하는 도구들보다 더 나은 용도를 찾지 못했습니다. Haskell 같은 언어의 문제는… 저는 살아오면서 수십, 수십 개의 컴퓨터 언어를 익혔고, 예전에는 형식 및 기초 논리를 전문으로 하는 수학자였습니다. 이런 모든 이력이 있어도 Haskell은 제 뇌를 아프게 합니다. 따라서 Haskell과 다른 순수 함수형 프로그래밍 언어가 여러분의 뇌를 아프게 한다면, 괜찮습니다. 그리고 제가 그것들에 대해 걱정하는 점은, 제 뇌를 아프게 한다면 논리를 전문으로 하는 기초 논리학자였던 적이 없는 사람들에게 도대체 어떻게 자리 잡을 수 있겠느냐는 것입니다.”
함수형 언어에 관하여
“제 걱정은 이것들이 아름다운 도구이지만, 대부분의 프로그래머가 사용하기에는 너무 어렵기 때문에 실제로 대중적 수용을 달성하지 못할 것이라는 점입니다. 그렇다면 매력은 무엇일까요? 함수형 언어를 사용해 쉽게 다룰 수 있는 문제 유형에서는, 함수형 언어를 사용하면 숨이 멎을 만큼, 압도적으로 우아하고 아름다우며 간결한 해결책이 나옵니다. 도구가 문제에 맞을 때, 제대로 설계된 함수형 프로그램보다 더 아름다운 것은 우주에 거의 없습니다. 하지만 문제는 ‘A’ – 도구를 이해하기 어렵다는 점과, ‘B’ – 제가 _‘문제가 도구에 맞을 때’_라고 말했듯이 함수형 프로그래밍 언어 도구에 맞지 않는 문제가 많다는 점입니다. 함수형 프로그래밍 언어 도구는 모든 것이 무상태이고 모든 트랜잭션이 되돌릴 수 있는 우주에서 살기를 정말 원하기 때문입니다.이런. 입출력 작업처럼 지저분한 것을 다루는 순간 그런 가정에 문제가 생깁니다… 본질적으로 되돌릴 수 없기 때문입니다. 함수형 프로그래밍 언어의 많은 복잡성은 피할 수 없는 이 인터페이스, 즉 순수 논리, 무상태성, 되돌릴 수 있음, 무한한 역추적이라는 프로그래밍 언어 내부 세계와 실제로 상태를 가진 객체를 다뤄야 하는 지저분한 외부 세계 사이의 이 에너지 장벽에서 발생합니다… 이것들은 매력적인 도구이고, 일부 문제 유형에 유용하며, 저는 미학적으로 사랑합니다. 하지만 소수의 선호를 넘어설 수 있을지는 모르겠습니다.”
함수형 언어 학습에 관하여
“그럼에도 이 도구들이 결코 큰 호응을 얻지 못할 수 있더라도, 하나는 배워 보십시오. 어떤 함수형 언어든 충분히 깊이 들어가면, 저에게는 Lisp에서 그랬는데… 어느 시점에 Satori에 도달할 것이고, 함수형 프로그래밍이 실제로 어떻게 작동하는지에 대한 깨달음을 얻을 것이며, 여러분의 전체 우주는 옆으로 크게 기울어 다시는 완전히 같지 않을 것입니다. 그 후 함수형 프로그래밍 언어를 단 한 줄도 사용하지 않더라도, 그것은 여러분의 사고방식을 바꾸고 추상화를 형성하는 방식을 바꾸며, 많은 것을 정리해 줄 것입니다.”
JAVA와 PYTHON이 더 함수형으로 보이는 것에 관하여
“아이러니하게도 Python의 경우 Guido는 실제로 Lisp를 좋아하지 않으며, 개인적으로는 함수형 구문을 언어(Python)에서 빼고 싶어 합니다. 하지만 그가 그럴 때마다 저를 포함한 친구들과 선임 개발자들이 그를 보며 말합니다. ‘내 차가운 시체 손가락에서 억지로 빼내기 전에는 내 lambda를 빼앗지 못할 것이다’.”
PYTHON 대 JAVA
“Python이 Java보다 좋은 점은 더 가볍고, Python 프로그래머의 관점에서 이해를 방해하는 불필요한 잡동사니인 선언, 부칙, 여러 요소로 된 거대한 구문 덤불이 없다는 것입니다. 그런 면에서 훨씬 더 나쁜 언어들도 있습니다. C++에 대한 제 불평을 보십시오. Java는 최적의 장기 유지보수성을 위해서는 구문이 약간 너무 무겁고 복잡합니다. 어쨌든 그것이 제 의견입니다.”
오픈 소스
“이제 우리는 많은 사람이 오픈 소스 도구를 사용하고 즐길 수 있으며, 점점 더 많은 사람이 이를 작성하고 유지보수하면서 생계를 꾸릴 수 있는 상황에 살고 있습니다. 그것은 좋은 일입니다. 모든 소프트웨어가 비독점적이 되는 것을 보고 싶은가요? 그렇게 되더라도 특별히 신경 쓰이지는 않겠지만, 제 주요 목표는 아닙니다. 다른 사람들이 제가 원하는 방식으로 소프트웨어를 작성할 자유를 침해하려 하지 않는 한, 독점 소프트웨어를 작성하는 것은 저에게 해가 되지 않습니다. 제가 보호하고 싶은 자유는 그 자유입니다. 저는 자발적으로 오픈 소스 커뮤니티의 일부가 되기로 선택한 사람들이 계속 그 일부로 남을 수 있기를 바랍니다. 그 목표가 달성되는 한, 다른 사람들이 무엇을 하는지는 제게 그다지 중요한 관심사가 아닙니다.”
아래에 여러분의 의견을 남겨 주세요. 읽어 주셔서 감사합니다.
