I2C보다 I3C, 센서 연결 시장이 흔들리는 이유

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

센서가 늘어나자 I2C 통신의 익숙함이 비용이 됐다

온도 센서 하나에서 센서 허브로 바뀐 개발 현장

센서가 한두 개뿐인 실습 보드에서는 I2C 통신이 여전히 가장 편합니다. SDA와 SCL 두 선만 맞추고 풀업 저항을 확인하면 아두이노, 라즈베리파이, ESP32 계열 보드에서 바로 값을 읽을 수 있기 때문입니다. 문제는 사물인터넷 장치가 단순 온도 기록기를 넘어 움직임, 조도, 기압, 전류, 거리, 배터리 상태를 함께 보는 작은 센서 허브로 바뀌었다는 점입니다.

입문 단계에서는 아두이노의 기본 개념처럼 쉬운 개발 환경이 큰 장점입니다. 하지만 제품화 단계로 가면 같은 버스에 여러 센서가 붙고, 각 센서의 샘플링 주기와 인터럽트 처리 방식이 달라집니다. 이때 I2C는 단순한 배선 기술이 아니라 버스 점유율, 주소 충돌, 전력 예산, 펌웨어 구조를 함께 설계해야 하는 시스템 문제가 됩니다.

• 버스 점유율: 100kHz나 400kHz 환경에서 센서가 늘면 한 장치가 데이터를 읽는 동안 다른 장치가 기다리는 시간이 커집니다. 로그 주기가 느린 환경 센서는 괜찮지만 IMU와 전류 센서를 동시에 빠르게 읽으면 지연이 체감됩니다.
• 주소 충돌: 같은 센서 모듈을 두 개 쓰면 주소가 겹치는 일이 흔합니다. 주소 핀으로 해결되지 않으면 멀티플렉서나 두 번째 버스가 필요하고, 그 순간 회로와 코드가 복잡해집니다.
• 인터럽트 핀 증가: I2C는 데이터 선이 두 개라 배선이 간단하지만, 센서 이벤트를 즉시 받으려면 별도 INT 핀이 늘어납니다. 저전력 사물인터넷 장치에서는 이 핀 하나도 배터리와 보드 면적에 영향을 줍니다.
• 전압 혼재: 5V 아두이노 보드, 3.3V 라즈베리파이, 1.8V 센서가 섞이면 레벨 시프터와 풀업 위치가 설계의 핵심이 됩니다. 단순 점퍼선 실습과 실제 제품 회로가 갈라지는 지점입니다.
• 진단 난이도: 값이 가끔 튀거나 장치가 사라지는 증상은 배선 불량처럼 보이지만, 실제로는 클럭 스트레칭, 풀업 저항, 노이즈, 드라이버 초기화 순서가 얽힌 경우가 많습니다.

트렌드를 읽을 때 핵심은 새 버스가 오래된 버스를 완전히 대체하느냐가 아닙니다. 같은 보드 면적에서 더 많은 센서를 안정적으로 다뤄야 하는 압력이 커졌느냐를 보는 것이 실무에 더 가깝습니다.

시장 변화는 부품표보다 펌웨어에서 먼저 보인다

흥미로운 변화는 부품 가격표보다 개발 흐름에서 먼저 나타납니다. 라즈베리파이에서는 I2C가 여전히 저속 주변장치와 센서 연결의 표준 선택지로 쓰이고, 아두이노 생태계도 Wire 라이브러리를 중심으로 수많은 예제가 유지됩니다. 다만 최신 임베디드 개발에서는 센서 값을 읽는 코드보다 디바이스 드라이버 통합개발환경의 개요에서 말하는 개발 환경처럼 드라이버, 테스트, 타깃 보드, 로그 도구를 한 덩어리로 보는 시각이 중요해졌습니다. 결국 I2C를 계속 쓰더라도 추상화 계층을 두고, 버스 변경이 애플리케이션 전체를 흔들지 않게 만드는 팀이 다음 하드웨어 전환에 유리합니다.

I3C가 빨라진 것이 아니라 보드의 역할이 달라졌다

I3C Basic v1.2가 보여주는 방향

2026년 9월 기준으로 I3C 흐름에서 눈여겨볼 지점은 단순 속도 홍보가 아닙니다. MIPI I3C v1.2와 I3C Basic v1.2는 2025년에 공개 흐름이 정리되었고, 문서 구조와 명확성을 강화해 구현자가 헷갈릴 수 있는 부분을 줄이는 방향으로 움직였습니다. 다시 말해 시장은 이제 I3C를 실험적인 새 장난감이 아니라 I2C 이후의 표준화된 센서 버스 후보로 다루기 시작했습니다.

