초록
AI에게 "회사 홈페이지 만들어 줘"라고 하면 30분 만에 그럴듯한 사이트가 나옵니다. 이 사실 자체는 논쟁거리가 아닙니다. 논쟁이 되는 지점은 그것을 회사의 공식 사이트로 올려 놓고 몇 년을 운영할 수 있는가입니다. 이 글은 AI 생성 결과물을 비난하거나 옹호하지 않고, 데모에서는 보이지 않다가 운영에서 반드시 드러나는 항목을 목록으로 만듭니다. 계정과 소스의 소유권, 비밀키 취급, 폼·인증·권한, 백업과 복구, 장애가 났을 때의 경로, 법적 고지, 의존성 노후화가 그 목록입니다. 각 항목에서 AI 생성 결과물이 통상 어디까지 채워 주고 어디가 비는지를 밝히고, 그 공백을 메우는 데 드는 실제 작업을 적습니다. 마지막으로 AI로 끝까지 가도 되는 경우와 사람이 받아야 하는 경우를 조건으로 구분합니다. 특정 도구의 우열은 다루지 않습니다.
1. 서론
작년까지 이 질문은 개발자들 사이의 논쟁이었습니다. 올해는 의사결정자의 질문이 되었습니다.
"직원이 AI로 사이트를 하나 만들었는데, 이걸 그냥 회사 사이트로 써도 될까요?"
이 질문에 "안 됩니다"라고 답하면 대개 틀립니다. 실제로 잘 굴러가는 경우가 있기 때문입니다. "됩니다"라고 답해도 대개 틀립니다. 몇 달 뒤에 문제가 생기는 경우도 있기 때문입니다.
정확한 답은 무엇을 만들었느냐가 아니라 무엇이 빠졌느냐에 달려 있습니다. 그리고 빠진 것들은 공통점이 있습니다. 화면에 안 보인다는 것입니다. 그래서 만든 사람도 검수하는 사람도 놓칩니다.
이 글은 그 안 보이는 목록입니다. 체크리스트로 쓸 수 있게 썼습니다.
먼저 한 가지를 분명히 해 두겠습니다. 이 글은 AI로 만들지 말라는 글이 아닙니다. 마지막 장에서 AI로 끝까지 가도 되는 경우를 따로 정리합니다. 실제로 그런 경우가 적지 않습니다.
2. AI가 잘하는 것과 못하는 것
목록에 들어가기 전에 경계를 그려 두는 편이 낫겠습니다. 현재 시점에서 관측되는 경향입니다.
확실히 잘하는 것
- 화면 만들기. 레이아웃, 반응형, 애니메이션, 컴포넌트 구조
- 흔한 패턴의 코드. 문의 폼, 목록·상세, 탭, 슬라이더
- 일회성 스크립트와 데이터 변환
- 문서화. 시키면 잘 씁니다. 안 시키면 안 씁니다
- 오류 메시지를 주면 원인 좁히기
잘 안 되는 것
- 결정을 기억하는 것. 왜 이렇게 했는지가 코드에 남지 않습니다
- 전체 일관성. 열 번의 대화로 만든 사이트는 열 가지 방식이 섞여 있는 경우가 많습니다
- 안 물어본 것을 챙기는 것. 이 글의 핵심입니다. 요청하지 않은 항목은 대체로 비어 있습니다
- 운영 환경과 개발 환경의 차이. 로컬에서 되는데 배포하면 안 되는 종류의 문제
- 책임. 잘못됐을 때 대응할 주체가 없습니다
정리하면 이렇습니다. 보이는 것은 잘 만들고, 안 보이는 것은 요청받은 만큼만 만듭니다. 그리고 대부분의 사람은 안 보이는 것을 요청할 줄 모릅니다. 몰라서가 아니라 존재를 몰라서입니다.
그 목록이 아래입니다.
3. 목록 하나 — 소유권
가장 먼저 확인해야 하고, 가장 자주 빠집니다.
AI로 사이트를 만들면 여러 서비스에 계정이 생깁니다. 배포 플랫폼, 도메인 등록기관, 데이터베이스, 이메일 발송, 분석 도구, 이미지 저장소. 각각에 계정이 있고, 그 계정에는 소유자가 있습니다.
문제는 그 소유자가 회사가 아니라 만든 사람 개인인 경우가 압도적으로 많다는 것입니다. 개인 이메일로 가입하고, 개인 카드로 결제하고, 개인 GitHub에 코드를 올립니다. 만든 사람이 직원이면 그나마 낫고, 알바나 외부인이면 상황이 나빠집니다.
이게 왜 문제인지는 그 사람이 그만두는 날 드러납니다. 사이트는 잘 돌아가는데 아무도 손댈 수 없는 상태가 됩니다. 결제 카드가 만료되면 어느 날 사이트가 내려갑니다.
확인할 것
| 항목 | 확인 질문 |
|---|---|
| 도메인 | 등록자가 회사 명의인가. 관리 계정에 접근 가능한가 |
| 배포 플랫폼 | 팀 계정인가 개인 계정인가. 결제 수단이 회사 것인가 |
| 소스 저장소 | 회사 조직 계정에 있는가. 최소 두 사람이 접근 가능한가 |
| 데이터베이스 | 소유 계정. 데이터를 우리가 내보낼 수 있는가 |
| 메일 발송 | 발신 도메인 인증이 우리 도메인 기준인가 |
| 분석·광고 | 소유권 이전이 가능한 형태인가 |
도메인이 특히 중요합니다. 다른 것은 최악의 경우 다시 만들 수 있지만, 도메인은 우리 것이 아니면 되찾기 어렵고 그동안 쌓인 검색 자산이 전부 날아갑니다.
이 항목은 AI가 만들었든 외주로 만들었든 똑같이 적용됩니다. 다만 외주 계약서에는 대개 소유권 조항이 있고, 직원이 AI로 만든 경우에는 아무 문서도 없다는 차이가 있습니다.
4. 목록 둘 — 비밀키
AI가 코드를 만들 때 API 키, 데이터베이스 접속 정보, 결제 비밀키 같은 것을 다루게 됩니다. 여기서 사고가 납니다.
흔한 사고 세 가지
첫째, 키가 소스에 그대로 박혀 있다. 그리고 그 소스가 공개 저장소에 올라가 있습니다. 공개 저장소를 자동으로 훑어 키를 찾아내는 도구가 실제로 돌아다니고, 발견까지 수 분 걸리는 경우도 있습니다. 클라우드 계정 키가 새면 남이 우리 카드로 서버를 돌립니다.
둘째, 브라우저에서 보이면 안 되는 키가 브라우저로 나간다. 프런트엔드 코드에 넣은 값은 사용자가 전부 볼 수 있습니다. 프레임워크마다 "브라우저로 나가는 변수"의 이름 규칙이 정해져 있는데(예: NEXT_PUBLIC_ 접두사), 이걸 모르고 붙이면 비밀키가 그대로 공개됩니다. 화면은 잘 동작하므로 알아채기 어렵습니다.
셋째, 만든 사람의 개인 키를 쓰고 있다. 개인 계정의 무료 한도로 만들었다가, 트래픽이 늘면 그 사람에게 청구가 갑니다. 또는 그 사람이 키를 폐기하면 사이트가 멈춥니다.
확인 방법
소스에 접근할 수 있다면 이 정도로 1차 확인이 됩니다.
# 흔한 키 형태를 훑기
grep -rnE "(sk_live|sk_test|AKIA|AIza|xox[baprs]-|-----BEGIN [A-Z ]*PRIVATE KEY)" . \
--exclude-dir={node_modules,.git,.next,dist,build}
# 브라우저로 나가는 변수에 비밀스러운 이름이 붙어 있지 않은지
grep -rn "NEXT_PUBLIC_" . --exclude-dir={node_modules,.git,.next} | grep -iE "secret|key|token|password"
두 번째 명령에서 뭔가 나오면 그 값은 이미 공개된 것으로 간주하고 폐기 후 재발급해야 합니다. 코드에서 지우는 것만으로는 부족합니다. 저장소 이력에 남아 있고, 이미 배포된 파일에도 남아 있습니다.
브라우저에서 직접 확인할 수도 있습니다. 사이트를 열고 개발자 도구의 소스 탭에서 secret, key, token 같은 단어를 검색해 보십시오.
5. 목록 셋 — 입력을 받는 모든 곳
화면상 가장 단순해 보이는 문의 폼이 운영에서 가장 자주 문제가 됩니다.
메일이 안 간다. 로컬에서는 갔는데 배포하면 안 가는 경우가 흔합니다. 원인은 대개 환경변수 설정, 발신 도메인 인증(SPF·DKIM·DMARC), 또는 스팸함 직행입니다. 이 구조는 Resend로 문의 폼 메일 보내기에서 갈라지는 지점을 따로 정리해 두었습니다.
메일이 가는데 안 본다. 발송은 되는데 대표 메일함이 방치되어 있는 경우입니다. 웃을 일이 아니라 실제로 자주 있습니다. 문의 폼을 만들었으면 누가 며칠 안에 확인하는가를 정해야 합니다.
메일만 가고 남지 않는다. 메일이 유실되거나 잘못 삭제되면 그 문의는 사라집니다. 데이터베이스에 함께 저장하는 편이 안전합니다.
스팸이 쏟아진다. 아무 보호 장치 없는 폼은 자동 프로그램이 금방 찾아냅니다. 하루에 수백 건이 들어오기 시작하면 진짜 문의가 묻힙니다. 최소한 봇 판별이나 간단한 검증 하나는 필요합니다.
입력값 검증이 프런트에만 있다. AI가 만든 폼은 화면 쪽 검증은 잘 넣는데, 서버 쪽 검증이 비는 경우가 있습니다. 화면 검증은 우회할 수 있으므로 실질적인 방어가 되지 않습니다.
받은 개인정보를 어떻게 다루는지가 없다. 이름과 연락처를 받으면 그 순간부터 개인정보 처리입니다. 수집 항목·목적·보유기간 고지와 동의 절차가 필요합니다. 이건 개발이 아니라 준수 사항이고, 요청하지 않으면 AI가 알아서 넣지 않습니다.
로그인 기능이 있다면 난이도가 한 단계 올라갑니다. 세션 발급·검증·만료의 계약이 어긋나면 조용히 뚫립니다. 이 부분은 Auth.js 세션 골격론에서 따로 다뤘습니다. 로그인이 필요한 사이트라면 AI 생성 결과물을 그대로 운영에 올리는 것을 권하지 않습니다.
6. 목록 넷 — 데이터가 사라졌을 때
데모에는 데이터가 없습니다. 운영에는 있습니다. 이 차이가 만드는 항목들입니다.
백업이 있는가. 데이터베이스를 쓰는 사이트라면 자동 백업이 켜져 있는지 확인하십시오. 관리형 서비스는 대개 기본 제공하지만, 무료 등급에서는 보관 기간이 짧거나 아예 없는 경우가 있습니다.
복구를 해 본 적이 있는가. 백업이 있다는 것과 복구가 된다는 것은 다릅니다. 한 번은 실제로 복구해 봐야 압니다. 30분이면 확인됩니다.
잘못 지웠을 때 되돌릴 수 있는가. 관리자 화면에 삭제 버튼이 있다면, 실수로 눌렀을 때 어떻게 되는지 확인하십시오. 즉시 완전 삭제되는 구조라면 표시만 하고 실제로는 남기는 방식으로 바꾸는 편이 안전합니다.
개인정보 파기 규칙이 있는가. 백업과 반대 방향의 요구입니다. 보유기간이 지난 정보는 지워야 하고, 백업본에도 그 규칙이 적용되어야 합니다.
7. 목록 다섯 — 장애가 났을 때
누가 아는가. 사이트가 내려갔을 때 알려 주는 장치가 없으면, 고객 전화로 알게 됩니다. 외형 감시 서비스는 무료 등급으로도 충분한 경우가 많습니다. 5분이면 붙입니다.
어디를 보는가. 오류가 났을 때 기록이 남는 곳이 정해져 있어야 합니다. 배포 플랫폼의 로그 화면이든 별도 오류 수집 도구든, 주소를 알고 있는 사람이 있어야 합니다.
누가 고치는가. 이 질문에 이름이 안 나오면 나머지는 무의미합니다. 만든 사람이 퇴사했고 아무도 코드를 안 읽어 봤다면, 장애는 곧 며칠짜리 정지입니다.
되돌릴 수 있는가. 배포 후 문제가 생겼을 때 직전 상태로 돌리는 방법이 있는지 확인하십시오. 대부분의 배포 플랫폼이 클릭 한 번으로 지원하는데, 그 기능이 있다는 걸 모르는 경우가 많습니다.
이 네 질문은 기술 수준이 아니라 운영 체계의 질문입니다. AI로 만들었든 대형 업체가 만들었든 똑같이 필요합니다. 다만 외주 계약에는 대개 유지보수 조항이 붙어 있고, AI로 직접 만든 경우에는 그 자리가 비어 있습니다. 유지보수 범위를 문장으로 고정하는 방법은 홈페이지 유지보수 계약에서 따로 다룹니다.
8. 목록 여섯 — 법적으로 있어야 하는 것들
화면에 안 보이지만 없으면 문제가 되는 것들입니다. 요청하지 않으면 AI가 만들지 않습니다.
개인정보 처리방침. 개인정보를 조금이라도 수집하면 필요합니다. 문의 폼 하나만 있어도 해당합니다. 남의 사이트에서 복사해 오는 경우가 많은데, 우리가 실제로 수집하는 항목과 다르면 없느니만 못합니다.
사업자 정보 표시. 상호, 대표자, 사업자등록번호, 주소, 연락처. 통신판매를 한다면 통신판매업 신고번호도 함께입니다.
쿠키·추적 안내. 분석 도구나 광고 태그를 붙였다면 그 사실이 안내되어야 합니다. 최소 기준은 개인 사이트 쿠키·개인정보 안내에 정리해 두었습니다.
이미지와 폰트의 출처. AI가 만든 사이트에 들어간 이미지가 어디서 왔는지 확인하십시오. 무료 이미지 사이트에서 가져온 것이라면 상업적 이용이 허용되는지, 폰트는 웹 사용이 허용되는 라이선스인지. 폰트 라이선스 문제는 국내에서 실제로 분쟁이 자주 나는 항목입니다.
접근성. 공공 부문이나 일정 규모 이상이면 법적 요구가 있고, 그렇지 않더라도 기본은 갖추는 편이 낫습니다. AI가 만든 화면은 대비나 대체 텍스트가 비는 경우가 흔합니다. 체크리스트는 WCAG 2.2 기준 웹 접근성에 실무 수준으로 정리해 두었습니다.
9. 목록 일곱 — 시간이 지나면 생기는 문제
이 항목은 만든 날에는 전혀 보이지 않습니다. 1년쯤 뒤에 나타납니다.
의존성이 낡습니다. 사이트는 수십 개의 외부 패키지 위에 서 있고, 그중 일부에서 보안 취약점이 발견됩니다. 아무도 갱신하지 않으면 취약한 상태로 계속 서비스됩니다.
갱신하면 깨집니다. 그래서 미루게 되고, 미루면 나중에 한꺼번에 올려야 해서 더 어려워집니다. 정기적으로 조금씩 올리는 편이 결국 쌉니다.
인증서와 결제 수단이 만료됩니다. HTTPS 인증서는 대부분 자동 갱신되지만 설정에 따라 아닌 경우가 있고, 카드 만료는 자동으로 해결되지 않습니다. 어느 날 서비스가 정지됩니다.
코드를 아무도 못 읽습니다. 이게 가장 큰 문제입니다. AI와 대화하며 만든 코드에는 왜 그렇게 했는지가 남지 않습니다. 6개월 뒤 본인이 봐도 낯설고, 다른 사람이 보면 처음부터 다시 짜는 게 빠르다는 판단이 나옵니다.
이 마지막 항목은 완화할 수 있습니다. 만드는 동안 README에 세 가지만 적어 두면 됩니다.
- 어떻게 띄우는가 — 필요한 환경변수 목록과 실행 명령
- 어디에 무엇이 있는가 — 폴더 구조 서너 줄
- 왜 그렇게 했는가 — 되돌리면 안 되는 결정들
AI에게 시키면 잘 씁니다. 시키지 않으면 안 씁니다.
10. 그래서 AI로 끝까지 가도 되는 경우
여기까지 읽으면 하지 말라는 글처럼 보이겠지만, 아닙니다. 아래 조건에서는 AI로 만들어 그대로 운영해도 무리가 없고, 오히려 외주가 과합니다.
조건 A — 정보를 보여 주기만 하는 사이트. 회사 소개, 제품 소개, 오시는 길. 입력받는 것이 없거나 문의 폼 하나뿐이고, 로그인도 결제도 없는 경우. 이런 사이트에서 3~7장의 목록은 대부분 해당하지 않거나 아주 가볍게 처리됩니다.
조건 B — 내부에서만 쓰는 도구. 사내 사람만 접근하는 관리 도구, 계산기, 조회 화면. 사고가 나도 외부 피해가 없고, 쓰는 사람이 문제를 바로 말해 줍니다.
조건 C — 검증용 페이지. 아이디어를 시험하는 랜딩, 사전 신청 페이지, 캠페인 페이지. 수명이 짧고, 실패해도 잃을 것이 적습니다. 오히려 빠르게 만드는 것이 목적에 맞습니다.
조건 D — 최소한 한 사람이 코드를 읽을 수 있는 조직. 이게 실질적인 분기점입니다. AI가 만든 코드를 읽고 판단할 수 있는 사람이 사내에 있으면, 위 목록의 대부분은 그 사람이 채울 수 있습니다. 없으면 채워지지 않습니다.
반대로 사람이 받아야 하는 경우는 이렇습니다.
- 로그인·회원 기능이 있다
- 결제를 받는다
- 개인정보를 규모 있게 다룬다 (회원 명부, 이력서, 진료·상담 기록)
- 사이트가 멈추면 매출이 멈춘다
- 규제 업종이다
- 앞으로 몇 년간 계속 고쳐 나갈 예정이다
마지막 항목이 의외로 중요합니다. 한 번 만들고 두는 사이트와 계속 고칠 사이트는 요구 조건이 다릅니다. 계속 고칠 예정이라면 코드가 읽히는 상태로 만들어져야 하고, 그것이 지금 시점에서 AI 생성 결과물의 가장 약한 부분입니다.
우리 상황이 어느 쪽인지 가늠이 안 된다면 혼자 만들지 팀에 맡길지 판단하는 도구에서 조건을 골라 확인할 수 있습니다.
11. 이미 만들어진 것을 넘겨받는다면
직원이나 외부인이 AI로 만든 사이트를 회사가 인수하는 상황이 실제로 자주 생깁니다. 순서는 이렇습니다.
1단계. 계정부터. 3장의 표를 그대로 씁니다. 소유권 이전이 안 되는 서비스가 있다면 그 목록을 만듭니다. 사람이 아직 협조적일 때 해야 합니다. 관계가 나빠진 뒤에는 못 합니다.
2단계. 소스 확보. 코드를 회사 저장소로 옮기고, 최소 두 사람이 접근 권한을 갖습니다. 배포에 필요한 환경변수 목록을 함께 받습니다. 값이 아니라 목록이 중요합니다. 무엇이 필요한지 모르면 다시 띄울 수 없습니다.
3단계. 키 전면 교체. 넘겨받은 키는 이미 다른 사람이 알고 있는 키입니다. 전부 새로 발급하고 옛것을 폐기합니다. 이 과정에서 어떤 서비스를 쓰고 있었는지도 드러납니다.
4단계. 4~8장 목록 점검. 각 항목에 ○/×를 매깁니다. ×가 어디에 몰려 있는지가 다음 작업 목록입니다.
5단계. 다시 띄워 보기. 받은 소스와 목록만으로 다른 환경에 한 번 띄워 봅니다. 여기서 성공하면 인수가 끝난 것이고, 실패하면 아직 못 받은 것이 있는 것입니다. 이 단계를 건너뛰면 인수했다고 착각하게 됩니다.
12. 결론
세 문장으로 정리합니다.
첫째, AI 생성 결과물의 문제는 품질이 아니라 범위입니다. 화면은 잘 만듭니다. 안 보이는 것 — 소유권, 키, 백업, 장애 경로, 법적 고지 — 은 요청받은 만큼만 만듭니다. 그리고 대부분의 사람은 그것을 요청할 줄 모릅니다. 그러니 검수는 화면이 아니라 이 글의 목록으로 하십시오.
둘째, 분기점은 도구가 아니라 조직입니다. 만든 코드를 읽고 판단할 사람이 하나라도 있는 조직에서는 AI로 만든 사이트가 잘 굴러갑니다. 없는 조직에서는 외주로 만들어도 시간이 지나면 같은 문제에 도달합니다. "누가 이걸 계속 볼 것인가"가 실질적인 질문입니다.
셋째, 전부 아니면 전무가 아닙니다. 소개 사이트는 AI로, 로그인과 결제가 붙는 부분은 사람이 — 이렇게 나누는 것이 실제로 가장 흔하고 합리적인 답입니다. 판단 기준은 사고가 났을 때 잃는 것의 크기이지, 만든 방법의 격이 아닙니다.
마지막으로 하나. 이 글의 목록은 AI로 만든 사이트에만 해당하지 않습니다. 외주로 받은 사이트를 검수할 때도 같은 목록이 쓰입니다. 다만 외주에는 계약서와 청구서라는 강제 장치가 있어서 일부가 자동으로 채워지고, 직접 만든 경우에는 아무도 묻지 않기 때문에 비어 있을 뿐입니다.
넘겨받거나 새로 지을 범위를 잡아 대략의 비용 구간을 보고 싶다면 외주 개발 비용 계산기에서 확인할 수 있습니다. 연락처를 남기지 않아도 결과는 그대로 보입니다.