기술을 얘기한다 2011.10.27 11:30

(필자 주: 1년쯤 전에 책에 넣으려고 작성했던 초고를 재활용한 포스트. 티스토리의 MS Word API가 각주를 처리하지 않아서 각주를 할 수 없이 본문에 끼워 넣고 회색으로 칠했다. 그 바람에 읽기가 많이 불편해져 버렸다. ㅠㅠ)

이 장에서는 오픈 소스가 소프트웨어 개발 방식에 가져다 준 변화를 살펴봄으로써 이러한 변화가 정부 2.0에 시사하는 바를 검토한다. 그리고 오픈 소스를 정부 2.0의 구현에 활용하는 방안과 그에 따른 이슈를 살펴보고 한국의 소프트웨어 개발 현실에 비춰 정부 2.0에 거는 기대를 제시한다.

1. 원리로서의 오픈 소스와 정부 2.0에 주는 시사점

오픈 소스는 단순히 소프트웨어를 개발하고 공급하는 하나의 방식이 아니라 인터넷 시대의 일 처리 방식에 대한 근본적인 성찰을 보여 주었다는 점에서 중요하다. 1990년대 초반 리눅스 운영체제의 등장은 기존의 개발자들 그 중에서도 특히 뛰어난 개발자들에게 큰 충격을 주었다. 왜냐하면 소수의 전문적인 프로그래머가 잘 정의된 설계에 따라 폐쇄적으로 개발하는 것이 당연히 가장 효과적인 개발 방법이라고 생각했는데 리눅스 개발을 이끈 리누스 토발즈는 인터넷으로 연결된 수많은 사용자들을 공동 개발자로 활용하는 떠들썩하고 정신 사나운 방식으로 개발을 하면서도 운영체제와 같은 무척 규모가 크고 까다로운 소프트웨어를 성공적으로 개발해 내었기 때문이다. 게다가, 리눅스는 엄청나게 빠른 속도로 개선이 되고 있었다. (물론, 지금도 진화는 계속되고 있다.) 한마디로 소프트웨어 개발 방법론에 있어서 코페르니쿠스적 전환이 이루어 진 셈이다. 이렇게 사용자의 참여를 기반으로 개발을 진행하는 소프트웨어를 오픈 소스 소프트웨어라고 하며 이 개발 방식이 갖는 특징은 다음과 같다.

  1. 사용자가 직접 참여하는 개발: 개발하고 있는 소프트웨어의 원시 코드를 공개하고 사용자들이 문제를 찾아내고 추가해야 할 기능을 (심지어는 추가에 필요한 프로그램 코드까지) 제안하도록 한다. 수많은 사용자들이 참여함으로써 다양한 환경에서 다양한 사용 방법으로 소프트웨어의 기능을 검증하므로 당연히 문제점도 더 빨리 발견하고 더 쉽게 해결한다.
  2. 모두를 만족시키는 하나 대신 소수를 만족시키는 여럿: 오픈 소스 개발에서는 최초의 결과물을 (완성도가 떨어진다고 하더라도) 최대한 빨리 내놓음으로써 그 아이디어에 관심 있는 사용자들을 끌어들이고 사용자들이 내놓는 아이디어나 추가 코드를 곧바로 반영하여 새 버전을 내놓음으로써 참여하는 보람을 느끼게 한다. 하지만, 최신 버전은 기능이 많은 반면 안정적이지 못한 경우가 대부분이어서 더 많은 기능을 원하는 사용자를 위한 최신 버전과 일반 사용자를 위해서는 안정적인 (물론 기능은 적은) 버전을 따로 둔다.
  3. 사용자가 만들어 가는 목표: 개발하려는 소프트웨어가 어떤 모양이 되어야 할 지 최종 목표 지점을 정해 놓고 가는 것이 아니라 사용자의 의견을 계속 수렴하여 개발 방향을 계속 수정한다.[각주: 좀 다른 맥락이긴 하지만, 소프트웨어 개발 방법론 중 하나인 익스트림 프로그래밍의 주창자인 켄트 벡은 소프트웨어 개발을 운전에 비유한 바 있다. "운전은 차를 올바른 길로 가게 하는 게 아니야. 운전이란 계속 주의를 기울이면서 이쪽으로 조금 저쪽으로 조금 바로 잡아가는 거지" (참조: Beck, K. and Andres, C. 2004 Extreme Programming Explained: Embrace Change. Addison-Wesley Professional.)] 이러한 방식은 사용자들로 하여금 자신들의 의견이 반영된다는 참여의 즐거움을 주는 동시에 변덕스런 사용자들의 요구 변화를 지속적으로 따라잡을 수 있다는 장점을 동시에 누리게 된다.

인터넷 또는 웹에서 누구나 정보를 똑같이 그리고 투명하게 접근할 수 있는 틀을 제공하고 이를 기반으로 다수의 참여자들이 자발적으로 참여할 수 있도록 독려하고 그러한 참여 결과를 반영하는 원리를 오픈 소스 개발 방법론이 제시하고 있는 것이다.

