스크립트
00:00:00질문 하나 하겠습니다. 네트워크를 사용하지 않고, 또 USB 스틱 같은 물리적 장치도
00:00:05사용하지 않고 어떻게 파일을 보낼 수 있을까요? 바로 광 파일 전송(optical file transfer)이 그 답입니다. 에번 크롤리라는
00:00:13개발자가 '데시만(Deciman)'이라는 도구를 만들었는데요, 이는 QR 코드를 깜빡이고
00:00:19이를 다시 읽어들이는 방식으로 한 기기에서 다른 기기로 파일을 전송할 수 있습니다. 정말 멋진 파일 전송 기술이며
00:00:26꽤 영리한 엔지니어링 전술을 사용합니다. 따라서 오늘 영상에서는 데시만을 살펴보고,
00:00:31어떻게 작동하는지 확인한 다음 다양한 시나리오에서 테스트하여 광 파일 전송이
00:00:37실제로 얼마나 강력한지 알아보겠습니다. 아주 흥미로운 시간이 될 테니 바로 시작해 보죠.
00:00:46데시만의 작동 방식은 이렇습니다. 한 기기가 화면에 QR 코드와 유사한 프레임 스트림을 표시하고
00:00:53다른 기기가 그곳에 카메라를 향해 이를 다시 파일로 디코딩합니다. 즉, 네트워크 스택이
00:01:00전혀 개입하지 않습니다. 따라서 에어 갭(망 분리) 장치와 파일을 교환해야 한다면, USB 드라이브 같은
00:01:06외부 장치를 물리적으로 연결하지 않고 할 수 있는 유일한 방법이 바로 이것입니다. 아이디어는 파일을
00:01:12일련의 QR 코드로 인코딩하고, 화면에 차례대로 깜빡이며, 반대편의 카메라가
00:01:19각 프레임을 캡처하고 디코딩하도록 하는 것입니다. 단순해 보일 수 있지만, 문제는 카메라가 실제로
00:01:26즉각적으로 캡처하지 않고 화면도 즉각적으로
00:01:32새로고침되지 않는다는 사실에서 발생합니다. 즉, 두 개의 서로 다른 하드웨어가 경쟁하는 셈이며, 동기화가 어긋나면
00:01:38프레임이 손상되거나 아예 누락됩니다. 하지만 이 문제에 대한 데시만의 해답은 '분수 부호화(fountain coding)'라는 방식입니다.
00:01:461번, 2번, 3번 프레임을 보내고 각각이 온전히 도달하기를 바라는 대신,
00:01:53각 프레임이 원본 파일의 특정 청크가 아니라 조각들을 수학적으로 혼합한 형태인, 사실상 무제한의
00:02:00인코딩된 프레임 스트림을 생성합니다. 즉, 대체 불가능한 단일 프레임이란 존재하지 않습니다.
00:02:07수신기는 꼭 47번 프레임이 필요한 것이 아니라, 어떤 것이든 도달하기만 하면 충분한 수의 프레임만 있으면 됩니다.
00:02:14절반을 놓쳐도 상관없습니다. 수신기가 충분히 모을 때까지 계속 브로드캐스팅할 뿐입니다.
00:02:22하지만 이 접근 방식이 만병통치약은 아닙니다. 이 방식에는 전송할 수 있는 데이터의 한계가 존재합니다.
00:02:29기본적으로 데시만의 송신기는 초당 60프레임 속도로 프레임당 2,953바이트를 밀어냅니다.
00:02:37이를 계산해 보면 초당 약 177킬로바이트라는 이론적 한계치가 나옵니다.
00:02:44일부 혼합 프레임은 설계상 본질적으로 중복되기 때문에 분수 부호화로 인한 오버헤드를 고려해야 합니다.
00:02:51그렇게 남는 수치가 바로 데시만 리드미(README) 파일에서 실제로 주장하는 값입니다.
00:02:56폰과 폰을 측정했을 때 초당 약 128킬로바이트로 정점을 찍습니다.
00:03:02특별히 2,953바이트 청크를 사용하는 이유는 표준 QR 크기 중 가장 큰 버전 40에 해당하기 때문이며,
00:03:11단일 프레임에 177x177 격자의 개별 모듈이 담겨 있는 형태입니다.
00:03:20여기서 진짜 상충 관계(trade-off)가 나타납니다. 프레임에 더 많은 데이터를 욱여넣으면 동일한 파일을 보내는 데
00:03:26전체적으로 필요한 프레임이 줄어들지만, 이는 읽어들이는 카메라가 더 높은 해상도와
00:03:33더 안정된 손놀림, 그리고 한 모듈과 다음 모듈을 구분할 수 있는 더 선명한 초점이 필요함을 의미합니다.
00:03:38따라서 전체 시스템은 세 가지 변수 간의 균형 잡기 게임입니다.
00:03:42초당 몇 프레임을 보내고 있는지, 각 프레임이 얼마나 조밀한지, 그리고 수신
00:03:49카메 실제로 그 밀도를 얼마나 잘 해상해 내는지 말이죠. 데시만은 기본적으로 특정 균형이 설정된 채 제공되며,
00:03:57이는 특정 시나리오에 맞춰 튜닝되어 있는데, 제가 알게 된 바에 따르면 제가 테스트한 시나리오와는 맞지 않았습니다.
00:04:03제 설정은 이렇습니다. 송신기로서 노트북 화면을 실제 사용할 때처럼 팔 길이 정도의 일반적인 거리에 두고 있습니다.
00:04:09이 설정으로 제 전송 속도는 초당 약 3킬로바이트에서 상한을 찍었습니다.
00:04:16전송된 프레임의 약 1~2퍼센트만 실제로 디코딩되고 있습니다. 나머지는 캡처되었다가 버려집니다.
00:04:23여기서 우리에게 불리하게 작용하는 요인은 세 가지가 있습니다. 첫 번째이자 가장 큰 난관은 프레임 속도 불일치입니다.
00:04:30송신기는 초당 60프레임을 밀어내고 있지만, 제 폰 카메라는 30프레임으로 캡처합니다. 30프레임만 챙기는 센서로는
00:04:3860개의 서로 다른 이미지를 샘플링할 수 없습니다. 단순히 절반을 놓치는 것보다 더 심각한 이유는, 각 캡처된
00:04:45프레임의 노출 창이 화면상의 서로 다른 두 QR 코드를 걸치기 때문입니다. 그래서 카메라는 프레임을 깔끔하게 놓치는 게 아니라, 두 개를 하나로 섞어버려 아무것도 디코딩되지 않는 결과물을 만듭니다.
00:04:56그리고 main.ts 파일에는 앱이 카메라에 명시적으로 60프레임을 요청하더라도 iOS가 조용히 30프레임을 전달한다는 주석까지 있습니다.
00:05:07카메라가 요청한 대로 주지 않으며, 코드는 이미 그것을 다루고 있습니다.
00:05:12그리고 같은 파일의 조금 더 아래쪽에는 첫 번째 시도에서 저에게 일어난 일을 정확히 예측하는 주석이 있습니다.
00:05:19초당 60프레임에 프레임당 2,953바이트라는 기본값은 근거리 폰 대 폰 데모에 특화되어 튜닝되어 있다는 것입니다.
00:05:29그리고 그 동일한 조합은 일반적인 모니터를 팔 길이만큼 두고 사용할 때는 고전할 것으로 예상됩니다.
00:05:35다시 말해, 프로젝트가 이럴 거라고 미리 말해준 셈이죠. 저는 코드를 그만큼 내려서 읽지 않았던 것뿐입니다.
00:05:41송신 측면에서 보면, 60헤르츠 노트북 패널도 반대로 똑같은 문제를 가집니다. LCD 픽셀은 회색에서 회색으로 색상을 완전히 전환하는 데 꽤 많은 시간이 걸립니다.
00:05:51그리고 그 정착 시간 때문에 다음 코드가 그 위에 덧칠해지기 전에 패널이 하나의 코드에 완전히 도달하지 못하게 됩니다.
00:05:58그래서 잔상 아티팩트가 생기죠. 두 번째 문제는 코드 밀도 대 카메라 해상도입니다.
00:06:042,953바이트는 QR 버전 40이지만, 안정적인 디코딩을 위해서는 모듈당 대략 3~4개의 카메라 픽셀이 필요하며, 이는 코드 자체만을 위해 선명한 초점으로 가로 600픽셀 이상이 필요하다는 뜻입니다.
00:06:20팔 길이만큼 떨어진 노트북 화면은 폰 카메라 프레임을 그만큼 채우는 경우가 드문 반면, 근거리의 폰 대 폰은 뷰파인더 전체를 쉽게 채웁니다.
00:06:30그리고 세 번째 문제는 밝기와 대비입니다. 이는 부수적인 문제이지만 수신기의 이진화 장치가 이미지를 깔끔하게 임계값 처리하는 데 도움이 되며, 프레임 속도 불일치나 크기가 안 맞는 코드를 해결할 수는 없습니다.
00:06:44자, 이제 동일한 전송을 시도해 보되, 이번에는 폰에서 다른 폰으로 해보겠습니다.
00:06:50따라서 유일하게 바뀌는 것은 송신기입니다. 가까이 두고 수신 폰의 전체 프레임을 채우는 작고 밝은 OLED 화면이죠.
00:06:58이제 카메라는 실제 프레임 속도에 더 가깝게 도달할 수 있습니다.
00:07:02코드가 고해상도로 프레임을 가득 채우며 싸워야 할 LCD 잔상도 없습니다.
00:07:07이 시나리오는 리드미 파일에 나온 초당 128킬로바이트라는 수치가 실제로 측정된 환경입니다.
00:07:14수신기 코드에는 작지만 정말 유용한 세부 정보도 있습니다.
00:07:18캡처 FPS와 디코딩 FPS를 따로 보고해 줍니다. 캡처는 카메라가 물리적으로 보고 있는 것을 말합니다.
00:07:26디코딩은 그중 실제로 사용 가능한 것이 얼마나 되는지 알려줍니다.
00:07:30이 두 숫자가 서로 벌어질 때, 즉 캡처는 건강한데 디코딩이 추락할 때
00:07:35프레임의 조밀함과 해당 거리에서 카메라가 실제로 해결할 수 있는 능력 간의 불일치를 보고 있는 것입니다.
00:07:42따라서 노트북에서 폰으로의 전송이 실제 사용 사례라면, 해결책은 송신기 측에서 이 세 가지 변수의 균형을 다시 맞추는 것입니다.
00:07:50프레임당 바이트 수를 1,465로 낮추어야 하며, 이는 더 크고 여유로운 모듈을 가진 더 거친 QR 버전과 일치합니다.
00:07:59그런 다음 카메라의 30 FPS 상한선 아래로 의도적으로 전송 FPS를 24로 낮춥니다.
00:08:07그러면 프레임이 서로 섞이지 않고 한 번에 하나씩 깔끔하게 샘플링됩니다.
00:08:12보시다시피 이 수치들을 낮추면 훨씬 더 큰 처리량을 얻을 수 있습니다.
00:08:16즉, 광 파일 전송은 모든 상황에 맞는 만능 해결책이 아님을 보여줍니다.
00:08:21사용 중인 하드웨어에 따라 모든 사용 사례에 맞게 수동으로 조정해야 합니다.
00:08:26자, 이렇게 해서 다 보셨습니다, 여러분.
00:08:27이것이 바로 요약된 데시만입니다.
00:08:29전반적으로 이번 프로젝트는 파고들기에 정말 재미있는 프로젝트였습니다.
00:08:32광 파일 전송은 꽤 멋진 기술입니다.
00:08:36그리고 실제 시나리오에서 분수 부호화 개념이 적용되는 것을 보는 것은 정말 흥미로웠습니다.
00:08:44이 프로젝트를 살펴보는 동안 이런 종류의 도구를 실제로 어디에 사용할 수 있을지 생각해보기도 했습니다.
00:08:49가장 뻔한 답은 네트워크 연결을 의도적으로 전혀 원하지 않는 에어 갭 전송일 것입니다.
00:08:57혹은 구형 하드웨어나 임베디드 시스템처럼 블루투스나 와이파이조차 없는 기기들이죠.
00:09:04제 말은 화면과 카메라만이 믿을 수 있는 유일한 두 가지인 곳이라면 어디든 말입니다.
00:09:10하지만 이 도구에 대해 어떻게 생각하시나요?
00:09:11이전에 광 전송 도구를 사용해 보신 적이 있으신가요?
00:09:14이에 대한 실생활에서의 활용도가 보이시나요?
00:09:17아래 댓글 섹션에 알려주세요.
00:09:19그리고 여러분, 이러한 유형의 기술 분석이 마음에 드신다면 영상 아래의 좋아요 버튼을 눌러 알려주세요.
00:09:25또한 저희 채널 구독도 잊지 마세요.
00:09:28BetterStack의 앤드러스였으며 다음 영상에서 뵙겠습니다.
00:09:34다음 영상에서 뵙겠습니다.