Sangwhan Moon

chrome://dino for Playdate

Sun, 21 Dec 2025 00:00:00 GMT

Note: This is not an official Google product. All assets are distributed under the Chromium license, and the game is a re-implementation of the original JavaScript version which does not follow the same license.

참고: 이 제품은 Google의 공식 제품이 아닙니다. 모든 에셋은 Chromium 라이선스에 따라 배포되며, 본 게임은 기존 JavaScript 버전을 재구현한 것으로 해당 라이선스를 따르지 않습니다.

최근에 이주 후, 여러가지 귀찮은 일이 동시에 연말에 몰려 들어와, 머리가 아픈 상황에 뭔가 머리 식힐만한게 없을까 하다가, 뭔가 머리를 식힐 무언가가 절실했다. 그 와중에 갑자기 떠오른게 전부터 봐둔 Playdate라는 휴대용 게임기였고, 홈페이지 가보니 여전히 배송이 시간이 좀 걸려 (예약제였던 예전보다는 덜 하지만) 그럼 돈 쓰지 말고 간접 체험 해보자는 취지에 간단한 게임을 하나 포팅해보기로 했다. 대상은, 아는 사람들은 아는 지루한 회의 시간의 영원한 벗인 타임킬러 게임, chrome://dino.

원 소스는 Chromium 구현체를 누군가가 예쁘게 뜯어내줘서 그걸 참고로 하였고 (사용중인 맥 미니에 Chromium을 체크아웃 할 정도의 여유 공간이 없어서), 그걸 Playdate용 Lua로 포팅한 버전. 대부분의 작업은 gemini-cli를 통해서 이루어졌으나, 상대적으로 매니악한 휴대용 기기 전용 개발 환경과 반드시 패키징 후 실행 및 검증을 CLI가 할 수 없는 에뮬레이터로 해야한다는 점, 그리고 원 구현체가 꽤 난해한 스프라이트 시트로 되어있어 수작업이 꽤 많이 들어갔다. 스프라이트 시트가 어떤 느낌이었는가 하면…

경험해본 사람들에게는 당연한 이야기로 들리겠지만 이런 스프라이트 시트를 LLM이 보면 똑똑하게 대응을 못한다. 이거 자르는데 시간을 제일 많이 쓴 것 같다.

또 하나의 난항은, Playdate의 1-bit 컬러였다. 1-bit 컬러가 무엇이냐 하면, 말 그대로 회색이 존재하지 않는 흑백 시스템. 회색은 용납되지 않는다. 명암이 필요하거나 투명이 필요하면 디더링에 의존해야 한다. 다른 곳에는 크게 문제가 없었는데, 구름에서 결국 디더링으로 회색 비슷한 효과를 냈다. 추후 UI 개선을 한다면 거기에도 쓰여야 할것으로 보인다.

개발 과정에 발견한 재미있는 사실이 두가지가 있다. 첫번째는, 개발 후 한번도 당연히 손도 안댔을거라는 확신을 배신한 TypeScript 재구현 사실. (참고로 한 버전은 TS가 아닌 JS 구현체이다. 게임 로직은 동일하다.) 두번째는, 아래 키를 누르면 숙이기가 가능하다는 것. 이 기능을 이용해서, 공중 점프 중에 하강을 가속화 시킬 수도 있는 다소 괴상한 게임 기능도 있다 (Space, <100ms>, ⬇️ 로 확인 가능).

실제 단말에서 돌아가는지는 지인을 통해서 확인은 했으나 (Thank you Michael!) 크랭크를 이용한 조작이 어떤지는 직접 해보지 않아 튜닝이 필요할 것으로 예상된다.

Download: https://static.sangwhan.com/Dino.pdx.zip

Accept-Language 간소화의 맹점

Fri, 11 Apr 2025 00:00:00 GMT

주: 아래 내용은 저자의 고용주의 공식적인 입장이 아니며, 개인적인 의견입니다. 보다 흥미로운 논쟁은 여기에.

Google의 Privacy Sandbox 프로젝트에서, 웹 브라우징 시 발생하는 의도치 않게 정밀하게 사용자 식별이 가능한 엔트로피 원(entropy source)을 줄이려는 노력의 일환으로, Accept-Language의 극단적인 간소화를 하려는 제안이 올라왔다. 대부분의 사용자는 뭐가 바뀌었는지 모르고 지나갈 수도 있는 변화지만 상대적으로 사용 인구가 적은 언어를 사용하거나, 다국어 구사자의 경우 하루 아침에 평소에 방문하던 선량한 웹사이트들이 익숙하지 않은 언어로 나오는 부작용이 있을 수 있어, 이에 대한 우려점을 몇 가지 사례를 예로 정리해보았다. 조금 더 심도있는 배경은 하기 내용을 참고.

https://www.w3.org/TR/fingerprinting-guidance/
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
https://www.w3.org/2001/tag/doc/web-without-3p-cookies/ (주: 이 문건에 대해서 주장하는 바에 동의하지는 않는다.)
https://www.w3.org/TR/ethical-web-principles/#privacy

이 문제를 발견하게 된 배경

회사에서 업무용으로 사용하는 컴퓨터에 설치된 Chrome에, 이상한 버그로 언어 우선 순위 설정을 무시하고 스웨덴어가 최상위 언어로 올라가는 문제가 있다. 현재 회사 컴퓨터의 언어 설정은 아래와 같은데,

ko-KR
ja-JP
sv-SE
en-US

4위인 스웨덴어가 어째서인지 Accept-Language에서는 최상위로 올라가는 희한한 버그가 있어, 상당수의 사이트가 스웨덴어로 표시되는 난처한 상황이다. 업무상 약간의 불편함이 있지만, 원인이 밝혀지기 전까지 설정을 손댔다가 진단이 불가능해질 것 같아 울며 겨자먹기로 방치한 상태다. 결과적으로, 버그와 상기 제안이 합쳐지면 웹사이트에는 다음과 같이 선호 언어가 전달된다.

sv-SE
ko-KR
ja-JP
en-US

다행히도, Google Workspace를 제외한, 내가 방문하는 웹사이트의 대부분은 스웨덴어를 지원하지 않는다. 덕분에 대부분 사이트를 한국어로 표시된다. 여기까지는 좋은데, 상기 기능의 실험군에 들어가면서 (Chrome의 대부분 신규 기능은 Finch라는 실험 프레임워크를 이용하여, 일부 사용자에게만 제공 되고 해당 실험 결과에 따라 데이터를 기반으로 출시 여부를 결정한다. 자세한 내용은 여기에) 한국어로 나오던 사이트가 갑자기 영어로 나오는 이상한 현상을 목격하게 되어서 들여다보게 되었다. (가장 먼저 이상한 점을 알아차린 곳은 네이버 인증.)

이는, 다름 아닌 네이버에 전달된 선호 언어가 다음과 같았기 때문이다.

sv-SE

당연한 이야기지만, 네이버는 스웨덴어를 지원하지 않고, 덕분에 스웨덴어 실패후 나와야할 한국어가 없으니, 대체 언어로 영어가 올라오게 된 것으로 보인다. 실제로 이 기능을 실험군에 들어가지 않고 확인해보고 싶다면, 개인정보 보호 브라우징을 (Ctrl+Shift+N / Cmd+Shift+N) 이용해서 개발자 툴 또는 echo.opera.com으로 헤더를 확인해볼 수 있다.

지역 언어 입장에서의 불편함

현 직장 팀의 과반수가 어쩌다 보니 대만(중화민국)에 있어, 쉬운 사례로 중국어 번체를 (國과 国 중 전자가 번체) 사용하는 대만의 사례가 떠올랐다. 예를 들면, 영어를 아예 읽지 못하는 사용자가 아래와 같이 언어 선호 설정이 되어있다고 가정을 해보자.

zh-TW (중국어 번체)
zh-CN (중국어 간체)
ja-JP

이 경우, 사이트에서 번체를 지원할 경우, 번체를 제공하고, 그게 실패할 경우 간체를 제공하게 된다. 그 마저도 없는 경우라면 글의 일부라도 한자로 나오는 일본어로 웹페이지를 볼 수 있게 된다. 다소 불편한 역사적인 이유로, 일본어를 구사할 수 있는 장년층도 있으니, 그냥 지어낸 사례는 아니다. 이 설정을 가지고 해당 제안이 모든 사용자에게 적용되기 시작한다면 어떻게 될까? 아래와 같이 웹사이트에 전달되게 된다.

zh-TW (중국어 번체)

이 경우, 사이트에서는 zh-TW를 지원하지 않으면 적당한 기본 설정 언어 또는 언어군으로 zh만 따서 내보내는 방법 중 택해야한다. 여기서 문제점은, 사이트 입장에서는 “사용자 아마 중국어밖에 읽지 못할테니 간체로 내보내자” 와 “사용자가 간체를 보면 정치적인 이유로 불편할 거니 영어로 내보내자” 중에서 하나를 택해야한다는 점이다. 이를 여러 언어로 확장하게 되면, 사이트 입장에서 다국어 지원을 하는게 머리가 아파지고, 이로 인해 사용자의 일부는 분명히 선호 언어를 설정에 명백하게 넣었음에도 불구하고 불편함을 감수해야하는 문제가 발생한다.

확장해서 보면, 유사한 사례로 중남미에서의 스페인어 (es-LA, es-ES), 브라질에서의 포르투갈어 (pt-BR → pt-PT), 마다가스카르에서의 프랑스어 (mg → fr-MG → fr-FR) 같은 경우도 생각해볼 수 있다. 보다 극단적인 사례로 아랍어는 ar-* 가 16개나 있다.

개인정보 보호와 사용자 선호도 존중, 무엇이 중요할까?

위에 링크된 깃헙 논쟁을 보면 의견이 꽤 극명하게 양분화 되어있다.

사용자가 언어 설정으로 인해 발생할 수 있는 위험성을 모르니, 이를 브라우저가 보호해줄 필요가 있다
사용자의 언어 설정은 근거가 있고, 그를 고려해서 다국어 지원을 사이트에서 할 수 있게 해줘야 한다

지극히 개인적인 입장으로, 후자쪽에 손을 들어주고 싶다. 다국어를 구사할 수 있는 사람 입장에서 현 제안은 인터넷상에서 무분별한 사용자 식별이라는 문제를 해결하기 위해 비교적 소수를 (3개 국어를 구사할 수 있는 사람은 인류의 13% 밖에 되지 않는다는 통계가 있다) 희생시키는 건 위험하다는 의견이다.

추신: 네이버 로그인 페이지의 영어가 자연스러웠다면 눈치를 못챘을지도. “shooting a QR code”가 눈에 밟힌 게 문제.

Wonderswan용 카피 카트리지

Tue, 25 Feb 2025 00:00:00 GMT

테트리스를 하고 싶은데, 이게 공교롭게도 중고가가 꽤 높게 책정되어 있어서 (15000엔 수준, 박스가 있을 경우에는 3만엔까지도 한다) 구매를 할 엄두를 못내고 있다가 알리에서 카피 카트리지를 팔고 있다는걸 알게 되어 호기심에 구매하였다. 진짜로 궁금했던건, Wonderwitch 기반 플래시 카드를 대량으로 싸게 만들어서 구워서 보내주는게 아닐지가 더 궁금해서였는데 (이게 맞을 경우 Wonderwitch의 복간판인 Wonderdog를 여러개 가질 수 있는 꼴이니) 공교롭게도 이건 아니었다. 구매 가격은 배송비 포함 21.60달러.

출처: 페이페이마켓 (2025년 2월 25일 기준)

우선 정품을 살펴보면, Mapper (2001형), EPROM, EEPROM으로 구성된 정품은 아래와 같은데, 여기서 사용된 Mapper는 사실상 반다이 또는 반다이와 계약된 서드파티가 아닐 경우 확보가 불가능하니 사실상 이걸 그대로 재현하는건 불가능하다.

출처: https://github.com/remy/ws-pcb-db

대륙에서 재구성한 구성은 FPGA를 통해서 NOR 플래시 메모리에서 읽은걸 Mapper인 척하면서 EPROM 처럼 본체에게 보이게 하고, EEPROM을 MRAM으로 에뮬레이션하는 형태가 아닐까 추측된다. SRAM 기반 카트리지도 이렇게 구성을 한다면 정기적으로 배터리를 교체해주는 수고수러움이 줄것이고, EEPROM의 고질적인 문제인 쓰기 사이클의 상한 문제도 해결되니 복제품이 어떻게 되면 더 완성도가 높은 제품이 아닐까 싶다.

사용된 NOR Flash를 64MBit로, 만약에 게임만 덜렁 들어있다면 사실상 1/8밖에 사용하지 않은 꼴이 된다. 아마도 판매하는 모든 게임을 같은 구성으로 판매하되, 주문이 들어오면 NOR에다가 입혀서 구운 다음에 (단면 기판이라, 토스터 오븐 같은걸로도 구울 수 있으니) 보내주는 형태로 의심된다.

왼쪽부터 순서대로 MRAM, NOR Flash, 그리고 FPGA. 부품 사이트를 통해서 FPGA를 소량구매시 객단가가 16.17달러인걸 감안하면 사실 21달러가 그렇게 비싼 가격은 아니고, 배터리 교체도 필요 없으니 오랫동안 묵혀도 문제는 없을것으로 생각된다. MRAM은 강력한 자기장에 민감하니 네오디뮴 자석 같은것만 근처에 안가게 조심한다면. 다만 레이저 마킹의 퀄리티/손상으로 보았을때 재생이나 저가 복제 부품의 가능성도 배제할 수 없으니… 내구성은 두고 봐야할 문제.

정품 테트리스 카트리지와 비교해보면, 디지털 패시브계 부품은 굉장히 적은 간단한 구성. C6이 없는건 조립실수인지 없어도 그만인 바이패스인지는 만든 사람만 답을 알고 있을거고…

뒷면은 정품 카트리지들과 같이 부품이 없다.

중요한 구성품은 총 3가지이다. 객단가 생각하면 만들어볼 생각하지 말고 그냥 그냥 중국에서 사자…

