ls

파일 목록보기

ls

상세정보 목록보기

ls -l

숨김파일을 포함한 목록보기

ls -a

읽기 쉬운 단위로 목록보기

ls -lh

수정시간 최신순으로 목록보기

ls -t

정렬 순서를 역순정렬 목록보기

ls -r

하위 디렉토리까지 포함 목록보기

ls -R

파일 종류를 마지막 문자로 구분하여 목록보기

ls -F 
# '/' 디렉토리, '*' 실행파일

파일크기 큰순으로 목록보기

ls -S

Network

SSH

SSH 시작

sudo systemctl start ssh

SSH 자동시작 등록

sudo systemctl enable ssh

Wifi

NetworkManager 실행

sudo systemctl start NetworkManager

Network Interface 목록 보기

sudo nmcli dev

Wifi 기능 켜기/끄기

sudo nmcli radio wifi on
#축약
sudo nmcli r wifi on

sudo nmcli radio wifi off
#축약
sudo nmcli r wifi off

Wifi 스캔

sudo nmcli dev wifi rescan

Wifi 목록보기

sudo nmcli dev wifi

Wifi 연결/끊기

sudo nmcli dev connect "<SSID>" password "<비밀번호>"
sudo nmcli connection down <SSID>

#장치연결 끊기
nmcli device disconnect <인터페이스이름>

나는 picocom을 이용해서 접속하였다.

    # picocom -b <baud rate> -d <통신 데이터 비트 수> /dev/<연결 시리얼 포트>
    picocom -b 1500000 -d 8 /dev/cu.usbserial-A5069RR4

접속이 되면 엔터를 한번 쳐준다. 로그인 하라고 하는데 초기 계정과 비밀번호를 입력하고 로그인 하면 된다.

다음은 오버레이 설정을 해주어야한다.

    sudo rsetup

Overlays - Manage Overlays 순으로 이동하고 본인이 사용하는 디스플레이를 선택한뒤 설정을 빠져 나오면 된다. *선택은 스페이스바, 포커스 이동은 탭

그렇게 설정하고 재부팅 하면 되는것이다. Rseutp을 빠져 나와서 재부팅해주자.

    sudo reboot

Fory는 JIT컴파일과 Zero-Copy를 이용한 고성능 직렬화 도구이다.

벤치마크

원래는 Ant Group(알리바바 계열사)에 내부 프로젝트로 시작 되었으나 2023년 Apache재단에 인큐베이팅 되면서 2025년에 TLP가 되었다.

처음에 오픈소스 기여를 할 생각은 없었다. 그냥 해당 프로젝트 GitHub 저장소를 방문해서 이것 저것 탐색 하다가 Contributing 탭을 보게되었다. 그중에 'Good First Issues'라는 링크를 보게 되었고 궁금해서 들어가 보았다.

그곳에는 처음 기여하는 사람들을 고려한 비교적 쉬운 이슈들을 모아둔 곳이었다. 나는 내가 해 볼 수 있는 이슈가 있을까 탐색하다가 CI/CD 관려 이슈를 보게 되었다.

해당이슈는 "Rust Github Action이 5분가량 소요되는데 3분대로 낮추었으면 좋겠다." 라는 이슈였다.

왠지 이정도는 내가 한번 도전해 볼 수 있을것 같다는 생각이 들어 해당 이슈에 "주니어 개발자이고 오픈소스 기여가 처음인데 이 이슈에 관심이 있어서 그런데 실수를 할 수 있겠지만 한번 이슈를 처리해봐도 될까요?" 라고 번역기를 이용해서 코멘트를 달았다.

그러자 하루가 지나고 운영자에게 "기여해주셔서 고맙습니다. 이슈를 당신한테 할당해 줄게요." 라는 코멘트를 받을 수 있었고 이슈가 나에게 할당되었다

먼저 github action 스크립트가 있는 .github/workflows/ 에 들어가서 Rust 관련 CI/CD 내용을 살펴보았고 Rust CI 부분에 캐시를 이용하는 코드가 없는것을 보게되었고 캐시를 이용할 수 있도록 스크립트를 추가해주었다.

CI 테스트는 ACT 를 사용하여 테스트 하였고 드라마틱한 시간 단축은 없었으나 그래도 평균 10초 정도는 단축 시킨것 같다.

그렇게 하여 PR을 요청하였다.

3주정도 지난후 PR이 승인이 되고 머지가 되었다.

그렇게 기여자 명단에 내가 올라가게 되었다. 처음 기여를 해보았는데 정말 뿌듯하다.

Radxa는 엣지 컴퓨팅, AI 및 산업용 애플리케이션을 위한 오픈 소스 싱글 보드 컴퓨터(SBC)와 임베디드 시스템을 제공하는 기업이다.

• 제품군 Rockchip SoC(시스템 온 칩)를 기반으로 한 ROCK Pi 시리즈(예: Rock Pi 4, Rock Pi S)가 주력 제품이다. 이 외에도 고성능 엣지 AI를 위한 Dragon Q6A(퀄컴 프로세서 기반) 및 산업용 임베디드 모듈(SOM)을 제공한다.
• 라즈베리 파이 대안 라즈베리 파이와 호환되거나 이를 대체할 수 있는 고성능 SBC를 제공하며, 특정 모델(예: Radxa Zero)은 라즈베리 파이 제로 시리즈의 강력한 대안으로 평가받는다.
• 주요 애플리케이션 IoT 장치, 멀티미디어, 산업용 자동화 기기, 그리고 AI 기반 엣지 컴퓨팅 기기 개발에 주로 사용된다.
• 생태계 자체 문서화 센터를 운영하며, 다양한 리눅스(Linux) 및 안드로이드(Android) 운영체제를 지원하는 커뮤니티 기반의 생태계를 구축하고 있다.

Rock 3B

Rock 3B

