웹 서비스에 활용할 목적으로 머신러닝에 공개 데이터를 집어넣는다면 피해자가 발생하지 않도록 필터링은 잘 하자. 특히 이메일 주소는 크롤링을 방지하려고 다양한 형태로 변형해서 게시하는데 이걸 조심해야 한다.
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
2015년 독일 통신 시장에는 큰 변화가 있었다. 무선 분야 각각 3/4위 사업자였던 e-plus와 O2가 합쳐지면서(O2가 e-plus를 인수하는 형태로) 통합 O2는 무선 가입자 수가 단숨에 1위로 올라갔다. 이동통신망은 합쳐진 이후에도 상당 기간 따로 놀다가, 4월 말에 상호간 3G 로밍을 허용하였다. 단 여기에서 LTE는 제외되기 때문에, 가입자 서로간의 LTE 망에는 접근할 수 없다.(O2는 선불 가입자에게 LTE를 안 열어놨고, e-plus는 열어놓았기 때문에 그런 것 같지만…) 물론 주파수 할당은 합쳐져 있기 때문에 의지만 있다면 추가 망 통합이 진행되었겠지만, 주파수 경매 이후로 모든 것이 미루어진 것 같았다.
마지막으로 독일에서 있었던 주파수 경매는 2010년이었으며, 이 때는 통신사가 4개 있었다(Telekom, Vodafone, e-plus, O2). 800, 1800(일부), 2100(일부), 2600MHz 대역이 경매에 부쳐졌으며, 800MHz 대역은 e-plus 제외 전 통신사 10MHz x2, 당시 경매에 나왔던 1800MHz 대역은 Telekom 15MHz x2, e-plus 5+5MHz x2, 2100MHz 대역은 Vodafone 4.95MHz x2, e-plus 9.9MHz x2, O2 4.95MHz x2, 2600MHz 대역은 Vodafone 20MHz x2, Telekom 20MHz x2, e-plus 10MHz x2, O2 20MHz x2씩 가져가게 된다. 비록 이 당시에도 TDD 주파수가 경매로 나오긴 했으나 실제 TDD 망이 구축되지는 않았다. (출처: Bundesnetzagentur) e-plus와 O2는 당시에 딜을 해서 주파수를 서로 나눠서 가져갔다는 설이 있다.
독일에 LTE가 깔리기 시작한 때도 이 주파수 경매 이후이다. Telekom은 이 때 획득한 15MHz+5MHz를 사용하여 Band 3에 20MHz LTE 망을 설치하였고, e-plus는 지역에 따라서 Band 3 중 10/15MHz 대역 망을 설치하였다. 기존 5MHz에서 실시 중이었던 GSM은 900MHz로 쫓아내면 되기 때문에 한국의 분석과는 다르게 광대역화가 쉬웠다. Telekom이 획득한 나머지 망 중 800MHz는 주로 교외 지역에, 2600MHz는 의외로 드물게 설치했다. 한편 Vodafone과 O2는 800MHz Band 20을 주력망으로 삼았고(10MHz 폭), 2.6GHz Band 7은 20MHz 광대역을 가지고 있긴 하나 Band 20보다는 덜 촘촘하게 설치했다. Vodafone은 1.8GHz에 5MHz 폭만 가지고 있었고, O2는 가지고 있던 대역폭 자체는 충분했으나 이걸 거의 GSM으로 사용했다.
2015년에 경매에 부쳐진 대역은 700, 900, 1500, 1800(일부)MHz 대역이며, 경매에 부쳐진 1800MHz 대역은 2010년에 경매에서 획득한 Telekom의 15MHz x2, e-plus의 10MHz x2를 제외한 50MHz x2 폭이다. 주파수 용도에는 별도의 제한을 걸어 두지 않았기 때문에 2, 3, 4, 5G 모두 사용 가능하다. 경매 대상 대역 중 에는 O2와 e-plus가 사용하였던 900, 1800MHz 대역 중 2016년 만료 대역이 조기 반환되어 포함되었다. (BNetzA) 경매 결과를 분석할 때 기존 확보 대역을 빼 놓으면 해석이 많이 엉뚱해 질 수 있다. (아래 사진 출처: BNetzA)
700MHz: LTE Band 28에 해당하는 대역이다. 최하위 5MHz 블록 1개(703-708MHz, 758-763MHz)만 고정 주파수이고 나머지는 유동 주파수이다. 한국에서는 방송사의 징징이로 인하여 소중한 주파수를 방송사에게 뭉텅이로 떼이고, 통신사에게는 20MHz x2(이것도 왠지 한 통신사에 몰아줄 것 같지만…)만 남아 있다. 독일에서는 방송사를 모두 쫓아내고 경매를 통해서 통신사가 모두 낙찰받았으며, 703MHz-733MHz, 758MHz-788MHz에서 10MHz x2씩 O2, Telekom, Vodafone 순으로 공평하게 가져갔다. 아직 DVB-T 방송이 이 대역에서 실행 중이라서 대역 정리 작업이 끝나야 LTE 망을 설치할 수 있고 5MHz당 낙찰 가격도 1.5GHz 다음으로 저렴하다.
900MHz: LTE Band 8, EGSM900에 해당하는 대역이다. 최하위 5MHz 블록 1개(880-885MHz, 925-930MHz)만 고정 주파수이고 나머지는 유동 주파수이다. 한국에서는 KT가 10MHz x2를 LTE로 사용 중이다. (KT가 850MHz 대신 여기를 가져간 게 유럽 통신사들이 GSM을 빨리 접고 LTE를 이 대역에 깔 예정이기 때문이었다는 카더라가 있지만…) GSM 900MHz는 전통적인 황금 주파수였고, 유럽 일부 국가에서는 여기에 3G를 깔아 두었지만 독일은 전부 GSM으로 사용 중이다. 과거에는 Telekom과 Vodafone이 사실상 여기를 독점하였고 e-plus와 O2는 각각 5MHz x2씩 가져갔으나, 경매 결과로 O2 10MHz x2, Vodafone 10MHz x2, Telekom 15MHz x2씩 가져갔다. 지금 시점에서 3G 증설은 모양이 좀 웃길 수도 있기에 세 통신사 모두 GSM 망 유지용으로 대역을 사용할 가능성이 크다. 게다가 GSM 휴대폰들은 대부분 900MHz를 지원하기 때문에 과거에 1800MHz에서 굴렸던 일부 GSM 망을 여기로 옮길 수도 있다.
1800MHz: LTE Band 3, PCS1800에 해당하는 대역이다. 최상위 5MHz 블록 1개(1780-1785MHz, 1875-1880MHz)만 고정 주파수이고 나머지는 유동 주파수이다. 이번 경매에서 낙찰가가 가장 높은 대역이다.
Telekom은 15MHz x2만 가져갔지만 기존 할당된 15MHz x2와 합쳐서 30MHz x2 대역을 가지고 있다.(1.8GHz 대역 최대 보유 예정) 현재 서비스 중인 20MHz 광대역 LTE를 그대로 유지 가능하며, 남은 10MHz는 CA용으로 쓰거나 5G를 깔 가능성도 있다.
O2는 e-plus 인수로 획득한 10MHz x2와 경매로 획득한 10MHz x2를 합쳐서 20MHz x2를 보유하게 된다. 현재 e-plus가 설치한 LTE 네트워크는 주파수 조정을 통해서 사용할 수도 있다. 단 이 대역을 전부 20MHz LTE로 돌려 버리면 e-plus의 1800MHz GSM을 전부 새로 얻은 900MHz로 이전해야 한다. 대부분 1800MHz GSM 휴대폰은 900MHz도 지원하므로 큰 문제는 없을 수도 있다.
Vodafone은 이번 경매로 25MHz x2를 획득하였다. 단 Vodafone은 기존 1800MHz 네트워크가 전부 GSM이었기 때문에 1800MHz LTE 네트워크를 전부 새로 설치해야 하며, Telekom과 마찬가지로 20MHz 망을 설치한다면 남은 5MHz를 GSM 혹은 다른 용도로 사용할 수도 있다.
1500MHz: LTE Band 32, 다운링크 전용 대역이다. Telekom과 Vodafone 모두 20MHz씩 가져갔다. 아직까지 표준화가 되지 않아서 지원하는 휴대폰도 전무하지만 만약 망을 설치한다면 이야기가 달라질 수도 있다. 덕분인지 낙찰 가격도 가장 저렴하다. 5G 용도로 사용할 가능성도 없지는 않다.
이 경매와는 별개로, 2100MHz 대역폭은 Vodafone 14.85MHz x2, O2 34.65MHz x2, Telekom 9.9MHz x2를 보유하고 있다. 마음만 먹는다면 O2가 2100MHz 대역에서 광대역 LTE를 깔아 버릴 수도 있지만 유럽에서는 해당 대역에 LTE를 설치한 통신사가 적다는 약점이 있다. 독일 한 언론에서는 2100MHz 대역의 넓은 주파수 때문에 O2가 이번 주파수 경매의 1.8GHz에 적극적으로 뛰어들지 않았다는 분석을 하였다. Telekom 제외 나머지 통신사가 2010년 경매로 획득한 Vodafone 4.95MHz x2, e-plus 9.9MHz x2, O2 4.95MHz x2 주파수는 2025년까지 유효하고, UMTS 초기에 획득한 나머지 Vodafone 9.9MHz x2, O2 19.8MHz x2, Telekom 9.9MHz x2 대역은 2020년까지 유효하다.
GSM 900MHz가 오랫동안 Telekom/Vodafone에 묶여 있었고, 1800MHz LTE 역시 Telekom과 e-plus만 할 수 있었으나 이번 경매를 통하여 모든 통신사들이 전 GSM/LTE 대역에서 사실상 동등한 양의 주파수를 확보하게 되었고, e-plus와 O2의 합병으로 3사의 가입자 규모가 비슷해졌기 때문에 앞으로 네트워크 품질로 어떻게 경쟁할 지를 지켜보는 것도 하나의 관전 포인트이다. CDMA를 빠르게 걷어내 버려서 3G가 사실상 마지노선이 된 한국과는 다르게, 독일은 아직 GSM이 살아 있고 LTE가 보급되면 GSM보다 3G를 더 빠르게 걷을 수도 있다. 그리고 Telekom과 O2의 1800MHz 대역은 이번 경매로 완전히 얻은 것이 아니고 2020년에 만료되는 대역이 일부 있다. 2020년 주변에 다시 일어날 주파수 경매를 보는 것도 재미있을 것이다.
