현장에서 도면을 펼쳐 놓고 이런 순간이 옵니다. 도면대로는 이게 안 들어갑니다. 아니면 두 장의 도면이 서로 다른 말을 하고 있습니다. 이때 보내는 것이 RFI(Request for Information)입니다.
한국어로는 보통 “질의서”나 “질의회신”으로 옮깁니다. 틀린 번역은 아닌데, 이 번역 때문에 RFI를 물어보는 서류로만 이해하게 됩니다. 실제로는 다릅니다.
제가 참여했던 대형 프로젝트에서는 RFI가 수백 건 단위로 나왔습니다. RFI 로그와 체인지 오더 로그를 나란히 놓고 보면, 상당수가 같은 사건의 앞뒤였습니다.
즉 RFI는 질문서가 아니라 돈과 일정이 움직이기 시작하는 첫 번째 기록입니다. 이 글은 그 관점에서 RFI를 정리합니다.
RFI는 질문이 아니라 기록입니다
RFI의 실질은 세 가지입니다.
첫째, 누가 언제 무엇을 물었는지가 남습니다. 둘째, 누가 언제 무엇이라고 답했는지가 남습니다. 셋째, 그 답이 계약 범위 안인지 밖인지를 나중에 판단할 근거가 됩니다.
이 세 번째가 핵심입니다. 공사가 끝난 뒤 “그때 왜 이렇게 시공했느냐”는 질문이 나올 때, 또는 “이건 추가 비용을 줄 수 없다”는 말이 나올 때, 꺼내는 것이 RFI 로그입니다. 구두로 받은 지시는 이 자리에서 아무 힘이 없습니다. 현장에서 “그때 담당자가 그렇게 하라고 했는데요”라는 말이 통하지 않는 이유가 이것입니다. 사람은 바뀌고 기억은 갈리지만, 번호가 붙은 기록은 남습니다.
그래서 RFI를 잘 쓴다는 건 질문을 잘한다는 뜻이 아니라, 나중에 꺼냈을 때 그 자체로 설명이 되는 기록을 만든다는 뜻입니다. 이 관점을 갖고 있느냐 아니냐가, 같은 상황에서 서로 다른 RFI를 쓰게 만듭니다.
대부분의 RFI는 설계와 시공의 관점 차이에서 나옵니다
RFI가 많이 나오면 설계가 부실했다는 뜻일까요. 꼭 그렇지는 않습니다.
설계자는 “무엇을 만들 것인가”를 그립니다. 시공자는 “그것을 어떤 순서로, 어떤 장비로, 어떤 공차 안에서 만들 것인가”를 봅니다. 두 관점은 겹치지만 같지 않습니다. 도면상으로는 완결된 디테일이, 현장에서는 시공 순서 때문에 성립하지 않는 경우가 흔합니다. 벽체가 먼저냐 덕트가 먼저냐 같은 문제는 도면에 그려지지 않습니다.
RFI 건수는 프로젝트마다 크게 다릅니다. 설계 성숙도, 발주 방식, 공기 압박에 따라 갈립니다. 그러니 “RFI가 몇 건이면 정상”이라는 기준은 없습니다. 다만 RFI가 폭증하는 프로젝트는 대체로 설계가 덜 여문 채 착공한 프로젝트입니다.
누가 RFI를 보내는가 — 하청만 보내는 게 아닙니다
가장 흔한 오해입니다.
일반적인 경로는 트레이드(하청)가 시공 검토 중 의문이 생겨 올리는 것입니다. 하지만 실제로는 GC가 직접 보내는 경우도 많습니다. GC가 설계와 시공성을 먼저 검토하다가 문제를 발견하면, 관련 트레이드에게 확인한 뒤 GC 이름으로 직접 올립니다. 여러 공종이 얽힌 간섭 문제는 특정 트레이드가 볼 수 없는 영역이라, 애초에 GC가 아니면 발견되지 않습니다.
이 구분이 나중에 중요해집니다. GC가 직접 보낸 RFI는 답변이 돌아왔을 때 트레이드가 그 사실을 모릅니다. 뒤에서 다시 다루겠지만, 재시공이 여기서 나옵니다.
트레이드가 올린 경우 GC의 PM 또는 PC가 먼저 검토합니다. 이 단계에서 걸러지는 것들이 있습니다. 이미 답이 나온 사안을 다시 묻는 경우, 도면을 제대로 안 본 경우, 시방서에 답이 있는 경우입니다. 현장 조건이 걸린 사안이면 슈퍼인텐던트와 함께 확인합니다. 걸러지지 않은 RFI를 그대로 올려 보내면 창구만 지저분해지고, 정작 중요한 RFI의 답변 순서가 뒤로 밀립니다.
RFI가 지나가는 경로 — 발주 방식에 따라 갈립니다
GC가 내용을 확인한 뒤 어디로 보내는지는 계약 형태에 따라 다릅니다.
| 발주 방식 | RFI 수신처 |
|---|---|
| Design-Build | 사내 design coordinator 또는 계약된 컨설턴트 |
| CM | 발주처, 또는 발주처의 컨설턴트 |
Design-Build에서는 설계 책임이 시공자 쪽에 있으므로 답변도 안에서 만들어집니다. CM에서는 설계가 발주처 쪽에 있으므로 밖으로 나갑니다. 같은 내용의 RFI라도 답이 며칠 만에 오느냐가 여기서 갈립니다.
계약 형태별 차이는 General Contractor가 알아야 할 건설 계약 종류와 General Contractor(GC)란 무엇인가 글에서 더 자세히 다뤘습니다.
왜 건축사가 답을 주는가 — BC의 Letters of Assurance 구조
여기서 BC주 특유의 구조가 하나 있습니다.
RFI를 올리면 구조·기계·전기 어느 분야의 질문이든 건축사를 통해 답이 돌아오는 경우가 많습니다. 처음 보면 “왜 전기 질문에 건축사가 답하지” 싶습니다.
BC 건축법은 프로젝트마다 CRP(Coordinating Registered Professional, 조정 등록 전문가)를 두게 되어 있고, 통상 건축사가 이 역할을 맡습니다. CRP는 허가 단계에서 Schedule A에 서명하고, 각 분야 전문가가 Schedule B를 냅니다. 그리고 공사가 끝나고 현장검토가 완료되면 CRP가 Schedule C-A에 서명해 “이 건물이 건축법에 실질적으로 부합한다”고 확인합니다.
마지막에 그 서류에 이름을 걸어야 하는 사람이 CRP입니다. 그러니 공사 중에도 각 분야의 답변을 CRP 또는 CRP가 소속된 컨설턴트 사무소가 취합해서 하나의 답으로 내려주는 것이 이상적입니다. 분야별로 제각각 답이 오면 서로 충돌하는 답이 나오고, 그 충돌을 현장이 떠안게 됩니다.
허가와 검사 체계는 BC주 건축 허가 완전 가이드에 정리해 뒀습니다.
이메일 말고 시스템으로 보내야 하는 이유
RFI는 이메일로도 주고받을 수 있습니다. 실제로 그렇게 하는 현장도 있습니다. 하지만 저는 Procore 같은 시스템을 강하게 선호합니다. 이유는 두 가지입니다.
추적이 안 됩니다. 이메일은 스레드가 갈라지고, 참조가 빠지고, 첨부가 어느 메일에 있었는지 잃어버립니다. 6개월 뒤에 “그때 뭐라고 답했었죠”를 확인하려면 검색부터 해야 합니다.
인수인계가 안 됩니다. 이게 더 큽니다. 프로젝트 중간에 새 인원이 배정되면, 그 사람은 이전 RFI를 볼 방법이 없습니다. 남의 메일함에 있으니까요. 시스템에 있으면 들어와서 로그를 처음부터 읽으면 됩니다. 현장 인력 교체가 잦은 프로젝트일수록 이 차이가 결정적입니다.
Procore에서 RFI를 올리고 확인하는 실제 절차는 Procore 현장 입문 가이드에 있습니다.
답변 기한은 계약서에 없습니다 — 직접 정해야 합니다
많은 분들이 계약서에 RFI 답변 기한이 박혀 있을 거라 생각합니다. 제 경험으로는 계약서가 이걸 정해 주지 않는 경우가 대부분입니다.
그래서 프로젝트 시작 단계에서 정합니다. 보통 Communication Plan 안에 들어갑니다. 누가 무엇을 어떤 경로로 언제까지 주고받을지를 규정하는 문서인데, RFI 턴어라운드도 여기 포함되는 것이 맞습니다. 내부적으로 정할 수도 있고, 발주처와 협의해 문서로 확정할 수도 있습니다. 후자가 훨씬 강합니다.
통상 5일에서 10일로 잡습니다. 단순 확인은 5일, 여러 분야가 얽히면 10일 식으로 나누기도 합니다.
이걸 착공 전에 문서로 합의해 두지 않으면, 나중에 “왜 이렇게 늦었느냐”고 따질 기준 자체가 없습니다. 기준이 없으면 두 달이 걸려도 “원래 오래 걸리는 사안이었다”는 답이 돌아옵니다. 지연을 주장하려면 먼저 기준이 있어야 합니다. 이 문장 하나 때문에 착공 전 한 시간을 쓸 가치가 있습니다.
답이 빨리 오는 RFI의 조건 — 그리고 첨부
답변 속도를 가장 크게 좌우하는 건 질문의 복잡도입니다. 여러 분야가 얽힌 사안은 당연히 오래 걸립니다.
하지만 같은 난이도라도 갈리는 지점이 있습니다. 왜 이 질문을 하는지가 설명되어 있느냐입니다.
“이 디테일이 맞습니까”만 적혀 있으면, 받는 사람은 도면부터 다시 열어 상황을 재구성해야 합니다. 반면 “A-501의 이 디테일대로는 상부 덕트와 간섭이 생깁니다. 아래 사진과 마크업 참조”라고 적혀 있으면, 검토자는 판단만 하면 됩니다.
검토자의 일을 줄여 주는 RFI가 빨리 돌아옵니다. 인심의 문제가 아니라 물리적으로 그렇습니다.
첨부는 도면 마크업이 기본입니다
첨부에 정해진 양은 없습니다. 다만 해당 도면이 있다면 그 도면에 마크업해서 보내는 것을 기본으로 삼고 있습니다.
말로 위치를 설명하면 오해가 생깁니다. “동측 벽체 상부”라고 써도 받는 사람이 다른 곳을 볼 수 있습니다. 도면에 동그라미 하나 치고 화살표 하나 그으면 그 오해가 사라집니다. 그리고 이 마크업은 나중에 그대로 현장에 나가는 자료가 되기도 합니다.
현장 사진도 같은 역할을 합니다. 실제 조건이 도면과 다르다는 걸 주장하려면, 그 조건을 보여 주는 것이 가장 빠릅니다. 사진 한 장이 문단 세 개를 대신합니다.
Proposed solution은 반드시 넣으십시오
이건 선택이 아니라 기본입니다.
질문만 던지면 설계자가 해법을 처음부터 만들어야 합니다. 시간이 오래 걸립니다. 대신 “이렇게 하면 될 것 같은데 괜찮겠습니까”를 같이 내면 검토자는 판단만 하면 됩니다.
그 뒤 결과는 둘 중 하나입니다.
- 수락: 발주처 입장에서 합당하면 그대로 승인되고, 제안한 방식으로 시공합니다.
- 거절: 설계가 변경되어 내려오고, 변경된 대로 시공해야 합니다.
거절되더라도 손해가 아닙니다. 제안을 냈다는 기록이 남고, 대안이 왜 안 되는지에 대한 설계자의 판단도 함께 남습니다. 나중에 비용 논쟁이 생겼을 때 이 기록이 일합니다. “우리는 더 싼 방법을 제안했지만 발주처가 거절했다”는 사실이 문서로 존재하는 것과, 기억으로만 존재하는 것은 완전히 다릅니다.
한 가지 주의할 점이 있습니다. 제안은 시공 관점의 제안이지 설계가 아닙니다. 구조 안전이나 코드 적합성 판단까지 넘겨받으면 곤란해집니다. 뒤에서 이 경계를 다룹니다.
질문 하나에 RFI 하나 — 기록을 지키는 원칙
원칙은 단순합니다. RFI 하나에 질문 하나. 하나를 완전히 닫아야 읽는 사람이 헷갈리지 않습니다.
같은 부위에 대한 후속 질문이라면, 새 RFI를 열고 “이 부분은 RFI #○○에서 이렇게 정리되었고, 이번에는 이러이러한 이유로 무엇을 어떻게 해야 하는지 확인 요청드립니다”라고 앞 건을 명시적으로 참조합니다. 이렇게 하면 두 건이 각각 독립된 기록으로 남으면서도 연결됩니다.
여기서 실제로 벌어지는 사고
원칙을 알면서도 무너지는 지점이 있습니다. 답변 안에서 대화가 이어지는 경우입니다.
1번을 물었는데, 답변이 오고, 그 답변에 딸린 2번 질문과 답이 같은 RFI 스레드 안에서 오갑니다. 그러면 나중에 사람들이 2번의 내용을 1번 RFI로 기억합니다. 로그를 열어 보면 제목은 1번인데 내용은 2번이 섞여 있습니다.
이게 왜 문제냐면, RFI는 나중에 번호로 인용되는 문서이기 때문입니다. “RFI #47에 따라 시공했습니다”라고 했을 때 #47이 무엇을 말하는지가 흐려지면, 그 기록은 근거로서의 힘을 잃습니다.
답변이 왔다고 시공하면 안 됩니다 — SI → 견적 → CO → 시공
여기서부터가 이 글에서 제일 중요한 부분입니다.
RFI에 답이 왔습니다. 그대로 시공하면 될까요. 아닙니다.
답변을 받으면 먼저 일정과 비용에 영향이 있는지 확인해야 합니다. 영향이 없으면 그대로 진행하면 됩니다. 영향이 있으면 시공 전에 발주처에 알려야 합니다.
특히 RFI 답변이 범위 변경이나 설계 변경에 해당하면, 이건 100% 체인지 오더 사안입니다. 답변서 한 장을 근거로 추가 공사를 그냥 해 버리면, 그 비용을 받을 근거가 사라집니다. 답변은 지시가 아닙니다.
밟아야 하는 순서
- SI(Site Instruction) 수령 — 발주처 또는 컨설턴트가 현장 지시를 발행합니다
- 견적 요청 — 관련 트레이드에 가격을 받습니다
- 견적 제출(CO 요청) — 발주처에 제출합니다
- CO 승인
- 시공
용어를 조심하셔야 합니다. 현장에서 말하는 SI는 Site Instruction이고, CCDC 계약서의 Change Directive(CD)와는 다른 것입니다. CD는 가격 합의 전에 우선 착수하라는 지시로, 비용은 실비 정산으로 나중에 확정됩니다. 발주처가 공기 때문에 기다릴 수 없을 때 쓰는 수단입니다.
무엇을 받았는지에 따라 지금 시공을 시작해도 되는지가 갈립니다. 이 구분이 흐려진 채 진행하면, 원가는 확정되었는데 매출은 확정되지 않은 상태가 됩니다. 그 시차가 어디서 손실이 되는지는 원가는 먼저, 매출은 나중에 편에서 다뤘습니다.
GC가 보낸 RFI는 반드시 트레이드에 전달하십시오
앞에서 예고한 재시공 문제입니다.
GC가 직접 올린 RFI는 답변도 GC에게 돌아옵니다. 트레이드는 그 RFI가 있었다는 사실조차 모를 수 있습니다. 그 상태로 시공이 들어가면 반영이 안 됩니다. 그리고 뜯고 다시 합니다. 이 재시공 비용은 발주처에 청구할 근거가 없습니다. 답은 제때 왔으니까요.
그래서 답변을 받으면 세 가지를 합니다.
- 관련 트레이드에 전달
- 시공팀에 공유
- 해당 도면에 표시 — 마크업된 도면이 현장에 나가야 합니다
여기에 하나 더. PM이나 PC가 작업 착수 전에 “이 부위에 이런 RFI가 있었습니다”라고 상기시켜 주는 것이 실제로 큰 차이를 만듭니다. 서류상 전달했다는 사실과, 현장 사람이 그걸 기억하고 있다는 사실은 다릅니다. 전달은 이메일 한 통으로 끝나지만, 반영은 사람이 그 순간에 떠올려야 일어납니다.
설계자가 계속 되물을 때 끊는 법
가끔 이런 상황이 생깁니다. 설계자가 답을 주는 대신 시공자에게 계속 되묻습니다. “그럼 어떻게 하는 게 좋겠습니까”가 반복됩니다.
시공자가 의견을 낼 수는 있습니다. 하지만 의무 사항이 아니고, 시공자는 설계자가 아닙니다. 되물음이 계속되면 답변 책임이 슬그머니 넘어옵니다. 그리고 나중에 문제가 생겼을 때, 그 판단을 한 사람이 누구였는지가 흐려집니다. 도면에 도장을 찍은 사람이 져야 할 책임을, 기록상으로는 현장이 진 모양이 되어 버립니다.
이럴 때는 이렇게 끊습니다.
이건 설계 사안이고, 현장에서는 디테일 없이 시공할 수 없습니다. 이런 방안을 제안드렸는데 허용되지 않는다면 상세 도면을 주시기 바랍니다.
요구가 명확해집니다. 방안을 수락하든지, 도면을 주든지 둘 중 하나입니다. 감정 섞을 필요도 없습니다. 그리고 이 요청이 기록으로 남는다는 점이 중요합니다. 이후 설계 지연이 공기에 영향을 주면, 이 RFI가 그 출발점을 증명합니다.
RFI 지연을 일정과 클레임으로 옮기는 법
RFI 지연은 그 자체로는 아무것도 아닙니다. 기록으로 옮겨야 힘이 생깁니다.
실제로 답변이 두 달 걸린 적이 있습니다. 발주처 PM이 휴가 중이라 창구가 비어 있었습니다. 그때 밟은 순서입니다.
1단계 — RFI 본문에 경고를 넣습니다. 올릴 때부터 “언제까지 답변이 없으면 일정에 영향이 있습니다”라고 적습니다. 지나고 나서 주장하는 것과, 처음부터 적어 둔 것은 무게가 다릅니다.
2단계 — 공정표에 activity로 넣습니다. RFI ## 응답 지연 — 4 weeks 형태로 지연 자체를 하나의 액티비티로 만들어 일정에 반영했습니다. 이렇게 하면 지연이 공정표 위에서 보이는 사실이 됩니다. 말이 아니라 도구가 증명합니다.
3단계 — Delay Notice를 발송합니다. 공정표에 반영한 기간(4 weeks)을 근거로 정식 통지를 보냅니다.
순서가 중요합니다. 경고 없이, 공정표 반영 없이, 두 달 뒤에 통지부터 보내면 “왜 진작 말하지 않았느냐”는 답이 돌아옵니다.
정리 — RFI를 다루는 사람이 결국 보게 되는 것
RFI를 오래 다루면 이런 결론에 닿습니다.
RFI는 질문하는 능력의 문제가 아니라 기록을 관리하는 능력의 문제입니다. 질문 자체는 현장에서 저절로 생깁니다. 차이는 그 질문이 추적 가능한 형태로 남느냐, 답변이 필요한 사람에게 닿느냐, 비용과 일정으로 옮겨졌느냐에서 생깁니다.
그래서 RFI를 잘 다루는 PC와 그렇지 않은 PC의 차이는 공사가 끝날 무렵에 드러납니다. 한쪽은 근거를 갖고 있고, 다른 쪽은 기억을 갖고 있습니다.
다음 편에서는 이 글에서 계속 나온 서브미탈과 샵드로잉을 다뤘습니다. RFI가 “물어보는 기록”이라면 서브미탈은 “승인받는 기록”이고, 승인 지연이 공정을 먹는 방식은 RFI 지연과 또 다릅니다.