건축 법규 제출 요구사항,
1,000페이지에 묻혀 있다

3주 후에야 드러나는 누락

누락된 제출 요구사항은 누락된 순간에 발견되는 경우가 거의 없습니다. 오랜 리드 타임이 필요한 항목이 제작 단계에 도달했는데 아무도 제작도를 승인하지 않았을 때, 또는 검토자가 제출된 적 없는 증명서를 요청할 때 비로소 표면화됩니다. 상업 프로젝트에서 제출물은 각 공종의 조달과 설치를 여는 관문입니다. 단 하나의 항목이 누락되어도 해당 공종은 패키지 검토가 끝날 때까지 보류될 수 있습니다.

이러한 패턴의 비용은 일화가 아니라 수치로 측정됩니다. PlanGrid와 FMI가 건설 전문가 약 600명을 대상으로 공동 실시한 설문 조사인 Construction Disconnected는 미국 재작업의 48%, 전 세계적으로는 52%가 열악한 프로젝트 데이터와 잘못된 의사소통 때문이라고 밝혔으며, 이는 미국에서 단 1년 동안 313억 달러에 달하는 수치입니다. 누락되었거나 접근할 수 없는 프로젝트 정보는 이 분류에서 데이터 측면에 해당합니다. 수작업으로 작성되어 완전하기를 바라는 요구사항 목록은 바로 이 설문 조사가 지적하는 유형의 문서입니다.

제출 요구사항이 실제로 존재하는 곳

표준 프로젝트 매뉴얼에서 제출물에 대한 규칙은 한 섹션에 있지만, 제출해야 할 목록은 그렇지 않습니다. 이 둘은 서로 다른 역할을 하는 서로 다른 문서이며, 건축 법규 제출 요구사항의 전체 세트를 구성하려면 두 문서를 모두 읽어야 합니다.

규칙은 CSI MasterFormat Division 01, Section 01 33 00, "Submittal Procedures"에 있으며, 제작도, 제품 데이터, 샘플, 증명서 및 제출물 기록에 대한 행정 및 절차 요구사항을 담고 있습니다 (CSI MasterFormat). 일정은 Section 01 32 19, "Submittals Schedule"에 있으며, 각 패키지의 제출 날짜를 정합니다. 어느 섹션도 모든 항목을 나열하지는 않습니다. 실제 항목은 Divisions 02~49에 걸친 각 기술 시방서 섹션의 Part 1, General에 있으며, "Submittals" 조항은 해당 공종이 제출해야 할 제작도, 제품 데이터 및 샘플을 알려줍니다. 콘크리트 섹션은 절차를 위해 01 33 00을 참조한 다음 자체 제품을 명명합니다. 이 패턴은 모든 섹션에서 반복되며, 도면은 시방서가 다시 언급하지 않는 요구사항을 추가합니다.

도구 체인은 이러한 분리를 반영합니다. Adobe Acrobat은 단일 파일을 열고 검색하며, Bluebeam Revu는 Studio Sessions를 통해 공동 검토를 위해 문서에 표시하고, Procore Submittals는 프로젝트 전반에 걸쳐 패키지와 상태를 추적합니다. 등록부 자체는 여전히 스프레드시트에 있으며, 이러한 모든 도구가 이를 지원합니다.

건축 법규는 종류가 다른 긴 문서입니다. 2024 International Building Code는 35개 장과 750페이지가 넘는 분량이며(ANSI), 모든 요구사항을 자체적으로 포함하지는 않습니다. Chapter 35, Referenced Standards는 의무의 상당 부분을 ASCE 7, ACI 318, NFPA 13과 같은 외부 문서에 위임하며(ICC), 채택은 지역별로 이루어지므로 시행 중인 버전은 주마다, 도시마다 수정됩니다. 실무자가 "법규"라고 부르는 것은 문서 세트에 걸친 통합본이지 단일 파일이 아닙니다. 그 세트가 하나의 거대한 PDF로 묶여 도착했을 때, 자체 섹션 경계를 따라 분할하는 것은 별도의 작업이며, 수천 페이지가 넘는 PDF를 처리하는 방법에서 다룹니다.