구분 | 세부 항목 | 사양 (Specifications) | | :--- | :--- | :--- | | 프로세서 | SoC | Rockchip RK3568 (Quad-core Cortex-A55 up to 2.0GHz) | | | GPU | Mali-G52-2EE (OpenGL ES 3.2, Vulkan 1.1 지원) | | | NPU | 1.0 TOPS (AI 가속기) | | 메모리 | RAM | 2GB / 4GB / 8GB LPDDR4 (3200MT/s) | | 저장 장치 | eMMC | eMMC 모듈 슬롯 지원 | | | MicroSD | 지원 (TF 카드 슬롯) | | | M.2 SSD | M.2 M Key (PCIe 3.0 x2) - NVMe SSD 지원 | | 비디오 출력 | HDMI | 1x HDMI 2.0 (4K@60Hz) | | | MIPI/eDP | 2x MIPI DSI, 1x eDP (트리플 디스플레이 가능) | | 네트워크 | Ethernet | 2x 기가비트 LAN (1개는 PoE 지원) | | | Wireless | M.2 E Key 슬롯 (WiFi 6/BT 모듈용) | | | Cellular | M.2 B Key 슬롯 (4G/5G 모듈용 + SIM 슬롯) | | USB 포트 | USB 3.0/2.0 | 2x USB 3.0 (1x OTG 포함), 2x USB 2.0 | | 확장 헤더 | GPIO | 40핀 헤더 (라즈베리 파이와 호환성 유지) | | 전원 | Input | USB Type-C (PD 2.0 / QC 2.0, 3.0 지원) | | 규격 | 크기 | 100mm x 75mm (Pico-ITX 폼팩터) |

OS 설치

Rock3 OS Download 사이트

위 링크에서 다운로드한다.

OS는 공식적으로 Debian과 Android 두가지를 지원하는데 현 시점으로 Android와 Debian 둘다 11까지 지원한다. 사이트에 들어가보면 다른 서드파티 이미지들도 몇개 존재한다.

하지만 나는 Tauri2로 작성된 앱을 Debian에서 실행하기 위해서 Pre-Release한 Debian12 버전을 이용해서 OS를 설치하였다.

Rock 3B Image Download 문서 Image 설치 가이드 이미지는 툴을 이용해서 설치하는 방법이 무난한것 같다.

보드에 eMMC와 SDcard, Nvme 세가지 물리저장장치를 지원하기 때문에 해당 방법에 맞게 설치하는 것이 좋다.

공식홈페이지에서는 Linux와 Windows OS에 대한 툴만 지원하기 때문에 MacOS는 그냥 dd를 이용해서 인스톨 하도록 하겠다.

이미지 압축해제

이미지가 이미지_이름.img.xz로 압축되어있는데. 이를 unzx로 해제 함면 된다.

unzx <이미지_이름>.img.xz

이렇게 하면 <이미지_이름>.img 이렇게 이미지가 나온다.

저장장치에 쓰기

나는 SSD를 따로 마운트 할 장비가 없기 때문에 USB 허브를 통해서 SDcard에 설치 한 뒤 실제 보드에서 Nvme SSD에 다시 재설치 하는 방향으로 진행하고자 한다.

SDcard에 설치

SDcard 위치 조회

USB 허브에 SDcard를 장착하고 Mac에 연결해준다. diskutil 명령어를 이용해서 저장장치가 어디에 연결되어있는지 확인한다.

diskutil list

저장장치가 /dev/disk<번호> 어떤 곳에 연결 되어있는지 확인한다.

SDcard 언마운트

저장장치가 어디에 연결 되어 있었는지 알아내었다면 플래시하기 위해서 언마운트 해주어야한다.

diskutil unmountDisk /dev/disk<번호>

SDcard 플래시

이제 dd를 이용해서 장치에 이미지를 플래시하면 된다.

sudo dd if=<이미지 경로> of=/dev/rdisk<번호> bs=1M status=progress

위에서 status는 플래시 상태를 보여주는 옵션이기 때문에 입력하지 않아도 무방하다.

플래시가 끝나면 혹시 모를 데이터 유실이나 파일시스템 일관성을 위해서 sync 를 해준다.

sync

이렇게 하면 OS가 SDcard에 잘 설치 되었다.

구동하기

Rock 3B 보드 SDcard 슬롯에 OS를 설치한 SDcard를 삽입하고 전원케이블(USB Type-C)을 꽂으면 자동으로 SDcard로 부터 OS를 부팅한다.

부팅 완료.

[dd man 사이트]

배경

Redis비용 문제를 해결하기 위해서 만들어 졌다. Redis는 모든 데이터를 메모리에 올려두고 사용하기 때문에 데이터가 커질수록 비용이 급격하게 올라간다. (메모리값...) 하지만 Kvrocks는 메모리 비용을 줄이면서 저장용량을 늘리는 것을 목표로한다.

원래 중국의 Meitu(메이투)에서 개발했으며, Trip.com, Baidu 등 여러 기업이 프로덕션 환경에서 사용하고 있다. 현재는 Apache 재단 프로젝트로 Apache 2.0 라이선스로 공개되어 있다.

특징

Redis호환성이 있어 기존 Redis 클라이언트를 통해 그대로 접근 할 수 있다. 네임스페이스를 통한 데이터 격리, MySQL과 유사한 binlog기반 비동기복제, Redis Sentinel을 활용한 고가용성, 클러스터링 모드를 지원한다.

언제 쓰면 좋은가?

Redis처럼 다양한 자료구조가 필요하지만 데이터 규모가 커서 전부 메모리에 올리기 부담스러운 경우에 적합하다.

나는 어떻게 사용할 것인가?

현재 서버의 RAM 용량이 DB, WebServer, Cache 등 여러 VM에 자원을 할당하기엔 매우 작음으로 Nvme SSD를 이용해서 캐시서버의 RAM할당량을 줄이고 SSD의 의존도를 높여는 비록 속도는 RAM보다 조금 느리지만 용량을 많이 사용 할 수 있도록 트레이트오프를 하여 운영할 예정이다.

128비트 구조

256,000조 제타바이트까지 지원한다.(사실상 용량 제한이 없음)

스토리지 풀링

여러 디스크를 하나의 논리적 저장소로 통합 관리하여 유연한 용량 확장 가능하다. RAID-Z1, Z2, Z3 같은 자체 RAID 방식도 지원한다.

스냅샷 및 클론

즉시 파일 시스템의 특정 시점을 저장(스냅샷)하고 복제(클록)하여 백업 및 복구에 매우 효율적이다.

Copy-on-write

데이터를 수정할 때 기존 데이터를 덮어쓰지 않고 새로운 위치에 저장하여 안정성을 높이고 데이터 손실을 최소화 한다.

