eonj - Tumblr blog

eonj · 6 years ago

Text

CS와 CE 중 어느 쪽이 오래 살아남을 것인가?

현재의 CS (컴퓨터과학) 와 CE (컴퓨터공학) 중 어느 쪽이 더 오래 살아남는 분야가 될 것인가?

이런 주제로 논쟁하기 좋아하는 사람들은 대부분 이렇게 말한다: CS는 계산이란 무엇인가에 대한 과학이고, CE는 어떻게 내가 원하는 계산을 만들 것인가에 대한 공학이다. 실리콘이 아니라 무엇으로 컴퓨터를 만들더라도 계산의 본질은 변하지 않는다. 그러나 어떤 계산으로 무엇을 만들 것인지는, 컴퓨터를 실리콘으로 만들지 않게 된다면 굉장히 많이 변하게 된다. 따라서 CS가 CE보다 더 오래 살아남는다고 결론짓는 것이 타당하다.

나도 이처럼 생각하던 시기가 있었다. 오늘날처럼 여러 이론 간의 관계가 급격히 뒤집어지는 시기에 실무를 뛰게 되기 전까지는, 나도 정말 그렇게 생각했다.

현실은 이렇다: 과학적 방법론은 스스로 혁신하지 못하는 것을 부끄러워하라고 하지만, 공학적 방법론은 모든 혁신을 조금씩은 두려워하고 경계하도록 만들어져 있다. 요약하건대 대체로 공학이 과학보다 보수적이다.

이는 근본적으로 과학보다 공학이 현실에 가깝기 때문이다. 과학에서 정량화는 사례와 체계를 다루는 하나의 도구일 뿐이지만, 공학적 접근에서는 정량화가 현실 세계에 대한 측정으로 작용한다. 이는 공학적 대안에 대해 가치를 판단하고 우열을 매기길 종용하는 하나의 절대기준이 있음을 시사한다 -- 바로 경제적 효율이다.

안타깝게도, 기술결정과 기술정책에 있어서도, 변화는 실제로 겪어 보기 전에는 어떻게 될지 모르는 것이다. 게다가 모든 종류의 변화에는 그것을 일단 수행할 뿐만 아니라 앞으로 잘 유지되도록 하기까지 꽤 많은 비용이 든다; 기술의 변화에 있어서는 대체로 이 비용을 일정 오차 내에서 추산할 수 있다. 그래서 기술혁신 역시 공학적 관점에서는 미지위험과 매몰비용을 상대하는 일이며, 대부분의 인간이 본능적으로 변화에 두려움을 느끼듯, 공학적 방법론 역시 기술혁신에 두려움을 매긴다.

그래서 공학적 방법론은 대체로 익숙함에 기대도록 한다. 만약 어떤 기술적 대안을 믿을 만하게 여기거나 믿지 말아야 할 만한 일정한 근거가 필요하다면, 대체로 그 기술이 실제 세계에서 경제적 가치를 평가받아 활용되고 있는지의 여부를 확인해 보아야 할 것이다. 한편 과학은 원래 그런 ‘현실적’ 판단으로부터 꽤 멀리 떨어져 있는 것이다. 과학적 방법론은 우리에게 끊임없이 무언가를 생소하게 보기를 요구한다. 과학이 특히 경계하는 것은 공동체적 믿음에 의해 견고해진 인식이며, 모든 생각은 언제든 과학적인 반박과 재해석에 의해 공격받을 수 있다. 그렇기에 대체로 혁신을 시작하는 주체는 과학이며, 그것을 마무리짓는 것이 공학이다. (물론, 우리는 실질적으로 일종의 ‘혁신압’에 시달리므로, 기술혁신을 지속가능한 수준에서 유지하는 것이 바람직하다. 이것이 기술경영이다.)

다시 CS 대 CE 논쟁으로 넘어와서, 우리가 CE를 한다면 기존에 주어진 계산을 어떻게 값싸게 잘 활용할 수 있는가에 집중해야 할 것이다. 그러나 CS를 한다면 용기를 갖고 계산이란 무엇인가에 대해 재정의할 준비가 되어 있어야 한다. 어느 분야가 기존의 모습에 고착되기 쉬운지는 너무나도 뻔한 일 아닌가?

반도체 산업은 어느날 무너져 버리지는 않을 것이다. 적어도 십수 년 후에도, 그때까지 인류가 살아 있다면, 지구 어디에선가는 값싸게 적절한 계산성능을 창출하기 위해 실리콘 잉곳을 썰어서 웨이퍼를 만들고 자외선을 쪼여 회로를 새기고 있을 것이다. 누군가는 머지않아 양자 얽힘을 이용한 큐비트 컴퓨터가 세계를 지배할 것이라고 했지만, 나는 이에 대해서 비관적인 편이다. 기술적 대안이 사회에 자리잡는 것은 그것이 공학적으로 평가했을 때 충분한 경제적 가치를 가질 때뿐이다. 그리고 큐비트는 아직 준비가 안 됐다. 오히려 지금 시점에서는 어떤 상태를 이산적으로 깨끗이 쪼개 하나의 값으로 쓰기 위해 양자역학을 도입하고 있는 실정이다.

하지만 계산의 본질에 대한 논의는, 좀 다르다. 우리는 지금까지 람다 대수나 튜링 기계를 이용해, 규칙에 따라 한 상태에서 다른 상태로 전이하는 것이 조합되어 결과적으로 원하는 것을 얻는 계산 능력을 구성한다고 배웠으며, 이런 모델로 어떤 문제의 계산 가능성이나 계산 복잡도를 정의하여 왔다. 그러나 이렇게 부단한 구성주의적 노력으로 만들어 왔던 컴퓨터와 계산의 세계가 지금 무너지고 있다. 문제를 정확히 정의하지 않고, 컴퓨터가 인간과 비슷한 방식으로 판단력을 얻어 나가게 할 수 있다고 밝혀지고 있기 때문이다. 기지의 영점을 해공간에 잘 헤쳐모아 두고, 영점을 모을 수 있는 적당한 방향과 크기의 경계를 만들면, 공간 안에서 기존의 영점을 모아 귀납적으로 적절한 개념을 모을 수 있다. 그리고 이렇게 배운 것은 ��사용할 수 있다. 바로 기계학습 이야기이다.

기계학습에서 우리는 내트워크의 초기값에 훈련집합을 반복학습시켜 하나의 모델로 수렴하도록 한다. 물론, 배운 것이라도 잘 기억하고 있는지 검증해야 한다. 그 다음에는, 모든 자료를 학습에 돌려 버리면 그 결과로 나온 개념이 실제로 우리가 의도한 개념과 일치하는지 알 수 없으므로, 검증집합과 시험집합을 또 두기도 한다. 이렇게 검토 과정을 거치고 나면 나오는 것은, 기존의 방식과는 판이하게 다르지만 기존과 유사한 판정 문제를 해결하는 무언가이다.

우리는 이것이 계산 능력을 지닌다고 말할 근거를 충분히 많이 가졌는가? 어떤 문제에서 조건을 읽고 답안을 쓰는 유한절차를 설계하기 위해, 우리는 계산 능력에 대한 기존의 모델을 따라 시간을 이산 단위로 분할하고 문제를 환원적으로 정의한다; 확률적으로 정답을 내는 모형은, 설계 단계에서부터 이 시간과 문제 복잡도 사이에서 타협을 본 결과로 만들어진다. 그러나 기계학습 방식의 모형에서 계산 능력을 갖는 것은 항상 불확실한 판단 그 자체이다; 그리고 계산이 옳을 확률을 높이는 것은 해공간의 모양을 잘 뒤트는 사상이며, 영점들과 원하는 근방을 하나의 경계로 잡도록 돕기 위해 모형의 복잡성이 추가된다.

자명한 예로부터 출발하면, 해공간을 재배치하는 사상은 분명히 그 자체로 계산 능력을 지닌다. 그러나 우리는 이것들이 정확히 얼마만큼의 계산 능력을 갖고 있는지에 대해 알고 있는 것이 없다. 애초에 이것을 계산 문제로 볼 수 있게 된지 얼마 되지 않았기 때문이다.

두 가지 방향이 공존한다. 첫째로, CS 분야는 지금이라도 처치-튜링의 신화를 벗어나야 한다. 문제를 기존 모형에서 계산 가능한 것들 사이에서 정의하기보다 수학적 체계로 정의하며 세계를 넓혀야 한다. 실해석으로부터 출발해 컴퓨터를 이용한 해석적 수치계산으로 들어와야 한다. 둘째로, 그럼에도 불구하고 CS는 컴퓨터에 관한 과학이며, 컴퓨터로 계산 가능한 범위를 다루는 분야이다. 따라서 기존의 계산 도구를 조합하여 어떻게 원하는 계산 문제를 풀 것인가, 하는 종류의 논의에 대해 충분한 형식화가 진행되어야 할 것이다. 그런 과정에서 우리는 문제를 정의하는 새로운 모형을 만들 것이고, 기존의 계산을 조합하여 얻는 새 계산이 갖는 정확도와 소요 자원을 원하는 수준에 맞출 수 있게 될 것이며, 마침내 무엇이 계산인지에 대해 정확한 통찰을 얻을 수 있을 것이다.

나는 CS 분야가 지금의 기초 이론에 머무르는 것이야말로 이 분야의 재앙이라고 생각한다. 지금 기계학습은 이미 CE 분야를 넘어 다른 분야의 문제를 푸는 도구로 널리 진출하였으며, 해석적 수치계산의 도구로 잘 설계된 미분방정식과 동등한 수준으로 공고히 자리매김하고 있다. 학습된 모형의 판단능력을 믿지 않는다고? 당신은 당신 자신의 지능을 너무 믿고 있다. 당신은 그렇게 과학을 해서는 안 된다.

0 notes

eonj · 6 years ago

Text

민주화살법 받아치기!

한국인들이 왜 인터넷에서 마주치는 중국인들에게 독재, 인권, 자유, 독립, 민주주의, 천안문, 프리 티벳, 타이완 넘버원 이런 주문을 외우고 있는지는 일단 당장 다루기를 미뤄 두고.

한국인들은 오늘날 “자유민주주의” 체제를 유지하고 개선해 온 역사 속에 있다는 사실을 꽤 자랑스러워하는 편인데, 아마 중국인들에게 이런 단어들을 쓰는 것도 아마 그쪽 체제에 대한 우월감을 배경으로 하고 있을 것이다. 그래서, 위 이미지가 꽤 흥해서 돌아다녔는데, 그 이유를 딱히 더 설명할 필요는 없을 것이다.

아마도 중웹에서, 한반도에서 1980년대에 체제에 저항해서 체제 불안정을 불러왔고 해외에도 이슈화된 사건이 있었고, 이를 ‘민주화 운동’으로 부르는 사람들이 공안탄압과 정치공작의 대상이 되어 왔다는 이야기가 퍼진 모양이다. 쉽게 말해 “이게 너희 나라의 폭동이라며?” 하며 끌어다 쓰는 셈. 뭐, 부분적으로는 옳은 사실이다. 애초에 전체적 맥락을 고려해서 성실하게 진실을 습득하는 것은 최종적으로 개인들의 책임이고 나는 그들에게 별 기대가 없다.

내가 궁금한 지점은, 만약 휴전선 이남 군정 시기 한국인들이 비슷한 일을 겪었다면 같은 대응이 나왔을까? 하는 질문이다. 뭐 어글리 코리안을 퇴치하기 위해 전화선 너머 한국인에게 “제주 광주 부마” 이런 공격을 하는 제3의 A국이 있었다고 해 보자. 자 그럼 가상의 한국인은 역으로 A국의 성공한 민주항쟁으로 받아쳐야 하는데, 문제는 이 A국이 존재할 조건이 너무 까다롭다는 것이다.

중앙집중권력에 의한 독재국가 내지는 과두정이었던 적이 있어야 한다. 그러나 그 독재를 자발적으로 청산하기 위한 노력이 상당해서 정치체제의 민주화를 이룩한 데 큰 기여분이 있어야 한다.

종교적 선민사상이나 인종계급론을 위시한 전쟁을 일으키는 침략국가여서는 안 된다.

웬만하면 성숙한 공화정을 운용하고 있어야 하고 ��유시장경제 기반이어야 한다.