I3C는 두 선을 쓰면서도 동적 주소 할당, 인밴드 인터럽트, 핫조인, 더 높은 전송률 같은 기능을 제공합니다. 표준 SDR 기준으로도 I2C보다 넓은 대역을 기대할 수 있고, HDR 모드에서는 더 큰 데이터 전송도 노릴 수 있습니다. 하지만 이것을 곧바로 모든 아두이노 프로젝트에 적용하라는 뜻으로 받아들이면 위험합니다. 컨트롤러, 타깃 센서, 드라이버, 분석 장비, 예제 코드가 함께 갖춰져야 실제 생산성이 올라갑니다.

엣지 AI와 센서 퓨전이 버스 선택을 밀어붙인다

최근 보드 시장의 변화는 센서를 많이 붙이는 것에서 끝나지 않습니다. 작은 장치가 현장에서 데이터를 모으고, 일부 판단을 클라우드로 보내기 전에 자체적으로 처리하는 엣지 AI 구조가 늘고 있습니다. 예를 들어 드론용 AI 보드 공개 소식처럼 기기 안에서 인식과 추적을 처리하려는 흐름은 센서 연결 방식에도 영향을 줍니다. 카메라 데이터 자체는 별도 고속 인터페이스가 담당하더라도, 전원 관리 IC, IMU, 온도 센서, 거리 센서, 상태 모니터링 칩은 여전히 보드 내부의 제어 버스에 매달립니다.

• 제품형 사물인터넷은 센서 데이터가 많아질수록 버스가 느린 병목이 될 수 있습니다. 특히 배터리 구동 장치라면 필요할 때만 깨우고 빠르게 읽고 다시 잠드는 구조가 중요합니다.
• 라즈베리파이 기반 게이트웨이는 여전히 I2C 확장성이 좋습니다. 다만 여러 센서 모듈을 긴 점퍼선으로 묶기보다, 센서 보드를 가까이 두고 통신 안정성을 우선해야 합니다.
• 아두이노 학습 프로젝트는 I2C가 압도적으로 실용적입니다. I3C를 먼저 배우기보다 풀업 저항, 주소 스캔, 로직 분석기 캡처를 익히는 편이 더 오래 갑니다.
• 임베디드 개발팀은 지금부터 드라이버 경계를 나누는 편이 좋습니다. 센서 읽기 함수가 직접 Wire 호출에 묶이면 나중에 SPI나 I3C로 옮길 때 코드 전체를 고치게 됩니다.
• PCB 설계에서는 I3C를 당장 쓰지 않더라도 테스트 패드, 풀업 저항 옵션, 전압 레일 분리, 짧은 배선 길이를 남겨 두면 다음 리비전에서 선택지가 넓어집니다.

I3C의 장점은 숫자로 보이는 속도보다 이벤트 처리 방식에 있습니다. 폴링으로 자주 묻는 보드에서, 필요한 순간 센서가 먼저 말할 수 있는 보드로 바뀌는 것이 더 큰 변화입니다.

아두이노와 라즈베리파이 프로젝트는 지금 무엇을 골라야 하나

I2C가 아직 첫 선택인 조건

가장 자주 받는 질문은 간단합니다. 지금 센서 프로젝트를 시작한다면 I2C를 써도 되느냐는 것입니다. 답은 대부분의 아두이노와 라즈베리파이 프로젝트에서 그렇다입니다. 온습도, 조도, 기압, RTC, 저속 전류 측정처럼 초당 수십 회 이하로 읽어도 충분한 센서라면 I2C 통신은 여전히 가장 경제적이고 자료가 풍부한 선택입니다. 모듈 가격도 대체로 접근성이 좋고, 국내 유통 기준으로 흔한 센서 보드는 몇천 원대부터 시작하는 경우가 많아 실습과 검증에 부담이 적습니다.

