예산 위원회 회원들에게

학부 프로그래밍 입문 교과의 함수형 언어 하스켈을 명령형 언어인 자바로 바꾸려고 한다는 소문 때문에, 그리고 예산 위원회가 잘못된 수준에서 이 결정이 내려지지 않도록 책임져야 한다고 생각해서 이 글을 씁니다.

여러분도 알다시피 이는 사소한 일이 아닙니다. 외지에서 온 동료들은, 엄격한 보수주의에서는 똑같이 평범해 질 것이 강요될 것이라고 가정하고서는, 내가 텍사스 오스틴 같은 곳에서 어떻게 버틸 수 있는지 궁금합니다. 이에 대해 나는 “걱정 마세요. 우리 컴퓨터 과학 학과는 매우 계몽된 곳입니다. 예를 들어, 프로그래밍 입문에 우리는 신입생들에게 하스켈을 가르칩니다”라는 식으로 답하곤 했습니다. 이 대답에 그들은 처음에는 거의 믿지 못하겠다는 반응을 하다가 결국엔 부러워합니다. 대게 그들의 학부 교과가 파스칼에서 C++나 자바 같은 것으로 전환하는 수준을 넘어서지 못하기 때문입니다.

아주 실용적인 이유를 들자면, 대부분 학생들이 어느 정도 명령형 프로그래밍에 친숙하기 때문에 1학년 교과에는 함수형 프로그래밍이 낫습니다. 학생들이 색다른 함수형 프로그래밍을 접하게 되면, 생각보다 프로그래밍에 더 많은 것이 있다는 메시지를 즉시 깨닫게 됩니다. 그리고 그들은 곧바로 고등학교 시절의 프로그래밍 수단으로는 매우 어렵거나 불가능한 해결책을 함수형 프로그래밍이 우아하게 수용한다는 사실을 목격하게 될 것입니다.

이렇게 선호하는 근본 이유는 함수형 프로그램이 명령형보다 수학적인 대상으로 훨씬 쉽게 인식되기 때문에 프로그램에 대한 엄격한 논증이 무엇인지 가르칠 수 있기 때문입니다. ‘지연 평가’로 인한 함수형 프로그래밍의 추가적인 장점은 운영 논증을 하지 않아도 되는 환경을 제공한다는 점입니다.

마지막으로, 하스켈과 자바를 구체적으로 비교했을 때, 하스켈이 완벽하지는 않지만, 엉망인 (그리고 상업적 확산을 위해 광범위한 광고 캠페인과 공격적인 영업 능력이 필요한) 자바보다 몇 등급이나 높은 품질입니다. 대체로 산업계가 형편 없다고 판명된 설계를 “사실상의” 표준으로 받아들이는 것은 나쁘다고 말하기에 충분합니다. 나는 대학이 더 건강한 대안들을 계속 유지해야 한다고 생각합니다.

바이올린이 바이올린 연주자를 만드는 것처럼, 우리 모두는 잘 다루려고 노력하는 그 도구에 의해 만들어집니다. 그리고 이런 점에서 우리의 사고 습관을 만드는 프로그래밍 언어들은 그릇된 영향을 미칩니다. 상황이 이러해서 첫 번째 프로그래밍 언어를 선택하는 일은 매우 중요합니다. 시작부터 배운 많은 것을 스스로 버리도록 강요받게 하기 보다는 컴퓨터 과학 교과 과정의 기초가 될 수 있는 문화를 만드는 수단으로 입문 프로그래밍 과정을 사용하고 싶습니다. 이런 선택이 우리 학부생에 대한 중대한 책임을 내포하고 있기 때문에 어떤 일에 대한 아무 책임자에게 맡길 수 없고 예산 위원회가 해야만 하는 것입니다. 이것은 공무원이나 직업 정치인에게 맡겨질 수 있는 것이 아닙니다. 지금 책임있는 정치가가 필요합니다.

대부분 개발자도 회사에 고용이 되어 일을 합니다. 하지만, 일반 노동자의 경우 고용자가 생산 수단을 제공하고 노동자는 단지 이 생산 수단을 운영하는데 필요한 노동력을 제공하는 것이 주인 것과 달리 소프트웨어 개발자(그리고 다른 지식 노동자)는 자신이 가진 지식과 지능으로 제품을 만들기 때문에 그 지위도 고용인과 대등한 관계에 있다고 볼 수 있습니다. 저는 이런 상황을 “소프트웨어 개발자는 생산 시설을 들고 일터에 걸어들어가고 퇴근할 때 들고 나오는 노동자”라고 말하곤 합니다.

작년에 우연히 마리사 데일(Mariesa Dale)이란 분의 기술자 히포크라테스 선서라는 글을 읽었습니다. 내용을 읽고 너무나 감동했고, 오랫동안 견지하던 제 뜻과 일치하여 이 선서에 동참하기로 했습니다.

동료들에게도 소개하고 싶어서 번역하려 했으나 계속 미루기만 하다가 최근에 조금씩 번역해서 이렇게 공개합니다. 오역이나 어색한 부분은 알려주시면 수정하겠습니다.

서문

기술자들은 오늘날 강력한 도구를 휘두른다. 우리는 한 번도 만난 적 없는 사람들에게 영향을 끼치는 설계를 하고, 우선순위를 정하고, 세상에 물건을 선보인다. 우리는 그들의 손목에, 랩탑 안에, 주머니 속에 있고 따라서 그들의 머릿속에 있다. 때로는 윤리가 흑백처럼 분명하지만 때로는 조금 더 복잡할 수도 있다.

난 운 좋게 최근에 인터랙션 18에서 진행된 앨런 쿠퍼의 강연을 들은 청중 중 하나였는데, 그는 강연장을 가득 메운 기술자들에게 다음과 같은 시나리오를 상상해 보라고 요청하면서 강연을 시작했다.

• 당신은 데이터 분석가로서 거의 완벽하게 타게팅되어 십억 달러 규모의 사업을 가능케 하는 광고 플랫폼을 구축하도록 돕는다. 하지만 외국 해커는 광고 플랫폼을 대통령 선거에 영향을 미치고 대의 민주주의를 해치는 데 사용한다.
• 당신은 세계 최고 수준이고 전 세계에 서비스될 기계 학습 철자 검사 알고리듬을 작성한다. 하지만 어느 날 이 알고리듬 때문에 몇 가지 처방 약 이름이 자동으로 다른 약 이름으로 수정했고 무고한 사람들이 피해를 당했다.

이런 예는 기술이나 제작자를 비난하려는 것이 목적이 아니다. 우리가 무엇을 만들 때 짊어질 책임을 설명하려는 것이 그 목적이다. 쿠퍼가 강연에서 말했듯, 우리는 단지 현재 기술의 구멍을 땜질하기만 할 뿐 아니라, 미래 기술이 이런 식으로 오남용되는 것을 막으면서 앞으로 나아간다.

선서의 배경

모든 사람이 각자의 방식으로 자신의 기준을 긋는다. 그리고 아마도 영향력 있는 제품을 구현할 때 무엇인 타당한지 따지는 범위는 다양할 것이다. 이것이 바로 의도된 사용이 사용자 경험의 현실과 항상 같지는 않다는 면에서 기술자들이 자신의 심리적 영향과 그 외 성과를 이해하기 위해 자신들이 구현하는 패턴에 대해 스스로 교육할 길을 찾아야 하는 이유이다. 그뿐 아니라, 우리는 무언가 선을 넘을 때 권위를 주장할 권리가 있음을 알아야 합니다.

엔지니어, 디자이너, 제품 관리자, 데이터 과학자 등으로 살면서 매일 휘두르는 엄청난 힘에도 불구하고, 우리 산업에서 윤리에 대한 교육과 감독은 너무 미약하다. 그리고 이런 자아 성찰의 순간을 갖는 사람은 나뿐 아니라, 아이폰 고안자에서 와이-컴비네이터(Y Combinator) 리더, 그리고 더 많은 사람이 모두 이를 느낍니다.

이 발견 과정에서 나는 윤리 표준을 자신들의 전문직에 통합하는 산업을 더 잘 이해하게 되었고, 의사의 히포크라테스 선서를 본뜬 기술자를 위한 선서를 만들게 되었다. 이것이 첫 기술직 종사자를 위한 서약은 아니며 마지막도 아닐 것이지만, 우리가 더는 우리의 책임과 우리 작업의 잠재적 영향에 대해 무지할 수 없다는 새로운 세계의 일부이다.

