[지디넷코리아]필자는 지난 호를 통해 '개발자의 진보'라는 거대담론을 끌어들여 진보를 방해하는 요소로 도그마를 꼽았습니다. 도그마는 자신이 신뢰하는 기술에 대한 집착으로 새로운 기술을 외면하게 합니다.

뿐만 아니라 적절하지 않은 영역에 잘못된 기술 적용을 유도합니다. 이번 글에서는 도그마와 더불어 우리를 괴롭게 하는 것인 '미신'에 대해 이야기해 보겠습니다.

플라톤의 『국가』에 나오는 ‘동굴의 비유’에 따르면 우리는 실제를 왜곡해서 봅니다. 동굴 안에 있는 사람은 동굴 밖의 사람들의 목소리를 동굴 특유의 울림현상 때문에 무섭게 듣게 됩니다. 동굴 안에 있는 사람은 불규칙한 표면의 벽에 반사되는 실제보다 크고 왜곡된 그림자 때문에 도깨비를 연상합니다.

따라서 동굴 안에 있는 사람은 바깥세상을 두려워하고 동굴 밖을 나오기를 꺼려합니다. 이런 잘못된 믿음을 우리는 미신이라고 합니다. 그리고 미신은 대상을 오해하게 하죠. 이제 동굴 밖으로 나가 봅시다.

미신을 경계하라
도그마가 집착이라면 미신은 환타지라고 할 수 있습니다. 미신은 실제가 아닌 허상을 보게 하기 때문이죠. 도그마의 경우처럼 새로운 패러다임을 적응하지 못하는 것도 좋은 자세가 아니지만 새로운 패러다임의 유혹에 쉽게 넘어가는 것도 위험합니다.

흔히 새로운 기술이 발표되면 과장된 선전이 동반됩니다. 선전의 속성은 장점을 부각시키고 단점은 무관심하게 만드는 것입니다. 물론 사용자 그룹이나 개발자 사이트에서 비판적이고 객관적 분석의 아티클이 게시되지만 일차적으로 접하는 정보는 선전입니다. 그동안 개발자들은 이런 선전의 홍수 속에서 많이도 일희일비했습니다.

선전은 팩트를 미신으로 만듭니다. 이런 상황에서 그 기술을 도입한다고 할 때 실제와 거리 있는 미신을 도구로 프로젝트에 참여하는 현상이 발생합니다. 따라서 우리는 좋은 기술을 좋게 사용하기 위해 허와 실을 판별하는 노력이 필요합니다.

스티브 맥코넬은 『Professional Software Development』에서 설명한 ‘프로세스 사칭(process imposter)’으로 설명한 내용이 이런 현상의 좋은 예시가 됩니다. 맥코넬의 설명을 빌리면 방법론의 중요성을 사칭하는 조직이 방법론을 적용하는 데 있어서 조직을 위한 방법론이 아닌, 방법론을 위한 방법론으로 접근법의 오류를 범하는 경우가 많습니다. 이 방법들은 결과적으로 프로젝트에 반작용이 될 수 있습니다.

가령 이 조직은 IBM의 정부 시스템 담당 부서나 NASA의 소프트웨어공학연구실(SEL) 같은 방법론 기반(process oriented) 조직들을 조사합니다. 짧은 관찰을 통해 이 조직들이 엄청난 분량의 산출물을 만들고 회의를 자주 한다는 사실을 알아냅니다. 그리고 곧바로 더 많은 산출물과 미팅들을 개발 과정에 포함시킵니다.

그렇다면 과연 이 조직도 IBM과 NASA의 성공사례에 동참할 수 있을까요? 아마 운이 따라주지 않는 한 좋은 결과를 얻기 힘들 것입니다. 웃지 못할 사실은 프로세스 사칭 손해에 대한 책임이 개발자들의 야근으로 돌아온다는 것입니다.

결국 문제는 너무 쉽게 새로움을 받아들이는 데 있습니다. 좀 더 정확하게 말하자면 과대 선전 슬로건에 현혹되는 것입니다. 이 새로움에 대한 긍정적이기만 한 정보들은 ‘다 잘 될 거야’라는 믿음을 주지만 여과·검증 없이 받아들였을 때 곧바로 미신이 되고 맙니다. 그리고 미신은 개발자에게 직접적으로 재앙을 부릅니다.

