PlanAssist: Google DeepMind가 영국 지자체 주택 인허가 심사 시간을 58% 줄인 방식

PlanAssist는 인허가 담당자의 결정은 건드리지 않고, 결정 앞의 서류 검증·정책 대조·보고서 초안을 AI에 맡겨 일반 주택 신청 심사 시간을 58% 줄였습니다. 따라 하려면 반복 비중이 큰 신청 유형 하나를 고르고, 모든 판단에 근거를 인용하게 하고, 담당자가 초안을 얼마나 고쳤는지를 채택 지표로 재야 합니다.

요약

Google DeepMind는 2026년 10월 31일 블로그에서 영국 지방정부용 인허가 심사 도구 PlanAssist의 시범 결과를 공개했습니다. 영국 정부, Google Cloud, 데이터 과학 기업 Faculty와 함께 Gemini로 만든 도구입니다. 대상은 다락 개조, 온실 증축, 주택 증축 같은 householder application(일반 주택 소유자의 소규모 건축 신청)입니다. PlanAssist는 신청 서류와 도면에 필요한 정보가 다 있는지 확인합니다. 그다음 보호수 지정 같은 heritage 제약, 지역·국가 계획 정책, 과거 쟁점과 주민 이의를 대조하고, 근거를 인용한 심사 보고서 초안을 만듭니다. 담당자는 이 초안을 고친 뒤 결정합니다.

2026년 6월부터 Barnet, Camden, Dorset 세 지자체에서 시범을 돌린 결과, 담당자가 일반 주택 신청 1건 심사에 쓰는 평균 시간이 58% 줄었습니다(원문 요약에서는 ‘최대 58%’). 생성된 보고서의 70% 이상은 담당자가 손대지 않고 승인했습니다. 이런 신청은 담당자 업무량의 최대 70%를 차지하지만 판단 자체는 대개 간단합니다. 그래서 준비 작업을 덜어 주면 효과가 크게 납니다. 원문은 이 효과를 영국 정부의 2029년까지 신규 주택 150만 호 목표와 연결합니다. 아래에서는 PlanAssist가 무엇을 맡고 무엇을 남기는지, 같은 구조를 다른 심사 업무에 옮길 때 무엇이 필요한지 차례로 봅니다.

핵심 메커니즘

Householder Application: 반복 비중이 가장 큰 신청 유형부터

PlanAssist는 모든 인허가 신청을 다루지 않습니다. 첫 대상은 일반 주택 소유자의 소규모 신청 하나입니다. 원문에 따르면 이 유형은 담당자 업무량의 최대 70%를 차지하고 대부분 승인하기 쉬운데도, 난이도에 비해 시간을 많이 먹습니다. 건수가 많고 판단 규칙이 비교적 정해진 유형이라 AI가 사전 작업을 맡기 좋습니다. 대형 개발 사업처럼 협의와 재량이 큰 신청은 이번 범위에 들지 않습니다. 작은 예시(가상): 구청 건축 인허가 팀이라면 단독주택 증축과 용도 변경 없는 대수선 신고처럼 건수가 많고 서식이 정해진 유형부터 고르는 식입니다.

Automated Groundwork: 결정 전 준비 작업을 다섯 단계로

PlanAssist가 맡는 일은 결정 앞의 준비 작업입니다. 원문 설명을 단계로 나누면 다섯입니다. 먼저 신청서와 도면에 필수 정보가 들어 있는지 확인합니다(validation). 이어 신청지가 heritage 제약, 예컨대 TPO(Tree Preservation Order, 보호수 지정)에 걸리는지 봅니다. 셋째로 지역 계획 규칙과 국가 정책에 맞는지 대조하고, 넷째로 같은 부지에 예전 쟁점이나 주민 이의가 있었는지 찾습니다. 마지막으로 이 결과를 근거와 함께 엮어 권고안이 담긴 보고서 초안을 씁니다. 담당자가 직접 하던 서류 확인과 규정 찾기가 여기에 모두 들어갑니다.

Fully Cited Report: 근거가 달린 초안과 수정 없는 승인 비율

PlanAssist의 산출물은 판단이 아니라 fully cited report(모든 판단에 근거를 인용한 보고서) 초안입니다. 담당자는 초안의 각 판단이 어느 정책과 서류에 기댔는지 보고 고치거나 그대로 승인합니다. 시범에서는 정책 준수 여부와 서류 완비 여부를 다룬 보고서의 70% 이상이 수정 없이 승인됐습니다. 이 비율은 AI 산출물이 실제 업무에 얼마나 채택되는지 보여 줍니다. 시간 절감만 재면 담당자가 초안을 대충 넘겨도 수치가 좋아 보입니다. 수정 없이 승인한 비율을 함께 보면 초안의 품질을 따로 확인할 수 있습니다.

