GIT2PDM

Git to Product Data Management

DymaxionKim

기본 스토리

Traditional PDM/PLM

• 회사의 CAD 데이타를 제대로 관리하기 위하여, 전통적으로 중앙집중식 서버로 구현된 상용 PDM/PLM 시스템을 사용하게 된다.
• 그러나, 시스템이 지나치게 복잡해지고, 회사 사정에 맞게 커스텀 개발이 들어가면 높은 개발비용이 추가로 들어가게 된다.
• 또 유지보수를 위해 계속 관리비용이 지출되어야 유지가 가능해진다.
• 그리고 높은 복잡성 만큼, 기초 데이타를 입력해야 하는 설계팀의 부담이 가중되고 반면에 효용성은 적다.
• 때문에 실무자들이 기피하는 경향이 있다.
• 비싸서 경영자도 싫어하고, 일이 많아져서 실무자도 싫어하는 것이다.
• 좋아하는 쪽은 컨설팅 업체 뿐이다.

VCS

• 소프트웨어 형상관리를 위한 VCS 시스템을 CAD 데이타 관리용으로 사용하는 경우도 있다.
• 대표적으로 SVN(SubVersion) 소프트웨어를 사용하는 것이다.
• 비교적 간단한 스크립트만으로 구성해서, 크게 어렵지 않게 관리 가능한 것 같다.
• 그러나 SVN은 여전히 기존의 전통적 PDM과 같이 중앙집중식 구조를 가지고 있어 실무자에게 자유가 제한된다.
• 대신 브랜치 분기 등의 기능이 가능하므로, 제품의 마이너 변형 버전을 진행하거나 할 때 도움이 될 수 있다.

DVCS

• 현존하는 형상관리 시스템 중 가장 고도로 발전된 DVCS (분산형 버전관리 시스템)를 사용하자는 주장이 나타나기 시작한다.
• 고려할 수 있는 대표적인 소프트웨어는 Git 및 Mercurial이다.
• 이중에 사용자층이 거대한 Git이 더 매력적이다.
• 시스템 구축은 SVN보다 오히려 더 간단할 수도 있다.
• Git을 사용할 경우, 사용자는 서버의 데이타를 Clone해서 다운로드 받은 후, Branch를 분기시켜서 마이너 버전으로 선언 후, 마음대로 뜯어고치고 나서 결과가 좋지 않으면 그대로 멈추고, 결과가 좋다면 팀장(관리자)에게 병합을 건의하면 된다. 팀장은 Master 버전에 실무 설계자가 고친 부분을 검토후, 간단히 병합(Merge)해 주면 끝이다.
• 이렇게 개정 이력이 쌓이면, 나중에 어느 버전이 필요하다 할 때 언제든지 쉽게 추적해서 살려낼 수 있고, 상상 가능한 모든 관리 동작들이 가능해진다.
• 최악의 경우, 서버가 다운된다고 하더라도 데이타가 저장된 하드디스크에서 직접 파일을 복사해내는 등의 복구 조치가 매우 간단하다.
• 로컬에서 작업이 이루어지므로 작업 속도 저하는 전혀 없으며, Git의 무시무시한 속도와 안정성 및 강력한 기본 기능은 타의 추종을 불허한다.
• 전통적인 PDM이 가지지 못한 유연성과 경직성에서 완전히 해방 가능한 것이다.

그런데,

• 그럼 Git을 쓰면 간단하네라는 결론이 나온다.

• 다만 문제점이 몇 가지 있다.

  • 기계설계자는 대체로 소프트웨어 공학에 익숙하지 못하다. Git 명령어를 배워서 매번 쳐넣으면서 관리하는 것은 고역이 될 것이다.
  • 브랜치에서 작업할 때, 팀원간에 서로 약속을 지키지 않으면 최종 병합 할 때 데이타가 꼬여서 잘 안 될 수도 있다. 데이타가 꼬일 경우, 기술적으로 해결할 능력이 있어야 한다. 때문에 좋은 팀웍과 설계데이타의 관리능력이 있는 팀장이 반드시 존재해야 한다.
  • 설계데이타는 대부분 이진데이타이기 때문에, 텍스트 데이타 관리에 적합한 Git의 강력한 파일비교기능(Diff)은 별로 의미가 없어질 수 있다.
  • 때문에 버전 갱신할 때 마다 데이타 용량이 크게 늘어날 위험이 있다. 너무 잦은 갱신은 거대한 용량을 소모할지도 모른다.
  • 프로젝트마다 따로 저장소를 분할해서 관리해야 할 것이다. 기존의 PDM처럼 하나의 거대한 저장소에 섞어넣고 사용하는 개념으로는, 로컬 PC로의 ‘분산’이 어려워질 수 있다. (지나치게 전체 용량이 커지기 때문)

