API 연동 업체 선정 기준 7가지 | 견적서에서 볼 것

먼저 짧게 답부터 드릴게요. API 연동은 결제·지도·알림 같은 외부 서비스를 우리 서비스에 붙이는 일이에요. 그런데 같은 기획서를 줘도 업체마다 견적이 크게 벌어져요. 한 곳은 핵심 기능만 잡고, 다른 곳은 예외 처리와 관리자 화면까지 넣거든요. 그래서 총액을 비교하기 전에 “비슷한 연동을 해봤는지, 그 사람이 실제로 들어오는지, 테스트 환경과 인수인계는 챙겼는지”를 물어야 해요. 발주 전에 던질 질문 7가지를 정리했어요.

“결제만 붙이면 되는데 왜 견적이 두 배씩 차이 나죠?” API 연동을 맡길 때 자주 나오는 질문이에요. 연동은 겉으로는 간단해 보여도, 외부 서비스의 규칙을 따라가고 실패하는 경우까지 처리해야 해서 업체의 경험에 따라 결과가 많이 갈려요. 업체를 고를 때 무엇을 봐야 하는지 하나씩 짚어볼게요.

1. 비슷한 연동을 해봤는지, 그 사람이 들어오는지

가장 먼저 볼 건 비슷한 연동 경험이에요. 결제, 정산, 지도, 알림처럼 외부 서비스를 붙여본 업체는 어디서 막히는지를 미리 알아요. 그런데 여기서 한 단계 더 물어야 해요. “그 경험을 가진 담당자가 이번 프로젝트에 실제로 들어오나요?”

같은 업종의 회사와 일해봤다는 말만으로는 부족해요. 어떤 기능을 맡았고, 그 일을 한 사람이 우리 프로젝트에 투입되는지가 결과를 가르거든요. 회사의 이력과 투입되는 사람의 이력은 다른 이야기예요.

2. 총액 말고 ‘포함 범위’를 비교하세요

견적서를 받으면 맨 아래 총액부터 보게 돼요. 그런데 같은 기획서로도 견적 차이가 크게 나는 건 대개 포함 범위가 다르기 때문이에요. 한 업체는 “연동이 성공하는 경우”만 잡고, 다른 업체는 결제 실패·중복 요청·환불 같은 예외 상황과 관리자 확인 화면까지 넣어요.

그래서 두 견적을 나란히 놓고 “이 금액에 예외 처리가 들어갔나, 관리자가 확인하는 화면이 있나, 테스트는 어디까지인가”를 대조해야 해요. 싸 보이는 견적이 사실은 반만 담긴 경우가 많아요. 연동이 전체 비용에 어떻게 작용하는지는 API 연동이 개발 비용에 미치는 영향에서 더 자세히 다뤘어요.

3. 테스트 환경을 주는지 먼저 확인하세요

외부 서비스를 붙일 때 의외로 중요한 게 테스트 환경이에요. 실제 돈이 오가기 전에 가짜 데이터로 연동을 확인할 수 있어야 하거든요. 결제사나 외부 서비스가 테스트 환경을 제공하는지, 업체가 그걸 써서 검증하는지를 미리 물어보세요.

외부 서비스에 접근할 때 쓰는 열쇠(API 키)도 같이 챙겨야 해요. 이 키는 우리 서비스를 쓸 권한을 증명하는 것이라, 누구 이름으로 발급받고 어떻게 보관하는지가 분명해야 해요. 나중에 업체를 바꿀 때 이 키가 업체 계정에만 묶여 있으면 곤란해지거든요.

4. 일정은 ‘연동 따로, 배포 따로’로 잡으세요

연동 일정을 짤 때 흔히 놓치는 게 서버에 올리고 도메인·보안 인증서(SSL)를 설정하는 시간이에요. 이 작업만 보통 며칠이 더 걸리는데, 개발 완료일과 뭉뚱그리면 “다 됐다는데 왜 아직 안 열리지?”가 돼요.

테스트와 버그 수정에도 시간이 들어요. 외부 서비스는 우리가 통제할 수 없어서, 그쪽 응답이 느리거나 규칙이 바뀌면 거기에 맞춰야 하거든요. 그래서 최종 오픈일을 기준으로 1～2주 정도 여유를 두고 일정을 잡는 게 안전해요. 일정에 여유가 없는 견적일수록 막판에 쫓기게 돼요.