요구사항 세트는 한 곳에 저장되어 있지 않습니다. 이는 Division 01 규칙, 모든 기술 섹션의 Submittals 조항, 도면 주석, 그리고 참조 표준의 합집합이며, 따라서 전체를 찾는 것은 파일에서 조회하는 것이 아니라 말뭉치에 대한 검색 문제처럼 작동합니다.

Ctrl+F가 실패하는 이유: 이것은 재현율 문제입니다

실패는 개인적인 문제가 아니라 기계적인 문제입니다. Ctrl+F는 입력한 정확한 문자열이 나타나는 모든 위치를 반환하므로 정밀도는 높지만 재현율은 사용자가 추측한 한 가지 표현으로 제한됩니다. 제출 요구사항이 하나의 이름으로만 나타나는 경우는 드뭅니다. 동일한 의무가 "submittal", "shop drawing", "product data", "sample", "certificate", "test report" 또는 단순히 "검토를 위해 제출"로 작성될 수 있습니다. 하나의 키워드로 제출 요구사항을 검색하면 한 부분집합만 찾을 수 있습니다.

정보 검색은 수십 년 동안 이 긴장 관계를 틀잡아 왔습니다. Robert Fairthorne은 정밀도를 선호하는 "Only-But-Not-All"과 재현율을 선호하는 "All-But-Not-Only"라는 두 가지 시스템 유형을 설명했습니다. 웹 검색은 아무도 첫 페이지를 넘겨 읽지 않기 때문에 전자를 원합니다. 규정 준수 작업은 거짓 긍정이 눈길 한 번이면 되고 거짓 부정이 일정을 망치기 때문에 후자를 원합니다. 사람들이 시방서에 사용하는 도구들, Ctrl+F부터 PDF 리더의 찾기 바까지, 모두 재현율 작업을 겨냥한 정밀도 도구입니다.

문서 전체를 손으로 읽는 것은 재현율이 높은 대안이지만, 분량이 많아질수록 성능이 저하됩니다. r/ConstructionManagers의 한 게시물은 "왜 submittals가 그렇게 악몽인가"로 시작하며, 첫 번째 답글은 "항상 고통스럽죠, 모든 작업마다 다른 시방서가 있으니까요"입니다. 그 변형이 바로 평이한 언어로 표현된 재현율 문제입니다. 팀이 이를 자동화하려고 할 때 신뢰 격차도 나타납니다. 시방서를 읽고 필요한 submittals의 Excel 목록을 반환하는 소프트웨어를 묻는 별도의 게시물에서, 한 관리자는 Procore의 자동 등록부가 "보통 많은 오류를 초래한다"고 보고하고 다른 사람에게 "하루를 수동으로 처리하는 데 쓰세요. 그러면 제대로 됐다는 걸 알 수 있습니다"라고 조언했습니다 (r/ConstructionManagers). 반대 의견은 자동화가 느리다는 것이 아닙니다. 검증되지 않은 목록은 신뢰할 수 없다는 것입니다.

1단계: 추출 전에 열 세트 정의하기

코드에서 요구사항을 추출하는 확실한 방법은 먼저 요구사항이 어떤 모습인지 결정한 다음 해당 필드만 뽑아내는 것입니다. 이는 일반적인 문서 처리 순서와 반대입니다. 도구에 1,000페이지를 요약하라고 요청하는 대신 원하는 다섯 개의 열을 지정하고 도구가 각 열을 의미별로 찾도록 하는 것입니다.

ImageToTable.ai에서는 이를 맞춤 열 추출이라고 합니다. 열 이름을 입력하면 AI가 각 필드의 의미를 이해하여 문서 어디에서든 일치하는 값을 찾습니다. 위치에 의존하지 않으며 문서별 템플릿이나 학습 데이터도 필요 없습니다. 제출 요구사항 목록에 적합한 열 세트는 다음과 같습니다:

• Spec Section: 요구사항을 부과하는 섹션 번호와 제목(예: 05 12 00 Structural Steel).
• Requirement: 문서 자체의 표현으로 작성된 제출 항목.
• Submission Type: Shop Drawing, Product Data, Sample, Certificate, Test Report, Mockup 등 통제된 목록에서 선택.
• Deadline: 섹션 또는 Submittals Schedule에 연결된 날짜 또는 리드 타임.
• Responsibility: 해당 항목을 제공해야 하는 공종 또는 당사자.