문제점에 대한 대응책

• PDM에 적합하게 잘 디자인된 클라이언트 GUI 프로그램을 하나 개발해서, 그것을 통해 서버와의 모든 관련 동작들을 처리하도록 한다. 이렇게 하면, 사용자는 어려운 Git의 개념을 굳이 배우지 않아도 GUI에서 인도해 주는대로 아무 생각없이 따라가면 될 것이다.
• 병합이 잘 될 수 있도록 팀장과 팀원들이 초기에 적응 기간을 가지는 것이 좋겠다. 실수를 시스템적으로 방지하는 수단도 개발시에 강구해 두는 것이 어떨까.
• 용량 증가는, 사내 서버를 사용한다고 가정하면 사실 별로 걱정할 일이 아닐수도 있다. 하드디스크 가격은 회사 입장에서 얼마 하지도 않는다.
• 또 데이타의 갱신(Commit)은 어떤 특정한 마일스톤에 도달했을 때만 하는 식으로 회수를 제한하는 운용 방침을 세워 두는 것도 좋겠다. 즉 프로그램 개발할 때 처럼 커밋을 굉장히 자주 하는 감각이 아니고, 기구설계 분야 특성에 맞게 더 신중하게 갱신해 가는 것이다. 갱신 회수가 줄어들면 작업자 입장에서는 번거로운 일이 줄어드는 효과도 있을 것이다.
• 전통적인 PDM처럼 거대한 저장소에 모든 설계데이타를 다 섞어놓고, 파트넘버와 BOM만으로 연관성을 찾아 들어가는 식의 운용 방식을 버리고, 프로젝트마다 별도의 저장소를 설정해서 완전히 분리시키는 것이 가볍게 움직이는데 도움이 될 것이다. 사실 부품공용화니 표준화니 뭐니 하면서 갖은 이유들을 대면서 다 섞어넣는다는 이념이 강하긴 했는데, 실제로 실무에서는 이게 굉장히 커다란 족쇄가 되기도 한다. 공용부품을 임의로 살짝 변형했다고 할 경우, 그 영향이 어디까지 미칠지 예측하기가 쉽지 않기 때문이다. 그 때문에 엉뚱한 다른 제품의 설계가 망가질 수도 있는 것이다. 차라리 완전히 분리해서 운용하는게 안전할 수 있다.

기존 사례 벤치마킹

상용 제품들

• 일단 몇 가지 열거해 본다.
  • PTC Windchill : MS Sharepoint 기반
  • CATIA PLM Express / ENOVIA Server
  • Solidworks PDM
  • Aras Innovator : MS 닷넷 기반
• 일단 MS Sharepoint에 기반한 일체의 솔루션은 고려하지 않기로 한다.
  • MS 제품을 사용하는 순간 지속적으로 직접비용이 발생한다.
  • MS WIndows OS에 완전히 종속되어 버려, 시스템의 유연성이 사라진다.
  • 그렇다고 사실 관리가 편해지는 것도 아니다.
• CATIA의 경우는 중소기업 입장에서는 최악의 정책을 밀어붙이는 중이다.
  • V6에서는 완전히 클라우드화해서 구축하도록 강요한다.
  • 모델러로서 별로 좋지도 않은 툴인데, 정책강요에 경직성까지 더해지니..
  • 답이 없다. 개인적으로 CATIA는 안쓰는걸 추천한다.
• Aras의 경우는, 오픈소스를 표방하고는 있으나 사실상은 그냥 상용 솔루션이라고 봐야겠다.
  • 컨설팅 및 커스터마이제이션을 하지 않고는 사용이 현실적으로 불가능하다.
  • 커스터마이제이션 개발 비용 및 아마존 클라우드 구축 및 유지 비용이 들어간다.
  • 지속적으로 버전업 및 관리 비용도 들어간다.
  • 옵션을 안 붙이면 제대로 된 기능이 없기 때문에 옵션도 구매해야 한다.

웹서비스 형태

• GrabCAD
• OnShape

오픈소스 솔루션들

• OpenPLM
  • Python Django 기반
  • 상당히 유니크해서 인상적이었다.
  • 개발이 중단된지 오래되어 현실적으로 사용 불가능하다.
