앱 개발 중 고객이 준비해야 할 문구·이미지·운영 정책 8가지

임시 로고와 예시 상품으로 화면을 먼저 만들 수는 있습니다. 문제는 임시 자료가 최종 자료로 바뀌는 시점과 승인자를 정하지 않았을 때입니다. 화면이 거의 완성된 뒤 메뉴 이름이나 상품 구조가 바뀌면 앱뿐 아니라 관리자, 데이터와 테스트 순서까지 다시 손봐야 할 수 있습니다.

고객이 준비할 자료는 다음 여덟 묶음으로 나누면 빠진 항목을 찾기 쉽습니다.

자료표에는 `항목·담당자·초안 전달일·최종 승인일·현재 버전`을 함께 적으세요. 전달이 늦어지면 임시 자료로 개발을 계속할지, 해당 화면의 검수일을 바꿀지도 미리 정합니다.

전체 일정에서 기획·디자인·개발·검수의 역할은 데브크래프트 진행 방식에서 확인할 수 있습니다. 아직 계약 전이라면 이번 목록보다 어플제작업체 상담 전 준비 가이드에서 서비스 목표, 사용자, 예산과 일정을 먼저 정리하는 것이 맞습니다.

색상과 서체도 이름만 전달하기보다 실제 사용 기준을 적습니다.

유료 서체나 구매한 디자인 소스는 앱과 웹, 광고물에 사용할 수 있는 범위가 다를 수 있습니다. 구매 영수증만 보내기보다 라이선스 문서와 허용 범위를 확인하고, 개발업체가 원본을 보관하거나 수정해도 되는지도 구분합니다.

먼저 서비스 전체에서 반복되는 기본 표현을 정하세요.

문구표에는 화면 이름과 위치를 함께 적습니다. `확인 문구 수정`보다 `예약 신청 화면 / 하단 버튼 / 예약하기`처럼 기록해야 같은 단어가 있는 다른 화면과 혼동하지 않습니다.

초안과 승인된 문구도 구분합니다. 대표나 운영 담당자가 마지막으로 확인할 것인지, 마케팅·법무 담당자의 확인이 필요한지 정해 두면 개발업체가 여러 버전 중 하나를 추측해 적용하는 일을 줄일 수 있습니다.

다음 정보를 이미지 목록에 함께 적으세요.

인터넷 검색 결과나 다른 회사의 SNS에서 찾은 이미지를 출처만 적고 사용하는 방식은 피해야 합니다. 한국저작권위원회의 저작권 비즈니스 지원센터는 권리자 정보 확인과 이용허락 관련 서비스를 안내합니다. 프로젝트별 사용 가능 여부는 실제 권리자·계약 조건을 기준으로 확인해야 합니다.

앱과 웹에서 의미를 전달하는 이미지는 대체 문구도 준비하는 것이 좋습니다. W3C는 정보성 이미지에는 핵심 정보나 기능을 전달하는 대체 텍스트를 제공하고, 장식용 이미지는 빈 대체 텍스트로 보조기기가 건너뛸 수 있게 안내합니다. W3C 이미지 대체 텍스트 안내

실제 데이터는 가능한 한 표 형태로 준비하세요.

자료를 전달하기 전에 필수 열, 형식과 예시 한 줄을 개발업체와 먼저 맞추면 다시 정리하는 시간을 줄일 수 있습니다. 앱과 관리자에 직접 등록할지, 표를 일괄 반영할지도 정합니다.

테스트에는 실제 고객의 이름·전화번호·주소·결제 정보가 아닌 별도 테스트 데이터를 사용합니다. 실데이터가 꼭 필요한 연동 검수라면 대상, 접근 권한, 보관 위치와 삭제 시점을 먼저 정해야 합니다.

기업 고객의 주문부터 배송·정산까지 앱과 관리자에서 연결한 형태는 우리푸드 주문·배송 관리 사례에서 확인할 수 있습니다. 사례는 특정 프로젝트의 구조이며 모든 서비스에 같은 카테고리·상태를 적용한다는 뜻은 아닙니다.

예를 들어 예약 취소라면 다음 질문에 답이 필요합니다.

운영 정책은 문장만 작성하지 말고 상태 변화로도 확인하세요. `신청 → 승인 → 완료`, `주문 → 결제 → 준비 → 배송`, `접수 → 검토 → 반려`처럼 시작과 종료 상태를 적고 누가 다음 상태로 바꿀 수 있는지 정합니다.

아직 결정하지 못한 항목을 개발업체가 관행대로 채우게 두기보다 `임시 정책`이라고 표시하고 최종 확정일을 잡는 편이 안전합니다. 정책이 바뀌면 고객 화면뿐 아니라 관리자 버튼, 권한, 알림, 결제와 통계 기준이 함께 달라질 수 있습니다.

개발업체에는 기능별 데이터 목록을 요청할 수 있습니다.

고객은 이를 바탕으로 운영 주체와 실제 정책을 확인해야 합니다. 모든 개인정보 처리를 하나의 동의 체크박스로 묶는다고 해결되는 것은 아닙니다. 개인정보 처리의 근거, 동의가 필요한 사항, 필수·선택 구분과 거부 시 영향은 서비스별로 검토해야 합니다.

현재 개인정보 보호법 제22조는 동의를 받을 때 각각의 동의 사항을 구분해 명확히 알리고 동의를 받도록 하며, 선택적으로 동의할 수 있는 사항에 동의하지 않았다는 이유로 서비스 제공을 거부해서는 안 된다고 정합니다. 국가법령정보센터 개인정보 보호법과 개인정보보호위원회의 개인정보 처리방침 작성지침을 참고하되, 현재 서비스에 맞는 최종 문서는 필요한 경우 개인정보·법률 전문가에게 확인받으세요.

이 글은 특정 서비스의 적법성이나 심사 통과를 판단하지 않습니다. 정책 문서를 최종 확정한 날짜와 승인자를 기록하고 기능이 바뀔 때 함께 다시 확인하는 기준을 제공합니다.

최소한 다음 상황을 확인하세요.

오류 코드를 그대로 보여주기보다 고객이 이해할 수 있는 상황과 다음 행동을 안내합니다. `오류가 발생했습니다`에서 끝내지 말고 다시 시도할지, 입력을 고칠지, 고객센터에 문의할지 구분하세요. 운영자가 문의를 찾을 수 있도록 필요한 경우 접수번호나 발생 시각을 함께 보여주는 방식도 정합니다.

알림은 발송 시점, 대상, 제목, 본문, 눌렀을 때 이동할 화면과 중복 방지 기준을 한 묶음으로 작성합니다. 알림 전송 구조와 지연·중복을 확인하는 방법은 앱 푸시 알림 개발 가이드에서 이어서 볼 수 있습니다.

테스트 자료에는 다음 내용을 포함하세요.

테스트 계정의 비밀번호를 공개 문서나 공용 대화방에 적지 말고, 접근할 사람과 전달 경로를 제한합니다. 실제 고객 계정을 복제하기보다 허구의 정보로 만든 전용 데이터를 사용하고 검수 종료 뒤 유지·삭제 기준도 정하세요.

중간 검수 단계에서는 앱 개발 중간 검수 체크리스트를 이용해 사용자 행동이 관리자와 다음 상태에 연결되는지 확인할 수 있습니다.

권장 흐름은 단순합니다.

같은 파일을 덮어쓰거나 `최종`, `진짜최종`처럼 이름을 붙이기보다 변경일과 승인 상태를 기록합니다. 문구 변경은 파일만 다시 보내지 말고 화면, 기존 문구, 바꿀 문구와 적용 희망일을 함께 적습니다.