Arachneng on Everything

저번 글에서 카일루아가 왜 만들어졌는지, 그리고 초기 설계가 어떠했는지에 대해서 간략히 설명했다. 많은 언어가 그렇듯, 카일루아 또한 실제로 작성된 첫 코드는 파서였다. 이번 글에서는 카일루아의 파서가 어떻게 발전했는지를 이야기해 보기로 한다.

왜 러스트를?

모두가 알고 있듯 카일루아는 러스트로 작성되어 있다. 꽤 많은 루아 타입 시스템이나 루아 확장 언어가 루아로 작성된 것과는 대조적인데, 여러 이유가 있다.

내가 작성하기 편했다. 어차피 이걸 무슨 언어로 짜도 건들 수 있는 사람은 나 밖에 없을 것이다(…).

타입 시스템이 강하고 대수적 자료형(algebraic data type)이 있는 언어는 보통 언어 구현 짜기 편리하다.

적절한 크기의 네이티브 바이너리가 하나 툭 튀어나오면 배포가 편리하다.

솔직히 말해서 이걸 루아로 짜라고 하면 그냥 혀 깨물고 죽을 것이다.

내가 한 러스트 빠 하긴 하지만(…) 카일루아 작업을 하면서 한 가지 더 느끼게 된 것은 바로 이것이다.

러스트 코드는 매우 리팩토링하기 좋다. 리팩토링 과정에서 컴파일 오류를 잡는 건 물론 해야 하지만, 리팩토링된 결과가 이전과 다르지 않다는 걸 타입 시스템을 사용해서 증명하기가 매우 수월하다.

현재의 카일루아 코드는 상당히 유기적으로 만들어진 코드라서, 크레이트가 10개로 쪼개져 있긴 하지만 여기 저기 이상한 구석이 많이 남아 있다. 유기적으로 만들 수 밖에 없던 것은 설계를 여러 차례 변경하면서 아키텍처도 함께 바꿔야 하는 경우가 많았기 때문인데, 그럼에도 불구하고 힘을 덜 들이고 리팩토링을 할 수 있었던 덕분에 그 정도로 힘든 작업은 아니었다. 좀 더 힘을 쓰면 타입 시스템 수준에서 이상한 구석들을 많이 잡을 수 있겠지만 여러 가지 이유로 (시간 문제도 있고, 그렇게 해서 얻는 이득이 크지 않다고 판단하여) 하지 않았다.

LALRPOP

코드를 오픈소스로 공개하면 좋은 것이 이렇게 초창기 코드를 그대로 링크해서 보여 줄 수 있다는 것이다. 이 코드는 날짜를 보면 알 수 있지만 설계에 앞서 빠르게 테스트로 구현한 토큰화 코드이고, 전형적인 추상 문법 트리(AST) 코드와 함께 LALRPOP으로 작성된 간단한 테스트 파서가 들어 있다.

토큰화 과정은 그다지 별로 특이한 점은 없다. 현재 코드와 비교해도 큰 차이가 없는데, 추가된 점은 오류 보고와, 카일루아 전용 토큰을 해석할 수 있도록 했다는 것, 그리고 이 글의 뒤에서 설명하겠지만 토큰 이전에 한 단계가 더 추가된 점이 있다. 토큰화 자체는 u8 바이트 반복자로부터 Tok 값 반복자를 만들어 내는 어댑터로 구현되었는데 이렇게 하다 보니 오류 복구가 미묘해진 부분이 있긴 하다. (최종적으로 모르는 문자가 나오면 아는 문자가 나올 때까지 스킵하고 하나의 오류를 보고하도록 했기 때문에 토큰화 과정에서 복구 불가능한 오류는 나올 수 없게 되었다.)

크게 달라진 것은 파서이다. LALRPOP은 여전히 꽤 실험적인 라이브러리 같지만 2015년 11월 당시에는 정말 실험적인 라이브러리였다. 내가 LALRPOP을 써 보면서 느낀 가장 큰 문제는 두 가지인데, 하나는 생성된 파일이 너무 크다는 것이었다. 몇 줄 안 되는 parser.lalrpop으로부터 생성된 parser.rs 파일이 이미 2천줄이 넘어간다! 실제로는 do와 break만 파싱하는 아주 간단한 물건인데도 말이다. 그래도 뭐 코딩이 편하니까 큰 문제 없겠지 하고 작업을 하긴 했었는데… 루아 문법을 거진 다 구현하고 나니 문법은 200여줄 남짓했는데 생성된 파일은 20만줄을 넘는 상황이 벌어졌다. 이 정도 되면 컴파일하는 데 몇 분 걸리고 난리가 난다. (당시 러스트 컴파일러는 더 느렸다는 점을 생각해 보자.) 이런 상황이 벌어진 것은 당시 LALRPOP이 LR/LALR 파서를 구현할 때 컴팩트한 테이블을 만든 게 아니라 모조리 match로 때려 박아서였고, 지금은 상황이 개선된 것으로 알고 있다(짐작컨대 당시 파서를 지금 LALRPOP로 컴파일하면 1/10 정도 나오지 않을까 싶다). 어쨌든 당시에는 이터레이션이 너무 느리다는 것 자체만으로 상당한 스트레스였다.

다른 문제는 좀 더 본질적인데, LALRPOP은 shift-reduce 충돌을 제어할 방법을 지원하지 않는다. 형식 문법이 뭔지 안다는 전제 하에 잠깐 파싱 이론을 가볍게(?) 들어 가면, LR 계열 파서는 현재까지 읽은 토큰들(42, foo, = 따위)이 어떤 비단말(non-terminal) 기호(루아의 경우 exp, chunk 따위)들에 포함되는지를 스택에 집어 넣고, 가장 안쪽에 있는 비말단 기호가 끝나서 스택에서 뽑혀야 하는지(“reduce”), 또는 다음 토큰을 읽어야 결정할 수 있는지(“shift”)를 상태 기계로 만들어서 파싱을 수행한다. 이를테면 다음과 같이 local x = 42 + 54 * f() return x라는 코드가 있는데 +까지 읽었다면…

| 열려 있는 비단말 기호들 | | <----| - - - -> exp <--------------| - - - -> stmt <--------------| - - - - - - - - > chunk local x = 42 + | 54 * f() return x | 현재까지 읽은 위치

…그럼 현재 위치에서 열려 있는 비단말 기호는 안쪽부터 순서대로 수식을 나타내는 exp, 문장을 나타내는 stmt, 그리고 실행 가능한 코드 뭉치를 나타내는 chunk 세 개가 있다. 42 또한 수식이고, 맨 앞의 x는 문법과 대조해 보면 대입문 좌변을 나타내는 var에 대응하겠지만 현재 위치에서는 더 이상 영향을 줄 수 없으므로 스택에 없는 것을 유념하자. 직관적으로 생각해 보면 이 상태에서는 어떤 비단말 기호도 끝마칠 수 없고, 따라서 다음 기호를 읽어야만 뭘 할지를 결정할 수 있다. 바로 이 과정을 상태 기계로 표현한 것이 LR 파서인 것이다. LR 파서 안에서는 SLR, GLR, LALR 등의 다양한 바리에이션이 있긴 하지만 기본적인 구조는 다 똑같다.

근데 뭐가 문제냐고? 카일루아 파싱 테스트에 들어 있는 다음 코드를 생각해 보자.

a = b + c (print or io.write)('done')

이건 문장 하나일까 두 개일까? 두 줄로 나뉘어 있는 건 아무 의미도 없다. 루아에서 개행문자는 공백과 완전히 똑같다(비슷하게 세미콜론을 생략 가능한 자바스크립트와는 이 점에서 다르다). 루아 문서에 따르면 이는 한 문장으로, c(...)는 함수 호출로 해석된다. 보이는 것과 비슷하게 두 문장으로 바꾸려면 중간에 세미콜론을 넣어야만 한다.

a = b + c; (print or io.write)('done')

하지만 이런 식으로 문법이 구성되어 있으면 c를 읽은 시점에서 현재 열려 있는 수식(exp)이나 문장(stmt) 따위를 reduce, 즉 마무리짓고 다음 문장으로 진행해야 할지, 아니면 다음 토큰을 shift, 즉 더 읽어 봐야 할지를 결정할 수 없다. 이를 shift-reduce 충돌이라고 한다. 이런 류의 충돌은 은근 흔해서 C의 조건문에서도 비슷한 사례가 있다. 이걸 해결하는 방법은 크게 두 가지가 있다.

해당 상황에서 shift를 할지 reduce를 할지를 명시적으로 지정한다. 꽤 많은 파서 생성기는 이 상황에서 옵션을 주면 강제로 shift를 하게 하는 기능이 있어서, 이 경우에도 shift를 하게 하면 문제가 해결된다. 근데 LALRPOP에는 이게 없다.

문법을 뜯어 고쳐서 충돌이 불가능하게 만든다. 루아 문법 같은 경우 수식으로 끝날 수 있는 모든 문장 뒤에는 (로 시작할 수 있는 문장(실질적으로 다른 대입문이나 함수 호출로 제한될 것이다)이 올 수 없도록 문법을 갈아 치우면 된다.

LALRPOP의 저자가 쓴 소개글에 따르면 s-r 충돌은 보통 문법 작성시의 실수로 생기는 경우가 많고, 따라서 실수를 잘 잡을 수 있게 하려면 s-r 충돌을 내버려 두는 게 아니라 문법을 고쳐서 충돌을 잡기가 더 쉽게 만들어야 한다고 생각하여 이런 결정을 내렸다고 한다. 나는 이 생각에 어느 정도 일리가 있다고는 보지만, 문제는 이 경우에는 충돌을 잡으려면 거의 모든 비단말 기호가 중복되어야 한다! 이는 충돌이 exp와 var 사이에서 일어나고, exp가 끄트머리에 등장하지 않는 문법 요소는 거의 없었기 때문이다. (하다못해 stmt조차도 repeat … until … 문법 때문에 중복이 필요하다.) 물론 어떻게든 고치면 돌아가게 만들 수 있었지만, 이런 상황에서 컴파일도 오래 걸리고 있다 보니 이틀 정도 잡고 고쳐 보다가 때려치고 손 파서로 선회했다.

그리하여, 현재의 카일루아 파서는 거대한 재귀 강하(recursive descent) 파서가 되었다. 중간에 수식 처리를 더 빠르게 하고 스택을 덜 쓰기 위해서 연산자 우선순위 파서를 추가적으로 구현하긴 했는데, 이건 성능 외에도 루아가 이미 똑같은 코드를 쓰고 있어서 거기에 맞추려고 한 것도 있다. 그리고 위에서 언급되었듯 손 파서가 실수할 가능성이 없진 않지만, 이미 파서를 몇 번 짜 봤고, 대상 문법이 극히 복잡한 게 아니며(LALR(1)로 파싱이 안 되는 수준이라거나…), 적절히 유지보수 가능하게 짜여졌고 테스트가 되는 상황이라면 손 파서를 굳이 기피할 이유는 없었다. 혹시 LALRPOP이 더 많이 발전해서 PEG 같은 걸 지원하기 시작하면 모르겠다.

입력 소스와 위치 추적

손 파서로 모든 걸 갈아 치운 뒤, 그 다음으로 파서 구조가 크게 바뀐 때는 오류 보고를 처음 설계할 때였다. 오류 보고에 대해서는 나중에 더 자세히 설명하겠지만, 일단은 오류 보고에는 기본적으로 열 단위까지 위치 정보가 들어갈 수 있다고만 알아 두자. 물론 대응되는 코드도 함께 표시되어야 한다(IDE에서는 그럴 필요가 없지만, 카일루아는 원래 명령줄 체커였다).

열 단위까지 위치 정보가 들어간다는 얘기는 파서가 뱉어 내는 AST에도 그 수준의 위치 정보가 모두 들어 있어야 한다는 소리와 동일하다. 이런 류의 위치 정보는 정말 아무 데나 들어갈 수 있기 때문에 일반화(generic) 타입이 있는 게 적절한데, 러스트 컴파일러에서 이 역할을 하는 자료구조의 이름을 Spanned라고 붙였기 때문에 카일루아에서도 마찬가지로 Spanned<T>라는 이름을 썼다. 이 타입이 가지고 있는 위치 정보(Span)는 크게 세 가지로 구성된다.

어느 파일에서 유래한 위치 정보인가? 물론 꼭 파일일 필요는 없다. 파서나 체커가 필요해서 생성한 경우도 있고, 내장 선언에서 유래한 경우도 있을 수 있다. 카일루아에서는 이들 정보를 모두 퉁쳐서 Unit이라는 타입으로 만들어 놓았다.

시작점이 파일의 어느 위치인가?

끝점이 파일의 어느 위치인가? 실제 범위에 끝점이 포함되냐 안 되냐는 대부분 편의 문제인데 카일루아에서는 포함되지 않는다.

그리고 각 필드 별로 32비트씩 12바이트가 할당되었다. Unit도 32비트라는 점에서 알 수 있듯이 이 데이터를 정말로 해석하려면 Source라 하는, 입력 소스를 위한 별도의 타입이 필요하다. 좀 더 정확히는 Unit을 만드는 주체가 Source라고 해야 할 것이다. 위치 값은 바이트 단위거나, (후술하듯) 워드 단위로 어느 쪽이 쓰이느냐는 파일에 따라 결정된다.

과연 이게 유일한 설계인가 하면, 당연히 그럴 리가. Source를 없애는 방법(Unit을 참조 카운팅을 하는 스마트 포인터로 갈아 치우면 된다)이라거나, 오프셋에 파일 정보를 합쳐 버리거나, 심지어 더 많은 정보를 Source에 던져 주고 아무 정보 없는 인덱스만 남기거나 하는 대안이 존재한다. 내가 위의 설계를 채택한 것은 기본적으로 i) 구현하기 쉽고 ii) 먼 훗날 Source 같이 위치 정보가 필요할 때 무조건 필요한 또 다른 맥락이 들어갈 때 기존에 존재하는 맥락이 있는 게 편해서였는데, 나중에 보니 내 생각이 아주 틀리진 않았지만 완벽한 것도 아니었다. 다른 설계의 장단점에 대해 잠시 살펴 보기로 하자.