Officer Final Say: 모든 신청의 결정은 담당자에게

원문은 모든 신청에서 최종 결정을 담당자가 한다고 거듭 밝힙니다. 모든 평가는 자격을 갖춘 담당자가 검토하고 승인해야 결정으로 넘어갑니다. 인허가는 행정 처분이어서 결정 책임을 사람에게 두어야 이의 제기와 감사에 답할 수 있습니다. 결정을 사람이 하는데도 시간이 절반 넘게 줄었다면, 줄어든 몫은 결정 앞의 준비 작업입니다. 원문은 그 결과 담당자가 전문성이 가장 필요한 곳에 집중할 수 있다고 설명합니다.

Pilot to Scale: 3곳 시범, 15곳 Beta, 그다음 전국

확대는 단계를 밟습니다. 세 지자체 시범 다음은 live application(실제로 접수된 신청)으로 돌리는 12개월 Beta입니다. 일부 지자체로 시작해 12곳을 세 cohort(동시에 합류하는 묶음)로 나눠 들이고, 모두 15곳까지 넓힙니다. 대도시권과 농촌 지역을 섞어 서로 다른 지역 사정에서 시험합니다. 이 시험이 성공하면 정부는 2027년에 잉글랜드 모든 지자체에 PlanAssist를 제공할 계획입니다. 지역마다 정책 문서와 신청 패턴이 다르기 때문에, 확대 단계에서도 지역 단위로 성능을 다시 확인합니다.

통념과 다른 주장

저자가 든 사례

Barnet·Camden·Dorset 시범

• 상황: 다락 개조, 온실, 증축 같은 작은 공사도 승인까지 수개월이 걸리기도 합니다. 이런 신청이 담당자 업무량의 최대 70%를 차지합니다.
• 한 일: 2026년 6월부터 세 지자체가 일반 주택 신청 심사에 PlanAssist를 씁니다. 서류 검증, 제약·정책·이력 대조, 인용 보고서 초안을 AI가 맡습니다.
• 결과: 담당자 평균 심사 시간 58% 감소, 생성 보고서 70% 이상 수정 없이 승인. 시범 건수와 측정 방법은 원문에서 밝히지 않았습니다.
• 연결: Householder Application, Automated Groundwork, Fully Cited Report.

12개월 Beta와 전국 확대 계획

• 상황: 시범은 세 지자체에 그쳤습니다.
• 한 일: 실제 접수 신청으로 12개월 Beta를 돌리며, 12곳을 세 cohort로 추가합니다. 대도시권과 농촌을 함께 넣습니다.
• 결과: 계획 단계입니다. 모두 15개 지자체에서 시험하고, 성공하면 2027년 잉글랜드 전 지자체에 제공합니다.
• 연결: Pilot to Scale, Officer Final Say.

기술 디테일: 심사 보고서 초안 도구를 직접 만든다면

아래 필드명, 설정값, 기준은 실제로 돌릴 때 필요한 것을 정리한 실행 제안이자 가상 예시이며, PlanAssist의 실제 구현으로 원문이 밝힌 내용이 아닙니다. 원문이 밝힌 것은 Gemini 기반이라는 점과 다섯 가지 작업, 인용 보고서 형식까지입니다.

Automated Groundwork의 판정을 둘로 나누려면 답이 정해진 판정은 LLM에 맡기지 않습니다. 신청지가 보호수 지정이나 보존 구역에 걸리는지는 지자체가 가진 지도 데이터를 주소·필지로 조회하면 나옵니다. 필수 서류 목록 대조도 규칙표로 끝납니다. LLM은 도면과 설명서에서 증축 높이·깊이 같은 값을 읽어 내고, 정책 조항과 사안을 맞대어 서술하는 일에 씁니다. 이렇게 나누면 제약 판정이 틀렸을 때 원인을 데이터에서 바로 찾을 수 있습니다.