원래 이것은 개인적인 노력이었고, 특히 중요한 설계 작업 동안 나 자신에게 충실할 수 있는 표준으로 만들었다. 하지만, 내가 이것을 공유한 동료의 범위가 점차 넓어지면서, 그중 일부도 선서의 가치를 발견했다. 어쩌면 당신도 그럴 것이다.

기술자 선서

나는 내 능력과 판단력을 다하여 이 서약을 이행할 것을 맹세한다.

나는 개인으로든 집단으로든, 사용자가 숫자나 목표가 아니라, 사람이고 존중되어야 한다는 것을 기억할 것이다.

나는 선배 기술자들이 어렵게 얻은 전문적이고 창의적인 성취를 존중할 것이고, 내 지식을 다가올 세대와 기꺼이 공유할 것이다.

나는 최종 사용자의 이익과 가치에 내 능력을 활용할 것이고, 제품의 목표가 이것과 충돌할 때 변호할 것이다.

기술에는 과학뿐 아니라 예술이 있고, 내가 내리는 결정의 결과에 대한 공감, 공예, 신중함이 나의 기술적 지식의 중요성이나 금전적 이득을 향한 충동이나 지위의 유혹보다 중요하다는 것을 기억할 것이다.

나는 “모른다”고 말하는 것을 부끄러워하지 않을 것이며, 심도 있는 비평이나 다양한 사고에 다른 사람의 실력이 필요할 때 동료들에게 도움을 청할 것이다.

나는 기술과 건강한 관계를 유지하기 위해 사용자가 필요함을 존중할 것이다. 내가 해결하려는 모든 문제에 대해, 나는 내가 만든 해결책의 대상자들과 직접 접속하도록 노력할 것이다.

나는 삶의 균형과 조작 문제에 주의를 기울이고, 윤리적 딜레마나 도덕적 무모함이 일어날 때 참여를 중단해야 한다.

나는 내가 만든 기술에 영향을 받은 이들의 삶에 긍정적인 영향을 주도록 노력할 것이다. 그러나 나는 삶에 심각한 결과를 초래할 부정적인 영향력이 내 힘 안에 있다는 것도 인정한다. 이 엄청난 책임은 나 자신의 한계에 대한 강한 겸손과 자각에 직면해야 한다.

난 내가 단지 플랫폼, 애플리케이션, 웹 사이트를 만들기만 할 뿐 아니라 내 작업이 결국 인류에게 영향을 미친다는 점을 기억할 것이다. 내 창조물을 사용할 지위나 자격이 그들의 가족, 경제적 안정성, 정신 건강에 영향을 미칠 수 있다. 내가 진정 윤리적인 제품을 만들었다고 믿는다면 내 책임에는 직접적인 관련 결과가 모두 포함되어야 한다.

나는 가능한 한 사용자의 착취를 막겠다. 방지하는 것이 구출하는 것보다 낫기 때문이다.

나는 내가 사회의 일원으로서 모든 내 동료 인간, 그들 마음의 소리와 지체부자유와 중도장애를 포함한 몸 모두에 특별한 의무가 있음을 기억할 것이다.

무엇보다, 나는 내가 관문을 지키는 사람임을 안다. 권위에 복종하기보다 내가 만든 기술의 결과에 훨씬 더 관심을 둔다. 내가 이 선서를 어기지 않는다면, 나는 삶과 내 기술을 즐기며, 내가 사는 동안 존중받고 그 후에는 기억될 것이다. 내가 항상 내 소명의 가장 높은 기준을 유지하기 위해 행동하기를 바라고, 내가 세상에 내놓는데 일조하는 경험과 제품을 통해 직간접적으로 내 도움을 구하는 사람들을 돕는 기쁨을 내가 오랫동안 경험하기 바란다.

데이크스트라옹은 코드의 정확성(?)을 중요하게 생각하는 사람이었고 수학처럼 증명을 하면서 엄격하게 코드를 쌓아 올라가는 편을 선호했다. 그리고 그는 OOP란 아이디어를 별로 좋아하지 않았다. 반면에 OOP를 창안한 앨런 케이는 조금 더 실용적인 편이었고 데이크스트라가 지나치게 엄격하다고 비판하기도 했다.

암튼, 이 글은 유효할지 모르나 유용하진 않다.

글을 읽으며 들었던 세부 항목 하나하나에 대한 반론은 글 마지막에 덧붙여진 아샬님 트윗에 대부분 적혀 있다.

글쓴이는 글의 절반 정도를 “잘못된 OOP”를 공격하는데 할애한다. 어떤 개념을 반대하는 류의 글 대부분이 반대하려는 개념 자체보다 그 개념을 잘못 적용한 사례를 잔뜩 나열하며 해당 개념이 문제라고 공격한다. 이는 학자의 자세라기 보다는 정치인의 자세이다.

그럼에도 내가 유효하다고 한 이유는 사실상 OOP를 한답시고 저지르는 범죄들을 잘 나열했기 때문이다. 난 글에서 지적한 죄목들이 대부분이 유죄임을 인정한다. 그게 OOP을 오해했거나 OOP와 상관 없더라도 OOP의 이름으로 저질러지고 있다는 사실은 맞다.

횡단 관심사 같이 OOP에서 풀기 어려운 문제도 잘 지적했다.

이렇게 유효한 글이지만 유용하지 않다. 요즘은 이렇게 OOP를 까고나면 FP라도 내세우는 편인데 이 글을 대안을 딱히 얘기하지 않는다. 그런면에서 유용하지 않다.

무엇보다 OOP라는 것이 역사적 이유로 인해 명확한 정의가 없어 코에 걸면 코걸이, 귀에 걸면 귀고리인데 이걸 까 봐야 뭘 어쩔 것인가? 이 또한 이 글이 유용하지 않은 이유이다.

이 글은 로직보다 데이터가 중요하다는 선언으로 시작한다. 이 명제는 오랫동안 프로그래머 세계에서 공리처럼 받아들여졌다. 나도 데이터 구조가 중요하다는 생각에 동의한다. 하지만 거시적인 관점으로 올라가면 시스템은 서로 정해진 인터페이스로 협력하는 하부 시스템의 집합으로 그려질 수 있다. 데이터는 모듈 속으로 숨어서 보이지 않는다.

OOP의 캡슐화 관점에서 프로그래밍 언어는 크게 세가지로 나눌 수 있을 것 같다. 처음부터 데이터와 로직을 분리해서 다루는 방식과 모든 프로그램을 작은 컴퓨터로 분해해서 끝까지 데이터와 로직을 함께 묶는 방식과 이 둘의 어중간한 중간으로 어느정도까지는 데이터와 로직을 묶어서 다루지만 일정 수준 이상이 되면 분리하는 방식이다.

비 OOP 언어 대부분이 첫번째에 해당한다. 두번째는 소위 말하는 순수 OOP 언어로서 극소수이다. OOP에 대한 관점이 다양하다보니 어떤 이는 순수 OOP 언어는 스몰톡 뿐이라고 하기도 한다. 대부분의 OOP 언어는 세번째에 속한다. 여기에서 스칼라나 오캐멀(OCaml) 같이 OOP와 FP를 결합한 언어의 기회가 생기는 것이다.

글쓴이는 “제 의견을 말씀드리자면 클래스와 객체는 너무 나뉘어 있고, 제대로 ‘격리’ 나 ‘API’ 에 신경을 쓸 수 있는 지점은 ‘모듈’ / ‘컴포넌트’ / ‘라이브러리’ 의 경계라고 생각합니다”라고 말했는데 이 부분이 우리가 꼬인 실타래를 같이 풀기 시작해볼만한 실마리라고 생각한다. OOP를 난잡하게 전방위로 공격하던 이 분과 그래도 이야기를 시작해볼만한 접점이다. 세번째 부류 언어 관점의 OOP로서 말이다.

OOP는 좋은 코드를 작성하고자 하는 사람이 좋은 코드를 작성하는데 방법을 고민하면서 사용하면 도움이 되지만 남들이 OOP는 이러이러한 거라고 말하는 설명을 곧이곧대로 받아들여 기계적으로 따르면 자동으로 좋은 코드가 나오는 건 아니다.

세상에 그런 기술은 없다.

발표 내내 이벤트 소싱은 여러번 강조했고, 역시나  (요즘 인기있는) 마이크로서비스를 가지고 제한적 컨텍스트(Bounded Context) 약 파는 것도 잊지 않았습니다.

