최근 데이터 엔지니어링을 공부하면서 원본 데이터를 별도로 저장 하는 기준에 대해 고민하게 되었고, 생각을 정리하기 위해 글을 작성하게 되었습니다.
1. 왜 고민을 하게 되었을까?
공공 데이터 포털의 데이터를 저장하는 작업을 하면서 원본 데이터를 저장할지 에 대한 고민이 생겼습니다. PG사에서 들어오는 결제 데이터는 금전과 직접 연결되어 있고 정산 기준 변경이나 이슈 발생 시 과거 내역을 그대로 확인해야 하기 때문에 원본을 남기는 것이 당연합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"transactionId": "TXN-20260215-000123",
"orderId": "ORD-998877",
"pgProvider": "TossPayments",
"method": "CARD",
"amount": 129000,
"currency": "KRW",
"approvedAt": "2026-02-15T10:12:33Z",
"card": {
"issuerCode": "11",
"acquirerCode": "31",
"installmentMonths": 3
},
"status": "DONE",
"rawResponseCode": "0000"
}
하지만 상권 정보나 업종 분류 같은 데이터는 우리 서비스에 맞게 정제해서 사용 해야 하는데, 굳이 원본 파일까지 그대로 저장해두어야 할까 하는 생각이 들었습니다. 가공된 결과만 있어도 충분해 보였기 때문입니다.
1
2
3
4
5
6
7
8
9
10
11
12
[
{
"code": "G20201",
"middle_code": "G202",
"name": "타이어 소매업"
},
{
"code": "G20202",
"middle_code": "G202",
"name": "자동차 부품 소매업"
}
]
2. 원본 데이터를 별도로 저장해야 하는 경우
이 과정에서 판단의 기준이 필요했는데요. 저는 해석 가능성, 재현 필요성 크게 두 가지 관점으로 이를 분류했습니다. 지금은 단순 참조 데이터처럼 보여도 분류 체계나 기준이 바뀌면 과거 데이터를 다시 해석해야 할 수 있고, 배치 오류나 누락이 발생하면 동일한 입력값을 기준으로 재처리해야 할 수도 있으니까요. 물론 일회성 데이터라면 크게 고민할 필요가 없겠죠?
- 아니면 나중에 다시 해석하거나 재처리해야 할 가능성이 있는 데이터인가?
- 이 데이터는 한 번 가공하고 끝나는 데이터인가?
조금 더 구체적으로 보면 다음과 같습니다.
- 해석이 바뀔 가능성이 있는 경우
- 동일한 사실을 여러 방식으로 해석해야 하는 경우
- 과거를 다시 해석해야 할 가능성이 있는 경우
2-1. 해석이 바뀔 가능성이 있는 경우
원본 데이터는 그 시점에 발생한 사실입니다. 반면 우리가 저장하는 가공 데이터는 그 사실에 특정 규칙을 적용해 만들어진 결과입니다. 즉, 가공 데이터에는 해석이 들어갑니다. 예를 들어, PG로부터 결제 응답이 내려왔다고 가정해 보겠습니다. PG가 보내준 결제 금액, 승인 시각, 카드사 코드 같은 값들은 원본 데이터입니다. 이것은 그 시점에 실제로 발생한 거래 사실입니다.
1
2
3
4
5
6
7
8
9
10
11
// PG가 내려준 원본 데이터 (사실)
{
"transactionId": "TXN-20260215-000123",
"orderId": "ORD-998877",
"amount": 100000,
"currency": "KRW",
"approvedAt": "2026-02-15T10:12:33Z",
"cardCompanyCode": "11",
"installmentMonths": 3,
"status": "DONE"
}
하지만 우리가 수수료율을 적용하고 VAT를 계산하는 순간, 데이터는 단순 사실이 아닌 해석 결과가 됩니다. 기준이 바뀌면 과거 데이터를 다시 계산해야 할 수 있고, 이때 원본이 없다면 동일한 사실을 기준으로 재해석하기 어렵기 때문입니다. 예를 들어, 비즈니스 정책이 변경 돼서 수수료율이 3.2%에서 3.0%로 변할 수 있겠죠?
1
2
3
4
5
6
7
8
9
10
// 우리가 정책을 적용해 만든 가공 데이터 (해석)
{
"orderId": "ORD-998877",
"paymentAmount": 100000,
"commissionRate": 0.032,
"commissionAmount": 3200,
"vatAmount": 320,
"settlementAmount": 96480,
"settlementStatus": "READY"
}
2-2. 동일한 사실을 여러 방식으로 해석해야 하는 경우
예를 들어 원장에 기록된 “2026년 2월 15일에 100,000원이 결제되었다 라는 사건” 은 변하지 않습니다. 하지만, 이 하나의 사실을 어떤 목적에서 바라보는지에 따라 전혀 다른 결과가 만들어집니다. 정산 관점에서는 수수료와 VAT를 계산해 실제 지급 금액을 산출해야 하고, 통계 관점에서는 해당 주문을 어느 기간 매출에 포함할지 결정해야 하며, 리포트 관점에서는 상품별·카테고리별 집계 형태로 재구성해야 합니다. 이처럼 해석이 여러 개가 될 수 있는 경우, 원본 데이터를 기준점으로 두고, 각 목적에 맞는 해석 결과를 별도로 생성해야 합니다.
1
2
3
4
5
6
7
8
9
10
// 원본 주문 데이터 (사실)
{
"orderId": "ORD-998877",
"userId": "USER-01",
"productId": "PROD-100",
"amount": 100000,
"approvedAt": "2026-02-15T10:12:33Z",
"status": "DONE"
}
1
2
3
4
5
6
7
8
9
// 정산 기준으로 해석한 데이터
{
"orderId": "ORD-998877",
"paymentAmount": 100000,
"commissionRate": 0.03,
"commissionAmount": 3000,
"vatAmount": 300,
"settlementAmount": 96700
}
1
2
3
4
5
6
7
8
// 통계 기준으로 해석한 데이터
{
"orderId": "ORD-998877",
"statMonth": "2026-02",
"includeInRevenue": true,
"category": "ELECTRONICS",
"dailyRevenue": 100000
}
2-3. 재처리
원본 데이터를 별도로 저장해야 하는 또 다른 이유는 해석 변경 때문이 아니라, 처리 과정을 재실행해야 할 가능성이 있기 때문입니다. 배치 로직에 버그가 있었거나, 일부 데이터가 누락되었거나, 장애로 집계가 중단되었다면 이미 만들어진 결과를 수정하는 것이 아니라 동일한 입력값을 기준으로 다시 계산하는 것이 안전합니다. 이때 기준이 되는 것은 가공 결과가 아니라 원본 데이터입니다. 예를 들어 하루 매출을 집계하는 배치가 실행되었는데, 특정 시점 이후 데이터가 누락된 상태로 완료되었다고 가정해 보겠습니다.
1
2
3
4
5
6
7
// 원본 주문 데이터 (사실)
{
"orderId": "ORD-998877",
"amount": 100000,
"approvedAt": "2026-02-15T10:12:33Z",
"status": "DONE"
}
1
2
3
4
5
// 장애로 일부만 반영된 집계 결과
{
"statDate": "2026-02-15",
"dailyRevenue": 4500000
}
나중에 확인해보니 10시 이후 주문이 집계에서 누락된 상태였습니다. 이 경우 집계 결과의 숫자만 보정하는 것이 아니라, 해당 날짜의 원본 주문 데이터를 기준으로 배치를 다시 실행해야 합니다. 이처럼 재처리가 필요한 상황에서는 가공 결과가 아니라 원본 데이터가 기준점이 됩니다. 원본이 없다면 동일한 조건으로 다시 계산하는 것이 불가능합니다.
1
2
3
4
5
// 원본 기준으로 재집계한 결과
{
"statDate": "2026-02-15",
"dailyRevenue": 5200000
}
3. 정리
해석이 거의 개입되지 않고 기준 변경이나 재처리 가능성이 없는 데이터라면 굳이 원본과 가공을 분리할 필요는 없습니다. 또한 일회성 데이터라도 그렇겠죠. 분류 기준은 사람마다, 상황마다 다를 수 있기 때문에 적절하게 기준을 잘 세워서 판단합시다.