임베디드 시스템은 기계 안에 들어가서 한 가지 일만 하는 작은 컴퓨터입니다. 세탁기, 도어락, 자동차 안의 제어 장치가 모두 임베디드 시스템입니다. 노트북처럼 아무 프로그램이나 돌리는 게 아니라 할 일이 정해져 있고, 대신 크기·전력·가격이 빠듯하다는 제약이 있습니다.

여기에 AI 모델이 들어가면 AI 임베디드 시스템입니다. 핵심은 "모델이 혼자 일하지 않는다"는 점입니다. 파이썬 수업에서는 model(x) 한 줄이면 끝났지만, 실제 기기에서는 그 x를 만들고 결과를 써먹는 과정이 앞뒤로 붙습니다. AI 도어락으로 한 바퀴를 따라가 보면 이렇습니다.

1. 센서·카메라: 카메라가 문 앞을 찍습니다.
2. 전처리: 사진을 모델이 원하는 224×224 크기로 줄이고(resize), 픽셀값 0~255를 0~1로 바꿉니다(normalization).
3. AI 추론: 모델이 "등록된 사람일 확률 0.93"이라는 숫자를 냅니다.
4. 후처리·판단: 0.9 이상일 때만 인정하고(confidence threshold), 3프레임 연속으로 인정될 때만 최종 판단합니다(temporal filtering). 한 장만 잘못 나와도 문이 열리는 걸 막기 위해서입니다.
5. 출력·액추에이터: 잠금장치 모터가 돌아 문이 열립니다.
6. 피드백: 문이 열리고 사람이 들어오면 문 앞 장면이 바뀌고, 그 장면이 다음 사진으로 다시 들어옵니다. 그래서 고리(폐루프) 모양입니다.

이 중 하나라도 잘못되면 모델이 아무리 정확해도 시스템은 실패합니다. 카메라가 어두우면 입력부터 틀리고, 후처리 기준이 너무 낮으면 엉뚱한 사람에게 문이 열립니다. 출력이 모터·잠금장치 같은 실제 물건이라서 작은 오류가 곧바로 안전 문제가 됩니다.

네 단어가 헷갈리는 이유는 서로 다른 질문에 대한 답이기 때문입니다. 질문으로 바꿔 보면 구분이 쉬워집니다.

• IoT: "이 기기가 네트워크에 연결돼 데이터를 주고받나?" 스마트폰으로 켜고 끄는 스마트 전구도 IoT입니다. AI가 없어도 됩니다.
• Edge Computing: "데이터를 멀리 있는 서버 말고, 데이터가 생긴 곳 가까이에서 처리하나?" 공장 게이트웨이가 센서 값의 평균만 내도 Edge Computing입니다. 역시 AI가 없어도 됩니다.
• Edge AI: "그 가까운 곳에서 하는 처리가 AI 추론인가?"
• On-device AI: "그 AI가 데이터를 만든 바로 그 기기 안에서 도나?"
• Cloud AI: "데이터를 인터넷으로 멀리 있는 서버에 보내서 AI를 돌리나?"

포함 관계: Edge AI의 "가까운 곳"에는 기기 자기 자신과 같은 건물의 gateway·서버가 모두 들어갑니다. On-device AI는 그중 "기기 자기 자신"인 경우만 말합니다. 그래서 On-device AI는 Edge AI의 일부(On-device AI ⊂ Edge AI)이고, 반대로 공장 서버에서 돌리는 AI는 Edge AI이지만 On-device AI는 아닙니다.

Jetson 예시가 말하는 것도 같습니다. 판단 기준은 장비 이름이 아니라 "데이터를 만든 기기와 AI를 돌린 기기가 같은가?"입니다. 로봇에 달린 카메라 영상을 로봇 안의 Jetson이 처리하면 같은 기기라서 On-device AI, 천장 카메라 여러 대의 영상을 따로 놓인 Jetson이 받아 처리하면 다른 기기라서 Gateway 기반 Edge AI입니다.

Cloud AI의 흐름을 먼저 떠올려 보세요. 카메라 → 인터넷 → 서버에서 추론 → 다시 인터넷 → 카메라로 결과 도착. 이 왕복 때문에 세 가지 문제가 생기고, 기기 안에서 처리하면 이 세 가지가 함께 줄어듭니다.

• Communication(통신): 영상은 데이터가 매우 큽니다. 3장에서 계산하겠지만 640×480 영상을 30 FPS로 보내면 1초에 약 27.6 MB입니다. 이걸 계속 보내면 통신 요금과 서버 비용이 들고, 인터넷이 끊기면 시스템이 멈춥니다. 기기 안에서 처리하면 "사람 있음" 같은 짧은 결과만 보내면 됩니다.
• Privacy(개인정보): Cloud로 보내면 얼굴·목소리 원본이 회사 서버로 나가고 저장됩니다. 기기 안에서 처리하면 원본은 밖으로 나가지 않습니다. 다만 기기를 도난당하거나 해킹당하면 안에 있는 데이터가 새어 나갈 수 있으므로, 접근 제어·암호화·기록 관리는 따로 해야 합니다. 그래서 교안이 "로컬 처리 = 자동으로 안전"은 아니라고 강조합니다.
• Latency(지연): 서버까지 갔다 오는 왕복 시간(RTT)과, 서버에서 다른 사람 요청 뒤에 줄 서서 기다리는 시간(queue)이 듭니다. 자율주행차가 보행자를 보고 바로 멈춰야 하는데 인터넷이 잠깐 느려지면 큰일이 나겠죠. 그래서 평균 지연뿐 아니라 가끔 생기는 가장 나쁜 지연도 함께 봐야 합니다.

표는 "어디서 AI를 돌릴지"를 고르는 비교표입니다. 읽는 요령은 한 배치의 장점이 다른 배치의 단점이라는 점입니다.

• Cloud: 서버에는 큰 GPU가 있어 큰 모델도 돌릴 수 있고 관리하기 쉽습니다. 대신 네트워크에 의존하고, 왕복 지연이 있고, 데이터가 밖으로 나갑니다.
• Edge gateway: 공장 한쪽에 서버 한 대를 두고 카메라 여러 대의 영상을 모아 처리하는 방식입니다. 현장에서 처리하니 빠르지만, 그 서버가 고장 나면 전체가 멈추고 설치 비용이 듭니다.
• On-device: 가장 빠르고 인터넷 없이 동작하며 데이터가 밖으로 안 나갑니다. 대신 작은 보드라서 큰 모델은 어렵고, 오래 돌리면 뜨거워집니다.
• Hybrid: 둘을 섞습니다. 스마트폰 사진 앱이 얼굴 인식은 폰 안에서 하고, 사진 백업과 모델 업데이트는 클라우드에서 하는 것이 예입니다. 장점을 합치는 대신 둘 사이를 맞추는 일이 복잡해집니다.

고를 때는 "즉시 반응해야 하나? 인터넷이 항상 되나? 데이터를 밖으로 보내도 되나? 모델이 얼마나 큰가?"를 차례로 물어보면 됩니다.

사용자가 느끼는 응답 시간은 "카메라가 찍은 순간부터 잠금장치가 움직이기 시작할 때까지"입니다. 도어락 예시로 다섯 칸을 채워 보면 이렇습니다.

