한글 인코딩에 관한 조합형완성형 논쟁은 유니코드에서 완성형과 조합형 모두를 수용하는 방식으로 종결되었지만, 한글 글꼴 구현에는 조합형 완성형 논쟁의 잔재가 아직까지도 남아 있고 글꼴을 갖다 써야 하는 곳에 따라서 과거의 조합형 글꼴을 아직도 써야 하는 경우가 생길 수도 있다. 당장 일부 한글 글꼴이 완성형 2350자 이외의 글자에 대한 글리프가 없어서 해당 글자를 입력하면 깨지는 것도 이 시기의 잔재이다. 디스플레이 화소 수가 적고 메모리 공간이 KB 대에서 노는 임베디드 환경이라면 조합형 글꼴(조합형 인코딩이 아님!)로 한글을 표시하는 게 유리할 수 있다. 한글 낱자가 들어오면 그것들을 나눗셈과 나머지 연산으로 자소 단위로 분해하고 수백개의 글리프 중 최대 3개를 OR 조합해서 표시하는 게 2350/11172자 모두의 글리프를 들고 있다가 표시하는 것보다 데이터 양은 더 적게 필요하다. 그 동안 도스 시절의 한글 바이오스나 컴퓨터 역사 초기의 한글 구현을 분석하면서 알게 되었던 각종 조합형 글꼴 구성을 이 글에서 정리하고자 한다.
8x4x4 조합형 글꼴
상당히 많은 곳에서 쓰이고 있는 조합형 글꼴 구성 방식이다. 원리는 지금도 잘 알려져 있고 명세를 구하는 것도 어렵지 않다(링크). 초성 8벌, 중성 4벌, 종성 4벌에 해당하는 글리프를 미리 만들어 두고 자모의 종류에 따라서 서로 다른 글리프를 사용한다. 8x4x4 조합형의 구현체는 많은 곳에서 찾을 수 있기 때문에 해당 조합 방식의 글꼴을 사용하는 곳과 추출하는 방법만을 여기에서 소개한다.
글꼴 통합 변환기(링크): 8x4x4 조합형 글꼴을 BDF나 TTF 형식으로 변환할 수 있다.
한글을 자유롭게 1.54(링크): 실행 파일 한 개로 구성된 한글 바이오스이다. 실행 파일 자체는 DIET 패커로 압축되어 있기 때문에 일단 압축을 풀어 주어야 비트맵을 추출할 수 있다. 글꼴은 한 종류만 들어가 있다.
한글 1.2, 1.5: 이 시기의 한글은 HFT 글꼴을 사용하지 않았고 프린터용 PFT와 화면용 SFT 글꼴을 사용했다. SFT 파일 형식은 헤더 32바이트만 잘라내면 나머지는 바이너리 비트맵이다.
태백한글 1.01, 1.5, 2.0, 3.0, 3.5: 글꼴은 전 버전 모두 FNT 확장자를 사용하며, 바이너리 비트맵이기 때문에 글꼴 통합 변환기에서 처리가 가능하다. 단 태백한글 3.0 이후의 24×24 등 16×16 초과 글꼴은 글꼴 통합 변환기로는 처리가 불가능하다.
미니 한글 라이브러리: 소스 코드의 FONT.C 파일에 8x4x4 비트맵이 하드코딩되어 있다.
HT: 실행 파일은 LZEXE로 압축되어 있다. 파일의 압축을 풀면 8x4x4 비트맵이 내장되어 있다.
8x4x4 조합형에서 초성 글리프가 두 벌 더 들어간 형태이다. 중성과 종성 조합 규칙은 8x4x4와 동일하나 초성 조합 규칙은 살짝 다르다. 글꼴 통합 변환기의 hanlib/Table8x4x4.c 파일과 hanlib/Table10x4x4.c 파일을 비교하면서 보면 이해할 수 있다. 아래에 있는 두 종류의 10x4x4 조합형 글꼴은 높이 문제 때문에 그대로 통합 변환기에 전달할 수는 없으며 적절하게 높이를 조정해 줘야 한다.
GSVIP(금성 한글 BIOS) 3.52: 글꼴은 GSF 확장자를 사용한다. 용량을 줄이기 위해서인지 16×16 글꼴임에도 불구하고 초성, 중성, 종성의 세로 높이는 각각 벌마다 일정하지 않다. 아래 그림은 의도적으로 16×16 사각형에 모든 벌을 출력하도록 설정했으나, 초성과 종성은 세로 출력 위치를 조정해 주어야 제대로 된 글자를 볼 수 있다.
HECON(대우통신 한글 BIOS) 4.00.20: HECON.EXE 파일에 내장된 글꼴도 이 쪽에 속하지만 역시 높이가 일정하지 않다. HE24.SYS 파일의 24×24 한글 글꼴은 12x2x4 조합을 사용한다.
GSVIP 한글 글꼴 예제
14x6x4 조합형 글꼴
아직까지 이 조합형을 사용하는 곳은 삼보컴퓨터 계열밖에 보지 못했다. 초성 벌 수가 상당히 많이 들어가 있다는 것이 특징이며, 중성은 x6이라고 쓰기는 했으나 일부 중성만 6벌이 들어가 있고 대부분 중성은 3벌만 들어가 있다. 아직까지 정확한 조합 방법을 찾지는 못했다. 특이하게 아래아가 중성 조합 중에 들어가 있다.
TGHP 1.20: HAN16.FNT와 HAN24.FNT에 각각 16×16, 24×24 글꼴이 들어가 있다. 24×24 글꼴은 초성 조합 벌 수가 13이나 12벌인 경우가 있다.
격리면제서가 날아가서 결국에는 자가격리는 불가피하게 되었지만, 한국행은 이미 오래 전부터 예정되어 있었기 때문에 비행기표는 그냥 있는 그대로 끊었다. 2021년 12월 현재 루프트한자는 프랑크푸르트/뮌헨발 서울행을 각각 4회/3회 굴리고 있고 이걸 합치면 독일발 한국행이 매일 뜨고는 있다. 그러나 나는 출발지가 어차피 베를린이기 때문에 환승을 하기는 해야 하고, 인천국제공항에 도착해서도 목적지가 부산인데다가 김해국제공항으로 직접 들어올 수가 없기 때문에 환승 여부는 크게 중요하지 않았다. 그렇지만 PCR 검사가 어떻게 되는지는 알 수가 없고 일정이 역시 어떻게 변경될지도 알 수 없기 때문에 예약 변경이 가능한 표를 끊기로 했다.
글을 쓰는 시점에서 루프트한자의 이코노미는 Basic/Basic Plus/Flex로 나뉜다. 셋 다 예약 변경 수수료는 없지만 차이는 환불 가능 여부에 있고, 나는 어차피 환불할 계획이 없기 때문에 이코노미 Basic을 그냥 끊었다. 게다가 무료 수하물에도 차이가 없기 때문에 굳이 예약 취소를 감안하고 티켓을 살 필요는 없었다.
아 물론 이 가격에 비행기 표를 끊었다는 거는 아님
문제는 독일에서 받아야 할 택배가 있었기 때문에 비행기 표를 좀 늦추었는데, 온라인으로 예약을 변경하려고 보니 불가능했다. 루프트한자 독일 콜센터는 참 악명이 높다는 말이 있었지만 그 동안에는 예약을 변경할 일이 없어서 가만히 있었는데, 이렇게 되고 보니 불가피했다. 콜센터 자체는 24시간 영업 중이긴 하지만 통화 성공률이 하늘의 별 따기라는 것을 이 기회에 느낄 수 있었다. 나만 하더라도 거의 5회 정도 기다린 끝에야 통화에 성공할 수 있었다. 독일 업무 시간 이외에 전화한다면 영어로 통화하는 게 성공 확률을 높여 주지 않을까 기대를 했는데, 뭐 성공하기는 했다. 문제는 그 통화라고 해도 거의 50분 가까이 대기를 하다가 연결이 되었다. 휴대폰 요금제에 통화 무제한이 끼어 있어서 다행이지, 아니었다면 꽤나 통화료가 나왔을 것이 예상되는 순간이었다.
루프트한자 잊지 않겠다
그리고 출발 2일 전에 PCR 검사를 예약했다. 베를린에서는 direkttesten.berlin 사이트에서 PCR 검사가 가능한 검사소 정보를 제공하고 있다. “Bietet bestätigende PCR Tests an” 옵션을 선택하면 PCR 검사소를 볼 수 있고, 지도에 표시된 핀을 클릭하면 검사소 정보를 볼 수 있다. 문제는 무료로 할 수 있는 신속항원검사(Bürgertest라고도 불림)와는 다르게 “여행” 목적의 PCR 검사는 가격 상한선이 없고, PCR 검사 속도와 검사소에 따라서 가격이 다르다. 내가 예약한 곳에서는 약 60유로에 당일 PCR 검사가 되었는데, 이 가격으로는 다른 검사소에서는 36시간 정도에 검사가 가능하다. 이 검사소에서는 가글로 시료를 채취하는데, 가글액이 가급적이면 목까지 닿아야 한다고 현장에서 안내를 받았다. 한국에서는 가급이나 면봉 둘 다를 인정하기 때문에 이 방식도 가능하다. 오전 11시에 시료를 채취했고, 검사 결과가 나온 것은 오후 11시 정도였다. 이제 이걸 혹시나 몰라서 미리 3부 정도 인쇄해 두었다. 한국에서 유효한 PCR 검사 결과로 인증(질병관리청 참고)하는 성명, 생년월일, 검사 방법, 검사 일자, 검사 결과, 발급 일자, 검사 기관명은 모두 나와 있었다.
없으면 비행기 입구컷 당함
베를린 공항에서는 접종 상태를 간단히 확인했고, 저 문서 확인은 뮌헨 공항에서 한국행 게이트 앞과 인천국제공항에서 제대로 했다. 뮌헨 공항에서는 한국행 게이트 앞에 별도의 인원을 배치하여 문서가 있는 사람들에게는 항공권에 별도의 스티커를 붙여 주고 있었다. 뮌헨발 서울행은 A350으로 운항하고 있는데 비행기의 1/3-1/2 정도만 차 있는 듯한 느낌이었다. 그래서 일부 사람들은 3열 시트를 전부 차지한 채로 누워 가는 경우도 있었다.
이 와중에 한국 입국에 필요한 건강상태 질문서에 평소 지병이었던 비염 때문에 기침이 있었다고 표시를 했으나, 이것 때문에 인천국제공항에서 유증상자 취급받아서(입국 당시에는 증상이 없었음) 입국도 나머지 사람들과는 따로 해야만 했다. 그리고 입국 심사를 금방 통과하지 못하고 인천국제공항에서 떨어져 있었던 국립검역소로 별도의 차량으로 이동하여 PCR 검사가 나오기까지 추가로 6시간을 대기해야 했다. 이렇게 표시했던 사람들 중에는 실제로 기침이 좀 심했던 사람도 있었고 PCR 검사 결과가 실제로 음성이었던 사람도 있었다. 약 절반은 무사히 풀려 나왔고 나머지 절반은 PCR 검사 결과가 미확정이었거나 다른 증상이 있어서였는지 풀려 나오지 못한 사람도 있었다. 이렇게 하는 이유가 이해는 갔지만 막상 당해 보니 “아 여기는 한국이었구나”라는 생각도 같이 들었다.
집으로 이동한 다음에는 원래로는 다음 날 보건소에 출석하여 검사를 받았어야 했지만, 이미 인천국제공항 검역소에서 PCR 음성이 나왔기 때문에 도착 후 검사는 생략할 수 있었다. 이제는 자가격리 10일이 지나야 다시 풀려나올 수 있다.
코로나19가 많은 것을 바꿔 놓긴 했지만, 가장 큰 것을 꼽아 보자면 역시 여행이 아닌가 싶다. 2020년에는 세계 대부분 공항의 이용객 수가 수직 낙하했고, 2021년에 와서는 슬슬 회복되어 가고는 있다. 나도 여기에서 예외는 아니었기 때문에 근 3년 동안 베를린 밖을 벗어났던 적은 손에 꼽을 정도이고, 한국에는 물건만 갈 수 있었지 내가 가는 것은 상상도 하기 어려웠다. 아, 코로나19로 인한 정신적인 피폐해짐은 여기에서 따로 언급하지 않겠다.
2020년 한 해 동안은 거의 묶여서 지내다가, 2021년부터 백신이 천천히 보급되기 시작했고 제1세계에 사는 사람이라면 아마 이 시점에서는 “자기가 맞기 싫어서” 안 맞은 경우를 제외하자면 어떻게든 코로나19 백신을 구했을 것이라고 본다. 그게 없었던 시기에는 한국에 입국하려면 자가격리가 강제되었기 때문에 가고 싶어도 엄두를 못 냈던 사람이 꽤 많았다고 기억한다. 나 또한 6월과 7월에 백신을 맞았기 때문에 언젠가는 한국에 들어갈 때 도움이 되겠지라고 생각하고 있었고, 적절한 시점에서 잠시 한국 방문을 계획할 수 있게 되었다.
한국 밖에서 예방 접종을 맞은 사람을 한국에서 어떻게 인정해 줘야 할 것인가가 2021년 중반에 나온 이후로 결국 예방 접종 인정 자체는 격리면제서의 형태로 2021년 8월부터 일부분은 가능하게 되었다. 그러나 한동안은 해외에서 예방 접종을 받는다고 하더라도 한국에서의 사회적 거리두기 규칙에서는 백신 미접종자와 거의 동일하게 취급했기 때문에, 내심 “아 이거 한국에 예방 접종 기록 등록하지 말고 4차까지 맞아 볼까”라는 생각을 하고 있었다. 그러나 이 문제도 어느 정도는 해결되어 가는 눈치였기 때문에 그 생각은 그만두고 격리면제서 발급이나 받자!로 마음을 바꿨다.
일단 항공권을 발권한 다음 시간적 여유가 있을 때 격리면제서를 받아 두기로 했다. 격리면제서의 유효 기한은 1개월이기 때문에 엄청나게 빨리 준비할 필요는 없으며, 코로나19로 인한 항공편 운행 상황을 알기 힘들기 때문에 적절한 시점에서 항공권을 발권했다. 요새는 비행편이 취소되거나 PCR 검사를 실패해서 비행기를 못 타는 경우도 있을 수 있기 때문에, 싸다고 취소나 여정 변경 불가 항공권을 끊기보다는 좀 돈이 더 들더라도 변경 가능한 항공권을 끊는 게 더 나을 수 있다. 여행자 보험이 있다고 하더라도.
준비해야 할 서류 자체는 재외공관마다 거의 동일하다. 독일에 있는 한국 재외공관이라면 주별로 관할이 나뉘어 있기 때문에 독일 내 주소를 증명할 수 있는 서류가 필요하다(Aufenthaltstitel 카드 뒷면 스캔으로 충분). 그리고 독일 기준으로는 Impfpass(개인 신상 정보면과 코로나19 접종 기록 필요), EU 디지털 인증서를 위한 QR 코드가 인쇄된 종이나 앱에 등록 후 캡처한 부분이 필요하다. 문제는 QR 코드나 앱 캡처 화면은 2/2만 있으면 되는 게 아니라 1/2, 2/2가 모두 나와 있어야 하고, 내 경우에는 독일에서 CovPass 앱이 시행되기 전에 모더나로 1차 접종을 맞았기 때문에 1차 접종을 증명하는 QR 코드가 따로 없었다. 그리고 1차 접종을 받았던 시점에서는 Impfpass를 잃어버려서 1차 접종은 Impfzentrum에서 나눠 준 별도의 종이에 백신 LOT 번호 스티커가 붙어 있었고, 나중에 받은 Impfpass 상에는 1차 접종이 사후에 옮겨서 기록된 걸로 나와 있었기 때문에 Impfpass뿐만 아니라 1차 접종 당시 접종 센터에서 나눠 준 종이까지 같이 스캔해서 첨부했다.
필요한 Impfpass 스캔본의 예시. 악용 내지 도용 방지를 위해서 불필요한 부분은 가림.
모든 문서를 스캔한 후 파일 하나로 만들어서 제출해야 했기 때문에 여기에서 삽질을 좀 했다. 가족관계증명서는 공동인증서 등 한국 인증서가 하나도 없기 때문에 집에 부탁해서 스캔본을 받았다. 나머지 모두는 복합기로 스캔한 다음 최종적으로 pdftk와 img2pdf를 사용하여 PDF로 이어붙였다. 뭐 여기가 pdftk나 img2pdf 사용 방법을 설명하는 곳은 아니므로 자세한 방법은 생략.
재외 공관이나 체재 지역마다 격리면제서 발급 담당 이메일 주소가 전부 다르기 때문에 자세한 사항은 각국 대사관 홈페이지를 참조해야 한다.
신청한 후 며칠 지나서 이메일로 격리면제서가 도착했으며, 이제 이걸 4부 인쇄해서 들고 들어가면 된다.
2021-12-03 업데이트: ㅋㅋㅎㅎㅅㅂㅅㅂㅅㅂㅅㅂ… 결국 이 모든 소용이 뻘짓이 되어 버렸다. 입국 예정 일자는 12월 16일 이후기는 한데, 그 때의 자가격리 정책이 어떻게 될지는 지켜봐야 할 일.
독일은 1981년 헬무트 슈미트 총리 집권 시기에 향후 30년간 전 (서독) 국토에 광 케이블을 설치하려고 계획했으나, 후임인 헬무트 콜 총리 당시 예산을 아낀다는 핑계를 대고 광 케이블 설치 계획을 취소하고 케이블 TV로 바꿔 버리는 바람에 지금도 유럽에서 FTTx 보급률이 낮은 편이고 닳고 닳은 전화선과 케이블 인터넷을 어떻게든 우려먹고 있다. VDSL Vectoring으로 250 Mbps를 뽑아내는 똥꼬쑈! 그래서 독일에 도착해서 인터넷을 신청하려고 하면 DSL이냐 케이블이냐 둘 중 하나가 대부분이고, FTTH는 들어온다면 로또를 맞았다고 생각하면 된다. 유선 인터넷 회사에서는 보통 DSL/케이블 모뎀+Wi-Fi 라우터 기능을 하는 장비를 (대여해) 주거나 사용자가 직접 모뎀을 설치할 수 있다. 비록 통신사 쪽에서는 좋아하지 않는 눈치긴 하지만 2016년 8월 1일에 법제화되었다(키워드: Routerfreiheit/Routerzwang). 한국에서 ipTIME 같은 걸 들고 왔다고 해도 그대로 쓸 수 없고 쓸 필요도 없는 게 이것 때문이다. 인터넷이 들어오는 방식이 다르기 때문.
내가 독일에 처음 왔을 때에는 DSL 모뎀+OpenWRT 설치가 가능한 Wi-Fi 공유기를 생각하고 있었으나 이걸 하고 싶어도 방법이 거의 없었다. DSL 모뎀만 따로 사려고 하니까 잘 찾지를 않는 건지 오프라인상으로는 구하기도 어려웠고, 그렇다고 통신사에서 제공하는 공유기를 쓰고 싶지는 않아서 2015년 당시의 DSL 최신 기종인 FritzBox 7490(출시는 2013년)을 사 버렸다. (협찬받은 거 그런 거 없음)
FritzBox 7490
나중에 알게 된 사실이긴 하지만, Ubiquity나 MikroTik 같은 기업용 딱지 붙은 거 빼고 가정용 딱지 붙은 것 중에서는 순정 소프트웨어 상태가 최고라고 할 수 있다. 기본 제공하는 기능이 단순히 DSL 모뎀+Wi-Fi뿐만 아니라 VoIP 게이트웨이(DECT, ISDN/POTS, SIP 전화 붙이기 가능), 간이 NAS(USB 저장 장치 연결 필요), IPSec VPN, DNS over TLS 등 하이엔드 공유기 라인업에서나 볼 수 있는 것들이 기본 내장되어 있다. 집에 설치해 둔 필립스 Hue 스마트 전구를 Home Assistant와 ZigBee 모듈을 사용해서 별도의 Hue 브리지 없이 사용하고 있는데, 일부러 스마트 홈을 인트라넷에 가둬 뒀기 때문에 접속하려면 VPN을 타고 가야만 하도록 만들어 놨다. USB 포트에 LTE 모뎀을 연결하면 DSL이나 케이블이 죽었을 때 자동으로 LTE로 전환하는 기능도 있고, 인터넷 이전이나 신규 설치가 꽤 오래 걸리는 독일 특성상 이걸 잘 써먹기도 했다. DECT 베이스 스테이션 기능을 사용해서 VoIP 서비스를 무선 전화기로 곧바로 사용할 수도 있다. 이미 독일에서는 2020년 Deutsche Telekom이 ISDN 공중 전화망을 다 걷어내 버려서 집전화가 거의 VoIP 기반으로 굴러 가고 있다는 점도 감안해야겠지만.
WPA3 지원IPSec VPN 지원DECT 베이스 스테이션 지원
단순히 기능뿐만 아니라 보안에도 신경을 많이 쓰고 있다. 칩셋 벤더의 역량에 따라 다르긴 하지만 주어진 한계 내에서는 리눅스 커널 버전을 잘 따라가고 있다. FritzBox 7490이 출시 당시에는 리눅스 커널 2.6.36을 사용했지만 지금은 3.10/4.4(Wi-Fi 서브시스템)까지 올라가 있다. 심지어 GPL 아카이브에는 가정용 공유기에서는 쉽게 찾아보기 힘든 AppArmor까지 적용해 둔 걸 확인할 수도 있다. 그리고 출시된 지 7년이 지난 모델에 WPA3 암호화를 제공해 주는 것도 포인트. 외부에서 라우터 설정 페이지에 접근할 때 DDNS 도메인으로 Let’s Encrypt 인증서를 찍는 것도 다른 공유기에서는 찾아보기 힘든 기능 중 하나다. AVM 홈페이지에서는 구형 모델의 기술 지원 중단 날짜를 아예 게시해 두었고, GPL을 준수하는 방법을 한동안 갈팡질팡하던 국내회사와는 다르게 펌웨어 버전별로 오픈소스 소스 코드를 잘 공개하고 있다. 몇 술 더 떠서 펌웨어 업데이트에서 보안 업데이트 내역만 따로 뽑아서 고지하거나, 각종 보안 문제에 어떻게 영향을 받는지를 별도로 공지하는 회사? 얼마나 있나? 2016년에 케이블 모뎀에 들어가는 DOCSIS CA 인증서 배포 문제 때문에 CA 인증서를 한 번 갈아엎은 적도 있었지만 이것도 보안 공지에 명시되어 있다.
MyFritz: Let’s Encrypt 인증서를 찍어 주는 기능 기본 내장
대신 이렇게 순정 펌웨어에 기능이 상당히 많이 들어가 있다 보니 도리어 OpenWRT를 올리기는 까다로운 편에 속하고 올리려는 시도도 적은 편이다. 실제로 OpenWRT 위키에 있는 AVM 장치도 대부분 지원이 중단된 모델 위주고, 현역이라고 할 수 있는 모델은 하드웨어 구조가 상대적으로 간단한 FritzBox 4020, 4040, 7530 정도이다(DSL은 OpenWRT에서 미지원). 지금 쓰고 있는 7490도 하드웨어 구조가 특이한 편에 속한데, 메인+DSL SoC로 Lantiq VRX288을 사용하는 것 자체는 평범하다. 그러나 Wi-Fi 칩셋으로 Lantiq WAV 시리즈를 사용하는 게 아니라 그 자체로도 공유기를 만들 수 있는 QCA9558+PCIe로 연결되는 QCA9880을 사용하고 있다. 한 술 더 떠서 USB 3.0 포트 두 개는 SoC가 아니라 PCIe로 연결해 둔 uPD720202 칩셋으로 돌아간다. 최신형 802.11ax 지원 6660 Cable은 그나마 구조가 정상적인 인텔 Puma 7+MaxLinear DOCSIS 프론트엔드+WAV600 구성이긴 하지만.
AVM의 주요 시장이 독일을 비롯한 유럽이고, 주력 모델이 DSL/케이블 내장형이라서 한국에서 사용하기에는 불필요하게 가격을 상승시키는 원인일 뿐이라서 이걸 공유기로 쓰려고 한국에서 굳이 구해다 쓰는 사람은 아직까지는 많이 보지 못한 것 같다. 심지어 Home Assistant 한국어 번역 프로젝트에서는 이걸 “독일통신사“로 착각하기도 했다. 7490 독일판도 한동안은 펌웨어 언어가 독일어만 지원했고 영어를 비롯한 타 언어 지원은 7.21 들어서야 추가되었다. 한국에서 이걸 쓴다면 기능을 100% 다 살릴 수는 없지만 방법이 아주 없는 것은 아니다.
독일에서 주력으로 팔리고 있는 모델은 DSL 모델과 케이블 모델이고, 유선 통신사에서 주는 모뎀+공유기도 대부분 DSL/케이블+Wi-Fi 내장형이기 때문에 한국산 공유기처럼 이더넷 포트만 달려 있는 모델은 주력 제품이 아니다. LTE 지원 모델 중 6890은 DSL+LTE, 6850과 6820은 LTE만 지원한다. 독일에는 FTTH가 되는 집은 로또 당첨이기 때문에 광 케이블 모델이 있기는 하지만(5490, 5491) 이건 일반 시장용으로는 풀지 않았고 ISP에 OEM으로만 들어갔다. 4040과 4020은 한국 공유기와 비슷하게 이더넷만 사용하지만 독일 유선 인터넷에 모뎀 단독으로 쓰는 환경은 거의 없기 때문에 이것도 주력 제품과는 거리가 있다.
그래서 한국에서 FritzBox를 사용하고 싶다면 차라리 DSL 모델이 가격 할인할 때 사는 것이 지원 받기에 그나마 나은 옵션이다. 독일 내에서 주력 상품이라서 펌웨어 업데이트도 잘 되고 있고, 내장 DSL 모뎀은 비활성화해 두고 기존 인터넷과 연결해서 사용하는 것도 가능하기 때문이다. 대신 이 경우 LAN 포트 하나를 희생해야 하지만. 결정적으로 DSL 모델은 리눅스 셸에 접근할 수 있지만 케이블 모델은 DOCSIS 보안 문제 때문에 셸 접근이 일반적으로는 막혀 있다.
FritzBox의 DSL 모뎀을 비활성화하고 공유기처럼 쓰기
만약 한국에서 DSL 모뎀으로 사용해야 한다면 Annex 설정에 주의해야 한다. 독일은 공중 전화망으로 ISDN을 활발하게 사용한 나라인데, ISDN은 아날로그 집전화보다 대역을 더 넓게 사용했다. 그래서 ADSL/VDSL을 도입할 때에도 ISDN 주파수 대역을 피해야 했기 때문에 업링크 주파수 대역이 다른 나라보다 고주파에서 시작한다. 아래 그림과 같이 주파수 대역을 Annex A, Annex B와 같이 구별한다. 독일은 Annex B를 사용하고 있고 나머지는 대부분 Annex A를 사용하고 있다. Annex 변경은 대부분 기종이 지원하기는 하지만 구형 독일판 모델은 Annex B에 고정되어 있을 수도 있으니 이걸 조심해야 한다. 그리고 PPP 인증 정보도 옮겨 심어야 하는데 기존 모뎀에서 복사하거나 통신사에 문의하는 방법밖에는 없다.
반면 케이블 모뎀의 경우 골때리는 문제가 몇 가지 있다. DOCSIS 3.0까지는 미국식 DOCSIS와 유럽식 EuroDOCSIS가 나뉘어 있고, FritzBox가 공식적으로 지원하는 것은 EuroDOCSIS이다. 둘 사이의 가장 큰 차이점은 다운링크 채널 대역폭이 DOCSIS는 6 MHz, EuroDOCSIS는 8 MHz이다. 이외에도 주파수 특성이 다른 것이 있지만 자세한 기술적인 정보는 생략. NTSC와 PAL 시절 채널 대역폭이 달랐던 것이 케이블 방송에도 그대로 적용되었고 이게 DOCSIS까지 타고 올라온 것이기 때문이다. DOCSIS 3.1 지원 모델은 글 쓰는 시점에서는 6660 Cable이 유일하다. EuroDOCSIS 3.0만 지원하는 모델이라면 한국 DOCSIS 망 신호를 잡지 못할 수도 있다. 여기에 더해서 DOCSIS 가입자 인증 문제가 있다. DOCSIS 인증은 케이블 모뎀의 MAC 주소와 장치별 인증서로 돌아가는데, MAC 주소와 장치별 인증서는 항상 1:1로 대응된다. 이론적으로는 통신사 고객센터에 MAC 주소를 불러 주고 이걸로 바꿔 달라고 할 수도 있지만, 기존 케이블 모뎀의 인증서와 MAC 주소를 복제하는 방법도 있다. 자세한 기술적인 방법은 케이블 모뎀마다 다르므로 생략. AVM의 기존 모델이 대부분 EuroDOCSIS 기반이고 미국에서 주력으로 팔렸던 적도 없었기 때문에 한국 CMTS에는 AVM의 인증서가 설치되어 있지 않을 수도 있다. 게다가 AVM은 2016년 DOCSIS 보안 취약점 사건 이후로 케이블 모뎀 내장형 FritzBox의 UART 사용 및 셸 진입을 아예 막아 버렸다. 일단은 이걸 뚫어야 DOCSIS 인증서를 심을 수 있기 때문에 기술적으로 자신이 없다면 안 하는 것을 추천한다.
VoIP 게이트웨이도 지원하기 때문에 이론적으로는 한국 통신사의 SIP 서버에 붙여서 쓸 수도 있지만 이건 아무도 시도해 보지 않았다. 게다가 SIP 인증 정보를 구하는 것부터가 일일 수도 있기 때문에 일단 그것부터 시작해야 FritzBox의 VoIP 기능을 한국에서 살릴 수 있을 것이다. 그리고 DECT 전화기를 사용한다면 주파수에 주의해야 한다. 독일에서 사용하는 DECT 주파수는 1880-1900 MHz고 FritzBox도 여기에 맞춰져 있다. 그러나 한국 DECT 주파수는 완전 갈라파고스인 1787 MHz에서 놀기 때문에 FritzBox에 한국 디지털 무선전화기를 붙일 수는 없다. 어차피 FritzBox가 SIP 서버로도 작동하기 때문에 SIP 다이얼러 앱을 사용하면 되므로 상관은 크게 없지만.
독일에서 좋든 싫든 FritzBox를 써 보게 되더라도 소프트웨어 품질은 생각한 것보다 상당히 좋을 수도 있다는 걸 생각해 봤으면 좋겠다.
웹 서비스에 활용할 목적으로 머신러닝에 공개 데이터를 집어넣는다면 피해자가 발생하지 않도록 필터링은 잘 하자. 특히 이메일 주소는 크롤링을 방지하려고 다양한 형태로 변형해서 게시하는데 이걸 조심해야 한다.
KISA의 해석에 따르면 대한민국 개인정보보호법은 내가 누군가에게 개인정보를 직접 제공했을 경우에만 적용되는 법률이며, 다른 사람이 내가 공개한 정보를 잘못 사용한 경우를 다루지는 않는다.
민사소송을 진행할 수 없거나 하기 어렵다면 개인정보분쟁조정위원회가 도움이 될 수 있다.
사건의 발단은 올해 1월, 이 때부터 조금씩 이상한 이메일을 받기 시작했다. 분명 나는 독일 아마존과는 관계가 없는 사람인데 왜 나한테 독일 아마존의 계정 활성화 관련 이메일이 오는가라는 의문에서 시작했다. 그 때는 무슨 일이 일어났는지 전혀 몰랐고 이것도 그냥 스팸이겠거니 싶어서 받은 메일을 그냥 무시해 버렸다. 멕시코의 한 은행에서 계좌 거래내역을 보내거나, 러시아에서 영수증이 날아온다거나, Fitbit이나 PSN 계정이 만들어지기도 하는 등 내 이메일 주소에 희한한 일이 한번두번 일어난 적도 아니었기도 하고. 이 사건을 해결하면서 내친김에 이것들도 다 해결해 버렸다.
PSN 계정 사건: 2016년 당초에 계정이 만들어졌던 곳은 브라질로 추정되지만(메일이 포르투갈어로 날아옴) 나는 브라질에 간 적도 없었다. 일단 말이 통하는 SIEK에 문의를 했으나 해결된 건 별로 없었고 SIE 트위터 채널로 문의해 봐도 독일 전화번호만 알려 줄 뿐이었다. 그러다가 GDPR 철퇴라는 것을 알게 되었고 유럽 지역 SCEE의 DPO에게 이메일을 보내서(dpo at scee dot net) 계정을 삭제시켰다. 여담이지만 소니의 PSN 계정 관리가 지역별로 나뉘어 있는 게 참 뭣같다는 사실을 이 과정에서 알게 되었다.
Fitbit 계정 사건: 이메일 주소를 인증받지 않은 것 같았기에 내 이메일 주소로 암호 찾기를 누른 다음 계정 탈퇴를 살포시 눌러 줬다. 내 이메일 주소 자체가 털렸다는 증거는 찾을 수 없었다.
러시아 영수증 사건: Yandex에 처음에 문의를 했는데, 돌아온 답장은 영수증을 보낸 개별 업체에 문의해야 한다는 것이었다. 그래서 업체 이메일 주소를 알아낸 다음 이메일 주소를 지웠다는 답을 얻었다. 내 러시아어 실력이 좀 심각하게 비대칭스러워서 메일 작성에는 구글 번역기의 도움을 얻었으나 적어도 업체에서 내 뜻을 이해한 것 같았다.
멕시코 은행 사건: 문제의 은행 트위터 채널로도 별 소용이 없었다. 마지막으로 이메일을 보낸 사람에게 나 멕시코에 가 본 적도 없다고 이메일을 보낸 이후에는 지금까지 메일이 들어오지 않고 있다.
올해 1월부터 받기 시작한 이상한 이메일
이 사건을 잊고 있었을 때쯤인 올해 3월 또 누군가가 독일 아마존 주문 관련 이메일을 보냈다. 이번에도 그냥 무시하려다가 지난 1월에 받은 이메일이 떠올라서, 무시하려던 걸 포기하고 답장을 써 봤다. 보낸 사람 이름은 한국이었지만 메일 내용이 독일어로 되어 있길래, 대강 독일어로 “이메일 주소 어디서 확인하셨나요? 저는 아마존에서 일하는 사람이 아닙니다”라고 메일을 써서 보냈다. 그리고 거기에서 대화가 끊김. 게다가 3월에는 무슨 마가 끼이기라도 했는지 독일 아마존 주문 메일 두 통 말고도 독일 통신사인 O2 문의랍시고 메일을 보내기도 했다. 독일어로 된 이메일에는 독일어로 답장해 줬고, 영어로 된 이메일에는 영어로 답장해 줬다. 이쯤에서는 그냥 스팸이겠거니 하는 생각보다는 대체 어디에서 이상한 일이 일어난 건지가 더 궁금해져서 이메일을 더 보낸 사람에게 “peremen at gmail.com” 주소가 어디에 나와 있는지 스크린샷을 찍어서 보내 달라고 했지만 답장은 돌아오지 않았다.
그리고 올해 4월 이번에는 또 독일 보다폰이다. 이번에는 보낸 사람 이름이 한국이라서 아예 한국어로 답장을 보냈다. “저는 해당 통신사와 아무 관계가 없는 사람입니다.” 중간에 뭔가 잘못된 것이 있는 것 같긴 한데, 그 사람도 어디에 이메일 주소가 나와 있는가 알려달라는 질문에는 결국 답하지 않았다. 5월에도 또 독일 아마존 계정 정지 관련된 이메일을 받았는데, 이번에는 영어로 답장했지만 좀 강하게 나가기로 했다. “Where did you got my e-mail address? … I am very annoyed this recently. …” 이것도 결국 답장을 받지 못했다. 6월에도 또 비슷한 뭔가를 얻었길래 이번에도 메일 주소를 어디서 알게 되었는가에 대한 질문에 대한 답장은 받지 못했다.
이렇게 8개월이 지난 후인 8월 초에 대체 왜 이런 메일이 오는가 정체를 알게 되었다. 이번에는 내 이메일 주소가 나와 있는 URL을 알려 달라고 한 대신 “이 이메일 주소로 연락하라고 나와 있는 곳을 캡처해서 보내 달라”라고 부탁해 봤다. 다행히도 이번에 보낸 사람은 아마존에서 받았다는 이메일을 보내 주기는 했지만 본문 어디에도 내 이메일 주소는 나와 있지 않았다. 혹시 Reply-To 헤더가 잘못되어 있는가 싶어서 이메일 원본을 달라고 요청했으나, 결국 그걸 받지는 못하고 파파고 번역 오류라는 답을 얻었다. 파파고. 대체 뭘 집어넣었길래 내 이메일을 이상하게 해석한 걸까? 그래서 직접 해 보기로 했다.
파파고에서 amazon.de 주소를 번역했을 때 이상하게 찍혔던 결과(현재는 수정됨)파파고에서 amazon.de 주소를 번역했을 때 수정된 결과
일단 문제의 독일어 이메일을 집어넣었는데 왜 https://www.amazon.de 한국어 번역 결과에 내 이메일 주소가 나오는 걸까? 그래서 그 부분 주변 문장만 남기고 지워 봤더니 파파고 번역기의 독일어 – 한국어 번역 결과가 문제가 있었다는 걸 알게 되었다. (확인해 보기, 2020-08-12 기준 archive.is 결과) 파파고 때문에 지난 8개월 동안 이상한 이메일을 받았다는 걸 알게 되고 나니까 허탈하기도 하고 화가 나기도 했다.
그래서 이 사건을 알게 된 8월 12일 당일에 지인들을 통해서 네이버 사내에 직접 문의를 넣었고, 공식적인 의견을 듣기 위해서 네이버 고객센터에 오역 신고를 병행했다. 다행히도 휴대폰 인증과 같은 멍청한 것들을 할 필요 없이 오역을 바로 집어넣을 수는 있었다. 일단 여기서 응답이 어떻게 돌아오는지 지켜보고 다음 행동을 결정하기로 했다. 네이버에서는 이 시점에서 문제를 인지하고 기술적인 준비를 하기는 하고 있었다. 한편 오역 신고에 대한 답장은 8월 13일에 돌아왔으나, 그 내용은 나를 열받게 하기에 충분했다. 아래는 당시 받은 이메일 내용이다.
독일어->한국어 번역에서 일부 URL과 같은 특수 입력에 대한 번역 처리가 미비하여 URL이 임의의 텍스트로 잘못 변환되면서 발생한 문제입니다.
Papago에 적용된 인공신경망 방식의 번역엔진은 온라인상에 수집된 학습 데이터를 기반으로 번역하고 있는데요, 반영된 데이터의 영향으로 오류가 발생할 수 있습니다.
해당 표현은 번역 엔진의 업데이트 및 다양한 예문 학습을 통해 최대한 정확하게 번역할 수 있도록 최선을 다하겠습니다.
다만, 번역 엔진이 해당 표현 및 유사 패턴의 표현을 학습하고 점검하기까지 약 1~2개월 이상 소요될 수 있는 점 양해해 주시길 부탁드립니다.
감사합니다.
네이버에서 받은 답장 내용
사실 여기에서 처리를 빠르게 해 줄 수 있다고 답장을 했으면 적당히 끝낼 생각이었는데, 무슨 독일 관청 일처리도 아니고 1-2개월 이상 걸릴 수 있다는 말이 트리거로 작용했다. 오역 신고에서는 내가 보상을 받는 것 때문에 이러는 게 아니라는 의도로 일부러 내가 관련 없는 이메일을 받고 있다는 사실을 언급하지는 않았는데, 이 시점에서는 제대로 열을 받아서 좀 더 빠른 처리를 할 필요가 있다고 생각했다. 아직은 유럽에 거주 중이기 때문이고 사건 시작 시점에서 나는 유럽에 있었기 때문에 이걸로 GDPR의 철퇴를 먹여야 하나? 아니면 한국 기관의 도움을 빌려야 하나? 이 고민을 하다가 네이버의 첫 답장을 받은 8월 13일에 한국인터넷진흥원 개인정보침해신고센터 및 개인정보분쟁조정위원회에 민원을 넣었다. 이 사건을 진행하면서 개인정보분쟁조정위원회를 처음 알게 되었고, 이 건에 대해서는 KISA보다 더 많은 도움이 되었다.
나는 KISA의 연구 부서 쪽 사람들은 연구 관계로 만난 적도 있었고 보안 컨퍼런스 같은 곳에서 드러나는 성과로 보았을 때 해야 할 일을 제대로 하는 사람들이라고 보지만, 대민 업무를 하는 부서나 기타 다른 정책을 담당하는 부서에는 좋은 기억을 갖고 있는 게 없었다. 이 사건으로 KISA에서 받은 답장도 내 선입견을 강화시키는 데 아주 약간 도움이 되긴 했다. 민원 제기 후 8월 24일에 받은 답장 내용을 요약하자면 한국 개인정보보호법은 내가 네이버 파파고에 개인정보를 제공한 관계가 성립했을 때만을 다루는 법률이고, 제3자가 직접 수집한 나에 대한 정보가 잘못 노출되었을 때에는 개인정보보호법의 관할이 아니라는 뜻이다. 뭐 법의 뜻이 그렇다는 게 이해가 가긴 하지만.
먼저, 우리 기관의 소관법령인 『개인정보 보호법』은 이 법에서 규정된 업무를 목적으로 개인정보 파일을 운용하기 위하여 스스로 또는 다른 사람을 통하여 개인정보를 처리하는 ‘개인정보처리자’를 적용 대상으로 하고 있으며, 개인정보처리자와 정보주체의 개인정보 처리에 관한 사항을 규정하고 있는 법률입니다.
기재하신 내용을 고려할 때 귀하께서 피신고업체의 서비스를 제공받기 위해 개인정보를 제공한 것이 아닌, 피신고업체의 오류로 인해 귀하의 이메일 주소가 노출되고 있는 것으로 보이며, 이에 귀하와 피신고업체의 관계를 위 내용에 따른 정보주체와 개인정보처리자의 관계로 보기는 어려워 피신고업체에게 본 법률을 적용하여 책임을 묻기는 어려울 것으로 보입니다.
따라서 피신고업체에 오류사항에 대한 처리 요청을 하여 보시기 바라며, 만약, 협의가 어려우신 경우에는 민/형사적인 방안을 강구하셔야 할 것으로 이에 대한 소송 가능성 여부 및 관련 절차에 대해서는 대한법률구조공단(http://www.klac.or.kr, ☎132)을 통하여 자세히 문의해 보실 수 있습니다.
한국인터넷진흥원 ☎118 상담센터
개인정보분쟁조정위원회에서는 상담 사례집을 홈페이지에 공개해 두고 있었고, 여기에는 온갖 시시콜콜한 사례가 다 있었기에 확신을 가지고 문의를 하는 데 도움이 되었다. 가령 CCTV 열람대장을 제대로 통제하지 못했다거나, 휴대폰 번호 한 자리를 틀려서 관계 없는 문자를 계속 받는다는 등. 위원회의 설립 목적 자체가 이러한 상황에서 민사소송으로 가지 않고 합의를 유도하는 것이라고 보았기 때문에 망설이지 않고 문의를 넣었다. 공인인증서도 만료된 지 너무나도 오래 되었고 새로운 공인인증서 발급 때문에 여기 한국 대사관을 찾아간다고 해도 한국 은행용 OTP도 방전된 지 오래 되었던 탓에 민사소송을 여기서 나홀로 진행하는 것도 좀 무리가 있기도 했다.
개인정보분쟁조정위원회 쪽은 8월 14일에 접수되었다는 연락을 받고 한동안 진행이 안 되는 것 같았고, 이와 동시에 파파고가 언제 번역을 갱신할지 매일 확인하고 있었다. 개인정보보호법 44조에 의하면 최대 60일 이내에 심사를 해야 한다고 되어 있으니까 일단 이 조항을 믿어 보기로 했다. 독일 와서 배운 것 중 하나가 서류 심사 기한이 있으면 그 기한을 모두 기다려 보라는 것도 있기에 더더욱 오래 기다렸다. 그러다가 8월 21일에 파파고 번역을 확인해 본 결과 URL을 입력했을 때 제대로 번역이 안 되는 건 여전했지만 내 이메일 주소는 더 이상 표시되지 않는다는 것을 확인했다. 처음에는 이게 단순한 임시 해결책인 줄 알았으나 네이버 쪽에서 받은 답변에 의하면 임시 해결책은 아니었다. 그리고 8월 28일에 상당히 상세한 기술적인 내용이 포함된 답장을 받았다. KDE 프로그램 설명서에서 공개되어 있었던 내 이메일 주소를 수집하면서, 띄어쓰기가 파파고 엔진에 있었던 패턴과는 다른 형태였기 때문에 파파고 전처리 단계에서 이메일 주소였다는 것을 인식하지 못하고 번역 결과에 노출시켜 버린 것이다. 그리고 공개 데이터 사용 시 데이터 정제 과정 및 이러한 형태의 오역 신고 개선을 준비 중에 있다는 건 이해하기로 했고, 네이버 쪽에서 밝힌 타임라인(8월 12일 모델 리프레시, 8월 21일 deploy)과 내가 관찰한 것이 일치하는 것도 확인했다. 이제 이 사건이 왜 이렇게 되었는지는 이해했고 사과의 뜻을 받아들이기로 마음먹고 개인정보분쟁조정위원회에서의 처분을 기다리기로 했다.
9월 10일에 개인정보분쟁조정위원회에서 연락이 왔고, 위원회 심의 전 조정 절차에 따른 합의를 통해서 사건을 종결하기로 결정했다. 개인정보분쟁조정위원회 측에서 제시한 합의안이 내 피해를 충분히 보상할 수 있다고 보았기에 합의를 받아들이기로 했고, 중간에 추석 연휴가 끼어 있어서 서류 처리에 시간이 조금 지연되었다. 그리고 10월 6일에 합의 이행을 확인하여 사건이 완전히 종결되었다.
다른 이상한 이메일은 원인은 잘 알려져 있었으나 해결책을 사용하는 데 시간이 걸렸던 한편, 이번 파파고 오역 사건은 원인을 찾는 데에만 8개월이라는 시간이 걸렸다. 만약 처음 내게 독일 아마존, 보다폰, O2 문의 메일을 보냈던 사람들이 내 이메일에 좀만 더 신경을 써서 답해 줬다면 8개월이라는 시간이 상당히 줄어들었을 수도 있다. 그리고 한국어로 물어 보는데 파파고로 번역했다는 걸 왜 숨겼는가 이해가 아직까지도 가지 않는다. 또 URL과 같은 것들을 번역기에 집어넣었을 때 달라졌다면 그걸 확인을 안 하는 사람은 왜 그리도 많았는지. 파파고가 원인인 것을 알게 된 후에는 상대적으로 일사천리로 진행되었고, 결과 자체는 만족스럽게 끝났다. 도대체 어디서 개인정보가 유출된 건지 몰랐던 8개월보다는 문제 해결까지의 2개월이 더 짧은 시간이기도 하고. 부디 앞으로 내 이메일로 이상한 무언가가 들어오지 않기를 바라면서 사건을 닫는다.
2020-10-06 업데이트: 사건 종결에 따라서 본문 내용의 업데이트를 한 데 모아서 보기 좋게 수정했다.