그렇다면 소프트웨어 개발자 집단이 발견해 낸 이러한 원리가 유용하다면 정부 또는 가버넌스라는 전혀 다른 영역에서도 비슷하게 적용될 수 있지 않을까? 이 장에서는 오픈 소스 소프트웨어 개발의 원리를 가장 잘 설명하고 있는 에릭 레이먼드의 "성당과 시장"을 정부 2.0의 관점에서 검토함으로써 오픈 소스 라는 원리가 새로운 정부의 원리에 원용될 수 있음을 보여 주고자 한다.[각주: 원문은 http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ 에서 볼 수 있으며 한국어 번역판은 http://wiki.kldp.org/wiki.php/DocbookSgml/Cathedral-Bazaar-TRANS 에서 볼 수 있다. 이 글의 본문에서 인용한 부분은 모두 한국어 번역판에서 가져왔다.] 이 절의 본문에서 인용된 글은 특별한 표시가 없는 한 "성당과 시장"에서 인용한 것이다.

원리1: 하고 싶은 것을 하게 하라.

"모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다. (중략) 개발자들은 너무나 자주, 단지 돈 때문에 그들이 필요로 하지도 않고 좋아하지도 않는 프로그램을 만들어 내는데 시간을 쓰고 있다. 하지만 리눅스 세계에서는 그렇지 않다 - 아마도 이것이 왜 리눅스 공동체에서 만들어진 소프트웨어들의 평균적이 품질이 그렇게나 좋은지를 설명해 줄 것이다."

너무나도 당연한 얘기지만 사람들은 자기가 하고 싶은 일을 할 때 가장 좋은 결과를 낸다. 정부가 제공하는 서비스는 정부가 그것을 하고 싶어서 제공하는 것이 아니라 납세자에 대한 정부의 의무이기 때문에 하는 것이다. 따라서, 정부가 제공하는 서비스가 시민들의 기대에 부응하지 못하는 것은 어쩌면 피할 수 없는 운명이다. 정말로 그 일을 하고 싶어하는 사람들이 그 일을 할 수 있도록 돕는 것으로 정부의 역할을 바꿔 나가는 것이 필요하다. 시민 스스로 정말로 필요로 한 것을 서비스로 만들어 갈 수 있다면 그 결과는 정부가 제공하는 서비스 보다 당연히 더 좋을 수 밖에 없을 것이다.

원리2: 결과로 평가하라.

"위대한 프로그래머의 중요한 특징 중 하나는 건설적인 게으름이다. 그들은 들인 노력으로가 아니라 결과로 평가 받는다는 것을 알고 있으며"

결과가 아닌 과정으로 평가하면 겉만 번드레한 결과를 낳는다. 과정이 아니라 결과로 평가해야 한다는 것에는 모두가 동의하면서 왜 정부가 제공하는 서비스는 겉만 번드레한 경우가 반복되는가? 그건 과정과 결과에 대한 혼동에서 비롯된다. 도로를 뚫고 강을 정비하고 신청사를 건립하고 웹 포털을 운영하는 것은 정부가 서민에게 제공해야 할 서비스를 달성하기 위한 도구(즉, 과정)에 지나지 않는다. 그런 도구를 통하여 제대로 된 서비스가 제공되었을 때 이를 이용하는 시민들이 결과적으로 만족을 느끼는 것이다. 시장님이 얼마나 많은 돈을 들여서 몇 그루의 가로수를 심었느냐가 아니라 그 가로수가 그저 아스팔트에 세운 초록색 말뚝인지 아니면 도심의 숲과 숲을 연결하는 생태 통로의 역할을 하는 지에 의해 평가되어야 한다. 하지만 우리의 관료제는 결과가 아니라 얼마나 그럴싸한 일을 많이 벌이는지 얼마나 늦게까지 퇴근하지 않고 자리를 지키는지로 평가하곤 한다. 그래서는 가망이 없다.

원리3: 중복을 피하라.

"누군가의 거의 완성된 소스를 찾아보는데 시간을 들이는 것이 (인용자 주: 처음부터 개발하는 것보다) 좋은 결과를 가져다 줄 가능성이 높다."

이건 너무 당연해서 굳이 원리라고 할 것도 없는데 현실 세계에서는 중복이 너무나도 잦다. 모든 지방자치단체가 거의 비슷한 일을 하므로 이를 소프트웨어로 개발하면 결국 비슷한 결과가 나올 수 밖에 없다. 그럼에도 불구하고 모든 지방자치단체들은 경쟁적으로 똑같은 서비스를 제각기 만들어 내고 있다. 이것이 전국의 모든 곳에서 반복되고 있으니 국가 전체로는 상당한 중복 투자가 되고 있는 셈이다.

중복의 문제는 단지 예산의 낭비로만 그치는 것이 아니라 투자의 효용 자체를 위협하고 모든 투자의 결과물을 싸잡아 진부하게 만들어 버린다. 이 글의 맥락과는 약간 다른 예이긴 하지만 이를 제일 잘 보여 주는 것이 모든 지방자치단체가 붕어빵 찍어 내듯 복제 해내는 각종 지역 축제다. 너무 많은 복제가 난립하다 보니 그 어느 것 하나 정체성을 유지할 수 없이 다 똑 같은 난장판이 되고 있다. "자연은 반복하지 않는다".[각주: Elizabeth Cady Stanton, "The Solitude of Self", http://historymatters.gmu.edu/d/5315/] 그냥 자연스럽게 생겨난 지역 축제라면 이렇게 똑 같을 수는 없다. 너무 많은 복제가 존재함으로써 이를 이용하는 시민들은 쉽게 식상하게 되고 이는 그나마 전통이 있고 제대로 준비하는 곳까지도 같이 오명을 뒤집어쓰게 만든다.

원리 4: 시민은 고객이 아니라 동료다.

"적절하게 유도해 준다면 사용자들은 공동개발자가 될 수도 있다. (중략) 사용자들을 공동개발자로 생각하면 코드가 다른 어떤 방법보다도 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다."

정부가 아무리 열심히 한다고 해도 자원이 제한되어 있으므로 제공할 수 있는 서비스의 한계는 뚜렷하다. 이런 한계를 가장 쉽게 그리고 가장 확실히 넘어서는 방법은 시민들의 손을 빌리는 것이다. 시민들이 정부의 서비스에 참여하는 방식은 크게 두 가지로 나뉠 수 있다. 소극적으로는 정부가 이미 제공하고 있는 서비스의 문제점을 찾아내고 개선하는 방안을 제시하는 것으로부터 적극적으로는 새로운 서비스를 제안하고 심지어는 직접 실현하는 것까지 모두 가능하다. 어차피 한정된 자원으로 일을 할 수 밖에 없는 정부로서는 시민들의 손을 빌려 서비스를 개선하고 확장해 나가는 것이 올바른 선택이라 할 수 있다. 시민들의 손을 빌린다는 것은 단지 정부 서비스에 참여하는 사람의 수를 늘인다는 양적인 측면뿐 만 아니라 질적인 측면에서의 변화(아래의 원리 6 참조)를 포함한다. 하지만 시민의 참여를 끌어내고 유지하는 것(아래의 원리 5 참조) 그리고 이를 위하여 정부가 갖추어야 할 바람직한 특성(아래의 원리 8과 9 참조)에 대한 고려도 필요하다.

원리 5: 사람들의 참여를 지속시키는 비밀은 전망과 보답이다.

"개발에 참여함으로써 자기만족을 얻으리라는 전망에 자극 받았고, 그들이 하는 일이 계속해서 (어떤 때는 날마다) 향상되고 있다는 것이 보답이 되었다."

사람은 변덕스럽다. 정부 2.0의 비전이 아무리 거창하고 아무리 당위라고 하더라도 시민들이 자신의 밥 벌이가 아닌 일에 성의를 다하여 지속적으로 매달리게 하는 것은 그저 이루어 지는 것은 아니다. 이는 "왜 오픈 인가?"라는 근본적인 질문에 맞닿아 있다. 눈에서 멀어 지면 마음마저 멀어 진다고 하지 않는가? 공개한다는 것은 사람들의 눈에 보이게 하는 것이며 그것도 그냥 겉 껍데기가 아니라 고갱이를 볼 수 있게 하는 것이다. 자기가 볼 수 있는 것이므로 관심이 생기고[각주: 우리는 볼 수 있는 것을 탐한다. (We begin by coveting what we see every day.) 영화 "양들의 침묵" 중 한니발 렉터의 대사.] 잘 되길 바라게 되는 것이고 잘 될 것이라는 전망을 품게 되는 것이다. 그러고 계속 수정된 내용이 공개됨으로써 관심을 유지할 수 있게 되고 내 의견이 (또는 나는 아니지만 나 같은 다른 시민들의 의견이) 반영되고 있다는 뿌듯함을 느끼게 된다. 시늉으로만 구색으로만 공개하고 공개된 데이터가 제대로 관리되지 않는다면 정부 2.0은 전자정부의 성과와 한계를 답습하게 될 것이다.

원리 6: 꼭 같은 것보다 다 다른 것이 더 좋다.[각주: 윤구병의 책 제목에서 무단으로 베낌]

"모든 문제는 누군가에게는 간단할 것이다"

다양성의 중요성은 많은 분야에서 무척 다양한 의미로 제기되지만 여기서도 예외는 아니다. 오픈 소스 소프트웨어 개발에서는 다양성이 특히 문제(즉, 버그)의 발견과 해결에 큰 도움을 준다. 개발자가 아무리 잘 설계해서 프로그램을 만든다고 하더라도 생각지 못했던 측면은 있을 수 밖에 없고 이는 생각지 않은 곳에서 생각지 않은 문제를 일으킨다.[각주: 아무리 완벽한 프로그램에도 버그는 있는 법. (Even a perfect program still has bugs.) (출처: 프로그래밍의 도(The Tao of Programming), http://www.canonical.org/~kragen/tao-of-programming.html ) ] 하지만, 개발자가 테스트하는 환경에서 개발자가 생각해 낸 방식으로만 테스트를 하여서는 그런 문제가 있다는 것을 알아내기는 거의 불가능하다. 수많은 사용자가 각기 다른 환경에서 각기 다른 목적으로 각기 다른 방식으로 프로그램을 쓰는 것 자체가 개발자로서는 흉내조차 내기 힘든 테스트를 해주는 것이다. 또한, 문제를 어떻게든 알아냈다고 하더라도 그 문제의 해결책을 개발자가 찾아내지 못했을 때 다수의 사용자 중 누군가가 쉽게 찾아낼 수 있다. 왜냐하면 다수의 사용자들 중에는 개발자 보다 더 뛰어난 개발자가 있을 수도 있겠지만 그렇지 않더라도 다른 관점에서 문제를 바라보았을 때 의외로 쉽게 문제가 풀릴 수 있기 때문이다.

원리 7: 서비스의 핵심은 데이터다.

"자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다."

아주 간단하게 정의하자면 컴퓨터란 주어진 데이터를 계산한 뒤 결과 데이터를 내놓는 물건이다. 결국 데이터는 컴퓨터 바깥(즉, 사람)과 컴퓨터 안(즉, 프로그램)을 매개한다. 사람은 자신이 원하는 데이터를 얻기 위해서 컴퓨터를 쓰는 것이다. 그 데이터를 얻는 방법이 얼마나 빠른지, 얼마나 편리한지 하는 것은 부수적인 것이다.[각주: 여기서 부수적이라는 것은 그것이 안 중요하거나 덜 중요하다는 뜻이 아니라 그것이 도구의 효율 문제이지 목적은 아니라는 뜻이다.] 따라서 좋은 서비스란 제공할 데이터를 잘 정의하는 것에서 출발해야 한다. 하지만, 많은 서비스가 데이터를 처리하는 틀만 만들어 놓고 막상 데이터를 제대로 채우지 않는 경우가 많다.[각주: 관리가 전혀 안 되는 수많은 게시판을 보라. 몇 년 째 새 데이터가 올라오지 않는 (또는 심지어는 텅텅 비어있는) 자료실은 여러 사이트에서 쉽게 발견되지 않는가?] 정부가 하는 일이 정리된 데이터로서 투명하게 우리의 전자정부를 통해서 공개된다면 전자정부 지수 세계 1위인 동시에 부패지수 세계 39위인 부조화를 해결할 수 있을 것이다.[각주: 김유승, "시민과 쌍방향 소통 '전자정부 2.0'은 필수과목", http://www.hani.co.kr/arti/SERIES/255/435362.html ]

데이터를 중심에 놓고 생각하는 것이 주는 장점 중 하나는 그 데이터를 활용하는 방법을 미리 제약하지 않는다는데 있다. 같은 데이터도 활용하는 사람에 따라 다른 의미로 활용될 수 있다.[각주: 미국의 이라크 침공이 임박했는지 아닌지 알아내는 간단한 방법은? 펜타곤으로 배달되는 피자의 개수를 세는 것이다. 중요한 결정이 임박하면 국방성 직원들은 생각지 않게 자리를 지키고 야근을 해야 하니 자연스레 피자를 많이 배달시킬 것이다. (이 일화는 브루스 슈나이어의 "디지털 보안의 비밀과 거짓말"에서 인용하였음.) ] 거꾸로 그 데이터를 이용해서 어떤 서비스를 어떤 식으로 구현하겠다는 것을 먼저 정해 버리면 그 데이터가 갖고 있는 잠재력을 사장시키게 되는 것이다.

원리 8: 마음부터 열어라.

"좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다."

원시 코드이건 데이터건 서비스건 뭔가를 연다고 했을 때 가장 먼저 그리고 가장 확실히 열어야 하는 것은 여는 사람의 마음이다. 앞에서 살펴본 바와 같이 열어 놓음으로써 발생하는 이득은 외부의 사람들을 내 편으로 끌어들여 그들의 능력을 활용하는 것으로부터 온다. 그런데 만약 내가 그들의 얘기로부터 뭔가 얻어내려는 마음을 갖고 있지 않다면 열어 놓은 것은 아무 소득이 없을 뿐만 오히려 도와 주려고 온 사람들을 적으로 만드는 꼴이 된다.

이렇게 간단한 원리가 왜 실현하기는 어려울까? 그것은 여는 사람이 갖고 있는 우월감 때문이다. "이건 내가 만들었으니까 또는 이건 내 일이니까 내가 제일 잘 알아" 라는 생각을 누구나 하기 마련이다. 하지만 앞의 원리 6에서 지적한 바와 같이 다양한 대중이 갖는 힘이라는 것은 절대 무시할 수 없다.

설령 우월감을 극복한다고 해도 다 되는 것은 아니다. 민감성을 가져야 한다. 외부 참여자들은 대개 이 분야 전문가도 아니고 온 종일 이 일에 매달려 있는 사람들도 아니다. 따라서 그들의 의견은 대개 전문가가 이해하기 힘든 논리에 모호한 언사로 제시된다. 이런 의견 더미 속에서 번뜩이는 아이디어를 찾아내는 것은 열린 마음에 민감성이 결합되었을 때만 가능하다.

원리 9: 최고의 기술은 소통이다.

"프로젝트를 조정하거나 이끄는 사람은 사람들과 잘 의사 소통하는 기술을 가지고 있어야 한다."

앞에서 언급한 열린 마음은 소통을 위한 가장 중요한 자질이다. 하지만 소통이 마음으로만 이루어지지는 않는다. 당연히 소통을 가능하게 하는 도구도 있어야 한다. 하지만, 마음과 도구만으로 소통은 이루어지지 않는다. 왜냐하면 소통은 "사회적 행동이라 그런 것이다. 진정한 소통은 문제의식의 사회적 공유를 전제"로 한다.[각주: 백승종, "소통의 의미", http://www.hani.co.kr/arti/SERIES/202/395531.html ] 개발을 이끌고 나가는 자와 옆에서 참여하는 자 또는 서비스를 제공하는 자와 제공받는 자는 그들이 서 있는 토대가 다르므로 의식의 공유가 어려울 수 밖에 없다. 이를 극복하지 않는 한 (또는 최소한 참여하는 사람들이 문제를 공유하고 있다는 착각을 계속 갖도록 할 수 없다면) 소통은 한계를 겪을 수 밖에 없다.

2. 정부 2.0을 실현하는 도구로서의 오픈 소스 소프트웨어

정부 2.0을 구현하는데 사용하는 도구로서 오픈 소스 소프트웨어가 어떤 역할을 할 수 있는 지를 살펴보자.

오픈 소스 소프트웨어는 정부 2.0을 지탱하는 뼈대다. 정부 2.0은 웹 2.0을 구현의 기반으로 삼고 있고 웹과 웹을 떠받치고 있는 인터넷의 근간에 오픈 소스 소프트웨어가 자리잡고 있음을 고려할 때 오픈 소스 소프트웨어는 정부 2.0을 지탱하는 뼈대라고 불러도 손색이 없을 것이다. 예를 들어, 어떤 사용자가 "모질라 파이어폭스" 웹 브라우저의 주소 창에 어떤 블로그의 주소를 입력하면 이 주소가 실제 인터넷 주소로 어떻게 연결되는지 도메인 이름 서버인 "BIND"에게 물어 봐서 알아내고 그 인터넷 주소에 접속을 하면 "리눅스" 운영체제를 탑재한 "아파치" 웹 서버가 접속을 받아서 블로그용 콘텐트 관리 시스템인 "워드프레스"를 이용해서 블로그 페이지를 보여 준다. 이 문장에서 겹 따옴표 안에 들어 있는 것은 모두 오픈 소스 소프트웨어이다. 즉, 이미 우리는 오픈 소스 소프트웨어로 구성된 웹 세상에 살고 있는 셈이다.

정확한 것은 더 조사가 필요하겠지만 다른 분야보다 유달리 인터넷 또는 웹 분야에서 오픈 소스 소프트웨어가 많이 이용되는 것으로 추측된다. 이는 아마도 인터넷을 키워 나가기 위해서는 필요한 도구를 큰 비용 없이 쉽게 구할 수 있어야 했으므로 인터넷 관련 도구는 오픈 소스 정책을 쓰는 경우가 많았고 또한 오픈 소스 소프트웨어 개발 자체가 인터넷이라는 강력하고 전 지구적인 의사 소통을 전제로 한 것이었으므로 결국 인터넷 또는 웹과 관련한 개발자들이 곧 (초창기) 오픈 소스 소프트웨어 개발자들과 상당 부분 겹칠 수 밖에 없었기 때문이라고 보인다.

그리고 오픈 소스 소프트웨어는 라이선스 비용이 없으므로 정부 2.0을 구축하는데 드는 비용을 줄일 수 있다. 하지만 소프트웨어가 공짜라는 것이 엄청난 비용의 절감으로 곧바로 연결되는 것은 아니다.

"사람들이 오픈 소스 소프트웨어를 볼 때 겉으로 드러나는 라이선스 비용이 없다는 점을 지적하지만 비용은 발생할 수 밖에 없다. 적절한 개발 전략을 정하는 것, 스태프에 필요한 기술을 갖춘 사람들이 있도록 만드는 것, 만든 시스템을 유지하고 관리할 수 있도록 하는 것 등의 노력이 필요하다. '어떻게 구현할까'에 제일 큰 노력이 든다. 결과적으로 기존의 독점적 솔루션에 비하여 60~80% 정도의 비용이 절감된다고 본다." [각주: Bryan Sivak 의 인터뷰 비디오, "Cost is only part of the Gov 2.0 open source story - O'Reilly Radar", http://radar.oreilly.com/2010/08/cost-savings-is-only-part-of-t.html ]

여기서 제일 중요한 점은 인력과 관련된 비용이다. 인력과 관련된 비용은 최소한 두 가지 형태를 가지는데 하나는 개발 과정에 투입되는 인력의 비용이고[각주: 총 개발 비용 (TCD, total cost of development) ] 또 하나는 개발된 결과물을 운용하고 유지하는데 드는 비용이다.[각주: 총 소유 비용 (TCO, total cost of ownership) ] 예를 들어, 어떤 도구가 오픈 소스라서 공짜라고 하더라도 그 도구를 사용해서 개발하거나 그 도구를 유지 보수하는 인력이 귀해서 인건비가 많이 든다면 결과적으로는 더 많은 비용이 발생할 수도 있다. 이러한 인력 수급의 문제는 나라마다 지역마다 다르므로 일반화하여 얘기할 수는 없다. 예를 들어, 한국에서는 대부분의 정보 통신 인력이 마이크로소프트 제품에 익숙하므로 오픈 소스 소프트웨어가 총 소유 비용에서는 더 비쌀 수도 있다는 점에 유의하여야 한다.[각주: (인용자 주: 고성능 클러스터 컴퓨터를 구성하는데 있어) "오픈 소스의 리눅스에 고성능 컴퓨터 솔루션을 탑재하고 관련 인건비를 합한 것과 마이크로소프트사의 솔루션에 관련 인건비를 합한 것을 비교하면 마이크로소프트가 가장 저렴하게 나오는 것이 현실입니다." (페이스 북을 통한 코멘트 중에서 이보성의 의견) ]

정부 2.0을 구현하는데 사용한 코드를 오픈 소스의 형태로 공개를 한다면 한 지방 정부에서 개발한 것을 다른 지방 정부에서 재사용하게 되어 중복 투자를 방지하게 된다.

"어차피 각 지방자치단체는 같은 기능을 하므로 이들 같은 기능을 지원하는 정보 기술 솔루션을 중복되어 개발될 수 밖에 없다. 그 중에는 아주 개발 비용이 많이 드는 것도 있을 수 있다. 따라서, 한 곳에서 개발한 것을 다른 모든 곳에서 재사용 (물론 필요한 만큼 수정한 다음) 한다면 엄청난 비용 절감이 될 것이다."[각주: Bryan Sivak 의 인터뷰 비디오, "Cost is only part of the Gov 2.0 open source story - O'Reilly Radar", http://radar.oreilly.com/2010/08/cost-savings-is-only-part-of-t.html ]

여기서 코드 재사용의 효과는 단지 중복 투자를 막음으로써 비용을 절감하는데 그치는 것이 아니다. 여러 지방 정부가 같은 원시 코드를 공유한다고 하면 그 중 어는 한 곳에서 원시 코드를 개선하였을 때 또는 새로운 기능을 추가하였을 때 다른 모든 곳에서도 그 혜택을 입게 된다. 게다가 하나의 서비스에 사용자가 더 많은 셈이 되므로 더 다양한 측면에서 그 서비스를 평가하고 활용하고 개선할 수 있는 기회가 생기게 된다. 이렇게 공개된 코드는 시민들의 참여를 독려하는 강력한 도구가 된다는 점은 굳이 반복할 필요 조차 없을 것이다.

그런데, 오픈 소스 소프트웨어를 실제로 적용하는데 있어서 일선 담당자들이 두려워하는 점 중의 하나는 문제가 발생했을 때 책임지고 도와 줄 곳이 없다는 점이다. 독점적인 솔루션의 경우 그 솔루션을 공급한 곳에 문의를 하면 되겠지만 오픈 소스 소프트웨어는 문의를 할 수 있는 전화번호도 없고 설령 관련된 메일링 리스트에 문의를 올린다고 해도 대답해야 할 책임을 가진 사람은 없다.[각주: "회사에 와 보니 거의 오픈 소스는 사용을 안하더라구요. (중략) 이유는, 첫째 서포트가 없다는 거지요. 돈 주고 사는 소프트웨어는 문제가 생기면 전화 걸 곳이 있는데 오픈 소스는 그게 잘 없지요. 가끔 돈 받고 서포트를 제공해주는 회사들도 있기는 한데 많은 경우 구멍가게 수준이라 영 따라가지를 못합니다. 상용 소프트웨어는 어떤 때는 엔지니어가 출장 나와서 고쳐놓고 가는 경우도 있으니까요." (페이스 북을 통한 코멘트 중에서 이승의 의견)] 따라서, 실패를 하면 곤란한 정부 시스템에 오픈 소스 소프트웨어를 사용하게 하기 위해서는 정부가 활용하기 위해 개발하는 오픈 소스 솔루션을 책임질 수 있는 형태를 만들어 내는 것이 필요하다.

3. 한국의 오픈 소스 개발자

사실 여부를 놓고는 냉소적인 평가도 많지만 (최소한 광대역 접속망에 관한 한) 한국은 인터넷 강국이다. 하지만 인터넷의 근간을 이루는 오픈 소스 분야에서 한국의 위상은 초라하기 짝이 없다. 오픈 소스 중에서 그나마 한국 개발자들이 공헌을 할 수 있었던 분야는 소프트웨어가 한글을 지원할 수 있도록 개선하는 부분인데 이마저도 소프트웨어의 국제화[각주: 어떤 언어 그리고 그 언어를 사용하는 사람들의 관습을 지원하도록 소프트웨어를 개선하는 일은 크게 둘로 나뉜다. 어떤 소프트웨어가 다양한 언어를 모두 지원할 수 있도록 만드는 것을 국제화(internationalization, 흔히 줄여서 i18n이라고 쓴다)라고 하고 특정 언어와 관습에 맞게 수정하는 작업은 지역화(localization, 흔히 줄여서 l10n이라고 쓴다)라고 한다. 예를 들어, 어떤 소프트웨어가 임의의 글자를 다 표현할 수 있도록 수정하는 작업은 국제화이고 그렇게 국제화된 소프트웨어에 한국어로 된 메시지를 넣고 한글 기준으로 정렬이 되고 돈 표시가 \ 표시로 나오게 하는 것은 지역화에 해당한다.] 가 급속히 진행되어 소프트웨어에 포함된 메시지(예를 들어, 메뉴, 도움말 등)를 한국어로 번역하는 것 이외에는 추가의 노력이 들지 않게 된 상황이라 오픈 소스의 열기가 한국에서 크게 일어나기는 쉽지 않아 보인다. 소프트웨어는 좋은데 한글이 제대로 안되어 답답하면 고쳐서 쓰려고 오픈 소스 소프트웨어 프로젝트에 관심을 둘 수 밖에 없지만 대부분 소프트웨어가 한글을 잘 지원하는 요즘에는 참여해야 할 동기가 발생하기 어려운 것이다.

그렇다고 해서 소프트웨어를 개발하는 일선 회사에서 오픈 소스 소프트웨어와 거리를 두고 있는 것도 아니다. 실은 (정확히 밝혀 낼 수는 없겠지만) 회사들이 독점적인 솔루션인 것처럼 판매하는 것 중에도 실은 "오픈 소스를 참조한 다음 덮어 둔 것"도 있을 것으로 보인다.[각주: 페이스 북의 코멘트 중에서 이경운의 의견] 제법 기술력이 있는 중소 벤처라고 해도 겨우 한 두 개의 자체 개발 솔루션을 갖고 있는 상황에서는 그 솔루션의 "코드 공개가 회사 자산 전부의 유출이라고 해도 과언이 아닌"[각주: 서광열, "달콤하고도 쓴 과일: 오픈 소스", http://skyul.egloos.com/2191344 ] 상황이 되므로 개발의 결과물을 공개한다는 것을 불가능하다. 그나만 자체 솔루션이 없는 회사들은 (최근에는 많이 바뀌었지만) 오픈 소스를 가져다가 포장만 해서 제품으로 팔기도 한다. 그러므로, "오픈 소스의 이용을 공표하는 것은 실상은 그 업체가 자체적인 기술력이 없음을 보여 주는 커밍아웃에 가깝기 때문"[각주: 서광열, "달콤하고도 쓴 과일: 오픈 소스", http://skyul.egloos.com/2191344 ] 에 우리나라의 정보 통신 기업은 자기가 만든 것을 오픈 소스로 내놓을 수도 없고 남의 오픈 소스를 가져와서 개선하였다고 하더라도 공개할 수 없는 형편인 것이다. 물론, 최근에는 솔루션을 납품하는 과정에서 라이선스 문제가 발생하지 않도록 솔루션 개발 단계에서부터 오픈 소스와의 라이선스 관계를 고려[각주: "2~3 년전에 회사에 있을 때, 개발자들이 GPL, LGPL 등 오픈소스 ...프로젝트의 라이센스 사항을 인지하지 못한 채 알게 모르게 제품 소스에 사용하고 있었죠. 현재는 블랙덕이라는 소프트웨어를 사용해서 오픈소스 사용 여부를 체크하고 있습니다." (페이스 북을 통한 코멘트 중에서 박찬진의 의견) ] 하는 정도의 변화가 발전이라면 발전이라 할 수 있을 것이다.

우리나라의 소프트웨어 개발 회사들이 오픈 소스 개발자들을 보유하고 육성할 수 있을 정도로 발전할 수 있다면 무척 바람직할 것이다 왜냐하면 오픈 소스 개발자는 특정 분야에 있어 첨단의 결과물을 다루는 사람일 뿐만 아니라 그가 오픈 소스 개발 프로젝트에 참여하는 과정에서 얻게 된 경험을 회사의 소프트웨어 개발에 활용할 수 있기 때문이다. 우리나라에서도 예외적이긴 하지만 그런 사례가 전혀 없는 것은 아니다. 앞으로 이런 사례가 늘어나길 기대한다.

"그는 사내 제품에 탑재된 오픈 소스 프로그램을 개발하면서 품질을 높이는 일과 더불어 오픈 소스 개발을 해 온 경험을 바탕으로 사내 개발자를 교육 시킨다고 한다. 뿐만 아니라 사내 개발 프로젝트에도 오픈 소스에서 사용되는 방법론을 채용해서 프로젝트를 진행하고 있기도 하였다."[각주: 윤석찬, "오픈 소스 개발자, 그들을 주목하라", http://channy.creation.net/blog/272 ]

만약에 회사 차원에서 오픈 소스에 참여하는 것이 한계가 있다면 개인 차원에서도 참여할 수 있을 것이다. 그리고 오픈 소스 개발에 참여하는 것은 개인적으로도 성취감을 줄 뿐만 아니라 그 프로젝트 다루고 있는 분야에 대한 깊이 있는 지식을 습득하게 되고 한 회사 안에서 일할 때는 배울 수 없는 프로젝트 관리 기법과 의사 소통 기법을 배우는 장점이 있다. 하지만, 회사 일 이외의 시간에 참여하는 것도 한국의 상황에서는 쉽지 않다. 세계 최장의 노동 시간을 자랑하는 한국에서도 소프트웨어 개발자들은 특별히 더 과로에 시달리고 있는 편이라 따로 시간을 내는 것이 거의 불가능하다고 보아야 한다. 이런 점에서 본다면 여가 시간에 소프트웨어 개발에 참여해서 세계적인 명성을 쌓는 해외의 개발자들은 부러움의 대상일 수 밖에 없다.

여기에 우리나라 개발자들이 갖고 있는 소양의 문제도 한 몫을 한다. 오픈 소스 소프트웨어 개발 프로젝트에서 대부분의 의사 소통이 영어로 이루어지므로 아무래도 언어의 장벽이 부담이 되긴 하지만 그것만 문제는 아니다. 우리나라의 개발자들이 의사 소통 능력이 떨어져서 협력해서 개발하려 하지 않고 혼자 풀어 가려는 성향도 있고[각주: "대부분의 개발자가 다른 개발자와의 의사소통을 힘들어한다. 어렵게 시작한 국내 오픈 소스 프로젝트도 다른 개발자의 도움을 받는 일이란 극히 드물다. 개발자들은 의사소통이 어려워서 기존의 프로젝트에 참여하기보다는 자신만의 새로운 프로젝트를 만드는 쪽을 선호한다." 서광열, "달콤하고도 쓴 과일: 오픈 소스", http://skyul.egloos.com/2191344 ] 다른 개발자의 프로젝트에 참여하고 독려하기 보다는 부정적인 반응을 보이는 경우도 많다[각주: "실제 개발에 도움되는 패치 한 줄이라도 보내주는 사람은 하나도 없고, 기껏 가뭄에 콩 나듯이 버그 리포팅이랍시고 하는데 그게 다 불평이에요. 같은 말이라도 좀 이쁘게 하면 참 좋을텐데... 꼭 왜 프로그램을 그 따위로 만들어놨냐 하는 식이죠." KLDPWiki, "한국에서 오픈소스 하기", http://wiki.kldp.org/wiki.php ] 고 한다.[각주: 정말로 우리나라 개발자들이 유독 이런 문제를 갖고 있는지는 별도의 조사가 필요하겠지만 만약 이것이 사실이라면 일방적이고 주입식인 교육, 협력보다는 경쟁을 가르치는 교육이 그 원인이 아닐까 하는 생각이 든다. ]

4. 한국에서의 소프트웨어 개발 현실과 정부 2.0에 거는 기대

소프트웨어 개발은 서로 상충하는 목표 사이에서 균형을 찾아내는 예술이다. 여기서 상충하는 목표는 예를 들면 다음과 같다.[각주: Ronald E Jeffries, "The Four Variables", http://xprogramming.com/Practices/PracFourVariables.html ]

  • 범위 – 무엇을 개발할 것인가 즉, 구현할 기능의 범위
  • 품질 – 얼마나 정확하게 그리고 그 외 바람직한 특성[각주: 예컨대, 같은 기능을 구현했다고 하더라도 훨씬 효율이 높게 동작한다거나 원시 프로그램이 깔끔하여 나중에 수정하기 쉽다거나 하는 등의 특성] 을 갖게 개발할 것인가
  • 자원 – 투입되는 인력이나 장비 등은 얼마나 되는가
  • 기간 – 프로젝트의 총 기간은 얼마인가

이들 네 목표는 팽팽한 균형을 이루고 있어 다른 목표를 건드리지 않고 한 목표만 바꿀 수 없다. 예를 들어, 구현할 기능을 추가하려면(범위의 변화) 사람을 더 투입하던지 기한을 늦추던지 아니면 다른 기능을 대충 만들 수 밖에 없다. 하지만 사람의 욕심이라는 것이 더 많은 기능을 더 좋은 품질로 돈은 덜 들이고 더 빨리 얻고 싶은 것이다. 그래서, 실제로는 고객에게 잘 보이는 목표는 상향 조정하고 대신 보이지 않는 목표는 하향 조정하게 된다.[각주: 겉만 번지르르 하고 제대로 동작하지 않거나 이용자의 인내력을 시험하는 서비스는 대개 이런 식 개발의 결과물이다.] 이런 현상은 전 세계 어느 곳에서나 반복적으로 일어나고 있다.

하지만, 한국에는 여기에 최소한 두 가지 심각한 문제점 즉, 일방적 희생을 강요하는 혹독한 하청 체계노가다식 비용 산정 방식이 추가된다.

한국에서의 소프트웨어 개발 프로젝트는 다른 산업 분야에서의 하청 관행이 그대로 적용되며 하청 시스템이 갖고 있는 온갖 문제점이 정확하게 재연된다. 흔히 '을'이라고 부르는 원청업체가 수익의 대부분을 가져가므로 '병' 또는 '정'이라고 불리는 하청업체는 늘 턱없이 적은 비용으로 개발을 하게 되며 따라서 대개 턱없이 부족한 인력이 투입되고 그 결과 엄청난 초과 근무로 이어진다. 심한 경우라고 하더라도 "경제협력개발기구(OECD) 평균 연간 근로시간이 1768시간인데, 단 5개월 만에 나는 2000시간 이상을 일했다"라는 주장이 그럴싸하게 들린다는 것은 실로 어처구니 없는 현실이다.[각주: 이대희, "사람 잡는 야근… 폐 잘라낸 SI개발자", http://www.pressian.com/article/article.asp?article_num=30100817171744] 게다가 '을'의 낙점을 받지 않는 한 프로젝트에 참여할 수 없는 '병'이나 '정'은 '을'의 무리한 요구도 거절 할 수 없게 된다. 한국에서의 소프트웨어 개발의 실태는 다음의 인용문이 잘 보여 준다.

평일 근무: 가능하면 경조사가 아니면 식사 후 오후 10:00까지 근무 부탁 드립니다.
주말 근무: 토요일은 가능하면 경조사가 아니면 오전 10:00 ~ 오후 6:00까지 근무 부탁 드립니다. 일요일은 고객과 함께하는 특별한 Task를 제외하고는 휴식이 좋겠지요. 허나, 시간이 없네요. 미진한 파트나 개발자는 어쩔 수 없이 잔여 Task 마무리를 위해 근무 부탁 드립니다.[각주: 클리앙의 게시물 중에서, "SI개발자인데 오늘 '을'한테 받은 메일 내용 중 일부 발췌", http://clien.career.co.kr/cs2/bbs/board.php?bo_table=park&wr_id=2746174]

이렇게 초과 근무를 요청하는 것이 당연시 될 뿐만 아니라 비용에 대하여도 무리한 요구를 하는 경우가 비일비재하다.

"일반적인 시스템 통합 견적은 '개발비 + 장비 가격'으로 되어 있고, 각각에 대해서 세부 내역을 제출하게 됩니다. 즉, 어떤 것을 공급 하느냐 하는 점도 기술 점수에 반영됩니다. 오픈 소스 소프트웨어에 대한 수요자의 인식, 아직 쉽지 않은 상황이죠. 오픈 소스 소프트웨어를 사용해서 저가 입찰에 성공하더라도 협상 과정에서 그 품목만 바꿔 달라는 (인용자 주: 유료 제품으로 바꿔 달라는 뜻) 경우도 있죠. 금액은 변동 없이" [각주: 페이스 북을 통한 코멘트 중에서 우항준의 의견]

이러한 하청, 재하청에 의한 개발은 오픈 소스 소프트웨어의 도입을 통한 비용 절감을 불가능하게 한다. "갑 – 을 – 병 – 정 – …"으로 이어지는 먹이사슬은 각 단계마다 수익이 발생해야 유지될 수 있다. 그런데 소프트웨어 개발 프로젝트 비용은 인건비와 개발에 활용되는 솔루션 비용이 대다수를 차지하는데 인건비는 투입되는 인력만큼 받는 것이므로 큰 수익이 발생하기 어렵고 결국 솔루션 비용에서 수익을 발생시켜야 한다. 따라서, 솔루션을 오픈 소스 소프트웨어를 쓰게 되면 국가 전체적으로는 비용이 절감되는 효과가 생기겠지만 프로젝트를 진행하는 쪽에서는 스스로 수익을 갉아먹는 꼴이 되므로 오픈 소스 소프트웨어를 적용하기가 더욱 어려워 진다.[각주: 페이스 북의 코멘트 중에서 이경운과 박충규의 의견]

혹독한 하청체계에 의한 수탈구조를 더욱 악화시키는 것은 촌스런 소프트웨어 개발 비용의 산정 방식이다. 우리나라의 소프트웨어 개발 비용은 철저하게 (투입되는 사람의 수 x 투입되는 기간 x 단가)로 결정된다.

공공 기관, 대기업을 막론하고 소프트웨어 단가는 모두 예전에 만들어 놓은, 소위 '과기부, 정통부 단가'에 따라 비용을 산정한다. 설상가상인 것은 용역 프로젝트라며 지적 재산권까지 내놓으라고 한다.[각주: 김홍선, "소프트웨어 개발 단가 산정이 한심한 이유", http://ceo.ahnlab.com/84]

이렇게 투입되는 사람의 능력을 고려하지 않는 계산 방식에서는 실력이 없는 사람(즉, 월급을 덜 줘도 되는 사람)을 투입하면 할수록 수익은 커진다. 물론 전혀 실력이 없는 사람(속칭 '허수아비')으로만 개발 팀을 구성하게 되면 결과물을 내놓을 수가 없으므로 실제로 개발을 담당하게 되는 실력 있는 몇 사람을 포함시키고 개발 부담은 거의 이들에게 집중된다. 원래 소프트웨어 개발 (또는 시스템 개발) 그 중에서도 특히 설계와 관리를 담당하는 시스템 엔지니어링은 인간, 경제, 기술의 측면을 동시에 고려하는 종합 예술로서 선진국에서는 최고의 직업으로 손꼽힌다.[각주: Focus Editor, "The Best Jobs In America", http://www.focus.com/fyi/human-resources/best-jobs/] 하지만, 실력이 있는 사람이나 없는 사람이나 열심히 하는 사람이나 자리만 채우는 사람이나 다 똑같이 평가되는 체계에서 창의성과 열정이 넘치는 젊은이들이 일하기를 바라는 것은 어불성설이다.

4. 정부 2.0은 새로운 기회일까?

이상으로 정부 2.0이 갖고 있는 비전과 오픈 소스가 우리에게 준 새로운 가능성 그리고 한국의 현실이 이러한 비전이나 가능성과 얼마나 동떨어져 있는지 살펴보았다. 우리가 원하건 원하지 않건 정부 2.0은 우리에게 현실로 다가오고 있는 현 상황에서 정부 2.0이 가져올 기회와 위험성을 소프트웨어 서비스의 관점에서 살펴보는 것으로 이 글을 마무리하고자 한다.

정부 2.0이 기존의 소프트웨어 개발 관행을 바꿔 놓고 그래서 창의적인 개발자들을 끌어들이게 될 것인가? 어느 정도는 그럴 것이다. 정부는 그저 데이터를 제공하고 다양한 서비스가 공존할 수 있는 플랫폼만을 제공하고 시민들이, 개발자들이 스스로 서비스를 개발하는 구조는 정부가 개발 프로젝트를 발주하고 이를 큰 회사들이 수주하여 하청, 재하청하는 현재의 구조와는 전적으로 달라질 수 밖에 없다. 오히려 아이디어를 내고 바로 개발에 착수할 수 있는 개인 개발자, 초소규모 회사들이 더 유리할 것이다. (고등학생이 만들었다는 아이폰 용 버스 시간 안내 프로그램 "서울버스"가 전형적인 예) 또한 개발 과정에서 정부가 오픈 소스를 장려한다면 (예를 들어, 정부에서 돈을 받아 개발한 결과물은 원칙적으로 공개하는 것을 고려할 수 있다) 그런 오픈 소스를 잘 이해하고 빨리 활용할 수 있는 능력 있는 개발자들이 대우받게 될 것이다. 물론 이런 희망 섞인 기대는 오픈 플랫폼 위에서 공정한 경쟁이 이루어졌을 때만 실현될 가능성이 크다. 그런 점에서 정부가 제공하는 정부 2.0이라는 플랫폼은 단지 서비스를 만들어 내는 플랫폼이 아니라 정해 진 규칙에 따라 공정한 경쟁이 이루어지게 하는 법적 제도적 장치를 포함하는 개념이 되어야 할 것이다.

정부 2.0이 성공적으로 실현된다면 수요와 공급이 시장의 원리에 따라 조화를 이루어서 좋은 서비스가 많이 생겨나고 시민들은 서비스를 더 편리하게 그리고 이전에는 상상조차 할 수 없었던 세심한 서비스까지 활용할 수 있게 될 것이다. 하지만 그게 다인가? 그렇지 않다. 정부 2.0은 "국가중심의 거버넌스와 시장적 거버넌스를 극복하는 시민사회적 거버넌스 또는 참여적 거버넌스"를[각주: 김유승, "시민과 쌍방향 소통 '전자정부 2.0'은 필수과목", http://www.hani.co.kr/arti/SERIES/255/435362.html] 추구하는 것인데 자칫 플랫폼으로서의 정부까지만 얘기하고 그 플랫폼을 시장의 논리에 맡겨 두기만 한다면 서비스 이용에 있어서 상대적인 약자들(예를 들어, 활용할 수 있는 기기를 구매할 능력이 안 되는 사람, 활용하는 능력이 부족한 사람, 외국인 등)을 서비스로부터 배제될 수 밖에 없다. 서비스를 개발하는 사람은 자기 서비스를 가장 많은 사람들이 활용할 수 있도록 하기 위하여 "서비스를 많이 활용하는 사람", "(유료 서비스라면 특히) 서비스로부터 많은 이득을 얻는 사람"에게 맞춰서 개발을 하게 된다. 이런 현상은 한편으로는 서비스의 획일화를 가져오고 다른 한편으로는 가진 자와 없는 자 사이의 격차를 더 키우는 결과를 낳을 수도 있다. 게다가, 노약자나 장애자의 경우 서비스의 사각 지대에 놓일 수 있다.[각주: 현재의 스마트 폰 응용 프로그램 시장이 그런 모습을 보인다. 정보 통신 기기를 잘 다룰 수 있고 그러한 기기를 통하여 얻은 정보를 자신의 업무에 활용함으로써 생산성을 높이고 더 많은 수익을 낼 수 있는 사람을 대상으로 삼고 프로그램이 개발되고 있는 실정이다.] 이러한 문제를 접근성, 보편성의 문제로 풀어 나가는 장치가 반드시 수반되어야 할 것이다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by 신묘군

티스토리 툴바