소셜 로그인·결제 연동 2026: 카카오·PG 붙일 때 드는 비용과 기간

소셜 로그인 연동은 카카오·네이버·구글·애플처럼 이미 계정을 가진 제공사의 인증을 빌려와 우리 서비스에 로그인시키는 작업이고, 결제(PG) 연동은 카드사·간편결제와 우리 서비스 사이에 승인·취소·정산이 오가게 만드는 작업이에요. 발주자 입장에서 두 작업의 공통점은 하나예요. 개발사가 코드를 다 짜도 그것만으로는 켜지지 않는다는 것. 양쪽 다 외부 제공사의 등록·검수·계약을 통과해야 실제 사용자가 쓸 수 있는 상태가 됩니다.

그래서 이 글은 구현 코드를 다루지 않아요. 검색해서 나오는 문서는 개발자용 연동 가이드가 많은데, 발주자가 미팅에서 실제로 부딪히는 문제는 다른 쪽에 있어요. 무엇을 요구할지, 어떤 서류를 우리가 준비할지, 심사가 밀렸을 때 일정표의 어느 줄이 흔들리는지, 계정 명의를 누구 이름으로 여는지 같은 것들이에요.

정리 순서는 이렇습니다. 먼저 소셜 로그인이 왜 단순 붙이기가 아닌지, 제공사별로 무엇을 심사하는지 봅니다. 그다음 결제 연동에 필요한 사업자 서류와 심사 기준을 정리하고, 마지막으로 견적·일정·명의·검수를 발주자 관점의 체크리스트로 묶습니다.

소셜 로그인 연동은 정확히 무엇을 붙이는 작업인가요?

발주서에 "카카오 로그인 연동"이라고 한 줄 적으면 개발사는 그것을 최소 네 덩어리로 읽어요. 첫째는 제공사 콘솔에 애플리케이션을 등록하고 키를 발급받는 일, 둘째는 앱이나 웹에서 제공사 인증 화면을 띄우고 돌아온 토큰을 받는 일, 셋째는 그 토큰을 서버에서 검증해 우리 서비스의 회원으로 만드는 일, 넷째는 그 회원이 다음에 다시 왔을 때 같은 사람으로 이어붙이는 일이에요.

이 중 발주자가 화면으로 확인할 수 있는 건 두 번째 덩어리뿐이에요. 나머지 세 덩어리는 화면에 드러나지 않아서 견적에서 과소평가되기 쉬워요. 특히 네 번째, 즉 계정 식별 규칙은 나중에 바꾸기가 어려워서 초기 결정이 그대로 굳어져요.

구체적으로는 이런 질문에 답을 정해야 합니다. 같은 사람이 카카오로 한 번, 구글로 한 번 가입하면 계정이 둘이 되나요, 하나로 합쳐지나요. 이메일을 기준으로 합친다면 제공사가 이메일을 안 주는 경우는 어떻게 하나요. 소셜 계정 연결을 해제하면 우리 서비스의 데이터는 남나요, 지워지나요. 이 답이 정해지지 않으면 개발사는 임의로 정하고, 서비스가 커진 뒤에 데이터 정리 작업이 다시 견적으로 돌아옵니다.

소셜 로그인이 왜 "그냥 붙이면 되는" 기능이 아닌가요?

연동 자체는 문서화가 잘 돼 있어요. 그래서 개발 난이도만 보면 큰 작업이 아닌 게 맞습니다. 문제는 난이도가 아니라 통제권이에요. 키를 발급하는 것도, 동의 항목을 허용하는 것도, 심사를 통과시키는 것도 우리가 아니라 제공사가 합니다.

그리고 제공사마다 "무료로 그냥 되는 범위"와 "심사를 통과해야 되는 범위"가 갈려요. 로그인만 되게 하는 것과, 로그인하면서 이메일·전화번호·생년월일 같은 정보를 함께 받아오는 것은 다른 작업으로 취급됩니다. 후자는 왜 그 정보가 필요한지 사업적 근거를 적어 신청하고, 승인이 나야 켜집니다. 이 차이를 모르고 견적을 받으면 "로그인 붙였는데 이메일이 안 들어온다"는 상황이 검수 직전에 나와요.

