jasu's blog

오랜만에 평택을 다녀왔다.
전날 가족회의를 한다는 어머니의 말씀을 듣고 토요일 저녁에 내려가려고 한 것이 하던 일을 마무리 하다 보니 아침이 되어서야 차를 몰고 평택으로 내려갔다.

항상 느끼는 거지만 서울에서 생활하다가 가끔 평택을 내려가면 공기가 다른 느낌을 받게 된다. 서울에서 평택까지의 거리는 그리 멀지 않은 거리임에도 불구하고 평택의 공기는 서울과는 다르다.

잠을 못자고 내려간 터라 들어가서 노트북을 켜놓고 잠들어 버렸다. 얼마나 잤을까 조카 태규의 목소리에 시끄러워 잠에서 깨어보니 청주에서 어머니와 누나 조카들이 집에 와있었다. 고향 집은 평택이지만 어머니는 청주에서 일을 하시고 누나는 결혼 후 청주에서 살다 보니 우리 가족의 제 2의 고향은 청주가 되었다.

오랜만에 식구들이 모두 모여서 밥을 먹고 이야기를 나누었는데 1년 사이에 아버지의 건강이 많이 안 좋으신 듯하다. 평생 농사를 지시고 무모한 사업보다 안정적인 농사일을 평생 하시고 사셨는데 이제 건강상의 이유로 내년부터는 모든 농사를 하지 않으실 듯 싶다.

여럿을 때는 부모님이 시켜서 어쩔 수 없이 농사 일을 도와드렸는데 머리가 크고 내 생활들이 늘어나면서 반항을 했던 나였다. 지금은 그 때의 내 행동에 많은 후회를 하고 있지만 그 당시는 나의 성장과정에서 어쩔 수 없이 겪게 되는 과도기였다는 생각이 든다. 그 이후로 아버지는 자식들에게 농사일을 도와달라는 말을 하지 않으셨다.

여럿을 때는 하루가 멀다 하고 부모님 싸우는 소리에 우울했던 것 같다. 어린 마음에 그렇게 서로 싸우고 힘들어 하면서 왜 같이 사시는지 하는 의문을 갖기도 했었다.

우리 아버지는 정이 많으시고 말 수가 없으시며 무모한 일을 벌리지 않으신다. 그런 반면 어머니는 외향적이시고 말이 많으시며 확신이 서는 일에 대해서는 추진하는 성격을 가지고 계시다. 그러다 보니 서로 의견이 맞지 않는 경우가 많이 발생하는데, 난 그때 마나 조금은 어머니 편에 서게 되었던 것 같다. 그 이유는 항상 크게 싸우는 날은 아버지가 술을 드시고 오신 날이었고 싸우는 내용을 들어보면 시시콜콜 어머니의 말이 옳은 것 같은 생각이 들었기 때문이다. 지금 생각해 보면 그때 무엇 때문에 싸우셨는지 어떻게 타협을 보셨는지 기억은 나지 않지만…

그런 두 분의 성격으로 인해서 아버지는 평생을 농사일을 하시며 사셨고 어머니는 시장에서 난전 장사도 하시고 돼지와 같은 가축을 키우시기도 했는데 그 때만 해도 집이 찢어지게 가난했던 때라 어머니는 니어카를 가지고 시내(집에서 시내까지는 걸어서 40분정도의 거리었다)에 가서 음식점에서 버리는 짬들을 모아서 돼지를 키우시기도 했다. 한 여름에는 그런 어머니를 도와주겠다며 뚝에 가서 어머니가 올 때까지 기다리기도 했던 기억이다.

내가 어릴 때는 어머니가 상당히 엄하셨다. 부유한 가정에서 태어나 아쉬운 것 없이 사셨던 어머니였는데 옛날에는 여자라는 이유만으로 학업을 포기해야 하는 경우가 상당히 많았다고 한다. 어머니도 할아버지의 반대로 인하여 고등교육을 받지 못한 한을 항상 가지고 사셨다. 그 전까지만 해도 어머니는 다른 남아들보다 공부를 잘 하셨다고 한다. (확인할 수 있는 방법이 없으나 자식으로서 믿는다 ^^)

그래서 그러셨는지 내가 초등학교 4학년 때 까지만 해도 방학이 되면 항상 아랫목에 이불을 놓고 식구들이 뺑 둘러 앉아서 책을 보거나 어머니가 정해놓은 분량까지 문제집을 풀거나 수판을 놓고 어머니가 불러주시는 숫자를 더하고 곱하는 일상 속에 살았다.

성적이 떨어지면 어머니에게 호되게 혼이 나기도 했는데 어느날은 집에 오는 길에 동네 어느 집에서 불이 난 것이다. 소방차가 와서 불을 끄고 있는 것을 구경하다가 집에 도착하는 시간이 늦었다. 어머니는 문제집을 가지고 기다리고 계셨고 들어오자마자 늦게 온 나를 혼내시기 시작하셨다. 그도 그럴 것이 어머니께서 풀어놓으라는 문제집이 있었는데 그 문제집의 답안을 보고 머리를 써가며 중간중간 틀린 답을 넣기도 하며 베껴놓았던 것이다. 답안 중에 답이 길어 “생략” 이라고 되어 있는 답까지 그대로 베껴놓았던 터였다. 이를 어머니가 눈치 채셨고 그 문제로 단단히 혼내시려고 기다리셨던 것이다. 그날 하필 동네에 불난리가 날게 뭐람…쿠쿠 그래도 불 구경은 재미났던 기억이다.

이렇게 어머니는 공부에 대해서는 상당히 엄하셨는데 내가 초등학교 5학년쯤에 손을 놓으셨던 것 같다. 어느날 학교에서 우수상을 받고 어머니에게 칭찬 받을 생각에 날듯이 좋아하며 집으로 달려왔는데 어머니는 일을 나가시기 위해 준비를 하고 계셨는지 내가 보여드리는 상장을 보시고도 별로 칭찬을 하지 않으셨던 것 같다. 그때 만약 어머니께서 많은 칭찬을 하셨다면 그 칭찬의 힘은 지금의 나 보다 더 사회적으로 바람직한 회사원이 되지 않았을까 하는 생각도 해보았다. ^^;

아버지는 공주 출신으로 말수가 없으시고 말이 느리신 전형적인 농부시다. 우리집의 일보다 이웃들의 일들을 먼저 챙겨주고 부당한 대우를 받으셔도 큰 노여움 없이 궁글게 살아오셨다. 농사라는 것이 바쁠 때는 한 없이 바쁘지만 일이 없을 때는 동네 사람들과 어울려 술을 마시거나 소일거리로 시간을 보내게 된다. 일을 하실 때면 술 기운에 일을 하셨고 그러다 보니 건강이 많이 안 좋아지신 듯 싶다.

저녁쯤에 누나와 조카들 그리고 어머니는 청주로 내려가셨고 집에는 형과 나, 그리고 아버지만 남게 되었는데 우리집 남자들은 말수가 없어서 같은 지붕 아래에 생활하고 있어도 하루에 몇 마디도 하기가 힘들다.

저녁을 먹고 서울로 올라간다며 아버지와 형에게 이야기를 하고 나와서 차에 시동을 켜고 앉아 있는데 불이 켜진 거실 창문에서 한참동안 나를 바라보고 계셨다. 그 모습을 보면서 말 한마디 사는 이야기 하지 못하는 과묵한 내가 불효자라는 생각이 들었다. 몸이 안 좋아 지시면서 더욱 쓸쓸해 보이시는 아버지에게 제대로 된 이야기 한번 나누지 못하고 다시 올라가는 것이 많이 죄송스러웠다…