이 중 두 개의 열은 의도적으로 설계할 가치가 있습니다. Submission Type은 추론 열로, AI가 문맥에서 요구사항을 분류하여 사용자가 나열한 옵션에 매핑합니다. 문서에 "Shop Drawing"이라는 라벨이 인쇄되어 있지 않아도 작동합니다. Responsibility도 같은 방식으로 작동합니다. 로그인한 사용자의 경우 규칙 형식을 사용하면 열 이름을 깔끔하게 유지하고 정규화를 JSON 규칙으로 이동할 수 있습니다. 이는 모든 날짜를 하나의 형식으로 통일하거나 모든 섹션 번호를 0으로 패딩하려는 경우에 중요합니다. 이 작업의 핵심은 요구사항 목록이 문서의 요약이 아니라 작고 명명된 스키마라는 점입니다.

2단계: 추출 후, 행을 페이지와 대조

추출은 목록을 생성합니다. 페이지 수준 검증이 이를 방어 가능하게 만드는 이유는, 검토자가 행에서 해당 행을 요구한 문장으로 빠르게 이동할 수 있는 경로가 필요하기 때문입니다.

추출 측면에서, 긴 문서는 단일 파일이 아닌 배치로 처리됩니다. 웹 앱과 API는 단일 업로드를 10 MB 및 50페이지로 제한하므로, 1,000페이지 분량의 코드는 청크로 처리된 후 하나의 스프레드시트로 병합되며, 각 청크에서 동일한 명명된 열이 추출됩니다. 이 메커니즘은 폴더에 대한 배치 실행과 일치하며, 목표는 PDF를 Excel로 변환하는 것과 동일하되, 단일 파일에서 코드북 규모로 확장된 것입니다. 텍스트 레이어가 작업을 어떻게 바꾸는지는 다중 페이지 추출이 할 수 있는 것과 할 수 없는 것에서 다룹니다.

검증 측면에서, Review Mode는 각 추출 셀을 Bbox를 통해 소스 위치와 연결합니다. Bbox는 AI가 값이 나온 영역 주위에 그리는 경계 상자입니다. 스프레드시트에서 셀에 마우스를 올리면 원본 페이지의 해당 영역이 강조 표시됩니다. 페이지에서 영역을 클릭하면 보기가 해당 셀로 다시 이동합니다. 단일 파일에 대해 이 기능을 실행할 수 있으며(1크레딧 소요), 자동 주석을 켜면 처리 완료 시점에 상자가 이미 생성되어 있습니다. 실질적인 효과는 1,000페이지 소스에 대해 행을 확인하는 데 수 초가 걸린다는 것이며, 수동 검색이 필요 없습니다. 또한 동일한 메커니즘이 검증 체크리스트를 실행할 가치가 있게 만듭니다.

검토 계획: 폭넓게 샘플링하고, 중요한 부분은 다시 읽으세요

검토 계획은 누락 시 비용이 큰 항목에 노력을 집중해야 하며, 300개 행에 균등하게 분산해서는 안 됩니다. 제출물 목록의 대부분 행은 영향이 적은 제품 데이터입니다. 일부는 전체 작업의 관문 역할을 합니다.

세 가지 방법으로 대부분의 위험을 관리할 수 있습니다:

위의 r/ConstructionManagers 스레드에서 한 관리자가 같은 생각을 한 줄로 표현했습니다: "제출물을 항상 요구하는 정확한 시방 섹션이나 도면 주석까지 추적하세요." 검토 계획은 이 지침을 반복 가능한 절차로 만든 것이며, 눈에 띄는 행이 아니라 문제가 될 수 있는 섹션에서 추적이 이루어지도록 합니다.

어떤 도구도 여기서 보장할 수 없는 것

어떤 모델도 1,000페이지 분량의 규범 문서에서 완전성을 보장하지 못하며, 그 반대를 주장하는 제품은 데모를 설명하는 것이지 법규집을 설명하는 것이 아닙니다. 재현율은 열 집합과 그 안의 단어에 의해 제한됩니다. 요구사항이 사용자의 열이 설명하지 않는 방식으로 표현된 경우, 모델이 여전히 이를 놓칠 수 있으며, 이것이 바로 검토 계획이 존재하는 이유이고, 추출이 아니라 계획이 보증을 담당하는 이유입니다.

