다중 소프트웨어 협업 시 파일 버전 충돌 관리 노하우

BIM 프로젝트는 건축·구조·설비(MEP) 팀이 Revit, Tekla, MagiCAD, ArchiCAD 같은 서로 다른 저작 도구로 동시에 모델을 만든다. 이 구조에서 가장 자주, 가장 비싸게 터지는 사고가 “누가 최신본을 가지고 있는지 모르는” 파일 버전 충돌이다. 어긋난 버전 위에서 며칠을 작업한 뒤에야 발견되면, 그 사이의 도면·수량·간섭검토 결과가 통째로 무효가 된다. 이 글은 버전 충돌이 생기는 근본 원인부터 파일 명명규칙, 공통데이터환경(CDE), 체크인·체크아웃과 잠금, 실무 운영 규칙까지 현장에서 바로 쓸 수 있는 수준으로 정리한다.

■ 버전 충돌은 왜 생기는가 — 세 가지 근본 원인

현장에서 관찰되는 충돌은 대부분 다음 세 가지 중 하나로 수렴한다. 원인을 구분해야 대책이 갈린다.

원인	발생 상황	결과	1차 대책
동시 편집(Concurrent edit)	같은 요소를 두 사람이 각자 로컬본에서 수정 후 저장	나중 저장이 앞 저장을 덮어씀(Lost update)	요소 단위 잠금·워크셰어링
소프트웨어 버전 상이	Revit 2024 팀과 2026 팀이 같은 모델을 열람	하위 호환 불가, 파일 승격 후 되돌리기 불가	프로젝트 착수 시 SW 버전 고정
업그레이드 비가역성	상위 버전으로 한 번 저장(Save)	구버전에서 영구히 열 수 없음	승격 전 원본 보존·전원 합의

세 번째가 특히 위험하다. Revit·ArchiCAD 등 대부분의 BIM 저작 도구는 파일을 상위 버전으로 한 번 저장하면 하위 버전에서 다시 열 수 없다. 팀원 한 명이 무심코 최신 빌드로 중앙모델을 저장하면, 구버전을 쓰는 나머지 전원이 그 순간 작업 불능에 빠진다. 그래서 “버전은 성능이 아니라 규약”이라는 원칙이 성립한다.

■ 파일 명명규칙 — 이름에 상태를 새긴다

충돌 방지의 출발점은 파일명이다. 국제표준 ISO 19650은 정보 컨테이너(파일)마다 고유 식별자를 부여하고, 그 안에 리비전과 상태 코드를 함께 담도록 권고한다. 필드를 하이픈으로 구분하는 방식이 사실상 표준이다.

필드	의미	예시
Project	프로젝트 코드	SEO23
Originator	작성 조직/회사	ARC(건축)
Volume/Level	구역·층 구분	ZZ, 03F
Type	정보 유형(모델·도면)	M3(3D모델)
Discipline	공종	A건축 S구조 M기계 E전기
Number	일련번호	0001
Suitability(상태)	정보 성숙도·용도	S2 공유용, A1 승인됨
Revision(리비전)	개정 이력	P01, P02, C01

실제 파일명 예: SEO23-ARC-ZZ-03F-M3-A-0001-S2-P03. 이렇게 하면 파일을 열지 않고도 “서울23 현장의 건축팀이 만든 3층 3D모델, 공유용(S2) 3차 개정본”임을 즉시 안다. 소규모 프로젝트라도 최소한 “프로젝트_공종_유형_리비전_날짜” 형식은 착수 시점에 못 박아야 한다. 명명규칙이 없으면 ‘최종’, ‘최종_진짜’, ‘최종_최종본2’ 같은 파일이 폴더에 쌓이고, 그 순간부터 최신본 추적은 사람의 기억에 의존하게 된다.

■ 리비전과 상태 코드 — 성숙도를 표기한다

리비전은 ‘몇 번째 개정본인가’를, 상태(Suitability) 코드는 ‘지금 이 파일을 어디까지 믿고 써도 되는가’를 나타낸다. 둘은 다른 축이다. ISO 19650 계열에서 널리 쓰는 코드 체계는 다음과 같다.

코드	구간	의미
S0	작업 중(WIP)	작성자 내부 초안, 타 공종 참조 금지
S1~S4	공유(Shared)	협업 참조·조정·검토용으로 공개
A / B	승인(Published)	승인됨(A) 또는 조건부 승인(B)
P0x / C0x	리비전 접두	P=예비(preliminary), C=계약(contractual)

리비전 표기 원칙 하나만 지켜도 사고가 준다. 내용이 바뀌면 반드시 리비전 번호를 올린다. 같은 리비전 번호를 유지한 채 내용만 덮어쓰면, 그 파일을 이미 받아 간 사람은 자기 것이 구버전인지 알 방법이 없다.

■ CDE(공통데이터환경) — 단일 진실 공급원

