① 관리자(CMS) 포함 여부 ② 퍼블리싱 별도인지 ③ 지원 브라우저 범위 ④ 시안 수정 횟수 ⑤ 프로토타입까지인지 목업까지인지. 이 5개만 문서로 못 박아도 분쟁의 대부분이 사라집니다.
Publishing · Markup
견적서에 "퍼블리싱 별도"라고 적혀 있을 때. 빠지면 화면이 안 나옵니다.
디자인 시안을 HTML/CSS로 화면에 옮기는 작업입니다. 기능은 없고 겉모습만 만듭니다.
한국 웹 업계에만 있는 직군입니다. 해외에는 없고 프론트엔드 개발자가 함께 합니다. 외주 견적을 볼 때 "퍼블리싱 별도"인지 "프론트 포함"인지 확인해야 합니다 — 이게 빠지면 시안은 있는데 화면이 없는 상태가 됩니다.
견적에 퍼블리싱(HTML/CSS 작업)이 포함되어 있는지 확인 부탁드립니다. 별도라면 그 비용과 일정도 함께 알려주세요. 디자인 시안만으로는 화면이 나오지 않습니다.
Frontend · Backend
버그를 보고할 때 — 어느 쪽 문제인지 말하면 대응이 빨라집니다.
프론트엔드는 사용자가 직접 보고 만지는 화면, 백엔드는 서버에서 데이터를 처리·저장하는 부분입니다.
"버튼이 안 눌려요"는 프론트, "저장이 안 돼요"는 대개 백엔드입니다. 어느 쪽 문제인지 구분해서 말하면 대응이 훨씬 빨라집니다. 잘 모르겠으면 "화면에서 어떻게 보이는지"를 그대로 설명하는 게 최선입니다.
버그를 보고할 때 화면에서 본 그대로 적겠습니다 — 어떤 화면에서 / 무엇을 눌렀더니 / 무엇이 기대와 달랐는지. 프론트 문제인지 백엔드 문제인지는 판단하지 않고 현상만 전달드립니다.
Application Programming Interface
"API 나와야 붙일 수 있어요" — 일정이 밀리는 대표적 이유.
시스템끼리 데이터를 주고받는 약속입니다. 프론트엔드가 백엔드에게 "회원 정보 주세요"라고 요청하는 창구입니다.
"API 나와야 붙일 수 있어요"는 백엔드 작업이 끝나야 화면에 실제 데이터를 연결할 수 있다는 뜻입니다. 그래서 API 일정이 프론트 일정을 결정합니다. 일정 협의할 때 이 의존 관계를 꼭 확인하세요.
API 개발 완료 예정일을 알려주세요. 프론트 화면 작업은 그 전에 끝나도 실제 데이터 연동은 API가 나온 뒤에 가능합니다. 일정에 이 의존 관계를 반영해야 합니다.
CMS · Admin
"관리자 페이지 포함인가요?" — 견적을 두 배로 바꾸는 질문.
콘텐츠를 직접 등록·수정할 수 있는 관리자 화면입니다. 개발자 없이 공지사항을 올리거나 상품을 추가할 수 있게 해줍니다.
사용자에게 보이는 건 왼쪽뿐이지만, 오른쪽도 똑같이 만들어야 합니다.
"관리자 페이지 포함인가요?"가 견적을 거의 두 배로 바꿉니다. 사용자 화면 20개짜리 프로젝트면 관리자 화면도 15~20개가 필요합니다. 계약 전 반드시 확인할 항목 1순위입니다.
"공지사항을 직접 올리고 싶다"는 요구가 있으면 이미 관리자 화면이 필요한 상황입니다. 계약서에 포함 여부를 명시하세요.
관리자(CMS) 화면이 필요한지 확인 부탁드립니다. 콘텐츠를 직접 등록·수정하시려면 관리자 화면이 별도로 필요하고, 사용자 화면과 비슷한 규모의 작업량이 추가됩니다.
Static · Dynamic Page
"간단한 홈페이지 하나만" — 로그인·게시판이 있으면 간단하지 않습니다.
정적은 누가 봐도 같은 고정된 내용, 동적은 데이터나 사용자에 따라 바뀌는 내용입니다.
회사 소개 · 오시는 길
내용이 고정됨
상품 목록 · 마이페이지
데이터에 따라 바뀜
회사 소개 페이지는 정적, 상품 목록은 동적입니다. 동적 페이지는 서버·데이터베이스가 필요해서 비용과 일정이 다릅니다. "간단한 홈페이지"라고 했는데 로그인·게시판이 있으면 그건 동적입니다.
요청하신 기능 중 로그인·게시판·상품 관리가 있어 동적 페이지입니다. 서버와 데이터베이스가 필요하므로 정적 홈페이지와는 비용·일정이 다릅니다. 범위를 다시 정리해드리겠습니다.
Single Page Application
"앱처럼 부드럽게 넘어가게 해주세요" — SEO 얘기가 따라옵니다.
페이지 새로고침 없이 화면이 바뀌는 방식입니다. 앱처럼 매끄럽게 전환됩니다.
클릭 → 흰 화면 → 새 페이지
매번 전체를 다시 불러옴
클릭 → 바뀐 부분만 교체
깜빡임 없이 전환
전환이 부드럽지만 첫 로딩이 느릴 수 있고, 검색엔진 노출(SEO)에 불리할 수 있습니다. 마케팅이 중요한 서비스라면 이 부분을 개발과 미리 상의해야 합니다.
SPA로 만들면 화면 전환은 부드럽지만 검색 노출에 불리할 수 있습니다. 검색 유입이 중요한 서비스라면 SSR(서버 렌더링)을 함께 검토해주세요.
Staging · Production · 테스트 서버 / 운영 서버
"실서버에 올렸어요" — 진짜 사용자에게 보인다는 뜻입니다.
스테이징은 테스트용 서버, 프로덕션은 실제 사용자가 쓰는 운영 서버입니다.
"운영에 반영했다"는 진짜 사용자에게 보인다는 뜻입니다. 검수는 반드시 스테이징에서 하고, 확인이 끝난 것만 운영에 올립니다. 스테이징 주소를 검색엔진이 수집하지 않도록 막았는지도 확인하세요.
검수는 스테이징(테스트 서버)에서 진행하고, 확인이 끝난 것만 운영에 반영해주세요. 그리고 스테이징 주소가 검색엔진에 노출되지 않도록 막아주세요.
Deploy
"수정했어요"와 "배포했어요"는 다릅니다.
작업한 코드를 서버에 올려 실제로 반영하는 것입니다.
"수정했어요"와 "배포했어요"는 다릅니다. 코드는 고쳤지만 아직 서버에 안 올렸다면 사용자에게는 그대로 보입니다. 검수할 때 "배포됐나요?"를 먼저 확인하세요.
수정 사항이 배포되었는지 확인 부탁드립니다. 코드만 수정하고 배포 전이면 제가 보는 화면에는 반영되지 않습니다. 배포 완료 후 알려주시면 검수하겠습니다.
Quality Assurance · 품질 검수
"다 고쳐주세요" — 우선순위를 붙여야 하는 순간.
만들어진 결과물이 요구대로 동작하는지 확인하는 단계입니다.
우선순위(P1~P3)를 붙여야 "다 고쳐주세요"에서 벗어날 수 있습니다.
QA 기간을 일정에 안 잡으면 오픈일이 밀립니다. 보통 전체 일정의 15~20%가 필요합니다. 그리고 QA는 개발자가 아니라 제3자가 해야 의미가 있습니다 — 만든 사람은 자기 실수를 못 봅니다.
QA 이슈에 우선순위를 붙여 전달하겠습니다 — P1(오픈 불가·즉시 수정) / P2(오픈 전 수정) / P3(여유될 때). 전체를 같은 무게로 다루면 정작 중요한 걸 놓칩니다.
Issue · Ticket
카톡으로 수정 요청을 보내려다 — 반드시 누락됩니다.
수정 요청이나 버그를 하나씩 등록한 단위입니다. Jira, Notion, GitHub 등에 기록합니다.
카톡으로 수정 요청하면 반드시 누락됩니다. 이슈로 등록해야 담당자·상태·기한이 남습니다. 좋은 이슈는 ①어떤 화면에서 ②무엇을 했더니 ③무엇이 기대와 달랐는지 세 가지가 다 적혀 있습니다.
수정 요청은 카톡 대신 이슈로 등록하겠습니다. 각 이슈에 ①화면 ②재현 방법 ③기대 결과 ④실제 결과 ⑤환경(기기·브라우저)을 적겠습니다.
Requirements Document
"그건 당연히 포함이죠" — 분쟁이 났을 때의 기준.
무엇을 만들지 합의한 문서입니다. 기능 목록과 범위를 적습니다.
| 번호 | 기능 | 포함 |
|---|---|---|
| R-01 | 이메일 회원가입 | O |
| R-02 | 소셜 로그인(카카오) | O |
| R-03 | 소셜 로그인(애플) | X |
"포함 X"를 명시해두는 것이 "포함 O"만큼 중요합니다.
범위 분쟁이 났을 때 기준이 되는 문서입니다. "그건 당연히 포함이죠"라는 말이 나오면 이 문서를 봅니다. 없으면 무조건 요청하는 쪽이 이깁니다. 애매한 표현("사용하기 편하게")은 빼고 확인 가능한 문장으로 적으세요.
요구사항 정의서에 포함/미포함을 명확히 적어주세요. 특히 "포함하지 않는 것"을 적어두는 게 중요합니다 — 애플 로그인 미포함, 다국어 미포함처럼요.
Scope Creep · 범위 증식
"이거 하나만 더" — 열 번 쌓이면 프로젝트가 무너집니다.
합의한 범위 밖의 요구가 조금씩 계속 늘어나는 현상입니다.
외주 프로젝트 최대 리스크입니다. "이거 하나만 더"가 열 번 쌓이면 프로젝트가 무너집니다. 거절하라는 뜻이 아니라 "가능합니다. 다만 일정이 3일 늘고 비용이 발생합니다"라고 매번 명시하라는 뜻입니다. 기록으로 남기면 대부분 스스로 정리됩니다.
요청하신 기능은 가능합니다. 다만 계약 범위 밖이라 일정이 약 3일 늘어나고 추가 비용이 발생합니다. 진행할지, MVP 이후로 미룰지 정해주시면 그대로 반영하겠습니다.
Dependency · 의존 관계
일정이 밀릴 때 — 대부분의 원인이 여기 있습니다.
다른 작업이 끝나야 시작할 수 있는 관계입니다. "API가 나와야 화면을 붙인다" 같은 것입니다.
기획이 하루 밀리면 뒤의 모든 작업이 하루씩 밀립니다.
일정이 밀리는 대부분의 원인이 디펜던시입니다. "디자인 3일, 개발 5일"처럼 단순 합산하면 안 됩니다. 앞 단계가 하루 밀리면 뒤가 전부 밀립니다. 일정표에 선행 작업을 표시해두세요.
일정표에 선행 작업(디펜던시)을 표시해주세요. 기획 확정이 하루 밀리면 디자인·퍼블리싱·개발이 전부 하루씩 밀립니다. 단순 합산이 아니라 의존 관계로 계산해야 합니다.
Resource · 개발용 파일
"리소스 주세요" — 이미지 뽑아달라는 뜻입니다.
개발에 넘겨야 하는 이미지·아이콘·폰트 파일을 말합니다.
"리소스 주세요"는 이미지 뽑아서 달라는 뜻입니다. 피그마 링크만 주면 개발자가 직접 잘라내야 하고, 그 과정에서 크기나 여백이 달라집니다. SVG·@2x/@3x·투명 배경 여부를 정리해서 폴더로 전달하세요.
리소스를 폴더로 정리해서 전달드리겠습니다 — icon(SVG) / image(@1x·@2x·@3x PNG) / font(woff2). 파일명은 영문 소문자와 하이픈으로 통일하겠습니다.
Design Spec · 개발 가이드
"가이드 주세요" — 수치를 표기한 문서를 달라는 뜻.
여백·색상·크기 같은 수치를 표기해 개발에 전달하는 문서입니다.
요즘은 Figma에서 개발자가 직접 값을 볼 수 있어서 별도 가이드 문서를 안 만드는 경우도 많습니다. 다만 "이건 반응형에서 어떻게 되는지"처럼 툴에서 안 보이는 정보는 여전히 글로 적어야 합니다.
수치는 피그마에서 직접 확인하실 수 있게 정리해뒀습니다. 다만 툴에서 안 보이는 정보(반응형 동작·상태 변화·분기 조건)는 별도 문서로 정리해 드리겠습니다.
Web vs App Estimate
"앱도 만들어주세요" — 견적이 몇 배가 되는 순간.
같은 서비스라도 웹으로 만드는지 앱으로 만드는지에 따라 비용·일정·유지보수가 크게 달라집니다.
| 반응형 웹 | 네이티브 앱 | |
|---|---|---|
| 만드는 벌 수 | 1벌 | 2벌 (iOS·AOS) |
| 스토어 심사 | 없음 | 필요 (수정마다) |
| 수정 반영 | 즉시 | 심사 후 · 수일 |
| 푸시 알림 | 제한적 | 가능 |
네이티브 앱은 iOS·안드로이드 두 벌을 만들고 앱스토어 심사를 통과해야 하며, 수정할 때마다 다시 심사를 받습니다. 웹은 배포하면 바로 반영됩니다. "앱도 같이"는 사실상 프로젝트가 하나 더 생기는 것입니다.
앱까지 포함하면 iOS·안드로이드 두 벌 개발 + 스토어 심사·배포가 추가됩니다. 우선 반응형 웹으로 출시해 반응을 보고, 필요하면 앱으로 확장하는 순서를 제안드립니다.