• Docdoku PLM
  • Java 서버 기반
  • 예쁘고 심플한 UI는 마음에 들었다.
  • CAD 데이타를 직접 다루는 기능이 아직 충분히 개발되어 있지 않다.
  • 아울러 현실적으로 도입하려면 옵션 추가 등 비용이 발생할 수 밖에 없다.

DVCS 솔루션들

선행 논의들

• How to transform old CAD-PDM integration paradigms : 파일탐색기에 PDM 메뉴를 추가하는 방식, 클라우드/웹서비스 형태 등의 변화를 설명.
• FUTURE OF PDM: COMPLEXITY, FUNCTIONALITY AND OPEN SOURCE : GrabCAD, Git 등의 새로운 형태의 PDM 시대가 올 것을 예측.
• Git for PDM (본인 블로그) : Git으로 구현한 PDM 가능성을 고찰해 본 글.
• Transforming git from SCM to PDM : PDM은 객체, SCM은 파일 관리라는 차이점이 있다는 점을 지적.
• Git, and why We Need Distributed PLM : DVCS를 PDM으로 사용해야 하는 이유를 논함.
• What is behind “GitHub for CAD” marketing buzz? : Github 형태의 서비스를 CAD용으로 제공하는 사업의 가능성에 대해 논함.
• PDM, Git and Solidworks : Solidwork PDM에는 Branch 개념이 없다는 점을 지적. TortoiseGit을 Solidworks용 PDM으로 간단히 사용하는 요령 설명과 운용 경험을 언급. 댓글 중에 “560MB짜리 대형 프로젝트가 있는데, 많은 분기와 리비젼을 거쳤는데도 증가된 최종 용량은 겨우 1.7GB였다”라는 경험이 언급되어 있음.

실제 구현 사례

• Subversion Hook Scripts Creo Pro/Engineer
  • 간단한 윈도우 배치파일들로만 이루어져 있다.
  • 서버에는 SVN이 설치되어 있고, 로컬 윈도우에는 TortoiseSVN을 설치한 상태에서 운용하는 것을 상정한 것이다.
  • 배치파일의 역할은, TortoiseSVN이 커밋할 때 자동으로 CREO 파일들에 따라붙는 리비젼 넘버들을 purge하고 정리해 준 후에 커밋이 이루어지도록 중간에 후킹 동작을 하는 것이다.
  • 이로서 SVN을 CREO용의 PDM으로 사용할 수 있게 한다.
• WouldBePDM
  • 개인 프로젝트인데, 로드맵을 보면 상당히 야침차다.
  • 기본 STEP 뿐만 아니라 CATIA, CREO, Solidworks, FreeCAD까지 전부 지원하려고 하는 듯 하다.
  • 대충 보니 자동으로 BOM까지 추출해 내는 걸로 봐서 기능성도 상당히 올려 놓은 것 같다.
  • 다만 작년 봄에 마지막 업데이트 이후 아무 활동이 없는 걸로 봐서는 미완의 프로젝트가 되지 않을까 싶다.
  • 서버단은 SVN을 사용하도록 되어 있고, 로컬 쪽에는 TortoiseSVN을 설치하고 그 위에 이것을 올려서 쓰는 방식 같다.

현재 수준 요약

• 현재 시점에서는, 일단 Git 또는 SVN을 사용해서 PDM으로 사용하는 사람들이 분명히 존재한다는 것을 알 수 있다.
• 또 실제로 그것이 잘 돌아간다는 점도 알 수 있다.
• 사용자 편의를 위해 배치파일이나 GUI앱을 만들어서 사용하려고 시도하는 것도 확인된다.

개발 목표 및 현실가능성

잠정 개발 목표

• Git 서버를 중심으로 한다.
  • 가장 발전된 시스템을 사용하는 것이 당연.
• SQL 데이타베이스는 사용하지 않는다.
  • 시스템을 단순하게 하는 것이 낫겠다.
  • 기구설계자가 SQL까지 다루라는 것은 무리다.
  • 저장소별로 1개 제품을 넣는다 치면, 굳이 DB가 없어도 속도저하를 염려할 필요는 없을 것이다.
• TortoiseSVN, TortoiseGIT 처럼 탐색기 마우스 오른쪽 버튼 메뉴를 집어넣어서 하는 방식도 나쁘지는 않겠다.
  • 하지만 꼭 그럴 필요가 없이 별도의 창을 띄워서 사용하도록 해도 무방할 것 같다.