1. 센서가 1개에서 4개 정도이고 값 변화가 느리다면 I2C를 먼저 선택합니다. 배선이 짧고 풀업이 적절하다면 개발 속도가 빠릅니다.
2. 같은 주소의 센서를 여러 개 써야 한다면 주소 변경 핀, I2C 멀티플렉서, 보드의 두 번째 I2C 버스를 순서대로 검토합니다. 이 단계에서 갑자기 I3C로 넘어가기보다 현재 생태계에서 안정적인 해결책을 찾는 편이 낫습니다.
3. IMU, 전류 센서, 거리 센서를 높은 주기로 동시에 읽는다면 버스 점유율을 계산합니다. 이때 로직 분석기로 실제 SCL 속도와 트랜잭션 시간을 확인하면 감으로 고르는 실수를 줄일 수 있습니다.
4. 제품화를 목표로 하고 센서 수가 계속 늘 전망이라면 회로는 I2C로 시작하더라도 펌웨어 구조는 I3C나 SPI로 갈아탈 수 있게 만듭니다. 센서 드라이버와 애플리케이션 로직을 분리하는 것이 핵심입니다.
5. 전력 예산이 매우 빡빡하다면 폴링 주기부터 줄입니다. 버스 교체보다 센서 슬립 모드, 인터럽트 활용, 배치 읽기 전략이 먼저 효과를 내는 경우가 많습니다.

그럼 I3C 보드는 언제 사야 할까

신기술이 보이면 바로 사야 할 것 같지만, I3C는 목적이 분명할 때 빛납니다. 컨트롤러가 I3C를 지원하고, 쓰려는 센서도 I3C 모드를 제공하며, 운영체제나 RTOS 드라이버에서 해당 조합을 다룰 수 있어야 합니다. 라즈베리파이의 일반적인 GPIO 프로젝트처럼 I2C 자료가 훨씬 많은 환경에서는 I3C 보드를 사도 예제 부족이 발목을 잡을 수 있습니다. 아두이노 계열도 보드마다 주변장치 지원이 다르므로, 구매 전에는 라이브러리 이름보다 실제 하드웨어 컨트롤러 지원 여부를 먼저 봐야 합니다.

실무적으로는 세 가지 경우에 I3C 검토가 빨라집니다. 첫째, 여러 센서 이벤트를 별도 INT 핀 없이 처리하고 싶을 때입니다. 둘째, 폴링 때문에 MCU가 자주 깨어나 배터리 수명이 줄어드는 제품일 때입니다. 셋째, 향후 같은 PCB에서 센서 구성이 바뀔 가능성이 높고 드라이버 추상화가 이미 준비되어 있을 때입니다. 이 조건이 아니라면 I2C를 단단하게 쓰는 편이 비용과 일정 면에서 더 낫습니다.

• 구매 전 확인 1: MCU 데이터시트에서 I3C 컨트롤러가 있는지, 단순 I2C 호환 표기인지 구분합니다. I2C 핀을 가진 보드가 곧 I3C 보드라는 뜻은 아닙니다.
• 구매 전 확인 2: 센서 데이터시트에서 I3C 모드 진입 조건, I2C 레거시 모드 지원, 허용 전압, 풀업 요구 사항을 봅니다. 같은 패키지라도 모듈 보드가 기능을 제한할 수 있습니다.
• 구매 전 확인 3: 드라이버 예제의 최종 업데이트 시점을 확인합니다. 2026년에 새 보드를 고를 때도 예제가 몇 년 전 베타 상태라면 개발 시간이 더 듭니다.
• 구매 전 확인 4: 로직 분석기가 I3C 해석을 지원하는지 확인합니다. 디버깅 장비가 없으면 새 버스의 장점보다 원인 모를 통신 오류가 더 크게 느껴집니다.
• 구매 전 확인 5: 지금 만들 장치가 학습용인지, 판매 가능한 사물인터넷 제품인지 정합니다. 학습용은 자료가 많은 I2C가 좋고, 제품형은 다음 리비전까지 고려한 버스 전략이 필요합니다.

자주 묻는 질문에 하나만 깊게 답하자면, I2C 센서 회로를 지금 설계하면 곧 낡아 보일까라는 걱정은 과합니다. 낡아 보이는 회로는 I2C를 썼기 때문이 아니라, 풀업 값을 검토하지 않고 긴 배선을 방치하고 드라이버를 애플리케이션 코드에 섞어 둔 회로입니다. 반대로 짧은 버스, 분리 가능한 풀업, 주소표, 테스트 패드, 추상화된 센서 드라이버를 갖춘 I2C 설계는 I3C 시대에도 충분히 좋은 출발점입니다. 다음 보드 리비전에서 바꿔야 할 것은 버스 이름이 아니라, 센서가 늘어나도 흔들리지 않는 연결 구조입니다.