1. \(T_{capture}\) = 8 ms: 카메라가 사진 한 장을 프로그램에 넘겨줄 때까지
2. \(T_{pre}\) = 12 ms: resize·normalization
3. \(T_{infer}\) = 35 ms: 모델 계산 (파이썬에서 model(x) 부분)
4. \(T_{post}\) = 5 ms: threshold 비교, 결과 정리
5. \(T_{act}\) = 10 ms: 모터가 실제로 움직이기 시작할 때까지

합치면 70 ms입니다. deadline이 100 ms라면 통과입니다.

보통 실습에서는 model(x) 앞뒤로만 시간을 재서 35 ms라고 생각하기 쉽습니다. 하지만 사용자가 느끼는 시간은 그 두 배인 70 ms입니다. 그리고 모델을 두 배 빠르게 만들어도(35 → 17.5 ms) 전체는 70 → 52.5 ms로 약 25%만 줄어듭니다. 그래서 교안이 "추론 시간만 측정하면 충분하지 않다"고 말하는 것입니다.

프로그램이 돌아가는 동안 메모리(RAM)에는 네 가지가 동시에 올라가 있습니다.

• Weights: 모델이 학습해서 저장한 숫자들입니다. 저장해 둔 .pt 모델 파일 크기와 거의 같습니다.
• Activations: 계산하는 도중에 각 층이 만들어 내는 중간 결과(feature map)입니다. 예를 들어 첫 conv 층 출력이 112×112×64개 숫자이고 숫자 하나가 4 byte(FP32)라면 약 3.2 MB입니다. 입력 이미지가 클수록 커집니다.
• Runtime: 파이썬, PyTorch 같은 라이브러리, 운영체제 자체가 차지하는 메모리입니다. 의외로 이게 수백 MB로 가장 큰 경우가 많습니다.
• Buffers: 카메라 사진을 담아 둘 칸, 입력·출력을 잠시 두는 공간입니다.

Peak memory는 이 넷을 더한 값 중 가장 많이 쓸 때의 양이고, 이게 실제로 쓸 수 있는 메모리보다 작아야 합니다. "실제로 쓸 수 있는"이 중요합니다. 4 GB 보드라도 운영체제와 다른 프로그램이 1 GB를 쓰고 있으면 나머지 3 GB 안에서 해결해야 합니다.

모델 파일이 40 MB라서 "4 GB 보드면 넉넉하네"라고 생각하기 쉽지만, 앞의 계산 예시처럼 runtime과 activation을 더하면 840 MB가 필요할 수 있습니다.

먼저 단위를 구분해야 합니다. 에너지(J)는 일의 총량이고, 전력(W)은 1초 동안 쓰는 에너지입니다(W = J/s). 휴대폰으로 치면 배터리 용량이 에너지, 지금 배터리가 닳는 속도가 전력입니다.

\(E_{decision}\)은 판단 한 번에 드는 에너지를 부품별로 더한 것입니다. 센서를 켜는 데(sensor), 계산하는 데(compute), 메모리를 읽고 쓰는 데(memory, 7절에서 보듯 이게 비쌉니다), 무선으로 결과를 보내는 데(communication), 모터를 움직이는 데(act) 에너지가 듭니다.

평균 전력은 "판단 한 번 에너지 × 1초에 판단하는 횟수 + 가만히 있어도 드는 전력"입니다. 한 번에 0.2 J, 1초에 10번 판단하면 2 W이고, 대기 전력 1.5 W를 더하면 3.5 W입니다.

이게 왜 중요하냐면, 배터리 기기라면 배터리가 얼마나 가는지가 정해지고, 팬이 없는 보드라면 열이 쌓여 성능이 떨어지기(throttling) 때문입니다. 줄이는 방법도 식에서 바로 보입니다. 판단을 1초에 30번 대신 10번만 하거나(r을 줄임), 한 번 판단의 에너지를 줄이면 됩니다.

같은 AI를 장치에 올릴 때 정해야 하는 것을 네 층으로 나눈 그림입니다. 위에서부터 차례로 보겠습니다.

• Compute (무엇을 계산하나): 어떤 모델 구조를 쓸지입니다. CNN, Transformer 같은 것이죠. 여기서 MAC은 multiply-accumulate, 즉 "가중치 × 입력을 곱해서 누적해 더하기"입니다. 신경망 계산은 거의 다 이 MAC이고, conv 층 하나에 수백만 번 들어갑니다. 모델이 클수록 MAC이 많습니다.
• Mapping (어떻게 나눠서 계산하나): 같은 계산을 어떤 순서와 단위로 나눌지입니다. 큰 행렬이 빠른 메모리에 한 번에 안 들어가면 작은 조각으로 잘라 조각씩 계산합니다(tiling). conv 다음 ReLU를 따로 하지 않고 한 번에 처리하면 중간 결과를 메모리에 썼다가 다시 읽는 일이 사라집니다(fusion).
• Format (숫자를 몇 bit로 쓰나): FP32는 숫자 하나에 4 byte, INT8은 1 byte입니다. INT8로 바꾸면 메모리가 1/4로 줄고 계산도 빨라지지만, 숫자가 거칠어져 정확도가 조금 떨어질 수 있습니다. sparsity는 0인 가중치를 활용하는 것입니다. 0은 곱해도 0이니 건너뛸 수 있습니다.
• Binding (어느 연산기에서 돌리나): conv는 GPU, 후처리는 CPU처럼 일을 연산기에 배정하는 것입니다.

네 층을 함께 정해야 하는 이유는 서로 영향을 주기 때문입니다. 예를 들어 INT8로 바꿨는데(Format) 그 보드의 가속기가 INT8을 지원하지 않으면(Binding) 빨라지지 않습니다.

6.1 최적화 식은 이 선택들을 점수로 비교하는 방법입니다. λ는 "오차·지연·에너지 중 무엇을 더 중요하게 볼지" 정하는 가중치입니다. 다만 메모리와 deadline은 점수로 타협할 수 있는 게 아니라 무조건 지켜야 하는 조건이라서, 먼저 이 조건으로 후보를 거르고 남은 후보끼리 점수를 비교합니다.

Figure 1-4는 "숫자 하나를 가져오는 데 에너지가 얼마나 드나"를 보여 줍니다. ALU에서 계산 한 번 하는 에너지를 1로 두면, 바로 옆 register에서 값을 읽는 건 약 1, 이웃 연산 유닛에서 받아오는 건 2, 칩 안의 큰 버퍼에서는 6, 칩 밖 DRAM에서는 200입니다.

즉 DRAM에서 숫자 하나를 가져오는 데 계산 200번어치 에너지가 듭니다. 그래서 AI를 효율적으로 돌리려면 계산을 줄이는 것만큼, 또는 그보다 더, DRAM을 오가는 횟수를 줄이는 것이 중요합니다.

Arithmetic intensity는 "가져온 데이터 1 byte로 계산을 몇 번 하나"입니다. 값이 클수록 한 번 가져온 데이터를 여러 번 재사용한다는 뜻입니다. 예를 들어 가중치 조각을 빠른 메모리에 한 번 올려놓고 여러 입력에 반복해서 쓰면(tiling) 같은 계산을 하면서도 DRAM 왕복이 줄어 intensity가 높아집니다. INT8처럼 숫자를 작게 쓰는 것도 옮기는 byte 자체를 줄이는 방법입니다.

