API 연동 개발 업체를 고를 때 확인할 5가지 기준
API 연동 업체를 고를 때는 연동 개수나 단가보다 실패했을 때 무엇이 남는지를 먼저 보세요. 같은 결제·ERP·메시지 연동이라도 재시도, 중복 방지, 오류 기록과 재처리 화면이 견적에 들어 있는지에 따라 운영 부담이 크게 달라집니다. 아래 내용은 발주 검토용 가이드이며 특정 업체의 납품 결과나 특정 API의 제공 조건을 보장하지 않습니다.
퍼스트핍 · 최종 업데이트:
1. 상대 서비스의 API 문서를 견적 전에 확인했는가
연동할 서비스가 어떤 기능을 API로 열어 두었는지는 서비스마다 다릅니다. 조회만 되고 등록·수정은 막혀 있거나, 별도 계약과 이용료가 필요하거나, 하루 호출 한도가 정해진 경우가 있습니다.
업체에 연동 대상 목록을 주고 각 API의 인증 방식, 호출 한도, 테스트 환경 제공 여부를 확인했는지 물어보세요. 문서를 읽지 않고 낸 견적은 착수 후 범위가 바뀌기 쉽습니다.
2. 인증 정보와 개인정보를 어떻게 다루는가
API 키와 비밀번호는 소스코드나 문서에 적지 않고 서버의 환경변수나 비밀 저장소에 두어야 합니다. 꼭 필요한 권한만 받은 키를 쓰는지, 담당자가 바뀌거나 키가 노출됐을 때 교체하는 절차가 있는지 확인하세요.
연동 기록에 고객 이름·연락처·결제 정보가 그대로 남지 않도록 어떤 값을 가리는지도 정해야 합니다. 이 기준이 계약 범위와 인수인계 문서에 들어가는지 보세요.
3. 실패했을 때 어떻게 처리하는가
상대 서비스가 느리거나 멈추면 요청이 실패했는지, 처리는 됐는데 응답만 늦은지 구분하기 어렵습니다. 응답을 얼마나 기다릴지, 몇 번 다시 시도할지, 같은 요청이 두 번 처리되지 않도록 고유 키를 쓰는지 확인하세요.
여러 건 중 일부만 실패했을 때 어느 건이 실패했는지 남기고, 담당자가 화면에서 다시 보낼 수 있는지도 중요합니다. 실패를 누가 언제 알게 되는지(메일·메시지 알림) 함께 정하세요.
4. 상대 API가 바뀌면 누가 대응하는가
외부 서비스는 버전을 올리거나 오래된 기능을 종료합니다. 공지를 누가 확인하고, 변경 대응이 하자보수에 들어가는지 유지보수 계약에 들어가는지 미리 나눠 두세요.
연동이 멈췄을 때 바로 알 수 있도록 성공·실패 건수를 보는 화면이나 알림이 있는지도 확인합니다. 출시 후 몇 주가 지나서야 데이터가 빠진 걸 아는 경우가 흔합니다.
5. 검수와 인수인계에 무엇이 포함되는가
정상 처리만 시험하지 말고 인증 만료, 호출 한도 초과, 중복 요청, 상대 서비스 장애 같은 실패 상황을 검수 시나리오에 넣으세요. 각 시나리오의 기대 결과를 착수 전에 문서로 합의하면 완료 기준을 두고 다툴 일이 줄어듭니다.
인수인계 때는 연동 목록과 인증 정보 위치, 오류 기록을 보는 방법, 재처리 절차, 상대 서비스 담당 창구를 정리한 운영 문서를 받으세요. 담당자가 바뀌어도 문서만 보고 대응할 수 있어야 합니다.
견적 요청 전 체크리스트
- 연동 대상별 API 문서·인증 방식·호출 한도·이용료
- 테스트 환경과 테스트 계정 제공 여부
- 인증 정보 보관 위치와 교체 절차, 기록에서 가릴 개인정보
- 재시도·중복 방지·부분 실패 재처리와 실패 알림
- API 변경 대응 범위(하자보수/유지보수)와 운영 문서
연동 개수와 단가만으로 견적을 비교하면 실패 처리와 운영 도구가 빠지기 쉽습니다. 대표적인 정상·실패 시나리오를 업체에 함께 전달하고, 각 시나리오가 어느 산출물과 검수 항목에 들어가는지 확인하세요.