알 만한 사람은 다 아는 피터 드그라스(Peter DeGrace), 레슬레 휴렛 슈탈(Leslie Hulet Stahl)의 『Wicked Problems, Righteous Solutions』가 정태중, 신승환 님의 공동 번역으로 세상에 나오게 되었습니다. 원서의 발행년도가 1990년이니 딱 20년 된 책이 번역되어 나오는 셈입니다.

번역부터 발간까지 책으로 나오는 과정에서 참으로 많은 우여곡절을 겪었습니다. 하지만 나름 재미도 있었고 의미도 있었던 작업이었습니다. 지금의 컴퓨터 프로그래밍, 소프트웨어 공학이 있기까지 참으로 많은 노력과 고민이 선대에 있었구나, 라는 사실에 누구를 신뢰하게 되었을 때 다가오는 희열 같은 걸 느끼기도 했습니다.

폭포수 모델로는 항상 마주치는 고약한 문제를 해결하지 못한다

고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫습니다. 즉 문제가 완전히 풀려야 비로소 그 문제가 무엇인지 완전히 이해되는 그런 문제이지요. 반면 그 반대편에는 합당한 문제가 있습니다. 합당한 문제는 정의할 수 있고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제입니다.

이 고약한 문제는 비단 소프트웨어 개발 분야에서만 나오는 문제는 아니지만 유독 이 분야에서 그 위세가 당당해 해당 이해관계자들을 항상 괴롭히고 있습니다. 그 해결책을 내기 위해 참으로 많은 사람들이 노력을 해오고 있습니다. 독자 여러분께서 보시는 도서, 아티클, 논문 들 가운데, 많은 부분이 이런 문제를 해결하려는 고민의 산물이라고 봐도 그리 틀린 얘기는 아닐 겁니다.

그런데 소프트웨어 개발에 내재하는 이 난제는 각종 방법론이나 도구가 발전한 오늘날에도 좀처럼 완전히 해결되지 않고 있습니다. 여러 가지 이유가 있겠으나, 저자는 이런 것들이 주요한 이유라고 합니다.

각 이해관계자들 간의 심리적, 조직적 내용과 태생적으로 야기되는 불확실성의 문제입니다. 소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 중심이 컴퓨터나 시스템이 중심인 것처럼 보이지만 사실은 사람이 중심에 서 있다고 보는 겁니다. 그리고 불확실성의 문제는 해결책의 정형성을 갖는 데 필수인 객관적이고 명료한 기준을 세우기 어렵게 만듭니다. 그럼 고약한 문제의 성격을 함 보죠.

-고약한 문제는 ‘정형화’되어 있지 않다.

-고약한 문제를 푸는 해결책은 ‘옳으냐 틀리냐’가 아니라 ‘좋냐 나쁘냐’다.

-고약한 문제에는 ‘중단의 규칙’이 없다.

‘코딩부터 하고 보는(?)’ 시대에서 나타난 폭포수 모델의 구조적 방법은 그 자체로 혁신적이었습니다. 그러나 그 복잡성을 더해가는 현실에서 폭포수 모델은 이런 난제에 대해 해결책을 내놓기에는 택도 없어 보입니다. 비용과 시간이 많이 들고, 변화하는 요구사항에 민첩하게 대응하지 못하며 ‘어떻게’에서 ‘무엇’이 분리될 뿐만 아니라 이해관계자들 사이의 커뮤니케이션에도 틈이 발생하기 때문입니다.

역사는 또 다른 혁신을 필요로 하고 있습니다. 저자는 이에 여러 대안적 모델을 제시합니다. 이 지점에서 애자일 방법론의 기원이 되는 인식의 뿌리를 엿볼 수 있을 것입니다. 또한 어떠한 형태의 도그마도 거부하는 의식적 노력이 해결책을 내놓는 데 왜 중요한지도 아울러 살펴 볼 수 있습니다.

이 책이 주는 현재의 의미는 무엇일까요?