또 하나. 소셜 로그인은 개인정보 처리방침과 붙어 있는 기능이에요. 어떤 항목을 받는지, 어디에 보관하는지, 필수 동의인지 선택 동의인지가 방침 문서에 적혀 있어야 하고, 심사에서 그 문서를 확인합니다. 방침 문서를 아직 안 만든 상태로 연동만 먼저 진행하면 심사 단계에서 멈춥니다.

정리하면 소셜 로그인의 리스크는 코드가 아니라 절차에 있어요. 코드는 개발사가 며칠이면 쓰지만, 절차는 우리가 서류를 준비해야 시작되고 제공사가 답을 줘야 끝납니다.

카카오·네이버·구글·애플은 각각 무엇을 심사하나요?

제공사별로 요구하는 게 조금씩 다른데, 공통 축은 세 가지예요. 첫째 이 서비스가 실재하는가(접속 가능한 화면이나 심사용 계정), 둘째 요청하는 정보가 서비스에 필요한가, 셋째 개인정보 처리와 약관 문서가 갖춰져 있는가.

아래 표는 발주자가 준비해야 하는 것 위주로 정리한 거예요. 개발사가 대신 신청서를 써주는 경우도 있지만, 사업자 정보와 사업 내용 설명은 발주자가 내야 하는 항목이에요.

표를 읽기 전에 열의 성격을 하나 밝혀둡니다. 마지막 열 「자주 막히는 지점」은 공표된 통계가 아니라 발주 현장에서 반복적으로 관찰되는 유형을 정리한 것이고, 제공사 공식 문서에 그렇게 적혀 있다는 뜻이 아니에요. 앞의 두 열은 각 제공사가 공개한 절차를 요약한 것이지만 이 열은 관찰이라는 점을 구분해서 읽어주세요.

이 표는 절차의 성격을 비교하려고 만든 거예요. 각 제공사의 요구 항목은 정책이 바뀌면 함께 바뀌니, 착수 시점에 해당 제공사의 공식 개발자 문서에서 현재 기준을 다시 확인하는 걸 전제로 읽어주세요. 개발사에 "우리가 준비해야 할 서류 목록을 제공사 문서 링크와 함께 달라"고 요청하면 이 표를 우리 프로젝트 버전으로 받을 수 있어요.

애플 로그인은 왜 iOS 앱에서 따로 챙겨야 하나요?

웹만 만든다면 애플 로그인은 선택이에요. 그런데 iOS 앱을 함께 낼 계획이라면 확인할 항목이 하나 늘어납니다. 애플은 서드파티 로그인을 쓰는 앱에 대해 로그인 옵션 요건을 심사 지침에 두고 있어요. 다만 그 조항의 문구가 개정을 거쳐 왔고 적용 예외도 있어서, 우리 앱에 애플 로그인이 필수인지는 착수 시점의 App Store Review Guidelines 원문으로 확인해야 합니다. 심사 절차 전반의 흐름은 앱스토어 심사 절차를 정리한 글에 따로 적어뒀어요.

발주 관점에서 중요한 건 조항 자체가 아니라 언제 알게 되느냐예요. 이 요건을 모르고 카카오 로그인만 붙여 개발을 끝낸 뒤 스토어에 올리면, 심사 반려를 받고 나서야 애플 로그인 연동을 추가하게 됩니다. 그 시점의 추가 작업은 견적 밖이고, 심사 재신청까지 걸리는 시간도 일정 밖이에요.

그래서 iOS 앱이 계획에 있다면 킥오프에서 이 질문을 먼저 던지세요. "우리가 붙일 소셜 로그인 목록을 기준으로 애플 로그인이 필수인지 아닌지, 판단 근거가 되는 심사 지침 조항 번호와 원문 링크를 알려달라." 개발사가 이 질문에 문서로 답하지 못하면 스토어 심사 경험이 얕다는 신호로 읽어도 됩니다. 킥오프에서 무엇을 확정하고 나와야 하는지는 킥오프 미팅 가이드에 항목별로 정리해뒀어요.

