Add test automation script scaffolds

2026-07-02 13:26:19 +09:00
parent 0a427da636
commit fd9e3ae1a6
14 changed files with 625 additions and 11 deletions
@@ -0,0 +1,12 @@
+# 레퍼런스: AI 기반 테스트 정책 (참고용)
+
+이 폴더의 문서는 참고용 레퍼런스입니다. 이 폴더에 있는 파일은 실개발(프로덕션) 환경에 자동으로 반영되거나 메인 브랜치에 병합되어 적용되지 않습니다.
+
+사용 안내:
+- 본 문서들은 초안 또는 정책 검토용 참고 자료입니다.
+- 실제 정책으로 채택하려면 검토(정책팀/보안팀), 승인(Human-in-the-loop) 및 관련 테스트 파이프라인 통합 절차를 반드시 완료해야 합니다.
+- 임시 파일이나 실험적 스크립트가 포함될 수 있으며, 자동화 파이프라인에 포함하지 마십시오.
+
+경로: `docs/references/ai-testing/`
+
+작성일: 2026-07-02
@@ -0,0 +1,93 @@
+# [POLICY] AI 기반 시스템 개발 및 테스트 자동화 통합 규약 (Comprehensive AI Testing Policy)
+
+* **문서 유형:** 개발 정책 및 CLI 참조 규약 (System Policy & Convention)
+* **적용 대상:** AI 파이프라인 소스코드, 모델 추론 레이어, LLM 기반 에이전트 워크플로우
+* **참조 경로:** `docs/references/ai-testing/ai_testing_policy_draft.md`
+* **최종 수정:** 2026. 07. 02
+
+---
+
+## 1. 목적 및 기본 준수 사항 (General Principles)
+
+1. **확률적 출력 관리:** AI 모델의 출력은 결정론적이지 않고 확률에 기반하므로, 모든 테스트 스크립트는 단순 문자열 매칭을 지양하고 구조적 스키마 검증 및 AI 기반 자가 평가 방식을 채택한다.
+2. **CLI 강제성:** 본 문서에 정의된 정책 수치(커버리지, 성능 메트릭 등)를 만족하지 못하는 코드는 빌드(Build) 및 Main 브랜치로의 병합(Merge)을 전면 차단한다.
+3. **통합 검증 체계:** 기존 소프트웨어의 베이스라인 테스트, AI 특화 기능 테스트, 엔진 교차 검증, 3대 레드팀 적대적 공격 테스트를 하나의 파이프라인 안에서 유기적으로 수행한다.
+
+---
+
+## 2. 소스코드 및 베이스라인 규약 (Code & Baseline Convention)
+
+### 2.1 정적 분석 및 코드 체크
+* 모든 PR(Pull Request) 및 커밋 시점에 CLI 기반의 정적 분석(Linting) 및 타입 검사(Type Checking)를 의무적으로 통과해야 한다.
+* AI 학습 파이프라인이나 데이터 전처리 스크립트 내의 문법 오류로 인한 자원 낭비를 방지하기 위해 빌드 프로세스 최우선 단계에서 정적 분석을 수행한다.
+
+### 2.2 유닛 테스트 강도 정책 (Unit Test Intensity)
+AI 시스템의 컴포넌트는 성격에 따라 유닛 테스트의 합격 기준 및 강도를 이원화하여 적용한다.
+
+* **결정론적 로직 영역 (High Intensity - 강도 높음):**
+  * **대상:** 데이터 전처리, 전처리 가드레일 필터, API 라우팅, 데이터 변환 래퍼
+  * **기준:** 테스트 통과율(Pass-rate) **100% 필수**이며 엄격하게 검증한다.
+* **확률론적 로직 영역 (Structural Validation - 구조적 검증):**
+  * **대상:** AI 모델 추론(Inference) 함수 결과값, 프롬프트 템플릿 컴포저 출력
+  * **기준:** 텍스트의 완전 일치 대신 다음 구조적 조건을 만족해야 함.
+    * 출력 데이터의 JSON 스키마/키값 유효성 검증
+    * 임베딩 벡터 차원(Shape)의 일치 여부 검증
+    * 모델 출력 확률 값의 범위 검증 ($0 \\le p \\le 1$)
+
+### 2.3 커버리지 테스트 기준 (Test Coverage)
+* **소스코드 라인 커버리지:** 일반 비즈니스 로직 및 데이터 전처리 코드는 최소 **80% 이상**의 라인 커버리지를 유지한다.
+* **시나리오 커버리지 (데이터셋 커버리지):** 단순히 코드 라인이 실행되었는가를 넘어, 사전에 준비된 사용자 의도(Intent) 데이터셋 및 극단적 엣지 케이스 시나리오 리스트의 최소 **90% 이상**을 테스트 스위트가 직접 경험하고 통과해야 한다.
+
+---
+
+## 3. 기능(Functional) 및 자율형 E2E 스냅샷 평가 규약 (E2E Snapshot Loop)
+
+### 3.1 기능 테스트 (Functional Testing)
+* AI 시스템이 기획한 대로 제 기능을 수행하는지 비즈니스 요구사항 부합 여부를 검증한다. (예: 인사를 하면 인사를 받는지, 이미지 분류기가 카테고리를 올바르게 반환하는지 등)
+
+### 3.2 스냅샷 저장 및 자율형 교정 루프 (Autonomous Correction Loop)
+생성형 AI 워크플로우의 엔드투엔드(E2E) 테스트 시, CLI는 사용자가 화면에서 요청하는 순간부터 AI를 거쳐 최종 화면이 뜰 때까지의 전체 과정을 통째로 테스트하되, 평가용 상위 AI(Evaluator LLM)를 활용한 자동 재시도 루프 정책을 적용한다.
+
+1. **스냅샷 생성:** 타겟 AI 엔진이 출력한 최종 결과(텍스트, 이미지 등)를 `tests/snapshots/` 디렉토리에 버전별 스냅샷으로 저장한다.
+2. **평가용 AI 검증:** 별도의 검증용 AI(또는 상위 모델)가 사전에 정의된 평가 루브릭을 기준으로 스냅샷의 답변이 올바른지 자가 검증한다.
+3. **FAIL 처리 및 반복(Loop):** 평가 기준 미달 시, CLI는 프롬프트나 파라미터를 수정하여 올바른 결과가 나올 때까지 **최대 $N$회(기본값: 3회)** 자동으로 반복 수행한다.
+4. **최종 판정:** 최대 반복 후에도 FAIL인 경우, 해당 빌드는 실패로 처리되며 인간 개발자의 검토(Human-in-the-loop) 단계로 이관된다.
+
+---
+
+## 4. 멀티 AI 엔진 교차 검증 정책 (Multi-Engine Switch Policy)
+
+특정 AI 파트너사의 모델에 대한 독점적 종속성(Lock-in)을 방지하고 시스템 마비 시 대체 가능성을 확보하기 위해, 모든 비즈니스 추론 기능은 다음 3가지 범주의 AI 엔진 종류별로 매트릭스 교차 테스트를 수행한다.
+
+1. **상용 폐쇄형 엔진 (Commercial Closed-Source):** (예: GPT-4o, Claude 3.5 Sonnet) 최고 수준의 추론 성능 및 기본적인 방어 가드레일 한계선을 측정하는 기준으로 삼는다.
+2. **오픈소스형 엔진 (Open-Source Local/Self-Hosted):** (예: Llama 3, Mistral) 데이터 보안 준수 환경 및 비용 최적화 라우팅 환경 하에서 가드레일이 무너지지 않는지 검증한다.
+3. **도메인 특화 미세조정 엔진 (Internal Fine-Tuned):** 사내 자체 데이터로 학습된 전용 모델을 테스트하여 특정 도메인 내에서의 성능을 점검하고 환각 지표(Hallucination Index)를 모니터링한다.
+
+---
+
+## 5. 3대 프로필 레드팀 공격 규약 (Red Teaming Matrix Policy)
+
+CLI 자동화 적대적 테스트셋은 AI 엔진의 보안 및 안정성을 허물기 위해 서로 다른 성향을 가진 다음 세 가지 공격 프로필을 무조건 포함하여 교차 검증을 실행해야 한다.
+
+| 공격 프로필 분류 | 집중 검증 영역 | 공격 벡터 예시 | 방어 및 검증 체크포인트 |
+| :--- | :--- | :--- | :--- |
+| **1. 기술형 레드팀<br>(Jailbreaker)** | 시스템 프롬프트 우회 및 가드레일 무력화 | 가상화 레이어 명령 주입, Base64/입력 인코딩 우회, DAN(무제한 모드) 페르소나 주입 공격 | 우회 불가능한 시스템 역할 가드레일(System Role Guardrail) 작동 여부 |
+| **2. 심리형 레드팀<br>(Social Engineer)** | 문맥 조작 및 감정적 우회 | 동정심 유발 시나리오(예: 할머니 동화책 이야기), 소설/역할극 빙자 유해 질문, 인지적 착시 유도 | 의미론적 경계 필터(Semantic Boundary Filters) 작동 및 윤리 정렬 점수 검증 |
+| **3. 악성 데이터형 레드팀<br>(Poisoner)** | 시스템 견고성 및 오작동 유도 | 버퍼 오버플로우 유도용 초장문 텍스트 입력, 노이즈가 섞인 적대적(Adversarial) 데이터 주입 | 입력값 정제 레이어(Sanitization) 가동 및 안전한 에러 핸들링(Fallback) 여부 |
+
+---
+
+## 6. 품질 점수 및 데이터 모니터링 메트릭 (Metrics & Monitoring)
+
+최종 배포 승인을 획득하기 위해 CLI는 테스트 완료 시점마다 아래 메트릭 계산식을 기반으로 한 결과 리포트를 의무적으로 생성해야 한다.
+
+### 6.1 모델 수학적 성능 메트릭
+새로운 변경 사항이나 프롬프트가 적용된 AI 엔진은 검증 데이터셋에서 다음 메트릭의 최소 기준치(Baseline: 예: 0.85)를 초과해야 한다.
+
+$$\text{Precision (정밀도)} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Positives}}$$
+
+$$\text{Recall (재현율)} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Negatives}}$$
+
+### 6.2 데이터 드리프트 감지 (Data Drift Monitoring)
+* 세상이 변하거나 트렌드가 바뀌어 발생하는 오작동을 막기 위해, CLI는 실제 운영 환경에서 수집된 입력 데이터와 모델 학습 데이터 간의 구조적 분포 차이를 **인구통계학적 안정도 지표(PSI, Population Stability Index)**를 통해 정기적으로 계산한다.
+* $\text{PSI} \ge 0.2$ 이상 검출 시, CLI는 '데이터 드리프트 경고(Warning)'를 발생시키고 AI 모델의 재학습(Retraining) 파이프라인 트리거를 요청한다.
@@ -0,0 +1,256 @@
+# tdc114plus 테스트 단계별 전략 (참고용 초안)
+
+* **문서 유형:** 테스트 전략 초안 (참고용)
+* **저장 경로:** `docs/references/ai-testing/tdc114plus_test_strategy.md`
+* **상태:** 참조 폴더 내 초안 — 사용 전 검토/승인 필요
+* **작성일:** 2026-07-02
+
+---
+
+## 목적
+
+`tdc114plus` 개발 중에 적용할 테스트 단계, 진입/종료 조건, 실행 방법, 검증 포인트를 정의한다. 이 문서는 참조용 초안이며, 최종 확정 시 사용자 승인을 받아 참조 폴더 밖(프로덕션 정책 위치)으로 이동한다.
+
+## 범위
+
+- Flutter 앱 클라이언트: UI, 화면 흐름, 비즈니스 로직
+- AI/ML 관련 컴포넌트: 추론 함수, 프롬프트 템플릿, 결과 검증 루틴
+- 백엔드 연동: Baron SSO 로그인, orgFront 직원/조직 데이터 조회
+
+---
+
+## 개발 단계별 테스트 전략
+
+`tdc114plus` 개발 진행은 다음 세 시기로 구분한다.
+
+1. 초반(Initial phase)
+2. 중반(Mid phase)
+3. 후반(Late phase)
+
+각 시기에 따라 테스트 우선순위와 적용 대상이 달라진다.
+
+### 초반(Initial phase)
+
+- 목표: 화면 흐름, 기본 기능, 코드 품질을 빠르게 검증하여 개발 기반을 마련한다.
+- 주요 활동:
+  - Flutter 프로젝트 골격 확립
+  - 로그인/직원검색/조직도 기본 화면 구성
+  - Mock 데이터 기반 화면 흐름 검증
+- 적용 테스트:
+  1. Static & CI Gate
+     - `flutter analyze`, `dart format`, `flutter test --coverage`
+     - 코드 스타일, 정적 분석, 기본 단위 테스트
+  2. Unit & Component Tests
+     - 화면 라우팅, 상태 전이, 데이터 변환
+     - Mock 기반 ViewModel/Controller 동작 검증
+  3. Mock-driven UI E2E
+     - Mock API로 로그인→검색→조직도 시나리오 검증
+     - 스냅샷 저장 및 회귀 검증
+- 개선 포인트:
+  - 코드 품질 이슈 조기 발견
+  - 초기 화면 플로우의 불일치 축소
+  - Mock 데이터와 실제 API 계약 간 차이를 명확히 정의
+- 예시 명령:
+
+```bash
+./scripts/flutter-docker.sh analyze
+flutter test --coverage
+genhtml coverage/lcov.info -o coverage/html
+```
+
+### 중반(Mid phase)
+
+- 목표: 외부 API 연동을 통합하고, 인증/권한/데이터 일관성 등을 검증한다.
+- 주요 활동:
+  - Baron SSO 로그인 연동
+  - orgFront 직원/조직 조회 로직 구현
+  - 권한/마스킹/가족사 필터 검증
+- 적용 테스트:
+  1. Integration Tests
+     - Staging 또는 계약된 환경에서 API 연동
+     - 로그인 세션, 직원 목록, 조직도 탐색 검증
+  2. Unit & Component Tests
+     - API 파싱, 재시도, 오류 처리, 보안 예외 로직
+  3. Snapshot Loop 유지
+     - Mock 데이터를 실 연동 API 형태로 업데이트
+     - UI 회귀 스냅샷 재검증
+- 개선 포인트:
+  - API 변경 영향 조기 검증
+  - 인증/권한 경계 문제 발견
+  - 데이터 포맷 불일치 최소화
+- 예시 명령:
+
+```bash
+export TDC114_API_BASE=https://staging-api.example.com
+export TDC114_API_KEY=staging-key
+./scripts/integration_tests.sh
+```
+
+### 후반(Late phase)
+
+- 목표: 릴리스 준비 상태에서 성능, 보안, 적대적 대응, 회귀 검증을 완료한다.
+- 주요 활동:
+  - 릴리스 후보 빌드
+  - 레드팀/적대적 테스트
+  - 성능 및 데이터 드리프트 점검
+- 적용 테스트:
+  1. Adversarial / Red-team Automated Runs
+     - Jailbreaker, Social Engineer, Poisoner 시나리오
+     - 시스템 역할, 의미론적 필터, 차단/대체 동작 검증
+  2. Release Gate & Performance Checks
+     - APK 빌드, 메모리/CPU 스모크, 보안 스캔
+     - PSI 기반 데이터 드리프트 감지
+  3. Regression Snapshot Validation
+     - 주요 화면 및 시나리오에 대한 스냅샷 재검증
+- 개선 포인트:
+  - 릴리스 이전 회귀 위험 제거
+  - 보안/안정성 취약점 보강
+  - 실제 운영 수준 성능 파악
+- 예시 명령:
+
+```bash
+flutter build apk --debug
+./scripts/perf_smoke.sh
+./scripts/redteam/run_all.sh --profile=jailbreaker
+```
+
+---
+
+## 각 단계별 테스트 분류
+
+| 테스트 유형 | 초반 | 중반 | 후반 |
+| --- | --- | --- | --- |
+| Static & CI Gate | 필수 | 필수 | 필수 |
+| Unit & Component Tests | 주력 | 유지 | 유지 |
+| Mock-driven UI E2E | 핵심 | 일부 유지 | 회귀 검증 |
+| Integration Tests | 준비 | 주력 | 유지/확장 |
+| Adversarial / Red-team Runs | 준비 | 준비 | 핵심 |
+| Release/Performance Checks | 없음 | 예비 | 주력 |
+
+### 단계별 핵심 검증 포인트
+
+- 초반: 화면 흐름, Mock 데이터 기반 상태 전환, 초기 코드 품질
+- 중반: 실제 API 연동, 인증 및 권한, 외부 오류 처리
+- 후반: 보안/레드팀 검증, 성능 안정성, 릴리스 체크리스트
+
+### 초반 단계 상세 시나리오
+
+- 로그인 화면 진입 및 입력 필드 유효성 검증
+- 입력된 전화번호가 형식에 맞지 않을 때 경고 메시지 표시
+- Mock 사용자 존재/미존재에 따른 로그인 성공/실패 플로우
+- 직원 검색 화면 진입 후 단어 검색, 결과 없음/결과 있음 케이스
+- 조직도 화면에서 노드 확장·축소, 팝업/상세 정보 표시
+- 즐겨찾기 토글 및 로컬 상태 저장 확인
+
+### 중반 단계 상세 시나리오
+
+- 실제 SSO 인증 실패 시 재시도 및 오류 메시지 표시
+- orgFront 직원 목록 중 특정 가족사 검색 시 필터 동작 확인
+- 조직도 건너뛰기 및 자회사/모회사 표시 일관성 검증
+- API 응답 구조 변경에 대한 파싱 예외 처리 확인
+- 네트워크 타임아웃/401/500 등 실패 케이스 대응 검증
+
+### 후반 단계 상세 시나리오
+
+- 릴리스 후보 APK 설치 후 주요 화면 진입 안정성 검증
+- Auth 세션 만료 후 재로그인 흐름 확인
+- 레드팀 공격 시나리오로 프롬프트 우회/입력 조작 시 방어 검증
+- 성능 기준에서 검색 응답 시간 및 UI 스크롤 부하 확인
+- 데이터 드리프트 지표(PSI) 계산에 필요한 로그 수집 경로 확인
+
+### 자동화 스크립트 템플릿
+
+아래 예시는 실제 스크립트 작성 시 템플릿으로 활용할 수 있는 구조이다.
+
+#### 1. Static & CI Gate 스크립트
+
+```bash
+#!/usr/bin/env bash
+set -e
+
+echo "[STATIC] Format check"
+./scripts/flutter-docker.sh format
+
+echo "[STATIC] Analyze"
+./scripts/flutter-docker.sh analyze
+
+echo "[STATIC] Unit tests with coverage"
+./scripts/flutter-docker.sh test --coverage
+
+echo "[STATIC] Completed"
+```
+
+#### 2. Mock-driven UI E2E 스크립트
+
+```bash
+#!/usr/bin/env bash
+set -e
+
+echo "[MOCK E2E] Start mock server"
+./scripts/mock-server.sh start
+
+echo "[MOCK E2E] Run UI automation"
+flutter drive --target=test_driver/app.dart
+
+echo "[MOCK E2E] Save snapshot results"
+# snapshot 저장 스크립트 예시
+./scripts/save-snapshots.sh tests/snapshots/tdc114plus
+```
+
+#### 3. Integration 테스트 실행 스크립트
+
+```bash
+#!/usr/bin/env bash
+set -e
+
+export TDC114_API_BASE=${TDC114_API_BASE:-https://staging-api.example.com}
+export TDC114_API_KEY=${TDC114_API_KEY:?"TDC114_API_KEY required"}
+
+echo "[INTEGRATION] Start integration tests"
+./scripts/integration_tests.sh
+```
+
+#### 4. 레드팀 자동화 실행 스크립트
+
+```bash
+#!/usr/bin/env bash
+set -e
+
+for profile in jailbreaker social_engineer poisoner; do
+  echo "[REDTEAM] Running profile: $profile"
+  ./scripts/redteam/run_all.sh --profile="$profile"
+done
+```
+
+#### 5. 릴리스 준비 스크립트
+
+```bash
+#!/usr/bin/env bash
+set -e
+
+echo "[RELEASE] Build debug APK"
+flutter build apk --debug
+
+echo "[RELEASE] Run performance smoke tests"
+./scripts/perf_smoke.sh
+
+echo "[RELEASE] Generate release report"
+./scripts/generate-release-report.sh reports/tdc114plus/$(date +%Y%m%d)
+```
+
+---
+
+## 리포트 및 기록
+
+- 자동화 실행 결과는 `reports/tdc114plus/YYYYMMDD/` 경로에 저장한다.
+- 저장 항목:
+  - 테스트 커버리지 보고서
+  - 실패 케이스 및 재현 정보
+  - 레드팀 시나리오 결과
+  - PSI/데이터 드리프트 계산 결과
+- 실패 이력은 Jira 또는 이슈 트래커로 자동 이관을 권장한다.
+
+## 거버넌스
+
+- 이 문서는 참조용 초안이며, 프로젝트 정책으로 채택하려면 정책팀/제품/보안 담당자의 승인 절차를 거쳐야 한다.
+- 승인 전까지 이 파일은 `docs/references/ai-testing/`에만 보관되며, 사용 전 최종 검토를 요청한다.
@@ -0,0 +1,93 @@
+# tdc114plus 테스트 자동화 스크립트 계획
+
+작성일: 2026-07-02
+상태: v1.0 초기 스크립트 기준
+
+목적: `docs/tdc114plus-testing-policy-2026-07-02.md`에 정의한 테스트 정책을 실제 `scripts/` 파일과 연결하고, 즉시 사용 가능한 스크립트와 향후 구현이 필요한 scaffold 스크립트를 구분한다.
+
+## 1. 즉시 사용 가능한 스크립트
+
+| 스크립트 | 목적 | 실행 예 |
+| --- | --- | --- |
+| `scripts/format-dart.sh` | Docker Flutter 이미지에서 `dart format lib test` 실행 | `./scripts/format-dart.sh` |
+| `scripts/quality-gate.sh` | `flutter analyze`, `flutter test` 순차 실행 | `./scripts/quality-gate.sh` |
+| `scripts/generate-release-report.sh` | git 상태와 릴리스 체크리스트 report 생성 | `./scripts/generate-release-report.sh` |
+| `scripts/perf_smoke.sh` | 현재 앱/테스트 파일 수와 기본 상태 출력 | `./scripts/perf_smoke.sh` |
+
+## 2. Scaffold 상태의 스크립트
+
+아래 스크립트는 파일은 존재하지만, 기반 기능이 아직 없으므로 실행 시 scaffold 안내와 함께 종료한다.
+
+| 스크립트 | 현재 상태 | 완성 조건 |
+| --- | --- | --- |
+| `scripts/mock-server.sh` | `status`, `stop`은 가능. `start`는 미구현 안내 | API 계약 기반 mock server 구현 |
+| `scripts/save-snapshots.sh` | snapshot source가 있으면 report 경로로 복사 | widget/integration screenshot 또는 snapshot 생성 체계 |
+| `scripts/integration_tests.sh` | `TDC114_API_BASE`와 `integration_test/` 필요 | staging API 또는 mock server 기반 integration test |
+| `scripts/redteam/run_all.sh` | 현재 AI 기능 없음 안내 | LLM/프롬프트 기반 기능이 실제 추가될 때 |
+
+## 3. Phase별 사용 기준
+
+### Phase 3: Mock 기반 1차 UI
+
+필수:
+
+```bash
+./scripts/format-dart.sh
+./scripts/quality-gate.sh
+```
+
+선택:
+
+```bash
+./scripts/save-snapshots.sh
+```
+
+단, snapshot 산출물이 생긴 뒤 사용한다.
+
+### Phase 4: 실제 API 연동
+
+필수 후보:
+
+```bash
+TDC114_API_BASE=https://staging.example.com ./scripts/integration_tests.sh
+```
+
+완성 조건:
+
+- `app/integration_test/` 테스트 추가
+- staging 또는 local mock API endpoint 확정
+- 민감정보 없는 test fixture 사용
+
+### Phase 5: 핵심 액션
+
+필수 후보:
+
+```bash
+./scripts/quality-gate.sh
+./scripts/perf_smoke.sh
+```
+
+추가 예정:
+
+- 전화걸기/문자보내기 URL 생성 테스트
+- 즐겨찾기 로컬 저장소 테스트
+
+### Phase 6: 빌드/배포 준비
+
+필수 후보:
+
+```bash
+./scripts/generate-release-report.sh
+```
+
+추가 예정:
+
+- Android debug APK build wrapper
+- 수동 검증 체크리스트 자동 생성
+
+## 4. 운영 원칙
+
+- 문서에 명령을 추가할 때는 실제 `scripts/` 파일도 함께 추가하거나 scaffold 상태를 명시한다.
+- scaffold 스크립트는 조용히 성공하지 않고, 미구현이면 non-zero exit code로 종료한다.
+- 실제 CI gate에 연결할 수 있는 스크립트는 `quality-gate.sh`부터 시작한다.
+- AI/LLM redteam 자동화는 현재 앱 범위 밖이므로 `redteam/run_all.sh`는 보류 상태로 유지한다.
@@ -39,15 +39,15 @@ Flutter 앱 코드를 변경한 모든 작업은 아래 검증을 통과해야
 추가로 Dart 파일을 많이 수정했거나 새 파일을 추가한 경우 formatter를 적용한다.

 ```bash
-docker run --rm -u 0:0 \
-  -v /home/ubuntu/workspace/tdc114plus:/workspace \
-  -w /workspace/app \
-  ghcr.io/cirruslabs/flutter:stable \
-  sh -lc "flutter pub get && dart format lib test && chown -R 1000:1000 /workspace/app"
+./scripts/format-dart.sh
 ```

 검증 실패 상태의 코드는 `main` 브랜치에 반영하지 않는다.

