잔여적 복지와 보편적 복지

사회적 시스템이 복지에 대한 관심이 높아지면서 복지 혜택을 받는 사람들의 대상에 대해 많은 의견들이 있다. '잔여적 복지' 혹은 '선택적 복지'라고 하는 용어는 현재 정부에서 추진하고 있는 못가진 자를 선택적으로 국가에서 혜택을 주는 것이다. 그와 반대로 '보편적 복지'는 국민 모두를 대상으로 동일한 혜택을 주는 개념이다.

이 두가지 형태의 복지는 각각의 장단점이 분명 존재한다. 우선 '잔여적 복지'의 경우, 그 대상자가 못가진 자로 한정되어 있어서 가진 자와 못가진 자를 나누는 또 하나의 차별을 만들게 된다. 또한, 가진 자들의 수입이 못가진 자에게로 돌아가기 때문에 가진 자들의 불만이나 편법을 낳을 수 있다. '보편적 복지'는 국민 전체에게 혜택이 되기 때문에 '잔여적 복지'가 갖게되는 단점은 어느 정도 해소되겠지만, 국가 재정이 문제가 된다. 어떠한 것이 더 나은 것인지에 대한 논의는 지금도 계속되고 있으니, 한번 지켜볼 만하다.

하지만, '복지'라는 어감에는 어찌되었든 내가 제일 먼저 떠오르는 단어가 '못가진 자'라는 사실에 '복지'에 대한 개념을 나도 잘못 이해하고 있는지도 모른다. 가진 자가 조금 더 희생을 해야하는 '잔여적 복지'의 개념에는 누군가의 희생이라는 개념을 가지며, 그로 인해 상대적으로 못가진 자가 있다라는 위안으로 '복지'를 생각하고 있는건 아닌지 모르겠다. '보편적 복지'를 주장하는 쪽에서는 사회 전체 구성원의 안정성을 이야기하고 있다. 즉, 사회 구성원 모두는 최소한 비빌 언덕이 마련되어 있기 때문에 그 바탕 위에 더 나은 발전 지향적인 도전을 할 수 있다라고 한다.

소프트웨어 개발은 이러한 잔여적 복지와 보편적 복지와 같은 개념이 많은 곳에서 존재한다. 그 중에서 가장 유사하게 맞아떨어지는 것이 '역할의 상하 계층화'이다. 역할은 상하의 개념이 거의 희박함에도 불구하고, 직책과 역할을 혼동하여 상하 계층을 만드는 것이다. 예를 들어, '아키텍트'와 '개발자'는 분명 역할로 구분되지만, 경험이 많고 직책이 높은 사람들이 주로 '아키텍트'를 담당하기 때문에 이 두 역할의 관계는 상하 계층 관계가 형성된다. 이와 같은 상황에서 '아키텍트'의 말은 곧 진리요, 명령이다. 이러한 관계는 역할이 가져야할 책임을 훼손하게 된다. 즉, '아키텍트'는 아키텍트로서의 책임을 수행함과 동시에 '개발자'의 책임 영역까지 침범해버린다. 즉, 모든 '개발자'의 작업에 대해 기계적인 절차를 준수하고, 일거수 일투족을 감시하려고 하게 된다. 이를 좀 더 강하게 제약하는 경우에는 결국 모든 틀만을 제시하고, 그 틀안에서 개발자가 수행하도록 강요하게까지 한다.

이를 복지의 개념으로 비교해보면, 역할을 동등 관계가 아닌, 상하 계층 관계를 가지는 경우, 상위의 기술자(아키텍트)는 자신이 하위의 기술자(개발자)보다 더 많은 기술을 가지고 있고, 이를 하위의 기술자들에게 혜택을 부여하도록 하는 행위를 한다. 즉, '잔여적 복지'의 형태이다. 이는 잔여적 복지의 단점인 차별을 만들고, 못가진자로 하여금 상처를 주게 된다. 또한, 가진 자(아키텍트)는 자신의 기술을 못가진 자(개발자)에게 베풀었다는 생각으로 못가진 자(개발자)를 불평하고, 비난하게 된다. 또한, 자신이 가진 기술이 대단한 것인양 못가진 자(개발자)에게 베풀기를 주저하는 핵심적인 내용이 있다고 믿는다. 이러한 '잔여적 복지'의 형태는 결국 가진 자라고 생각하고 있는 역할을 가진 사람의 기술 배척 사상을 낳게 된다. 즉, 자신이 경험한 기술 이외의 것에 대해서는 전혀 인정하지도 않으며, 받아들이지도 않는다. 물론, 이러한 형태는 빠른 결정과 신속한 개발을 진행할 수도 있겠지만, 가진 자(아키텍트)의 판단에 따라 모든 것이 진행되기 때문에 전혀 고객이 원하지도 않고, 본인이 생각하지도 못한 결과를 낳는 경우가 많다. '잔여적 복지' 역시 적은 재정으로 짧은 시간 안에 보여지는 복지 정책을 취할 수는 있다. 

소프트웨어 프로젝트는 CEO나 CIO에게 당장 보고해야 하는 결과를 만들어내는 작업이 아니다. 이들의 입맛에 맞는 것을 만들려면 이들이 가진 생각만을 듣고 소프트웨어를 만드는 것이 훨씬 나을 것이다. (물론, CEO나 CIO는 중요한 이해관계자이다. 여기서 말하는 것은 CEO나 CIO가 소프트웨어가 갖는 기본적인 원리나 원칙을 제대로 이해하는 경우에는 상관없지만, 그렇지 못한 경우에는 어떻게든 올바른 소프트웨어가 만들어지도록 설득하거나 이해시키는 과정이 필요함을 뜻한다.) 당장에 눈에 보이지 않는다고 해서 '잔여적 복지'를 선택하여 포퓰리즘과 같은 효과를 보게 되면, 소프트웨어 아키텍처가 지닌 고유의 성질을 잃어버릴 가능성이 높다.

시간이 다소 걸리더라도 '보편적 복지'를 선택해서 '역할의 수평적 관계'를 이룬다면, 더 안정적인 상태에서 보다 나은 발전을 도모할 수 있을 것이다. 즉, 서로의 고유한 영역을 지키고, 책임을 침범하지 않도록 주의하면 더 창조적인 마이드를 통해 고객에게 더 가치있는 결과물을 인도할 수 있을 것이다.