AI 자동화15분
RAG 대표 기술 한눈에 보기: 검색부터 GraphRAG까지
RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
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)은 서로 다른 축입니다.
앱을 콜드 스타트하면 흰 배경과 앱 아이콘으로 구성된 iOS 스플래시가 정상보다 오래 남습니다. 같은 TestFlight 빌드에서도 빠르게 열릴 때와 약 8초 동안 멈춘 것처럼 보일 때가 섞여 간헐적으로 재현됩니다.
성능 최적화에서 가장 당황스러운 순간은 개발 환경에서는 빠른데 배포 후 측정값만 크게 느릴 때입니다. 이번 랜딩 페이지가 그랬습니다. 개발 환경에서 관찰한 LCP는 약 1.68초였지만 PageSpeed Insights의 첫 측정은 5.5초까지 늘어났습니다. 이후 배포본을 다시 측정했을 때도 성능 점수 72점, LCP 4…
Docker 빌드가 느리면 패키지 설치나 애플리케이션 컴파일부터 보게 됩니다. 저도 타입 검사 실패를 고치는 데 집중하다가 그보다 앞선 load build context 단계에서 40초가 넘게 쓰이고 있다는 사실을 뒤늦게 봤습니다. 실패 원인과는 별개였지만, 매 배포마다 반복되는 낭비였습니다.
Next.js 앱에서 로컬 타입 검사는 통과하는데 Docker 배포에서만 같은 오류가 다시 나오면 코드보다 빌드 이미지에 무엇이 들어갔는지 봐야 합니다. 이번 작업에서는 린트, 타입 검사, 프로덕션 빌드를 모두 통과시킨 뒤 배포했는데 원격 빌드만 실패했습니다. 같은 커밋과 같은 잠금 파일을 썼으니 처음에는 환경 차이가 …
Expo 앱의 app.json을 고친 뒤 저장소에 푸시했습니다. production 채널의 OTA 작업도 평소처럼 실행됐습니다. 배포 작업이 성공하면 변경 사항이 앱에 들어간 것처럼 느껴집니다. 이번에는 그렇지 않았습니다.
앱스토어 심사라고 하면 사람이 아이폰을 들고 앱을 하나씩 눌러 보는 장면부터 떠올리기 쉽습니다. 저도 그랬습니다. 그런데 iOS 앱을 제출한 뒤 받은 반려 메시지에는 automated analysis라는 표현이 적혀 있었습니다. 사람 심사관의 판단을 기다리기도 전에 업로드한 바이너리의 권한 문구가 자동 분석에서 걸린 경…
Next.js 애플리케이션은 운영 빌드가 안정적이면 개발 서버도 같은 방식으로 움직일 것 같지만, 둘은 클라이언트 코드의 수명이 다릅니다. 제가 확인한 환경은 Next.js 16.2.7과 Turbopack이었고, 운영 사이트에서는 잘 눌리던 상단 메뉴가 로컬 개발 서버에서만 간헐적으로 먹통이 됐습니다.
브랜드 인트로를 만들면서 출발점은 로고 모양이 아니라 문자 수였습니다. DUOLABS AI STUDIO를 적어 놓고 중복을 걷어내니 남는 글자는 D, U, O, L, A, B, S, I, T 아홉 개였습니다. 3×3 격자 하나를 채우기에 정확한 숫자였습니다.
페이지 이동을 빠르게 보이게 만드는 장치는 대개 눈에 잘 띄지 않습니다. 미리 다음 화면을 받아 두거나, 서버 응답을 기다리는 동안 스켈레톤을 보여주는 식입니다. 이번에는 그 두 가지가 한꺼번에 작동하면서 오히려 이동을 늦추고 화면 상태까지 헷갈리게 만들었습니다.
웹 앱의 화면 가장자리는 평소에는 눈에 잘 들어오지 않습니다. 콘텐츠와 배경이 자연스럽게 이어지면 굳이 볼 이유가 없기 때문입니다. 그런데 여러 화면을 확인하던 중 오른쪽 끝에 비어 보이는 세로 띠가 계속 눈에 걸렸습니다. 어떤 화면에서는 나타나고, 어떤 화면에서는 덜 보였습니다.
웹사이트는 공개 버튼을 누르는 순간 완성되는 것이 아니라 운영이 시작된다. 담당자, 지표, 콘텐츠 갱신, 보안 업데이트, 백업과 복구 절차가 없으면 잘 만든 사이트도 빠르게 낡는다. 이 글에서는 소규모 팀도 지속할 수 있는 웹사이트 운영 체계를 만드는 방법을 다룬다.
디자인 시안을 웹으로 옮길 때 핵심은 픽셀을 그대로 복사하는 것이 아니라, 콘텐츠의 의미와 반복 규칙을 브라우저가 이해할 수 있는 구조로 번역하는 것이다. 이 글에서는 시맨틱 HTML, 디자인 토큰, 컴포넌트, 반응형 규칙을 이용해 시안을 유지보수 가능한 코드로 구현하는 순서를 살펴본다.
좋은 웹사이트 기획은 화면을 많이 그리는 일이 아니라, 방문자가 해야 할 일을 콘텐츠와 구조로 명확하게 만드는 일이다. 이 글에서는 첫 코드를 작성하기 전에 목표, 사용자, 콘텐츠, 페이지 구조, URL, 접근성 기준을 하나의 실행 가능한 문서로 정리하는 방법을 다룬다.
웹 레이아웃은 화면을 몇 칸으로 나눌지 정하는 작업이 아닙니다. 콘텐츠의 읽기 순서를 먼저 세우고, 넓이가 달라져도 그 순서와 기능이 무너지지 않도록 공간의 규칙을 만드는 작업입니다.
Expo 앱을 배포한다고 하면 보통 eas build 명령 하나를 떠올립니다. 실제 운영 배포는 빌드, 앱 서명, 스토어 업로드, 베타 테스트, 심사, 공개 출시, OTA 업데이트가 서로 다른 단계입니다. 이 구분을 놓치면 CI가 성공했는데 스토어에는 앱이 없거나, JavaScript 수정이라고 생각해 OTA를 발행했는…
예전에는 Google이나 네이버 검색 결과의 상단에 노출되는 것이 목표였습니다. 이제는 AI Overview, AI Mode와 여러 답변형 서비스가 웹 문서를 요약해 답을 만들면서 AEO와 GEO라는 표현도 자주 보입니다.
광고를 시작하려고 하면 네이버 검색광고, 구글 검색광고, 인스타그램 광고 중 어디에 돈을 써야 할지부터 막힙니다. 세 채널 모두 고객을 데려오는 광고지만 맡은 역할은 다릅니다.
인스타그램 릴스 하나를 광고하면 얼마가 들까. 페이스북 광고는 릴스보다 저렴할까. 틱톡이나 유튜브 쇼츠까지 같이 집행해야 할까.
Polar.sh와 토스페이먼츠는 모두 웹사이트에 결제를 붙일 때 검토할 수 있는 서비스입니다. 하지만 둘은 같은 종류의 결제대행사가 아닙니다.
앱 개발 상담에서 자주 나오는 질문이 있습니다. "Flutter와 React Native 중 무엇이 더 좋은가요?"
한국어, 영어, 일본어, 중국어를 직접 제공하는 React 랜딩 페이지에서 예상하지 못한 문제가 생겼습니다. Chrome이 띄운 "이 페이지를 번역하시겠습니까?" 제안을 수락하면 번역이 시작되는 듯하다가, 잠시 뒤 사이트의 "일시적인 오류가 발생했습니다" 화면으로 바뀌었습니다.
웹사이트를 만들었다고 네이버 검색 결과에 바로 나타나는 것은 아닙니다. 검색로봇이 사이트를 발견하고, 문서를 수집하고, 색인할 수 있어야 합니다. 네이버 서치어드바이저는 이 과정을 직접 보장하는 등록 창구라기보다 사이트 소유권을 확인하고 수집·색인 상태를 점검하는 운영 도구에 가깝습니다.