이제는 혼자 생활하는 것이 익숙해져서 오래도록 떨어져 있어도 가족에 대한 그리움 마저 잊고 사는 것 같다. 앞으로는 좀더 노력해야 겠다는 생각을 하게 되는 밤이다.

몇 달 전 지인 중 한 명이 갑작스럽게 전화를 하였다. 구글 본사에 취업을 하게 되어 출국장에서 제 생각이 나서 안부는 전하고 가야겠기에 연락을 했다고 한다. 그 전화를 끊고 나서 한편으로 부럽다는 생각이 들었다. 누구나 근무하고 싶은 세계 최고의 전도 유망한 좋은 회사와 창의적인 업무 환경, 미국 서부의 좋은 날씨, 그리고 가족들에게 좋은 교육 환경까지 제공할 수 있다고 생각이 들었기 때문이다.

오후에 미국에 있는 또 다른 지인과 채팅을 하면서 이런 저런 이야기를 했더니, 오히려 그는 미국 생활 이란 것이 매우 척박한 삶이라면서 나를 위로 하였다. 구글 본사는 밖에서 보는 만큼 그렇게 낭만적이지 않으며 워크 홀릭의 땅이니 너무 부러워하지 말라는 충고였다.

정말 구글은 개발자들에게 낭만적인 곳인 걸까? 필자도 세 번 정도 구글을 다녀왔었지만 외견상으로는 멋진 업무 환경과 엔지니어를 위주로 하는 회사 정책 등 개발자들에게 희망을 주는 곳이라고 말할 수 있을 것이다. 그 중에도 가장 널리 알려진 20% 프로젝트 제도가 있다. 이 방식은 현업 외에 창의적인 일을 할 수 있다는 개발자들에게 동경의 대상이 되는 제도 이다. 실제로 구글 개발자들은 개인 업무의 20%를 자신이 원하는 프로젝트에 시간을 투입할 수 있다. 일주일의 하루든지 일년에 두 달이든 그건 스스로 정할 수 있다.

구글의 독특한 문화, 20% 프로젝트
기술 기반 회사에서 개발자들에게 자신의 창의력을 발휘할 시간적 기회를 준다는 것은 매우 중요하면서도 필요한 일이다. 하지만 실천하기는 매우 어려운 일이기도 하다. 그러나 구글의 개발 방법론은 외견상으로 크게 성공을 했고, 최근에 나온 많은 혁신적인 서비스와 프로젝트들이 나오게 된 밑거름이 되었다.

어떤 구글 직원의 이야기에 따르면 구글의 20% 프로젝트는 다음과 같이 진행된다고 한다.

(중략)…만약 자기가 하려는 일이 아직 프로젝트가 돼 있지 않다면 ‘아이디어 마켓’에 자신의 아이디어를 올리면 된다고 했다. 이 아이디어에 일정 수 이상의 다른 직원이 좋은 아이디어라고 동의하면 ‘20% 프로젝트’가 된다고 설명했다…(중략)… 이 후 ‘20% 프로젝트’가 어느정도 성과를 거두고 더 큰 자원(서버, 네트워크, 마케팅 등)이 필요하다고 판단되면 임원에게 보고하고 정식 프로젝트로 승격되는 과정을 거친다. 정식 프로젝트로 승격되면 이 프로젝트는 이제 ‘80% 프로젝트’가 된다는 것이다.

‘80% 프로젝트’는 임원들의 승인을 거친 아이템으로 시장에 서비스로 출시되는 것을 염두에 두고 하는 프로젝트이다. 구글의 서비스 런칭 단계는 따라서 ‘아이디어 마켓’→ ‘20% 프로젝트’ → ‘80% 프로젝트’ → ‘상품화’ 등으로 이어진다는 설명이다. 그는 구글의 이러한 독특한 문화를 설명하면서 “구글은 직원들간에 자유로운 정보유통과 더불어 함께 일구는 문화가 잘 구축돼 있다”며 “그런 경쟁력이 지금의 구글을 있게 한 밑거름”이라고 분석했다…(후략) 구글 직원이 소개하는 독특한 ‘구글 기업문화’, 정종오 기자, 아이뉴스

참 재미있는 서비스 설계 구조라고 할 수 있다. 소위 전략, 기획을 담당하는 사업 부서 혹은 부서장의 의지에 따라 사업이 추진 되는 데, 비해 Bottom-up 방식의 민주적 의사 결정에 의해 서비스를 만든다는 것이다. 통상 일반적인 회사 체계를 가지는 곳에서는 이해가 가지 않는 이 방식이 구글에서는 어떻게 가능한 것인가 몇 가지 살펴 보았다.

1. 시장 경쟁 지향 프로젝트 환경을 제공한다.
우선 구글은 진짜 개발자들에게 20%의 시간을 준다. 구글 코드 서비스를 담당하고 있는 그레그 스타인(Greg Stein)에 따르면, 모든 개발자들이 접근할 수 있는 기반 플랫폼을 기초로 하여 3~4명 단위의 소규모 프로젝트(20% 프로젝트)가 천여 개 이상 진행되고 있다고 한다. 구글의 개발자들은 그 가운데 스스로 성공 가능성이 높은 프로젝트를 선정하고 경영자들의 승인 아래 더 많은 사람이 프로젝트에 투입 되도록 문호를 개방 한다. 이 말은 결국 선택 받지 못하는 프로젝트는 스스로 도태된다는 것을 의미한다.
얼핏 보기에는 프로젝트 추진에 대한 민주적 의사 결정처럼 보이지만, 실제로는 약육 강식, 자연 도태의 환경과 비슷하다고 볼 수 있다. 창의성 높은 프로젝트가 계속 계발 되는 동시에 이 와중에서 심각하고 과도한 경쟁을 유발한다는 이야기이다.

실제로 구글에서는 한해 추진된 20% 프로젝트 중 가장 뛰어났다고 생각되는 것에 백만 불을 상금으로 주는 제도도 있다고 한다. 필자가 구글에 방문할 때마다 오후 늦은 시간이었다. 실리콘 밸리이긴 하지만 퇴근 시간이기 때문에 101번 고속도로가 체증을 일으키고 있었지만 구글은 저녁 식사 후에도 여전히 사무실 불을 밝히고 있는 몇 안 되는 곳 중에 하나다. 마치 연구에 몰두 하는 대학 캠퍼스를 연상하게 한다.

2. 똑똑한 워크홀릭이 주류여야 한다.
구글에 입사하기 위해서는 꽤 까다로운 절차를 통과해야 하는 것으로 유명 하다. 구글이 후보자를 면접 하는 중에 가장 중요하게 보는 덕목이 ‘자기 주도적’인 사람인가 하는 점이라고 한다. 실제로 그 변덕스럽고 이해할 수 없는 절차를 통과한 사람은 정말 구글에 대한 열정이 높고 자기 주도적인 사람이 아니라면 어려울 것이다. 면접 과정에서 그 치열하고 어려운 기업 문화를 미리 느껴 볼 수 있으니까. 이런 이면에는 기업의 성장에 ‘무임 승차(Free Riding)하는 사람을 배제’ 하는 것이 그들의 첫 번째 인재 정책이라고 할 수 있다.