Source가 없는 설계는 더 이상 Unit이 어느 AST에서도 사용되지 않을 때 메모리를 자동으로 해제해 준다는 잇점이 있고, 멀티스레드 환경에서 좀 더 사용하기 쉽다(기존 설계에서는 Source에 적절히 락을 걸어야 한다). 하지만 이런 상황이 생각보다 흔하진 않았고, 어차피 후술할 IDE와의 연동이 들어가면 이 설계의 장점이 크지 않다. 메모리를 더 많이 쓸 수 있고 참조 카운트의 부하가 있을 수도 있다는 것도 걸림돌이었다.

오프셋에 파일 정보를 포함하는 설계는 다르게 말하면 파일 정보가 없이 거대한 버퍼에다가 모든 파일의 내용을 집어 넣고 그 버퍼에서의 인덱스를 위치 정보로 쓰겠다는 뜻이다. (물론 나중에 참조를 위해서 파일 정보를 따로 둘 순 있겠지만.) 이 설계를 잠시 고민하다가 접은 가장 큰 이유는 파일이 변경될 가능성을 배제할 수 없었기 때문이다. IDE에서 일부 파일만 수정된 걸 새로 체크하는 경우는 흔한 일이다.

모든 위치 정보를 Source에 의존하는 핸들로 만드는 설계는 생각보다 할만할 수도 있다. 본래 이걸 채택하지 않은 이유는 위치 정보가 아무리 불투명해도 두 Span을 포함하는 하나의 Span을 계산한다거나 하는 정도의 연산은 할 수 있고, 그럼 그걸 할 때마다 Source를 요구하는 건 좋지 않다고 생각했기 때문인데, 다행히 그다지 흔한 일은 아니었다. 그러나 디버깅 과정에서 위치 정보를 볼 일이 꽤 많은데, Source가 없는 맥락에서 핸들 번호만 보이는 건 별로 유쾌한 경험은 아니라1 여전히 그다지 내키지 않는다.

한편으로 IDE와 연동을 해 보다 보니까 Source 자체에도 설계 변경이 필요했다. 하나는 UTF-16(처럼 생긴) 문자열의 존재로, 비주얼 스튜디오(C#)나 비쥬얼 스튜디오 코드(JavaScript)나 2바이트 워드를 기반으로 하는 문자열을 인터페이스에서 강제하고 있기 때문에 Source에서도 이를 따라야 했다. 결과적으로 Span의 인덱스는 파일이 어디서 왔느냐에 따라서 바이트 인덱스거나 워드 인덱스냐가 결정되고, 개별 문자는 8비트 바이트일 수도 16비트 워드일 수도 있게 되었다(다행히 루아의 모든 문법 요소는 7비트 그래픽 문자에 포함된다). 물론 인코딩 정보가 어디 있는 건 또 아니기 때문에, 8비트 바이트 파일이라면 UTF-8이거나 MBCS2로 가정하고, 16비트 워드 파일이라면 UTF-16으로 가정하는 식으로 처리한 뒤, 파싱 후에는 UTF-16을 UTF-8로 변환하여 바이트 문자열로 정규화하는… 뭐 그런 노가다를 해야 했다.

또 하나는 Source가 단순히 변경 가능한 수준 뿐만 아니라 버저닝이 가능해야 한다는 점이었다. 이 설계의 존재를 알게 된 것은 VS 확장을 만들 시점이었는데, 파싱을 하거나 체킹을 할 때 사용한 소스 코드와 현재의 소스 코드와 다를 수 있기 때문에, 소스 코드가 변경될 때마다 다른 버전을 붙이고 Span(에 대응하는 타입)을 버전들 사이에서 서로 변환 가능하게 하는 것이었다. 다행히 현재 카일루아 설계는 파일이 추가 삭제되는 것에는 대응되어 있으니까 기술적으로는 새 파일이 추가된 것처럼 구현하면 되지만, 어떤 “파일”들이 실제로는 같은 파일의 다른 버전을 가리키는지, 그리고 이들 사이에서 Span이 어떻게 변환되는지는 아직 구현한 게 없다. 따라서 현재는… 변경이 일어나게 되면 그냥 락을 건다. 장기적으로는 버저닝을 구현해야 할 거라 본다.

차회 예고

본래는 파서의 오류 복구를 이번 글에 쓰려고 했는데… 파서 얘기를 쓰다 보니까 너무 길어져서 해당 부분은 다음 글로 넘기기로 한다.

카일루아에는 실제로 이런 식으로 내부적으로는 핸들로만 보이는 값이 하나 존재한다. 바로 ScopedId라고 부르는 지역 변수 인덱스인데, 이름이 안 나오는 건 좀 귀찮지만 해 보다 보니까 결국 지역 변수 인덱스를 할당하는 로그를 찍으면 검색으로 알아낼 수 있어서 디버깅할 때 문제가 크진 않았다. 하지만 위치 정보를 이런 식으로 로그에 매번 찍어 줄 수는 없는 노릇이다. ↩︎

이 글을 쓰다가 지우다 한지는 꽤 오래 되었다. 첫 문단만 쓰여 있는 초안은 2015년 12월 15일이라는 날짜가 박혀 있고, IRC 로그를 잠시 뒤져 보니 처음으로 이 일을 하고 있다는 얘기를 은연중에 언급한 건 2015년 12월 3일이었다. 이렇게.

<lifthrasiir> 아 오랜만에 PL 관련된 걸 하려니까 아무것도 기억나지 않음…

그로부터, 지난 4월 25일에 카일루아라는 물건을 발표하기까지는 16개월이 걸렸다. 그동안 나를 아는 여러 사람들은 이제 나루를 다시 만드시죠라는 무시무시한 개드립을 치고 있었는데, 한 언어가 설계되고 구현되고 다시 설계된 뒤에 재구현되는 과정을 거쳐 보니 나루는 참 꿈도 컸구나 하는 생각이 든다. 이 정도 언어 만드는 데 이 정도 노력이 필요한데 나루 같은 걸 어떻게 만들 생각을 했단 말인가…

나에게 카일루아는 두 가지 의미를 가지고 있는데, 하나는 앞에서 말했듯 언어를 만드는 모든 과정을 처음으로 내 손으로 다 거친 사례라는 점이고, 다른 하나는 한국에서 드물게 언어 관련해서 밥 벌어 먹고 산 사례였다는 점이었다. (나는 이런 류의 일을 한 번이라도 해 본 사람이 학계 제외하면 한국에서 두 자릿수 정도 되지 않을까 싶다.) 여기에는 마침 상대적으로 필요한 인력이 적어도 되는 시기에, 되면 훌륭하고 안 되어도 큰 부담은 없는 프로젝트가 있었고, 그걸 수행하기에 적합한 사람이 마침 손이 비어 있어서 맡겨도 되는 몇 가지 행운이 함께 따라 주었던 것 같다. 물론 반대로 보면 혼자 하는 프로젝트는 언제나 번아웃의 위험이 있고 실제로 몇 차례 겪기도 했지만, 그럼에도 불구하고 이런 드문 기회를 얻은 것은 긍정적으로 생각한다. 어쨌든, 뭔가 나오지 않았는가? :)

이 글은 카일루아 연작의 첫번째 글이 된다. 어떤 부분은 당연한 부분도 있을 수 있고 어떤 부분은 나만 그렇게 생각했을 수도 있지만, 이번 연작에서는 카일루아의 처음부터 끝까지를 모두 하나 하나 다뤄 보려고 한다. 읽는 사람한테나 그걸 쓰는 나한테나 쉽지 않은 연작일 수 있는데 아무쪼록 모종의 도움이 되었으면 하는 바람이다.

일반적인 조언: 소숫점 n자리에서 반올림 같은 것은 출력의 문제입니다. 값을 미리 계산하면 99%의 확률로 실수합니다. printf 따위로 출력할 때 인자를 넘기는 것으로 대응하는 것이 쉽고 옳은 방법입니다.

이 얘기를 좀 더 길게 써 보려고 한다.

반올림이 출력의 문제라고 하는 것은 반올림의 거의 모든 사용이 출력 직전에 일어난다는 데서 나오는 관찰이다. 사실 착각하기 쉬울 수도 있는데, 우리는 십진법에 워낙 익숙하기 때문에 유효자릿수 같은 개념을 아무 생각 없이 사용하긴 하지만 사실 이건 숫자 범위(interval)를 나타내는 덜 정확한 방법에 불과하다. 이를테면 3.1415±0.0073 같은 오차 범위를 사람이 읽기 귀찮으니 3.142(7)이라고 표시하는 것인데, 이걸 두고 3.142 같은 숫자 자체에 의미가 있다고 주장하면 좀 곤란한 것이다. 반올림이 계산 과정의 일부로 들어가는 경우가 아주 없진 않은데1 일반적으로는 다분히 출력에 한정된 임의적인 것이므로 출력에 맡기는 게 맞다는 것이다.

반올림된 수치를 저장하는 게 문제가 되는 이유는 앞의 트윗에서도 링크되어 있지만, 의도치 않은 계산 실수를 쉽게 할 수 있다는 데 있다. 옛날에 쓴 글에서 사용한 표기법을 재활용하면, round(x)와 round([x])는 서로 다른 값이 나올 수 있는 데다가 [round([x])]의 참값이 round([x])보다 작을 수 있다. 구체적인 예시를 두 개 들어 보기로 하자. 아래에서 round(x, y)는 소숫점 y자리까지 남기고 반올림한다.

x = 1.005 [x] = 1.00499 99999 99999 89341 85896 35984 97211 93313 59863 28125 round(x, 2) = 1.01 round([x], 2) = 1.00 (???) x = 1.00005 [x] = 1.00005 00000 00000 10551 55962 60374 87760 18619 53735 35156 25 round([x], 4) = 1.0001 [round([x], 4)] = 1.00009 99999 99999 98898 65875 95718 44711 89975 73852 53906 25 (?????)

첫번째 예제에서는 [x] 시점에서 이미 원래 정확한 값보다 작은 숫자가 되어 버렸기 때문에 반올림에 의미가 없다. 두번째 예제에서는 반올림 자체는 잘 되었지만, 그걸 저장하니 마찬가지로 더 작은 숫자가 되어 버렸다. 따라서 (int) Math.round(x * 10000) 같은 걸 한다면 전혀 예상하지 못한 결과가 나와 버릴 것이다. 상황이 이러하니 정확한 값이 필요하다면 부동소숫점을 쓰지 말고, 부동소숫점을 이미 쓰고 있다면 반올림과 같은 출력에 관련된 것을 모두 출력에 맡기는 게 옳은 것이다.

한편 이 트윗을 쓰다 보니 루비 2.4부터는 1.005.round(2)가 1.01이 나온다는 충격적인 제보를 듣게 되었다. 이게 뭔 소리야?? 나도 모르는 사이에 스리슬쩍 루비가 BigDecimal을 기본값으로 만들었나?? 싶어서 코드를 찾아 봤는데 코드를 보고 더 충격을 먹었다. 문제의 커밋을 보면...

* numeric.c (flo_round, int_round): support round-to-nearest-even semantics of IEEE 754 to match sprintf behavior, and add half: optional keyword argument for the old behavior. (강조는 본인)

보아하니 이런 류의 버그에 대응하기 위해 sprintf를 고쳤고, 거기에 맞춰서 round 메소드도 따라 고친 것이다. 구현을 깊이 보진 않았지만 뭐 1 ulp2 사이에서 반올림이 가능하면 올려 버리는 그런 류의 구현이면 될 것이다.