압축 및 중복제거

LZ4, ZSTD 등의 알고리즘으로 저장되는 데이터를 실시간으로 압축하거나 중복을 제거하여 저장 공간 효율을 극대화한다.

데이터 무결성

모든 데이터 블록에 체크섬을 적용하고, 읽을 때마다 검증한다. 손상이 감지되면 미러나 패리티 정보를 통해 자동으로 복구하는 "self-healing" 기능을 제공한다.

이건 하드웨어 레벨이 아닌 소프트웨어 레벨에서 직접 관리하는 것이기때문에 Silent Corruption까지 잡아낸다. (RAID는 보통 디스크가 완전히 멈춰야 고장으로 인식)

특징

비동기 통신

별도의 클럭 선 없이 TX(송신), RX(수신) 2개의 신호선만 사용하여 데이터를 교환한다.

데이터 프레임

데이터는 [시작 비트(1) + 데이터(58bit) + 패리티 비트(옵션) + 정지 비트(12)] 구조로 전송된다.

보율 (Baud Rate)

통신 속도를 나타내며, 송수신 측에서 동일한 속도(예: 9600, 115200 bps)로 설정해야 한다.

양방향 통신

TX와 RX를 통해 동시에 송수신이 가능한 Full-duplex 방식이다.

작동 원리

직렬화(Serialization)

병렬 데이터(데이터 처리부)를 1비트 단위의 직렬 신호로 변환하여 전송한다.

역직렬화(Deserialization)

수신부에서는 받은 1비트 신호들을 다시 병렬 데이터로 모아 처리한다.

약속된 속도

수신 측은 미리 정해진 보율(baud rate)에 따라 데이터의 시작과 끝을 감지한다.

핵심적인 특징은 Rust 언어로 작성된 도구이며, 주로 Rust 내장(Embedded Rust) 개발 환경에서 편리하게 펌웨어를 전송하고 시리얼 모니터링을 하기 위해 사용된다.

시리얼 플래싱

시리얼 포트(UART)를 통해 빌드된 이진 파일(Binary/ELF)을 ESP 칩의 플래시 메모리에 기록한다.

다양한 칩 지원

ESP32, ESP32-S2/S3, ESP32-C2/C3/C6, ESP32-H2, ESP8266 등 대부분의 에스프레시프 칩을 지원한다.

크로스 플랫폼

Windows, macOS, Linux에서 모두 동작한다.

Cargo 플러그인 (cargo-espflash)

Rust의 빌드 도구인 cargo와 연동되어 cargo run 또는 cargo espflash flash 명령어로 빌드와 동시에 펌웨어를 굽는 편리한 기능을 제공한다.

모니터링 기능

펌웨어 굽기 후, 바로 시리얼 모니터를 열어 디버깅 로그를 확인할 수 있다.

설치

cargo install espflash --locked

# 또는 cargo-espflash 플러그인 설치
cargo install cargo-espflash --locked

핵심 명령어

• flash: 펌웨어 바이너리 파일 굽기
• save-image: 바이너리 이미지를 로컬에 저장
• board-info: 연결된 보드 정보 확인
• erase-flash: 플래시 메모리 전체 삭제
• monitor: 시리얼 모니터만 실행

내가 구성하려고 하는 규모는 1~5만 동시접속이 원활한 서버 이다. 이건 단순히 나의 호기심에서 시작되었기 때문에 어떤 결말이 있을지 잘 모르겠다. 잘 만들어서 잘마무리 되었으면 좋겠다.

삭제하고 다시 git submodule update를 해보았지만 여전히 용량 미달...

긴급히 대표님께 Help 요청!

이렇게 하고 서브모듈 제거 한 뒤 다시 git submodule update 커맨드를 이용하니 파일이 제대로 클론 되었다.

Git의 한계

Git은 모든 수정 이력을 로컬에 저장하므로, 용량이 큰 바이너리 파일이 자주 바뀌면 저장소 크기가 순식간에 수십 GB로 늘어난다.

GitHub 제한

GitHub는 단일 파일이 100MB를 넘으면 푸시를 차단한다. LFS를 쓰면 파일당 최대 5GB(또는 그 이상)까지 올릴 수 있다.

설치

brew install git-lfs

git lfs install

최근 사내 프로젝트를 개발하면서 "사용자가 버튼을 누르고 말을 마친 뒤, 다시 버튼을 누르지 않아도 알아서녹음이 종료되는" 기능이 필요했다.

스포츠 현장이나 손이 바쁜 상황에서는 녹음 종료 버튼을 누르는 것조차 번거로운 일이기 때문이다. 이번 포스팅에서는 Rust 오디오 라이브러리인 cpal과 hound를 사용하여 VAD(Voice Activity Detection)와 오디오 트리밍(Trimming)을 구현과정을 공유한다.

사용한 라이브러리 (Crates)

• cpal: Rust의 표준적인 로우레벨 오디오 입출력 라이브러리다. (WASAPI, CoreAudio, ALSA 등 지원)
• hound: WAV 포맷의 인코딩/디코딩을 쉽게 처리해주는 라이브러리다. [dependencies] cpal = "0.15" hound = "3.5"

핵심 시나리오

1. 녹음 시작: 사용자가 버튼을 누르면 녹음이 시작된다.
2. 묵음 감지 (Auto-Stop): 사용자가 말을 하다가 멈추면(약 2초간 침묵), 시스템이 이를 감지하고 녹음을 자동 종료한다.
3. 후처리 (Trimming): 자동 종료를 위해 기다렸던 2초간의 공백과, 말하기 전의 공백을 잘라내어 깔끔한 파일로 저장한다.

1. 묵음 감지 (Silence Detection) 구현

녹음을 계속 진행하면서 들어오는 오디오 샘플의 진폭(Amplitude)을 실시간으로 체크한다. 특정 임계값(threshold)보다 작은 소리가 일정 시간(max_silence_samples) 이상 지속되면 녹음을 중단하는 신호를 보낸다.

