기존 시스템을 홈페이지에 연결하는 방법은 크게 네 가지입니다. 원본 시스템의 API를 호출하거나, 조회 권한만 받은 계정으로 DB를 읽거나, 바깥에서 모은 데이터를 승인을 거쳐 넣거나, 방문자를 원본 화면으로 보내는 것입니다. 어느 쪽이 맞는지는 데이터를 누가 관리하는지, 얼마나 자주 바뀌는지, 개인정보가 섞여 있는지로 정해집니다. 이 글은 VENOX 제품에서 실제로 쓰는 방식을 예로 네 가지를 비교합니다.
네 가지 방법 한눈에
1. API가 있으면 API부터
원본 시스템이 API를 제공하면 가장 먼저 검토합니다. 원본 시스템이 어떤 데이터를 얼마나 내줄지 스스로 정하기 때문에, 홈페이지 쪽은 원본의 테이블 구조를 몰라도 됩니다. 원본 시스템 내부가 바뀌어도 API 형식만 유지되면 홈페이지를 고칠 일이 적습니다.
예: 관리자 화면의 방문 통계
VENOX CMS 관리자 화면의 Google Analytics 탭은 GA4 Data API를 호출해 방문자 수, 인기 페이지, 유입 경로, 기기 비율을 보여 줍니다. 호출에는 GA 속성을 읽을 권한만 받은 서비스 계정을 씁니다. 받은 결과는 서버 메모리에 10분 동안 보관해서 같은 화면을 여러 번 열어도 API를 다시 부르지 않고, 실시간 사용자 수만 1분마다 새로 받습니다.
호출 한도 — 대부분의 API는 하루·분당 호출량이 정해져 있습니다. 화면을 열 때마다 부르지 말고 결과를 잠시 보관합니다.
키 보관 — API 키와 인증 파일은 소스 코드 저장소에 넣지 않고 서버 설정으로 분리합니다.
원본이 멈췄을 때 — 오류 내용을 그대로 보여 주지 말고 "지금 불러올 수 없습니다" 같은 화면을 준비합니다.
2. API가 없으면 읽기 전용 계정으로
오래된 업무 시스템은 API가 없는 경우가 많습니다. 이때는 원본 DB에 조회(SELECT) 권한만 있는 계정을 따로 받아 필요한 테이블만 읽습니다. 홈페이지 쪽 실수로 원본 데이터가 바뀌는 일을 계정 권한 단계에서 막는 방식입니다.
예: 챗봇이 CMS 게시판을 읽는 방식
Nexis Chat은 기관 CMS의 게시판 글과 첨부파일을 읽어 답변 근거로 씁니다. 연결은 읽기 전용이고, 어느 게시판을 읽을지(허용 목록)와 게시판 테이블의 어느 열이 제목·본문·작성일인지(테이블 매핑)를 관리자 화면에서 지정합니다. Contbot의 CMS 수집기도 조회 쿼리만 실행합니다.
좋은 점
원본 시스템을 고치지 않아도 됩니다.
필요한 열만 골라 읽을 수 있습니다.
조심할 점
원본 테이블 구조가 바뀌면 매핑을 다시 맞춰야 합니다.
조회도 원본 DB에 부담을 줍니다. 자주 바뀌지 않는 데이터는 주기적으로 가져와 홈페이지 쪽에 저장해 두고 씁니다.
개인정보 열은 아예 권한에서 뺍니다. 공개해도 되는 열만 담은 뷰(view)를 만들고 그 뷰만 읽게 하는 방법이 깔끔합니다.
3. 밖에서 모은 데이터는 승인을 거쳐 넣기
공공 데이터나 다른 기관의 공개 자료를 모아 보여 줄 때는 수집 프로그램이 홈페이지로 데이터를 보내는 방식이 맞습니다. 이때 챙길 것은 두 가지입니다. 아무나 보낼 수 없어야 하고, 들어온 데이터가 바로 공개되지 않아야 합니다.
예: VENOX CMS 정책뉴스
수집 프로그램이 정책브리핑(korea.kr)의 공개 뉴스를 모아 정책뉴스 일괄 등록 주소로 보냅니다.
요청 헤더에 전용 토큰이 있어야 받습니다. 토큰은 32자 이상이어야 하고, 토큰 비교는 어느 글자에서 틀렸는지와 상관없이 같은 시간이 걸리는 방식이라 응답 시간으로 토큰을 알아내기 어렵습니다.
같은 뉴스(원본 ID가 같은 뉴스)는 한 번만 저장합니다.
새 뉴스는 대기 상태로 저장되고 화면에는 나오지 않습니다. 관리자가 승인해야 공개 목록에 나오고, 여러 건을 한꺼번에 승인하거나 반려할 수도 있습니다.
4. 옮기지 않고 연결만: 링크와 삽입 화면
수강 신청, 결제, 민원 접수처럼 원본 시스템 안에서 끝나야 하는 업무는 데이터를 옮기지 않고 그 화면으로 보냅니다. VENOX CMS에서는 메뉴에 외부 주소를 넣고 새 창으로 열지 정할 수 있고, 페이지 본문에 다른 시스템 화면을 삽입(iframe)할 수도 있습니다.
삽입 화면 안의 글은 검색엔진과 AI 검색이 홈페이지 내용으로 보지 않습니다. 검색에 나와야 하는 안내 문구는 홈페이지 본문에 따로 씁니다.
원본 시스템이 다른 사이트 안에 표시되는 것을 막아 두었다면(X-Frame-Options, frame-ancestors) 삽입은 안 되고 링크로만 연결됩니다.
새 창으로 열리는 링크에는 "새 창"이라고 적어 두면 방문자가 덜 헷갈립니다.
보내는 쪽도 연동입니다: 문의 접수와 메일
연동은 가져오는 쪽만 있는 것이 아닙니다. VENOX CMS의 문의 폼은 접수 내용을 DB에 저장한 다음, 받는 주소가 지정돼 있으면 담당자에게 메일을 보냅니다. 메일 발송 서버(SMTP) 설정은 관리자 화면의 시스템 설정에서 바꾸고 테스트 메일로 확인합니다. 화면에서 설정하지 않았으면 서버 설정 파일의 값을 씁니다.
연결하기 전에 정할 것
| 정할 것 | 왜 필요한가 |
|---|---|
| 원본은 어디인가 | 같은 데이터를 두 곳에서 고치면 어느 쪽이 맞는지 알 수 없게 됩니다. 수정은 원본 한 곳에서만 합니다. |
| 얼마나 자주 바뀌나 | 실시간이 필요한지, 하루 한 번이면 되는지에 따라 방식이 달라집니다. |
| 개인정보가 섞여 있나 | 공개 화면에 필요 없는 열은 처음부터 권한에서 뺍니다. |
| 원본이 멈추면 | 홈페이지까지 같이 멈추지 않도록 보관해 둔 값이나 안내 화면을 보여 줍니다. |
| 누가 관리하나 | 매핑, 토큰, 계정 비밀번호를 바꿀 담당자와 절차를 정해 둡니다. |
자주 묻는 질문
홈페이지가 원본 데이터를 바꿀 수도 있나요?
할 수는 있지만 기본은 읽기만입니다. 쓰기가 꼭 필요하면 원본 시스템이 제공하는 API를 거치게 해서 원본의 검사 규칙을 통과하도록 합니다. 홈페이지가 원본 DB에 직접 쓰는 방식은 권하지 않습니다.
API도 없고 DB 접근도 안 된다면요?
원본 시스템에서 정기적으로 파일(CSV 등)을 내보내 홈페이지에 올리는 방법이 남습니다. 자동화 정도는 낮지만 원본 시스템에 손대지 않아도 됩니다. 이 경우에는 파일 형식과 올리는 화면을 따로 만들어야 합니다.
챗봇이나 AI 검색에 붙일 때도 같은가요?
같습니다. AI는 읽을 데이터가 정해진 다음의 문제입니다. 어떤 게시판과 첨부파일을 읽힐지, 개인정보를 어디서 거를지 먼저 정합니다. 실제 예는 Nexis Chat 답변 파이프라인과 Contbot 답변 방식에 정리했습니다.
관련 글: 시스템 연동 개발 · VENOX CMS 구조 해설 · 도입 문의