스티브 맥코넬도 ‘이 책이 가진 아이디어의 중요성’[주5]에 대해 언급했지만 20년 전에 이런 아이디어를 고민했고 그 결과물이 푸른 이끼에 물 스미듯 오늘날 많은 영역에서 회자되고 있다는 사실에 어떤 경외감 같은 걸 느끼게 됩니다.

이 책을 번역하신 정태중, 신승환 님도 그 부분에서 이 책의 유의미성을 찾으신 거 같습니다. 무척이나 상세한 역자 서문에서 많은 고민의 자욱을 들여다볼 수 있습니다. 아래에서 확인하실 수 있습니다. 번역하시느라 정말 수고 많으셨습니다. 꾸벅 OTL~

<역자서문>

정태중, 신승환

이 책을 처음 번역해 달라는 요청을 받았을 때, 참 난감했습니다. 이 글을 쓰는 시점으로 볼 때 이 책은 출판 된 지 20년이 넘었기 때문입니다. IT쪽 이야기는 1년만 지나도 옛 이야기가 되죠. 이런 IT쪽 시간을 놓고 보면, 이 책은 담배 피는 호랑이가 어릴 적 우유 마실 때 나온 셈입니다. 그리고 저를 더 당황스럽게 했던 건, 책에서 주로 언급하는 프로그래밍 언어가 코볼과 포트란이라는 점이었습니다. 저는 코볼이란 혹자가 불평하길 밀레니엄 사기에[주1] 등장한 언어라는 사실을 인지한 수준이었고, 포트란은 대학교 교양 과정에서 배운 포트란77이 제 경험의 전부였기 때문이었습니다.

포트란77을 처음 배울 때, 저는 이미 C를 사용해서 그럭저럭 프로그램을 만들 수 있는 수준이었기 때문에, 터미널 환경에서 실행되던 포트란77은 참 매력 없고 재미없는 언어였습니다. 포트란이 지루했다는 제 경험 탓이었는지, 이 책에서 포트란 이야기를 할 때면 할머니가 즐겨 듣는 AM방송만 나오는 라디오처럼 구식으로 느껴졌습니다.

하지만 번역을 하려고 통독하고 나서, 이 책을 성급하게 과소평가했다는 생각이 들었습니다. 어느 분야에나 고전이라는 게 있습니다. 시대를 뛰어넘는 보편성을 가졌다고 평가받는 것들이 아마도 고전의 반열에 속하는 듯합니다. 하지만 책이든 음악이든 그림이든 영화든, 고전은 그것이 만들어진 시대를 일정하게 반영하기 때문에, 후대 사람이 볼 때 표현이 거칠거나 최신의 것과 맞지 않는다고 느낄 수 있습니다. 그럼에도 고전이 시대의 풍파를 이기고도 평가를 받는 것은, 고전이 주는 가치가 유효하고 심리적 혹은 지적 자극을 주기 때문입니다.

고전을 이렇게 정의한다면, 이 책은 아마도 IT 고전으로 분류될 수 있습니다. IBM 호환 PC와 맥의 초창기인, 아주 오래 전에 나온 책이지만, 핸드폰으로 지구 반대편 재난 상황을 실시간으로 확인하고 도움의 손길을 내밀 수 있는 지금 시점에도 충분한 가치를 주기 때문이죠. 그렇다면, 20년이 지난 지금에서 이 책이 주는 가치는 무엇일까요?

이 책이 출판되고 나서 우리 분야에서 어떤 일들이 있는지 간단하게 살펴보겠습니다. 이 책은 폭포수 모델의 문제점을 파헤치면서, 주로 구조적 분석과 설계(Structured Analysis and Design)를 이야기합니다. 구조적 분석과 설계는 코딩부터 시작하는 방법을 대체하는 훌륭한 방법이었습니다. 구조적 분석과 설계가 우리가 일하는 방식을 지배할 때, 이 책에서 아직 성숙하지 않은 기술이라고 말한 객체 지향 분석과 설계(Object oriented Analysis and Design) 방법이 등장했습니다.