+자동화 스크립트의 구현 상태와 향후 보강 계획은 아래 문서를 따른다.
+
+- `docs/tdc114plus-script-automation-plan-2026-07-02.md`
+
 ## 3. 테스트 강도 기준

 ### 3.1 강한 테스트가 필요한 영역
@@ -245,6 +245,7 @@ Mock 데이터가 API 계약과 달라지는 경우 API 계약 문서를 먼저

 - `docs/references/ai-testing/ai_testing_policy_draft.md`
 - `docs/references/ai-testing/tdc114plus_test_strategy.md`
+- `docs/tdc114plus-script-automation-plan-2026-07-02.md`

 본 문서는 위 참고문서보다 `tdc114plus` 개발에 우선 적용한다.

@@ -47,12 +47,13 @@
 | 13 | API 계약 검토 및 확정 | 완료 | API 계약 초안의 추가 확인사항 검토 후 1차 구현 기준 확정 | `docs/tdc114plus-api-contract-2026-07-02.md` |
 | 14 | 데이터 모델 설계 | 완료 | 직원, 조직, 가족사, 즐겨찾기 모델 정의 | Dart model 및 model test |
 | 15 | 테스트 정책 정식화 | 완료 | AI testing 참고 초안을 tdc114plus Flutter 앱/API/보안 중심 테스트 정책으로 재해석 | `docs/tdc114plus-testing-policy-2026-07-02.md` |
