개인 AI 프로젝트의 운영 책임자는 대개 만든 사람 자신이다. 도메인을 연결하고 링크를 공유하는 순간부터 ‘기능이 된다’는 설명만으로는 부족하다. 어떤 데이터를 받는지, 비밀키는 어디에 있는지, 오류와 비용을 누가 확인하는지, 공개를 멈추거나 되돌릴 방법이 무엇인지 말할 수 있어야 한다. KAAI 개인 AI 실무·프로젝트 리포트는 이를 완료의 네 번째 문인 ‘공개 경계’로 다룬다.
도메인, 호스팅, 앱, 데이터는 서로 다른 책임이다
웹 주소가 생겼다고 서비스 운영이 한 덩어리로 끝나는 것은 아니다. 브라우저는 URL로 자원을 요청하고, 도메인 이름은 주소를 찾는 데 쓰이며, 호스팅은 파일이나 서버 응답을 제공한다. 앱은 사용자의 작업 규칙을 실행하고, 필요한 경우 데이터 저장소가 상태를 보관한다. HTTP의 요청·응답 기본 구조는 MDN의 HTTP 개요에서 확인할 수 있다.
이 층을 나눠 적으면 장애 질문도 달라진다. 주소가 연결되지 않는가, 파일이 배포되지 않았는가, 앱의 핵심 작업이 실패했는가, 데이터 읽기 권한이 잘못됐는가. ‘사이트가 안 된다’는 한 문장을 구체적인 확인 순서로 바꾸는 것이 운영 책임의 시작이다.
정적 페이지는 HTML·CSS·JavaScript 파일만으로도 배포할 수 있다. 하지만 인증, 비밀키, 여러 사용자가 함께 쓰는 데이터가 필요하면 브라우저 코드만으로 처리해서는 안 되는 일이 생긴다. GitHub Pages는 올바르게 구성한 커스텀 도메인에 HTTPS를 지원하지만, HTTPS가 앱의 권한과 데이터 설계를 대신하지는 않는다. Pages의 범위와 혼합 콘텐츠 주의점은 GitHub의 HTTPS 문서에 설명돼 있다.
수집하기 전에 데이터의 필요부터 묻는다
공개 전에 가장 먼저 줄여야 할 것은 기능이 아니라 불필요한 데이터와 권한이다. 이름, 연락처, 대화 내용, 업로드 파일을 받는다면 왜 필요한지, 어디에 저장되는지, 언제 지우는지, 누가 접근하는지를 적는다. 목적을 설명할 수 없는 정보는 처음부터 받지 않는 편이 안전한 기본값이다.
- 개인정보: 최소 수집, 짧은 보관, 삭제 경로를 정한다.
- AI 입력: 타인의 정보, 기밀, 저작물이 섞이는지 확인한다.
- 출력: 틀린 결과가 자동 실행되지 않도록 검토와 중단 경로를 둔다.
- 로그: 오류 기록에 민감정보가 남지 않도록 필드를 줄이고 접근을 제한한다.
이 점검표만으로 법률 준수나 보안 감사를 완료했다고 말할 수는 없다. 프로젝트의 위험과 데이터 종류에 따라 전문 검토가 필요하다. OWASP는 민감정보 최소화와 전송·저장 보호, 키 관리를 주요 통제로 설명한다. 세부 원칙은 OWASP A02 문서에서 확인할 수 있다.
API 키는 사용자에게 전달하는 기능이 아니다
브라우저에서 실행되는 코드와 공개 저장소는 사용자가 볼 수 있다고 가정해야 한다. API 키를 프런트엔드 코드에 넣거나 저장소에 커밋하면 안 된다. OpenAI도 API 키를 브라우저나 모바일 클라이언트에 배포하지 말고, 백엔드와 환경변수 같은 안전한 관리 경로를 사용하라고 안내한다. 이는 OpenAI 키에 관한 공급사 지침이며 자세한 내용은 API 키 안전 도움말에서 확인할 수 있다.
키를 숨기는 것만으로 운영이 끝나지는 않는다. 누가 키를 발급하고 교체하는지, 사용량과 비용을 어디서 확인하는지, 유출이 의심될 때 어떤 기능을 중단하는지까지 기록해야 한다. 개인 프로젝트라도 비용 상한과 중단 절차가 없으면 작은 오류가 반복 호출로 이어질 수 있다.
검색 노출은 완료 증거가 아니라 게시 뒤 확인할 경로다
공개 글과 서비스에는 고유한 제목과 설명, 분명한 H1, 대표 URL, 의미 있는 이미지 대체 설명을 준비할 수 있다. 네이버는 검색로봇이 문서를 이해할 수 있도록 고유한 title·description과 H1, 이미지 alt 같은 구조를 안내한다. 네이버 서치어드바이저 기본 가이드에서 현재 기준을 확인할 수 있다.
Google도 사람에게 유용한 원본 콘텐츠와 기본 SEO를 강조하며, 생성형 검색 기능에 별도의 비밀 공식이 있는 것처럼 접근하지 말라고 안내한다. Google의 AI 검색 최적화 가이드를 준비 근거로 쓸 수 있지만, 색인·순위·유입·AI 인용을 보장하는 자료는 아니다. 실제 공개 뒤에는 Search Console과 서치어드바이저 등에서 수집과 검색어, 클릭을 별도로 확인해야 한다.
확장 기술은 막힌 이유가 분명할 때만 더한다
RAG, Agent, Docker, 로컬 모델은 멋있어 보이는 부품 목록이 아니다. 내 문서에서 근거를 찾아야 하는지, 여러 도구 행동을 위임해야 하는지, 실행 환경 차이 때문에 재현이 깨지는지, 로컬 처리가 필요한지처럼 해결할 문제가 먼저 있어야 한다. 기술을 하나 더하면 데이터, 권한, 비용, 업데이트, 복구라는 운영 책임도 함께 늘어난다.
공개 전 마지막 기록에는 배포 주소, 현재 버전, 데이터와 비밀 관리 위치, 테스트 결과와 제외 범위, 비용 확인 방법, 장애 시 중단·복구 절차, 인계할 사람이 따라 할 설명을 넣는다. 개인 프로젝트의 장점은 책임을 생략하는 데 있지 않다. 약속할 범위를 작게 정하고, 그 범위의 책임을 한 사람이 끝까지 볼 수 있다는 데 있다. 전체 공개 경계와 확장 판단표는 KAAI 보고서 원문에서 확인할 수 있다.