• CREO 중심으로 우선 구현하되, 추후 다른 CAD도 대응할 수 있도록 여지를 둔다.
• 커밋 할 때 반드시 특정 양식을 띄워서 내용을 기입해야만 진행 가능하도록 강제한다.
  • 추후 문서 자동 작성 기능에 대비.
  • 설변수정 관련 이력, 각종 대장 등이 정해진 양식으로 자동 작성되도록.
  • 문서 자동 작성 기능은 별도의 앱으로 따로 구현한다. (복잡도를 낮추고 유연성을 확보하기 위함)
• BOM 자동 작성 기능의 구현 가능성 여부가 관건이다.
  • 가장 쉬운 방법은, asm 파일을 어렵게 분석하지 말고, tree 파일이 있는지 반드시 확인해서 없으면 그걸 만들라고 사용자에게 지시하는 것이다. tree 파일을 신뢰하고 거기서 정보를 얻는 방법이 가장 쉬울 것이다.
  • 다만 이렇게 할 경우, 설변이 있는데도 tree에 반영되지 않을 위험이 있기는 하다.
  • BOM은 YAML 또는 JSON 등의 형식으로 저장되도록 한다.
  • Excel 등으로 BOM이 깔끔하게 자동 생성되도록 하는 기능은 별도의 앱으로 구현한다.
• 기타 기능
  • 2D 도면 : drw 파일로부터 dxf, pdf 파일을 자동 생성해내는 기능이 있으면 좋을 것 같다.
  • 이것은 CREO의 Batch 기능을 활용해서 간단하게 구현은 가능할 것 같다.
• 실행 환경
  • 앱은 가급적 OS에 구애받지 않고 윈도우,리눅스 어느쪽이든 손쉽게 컴파일되거나 실행가능하도록 개발하는 것이 좋겠다고 생각된다.
  • 이를 위해 Python 앱으로 개발해서 패키지화하는 것은 어떨까 싶기도 하다.

현실 가능성

개발자에게 필요한 기술

• Git에 관해 잘 이해하고 있을 것.
• CAD 및 BOM에 관해 이해하고 있을 것. (쉽게 개념 설명 가능)
• 멀티플랫폼 앱 개발 가능할 것. (Python 추천. 또는 cmake 활용 등.)
• 개발된 앱을 사용자가 설치하기 쉽도록 깔끔하게 패키징할 수 있을 것.
  • 앱 설치시 Python 인터프리터, 모듈, git 클라이언트 등이 모두 다 들어있도록 해서, 설치를 한 번에 쉽게 끝낼 수 있어야 함.
• 앱 개발시 Github 상에서 진행 가능할 것.

개발 비용의 분할

• 다음과 같이 앱을 분할해서 별도 프로젝트화 한다.
  • Git 서버 구축 : Github 같은 온라인 서비스를 유료로 이용해도 되지 않을까 싶기도 하다. 또는 사설로 직접 서버를 구축해도 무방할 것이다. 이때는 Gitbucket 같은 관리용 웹서비스도 함께 동작시키는 것이 좋겠다.
  • GIT2PDM : 기본 앱. (Git 클라이언트)
  • NUM2ONE : prt,asm,drw 파일의 버전넘버를 정리. (CREO)
  • TREE2BOM : BOM JSON TREE 자동 생성 앱. (CREO)
  • GIT2ISO : ISO 품질경영 인증심사용 문서 자동 생성 앱.
  • PART2BOM : 파트 속성 정보 자동 입력기 (2D 도면 내용을 인식해서 자동 생성되도록 하면 제일 좋은데.)
  • BOM2EXCEL : JSON으로부터 BOM Excel 파일을 자동 생성하는 앱.
  • DRW2DXF : drw 파일을 전부 자동으로 dxf로 생성해 주는 앱. (CREO)
  • DRW2PDF : drw 파일을 전부 자동으로 pdf로 생성해 주는 앱. (CREO)
• 분할된 프로젝트를 모두 한꺼번에 개발하지 않고, 일단 기본앱부터 먼저 개발하고, 나머지는 순차적으로 개발 진행한다.
  • 이렇게 할 경우, 각 앱들의 복잡도를 낮춰서 버그 가능성을 줄일 수 있다.
  • 순차적으로 비용이 지출되므로, 높은 비용을 한꺼번에 지출하면서 실패 위험을 떠안을 부담을 낮출 수 있다.

프로젝트 관리 기능