음, 내가 알기로 1980년대 부근에 이런 국가가 없다. 세 번째 조건을 제외한다면 아마 공산권 국가들이 프롤레타리아 혁명으로 이상적인 노동자권력과 인민민주주의를 이룩했다고 자축하던 사례를 들 수는 있겠다만, 그 시기에 제정신이었다면 이미 공산주의 체제의 한계를 절감했을 것이다. 애초에 이상하게 받아쳤을 이유가 없다는 것. 아니면 보통선거로 대표자를 뽑지만 별 의미가 없고 유사군정으로 돌아가는 경찰국가들이 있는데 침략전을 하지 않는 경우가 있다. 아무튼.

어쩌면 한국인들은 꽤 잘 해 온 편일 것이다 -- 나는 한국인들이 꽤 잘 해 왔다고 생각한다. 심지어 나는 한국인들이 정말 잘 하고 있기 때문에 사람들의 역량에 비해 대한민국의 위상이 오히려 상당히 저평가되고 있는 지점이 있기도 하다고 생각한다. 그래서 나는 한국인들이 앞으로도 더 많은 것들을 잘 해 주고 한국이 꽤 괜찮은 곳이 되기를 바란다. 그리 오래 되지 않은 작은 바람이지만 앞으로 꽤 한동안 이렇게 생각하며 살 것 같다.

0 notes

eonj · 6 years ago

Text

와! 제네릭 컬렉션!

이 글은 Tumblr 마크다운 에디터의 고질적 문제로부터 도망쳐서 다음 주소로 옮겨졌습니다.

https://eonj.github.io/trouble.log/2019-06-21.wow-much-generic-collection/

0 notes

eonj · 6 years ago

Text

네이버 ‘제2 데이터센터’ 용인 건립 계획 무산... 주민들 “데이터센터는 세계적 기피시설” vs. 관계자 “지역이기주의의 폐해”

네이버에서 춘천의 데이터센터 각에 이어 두 번째 데이터센터를 지을 계획을 갖고 있었다는 사실은 꽤 널리 알려져 있었다. 조금 관심이 있었다면 네이버에서 사실상 용인 모처를 내정해 두었다는 것 역시 알고 있었을 것이다. 그리고 웃기게도 데이터센터 역시 한때 유치경쟁이 있었다. 이젠 전혀 아니게 되었지만.

제목을 무슨 평범한 기사처럼 지었다만 사실관계에 대해서는 이 글에서 더 자세히 다룰 생각이 없다. 어차피 어떤 사실을 말하고 어떤 사실을 말하지 않으며 어떤 거짓을 섞을지 결정하는 것은, 내 견해가 제일 정당하다는 주장을 맥락 속에 숨기어 여러 사람들의 생각에 유��한 사실인 양 전파하기 위해 그것이 가장 좋은 수단이기 때문이다. 이 글에는 내 개인적 의견이 투명하게 드러나 있으며 내 정치적, 사회적, 경제적 관점까지도 일부 담겨 있다. 무슨 잡설이 이렇게 기냐면 내 현재 신분과 관련해 이런 글을 발행하는 것이 입장 표명으로써 부적절하다는 지적이 들어올 수 있기 때문이다. 개인 의견에 불과하나, 그런 지적은 달게 받겠다. 그러나 내 블로그에 이 글과는 비교가 안 될 정도로 부적절한 글이 널려 있으므로 관심을 가져 주면 더 좋겠다. 물론 딱히 보고 싶지 않을 것이다. 당신의 눈에 가장 잘 띄는 것이 당신에게 가장 중요한 사실이고 명백한 쟁점이다. 당신을 존중한다.

지역사회의 승리

여러 기사들에 따르면, 네이버에서는 공식적으로 용인을 포기했다. 나는 이것이 주민자치적 공익운동의 아주 평범한 성과라고 생각한다. 데이터센터가 기피시설인 것은 세계적 추세이며 이것을 쫓아낸 것은 지역 주민들이 참 잘 한 일이다. 오랫동안 수많은 지역이익운동이 이와 같은 성공을 거두었으며 앞으로도 이런 성공이 그들에게 계속되기를 진심으로 바란다.

대체로 기업에서 시설을 새로 만들려고 할때 여러 지역에서 유치경쟁이 벌어진다. 특히 대기업의 커다란 공업단지일수록 그런 유치경쟁이 치열해지고 선호도가 높아지는데 이는 기업의 경제규모와 인적규모에는 양의 상관관계가 있으며 인적규모가 큰 시설이 들어오면 지역사회의 경제규모도 커지기 때문이다. 이런 선험적 판단은 농업보다는 공업분야에서, 연구시설보다는 생산시설에 대해서 유용하며 그렇기에 제조업 공장은 이런 유치경쟁에서 특히 환영받는 편이다. 공장은 규모가 클수록 사람이 많고 첨단공업일수록 부가가치가 크므로 지방세수도 클 것이라고 대충 짐작할 수 있다. 근로자가 많으면 그 지역에 눌러 사는 사람도 많을 것이고 우리 지역의 이익을 대변할 표심도 많아질 것이다.

그러나 데이터센터는 지역의 이익에 전혀 도움이 되지 않는다. 차라리 땅을 가만히 놔 두면 제조업 공단이 들어올 가능성이라도 열어 둘 수 있는데, 데이터센터는 그 땅에 큰 건물을 짓고 컴퓨터만 어마어마하게 몰아넣는다. 컴퓨터는 전기를 먹고 인터넷에 의존해 일하지, 사람처럼 밥을 먹고 지역 주민들의 커뮤니티에 의존해 살지 않는다. 데이터센터가 지역에 도움이 될 수나 있겠는가? 택도 없는 소리다.

그렇게 같은 논리로 서울 성북구 주택임대업자들은 고려대학교의 학생기숙사 신설에 반대하며, 판교테크노밸리의 상인들은 회사 구내식당에 반대하며, 양구 상인들은 군부대의 위수지역 폐지에 반대하며, 그렇게 플래카드를 걸고 민원을 넣고 데모를 한다. 그들은 그렇게 수시로 상생을 외치면서 지역균형발전과 지방자치에 대한 본질적 의문을 제기하는 사람들을 위한 좋은 근거로 오늘도 전국 각지에서 활약하고 있다.

투명성 없는 민주주의의 ��배

나는 지역균형발전이나 지방자치에 반대하지 않는다. 오히려 지방자치를 적극적으로 지지하는 쪽으로, 이번 데이터센터의 문제를 해결하는 최선의 대안 역시 지방자치 강화에 있다고 보는 편이다. 데이터센터가 지역주민에게 이익을 환원해 주지 못하는 이유는 데이터센터가 의존하는 물적 인프라가 주로 사회간접자본 인프라를 운영하는 국가수준의 기업들의 것이기 때문이다. 따라서 이 대안으로 각 지방행정부 관할의 영토 내에서는 지방 통신사업자, 전력공단, 토지공사 등이 배타적으로 영업을 할 권리가 보장되어야 한다. 그렇게 해야 데이터센터가 들어가서 땅과 전기와 인터넷만 먹고 있어도 그 지역에 이익을 보장할 수 있을 것이다.

그리고 이는 역설적으로 각 지역의 물적 인프라를 관할하는 공기업들이 다른 지역의 동종업계 공기업들과 하나의 시장에 진입하여 경쟁하는 신세가 된다는 것을 의미한다. 새로운 시설을 지으려는 기업 입장에서는 공기업이 물적분할되고 서로 경쟁하면 인프라의 소비자로서 이만큼 좋은 시장이 없다. 지역주민과 기업 모두 윈윈하는 시장이 되는 셈이다.

그러나 인프라는 상호보충적으로 시너지를 내며 인프라를 보강하기 위해서는 막대한 비용이 들어가는 한편, 물적 인프라는 대체로 한 지역에서 다른 지역으로 쉽게 이전할 수 없는 것들이다. 발전소나 송전시설이나 통신구나 이런 것들을 쉽게 다른 지역의 공기업에 팔 수나 있겠는가? 결국 기존에 인프라를 많이 가진 지역이 기업을 쉽게 많이 유치하여 그 결과로 더 많은 인프라를 만들 수 있을 것이고, 주민세를 이용해 인프라를 증설하거나 행사를 유치하는 개별건들의 경제효과를 부풀리는 사기성 전시행정이 더욱 급증할 것이며, 정보소외계층의 세금이 낭비되는 현상이 가속될 것이다. 이것이 최선의 대안인가? 차라리 정보접근성과 지능과 행동력에 따라 사람들이 자본주의적으로 자연선택된다고 하면 나는 할 말 없다.

그래서 나는 지역주민자치와 지역균형발전이 딱히 별 연관이 없다고 보는 편이다. 이는 사람들이나 사람의 소집단들이 대체로 자신의 중장기적 이익을 위해 합리적으로 행동하지 못하는 특성때문만이 아니다. 집단의 경쟁력을 위해 선택과 집중이 필수적이라는 역사적 상식 때문에 오늘날 수많은 시스템은 소수에게 특권을 부여하는 방식으로 설계된다. 그러나 그 시스템에서 실존하는 특별한 권리가 특별한 의무를 동반하지 않고, 특권의 존재가 부정되고, 모두가 비슷한 권리와 비슷한 의무를 지니는 시스템의 형식을 따른다면 결국 그것은 특권을 더욱 공고히 하는 데 기여한다. 그래서 특권을 견제하는 진정한 도구는 다수결이 아니라 투명성이다.

데이터센터는 정말 도움이 될 수 없을까

4차산업혁명이 진행될수록 높은 부가가치를 생산하는 첨단기술시설에서는 사람들이 사라져 갈 것이다. 자동화는 고부가가치의 핵심이고 사람은 공정신뢰도의 가장 큰 위험요소이며 첨단은 자동화와 공정신뢰도 확보의 다른 이름이기 때문이다. 오늘날 데이터센터가 인터넷 서비스 기업이나 컨텐츠 서비스 기업에서 소외지역에 비용만 전가하고 이익을 환원하지는 못하는 기피시설의 대표주��이지만, 앞으로는 더 많은 공업시설들이 그런 운명의 길로 접어들 것이라는 뜻이다. 단적인 예로 유로존에서 유로 강제의 역효과로 독일이 돈을 벌고 있으며 비행기나 기계부품을 만드는 공장이 있는 국가들은 돈을 전혀 벌지 못하는 현상이 이런 사실을 한 원인으로 하여 나타나는 것이며, 만약 한국에서 자동차 공장이나 조선업의 경쟁력을 앞으로도 그럭저럭 가져간다면 차세대 공장들도 비슷한 방식이 될 것이다.

나는 이론적으로는 컴퓨터에 이식된 자동화된 역무도 그것을 수행하는 소프트웨어의 개발자에게 소속된 지적자산이며, 그런 자동화 역무의 개별건에 가치를 매겨 개발자에게 비용을 지불해야 하고, 해당 역무가 실제로 수행되는 지역에 그 비용에 대한 부가가치세를 납부하도록 하는 것이 유일한 깔끔한 해법이라고 생각한다. 그러나 이는 공산주의적 이데아만큼이나 실현가능성이 없으며 시스템 전체의 경쟁력 관점에서 너무나 취약하기 때문에 이런 시스템이 도태될 것이라고 생각한다.

진짜 해법은 자연스러움 속에 있다. 필수적인 인프라, 대규모의 데이터센터, 첨단 공장일수록 그곳에 내재된 지적자산의 가치는 어마어마할 것이며 소비자들이 그곳에 간접적으로 비용을 지불하고 국가적으로 여러 보호와 지원을 받게 된다. 이를테면 통신 인프라와 더불어 네이버 데이터센터 각은 국가 주요 방호시설로 지정되어 국방자원이 할당되어 있고 전시작전이 구성되어 있다. 따라서 재난상황에서 지역주민이 향유할 수 있는 전력, 급배수, 교통, 통신, 물자보급 인프라에 있어서도 지역에 동원될 수 있는 자원의 규모가 달라지게 되며 이는 지역주민들에게 자명한 이익의 낙수효과이다.

반도체 관련 첨단 공장을 환영하지만 데이터센터를 반대하는 지역주민 당사자들의 의견을 묻고 싶은 심정이다: 만약 그 공장의 공정자동화 수준이 높아서 사람들이 별로 다니지 않고, 공정신뢰도 상승을 위해 알려지지 않은 맹독성 물질을 사용하고 있으며, 실제 부가가치가 있는 상품을 만들지도 않아서 지방세 납부가 별로 없을 지경이라면, 당신은 여전히 그 공장을 환영하겠는가? 대강 아니라고 생각하지만 그런 가정에는 별 의미가 없으며 내가 그런 질문을 할 수도 없으므로 잊고 지나가기로 한다. 어차피 아직 사람은 평균적으로 백 년도 다 살지 못한다. 그리고 나중에 알고 보니 공장이 지역의 기대를 배신한다면 신문기자들이 다룰 쟁점이 생기니 그것도 좋겠다.