-| 16 | Mock 데이터 기반 화면 확장 | 다음 작업 | 직원목록, 검색, 가족사 필터, 조직도 화면을 mock 데이터로 우선 구현 | 동작 가능한 UI |
-| 17 | Baron SSO 로그인 연동 | 대기 | 전화번호 입력 후 SSO 등록 인원 여부 확인 연동 | 로그인 client/repository |
-| 18 | orgFront 데이터 연동 | 대기 | 직원/조직 데이터 API 연동 | directory/organization client |
-| 19 | 전화/문자 액션 구현 | 대기 | `url_launcher` 기반 전화걸기/문자보내기 구현 | 연락 액션 |
-| 20 | 즐겨찾기 구현 | 대기 | 1차 로컬 저장 기반 즐겨찾기 구현 | favorites feature |
-| 21 | Android APK 빌드 확인 | 대기 | debug APK 빌드 및 실행 확인 | APK 산출물 |
+| 16 | 테스트 자동화 스크립트 초기 구성 | 완료 | 테스트 정책 기반 scripts 추가 및 scaffold 상태 문서화 | `scripts/*.sh`, `docs/tdc114plus-script-automation-plan-2026-07-02.md` |
+| 17 | Mock 데이터 기반 화면 확장 | 다음 작업 | 직원목록, 검색, 가족사 필터, 조직도 화면을 mock 데이터로 우선 구현 | 동작 가능한 UI |
+| 18 | Baron SSO 로그인 연동 | 대기 | 전화번호 입력 후 SSO 등록 인원 여부 확인 연동 | 로그인 client/repository |
+| 19 | orgFront 데이터 연동 | 대기 | 직원/조직 데이터 API 연동 | directory/organization client |
+| 20 | 전화/문자 액션 구현 | 대기 | `url_launcher` 기반 전화걸기/문자보내기 구현 | 연락 액션 |
+| 21 | 즐겨찾기 구현 | 대기 | 1차 로컬 저장 기반 즐겨찾기 구현 | favorites feature |
+| 22 | Android APK 빌드 확인 | 대기 | debug APK 빌드 및 실행 확인 | APK 산출물 |

 ## 3. 단계별 타임테이블