이런 류의 반올림을 흔히 "겉치레 반올림"(cosmetic rounding)이라고 한다. 즉, 진짜 반올림 결과랑은 무관하게 사람이 보기 좋으라고 반올림을 한 것이다. 이런 류의 반올림이 전례가 없는 것은 아니어서, William Kahan의 고전에서는 매틀랩이 log_10(10^x)가 정수 x에 대해서 항상 x가 나오도록 내부적으로 조정이 되어 있다는 예제가 나온다. (정작 해당 함수는 다른 값에 대해서는 ~3 ulp까지의 오차를 보였다나.) 나는 이것이 문제의 본질을 흐려버리기 때문에 나쁜 선례라고 생각하고, 더 나아가서는 Numeric#round에 추가 인자를 넣은 것 자체가 문제가 있지 않나 싶은데 뭐 루비는 국제 표준(...)이 되었으니 어쩔 수 없을 지도 모르겠다.

내가 들었던 반론 중 하나는 사람이 계산 과정을 따라가도록 로직을 설계해야 하는 경우 (예: 게임에서 사용되는 숫자) 반올림이 중간 중간에 강제로 들어가야 할 수 있다는 것이었다. 틀린 말은 아닌데 나라면 부동소숫점 안 쓰고 소숫점 n자리까지 나타낸 고정소숫점 형식을 쓸 것이다. ↩︎

글을 읽어 본 사람들은 눈치챘을 지도 모르지만 사실 내가 짜증난 건 네이버 때문이 아니라 (네이버는 내가 안 쓰기도 하고 욕 좀 먹으면 고칠 가능성이 높으니까…) 한겨레 때문이었다. 좀 더 구체적으로는, 내 글은 “너네 글 쓰고 검수하고 하는 사람은 몇 명 안 되지만 그걸로 영향받는 사람들은 수천 수만명인데 좀 책임감이라는 게 있어야 하지 않겠니 그래도?”를 아주 정중하게 쓴 것에 가깝다. 여기에 대한 기자의 반응은 “우리가 틀려도 공론화가 되면 우리의 책임을 다하는 것이라 생각한다”1에 가까웠는데, 개인적으로는 이 반응이 더 어이가 없었다. 아 물론 JTBC가 태블릿 입수해서 공개하는 것 같이 공론화 그 자체로 언론의 역할이 되는 경우도 있는데… 그런 건 보통 특종이라고 부른다. 사실 자체만으로 사회를 움직일 수 있다는 확신이 생기는 그런 보도는 많지 않다.

좀 더 구체적으로 말하면, 내 사견으로 언론이 제공하는 컨텐츠는 크게 세 종류가 있다. 하나는 단순 정보의 제공이다. 이를테면 리빙 포인트 같은 것. 물론 이 역할은 언론의 근본적인 역할이라기보다는 언론이 가장 쉽게 접할 수 있는 활자 매체였던 시절에 하던 역할이 지금까지 내려 오는 것에 가까우며, 지금 와서 단순 정보만 제공하는 언론은 살아남기 힘들 것이다. 두번째는 공적으로 알려지는 것이 마땅하다고 여겨질 사건에 대해서 자료를 수집하거나 취재원을 찾아 다니는 것, 즉 사건의 탐사이다. 마지막으로 앞의 두 컨텐츠를 가공하여 독자에게 제공하는 과정에서 그것이 무엇을 의미하는지 관점을 제시하는 것이다. 이상의 세 종류의 컨텐츠는 분리되어 제공되기도 하고 적절히 섞여서 제공되기도 하는데, 해당 기사에서 한겨레는 네이버의 입장을 복붙해 버리면서 사건의 탐사에도 관점의 제시에도 실패했다. 그나마 어디처럼 HTTPS가 국제 표준이 아니라는 미친 소리는 하지 않아서 다행이지.

한겨레를 살짝 변호해 주면, 뭐 이게 다른 나라라고 상태가 좋은 건 아니지만, 특히 한국 언론은 광고주에 지나치게 휘둘릴 정도로 재정 상태가 좋지 않으며, 재정 상태가 안 좋을수록 (기자 수와 능력에 크게 의존하는) 사건의 탐사가 취약한 경우가 많다. 그러니 무슨 관점을 제시하고 싶어도 잘 될 턱이 없는 것. 이게 변호인진 잘 모르겠다… 하지만 이건 한겨레 사정이고 최근의 퀄리티 저하는 한겨레가 한걸레(…)라는 멸칭으로 불릴 정도로 심각한 상황인데, 여기에 위기의식을 가질 망정 우리가 공론화를 하면 오피니언을 이끌 수 있다는 안일한 자세가 드러나는 반응을 보니 뒷골이 좀 많이 땡겼다.

내가 이 건에서는 한겨레가 관련되어 있어서 한겨레를 깠지만, 사실 이런 시각이 한겨레에만 국한되어 있지는 않을 거라고 생각한다. 기실 한국에서 정말로 탐사보도를 제대로 할 수 있을 정도로 자본도 있고 거기에 호응하는 대중도 많은 언론은 JTBC 밖에 남지 않은 것 같고2, 여기에서 그런 시각을 가진다면 뭐 그럴 수 있겠다 싶지만 다른 데라면 아니올시다. 꽤 잘 나가는 신규 인터넷 언론들을 보면 이런 점을 인식하여 컨텐츠 특화를 많이 하는데, 이를테면 뉴스타파 같이 사건 탐사에 올인을 하거나, 슬로우뉴스 같이 자원이 많이 드는 사건 탐사를 피하고 오피니언에 집중하는 등의 접근을 볼 수 있다. 더 이상 오피니언 리더가 될 수 없다는 걸 인식했으면 이런 시도라도 해야 하는 거 아닐까? 아니면 옛날에 내가 제안했듯 매체를 최대한 활용해 보시거나.

주의. 나는 답장을 받긴 했으나 이 답장을 공개해도 된다는 허락을 미리 구하지도 않았고 필요성도 느끼지 않아서 답장을 공개하지 않는다. 즉 앞의 따옴표에 쓰여진 내용은 이 답장에 대한 나의 해석으로, 내가 제대로 답장을 해석한 것인지, 또는 내가 의도적으로 답장의 내용을 왜곡하는 것인지에 대해서 나를 믿어서는 안 된다! 뭐 그렇다고. ↩︎

한국에서는 모 제품의 영향으로 백신이라고도 많이 부르는 안티바이러스(AV) 소프트웨어는 옛날부터 필수적인 것으로 인식되어 왔다. 컴퓨터는 일반 목적의 컴퓨팅1 기기이니만큼, 자칫 실수하면 내가 원하지 않는 계산을 할 수도 있는데 AV는 이 상황을 해결하기 위한 방법 중 하나이다. 그런데 그것을 아시는가? 대부분의 AV 소프트웨어가 생각보다 보안적으로 취약하다는 것을? 농담같아 보인다면 해커뉴스에서 작년에 나온 AV 뉴스만 모아서 보자. 노턴 안티바이러스가 사정 없이 뚫린 것이 아마도 가장 대표적인 사건일텐데, 기사화만 덜 되었지 거의 모든 주요 AV 소프트웨어에서 강력한 취약점이 하나 쯤은 튀어 나왔다. 도대체 무슨 일이 일어난 걸까?

컴퓨터는 기본적으로는 결정론적으로 돌아가고, (외부의 사건 등을 모두 포함해서) 입력이 고정되면 출력이 똑같이 나온다는 것이 가장 큰 특징이다. 그래서 컴퓨터에서 문제가 생길 경우 그건 컴퓨터(하드웨어)가 잘못 해서 그런 게 아니고 거기에 있던 소프트웨어가 잘못 했거나 모니터와 의자 사이에 있는 사람이 잘못해서 그런 것이다. 그리고 문제를 미리 막냐(방어)와 문제가 터졌을 때 확산을 막냐(감지)로 다시 세분화하면, 여섯 가지 상황이 가능하다.

시스템이 문제여서 방어

시스템이 문제여서 감지

소프트웨어가 문제여서 방어

소프트웨어가 문제여서 감지

사람이 문제여서 방어

사람이 문제여서 감지

그래서 뭔 말을 하고 싶냐면, 원래의 AV는 4번과 6번 밖에 감지할 수 없다. 그것도 한동안은 “알려진” 악성코드만을 패턴으로 감지할 수 있었는데(signature-based detection), 당연히 패턴을 계속 바꾸는 악성코드가 등장하자 AV의 접근은 i) 일단 알려진 악성코드는 빠르게 갱신해서 감지해 내고(뒤에서 못 걸러냈다고 손을 놓고 있을 수만은 없으니) ii) 그게 안 되면 차선으로 이상한 징후를 감지해 보자는 것으로 바뀌게 된다. 이른바 AV의 보안 솔루션화를 통해 2번을 추가적으로 감지하겠다는 전략인데, 문제는 보안 솔루션은 시스템에 속한다는 것이다. 즉 AV에 보안 취약점이 있으면 일반 소프트웨어처럼 그 소프트웨어로 문제가 국한되는 것이 아니라 전체 시스템에 영향을 미친다.

더 큰 문제는 일반적으로 시스템으로 받아들여지는 운영체제 벤더들이나 웹 브라우저 벤더들은 보안적으로 매우 높은 기준선을 가지고 있으나(물론 하루 아침에 이렇게 된 건 아니고 오랫동안 뚫리면서 기준이 올라갔다), AV 벤더들은 이런 기준선을 적용받지 않는다는 점이다. 이를테면 노턴 안티바이러스 사건의 경우 실행 파일 압축을 풀기 위해서 시스템 수준에서 압축을 푸는 코드를 가지고 있었는데, 이 코드가 잘못되었을 때 어떤 방어 장치도 없었기 때문에 취약점이 발견되자 바로 시스템이 뚫려 버렸다. 비교를 해 보면, 요즘 웹 브라우저 벤더들은 똑같은 종류의 코드(이를테면 글꼴 포맷이나 이미지 포맷 등)를 샌드박스에 집어 넣고 돌리는데, 이런 류의 코드에 버그가 없다는 걸 보장하기에는 복잡도가 크기 때문에 차라리 이상한 일이 일어나도 피해를 최소화하는 게 낫다는 걸 깨달았기 때문이다. 이런 샌드박스 접근이나 요즘 모질라가 전폭적으로 밀고 있는 “언어 기반” 보안 같은 접근은 비용은 차치하고라도 상당한 효과가 있다고 알려져 있으나 AV 벤더들은 이런 걸 시도해 본다는 낌새조차 없었다. 혹자는 AV가 보안 문제들을 원천적으로 막는 데 인센티브2 자체가 없어서 이런 사태가 벌어지지 않냐 하는 추측을 하기도 한다.

하나 더 언급해야 하는 것은, AV는 원치 않는 계산을 막는 유일한 방법이 아니라는 것이다(애초에 AV는 방어를 하기도 어렵다). 3번 시나리오를 막는 가장 확실한 방법은 버그가 없거나 적은 소프트웨어를 짜는 것이고, 4번 시나리오는 이른바 방어적 프로그래밍이라고 하는 전략이나, 컴파일 시점에서 방어 코드를 삽입하는 전략으로 흔히 구현된다. 1번 시나리오는 가장 높은 권한으로 실행되는 코드(“커널”)를 최대한 줄이는 전략을 생각해 볼 수 있고, 2번 시나리오는 용도별로 계정을 나누는 등의 정책이 해당된다. 가장 어려운 것은 사람이 관여되는 5와 6번 시나리오로, 교육을 통해 애초에 문제가 될만한 짓을 하지 않는 것이 5번, 그리고 문제가 되는 상황에서 지속적으로 상기시켜 주는 것이 6번에 해당할 것이다(아시다시피 완벽하진 않다). 이를 다시 정리하면,

시스템과 소프트웨어가 충분히 안전하고, 그걸 쓰는 사람이 충분한 보안 의식을 가지고 있다면, AV는 불필요하다.

물론 이는 전건 두 개가 완벽하게 만족될 때만 성립하는 명제이다. 현실에서는 시스템도 소프트웨어도 그 정도로 안전하지는 않으며(특히 제로 데이 공격의 존재는 위협 감지의 필요성을 배가시켜 준다), 사람은… 말을 말자. 그렇기 때문에 현실적으로는 가벼운 AV가 있는 것 자체는 감수해야 할 비용이다(윈도의 경우 Windows Defender가 이 역할을 하고 있다). 하지만 AV가 이 모든 상황을 해결시켜 줄 거라는 믿음은, 어, 말 그대로, 믿음—즉 미신이다. 개인 단위에서 AV보다 더 중요한 것은 소프트웨어 업데이트(1번 및 3번 시나리오를 강화시키기 위하여)와 보안 의식(5번 및 6번 시나리오를 차단하기 위하여)이다. 그리고 운영체제들이 점차 방어 우선 전략으로 가면 갈수록—우리는 iOS가 이걸 얼마나 성공적으로 수행하는지(와 그에 수반되는 개발자들의 비용)를 봐 왔다—더욱 더 중요해지는 것은 후자가 될 것이다. 보안은 공짜가 아니다.

