공공데이터로 지역 장례 콘텐츠 자동 생성 파이프라인 구축

공공데이터를 붙여서 실제 지역 기반 콘텐츠를 자동 생성하는 파이프라인을 붙였다.

왜 실데이터인가

처음에는 목업 데이터로 글 생성 파이프라인 전체 흐름을 먼저 잡았다. 구조가 어느 정도 잡히고 나면 실데이터로 교체하면 된다는 판단이었는데, 막상 공공데이터를 붙이고 나니 예상 외의 지점들이 튀어나왔다. 지역명 표기 불일치, 누락 필드, 데이터 품질 편차 같은 문제들이다. 목업 단계에서는 보이지 않던 것들이 실데이터를 넣는 순간 드러나기 마련이다. 이게 사실 실데이터 연동을 "일찍 붙이는 게 좋다"는 근거이기도 하다. 파이프라인이 깔끔하게 돌더라도 데이터가 지저분하면 결과물도 지저분해지기 때문에, 데이터 정제 로직은 생성 로직보다 오히려 먼저 다듬어야 하는 경우가 많다.

파일별 역할 분리

변경된 파일이 세 개인데, 각자 역할이 명확하게 나뉜다.

funeral_realdata.py가 중간 어댑터 역할을 하고 있다는 게 포인트다. JSON을 그대로 generate.py에 넘기지 않고, 한 번 정제/변환 레이어를 두는 구조는 나중에 공공데이터 포맷이 바뀌거나 다른 데이터 소스가 추가될 때 generate.py를 건드리지 않아도 된다는 장점이 있다. 파이프라인을 팀에서 같이 유지보수할 때 이런 레이어 분리가 실질적인 비용 절감으로 이어진다.

지역 가이드 글 생성 파이프라인

실제 흐름을 단순화하면 이렇다.

# funeral_realdata.py (개념 예시)
def load_region_data(json_path: str) -> list[dict]:
    with open(json_path, encoding="utf-8") as f:
        raw = json.load(f)
    return [normalize_record(r) for r in raw]

def normalize_record(record: dict) -> dict:
    return {
        "region": record.get("지역명", "").strip(),
        "address": record.get("주소", ""),
        "facilities": record.get("시설정보", []),
        # 공공데이터 필드명 → 내부 스키마 매핑
    }

# generate.py (개념 예시)
regions = load_region_data("funeral_realdata.json")
for region in regions:
    prompt = build_prompt(region)
    article = llm_generate(prompt)
    save_article(region["region"], article)

이렇게 데이터 로딩 → 정제 → 프롬프트 빌드 → 생성 → 저장을 단계별로 분리해두면 각 단계를 독립적으로 테스트할 수 있다. 프롬프트 품질을 개선할 때 데이터 파이프라인을 다시 돌리지 않아도 되고, 데이터가 바뀌었을 때 생성 로직을 바꾸지 않아도 된다.

회고

공공데이터 기반 콘텐츠 자동화는 생각보다 데이터 정제에 시간이 많이 들어간다. "데이터 준비됐으니 생성 로직만 짜면 되겠다"는 예상은 거의 항상 틀린다. 이번에도 실데이터를 붙이고 나서 지역명 중복, 좌표 누락, 특수문자 섞인 시설명 같은 엣지케이스들을 하나씩 처리했다. 그래서 데이터 정제 로직을 별도 파일(funeral_realdata.py)로 분리한 게 잘한 선택이었다고 생각한다. 나중에 "이 지역 데이터 왜 이상하게 나와?" 하는 이슈가 들어올 때 어디를 봐야 하는지 명확해지기 때문이다.

팀 차원에서는, 글 생성 결과물의 품질을 사람이 직접 샘플링해서 검수하는 루틴을 초기부터 세팅해두는 게 중요하다. 자동 생성이 아무리 잘 돌아도 "이 지역은 왜 잘못 된 정보가 들어갔지?"를 발견하는 건 결국 사람의 눈이다. 파이프라인 자동화와 인간 검수를 같이 설계해야 한다는 점, 이번 작업에서 다시 확인했다.

다음은 생성된 글의 품질 지표를 어떻게 정량화할지 고민할 차례다.