애플 로그인에는 하나 더 붙는 게 있어요. 이메일 가리기 기능 때문에 사용자가 실제 이메일 대신 릴레이 주소를 줄 수 있고, 그 주소로 메일을 보내려면 도메인과 발신 주소를 미리 등록해둬야 합니다. 회원 이메일로 알림을 보내는 서비스라면 이 설정이 빠졌을 때 메일이 나가지 않아요.

소셜 로그인을 여러 개 붙이면 공수가 그만큼 배로 드나요?

배로 들지는 않아요. 첫 번째 제공사를 붙일 때 인증 흐름·세션·회원 테이블·연동 해제 처리 같은 기반이 함께 만들어지기 때문에, 두 번째부터는 같은 기반 위에 제공사별 차이만 얹습니다. 다만 줄어드는 건 개발 공수이고, 심사 절차는 제공사 수만큼 그대로 늘어나요.

그래서 발주자가 실수하기 쉬운 지점이 여기예요. 견적서에는 "소셜 로그인 4종"이 한 줄로 묶여 저렴하게 잡히는데, 일정표에는 네 개의 심사 라인이 필요합니다. 개발 공수가 줄어드는 것과 대기 시간이 줄어드는 것은 다른 얘기예요.

몇 개를 붙일지 정할 때는 기능이 아니라 우리 사용자가 이미 어떤 계정을 쓰고 있는지로 정하세요. 국내 일반 소비자 대상이면 카카오·네이버를, iOS 앱을 낸다면 애플을, 해외 사용자나 B2B 업무 계정을 받는다면 구글을 후보로 놓고 검토하는 식이에요. 목적 없이 개수만 늘리면 심사 라인과 유지보수 대상만 늘어납니다.

런칭 시점에 다 붙일 필요도 없어요. 기반을 만들어두고 제공사 한두 개로 시작한 뒤 나중에 추가하는 방식이 가능한지 개발사에 확인하면, 초기 일정에서 심사 대기를 줄일 수 있습니다. 이런 범위 조정은 MVP 범위를 확정하는 단계에서 하는 게 견적 흔들림이 적어요.

결제(PG) 연동을 시작하려면 어떤 서류가 필요한가요?

PG 연동은 소셜 로그인과 성격이 완전히 달라요. 소셜 로그인은 개발자 콘솔 등록과 검수로 끝나지만, 결제는 돈을 받는 계약이라 사업자 실체를 확인합니다. 개발사가 대신 해줄 수 있는 부분이 적고, 발주자 본인이 준비해야 하는 항목이 많아요.

여기서 일정이 밀리는 이유는 서류가 어려워서가 아니에요. 서류를 준비해야 한다는 걸 개발이 끝난 뒤에 알기 때문입니다. 통신판매업 신고처럼 관할 기관 처리 기간이 필요한 항목이 하나라도 걸리면, 코드가 완성돼 있어도 결제 테스트를 시작할 수 없어요.

아래 표에서도 열의 성격을 밝혀둡니다. 마지막 열 「빠졌을 때 생기는 일」은 공표된 통계가 아니라 발주 현장에서 반복적으로 관찰되는 유형이고, PG사 공식 문서에 그렇게 적혀 있다는 뜻이 아니에요. 실제 처리 방식은 PG사와 계약 조건에 따라 다를 수 있습니다.

표를 이렇게 나눈 이유는 착수 시점 열 때문이에요. 항목 목록만 보면 다 비슷해 보이는데, 실제로는 "지금 당장 시작해야 하는 것"과 "개발이 어느 정도 된 뒤에 해도 되는 것"이 갈립니다. 통신판매업 신고와 사업자 명의 계좌는 앞쪽에, 화면·약관 게시는 개발 중반에 놓으면 대기가 겹치지 않아요.

PG 심사는 사이트의 무엇을 보나요?

PG 심사는 코드를 보지 않아요. 구매자 눈에 보이는 화면을 봅니다. 실제로 무엇을 파는 서비스인지, 값이 얼마인지, 문제가 생기면 어디로 연락하는지, 환불은 어떤 기준으로 되는지가 화면에 있는지를 확인해요.