우리가 그다지 인식하지 않을 뿐 “계산”(computation)은 매우 본질적인 개념으로, 우리가 머릿속에서 하는 모든 생각들도 계산이요, 우주의 입자들이 상호작용하는 것도 계산의 일종으로 볼 수 있다. 단지 우리가 계산이라고 하면 숫자로 하는 극히 단순한 계산을 가리키는 경우가 많아서 컴퓨팅이라는 미번역어를 잠깐 썼을 뿐. ↩︎

그러니까, 옛날에 이런 정신나간 크로스워드 퍼즐1을 보고 와 미쳤네ㅋㅋㅋ 하고 실제로는 풀지 않고 넘어간 적이 있었다. 이걸 푸는 데 얼마나 시간이 걸릴지 조금만 해 보고 짐작할 수 있었기 때문이다. 근데 어제 누군가가 풀려고 하고 있길래... 낚여 버렸다.

처음에는 PDF 파일 위에다 텍스트를 올려 놓아서 편집을 하다가, 실수로 잘못 건드는 경우를 도저히 참을 수 없어서 (그리고 한 번 백트래킹을 할 뻔 해서...) 아예 각을 잡고 풀이 과정을 텍스트로 써 놓고 보니 왠지 공개하고 싶어졌다. 이 접근은 옛날에 스도쿠 퍼즐을 인간이 푸는 방법대로 푸는 프로그램을 본 적이 있어서 떠올린 것인데, 물론 적절한 알고리즘2을 쓰면 풀리기야 하겠지만... 원래 퍼즐이라는 건 자동으로 풀면 재미가 없는 것이니까. 그런 고로 뭐 이런 그지 깽깽이 같은 퍼즐을 어떻게 풀어 라고 생각한다면 스포일러를 당하고 더 풀지 않도록 하기로 하자.

MIT Mystery Hunt 2013 문제 중 하나였다고 한다. ↩︎

이전 글에서 예고했듯, 앞에서 코딩의 발전에 대해서 얘기했다면 여기에서는 모델링과 기타 알고리즘의 근황을 다루기로 한다. 아마 이전 글보다는 덜 기술적…일까?

커다란 데이터를 그 구조를 살펴서 정확히 같거나(비손실) 거의 같은 결과(손실)로 복구할 수 있도록 데이터를 줄이는 걸 압축 알고리즘이라고 한다. 압축 알고리즘은 데이터의 크기를 줄일 수 있는 대신 그걸 압축하거나 압축 해제하는 데 연산을 소모하기 때문에 항상 트레이드오프가 따라 붙었고, 그래서 ZIP 포맷의 유명세와 함께 DEFLATE가 “대강 대충 쓸만한 적절한 알고리즘”의 자리를 먹어 버린 뒤로는, 특히 지난 십수년간은 더 나은 압축 알고리즘이라는 건 연산 비용을 쓰면서 데이터를 줄일 만한 이유가 있을 때나 고려해 보는 선택지에 불과했다. 그러던 것이 재작년에서 작년 사이에 갑자기 크게 바뀌었다. 모두가 압축 알고리즘에 대해서 관심을 가지고 모두가 그 얘기를 한 번씩은 하고 있다. 아마도 가장 상징적인 사건은 작년에 페이스북이 압축 속도나 압축률이나 모두 DEFLATE를 상회한다는 Zstandard라는 것을 내 놓은 것이리라.

도대체 왜 갑자기 압축 알고리즘이 다시 주목을 받게 되었는가? 아마도 짐작할 수 있는 이유로는 공짜 점심이 끝났기 때문일 것이다. 컴퓨팅 기술은 2000년대까지만 해도 착실히 지수적으로 증가해 왔고, 덕분에 우리는 30년 전보다 100배 가벼운데 1000배 빠른 CPU에 1000배 많은 데이터를 담을 수 있는 스마트폰으로 플래피 버드를 플레이할 수 있게 되었다. 플래피 버드 드립은 농담하는 것이 아닌게 연산력이 올라가면 그동안 시도하기 어려웠던 다양한 소프트웨어 개발 기술을 써 볼 수 있게 되기 때문이다(30년 전에 쓰레기 수집[GC] 같은 것을 아무 데서나 써 먹기는 쉽지 않았을 것이다). 근데 물론 연산력은 계속 올라가고는 있지만 성장세도 둔화되었을 뿐만 아니라 아무 것도 안 하면 빨라지는 그런 성장은 이제 끝났다는 게 문제이다. 멀티코어도, GPU 연산도, 그리고 모바일 네트워크도 성능이 올라가긴 하는데 그 과실을 먹으려면 뭔가를 해야 하는 시대가 온 것이다. 그러하니 지금껏 경시되어 왔던 분야에 사람들이 다시 눈을 들이기 시작하고, 그 중에 압축 알고리즘이 있는 셈이다.

지난 십수년간 압축 알고리즘 동네에서는 무슨 일이 일어났는가? 그걸 알려면 압축 알고리즘이 실제로 어떻게 구성되고, 어느 부분이 공략 가능하며, 무슨 발견이 일어났는지를 살펴 봐야 한다. 그래서 이 글과 다음에 따를 글에서는 압축 알고리즘의 큰 구성 요소를 둘로 나눠서 각각의 근황을 살펴 보기로 한다.

가끔 좀 진지한 얘기를 하다 보면 내가 말하려는 개념이 일반적으로 있을 것 같아서 이를 나타내는 낱말을 찾아 보다가 못 찾아서 빙빙 돌려서 설명하는 경우가 제법 있는데, 최근 들어 알게 된 낱말 중에 하나로 “교차성(intersectionality)”이라는 것이 있다. 어떤 대상이 여러 특질을 가질 수 있다면 그 특질이 교차해서 생기는 세부 특질 또한 중요하다는 것. 집합론적으로 말하면 집합 A와 B가 있을 때 A와 B가 서로 소가 아니라면 당연히 교집합 A ∩ B가 존재하니 A ∩ B와 A ∩ BC, AC ∩ B를 서로 묶어서 생각하려는 것은 잘못된 얘기라는… 이렇게 써 놓으니 엄청나게 당연한 얘기 같아 보이지만 많이 까먹기도 하는 그런 것이다.

교차성이라는 낱말 자체가 사회학에서, 그것도 하필(?) 차별에 대한 연구에서 나온 이유는 아무래도 우리는 집단을 서로 소인 집합, 즉 분할(partition)으로 나누는 데에 익숙하지 서로 겹칠 수 있는 집합으로 나누는 데는 익숙하지 않다는 점이 크지 않았을까 싶다. 내가 저 낱말을 찾던 맥락 중 하나로는, 사람들은 어렴풋이 차별받는 집단에 대한 연민1을 가지고 있지만, 그 연민은 그 집단을 대표하는 이미지에 대한 것이지 집단 자체에 대한 것은 아니며, 그 이미지가 깨지면 사람들의 반응은 크게 바뀐다는 것이었다. 이를테면 현재 진행형인 유럽 난민 사태에서 난민에 대한 인식이 나빠진 이유 중 하나는 난민들이 작년 새해 벽두에 성폭행을 많이 일으켰다는 사건 때문인데, 거야 문화가 다른 사람들이 한 나라에 100만명이나 유입되면 일이 안 터질 리가 있나(…). 난민이 아니라 선진국 국가라도 그 정도 사람 수가 문화가 다른 나라에 짧은 시간 안에 유입되면 비슷한 규모의 사건이 안 터질 거라고 장담할 수 없다. 난민은 그 자체로 (사회에 섭동을 가져 오기 때문에) 다른 문제이기에 난민의 유입에 따라 예상되는 사회적 비용을 추산해서 정책에 반영하는 것이 옳지, 난민 그 자체가 옳지 않다고 난리가 나는 건 여러 의미에서 눈 뜨고 못 볼 일이다. 자, 이제 이 사태를 보고 “유럽인들은 멍청하게도 저런 걸 나눠서 생각하지 못 하네”라고 하는 사람들은 자신이 조선족에 대해서 어떻게 생각하는지 되짚어 보기로 하자. 눈에 보이는 사회 혼란만 안 일어났지 조선족에 대한 한국 사회의 취급은 한국 사람이 남 지적을 할만한 수준이 아니다.

교차성이라는 것은 사람들이 쉽게 바로 받아들이는 개념은 아니기 때문에 결국 이런 함정이 있으니까 조심해야 한다라는 걸 사람들이 다른 방법으로 깨달아야 하는데, 작년 내내 느낀 점은 역시 이걸 받아 들이는 것 자체가 근본적으로 불가능한 거 아닌가… 하는 쓰디쓴 결론이었다. 엄청나게 긴 시간이 지나 우리는 일부 집단을 사회에 반영시키는 데는 성공했지만 그건 각개격파이지 반영 자체가 자동화된 프로세스가 될 수는 없는 걸까 하는 비관적인 생각. 그나마 이런 생각을 나만 하고는 있지 않을 거라는 것이 위안거리인데, 2017년이 이미 쫌 지나긴 했지만 앞으로 어떻게 될지는 두고 봐야 겠다. 확증편향만 강해지는 일은 없었으면.

메아리 저널에서는 리그베다위키(구 엔하위키)에 대해 2013년에 한 번, 2015년에 한 번 그리고 망한 뒤에(…) 한 번 더 다룬 적이 있다. 나의 기본 견해는 예나 지금이나 크게 달라지지 않았는데, 청동 씨가 사이트 운영 및 중재 과정에서 상당한 인적·물적 투자를 했음은 부정하지 않으나(그리고 그 이유 때문에 청동 씨에게 무제한적인 공격을 하지는 않으나), 그것이 저작권 및 저작권과 유사한 특성을 가지는 다른 권리를 보유할 정당성을 주진 않는다는 입장이다. 왜냐하면 사이트 운영 및 중재는 사용자가 많은 사이트의 동작을 위하여 필수 불가결한 작업이며, 사이트가 동작한다는 이유만으로 데이터베이스권1이 부여된다는 것은 상당히 납득이 가지 않는 결과이기 때문이다. 또한 저작권법에서 “데이터베이스제작자”의 정의는 그 데이터베이스를 체계적으로 구성하는 데 큰 역할을 한 사람이어야 하는데, 운영자 수가 극단적으로 적은 구조 때문에 리그베다위키의 결정 프로세스는 후기로 갈수록 전체 위키를 커버하지 못 했으며, 여기에 대한 불만이 여기저기서 터져 나왔으나 청동 씨는 사람을 충원하는 대신 이상한 인터넷 언론을 만들었다(…).2 이러한 상황이니 그의 위키에 대한 권리적 기여는 데이터베이스권보다는 무려 1만 수천 개에 달한다고 추정되는 편집저작물의 저작권자(중 하나)로 보는 것이 더 온당하다고 생각해 왔다. 1심에서 데이터베이스권을 인정하지 않고 대신 부정경쟁방지법에 의거하여 판결을 내린 것은 그래서 상당히 적절한, 기여를 인정하면서도 확대 해석을 피한 결정이었다고 생각했다.

그런데 이번 2심 결정은 매우 당혹스럽다. “체계와 카테고리, 항목 등을 설계했을 뿐만 아니라 인적·물적으로 상당한 투자를 했고 체계적 검색 기능도 도입했다”라니, 그가 설계했다는 계층적 체계(특히 첫 페이지에 있는 그것)와 카테고리는 나무위키에서 모조리 갈아 엎어졌다. 단지 리그베다위키에 대한 반감에서 생겨난 것 뿐만이 아니라, 애당초 현행 나무위키의 카테고리 구조는 리그베다의 그것과는 완전히 다른, 굳이 비교하자면 미디어위키에 가까운 형태로, 이는 위키 기여자들이 그가 만든 체계를 좋아서 쓴 게 아니라 그냥 존재하기 때문에 또는 바꾸는데 품이 들기 때문에 사용했다는 것을 방증하며 사용자 참여만 가능했으면 얼마든지 바뀌었을 것임을 함의한다. “통일되고 짜임새 있는 목차 구조와 페이지 작성 양식 등을 만들었다”라고? 그런 걸 만들었다고 치면 왜 수십만개의 문서 중 대부분은 문서의 통일성보다는 리그베다위키스러운 표현에 더 집착하고 있는 것인지? 현재 알려진 정보만 봐도, 나는 여러 의미에서 법원이 위키 사이트의 운영과 중재를 다른 사이트의 그것보다 더욱 더 어려운 것으로 평가하고 있는 (그래서 이를 “상당한 투자3”로 인정한) 것이 아닌가 의심스럽다.

