인사. 오늘 이야기는 교각 도면 한 장을 AI와 함께 3D 모델로 옮겨 본 경험입니다. 먼저 결과부터 말씀드리고(도면에서 무엇이 보였는지), 그 일을 반복 가능하게 만든 웹앱, 마지막으로 앞으로의 계획을 이야기합니다. 모델 이미지는 모두 Rhino 8에서 직접 렌더한 것입니다.

이 발표의 결론을 먼저 보여 드립니다. 운곡교 P1 한 개 교각을 모델링하면서 도면 오류·불일치 12건, 재료표·형상·작도 누락 10건, 철근 배치 간섭 7곳을 확인했습니다. 모든 판정은 제가 확정한 것이고, 설계사 회신에 따라 바뀔 수 있습니다.

앱의 목적은 한 문장입니다. 도면을 넣으면 3D 모델과 검토보고서 초안이 나옵니다. 중요한 것은 역할 분담입니다. AI가 읽고 만들고, 검사 프로그램이 도면 값으로 다시 확인하며, 확정과 승인은 사람이 합니다. 기술 구성은 Python 엔진, 로컬에서 자동 실행되는 Rhino 8, 그리고 단순한 웹 화면입니다.

다섯 단계입니다. 도면을 올리면 앱이 변환하고 색인하고, 표에서 읽은 값을 입력값과 대조합니다. 사람이 값을 확정한 뒤에야 게이트가 돌아갑니다. 게이트는 형상부터 받침까지 차례로 만들고 검사하며, 각 단계의 승인은 사람이 합니다. 사람이 판단하는 곳은 세 군데입니다. 도면끼리 다를 때 무엇을 택할지, 도면에 없는 배치를 인정할지, 단계별 확정과 승인입니다.

이 앱에서 가장 중요한 부분입니다. 모델을 만든 프로그램이 자기 결과를 검사하면 의미가 없으니, 검사 프로그램은 생성 입력을 읽지 않고 도면에서 따로 옮겨 둔 기대값만 읽습니다. 검사기가 정말 잡아내는지 확인하려고 객체를 일부러 5밀리 옮겨 봅니다. 저장 후 다시 열어 대조하고, 앞 단계 객체가 바뀌지 않았는지도 지문으로 확인합니다. 네 가지가 모두 맞아야 PASS입니다.

숫자로 요약하면, 네 가지 교각 형식, 철근 5,570본, 게이트 검사 2,022항목이 모두 PASS입니다. 다만 이것은 제가 만든 검사로 확인한 자체 검증이고, 사람의 확정과 승인, 육안 확인이 남아 있습니다. 작업 시간 절감은 측정하지 않았기 때문에 말씀드리지 않겠습니다.

이 앱이 할 수 있는 일과 없는 일을 분명히 하겠습니다. 도면 표를 읽어 값을 제안하고, 모델과 보고서 초안을 만들고, 자동 검사로 확인합니다. 하지만 구조계산이나 시공성 검토는 하지 않고, 간섭도 아직 정량 검사는 하지 않습니다. 가장 중요한 것은 도면끼리 다를 때 어느 쪽이 맞는지는 앱이 판단하지 않는다는 점입니다. 그것은 설계사와 담당자의 몫입니다.

여기서부터는 운곡교 P1에서 확인한 내용입니다. 이 교각이 첫 번째 대상이었고, 3D로 옮기는 과정에서 도면 오류와 불일치, 철근 간섭을 찾았습니다.

열두 건을 판정 기준으로 나누면 오류 1건, 불일치 7건, 확인 필요 4건입니다. 오류는 같은 도면 안에서 값이 모순되는 경우이고, 불일치는 작도와 재료표가 다른 경우입니다. 다음 두 장에서 대표적인 것을 보여 드립니다.

대표 사례 네 건입니다. 띠철근 간격은 같은 도면의 라벨과 치수가 다릅니다. 주철근 상단은 작도와 재료표가 다릅니다. B12는 작도 28곳인데 재료표는 34본입니다. 상면 철근 높이는 치수대로면 피복이 100인데 작도 점으로는 58밀리까지 내려갑니다. 모델에는 근거가 더 강한 쪽을 적용했고, 설계사 확인이 필요한 항목으로 남겼습니다.

코핑에서는 스터럽 폭이 재료표 1,407인데 작도는 1,160, 1,740, 1,160으로 세 개로 나뉩니다. 받침에서는 대좌 높이와 후열 패드 크기가 표와 평면도에서 다릅니다. 누락도 있습니다. B9의 수량이 비어 있어 총연장을 길이로 나누어 역산했고, 교각 중심 좌표가 도면에 없어 모델은 교각 중심을 원점으로 잡았습니다.

열두 건을 원인으로 묶으면 세 가지입니다. 같은 내용을 두 군데 적어서 갈리고, 작도와 재료표를 따로 만들어서 갈리고, 치수 기준을 표기하지 않아서 갈립니다. 개선안은 각각 하나씩이고, 가장 실무적인 것은 재료표가 확정된 뒤 작도를 역으로 대조하는 검토 단계를 넣는 것입니다. 이 모델과 검사 스크립트를 그 검토에 재사용할 수 있습니다.

