자주 무선충전 탁상시계 분해하기

집 근처 이마트에서 장을 보다가 자주 매장에서 휴대폰을 무선으로 충전할 수 있는 탁상 시계를 샀습니다. 자던 도중 중간에 깨서 시간을 보는 일이 자주 있는데, 이럴 때마다 핸드폰을 꺼내서 잠금 화면을 보는 것보다는 항상 볼 수 있는 시계가 더 편하니까요. 무선 충전 기능도 자면서 머리맡에서 핸드폰을 충전하는 게 편하다는 생각도 들었고요.

포장과 설명서가 조금 엉성한 감이 있었지만 현재 시간을 충실하게 보여주고 무선 충전도 어느 정도 잘 되니 그러려니 하고 써 왔죠. 그러던 어느날, 자고 일어나니 휴대폰이 전혀 충전되지 않기 시작하고, 흔들면 떨그럭거리는 소리가 나기 시작했습니다. 어딘가 문제가 생긴 거죠.

이마트 고객센터나 자주 고객센터에 물어보려고 했지만 이마트 앱으로 영수증을 받았던 모양인지 90일이 지나 영수증을 확인할 수 없었고, 그냥 이렇게 된 김에 뜯어서 안에 뭐가 있나 살펴보자는 생각으로 뜯을 결심을 하게 되었습니다. 어차피 어딘가 고장난 물건이니 더 이상은 잃을 게 없잖아요? 사실 영수증을 못 찾겠다는 건 핑계일지도 모르겠네요.

따로 나사로 고정한 건 없어보이는데, 배터리 커버를 열고

작은 나사가 두 개 있어서 열어보니 리튬 전지가 숨어 있었습니다. 아마도 다른 방법으로 열어야 하나 보네요.

기타 피크처럼 생긴 오프닝 툴로 틈새를 공략해 보니 열립니다. 걸쇠로 고정되어 있는 부분을 스쳐 주기만 하면 쉽게 열 수 있네요.

안에서 떨그럭거리고 있던 것의 정체는 무선 충전기 코일이었습니다. 코일이 제자리에서 떨어지다 보니 무선 충전을 할 수 없어 무선 충전기로서 구실을 할 수 없었네요.

코일을 비롯해서 이곳저곳에 글루건으로 처리한 것처럼 보였는데, 충전기를 지속적으로 사용하면서 발생하는 열이 글루건을 천천히 녹여가다가 언젠가부터 무선 충전 코일이 떨어져 나와 마침내 무선 충전의 임무에서 해방되었고 무선 충전 코일은 탁상시계 속에서 자유분방한 삶을 살 수 있게 된 것입니다.

한 가지 재미있었던 부분은 코일이라고 생각했던 부분이 사실은 독립적으로 동작하는 무선 충전기라는 점입니다. microUSB 단자가 어엿하게 달려 있기 때문에 여기에 USB 케이블을 연결해도 아무 문제 없이 잘 작동합니다. 시계에 연결하든 무선 충전기에 연결하든 운명의 붉은 실과 검은 실로 연결되어 있어 양쪽 다 전원이 들어오니, 운명 공동체가 되어버린 셈이네요.

엉성하게 납땜으로 연결되어 있던 점에서 조금 웃기기도 하면서, 어느 정도 모듈화에 대해서 좋은 아이디어를 낸 것 같다는 생각도 들었습니다. 그런 아이디어를 차치하고 나면, 고장이 나서 열어보게 되었다는 점에서 결과적으로 이 제품의 만듦새가 썩 좋지는 않았으니 품질이 좋다고 말하긴 힘들겠네요.

다시 글루건을 꺼내서 이걸 탁상시계 하우징 안에 집어넣으면 써 왔던 대로 쓸 수 있겠지만 언젠가는 안에서 발생하는 열로 다시 떨어져버릴 테지요. 무선 충전기 기판만 따로 떼어다가 다른 곳에 붙여 쓰면 좋겠다는 생각이 들었지만 지금 당장 좋은 아이디어가 생각나지 않네요. 생각날 때쯤 다시 꺼내보지 않을까 싶어요.

앞으로도 이런 제품을 살 지는 잘 모르겠어요.

여전히 텍스트 인코딩은 고통스러운 문제입니다

텍스트 인코딩은 골치아픈 문제였습니다. 컴퓨터 제조사마다 다른 인코딩 규격을 사용했기 때문에 있었던 혼란은 ASCII가 나오면서 먼 옛날 이야기가 되어버렸고, 국가나 언어마다 다른 인코딩 규격을 사용했던 문제는 유니코드가 나오고 나서 어느 정도 정리되는 것 같아 보였습니다. 유니코드 컨소시엄이 첫 유니코드 규격을 내놓은 지 30년이 다 되어가고, 대부분의 컴퓨터 시스템이 파일 이름을 비롯한 각종 텍스트를 저장할 때 기본적으로 유니코드 기반의 텍스트 인코딩인 UTF-8을 사용하고 있으니까요.

