2026년 1월 20일
충전 테스트를 하려면 지하 주차장으로? -하드웨어 테스트와 협업에 대한 이야기
EV 충전기 시뮬레이터의 성장 이야기
시작은 단순한 문제 해결이었습니다
CSMS(충전소 관리 시스템)를 완전히 새로 만들어야 했습니다. (이전 블로그 참고)
기존 시스템에 구현되어 있던 다양한 기능들, OCPP 표준 위에 얹혀진 우리만의 요구사항들. 이 모든 것을 새 시스템에서도 동작하게 만들어야 했습니다. 그런데...
테스트할 때마다 실제 충전기가 필요했습니다.
충전기를 연결하고, 상태를 확인하고, 메시지를 주고받으며 하나하나 검증하는 과정. 한두 번이야 괜찮지만, 개발 과정에서 이런 테스트가 수십, 수백 번 반복되어야 했습니다. 게다가 개발 환경에서 항상 충전기를 쓸 수 있는 것도 아니었습니다. 특정 에러 상황을 재현하고 싶어도, 하드웨어가 그 상황을 만들어주기를 기다려야 했습니다.
물론 개발자입장에서는 다양한 방법으로 mocking하고 할수 있지만, 이를 함께 커뮤니케이션하는 다양한 역할의 동료들에게는 큰 한계점이었습니다.
자연스럽게 한 가지 생각이 떠올랐습니다.
"가상의 충전기를 만들면 되지 않을까?"
제조사와의 소통에서 느낀 또 다른 문제
개발 과정의 어려움만 있었던 게 아닙니다. 충전기 제조사들과 협업하면서도 비슷한 비효율이 쌓이고 있었습니다.
제조사에서 연락이 옵니다. "이런 상황에서는 충전기가 이렇게 동작해야되는게 맞을까요?", "이런 상황에서는 이렇게 처리해도 될까요?"
답변하려면 상황을 파악해야 하고, 로그를 분석해야 하고, 필요하면 직접 테스트해서 재현해봐야 합니다. 단순한 질문 하나에도 꽤 많은 시간이 들어갑니다. 그리고 이런 연락은 수시로 옵니다. 개발에 집중하고 있는데 연락이 오면, 흐름이 끊깁니다.
연동 규격서라는 문서가 있긴 합니다. 하지만 문서는 해석의 여지를 남깁니다. "이 상황에서 이렇게 해야 한다"고 써있어도, 각자의 이해가 조금씩 달라서 같은 내용을 반복해서 설명하게 됩니다.
여러 제조사에 동일한 설명을 다양한 방식으로 해야 합니다. 이는 시간과 비용이 많이 들었습니다.
좀 더 효과적으로 이런 문의를 줄이고 연동 및 제작을 지원할 수 없나?
레퍼런스의 부재
이런 비효율을 해소하기 위해 제조사 지원 도구를 만들었습니다. 이 도구를 통해 제조사는 CSMS 서버 쪽의 동작을 직접 확인할 수 있게 되었고, 서버 관련 문의는 많이 줄어들었습니다.
하지만 결정적인 한계가 있었습니다.
"정상적인 충전기는 어떻게 동작해야 하는지"에 대한 기준이 없었습니다.
서버가 어떻게 응답하는지는 볼 수 있지만, 그 응답을 받은 충전기가 어떻게 행동해야 하는지에 대한 레퍼런스가 없었던 것입니다. 연동 규격서에 글로 써있긴 하지만, 실제로 동작하는 예제가 없으니 늘 "이게 맞나요?"라는 질문이 오갔습니다.
제조사에 레퍼런스 충전기를 제공할 수 있으면 이는 해결될것 같습니다. 다만 그것 또한 만만치 않은 일입니다. 우리 회사는 제조사가 아니기 때문이죠. 그럼 가상의 충전기를 만들어서 제공할 수 있지 않을까? 연동 규격서에 써있는 내용을 실제로 동작하는 충전기 형태로 보여줄 수 있으니까요.
현재 시뮬레이터의 기능
현재 시뮬레이터는 아래와 같은 기능으로, 구현되어 있습니다.
- OCPP 1.6기반에서 볼트업 연동규격서를 준수한 스펙. (OCPP 2.1 준비중)
- 볼트업 CSMS 개발환경에 등록된 충전기로서 온전히 실물 충전기처럼 동작.
- 누구나 시뮬레이터 사이트에서, CSMS에 등록된 충전기를 시뮬레이터를 통해 연결하고, 조작하고, 실물충전기처럼 테스트 가능.
- 통합테스트툴에서 충전기 조작이 필요한 상황에 대해 실물충전기를 대체하여 테스트시나리오상에서 유기적으로 활용.
- AI를 통한 통합테스트 시나리오 작성 및 시뮬레이터 코드 작업.
시뮬레이터의 진화
시뮬레이터는 한 번에 완성되지 않았습니다. 필요에 따라 조금씩 확장되면서 진화했습니다.
Phase 1: CSMS 테스트 도구
처음 목표는 단순했습니다. 새로 만드는 CSMS 서버가 OCPP 프로토콜을 제대로 처리하는지 확인하는 것이었습니다.
가상의 충전기가 OCPP 메시지를 보내고, 서버의 응답을 검증합니다. 부팅, 상태 변경, 충전 시작과 종료, 에러 상황까지 다양한 시나리오를 코드로 정의해서 테스트할 수 있게 되었습니다.
덕분에 실제 충전기 없이도 개발을 진행할 수 있었고, 현실에서 재현하기 어려운 엣지 케이스들도 마음껏 테스트할 수 있었습니다.
Phase 2: 앱 통합 테스트
CSMS가 어느 정도 안정되자, 다음 과제가 생겼습니다. 모바일 앱과 CSMS, 충전기가 연동되는 전체 흐름을 테스트해야 했습니다.
앱에서 원격 충전을 시작하면, 그 명령이 CSMS를 거쳐 충전기까지 전달됩니다. 충전이 시작되면 충전량이 올라오면서 앱의 충전 중 화면이 변합니다. 요금이 적용되는 과정, 원격으로 충전을 종료했을 때 충전 완료 상태로 넘어가는 과정. 이런 것들은 실제 충전 상황에서만 확인할 수 있었습니다.
시뮬레이터가 가상 충전기 역할을 해주면서, 이 모든 흐름을 충전기 없이 테스트할 수 있게 되었습니다. 앱 개발팀과 백엔드 팀이 서로를 기다릴 필요 없이 독립적으로 개발하고 테스트할 수 있게 되었습니다.
Phase 3: 충전기 검증 도구 (역할의 전환)
여기서 재미있는 변화가 생겼습니다.
지금까지 시뮬레이터는 충전기 역할을 했습니다. CSMS를 테스트하기 위해 가상의 충전기가 되어주었습니다.
그런데 Phase 3에서는 새로운 도구가 만들어졌습니다. 통합 테스트 도구입니다. 이 도구는 시뮬레이터에서 축적된 테스트 시나리오를 활용해서, 이번에는 실제 충전기를 테스트합니다. 충전기를 연결하고, 미리 정의된 시나리오에 따라 충전기가 올바르게 동작하는지 검증하는 것입니다.
이 기능은 곧 실무에 투입될 예정입니다. 새로 납품된 충전기를 확인하는 입고 검수, 현장에 설치된 충전기를 확인하는 준공 검사. 각 단계에 맞는 테스트 목록들을 실행하고 검증하는 데 활용하기를 기대하며, 현재 적용을 준비하고 있습니다. 이는 각 실행하는 환경이나 상황에 따라 테스트 결과가 오차가 생기는것을 방지하고, 명확하게 테스트 결과를 리포팅 받을수 있게 됩니다.
Phase 4: 고도화 과제
이후엔 이렇게 만들어진 각각의 도구들을 실질적인 환경에서 더 나은 시스템이 될 수 있게, 고도화 하고 정착하는 미션이 진행 될 예정입니다.
시뮬레이터가 바꾼 것들
신규 기능 개발 프로세스의 변화
시뮬레이터가 있음으로 해서 가장 효과를 봤던 또다른 과정은 신규 기능 개발 방식입니다.
새로운 기능을 실험하고 추가하려면 제조사나 하드웨어 제작이 없이는 쉽지 않은 부분들이 많습니다. 어떤 하드웨어가 어떤 부분이 가능한지, 무엇이 제약인지, 우리는 어떻게 프로토콜을 정의하는게 좋을지등을 선행기술을 검토하는 단계에서는 이를 같이 협업하기란 서로 아주 어려운 부분입니다.
지금은 다릅니다.
- 아이디어가 떠오르면, 시뮬레이터에서 먼저 실험합니다.
- 시뮬레이터 상에서 기능을 검증하고 완성합니다.
- 검증이 끝나면 CSMS에 반영합니다.
- 연동 규격서에 스펙을 추가합니다.
- 제조사에 완성된 스펙과 동작하는 레퍼런스를 함께 제공합니다.
이 프로세스 덕분에 설계 난이도가 낮아지고, 실험 비용이 줄어들었습니다. 수정-테스트 사이클이 파트너사 커뮤니케이션, 피드백, 반영에 따른 시간이 사안에 따라 다르겠지만, 신규 기능 실험같은 경우 최소 1주에서 길게는 1달까지 걸리던 시간이 내부적으로 짧게는 1일에서 길게는 1주 이내로 단축되었습니다.
실제로 이렇게 개발한 기능들
이 프로세스를 통해 몇 가지 선행 기술을 개발하고 검증했습니다.
지금은 모두 공유할순 없지만, 신규플랫폼 런칭전에, 서비스적인 차별화를 위해 시도 했던 3~4가지의 선행기술들을 모두 이 시뮬레이터를 통해 실험/검증 했었고, 그 중 일부는 앞으로 하나씩 실제 반영되어 공개될 준비를 하고 있습니다.
이 기능들은 모두 실제 충전기 하드웨어 없이 시뮬레이터에서 먼저 프로토타입을 만들고 검증했습니다. 일부는 이미 실제 서비스에 반영되어 제조사에 제공되었고, 일부는 아직 기술 검증 단계에 있습니다.
앞으로도 충전기를 통해 제공될 새로운 기술/기능이나 새로운 표준에 대해서도 이를 활용해 진행할 예정입니다.
향후 시뮬레이터를 통해 기대하는 가치
시뮬레이터가 제조사에 제대로 제공되면, 협업 방식이 근본적으로 달라질 것으로 기대합니다.
재현 가능한 시나리오: "저희 충전기에서 이상해요"라는 모호한 버그 리포트 대신, "시뮬레이터의 이 시나리오와 비교했을 때 여기서 다릅니다"라는 구체적인 근거로 소통할 수 있습니다.
규격서의 실행 가능한 버전: 문서는 해석의 여지를 남깁니다. 시뮬레이터는 "이렇게 동작해야 한다"를 직접 보여주는 살아있는 예제입니다. 코드가 곧 스펙입니다.
셀프 서비스 검증: 제조사가 새 펌웨어 배포 전이나 시스템 변경 시 스스로 호환성을 테스트할 수 있습니다. 양쪽 모두의 지원 비용이 줄어듭니다.
말 그대로, 현실적으로 제공하기 힘든 실물 레퍼런스 충전기를 완전히 대체하는 가상의 레퍼런스 충전기인 것입니다.
AI와 함께한 개발 이야기
시뮬레이터 이야기에서 빠뜨릴 수 없는 부분이 있습니다. 바로 AI를 활용한 개발 경험입니다.
초기 시뮬레이터는 Spring + Kotlin 기반으로 일반적인 방식으로 개발했습니다. 모든 OCPP 스펙을 개발자가 직접 하나하나 구현해야 했고, 그만큼 시간과 비용이 많이 들었습니다.
그런데 최근 버전은 완전히 다른 방식으로 개발되었습니다.
순수하게 AI를 활용해서, 작업일 기준 단 5일 만에 핵심 기능을 완성했습니다.
시뮬레이터는 AI로 만들기에 더 없이 좋은 소재입니다. OCPP라는 표준 스펙이 정해져있고, AI는 이에 대해 이미 꽤 잘 알고 있는 상태이며, 표준스펙 문서도 제공할수 있기 때문이죠. 이에 몇가지 추가적인 요구사항을 담아, 설계부터 전체 구현까지 단 5일만에 완성되고, 이를 실사용을 위한 몇가지 세팅을 하는데 하루 이틀 더 쓴 것 같네요.
통합 테스트 도구, 로컬 시뮬레이터, 원격 시뮬레이터까지. 기존 방식으로는 몇 주, 어쩌면 몇 달이 걸렸을 작업입니다.
이미 많은 분들이 AI를 활용해서 다양한 것들을 잘 만들어내고 계실 것입니다. 저희의 경험이 특별하다고 생각하지는 않지만, 기회가 된다면 구체적인 과정을 공유해볼 예정입니다. AI를 이용해 작업을 하는 과정에서, 현재수준에서의 한계와 그걸 잘 활용하는 방법 또한 많은 경험을 쌓고 있는 중입니다.
앞으로의 방향
시뮬레이터는 계속 발전할 예정입니다.
- CI/CD 통합: 코드가 변경될 때마다 자동으로 시뮬레이터 테스트가 돌아가도록 합니다. 리그레션을 방지합니다.
- 더 많은 시나리오: 에러 상황, 타임아웃, 다중 커넥터 동시 충전 등 더 다양한 케이스를 커버합니다.
- 파트너 포털 통합: 제조사가 웹에서 직접 테스트를 실행하고, 결과 리포트를 받을 수 있도록 합니다.
마치며
시뮬레이터는 처음에는 단순한 테스트 도구였습니다.
"실제 충전기 없이 어떻게 테스트할까?"라는 현실적인 문제를 해결하려고 만들기 시작했습니다.
그런데 시간이 지나면서 그 이상의 가치를 보여주었습니다.
- 개발 도구에서 → 통합 테스트 플랫폼으로
- 내부 용도에서 → 파트너 협업 도구로
- 현재 기능 검증에서 → 미래 기능 선행 개발의 기반으로
충전 인프라 사업에서 소프트웨어와 하드웨어의 경계를 넘나드는 일은 항상 도전적입니다. 시뮬레이터는 그 간극을 메우고, 더 빠른 혁신을 가능하게 하는 다리 역할을 하고 있습니다.
특히 AI를 활용해서 단 5일 만에 새로운 버전을 완성한 경험은, 앞으로 이런 도구들이 더욱 빠르고 효율적으로 만들어질 수 있다는 가능성을 보여줍니다.
다음에는 시뮬레이터를 만들었던 AI활용 경험과 소감을 공유해 보도록 하겠습니다. 아, 그 사이 이미 AI활용법에 대해서는 수 많은 변화가 또 진행되었을지도 모르겠네요.
