노바랩｜AI 시대의 웹개발 가이드

MVP 기능 우선순위, 남길 것과 버릴 것 가르기

novalab-official — Thu, 16 Jul 2026 03:51:05 +0900

첫 버전을 만들 때 가장 어려운 건 기능을 고르는 일이 아니라 버리는 일이다. 아이디어는 늘 기능 목록을 부풀리고 그 목록을 그대로 개발하면 출시가 한없이 밀린다. 그래서 필요한 건 우선순위를 매기는 기준이다. 몇 가지 도구를 쓰면 감정이 아니라 규칙으로 자를 수 있다.

단일 판단 기준: 검증을 막는가

가장 단순한 기준부터 보자. "이 기능을 빼면 이번에 확인하려는 핵심 가치가 성립하지 않는가." 성립이 막히면 남기고 없어도 검증은 되는데 불편할 뿐이면 미룬다. 예를 들어 예약 서비스라면 예약 확정과 중복 방지는 빠지면 서비스가 아니지만 적립 포인트는 없어도 "이 가격에 예약하는가"를 확인하는 데 지장이 없다. 전자는 남고 후자는 다음 버전이다.

남기는 신호와 미루는 신호

기준을 표로 정리하면 판단이 빨라진다. 기능을 하나씩 대보고 왼쪽에 걸리면 남기고 오른쪽이면 다음 버전으로 내린다.

| 남긴다 | 미룬다 |
|---|---|
| 없으면 핵심 검증이 막힌다 | 없어도 검증은 된다 |
| 돈·예약이 실제로 오간다 | 편의·완성도를 높인다 |
| 그 유형의 필수 축이다 | 곁가지·선택 기능이다 |

MoSCoW로 한 번 더 거른다

