캐나다 건설 서브미탈 완전 가이드 — “승인”이 아니라 “검토”입니다

캐나다 건설 서브미탈 완전 가이드 — Submittals in Canadian Construction

지난 편에서 RFI를 “물어보는 기록”이라고 정리하면서, 다음 편은 “승인받는 기록”인 서브미탈을 다루겠다고 했습니다.

그런데 그 예고부터 정확하지 않았습니다. 서브미탈은 승인받는 서류가 아닙니다.

이 한 문장을 모르고 몇 년을 일하는 사람이 있습니다. Procore 화면에는 분명히 Approved라고 찍히니까요. 그런데 그 도장을 찍은 컨설턴트에게 물어보면 십중팔구 이렇게 말합니다. “우리는 승인한 게 아니라 검토한 겁니다.”

말장난처럼 들리지만 아닙니다. 이 차이가 나중에 누가 돈을 무는지를 가릅니다.

서브미탈은 무엇인가 — 짓기 전에 확인받는 절차

서브미탈은 시공에 들어가기 전에 “우리는 이걸 이렇게 만들 겁니다”를 제출해 확인받는 절차입니다.

도면과 시방서는 “무엇을 만들라”까지만 말합니다. 실제로 어느 제조사의 어느 모델을, 어떤 치수로, 어떤 방식으로 붙일지는 시공자가 정합니다. 그 정한 내용을 설계자가 보고 “설계 의도와 어긋나지 않는다”를 확인하는 것이 서브미탈입니다.

RFI가 모르는 것을 묻는 기록이라면, 서브미탈은 정한 것을 알리고 확인받는 기록입니다. 방향이 반대입니다. RFI는 답을 기다리는 동안 그 부분만 멈추지만, 서브미탈은 확인이 끝나야 비로소 자재를 주문할 수 있습니다. 그래서 지연이 만드는 피해의 크기도 완전히 다릅니다. 이 글의 후반부가 사실상 그 이야기입니다.

한 가지 먼저 정리하고 갑니다. 무엇을 제출해야 하는지는 시방서가 정합니다. Division별로 제출 요구사항이 적혀 있고, 시방서가 자세할수록 목록이 명확해집니다. “서브미탈이 몇 건쯤 나오나요”라는 질문에 정답이 없는 이유가 이것입니다. 프로젝트마다 시방서가 다르니 건수도 다릅니다. 세는 게 아니라 각 Division의 요구사항을 훑어서 목록을 만드는 것이 시작입니다.

“Approved”라고 찍히지만 컨설턴트는 “Reviewed”를 뜻합니다

여기가 이 글에서 가장 중요한 대목입니다.

컨설턴트들은 approved라는 단어를 싫어합니다. 가능하면 reviewed를 쓰고 싶어 합니다. Procore 같은 시스템은 버튼 라벨이 Approved로 고정돼 있어서 화면에는 그렇게 뜨지만, 의미는 reviewed로 읽는 것이 맞습니다.

이유는 책임입니다. “승인했다”고 말하는 순간, 설계자가 시공자의 치수·수량·시공 방법·현장 조건까지 보증한 모양이 됩니다. 그래서 검토 도장에는 대개 이런 취지의 문구가 붙습니다. 설계 개념에 대한 일반적 부합 여부만 검토했으며, 이 검토가 계약상 시공자의 책임을 면제하지 않는다.

즉 검토를 통과했다는 건 “설계 의도에서 벗어나지 않았다”는 뜻이지, “이대로 지으면 문제없다”는 뜻이 아닙니다.

그래서 책임은 어디에 남는가

현장에서 이 오해가 사고를 만듭니다.

치수를 잘못 적어 제출했는데 검토를 통과했다고 칩시다. 그대로 제작해서 안 맞으면 그 비용은 시공자 몫입니다. “당신들이 승인했잖습니까”는 통하지 않습니다. 검토자는 설계 의도를 봤을 뿐 현장 치수를 재준 적이 없기 때문입니다.

