09 · 데이터베이스와 영속성

← 챕터 목록

데이터를 "어딘가에 남긴다"는 결정은 성능·보안·유지보수를 한꺼번에 좌우한다. 이 챕터는 저장소 선택 기준에서 출발해 트랜잭션·인덱스·마이그레이션 같은 DB 정본 개념을 iOS 스택에 매핑하고, 실무에서 오해가 가장 잦은 Core Data의 정체와 스레드 안전성으로 마무리한다.

Q1. UserDefaults, Keychain, File, Database는 어떤 기준으로 선택하는가?

CS 원리

영속성 저장소는 하나의 스펙트럼입니다. 한쪽 끝에는 key-value 스토어(작은 값, 스키마 없음, 통째 로드), 다른 쪽 끝에는 구조화된 쿼리 엔진(스키마·인덱스·트랜잭션·부분 조회)이 있습니다. 그 사이에 파일 시스템(임의의 바이트 blob, OS가 이름·권한·암호화만 관리)과 보안 전용 스토어(OS가 키로 암호화하고 접근을 강제하는 비밀 저장소)가 놓입니다. 선택은 결국 "이 데이터를 부분적으로/자주 질의하는가", "얼마나 크고 구조적인가", "노출되면 피해가 큰가"에 대한 답입니다.

iOS에서는

UserDefaults는 ~/Library/Preferences/<bundle-id>.plist에 저장되고 cfprefsd 데몬이 관리합니다. 문제는 도메인 단위로 캐시된다는 점 — 값 하나를 읽어도 사실상 해당 도메인 전체가 메모리에 상주합니다. 그래서 Apple 문서도 "적은 양의 데이터"로 한정합니다. Keychain은 내부적으로 SQLite로 저장되지만 Keychain Services가 데이터 보호 클래스와 (기기에 따라) Secure Enclave로 암호화합니다. kSecAttrAccessible* 로 "언제 접근 가능한지"를 강제할 수 있습니다. File은 샌드박스의 Documents/(사용자 데이터, 백업 대상)·Library/Caches/(재생성 가능, 백업 제외·시스템이 지울 수 있음)·tmp/로 나뉘고, 파일마다 데이터 보호 클래스를 붙일 수 있습니다. Database는 SQLite를 직접 쓰거나 그 위의 GRDB, 또는 Core Data / SwiftData / Realm으로 접근합니다.

실험 · 도구

시뮬레이터에서 저장 위치를 눈으로 확인하면 감이 옵니다. xcrun simctl get_app_container booted <bundle-id> data로 컨테이너 경로를 얻어 Library/Preferences/의 plist를 plutil -p로 열면 UserDefaults가 평문 XML/binary plist라는 걸 바로 봅니다. 반대로 Keychain 항목은 파일로 노출되지 않습니다. 관찰 지표: plist 파일 크기 증가(= UserDefaults 오남용 신호), 앱 콜드스타트 시간.

// ❌ 토큰을 UserDefaults 에 — plist 평문, 백업·파일 접근으로 노출된다
UserDefaults.standard.set(accessToken, forKey: "token")

// ✅ Keychain — 데이터 보호로 암호화, 접근성 클래스로 노출 시점을 제한
let query: [String: Any] = [
    kSecClass as String:       kSecClassGenericPassword,
    kSecAttrAccount as String: "accessToken",
    kSecValueData as String:   Data(accessToken.utf8),
    // 첫 잠금 해제 후에만 접근, 이 기기에서만 (백업으로도 유출 안 됨)
    kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
]
SecItemAdd(query as CFDictionary, nil)

프로젝트 적용

• 토큰·리프레시토큰·PIN·암호화 키는 무조건 Keychain. UserDefaults·plist·평문 파일에 두지 않는다.
• UserDefaults에는 수 KB 이내의 사용자 설정만. 이미지·JSON 응답·목록 캐시를 넣지 않는다(콜드스타트 지연 + 메모리 상주).
• 재생성 가능한 데이터는 Library/Caches나 tmp에 두고 Documents를 아끼며, 백업에서 빼야 하면 isExcludedFromBackup을 설정한다.
• "조회 조건이 생기기 시작"하면(정렬·필터·페이지네이션) 파일/UserDefaults를 억지로 붙들지 말고 Database로 승격한다.