약 한 달 전에 회사 동료와 마이크로서비스와 제한적 컨텍스트를 두고 가볍게 토론을 했습니다. 동료의 팀에서 마이크로서비스 아키텍처로 애플리케이션을 만들었는데 잘 안 풀렸고 나중에 보니 제한적 컨텍스트를 적용하지 않았기 때문이라고 말했습니다. 하지만 저는 이 의견에 동의하지 않았습니다.

 에릭 에반스는 2003년에 DDD를 출간한 이후에 DDD도 변화와 발전을 했고 그 대표가 이벤트 소스이며 제한적 컨텍스트도 중요도가 바뀌었다고 합니다. 자신이 다시 책을 쓴다면 기존처럼 제한적 컨텍스트를 책 후반부에 두지 않고 보편적 언어와 함께 핵심 요소로 강조할 거라고 했었던 것으로 기억합니다. 그러면서 마이크로서비스 마다 제한적 컨텍스트를 두고 독립된 보편적 언어를 만들어야 한다고 주장합니다.

제가 제 동료의 생각에 반대한 이유는 제한적 컨텍스트가 중요하지 않다고 생각해서가 아니라 마이크로서비스의 크기 때문입니다.

제가 알기로 동료가 말한 애플리케이션 개발 프로젝트는 잘 해야 네댓 명이 단기간에 만든 소규모 서비스인데 그 안에서 만든 마이크로서비스의 크기라는 게 독립적인 보편적 언어(ubiquitous language)를 갖을 정도로 크다고 판단되지 않았습니다.

마이크로서비스와 관련한 논란 중 대표적인 것이 마이크로서비스는 얼마나 마이크로해야 하느냐, 즉 얼마나 작아야 마이크로서비스냐는 문제입니다.

어떤 사람은 마이크로서비스는 컴포넌트가 아니라고 말하면서 마이크로서비스는 생각보다 크다고 말합니다.

한편으로 마이크로서비스는 한 스크럼 팀이 한 스프린트에 개발할 정도의 규모여야 한다고 말하는 사람도 있습니다.

마이크로서비스 하나는 한 팀 정도가 담당하는 규모라는 의견도 있습니다.

에릭 에반스가 마이크로서비스 아키텍처의 유행을 틈타서 제한적 컨텍스트가 마이크로서비스의 문제를 해결해 줄거라고 약 팔고 다닌 건 작년에 인지했습니다. 닐 포드는 마이크로서비스 아키텍처가 DDD를 물리적인 아키텍처로 현실화 한 것이라고 말하면서 에릭 에반스를 응원합니다.에릭 에반스의 이 주장과 함께 인터넷에는 이에 동조하는 글이 많이 생겨났습니다. 하지만 저는 이 주장에 선뜻 동의하지 못합니다.

도메인 주도 설계에서 에릭 에반스는 대규모 조직에서 너무 큰 단위 모델을 일관되게 유지하는 것이 비현실적이라면서 독립적인 보편적 언어를 개발할 수 있도록 도메인 영역을 제한하도록 권합니다. 그러면서 제한적 컨텍스트라는 개념을 소개합니다. 그런데 책에서 이 때 말한 “너무 큰”의 규모는 기업 전체 규모입니다. 한 회사 전체가 단일 언어를 유지할 수 없다는 말입니다. 한 회사라는 기준도 회사의 크기가 천차 만별이라서 절대적인 기준은 아니겠지만 한 언어를 유지할 수 없을 정도로 충분히 큰 조직이라는 사실만은 분명합니다.

아무리 그 동안 제한적 컨텍스트를 적극적으로 활용하는 방향으로 DDD가 발전했다고 해도 소수의 인원이 단기간에 마이크로서비스 아키텍처로 개발했다는 애플리케이션의 마이크로서비스가 독립적인 보편적 언어를 갖는다는 건 지나친 적용이라고 생각합니다.

거꾸로 에릭 에반스의 주장을 적극 받아 들여서 마이크로서비스의 크기를 정하는 방식도 가능합니다. 어차피 마이크로서비스의 크기에 대해 합의가 안 되고 논란이 계속된다면 보편적 언어를 갖을 만큼 크고 독립적인 단위라는 기준을 사용하는 것도 나쁘지 않아 보입니다.

좋은 설계를 강조하는 전문가들은 너무 엄격한 기준을 제시하는 경향이 있습니다. 저는 아무리 에릭 에반스가 제한적 컨텍스트를 강조하더라도 지나치게 작은 제한적 컨텍스트를 설정함으로서 컨텍스트 매핑을 복잡하게 만들고 한 팀에서 여러 독립적인 언어(모델)를 사용하도록 해서는 안 된다고 생각합니다.

커뮤니케이션의 문제를 극복하는 게 DDD의 목적 중 하나인데 오히려 DDD 때문에 커뮤니케이션이 복잡해진다면 이는 DDD의 애초 목적에도 맞지 않습니다.

DDD 책을 보면 제한적 컨텍스트와 모듈의 차이에 대한 박스 글이 있습니다. “제한적 컨텍스트는 모듈이 아니라”라는 이 글에서 에릭 에반스는 제한적 컨텍스트 안에 여러 모듈을 둘 수 있다고 말합니다. 저는 이 모듈이 마이크로서비스로 보입니다.

재귀 호출도 저에게는 그와 같은 사례 중 하나 입니다. 어릴 때 이런 저런 프로그래밍 관련 지식을 배우면서 알게 되었고 자연스럽게 익혀서 쓰는 기법입니다. 어떤 문제는 재귀가 아니면 쉽게 푸는 방법을 전혀 모르기도 합니다.

시간이 된다면 이 문제를 하나 풀어 보십시오.

미국에는 1 센트, 5 센트, 10 센트, 25 센트 50 센트 등 다섯가지 동전이 있습니다. 이 동전을 무한정 확보할 수 있다고 하면 이들의 조합으로 어떤 금액도 만들 수 있습니다. 특정 금액 m이 주어졌을 때 이 다섯가지 동전을 조합해서 주어진 금액을 만들 수 있는 경우의 수는 몇가지가 있을까요?

꼭 완벽하기 풀지는 않더라도 몇 분 만이라도 어떻게 풀면 될지 생각해 보십시오.

이 문제는 “컴퓨터 프로그램의 구조와 해석”이라는 책의 1.2.2 장에서 “분기되는 재귀”를 설명하는 중에 예제로 나온 유명한 문제입니다. 저는 이 문제를 재귀가 아니면 잘 풀지 못합니다. 제가 재귀로 푼 코드는 다음과 같습니다.

public class ChangeCounter
{
    int cents[] = { 50, 25, 10, 5, 1 };

    public int count(int amount)
    {
        return count(amount, 0);
    }

    private int count(int amount, int idx)
    {
        if (amount == 0)
            return 1;
        else if (amount < 0 || idx >= cents.length)
            return 0;
        else
            return count(amount - cents[idx], idx) + count(amount, idx + 1);
    }
}

어떤 분은 저와는 달리 (스택을 사용한다거나 하는 방법으로) 재귀를 사용하지 않고도 문제를 풀 수 있겠지만 이렇게 단순하게 해결되지는 않을 겁니다. 제가 말하고 싶은 건 재귀는 어떤 문제의 경우 아주 효과적인 해결 방법입니다. 그리고 놀랍게도 별로 어렵지도 않습니다.

저는 최근에 자바 개발자 중에 재귀를 무척 어려운 고급 기법으로 알고 일부러 외면하거나 학습하면서 어려워하는 모습을 보면서 사실 좀 놀랐습니다. 그리고 왜 그러는지 궁금했습니다. 절대 재귀를 어려워하는 분들을 조롱하고 비난한다는 얘기가 아닙니다. 저는 정말 프로그래밍에 숙달된 분 조차 재귀를 어렵게 느끼도록 하는 요인이 뭔지 궁금했습니다. 더 나아가서 그 문제를 풀어 줄 방법도 알고 싶었습니다. 아직 완벽하게 범인을 알아 낸 것은 아니지만 몇몇 용의자를 찾았고 그 중 누가 범인인지 대략 느낌이 갑니다.

무혐의 용의자: 스택 오버 플로 공포증