• 본 개발에서는 철저하게 프로젝트 관리기능은 배제한다.
• 다만, 이 기능은 다른 소프트웨어를 사용해서 대체 가능하다고 본다.
• 대표적으로 Redmine을 들 수 있다.
• Redmine 서버를 구축해 놓으면, Git 저장소와 연계시켜 스케쥴 관리 및 이슈트래킹, 위키, 관련 문서파일 관리 등을 운용할 수 있다.
• 다만 Redmine은 SQL DB를 사용하므로, DB 관리 및 업데이트가 좀 까다롭다. 서버가 뻗었을 경우 복구하는데 고생할 가능성이 있다.
• 굳이 Redmine 말고 로컬에서 프로젝트 관리는 따로 하는 방법도 있을 것이다.

사업성

• 철저하게 오픈소스 기반이기 때문에, 개발된 솔루션 역시 오픈소스화 해야 한다.
• 오픈소스 커뮤니티에서 유용성을 검증하고, 파일럿 사용자층을 확보할 수 있을 것이다.
• 이를 통해 석세스 스토리를 발굴 가능하다.
• 타사에서 도입하려고 할 경우, 교육이나 컨설팅 또는 커스터마이제이션 추가개발 등을 통해 서비스 가능하다.
• 굳이 사업화하지 않더라도, 자사에 적용하는 것만으로도 수억~십수억원 가량의 비용을 절감한 효과를 이미 거둔 것으로 볼 수 있다.

개발전 검증

• 실제 개발에 들어가기 전에 검증을 직접 해 볼 수 있다.
• 먼저 Github를 서버로 삼고, 로컬에는 Git for Windows 및 TortoiseGIT를 설치한다.
• CREO를 위해 Subversion Hook Scripts Creo Pro/Engineer과 같은 동작을 하는 스크립트를 하나 개발한다.
• 이 도구들을 이용하여, CAD 데이타를 시험적으로 관리해 본다.
• 관리하면서 장단점, 개선사항 등을 메모해서 UX 설계시 반영할 수 있도록 준비한다.

구현 방법 검토

Git Server

새로운 서버 앱을 개발하지 않고, 기존에 있는 것 중에서 골라서 쓰기로 한다.

• Online Service
  • Github, Gitlab, BitBucket …
  • CAD 데이타 저장소로 충분히 큰 용량으로 사용 가능한지 약관 등을 검토 필요.
  • 월 사용료 검토 필요. Github BitBucket
  • Solidworks 프로젝트 저장소로 사용한 예 : https://github.com/oroca/G-ROVER/tree/master/%EA%B8%B0%EA%B5%AC%EA%B4%80%EB%A0%A8/g_toy
  • Github의 경우, stl 파일은 직접 3D로 호스팅까지 된다!
• Cloud Service
  • MS Azure, AWS, Google Cloud …
  • 충분히 큰 용량을 사용할 경우, 월 사용료 검토 필요.
• Private Server
  • GitBucket, Gitlab Community Edition, Gogs, Gitea … 기타
  • 전담 관리자 지정이 상시 가능할지 현실성 검토 필요.
  • 하드웨어 구축 비용, 전기료 등 검토 필요.
  • 데이타 백업 등 안정성 복안 마련할 것.
• 이상 3개 방안 중에서 비용, 관리인력 여부 등을 검토하여 결정 가능.

벤치마킹

• GitBucket (Demo : root,root)
  • Github 서비스와 유사한 사용법
  • Wiki, 이슈트래커, 마일스톤 설정 기능 내장
  • 스케쥴 관리, 브랜치 관리 그래픽 기능은 없음
  • 상당히 심플하다.
• Gitlab Community Edition (Demo)
  • 완성도가 거의 완벽하다.
  • 대신 너무 복잡해 보인다.
• Gogs 또는 Gitea
  • GItea는 실행파일을 받아서 실행하는 것만으로 간단히 된다.
  • 엄청나게 간단하고 단순하고 포터블하다.
  • 위키 정도는 포함되어 있다.
  • 예쁘고 한글화도 어느정도 되어 있다.
  • 만일 사용하게 된다면 이것이 제일 유력할 것 같다.
• Redmine
  • 전문적인 프로젝트 관리 기능 내장
  • 간트챠트 생성 가능
  • 굳이 스케쥴 관리까지 세밀하게 할 계획이 없다면 따로 이것을 설치할 필요 없이, 그냥 GitBucket 으로 대체해도 될 것 같다.

워크 플로우