그래서 순서가 뒤집히면 곤란해집니다. 결제 기능을 먼저 붙이고 나중에 상품 페이지를 만들겠다는 계획은 심사에서 막혀요. 심사 시점에는 결제만 빼고 나머지가 다 보이는 상태여야 합니다. 개발사와 일정을 짤 때 "PG 심사 신청 가능 상태"를 하나의 마일스톤으로 명시해두면 이 순서가 무너지지 않아요.

자주 반려되는 지점은 문서와 표기예요. 환불 규정이 약관 안에 한 줄만 있고 구매 화면에서 안 보이는 경우, 사업자 정보 표기가 푸터에 빠져 있는 경우, 문의 연락처가 이메일 하나뿐인 경우 같은 것들이 보완 요청으로 돌아옵니다. 이건 개발 문제가 아니라 준비 문제라서, 발주자가 미리 챙기면 한 번에 통과할 수 있어요.

미성년자 결제, 정기결제 해지 안내, 청약 철회 안내처럼 업종에 따라 추가로 요구되는 표기도 있어요. 우리 서비스가 어떤 업종으로 등록되는지에 따라 달라지니, PG사 담당자에게 "우리 업종 코드 기준으로 화면에 있어야 하는 표기 목록"을 문서로 받아 개발사에 그대로 전달하는 게 안전합니다.

간편결제를 따로 붙이면 무엇이 늘어나나요?

간편결제 연동은 카드 결제를 붙였다고 자동으로 켜지는 작업이 아니에요. PG사를 통해 묶여서 제공되는 경우도 있고, 제공사와 별도 계약·심사를 거쳐야 하는 경우도 있습니다. 어느 쪽인지에 따라 공수와 대기 시간이 갈리니, 견적 전에 이 질문을 먼저 정리하세요.

발주자가 개발사에 물어볼 문장은 이렇습니다. "우리가 붙일 간편결제 각각에 대해, PG 계약 안에 포함되는지 별도 계약이 필요한지, 별도라면 신청 주체가 누구인지 표로 달라." 답이 표로 오면 그대로 일정표의 심사 라인이 됩니다.

기능 면에서도 차이가 있어요. 결제창이 하나 더 생기는 게 아니라, 취소·부분취소·정기결제 지원 여부가 수단마다 다릅니다. 어떤 수단은 부분취소가 안 되거나 조건이 붙어요. 이걸 모르고 "취소 기능 있음"으로 검수하면, 운영 중에 특정 수단만 취소가 안 되는 상황을 고객센터가 받게 됩니다.

그래서 간편결제를 여러 개 붙일 때는 수단별 지원 기능 대조표를 개발사에 요구하세요. 승인·전체취소·부분취소·정기결제·현금영수증·에스크로 같은 열을 두고 수단별로 채우면, 운영 정책을 그 표에 맞춰 정할 수 있습니다.

정기결제(빌링)는 왜 일반 결제와 별개 견적인가요?

일반 결제는 사용자가 버튼을 누른 그 순간에 승인을 받으면 끝나요. 정기결제는 사용자가 없는 시점에 서버가 알아서 청구합니다. 이 차이 때문에 만들어야 하는 것이 통째로 하나 더 늘어나요.

구체적으로는 카드 정보를 대신하는 빌링키 발급과 보관, 매달 청구를 돌리는 스케줄러, 실패했을 때 재시도 규칙, 재시도도 실패했을 때 서비스 이용을 어떻게 제한할지, 중도 해지·요금제 변경 시 금액을 어떻게 계산할지가 전부 별도 작업입니다. 여기에 결제 실패 안내 메일이나 알림도 붙어요.

정기결제는 계약·심사 측면에서도 조건이 더 붙는 경우가 있어요. 해지 방법을 화면에서 쉽게 찾을 수 있는지, 다음 결제일을 미리 안내하는지 같은 항목이 확인 대상이 됩니다. 구독 서비스를 만들 계획이라면 이 요건을 화면 설계 단계에서 반영해야 나중에 화면을 다시 그리지 않아요.