꼬리 질문

• Keychain 항목이 앱 삭제 후에도 남는 걸 역이용/방어하려면 첫 실행 시 어떤 전략을 쓰나요? App Group·Keychain Sharing이 걸리면 판단이 어떻게 달라지나요?
• App Group으로 위젯·확장과 공유해야 하는 설정값이라면 UserDefaults·File·Database 중 무엇이 어떻게 달라지나요?
• 기기가 잠긴 상태(백그라운드 페치 등)에서도 데이터를 읽어야 한다면 데이터 보호 클래스를 어떻게 고르나요?

Q2. Transaction과 ACID는 무엇인가?

CS 원리

ACID는 각각 다른 실패로부터 지킵니다. Atomicity는 "돈 빼기"와 "돈 넣기" 사이에서 프로세스가 죽어도 반쪽 상태가 남지 않게 합니다 — 커밋 전 로그(undo)로 되돌립니다. Consistency는 외래키·유니크·NOT NULL 같은 불변식을 트랜잭션 경계에서 항상 만족시킵니다. Isolation은 동시 실행을 마치 순차 실행처럼 보이게 하는 정도이며, 격리 수준(Read Committed, Repeatable Read, Serializable 등)에 따라 dirty read·non-repeatable read·phantom read가 허용되는지가 달라집니다. Durability는 커밋 응답을 받은 데이터가 저장 매체에 안전히 내려간 것(fsync)을 의미합니다. 구현의 핵심은 Write-Ahead Logging — 데이터 페이지를 덮어쓰기 전에 변경 기록을 먼저 로그에 안전하게 써두어, 크래시 후 재시작 때 redo/undo로 일관 상태를 복구합니다.

iOS에서는

iOS 영속성의 바닥에는 대개 SQLite 트랜잭션이 있습니다. SQLite는 기본적으로 원자적 커밋을 보장하고, WAL 모드에서는 변경을 별도 -wal 파일에 먼저 쓴 뒤 체크포인트 때 본 DB에 반영합니다. WAL의 실질적 이점은 동시성 — 다수의 reader와 한 명의 writer가 서로를 막지 않습니다. Core Data는 iOS 7부터 SQLite 스토어에 WAL을 기본으로 씁니다. NSManagedObjectContext.save()는 그 컨텍스트에 쌓인 변경을 한 트랜잭션으로 커밋하므로, 저장이 실패하면 부분 반영 없이 오류를 던집니다. GRDB는 이를 try db.write { ... } 클로저로 명시적으로 감싸, 클로저가 정상 종료하면 커밋, throw하면 롤백합니다.

BEGIN;                                                   -- 트랜잭션 시작
UPDATE account SET balance = balance - 100 WHERE id = 1;  -- 출금
UPDATE account SET balance = balance + 100 WHERE id = 2;  -- 입금
COMMIT;                                                   -- 둘 다 반영(원자성)
-- 두 UPDATE 사이에서 앱이 죽어도, 커밋 전이면 SQLite 가 자동 ROLLBACK →
-- "출금은 됐는데 입금은 안 된" 반쪽 상태가 남지 않는다.

실험 · 도구

Core Data가 실제로 WAL을 쓰는지 확인해 보세요. 스토어 폴더에 Model.sqlite 옆으로 Model.sqlite-wal과 -shm이 함께 생기면 WAL 모드입니다. sqlite3 Model.sqlite "PRAGMA journal_mode;"가 wal을 반환하는지 봅니다. 격리 실험은 두 연결을 열고 한쪽에서 BEGIN; UPDATE ... 후 커밋하지 않은 상태로 다른 연결에서 같은 행을 읽어, 커밋 전 값이 보이는지(dirty read 여부)를 관찰합니다. SQLite는 dirty read를 허용하지 않으므로 이전 값이 보여야 정상입니다.

프로젝트 적용

• "읽고-계산하고-쓰기"가 하나의 정합성 단위면 반드시 한 트랜잭션으로 묶는다. 개별 save()를 여러 번 나누면 중간 크래시에 반쪽 상태가 남는다.
• 대량 삽입은 행마다 커밋하지 말고 한 트랜잭션으로 묶어라 — 커밋마다 발생하는 fsync 비용이 수백 배 차이를 만든다.
• WAL 파일이 무한히 커지면 체크포인트가 안 도는 신호(장수명 reader가 붙잡고 있음). 백그라운드 컨텍스트를 오래 열어두지 않는다.