이 판결이 대단히 우려스러운 것은, 청동 씨의 의도는 어쨌든간에 웹사이트가 유지될 수준의 운영을 통해서 데이터베이스권을 획득할 수 있다는 전무후무한 결론이 유도될 수 있는 길이 열렸다는 것이다. 이는 엔하위키 미러 같이 단순히 이를 복제하는 것으로 수익을 얻으려고 하는 회색지대에 가까운 사업자에게만 독이 되는 것이 아니라(차라리 그랬으면 좋으련만!), 커뮤니티가 사이트 구성원이 아닌 사이트 저작물을 통해 형성되는 위키 커뮤니티의 사이트 종속성을 강화시켜 사용자에게도 독이 될 것이다. 현재의 나무위키도 불만을 가진 사람들은 많이 있지만 이게 집단 불만으로 표출되지 않는 이유는, 적어도 나무위키는 리그베다위키 같이 저작물의 이동을 불가하게 하는 상황을 만들지 않을 거라는 믿음이 있고 현재까지는 좀 느리긴 해도 어떻게든 지켜지고 있다는 것 때문이다. 이 사건은 이제 3심으로 넘어갔고, 새삼스럽지도 않지만 이번에도 양자가 함께 상고를 한 상태인데 최종 판결에 따라서 상당한 파장을 불러 일으킬 거라 생각한다. 많은 사람들이 관심을 가지고 지켜 봐야 할 이유이다.

Sui generis database right. 기존의 저작권법이 커버하지 못 하는, 누구라도 특정 기준을 가지고 체계적으로 만들 수는 있어서 창작물로 인정받진 않지만 그 과정에 상당한 인적·물적 자원이 소요되는 편집물을 위한 저작권의 마이너 카피. 예를 들어서 “해리 포터를 다룬 책들의 목록” 같은 것은 창작성은 없지만 이걸 제대로 만드는 건 꽤 많은 노력이 필요하기 때문에 (단순히 제목에서 해리 포터라는 이름을 찾는 것이 아니니까!) 데이터베이스권으로 인정받을 수 있다. 근데 리그베다위키 측의 주장은 결국 위키의 내용과는 별개로 그 색인이나 관련 문서의 나열은 데이터베이스권으로 인정받아야 한다는 것인데, 색인은 자동 색인이고 관련 문서의 나열은 개별 기여자들이 작성한 게 훨씬 많다(…). ↩︎

내가 첫 글을 썼던 2013년 즈음부터 이 문제의 사이트는 수면 아래에서 암약(?)하고 있었는데, 이는 저작권의 해석 문제로 쉽게 상업적 활동을 하기 어려운 위키는 현행 유지하고, 이와 연결된 별개의 인터넷 사이트를 상업적인 발판으로 삼으려는 시도였다고 본다. 물론 그가 금전적으로 여유롭지 않다면 이런 시도 자체를 나쁘게 생각할 이유는 없으나, 그렇다고 해서 위키가 잘 운영되지 않은 것을 부정할 수는 없을 것이다. ↩︎

1차 자료(primary source)는 정보와 매우 가까운 기록이나, 그러한 사람으로부터 유래한다. 큰 교통사고가 났다면 1차 자료에는 교통사고의 당사자나, 그 목격자, 경찰 기록, CCTV 등이 포함될 것이다. 1차 자료에도 당연히 그 정보의 해석이 들어갈 수는 있지만 편향을 배제할 수 없기 때문에 바로 쓰이지는 않는다(교통사고 당사자는 자기 책임을 당연히 부정하려 들 것이다).

2차 자료(secondary source)는 1차 자료를 일반화하거나 분석하고 해석한 결과이다. 교통사고의 예를 계속 이어가면 2차 자료에는 사건을 다루는 신문 기사 같은 것이 포함되겠다.

3차 자료(tertiary source)는 1차나 2차 자료를 요약하고 정리한 결과이다. 대부분의 백과사전 같은 것이 3차 자료에 포함된다. 3차 자료는 정보 그 자체를 얻기보다는 정보를 얻기 위해 어떤 문헌을 더 찾아 봐야 하는지에 더 많이 쓰인다. 만약 요약 정리한 결과에 추가적인 해석이 들어간다면 2차와 3차 자료 사이의 경계는 뚜렷하지 않을 수도 있다.

이상의 분류를 사용해서 독자 연구 금지 정책을 거칠게 요약하면 “공개 발표된 믿을만한 자료를 사용하되, 자료의 해석은 이미 2차 및 3차 자료로 발표된 것에 근거하여야 하며, 3차 자료는 자제”한다고 할 수 있다. 근데 보통 위키백과질을 하다 보면 이걸 아무 생각 없이 “믿을만한 주요 언론에 발표된 것”으로 줄여서 생각하는 경우가 있다. 믿을만한 주요 언론이 무슨 기준으로 정해지고, 언론에 일단 발표되면 문제가 없다는 것인지에 대한 성찰 없이 말이다. 이런 단순화는 두 가지 이유로 틀렸는데,

언론은 2차 자료의 주요 생산자이기도 하지만 3차 자료도 더럽게 많이 생산한다. 아니, 사실 지금같이 저널리즘의 상태가 좋지 않다면 2차 자료보다 3차 자료의 생산이 더 쉽고 빠르니 이걸 선호하게 된다. 요즘 미들 미디어라 불리며 열심히 세를 불리고 있는 새로운 형태의 언론은 아예 2차 자료를 완전히 건너 뛰고 3차 자료만 생산하기로 마음먹은 경우라고 할 수 있다.

그렇다고 언론이 1차 자료를 생산하지 않냐 하면 그럴 리가. 이는 보통 저널리즘의 주된 가치라고 생각하는 탐사 보도에서 여실하게 드러나는데, 탐사 보도를 통해 기자가 사건 당사자가 되는 경우가 적지 않게 있다. 최근의 예를 들자면 《시사IN》의 주진우 기자 같은 사람이 있을 것이다. 분명 이러한 사람은 언론에 필수 불가결하지만, 그렇게 생산된 자료가 2차 자료라고 하기에는 이미 기자가 너무 정보와 가까워져 버린 것이다.

이게 너무 길어 보이니 좀 더 간단하게 말하면 언론은 1차, 2차, 3차 자료를 모두 생산할 수 있는 매체이다. 즉, 언론에 올랐다는 것만으로 자료의 편향이 제거되고 자료의 해석이 의미가 있다고 단정할 수 없다! 어찌 보면 당연하지만, 이게 왜 당연한 지는 자료의 성격을 나누어 분석해야만 이해할 수 있다는 점이 내가 이 분류법에서 배운 가장 큰 깨달음이었던 것 같다.

거대한 HTML 명세를 오랫동안 홀로 편집했던 걸로 유명한 (지금은 몇 명이 더 붙었다) Ian Hixie의 웹사이트를 예전에 둘러 보다가 Hixie English라는 페이지를 본 적이 있다. 이른바, 남들이 영어를 어떻게 쓰건간에 나는 이런 식으로 영어를 쓰겠다라고 선언하는 글이다. 언어의 사회성을 중히 여기는 사람이라면 경악할만한 선언이지만, HTML 명세가 이상한 영어로 쓰여져 있지 않다는 점도 그렇고, 사실 영어에서는 이를테면 각 언론사나 각 대학 별로 영어의 맞춤법에 가깝다고 할 수 있는 존중할 만한 스타일 가이드가 있는 경우가 많으며 The Elements of Style 같이 그와는 별개로 만들어진 스타일 가이드도 있다. 상황이 이러하니 개인이 자신만의 규칙을 만드는 것이 흔한 일은 아니긴 하지만 딱히 못 할 일은 아니기도 하다. 이 시점에서 질문을 던져 보자. 무슨 장점이 있을까, 그리고 한국어에는 왜 그런 게 없을까?

뒤의 얘기부터 먼저 하자면, 영어는 이미 오래 전부터 (현대 철자법의 모태가 되었다고 평가받는 셰익스피어는 500년 전 사람이다!) 근대적인 표기로 쓰여진 언어이자, 그 글이 많은 사람에게 읽히는 환경이 오래 전부터 조성된 언어이다. 스타일 가이드가 글을 쓸 일이 많은 언론사나 대학에서 유래하는 게 괜한 이유가 아닌 것이다. 반면 한국어는 한글의 창제 과정에서도 알 수 있듯이 국가가 주도해서 글쓰기를 확립시킨 언어로, 물론 세종대왕의 한글 창제가 전혀 비판받을 일은 아니겠으나 실제 글 쓰는 이들의 필요성보다 국가의 권장과 교육이 더 큰 압력으로 작용한 언어라고 생각할 수 있다. 게다가 현대 한국어 표기에서 가장 특징적인 요소들은 모조리 1933년 한글 맞춤법 통일안에서 왔는데(어원을 밝혀 적고, 토씨를 제외하고 낱말 단위로 띄어쓰는 게 모두 여기에서 명문화되었다), 이렇게 따지자면 진정한 현대 한글 표기는 100년도 안 된 것이니 필요성이 생길 시간조차 부족했을 것이다.

이런 역사적인 배경을 감안하고 국가 주도의 맞춤법과 민간 주도의 스타일 가이드의 장단점을 생각해 보자. 대부분 한 쪽의 장점은 다른 쪽의 단점인 경우가 많으므로 함께 다루는 것이 좋겠다.

맞춤법은 하나 뿐이고 스타일 가이드는 여러 개이다. 맞춤법을 중히 여기는 사람들은 규칙이 하나 뿐이기 때문에 서로 다른 표준이 충돌하면서 생기는 혼란이 사라진다고 주장하는 반면, 그렇지 않은 사람들은 상황에 따라 적절한 세부 규칙이 필요할 수도 있는데 이를 모두 담을 수 있는 표준안은 존재할 수 없다고 주장한다. 세부 규칙 자체는 이미 수많은 전문 용어와 고도로 분화된 사회에서 필요성이 증명되므로, 즉 이 사안의 중점은 “세부 규칙을 표준화할 필요성”이 “여러 표준으로 인한 혼란”을 감수할 수 있을 만큼 중요하냐에 달렸다.

국가 주도의 맞춤법은 사투리나 서로 다른 계층의 언어 사용자를 고려하지 않는/못한다는 지적이 많다. 한국의 예를 살펴 보면, 한국은 한동안 중앙 정부에서 사투리를 의도적으로 배제해 왔으며, 그런 명시적인 배제가 없는 지금도 사투리에 대한 인식은 완전히 나아지지 않았다. (이를 단적으로 보여 주는 것이 다름 아닌 제주어일 것이다.) 반면 지역 갈등과 세대 갈등은 단순히 언어의 분화를 인정하는 수준으로 해결 할 수 있는 게 아니지 않느냐는 이유에서, 이것이 왜 맞춤법의 책임이느냐는 반론도 있다.

국가 주도의 맞춤법은 국가의 프로파간다를 담는 경우가 많다는 지적도 있다. 멀지 않은 예로 저기 조선1의 문화어는 하나부터 열까지 프로파간다 투성이이며, 그 정도로 대놓고 하지 않는다 하여도 한국어의 “우리나라”의 정의처럼 은연중에 프로파간다가 드러나는 경우도 종종 있다. 민간이 주도한다고 프로파간다가 사라지진 않겠지만 적어도 선택의 여지는 있지 않겠냐는 논리인 것이다.

국가 주도의 맞춤법이 실제 언중의 언어 생활을 너무 늦게 반영하는 경우가 많다. 이건 맞춤법이 촘촘할수록 더 심해지는 문제인데, 한국의 맞춤법의 경우 낱말의 정의를 사실상 《표준국어대사전》에 맡겨 버리는 바람에 낱말의 경계에 민감한 띄어쓰기가 갱신 잘 안 되는 사전에 매여 버리는 결과를 낳았다.2 짜장면 같이 언중 모두가 쓰는 낱말이 한동안 비표준어였던 경우도 있고, 비교적 변화가 빠른 낱말 말고 문법의 변화에서도 이런 현상이 종종 보인다. 그러나 “다르다”가 “틀리다”로 흡수되는 현상 같이 언중의 언어 생활이 항상 올바르다고 할 수만은 없기 때문에, 반영이 늦다는 것이 단점이 될 수도 있지만 장점이 될 수도 있다.

이상이 내가 가능하면 중립적으로 국가 주도의 맞춤법에 찬성하는 시각과 반대하는 시각을 정리한 내용이다. 여러분은 어떻게 생각하시는지? 다음은 위 논의에 대한 (엄밀히는 그 중에서도 한국어에 국한된) 나의 대답이다.

나는 한글 맞춤법의 필요성에 대해서는 인정하되, 국립국어원이 더 적극적으로 한글 맞춤법의 탈독재에 앞장서야 한다고 생각한다. 앞에서 말했듯 한국어에서 맞춤법이 본격적으로 필요해진 건 길게 잡아야 백 몇십년에 지나지 않으며, 이런 짧은 역사를 생각하면 국가가 주도하는 모델 자체를 부정할 수는 없다. 그러나 그 결과로 한글 맞춤법이 다른 가능성을 모조리 날려 버리면서 독재를 하게 되는 것은 올바르지 않다. 근년간에 국립국어원이 짜장면 같이 모든 언중이 쓰는 낱말을 마침내 복수 표준어로 인정하는 등 조금 완화된 분위기가 있긴 하지만, 한글 맞춤법이라는 표준의 존재 자체가 다른 표기안들을 찍어 누르는 경향이 있으니만큼 그 경향을 완화시키는 책임 또한 국립국어원에 있다고 생각한다. 당장 생각해 볼 수 있는 예로는, 한글 맞춤법에서 크게 비판받고 실제로 지키기도 어려운 규정들을 어느 정도 자율로 풀어서 세칙을 민간에게 맡기는 타협책이 있겠다. 띄어쓰기 같은 경우 아예 규정도 없으니 국립국어원이 자신들이 최종 권위로 유권해석을 하는데 이런 태도도 좀 줄여 줬으면 좋겠다.

