충전기 소프트웨어를 고르다 BSP 버전에 부딪혔다 — EVerest와 Dunfell

8 분 소요

SC6_0 보드의 하드웨어 시험이 꽤 진행됐다. PLC 모뎀(QCA7005)이 펌웨어를 받아 돌고, ADC로 CP 전압을 읽고, PWM으로 CP를 움직이고, 누전·비상 인터럽트가 들어오고, 전력량계와 Modbus로 대화한다.

이제 이 위에 충전기 프로그램을 올려야 한다. 오늘은 그 소프트웨어를 고르는 데 하루를 썼다. 결론부터 말하면 EVerest로 기울었다. 그런데 결정적인 걸림돌은 언어도 라이브러리도 아니라 지금 쓰는 BSP의 버전이었다.

1. 충전기 프로그램이 해야 할 일

먼저 범위를 나눴다.

층	하는 일	SC6_0 하드웨어
① 기본 충전 제어 (IEC 61851)	CP 상태 판정(12/9/6V), PWM 듀티로 허용 전류 알림, 릴레이, 누전·비상 처리	`pwmchip0`, ADC `iio:device4`, DOUT, RCD/EM_INT
② 고급 통신 (ISO 15118)	SLAC으로 차량과 매칭 → IP 통신, Plug&Charge	QCA7005 (`eth1`)
③ 서버 연동 (OCPP)	충전 시작·종료, 과금, 원격 제어	유선, WiFi
④ 주변 기능	전력량, 카드 인증, 표시	전력량계, 카드 리더, LCD 시리얼

①만 있으면 “충전은 되는” 충전기다. 그런데 이 보드에는 QCA7005가 있다. ISO 15118(②)을 염두에 둔 설계라는 뜻이다. ②와 ③은 규격이 방대하고 차량·서버와의 호환성 시험이 끝이 없다. 이걸 직접 구현하는 게 프로젝트 최대의 위험이라는 게 출발점이었다.

2. 후보들

후보	언어	형태	특징
EVerest	C++	완성된 충전기 스택	Linux Foundation Energy. IEC 61851, SLAC, ISO 15118-2/-20, OCPP 1.6/2.0.1까지 모듈로 갖춤. Tritium 등 채택 발표 (5절 참고)
Tux-EVSE	Rust + C 프레임워크	완성된 충전기 스택	IoT.bzh. AFB(redpesk) 프레임워크 위의 Rust 바인딩들. SLAC 저장소는 “진행 중, 아마 안 될 것”이라고 경고
hupe1980 `iso15118` / `ocpp-kit`	순수 Rust	프로토콜 부품 세트	Sans-I/O 설계. ISO 15118-2/-20, SLAC 상태 머신, Plug&Charge까지. 프레임워크 의존 없음. 매우 초기 (커밋 10개 남짓, 1.0 이전)
직접 개발	자유	-	①+③ 정도는 가능. ②는 사실상 불가능
상용 스택	-	-	비용, 라이선스

처음에는 “Rust로는 ISO 15118을 직접 구현해야 한다”고 생각했는데, 찾아보니 틀렸다. Rust 구현체가 둘이나 있었다. 특히 hupe1980의 크레이트는 소켓·시계·TLS를 전혀 갖지 않고 호출하는 쪽이 넣어 주는 구조라, 특정 OS나 프레임워크에 묶이지 않는다는 점이 매력적이었다.

흥미로운 건 같은 저자의 백엔드 프로젝트 emob의 README였다. 충전기 쪽 펌웨어로는 EVerest를 전제하고 있었다.

한 부분만 맡는 유명한 것들

“충전기 소프트웨어”로 검색하면 더 많은 이름이 나온다. 다만 대부분은 충전기 전체가 아니라 한 부분을 맡거나 MCU용이다.

분류	이름	특징
충전기 펌웨어 (MCU)	OpenEVSE, SmartEVSE	Arduino/ESP32 홈 충전기. ISO 15118 없음
OCPP 라이브러리	MicroOcpp (C++), mobilityhouse `ocpp` (Python), libocpp (C++)	충전기 쪽 OCPP. MicroOcpp는 가볍고 리눅스에서도 동작
OCPP 관제 서버	SteVe (Java)	충전기 시험용 서버로 유명
ISO 15118	Josev (Python), RISE V2G (Java, 사실상 중단), OpenV2G (C)	15118만
SLAC / PLC	pyPLC (Python), open-plc-utils (C)	pyPLC는 QCA7000 계열 모뎀을 쓰는 취미 프로젝트. open-plc-utils는 이미 쓰고 있다
상용	Vector vSECC, Switch EV, chargebyte, PIONIX	chargebyte와 PIONIX는 EVerest 기반