자바 개발자들과 재귀를 이야기하는 자리에는 늘 스택 오버 플로를 우려하는 목소리가 들립니다. 사실 자바 뿐 아니라 C나 다른 명령형 언어를 사용하는 사람들 가운데에도 이 도시 괴담이 떠도는 것을 보면 역사가 깊은 전설 같습니다. 많은 분들이 프로그래밍에 입문하면서 존경하는 선배나 선임자에게 재귀를 사용하면 스택 오버 플로 오류가 발생해서 프로그램이 멈출 수 있으니 절대! 예외 없이! 언제나! 누구라도! 사용해서는 안된다고 배웠고 이를 금과옥조처럼 여기며 살았던 것입니다.

선배의 말처럼 재귀는 대부분의 언어에서 잘못하면 스택 오버 플로가 발생할 수 있는 위험한 기법입니다. 반복문이 잘못하면 무한 루프에 빠질 수 있는 위험한 기법인 것처럼 말입니다. 사실 프로그래밍을 잘못 작성하지 않는다면 재귀로 인해 스택 오버 플로가 일어나는 일은 흔치 않으며 스택 오버 플로가 발생할 수 있는 상황을 회피하는 방법도 있습니다. 특성을 이해하고 활용하면 도움이 되는 좋은 기법이며 무조건 회피할 이유가 없습니다.

이 공포증이 재귀를 멀리하게 만든 원흉인 것은 맞지만 정작 재귀를 익히면서 어렵다는 생각이 들게 만드는 요인은 아닐 것입니다. 저는 재귀가 어렵지 않다고 생각하고 권했는데 실제로 많은 자바 개발자들이 익히면서 어려워하는 것을 실제로 봤습니다.

첫째 용의자: 높은 난이도

가장 먼저 떠오르는 용의자는 재귀가 정말 이해하기 어려운 기술이라는 주장입니다. 재귀를 별다른 노력 없이 익힌 내가 초천재일지도 모릅니다. IQ 140이 넘는 사람들은 세상 모른 사람들이 자기처럼 머리가 똑똑한 줄 안다고 하더군요.

단언하건데 저는 머리가 그리 좋지 않습니다. 학창 시절에도 성적이 좋지 않았고 사회 생활을 하면서도 늘 제 지능이 평균 수준이라는 사실은 끊임 없이 확인했습니다. 대체로 복잡한 일을 좋아하는 프로그래머 사이에서는 오히려 평균 이하라고 생각됩니다. 따라서 제가 재귀를 별 어려움 없이, 그것도 막 프로그래밍을 배우던 고등학생 시절에 습득했는데 저보다 분명히 똑똑한 많은 사람들이 습득하는 데 곤란을 겪는 이유는 대단히 복잡한 어려운 개념이기 때문이 아닐 겁니다.

둘째 용의자: 분기가 일어나는 반복적 구조 경험 부족

우리가 흔히 경험하는 반복적 구조는 선형적인 반복입니다. 선형적인 반복 상황에서도 재귀를 사용할 수 있고 실제로 함수형 언어에서는 선형 반복에도 재귀를 사용하지만 자바 프로그래머들은 보통 이런 반복 구조는 for나 while 같은 반복문으로 처리합니다. 여러 반복문을 중복하는 2차원, 3차원 등 다차원 반복문도 결국은 선형 반복의 변형일 뿐입니다.

단순한 선형 반복이 아닌, 분기가 일어나는 반복적 상황, 예를 들어 트리 구조 탐색 같은 상황은 일반적인 애플리케이션 프로그래밍, 특히 DB 의존적인 애플리케이션의 개발에는 접할 일이 별로 없습니다. 그런데 이런 형태의 반복적 상황은 선형 반복으로는 해결할 수 없습니다. 반복문과 함께 분기 지점의 상태를 임시로 보관할 스택 같은 자료구조가 별도로 동원되어야 하는데요. 재귀호출을 사용하는 방식과 스택에 할일을 보관하면서 분기를 직접 처리하는 방식은 사실상 동일합니다. 시스템의 호출 스택을 사용할 것이냐 별도의 명시적인 스택을 사용하느냐의 차이 뿐입니다.

선형 반복에도 주로 재귀를 사용하는 함수형 프로그래밍 언어에서는 이미 재귀에 익숙하기 때문에 분기를 처리해야 하는 문제도 큰 어려움 없이 재귀로 해결합니다. 하지만 반복문으로 선형 반복을 처리하던 자바 개발자는 분기 상황에서 갑자기 처리 방법을 재귀로 바꾸거나 스택을 도입해야 하기 때문에 난이도가 갑자기 올라가는 것으로 느낄 것입니다. 그나마 스택을 사용한 번거로운 방법을 조금 더 쉽다고 느끼는 것 같습니다.

이 용의자는 제가 용의자 목록에서 제외 시켰던 첫번째 용의자와 공범일 가능성이 높습니다. 좀 처럼 경험하기 힘들고 복잡한 문제를 해결하는 기술이기 때문에 낯설 뿐 아니라 더 어렵다고 주장할 수 있습니다. 만약 이것이 범인이었다면 전 보다 똑똑한 사람이어야 합니다. 그런데 그다지 똑똑하지 않다고 이미 말씀드렸으므로 성급하게 범인으로 지목하지 않겠습니다.

다만 자바 개발자 입장에서 컬랙션 프레임워크(Collection Framework)가 반복문으로 처리하기 좋게 만들어져있기 때문에 함수형 프로그래밍 언어를 사용하는 사람들과 달리 재귀를 경험할 기회가 별로 없고, 재귀로 풀면 좋은 문제 상황을 드물게 만나면 갑자기 사고하는 방식을 바꿔야 하기 때문에 어렵다고 느낄 수는 있습니다.

셋째 용의자: 제어 흐름 추적 습관

자바는 명령형 프로그래밍 언어입니다. 객체지향 언어를 표방하지만 그 기저에는 명령형 패러다임이 깔려 있습니다. 따라서 우리는 자바로 프로그래밍을 할 때 컴퓨터에게 명령을 내린다고 생각하면서 그 명령의 순서와 분기와 반복을 추적하는 습관을 무의식 중에 훈련합니다.

예를 들어 팩토리얼을 구하는 코드를 작성해 보겠습니다. 팩토리얼은 특정 숫자 n이 주어졌을 때 1부터 n까지의 자연수를 모두 곱한 수이고 n!이라고 표기합니다. 이를 정의하면 다음과 같은 수식으로 표현할 수 있습니다.

1부터 n까지의 숫자를 모두 곱한 값이므로 이를 코드로 바꾸면 다음과 같이 반복문을 사용해서 계산할 수 있습니다.

int factorial(int n)
{
    int fact = 1;
    for(int c = 1; c <= n; c++)
        fact = fact * c;
    return fact;
}

이 코드를 작성하고 읽을 때 우리는 한줄 한줄 컴퓨터가 실행하는 과정을 단계별로 추적합니다. 결국 우리는 컴퓨터가 어떻게 팩토리얼을 계산하는지 알려준다는 느낌으로 코드를 작성합니다.

팩토리얼을 위와 다른 형태의 식으로 정의할 수 있습니다.

n이 0일 때는 1이고 0보다 클 때에는 (n-1)!와 n의 곱이라는 의미입니다. 이를 코드로 표현하면 다음과 같습니다.

int factorial(int n)
{
    if(n == 0) return 1;
    else return factorial(n-1) * n;
}

보시는 것처럼 위 식을 그대로 코드로 담았습니다. 이 코드는 어떻게 문제를 풀어야 하는지 명령을 내린다는 느낌 보다는 문제 정의 자체를 그대로 코드로 표현한다는 느낌으로 작성했습니다.

핵심은 이렇습니다. 우리가 프로그래밍을 하는 방법은 크게 두 가지입니다. 보통은 우리는 컴퓨터에게 명령을 내려서 문제를 풀게 제어한다는 생각으로 프로그래밍하도록 훈련 받았습니다. 그런데 고수준 언어에서는 이렇게 명령을 내리는 방식 말고 문제 정의를 코드로 표현한다는 느낌으로 코딩하는 방식도 있습니다. 이런 방식을 선언적 프로그래밍이라고 합니다.

결론

저는 확신하는데 재귀를 어렵게 느끼는 이유는 머리가 나빠서도 아니고, 좀 처럼 경험하기 힘든 특수한 상황에서만 필요한 고급 기법이기 때문도 아닙니다.

프로그램을 작성하면서 머리를 굴리는 방식이 다르기 때문입니다. 즉, 어려운 게 아니고 다른 겁니다. 다시 말해 어색한 것이지 난해한 게 아닙니다.