• Latency: 사진 한 장이 들어와서 결과가 나올 때까지 걸린 시간입니다. "한 장에 몇 ms?"
• Throughput(FPS): 1초 동안 처리를 끝낸 사진 수입니다. "1초에 몇 장?"
• Jitter: 매번 걸리는 시간이 얼마나 들쭉날쭉한지입니다. 평균은 같아도 들쭉날쭉하면 영상이 뚝뚝 끊겨 보이고 제어가 불안정해집니다.

두 지표가 따로 필요한 이유는 파이프라인 때문입니다. 빨래로 생각해 보세요. 세탁 30분, 건조 60분이라면, 한 바구니만 놓고 보면 90분 걸립니다(latency). 그런데 첫 바구니가 건조기로 넘어가는 순간 세탁기는 쉬지 않고 다음 바구니를 돌릴 수 있습니다. 그러면 한 바구니 걸리는 시간은 그대로 90분인데, 시간당 끝나는 바구니 수는 늘어납니다(throughput). 이때 결과는 가장 느린 기계(건조기)의 속도, 즉 60분마다 하나씩 나옵니다.

교안 예시도 똑같습니다. 전처리 10 → 추론 20 → 후처리 10 ms라면, 순차 처리는 한 장에 40 ms이고 40 ms마다 결과가 나오니 25 FPS입니다. 파이프라인으로 겹쳐 돌리면 한 장에 걸리는 시간은 여전히 40 ms인데, 가장 느린 추론 단계(20 ms)마다 결과가 나오니 50 FPS가 됩니다.

그래서 "FPS가 높다 = 반응이 빠르다"가 아닙니다. FPS는 두 배가 됐지만 버튼을 누르고 결과를 보기까지의 시간은 그대로입니다. 또 카메라가 1초에 30장을 보내도 시스템이 15장만 처리하면 나머지 15장은 버려지므로, 카메라 FPS와 처리 FPS도 구분해야 합니다.

백분위수는 측정값을 짧은 순서대로 줄 세웠을 때 몇 % 지점의 값인지입니다. 1,000번 쟀다면 p50은 500번째, p95는 950번째, p99는 990번째 값입니다.

교안 예시로 따라가 보겠습니다. 1,000장 중 990장이 20 ms, 10장이 200 ms 걸렸고, 제한은 100 ms입니다.

• 평균: (990×20 + 10×200) ÷ 1000 = 21.8 ms → 아주 빨라 보입니다.
• p95: 950번째 값 = 20 ms, p99: 990번째 값 = 20 ms → 이것도 좋아 보입니다.
• 하지만 991~1000번째 10장은 200 ms로 제한(100 ms)을 넘습니다. 마감 초과율 = 10 ÷ 1000 = 1%입니다.

즉 평균과 p95가 좋아도 100번에 1번은 늦습니다. 동영상 플레이어라면 넘어갈 수 있지만, 자율주행 브레이크라면 100번에 1번 늦는 것은 허용할 수 없습니다. 그래서 교안은 평균·p95와 함께 마감 초과율을 꼭 보고, 매번 지켜야 하는 안전 제어는 가장 나쁜 경우를 따로 검증하라고 합니다.

함께 볼 두 가지도 같은 이유입니다. Dropped frame: 느린 프레임을 그냥 버리는 시스템은 남은 프레임만 재면 빨라 보이므로, 버린 수도 같이 기록해야 합니다. Thermal throttling: 처음 1분은 빠르다가 10분 뒤 보드가 뜨거워져 느려질 수 있으므로, 오래 켜 둔 상태에서도 재야 합니다.

시스템이 "잘 된다"는 것을 확인하려면 정확도 하나로는 부족하고 다섯 가지를 모두 봐야 한다는 표입니다.

• 모델 품질: Accuracy는 전체 중 맞힌 비율입니다. F1은 "맞다고 한 것 중 진짜 맞은 비율(정밀도)"과 "진짜 맞는 것 중 찾아낸 비율(재현율)"을 함께 보는 점수, mAP는 객체 탐지에서 쓰는 평균 정밀도입니다. False Negative는 "있는데 없다고 한 것"입니다. 출입문이나 안전 시스템에서는 사람을 놓치는 게 가장 위험하므로, 전체 정확도보다 이 값을 따로 봐야 합니다.
• 응답성: 앞에서 배운 p50/p95 지연, FPS, jitter입니다.
• 자원: 메모리를 최대 얼마나 쓰는지, CPU/GPU가 실제로 몇 % 일하는지(utilization)입니다. GPU 사용률이 낮다면 GPU가 데이터를 기다리며 놀고 있다는 뜻일 수 있습니다.
• 에너지·열: 평균 전력, 추론 한 번당 에너지, 온도입니다.
• 운영: 인터넷을 끊어 보고, 카메라를 뽑아 보고, 프로그램을 강제로 죽여 본 뒤 안전하게 복구되는지 확인합니다.

이 예제의 핵심은 설계가 "어떤 모델을 쓸까?"가 아니라 요구사항 한 줄 한 줄에서 결정이 나온다는 것입니다.

• "인터넷이 끊겨도 잠금이 동작해야 한다" → 판단을 Cloud에 두면 안 되므로 On-device.
• "얼굴 원본을 외부로 보내면 안 된다" → 역시 On-device. 다만 "몇 명이 출입했나" 같은 익명 통계와 모델 업데이트는 Cloud에서 해도 되므로 결국 Hybrid.
• "p95 end-to-end 100 ms 이하" → 모델만이 아니라 카메라·후처리·모터까지 포함해 단계별로 재야 함.
• "False Negative 우선" → 조명·거리·가림 조건을 바꿔 가며 사람을 놓치는 경우를 집중 테스트.

아래의 팀 프로젝트 질문 9개도 같은 구조입니다. 입력은 무엇이고, 무엇을 판단하고, 무엇을 출력하는지, 어디서 돌리고, 얼마나 빨라야 하고, 메모리와 전력은 얼마나 쓸 수 있고, 고장 나면 어떻게 안전하게 멈출지를 먼저 숫자와 함께 정한 다음에 모델을 고릅니다.

1학년 때 배운 "CPU = 제어장치 + ALU + 레지스터" 그림은 처리기 하나의 구조입니다. Raspberry Pi나 Jetson 같은 SoC에는 그런 처리기가 여러 종류, 따로따로 들어 있습니다. 교안의 "연산기"는 CPU, GPU, NPU 각각을 가리킵니다.

• CPU: 크고 똑똑한 core가 몇 개(Raspberry Pi 5는 4개) 있고, core마다 자기 ALU·레지스터·cache가 있습니다.
• GPU: 단순한 계산 유닛이 아주 많습니다. Jetson Nano GPU에는 CUDA core가 128개 있어서, 작은 ALU 128개가 같은 계산을 동시에 하는 셈입니다.
• NPU: 곱하고 더하는(MAC) 전용 계산기를 격자 모양으로 많이 깔아 둔, 신경망 전용 장치입니다.