명명규칙과 상태 코드를 실제로 강제하는 그릇이 CDE(Common Data Environment)다. CDE는 프로젝트의 모든 정보 컨테이너가 모이는 단일 저장소이자 프로세스로, ISO 19650이 규정하는 네 개의 상태 구역으로 파일을 이동시키며 관리한다.

구역	역할	이동 조건
Work in Progress	각 팀 내부 작업 공간	작성자만 접근
Shared	공종 간 조정·참조	내부 검토 통과 시 승격
Published	승인된 배포본	정보관리자 승인
Archive	과거 이력 보존	대체본 발생 시 자동 이관

CDE의 핵심 가치는 ‘단일 진실 공급원(Single Source of Truth)’이다. 모든 팀이 이메일이나 개인 USB가 아니라 이 저장소에서만 최신본을 가져가면, “내 폴더의 파일이 최신인가”라는 질문 자체가 사라진다. Autodesk Construction Cloud(BIM 360/ACC), Trimble Connect, Bentley ProjectWise 같은 플랫폼이 이 CDE 역할을 하며, 리비전 자동 채번·접근 권한·감사 로그를 함께 제공한다. 소규모 팀이라도 NAS 한 대에 폴더 구조(WIP/Shared/Published/Archive)만 정해 운영하면 CDE의 최소 형태는 갖춰진다.

■ 잠금·체크인/체크아웃과 워크셰어링

전체 모델 파일을 통째로 주고받는 방식은 근본적으로 동시 편집 충돌을 못 막는다. 두 가지 기술적 장치로 이를 해소한다.

요소 단위 잠금(Element borrowing): Revit 워크셰어링은 한 사용자가 요소를 편집하는 순간 그 요소를 ‘대여’ 상태로 잠근다. 다른 사용자가 같은 요소를 건드리면 즉시 경고가 뜬다. 중앙 저장(Synchronize with Central) 시점에 변경분이 병합되고 잠금이 풀린다.
체크아웃/체크인: 문서·모델을 수정하려면 CDE에서 체크아웃해 잠그고, 끝나면 새 리비전으로 체크인한다. 체크아웃된 동안 타인은 읽기만 가능하다. 이 흐름이 ‘두 사람이 동시에 최신본을 각자 덮어쓰는’ 사고를 원천 차단한다.

병행해서 BCF(BIM Collaboration Format)를 쓰면 통신 비용이 크게 준다. 무거운 모델 전체를 주고받는 대신 문제가 되는 부위만 뷰포인트·코멘트로 캡처해 XML로 주고받으므로, “어느 시점 모델의 어느 요소에서 무슨 이슈가 났는가”의 이력이 남는다.

■ 실무 운영 규칙 — 프로젝트 착수일에 정할 것

착수 회의에서 SW 버전을 한 개로 고정하고 문서화한다. 프로젝트 도중 상위 버전 승격은 전원 합의 없이는 금지한다.
명명규칙·리비전 규칙을 1페이지 표로 만들어 CDE 최상단에 게시한다.
주 1회 이상 각 공종 모델을 합쳐 간섭검토(Clash Detection)를 하는 정기 통합검토 일정을 초기부터 캘린더에 고정한다. 마감 직전 몰아서 발견되는 대형 간섭을 예방한다.
중앙 저장(동기화)은 큰 작업 전후로 반드시 수행한다. 며칠씩 로컬본만 붙들고 있으면 병합 충돌 규모가 커진다.
백업은 Published 승격 시점마다 스냅샷을 남긴다. 상위 버전 승격 직전 원본을 별도 폴더에 보존한다.

■ 눈여겨볼 것

버전 충돌 관리의 본질은 소프트웨어 기능이 아니라 “언제, 어떤 규칙으로, 무엇을 공유할 것인가”를 착수 전에 합의하는 프로세스다. 값비싼 CDE 플랫폼을 도입해도 팀이 명명규칙과 상태 코드를 지키지 않으면 소용없고, 반대로 NAS 폴더 네 개와 파일명 규칙만으로도 상당한 수준의 통제가 가능하다. 도구보다 규약이 먼저다.

■ 이런 분께 도움이 됩니다

여러 협력사·공종이 서로 다른 BIM 도구로 동시에 작업하는 프로젝트의 BIM 매니저
‘최종_진짜최종’ 파일 난립과 덮어쓰기 사고를 반복 경험한 설계팀
ISO 19650 기반 정보관리 체계를 처음 도입하려는 발주처·CM 담당자

■ 참고

상태 코드(S0~S4, A/B)와 리비전 접두(P/C) 체계는 발주처·프로젝트마다 세부가 다르므로, 착수 시 BIM 수행계획서(BEP)에 정확한 코드표를 확정해 전원이 동일하게 적용해야 한다. Revit 워크셰어링의 요소 대여·중앙 동기화 동작은 저작 도구 버전에 따라 UI 명칭이 바뀔 수 있으니 사용 중인 빌드의 도움말을 함께 확인한다.