독일은 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 업데이트: 사건 종결에 따라서 본문 내용의 업데이트를 한 데 모아서 보기 좋게 수정했다.
이 글은 habr.com 사이트에 올라왔던 “Audio over Bluetooth: most detailed information about profiles, codecs, and devices” 글을 번역한 것이다. 원문: https://habr.com/en/post/456182/
3.5 mm 오디오 잭이 없는 스마트폰이 시장의 주력 상품이 되면서 헤드폰 업계에는 대격변이 일어났습니다. 많은 사용자들은 블루투스 헤드폰을 사용하여 음악을 듣고 통화를 하게 되었습니다. 그러나 블루투스 장치 제조사들은 자세한 제품 정보를 잘 공개하지 않으려고 하고, 인터넷에 있는 블루투스 오디오에 대한 글은 때때로 서로가 모순되거나 정확하지 않기도 합니다. 이러한 글에서는 모든 기능을 언급하지도 않으며, 틀린 정보를 담고 있기도 합니다. 이 글에서는 블루투스 프로토콜, 블루투스 스택, 헤드폰, 스피커, 음악과 통화용 블루투스 코덱의 기능, 전송되는 오디오의 품질과 지연 시간에 영향을 주는 요소, 지원하는 코덱과 장치가 지원하는 기타 기능 정보를 캡처하고 디코드하는 방법에 대해서 알아 볼 것입니다.
TL;DR:
SBC 코덱은 괜찮습니다
헤드폰에는 코덱별 이퀄라이저와 후처리 설정이 존재합니다
aptX는 광고 문구만큼 대단한 것이 아닙니다
LDAC는 단지 마케팅 용어입니다
음성 통화 품질은 여전히 좋지 않습니다
웹 브라우저는 C 언어로 된 오디오 인코더를 emscripten을 사용하여 WebAssembly로 컴파일 및 실행할 수 있으며, 이 과정에서 지연은 발생하지 않습니다.
블루투스로 음악 듣기
블루투스 장치의 기능은 블루투스 표준 문서에 정의되어 있는 프로필로 정해집니다. 블루투스 음악은 고품질 오디오용 A2DP 전송 프로필을 사용합니다. A2DP 표준은 2003년에 최초로 정의되었으며, 그 이후로 큰 변화는 없었습니다.
A2DP 프로필에서 정의하는 유일한 필수 코덱은 SBC이며, 추가로 3종류의 선택적 코덱이 있습니다. SBC 코덱은 계산 복잡도가 낮으며 블루투스 용도로 개발되었습니다. 제조사에서는 A2DP에 포함되어 있지 않은 제조사별 코덱을 사용할 수도 있습니다.
2019년 6월 기준, XKCD 만화에서 보는 것처럼 14개의 A2DP 코덱이 알려져 있습니다:
SBC ← A2DP에 포함됨, 모든 장치에서 지원
MPEG-1/2 Layer 1/2/3 ← A2DP에 포함됨: 잘 알려진 MP3, 디지털 TV에서 자주 사용되는 MP2, 더 이상 사용되지 않는 MP1
MPEG-2/4 AAC ← A2DP에 포함됨
ATRAC ← 소니의 구형 코덱, A2DP에 포함됨
LDAC ← 소니의 신형 코덱
aptX ← 1988년에 개발된 코덱
aptX HD ← aptX와 동일하나 인코딩 프로필이 다름
aptX Low Latency ← 완전히 다른 코덱, 소프트웨어 구현 없음 버퍼 용량이 작은 aptX
aptX Adaptive ← 퀄컴에서 개발한 또 다른 코덱
FastStream ← 의사 코덱(pseudo-codec), SBC를 기반으로 함
HWA LHDC ← 화웨이의 신형 코덱
Samsung HD ← 2종류의 장치에서 지원
Samsung Scalable ← 2종류의 장치에서 지원
Samsung UHQ-BT ← 3종류의 장치에서 지원
블루투스 EDR을 사용하면 2-3 Mb/s로 데이터를 전송할 수 있으며, 비압축 16비트 PCM 2채널 데이터는 1.4 Mb/s의 대역폭만을 필요로 하는데 애시당초 왜 코덱이 필요했을까요?
블루투스 데이터 전송
블루투스에는 두 가지 데이터 전송 방식이 있습니다. ACL(Asynchronous Connection Less) 모드는 연결을 맺지 않고 비동기식으로 데이터를 전송하며, SCO(Synchronous Connection Oriented) 모드는 연결을 맺고 동기식으로 데이터를 전송합니다.
데이터 전송은 시분할 방식으로 이뤄지며, 각각 데이터 패킷마다 주파수 채널을 바꿉니다(Frequency-Hop/Time-Division-Duplex, FH/TDD). 시간은 슬롯이라고 불리는 625마이크로초 단위의 간격으로 나뉩니다. 일부 장치는 짝수번 슬롯에 데이터를 전송하고, 다른 장치는 홀수번 슬롯에 데이터를 전송합니다. 전송된 패킷은 데이터 크기와 전송 모드에 따라서 1, 3 또는 5개의 슬롯을 점유할 수 있습니다. 만약 패킷이 충분히 크고 1개 초과 슬롯을 사용해서 전송해야 한다면 데이터는 전송이 끝날 때까지 짝수번과 홀수번 슬롯으로 전송됩니다. 만약 각각 패킷이 1개 슬롯만 사용하고 양쪽 장치가 연속적으로 데이터를 주고받는다면 1초에 최대 1600개까지의 패킷을 보내고 받을 수 있습니다.
각종 장치 사양과 블루투스 웹 사이트에 나타난 대로, EDR에서 사용하는 2 또는 3 Mbps 전송률은 동시에 양방향으로 전송되는 데이터를 모두 합친(데이터를 캡슐화하는 프로토콜의 기술적인 헤더도 전부 포함) 최대 전송률입니다. 실제 데이터 전송률은 일정하지 않습니다.
음악 스트리밍은 비동기식으로 이뤄지며, 2-DH5 및 3-DH5 패킷을 사용합니다. 해당 패킷은 EDR 모드에서 각각 최대 2 Mb/s, 3 Mb/s까지의 전송률을 지원하며 5개의 시분할 슬롯을 점유합니다.
한개의 장치에서 5개의 슬롯을 사용하고 다른 장치에서 1개의 슬롯을 사용할 때의(DH5/DH1) 전송 다이어그램
시분할 원칙에 의해서, 하나의 패킷을 전송한 후 두 번째 장치에서 아무 것도 전송하지 않았거나 작은 패킷을 전송했다면 625마이크로초 시간 슬롯을 기다려야 하며, 두 번째 장치에서 더 큰 패킷으로 전송했다면 더 오래 기다려야 합니다. 두 개 이상의 장치(헤드폰, 스마트 워치, 피트니스 트래커 등)가 휴대폰에 연결되어 있다면 전송 시간은 모든 장치가 공유합니다.
A2DP 오디오 스트리밍은 L2CAP와 AVDTP 전송 프로토콜로 캡슐화되어야 하며 패킷에서 오디오를 전송할 수 있는 최대 공간에서 16바이트를 차지합니다.
패킷 형식
슬롯 개수
패킷당 바이트 수
최대 A2DP 페이로드 바이트
최대 A2DP 페이로드 비트레이트
2-DH3
3
367
351
936 kb/s
3-DH3
3
552
536
1429 kb/s
2-DH5
5
679
663
1414 kb/s
3-DH5
5
1021
1005
2143 kb/s
실제 상황에서 비압축 오디오를 전송하기에는 1414 및 1429 kbps는 충분하지 않습니다. 2.4 GHz 대역은 여러 장치가 공유하고 서비스 데이터도 전송해야 하기 때문입니다. EDR 3 Mbps 모드를 사용하려면 높은 전송 전력과 신호대 잡음비가 필요하지만, 실제 상황에서는 짧은 끊김이 종종 발생하기에 PCM을 안정적으로 전송할 수 없으며, 가능하다고 하더라도 수 미터 이내의 거리에서만 안정적입니다.
실제로도 990 kb/s 오디오 스트림(LDAC 990 kb/s)도 안정적으로 전송하기 쉽지 않습니다.
이제 코덱으로 돌아갑시다.
SBC
이 코덱은 A2DP 표준을 지원하는 장치에서 필수로 지원해야 하는 코덱입니다. 최적의 코덱이자 최악의 코덱이기도 합니다.
샘플링 레이트
비트 해상도
비트 전송률
인코딩 지원
디코딩 지원
16, 32, 44.1, 48 kHz
16비트
10-1500 kb/s
모든 장치
모든 장치
SBC는 빠르게 연산할 수 있는 간단한 코덱이며, 간단한 청각 마스킹(auditory masking)을 사용하는 원시적인 심리 음향 모델(psychoacoustic model)이 적용된 적응형 펄스 코드 부호화(APCM, Adaptive PCM)를 사용합니다.
A2DP 표준에서는 중간 품질(Middle Quality), 고품질(High Quality) 두 가지의 프로필을 추천하고 있습니다.
코덱 설정으로 알고리즘에 의한 지연, 블록당 샘플 개수, 비트 할당 알고리즘을 제어할 수 있으나, 대개의 경우 표준에서 정의한 인자(조인트 스테레오, 주파수 대역 8종류, 오디오 프레임당 16블록, 라우드니스 비트 할당)를 사용합니다.
SBC에서는 비트 전송률에 직접 영향을 주는 비트풀(bitpool) 인자를 유동적으로 조정할 수 있습니다. 오디오가 지연되었거나, 패킷이 손실되었거나, 장치가 너무 멀리 떨어져 있다면 오디오 소스에서 비트풀을 줄여서 오디오 끊김을 방지하며 연결이 다시 안정화되었을 때 비트풀을 늘릴 수 있습니다.
대부분 헤드폰 제조사에서는 최대 비트풀 인자를 53으로 설정하며, 이 경우 권장 프로필을 사용하면 최대 비트 전송률은 328 kbps로 제한됩니다.
헤드폰 제조사에서 최대 비트풀 값을 53 이상으로 설정했다고 하더라도(Beats Solo³, JBL Everest Elite 750NC, Apple AirPods 및 일부 리시버와 자동차 헤드 유닛 등에서 실제로 사용함) 대부분 OS에서는 블루투스 스택의 내부 제한 때문에 높은 비트 전송률을 사용하지 못합니다.
또 다른 제조사에서는 최대 비트풀 값을 낮게 설정하기도 하며, 이는 음질을 악화시킵니다. 예를 들어 Bluedio T에서는 39, 삼성 기어 아이콘X에서는 37로 설정합니다.
블루투스 스택에서 인위적인 제한을 가한 가능성 있는 이유는 인증 테스트를 충분히 거치지 못했거나, 일부 장치에서는 자주 사용되지 않는 프로필이나 큰 비트풀 값을 지원한다고 하더라도 실제로 사용했을 때 호환성 문제가 발생하기 때문입니다. 개발자 입장에서는 잘못 구현된 장치 데이터베이스를 만들기보다는 추천하는 프로필에서 제안하는 값으로 옵션을 제한하는 것이 더 쉬웠을 것입니다. 비록 지금은 제대로 동작하지 않는 기능의 데이터베이스가 존재합니다.
SBC는 저주파 대역부터 고주파 대역 순 주파수 대역별로 양자화 비트를 동적 할당하며, 각각 대역마다 다른 가중치를 설정합니다. 만약 전체 비트 전송률이 저주파 대역과 중주파 대역에서 사용되었다면 고주파 대역은 묵음으로 대체되어 잘려 나갑니다.
SBC 328 kbps의 예를 들어 봅시다. 원본 오디오는 위쪽, SBC로 인코딩한 오디오는 아래쪽에 있습니다. 비교를 위해서 트랙을 전환했습니다. 비디오 파일의 오디오 스트림은 FLAC 무손실 코덱으로 압축되었습니다. MP4 컨테이너에서 FLAC을 사용하는 것은 공식 표준에 포함되어 있지 않기 때문에 일부 웹 브라우저에서 아래 예제를 재생하지 못할 수도 있습니다(데스크톱 Chrome이나 Firefox의 최신 버전에서는 작동함). 오디오를 들을 수 없다면 파일을 다운로드해서 직접 재생해 보십시오.
ZZ Top — Sharp Dressed Man
스펙트로그램에서 전환하는 순간을 볼 수 있습니다. SBC 코덱에서는 17.5 kHz 이상의 고주파 대역을 주기적으로 잘라내며, 20 kHz 이상의 대역에는 비트를 할당하지 않습니다. 스펙트로그램은 클릭해서 확대할 수 있습니다(1.7 MB).
원 저자는 이 곡의 원본과 SBC 인코딩된 것을 구분할 수 없다고 밝혔습니다.
이제 또 다른 것을 알아봅시다. 비트풀 값을 37로 변경하여 삼성 기어 아이콘X의 음질을 시뮬레이션해 보겠습니다(위쪽: 원본 스트림, 아래쪽: SBC 239 kbps, 오디오 인코딩: FLAC).
Mindless Self Indulgence — Witness
원 저자는 탁탁거리는 소리, 작은 스테레오 효과 및 고주파 대역 보컬에서 불쾌한 치찰음을 들을 수 있었습니다.
정리하자면 SBC는 매우 유연한 코덱입니다. 저지연 모드로 설정할 수도 있으며, 높은 비트 전송률(452 kb/s 이상)에서 고음질을 제공하며, 표준 고음질(328 kb/s) 모드에서 대부분 경우에 만족할 만한 음질을 제공합니다. 그러나 이 코덱이 저음질로 알려지게 된 데에는 몇 가지 이유가 있습니다. A2DP 표준에서는 고정된 프로필을 정의하지 않으며(단지 추천만 함), 블루투스 스택 개발자들은 비트풀을 인위적으로 제한하며, 사용자 인터페이스에는 전송되는 오디오 설정이 표시되지 않으며, 헤드폰 제조사에서는 비트풀 값을 임의로 설정할 수 있으며 해당 설정값을 제품 상세 정보에 기재하지 않기 때문입니다.
같은 비트풀을 사용했다고 하더라도 프로필에 따라서 비트 전송률이 달라집니다. 예를 들어서 같은 비트풀 53을 사용했다고 하더라도 추천하는 고음질 프로필에서는 328 kbps, 듀얼 채널 모드와 주파수 대역 4종류 사용 시에는 1212 kbps 비트 전송률을 사용합니다. 그래서 OS 제작사에서는 비트풀 제한과 더불어 비트 전송률 제한도 둡니다. A2DP 표준 그 자체의 결함 때문에 이 문제가 발생했다고 봅니다. 프로필에서는 비트풀이 아닌 비트 전송률을 협상해야 했습니다.
OS별 SBC 구현에서 지원하는 기능입니다:
OS
샘플링 레이트
최대 비트풀 제한
최대 비트 전송률 제한
일반적 비트 전송률
동적 비트풀 지원
Windows 10
44.1 kHz
53
512 kb/s
328 kb/s
✓*
리눅스 (BlueZ + PulseAudio)
16, 32, 44.1, 48 kHz
64(들어오는 연결), 53 (나가는 연결)
제한 없음
328 kb/s
✓*
macOS High Sierra
44.1 kHz
64, 기본값 53***
알 수 없음
328 kb/s
✗
안드로이드 4.4-9
44.1/48 kHz**
53
328 kb/s
328 kb/s
✗
안드로이드 4.1-4.3.1
44.1, 48 kHz**
53
229 kb/s
229 kb/s
✗
블랙베리 OS 10
48 kHz
53
제한 없음
328 kb/s
✗
* 비트풀은 자동으로 감소하지만, 전송 조건이 달라져도 자동으로 증가하지는 않습니다. 비트풀을 되돌리려면 재생을 중지하고 몇 초 동안 기다린 다음 오디오를 다시 재생해야 합니다.
** 기본값은 펌웨어를 컴파일할 때 스택 설정에 따라 다라집니다. 안드로이드 8/8.1에서는 컴파일 시간 설정에 따라서 44.1 kHz나 48 kHz 중 하나로 결정되며, 다른 버전에서는 44.1 kHz와 48 kHz를 동시에 지원합니다.
*** Bluetooth Explorer 소프트웨어를 사용하여 비트풀 값을 조정할 수 있습니다.
aptX와 aptX HD
aptX는 빠르게 연산할 수 있는 간단한 코덱이며, 심리 음향 모델을 사용하지 않으며, 적응형 차분 펄스 코드 부호화(ADPCM)를 사용합니다. 이 코덱은 1988년 주변부터 사용되기 시작했습니다(특허 출원은 1988년 2월). 이 코덱은 블루투스 이전에는 전문적인 무선 오디오 장치에 사용되었습니다. 현재 퀄컴에서 소유하고 있으며, 라이선스 허가를 받고 비용을 지불해야 합니다. 2014년 기준 허가 비용은 1회의 $6,000 및 최대 10,000대의 장치까지 장치마다 약 $1입니다.(출처, 16쪽)
코덱에서 설정할 수 있는 유일한 인자는 샘플링 레이트입니다. 채널 개수나 모드 설정 옵션 등이 있지만 대부분 장치에서는 스테레오만 지원합니다(70개 이상의 모델에서 확인함).
코덱
샘플링 레이트
비트 해상도
비트 전송률
인코딩 지원
디코딩 지원
aptX
16, 32, 44.1, 48 kHz
16비트
128 / 256 / 352 / 384 kb/s (샘플링 레이트에 따라 다름)
Windows 10(데스크톱과 모바일), macOS, 안드로이드 4.4+/7*, 블랙베리 OS 10
다양한 장치(하드웨어 디코딩)
* 7 이하의 버전에서는 블루투스 스택을 수정해야 합니다. OS에 인코딩 라이브러리가 포함되었다고 하더라도 안드로이드 장치 제조사에서 퀄컴에 코덱 사용 라이선스를 얻었을 때만 지원합니다.
aptX는 오디오를 4개의 주파수 대역으로 분할하고 각각 대역마다 고정된 비트 수를 사용하여 양자화 과정을 거칩니다. 0-5.5 kHz까지 8비트, 5.5-11 kHz까지 4비트, 11-16.5 kHz까지 2비트, 16.5-22 kHz까지 2비트(44.1 kHz 샘플링 레이트 기준).
aptX 오디오 예제(위쪽: 원본 오디오, 아래쪽: aptX 인코딩된 오디오, 왼쪽 채널의 스펙트로그램만 있음, FLAC으로 압축됨):
고주파 대역이 약간 붉게 표시되지만 원 저자는 차이를 들을 수 없었습니다.
코덱의 양자화 비트 분할이 고정되어 있기 때문에, 다른 주파수 대역에서 더 많은 비트가 필요하다고 해도 비트를 “넘겨줄” 수 없습니다. SBC와는 다르게 aptX는 주파수를 인위적으로 “자르지” 않지만 양자화 노이즈를 추가하여 오디오의 다이나믹 레인지를 감소시킵니다.
가령 한 대역에 2비트를 사용한다고 하더라도 다이나믹 레인지가 12 dB 감소한다고 가정해서는 안 됩니다. ADPCM에서는 2비트 양자화를 사용한다고 해도 최대 96 dB까지의 다이나믹 레인지를 지원하지만 특정한 종류의 신호에만 해당합니다.
현재 값의 절댓값을 수치로 저장하는 PCM과는 다르게, ADPCM은 현재 값과 다음 값의 차이를 수치로 저장합니다. 따라서 같은 데이터(무손실)나 거의 같은 데이터(약간의 반올림 오류)를 저장할 때 필요한 비트 수를 줄일 수 있습니다. 반올림 오류를 줄이기 위해서 인수 테이블(factor table)을 사용합니다.
코덱을 개발할 때 음악 오디오 파일을 기반으로 하여 ADPCM 계수를 계산했습니다. 테이블을 만들 때 사용한 음악 모음과 오디오 시그널이 비슷할수록 aptX에 의한 양자화 오류(노이즈)는 더 줄어듭니다.
그래서 인위적으로 생성한 테스트 결과는 항상 음악보다 더 나쁩니다. aptX가 잘 작동하지 못하는 인위적인 테스트로 12.4 kHz 사인파를 만들어 보았습니다. (위쪽: 원래 신호, 아래쪽: aptX 인코딩. FLAC 오디오. 귀갱 주의!):
스펙트럼 그래프:
노이즈를 명확하게 들을 수 있습니다.
그러나 진폭이 더 낮은(더 조용한) 사인파를 생성하면 노이즈 크기도 동시에 줄어듭니다. 이로서 다이나믹 레인지의 범위를 알 수 있습니다:
원래 음악 트랙과 압축된 트랙의 차이를 들어 보려면 신호를 반전한 다음 각각 채널에 트랙을 합산하는 방법이 있습니다. 이 방식은 대개의 경우 정확하지 않으며 복잡한 코덱을 사용한다면 올바른 결과가 나오지 않을 가능성이 높지만, ADPCM 수준의 코덱에서는 이 방식에 큰 오류가 없습니다.
신호 차이의 제곱 평균 제곱근(root mean square)은 -37.4 dB이며, 압축되었음을 감안해도 작습니다.
aptX HD
aptX HD는 독립된 코덱이 아니며, 단지 개선된 aptX 인코딩 프로필일 뿐입니다. 인코딩할 때 각각 주파수 대역별로 사용하는 비트 수가 변경되었습니다.0-5.5 kHz까지 10비트, 5.5-11 kHz까지 6비트, 11-16.5 kHz까지 4비트, 16.5-22 kHz까지 4비트(44.1 kHz 기준).
코덱
샘플링 레이트
비트 해상도
비트 전송률
인코딩 지원
디코딩 지원
aptX HD
16, 32, 44.1, 48 kHz
24비트
192 / 384 / 529 / 576 kb/s (샘플링 레이트에 따라 다름)
안드로이드 8+*
일부 오디오 장치(하드웨어)
* 7 이하의 버전에서는 블루투스 스택을 수정해야 합니다. OS에 인코딩 라이브러리가 포함되었다고 하더라도 안드로이드 장치 제조사에서 퀄컴에 코덱 사용 라이선스를 얻었을 때만 지원합니다.
이 코덱은 aptX보다 자주 사용되지는 않습니다. 퀄컴에서 별개의 라이선스 계약과 라이선스 비용을 지불해야 하는 것 같습니다.
12.4 kHz 사인파를 인코딩해 보겠습니다:
aptX보다 더 좋지만 여전히 잡음이 있습니다.
aptX Low Latency
aptX의 저지연 버전 역시 독립된 코덱이 아닙니다. aptX와의 차이점은 지연 시간과 오디오 유닛에 적용된 버퍼 설정 뿐입니다. 이것을 제외하면 aptX와 동일합니다.
오디오 지연을 프로그램으로 조절할 수 없는 영화나 게임과 같은 저지연 인터랙티브 오디오에서의 사용을 위해서 설계되었습니다. 델에서 개발한 인텔 블루투스 칩셋 드라이버에서 소프트웨어적으로 지원합니다. 일부 트랜스미터, 리시버, 헤드폰, 스피커에서 지원하나 스마트폰에서는 찾아 보기 어렵습니다.
샘플링 레이트
비트 전송률
인코딩 지원
디코딩 지원
44.1 kHz
352 kb/s
델 드라이버가 설치된 Windows 및 일부 트랜스미터(하드웨어)
일부 오디오 장치(소프트웨어)
AAC
AAC(Advanced Audio Coding)는 복잡한 심리 음향 모델이 적용된 연산하기 복잡한 코덱입니다. 인터넷에서의 오디오 전송에 폭낣게 사용되며, MP3 다음으로 많이 사용됩니다. AAC를 사용하려면 라이선스 허가를 받고 비용을 지불해야 합니다. 1회 지불 $15,000(15인 이하 회사의 경우 $1,000) 및 첫 500,000대의 장치까지 장치당 $0.98입니다(출처).
코덱은 MPEG-2 및 MPEG-4 표준에 정의되어 있으며, 많은 사람들의 생각과는 다르게 애플의 독점 코덱이 아닙니다.
샘플링 레이트
비트 전송률
인코딩 지원
디코딩 지원
8 — 96 kHz
8 — 576 kb/s (스테레오), 256 — 320 kb/s (블루투스에 주로 사용)
macOS, 안드로이드 7+*, iOS
다양한 장치(하드웨어)
* 제조사에서 로열티를 지불한 장치만 해당
iOS와 macOS에는 현재 시점에서 가장 고품질로 인코딩하는 애플 AAC 인코더가 포함되어 있습니다. 안드로이드는 애플 AAC 다음으로 음질이 좋은 프라운호퍼 FDK AAC 인코더를 사용하지만, 다양한 SoC 제조사의 플랫폼 내장형 하드웨어 인코더를 사용할 수도 있습니다. SoundGuys 웹 사이트에 올라온 테스트 결과에 의하면 안드로이드 휴대폰마다 AAC 인코딩 음질에 큰 차이가 있었습니다:
대부분의 무선 오디오 장치에서는 최대 320 kbps AAC 비트 전송률을 지원하며, 일부는 최대 256 kbps까지만 지원합니다. 다른 비트 전송률은 거의 사용되지 않습니다.
320 kbps와 256 kbps의 AAC 품질 자체는 나쁘지 않지만, 이미 압축된 오디오의 재압축 손실(generation loss)에 취약합니다. iOS에서는 원본과 AAC 256 kbps의 차이를 듣기 힘들며, 여러 번 다시 인코딩되어도 차이는 거의 없습니다. MP3 320 kbps를 AAC 256 kbps로 다시 인코딩했다고 하더라도 차이를 무시할 수 있습니다.
다른 블루투스 코덱과 마찬가지로 음악이 재생될 때 한 번 디코딩된 후 다른 코덱으로 인코딩됩니다. AAC 형식의 음악을 듣는다고 하더라도 OS에서 디코딩을 거친 다음 블루투스로 전송하려고 다시 AAC로 인코딩합니다. 음악과 새 메시지 알림 등 여러 오디오 스트림을 혼합하려면 불가피하며, iOS라고 해도 예외가 아닙니다. iOS에서 블루투스로 음악을 들을 때 트랜스코딩 과정을 거치지 않는다는 여러 언급이 있으나 이는 잘못된 사실입니다.
AAC 표준 인코딩 방법 외에도 여러 가지 확장이 있습니다. 블루투스에서 사용하는 확장 중에는 SLS(Scalable To Lossless)가 있으며, 오디오를 손실 없이 전송할 수 있습니다. 그러나 현재까지 출시된 장치 중에서는 SLS를 지원하는 장치가 없습니다. 전송 지연을 최소화할 수 있는 AAC-LD(Low Delay)는 아직 블루투스에서 사용하도록 표준화되지 않았습니다.
MP1/2/3
MPEG-1/2 Part 3 코덱은 잘 알려진 MP3, 덜 알려진 MP2(디지털 TV와 라디오에 사용됨) 및 거의 알려지지 않은 MP1로 구성되어 있습니다.
과거에 사용되었던 MP1과 MP2 코덱은 지원되지 않으며, 인코딩이나 디코딩을 지원하는 블루투스 헤드폰이나 블루투스 코덱도 존재하지 않습니다.
일부 헤드폰에서는 MP3 디코딩을 지원하지만, 최근에 사용되는 운영 체제에서는 인코딩을 지원하지 않습니다. Windows의 서드파티 블루투스 스택인 BlueSoleil에서는 설정 파일을 직접 편집하면 MP3 인코딩을 사용할 수 있다고 알려져 있지만, 원 저자가 Windows 10에서 시험해 본 결과 파란 화면이 떴습니다. 즉 블루투스 오디오에 사용할 수 없었습니다.
A2DP가 보급되기 전이었던 2006년-2008년에는 심비안과 Windows Mobile용으로 출시되었던 MSI BluePlayer 프로그램과 노키아 BH-501 헤드셋의 조합으로 MP3 음악을 들을 수 있었습니다. 당시 스마트폰 OS 아키텍처에서는 외부 프로그램이 시스템의 저수준 기능에 접근할 수 있었으며, Windows Mobile에는 서드파티 블루투스 스택을 설치할 수도 있었습니다.
MP3 코덱의 마지막 특허는 만료되었으며, 2017년 4월 23일부터 코덱 라이선스 비용을 지불할 필요가 없습니다.
If the longest-running patent mentioned in the aforementioned references is taken as a measure, then the MP3 technology became patent-free in the United States on 16 April 2017 when U.S. Patent 6,009,399, held by and administered by Technicolor, expired.
소니에서 개발하고 활발하게 밀어 주고 있는 “Hi-Res” 코덱입니다. 96 kHz까지의 샘플링 레이트와 24비트 해상도를 지원하며, 최대 비트 전송률은 990 kbps입니다. 기존 블루투스 코덱을 대체하는 오디오파일용 코덱으로 마케팅하고 있습니다. 무선 전송 조건에 따라서 비트 전송률을 조정하는 적응형 비트 전송률을 지원합니다.
LDAC 인코더(libldac)는 표준 안드로이드 배포판에 포함되어 있으며, 안드로이드 8 이상부터 모든 안드로이드 스마트폰에서 LDAC 인코딩을 지원합니다. 소프트웨어 기반 디코더는 무료로 공개된 것이 없으며 코덱 표준 역시 공개되어 있지 않습니다. 그러나 인코더를 분석해 보았을 때 내부 동작 방식은 플레이스테이션 4와 비타에서도 사용했던 소니의 ATRAC9 코덱과 상당히 유사했습니다. 두 코덱은 모두 주파수 영역(frequency domain)에서 작동하며, 수정된 이산 코사인 변환(MDCT)과 허프만 코딩을 사용합니다.
LDAC는 오디오를 12 또는 16개의 주파수 대역으로 나눕니다. 44.1 kHz와 48 kHz에서는 12개, 88.2 kHz와 96 kHz에서는 16개로 나눕니다.
LDAC는 대부분 소니 헤드폰에서만 지원합니다. 다른 제조사의 헤드폰이나 DAC에서도 지원하기는 하지만 매우 드뭅니다.
LDAC를 “Hi-Res” 코덱으로 마케팅하려는 의도 때문에 일부 적절하지 못한 기술적인 선택이 있었습니다. CD 품질 오디오를 여전히 무손실 압축할 수 없음에도 불구하고 인간이 들을 수 없는 비가청 주파수 영역을 인코딩하고 전송하는 데 비트를 사용하고 높은 비트 해상도를 사용하는 것은 적절하지 못한 선택입니다. CD 오디오 전송과 Hi-Res 오디오 전송 두 가지 모드를 사용할 수 있으며, CD 오디오 전송 시에는 무선(over-the-air)으로 44.1 kHz/16비트만 전송됩니다.
무료로 공개된 LDAC 소프트웨어 디코더가 없기 때문에 LDAC를 지원하는 장치 없이 코덱을 테스트할 수는 없었습니다. SoundGuys.com에서 LDAC를 지원하는 DAC의 디지털 출력에 연결하여 녹음한 테스트 결과에 의하면 CD 음질 모드의 LDAC 660 및 990 kbps의 신호대 잡음비는 aptX HD보다 약간 더 높았습니다.
LDAC는 기존 프로필 외에도 138 kbps부터 990 kbps 사이의 유동적 비트 전송률을 지원합니다. 하지만 현재의 안드로이드 장치에서는 표준화된 303/606/909 및 330/660/990 kbps 프로필만 사용합니다.
기타 코덱
다른 A2DP 코덱은 많이 사용되지 않습니다. 이러한 코덱은 거의 지원되지 않거나, 일부 헤드폰과 스마트폰에서만 지원합니다.
A2DP에서 표준화된 ATRAC 코덱은 소니에서도 사용된 적이 없었습니다. 삼성 HD, 삼성 Scalable, 삼성 UHQ-BT 코덱은 송신 및 수신이 가능한 장치가 한정되어 있습니다. 화웨이 LHDC 코덱은 나온 지 얼마 되지 않았으며 3종류(?)의 장치에서만 지원합니다.
오디오 장치의 코덱 지원
많은 제조사에서 무선 헤드폰, 스피커, 리시버, 트랜스미터에 사용되는 코덱 정보를 정확하게 공개하지 않습니다. 일부 기기에서는 제조사에서는 특정 코덱을 “지원”한다고 표시되어 있으나 송신은 지원하나 수신은 지원하지 않습니다(수신기와 송신기가 결합된 장치의 경우 중요함). 이러한 사실은 별도로 표기되어 있지 않습니다. 인코더와 디코더 라이선스가 별개인 것이 이 문제의 원인인 것 같습니다. 매우 저렴한 장치는 aptX도 지원한다고 표시되어 있지 않는 경우가 있습니다.
불행하게도 대부분 OS에서는 사용자 인터페이스에 지원하는 코덱을 표시하지 않습니다. 현재 사용 중인 코덱 정보는 안드로이드 버전 8 이상과 macOS에서만 표시됩니다. 이 경우에도 휴대폰/컴퓨터와 헤드폰에서 모두 지원하는 코덱만 표시됩니다.
그렇다면 장치가 지원하는 코덱 정보는 어떻게 알 수 있을까요? A2DP 협상 옵션이 포함된 트래픽을 캡처하고 분석하면 됩니다!
리눅스, macOS, 안드로이드에서 실행할 수 있습니다. 리눅스에서는 Wireshark나 hcidump, macOS에서는 Bluetooth Explorer, 안드로이드에서는 개발자 도구의 블루트스 HCI 덤프 저장 기능을 사용할 수 있습니다. Wireshark에서 분석할 수 있는 btsnoop 형식으로 저장됩니다.
메모: 올바른 덤프를 얻으려면 스마트폰/컴퓨터에서 연결 요청을 보내야 하며, 그 반대로는 불가능합니다! 헤드폰에서도 스마트폰이나 컴퓨터로 연결 요청을 보낼 수 있으며, 이 때에는 휴대폰에서 사용 가능한 코덱을 요청할 뿐이지 장치에서 지원하는 코덱 정보를 전송하지 않습니다. 올바른 덤프를 얻으려면 장치 페어링을 해제한 다음, 패킷 덤프를 시작하고 헤드폰과 스마트폰/컴퓨터를 다시 페어링해야 합니다.
다음 필터를 사용하여 관련된 트래픽만 볼 수 있습니다:
btavdtp.signal_id
이 필터를 사용하면 다음과 비슷한 패킷이 표시됩니다:
GetCapabilities 명령을 누르면 코덱의 자세한 정보를 알 수 있습니다.
Wireshark에서 모든 코덱 식별자를 지원하지 않기 때문에 일부 코덱은 직접 확인해야 합니다. 아래의 코덱 식별자 목록을 참조하십시오:
필수:
0x00 - SBC
선택:
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
제조사 특정:
0xFF 0x004F 0x01 - aptX
0xFF 0x00D7 0x24 - aptX HD
0xFF 0x000A 0x02 - aptX Low Latency
0xFF 0x00D7 0x02 - aptX Low Latency
0xFF 0x000A 0x01 - FastStream
0xFF 0x012D 0xAA - LDAC
0xFF 0x0075 0x0102 - 삼성 HD
0xFF 0x0075 0x0103 - 삼성 Scalable Codec
0xFF 0x053A 0x484C - Savitech LHDC
0xFF 0x000A 0x0104 - The CSR True Wireless Stereo v3 Codec ID for AAC
0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3
0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for aptX
간단하지만 유용한 Windows용 Bluetooth Tweaker 소프트웨어를 사용하면 지원하는 코덱과 사용 중인 코덱을 볼 수 있습니다.
리눅스를 사용한다면 BlueZ 패키지의 avinfo 유틸리티를 사용할 수 있습니다.
코덱 비교. 어느 코덱이 더 좋은가요?
각각 코덱은 장단점이 모두 있습니다.
aptX와 aptX HD는 인코더와 디코더를 변경하지 않는 한 변경할 수 없는 하드코딩된 프로필을 사용합니다. 스마트폰이나 헤드폰 제조사라고 해도 aptX의 비트 전송률이나 코딩 인자를 변경할 수 없습니다. 코덱의 소유자인 퀄컴은 레퍼런스 인코더 라이브러리를 라이선스 계약을 맺은 곳에 제공합니다. 이 점은 음질을 항상 미리 알 수 있다는 aptX의 장점이기도 합니다.
한편 SBC는 여러 인자를 조정할 수 있고, 유동적 비트 전송률을 지원(무선이 혼잡한 경우 인코더에서 비트풀을 감소시킬 수 있음)하며, 하드코딩된 프로필을 사용하지 않지만 2003년에 정의된 A2DP 표준에는 “중간 품질”과 “고품질” 추천값만 존재할 뿐입니다. “고품질”은 현재의 기준으로는 더 이상 고품질이 아니지만, 많은 블루투스 스택에서는 기술적인 제한이 없음에도 불구하고 “고품질” 프로필 이상의 인자를 사용할 수 없습니다.
Bluetooth SIG에서는 라이브러리 형태의 SBC 레퍼런스 인코더를 제공하지 않기 때문에 제조사에서 직접 구현해야 합니다.
이 점은 SBC의 약점이기도 합니다. 특정한 장치에서 나오는 음질을 미리 알기는 어렵습니다. SBC는 설정에 따라 저음질과 최고 음질 결과물을 생성할 수 있으나, 최고 음질은 블루투스 스택의 인위적인 제한을 비활성화하거나 우회하지 않으면 불가능합니다.
AAC의 상황은 애매합니다. 이론적으로는 코덱으로 인코딩한 결과물이 원음과 구분하기 어려워야 하나, 실제로는 SoundGuys 연구소에서 여러 안드로이드 장치에서 테스트해 본 결과에 의하면 그렇지 않았습니다. 이런 현상이 발생하는 이유로는 여러 휴대폰 칩셋에 내장된 하드웨어 인코더의 품질 문제로 추정됩니다. 애플 장치에서는 AAC를 사용하는 것을 추천하지만, 안드로이드 장치에서는 aptX/HD나 LDAC 쪽이 더 좋습니다.
대체 코덱을 지원하는 장치는 대개의 경우 품질이 좋은 편입니다. 싸구려 저품질 장치에 이러한 코덱을 지원하는 로열티를 낼 이유는 없기 때문입니다. 자체 실험 결과 고품질 하드웨어에서의 SBC의 음질은 상당히 좋았습니다.
원 저자는 특정 오디오를 브라우저에서 실시간으로 SBC, aptX, aptX HD로 인코딩하는 웹 서비스를 개발했습니다. 블루투스로 오디오를 전송하지 않고도 임의의 유선 헤드폰, 스피커에서 즐겨 듣는 곡을 사용하여 오디오 코덱을 시험해 볼 수 있습니다. 오디오 재생 중에 인코딩 인자를 변경할 수도 있습니다.
이 서비스는 BlueZ 프로젝트의 SBC 코딩 라이브러리와 ffmpeg의 libopenaptx를 사용하며, 웹 브라우저에서 사용할 수 있도록 C 언어에서 emscripten을 사용하여 WebAssembly와 자바스크립트로 컴파일됩니다. 대단하죠!
실제 작동하는 모습입니다:
Your browser does not support HTML5 video.
서로 다른 코덱에서 20 kHz 이상의 노이즈 레벨이 변경되는 것에 주목하십시오. 원본 MP3 파일에는 20 kHz 이상의 주파수가 저장되어 있지 않습니다.
코덱을 변경해 보고 원본, SBC 53 조인트 스테레오(일반적으로 자주 사용되는 표준 프로필), aptX, aptX HD 사이의 차이점을 들어 보십시오.
그래도 “헤드폰”에서 코덱 사이의 차이를 들을 수 있어요!
웹 서비스를 통해서 코덱의 차이를 들어 보지 않았다면 블루투스 헤드폰으로 음악을 들었을 때 차이를 느꼈다고 주장합니다. 불행히도 이것은 플라시보 효과가 아니라 실제 존재하는 차이지만, 코덱의 차이로 인해서 발생하는 차이는 아닙니다.
무선 리시버에 내장된 대부분의 블루투스 오디오 칩셋은 DSP(디지털 신호 프로세서)를 내장하고 있어서 소리를 강화(또는 변화)할 수 있는 이퀄라이저, 컴팬더(compander), 스테레오 익스텐더 기능을 구현합니다. 블루투스 하드웨어 제조사에서는 각각 코덱별로 DSP 설정을 변경할 수 있으며, 코덱을 변경할 때 청자가 코덱에 따른 음질 차이를 듣는다고 생각하는 것은 실제로는 서로 다른 DSP 설정에 의한 차이입니다.
CSR/퀄컴 칩셋의 Kalimba DSP 오디오 처리 프로필각각 코덱과 출력 방식별 DSP 기능 활성화
일부 프리미엄 장치는 DSP 인자를 조절할 수 있는 소프트웨어를 지원하지만, 저렴한 헤드폰은 이러한 기능을 지원하지 않으며 사용자는 사운드 후처리 기능을 표준 도구만으로 끌 수 없습니다.
장치별 기능
A2DP 표준의 현재 버전에서는 오디오 스트림의 음량을 직접 조절하지 않고 AVRCP 프로토콜을 사용하여 특수 명령으로 출력 게인을 제어하는 절대 음량 제어(absolute volume control) 기능을 지원합니다. 헤드폰에서 음량을 변경했으나 휴대폰의 음량과 동기화되지 않는다면 헤드폰이나 휴대폰에서 이 기능을 지원하지 않는 것입니다. 이 경우에는 휴대폰에서는 항상 최대 음량으로 음악을 재생하고 헤드폰 단추로 음량을 조절하는 것을 추천합니다. 신호대 잡음비가 더 나을 것이며 음질이 높아야 합니다.
현실에서는 더 나쁜 경우도 존재합니다. RealForce OverDrive D1 헤드폰에서는 SBC에 강력한 컴팬더를 사용하기 때문에 음량을 높이면 조용한 소리의 음량도 같이 올라가지만 시끄러운 소리의 음량은 변하지 않습니다(신호가 압축됨). 그래서 컴퓨터 쪽의 음량을 절반 정도로 설정하여 압축 효과가 실질적으로 나타나지 않게 해야 합니다.
원 저자의 관찰 결과에 의하면 추가 코덱을 지원하는 모든 헤드폰에서는 절대 음량 제어 기능을 제공하며, 코덱 인증 절차의 일부로 포함되어 있을 것으로 추정합니다.
일부 헤드폰은 동시에 두 개의 장치에 연결할 수 있습니다. 컴퓨터에서 음악을 들으며 휴대폰에서 통화를 할 수 있는 것과 같은 상황을 지원합니다. 그러나 이런 상황에서는 대체 코덱이 비활성화되며 SBC만 사용됩니다.
AVDTP 1.3 지연 보고(Delay Reporting) 기능을 지원하는 헤드폰에서는 소리를 전송하는 장치에 지연 상황을 보고할 수 있습니다. 동영상을 볼 때 음악과 영상의 동기화를 조절하는 데 도움을 줄 수 있습니다. 만약 무선 혼선이 일어난다면 음성이 영상을 따라가지 못하는 것이 아니라 동영상 재생기에서 영상 재생이 느려져서 음성과 영상의 동기화를 다시 맞춥니다.
이 기능은 많은 헤드폰에서 지원하며, 안드로이드 9+, PulseAudio 12.0+가 설치된 리눅스에서 사용할 수 있습니다. 다른 OS에서의 지원은 알려져 있지 않습니다.
블루투스를 통한 전이중 통신. 음성 전송.
SCO(Synchronous Connection Oriented)와 확장된 버전 eSCO(Enhanced Synchronous Connection Oriented) 모드는 블루투스 음성 전송에 사용됩니다. 이 모드에서는 음성을 엄격한 순차적으로 전송할 수 있으며, 송신과 수신 속도는 대칭적이며, 패킷 수신 확인이나 재전송을 기다리지 않습니다. 무선 채널을 통한 오디오 전송 지연 시간을 줄여 주지만, 단위 시간당 전송되는 오디오 데이터의 양에 큰 제한을 두며 음질에 악영향을 줍니다.
이 모드를 사용할 때에는 마이크로 녹음된 음성과 헤드폰으로 전송되는 음성의 음질이 동일합니다.
데이터 그 자체의 전송은 HSP 프로필로 표준화되어 있으며, 이 프로필에서는 음량 제어 기능, 핸드셋 통화 시작 및 종료 등 여러 기능을 지원합니다.
불행히도 2019년 현재에도 블루투스 음성 전송 품질은 좋지 못하며 왜 Bluetooth SIG가 이 부분에 관심을 주지 않는지는 알려져 있지 않습니다.
CVSD
기본 음성 전송 코덱 CVSD는 2002년에 표준화되었으며, 모든 양방향 블루투스 장치에서 지원합니다. 일반적인 유선 전화 음질인 8 kHz 샘플링 레이트 오디오 전송을 지원합니다.
CVSD보다는 더 낫지만 여전히 음질이 좋은 편은 아닙니다. 인터넷, 특히 게임 내에서 통신하려고 헤드폰을 사용한다면 게임의 소리도 16 kHz 샘플링 레이트로 전송되기 때문에 음질이 좋지 않게 들릴 것입니다.
FastStream
CSR은 SBC를 재사용하는 아이디어를 확장했습니다. SCO 프로토콜의 한계를 우회하고 비트 전송률을 높이기 위해서 양방향 전송이 가능한 SBC를 단방향 전송만 가능한 A2DP처럼 사용할 수 있는 기능을 개발했고, 이 기능의 이름을 “FastStream”이라고 붙였습니다.
FastStream은 스피커로 44.1 kHz나 48 kHz 샘플링 레이트, 212 kbps로 인코딩된 소리를 재생합니다. 마이크에서 녹음한 오디오는 16 kHz 샘플링 레이트, 72 kbps 비트 전송률(mSBC보다 약간 높은 수준)로 전송됩니다. 이러한 구성은 온라인 게임 내에서의 통신에 좀 더 유용합니다. 게임 소리와 다른 팀 구성원의 소리는 여전히 고음질로 들을 수 있습니다.
이 방식은 매우 재미있는 핵이지만, A2DP 표준과는 모순된다는 문제가 있기 때문에 CSR의 일부 트랜스미터에서만 지원합니다. 이들은 블루투스 오디오 장치가 아닌 USB 오디오 카드처럼 작동합니다. 그러나 다른 블루투스 스택에서는 지원하지 않습니다. FastStream을 지원하는 헤드폰은 여러 종류가 있습니다.
현재 FastStream은 Pali Rohár가 작성한 리눅스 PulseAudio 패치로만 지원되는 것 같으며, 아직 메인라인에 통합되지는 않았습니다.
aptX Low Latency
놀랍게도 aptX Low Latency는 양방향 오디오를 지원합니다. FastStream과 비슷한 원리를 사용합니다.
이 코덱의 기능을 테스트해 볼 수 있는 방법은 없습니다. 아직까지 알려진 OS나 블루투스 스택 중에 Low Latency 디코딩을 지원하는 것은 없습니다.
블루투스 5, Classic과 Low Energy
블루투스 스펙과 버전을 둘러싼 여러 곳에서 혼동이 있습니다. 하나의 브랜드 아래에 두 가지의 서로 호환되지 않는 표준이 있으며, 이 둘은 서로 다른 목적으로 사용됩니다.
Bluetooth Classic과 Bluetooth Low Energy(LE, Bluetooth Smart라고도 알려짐)는 서로 호환성이 없는 두 종류의 블루투스 프로토콜입니다. Bluetooth High Speed라는 또 다른 프로토콜이 있지만 아직까지 찾아보기 어려우며 가정용 장치에는 사용되지 않습니다.
블루투스 4.0부터 표준안의 변경 사항은 Bluetooth Low Energy에 더 많은 초점을 맞추고 있으며, Classic 프로토콜의 개선 사항은 미미했습니다.
블루투스 4.2와 블루투스 5 사이의 차이점:
9 CHANGES FROM v4.2 TO 5.0 9.1 NEW FEATURES Several new features are introduced in Bluetooth Core Specification 5.0 Release. The major areas of improvement are:
• Slot Availability Mask (SAM) • 2 Msym/s PHY for LE • LE Long Range • High Duty Cycle Non-Connectable Advertising • LE Advertising Extensions • LE Channel Selection Algorithm #2
9.1.1 Features Added in CSA5 — Integrated in v5.0 • Higher Output Power
블루투스 5의 Classic에 영향을 주는 변경 사항은 단 한 가지 뿐입니다. SAM(Slot Availability Mask) 기능이 추가되었으며, 무선 주파수 공유에 좀 더 도움을 주는 목적을 가지고 있습니다. 다른 모든 변경 사항은 Bluetooth LE(및 Higher Output Power)에만 적용됩니다.
모든 오디오 장치에서는 Bluetooth Classic만 사용합니다. Bluetooth Low Energy 표준에는 오디오 전송 기능이 없기 때문에 헤드폰과 스피커를 연결할 수 없습니다. 고음질 오디오를 전송하는 A2DP 표준은 Bluetooth Classic으로만 작동하며, Bluetooth LE에는 같은 역할을 하는 것이 없습니다.
요약하자면, 블루투스 5를 지원하는 오디오 장치를 단지 새로운 버전의 프로토콜을 지원하기 때문에 사는 것은 의미가 없습니다. 오디오 전송은 블루투스 4.0/4.1/4.2와 완전히 동일합니다.
새 헤드폰을 출시하면서 블루투스 5 때문에 크기가 더 커지고 전력 소모량을 줄였다는 광고를 봤다면 해당 제조사에서도 블루투스 표준을 제대로 이해하지 못했거나 혼동을 주려는 의도임을 이해해야 합니다. 심지어는 블루투스 칩셋 제조사에서도 두 가지 표준을 혼동하며, 일부 블루투스 5 칩셋은 LE 부분만 블루투스 5를 사용하고 Classic에는 4.2를 사용하기도 합니다.
오디오 전송 지연
오디오 전송 지연(랙이라고도 함)은 여러 요소에 의해서 결정됩니다. 오디오 라이브러리, 블루투스 스택, 재생 장치 자체 버퍼의 크기, 코덱의 알고리즘적 지연 등이 있습니다.
SBC, aptX, aptX HD와 같은 간단한 코덱의 지연 시간은 3-6 ms 정도로 무시할 수 있는 정도로 짧은 편입니다. 그러나 AAC, LDAC와 같은 복잡한 코덱의 지연 시간은 귀로도 들을 수 있습니다. 44.1 kHz AAC의 알고리즘 지연은 60 ms, LDAC는 30 ms 정도입니다. LDAC의 지연 시간은 소스 코드 분석을 통해서 계산했으나, 실제로 큰 차이는 없을 것입니다.
총 지연 시간은 재생 장치, 칩셋, 버퍼에 크게 의존합니다. 테스트하는 동안 여러 다른 장치에서 SBC 코덱을 사용할 때 150 ms부터 250 ms까지의 지연 시간을 측정할 수 있었습니다. aptX, AAC, LDAC 추가 코덱을 지원하는 장치에서 고품질 구성 요소를 사용하고 버퍼 크기를 작게 설정했다면 대개의 경우 다음 지연을 예상할 수 있습니다:
SBC: 150-250 ms
aptX: 130-180 ms
AAC: 190-240 ms
LDAC: 160-210 ms
마지막으로 한 번 짚고 지나갑니다. aptX Low Latency는 여러 운영 체제에서 지원하지 않기 때문에 저지연 모드를 사용하려면 트랜스미터+리시버나 트랜스미터+헤드폰/스피커 번들을 사용해야 하며, 모든 장치에서 이 코덱을 지원해야 합니다.
인증, 로고, 장치의 문제
고품질 오디오 장치와 싸구려 물건을 어떻게 구분할 수 있을까요? 일단 외관부터 봅시다!
싸구려 중국제 헤드폰, 스피커, 리시버의 특징은 다음과 같습니다:
포장 상자와 장치 그 자체에 “Bluetooth” 언급이 없으며, “무선”이나 “BT” 등만 있음
포장 상자나 장치에 블루투스 로고 가 없음
파란색 LED가 없음
이러한 특징이 보이지 않는다면 장치가 인증받지 않았음을 의미하며, 장치 품질에 대해서 보증할 수 없음을 의미합니다. 예를 들어 Bluetooth SIG에서 인증받지 않은 Bluedio 헤드폰은 A2DP 표준을 완전히 준수하지 않습니다. 아마도 인증 절차를 통과할 수 없었을 것입니다.
이제 일부 장치와 포장 박스를 알아 봅시다:
이 장치는 모두 인증받지 않았습니다. 설명서에 로고와 “블루투스” 이름이 있기는 하지만, 실제로 이 로고는 장치나 포장 박스에 있어야 합니다.
만약 블루투스 헤드폰이나 스피커에서 나오는 안내 음성이 “Ze bluetooth dewise is connecteda successfulle”처럼 왜곡되어 있다면 장치의 품질에 대해서 큰 기대를 하지 마십시오.
결론
블루투스는 유선 휴대폰을 완전히 대체할 수 있을까요? 아마도요. 그러나 저품질 음성 통화, 게임 등에 문제가 될 수 있는 음악 전송 지연 시간, 라이선스 비용이 필요하기 때문에 스마트폰과 헤드폰 가격을 올리는 데 기여하는 독점 코덱을 감안해야 합니다.
대체 코덱은 매우 활발히 마케팅되고 있습니다. aptX와 LDAC는 “오래되고 저음질”인 SBC의 대체품으로 광고되고 있지만 실제로 SBC는 생각하는 것만큼 나쁘지 않습니다.
HP Microserver Gen8은 시스템 칩셋으로 인텔 C204를 사용하고, 기본적으로 하드 베이에서 나온 SFF-8087 케이블이 인텔 C204의 SATA 컨트롤러에 연결되어 있다. 그래서 0, 1번 베이만 SATA 6Gbps를 지원하기 때문에 PCIe 슬롯에다가 SAS HBA를 붙여서 모든 베이에서 6Gbps를 사용하도록 하는 개조를 자주 당하고는 한다. ZFS 같은 소프트웨어 RAID를 사용할 거라면 굳이 하드웨어 RAID 카드를 붙일 필요가 없어서 IT 모드로 플래싱할 수 있는 캐시 안 달린 RAID 카드를 사용하기도 한다.
LSI(Avago를 거쳐서 Broadcom에 인수됨) RAID/HBA 카드는 SAS 계열에서 본좌 중 하나로 취급된다. LSI는 자체적으로 카드를 만들어서 팔 뿐만 아니라 서버 제조사에 OEM으로도 칩셋을 납품한다. LSI 버전 리테일 카드보다 OEM 버전 카드가 더 싸긴 한데, OEM 버전 카드는 LSI 버전보다 최신 펌웨어가 더 늦게 올라오거나 IR/IT 모드 펌웨어 중 하나마 올라오기도 한다. LSI SAS 칩셋과 카드 정보를 보려면 serverthehome에 있는 정보를 참조하면 된다. 덕분에 2cpu에서 인기 있었던 하드웨어가 IBM M1015인데, 이건 그냥 LSI 펌웨어를 강제로 밀어 넣으면 LSI 카드로 변신하고 IR/IT 모드 전환도 자유롭기 때문이다. 아직까지 국내에 후지쯔 D2607 카드로 시도해 보았다는 사람은 안 보이는데, 사실 후지쯔 카드의 SBR 구조가 다른 LSI 칩셋 카드와는 달라서 2016년에서야 성공했다는 블로그 글이 나왔다. 독일 이베이를 눈팅하다가 D2607이 꽤 싸게 풀린 걸 하나 낚아채서 이걸 시도해 보았다.
martan.st에 의하면 후지쯔 카드의 SBR은 0x12번째 바이트가 다른 LSI 카드와는 살짝 달라서, 다른 회사의 SBR을 그대로 밀어 넣으면 2개의 SFF-8087 포트 중 하나만 인식하는 경우가 생긴다. serverthehome에 올라온 글에 의하면, D2607 카드에는 A11과 A21 리비전이 있는데 문제의 0x12번째 바이트가 A11과 A21 리비전끼리도 서로 달라서(A11: 0x04, A21: 0x00) IT 모드로 플래싱할 때에도 하드웨어 리비전을 맞춰서 플래싱해야 한다. 내가 받은 카드도 A21 리비전이라서 D2607-A21용 SBR을 구해야 했다.
준비물은 UEFI 부팅 가능한 보드, D2607 카드와 포맷해도 상관 없는 USB 메모리다. Microserver Gen8은 UEFI를 지원하지 않지만, marcan.st 블로그에서는 sas2flash의 UEFI 버전을 수정해서 Mfg Page 2 validation을 건너뛰도록 만들어 놨기 때문이다. sas2flash의 DOS 버전의 같은 부분을 수정하면 UEFI 부팅 가능한 보드가 없어도 되지만, 아직까지 사람들이 거기까지는 시도해 보지 않은 것 같다. lime-technology 사이트에 A21과 A11 리비전용 SBR, sas2flash, IT 모드 펌웨어를 모아 놓은 압축 파일을 누군가가 올려 두었다. Rufus로 DOS 부팅용 USB를 만든 다음 이 파일을 USB 메모리의 루트에 압축을 풀어 놓으면 된다.
명령을 내려서 RAID 카드의 SAS 주소를 기록해 둔다. 혹시나 카드가 맛이 갈 때를 대비해서
megarec -readsbr 0 orig_sbr.bin
명령을 내려서 원본 SBR을 백업해 둔다. 그 다음 카드를 초기화한 다음 IT 모드용 SBR을 플래시해 주고 다시 한 번 더 초기화한다. 여기까지는 다른 LSI 칩셋 카드와 같다.
megarec -cleanflash 0 (카드에 따라서 여러 번 실행해야 할 수도 있음)
megarec -writesbr 0 SBR-A21.bin (카드가 A21 리비전인 경우)
megarec -writesbr 0 SBR-A11.bin (카드가 A11 리비전인 경우)
megarec -cleanflash 0
그 다음 UEFI 셸로 부팅해서 IT 모드 펌웨어를 밀어넣는다. 저 사이트에 올라온 2118it.p20.bin 파일은 Broadcom 사이트에 올라와 있는 LSI 9211-8i의 20.00.07.00 펌웨어와 동일하다. MD5 체크섬은 동일하나, 찝찝하면 공식 사이트에 있는 파일로 새로 밀어넣어도 상관 없다.
fs0: (UEFI 셸 진입 시 표시되는 USB 메모리 경로로 입력)
sas2hax -o -f 2118it.p20.bin
이 단계에서 카드를 초기화할 수 없다는 오류 메시지가 뜨데, 의도된 결과다. 그래서 시스템을 UEFI 셸로 재부팅한 다음 다시 한 번 더 명령을 수행해 준다.
fs0: (이전 단계에서 실행했던 것과 동일한 경로)
sas2hax -o -f 2118it.p20.bin -b mptsas2.p20.rom
sas2hax -o -sasadd (이전에 기록해 둔 SAS 주소)
마지막으로 DOS로 재부팅한 다음 SBR을 한 번 더 기록해 준다.
megarec -writesbr 0 SBR-A21.bin 또는
megarec -writesbr 0 SBR-A11.bin
IBM M1015 같은 것과는 SBR 및 펌웨어 구조가 달라서 후지쯔용 SBR을 사용하고 sas2flash의 LSI 버전을 사용할 수 없다는 게 차이점이지만, 한 번 플래싱해 두면 HBA 모드로 계속 사용할 수 있다. 후지쯔 카드에 LSI 펌웨어를 올리는 방법 자체가 2016년 5월에서야 최초로 알려졌기 때문에 LSI 펌웨어를 올린 후에 펌웨어 업그레이드는 아직까지는 아무도 시도해 보지 않은 것 같다.
공장 상태의 D2607을 연결하면 MegaRAID Configuration Utility 진입 메뉴가 뜨지만, IT 모드 플래싱이 완료되면 이런 게 뜬다. 이제 이 상태에서는 MegaRAID Storage Manager를 설치해도 HDD 정보만 표시되며, sas2ircu로도 할 수 있는 일은 HBA와 하드디스크 정보 보기밖에 없다. megacli/storcli는 컨트롤러를 인식하지 못한다.
베를린에서 한국으로 간다면 가장 큰 문제점이 어디서든 최소한 한 번 환승을 해야 한다는 것이다. 그나마 서울로 간다면 유럽 내 대형 공항에서 한 번만 환승하면 끝이지만, 목적지가 서울이 아니라면 여러 번의 환승은 불가피하다. 제아무리 환승 내항기와 인천공항행 KTX가 다닌다고 해도 목적지 공항에 최소 환승으로 갈 수 있다는 것의 메리트는 상당히 크다. 또 하나의 문제는 베를린발 대륙간 노선 수가 얼마 없다는 것이다. 2017년 현재 테겔에서 아시아로 오는 노선은 카타르 항공의 도하행, MIAT 몽골 항공의 모스크바 경유 울란바토르행, 하이난 항공의 베이징행 정도를 빼면 이스라엘이나 터키까지만 간다. 쇠네펠트 쪽에는 이란행 노선이 좀 있지만 한국 가는 길에 굳이 거기를 경유할 필요는 없다.
그 동안 부산으로 갈 때는 어쩔 수 없이 인천으로 갔으나, 이번에는 베이징 경유 부산행이라는 다른 옵션을 시도해 보았다. 베를린까지 환승 횟수를 최소로 줄일 수 있다는 게 가장 컸고, 적어도 이 티켓을 예약하는 시점에서는 에어 베를린이 아직 살아 있었기 때문에 그 쪽으로 마일리지를 쌓으려는 의도도 있었다. (물론 에어 베를린은 이제 퇴갤해 버렸지만) 그리고 아무리 중국 항공사라도 UA보다는 장거리 서비스가 나을 것이라는 기대 덕분에 베를린 테겔발 베이징 경유 부산행 항공권을 끊었다. AVOD 없는 UA 747로 대서양도 건너 봤는데 어떤 걸 더 못하겠냐. TXL-PEK 구간은 하이난 항공, PEK-PUS 구간은 아시아나항공으로 예약했는데 이게 나중에 환승 시에 좀 문제가 되었다.
하이난 항공은 베를린 테겔에서 터미널 C를 사용하는데, 여기는 버스에서 내리면 바로 있는 터미널 A/B와는 멀리 떨어져 있다. 중간에 한 번 계단을 내려가는 구간이 있는데, 문이 늦게 열리기는 하지만 엘리베이터가 있으니 짐이 많으면 그 쪽으로 가면 된다. 예상대로 테겔 공항의 부가세 환급 데스크는 하이난 항공 출발 시간이 다가오자 바리바리 짐을 싸 들고 온 사람들로 붐볐고, 나는 해당 사항이 없기 때문에 바로 체크인 카운터로 직행했다. 이 티켓은 두 항공사가 걸친 여정이라서 아시아나 쪽에서도 하이난 쪽에서도 웹 체크인이 불가능했다. 테겔 공항의 직원들은 PUS가 어디에 있는 지 잘 모르는 듯했지만, 짐이 부산까지 간다는 말은 베이징에서 깔끔하게 예상이 빗나갔다.
베를린 테겔의 출국 심사대를 통과하고, 어차피 터미널 C도 그리 크지 않았기 때문에 적절히 시간을 죽치고 있다가 바로 탑승했다. A330-300 기체를 보내며 이코노미 좌석은 다행히도 2-4-2 배치였다. 출발 요일은 주말을 살짝 피했기 때문에 빈 자리가 아주 없지는 않은 편이었다. 좌석에는 베개, 담요가 놓여 있고, 안대, 칫솔과 치약 세트, 수면 양말 정도가 들어가 있는 Amenity kit이 같이 있었다.
A330 기내
비행기가 이륙하고 나서 식사 메뉴를 나눠 주는데 그 덕분에 아무리 중국식이라고 해도 최소한 무엇을 먹는지는 알고 먹을 수 있었다. 기내식은 출발할 때 한 번, 도착하기 전에 한 번 나온다. 하이난 항공이 지금은 코드셰어 편으로만 한국에 취항하기 때문에 의외일 수도 있지만, 한국인 승무원도 최소한 2명은 탑승하고 있었다. 승무원 명찰에 달려 있는 국기를 보고 알아챌 수 있다. 당시 TXL-PEK 편에 탔던 유일한 한국인이었던 덕분에 유리한 점이 없진 않았다.
HU490 TXL-PEK 기내식 1
HU490 TXL-PEK 기내식 2
중국 항공사들은 아직도 기내에서 비행기 모드의 휴대폰도 사용을 금지하고 있기 때문에, 다른 항공사의 금연 표시등이 있어야 할 자리에 휴대폰 금지 표시등이 있다. 덕분에 기내 엔터테인먼트가 없으면 비행 시간이 지루해지기 쉽다. 한국에 취항하지 않기 때문에 한국 영화나 TV 프로그램은 기대하지 않고 있었지만, 한 때 불태웠던 2048이 AVOD에 들어가 있어서 이걸로 시간을 오래 때웠다. (보너스로 2048 하던 시절의 손 감각이 아직 사라지지 않았다는 것도 확인했다) 시차 적응을 위해서 저녁을 먹은 다음에 눈을 붙였더니 시베리아 동쪽까지 날아가고 있었다.
기내 엔터테인먼트에 2048?
이 비행편은 베이징 수도 국제공항 터미널 2로 도착하고 출발한다. 문제는 연결편으로 끊은 아시아나항공은 터미널 3을 사용하는데, PEK에서 다른 터미널의 비행기로 갈아타려면 일단 공항을 나갔다가 들어와야 한다. Transfer라고 쓰여 있는 곳에서는 같은 터미널의 비행기로만 갈아탈 수 있기 때문에, 다른 터미널의 비행기로 간다면 살인적인 인파를 뚫고 일반적인 출입국 절차를 밟아야 한다. (중국 출입국 카드도 다 써야 한다는 점은 보너스) 짐이 혹시나 자동으로 연결되지 않을까 기대하긴 했지만, 수하물 컨베이어에 올라와 있는 점을 보고 고생길 시작이란 걸 느꼈다. T2를 빠져나가서 T3으로 갈 때에는 공항에서 운영하는 무료 셔틀버스를 사용하면 되는데, 걸어갈 수 없는 거리만큼 떨어져 있기 때문에 다른 교통 수단은 잠시 잊어 두자. 택시는 잘못 탔다가는 고생할 수 있다. 아무튼 T2의 입국 심사와 T3의 아시아나항공 체크인+출국 심사를 다 뚫고 나니 약 2시간 정도가 걸렸고, 여기에는 아시아나 체크인 카운터가 열리지 않아서 기다렸던 30분 정도가 포함된다. 아시아나항공의 PEK-PUS 노선은 그냥저냥 평범했다. 아시아나가 서비스 줄인다는 말이 있지만 다행히도 Hot meal이 나왔다.
부산에서 올 때에도 이 과정의 역순을 그대로 밟았다. 짐을 체크인할 때 베를린까지 바로 간다는 말을 들었고 Baggage tag에도 PEK/TXL이 다 찍혀 있었으나, 출국편에서 본 것처럼 수하물 찾는 곳에 짐이 있었을 지도 모르기 때문에 24시간 내 환승용 임시 비자를 받아서 입국 심사를 통과한 뒤에도 컨베이어 벨트를 다시 확인했다. 내 짐이 없다는 것을 다시 한 번 확인하고 T3을 떠나 T2로 갔다. 처음 이걸 해 본다면 당황하기 쉬운 구조이지만, 올 때 한 번 해 봤기 때문에 이번에는 무리가 없었다. 부산에서 비행기가 15분 늦게 출발해서 안 그래도 부족할 수도 있는 3시간 45분이라는 환승 시간도 15분 짧아졌지만, T3 입국 심사와 T2 출국 심사 및 하이난 항공 체크인을 모두 합쳐서 2시간 내에 끝낼 수 있었다. 이리저리 뛴다고 고생은 했지만.
PEK T2 FIDS
역시 PEK-TXL도 TXL-PEK와 같은 서비스가 제공된다. 단지 차이점이라면 중국에서 기내식을 입고시킨다는 것 뿐. 이번에는 출발 요일이 토요일이었기 때문에 사람들이 더 많았다는 게 더 큰 차이점이다. TXL-PEK 편은 군데군데 빈 자리가 보였지만, 이번에는 자리가 꽉 차서 나왔다.
HU489 PEK-TXL 기내식 1
TXL과 PEK 두 공항 양쪽에서 보딩 브리지는 쓰지 못하고 버스로 주기장까지 이동해야 했는데, PEK 쪽은 그래도 입국 심사대가 여러 개라서 인원이 분산될 여지라도 있기에 별 우려가 없었지만 TXL 쪽은 입국 심사대 개수도 적기 때문에 일단 뛰는 게 중요했다. 심사대를 빠르게 통과해야 하는 이유가 하나 더 있었기 때문이다. 기존 한국 여권에 유효 기간이 남은 독일 D 비자가 있는 상태에서 페이지가 다 차서 새 여권을 발급받았다. 이 상황에서 독일 입국이 가능한가가 문제였는데, 결론부터 말하자면 가능했다. 입국 심사관은 구 여권에 있는 비자는 구 여권에 VOID 구멍이 뚫리면서 효력이 정지되기 때문에 빠른 시일 내에 비자를 재발급받아야 한다고 했다. 운 좋게도 Ausländerbehörde에 예약을 잡아 놓은 상태였기 때문에 문제가 생기면 그 이야기를 하려고 했지만, 거기까지는 안 가도 되었다.
에어 베를린 파산 직전까지 하이난 항공은 베를린에서 AB 편으로 다른 유럽 도시로 짐을 연결시켜 주었는데, 이제 AB가 파산하고 나서는 어떻게 되었는가가 궁금해진다. 실제로 AB 파산 이후에 테겔 공항의 손님이 줄어들고 베를린발 항공 노선의 가격이 인상되었다는 보도가 있었기 때문에, 개인적으로는 어떻게든 AB가 버텨 줬으면 하는 바람이 있었지만 뭐 어쩌겠는가. #BER4EVR