즉 다 같이 ALU 하나를 쓰는 게 아니라, CPU의 ALU·GPU의 ALU·NPU의 MAC은 물리적으로 다른 회로이고 동시에 각자 다른 일을 할 수 있습니다.

그런데 메모리(DRAM)는 같이 씁니다. 큰 메모리인 DRAM은 칩 밖에 하나 있고, 모든 연산기가 칩 안의 공용 통로(interconnect)를 통해 함께 씁니다. 대신 각 연산기는 자기 ALU 바로 옆에 작고 빠른 개인 저장소(cache나 buffer)를 따로 갖고 있습니다.

그래서 "입력 데이터와 모델 가중치는 대개 DRAM에 저장되고, 각 연산기의 가까운 cache·buffer로 이동"이라는 문장은 이런 뜻입니다. 카메라 사진과 모델 weight 같은 큰 데이터는 일단 모두가 쓰는 공용 창고(DRAM)에 있고, 실제로 계산할 때는 그중 지금 필요한 조각만 그 연산기 옆 개인 저장소로 가져와 ALU가 계산합니다. ALU가 DRAM에서 직접 꺼내 쓰면 너무 느리기 때문입니다. Jetson Nano에서 사진 한 장을 탐지하는 과정을 따라가 보면 이렇습니다.

1. 프로그램을 켜면 모델 weight가 SD카드에서 DRAM으로 올라옵니다.
2. 카메라 사진이 DMA를 통해 DRAM에 들어옵니다.
3. GPU가 첫 번째 conv를 계산하려고 필요한 weight와 사진 조각을 GPU 옆 cache·buffer로 가져와 128개 core로 계산하고, 결과를 다시 DRAM에 씁니다. 이걸 층마다 반복합니다.
4. 탐지 결과가 나오면 CPU가 그 결과를 자기 cache로 가져와 NMS·threshold 판단을 하고 경고를 출력합니다.

같은 데이터가 DRAM ↔ GPU 쪽 ↔ CPU 쪽을 계속 오가고, 카메라·저장장치·네트워크 데이터도 같은 통로와 DRAM을 씁니다. 그래서 GPU가 아무리 빨라도 이 공용 통로가 붐비면 기다려야 하고, 이것이 "공유 자원이 포화되면 전체 성능이 제한된다"는 말입니다.

이 표는 "프로그램이 안 되거나 느릴 때 어디부터 의심할지" 정리한 지도입니다. 아래로 갈수록 하드웨어에 가깝습니다. 실제로 겪는 상황과 연결하면 이렇습니다.

• 내 코드의 순서나 예외 처리가 잘못됨 → 응용 층
• "이 연산은 지원하지 않습니다(operator not supported)" 에러, FP16으로 바꿨더니 결과가 이상함 → Framework·runtime 층 (PyTorch, OpenCV, TensorRT 같은 라이브러리)
• 카메라를 꽂았는데 장치가 안 잡힘, 버전이 안 맞아 설치가 안 됨 → OS·driver 층 (driver는 운영체제가 장치를 쓸 수 있게 해 주는 프로그램)
• CPU가 장치를 제어하는 가장 낮은 단계. ISA는 CPU가 알아듣는 명령어 목록(Raspberry Pi와 Jetson은 Arm)이고, register는 장치를 조작하는 스위치 칸입니다 → ISA·register 층
• 모든 게 맞는데 느림, 뜨거워짐, 선이 빠짐 → 하드웨어 층

세 연산기는 잘하는 일의 종류가 다릅니다.

• CPU: core는 몇 개뿐이지만 하나하나가 똑똑합니다. if 분기가 많고 순서대로 해야 하는 일, 파일·네트워크·장치를 다루는 일, 결과를 보고 규칙대로 판단하는 일에 강합니다. 대신 수백만 개의 숫자에 같은 곱셈을 하는 일은 core 수가 적어서 느립니다.
• GPU: 단순한 core가 아주 많습니다. 이미지 픽셀 수십만 개에 같은 연산을 하거나, 큰 행렬을 곱하는 것처럼 "같은 일을 많이" 하는 데 강합니다. 대신 GPU에 일을 시키려면 데이터를 GPU 쪽으로 보내고 실행 준비(kernel launch)를 해야 해서, 아주 작은 일은 CPU가 혼자 하는 게 오히려 빠를 수 있습니다.
• NPU: 신경망 계산만을 위해 만든 장치라 같은 전력으로 훨씬 많은 계산을 합니다. 대신 모델을 NPU용으로 변환(compile)해야 하고, NPU가 지원하지 않는 연산이나 숫자 형식이 있으면 그 부분은 CPU로 넘어가 오히려 느려질 수 있습니다.

예를 들어 객체 탐지에서 conv 계산은 GPU에, 겹친 박스를 정리하는 NMS는 분기가 많은 작은 작업이라 CPU에 맡깁니다. 그리고 Jetson Nano에는 NPU가 없습니다. CPU와 GPU만 있으니 "NPU 보드"라고 쓰면 틀립니다.

Amdahl의 법칙을 시간으로 계산해 보면 바로 이해됩니다. 원래 10초 걸리는 프로그램이 있다고 합시다.

• 그중 8초(80%)가 GPU로 빠르게 할 수 있는 부분이고, 이걸 10배 빠르게 하면 8초 → 0.8초가 됩니다.
• 나머지 2초(전처리·후처리·I/O)는 가속이 안 되니 그대로 2초입니다.
• 전체는 0.8 + 2 = 2.8초. 10 ÷ 2.8 ≈ 3.57배 빨라졌습니다. 10배가 아닙니다.
• GPU를 무한히 빠르게 만들어도 8초 → 0초, 나머지 2초는 그대로라서 10 ÷ 2 = 5배가 한계입니다. 이게 상한 1/(1−p)입니다.

50%를 20배 가속하는 경우도 같습니다. 10초 중 5초가 0.25초가 되고 나머지 5초는 그대로라 5.25초, 10 ÷ 5.25 ≈ 1.90배입니다.

교훈은 "빨라지지 않는 부분이 전체를 붙잡는다"입니다. 그래서 가속기를 사기 전에 전체 시간 중 가속기로 넘길 수 있는 비율(p)부터 재 봐야 하고, 때로는 전처리·후처리를 줄이는 게 더 효과적입니다.

"빠른 메모리를 크게 만들면 되지 않나?" 싶지만, 빠른 메모리는 비싸고 칩 안 공간을 많이 차지해서 크게 만들 수 없습니다. 그래서 작고 빠른 것부터 크고 느린 것까지 층을 나눠 둡니다.

• Register: ALU 바로 옆, 값 몇 개를 담는 칸. 가장 빠름.
• Cache: 칩 안에 있는 작은 메모리. 최근에 쓴 데이터와 그 주변을 담아 둠.
• DRAM: 보드의 RAM(예: 4 GB). 모델·중간 결과·사진이 여기에 있음. cache보다 훨씬 느리고 오가는 데 에너지가 많이 듦.
• Storage (SD카드·NVMe): 전원을 꺼도 남는 저장장치. 너무 느려서 계산 중에는 쓰지 않고, 프로그램 시작 때 모델 파일을 DRAM으로 읽어 올리는 데만 씀.

