KT
대표 통합 프롬프트 · KT 참고 사례를 바탕으로 한 제품·UX·UI·프론트엔드·SEO/AEO·QA 통합 제작 명세
QUICK ANSWER
KT의 정보 구조를 참고해 사이트를 어떻게 만들 수 있나요?
이 페이지의 개발 프롬프트와 DESIGN.MD를 함께 사용하면 됩니다. 개발 프롬프트는 연결 상태와 요금제 관리에 필요한 기능·정보 구조·상태·SEO를 정의하고, DESIGN.MD는 화면 구조·토큰·컴포넌트·반응형·접근성 기준을 고정합니다.
사이트 개발 기준
요금제·사용량·기기의 관계와 상태, 주요 사용자 흐름, 오류 복구와 완료 조건을 구현 가능한 명세로 제공합니다.
사이트 디자인 기준
비교 선택 흐름 · 기능적이고 빠른 · 정보 밀도 보통 · 사용량/조건 → 플랜 카드 비교 → 제한·가격 → 가입/상담을 출발점으로 삼되 로고, 고유 문구, 이미지와 픽셀 레이아웃은 복제하지 않습니다.
반드시 점검할 위험
통신 범위·청구 명확성·서비스 장애을 핵심 설계 리스크로 다루고 loading, empty, error, partial-data, success 상태를 모두 정의합니다.
바로 사용하는 순서
- 개발 프롬프트에서 사용자, 핵심 기능과 기술 스택을 프로젝트에 맞게 바꿉니다.
- DESIGN.MD를 AI 빌더나 코드 에이전트의 디자인 기준 문서로 전달합니다.
- 360px, 768px, 1280px 화면과 키보드 탐색, 오류 상태를 완료 체크리스트로 검수합니다.
REFERENCE & BLUEPRINT
실사이트와 설계 미리보기