객체 지향 분석과 설계가 구조적 분석과 설계의 아성에 도전해서 오늘날 개발 방법의 핵심이 된 것은, 소프트웨어의 다양한 특성을 모델링할 수 있는 UML의 탄생과 발전, 객체 지향 언어의 대표주자인 자바의 대 히트 덕분이었죠. ‘객체 지향 분석과 설계 방법’ ‘UML’ ‘객체 지향 언어’의 3각 편대는 구조적 분석과 설계 세력이 진을 치고 있는 소프트웨어 영토의 많은 지역을 점령했습니다.

객체 지향 패러다임이 그 세력을 넓힐 무렵, GoF로 표현되는 4인방이 디자인 패턴이라는 것을 들고 나옴으로써, 우리 분야의 오랜 숙제인 ‘무엇을(What)’과 ‘어떻게(How)’의 간극을 메우는 방법을 제시했습니다. 물론 디자인 패턴으로만 요구사항과 설계의 간극을 완벽하게 메울 수는 없지만, 현재 다양한 분야에 알맞은 아키텍처가 만들어지고 쓰인다는 데에서도 ‘무엇’과 ‘어떻게’의 간극을 메울 희망을 찾을 수 있었습니다.

아울러 우리는 ‘소프트웨어 프로덕트 라인(Software Product Line)’을 사용해서 ‘넘지 못하는 4차원 벽’ 너머에 있는 영업, 마케팅, 고객들의 이야기들을 체계적으로 정리하고 아키텍처로 현실화하려고 애쓰고 있습니다. 또한 우리가 일하는 방식을 개선하려고 소프트웨어 개발 조직이 오랜 기간 축적한 데이터를 기반으로 만든 CMMI류의 프로세스 개선 모델은, 대규모로 소프트웨어를 개발하는 조직의 개발 수준이 어느 정도인지 객관적으로 평가하고 개선하는 방법을 알려주는 경지에 이르렀습니다.

개발자가 코드를 짜면서 버그도 만든다는 것은 잘 알려진 사실입니다. 제대로 된 것을 만든다는 확신을 가지려면 검증 작업이 필수입니다. 하지만 개발이라는 용어에 매우 친숙한 개발자들에게 테스트는 이웃 마을 김 서방 얘기였던 때가 있었습니다. 개발자들의 관심 영역 밖에 있던 테스트가 지금은 테스트 주도 개발(Test Driven Development)이라는 방법 덕분에 테스트에 대한 개발자들의 인식이 새로워지기 시작했습니다. 그리고 테스트 자동화 도구, 정적 분석 도구, 동적 분석 도구 등의 발전은 제대로 된 소프트웨어를 만들 가능성을 키웠습니다.

이 책이 출판된 이후에, 소프트웨어 개발과 관련된 발전은 괄목할만합니다. 그렇다면 이 책에서 언급한 고약한 문제는 어떻게 됐을까요? 이런 발전 덕분에, 고약한 문제는 우리 분야에서 완전히 사라졌을까요? 자신 있게 그렇다!, 하고 대답할 수 있다면 좋겠지만, 아쉽게도 현실은 그렇지 못합니다. 고약한 문제는 사라지지 않은 채 우리 주의를 맴돌고 있습니다.

프로젝트마다 혹은 일을 할 때마다 우리를 괴롭히는 것은, 고약한 문제의 근원적인 특징 즉 우리가 만들거나 다루는 것이 눈에 보이지 않는다는 점 때문입니다. 하지만 이 책에서 고약한 문제를 해결하는 적절한 해결책으로 소개했던 스크럼은, 이제 우리가 일하는 세계에서 주류 방법으로 자리를 잡고 있습니다. 스크럼 같은 반복적이고 점진적인 개발방법 덕분에, 우리는 작동하는 소프트웨어를 프로젝트 동안 만들고 사용해 볼 수 있고, 따라서 제대로 나아가고 있는지 알게 되었습니다.