계산은 항상 위층에서 일어나고, 아래층의 데이터는 필요할 때 위로 끌어올려집니다. 필요한 데이터가 위층에 이미 있으면 빠르고, 없으면 아래층까지 다녀와야 해서 느립니다.

Cache hit은 찾는 데이터가 cache에 이미 있는 경우, cache miss는 없어서 DRAM에서 가져와야 하는 경우입니다. 평균 접근 시간(AMAT)은 "일단 cache를 보는 시간 + 없을 확률 × DRAM 다녀오는 추가 시간"입니다. cache 확인에 1 ns, DRAM 왕복에 100 ns가 더 걸리고 10번 중 1번 없다면 1 + 0.1 × 100 = 11 ns입니다.

miss를 줄이는 열쇠가 locality입니다. cache는 데이터를 하나만 가져오지 않고 주변까지 한 덩어리로 가져옵니다. 그래서 배열을 a[0], a[1], a[2]… 순서대로 읽으면 다음 값이 이미 같이 올라와 있어 hit이 많습니다. 반대로 큰 2차원 배열을 열 방향으로 띄엄띄엄 읽으면 매번 다른 덩어리를 가져와야 해서 miss가 많습니다. 데이터 배치(data layout), 연속 접근, tiling이 모두 이 locality를 높이는 방법입니다.

Bandwidth는 1초에 옮길 수 있는 데이터 양, 즉 도로의 폭입니다. 60 MB를 옮겨야 하는데 도로가 1초에 10 GB를 옮길 수 있다면 최소 6 ms가 걸립니다. 이게 \(T_{memory}\ge D_{moved}/B_{effective}\)의 뜻입니다.

계산과 데이터 옮기기를 동시에 할 수 있다면, 그 단계의 시간은 둘 중 더 긴 쪽입니다. 계산 4 ms, 옮기기 6 ms라면 6 ms입니다. 이렇게 옮기는 쪽이 더 긴 상태를 memory-bound라고 합니다. 이때 모델을 줄여 계산을 2 ms로 만들어도 여전히 6 ms입니다. "FLOPs를 줄였는데 왜 안 빨라지지?"의 답이 이것입니다.

Effective(유효)라는 말이 붙은 이유는, 카메라·저장장치·다른 프로그램도 같은 도로를 쓰기 때문에 실제로 쓸 수 있는 폭은 사양표 숫자보다 작기 때문입니다.

Working set은 "지금 반복해서 계속 쓰는 데이터 묶음"입니다. 이게 cache에 다 들어가면 한 번 올려놓고 계속 재사용할 수 있지만, cache보다 크면 쓸 때마다 DRAM에 다녀와야 해서 느려집니다.

CPU가 카메라·LED·센서 같은 주변장치와 대화하는 세 가지 방법입니다.

• Memory-mapped I/O: 장치 안에는 "켜기/끄기", "상태" 같은 제어용 칸(register)이 있는데, 이 칸들을 특정 메모리 주소에 연결해 둡니다. 그러면 CPU는 메모리에 값을 쓰는 것과 똑같은 명령(store)으로 그 주소에 1을 써서 LED를 켜고, 읽는 명령(load)으로 버튼 상태를 확인합니다. 파이썬 GPIO 라이브러리도 결국 내부에서 이 일을 합니다.
• Polling과 Interrupt: 택배를 기다리는 상황과 같습니다. 1분마다 현관문을 열어 확인하는 게 polling이고, 택배 기사가 초인종을 누르면 그때 나가는 게 interrupt입니다. polling은 CPU 시간을 낭비하고 확인하는 사이에 온 짧은 신호를 놓칠 수 있습니다. interrupt는 신호가 오면 미리 정해 둔 처리 함수(handler)가 실행됩니다.
• DMA: 사진처럼 큰 데이터를 CPU가 한 byte씩 옮기면 CPU가 다른 일을 못 합니다. DMA는 CPU 대신 데이터를 옮겨 주는 전용 장치입니다. CPU는 "카메라 데이터를 메모리 이 위치로 옮겨"라고 지시만 하고 다른 일을 합니다.

그림을 왼쪽부터 따라가면 됩니다.

1. CPU가 DMA에게 "카메라 frame을 DRAM의 이 buffer로 옮겨라"라고 설정합니다(점선 ①). CPU가 직접 옮기지는 않습니다.
2. DMA controller가 카메라 데이터를 DRAM buffer로 옮깁니다. 그동안 CPU는 다른 일을 합니다(②).
3. GPU/NPU가 그 buffer를 읽어 추론합니다.
4. 끝나면 CPU가 "완료" 신호를 받고 결과를 처리합니다(③).

여기서 주의할 점은 복사입니다. 같은 사진을 "CPU용 복사본", "GPU용 복사본"으로 여러 번 복사하면 그만큼 시간·bandwidth·메모리가 낭비됩니다. zero-copy는 복사하지 않고 같은 메모리를 CPU와 GPU가 같이 보는 방식입니다. Jetson처럼 CPU와 GPU가 같은 DRAM을 쓰면 가능합니다.

다만 조건이 있습니다. CPU cache에 옛날 값이 남아 있으면 GPU가 바꾼 새 값과 달라질 수 있으니 서로 같은 값을 보도록 맞춰야 하고(cache coherency), DMA가 다 옮기기 전에 GPU가 읽으면 안 되니 순서를 맞춰야 합니다(synchronization). 또 GPU가 원하는 픽셀 순서나 메모리 정렬과 달라도 안 됩니다.

두 보드는 "어느 게 더 좋다"가 아니라 잘하는 일이 다르다고 보면 됩니다.

• Jetson Nano: CUDA를 쓸 수 있는 GPU(128 core)가 있어서 카메라 영상을 CNN으로 분석하는 일에 강합니다. NVIDIA의 TensorRT로 모델을 GPU에 맞게 최적화할 수 있습니다. 대신 CPU와 GPU가 4 GB 메모리 하나를 나눠 쓰기 때문에(GPU 전용 메모리가 따로 없음) 큰 모델은 금방 메모리가 찹니다. 5~10 W를 쓰며 열이 나고, 지원 software가 JetPack 4.6 계열에서 멈춰 있어서 최신 라이브러리가 안 깔릴 수 있습니다. 그래서 Python·CUDA·TensorRT 버전을 처음부터 맞춰서 고정해야 합니다.
• Raspberry Pi 5: 별도의 AI 가속기는 기본으로 없고, RP1이라는 칩이 USB·네트워크·GPIO 같은 외부 연결을 맡습니다. 그래서 여러 센서와 GPIO를 연결하고 네트워크로 주고받는 일에 강하고, AI는 가벼운 모델을 CPU로 돌리거나 AI 가속기를 따로 붙여서 씁니다.

프로젝트가 "카메라 영상 AI가 중심"이면 Jetson, "센서 여러 개 연결과 제어가 중심"이면 Raspberry Pi 쪽이 자연스럽습니다. 교안이 "작업 배치도·data path·지원 runtime·측정 지표로 설명하라"고 하는 것도 이 이유를 근거로 대라는 뜻입니다.

