설계 검증 체크 리스트 데이터베이스

■ 설계 검증 시스템 필요성

데이터 기반 검토 시스템이 정착되면, 고참 경력자의 머릿속에만 있던 노하우가 회사의 자산(DB)으로 축적됩니다. 주니어들의 도면 품질이 빠르게 상향 평준화되는 효과를 볼수 있습니다. 처음부터 너무 거대하게 시작하기보다는, 자주 발생하는 핵심 체크 항목 20~30개 정도로 프로토타입 앱을 만들어 부서 내에 적용해 보며 살을 붙여 나가는 방식을 추천합니다.

데이터베이스 기반의 도면 검토 시스템과 피드백 루프가 정착되면, 자연스럽게 부품별 설계 표준화(Design Standardization)로 이어지게 됩니다. 경력자분의 노하우가 담긴 DB와 검증 체크 시스템이 결합한다면, 부품 표준화는 물론이고 회사 전체의 설계 자산(IP)을 한 단계 끌어올리는 강력한 무기가 될 것입니다.

---

▶ 구현 컨셉

엑셀이나 체크리스트 문서에만 의존하던 방식에서 벗어나, 데이터베이스(DB) 기반의 도면 검토 시스템을 구축하고 분석 피드백 루프까지 고려하시는 것은 도면 품질 표준화와 휴먼 에러 방지를 위한 가장 이상적인 방향입니다.

파이썬(Python)을 활용하여 [데이터베이스 설계 ➔ 도면 검토 앱 개발 ➔ 데이터 분석 및 DB 업데이트]로 이어지는 전체 시스템 선순환 구조를 만들어야 합니다. 3D CAD마다 무료 API(라이브러리)를 제공 합니다. 이것을 활용 합니다.

1. 시스템 아키텍처 및 선순환 루프

[1단계: DB 구축] ➔ [2단계: 파이썬 검토 앱] ➔ [3단계: 검토 데이터 누적] ➔ [4단계: 데이터 분석]        ▲                                                                                                                               |        └─────── (오류 다발 항목 가중치 조정 및 신규 항목 추가) ─────────────

 

2. 데이터베이스(DB) 구조 설계 (PostgreSQL / SQLite 예시)

데이터 관리를 위해 핵심 테이블은 최소 3개 구조로 분리하여 관계형(RDBMS)으로 설계하는 것이 좋습니다.

① Check_Items (체크 항목 마스터 테이블)

• ID (PK): 항목 고유 번호
• Category: 분류 (기하공차, DfM, 표제란, 조립성 등)
• Standard_Item: 체크해야 할 표준 내용
• Weight: 중요도/가중치 (기본값 1, 오류 빈도가 높을수록 자동 상향)
• Is_Active: 활성화 여부 (True/False)

② Review_History (도면 검토 마스터 테이블)

• Review_ID (PK): 검토 고유 번호
• Drawing_No: 도면 번호 (프로젝트/파트 식별)
• Designer_ID: 설계자 이름/ID
• Reviewer_ID: 검토자(PL/팀장) 이름/ID
• Review_Date: 검토 일자

③ Review_Details (검토 상세 매핑 테이블)

• Detail_ID (PK): 상세 결과 고유 번호
• Review_ID (FK): Review_History 연결
• Item_ID (FK): Check_Items 연결
• Result: 통과(Pass), 불합격(Fail), 해당없음(N/A)
• Fail_Reason: (Fail일 경우) 구체적인 반려 사유 텍스트 기입

 

3. 파이썬 기반 검토 애플리케이션 기능 설계

설계자가 도면을 릴리즈(출도)하기 전, 시스템에서 도면 번호를 입력하고 체크리스트를 하나씩 확인해야만 승인 요청이 가능하도록 통제(Gate) 역할을 수행합니다.

1) UI 구성 (PyQt / Tkinter / JavaFX 등 활용):

왼쪽에는 도면 파일 정보와 설계자 정보 입력창, 오른쪽에는 DB에서 로드된 체크 항목들이 체크박스 형태로 나열됩니다.

2) 필수 체크 로직: * 모든 항목에 대해 Pass, Fail, N/A 중 하나를 선택하지 않으면 '최종 제출' 버튼이 활성화되지 않도록 강제합니다.

Fail을 선택하면 반드시 반려 사유를 작성해야 데이터로 축적됩니다.