• 설계팀은 각자 자신의 계정과 저장소를 가진다.
• 자신의 저장소에는 자신이 맡은 프로젝트들이 있다.
• 새로운 프로젝트를 건드려야 할 경우에는, 팀장의 저장소에서 Fork 해서 작업한다.
• 수정작업을 완료한 후에는 팀장에게 Pull Request 한다.
• 팀장은 그것을 Merge해서 판올림에 최종 반영한다.
• 원래 프로젝트의 변형판(Class2 프로젝트)을 진행해야 할 경우에는, 팀장이 브랜치를 낸다.
• 팀원은 자신의 저장소에서 임의로 브랜치를 내는 등의 작업이 가능하나, 그것은 개인의 판단에 의한다.
• 팀장이 새로운 프로젝트 저장소를 개설할 경우, 해당 프로젝트에 필요한 README.md 파일 등을 통해 기본적인 정보를 양식에 맞게 정리한다.

GIT2PDM

• 벤치마킹 : TortoiseGIT

워크 플로우

• 작업자의 깨끗한 새 로컬 PC가 있다고 하자.
• 일단 GIT2PDM을 로컬에 설치하고, 최초 실행한다.
• 사용자 인증을 위한 로그인 절차를 거친다.
• 앞으로 모든 작업이 이루어질 로컬 저장소 루트 위치를 지정해 준다. 그러면 백그라운드에서 init 작업이 이루어진다. 이때, 표준 .gitattributes 등이 자동으로 설정되도록 한다.
• 한편, 따로 웹브라우저로 서버에 접속한다.
• 서버에 로그인 후, 자신의 저장소에서 로컬로 Clone 해 올 저장소를 선택하고 Git 주소를 복사한다.
• 다시 GIT2PDM으로 돌아온다.
• 앞서 복사한 서버 저장소의 Git 주소를 카피해 넣고 Clone 해 온다.
• Clone 되어 다운로드 받아진 저장소에서 설계 수정 작업을 완료한다.
• 로컬 쪽의 자신의 저장소 목록을 본다.
• 그 중에 서버로 Push할 저장소를 선택하고 푸쉬 버튼을 누른다.
• 그러면 먼저 팝업창이 하나 뜬다.
• 팝업창에 수정 내용을 기재하고 OK 버튼을 누르다.
• 아울러 백그라운드에서는 NUM2ONE, TREE2BOM, GIT2ISO, PART2BOM, BOM2EXCEL, DRW2DXF, DRW2PDF 등의 스크립트가 실행되도록 한다.
• 이후 pull, add, commit, push 과정이 자동 진행되어 업로드 된다.
• 동시에 팀장에게 Pull Request를 준다.
• 만일 팀장이 수정사항을 검토후 반려할 경우에는, 추가 수정 후 다시 Pull Request를 한다.

사실, 이렇게 기술된 GIT2PDM의 기능은 전부 TortoiseGIT로도 충분히 사용할 수 있다. 다만 이 프로그램으로 새로 개발하는 이유는 그 절차를 단순화하고 정형화시켜 작업자의 피로도를 감소시키기 위한 것이다. (Git에 대한 개념이 없어도 사용 가능하도록 하고, 마우스 버튼 클릭 회수와 절차를 간소화하며, 커밋 메시지의 양식을 강제하고 통일시키기 위한 목적)

UI에 필요한 요소

• 실행시 로그인 창
• 메인 윈도우
  • 설정 탭 : 로컬 저장소 루트 위치 경로, 사용자 아이디/이메일/비번/이름/사번, 저장 버튼 하나.
  • Clone 탭 : 서버 저장소 주소를 써 넣을 텍스트 위젯, 클론 해 오라는 명령 버튼 하나.
  • Push 탭 : 로컬 저장소 리스트, 푸쉬 버튼 하나.
• 커밋 코멘트 양식
  • 기존 회사 품질경영 관련 양식들을 먼저 분석해서, 필요한 정보들을 추출할 것.
  • 문제점-해결방법-결과보고 뼈대를 근간으로 기입 양식을 작성하도록 할 것.

기술 검토

• 이진파일들을 효과적으로 다루기 위한 옵션들 검토 (헤더 분석 관리, Git flow 옵션 등)
• 확장 용이성 검토 (추후 메뉴 추가를 위해 소스코드 변경 없이 설정파일만 수정해서 가능한지 등)
• 개발도구 : Python, PyQt 사용 상정. 독립된 단일 실행파일로 빌드.

유의사항

• 본 프로그램은 최소한의 기능만 갖추고, 매우 단순하게 사용할 수 있도록 한다는데 촛점을 둔다.
• 복잡한 고급 기능은 전부 다 생략한다. (로컬에서의 분기,병합 작업 등)

NUM2ONE

• 벤치마킹 : Subversion Hook Scripts Creo Pro/Engineer
• 기술검토
  • CREO일 경우
  • prt,asm,drw 파일의 버전넘버 중 앞선 번호를 purge하고 최종본만 번호 1로 정리
  • 불필요한 로그파일 등은 자동 삭제
  • 가능한 Batch 파일로 구현