발주자 관점의 결론은 간단해요. 견적서에 "결제 연동"이라고만 적혀 있으면 정기결제는 안 들어 있다고 보고 물어보세요. 견적서를 항목 단위로 뜯어보는 방법은 따로 정리해뒀는데, 결제는 그 안에서도 한 줄이 여러 작업을 가리는 대표적인 항목입니다.

이 연동들의 비용과 기간은 어느 정도로 잡아야 하나요?

먼저 이 표의 경계를 그어둡니다. 아래 구간은 제공사 심사가 끼는 로그인·결제 연동에 한정한 것이고, 지도·알림·외부 시스템 조회처럼 심사 없이 붙는 일반 API 연동은 견적 구조가 다릅니다. 심사가 없는 연동은 대기 라인이 안 생기는 대신 규격 문서 품질과 테스트 환경 제공 여부가 공수를 좌우해요.

그리고 하나 더 밝혀둘 게 있어요. 아래 표의 금액은 국내 외주 시장의 현장 견적 기준이고 공표 통계가 아니에요. 개발사 규모, 기존 코드 상태, 웹만인지 앱까지인지에 따라 구간 밖으로 나가는 경우도 흔합니다. 우리 프로젝트 견적이 이 구간과 다르다고 해서 틀린 견적이라는 뜻이 아니라, 왜 다른지 물어볼 근거로 쓰는 표예요.

기간은 금액보다 예측이 어렵습니다. 개발 공수는 개발사가 통제하지만 심사 대기는 통제 밖이기 때문이에요. 그래서 기간은 "며칠"로 받지 말고 개발 공수 라인과 심사 대기 라인을 나눠서 받으세요. 제공사별 심사 소요는 공지된 기준이 있는 곳도 있고 없는 곳도 있으니, 개발사에 각 제공사 문서 링크와 함께 현재 기준을 확인해 달라고 요청하는 게 정확합니다.

다시 한번 적어두면, 위 구간은 현장에서 오가는 견적을 정리한 것이고 공인된 평균 견적 통계는 확인되지 않습니다. 그래서 이 표는 답이 아니라 질문지로 쓰는 게 맞아요.

심사 기간을 일정표에 별도 라인으로 잡아야 하는 이유는 무엇인가요?

심사는 개발 작업과 성질이 다릅니다. 개발은 사람을 더 붙이거나 순서를 바꿔 앞당길 수 있지만, 심사는 신청서를 낸 다음부터 우리가 손댈 수 있는 게 없어요. 이 구간을 개발 일정 안에 뭉뚱그려 넣으면, 심사가 하루만 밀려도 그 뒤 작업이 통째로 밀리는데 원인이 어디인지 회의에서 설명이 안 됩니다.

그래서 심사는 별도 라인으로 그립니다. 그리고 각 라인에 신청 가능 조건을 함께 적어요. 조건이 안 갖춰지면 신청 자체가 안 되니, 그 조건이 실제 선행 작업이 됩니다.

이 표의 세 번째 열이 발주자에게 실질적인 부분이에요. 어떤 심사가 밀리면 무엇이 멈추는지를 미리 적어두면, 지연이 생겼을 때 대체 작업을 앞당길지 오픈일을 조정할지 바로 판단할 수 있어요. 마일스톤을 계약서에 어떻게 쓰는지와 일정이 밀렸을 때의 대응 절차를 함께 보면 이 라인들을 계약 문서로 옮길 수 있습니다.

한 가지 더. 심사 대기는 개발사가 통제할 수 없는 구간에서 생깁니다. 계약서의 지연 배상 조항이 "외부 기관 심사 대기"를 어떻게 다루는지 미리 확인해두면, 나중에 책임 소재로 다투지 않습니다.

개발자 계정과 PG 계약의 명의는 누구 이름이어야 하나요?

이건 기술 결정이 아니라 자산 결정이에요. 결론부터 적으면 계정과 계약의 명의는 발주자(사업자) 앞으로 여는 것이 원칙이고, 개발사는 그 계정에 초대받아 작업하는 구조가 맞습니다. 여기서 말하는 명의는 제3자 서비스 계정과 결제 대행 계약이고, 산출물 자체의 소유권·저작권은 별도 조항으로 다룹니다.