위 표는 객체 탐지 과정의 각 단계를 "그 일을 가장 잘하는 장치"에 맡긴 것입니다. 사진 받기는 데이터를 옮기는 일이라 DMA, conv 계산은 같은 계산을 많이 하는 일이라 GPU, 박스 정리와 규칙 판단은 분기가 많은 작은 일이라 CPU, 모터·경보는 장치를 다루는 일이라 CPU와 I/O controller입니다.

아래 병목 확인 순서는 "느릴 때 범인 찾는 법"입니다. 전체 시간만 재면 어디가 느린지 모르니 ① 단계별로 따로 재고, ② CPU·GPU가 실제로 바쁜지 놀고 있는지 보고, ③ 쓸데없는 복사가 있는지, ④ 줄 서서 기다리는 시간이나 버려지는 프레임이 있는지 확인하고, ⑤ 마지막으로 오래 돌려서 열 때문에 느려지지 않는지 봅니다.

센서 값은 현실을 그대로 가져온 게 아니라 여러 단계를 거쳐 "옮겨 적은" 값입니다. 온도 센서 하나로 따라가 보겠습니다.

1. 물리량: 방 온도가 25 ℃입니다.
2. Transduction: 센서 안의 소자가 온도에 따라 저항이 바뀌고, 이것이 0.75 V 같은 전압으로 나옵니다. 물리량이 전기 신호로 바뀌는 단계입니다.
3. Signal conditioning: 신호가 너무 약하면 키우고(증폭), 잡음을 걸러 ADC에 넣기 좋게 다듬습니다.
4. ADC·Sampling: 정해진 간격마다 전압을 재서 숫자로 바꿉니다. 12-bit ADC라면 0.75 V가 약 931이라는 정수가 됩니다.
5. 값 + metadata: 931이라는 숫자에 "언제 쟀는지(timestamp)", "몇 번째 측정인지" 같은 정보를 붙입니다.
6. Calibration·filter: 보정식으로 931을 25.2 ℃로 바꾸고, 튀는 값을 걸러낸 뒤 AI에 넣습니다.

단계마다 오차가 섞일 수 있습니다(그림의 빨간 점선). 그래서 AI가 "온도가 갑자기 변했다"고 판단해도, 그게 진짜 온도 변화인지 센서 잡음인지 구분하려면 값과 함께 언제·어떤 설정으로 쟀는지를 기록해 둬야 합니다.

식 \(y_t=s\,x_t+b+n_t\)는 "센서가 보여 주는 값은 실제 값에 배율을 곱하고, 일정량을 더하고, 잡음이 섞인 것"이라는 뜻입니다. 체중계로 생각해 보세요.

• \(s\) (sensitivity): 실제 무게의 1.02배로 보여 준다면 s = 1.02
• \(b\) (offset): 아무것도 안 올렸는데 0.5 kg이 나온다면 b = 0.5
• \(n_t\) (noise): 같은 사람이 올라가도 매번 조금씩 다르게 나오는 흔들림

Calibration은 s와 b를 알아내는 과정입니다. 무게를 정확히 아는 물건으로 재 보면 됩니다. 아무것도 안 올렸을 때 0.5, 정확히 50 kg인 추를 올렸을 때 51.5가 나왔다면 s = (51.5 − 0.5) ÷ 50 = 1.02, b = 0.5입니다. 그다음부터는 측정값에서 거꾸로 계산해(\(\hat{x}_t=(y_t-\hat{b})/\hat{s}\)) 실제 무게를 구합니다.

하지만 두 가지는 보정으로 해결되지 않습니다. 매번 다른 잡음(n)은 남고, 체중계 한도가 150 kg인데 200 kg이 올라가면 150에서 멈춰 버려서(saturation) 거꾸로 계산해도 진짜 값을 알 수 없습니다.

과녁에 화살을 쏘는 그림으로 생각하면 쉽습니다. Accuracy는 화살이 과녁 중앙(참값)에 얼마나 가까운지, Precision은 화살끼리 얼마나 모여 있는지입니다. 화살이 한쪽 구석에 촘촘히 모여 박혔다면 precision은 높지만 accuracy는 낮고, 그 한쪽으로 치우친 정도가 bias입니다.

• Range: 체온계라면 35~42 ℃처럼 잴 수 있는 범위
• Resolution: 0.1 ℃ 단위로 보여 주는지, 1 ℃ 단위인지. 구분할 수 있는 가장 작은 차이
• Noise: 가만히 있어도 25.1, 24.9, 25.2처럼 매번 불규칙하게 흔들리는 것
• Drift: 몇 달 쓰다 보니, 또는 기기가 뜨거워지니 기준이 조금씩 밀리는 것. 그래서 주기적으로 다시 보정해야 함
• Saturation: 범위를 넘으면 최댓값에 붙어 버리는 것. 42 ℃ 한도 체온계에 50 ℃ 물을 재면 42로 나옴. 이 42를 정상 값으로 믿으면 안 됨

ADC는 연속적으로 변하는 전압을 계단처럼 칸을 나눠 번호를 붙이는 장치입니다. N-bit ADC는 \(2^N\)칸으로 나눕니다. 12-bit라면 4096칸이고, 0~3.3 V를 4096칸으로 나누면 한 칸이 3.3 ÷ 4096 ≈ 0.81 mV입니다. 1.2 V가 들어오면 1.2 ÷ 0.000806 ≈ 1489번째 칸, 그래서 숫자 1489가 나옵니다.

bit 수를 늘리면 칸이 촘촘해져 더 작은 변화를 구분할 수 있습니다. 하지만 센서 자체가 흔들리면(noise) 칸을 아무리 촘촘히 나눠도 그 흔들림까지 정밀하게 기록할 뿐이고, 데이터 양과 전력만 늘어납니다.

범위를 넘는 전압(3.5 V)이 들어오면 맨 끝 칸 4095에 붙어 버립니다. 그래서 센서 출력 전압이 ADC가 받을 수 있는 범위 안에 들어오는지 먼저 확인해야 합니다.

그리고 Raspberry Pi의 일반 GPIO 핀은 0 아니면 1만 읽는 digital 핀입니다. 전압을 숫자로 바꾸는 ADC가 없으니 analog 센서를 그냥 꽂으면 못 읽습니다. 외부 ADC 칩을 붙이거나 ADC가 내장된 센서를 써야 합니다.

Sampling은 연속적인 신호를 일정 간격으로 "찍는" 것입니다. \(f_s\)는 1초에 몇 번 찍는지, \(T_s\)는 찍는 간격입니다. 50 Hz로 찍으면 0.02초(20 ms)마다 한 번입니다.

Aliasing은 너무 띄엄띄엄 찍어서 빠른 신호가 느린 신호처럼 보이는 현상입니다. 동영상에서 자동차 바퀴나 선풍기 날개가 천천히 돌거나 거꾸로 도는 것처럼 보이는 게 바로 이것입니다. 그림의 아래쪽을 보면, 1초에 9번 진동하는 신호를 1초에 10번만 찍으니 찍을 때마다 거의 한 바퀴 돌고 난 위치가 찍혀서, 점들을 이으면 1초에 1번 진동하는 느린 파형(점선)이 됩니다.