지역경제와 기피시설

기피시설은 실존한다. 개별 기피시설의 종합적 효과가 좋든 나쁘든, 아무튼 기피시설로 퉁쳐지는 무언가의 존재는 내지인과 외지인들의 경제활동을 위축시키며 지역경제에 악영향을 준다. 그래서 지역경제의 주도권을 가진 당사자들은 대개 쓰레기장보다는 요양원에 살고 싶어하고, 요양원보다는 공업단지에, 공업단지보다는 혁신도시에, 혁신도시보다는 관광지에 살고 싶어한다. 그러나 관광지가 양산되는 것은 문화산업적으로도 여러 문제를 동반하며 정책적으로는 이 중 쓰레기장을 잘 만드는 것이 가장 중요하다. 그래서 요즘은 문화 인프라와 업무지구에 주거기능과 교통, 교육이 보강된 혁신도시를 만들고 그 안에 쓰레기장 따위를 넣어서 신설 도시복합체의 기능적 ��립성을 도모한다.

그러나 이런 정책기조가 언제까지나 효과를 발휘할 것이라고는 기대하기 힘들다. 머지않아 각 지방의 정책결정에 강력한 영향을 주는 수준의 인구와 경제규모를 확보하는 혁신도시들이 생겨날 것이며, 성공한 신도시들처럼 선호시설을 더 많이 끌어오고 기피시설을 자꾸 밖으로 내보내려 할 것이다. 기피시설 이용량에 대해 지자체 간에 비용을 정산하도록 할 경우 결국 가장 크게 힘들어지는 건 도시빈민들이며 도시빈민들의 가난은 지역의 비극으로 소비될 것이다. 그래서 생산기술이 발전하고 자원이 충분히 남아서 기존 신도시의 문화 인프라를 별 것 아니게 만들어 버리는 과정은 지역균형발전에 있어 매우 중요하다. 국가가 존속하는 한 중앙행정부는 또 다른 신도시를 구성해서 기존 신도시의 주도권을 빼앗는 방식으로 지역경제의 수명을 관리할 수 있다.

한편 기술시설의 입지에 대해서는 생산기술 발전의 역할이 다소 다르다. 지금까지 공업단지는 대체로 소외지역에서라도 주변에 유치했을 때 이득이 되는 것으로 취급되었고 그래서 심지어 혁신도시에서도 공업단지 조성은 장점으로 알려져 있다. 그러나 4차산업혁명의 성과들이 이런 대중적 시각을 조만간 크게 뒤집어 놓을 것이며 기술시설은 쓰레기장이나 별 차이가 없어질 것이다. 데이터센터 입지 논쟁은 그런 전환의 시작점에 있을 뿐이며 앞으로는 그런 기술시설의 존재가 국가적으로 어떤 특별대우를 받으며 그것이 지역주민에게 어떻게 이득이 될지에 따라 기술시설은 입지를 찾을 수도, 찾지 못할 수도 있다.

그렇게 사람들은 부지불식간에 첨단 정보기술과 4차산업혁명까지도 기존의 국가적 질서에 편입시키는 데 일조하며 그렇게 아래로부터의 혁신은 갈 곳을 잃는다. 인간의 사고능력은 높은 편이지만, 그것을 활용해 자신에게 도움이 안 되는 체제변혁에 저항하고 적을 만들어 공격하는 것이야말로 인간의 본성일지도 모른다. 그리고 만약 이것이 사실이라면, 평등이 공정이라 믿고 지역주민자치가 지역균형발전의 핵심이라고 생각하며 불투명한 특권을 없는 셈치고 살아가는 눈 먼 민주시민들은 앞으로도 별로 줄지 않을 것이다. 솔직히 이런 결론은 나도 원하지 않으므로 다들 자신이 조금은 갖고 있는 얄팍한 지역이기주의를 들여다 보는 시간을 잠깐만 갖기를 바란다.

0 notes

eonj · 6 years ago

Text

블록체인 대잔치

4차 산업 혁명(이하 4IR), 창조경제(이하 CI/CE; 창조산업과 더불어), 이런 버즈워드로 인해 IT업계가 들썩거리는 것은 사실 어제오늘 뉴스가 아니다. 많은 사람들은 정보기술과 통신기술의 고도화에 대한 이해를 포기하고 이를 교양지식에 편입하는 것을 거부해 왔다. 이 때문에 컴퓨터와 소프트웨어 분야에서 새로이 만들어지는 무언가의 중요성을 사회에 널리 알리기 위해서는 다른 분야에서 요긴하게 쓰이는 키워드를 조합하여 �� 어휘를 탄생시키는 방법이 널리 사용되었다. 한때 최악의 버즈워드는 Web 2.0이었고 Ubiquitous였으며 Big data였다; 희한하게도 이것들 모두 결국 실체가 있게 되었지만 말이다. 놀랍게도 Artifial intelligence와 Deep learning도, Smart technology나 Internet of Things도 결국 그렇게밖에 부를 수 없는 애매한 무언가로 발전한 것이다. (이들 각각에 대한 이야기는 나중에 따로 풀 기회가 있을 것이다.)

4IR이나 CI/CE가 비슷한 길을 걷고 있긴 한데 거기에 블록체인이 들어갈지는 잘 모르겠다. 4IR이나 CI/CE는 역사적인 버즈워드들에 비하면 목표지점과 범위가 명확한 편인데 애초에 이들 둘 다 블록체인 산업과는 거리가 먼 개념이기 때문이다. 블록체인 산업을 육성하는 정책으로는 4IR과 CI/CE에 가까워질 수 없다는 것이다. 그러나 희한하게도 아무튼 블록체인은 개인의 참여적 생산을 전제하고 창조성을 보장한다는 면에서 4IR과 CI/CE와 깊은 연관이 있는 것으로 비추어지며 블록체인 기반으로 4IR이나 CI/CE를 바라보는 프로젝트가 많이 생겨나고 있는 것도 사실이다. 도대체 무슨 일이 일어나고 있는 것일까?

4IR

이런 복잡한 상황에 대해 제대로 이해하려면 일단 4IR과 CI/CE에 대한 개념을 먼저 이해하는 것이 좋겠다. 4IR은 비교적 최근에 알려져서 꽤 생소한 단어이지만 한국어 화자 문화권에는 이전부터 널리 알려진 유사개념이 있다: 정보화의 물결(3W). 3W는 농업-산업-정보화로 이어지는 세 번째의 인류문화사적 혁명이 실현되고 있다는 이론이다. 대체로 농업 시대는 노동집약적이었고, 산업 시대는 그 중간 특성을 띠며, 완전한 정보화의 시대에 와서야 모든 것들이 지식집약이게 되는 것으로 간주된다. 또한 이 새 시대에는 모든 시장활동이 개인화되고 정부 서비스가 똑똑해지며 개인의 생산이 보장될 것으로 기대된다. 여기까지는 대한민국 중등교육 수준 교양으로 꽤 널리 알려진 이야기이며 3W는 거의 실존하는 것으로 취급된다.

그러나 사실 3W 이론은 상당한 비판을 마주하였다. 산업 혁명의 경우 대량생산의 시대를 불러온 굵직한 사건들의 실체가 분명하며 국가체제와 전쟁 수준에 이르는 엄청난 변화를 가져온 것이 확실하지만, 정보 혁명의 경우 소수주체가 없고 변화양상이 너무 작고 다양하기 때문이다. 또한 3W 이론은 정보화의 토대가 된 기존의 산업구조를 도구화/타자화하여, 대강 결국 모든 것이 정보화를 통해 다시 뒤집어질 것이라고 말하고 있다고 할 수도 있다.

3W 이론이 대륙간 갈등과 대결 구도에 알맞은 이념적 특성을 지닌다는 지적도 있다. 농업 혁명은 호모 사피엔스가 아프리카 대륙을 나와서 사람속 유인원 중 최강자가 되고 인류의 문화가 존속하는 데 결정적인 역할을 하였으며, 산업 혁명은 그 주도권을 서유럽 국가들에게 넘겨주는 계기가 되었다. 정보 혁명이 정말로 산업 혁명만큼의 파급효과가 있다면 세계 질서�� 주도권은 미국으로 완전히 넘어갈 것이다

4IR은 3W와 비슷한 미래를 예견하지만 이념적으로 완전히 대척점에 있는 이론체계이다. 4IR 이론은 오늘날 인류가 산업 혁명의 네 번째 단계에 있다고 판단한다. 첫 번째 단계는 흔히 산업 혁명 그 자체로 표상되는 증기기관과 같은 동력원을 통한 자동화였다. 두 번째 단계는 자동화를 통한 여러 공학적 분야의 발전이었는데, 하나는 재료공학적 양질 대량생산과 그에 따른 소형/정밀 기계공정의 발전이다. 다른 하나로 더 중요한 것이 모터 즉 전동기와 전력산업이다. 그리고 산업 혁명의 세 번째 단계가 바로 초미세공정의 발전과 컴퓨터의 발명/발전이다. 즉 4IR은 3W의 초기전제를 산업 혁명의 연장선상에 놓는다.

4IR의 핵심은 그 이름에서 보이듯 산업 혁명의 네 번째 단계인데, 컴퓨터의 일반사무적 이용을 넘어 컴퓨터 자체를 생산체계에 결합시켜 생산의 효율과 개별성을 높이고 이를 통해 공정신뢰도와 상품개체의 개인화를 노리는 것이다. 여기서 등장하는 개념으로 대표적인 것이 가상물리시스템(CPS)이며, 그 밖에 전산기계제어와 로보틱스, 인공지능, 산업 IoT -- 그리고 탈중앙화된 정책체계가 있다.

결과적으로 3W나 4IR 중 어느 쪽만이 옳고 어느 쪽은 틀렸다고 말하기는 힘들다. 미국은 WW2 이후 정보전(첩보전; 지능전) 능력을 토대로 세계 패권을 쥐었고, 정보기술과 관련된 국가 간 갈등 양상이 실존하며, 공공서비스나 시장에서의 정보불균형은 상당한 사회갈등을 유발하는 한편 유튜브는 완전히 세계 국경을 넘었다. 그러나 정보를 많이 모으고 대세를 만들기보다는 안전과 정확성에 집중해야 하는 생산체계가 있으며, 시장이 고도로 개인화되더라도 그런 생산체계의 바탕은 결국 대량생산이라는 산업혁명의 물리적 토대에 있다.

CI/CE

CI/CE는 정보 사회의 산업적이지 않은 측면에 대한 분석으로 4IR보다는 좀 더 오래되었으며 다소 무른 이론이다. 사실 이 역시 창조경제나 창조산업보다는 더 널리 알려져 정책적으로도 오래 쓰인 유의어가 있다: 문화산업. 문화산업이라는 표현은 오늘날 대자본의 개입으로 전통적으로 가내수공업적, 장인정신적 기예의 영역��었던 문화요소들이 산업화되는 현상을 표방한다. 건축공학과 건축디자인, 레이아웃과 시각디자인, 제품생산과 산업디자인, 도서/사진/음악/영상(TV/영화) 등이 CI/CE에 포함된다. 그 밖에 CI/CE의 근간을 이루는 영역으로 광고가 있으며 플랫폼으로써 IT와 소프트웨어가 존재한다고 알려져 있다.

CI/CE는 양면성을 갖고 있는데, 산업혁명으로 인한 사회 자본규모의 급성장을 따라 문화산업이 문화콘텐츠를 생산해 내기 때문에 대중의 문화적 획일화와 몰개성을 만들 수 있다는 것이 어두운 단면이다. 그러나 반대로 누구든 문화요소를 문화콘텐츠로 만들어 배포할 수 있는 수단과 플랫폼에 접근할 수 있으며, 이전에는 이런 일이 국가체제 수준에서나 할 수 있는 고비용의 일이었으나 이젠 누구나 대중적 지지를 바탕으로 영향력을 획득할 수 있는 것이다.