꼬리 질문

• 격리 수준 중 Serializable이 가장 안전한데도 항상 쓰지 않는 이유는? 어떤 이상현상(anomaly)까지 허용할지 어떻게 결정하나요?
• WAL 모드에서 -wal 파일이 계속 커진다면 원인과 해결책은 무엇인가요? (체크포인트, 장수명 트랜잭션)
• Core Data에서 save() 한 번에 수만 건을 넣으면 무슨 문제가 생기고, 어떻게 배치로 쪼개면서도 원자성을 유지하나요?

Q3. Database Index는 검색을 어떻게 빠르게 만들며 어떤 비용이 있는가?

CS 원리

인덱스 없이 WHERE room_id = 42를 처리하면 DB는 모든 행을 하나씩 검사합니다(full table scan, O(n)). 인덱스는 그 컬럼의 값들을 정렬된 B-tree/B+tree로 유지합니다. 트리 높이가 log(n)이라 몇 번의 비교로 원하는 값(또는 행 위치)에 도달합니다. 정렬돼 있다는 성질 덕분에 범위 검색(BETWEEN), 정렬(ORDER BY), 접두 검색도 빨라집니다. 비용의 본질은 중복된 진실입니다 — 같은 데이터를 두 벌(테이블 + 인덱스) 유지하므로, 쓰기마다 양쪽을 맞춰야 하고(write amplification) 저장 공간이 늘어납니다. 복합 인덱스는 컬럼 순서가 중요합니다(맨 앞 컬럼부터 접두로만 활용 가능 — leftmost prefix 규칙).

iOS에서는

SQLite는 테이블과 인덱스를 모두 B-tree 계열로 구현합니다. 어떤 인덱스를 쓸지(또는 못 쓸지)는 EXPLAIN QUERY PLAN으로 확인합니다. Core Data에서는 엔티티 속성에 인덱스(fetch index)를 모델 에디터에서 지정하고, 복합 인덱스도 만들 수 있습니다. SwiftData는 @Model에 #Index·#Unique 매크로로 선언합니다. 요점은 어느 계층을 쓰든 결국 바닥의 SQLite 인덱스로 내려간다는 것입니다.

sqlite> EXPLAIN QUERY PLAN SELECT * FROM message WHERE room_id = 42;
--  SCAN message                                    ← 풀 스캔 (O(n))

CREATE INDEX idx_message_room ON message(room_id);

sqlite> EXPLAIN QUERY PLAN SELECT * FROM message WHERE room_id = 42;
--  SEARCH message USING INDEX idx_message_room (room_id=?)   ← 인덱스 탐색 (O(log n))

실험 · 도구

수만 건을 넣은 테이블에서 인덱스 생성 전후로 같은 쿼리의 EXPLAIN QUERY PLAN이 SCAN→SEARCH ... USING INDEX로 바뀌는지 보고, 실제 실행 시간을 잽니다. 반대 실험도 중요합니다 — 인덱스를 여러 개 건 테이블에 대량 INSERT를 돌려 삽입 시간이 인덱스 수에 비례해 늘어나는지 측정하면 "쓰기 비용"이 체감됩니다. Core Data라면 Instruments의 Core Data 템플릿으로 fetch가 실제로 몇 건을 훑는지 관찰합니다.

프로젝트 적용

• 인덱스는 읽기 패턴을 보고 건다. WHERE·ORDER BY·JOIN·외래키에 자주 쓰이는 컬럼이 후보다.
• 복합 인덱스는 컬럼 순서가 성능을 좌우한다. 등호(=)로 걸리는 컬럼을 앞에, 범위·정렬용 컬럼을 뒤에 두고, 여러 쿼리에서 공통으로 쓰이는 컬럼을 선두에 둔다(leftmost prefix). "선택도 높은 컬럼을 무조건 앞에"는 흔한 미신이니 실제 쿼리 조건 모양에 맞춘다.
• 쓰기가 압도적으로 많은 테이블(로그·이벤트 적재)에 불필요한 인덱스를 남발하지 않는다.

꼬리 질문