FPGA - Altera MAX II (EPM240T100C5N): https://www.mouser.jp/ProductDetail/Altera/EPM240T100C5N?qs=jblrfmjbeiHmgaW5DQXOiw%3D%3D
NOR Flash - MX29LV640EBTI-70G: https://www.mouser.jp/ProductDetail/Macronix/MX29LV640EBTI-70G-TR?qs=mELouGlnn3elQvXLs7z16Q%3D%3D
MRAM - MR256A08BSO35: https://www.mouser.jp/ProductDetail/Everspin-Technologies/MR256A08BSO35?qs=lzGMqP3RDOLLV0tX2sCFgg%3D%3D

Wonderswan Color IPS 액정 개조

Thu, 20 Feb 2025 00:00:00 GMT

21세기 초입에 나온 괴작 휴대용 게임기가 있다. 좋은 아이디어들과 꽤나 탄탄한 서드 파티 지원으로 기대를 받고 있었으나, 1999년에 첫 흑백 기종을 팔아먹은 뒤, 출시 1년 반만에 (2000년 12월) 컬러 기종을 내놓을때 기존 흑백 유저를 버리는 과격한 전략으로 많은 사람들이 실망을 했고, 그 마저 발매한 컬러 버전의 하드웨어가 굉장히 실망스러워서 많은 원성을 산 제품으로, 뒤늦게 살짝 좋은 액정을 추가한 스완 크리스탈 기종을 발매하였으나 이미 발매 예정된 게임이 없어서 굉장히 판매가 저조했다.

소문에 의하면 실패의 원인은 북미 시장 진출에 닌텐도의 견제가 있어서 미국 총판을 맡기로 한 마텔사가 발을 뺐다는 소문이 있다. 덕분에 발매 5년만에 게임도 몇개 없이 단종되었다. 이렇게 애매한 물거인데도 불구하고, 당시에 잘 팔리지가 않아서인지 현재 중고 거래가가 높게 형성되어 있는 편이다 (컬러 기종 출시 가격이 6800엔, 야후 옥션에서 2025년 거래가가 약 3800엔 전후).

각설하고, 요점부터 이야기하자면 비인기 휴대용 게임기에 사양도 서드파티 지원도 부실해서 실패한 아는 사람만 아는 기종.

가장 높은 밝기에 최대한 좋은 각도로 촬영한 것인데, 액정의 (STN) 수채화를 세탁기에 돌린듯한 색감에, 편광이라고 의심될 정도의 시야각, 백라이트도 없고, 액정 보호를 위한 플라스틱도 조차도 반사가 심해서 실내에서도 화면이 간신히 보이는 수준이다.

이걸 최근에 중국의 어느 집단에서 훌륭한 IPS 액정으로 개조할 수 있는 키트가 나와, 재미삼아 한번 시도해보기로 하였다. 일단 분해. 개인적인 기록 목적으로 친절하게 단계별로 설명된 가이드는 아니니, 봐서 이해가 안될 경우 판매처 또는 동영상 가이드를 참고하면 된다.

분해 후 4개의 액정 쿠션 제거 (하얀 네모 4개). 노후 정도에 따라 에탄올 등으로 테이프를 한번 더 비벼서 제거해야할수도 있다. 이후에 쇼트 방지용 테이프 도포.

액정 전원 선 연결. 배터리 단자 옆에 각각 VCC/GND를 딸 수 있는 곳이 있으므로 잘 활용하면 된다. 배터리 단자가 녹지 않게 신속한 작업이 필요하므로 송진이나 플럭스를 사용하면 좋다.

기존 액정과 패널 제거. 패널 제거 후에 플라스틱에 남은 찌꺼기는 미지근한 물과 지우개로 정리하였다. 케이스 도료 내구성이 좋지 않기 때문에 에탄올 같은건 사용하지 않았다.

IPS 액정 뒷면에 쇼트 방지용 테이프와 단자 연결까지 어느 정도 완료한 모습. 주 포인트는 IPS 액정 컨트롤 보드와 본체 메인보드 리본케이블 연결이 다른 방향이라는 점. (액정쪽은 파란게 위로, 본체쪽은 파란게 밑으로)

잘못 연결해도 부팅은 된다. 화면이 안나오고 부팅 소리만 날 경우 케이블 연결 불량을 확인하면 된다.

케이스 뚜껑 닫기 전의 조립 완료 모습. 터치 버튼은 최대한 멀게, 리본 케이블은 저런 느낌으로 정리해두면 케이스 닫기가 수월하다. 왼쪽의 빨간 전원선은 당연한 이야기지만 안쪽으로 넣어줘야 한다.

정상 동작되는 모습. 멀리서 찍어도 액정이 잘 보인다.

Synology DS416 Slim 전원 불량 수리

Sat, 15 Feb 2025 00:00:00 GMT

Synology에서 2015~2016년경 판매했던 DS416 Slim이라는 모델이 있다. 2.5인치 하드디스크 4개가 들어가는 제품으로, 당시에는 책상 위에 올려두고 쓰기에도 부담 없는 크기였다. (3.5인치 제품을 사용해본 사람이라면 알겠지만, 책상 위에 두기엔 크기가 꽤 부담스럽다.) 또한, 당시에는 2.5인치 고용량 하드디스크의 신제품이 꾸준히 출시되던 시기라 비교적 매력적인 제품이었다.

현재는 고용량 SATA SSD를 사용해 NAS를 구성할 수 있는 시대가 되었지만, 이 모델의 최대 용량이 3.5인치 하드디스크 한 개보다도 작아져서 다소 애매한 포지션이 되었다.

좁은 일본 원룸에서 생활할 때 백업 및 Plex 서버 용도로 유용하게 사용했는데, 어느 날 갑자기 전원이 들어오지 않는 문제가 발생했다. 전원부 문제를 의심하고 만능 DC 어댑터를 구매해 교체해봤지만 해결되지 않아, 결국 어댑터를 반품하고 그대로 방치했다.

그렇게 약 2년 동안 방치한 후, 시간이 좀 생겨 다시 살펴봤다. 조사해보니 이 모델에서 장기 사용 시 특정 콘덴서가 쇼트 나는 문제가 발생하는 설계 결함이 있다는 정보를 발견했다. 동일한 증상을 겪은 사례들이 있었고, 원인도 동일할 가능성이 높았지만 바빠서 결국 다시 2년간 방치했다.

사실 출시된 지 9년 된 기기라 폐기해도 무방하지만, 문제는 데이터였다. 4년 동안 접속하지 않아도 문제없는 자료들이긴 했겠지만, 그래도 찜찜한 마음에 박사 디펜스가 끝난 김에 묵혀뒀던 NAS를 수리해보기로 했다.

공교롭게도 iFixit 같은 친절한 분해 가이드는 없었지만, 생각보다 내부 구조가 단순해서 메인보드까지 분해하는 데 어려움은 없었다.

케이스 분해 참고 영상

어느 이탈리아 수리공이 올린 영상. “우노”, “두에”, “트레”, “콰트로” 정도만 알아들을 수 있으면 된다. 이는 단계별로 제거해야 하는 나사 개수(최대 4개)를 의미한다. 2~3 사이에서 뭐라고 하는 부분은 드라이버가 안 들어가서 다른 걸로 시도하겠다는 내용 정도로 보인다. 나사는 총 14개 나오며, 분리해야할 케이블은 두 개. 그것도 커스텀 리본이 아니라 실수해도 교체품을 구할 수 있다.

해야 할 작업 2가지

분해한 김에 CR1220 RTC 배터리 교체
C390, C391, C150 콘덴서 쇼트 여부 확인 후 교체

콘덴서 교체 시 사용할 부품의 사양에 대해서 의견이 분분하지만, 그냥 제거해도 기동 자체는 가능하다. 다만, 문제가 없다고 100% 보장할 수는 없다.

(주: 일련번호 노출 관련. 보증기간 지난지 조금 있으면 9주년 된 고물에 사용자등록도 안해서, 괜찮습니다.)

문제의 콘덴서들은 붉은 동그라미로 표시해두었다.

이걸 교체하면 끝.

교체할 콘덴서는 22uF 16V/50V로 예정하고 있었지만, 집에 재고가 없어 일단 제거한 상태로 기동 확인만 진행했다. 다행히 정상적으로 부팅되었고, 저장된 데이터도 모두 무사함을 확인했다.

업데이트: 22uF는 잘못된 값으로, 사용시 주변 콘덴서가 전부 다 쇼트나는 문제가 발생하니 굳이 쓰겠다면 그냥 제거한 상태로 사용하자..

문제의 MLCC (우측 상단). 비교용으로 둔 10NT는 대략 100원 / 100엔 동전 크기. 쇼트가 난 상태라 원래 값을 부품만으로 확인할 방법은 없다.

부품이 크기를 보면 짐작할 수 있겠지만 초보자한테 권할 수 있는 수리는 아니다.

3년만에 펜(?)을 잡다

Mon, 10 Jul 2023 00:00:00 GMT

3년만에 블로그에 글을 적는 기분이 다소 생소하다. 원래도 자주 안썼는데, 여러가지 사건이 터지고 무엇보다 삶이 바빠져 쌓여있던 문제의 해결이 늦어지고… 아무튼 그 사이에 많은 일이 있었다.

일단, 오랫동안 정을 쌓아왔던 스타트업과 불가피하게 이별을 하게 되었다. 잦은 정리해고의 외자계, 미래가 불투명한 스타트업에서 합쳐서 10년 이상 불안한 마음으로 생활하던걸 좀 벗어나보고자 안정성을 우선으로 대기업으로 전직을 하게 되었다. 스타트업 마지막 1년의 질풍노도의 스토리는 다음에. 어쨋거나 전직을 하고 바빴지만, 블로그가 정지된데에는 더 큰 이유가 있었다.

가장 크게 기여한 계기를 실토하자면, Ghost 보안 패치를 하면서 권고에 따라 비밀번호를 바꿨는데, 이걸 새까맣게 잊어먹었다. 거기에다 뒤늦게 SMTP 서버 설정이 안되어있어, 메일로 초기화도 불가능한 상황이라는걸 알아버렸고, 결국 내 집 열쇠 바꾸고 열쇠 잃어버린 바보 꼴이 된게 사실상 이유다. MySQL 들어가서 쑤시면 될 것 같긴 했으나… 굳이 그렇게까지 해야하나 하는 생각이 들었고, 결국 귀찮이즘의 승리로 블로그가 사실상 3년 동안 방치되었다.

사실 Ghost 써본 사람들은 알텐데, 생각보다 마크다운으로 그림 넣어가면서 쓰는게 흐름이 잘 끊긴다. 그래서 어차피 생산성도 안좋은 Ghost를 벗어나보려고 Notion 기반 블로그를 만들었는데, Notion에서 컨텐츠를 땡겨가는 코드가 하루 아침에 동작하지 않게 되었고, 이로 인해 의욕이 상실된 즈음해서 회사 일도 바빠져서 결국 뒷전으로 미뤄졌다.

남의 코드를 이용해서이기는 하지만, 위에서 시도하던 Notion 기반 블로그를 결국 성공적으로 올렸고, 덕분에 요새 핫하다는 Vercel도 써보고 next.js도 써봤다. 그래서 3년만에 자축하는 글 같은 느낌으로 적어본다.

일단 Vercel 소감은, 잘 만들었다. 프론트엔드의 가려운 점들을 꽤 시원하게 한방에 해결해주는 것들이 많고, 빌드 툴이나 이런것들 사용자 체험이 세련되고 좋다. 예를 들면, 프론트를 여러 버전을 배포된 상태로 두게 되고, 하나가 현행이 되는데, 아래와 같다.

위에 있는 blog-xxxx-sangwhan.vercel.app 주소들 중 빌드 된 것들은 다 접속이 가능하다.

Rollback 같은것도 한 클릭으로 가능.

다만… 기업용 플랜으로 가게 되면 적지 않은 부담이 될 것 같기는 하다. (좌석당 20불이니 개발자가 40명 있는 조직이면, 오늘자 환율로 한달에 104만원, 1년에 1250만원이다…)

Next.js는 왜 좋은지 잘 모르겠다. 일부러 찾아서 쓰지는 않을듯.

Japan's COVID-19 Reports - 140KBs of Unadulterated Incompetence

Sun, 29 Mar 2020 00:00:00 GMT

These are some thoughts on the daily reports issued by the Japanese Ministry of Health, Labor, and Welfare. I'll be using data from the March 27 COVID-19 status report and the English Version.

Setting aside that these reports seem to be manually written in HTML by a human being (unlike other places that offer a dashboard, e.g. South Korea) there are some serious issues with this report format. I am writing this on March 29, but I will explain why am I using a report from March 27 at the end.

Sums? Where we are going, we don't need sums to work.

First, this is the breakdown table at the top of the report. I'm using the version from the English page, for legibility reasons. Here is an illustration of the legibility problem, using a grain of sesame:

Compare this with a Wikipedia page, with the same sesame grain.

First problem here is that none of the really important tables here are actually text based tables - they are images. Images with no alt text, hence will give you dead silence if you try to access the information with a screen reader. I won't go into the details why this is bad as that's enough material for a whole new post, but you can read more on this here.

On the other hand, it's extremely detailed, which is nice - but how do these numbers break down? The answer is, not in a very straightforward way.

So this table, confusingly enough is a quasi-hierarchy. It has these levels:

Level 1: PCR tested positive, PCR tested
Level 2: With no symptoms, With symptoms, Under confirmation of the symptom, Death (this is special, see below)
Level 3: w/Symptoms - Already discharged, w/Symptoms - Need in-patient treatment, w/o Symptoms - Already discharged, w/o Symptoms - Need in-patient treatment
And so forth.

Tested negative is implicit. It's presumably pcr_tested - pcr_tested_positive. Ideally, pcr_positive and pcr_negative would have been level 1, with level 0 being pcr_tested.

Now confusingly enough, here is how you integrate to get PCR tested positive, which is level 2:

pcr_tested_positive = with_no_symptoms + with_symptoms + under_confirmation

Remember to not include death, because this is a quasi-hierarchy. The table tempts you to, but it's excluded. (The quasi-nature is because it is under the PCR tested positive umbrella on level 2.) So what about integrating level 3?

That's simple. You don't. Because no matter how hard you try, the numbers won't add up. (e.g. Give it a try - you'll end up with 129 != 131 and 1147 != 1191. We'll need one of these numbers later.) Level 4 adds up though, so the plot thickens.

So, up next - do the rows integrate nicely? Fortunately - yes. Does the breakdown matter to the average joe? Not really. Unless you are a healthcare official, the details really don't matter - the average population only needs to know the summed numbers to be able to compare how bad the situation is with other countries, and how careful they should be when leaving their homes.

Here is a simplified version I made that shows only what matters to the average person.

According to this data, the positive case mortality rate is around 3.21%.

The statistically disappearing ghost ship passengers

Moving on to the next chart, we can see some interesting patterns here.

First, there is a new number that was not disclosed in the previous table - 2059, and 672 respectively. So what are these? 2059 is a sum including the cruise ship passengers. Even worse, in the Japanese version even this table is missing - and only provides a separate table with the cruise ship numbers, and completely omits the summed count.

Why? Nobody knows. The problem here is that these people are no longer on the ship; and have actually landed on Japanese soil. So the real number of positive cases on Japanese soil is actually 2059, and not 1387 as the previous table suggests. It is also worth noting that 603 of the 672 people have been discharged, and nobody has a slight idea where these people are as of today.

