웹 인프라14분
블로그를 서브도메인에서 하위 경로로 옮긴 이유, 그리고 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가 아니라 신뢰 경계입니다.
문서 AI 기능을 로컬에서 완성하고 운영에 배포했을 때, 답변 자체는 정상인데 화면의 느낌이 완전히 달라졌습니다. 스트리밍 답변은 한꺼번에 나타났고, 전체 화면 패널은 작은 섹션 안에 갇혔으며, 모달이 열리자마자 배경 스크롤 잠금이 풀렸습니다.
RAG 시스템에는 검색 결과가 질문과 충분히 관련 있는지 판단하는 기준이 필요합니다. 기준이 너무 낮으면 무관한 문서를 근거로 답하고, 너무 높으면 답이 있는 질문도 “근거가 없다”고 처리합니다.
문서 RAG를 처음 만들 때는 “문서를 검색하고 모델에 넣으면 된다”는 설명이 충분해 보입니다. 실제 서비스에 붙이기 시작하면 질문이 달라집니다. 문서를 언제 나누고, 어떤 기준으로 다시 색인하며, 관리자 문서와 공개 문서를 어떻게 분리하고, 답변의 근거를 사용자가 어떻게 확인하게 할 것인가가 중요해집니다.
문서 검색과 질의응답을 결합한 RAG 시스템을 만들 때 가장 먼저 떠오르는 질문은 대개 비슷합니다.
챗봇 답변을 한 글자씩 흘려보내는 것은 기술적 과시가 아닙니다. 사람이 기다릴 수 있게 만드는 장치입니다. 같은 5초라도 빈 화면을 보는 5초와 글자가 차오르는 5초는 완전히 다른 시간입니다.
서비스를 운영하다 보면 GitHub 토큰, 데이터베이스 비밀번호, API 키, 배포 인증서, 백업 암호화 키가 빠르게 늘어납니다. 처음에는 비밀번호 관리 앱의 메모나 여러 .env 파일에 저장해도 괜찮아 보이지만, 키가 많아질수록 “무엇이 최신인지”, “개발용인지 운영용인지”, “어디에서 사용 중인지”를 판단하기 어려워…
같은 날 확인된 세 증상은 원인이 서로 달랐으며, 모두 해당 테스트 환경에서 데스크톱 Chrome과 다르게 나타난 WebKit 관련 동작이었습니다.
같은 디자인 시스템을 사용하는데도 어떤 화면은 정돈되어 보이고, 어떤 화면은 미묘하게 어긋나 보일 때가 있습니다. 색상과 버튼 모양이 같아도 페이지 폭, 여백, 제목 위치, 입력 필드의 구성이 제각각이면 전체 인상은 쉽게 흐트러집니다.
디자인 시스템이 두세 개로 늘어나면 가장 먼저 보이는 차이는 색상과 모서리입니다. 그래서 새로운 시스템을 만들 때 기존 버튼과 카드의 색만 바꾸는 일로 시작하기 쉽습니다. 하지만 시간이 지나면 각 시스템 폴더에 Button, Input, Dialog, Chart 구현이 하나씩 생깁니다. 처음에는 독립성이 높아 보이지만,…
Flutter 앱의 빌드 명령은 간단합니다. Android는 flutter build appbundle, iOS는 flutter build ipa로 결과물을 만들 수 있습니다. 그러나 팀이 반복해서 사용할 수 있는 배포 체계를 만들려면 그 뒤에 있는 서명, 권한, 스토어 API, 심사와 출시 절차까지 함께 설계해야 합니…
Expo를 사용하면 네이티브 빌드 과정이 크게 단순해집니다. 하지만 앱스토어 출시까지 명령어 한두 줄로 끝나는 것은 아닙니다. 실제 자동 배포를 만들려면 앱 등록, 서명 자격 증명, 스토어 API 권한, CI/CD 승인 절차가 먼저 준비되어야 합니다.
앞선 글에서는 이미 TestFlight에 올라간 iOS 빌드를 AI가 App Store 심사까지 제출한 과정을 다뤘습니다.
사내에 AI를 도입하려는 회사가 가장 먼저 부딪히는 질문이 있습니다. "모델 하나면 되는 것 아닌가요?"
코드를 한 줄도 수정하지 않았는데 TestFlight에 올라가 있던 앱이 App Review 제출 상태로 바뀌었습니다. 얼핏 보면 AI가 앱을 새로 빌드해서 배포한 것처럼 보이지만, 실제로는 이미 준비된 빌드와 스토어 정보를 확인한 뒤 App Store Connect의 심사 절차를 진행한 것입니다.
빌드 모드(Debug/Release)와 배포 방식(Development/Ad Hoc/TestFlight)은 서로 다른 축입니다.
앱을 콜드 스타트하면 흰 배경과 앱 아이콘으로 구성된 iOS 스플래시가 정상보다 오래 남습니다. 같은 TestFlight 빌드에서도 빠르게 열릴 때와 약 8초 동안 멈춘 것처럼 보일 때가 섞여 간헐적으로 재현됩니다.
무료 티어에서 걸린 문제들을 Pro 요금제로 올리면 몇 개가 사라질까. 세어보니 용량 문제는 전부 지워졌는데 블로커는 오히려 하나 늘었다. 돈으로 사는 것과 못 사는 것의 경계에 대한 기록.
잘 돌아가던 개인 프로젝트를 Vercel과 Supabase 무료 티어로 옮길 수 있을지 검토했다. 요금제 한도표부터 보는 대신 코드를 먼저 읽었고, 진짜 제약은 숫자가 아니라 실행 모델 쪽에 있었다.
Expo 앱을 개발하다 보면 명령어보다 “지금 다시 빌드해야 하나?”가 더 헷갈립니다. 화면 코드만 바꿨는데 Gradle 빌드를 다시 돌리기도 하고, 반대로 스플래시 이미지를 바꾼 뒤 Metro만 재시작해서 왜 그대로인지 한참 보기도 합니다.
Vercel 같은 서버리스 환경에 백그라운드 작업 큐와 요청 제한을 붙이려고 문서를 펼치면
웹 서비스를 만들다 보면 이런 값들을 자주 다룹니다.
Next.js로 웹 서비스를 만들 때 AWS 서비스를 하나씩 고르면 꽤 긴 목록이 나온다. CDN, API 입구, 함수 실행, PostgreSQL, 인증, 파일 저장, Redis, Queue, 이벤트 예약, 배포 파이프라인이 각각 다른 서비스다.
서버리스 프로젝트에 Worker를 붙일 때 QStash가 반드시 필요한 것은 아니다. 이미 Supabase를 사용하고 있다면 PostgreSQL 기반의 Supabase Queues로 작업을 저장하고, Vercel 함수가 메시지를 가져가 처리하는 구조를 만들 수 있다.
Vercel은 코드를 실행하고, Supabase는 데이터를 영구 저장하며, QStash는 비동기 작업을 전달한다. 여기까지 이해하고 나면 Redis의 자리가 모호하게 느껴질 수 있다.
서버리스 프로젝트에 비동기 처리를 추가하려고 하면 서비스 구성이 갑자기 복잡해 보인다. Vercel, Supabase, Upstash까지 연결했는데 Worker라는 이름이 하나 더 등장하기 때문이다.
Supabase를 처음 접하면 관리형 PostgreSQL 서비스로 이해하기 쉽습니다. 실제로 PostgreSQL은 Supabase의 중심이지만, 전체 제품은 데이터베이스보다 훨씬 넓은 범위를 다룹니다.
Vercel에 앱을 올리고, Supabase에 데이터를 저장하고, Upstash Redis로 요청 제한을 걸고, QStash로 비동기 작업을 전달한다고 해보자. 서비스 이름만 네 개다. 이쯤 되면 자연스럽게 이런 생각이 든다.
홈페이지 플랫폼 이전은 새 화면을 만드는 작업만이 아닙니다. 기존 URL과 검색 노출, 도메인과 회사 메일, 게시물과 이미지, 문의 폼, 분석 태그까지 함께 옮겨야 비로소 이전이 끝납니다.
아임웹이나 카페24로 시작한 사이트가 성장하면 어느 순간 “이제 맞춤 개발을 해야 할까?”라는 질문이 생깁니다. 관리자 화면 밖의 엑셀 작업이 늘고, 앱과 외부 서비스를 계속 붙이는데도 업무가 매끄럽지 않기 때문입니다.
서버리스 서비스를 구성하다 보면 Supabase, QStash, Redis가 한 화면에 함께 등장합니다. 모두 데이터를 다루는 것처럼 보여 처음에는 무엇을 어디에 써야 하는지 헷갈리기 쉽습니다.
Flutter 프로젝트를 다른 컴퓨터로 옮길 때 가장 흔한 착각은 “Git 저장소만 clone하면 되겠지”라는 생각입니다. 소스 코드는 돌아오지만 .gitignore에 들어간 환경 파일, Firebase 설정, 앱 서명 키가 빠져 있으면 개발 빌드부터 스토어 업데이트까지 곳곳에서 막힙니다.
온프레미스에서 서비스를 운영하면 애플리케이션, 데이터베이스, Redis, WebSocket 서버와 백그라운드 워커를 한 네트워크 안에 둘 수 있습니다. 프로세스를 계속 띄워두기도 쉽습니다. setInterval로 10초마다 데이터베이스를 확인하는 코드도 일단은 잘 동작합니다.
쇼핑몰은 보기 좋은 상품 페이지 하나로 완성되지 않습니다. 상품 옵션, 재고, 결제, 취소·교환·반품, 배송, 회원, 쿠폰, 정산과 고객 문의가 연결되어야 합니다. 그래서 쇼핑몰 플랫폼은 디자인보다 판매 후 운영 흐름을 먼저 비교해야 합니다.
회사 홈페이지를 만들 때 반드시 Next.js 같은 개발 프레임워크가 필요한 것은 아닙니다. 회사 소개, 서비스 설명, 구축 사례와 문의 접수가 중심이라면 홈페이지 빌더나 CMS가 더 빠르고 운영하기 쉬울 수 있습니다.
웹사이트를 만들 때 자주 듣는 이름으로 Vercel, Cloudflare Pages, Netlify가 있습니다. 여기에 AWS나 직접 관리하는 서버까지 더하면 선택지가 너무 많아 보입니다. 하지만 먼저 구분할 것이 있습니다. 이들은 완성된 홈페이지를 만들어 주는 서비스가 아니라, 개발자가 작성한 코드를 빌드하고 실행하는…
GitHub에 커밋을 푸시하면 자동으로 서비스가 배포됩니다. 겉으로 보면 GitHub Actions의 Self-hosted Runner와 Vercel은 똑같아 보입니다.
코드를 수정하고 로컬에서 잘 동작하는 것까지 확인했습니다. 이제 아래처럼 GitHub에 올립니다.
웹사이트는 화면과 기능이 완성됐다고 바로 공개할 수 있는 상태가 되는 것은 아닙니다. 실제 사용자가 느끼는 속도, HTTP 보안 헤더, HTTPS 설정, 키보드 접근성, 구조화 데이터, DNS 설정은 서로 다른 문제입니다.
랜딩페이지를 만들 때도 백엔드가 필요하다고 생각하는 경우가 있다. 반대로 로그인, 예약, 결제와 파일 업로드가 있는 서비스를 단순 홈페이지처럼 구성하려는 경우도 있다.
한 애플리케이션을 여러 회사가 함께 사용하는 SaaS에서는 로그인보다 테넌트 경계가 더 중요하다. 사용자가 정상적으로 로그인했더라도 다른 회사의 계약, 직원, 파일, 검색 결과를 볼 수 있다면 인증은 성공했지만 데이터 격리는 실패한 것이다.
사내 시스템은 외부 고객 서비스보다 사용자가 적다는 이유로 공개 전 점검이 짧아지기 쉽다. 하지만 결재, 계약, 인사, 회계처럼 업무의 기준이 되는 시스템은 한 번의 권한 오류나 데이터 손실도 실제 업무 중단으로 이어진다.
사내 시스템의 좋은 아키텍처는 가장 큰 서버나 가장 복잡한 기술 조합이 아니다. 현재 업무를 무리 없이 지원하고, 문제가 생겼을 때 되돌릴 수 있으며, 사용자가 늘면 필요한 부분만 확장할 수 있는 구조다.
월 10달러 안팎의 VPS를 보면 Vercel, Supabase 같은 관리형 서비스를 합친 것보다 훨씬 저렴해 보인다. 실제로 안정적인 부하가 있고 서버를 운영할 사람이 있다면 VPS가 경제적일 수 있다. 하지만 인스턴스 가격만 비교하면 백업, 저장 공간, 전송량, 보안 패치, 장애 대응 시간이 빠진다.
클라우드 비용은 서버 한 대의 월정액처럼 움직이지 않는다. 트래픽, 함수 실행 시간, DB 용량, 로그, 파일 전송, 실시간 연결이 각각 늘어난다. 작은 코드 실수나 공개된 API 키 하나가 짧은 시간에 사용량을 키울 수도 있다.
빠른 롤백은 사람이 명령어를 빨리 입력하는 능력이 아니다. 이전 버전이 무엇인지 알고, 같은 산출물을 다시 실행할 수 있고, DB가 이전 코드와 호환되도록 미리 설계한 결과다. 준비 없이 배포한 뒤 5분 안에 되돌리겠다는 목표는 지키기 어렵다.
브라우저가 파일을 애플리케이션 서버에 보내고, 서버가 다시 객체 저장소로 전달하는 방식은 이해하기 쉽다. 하지만 파일이 커지면 서버는 같은 데이터를 두 번 전송하고, 메모리와 실행 시간을 오래 점유한다. 서버리스 환경의 본문 크기 제한에도 걸리기 쉽다.
보고서 생성, 대량 메일, 이미지 변환, 외부 API 수집을 일반 API 요청 안에서 끝내려 하면 처음에는 단순해 보인다. 하지만 실행 시간이 길어질수록 브라우저, 프록시, 서버리스 함수 중 하나가 먼저 연결을 끊을 가능성이 커진다. 사용자가 다시 누르면 같은 작업이 중복 실행되기도 한다.
실시간 기능이 필요하다는 말은 요구사항이 아니다. 사용자가 몇 초 늦게 봐도 되는지, 서버에서 브라우저로만 보내면 되는지, 양쪽이 계속 메시지를 주고받아야 하는지부터 정해야 한다. 이 질문에 답하면 Polling, SSE, WebSocket, Supabase Realtime 중 선택이 쉬워진다.
모든 장애를 미리 예측할 수는 없다. 대신 사용자가 먼저 알려 주기 전에 이상을 발견하고, 원인을 좁힐 자료를 남기고, 같은 장애가 반복되지 않게 만들 수는 있다. 소규모 서비스의 모니터링은 비싼 도구보다 적은 수의 정확한 신호에서 시작하는 편이 낫다.
백업이 성공했다는 알림은 데이터를 되살릴 수 있다는 보증이 아니다. 파일이 손상됐거나, 필요한 암호화 키가 없거나, 복구 순서를 아무도 모르면 백업은 있어도 업무를 재개할 수 없다. 사내 시스템의 백업 설계는 저장 횟수보다 복구 목표와 복원 시험에서 시작해야 한다.
VPS를 만들면 몇 분 안에 공인 IP가 생기고 인터넷에서 접속할 수 있다. 편리하지만 그 순간부터 자동 스캔과 로그인 시도의 대상이 된다. 애플리케이션을 올리기 전에 운영체제와 접속 경로부터 잠그는 이유다.
사내 시스템은 직원 수가 적다고 해서 항상 가볍지 않다. 20명이 쓰는 문서 변환 시스템은 100명이 쓰는 단순 결재 시스템보다 더 많은 CPU와 저장 공간을 요구할 수 있다. 그래서 배포 구조는 인원수보다 동시 접속, 요청 시간, 파일 크기, 실시간 연결 수, 장애 허용 시간을 기준으로 정해야 한다.
사내 시스템을 처음 만들 때는 Vercel, Supabase 같은 관리형 서비스를 조합하는 것이 효율적이다. 서버를 직접 관리하지 않아도 되고 사용자가 적은 시기에는 비용도 낮다.
웹 서비스에는 첨부 파일, 프로필 이미지, 업무 문서, 내보내기 파일과 백업 데이터를 저장할 공간이 필요하다. 대표적인 선택지는 Amazon S3와 Cloudflare R2다. 두 서비스 모두 안정적인 객체 스토리지지만 비용 구조와 강점은 꽤 다르다.
Next.js 서비스의 웹 화면과 API는 Vercel에 올릴 수 있지만, 모든 프로세스를 같은 방식으로 배포할 수 있는 것은 아닙니다. WebSocket 연결을 오래 유지하는 실시간 서버와 큐를 계속 확인하는 백그라운드 워커는 일반적인 웹 요청과 실행 방식이 다릅니다.
웹과 모바일 앱을 함께 제공하는 서비스를 배포할 때는 화면을 올리는 비용만 계산해서는 안 됩니다. 데이터베이스, 캐시, 실시간 통신, 백그라운드 작업, 이미지 저장소까지 포함해야 실제 운영비에 가까워집니다.
사내 시스템을 만들 때 가장 자주 나오는 질문 중 하나는 "직원 수가 늘어나면 서버 비용도 같은 비율로 늘어나는가"입니다. Vercel과 Supabase 조합에서는 직원 수보다 배포를 관리하는 개발자 수, 동시에 발생하는 요청, 데이터베이스 쿼리와 배치 작업이 비용에 더 큰 영향을 줍니다.
사내 시스템을 새로 만들 때 인프라를 처음부터 크게 잡아야 할지 고민하게 됩니다. 특히 Supabase Pro를 검토하면 Micro와 Small의 월 비용 차이는 크지 않지만, 어떤 기준으로 선택해야 하는지는 가격표만 보고 판단하기 어렵습니다.
부동산 운영에서는 공간의 상태가 계속 바뀝니다. 매물이 계약되고, 임대 기간이 지나며, 입주사의 요청이 생깁니다. 정보를 각각 관리하면 공실·갱신·민원 대응의 우선순위를 놓치기 쉽습니다. DUOLABS CP는 공간을 중심으로 세 가지 업무를 연결합니다.
물류 업무는 출발 전 배차, 이동 중 배송 상태, 운행 후 차량 기록이 이어져야 합니다. 각각을 전화와 종이로 관리하면 중복 배차나 인수 확인 누락, 운행거리 불일치가 생기기 쉽습니다. DUOLABS CP는 이 흐름을 세 개의 모듈로 정리합니다.
현장은 매일 상황이 바뀝니다. 작업 기록, 계획 대비 진척, 안전 지적, 자재 이동이 따로 남으면 사무실에서는 문제를 늦게 알게 됩니다. DUOLABS CP의 건설·현장 영역은 현장 보고와 후속 조치를 하나의 관리 흐름으로 보는 예시입니다.
클리닉의 운영 화면은 진료 판단을 대신하는 시스템이 아니라 환자가 기다리고, 수납하고, 다음 방문을 안내받는 과정이 끊기지 않게 도와야 합니다. DUOLABS CP의 의료·클리닉 영역은 비진료 운영에 초점을 맞춘 세 가지 화면을 보여 줍니다.
학원 운영 정보는 학생 명단, 출결표, 수강료 장부, 성적표로 쉽게 나뉩니다. 각각은 관리되어도 보호자에게 필요한 설명이나 미납·결석 대응은 늦어질 수 있습니다. DUOLABS CP의 교육·학원 영역은 학생 한 명의 운영 정보를 네 가지 관점에서 이어 봅니다.
매장 운영에서는 주문이 많아도 원가와 폐기, 발주를 놓치면 이익이 남지 않습니다. 홀과 주방의 상태도 서로 달라 고객 대기와 조리 지연이 생깁니다. DUOLABS CP의 요식·매장 영역은 메뉴 원가, 식자재 발주, 테이블 주문을 하나의 운영 이야기로 묶습니다.
이커머스 운영은 주문 목록만으로 설명되지 않습니다. 상품 옵션의 가격이 맞아야 하고, 배송 상태가 이어져야 하며, 반품 뒤 환불과 채널 수수료까지 정리되어야 실제 이익을 알 수 있습니다. DUOLABS CP는 이 과정을 네 개의 업무 화면으로 나눕니다.
고객지원의 품질은 답변 속도만으로 결정되지 않습니다. 문의가 담당자를 만나고, 같은 질문의 답이 지식으로 남고, 고객 혜택의 변동까지 추적되어야 일관된 경험이 만들어집니다. DUOLABS CP는 문의 티켓, 지식베이스, 포인트 원장을 각각의 모듈로 보여 줍니다.
돈과 관련된 업무는 숫자가 맞는 것만큼 처리 상태가 분명한 것이 중요합니다. 매출은 잡혔지만 세금계산서가 발행되지 않았거나, 급여 계산은 끝났지만 지급 확인이 빠지는 식의 틈이 생기기 때문입니다. DUOLABS CP의 회계·재무 영역은 월별 운영에 필요한 세 화면을 정리합니다.
예약 기반 사업은 시간표만 관리해서 끝나지 않습니다. 노쇼를 줄이고, 회원권 잔여 횟수를 확인하고, 강사와 공간의 정원을 맞춰야 실제 운영이 안정됩니다. DUOLABS CP는 이 세 가지를 서로 연결할 수 있는 기본 단위로 나눠 보여 줍니다.
제조·유통 현장은 재고, 생산, 품질, 설비, 출하가 서로 영향을 줍니다. 그런데 각 단계가 다른 엑셀로 나뉘면 부족 재고나 지연이 뒤늦게 발견됩니다. DUOLABS CP의 제조·유통 영역은 현장의 주요 신호를 한 흐름으로 이어 보는 예시입니다.
영업 정보가 명함, 메신저, 견적 파일, 담당자의 머릿속에 나뉘면 ‘누구에게 무엇을 약속했는지’부터 다시 확인해야 합니다. DUOLABS CP의 영업·매출 영역은 잠재 고객을 발견한 순간부터 견적, 수주, 계약 갱신까지 이어지는 흐름을 보여 줍니다.
백오피스의 출발점은 화려한 대시보드보다 매일 반복되는 일을 빠뜨리지 않는 것입니다. 결재는 메신저에, 근태는 엑셀에, 자산은 담당자의 기억에 흩어져 있으면 작은 확인에도 여러 사람의 시간이 듭니다. DUOLABS CP의 공통 업무 영역은 이런 기본 업무를 하나의 운영 화면으로 모은 예시입니다.
백오피스는 회사마다 다릅니다. 같은 ‘예약’이라도 미용실은 디자이너와 시술 시간을 보고, 학원은 강사·강의실·정원을 함께 봅니다. 범용 프로그램에 업무를 억지로 맞추기보다 필요한 기능을 골라 현재의 규칙에 맞추는 접근이 필요한 이유입니다.
DUOLABS AI 기능 탐구 서른 번째 글은 브리프, 채널, 문체와 브랜드 용어를 기준으로 콘텐츠를 만들고 버전을 비교하는 콘텐츠 스튜디오입니다.
DUOLABS AI 기능 탐구 스물아홉 번째 글은 회의와 통화 전사록에서 참가자, 요약, 결정 사항과 담당자별 할 일을 구조화하는 회의·통화 인텔리전스입니다.
DUOLABS AI 기능 탐구 스물여덟 번째 글은 문서 유형을 분류하고 핵심 요약, 필드와 검토 위험을 구조화하는 문서 인텔리전스입니다.
DUOLABS AI 기능 탐구 스물일곱 번째 글은 CSV·TSV 데이터를 빠르게 프로파일링하고 자연어 질문에 답하는 AI 데이터 분석가입니다.
DUOLABS AI 기능 탐구 스물여섯 번째 글은 실행 원장의 오류율, 지연, 비용과 실행 수를 임계값으로 감시하는 알림·SLA 센터입니다.
DUOLABS AI 기능 탐구 스물다섯 번째 글은 워크플로를 일정에 맞춰 실행하고 다음 실행과 최근 상태를 관리하는 예약·스케줄 기능입니다.
DUOLABS AI 기능 탐구 스물네 번째 글은 평가 입력과 기대 결과를 모으고 버전으로 관리하는 데이터셋 연구소입니다.
DUOLABS AI 기능 탐구 스물세 번째 글은 저신뢰·고위험 AI 결과를 한곳에 모아 승인하거나 반려하는 사람 검토함입니다.
DUOLABS AI 기능 탐구 스물두 번째 글은 업무 시스템과 문서 저장소를 AI 흐름에 연결하고 상태를 관리하는 커넥터 허브입니다.
DUOLABS AI 기능 탐구 스물한 번째 글은 생성, 구조화, 사람 검토와 결과 확정을 하나의 실행 흐름으로 묶는 워크플로 스튜디오입니다.
DUOLABS AI 기능 탐구 스무 번째 글은 API 키 원문을 화면에 노출하지 않고 설정 상태와 공급자 연결을 점검하는 키 보관함입니다.
DUOLABS AI 기능 탐구 열아홉 번째 글은 표현은 달라도 의미가 비슷한 질문에 저장된 답변을 재사용하는 시맨틱 캐시입니다.
DUOLABS AI 기능 탐구 열여덟 번째 글은 실행 기록을 모아 토큰, 추정 비용과 로컬 처리 비중을 분석하는 사용량·비용 대시보드입니다.
DUOLABS AI 기능 탐구 열일곱 번째 글은 같은 평가 항목으로 여러 모델의 답변을 만들고 점수와 근거를 비교하는 평가 매트릭스입니다.
DUOLABS AI 기능 탐구 열여섯 번째 글은 여러 AI 기능의 실행 결과를 하나의 원장에 모으고 단계별 흐름과 오류를 확인하는 실행 트레이스입니다.
DUOLABS AI 기능 탐구 열다섯 번째 글은 에이전트가 사용할 수 있는 도구의 입력 규격을 확인하고 직접 실행해 보는 도구 카탈로그입니다.
DUOLABS AI 기능 탐구 열네 번째 글은 로컬·클라우드 LLM 인프라의 상태와 모델 배치를 공간적으로 보여주는 3D 서버룸입니다.
DUOLABS AI 기능 탐구 열세 번째 글은 연결된 AI 서버와 모델을 확인하고, 업무 유형마다 기본 모델을 지정하는 모델 콘솔입니다.
DUOLABS AI 기능 탐구 열두 번째 글은 번역할 때마다 달라지기 쉬운 제품명과 업무 용어를 용어집으로 고정하고, 결과가 규칙을 지켰는지 확인하는 번역·현지화입니다.
DUOLABS AI 기능 탐구 열한 번째 글은 같은 프롬프트를 여러 모델에 동시에 보내 결과와 실행 지표를 비교하는 플레이그라운드입니다.
DUOLABS AI 기능 탐구 열 번째 글은 외부 시스템의 이벤트를 받아 구조화 추출이나 에이전트를 실행하는 통합·웹훅입니다.
DUOLABS AI 기능 탐구 아홉 번째 글은 반복해서 사용하는 프롬프트를 변수와 버전으로 관리하는 프롬프트 라이브러리입니다.
DUOLABS AI 기능 탐구 여덟 번째 글은 AI의 역할, 시스템 프롬프트, 사용할 모델과 도구 권한을 하나로 묶어 저장하는 에이전트 빌더입니다.
DUOLABS AI 기능 탐구 일곱 번째 글은 대화만 하는 AI를 넘어, 질문에 필요한 도구를 직접 선택해 호출하는 AI 어시스턴트입니다.
DUOLABS AI 기능 탐구 여섯 번째 글은 고객 문의의 의도를 판별하고 알맞은 담당 흐름을 선택하는 분류·라우팅입니다.
DUOLABS AI 기능 탐구 다섯 번째 글은 여러 건의 텍스트를 같은 규칙으로 반복 처리하는 배치 자동화입니다.
DUOLABS AI 기능 탐구 네 번째 글은 이미지 속 글자와 항목을 읽어 표와 JSON 데이터로 바꾸는 비전·OCR입니다.
DUOLABS AI 기능 탐구 세 번째 글은 이메일, 문서, 메모처럼 형식이 일정하지 않은 텍스트를 원하는 표와 JSON 구조로 바꾸는 추출 스튜디오입니다.
DUOLABS AI 기능 탐구 두 번째 글은 AI에 텍스트를 보내기 전에 개인정보를 찾아 가리는 가드레일·PII 마스킹입니다.
DUOLABS AI의 기능을 하나씩 살펴보는 연속 기획 첫 번째 글입니다. 첫 주제는 사내 문서에서 근거를 찾아 답하는 지식베이스와 RAG 질의응답입니다.
고객은 궁금한 순간에 바로 답을 원하지만, 모든 문의에 사람이 즉시 대응하기는 어렵습니다. 특히 영업시간 밖의 질문, 반복되는 이용 방법 문의, 담당 부서 연결 요청이 쌓이면 고객의 대기 시간과 실무자의 피로가 함께 늘어납니다.
웹사이트 주소를 카카오톡이나 슬랙에 공유하면 제목, 설명과 함께 대표 이미지가 표시됩니다. 이 이미지를 흔히 OG 이미지라고 부릅니다.
웹사이트는 공개 버튼을 누르는 순간 완성되는 것이 아니라 운영이 시작된다. 담당자, 지표, 콘텐츠 갱신, 보안 업데이트, 백업과 복구 절차가 없으면 잘 만든 사이트도 빠르게 낡는다. 이 글에서는 소규모 팀도 지속할 수 있는 웹사이트 운영 체계를 만드는 방법을 다룬다.
디자인 시안을 웹으로 옮길 때 핵심은 픽셀을 그대로 복사하는 것이 아니라, 콘텐츠의 의미와 반복 규칙을 브라우저가 이해할 수 있는 구조로 번역하는 것이다. 이 글에서는 시맨틱 HTML, 디자인 토큰, 컴포넌트, 반응형 규칙을 이용해 시안을 유지보수 가능한 코드로 구현하는 순서를 살펴본다.
좋은 웹사이트 기획은 화면을 많이 그리는 일이 아니라, 방문자가 해야 할 일을 콘텐츠와 구조로 명확하게 만드는 일이다. 이 글에서는 첫 코드를 작성하기 전에 목표, 사용자, 콘텐츠, 페이지 구조, URL, 접근성 기준을 하나의 실행 가능한 문서로 정리하는 방법을 다룬다.
웹 레이아웃은 화면을 몇 칸으로 나눌지 정하는 작업이 아닙니다. 콘텐츠의 읽기 순서를 먼저 세우고, 넓이가 달라져도 그 순서와 기능이 무너지지 않도록 공간의 규칙을 만드는 작업입니다.
Polar.sh와 토스페이먼츠는 모두 웹사이트에 결제를 붙일 때 검토할 수 있는 서비스입니다. 하지만 둘은 같은 종류의 결제대행사가 아닙니다.
앱 개발 상담에서 자주 나오는 질문이 있습니다. "Flutter와 React Native 중 무엇이 더 좋은가요?"
한국어, 영어, 일본어, 중국어를 직접 제공하는 React 랜딩 페이지에서 예상하지 못한 문제가 생겼습니다. Chrome이 띄운 "이 페이지를 번역하시겠습니까?" 제안을 수락하면 번역이 시작되는 듯하다가, 잠시 뒤 사이트의 "일시적인 오류가 발생했습니다" 화면으로 바뀌었습니다.
웹사이트를 만들었다고 네이버 검색 결과에 바로 나타나는 것은 아닙니다. 검색로봇이 사이트를 발견하고, 문서를 수집하고, 색인할 수 있어야 합니다. 네이버 서치어드바이저는 이 과정을 직접 보장하는 등록 창구라기보다 사이트 소유권을 확인하고 수집·색인 상태를 점검하는 운영 도구에 가깝습니다.
Claude는 Gmail, Google Drive, Slack 같은 커넥터를 기본으로 제공합니다. 하지만 쓰고 싶은 서비스가 목록에 없다면 직접 등록할 수 있습니다. 커스텀 커넥터를 붙이면 대화 도중에 그 서비스의 기능을 바로 호출할 수 있습니다.
디자인 시스템을 운영하다 보면 버튼, 컬러, 레이아웃보다 먼저 부딪히는 문제가 있습니다. 바로 이름입니다. 이름은 문서 구조, 패키지명, 컴포넌트 철학, 팀 내 커뮤니케이션에 계속 영향을 줍니다.
네오브루탈리즘은 최근 웹과 앱 디자인에서 자주 보이는 강한 시각 스타일입니다. 두꺼운 테두리, 원색, 딱딱한 그림자, 과감한 타이포그래피를 사용해 화면을 포스터처럼 보이게 만듭니다.
AI 도구를 프로젝트에 도입하면 생산성이 올라갈 수 있지만, 규칙 없이 쓰면 결과가 흔들립니다. AI 프로젝트 관리는 프롬프트를 잘 쓰는 것을 넘어 컨텍스트, 도구, 검증, 작업 규칙을 함께 설계하는 일입니다.
AI를 잘 쓰는 핵심은 좋은 모델을 고르는 것만이 아닙니다. 모델에게 어떤 정보를 주고, 어떤 도구를 연결하고, 결과를 어떻게 검증할지까지 설계해야 실제 업무에 도움이 됩니다.
AI 개발 도구가 많아지면서 이름은 비슷하지만 역할이 전혀 다른 도구들이 함께 비교됩니다. CodeRabbit, Warp AI, Cursor도 모두 개발자를 돕지만 같은 범주의 제품은 아닙니다.
React Native와 Expo로 여러 고객 앱을 개발·배포한다면 계정, 비용, 서명 키, 스토어 권한을 어떻게 나눌지 초기에 정해야 합니다. 이 구조를 잘못 잡으면 나중에 소유권 이전, 업데이트, 보안 관리가 복잡해집니다.
React Native나 Expo로 개발하다 보면 코드를 고쳤는데 앱에 바로 반영되지 않는 경우가 있습니다. 이때 원인 중 하나가 파일 변경 감시 도구인 Watchman 문제일 수 있습니다.
Google Play Console에는 여러 출시 트랙이 있습니다. 처음 앱을 배포할 때 내부 테스트, 비공개 테스트, 공개 테스트, 프로덕션의 차이를 이해하지 못하면 심사와 배포 흐름이 헷갈릴 수 있습니다.
모바일 앱 배포는 빌드 파일을 만드는 것에서 끝나지 않습니다. 인증서, 서명 키, 스토어 메타데이터, 심사 정보, 버전 관리, 제출 자동화까지 함께 설계해야 반복 가능한 배포가 됩니다.
Expo Application Services(EAS)는 React Native 앱을 빌드, 제출, 업데이트하는 과정을 단순하게 만들어줍니다. 하지만 팀 규모와 빌드 빈도에 따라 비용 구조를 이해하고 써야 합니다.
OTA(Over-The-Air) 업데이트는 앱 스토어 심사를 거치지 않고 설치된 앱의 JavaScript 코드와 에셋을 갱신하는 방식입니다. React Native와 Expo 환경에서는 빠른 버그 수정과 작은 기능 개선에 매우 유용합니다.
사용자가 버튼이나 링크를 눌렀는데 아무 반응이 없는 것처럼 보이면, 실제 로딩 시간이 길지 않아도 서비스가 느리다고 느낍니다. 이 문제는 단순한 성능 문제가 아니라 체감 성능과 피드백의 문제입니다.
웹사이트나 앱을 만들 때 “어떤 느낌으로 디자인할 것인가”는 생각보다 중요한 결정입니다. 같은 기능이라도 시각 언어에 따라 신뢰감, 친근함, 전문성, 실험성이 완전히 달라집니다.
새 서브도메인을 추가한 직후 “Safari에서는 열리는데 Chrome에서는 안 열린다” 같은 일이 생길 수 있습니다. 이럴 때 바로 서버 장애나 DNS 설정 오류라고 판단하기 쉽지만, 실제 원인은 로컬 또는 브라우저 DNS 캐시인 경우가 많습니다.
웹 서비스를 만들 때 기술 스택은 단순한 취향 문제가 아닙니다. 개발 속도, 유지보수, 확장성, 채용 가능성, 운영 비용까지 영향을 줍니다. 작은 팀이나 1인 개발 조직이라면 특히 “적은 인원으로 오래 가져갈 수 있는 조합”이 중요합니다.
웹사이트에 Apple Pay를 붙이면 모바일 Safari 사용자에게 훨씬 빠른 결제 경험을 제공할 수 있습니다. 다만 버튼 하나만 추가한다고 끝나는 기능은 아닙니다. 도메인 검증, 결제 세션 생성, 결제 토큰 승인, PG 연동까지 함께 설계해야 합니다.
개발 중에는 현재 작업을 유지한 채 다른 브랜치에서 긴급 수정이나 리뷰를 해야 할 때가 있습니다. 이때 매번 stash를 하거나 브랜치를 바꾸면 작업 흐름이 끊깁니다. git worktree는 이런 상황에서 매우 유용한 도구입니다.
Cloudflare Tunnel로 서비스를 노출하면 origin 서버가 보는 접속 IP가 실제 방문자 IP가 아닐 수 있습니다. 모든 요청이 터널 또는 프록시에서 온 것처럼 보이면 rate limit, 방문 통계, IP 차단 같은 기능이 부정확해집니다.
HSTS(HTTP Strict Transport Security)는 브라우저에 “이 도메인은 항상 HTTPS로만 접속해야 한다”고 알려주는 보안 정책입니다. 잘 설정하면 중간자 공격과 SSL stripping을 줄일 수 있지만, 성급하게 적용하면 장애 복구가 어려워질 수 있습니다.
웹사이트 주소 앞에 자물쇠 표시가 붙고 https://로 시작한다면 SSL/TLS 인증서가 사용되고 있다는 뜻입니다. 인증서는 방문자가 접속한 사이트가 진짜인지 확인하고, 주고받는 데이터를 암호화하는 역할을 합니다.