CI/CE의 기본적 가정은 바로 인간의 창조성이야말로 인간 사회에서 ��장 중요한 궁극적 자원이라는 것이다. 이는 물론 앞서 설명한 농업 혁명과 산업 혁명 등으로 인해 물질적 자원이 충분히 풍요로워졌을 때의 이야기이지만, 반대로 정신적 자원이 물질적 자원의 풍요를 부추기는 현상도 나타난다. 여기서 가장 중요한 것이 바로 지식재산권인데 실용적인 생각이나 고유한 생각을 재산으로 취급하여 소유자에게 그것을 행사할 수 있는 독점적 권리를 부여하는 것이다.

상표권과 정보인권 계통을 제외하고 나면, 지식재산권은 기본적으로 어떤 아이디어나 표현의 고유성을 전제하여 그에 대한 독점적 재산권을 인정한다. 오늘날 근대 국가들은 지식재산권과 관련된 다수의 국제협약을 통하여, 아이디어 수준에서 고유하며 실용성이 있는 것은 실현가능한 것에 특허를 부여하며, 산업적 실용성은 없으나 고유한 표현으로써 실현된 것에는 그 역시 산업적 가치가 내재되어 있는 것으로 보아 저작권을 부여한다. 지식재산권은 즉 재산을 생성하는 원천 역시 재산으로 보는 것이며, 이는 전통적으로 기술적 노하우나 예술적 활동에 가치를 인정하고 보호하던 불문법과도 맞닿아 있다.

이렇게 보면 정책적으로 CI/CE의 그림자를 최대한 줄이고 모든 개인이 아이디어를 내는 주체로서 보호받는 사회가 되어 가는 것 같으나, 인지능력이 좀 떨어지는 게 아니라면 사회 현실이 그렇지 못하다는 것을 알고 있을 것이다. 대부분의 근대 국가 민법/상법 체계에서는 고용인이 생산한 지식재산에 대한 권리는 고용주(사업체)에 귀속되며 이는 회수할 수 없다. 창의성이야말로 진정한 자원인데, 자본 기반의 사업체가 안정된 자본과 시스템을 제공한다는 이유로 창의성 자체를 소유할 권한을 갖는 법적 근거가 있는 것이다. 또한 행정-사법체계가 소자본과 대자본 간의 지식재산 관련 분쟁에서 공정하고 엄정한 대응을 보이지 못하는 모습 역시 허다하다. 가장 큰 문제는 국가 간 관계인데, 지식재산 역시 돈이 돈을 버는 논리를 그대로 따르기 때문에 국제 관계에서 사다리 걷어차기가 일어난다는 것이다. 유형재산이나 화폐라면 분배라도 가능하지, 지식재산은 분배하기도 애매하다.

CI/CE의 그림자가 꼭 지식재산권을 인정하기 때문에 벌어지는 문제는 아니라고 볼 수도 있다. 특허나 저작권보다도 사실 더 큰 것은 안정된 시스템을 운영하는 노하우이며 이것은 국제특허 따위로 공개출원등록되지도 않는다. 이런 부분 역시 사업비밀이나 군사비밀 등 각종 법적 근거로 보호되는데, CI/CE가 이런 모든 역작용을 옹호하고 있는 것은 아니다. 결과적으로 CI/CE 관점에서의 이상적 사회는 누구든 자신의 생각을 널리 알리고 가치를 인정받아 경제적으로도 보상을 받는 것이며 이 때문에 CI/CE의 이상 역시 탈중앙화된 정책체계로 대변된다.

블록체인

이쯤 되면 4IR와 CI/CE가 공통적으로 탈중앙화된 정책체계라는 것을 이상으로 두고 있으며 별 관련도 없어 보이는 둘이 묶여서 희한하게도 블록체인이라는 것이 잘나가는 이유를 알 수 있을 것이다. 그런데 우리는 블록체인 자체에 대해서는 얼마나 알고 있을까? 블록체인이 정말 탈중앙화된 정책체계를 만들어 줄까?

놀랍게도 블록체인은 탈중앙화된 정책체계를 위한 도구가 맞다. 보다 정확히 말하자면, 블록체인은 처음부터 임의의 정책체계에 속한 개체들로부터 정책결정을 검토하고 승인하는 특수관계의 개체의 존재를--즉 ‘중앙’을--제거하기 위해서 고��되었다. 블록체인에 무언가를 넣으면, 중앙 없이도 잘 돌아가게 할 수 있다. 정말 놀라운 일이다. 지금까지 중앙 집중된 관리체계를 유지하기 위해 들어간 모든 비용은 다 허상이었다.

물론 거짓말이다. 블록체인은 그 정책체계의 모든 개체에 적용되는 기본법의 명령이 중앙의 존재를 부정하도록 작성된 경우에만 탈중앙화가 이루어진다. 다시 말하자면 기술적으로 블록체인은 그냥 탈중앙화를 도와주는 수단일 뿐이라는 것이다. 게다가 그 정책체계 역시 대체로 폭력적이기 그지없어서, 절대 다수의 블록체인은 어떤 결정이 승인되는 조건을 과반의 찬성으로 두고 있는 것이 정책 기조이다. 대체 뭐가 문제인지 짚어 보자.

경제학에는 불가능의 삼각형이라는 개념이 있다. 개방경제 모형인 IS-LM-BoP 모형에서 어떤 국가가 고정환율(환율안정), 자본이동자유화(자본통제금기), 통화정책독립성의 셋 모두를 달성하는 것은 불가능하다는 것이며 이는 수학적으로 그럴듯한 증명도 되어 있다. 고정환율로 안정된 미래를 도모하고 시장도 세계에 개방하면 통화정책을 정하는 데 다른 국가들의 눈치를 봐야 한다. 아무튼 많아야 둘을 달성가능하며 최소 하나는 포기해야 한다. 물론 이 모형에 예외는 있으며 경제학답게 거의 모든 국가가 조금씩 예외이지만 말이다.

컴퓨터에도 이와 꼭 닮은 이론이 있는데 CAP 삼각형이라고 한다. 시계열에서 변하는 어떤 자료를 관리하고자 할때 그 자료의 일관성(consistency), 가용성(availability), 분할내성(partition tolerance)의 셋을 동시에 달성할 수 없다는 것이다. 만약 자료가 쉽게 여러 위치에 단순히 나뉘어 보관되어 있으면, 일관성을 맞추기도 어려울 것이고 필요할 때 특정 자료를 찾아내기도 어려울 것이다. 자료를 여러 곳에 똑같이 복제하여 보관하면 이를 피할 수 있나 싶었는데, 또 특정 자료를 찾으려 할 때마다 여러 곳에 있는 자료가 다 똑같은지 점검해야 자료의 정확성을 보장할 수 있거나, 새로운 자료를 넣을 때마다 동일성을 맞춰야 할 것이다.

이론적으로 CAP는 셋 다 맞출 수 없지만 제정신인 IT 기업이라면 셋 다 맞추기 위해 애쓴다. C가 없으면 사용자에게 이상한 것을 보여주게 되고 A가 없으면 사용자와 소통할 수 없는 장애상태가 되며 P가 없으면 시스템에 큰일이 났을 때 돌이킬 수 없게 된다. 이 중 최고는 당연히 구글로 전 지구 각지의 데이터센터에 원자시계를 두고 위성통신을 비롯한 각종 보정기법을 이용해 시계 시간을 최대한 정확하게 맞춘다. 그럼 A와 P를 보장하면서 적어도 C가 너무 오랫동안 크게 잘못되지는 않게 된다.

블록체인의 기술적 의의에 대한 수많은 서술이 있지만 근본적으로 블록체인은 CAP 문제를 다소 다른 방식으로 푼다. 자료에 대한 조작은 결국 변경되거나 열람하거나 둘 중 하나인데, 변경하는 조작의 가용성을 매우 낮추면 열람하는 조작의 가용성을 매우 높인 채로 일관성과 분할내성도 높게 유지할 수 있게 된다. 이는 상태를 변경하는 조작이 근본적으로 시계열에서 일관성과 분할내성에 악영향을 줄 수 있기 때문이다. 따라서 변경 이전의 값과 변경에 투입되는 값을 비교하여 변경 이후에도 일관성이 유지될지를 검증하는 것이 필수로 해결해야 하는 문제가 되며, 널리 알려진 첫 블록체인인 비트코인이 이를 작업증명(PoW)을 도입하여 탈중앙화하여 풀었기에 블록체인은 흔히 비잔틴 문제를 푸는 방법이라고 알려지게 되었고 분산원장기술이라고도 하게 되었다.

한 가지 주의할 점은 블록체인의 핵심 프로세스는 탈중앙화 가능한 정책결정 그 자체라는 점이다. 즉 블록체인이 CAP 문제를 좀 다르게 풀긴 하는데, 분할내성의 기본 가정은 그냥 블록체인에 실존하는 문제로 남았다. 따라서 변경하는 조작이 승인된 이후에도 모든 개체가 그 조작의 결과를 즉시 열람할 수 있는 것은 아니다. 물론 자료들은 분산 보관되기 때문에 일단은 그럭저럭 즉시 열람 가능하다. 블록체인은 처음부터, 그렇게 미처 덜 조작된 상태가 즉시 열람되는 것이, 일관성을 잃지 않는다고 정의한다. 즉 블록체인의 단점은 즉각적으로 최신 정보를 요구하는 시스템에 치명적이다. 또한 블록체인은 과반찬성 승인정책을 따르며 높은 가용성을 보장하려 하기에 대체로 모든 개체들에게 분산 보관되며 따라서 기밀성을 요구하는 시스템에도 치명적이다.

대체 왜 그러세요

정보기술과 통신기술의 각 분야는, 여러 표준이 공존하면서 장점을 살리고 단점을 보완하며 서로 닮아 가는 방식으로 흘러 왔다. 데이터베이스 분야도 마찬가지여서 전통적 강자인 RDBMS/SQL이 있고 그 라이벌인 ODBMS/NoSQL이 있으며 최근에는 GraphDB/GraphQL이 대두되는 등 꾸준히 특정목적의 신식 표준이 분화되고 또 구식 표준은 신식 표준을 참고하며 발전해 왔다. 대체로 장점이 고만고만한 상황에서 기술적 결정은 주로 치명적 단점을 피하는 방식으로 이루어져 왔다.

블록체인은 장단점이 명확한 신기술이다. 위에서 정리했듯 실시간성도 모자라고 기밀성도 보장되지 않는다. 물론 블록체인을 잘 개량하면 실시간성을 조금 개선할 수 있다. 기밀성 역시 개선할 수 있다. 그러나 그렇게 개량된 블록체인의 실시간성과 기밀성조차도 기존의 중앙집중화된 데이터베이스에 비할 것이 못 될 정도로 처참하다.

그러나 블록체인의 장점을 살리는 프로젝트 역시 곳곳에서 진행되고 있다. 이더리움, 리플이나 모네로와 같이 암호화폐인 블록체인의 발전형으로 거래의 일부로 형식화된 계약을 거래내역과 함께 박제하여 승인하는 동시에 성능을 높이려는 시도들이 이루어지고 있다. 네오, 이오스, 스텔라루멘 등은 여기서 더 나아가 암호화폐 간의 환전 플랫폼이 되고자 하고 있으며, 베이직어텐션토큰이나 온톨로지토큰 등은 새로운 실용적 구현이나 독창적 표현물의 유통을 돕는 플랫폼이 되려고 하고 있다. 기술과 컨텐츠를 실어나르는 블록체인이 세계공용화폐가 된다면 그야말로 국경이 없는 사회가 되고 4IR과 CI/CE의 꿈이 이루어질 것이다. 물론 연산성능은 엄청나게 많이 필요할 것이며 다수의 플랫폼이 중앙 통제 기반으로 설계되고 있지만 말이다.

위에 열거한 것은 희망편이다. 절망편을 보자. 한번 블록체인을 통해 개인정보가 유통되면 그것은 영원히 블록체인에 박제된다. 블록체인은 조작기록의 나열이며 통제자가 없으니 완전히 지울 수도 없다. 버그투성이의 코드로 만들어진 스마트 계약이 수두룩하며 허공에서 돈이 사라지고 있다. 완전한 분산결정을 하기에는 너무 많은 컴퓨터의 연산성능이 필요하고 시간적 비용을 극복하기 위해 결국 자료를 충분히 검증하지 않거나 중앙통제자가 검증한다. 기밀성이 훼손되고 일관성이 떨어지며 성능이 나쁘고 결국 중앙통제자가 등장하였다.