특히 구글에는 아주 똑똑한(Smart) 사람이 많다. 존 버틀러의 “The Search”에 따르면, 2002년 중반 실리콘 밸리 침체기에도 구글의 성장과 독특한 천재 예찬론을 기초로 아이비 리그 출신들의 석박사급 인재를 많이 충원을 했다. 현재는 좀 완화되기는 했지만, 학교와 학점(GPA)과 학위를 중시하는 것은 여전하다.

구글에는 소위 카스트 제도라고 불릴 정도로 똑똑한 엔지니어 위주의 인재 정책을 펴고 있다. 실력이 뛰어나고 이름 있는 공개 소프트웨어 분야의 수 많은 엔지니어들이 구글로 자리를 옮겼다. 특히, 최근에 아이디어와 끼가 넘치는 3~4인 정도의 웹2.0 스타트업 기업들도 대거 인수하여 인재를 확충하고 있다. 이들에게 자기 성취를 할 수 있는 업무 여건 및 경쟁 환경을 도입하는 것은 불 붙은 곳에 기름을 끼얹는 것이나 다름이 없다.

3. 경영자의 절대 권력이 존재해야 한다.
구글은 성공 가도를 달리기 시작하던 2002년말, 래리 페이지와 세리게이 브린은 그들의 조직 구조를 ‘위계형’에서 ‘수평형’으로 바꾸고 80:20 프로젝트를 도입했다. 이 때 부터 상위 100개 프로젝트 목록이라는 것이 있었다고 한다. (지금은 없어지고 사업 분야별로 각자 목록을 가지고 있지만) 페이지와 브린은 여전히 그 프로젝트 목록을 살피고 투입해야 될 프로젝트에 대한 의사 결정을 한다.

‘똑똑한 워크홀릭’들이 절대 권력을 행사하는 경영자의 판단에 따라 신데렐라가 될 수 있다는 기회 때문에 이 프로젝트의 창의성과 혁신성은 더 높아지고 있다. 이런 특징은 마이크로소프트의 빌 게이츠나 오라클의 래리 엘리슨, 애플의 스티브 잡스 등 경영자이면서 오너인 회사에서는 두드러진다. 빌 게이츠는 일년에 두번 모든 직원들이 올린 보고서를 읽어 보는 씽크 위크를 가지고, 일반 사원들의 의견까지도 수렴하고 있다. 이것은 경영자이면서 오너인 사람은 똑똑하다는 가정하에 기업의 성공 가능성이 매우 높다고 할 수 있다.

많은 기업들이 구글의 20% 프로젝트에 감명을 받고 비슷한 제도를 만들어 볼까 고민한다.하지만 대부분의 회사들이 위의 조건들을 충족하지 못할 것이다. 이런 제도를 도입 하기 전에 자신의 조직에 정말 적합한 제도인지는 한번 돌아볼 필요가 있겠다. 구글의 20% 프로젝트의 성공이 우리에게 시사해 주는 바는 엔지니어의 창의성을 담보해 주면 기술 경쟁에서 장기적으로 유리한 고지를 점할 수 있다는 점이다. 이런 원칙을 기초로 자신의 회사에 적용할 방법을 찾는 것이 좋겠다

출처 : 윤석찬 (다음 R&D 센터 팀장)

스티븐 스필버그 감독은 영화 <뮌헨>을 발표한 후 알고 지내던 유태인 친구를 여러 명 잃었다고 고백했다. 영화 속에서 주인공은 이스라엘 정보기관 모사드의 도움을 받아 폭탄 제조, 문서 위조, 사건 뒤처리 등의 다양한 재주를 가진 6명의 요원으로 팀을 구성한 다음, 1972년 뮌헨 올림픽 선수촌에서 테러를 일으킨 검은 9월단의 배후 요원들을 한 명씩 살해한다.

하지만 시간이 흐르면서 주인공을 비롯한 요원들은 국가를 위한 복수와 비인도적인 살인 행위 사이에서 갈등을 겪게 되고 스스로의 생명마저 위협받자 깊은 회의에 빠져들게 된다. 스필버그 감독은 인간적인‘갈등’과‘회의’를 그렸을 뿐인데 열혈 유태인들은 그것조차 용납하기 어려웠던 모양이다.

아무튼 영화 속의 주인공은 복수의 대상 11명이 은거하고 있는 장소와 그밖에 필요한 정보를 얻기 위해서 일종의‘정보 브로커’와 거래를 한다. 그에게 거액의 돈을 주고 살해할 대상이 숨어 있는 장소에 대한 정보를 얻는 것이다. 재미있는 점은 주인공의 복수가 진행되는 동안 다른 나라의 정보조직에서도 똑같은 정보 브로커에게 접근해서 주인공과 동료들의 신원을 파악하려고 한다는 점이다. 이름도 없고, 얼굴도 없어서 어느 누구에게도 존재가 드러나지 않아야 하는 정보조직 세계의 요원들이 이렇게 ‘정보 브로커’라는 존재를 통해서 오히려 하나의 지점에서 만나는 현상이 벌어진다.


상황중심이란 개념 이해하기    

이렇게 다양한 독립적인 개체들이 자신의 목적을 위해서 공통적으로 통과할 수밖에 없는 지점, 혹은 수행할 수밖에 없는 행동을 상황중심 프로그래밍(Aspect Oriented Programming)에서는 접점(join point)라고 부른다.‘ 상황중심’이란 요즘 프로그래밍 세계에서 주목을 받고 있는 ‘Aspect Oriented’라는 표현을 나름대로 우리말로 옮겨본 것이다.‘ Aspect Oriented’라는 말이 국내에서는‘관점 지향’이라는 말로 표현되기도 하는데, 이것은 그 동안 ‘Object Oriented’를‘객체 지향’이라고 불러온 관성의 영향인 것으로 생각된다.

사실‘관점 지향’이라는 말은 의미가 분명하지 않을 뿐만 아니라 겉으로 드러나는 의미조차 정확하다고 보기 어렵다. ‘관점’을‘지향’한다니? 프로그래밍을 수행하는 사람이 자기 관점을 분명히 세우고 그것을 목표로 전진하라는 말인가?‘ 관점 지향’이라는 말이 국내 프로그래머 사이에서 일정한 합의를 이루고 있는 표현이라면 어쩔 수 없지만, 최소한 이 글에서는‘Aspect Object’를‘상황중심’으로 표현하고자 한다. 이렇게 해야 새로운 방법론이 전하고자 하는 의미가 분명하게 드러나기 때문이다.

상황중심 프로그래밍은 말 그대로 현재의 소프트웨어 코드가 처해 있는 특정한‘상황’에 초점을 맞추는 프로그래밍을 의미한다. 폭발적으로 늘어나는 수요를 감당하지 못해 심각한 위기를 맞이했던 소프트웨어 개발시장은‘모듈(module)’과‘객체(object)’라는 혁명적인 개념을 발견하면서 위기를 극복했다. 방대한 분량의 소프트웨어 코드를 모듈과 객체라는 작고 독립적인 부분으로 분리할 수 있었기 때문에 프로그래머들은 점점 더 복잡한 업무를 수행하는 코드를 만들어 낼 수 있었던 것이다. 하지만 독립적인 모듈과 객체의 수마저 기하급수적인 규모로 증가하면서 예전과는 전혀 다른 문제가 대두되었다.

