I2C 통신과 SPI, 센서 연결에서 갈리는 순간

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

센서를 많이 붙일수록 먼저 갈리는 선택

핀 수가 부족한 보드라면 I2C가 먼저 보입니다

아두이노나 라즈베리파이에 온습도, 조도, 기압, 가속도 센서를 동시에 붙이다 보면 가장 먼저 부딪히는 문제는 속도가 아니라 핀 수와 배선 정리입니다. 이때 I2C 통신은 SDA와 SCL 두 선을 여러 장치가 공유하므로 작은 프로젝트에서 꽤 강한 선택지가 됩니다.

반대로 SPI는 MOSI, MISO, SCK에 장치별 CS 선이 추가됩니다. 센서가 하나일 때는 단순하지만 장치가 늘수록 선택선이 계속 필요해지고, 브레드보드 위에서는 배선이 금방 복잡해집니다. 그래서 초보자는 I2C가 쉽다고 느끼고, 고속 데이터가 필요한 사람은 SPI가 편하다고 말합니다.

• I2C 통신: 선은 적고 주소 관리가 중요합니다.
• SPI: 속도는 빠르지만 장치마다 CS 배선이 늘어납니다.
• 센서 연결: 센서 개수, 데이터량, 보드 핀 수를 함께 봐야 합니다.

센서가 3개 이상이고 데이터가 느리게 변한다면 I2C부터 검토하고, 화면·카메라·고속 ADC처럼 연속 데이터가 많다면 SPI 쪽을 먼저 의심하는 편이 실무적으로 빠릅니다.

속도 대결은 SPI가 이기지만 항상 필요한 승리는 아닙니다

느린 센서는 빠른 버스가 체감되지 않습니다

SPI는 구조상 클럭을 높게 가져가기 쉽고, 전이중 통신도 가능합니다. 마이크로SD 카드, 디스플레이, 고속 ADC처럼 데이터를 계속 밀어 넣거나 읽어야 하는 장치에서는 SPI의 장점이 분명합니다. 하지만 온습도 센서처럼 1초에 한두 번 읽는 장치라면 그 속도 차이가 사용자 경험으로 이어지지 않습니다.

I2C 통신은 보통 표준 모드, 고속 모드, 더 빠른 확장 모드로 나뉘지만, 실제 아두이노 프로젝트에서는 배선 길이와 풀업 저항, 센서 모듈 품질 때문에 이론 속도보다 안정성이 더 중요합니다. 특히 사물인터넷 장치에서 센서값을 MQTT나 HTTP로 보내는 구조라면 통신 병목은 센서 버스보다 네트워크나 전원 관리에서 생기는 일이 많습니다.

데이터량으로 보면 판단이 쉬워집니다

1. 온습도, 조도, 기압처럼 값이 천천히 변하면 I2C 통신이 충분합니다.
2. IMU를 높은 샘플링으로 읽거나 파형을 수집하면 SPI가 유리합니다.
3. OLED 작은 화면은 I2C도 가능하지만, 큰 화면이나 빠른 갱신은 SPI가 낫습니다.
4. 라즈베리파이에서 여러 센서를 주기적으로 기록하는 정도라면 I2C의 배선 단순성이 더 크게 작용합니다.

속도만 보면 SPI가 화려하지만, 프로젝트 전체로 보면 필요한 만큼만 빠른 구조가 더 좋습니다. 빠른 버스는 배선, 디버깅, 핀 점유라는 비용을 함께 가져오기 때문입니다.

주소 충돌과 CS 핀 부족은 서로 다른 골칫거리입니다

I2C는 주소표를 먼저 확인해야 합니다

I2C 통신의 약점은 장치마다 주소가 있다는 점입니다. 같은 주소를 가진 센서 두 개를 같은 버스에 그대로 붙이면 둘 중 하나를 선택해서 말할 방법이 없습니다. 예를 들어 같은 온습도 센서 모듈을 두 지점에 달고 싶을 때, 주소 변경 핀이 없으면 멀티플렉서나 별도 버스를 고려해야 합니다.

SPI는 주소 충돌이 아니라 CS 핀 관리가 문제입니다. 장치마다 선택선이 따로 있으니 같은 종류 장치를 여러 개 붙이는 것은 비교적 명확합니다. 대신 보드의 남는 GPIO가 부족해질 수 있고, 라즈베리파이처럼 다른 기능과 핀이 겹치는 환경에서는 핀맵을 먼저 그려야 합니다.

• I2C에서 같은 주소 센서가 겹치면 주소 변경 가능 여부를 먼저 확인합니다.
• 주소 변경이 안 되면 TCA9548A 같은 I2C 멀티플렉서가 대안이 됩니다.
• SPI는 장치 수만큼 CS 핀을 확보하거나 GPIO 확장을 고려합니다.
• 실제 회로에서는 통신 방식보다 핀 배치와 케이블 동선이 실패를 더 자주 만듭니다.

아두이노 입문자는 보통 라이브러리 예제부터 실행하지만, 임베디드 개발에서는 예제 코드보다 데이터시트의 주소, 전압, 타이밍 표를 먼저 봐야 합니다. 아두이노의 기본 개념을 익힌 뒤에도 실제 센서 연결에서는 이 작은 표 하나가 하루짜리 삽질을 줄여줍니다.