반대로, 현행 맞춤법에 반대하는 사람이나 단체, 집단은 그만한 책임을 져야 한다고도 생각한다. 구체적으로, 어떠한 맞춤법이든 스타일 가이드든 최우선 원칙은 일관성이다. 규칙 안에서의 일관성 말고 일단 세워진 규칙이 일관되게 지켜져야 한다는 의미에서의 일관성 말이다. “띄어쓰기”(현행 표준)와 “띄어 쓰기”라는 두 표기가 있으면, 둘 중 하나를 선택해서 일관되게 표기하는 것은 괜찮다. 하지만 둘을 섞어 쓰는 것은 괜찮지 않다! 일관성을 위해서는 보통 그 선택을 명문화하는 과정이 필요할 것이니, Hixie가 그랬듯이 자신의 선택을 구체적으로 정하고 가능하면 다른 데서도 참고할 수 있도록 공개해 주면 참 좋지 않겠는가.3 궁극적으로 내 소망은, 국립국어원과 일부 국어학자들에 국한된 맞춤법 논의를 좀 더 다양한 집단이 독립적으로 할 수 있게 하여 국가 주도의 맞춤법에서 생기는 많은 문제들을 최대한 완화할 수 있었으면, 한다.

조선민주주의인민공화국 얘기다. 사실 이 낱말의 사용 자체가 프로파간다긴 하다(…). 조선이라는 체제에 대한 비판과는 별개로, 저 북녘 땅을 실효 지배하고 있는 집단이 스스로 주장하는 이름인 이상 도덕적으로 문제가 되지 않는 수준에서 인정은 해 줘야 하지 않겠느냐는 생각에서 되도록 이 약칭을 쓰려고 하고 있다. (도덕적인 문제가 있다고 판단되는 경우는 버마 같은 경우가 있겠다.) 설마 싶어서 부연하지만 이 명칭을 쓴다고 절대로 저 집단의 사상 등을 인정하는 것이 아니다. 당장 이 주석만 봐도 내가 “국가”라는 낱말을 안 쓰려고 얼마나 노력했는지 보이지 않는가. ↩︎

아주 엄밀히 말하면 맞춤법 조항 자체에는 사전에 대한 언급이 없다. 하지만 맞춤법의 한 부분인 외래어 표기법 또한 최종적으로 국립국어원의 유권해석을 따르는 이상, 맞춤법의 낱말의 정의 또한 국립국어원의 해석에 따른다고 보아 국립국어원이 편찬하는 사전을 기준으로 삼는 것이다. 사실 다른 사전이 있으면 그거라도 써 보겠는데 요즘은 다른 사전들이 다 멸망했지 ↩︎

꼭 소프트웨어에만 붙어 있는 건 아니지만(웹 2.0이나 정부 3.0 같은 것도 있으니), 어지간한 소프트웨어에는 버전 번호가 붙어 있게 마련이다. 버전 번호의 필요성은 거의 모든 소프트웨어는 한 번 만들어지고 나서 어떤 식으로든 바뀐다는 사실에서 출발한다. 바뀌기 전의 소프트웨어를 쓰던 사람이 이게 어느 시점의 소프트웨어이고 무엇이 바뀌었는지 알려면 그 사실을 간단한 형태로 알려 주는… 그래, 버전 번호 같은 것이 있으면 좋지 않겠는가?

버전 번호는 소프트웨어 개발자가 사용자에게 알려 주는 중요한 정보이기 때문에 함부로 정할 것이 아니다. (자기 자신만 쓴다면 상관이 없겠지만…) 역사와 전통 덕분에 버전 번호를 정하는 체계가 한 두 가지가 아닌데, 여러 가지 특징과 장단점을 가지고 있어서 이걸 정하는 것도 일이다. 그러하니 여기에서는 중요한 체계들을 살펴 보면서, 어떻게 쓰이고 어떤 함의가 있는지를 알아 보기로 한다. 중요한 체계가 너무 많다고? 하하하, 저널 하루 놓쳤으니까 이만큼은 써야죠(…).

작년에 Awesome Unicode라는 유니코드에 대한 이런 저런 사실들을 모아 놓은 저장소를 본 적이 있는데, 한글 채움 문자 얘기가 있는데 왜 공백인지 잘 모르겠다고 쓰여 있어서 옛날에 레딧에 올렸던 내용과 함께 내친 김에 한중일(CJK) 관련된 것들을 생각나는 대로 왕창 써서 올린 적이 있다. 그러고 나서 잊어 버리고 있었는데, 몇 달 뒤에 아는 분께서 저 글에 미묘한 오류가 있다면서 알려 주시길래 깜짝 놀란 적이 있다(“아니 저 이슈를 어디서 보셨길래?”).

사실 유니코드는 당연히 서양에서 개발이 시작되었고, 서양의 많은 문자들은 결국 페니키아 문자에서 출발하여 분화된 것이므로 알파벳에서 멀어지는 문자일 수록 유니코드에 매끈하게 통합되기 어려웠던 건 사실이다. 설계 과정에서 한중일 문자가 고려가 되지 않은 건 아니지만 (오히려 한자의 존재 자체가 유니코드 제정의 동력이 되었다는 얘기도 있다) 워낙 이질적인 구조다 보니 삐끗난 부분이 여럿 있는데, 그 때문에 지금까지 남아 있는 이상한 것들이 여럿 있다. 그리하여, 예전에 써 놓았던 글을 피드백을 반영해서 재작성에 가까운 번역을 해 보기로 한다. 내용 자체는 한중일 문자에 대해 잘 모르는 외국인을 위해 쓴 것이므로 이미 잘 알고 있는 내용이 있어도 그러려니 하시길… 대괄호 안에 있는 내용은 원문의 맥락이 부족해서 추가했거나 나중에 가필/수정한 부분.

한글 채움 문자

한글 채움 문자(U+3164 HANGUL FILLER)는 문자 집합이 선택할 수 있는 가장 멍청한 선택이라 할 수 있다. 한글은 간단한 알고리즘으로 조립되는 문자이기에 한글 문자 집합도 이상적으로는 그렇게 구성되어야 하겠으나, 기존에 널리 쓰이던 멀티바이트 인코딩들(ISO 2022, EUC)은 모두 94 × 94 = 8836자라는 상대적으로 작은 문자 집합1만을 사용할 수 있었고, 이는 현대 한글 음절 19 × 21 × 28 = 11172에 비해 훨씬 부족했다.

따라서 KS X 1001 문자 집합은 2350자의 자주 쓰이는 한글 음절(이랑 다른 이유로 유니코드에서 말썽이 된, 중복을 포함하는 한자 4888자)만을 포함하게 되었다. 다른 한글 음절이 지원되지 않는다는 점은 차치하고라도, 이 설계 때문에 한글을 지원하는 모든 소프트웨어의 복잡도가 늘어나 버렸고 유니코드 이전에 존재하던 또 다른 “조합형” 인코딩과의 충돌 및 논란이 있어 왔다. 표준화 기구는 나중에 설계가 부족했음을 인정했으나, 그 대안이라는 것이 문자 4개의 조합, 즉 8바이트의 열로 남아 있는 음절들을 임시로 표현할 수 있게 한다는 것이었다! 한글 채움 문자는 이런 조합을 표시하는 문자로, 이를테면 ㄱㅏ은 가를 나타내고 ㅂㅞㄺ은 KS X 1001에 포함되지 않은 뷁을 나타내는 식이다.

한글 채움 문자는 너무 늦게 추가되었기 때문에 소프트웨어 업계에서 사실상 외면받았다. 하지만 한글 채움 문자가 KS X 1001에 포함되어 있는 이상 유니코드에도 추가되어야 했고, 유니코드에는 한글 조합에 대한 표준이 존재하지 않지만 어쨌든 문자의 일부로 쓰일 수 있으니까 문자처럼 취급되어야 했다. [그래서 분명히 보이지 않는 문자임에도 불구하고 문자나 더 나아가 식별자의 일부로 쓰일 수 있게 된 것이다.] 이러어언.

한중일 통합 한자

시작하기에 앞서, 사실 “한중일” 통합 한자(Unified CJK Ideograph2)에는 베트남이 과거에 사용했던 쯔놈도 들어 있다는 걸 알아 두자. 물론 이제 이 이름은 고칠 수 없다.

한자 통합(Han unification)은 역사적으로 동일하게 취급되던 살짝 살짝 다른 이체자들을 하나의 한자로 합쳐서 인코딩하는 거대한 작업이었다. 문제는 역사적으로 동일하다고 실제 사용이 동일한 건 아니었다는 점인데, 이를테면 특정한 고유명사는 항상 똑같은 한자로만 쓰이는 경우가 있다. 확인해 보진 않았지만, 내 생각에 이건 기본다국어평면(BMP)의 제한된 크기와 관련되어 있지 않나 싶은데, 이런 한자들은 유니코드가 16비트로 제한되던 시절 초기에 추가되었기 때문이다. 물론 다양한 예외도 존재하는데 보통 한자가 유래한 문자 집합에서 통합이 되어 있지 않은 경우가 대부분이며, 원래 통합되었던 문자들이 나중에 쪼개지는 경우도 있다. 이체자 선택자(variation selector)와 한자 이체자 데이터베이스(IVD)가 이 오래된 문제를 마침내 제대로 해결할 거라고 다들 믿는데, 이들을 지원하는 글꼴과 소프트웨어 모두 아직 충분히 널리 쓰이고 있진 않다.

완전히 같은 모양의 한자가 여럿 인코딩된 경우도 있는데, 여러 종류로 나눌 수 있다. 일단 Big5에서 실수로 합치지 않은 U+FA0C랑 U+FA0D 같이 쌩 버그인 경우가 있고, 앞에서 언급되었던 KS X 1001의 경우 독음만 다른 같은 문자가 수백자나 인코딩되어 있는데 실제로는 신뢰할 수 없는 정보가 되어 버린 사례같이 그냥 멍청한 경우도 있으며, 물론 강희자전의 한자 부수도 중복이다.

아예 그 원전을 알 수 없는 한자가 등록된 경우도 있다. 가장 유명한 것으로는 JIS X 0208에서 유래한 문자들이 있는데, 그 중에서도 彁는 원전도 원전이 어떤 오류로 그렇게 인코딩된 건지도 알 수 없다는 점에서 두 배로 알 수 없는 경우이다.

[실은 한자 말고 한글에도 버그가 좀 들어 있다고 알려져 있다. 정확히는 옛한글 낱자의 문제인데, 옛한글 겹낱자 중에 옛이응이 들어가야 할 것이 이응이 들어 있다거나(초기 한글에서 그냥 이응은 음가가 없기 때문에 {2017-01-16 빠진 낱말 추가:} 종성 겹낱자의 일부로 들어와서는 안 된다), ㆅ(U+3185)의 오자로 보이는 ꥼ(U+A97C)가 문헌 출처도 없이 버젓이 들어 있는 것 같다거나… 현대 한글과는 달리 옛한글은 절대적으로 문헌 발굴에 의지하기 때문에 생길 수 있는 문제들이다.]

호환 기호

[한중일 문자 집합이 가져다 준 것은 다양한 보통 문자 말고도] 호환 기호들이 많이 있는데, 이들은 한중일에서 많이 쓰이는 네모나게 여러 문자를 뭉친 기호들(이를테면 U+3392는 “MHz”를 한 문자로 표시한다)에서 유래한 것으로 트윗을 최적화하는데 매우 매우 유용하다. 물론 실수도 있는데, 이를테면 Ken Lunde3가 설명하길 오타 때문에 네모나게 뭉친 기호가 실제로 사용되는 어떤 단위나 약자에도 대응되지 않게 된 경우가 있다고 한다.

아 물론 에모지도 일본에서 온 것이다. 이게 다 일본의 통신 삼사 때문이니 그 쪽을 탓하라.

[에모지에 대해서는 옛날에 긴 글을 쓴 적이 있으니 이 쪽을 참고. 6.0 이후에도 에모지는 크고 작은 사건을 일으켜 왔는데 최근의 사례를 하나만 들면 애플이 비난에 못 이겨 총을 나타내는 에모지를 장난감 물총(…)으로 바꾼 사례 따위가 있다. 그러니까 이런 거 넣지 말라고.]

정규화 문제