이 도구는 또한 법규를 해석하지 않습니다. 요청한 요구사항 텍스트를 추출할 뿐, 요구사항이 사용자의 범위에 적용되는지, 참조된 표준이 의무를 변경하는지, 또는 최종적으로 생성한 제출물이 적합한지 여부를 판단하지 않습니다. 이러한 것들은 전문가의 판단입니다. 요구사항의 일부가 Chapter 35 참조와 지역 개정안에 있는 문서의 경우, 추출은 제공한 파일만을 다룰 수 있으며, 전체 문서 세트를 구성하는 것은 어떤 추출기도 대신 수행하지 않는 단계입니다.

두 가지 한계를 함께 읽으면 정직한 방법이 정의됩니다: 재현율을 높이기 위한 정의된 열 집합과 누락 위험에 맞춰 조정된 검토 계획입니다. 그 외의 모든 것은 누구도 보증할 수 없는 주장입니다.

FAQ

AI가 1,000페이지 분량의 건축 법규에서 모든 제출 요구사항을 찾을 수 있나요?

보장할 수 없습니다. 비전 기반 추출기는 정의된 열 집합을 전체 문서에서 키워드 검색보다 훨씬 높은 재현율로 추출할 수 있으며, 페이지 수준 검증을 통해 결과를 확인할 수 있습니다. 완전성은 여전히 열 집합과 누락 비용이 큰 섹션에 대한 검토 과정에 달려 있습니다.

전체 법규를 하나의 파일로 업로드해야 하나요?

아닙니다. 단일 업로드는 10 MB 및 50페이지로 제한되며, 긴 문서를 청크로 나누고 병합할 때 처리 정확도가 더 잘 유지됩니다. 법규를 자체 섹션 경계를 따라 분할하고, 청크를 하나의 배치로 처리하고, 각각에서 동일한 열을 추출하세요. 다중 파일 실행의 메커니즘은 여러 파일을 한 번에 일괄 처리하는 것과 동일합니다.

다른 표현으로 작성된 요구사항은 어떻게 찾나요?

리터럴 문자열 대신 필드를 설명하세요. Submission Type을 Shop Drawing, Product Data, Sample, Certificate, Test Report, Mockup으로 설정하는 등 옵션 목록이 있는 추론 열을 사용하면 모델이 단일 키워드를 매칭하는 대신 문맥에서 요구사항을 분류할 수 있습니다. 이것이 검색과 추출의 차이입니다.

이것이 제출물 로그를 대체하나요?

아닙니다. 추출은 로그의 기반이 되는 초기 목록을 생성합니다. 상태, 검토자, 승인 날짜 추적은 여전히 제출물 관리 도구나 스프레드시트에서 이루어져야 합니다. 달라지는 점은 로그가 아무도 완전히 검증할 수 없는 수동 추출 대신 확인 가능한 목록에서 시작된다는 것입니다.

요구사항이 제 작업 범위에 적용되는지 알 수 있나요?

아닙니다. 이 도구는 요구사항 텍스트와 사용자가 지정한 필드를 추출합니다. 적용 여부 결정, 참조 표준 검토, 규정 준수 확인은 여전히 사람의 판단이 필요하며, 검토 계획에서 이러한 판단이 이루어집니다.

긴 문서에서 Ctrl+F를 사용하려는 본능은 타당합니다. 다만 잘못된 지표를 목표로 하고 있을 뿐입니다. 검색은 정밀도를 높이고, 규정 준수는 재현율을 요구하며, 이 둘 사이의 간격에서 놓친 제출물이 발생합니다. 열을 정의하고 해당 열만 추출한 다음, 누락 시 실제 비용이 발생하는 섹션에 검토 시간을 투자하세요. 페이지로 추적할 수 있는 요구사항 목록은 추적할 수 없는 완벽해 보이는 목록보다 가치가 있습니다.

시방서 PDF에서 사용해 보기