블로그를 서브도메인에서 하위 경로로 옮긴 이유, 그리고 CSP가 애드센스를 막고 있었습니다
회사 사이트와 기술 블로그를 따로 운영하는 구성은 흔합니다. 회사는 duolabs.co.kr, 블로그는 blog.duolabs.co.kr.
회사 사이트와 기술 블로그를 따로 운영하는 구성은 흔합니다. 회사는 duolabs.co.kr, 블로그는 blog.duolabs.co.kr.
RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
문서는 많지만 필요한 순간에 찾기 어렵고, 검색 결과를 열어 일일이 내용을 비교해야 한다면 지식은 충분히 활용되지 못합니다. 이번 글에서는 문서와 업무 데이터를 자연어로 검색하고, 근거와 함께 답을 생성하는 RAG 시스템을 작은 범위에서 시작해 운영 가능한 구조로 확장한 과정을 정리합니다.
Next.js와 PostgreSQL로 만든 웹 애플리케이션을 운영할 때 관리형 플랫폼과 VPS 중 어느 쪽이 더 저렴한지는 월 기본요금만으로 판단하기 어렵습니다. 관리형 플랫폼은 배포와 확장을 대신 처리하고, VPS는 낮은 인프라 비용 대신 서버 운영을 직접 맡아야 합니다.
웹사이트를 운영하다 보면 루트 주소에서 robots.txt라는 작은 텍스트 파일을 만나게 됩니다. 내용은 몇 줄뿐인데 검색엔진 최적화 점검표에는 거의 빠지지 않고 등장합니다.
호스팅 서비스를 비교할 때 가장 먼저 확인해야 할 것은 가격표가 아니라 서로 같은 종류의 서비스를 비교하고 있는가입니다. AWS와 Vercel, Railway와 VPS는 모두 애플리케이션을 운영할 수 있지만 사용자가 직접 관리해야 하는 범위가 다릅니다.
문서 질의응답 기능은 검색과 답변 생성을 함께 수행하기 때문에 일반 API보다 처리 비용이 큽니다. 그런데 모바일 화면에서 제공하는 질문이 미리 준비된 여덟 개로 고정되어 있다면 캐시 대상은 매우 작아집니다.
새 기능의 코드와 테스트가 모두 준비되어도 데이터베이스 테이블이 운영에 만들어지지 않으면 서비스는 시작할 수 없습니다. 문서 RAG 기능을 배포하는 과정에서 실제 배포 스크립트는 마이그레이션 파일을 적용하고 있었지만, 개발 지침에는 마이그레이션 파일을 만들지 말라고 적혀 있는 불일치를 발견했습니다.
데스크톱에서 잘 작동하는 AI 인터페이스를 모바일 화면에 그대로 줄이면 기능은 남지만 경험은 쉽게 무너집니다. 사이드바, 대화, 참고 문헌을 동시에 보여주는 3단 구조는 넓은 화면에서는 강력하지만 작은 화면에서는 탐색과 스크롤이 서로 경쟁합니다.
문서 RAG를 관리자 화면 안에서만 사용하다가 공개 웹 서비스로 확장하면 가장 먼저 바뀌어야 하는 것은 UI가 아니라 신뢰 경계입니다.