또한 고약한 문제의 특징 가운데 하나였던 설계문서와 코드가 일치하지 않는 문제는, MBD(Model Based Design)나 MDD(Model Driven Development)를 사용해서 어느 정도 해결의 실마리를 찾게 되었습니다. 물론 기술들은 여전히 개선할 부분이 많지만, 우리에게 희망을 줍니다.

소프트웨어 공학의 기반을 이루는 과학이 무엇인지 아직도 논란의 여지가 많고, 우리가 설계 원칙으로 삼는 응집성, 결합성, 단일 책임의 원칙, 의존관계 역전의 원칙, 인터페이스 분리의 원칙, 리스코프 대체의 원칙, 개방 폐쇄 원칙을 이루는 근간을 명확하게 설명할 수 없는 없습니다. [주2] 하지만 고약한 문제를 해결하고 일하는 방법을 개선하려는 노력해온 덕분에, 우리는 SWEBOK[주3], 즉 거대한 소프트웨어 엔지니어링 지식 체계를 수립하는 수준에도 도달했습니다.

자, 이 정도 수준이면 우리를 괴롭히는 고약한 문제를 완벽하게 해결하지 못했기 때문에 개운하지 않아도, 그 동안 확실히 많이 발전했다고 우리 자신에게 칭찬의 말을 건네도 괜찮을 듯합니다. 하지만 전 세계적인 소프트웨어 공학 수준은 둘째로 치더라도, 잊을만하면 들려오는 대한민국에 소프트웨어 공학 수준은 형편없다는 이야기[주4]나, 대한민국 소프트웨어의 미래가 없다는 자조 섞인 탄성은, 소박한 자아도취에 빠진 우리 자신을 머쓱하게 하기도 합니다.

이 책이 출간된 후 이룬 위대한 성과에도 불구하고, 우리는 ‘제대로 좀 못해?’ 하는 세상 사람들의 부당한 평가나, 스스로 ‘우리는 왜 이렇게 형편없지?’ 라고 온당하지 않은 평가를 자신에게 하는 이유는 무엇일까요? 우리의 현재 상황을 말하기 전에, 일반적인 공학에서 일어나는 일을 살펴보겠습니다.

잊을만하면 ‘9시 뉴스’나 ‘신문의 사회면’을 장식하는 기사가 있습니다. 바로 ‘무한동력을 만들어내는 기계’를 이용해서 사기를 쳤다는 기사입니다. 물론 사기성 이벤트가 아니더라도 가끔씩 ‘세상에 이런 일이’라는 TV 프로그램에, 무한동력 기계를 만들려는 아마추어 발명가들의 열정적인 모습이 나올 때가 있습니다. 무한동력 기계란, 작동하는 데 필요한 에너지를 공급하지 않아도 영원히 일을 하는 기계입니다. 한 문장으로 무한동력 기계를 설명하니, 일견 가능할 것도 같기도 합니다. 무한동력 기계를 발명한다면 인류는 지구온난화나 자원 고갈이라는 무시무시한 전 인류적 재앙에서 벗어날 수 있을 것입니다. 상당히 매력적인 기계임에 틀림없습니다.

그런데 이런 무한동력 기계는, 기계공학 교과과정 중에 하나인 열역학을 배운 사람들에게 말도 안 되는 헛소리입니다. 열역학 제2법칙에 따르면 모든 반응은 엔트로피가 증가하는 방향으로 일어납니다. 에너지를 지속적으로 공급하지 않아도 알아서 일을 한다는 무한동력 기계는 엔트로피가 증가하지 않기 때문에 작동할 수 없습니다. 즉 무한동력 기계는 열역학 제2법칙을 어기기 때문에 존재하지 않습니다.