3) (Advanced) CAD API 연동 확장:

추후 파이썬으로 CAD API(예: Creo Async Connection 등)를 연동하면, 표제란 공란 여부나 특정 끼워맞춤 공차 기입 여부 등을 스크립트가 도면에서 자동으로 선검색하여 체크박스에 미리 피드백을 줄 수도 있습니다.

 

4. 데이터 축적 및 통계 분석 (지속적인 DB 업데이트 루프)

체크 데이터가 쌓이면 파이썬의 Pandas 라이브러리를 활용해 분기 또는 매달 분석을 수행합니다.

① 불량 빈도 분석 (Pareto Chart 활용)

• 어떤 체크 항목에서 가장 Fail이 많이 발생하는지 통계를 냅니다.
• 액션: Fail 빈도가 상위 10% 안에 드는 항목은 Check_Items 테이블의 가중치(Weight)를 높여, 검토 앱 내에서 상단에 붉은색 글씨로 강조 표시되도록 동적 업데이트합니다.

② 텍스트 마이닝을 통한 신규 항목 발굴

• 검토자가 작성한 Fail_Reason(반려 사유) 텍스트를 형태소 분석하여 자주 나오는 단어 조합을 추출합니다. (예: "C모따기 누락", "O링 치수 불량")
• 액션: 기존 표준 체크리스트에 없던 새로운 불량 패턴이 발견되면, 이를 정형화하여 Check_Items에 신규 체크 항목으로 자동/수동 추가합니다.

③ 설계자별 취약점 피드백

• 설계자별로 자주 놓치는 카테고리(예: A 연구원은 기하공차 오류가 많고, B 연구원은 DfM 오류가 많음)를 리포트로 도출하여, 설계자 스스로 어떤 부분을 더 신경 써야 하는지 맞춤형 가이드를 제공합니다.

 

---

■ 부품별 설계 표준화(Design Standardization)로 발전 하기

"도면의 오타를 잡는 수준"을 넘어, 설계 표준화까지 연결되는지 그 메커니즘 구성하기

1. '체크리스트'가 곧 '설계 표준 가이드북'이 됩니다

기존의 설계 표준 문서는 두꺼운 매뉴얼 형태로 서버 어딘가에 방치되기 일쑤였습니다. 하지만 이 시스템이 도입되면 다음과 같은 변화가 일어납니다.

• 살아있는 표준화 교육: 주니어 설계자가 도면을 다 그리고 검토 앱을 켜는 순간, 부품별(사출, 판금, 절삭 등)로 반드시 지켜야 할 표준 규칙이 눈앞에 데이터로 제시됩니다.
• 설계 단계에서의 강제성: 시스템이 승인을 통제하므로, 표준을 준수하지 않으면 다음 단계(출도 및 발주)로 넘어갈 수 없습니다. 즉, 표준화가 규칙이 아닌 '프로세스'로 강제 정착됩니다

 

2. '부품 유형별' 맞춤형 체크리스트로 진화

데이터가 쌓이면 모든 부품에 동일한 기준을 적용하는 것이 아니라, 부품의 특성이나 공정에 따라 체크리스트가 동적으로 분기되도록 발전시킬 수 있습니다.

부품별 카테고리가 정교해질수록 설계자는 "우리 회사의 사출 부품은 최소 살두께 2.0mm, 리브 두께는 살두께의 60% 이하"라는 구체적인 표준 규격을 자연스럽게 몸으로 익히게 됩니다.

3. 휴먼 에러 데이터 분석을 통한 표준 규격 개정

시스템의 진정한 가치는 "왜 이 표준이 필요한가?"를 데이터로 증명한다는 점에 있습니다.

• 데이터 기반의 설득력: 만약 특정 샤프트 부품에서 베어링 끼워맞춤 공차 오류(Fail)가 지난달에만 15건이 발생했다면, 이는 설계 표준 가이드가 모호하거나 현실과 맞지 않다는 뜻입니다.
• 표준의 지속적인 업데이트: 분석 결과를 바탕으로 "앞으로 Ø20 이하 샤프트의 베어링 조립부는 무조건 JS7 공차를 표준으로 한다"와 같이 사내 표준을 데이터 기반으로 현실성 있게 다듬을 수 있습니다.

---