개인적으로 블록체인 기반의 신규 서비스/시스템 아이디어 중 가장 경악스러운 것이 두 가지 있었는데 하나는 요즘 소식이 안 들리는 것으로 블록체인에 국민의 의료기록정보를 공공자료로 풀겠다는 것이었다. 블록체인 네트워크는 기본적으로 공개인데 의료나 제약 관련 산업의 부흥을 위해 의료기록과 같은 민감한 정보를 거기에 싣겠다는 기사였다. 암호화야 당연히 하겠지만 기본적으로 모든 암호는 풀린다. 열람할 사람에게 복호화가 가능해야 하므로 양방향 암호화일 것이고, 단방향 암호화도 사실 언젠가 풀리는 건 마찬가지다. 그런 고급 정보를 평문으로 뽑기 위해서라면 암호해독에 총력전이 가해질 것이다.

두 번째는 현재진행형인데 은행에서 금융기록정보를 블록체인으로 관리하겠다고 하는 것이다. 다행히 금융 관련해서는 정부의 감시가 살벌하니 당연히 공개 블록체인으로 관리하지는 않고 사설화하겠다고 한다. 그러나 자료를 공개하지도 않을 것이고, 결국 어떤 권위있는 개체가 데이터베이스의 일관성을 통제할 것이라면, 뭐하러 전체적인 비용을 상승시키는 결정을 하는가? 대체 왜 중앙집중하여 관리해야 CAP와 기밀성을 손쉽게 확보할 수 있고 그래야 하는 종류의 자료를 블록체인으로 관리하는가?

ㅎㅎ는 흑흑입니다만

CAP와 기밀성이 생명과도 같은 자료를 유지하기 위해, CAP와 기밀성에 손해를 보면서까지, 자료를 중앙집중해 관리하지 않는 이유는 무엇일까? 아는 사람도 있고 눈치챈 사람도 있겠는데, 자료를 중앙에서 직접 관리하지 않는 것이 바로 그 목적인 것이다.

자료를 중앙에서 직접 관리하면 권위 있는 개체가 해당 데이터의 CAP라든지 기밀성이라든지 하는 모든 요구사항에 대한 책임권한을 지게 된다. 이는 어떤 사고가 발생했을 시에 금융과 같은 고신뢰 요구 시스템에서 특히 큰 대응비용의 발생을 초래하며 심한 경우 금전적 피해에 대한 배상책임까지도 안게 될 소지가 있다. 그러나 블록체인을 사용하면 기밀성의 책임을 모두에게 지우고, C를 담당하는 외주회사가 있고 또 A를 담당하는 외주회사가 있으며 블록체인이니 자동으로 P가 보장되게 된다. 그렇게 책임의 외주화를 위해 블록체인이 쓰인다.

보안 분야의 격언이 있다. 사슬의 강도가 가장 약한 고리의 강도로 결정되듯, 어떤 시스템의 보안성능은 그 중 가장 약한 서브시스템의 ��안성능만큼으로 귀결된다. 권위 있는 단일책임주체의 관리가 필요한 자료에 대한 관리를 분야별로 외주화한다면 조만간 어떤 사고가 발생해도 누가 그 책임을 져야 하는지조차 불분명해지게 될 것이다. 블록체인을 도입하자고 한 갑? 아니면 그것을 내버려둔 슈퍼갑? 아니면 최초에 블록체인을 발명한 익명의 외계인? 미래는 알 수 없다.

적어도 지금 블록체인이라는 마법단어에 홀려 4IR 버스와 CI/CE 기차에 올라탈 수 있다고 생각하며 투자를 감행하고 있는 사람은 정신차리기 바란다. 블록체인이 4IR이나 CI/CE에 기여할 수 있는 방법은 그런 것이 아니��. 그렇게 도입한 블록체인이 조만간 크게 뒤통수를 칠 것이며, 이렇게 블록체인을 마법단어로 부양시키며 교묘하게 큰 판을 짠 누군가는 절대 당신 대신 책임져 주지 않는다. 단적인 예로 의료와 금융을 들었지만 당연히 그 둘이 전부가 아니다. 이런 오늘날의 현실은 사실상 블록체인 대재앙, 아니 블록체인 대잔치이다. 축배를 들어라, 잔치에서 길을 잃지 않는 건 당신 책임이고 4IR이든 CI/CE든 하고 싶다면 블록체인은 좀 아니다.

1 note · View note

eonj · 6 years ago

Text

User-Agent:

한 웹서비스가 클라이언트 웹브라우저마다 다른 컨텐츠를 보여주는 것이 가능한 일일까? 내가 이전에 UA detection considered harmful, and so on 이라는 글에서도 다루었지만, UA 문자열을 이용해 이런 일을 하려는 시도는 정말 많이 있었으나 사실상 모두 패작이었다.

UA 문자열을 해석하려 드는 게 거의 무의미하다는 사실은 오늘날 웹 개발자 대부분이 알고 있는 부분이다. 그렇기에 각 웹브라우저 벤더들은 그냥 빠르게 자동 업데이트를 한다. 웬만하면 이전 버전의 버그는 현 버전에서 고치고, 다음 버전에서는 동종의 버그가 재발하지 않기를 빌면서. 그러나 그런 일은 일어나지 않으므로 웹브라우저들은 꾸준히 업데이트를 하고 유저들은 버그를 만날 가능성을 품고 살아가는 것이다.

서비스 기획자나 디자이너 등의 직군에게는 이 사실이 잘 와닿지 않을 수 있다. 어쨌든 UA 값의 동일성으로부터 브라우저의 동작을 특정할 수 있다. 즉 UA 값에 들어 있는 웹브라우저 종류/버전, OS 종류/버전 등에 따라 클라이언트의 작동을 정확히 알 수 있으면 그에 대응하는 코드를 짤 수 있는 셈이다. 그러나 그건 불가능하다. 즉 이는 어느날 업데이트된 새 웹브라우저 버전에서 새로 출시한 서비스에 심각한 장애가 발생할 수 있는 가능성을 의미한다. 이는 특히 관리자나 비즈니스맨 관점에서 매우 큰 미지위험이다. 그래도 개발자들은 그렇게 할 수 없다. 왜 이런 일이 벌어질까?

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3788.1 Safari/537.36

뭐 이런 걸 대뜸 보여준다고 해서 정확히 이해할 수 있었으면 애초에 이 글을 읽을 필요가 없을 것이다. 그러니 사실관계를 살짝 왜곡하지만 이해하기 쉬운 현실적 비유를 들어 설명해 보겠다.

어느날 이미 잘 된 밥을 국으로 끓여 먹는 식사가 등장했고 이는 태초의 국밥이었다. 국밥은 성공했다.

손맛 좋은 할매가 이 기회를 틈타, 국밥을 만들어 팔고 돈을 받는 집을 차렸다. 국밥은 훌훌 마��고 금방 떠날 수 있었기에 국밥집은 요식업계를 통틀어 대성공했고 할매는 영리하게도 가게 이름을 할매국밥으로 브랜딩했다.

할매국밥은 크게 소문이 났고 사람들은 다른 국밥집에서도 할매국밥의 맛을 느끼기를 바랐다. 옆집 할매는 손님들 기분이라도 좋으라고 자기 집의 이름을 원조 할매국밥으로 바꿨다. 원조 할매국밥은 특급 성공을 거두었다.

할매국밥은 망했고 원조 할매국밥이 세상을 지배했다. 처음 할매국밥을 차린 할매는 눈물을 흘리며 칼을 갈았다. 몇 년 후 그 할매는 전주콩나물국밥을 갈고닦아서 원조 삼십년전통 할매국밥 전주콩나물국밥을 차렸다. 첫 성공만큼은 아니지만 찾는 사람이 많았다. 전주콩나물국밥을 배워 가서 새 국밥집을 차리는 사람도 있었다.

지나가던 할배는 자기도 국밥집을 차리고 싶었다. 그래서 할배국밥을 차렸지만 특유의 구린 이름 때문에 할배국밥은 망했고, 할배가 차린 다음 식당인 원조 할매국밥 할배의 손맛이 어떠냐!는 똑같은 국밥 맛으로 그럭저럭 흥행을 누렸다. 할배는 중간에 원조 할매국밥 이젠 할배의 손맛이다!로 이름을 바꾸기도 했다. 이 할배는 나이가 많아서 장사를 오래 못 하고 접었다. 아무튼 이제 식당 이름에 원조나 할매국밥이나 원조 할매국밥이 들어가야 성공한다는 생각은 거의 기정사실이 되었다.

또 다른 할매는 원조 할매국밥과 비슷한 시기에 국밥집을 열었지만 역시 잘 되지 않았다. 그래서 그 할매도 국밥집 이름을 전통 할매국밥 원조 수육국밥 돼지국밥으로 바꿨다. 아무튼 그 국밥집도 꽤 잘 됐다.

소싯적에 돈을 벌어 놓은 할배가 국밥집 사업에 욕심을 냈다. 그래서 할배는 할매한테 수육국밥과 돼지국밥 레시피를 받아서 서울 2호선 교대역 근처에 부산 할배의 할매국밥 원조 수육국밥 돼지국밥을 냈다. 할배는 옛 지인들을 통해 자기 국밥집에 대한 좋은 소문을 냈고 할배가 국밥을 잘 하는 걸로 소문이 났다. 이제 꽤 많은 사람들은 흔한 할매국밥 맛이 아니라 할배의 할매국밥 맛을 찾았다.

더 돈이 많은 친구 할배가 신이 나서 자기도 분당에 국밥집을 차렸고 부산 영도 할배의 할매국밥 원조 수육국밥 돼지국밥이라고 이름을 지었다. 이 미친 이름의 국밥집은 국밥을 정말로 잘 만들었기 때문에 드디어 원조 할매국밥보다 할배의 할매국밥이 맛있다는 여론이 형성되었다. 원조 할매국밥은 이제야 망했다. 사람들은 이 집을 그냥 영도국밥이라고 불렀다.

원조 할매국밥을 만들던 할매는 피눈물을 흘리며 일산에 원조 할매국밥 전주콩나물국밥식 녹두나물국밥을 내기도 하고, 대전에 할매국밥 원조 전주콩나물국밥식 부산 수육국밥 돼지국밥 소고기국밥을 내기도 하고, 심지어 빚을 내서 압구정에 할배의 할매국밥 새우젓 넣은 원조 전주콩나물국밥 원조 부산 수육국밥 원조 부산 돼지국밥 그러나 진짜 국밥은 녹두나물국밥 그리고 소고기국밥을 내기도 했는데 불행인지 다행인지 아무튼 이것들은 다 망했다.

다행히 전주콩나물국밥은 처음에 손맛 좋던 할매가 계속 했다. 전주콩나물국밥은 짓기도 어렵고 즐겨 먹는 사람도 적었다. 그래서 다른 할매들와 할배들은 전주콩나물국밥을 차리는 대신 힘을 합쳐서 전주콩나물국밥이 맛없다는 마타도어를 퍼뜨리기 시작했다.

뻥이나 구라 아니냐고? 솔직히 그러면 좋겠다. 다 사실 기반이다.

사설이 길었다. 그런데 그만한 가치가 있는 스토리이다.

위 스토리에서 영도국밥은 크게 성공해서 원조 할매국밥을 꺾었다. 그러나 사람들은 콩나물국밥 할매를 기억해주었고 콩나물국밥을 찾는 사람이 꾸준히 있었다. 원조(?) 할매 집에 가서 여긴 콩나물국밥 안 하냐고 묻던 사람들은 이제 영도국밥 할배에게 똑같은 질문을 하기 시작했다. 할배는 할매가 하듯 전주콩나물국밥을 까내렸는데 그 방법은 더욱 악질적이어서, 영도국밥에서 전주콩나물국밥 남부시장의 맛!을 팔았지만 둘이 먹다 하나가 죽을 정도로 맛이 없었다.

누구를 나무랄 수 있을까? 다 돈 벌자고 하는 일인데 말이다. 영도국밥 할배 때문에 전주콩나물국밥이 망한 것도 아니고 아무튼 할배는 많은 이들에게 국밥을 싸고 맛있게 팔았으므로 천국에 갈 것이다. 나는 진심으로 영도국밥 할배가 천국에 가기를 바란다. 가능하면 빨리 천국에 가길 바란다는 뜻이다. 전주콩나물국밥 할매가 이대로 망하기 전에.

그러나 사람들은 이제 국밥집도 아닌 곳에서 영도국밥이라는 메뉴를 팔기 시작했다. 사람들이 쌀밥을 먹는 한 영도국밥은 모든 밥집에서 영생할 것이다.

그때야말로 국밥의 종말이 온다.

