📋 목차
충전기 스펙표를 보다 보면 OCPP 지원이라는 문구가 꼭 있더라고요. 문제는 그 한 줄이 실제 운영에서 체감 차이를 크게 만든다는 거예요. 같은 출력, 같은 커넥터인데도 어떤 충전기는 관제에 바로 붙고 어떤 건 며칠을 잡아먹어요. 숫자 하나로 말하면, 설치 이후 첫 달에 원격 장애 처리가 안 돼서 현장 출동이 2배 가까이 늘어난 적도 있었어요.
OCPP는 충전기와 운영 서버가 주고받는 언어예요. 충전 시작과 정지, 이용자 인증, 상태 보고, 장애 코드 같은 운영의 뼈대가 여기로 흐르죠. 그래서 “OCPP 지원”은 단순 체크박스가 아니라, 어떤 버전을 어떤 방식으로 구현했는지까지 봐야 진짜 의미가 생겨요. 솔직히 여기서 한 번 삐끗하면, 충전기는 돌아가는데 서비스는 멈춘 상태가 되기 쉬워요.
OCPP 지원이란 말, 어디까지를 말하는 걸까요
OCPP 지원이라고 적혀 있어도 범위가 제각각이더라고요. 충전기 본체가 OCPP로 서버에 붙는 것만 말하는 경우가 있고, 충전기를 관리하는 관제 시스템이 OCPP를 이해한다는 뜻으로 쓰이기도 해요. 더 헷갈리는 지점은 버전이에요. OCPP 1.6, 1.6J, 2.0.1, 2.1처럼 숫자가 달라지고, 같은 버전 안에서도 보안 프로필이나 선택 기능이 달라져요. Open Charge Alliance 쪽 다운로드 안내를 보면 OCPP 1.6, 2.0.1, 2.1 자료가 따로 제공돼요.
실무에서 “OCPP 지원”을 확인할 때는 질문을 두 개로 쪼개면 속이 편해요. 첫째, 충전기와 서버가 연결되는 전송 방식이 뭐냐는 거예요. OCPP 1.6은 SOAP이나 JSON이 언급되는데, 현장에선 JSON over WebSocket을 가리켜 1.6J라고 부르는 흐름이 굳어져 있어요. ABB 충전기 구현 문서도 1.6-J를 JSON over WebSocket으로 설명하고 있더라고요. 둘째, 서버가 받은 메시지를 운영 업무에 쓸 수 있느냐예요. 상태만 들어오고 원격 시작이 안 되면, 지원이라고 부르기 애매해져요.
OCPP 지원 문구를 실무 언어로 바꿔보면
| 스펙표 문구 | 현장에서 확인해야 할 내용 | 안 맞으면 생기는 일 |
| OCPP 1.6 지원 | 1.6J인지, SOAP인지, 서버가 어떤 바인딩을 받는지 | 연결 자체가 안 됨, 붙었다가 끊김 반복 |
| OCPP 2.0.1 지원 | CSMS도 2.0.1을 실제 운영으로 받는지 | 충전기만 2.0.1, 서버는 1.6이라 호환 불가 |
| 보안 통신 지원 | TLS 적용 여부, 인증서 운영 방식, 시간 동기화 | 특정 날부터 접속 불가, 인증서 만료 이슈 |
| 원격제어/관제 연동 | RemoteStart/Stop, 진단, 펌웨어, 알람 처리 범위 | 장애가 나도 현장 출동만 남음 |
아, 그리고 OCPP는 “충전기와 운영 서버” 구간 얘기예요. 로밍이나 타사 결제 연동은 보통 OCPI 같은 다른 프로토콜이 얹히는 경우가 많아요. 그래서 OCPP가 정상이어도 결제가 꼬이면 이용자 입장에선 충전이 안 되는 것처럼 느껴지죠. 그 순간이 진짜 충격이에요.
국내에선 왜 OCPP 1.6 얘기가 유독 많아요
국내에서 OCPP 1.6이 자주 언급되는 건, 보조금과 발주 조건에서 표준 준수를 요구하는 흐름이 생겼기 때문이에요. 국가기술표준원 보도자료를 보면 2022년 말에 충전스테이션 관리 시스템 관련 KS 고시에서 공통 통신방식으로 OCPP를 활용할 수 있게 했다고 설명해요. 이건 제조사나 사업자가 제각각 쓰던 방식을 한 방향으로 모으려는 신호로 읽혀요. 실제 조달 문서에서도 OCA가 만든 OCPP 1.6 이상 공인인증 완료 같은 요구가 들어가 있더라고요.
환경부 사업 쪽에서는 OCPP 1.6 인증을 사실상 필수 조건처럼 보는 시장 분위기가 굳어졌다는 보도도 계속 나와요. 2023년 이후 OCPP 1.6 인증 의무화가 언급되는 국내 기사들이 있고, 2026년에도 OCPP 1.6 CSMS 인증을 받았다는 소식이 이어져요. 이런 흐름 때문에 충전기 구매나 관제 시스템 구축에서 1.6을 기본선으로 보는 곳이 많아졌어요. 근데 글쎄요, 1.6이면 끝이라고 생각하면 여기서부터 함정이 시작돼요.
국내에서 많이 쓰는 OCPP 요구 조건을 숫자로 정리
| 구분 | 자주 등장하는 기준 | 체감 포인트 |
| 국가 표준 흐름 | 2022년 KS 고시에서 OCPP 활용 기반 언급 | 제조사-사업자 혼선 줄이려는 방향 |
| 발주/조달 조건 | OCPP 1.6 이상, OCA 공인인증 요구 문구 등장 | 서류로 끝내면 현장에서 삐끗 |
| 운영사 실무 | 1.6J JSON over WebSocket 구성 선호 | 서버가 SOAP만 받으면 바로 막힘 |
| 고도화 방향 | 2.0.1 인증/도입 소식 증가 | 보안, 장치관리, 스마트 충전 요구가 커짐 |
여기서 질문 하나. 충전기만 OCPP 1.6을 지원하면 충분할까요? 운영 서버, 결제, 로밍까지 끼면 얘기가 달라져요. 그래서 “국내 기준은 1.6이니까 무조건 1.6”처럼 단순화하면, 나중에 교체 비용이 커질 수 있어요.
1.6J와 2.0.1, 뭐가 달라서 이렇게 갈리나요
OCPP 1.6은 오래 쓰인 만큼 생태계가 넓어요. 특히 1.6J는 JSON over WebSocket 조합으로 굴러가는 경우가 많고, 충전기 제조사 문서에서도 그 형태를 전제로 설명하는 사례가 보이죠. 그래서 빠르게 구축할 때는 1.6J가 마음 편한 선택이 될 때가 있어요. 근데 보안이나 장치 관리, 스마트 충전 같은 요구가 늘면 2.0.1 이야기가 나오기 시작해요. ABB의 백서에서도 업계가 1.6J에서 2.0.1로 전환을 시작한다고 언급하면서, 버전 간 호환이 쉽지 않다는 점을 같이 짚더라고요.
2.0.1은 보안과 기능이 강화된 방향으로 알려져 있어요. 국내에서도 2025년 말에 OCPP 2.0.1 인증 취득 소식이 나오고, 강화된 보안 통신 환경이나 플러그앤차지 같은 고도화 언급이 따라붙어요. Open Charge Alliance 쪽에서는 2.0.1 인증서들이 꾸준히 발급되고, 2026년에도 2.0.1 인증서 PDF가 올라와 있어요. 그러니까 시장이 2.0.1로 슬금슬금 옮겨가는 느낌이 나요.
버전 선택이 막막하면 이렇게 생각하면 편해요. 이미 운영 중인 관제 서버가 1.6J 중심이면 1.6J로 안정화가 먼저예요. 신규 구축이고 장기 운영, 보안 감사를 염두에 둔다면 2.0.1을 검토할 가치가 커져요. 급하게 결정하면, 나중에 충전기 교체보다 서버 교체가 더 비싸게 나올 때가 있거든요.
1.6J vs 2.0.1, 운영에서 체감되는 차이만 뽑아보기
| 항목 | OCPP 1.6J | OCPP 2.0.1 |
| 전송 방식 | JSON over WebSocket 형태가 널리 쓰임 | WebSocket 기반 운용 전제 사례가 많음 |
| 도입 난이도 | 레거시 CPMS와 붙이기 쉬운 편 | 서버, 인증체계까지 같이 설계하는 편이 안전 |
| 보안 체감 | TLS 구성은 가능, 운영 품질은 구현에 달림 | 보안 요구가 커진 시장에서 선택 이유가 생김 |
| 미래 확장 | 이미 깔린 기반이 크다는 장점 | 스마트 충전, 장치 모델링 같은 방향과 맞음 |
표만 보면 2.0.1이 무조건 좋아 보이죠. 근데 운영 서버가 1.6만 받는 구조면 2.0.1 충전기를 들여와도 바로는 못 써요. 이게 제일 흔한 함정이에요. “충전기는 최신으로 샀는데 서버가 못 받는다”는 상황, 생각보다 자주 벌어져요.
인증서가 있으면 다 되는 줄 알았어요
OCPP 인증서가 있으면 마음이 놓이긴 해요. Open Charge Alliance에서 발급하는 인증서에는 대상이 충전기 쪽인지, CSMS 쪽인지가 나뉘고, 코어와 어드밴스드 같은 범주가 적히는 형태가 보여요. 국내 기사에서도 OCPP 1.6 CSMS Full 같은 표현으로 인증을 받았다는 소식이 나오고요. 근데 인증서는 “표준에 맞게 구현했다”에 가깝지, “우리 서버와 100% 호환”을 보장하진 않아요. 선택 기능이 많아서 그래요.
그래서 인증서가 있어도 현장 테스트가 꼭 필요해요. 예를 들어 서버가 요구하는 부가 필드, 특정 상태 코드 해석, 재접속 정책, 시간 동기화 방식이 다르면 운영이 삐걱거려요. 충전기 구현 문서들에서도 충전기가 기본적으로 특정 서버에 붙도록 되어 있고, 외부 OCPP 서버로 연결 가능하다고 설명하는 경우가 있어요. 이 말은 곧, 실제 연결 설정과 운영 정책이 중요하다는 뜻이에요. 어차피 관제는 기술보다 운영 습관이 더 크게 작동하거든요.
인증서만 믿고 발주하면 위험해요. 발주 문서에 OCPP 1.6 이상 공인인증 같은 문구가 있어도, 실제 구축에선 1.6J인지 1.6 SOAP인지부터 엇갈릴 수 있어요. 그 상태로 장비가 들어오면, 일정은 지키는데 운영은 망가지는 그림이 나와요.
OCPP 호환을 좌우하는 현실 체크 포인트
| 체크 포인트 | 권장 확인 방식 | 숫자로 잡히는 기준 예시 |
| 전송 바인딩 | 서버가 WebSocket JSON을 받는지 먼저 확인 | 운영망에서 443 포트 WSS 허용 여부 |
| 재접속 정책 | 회선 불안정 상황에서 재연결 로그 확인 | 재시도 간격 30초, 60초, 300초로 비교 테스트 |
| 시간 동기화 | TLS 적용 시 NTP 설정 여부 확인 | 시간 오차 5분만 나도 인증서 검증이 흔들릴 수 있음 |
| 원격 기능 범위 | RemoteStart/Stop, 펌웨어, 진단 항목 목록화 | 필수 10개 기능, 선택 10개 기능으로 구분해 계약서에 박기 |
여기서 숫자는 절대값이 아니라 운영 기준을 만들기 위한 도구예요. 예를 들어 재시도 간격을 30초로 잡을지 300초로 잡을지에 따라, 장애 때 서버 부하랑 현장 체감이 달라져요. 이런 걸 미리 정해두면, 장애 대응이 훨씬 덜 흔들려요.
현장에선 OCPP가 붙는데 결제가 안 됐어요
한 번은 충전기 설치 후 관제 화면에 상태가 잘 올라오는 걸 보고 안심했어요. OCPP 연결이 안정적으로 유지되고, 하트비트도 정상이라서 “이제 끝났다” 싶었죠. 근데 막상 이용자가 결제하고 충전을 누르니 시작이 안 되는 거예요. 그 순간 머리가 하얘졌어요. 소름이 쫙 돋고, ‘내가 뭘 놓쳤지’라는 생각만 맴돌더라고요.
원인은 OCPP가 아니라 인증과 결제 흐름이 얹히는 부분이었어요. 충전기는 서버와 대화는 하는데, 결제 시스템에서 내려오는 승인 토큰을 서버가 OCPP 트랜잭션에 제대로 매핑하지 못했거든요. 로그를 쪼개서 보니 서버는 RemoteStart 요청을 보냈다고 생각했는데, 충전기는 “권한 없음” 쪽으로 떨어지고 있었어요. 그날 이후로는 OCPP만 붙었다고 퇴근하지 않아요, 실제 결제부터 충전 종료 정산까지 한 사이클을 꼭 돌려요.
이 경험 이후로 깨달은 게 있어요. 이용자는 OCPP가 뭔지 몰라요. 결제하고 충전이 되느냐만 보죠. 그래서 운영 목표는 “표준 준수”가 아니라 “실사용 시나리오 완주”로 잡는 게 맞더라고요. 혹시 충전기는 살아 있는데 서비스가 죽어 있는 느낌, 겪어본 적 있어요?
도입 전에 이것만 확인해도 시행착오가 줄어요
OCPP 지원 충전기를 도입할 때 제일 먼저 할 일은 버전 매칭이에요. 충전기, 관제 서버, 로밍 연동, 결제 연동까지 각각의 버전을 적어놓고 서로 맞는지 보는 거죠. 그다음은 보안과 네트워크예요. 현장에선 WebSocket을 쓰는 구성이 많다 보니, 방화벽에서 443만 열면 될 것 같아도 인증서나 프록시 정책 때문에 끊기는 일이 생겨요. 그래서 설치 전에 네트워크 담당자랑 포트, 인증서, 시간 동기화까지 한 장으로 정리해두면 편해요.
돈 얘기도 해볼게요. 현장 출동 한 번이 5만원만 잡아도, 한 달에 20번이면 100만원이 나가요. OCPP 원격 진단과 원격 재설정이 제대로 되면, 이 비용이 눈에 띄게 줄어들 수 있어요. 그래서 계약 단계에서 원격 기능 범위를 박아두는 게 진짜 중요해요. 특히 발주 문서에서 OCPP 인증을 요구하는 흐름이 있는 만큼, 인증서 유무 말고 운영 기능까지 계약 조건으로 끌고 들어오는 게 안전해요.
긴급하게 한 줄로 정리하면 이거예요. 충전기 구매 전, 우리 서버가 받는 OCPP 버전과 바인딩을 먼저 확정해요. 그 다음 납품 업체에게 실제 연결 테스트 로그를 요구해요. 문서로는 다 된다고 해도, 현장에서 안 붙으면 답이 없거든요.
지금 당장 할 수 있는 실전 체크리스트도 남겨둘게요. 충전기 쪽은 OCPP 버전, 1.6J 여부, 인증서 갱신 방식, 장애 코드 목록을 받고요. 서버 쪽은 허용 메시지 범위, 원격 시작과 정지 정책, 재접속 정책을 확인해요. 마지막으로 현장 회선에서 WSS 접속이 안정적인지, 시간 동기화가 잡히는지까지 보면 큰 사고는 줄어요. 급하면 오늘 바로 점검할 수 있어요.
FAQ
Q. OCPP 지원 충전기라면 어떤 관제 서버에도 바로 붙나요?
A. 같은 OCPP라도 버전과 전송 바인딩이 다르면 바로 붙지 않을 수 있어요. 1.6과 1.6J, 2.0.1처럼 숫자와 구현 방식을 먼저 맞춰야 해요.
Q. OCPP 1.6J에서 J는 정확히 뭐예요?
A. 핵심은 JSON over WebSocket 바인딩을 뜻하는 표현으로 많이 쓰여요. 제조사 구현 문서에서도 1.6-J를 그런 형태로 설명하는 사례가 보여요.
Q. 국내에선 왜 OCPP 1.6 인증 이야기가 계속 나오나요?
A. 2022년 국가기술표준원 보도자료에서 충전기 통신방식으로 OCPP 활용을 언급했고, 발주 문서에서도 OCPP 1.6 이상 공인인증 요구가 보이는 흐름이 있어요. 그래서 현장 기본선이 1.6으로 잡히는 경우가 많아요.
Q. OCPP 2.0.1은 뭐가 좋아서 다들 얘기하나요?
A. 업계 백서들에서 1.6J에서 2.0.1로 전환 흐름을 언급하면서 보안과 기능 고도화를 같이 말해요. 국내에서도 2.0.1 인증 취득과 강화된 보안 통신 환경을 강조하는 사례가 나와요.
Q. OCPP 인증서가 있으면 호환 문제는 끝난 건가요?
A. 인증서는 표준 준수의 근거가 되지만, 서버마다 선택 기능과 운영 정책이 달라 현장 테스트가 필요해요. 특히 원격 시작과 결제 연동은 실제 시나리오로 검증하는 게 안전해요.
Q. OCPP가 정상인데도 결제가 안 되는 일이 생기나요?
A. 생겨요, OCPP는 충전기와 관제 서버 구간이고 결제나 로밍은 다른 연동이 얹히는 구조가 많아요. 그래서 OCPP 접속이 멀쩡해도 인증 토큰 매핑이나 결제 승인 흐름에서 막힐 수 있어요.
Q. 신규 구축이면 1.6J와 2.0.1 중 뭘로 가는 게 나아요?
A. 기존 운영 서버와 연동이 최우선이면 1.6J가 현실적인 선택이 될 때가 많아요. 장기 운영과 보안 요구를 강하게 잡는다면 2.0.1을 서버까지 포함해 설계하는 편이 덜 흔들려요.
Q. 운영 중인 충전소에서 OCPP 문제를 빠르게 찾는 방법이 있나요?
A. 첫 문장은 이거예요, 연결 끊김 시간대와 재접속 로그부터 모으는 게 제일 빨라요. 그 다음 WSS 통과 여부, 인증서 만료, 시간 동기화 순으로 보면 원인이 잘 잡혀요.
Q. 발주 문서에서 OCPP 인증 요구가 있으면 무엇을 추가로 적어야 할까요?
A. 버전만 적지 말고 1.6J 여부, 보안 통신 적용 범위, 원격 기능 목록을 같이 적는 게 좋아요. 그래야 납품 후에 “지원은 하는데 우리 운영과는 다르다”는 말이 줄어요.