유사한 사례가 우리 주변에 매우 많이 발생합니다. UML을 도입하면 개념적 모델을 작성하여 의사소통의 오류 없이 전달할 수 있습니다. 하지만 작업자의 시스템 분석과 표현 방식에 따라 여러 가지 그림이 나올 수 있습니다. 따라서 표현 방식이 표준화됐지만 표현 의도나 내용까지 표준화되지는 않습니다. 즉, UML은 의사소통의 공감대를 촉진시키는 좋은 도구일 뿐이지 의사소통 장애율을 0%로 만들어주지는 않습니다(촉진과 실현의 착란 현상).

하지만 UML을 설명하는 사람은 좀처럼 이 사실을 고백하지 않습니다. 물론 필자의 경우도 그랬지만 일단 UML 사용을 권하는 입장에서는 주의점이나 단점을 말해줄 여지가 없는 것입니다. 수동적으로 이 정보를 그대로 받아들인 사람은 의심 없이 UML을 사용하게 됩니다. 미신에 빠진 상태에서 이제 UML을 사용하게 되겠지만 이 상황에서도 단점이나 주의점 등을 포함한 균형 잡힌 정보를 수집하여 함정에 빠지는 일을 경계해야 합니다.

정리하자면 새로운 패러다임을 접근하는 방식을 신중하게 수립해야 한다는 것입니다. 이런 방법 중 하나로 XP에선 난감한 문제들의 해결책을 찾을 때 사용하는 스파이크 솔루션(spike solution)은 차용해볼 만합니다. 키포인트가 되는 문제 상황을 정의하고 이 상황 하에 실제로 적용하려는 방법을 시험해보는 것입니다. 이런 시뮬레이션을 통한 추론이 한 방법일 수 있습니다.

근본적으로 전술했던 오류는 편향되게 수집한 정보가 원인입니다. 바꿔 말하자면 충분한 학습의 부재입니다. 그러므로 얻게 되는 결론이 팩트가 아닌 미신이 될 수밖에 없습니다. 따라서 좀 더 정확한 정보 수집과 그 정보가 현재의 필요(need)에 적합한지 검사를 거쳐야 할 것입니다. 새로운 대안에 대한 객관성·보편 타당성이 확보되지 않는다면 미신과의 전쟁에서 승리할 수 없습니다.

진보와 패러다임의 혁명

토마스 쿤

필자는 의도적으로 본문을 통해 ‘패러다임’, ‘진보’ 같은 거대 담론의 용어들을 사용했습니다. 그것은 진보란 어떻게 이루어지며, 또 진보와 패러다임간의 상관관계를 설명하고 싶었기 때문입니다. 과학철학자 토마스 쿤(Thomas S. Kuhn)은 『과학혁명의 구조』에서 진보의 과정을 ‘패러다임의 혁명’으로 설명하고 있습니다.

패러다임은 우리가 자연스럽게 사용하는 개념이지만 복잡하고 까다로운 뜻을 지니고 있어서 쿤 자신도 정확하게 규정하지 않고 사용했기 때문에 개념에 혼란이 빚어지고 있습니다. 보편적으로 패러다임이란 어떤 과학자 사회(scientific community)가 공통적으로 가지고 있는 가치관, 신념, 준거 체계라 할 수 있습니다. 또는 그 시대를 대표하는 과학적 이론이나 기준으로 과학자들이 공유하고 있는 신념을 말합니다. 즉, 패러다임이란 어떤 과학의 학파에 정합성(整合性)을 주는 모델 정도로 인식할 수 있습니다.

하나의 패러다임이 다른 패러다임으로 대체되는 현상을 패러다임 전이라고 합니다. 쿤에 의하면 하나의 패러다임이 확립되기 이전, 이 전이가 발생하기 이전 상태를 전과학 상태라 합니다. 이때 이 패러다임은 보편적인 이론이 존재하지 않고 여러 가지 가설과 학설이 분분해 혼란스러운 상황이 발생합니다. 새로운 대안을 위해 여러 이론들이 경합을 벌이는 시기이기도 합니다. 이때 어떤 이론들은 승자가 되기도 하고 어떤 이론들은 서로 합병되기도 하고 어떤 이론들은 이슈만 남기고 역사의 페이지에서 사라지게 됩니다.