그러니 서브미탈을 올릴 때의 마음가짐이 달라야 합니다. 검토를 통과시키는 것이 목표가 아니라, 틀린 게 없는 상태로 올리는 것이 목표입니다. 검토는 마지막 안전망이 아니라 설계 의도 확인 절차일 뿐입니다. 이 문장 하나만 갖고 가셔도 이 글은 값을 합니다.

검토 도장의 의미 — Approved로 표시되지만 실제로는 Reviewed, 책임 분담
시스템은 Approved라고 찍지만 컨설턴트가 뜻하는 것은 Reviewed다. 치수·수량·시공법·현장조건은 그대로 시공자 몫으로 남는다

누가 만들어 어디를 거치는가

경로 자체는 단순합니다.

트레이드가 자기 공종의 제출물을 만들어 GC에 냅니다. GC는 그것을 시방서 섹션별로 구분하고 검토한 뒤 컨설턴트에게 제출합니다. Procore로 보내고 Procore로 받습니다.

여기서 GC의 역할이 단순 전달이 아니라는 점이 중요합니다. 섹션 구분이 틀리면 검토자가 어느 시방 조항에 대고 봐야 하는지부터 헷갈립니다. 누락된 항목이 있으면 그대로 재제출 사유가 됩니다. 이미 답이 나온 사안을 다시 올리는 경우도 있습니다. 걸러서 올리는 일이 GC 몫입니다. 그리고 걸러지지 않은 제출물이 쌓이면 정작 급한 항목의 검토 순서가 뒤로 밀립니다.

예외가 하나 있습니다. 샘플처럼 발주처가 직접 봐야 하는 항목은 컨설턴트와 함께 발주처에도 검토를 요청합니다. 색상이나 마감재처럼 취향과 의사결정이 걸린 것들입니다. 이 경우 검토자가 둘이 되므로 일정도 그만큼 더 잡아야 합니다.

제출과 추적을 Procore에서 어떻게 하는지는 Procore 현장 입문 가이드에 있습니다.

검토 기한 2주 — 이것도 여러분이 정하는 것입니다

통상 2주입니다. 그런데 RFI 때와 마찬가지로, 이 기한도 계약서가 정해 주지 않는 경우가 많습니다.

그래서 Communication Plan에 넣습니다. 프로젝트 시작 단계에서 정해 문서로 남깁니다. 내부적으로만 정할 수도 있고 발주처와 합의해 확정할 수도 있는데, 후자가 훨씬 강합니다.

이걸 해두지 않으면 나중에 “왜 3주가 걸렸느냐”고 물을 기준 자체가 없습니다. 기준이 없으면 한 달이 걸려도 “원래 복잡한 항목이었다”는 답이 돌아옵니다.

RFI 편에서 했던 말이 여기서도 똑같이 적용됩니다. 지연을 주장하려면 먼저 기준이 있어야 합니다. 다만 서브미탈은 RFI보다 기한을 길게 잡습니다. 검토자가 시방서와 대조하고 여러 분야를 확인해야 하기 때문입니다.

종류 — 그리고 close-out을 따로 묶어야 하는 이유

실무에서 다루는 것은 크게 이렇습니다.

종류 성격
Product data 제조사 자료, 사양서
Shop drawing 시공 상세도. 제작·설치 치수까지
Sample 실물 견본. 발주처 확인이 필요한 경우가 많음
Mock-up 현장에 실제로 만들어 보이는 것
Close-out (O&M, As-built) 준공 서류

Close-out은 별도 패키지로 관리하는 것이 맞습니다. 그리고 준공 때 모으기 시작하면 늦습니다.

이유가 명확합니다. 트레이드도 close-out 서류를 만드는 데 시간이 걸립니다. 준공 임박해서 요구하면 그때부터 자료를 찾기 시작하고, 이미 현장을 떠난 인력이 있으면 그마저 안 됩니다. 그리고 이 지연이 길어지면 GC 비용으로 돌아옵니다.

그래서 서브미탈을 처음 받는 시점부터 어떤 close-out 서류를 낼 것인지 목록을 알고 준비시키는 것이 실제로 돈을 아끼는 방법입니다.

샘플과 목업은 서류로 돌리지 마십시오

이건 경험에서 나온 판단입니다.