UA를 통해 웹브라우저를 탐지하는 기술은 한때 필수적이었다. 웹브라우저는 HTML로 작성된 문서를 보여주는 역할을 하였다. 그 문서가 중간에 좀 이상해진 적이 있긴 하지만 아무튼 웹문서는 일단 웹브라우저 클라이언트에 도달하고 나면 스스로 잘 보일 수 있는지 없는지 판단할 수 없었다. 그러므로 HTTP 요청 시점에 클라이언트가 자신을 나타내는 식별자를 보내는 관습이 생겼다. 이것이 User-Agent이다.

그러나 새로 웹브라우저가 출시된다고 해서 웹서버에서 대응해 줄 리는 만무했다. 당시 넷스케이프 커뮤니케이터가 스스로를 대강 Mozilla라고 불렀는데, MSIE는 이를 흉내내 스스로를 대강 Mozilla (compatible MSIE Windows)라고 불렀다. 발상의 전환 덕에 MSIE는 저비용으로 넷스케이프를 밀어내는 데 성공한다. 그 다음 이야기는 따로 찾아 보면 금방 나온다. Mozilla (Windows) Gecko Firefox니, Mozilla (compatible Konqueror FreeBSD) (KHTML, like Gecko)니, Mozilla (Windows) AppleWebKit (KHTML, like Gecko) Chrome Safari니 하는 것 말이다. 마지막 것이 바로 맨 처음에 언급한 그 UA값이다. 뭔지 구별할 수나 있겠는가? 이게 바로 Chrome이다.

부활한 Mozilla는 Firefox (Gecko)라는 힘든 싸움을 계속하고 있다. 그러나 Microsoft는 Internet Explorer (Trident)를 포기했고, 최근에는 Edge를 살리기 위해 EdgeHTML을 포기하고 Chromium에 함께하겠다고 했다. 다 비용의 문제일 것이다. 이때 놀랍게도 아주 많은 웹 개발자들은 파편화된 세계가 Chromium으로 수렴해 간다는 것에 큰 우려를 표했다. 웹브라우저의 기능 파편화야말로 웹 개발자들에게 큰 고통 그 자체인데도 말이다. 웹이 통일되면 개발이 너무 쉬워져서 개발자들이 설 땅이 없어지기 때문일까?

MSIE가 초창기에 어느 정도 자리를 잡고 나서는 넷스케이프에서만 지원하는 API를 지원하는 척해서 웹사이트를 망가뜨리고 넷스케이프 내비게이터 지원을 포기하게 만든 적이 있다. 방법은 MSIE를 UA 값으로 거르는 것이었지만 ��은 사람들이 쓰러져 가는 넷스케이프를 지원하길 포기했다. 놀랍게도 Chrome에서 MSIE가 하던 일을 고의로 똑같이 한 적이 많다는 증언이 다수 나왔다. 한때 Firefox와 Chrome이 모두 웹 표준의 수호자들인 것처럼 알려졌지만 실상은 Chrome 역시 플랫폼 서비스로서 영토를 넓히기 위해 무자비하게 싸우고 있던 중인 것이다.

왜 굳이 그렇게 싸우냐고? 우선 독과점적 시장을 구축하고 나면 정말 많은 비용을 아낄 수 ��기 때문이다. 자유경쟁시장에서는 어떤 생산자도 승자가 될 수 없다. 소비자가 자유경쟁시장의 유일한 승자이기 때문이다. 그렇기 때문에 생산자들은 소비자에게 익숙함과 단기적 편리함이라는 실리를 제공하여 소비자들이 통합된 체계에 매몰되게 하려 한다. IT 분야에서는 다른 분야에 비해 이런 작업이 훨씬 쉽다.

오늘날 Chromium (Blink)은 각종 웹브라우저로만 쓰이는 것이 아니다. Blink와 V8은 Electron 프레임워크를 거쳐 데스크탑 환경에 쉽게 안착하는 크로스플랫폼 하이브리드 앱 개발 환경으로 자리잡았다. 웹 통계를 보면 그래도 아직 Gecko가 잘 하고 있는 것 같은가? Atom 꺼라. Visual Studio Code 꺼라. Slack도 끄고 Discord도 꺼라.

요즘 웬만한 웹사이트가 Firefox에서 적은 버그로 그럭저럭 잘 보이는 것 같은데 여기에는 Webpack의 역할이 상당했고 React의 도움도 컸다. (Angular를 사용한 Google 웹서비스가 한동안 Firefox에서 잘 작동하지 않았고 Vue는 아직도 Firefox 지원이 별로다.) 그러나 힙스터 개발자들은 이제 Parcel로 이주하려고 하고 있고 제발 Virtual DOM을 그만 만들라는 말도 끊임없이 나오고 있다. 바야흐로 웹 앱만의 시대이다.

우리는 무지와 무념무상 속에서 영원히 행복할 것이다.

사람들은 끊임없이 과거를 잊으려 한다. 이는 과거의 결정들이 우리를 현실 속에서 지혜롭게 만들어 주며 현실 속에서 지혜로움은 우리에게 고통을 주기 때문이다. 우리는 과거의 많은 결정들을 원시적이고 미개했던 광기와 혼란의 흔적으로 치부하기 일쑤이다. 그러나 그 광기와 혼란이야말로 정말 모두가 자신의 생각을 열심히 드러냈다는 증거이다. 문제를 정말로 잘 해결하고 싶다면 일단 광기와 혼란의 실재성을 인정할 필요가 있다.

기술적 결정에서도 이는 마찬가지여서, 어쩌다 보니 Intel의 x86이 초대박을 치고 그렇게 아직도 AMD의 x86_64를 쓰고 있다. 기술적 세부사항은 보이지 않는 곳에 덮어 두고 어떤 느낌적 느낌으로 그냥 잘 살고 싶은 것이다. 이는 기술자들이 기술적 결정을 내릴 때에도 마찬가지이기 때문에 Parcel은 곧 Webpack의 레거시를 털어 버리고 Trident/Chakra, EdgeHTML/ChakraCore, Gecko/SpiderMonkey 지원을 중단할 것이다. 그때야말로 Web의 종말이 올 것이다. Web의 살아 있는 부분은 Electron에서 크로스플랫폼을 지원하거나 Chrome OS 앱을 짜는 도구로 전락할 것이고 곧이어 Electron으로는 크로스플랫폼을 만들 수 없게 되며 Chrome OS도 삼도천을 건널 것이다. 그렇게 역사는 반복된다.

가볍고 빠르고 단단�� 도구는 문제를 단순화하는 데에서 나온다. 망치 하나로 다 하고 싶다면 못이 아닌 것을 일단 다 없애면 된다. 이게 우스운 소리라는 건 망치로 못을 박아 본 적이 없는 사람도 알 것이다. 그러니 제발 망치 하나로 다 하려 하지 말자. 여러 도구들의 역사적 맥락을 배우고 그것들을 올바르게 사용하는 방법을 새로이 익혀야 한다. 우리는 도구를 만들 줄 아는 사람이고, 그것이 우리가 동일한 실수를 반복하지 않는 방법이다. 동일한 실수를 해도 되는 기술자라면... 그냥 그렇게 살기 바란다. UA 탐지 코드를 복붙하고 잊어라.

그리고 컴퓨터 소프트웨어 관련 분야의 모든 분들은 제발 우리가 서 있는 환경이 어떤 마법이라서 시키는 대로 그 위에서 열심히 뛰면 로켓이 되어 우주로 날아갈 수 있다고 생각하지는 말아 주기 바란다. 다른 모든 곳이 그랬듯 이곳은 전쟁터였다. 전쟁터에서 미지위험을 줄이려면 우선 단단한 바닥이라도 만들어야 하고 그래서 우리는 자꾸만 하라는 일은 안 하고 집을 짓는다.

0 notes

eonj · 6 years ago

Text

회사를 좀 쉬었다

한참 그럭저럭 다니던 회사를 좀 쉬는 중이다. 사정이 좀 복잡한데 결국 건강 상의 문제가 있었다고 요약할 수 있을 것 같다. 심신의 건강이 많이 나빠졌다. 몸의 문제로는, 심혈관 및 혈액계, 소화기 및 내분비계, 근골격 및 중추신경계, 호흡기계 모두에 사소하지만은 않은 질환들이 있었다. (그나마 문제가 발견되지 않은 채 남은 건 비뇨기/배설/생식기계 정도인가...) 마음의 문제로는, 장기간 누적된 사회적 약점과 더불어, 정동에 있어 기분 부전 - 의욕 상실 - 동기 결여를 아우르는 우울에피소드를 계속 겪어 왔으며, 평가절하 - 흑백사고적 낙인 - 재앙화로 이어지는 부정적 과편향 사고 역시 끊이지 않았다.

마음의 문제에 대해서는 그나마 한동안 내 건강의 주요 관심사로 두고 관리를 해 왔는데 결과로 보건대 전체적으로 좋은 방식은 아니었던 것 같다. 내 생활 습관과 인지와 행동을 개선해 가면서 새로운 나를 위한 태도를 만들어 갔어야 하는데, 그러지 못했다. 나는 내 인식범위에 걸려든 부정적 정서를 당장 잠재우는데 급급했으며 그것이 혹시나 내 지친 몸 곳곳에서 발생하는 여러 신호의 한 표면적 발현일 수도 있다는 생각을 미처 하지 못했다. 나는, 이제야말로 앞으로 일 때문에 스트레스 받지 말아야지, 하면서도 자꾸만 더 열심히 일하고 일을 더 잘 하고자 했다. 일이 잘 돌아가지 않는 게 스트레스라면 결국 내가 더 열심히 해서 내가 잘 하는 것이 스트레스를 해소하는 방법이라는 아주 정직하고 고지식하고 억지스��고 멍청한 생각을 버리지 못했던 것이다. 연말이 다 되어서야 연간 건강검진을 받았다. 나는 건강검진 결과를 받아들어서는 완전히 지쳐 나가떨어지고 말았다.

문제가 있는 사람답게 가장 극단적인 선택지인 “퇴사 후 어떻게든 되겠지”를 가장 우선순위에 뒀다. 한동안 회사에서도 공공연히 하고 다닌 말이다만 컴퓨터 프로그래머를 그만두고 싶었다. 그러나 이 학력과 경력으로 소프트웨어 엔지니어링과 무관한 일을 구하고 이 판을 완전히 뜨는 건, 지금의 일을 계속 하는 것보다도 더 어렵다는 사실을 경험적으로 알고 있었다. 결국 퇴사안은 내 선에서 걸러졌다. 그 뒤에는 휴직을 하려고 리더면담을 거쳤으며 좀 더 침착히 검토해 본 결과 병가를 내게 됐다. 그 병가를 받아서 쉬는 것조차도 여러 법적 주체의 서로 다른 입장 때문에 자꾸 엇갈리는 판단과 의견을 상대하는 일이었다는 이야기의 디테일은 사석에서 꺼내기에도 지저분한 수준이다. 정말로 쉬게 된 첫 날에는 모든 것이 지긋지긋했다.

당연히 그 정신으로는 정상적으로 무얼 할 수가 없었다. 첫 주 동안에는 아무 것도 제대로 하지 못했으며 오히려 건강 상태가 악화일로를 걸었다. 고향에 내려가 가족 덕을 좀 봤다. 대부분의 집안일에서 손을 떼고 내가 좋아하는 요리나 하면서 매일 산책 이상의 운동을 다녔다. 그렇게 2주쯤 고향에만 있으니 답답하더라. 쉬면서 하고 싶은 게 많았다. 평소에 생각하던 것들 중 ‘길게 쉬어야 비로소 할 수 있는 것들’이거나 ‘당분간 일을 쉬면서 하면 좋을 것들’에 대한 바람이 자꾸만 가만히 있는 나를 간지럽혔다. 읽기, 쓰기, 여행, 그 밖의 모든 것들. 결국 나는 다시 분당으로 돌아왔다.

이쯤 해서 결과부터 말하자면 이번 병가에서 얻은 것은 아주 조금 건강해졌음뿐이다. 그 약간의 건강이나마 얻을 수 있었으니 다행이라고 해야 겸손한 판단일 것이다. 혼자 쉬었다면 계속 나빠질 것이 뻔했으니까. 그래도 분당에 돌아와서도 운동은 그럭저럭 꾸준히 했다. 다른 건 어땠냐고? 일을 쉰다고 글을 오래 읽는 참을성이 나아지는 일은 없었으며 글감을 어떻게든 하나라도 진짜 글로 써내는 과감함이 생기지도 않았다. 내게 도움이 될 여행을 직접 구상해서 실행에 옮기기까지 하려면 인내와 용기가 모두 필요한데 여행을 떠나는 데 성공했을 리도 만무하다. 그리고 한 가지 깨달은 게 있는데 나는 시간이 없는 게 아니라 돈도 없는 것이었다.