• 커버링 인덱스(covering index)가 뭐고, 언제 테이블 접근 자체를 없앨 수 있나요?
• WHERE a = ? AND b > ? 쿼리에 (a, b) 인덱스는 잘 쓰이는데 (b, a)는 왜 그만큼 못 쓰이나요? (두 조건이 모두 등호라면 순서가 성능을 가르지 않는 이유도 함께)
• 인덱스가 오히려 안 쓰이는 게 나은 경우(테이블이 아주 작거나, 결과가 테이블의 대부분일 때)는 왜 그런가요?

Q4. Migration은 왜 필요하며 실패에 어떻게 대비하는가?

CS 원리

데이터베이스 스키마는 시간이 지나며 진화합니다(schema evolution). 문제는 코드는 배포로 한 번에 교체되지만 데이터는 각 기기에 과거 버전 그대로 남아 있다는 점입니다. 마이그레이션은 "버전 N의 데이터 → 버전 N+1의 스키마"로 변환하는 함수입니다. 안전한 마이그레이션의 조건은 (1) 원자성 — 성공하면 새 스키마, 실패하면 원본 그대로여야 하고 반쪽 변환 상태가 남으면 안 됩니다. (2) 단조 전진 — 보통 롤백(다운 마이그레이션)은 유실 없이 되돌릴 수 없어 앞으로만 갑니다. (3) 멱등/재개 가능성 — 도중에 실패해도 다시 실행할 수 있어야 합니다. 대량 데이터 변환은 메모리·시간이 커서, 여러 버전을 한 번에 건너뛰기보다 중간 단계를 거쳐(staged) 옮기는 편이 안전합니다.

iOS에서는

Core Data는 변경이 단순하면(속성 추가, 엔티티/관계 추가·삭제, renaming identifier로 이름 변경) lightweight migration으로 매핑을 자동 추론합니다 — NSMigratePersistentStoresAutomaticallyOption·NSInferMappingModelAutomaticallyOption을 켭니다. 속성 분해·병합처럼 추론 불가한 변경은 .xcmappingmodel과 NSEntityMigrationPolicy로 heavyweight migration을 씁니다. SwiftData는 SchemaMigrationPlan과 VersionedSchema로 버전을 명시하고, 각 MigrationStage를 .lightweight 또는 .custom(before/after 클로저)으로 정의합니다. 순수 SQLite/GRDB라면 PRAGMA user_version이나 GRDB의 DatabaseMigrator로 버전을 추적하며 ALTER TABLE을 순서대로 적용합니다.

enum SchemaV1: VersionedSchema {
    static var versionIdentifier = Schema.Version(1, 0, 0)
    static var models: [any PersistentModel.Type] { [Trip.self] }
}
enum SchemaV2: VersionedSchema {           // name 을 title 로 분리하는 등 변경
    static var versionIdentifier = Schema.Version(2, 0, 0)
    static var models: [any PersistentModel.Type] { [Trip.self] }
}

enum TripMigrationPlan: SchemaMigrationPlan {
    static var schemas: [any VersionedSchema.Type] { [SchemaV1.self, SchemaV2.self] }
    static var stages: [MigrationStage] {
        // 자동 추론 가능하면 lightweight, 데이터 가공이 필요하면 .custom(before:after:)
        [ .lightweight(fromVersion: SchemaV1.self, toVersion: SchemaV2.self) ]
    }
}

실험 · 도구

회귀 방지의 핵심은 구버전 store 파일을 테스트 픽스처로 보관하는 것입니다. v1 시절의 실제 .sqlite를 테스트 번들에 넣어두고, 최신 코드로 열어 마이그레이션이 성공하고 데이터가 보존되는지 자동 테스트로 검증합니다. 실기기에서는 이전 버전 앱으로 데이터를 만든 뒤 새 빌드를 덮어 설치해 콜드스타트에서 크래시 없이 열리는지 확인합니다. 관찰 지표: 마이그레이션 소요 시간(대량 데이터에서 앱 시작 지연·워치독 종료 위험), 성공/실패율(원격 로깅).

프로젝트 적용