심지어 유니코드 정규화가 제대로 동작하지 않는 사례도 있다. 유니코드에서 한글 음절은 두 개의 정규화된 형식이 있는데, 하나는 완전히 합쳐진 형태(예: U+AC00 가)이고 하나는 완전히 풀린 형태(예: U+1100 ㄱ + U+1161 ㅏ)이다. 정규화 후 이들은 똑같이 취급되어야 하는데, 이 정규화 알고리즘에는 완전히 합쳐지는 게 불가능한 옛한글과 관련해서 중요한 오류가 있다. (예: U+1103 U+1172 U+11F0 듀ᇰ은 종성 때문에 옛한글로 분류되는데, 정규화 뒤 첫 두 낱자가 U+B4C0 듀로 합쳐지면서 두 개의 글자로 쪼개진다.) 유니코드 알고리즘을 더 이상 고칠 수는 없으므로, 결국 한국에서 쓸 목적으로 한글을 제대로 처리하는 정규화 알고리즘(KS X 1026-1)이 따로 나와 버리고 말았다.

유니코드 2.0 이전의 한글

이 사건은 워낙에 유명해서 "Korean mess"라는 용어가 따로 있을 정도이다. 한글은 유니코드 역사를 통틀어 통째로 움직여 다닌 유일한 문자일 것이다.4 유니코드 2.0 이전에 한글은 조합되는 형태로 인코딩되지 않았고, U+3400..4DFF 영역에 할당되어 있었다. 현대 한글이 종국에는 아무 의미 있는 순서 없이 유니코드에 통째로 인코딩될 때가 올 거라는 것이 시간이 갈수록 분명해지자, 긴 토론 끝에 한글은 U+AC00..D7FF로 옮겨 갔고 순서도 규칙적으로 바뀌었다. 이 때문에 현재의 한중일 한자 블록이 기존 한글 블록 바로 뒤인 U+4E00에서 시작하는 것이다. (자세한 사항. 여러 참석자들에 따르면 이 전체 과정은 거의 박빙이었고 개판 일보 전이었다 카더라.)

[이 부분에 대해서는 조금 더 설명할 필요가 있겠다. 요전에 신정식 씨가 한글의 11172자 인코딩 자체가 불합리하게 이루어졌다는 주장을 한 적이 있어서 개인적으로 이리 저리 찾아 본 적이 있는데, 실제로 어느 정도의 야바위(…)가 있던 건 사실로 보인다. 인터넷으로 접근할 수 있는 자료가 없어서 불명확한 부분도 많은데 내가 파악한 바를 간단히 요약하면, 유니코드 1.0의 한글은 KS X 1001이 존재한다는 이유만으로 사용자 피드백이 없이 대강 들어간 것이었고, 이 때문에 2.0 표준화 과정에서 한글을 재인코딩하려는 실 사용자측(국가가 아니다! 이 작업을 주도한 주체 중 하나는 다름 아닌 한컴이었다.)의 움직임이 있었는데 표준화 과정에 너무 늦게 들어 오는 바람에 국가들의 반대가 거셌던 것으로 보인다. (2017-01-07 추가: 문헌을 다시 읽어 봤는데 1.0 시절에도 움직임이 없진 않았던 것으로 확인.) (2017-01-16 추가: 정확한 문헌을 묻는 분이 계셔서 첨언하면, 강태진 저 《세상은 꿈꾸는 자의 것이다》 등을 참고하였다. 인터넷 상에 떠돌아다니는 텍스트가 있다…) 그래서 뭔 짓을 했냐 하면 반대파 대표에게 식사를 사 주기도 하고 미국이 중재안을 만들어 오자 아예 비토해 버렸다는 듯… 최종적으로는 한자와는 달리 한글은 현대 한글이 완전히 할당되면 추가 할당이 없을 것이라는 논리가 어떻게든 받아들여져서 통과되었다고 하는데, 과연 어떻게 보면 떼 써서 자기 원하는 바를 관철해 낸 나쁜 선례처럼 보이기도 한다. 다만 기술적인 참작 여지가 어느 정도 있고(유니코드 구현자 입장에서는 확실히 규칙적인 쪽이 편하다), 유니코드에서 허구한 날 싸우는 건 이 때에 국한된 일이 아니긴 하므로 개인적으로는 그냥 초창기 유니코드의 혼돈·파괴·망ㄱ…를 보여 주는 예시로만 보는 것이 옳지 않나 싶다.]

기술적으로는 3바이트 인코딩을 써서 94 × 94 × 94 = 830584자를 사용할 수도 있었다. 하지만 내가 아는 한 이러한 인코딩을 요구하는 문자 집합이 실제로 설계된 적은 없으며, 따라서 실제로 쓸 수 있는 구현도 없다고 볼 수 있다. ↩︎

[원문에서는 언급하지 않았지만 사실 한자는 한 문자가 (어떤 기준에서든) 낱말을 나타내는 표어문자(logogram)이지 완벽히 뜻만을 나타내는 표의문자(ideograph)가 아니기 때문에 이 영문 표기조차 틀렸다. 한자에는 오로지 문법적으로만 사용되는 문자도 들어 있기 때문이다. 근데 물론 이것도 바꾸기에는 늦었다.] ↩︎

[어도비에서 유니코드 표준화 과정에 오랫동안 참여해 온 유니코드 전문가. 만약 유니코드에 관심이 많다면 이 분의 블로그는 필독할 것.] ↩︎

  메아리를 비롯해서 이런 저런 사이트들이 호스팅되고 있는 루리넷 “오카리나” 서버를 마침내 집으로 옮겼다. 지난 몇 년간 서버를 운영해 왔는데, 옛날에는 웹 서버 등으로 많이 사용되었지만 이제는 쓰는 사람만 쓰는 셸 서버에 더 가깝게 운영되다 보니 굳이 비싼 돈 주고 IDC에 넣을 필요가 없어졌다. 특히 다른 사람의 간섭이 적은 주거를 찾으면서 이제 그냥 집에 옮겨야지… 옮겨야지 한 게 1년이 지나 버렸는데, 마침내 정산을 마치고 집에 제반 장비(주로 UPS)를 갖춰서 대강 정리를 마친 게 방금 전의 일. 나는 곱게 서버만 옮기지 왜 배포판 업데이트를 한다고 또 한바탕 난리를 쳤을까?

당연한 얘기긴 한데 집에서 서버를 돌리는 건 여러 가지 장애가 있고, 서버 자체에게도 그 정도로 좋은 환경은 아니다. 온도와 습도 조절이 잘 안 되는 건 물론이고 정전이나 네트워크 장애 같은 것도 IDC보다야 흔한 일이다. 실은 그래서 현재 루리넷은 집으로 옮겨 온 오카리나 서버와는 별개로 고가용성을 목적으로 AWS에서 돌아가는 작은 서버가 따로 있다. 그럼에도 불구하고 서버를 옮기게 된 건 이런 저런 조건이 맞아 떨어졌기 때문이다. 집에 서버를 들여 놓을 생각이 있는 분께는 참고가 될지도?

집에서 서버를 돌릴 때 가장 큰 비용은 전기료인데, 누진제의 혜택(?)을 가장 많이 받는 1인 가구라 돈 별로 안 내도 된다. 예상되는 추가 비용이 많아야 2만원.

집에 이사를 올 때 서버를 돌릴 가능성도 상정하고 약간의 추가 비용(이래봤자 만원 정도)으로 가정집에서 경제적으로 들일 수 있는 나쁘지 않은 회선을 들여 왔다. 그래서 회선 부분에서는 추가 비용이 없다.

의도하진 않았지만 현 서버를 맞출 때 미니 데스크탑으로 맞췄고 구성 요소도 그다지 유별나게 가동 환경을 따지지 않기 때문에, 가정에서 돌린다고 수명이 급격히 줄어들진 않을 거라는 확신이 있었다. 1U 서버였다면 어려웠겠지.

여름과 겨울을 나고 보니 집이 생각보다 외부 온도에 민감하진 않은 것으로 드러났다. 습도도 세탁을 하는 게 아니면 집 자체는 큰 문제가 없었다. 장기적으로는 먼지가 문제가 될 수는 있는데, 그래서 쑤셔 박은 장소가 사진에서 보이듯 외부와 가장 격리된 옷장 아랫쪽인 것이다.

거진 십수년 간의 공동 생활을 통해 일정 이하의 소음이 수면 패턴에 전혀 영향을 미치지 않는다는 점을 확인했다(…). 물론 아예 신경이 쓰이지 않는 건 아니므로 격리된 장소에 쑤셔 박아 놓았지만. 참고로 원래 갖고 있던 데스크탑이 저 서버보다 더 시끄럽다(왜??).

누누히 얘기가 나오는 거지만 메아리는 거의 모든 부분이 정적으로 구성되어 있어서 요즘 하루가 멀다 하고 나오는 정적 웹사이트 생성기를 쓰기에 적절한 구조로 되어 있다. 적어도 이론상으로는. 실제로는 뭐 보다시피 저널은 아무래도 야짤 플랫폼으로만 생명력을 유지하고 있는 듯한 텀블러고(…) 오래 전에 멸망한 풉;은 도쿠위키(의 상당히 오래된 버전)이며 뇌는 무려 ikiwiki이다. 몇 년 전부터 몇 차례 새로운 디자인을 시도하고는 있는데 몇 가지 이유로 잘 안 되고 있다. 그래서 오늘은 도대체 뭐가 문제이며, 내가 생각하는 이상적인 설계가 뭔지를 써 놓아 보고 잊어버리려고 한다.

정적 웹사이트 생성기의 얼개

보통의 정적 웹사이트 생성기는 이런 식으로 구성되어 있다.

사이트의 구조를 어떤 방법으로든 얻어 낸다. 보통 이 부분이 가장 변화무쌍하며, 사람들의 취향에 따라 다양한 접근이 있다. “정적” 웹사이트 생성기라고 해서 이 부분에 꼭 디비를 안 쓸 필요는 없다는 것도 주목.

텍스트를 적절한 마크업을 써서 HTML로 변환한다. 요즘은 거진 다 마크다운이지만 꼭 그럴 필요까지는 없다.

미리 지정된 HTML 템플릿에 지정한 텍스트와 메타데이터를 쑤셔 넣는다. 물론 템플릿 언어에 따라 모든 것이 갈린다.

위 과정을 소스 파일이 바뀔 때마다 적절한 방법으로 점진적으로 갱신한다. 예를 들어서 블로그 스타일이라면 y년 m월 d일에 쓰여진 글이 고쳐질 때 y년 m월 아카이브와 그 앞뒷글도 함께 갱신하는 식.

웃긴 것은 현존하는 어지간한 웹사이트 생성기들은 네 가지 점 모두 내 필요를 충족하지 못 한다는 점이다.

대부분의 정적 웹사이트 생성기는 블로그 스타일 또는 완벽한 평면적 웹사이트에 최적화되어 있다. 따라서 조금만 구조가 복잡해져도 그대로 쓸 수 없거나 상당히 불편해진다. 그런데 메아리는 블로그, 위키, 자동 리스트, 메타 페이지 따위가 어지럽게 뒤섞인 상당히 실험적인 웹사이트 포맷이란 말이다(…). Lektor가 나왔을 때 개인적으로 기대했던 것은 바로 이거였는데, 소스 코드를 뜯어 보니 여전히 이 쪽도 그다지 확장성은 없었다.

마크다운은 훌륭한 경량 마크업 언어긴 하지만 아주 옛날에 지적했듯 확장성이 심하게 떨어진다. 단적으로, 현재의 메아리 풉;에 해당할 부분에서는 위키 링크가 없으면 많이 곤란한데 마크다운에는 그 따위 거 없다. 그래서 neu.mearie.org 실험을 할 적에 Pandoc 후처리 필터까지 만들어가면서 위키 링크를 구현해 보았는데 못 해 먹겠더라. 최근에는 Pandoc을 그대로 쓸 수 없다는 판단 하에 다른 CommonMark 라이브러리들을 가지고 좀 실험해 보고 있다. (눈물이 난다…) Asciidoctor를 쓰면 어떻겠느냐는 얘기도 여기 저기서 나오고 있는데, 마크다운으로 쓰여진 텍스트가 수천페이지이고1 요구사항이 기괴해서 어차피 그대로 쓸 수는 없을 거라는 점은 동일할 듯. reST도 옛날에 심각하게 고민해 보았다(지금까지 나온 것 중에서는 그나마 확장성이 가장 높다).

현재의 메아리는 Mako 기반의 템플릿을 쓰고 있다. 이게 왜 문제인지 모르다면… Mako는 일반적인 템플릿 언어보다 훨씬 파이썬에 가깝다는 점을 상기하자.

1번과 연결되는데, 메아리의 전체적인 구조 때문에 단순한 의존성 그래프가 나오지 않는다. 이를테면 위키라면 해당 위키 문서를 링크하는 모든 문서에 의존성이 걸린다(해당 위키 문서가 사라지면 빨간 줄을 그어 줘야 하니까!).