TREE2BOM

• CREO일 경우
• TREE 파일이 있는지 검사하고, 있을 경우 작동함
• TREE.JSON 파일로 자동 생성

GIT2ISO

• 벤치마킹 : JSON Resume
• ISO 품질경영 인증심사용 문서 자동 생성.
• 각각의 문서들의 정보는 전부 문서별로 JSON으로 생성하고, 별도의 디자인 템플릿을 따로 마련해 두었다가 병합시켜 HTML 등의 포멧으로 출력되도록 함.

PART2BOM

• CREO 대상
• 파트 속성 정보 자동 입력기 (2D 도면 내용을 인식해서 자동 생성되도록 하면 제일 좋은데.)
• 기초 정보는 TREE2BOM에서 생성된 TREE.JSON 파일로 한다.
• 일단 각 파트 및 서브어셈블리들의 이름(파일이름)을 해당 파트의 파트네임/파트넘버로 삼는다.
• 기타 다른 속성 정보들의 입력
  • 파트리스트 팝업창을 띄워서, 직접 입력하도록 하는 방법이 좋겠다.
  • 이게 너무 구현이 번거롭다면, 엑셀로 작성한 것을 인식해서 입력받는 방법도 있을 것이다.
  • 가장 좋은 것은, 각 파트 및 서브어셈블리의 2D 도면(dxf파일)을 자동 인식해서 거기서 직접 정보를 추출해 내는 것이다. 다만 이렇게 하려면, 도면의 규격을 1종으로 완벽하게 통일하고, 도면 표제란 기입 방법 역시 철저하게 통제하는 것이다. 그러면 가능할지도 모른다.
• 아무튼 속성 입력이 다 되었으면, 이 정보를 토대로 완전한 버전의 새로운 BOM.JSON 파일을 생성한다.

BOM2EXCEL

• PART2BOM에서 생성된 BOM.JSON 파일을 기초 정보로 삼는다.
• Excel 양식 탬플릿은 별도로 준비해 둔다.
• 탬플릿에 해당 정보를 넣어서 새로 BOM.xls 파일을 자동 생성한다.

DRW2DXF

• CREO 대상
• drw 파일을 전부 자동으로 dxf로 생성해 준다.
• 구현 방법은 아마 Pro/Batch를 들여다 보면 답이 나올 것 같다.

DRW2PDF

• CREO 대상
• drw 파일을 전부 자동으로 pdf로 생성해 준다.
• 구현 방법은 아마 Pro/Batch를 들여다 보면 답이 나올 것 같다.

기대 효과

전통적 PDM과의 비교

장점

• 비용 절약
  • 직접 개발도 가능 (대신 연구 기간 및 코드 품질 부분을 고려해야 함)
  • 프리랜서에게 의뢰하여 실비로 개발 가능
• 관리 용이
  • 매우 간단한 구조
  • 서버가 뻗어도 데이타는 그냥 복사해도 되므로 데이타 추출이 간단함
• 데이터 안정성 향상 (분산 다중 저장)
  • 서버, 클라이언트에 데이타가 중복되어 존재함 (분산형)
  • 모든 팀원들이 각자 자신의 저장소를 별도로 소유함
  • 서버, 로컬PC 중 어느 한 쪽이 파괴되어도 쉽게 원상 복구 가능
• 다종 CAD 대응에 문제 없음
  • 특정 CAD 제품에 종속되지 않아 경영적으로 유리함
  • CAD 및 문서를 한꺼번에 묶어서 관리하는 것도 가능
• 작업 속도 향상
• 중앙집중식 PDM은 네트워크 속도 한계로 인해 작업 속도가 크게 낮아지는 단점이 있음
• 분산형 시스템이므로, 설계작업 자체는 그냥 로컬 작업하는 것과 다를 바 없음
• 실무자의 업무량 감소
  • 업데이트 이력이 완전 자동 관리됨. 실무자는 버전 관리에 신경쓸 필요가 전혀 없어짐.
  • BOM 작성 과정 대부분이 자동화됨
  • 품질경영 관련 서류 생산의 대부분이 자동화됨
• 하드웨어, 소프트웨어 개발 부분에도 즉시 적용 가능
  • 시스템 컴스터마이제이션 불필요
  • 개발 부문별로 팀장(마스터 저장소)만 지정하고 그냥 사용하면 됨

약점

