I2C 통신 vs SPI, 센서 버스 선택의 기준

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

I2C와 SPI가 갈리는 첫 지점은 배선 수입니다

두 선으로 끝내는 I2C, 대신 규칙이 많습니다

센서 여러 개를 한 보드에 붙일 때 가장 먼저 부딪히는 선택은 I2C 통신이냐 SPI 통신이냐입니다. 아두이노나 라즈베리파이 예제에서는 둘 다 쉽게 보이지만, 실제 프로젝트 박스 안에 넣고 며칠 돌려보면 차이가 꽤 선명해집니다.

I2C는 SDA와 SCL 두 선만으로 여러 장치를 연결할 수 있어 배선이 단순합니다. 온습도 센서, 조도 센서, 기압 센서처럼 저속으로 값을 읽는 센서 연결에는 특히 편합니다. 다만 주소 충돌, 풀업 저항, 버스 길이, 전압 레벨 같은 조건을 무시하면 통신이 간헐적으로 멈추는 쪽도 I2C입니다.

• I2C 장점: 선이 적고 센서를 병렬로 붙이기 쉽습니다. 작은 프로젝트, 교육용 실습, 저속 환경 데이터 수집에 잘 맞습니다.
• I2C 단점: 같은 주소를 가진 센서가 있으면 바로 난감해집니다. 배선이 길어지거나 풀업이 맞지 않으면 파형이 무너질 수 있습니다.
• 현장 기준: 센서가 2~5개이고 1초에 몇 번 읽는 수준이라면 I2C가 대부분 더 깔끔합니다.

SPI는 선이 많지만 속도와 예측 가능성이 좋습니다

SPI는 MOSI, MISO, SCK에 장치별 CS 선이 필요합니다. 센서가 늘어날수록 칩 선택선도 늘어나므로 브레드보드에서는 금방 복잡해 보입니다. 대신 통신 구조가 단순하고 속도가 빨라 디스플레이, 플래시 메모리, 고속 ADC처럼 데이터량이 큰 부품에서 강합니다.

예를 들어 라즈베리파이에 소형 OLED 하나와 저가형 센서 몇 개를 붙인다면 I2C가 편합니다. 반대로 컬러 TFT 화면을 빠르게 갱신하거나 샘플링 속도가 높은 센서 데이터를 놓치면 안 되는 프로젝트라면 SPI가 낫습니다. 아두이노의 기본 개념처럼 입문 보드에서는 쉬운 예제로 시작하지만, 실제 설계에서는 버스 특성까지 같이 봐야 합니다.

팁: 배선이 적은 것이 항상 안정적이라는 뜻은 아닙니다. I2C는 선이 적은 대신 버스 전체가 하나의 전기적 환경을 공유하므로, 풀업과 배선 품질이 프로젝트의 성패를 좌우합니다.

센서 프로젝트에서는 속도보다 실패 방식이 더 중요합니다

느려도 괜찮은 데이터와 놓치면 안 되는 데이터

I2C와 SPI를 비교할 때 흔히 속도 숫자부터 봅니다. 하지만 사물인터넷 프로젝트에서는 최고 속도보다 실패했을 때 어떤 일이 벌어지는지가 더 중요합니다. 온습도 값이 1초 늦게 들어오는 것은 괜찮지만, 모터 전류 감시 값이나 고속 진동 데이터가 빠지면 판단 자체가 틀어질 수 있습니다.

I2C는 일반적으로 환경 센서처럼 값 변화가 느린 부품에 잘 맞습니다. 반면 SPI는 화면 출력, 저장장치, 고속 센서처럼 연속 데이터가 필요한 부품에 유리합니다. 사용자가 체감하는 차이는 코드 한 줄보다 운영 중 복구 방식에서 크게 나타납니다.

1. 온습도·조도·기압: I2C가 유리합니다. 읽는 주기가 길고 모듈 종류가 많아 아두이노 실습과 임베디드 개발 입문에 적합합니다.
2. OLED·간단한 RTC: I2C로 충분한 경우가 많습니다. 단, 같은 주소 장치가 함께 쓰이는지 먼저 확인해야 합니다.
3. TFT LCD·SD 카드·고속 ADC: SPI가 유리합니다. 데이터 전송량이 많고 일정한 응답 시간이 필요하기 때문입니다.
4. 여러 센서의 장거리 배선: 둘 다 조심해야 합니다. I2C는 특히 케이블 길이와 노이즈에 민감하므로 별도 버퍼나 통신 방식 변경을 검토해야 합니다.

에러가 났을 때 복구 난이도도 다릅니다

I2C 버스에서 특정 장치가 SDA를 잡고 놓지 않으면 나머지 센서까지 함께 멈춘 것처럼 보일 수 있습니다. 그래서 실무에서는 전원 재인가 회로, 버스 리셋 루틴, 타임아웃 처리를 함께 넣습니다. 반면 SPI는 장치별 CS 선으로 선택하기 때문에 한 장치의 문제가 전체 버스에 미치는 영향이 상대적으로 좁습니다.