이제 철근 간섭입니다. 모델에서 교차하거나 가까이 붙은 위치 일곱 곳입니다. 정량 검사를 한 것은 아니고, 시공 때 위치 조정 기준이 필요한 곳을 알려 주는 목록입니다. 다음 세 장에서 이 중 여섯 곳을 Rhino 화면으로 보여 드립니다. 빨강과 파랑은 서로 만나는 두 철근, 회색은 주변 철근입니다.

왼쪽은 기둥의 크로스타이 P6입니다. 같은 높이의 네 본이 기둥 중심에서 한 점으로 교차합니다. 도면대로 모델링하면 이렇게 되고, 시공에서는 높이를 어긋나게 하는 등의 조정이 필요합니다. 오른쪽은 기초의 수직 결속근 B9가 기둥 안쪽 위치에서 기둥 철근과 만나는 모습입니다.

기초에서는 두 가지입니다. 왼쪽, 상면과 하면 철근 B5와 B6은 모서리에서 다리가 겹칩니다. 오른쪽, 기둥 주철근의 갈고리가 기초 하면 철근과 거의 같은 높이에서 방사형으로 퍼져 B7과 근접합니다. 도면 값 그대로 모델링한 결과이며, 실제 시공에서의 위치 조정은 설계사와 협의가 필요합니다.

코핑에서는 두 가지입니다. 스터럽의 하단이 하면 철근 C7, C8과 같은 높이에 놓입니다. 그리고 받침 아래 보강근 S1, S2의 다리 700이 상면 주철근 3단을 지나갑니다. 둘 다 도면에 그려진 대로 모델링했을 때 나타난 결과입니다.

네 가지 교각입니다. 운곡교는 말뚝기초에 하면이 곡선인 코핑, 산외교 울산은 말뚝 없는 직접기초, Ramp-A교는 기초판 없이 단일 현장타설말뚝에 나팔형 코핑, 옥성교는 평면이 사각 18도입니다. 형식이 이만큼 다른데도 같은 앱의 틀, 즉 읽기, 생성, 검사, 보고서 흐름으로 처리했습니다. 다만 형식마다 생성기나 검사기를 일부 추가해야 했습니다.

운곡교 P1이 시작점입니다. 앱을 만들기 전에 이 교각 하나를 스크립트 25종과 검사 5종으로 모델링했고, 이 경험이 앱의 판독 규칙과 검사 구조가 되었습니다.

두 번째는 산외교 울산입니다. 기초가 직접기초이고 코핑 끝면과 평면 모서리 형상이 다릅니다. 여기서 철근 생성기와 검사기를 형식에 맞게 추가했고, 코핑 철근을 철근별 중심선으로 만드는 방식을 처음 썼습니다. 도면이 불명확한 곳은 추론이라고 표시해 확인 대기로 남겼습니다.

세 번째는 Ramp-A교입니다. 기초판이 없고 단일 현장타설말뚝이며, 코핑은 나팔형입니다. 말뚝 철근망과 코핑 철근을 같은 방식으로 만들었습니다. 여기서 앱의 숨은 결함이 드러났습니다. 말뚝과 말뚝 철근망이 앱의 확정 대상에서 빠져 있어서, 엔진을 직접 실행할 때는 보이지 않던 문제가 앱 화면에서 단계를 막았습니다. 새 형식을 넣어 봐야 보이는 종류의 결함이었습니다.

네 번째는 옥성교입니다. 평면이 사각 18도라서 코핑 철근을 단면에서 만든 다음 같은 각도로 전단 변환했습니다. 철근은 1,899본으로 가장 많습니다. 판독에서 재미있었던 것은 재료표 수량이 해독의 열쇠였다는 점입니다. 스터럽 연직선이 106개인데 재료표의 스터럽 수량 39, 27, 40을 합친 값과 같았고, 정면 점 117개는 C18 수량 117과 같았습니다. 이렇게 작도와 재료표가 맞는지 확인하며 읽었습니다.

교각을 하나 더할 때마다 앱이 한 번씩 깨졌습니다. 운곡교 P2에서는 운곡교 값에 고정된 곳이 나왔고, 울산에서는 표 판독이, Ramp-A에서는 확정 대상이, 옥성교에서는 표의 머리행 판독과 게이트 구분이 문제였습니다. 그때마다 고치고, 앞 교각이 그대로인지 회귀 시험으로 확인했습니다. 이 과정이 일반화였습니다.

앞으로의 계획은 세 단계로 제안드립니다. 먼저 판독을 넓혀 표 밖의 치수와 철근 상세도 읽고, 남은 일반화 과제를 정리합니다. 다음으로 검사를 넓혀 간섭을 정량으로 검사하고 갈고리와 겹이음도 모델링합니다. 그다음에 측량좌표, 다른 산출 형식, T형 이외 형식으로 범위를 넓힙니다. 순서와 범위는 아직 확정이 아니라 제안입니다.

정리합니다. AI는 도면을 모델로 옮기는 일을 빠르고 일관되게 하지만, 도면이 맞는지는 사람이 판단합니다. 오늘 보여 드린 도면 오류와 간섭 목록은 설계사 확인이 필요한 초안입니다. 세 가지를 논의드리고 싶습니다. 설계 검토에 3D 간섭·피복 검토를 넣을지, 재료표 확정 뒤 작도를 역대조하는 단계를 둘지, 그리고 다음에 모델링할 교각과 앱 적용 범위입니다.