전원과 노이즈 앞에서는 배선이 더 솔직합니다

I2C는 풀업 저항과 선 길이에 민감합니다

I2C 통신은 오픈드레인 구조를 쓰기 때문에 풀업 저항이 신호 품질을 좌우합니다. 모듈에 이미 풀업 저항이 들어 있는 경우가 많아 처음에는 편하지만, 여러 모듈을 동시에 붙이면 풀업이 병렬로 겹쳐 값이 너무 낮아질 수 있습니다. 그러면 파형이 예쁘게 올라오지 않거나 특정 센서만 간헐적으로 응답하지 않는 일이 생깁니다.

SPI도 노이즈에서 자유롭지는 않습니다. 클럭이 빠른 만큼 긴 점퍼선, 느슨한 접지, 전원 리플에 민감해질 수 있습니다. 다만 장치 선택이 분리되어 있어 I2C처럼 한 장치의 문제로 전체 버스가 멈춘 듯 보이는 상황은 상대적으로 덜합니다.

책상 위 성공과 현장 성공은 다릅니다

• 브레드보드 테스트에서는 I2C가 깔끔해 보여도 케이스 안 배선에서는 오류가 생길 수 있습니다.
• 긴 배선이 필요하면 차동 통신, 버스 확장기, 센서 위치 재배치를 검토합니다.
• 3.3V 라즈베리파이와 5V 아두이노 센서를 섞을 때는 레벨 시프터를 확인합니다.
• 전원선과 신호선을 묶어 길게 빼면 센서값이 흔들릴 수 있습니다.

사물인터넷 장치가 하루 이틀은 잘 움직이다가 현장 설치 후 멈춘다면 코드를 먼저 의심하기 쉽습니다. 하지만 전원 어댑터 품질, 접지 공유, 케이블 고정, 풀업 저항 중 하나가 원인인 경우도 많습니다. 통신 방식 선택은 회로 환경을 포함한 선택이어야 합니다.

코드 작성 난이도는 라이브러리보다 디버깅에서 갈립니다

I2C는 스캐너 하나로 시작이 쉽습니다

아두이노에서 I2C 센서를 붙일 때는 I2C 스캐너 예제로 장치 주소가 보이는지 확인하는 습관이 좋습니다. 주소가 보이면 최소한 전원, SDA, SCL, 풀업의 큰 문제는 통과한 셈입니다. 이 단순한 확인 절차 덕분에 I2C는 입문자에게 친절한 편입니다.

SPI는 장치마다 모드, 클럭 극성, 클럭 위상, 최대 속도 설정이 다를 수 있습니다. 라이브러리가 잘 되어 있으면 몰라도 되지만, 여러 SPI 장치를 한 버스에 붙이면 각 장치가 원하는 설정을 전환해야 합니다. 여기서 설정 복원이 빠지면 디스플레이는 되는데 메모리 카드가 안 되거나, 센서는 되는데 화면이 깨지는 식의 문제가 나옵니다.

1. I2C는 먼저 스캐너로 주소가 잡히는지 확인합니다.
2. 주소가 안 보이면 배선, 전압, 풀업, GND 공유를 순서대로 봅니다.
3. SPI는 CS 핀이 정확히 HIGH와 LOW로 제어되는지 확인합니다.
4. SPI 장치가 여러 개라면 각 장치의 SPI 모드와 클럭을 코드에서 분리합니다.

라이브러리 예제가 실행된다는 사실은 출발점일 뿐입니다. 여러 센서를 동시에 붙이는 순간부터는 버스 설정, 초기화 순서, 에러 재시도 로직이 품질을 가릅니다.

임베디드 개발 환경에서는 코드 편집기, 컴파일러, 보드 설정, 드라이버가 함께 맞아야 합니다. 개발 도구의 개념이 낯설다면 통합개발환경의 개요처럼 큰 흐름을 먼저 잡아두면 보드별 설정 차이를 이해하기가 수월합니다.

아두이노와 라즈베리파이는 같은 답을 주지 않습니다

아두이노는 단순성과 실시간성이 강점입니다

아두이노는 센서 하나를 읽고 릴레이를 켜거나 작은 OLED에 값을 표시하는 작업에 잘 맞습니다. I2C 통신을 쓰면 핀을 아끼면서 여러 센서를 붙이기 좋고, 코드도 비교적 짧습니다. 전원이 안정적이고 샘플링 속도가 낮다면 작은 보드 하나로도 충분히 실용적인 장치를 만들 수 있습니다.

라즈베리파이는 리눅스 기반이라 파일 저장, 웹 서버, 데이터 시각화, 네트워크 연동이 강합니다. 대신 실시간 제어는 아두이노보다 신경 쓸 부분이 많습니다. 라즈베리파이에 I2C 센서를 붙여 데이터를 저장하고, 고속 장치나 화면은 SPI로 연결하는 혼합 구조도 흔히 쓰입니다.

보드 성격에 따라 통신 선택이 달라집니다

