웹 인프라12분
S3와 R2를 다시 비교해보니, 저장비보다 CDN 경로가 더 중요했습니다
이 글의 가격과 제품 조건은 2026년 8월 4일 공식 문서 기준입니다.
이 글의 가격과 제품 조건은 2026년 8월 4일 공식 문서 기준입니다.
모바일 서명 파일이나 환경설정을 백업하다 보면 값 대부분이 Base64처럼 보일 때가 있다. 이때 가장 먼저 구분해야 할 사실이 있다.
모바일 앱의 운영 환경을 정리하다 보면 Android Keystore, iOS 인증서, Provisioning Profile 같은 낯선 자격 증명을 만나게 된다. 이런 파일을 보고 있으면 새로운 컴퓨터에서 앱을 다시 빌드하는 일이 상당히 복잡할 것처럼 느껴진다.
Expo EAS를 사용하면 모바일 앱의 빌드와 스토어 제출을 자동화할 수 있다. 편리한 만큼 운영에 필요한 자격 증명이 여러 곳에 나뉘어 저장되기 때문에, 각각의 역할을 구분하지 않으면 토큰 하나만 보관하고도 백업이 끝났다고 생각하기 쉽다.
RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
문서는 많지만 필요한 순간에 찾기 어렵고, 검색 결과를 열어 일일이 내용을 비교해야 한다면 지식은 충분히 활용되지 못합니다. 이번 글에서는 문서와 업무 데이터를 자연어로 검색하고, 근거와 함께 답을 생성하는 RAG 시스템을 작은 범위에서 시작해 운영 가능한 구조로 확장한 과정을 정리합니다.
웹사이트를 운영하다 보면 루트 주소에서 robots.txt라는 작은 텍스트 파일을 만나게 됩니다. 내용은 몇 줄뿐인데 검색엔진 최적화 점검표에는 거의 빠지지 않고 등장합니다.
새 기능의 코드와 테스트가 모두 준비되어도 데이터베이스 테이블이 운영에 만들어지지 않으면 서비스는 시작할 수 없습니다. 문서 RAG 기능을 배포하는 과정에서 실제 배포 스크립트는 마이그레이션 파일을 적용하고 있었지만, 개발 지침에는 마이그레이션 파일을 만들지 말라고 적혀 있는 불일치를 발견했습니다.
데스크톱에서 잘 작동하는 AI 인터페이스를 모바일 화면에 그대로 줄이면 기능은 남지만 경험은 쉽게 무너집니다. 사이드바, 대화, 참고 문헌을 동시에 보여주는 3단 구조는 넓은 화면에서는 강력하지만 작은 화면에서는 탐색과 스크롤이 서로 경쟁합니다.
문서 RAG를 관리자 화면 안에서만 사용하다가 공개 웹 서비스로 확장하면 가장 먼저 바뀌어야 하는 것은 UI가 아니라 신뢰 경계입니다.
문서 AI 기능을 로컬에서 완성하고 운영에 배포했을 때, 답변 자체는 정상인데 화면의 느낌이 완전히 달라졌습니다. 스트리밍 답변은 한꺼번에 나타났고, 전체 화면 패널은 작은 섹션 안에 갇혔으며, 모달이 열리자마자 배경 스크롤 잠금이 풀렸습니다.
RAG 시스템에는 검색 결과가 질문과 충분히 관련 있는지 판단하는 기준이 필요합니다. 기준이 너무 낮으면 무관한 문서를 근거로 답하고, 너무 높으면 답이 있는 질문도 “근거가 없다”고 처리합니다.
문서 RAG를 처음 만들 때는 “문서를 검색하고 모델에 넣으면 된다”는 설명이 충분해 보입니다. 실제 서비스에 붙이기 시작하면 질문이 달라집니다. 문서를 언제 나누고, 어떤 기준으로 다시 색인하며, 관리자 문서와 공개 문서를 어떻게 분리하고, 답변의 근거를 사용자가 어떻게 확인하게 할 것인가가 중요해집니다.
문서 검색과 질의응답을 결합한 RAG 시스템을 만들 때 가장 먼저 떠오르는 질문은 대개 비슷합니다.
디자인 시스템이 두세 개로 늘어나면 가장 먼저 보이는 차이는 색상과 모서리입니다. 그래서 새로운 시스템을 만들 때 기존 버튼과 카드의 색만 바꾸는 일로 시작하기 쉽습니다. 하지만 시간이 지나면 각 시스템 폴더에 Button, Input, Dialog, Chart 구현이 하나씩 생깁니다. 처음에는 독립성이 높아 보이지만,…
Flutter 앱의 빌드 명령은 간단합니다. Android는 flutter build appbundle, iOS는 flutter build ipa로 결과물을 만들 수 있습니다. 그러나 팀이 반복해서 사용할 수 있는 배포 체계를 만들려면 그 뒤에 있는 서명, 권한, 스토어 API, 심사와 출시 절차까지 함께 설계해야 합니…
Expo를 사용하면 네이티브 빌드 과정이 크게 단순해집니다. 하지만 앱스토어 출시까지 명령어 한두 줄로 끝나는 것은 아닙니다. 실제 자동 배포를 만들려면 앱 등록, 서명 자격 증명, 스토어 API 권한, CI/CD 승인 절차가 먼저 준비되어야 합니다.
앞선 글에서는 이미 TestFlight에 올라간 iOS 빌드를 AI가 App Store 심사까지 제출한 과정을 다뤘습니다.
코드를 한 줄도 수정하지 않았는데 TestFlight에 올라가 있던 앱이 App Review 제출 상태로 바뀌었습니다. 얼핏 보면 AI가 앱을 새로 빌드해서 배포한 것처럼 보이지만, 실제로는 이미 준비된 빌드와 스토어 정보를 확인한 뒤 App Store Connect의 심사 절차를 진행한 것입니다.
빌드 모드(Debug/Release)와 배포 방식(Development/Ad Hoc/TestFlight)은 서로 다른 축입니다.