모듈과 객체는 코드를 추상적이고 부분적인 캡슐로 분리해서 전체적인 코드에 대한 관리가 가능하도록 만들고 필요하면 재사용 할 수 있는 방법까지 제공했다. 즉 모듈과 객체는 코드의 부분을 떼어내서 추상화하는 방법을 제공한 것이다. 하지만 이러한 방법은 모듈과 객체를 가로지르며 존재하는 공통의 관심사(cross-cutting concern)를 효율적으로 추상화하는 방법은 제공하지 않았다. 공통의 관심사란 보안(security), 성능(performance), 기록(logging)과 같은 소프트웨어의 일반적인 속성에서부터 데이터 캐시(cache) 관리나 네트워크 프로토콜의 구현처럼 구체적인 기능에 이르기까지 다양하다.

이러한 공통의 관심사는 특정한 모듈이나 객체가 구현하는 기능에 국한되는 것이 아니라 소프트웨어 시스템 전체에 걸쳐 수평적으로 영향을 미친다. 잘 이해가 되지 않는 독자는 다음 예를 생각해 보면 도움이 될 것이다.


공통의 관심사    

인터넷 붐이 한창이던 90년대에 미국에서는‘수평적 시장(horizontal market)’과‘수직적 시장(vertical market)’이라는 표현이 자주 사용되었다. 수직적 시장이란 어떤 제품이 특정한 분야의 시장에 국한되는 경우를 의미한다. 예를 들어서 책, 의류, 자동차, 컴퓨터, 혹은 의료보험 시스템 등은 다른 분야와 겹치지 않는 자기 자신만의 시장을 형성한다.

이들은 모두 수직적 시장의 예이다. 하지만 웹브라우저와 같은 소프트웨어는 특정한 시장에 국한되지 않고 모든 수직적 시장들 사이에 공통적으로 존재하며 영향을 미친다. 그 자체로는 특정 품목에 대한 시장을 형성하지 않지만 여러 시장에서 동시에 존재하는‘공통의 관심사’가 되는 것이다.

영화 <뮌헨>에서 이스라엘의 모사드, 소련의 KGB, 미국의 CIA, 팔레스타인의 검은 9월단 등은 각자 겹치지 않는 고유의 영역을 구성하고 있지만, 그들이 어떤 인물의 은신처를‘검색’하기 위해서는 다양한 정보를 보유하고 있는‘정보 브로커’를 찾아가야만 했다. 각 국의 정보기관이 수직적 시장을 형성하고 있다면,‘ 정보 브로커’는 웹브라우저와 마찬가지로 수평적 시장을 형성하고 있는 셈이다. 이 경우에‘정보 브로커’는 여러 정보기관들을 가로지르며 공통적으로 존재하는‘공통의 관심사’로서의 역할을 담당한다.

오늘날의 프로그래밍 세계에서 수직적 시장을 구성하는 존재는 말할 것도 없이‘객체’들이다. 객체들은 저마다
주어진 일감을 구현하면서 일이 서로 겹치지 않도록 소프트웨어의 전체 영역을 분할한다. 이렇게 분할을 더욱 효율적으로 만들기 위해서 비슷한 일을 하는 객체를 한곳에 묶어서‘패키지(package)’라고 부르기도 한다. 지금까지 프로그래밍은 이러한 분할을 통해서 충분히 잘 이루어져 왔다.

하지만 이렇게 역할 분담을 통한 균형과 평화가 이루어진 상황에서도 여러 객체 사이에 존재하는‘공통의 관심사’는 존재하기 마련이다. 앞에서 예로 든 보안, 성능, 기록, 캐시, 프로토콜 등이 바로 그들이다. 이밖에 유닛테스트(unit test)나 테스트 자동화 등도 여기에 포함될 수 있을 것이다.

좀 더 이해를 돕기 위해서 하나의 구체적인 상황을 생각해보자. 소프트웨어의 사용자들이 항상 그렇듯이 개발자가 개발한 시스템을 이용하는 사용자 중에는 구체적인 데이터를 제시하지 않으면서 말로만“시스템이 느려 터졌다.

답답해서 못 쓰겠다.”라고 불평을 늘어놓는 사람이 있다. 소프트웨어를 제작하고 관리하는 입장에서는 이렇게 막연하게 불평만 늘어놓는 사용자처럼 속상한 존재가 없다.

구체적으로 어떤 기능을 사용할 때‘느린지’를 알아야 그가 겪고 있는 문제가 PC 하드웨어와 관련된 문제인지, 개발자가 만든 소프트웨어의 문제인지, 네트워크의 문제인지, 혹은 서버나 데이터베이스의 문제인지를 알 수 있고 그에 따른 해결책을 제시할 수 있기 때문이다(물론 사용자가 허락만 해준다면 그가 소프트웨어를 어떻게 사용하는지 직접 관찰할 수도 있을 것이다. 하지만 성격이 곱지 않은 월스트리트의 트레이더에게‘저는 소프트웨어를 제작한 사람인데요, 잠시 옆에서 PC를 사용하는 모습을 관찰해도 될 까요’라고 묻는 것은 자살 행위이다).

그렇지만 사용자가 데이터를 제공해 주지 않는다고 해서 손을 놓고 있을 수는 없으므로 우리는 필요한 데이터를 스스로 구해야 한다는 결론을 내리게 되었다. 그리하여 우리가 구현하기로 한 기능은 사용자가 소프트웨어에서 어떤 동작을 수행할 때마다 맨 처음 GUI의 이벤트 처리 메소드(event handler)에서 출발해서 서버와 데이터베이스에 이르는 과정에 존재하는 각 계층을 통과하는 데 걸린 시간을 측정한 다음 로그 파일과 같은 하나의 장소에 기록하는 것이었다.


스파이로그    

사용자가 GUI 화면에서 주식이나 채권 가격 같은 데이터를 입력하고 OK 버튼을 눌렀다고 해보자. 그러면 소프트웨어의 흐름은 GUI 계층, GUI 계층 아래에 존재하는 네트워크 계층, 실제 네트워크 전송, 서버에서 사용자의 요청을 받아들여서 적절한 컴포넌트( component)에게 전달하는 계층, 데이터베이스에 저장되어 있는 프로시저(stored procedure), 최종적인 데이터를 담고 있는 응답객체를 생성하는 계층, 응답 객체를 GUI 클라이언트에게 전송하는 계층, GUI가 서버의 응답을 받아서 처리하는 계층 등을 차례로 통과한다.

이 때 각 계층에서 소요된 시간을 측정해서 하나의 객체에 저장하는 것이다. 이렇게 처리시간이 기록된 객체는 각 계층을 통과할 때마다 다음 계층에게 전달되면서 값을 축적해 나간다. 필요한 처리 과정이 모두 끝나고 나면 이 객체에 저장된 값은 미리 지정된 포맷에 따라서 로그 파일에 기록되고 객체의 수명은 끝이 난다.

이제 사용자가 시스템의 성능에 대해서 밑도 끝도 없는 불평을 늘어놓으면 로그 파일에 저장되어 있는 데이터를 분석해서 실제로 성능에 문제가 있었는지, 만약 문제가 있었다면 어느 계층에서 문제가 있었는지를 파악할 수 있다.

이렇게 유용한 기능의 이름을‘스파이로그’라고 불러보자. 앞의 설명을 읽으면서‘흠 소프트웨어의 여러 계층을 관통하는 <공통의 관심사>를 설명하려고 애쓰고 있군’하고 생각하는 독자가 있다면 만점이다. ‘공통의 관심사(crosscutting concern)’라는 개념을 이해했다면 상황중심 프로그래밍의 98%를 거의 이해한 것과 다름이 없다.

