결제·정산 시스템 외주 견적은 ‘PG 연동’ 한 줄로 비교하면 거의 항상 누락이 생깁니다. 예약·커머스·중개·SaaS 서비스라면 주문 생성, 결제 승인, 웹훅, 취소·부분취소, 판매자 정산, 세금증빙, 관리자 화면, 대사, 장애 재처리까지 항목을 쪼갠 뒤 PG 직접 연동·통합 결제 모듈·커스텀 정산 개발 중 하나를 선택해야 합니다. MVP는 통합 결제 모듈과 최소 정산표로 시작하고, 여러 판매자에게 돈을 나누어 지급하는 플랫폼은 처음부터 정산 원장과 대사 범위를 견적에 포함하는 편이 안전합니다.
1. 먼저 고를 것: PG 직접 연동, 통합 결제 모듈, 커스텀 정산
결제 견적의 첫 질문은 어떤 PG가 좋은가가 아니라 ‘우리 서비스가 돈을 어떻게 받고, 누가 누구에게 얼마를 지급하는가’입니다. 토스페이먼츠 같은 PG를 직접 붙일 수도 있고, 포트원 같은 통합 결제 모듈을 통해 여러 결제수단을 관리할 수도 있으며, 플랫폼형 서비스는 별도 정산 원장과 대사 화면을 커스텀 개발해야 할 수 있습니다.
| 선택지 | 적합한 경우 | 견적서에 보여야 할 항목 | 주의할 점 |
|---|---|---|---|
| PG 직접 연동 | 단일 사업자, 단일 PG, 결제수단이 명확한 쇼핑몰·예약 서비스 | 결제창 또는 SDK, 결제 승인 API, 주문번호와 결제키 저장, 웹훅, 전액취소·부분취소, 영수증 링크, 운영 로그 | PG를 바꾸거나 복수 PG를 붙일 때 재개발 범위가 커질 수 있습니다. 정산 대사와 관리자 기능은 별도입니다. |
| 통합 결제 모듈 | MVP 출시가 급하고 여러 PG·간편결제 가능성을 열어두고 싶은 SaaS·커머스 | 모듈 SDK, 서버 API, 결제 상태 동기화, 웹훅, 취소 API, 대시보드 운영 방식, 솔루션 콘솔 권한 | 결제 상태는 솔루션과 서비스 DB가 함께 맞아야 합니다. 포트원 문서도 PG사를 통해 직접 취소하면 포트원과 결제 상태가 동기화되지 않아 데이터 불일치가 생길 수 있다고 안내합니다. ([developers.portone.io](https://developers.portone.io/opi/ko/integration/cancel/v2/readme?utm_source=openai)) |
| 커스텀 정산 개발 | 판매자, 강사, 호스트, 제휴사별 수수료·정산 주기·보류금·차감금이 다른 플랫폼 | 정산 원장, 수수료 정책, 배치 작업, 정산 승인, 지급 파일, 대사 리포트, 오류 재처리, 권한·감사 로그 | 결제 기능보다 운영 설계가 더 큽니다. 자금 흐름이 플랫폼을 거치는 구조는 개발 전 법무·세무 검토가 필요합니다. |
2. 결제 버튼 뒤에 숨어 있는 9단계 업무 흐름
토스페이먼츠 코어 API만 보더라도 결제 승인, 결제 조회, 결제 취소, 현금영수증 발급·취소, 정산 조회가 각각 다른 API 범위로 분리됩니다. 예를 들어 결제 취소는 paymentKey 기준으로 처리하고, 부분취소는 cancelAmount가 들어가며, 정산 조회는 지급받을 금액·날짜·수수료 정보를 확인해 내부 데이터와 맞추는 대사 업무로 이어집니다. ([docs.tosspayments.com](https://docs.tosspayments.com/reference))
- 상품·예약·구독 생성: 상품명, 수량, 예약일, 과세·면세 여부, 할인 전후 금액을 확정합니다.
- 주문 생성: 내부 주문번호를 만들고 중복 결제 방지 상태를 둡니다. 결제 실패 후 재시도 정책도 필요합니다.
- 결제 요청·승인: 프론트 결제창과 서버 승인 검증을 분리합니다. 승인 성공만 믿지 말고 서버 DB에 최종 상태를 기록해야 합니다.
- 웹훅 수신: 결제창 콜백이 누락되어도 서버가 결제 상태를 복구할 수 있어야 합니다. 이 부분은 Webhook 설계·보안·운영 가이드처럼 서명 검증, 재시도, 멱등 처리가 핵심입니다.
- 취소·부분취소·환불: 카드 부분취소, 가상계좌 환불 계좌, 쿠폰 환급, 예약 좌석 복구가 함께 움직입니다. 토스페이먼츠 취소 가이드는 결제수단에 따라 부분취소 제약과 환불 계좌 처리가 달라질 수 있음을 안내합니다. ([docs.tosspayments.com](https://docs.tosspayments.com/guides/v2/cancel-payment))
- 현금영수증·세금계산서: 결제 승인과 별개로 발행, 취소, 조회, 실패 재처리를 따로 봐야 합니다.
- PG 정산 데이터 수집: 지급일 기준, 매출일 기준, 수수료, 부가세, 취소 차감 내역을 가져옵니다.
- 판매자별 정산 계산: 플랫폼 수수료, 판매자 등급, 쿠폰 부담 주체, 보류금, 위약금, 환불 차감을 반영합니다.
- 관리자 대사·재처리: PG 데이터와 내부 주문 데이터가 다를 때 원인을 보고, 재조회·재전송·수기 보정할 수 있어야 합니다.
3. 결제·정산 시스템 외주 견적 항목 비교표
아래 표는 견적서의 ‘PG 연동’ 한 줄을 실제 개발·운영 항목으로 쪼갠 것입니다. 업체별 단가보다 먼저 이 항목들이 포함인지 제외인지 표시해 달라고 요청하면 견적 비교가 훨씬 쉬워집니다.
| 견적 항목 | MVP 최소 범위 | 운영형·플랫폼 추가 범위 | 검수 기준 |
|---|---|---|---|
| 1. PG·결제수단 사전 검토 | 카드, 계좌이체, 가상계좌 중 필수 수단 정의 | 간편결제, 해외결제, 에스크로, 정기결제 검토 | 서비스 모델별 결제수단 표가 산출물에 포함 |
| 2. 결제창·위젯 UI | 결제 버튼, 약관 동의, 성공·실패 페이지 | 모바일 웹뷰, 앱 딥링크, 결제수단별 안내 문구 | 실패·취소·뒤로가기 케이스가 테스트됨 |
| 3. 주문·결제 DB | 주문번호, 금액, 결제상태, 결제키 저장 | 결제 이력 테이블, 상태 변경 로그, 중복 결제 방지 | 동일 주문 재시도 시 금액과 상태가 깨지지 않음 |
| 4. 결제 승인 검증 | 서버에서 승인 결과 확인 후 주문 완료 처리 | 금액 위변조 검증, 결제수단별 예외, 타임아웃 재조회 | 프론트 콜백만으로 주문 완료 처리하지 않음 |
| 5. 웹훅·콜백 | 결제 완료와 취소 알림 수신 | 서명 검증, 재시도 큐, 멱등키, 실패 알림 | 같은 웹훅이 여러 번 와도 주문 상태가 중복 변경되지 않음 |
| 6. 전액취소·부분취소 | 관리자 전액취소 버튼 | 부분취소, 다회 부분취소, 취소 사유, 환불 내역 분리 | 취소 후 주문, 재고, 예약, 정산 예정액이 함께 바뀜 |
| 7. 가상계좌·계좌이체 환불 | 입금 전 취소 처리 | 환불 계좌 입력, 예금주 검증, 환불 실패 재처리 | 환불 계좌 정보 보관 기간과 접근권한이 정의됨 |
| 8. 구독·빌링키 | 후순위 또는 수동 청구 | 빌링키 발급, 정기 과금, 미납 재시도, 플랜 변경 정산 | 해지·업그레이드·다운그레이드 시 일할 계산 정책이 문서화됨 |
| 9. 쿠폰·포인트 | 단순 할인 금액 저장 | 쿠폰 부담 주체, 부분취소 시 환급 규칙, 프로모션 예산 복구 | 부분취소 후 남은 금액과 할인액 계산식이 검수표와 일치 |
| 10. 현금영수증 | 발급 여부와 식별번호 저장 | 발급 API, 취소 API, 실패 재시도, 자진발급 정책 | 현금성 결제 승인·취소와 영수증 상태가 함께 맞음 |
| 11. 세금계산서 | 운영자가 수동 발행할 수 있도록 데이터 다운로드 | 전자세금계산서 API 또는 시스템사업자 연동, 수정발행, 역발행 | 공급자·공급받는자·공급가액·부가세 데이터가 누락되지 않음 |
| 12. 정산 원장 | 주문별 결제금액과 수수료 메모 | 판매자별 매출, 수수료, 차감, 보류, 지급 예정액 원장 | 주문 1건이 정산 원장에 어떤 항목으로 반영되는지 추적 가능 |
| 13. 판매자 수수료 정책 | 고정 수수료율 1개 | 판매자 등급, 카테고리, 프로모션, 최소 정산액, 보류 기간 | 정산 공식이 스프레드시트 샘플과 동일하게 계산됨 |
| 14. 정산 대사 | PG 콘솔 다운로드 후 수동 확인 | PG 거래대사, 입금대사, 이상 거래 리포트, 재조회 배치 | 내부 주문과 PG 정산 내역의 누락·금액 불일치가 표시됨 |
| 15. 관리자 화면 | 주문 검색, 결제상태, 취소 버튼 | 판매자별 정산서, 대사 결과, 세금증빙, 다운로드, 승인 워크플로 | 운영자가 개발자 없이 일일 결제·환불·정산 상태를 확인 가능 |
| 16. 권한·감사 로그 | 관리자 로그인 | 역할별 권한, 환불 승인자, 정산 확정자, 변경 이력 | 누가 언제 얼마를 취소·보정했는지 로그로 남음 |
| 17. 오류 재처리·알림 | 결제 실패 메시지 표시 | 웹훅 실패 큐, 배치 실패 알림, 슬랙·메일 통보, 수동 재시도 | PG 장애나 네트워크 오류 후 복구 절차가 문서화됨 |
| 18. 배포·모니터링·인수인계 | 운영 서버 배포 | 환경변수, PG 키 권한, 로그 모니터링, 백업, 운영 매뉴얼 | 계정·서버·소스코드 인수 기준은 외주개발 서버 인수 체크리스트에 맞춰 확인 |
포트원은 PG 거래대사를 통해 PG와 간편결제사 정산 내역을 통합 조회하고, 주문금액 불일치나 PG·고객사 어느 한쪽에만 있는 데이터를 이상 거래로 볼 수 있게 안내합니다. 이런 기능을 쓸지, 아니면 자체 대사 화면을 만들지는 견적 단계에서 분리해야 합니다. ([developers.portone.io](https://developers.portone.io/opi/ko/etc/recon?utm_source=openai))
4. 비용은 어떻게 산정할까: 가격보다 공수 구조를 보라
결제·정산 견적의 금액은 시장 평균가로 단순 비교하기 어렵습니다. 같은 ‘부분환불’이라도 단일 상품 환불인지, 쿠폰·포인트·판매자 정산·세금증빙까지 같이 되돌려야 하는지에 따라 공수가 완전히 달라집니다. 따라서 아래 산정식을 먼저 업체에 공유해 범위를 맞추는 편이 안전합니다.
총 견적 = 기본 결제 연동 공수 + 환불·취소 공수 + 정산 규칙 공수 + 관리자 화면 공수 + 대사·배치 공수 + QA·보안·배포 공수 + 문서화·인수인계 공수 + 외부 서비스 이용료
| 산정 블록 | 공수를 키우는 변수 | 발주자가 준비할 자료 |
|---|---|---|
| 기본 결제 | 결제수단 수, 웹·앱 동시 지원, PG 심사 상태, 테스트 계정 준비 여부 | 결제수단 목록, 참고 서비스, 성공·실패 화면 기획 |
| 환불·취소 | 부분취소 횟수, 가상계좌 환불, 쿠폰·포인트 복구, 예약 위약금 | 환불 정책표, 취소 사유, 운영자 승인 기준 |
| 정산 | 판매자 수, 수수료 공식 수, 정산 주기, 보류금, 최소 지급액 | 정산 샘플 엑셀, 판매자 계약 조건, 세무 처리 기준 |
| 대사·배치 | PG 정산 데이터 수집 방식, 입금 확인 주기, 이상 거래 처리 | PG 콘솔 샘플, 은행 입금 내역 양식, 대사 기준 |
| 관리자 | 검색 조건, 다운로드, 역할별 권한, 승인 워크플로 | 운영자 역할표, 일일 운영 시나리오, 필요한 리포트 |
| 인수·유지보수 | 소스 소유권, 서버 계정, 장애 대응, PG API 변경 대응 | 계약서 초안, 서버 소유 구조, 하자보수 기간 |
외주 개발비를 마일스톤으로 나눌 때는 결제창 완료, 환불 완료, 관리자 완료처럼 화면 단위로만 자르지 말고 ‘테스트 결제 성공’, ‘부분취소 후 정산 예정액 반영’, ‘대사 불일치 리포트 확인’처럼 검수 가능한 업무 단위로 나누는 것이 좋습니다. 계약 구조는 외주 개발 마일스톤 결제 비율 계약서 예시를 함께 참고하면 범위 변경 분쟁을 줄일 수 있습니다.
5. 세금계산서·현금영수증은 결제 연동에 자동 포함되지 않는다
현금영수증은 PG 또는 결제 솔루션의 API로 발급·취소할 수 있는 경우가 있지만, 발급 대상, 식별번호, 발급 실패, 부분취소 시 취소 금액 처리는 서비스 DB와 맞아야 합니다. 전자세금계산서는 국세청 홈택스 또는 시스템사업자 발급 사이트를 선택해 발급할 수 있고, 발급을 위해 인증수단과 전송 절차가 필요하므로 결제 승인 기능과 별도 견적 항목으로 보는 편이 안전합니다. ([ems.nts.go.kr](https://ems.nts.go.kr/nts/cm/cntnts/cntntsView.do?cntntsId=7790&utm_source=openai))
- 현금영수증: 계좌이체·가상계좌 등 현금성 결제, 자진발급, 발급 취소, 조회 화면을 분리합니다.
- 세금계산서: B2B SaaS, 광고비, 중개 수수료 매출처럼 공급자·공급받는자 정보가 필요한 거래에서 별도 정책이 필요합니다.
- 매출전표: 카드 결제 영수증 링크를 사용자와 운영자가 확인할 수 있게 저장합니다.
- 정산서: 판매자에게 지급되는 금액을 설명하는 운영 문서로, 세금계산서와 같은 문서가 아닙니다.
6. 플랫폼 정산은 개발 전에 자금 흐름부터 확정하라
여러 판매자나 파트너의 거래대금을 받아 나중에 나누어 지급하는 구조라면 단순 개발 이슈가 아닙니다. 전자금융거래법 제28조는 전자지급결제대행 관련 업무를 등록 대상으로 두고 있으며, 금융위 법령해석도 통신판매중개업자가 결제대금 정산 과정에 관여하는지 여부를 중요한 기준으로 봅니다. 실제 등록 필요 여부는 모델별로 달라질 수 있으므로, 개발 착수 전 법무·세무 전문가와 PG사에 자금 흐름도를 보여주고 확인해야 합니다. ([law.go.kr](https://law.go.kr/LSW/lsLawLinkInfo.do?ancYnChk=0&chrClsCd=010202&lsJoLnkSeq=1007935933&utm_source=openai))
- 구매자가 결제한 돈이 누구 명의의 가맹점으로 들어오는가?
- PG가 판매자에게 직접 지급하는가, 플랫폼이 받아서 지급하는가?
- 플랫폼 수수료는 결제 시점에 차감되는가, 정산 시점에 차감되는가?
- 환불이 발생하면 판매자 정산 예정액에서 차감되는가, 플랫폼이 먼저 부담하는가?
- 세금계산서는 플랫폼 수수료에 대해서만 발행하는가, 전체 거래액에 대해 발행하는가?
- 정산 보류, 분쟁, 노쇼, 위약금, 쿠폰 부담 주체는 누구인가?
7. 외주 계약서에 넣을 검수 체크리스트
다음 항목은 그대로 복사해 제안요청서나 계약서 별첨에 넣어도 됩니다. 핵심은 기능명을 쓰는 것이 아니라, 실패 상황까지 테스트 가능한 문장으로 쓰는 것입니다.
- 결제 승인 성공 시 내부 주문 상태, 결제 상태, 사용자 알림이 모두 완료로 변경된다.
- 결제 승인 실패·사용자 결제창 이탈·네트워크 타임아웃 시 주문이 임의로 완료 처리되지 않는다.
- 동일 주문에 웹훅이 중복 수신되어도 결제·취소·정산 상태가 한 번만 반영된다.
- 관리자는 전액취소와 부분취소를 구분해 실행할 수 있고, 취소 사유와 실행자가 로그에 남는다.
- 부분취소 후 쿠폰, 포인트, 재고, 예약 가능 수량, 판매자 정산 예정액이 정책대로 변경된다.
- 현금영수증 또는 세금계산서 발급 실패 건을 관리자에서 조회하고 재처리할 수 있다.
- PG 정산 데이터와 내부 주문 데이터의 금액 불일치, 누락, 중복을 표시하는 대사 화면 또는 리포트가 있다.
- 정산 공식은 샘플 엑셀 10건 이상과 동일한 결과를 낸다. 환불·쿠폰·수수료·보류금 케이스를 포함한다.
- 운영 서버, 소스코드 저장소, DB 백업, PG 키, 환경변수, 배포 계정의 소유자와 인수 방법이 명시된다.
- 하자보수 범위에 PG API 변경, 결제 장애, 웹훅 실패, 정산 오류가 포함되는지 별도로 적는다.
8. 서비스 유형별 추천 범위
| 서비스 유형 | 처음부터 필요한 범위 | 나중으로 미뤄도 되는 범위 | 특별 주의 |
|---|---|---|---|
| 예약 서비스 | 예약금 결제, 일정 변경, 취소 수수료, 관리자 환불 | 자동 정산서, 복잡한 프로모션 | 부분취소와 노쇼 위약금이 정산에 반영되어야 합니다. |
| 단일 판매자 커머스 | 카드 결제, 주문 상태, 전액취소, 현금영수증 | 복수 PG 라우팅, 판매자별 정산 | 재고 복구와 취소 재고 반영을 빼먹기 쉽습니다. |
| 중개·마켓플레이스 | 판매자 원장, 수수료, 정산 예정액, 보류·차감, 대사 | 정교한 자동 지급은 2차 고도화 가능 | 자금 흐름과 PG 등록 이슈를 개발 전 확인해야 합니다. |
| SaaS 구독 | 플랜, 결제수단 저장, 정기 결제, 미납 알림, 세금계산서 | 연간 계약 자동 갱신, 사용량 기반 과금 | 업그레이드·다운그레이드 일할 계산 기준이 필요합니다. |
| 정부지원 MVP | 핵심 결제 플로우, 관리자 주문 조회, 기본 취소, 정산 시뮬레이션 | 완전 자동 대사, 다중 PG, 고급 리포트 | 최종보고용 데모와 실제 운영용 범위를 혼동하지 않아야 합니다. |
9. 견적 요청 전에 준비할 자료
개발사에 ‘결제 넣어주세요’라고 문의하면 대부분의 견적은 넓은 가정 위에 작성됩니다. 아래 자료를 준비하면 과소 견적과 누락 계약을 줄일 수 있습니다.
- 상품·예약·구독 단위: 무엇을 결제하는지, 한 주문에 여러 상품이 들어가는지
- 결제수단: 카드, 계좌이체, 가상계좌, 간편결제, 정기결제 중 필수와 후순위
- 주문 상태표: 생성, 결제대기, 결제완료, 취소요청, 부분취소, 환불완료, 만료
- 환불 정책: 전액환불, 부분환불, 취소 가능 기한, 위약금, 운영자 승인 필요 여부
- 정산 공식: 판매자 수수료, PG 수수료 부담 주체, 쿠폰 부담, 보류금, 최소 지급액
- 세금증빙 정책: 현금영수증, 세금계산서, 매출전표, 정산서의 발행 주체
- 관리자 역할: CS 담당자, 정산 담당자, 최고관리자의 권한 차이
- 검수 데이터: 성공 결제, 실패 결제, 부분취소, 가상계좌 환불, 정산 불일치 샘플
10. AgentMit/BizMit과 검토할 때의 범위
AgentMit은 결제 버튼만 붙이는 방식보다 주문·결제·환불·정산·관리자·자동화·배포·유지보수 범위를 함께 정의하는 쪽에 맞춰 프로젝트를 봅니다. 특히 BizMit 기반 SaaS, 예약·매칭 서비스, 정부지원사업 MVP, 운영 관리자 대시보드에서는 결제 승인보다 출시 후 매일 확인할 정산·대사·오류 재처리 화면이 더 중요해지는 경우가 많습니다.
이미 견적서를 받았다면 ‘PG 연동’이라는 항목 아래에 위 18개 항목이 포함되는지 표시해 보세요. 비어 있는 항목이 많다면 개발사를 바꾸기 전에 범위표를 다시 만들고, 꼭 필요한 1차 출시 범위와 2차 고도화 범위를 나누는 것이 좋습니다. AgentMit에 문의할 때도 같은 방식으로 현재 서비스 모델, 결제수단, 정산 공식, 출시일, 운영 인력을 보내주시면 MVP 견적과 실서비스 견적을 분리해 검토할 수 있습니다.
FAQ
Q1. PG 직접 연동과 포트원 같은 통합 결제 모듈 중 무엇이 더 저렴한가요?
초기 MVP만 보면 통합 결제 모듈이 개발 범위를 줄이는 경우가 많지만, 최종 비용은 PG 수수료, 솔루션 요금, 운영 대사 방식, 향후 PG 교체 가능성까지 합쳐 봐야 합니다. 단일 PG를 오래 쓸 계획이고 내부 개발 역량이 있으면 직접 연동도 합리적입니다.
Q2. 외주 견적서에 PG 연동이라고 쓰여 있으면 환불과 부분환불도 포함인가요?
자동 포함이라고 보면 위험합니다. 전액취소, 부분취소, 가상계좌 환불 계좌, 쿠폰·포인트 환급, 재고·예약 복구, 관리자 승인까지 각각 별도 검수 항목으로 적어야 합니다.
Q3. 플랫폼 판매자 정산은 PG사가 알아서 처리해 주나요?
PG 정산은 보통 상점 기준 입금 내역을 의미하고, 판매자별 수수료·쿠폰 부담·보류금·차감금을 계산하는 내부 정산 원장은 별도 개발 범위가 되는 경우가 많습니다. 정산 지급대행 상품을 쓰더라도 판매자 정책과 관리자 화면은 서비스 쪽에서 정의해야 합니다.
Q4. 세금계산서와 현금영수증 자동 발행도 결제 연동 범위에 넣어야 하나요?
넣어야 합니다. 현금영수증, 세금계산서, 거래명세서, 매출전표 링크는 데이터 소스와 발행 주체가 다르므로 결제 승인 기능과 분리해 견적서에 적는 것이 안전합니다.
Q5. 정부지원사업 MVP에서는 결제·정산을 어디까지 구현해야 하나요?
사업 검증 단계라면 실제 결제 승인, 기본 취소, 관리자 주문 조회, 정산 시뮬레이션 표 정도로 시작할 수 있습니다. 다만 플랫폼형 과제에서 판매자에게 실제 지급이 발생한다면 정산 원장, 대사, 권한, 로그 범위를 MVP 안에 최소 형태로라도 포함하는 편이 좋습니다.
참고한 공식 문서
이 글은 특정 PG나 솔루션을 추천하기보다, 공식 문서에서 확인되는 API 범위와 운영 주의사항을 기준으로 외주 견적 항목을 나누었습니다.
- 토스페이먼츠 코어 API와 결제 취소 가이드: 결제 승인, 취소, 부분취소, 현금영수증, 정산 조회 범위 확인. ([docs.tosspayments.com](https://docs.tosspayments.com/reference))
- 포트원 결제취소·PG 거래대사 문서: 결제 상태 동기화와 대사 리포트 범위 확인. ([developers.portone.io](https://developers.portone.io/opi/ko/integration/cancel/v2/readme?utm_source=openai))
- 국세청 전자세금계산서 안내: 홈택스 또는 시스템사업자 발급 구조와 인증·전송 맥락 확인. ([ems.nts.go.kr](https://ems.nts.go.kr/nts/cm/cntnts/cntntsView.do?cntntsId=7790&utm_source=openai))
- 전자금융거래법 및 금융위 법령해석: 플랫폼형 정산 구조에서 법무 검토가 필요한 이유 확인. ([law.go.kr](https://law.go.kr/LSW/lsLawLinkInfo.do?ancYnChk=0&chrClsCd=010202&lsJoLnkSeq=1007935933&utm_source=openai))