Fully Cited Report를 구조화 출력으로 받으려면 보고서를 자유 서술로 받지 않고 판단 항목(finding) 단위 JSON으로 받습니다. finding마다 근거 문서와 위치를 반드시 넣게 하고, 근거가 없으면 status를 needs_officer로 두게 합니다. 정책 문서는 조항 단위로 잘라 색인하고, 조항마다 판본과 시행일을 붙여 검색합니다. 그래야 정책이 개정됐을 때 옛 조항을 인용하는 일을 막을 수 있습니다. temperature는 0으로 두고 같은 신청을 2회 생성해 recommendation이 다른 건은 담당자 확인 목록에 올립니다.

{
  "application_id": "HH-2026-04217",
  "type": "householder / rear extension",
  "validation": {"complete": false, "missing": ["floor_plan_existing"]},
  "constraints": [{"name": "TPO", "hit": false, "source": "gis:tpo_layer 2026-10-01"}],
  "findings": [
    {"topic": "depth_of_extension", "assessment": "지역 기준 이내",
     "citations": [{"doc": "local_plan_v3", "clause": "D4.2", "effective": "2025-04-01"},
                   {"doc": "drawing_02.pdf", "page": 1}],
     "status": "drafted"},
    {"topic": "neighbour_objection", "assessment": "2024년 일조 이의 1건 확인",
     "citations": [{"doc": "history:2024-0311"}], "status": "needs_officer"}
  ],
  "recommendation": "approve_with_conditions",
  "model_version": "gemini-x / prompt-v7",
  "runs_agree": true
}

수정 없이 승인한 비율을 재려면 담당자가 초안을 고칠 때마다 finding 단위로 수정 전후 diff와 사유 코드(사실 오류, 인용 오류, 정책 해석, 표현만 수정)를 남깁니다. 보고서 단위 무수정 승인율은 원문의 70%와 비교할 수 있는 지표이고, finding 단위 수정률은 어느 판단 유형이 약한지 알려 줍니다. 표현만 고친 건은 품질 문제와 따로 셉니다. 무수정 승인율이 몇 주째 100%에 가깝다면 담당자가 검토를 건너뛰는지 표본을 다시 심사해 확인합니다.

막히는 경우	증상	대응
도면이 스캔 이미지	치수를 잘못 읽음	치수 값은 신뢰도 낮으면 needs_officer로, 원본 위치를 함께 표시
정책 개정	옛 조항 인용	조항에 시행일을 달고 신청 접수일 기준으로만 검색
지역마다 다른 정책	한 지역에서 맞던 판단이 다른 지역에서 틀림	지자체별 정답 세트로 따로 평가, 지역별 수정률 비교
인용이 있으나 내용과 무관	조항 번호만 그럴듯함	인용 조항 원문과 assessment를 대조하는 검증 호출 추가
형식적 승인	무수정 승인율이 비정상적으로 높음	주 단위 무작위 표본 재심사

현업 실행 디테일: 누가, 언제, 무엇을

PlanAssist 구조를 우리 조직의 심사 업무(구매 계약 검토, 설계 변경 승인, 사내 규정 심사 등)에 옮길 때의 가상 예시입니다.

역할	맡는 일
심사 부서장	대상 신청 유형 선정, 시범 진행 여부 결정
선임 심사자 2~3명	판단 항목(finding) 목록과 정답 세트 작성, 초안 검수
규정·정책 담당	정책 문서를 조항 단위로 정리, 개정 이력 관리
데이터·GIS 또는 마스터 데이터 담당	규칙 조회용 데이터(제약 목록, 이력) 연결
AI 엔지니어 1~2명	검색 색인, 구조화 출력, 편집 diff 로그 구축
법무·감사	최종 결정자 규칙과 기록 보존 기준 승인

준비물. 대상 유형의 최근 결정 완료 건 100~200건과 담당자가 쓴 실제 심사 보고서, 건별 접수·결정 시각, 적용 정책·규정 원문과 개정 이력, 과거 이의·쟁점 기록, 데이터 외부 반출 기준이 필요합니다.

기간	할 일	산출물
1~2주	30건을 재 기준선 측정, 신청 유형과 finding 목록 합의	단계별 시간표, finding 정의서
3~4주	정답 세트 100건으로 초안 생성 시험, 인용 정확도 확인	finding별 일치율, 인용 오류 목록
5~7주	섀도 운영: 담당자는 기존대로 심사하고 초안을 나란히 비교	건당 시간 비교, 무수정 승인율, 수정 사유 분포
8주	판정 회의, 다음 유형이나 다음 부서 후보 선정	진행·보완·중단 결정서

현업에 물을 것.