이러한 스파이로그를 실제로 구현하는 방법은 어렵지 않다. 소프트웨어가 객체지향 기법에 따라서 계층별로 잘 분리되어 있다면 더욱 그러하다. 각 계층의 시작과 끝 부분에서 시간을 측정하는 데 필요한 동작을 수행하기만 하면 되기 때문이다. 하지만 그것이 가능하기 위해서는 최소한 두개의 전제 조건이 필요하다. 하나는 스파이로그를 구현하는 프로그래머가 각 계층의 입구와 출구를 정확하게 파악하고 있어야 한다는 점이고, 두 번째는 스파이로그를 구현하기 위해서는 입구와 출구에 해당하는 객체의 소스 파일이 수정되어야 한다는 점이다. 즉, 입구에 해당하는 위치에서는 앞의 계층에서 전달한 시간 측정용 객체를 받아들인 다음 들어온 시간(time stamp)을 찍고, 출구에 해당하는 위치에서는 같은 객체 위에 나가는 시간을 찍고 나서 뒤에 있는 계층에게 객체를 전달해 주는 것이다.

이런 방법은 기능적으로는 아무런 문제가 없지만 코드의 관리라는 측면에서 보면 문제가 많다. 한 가지만 예를 들자면 이런 식이다. 시스템에 A, B, C, D라는 네 개의 계층이 존재한다고 하자. 하나의 동작(operation)이 완성되려면 A, B, C, D, C, B, A라는 완성된 사이클이 그려져야하고, 스파이로그는 이러한 일곱 단계가 소비하는 시간을 각각 측정해서 기록한다.

그런데 나중에 누가 C 계층을 리팩토링해서 그것을 C1과 C2라는 두 개의 계층으로 분리했다고 가정해보자. 그리고 스파이로그의 존재를 의식하지 못한 그가 C1이 받아들인 객체를 C2에게 전달하는 것을 깜빡 잊었다고 하자. 이와 같은 본의 아닌‘실수’가 도입되는 순간 C1과 C2 사이의 고리가 끊어지면서 스파이로그의 기능은 동작을 멈출 수밖에 없다.

여러 계층이 공유하고 있는‘공통의 관심사’가 단지 한계층에서 발생한 실수 때문에 완전히 동작을 멈춘다는 것은 공정하게 들리지 않는다. 뿐만 아니라 스파이로그의 기능이 여러 소스 파일에 분산되면서 코드의 관리가 어려워진다는 단점도 존재한다. 이러한 상황은 서로 독립적으로 분할되어 있어야 하는‘객체’라는 존재를 중심으로 하는 프로그래밍 방법론으로는 명쾌하게 해결되기 어렵다.

객체는 본질적으로 다른 객체와 나란히 서 있도록 만들어진 존재이지, 다른 객체의 허리를 가로지르며 직교(orthogonal)하도록 만들어진 존재가 아니기 때문이다. 바로 이와 같이‘난처한 상황’에서 힘을 발휘하는 것이‘상황중심’의 프로그래밍이다.


제록스 팔로알토연구소에서 탄생    

상황중심 프로그래밍이라는 개념은 제록스 팔로알토 연구소에서 탄생한 것으로 알려져 있다. 현재 캐나다의 브리티시 콜롬비아 대학의 컴퓨터 사이언스 교수인 그레고르킥잘레스(Gregor Kiczales)는 팔로알토 연구소에서의 연구를 확장해서 현재 상황중심 프로그래밍 세계에서 대표적인 언어로 인정받고 있는 AspectJ를 설계했다. IBM에서도 HyperJ나 관심 변경 환경(Concern Manipulation Environment)과 같은 상황중심 프로그래밍 언어를 발표했지만, 현재 프로그래머 사이에서 널리 받아들여지고 있는 언어는 단연 AspectJ이다.

상황중심 프로그래밍에서 사용하는 개념은 크게 네 가지가 있다. 접점(pointcut), 안내(advice), 내부타입 선언(inter type declaration), 그리고 이들을 모두 묶어서 하나의 단위로 추상화하는 상황(aspect)이 그들이다. 상황중심 프로그래밍이나 이러한 개념들이 의미하는 바는 AspectJ의 홈페이지 등에서 쉽게 접할 수 있다. AspectJ에 대한 책도 이미 적지 않게 나와 있다. 여기에서 이들이 의미하는 바를 간단하게 살펴보자면 이렇다.

우선 접점(pointcut)은 공통의 관심사가 여러 개의 객체나 계층을 가로지를 때 그들과 만나게 되는 지점을 의미한다. 앞에서 살펴본 예에서는 각 계층의 입구와 출구가 접점에 해당하고, 더 앞에서 든 예에서는 모사드, CIA, KGB의 요원들이‘정보 브로커’와 만나는 상황 자체가 접점에 해당할 것이다. 접점은 상황중심 프로그래밍을 수행하는 프로그래머가 이미 존재하는 소프트웨어 시스템을 이해하고 있는 수준, 혹은 핵심을 짚어내는 안목에 따라 제대로 짚어질 수도 있고, 엉뚱한 곳이 접점으로 인식될 수도 있다. 어쨌든 프로그래머가 일단 접점을 골라냈으면 그 다음에 할 일은 그 곳에서 할 일을 정의하는 것이다.

그것이 안내(advice)이다. 상황중심 프로그래밍에서 안내는 객체지향 프로그래밍에서의 메소드에 해당한다고 생각하면 쉽다. 특정한 접점에 이르기 직전이나 혹은 직후에 어떤 일을 할 것인가를 정의하는 알고리즘이 안내의 내용을 이룬다.

내부 타입 정의(inter type declaration)는 약간 복잡하다. 이것은 자바 프로그래밍과 같은 기존의 프로그래밍 방식에 익숙한 사람들에게 개념적인 혼란을 초래하기 때문이다. 자바 언어를 예로 들자면, 어느 객체에게 새로운 인스턴스 변수(instance variable) 혹은 필드(field)를 추가하는 것은 언제나 소스 코드의 수정과 컴파일을 통해서 이루어진다.

프로그램이 실행되고 있는 도중에 새로운 필드를 내 마음대로 추가할 수는 없는 것이다. 자바 런타임(runtime) 내부에서 클래스 이름만 가지고 클래스의 인스턴스를 만들어내는 기능은 있지만 클래스에 이미 정의되어 있지 않은 필드를 더하는 기능은 없다.

그런데 상황중심 프로그램에서 사용하는‘내부 타입 정의’기능은 객체에게 새로운 필드를 동적으로 더하는 것을 가능하게 만든다. 이러한 기능이 필요한 이유는 이미 존재하는 다양한 객체와 계층을 가로지르면서 동작하는 알고 리즘을 작성하기 위해서는 주어진 객체의 정해진 틀을 뛰어넘는 능력이 필요하기 때문일 것으로 추측된다. 사실 필자 역시 상황중심 프로그래밍에 익숙하지 않기 때문에 섣불리 말하기는 어렵지만, 이러한 기능이 바람직한지에 대해서는 의문이 든다.

상황중심 프로그래밍을 구사하는 프로그래머가 어느 객체에게 내부 타입 정의 기능을 이용해서 동적으로 어떤 필드를 추가했다고 해보자. 그는 객체를 정의하고 있는 클래스에 새로운 필드를 사용하는 알고리즘을 추가할 수도 있다. ‘( 내부 타입 정의’기능을 통해서 추가한 필드가 퍼블릭으로 정의되어 있다면 기존의 자바 코드에서 접근하는 것이 가능하기 때문이다.)