개발사 명의로 열면 당장은 편합니다. 서류를 개발사가 챙기고, 설정도 알아서 합니다. 문제는 프로젝트가 끝난 뒤예요. 개발사를 바꾸거나 관계가 끊기면 앱 소유권 이전, PG 계약 승계, 키 재발급을 다시 해야 하고 그 과정에서 서비스가 멈출 수 있어요.

표에서 PG 행을 다시 보면, PG사 정책상 정산 계좌는 가맹점 사업자 명의를 요구하는 것이 일반적이라 타사 명의로 여는 구조는 애초에 잘 성립하지 않습니다. 계약 조건은 PG사마다 다를 수 있으니 신청 전에 해당 PG사의 가맹 신청 안내에서 확인하세요.

애플 개발자 프로그램의 등록 비용과 개인·법인 가입 차이, 명의 결정 기준은 애플 개발자 계정 등록 가이드에 정리해뒀어요. 이 글에서는 로그인·결제 연동이 그 계정에 무엇을 요구하는지만 봅니다. 마찬가지로 도메인·호스팅과 클라우드 콘솔 명의는 클라우드·인프라 인계 가이드가 깊게 다루니, 위 표는 연동 제공사 계정 중심으로 읽고 인프라 쪽은 그 글에서 확인하시면 됩니다.

명의 원칙은 계약서에 한 줄로 넣을 수 있어요. "제3자 서비스 계정 및 결제 대행 계약의 명의는 갑으로 하고, 을은 갑이 부여한 권한 범위에서 사용한다"는 취지의 문장이면 충분합니다. 제3자 서비스 비용과 사전 고지 의무를 계약서에 어떻게 적어야 하는지는 계약서 독소조항 분석에서 함께 확인하세요. 프로젝트 종료 시 어떤 계정과 키를 넘겨받는지는 인수인계 자산 목록에 함께 적어두면 됩니다.

운영 키를 어디에 보관하고 누가 볼 수 있는지도 정해야 해요. 결제 관련 키는 유출되면 금전 피해로 이어지니 보안 점검 항목과 함께 다루는 게 맞습니다.

견적서와 계약서에 무엇이 적혀 있어야 하나요?

결제·로그인 연동은 견적서에서 한 줄로 접히기 쉬운 항목이에요. 그래서 발주자가 항목을 펼쳐달라고 요구해야 합니다. 다음 문장들을 그대로 개발사에 보내면 됩니다.

• 소셜 로그인은 몇 종이고, 각각 심사 신청서를 누가 작성하나요
• 회원 식별 기준(중복 가입·계정 병합·연동 해제) 처리가 견적에 포함되나요
• 결제는 승인만인가요, 전체취소·부분취소·환불 처리까지인가요
• 결제 결과 통지를 우리 서버가 못 받았을 때의 재처리와 대사(장부 대조)가 포함되나요
• 정기결제가 필요하다면 별도 항목으로 분리해 주세요
• PG 심사 신청에 필요한 화면과 문서 중 개발사가 담당하는 범위는 어디까지인가요
• 심사 반려로 인한 재작업은 어떤 조건에서 추가 비용인가요
• 테스트 환경과 운영 환경 전환 작업이 포함되나요

계약서에는 세 가지를 넣습니다. 첫째 명의 원칙, 둘째 심사 대기 구간의 일정 처리 방식, 셋째 연동 검수 기준이에요. 특히 검수 기준은 "결제가 된다"가 아니라 실패 경로까지 포함한 시나리오 목록으로 적어야 나중에 다투지 않습니다. 어떤 시나리오를 적을지는 다음 절의 검수 항목을 그대로 옮겨 쓰면 됩니다.

결제·정산 시스템을 나중에 넘겨받는 절차는 범위가 또 달라요. 운영 단계에서 무엇을 인계받아야 하는지는 결제·정산 시스템 인계 가이드에 따로 정리해뒀습니다. 이 글은 붙이는 단계, 그 글은 넘겨받는 단계로 나눠 보시면 됩니다.

연동 검수는 무엇을 눌러봐야 하나요?