IT 역사에서도 이런 혼돈의 시기가 빈번히 발생합니다. 얼마 전만 보더라도 AOP, Product-Line, SOA, 웹서비스, MDA, O/R 맵핑 등과 같은 이슈들이 홍수처럼 등장할 때가 있었습니다. 하지만 일부는 지속적으로 활발히 연구되고 있고, 일부는 회자되고만 있습니다.

이런 혼돈스런 이론들이 차차 질서를 갖게 되면 이들을 포괄하는 체계와 논리가 형성됩니다. 어느 정도 안정된 이론적 토대를 갖추게 되면 이 패러다임은 과학자들의 지속적인 지지를 얻으며, 과학자들이 문제 해결의 틀을 맡길 만큼 절대적인 신뢰를 보냅니다. 이러한 패러다임에 바탕을 둔 연구를 ‘정상과학(normal science)’이라 합니다.

이때 과학자들은 모든 탐구 대상을 정상과학의 패러다임으로 접근합니다. 패러다임은 이때 하나의 세계관이 되는 것입니다. 객체지향 패러다임의 시대에 모든 사물은 객체로 보이고, 컴포넌트 시대에서는 모든 게 컴포넌트로밖에 보이지 않습니다. 또한 이 시기의 이론들은 이 패러다임을 강화·옹호하는 것이 대부분이며 이 세계관을 벗어난 사고에서 자유롭기 힘듭니다. 이때 발표되는 논문들은 해당 패러다임에 관한 논문 일색이라는 점을 보면 잘 알 수 있습니다.

사실 이 시기는 소프트웨어 분야의 경우 표준화 작업이 집중적으로 일어납니다. 필자의 관찰에 의하면 자바 스펙이나 CORBA, J2EE 표준화 작업이 갑자기 상승곡선을 나타내는 시기가 이 정상과학 단계에서 이뤄집니다. 또한 이 즈음에서 각 밴더의 제품들이 안정화되고 레퍼런스 사이트가 늘어나게 됩니다. 이렇게 신뢰를 보장하는 조건이 형성되면 시장에서도 이 기술에 대한 소비가 늘어나며, 이런 분위기와 더불어 개발자의 학습욕구를 조급하게 자극합니다.

이 정상과학이 시대적 정설이 되다가도 어느 순간 이 패러다임으로 설명할 수 없는 여러 가지 모순과 균열이 나타나고 새로운 문제가 제기됩니다. 이 시기의 학자들은 정상과학의 당위를 입증하기 위해 정상과학에 대한 애드혹(ad-hoc : 임기응변식의) 수정 작업을 진행합니다.

이를테면 90년대 후반, 4GL 언어를 주축으로 C/S 애플리케이션이 한참 주가를 올렸는데 시스템이 복잡하고 거대해짐에 따라, 그리고 인터넷의 확산과 PC 사용자가 많아짐에 따라 C/S 구조만으로 해결할 수 없는 문제점이 속출하게 됩니다. 이에 대한 대책으로 좀 더 강력한 C/S 기반의 컴포넌트들이 생산됐지만 결국 분산 시스템 패러다임으로 전권을 내주게 됩니다.

결국 애드혹 수정의 한계를 느끼는 단계에서 정상과학에 ‘이상(異常, anomaly)’이 생기고 이상 현상을 해결할 수 있는 새로운 학설이 등장하게 됩니다. 이 시기는 또 다시 차세대 대안적 패러다임의 발생을 위한 전과학 발생의 조건이 됩니다. 이처럼 하나의 패러다임 생명주기는 하나의 사이클로 표현될 수 있으며 하나의 사이클의 끝은 다음 사이클의 시작과 만나게 됩니다. 정리하자면 패러다임의 생명주기는 다음과 같은 단계로 표현될 수 있습니다(<그림 1>)

<그림1> 과학 혁명의 구조

지금까지 진보라는 의미는 이런 패러다임 변화의 사이클의 연장에서 한 사이클이 끝난 후 다음 사이클로의 전이를 의미합니다. 쿤에 의하면 이 한 사이클의 전이는 혁명적이며 이 사이클의 무한 연장을 과학 혁명의 구조라고 설명합니다. 따라서 우리가 IT 종사자로서 빠르게 변하는 시대의 속도와 맞추기 위해 시대가 원하는 패러다임의 본질을 정확히 읽을 수 있어야 하며 이런 혜안이 없이는 시대의 속도에 동기화하기 힘든 입장에 처합니다.

