기술소식
하자가 발견됐습니다. 현장소장은 도면을 꺼내 위치를 확인하고, 담당자에게 전화해 설명하고, 사진을 찍어 메신저로 공유합니다. 상대방은 "어느 쪽이요?"라고 되묻고, 다시 "북측 창호 아래쪽"이라는 답이 돌아옵니다. 이 과정은 현장마다, 하자마다 반복됩니다.
리네임DP의 프로젝트 도면 관리 기능과 시공 기록·하자보수 요청 기능이 어떻게 연결되는지, 그리고 그 연결이 현장에 어떤 변화를 만드는지를 살펴보겠습니다.
도면은 설계 단계에서 만들어지고, 현장 기록은 따로 쌓입니다. 버전 관리가 되지 않으면 작업자가 구버전 도면을 보고 시공하는 일이 생기는데요. 설계 변경이 잦은 현장일수록 이 위험은 커집니다.
시공 기록도 마찬가지입니다. 사진은 사진첩에, 메모는 메신저에, 결재는 종이나 이메일로 흩어집니다. "언제, 어디서, 무슨 작업이었는지"가 한 곳에 연결된 적이 없는 구조인데요. 하자가 발생했을 때 원인을 추적하려면 담당자의 기억에 의존하거나, 흩어진 메신저 대화를 뒤져야 합니다.
이것은 특정 현장의 문제가 아닙니다. 도면과 현장 기록이 처음부터 연결되지 않는 구조로 운영돼 왔기 때문입니다. 분쟁이 생겼을 때 증빙이 부족한 이유, 하자 원인을 특정하기 어려운 이유가 여기서 출발합니다.
리네임DP의 프로젝트 도면 관리 기능은 도면을 단순한 설계 문서가 아니라 현장 활동의 출발점으로 다룹니다.
핵심은 위치 태그입니다. 도면 위 원하는 지점을 선택하면 위치 태그가 생성되는데요. 이 태그 하나가 시공 기록 등록, 하자보수 요청, 현장 메시지 전송의 공통 출발점이 됩니다. "북측 창호 아래쪽"이라는 텍스트 설명 대신, 도면 위의 한 점이 그 위치를 고정합니다.
버전 관리도 함께 작동합니다. 도면이 업데이트되면 변경 이력이 추적되고, 현장에서 항상 최신 도면을 기준으로 작업할 수 있게 됩니다. 대형 도면에서는 영역별 페이지 이동 마커를 통해 원하는 구역으로 바로 이동할 수 있어, 수십 장짜리 도면에서 특정 위치를 찾는 데 드는 시간도 줄어듭니다.
시공 기록과 하자보수 요청의 시작은 사진입니다. 현장에서 사진을 촬영하면, VLM이 사진 속 텍스트와 현장 정보를 실시간으로 판독합니다. LLM이 그 분석을 바탕으로 시공 기록 내용이나 하자보수 요청서를 자동으로 생성하는데요. 기록 담당자가 직접 타이핑해야 했던 내용이 사진 한 장에서 출발하는 구조입니다.
여기서 중요한 것은 메타데이터입니다. 사진이 촬영된 위치와 시간이 자동으로 기록에 태깅되는데요. "어느 위치에서 어떤 공정을 언제 진행했는지"가 사후 진술이 아닌 데이터로 남습니다.
하자보수 요청의 경우 승인 프로세스도 함께 기록됩니다. 결재 전 과정의 이력이 자동으로 남기 때문에, 승인이 언제 누구에게 이뤄졌는지가 추적 가능한 형태로 보존됩니다. 기록을 만드는 데 드는 시간이 줄어드는 동시에, 기록의 신뢰도는 높아지는 구조입니다.
이 지점에서 질문 하나를 던져보겠습니다.
도면 위의 위치 태그에 시공 기록과 하자보수 요청이 계속 쌓이면, 그 도면은 무엇이 될까요.
동일한 위치에서 반복되는 하자를 한눈에 파악할 수 있습니다. 특정 공종에서 집중적으로 발생하는 문제를 추적할 수 있습니다. 분쟁이 생겼을 때 "어디서, 언제, 어떤 상태였는지"를 도면과 사진과 결재 이력이 함께 묶인 형태로 제시할 수 있습니다.
도면이 설계 문서에서 현장 이력의 지도로 바뀌는 것입니다.
물론 이 연결이 모든 현장 문제를 해결하지는 않습니다. 다만 "사진이 메신저에 있고, 도면은 사무실 컴퓨터에 있고, 결재는 종이로 남아 있는" 구조에서, 세 가지가 도면 위의 한 점에 묶이는 구조로 옮겨가는 데는 실질적인 차이가 있습니다.
건설 현장의 기록은 오랫동안 작업자의 기억과 메신저 대화에 의존해 왔습니다. 그 구조에서는 하자의 원인을 추적하기도, 분쟁에 대응하기도 쉽지 않은데요. 도면과 현장 기록을 위치라는 공통 언어로 연결하는 것은, 현장의 경험을 데이터로 쌓는 가장 직접적인 방법 중 하나입니다.
프로젝트 도면 관리와 시공 기록·하자보수 요청 기능이 현장에서 어떻게 작동하는지 더 자세히 살펴보고 싶으시다면, 리네임DP를 통해 확인하실 수 있습니다.