Nyquist 조건 \(f_s>2f_{max}\)는 "가장 빠른 변화의 한 주기 안에 최소 두 번 넘게 찍어야 모양을 놓치지 않는다"는 뜻입니다. 9 Hz 신호라면 18 Hz보다 빠르게 찍어야 합니다.

중요한 점은 한번 aliasing이 생기면 찍은 뒤에는 되돌릴 수 없다는 것입니다. 점만 보면 진짜 1 Hz 신호인지 9 Hz 신호가 잘못 찍힌 건지 구분할 방법이 없습니다. 그래서 찍기 전에 너무 빠른 성분을 걸러내는 필터(anti-alias filter)를 두고, 필터가 완벽하지 않으니 2배보다 여유 있게 찍습니다. 반대로 너무 자주 찍으면 데이터·전력·CPU 부담이 커집니다.

데이터를 언제 어떻게 받아올지 고르는 표입니다.

• Periodic sampling: 일정 간격마다 잽니다. 온도, 가속도(IMU), 소리처럼 계속 변하는 값에 씁니다.
• Polling: CPU가 "바뀌었나?"를 계속 확인합니다. 간단하지만 CPU를 낭비하고, 확인하는 사이에 짧게 눌렸다 떼어진 버튼을 놓칠 수 있습니다.
• Interrupt: 버튼이 눌리거나 "데이터 준비됨" 신호가 오면 장치가 알려 줍니다. 단, 버튼은 눌리는 순간 접점이 떨려서 신호가 여러 번 들어올 수 있어 이를 걸러야 합니다(debounce).
• DMA stream: 카메라·오디오처럼 계속 쏟아지는 큰 데이터를 CPU 없이 메모리로 받습니다. 어느 buffer를 지금 누가 쓰는지 정해야 합니다.

바늘구멍 사진기 원리입니다. 3D 공간의 점에서 카메라 중심으로 직선을 그었을 때 그 선이 이미지 평면과 만나는 곳이 사진 속 픽셀 위치입니다(Figure 3-3).

식 \(u=f_x\,X/Z+c_x\)를 하나씩 보면 이렇습니다. \(X\)는 물체가 카메라 중심선에서 옆으로 떨어진 거리, \(Z\)는 카메라에서 물체까지의 거리입니다. \(X/Z\)는 "옆으로 떨어진 정도 ÷ 거리"이고, 여기에 확대 배율 \(f_x\)를 곱해 픽셀 단위로 바꾸고, 사진 중심 위치 \(c_x\)를 더합니다. 640×480 사진이라면 중심은 대략 (320, 240)입니다. 옆으로 0.5 m 떨어진 물체가 2 m 거리에 있으면 중심에서 150픽셀, 4 m로 멀어지면 75픽셀 떨어진 곳에 찍힙니다. 멀리 있는 물체가 작게 찍히는 이유입니다.

아래 행렬 식은 같은 내용을 두 부분으로 나눈 것입니다. \(K\) (intrinsic)는 카메라 자체의 성질입니다. 렌즈가 얼마나 확대하는지(f), 사진 중심이 어디인지(c)입니다. 카메라를 어디에 두든 변하지 않습니다. \(R,t\) (extrinsic)는 카메라를 어디에, 어느 방향으로 놓았는지입니다. 카메라를 옮기면 바뀝니다.

Calibration은 이 값들을 알아내는 과정입니다. 칸 크기를 정확히 아는 체커보드를 여러 각도로 찍으면, "실제로는 이 위치인 모서리가 사진에서는 이 픽셀에 찍혔다"는 짝을 많이 얻을 수 있고, 여기서 K, R, t와 렌즈 왜곡을 계산합니다. AI가 "사진 속 사람이 실제로 몇 m 앞에 있나"를 알려면 이 값들이 필요합니다.

스마트폰으로 사진을 찍을 때 겪는 일들이 그대로 AI 입력 문제가 됩니다.

• Exposure time: 셔터를 오래 열수록 빛을 많이 받아 밝아지지만, 그동안 움직인 물체는 번져서(motion blur) 모양이 흐려집니다.
• Analogue gain: 센서 신호를 증폭해 밝게 만듭니다. 어두운 곳에서 감도를 올린 사진이 자글자글한 것처럼 잡음도 같이 커져, AI가 잡음을 물체로 착각할 수 있습니다.
• White balance: 형광등 아래 사진이 푸르스름하고 백열등 아래 사진이 누렇게 나오는 것을 보정하는 설정입니다. 색이 바뀌면 학습 때 본 색과 달라집니다.
• Focus: 초점이 안 맞으면 작은 물체의 윤곽이 뭉개집니다.
• Rolling vs Global shutter: rolling shutter는 위에서 아래로 한 줄씩 차례로 찍어서, 빨리 움직이는 프로펠러가 휘어져 보이는 식으로 모양이 왜곡됩니다. global shutter는 전체를 한 순간에 찍어서 이런 왜곡이 없습니다.

핵심은 이 설정들이 바뀌면 AI가 받는 사진의 분포가 바뀐다는 점입니다. 학습 데이터는 밝은 낮 사진인데 실제 카메라는 밤에 감도를 올려 잡음 많은 사진을 보내면, 모델이 처음 보는 종류의 입력이라 틀리기 쉽습니다. 카메라의 자동 설정이 장면마다 값을 바꾸기 때문에, 평가할 때는 설정값을 기록해 두거나 고정합니다.

영상 데이터 양은 "사진 한 장의 크기 × 1초에 몇 장"입니다. 사진 한 장은 가로 픽셀 × 세로 픽셀 × 픽셀 하나의 bit 수입니다. RGB8은 빨강·초록·파랑을 각각 8 bit로 쓰니 픽셀 하나에 24 bit입니다.

640 × 480 = 307,200 픽셀, × 24 bit = 한 장에 약 7.4 Mbit, × 30장 = 1초에 약 221 Mbit입니다. byte로 바꾸면(÷8) 1초에 약 27.6 MB입니다. 작은 해상도인데도 1초에 사진 수십 MB가 쏟아지니, 카메라 전용 고속 연결(CSI-2)이 필요하고 메모리 bandwidth도 많이 씁니다.

JPEG·H.264 압축을 하면 데이터 양은 크게 줄지만, 압축하고 푸는 데 시간이 들고 화질이 조금 손상됩니다.

아래 표의 libcamera, Picamera2, GStreamer 같은 이름은 각 보드에서 카메라를 다루는 라이브러리 이름입니다. Raspberry Pi에서는 파이썬으로 Picamera2를, Jetson에서는 GStreamer를 주로 씁니다.

연결 방식은 "얼마나 많은 데이터를, 얼마나 빨리, 몇 개의 장치와 주고받나"로 고릅니다.

