계좌조회 API 비용은 대부분 호출 건당 과금 구조로 정해지며, 어떤 방식으로 조회하는지, 한 달에 몇 건을 호출하는지, 다른 인증을 함께 쓰는지에 따라 달라집니다. 같은 서비스라도 연동을 어떻게 설계하느냐에 따라 호출 건수가 달라지기 때문에, 단가만 비교하기보다 우리 서비스에서 실제로 몇 건이 호출될지를 먼저 계산하는 것이 중요합니다. 이 글에서는 금액 대신 비용이 달라지는 항목과 호출 건수를 줄이는 구성을 정리합니다.
계좌조회 API는 어떤 과금 구조가 많나요?
계좌조회 API의 과금 구조는 제공사마다 다르지만, 보통 다음 세 가지 중 하나이거나 이를 섞은 형태입니다.
건당 과금: 호출한 건수만큼 비용을 냅니다. 사용량이 일정하지 않은 서비스에서 예산을 맞추기 쉽습니다.
기본 사용량 + 초과 과금: 월 기본 사용량까지는 정해진 비용을 내고, 넘는 건수만큼 추가로 냅니다. 사용량이 꾸준한 서비스에 맞습니다.
구간별 단가: 월 호출 건수가 많아질수록 건당 단가가 낮아지는 구조입니다. 가입자가 빠르게 늘어나는 서비스라면 구간 기준을 미리 확인합니다.
과금 구조를 비교할 때는 실패한 호출도 과금되는지, 테스트 환경 호출은 과금되지 않는지, 최소 사용량 조건이 있는지를 함께 확인해야 실제 비용을 예측할 수 있습니다.
조회 방식에 따라 비용이 어떻게 달라지나요?
계좌조회 API는 확인하는 범위에 따라 처리 과정이 달라서, 조회 방식별로 비용 구조도 달라질 수 있습니다.
예금주 확인: 계좌의 예금주 이름만 확인합니다. 처리 과정이 단순한 편입니다.
실명 조회: 계좌 명의가 고객 실명 정보와 일치하는지 확인합니다.
1원 인증: 고객 계좌로 실제로 1원을 보내고 인증 코드를 확인하는 과정이 포함됩니다. 송금과 코드 확인이 함께 이뤄지는 만큼, 명의 확인만 하는 방식과 비용 구조를 따로 확인해야 합니다.
잔액·거래내역 조회: 고객 동의를 받아 오픈뱅킹 등으로 정보를 가져오는 별도 API입니다. 알체라 eKYC가 제공하는 기능은 아닙니다.
고객 계좌가 본인 것인지 확인해야 하는 서비스라면 1원 인증이 필요하고, 이때 비용을 줄이는 핵심은 1원 인증을 꼭 필요한 계좌에만 호출하는 것입니다. 알체라 eKYC는 1원 인증을 API로 제공하며 호출 건당 과금 방식으로 운영됩니다. 구체적인 금액은 확인 범위와 예상 건수에 따라 안내하고 있으며, 알체라 eKYC는 고객사 110곳, 누적 1,430만 회 인증, 제1금융권 70%가 사용하고 있습니다.
월 호출 건수는 어떻게 계산하나요?
계좌조회 API 비용을 예측하려면 월 호출 건수를 다음 순서로 계산합니다.
신규 등록 건수: 한 달 동안 계좌를 처음 등록하는 고객 수를 잡습니다.
계좌 변경 건수: 기존 고객이 계좌를 바꾸는 건수를 더합니다. 계좌 변경 때 다시 확인하도록 설계했다면 반드시 포함합니다.
실패 후 재시도 건수: 인증 코드 시간 초과나 입력 오류로 다시 보내기를 하는 비율을 곱해 더합니다.
명의 확인 단계 건수: 1원 인증 전에 명의 대조를 먼저 한다면, 명의 대조는 모든 계좌에, 1원 인증은 명의가 같은 계좌에만 호출된다는 점을 반영합니다.
이렇게 계산하면 "가입자 수 = 호출 건수"로 단순하게 잡았을 때보다 실제에 가까운 값을 얻을 수 있습니다.
추가 인증과 부가 항목은 비용에 어떤 영향을 주나요?
계좌 확인만 하는지, 다른 확인 단계와 묶는지에 따라 전체 비용이 달라집니다.
다른 인증과의 결합: 계좌 확인 앞뒤로 고객 신원 확인 같은 단계를 함께 쓰면, 단계별 호출 건수를 각각 계산해야 합니다.
적용 단계 수: 가입, 계좌 변경, 출금 전 확인처럼 계좌 확인을 붙이는 단계가 많을수록 호출 건수가 늘어납니다.
결과 보관과 관리 화면: 확인 이력을 조회하는 관리 화면이나 결과 보관 기능이 별도 항목인지 확인합니다.
기술 지원 범위: 장애 대응 시간이나 전담 지원이 기본 범위에 포함되는지 확인합니다.
연동과 운영에서 생기는 내부 비용은 무엇이 있나요?
API 사용료 외에도 서비스 쪽에서 드는 비용이 있어, 예산을 잡을 때 함께 고려해야 합니다.
개발 리소스: 1원 송금 요청, 인증 코드 입력 화면, 결과 처리, 실패 처리를 구현하는 개발 작업이 필요합니다.
보안 관리: 계좌번호와 실명 정보를 암호화된 구간으로만 주고받고, 저장 시 일부를 가리는 등 보안 기준을 맞추는 작업이 필요합니다.
고객 지원: 인증 코드를 찾지 못하거나 명의가 맞지 않는 고객의 문의를 처리하는 인력이 필요합니다. 화면 안내가 부족하면 이 비용이 늘어납니다.
운영 모니터링: 성공률과 실패 사유를 주기적으로 보고 개선하는 업무가 필요합니다.
무료 플랜과 유료 플랜은 무엇이 다른가요?
계좌조회 API 중에는 무료 플랜을 두는 곳도 있지만, 무료 플랜은 대부분 개발과 검토 단계에 맞춰져 있습니다.
무료 플랜: 테스트 환경이나 제한된 호출량 안에서 기본 조회를 해 볼 수 있습니다. 연동 흐름과 응답 형식을 미리 확인하는 데 씁니다.
유료 플랜: 실제 고객 계좌를 운영 규모로 조회할 수 있고, 장애 대응과 기술 지원이 포함되는 경우가 많습니다.
무료 플랜으로 흐름을 만든 뒤 유료로 넘어갈 때 요청 형식을 그대로 쓸 수 있는지, 다시 개발해야 하는 부분은 없는지 확인해 두면 전환 비용을 줄일 수 있습니다.
비용 대비 효과는 무엇으로 판단하나요?
계좌조회 API 비용은 API를 쓰지 않을 때 드는 비용과 함께 비교해야 판단할 수 있습니다. 다음 항목을 도입 전후로 비교해 보세요.
잘못된 계좌로 나간 지급 건수: 정산·환불·대출금이 다른 사람 계좌로 나가 되돌려야 했던 건수입니다.
계좌 관련 고객 문의 건수: 무단 출금, 환불 계좌 오류 같은 문의를 처리하는 데 드는 시간입니다.
수작업 확인 시간: 담당자가 통장 사본 등을 직접 확인하던 시간입니다.
계좌조회 API 비용을 줄이려면 어떻게 구성해야 하나요?
계좌조회 API 비용은 단가보다 불필요한 호출을 얼마나 줄이느냐에 따라 달라집니다. 다음 구성을 적용하면 호출 건수를 줄일 수 있습니다.
입력 형식 먼저 확인: 계좌번호 자릿수와 형식을 화면에서 먼저 확인해, 잘못된 계좌로 API를 호출하지 않게 합니다.
명의 대조 후 1원 인증: 명의가 다른 계좌에는 1원 인증을 호출하지 않아, 송금이 포함된 호출을 줄입니다.
중복 요청 막기: 고객이 버튼을 여러 번 누르거나 응답이 늦을 때 같은 요청이 다시 나가지 않게 합니다. 응답이 늦으면 다시 보내기 전에 처리 결과부터 조회합니다.
재시도 횟수 제한: 같은 계좌로 다시 보내기를 허용하는 횟수를 정해, 반복 호출을 막습니다.
확인된 계좌 재사용: 계좌가 바뀌지 않았다면 결제나 지급 때마다 다시 확인하지 않고 기존 확인 결과를 씁니다.
필요한 단계에만 적용: 돈이 고객에게 나가는 단계처럼 확인이 꼭 필요한 곳에 1원 인증을 두고, 단순 정보 입력 단계에는 명의 확인만 둡니다.
화면 안내 개선: 입금자명 위치와 남은 시간을 분명히 안내해, 시간 초과로 인한 재시도를 줄입니다.
견적을 요청하기 전에 무엇을 정리해 두면 좋나요?
계좌조회 API 견적을 요청할 때 다음 내용을 정리해 두면, 우리 서비스에 맞는 구성과 비용을 빠르게 안내받을 수 있습니다.
확인 범위: 예금주 확인만 필요한지, 1원 인증까지 필요한지 정합니다.
적용 단계: 가입, 계좌 등록, 계좌 변경, 출금 전 확인 중 어디에 붙일지 정합니다.
예상 월 건수: 위에서 계산한 신규 등록, 계좌 변경, 재시도 건수를 정리합니다.
재시도 정책: 인증 코드 유효 시간과 다시 보내기 허용 횟수를 정합니다.
테스트 환경 필요 여부: 운영 전에 테스트 환경을 쓸 수 있는지, 테스트 호출은 어떻게 처리되는지 확인합니다.
정리: 계좌조회 API 비용을 볼 때 확인할 것
계좌조회 API 비용은 대부분 호출 건당 과금이며, 조회 방식·호출 건수·추가 인증에 따라 달라집니다.
실패 호출 과금 여부, 테스트 호출 조건, 최소 사용량 조건을 함께 확인해야 실제 비용을 예측할 수 있습니다.
월 호출 건수는 신규 등록, 계좌 변경, 재시도를 더하고 단계별로 걸러지는 건수를 반영해 계산합니다.
명의 대조 후 1원 인증, 중복 요청 방지, 확인된 계좌 재사용으로 불필요한 호출을 줄입니다.
.svg)
.png)
.svg)
.svg)
