API 연동은 우리 서비스가 다른 회사의 서비스와 정해진 규격으로 데이터를 주고받도록 잇는 작업입니다. 다른 서비스 계정으로 로그인을 받는 것, 결제를 결제대행사에 넘기는 것, 우편번호를 주소 서비스에서 가져오는 것, 알림 메시지를 발송 대행사로 보내는 것이 모두 여기에 들어갑니다. 발주자에게 중요한 것은 구현 방식이 아니라 이 작업이 상대편이 있는 작업이라는 점입니다. 개발사가 아무리 잘해도 상대 서비스의 문서 상태, 심사 절차, 요금 정책, 스펙 변경이 일정과 비용을 함께 결정합니다.
그래서 이 글은 연동을 어떻게 구현하는지 설명하지 않습니다. 코드 이야기는 개발사 몫입니다. 대신 발주자가 견적을 받기 전에 무엇을 정리해야 하고, 견적서에서 무엇을 확인해야 하며, 연동이 깨졌을 때 누가 고치는지를 계약에 어떻게 적어두는지를 다룹니다. API 연동은 회신 금액의 전제가 서로 달라지기 쉬운 항목입니다. 같은 요청을 받고도 개발사마다 세는 대상이 달라 금액이 벌어지는 경우가, 포텐랩이 받는 발주 문의에서 반복적으로 관찰됩니다.
발주자가 "결제 연동해 주세요"라고 말할 때 실제로 넘어가는 일은 한 덩어리가 아닙니다. 조사, 계정과 권한, 구현, 실패 경로 처리, 운영 인계 다섯 층으로 나뉘고, 이 중 코드를 쓰는 구간은 셋째 하나입니다. 나머지 네 층은 서류 제출, 심사 대기, 약관 확인, 운영 감시처럼 개발 실력과 무관하게 시간이 흐르거나 계약이 끝난 뒤까지 남는 일입니다.
이 구분이 발주자에게 중요한 이유는 층마다 일을 하는 주체가 다르기 때문입니다. 조사와 구현은 개발사가 맡지만, 계정 개설과 심사 서류는 발주자 본인이 제출해야 하는 경우가 자주 있고, 운영 인계는 계약이 끝난 뒤 발주자 쪽에 남습니다. 견적서를 볼 때 자주 놓치는 것도 첫째와 다섯째입니다. 견적서에는 셋째 층만 금액으로 적혀 있는데, 실제 프로젝트에서는 첫째 층에서 일정이 밀리고 다섯째 층에서 비용이 다시 발생합니다.
각 층에서 발주자가 확인할 것과 빠뜨렸을 때 생기는 일을 아래 표로 정리했습니다. 견적서 항목 전체를 뜯어보는 일반적인 방법은 IT 외주 개발 견적서 완전 분석 가이드에 정리해 두었고, 이 글은 그중 연동 항목만 확대해서 봅니다.
| 연동 1건에 들어가는 다섯 층 | 발주자가 이 층에서 확인할 것 | 빠뜨렸을 때 나중에 생기는 일 |
|---|---|---|
| 첫째, 조사 및 가능 여부 확인 | 원하는 동작이 상대 서비스에 실제로 열려 있는가, 약관상 우리 용도가 허용되는가 | 구현 중반에 "그 기능은 제공되지 않는다"가 나와 기획이 되돌아간다 |
| 둘째, 계정 개설 및 심사 | 서류를 낼 주체가 우리인가 개발사인가, 대기 기간을 일정에 넣었는가 | 개발은 끝났는데 승인이 안 나 오픈이 밀린다 |
| 셋째, 구현 | 샌드박스와 실계정 중 어디까지가 견적에 들어 있는가 | 실계정 전환이 추가 견적으로 넘어온다 |
| 넷째, 실패 경로 처리 | 타임아웃, 중복 요청, 부분 실패 시 동작이 정의됐는가 | 오픈 후 데이터가 어긋나고 원인 추적에 시간이 든다 |
| 다섯째, 운영 인계 | 키 갱신, 장애 알림, 스펙 변경 추적을 누가 맡는가 | 계약 종료 뒤 아무도 안 보는 상태로 방치된다 |
연동은 화면이 없는 작업입니다. 화면 개발은 발주자가 결과를 눈으로 확인할 수 있어서 "이만큼 했다"가 보이지만, 연동은 정상 동작할 때 아무것도 보이지 않습니다. 그래서 견적에서 과소평가되기 쉽고, 반대로 개발사가 위험을 크게 잡아 금액을 올려 부르기도 합니다. 같은 요청에 회신 금액이 벌어지는 이유가 여기 있습니다.
또 하나는 통제권입니다. 일반 기능은 개발사가 일정을 통제할 수 있지만, 연동은 상대 서비스의 심사 대기, 문서 오류, 점검 시간, 정책 변경에 걸립니다. 개발사가 성실해도 못 지키는 일정이 생기는 영역이라 별도 항목으로 빼고 대기 구간을 일정에 명시하는 것이 안전합니다. 이 대기 구간을 개발 기간 안에 섞어 넣은 견적서는 나중에 지연 책임을 가리기 어렵게 만듭니다.
세 번째는 예외 처리 비중입니다. 연동에서 공수가 늘어나는 자리는 성공 경로보다 실패 경로인 경우가 자주 있습니다. 상대가 응답하지 않을 때, 응답이 늦게 올 때, 같은 요청이 두 번 갈 때, 일부만 처리됐을 때 우리 서비스가 어떻게 행동할지를 정하는 일이 공수를 만듭니다. 견적을 받을 때 "실패 시 동작이 견적에 포함되어 있나요"를 물어보면 이 항목을 세었는지 아닌지가 바로 드러납니다.
연동이 있는 프로젝트에서는 화면 수보다 외부와 맞닿는 경계의 수가 견적에 더 크게 반영됩니다. 경계란 우리 서비스가 외부와 맞닿는 지점을 말합니다. 연동이 하나 늘면 인증 방식 하나, 오류 코드 체계 하나, 재시도 규칙 하나, 데이터 형식 하나가 함께 늘어납니다. 이것들이 서비스마다 제각각이라 앞의 연동에서 만든 처리 방식을 그대로 재사용하기 어려운 경우가 자주 있습니다.
연동끼리 엮이면 공수는 단순 합산보다 빠르게 늘어날 수 있습니다. 예를 들어 결제 연동과 회계 연동이 같이 있으면 두 쪽 숫자가 맞는지 확인하는 대사 작업이 새로 생깁니다. 배송 연동과 알림 연동이 함께 있으면 배송 상태 변경이 알림 발송을 부르는 흐름을 따로 설계해야 합니다. 연동 건수를 셀 때는 목록의 길이가 아니라 서로 데이터를 주고받는 쌍까지 세는 편이 실제 공수에 가깝습니다.
반대로 견적을 줄이는 방법도 있습니다. 초기 버전에서 굳이 자동화하지 않아도 되는 연동을 골라내는 것입니다. 하루 몇 건 안 되는 업무라면 사람이 관리자 화면에서 처리하고, 사용량이 늘었을 때 연동으로 바꾸는 선택이 가능합니다. 무엇을 지금 넣고 무엇을 미룰지 정하는 기준은 MVP 범위 확정 절차에서 다룬 판정 방식을 그대로 쓸 수 있습니다.
목록의 초안은 발주자가 만드는 편이 낫습니다. 개발사는 우리 사업이 어떤 외부 서비스에 이미 묶여 있는지 모릅니다. 지금 쓰는 세무 프로그램, 이미 계약된 문자 발송 업체, 본사에서 내려주는 재고 파일 같은 것은 발주자만 압니다. 이 정보가 늦게 나오면 이미 만든 부분을 다시 손대야 합니다.
목록은 문장으로 적지 말고 표로 적습니다. 한 줄에 한 연동을 두고 아래 칸을 채우면, 개발사가 견적을 낼 때 해석으로 메워야 할 자리가 줄어듭니다. 채우다가 비는 칸이 나오면 그 칸이 곧 발주 전에 해결해야 할 숙제입니다. 견적 요청서 전체 구성은 RFP 뜻과 작성법 완전 가이드를 참고하고, 이 표는 그 안의 첨부 문서로 붙이면 됩니다.
| 목록에 넣을 칸 | 적는 방법 | 비어 있으면 생길 수 있는 해석 차이 |
|---|---|---|
| 대상 서비스 | 회사명과 서비스명을 정확히. 같은 회사도 상품이 여러 개다 | 비슷한 이름의 다른 상품을 기준으로 견적이 잡힐 수 있다 |
| 우리가 쓰려는 동작 | "연동"이 아니라 "주문이 들어오면 송장번호를 받아온다"처럼 동작으로 | 범위가 좁게 해석된 견적을 받게 되고, 나머지가 뒤에 추가 견적으로 돌아올 수 있다 |
| 계약과 계정 보유 여부 | 이미 쓰는 중인지, 신규 가입이 필요한지, 계약이 필요한지 | 계정이 이미 있다고 전제돼 심사 대기가 일정에서 빠질 수 있다 |
| 문서 위치 | 공개 문서 주소, 없으면 담당자 연락처 | 문서가 갖춰져 있다고 전제돼 조사 공수가 아예 잡히지 않을 수 있다 |
| 사용료 부담 주체 | 발주자 명의 결제인지 개발사가 대납 후 정산인지 | 운영비가 견적에서 통째로 빠질 수 있다 |
| 실패했을 때 서비스가 멈추는가 | 멈춤, 일부 기능 제한, 영향 없음 중 하나로 | 중요도가 낮게 해석돼 예외 처리가 간단하게 잡힐 수 있다 |
문서 상태는 연동 견적을 가르는 축입니다. 공개 문서, 샌드박스 환경, 오류 코드 목록, 변경 이력이 갖춰진 서비스는 개발사가 착수 전에 범위를 판단할 수 있습니다. 반대로 문서가 없고 담당자 이메일로 스펙을 받아야 하는 서비스는 조사 자체가 별도 작업이 됩니다. 이 경우 개발사는 위험을 금액에 얹거나, 조사 단계를 따로 계약하자고 제안합니다.
문서가 없는 쪽으로는 협력사 시스템, 오래된 사내 프로그램, 특정 산업의 전용 시스템이 자주 나옵니다. 이때 발주자가 할 일은 코드를 이해하는 것이 아니라 상대편 기술 담당자와의 연결 통로를 확보하는 것입니다. 질문을 보냈을 때 며칠 안에 답이 오는 경로가 있는지, 테스트용 계정을 내줄 수 있는지를 발주 전에 확인해야 합니다. 이 통로가 없으면 개발사는 일정을 약속할 수 없습니다.
문서가 있어도 안심할 수 없는 경우가 있습니다. 문서와 실제 동작이 다른 경우, 예제가 오래된 버전 기준인 경우, 한국어 문서와 영어 문서 내용이 어긋나는 경우입니다. 그래서 견적 단계에서 "문서 기준으로 산정했고, 실제 동작이 다르면 변경 절차를 따른다"는 문장을 넣어두면 나중에 다툴 일이 줄어듭니다. 변경 절차를 문서로 남기는 방법은 변경 요청서(CR) 작성 가이드에 정리돼 있습니다.
| API 유형 | 알아보는 신호 | 발주자가 미리 해둘 것 | 견적에 나타나는 방식 |
|---|---|---|---|
| 공개 문서형 | 문서 주소가 공개돼 있고 테스트 키를 바로 받는다 | 계정만 우리 명의로 개설 | 구현 공수 위주로 산정된다 |
| 심사형 | 가입은 되는데 실서비스 키는 검수 후 발급된다 | 사업자 서류, 처리방침, 심사용 계정 준비 | 구현 외에 심사 대응과 대기 구간이 붙는다 |
| 계약형 | 영업 담당자와 계약을 맺어야 문서를 받는다 | 계약 협상을 발주 전에 시작 | 계약 완료 시점이 착수 조건으로 걸린다 |
| 문서 없는 사내 또는 협력사 시스템 | 담당자에게 물어봐야 스펙을 안다 | 기술 담당자 연결과 질의 응답 경로 확보 | 조사 단계가 별도 항목으로 잡히거나 금액에 위험이 얹힌다 |
지도 서비스, 공공 데이터 포털, 금융 관련 서비스처럼 실서비스 사용 전에 심사나 신청 절차를 두는 API가 있습니다. 이런 심사에서는 코드보다 서비스가 실제로 존재한다는 증거를 확인하는 경우가 많습니다. 서비스 소개 화면, 접근 가능한 도메인, 개인정보 처리방침, 이용약관, 심사자가 직접 들어가 볼 수 있는 테스트 계정이 자주 요구되는 항목입니다. 다만 요구 항목은 제공사마다 다르고, 금융이나 공공 데이터 쪽은 기술 구성이나 보안 항목을 함께 보는 경우도 있으므로 해당 서비스의 심사 안내 페이지에서 확인하세요.
대표적으로 로그인 제공사와 결제대행사도 이 유형에 들어갑니다. 다만 이 둘은 제공사별로 서류와 대기 구간이 크게 갈려서, 이 글에서는 심사형 연동에 공통으로 해당하는 절차만 다룹니다. 어느 쪽이든 준비물의 성격은 같습니다. 이 문서들은 개발사가 아니라 발주자가 만들어야 하는 것인데, 개발 일정표에는 이 작업이 안 적혀 있어서 개발이 끝난 뒤에야 준비를 시작하는 순서가 자주 나옵니다.
그래서 착수 시점에 심사가 필요한 연동을 먼저 골라내고, 연동별로 제출 서류와 담당자를 정해두는 것이 실질적인 일정 단축 방법입니다. 심사 기간은 서비스마다 다르고 공지도 자주 바뀌므로, 특정 일수를 가정해 일정을 짜지 마세요. 각 제공사의 공지 페이지에서 현재 기준을 확인하고, 반려됐을 때 재제출하는 구간까지 일정에 넣어야 합니다. 앱 스토어 심사도 같은 성격의 대기 구간이고, 이쪽은 앱 출시·앱스토어 심사 완전 가이드에서 따로 다룹니다.
원칙은 간단합니다. 외부 서비스 계정은 발주자 법인 명의로 만들고, 결제 수단도 발주자 것을 연결합니다. 개발사 계정으로 만들면 계약이 끝난 뒤 계정을 넘겨받는 과정에서 문제가 생깁니다. 서비스에 따라 명의 변경이 아예 안 되거나, 다시 심사를 받아야 하거나, 그동안 쌓인 설정과 이력이 함께 넘어오지 않기도 합니다.
키는 역할별로 나눠 발급합니다. 개발용과 운영용을 분리하고, 개발사에는 필요한 범위의 키만 줍니다. 그리고 계약 종료 시 키를 재발급하고 개발사 접근을 회수하는 절차를 계약서에 적어둡니다. 이 절차가 없으면 종료 후에도 외부 서비스에 접근 가능한 키가 남습니다.
키를 주고받는 경로도 정해두는 편이 좋습니다. 메신저나 이메일 본문에 키를 그대로 붙여 보내는 방식은 대화 기록이 여러 사람 기기에 남아 회수가 어렵습니다. 접근 권한을 관리할 수 있는 저장소를 쓰고, 누가 언제 어떤 키를 받았는지 목록으로 남깁니다. 넘겨받아야 할 계정과 자산 전체 목록은 인수인계 완전 가이드에, 키 관리와 점검 항목은 보안 점검·취약점 대응 가이드에 있습니다.
개발비는 대체로 프로젝트 단위로 정산되지만, 외부 API 사용료는 서비스가 운영되는 동안 계속 발생할 수 있습니다. 과금 방식도 종류가 있습니다. 호출 건수로 세는 방식, 처리량으로 세는 방식, 월정액에 사용량을 얹는 방식, 무료 구간을 준 뒤 초과분만 받는 방식이 섞여 있습니다. 무료 구간 안에서 개발을 마치면 오픈 전까지 비용이 보이지 않다가 사용자가 늘면서 나타납니다.
단가는 이 글에 적지 않습니다. 제공사마다 다르고 요금제가 자주 바뀌어서 며칠이면 틀린 정보가 되기 때문입니다. 대신 각 서비스의 공식 가격 페이지에서 직접 확인하고, 그 값을 우리 예상 사용량에 곱해 월 운영비를 계산하세요. 계산 결과는 견적서의 개발비와 별도 줄로 관리해야 총비용이 보입니다. 사용량 기반 과금이 어떻게 예상을 벗어나는지는 OpenAI API 비용 줄이는 법에서 AI API를 예로 자세히 다뤘습니다.
견적 요청 시에는 "연동 대상별 월 예상 운영비를 별도 표로 제출해 주세요"라고 명시하는 편이 좋습니다. 이렇게 요구하면 개발사가 요금제를 실제로 확인했는지가 드러나고, 회신 간 비교도 쉬워집니다. 견적 단계에서 받은 이 표는 착수 회의에서 다시 확인해 합의 항목으로 굳히는 것이 좋습니다. 킥오프에서 제3자 서비스 비용을 어떻게 합의하는지는 IT 외주 개발 킥오프 미팅 완전 가이드의 체크리스트에 있습니다. 즉 견적 단계에서는 금액을 받고, 착수 단계에서 그 금액을 합의 문서로 옮기는 순서입니다.
계약서 문구도 함께 봐야 합니다. 사용료 부담 주체와 사전 고지 의무를 어떻게 적으면 발주자에게 불리해지는지는 IT 외주 개발 계약서 독소조항 완전 분석의 다섯 번째 조항에서 다룹니다. 총소유비용 관점에서 개발비와 운영비를 함께 쌓아보는 방법은 홈페이지 제작 비용 2026에서 3년 합산 예시로 설명했습니다.
"연동됐습니다"라는 말은 검수 기준이 될 수 없습니다. 샌드박스에서 성공 응답을 받은 것과 실제 계정에서 실제 거래가 도는 것은 다른 상태입니다. 검수 기준은 시나리오로 적어야 합니다. 예를 들어 결제라면 "결제 성공 후 주문 상태가 바뀌고, 취소 시 환불이 반영되며, 결제 도중 창을 닫으면 주문이 미결제로 남는다"처럼 씁니다.
실패 시나리오를 반드시 포함하세요. 상대가 응답하지 않을 때, 응답이 늦을 때, 같은 요청이 두 번 전달됐을 때, 상대 점검 시간에 걸렸을 때 우리 화면과 데이터가 어떻게 되는지를 하나씩 확인합니다. 이 목록이 검수 항목이 되면 개발사도 처음부터 그 경로를 만들어 둡니다. 검수 문서를 어떻게 구성하고 사인오프까지 가는지는 산출물 검수·사인오프 완전 가이드에 있습니다.
실계정 테스트에는 사전 준비가 필요합니다. 결제라면 실제 카드로 소액 거래를 하고 취소까지 돌려봐야 하고, 알림 메시지라면 발신 정보 등록이 끝나 있어야 합니다. 이 준비를 누가 언제 하는지 검수 일정 안에 적어두지 않으면, 검수 예정일에 테스트를 못 하고 일정이 뒤로 밀립니다.
이 질문이 API 연동 계약에서 실무적으로 중요한 지점입니다. 연동은 우리 코드가 멀쩡해도 상대가 바뀌면 깨집니다. 그런데 계약서에는 "하자보수 O개월"만 적혀 있고, 하자의 정의가 우리 코드 결함으로 한정돼 있는 경우가 있습니다. 이 상태에서 상대 서비스가 규격을 바꾸면 무상 대상인지 유상 대상인지 다툼이 생깁니다.
해결 방법은 원인별로 처리 방식을 미리 갈라두는 것입니다. 계약서나 유지보수 조건에 아래 구분을 표로 넣고, 각 줄에 대응 착수 기준과 비용 부담을 적습니다. 중요한 것은 금액을 미리 정하는 것보다 어떤 상황이 어느 칸에 들어가는지를 합의해 두는 것입니다. 유지보수 계약의 범위 설정은 개발 유지보수 계약·비용 가이드에서 더 넓게 다룹니다.
| 깨진 원인 | 누가 판단하는가 | 계약에 적어둘 처리 방식 |
|---|---|---|
| 우리 쪽 구현 결함 | 재현 절차로 확인 가능 | 하자보수 기간 내 무상 수정, 착수 기준 시간 명시 |
| 상대 서비스의 소규모 규격 변경 | 상대의 공지나 변경 이력으로 확인 | 유지보수 범위에 포함할지, 건별 처리할지 사전 합의 |
| 상대 서비스의 대규모 개편이나 구버전 종료 | 상대 공지 기준 | 신규 개발로 보고 별도 견적, 다만 통지와 영향 분석은 유지보수 범위에 |
| 키 만료, 계약 해지, 요금 미납 | 발주자 계정 상태 | 발주자 책임으로 두되 만료 임박 알림을 누가 보내는지 지정 |
| 사용량 초과로 인한 호출 제한 | 사용량 기록 | 임계치 알림과 상향 신청 절차를 운영 문서에 포함 |
| 상대 서비스 장애 | 상대 상태 페이지 | 복구 대기 중 우리 서비스가 취할 동작을 사전 정의 |
표에서 두 번째와 세 번째 줄을 가르는 기준을 계약 시점에 문장으로 남겨두면 좋습니다. 예를 들어 "상대가 기존 방식을 계속 지원하면서 항목만 추가한 경우는 유지보수, 기존 방식을 종료해 다시 만들어야 하는 경우는 신규 개발"처럼 적습니다. 완벽한 구분은 어렵지만, 기준이 있는 것과 없는 것의 차이가 큽니다.
연동 장애를 사용자 문의로 뒤늦게 알게 되는 경우가 있습니다. 그 전에 알아차리려면 세 가지를 요구하세요. 첫째, 연동별 실패율이 일정 수준을 넘으면 알림이 오도록 하는 것입니다. 둘째, 결제나 정산처럼 숫자가 오가는 연동은 우리 기록과 상대 기록을 맞춰보는 대사 절차를 두는 것입니다. 셋째, 상대 서비스의 상태 공지와 개발자 공지를 구독해 둘 담당자를 정하는 것입니다.
세 번째는 사람 문제라 자주 빠집니다. 상대 서비스가 구버전 종료를 몇 달 전에 공지해도 그 메일을 아무도 안 보면 종료 당일에 서비스가 멈춥니다. 공지 수신 주소를 개인 메일이 아니라 회사 공용 주소로 등록하고, 그 주소를 확인할 담당자를 계약서나 운영 문서에 적어두세요. 담당자가 개발사 직원이라면 계약 종료 시 인계 대상에 포함해야 합니다.
알림 체계와 온콜 대응을 외주로 맡길 때 무엇을 받게 되는지는 모니터링 외주 개발 인계 가이드에서 다뤘고, 결제·정산 쪽에서 넘겨받아야 할 인계 항목은 결제·정산 시스템 인계 가이드에 정리돼 있습니다.
연동을 한 줄로 적으면 회신도 한 줄로 옵니다. "API 연동 일체"라고 쓰면 개발사마다 다른 범위를 상상하고, 그 결과 회신 금액이 서로 비교 불가능한 상태가 됩니다. 아래 표의 오른쪽처럼 적으면 개발사가 같은 것을 세게 되고, 회신 간 비교가 가능해집니다.
| 자주 보는 요청 문장 | 비어 있는 정보 | 대신 적을 문장 |
|---|---|---|
| 결제 연동 필요 | 어느 대행사인지, 계약 상태, 정기결제 여부 | 결제대행사 A(계약 완료, 테스트 키 보유)로 일반결제와 부분취소까지 연동 |
| 지도 좀 붙여주세요 | 어떤 지도 서비스, 쓰려는 기능, 예상 호출량 | 지도 표시와 주소 검색 두 기능, 월 예상 호출량 첨부, 요금 구간 확인 요청 |
| 사내 시스템과 연동 | 문서 유무, 담당자, 접근 방식 | 사내 재고 시스템(문서 없음, 담당자 지정 완료)과 재고 수량 조회 연동, 조사 단계 별도 산정 가능 |
| 알림 발송 기능 | 채널, 발신 정보 등록 상태, 템플릿 심사 필요 여부 | 알림 메시지 발송(발신 정보 등록 상태와 템플릿 심사 필요 여부는 제공사 공지에서 확인) 연동, 심사 대기 구간을 일정에 별도 표시 |
| API 연동 일체 | 건수, 대상, 실패 처리 범위 | 연동 목록 표 첨부, 각 건별 견적과 월 운영비를 나눠 제출 요청 |
여기에 한 문장을 더 붙이면 좋습니다. "각 연동의 실패 시 동작 정의와 실계정 테스트가 견적에 포함되는지 명시해 주세요." 이 문장 하나로 견적서의 성격이 달라집니다. 기능 단위로 요구사항을 정리하는 방법은 앱 아이디어를 기능 명세서로 만드는 법에서 이어서 볼 수 있습니다.
연동 프로젝트에서 자주 되풀이되는 문제들이 있습니다. 기술 난이도가 아니라 준비 순서와 권한에서 비롯되는 것들입니다.
약관 문제는 특히 조심해야 합니다. 서비스마다 허용 범위가 다르고, 같은 서비스라도 요금제에 따라 조건이 달라집니다. 우리 용도가 허용되는지는 일반론이 아니라 해당 서비스의 현재 약관과 개발자 정책 문서를 기준으로 확인해야 하고, 판단이 어려우면 제공사에 직접 문의해 답변을 문서로 남겨두는 편이 안전합니다.
연동은 지연 원인을 가리기 어려운 항목입니다. 개발사는 상대 서비스 탓이라 하고 발주자는 개발이 늦다고 보는 상황이 생깁니다. 이를 줄이려면 연동별로 대기 구간과 작업 구간을 처음부터 분리해 표시하는 방법이 있습니다. 심사 제출일, 승인일, 구현 시작일, 실계정 테스트일을 각각 기록하면 어디서 시간이 갔는지 나중에 확인할 수 있습니다.
승인 대기 중에 개발을 멈추지 않도록 설계하는 것도 방법입니다. 실계정 키가 나오기 전이라도 샌드박스나 가짜 응답으로 우리 쪽 흐름을 먼저 완성해 두면, 키가 나온 뒤 남는 작업이 줄어듭니다. 견적 단계에서 "승인 대기 중 어떤 작업을 진행할 계획인가요"를 물어보면 개발사의 일정 설계 방식이 드러납니다.
이미 일정이 밀린 상황에서 무엇을 확인하고 어떤 순서로 대응하는지는 일정 지연 대응 완전 가이드에 별도로 정리했습니다. 연동 지연은 범위 축소로 대응 가능한 경우가 있어서, 어떤 연동을 오픈 후로 미룰 수 있는지 먼저 따져보는 것이 실용적입니다.
연동의 성격에 따라 필요한 팀이 다릅니다. 결제, 로그인, 배송, 사내 시스템처럼 규격이 정해진 연동은 제품 개발팀이 맡는 일입니다. 반면 AI 모델 API처럼 같은 입력에 매번 다른 결과가 나오는 연동은 성격이 다릅니다. 검수 기준을 "동작한다"로 잡을 수 없고, 품질 평가 방식과 비용 통제 설계가 함께 필요합니다.
포텐랩은 앱과 웹 프로덕트 개발, 그리고 외부 서비스 연동이 포함된 MVP 구축을 맡습니다. AI 자체가 제품인 경우 — 챗봇, 문서 검색, RAG처럼 모델 품질이 서비스 가치를 결정하는 프로젝트는 트리숲(TreeSoop) 쪽이 맞습니다. 가르는 질문은 하나입니다. 연동이 기능을 붙이는 일인가, 아니면 연동 결과의 품질 자체가 제품인가. 맞지 않는 쪽에 맡기면 양쪽 모두 손해라서, 기준을 먼저 확인하는 편이 서로에게 낫습니다.
연동은 상대편이 있는 작업이라 약속한 일정을 지키는 일이 우리 쪽 노력만으로 끝나지 않습니다. 그래서 발주자가 볼 수 있는 지표는 결국 맡긴 일이 끝까지 갔는가입니다. 포텐랩 자체 실적 기준으로 수행완수율은 97%입니다. 어느 쪽에 맡기든 발주 전에 연동 목록 표를 채워 가면 첫 미팅의 밀도가 달라집니다. AI 기능을 발주할 때 계약서와 요청서에 넣을 항목은 AI·LLM 기능 발주 완전 가이드에, 전체 개발 발주 흐름은 MVP 뜻과 개발 방법 2026에 정리돼 있습니다.
연동은 상대편이 있는 작업이라 심사 대기, 문서 오류, 점검 시간, 정책 변경처럼 개발사가 통제할 수 없는 요인이 일정에 걸립니다. 또 화면이 없어 진척이 눈에 보이지 않고, 공수가 늘어나는 자리는 성공 경로보다 실패 경로 처리인 경우가 자주 있습니다. 그래서 일반 기능과 묶지 말고 별도 항목으로 빼서 대기 구간을 일정에 명시하는 편이 안전합니다.
연동이 있는 프로젝트에서는 화면 수보다 외부와 맞닿는 경계의 수가 견적에 더 크게 반영됩니다. 연동이 하나 늘 때마다 인증 방식, 오류 코드 체계, 재시도 규칙, 데이터 형식이 함께 늘어나는데 서비스마다 제각각이라 앞의 처리 방식을 그대로 재사용하기 어렵습니다. 결제와 회계처럼 연동끼리 데이터를 주고받으면 대사 작업이 새로 생겨 단순 합산보다 빠르게 늘어날 수 있습니다.
외부 서비스 계정은 발주자 법인 명의로 만들고 결제 수단도 발주자 것을 연결하는 편이 안전합니다. 개발사 명의로 만들면 계약 종료 후 명의 변경이 아예 안 되거나, 다시 심사를 받아야 하거나, 그동안 쌓인 설정과 이력이 함께 넘어오지 않을 수 있습니다. 키는 개발용과 운영용을 나눠 발급하고, 계약 종료 시 재발급과 접근 회수 절차를 계약서에 적어두세요.
이런 심사에서는 코드보다 서비스가 실제로 존재한다는 증거를 확인하는 경우가 많습니다. 서비스 소개 화면, 접근 가능한 도메인, 개인정보 처리방침, 이용약관, 심사자가 직접 들어가 볼 수 있는 테스트 계정이 자주 요구되고 주로 발주자가 준비하는 문서입니다. 다만 요구 항목과 심사 기간은 제공사마다 다르고 공지도 자주 바뀌므로, 해당 서비스의 심사 안내 페이지에서 현재 기준을 확인한 뒤 반려 시 재제출 구간까지 일정에 넣으세요.
계약에 원인별 구분이 없으면 무상인지 유상인지 다툼이 됩니다. 우리 쪽 구현 결함은 하자보수, 상대의 소규모 규격 변경은 유지보수 범위에 넣을지 건별로 처리할지 사전 합의, 구버전 종료처럼 다시 만들어야 하는 경우는 신규 개발로 보고 별도 견적을 잡습니다. 기존 방식이 계속 지원되는지 종료되는지를 가르는 문장을 계약 시점에 남겨두면 판단이 쉬워집니다.
"연동됐습니다"는 검수 기준이 될 수 없고, 샌드박스 성공 응답과 실계정에서 실제 거래가 도는 것은 다른 상태입니다. 결제라면 "결제 성공 후 주문 상태가 바뀌고, 취소 시 환불이 반영되며, 도중에 창을 닫으면 미결제로 남는다"처럼 시나리오로 적습니다. 응답 없음, 지연, 중복 요청, 상대 점검 시간 같은 실패 시나리오도 검수 항목에 함께 넣어야 합니다.