주머니 속 가속도계라는 센서

폰 안의 작은 저울

스마트폰에는 가속도계가 들어 있다. 화면 방향을 바꾸고, 걸음 수를 세고, 게임에서 기울기를 읽는 그 센서다.

원리는 의외로 단순하다. 아주 작은 추가 스프링에 매달려 있고, 기기가 움직이면 추가 관성 때문에 조금 뒤처진다. 그 밀림의 정도를 전기적으로 읽는다.

이런 구조를 통틀어 MEMS라 부른다. 반도체 공정으로 만든 미세 기계 장치다. 크기가 밀리미터 이하이고 값이 아주 싸다. 그래서 모든 폰에 들어갈 수 있었다.

우리 프로젝트가 성립하는 근거가 바로 이것이다. 이미 수천만 대가 도로 위를 돌아다니고 있다.

무엇을 재는가

가속도계는 세 방향의 가속도를 잰다. 폰을 기준으로 좌우, 위아래, 앞뒤.

여기서 첫 번째 주의점이 나온다. 중력도 가속도로 잡힌다.

가만히 놓아둔 폰도 아래 방향으로 약 9.8의 값을 읽는다. 지구가 당기는 힘 때문이다. 그래서 측정값에는 항상 중력이 섞여 있고, 이걸 분리해야 실제 움직임을 알 수 있다.

그리고 폰이 기울어져 있으면 중력이 세 축에 나뉘어 들어간다. 컵홀더에 비스듬히 놓인 폰은 “아래”가 어느 축인지 모른다.

그래서 첫 작업은 방향 정렬이다. 정지 상태나 등속 주행 구간에서 중력 방향을 찾아, 그것을 기준으로 축을 돌려 세운다. 그러면 “노면에 수직인 방향”을 알 수 있고, 우리가 관심 있는 상하 진동을 뽑아낼 수 있다.

얼마나 자주 재는가

두 번째로 중요한 것이 표본율이다. 초당 몇 번 측정하는가.

폰의 가속도계는 대개 초당 수십에서 수백 회 측정할 수 있다. 앱에서 설정할 수 있는 값이다.

여기에 신호 처리의 기본 제약이 걸린다. 측정 속도의 절반보다 빠른 진동은 제대로 잡을 수 없다. 초당 100회 측정하면 초당 50번 이하로 떠는 것까지만 안전하게 다룰 수 있다.

14편에서 우리가 관심 있는 대역이 “초당 열 번에서 스무 번” 정도라고 했다. 그러면 초당 100회 정도의 측정으로 충분하다. 여유를 두려면 200회.

그리고 이건 폰이 감당할 수 있는 수준이다. 배터리와 저장 공간에 부담이 되지 않는다. 우리가 다루려는 대역이 다행히 폰의 능력 안에 있다.

만약 훨씬 빠른 진동을 봐야 했다면 이 프로젝트는 성립하지 않았을 것이다.

전용 계측기와 무엇이 다른가

정직하게 비교해 보자.

	전용 진동 계측기	폰 가속도계
정확도	높다	낮다
잡음	적다	많다
값의 안정성	교정되어 일정	기기·온도에 따라 흔들린다
부착 상태	단단히 고정	제각각
측정 위치	원하는 곳	차 안, 사람 마음대로
대수	몇 대	수천만 대
비용	높다	0

앞의 다섯 줄은 전부 폰이 불리하다. 뒤의 두 줄만 유리하다.

그런데 이 프로젝트의 전제는 뒤의 두 줄이 앞의 다섯 줄을 이길 수 있다는 것이다. 1부와 2부에서 계속 말한 원리다. 정밀도를 장비가 아니라 반복으로 확보한다.

폰만의 문제들

폰을 쓰기 때문에 생기는 고유한 문제가 몇 가지 있다. 이건 신호 처리로 다뤄야 한다.

거치 상태가 제각각이다. 단단한 거치대, 컵홀더, 시트, 주머니, 가방. 각각 다른 필터가 하나 더 붙는 셈이다. 특히 주머니나 가방 안의 폰은 자기 나름대로 덜컹거려서 노면 신호를 심하게 왜곡한다.

대응: 신호의 성격으로 거치 상태를 추정해 분류하고, 신뢰할 수 없는 상태의 데이터는 무게를 낮춘다. 거치대에 고정된 상태의 데이터를 우대한다.

기기마다 다르다. 같은 흔들림에 대해 기종마다 조금씩 다른 값을 읽는다. 교정되지 않은 센서들이다.

대응: 절대값을 쓰지 않는다. 같은 기기 안에서의 상대적 변화만 본다. “이 기기가 이 구간에서 읽은 값이, 같은 기기가 다른 구간에서 읽은 값에 비해 어떤가.”

운영체제가 측정을 방해한다. 앱이 백그라운드에 있으면 측정 주기가 불규칙해지거나 중단된다. 배터리 절약 기능이 개입한다.

대응: 측정 시각을 함께 기록하고, 간격이 불규칙한 구간은 보간하거나 버린다. 가장 흔한 실패 원인이 물리가 아니라 운영체제의 제약이라는 것이 현실이다.

배터리를 쓴다. 상시 측정과 위치 기록은 전력을 소모한다.

대응: 주행 중에만 측정한다. 차에 탔는지는 폰이 이미 판단할 수 있다. 그리고 데이터를 그때그때 보내지 않고 모아서 와이파이에 연결될 때 올린다.

그래서 무엇을 저장하나

여기서 설계 판단이 하나 있다. 원본 신호를 다 저장할 것인가.

초당 100회 × 3축으로 계속 기록하면 데이터가 상당히 쌓인다. 하루 두 시간 운전이면 수백만 개의 숫자다. 이걸 다 서버로 보내는 것은 통신비와 저장비가 부담이고, 13편에서 말한 개인정보 원칙에도 어긋난다.

그래서 폰에서 먼저 요약한다.

• 짧은 구간(예: 몇 초)마다 신호의 특징값만 계산한다
• 그 특징값과 위치, 속도, 시각만 서버로 보낸다
• 원본 신호는 신고가 있었던 구간 주변만 남긴다

이러면 데이터가 크게 줄고, 이동 경로 전체가 서버에 쌓이지 않는다.

다만 대가가 있다. 나중에 “다른 특징값을 봤어야 했다”고 깨달아도 원본이 없다. 처음에 무엇을 저장할지 정하는 결정이 나중의 분석 가능성을 제한한다.

그래서 초기에는 신고 주변 구간의 원본을 넉넉히 남기기로 했다. 그게 4부의 학습에 쓰일 재료이기 때문이다. 어떤 특징이 중요한지 아직 모르는 단계에서는 원본이 필요하다.

다음 편에서 그 특징값을 만드는 핵심 도구를 다룬다. 시간축의 신호를 주파수축으로 옮기는 변환이다.

---

다음 편 예고 — 시간을 주파수로 — 푸리에 변환. 겹쳐진 흔들림을 성분으로 나누는 방법을, 수식 대신 그림과 비유로 이해한다.