5. 무상 수정 범위를 숫자와 기준으로 받으세요

연동이 끝난 뒤에 “이건 수정인가, 추가인가”로 다투는 일이 자주 생겨요. 그래서 계약 전에 수정 범위를 또렷하게 받아두는 게 좋아요. 업체마다 기준이 다른데, 어떤 곳은 “처음 요청 범위 안의 세부 수정은 2회까지 무상”처럼 횟수로 정하고, 어떤 곳은 “합의된 기획 안에서 제대로 안 되는 오류나 빠진 기능은 횟수 제한 없이 무상, 새 API를 더 붙이는 건 유상”처럼 성격으로 나눠요.

어느 방식이든 “무엇이 무상이고 무엇이 유상인지”가 계약서에 적혀 있으면 돼요. 발주 전에 업체에 어떤 질문을 던져야 하는지는 견적서에서 업체에 되물을 질문에 모아뒀어요.

6. 인수인계 항목을 계약 시점에 못 박으세요

연동은 한 번 붙이고 끝이 아니에요. 외부 서비스가 규칙을 바꾸면 우리도 따라가야 하고, 그때 업체가 바뀌어 있을 수도 있어요. 그래서 소스 코드, 관리자 계정, 서버 접근 권한, 그리고 어떤 외부 서비스를 어떤 버전으로 붙였는지 적은 문서를 “납품 때 함께 받는다”고 계약에 적어두는 게 좋아요.

이걸 처음에 정해두면 나중에 유지보수를 맡기거나 업체를 바꿀 때 훨씬 수월해져요. 반대로 인수인계 범위가 흐릿하면, 멀쩡히 돌아가는 서비스인데도 손댈 수 있는 사람이 원래 업체뿐인 상황에 묶여요.

7. 유지보수 포함 여부를 계약서에서 확인하세요

대부분의 업체가 유지보수 계약을 함께 제안해요. 그런데 “유지보수 해드려요”라는 말과 “무엇을 어디까지 해준다”는 다른 이야기예요. 외부 서비스의 규칙 변경에 대응하는 것까지 포함인지, 아니면 그건 별도인지가 특히 중요해요. 연동한 외부 서비스는 우리가 손대지 않아도 저쪽에서 바뀌거든요.

저희는 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각해요. 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영하면서, 연동은 오픈이 끝이 아니라 시작이라는 걸 배웠거든요. 롯데·캐논 같은 곳과도 함께해 왔고요. 어떤 업체가 맞을지, 견적서를 어떻게 읽어야 할지 고민이라면 연동 견적을 함께 짚어드릴게요 →

자주 묻는 질문

API 연동 업체를 고를 때 가장 먼저 봐야 할 건 뭔가요?

비슷한 연동 경험과, 그 경험을 가진 담당자가 실제로 투입되는지예요. 회사 이력과 투입 인력의 이력은 달라서, “비슷한 업종과 일해봤다”가 아니라 “어떤 기능을 맡았고 그 사람이 우리 프로젝트에 들어오느냐”를 물어야 해요. 그다음으로 견적의 포함 범위와 테스트 환경을 확인하면 돼요.

같은 기획서인데 연동 견적이 왜 이렇게 차이 나나요?

대부분 포함 범위가 다르기 때문이에요. 연동이 성공하는 경우만 잡은 견적과, 실패·중복·환불 같은 예외 처리와 관리자 확인 화면까지 넣은 견적은 금액이 크게 달라져요. 총액만 비교하지 말고 “예외 처리, 관리자 화면, 테스트 범위가 들어갔는지”를 항목별로 대조하는 게 좋아요.

연동한 뒤에 외부 서비스가 바뀌면 비용이 또 드나요?

그럴 수 있어요. 외부 서비스는 우리가 손대지 않아도 저쪽에서 규칙을 바꾸는데, 그 변경에 맞추는 작업이 유지보수에 포함인지 별도인지는 업체마다 달라요. 그래서 계약서에 “외부 서비스 규칙 변경 대응”이 유지보수 범위에 들어가는지를 미리 적어두는 게 안전해요.