이렇게 작성된 소스 코드를 나중에 읽는 다른 프로그래머는 (특히 그가 상황중심 프로그램의 존재를 인식하지 못하고 있다면) 도대체 이 코드가 사용하고 있는 필드가 어디에 정의되어 있는 것인지 알 길이 없다. 이런 식의 혼란은 미묘한 버그의 원인이 될 수 있다.

이런 측면에서 보자면 내부 타입 정의를 이용하는 것은 멀쩡한 객체에게 뼈를 깎고 살을 붙이는 성형수술을 시도하는 것, 혹은 객체의 유전자를 조작해서 없던 장기를 만들어 내는 것에 비유할 만하다. 수술이나 유전자 조작이 필요한 결과를 낳는다면 다행이지만, 잘못된 결과를 낳거나 그것이 남용된다면 차라리 하지 않느니만 못한 일이 될 것이다.

마지막으로, 객체지향 프로그래밍에서 클래스가 변수와 메소드를 한 곳에 묶어서 하나의 객체로 추상화하듯, 상황중심 프로그래밍에서 사용되는 접점, 안내, 내부 타입 정의를 한 곳에 묶어서 추상화하는 것은‘상황(aspect)’이다. 따라서 상황은 객체지향 프로그래밍에서 객체가 중심에 서있듯이 상황중심 프로그래밍에서 가장 중심에 서있는 개념이 된다(이것은 프로그래머들이 혐오하는‘중복’된 표현처럼 들린다. 하지만 달리 표현할 방법이 없다. 상황중심 프로그래밍에서 중심은 상황이기 때문이다).


출처 : 임백준(월스트리트 금융전문가) & 소프트웨어 산책외 다수 저자

답답해서 잠을 못 이루는 사안이 있다. 두고 보기에는 점점 꼬여가는 한국의 웹이다. '직접적 가치 교환 플랫폼'으로 진화해 나가야 할 웹이 현실이 드리워 놓은 구조적 장벽에 막혀 확장 의욕을 잃고 방황하고 있다.

지금 우리 IT 업계와 정책이 심사 숙고해야 할 문제는 ActiveX 호환성이나 웹접근성과 같은 발등의 불을 단기적으로 해소하는 일이 아니라, 급변하는 세계 속에서 과연 우리 IT가 세계에 의미가 있는 존재로 성장할 수 있을지 걱정해야 하는 레벨의 장기적 문제다.

법과 제도에 길들여진 기술은 그 특유의 창조성을 잃어 버리고, 고착화되어 고비용의 성곽을 쌓고 그대로 굳어 간다. 특히 지난 닷컴붐을 기점으로 형성된 전자 거래에 대한 보호 제도가 실은 보호가 아닌 규제와 간섭의 제도로 변해 버렸다. 뿐만 아니라 이에 대해 업계와 사회 전체가 이를 '당연한 기성 사실'로 삼고 의심하지 않은 채 주눅이 들어 그 틀 안에서 해법을 찾으려 하고 있다. 원점으로 돌아갈 용기를 잃은 것이다.

그러나 충격적이지만 이미 다 느끼고 있는 질문을 이제는 소리 내어 말해야만 한다.

"우리에게 공인인증체계란 정말 필요한 것일까?"

원래 인증서 자체는, 그리고 인증서가 근거한 PKI란 매력적이다. 공개키/비밀키의 쌍이 핵심 역할을 하는 이 인프라에서, 인증서는 거래 당사자가 진짜 그 사람임을 증명하고, 당사자만 이해할 수 있는 암호화된 통신으로 거래가 이루어질 수 있도록 한다. 내가 비밀키로 사인한 문서를 내 공개키로 확인할 수 있기에, 타인은 틀림 없이 내가 만든 문서임을 알게 된다는 원리다. 내 공개키로 다른 사람이 암호화해서 보내온 문서는 비밀키를 지닌 나만이 열 수 있다는 원리다. 이러한 의미에서 PKI 자체는 유용하고 또 탁월하다. 글로벌 기업은 직원과 자원의 인증 수단으로 사설 인증서를 널리 쓰고 있다.

문제는 '공인'이다.

현재 1500 만명, 그러니까 전 경제인구의 65%에 공인인증서가 보급되었다고 우리는 자화자찬한다. 세계 최고다. 주민등록제도에 이어 또 다른 쾌거다. 그렇지만 우리는 여기서 원점으로 돌아가 왜 공인인증서를 발부 받아야 하는지에 대한 의문을 풀어야 한다.

공인인증서는 현재 전자서명법 2조에서 밝힌 바와 같이 가입자가 생성한 정보가 가입자에 유일하게 속한다는 사실을 확인하고 증명하는데 있다. 민사소송법 358조의 작성자의 서명이나 날인 또는 무인이 있는 때에는 진정한 것으로 추정한다는 법리와 마찬가지 선상에 있을 것이다. 즉 공인인증서는 기본적으로 인감인 것이다.

그렇다면 전자 서명이란 이 문서가 틀림없이 내가 작성한 문서라는 점을, 그러니까 지금 눈 앞의 전자정보가 내 의사에 따른 것임을 입증하려는 것에 불과하다. 이 것이 원점이다. 현재 온라인상의 전자 거래에 있어서 그 규제의 원점이 되고 있는 전자서명법이 1장에서 밝힌 목적, 정의, 효력은 그 것이 전부다.

그러나 2장으로 넘어 가면서 전자서명법은 '법의 기술 중립성(벤더 중립성과는 완전히 차원이 다른)'과 역행한다. 사실상 본법은 2001년 말의 개정에도 불구하고 사실상 비대칭알고리즘 공인인증인프라(NPKI)에 근거한 공인인증서에 의한 것이 공인된 전자서명이다라고 암시하고 있기 때문이다. 루트CA, 즉 최상위인증기관을 국가의 관할 하에 두는 일은 사연이 있기 때문이라며 넘어갈 수 있다. 그러나 그 것이 거대한 피라미드형 기술 카르텔이 되는 것에는 반대할 수 밖에 없다. 사연이 있어서 꼭 공인인증인프라(NPKI)가 유지되어야 한다면, 외국계를 포함한 다른 사설인증기관이 이와 상호인증(Bridge CA)되는 것을 허락해야 한다.

웹에서 쓸 수 있는 인증 수단은 '공인인증서'만이 아니다. 그럼에도 전자금융감독규정 및 시행 세칙에는 '공인인증서의 의무화'가 명문화되어 있다. 한국에서 전자거래를 하려면 공인인증서를 써야만 하는 것이다.

구조개혁 1: 공인 인증서에 의한 인증 의무화 폐지
공인인증서에 의한 인증 의무화는 법의 기술 중립성을 잃고 기술 발전을 저해하고 있다. 공인인증서가 활용되기 위해서는 전자서명법에서 규정된 관련 기관과 다시 그 관련 업체의 솔루션을 도입해야만 한다. 사실 인증을 위해 공인인증서만이 사용되어야 한다 믿는 것은 일종의 착시현상이다. 공인인증서 없이도 현재 널리 보편적으로 쓰이고 있는 시스템만으로 저비용 PKI 운용이 가능하고 세계적 사례도 많다. 사설 인증서 생성기는 서버마다 들어 있지만 모두 놀리고 있다.