“리눅스에서 ①~③을 한 번에”라는 조건을 걸면 오픈소스는 EVerest 말고 마땅한 게 없었다.

3. C++이냐 Rust냐

Rust의 장점은 분명하다.

메모리 안전. OCPP와 ISO 15118은 외부에서 데이터가 들어오는 곳이라 파싱 버그가 곧 보안 구멍이다.
툴체인 독립. Rust 컴파일러는 자체 LLVM을 쓰니, 2020년산 SDK의 gcc 9.3과 상관없이 최신 언어 기능을 쓸 수 있다.
동시성 안전. CP 감시, 전력량계, 서버 통신이 동시에 돈다.

그래도 기반으로는 C++(EVerest)을 골랐다. 이유는 언어 자체가 아니다.

프로토콜을 직접 만들지 않는 게 언어보다 중요하다. 검증된 구현이 있는 쪽이 C++이다.
Rust 충전 생태계는 아직 젊다. 후보들이 대부분 1.0 이전이거나 개인 프로젝트다.
팀의 학습 비용. 브링업을 거의 혼자 하는 상황에서 언어 전환까지 얹기는 부담이다.

정리한 구성은 이렇다.

부분	언어
SLAC, ISO 15118, OCPP	EVerest (C++) 그대로
보드 전용 모듈 (CP, ADC, 릴레이, RCD)	C++
안전 기능 (Cortex-M4)	C
Rust	나중에 독립적인 작은 모듈부터 선택적으로

STM32MP157에는 Cortex-M4가 따로 있다. 릴레이 차단이나 CP 이상 감지처럼 늦으면 안 되는 일은 M4가 맡고, 리눅스는 프로토콜과 서버 통신을 맡는 구조가 정석이다. Tux-EVSE도 TI AM62x에 M4 펌웨어를 붙인 같은 구조였다.

4. EVerest는 어떻게 생겼나

기능마다 모듈이 있고, 설정 파일(YAML)로 연결하며, 모듈 사이는 MQTT로 통신한다.

                 ┌────────────── 관제 서버
                 │ OCPP
 ┌───────────────┴────────────────────────────────┐
 │  OCPP 모듈        인증 모듈(RFID)    에너지 관리   │
 │        ╲              │              ╱          │
 │         ╲─────── EvseManager ───────╱           │  ← 충전 흐름의 중심
 │        ╱              │              ╲          │
 │  ISO 15118 모듈    SLAC 모듈       전력량계 모듈   │
 │                       │                         │
 │               ★ 보드 드라이버(BSP) 모듈            │  ← 우리가 만들 부분
 └───────────────────────┼─────────────────────────┘
                         │
     CP PWM · AD_CP · 릴레이 · RCD · QCA7005 · 전력량계

우리가 만들 건 사실상 보드 드라이버 모듈 하나다. 지금까지 한 하드웨어 시험(pwmchip0, iio:device4, DOUT, RCD/EM_INT)이 그대로 그 모듈의 재료가 된다. 헛수고가 없다는 게 마음에 들었다.

5. EVerest, 정말 유명한가

후보를 고르는 동안 나는 EVerest를 “사실상 업계 표준”이라고 불렀다. 확인해 보니 과장이었다.

GitHub 숫자부터 보면 이렇다(2026-10-22 확인).

프로젝트	분류	Stars	Forks
SteVe	OCPP 관제 서버	1.1k	497
mobilityhouse `ocpp`	OCPP 라이브러리	1.0k	398
EVerest `everest-core`	충전기 전체 스택	283	208
OpenEVSE	MCU 펌웨어	199	95

별 수로는 1등이 아니다. OCPP 쪽은 범위가 좁고 쓰는 사람층이 넓어서 별이 많이 붙는다. 충전기 전체를 다루는 프로젝트끼리 놓으면 EVerest가 앞선다. EVerest는 저장소가 여러 개로 나뉘어 있어 everest-core 하나의 숫자는 실제보다 작게 보이기도 한다.

업계 쪽 근거는 이렇다.

근거	내용
소속	LF Energy 공식 프로젝트. 단계는 “Early Adoption”(초기 확산)
Tritium	DC 급속충전기 대형 제조사. PIONIX를 통해 EVerest 기반 소프트웨어 채택 (2026년 5월 발표)
그 밖의 채택	chargebyte, Seeed Studio, Park&Charge/Qwello, Enteligent 등
규모 (PIONIX 주장)	30곳 이상 참여, 2억 1,500만 kWh 이상 충전
최신 릴리스	2026.02