재귀 문제 몇 번 만 풀어보면 금방 감을 잡을 수 있습니다. 물론 명령형으로도 어려운 알고리듬을 만들려면 어려운 것처럼 재귀로도 어려운 알고리듬은 어렵습니다. 하지만 재귀가 어려운 건 아닙니다.

사실 재귀를 쉽게 이해하는 방법까지 이번 글에 담으려고 했는데 오늘은 우리가 재귀를 이해하는 데 어려움을 겪는 이유에 대해서만 적도록 하겠습니다.  다음 기회에 재귀를 설명해 보도록 하겠습니다.

힌트를 드리자면 재귀 코드를 보면 절대 흐름을 추적하려 마십시오. 오히려 문제를 정의한 식으로 보십시오. 그리고 어떤식으로 처리될지 머리에서 CPU를 모의 실험하지 마시고 그 정의가 무엇을 나타내는 정의인지 이해하려고 하십시오.

글을 읽으면서 이 비판(나쁜 의미가 아닌)에 일부 동의하면서도 제가 비판 대상의 일부임을 솔직히 인정하지 않을 수 없었습니다. 그래서 약간의 변명이 필요하다는 생각이 들었습니다. 사실 저는 이렇게 다른 사람의 주장을 논박하면서 토론하는 것을 좋아합니다. 이런 일을 단순히 즐기는 면도 있지만 이런 토론을 통해서 주제가 더욱 풍성하고 명확해진다고 생각하기 때문입니다.

먼저 코딩 시험에 대한 제 개인적인 의견은, 해당 코딩 문제를 풀어야만 통과하는 엄격한 시험이라면 전 낮은 수준의 문제를 내도록 해야 한다는 의견입니다. 높은 역량을 가진 기술자를 뽑기 위한 수단이라기보다는 기준 이하의 기술자를 걸러내기 위한 수단이란 뜻입니다.

범균님이 말한 알고리듬 수준의 코딩 시험이 어떤 것을 말하는지 불분명하지만 알고리듬 경진 대회에 나오는 어려운 문제를 꼭 풀어야 한다고 요청하거나 대학 시절에 공부하기는 했지만 일하면서 거의 접할 일이 없는 정렬이나 탐색 알고리듬을 풀어 보라는 식은 해당 직무가 그런 역량을 필요로하는 것이 아닌 이상 지나친 것일 수도 있습니다. 범균님께서 말씀하신 대로 일반 애플리케이션 개발자에게는 그런 알고리듬 능력보다는 모델링 능력과 데이터 가공 능력이 실제 업무에 더 필요하기 때문입니다.

하지만 어떤 코딩 시험은 꼭 풀어야만 통과한다는 기준보다는 특정 문제를 줬을 때 그 문제를 분석하고 해결해 나가는 과정을 관찰하면서 그 사람의 수준을 알아보려는 의도로 진행되는 경우도 많습니다. 질문이 모호할 때 다시 물어본다거나, 바로 세부 구현으로 넘어가지 않고 여러가지 개념적인 흐름을 탐색한다거나, 여러 가지 가설을 세우고 검증한다거나 하는 모습을 보면서 어떤 역량을 가진 사람인지 알아 보는 것이지요. 좋은 면접관이라면 적당히 도움도 주고 도전도 하면서 그 시간을 이끌 것입니다.

이런 차이는 대면 면접에서도 적용되는데 구현 기술이나 방법론이나 최신 기술 경향이나 과거 경험들에 대해서 여러 가지 질문들이 나올 수 있는데 이 모든 것에 하나라도 올바로 대답하지 못한다고 떨어뜨리는 회사는 아마 없을 것입니다. 완급을 조절하면서 어떤 수준의 사람인지 알아보려는 것일 뿐이죠.

예를 들어, (그리 중요하다고 생각하지 않지만) SOLID 원칙이나 몇몇 디자인 패턴에 대해서 질문할 경우가 있습니다. 요즘은 워낙 많은 사람이 SOLID에 대해서 알고 있어서 용어를 모르는 사람은 거의 없습니다. 대부분 다섯 가지 원칙이 무엇이고 어떤 뜻인지도 잘 얘기합니다. 하지만 교과서적인 정의를 줄줄이 읊는 사람과 한 번이라도 고민해 보고 자신의 말로 개념을 말하는 사람은 분명히 다릅니다. 제가 아는 몇 사람은 SOLID 중 몇가지 원칙 밖에 기억하지 못했지만 그 의미를 서투른 말로 떠듬떠듬 설명하는 과정에서 무의식중에 자신이 좋은 SW를 개발하는 데 고민하는 사람이라는 사실을 우리에게 알려 주었고 우리는 그분들에게 같이 일하자고 제안했었습니다. 물론 지금도 훌륭하게 기여하고 있습니다.

그럼 왜 이런 면접이 문제로 거론되는 걸까요?

몇몇 면접관들은 완장 효과 때문인지 권위적인 자세로 면접을 진행하면서 면접 대상자가 인격적으로 모욕을 느끼게 합니다. 마치 심문하듯 면접을 진행하면서 자신도 넘지 못할 수준을 요구합니다. 때로는 상대의 역량을 알아내려고 하기보다는 자신의 전문 분야에 편중된 질문을 하면서 공정하게 면접을 진행하지 않습니다. 면접이 아니라 면접관의 자기 자랑으로 흐르기도 합니다. 어떤 면접 대상자는 자신이 검증 대상이 된다는 사실 자체를 못 받아들이는 사람도 있는데, 권위적인 면접관과 이 자존감 낮은 면접자가 만나면 지옥이 펼쳐집니다. 불행한 일이지만 실제로 일어나는 상황이고 이런 안 좋은 경험이 면접이 지나치게 어렵다는 식으로 알려지는 경우가 있습니다.

개발자 면접은 일종의 협상입니다. 아무리 뛰어난 사람이라도 해당 시점에 필요한 적임자가 아닐 수도 있고 거꾸로 당장 일 할 수 없는 사람이라도 성장 가능성만 있으면 뽑을 수 있는 상황일 수도 있습니다. 면접 결과가 자신을 객관적으로 평가한 결과라고 생각하지 않는 게 좋습니다. 같은 사람과 다음번에 또 면접을 보게 되면 다른 결과가 나올 수도 있습니다. 당시 상황과 필요에 따라 평가의 기준은 달라지게 마련입니다. 면접 결과가 안 좋으면 그냥 상황이 안 맞았다고 생각하시는 것이 좋습니다.

면접은 객관적이지도 않지만 절대 평가도 아닌데, 어떤 때는 내가 부족하지만, 같이 면접을 봤던 사람들에 비해 상대적으로 낫다고 판단되어 채용이 될 수도 있고 어떤 때는 충분한 자격이 있지만 더 적합한 사람에 밀려 탈락할 수도 있습니다.

물론 이런 변명에도 불구하고, 면접이 지나치게 엄격하다는 소문은 도전하는 사람들의 의지를 꺾을 수 있어서 회사 입장에서는 면접에서 탈락하는 사람들이 면접 기준이 너무 높아서 탈락했다고 오해하지 않도록 사후 관리를 잘 할 필요가 있습니다. 실제로 그런 소문 때문에 구인에 어려움을 겪는 회사가 있기도 하고요.

몇몇 회사는 채용에서 탈락한 기록을 관리하면서 한번 떨어졌던 사람은 가능하면 면접 후보에서 제외하는 경우도 있는데 정말 바보 같은 짓입니다.

글이 생각보다 길어졌는데, 제가 하고 싶은 말은 하나뿐입니다. 도전했는데 떨어졌다면 자신을 다시 돌아보고 심기일전하는 계기로 삼는 것은 좋지만 절대로 포기하지 마시고 다시 도전하십시오. 절대적이지도 객관적이지도 않고 일관성도 없고 때로는 미친놈일 수도 있는 누군가의 평가에 너무 큰 의미를 부여할 필요는 없습니다.

사실 SW 개발자는 실력으로 공정하게 평가 받는 환경을 늘 추구합니다. 더 나아가 좋은 개발 실력이 사업의 성패에 큰 영향을 주는 사회를 간절히 원합니다. 그래서 기술을 무시한 의사 결정이나 기술자를 부품 취급하는 관행이 없어지고 기술이 세상을 더 나은 세상으로 만드는데 쓰일 수 있기를 바랍니다. 그런 관점에서 어떤 회사인가가 높은 수준의 개발자를 찾고 그들을 대우해준다는 소식이 들린다면 이는 좋은 소식이기도 합니다.