그렇다고 SPI가 무조건 안전한 것은 아닙니다. CS 제어가 잘못되면 두 장치가 동시에 응답하거나, 배선이 길 때 클록 신호가 흔들려 잘못된 데이터가 들어올 수 있습니다. 특히 라즈베리파이처럼 리눅스 기반 보드에서는 디바이스 드라이버 설정도 함께 봐야 하며, 디바이스 드라이버 통합개발환경의 개요를 참고하면 하드웨어와 소프트웨어 계층이 왜 함께 묶이는지 이해하는 데 도움이 됩니다.

• I2C 복구 포인트: 통신 타임아웃, SCL 클록 펄스 복구, 센서별 전원 스위칭을 고려합니다.
• SPI 복구 포인트: CS 초기 상태, 전송 모드, 클록 극성·위상 설정을 점검합니다.
• 공통 포인트: 실패 로그를 남겨야 원인을 찾을 수 있습니다. 단순히 재부팅으로 덮으면 현장 문제는 반복됩니다.

전문가 조언: 센서 버스 선택은 “빠른가?”보다 “문제가 생겼을 때 어느 범위까지 번지는가?”를 기준으로 보면 훨씬 현실적인 판단이 됩니다.

예산과 제작 시간으로 보면 선택이 더 빨라집니다

아두이노 실습은 I2C, 제품 느낌은 혼합 구성이 많습니다

처음 만드는 아두이노 센서 박스라면 I2C로 시작하는 편이 빠릅니다. 배선이 적고 예제 코드가 많으며, 온습도·기압·조도·OLED 같은 부품을 한 버스에 묶기 쉽습니다. 아두이노 관련 설명에서도 볼 수 있듯이 입문 환경의 장점은 빠르게 연결하고 동작을 확인하는 데 있습니다.

하지만 프로젝트가 커지면 I2C 하나로 모든 것을 해결하려는 방식은 오히려 시간을 잡아먹습니다. 환경 센서는 I2C, 화면이나 저장장치는 SPI, 외부 장거리 통신은 UART·RS-485·무선 모듈로 나누는 식의 혼합 구성이 더 자연스럽습니다. 사물인터넷 장치에서 중요한 것은 특정 통신 하나를 고집하는 것이 아니라, 데이터 성격에 맞게 버스를 나누는 설계 감각입니다.

• 하루짜리 실습: I2C 센서 1~3개와 아두이노 조합이 가장 빠릅니다. 배선 실수도 적고 결과 확인이 쉽습니다.
• 일주일짜리 프로토타입: I2C 센서와 SPI 표시장치를 분리하면 디버깅이 편합니다. 화면 갱신 때문에 센서 읽기가 밀리는 문제를 줄일 수 있습니다.
• 한 달 이상 운용: 통신 실패 로그, 커넥터 고정, 전원 노이즈 대책까지 포함해야 합니다. 이 단계에서는 버스 선택보다 유지보수 구조가 더 중요해집니다.

숫자로 잡아보는 현실적인 선택 기준

부품 가격만 보면 I2C 센서 모듈과 SPI 센서 모듈의 차이는 크지 않은 경우가 많습니다. 국내 온라인 부품몰 기준으로 흔한 환경 센서는 대략 몇천 원대부터 시작하고, 고속 ADC나 정밀 센서는 사양에 따라 가격이 빠르게 올라갑니다. 문제는 부품값보다 디버깅 시간입니다. 3시간 안에 동작 확인이 목표라면 I2C가 유리하고, 1Mbps 이상 전송이나 빠른 화면 갱신이 필요하면 SPI를 처음부터 잡는 편이 낫습니다.

실무적으로는 다음 숫자를 기준선으로 두면 판단이 빨라집니다. 센서가 5개 이하이고 배선 길이가 30cm 안쪽이며 초당 1~10회 읽는다면 I2C로 충분한 경우가 많습니다. 반대로 데이터가 연속으로 흐르고, 장치별 응답 시간이 중요하며, 보드 안에서 선 몇 가닥이 늘어나는 것을 감당할 수 있다면 SPI가 더 든든합니다.

1. 예산 1만~3만 원: 아두이노 호환 보드와 I2C 센서 1~2개로 시작합니다. 학습 속도가 빠르고 실패 비용이 낮습니다.
2. 예산 3만~7만 원: I2C 환경 센서에 SPI 디스플레이를 붙여 역할을 나눕니다. 작은 사물인터넷 대시보드 형태까지 만들 수 있습니다.
3. 작업 시간 2~3시간: I2C가 유리합니다. 주소 스캔, 라이브러리 예제 실행, 시리얼 출력까지 흐름이 짧습니다.
4. 작업 시간 1~2일: SPI 설정과 배선 검증에 시간을 배정할 수 있습니다. 로직 애널라이저로 클록과 CS를 확인하면 삽질을 크게 줄일 수 있습니다.
5. 운용 기간 2주 이상: 통신 방식보다 커넥터, 전원 안정화, 예외 처리 코드에 시간을 써야 합니다. 대략 제작 시간의 30%는 동작 구현, 70%는 안정화에 잡는 편이 현실적입니다.