하지만 완전히 해결된 문제는 아닙니다.

여전히 누군가는 텍스트 인코딩 때문에 비명을 지르고 있습니다. 한국에서 널리 쓰이는 각종 시스템은 아직도 자주 쓰이는 한글 2,350자만 지원하는 인코딩을 사용하기 때문에 자신의 이름을 온전히 학생증에 새기지 못하고, 그런 불편함을 적은 뉴스 기사조차도 신문사의 시스템 때문에 깨지는 문제가 있기도 했습니다.

대한민국 정부의 공공정보시스템은 2010년부터 UTF-8을 사용하도록 보완해서 한글로 표현할 수 있는 대부분의 이름을 주민등록증에 새길 수 있다고 합니다. 하지만 통신사나 은행에서 사용하는 시스템이 2,350자만 지원하는 경우가 많기 때문에 명의자 이름이 주민등록상 이름과 일치하지 않아 겪는 어려움도 크다고들 해요. 이런 문제는 텍스트 인코딩 문제가 아니더라도 시스템마다 이름이 다르게 표기되기도 하는 버들 류(柳)씨 분들이나 외국인들도 자주 겪는다고 합니다.

소프트웨어 개발자들에게는…

플레인 텍스트 기반으로 이루어진 형식이나 유니코드 이전에 만들어진 파일 규격들도 골칫덩어리입니다. 소스 코드에서는 파일 어딘가에 # -*- coding: utf-8 -*- 같은 라인을 적거나, HTTP 요청이라면 헤더 어딘가에 인코딩을 명시하기도 합니다. json 같은 텍스트 형식들은 기본적으로 UTF-8으로 인코딩해야 한다고 정해 놓기도 하고요.

인코딩을 명시해놓은 다행스러운 상황이 있기도 하지만 모든 파일 형식이 이렇게 해놓지 않은 것이 문제입니다. 인코딩을 정확히 명시하지 않거나, 인코딩을 명시하는 규격이 최근에 나와 잘 지원이 되지 않는 경우도 있기 때문이지요. 이런 문제로 인해서 처리하기가 까다로운 파일 포맷 중, 가장 널리 쓰이는 포맷은 파일을 압축할 때 많이 쓰는 zip 파일이 아닐까 싶습니다.

1989년에 처음 나온 이 파일 형식은 유니코드보다 먼저 세상에 나왔기 때문에 출시 당시에는 유니코드를 지원할 수 없었습니다. 어느 정도 시간이 지난 후에는 파일 이름에 UTF-8을 사용하는지 여부, UTF-8로 인코딩한 파일 이름 등을 저장하는 필드를 규격에서 지원하기 시작했지만, 예전에 만들어져 이런 기능을 지원하지 않는 압축 소프트웨어와 그런 소프트웨어에서 압축한 파일을 계속해서 지원해야 했기 때문에 모든 소프트웨어에서 이런 기능을 지원하지는 않습니다.

이런 텍스트 인코딩에 대한 힌트를 규격에서 지원해준다 한들 그런 이정표가 없는 상황을 대비해서 이런 파일을 처리하는 소프트웨어 개발자는 인코딩을 직접 추측해야 하는 상황에도 대비해야 했습니다. 여러 언어 문화권에서 들어오는 파일을 처리하기 위해서는 이 텍스트가 한국에서 널리 쓰는 EUC-KR인지, 일본에서 널리 쓰는 Shift-JIS인지, 중국에서 널리 쓰는 GB18030인지, 미국과 유럽 지역에서 널리 쓰는 ISO-8859-1/2인지 아니면 그냥 UTF-8을 쓰는지를 추측해야만 하죠.

특정 인코딩에서 어떤 패턴으로 바이트가 나타나는지로 인코딩을 추측하는 방법이 가장 일반적입니다. 모든 바이트의 맨 앞 비트가 0으로 이루어진 텍스트라면 ‘ASCII 코드로만 이루어진 텍스트겠구나’ 할 수 있는 것처럼요. 다른 인코딩은 이보다 조금 더 복잡할테지만, 이미 오랜 시간동안 많은 사람들이 공들여놓아서 만든 chardet이나 uchardet이 있으니 직접 구현하는 것보다 이쪽을 쓰는 게 나을 것 같습니다.

UTF-8이 당연한 세상을 위하여

시스템이나 파일 형식을 새로 만들 때 텍스트를 유니코드 기반 인코딩으로 저장하는 건 너무나도 당연한 일이 되어버렸습니다. 설령 한국 국내에서만 쓰는 시스템이라 하더라도 요즘 사람들이 쓰는 이모지🤔를 넣기 위해서는 유니코드를 써야 하고, 하위 호환을 위해서 어느 정도 예전의 지역별 인코딩에 관대했던 Windows와는 달리 요즘 많이 쓰이는 iOS나 Android 같은 운영체제들은 개발될 때부터 다국어를 염두에 두고 만들어져서 설계 자체에서부터 유니코드를 염두에 두고 있으니까요.