이는 IT​ 조직도 예외가 아니어서 대부분의 회사는 IT 조직이 사업에 밀착해서 최적화되어 일하도록 강하게 요청합니다. 사업의  목표를 이해함은 물론이고 사업의 요청에 충실해야 하며 비용 효율화를 달성해야 하고 사업과 방향성이 맞지 않는 일은 금기입니다. 심지어 중장기 R&D도 배부른 짓이고 비현실적인 일이라는 비난을 받기 일쑤입니다.

회사에서는 가볍고 빠르게 일을 처리해서 사업에 날개를 달아 주면서도 비용은 적게 먹고 불필요한 일은 하지 않는 IT 조직을 기대합니다. 하지만 대부분의 IT 조직은 무슨 일을 하는지 모르겠지만 생각보다 비용을 많이 먹어서 부담을 가중시키고, 느리고, 늘 문제를 일으키고, 알지 못할 변명만 늘어 놓는, 필요악 같은 존재입니다. IT 투자는 늘 밑 빠진 독에 불 붓기 같고, 실력이 없는 것인지 일 안하고 놀기만 하는 것인지, 의심의 골만 깊어 갑니다.

MIT 슬론 경영 리뷰지 2007 가을호에는 “IT의 사업 정렬 함정을 피하는 법(Avoiding the Alignment Trap in IT)”라는 제목의 논문이 실렸었습니다. 이 논문에서 “정렬 함정(Alignment Trap)”이라는 재미있는 개념을 소개합니다.

논문에 따르면, IT로 문제를 격는 회사들이 잘못된 지침에 따라 문제를 진단 합니다. IT를 활용해서 높은 사업 성과를 내려는 회사들은 IT가 사업에 정렬해서 일하도록 하는데 초점을 맞추었는데 저자들이 관찰한 많은 회사에서는 IT와 사업의 모든 요소가 긴밀하게 연계되어야 한다고 믿었습니다. 만약 이에 벗어날 경우 IT 조직은 부적절하거나 실패했다는 판정을 받게 됩니다.

일반적으로 이는 맞는 말이지만 저자들은 이상한 패턴을 발견했는데요. 여러 사례를 관찰한 결과, 사업에 정렬되었음에도 불구하고 IT와 관련된 사업적 성과가 지지부진하기도 하고 오히려 하락 하는 일도 있었다는 것입니다. IT부서가 사업에 정렬하더라도 사업 성과가 쉽게 좋아지지 않을 뿐 아니라 어떤 경우에는 나빠질 수 있다는 거죠.

저자들은 가장 먼저 IT 조직이 사업에 정렬하고자 자원을 어떻게 사용하는지 살펴 보았는데, IT 조직들은 개별 사업의 독특한 필요에 최적화된 최고의 솔루션을 개발했지만, 표준화나 오래된 시스템를 개선해야 할 필요는 무시했습니다. 기존의 복잡한 시스템에 새로운 복잡한 로직을 얹었기 때문에 시스템을 강화하거나 인프라를 개선하는 작업은 더 어려워진 것이죠. 이로 인해 비용은 증가하고 작업 지연이 심해지고 시스템이 파편화되는 바람에 관리자는 관련 사업 부서와 조율하기 힘들어졌습니다.

실랙티브 보험 그룹의 부사장이면서 CIO인 리차드 F 코넬가 “효율이 나쁜  IT 조직은 올바른 사업 목표에 정렬시켰더라도 목표를 달성할 수 없다”고 했다는데 이것이 바로 “정렬 함정”입니다.

저자들은 정렬 함정을 시험하기 위해서 452개 업체의 504 명 사업과 기술 담당 임원들에게 설문을 했습니다. 그리고 설문 결과를 가지고 30명의 CIO와 다른 부장급 리더들에게 깊이 있는 인터뷰를 수행했습니다.

설문에 따르면 단지 18% 만이 회사의 IT 지출이 사업의 우선순위에 정렬되었다고 믿는다며 응답했고, 15%만이 IT 효율이 높은 수준이라고 답했습니다. 그리고 거의 75%의 응답자가 그들의 IT 조직이 사업에 긴밀하게 정렬되거나 효율적이라고 생각하지 않는다는 것을 알 수 있었답니다.

다음은 그 설문의 결과를 정리한 도식입니다.

IT 조직이 사업에 긴밀하게 정렬하면서도 효율도 높은 회사는 “IT 기반의 성장”, 효율은 높지만 사업에 정렬하지 못한 회사는 “능률적인 IT”, 효율도 낮고 사업에도 별 도움을 못 주는 회사는 “유지보수 영역”이라고 이름을 붙였습니다. 그리고 효율이 떨어지면서도 사업에 긴밀하게 정렬된 회사를 “정렬 함정”으로 분류했습니다.

정렬 함정에 빠진 회사는 전체의 11%에 해당 했는데, 이 회사는 평균보다 13% 더 많이 IT에 돈을 쓰지만 회사는 3년 평균 매출이 15% 하락했습니다.

74%의 회사는 “유지보수 영역”에 해당하고, IT 지출이 평균 수준임에도 불구하고 매출은 살짝 하락한 평균 -2% 수준이었습니다.

나머지 두 영역은 결과가 무척 좋아서, 8%에 해당하는 “능률적 IT”에 해당하는 회사들은 효율적인 IT 프로젝트 운영에 초점을 맞추기 때문에 예산 안에서 프로젝트가 수행되고 평균보다 15% 적은 비용을 IT에 쓰지만 매출은 오히려 평균보다 11% 높은  성장을 했습니다.

효율도 뛰어나고 사업과도 긴밀하게 정렬해서 일하는 7%의 회사들은 지난 3년간 평균 매출이 35% 증가했고 비용은 평균보다 6%가 적었습니다.

이 설문 연구를 통해서 역량이 충분하지 않은 IT 조직을 가진 회사가 성급하게 사업에 밀착해서 프로젝트를 진행하도록 했을 때 IT가 오히려 회사의 실적에 악영향을 끼칠 수 있으며 사업과 분리되었을 때보다도 안 좋은 결과를 낸다는 사실을 알 수 있습니다. 즉, 어떤 회사가 IT 역량을 기반으로 경쟁 우위를 점하고 싶다고 하면, IT 부서가 사업에 밀착해서 일하도록 하기 보다는 먼저 역량을 강화하게 하고 나서 사업에 밀착해서 기여하도록 해야 한다는 교훈을 얻을 수 있습니다.

논문은 IT 조직이 비록 사업을 위해 밀착해서 일하지 않더라도 역량이 뛰어나다면 15%의 비용을 절감하고 회사 매출도 11%가 증가하는 것으로 나타났으므로 섣불리 사업에 최적화해서 일하게 하기 보다는 먼저 역량을 높이는데 투자하는 것을 주저할 필요가 없다고 지적합니다.

논문에서는 IT 조직을 효율화 할 세가지 방안을 제시합니다.

• 단순성 강조
  회사는 시스템을 복잡하지 않게 만들어야 합니다. 사업의 개별 요구사항을 빠르게 응급 처방으로 대응하다보면 시스템은 복잡해질 수 밖에 없는데, 사내 표준을 개발하고 정착시켜야 합니다. 이는 기존 시스템을 교체하거나 표준화된 인프라로 대체해야 하는 큰 작업이지만 초기 비용은 나중에 회수할 수 있습니다.
• “올바른 소싱(rightsourcing)” 능력
  IT 조직은 몇몇 전문 분야에 대해서 외부에서 역량을 조달하는 편이므로 올마른 소싱 능력을 키우지 않으면 안 됩니다. 가장 먼저는 어떤 일을 외부에서 소싱할지 올바른 결정을 할 수 있어야 합니다. 전략의 핵심이거나 회사 경쟁 차별화 요소인 경우는 내부에서 하면서 외부의 값싼 솔루션이나 역량을 적절히 활용할 수 있어야 합니다.
  무엇보다 효과적인 아웃소싱을 위해서는 해당 업무를 먼저 이해해야 하므로 내부에서 업무를 직접 수행하여 업무의 성격을 파악하고 나서 아웃소싱을 해야 합니다.