내가 일을 쉬기 시작하면서 공연히 알리지 않았던 이유는 앞으로 어떻게 살지에 대한 계획이 전혀 없었기 때문이다. 물론 지금도 그런 거창한 계획을 갖고 있는 건 아니다만, 적어도 한 발짝 앞을 보는 시야는 생겼다. 일과 삶의 균형에 대해 감히 한마디 하자면, 일과 삶은 서로를 깎아 가며 균형을 맞추는 것이 아니다. 노동은 삶의 지극히 일부분일 뿐이며 오늘날 일은 노동가치가 몇 겹의 옷을 입고 시장가치로 바뀌는 과정이다. 삶이 없으면 노동도 없으며 제대로 일을 하지도 못한다. 나는 내 삶의 기초인 건강을 헐어 가면서 일하지 않을 것이며 건강을 되찾아 유지할 수 있는 패턴으로 사는 것을 최선의 법으로 할 것이다. 삶의 즐거움을 위해서 일할 것이다. 그리고 삶의 즐거움을 위해서 꼭 계속 운동할 것이다.

앞으로 어떻게 살지에 대해서는 크게 걱정하거나 계획하려 들지 않으려 한다. 언젠가 내 일의 기본적 요구가 내 삶의 즐거움을 위한 기본 원칙과 병존하지 못하는 상황이 올 수 있다. 조만간 한번쯤은 꼭 또다시 그렇게 될 것이다. 그때가 되어 어떤 결정을 내릴지는 아직도 모르겠다. 이전보다는 내 삶의 기본을 위하는 방향으로 생각을 해야 좋겠다만, 아마 내가 실수를 몇 번쯤은 더 하겠지. 일단 다음주에 복직이 예정되어 있고 당분간 그냥 지금 회사에 계속 다닐 것 같다. 벌써 기분이 어수선하여 영 편치 않은데 이게 조건반사적인 스트레스인지 별다른 이유를 영 모르겠으니 이걸 당장 어째야 할지 모르겠다. 어휴.

0 notes

eonj · 7 years ago

Text

정상기술에 대하여

가끔씩 이런 일이 벌어진다. 하나의 기술적 문제를 어떻게 해결할 것인가에 대해 여러 대안들이 난무하고 각 대안에는 모두 어딘가 빈틈이 있다. 그때 새로운 대안으로 그 문제를 커버하는 것이 아니라, 아주 작은 발상의 전환이 그 문제를 아예 없던 것으로 만들어 버린다.

The H1 Debate라는 그룹이 있었다. 꽤 오래된 논란거리인 “H1 논쟁”을 내세워서 HTML 마크업 시맨틱에 대한 논의 정보를 모으고 생산하는 그룹이었다. H1 논쟁은 별로 특별한 게 아니고 웹페이지의 어디에 h1 태그를 달아야 하느냐는 논쟁이다. 사이트의 이름 부분이 h1으로 되어 있어야 하는가? 아니면 그 페이지의 본문에 붙은 제목이 h1으로 되어 있어야 하는가? 각자 생각하는 바가 있겠지만, h1 논쟁에 대해서는 정말 치열한 공방이 오고 갔으며 양쪽의 표심 역시 막상막하였다. 사이트 이름에 h1이 붙으면 좋은 이유가 있고 본문에 h1이 붙으면 좋은 이유가 또 있다. 그러나 한 웹페이지는 하나의 문서를 의미하기 때문에 하나의 문서 본문(body)에 제목(h1)이 두 개 있다는 건 말이 안 되는 일이었다. 둘 중 하나에만 h1을 써야 했다. 그게 의미론적으로 옳았으니까.

이 논쟁은 차세대 웹 표준 주도권 싸움에서 W3C가 손을 놓고 WHATWG가 이기면서 어이없게 끝난다. WHATWG는 하이퍼텍스트의 의미의 포커스를 텍스트라는 기초에서 하이퍼텍스트의 실질적인 기능으로 이동시켜 버린다. 즉 WHATWG가 그 이름을 통해 표방하듯, HTML이 하이퍼텍스트 애플리케이션을 만드는 언어가 된 것이다. 이 의미론에 기초한 마크업 언어 표준은 HTML5라고 불리게 되었다. HTML5는 하나의 웹 애플리케이션이 포함할 수 있는 많은 기능과 내용 각각에 의미역을 지정하는 태그를 추가했는데 이를테면 nav, header, article, section과 같은 것이었다. 이로써 굳이 한 웹페이지에 h1 태그가 하나만 있을 이유가 없게 되었다. 페이지 제목을 h1으로 마크업하고 싶으면 header 내에 h1을 넣으면 되고, 한 페이지에 글이 여러 개면 각 글을 article로 묶고 그 안에 h1으로 글 제목을 표시하면 되니까.

역사에 가정은 없다지만, 만약 W3C가 수제 온톨로지와 이름공간 기반으로 만들어진 XHTML2 모델에 끝까지 집착해 XHTML2를 REC로 채택했다면 어떨까? 아마 기존의 문서들을 XHTML2로 바꿔 나가는 속도는 또 다른 수많은 웹페이지가 생산되는 속도를 절대 따라잡을 수 없었을 것이다. XHTML2라는 표준은 현실과 괴리되어 사장되고 W3C의 권위 역시 추락했을 것이다. 수많은 웹페이지들은 실질적으로 지킬 수 없는 표준 없이 웹 브라우저들의 구현에 맞추어 떠돌았을 것이다. 이런 현상은 실제로 있었고, WHATWG가 결성되고 이내 보다 못해 HTML5라는 제안을 내놓게 된 배경이기도 하다. 아마 W3C 안에서도 기울어 가는 현실을 직시한 사람들이 점차 늘어 갔을 것이다. WHATWG가 만든 변화의 물결에 따라 W3C의 표준화 역시 열리고 간소화되어 갔다.

W3C와 WHATWG의 협력으로 HTML5가 REC로 채택되고 나서도 WHATWG의 DOM / Web API는 변화를 거듭해 갔고 HTML5라는 단일 브랜드에는 끊임없이 새로운 것이 추가되었다. 이는 하나의 구심점이 되기에는 좋았지만 웹 표준으로써의 효력은 모자란 감이 있었다. 기술 표준은 어떤 대상이 그 표준을 얼마나 잘 준수했는지를 정량적으로 평가해서 수치화할 수 있는 도구여야 한다. 그러나 변하는 표준은 그 기능을 할 수 없다. W3C는 HTML5의 초기 REC을 다시 HTML 5로 규정하고 이후 HTML 5.1, HTML 5.2 등의 버저닝을 하고 있다. 2018년 12월 15일 현재 W3C는 GitHub에서 HTML 5.3의 WD를 관리하고 있다. W3C는 수많은 사람들의 의견을 수렴해 가며, 하이퍼텍스트로 만들어지거나 하이퍼텍스트가 보조하는 수많은 멀티미디어와 애플리케이션이 올바르게 완성된 의미론을 갖도록 치열하게 노력하고 있다. WHATWG는 이 과정에 보조를 맞추고 있으며 WHATWG의 Living Standard 페이지는 W3C의 WD와 함께 변한다.

이 상황이 하이퍼텍스트의 종말까지 계속되리라고는 여길 수 없다. 언젠가는 기존의 하이퍼텍스트가 낡아 버리고 그와 완전히 다른 하이퍼미디어 모델이 출현할 것이다. 하이퍼미디어 이론이 잘 응용된 이미지나 사운드나 영상이나…… 게임이나 그런 것들 말이다. 아마 그 때가 되면 HTML 5의 img, audio, video 태그는 너무 낡은 것이 되어 버리고 새로운 표준이 출현할 것이다. 물론 그것이 여전히 HTML 5처럼 SGML 기반이며 XHTML 5처럼 XML 기반으로 정의할 수 있을지는 아무도 모른다. 그리고 그것이 여전히 특허로 닫혀 있지 않으며 잘 공개된 자유로운 표준일지도 미지수이다. 그러나 그것의 정체성은 여전히 하이퍼-무언가이다.

이 지점에서 h1 논쟁으로 돌아오면 h1 논쟁이 얼마나 부질없게 느껴지는가. 그러나 HTML 5라는 큰 변화는 h1 논쟁과 같은 토양에서 피어났다. 그리고 앞으로도 그�� 것이며, HTML 5 역시 언젠가는 썩어서 흙이 되고 HTML 5의 한계 안에서의 논쟁은 새로운 발상의 전환을 피워 낼 자양분이 될 것이다.

어떤 문제에 대해서는 발상의 전환이 그 문제를 완전히 해소해 버릴 수 있는 패러다임의 전환일 수 있다. 그러나 그것이 모든 미래의 문제를 영원히 해결해 주지는 않는다. 정상기술은, 이렇게 정상과학과 비슷한 길을 걷는다.

1 note · View note

eonj · 7 years ago

Text

글 쓰는 이의 사치 4: 글 쓰지 않는 이의 사치

‘글 쓰는 이의 사치’ 시리즈 네 번째. 부제가 글 쓰지 않는 이의 사치인 까닭은 당연히 내가 글을 쓰지 않고 있기 때문이다. 나는 요즘 아예 내가 글 쓰는 이라고 생각하지 않고 있는데 내가 웬만한 사람들에 비해서도 글을 적게 쓰고 있다는 사실을 알게 되었기 때문이다. 평균적으로 사람들은 꽤 많은 글을 쓴다. 그것이 메시지 한 토막이든, 몇 줄짜리 일기든, 꽤 긴 블로그 글이나 보고서든, 그것들 사이의 중간쯤 되는 무언가이든 말이다.

종류를 막론하고, 텍스트를 보면 나는 매우 피곤하다. 이 피로감은 내가 텍스트에 대해 얼마나 심각한 강박이 있는지를 알려 주는데, 이는 그 피로가 유래하는 지점을 내가 알기 때문이다: 나는 텍스트를 보고 항상 드러난 맥락과 숨겨진 배경 속에서 모든 것을 정확히 파악하려고 한다. 또한 나는 만약 내가 텍스트를 채워 넣어야 하는 빈 칸을 보면 거의 교착 상태에 빠지다시피 한다. 내가 쓴 표현들이 내 느낌과 생각이나 내가 아는 사실을 나타내는 데 적확할 것은 물론이요, 내용이 목적에 충실해야 하고, 맥락이 너무 복잡하지 않게 드러나야 하며, 너무 많은 것을 배경에 숨기면 안 되기 때문이다. 그러나 어찌하려는 노력이든 그마저도 과하지 않은 것이 좋고 말이다.

(위 한 문단을 쓰는 데만 해도 몇 번을 지우고 고쳤는지 모른다. 후보군에 오른 낱말과 어구를 모두 모으면 위 문단의 5배 분량이 된다. 그러나 긴장의 끈을 마냥 놓을 수는 없는 것이, 긴장을 풀자마자 이 직전 문장에서 ‘위 문단’을 ‘위 문장’이라고 엉터리로 쓸 뻔했다.)

나는 대강 26년을 살았는데, 10년 된 큰 글감과 5년 된 또 다른 큰 글감이 있고, 그 밖에도 때맞춰 빛을 보지 못하고 잠든 수많은 글조각들이 있다. 애착을 갖고 공들이는 글쓰기를 거의 완전히 쉰지도 1년쯤 됐는데, 다른 이유는 아니고 내가 컴퓨터 프로그래머로 취직을 했기에 글에 쓸 힘이 내 마음만큼 없었기 때문이다. 그 동안 힘 빠진 글 쓰는 연습이 좀 되었다. 당장 내가 겪은 경험이나 지금 내가 아는 사실만 딱 떼어다 글을 만들고 끝내는 연습. 블로그에도 (별 영양가 없을 것이라 생각해서) 그런 글이 있고, 사내 문서로도 (필요할 때 몇 번 읽��고 말 것이기에) 그런 글들을 생산했다.