@@ -65,6 +66,7 @@
 | Phase 2-2 | 완료 | API 계약 검토 및 확정 | token 종류, 전화번호 로그인 보안 수준, 개인정보 마스킹 범위, 즐겨찾기 동기화 여부 확인 | API 계약 확정본 |
 | Phase 2-3 | 완료 | Dart 데이터 모델 설계 | 확정된 API 계약 기준으로 직원, 조직, 로그인, 즐겨찾기 model 정의 | analyze/test 통과 |
 | Phase 2-4 | 완료 | 테스트 정책 정식화 | AI testing 참고 초안을 tdc114plus 적용 기준으로 정리 | `docs/tdc114plus-testing-policy-2026-07-02.md` |
+| Phase 2-5 | 완료 | 테스트 자동화 스크립트 초기 구성 | 즉시 실행 가능한 quality/format/report 스크립트와 scaffold 스크립트 추가 | `docs/tdc114plus-script-automation-plan-2026-07-02.md` |
 | Phase 3 | 다음 | Mock 기반 1차 UI 완성 | 직원목록, 검색, 가족사 필터, 조직도, 상세 화면 구성 | API 없이 화면 흐름 확인 가능 |
 | Phase 4 | 이후 | 실제 API 연동 | SSO 로그인, orgFront 직원/조직 데이터 연동 | 등록 사용자 로그인 및 직원목록 조회 |
 | Phase 5 | 이후 | 핵심 액션 완성 | 전화걸기, 문자보내기, 즐겨찾기 저장 | 1차 기본 기능 수동 검증 |
