#TECH 수정: 2026-11-01 글 Vullean

Raspberry Pi Pico와 W5100S로 Azure IoT에 연결한 프로젝트, 지금도 참고할 수 있을까

2021년 Raspberry Pi Pico, WIZnet W5100S, Azure IoT C SDK를 연결한 프로젝트를 현재 기준으로 다시 살펴봅니다. 그대로 따라 할 설치 안내와 지금도 참고할 포팅 구조를 구분합니다.

네트워크 발행일: 2026-11-01 예상 읽기 시간: 약 5분 작성: Vullean Raspberry Pi Pico W5100S RP2040 Azure IoT Embedded Networking

이 프로젝트는 구식일까? 현재 그대로 빌드하는 안내로 보기에는 오래됐지만, 작은 MCU 프로젝트에 네트워크 칩과 TLS, 클라우드 SDK를 어떻게 연결했는지 돌아보는 사례로는 여전히 읽을 만하다.

여기서는 pico-examples 저장소의 코드와 README를 기준으로 구조와 한계를 살펴본다. 현재 환경에서 빌드하거나 Azure IoT Hub에 접속해 재검증한 튜토리얼은 아니다.

프로젝트에서 연결한 것

저장소의 README는 대상을 NonOS + WIZnet W5100S라고 적고 있다. 애플리케이션에는 telemetry, cloud-to-device, X.509 client와 device provisioning 예제 파일이 있다.

Azure IoT sample application
        |
Azure IoT C SDK
        |
project port: socket, TLS, time, platform APIs
        |
WIZnet ioLibrary / DHCP / DNS
        |
SPI
        |
W5100S

W5100S는 TCP/IP와 Ethernet 기능을 칩 안에 포함하고, MCU에 SPI 또는 parallel bus로 연결하는 hardwired TCP/IP controller다. 이 구조에서는 보드의 MCU가 lwIP를 실행하는 대신 WIZnet ioLibrary의 socket API를 사용한다. 프로젝트 README와 W5100S 제품 문서를 함께 보면 차이가 분명해진다.

따라서 이 코드는 lwIP 포팅 예제는 아니다. pbuf ownership이나 tcpip_thread 규칙을 설명하려는 글과는 별개의 네트워크 구조다. lwIP를 공부하려면 lwIP 학습 로드맵을 보면 된다.

CircuitPython으로 Pico와 W5500/W5100S를 연결한 별도 기록은 Pico와 WIZnet CircuitPython 프로젝트에서 다룬다. 두 프로젝트 모두 WIZnet 칩을 사용하지만 SDK와 애플리케이션 구조는 다르다.

지금 보기에 오래된 부분

의존성 버전이 2021년 기준이다

저장소의 CMake는 Azure IoT C SDK LTS_07_2021_Ref01과 Mbed TLS 3.0.0 경로를 기본값으로 둔다. README에는 Azure SDK 1.4.1도 함께 안내하고, 예시 빌드 출력은 azure-iot-sdk-c-1.4.1 경로를 사용한다. 저장소에 포함된 CMake 설정과 README의 의존성 및 빌드 기록이 서로 일치하지 않는다.

프로젝트의 마지막 변경은 2021년 11월 7일이다. 현재 Raspberry Pi Pico SDK의 최신 릴리스는 2.3.1이지만, 이 저장소는 사용할 Pico SDK의 정확한 버전을 고정하지 않고 로컬 PICO_SDK_PATH에 의존한다. 그러므로 과거 README의 빌드 명령만으로 현재 환경의 재현성을 기대하기 어렵다.

TLS 라이브러리 내부 헤더를 직접 수정하도록 안내한다

README는 Mbed TLS의 ssl.h와 x509_crt.h 안에 있는 필드를 바꾸는 임시 workaround를 요구한다. 공개 API 대신 라이브러리 내부 표현에 기대는 방식이라, 버전이 달라지면 컴파일이나 동작을 다시 확인해야 한다. 프로젝트 TLS adapter와 사용하는 Mbed TLS 버전을 함께 고정하지 않으면 이 수정이 왜 필요한지 추적하기도 어렵다.

인증 정보와 빌드 환경을 새로 설계해야 한다

README는 sample_certs.c에 IoT Hub connection string, 인증서와 개인 키를 넣으라고 안내한다. 이 방식은 과거 샘플을 이해하기 위한 설명으로만 봐야 한다. 실제 비밀값을 저장소에 넣지 말고, 인증서와 키를 생성, 보관, 폐기하는 절차를 현재 배포 환경에 맞게 따로 설계해야 한다.

그래도 읽어볼 만한 이유

이 프로젝트의 참고 가치는 지금의 최신 설치법보다 SDK 사이의 경계에 있다. 애플리케이션 코드만 가져오는 것으로 끝나지 않고, Azure SDK가 기대하는 socket, TLS, 시간, platform API를 해당 보드의 네트워크와 실행 모델에 맞춰 연결해야 한다.

저장소에는 그 경계가 파일로 나뉘어 있다.

요즘 환경으로 다시 옮긴다면 이런 경계를 따라 읽는 것이 유용하다. 어느 코드가 TCP/IP를 담당하고, TLS adapter가 socket 계층과 어떻게 이어지며, 시간이 필요한 SDK 함수를 어떤 실행 흐름에서 호출하는지 차례대로 확인할 수 있다.

지금 따라 할 수 있는 예제인가

현재 기준으로는 다음처럼 나누는 편이 정확하다.

구분 판단
2021년 당시의 포팅 구조와 파일 역할을 살펴보기 가능
과거 README만 보고 최신 도구로 그대로 빌드하기 먼저 버전과 설정을 재검증해야 함
현재 Azure 서비스에 실제 연결된다고 단정하기 현재 장비와 계정으로 다시 시험하기 전에는 단정할 수 없음
lwIP 동작을 배우는 자료로 사용하기 맞지 않음. W5100S의 hardwired TCP/IP 구조임

다시 실행 가능한 가이드로 만들려면 Pico SDK, Azure SDK, Mbed TLS와 WIZnet ioLibrary 버전을 함께 고정하고, 내부 헤더 수정 없이 TLS adapter를 구성할 수 있는지부터 검증해야 한다. 인증서와 장치 시간, DNS, TLS handshake까지 현재 환경에서 확인한 뒤에야 최신 설정 안내로 쓸 수 있다.

마무리

이 저장소는 오래됐지만 기록 가치까지 사라진 것은 아니다. 다만 최신 Azure IoT 연결 튜토리얼이 아니라, 2021년 Pico와 W5100S 프로젝트의 포팅 구조를 돌아보는 기술 회고로 다루는 편이 맞다.

현재 빌드와 서비스 연결은 다시 검증하지 않았으므로 이 글도 재현 절차를 약속하지 않는다. 다음 단계로 실제 보드와 현재 도구를 준비해 확인한다면, 그때의 설정과 결과를 별도의 재현 가능한 실습 글로 덧붙일 수 있다.

광고