다만 채택 사례 대부분이 EVerest를 주도하는 PIONIX의 발표다. 독립적인 조사는 찾지 못했고, “많은 회사가 비밀유지계약 때문에 사용을 공개하지 않는다”는 언급도 있었다.

그래서 정확한 표현은 이렇다.

표현	맞나
리눅스 충전기 전체 스택 오픈소스 중 가장 알려진 것	✔
대형 제조사도 쓰기 시작한 것	✔ (Tritium)
가장 유명한 충전 관련 오픈소스	✘ OCPP 쪽이 더 널리 쓰임
사실상 업계 표준	✘ 상용 충전기 대부분은 여전히 제조사 자체 펌웨어

판단은 바뀌지 않았다. 필요한 건 별이 많은 프로젝트가 아니라, IEC 61851 + SLAC + ISO 15118 + OCPP를 리눅스에서 한 번에 해결하는 검증된 구현이기 때문이다. 다만 “초기 확산 단계”라 구조가 바뀌기도 한다(2026년 4월에 libocpp가 본 저장소로 합쳐졌다). 쓸 버전을 정하면 한동안 고정하는 게 좋겠다.

6. 그런데 보드에 어떻게 올리지?

여기서 막혔다. EVerest 저장소의 Yocto 레이어 폴더에는 이것만 있다.

everest-core/yocto/
├── kirkstone
├── scarthgap
├── wrynose
└── meta-everest-common

Dunfell이 없다. 그런데 우리 보드는 뭘까. 확인해 봤다.