연동 검수에서 자주 벌어지는 일은 정상 경로만 확인하고 끝내는 거예요. 로그인 되고 결제 되면 통과시키는데, 운영에서 문제가 되는 건 실패 경로입니다. 실패 경로는 개발사도 테스트하기 번거로워서 검수 목록에 없으면 안 해보는 경우가 있어요.

발주자가 직접 눌러볼 목록은 이렇습니다. 소셜 로그인 쪽에서는 같은 이메일로 다른 제공사 가입, 연동 해제 후 재가입, 제공사 쪽에서 앱 연결을 끊은 뒤 재로그인, 이메일을 제공하지 않는 계정으로 가입을 확인하세요.

결제 쪽에서는 결제창을 중간에 닫기, 카드 한도 초과로 실패, 승인 직후 취소, 부분취소, 취소한 주문의 상태 표시, 결제는 됐는데 우리 서버가 결과 통지를 못 받은 상황에서의 복구를 확인합니다. 마지막 항목이 운영에서 성가신 사고로 이어지는데, 사용자는 돈이 나갔는데 주문이 없는 상태가 되기 때문이에요.

검수는 개발사가 시연하는 자리가 아니라 발주자가 눌러보는 자리여야 합니다. 검수 항목을 문서로 만들고 통과 여부를 서명으로 남기는 절차는 산출물 검수·사인오프 가이드에 정리돼 있어요. 이 글이 다루는 건 연동 실패 경로 시나리오까지이고, 출시 전에 확인해야 할 전체 테스트 범위는 QA·테스트 체크리스트에서 이어서 보시면 됩니다.

발주자가 자주 오해하는 것은 무엇인가요?

첫째, "소셜 로그인은 무료니까 비용이 안 든다"는 오해예요. 로그인 기능 자체에 제공사 이용료가 붙지 않는 경우가 많다는 것과, 우리 서비스에 붙이는 공수가 없다는 것은 다른 얘깁니다. 회원 체계 설계가 그 안에 들어 있어요. 그리고 부가 기능이나 발송량에 따라 별도 과금이 생기는 항목도 있으니, 이용료 여부는 제공사 요금 안내에서 확인하세요.

둘째, "PG를 붙이면 결제가 끝난다"는 오해입니다. 결제는 승인·취소·정산·대사·세금 처리로 이어지는 흐름이고, PG 연동은 그중 앞부분이에요. 정산 내역을 확인할 관리자 화면이 없으면 운영 첫 달에 엑셀로 대조하게 됩니다.

셋째, "심사는 개발사가 알아서 한다"는 오해예요. 신청서 작성은 도와줄 수 있지만 사업자 서류와 사업 내용 설명은 발주자가 냅니다. 이 구분을 킥오프에서 문서로 나눠두면 서로 기다리다 일정을 버리는 일이 줄어요.

넷째, "나중에 다른 PG로 바꾸면 된다"는 오해입니다. 바꿀 수는 있지만 결제 코드와 주문 상태 처리가 PG 규격에 맞춰져 있어서 재작업이 따라와요. 처음부터 결제 로직을 우리 서비스 안에 두고 PG 연동 부분만 얇게 분리해달라고 요구하면 나중 교체 비용이 줄어듭니다. 이 요구는 견적 단계에서 해야 반영돼요.

포텐랩과 트리숲, 어느 쪽이 맞나요?

가르는 질문은 하나예요. 만들려는 것이 서비스인가, AI 자체인가.

로그인과 결제를 붙여 사용자에게 파는 서비스를 만드는 거라면 포텐랩이 맡는 영역이에요. 앱과 웹 프로덕트를 발주자 관점에서 설계하고, 심사 라인까지 포함한 일정으로 굴리는 일입니다. 포텐랩은 자체 집계 기준으로 97% 수행완수율을 유지하고 있어요.

반대로 AI 챗봇이나 RAG처럼 AI 자체가 제품인 경우라면 트리숲(TreeSoop)이 맞습니다. 이 경우에도 로그인과 결제는 필요하지만, 프로젝트의 무게 중심이 모델·검색·평가 쪽에 있어서 다루는 사람이 달라요.