실사이트 이미지는 두 캡처 공급자를 동시에 확인해 빠른 응답을 사용합니다. 지역·로그인·사이트 정책으로 캡처가 불가능하면 브랜드 색상과 대표 화면 구조로 만든 대체 이미지를 자동 표시합니다.
COPY-READY PROMPT
프롬프트 MD 미리보기
KT
대표 통합 제작 프롬프트 · 통신 · 결과물: 제품 기획부터 UX·UI·프론트엔드·SEO/AEO·QA까지 연결된 제작 명세
이 프롬프트가 필요한 순간
KT처럼 연결 상태와 요금제 관리 목표가 중요한 서비스를 기획·디자인·개발할 때 사용한다. 공개된 KT의 서비스 구조를 참고하되 로고, 문구, 고유 자산이나 화면을 복제하지 않고 자신의 제품 문제에 맞게 재해석한다.
- 참고 서비스: KT
- 핵심 객체: 요금제·사용량·기기
- 핵심 위험: 통신 범위·청구 명확성·서비스 장애
- 프롬프트 분야: 통합
- 기대 결과물: 제품 기획부터 UX·UI·프론트엔드·SEO/AEO·QA까지 연결된 제작 명세
공개 인터페이스 디자인 분석
- 분석 기준: 공개 첫 화면과 대표 작업 흐름에서 반복되는 시각·구조 패턴이다. 서비스 업데이트에 따라 달라질 수 있으므로 실사이트 캡처로 최종 확인한다.
- 화면 원형: 비교 선택 흐름
- 톤 & 매너: 기능적이고 빠른
- 정보 밀도: 보통
- 색채 전략: 중립 표면 위 절제된 브랜드 포인트 (#E2231A)
- 탐색 구조: 가벼운 상단 탐색
- 구조 순서: 사용량/조건 → 플랜 카드 비교 → 제한·가격 → 가입/상담
- 재사용할 패턴: 사용량 요약 · 보장 카드 · 플랜 카드 · 기기 카드 · 지원 진입
- 독립 적용 규칙: 순서와 판단 원칙만 참고하고, 로고·카피·이미지·아이콘·고유 화면 배치는 복제하지 않는다.
먼저 바꿀 입력값
만들_서비스: "[내 서비스 이름]"
타깃_사용자: "[핵심 사용자와 상황]"
핵심_문제: "[사용자가 해결하려는 문제]"
핵심_기능: "[반드시 포함할 3~5개 기능]"
비즈니스_목표: "[전환·활성·유지 등]"
기술_스택: "[예: Next.js + Tailwind CSS]"
브랜드_톤: "[예: 명확하고 차분함]"복사해서 쓰는 프롬프트
너는 시니어 제품 디자이너, UX 전략가, 프론트엔드 아키텍트다.
[내 서비스 이름]을 위한 대표 통합 제작 프롬프트를 작성하고 필요한 경우 구현 코드까지 만들어줘.
참고 서비스는 KT(https://www.kt.com)이며, 참고할 점은 연결 상태와 요금제 관리 목표를 다루는 정보 구조와 사용자의 결정 흐름이다.
KT의 로고, 고유 문구, 이미지, 저작물, 픽셀 단위 레이아웃은 복제하지 말고 독립적인 제품 언어로 재해석해.
프로젝트 조건:
- 타깃 사용자: [핵심 사용자와 상황]
- 해결할 문제: [사용자가 해결하려는 문제]
- 핵심 기능: [반드시 포함할 3~5개 기능]
- 비즈니스 목표: [전환·활성·유지 등]
- 기술 스택: [예: Next.js + Tailwind CSS]
- 브랜드 톤: [예: 명확하고 차분함]
이번 작업 지시:
사용자 문제와 성공 지표, 정보 구조, 핵심 흐름, 반응형 UI, 디자인 토큰, 컴포넌트 상태, UX 라이팅, 접근성, 프론트엔드 구현, SEO/AEO, 성능과 출시 QA를 하나의 일관된 결과물로 설계해.
반드시 포함할 기준:
1. 요금제·사용량·기기의 상태와 관계가 한눈에 이해되어야 한다.
2. 통신 범위·청구 명확성·서비스 장애에 관한 예방·설명·복구 경로가 있어야 한다.
3. 정상뿐 아니라 loading, empty, error, success, disabled, partial-data 상태를 정의한다.
4. 360px, 768px, 1280px에서 콘텐츠 우선순위와 탐색 방식이 유지되어야 한다.
5. 시맨틱 HTML, 키보드 탐색, focus-visible, 44px 터치 타깃, WCAG AA 대비를 지킨다.
6. 추상적인 조언으로 끝내지 말고 화면 구조, 컴포넌트, 상태, 문구와 완료 조건을 구체적으로 제시한다.
7. 페이지별 고유 title·meta description·canonical, 시맨틱 제목 계층, 내부 링크와 크롤링 가능한 서비스 URL을 설계한다.
8. 핵심 질문에는 첫 문장부터 직접 답하고, 화면에 실제 보이는 Q&A와 WebSite·WebPage·CreativeWork JSON-LD가 내용과 일치하게 한다.
출력 순서:
- 목표와 가정
- 사용자 흐름 또는 정보 구조
- 화면/컴포넌트 명세
- 상태와 예외 처리
- 반응형·접근성 규칙
- SEO·AEO 콘텐츠와 구조화 데이터 계획
- 필요한 경우 구현 예시
- 검증 가능한 완료 체크리스트빠른 디자인 토큰 출발점
:root {
--color-primary: #E2231A;
--color-ink: #17201D;
--color-canvas: #F6F8F7;
--color-surface: #FFFFFF;
--color-tint: #E2231A22;
--color-danger: #DC2626;
--radius-card: 12px;
--space-1: 4px; --space-2: 8px; --space-3: 12px;
--space-4: 16px; --space-6: 24px; --space-8: 32px;
}목업은 비교 선택 흐름 · 기능적이고 빠른 · 정보 밀도 보통 · 사용량/조건 → 플랜 카드 비교 → 제한·가격 → 가입/상담 · #E2231A 기반의 KT 브랜드 인상과 위 공개 인터페이스 분석을 참고한 구조적 출발점이다. 공개 사이트의 로고·문구·이미지·고유 화면을 복제하지 않으면서도, 색채 역할, 정보 밀도, 탐색 구조와 반복 패턴을 반영해 실제 서비스 계열의 정보 위계를 빠르게 이해할 수 있게 한다.
기대 산출물
- 제품 기획부터 UX·UI·프론트엔드·SEO/AEO·QA까지 연결된 제작 명세
- 핵심 사용자 시나리오와 성공 기준
- 컴포넌트별 데이터·상태·행동 명세
- 모바일/태블릿/데스크톱 적응 규칙
- 오류 예방, 복구, 접근성 요구사항
- 개발자가 그대로 검수할 수 있는 acceptance criteria
이어서 쓰는 개선 프롬프트
첫 결과를 받은 뒤 아래 문장을 한 번씩 이어서 사용하면 추상적인 제안을 구현 가능한 수준으로 좁힐 수 있다.
- 상태 구체화 — "방금 만든 제품 기획부터 UX·UI·프론트엔드·SEO/AEO·QA까지 연결된 제작 명세에서 가장 중요한 흐름 하나를 골라 정상, 로딩, 빈 데이터, 부분 데이터, 입력 오류, 서버 오류, 권한 없음, 성공 상태를 동일한 데이터 스키마와 컴포넌트 단위로 구체화해줘."
- 프로토타입 전환 — "제안 내용을 시맨틱 HTML과 재사용 가능한 컴포넌트로 구현해줘. 360px·768px·1280px 반응형, 키보드 포커스 순서, 실제 길이의 한국어 샘플 데이터를 포함해줘."
- 비판적 검토 — "통신 범위·청구 명확성·서비스 장애 관점에서 이 결과의 실패 가능성을 심각도 순으로 찾아줘. 각 문제에 관찰 가능한 근거, 수정안, 검증 방법, 완료 조건을 붙여줘."
- 독창성 점검 — "참고 서비스 KT의 정보 구조만 남기고, 브랜드 색·고유 문구·자산·화면 배치를 닮은 부분을 찾아 독립적인 제품 언어로 다시 설계해줘."
- 개발 핸드오프 — "통합 결과를 개발 티켓으로 분해해줘. 각 티켓에 목적, 데이터 요구사항, 컴포넌트 API, edge case, 접근성 기준, 테스트 시나리오를 작성해줘."
검수 체크리스트
- ☐ 참고 사례는 KT의 정보 구조로 한정된다.
- ☐ 내 서비스의 사용자·문제·기능 입력값이 실제 내용에 반영됐다.
- ☐ 요금제·사용량·기기의 우선순위와 상태 변화가 명확하다.
- ☐ 통신 범위·청구 명확성·서비스 장애에 관한 신뢰 정보와 복구 경로가 있다.
- ☐ 빈 상태·오류·지연·권한 부족·부분 데이터가 빠지지 않았다.
- ☐ 키보드·스크린리더·200% 확대·모션 감소를 검증할 수 있다.
- ☐ 특정 브랜드 자산을 복제하지 않고 독립적인 디자인으로 완성됐다.