• 완결적 책임 구축
  IT 조직이 주어진 예산 안에서 기대하는 결과를 내도록 책임질 수 없다면 효율성은 실현될 수 없습니다. 단순히 책임이 있다고 말하는 수준에 머물러서는 안되고 조직 변화에 반영해야 합니다. 사업 단위로 IT 조직을 구성하지 말아야 하며 사업의 지나치에 휘둘리지 않도록 제약을 가해야 합니다.

우리나라 기업들은 대부분 영업 조직의 발언권이 강한 편입니다. 더구나 IT에 대한 이해가 매우 낮아서 사업을 보조하는 수단으로서만 활용될 뿐 회사의 성장을 견인하지는 못합니다. 이런 상황에서 저가의 초급 인력로 구성된 팀이나 외주 개발이라는 효율성 낮은 방식으로 사업에 밀착해서 일하고 사업의 요청을 거의 일방적으로 수용하도록 강요받고 있습니다. 그렇지 못한 기술 조직은 공격의 대상이 됩니다. 더 심각한 것은 많은 개발 조직의 구성원들이 이런 환경에 익숙해 있고 개발 조직을 관리하는 사람들이 이른 구조를 유지하는게 자기의 역할이라고 생각한다는 점입니다.

IT 기술이 회사의 사업에 중요한 기반이라고 생각하는데 성과가 안 좋은 회사에서는 이 “정렬 함정”에 빠지지는 않았는지 검토해 보아야 할 것입니다.

그러다 보니 새로운 금광이 발견되었다는 소식을 빨리 접하고 남들보다 먼저 깃발을 꼽는 것이 소프트웨어 개발자를 포함한 컴퓨터 관련 종사자의 중요한 생존 전략이 되어 버렸다. 심지어 어떤 (전직) 개발자는 직접 금은 캐지는 않고 금을 찾으려고 혈안이 된 개발자에게 새 금광 소식을 전하거나 금광 채굴단을 모집하거나 청바지를 파는 것을 생업으로 삼기도 한다.

골드 러시가 일어나고 새로운 기회를 찾는 거야 늘 즐거운 일이지만 이런 특성 때문에 무시되는 한가지는 소프트웨어 전문가 의식이다. 오히려 어떤 기술을 남들보다 먼저 사용하거나 더 잘 쓰는 사람을 ‘전문가’라고 부르는 실정이다. 스티브 맥코넬은 이에 대해 “골드 러시 이후, 진정한 소프트웨어 공학 전문직 창조(After the Gold Rush: Creating a True Profession of Software Engineering)”라는 책을 썼는데 아쉽게 번역이 된 것 같지는 않다.

내 머리 속에는 소프트웨어 개발의 전문성이란 주제로 두 사람이 떠오르는데, 이 스티브 맥코넬이 그 한 사람이고 요 몇년 사이에 엉클 밥(로버트 C 마틴)이 추가되었다. 스티브 맥코넬은 소프트웨어 전문가를 소프트웨어 공학자로 보았다. 아직 기예 수준에 머물러 있는 소프트웨어 개발을 공학적으로 접근해서 여러가지 소프트웨어 공학 지식을 활용하는 사람이다.

이 글은 내가 여러 다른 프로그래머와 자바에서 수상한 냄새가 나는 이유를 나누던 대화를 정리한 글이다. 이 글은 자바에 대한 비평이 아니다. 해커의 탐지 능력(hacker’s radar)에 대한 사례 연구이다.

오랜 시간 동안, 해커는 좋은 (또는 나쁜) 기술을 분별하는 코를 개발한다. 내가 자바를 수상적어 하도록 하는 이유를 찾아서 적어 보면 재미있겠다는 생각이 들었다.

이 글을 읽은 어떤 사람은 전에 작성된 적이 없는 어떤 것을 적어 보는 게 재미 있다고 생각한다. 다른 이들은 내가 이해 못하는 것에 대해서 쓰려는 듯 보여 곤경에 처할 거라고 말한다. 그래서,  만약의 안 좋은 상황을 대비해, 내가 여기에 (내가 한번도 써 본 적이 없는) 자바가 아닌 해커의 탐지 능력에 대해 쓰려는 걸 분명히 하고 싶다.

“겉 표지만 보고는 책에 대해 말할 수 없다”는 격언은 타임스지가 구매자 고유의 취향에 맞추기 위해 보드지로 된 무지 표지의 책을 팔았던 것에서 유래했다. 당시에는 표지를 가지고 책을 논할 수 없었다. 하지만 출판은 그날 이후로 발전했고 오늘날 출판업자들은 표지로 책을 논할 수 있을 정도로 잘 만들려고 힘쓴다.

서점에서 시간을 많이 보내다 보니 이제는 출판업자가 책에 대해서 말하려는 의미를 전부, 어쩌면 조금 더, 이해하는 방법을 익힌 것처럼 느껴진다. 서점에서 죽 때리지 않을 때에는 대부분 컴퓨터 앞에 앉아 있는데, 어느 정도 기술의 표지를 보고도 판단하는 법을 배운 것 같이 느껴진다. 그저 운일 뿐이겠지만, 진짜 저질로 판명난 몇몇 기술에서 날 지켜 주었다.

지금까지는, 자바가 그런 저질로 보인다. 나는 자바로 프로그램을 작성해 보지 않았고 참고 도서도 대충 훑어본 이상은 없지만, 언어로서 그다지 성공할 것 같아 보이지 않았다. 내 실수로 판명이 날지도 모른다. 기술을 전망하는 일은 위험한 사업이다. 아무튼 얼마나 가치 있는지는 모르겠으나, 일종의 타임 캡슐이랄까, 자바가 보기 안 좋았던 이유는 이렇다.

1. 매우 왕성히 과대 선전했다. 진정한 표준은 굳이 홍보할 필요가 없다. 아무도 C나 유닉스(Unix)나 HTML을 홍보하지 않았다. 진정한 표준은 시간이 흐름에 따라 대부분의 사람이 알게 된다고 인정되는 편이다. 매력의 강도로 봤을 때 해커의 탐지 화면에는 펄이 자바 만큼, 오히려 크게 보인다.

2. 목표 수준이 낮다. 첫번째 자바 백서에 의하면, 고슬링은 자바를 C를 사용하던 프로그래머에게 너무 어렵지 않도록 설계했다고 노골적으로 말한다. 자바는 또 다른 C++로 설계된 것이다. C++는 C에 다른 고급 언어에서 몇가지를 아이디어를 취한 언어이다. 시트콤이나 정크 푸드나 패키지 여행을 만드는 사람처럼, 자바를 설계한 사람은 의도적으로 자기들 보다 똑똑하지 않은 사람들을 위한 제품을 설계한 것이다. 역사상, 타인이 사용하도록 만든 언어는 안 좋았다. 코볼(Cobol), PL/1, 파스칼(Pascal), 에이다(Ada), C++ 가 그랬다. 좋은 언어는 창조자 자신을 위해 설계되었다. C, 펄(Perl), 스몰토크(Smalltalk), 리스프(Lisp)이다.

3. 동기가 엉뚱하다. 한번은 누군가 사람들이 책을 쓰고 싶어서가 아니고 뭔가 할 말이 있어서 책을 쓴다면 세상이 더 나은 곳이 될 것이라고 말했다. 이와 같이, 우리가 항상 들은 자바를 만든 이유는 프로그래밍 언어에 대해서 말하고 싶은 무엇 때문이 아니다.  자바가 썬(Sun)이 마이크로소프트의 토대를 약화시키려는 계획의 일부인 것으로 들었다.

4. 아무도 좋아하지 않는다. C, 펄(Perl), 파이썬(Python), 스몰토크(Smalltalk), 리스프(Lisp) 프로그래머는 자신이 사용하는 언어를 사랑한다. 난 한번도 자신이 사용하는 자바를 사랑한다는 말을 듣지 못했다.

5. 사용하도록 강요 받는다. 내가 아는 자바를 쓰는 많은 사람은 그래야 할 것 같아서 자바를 사용한다. 자금을 지원 받으려면 그래야 할 것 같아서나 고객이 원한다고 생각해서나 관리자에게서 뭔가 말을 들었기 때문이다.  그들은 똑똑한 사람이다. 기술이 좋았다면 그들은 자발적으로 그 기술을 사용했을 것이다.

6. 요리사가 지나치게 많다. 최고의 프로그래밍 언어는 지금까지 소그룹이 개발했다. 자바는 위원회가 운영하는 것 같다. 자바가 좋은 언어라고 밝혀진다면, 역사상 처음으로 위원회가 설계한 좋은 언어가 될것이다.