@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+IMAGE="${FLUTTER_DOCKER_IMAGE:-ghcr.io/cirruslabs/flutter:stable}"
+
+docker run --rm \
+  -u 0:0 \
+  -v "$ROOT_DIR:/workspace" \
+  -w /workspace/app \
+  "$IMAGE" \
+  sh -lc "flutter pub get && dart format lib test && chown -R 1000:1000 /workspace/app"
@@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+REPORT_DIR="${1:-$ROOT_DIR/reports/tdc114plus/$(date +%Y%m%d-%H%M%S)}"
+REPORT_FILE="$REPORT_DIR/release-report.md"
+
+mkdir -p "$REPORT_DIR"
+
+{
+  echo "# tdc114plus release report"
+  echo
+  echo "Generated at: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
+  echo
+  echo "## Git"
+  echo
+  echo '```text'
+  git -C "$ROOT_DIR" status --short --branch
+  echo
+  git -C "$ROOT_DIR" log --oneline -n 10
+  echo '```'
+  echo
+  echo "## Verification Checklist"
+  echo
+  echo "- [ ] ./scripts/format-dart.sh"
+  echo "- [ ] ./scripts/quality-gate.sh"
+  echo "- [ ] Android debug APK build"
+  echo "- [ ] Login/search/detail/favorites smoke test"
+  echo "- [ ] Token storage review"
+  echo "- [ ] Personal data exposure review"
+} >"$REPORT_FILE"
+
+echo "generated release report: $REPORT_FILE"
@@ -0,0 +1,19 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+APP_DIR="$ROOT_DIR/app"
+
+if [ -z "${TDC114_API_BASE:-}" ]; then
+  echo "TDC114_API_BASE is required for integration tests." >&2
+  echo "Example: TDC114_API_BASE=https://staging.example.com $0" >&2
+  exit 64
+fi
+
+if [ ! -d "$APP_DIR/integration_test" ]; then
+  echo "integration test scaffold: $APP_DIR/integration_test does not exist yet." >&2
+  echo "Add Flutter integration tests before enabling this script in CI." >&2
+  exit 2
+fi
+
+"$ROOT_DIR/scripts/flutter-docker.sh" test integration_test
@@ -0,0 +1,32 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+PID_FILE="$ROOT_DIR/.tdc114plus-mock-server.pid"
+
+case "${1:-}" in
+  start)
+    echo "mock-server scaffold: no mock API server has been implemented yet." >&2
+    echo "Expected future command: start a local API-compatible mock server." >&2
+    exit 2
+    ;;
+  stop)
+    if [ -f "$PID_FILE" ]; then
+      echo "mock-server scaffold: removing stale pid file $PID_FILE"
+      rm -f "$PID_FILE"
+    else
+      echo "mock-server scaffold: no running mock server pid file found."
+    fi
+    ;;
+  status)
+    if [ -f "$PID_FILE" ]; then
+      echo "mock-server scaffold: pid file exists at $PID_FILE"
+    else
+      echo "mock-server scaffold: not running."
+    fi
+    ;;
+  *)
+    echo "Usage: $0 {start|stop|status}" >&2
+    exit 64
+    ;;
+esac
@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+APP_DIR="$ROOT_DIR/app"
+
+if [ ! -d "$APP_DIR" ]; then
+  echo "app directory does not exist: $APP_DIR" >&2
+  exit 1
+fi
+
+echo "perf smoke scaffold"
+echo "- app directory: $APP_DIR"
+echo "- dart files: $(find "$APP_DIR/lib" -name '*.dart' | wc -l)"
+echo "- test files: $(find "$APP_DIR/test" -name '*.dart' | wc -l)"
+echo "No runtime performance probe is implemented yet."
@@ -0,0 +1,7 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+
+"$ROOT_DIR/scripts/flutter-docker.sh" analyze
+"$ROOT_DIR/scripts/flutter-docker.sh" test
@@ -0,0 +1,22 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+PROFILE="all"
+
+for arg in "$@"; do
+  case "$arg" in
+    --profile=*)
+      PROFILE="${arg#--profile=}"
+      ;;
+    *)
+      echo "Unknown argument: $arg" >&2
+      echo "Usage: $0 [--profile=jailbreaker|social_engineer|poisoner|all]" >&2
+      exit 64
+      ;;
+  esac
+done
+
+echo "redteam scaffold: profile=$PROFILE"
+echo "tdc114plus does not include LLM/AI inference in the current scope."
+echo "This script is reserved for future AI features or prompt-based workflows."
+exit 2
@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+SOURCE_DIR="${1:-$ROOT_DIR/app/test/snapshots}"
+TARGET_DIR="${2:-$ROOT_DIR/reports/snapshots/$(date +%Y%m%d-%H%M%S)}"
+
+if [ ! -d "$SOURCE_DIR" ]; then
+  echo "snapshot source directory does not exist: $SOURCE_DIR" >&2
+  echo "Create widget/integration snapshot output first, then rerun this script." >&2
+  exit 2
+fi
+
+mkdir -p "$TARGET_DIR"
+cp -R "$SOURCE_DIR"/. "$TARGET_DIR"/
+echo "saved snapshots to $TARGET_DIR"