• 마이그레이션 직전에 store 파일을 백업하고, 실패 시 백업으로 복원한 뒤 재시도하거나 사용자에게 알린다. 그냥 스토어를 지워버리는 fallback은 데이터 유실이니 최후수단으로만.
• 큰 변환은 메인 스레드에서 하지 않는다. 시작 화면을 막고 백그라운드에서 진행 상태를 노출한다.
• 버전을 건너뛰는 업그레이드(v1→v5)를 반드시 테스트한다. 실제 사용자는 몇 버전을 건너뛰고 온다.
• 다운그레이드는 지원하지 않는 걸 전제로 설계한다(앞으로만 전진). 필요하면 새 필드는 nullable/기본값으로 추가해 하위 호환을 열어둔다.

꼬리 질문

• 사용자가 v1에서 v5로 한 번에 올라올 때 순차(staged) 마이그레이션과 직접 매핑 중 무엇을, 왜 택하나요?
• 마이그레이션 도중 앱이 강제 종료되면 다음 실행에서 무슨 일이 벌어지나요? 재개 가능하게 하려면?
• 서버 스키마와 로컬 캐시 스키마가 함께 바뀔 때 마이그레이션 순서와 하위 호환은 어떻게 조율하나요?

Q5. Core Data는 Database인가? 어떤 역할을 하는 Framework인가?

CS 원리

객체지향 메모리 모델(포인터로 연결된 객체 그래프)과 관계형 저장(테이블·행·외래키) 사이에는 임피던스 불일치(object-relational impedance mismatch)가 있습니다. 객체 그래프 관리 프레임워크는 이 간극을 메웁니다 — 개발자는 객체와 관계를 다루고, 프레임워크가 (1) 어떤 객체가 바뀌었는지 추적하고, (2) 필요할 때만 디스크에서 채워 넣고(lazy/faulting), (3) 같은 레코드는 메모리에서 한 인스턴스로 유지하며(uniquing/identity map), (4) 변경을 모아 저장소에 반영합니다. 이건 "질의 엔진"의 일이 아니라 "메모리 상태와 저장 상태를 동기화"하는 일입니다. 그래서 Core Data는 DB의 대체가 아니라 DB(또는 다른 저장소) 위의 계층입니다.

iOS에서는

스택은 네 조각입니다. NSManagedObjectModel(스키마, .momd), NSPersistentStoreCoordinator(모델과 저장소를 잇는 중재자), NSManagedObjectContext(변경을 쌓는 작업 공간·scratchpad), 그리고 NSPersistentStore(실제 바이트가 사는 곳). iOS 10부터는 NSPersistentContainer가 이 조립을 대신해 줍니다. 핵심 관찰: 저장소 타입만 바꿔도 앱 코드(객체 그래프 API)는 그대로라는 점이 Core Data가 DB 엔진이 아님을 드러냅니다.

let container = NSPersistentContainer(name: "Model")
let desc = container.persistentStoreDescriptions.first!

// 저장소를 통째로 바꿔도 위층 코드(fetch/insert/save)는 그대로다.
desc.type = NSInMemoryStoreType     // 테스트용 (또는 NSSQLiteStoreType / NSBinaryStoreType)

container.loadPersistentStores { _, error in
    if let error { fatalError("store load 실패: \(error)") }
}
// → Core Data 는 "무엇으로 저장하느냐"와 "객체를 어떻게 다루느냐"를 분리한다.

프로젝트 적용

• "복잡한 조인·집계·리포팅 쿼리가 중심"인 요구라면 Core Data보다 SQLite/GRDB의 직접 SQL이 잘 맞을 수 있다. Core Data의 강점은 객체 그래프·관계·UI 연동(NSFetchedResultsController)이다.
• 테스트에서는 in-memory 스토어로 갈아끼워 디스크 없이 빠르게 돌린다. (기능을 온전히 쓰려면 NSInMemoryStoreType 대신 store URL을 /dev/null로 둬 SQLite in-memory로 여는 방식도 흔히 쓴다.)
• Core Data를 "그냥 DB"로 취급해 raw SQL 감각으로 접근하면 faulting·context 수명·저장 타이밍에서 버그가 난다. 프레임워크의 모델을 존중한다.

꼬리 질문

• faulting(fault)이 뭐고, 이게 왜 "Core Data는 DB가 아니다"라는 성격과 연결되나요?
• SwiftData는 Core Data와 어떤 관계인가요? 내부적으로 무엇을 공유하나요?
• 같은 요구를 GRDB(직접 SQL)로 풀 때와 Core Data로 풀 때, 결정을 가르는 기준은 무엇인가요?