대안①: 접근 허가시 사설 인증서 허용 및 다단계/다각도의 질의식 인증.
시스템으로의 접근 허가권을 어떻게 부여할지 기술적 선택은 전적으로 그 시스템의 판단이다. 감독기관은 그 판단의 건전성과 안전성만 파악하면 된다. 브라우저만으로도 다수의 표준 인증서를 관리할 수 있다. 게다가 인증서 그 자체는 완전 솔루션이 아니다. 인증서가 절취될 가능성이 상존하기에 심정적 안도감만 있을 뿐이다. 마음(패스워드)과 사물(인증서)의 두 종류를 검사한다는 안도감뿐이다. 일본의 은행처럼 다단계의 패스워드 질의 과정을 통과하게 하여 마음을 여러 번 검사하고, 그 중 한 단계는 키보드가 아닌 화면과의 인터랙션으로 다른 각도에서 검사한다면 충분한 일이다.

대안②: OTP(One time password) 및 HSM(Hardware Security Module), 그리고 생체 인식 등 신기술의 적용
공인인증체제는 그 자체가 궁극의 보안 솔루션이 전혀 아님이 이미 다양한 경로를 통해 파악되어 있으나, 현재의 법제 및 감독 규정은 이 체제에 밀결합되어 있다. 새로운 신기술 중 특히 OTP는 최소한의 구조개혁만으로 적용이 가능하고 이미 도입이 시작된 곳도 있다. 즉 다단계/다각도의 상호작용으로 마음을 검사하는 것이 공인인증서라는 사물보다 훨씬 더 인증에 효과적인 것이다. 이러한 새로운 사용자 인증 절차는 공인인증에 의한 인증 과정을 충분히 ‘대체’할 수 있다. 그래도 만약 사물이 필요하다면 HSM이나 생체와 같은 제대로 된 사물의 인증을 고려해야 한다. 사물이라 믿었던 공인인증서는 결국 무한 복제가 가능한 정보일 뿐이다. 우리는 공인인증서가 안전한 인증수단이라는 공동최면 상태였을 뿐이다.

구조개혁 2: 독자적 암호화 통신 알고리즘 이외에 SSL 3.0 적용 허용
현재 한국 웹의 암호화 통신 알고리즘은 플러그인에 의한 SEED가 사실상 강제된 채, SSL/HTTPS는 사용되고 있지 않다. 전자가 후자보다 뛰어나다고 가정하자. 그러나 그 가정에도 불구, 우리는 여기서 막대한 사회적 비용을 지불해 왔음을 깨달아야 한다. 이는 전형적인 "Reinventing the wheel"의 오류다. 공개키 기반 암호화 통신은 국제 표준화된 SSL로 충분하다.

글로벌 환경에서 기술 인프라스트럭처의 독자적 폐쇄계를 구성하는 것은 무의미하다. 웹과 같은 평평한 세계에서는 세계적 기술을 만들던가 세계적 기술을 채택하던가 양자택일뿐이다. SEED가 뛰어난 아키텍처였다면 빠른 시기에 국제표준화와 벤더로의 로비로 브라우저에 탑재시켰어야 했다. 지금은 완전히 우물안 개구리가 되어 버렸다. 그리고 세계 시장에서 소외된 자폐적 업계만 남았다. 역사적으로 이러한 시도가 마지막으로 이루어진 것은 2차 대전에서의 독일과 일본 정도였다. 우리는 이 시대착오적 민족주의 기술입국 마인드셋에서 탈피하지 못하고 있다.

대안: 서비스 업자가 어떠한 기술을 쓰든(즉 SEED를 쓰지 않더라도) 그 것이 가이드라인을 만족시키면 개입하지 않는다.
어떤 금융 기관이 이미 서버에 탑재된 베리사인의 인증키를 써서 128bit SSL 통신을 하겠다고 한다면 금융감독원을 포함한 어떠한 감독기관도 간섭하지 않으면 된다. 서비스 업자는 시장 논리에 따라 최대 다수의 후생을 극대화하는 선택을 할 것이다. 아마도 현존하는 대부분의 브라우저가 지원하는 SSL 3.0 기반 HTTPS 암호화 통신을 매우 저렴하게 구축할 것이다. 그 결과 XP도 비스타도 리눅스도 맥도, IE도 파이어폭스도 사파리도 오페라도 그리고 무엇보다도 내가 늘 사용하는 골동품 모바일 단말 윈도우 CE.NET에서도 온라인 뱅킹과 관공서에 들어갈 수 있게 된다.

구조개혁 3: 공인인증서에 의한 서증(書證)의 적용 범주 재정의
현재의 공인인증서는 공개키 기반의 암호화 전자거래에 있어서 ‘서명’을 한다고 한다. 일반적으로 PKI의 혜택 중의 하나는 바로 '디지털 서명'과 이를 토대로 '부인 방지'를 할 수 있을 것이라는 믿음이다. 그리고 이 믿음을 적극적으로 웹으로 가져왔다. 거래에 디지털 인감을 찍어줌으로써 거래가 없었다 부인하는 일을 막을 수 있다거나 후일 거래 증빙이 된다는 것이다. 그러나 이에는 두 가지 문제가 있다. 하나는 공인인증서 자체가 절취될 수 있는 가정이 있기에, 대면하지 않은 거래에 있어 본인이 거래를 했다 추정할 수 있는 법적 근거의 성립 여부다. 인증서라는 절취 가능한 정보 만으로 본인 확인을 의존한다는 전제에서는 의미가 없다. 공인인증서가 복제되어 쓰이게 되면 정말 본인이 하지 않은 거래일 터 이 것이 무슨 소용인가. 오히려 철저히 본인을 확인하고, 이를 로깅하는 것이 더 실효성이 높다. '디지털 포렌직(Digital forensic)'을 발전시켜야 한다. 남의 사인은 베끼기 어렵지만 남의 도장은 남보다 더 잘 찍을 수도 있는 것이다. 디지털 인감이 부인 방지(Non-repudiation)에 법적 효력을 가질 수 있는지에 대한 의문은 널리 이야기되는 사실일 뿐만 아니라, 선진국의 전자서명법의 태동기에도 심각하게 의문시된 채 지금도 결론이 나지 않은 문제다. 그럼에도 이를 공인 문서화 하여 진정성립을 자동적으로 추정시키는 것은 개인에게 더없이 불리하다. 이 점이 또 하나의 문제다.

서증의 효력이 있다고 한다면 이처럼 또 다른 문제가 생긴다. 현실 생활에서는 인감을 필요로 하는 상황이 아닌, 온라인 쇼핑이나 은행 업무와 같이 인감과 무관한 거래에도 자신의 전자 인감을 남발하는 결과를 초래하는 것. 무의미한 정보 제공이다. 이는 리스크에 대한 체제의 책임 회피이고 여기에서 소외되는 것은 개인뿐이다. 쇼핑시 30만원 이상에 공인인증서를 제출하라는 등 세계적으로 유례가 없는 요건은, 만의 하나 벌어질 리스크에 체제가 면피하기 위한 구실에 지나지 않는다. 이러한 '면피의 시스템'을, 요즈음 분위기라면 윈도우, 리눅스, 애플, 그리고 앞으로 등장할 모든 운영 체제와 디바이스용으로 만들어야 할 판국이다. 민간 개인에게 있어 보안의 의미는 '나만 나의 거래를 안전하게' 하면 되는 것이지, '내가 거래를 했다는 공문서를 제출할' 의무가 아니다. 오히려 필요한 것은 그들이 나와 거래를 했다는 영수증일 것이다. 뿐만 아니라 웹서비스의 WS-*와 같은 자동적 전자문서 교환에 있어서의 서증은 어떻게 할 것인지, 현재의 체제는 답이 없다.