주요 코드 로직

  // 설정값
  let silence_threshold = 0.01; // 이 값보다 작으면 묵음으로 간주 (0.0 ~ 1.0)
  let sample_rate = config.sample_rate().0;
  let max_silence_samples = (sample_rate as usize) * 2; // 2초 분량의 샘플 수


  // 상태 공유를 위한 아토믹 변수
  let consecutive_silence = Arc::new(AtomicUsize::new(0));
  let stop_signal = Arc::new(AtomicBool::new(false));

  // ... (스트림 생성 코드 생략)


  // 샘플 처리 클로저
  move |data: &[f32], : &| {
      for &sample in data {
          // 절대값이 임계값보다 작으면 침묵 카운트 증가
          if sample.abs() < silence_threshold {
              let count = consecutive_silence.fetch_add(1, Ordering::Relaxed) + 1;

              // 2초 이상 침묵 시 정지 신호 발생
              if count >= max_silence_samples {
                  stop_signal.store(true, Ordering::Relaxed);
              }
          } else {
              // 소리가 감지되면 카운트 리셋
              consecutive_silence.store(0, Ordering::Relaxed);
          }

          // ... (채널로 데이터 전송)
      }
  }

이 로직 덕분에 사용자는 말을 끝낸 후 가만히 있으면, 약 2초 뒤에 녹음이 자동으로 종료된다.

2. 오디오 트리밍 (Trimming) 구현

VAD 방식으로 녹음을 종료하면 필연적으로 "말을 마친 후 2초간의 정적"이 파일 뒷부분에 포함된다. 이를 그대로 사용하여 재생 시 답답함을 유발하므로, 앞뒤의 묵음 구간을 잘라내야 한다.