On top of that, "cured" cases reported by the government in press releases (but not this report, so the numbers aren't off by 600 people) include patients from the cruise ship, so if you calculate the ratio of cured to infected, it's on a different magnitude. Number magic! Deaths on the other hand have not been summed, so if you are a Japanese citizen who happened to die of COVID-19 complications after getting off of the Diamond Princess, you have not contributed to the mortality rate. Yay for statistics!

Moving on to the next nit, there is a bubble that says "from severe to moderate/mild symptoms" with a value next to it, but crossing two cells. What does this mean? Nobody knows, and there is no explanation why it crosses two cells on the page either.

The previous table, which is dated "12:00, Mar. 27", this table is dated "18:00 Mar. 26". That is a 18 hour difference between two adjacent tables - yet the total cases are exactly the same. So either all the hospitals are clocking out exactly at 18:00 and halting all testing, or something is very wrong.

Look Woody, infected people everywhere. EVERYWHERE.

Now, after roughly two screens worth of a information summarized about the local situation, they move on to a static table breakdown of the global situation with no visualization. This section allocates a 53.47% of the vertical pixel real estate of the entire report. Sure, it's useful information - but not in a table which doesn't allow sorting with no plot. Here is the real-estate breakdown visualized:

Here is the thing - there are a dozens of places that do this better than this page, so the citizens here can look them up there. Even if English literacy is not a thing in Japan, I'm sure Ctrl+F and typing a country name in English for specific cases is not rocket science for anyone who has finished mandatory public education. Why they allocate so much space to information very few will read is a mystery - if they really want to, this should probably be a separate post.

I'm not sure what the intent of this is. Is it to show how terrible the rest of the world is and how great Japan is managing the situation? I don't know.

I normally don't sum things, but when I do - they don't add up.

Now, we finally move on to the meat of the report. Local regional breakdowns. Why this is after the global numbers is beyond me, but at this point it seems like anything goes.

The table columns are in the order of municipality, patients, currently in-hospital, discharged, and dead.

Now to add more consistency to the report, we have yet another unsortable static table. You can also see here that unlike the previous table, it has been sorted by the second column, which is well, consistent with none of the tables we have seen so far - but at this point, who cares.

This time, the sum of patients include the dead. Try it yourself.

227 = 194 + 28 + 5

There is no rhyme or reason behind the inconsistencies between the first summary table and the regional breakdown. (Not to mention that none of the tables have matching columns for baseline comparison, because that seemed like a good idea at the time to someone at Kasumigaseki.) There isn't much more to write about here, common sense seems to be a scarce resource to those who have been involved in the report.

Moving on, here is the grand total.

Wait, what? Where did 1191 come from? When is this table from? Well, nobody knows - it's not written anywhere. Let's add those up, like we did on the first row of the same table.

828 + 319 + 46 = 1193

What?

What we do know is that this is yet another set of new numbers which don't match up to anything we have seen so far. Or does it? Remember they noted 無症状病原体保有者を除く (excluding those who are asymptomatic) above? Well, let's try that - here are some assumptions we will make based on what the government probably was thinking.

Awaiting is considered asymptomatic, because that lowers the count. No symptoms, right?
Asymptomatic is obviously asymptomatic.
The dead has no symptoms, obviously.
Remember we pretend the ghost ship passengers don't exist? They don't. They don't exist. Shhh.

Ah, but there is 1191, which is the "with symptoms" column sum in the first table, right? But what about awaiting and dead and all of that? Maybe there is another way to compute this.

After trying a bunch of combinations from the table above, the conclusion is that this number might also come from this function.

sum_local = pcr_positive - with_no_symptoms - awaiting_symptoms
1191 = 1349 - 131 - 27

It turns out - this magic function works for all rows. That means the hierarchy is represented in yet another confusing form, but let's not go too deep into that.

I have no idea what they did about the dead, but the dead do not seem to be part of the equation. Why they chose this particular subset is beyond me.

Incompetence? That's our Scrapeshield.

To add insult to injury, if you want to use these reports as a foundation for analysis, you are in for a surprise. (at least I was.)

Here are some issues that I encountered:

The report formats constantly seem to change
Images, as noted above
No semantics or meaningful selectors in the markup
Multiple report types
No URL patterns

The reason why I used a two day old report on March 29 is simple, there was no full report yesterday nor today. I'm guessing the Tokyo lockdown means that nobody can get to work, and PCs are too expensive to buy for home use so the people at the Ministry of Health can enjoy a nice weekend with hoarded pasta.

(4) in particular is interesting - the government releases multiple types of reports, depending on the week of day. Here are the different types: (you can see the full list here)

新型コロナウイルス感染症の現在の状況と厚生労働省の対応について: Full report. Only released on weekdays. Summary table, cruise ship table, international table, followed by regional breakdown table.
新型コロナウイルス感染症の現在の状況について: Weekend/public holiday edition. Summary table, cruise ship table, and international table. No local regional breakdown.
新型コロナウイルスに関連した患者等の発生について: Released daily. Least useful, easiest to parse. Contains only a delta of new confirmed cases (no status, like the regional breakdown in the fully report) broke down by region.

There is still no delta report for today as of now (March 29, 16:16) and as the report release time is not noted on the posts, I'm not sure when to expect it.

(UPDATE: I see it now, as of 19:30. I'm suspecting the 18:00 timestamp from earlier is probably related to this. Just a guess.)

Suggestions

So, so far I've been complaining about this report type with no actionable feedback - which is bad. I doubt the Japanese government will read this post and actually take any sensible action, but here are some suggestions.

Make two reports. A summary (not more than two pages) report for citizens, and another detailed one for health professionals and formal use.
Remove the international table. It's not useful to 99% of the audience out there. We have WHO data for that - that's what hyperlinks are for. If you want to do your own international edition (which I believe you should not, considering the quality of your existing reports) please do it as a separate report.
Accompany reports with the raw data used. Even better, provide a public data feed for people to take away and throw into a tool of their choice - you might get a nice dashboard or trend report for free from someone who is bored enough.
If you can't do (3), at least add some selectors to your HTML reports that can be used to pull the data out.
Make the data field availability as consistent as possible. Don't suddenly add and remove fields.
Make the format of the report and data points available consistent every day.
Don't invent magic equations. People notice when the numbers don't match up. If you invent an equation, disclose how you ended up with that number.
Release reports and data regularly, and communicate when this will be and if you cannot communicate that too.
Make the report URLs predictable, so people can scrape if needed.
Please consider accessibility when making these reports available. Sure - OCR technology has advanced, but that is not a valid excuse.
Enough with the bloody PDFs. Tabular data in the worst case can be released as CSV or XLS and nobody will complain. Maybe that grumpy guy who still uses his 25 year old PC-98 might, but f$#k him.

ABCI and TSUBAME 3.0

Sat, 17 Aug 2019 00:00:00 GMT

This is an early introductory document covering the differences between two supercomputers which I happened to have access to.

More content might be added when I have time.

Hardware

A comparison of the compute nodes in the following table. The characteristics are relatively similar, but ABCI is generally more powerful and uses slightly more recent hardware.

In particular, one would not train a mixed-precision model on TSUBAME.

	TSUBAME 3.0	ABCI
CPU	Intel(R) Xeon(R) CPU E5-2680 v4	Intel(R) Xeon(R) Gold 6148
CPU Clock	2.40Ghz	2.40Ghz
CPU Core Count (Threads)	28 (56)	40 (80)
RAM	256GB	360GB
GPU	Tesla P100-SXM2	Tesla V100-SXM2
GPU VRAM	16GB (-10MB)	16GB (-0MB)
Interconnect	4x Intel Omni-Path	2x Mellanox Infiniband EDR
Full Resource	q_node	rt_F
Scratch (NVMe)	/scr	/local
Apps	/apps	/bb/apps
Home FS	Lustre	Lustre
Shared	/gs/hs0, /gs/hs1, /gs/hs2	/fs1, /fs2, /fs3
Shared FS	Lustre	GPFS
Max Duration - Batch (Hours)	24	72
Max Duration - Interactive (Hours)	24	12
Hourly Rate - Standard (JPY)	80	200

Trial Jobs

TSUBAME 3.0 allows one to submit up to two trial jobs using qsub. This is not supported in ABCI.

(Getting a shell through a trial job via qrsh seems to be rather tricky, possibly because trial jobs have extremely low priority. For the time being the cause of this is inconclusive.)

Interactive Node

TSUBAME has the interactive node world accessible through the following domain - which is load balanced between two nodes. (login0 and login1 - both can be accessed directly by changing the name in the domain.)

login.t3.gsic.titech.ac.jp

ABCI on the other hand does not allow direct access to the interactive node, and one needs to go through a proxy. The proxy is on the domain:

as.abci.ai

And one needs to use this as a jump node to get to the actual login servers. This can be done by ssh-ing into as.abci.ai, then ssh-ing into es. This is tedious and annoying, but recent versions of OpenSSH simplify this through a feature called "jump hosts". Ignore the official documentation - which gives you a convoluted method for connecting and use this:

ssh -J username@as.abci.ai username@es

es is load balanced between 4 nodes, which can be accessed directly.

Requesting Resources

Since both use the exact same job scheduler (Univa Grid Engine) - job submission generally works the same. The only thing you need to change when requesting a resource is the type, so the following command in TSUBAME:

qrsh -g my-tsubame-group -l q_node=1 -l h_rt=00:10:00

Would be this in ABCI:

qrsh -g my-abci-group -l rt_F=1 -l h_rt=00:10:00

Same rules apply in job scripts.

Module Naming

Both systems use GNU module to enable optional software packages. The naming convention is slightly different - ABCI uses two levels for module versions, while TSUBAME only uses a top level.

ABCI: cuda/10.0/10.0.130
TSUBAME: cuda/10.0.130

Choosing The Right Computer

ABCI is 2.5x more expensive than TSUBAME (for Tokyo Tech users, if your project billing falls under 第4条第4項(成果非公開), then it's a 25% difference.) - so the general rule of thumb seems to be this:

I absolutely need FP16: ABCI, although it's worth noting that one can get 2x the nodes on TSUBAME so if you can setup distributed training, it might be more cost effective to do it there.
I need more than 256GB RAM: ABCI
I need lots of CPU cores: ABCI
I need bleeding edge CPU instructions: ABCI
TSUBAME is overbooked: ABCI, obviously
Otherwise: TSUBAME

That said, both are way cheaper than EC2 or GCP.

Closing Remarks

I wish TSUBAME billing could be simplified, the points system seems to be designed to obfuscate how much money one is spending on compute.

또 하나의 브라우저 엔진이 없어졌다

Fri, 19 Jan 2018 00:00:00 GMT

개인적인 입장의 글입니다. 현재 활동하고 있는 표준화 단체, 고용주의 입장과는 무관합니다.

Microsoft에서 지지난주에 Internet Explorer의 후속으로 개발하던 브라우저 Edge의 (코드명: Spartan) 엔진 개발을 중단하고, Chromium기반의 브라우저로 새로이 내놓겠다는 기사를 보았다. 소문은 그 이전에 돌기 시작하였는데, 이게 발표되고 나서 충격이 컸던건 사실이다.

전 직장이었던 Opera의 Presto엔진 개발 중단에 이어, 두번째 대형 엔진의 개발 포기 소식이다. 이에 대해서는 현재 소속 되어있는 Technical Architecture Group에서도 의견이 많이 나뉜다. 이는 어디까지나 개인적인 의견이지만, 단기적으로 보았을때는 컨텐츠 개발 편의성에 측면에서는 좋은 소식일 수 있으나 장기적인 웹의 미래를 생각한다면 좋으 소식이라고 하기 힘들다.

사람들이 Edge를 어떻게 생각했는지 모르겠지만, 브라우저 엔지니어링을 8.5년 해본 입장에서 봤을때는 굉장히 잘 만든 브라우저라고 생각해서 더욱 안타깝고, 나아가 노력이 아깝다는 생각이 들었다.

같은 주제에 대해 Andre Garzia씨가 쓴 글을 인용하면, 브라우저 엔진이 없어지는것은 세상에 언어가 없어지는것과 같다는 표현을 한다. 사실 어떻게 표현을 해야할지 좋은 아이디어가 떠오르지 않았는데, 적절한 예를 든 것 같다. 모두가 같은 언어를 사용한다면, 일반적인 관점에서는 편할 수 있으나 단일 문화가 정착되는 시점에서 그게 당연시되고, 그 당연시 됨에 따라 사실상 새로운 언어, 아울러 소수 언어가 소외되는 현상이 당연히 발생하게 된다.

기억을 더듬어보면 IE가 시장 주도권을 가졌던 시절 상당수 컨텐츠가 IE만을 지원했었다. 비주류 브라우저를 이용하는 사용자들은 엄청난 불편함을 감수하거나 윈도우와 IE를 병행해서 사용해야만 했다. (공고롭게도, 지금도 이렇게 해야하는 사이트가 남아있다.) 시장은 비주류 브라우저에게 혹독한 현실이었고, 회사에서 그러한 브라우저들 지원을 한다고 하면 [1] 보통 시간 낭비한다는 소리를 듣곤 하였다.

이러한 어려운 상황을 여러 사람이 열정적으로 합심하여 지금의 새로운 HTML로 표준화를 성공적으로 해냈고, 덕분에 플래시나 기타 플러그인에 의존하던 컨텐츠 대부분이 지금은 표준 기술만으로 구성되어 비교적 잘 돌아가고 있고, 어느 브라우저를 사용하든 [2] 대부분의 웹 서비스 기능은 이용할 수 있는 세상이 만들어지나 싶더니 이런 일이 생겨버린건 결코 긍정적으로 보기는 힘들다.

Chromium이 주류 브라우저가 된 지금, 이미 이러한 어두운 과거로 회귀하는 현상이 조금씩 보이고 있다. 특히 국내가 그런 현상이 심한 편인데, 모노컬쳐를 조장하는 행위다. 이미 엎질러진 물, [3] 이제는 컨텐츠 개발자들이 웹을 지킬 수 밖에 없게 되었다.

닭과 달걀의 문제로 보일 수 있겠지만, 유저 이전에 컨텐츠가 있다. 컨텐츠가 없는 웹 브라우저는 그저 about:blank가 담긴 창이니. 그러니 여러 사람이 이런 문제를 심각하게 받아들이고, 웹이라는 사회의 균형이 더 무너지지는 않게 모두가 신경을 써줘야만 살아남을 수 있다는 걸 이야기하고 싶다.

이제는 새로운 브라우저 엔진이 나오기에 웹은 너무 기능이 많기 때문에 이번에 무너지면 IE 독점 시장 시절과 같은 빙하기를 다시 한번, 이번에는 더욱 길게 경험하게 될꺼라는걸 잊지 말고 [4] 호환성을 지켜줬으면 하는 작은 바램이다.

사실 나의 경우에는 넷스케이프 호환성을 맞출 수 있다는 이유로 틈새 시장의 이득을 보고, 그러한 잡기술이 바탕이 되어 결국 브라우저 회사에 취업을 할 수 있게 되었지만 이건 특수한 케이스라고 생각한다.
단, 국내 정부 관련 서비스나 금융권은 특수 케이스로 예외로 치자. 이것 관련해서는 쓰던 글이 있었는데 시간이 되면 마저 썰을 푸는걸로.
Chromium은 오픈소스 프로젝트이지만, 관리 체계가 상당히 특이하다. 현재 구조에는 개선이 필요한데, 이와 관련해서는 나중에 시간이 허락할때 따로 생각을 좀 정리해볼 예정이다.
특히, 요새는 Polyfill들이 잘 나오니 적극적으로 활용해주면 이게 어렵지 않게 가능하다. Polyfill.io 같은 서비스를 쓰면 브라우저 버전에 맞는 Polyfill을 내려주니 이런 서비스를 적극적으로 이용하자.

The Story of Cynthia

Thu, 18 Jan 2018 00:00:00 GMT

Some have seen my Github username and have wondered why is this dude calling himself Cynthia? Of all things?

So here is the background story. It isn't a very interesting one. If you were expecting me talking about gender identity and what not, this isn't it. (Although I do wonder sometimes if I am a fish. More on that sometime later.)

So if that was what you were looking for - feel free to hit the back button.

Back in 1995, there was a public and free Unix system which one could sign up, login and try well, anything. This was provided by a Korean company that probably had an unused SunOS machine just doing nothing, and one of the employees probably just thought it would be a cool idea.

Back then - stuff like this was fine to do - nowadays, well - you know what would happen to services like this.

(I had already completely destroyed my dad's computer attempting to install Linux with a pile of bad sector polluted floppy disks and a poorly written guide on how to do it - so having a Unix compatible system at home really wasn't an option.)

So it turns out - this free service had a couple limitations - one was that your shell account was limited to 4-8 characters, was case insensitive (requests would be lowercase converted) - and thanks to that little quirk, almost any commonly imaginable English word - including my surname and my name were all taken. (I was at a friend's place - who also happened to have a slightly better modem than I did, and parents who wouldn't go crazy on the phone bill.)

If I roughly remember what we tried - this is the rough list: (Personal information redacted)

moon
sangwhan
moon[birthYYYY]
[birthYYYY]moon
moon[birthmmdd]
[birthmmdd]moon
...and some other ones, can't remember them all.

Then we pulled out a dictionary looking for anything useful under the word "moon", because we ran out of options.

lunar
lunatic: This would have been cool.
...and through the entire list. Which wasn't long.

No avail. However, it turns out that my friend's father was a hard core Christian and even doing a part-time program in graduate school studying related topics - and had an old Korean-Latin dictionary sitting around. So we took that, and went through the list of words that meant "moon".

The first option was diana, which was clearly a feminine name - so we that skipped that one. The next one in the list was cynthia. Little did this dictionary note that it was the goddess of the moon, not just the moon - so I went for that. This wouldn't have happened in 2018, since - Wikipedia. Google. Or well, actual internet.

I have never heard anyone with this name, so little did I know this was feminine [1] - only having limited exposure to the western world. [2]

So, to this day - all of the accounts which are somewhat related to PAM authentication of some form are "cynthia". I don't really have a good excuse - my fingers have been typing that for 22 years and counting, and I'm too lazy to have different account names across different machines.

I learned the lesson about muscle memory the hard way, as my previous employer forced me to use something that resembled my name - "smoon" in this case. Now at my new workplace I am back to cynthia. If I do hire a real Cynthia, then well - sucks to be her.

To give you a rough idea of how reluctant to change I am - my current macOS home directory (on a Retina 2012) is a cumulative migration which started from a Titanium Powerbook G4 in 2002.

[1] There was a gut feeling that this sort of felt feminine, but shit - it was supposed to be Latin, what would I know.

[2] This is probably why "English" names from people of Chinese heritage countries (e.g. Taiwan) around my age have some occasional surprises. My favorite to this day is Piggyboy - who was a customer contact at my previous workplace. I am not making this up.

DIY Finsix Dart Magsafe Tip

Sun, 27 Aug 2017 00:00:00 GMT

NOTA BENE: Following this tutorial will most likely result in voiding multiple warranties across multiple devices. If done incorrectly this may result in extreme consequences - including fires, battery and or charger explosions and overheating, short circuits which can have consequences including burning your house or building down. The author takes no responsibility for damage caused by performing this modification.

Do not use the modified adapter on any 15 inch Macbook device, as the Finsix Dart is unable to provide the required output to sufficiently drive the device.

Please note that the final result of this has not been properly tested with lab equipment. Also note that the output of the Dart is 20VDC, while Magsafe 1 power supplies output 16.5VDC. While I have used a Magsafe 1 connector here (mostly because I had a readily available broken power supply to cut the cable off of), I used a Magsafe 2 converter and have not actually charged a Magsafe 1 device with this. If you plan to charge a Magsafe 1 device, it might be worth double checking if the output voltage is a safe setup or not.

TL:DR; for the experienced: 1) Get compatible connectors from eBay or Amazon (Links below) 2) wire up with a donor Magsafe.

Now that we have gone through that...

The Finsix Dart is a compact charger for laptops which comes a large set of tips that allows you to charge almost any laptop on the market. However, this does not include any Apple devices - mostly due to the legal complications for shipping Magsafe compatible devices. (There are rumors of Magsafe tips that shipped to Kickstarter backers, but I was unable to find any proof that these actually exist as none of them turned up in the used market.)

Parts needed:

Magsafe (1 or 2) cable: You can get these from eBay as repair parts, or cut them off of a broken charger. Cut it roughly 10cm from the charger.
Finsix compatible connectors: Finsix uses a proprietary connector, which is luckily a very simple form factor so finding one that fits isn't too hard. These are mostly sold as "outdoor waterproof LED cables" on either eBay or Aliexpress. Amazon Japan also has these here.
Electric tape: As we are dealing with 20VDC, you absolutely want proper insulation. Don't cheap out on this.
Multimeter: Any cheap multimeter that can test continuity (the "beep" mode) should do.
EMI filters (optional): This isn't strictly necessary, but is a neat trick for hiding electric tape while doing passive filtering. Two birds, one stone. Get one that fits 5mm gauge wire. I used this.
Solder kit (optional): If you want a slightly more secure connection between the two wires, this is strongly recommended.
Wire stripper: Any stripper that can handle small gauge wires should work. I used a Vessel 3500 E-2.
Knife (optional): A standard office paper knife or X-ACTO blade should do.

The Dart uses a connector that looks roughly like the diagram above. It is a circular connector, with one side cut out. This perfectly fits the connector that we are going to use, but as the connector only has a very small ridge to prevent incorrect polarity you need to be careful when connecting it. (Normally, you won't have to do this too often. I use the ridge as a visual indicator for the polarity.)

These LED cable connectors do not come with any standard wire color coding scheme (mind was brown/blue, which makes no sense), so you will need to use a multimeter to find out which one maps to which color, then make sure GND connects to GND on the Magsafe, and VCC maps to VCC.

Normally, if you cut a Magsafe cable - there are two internal cables - one white and one black. Black is GND, which maps to pin 1 and 5, and white is VCC which maps to 2 and 4. 3 is connected to a negotiation chip inside the connector, so there is no wire that corresponds to that pin. If you are using a aftermarket repair cable (e.g. eBay, Aliexpress) the colors may not match the genuine cables, so please test with a multimeter to ensure polarity.

Whatever combination you come up with using a multimeter, strip both sides of the wire around 1cm, connect the two wire pairs, isolate them with a piece of paper so they are not shorted, connect it to the Dart USB cable and test them by checking if pin 1 and 5 on the Magsafe maps to GND on the Dart cable, and 2 and 4 to VCC on the Dart cable.

Depending on the connector you used, you may need to use a shave off a bit of plastic on the compatible connector for a tighter fit.

Test between the two connectors as seen in photo above.

Now that you have everything in place, test continuity between the charger end of the Dart USB cable and the Magsafe pins. Make sure you test these combinations:

Magsafe 1/5 to GND: Should be connected
Magsafe 2/4 to VCC: Should be connected
Magsafe 1/5 to VCC: Should not be connected
Magsafe 2/4 to GND: Should not be connected

All four tests (or all 8 tests) should pass, otherwise something is wrong. If only one of the pin pairs (e.g. pin 1 connects to GND, but 5 does not) check for continuity, then it is most likely you have a broken Magsafe connector, and might want to throw it out.

When all of the tests have passed, either you can solder the wire pairs for stability or just tape it up with electric tape. After you are done, repeat the same continuity tests again and make sure nothing has changed. Mistakes here can happen, so make sure you test for short circuits.

(Optional) When you are done, wrap it up with enough electric tape so the tape thickness roughly matches up with the original Magsafe wire's gauge, then clip on a EMI filter for a more professional look.

Local Debugging of Service Workers

Thu, 17 Aug 2017 00:00:00 GMT

Service workers requires a secure origin to work. For this reason, to debug service workers locally you will need to setup a HTTPS server on your local machine - unfortunately it isn't an entirely straightforward process. Here is a quick and dirty trick to do this.

First, you will need to create a self signed certificate. This can be done using the following command. (Example is valid for 10 years, Do not do this in production. Bad idea.)

openssl req -new -x509 -keyout /usr/local/etc/local-server.pem -out /usr/local/etc/local-server.pem -days 3650 -nodes

Then. you will need to start a local server that uses this certificate and serves HTTPS. The following snippet should be placed in a convenient location for execution, in my case I put it in /usr/local/bin/https-server. Put it wherever works for you, and add a +x bit. This is for Python 2.7. (or near versions.)

#!/usr/bin/python
import BaseHTTPServer, SimpleHTTPServer
import ssl
httpd = BaseHTTPServer.HTTPServer(('localhost', 4443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='/usr/local/etc/local-server.pem', server_side=True)
httpd.serve_forever()

(Note: The HTTP server modules have been moved in Python 3.x, so that will need to be patched.)

Now, go to the directory where you have the SW based application running. For the example of our JavaScript SDK, this will be the root of the checked out repository. Run the https-server script. If you prefer a standard port, you will need to change the line that mentioned 4443 above to 443, and run the server as root. This is not recommended.

The following example only covers Chrome. Other implementations probably involve different tricks for working around certificate validation.

Close all instances of Chrome. (or whatever Chrome based browser you are running) Make sure the root process is completely dead, and not just all the tabs closed. Now, start Chrome with the following flags:

--ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:4443

On macOS, this would normally be:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome  --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:4443

On Linux, this would normally be:

google-chrome  --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:4443

Now, you can go to https://localhost:4443 and debug your service worker locally. When you are done, make sure you shutdown the current browser instance - as the flag overrides are not safe for everyday browsing.

Barnes-Hut t-SNE for CUDA (Linux, Mac)

Thu, 02 Mar 2017 00:00:00 GMT

I recently had to do some large-scale analysis, which was better suited to be run on a GPU. t-SNE is an excellent tool for visualizing data clusters, and those who have found this post via Google probably know what this already is, so I'm not going to go into much detail on the explanation. (The official page is here, with all the details you will need.)

I luckily found some readymade Python bindings, but with extremely limited documentation, and missing key pieces to get this working.

https://github.com/georgedimitriadis/t_sne_bhcuda

Turns out that the binary building part was completely omitted in the repository, so here are pre-built binaries which I made for my own use.

Obviously, this comes with no warranty. If this works for you, good, if it doesn't - you are on your own.

Ubuntu Linux 16.04 (x86_64), CUDA 8.0:

https://static.sangwhan.com/t_sne_bhcuda

macOS 10.10 (x86_64), CUDA 7.5:

https://static.sangwhan.com/t_sne_bhcuda75

Place this into the bin directory of your checkout, and the library should work as expected. (The unfortunate bit is as this relies on a external binary, there is a lot of I/O and lexical casting involved - which I plan to look into someday.)

If the perplexity is too small, it will trip and trigger a assertion with very little useful information to debug the problem. If it doesn't work, try reducing the perplexity. (More on what that is in the official page, link above.)

One thing to note: There is an interesting bug in the implementation's VRAM calculation routine. (which I didn't bother looking into) Setting gpu_mem to a value above 0.9 triggers VRAM OOM. (It seems to think a Titan X has 13.2GBs of memory, based on the actual allocated VRAM and ratio I used.)

I use the binary outside of the Python binding as well, so in my case, I replaced the _find_exe_dir() helper in my site-package installation.

def _find_exe_dir():
    exe_dir = '/usr/local/bin'
    exe_file = 't_sne_bhcuda'

    return path_join(exe_dir, exe_file)

Both binaries are for 64-bit systems.

Example code: (Taken from the original source)

import t_sne_bhcuda.bhtsne_cuda as tsne_bhcuda
import matplotlib.pyplot as plt
import numpy as np

perplexity = 50.0
theta = 0.5
learning_rate = 200.0
iterations = 2000
gpu_mem = 0.8

t_sne_result = tsne_bhcuda.t_sne(samples=data_for_tsne, files_dir='/home/user/wherever', no_dims=2, perplexity=perplexity, eta=learning_rate, theta=theta, iterations=iterations, gpu_mem=gpu_mem, randseed=-1, verbose=2)
t_sne_result = np.transpose(t_sne_result)

fig = plt.figure()
ax = fig.add_subplot(111)
ax.scatter(t_sne_result[0], t_sne_result[1])
plt.show()

Step by step instructions:

Git clone Python bindings repository from Github.
Make bin directory, download binary for your platform and drop it in there with the filename t_sne_bhcuda
Alternatively, use the patch above and drop it into /usr/local/bin, same filename.
Use the example code above.

FreeBSD 에 PowerDNS + MySQL 백엔드 설치, 그리고 오픈소스의 힘과 문제점

Mon, 02 Jan 2017 00:00:00 GMT

전편에 이어. FreeBSD를 사용하는 서버의 궁극적인 목적은 내부 DNS 및 내부 DHCP를 위한것이었다.

Master 와 Slave가 있어 두개가 같은 설정으로 유지되었으면 했다.
DNS의 내장 기능을 이용해도 되겠지만, MySQL의 master-slave replication을 이용하여 한개 노드가 실패할 경우 바로 master로 사용할 수 있게 하고 싶었다.
DHCP는 그냥 pkg에서 설치하면 되는 문제여서 큰 난관이 없었다.

여기서 문제가 하나 발생하게 되는데, FreeBSD pkg repository에 있는 powerdns 패키지에는 MySQL 백엔드가 아닌 Postgres 백엔드만 포함되어 있다는 것이었다.

일반적으로 Postgres를 사용할 줄 아는 경우라면 큰 문제가 되지 않는데, 공교롭게도 사내에서 Postgres를 다뤄본 경험이 있는 사람이 1명 밖에 없어 single point of failure의 위험성이 있었다. 그리하여, MySQL 백엔드를 포함하여 새로 빌드하기로.

설치에 앞서, 의존성이 최근에 추가된게 하나 있어 해당 의존성을 위해 pandoc이라는 문서 프리프로세서의 설치가 필요하다. (이전에 패키지 명칭이 pandoc 이었으니 만약에 아래 명령으로 설치가 안된다면 pandoc 으로 바꿔보면 될 수도 있다.)

pkg install hs-pandoc

컴파일 방법은 공식 문서에 있는 그대로 따라했고, 추가한건 MySQL 백엔드를 활성화 시켜준 것 밖에 없다. 명령은 아래와 같다.

./configure --with-modules="bind gmysql"

우분투의 build-essential에 해당하는것을 설치하고 (이와 관련해서는 이전 글에 설명 되어있으니 참고하면 된다.) 빌드를 진행하는데, 괴상한 컴파일 오류를 경험하게 되었다. (내가 겪었던 컴파일 에러는 터미널 스크롤백의 신들에게 재물로 바쳐졌기 때문에 더 이상 없다. 굳이 해당 refspec을 찾아가서 재현해보기는 귀찮으나, 궁극적으로는 같은 에러이다.)

이 오류의 원인은 대부분의 청중에게 의미가 없을 듯 하여, 이 글에서는 설명하지 않겠다. (명시적으로 생성된 std::string과 묵시적으로 생성된 std::string의 수명과 reference tuple 안에 rvalue를 담을 수 있는가 없는가에 대해 표준의 과도한 해석을 clang에서 하고 있는 문제인데, 더 이야기를 하자면 복잡하니 생략. 내용이 궁금하면 PR을 보면 된다.)

불행 중 다행은 나 말고 이 문제를 겪은 사람이 있다는 것이었고, 적어도 우리 환경에 한정된 문제가 아니었다는 것이다.

추가 (45879fae66a5fbc37d1edf32b2b9337383140d2f 기준): FreeBSD 빌드가 또 망가져버려서, PR#5067의 패치가 필요하고, export CXXFLAGS=-std=c++11을 추가해주어야 한다.

오픈소스의 문제점

여기서 문제는 깃헙에 버그 리포트가 들어간 날짜는 3월 11이었다는 것이고, 내가 이 문제를 겪은것은 10월 3일이었다는 것이다. 1줄 짜리 컴파일 에러 하나를 수정하는데 7달 동안 아무도 손을 대지 않았다는 것이다.

오픈소스의 문제점은 생산을 하는 사람이 소비를 하는 사람보다 월등하게 적다는 것이다. 특히나 난이도 높은 근본 라이브러리일수록 (특히, C/C++일 경우 이 문제가 심각하다) 사람들이 기여를 안하고 쓰기만 한다는 것이다. 문제는 기여를 하는 사람들이 적고, 요구사항을 외치는 유저들만 너무 많아 대응이 안되는 시점에 기여를 하던 사람들도 결국에는 하나씩 번아웃을 하여 오픈소스에 기여하는 것을 포기한다는 것이다.

한 줄짜리 패치 보내면서 생색 내는것 같지만, 이렇게라도 하는 사람이 너무 없는게 현실이다. 다행히도, PowerDNS 커미터들이 내 패치를 빠르게 (하루 걸렸던것으로 기억된다) PR을 반영해주었고, BSD + clang 환경 호환성 문제가 어렵지 않게 해결되었다.

오픈소스를 갖다 쓰지만 말고, 문제가 있으면 문제가 있다고 보고만 하던가 그냥 쉽게 동작하는 다른 라이브러리를 택하는 경우가 많은데 만약에 해결을 할 수 있는 문제면 해결을 해서 기여도 했으면 하는 바램이다.

삭제된 내용

원래 글에는 PowerDNS 설정 관련된 내용도 있었으나, 회사 내에서 PowerDNS를 사용하는 목적이 내부 DNS 및 비표준 내부 TLD를 지원 하기 위한 목적이어서 설정 공유를 하면 혼란만 있을 것 같아 (해당 설정을 그대로 복제하였을 경우 정상적인 DNS 환경이 아닌 특수한 환경으로 설정되어 버리기 때문에), 처음 작성한 내용에서 삭제하였다.

추가된 내용

2017.2.22: Pandoc 의존성 관련 내용 추가.

Ubuntu Server에 익숙한 유저를 위한 FreeBSD 기본 설정

Tue, 04 Oct 2016 00:00:00 GMT

회사에서 이전까지 내부 테스트 서버 등을 접속하기 위해서 mDNS (Bonjour)를 이용하다가, 안정성 문제나 broadcast 노이즈 등이 너무 많고, 서브넷을 분리할 생각에 내부 DNS를 구축하기로 하였다. 새로 아주 저사양 서버를 2대 구입하여, DNS를 거기에 넣기로 하였는데, 간혈적으로 재부팅시 부팅이 완료되지 않는 어이없는 systemd 버그를 겪게 되어 초기 세팅 후 장기적인 안정성 문제에 대해서 걱정이 들기 시작하였다.

해당 버그는 수정이 된 상태이나, 부팅을 담당하는 모듈이 부팅을 완료하지 못하는 버그가 있는 상태에서 릴리즈가 되었다는 것 자체에 대해서 신뢰도의 문제가 있어, 일단은 당분간은 사내에 systemd를 사용하는 배포판의 도입은 미루는 것으로 하고, 그 사이에 대책을 조금 고민하다 systemd와 연이 있을래야 있을 수 없는 BSD를 사용하기로 하였다. (아울러 개인적으로 Lennart Poettering의 철학과 동의하지 않는다. 이건 어디까지나 사족이지만...)

여러가지를 검토하다 (DragonflyBSD를 특히 유심히 보았다) 결국은 해본적이 있는 FreeBSD로 결정을 하였는데, 오랫만에 해보니 (마지막으로 양산에서 썼던게 4.x대였던걸로 기억된다.) 저쪽 환경에 너무 익숙해져버려 불편한 점이 한두가지가 아니었다. 그래서 조금 환경을 비슷하게 맞추는 과정의 기록을 남기기로.

FreeBSD는 apt-get이나 yum이 없고, 자체 패키지 매니져를 사용한다. ports와 pkg 두 가지 중에서 선택을 할 수 있는데, 전자는 소스 빌드라고 생각하면 되고 후자는 빌드 된 바이너리를 사용한다. 배포 대상 하드웨어가 흔해빠진 인텔이어서, 아래 예시에는 시간 절약을 위해 후자를 사용하였다. 이전에 양산때에는 서버가 DEC Alpha여서 포트로 다 빌드를 했던 (좋지 않은) 기억이 있다.

설치 자체는 인스톨러를 사용할 경우 크게 어려움이 없으니 설명을 생략하고, 환경을 조금이나마 근대적인 환경으로 사용할 수 있도록 하는 방법을 공유하면 도움이 될 사람이 있을까 싶어 문서화. (이 서버들의 경우에는 ZFS 전체 디스크 사용으로 자동 설정, 나머지는 거의 기본 설정, 단 games 메타 패키지는 뺐다.)

한 가지 주의할 점이 있다면, 서버 목적이라면 설치 과정 중 사용자 계정 추가시 관리자는 wheel 그룹에 넣어주는게 좋다는 것 정도가 되겠다. OpenSSH 설치 기본 옵션에 root 로그인이 금지되어 있는데, wheel 그룹에 넣어줘야 su가 된다. (FreeBSD는 기본 배포시 sudo가 없다. 필요하면 설치해서 사용해야한다.) 이걸 까먹으면 이후에 물리적으로 서버에 가서 작업을 한번 해줘야하는 문제가 발생하니 주의하도록 하자.

개인적으로 사용중인 노트북 모니터가 작아서, motd가 보지 않을 내용이 너무 많이 표시되어 빈 내용으로 삭제.

mv /etc/motd /etc/motd.bak
touch /etc/motd

FreeBSD에는 설치시 컴파일러가 (10.x 설치시 LLVM 3.7이 깔려있다.) 따라오나 build-essential에 해당되는 메타패키지가 없어 이걸 알아서 조립을 해야한다. 아래가 그것.

pkg install autoconf automake devel/pkgconf libtool bison gmake ragel devel/boost-all git

이 중에서 매우 중요한것이 gmake이다. FreeBSD는 자체적인 make를 포함하여 배포를 하는데, GNU Make와 호환이 되지 않기 때문에 상당수 오픈 소스 프로젝트가 빌드가 되지 않는다. 마지막 2개는 나의 경우에는 필요했는데, 필요하지 않을 경우에는 생략하여도 된다.

상당수 오픈소스 프로젝트는 Makefile내에 게으르게 gcc/g++를 쓰도록 하드 코딩 되어있다. 컴파일러가 깔려있는 마당에 굳이 GNU Compiler를 설치할 의미는 없는듯 하여, 이 부분은 macOS에서 애플이 사용하는 꼼수를 사용하였다.

# 이런 짓 자주 하면 지옥 간다.
ln -s /usr/local/llvm37/bin/clang /usr/local/bin/gcc
ln -s /usr/local/llvm37/bin/clang++ /usr/local/bin/g++

사용하는 FreeBSD 버전에 따라 /usr/local/llvm[0-9]+ 에서 사용하고 싶은 버전을 찾아서 써주면 된다.

마지막으로, FreeBSD는 기본으로 쉘로 csh를, 기본 에디터로 BSD vi를 사용하는데, 상당 수 프로젝트들이 (아울러 사내 프로젝트들) bashism이 심하고, BSD vi의 기능상 제약이 많아 전역 bash 설정의 alias 레벨에서 바꾸었다. 아울러 make도 gmake로 alias. bash 사용자에만 해당되지만, rootfs를 손상시키지 않고 익숙한 환경을 유지할 수가 있는 편법이다.

/etc/profile 하단에 아래 내용 추가

if [ "$PS1" ]; then
  if [ "$BASH" ] && [ "$BASH" != "/bin/sh" ]; then
    . /etc/bash.bashrc
  fi
fi

/etc/bash.bashrc 작성

# Better prompt for both normal and sudo
PS1='[\u@\h \W]\$ '
SUDO_PS1='[\u@\h \W]\$ '

export TERM=xterm-color
export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad

# BSD ls uses a different parameter for colorization
alias ls="ls -G"
alias l="ls -lG"
alias ll="ls -lGa"
alias vi="vim"
# BSD make isn't particularly useful, so replace that with gmake
alias make="gmake"

BSD ls의 경우는 색상 표시를 위한 옵션이 다르다. BSD에서 제공하는 coreutils에 해당되는 명령의 경우 GNU에 비해서 기능이 없거나, 사용 방법이 달라 불편함이 있을 수 있다. GNU에만 있는 기능들이 필요할 경우, sysutils/coreutils를 설치하면 된다. (현재 작업중인 배포 환경에는 디스크 용량 절약을 위해 coreutils설치를 하지 않았다.)

PowerDNS 설치법은 다음 글에.

잘 알려지지 않은 Python REPL - ptpython

Wed, 17 Aug 2016 00:00:00 GMT

입력 히스토리는 업무와 관련된 대외비 코드가 있어 초기화 하였다.

최근에 NLP 처리 관련 ML 작업을 조금 하고 있는데, training iteration을 조금 더 단순화 하기 위해서 코드를 매번 바꾸는 형식 아니라 웹이나 CLI로 만들어서 고민하던 중 CLI를 만들어볼까 하다가 발견한 python-prompt-toolkit 이라는 페이지에서 우연히 발견하였다.

설치에 큰 노력이 들지 않아 설치해봤는데, 이게 꽤 물건이다. iPython을 버려도 될 정도로 훌륭하다. Quicksilver에서 Alfred로 넘어갔을때 처럼 30분 써보고 바로 결정하는 일이 잘 없는데, 이게 딱 그 경우.

이렇게 여러가지 설정도 제공하고, iPython 처럼 사용도 가능하다.

오류가 발생하면 구문 에러를 출력하고 위치를 알려주는게 아니라, 구문 에러가 나는 곳으로 커서가 이동이 된다.

vi 식으로 코드 편집도 가능해서, u를 이용해서 NAV 모드에서 입력 취소도 가능하다. 위 스크린샷은 Esc, Esc, w, w, cw, ;, Space로 오류를 보정한 모습.

히스토리 화면에서 전에 입력했던 이력을 짜집기해서 프로그램을 만들 수도 있다. 이건 꽤나 괜찮은 듯. 기능을 좀 더 확인해봐야겠지만, 왜 더 알려지지 않았는지 신기할 정도로 훌륭한 REPL이다.

아쉬운 점은, 자동 완성이 iPython에서 개선된것 같지는 않다. 동일한 버그(?)들이 있다. (그래도 Jupyter 보다야...)

외부 미디어 연결시 Photos.app 자동 실행 막기

Tue, 16 Aug 2016 00:00:00 GMT

애플의 어떤 팀에서 이 정신 나간 아이디어를 냈는지는 모르겠지만, Yosemite 부터 무슨 장치만 연결하면 Photos.app이 실행되는, 설정 UI로는 끌수도 없는 기능이 있다. (개별 장치에 대해서만 끌 수 있다.)

위 스샷이 문제의

Photos.app

다행히도, 아래 명령으로 모든 장치에 대해서 영원히 이 기능을 꺼버릴 수 있다.

defaults -currentHost write com.apple.ImageCapture disableHotPlug -bool YES

iTerm2 로 터미널에서 이미지 보기

Thu, 21 Jul 2016 00:00:00 GMT

비교적 최근 버전에 추가된 기능인데, iTerm2를 이용하여 터미널에서 이미지를 볼 수 있는 요긴한 기능이 추가된것을 오늘 알았다. 업무상 이미지를 볼 일이 많다 보니, 앞으로 꽤 유용하게 사용할 수 있는 기능으로 보인다.

또는 아래 명령 (iTerm 3.0.5 기준으로는 유효하나, 이후에 바뀔 수 있다) 를 복사해서 붙여넣으면 된다.

curl -L https://iterm2.com/misc/install_shell_integration_and_utilities.sh | bash

로컬에 있는 파일을 볼때는

imgcat 파일명

식으로 보면 되는데, 더 요긴한건 파이프가 지원이 된다. 단적인 예로,

curl https://stdio.sangwhan.com/content/images/2016/07/Screen-Shot-2016-07-21-at-7-49-58-PM.png | imgcat

를 하면 아래와 같이 나온다. (이미지는 때마침 링크가 있어 블로그 글 이미지를 그대로 사용하였다.)

Slack을 3개월간 써본 단상

Tue, 01 Mar 2016 00:00:00 GMT

지금 일하는 곳에서 약 3개월 전에 슬랙을 도입하였다. 처음에 몇주 정도 무료로 써보고, integration 의존성이 높아지고 과거 대화 검색이 필요해지면서 결국 유료로 전향.

이전에 사용하던것은 Skype. 전반적으로는 문제가 없었으나, 다소 신경쓰이는 문제들이 있었는데:

모바일 클라이언트가 배터리를 너무 많이 먹는다.
데스크탑에서는 P2P 네트워크의 bridge node로 기본으로 사용하기 때문에, 테더링할때 안끄면 후회할 일이 발생한다.
상대가 오프라인일때 메시지를 보내고 내가 오프라인이 되면, 상대방이 이후 먼저 온라인이 되더라도 내가 온라인이 될때까지 메시지 전달이 되지 않는다. (단, 그룹 대화방의 경우는 그 메시지를 수신한 사람이 한명이라도 있고 온라인일 경우에는 전달이 된다.)
파일 보낸건 그때 바로 안받으면 못받는다고 보면 된다.
파일 전송 속도의 편차가 심하고, 공공 네트워크 같은 곳 (예를 들면, 스타벅스 Wifi) 에서 승인 handshake시 간혈적으로 말썽이 난다.
대화록이 로컬에 저장되기 때문에 (보안 측면에서는 이 부분이 나쁘다고 할 수 없으나, 대화록 백업을 정상적인 방법으로는 못하고 export도 안된다) PC가 바뀔 경우 과거 대화 검색이 불가능하다.
그 외 사소한것으로는 간혈적인 이중 푸시 노티 문제, 로그아웃 후 마지막 로그인했던 아이디의 푸시가 오는 문제. (...이건 사소하지는 않다. iOS에서 발생하는 문제이며, Android는 해당이 없는 듯 하다.)

이러한 문제 등으로 IRC (via IRCCloud), Campfire 등을 시도하였는데 여러가지로 반응이 좋지 않아 (사용률이 대단히 저조했다) 결국에는 서비스를 중단하고 (자체 IRC 서버를 운영했었다) 다시 Skype를 복귀를 했다가, 최근에 많이들 사용하는 Slack을 시도해보기로 하였다.

다른 후보들도 있었다.

IRC / IRCCloud: 도입 실패 이력이 있어 스킵.
Campfire: 도입 실패 이력이 있어 스킵.
Hipchat: 지금 다니는 대학원에서 사용중. UX가 일단 상당히 별로고, Atlassian ID 또는 Bitbucket ID가 이미 있을 경우 골아픈 인증시스템 버그 때문에 고생한 적이 있어 일단 배제해버렸다. 장점은 (유료 플랜에 한하여) 영상 통화나 화면 공유가 되는데, 이게 얼마나 잘되는지는 시도해보지 않아 모르겠다. (JIRA cloud 성능을 생각하면, 서버 중개식으로 Atlassian 서버를 경유한다면 서비스 품질에 대해서 조금 걱정이 되기는 한다.)
잔디: 파일 공유가 메인 기능이고, Integration이 구글 위주라 패스.
Zulip: 무료로 사용이 가능하고, 이런 저런 측면에서 꽤 강력한 후보였으나 공교롭게도 도입 검토 시점에는 모바일 클라이언트가 제대로 빌드가 안되었다.

우선, 도입시도시에는 예외없이 전원 전향하고 Skype를 버리는 형태로 했는데, 전환은 꽤 매끄럽게 되었고, 사용률도 매우 높았다. (역시 UI가 이쁘고 봐야한다.) 지금 도입 만족도가 높고, 상당량의 커뮤니케이션이 그 안에서 발생한다. 대외 커뮤니케이션이나 기록이 확실히 남아야하는 경우에는 아직도 메일을 사용하고, 그 외 상당량 커뮤니케이션은 기록 없이 구두로 발생한다. 후자는 원격 근무자 밖에 없는 회사를 차리지 않는 이상은, 한국 사람 특성상 없어지기는 어려울 듯.

잘 나가는 애들 다들 쓴다니까 사람들이 반응이 좋았던것일지도 모른다는 생각이 조심스럽게 들기는 했다. 심지어 최근에 구글 안에서도 슬랙을 사용하는 팀이 있다 한다.

일단 슬랙의 가장 큰 장점은 Bot을 직접 짜거나 하지 않더라도 바로 사용할 수 있는 integration이 많다는 것이다. 현재 사용중인 App은 10개, 그 안에 integration은 정확히 모르겠으나, 꽤 많다. 자체적으로 Bot을 돌리고 있는것들도 있다. 최근에는 한잔씩 내릴 수 있는 기계를 사서 안쓰이지만, 이전에 아침에 커피 당번도 Slack Bot으로 정했었다. (사실은 불과 3주전까지의 이야기이다. 사실 커피는 핑계였고, 신입 직원에게 load balancer에서 사용할 queueing 알고리즘을 고민시키기 위함이었다.)

현재 업무 지원 용도로는 다음 기능들을 사용하고 있다.

서비스 장애/오류/관리자 손길이 필요한 상황 보고
스토리지 장비 오류 보고
Teamcity Continuous Integration
JIRA
Trello (지금은 대부분 JIRA로 넘어갔다.)
Google Calendar로 일정/휴가 관리 및 reminder

일단은 작은 회사인 만큼 한 사람이 한가지 일만 하지는 않는다. 슬랙 덕분에 내부에서 일어나는것 상당량을 모두가 관련 채널에 들어가 있으면 알 수 있다는건 공개성 측면에서 긍정적인 효과를 볼 수 있었다. 커지면 어떨지는 겪어봐야 알 듯.

simple-slack-api 라는것을 이용하여 기본적인 골격은 정말 금방 만들 수 있었다. 이전에 TCL로 Eggdrop 삽질 하던 시절 생각하면 세상 참 좋아진 것 같다. (예제는 Kotlin이나, 실제 운영중인 bot은 그냥 Java이다.)

package com.oddconcepts.coffeebot
import com.ullink.slack.simpleslackapi.impl.SlackSessionFactory

fun main(args: Array<String>) {
    val session = SlackSessionFactory.createWebSocketSlackSession(kKey);
    session.connect();
    session.addMessagePostedListener({ posted, session ->
        if (posted.sender.userName == kUserName)
            session.sendMessage(posted.channel, "Testing", null);
    });
}

지금까지 장점을 좀 정리하자면:

Integration이 기본 지원되는게 많아 그냥 폼 몇개 채우는거만으로 서비스 연계가 가능하다.
시스템이 통보를 해줘야하는데 담당자 한명만 이 내용을 알고 있는 환경을 전원 공유 환경으로 오픈된 업무 문화를 만들 수 있다. (이건 조직 규모에 따라 적절하게 사용하기 나름이지만.)
Bot 개발이 편하다.
UI가 다른 엔터프라이즈 메시징 서비스에 비해서는 다가가기 쉽다.
중개 서버가 있어 대화창에서 파일 공유가 매우 안정적으로 된다.

정도가 될 것 같다.

장점을 이야기했으니, 이제는 단점. 모든게 완벽할 수는 없으니 이 부분에 대해서는 확실히 짚고 넘어갈 필요가 있다.

우선, 가장 큰 문제. 데스크탑 클라이언트의 전반적인 퍼포먼스 문제왜 배터리 소모량 문제는 근시일 내에 해결되지 않으면 서비스의 실패 요인이 될 수 있을 정도로 심각하다. 만약에 전부 네이티브로 해결을 보고 기능상 동일한 수준을 제공하는 서비스가 나온다면 시장을 꽤 뺏어갈 수 있지 않을까 싶을 정도. 카페 근무시에는 아예 클라이언트를 꺼두고 모바일 푸시만 보면서 일할 정도로 배터리 수명에 지장을 준다.

브라우저 기반이라서는 사실 Slack의 사정이고, 이 부분은 절실하게 개선이 필요하다.

(위에서 Safari가 가장 많이 차지하고 있는 이유는 이 글을 사파리에서 작성하고 있기 때문이다. 슬랙은 사용하지도 않았다.)

그리고 구글을 제외한 대부분 외국 서비스에 공통되는 문제이나, 한글 검색이 상당히 문제가 있고 아울러 영어 검색도 딱히 좋지는 않다. 과거 대화록 검색에서 결국 원하던것을 찾지 못하여 스크롤로 찾은 적이 제법 있었으니, 검색은 사실상 포기하는게 나을수도 있다. (이건 Confluence나 JIRA 같은 경우에도 해당되는 문제이다)

Snippet (Command+엔터로 긴 글 붙여넣기) 처리가 상당히 느리다. 만약에 빌드 로그 같은걸 붙여넣을 경우 그걸 불러올때 클라이언트가 멈추는 수준으로 느려졌다가 간신히 표시된다는 느낌을 받았는데, 매번 다운로드를 받아서 봐야하는 불편함이 있다.

IFTTT인테그레이션에 의존한다면 그냥 잊고 사는게 편하다. 처음에 두번 정도 동작하고 그 뒤로는 동작하는 것을 본 적이 없다. 이게 업무상 중요한 기능이 아닌지라 (텀블러 연동) IFTTT의 문제인지 Slack의 문제인지는 확인해보지 않았으나, 엔드유저 입장에서 봤을때는 그 문제가 어디 있는지는 사실 관심이 없다. 된다 안된다에만 관심이 있는데, 경험상으로는 안된다.

비싸다. 우리 같은 경우 사람 수가 적어 크게 부담되는 금액은 아니지만, 메신저 주제에 Google Apps for Work보다 높은 금액을 지불해야하는건 사실 가격대 성능비가 좋다고 할 수는 없다. 100명 있는 조직이라고 하면, 1년에 메신저 사용료가 1000만원이라는 이야기다. 아주 큰 돈은 아니지만, 다른 무료 대안이 있는걸 감안했을때는 분명히 부담되는 비용.

단축키가 희한하고 (OS 표준하고는 좀 안맞는다) 커스터마이징이 안된다. 나의 경우, Command + Alt + 방향키와 Command + Shift + []를 사용하는 툴 대부분에서 굉장히 많이 사용한다. 문제는, 이게 동작하는 방식이 슬랙에서는 굉장히 이상한데 (특히 Command + Alt + 방향키) 원하는 기능의 단축키는 Alt + 위/아래 이다.

다조직을 사용하는 경우, 인증 시스템이 상당히 야리꾸리하다. 어차피 같은 백엔드일텐데, 같은 메일 주소, 허나 다른 비밀번호로 다른 조직 2개에 가입이 가능하다. 유저 매핑상 조직 가입 여부만 기록해두면 될 것 같은데 굳이 이런 형태로 구현한 이유에 대해서는 조금 이해가 안되는 점은 있다.

그리고 마지막으로, 개인적인 취향의 문제이지만 테마 기능이 상당히 미흡하다. 사이드바 색깔은 변경할 수 있으나, 눈이 아파서 어두운 배경을 선호하는 사람한테는 쥐약이다. 이걸 해결하는 방법은 Greasemonkey 스크립트 같은걸 이용하는 것인데, 이것 마저도 커스텀 MacGap 기반인 맥 버전에서는 사용할 수 없다. 사실 사이드바만 색상 변경 가능한건 무슨 의미인가 싶기도 하다.

사용할지 말지는 어디까지나 팀의 성향과 커뮤니케이션 스타일, 그리고 특히 타 서비스와 연동의 필요성에 따라 달려있는것 같다. 완벽하지는 않지만, 성향이 맞다면 써볼 만한 툴.

쓸데없는 사실: Slack 백엔드 스택의 상당량은 PHP(?!)임. 쓸데없는 사실2: 구글 인증 Slack 조직에 가입했다가 해당 구글 계정에 대한 권한을 상실하면 클라이언트에서 로그아웃이 영원히 불가능한 버그가 있다.

지극히 개인적인 이어폰/헤드폰 리뷰 (고가편)

Fri, 27 Nov 2015 00:00:00 GMT

저가 중에서 지금 아직 배송중인 제품이 두개 있어서 일단은 고가만 따로 찢어서 먼저 작성해보았다. 여기에 있는 제품 상당수는 기혼자의 경우 허락을 받지 않고 구매했다가 쳐맞을 가능성이 있는 가격대를 갖고 있는 제품이 좀 있으므로 주의가 필요하다.

별점은 소리 외 실용성까지 포함되었으므로 소리에 대해서만 보고 싶으면 측정 결과를 보는 것을 추천한다.

Audio Technica ATH-M50(X)

이미지 출처: http://www.audio-technica.com/cms/headphones/99aff89488ddd6b1/

별점: ★★★★☆
가격: 25만원 전후.
휴대 가능: 임페던스가 낮고, 접이식이라 기술적으로는 가능하다.

Over-the-ear 헤드폰. (크다라고 해석하면 된다.) 오디오 테크니카 제품은 저가형과 적당히 가격이 나가는 제품하고 차이가 많이 난다. M50 정도까지 올라가는 시점부터 괜찮은 소리를 경험할 수 있다. M50은 사실 단종되었고, 이전에 케이블 교환이 불가능했던 M50 제품에 케이블 탈착이 가능하게 하면서 가격을 좀 (많이) 올린 M50X라는 모델이 현재 유통중이다. 소리 자체는 기존 M50하고 같으니 거치형으로 사용할 예정이고, 선을 잘 관리할 수 있으면 M50 중고를 사도 된다. 이동하면서 사용할 예정일 경우, M50은 풀린 선은 인질 납치하고 묶을 정도의 선 길이를 자랑하고, 꼬인선은 선 무게가 느껴지는 단점이 있으니, 자금의 여유가 된다면 M50X를 사는게 좋다. 필요한 선 길이로 하나 사서 바꿔끼면 되니. 개인적으로는 이상하게도 꼬인선이 2000엔 쌌기 때문에 M50 꼬인선을 사용한다.

소리는 저음이 살짝 강한 강한 감이 있지만, 단순 모니터가 아닌 청음 겸용으로 사용한다면 크게 문제가 안되고 그래도 비교적 균형감이 있는 소리가 나오는 제품. 기본으로 달려있는 이어패드는 여름에 땀이 굉장히 많이 찬다는 단점과 (순정품으로 나오는 Velour 소재의 별매 이어패드가 있는데, 이것도 마찬가지로 땀이 찬다. 게다가 땀을 흡수까지 하기 때문에 나중에 냄새가 날 우려도 있다.) 헤드밴드가 다소 무겁고 둔하기 때문에 착용시에 무게감이 좀 있다는게 사용자에 따라 장점도 단점도 될 수 있다. 크기하고 헤드밴드 디자인 때문에 덕분에 별점 하나 뺐다.

미국이나 일본에서 살 수 있으면 싸게 살 수 있으니 만약에 그렇게 살 수 있는 경로가 있다면 가성비 면에서 이 제품 만한 제품 찾기가 쉽지는 않을 것이다. 아울러 오디오 테크니카는 어느 정도 수준이 되는 제품부터는 외주 생산이 아니라 자체 운영하는 대만 공장이나 일본 공장에서 생산하므로, 여기서 생산하는 제품의 품질은 믿을만 하다.

장시간 착용해도 피로하지 않고, 밸런스가 좋은 소리를 내주는 만큼 듣는데 지치거나 하지 않는다. 가격도 그럭저럭 무난한 편이고, 꽤 튼튼하기 때문에 업무용 헤드폰으로 추천. 접이식이긴 하지만, 접어도 사이즈가 상당히 크기 때문에 이동용으로는 조금 애매한 감이 있다. (이 정도 소리를 내주는 헤드폰 중에 이 정도로 38옴 수준으로 임피던스가 낮은게 없어서 조금만 더 작았으면 매우 훌륭한 이동용이 되었을텐데 하는 아쉬움이 있다.) 마지막으로 측정 결과는 여기에.

Bang and Olufsen 3I

이미지 출처: http://www.beoplay.com/products/beoplayearset3

별점: ★★★★★
가격: 30만원 전후.
휴대 가능: 가능.

위험한 가격대의 디자이너 오디오 제품을 많이 만드는 덴마크 회사의 귀에 거는 이어폰. 이 회사 거치형 오디오 제품은 허락 없이 세트 구성했다가 일방적인 이혼 통보 등을 경험할 수 있으나, 다행히도 휴대용은 그 정도의 가격은 아니다. 아쉬운 점이라면 현재는 모든 이어폰/헤드폰 제품을 그곳에서 만든다는 것. 아울러 한국내 취급점이 적어보인다. 그렇다고 해도 이어폰 치고는 비싸다.

A8에 아이폰용 마이크/리모콘을 단 제품이다. 잘 알고 있을 A8 제품하고 같은 소리가 난다고 나는 확신하나, 몇몇 세력들이 아니라는 평이 있다. 왼쪽 귀에 A8, 오른쪽 귀에 3I를 끼고 같은 소스로 들어본 결과 같은 드라이버라고 적어도 나는 결론을 내렸다. 판단은 알아서. 어차피 A8은 지금 신품 구하기 어려우니 특별히 4극 플러그를 사용할때 말썽을 부리는 기기를 쓰지 않는 이상 이걸 사는게 맞다.

당연한 이야기이지만, 커널형보다는 소리가 시원하다. 솜을 사용하지 않으면 착용감도 애매하고, 그에 따라서 소리 균형이 좀 안좋다. 솜을 사용하면 확실히 저음쪽에 좀 편향된다는 느낌이 있으나, 그래도 다른 이어폰에 솜을 사용하는 것 보다는 훨씬 균형감이 있다. 착용감도 굉장히 좋은데, 안경을 끼는 사람은 귀에 거는게 두개가 되어서 애매할 수 있다. (직접 해본 결과, 애매하다. 안경 끼는 사람이면 별점 하나 빼는게 맞다.) 사소한 장점이지만, 예쁘다.

하우징 모양 특성상 솜을 잘못 끼면 나도 모르는 사이에 빠지기가 쉽다. (케이스에 넣었다가 빼거나 할때 빠지고 그런 일이 많다.) 싸구려 솜을 아예 여러 세트 사서 들고 다니는걸 추천. 케이스가 예쁘나 사용이 불편해서 (써보면 알 수 있다...) Brainwavz제 하드케이스에 넣어 갖고 다닌다. 공교롭게도 3I는 측정이 없으나, 같은 드라이버인 A8의 측정 결과는 여기에 있다.

Beyerdynamic DT1350

이미지 출처: http://tascam.jp/product/dt_1350/

별점: ★★★★☆
가격: 40만원 전후.
휴대 가능: 임페던스가 80Ω으로 높은 편이나 의외로 앰프 없어도 무난히 구동 가능. 있는 편이 좋으니 실제로 휴대할지는 본인 판단. 일단은 가능.

이 글에 있는 유일한 On-ear 헤드폰. (작다라고 해석하면 된다. 유사한 형태로는 젠하이저 PX100/PX200, Koss의 포타프로 같은 제품의 형태를 생각하면 된다.) 1937년에 최초의 다이나믹 헤드폰 DT48 (여담이지만 이 제품은 2012년까지 무려 75년 동안 생산했다) 처음으로 만든 역사와 전통이 있는 바이어다이나믹에서 새로 내놓은 Tesla 라인 중에서 저가 제품 중 하나이다. (최상위 제품인 T1은 100만원 넘어간다.)

저음에 치우친 성향이 있는 T50p/T51p와 달리, 레퍼런스 성향이 강한, 어찌보면 심심한 소리라고 생각될 수 있는 제품이다. M50X은 재미가 좀 있는 대신 저음 편향이 좀 심한데, DT1350은 전혀 편향되지 않은 소리를 즐길 수 있다. 장시간 착용해도 불편하지 않고, 아무래도 얼굴을 덮는 면적이 적은 만큼 땀도 상대적으로 덜 찬다. 헨드밴드도 가볍고, 접이가 되지는 않으나 기본 사이즈가 작기 때문에 휴대하기에 다른 헤드폰보다 수월하다. (물론, 포타프로처럼 손바닥에 들어갈 사이즈로 접히지는 않는다.) 개인적으로는 갈라지는 헤드밴드 디자인이 좋은데, 이건 호불호가 갈리는것 같다. 크기가 작기 때문에 이동용으로 사용하기 좋고, 예쁘지 않은 디자인이 대부분인 바이어다이나믹 라인업치고는 디자인이 예쁘다. (헤드폰 애호가들은 못느끼는것 중 하나가, 풀사이즈 over-the-ear를 차고 거리를 돌아다니는게 어울리는 사람은 거의 없다는거다. 게다가 DT990 같은 디자인은 아무리 예쁘고 잘생긴 연애인이라도 단박에 덕밍아웃 된다.)

소스랑 연결하는 선이 어째서인지 왼쪽에 달린건 한가지 단점. 상당수 사람들이 오른손 잡이이고, 오른쪽 주머니에 소스를 넣고 다니는걸 감안하면 좀 이해가 안되나, 대칭형이니 그냥 거꾸로 하면 된다. (inverse stereo로 듣는다고 이상해지는 음악은 거의 없다.) 교체도 안되는데 선이 매우 길기 때문에 선을 묶고 다녀야하는 점과, 임피던스가 80옴으로 비교적 높다는게 휴대하는데 다른 이유로는 완벽할 수도 있었던 제품을 깎아내리는 점이 약간 아쉬워서 별점 하나 빠졌다.

Etymotic Research ER4-PT

이미지 출처: http://www.etymotic.com/consumer/earphones/er4.html

별점: ★★★★★
가격: 40만원 전후.
휴대 가능: 가능.

커스텀의 영역으로 들어가지 않는 IEM중에서는 개인적으로 본좌급 제품. 싱글 BA라는걸 갖고 많이 까이지만, 개인적으로는 싱글로도 이 정도 소리를 내면 굳이 멀티 BA로 갈 필요가 있나 라는 생각이 든다. 여기서 소개한 제품 중에서 가장 철저한 QC 과정을 거치는 제품으로, 구매시 박스 안에 채널 균형하고 FR 측정한 결과를 같이 넣어주고, 해당 서류에 검수를 한 사람의 인증 서명이 들어가 있다. 혹시라도 채널 균형이 안맞거나 하면 에티모틱사에 보내면 수리/보정 후 다시 받을 수 있다.

ER4-PT와 ER4P는 기본적으로 이어폰 자체는 같은 제품이다. 차이는 위에 검수를 한 인증서와 ER4S 변환 케이블, 별로 쓸 일 없는 비행기용 어댑터가 들어있다는 차이 정도이다. 그 중에서 ER4S 케이블 정도는 원래 가격이 좀 있는 물건이라 (내용물 자체는, 사실 그냥 저항 2개다.) 꽤 큰 플러스이다. 아울러 FR 특성 자체도 ER4S가 더 좋기 때문에, 앰프 사용시에는 반갑게 사용할 수 있다. (다른 용도가 딱히 없어서, 나 같은 경우는 변환 케이블을 그냥 앰프에 꼽아두었다.) 거치용 ER4S와 휴대용 ER4P를 한번에 사는 격이니 이건 확실히 이득이다. ER4B도 직접 회로를 짜면 시뮬레이션은 가능하나, Binaural 오디오 이외에는 용도가 다소 애매하니 굳이 신경을 안써도 되겠다.

추가적으로, Etymotic의 고객 지원은 매우 좋기 때문에 기본적으로 먹고 들어가는 점수가 있다. (음향쪽에서는 최강의 고객 지원을 자랑하는 Koss 다음 정도라고 개인적으로 생각한다. 다만, Koss는 보증 기한이 무제한이라는 무시 못할 강점이 있다.) 고객 지원을 외주 센터에 주지 않고 전량 본사에서 직접 운영하기 때문에 문제점이 있어서 질의를 하면 뇌가 달린 사람이 대답을 해준다는 장점이 있다. 아울러 보증 기간 내에 있는 제품이 문제가 생겼을 경우에는 자세한 내용 묻지 않고 전체 무상 교환이 들어간다. (경험상 살짝 넘어간 것도 받았다. 너무 남용하지는 말자.)

단점. 3-flange 이어팁에 대해서 호불호가 굉장히 갈린다. 혹자들은 산낙지를 고막에 붙여놓은 듯한 고통을 호소하고, 혹자들은 훌륭한 차음성을 찬양한다. 교체를 자주 해줘야하는게 조금 문제이지만, 전자에 해당하는 사람이라면 연탄 이어팁을 사용하면 된다. (번들된 다른 폼팁은 소리 특성이 많이 바뀌기 때문에 추천하지 않는다.) 마지막으로, 레퍼런스 성향이 강한 제품인 만큼 소리가 균형 있지만 매우 심심하고, 특히 베이스가 중후한 소리를 좋아하는 사람한테는 좀 아쉬울 수 있다. 싱글 BA라고 많이 까이는데, 이 부분에 대해서는 본인이 판달 할 몫. 마지막으로 사소한 불평이지만 이어폰 주제에 선이 좀 길다.

Phonak PFE232

이미지 출처: http://www.amazon.com/Audeo-PFE-232-Perfect-Earphones/dp/B006GAERYS

별점: ★★★★☆
가격: 단종 제품. 50만원 전후. (정가는 70만원대. 포낙이 접으면서 가격 내려감.)
휴대 가능: 가능. 단, 이어폰 치고는 임페던스가 높다.

본업은 보청기회사에서 잠시 미쳐서 내고 접었던 Audeo라는 이어폰 브랜드의 최상위 제품군. 단종이 되기 전에 사운드캣에서 69.9만원이라는 살인적인 가격에 판매를 한 제품인 만큼 잘 팔리지는 않은 것으로 알고 있다. 이런 가격을 자랑하지만, 듀얼 BA라는 어찌보면 조금은 아쉬운 스펙을 갖고 있는데, Sonion제 BA를 사용하는 다른 PFE제품군과는 달리 Knowles제로 저음 대역을 위해서 EF-31264-000를, 고음 대역은 ED-23619를 크로스오버해서 사용하고 있다. 할인 가격을 감안해도 비싸기 때문에 별점 하나 빠진다.

PFE0xx나 PFE1xx의 상위 기종인 만큼 소리의 특색이 비슷할꺼라 기대하면 오산이다. 개인적인 소견으로는 굉장히 다른 성향의 소리를 내주는 제품으로, BA 제조사나 구성을 감안하면 충분히 있을 수 있는 일이다. 소리는 굳이 이야기하자면 균형이 있는 레퍼런스계 보다는 다이나믹한 느낌으로, 저음과 고음이 강하다. 특히나 고음의 시원함은 BA를 사용하는 이어폰 치고는 좀 드문 수준이라 좋다고 생각하나, 저음 때문에 중음이 좀 묻힌다는 인상은 있다.

원래 하라는대로 사이드를 사용하고 over-ear 형태로 착용할 경우 착용감이 좋다. (개인적으로는 PFE132에 포함된 투명 이어가이드가 PFE232에 포함된 검정색 보다 편하다고 생각하지만, 이건 개인적인 취향 문제인 듯.) 다만, over-ear가 다 그렇지만 안경과 동시에 사용하면 조금 불편하다. 이때에는 아쉬운대로 좌우를 바꿔서 그냥 in-ear로 착용할 수 있다. (꽤나 당연하게 느껴진 방법인데, 골든이어스나 헤드파이 같은 커뮤니티에 이 방법을 쓰는 사람이 없다는게 좀 신기하다고 생각했다.)

구성품이 좋은 편이나, PFE 1xx 제품군 대부분도 이 정도 되기 때문에 역시나 가격을 정당화 할 수 있는 수준은 아니다. 최상위 기종인 만큼 포낙의 필터 3인방 모두가 2쌍씩 포함되어있고, 공교롭게도 2015년 10월 현재 품귀 현상인 회색 필터 신품을 입수할 수 있는 유일한 방법이기도 하다. (다만, 그걸 위해서 감수해야하는 희생은... 크다. 현재 지구상에 남아있는 판매처는 Earphone Solutions 한 곳. 그나마도 재고가 없어질때까지만 판다고 한다.) 가장 큰 차이는 케이블이 교체가 가능하고 끊어지거나 하면 교체품을 구입할 수 있다는건데, 이것 역시 재고 소진이 되면 문제가 될 여지가 있다. 전 Audeo 제품군과 같은 문제이지만, 케이스는 확실히 애매하다. 사이즈가 작은 만큼 유닛끼리 안에서 부딧치면서 상처가 나는 문제는 둘째치고, Audeo 제품군이 전체적으로 선이 형상 기억이 잘 되는 만큼 제공된 케이스를 사용하면 꺼내서 사용할때 선이 꼬여서 반항을 하는 일이 자주 생긴다. 정신 건상을 위해서 다이소 같은데서 주머니 같은걸 사서 휴대하거나, Shure EASCASE나 EAHCASE 케이스를 사용할 것을 강력하게 권장한다. 다소 혹평을 받은 측정 결과는 여기에.

Sennheiser HD650

이미지 출처: http://en-us.sennheiser.com/high-quality-headphones-around-ear-audio-surround-hd-650

별점: ★★★★★
가격: 50만원 전후. (한국에서는 좀 더 싸게 살 수도 있는것 같다.)
휴대 가능: 불가능.

집에서 사용할 거치용 헤드폰을 하나만 사서 동해물과 백두산이 마르고 닳도록 쓰고 싶다면 다른 리뷰 보지 말고 그냥 이걸 사면 된다. 역사와 전통이 있는 회사에서 만든 레퍼런스급인 만큼 소리는 흠잡을 곳이 없다. 착용감도 매우 좋고, 오픈형이다 보니 밀폐형 처럼 더운 문제는 확실히 없다. 완성도가 매우 높은 기종이고, 두고두고 쓸 수 있는 튼튼한 소재인 만큼 이어패드하고 (Part Number: H-50635) 헤드밴드 패드만 (Part Number: 088597) 닳았을때 교체해주면 된다. 이어패드는 잘하면 ATH 패드 중 몇 기종하고 호환이 될 수도 있는 사이즈이니 귀찮으면 그걸로, 헤드밴드 패드는 정 귀찮으면 문풍지로(...) 저렴하게 교체가 가능하다. (어차피 집에 놓고 쓸거니 모양이 신경 쓰이지 않는다면 말이다.) 생산은 아일랜드에서 한다.

소리는 성향은 레퍼런스계이긴 하지만, 따뜻하면서도 시원한 느낌의 (후자는 오픈형의 특성이다.) 소리를 경험할 수 있다. 오픈형의 특성을 잘 살렸고, 최상급 드라이버가 들어가 있는 제품이니 실망할 일은 절대 없을것이다. 아울러 꽤 가볍다. 300옴이라는 꽤나 높은 임피던스를 자랑하므로, 앰프 사용을 강력하게 권장한다. 테스트 결과 페어링이 가장 좋았던 기기는 Benchmark Media DAC2 HGC였으나, 정신이 똑바로 박힌 사람이라면 적당히 저렴한 헤드폰 앰프랑 붙여서 사용하면 된다. 굳이 그것도 귀찮다면, 그냥 갖고 있는 소스에 꼽아도 되는데 본연의 성능은 못낼 가능성이 있다는 점에 주의. 벤치마크사에서 헤드폰 앰프 회로 테스트를 할때 사용하는 레퍼런스가 HD650인 나큼 앞서 언급한 DAC2 HGC와의 페어링은 매우 훌륭하나, 이상하게도 사고나면 그 달 월급을 안받은 것 같은 기분을 느낄 수 있다.

동봉된 케이블이 존나게 길다. 3미터니까 어지간한 방에서는 책상위에 있는 앰프에 헤드폰을 꼽아두고 베란다에 담배를 피러 갈 수 있는 거리다. 문제는 이걸 책상에서 사용하게 될 경우 선이 걸리적 거리고, 의자에 걸리는 등 피곤한 일이 생긴다. 고로 50만원이라는 거금을 들여서 사고, 돈을 더 들여서 교체용 선을 사거나, 흉하게 빵봉지 묶는 철사로 대충 묶어서라도 케이블 끌림을 방지해주는게 좋다. (선은 교체가 가능한 디자인으로, 뽑으면 빠진다.) 개인적으로는 Oyaide제 HPC-35HDX라는 케이블을 사용하고 있다. HPC-22W 이라는 PCOCC-A라는 순도가 높고 잡음 등을 확실하게 잡아주는 최고급 소재의 0.08mm 굵기의 선을 20가닥씩 3개조를 꼬아서 대칭형으로 만들어 내부 선과 공간의 균형, 그리고 선의 변형 및 손상을 방지하는 새로운 디자인에 남은 공간을 섬유로 채워 전도성을 극대화 하면서 내구성을 올린 고급 케이블이다. 물론, 이건 제조사에서 하는 마케팅용 개소리이고, 결국은 그냥 선이다. 아마존 프라임 주문이 가능한 가장 싼 3.5파이 커넥터가 기본인 짧은 선이라는 이유에서 샀을 뿐, 음질이 더 좋아지거나 하지는 않는다. 싸다고 해도, 6만원 정도 하니, 시간의 여유가 있다면 알리나 이베이에서 좀 더 저렴한 선을 사는걸 추천한다. 묻지마 브랜드 대륙제는 커넥터 체결시 땜질 퀄리티 등에 대해서는 우려되는 바가 있으니, 싸다고 무턱대고 사는 것 보다는 인지도가 어느 정도 있는 벤더를 골라서 그 중에서 싼거 사면 된다. 블라인드 테스트로 돌고래 아니면 어차피 구분 못한다.

오픈형인 만큼 사무실에서 사용하면 모두가 헤드폰을 사용하는 건전한 업무 환경이 아닐 경우 동료들에게 뒤통수를 쳐맞을 각오를 해야한다. 소리가 새는건 막을 수 없고, 막아서도 안되는 디자인이다. 고로 밖에서도 사용 못한다. (아울러 밖의 소리가 들린다.) 내가 회사 사장이 아니면 이건 가정이나 스튜디오에서 사용하는 수 밖에 없다. 다만, 그런게 문제가 없는 상황이라면 정답은 이것이라고 할만한 헤드폰. 측정 결과는 여기에.

Sony MDR-E888

이미지 출처: http://www.amazon.co.jp/ソニー-MDR-E888LP-SONY-ステレオ・イヤーレシーバー/dp/B00008S22K

별점: ★★★☆☆
가격: 중고는 3만원부터 50만원까지 다양하고, 신품은 부르는게 가격.
휴대 가능: 잃어버려도 울지 않을 자신이 있다면 가능.

2015년 현재로 따지면 빈티지나 레트로로 분류될 수 있는 제품이다. 고가형 이어폰 시장을 개척했다고도 할 수 있는 제품으로, 발매 당시 8000엔이 넘어가는 이어폰 치고는 꽤나 파격적인 가격을 자랑했다. (지금은 8000엔이면 "쓸만한 수준이겠군"이라고 생각하는게 일반적이니, 오래 살고 볼 일이다.) 데이터시트 상으로는 최고 27Khz까지 표현이 가능하다고 하나, 주변에 실험해 볼 돌고래가 없어서 실제로 그 정도까지 올라가는지는 모르겠다. CDP와 MDP가 주류를 이루고, 주변에 한 두명 정도가 MP3 플레이어를 갖고 있었고, 지인과 사돈의 팔촌까지 다 동원하면 Sony Music Clip (소니에서 처음 내놓은 플래시 메모리 미디어 플레이어로, 내장 메모리가 NAND인 MD라고 생각하면 된다. 실제로 음성 코덱도 ATRAC3를 사용했다.) 갖고 있는 사람이 한대 나올까말까 하던 시절의 명기.

분명히 소리는 좋다. 15년이 넘은 제품이라고 믿을 수 없을 정도로 해상력이 좋고 (당대 일반적인 이어폰 중에 집에 아직 굴러다니는거 꺼내서 한번 들어보면 확실히 다르다.), 이어폰으로 흔하지 않은 오픈형이라 명쾌하면서 시원한 소리를 내준다. 개인적으로는 솜을 사용하지 않았을 경우 소리를 더 선호하는데, 세월이 세월인 만큼 최대한 교체품이 없는 고무링에 직접 접촉을 피하기 위해서 아쉽지만 솜을 사용하고 있다. 솜을 사용하면 해상력이 다소 떨어지고 저음에 치우치는 경향이 있다. 장시간 착용시에도 피로하지 않으나, 고무 목에 부하를 줄 수 있는 문제가 있다. (이것도 오래되었기 때문에 문제가 되는데, 고무를 상당히 많이 사용한 제품인 만큼 오래되면 고무가 하얗게 되는 문제가 있다.)

신품 구하기가 어렵다. 지금도 전설의 이어폰을 찾아서 온라인을 열심히 뒤지는 용자들이 있는데, 일본 생산 물량 미개봉을 구한다고 하면, 아마도 꽤나 금액이 나갈 것이다. 타오바오에서는 100만원까지 나가는걸 보았다. 이 이어폰이 그만한 가치가 있는가라고 물으면, 솔직히 소리로는 아니올시다라고 생각한다. 분명히 좋은 소리를 내주는 이어폰이긴 하나, 15년이 넘은 제품인 만큼 그 사이에 기술은 많이 발전했다. 물론 고급 이어폰 시장을 개척했다는 역사적 가치나 추억으로서의 의미는 꽤 강하다. 특히 BA 기술의 진보는 실로 경이로운 수준이니 지금와서 저런 돈을 들여서 이 제품을 구매하는건 크게 의미가 없다고 생각한다. 굳이 성향이 비슷한걸 원한다면, B&O 3I나 Yuin사의 PK시리즈가 있으니 그런 제품을 이용하면 되겠다. 측정 결과는 여기에.