샘플은 발주처가 봐야 하는 경우 사진으로 서브미탈을 올리고, 실물은 따로 보냅니다. 서류만 가면 색이나 질감을 판단할 수 없고, 실물만 가면 기록이 남지 않습니다. 둘 다 가야 결정이 납니다.

목업은 다릅니다. 현장에 실제로 만들어 놓고 당사자들이 모여 보고 승인받는 편이 훨씬 빠릅니다. 서브미탈 절차에 태우면 이렇게 됩니다. 제출 → 검토 → 코멘트 → 트레이드에 전달 → 수정 → 재검토. 한 바퀴에 몇 주가 사라집니다.

현장에서 직접 보고 그 자리에서 논의하면 하루면 끝날 일입니다. 목업의 목적 자체가 “실물을 보고 판단하는 것”인데 그걸 종이로 왕복시킬 이유가 없습니다.

그래서 목업은 목록만 관리하면 됩니다. 어떤 항목에 목업이 요구되는지, 언제 어디에 세울지를 알고 있으면 충분합니다. 서류 워크플로에 넣어 관리하려 들면 오히려 느려집니다.

샵드로잉에 도장이 필요한 것들 — Schedule S-B·S-C 사슬

BC에서 알아야 할 구조가 하나 더 있습니다.

서브미탈 절차 자체는 계약상 절차이고, 지난 편에서 다룬 Letters of Assurance(Schedule A·B·C-A·C-B)와는 별개입니다. 그런데 일부 샵드로잉은 그 사슬에 걸립니다.

비구조 프레이밍, 글레이징, 거푸집처럼 트레이드가 설계까지 해서 올리는 항목은 해당 엔지니어가 샵드로잉에 직접 날인해서 보내야 합니다. 그리고 그 엔지니어들은 지원 등록 전문가(Supporting Registered Professional)로서 서류를 냅니다.

사슬은 이렇게 이어집니다.

지원 전문가가 Schedule S-B·S-C 제출 → 해당 분야 record 전문가가 그것을 다 받아야 Schedule C-B 제출 가능 → 그 다음에야 CRP가 Schedule C-A 발행

즉 트레이드가 샵드로잉을 늦게 내면 그 여파가 준공 서류까지 갑니다. 건물을 다 지어놓고 C-A가 안 나오는 상황이 여기서 생깁니다. 지난 편의 RFI 가이드에서 CRP를 다뤘는데, 그 이야기의 뒷부분이 이겁니다. 허가와 검사 체계는 BC주 건축 허가 완전 가이드에 정리해 뒀습니다.

BC 서류 사슬 — 샵드로잉 날인부터 Schedule S-B, C-B, C-A까지
샵드로잉 하나가 늦으면 그 뒤 서류가 순서대로 밀린다. 건물을 다 지어놓고 C-A가 안 나오는 상황이 여기서 생긴다

검토 결과 — 그리고 발주를 걸어도 되는 시점

결과 코드는 넷입니다.

결과 뜻 발주 가능?
Approved 그대로 진행 ✅
Approved as Noted 코멘트 반영 조건부 ✅
Revise and Resubmit 고쳐서 다시 ❌
Rejected 반려 ❌

Rejected와 Revise and Resubmit은 실질적으로 같습니다. 반려됐으면 고쳐서 다시 내야 하니까요. 구분에 에너지를 쓸 필요가 없습니다.

진짜 알아야 할 구분은 Approved as Noted와 Revise and Resubmit입니다.

Approved as Noted를 받으면 발주를 걸 수 있습니다. 공정이 급할 때 컨설턴트에게 요청해서 이 결과를 받아내는 것도 실무입니다. 다만 as noted인 이상 코멘트를 반영한 최종본을 다시 제출하는 것이 맞습니다. 물론 코멘트 성격에 따라 다릅니다. 색상 표기 수정 하나와 치수 변경은 무게가 다르니까요.

진짜 위험은 여기에 있습니다 — 승인이 나야 시계가 시작됩니다

RFI 지연과 서브미탈 지연은 성격이 다릅니다.

RFI 지연은 “답을 못 받아서 그 부분을 못 짓는 것”입니다. 국지적입니다.