기능이 많을 땐 네 칸으로 나누는 방법이 쓸 만하다. 반드시 있어야 하는 것(Must), 있으면 좋은 것(Should), 없어도 되는 것(Could), 이번엔 안 하는 것(Won't). 첫 버전에는 Must만 넣는다. Should와 Could는 다음 버전 목록으로 내리고 Won't는 아예 접어둔다. 앞의 단일 기준으로 남긴 기능을 다시 이 표에 넣어보면, Must가 생각보다 적다는 걸 알게 된다.

유형별로 빠지면 안 되는 최소 기능

핵심만 남기라는 말은 유형을 만나야 구체적이 된다. 아래는 유형별로 첫 버전에서 빠지면 안 되는 축이다.

예약형: 시간대 선택, 예약 확정 안내, 같은 시간 중복 예약 막기.
커머스형: 상품 보기, 결제, 주문 내역 확인.
콘텐츠형: 글 발행, 목록·상세 보기, 검색이나 분류 하나.
커뮤니티형: 글쓰기, 남의 글 읽기, 최소한의 신고·삭제.
도구형: 입력, 처리, 결과.

주의할 점이 있다. 개수는 줄이되 남긴 기능은 끝까지 제대로 돌아가야 한다. 범위를 좁히는 것과 핵심을 부실하게 만드는 것은 다른 이야기다. 예약 확정을 넣기로 했다면 화면 수는 줄여도 확정과 중복 방지만큼은 실제로 작동해야, 사용자가 써보고 답을 준다.

현실에서는 Must끼리도 경쟁한다. 개발 시간이 한정되면 Must 안에서도 가장 위험한 가정을 검증하는 것부터 만든다. 예약 서비스라면 "사람들이 이 가격에 예약을 하는가"가 "결제가 매끄러운가"보다 먼저다. 어느 가정이 틀렸을 때 서비스 자체가 흔들리는지를 기준으로 순서를 잡으면, 같은 Must 안에서도 무엇을 먼저 만들지가 정해진다.

자르는 순서 한 가지

실무에서는 순서를 정해두면 손이 나간다. 먼저 이번에 확인할 가설 한 문장을 적고 기획서 기능을 종이에 모두 펼친 뒤, 기능마다 "빼면 이 가설 검증이 막히나"를 표시한다. 막히는 것만 남기고 나머지는 다음 버전 목록으로 옮긴다. 아깝다는 이유로 남발하면 목록이 다시 부푸니, 판단이 흐려질 때는 "이번 검증"이라는 말만 되뇌면 된다.

Q. MVP는 최대한 적은 기능만 넣으면 되나요?
개수가 목표가 아닙니다. 이번 검증에 필요한 기능이면 남기고 아니면 빼는 것이라, 유형에 따라 서너 개일 수도 예닐곱 개일 수도 있습니다. 숫자보다 남은 기능이 하나의 검증 목표로 묶이는지가 중요합니다.

Q. 뺀 기능은 나중에 넣기 어렵지 않나요?
처음부터 다음 버전을 염두에 두고 만들면 대개 무리 없이 붙습니다. 미룬 기능은 버린 게 아니라 목록에 적어둔 것이라, 첫 버전 반응을 보고 우선순위대로 더하면 됩니다.

원문: https://nova-lab.dev/r/t/mvp-scope-first-version

자주 묻는 질문

Q. MVP 범위는 기능을 몇 개까지 넣어야 적당한가요?

개수로 정하는 게 아니라 기준으로 정합니다.

이 기능이 없으면 이번에 확인하려는 핵심 가치가 성립하지 않는가를 물어, 그렇다는 것만 남기면 됩니다.

그러면 유형에 따라 서너 개가 될 수도, 예닐곱 개가 될 수도 있습니다.

중요한 건 숫자가 아니라 남은 기능이 하나의 검증 목표로 묶이는지입니다.

Q. MVP는 대충 만들어도 되나요?

범위는 좁히되 완성도는 낮추지 않는 게 맞습니다.

핵심 흐름은 사용자가 실제로 끝까지 써 봐야 배움이 나오기 때문입니다.

예를 들어 예약을 검증한다면 예약 화면 수는 줄이더라도 예약이 실제로 확정되고 중복이 막히는 것까지는 제대로 돌아가야 합니다.

곁가지 기능을 빼는 것과 핵심을 부실하게 만드는 것은 다릅니다.

Q. 지금 뺀 기능은 나중에 넣기 어렵지 않나요?

처음부터 다음 버전을 염두에 두고 만들면 대부분 무리 없이 붙일 수 있습니다.

미룬 기능은 버리는 게 아니라 목록에 적어 두는 것이라, 첫 버전에서 얻은 반응을 보고 우선순위대로 더하면 됩니다.

오히려 반응을 보고 넣으면 안 쓸 기능에 미리 돈을 묶지 않아도 됩니다.

글 · 노바랩 NovaLab · https://nova-lab.dev

홈페이지 외주 견적서, 네 가지 축으로 해부하기

novalab-official — Thu, 16 Jul 2026 03:44:00 +0900

홈페이지 외주 견적을 여러 곳에서 받으면, 총액만 다른 게 아니라 견적서 서식 자체가 다르다. 어떤 곳은 반응형을 기본에 넣고 어떤 곳은 옵션으로 뺀다. 그래서 총액을 그대로 비교하면 사과와 배를 견주는 꼴이 된다. 견적을 해부하는 기준을 잡으면 이 혼란이 정리된다. 축은 네 가지다.

견적을 가르는 네 축

첫째는 화면 수다. 회사 소개와 문의 정도의 5화면과, 게시판·검색·채용까지 붙은 20화면은 기획·디자인·개발 공수가 몇 배 차이 난다. 둘째는 관리자 기능이다. 운영자가 직접 글이나 상품을 고치는 화면은 방문자 화면과 별개로 하나 더 만드는 작업이라, 견적에서 가장 크게 움직인다. 셋째는 반응형 범위, 넷째는 유지보수 범위다. 반응형은 PC를 줄이기만 하느냐, 기기별로 배치를 다시 짜느냐에 따라 손이 갈린다. 유지보수는 납품으로 끝이냐, 월 단위로 수정·보안·백업을 맡느냐로 나뉜다.

제작 방식도 봐야 한다

같은 홈페이지라도 코딩으로 처음부터 개발하느냐, 노코드 플랫폼 위에 올리느냐로 비용이 갈린다. 노코드는 개발 시간이 짧아 견적이 낮지만 커스터마이징에 한계가 있고 코딩은 자유도가 높은 대신 시간이 든다. 견적서에 제작 방식이 안 적혀 있다면 물어봐야 한다. 방식이 다르면 애초에 비교 자체가 성립하지 않기 때문이다.

저가형과 표준형, 무엇을 빼서 싼가

낮은 견적이 나쁜 건 아니다. 다만 무엇을 덜어내 값을 낮췄는지 알아야 한다. 아래는 같은 소개형 홈페이지를 저가형과 표준형으로 잡았을 때 흔히 갈리는 구성이다.

| 항목 | 저가형 견적 | 표준형 견적 |
|---|---|---|
| 관리자 화면 | 없음(수정은 요청) | 포함(직접 수정) |
| 반응형 | PC 축소 | 기기별 최적화 |
| 유지보수 | 납품 후 종료 | 월 단위 계약 |
| 제작 방식 | 노코드 템플릿 | 코딩 또는 혼합 |

표에서 보이듯 저가형은 대개 뒤쪽 항목을 덜어내 값을 낮춘다. 그 항목이 지금 필요 없다면 저가형이 맞고 곧 필요하다면 처음부터 넣는 편이 낫다.

견적서에 던질 질문 다섯 개

견적을 같은 선에 세우려면, 문서에 안 적힌 부분을 질문으로 메워야 한다. 아래 다섯 개면 대부분의 빈칸이 드러난다.

1. 화면은 몇 개이고 게시판·검색 같은 기능은 포함인가.
2. 관리자 화면이 포함인가, 아니면 수정은 매번 요청해야 하는가.
3. 반응형은 기기별 최적화인가, PC 축소인가.
4. 유지보수는 어디까지이고 월 비용은 얼마인가.
5. 제작 방식은 코딩인가 노코드인가.

이 답을 표로 채운 뒤 총액을 다시 보면, "A가 제일 싸다"가 "A는 관리자와 유지보수가 빠져서 싸다"로 바뀐다. 그때 비로소 값을 제대로 비교할 수 있다.

판단 기준

사이트를 오래 직접 운영할 거라면 관리자와 유지보수가 포함된 견적이 결국 이득이다. 단순 소개용이고 내용이 거의 안 바뀐다면 그 항목을 빼도 된다. 예산이 빠듯하면 화면 수부터 줄이는 편이 낫다. 화면은 나중에 더하기 쉽지만 관리자나 반응형은 뒤에 끼우려면 구조를 다시 손대야 하는 경우가 많다.

한 가지 더. 견적서에 유지보수가 '월 얼마'로 명시됐는지 봐야 한다. 유지보수는 오픈 시점의 일회성 비용이 아니라 매달이나 매년 붙는 항목이라, 개발비만 낮게 잡고 이걸 빼두면 1년 뒤 총지출이 뒤집히기도 한다. 그래서 견적 비교는 '첫 금액'이 아니라 '1년 굴린 뒤의 총액'으로 잡아야 정확하다. 표에 유지보수 월 비용까지 적어 12개월을 곱해보면, 처음에 싸 보이던 견적의 순위가 바뀌는 일이 흔하다.

Q. 가장 싼 견적을 고르면 손해인가요?
꼭 그렇진 않습니다. 다만 왜 싼지부터 확인하세요. 대개 관리자·반응형·유지보수가 빠져서 싼 경우가 많고 나중에 그걸 더하면 총액이 역전되기도 합니다.

Q. 유지보수는 견적에서 빼도 되나요?
오래 운영할 사이트면 넣는 편이 낫습니다. 오픈 뒤에도 수정과 보안 점검이 계속 생기고 빼두면 건마다 비용을 따로 내야 할 수 있습니다.

원문: https://nova-lab.dev/r/t/homepage-dev-cost-factors

자주 묻는 질문

Q. 홈페이지 개발 외주 견적, 가장 싼 곳을 고르면 손해인가요?

무조건 손해는 아니지만 왜 싼지부터 확인해야 합니다.

대개 가장 싼 견적은 관리자 기능·반응형·유지보수 같은 항목이 빠져 있어서 싼 경우가 많습니다.

그 항목을 나중에 추가하면 총액이 다른 견적과 비슷해지거나 오히려 넘어서기도 합니다.

지금 필요 없는 기능이라면 싼 견적이 맞고 곧 필요할 기능이라면 처음부터 포함된 견적이 낫습니다.

Q. 관리자 페이지가 있으면 견적이 얼마나 오르나요?

금액은 업체와 기능 범위에 따라 다르지만 관리자 기능은 견적을 크게 움직이는 항목입니다.

방문자가 보는 화면과 별도로 직접 내용을 고치는 화면을 또 만들어야 해서 작업량이 늘기 때문입니다.

대신 오픈 뒤 문구·이미지·공지를 스스로 바꿀 수 있어 자주 고칠 사이트라면 그만한 값을 합니다.

Q. 유지보수는 견적에 꼭 넣어야 하나요?

사이트를 오래 직접 운영할 계획이면 넣는 편이 낫습니다.

오픈이 끝이 아니라 보안 점검, 내용 수정, 오류 대응 같은 일이 계속 생기기 때문입니다.

유지보수를 빼면 당장 견적은 낮아지지만 나중에 건마다 비용을 따로 내야 할 수 있습니다.

내용이 거의 안 바뀌는 소개형 사이트라면 최소한으로 잡아도 됩니다.

글 · 노바랩 NovaLab · https://nova-lab.dev

외부 API 연동 실무 체크리스트: 준비물·심사·호출 상한

novalab-official — Wed, 15 Jul 2026 06:37:12 +0900

외부 서비스를 붙이는 작업은 코드보다 행정에 시간이 더 든다. 견적서에 한 줄로 적히는 "API 연동"이 실제로는 키 발급, 도메인 등록, 심사, 예외 처리, 운영 점검까지 다섯 덩어리로 나뉘기 때문이다. 이 글은 연동 유형별로 무엇을 준비해야 하고 어디서 일정이 새는지 정리한다.

연동 유형별 준비물 대조표

| 유형 | 준비물 | 심사 여부 | 일정을 늦추는 지점 |
|---|---|---|---|
| 소셜 로그인 | 개발자 계정, 실서비스 도메인, 동의항목 정의 | 민감 항목은 별도 검수 | 받을 정보를 과하게 요구해 검수가 길어짐 |
| 결제 | 사업자등록증, 통신판매업 신고증, 정산 계좌 | 사업자 심사 필수 | 심사 완료 전 실거래 키가 안 나옴 |
| 지도·주소 | 개발자 키, 도메인 등록 | 대체로 자동승인 | 호출량 초과 시 과금 또는 차단 |
| 공공데이터 | 활용신청, 인증키 | 자동승인/심의승인으로 갈림 | 심의는 승인까지 며칠 대기 |
| 알림톡·문자 | 발신번호 등록, 템플릿 승인 | 템플릿 검수 | 문구를 바꾸면 다시 검수 |

표의 오른쪽 열이 핵심이다. 개발이 아니라 승인·검수가 오픈일을 정한다.

키 관리 원칙

연동에서 사고가 나는 자리는 대부분 키다.

시크릿 키는 코드에 넣지 않는다. 서버 환경변수로 분리하고 저장소에 커밋하지 않는다.
개발용 키와 실서비스용 키를 분리한다. 테스트 결제가 실거래로 나가는 사고를 막는다.
앱은 반드시 발주자(대표자·법인) 명의 계정으로 등록한다. 개발사 개인 계정으로 등록하면 업체 교체 시 서비스가 통째로 멈춘다.
유출 시 재발급 절차를 미리 확인해 둔다. 키를 갈아 끼우면 배포가 한 번 더 필요하다.

호출 상한을 계산하는 습관

외부 API는 무제한이 아니다. 예를 들어 공공데이터포털은 개발계정에 하루 평균 1,000건, 운영계정에 하루 최대 10만 건의 트래픽을 준다. 활용신청도 자동승인과 심의승인으로 나뉘고 심의승인은 신청 후 2~3일이 걸린다.

그래서 기획 단계에서 이 계산을 한 번 해 두는 게 좋다. 하루 방문자 수 × 한 사람이 그 기능을 쓰는 횟수 = 하루 호출량. 여기에 여유를 두 배쯤 얹어 상한과 비교한다. 상한에 걸리는 순간 그날의 그 기능은 죽는다. 이벤트나 광고 집행처럼 트래픽이 튀는 날을 기준으로 잡아야 한다.

계약서에 넣을 한 줄

외부 API는 우리가 통제하지 못하는 구간이 있다. 상대 서버 장애, 사업자 심사 반려, 규격 변경은 개발사가 손쓸 수 없다. 그래서 계약서에 다음 취지의 문장을 한 줄 넣어 두면 분쟁이 줄어든다. 외부 서비스의 장애·심사 지연으로 발생한 일정 지연은 개발사 귀책이 아니며, 규격 변경에 따른 수정은 유지보수 범위로 처리한다.

---

Q. 직접 개발과 API 연동, 어느 쪽이 싼가요?
A. 초기 비용은 연동이 압도적으로 싸다. 대신 호출량이나 건당 수수료가 계속 나가고 일정 통제권을 상대에게 넘긴다. 우리 사업의 차별점이 아닌 기능(로그인·지도·결제)은 연동이 맞고, 손님이 우리를 고르는 이유가 되는 기능은 직접 만드는 게 맞다.

Q. 연동한 기능이 어느 날 갑자기 멈추면 누구 책임인가요?
A. 원인부터 갈라야 한다. 상대 서버 장애나 규격 변경이면 개발사가 예방할 수 없고, 대응 속도만 문제가 된다. 유지보수 계약이 없으면 그 대응조차 별도 비용이 붙으니 계약 시점에 범위를 정해 두는 편이 낫다.

원문: https://nova-lab.dev/r/t/what-is-an-api

자주 묻는 질문

Q. API 연동은 이미 만들어진 기능을 쓰는 건데 왜 비용이 드나요?

붙이는 코드 자체는 짧습니다.

시간을 잡아먹는 건 앱 등록과 키 발급, 동의항목 검수, 그리고 토큰 만료나 동의 거절 같은 예외 처리입니다.

결제처럼 사업자 심사가 필요한 연동은 개발이 끝나도 심사가 끝나야 실거래를 열 수 있습니다.

Q. 외부 API를 쓰면 우리 마음대로 기능을 바꿀 수 있나요?

없습니다.

무엇을 요청할 수 있고 무엇이 돌아오는지는 상대가 정합니다.

상대가 열어 주지 않은 정보는 가져올 방법이 없고, 상대가 규격을 바꾸면 우리 쪽 코드도 따라 고쳐야 합니다.

Q. 발주자가 미리 준비하면 좋은 것은 무엇인가요?

사업자등록증과 통신판매업 신고증, 대표자나 회사 명의 계정, 실제로 쓸 도메인을 먼저 준비해 두면 연동 일정이 며칠씩 당겨집니다.

특히 앱은 개발사 개인 계정이 아니라 발주자 명의 계정으로 등록해야 나중에 업체를 바꿔도 로그인이 살아 있습니다.

글 · 노바랩 NovaLab · https://nova-lab.dev

홈페이지 제작 견적서 읽는 법과 계약 전 점검 루틴

novalab-official — Wed, 15 Jul 2026 06:27:35 +0900

홈페이지 제작 견적서를 받아 든 발주자가 가장 먼저 하는 실수는 총액부터 보는 것이다. 총액은 결과값일 뿐이고, 실제로 봐야 할 자리는 그 총액을 만들어 낸 항목의 구성이다. 이 글은 견적서를 읽는 순서와 계약 전 점검 루틴을 정리한다. 지역은 대구를 기준으로 하지만 판단 기준 자체는 어디서나 같다.

견적서를 읽는 순서

견적서는 위에서 아래로 읽지 말고 다음 네 덩어리로 갈라서 봐야 한다.

1. 기획·설계 — 화면 목록과 기능 정의가 문서로 나오는가. 이게 빠진 견적은 나중에 "그건 범위 밖입니다"로 돌아온다.
2. 디자인 — 템플릿 커스터마이징인지 화면별 신규 디자인인지. 시안 수정 횟수가 몇 회까지 포함인지.
3. 퍼블리싱·개발 — 반응형 대응 범위(모바일 별도 견적인지), 관리자 화면 포함 여부.
4. 운영·유지보수 — 월 비용에 무엇이 들어가는지. 단순 장애 대응인지, 콘텐츠 수정까지인지.

같은 총액이라도 1번이 두툼한 견적과 2번만 두툼한 견적은 완성물이 완전히 다르다. 전자는 오픈 후 손볼 게 적고, 후자는 예쁘지만 손님 행동을 설계하지 않은 사이트가 나온다.

소유권 점검표

제작비를 완납해도 소유가 넘어오지 않는 항목이 있다. 계약서 서명 전에 네 줄을 확인한다.

| 항목 | 확인할 것 | 넘어오지 않으면 |
|---|---|---|
| 도메인 | 등록 명의가 발주자인가 | 업체 교체 시 주소를 잃는다 |
| 호스팅 | 계정 소유자가 누구인가 | 서버 이전이 막힌다 |
| 소스코드 | 오픈 시점에 인계하는가 | 다음 업체가 처음부터 다시 만든다 |
| 관리자·검색 계정 | 발주자 계정으로 개설하는가 | 콘텐츠 수정과 색인 요청을 못 한다 |

일정 관리 루틴

제작 일정이 밀리는 원인은 개발 속도가 아니라 콘텐츠 공급이다. 발주자가 다음 루틴을 돌리면 지연 대부분이 사라진다.

착수 시점: 필요한 사진·원고 목록을 업체에서 받아 마감일을 역산해 달력에 박는다.
주 1회: 진행 중인 화면 하나를 실제 휴대폰으로 열어 본다. 시안 이미지가 아니라 동작하는 화면으로.
오픈 2주 전: 콘텐츠를 100% 채운다. 빈 자리를 두고 검수에 들어가면 검수가 두 번 된다.
오픈 직후: 네이버 서치어드바이저·구글 서치콘솔에 사이트를 등록하고 색인 요청을 넣는다.

지역 업체를 선택할 실익

대구 업체를 고를 근거는 가격이 아니라 물리적 거리에서 나오는 것들이다. 매장 촬영이 필요한 업종, 대표가 화면을 옆에서 보며 결정하려는 조직, 오픈 후 대면 교육이 필요한 팀이라면 이동 한 시간이 사흘의 원격 소통을 대신한다. 반대로 원고와 사진이 이미 준비돼 있고 기능 요구가 문서로 확정된 프로젝트라면 지역은 판단 기준에서 빠진다. 이때는 유사 업종 경험과 오픈 후 응답 속도만 본다.

비용을 낮추려면 기업마당(bizinfo.go.kr)의 지자체별 공고를 확인해 지원사업 시기에 제작 일정을 맞추는 방법이 있다.

---

Q. 견적서에 유지보수가 아예 없으면 어떻게 하나요?
A. 유지보수 없는 견적은 총액이 싸 보이는 착시를 만든다. 오픈 6개월 뒤 브라우저 업데이트나 인증서 만료로 문제가 생겼을 때 건당 요금이 붙는지, 월 계약이 필요한지 계약 전에 확인해야 한다.

Q. 템플릿 제작은 무조건 손해인가요?
A. 아니다. 손님이 정보를 확인하고 전화만 걸면 되는 소개형 사이트라면 템플릿이 합리적이다. 예약·결제처럼 데이터를 다루는 기능이 붙거나 브랜드 인상이 매출을 좌우하는 업종이라면 그때부터 신규 디자인의 값어치가 생긴다.

원문: https://nova-lab.dev/r/t/daegu-homepage-production-guide

자주 묻는 질문

Q. 대구에서 홈페이지 제작을 맡기면 기간이 얼마나 걸리나요?

소개 화면 중심의 작은 사이트는 문의에서 오픈까지 몇 주 안에 끝나는 경우가 많습니다.

예약이나 결제처럼 데이터를 다루는 기능이 붙으면 개발과 테스트에 드는 시간이 그만큼 늘어납니다.

일정을 좌우하는 건 개발 속도보다 사진과 원고가 언제 준비되느냐입니다.

Q. 견적서에서 가장 먼저 확인할 항목은 무엇인가요?

기획·디자인·개발·유지보수가 항목별로 나뉘어 있는지부터 봅니다.

총액만 적힌 견적서는 나중에 범위 다툼이 생깁니다.

시안 수정 횟수와 유지보수에 무엇이 포함되는지도 계약 전에 문장으로 확인해야 합니다.

Q. 꼭 대구에 있는 업체를 골라야 하나요?

매장 촬영이 필요하거나 대면 회의가 자주 필요한 상황이면 대구 업체가 유리합니다.

원고와 사진이 이미 있고 기능 요구가 문서로 정리돼 있다면 지역은 선택 기준에서 빠집니다.

이때는 유사 업종 경험과 오픈 뒤 응답 속도를 보고 고르는 편이 낫습니다.

글 · 노바랩 NovaLab · https://nova-lab.dev

배포 전 점검 12항목 — 서버·도메인·백업·알림 체크리스트

novalab-official — Tue, 14 Jul 2026 20:43:37 +0900

"서버가 뭔가요"라는 질문에 대한 답은 대부분 비슷하다. 요청을 받아 응답하는 컴퓨터라는 정의다. 정의는 맞지만 발주자에게는 쓸모가 적다. 실제로 필요한 지식은 따로 있다. 내 사이트가 어떤 서버를 요구하는지, 배포할 때 무엇이 걸려 있는지, 계약에서 무엇을 지켜야 하는지다.

정의보다 조건이 중요하다

MDN 문서에서 웹 서버는 두 얼굴을 가진 말로 정의된다. 기계 쪽으로는 파일을 담아 인터넷에 물려 둔 컴퓨터, 프로그램 쪽으로는 방문자가 그 파일에 닿는 경로를 관리하는 소프트웨어다.

발주자에게 쓸모 있는 대목은 그다음에 나온다. 같은 문서가 웹사이트 전용 서버의 요건을 네 줄로 못 박는다. 항상 실행 중일 것, 항상 인터넷에 연결돼 있을 것, 고정된 주소를 가질 것, 제3자가 유지보수할 것. 개인 노트북이 서버 자리를 못 지키는 이유가 여기 다 나와 있다. 가정용 회선은 고정 IP를 주지 않는 경우가 많고, 노트북은 덮으면 멈춘다.

배포 전 점검 12항목

"코드를 서버에 올린다"는 한 문장에는 최소 열두 가지 확인이 들어 있다. 오픈 직전 체크리스트로 쓰면 된다.

1. 서버 요금제와 결제 수단이 발주자 명의인가
2. 도메인 소유자가 발주자 명의인가
3. 도메인이 서버 주소를 정확히 가리키는가
4. www 주소와 기본 주소 중 하나로 통일했는가
5. HTTPS 인증서가 설치돼 있고 자동 갱신이 걸려 있는가
6. 프로그램이 죽으면 자동으로 다시 켜지는가
7. 데이터베이스 접속 정보가 코드가 아니라 서버 설정에 있는가
8. 데이터베이스 백업 주기가 정해져 있는가
9. 서버가 멈췄을 때 알림이 담당자에게 가는가
10. 관리자 계정 비밀번호를 발주자가 바꿀 수 있는가
11. 서버 접속 열쇠를 인수인계 문서에 적어 두었는가
12. 월 고정비가 얼마인지 문서로 확인했는가

이 중 7번과 9번이 사고를 가르는 항목이다. 접속 정보가 코드에 박혀 있으면 유출 사고로 이어지고, 알림이 없으면 손님이 먼저 장애를 발견한다.

세 가지 선택지 비교

| 방식 | 맞는 경우 | 운영 부담 | 월 비용 감각 |
|---|---|---|---|
| 정적 호스팅 | 소개·랜딩·블로그 | 거의 없음 | 가장 가볍다 |
| 관리형 호스팅 | 문의 폼·간단한 회원 기능 | 업체가 대신 관리 | 중간 |
| 클라우드·서버 임대 | 결제·정산·대량 데이터 | 보안 업데이트·감시 필요 | 트래픽에 따라 증가 |

기준은 방문자 수가 아니라 기능이다. 로그인·결제·개인정보가 없으면 정적 호스팅에서 시작하고, 셋 중 하나라도 들어오는 순간 관리형 이상으로 올린다. 정산이 걸린 서비스나 직원이 매일 쓰는 업무 시스템이라면 처음부터 클라우드로 잡고 유지보수 계약을 함께 맺는 편이 낫다.

Q&A

서버는 한 번 사면 끝인가요?
아니다. 서버는 자리값이라 쓰는 동안 매달 나간다. 제작비와 별개 항목으로 잡히므로 견적서에서 인프라 비용을 따로 확인해야 한다.

도메인만 사면 사이트가 뜨나요?
뜨지 않는다. 도메인은 이름표이고 서버는 건물이다. 이름표를 사도 가리킬 건물이 없으면 방문자는 아무것도 보지 못한다.

원문: https://nova-lab.dev/r/t/what-is-a-server

자주 묻는 질문

Q. 내 노트북을 서버로 쓰면 안 되나요?

가능은 하지만 오래 버티지 못합니다.

MDN은 웹사이트 파일을 담는 서버의 조건으로 항상 실행 중일 것, 항상 인터넷에 연결돼 있을 것, 고정된 주소를 가질 것, 제3자가 유지보수할 것을 듭니다.

노트북은 덮으면 멈추고 가정용 회선은 주소가 수시로 바뀝니다.

Q. 서버 비용은 매달 나가나요?

네, 서버는 자리값이라 쓰는 동안 매달 나갑니다.

사이트 제작비와는 별개 항목이라 견적서에서 인프라 비용을 따로 확인해야 합니다.

소개 사이트라면 정적 호스팅으로 가볍게 시작할 수 있습니다.

Q. 서버와 도메인은 누구 명의로 계약해야 하나요?

발주자 명의로 계약하고 업체에는 관리 권한만 주는 순서가 안전합니다.

명의가 업체로 되어 있으면 업체를 바꿀 때 사이트와 도메인을 그대로 두고 나와야 하는 상황이 생깁니다.

글 · 노바랩 NovaLab · https://nova-lab.dev

견적서의 'SEO 최적화 포함'을 검수 가능한 항목으로 쪼개기

novalab-official — Tue, 14 Jul 2026 20:40:54 +0900

웹 제작 견적서를 열어 보면 "SEO 최적화 포함"이라는 한 줄이 거의 빠지지 않는다. 그런데 이 한 줄이 실제로 무엇을 약속하는지는 아무도 설명하지 않는다. 발주자가 이 문장을 계약 가능한 항목으로 쪼개는 법을 정리한다.

검수 가능한 항목으로 쪼개기

SEO를 "잘해 주세요"로 남겨 두면 검수할 방법이 없다. 아래 다섯 항목은 완성 뒤 고치기 어려운 구조에 해당하므로, 계약서 범위에 문장으로 적어 두는 편이 낫다.

| 항목 | 계약서에 적을 문장 | 검수 방법 |
|---|---|---|
| 렌더링 | 공개 페이지는 서버에서 HTML을 완성해 응답한다 | 브라우저 자바스크립트를 끄고 본문이 보이는지 확인 |
| 주소 구조 | 상세 콘텐츠는 항목마다 고유 URL을 갖는다 | 사례·상품 두 건의 주소가 다른지 확인 |
| 메타 편집 | 페이지별 제목·설명을 관리자 화면에서 수정한다 | 발주자 계정으로 직접 수정 시연 |
| 사이트맵 | 새 콘텐츠 발행 시 sitemap.xml에 자동 반영된다 | 글 발행 후 sitemap 재확인 |
| 속도 | LCP 2.5초, INP 200밀리초, CLS 0.1 이하 | 지정 도구·지정 페이지로 측정 |

속도 수치는 임의로 정한 값이 아니다. 구글이 코어 웹 바이탈 권장선으로 제시하는 기준이며, 판정은 모바일과 데스크톱을 나눠 방문의 75번째 백분위수로 한다.

발주 전 30분 점검 루틴

업체 후보가 만든 기존 사이트를 대상으로 30분이면 돌려 볼 수 있는 점검 순서다. 개발 지식이 없어도 가능하다.

1. 후보 업체가 만든 사이트를 하나 연다. 브라우저 설정에서 자바스크립트를 끄고 새로고침한다. 본문 텍스트가 그대로 보이면 서버 렌더링, 빈 화면이면 브라우저 렌더링이다.
2. 상세 페이지 두 개를 열어 주소창을 비교한다. 주소가 같으면 검색엔진에게는 한 페이지다.
3. 주소 뒤에 `/sitemap.xml`을 붙여 본다. 파일이 없거나 페이지 목록이 비어 있으면 검색 준비가 안 된 사이트다.
4. 페이지 원본 보기에서 `<title>`과 `description`이 페이지마다 다른지 확인한다. 전 페이지가 같은 문구면 자동 생성만 걸어 둔 것이다.
5. 휴대폰 데이터로 첫 화면을 열어 체감 속도를 본다.

다섯 항목 중 세 개 이상 걸리면, 그 업체가 만드는 사이트도 같은 상태로 나온다고 보는 편이 안전하다.

견적에서 빼도 되는 항목

구글은 SEO 기본 가이드에서 키워드 메타 태그를 쓰지 않는다고 명시한다. 견적서에 "메타 키워드 등록"이 항목으로 잡혀 있다면 근거가 없다. 콘텐츠 길이 자체가 순위 요소라는 설명도 같은 문서가 부정한다. 분량 채우기에 붙는 비용은 검색보다 읽는 사람을 잃는 쪽에 가깝다.

반대로 구조 작업은 시점에 따라 비용이 크게 달라진다. 렌더링 방식과 주소 구조는 제작 초기에 결정하면 설계의 일부지만, 완성 후에 바꾸면 화면을 다시 짜는 일이 된다.

판단 기준

소개·소식 위주의 사이트라면 페이지를 미리 만들어 두는 정적 생성으로 충분하다. 로그인 뒤 개인 데이터를 다루는 서비스라면 공개 페이지만 서버에서 완성해 내리고 로그인 이후 화면은 브라우저에서 그리도록 나눈다. 검색으로 사람을 데려오는 페이지와 로그인한 사람만 보는 화면은 요구 자체가 다르다.

Q&A

오픈했는데 검색에 안 뜹니다. 업체 잘못인가요?
구글은 변경 반영에 몇 시간에서 몇 달까지 걸릴 수 있다고 안내한다. 다만 위 점검 루틴에서 색인 구조 자체가 빠져 있다면 시간 문제가 아니라 구조 문제다.

이미 완성된 사이트인데 지금이라도 고칠 수 있나요?
메타·사이트맵·속도는 사후에도 고칠 수 있다. 렌더링 방식과 주소 구조는 화면을 다시 짜야 하는 경우가 많아 비용이 크게 뛴다. 리뉴얼 시점에 함께 잡는 편이 현실적이다.

원문: https://nova-lab.dev/r/t/homepage-seo-ranking-guide

자주 묻는 질문

Q. SEO는 사이트를 다 만든 뒤에 시작해도 되나요?

구조에 해당하는 항목은 제작 단계에서 정해집니다.

렌더링 방식과 주소 구조는 완성 후에 바꾸려면 화면을 다시 짜야 하는 경우가 많습니다.

콘텐츠와 메타 문구는 나중에도 고칠 수 있지만, 색인 구조는 처음에 잡는 편이 비용이 훨씬 적게 듭니다.

Q. 견적서의 'SEO 최적화 포함'은 무엇을 확인해야 하나요?

항목을 쪼개서 물어야 내용이 드러납니다.

페이지별 제목·설명을 누가 고치는지, 새 글이 사이트맵에 자동으로 붙는지, 속도 목표 수치와 측정 도구가 문서에 적혀 있는지, 검색 도구 계정 명의가 누구인지를 확인하세요.

Q. 메타 키워드는 넣어야 하나요?

구글은 SEO 기본 가이드에서 키워드 메타 태그를 사용하지 않는다고 밝혔습니다.

견적에 이 항목이 잡혀 있다면 무엇을 하는 작업인지 되묻고, 근거가 없으면 빼는 편이 낫습니다.

글 · 노바랩 NovaLab · https://nova-lab.dev

엑셀에서 데이터베이스로 — 전환 시점 점수표와 이관 전 정제 루틴

novalab-official — Sun, 12 Jul 2026 20:06:04 +0900

스프레드시트를 언제 버려야 하는가. 이 질문에 "데이터가 많아지면"이라고 답하면 대개 시점을 놓친다. 공식 상한부터 확인하면 이유가 분명해진다.

마이크로소프트 공식 문서 기준으로 엑셀 워크시트 한 장은 1,048,576행 × 16,384열, 셀 하나에 32,767자까지 담는다. 구글 고객센터는 스프레드시트 한 파일의 상한을 1,000만 셀로 안내한다. 소규모 사업장이 이 벽에 부딪히는 일은 드물다. 그런데도 시트는 무너진다. 한계가 용량이 아닌 다른 축에 있기 때문이다.

실제 한계는 세 축이다

첫째는 동시성이다. 구글 고객센터에 따르면 문서 하나는 동시에 100개 탭 또는 기기에서 편집되고, 그 수를 넘으면 소유자와 일부 편집자만 값을 고칠 수 있다. 다만 이 숫자를 안전선으로 읽으면 안 된다. 셋이 같은 칸을 고치는 순간 마지막 저장이 앞선 작업을 덮는다. 경고도 로그도 없다.

둘째는 무결성이다. 시트는 형식을 강제하지 않는다. 전화번호 칸이 문자열이든 숫자든 받아들이고, 중복 회원이 두 줄로 들어가도 막지 않는다. 셋째는 권한이다. 시트의 권한 단위는 파일이라, 특정 열만 감추려면 파일을 쪼개야 하고 쪼갠 데이터는 반드시 어긋난다.

전환 시점 점수표

아래 항목에 해당하면 점수를 더한다. 합계 3점 이상이면 이관을 검토하고, 5점 이상이면 미루는 비용이 옮기는 비용을 넘어선 상태로 본다.

| 항목 | 배점 |
|---|---|
| 두 사람 이상이 같은 파일을 동시에 수정한다 | 2 |
| 값 변경 이력을 나중에 따져야 한다(재고·정산·회원) | 2 |
| 같은 정보가 두 파일 이상에 중복돼 있다 | 1 |
| 고객·직원이 화면에서 직접 값을 입력할 예정이다 | 2 |
| 파일 로딩·수식 계산이 눈에 띄게 느려졌다 | 1 |
| 특정 열만 일부 직원에게 숨겨야 한다 | 1 |

합계 0~2점이면 시트를 유지하는 편이 경제적이다. 혼자 쓰는 견적표나 월말 정산표를 옮기면 개발·운영 비용만 늘어난다. 전환은 사람이 겹치기 시작할 때 값을 한다.

이관 비용을 좌우하는 건 정제다

견적이 갈리는 지점은 개발이 아니라 데이터 정제인 경우가 많다. 옮기기 전에 아래 순서로 정리해두면 협의가 빨라진다.

1. 열 단위로 자료형을 확정한다. 날짜·금액·전화번호를 각각 어떤 형식으로 통일할지 먼저 정한다.
2. 중복 행을 판정할 기준 열을 고른다. 회원이면 연락처, 주문이면 주문번호처럼 유일값이 될 열이 필요하다.
3. 빈칸 처리 규칙을 정한다. 비워둘 수 있는 칸인지, 반드시 채워야 하는 칸인지 구분한다.
4. 과거 데이터의 보존 범위를 정한다. 3년 치를 전부 옮길지, 최근 1년만 옮기고 나머지는 파일로 보관할지 결정한다.
5. 정제 전후 행 수를 대조한다. 옮긴 뒤 숫자가 맞지 않으면 어디서 빠졌는지 추적할 근거가 된다.

이 다섯 가지가 정리돼 있으면 업체가 견적을 좁게 낼 수 있다. 반대로 형식이 뒤섞인 원본을 그대로 넘기면, 정제 공수가 견적의 큰 몫을 차지하고 그 몫은 대체로 발주자가 부담한다.

옮긴 뒤에도 시트는 남는다

데이터베이스를 도입한다고 스프레드시트를 버리지는 않는다. 원본은 데이터베이스에 두고, 분석·보고서는 필요할 때 시트로 내려받아 본다. 지켜야 할 규칙은 하나다. 원본은 한 곳에만 둔다. 이 원칙이 깨지면 두 벌의 데이터가 생기고, 결국 처음의 문제로 돌아간다.

Q. 데이터가 적으면 데이터베이스가 필요 없나요?
양이 아니라 동시성이 기준이다. 행 1만 개를 넷이 함께 고치는 쪽이 행 50만 개를 혼자 보는 쪽보다 사고 확률이 훨씬 높다.

Q. 엑셀을 잘 설계하면 데이터베이스를 대신할 수 있나요?
수식과 매크로로 입력 형식은 어느 정도 강제된다. 그러나 동시에 들어온 두 수정에 순서를 매기는 처리는 흉내 낼 수 없고, 중복 판매 사고는 바로 그 지점에서 난다.

이력과 권한 — 늦게 드러나는 두 가지

동시성 사고는 눈에 보인다. 중복 판매가 나거나 값이 사라지니 바로 안다. 반면 이력과 권한 문제는 한참 뒤에 드러난다.

정산이 틀어졌을 때 "이 금액을 누가 언제 고쳤는가"를 따질 수 없으면 원인을 찾지 못한다. 시트에도 변경 기록이 남지만 셀 단위로 추적하기는 어렵고, 몇 달 지난 기록은 사실상 못 쓴다. 데이터베이스는 값이 바뀔 때 누가 언제 무엇을 어떻게 바꿨는지 기록으로 남기도록 설계할 수 있다.

권한도 마찬가지다. 시트의 권한 단위는 파일이라, 아르바이트생에게 배송 상태만 보여주고 매출은 감추려면 파일을 따로 만들어야 한다. 그 순간 같은 데이터가 두 벌이 되고, 두 벌은 시간이 지나면 반드시 어긋난다. 데이터베이스에서는 같은 원본을 두고 열 단위로 접근을 나눈다.

원문: https://nova-lab.dev/r/t/what-is-database

자주 묻는 질문

Q. 엑셀 대신 데이터베이스를 써야 하는 기준이 뭔가요?

데이터 양보다 동시성이 기준이다.

두 사람 이상이 같은 파일을 동시에 고치거나, 누가 언제 값을 바꿨는지 추적해야 한다면 시트로는 오래 못 간다.

혼자 계산하고 끝나는 일이라면 엑셀이 여전히 빠르고 싸다.

Q. 구글시트는 몇 명까지 같이 쓸 수 있나요?

구글 고객센터에 따르면 문서 하나는 동시에 100개 탭 또는 기기에서만 편집할 수 있고, 그 수를 넘으면 소유자와 일부 편집자만 수정할 수 있다.

다만 실무에서는 셋만 함께 고쳐도 값이 덮이는 사고가 나기 때문에 이 숫자를 안전선으로 보면 안 된다.

Q. 지금 쌓인 엑셀 데이터를 그대로 옮길 수 있나요?

대부분 옮길 수 있다.

다만 형식이 뒤섞인 칸(전화번호·날짜·금액)은 정리하는 작업이 따로 붙고, 그 정리에 드는 시간이 이관 비용의 큰 몫을 차지한다.

견적을 받을 때 데이터 정제가 포함된 금액인지 따로 확인하는 게 좋다.

글 · 노바랩 NovaLab · https://nova-lab.dev

AI 검색 노출 점검 루틴 — robots.txt 3종 스위치와 4주 확인 사이클

novalab-official — Sun, 12 Jul 2026 20:02:24 +0900

AI 검색 최적화를 새로운 기술 도입 문제로 접근하면 대개 돈만 쓰고 끝난다. 실제로는 접근 권한 설정과 문서 구조 손질, 그리고 확인 사이클을 도는 운영 문제에 가깝다. 구글도 공식 AI 최적화 가이드에서 생성형 AI 검색 최적화는 결국 검색 경험 최적화이며 여전히 SEO라고 못 박았다.

그래서 이 글은 개념 설명 대신 점검 루틴만 다룬다.

1단계 — 크롤러 3종 스위치를 결정한다

OpenAI 공식 문서 기준으로 크롤러는 세 종류이고 robots.txt에서 각각 따로 제어된다. 셋을 한 덩어리로 다루는 순간 판단이 뭉개진다.

| 봇 | 역할 | 열었을 때 얻는 것 | 닫았을 때 잃는 것 |
|---|---|---|---|
| OAI-SearchBot | 챗GPT 검색 노출 | AI 답변의 출처 노출 | 출처 목록에서 제외 |
| GPTBot | 모델 학습용 수집 | 학습 데이터 편입 | 학습 제외(노출과 무관) |
| ChatGPT-User | 사용자 요청 시 방문 | 사용자가 준 링크를 읽음 | 링크를 줘도 못 읽음 |

핵심은 학습 차단과 노출 차단이 별개 스위치라는 점이다. 콘텐츠 무단 학습이 우려된다면 GPTBot만 닫고 OAI-SearchBot은 열어두면 된다. 셋을 통째로 막아놓고 인용이 안 된다고 말하는 사이트가 흔한데, 그건 최적화 이전에 설정 사고다.

2단계 — 문서를 조각 단위로 자기완결시킨다

AI는 페이지 전체를 통독하지 않고 문서 조각을 읽어 인용한다. 그래서 맥락이 조각 안에 들어 있어야 한다. 실무에서 손볼 지점은 세 곳이다.

첫째, 첫 문단이다. 제목이 던진 질문에 두세 문장으로 답을 끝내야 한다. 답이 스크롤 아래에 있으면 발췌 대상에서 밀린다. 둘째, 소제목이다. 가격·기간·조건처럼 실제로 자주 듣는 질문을 질문 형태 소제목으로 올리고 바로 아래 답을 붙인다. 셋째, 회사 정보다. 상호·지역·서비스 범위가 한 페이지 안에서 완결돼야 한다. "저희는"으로만 지칭된 문단은 인용돼도 누구 얘기인지 남지 않는다.

llms.txt는 이 단계에서 우선순위가 아니다. 구글은 llms.txt를 비롯한 AI 전용 파일을 쓰지 않는다고 공식 문서에 적었고, 만들어도 구글 검색 순위에는 득실이 없다.

3단계 — 4주 확인 사이클을 돈다

점검을 한 번 하고 끝내면 결과를 알 수 없다. 아래 주기를 한 번 돌려보면 어디가 막혔는지 드러난다.

1. 1주차: robots.txt 확인 및 스위치 조정, 변경 사항을 날짜와 함께 메모한다.
2. 2주차: 문의가 많이 들어오는 페이지 3개의 첫 문단과 소제목을 위 기준대로 고쳐 쓴다.
3. 3주차: 손대지 않고 기다린다. 크롤러가 재방문해 색인을 갱신할 시간을 준다.
4. 4주차: 챗GPT·퍼플렉시티에 자기 업종 질문을 5개 던지고, 출처에 자사 사이트가 뜨는지 기록한다. 안 뜨면 경쟁사 어느 페이지가 인용됐는지 확인한다.

이 기록이 쌓이면 무엇이 효과가 있었는지 추적된다. 4주차에 경쟁사 페이지를 열어보는 작업이 특히 값지다. 어떤 문단이 통째로 인용됐는지 보면 답 문단의 길이와 형식이 감으로 잡힌다.

비용을 어디에 쓸 것인가

1단계는 30분이면 끝나고 개발자도 필요 없다. 2단계는 글쓰기 노동이라 시간이 든다. 그래서 견적에 'AI 검색 최적화'가 별도 상품으로 붙어 온다면, 그 안에 무엇이 들었는지 항목별로 확인하는 편이 낫다. 파일 하나 올리는 작업과 본문을 다시 쓰는 작업은 성격도 값도 다르다.

Q. robots.txt에서 AI 봇을 전부 막으면 콘텐츠가 보호되나요?
학습용 GPTBot과 검색용 OAI-SearchBot은 따로 제어된다. 전부 막으면 학습뿐 아니라 AI 답변의 출처 목록에서도 빠지므로, 보호가 아니라 퇴장에 가깝다.

Q. llms.txt를 만들면 인용 확률이 올라가나요?
구글은 공식 가이드에서 llms.txt를 사용하지 않는다고 밝혔고 순위에도 영향이 없다고 적었다. 만들어도 무방하지만 본문 구조를 고치는 작업보다 앞세울 근거는 없다.

손보기 전과 후 — 소제목 하나의 차이

추상적으로 들릴 수 있으니 실제로 무엇을 고치는지 적어둔다. 서비스 페이지의 소제목이 '서비스 개요'이고 그 아래 문단이 회사 소개로 시작한다면, 그 조각은 어떤 질문에도 답하지 않는다. 인용될 근거가 없다.

같은 내용을 '시공 기간은 얼마나 걸리나요'라는 소제목으로 바꾸고, 바로 아래 첫 문장에서 "규모에 따라 다르지만 통상 2~4주가 걸린다"로 답을 끝내면 그 조각 하나가 독립적으로 인용 가능해진다. 문단 안에 회사명과 지역까지 들어 있으면 인용됐을 때 누구 얘기인지도 남는다.

바꿔야 할 문장은 대개 많지 않다. 문의로 자주 들어오는 질문 다섯 개가 페이지 어디에 답으로 존재하는지 확인하고, 그 다섯 개를 소제목 자리로 끌어올리는 작업이 대부분이다.

원문: https://nova-lab.dev/r/t/geo-aeo-ai-search-guide

자주 묻는 질문

Q. GEO와 SEO 중 뭘 먼저 해야 하나요?

SEO가 먼저다.

구글은 생성형 AI 검색 최적화도 결국 SEO라고 공식 가이드에 적었고, 색인에 들지 못한 페이지는 AI 답변에도 인용되지 않는다.

기본 점검을 끝낸 뒤 질문형 소제목과 자기완결적인 문단으로 GEO를 얹는 순서가 맞다.

Q. llms.txt는 꼭 만들어야 하나요?

구글은 llms.txt를 비롯한 AI 전용 파일을 쓰지 않는다고 공식 문서에 밝혔다.

올려도 구글 검색 순위에는 득도 실도 없다.

다른 서비스 때문에 유지하는 건 자유지만, 본문 개선보다 앞세울 일은 아니다.

Q. AI 봇을 막으면 콘텐츠가 보호되나요?

학습용 GPTBot과 검색용 OAI-SearchBot은 robots.txt에서 따로 제어된다.

전부 막으면 학습뿐 아니라 AI 답변의 출처 목록에서도 빠진다.

학습만 막고 검색 노출은 열어두는 설정이 가능하니 둘을 구분해서 결정하는 게 낫다.

글 · 노바랩 NovaLab · https://nova-lab.dev

검색엔진 작동 원리와 사이트 색인 등록 실무 절차

novalab-official — Sat, 11 Jul 2026 22:21:22 +0900

검색엔진은 크롤링, 색인, 순위 세 단계로 웹페이지를 찾아 결과에 노출한다. 각 단계의 역할과 사이트를 검색에 올리는 절차를 정리한다. 색인 단계를 놓치면 아무리 좋은 페이지도 검색에 나오지 않는다.

3단계 작동 원리

크롤링: 검색 로봇이 링크를 따라 이동하며 페이지를 수집한다. 링크가 없는 페이지는 수집에서 누락될 수 있다.
색인: 수집한 페이지의 제목·본문·이미지를 분석해 검색엔진 목록에 등록한다. 색인에 없으면 검색 대상 자체가 아니다.
순위: 색인된 페이지 중 검색어와의 관련성, 콘텐츠 품질, 외부 인용 등을 종합해 노출 순서를 정한다.

구글과 네이버 차이

등록 도구: 구글은 서치 콘솔, 네이버는 서치 어드바이저를 사용한다.
결과 구성: 구글은 웹페이지 중심, 네이버는 블로그·카페 등 자체 서비스 비중이 크다.
크롤링 성향: 구글은 링크 기반으로 폭넓게, 네이버는 등록된 사이트와 자체 서비스를 우선한다.
국내 유입을 고려하면 두 도구에 모두 등록하는 편이 안전하다.

색인 등록 실무 절차

구글 서치 콘솔과 네이버 서치 어드바이저에서 사이트 소유권을 확인한다.
사이트맵(sitemap.xml)을 생성해 각 도구에 제출한다.
주요 페이지의 색인 여부를 확인하고, 누락된 페이지는 색인(수집)을 요청한다.
robots.txt나 noindex 설정으로 색인이 차단되지 않았는지 점검한다.
페이지 제목과 본문을 실제 검색어에 맞게 정리해 순위 상승 여지를 만든다.

색인 점검 루틴

등록 후에는 다음 루틴으로 상태를 관리한다.

월 1회 site:도메인 검색으로 색인 페이지 수를 확인한다. 수가 줄면 차단 설정이나 오류를 의심한다.
새 페이지를 올리면 서치 콘솔·서치 어드바이저에서 수집을 요청한다. 자연 수집보다 빠르다.
제작 단계의 검색 차단(noindex, robots) 해제 여부를 오픈 시점에 반드시 확인한다. 색인 실패 원인 중 가장 흔하다.
www 유무, http/https가 섞여 있으면 대표 주소로 통합한다. 같은 내용이 두 주소로 잡히면 평가가 분산된다.

정리

크롤링은 발견, 색인은 등록, 순위는 정렬이다. 이 가운데 색인이 검색 노출의 전제 조건이다. 새 사이트는 등록과 사이트맵 제출부터 처리하고, 색인 상태를 확인한 뒤 콘텐츠를 다듬는 순서로 접근하면 검색 유입을 안정적으로 늘릴 수 있다.

자주 묻는 질문

Q. 색인까지 얼마나 걸리나?
새 사이트는 등록과 사이트맵 제출 후 보통 며칠에서 몇 주다. 한 달 넘게 비어 있으면 차단 설정과 중복 주소를 점검한다.

Q. 네이버와 구글 중 어디부터 등록하나?
순서는 무관하다. 도구가 다를 뿐 절차가 같으니 같은 날 둘 다 등록하는 편이 낫다.

원문: https://nova-lab.dev/blog/how-search-engine-works?utm_source=tistory&utm_medium=syndication&utm_campaign=how-search-engine-works

자주 묻는 질문

Q. 새로 만든 사이트가 검색에 안 떠요. 왜 그런가요?

대부분 아직 색인에 들지 않아서다.

검색엔진에 사이트를 등록하지 않았다면 크롤러가 방문하지 못해 색인이 잡히지 않는다.

구글 서치 콘솔과 네이버 서치 어드바이저에 사이트를 등록하고 사이트맵을 제출하면, 보통 며칠 안에 색인이 시작된다.

Q. 구글과 네이버 중 한 곳만 등록해도 되나요?

둘 다 등록하는 편을 권한다.

두 검색엔진은 페이지를 모으고 보여주는 방식이 서로 달라, 한쪽에만 등록하면 다른 쪽에서 유입될 손님을 놓친다.

국내 서비스라면 특히 네이버 등록을 빠뜨리지 않는 게 좋다.

Q. 색인에 들어가면 바로 검색 상위에 뜨나요?

그렇지는 않다.

색인은 검색 결과에 오를 자격을 얻는 단계이고, 그중 몇 번째에 놓일지는 순위가 따로 정한다.

페이지 내용이 검색어에 잘 답하고 시간이 지나 신뢰가 쌓이면 순위가 오르지만, 색인 직후부터 상위 노출이 보장되지는 않는다.

원문: https://nova-lab.dev/blog/how-search-engine-works?utm_source=tistory&utm_medium=syndication&utm_campaign=how-search-engine-works

글 · 노바랩 NovaLab · https://nova-lab.dev

프론트엔드·백엔드 역할 구분과 견적 항목 점검 체크리스트

novalab-official — Sat, 11 Jul 2026 22:02:43 +0900

웹 개발 견적서를 받으면 항목이 프론트엔드와 백엔드로 갈려 있는 경우가 많다. 두 영역의 역할을 알아야 견적을 제대로 검토하고, 문제가 생겼을 때 원인을 빠르게 좁힐 수 있다. 아래에 역할 구분과 점검 항목을 정리한다.

두 영역의 역할

프론트엔드는 사용자가 보는 화면과 상호작용을 담당한다. 화면 구성, 버튼, 글꼴, 반응형 배치, 애니메이션이 여기 속한다. 결과가 화면에 바로 드러난다.

백엔드는 화면 뒤에서 데이터를 처리하고 저장한다. 로그인 인증, 주문 기록, 재고 계산, 데이터베이스 연동이 대표적이다. 겉으로는 보이지 않지만 서비스의 핵심 로직이 여기서 돈다.

증상으로 원인 영역 좁히기

화면이 깨지거나 글자가 겹친다: 프론트엔드
특정 기기나 해상도에서만 배치가 틀어진다: 프론트엔드
버튼을 눌러도 반응이 없다: 프론트엔드(이벤트 연결 문제)
반응은 있으나 저장·조회 결과가 틀리다: 백엔드
로그인·결제·주문이 실패한다: 백엔드
데이터는 맞는데 표시 형식만 어긋난다: 프론트엔드

견적 검토 체크리스트

프론트엔드 항목에 반응형(모바일 대응)이 포함됐는지 확인한다.
백엔드 항목에 데이터 저장·회원·결제 등 필요한 기능이 빠짐없이 잡혔는지 본다.
소개용 홈페이지처럼 저장 기능이 없으면 백엔드 비중이 작거나 없을 수 있다.
회원·주문·결제가 있는데 백엔드 항목이 비어 있으면 처리 방식을 반드시 물어본다.
유지보수 범위가 프론트엔드와 백엔드 각각에 대해 명시됐는지 확인한다.

요구사항별 비용 귀속

수정·추가 요청이 어느 영역 비용으로 잡히는지 알면 견적 협상이 쉬워진다.

디자인 리뉴얼, 모바일 대응, 애니메이션: 프론트엔드
회원 등급, 포인트, 정산 자동화: 백엔드
검색·필터 기능: 화면은 프론트엔드, 조회 속도는 백엔드
페이지 로딩 속도 개선: 대개 양쪽 모두(이미지·스크립트는 앞, 조회 구조는 뒤)

저장할 데이터가 없는 소개형 사이트는 비용 대부분이 프론트엔드다. 회원·주문·결제가 들어가면 백엔드 비중이 절반 안팎까지 올라가는 견적이 흔하다. 항목별로 화면 쪽인지 데이터 쪽인지 물었을 때 답이 명확한 업체를 고르는 편이 안전하다.

정리

프론트엔드와 백엔드는 담당 영역, 노출 여부, 필요한 기술이 다르다. 그래서 견적서도 둘로 나뉜다. 증상을 화면이냐 데이터냐로 나누면 문의와 수리가 빨라지고, 견적을 볼 때도 어느 항목이 무엇을 위한 비용인지 판단할 수 있다.

자주 묻는 질문

Q. 프론트엔드와 백엔드 중 어느 쪽 개발자가 필요한지 어떻게 판단하나?
화면·배치·반응형 문제면 프론트엔드, 저장·조회·결제 오류면 백엔드다. 증상을 둘로 나눠 전달하면 배정이 빨라진다.

Q. 견적서에 백엔드 항목이 없는데 정상인가?
저장 기능이 없는 소개형 사이트라면 정상이다. 회원·주문·결제가 있는데 백엔드가 비어 있으면 처리 방식을 반드시 확인해야 한다.

원문: https://nova-lab.dev/blog/frontend-vs-backend

자주 묻는 질문

Q. 프론트엔드와 백엔드, 한 사람이 다 할 수 있나요?

가능하다.

두 영역을 함께 다루는 개발자를 흔히 풀스택이라 부른다.

다만 규모가 커지면 화면과 데이터 처리를 나눠 맡는 편이 속도와 안정성에서 유리하다.

작은 소개용 홈페이지는 한 사람이, 기능이 많은 서비스는 팀으로 진행하는 경우가 많다.

Q. 견적서에 프론트엔드만 있고 백엔드가 없으면 문제인가요?

사이트 성격에 따라 다르다.

소개용 홈페이지처럼 데이터를 저장하지 않는 사이트는 백엔드가 거의 필요 없다.

반대로 회원가입·주문·결제가 있으면 백엔드 비용이 빠졌는지 반드시 확인해야 한다.

항목이 없다면 그 기능을 어떻게 처리하는지 물어보는 게 안전하다.

Q. 화면 문제인지 데이터 문제인지 제가 정말 구분할 수 있나요?

완벽히는 아니어도 방향은 잡을 수 있다.

눈에 보이는 게 어긋나면 화면, 저장·조회·결제 결과가 어긋나면 데이터 쪽이라고 보면 대체로 맞는다.

정확한 진단은 업체 몫이지만, 이렇게 나눠 전달하면 소통이 훨씬 빨라진다.

글 · 노바랩 NovaLab · https://nova-lab.dev