0801 프론트엔드 실무 심화 (14/N): 실무 적용 로드맵, 우선순위와 성과 정리 전략
✅ 1. 프론트엔드 실무 심화 마무리
- 지금까지 프론트엔드 실무 심화에서는 단순히 React 문법을 배우는 것이 아니라, 실제 운영 서비스에서 화면 품질을 높이는 기준을 정리했습니다.
- 고객 화면에서는 상담 신청 전환, 모바일 UX, 상품 상세 가독성, 로딩/에러 처리, 이미지 성능이 중요합니다.
- 관리자 화면에서는 검색/필터, 테이블, 권한, API 연동, 상태 변경, 배포 전 QA가 중요합니다.
- 결국 프론트엔드는 “예쁜 화면”이 아니라, 사용자가 원하는 행동을 빠르고 안전하게 완료하게 만드는 영역입니다.
상태 관리
↓
폼 검증
↓
로딩/에러/빈 상태
↓
관리자 테이블
↓
권한 기반 UI
↓
컴포넌트 설계
↓
반응형/접근성
↓
성능 최적화
↓
테스트/QA
↓
배포/모니터링
↓
API 계약
↓
아키텍처
↓
AI 자동화
➕ 1-1. 핵심 관점
고객 화면:
전환율, 신뢰감, 모바일 사용성
관리자 화면:
업무 속도, 정확성, 권한, 운영 안정성
개발자 관점:
유지보수성, 재사용성, 테스트 가능성, 배포 안정성
- 프론트엔드 실무는 이 세 가지를 동시에 봐야 합니다.
- 단순히 “화면이 나온다”에서 끝나면 운영 단계에서 계속 문제가 생깁니다.
✅ 2. 지금까지의 주제 요약
➕ 2-1. 0718 상태 관리와 서버 상태 관리
- 로컬 UI 상태, 전역 상태, 서버 상태, URL 상태, 폼 상태를 구분했습니다.
- 서버 상태는 TanStack Query로 관리하고, 검색 조건은 URL query string에 남기는 구조를 정리했습니다.
모달 열림:
로컬 상태
상담 목록:
서버 상태
검색어/page/status:
URL 상태
상담 신청 입력값:
폼 상태
관리자 권한:
전역 또는 me query
➕ 2-2. 0719 폼 처리와 유효성 검증
- react-hook-form, zod, useMutation을 연결해 상담 신청/관리자 저장 폼을 안정적으로 처리하는 기준을 정리했습니다.
- 프론트 검증은 UX, 백엔드 검증은 최종 방어선이라는 점이 핵심입니다.
프론트 검증:
입력 실수 즉시 안내
백엔드 검증:
보안과 데이터 정합성 보장
폼 제출:
useMutation + pending + success/error feedback
➕ 2-3. 0720 로딩, 에러, 빈 상태
- Loading, Empty, Error, Success 상태를 구분했습니다.
- 빈 화면과 에러 화면을 구분하고, 사용자가 다음에 무엇을 해야 하는지 알려주는 UX가 중요합니다.
Loading:
기다리는 중
Empty:
성공했지만 데이터 없음
Error:
요청 실패
Success:
데이터 표시
➕ 2-4. 0721 관리자 테이블
- 검색, 필터, 페이지네이션, 정렬, Empty 상태, 권한 액션, 엑셀 다운로드 기준을 정리했습니다.
- 관리자 테이블은 운영자가 가장 많이 보는 화면이므로 업무 속도와 정확성이 중요합니다.
검색 조건:
URL query string
목록 데이터:
TanStack Query
페이지네이션:
서버 기준
엑셀 다운로드:
현재 필터 조건 기준
➕ 2-5. 0722 권한 기반 UI
- 인증과 인가를 구분하고, role/permission 기반으로 메뉴, 페이지, 버튼, 데이터 표시를 제어하는 기준을 정리했습니다.
- 프론트 버튼 숨김은 UX이고, 실제 보안은 백엔드 Guard/API 권한 검사에서 처리해야 합니다.
프론트 권한:
메뉴/버튼/페이지 노출 제어
백엔드 권한:
실제 API 접근 차단
개인정보:
백엔드에서 권한별 마스킹
➕ 2-6. 0723 컴포넌트 설계와 디자인 시스템
- 공통 UI와 도메인 컴포넌트를 구분했습니다.
- Button, Input, Modal, Badge, EmptyState, ErrorState 같은 기본 UI를 정리하면 화면 품질이 안정됩니다.
components/ui:
순수 공통 UI
features/*/components:
도메인 컴포넌트
design token:
색상, 간격, radius, typography 기준
➕ 2-7. 0724 반응형과 접근성
- 모바일 상품 상세, Sticky CTA, 모바일 상담 신청 폼, 관리자 테이블 모바일 대응, semantic HTML, label, focus, aria 기준을 정리했습니다.
- 고객 화면은 모바일 전환율, 관리자 화면은 최소 업무 가능성이 중요합니다.
고객 모바일:
핵심 정보 + CTA 우선
관리자 모바일:
핵심 데이터 확인 가능
접근성:
semantic HTML + label + focus + error 연결
➕ 2-8. 0725 성능 최적화
- 이미지 최적화, 코드 스플리팅, React 렌더링 최적화, 테이블 성능, API 요청 최적화를 정리했습니다.
- 성능 최적화는 감으로 하지 말고 측정 후 병목부터 잡아야 합니다.
고객 화면:
이미지, LCP, CTA 반응성
관리자 화면:
테이블, API 응답, queryKey, pagination
최적화 순서:
측정 → 병목 확인 → 개선 → 재측정
➕ 2-9. 0727 테스트와 QA
- Vitest, React Testing Library, Playwright, 수동 QA 체크리스트를 정리했습니다.
- 1인 개발자는 모든 것을 자동화하기보다 핵심 흐름 중심으로 테스트와 체크리스트를 가져가는 것이 현실적입니다.
자동 테스트:
유틸, 권한 버튼, 폼 검증
수동 QA:
모바일, 모달, 실제 화면 흐름
배포 전:
lint + test + build + 핵심 QA
➕ 2-10. 0728 배포와 모니터링
- 환경변수, S3 + CloudFront, SPA 라우팅, 캐시, invalidation, ErrorBoundary, Chunk Load Error, 운영 이벤트를 정리했습니다.
- 프론트엔드 배포는 빌드 결과물을 올리는 것뿐 아니라 캐시와 운영 확인까지 포함합니다.
index.html:
짧은 캐시
hashed assets:
긴 캐시
CloudFront:
배포 후 invalidation
운영 확인:
Smoke Test + Error monitoring
➕ 2-11. 0729 API 연동과 계약 관리
- apiClient, domain api, request/response type, ApiError, queryKey, invalidate 기준을 정리했습니다.
- API 계약이 명확해야 프론트와 백엔드가 안정적으로 맞습니다.
apiClient:
공통 통신 기준
domain api:
기능별 API 함수
query hook:
TanStack Query 연결
API contract:
request/response/error/permission 문서화
➕ 2-12. 0730 아키텍처와 폴더 구조
- features 기반 구조, 공통 UI와 도메인 컴포넌트 분리, hooks/types/utils 위치 기준을 정리했습니다.
- AI IDE/Codex에게 작업을 맡기기 쉬운 구조가 유지보수에도 좋습니다.
features:
도메인별 기능 코드
components/ui:
순수 공통 UI
lib:
apiClient, queryClient
config:
env, routes, permissions
➕ 2-13. 0731 AI 자동화와 운영 기록
- git diff 리뷰, 커밋 메시지, QA 체크리스트, 작업 요약, 릴리즈 노트, Runbook 자동화 기준을 정리했습니다.
- AI는 초안과 리뷰를 맡기고, 사람은 승인과 배포를 담당하는 구조가 안전합니다.
AI:
초안, 리뷰, 요약, 체크리스트
사람:
검수, 승인, 배포, 운영 판단
기록:
커밋, 작업 로그, 릴리즈 노트, 장애 문서
✅ 3. 현재 프로젝트에 바로 적용할 우선순위
- 모든 내용을 한 번에 적용하려고 하면 부담이 큽니다.
- 지금 서비스 기준으로는 고객 상담 신청과 관리자 상담 처리 흐름부터 잡는 것이 가장 효과가 큽니다.
➕ 3-1. 1순위: 고객 상담 신청 흐름
상품 상세
상담 신청 CTA
상담 신청 모달
전화번호 입력 UX
폼 유효성 검증
중복 신청 처리
성공/실패 메시지
모바일 바텀시트 대응
- 고객이 신청을 못 하면 매출/리드에 직접 영향이 갑니다.
- 가장 먼저 안정화해야 할 화면입니다.
➕ 3-2. 2순위: 관리자 상담 목록/상태 변경
상담 목록 검색/필터
URL query string
페이지네이션
Empty/Error 상태
상담 상세 모달
상태 변경 mutation
상태 변경 후 목록 갱신
권한별 버튼 노출
- 운영자가 가장 자주 보는 화면입니다.
- 상담 데이터가 정확히 보이고, 상태 변경이 안전해야 합니다.
➕ 3-3. 3순위: 상품 상세/상품 관리
상품 이미지 최적화
상품명/요금/혜택 가독성
상품 상세 모바일 UX
관리자 상품 등록/수정 폼
상품 노출/비노출
상품 이미지 업로드
상품 수정 후 고객 화면 반영
- 상품 상세는 고객 전환에 중요하고, 상품 관리는 운영 효율에 중요합니다.
- 이미지 용량과 모바일 가독성은 꼭 봐야 합니다.
➕ 3-4. 4순위: 배포/QA/자동화
npm run verify
배포 전 체크리스트
CloudFront 캐시 확인
Smoke Test
git diff 리뷰
커밋 메시지 자동화
작업 요약 자동화
릴리즈 노트 템플릿
- 기능 개발만큼 배포 검증 체계도 중요합니다.
- 혼자 개발할수록 체크리스트가 실수를 막아줍니다.
✅ 4. 4주 적용 로드맵
- 프론트엔드 심화 내용을 실제 프로젝트에 반영한다면 4주 단위로 나눠 진행하는 것이 현실적입니다.
➕ 4-1. 1주차: 상담 신청/고객 모바일 UX 안정화
목표:
고객이 모바일에서 상담 신청을 안정적으로 완료할 수 있게 만들기
작업:
- 상품 상세 모바일 레이아웃 점검
- Sticky CTA 정리
- 상담 신청 모달 모바일 대응
- 전화번호 input type/inputMode 적용
- react-hook-form + zod 검증 확인
- 중복 신청 에러 처리
- 성공/실패 메시지 정리
- 상담 신청 QA 체크리스트 작성
➕ 4-2. 1주차 완료 기준
모바일에서 상담 신청 버튼이 잘 보임
전화번호 입력이 편함
필수값 누락 에러가 명확함
중복 신청 안내가 명확함
성공 시 완료 메시지가 나옴
제출 중 중복 클릭이 막힘
➕ 4-3. 2주차: 관리자 상담 목록/테이블 안정화
목표:
운영자가 상담 데이터를 빠르게 찾고 안전하게 처리할 수 있게 만들기
작업:
- 검색/필터 URL query string 연결
- queryKey에 page/status/source/keyword/date 포함
- EmptyState/ErrorState 적용
- 필터 초기화 버튼 추가
- 상태 변경 mutation 후 목록 invalidate
- 권한별 상태 변경 버튼 노출 제어
- 모바일 상담 카드형 또는 핵심 컬럼 점검
➕ 4-4. 2주차 완료 기준
검색 조건이 URL에 남음
새로고침 후 조건이 유지됨
필터 변경 시 page가 1로 초기화됨
상태 변경 후 목록이 갱신됨
VIEWER에게 수정 버튼이 보이지 않음
Empty/Error 상태가 구분됨
➕ 4-5. 3주차: 공통 UI/API 구조 정리
목표:
반복되는 UI와 API 연동 구조를 정리해 유지보수성을 높이기
작업:
- Button/Input/Modal/Badge 기준 정리
- EmptyState/ErrorState 공통화
- apiClient 구조 점검
- domain api 함수 분리
- request/response type 정리
- ApiError 정규화
- queryKeys 객체 정리
- 권한 util 위치 정리
➕ 4-6. 3주차 완료 기준
API 경로가 컴포넌트에 직접 흩어져 있지 않음
공통 UI 사용 기준이 있음
queryKey가 중복 문자열로 흩어져 있지 않음
권한 체크가 hasPermission 기준으로 통일됨
에러 처리가 code 기준으로 가능함
➕ 4-7. 4주차: 배포/QA/AI 자동화 체계 구축
목표:
배포 전 검증과 작업 기록을 표준화해 운영 안정성을 높이기
작업:
- npm run verify 구성
- 배포 전 QA 체크리스트 작성
- 고객/관리자 Smoke Test 정리
- git diff 리뷰 프롬프트 작성
- 커밋 메시지 프롬프트 작성
- 작업 요약 템플릿 작성
- 릴리즈 노트 템플릿 작성
- docs/frontend 구조 정리
➕ 4-8. 4주차 완료 기준
배포 전 실행할 명령어가 표준화됨
배포 후 확인할 Smoke Test가 있음
AI에게 diff 리뷰를 맡길 프롬프트가 있음
작업 요약이 Markdown/Notion으로 남음
프론트 구조 문서가 존재함
✅ 5. 실제 작업 순서 예시
- 하루 작업 단위로 보면 더 현실적으로 나눌 수 있습니다.
➕ 5-1. 상담 신청 개선 작업 예시
1. 현재 상담 신청 모달 코드 확인
2. form schema 확인
3. 전화번호 input UX 확인
4. createConsult mutation 확인
5. CONSULT_DUPLICATED 에러 처리 확인
6. 제출 중 버튼 disabled 확인
7. 모바일 모달 높이/스크롤 확인
8. 성공/실패 메시지 정리
9. npm run build
10. 모바일 실제 QA
11. 커밋
12. 작업 요약 작성
➕ 5-2. 관리자 상담 목록 개선 작업 예시
1. URL query 파싱 hook 확인
2. 검색 폼 submit 로직 확인
3. queryKey에 모든 조건 포함 여부 확인
4. EmptyState/ErrorState 적용 여부 확인
5. 필터 초기화 로직 확인
6. 상태 변경 mutation invalidate 확인
7. 권한별 버튼 노출 확인
8. 새로고침/뒤로가기 QA
9. npm run verify
10. 커밋
11. 릴리즈 노트 작성
- 작업 순서를 이렇게 쪼개면 AI에게 맡길 부분과 직접 확인할 부분이 명확해집니다.
- AI에게는 코드 초안과 diff 리뷰를 맡기고, 최종 QA는 직접 해야 합니다.
✅ 6. 성과로 표현할 수 있는 개선 항목
- 프론트엔드 개선은 단순히 “화면 수정”으로 쓰면 약해집니다.
- 운영 효과와 사용자 효과로 바꿔 표현해야 합니다.
➕ 6-1. 상담 신청 개선
약한 표현:
상담 신청 모달 수정
강한 표현:
모바일 상담 신청 모달의 입력 UX, 유효성 검증, 중복 신청 에러 처리, 제출 중 중복 클릭 방지를 개선해 고객 신청 흐름의 안정성을 높임
➕ 6-2. 관리자 테이블 개선
약한 표현:
관리자 상담 목록 수정
강한 표현:
관리자 상담 목록의 검색/필터 조건을 URL query string과 TanStack Query queryKey로 표준화해 새로고침/뒤로가기/검색 재현성을 개선하고 운영자의 데이터 탐색 효율을 높임
➕ 6-3. 권한 UI 개선
약한 표현:
버튼 권한 처리
강한 표현:
관리자 역할/권한에 따른 메뉴·버튼 노출 기준을 정리하고 VIEWER/마케터 계정의 민감 작업 접근을 제한해 운영 실수 가능성을 낮춤
➕ 6-4. 배포/QA 개선
약한 표현:
배포 전 테스트함
강한 표현:
프론트엔드 배포 전 lint/test/build와 고객·관리자 핵심 흐름 Smoke Test를 표준화해 배포 전 회귀 위험을 줄이는 검증 체계를 구축함
➕ 6-5. AI 자동화 개선
약한 표현:
AI로 작업 정리함
강한 표현:
git diff 기반 AI 리뷰, 커밋 메시지 추천, QA 체크리스트, 작업 요약 자동화 흐름을 구축해 1인 개발 환경에서 작업 기록과 배포 전 검증 효율을 개선함
✅ 7. 포트폴리오/경력기술서에 넣기 좋은 문장
➕ 7-1. 프론트엔드 운영 개선
React + TypeScript 기반 온라인 휴대폰 판매몰의 고객 화면과 관리자 화면을 운영하며, 상담 신청 UX, 관리자 상담 목록, 검색/필터, 권한 기반 UI, 배포 전 QA 체계를 개선했습니다.
➕ 7-2. 상태 관리/API 연동
TanStack Query를 활용해 상품·상담·관리자 목록의 서버 상태를 관리하고, URL query string 기반 검색/필터와 queryKey 구조를 정리해 데이터 조회 흐름의 일관성을 높였습니다.
➕ 7-3. 관리자 화면
관리자 상담 관리 화면에서 검색 조건 유지, 페이지네이션, 상태 변경 후 목록 갱신, Empty/Error 상태, 권한별 버튼 노출을 정리해 운영자가 상담 데이터를 더 빠르고 안전하게 처리할 수 있도록 개선했습니다.
➕ 7-4. 고객 화면
모바일 상품 상세와 상담 신청 모달의 CTA 배치, 입력 UX, 유효성 검증, 중복 신청 안내, 제출 중 중복 클릭 방지를 개선해 고객 신청 흐름의 안정성을 높였습니다.
➕ 7-5. 운영 자동화
프론트엔드 배포 전 lint/test/build 검증과 수동 QA 체크리스트, git diff 기반 AI 리뷰, 작업 요약 자동화 흐름을 정리해 1인 개발 환경의 운영 안정성과 기록 품질을 개선했습니다.
✅ 8. 연봉협상에서 말할 수 있는 포인트
- 개발회사가 아닌 일반 회사에서는 “기술적으로 뭐가 어려웠는지”보다 “운영에 어떤 효과가 있었는지”가 더 중요하게 먹힐 수 있습니다.
- 그래서 프론트엔드 개선도 운영 효과로 설명해야 합니다.
➕ 8-1. 대표에게 설명하기 쉬운 표현
고객이 모바일에서 상담 신청을 더 쉽게 할 수 있도록 신청 화면과 오류 안내를 정리했습니다.
관리자가 상담 데이터를 빠르게 찾고 처리할 수 있도록 검색, 필터, 상태 변경 화면을 개선했습니다.
권한별로 볼 수 있는 메뉴와 버튼을 나눠서 실수로 잘못 수정하거나 다운로드하는 위험을 줄였습니다.
배포 전 확인 절차를 정리해 기능 수정 후 기존 화면이 깨지는 문제를 줄일 수 있게 했습니다.
➕ 8-2. 개발자스럽게 설명하는 표현
서버 상태와 URL 상태를 분리하고, TanStack Query queryKey와 invalidate 기준을 정리해 관리자 목록 조회와 상태 변경 이후 데이터 동기화 흐름을 안정화했습니다.
react-hook-form과 zod 기반 폼 검증, API 에러 code 기반 분기, pending 상태 제어를 적용해 상담 신청과 관리자 저장 폼의 입력 안정성을 개선했습니다.
공통 Empty/Error/Loading 상태와 권한 기반 UI 조건을 정리해 고객/관리자 화면의 예외 상태 UX와 운영 보조 기능을 표준화했습니다.
- 협상 자리에서는 너무 깊은 기술 용어만 말하면 전달력이 떨어질 수 있습니다.
- “운영 효율, 실수 방지, 고객 신청 안정화”로 번역해서 말하는 것이 좋습니다.
✅ 9. 실무에서 계속 가져갈 기준
➕ 9-1. 새 화면 만들 때
1. 이 화면의 주 사용자는 누구인가?
2. 핵심 행동은 무엇인가?
3. 서버 상태는 무엇인가?
4. URL에 남겨야 할 상태는 무엇인가?
5. 폼 검증이 필요한가?
6. 로딩/에러/빈 상태가 있는가?
7. 권한 조건이 있는가?
8. 모바일에서 핵심 행동이 가능한가?
9. API 타입과 에러 처리가 명확한가?
10. 배포 전 QA 항목은 무엇인가?
➕ 9-2. 새 API 붙일 때
1. domain api 함수로 분리했는가?
2. request/response type이 있는가?
3. 에러 code 기준이 있는가?
4. queryKey가 적절한가?
5. mutation 후 invalidate 기준이 있는가?
6. 401/403/409 처리를 고려했는가?
7. 개인정보 마스킹 기준이 맞는가?
8. API 계약 문서가 있는가?
➕ 9-3. 새 관리자 기능 만들 때
1. 검색/필터가 필요한가?
2. URL 상태로 남길 조건은 무엇인가?
3. Empty/Error 상태는 어떻게 보일 것인가?
4. 권한별 버튼 노출은 어떻게 할 것인가?
5. 상태 변경이나 삭제에 Confirm이 필요한가?
6. 작업 이력이 남아야 하는가?
7. 엑셀 다운로드가 필요한가?
8. 대량 작업 위험은 없는가?
✅ 10. 다음 학습 방향
- 프론트엔드 실무 심화까지 정리했다면, 이제 다음은 3가지 방향으로 갈 수 있습니다.
➕ 10-1. 인프라/DevOps 운영 심화
주제:
Docker
Nginx
S3/CloudFront
GitHub Actions
Blue-Green/Rolling 배포
로그/모니터링
AWS 운영
비용 관리
백업/복구
- 배포와 운영까지 직접 맡는 1인 개발자에게 매우 중요합니다.
- 특히 현재 AWS 운영, S3/CloudFront, 백엔드 배포와 연결됩니다.
➕ 10-2. CS/시스템 설계 보강
주제:
HTTP
브라우저 렌더링
네트워크
DB 인덱스
트랜잭션
캐시
동시성
Queue
시스템 설계
- 실무 중 마주치는 문제를 더 깊게 이해하는 데 필요합니다.
- 면접/이직 준비에도 도움이 됩니다.
➕ 10-3. AI 기반 개발 자동화 실전
주제:
git diff 요약
커밋 메시지 자동화
일일 작업 리포트
Notion 업로드
트러블슈팅 문서 자동화
QA 체크리스트 생성
릴리즈 노트 자동화
로컬 LLM/Ollama 연동
- 이미 작업 중인 local-llm-work-report와 가장 직접적으로 이어집니다.
- 실무 성과와 기록 자동화를 동시에 만들 수 있습니다.
✅ 11. 추천 다음 시리즈
- 현재 흐름상 다음으로 가장 현실적인 시리즈는 인프라/DevOps 운영 심화입니다.
- 이유는 프론트/백엔드 실무를 정리했으니, 이제 실제 서비스를 안전하게 배포하고 운영하는 기준이 필요하기 때문입니다.
➕ 11-1. 추천 제목
0802 인프라/DevOps 운영 심화 (1/N): 로컬 개발환경, 배포환경과 운영환경 구분
➕ 11-2. 이어갈 주제 후보
0802:
로컬 개발환경, 배포환경과 운영환경 구분
0803:
Docker, OrbStack과 개발 DB 운영
0804:
Nginx, Reverse Proxy와 HTTPS 기본
0805:
S3 + CloudFront 정적 배포와 캐시 전략
0806:
GitHub Actions CI/CD 기본
0807:
환경변수, Secret 관리와 AWS SSM
0808:
로그, 모니터링과 장애 대응
0809:
백업, 복구와 롤백 전략
0810:
배포 체크리스트와 Runbook
0811:
1인 개발자 운영 자동화 로드맵
- 이 흐름은 현재 실무와 가장 잘 맞습니다.
- 특히 SSM, AWS, Mac 개발환경, 로컬/운영 분리, 배포 자동화와 연결할 수 있습니다.
✅ 12. 프론트엔드 실무 심화 최종 체크리스트
➕ 12-1. 고객 화면
- 모바일에서 핵심 CTA가 잘 보이는가?
- 상담 신청 폼이 짧고 명확한가?
- 전화번호 입력 UX가 좋은가?
- 제출 중 중복 클릭이 막히는가?
- 성공/실패 메시지가 고객 친화적인가?
- 상품 이미지가 빠르고 깨지지 않게 보이는가?
- 로딩/에러/빈 상태가 처리되어 있는가?
- 배너와 혜택 문구가 모바일에서 읽히는가?
➕ 12-2. 관리자 화면
- 검색/필터 조건이 URL에 남는가?
- queryKey에 모든 조건이 포함되어 있는가?
- 페이지네이션이 서버 기준으로 동작하는가?
- Empty/Error 상태가 구분되는가?
- 상태 변경 후 목록이 갱신되는가?
- 권한별 메뉴/버튼이 제어되는가?
- 엑셀 다운로드에 권한/Confirm/이력이 있는가?
- 모바일에서도 핵심 정보 확인이 가능한가?
➕ 12-3. 코드 구조
- API 호출이 domain api로 분리되어 있는가?
- request/response type이 정의되어 있는가?
- 공통 UI와 도메인 컴포넌트가 분리되어 있는가?
- features 구조가 정리되어 있는가?
- queryKeys가 공통 관리되는가?
- 권한 util이 한 곳에 있는가?
- 환경변수가 config/env.ts에서 관리되는가?
- utils/helper/common 파일이 난잡하지 않은가?
➕ 12-4. 운영/배포
npm run verify가 있는가?- 배포 전 QA 체크리스트가 있는가?
- 배포 후 Smoke Test가 있는가?
- CloudFront 캐시/invalidation 기준이 있는가?
- ErrorBoundary 또는 에러 모니터링이 있는가?
- 프론트 운영 로그에 개인정보가 남지 않는가?
- 릴리즈 노트가 남는가?
- 롤백 기준이 정리되어 있는가?
➕ 12-5. AI 자동화
- git diff 리뷰 프롬프트가 있는가?
- 커밋 메시지 프롬프트가 있는가?
- QA 체크리스트 생성 프롬프트가 있는가?
- 작업 요약 템플릿이 있는가?
- 릴리즈 노트 템플릿이 있는가?
- AI에게 Secret/개인정보를 넘기지 않는가?
- AI 결과를 git diff로 직접 확인하는가?
- 자동화 결과를 성과 기록으로 연결하는가?
✅ 13. AI를 활용해 프론트엔드 전체를 점검할 때 질문법
- 프론트엔드 전체 점검은 범위가 넓기 때문에 고객 화면, 관리자 화면, 코드 구조, 배포/QA, 자동화로 나눠 요청하는 것이 좋습니다.
➕ 13-1. 좋은 질문 예시
React + TypeScript + TanStack Query 기반 온라인 휴대폰 판매몰 프론트엔드 전체를 실무 기준으로 점검하고 싶어.
상황:
1. 고객 화면에는 상품 목록, 상품 상세, 상담 신청 모달, 사전예약 페이지가 있음
2. 관리자 화면에는 상담 목록, 검색/필터, 상태 변경, 상품 관리, 배너 관리, 엑셀 다운로드, 권한 UI가 있음
3. 상담 신청은 모바일 고객 전환에 중요함
4. 관리자 상담 목록은 운영자가 가장 자주 보는 화면임
5. 서버 상태는 TanStack Query, 폼은 react-hook-form + zod를 사용함
6. 검색 조건은 URL query string으로 유지하고 싶음
7. API는 domain api와 apiClient로 분리하려고 함
8. S3 + CloudFront로 배포하며 배포 전 QA 체크리스트가 필요함
9. AI IDE/Codex를 활용해 작업 자동화와 기록 자동화를 하고 싶음
요청:
- 고객 화면 UX 점검 기준
- 관리자 화면 UX 점검 기준
- 상태 관리/API 연동 점검 기준
- 컴포넌트/폴더 구조 점검 기준
- 권한/개인정보 처리 점검 기준
- 성능/반응형/접근성 점검 기준
- 테스트/QA/배포 체크리스트
- AI 자동화 도입 순서
- 4주 개선 로드맵
- 경력기술서에 쓸 수 있는 성과 문장
을 실무 기준으로 정리해줘.
➕ 13-2. AI 답변 검증 기준
- 고객 화면과 관리자 화면을 구분하는가?
- 상담 신청과 관리자 상담 목록을 우선순위로 보는가?
- 서버 상태/URL 상태/폼 상태를 구분하는가?
- queryKey, invalidate, ApiError 처리를 포함하는가?
- 권한과 개인정보 마스킹을 백엔드 기준으로 설명하는가?
- 모바일 UX와 접근성을 포함하는가?
- 배포 전 lint/test/build/QA를 포함하는가?
- 현재 1인 개발자 상황에 맞게 과하지 않은 로드맵을 제안하는가?
📌 요약
- 이번 프론트엔드 실무 심화 시리즈는 React 문법 자체보다 실제 운영 서비스에서 화면을 안정적으로 만들기 위한 기준을 정리한 흐름입니다.
- 고객 화면에서는 모바일 상품 상세, 상담 신청 CTA, 폼 검증, 성공/실패 메시지, 이미지 성능이 가장 중요합니다.
- 관리자 화면에서는 검색/필터, URL 상태, TanStack Query queryKey, 페이지네이션, Empty/Error 상태, 권한별 버튼, 상태 변경 후 갱신이 중요합니다.
- 코드 구조에서는 features 기반 폴더 구조, domain api, query hook, 공통 UI, 권한 util, queryKeys, config/env 분리가 핵심입니다.
- 배포와 운영에서는 lint/test/build, Smoke Test, CloudFront 캐시, ErrorBoundary, 운영 로그 개인정보 제거, 릴리즈 노트가 중요합니다.
- AI 자동화는 코드를 무검토로 맡기는 것이 아니라 git diff 리뷰, 커밋 메시지, QA 체크리스트, 작업 요약, 릴리즈 노트 초안을 만드는 데 먼저 활용하는 것이 안전합니다.
- 지금 프로젝트에서는 고객 상담 신청 흐름과 관리자 상담 목록/상태 변경 흐름을 최우선으로 안정화하는 것이 가장 효과가 큽니다.
- 성과 표현은 “화면 수정”이 아니라 “모바일 신청 안정화”, “운영자 검색/처리 효율 개선”, “권한 기반 실수 방지”, “배포 전 검증 체계 구축”처럼 운영 효과 중심으로 정리해야 합니다.
- 다음 흐름은 인프라/DevOps 운영 심화로 넘어가 로컬/운영 환경 구분, Docker/OrbStack, S3/CloudFront, GitHub Actions, SSM, 로그/모니터링, 롤백까지 정리하는 것이 가장 자연스럽습니다.