그 밖에도 몇 차례의 실험 끝에 Travis 등을 사용해서 완전 자동화하겠다는 구상이 꼬여버린 점도 있다. 이 점에서는 Lektor에 배울 것이 많은데, Lektor가 제시하는 모델은 로컬에서는 텍스트 편집기를 써도 되고 좀 더 자동화된 웹 인터페이스를 써도 되지만 최종적으로는 정적 HTML이 생성되어서 배치(deploy)된다는 것이다. 어지간한 정적 웹사이트 생성기가 watch 모드(파일 변경을 모니터링하다가 바뀌면 바로 재빌드하는 모드)를 지원하긴 하지만 실시간 확인에는 미치지 못 한다는 점을 생각하면 장점만 취합한 것이다. 사실 원래 목표는 Travis로 자동화하고 편집을 깃헙에서 바로 하는 거였지…

무엇이 필요한가

위의 요구사항에서 추론되는, 새로운 정적 웹사이트 생성기의 구성 요소는 세 개로 정리된다.

동적 의존성 추적 엔진

1에 적합한 형태로 의존성 정보를 읽고 쓰는 확장 가능한 마크업 언어 구현

1에 적합한 형태로 의존성 정보를 읽고 쓰는 최종 템플릿 엔진

1이 매우 중요한 구성 요소라는 걸 깨닫는 데는 기나긴 삽질이 필요했다. 사실 아주 먼 옛날에 파이썬 기반 웹 애플리케이션 형태로 만들려고 했을 때도, 현재의 메아리를 구성하는 Makefile도, 그리고 neu.mearie.org에서 사용하고 있는 미친 크기의 Makefile도 모두 다 의존성 추적에서 상당한 삽질을 하고 있었는데 그걸 이제야 알았나 싶다. 1에 비해 2와 3은 상대적으로 마이너한 부분으로, 정 안 되겠으면 대강 만들어서 넘겨도 되는 수준이다! 그보다는 옛날에 삽질을 하도 많이 했기 때문에 더 할 여력이 없는 것이다

그럼 의존성 추적에서 널리 쓰이는 Make를 못 쓰는 이유가 뭐냐고 반문할 수 있겠는데, “동적”이라는 낱말이 중요하다. 예를 들어서 A.md라는 소스 파일에서 마크업 변환으로 A.content.html이 나온 뒤 템플릿 journal.tmpl.html과 합쳐져 최종 웹페이지 A.html이 되고, 중간에 삽입된 alpha.png 파일은 자동으로 썸네일이 생성되어 alpha.thumb.png와 함께 배치된다고 하자. 이러한 의존성 정보는 A.md를 파싱하기 전까지는 아무 것도 알 수 없다. 위에 링크한 Makefile에서는 다양한 꼼수를 사용해서 이를 어떻게 둘러 가고 있는데, 결국 Makefile은 대부분의 규칙이 미리 알려져 있는 의존성 그래프에서 위상정렬하는 걸 기반으로 하기 때문에 깊이가 조금만 깊어져도 규칙을 관리할 수 없다. Make 대신에 몇 가지 대안을 찾아 보았고, 특히 tup를 꽤 깊이 살펴 봤는데, 결국 의존성 정보를 실시간으로 수정하는 건 가능하지 않아서 (다른 점에서는 결격 사유가 거의 없었으나) 포기했다.

재밌는 점은, 사실 이러한 동적 의존성 추적 엔진은 제대로만 만들어지면 Make 같은 전통적인 정적 의존성 추적 엔진을 대체할 가능성이 있다는 점이다. 당장 동적인 규칙을 만들기 위한 Makefile 꼼수는 다름이 아니라 C/C++ 컴파일 규칙을 만드는 과정에서 나온 것이다.2 그래서 현재 방향은 1을 제대로 만들어 보는 것으로 선회한 상태. 혹시 이런 요건을 만족하는 라이브러리나 애플리케이션이 있다면 제발, 제발 연락해 주시라.

Asciidoctor가 마크다운 호환성이 있다고 주장하는 건 개뻥이니 믿지 말자. Asciidoctor의 마크다운 호환성은 인라인 문법 몇 개 가지고 주장하는 거다(…). 당장 리스트 문법부터 호환이 되지 않는다. ↩︎

여기에서 굳이 이야기를 꺼내진 않지만 요즘은 박근혜-최순실 게이트 덕분에 JTBC가 흥하고 있는데, 그래서 텔레비전이 없는 나도 JTBC 뉴스룸을 자주 챙겨 본다. 마침 어제 정유라가 덴마크에서 잡혔고 그 과정을 보여 준다길래 생방은 아니지만 뒤늦게 뉴스룸을 보다가 내 눈을 의심하게 하는 장면을 보게 되었는데, 아니 글쎄 군데 군데 잡히는 정유라 여권의 기계 판독 영역(MRZ)이 전부 다는 아니지만 일부 가려지지 않고 표시되어 있더라… (그것도 한 화면에서 안 나온다는 얘기지 다 합쳐 놓으면 MRZ를 복구하는 건 어렵지 않다!) 기계 판독 영역에는 생년월일, 국적, 성별, (대한민국 국민이라면) 주민등록번호, 여권 유효일 같은 게 거의 대놓고 들어가 있기 때문에 사실상 주민등록증을 까 놓는 수준의 파급력이 있다. 일부 영상에서는 완전히 가려져 있는 걸로 봐서 바쁘게 편집하다가 미처 눈치를 못 챈 거 아닌가 싶은데, 설마하니 정유라의 개인 정보를 공공재화하려는 게 아닌 이상 조금 더 조심할 필요가 있지 않나 싶다.

꼭 이런 사례 뿐만은 아니어도, 정보화 사회(웃음)에서 개개인은 엄청난 양의 정보를 알게 모르게 뿌리고 다닌다. 개중에는 이를테면 신용 정보 같이, 원래는 노출될 것이 아니었음에도 사고 또는 무관심으로 노출되는 것도 많지만, 개중에는 자기 자신이 의식하여 정보를 노출하는 경우도 심심찮게 보인다. 정보를 수집하여 가공하는 것을 흔히 광산에서 광물을 캐내는 것에 비유해 데이터 마이닝(data mining)이라 한다. 나는 어떤 사람을 처음 봤을 때 그 사람이 그동안 뿌리고 다닌 정보를 문제가 되지 않을 범위에서1 이리 저리 찾아 보는 수동(…) 데이터 마이닝을 종종 해 보는데, 그 결과는 참 볼만하다. 더 볼만한 것은, 가끔씩 이렇게 스스로 노출시켜 놓은 정보가 다른 방법으로 사용되어 문제가 되는 사례가 여기 저기에서 보이는데(얼마나 많은지 네티즌 수사대라는 여러 의미에서 위험한 신조어가 있지 않은가), 그렇게 문제가 되어 놓고도 정보의 셀프 노출에 대해서는 문제를 삼지 않는 사람들이 태반이라는 점이다.

당연한 소리를 하나 첨언하면, 사실 현대 사회에서 정보를 아예 안 뿌리고 다닐 수 있는 방법은 없다. 당장 선술했던 데이터 마이닝의 주된 사용처도 개개인이 인식하지 못 하는데 전체를 모아 놓으면 파악할 수 있는 통찰을 얻고자 하는 것인데, 어떻게 개개인이 전체를 보지도 않고 통찰에 영향을 주는 그런 시그널을 잡을 수 있겠느냔 말이다. 여기에서는 그런 비현실적인 얘기를 하려는 게 아니다. 오히려, “무슨” 정보가 “어떻게” 뿌려지고 있으며 “누가” 그 정보에 접근할 수 있는지 파악하는 감각을 기르는 것이 중요하다고 생각한다. 몇 가지 예시를 들어 보자.

이름은 얼마나 많은 사람들이 알고 있을까? 이름은 원래 다른 사람이 부르라고 만들어진 것이니만큼 숨기고 싶어도 숨기기 어렵다. 내가 아는 어떤 한 사람은 총력을 다해서 자기 본명을 숨기고 다녔는데, 물론 그도 자기 이름이 그렇게 쉽게 숨길 수 있는 건 아니라는 걸 알고 있었지만(그래서 어디까지나 공개되어 있는 쪽에 협조해 달라는 수준이었다), 나는 그 얘기를 들었을 때 어렵지 않게 두 세 다리 건너 본명을 가리키는 웹 문서를 찾아내서 보여 줄 수 있었다(…). 상황이 이러하니, 원래 이름을 숨기고자 할 때는 그 이름과 최대한 연결을 짓지 않는 방향으로 별명을 사용해야 할 것이다. 특히 본명으로부터 유래한 이름은 의도하고 쓰는 것(본명이 복잡하다거나 하는 이유 등)이 아니면 최대한 피해야 한다.

나이나 성별, 직업은 얼마나 많은 사람들이 알고 있을까? 이것 또한 일반적으로 숨기기 어려운 종류의 정보인데, 평소의 언행과 이런 정보 사이의 상관 관계가 높기 때문에 충분히 오랫동안 관측하면 꽤 높은 정확도로 알아 낼 수 있다. 한 가지 안타까운 점은 이렇게 알기 쉬운 정보를 가지고 차별을 하는 문화가 여전히 널리 퍼져 있다는 점이다. 이런 것들을 숨기려면 오랫동안 관측될 수 없는 환경, 즉 명의를 오랫동안 쓰는 걸 피하는 생활을 하는 수 밖에 없는데 가능은 하지만 쉽지 않다.

주소는 얼마나 많은 사람들이 알고 있을까? 여기서부터는 자기가 대놓고 말하지 않으면 일정 정확도 이상으로 알기 어려운 것들이 나오기 시작한다. 상술한 방법론에서 예를 들어서 어느 나라에 사는지(평소 활동하는 시간대로부터 잠자는 시간대를 추론할 수 있다), 어느 지역에 사는지 정도는 알 수 있으나, 번지 단위의 세부 주소는 어지간히 대놓고 정보를 뿌리지 않으면 일반적으로는 얻기 매우 어렵다. 문제는 자기가 정보를 뿌리고 있다는 것을 인식하지 못 한 채 뿌려 버리는 것(…). 택배 운송장이라거나, 집 근처 또는 집 앞에서 찍은 사진, 해당 집에서만 찍을 수 있는 종류의 사진, 특정 시점에서 특정 위치에서만 일어난 사건 등이 주소를 노출시킬 수 있는 대표적인 예이다.

전화번호는 얼마나 많은 사람들이 알고 있을까? 기술적으로는 전화번호는 주소 정도로 알기 어려워야 정상이다. 주소든 전화번호든 장기적으로 아는 사람들은 지인들에 한정되고 단기적으로는 믿을만한2 기업들로 한정된다고 생각할 수 있으니까. 헌데 안타깝게도 전화번호는 주소보다 훨씬 잘 공유되는 게 일반적인데, 여러 요인이 있지만 i) 더 짧으니까 노출이 잘 되고 ii) 전화번호를 고유 키 삼는 데이터베이스가 하도 많아서 그 데이터베이스가 털리면 끝장이 나는데다 iii) 사업 관계나 학교 내 소그룹 같이 단기적으로 유지될 개인 관계가 크게 늘었기 때문이 아닌가 싶다.

한때 공공재 취급을 받았던 주민등록번호 같은 것은 시대가 마침내 변하여 그 정도로 노출이 심해지진 않게 되었다. (물론 이미 노출된 사람들의 주민등록번호가 다시 숨겨지는 건 아니다…) 여기에는 주민등록번호가 필수적으로 필요하지 않은 기업이 주민등록번호를 받지 못 하게 강제한 것이 크게 작용했는데, 앞에서 전화번호가 얼마나 그리고 왜 많이 노출되는지와 비교해 보면 시사하는 바가 크다.

이런 식으로 감을 잡으면 반대 방향으로 어떤 정보를 노출시킬 지 선택할 수 있게 된다. 예를 들어 집들이를 한다고 하면 적지 않은 사람들에게 주소를 공개해야 하는데, 이것은 필요한 것인가? 필요한 것이라고 판단했다면 그럼 정확히 그 사람들에게만 전달될 수 있도록 개별적으로 정보를 전달하거나, 세부 주소를 식별하긴 어렵지만 적절히 걸어서 집에 도달할 수 있는 장소에 결집을 시키는 걸 생각할 수 있다. 그리고 개인적으로는 이렇게 하였음에도 다른 사람들에 의해 (특히 인스타그램 같은 것들을 통해) 주소가 식별되는 위험성이 있을 수 있다. 위험성을 얼마나 묵인할 수 있는지에 따라서 접근이 달라진다(아예 믿을만한 사람들끼리만 집들이를 하고 싶을 수도 있겠다). 짐작한 분도 있겠지만 사실 이건 위협 모델링이라고 하는 매우 고전적이지만 매우 알려지지 않은 방법론을 그대로 가져 온 것이다. 보안이나, 개인 정보나, 문제를 인식하는 것이 최우선인 것이다.

일반적으로 용인되지 않는 방법으로 얻을 수 있는 정보 같은 걸 쓰지 않고, 검색 엔진 등을 사용해서 흔적들을 추적한다는 얘기. ↩︎