더불어 쿤에 의하면 이 사이클의 한 반복이 꼭 과학의 발전을 의미하지 않습니다. 패러다임의 전환, 즉 과학 혁명 자체가 과학의 발전과 일치하지는 않습니다. 과학자들이 새로운 패러다임을 수용하게 되는 이유는 새로운 패러다임이 과거의 패러다임보다 문제를 잘 해결하거나 더 나은 과학 이론을 제공하기 때문이 아니라 기존의 패러다임이 현재 나타나는 이상 현상을 해결하지 못했기 때문입니다.

여기서 우리가 미신에 빠지는 두 가지 상황을 유추할 수 있습니다. 하나는 새로운 패러다임의 본질을 이해하지 못하고 수용하는 것과 다른 하나는 발전되지 않는 과학을 채택하는 것입니다. 따라서 새로운 패러다임에 접근할 때 평가자의 입장을 가질 필요가 있습니다.

평가자로서의 입장을 갖기 위해서는 패러다임의 본질과 출생의 비밀(?)에 대해서도 이해할 수 있어야 합니다. 쿤의 이론을 인용한 또 다른 이유는 쿤의 이론을 따르면 현 패러다임의 흥망성쇠 단계상의 위치를 포착할 수 있고, 현 패러다임이 극복하려 했던 부분과 극복하지 못하는 부분을 포착할 수 있는 좋은 프리즘이 되기 때문입니다.

방법론 패러다임의 전이 과정
그렇다면 방법론 역사에서 패러다임의 혁명이 어떻게 전이됐는지 살펴보도록 합시다. 폭포수 모델은 일반적인 제조업의 생산 모델을 그대로 따르고 있습니다. 따라서 일반적인 개발 과정을 단계별로 잘 정의하고 있습니다(문제 분석, 요구사항 분석, 설계, 구현, 테스트, 운영 및 유지보수 등).

하지만 초기의 결정 사항들에 대한 검증(테스트 단계)이 너무 늦게 이루어지기 때문에 테스트 상에서 잘못이 발견되었을 때 복구비용이 너무 큽니다. 또한 고객의 요구사항을 정확히 수집하는 방법이 부재하여 고객이 원했던 시스템과 다른 시스템을 만들 가능성도 있습니다. 즉 제조업의 공정 과정을 소프트웨어 개발에 적용했을 때 모순들이 발견됩니다. 후자의 문제점들을 해결하는 방안으로 프로토타이핑 기법이 적용됩니다.

고객에게 실제 시스템의 UI와 기능들을 확인시켜 주고 작업하기 때문에(JAD : Joint Application Development) 의사소통 문제를 해결할 수 있습니다. 하지만 고객의 요구사항은 초기에 완결되는 것이 아니라 제작 과정에서 변경될 수 있습니다. 즉, 프로젝트가 진행되면서 요구사항이 구체화·세분화되어가며 이런 관계로 초기에 수립했던 시스템의 디자인은 상대적으로 변하게 됩니다.

이와 같은 리스크들을 관리하고 시스템에 대한 이해를 확인·수립할 수 있는 나선형 모델이 개발됩니다. 하지만 변경의 비용은 여전히 심각하여 아키텍처 중심의 개발이 제안됩니다. 이 시점에서 여러 시행착오를 거치면서 얻게 된 수많은 연구 결과들과 UML, 객체지향 등의 이론들이 집대성되어 객체지향 방법론이 탄생합니다.

즉, 폭포수 → 프로토타입 → 나선형 → 객체지향으로의 방법론 모델 변화는 이전 단계의 검증된 기술들을 그대로 수렴합니다. 반면 전 단계가 해결하지 못한 구조적 모순을 해결하므로 진화해 가는 것입니다.

<그림 2> 방법론 패러다임의 전이

