0731 프론트엔드 실무 심화 (13/N): 작업 자동화, AI 활용과 운영 기록 체계
✅ 1. 프론트엔드 작업 자동화란 무엇인가?
- 프론트엔드 작업 자동화는 반복되는 개발, 검증, 문서화, 배포 전 확인, 작업 기록을 도구와 AI를 활용해 더 빠르고 안정적으로 처리하는 방식입니다.
- 단순히 AI에게 코드를 짜게 하는 것이 아니라, 작업 전 설계, 코드 수정, diff 리뷰, 테스트, QA 체크리스트, 커밋 메시지, 릴리즈 노트까지 연결하는 흐름입니다.
- 1인 개발자일수록 작업 기록과 검증 자동화가 중요합니다.
요구사항 정리
↓
AI 설계 초안
↓
코드 수정
↓
lint/test/build
↓
git diff 리뷰
↓
QA 체크리스트
↓
커밋 메시지
↓
작업 요약/릴리즈 노트
➕ 1-1. 자동화가 필요한 이유
- 반복되는 작업 시간을 줄일 수 있습니다.
- 배포 전 실수를 줄일 수 있습니다.
- 작업 내용을 Notion, Markdown, GitHub에 정리하기 쉬워집니다.
- 연봉협상/이직용 성과 정리에 활용할 수 있습니다.
- AI IDE/Codex에게 작업을 맡길 때 품질이 올라갑니다.
- 혼자 개발해도 팀처럼 기록과 검증 체계를 만들 수 있습니다.
수동 작업만 하는 경우:
작업 내용 기억에 의존
커밋 메시지 대충 작성
배포 전 QA 누락
장애 원인 추적 어려움
자동화가 있는 경우:
diff 기반 작업 요약
체크리스트 기반 QA
일관된 커밋 메시지
운영 기록 축적
✅ 2. 프론트엔드에서 자동화하기 좋은 작업
- 자동화는 모든 것을 맡기는 것이 아니라, 반복적이고 검증 가능한 작업부터 적용하는 것이 좋습니다.
| 작업 | 자동화 적합도 | 이유 |
|---|
| 커밋 메시지 초안 | 높음 | diff 기반으로 작성 가능 |
| 작업 요약 | 높음 | git log/diff 기반으로 정리 가능 |
| QA 체크리스트 생성 | 높음 | 변경 파일 기준으로 후보 추출 가능 |
| lint/test/build 실행 | 높음 | 명령어 기반 검증 |
| 릴리즈 노트 초안 | 높음 | 커밋/변경사항 기반 |
| UI 코드 생성 | 중간 | 검수 필요 |
| 디자인 수정 | 중간 | 실제 화면 확인 필요 |
| 운영 배포 자동 승인 | 낮음 | 위험도가 높음 |
| 권한/보안 로직 자동 반영 | 낮음 | 사람 검토 필수 |
➕ 2-1. 바로 도입하기 좋은 것
git diff 기반 코드 리뷰
커밋 메시지 추천
작업 요약 Markdown 생성
배포 전 체크리스트 생성
프론트 QA 항목 자동 추출
TIL 초안 생성
- 자동화는 “사람이 확인할 초안”을 만드는 데 먼저 쓰는 것이 안전합니다.
- 운영 배포나 보안 코드를 AI가 무검토로 실행하게 하면 안 됩니다.
✅ 3. AI에게 프론트엔드 작업을 맡길 때 기본 원칙
- AI에게 작업을 맡길 때는 범위, 파일 위치, 기존 패턴, 금지 사항을 명확히 줘야 합니다.
- “관리자 화면 수정해줘”처럼 넓게 지시하면 원치 않는 파일까지 바뀔 수 있습니다.
➕ 3-1. 좋은 지시의 조건
수정 범위가 명확함
관련 파일/feature를 알려줌
사용 중인 라이브러리를 알려줌
기존 패턴을 따르라고 함
건드리면 안 되는 파일을 알려줌
테스트/검증 기준을 알려줌
결과를 diff 기준으로 설명하게 함
➕ 3-2. 나쁜 지시
관리자 페이지 좋게 고쳐줘
상담 목록 좀 개선해줘
프론트 코드 리팩토링해줘
버그 없게 해줘
- 이런 지시는 너무 넓습니다.
- AI가 공통 컴포넌트, 스타일, API 구조를 마음대로 바꿀 수 있습니다.
➕ 3-3. 좋은 지시
features/admin-consults 내부에서만 상담 목록 Empty 상태를 개선해줘.
조건:
1. components/ui/EmptyState는 수정하지 마
2. 기존 useAdminConsults hook을 그대로 사용해
3. 검색 결과가 없을 때 필터 초기화 버튼을 보여줘
4. resetFilters는 URL query string을 /admin/consults?page=1&limit=20으로 초기화해
5. 로딩/에러 상태 기존 패턴은 유지해
6. 변경 후 수정한 파일과 QA 항목을 정리해줘
- 이 정도로 구체적이면 AI 결과물이 훨씬 안정적입니다.
✅ 4. AI 작업 전 컨텍스트 제공
- AI는 프로젝트 전체를 완벽히 모릅니다.
- 필요한 맥락을 주지 않으면 일반적인 답변이나 프로젝트와 안 맞는 코드를 만들 수 있습니다.
➕ 4-1. 제공하면 좋은 정보
프로젝트 스택:
React, TypeScript, Vite, TanStack Query, react-hook-form, zod
폴더 구조:
features, components/ui, lib, config
상태 관리 기준:
서버 상태는 TanStack Query
검색 조건은 URL query string
전역 UI는 Zustand 또는 Context
API 기준:
apiClient 사용
도메인별 api 함수 사용
queryKeys 객체 사용
UI 기준:
공통 Button/Modal/EmptyState/ErrorState 사용
권한 기준:
hasPermission 사용
실제 보안은 백엔드 Guard
➕ 4-2. 컨텍스트 템플릿
프로젝트 기준:
- React + TypeScript + Vite
- 서버 상태: TanStack Query
- 폼: react-hook-form + zod
- API 호출: lib/apiClient + features/*/api
- queryKey: queryKeys 객체 사용
- 공통 UI: components/ui
- 도메인 컴포넌트: features/*/components
- 검색/필터: URL query string
- 권한: hasPermission 유틸 사용
- 프론트 env: VITE_ 환경변수만 사용, Secret 금지
- 이런 템플릿을 AI 작업 시작 전에 붙이면 결과가 안정됩니다.
- 프로젝트 문서에 저장해두면 매번 반복하지 않아도 됩니다.
✅ 5. Git diff 기반 리뷰 자동화
- AI 자동화에서 가장 실용적인 것은
git diff 리뷰입니다.
- 변경된 코드를 기준으로 위험 요소, QA 항목, 커밋 메시지 후보를 뽑을 수 있습니다.
➕ 5-1. diff 리뷰에서 볼 것
공통 컴포넌트 변경 여부
API client 변경 여부
queryKey 변경 여부
권한 로직 변경 여부
환경변수 추가 여부
라우팅 변경 여부
전역 CSS 변경 여부
폼 검증 변경 여부
모바일 레이아웃 영향
개인정보 로그 노출 여부
➕ 5-2. AI diff 리뷰 프롬프트
아래 git diff를 프론트엔드 운영 배포 전 관점으로 리뷰해줘.
중점:
1. 고객 상담 신청 흐름에 영향이 있는지
2. 관리자 상담 목록/검색/상태 변경에 영향이 있는지
3. queryKey 또는 invalidate 누락 가능성이 있는지
4. 권한 없는 사용자에게 버튼이 노출될 가능성이 있는지
5. 모바일 화면이 깨질 수 있는 CSS 변경이 있는지
6. API Base URL 또는 환경변수 변경이 있는지
7. 개인정보가 console.log나 이벤트에 노출되는지
8. 배포 전 반드시 확인해야 할 QA 항목
답변:
- 위험도 높은 변경
- 확인할 화면
- 필요한 테스트 명령어
- 수동 QA 체크리스트
- 커밋 분리 제안
- diff 리뷰는 실제 코드 변경을 기반으로 하기 때문에 일반 조언보다 훨씬 유용합니다.
- 특히 AI IDE가 수정한 코드는 반드시 diff로 검토해야 합니다.
✅ 6. 커밋 메시지 자동화
- 커밋 메시지는 작업 기록의 가장 기본입니다.
- 좋은 커밋 메시지는 나중에 작업 요약, 릴리즈 노트, 연봉협상 자료로도 이어집니다.
➕ 6-1. 좋은 커밋 메시지 기준
무엇을 바꿨는지 드러남
왜 바꿨는지 필요하면 포함
너무 포괄적이지 않음
실제 diff와 일치함
기능/리팩토링/문서/수정이 섞이지 않음
➕ 6-2. 예시
feat: 상담 목록 Empty 상태에 필터 초기화 액션 추가
fix: 모바일 상담 신청 모달 하단 버튼 겹침 수정
refactor: 관리자 상담 API queryKey 관리 구조 분리
test: 권한별 상담 상태 변경 버튼 노출 테스트 추가
docs: 프론트엔드 배포 체크리스트 문서화
➕ 6-3. AI 커밋 메시지 프롬프트
아래 staged diff를 보고 커밋 메시지를 추천해줘.
조건:
1. Conventional Commits 형식
2. 한국어로 작성
3. 실제 변경 내용만 반영
4. 너무 넓은 표현 금지
5. 기능 변경과 리팩토링이 섞였으면 커밋 분리 제안
6. 제목 50자 안팎
7. 본문이 필요하면 bullet로 작성
출력:
- 추천 커밋 메시지
- 커밋 분리 필요 여부
- 배포 전 확인할 QA
- 커밋 메시지 자동화는 바로 적용해도 위험도가 낮습니다.
- 다만 AI가 과장해서 쓰지 않게 실제 diff 기준으로 검토해야 합니다.
✅ 7. 작업 요약 자동화
- 작업 요약은 하루 단위 또는 기능 단위로 작성하면 좋습니다.
- Git log와 diff를 기반으로 AI가 초안을 만들 수 있습니다.
➕ 7-1. 작업 요약에 들어갈 것
작업 목적
변경한 화면
변경한 기능
수정한 파일/모듈
API 영향
환경변수 영향
테스트/빌드 결과
QA 항목
운영 영향
남은 TODO
➕ 7-2. 프론트 작업 요약 예시
## 프론트엔드 작업 요약
### 작업 목적
관리자 상담 목록에서 검색 결과가 없을 때 운영자가 빠르게 필터를 초기화할 수 있도록 Empty 상태 UX를 개선했다.
### 주요 변경
- 상담 목록 EmptyState 메시지 개선
- 필터 초기화 버튼 추가
- URL query string 초기화 로직 추가
- 검색 조건 변경 시 page=1 유지 확인
### 영향 화면
- `/admin/consults`
### 검증
- `npm run lint`
- `npm run build`
- 상담 목록 검색/필터 수동 QA
### 배포 후 확인
- 검색 결과 없음 상태
- 필터 초기화 버튼
- 새로고침 후 검색 조건 유지
- 작업 요약은 Notion, Markdown, GitHub PR 설명에 모두 활용할 수 있습니다.
- 나중에 성과 정리할 때 큰 자산이 됩니다.
✅ 8. 릴리즈 노트 자동화
- 릴리즈 노트는 배포 단위로 무엇이 바뀌었는지 정리하는 문서입니다.
- 운영자가 확인해야 할 내용, QA 항목, 롤백 기준까지 포함하면 좋습니다.
➕ 8-1. 릴리즈 노트 구조
배포 일시
배포 버전/커밋
주요 변경사항
버그 수정
API/환경변수 영향
권한 영향
고객 화면 영향
관리자 화면 영향
QA 결과
롤백 기준
➕ 8-2. 예시
## Frontend Release Note - 2026-07-31
### 주요 변경
- 관리자 상담 목록 Empty 상태 UX 개선
- 필터 초기화 버튼 추가
- 상담 상태 변경 mutation 후 목록 갱신 기준 정리
### 영향 화면
- 관리자 상담 목록
- 상담 상세 모달
### API 영향
- 신규 API 없음
- 기존 상담 목록 API 사용
### 환경변수
- 변경 없음
### QA
- 상담 목록 검색/필터 확인
- Empty 상태 확인
- 상태 변경 후 목록 갱신 확인
- 모바일 상담 목록 핵심 정보 확인
### 롤백 기준
- 상담 목록 조회 실패
- 상태 변경 후 목록 갱신 오류
- 관리자 화면 진입 불가
- 릴리즈 노트가 있으면 배포 후 문제가 생겼을 때 원인 추적이 쉬워집니다.
- 작은 배포라도 핵심 변경은 남기는 습관이 좋습니다.
✅ 9. QA 체크리스트 자동 생성
- 변경 파일을 보면 어떤 화면을 확인해야 하는지 어느 정도 추론할 수 있습니다.
- AI에게 diff를 주고 QA 체크리스트를 생성하게 하면 배포 전 실수를 줄일 수 있습니다.
➕ 9-1. 파일별 QA 기준
features/consults:
고객 상담 신청 QA
features/admin-consults:
관리자 상담 목록/상세/상태 변경 QA
components/ui/Button:
모든 주요 버튼 회귀 QA
components/ui/Modal:
상담 신청 모달, 상태 변경 모달, 삭제 confirm QA
lib/apiClient:
로그인, API 에러, 401/403 처리 QA
config/env:
운영 환경변수, API Base URL QA
styles/globals.css:
고객/관리자 주요 화면 레이아웃 QA
➕ 9-2. AI QA 생성 프롬프트
아래 변경 파일 목록과 git diff를 보고 배포 전 수동 QA 체크리스트를 만들어줘.
조건:
1. 고객 화면과 관리자 화면을 구분
2. 변경 영향이 큰 화면부터 정리
3. 모바일 확인이 필요한 항목 표시
4. 권한 확인이 필요한 항목 표시
5. API/환경변수 확인 항목 표시
6. 체크박스 형태로 작성
7. 1인 개발자가 배포 전 실제로 확인할 수 있는 수준으로 작성
출력:
- 고위험 QA
- 일반 QA
- 모바일 QA
- 권한 QA
- 배포 후 Smoke Test
- 이 방식은 실제로 바로 써먹기 좋습니다.
- 특히 공통 컴포넌트 변경 시 회귀 QA 항목을 놓치지 않게 해줍니다.
✅ 10. 프론트엔드 작업 로그 구조
- 작업 로그는 나중에 성과 정리, 장애 분석, TIL 작성에 쓰입니다.
- 매일 완벽한 글을 쓰려고 하면 오래 못 갑니다.
- 대신 구조를 정해두고 자동 초안을 만들면 부담이 줄어듭니다.
➕ 10-1. 일일 작업 로그 템플릿
# 2026-07-31 프론트엔드 작업 로그
## 오늘 작업
-
## 변경 화면
-
## 주요 변경 파일
-
## 해결한 문제
-
## 검증
- [ ] npm run lint
- [ ] npm run test:run
- [ ] npm run build
- [ ] 수동 QA
## 운영 영향
-
## 남은 TODO
-
## 배운 점
-
➕ 10-2. Git 기반 자동 요약
오늘 커밋 목록
오늘 변경 파일
오늘 diff 요약
테스트 실행 결과
배포 여부
QA 결과
- 작업 로그는 길 필요가 없습니다.
- 핵심은 “무엇을 왜 바꿨고, 어떻게 검증했는지”입니다.
✅ 11. TIL 자동화
- 지금 작성 중인 TIL 시리즈처럼, 실무 경험을 학습 문서로 바꾸는 것도 자동화할 수 있습니다.
- 단순 업무 기록이 아니라 개념화하면 공부와 커리어 자료가 됩니다.
➕ 11-1. TIL 변환 흐름
작업 로그
↓
문제 상황 추출
↓
개념 정리
↓
실무 예시 추가
↓
체크리스트 작성
↓
AI 질문법 추가
↓
Markdown 문서화
➕ 11-2. 프론트 TIL 주제 후보
상담 신청 폼 검증 개선
관리자 검색 조건 URL 상태화
TanStack Query queryKey 정리
권한별 버튼 노출 제어
모바일 Sticky CTA 개선
Empty/ErrorState 공통화
S3 + CloudFront 배포 캐시 문제
API 에러 코드 기반 처리
- 실제로 겪은 작업을 TIL로 정리하면 추상적인 공부보다 훨씬 강합니다.
- 연봉협상 때도 “학습”이 아니라 “운영 개선 경험”으로 설명할 수 있습니다.
✅ 12. AI를 활용한 코드 생성
- AI는 컴포넌트, hook, API 함수, 테스트 초안 작성에 유용합니다.
- 하지만 프로젝트 패턴을 알려주지 않으면 새로운 스타일을 만들어버릴 수 있습니다.
➕ 12-1. AI에게 맡기기 좋은 코드
반복되는 CRUD API 함수
TanStack Query hook 초안
폼 zod schema 초안
컴포넌트 props 타입 초안
Empty/ErrorState 적용
테스트 케이스 초안
문서 템플릿
➕ 12-2. AI 결과 검수 기준
기존 폴더 구조를 따르는가?
기존 공통 UI를 사용하는가?
API client를 사용하는가?
queryKey 기준을 따르는가?
권한 util을 사용하는가?
any를 남발하지 않는가?
로딩/에러/빈 상태를 처리하는가?
테스트/QA 항목을 제시하는가?
- AI가 만든 코드는 반드시 직접 읽어야 합니다.
- 특히 권한, 개인정보, API 에러 처리, 배포 설정은 무조건 검토해야 합니다.
✅ 13. AI로 테스트 초안 만들기
- 테스트는 AI가 초안을 만들기 좋은 영역입니다.
- 개발자는 테스트 의도와 기대 결과가 맞는지 검수하면 됩니다.
➕ 13-1. 테스트 초안 요청 예시
아래 ConsultSearchForm 컴포넌트에 대한 React Testing Library 테스트 초안을 작성해줘.
검증할 것:
1. keyword 입력 후 검색 버튼을 누르면 onSubmit이 호출됨
2. status 필터 선택 값이 제출됨
3. 초기화 버튼을 누르면 onReset이 호출됨
4. 검색 버튼은 role 기준으로 찾기
5. 테스트는 사용자 관점으로 작성
6. 불필요한 implementation detail 테스트 금지
➕ 13-2. 검수 기준
실제 사용자 행동 기준인가?
CSS class에 의존하지 않는가?
테스트 이름이 의도를 설명하는가?
Mock이 과하지 않은가?
깨지기 쉬운 내부 구현을 테스트하지 않는가?
핵심 비즈니스 흐름을 검증하는가?
- AI는 테스트를 많이 만들어낼 수 있지만, 쓸모없는 테스트도 많이 만듭니다.
- “운영에서 깨지면 곤란한 흐름” 중심으로 유지해야 합니다.
✅ 14. AI로 문서화 자동화
- 프론트엔드 문서화는 반복적으로 미뤄지기 쉽습니다.
- AI를 활용하면 코드와 diff를 기반으로 문서 초안을 빠르게 만들 수 있습니다.
➕ 14-1. 문서화 대상
컴포넌트 사용법
API 연동 규칙
queryKey 규칙
권한 UI 기준
배포 절차
QA 체크리스트
환경변수 목록
장애 대응 Runbook
➕ 14-2. 문서화 요청 예시
아래 프론트엔드 폴더 구조와 주요 코드 일부를 보고 docs/frontend-architecture.md 초안을 작성해줘.
포함할 것:
1. 폴더별 역할
2. features 구조 기준
3. 공통 UI 위치 기준
4. API 연동 규칙
5. TanStack Query queryKey 규칙
6. 권한 UI 처리 기준
7. 환경변수 관리 기준
8. 새 기능 추가 시 파일 위치 기준
9. AI IDE 작업 시 주의사항
- 문서는 완성도가 낮아도 없는 것보다 낫습니다.
- 나중에 AI에게 작업을 맡길 때 문서가 컨텍스트 역할을 합니다.
✅ 15. 자동화 스크립트 구성
- 반복 명령어는 package.json scripts나 shell script로 묶으면 좋습니다.
- 검증 명령어가 표준화되면 실수가 줄어듭니다.
➕ 15-1. package.json 예시
{
"scripts": {
"dev": "vite",
"lint": "eslint .",
"test": "vitest",
"test:run": "vitest run",
"typecheck": "tsc --noEmit",
"build": "vite build",
"verify": "npm run lint && npm run test:run && npm run typecheck && npm run build"
}
}
➕ 15-2. 배포 전 검증
npm run verify
➕ 15-3. 장점
배포 전 명령어 통일
AI에게 실행 기준 전달 쉬움
GitHub Actions로 연결 쉬움
검증 누락 감소
verify 스크립트 하나를 만들어두면 배포 전 습관화하기 좋습니다.- CI에서도 같은 명령어를 쓰면 로컬과 배포 검증 기준이 맞습니다.
✅ 16. Git Hook 자동화
- Git Hook을 사용하면 커밋 전 lint/test를 자동 실행할 수 있습니다.
- Husky, lint-staged 같은 도구를 사용할 수 있습니다.
➕ 16-1. 적용 후보
커밋 전 lint
커밋 전 format
staged 파일만 검사
커밋 메시지 형식 검사
➕ 16-2. 주의할 점
너무 무거운 테스트를 pre-commit에 넣지 않기
커밋이 너무 느려지면 안 씀
build 전체는 pre-push나 CI로 분리
1인 개발자는 단순하게 시작
- 처음에는 lint-staged 정도만 해도 충분합니다.
- 커밋마다 전체 E2E를 돌리면 개발 흐름이 느려집니다.
✅ 17. GitHub Actions로 검증 자동화
- GitHub Actions를 사용하면 push 또는 PR 시 lint/test/build를 자동 실행할 수 있습니다.
- 배포 전 최소 안전망이 됩니다.
➕ 17-1. 기본 흐름
push 또는 pull request
↓
checkout
↓
node setup
↓
npm ci 또는 pnpm install
↓
lint
↓
test
↓
typecheck
↓
build
➕ 17-2. 장점
로컬에서 깜빡한 검증을 CI가 잡아줌
main branch 안정성 향상
AI 수정 코드 검증 가능
배포 자동화로 확장 가능
➕ 17-3. 주의할 점
환경변수 필요한 build는 CI env 설정 필요
Secret은 GitHub Secrets로 관리
운영 배포는 branch 제한 필요
실패 시 배포 중단
- 1인 개발자라도 CI는 큰 도움이 됩니다.
- 최소
lint + build만이라도 자동화하면 실수가 줄어듭니다.
✅ 18. 프론트엔드 운영 Runbook 자동화
- Runbook은 문제가 생겼을 때 따라 할 절차서입니다.
- 프론트엔드도 장애 대응 문서가 필요합니다.
➕ 18-1. Runbook이 필요한 상황
운영 화면 흰 화면
API 호출 실패
상담 신청 버튼 동작 안 함
관리자 로그인 실패
CloudFront 캐시 문제
Chunk Load Error
모바일 모달 깨짐
환경변수 누락
➕ 18-2. Runbook 템플릿
# 프론트엔드 장애 Runbook
## 증상
-
## 영향 범위
- 고객 화면 / 관리자 화면
- 영향 URL
- 영향 기능
## 즉시 확인
- 최근 배포 여부
- 브라우저 console error
- Network API 상태
- CloudFront/S3 배포 상태
- 환경변수/API Base URL
- 캐시/invalidation 여부
## 임시 대응
- 새로고침 안내
- 이전 버전 롤백
- CloudFront invalidation
- 문제 기능 숨김
- 고객 안내 문구 노출
## 원인
-
## 재발 방지
-
- 장애가 났을 때 처음부터 생각하려고 하면 늦습니다.
- 미리 확인 순서를 문서화해두면 대응 속도가 빨라집니다.
✅ 19. 운영 이벤트와 작업 기록 연결
- 프론트엔드 운영 개선은 이벤트와 작업 기록이 연결되면 더 강해집니다.
- 예를 들어 상담 신청 실패 이벤트가 증가하면 해당 날짜 배포와 비교할 수 있습니다.
➕ 19-1. 연결하면 좋은 데이터
배포 일시
배포 커밋
상담 신청 클릭 수
상담 신청 성공/실패 수
API 에러 수
관리자 상태 변경 실패 수
페이지 로딩 에러
Chunk Load Error 발생 수
➕ 19-2. 활용 예시
상담 신청 실패 증가
↓
최근 프론트 배포 확인
↓
상담 신청 폼 변경 diff 확인
↓
API 에러 code 확인
↓
문제 커밋 추적
↓
롤백 또는 hotfix
- 기록이 없으면 장애 원인 분석이 감에 의존하게 됩니다.
- 작은 서비스라도 배포 기록과 핵심 이벤트 정도는 남기는 것이 좋습니다.
✅ 20. AI 자동화에서 조심해야 할 것
- AI 자동화는 강력하지만, 무조건 맡기면 위험합니다.
- 특히 운영 데이터, 개인정보, 권한, 배포는 사람이 최종 승인해야 합니다.
➕ 20-1. AI에게 맡기면 위험한 것
운영 배포 자동 승인
운영 DB/고객 데이터 직접 수정
권한/인증 코드 무검토 반영
개인정보 포함 로그 분석 외부 전송
환경변수/Secret 파일 제공
알림톡/SMS 실제 발송 자동 테스트
대량 삭제/상태 변경 코드 자동 실행
➕ 20-2. 안전한 원칙
AI는 초안과 리뷰
사람은 승인과 배포
Secret은 제공하지 않음
개인정보는 마스킹
운영 영향 작업은 수동 확인
git diff는 반드시 확인
- 자동화의 목적은 판단을 없애는 것이 아니라, 판단할 자료를 빠르게 만드는 것입니다.
- 특히 1인 개발자는 사람이 마지막 방어선입니다.
✅ 21. AI 작업 결과 검증 루틴
- AI가 코드를 수정한 뒤에는 항상 같은 루틴으로 검증해야 합니다.
➕ 21-1. 기본 루틴
1. git diff 확인
2. 수정 파일 위치 확인
3. 공통 컴포넌트 영향 확인
4. API/queryKey/invalidate 확인
5. 권한/개인정보 영향 확인
6. npm run verify 실행
7. 핵심 수동 QA
8. 커밋 메시지 작성
9. 작업 요약 기록
➕ 21-2. 프론트 수동 QA 최소 세트
고객 상품 상세 접속
상담 신청 모달 열기
상담 신청 필수값 검증
관리자 로그인
상담 목록 조회
검색/필터 실행
상태 변경 모달 열기
권한 버튼 확인
- 변경이 작아도 핵심 흐름은 확인해야 합니다.
- 특히 상담 신청과 관리자 상담 처리는 우선순위가 높습니다.
✅ 22. 작업 자동화와 커리어 자료화
- 자동화 기록은 단순 편의 기능이 아니라 커리어 자산입니다.
- 작업 요약, 릴리즈 노트, 장애 기록, QA 체크리스트는 성과 설명에 바로 사용할 수 있습니다.
➕ 22-1. 성과 표현으로 바꾸기
그냥 한 일:
상담 목록 UI 수정
성과 표현:
관리자 상담 목록의 검색 결과 없음 상태와 필터 초기화 UX를 개선해 운영자가 조건 오류를 빠르게 복구할 수 있도록 개선
그냥 한 일:
배포 체크리스트 작성
성과 표현:
프론트엔드 배포 전 lint/test/build/QA 체크리스트를 표준화해 배포 실수와 회귀 위험을 줄이는 운영 검증 체계 구축
➕ 22-2. 연봉협상/이직에 쓰기 좋은 표현
프론트엔드 API 연동 구조를 domain api와 TanStack Query hook 기준으로 정리해 유지보수성을 개선
관리자 화면의 검색/필터/페이지네이션 상태를 URL query string과 queryKey로 표준화해 운영 재현성과 사용성을 개선
공통 Empty/Error/Loading 상태 컴포넌트를 정리해 고객/관리자 화면의 예외 상태 UX를 일관화
AI 기반 git diff 리뷰와 작업 요약 자동화를 도입해 1인 개발 환경의 작업 기록과 배포 전 검증 효율을 개선
- 작업을 기록하지 않으면 성과가 흩어집니다.
- 자동화는 실무 생산성과 커리어 정리를 동시에 돕습니다.
✅ 23. 1인 개발자용 프론트 자동화 로드맵
- 1인 개발자는 복잡한 자동화보다 바로 쓸 수 있는 작은 자동화부터 시작하는 것이 좋습니다.
➕ 23-1. 1단계: 검증 명령어 표준화
npm run lint
npm run test:run
npm run typecheck
npm run build
npm run verify
➕ 23-2. 2단계: AI 리뷰 도입
git diff 기반 리뷰
커밋 메시지 추천
QA 체크리스트 생성
작업 요약 생성
➕ 23-3. 3단계: 문서 자동화
일일 작업 로그
릴리즈 노트
TIL 초안
장애 Runbook
프론트 구조 문서
➕ 23-4. 4단계: CI 연결
GitHub Actions lint/build
test:run 추가
PR/Push 검증
배포 전 자동 체크
➕ 23-5. 5단계: 배포 자동화
S3 sync 스크립트
CloudFront invalidation
배포 후 Smoke Test 체크리스트
롤백 스크립트
- 처음부터 5단계를 다 하려고 하면 부담이 큽니다.
- 지금은 1~2단계만 해도 효과가 큽니다.
✅ 24. 자동화 문서 구조
- 자동화 관련 문서는 별도 폴더로 정리하면 좋습니다.
docs/
frontend/
architecture.md
api-integration.md
ui-components.md
permissions.md
qa-checklist.md
deploy.md
automation.md
daily/
2026-07-31.md
releases/
frontend-2026-07-31.md
troubleshooting/
frontend-chunk-load-error.md
frontend-api-base-url-error.md
➕ 24-1. automation.md에 넣을 것
AI 작업 원칙
프롬프트 템플릿
git diff 리뷰 기준
커밋 메시지 규칙
QA 체크리스트 생성 기준
작업 요약 템플릿
릴리즈 노트 템플릿
AI 금지 사항
검증 명령어
- 자동화 문서가 있으면 AI에게 “이 문서 기준으로 작업해”라고 지시할 수 있습니다.
- 결국 문서가 자동화 품질을 결정합니다.
✅ 25. 실무 체크리스트
➕ 25-1. AI 작업 체크리스트
- 작업 범위를 feature 단위로 제한했는가?
- 건드리면 안 되는 파일을 명시했는가?
- 기존 공통 UI와 queryKey 기준을 알려줬는가?
- 권한/개인정보 관련 주의사항을 명시했는가?
- AI 결과물을 git diff로 확인했는가?
- 불필요한 파일 생성이나 스타일 변경이 없는가?
any나 임시 코드가 남아 있지 않은가?- 테스트/QA 항목을 함께 받았는가?
➕ 25-2. 자동화 체크리스트
npm run verify 같은 통합 검증 명령어가 있는가?- 커밋 메시지 규칙이 있는가?
- git diff 리뷰 프롬프트가 준비되어 있는가?
- QA 체크리스트 생성 프롬프트가 있는가?
- 작업 요약 템플릿이 있는가?
- 릴리즈 노트 템플릿이 있는가?
- 배포 전/후 체크리스트가 문서화되어 있는가?
- 장애 Runbook 템플릿이 있는가?
➕ 25-3. 운영 기록 체크리스트
- 오늘 변경한 화면이 기록되어 있는가?
- 주요 변경 파일이 기록되어 있는가?
- 테스트/빌드 결과가 기록되어 있는가?
- 수동 QA 결과가 기록되어 있는가?
- 배포 여부와 배포 시간이 기록되어 있는가?
- 운영 영향과 롤백 기준이 기록되어 있는가?
- 남은 TODO가 정리되어 있는가?
- 성과로 표현 가능한 개선 내용이 정리되어 있는가?
✅ 26. AI를 활용해 프론트 자동화 체계를 설계할 때 질문법
- AI에게 자동화 체계를 설계시킬 때는 현재 개발 방식, 사용 도구, 반복 작업, 배포 방식, 기록 목적을 함께 알려줘야 합니다.
➕ 26-1. 좋은 질문 예시
React + TypeScript + TanStack Query 기반 온라인 휴대폰 판매몰 프론트엔드 작업 자동화 체계를 만들고 싶어.
상황:
1. 1인 개발자로 고객 화면과 관리자 화면을 모두 관리함
2. 고객 화면에는 상품 상세, 상담 신청, 사전예약 페이지가 있음
3. 관리자 화면에는 상담 목록, 검색/필터, 상태 변경, 엑셀 Export, 권한 UI가 있음
4. 배포 전 lint/test/build와 수동 QA가 필요함
5. S3 + CloudFront로 정적 배포함
6. AI IDE/Codex를 활용해 코드 수정과 리뷰를 하고 싶음
7. 작업 내용을 Markdown/Notion에 매일 정리하고 싶음
8. 커밋 메시지와 릴리즈 노트도 자동 초안을 만들고 싶음
9. 개인정보와 Secret은 AI에게 넘기지 않아야 함
요청:
- 자동화 가능한 작업과 사람이 승인해야 하는 작업 구분
- git diff 리뷰 프롬프트
- 커밋 메시지 프롬프트
- QA 체크리스트 생성 프롬프트
- 작업 요약 템플릿
- 릴리즈 노트 템플릿
- npm scripts verify 구성
- GitHub Actions 도입 순서
- AI 작업 안전수칙
- 1인 개발자 기준 단계별 로드맵
을 실무 기준으로 정리해줘.
➕ 26-2. AI 답변 검증 기준
- 운영 배포를 무검토 자동화하라고 하지 않는가?
- AI는 초안과 리뷰, 사람은 승인이라는 기준을 지키는가?
- 개인정보와 Secret을 AI에 넘기지 말라고 하는가?
- git diff 기반 리뷰와 QA 자동화를 우선 제안하는가?
- lint/test/build 검증 명령어를 포함하는가?
- 커밋 메시지와 작업 요약을 실제 diff 기반으로 작성하게 하는가?
- 1인 개발자 기준으로 과하지 않은 단계별 도입을 제안하는가?
- 커리어 자료화까지 연결할 수 있게 정리하는가?
📌 요약
- 프론트엔드 작업 자동화는 코드 작성뿐 아니라 설계, 검증, QA, 커밋, 릴리즈 노트, 작업 기록까지 반복 흐름을 표준화하는 작업입니다.
- AI는 코드를 무조건 대신 작성하는 도구가 아니라, diff 리뷰, 커밋 메시지, QA 체크리스트, 작업 요약, 문서화 초안을 빠르게 만드는 도구로 쓰는 것이 안전합니다.
- AI에게 작업을 맡길 때는 수정 범위, 관련 feature, 기존 패턴, 건드리면 안 되는 파일, 검증 기준을 명확히 줘야 합니다.
- git diff 기반 리뷰는 공통 컴포넌트 변경, API client 변경, queryKey 누락, 권한 로직 변경, 환경변수 변경, 개인정보 로그 노출을 점검하는 데 매우 유용합니다.
- 커밋 메시지와 작업 요약은 실제 diff를 기준으로 작성해야 하며, 과장 없이 무엇을 왜 바꿨는지 드러나야 합니다.
- QA 체크리스트는 변경 파일과 영향 화면을 기준으로 생성하면 배포 전 놓치는 항목을 줄일 수 있습니다.
npm run verify처럼 lint, test, typecheck, build를 묶은 명령어를 만들어두면 로컬 검증과 CI 연결이 쉬워집니다.- GitHub Actions는 처음에는 lint/build부터 시작하고, 이후 test, typecheck, 핵심 E2E, 배포 자동화로 확장하는 것이 현실적입니다.
- 자동화 과정에서 Secret, 개인정보, 운영 데이터, 권한/보안 로직, 운영 배포는 반드시 사람이 최종 검토해야 합니다.
- 작업 로그, 릴리즈 노트, 장애 Runbook, TIL 자동화는 실무 생산성뿐 아니라 연봉협상과 이직용 성과 자료로도 큰 자산이 됩니다.