Q6. Core Data의 Context는 Thread-safe한가?

CS 원리

동시성을 다루는 방법에는 락(공유 가변 상태를 잠금)과 confinement(가변 상태를 하나의 실행 맥락에 가둬 애초에 공유하지 않음)가 있습니다. Core Data는 후자를 택합니다. 컨텍스트는 변경을 쌓아두는 가변 상태 덩어리라, 여러 스레드가 동시에 건드리면 내부 자료구조가 깨집니다. 그래서 "이 컨텍스트에 대한 모든 접근은 지정된 하나의 큐에서 직렬로"라는 규칙을 강제하고, perform은 작업을 그 큐에 넣는 관문입니다. 데이터를 다른 맥락으로 옮길 때 객체 자체는 특정 컨텍스트에 종속되므로 옮길 수 없고, 영속 식별자(어느 컨텍스트에서도 같은 레코드를 가리키는, 불변이고 스레드 안전한 식별자 — NSObject 서브클래스인 참조 타입)만 안전하게 넘어갑니다.

iOS에서는

컨텍스트는 생성 시 concurrency type을 정합니다. .mainQueueConcurrencyType(UI용, container.viewContext)과 .privateQueueConcurrencyType(백그라운드용, newBackgroundContext() 또는 performBackgroundTask). 어느 쪽이든 접근은 NSManagedObjectContext의 perform(_:)/performAndWait(_:)로 감쌉니다. main 컨텍스트조차 예외는 UI 코드가 이미 main에서 도는 경우일 뿐, 원칙은 "그 컨텍스트의 큐 위에서". 변경을 컨텍스트 간에 반영하려면 automaticallyMergesChangesFromParent나 NSManagedObjectContextDidSave 알림을 씁니다. 자세한 패턴은 Using Core Data in the Background에 정리돼 있습니다.

let bg = container.newBackgroundContext()
let objectID = person.objectID          // main 컨텍스트의 객체에서 ID만 추출 (불변·스레드 안전, 넘기기 안전)

bg.perform {                            // 반드시 이 컨텍스트의 큐 위에서 실행
    guard let obj = try? bg.existingObject(with: objectID) else { return }
    obj.setValue("done", forKey: "status")
    try? bg.save()                      // 이 save() 가 하나의 트랜잭션
}

// ❌ 절대 금지: 다른 스레드에서 만든 NSManagedObject 를 그대로 참조
// DispatchQueue.global().async { print(person.name) }   // objectID 아님 → 크래시/데이터 손상

실험 · 도구

규칙 위반을 런타임에 크래시로 잡아주는 도구가 있습니다. 스킴의 실행 인자에 -com.apple.CoreData.ConcurrencyDebug 1을 추가하면, 컨텍스트를 잘못된 큐에서 만지는 순간 즉시 트랩이 걸립니다. 개발·CI에서 항상 켜 두면 confinement 위반을 조기에 발견합니다. 여기에 Thread Sanitizer를 함께 켜면 Core Data 밖의 데이터 레이스도 잡힙니다. 관찰 지표: ConcurrencyDebug 트랩 스택트레이스가 가리키는 "큐 밖 접근" 지점.

프로젝트 적용

• 컨텍스트를 지역 변수로 붙잡아 아무 스레드에서나 쓰지 않는다. 접근은 항상 그 컨텍스트의 perform 안에서.
• 스레드 경계를 넘길 땐 NSManagedObject가 아니라 objectID를 넘기고, 상대 컨텍스트에서 existingObject(with:)로 재조회한다.
• UI는 viewContext(main), 쓰기·import는 background 컨텍스트로 분리하고, 변경 병합 정책(mergePolicy)을 명시한다.
• 개발/CI 빌드에 -com.apple.CoreData.ConcurrencyDebug 1을 상시 켠다.

꼬리 질문

• 임시 objectID와 영구 objectID의 차이는? obtainPermanentIDs(for:)는 언제 필요한가요?
• parent/child 컨텍스트 구조에서 child의 save()는 어디까지 반영되나요? 디스크에 언제 실제로 쓰이나요?
• SwiftData의 ModelContext·@ModelActor는 이 confinement 문제를 어떻게 다르게(또는 같게) 풉니까?

출처 · 참고자료