데이터가 먼저 정해져 있을 때의 설계

크롤링, 외부 API, 레거시 DB, 공공 데이터처럼 데이터 형태가 이미 결정되어 있는 경우 how-to-design-a-program-from-scratch|설계 프로세스가 어떻게 달라지는가.

순서가 뒤집히는 게 아니라 시작점이 달라진다

⓪ 단계가 추가된다. 외부에서 뭘 받을 수 있는지 파악하고, 그 제약 안에서 요구사항을 정한다.

핵심: 외부 데이터 ≠ 내 도메인 모델

학교 수강신청 페이지 크롤링 예시. 사이트에서 받는 원본:

{
  "subject_no": "CSE3081",
  "subject_nm": "알고리즘",
  "time_room": "월3,4(공7-301)/수3,4(공7-301)"
}

time_room에 요일, 시간, 강의실이 문자열 하나에 뭉쳐있다. 이걸 그대로 내 DB에 넣으면 안 된다. 충돌 검사할 때마다 파싱해야 하니까.

변환 계층을 두고, 내 도메인 모델에 맞게 변환해서 저장한다:

외부: time_room: "월3,4(공7-301)"
         ↓ 변환
내부: day: "mon", start_time: "10:00", end_time: "11:30", room: "공7-301"

외부 API도 같은 구조다. designing-local-app-with-server-dependency|LLM 인터페이스도 동일한 패턴 — 외부 형태를 내 형태로 변환하는 계층이 있고, 핵심 로직은 항상 내 형태만 다룬다.

요구사항에 미치는 영향

외부 데이터가 먼저이면 "할 수 있는 것의 범위"가 제한된다:

일반적: "시간표에 원하는 정보를 다 넣겠다"
제약 있을 때: "사이트에서 교수 연구실 번호를 안 준다"
            → v1에서 포기하거나 다른 소스 필요

how-to-scope-requirements|요구사항 종이에 "데이터 제약" 칸을 추가하면 된다.

가장 중요한 원칙

외부 데이터의 형태에 내 도메인 모델을 맞추지 않는다. 외부가 주는 형태가 아무리 이상해도, 내 앱 안에서는 내가 설계한 구조를 유지하고, 둘 사이에 변환 계층을 둔다. 이게 깨지면 외부가 바뀔 때마다 내 앱 전체가 흔들린다.