1. 이 유형의 신청은 전체 건수의 몇 %이고, 1건에 준비 작업과 판단에 각각 몇 분을 쓰나요?
2. 판단 근거로 가장 자주 찾아보는 규정과 데이터는 무엇이고, 어디에 있나요?
3. 서류 누락으로 반려하는 비율은 얼마이고, 어떤 서류가 가장 자주 빠지나요?
4. 담당자가 보고서에 반드시 근거를 남겨야 하는 판단은 어느 것인가요?
5. 이의 제기나 감사가 들어오면 어떤 기록을 내놓아야 하나요?

진행 판정 기준(예시). 섀도 운영에서 결정 전 준비 시간이 기준선보다 50% 이상 줄고, 보고서 단위 무수정 승인율이 60% 이상이며, 인용 오류가 finding의 2% 미만이면 실제 운영으로 넘어갑니다. 무수정 승인율이 40~60%면 수정 사유가 몰린 finding을 보강해 2주 더 봅니다. 그 아래면 신청 유형을 더 좁혀 다시 설계합니다. 어떤 경우에도 결정 기록이 담당자 이름으로 남지 않으면 확대하지 않습니다.

AX 적용 제언. 기업 안에도 인허가와 닮은 일이 많습니다. 구매 품의, 계약 검토, 설계 변경 승인, 신규 거래처 심사처럼 서류를 받아 규정에 비추어 판단하는 업무입니다. 출발점은 PlanAssist와 같습니다. 건수가 가장 많고 판단이 가장 단순한 유형 하나를 고르고, 결정권은 그대로 둔 채 준비 작업만 AI에 넘깁니다. 성과 보고에는 시간 절감과 함께 무수정 승인율을 넣어야 경영진이 품질까지 판단할 수 있습니다. 확대할 때는 PlanAssist가 지역을 섞어 Beta를 돌리듯, 다른 사업장·법인에서 같은 지표를 다시 재고 넘어갑니다.

원문 사례

항목	내용
원문	Google DeepMind 블로그 「Speeding up planning decisions with AI」(2026.10.31), Owen Larter, David Thacker
도구	PlanAssist, Gemini 기반 인허가 심사 지원 도구
개발 참여	Google DeepMind, 영국 정부, Google Cloud, Faculty
대상	householder application(다락 개조, 온실, 증축 등), 담당자 업무량의 최대 70%
하는 일	서류·도면 필수 정보 검증, heritage 제약(보호수 지정 등) 확인, 지역·국가 정책 대조, 과거 쟁점·주민 이의 확인, 인용이 달린 보고서·권고안 초안
시범	Barnet, Camden, Dorset, 2026년 6월부터
결과	담당자 평균 심사 시간 58% 감소(요약 표현 ‘최대 58%’), 생성 보고서 70% 이상 수정 없이 승인
사람 역할	모든 신청의 최종 결정은 담당자, 모든 평가는 자격 있는 담당자의 검토·승인 필요
확대 계획	live 신청으로 12개월 Beta, 12곳을 3개 cohort로 추가해 총 15곳(대도시권·농촌), 성공 시 2027년 잉글랜드 전 지자체 제공
정책 맥락	영국 정부의 2029년까지 신규 주택 150만 호 목표

핵심 개념

householder application

주택 소유자가 자기 집을 증축하거나 개조할 때 내는 소규모 건축 인허가 신청입니다.

planning officer

지자체에서 인허가 신청을 심사하고 승인 여부를 정하는 담당 공무원입니다.

Tree Preservation Order (TPO)

지자체가 특정 나무나 숲을 보호 대상으로 지정해 함부로 베거나 훼손하지 못하게 하는 명령입니다.

validation

심사를 시작하기 전에 신청서와 도면에 필수 정보가 빠짐없이 들어 있는지 확인하는 단계입니다.

Beta

시범이 끝난 뒤 실제 접수 건으로 더 많은 기관에서 돌려 보는 정식 출시 전 단계입니다.

cohort

같은 시점에 함께 합류해 같은 일정으로 도입하는 기관 묶음입니다.

내 메모

TODO: 내 생각 추가

원문은 Google DeepMind 블로그의 「Speeding up planning decisions with AI」(Owen Larter, David Thacker, 2026.10.31)입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 58%와 70% 같은 수치는 시범에 대한 원문 발표이며, 다섯 단계 구분은 원문 설명을 단계로 재구성한 것입니다. TPO와 householder application의 뜻풀이는 영국 제도의 일반적 정의로 보탰습니다. 기술·현업 실행 디테일, JSON 예시, 막히는 경우 표, 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전문은 원문 페이지에서 볼 수 있습니다.