앱 개발
운영 중인 앱에 AI 챗봇을 붙이는 일 자체는 예전보다 훨씬 쉬워졌습니다. 어려운 건 붙인 다음입니다. 엉뚱한 답을 했을 때 누가 책임지는지, 고객 정보가 외부 AI 회사로 넘어가도 되는지, 사용자에게 AI라는 걸 어떻게 알릴지를 먼저 정해 두지 않으면 출시 후에 기능을 내리는 일이 생깁니다. 이 글은 기존 앱에 LLM(대규모 언어 모델, ChatGPT 같은 서비스의 기반이 되는 AI) 챗봇을 넣을 때 저희가 고객사와 먼저 정리하는 내용입니다.
챗봇이 잘 맞는 곳과 안 맞는 곳
챗봇이 효과를 내는 곳은 대체로 질문의 형태가 다양하고, 답은 이미 어딘가 문서로 존재하는 영역입니다. 이용 방법 안내, 자주 묻는 질문, 상품이나 서비스 조건 설명, 앱 안의 긴 콘텐츠 요약 같은 것들입니다. 고객센터 FAQ 페이지를 끝까지 읽는 사용자는 많지 않은데, 같은 내용을 물어보면 바로 답해 주니 체감이 확실히 다릅니다.
반대로 잘 안 맞는 곳도 분명합니다. 정확한 숫자가 필요한 답, 예를 들어 오늘 남은 예약 수나 내 포인트 잔액은 챗봇이 "생성"하면 안 되고 서버의 데이터를 그대로 보여 줘야 합니다. 환불 승인, 진단에 가까운 건강 판단, 법률 판단처럼 틀렸을 때 책임이 큰 영역도 챗봇이 결론을 내리게 두면 안 됩니다. 이런 영역은 챗봇이 관련 화면이나 상담원으로 안내하는 역할까지만 맡기는 게 맞습니다.
버튼 세 번이면 끝나는 기능을 굳이 대화로 바꾸는 것도 피하는 편입니다. 대화가 항상 더 편한 것은 아니어서, 이미 잘 만든 화면이 있다면 챗봇은 그 화면으로 연결해 주는 쪽이 낫습니다.
API 키는 앱 안에 넣으면 안 됩니다
가장 먼저 짚는 부분입니다. OpenAI, Anthropic, Google 같은 AI 회사의 API를 쓰려면 API 키(사용 권한을 증명하는 비밀 문자열)가 필요한데, 이 키를 앱 코드에 넣어 배포하면 안 됩니다. 앱 설치 파일은 누구나 내려받아 풀어 볼 수 있어서 키가 그대로 드러나고, 누군가 그 키로 우리 계정에 요청을 쏟아부어도 막을 방법이 없습니다. 요금은 키 주인에게 청구됩니다.
그래서 구조는 항상 이렇게 잡습니다. 앱은 우리 회사 서버에만 질문을 보냅니다. 서버가 로그인한 사용자인지 확인하고, 사용자별 하루 사용량 같은 제한을 걸고, 보내면 안 되는 정보를 걸러 낸 뒤 AI 회사 API를 호출합니다. 답을 받으면 서버에서 기록을 남기고 앱으로 돌려줍니다.
이렇게 서버를 한 번 거치면 얻는 게 많습니다. 나중에 AI 모델이나 회사를 바꿀 때 앱 업데이트 없이 서버만 바꾸면 됩니다. 문제 있는 답변이 나왔을 때 기록을 보고 원인을 찾을 수 있습니다. 비용이 갑자기 늘어도 서버에서 바로 차단할 수 있습니다. 답변을 글자 단위로 흘려 보여 주는 스트리밍도 서버를 거쳐서 충분히 구현됩니다.
회사 문서를 기반으로 답하게 하는 방법(RAG)
범용 AI 모델은 우리 회사의 요금 정책이나 이용 약관을 모릅니다. 모르는 걸 물으면 그럴듯하게 지어내기도 합니다. 그래서 대부분의 업무용 챗봇은 RAG(검색 증강 생성)라는 방식을 씁니다.
- 질문 받기사용자가 앱에서 질문
- 문서 찾기회사 문서에서 관련 부분 검색
- 함께 넘기기찾은 부분을 질문과 함께 AI에 전달
- 근거로 답변자료를 근거로 답을 만들어 보여 줌
이름은 어려워 보여도 원리는 단순합니다. 사용자가 질문하면 먼저 우리 문서 중에서 관련 있는 부분을 찾아오고, 그 부분을 질문과 함께 AI에 넘기면서 "이 자료를 근거로 답하라"고 시키는 겁니다. 시험으로 치면 오픈북 시험입니다. AI 모델을 새로 학습시키는 것이 아니라서 문서가 바뀌면 검색 대상 문서만 갱신하면 됩니다.
실제로 해 보면 AI 모델보다 문서 상태가 결과를 좌우합니다. 같은 내용이 버전별로 여러 문서에 흩어져 있거나, 오래된 공지가 지워지지 않고 남아 있으면 챗봇도 오래된 내용을 답합니다. 그래서 저희는 챗봇 개발에 들어가기 전에 고객사와 함께 "챗봇이 참고할 문서 목록"을 먼저 만들고, 그 문서를 누가 언제 고칠지 담당자를 정합니다. 이 작업을 건너뛰면 개발이 끝나도 품질이 올라가지 않습니다.
틀린 답변은 줄일 수 있지만 없앨 수는 없습니다
AI가 사실이 아닌 내용을 자신 있게 말하는 현상을 흔히 할루시네이션(환각)이라고 부릅니다. RAG를 쓰면 많이 줄어들지만 완전히 사라지지는 않습니다. 그래서 틀릴 수 있다는 전제로 설계해야 합니다.
저희가 기본으로 넣는 장치는 이 정도입니다.
- 답변 근거가 된 문서나 화면 링크를 같이 보여 줘서 사용자가 직접 확인할 수 있게 합니다.
- 관련 문서를 찾지 못하면 지어내지 말고 "확인할 수 없다"고 답한 뒤 고객센터나 담당 화면으로 안내하도록 지시합니다.
- 금액, 날짜, 잔여 수량처럼 정확해야 하는 값은 AI 문장이 아니라 서버 데이터로 표시합니다.
- 답변마다 좋아요·싫어요나 신고 버튼을 두고, 싫어요가 달린 대화는 주기적으로 모아서 문서나 지시문을 고칩니다.
- 출시 전에 실제 고객 문의를 바탕으로 질문 목록을 만들어 답변을 한 번씩 검토합니다. 모델이나 지시문을 바꿀 때마다 같은 목록으로 다시 돌려 봅니다.
헬스케어처럼 민감한 분야라면 범위를 더 좁힙니다. 증상에 대해 판단을 내리는 대신 앱 안의 기록을 정리해 보여 주거나 의료진 상담으로 연결하는 정도로 역할을 정하는 경우가 많습니다.
개인정보는 필요한 만큼만 보냅니다
챗봇 대화에는 사용자가 생각보다 많은 개인정보를 적습니다. 이름, 전화번호, 주소는 물론이고 건강 상태나 가족 이야기까지 들어옵니다. 이 내용이 그대로 외부 AI 회사로 넘어가는 구조라면, 개인정보 처리방침과 위탁·제공 고지에 반영해야 하고 실제로 그만큼 보낼 필요가 있는지부터 따져 봐야 합니다.
실무에서는 서버에서 전화번호나 주민등록번호 형식의 문자열을 가려서 보내고, 회원 정보는 꼭 필요한 항목만 질문에 붙입니다. AI 회사의 기업용 API 약관에서 입력 데이터를 모델 학습에 쓰는지, 얼마나 보관하는지도 확인합니다. 개인정보보호위원회가 2025년 8월 6일 공개한 "생성형 인공지능 개발·활용을 위한 개인정보 처리 안내서"에 상용 AI 서비스를 활용하는 사업자가 참고할 기준이 정리되어 있으니 기획 단계에서 한 번 읽어 보시길 권합니다.
App Store 심사 가이드라인 5.1.2(i)에도 관련 내용이 있습니다. 개인 데이터를 제3자 AI를 포함한 외부와 공유한다면 어디에 공유하는지 분명히 알리고, 공유하기 전에 사용자의 명시적인 허락을 받아야 한다고 적혀 있습니다. 챗봇 첫 화면에 안내와 동의 단계를 두는 이유가 여기에 있습니다.
AI 기본법과 스토어 정책에서 챙길 것
정책브리핑(과학기술정보통신부, 2026년 1월 21일)에 따르면 "인공지능 발전과 신뢰 기반 조성 등에 관한 기본법"(AI 기본법)이 2026년 1월 22일부터 시행됐습니다. 생성형 AI를 활용한 제품이나 서비스를 제공하는 사업자는 AI를 쓴다는 사실을 이용자에게 미리 알려야 하고, 생성형 AI 결과물은 AI가 만들었다는 것을 알 수 있게 표시해야 합니다. 서비스 안에서만 보이는 결과물은 알림 창이나 화면 표시 같은 방식으로도 알릴 수 있다고 안내되어 있습니다. 과기정통부는 최소 1년 이상 과태료 계도기간을 두겠다고 밝혔지만, 기능을 새로 만드는 지금 넣어 두는 편이 나중에 고치는 것보다 훨씬 쉽습니다.
- AI를 쓴다는 사실 미리 알리기
- 답변 말풍선에 AI 표시
- 앱 안에서 바로 신고하는 기능
- 불쾌한 콘텐츠 필터링과 차단
- 연령 등급 설문에 챗봇 반영
앱에서는 보통 챗봇 화면 상단이나 첫 진입 시 "AI가 생성한 답변으로 정확하지 않을 수 있습니다" 같은 문구를 두고, 답변 말풍선에 AI 표시를 붙이는 방식으로 대응합니다. 우리 서비스가 의무 대상인지, 어떤 방식이 충분한지는 과기정통부의 투명성 확보 가이드라인을 기준으로 확인하시는 게 정확합니다.
스토어 정책도 있습니다. 구글 플레이 개발자 정책의 AI 생성 콘텐츠 항목은 대화가 핵심 기능인 AI 챗봇을 대상으로 들고 있고, 사용자가 앱을 벗어나지 않고 불쾌한 AI 콘텐츠를 신고할 수 있는 기능을 갖추라고 요구합니다. App Store 심사 가이드라인 1.2의 사용자 생성 콘텐츠 규정도 AI 콘텐츠 생성 앱을 포함해 신고, 차단, 필터링 수단을 요구합니다. Apple은 2025년 7월 연령 등급 개편 공지에서 AI 어시스턴트나 챗봇이 민감한 콘텐츠 노출에 주는 영향도 등급 설문에 반영하라고 안내했습니다. 앞에서 말한 신고 버튼은 품질 관리뿐 아니라 심사 대응에도 필요한 셈입니다.
운영 비용은 어디서 늘어나나요
AI API 요금은 대체로 주고받는 글자 양(토큰)에 비례합니다. 그래서 비용을 좌우하는 건 사용자 수보다 대화 방식입니다. 대화가 길어질수록 앞의 대화를 매번 같이 보내야 해서 요청 하나가 점점 커지고, RAG로 붙이는 문서 분량이 많아도 비용이 늘어납니다. 어떤 모델을 쓰느냐에 따라 같은 질문도 요금 차이가 크게 납니다.
그래서 저희는 간단한 안내 질문은 가볍고 저렴한 모델로, 복잡한 질문만 상위 모델로 보내도록 나누거나, 자주 나오는 질문은 답을 저장해 두었다가 재사용하는 방식을 씁니다. 사용자별 일일 사용 한도와 월간 알림을 서버에 걸어 두면 예상 밖의 청구를 막을 수 있습니다. AI 기능 개발 방식은 AI 앱 개발 페이지에 더 자세히 적어 두었습니다.
자주 묻는 질문
챗봇을 넣으려면 앱을 새로 만들어야 하나요?
대부분은 그렇지 않습니다. 챗봇 화면 하나와 이를 받쳐 줄 서버 기능을 추가하는 작업이라 기존 앱 구조를 크게 건드리지 않습니다. 다만 로그인 방식이나 서버가 너무 오래된 경우에는 그 부분을 먼저 정리해야 할 수 있습니다.
우리 회사 데이터로 AI를 학습시켜야 하나요?
처음부터 학습까지 갈 필요는 거의 없습니다. 회사 문서를 검색해 답변 근거로 넘기는 RAG 방식으로 대부분의 업무용 챗봇은 충분히 만들 수 있습니다. 문서가 바뀌어도 바로 반영된다는 점에서도 이쪽이 운영하기 편합니다.
챗봇이 틀린 답을 하면 책임은 누구에게 있나요?
사용자 입장에서는 서비스를 제공한 회사의 답변으로 받아들입니다. 그래서 책임이 큰 영역은 챗봇이 결론을 내리지 않도록 범위를 정하고, 근거 링크와 상담 연결을 함께 두는 것이 중요합니다. 법적 판단이 필요한 부분은 별도로 법률 검토를 받으시길 권합니다.
AI 기본법 때문에 꼭 해야 하는 화면 작업이 있나요?
생성형 AI를 쓴다는 사전 고지와 결과물 표시가 기본입니다. 챗봇 첫 화면 안내 문구와 답변에 붙는 AI 표시 정도로 대응하는 경우가 많습니다. 구체적인 기준은 과기정통부 가이드라인을 확인하시는 것이 정확합니다.
운영 중인 앱에 AI 챗봇이나 문서 기반 답변 기능을 넣는 것을 검토하고 계시다면 상담 페이지로 앱과 문서 현황을 알려 주세요.
기획부터 출시까지, 모바일파트너스가 함께합니다
2026년 8월 31일부터 구글 플레이 신규 앱과 업데이트는 Android 16(API 36)을 타깃으로 해야 합니다. 엣지 투 엣지, 뒤로 가기, 큰 화면 회전 규칙 등 실제로 손봐야 할 부분과 점검 순서를 정리했습니다.
바이브 코딩은 팀 상황에 따라 쓰는 범위가 달라집니다. 새 서비스, 기존 서비스, 기획자 프로토타입별로 어디에 쓰면 좋고 무엇을 막아야 하는지 실무 기준으로 정리했습니다.
기존 앱에 LLM 기반 AI 챗봇을 붙일 때 효과가 있는 곳과 없는 곳, 서버 구조, 회사 문서 연결(RAG), 틀린 답변 대응, 개인정보, AI 기본법 고지 의무, 스토어 정책까지 실무 순서로 정리했습니다.