서브미탈 지연은 다릅니다. 검토가 끝나야 발주가 나갑니다. 발주가 나가야 제작이 시작되고, 제작이 끝나야 배송이 되고, 배송이 돼야 설치합니다. 즉 검토 지연은 그 뒤에 붙은 모든 기간을 통째로 뒤로 밉니다. 2주 지연이 2주로 끝나지 않는 이유입니다.

그리고 그 자재가 critical path 위에 있으면 프로젝트 전체가 밀립니다.

그래서 장납기 자재는 계약 직후 바로

트레이드와 계약을 체결하자마자 서브미탈부터 받아야 합니다. 현장에서 문제를 일으키는 단골은 이런 것들입니다.

  • 철골 (주 구조물)
  • 엘리베이터
  • 발전기
  • 배전반
  • 기계 장비
  • 방화 알루미늄 프레임·유리
  • 타일 (수입 품목인 경우)

실제로 가장 오래 끌었던 것은 엘리베이터와 철골이었습니다. 철골은 철골 계약자와 그 하도급 사이의 문제까지 겹치면서 설계 검토가 늘어졌고, 그 여파가 프로젝트 내내 따라왔습니다.

Submittal schedule은 거꾸로 짭니다

서브미탈 일정은 설치일에서 역산합니다. 마스터 공정표와 시공 순서를 이해하고 있어야 짤 수 있습니다. 구매·조달 계획은 시공 순서를 기준으로 세우는 것이 맞습니다.

방법은 단순합니다. 설치일에서 거꾸로 빼나갑니다.

설치 예정일 − 배송 − 제작 − 발주 처리 − 검토 기간 = 서브미탈 제출 마감일

예를 들어 9월 10일 설치라면, 배송 3주·제작 8주·발주 처리 1주·검토 2주를 빼서 약 14주, 즉 6월 초에는 제출이 끝나 있어야 합니다. 기간은 품목과 공급사에 따라 크게 다르니, 위 숫자는 계산 방식을 보여주기 위한 예시로만 보시기 바랍니다.

이 계산을 해보면 왜 “계약 직후 바로”라는 말이 나오는지 알게 됩니다. 장납기 품목은 착공하고 나서 챙기면 이미 늦습니다.

승인 지연도 공정표에 얹으십시오

RFI 편에서 정리한 3단계가 여기서도 그대로 적용됩니다.

검토가 약속한 기한을 넘기면 공정표에 “서브미탈 지연”을 하나의 액티비티로 넣습니다. 그래야 지연이 말이 아니라 공정표 위의 사실이 됩니다.

이렇게 관리해 두면 나중에 논쟁이 생겼을 때 근거가 됩니다. 자재가 늦게 온 이유가 우리 준비 부족이 아니라 검토 지연이었다는 걸, 기억이 아니라 문서로 보여줄 수 있습니다.

서브미탈 역산 타임라인 — 설치일에서 배송·제작·발주·검토를 빼서 제출 마감일 구하기
설치일에서 거꾸로 빼면 제출 마감일이 나온다. 검토 2주가 밀리면 뒤에 붙은 발주·제작·배송이 통째로 밀린다

승인은 X, 납품은 Y — 그리고 그때 할 수 있는 것

실제로 생기는 일입니다. 도면에는 X로 표기해 검토를 통과했는데 현장에 Y가 옵니다.

트레이드가 실수했거나, 이윤을 더 남기려고 바꿨거나 둘 중 하나입니다. 어느 쪽이든 발견은 대개 자재가 도착한 뒤에 이뤄집니다.

판단 기준은 명확합니다.

  • 사양보다 높은 것이 왔다면 문제 삼을 이유가 없습니다.
  • 사양보다 낮은 것이 왔다면 합당한 이유를 대야 하고, 자재 비용 차액을 발주처에 돌려주는 방향으로 정리하면서 일정을 지키는 것이 현실적입니다.

두 번째 경우가 실무의 판단력이 드러나는 지점입니다. 원칙대로라면 다시 만들어 오라고 해야 하지만, 그게 항상 최선은 아닙니다.