그렇게 본의 아니게 글에서 힘 빼는 연습이 되고 나서, 그 몇 년 묵은 글감을 위해 모아 놓은 글조각들을 보았다. 아니나 다를까, 엄청나게 힘이 들어가 있었다. 이렇게 힘을 잔뜩 줘서는 글이 나올 수가 없을 지경이었다. 나는 무슨 생각으로 이렇게 힘을 줬을까? 나는 글을 잘 쓰고 싶었던 걸까, 글을 잘 쓰는 내가 되고 싶었던 걸까? 전자도 있었겠지만 아무래도 후자가 너무 강했던 걸 부정하지 못하겠다.

글을 낳는다는 건 (낳는다는 은유를 남성이 함부로 써도 될까?) 정말 고통스러우며 무척 즐거운 일이다. 그렇기에 글이 아무튼 나오기 위해서는 글쓰기가 주는 고통을 즐기고 글쓰기가 주는 즐거움을 경계할 줄 잘아야 한다. 글을 너무 잘 쓰려고 하면 사유의 소용돌이에 빠져 글은 나오지 않지만 생각하는 나는 즐거움을 누릴 것이다. 글을 너무 대충 쓰는 것은 글쓰기의 즐거움을 고통과 함께 내다 버리는 것이다. 글이 잘 통제되기 위해서는 글을 잘 통제하려는 자신부터 잘 통제할 필요가 있다. 여느 예술이나 체육에서 중요한 기법이 그러하듯 말이다.

한편 글은 코드와도 비슷해서 어떤 규모를 넘어가면 일관성을 유지하면서 쓰는 게 거의 불가능에 가깝다. (이 비유를 이해하는 사람이 얼마나 있을까? 사실 코드가 글과 같은 것인데, 글은 혼자 쓰더라도 자고 일어나서 쓰면 달라진다. 코드는 보통 서로 다르게 자고 일어나 온 사람들이 함께 쓰는 것이다.) 그래서 글을 잘 쓰려는 노력 자체를 하지 않는 게 좋다. 글은 썩 나쁘지 않은 수준까지만 다듬어져야 한다. 어차피 자고 일어나서 보면 이상해질 글이기 때문이다. 너무 잘 쓰려고 노력하면 그 노력이 집착이 되고, 나중에 되짚어 보니 이상하더라도 뒤집어 엎어 버리고 새로 쓸 생각을 하지 못하게 될 수도 있다. (요 몇 달 사이 코드에 대해서도 비슷한 것을 느꼈는데, 이에 대해서는 먼 훗날에 진득하게 다루어 볼 요량이다.)

자, 이 ‘글 쓰는 이의 사치’ 시리즈의 첫 편에서 나는 글을 마쳐 내보내지 않고 묵혀 두는 것이 글 쓰는 이의 최대 사치라고 했으며 후속편들에서 그런 사치를 범하는 나를 강하게 자기비판한 바 있다. 만약 그게 여전히 사치라면, 이번에는 나는 그 사치를 적극적으로 누려 볼까 한다. 앞서 일렀듯, 나는 텍스트를 보면 피곤하다; 사실 이걸 깨닫기까지 정말 오랜 시간이 걸렸고 거기에 많은 노력이 있었다. 그리고 이 피로는 아직 끝나지 않았다. 그렇기에 지금 내가 다시 글쓰기를 시작한다면 힘을 충분히 빼고 쓸 자신이 없다. 그래서 사치를 더 누리려는 것이다. 글 앞에서 빈 칸을 마주하고도 충분히 힘을 뺄 수 있게 될 때까지. 어차피 내가 아끼던 글조각들은 아끼다 똥 되었다. 그리고 잘 아껴 두었기에 비로소 그게 똥임을 알았다. 다음 글은 나중에 보아도 그럭저럭 괜찮게 쓰리라.

돌아보니 오늘도 이렇게 똥을 하나 썼다. 하수도를 따라 잘 흘러 가거라.

0 notes

eonj · 7 years ago

Text

프로그래머들의 이름 짓기

프로그래머들은 이름 짓기에 질려 있는데, 이 이유는 설명하자면 끝이 없지만, 기본적으로는 코드 상에서 커뮤니케이션의 일차적인 프리미티브로 개체들의 이름이 쓰이기 때문이다. 혼자 일하는 사람조차도 끊임없이 과거의 자신을 원망하며 미래의 자신에게 빚을 지는 대화를 계속 하게 된다.

그래서인지 프로그래머들은 이 이름 짓기의 싸움에서 위트있고 독특한 이름을 추구하는 경향을 보인다. 예를 들어 내가 소속된 프로젝트에서 프로덕트의 버전이 1.x에서 2.x로 넘어갈 때 새 저장소 이름을 정해야 했는데, 그 코드네임으로 누군가는 영화의 등장인물 이름을, 누군가는 항정신성 약물 이름을, 누군가는 “RIP”(1.x를 저세상으로 보내 버린다는 뜻에서)를 주장하기도 했다. (내 중재로 인해 그 프로젝트 저장소의 이름은 결국 코드네임을 쓰지 않고 프로덕트의 대외적 명칭과 버전을 합쳐서 쓰게 되었다. 물론 위 3개 중 하나는 내 제안이다. 맞혀 보시라.)

이런 식으로 프로그래머들에게 코드 밖의 무언가에 대해 무제약으로 이름을 짓게 시키면 온갖 괴상한 것들이 튀어 나오기 때문에, (물론 코드 안에서도 꼭 괴상하게 이름을 짓는 사람이 있다만... 자기 이름을 넣는다든지.) 그들에게 실제 프로덕트의 이름을 짓게 시키는 경우는 매우 드문 편이다. 그래서 대체로 프로덕트의 이름은 소비자를 배려하여 매우 세심하게 설계된다. 잘못된 이름은 그 프로덕트의 생명을 박탈하고 마침내 그 프로덕트를 파멸로 이끌 수도 있기 때문이다.

엄밀히 말하면 위와 같은 세심히 설계된 이름은 최종 소비자가 프로그래머가 아닌 경우에 한정된다. 이 외의 경우에는 굳이 이름을 세심히 설계할 이유가 없기 때문에, 프로그래머들은 프로그래머들을 위해 무언가의 이름을 지을 때 이 이상한 욕구를 가감없이 발휘한다. 그리고 대체로 그 이름을 소비하는 프로그래머들 역시 그런 이상한 이름을 존중해 주는 편이다.

그러나 이게 좋은 현상은 아닌 게, 프로그래머들 역시 자신들이 소비하는 프로덕트의 이름에 큰 영향을 받기 때문이다. 예를 들면 라이브러리, 유틸리티, 프레임워크, 컴파일러, 그리고 프로그래밍 언어의 이름과 같은 것들이다. 오늘 다룰 내용은 바로 이 프로그래밍 언어에 잘못 지어진 이름들과 그 언어들의 생명에 관한 것이다. 물론 잡설이 훨씬 더 많다.

프로그래밍 언어의 세대 구분에서 무엇이 4GL이고 5GL인지는 아직도 논쟁의 소지가 있다만, 나는 오늘날 4GL 내지 5GL의 미래를 달리는 언어들은 크게 다음의 8개 정도라고 생각한다.

C# 5.0+

Java 8+

Kotlin

Swift

Rust

JavaScript (ECMAScript 2016+)

Python

이 중 앞의 4개는 회사에서 잘 지은 이름이다. C#, Java의 경우에는 워낙 악명높은 이름이었으나 3GL 시대를 지배하게 된 언어의 브랜드를 유지함으로써 오히려 브랜드 가치를 만든 경우이다. Kotlin과 Swift의 경우 언어를 잘 보급하기 위해 이름을 세련되게 짓는 데 신경을 많이 쓴 모습을 볼 수 있다. 한편 뒤의 4개의 이름을 보면, 커뮤니티나 개발자가 지은 이름을 그대로 쓴 것 같다는 인상을 지울 수 없다. 난 이 4개 언어의 이름을 정말 좋아하지 않는 편인데, 영어의 대중적 언어 감수성을 갖고 있는 사람이라면 다들 공감하리라 믿는다.

Rust는 이 중 브랜드 이미지에서 최악의 이름으로, 언어의 컨셉인 safeness, robustness와 정면으로 대치되는 이름이다. 놀랍게도 rust와 robust는 단 두 글자 차이인데도, Rust를 쓰는 사람 손에서는 녹슨 기계 관절 냄새가 날 것 같다는 느낌이 든다. 일부러 이렇게 이름을 설계하라고 해도 못 할 지경이다. 이렇게 언어에 대한 부정적 느낌으로 언어를 배우기 시작하면 누가 이 어려운 길을 굳이 걸으려 하겠는가?

Go는 역시 좋은 이름이 아니다. 물론 바둑을 go라고 부르기도 한다만, Go라는 이름은 그 느낌을 주기 위해 만들어지지 않았으며, 설계된 대로 잘 굴러갈 것 같은 느낌을 준다. 그리고 그 덕분에 Go가 들어간 문장은 문법적으로 정상이 아니고 긴 문장이라면 읽기 부담스러운 수준이 된다.

JavaScript는 어떤 브랜드 이름을 지어야 할 때 피해야 하는 단적인 예시를 보여 준다고 할 수 있다. 굳이 잘 나가는 다른 이름인 Java를 끌어다 쓰면서, 발상의 한계로 인해 그 언어가 script라고 한정하여 JavaScript라고 이름을 지은 것이다. 오늘날 JavaScript의 이름을 정확하게 쓰는 사람은 많지 않으며 Javascript, Java-script, Java Script 등 수많은 변종 이름들이 프로그래머 커뮤니티에 난무하고 있다. 물론 이렇게 사람들에게 그대로 쓰기 싫은 브랜드 이름이 되었을 뿐더러, Java같지도 않고 이제는 script도 아니니 정말 멍청한 이름이 된 셈이다.

Python은 이 중 이상한 느낌의 일반명사나 동사나 타 브랜드를 끌어다 쓰지 않은 이름이기에 그나마 낫다. 그렇다고 비단뱀이라는 이름을 잘 지었다는 건 절대 아니며, 덕분에 PyPy라는 우로보로스ouroboros가 탄생하게 되었다는 건 그들에게 어떨지 모르겠다. 비단뱀으로 쓰인 비단뱀 실행시간 말이다. 덤으로 Python 2와 Python 3을 보면 PEP의 브랜드 관리는 엉망진창이었고 Python이라는 이름이 그럭저럭 괜찮아 보이는 건 순전히 운이었음을 알 수 있다. 우리는 Python으로부터 위원회 흉내내는 커뮤니티가 얼마나 유해한지 배울 수 있었던 것이다.

자, 그래서 이들의 생명력은 어떤가? 이들이 걷고 있는 길은 꼭 그들의 이름을 어떻게 지었는지와 아주 강하게 연관되어 있다고 볼 수는 없다. C#과 Java는 많은 비판을 받았던 이름이지만 오늘날 메인스트림이며, Python은 타입이 조금 있는 셸 스크립트 수준이지만 그래도 Ruby나 Perl보다는 낫기에 괜찮은 라이브러리를 만드는 사람들을 모을 수 있었다. Rust는 너무 안전하며, Go는 너무 느리고, JavaScript는 잘못 설계되었다. (여담이지만 정확히 하자면, The Holy Trinity and JavaScript라고 돌아다니는 유머는 크게 잘못된 설계를 보여주지는 않는다. 요즘 JavaScript에서 가장 문제가 되는 부분은 원형prototype과 특성trait 기반 언어가 하필 [[Call]]과 [[Construct]]의 용법을 제대로 구분하지 않아서 문제가 되었던 걸 또 클래스로 풀려고 했다는 점이다.) 그래도 여전히 Rust, Go, JavaScript, Python을 그 이름이나 브랜드 때문에 배우기 시작조차 하지 않으려는 사람은 존재한다.

프로그래머들은 왜 이렇게 평범하지 않은 이름을 짓기 시작했을까? 답은 위에서 말했듯, 매일 정확한 이름을 만들어야만 하는 프로그래머들의 일탈이라고 볼 수 있을 것이다. 그러나 그들은 그들 생각처럼 이름을 위트있게 잘 짓는 게 아니다. 프로그래밍 언어뿐만 아니라 라이브러리나 유틸리티 등등의 이름에서도 이런 일이 벌어지고 있다. 물론 웬만한 평범한 이름은 이미 바닥났으며 특별한 이름은 프로덕트의 생명을 위해 중요하다. 그러나 프로그래머들은 특별한 이름을 지을 때 이 사실을 주지해야 할 것이다: 프로그래머들의 센스있는 이름에 대한 집착은 그들의 프로덕트의 생명에 좋지 않을 수 있다.

1 note · View note