이렇게 진보란 연장선 상에서 여러 패러다임의 흥망성쇠가 등장하며 각 패러다임의 전이는 당시 정복하려 했던 방법론의 문제와 이전 패러다임의 모순들을 읽을 수 있습니다. 따라서 각 패러다임의 이해는 높아질 뿐만 아니라 이런 역사적 흐름에 약간의 예지력을 추가하면 미래의 대안도 예측할 수 있습니다.

우리는 많은 패러다임의 전환을 경험했습니다. 하지만 분별력 없는 새로운 패러다임의 도입으로 인해 아깝게 사장된 과거의 유산들도 돌아봐야 할 것입니다. 즉, 우리가 열심히 만들어서 분만한 메인프레임의 코볼 모듈, C 라이브러리들, 4GL 컴포넌트 등 나의 고된 작업의 소중한 결과들이 너무 쉽게 사생아로 버려지고 있는 것은 아닌지 확인해 보아야 할 것입니다.

따라서 과거의 것은 무조건 폐기돼선 안 됩니다. 이를테면 메인프레임은 구시대의 산물일까요? 메인프레임은 그 시대적 요구를 만족했던 솔루션입니다. 또한 메인프레임 단계를 생략한 현재의 엔터프라이즈 시스템을 생각할 수 없을 정도로 역사적으로 의미있는 단계였습니다. 그리고 현재의 시스템들은 메인프레임으로부터 많은 것들을 배웠습니다.

아직도 Batch Job 사용에 있어 메인프레임은 자기 몫을 충분히 하고 있습니다. 그런 의미에서 함부로 폐기해야 할 대상이 아닙니다. 하지만 우리는 가끔 기술 발전의 관성에 빠져 과거의 지혜들을 소홀히 할 때가 있습니다. 즉, 시대의 속도에 동기화하는 노력과 함께 한편으로는 가지고 가야 할 것들을 챙기는 노력도 필요합니다. 사실 과거의 지혜들은 시대가 지나도 이후 기술들에 반영이 되거나 일부가 됩니다. 잠시 후 소개할 라카토스의 연구는 이 내용을 포함합니다.

연구 프로그램

라카토스

쿤에 의하면 과학의 혁명을 곧 과학의 발전으로 등치시킬 수 없다고 했습니다. 즉, A라는 패러다임에서 B로의 변경이 곧 B라는 패러다임의 우월성을 대변하지 않습니다. 그렇다면 A라는 패러다임에 비해 B라는 패러다임이 우월하다는 것은 어떻게 증명할 수 있을까요?

포퍼의 제자였던 라카토스(Lakatos)는 패러다임의 우월성을 입증하는 작업으로 ‘연구 프로그램(Research Program)’을 제안하고 있습니다. 라카토스의 연구 프로그램에 의하면 다음과 같은 조건들이 갖춰질 때 패러다임의 진보를 진단할 수 있다고 합니다.


꼭 이런 난해한 검증을 거치지 않더라도 새로운 패러다임 도입 이전에 이와 유사한 나름의 검증 작업이 선행되어야 할 것입니다. 이 방법론 중 가령 나선형 모델의 방법론에서 객체지향 방법론을 채택하는데 있어 다음과 같은 검증을 할 수 있습니다. 그리고 이런 류의 연구 프로그램을 거쳐야만 진보를 확인할 수 있고 안심하고 적용할 수 있을 것입니다.

장황하게 과학철학자들을 개입시켜 진보에 대한 진단을 해야 했던 이유는 너무도 쉽게 새로운 기술이나 툴, 환경, 방법론 등에 대한 환상을 갖고 검증절차 없이 채택하는 경향이 존재하기 때문입니다. 이 미신을 극복할 수 있어야 기술과 실력의 진보를 확인할 수 있는 나침반을 확보할 수 있습니다.

여기서 생각해 볼 문제는 또 있습니다. 한창 C/S 기반의 4GL 컴포넌트들이 아성을 누리던 시대가 있었습니다. 웹이 대세고 객체지향 개념이 정상과학으로 채택되자 4GL 컴포넌트들은 홀연히 관심 밖으로 밀려납니다. 웹의 인프라와 더불어 소프트웨어가 더욱 거대하고 복잡하게 비대해지면서 다시 왕권은 (4GL 컴포넌트의 문제들을 제거하고 시대적 요구에 맞게 업그레이드된) CBD로 넘어갔습니다. 이런 춘추시대와 같은 소프트웨어 역사를 볼 때 우리에게 있어 진보의 요소에는 ‘시대적 요구와 환경’이라는 변수를 잊지 말아야 할 것입니다.

