도면에서 “숫자”가 틀리면, 모든 게 틀어지는 이유
실무에서 도면 오류는 대개 “선이 잘못 그려져서”가 아니라 “단위와 스케일이 어긋나서” 생기는 경우가 정말 많아요. 특히 오토캐드로 작업할 때는 화면에서 보기엔 멀쩡한데, 출력했더니 치수가 엉뚱하게 나오거나 협력사에서 “이거 몇 배로 커요/작아요”라고 되묻는 일이 종종 생기죠. 이런 문제는 한 번 터지면 수정 시간이 눈덩이처럼 불어나고, 심하면 제작/시공 단계에서 비용이 크게 나가기도 해요.
실제로 미국의 한 건설·엔지니어링 업계 보고서(여러 업계 리서치에서 반복적으로 언급되는 내용)에 따르면, 프로젝트 재작업(rework)의 주요 원인 중 하나가 도면/모델의 불일치와 커뮤니케이션 오류로 꼽히는데요. 단위·스케일 실수는 그 불일치의 대표적인 트리거예요. “mm로 그린 줄 알았는데 inch였다”, “외부 참조(Xref)가 다른 단위로 붙었다”, “출력 스케일을 잘못 넣었다” 같은 것들이요.
이번 글에서는 오토캐드에서 단위와 스케일을 안정적으로 관리해서 실무 도면 오류를 줄이는 방법을, 예시와 체크리스트 중심으로 친근하게 정리해볼게요.
단위(Unit)부터 잡아야 하는 이유: ‘도면의 언어’를 통일하기
단위는 도면의 공용어예요. 팀/협력사/외주/제작소가 서로 다르더라도 단위가 통일되면 커뮤니케이션 비용이 확 떨어져요. 반대로 단위가 흔들리면, 치수·블록·해치·텍스트·외부참조까지 줄줄이 영향을 받아요.
오토캐드에서 단위 설정의 핵심: UNITS와 INSUNITS
많이들 UNITS만 설정하면 끝이라고 생각하는데, 실무에서는 INSUNITS(삽입 단위)까지 같이 봐야 안정적이에요. UNITS는 주로 표시 형식(소수점 자리, 각도 단위 등)과 관련이 크고, INSUNITS는 외부에서 블록이나 Xref를 가져올 때 “이 파일은 어떤 단위를 기준으로 삽입할까?”를 좌우하거든요.
- UNITS: 길이 형식(Decimal/Engineering/Architectural 등), 정밀도, 각도 단위/정밀도 등 표시 체계
- INSUNITS: 블록/Xref 삽입 시 단위 변환 기준(예: mm, cm, m, inch 등)
- 실무 권장: 사내 표준이 mm라면, 템플릿(DWT)에서 INSUNITS까지 mm로 고정해두기
대표적인 단위 사고 3가지(실제 현장에서 자주 나와요)
아래는 정말 흔한 케이스예요. “왜 이렇게 커졌지/작아졌지”의 80%는 여기서 나옵니다.
- mm 도면에 m 기준 블록 삽입: 예를 들어 1,000배로 커지거나 작아짐(특히 구조/토목/기계 협업에서 잦음)
- 인치 기반 도면을 모르고 가져옴: 25.4배 스케일 차이로 치명적 오류 발생
- 기존 도면을 복사해 쓰면서 단위 표준이 섞임: 파일마다 INSUNITS가 제각각이라 프로젝트 후반에 폭발
“1:1로 그린다”의 진짜 의미: 모델 공간과 도면 공간 역할 분리
오토캐드를 오래 써도 헷갈리는 부분이 바로 모델(Model)과 레이아웃(Layout, Paper Space)의 관계예요. 하지만 원칙은 간단해요.
- 모델 공간: 실제 크기(1:1)로 그린다
- 레이아웃: 출력 스케일을 만든다(뷰포트로 축척 관리)
모델에서 스케일로 “그려버리면” 생기는 문제
예를 들어 어떤 사람이 “출력 1:100이니까 모델에서 100배 줄여 그리자”라고 하면, 그 순간부터 도면은 지뢰밭이 돼요. 치수 스타일, 블록, 해치 패턴, 텍스트 높이, 외부참조까지 전부 계산이 꼬이기 시작하거든요. 무엇보다 다른 사람이 파일을 열었을 때 “이게 실제 크기인지, 축소해서 그린 건지” 판단이 안 돼요.
실무 표준 워크플로(권장)
- 모델: mm 기준이면 실제 치수 그대로 그리기(예: 1200mm는 길이 1200으로)
- 레이아웃: A1/A3 등 용지 설정 후 뷰포트 축척으로 1:50, 1:100 등을 지정
- 치수/문자: Annotative(주석 축척) 또는 레이아웃 기준으로 일관되게 운용
출력(Plot) 스케일이 무너지는 순간: “맞게 보이는데 왜 틀리죠?”
화면에서는 맞는데 출력하면 틀리는 문제는 대개 플롯 설정과 CTB/STB(플롯 스타일), 그리고 레이아웃 뷰포트 축척의 조합에서 발생해요.
가장 흔한 출력 오류 패턴
- 레이아웃 용지 크기(A3로 출력해야 하는데 A4로 설정)
- 플롯 스케일이 “Fit to paper(용지에 맞춤)”로 되어 있어 축척이 깨짐
- 뷰포트 잠금(Lock)이 안 되어 줌/팬 하다가 축척이 변함
- PDF 출력 드라이버 설정에 따라 선가중치가 과하게 두껍거나 얇아짐
체크리스트: 출력 전 2분 점검(효과 좋습니다)
- 레이아웃 용지: 프로젝트 표준(A1/A3 등)과 동일한지
- Plot Scale: 1:1(레이아웃 기준)인지, Fit to paper가 꺼져 있는지
- 뷰포트: 목표 축척(예: 1:100)인지 + Lock 상태인지
- 테스트 출력: 눈금자/스케일바로 100mm가 실제 100mm로 나오는지 확인
- 선가중치: CTB/STB가 표준 파일인지(특히 외주 도면 받을 때)
Xref/블록 스케일 사고를 막는 방법: 협업의 핵심 구간
실무에서 단위 사고가 가장 많이 터지는 곳이 외부참조(Xref)와 블록(Blocks)이에요. 내가 그린 건 멀쩡한데 남의 파일이 들어오는 순간 갑자기 도면이 커지거나, 글씨가 괴물처럼 커지거나, 해치 간격이 이상해지는 일이 생기죠.
Xref 단위 문제의 전형적인 사례
예를 들어 건축팀은 mm, 기계팀은 inch 기반으로 작업한 파일을 전달했다고 해볼게요. 이걸 아무 생각 없이 Xref로 붙이면 25.4배 이슈가 발생할 수 있어요. 문제는 “한 번 붙이고 나서” 나중에 알아차리면, 그 사이에 그 위에 작업한 객체들이 많아져서 되돌리기 어렵다는 점이에요.
예방 중심의 운영 팁
- 프로젝트 시작 시 “기준 단위(mm/m/inch)”를 문서화하고 공유하기
- 표준 템플릿(DWT)에 INSUNITS/치수 스타일/텍스트 스타일을 고정해 배포하기
- Xref 받으면 바로 검증: 기준 길이(예: 기둥 간격 8000mm 등)를 재서 상식적인 값인지 확인
- 블록 라이브러리도 단위별로 분리 운영(예: _MM, _M 같은 접미사 규칙)
치수·문자·해치가 ‘따로 노는’ 이유: 주석 스케일(Annotative) 이해하기
도면에서 사람을 가장 혼란스럽게 하는 게 “선은 맞는데 글씨가 너무 크다/작다”, “치수 화살표가 이상하다”, “해치가 너무 촘촘하거나 듬성듬성하다” 같은 문제예요. 이건 대개 주석 객체의 스케일 관리가 일관되지 않아서 생깁니다.
Annotative를 쓰면 편해지는 상황
한 도면에서 1:50과 1:100 뷰포트를 동시에 쓰는 경우가 많죠. 이때 텍스트 높이를 뷰포트마다 따로 조정하는 건 시간이 오래 걸리고 실수도 늘어요. Annotative를 제대로 쓰면 같은 텍스트/치수가 뷰포트 축척에 맞게 자동으로 표시될 수 있어요.
- 다중 축척 도면(상세도+평면도 혼합)에서 텍스트 크기 통일
- 치수 스타일을 “모델에서 1:1” 원칙으로 유지하면서 출력 가독성 확보
- 도면 수정 시 텍스트/치수 재조정 시간을 절감
해치(Hatch) 스케일 실수 줄이는 방법
해치는 단위·축척 실수의 피해를 크게 받는 요소예요. 같은 패턴이라도 스케일 값이 프로젝트 표준과 다르면 질감이 완전히 달라져요. 특히 도면 여러 장을 묶어 제출할 때 해치 밀도가 제각각이면 완성도가 확 떨어져 보이죠.
- 해치 스케일 기준값을 사내 표준으로 정해두기(예: 콘크리트/토사/단열 등)
- 뷰포트별 표시가 필요하면 Annotative 해치 또는 별도 레이어 전략 고려
- 외부 도면에서 해치가 들어오면 먼저 “의도된 밀도”인지 비교 검토
실무에서 바로 쓰는 “단위·스케일 오류” 문제 해결 루틴
이미 도면이 꼬였을 때는 “감으로 확대/축소”하기보다, 원인을 추적해서 한 번에 정리하는 게 좋아요. 아래 루틴을 따라가면 대부분의 스케일 문제를 빠르게 좁힐 수 있어요.
1단계: 기준 길이로 진단하기
도면에서 명확한 기준이 되는 길이를 하나 잡아요. 예를 들면 문 폭 900mm, 기둥 그리드 8000mm, 장비 외형 1500mm 같은 값이요. 그걸 재서 “상식적인 값인지” 확인하면, 단위 문제가 있는지 바로 감이 와요.
2단계: 원인 위치를 분리하기(모델/레이아웃/Xref/블록)
- 모델 자체가 잘못 그려졌나?
- 레이아웃 뷰포트 축척이 틀렸나?
- Xref가 다른 단위로 들어왔나?
- 블록이 삽입될 때 단위 변환이 일어났나?
3단계: “수정 방식”을 선택하기(상황별 추천)
여기서 중요한 건, 무조건 전체 스케일을 한 번에 바꾸기 전에 “무엇을 기준으로 정상화할지”를 결정하는 거예요.
- Xref만 문제: Xref 원본 단위를 맞추거나, 삽입 시 단위 변환 옵션을 명확히 적용
- 블록만 문제: 블록 재정의(정상 단위로 만든 블록으로 교체) 또는 삽입 스케일 규칙 통일
- 모델이 통째로 문제: 기준 길이로 스케일 팩터를 계산(예: 25.4, 1000 등) 후 일괄 스케일 조정하되, 주석/치수는 별도 점검
- 출력만 문제: 레이아웃 플롯 설정과 뷰포트 잠금부터 복구
4단계: 재발 방지 장치 만들기(가장 중요한 단계)
한 번 고친 도면이 다음 주에 또 같은 이유로 터지면 정말 허무하잖아요. 재발 방지는 “개인 습관”보다 “시스템”으로 가는 게 효과가 좋아요.
- 프로젝트 시작 시 표준 템플릿(DWT) 강제
- 도면 납품 전 체크리스트(단위/플롯/뷰포트/CTB/Xref) 운영
- 협력사에 전달할 때 “단위, 기준 축척, 출력 규격”을 메일/문서로 함께 전달
- 공용 블록 라이브러리 단위 표준화 및 버전 관리
정보 : 오토캐드 대안으로는 100% 호환성을 자랑하는 zw캐드 가 있습니다.
단위와 스케일은 ‘설정’이 아니라 ‘운영’이에요
오토캐드에서 단위·스케일 문제는 버튼 몇 번으로 끝나는 게 아니라, 프로젝트 전 과정에서 일관되게 운영해야 줄어들어요. 모델은 1:1로, 레이아웃은 뷰포트 축척으로, 출력은 1:1(레이아웃 기준)로, 그리고 Xref/블록은 단위 표준을 강제하는 방식이 가장 안전합니다.
- UNITS만 보지 말고 INSUNITS까지 함께 관리하기
- 모델 1:1 원칙 + 레이아웃에서 축척 관리로 혼란 줄이기
- 플롯 설정(용지/스케일/Fit to paper/CTB) 체크리스트 습관화
- Xref/블록은 “받는 즉시” 기준 길이로 검증하기
- Annotative로 다중 축척 도면의 텍스트/치수 일관성 확보
이 루틴만 잡아도 도면 오류가 체감상 확 줄어들 거예요. 특히 협업이 많은 팀이라면, 개인이 잘하는 것보다 “표준 템플릿+검증 절차+체크리스트” 3종 세트가 진짜 강력합니다.