단, 너무 칼같이 자르면 소리가 부자연스럽게 끊길 수 있으므로 0.2초 정도의 패딩(Padding)을 둔다.

  fn trim_silence(file_path: &Path) -> Result<f32> {
      // 1. 파일 전체를 읽어서 샘플 벡터로 변환
      let (spec, samples) = {
          let mut reader = hound::WavReader::open(file_path)?;
          let spec = reader.spec();
          let samples: Vec<f32> = reader.samples::<f32>().collect::<Result<Vec<>, >>()?;
          (spec, samples)
      let threshold = 0.01;

      // 2. 유효한 소리가 시작되는 지점과 끝나는 지점 찾기
      let start = samples.iter().position(|&s| s.abs() > threshold);
      let end = samples.iter().rposition(|&s| s.abs() > threshold);


      if let (Some(start_idx), Some(end_idx)) = (start, end) {
          // 3. 앞뒤로 0.2초씩 여유(Padding) 주기
          let padding_sec = 0.2;
          let padding_samples = (spec.sample_rate as f32 * padding_sec) as usize;


          let start_padded = start_idx.saturating_sub(padding_samples);
          let end_padded = (end_idx + padding_samples).min(samples.len() - 1);


          // 4. 해당 구간만 잘라서 다시 저장
          let trimmed_samples = &samples[start_padded..=end_padded];
          let mut writer = hound::WavWriter::create(file_path, spec)?;


          for &sample in trimmed_samples {
              writer.write_sample(sample)?;
          }
          writer.finalize()?;

          // 최종 재생 시간 반환
          return Ok(trimmed_samples.len() as f32 / spec.sample_rate as f32);
      }


      Ok(0.0) // 소리가 아예 없는 경우
  }

결과 및 장점

이러한 VAD + Trimming 구조를 적용하면 다음과 같은 이점이 있다.

1. UX 향상 (Hands-Free): "녹음 시작" 버튼 한 번만 누르면 된다. 장갑을 끼고 있거나 화면을 계속 볼 수 없는 환경에 매우 유용하다.

2. 데이터 효율성: 불필요한 공백을 제거하여 파일 용량을 줄이고, 전송 속도를 높인다.

3. 명확한 의사 전달: 재생 시 딜레이 없이 즉각적으로 음성이 나오므로, 피치컴(PitchCom)과 같은 신속한 명령 전달 장치에 적합하다.

   주의할 점: Threshold 튜닝

   silence_threshold 값(여기서는 0.01)은 환경에 따라 튜닝이 필요하다.

• 너무 낮으면: 주변 소음(바람 소리, 관중 소리) 때문에 녹음이 절대 안 끝날 수 있다.
• 너무 높으면: 작게 말하는 소리나 'ㅅ, ㅎ' 같은 고주파 발음이 잘려 나갈 수 있다.

실제 환경 테스트를 통해 적절한 값을 찾거나, 사용자 설정으로 빼두는 것이 좋다.

참고: 이 코드는 Tauri 앱의 백엔드(Rust) 부분에서 동작하며, 프론트엔드와는 비동기 커맨드로 통신한다. 웹 브라우저 API(MediaRecorder)를 쓰지 않고 네이티브 오디오 장치를 직접 제어함으로써 더 정밀한 제어가 가능했다.

Pulse Code Modulation의 약자 펄스 부호 변조는 음성이나 영상 같은 연속적인 아날로그 신호를 0과 1로 이루어진 디지털 신호로 변환하는 가장 대표적인 기술

배경

통신 잡음

1930년대 아날로그 통신 시대에는 신호를 멀리 보낼수록 신호가 약해졌고, 이를 다시 키우기 위해 증폭기를 사용해야 했다. 하지만 증폭기는 신호뿐만 아니라 함께 섞인 잡음(Noise)까지 그대로 키워버리는 치명적인 단점이 있었다. 거리가 멀어질수록 잡음이 누적되어 통화 품질이 급격히 떨어지는 것이 당시 통신업계의 가장 큰 고민이었다.

알렉 리브스의 아이디어

1937년 영국의 엔지니어인 알렉 리브스(Alec Reeves)는 신호를 아예 '숫자(디지털)'로 바꾸어 전송하면 이 문제를 해결할 수 있다고 생각했다.

소리의 높낮이를 숫자로 바꿔 보내면, 전송 중에 잡음이 섞여 신호가 조금 일그러지더라도 수신측에서는 그것이 '0'인지 '1'인지 명확히 구별할 수 있고 숫자를 원래대로 복원하기만 하면 잡음 없는 깨끗한 원래의 소리를 되찾을 수 있게 된 것이다.

기술적 한계

알렉 리브스는 1937년에 PCM 이론을 정립하고 특허를 냈지만, 당시 진공관 기술로는 복잡한 디지털 변환 회로를 경제적으로 구현하기 어려워 한동안 묻혀 있었다. 그러다 제2차 세계대전 중 보안이 중요한 군사용 암호 통신(예: SIGSALY 시스템)에 먼저 도입되며 그 가치를 인정받기 시작했다.

반도체 시대

1960년대 이후 트랜지스터와 반도체 기술이 발전하면서 복잡한 회로를 작고 저렴하게 만들 수 있게 되자, 1962년 벨 연구소의 T1 캐리어 시스템을 시작으로 일반 전화망에 PCM이 본격적으로 보급되었다.

CD, MP3, 유튜브의 모든 디지털 사운드는 이 탄생 배경을 뿌리에 두고 있다.

과정

변조

표본화

나이퀴스트 이론에 따라 아날로그 파형을 일정한 시간 간격으로 잘라 순간적인 진폭값을 추출한다.

샘플링된 진폭의 집합인 PAM(Pulse Amplitude Modulation) 신호가 생성된다.

나이퀴스트 이론 원래의 소리를 완벽하게 복원하려면, 소리가 가진 최고 주파수의 2배 이상의 속도로 샘플을 채취해야 한다.
인간의 가청 주파수가 약 20kHz이므로, CD 음질은 그 2배인 44.1kHz(1초에 44,100번)로 샘플링

양자화

표본화로 얻은 연속적인 진폭값을 미리 정해진 이산적인(떨어져 있는) 수치로 매칭시키는 과정이다. 세로축(진폭)을 일정한 단계(Level)로 나누고, 측정된 값이 어느 단계에 가장 가까운지 결정한다.

비트 심도 (Bit Depth)

단계를 얼마나 세밀하게 나누느냐를 결정한다.

• 8비트: 2^8 = 256 단계로 소리 크기를 조절
• 16비트: 2^16 = 65,536 단계로 조절 (CD 음질)

이 과정에서 필연적으로 발생하는 오차를 양자화 잡음이라고 한다.

양자화 잡음 (Quantization Noise) 실제 아날로그 값과 디지털로 변환된 근삿값 사이의 미세한 차이를 말한다. 비트 수가 높을수록 이 오차(잡음)가 줄어든다.

부호화

양자화된 수치 데이터를 2진수(0과 1) 형태의 디지털 코드로 최종 변환한다. 양자화 단계에서 할당된 10진수 값을 2진법 코드로 바꾼다.

• 예시: 특정 시점의 소리 크기가 '7'번 단계였다면, 이를 3비트 부호화하여 111로 기록

결과물

우리가 흔히 말하는 순수 디지털 데이터(Binary Stream)가 완성된다. 이 데이터가 PCM이며 파일(WAV 등)로 저장되거나 통신망을 통해 전송된다.

요약

변조(ADC) : 소리(곡선) → 점 찍기(표본) → 반올림(양자) → 숫자(0, 1)

복조

복조(Demodulation) 과정은 한 마디로 '숫자(0, 1)를 다시 소리의 파형으로 되돌리는 역과정', 위 3단계를 정확히 거꾸로 거슬러 올라간다고 생각하면 쉽다.

재생

전송된 0과 1의 디지털 신호를 다시 읽어 들이는 단계, 전송 과정에서 섞인 잡음을 제거하고, 원래의 깨끗한 '0'과 '1'의 전기적 펄스(부호)를 복원한다. 디지털은 신호가 조금 찌그러져도 0인지 1인지 판별만 가능하면 원래 신호로 100% 복구할 수 있다.

복호화

이진수(0, 1) 데이터를 다시 원래의 양자화된 수치(높이 값)로 바꾸는 과정, 예를 들어 111이라는 데이터를 받았다면, 이를 다시 7이라는 진폭 레벨로 해석한다. 일정한 시간 간격마다 서로 다른 높이를 가진 계단 모양의 펄스(PAM 신호)가 만들어진다.

보간 및 필터링

가장 중요한 단계로, 각진 계단 모양의 신호를 부드러운 곡선(아날로그 파형)으로 만드는 과정, 저역 통과 필터(Low Pass Filter)를 통과시킨다. 이 필터는 급격하게 변하는 계단식의 고주파 성분을 깎아내고, 점과 점 사이를 부드럽게 이어주는 역할을 한다.

결과

우리가 스피커나 이어폰을 통해 들을 수 있는 매끄러운 아날로그 전기 신호(소리)가 완성된다.

요약

복조(DAC): 숫자(0, 1) → 숫자 읽기(복호) → 계단 만들기 → 부드럽게 잇기(필터) → 소리(곡선)

특징

잡음에 강함

아날로그와 달리 신호가 감쇄되더라도 재생 중계기를 통해 원래의 디지털 신호(0 또는 1)를 완벽하게 복원할 수 있어 전송 품질이 우수.

범용성

컴퓨터, CD, DVD, 디지털 전화 등 현대 거의 모든 디지털 오디오 기기의 표준 포맷으로 사용됨.

효율적 전송

여러 회선의 신호를 하나의 전송로에 묶어 보내는 시분할 다중화(TDM) 방식이 가능해져 통신 효율이 높음.

WAV(Waveform Audio File Format)는 마이크로소프트와 IBM이 개발한 표준 오디오 파일 형식으로, 오디오 데이터를 압축 없이 그대로 저장하여 원본에 가까운 무손실 고음질을 제공한다. 주로 윈도우 환경에서 사용되며, CD와 동일한 PCM 데이터를 사용하여 용량이 크지만 전문적인 음향 편집에 적합하다.

배경

WAV가 등장하기 전에는 각 컴퓨터 시스템이나 애플리케이션마다 서로 다른 오디오 포맷을 사용해 호환성이 매우 떨어졌다. Microsoft와 IBM은 Windows 3.1 출시와 함께 누구나 보편적으로 사용할 수 있는 오디오 파일의 표준 규격을 만들고자 했다.

이전 방식

MIDI

Musical Instrument Digital Interface의 약자로 실제 소리를 녹음한 게 아니라 '악기 연주 정보(악보)'만 담은 파일, 용량은 매우 작지만, 컴퓨터 사운드 카드의 성능에 따라 소리 품질이 천차만별이었다.

저품질 모노 녹음

용량을 아끼기 위해 샘플링 레이트를 극단적으로 낮춘(8-bit, 11kHz~22kHz) 모노 음원들이 사용되었다. 라디오보다 못한 지지직거리는 음질이 당시의 일반적인 '컴퓨터 소리'였다.

WAV 등장

44.1kHz, 16-bit 스테레오(CD 음질)를 지원하는 WAV의 등장은 컴퓨터에서도 가전 오디오(CD 플레이어) 수준의 깨끗한 소리를 낼 수 있다는 것을 의미했다. 비록 용량은 컸지만, 별도의 압축 해제 과정이 필요 없는 비압축 방식이었기에 당시 낮은 CPU 사양에서도 끊김 없이 고음질 오디오를 재생할 수 있는 최선의 선택이었다.

RIFF 구조

WAV는 데이터를 chunk 단위로 저장하는 RIFF(Resource Interchange File Format)라는 큰 구조 안에 오디오 데이터를 담는 방식으로 설계되었다.

유연성

단순 오디오 정보뿐만 아니라 제작자, 샘플 레이트 등 다양한 메타데이터를 함께 담을 수 있었다.

직관성

압축되지 않은 날것의 데이터(PCM)를 그대로 담았기 때문에, 당시 사양의 컴퓨터에서도 복잡한 연산 없이 소리를 즉각 재생하고 편집하기에 유리했다.

활용

1990년대 초반

Windows의 부팅음이나 시스템 알림음의 기본 포맷으로 채택되며 대중에게 알려지기 시작했다. PC에서 CD 수준의 고음질을 재생할 수 있는 거의 유일한 방법이었으며, 초기 멀티미디어 백과사전이나 게임의 음원으로 활용되었다.

1990년대 후반~2000년대

표준화

현재는 전 세계 음악 및 방송 산업의표준 마스터 포맷으로 진화했다. 무손실의 고음질 덕분에 일반 감상용을 넘어 전문 음악 제작 및 방송 분야의 골드 표준으로 자리 잡게 되었다. 유럽방송연맹(EBU)이 WAV를 기반으로 메타데이터를 강화한 BWF(Broadcast Wave Format)를 표준으로 정하면서 전문 방송 및 영화 산업의 필수 포맷이 되었다.

인터넷과 MP3

1990년대 중반 모뎀(Dial-up) 속도로 30MB의 WAV 노래 한 곡을 받으려면 수 시간이 걸렸다. (사실상 온라인 전송이 불가능)

인터넷 속도가 느려, 용량이 큰 WAV는 감상용으로는 부적합했다. 일반 사용자들은 MP3로 옮겨갔지만, 전문가들은 원본 보존을 위해 여전히 WAV를 고수했다.

MP3는 가청 주파수 밖의 데이터를 삭제해 음질은 유지하면서 용량을 3~4MB로 줄였다. 덕분에 수분 내에 다운로드가 가능해졌고, 비로소 '음악 파일'이 인터넷을 타고 흐르기 시작했다.

현재

전문 음향 작업

데이터 손실 없이 무한 수정이 가능하여, 현재도 모든 음악 레코딩 및 믹싱 단계에서 기본으로 사용된다.

고음질 스트리밍의 뿌리

FLAC이나 ALAC 같은 최신 무손실 압축 포맷도 결국 원본인 WAV 데이터를 압축한 것이므로, 모든 고음질 음원의 '마스터 파일' 역할을 수행한다.

기술적 확장

현대의 WAV는 초기의 단순함을 넘어 멀티채널 서라운드 사운드(5.1채널 등)와 고해상도 오디오(192kHz/32-bit 이상)를 모두 담는 유연한 컨테이너로 발전했다.

• Leptos는 특징이 웹어셈블리 베이스로 동작한다.
• 가상DOM을 사용하지 않고 직접 DOM노드를 수정한다.(리액트 보다 2배 빠른 성능을 내기도 한다.)
• Rust의 타입시스템과 효율적인 메모리관리 덕분에 복잡한 UI에서도 굉장히 좋은 유저 경험을 선보인다.

가상돔을 사용하지 않고 DOM을 직접 컨트롤하는부분과 컴파일타임 프레임이라는 점이 Sevelte와 매우 유사한거 같다. (개인적으로 Svelte를 좋아한다.)

JS Framework Benchmark

Leptos:  ~250ms
React:   ~450ms
차이:    +80% 느림 (React)

Leptos:  ~35MB
React:   ~75MB
차이:    +114% 더 많음 (React)

Leptos:  ~150ms (WASM 로드 포함)
React:   ~200ms
차이:    +33% 느림 (React)

이제 본격적으로 Leptos를 시작해보자

환경구성

# Trunk는 Rust 용 WASM 웹 응용 프로그램 번들러
cargo install trunk

Rust 프로젝트 생성

# 프로젝트 이름을 ui로 만든다.
cargo new ui

# 이동
cd ui

# 구조 확인
tree 

├── Cargo.toml
└── src
    └── main.rs

target 설치

#웹어셈블리 바이너리 형식으로 빌드할 수 있도록 필요한 도구(타겟)를 설치
rustup target add wasm32-unknown-unknown

의존성 추가

Cargo.toml에 의존성을 추가해준다.

[package]
...

[dependencies]
# leptos 추가 (Client Side Rendering을 하는 앱을 위해 features를 csr 로 하였다.)
leptos = { version = "0.8.15", features = ["csr"] }

index.html 생성

프로젝트 최상단에 index.html을 만든다.

├── Cargo.lock
├── Cargo.toml
├── index.html # 생성
└── src
    └── main.rs

index.html

<!doctype html>
<html>
    <head></head>
    <body></body>
</html>

main.rs 작성

use leptos::prelude::*;

fn main() {
    leptos::mount::mount_to_body(|| view! { <p>"Hello, world!"</p> })
}

실행해보기

# 실행
trunk serve

터미널에 표시된 주소를 열면 잘 내용이 잘 나오는걸 볼 수 있다.

공식 홈페이지에서 강력하게 개발 Toolkit을 설치하여 개발환경 셋팅을 하지 말라는 것이었다. 하고 싶다면 Docker를 설치해서 환경을 구성하라는건데...

나는 구형 DS218j 모델이라 도커를 설치 할 수 가 없다... 그냥 외부에서 작업해서 크로스컴 파일 해서 사용하는 수 밖에 없을 것 같다.

./example: /lib/libc.so.6: version `GLIBC_2.28' not found (required by ./example)
./example: /lib/libc.so.6: version `GLIBC_2.30' not found (required by ./example)
./example: /lib/libc.so.6: version `GLIBC_2.33' not found (required by ./example)
./example: /lib/libc.so.6: version `GLIBC_2.32' not found (required by ./example)
./example: /lib/libc.so.6: version `GLIBC_2.34' not found (required by ./example)

개발 환경에서는 잘 실행되던 프로그램이 타겟 시스템에서는 GLIBC 버전 문제로 실행되지 않는 것이다.

원인 분석

빌드 환경의 GLIBC 버전(2.34)과 타겟 시스템의 GLIBC 버전(2.27 이하)이 맞지 않아 발생하는 호환성 문제다.

GLIBC 동적 링크 바이너리는 시스템의 libc.so.6 등의 공유 라이브러리에 의존하기 때문에, 타겟 시스템에 호환되는 버전의 라이브러리가 필요하다.

해결 방법

크게 두 가지 접근 방법이 있다:

1. GLIBC 버전 맞추기 - 타겟 시스템 업그레이드 또는 낮은 버전으로 재빌드
2. musl 정적 링크 - 외부 의존성을 제거하여 모든 환경에서 실행 가능

musl이란?

musl은 경량 C 표준 라이브러리로, 정적 링크에 최적화되어 있다. GLIBC의 대안으로 특히 임베디드 시스템과 컨테이너 환경에서 널리 사용된다.

주요 특징

장점:

• 정적 링크 최적화 - 단일 실행 파일 생성 용이
• 높은 이식성 - GLIBC 버전과 무관하게 실행
• 작은 크기 - GLIBC보다 가볍고 컴팩트
• 의존성 제거 - 시스템 라이브러리 불필요
• 배포 간소화 - 단일 파일만 전송

단점:

• 약간의 성능 저하 (5-10%, 특히 멀티스레딩)
• 일부 GLIBC 전용 기능 미지원
• 정적 링크로 인한 바이너리 크기 증가

GLIBC vs musl 비교

의존성 비교

GLIBC 빌드: $ ldd example libc.so.6 => /lib/libc.so.6 libm.so.6 => /lib/libm.so.6 ...

musl 정적 빌드: $ ldd example not a dynamic executable

언제 musl을 사용하나?

• musl이 적합한 경우

  • CLI 도구, 유틸리티

  • 컨테이너/Docker 이미지 (Alpine Linux)

  • 임베디드 시스템

  • 다양한 환경에 배포해야 하는 경우

  • 구형 시스템에 배포하는 경우

• GLIBC가 적합한 경우

  • 최고 성능이 필요한 서버 애플리케이션
  • GUI 애플리케이션 (GTK, Qt 등)
  • 복잡한 C 라이브러리 의존성이 있는 경우

musl을 선택한 이유

대상 환경은 Synology NAS이다. Synology DSM은 시스템 핵심 라이브러리인 GLIBC를 함부로 업데이트할 수 없는 환경이다. GLIBC 버전을 변경하면 DSM 전체가 불안정해지거나 부팅 불가 상태가 될 위험이 있다. 이러한 제약 때문에 시스템 라이브러리에 의존하지 않는 musl 정적 링크 방식을 선택했다.

musl로 빌드하기

필수 도구 설치

sudo apt update
sudo apt install musl-tools gcc-arm-linux-gnueabihf

Rust 타겟 추가

rustup target add arm-unknown-linux-musleabihf

Cargo 설정

# ~/.cargo/config.toml 파일에 링커 설정 추가
[target.arm-unknown-linux-musleabihf]
linker = "arm-linux-gnueabihf-gcc"

빌드

cargo build --target arm-unknown-linux-musleabihf --release

빌드된 바이너리는 target/arm-unknown-linux-musleabihf/release/ 디렉토리에 생성된다.

잘 실행이 되었다.

Hardware Specs

DS218j의 하드웨어 스펙 참고로 32bit 이다. Docker를 지원하지 않는다...

SSH 접속

먼저 ssh로 NAS에 접속한다.

Rust 설치

rustup.rs 링크에서 리눅스용 터미널 커맨드를 복사 붙여 넣기 하였다.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

그랬더니 오류가 나왔다.

오류 발생1

error: Cannot execute /tmp/tmp.lSpi4HlAnJ/rustup-init (likely because of mounting /tmp as noexec).
error: Please copy the file to a location where you can execute binaries and run ./rustup-init.

검색해보니 noexec 옵션 때문에 /tmp를 사용 할 수 없다는 것이었다.

해결방법

방법1

#홈 디렉터리에 tmp폴더 만들기
mkdir -p ~/tmp  
#Rust 설치스크립트 다운로드
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs -o ~/rustup-init.sh
#실행 권한 부여
chmod +x ~/rustup-init.sh
#홈 디렉터리 tmp를 임시폴더로 설정 및 실행
TMPDIR=~/tmp ~/rustup-init.sh

방법2

# 임시 해제 (재부팅 시 초기화)
sudo mount -o remount,exec /tmp
# 설치
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

설치 화면이 잘 나온다.

설치완료

버전 확인

오류 발생2

error: linker `arm-linux-gnueabihf-gcc` not found
  |
  = note: No such file or directory (os error 2)

error: could not compile `api-server` (bin "api-server") due to 1 previous error

Rust가 크로스 컴파일 링커를 찾지 못하고 있어서 인데 외부에서 크로스 컴파일을 하거나 Docker를 사용하라는 솔루션이 있는데 Docker를 지원하지 않기 때문에 어쩔 수 없이 외부에서 빌드를 해서 실행 하는 방향으로 생각해봐야겠다.

결론

설치는 할 수 있으나. 컴파일이 되지 않는다.

프로젝트 생성하기

기존 프로젝트에서 새로운 프로젝트를 생성해준다.

    cargo new <새로운 워크스페이스 이름>

Workspace 추가

root에 위치한 Cargo.toml 파일에 workspace 테이블을 만들고 resolver,member키를 선언하고 값을 입력해준다.

resolver

Cargo에서 지원하는 프로젝트 dependency의 feature 조합을 계산하는 기능이다.

주요 차이점: resolver = "1": 오래된 방식 resolver = "2": dev-dependencies가 일반 dependencies의 feature에 영향을 주지 않음, edition 2021 부터는 2이 기본값이다. resolver = "3": Rust 1.84+ 필수, MSRV(Minimum Supported Rust Version) 관리 개선, edition 2024 부터는 3이 기본값이다.

members

어떤 패키지를 멤버로 사용할지 정의한다. 대괄호를 사용하여 (경로가 포함 된)디렉토리 이름을 문자열로 선언해줍니다.

이렇게 해놓으면 root에서 cargo build를 수행하여도 하위 workspace들까지 모두 한번에 build가 된다.

Workspace 사용해보기

의존성 추가

main.rs 를 lib.rs 로 변경한다. 그리고 fn main을 다른 함수로 작성한다. main.rs를lib.rs로 만드는 이유는 이 프로젝트를 실행 가능한 프로그램이 아닌 재사용 가능한 라이브러리로 전환한다는 의미이다.

root Cargo.toml의 depentancies 테이블에 의존성을 등록해준다.

root의 main.rs에 하위 워크스페이스의 함수를 호출하는 코드를 작성한다.

실행을 시키면 잘 동작한다.

그래서 Workspace를 사용하면 뭐가 좋은가?

빌드 시간 단축

독립적 컴파일, 증분 빌드

모노리스 프로젝트로 관리하게 되면 파일 하나만 변경하여도 전체를 다시 컴파일 해야 할 수 도 있지만 워크스페이스를 사용하여 여러 크레이트(패키지)로 관리하면 변경되지 않은 크레이트의 컴파일 결과물을 재사용하게 되어 시간 단축이 있다.

의존성 관리 효율화 및 일관성

단일화

워크스페이스 내의 모든 크레이트는 하나의 Cargo.lock 파일을 공유하게 된다.

버전 통일

단일 Cargo.lock 파일을 통해 모든 크레이트가 동일한 버전의 의존성을 사용하도록 보장하고, target 폴더를 공유하여 중복 빌드를 방지한다.

코드 구조화 및 모듈화

논리적 분리

애플리케이션의 핵심 로직, CLI 도구, API 서버 등 분리하여 관리 할 수 있다.

코드 재사용

공통으로 사용하는 유틸리티나 데이터 모델을 별도의 라이브러리로 만들어 다른 크레이트에서 쉽게 재사용을 할 수 있다.

관심사 분리

각 크레이트가 자신만의 책임을 갖게 되어 코드 베이스가 깔끔해지고 유지보수가 용이해 진다.

개발 워크플로우 최적화

한번에 빌드/테스트

cargo <command> --workspace 명령을 사용해서 root에서 모든 크레이트를 한번에 빌드하거나 테스트 할 수 있다.

언제 사용해야 하나

• 프로젝트가 커져서 빌드 시간이 답답하게 느껴질 때
• 하나의 프로젝트 안에 여러 개의 실행 파일(Binary)이나 라이브러리가 공존할 때
• 공통 코드를 여러 곳에서 공유해야 할 때

Cargo Book

cargo new <프로젝트 이름>

프로젝트 이름은 Rust 언어가 사용하고 있는 예약 키워드로 프로젝트 이름을 만들 수는 없다. 그렇게 하고 싶다면 예약 키워드가 아닌 다른 이름으로 프로젝트를 만든 뒤 Cargo.toml에서 name을 변경해야 한다.

프로젝트가 생성되었다. 코드 편집기를 이용해서 프로젝트를 열어보자

프로젝트를 생성하면 이런 구조가 만들어진다.

EXAMPLE
|   .gitignore    # git에서 추적을 무시해야하는 파일 목록 파일
|   Cargo.toml    # Cargo 설정 파일 
\---src
        main.rs    # 러스트 소스코드

main.rs

main.rs 파일을 열어보면 Hello, world! 를 출력하는 기본 코드가 작성되어 있다.

해당 경로로 터미널을 열어서 cargo build 를 해준다.

cargo run 으로 실행을 해주면 Hello world! 가 출력된다.

cargo build를 안하고 바고 cargo run을 해주어도 된다. cargo run을 하면 build를 수행하고 실행한다.

실행 할때 나오는 빌드 관련 출력이 보고 싶지 않다면 -q 옵션(quiet) 로 실행하면 빌드 관련된 출력이 없이 프로그램 출력만 나온다.

Cargo.toml

package

소스 파일과 패키지를 설명하는 매니패스트 파일 모음집이다.

name

패키지 이름은 패키지를 참조하는 데 사용되는 식별자이다 이는 다른 패키지의 종속성으로 나열될 때 사용되며 유추된 lib 및 bin 대상의 기본 이름으로 사용된다. 이름은 영문과숫자만 사용 할 수 있으며 -나_로 구분자를 줄 수 있다.

한글을 섞었을때 실패

이모지를 섞었을때 실패

영문과 _, 숫자를 섞었을때 성공

version

SemVer 사양에 따라 형식이 지정된다. 버전에는 주 버전, 부 버전, 패치 버전의 세 가지 숫자 부분이 있어야 한다.

주 버전, 부 버전, 패치 버전 구성을 지키지 않았을때

뒤에 -를 붙여서 알파/베타 버전용으로 만들 수 있다.

+를 붙여서 메타데이터를 추가 할 수 있다. 정보 제공 목적이고 Cargo에서 무시된다고 한다.

edition

edition 키는 패키지가 컴파일되는 Rust 에디션에 영향을 미치는 선택적 키이다. 테스트 스위트, 벤치마크, 바이너리, 예제 등을 포함한 패키지의 모든 대상/크레이트에 영향을 미친다. 에디션 필드를 입력하지 않으면 자동으로 2015 에디션으로 동작하게 된다.

Rust

설치

Y 입력

원하는 설치 타입선택 1번 기본설치 (그냥 엔터누르면 1번으로 설치됨)

설치완료 (하단에 나온 메시지 대로 환경 변수 편집에서 bin 경로 등록)

환경변수 설정

시스템 환경변수 편집에 들어간다.

환경 변수(N)... 클릭

상단에 Path 더블클릭

여러 값들이 있는데 <메인드라이버>:\Users<유저이름>.cargo\bin 가 있는지 확인 없다면 새로만들기 해서 등록해주면 된다.

터미널 켜서 cargo --version 입력하여 버전이 출력된다면 설치가 완료 된것이다.