# Phase 2 — 데이터 · 시스템 진단

> **이 장에서 배우는 것**
> 착수 전에 확인해야 할 네 가지, 그리고 이 단계를 건너뛰었을 때 어디서
> 막히는지.
>
> **데이터베이스가 무엇인지부터 모르겠다면** [데이터베이스란 무엇인가](/guide/it-database)를 먼저 보세요.

## 이 단계의 목적

> **기존 데이터와 시스템 환경을 분석하고 연동 방안을 수립합니다.**

한 문장으로 하면 **"만들 수 있는지 만들기 전에 확인하는 것"**입니다.

가장 아까운 실패가 이겁니다.

```
POC 3주차: "그 데이터는 못 가져옵니다"
→ 보안팀 승인이 필요한데 2개월 걸린다
→ 또는 그 시스템에 API가 없다
→ 또는 데이터가 있긴 한데 품질이 못 쓸 수준이다
```

**만들다가 알게 되면 이미 3주를 쓴 뒤입니다.** Phase 2는 그 3주를 3일로 줄이는
단계입니다.

## 네 가지 활동

### 1. 데이터 소스 매핑 (API/DB/문서)

필요한 데이터가 **어디에 어떤 형태로** 있는지 적습니다.

| 필요한 것 | 어디에 | 형태 | 접근 방법 | 확인됨 |
|---|---|---|---|---|
| 청구서 원본 | 회계팀 메일함 | PDF 첨부 | IMAP | ○ |
| 거래처 마스터 | ERP | DB 테이블 | 읽기 계정 필요 | **△ 신청 중** |
| 계정 코드 규칙 | 담당자 머릿속 | — | 인터뷰로 문서화 | ✗ |
| 과거 입력 이력 | ERP | DB | 위와 동일 | △ |

**세 번째 줄을 눈여겨보세요.** "담당자 머릿속"에 있는 규칙은 매우 흔하고, 이걸
문서화하는 것 자체가 이 단계의 산출물입니다.

### 2. 시스템 연동 가능성 검토

각 시스템에 **어떻게 연결할 수 있는지** 확인합니다.

| 연동 방식 | 난이도 | 확인할 것 |
|---|---|---|
| 공식 API가 있다 | 낮음 | 인증 방식, 호출 제한 |
| DB 직접 읽기 | 중간 | 읽기 전용 계정, 스키마 변경 위험 |
| 파일로 주고받기 | 중간 | 주기, 파일 위치, 형식 안정성 |
| 화면 자동화뿐 | **높음** | 화면이 바뀌면 깨짐. 최후 수단 |

마지막 줄이면 **재검토가 필요합니다.** 만들 수는 있지만 유지가 안 됩니다.

### 3. 데이터 품질 평가

접근할 수 있다고 쓸 수 있는 건 아닙니다.

```
확인 항목:
  □ 빠진 값이 얼마나 되나        (예: 거래처 코드 12% 누락)
  □ 형식이 일관적인가            (날짜가 3가지 형식으로 섞여 있음)
  □ 중복이 있나                  (같은 거래처가 이름 다르게 4건)
  □ 언제까지 거슬러 올라가나      (2년치만 있음)
  □ 갱신 주기는                  (야간 배치, 하루 늦음)
```

**"하루 늦음"이 치명적인 과제**가 있습니다. 실시간 응대에 쓸 데이터가 하루
늦으면 그 과제는 성립하지 않습니다. 이런 걸 지금 발견해야 합니다.

### 4. 거버넌스 & 보안 요구사항 정리

| 확인 | 왜 |
|---|---|
| 이 데이터가 외부로 나가도 되나 | 개인정보·영업비밀 포함 여부 |
| 승인이 필요한가, 누구의 | 대개 예상보다 오래 걸림 |
| 로그를 남겨야 하나 | 규제 업종에서 필수 |
| 폐쇄망이어야 하나 | 그렇다면 구성이 완전히 달라짐 |

**승인 소요 기간을 반드시 물어보세요.** "2주면 됩니다"와 "분기 심의회를
거칩니다"는 계획이 완전히 달라집니다.

## 산출물

> **시스템 아키텍처 & 데이터 플로우 다이어그램**

그림 한 장이면 충분합니다. 이런 형태입니다.

```mermaid
graph TD
  A["회계팀 메일함<br/>PDF 첨부"] --> B["문서 읽기"]
  C["ERP 거래처 마스터<br/>읽기 전용 계정"] --> B
  D["계정 코드 규칙<br/>문서화 완료"] --> B
  B --> E["입력안 생성"]
  E --> F{"금액 100만원 초과?"}
  F -->|"예"| G["사람 승인"]
  F -->|"아니오"| H["ERP 자동 입력"]
  G --> H
```

이 그림에 **사람 승인이 어디에 들어가는지**가 표시되어 있어야 합니다. 그게
[가드레일](/guide/ha-guardrails) 설계의 시작입니다.

## 게이트 — 다음으로 넘어가려면

> **필요한 데이터에 실제로 접근할 수 있음을 확인했는가?**

"확인했다"의 기준은 **실제로 한 번 가져와 본 것**입니다. "가능할 것 같다"가
아닙니다.

```
✗ "ERP에 API가 있다고 합니다"
✓ "읽기 계정을 받아서 거래처 10건을 실제로 조회해봤습니다"
```

## 이 단계에서 자주 하는 실수

### 문서만 보고 판단합니다

"API 문서에 있으니 되겠지" → 실제로는 그 엔드포인트가 비활성화돼 있거나, 권한이
다르거나, 응답이 문서와 다릅니다. **한 번 실제로 호출해보는 데 30분**이면
됩니다.

### 보안 승인을 나중으로 미룹니다

가장 흔한 일정 지연 원인입니다. 기술 검토는 며칠이면 되는데 승인은 몇 주가
걸립니다. **Phase 2를 시작하는 날 승인 신청부터** 넣으세요. 다른 확인을 하는
동안 병렬로 진행됩니다.

### 데이터 품질을 눈으로만 봅니다

10건 보고 "괜찮네" 하면 안 됩니다. 전체에 대해 **빠진 값 비율, 형식 종류, 중복
건수**를 세어보세요. 쿼리 몇 줄이면 됩니다.

---

## 확인

**1. "데이터에 접근할 수 있음을 확인했다"의 기준은 무엇입니까?**

<details>
<summary>답</summary>

**실제로 한 번 가져와 본 것**입니다. "API가 있다고 합니다"는 확인이 아니고,
"읽기 계정을 받아 10건을 조회해봤습니다"가 확인입니다.
</details>

**2. 데이터 갱신 주기가 "야간 배치, 하루 늦음"인 것이 왜 중요합니까?**

<details>
<summary>답</summary>

**과제 성립 여부를 바꾸기 때문**입니다. 실시간 고객 응대에 쓸 데이터가 하루
늦으면 그 과제는 성립하지 않습니다. 이런 건 만들기 전에 발견해야 합니다.
</details>

**3. 보안 승인을 Phase 2 시작일에 바로 신청해야 하는 이유는?**

<details>
<summary>답</summary>

**승인이 기술 검토보다 훨씬 오래 걸리기 때문**입니다. 기술 확인은 며칠이면 되는데
승인은 몇 주가 걸리고, 가장 흔한 일정 지연 원인입니다. 먼저 신청해두면 다른
확인을 하는 동안 병렬로 진행됩니다.
</details>

---

만들기 전에 법적 요건을 한 번 확인합니다 →
[규제와 컴플라이언스](/guide/ax-compliance)