공학(Engineering)이란 과학(Science)의 원리나 법칙과 장인 정신이 깃든 기술(Technology)을 사용해서 유용한 무언가를 만들어내는 것입니다. 따라서 우리가 공학을 사용해서 무언가를 만들어 낼 때 과학에서 제시하는 원리와 법칙을 위반할 수는 없습니다.

엔지니어는 과학자가 아니지만, 과학자의 자세를 가져야 합니다. 미신이나 신앙에 따라서 설계를 하는 것이 아니라, 과학이 제시하는 게임의 법칙 안에서 물건을 만들어야 합니다. 종교는 필연성이 특징입니다. 세상에서 일어나는 모든 일은 신의 뜻이거나 종교의 울타리 안에서 이해해야 합니다. 하지만 과학은 반증이 생명입니다. 어떤 현상을 설명하는 가설을 세우고, 가설을 증명하려면 실험을 해야 합니다. 실험이 가설을 증명한다면 다행이지만, 종종 가설에 반하는 결과를 내놓을 때가 있습니다. 과학을 한다면 이런 결과를 겸허하게 받아들이고, 가설을 폐기하고 새로운 가설을 세우거나 수정해서 다시 실험을 해야 합니다.

물론 엔지니어가 과학자가 될 필요는 없습니다. 세상을 설명하는 가설을 만들 필요도, 그런 가설을 증명하는 실험을 하지 않아도 괜찮습니다. 하지만 자신이 사용하는 방법이 효과적이지 않거나 그릇되었다고 생각할 때, 새로운 방법을 도입하는 자세를 견지해야 합니다. 아울러 엔지니어는 자신이 배운 과학적 원리가 내포된 공학적 지식에 기초해서 물건을 만들어야 합니다. 이런 것들을 이 책에서 전문가 정신(프로 의식)이라고 불렀습니다.

분야에 관계없이 공학을 한다는 것은, 단순한 아마추어가 아닌 전문가의 자질을 갖추어야 하는데, 무한동력 기계를 발견하겠다고 인생을 투자하는 아마추어 발명가는 전문가로서 기본적인 공학적 지식이 부족한 것이고, 이에 반해 무한동력 기계를 발견하겠다고 사기를 치는 엔지니어는 전문가 정신이 부족한 것입니다. 전문 지식이 없는 열정은 공허일 뿐이고, 양심이 사라진 전문가는 해악일 뿐입니다.

소프트웨어 엔지니어링이 기술의 발전과 맞물려 성장하지 못하는 것은, 전문 지식이 부족한 아마추어 전문가나 전문가 정신(프로의식)이 없는 전문가에게 가장 큰 원인이 있는 듯합니다. 아무리 기술이 발전하더라도 우리가 모두 아마추어 엔지니어로 남는다면, 무모하게 소프트웨어 세상의 무한동력 기계를 발명하려고 들거나, 프로젝트 시 데모만 하면 시스템이 죽어난다는 데모 귀신 징크스를 불안해하면서 살아갈 겁니다.

결국 우리는 기술적으로 예전에 비해서 많이 발전했지만, 우리에게 내리는 부당해 보이는 평가나 처우에 대해서, 혹은 우리는 얼마나 전문가 정신을 겸비한 엔지니어로서 일을 했는지 자문해 보아야 합니다. 물론 고약한 문제는 아직도 유효하고, 우리가 제대로 된 것을 만드는 것은 우리를 둘러싼 조직의 역학관계 때문에 요원해 보이기도 하지만, 우리가 전문가 정신을 갖춘 엔지니어로서 스스로 자리매김을 할 때, 우리는 제대로 된 보상을 받을 수 있을 것이라 생각합니다.

이 책이 주는 가장 큰 가치는, 우리 스스로 이런 질문을 끊임없이 하게 하는 데 있습니다. 마치 저자가 “소프트웨어, 어떻게 할 것인가?”에 대한 물음과 그것의 지난한 해소 과정에서 이 책을 저술했듯이, 소프트웨어 개발 현장에서 분투하고 있는 우리 모두가 이런 의문을 품고 고민하는 데 이 책이 조금이나마 도움이 되었으면 하는 바람입니다.

