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

이 장에서 배우는 것 착수 전에 확인해야 할 네 가지, 그리고 이 단계를 건너뛰었을 때 어디서 막히는지.

데이터베이스가 무엇인지부터 모르겠다면 데이터베이스란 무엇인가를 먼저 보세요.

이 단계의 목적

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

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

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

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

네 가지 활동

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

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

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

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

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

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

3. 데이터 품질 평가

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

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

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

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

산출물

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

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

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

이 그림에 사람 승인이 어디에 들어가는지가 표시되어 있어야 합니다. 그게 가드레일 설계의 시작입니다.

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

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

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

이 단계에서 자주 하는 실수

문서만 보고 판단합니다

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

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

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

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

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

확인

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

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

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

만들기 전에 법적 요건을 한 번 확인합니다 → 규제와 컴플라이언스