유니코드가 널리 쓰이기 전에 나왔거나 하는 이유로 유니코드를 염두에 두지 못하고 개발된 zip 파일 같은 형식도 널리 쓰이는 소프트웨어가 최신 규격을 잘 따라가게 업데이트되거나 (이미 널리 쓰이는 포맷이라 가능성이 적기는 하지만) 유니코드를 기반으로 개발된 파일 포맷으로 완전히 대체되던가 하는 방법으로 나아갔으면 좋겠고, 이미 만들어진 많은 시스템들도 차츰차츰 업데이트하거나 교체해서 흔치 않은 이름을 가진 분들도 자기 이름을 모든 시스템에서 온전히 쓸 수 있었으면 좋겠습니다.

함께 읽어보면 좋은 글

〈오리 앤 더 블라인드 포레스트〉의 닌텐도 스위치 발매

〈마인크래프트〉의 스위치 버전이 PC를 포함한 다른 플랫폼과 함께 온라인 플레이를 하게 되고 나서부터, 비록 MS는 휴대용 게임기를 만들지는 않지만 어떻게 보면 경쟁사라고 할 수 있는 두 회사에서 어느 정도 파트너십에 관한 나오기 시작했다.

올 2월 〈오리 앤 더 블라인드 포레스트〉가 클라우드 스트리밍의 형태로 닌텐도 스위치에서 플레이할 수 있을 것이라는 이야기가 나왔었고, 4월에는 〈컵헤드〉가 스위치에 발매되었다. 6월에는 〈슈퍼 스매시 브라더스 얼티밋〉에서 세 번째 DLC 캐릭터로 반조&카주이가 발표되었고, 한동안 언급이 없었던 〈오리〉가 닌텐도 스위치로 다음주에 발매될 예정이라고 한다.

닌텐도는 8월 19일 〈오리 앤 더 블라인드 포레스트〉를 닌텐도 스위치로 발매한다고 밝혔다.

처음 클라우드 플레이로 출시된다는 소문이 있었을 때는 ‘날렵하고 즉각적인 플레이를 요구해서 지연을 최소화 해야 하는 게임을 클라우드 플레이로 제공할 생각을 하지?’ 싶었는데 결국은 닌텐도 스위치에서 독립적으로 돌아가는 쪽으로 결정이 난 것 같다. 내장 그래픽카드로 플레이하면 조금 어려울 정도로 성능을 많이 요구하는 게임이기도 한데, 컵헤드처럼 원활하게 게임을 플레이하기 위해 여러 가지를 타협한 것처럼 보인다.

〈컵헤드〉에 이어서 마이크로소프트가 어느 정도 지분을 갖고 있어 다른 플랫폼으로 발매될 거라고는 상상하기 힘들었던 게임들이 〈오리〉까지도 마이크로소프트가 관여하지 않는 플랫폼에 발매한다고 하니 〈헤일로〉나 〈포르자 모터스포츠〉 같은 마이크로소프트가 직접 개발하는 프랜차이즈도 발매하지 않을까 잠깐이나마 희망을 가지던 사람들이 있었는데, 아무래도 이건 마이크로소프트에서 완전히 부정을 해 버린 모양이다. 인디 게임 스튜디오에 투자해서 만들어낸 게임과 직접 개발한 게임에 있어서는 조금 입장이 다를 수밖에 없겠지.

아무튼 〈수퍼 핫〉이나 〈핫라인 마이애미〉을 비롯해서 걸출한 인디게임들이 발매한다는 사실은 정말 반갑기는 한데, 내가 엑스박스 원에서 즐기기 위해 산 게임이 공교롭게도 〈컵헤드〉와 〈오리〉라서 기뻐해야 할지 슬퍼해야 할지 모르겠다. 😂다른 플랫폼에는 절대로 발매 안 할 줄 알았지. 하지만 엑스박스에는 아직 닌텐도 스위치에서는 구동할 수 없는 최고의 게임(?) 〈넷플릭스〉와 〈블루-레이 플레이어〉가 있다! 4K HDR로 즐길 수 있는 몇 안 되는 플랫폼이니 이건 닌텐도 플랫폼에 비슷한 사양으로 이식하는데 분명 오랜 세월이 걸릴 거야!

헤더 사진에서 스위치 라이트를 쥐고 있는 사진은 닌텐도 공식 홈페이지에서 입수했고, 스위치 라이트 속의 화면 사진은 Zoë ReeveUnsplash에 올린 것을 사용했다.