다들 형식적으로 쓰는 BEP, 제대로 쓰면 프로젝트 갈등의 8할이 사라진다

"BEP는 발주처가 요구하니까 형식적으로 내는 서류 아닌가요?" — 실무에서 정말 자주 듣는 말이다. 그런데 프로젝트 후반부에 "이 모델 LOD가 왜 이래요?", "그 정보는 누가 넣기로 했었죠?" 같은 다툼이 벌어질 때, 원인을 거슬러 올라가면 대부분 BEP를 대충 썼거나 아예 안 썼다는 사실과 만난다.

"BEP, 그냥 템플릿 복붙해서 내면 안 되나요?"

안 된다. BEP(BIM Execution Plan)는 "이 프로젝트에서 BIM을 어떻게 수행할 것인가"에 대한 청사진이자, 참여자 전원이 지켜야 할 약속이다. 다른 프로젝트의 BEP를 복붙하면, 약속의 내용은 그대로인데 지킬 사람들의 상황만 달라지는 셈이다.

BEP 없이 시작한 프로젝트에서 실제로 벌어지는 일

• 설계팀은 LOD 300으로 모델링했는데 시공팀은 LOD 400을 기대하고 있었다
• 파일 명명 규칙이 팀마다 달라 CDE에서 최신 버전을 못 찾는다
• "이 속성은 누가 입력하기로 했는지" 아무도 기억하지 못한다
• 소프트웨어 버전이 팀마다 달라 모델을 열자마자 깨진다

이 모든 문제는 사실 기술 문제가 아니라 "합의된 게 없어서" 생기는 문제다. BEP는 정확히 이 지점을 막기 위해 존재한다.

BEP에 반드시 들어가야 할 6가지

BEP의 핵심 구성 요소

1. 프로젝트 정보: 프로젝트 개요, 참여자, 역할과 책임(RACI)
2. BIM 목표 및 범위: 이 프로젝트에서 BIM으로 정확히 무엇을 할 것인가
3. LOD/LOI Matrix: 객체별·단계별 상세 수준과 정보 수준을 표로 명시
4. CDE 전략: 데이터 저장소, 폴더 구조, 파일 명명 규칙, 승인 워크플로우
5. 소프트웨어 및 버전: 사용할 도구, 버전, 파일 교환 포맷(IFC 등)
6. 전달 계획: 각 단계에서 언제, 무엇을, 어떤 형식으로 전달할 것인가

LOD/LOI Matrix가 핵심이다

6가지 중 실무에서 분쟁을 가장 많이 막아주는 건 단연 LOD/LOI Matrix다. "구조 모델은 LOD 300, 배관은 LOD 200" 식으로 객체군별로 표를 만들어두면, "이 정도까지 해드리는 거 맞나요?"라는 질문 자체가 나올 일이 없다.

좋은 BEP vs 나쁜 BEP

다른 프로젝트 BEP 복붙의 함정

벤치마크 BEP를 참고하는 것 자체는 좋다. 문제는 참여자 이름, 소프트웨어 버전, LOD 기준까지 그대로 복붙하는 경우다. 그 순간 BEP는 "이 프로젝트의 약속"이 아니라 "아무도 안 읽는 장식"으로 전락한다.

작성 팁

BEP는 화려하게 쓸수록 오히려 위험하다. 지키지도 못할 수준으로 목표를 잡아놓으면, 그 자체가 나중에 "계약 위반"의 근거가 되어 돌아온다. 실무에서 실제로 지킬 수 있는 수준으로, 구체적인 숫자와 예시를 담아 작성하는 것이 핵심이다.

흔히 하는 실수

착수 단계에서 BEP를 한 번 쓰고 그걸로 끝이라고 생각하는 것. BEP는 "만들어두고 안 보는 문서"가 아니라, 설계 단계에서 시공 단계로 넘어갈 때처럼 프로젝트 국면이 바뀔 때마다 리뷰하고 갱신해야 하는 살아있는 문서다.

마무리

BEP를 제대로 쓰는 데 드는 시간은 며칠이지만, BEP 없이 진행된 프로젝트가 막바지에 치르는 대가는 훨씬 크다. "이 프로젝트에서 BIM을 어떻게 할 것인가"를 처음부터 문서로 합의해두는 것 — 그것이 BEP의 유일한 존재 이유다.