웹과 앱 결제 화면에서 카드 번호와 유효기간을 자동으로 입력받으려면, 촬영 화면을 직접 제어해야 하는지가 SDK와 API를 가르는 첫 기준입니다. 화면 구성의 자유도와 보안 검토 범위를 함께 따져 보면 선택이 빨라집니다.
이 글은 카드 OCR SDK와 API 연동 방식을 비교하고, 웹·앱을 함께 운영하는 팀이 어떤 순서로 고르면 좋은지 정리합니다.
두 방식의 가장 큰 차이는 촬영과 인식을 누가 맡는가입니다. API는 서비스가 직접 촬영 화면을 만들고 이미지를 서버로 보내 결과를 받습니다. SDK는 촬영 화면과 이미지 전처리를 제공하는 모듈을 앱이나 웹에 넣어 쓰는 방식입니다.

이 차이를 구분하지 않으면 일정과 보안 검토가 자주 꼬입니다. 개발팀은 화면 개발 분량만 보고 방식을 정하는데, 보안팀은 카드 이미지가 어디를 거치는지부터 묻기 때문입니다.
두 질문을 한 번에 정리해 두어야 재검토를 줄일 수 있습니다.
보안 검토에서 가장 먼저 확인할 것은 카드 이미지가 이동하는 경로입니다. 이미지를 서버로 보내는 구조는 전송 구간 암호화, 서버 보관 여부, 로그 마스킹이 검토 대상입니다. 단말에서 처리하는 구조는 이미지가 기기 밖으로 나가지 않는 범위가 어디까지인지 확인해야 합니다.

이 부분은 제품마다 달라서 일반론으로 정할 수 없습니다. 검토 요청서에는 이미지 전송 여부, 보관 기간, 인식 후 즉시 폐기 여부, 결과값만 서비스 서버로 전달되는지를 항목으로 넣어 두는 것이 좋습니다.
이렇게 하면 보안팀이 필요한 답을 한 번에 받을 수 있습니다.
웹과 앱은 같은 서비스여도 처리 환경이 다릅니다. 앱은 네이티브 카메라와 연동되어 초점과 해상도를 세밀하게 다룰 수 있습니다. 웹은 브라우저와 단말 종류에 따라 카메라 권한과 해상도가 달라져 별도 점검이 필요합니다.
결제 화면은 전환율에 직접 영향을 주는 영역이어서 촬영 화면을 얼마나 제어할 수 있는지가 중요합니다. 카드 가이드 틀, 안내 문구, 촬영 후 확인 단계의 배치가 서비스 톤과 맞아야 하기 때문입니다.

결국 빠른 출시가 우선이면 SDK, 결제 화면의 경험을 세밀하게 설계해야 하면 API가 맞는 경우가 많습니다. 두 방식을 섞어 앱은 SDK, 웹은 API로 가는 구성도 가능하므로 환경별로 나눠 판단해도 됩니다.
카드 OCR은 반사, 엠보싱 글자, 어두운 조명 같은 조건 때문에 일부 실패가 생길 수밖에 없습니다.
그래서 인식률 수치만 보지 말고 실패했을 때의 화면 흐름을 먼저 설계해야 합니다. 재촬영 안내와 직접 입력 전환이 자연스러워야 이탈이 줄어듭니다.

도입 일정은 연동 방식보다 검토 절차에 좌우되는 경우가 많습니다. 알체라 기준으로 SaaS 연동 자체는 30분 수준이고, 개발과 테스트를 포함한 전체 도입은 평균 1~3개월입니다. 보안 검토 자료를 먼저 준비하면 이 범위 안에서 일정을 맞추기 쉽습니다.

알체라 eKYC는 카드 검증 기능을 제공하며, SaaS(코스콤 금융 클라우드)와 설치형을 모두 지원합니다. 외부 클라우드 사용이 어려운 금융권이라면 설치형을, 빠른 검증이 필요한 서비스라면 SaaS를 우선 검토할 수 있습니다.
고르는 흐름은 단순하게 정리할 수 있습니다. 먼저 카드 이미지가 거치는 경로에 대한 보안 기준을 정하고, 다음으로 웹과 앱 중 촬영 화면을 직접 만들어야 하는 쪽을 가립니다. 마지막으로 인식 실패 시 수동 입력 전환 기준을 정하면 방식이 자연스럽게 좁혀집니다.
알체라는 고객사 110곳 이상과 계약 연장률 95.5%를 기록하고 있고, 제1금융권 70%가 사용하는 만큼 금융 환경의 검토 절차에도 익숙합니다. 사용 환경과 일정을 알려 주시면 맞는 연동 방식을 함께 정리해 드립니다.