맞지 않는 쪽으로 보내는 게 서로에게 손해라서 기준을 먼저 적었어요. 판단이 애매하면 만들려는 화면 목록을 들고 오시면 됩니다. 화면 목록만 봐도 어느 쪽 일인지 대체로 갈립니다. 결제가 들어가는 프로덕트의 초기 범위를 잡는 방법은 MVP 개발 가이드에 정리해뒀어요.

자주 묻는 질문

소셜 로그인 연동에는 비용이 얼마나 드나요?

국내 외주 시장의 현장 견적 기준으로 첫 1종은 80만~250만 원, 추가 1종은 40만~120만 원 구간에서 오갑니다. 첫 종에 인증 흐름·세션·회원 테이블 설계가 함께 들어가기 때문에 두 번째부터는 개발 공수가 줄어요. 다만 이 금액은 공표 통계가 아니라 현장 견적 범위이고, 심사 대기 시간은 제공사 수만큼 그대로 늘어납니다.

카카오 로그인 연동을 하면 사용자 이메일도 바로 받아올 수 있나요?

자동으로 되지는 않습니다. 로그인만 하는 것과 이메일·전화번호 같은 정보를 함께 받아오는 것은 다른 절차로 취급돼서, 왜 그 정보가 필요한지 근거를 적어 신청하고 승인을 받아야 켜집니다. 개인정보 처리방침에 해당 항목이 적혀 있어야 심사가 진행되니 문서를 먼저 준비해두세요. 요구 항목은 정책에 따라 바뀌니 착수 시점에 카카오 공식 개발자 문서에서 현재 기준을 확인하는 게 정확합니다.

PG 결제 연동을 하려면 사업자등록증 말고 무엇이 더 필요한가요?

통신판매업 신고증, 대표자 신분 확인 서류(법인이면 법인 서류), 사업자 명의 정산 계좌, 접속 가능한 서비스 URL과 화면, 이용약관·개인정보 처리방침·환불 규정, 화면상의 사업자 정보 표기가 함께 필요합니다. 통신판매업 신고는 관할 기관 처리 기간이 있어서 개발이 끝난 뒤에 시작하면 그만큼 결제 테스트가 밀려요. 서류 준비는 개발과 병행해 앞쪽에 배치하는 편이 안전합니다.

개발자 계정과 PG 계약은 개발사 명의로 열어도 되나요?

발주자(사업자) 명의로 여는 것이 원칙이고, 개발사는 그 계정에 초대받아 작업하는 구조가 맞습니다. PG사 정책상 정산 계좌는 가맹점 사업자 명의를 요구하는 것이 일반적이라 타사 명의로 여는 구조는 애초에 잘 성립하지 않고, 앱스토어·플레이 콘솔은 개발사 명의로 열면 나중에 이전 절차와 시간이 듭니다. 계약서에 명의 원칙을 한 줄로 넣고 인수인계 목록에 계정과 키를 함께 적어두세요.

심사 기간을 개발 일정에 포함시키면 안 되는 이유가 무엇인가요?

개발은 사람을 더 붙이거나 순서를 바꿔 앞당길 수 있지만, 심사는 신청한 뒤 우리가 손댈 수 있는 게 없기 때문입니다. 두 구간을 한 줄로 묶으면 심사가 밀렸을 때 원인이 어디인지 설명이 안 되고 뒤 작업이 통째로 밀려요. 심사는 별도 라인으로 그리고 각 라인에 신청 가능 조건을 함께 적어두면 무엇이 선행 작업인지 분명해집니다.

정기결제(구독)는 일반 결제 연동에 포함되나요?

별개 항목으로 보는 것이 맞습니다. 빌링키 발급과 보관, 청구 스케줄러, 결제 실패 시 재시도 규칙, 실패가 이어질 때의 이용 제한, 중도 해지·요금제 변경 시 금액 계산이 모두 추가 작업이에요. 견적서에 결제 연동이라고만 적혀 있으면 정기결제는 포함되지 않았다고 보고 별도 항목으로 분리해 달라고 요청하세요.

함께 읽으면 좋은 글

• API 연동 개발의 비용 구조
• 기능명세서 양식과 한 행에 넣을 항목
• 소스코드 소유권과 저작권 양도 조항