연동 견적, 테스트 환경·상대사 협의 비용은 누가 낼까요
연동 견적서에 줄로 안 잡히는 일은 테스트 서버·테스트 계정·상대사 심사·운영 전환 재검증이에요. 카드사 심사는 계약 후 최대 10～14영업일, 알림톡 템플릿 검수는 평균 2～3영업일이 걸려요. 누가 준비하고 누가 비용을 지는지 계약 문장 6가지로 정리했어요.
먼저 짧게 답부터 드릴게요. 연동 견적서에는 “결제 연동 1식”처럼 개발 작업만 한 줄로 잡히고, 그 앞뒤의 일은 빠지기 쉬워요. 상대 시스템의 테스트 서버 확보, 테스트 계정과 데이터 준비, 상대사 담당자와의 회의와 답변 대기, 심사·승인, 운영 전환 뒤 재검증이에요. 이 일들을 누가 준비하고 누가 비용을 지는지 견적서와 계약서에 문장으로 남겨 둬야 추가 청구나 오픈 지연으로 번지지 않아요. 직접 만들고 운영해 본 개발사 기준으로 정리했어요.
“개발은 다 끝났다면서요. 그런데 왜 오픈을 못 해요?”
결제나 알림이 붙은 프로젝트 막바지에 발주 담당자에게서 자주 듣는 말이에요. 코드는 끝났는데 카드사 심사가 아직이거나, 알림톡 템플릿이 반려됐거나, 상대사가 운영 서버 접속을 아직 열어 주지 않은 상태예요. 따져 보면 견적서 어디에도 이 일들의 줄이 없었어요.
연동 난이도와 검증 기간은 기존 시스템 연동이 있으면 왜 더 어려워질까요에서, 매달 나가는 사용료는 외부 서비스 연동 비용, 개발비는 줄고 운영비는 늘까요에서 다뤘어요. 이 글은 그 사이에 끼어 있는 일만 따로 봐요. 견적서에 줄로 안 잡히는 준비·협의·심사예요.
1. 연동 견적서에 줄로 안 잡히는 일은 무엇일까요
개발사가 견적을 낼 때 셀 수 있는 건 우리 쪽 코드예요. 화면이 몇 개인지, 상대 API(시스템끼리 데이터를 주고받는 통로)를 몇 번 부르는지, 실패하면 어떻게 처리할지까지는 계산이 돼요. 그런데 연동은 상대가 있는 일이라 우리 코드 바깥에서도 시간이 흘러요. 그 시간이 견적서에 안 보이면 결국 누군가 떠안게 돼요.
자사 실무 기준 예시 — 연동 견적서에서 자주 빠지는 일 6가지
| 빠지기 쉬운 일 | 주로 누가 준비하나요 | 안 정해 두면 생기는 일 |
|---|---|---|
| ① 상대 시스템의 테스트 서버·샌드박스 | 상대사(요청은 발주사) | 운영 환경에서 바로 시험해 실제 결제·발송이 나가요 |
| ② 테스트 계정·테스트 데이터 | 발주사와 상대사 | 계정 발급을 기다리느라 개발이 멈춰요 |
| ③ 상대사 회의·문의 답변 | 창구는 발주사, 실무는 개발사 | 기다린 시간이 공수로 청구되거나 일정이 밀려요 |
| ④ 상대사 심사·승인 | 발주사 명의로 신청 | 코드는 끝났는데 오픈을 못 해요 |
| ⑤ 운영 전환 뒤 재검증 | 개발사와 발주사 | 테스트에선 되던 결제가 운영에서 실패해요 |
| ⑥ 상대사 교체·규격 변경 재작업 | 계약에 따라 달라요 | 하자보수인지 추가 개발인지 다툼이 생겨요 |
(자사 실무 기준 예시예요. 특정 고객사 사례가 아니에요.)
가운데 칸을 보세요. 상당수가 발주사 쪽 준비물이에요. 결제대행사(PG, 카드 결제를 대신 처리해 주는 회사) 계약이나 카카오 비즈니스 채널, 공공기관 승인 신청은 서비스를 운영할 회사의 사업자 명의로 해야 하는 경우가 많아서예요. 개발사가 대신 해 줄 수 없으니, 견적서에 “발주사 준비”라고 적혀 있지 않으면 착수하고 나서야 알게 돼요.
개발외주비용을 비교할 때도 이 여섯 줄이 있는 견적과 없는 견적은 같은 기준이 아니에요. 없는 쪽이 싸 보여도 빠진 일이 없어지지는 않거든요. API 연동 자체가 견적을 어떻게 키우는지는 API 연동이 무엇이고 왜 견적을 크게 바꿀까요에, 견적이 낮게 나오는 다른 이유는 저가 견적의 함정은 어디에 숨어 있을까요에 정리해 뒀어요.
2. 상대 시스템에 테스트 서버가 없으면 무엇이 달라질까요
시험을 실제 운영 환경에서 해야 해요. 테스트 서버(샌드박스)가 있으면 돈이 오가지 않는 상태로 성공·실패·취소를 몇 번이고 돌려 볼 수 있어요. 없으면 시험 한 번 한 번이 진짜 결제, 진짜 문자, 진짜 데이터 변경이 돼요.
국내 주요 결제·메시지·로그인 서비스는 다행히 테스트 환경을 공개적으로 줘요. 다만 테스트 환경이 있다는 것과 거기서 전부 확인할 수 있다는 건 다른 얘기예요. 공식 문서에도 그 차이가 적혀 있어요.
공식 외부 기준 — 테스트 환경에서 확인할 수 있는 범위
| 서비스 유형 | 테스트 환경에서 되는 것 | 테스트 환경에서 안 되는 것 |
|---|---|---|
| 결제대행(토스페이먼츠 예) | 가입 전에도 테스트 API 키로 결제창 연동 준비, 실제 결제는 일어나지 않음 | 추가 계약한 간편결제 수단은 테스트 API에서 확인 불가 |
| 카카오 로그인 | 테스트 앱에서 기능을 먼저 써 볼 수 있음 | 테스트 앱에서 쓰던 추가 기능을 원본 앱에서 쓰려면 원본 앱에서 별도 검수 필요 |
| 알림톡(카카오 비즈메시지) | 템플릿 등록과 검수 요청 | 검수가 끝난 템플릿만 발송에 사용 가능 |
| 공공데이터포털 오픈API | 자동승인 데이터는 신청과 동시에 사용 | 심의승인 데이터는 제공기관 담당자 승인 후 사용 |
(출처: 토스페이먼츠 공식 블로그 ‘API 키 확인하기’(2024년 8월 게시)·‘카드사 심사 통과 체크리스트’(2026년 10월 게시), 카카오 디벨로퍼스 카카오싱크 사전 준비 문서, 네이버 클라우드 SENS 알림톡 템플릿 문서, 공공데이터포털 이용가이드. 모두 2026년 10월에 확인했어요.)
사내 시스템이나 협력사 시스템은 사정이 더 나빠요. 테스트 서버 없이 운영 서버 하나만 있는 경우가 흔하거든요. 이때 고를 수 있는 길은 세 가지예요.
- 상대사에 테스트 서버를 만들어 달라고 요청해요. 상대사 작업이라 별도 비용이 붙을 수 있고, 그 견적은 상대사에게 따로 받아야 해요.
- 우리 쪽에 가짜 상대(모의 서버)를 만들어 시험해요. 개발 공수가 늘어나는 대신 상대 일정에 덜 묶여요.
- 운영 서버에서 시험용 데이터를 정해 놓고 조심스럽게 시험해요. 돈은 덜 들지만, 시험 데이터를 어떻게 지우고 되돌릴지 미리 합의해야 해요.
어느 길이든 견적서에 무엇을 전제로 했는지 한 줄은 있어야 해요. 개발사는 1번을 전제로 계산했는데 실제로 2번을 하게 되면 그 차이가 추가 청구로 돌아와요. 우리 쪽 서버를 개발·스테이징·운영으로 나누는 이야기는 개발·스테이징·운영 서버, 왜 여러 개가 필요할까요에 따로 있어요.
용어 정리 — 샌드박스는 실제 결제나 발송이 일어나지 않는 상대사의 시험용 환경이에요. 테스트 키·라이브 키는 같은 서비스에 들어가는 열쇠를 시험용과 실제용으로 나눠 둔 것이고요. 운영 전환은 시험용 열쇠와 주소를 실제용으로 바꿔 끼우는 순간을 말해요. 실무에선 “샌드박스에선 다 통과했고, 라이브 키 나오면 전환할게요”처럼 말해요.
3. 테스트 계정·테스트 데이터는 누가 준비해야 할까요
계정은 발주사가, 데이터는 발주사와 개발사가 나눠서 준비하는 경우가 많아요. 상대 서비스에 가입하고 계약하는 주체가 대개 발주사이기 때문이에요.
심사용 계정도 여기 들어가요. 토스페이먼츠 안내를 보면 회원만 쓸 수 있는 쇼핑몰(폐쇄몰)은 카드사 심사 때 테스트 계정 아이디와 비밀번호를 계약 담당자에게 넘기거나 결제 경로 파일을 따로 만들어야 해요. 심사하는 쪽도 결제 화면까지 들어가 봐야 하니까요. 이 계정을 누가 만들고 누가 넘기는지 정해 두지 않으면 심사가 계정 하나 때문에 멈춰요.
자사 실무 기준 예시 — 테스트 준비물 나누기
| 준비물 | 발주사 | 개발사 | 상대사 |
|---|---|---|---|
| 상대 서비스 가입·계약(사업자 명의) | 신청 | 필요 서류 안내 | 승인·발급 |
| 테스트 계정·테스트 키 | 받아서 전달 | 연동에 사용 | 발급 |
| 시험용 데이터(가짜 회원·주문) | 형식 확인 | 만들어 넣기 | 데이터 형식 문서 제공 |
| 실제 데이터 샘플 | 개인정보를 지우거나 바꿔서 제공 | 형식 검증 | — |
| 심사용 계정(회원 전용 서비스) | 승인 | 만들어 전달 | 심사에 사용 |
(자사 실무 기준 예시예요. 실제 역할은 계약으로 정해요.)
실제 데이터 샘플은 특히 조심해야 해요. 상대 시스템이 주는 형식을 맞춰 보려면 진짜 데이터가 가장 정확한데, 그대로 넘기면 개인정보가 개발 환경으로 흘러가요. 이름과 연락처를 지우거나 바꾼 샘플 몇 건이면 형식 확인에는 충분해요.
붙는 상대가 많을수록 이 표의 줄도 늘어나요. CRM(고객 관리 시스템) 개발 비용을 유형별로 견줄 때 금액 차이가 크게 나는 지점도 여기예요. 문자·알림톡·결제·회계 프로그램처럼 붙는 곳이 하나 늘 때마다 계정과 시험 데이터를 받아 올 곳도 하나씩 늘어나요.
4. 상대사 심사·승인은 얼마나 걸릴까요
심사 기간은 개발 기간이 아니라 달력 기간이에요. 개발자가 손을 놓고 있어도 날짜는 흘러가요. 반려되면 다시 세고요. 그래서 개발 일정과 겹치게 미리 신청해 두는 게 핵심이에요.
공식 외부 기준 — 연동에서 자주 만나는 심사·승인 절차
| 절차 | 공개된 기간·조건 | 함께 볼 점 |
|---|---|---|
| 카드사 심사(PG 가입) | 계약 완료 후 최대 10～14영업일, 카드사 9곳이 각자 심사 | 500만 원 이상 고가 상품은 3～4영업일이 더 걸릴 수 있음 |
| 알림톡 템플릿 검수 | 평균 2～3영업일(주말·공휴일 제외) | 반려되면 고쳐서 재검수, 검수 완료 뒤엔 수정·삭제 불가 |
| 공공데이터포털 오픈API 심의승인 | 신청 후 보통 2～3일 | 자동승인 데이터는 신청과 동시에 승인 |
| 카카오 로그인 비즈니스 채널·추가 동의항목 | 심사 필요, 기간은 공식 문서에 없음 | 비즈 앱 전환 자체는 심사가 없음 |
| 행정정보 공동이용 | 행정안전부 공동이용센터가 신청을 심사·승인, 처리 기간은 확인 못 함 | 공공기관 시스템과 붙는 사업이면 착수 전에 확인 |
(출처: 토스페이먼츠 ‘카드사 심사 통과 체크리스트’(2026년 10월 6일 게시), 네이버 클라우드 SENS 알림톡 템플릿 문서, 공공데이터포털 이용가이드, 카카오 디벨로퍼스 카카오싱크 사전 준비 문서, 행정안전부 행정정보 공동이용 안내. 모두 2026년 10월에 확인했어요. 기관마다 바뀔 수 있으니 실제 일정은 각 안내를 다시 확인하세요.)
계산해 보면 감이 와요. 카드사 심사 14영업일은 주말을 끼면 달력으로 약 3주예요. 게다가 계약이 끝난 뒤부터 세니까 PG 계약을 개발 막바지에 하면 오픈이 그만큼 밀려요. 알림톡도 템플릿이 한 번 반려되면 평균 2～3영업일이 한 번 더 붙어요.
심사를 받으려면 화면도 먼저 준비돼 있어야 해요. 같은 안내에 따르면 카드사 심사에는 즉시 구매할 수 있는 상품이 최소 1개, 배송·환불 정책, 사업자등록증과 일치하는 하단 정보가 필요하고, 통신판매업 신고번호가 없으면 국민카드 심사에서 빠져요(간이과세자·비영리기관·공공기관은 예외). 그래서 저희는 결제가 있는 사업이면 상품 화면과 하단 정보를 먼저 만들어 심사를 걸어 두고, 나머지 기능은 심사가 도는 동안 만드는 순서를 권해요. 앱 개발 외주 비용을 견적받을 때 결제가 들어간다면 일정표에 “카드사 심사 대기”가 있는지부터 보세요.
금융 쪽은 더 길 수 있어요. 2019년 오픈뱅킹 도입 당시 금융위원회 자료를 보면 핀테크 기업은 금융결제원의 이용적합성 승인을 받은 뒤 기능 테스트와 보안점검을 거쳐야 서비스를 열 수 있었어요. 지금 절차는 확인하지 못했으니(미검증), 금융 오픈API가 끼는 사업이라면 해당 기관에 직접 확인해 일정에 넣어야 해요.
5. 상대사 회의와 답변 대기는 어떻게 비용이 되나요
기다리는 시간도 투입이에요. 인력 단가(MM, 한 사람이 한 달 일하는 양)로 견적을 냈다면 상대사 답을 기다리는 동안에도 그 인력은 이 프로젝트에 묶여 있어요. 고정가라면 개발사가 그 시간을 떠안아요. 그러면 다음 견적부터 여유분이 붙고요. 어느 쪽이든 발주자가 내는 돈에 섞여 들어가요.
숫자로 보면 단순해요. 개발자 2명이 상대사 답을 2주 기다리면 약 1MM이 일정에서 그냥 사라져요. 견적서의 월 단가를 곱하면 그게 금액이에요.
그래서 회의와 문의는 횟수와 기한으로 묶어 두는 게 좋아요.
자사 실무 기준 예시 — 상대사 협의를 견적서에 적는 법
| 항목 | 견적서·과업지시서에 적는 예 |
|---|---|
| 협의 창구 | 상대사와의 첫 연락은 발주사 담당자가 열고, 기술 문의는 개발사가 직접 해요 |
| 포함 회의 수 | 상대사와의 연동 협의 회의 ○회 포함, 넘으면 회당 협의 |
| 답변 기한 | 상대사 답변이 ○영업일 넘게 없으면 발주사에 알리고 일정 조정을 협의 |
| 멈춘 기간 처리 | 상대사 사유로 멈춘 기간은 일정에서 빼고, 인력 재배치 여부를 함께 정함 |
| 기록 | 상대사와 합의한 규격·변경은 회의록으로 남겨 양쪽이 확인 |
(자사 실무 기준 예시예요. 숫자는 사업마다 정해요.)
상대가 회사가 아니라 장비일 때도 있어요. 장비 제조사의 프로그램과 붙는 GUI 소프트웨어(화면을 갖춘 설치형 프로그램) 외주 개발이 그래요. 저희가 캐논코리아 카메라 펌웨어 업데이트 유틸리티를 Windows·Mac용으로 만들 때 가장 큰 부담은 다양한 펌웨어 버전과 장치 조합을 테스트하는 일이었어요. 이런 사업에서는 시험할 장비를 누가, 몇 대, 언제까지 빌려주는지가 일정을 정해요. 견적서에 장비 대여 조건이 없으면 그 줄부터 물어보세요.
운영사 Tip 저희는 착수 첫 주에 상대사별 준비물 표를 발주 담당자와 같이 채워요. 빈칸이 곧 일정 위험 목록이거든요. 빈칸이 많은 연동일수록 개발 순서를 뒤로 미루지 않고 오히려 맨 앞에 둬요. 상대가 늦을수록 먼저 두드려 놔야, 답을 기다리는 동안 다른 기능을 만들 수 있어요.
6. 테스트를 통과했는데 운영 전환 때 또 무엇을 확인하나요
테스트 환경과 운영 환경은 서로 다른 서버예요. 열쇠와 주소를 바꿔 끼우는 순간, 테스트에선 안 보이던 조건이 나타나요. 이것도 공식 문서에 적혀 있어요.
- 토스페이먼츠는 라이브 API에서는 심사가 끝난 결제수단만 보이고, 심사가 끝나지 않은 카드사로는 결제가 실패할 수 있다고 안내해요. 테스트에서 모든 카드가 통과해도 운영 첫날엔 일부 카드사만 될 수 있다는 뜻이에요.
- 같은 안내에서 연동할 상점 아이디가 계약 완료 상태인지 확인하라고 해요. 심사 중이거나 계약이 취소된 아이디가 기본값으로 잡혀 있는 경우가 있대요.
- 카카오 로그인은 테스트 앱에서 쓰던 추가 기능을 원본 앱에서 쓰려면 원본 앱에서 따로 검수를 받아야 해요.
- 알림톡 템플릿은 검수가 끝나면 수정도 삭제도 안 돼요. 발송에 한 번도 안 쓴 템플릿만 승인을 취소해 되돌릴 수 있어서, 이미 쓰고 있는 문구를 고치려면 새 템플릿으로 다시 검수받아야 해요.
그러니 운영 전환은 “키만 바꾸면 끝”이 아니라 일정에 따로 잡는 작업 단계예요.
자사 실무 기준 예시 — 운영 전환 재검증 항목
| 항목 | 확인 방법 | 비용은 누가 |
|---|---|---|
| 실제 결제 1건과 취소 1건 | 소액 상품을 결제한 뒤 바로 취소 | 결제는 발주사 카드로, 작업은 개발사 |
| 결제수단별 동작 | 심사가 끝난 카드사와 간편결제부터 하나씩 | 개발사 |
| 알림 실제 발송 | 내부 직원 번호로 발송 확인 | 발송 요금은 발주사 |
| 상대 서버 접속 허용 | 운영 서버 주소(IP)를 상대사에 등록했는지 | 요청은 발주사, 등록은 상대사 |
| 결과를 받는 주소(콜백) | 운영 도메인으로 바뀌었는지 | 개발사 |
(자사 실무 기준 예시예요. 상대 서비스마다 항목이 달라요.)
기업을 위한 AI·생성형 AI 개발 외주도 같은 구조예요. 시험 단계에선 개발사 계정의 키로 돌리다가, 운영으로 넘어갈 때 발주사 명의의 키와 사용량 한도로 바꿔야 해요. 이 전환을 언제 누가 하는지 정해 두지 않으면 오픈 직전에 사용량 한도에 걸리거나 사용료 청구서가 엉뚱한 회사로 가요.
7. 연동 범위는 계약서에 어떤 문장으로 남길까요
1～6장에서 본 일들은 계약서 별첨이나 과업지시서에 문장으로 옮겨야 착수 뒤에도 남아요. 회의 자리에서 말로 합의한 건 담당자가 바뀌면 사라지기 쉬워요.
자사 실무 기준 예시 — 계약서·과업지시서에 넣을 문장 6가지
- 연동 대상 목록 — 연동 대상은 별첨 목록의 ○개 서비스로 하며, 목록에 없는 연동은 별도로 협의한다.
- 준비 주체 — 상대 서비스 가입·계약·심사 신청은 발주사 명의로 하고, 개발사는 필요한 서류 안내와 심사용 화면 준비를 지원한다.
- 테스트 환경 전제 — 견적은 상대사가 테스트 환경을 제공한다는 전제로 산정했으며, 제공되지 않으면 모의 서버 구축 등 대안과 비용을 다시 협의한다.
- 멈춘 기간 — 상대사 사유로 연동 작업이 ○영업일 넘게 멈추면 그 기간은 일정에서 제외하고, 투입 인력 운영을 협의한다.
- 운영 전환 — 운영 전환과 재검증(실결제·실발송 확인)은 개발 범위에 포함하며, 여기에 드는 결제·발송 실비는 발주사가 부담한다.
- 상대사 교체 — 오픈 뒤 상대사 교체나 상대 규격 변경에 따른 수정은 하자보수가 아니라 유지보수 또는 추가 개발로 보고, 범위와 금액을 따로 정한다.
(자사 실무 기준 예시 문구예요. 실제 계약서는 법무 검토를 거쳐 정하세요.)
3번과 6번이 다툼이 가장 잦은 자리예요. 3번이 없으면 “테스트 서버가 없을 줄 몰랐다”는 말이 서로에게서 나오고, 6번이 없으면 오픈 몇 달 뒤 PG를 바꿀 때 그 작업이 무상 하자보수인지를 두고 다시 만나게 돼요. 공공 SI(시스템 구축 사업)라면 이 문장들은 과업지시서로 들어가요. 도급 구조와 대가 산정이 어떻게 맞물리는지는 SI 개발 비용, 도급 구조부터 봐야 하는 이유에 정리해 뒀어요.
흔한 실수 “연동 1식”에 심사까지 들어 있다고 믿는 거예요. 같은 줄을 두고 개발사는 코드를, 발주사는 오픈을 떠올려요. 다른 하나는 PG 계약을 개발이 끝난 뒤로 미루는 거예요. 카드사 심사는 계약이 끝나야 시작되니(최대 10～14영업일), 그만큼 오픈이 고스란히 밀려요.
8. 상대사가 바뀌면 처음부터 다시 도는 일은 무엇일까요
상대사는 오픈한 뒤에도 바뀌어요. 수수료 때문에 PG를 옮기기도 하고 메시지 대행사를 바꾸기도 해요. 상대 시스템이 새 버전으로 올라가는 일도 있고요. 그때마다 1～6장에서 본 일이 다시 돌아요. 새 테스트 계정, 새 심사, 새 운영 전환 재검증이에요.
그래서 저희는 연동 부분을 만들 때 상대사가 바뀌어도 고칠 곳이 한 군데에 모이도록 나눠 두는 편이에요. 연동 코드가 화면 곳곳에 흩어져 있으면 상대사 하나 바꾸는 일이 프로젝트 하나만큼 커져요. 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각하는데, 연동에서는 그 차이가 상대가 바뀌는 날 드러나요.
현장 장비가 끼면 상대가 회사 하나가 아니에요. 롯데백화점 수원 푸드홀 실시간 혼잡도 관리 시스템은 캐논코리아와 컨소시엄으로 함께 수행했고, 센서는 캐논코리아가 제공했어요. 보안 요건 때문에 내부·사설 네트워크로 구성해야 했고요. 장비와 접속 환경을 쥔 쪽이 따로 있으면 시험 일정도 그쪽과 같이 짜야 해요. 견적서의 “협의 회의” 줄이 형식이 아니라 실제 일정이 되는 이유예요.
자체 SaaS 4종을 직접 운영하면서 배운 것도 같은 결이에요. 외부 서비스는 우리 일정과 상관없이 바뀌니까 바뀌었을 때 다시 해야 할 일의 목록을 처음부터 알고 있는 게 운영 비용을 줄여요. 견적 전체에서 연동이 어느 자리에 있는지는 B2B 소프트웨어 개발 외주 비용, 얼마나 들까요에서, 출시 첫해에 따로 나오는 비용은 앱 견적서에 없던 비용, 출시 첫해에 나와요에서 함께 보시면 좋아요.
받아 둔 연동 견적서에 이 여섯 줄이 있는지 판단이 안 서신다면 붙여야 할 상대사 목록만 들고 오셔도 괜찮아요. 어느 칸이 발주사 준비이고 어느 칸이 개발 범위인지부터 같이 나눠 볼 수 있어요. 저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해 온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 연동 견적의 빈 줄, 같이 채워 봐요 →
9. 자주 묻는 질문 (FAQ)
연동 상대사가 테스트 서버를 주지 않으면 견적을 어떻게 잡아야 하나요?
견적서에 어떤 방법을 전제로 계산했는지 한 줄로 적어 달라고 하세요. 상대사에 테스트 서버를 요청하면 상대사 작업비가 따로 붙을 수 있고, 개발사가 모의 서버를 만들면 개발 공수가 늘어요. 운영 서버에서 시험한다면 시험 데이터를 어떻게 정리할지 미리 합의해야 하고요. 전제가 적혀 있으면 나중에 방법이 바뀌어도 추가 비용을 다툼 없이 정할 수 있어요.
AI 개발 외주는 기획부터 검수까지 어떻게 맡기나요? 외부 AI API를 붙이면 무엇을 더 정해야 하나요?
기획, 데이터 준비, 연동, 평가, 검수를 단계로 나눠 맡기는 게 기본이에요. 외부 AI API가 들어가면 두 가지를 더 정해요. 시험 단계에서 누구 명의의 키와 사용량으로 돌릴지, 그리고 운영으로 넘어갈 때 발주사 명의 계정으로 언제 바꿀지예요. 검수 단계에는 운영 키로 다시 확인하는 재검증을 넣어 두세요. 시험 설정에서 되던 것이 운영 설정에서 다르게 움직이는 일이 있어요.
카드사 심사는 개발이 다 끝난 뒤에 신청해야 하나요?
그럴 필요 없어요. 토스페이먼츠 안내를 보면 카드사 심사는 계약 완료 후 최대 10～14영업일이 걸리고, 심사 때 즉시 구매할 수 있는 상품과 배송·환불 정책, 사업자 정보가 담긴 하단 정보가 필요해요. 이 화면부터 만들어 심사를 걸어 두고 나머지 기능은 심사 기간에 개발하면 오픈이 덜 밀려요. 결제창 연동은 가입 전에도 테스트 API 키로 준비할 수 있어요.