최악은 재발주입니다. 다시 만들어 다시 보내는 동안 일정이 통째로 밀리고, 그 지연이 발주처의 운영 개시에 영향을 주면 그때부터는 자재비 차원의 문제가 아니게 됩니다. 건물을 못 여는 손해는 자재 차액과 비교가 되지 않습니다. 그래서 “차액을 돌려주고 일정을 지킨다”가 종종 모두에게 나은 답이 됩니다.

재제출 교착 — 초안을 받아준 대가

이건 잘 안 풀렸던 경험입니다.

트레이드가 완성되지 않은 초안을 제출했습니다. “코멘트를 주면 그에 맞춰 완성하겠다”는 논리였습니다. 그런데 컨설턴트는 검토를 거부했습니다. 초안에 코멘트를 달아봐야 완성본이 오면 처음부터 다시 봐야 하기 때문입니다. 그래서 아예 검토를 시작하지 않았습니다.

미팅으로 조율을 시도했지만 그 현장에서는 끝내 잘 풀리지 않았습니다. 자재는 지연됐고, 그 갭을 현장에서 메우느라 정말 고생했습니다.

지금 돌아보면 답은 하나였습니다. GC가 트레이드를 압박해서 어떻게든 설계를 완성시킨 뒤 검토에 넣었어야 했습니다.

트레이드 입장에서는 초안을 던져 놓고 피드백으로 완성하는 편이 편합니다. 하지만 그 방식이 막히면 손해는 트레이드가 아니라 GC에게 옵니다. 결국 발주처 앞에서 일정을 책임지는 쪽은 GC이기 때문입니다.

서브미탈이 RFI가 되고, 체인지 오더가 되는 지점

세 문서는 따로 놀지 않습니다.

서브미탈 → RFI. 검토 코멘트가 이해되지 않거나, 코멘트보다 나은 대안이 있을 때 서브미탈 번호를 참조해 RFI를 올립니다. “이 코멘트를 이렇게 이해했는데 맞습니까”, “이런 대안이 더 낫다고 보는데 허용되겠습니까”를 묻는 것입니다. 그렇게 방향을 확정한 뒤 최종 서브미탈을 다시 제출합니다. 순서가 중요합니다. RFI로 정리하지 않고 재제출부터 하면 같은 코멘트를 또 받습니다. RFI 쓰는 법은 캐나다 건설 RFI 완전 가이드에 정리해 뒀습니다.

서브미탈 → 체인지 오더. 시방서에 적힌 제품이 단종됐거나 구할 수 없을 때입니다. 사양에 맞는 대체품을 찾아 변경 절차를 밟게 됩니다.

이때 조심할 것이 있습니다. 대체품 승인을 받았다고 그대로 진행하면, 원가는 확정되는데 매출은 확정되지 않은 상태가 됩니다. 그 시차가 어디서 손실이 되는지는 원가는 먼저, 매출은 나중에에서 다뤘습니다.

정리 — 서브미탈을 다루는 사람이 결국 보게 되는 것

두 가지가 남습니다.

첫째, 검토는 면죄부가 아닙니다. Approved 도장을 받아도 치수와 시공 방법의 책임은 그대로 시공자에게 있습니다. 그러니 “검토에서 걸러주겠지”라는 기대로 올리면 안 됩니다. 그 기대가 트레이드의 초안을 그대로 올려보내게 만들고, 앞에서 본 교착으로 이어집니다.

둘째, 서브미탈 관리는 서류 관리가 아니라 일정 관리입니다. 검토 2주가 늦으면 자재가 2주 늦는 게 아니라, 그 뒤에 붙은 제작과 배송이 통째로 밀립니다. 그래서 잘하는 PC는 서브미탈 목록을 시방서 순서가 아니라 설치 순서로 봅니다. 같은 목록인데 보는 축이 다릅니다.

다음 편에서는 이 시리즈의 마지막, 체인지 오더를 다루겠습니다. RFI에서 시작되고 서브미탈에서도 흘러드는 변경들이, 어떤 문서를 거쳐 어떻게 돈이 되는지를 정리하겠습니다.

함께 읽으면 좋은 글