• 아두이노 단독 장치라면 I2C 센서와 간단한 액추에이터 조합이 관리하기 쉽습니다.
• 라즈베리파이 데이터 로거라면 I2C 센서값을 주기적으로 기록하고 네트워크로 전송하기 좋습니다.
• 디스플레이를 빠르게 갱신해야 하면 SPI OLED나 TFT를 고려합니다.
• 산업 현장처럼 긴 거리와 잡음이 크면 I2C와 SPI보다 RS-485나 CAN이 맞을 수 있습니다.

요즘 사물인터넷 프로젝트는 단순히 센서값을 읽는 데서 끝나지 않습니다. 사용자의 생활 패턴이나 장치 상태를 기록하는 라이프로그 성격으로 확장되기도 하는데, 이런 흐름은 라이프로그 서비스 설명에서도 맥락을 볼 수 있습니다. 센서 통신 선택은 결국 어떤 데이터를 얼마나 자주, 어디까지 보낼지와 연결됩니다.

가격보다 중요한 것은 실패했을 때 바꿀 수 있는 구조입니다

부품값은 작아도 재작업 비용은 큽니다

I2C 센서 모듈은 대체로 저렴하고 종류도 많습니다. 온습도, 기압, 조도, 거리, 전류 측정 등 기본 센서군은 몇천 원대부터 구할 수 있어 빠른 프로토타입에 좋습니다. SPI 장치도 저렴한 편이지만, 디스플레이나 저장장치처럼 기능이 큰 모듈은 배선과 전원 설계까지 함께 봐야 합니다.

문제는 부품값보다 재작업 비용입니다. 케이스를 이미 출력했고 배선을 납땜했는데 주소 충돌이 발견되면 멀티플렉서를 추가하거나 센서 종류를 바꿔야 합니다. 반대로 SPI로 설계했는데 남는 GPIO가 부족하면 핀 확장이나 보드 변경이 필요합니다. 작은 프로젝트라도 처음에 변경 여지를 남기는 편이 좋습니다.

1. 센서 후보를 고를 때 같은 기능의 I2C형과 SPI형을 함께 찾아봅니다.
2. 주소 변경 핀, 전압 범위, 라이브러리 유지 상태를 확인합니다.
3. PCB를 만들기 전에는 테스트 패드와 예비 GPIO를 남깁니다.
4. 현장 교체를 생각한다면 커넥터 방향과 케이블 길이도 기록합니다.

실무에서는 가장 싼 센서보다 문제가 생겼을 때 대체 가능한 센서가 더 안전합니다. 특히 블로그 예제를 따라 하는 단계에서 제품 형태로 넘어갈 계획이 있다면, 지금 당장 동작하는 회로보다 나중에 바꿀 수 있는 회로가 더 오래 버팁니다.

두 방식을 섞어도 되냐는 질문에 대한 현실적인 답

섞는 것은 가능하지만 기준 없이 섞으면 디버깅이 길어집니다

I2C 통신과 SPI는 한 프로젝트 안에서 함께 써도 됩니다. 실제로 라즈베리파이에는 I2C 센서 여러 개를 붙이고, SPI 디스플레이나 ADC를 같이 쓰는 구성이 흔합니다. 아두이노에서도 핀이 허용된다면 I2C 온습도 센서와 SPI 화면을 동시에 운용할 수 있습니다.

다만 섞을 때는 역할을 분명히 나누는 것이 좋습니다. 느리게 변하는 환경 센서는 I2C, 빠르게 갱신해야 하는 화면이나 저장장치는 SPI처럼 기준을 세우면 회로도와 코드가 훨씬 읽기 쉬워집니다. 모든 장치를 한 방식으로 통일하려고 애쓰면 오히려 성능이나 안정성에서 손해를 볼 수 있습니다.

• 환경 센서, RTC, 소형 EEPROM은 I2C 후보로 둡니다.
• TFT 화면, SD 카드, 고속 ADC는 SPI 후보로 둡니다.
• 전원 라인은 통신 방식과 별개로 충분한 용량과 안정성을 확보합니다.
• 코드에서는 I2C 초기화와 SPI 초기화를 분리하고, 오류 로그를 따로 남깁니다.

독자가 가장 자주 묻는 질문은 “처음 배우는 입장에서는 무엇을 먼저 익혀야 하느냐”입니다. 답은 I2C 통신을 먼저 익히고, 데이터가 많아지는 순간 SPI로 확장하는 순서입니다. 이렇게 가면 센서 연결의 기본인 전원, GND, 주소, 풀업, 라이브러리 초기화를 자연스럽게 배우고, 이후 SPI에서 CS 핀과 클럭 설정을 이해할 발판이 생깁니다.

이미 프로젝트가 정해져 있다면 순서를 바꿔도 됩니다. 작은 날씨 기록 장치라면 I2C가 출발점이고, 빠른 그래프 표시 장치라면 SPI가 출발점입니다. 중요한 것은 어느 쪽이 더 우수하냐가 아니라, 내 센서가 얼마나 자주 말해야 하고 보드가 그 말을 얼마나 안정적으로 받아야 하는지를 먼저 정하는 일입니다.