• GPIO: 핀 하나로 켜짐(High)/꺼짐(Low)만 주고받습니다. 버튼 누름, LED 켜기.
• PWM: 핀을 아주 빠르게 켰다 껐다 하면서 켜진 시간의 비율로 세기를 조절합니다. LED 밝기, 서보 모터 각도.
• UART: 선 두 개(TX 보내기, RX 받기)로 글자를 한 줄씩 주고받습니다. GPS 모듈이 위치 정보를 문장으로 계속 보내는 게 예입니다. 박자를 맞추는 시계선이 없어서(비동기) 양쪽이 같은 속도(baud)로 약속해야 합니다.
• I²C: 선 두 개(SDA 데이터, SCL 시계)에 센서 여러 개를 줄줄이 연결하고, 각 센서를 주소로 부릅니다. 핀을 아끼기 좋지만 느린 편이고, 같은 주소를 가진 센서 두 개를 같이 달면 충돌합니다.
• SPI: 선이 4개 이상 필요하고 장치마다 선택선(CS)이 하나씩 더 필요하지만, 시계선으로 박자를 맞춰(동기식) I²C보다 빠릅니다.
• CSI-2: 카메라 전용 고속 연결입니다. 앞에서 계산한 초당 수백 Mbit 영상을 보내는 용도입니다.
• USB: 꽂기만 하면 되는 범용 연결입니다. 대신 다른 USB 장치들과 대역폭을 나눠 쓰고, 드라이버가 있어야 합니다.

한 장치가 두 가지를 같이 쓰기도 합니다. 카메라 모듈은 "노출을 얼마로" 같은 설정은 I²C로, 영상 자체는 CSI-2로 주고받습니다.

들어오는 속도가 처리 속도보다 빠르면 줄이 계속 길어집니다. 카메라가 1초에 30장을 보내는데 1초에 25장만 처리하면, 1초마다 5장씩 밀립니다. 10초 뒤에는 50장이 줄 서 있고, 지금 처리하는 사진은 2초 전 장면입니다. 그래서 \(r_{in}\lt r_{process}\)가 필요하고, 평균적으로는 맞아도 순간적으로 몰릴 수 있으니 줄(buffer)을 어떻게 관리할지 정책을 정해야 합니다.

• FIFO: 줄 선 순서대로 전부 처리합니다. 하나도 빠뜨리면 안 되는 기록용에 맞습니다. 하지만 제어용이면 위 예처럼 몇 초 전 장면을 보고 판단하게 됩니다.
• Latest-only: 밀린 사진은 버리고 가장 최신 사진만 처리합니다. 로봇처럼 "지금" 상황이 중요할 때 씁니다.
• Ring buffer: 정해진 칸 수만큼만 저장하고 꽉 차면 가장 오래된 것부터 덮어씁니다. 블랙박스가 사고 전후 몇 초만 남겨 두는 방식입니다.
• Double buffer: 칸 두 개를 번갈아 씁니다. 하나에 카메라가 사진을 채우는 동안 다른 하나의 사진을 처리합니다.

Timestamp는 "이 값이 언제 측정됐나"입니다. 프로그램이 읽은 시각이 아니라 센서가 실제로 잰 시각에 가까워야 합니다. 카메라는 33 ms마다, 가속도 센서는 10 ms마다 값을 내는데, 이 둘을 합쳐 판단하려면(sensor fusion) 같은 순간의 값끼리 짝지어야 합니다. 0.1초 차이 나는 값을 짝지으면 각각은 정확해도 합친 결과가 틀립니다.

센서 값이 들쭉날쭉할 때 부드럽게 다듬는 세 가지 방법입니다.

• EMA: 새 값과 지금까지의 평균을 섞습니다. α는 새 값을 얼마나 믿을지입니다. 평균이 10인데 새 값 20이 들어오면, α = 0.2일 때 0.2×20 + 0.8×10 = 12로 조금만 움직이고, α = 0.8일 때 18로 크게 움직입니다. α가 작으면 잡음에 둔감하지만 진짜 변화에도 늦게 반응합니다.
• Median filter: 최근 값 몇 개 중 가운데 값을 씁니다. 10, 10, 50, 10, 10이 들어오면 평균은 18로 튀지만 가운데 값은 10이라서 순간적으로 튄 50을 무시합니다. 대신 창(window)을 너무 크게 잡으면 진짜 변화도 늦게 반영됩니다.
• Hysteresis: 켜는 기준과 끄는 기준을 다르게 둡니다. 에어컨이 26도에서 켜지고 24도에서 꺼지는 것과 같습니다. 기준이 25도 하나라면 25.1, 24.9, 25.1… 사이를 오갈 때 계속 켜졌다 꺼졌다 합니다. 기준을 둘로 벌리면 한 번 켜진 뒤 24도 아래로 내려가야 꺼집니다. AI confidence에도 똑같이 써서 경고가 깜빡거리는 것을 막습니다.

PWM: digital 핀은 0 V 아니면 3.3 V만 낼 수 있습니다. 그런데 핀을 1초에 수백 번 켰다 껐다 하면서 켜져 있는 시간의 비율을 바꾸면, 평균적으로는 중간 세기처럼 동작합니다. 켜진 비율이 duty cycle입니다. 50%면 LED가 절반 밝기처럼 보입니다. 서보 모터는 보통 50 Hz(20 ms 주기) 신호에서 켜진 시간의 길이로 각도를 정합니다.

왜 GPIO에 모터를 직접 연결하면 안 되나: GPIO 핀은 신호용이라 작은 전압(3.3 V)과 작은 전류만 낼 수 있습니다. 모터는 큰 힘이 필요해서 훨씬 큰 전류를 원하므로, 핀에 바로 연결하면 모터가 안 돌거나 보드가 망가집니다. 그래서 GPIO는 "켜라/꺼라" 신호만 보내고, 실제 전기는 별도 전원에서 모터 드라이버나 트랜지스터라는 "전기 스위치"를 통해 공급합니다. 5 V를 쓰는 부품과 연결할 때는 전압을 바꿔 주는 level shifter를 씁니다.

모터·릴레이처럼 안에 코일이 든 장치는 전기를 끊는 순간 반대 방향으로 높은 전압이 튑니다. 이걸 흘려보내는 다이오드가 flyback 보호입니다.

Fail-safe: 프로그램이 멈추거나 센서가 고장 났을 때 모터가 계속 돌거나 릴레이가 켜진 채로 남으면 위험합니다. 그래서 "아무 신호가 없을 때의 기본 상태"가 안전한 쪽이 되도록 설계합니다.

카메라와 거리 센서를 함께 써서 "사람이 가까이 오면 경고"하는 예제입니다. 센서가 두 개라서 1장에서 배운 것 외에 두 가지를 더 챙겨야 합니다.

첫째, 같은 순간의 값끼리 짝짓기입니다. 카메라는 30 FPS(약 33 ms마다), 거리 센서는 50 Hz(20 ms마다)로 값을 내니 박자가 다릅니다. 그래서 카메라 사진마다 시간이 가장 가까운 거리 값을 골라 짝짓고, 그 시간 차이가 너무 크면(maximum age 초과) 그 값은 믿지 않습니다.

둘째, 무엇이 고장 날 수 있는지 미리 적어 두기입니다. 아래 실패 조건 다섯 개는 각각 앞에서 배운 개념과 연결됩니다. 노출 변화는 6.3절, saturation은 3.3절, timestamp 어긋남은 8.3절, 오래된 프레임 누적은 8.1절, 프로그램이 죽은 뒤 릴레이가 켜진 채 남는 것은 10절의 fail-safe입니다.