티온 CRM API

티온 CRM API를 검색하는 분은 회사 사이트 여러 곳에서 들어오는 문의가 메일, 스프레드시트, 각 사이트 관리자 화면에 흩어져 있어 한곳에 모으려는 개발·운영 담당자입니다. 이 글은 문의폼에서 CRM까지의 데이터 흐름, 서버사이드 연동이 필수인 이유, 개인정보 동의 체크리스트, 전송 실패 대비 설계를 설명합니다. 보안을 위해 실제 접속 주소, 인증키, 세부 경로는 이 글에 적지 않으며 연동 시 운영사가 별도로 안내합니다.

티온 CRM API를 찾는 이유 — 흩어진 문의 데이터 문제

문의 데이터가 흩어져 있으면 세 가지 문제가 생깁니다. 첫째, 같은 고객이 여러 사이트에서 문의해도 한 사람인지 알 수 없습니다. 둘째, 담당자가 메일함을 확인하지 못한 사이 응대가 늦어집니다. 셋째, 동의 이력과 보관기한 관리가 사이트마다 달라 개인정보 관리가 어려워집니다. 중앙 CRM으로 모으면 문의 이력, 동의 여부, 처리 상태를 한 화면에서 관리할 수 있습니다.

• 사이트별로 문의가 메일·스프레드시트에 분산
• 중복 문의와 응대 누락
• 동의 이력·보관기한 관리 불일치
• 광고 성과와 문의 결과를 연결해 보기 어려움

또한 광고나 콘텐츠가 실제 문의로 이어졌는지 확인하려면 문의 데이터가 한곳에 있어야 합니다. 리드는 수집한 플랫폼이 먼저 보관하고, 원본 데이터를 외부에 그대로 넘기지 않는 원칙도 이 구조에서 지키기 쉬워집니다.

문의폼에서 CRM까지 데이터 흐름

안전한 연동 구조의 핵심은 브라우저가 CRM과 직접 통신하지 않는다는 점입니다. 방문자가 폼을 제출하면 먼저 자사 사이트 서버가 받고, 서버가 입력값을 검증한 뒤 백업을 남기고 CRM으로 전송합니다. 전송 결과에 따라 성공·실패를 기록하고, 방문자에게는 접수 완료 화면을 보여줍니다.

1. 폼 제출방문자가 동의 체크 후 제출
2. 서버 수신사이트 서버가 입력값 검증
3. 로컬 백업웹 공개 경로 밖에 기록
4. 서버 간 전송인증키를 붙여 CRM으로 전송
5. 결과 기록성공·실패 상태 저장
6. 재전송실패분 주기적 재시도

이 순서에서 로컬 백업이 전송보다 앞에 있다는 점이 중요합니다. 전송 단계에서 문제가 생겨도 리드가 남아 있어 나중에 다시 보낼 수 있습니다. 방문자에게는 처리 결과와 관계없이 접수 완료를 안내하고, 실패 처리는 서버에서 조용히 이어집니다.

서버사이드 연동이 필수인 이유와 인증키 관리 원칙

브라우저에서 실행되는 자바스크립트나 HTML 숨김 필드에 인증키를 넣으면, 누구나 개발자 도구로 키를 볼 수 있습니다. 키가 노출되면 제3자가 가짜 리드를 대량으로 넣거나 정상 데이터를 오염시킬 수 있습니다. 그래서 인증키는 서버 측 설정 파일에만 두고, 서버가 CRM과 통신할 때만 사용합니다. OWASP도 비밀 정보를 소스 코드나 클라이언트에 두지 말고 별도 저장소에서 관리하라고 권고합니다(OWASP Secrets Management Cheat Sheet).

개인정보 동의·수집 목적·보관기한 체크리스트

「개인정보 보호법」 제15조는 개인정보를 수집할 때 목적, 항목, 보유·이용 기간, 동의를 거부할 권리와 불이익을 알리고 동의를 받도록 정하고 있습니다. 제22조는 동의 사항을 구분해 받도록 하고, 제21조는 보유기간이 지나면 지체 없이 파기하도록 합니다. 원문은 국가법령정보센터 개인정보 보호법에서 확인할 수 있습니다.

전송 실패 대비 백업과 재전송 설계

네트워크 지연, 상대 서버 점검, 일시적 오류는 언제든 생길 수 있습니다. 전송만 시도하고 실패를 기록하지 않으면 그 시간에 들어온 리드는 사라집니다. 그래서 전송 전에 로컬 백업을 먼저 남기고, 실패한 건은 대기 목록에 넣어 주기적으로 다시 보내는 구조가 필요합니다. 성공 판정은 응답 코드와 응답 본문을 함께 확인해야 정확합니다.

• 백업 위치: 웹에서 접근할 수 없는 경로, 소유자만 읽기 권한
• 실패 판정: 시간 초과, 서버 오류 응답, 응답 본문의 실패 표시
• 재전송: 일정 간격으로 재시도, 횟수 초과 시 담당자 확인
• 중복 방지: 건별 고유 식별자로 같은 리드가 두 번 적재되지 않게 처리

백업 파일도 개인정보이므로 보관 기간이 지나면 CRM 원본과 함께 파기합니다.

재전송 결과도 이력에 남겨 두면 장애 시간대와 영향 건수를 나중에 확인할 수 있습니다.

자주 하는 실수와 올바른 예

연동 초기에 가장 위험한 실수는 개발 편의를 위해 브라우저에서 바로 CRM으로 전송하는 것입니다. 테스트할 때는 빠르지만, 배포 후에는 키가 공개된 상태가 됩니다. 동의 체크 없이 수집하거나 필수·선택 동의를 하나로 묶는 것도 자주 보이는 문제입니다.

배포 전에는 페이지 소스와 네트워크 요청을 직접 열어 키 문자열이 보이지 않는지, 동의하지 않으면 제출이 막히는지를 확인하는 절차를 체크리스트에 넣어 두면 실수를 줄일 수 있습니다.

자주 묻는 질문

정적 사이트에서도 연동할 수 있나요?

서버 코드를 실행할 수 없는 정적 사이트라면 폼을 받아 줄 별도 서버 측 처리 지점이 필요합니다. 키를 브라우저에 두는 방식으로 우회해서는 안 됩니다.

기존 문의 데이터도 옮길 수 있나요?

과거 데이터는 당시 받은 동의 범위 안에서만 이전할 수 있습니다. 동의 이력이 없는 데이터는 이전 전에 법적 근거를 확인해야 합니다.

연동 비용은 어떻게 되나요?

운영사 안내 기준으로 연동 범위와 사이트 수에 따라 견적이 정해집니다. 엔터프라이즈 연동은 상담 페이지로, 서비스 전체 구성은 티온캡 안내로 확인하세요.

동의를 받지 않은 항목은 어떻게 처리하나요?

동의하지 않은 선택 항목은 수집하지 않고 전송하지도 않습니다. 폼에서 해당 입력값을 비워 두거나 저장 단계에서 제외하도록 설계합니다.

기준일 2026-10-06. 법령 설명은 국가법령정보센터 원문 기준 요약이며 법률 자문이 아닙니다. 구체적 적용은 전문가와 상담하세요.

이 글은 AI(인공지능)의 도움을 받아 작성되었습니다.