그리고 한 가지 덧붙이자면, 8장을 추가할지에 대해서 편집진과 역자들 사이에 많은 이야기가 오고 갔습니다. 물론 원작을 훼손하지 말아야 한다는 원론적인 이유도 있지만, 그 중심적인 이유는 8장에서 최신 방법론이라고 소개하는 것들이, 사실 지금 관점에서 최신이라고 할 수 없는 것들이기 때문입니다. 결국 “빼야 한다” “실어야 한다”는 갑론을박 끝에 8장은 책에 실리게 되었습니다.

편집진과 역자들은 어떤 결론을 얻었기에 최신도 아닌 방법론을 최신이라고 소개하는 이번 장을 실었을까요? 그 이유를 생각하려면 현대적인 것, 즉 모던(Modern)에 대해서 생각해 봐야 합니다. 강신주 씨가 쓴 ‘철학 vs. 철학’에서 ‘모던’이란 말은 ‘새로운’을 의미하는 라틴어 형용사 ‘모데르나(moderna)’에서 유래했다고 합니다.

현대적인 것이라는 말의 유래를 생각했을 때 현재 시점에서 모던한 것의 운명은 두 가지 정도인 것 같습니다. 먼저 시간이 흘러도 그 가치를 평가할 수 있는 것으로서 소위 클래식의 반열에 오르는 것이 있겠죠. 다른 하나는 현재 엄청난 인기를 얻지만 한때 유행으로 끝나고 시간이 흐르면서 그냥 구식의 어떤 것이 되어버리는 것이 있겠죠.

이런 기준에서 봤을 때, 8장에서 소개하는 일부 방법론은 그냥 구식이 되어버린 어떤 것일 수 있습니다. 과거 모던했던 어떤 방법론이 현재에도 사용되느냐 사용되지 않느냐로 생각한다면, 옛 것이라 할 수 있겠죠. 하지만 관점을 조금 달리해서, “문서화는 어렵고 일치하지 않는 문제가 있다” “결함이 없는 소프트웨어를 만들자” “요구사항을 최대한 확정하고 가자”처럼 이런 방법론이 나온 상황과 맥락, 방법론을 이끈 아이디어는 아직도 유효하다고 생각합니다.

결국 방법론 자체가 주는 실용성이 떨어지고 구식의 것일지 몰라도, 방법론이 해결하려는 문제의 본질과 그 아이디어가 주는 참신함을 생각한다면 모던하다고 판단했고, 지금 사용하고 있는 최신의 것들이 본질적으로 많은 사람들의 고민과 노력의 결과물이 축적된 것이라는 역사성 또한 중요하다고 판단해서 8장을 책에 담기로 결정했습니다. 아무쪼록 이 책으로 여러분을 괴롭히는 현재 진행형의 문제들에 대한 모던한 해결책을 찾으시길 바랍니다.

[주1] Y2K 문제

[주2] 단일 책임의 원칙(Single Responsibility Principle)

의존 관계 역전의 원칙(Dependency Inversion Principle)

인터페이스 분리의 원칙(Interface Segregation Principle)

리스코프 대체의 원칙(Liskov Substitution Principle)

개방 폐쇄 원칙(Open-Closed Principle)

[주3] Software Engineering Body of Knowledge

[주4] <http://www.etnews.co.kr/news/detail.html?id=201002030264>

[주5] Steve McConnell: Wicked Problems, Righteous Solutions (Peter DeGrace and Leslie Stahl). I liked this book from the start, and the longer I’ve considered its ideas the more important the book seems. The book describes life cycle models such as waterfall, evolutionary prototyping, scrum development, and so on. Projects that choose the wrong lifecycle model for their specific needs will face an uphill battle and risk not finishing at all. For gaining a big-picture understanding of how software projects, work, this book is hard to beat.