root@myir:~# cat /etc/os-release
ID="openstlinux-eglfs"
NAME="ST OpenSTLinux - EGLfs - (A Yocto Project Based Distro)"
VERSION="3.1-snapshot-20211108 (dunfell)"
...
root@myir:~# cat /proc/version
Linux version 5.4.31 (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP PREEMPT Tue Nov 2 07:05:34 UTC 2021
root@myir:~# openssl version
OpenSSL 1.1.1f  31 Mar 2020

층	버전	비고
배포판	OpenSTLinux 3.1 (eglfs), 2021-11 빌드	MYiR SDK v3.0
Yocto	3.1 Dunfell	2020년 LTS, 지원 종료
커널	5.4.31, MYiR 사전 빌드 그대로	우리는 DTB와 모듈만 교체해 왔다
U-Boot / TF-A	2020.01 (LTDC 끄기 수정) / 2.2 원본
OpenSSL	1.1.1f	2023년 9월 지원 종료

EVerest는 Kirkstone 이상을 요구하고, 공식 문서는 아니지만 OpenSSL 3.0 이상이 필요하다는 정보도 있다. 지금 BSP는 두 세대 아래다. 그리고 이건 EVerest만의 문제가 아니다. OCPP와 ISO 15118의 TLS를 지원이 끝난 OpenSSL로 한다는 뜻이니, 제품이라면 어차피 올려야 한다.

배포판 이름의 eglfs도 눈에 띄었다. MYiR 평가보드의 Qt 데모용 그래픽 구성이다. 화면 없는 충전기에는 필요 없는 것이 잔뜩 들어 있는 셈이다.

DTS를 고치는 것과 뭐가 다른가

지금까지 DTS는 수십 번 고쳤다. Yocto 버전을 올리는 것도 비슷한 일일까. 전혀 다르다.

┌──────────────────────────────────────────┐
│ 응용 프로그램 (EVerest ...)               │ ┐
│ 라이브러리 (OpenSSL, Boost, systemd ...)  │ │ ← 여기가 안 맞는다
│ glibc · gcc                               │ │
│ 리눅스 커널                               │ │  Yocto 버전이
│   └─ DTS/DTB  ← 지금까지 고쳐 온 곳       │ │  정하는 범위
│ U-Boot · TF-A                             │ ┘
└──────────────────────────────────────────┘

DTS는 커널 안의 한 조각이고, Yocto 버전은 이 그림 전체다. DTS를 아무리 고쳐도 OpenSSL 버전은 바뀌지 않는다.

7. 새 BSP를 찾아서

MYiR: 이 모듈은 5.4가 끝

MYiR의 공식 자료에서 MYC-YA157C(V2, V3)의 BSP는 Linux 5.4.31 / Yocto 3.1이 마지막이다. SDK 릴리스도 2021년 11월 이후 갱신이 없다.

MYiR GitHub에는 2026년 10월까지 갱신되는 새 브랜치가 있었다. 커널 develop_6.6.129, Yocto 레이어 develop_v26.06.10-scarthgap. 그런데 Scarthgap 레이어의 보드 설정에 보이는 건 STM32MP25 보드(myd-ld25x, myd-lf25x)와 ST 공식 보드뿐이었다. YA157C용은 보이지 않았다(목록 일부만 확인했다).

ST: STM32MP15는 최신까지 지원

ST 공식 OpenSTLinux는 계속 STM32MP15를 지원한다.

ST 버전	Yocto	커널
v2.x (지금 우리 기반)	Dunfell	5.4
v4.x	Kirkstone	5.15
v6.x	Scarthgap (LTS, 2028년까지)	6.x

칩은 지원되는데, 우리 모듈이 지원되지 않는 상황이다.

이 모듈만의 사정: PMIC가 없다

MYiR의 2020년 제품 변경 공지에 이런 줄이 있었다.

Using the Discrete devices power circuit to replace the STPMIC

이 모듈은 ST 전원 관리 칩 대신 개별 전원 회로를 쓴다. 어제 ADC가 에러 없이 사라졌던 원인, 즉 MYiR DTS의 buck3가 드라이버 없는 빈 노드였던 것이 바로 이 흔적이었다. 새 BSP로 옮길 때도 ST 기본 설정은 PMIC를 가정하므로, 이 부분이 가장 손이 많이 갈 것이다.

8. 앞으로의 길

1단계: MYiR에 문의한다. YA157C용 Scarthgap BSP 계획이 있는지 묻는다. 없다면 직접 이식하는 데 필요한 자료를 요청한다.

모듈 DDR 설정
PMIC 없는 전원 설계 메모
VREF+/VDDA 연결(어제 ADC 기준전압 문제를 확정하는 데도 쓰인다)

2단계: 없으면 ST v6.x에 직접 이식한다. “처음부터 만드는” 게 아니라 ST가 만든 것 위에 모듈과 보드를 얹는 작업이다.

단계	확인 지점
TF-A + DDR 설정	시리얼에 TF-A 로그, DDR 시험 통과. 가장 어렵다
U-Boot	프롬프트까지
커널 (모듈 DTS)	로그인까지
SC6_0 DTS	QCA7005, ADC, PWM, GPIO. 지금까지의 시험이 그대로 체크리스트
EVerest	시뮬레이션 → 실제 하드웨어

생각보다 위험하지 않은 이유도 있다.

SD 카드 부팅이라 새 BSP는 새 카드에서 시험하면 된다. 안 되면 원래 카드를 꽂으면 끝이다.
가장 어려운 DDR 설정은 동작하는 원본 값이 MYiR 소스에 있다.

BSP를 기다리지 않는 길도 있다. IEC 61851 제어는 직접 짜고, OCPP는 MicroOcpp 같은 가벼운 라이브러리를 쓰는 구성이다. 지금 BSP(OpenSSL 1.1.1)에서도 빌드될 가능성이 높다(확인 필요). 회사 요구가 “일단 IEC 61851 + OCPP”라면 이 길로 먼저 제품을 만들고, ISO 15118은 BSP를 올린 뒤 EVerest로 옮기는 단계적 접근이 가능하다. 다만 그때 충전 제어 코드는 다시 짜야 한다(보드 제어 부분은 재사용). 결국 회사가 ISO 15118을 언제부터 요구하느냐가 두 길을 가른다.

그동안 하드웨어 시험은 계속한다. 워치독, 릴레이, 카드 리더, 보안칩 시험은 어떤 BSP에서든 필요하고, 결과도 그대로 옮겨 간다.

정리

충전기 소프트웨어 후보      → EVerest / Tux-EVSE / hupe1980 / 직접 / 상용
C++ vs Rust                → 언어보다 "프로토콜을 직접 만들지 않는 것"이 중요
EVerest                    → 우리가 만들 건 보드 드라이버 모듈 하나
정말 유명한가               → 전체 스택 오픈소스 중 1위, "업계 표준"은 과장
그런데 Yocto 레이어는        → kirkstone / scarthgap / wrynose (dunfell 없음)
우리 BSP는                  → OpenSTLinux 3.1 dunfell, OpenSSL 1.1.1f
MYiR 새 BSP                → YA157C용은 안 보임 (새 작업은 MP25용)
ST 공식                    → MP15를 Scarthgap까지 지원
다음                       → MYiR 문의 → 없으면 ST v6.x 직접 이식
                             (또는 지금 BSP에서 IEC 61851 + MicroOcpp로 먼저)

소프트웨어를 고르러 갔다가 BSP의 나이를 마주한 하루였다. 하드웨어 브링업을 할 때는 “동작하는가”만 봤는데, 제품 소프트웨어를 얹으려니 “얼마나 오래된 기반 위에 서 있는가”가 보이기 시작했다. 다행히 지금까지 쌓은 DTS와 하드웨어 지식은 새 기반으로 그대로 옮겨 간다.

참고

Twitter Facebook LinkedIn

이 정훈