대안: 현실에서 인감이 필요로 하지 않는 모든 상황은 온라인 상에서도 공인인증서에 의한 전자서명을 요구해서는 안 된다.
그리고 형식적 증거로서 서증이 필요한 상황이 오더라도 그 사안은 전자서명법 만이 아닌 민사소송법의 견지에서 함께 고려되어야 할 것이고, 그렇다면 더욱 기술 중립적으로 PKI 방식이 아닌 다양한 기술적 가능성에 대해서도 그 가능성을 열어 두어야 한다.

현재 상황은 예를 들자면 도장 날인은 효력이 있으나 자필 서명은 효력이 없다고 하는 것과 마찬가지다. 태블릿 서명이나, 생체인식에 의한 서명 등 다양한 기술적 가능성이 있을 것이다. 미국 국세청의 세금 신고에 서는 본인의 서명을 겨우 다섯 자리의 자기가 설정한 암호를 누르는 것으로 갈음한다. 겨우 다섯 자리다. 자신이 설정한 다섯 자리의 암호를 스스로 입력하면 그 것이 서명이다. 공인인증서가 서증의 역할에 절대적인 것은 아니라는 합리적인 반증이다.

구조개혁 4: 프로그램의 선택과 설치라는 개인과 시장의 자유 재량과 권리를 보호
나는 기본적으로 사용자에게는 ‘웹’ 이상의 기능을 원할 권리가 있다고 보는 주의다. 그러나 동시에 원하지 않는 기능을 거부할 권리도 있다고 보는 주의이기도 하다.

이상 1,2,3의 구조개혁이 성공하면 대부분의 플러그인은 사라질 일이겠지만 '키보드 보안 플러그인' 같은 경우는 주무부처가 달라 계속 강요될지도 모른다. 그러나 잠시 생각해 보면 이 또한 무의미한 플러그인이다. 일본의 은행은 키보드 해킹이 두려우면 랜덤하게 변하는 화면상의 키패드를 누르도록 하는 단계를 한 번 더 둔다. 그런데 한국의 은행들은 플러그인이 행여 모자랄까 방화벽 플러그인까지 깔아 주려 하는데, 이는 친절이 아닌 명백한 월권이며 개인의 선택권 침해다. 많은 플러그인은 요긴하지만 그 것을 사용할지 여부는 철저하게 사용자와 서비스 사이의 판단이지, 이를 제도나 행정이 강요해서는 안될 일이다.

미래에서의 생존을 위한 구조개혁
도대체 이러한 무의미한 시스템을 위한 개발 비용은 어디서 나는 것일까? 설마 내 세금일까? 공적 자금일까? 폭력적인 플러그인과 존재의미가 모호한 공인인증체계의 유지를 위해 도대체 얼마만큼의 자금이 투하되어 온 것일까? 구조 개혁을 부르짖는 첫 번째 이유는 바로 이 직접 비용 때문이다. 또 공인인증서의 사용 강제에 따른 막대한 자금과 시간과 그로 인해 야기되는 시민들의 불편함에 대한 간접 비용도 무시 할 수 없다. 완전 무결 노 리스크의 진공 상태 사회란 만들 수 없다. 상상할 수 있는 모든 리스크에 대응하는 조치를 일단 해 봄으로써 만족감을 얻으려는 마음은 이해가 간다. 그러나 그 코스트는 고려되고 있지 않다.

더 안타까운 것은 기회 비용이다. 선진 IT 강국들은 OS와 브라우저에 기본 탑재된 표준화된 기술만으로 안전한 거래를 하기 위한 노력을 하고 그 과정에서 또 다른 세계적 표준을 만들어 내고자 노력한다. 반면 우리는 일단 ‘우물 안 개구리’식 기술이 적용되도록 감독기관의 감찰을 통과하고 이 회로에 속한 이들에게 대규모 발주를 해야 한다. 웹2.0적 '가치 교환 플랫폼'을 꿈꾸는 벤처가 도무지 생겨날 수가 없다. 별다른 추가적 제제나 감시 없이 전자 거래가 가능하게 되면 자신의 입지가 위태로워지는 이들이 리스크를 침소봉대하여 제도와 시스템을 만들고, 그럼에도 불구 사고가 터져 제도의 근본적 신뢰성에 금이 갔음에도, 좀처럼 정정할 의도가 없다. 정부와 행정의 역할은 어디로 갔나?

지금과 같은 굳어 버린 성곽 속에서는 새로운 아이디어의 창발이 원천적으로 억제될 뿐만 아니라, 외적 변화에 적응할 때 막대한 사회적 비용이 지불되며, 그리고 파괴적 신기술의 유입이 차단되어 가늠할 수 없는 산업의 왜곡으로 이어진다. 각국 전자 거래법의 기본 원칙은 ‘국제적 기술 동향과 조화된 입법’을 늘 꿈꿔왔다. 왜냐하면 전자 거래의 범지구적 성격을 알기 때문이다. 우리와 매우 흡사한 일본의 전자서명법도 우리 공인인증에 해당하는 '특정인증업무'의 입법이 있지만, 그 입법 경위는 외국과의 상호인증을 위한 것이기에 특정인증업무의 기준을 따르지 않더라도 법률효과는 존속된다. 그 덕에 인증서가 쓰이는 경우는 세금 신고 정도이고, 이 조차 시스템 도입 3년이 지난 지금 개인의 0.2%만 사용하고 있다.

물론 한국의 전자서명법도 원래 그런 법리일지 모른다. 그렇지만 이미 다양한 시행 세칙 및 관련 기관의 감독은 이를 굳어 버린 감시 감독 체제로 진화시켜 버렸다. 그리고 이를 충실히 따르는 업계는 어느새 놀랄 만큼 기형적인 웹 생태계를 만들어 놓은 것이다.

한국의 웹은, 그 서비스의 면모는 독창적이고 기발하며 참신하다. 그렇지만 웹은 세계와의 소통이 전제다. 그렇기에 우리는 외국의 쇼핑몰에서 물건을 살 수 있고, 외국의 메일 서비스를 그대로 이용할 수 있는 것이다. 이런 일이 가능하게 하기 위해 사람들은 표준을 이야기하고, 아니 웹 자체가 하나의 표준인 것이다. 이 공간이 거대한 소통의 플랫폼, '직접적 가치 교환의 플랫폼'으로 진화해 나가려는 시점에 있건만, 우리는 주민등록번호 없으면 가입 못하는 시스템을 만들더니 이제 공인인증서가 없으면 진행이 안 되는 시스템을 만들고 그 안에 갇혀 있다. 정말 공인인증서가 필요하다 믿는다면 이를 세계적 규모의 표준으로 만들어야 한다. 정말 관공서에서 전자 서명의 서증이 필요하다면 유럽의 WASP (Web Activated Signature Protocol)처럼 천천히 느긋하게 표준화의 길을 걸어야 한다.

프로슈머, 소액결제, 지역통화 등등 우리는 지금까지 현실에서 생각지도 못했던 가치 교환의 욕구와 만나게 될 것이다. 지금 세계는 이상계 위에서 그리고 환상계 속에서 새 시대에 걸맞은 새로운 플랫폼을 만들려 노력하고, 또 그 위에서 새로운 기회를 찾으려 분주하다. 그러나 우리는 법과 감독의 규율에 갇혀 아무 생각도 하지 않고 있는 듯 하다.

변화의 시대. 새로운 플랫폼을 쓰지 말라고 권하는 게 나을까, 그 플랫폼을 타고 세계로 뻗어나가는 게 나을까? 후자가 답이라면 단기적인 해법에 집착하지 말고 미래를 위한 구조개혁을 단행할 때다.

출처 :  김국현(IT평론가)