7. 관료적이다. 자바에 관한 내 짧은 지식에 따르면,  뭔가를 할 때의 따라야 할 규범이 매우 많다. 진짜 좋은 언어는 그렇지 않다. 좋은 언어는 하려고 하는 일을 할 수 있도록 하면서도 번잡한 일은 줄여준다.

8. 진보적인 것처럼 위장되었다. 썬은 자바가 펄이나 파이썬처럼 일반 대중의 오픈소스 언어 성과인 척 한다. 이것은 거대 기업에 의해 통제되도록 일어난 일일 뿐이다. 따라서 이 언어는 큰 기업에서 만들어진 모든 것이 그렇듯 밋밋하고 투박할 것이다.

9. 대규모 조직용으로 설계되었다. 큰  조직은 해커와 목적이 다르다.  큰 조직에서는 그저그런 프로그래머로 구성된 큰 팀이 사용하기에 적합한(적으도 그렇기 보이는) 언어를 원한다. 이런 언어는 이삿짐 센터 트럭에 있는 속도 제한기 같이 바보들이 큰 피해를 입힐 행위를 하지 못하게 하는 특징이 있다. 해커는 자신들을 펌하하는 언어를 좋아하지 않는다. 해커는 정말 힘을 원한다. 역사적으로, 큰 조직을 위해 설계된 (PL/I, 에이다 같은) 언어는 망한 반면, (C나 펄 같은) 해커 언어는 흥했다. 현재의 십대 해커는 미래의 CTO이기 때문이다.

10. 엉뚱한 사람이 좋아한다. 내가 인정하는 프로그래머 대부분은 대체로 자바에 끌리지 않는다.  자바를 좋아하는 사람은 누구일까? 정장을 입은 사람이다. 그들이 아는 언어는 다른 사람에게 추천 받은 것은 하나도 없고 언론에서 계속 들은 자바 뿐이다. 큰 회사에 소속된 프로그래머도 있다. 그들은 C++보다 더 좋은 뭔가를 찾느라 혈안이 되어 있다.  단순한 학부생도 그렇다. 그들은 직업을 구할 수 있는 것(면접 시험에 나올 것인가?)이라면 뭐든 좋아할 준비가 되어 있다.  이 사람들은 바람이 불 때마다 생각을 바꾼다.

11. 아버지가 위기에 몰렸다. 썬(Sun)의 사업 모델은 두 전선에서 토대가 허물어지고 있다. 데스크탑 기기에서 사용되는 것과 동일한 유형의 싸구러 인텔 프로세서는 이제 서버에서 쓰기에도 충분히 빠르다. FreeBSD는 적어도 솔라리스(Solaris) 만큼 서버용 OS로 적합해 보인다. 썬은 우리에게 고성능 애플리케이션에 썬의 서버가 필요한 것처럼 광고한다. 이것이 사실이라면, 야후는 썬을 사려고 앞장설 것이다. 하지만 내가 야후에 있었을 때, 서버는 모두 인텔 기기에 FreeBSD가 돌아갔다. 이는 썬의 미래에 좋지 않은 전조이다. 썬이 위기에 처한다면, 자바도 함께 위험해 질 수 있다.

12. 미 국방부가 좋아한다. 국방부는 개발자들에게 자바를 사용하도록 독려한다. 이 사실이 내게는 그 무엇보다 X 같은 신호로 보인다. 국방부는 국가를 방어하는 일은 (돈을 많이 쓰지만) 잘한다. 하지만, 그들은 계획과 절차와 규범을 사랑한다. 그들의 문화는 해커 문화와 반대된다. 소프트웨어에 관한 문제에서 그들은 틀린 답에 손을 드는 편이다. 지난 번에 국방부가 진짜 좋아했던 프로그래밍 언어는 에이다였다.

이 글이 자바를 비평한 글이 아님을 명심하자. 하지만 자바의 표지에 대한 비판이긴 하다. 자바를 좋아하거나 싫어할 만큼 자바를 잘 알지 못하다. 그저 내가 자바를 배우려는데 적극적이지 않은 이유를 설명한 글이다.

프로그램을 작성해 보지도 않고 한 언어를 무시하는 건 거만해 보일 수 있으나, 모든 프로그래머가 해야만 할 일이다. 세상에는 배워야 할 기술이 너무 많다. 밖에서 보이는 신호 만으로 평가하는 방법을 배워야만 시간을 아낄 수 있다. 나는 마찬가지로 여러가지 중에 코볼, 에이다, 비쥬얼 베이직, IBM AS400, VRML, ISO 900, SET 프로토콜, VMS, 노벨 네트웨어, 코바(CORBA)를 호기롭게 무시했었다. 정말 구린내가 났다.

자바의 경우엔 내가 틀릴 수도 있다. 자바는 한 대기업이 경쟁사를 해치려고 촉진했고, 주류 청중을 위해 위원회가 설계했으며,하늘에 닿을 정도로 과장 광고를 하고, 국방부의 사랑을 받았음에도 내가 프로그래밍하고 싶어하는 흠 없고 아름답고, 강력한 언어 일 수도 있다. 그럴 수도 있겠지만 매우 비관적이다.

케빈 켈러허(Kevin Kelleher)가 프로그래밍 언어를 비교하는 재미있는 방법을 제안했다. 각 언어가 해결하려는 문제를 적어 보자는 것이다. 이 방식으로 많은 언어가 정말 잘 설명되는 것을 보고 놀랐다.

파스칼(Pascal): 알골은 데이터 타입이 부족해.
Pascal: Algol doesn’t have enough data types.

모듈라(Modula): 파스칼은 시스템 프로그래밍에 너무 취약해.
Modula: Pascal is too wimpy for systems programming.

시뮬라(Simula): 알골은 시뮬레이션에 적합하지 않아.
Simula: Algol isn’t good enough at simulations.

스몰톡(Smalltalk): 시뮬라의 모든 것이 객체가 아니야.
Smalltalk: Not everything in Simula is an object.

포트란(Fortran): 어셈블리 언어는 너무 하부 수준이야.
Fortran: Assembly language is too low-level.

코볼(Cobol): 포트란은 무서워.
Cobol: Fortran is scary.

피엘원(PL/I): 포트란은 데이터 형이 부족해.
PL/I: Fortran doesn’t have enough data types.

에이다(Ada): 모든 언어는 뭔가가 빠져있어.
Ada: Every existing language is missing something.

베이직(Basic): 포트란은 무서워.
Basic: Fortran is scary.

에이피엘(APL): 포트란은 배열을 다루는데 적당치 않아.
APL: Fortran isn’t good enough at manipulating arrays.

제이(J): APL은 고유의 문자집합이 필요해.
J: APL requires its own character set.

씨(C): 어셈블리 언어는 너무 하부 수준이야.
C: Assembly language is too low-level.

씨뿔뿔(C++): C는 너무 하부 수준이야.
C++: C is too low-level.

자바(Java): C++는 너무 잡다해. 그리고, 마이크로소프트가 우리를 박살내려고 해.
Java: C++ is a kludge. And Microsoft is going to crush us.

씨샵(C#): 자바는 썬이 다 해먹으려고 해.
C#: Java is controlled by Sun.

리스프(Lisp): 투어링 머신은 계산을 서술하기에 난해해.
Lisp: Turing Machines are an awkward way to describe computation.

스킴(Scheme): 맥리스프(MacLisp)는 너무 잡다해.
Scheme: MacLisp is a kludge.

티(T): 스킴은 라이브러리가 없어.
T: Scheme has no libraries.

커먼 리스프(Common Lisp): 리스프는 방언이 너무 많아.
Common Lisp: There are too many dialects of Lisp.

딜런(Dylan): 스킴은 라이브러리가 없고 리스프 문법은 무서워.
Dylan: Scheme has no libraries, and Lisp syntax is scary.

펄(Perl): 쉘 스크립트/awk/seed는 프로그래밍 언어라고 하기엔 부족해.
Perl: Shell scripts/awk/sed are not enough like programming languages.

파이선(Python): 펄은 너무 잡다해.
Python: Perl is a kludge.

루비(Ruby): 펄은 너무 잡다하고 리스프 문법은 무서워.
Ruby: Perl is a kludge, and Lisp syntax is scary.

프롤로그(Prolog): 프로그래밍은 논리에 비해서 부족해.
Prolog: Programming is not enough like logic.