‘USE’가 아닌 ‘DRIVE’
패러다임은 세계관입니다. 사람들은 패러다임을 통해 대상을 인식합니다. 우리는 객체지향이라는 패러다임으로 소프트웨어를 바라보기도 하고 특정 방법론이라는 패러다임으로 프로젝트 진행 과정을 이해하기도 합니다. 필자도 CORBA란 패러다임으로 모든 소프트웨어를 바라보곤 하는데, 가령 트랜잭션 시스템들을 이해할 때 CORBA OTS (Object Transaction Service)에 대한 이해를 기반으로 접근을 시작하거나 객체 직렬화를 이해할 때 CORBA의 Value Object 전송 매커니즘으로 해석합니다.

좋았던 점은 이미 학습한 유사 지식을 통해서 이해의 깊이와 속도를 높일 수 있는 반면 자신이 가진 프리즘의 영역 밖에선 허약해집니다. 따라서 여러 프리즘의 관점을 가질수록 대상에 대한 이해는 넓어집니다. 즉, 폭넓은 프리즘을 갖는다면 미신도 도그마에도 자유로울 수 있는 유리한 위치에 놓일 수 있습니다. 한편으론 새로운 개념을 받아들이기 위해선 그 개념을 해석할 수 있는 준거, 토대가 있어야 합니다. 따라서 숙고해서 정립한 자신 고유의 세계관을 갖는다는 것은 패러다임 수용에 도움이 됩니다.

상술한 바와 같이 대개 새로운 패러다임은 그 우월성의 과대 선전과 함께 ‘무조건 좋다’ 식의 무드를 조성합니다. 쿤의 지적처럼 새로운 패러다임이 꼭 좋은 것이라고 할 수는 없습니다. 패러다임간의 우월성을 입증하는 작업을 통해야만 그 패러다임이 차세대 대안으로서 왕좌를 거머쥘 수 있습니다. 이 과대 광고와 검증, 여과, 재단 없는 수용은 그 패러다임을 미신으로 둔갑시키며 스스로를 피해자로 전락시킵니다. 이제 동굴 밖으로 나가 실체를 바라봅시다.

혼다 신화의 주역인 혼다 이치로는 이렇게 말하고 있습니다. “한번 모방하면 영원히 모방하게 된다… 우리들은 처음부터 고통스러운 방향을 선택했다. 그렇기 때문에 나중엔 쉬워졌다.” 확실히 우리는 새로운 기술을 여과 없이 받아들이는 데 익숙합니다. 그러므로 그대로 받아들이는 태도를 필자는 단순한 ‘소비’로 봅니다.

하지만 이 기술들을 소비하는 이유는 도입하기 위해서입니다. 소비만 있는 사용은 반드시 후폭풍이 따릅니다. 즉, 나중에 편함에 대한 대가를 지게 됩니다. 소비와 도입은 다른 개념입니다. 도입을 위해서 그 조직에 익숙하게 대상을 만들거나 대상을 잘 사용하도록 조직을 바꿔야 합니다(방법론에선 Tailoring, SW의 경우 Porting이라고 합니다). 즉 새로운 기술, 방법론, 툴을 접하는 데 있어 ‘USE’가 아닌 ‘DRIVE’해야 할 것입니다.

사실 이 텍스트를 통해 필자도 감당하기 힘든 권장 사항들을 주문하기란 매우 곤욕스럽습니다. 하지만 IT란 전장에서 생존하기 위해 자신의 단점을 극복하려는 노력은 개발자로서 필연적인 숙명입니다.

도그마는 고집스러운 독단의 늪이고 미신은 최음제입니다. 따라서 도그마적으로 접근하는 방법은 현재 패러다임이란 관성속도에 집착한 나머지 새로운 패러다임의 속도에 적응하지 못하는 것이고 미신은 발 빠르게 새로운 패러다임의 속도를 쫓는 나머지 새로운 패러다임의 내용들을 놓치게 됩니다. 따라서 자신의 가치관에 반증·오류 가능성을 열어놓는 것과 새로운 가치관에 진지하게 접근하는 중심이 필요합니다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.