• 제품수명주기 전반에 대한 관리 능력은 없음.
  • 프로젝트 스케쥴 관리 기능 없음.
  • 재무/영업/구매/자재/생산팀에 직접적인 영향이 없음. (전사적 자원관리 능력 없음)
• 소프트웨어 공학을 이해하는 관리자가 필요함.
  • 업데이트, 문제발생시 해결을 자체적으로 해야 함. (실비로 외주를 줘도 되긴 함)
  • 개발팀이 본 시스템을 운영할 의지가 있어야 함. (개발팀내의 워크플로우가 무너지기 시작하면 결국 유명무실하게 됨)

설계사상적 특징

• 작고 간단한 앱들을 여러개 만들어서, 그것을 조합하여 사용
• 안정성이 입증된 오픈소스 소프트웨어에 철저하게 의존
• 지루하고 루틴한 부분의 업무를 최대한 자동화한다는 목표
• 사용자가 익혀야 할 사용요령을 최대한 간단하게. (최대 30분 설명 후 곧바로 사용 가능하도록)

경영 측면

비용 절감 효과

• 전문 커스텀 PLM 시스템을 도입할 경우, 5억~20억원 정도의 구축 비용이 소요되고, 매년 1억원 이상의 유지비용이 발생.
• 저렴한 기성품 PDM 시스템을 도입할 경우, 1~3억원 정도의 구축 비용이 소요되고, 매년 수천만원 수준의 유지비용이 발생.
• 서비스형 PDM 시스템의 경우, 회사에 맞게 커스터마이제이션하는 것이 곤란. 아울러 원격지에 데이타가 저장되므로 무형자산의 안정성에 심리적 불안 요인이 상존하게 됨.

필요 인력 절감 효과

• 기성품 PDM/PLM의 경우, 반드시 컨설팅 업체가 유지보수/교육을 지속적으로 실시해야 함.
• 방대한 데이타 입력 작업을 실무자들이 매우 기피함. (핵심 기술인력의 이직 사유가 될 수도 있음)
• 회사 전산실에서는 서버의 하드웨어적 관리만 해 주면 됨.
• 소프트웨어적 관리는 개발팀 스스로 하는데 별다른 어려움이 없음. (단순한 시스템)

품질 관리 효과

• PDM/PLM 시스템 구축에서 기대할 수 있는, 일반적 품질 관리 효과를 거의 전부 동일하게 기대할 수 있다.
• 모든 개발이력, 각 버전별 설계정보들, 모든 제품의 변형판들에 대한 설계정보들이 전부 그대로 자동 축적되게 됨.
• 필요한 버전의 설계안을 찾아서 보는 것은 매우 쉬움.
• 따라서, 판매된 제품의 사후 지원에 필요한 기술정보가 100% 지원됨.

무형자산 축적 효과

• 사세가 크게 확장되어 신규 시스템으로의 마이그레이션이 필요할 경우, 매우 쉽게 대응 가능 (시멘틱하게 정보가 축적되어 있기 때문)
• 핵심 기술 인력이 교체되더라도, 인수인계 절차중 데이타 이관 절차가 불필요해짐.
• 퇴직자의 PC는 별다른 백업 없이 그대로 포멧해 버려도 무방. (필요한 데이타는 이미 서버에 다 있으므로)

실무자의 이익

신규 학습 최소화

• 기성품 PDM/PLM의 정글 같은 복잡함과 비교하면, 본 시스템은 사실 뭘 학습할 것도 없을 정도로 단순하다.

문서 작업의 고통에서 해방

• BOM, Partlist 작성 작업을 크게 효율화 가능
• 품질경영 인증용 서류 작업은 이미 다 되어 있어, 단순 검토 및 세부 수정만 약간 해 주면 끝나는 수준으로 할 수 있을 것이다.
• 부품번호 채번, 관리 등 머리가 터지는 경험에서 완전 해방.

설계데이타 버전 관리 고통에서 해방

• 설계안을 개정한 후, Push만 해 주면 끝.

파생 제품 개발시 버전 관리 고통에서 해방

• 기존 제품 설계데이타에서, 새로 Branch만 만들고 거기서 작업하면 끝.

–> 설계/개발자는 개발 자체에만 집중할 수 있도록 여건 조성

결론

개발전 효과성을 간단히 검증해 보자.

개발 시작 전 상세 설계에 만전을 기하자.

개발 목적과 효용성을 최대한 알리자.

구현은 최단기간에 끝내자.

구현 후 사용자 교육, 도큐멘테이션을 잘 하자.

적용 이후 즉각적인 효과를 최대한 과시하자.