티맥스OS를 보면서....

티맥스OS를 보면서....

이거 전형적인 '한국형 기업 문화'의 형태라는건 다들 잘 아실것 같아요.
경험적으로 보면 회사 내부 사정이 이런 식으로 돌아가면 대체로 이렇게 흘러가던데...


1단계
경영진이 매출/성과 가시화에 대한 압박으로 불가능한 목표 + 무리한 일정을 요구한다.

2단계
말솜씨가 좀 없고 진짜 핵심적인 엔지니어가 중역에게 '이런식으로는 안됩니다' 했다가 엄청 모욕만 받고 찌그러진다.  사장은 웬 어리버리한 듣보잡이 되도 않은 소리하냐고 중역에게 질책한다(사장은 누가 진짜 핵심 개발자인지 잘 모른다).

3단계
엔지니어링 능력은 좀 떨어지지만 사내정치에 능한 타입의 PM이 핵심 엔지니어를 왕따시킨다.

4단계
이때 2가지 경우로 분기가 됩니다.

    핵심 엔지니어가 관둔다.
    핵심 엔지니어가 자신의 수명과 프로젝트를 맞바꾸기고 결심하고 스팀팩을 맞고 어떻게든 계속한다.
       
5단계
핵심 엔지니어가 관뒀을 경우에는, 그대로 프로젝트가 망한다.  계속 이어지는 것 처럼 보여도 결국 망하게 되어 있다.
핵심 엔지니어가 어떻게든 구현은 해낸다.  물론 올바른 소프트웨어공학을 적용할 수 있는 상황이 아니었으므로 구현하는데만 급급할 수 밖에 없어서, 버그를 예측할 수 없고 또 버그가 나와도 구조적으로 해결하기 곤란한 경우가 많다.  화면이 나간다던가, 블루스크린이 뜬다던가 하는 눈에 확 띄는 버그가 나오게 되면 사내 품평회에서 사장 및 중역들은 핵심 개발자를 불러다가 실력이 없다는 둥 별 모욕을 다 주고 회의식 밖으로 쫒아보낸다.  PM은 핵심 개발자에게 모든 책임을 다 떠넘긴다.

6단계
경영진은 모든 것을 '엔지니어의 실력 탓'으로 돌리고, 이런 어리버리한 한 사람의 개발자에게 핵심적인 기술이 종속되는 상황은 경영학적으로 안 좋으니, 핵심 개발자가 아키텍쳐를 설계할 수 있는 권한을 다 빼앗고, 여러 명을 투입하면 더 나은 결과가 나올 거라고 믿는다.

7단계
안간힘을 쓰면서 아키텍쳐의 '우아함'을 지켜나가던 핵심개발자의 설계권한이 무시되었으므로, 그보다 실력이 한참 떨어지는 저급 개발자들이 여러명 달라붙어 소위 '입개발'을 시전한다.  아키텍쳐는 결국 누더기가 되고, 이걸 감당할 능력이 없기 때문에 입개발자들은 시간이 흘러가면서 하나 둘 조용히 퇴사한다.  물론 퇴사 이유는 다른 핑계를 댄다.

8단계 : 亡




보통 중소기업 레벨에서는 한 사람의 핵심 엔지니어에 의해 특정 프로젝트/사업의 성패가 완전히 종속되는 경우가 있죠.
이게 경영적으로는 분명 리스크 요인은 맞는데, 이걸 피하려면 제대로 된 개발시스템과 프로세스를 밟아나가야 되는데, 과정보다 결과만 중시하는 한국 특유의 문화 때문에, 이런 상황을 경영진 스스로 자초하면서 그 탓을 핵심 엔지니어에게 덮어씌우는 상황이 자주 연출됩니다.

'핵심 엔지니어'는 대체로 학구적 성향, 말솜씨가 좀 떨어지고, 사교성이 조금 덜 한 경우가 왕왕 있더군요.
(영화 이미테이션 게임에 나오는 엘런 튜링 비슷한 거라고 보면 될 듯.)


물론 요즘은 엔지니어에게 요구되는 자질이, 엔지니어링 능력 자체 보다는 사회적 스킬과 커뮤니케이션 능력, 매니지먼트 능력을 중시하는 경향이 강하긴 합니다만...
이게 과연 정답일지는 의문입니다.
아시다시피 '여러 분야에 모두 깊게 잘 하는 완벽한 엔지니어'는 잘 없습니다.
(사실 내 관점에서는 그런 사람을 단 한 명도 본 적이 없습니다.)


특히 기술적으로 도전적인 과제의 경우에는, 엔지니어링 자체에 아주 깊게 탐험해 들어가는 천재 - 사회적 멍청이형의 엔지니어가 있어야 진척이 발생하는 경우를 자주 봤습니다.
'입개발'하는 사람들만 모아놔서는 아무것도 안되죠.  그런 타입의 엔지니어들은 자기가 뭘 신기술을 도전한다던가, 아주 어려운 것을 온전히 자기 어깨에 모든 책임을 지고 몸을 던지지 않거든요.
남이 구현해 놓은 것을 보고 품평이나 하는 스타일이 많습니다.



아무튼, 티맥스의 내부 사정은 잘 모르겠지만, 프로젝트가 저따위로 기획/진행되고 완성도가 충분치 않은 상태에서 무리하게 일정이 잡혀진 발표를 강행해 버리는 것은 티맥스 회사의 경영진의 자질에서 모든 문제가 비롯된다고 봅니다.
모르긴 몰라도, 발표회장에서 컴퓨터가 얼어버리거나 다운되는 버그의 원인을 제공한 코드를 작성한, 누군지 모를 그 '핵심 엔지니어'가 그 회사 안에서 받게 될 모욕과 뒷담화를 상상하게 되네요.

'우리 회사는 쿨하니까 기술적으로 실수해도 왕따 같은거 안 시켜'

라고 말하는 사람이 있다면 한국 기업 문화의 어두운 측면을 외면하는 부류 아닐까 합니다.

STEP AP242 Standard

3D 설계데이타 교환을 위한 국제표준 중립 포멧으로 STEP이 제정된지 수십년이 흘렀는데, 아직 CAD 분야에서는 STEP Native Modeler는 개발되지 않았다. 그리고 현재 현업에서는 대부분 AP203 및 AP214를 사용한다.

우선 AP203에 관해서.

IGES를 대체하기 위해 STEP 표준이 논의되면서, 제일 먼저 나온 사양이 AP203이다. AP 명세를 구현하는 실체는, 텍스트로 표현된 Express 스키마 문법이다. 이때는 아직 XML이 나오기 전이므로, 전용의 구문 문법을 개발해서 사용한 것이다. AP203을 주도적으로 제정한 곳은 미국 국방분야의 항공회사들로 보통 알려져 있다. 즉 보잉 같은 회사를 말한다. 초창기 표준이므로 가벼운 대신 담고 있는 정보가 좀 부족하다. 예를 들어, 내부에 구성되어 있는 엔티티들의 색상을 정의하는 구문이 존재하지 않는다. 따라서 초창기 AP203 표준에 따라 구현된 STEP 파일 생성기로 만들어낸 STEP 파일을 CAD에서 읽어들이면, 색상정보가 다 빠져버려 탈색된 빨래 같은 것이 뜨게 된다.
물론 시대가 흐르면서 AP203도 계속 업그레이드 되었다. 따라서 요즘 사용하는 버전의 3D CAD 툴에서 생성한 AP203 STEP 파일들은 색상 정보를 담아낼 수 있다. 그리고, 어셈블리 구조를 모듈화하여 표현한 업그레이드 버전인 AP203-ed2가 거의 최종 버전인 것 같은데… 이 표준으로 생성할 경우에는 여러 CAD 시스템 간에 데이타 교환시 실패 확률이 매우 높아진다. 서로 제대로 구현하지 못했다는 이야기다.
좋은 예로, CREO 2에서 AP203-ed2로 STEP 파일을 생성한 후에, 그 파일을 CATIA V5R20에서 읽어들이면 형상 재구성에 실패한다. 때문에 STEP 버전을 낮춰서, CREO 2에서 구버전의 AP203으로 생성한 후에, 그 파일을 CATIA V5R20에서 읽어들이면 성공적인 결과를 볼 수 있다. 이런 식의 미묘함 때문에, STEP을 이용한 이기종 CAD 간의 데이타 교환시에는 가능한 구버전의 STEP 표준으로 파일을 생성하는 것이 유리하다. 물론 그 대신, STEP 파일 안에 담기는 정보는 더 적어지게 되고, 실질적으로는 IGES 수준의 형상 정보 정도만 교환하는데 만족할 수 밖에 없다.
사실 AP203 표준에는 더 많은 정보를 담아내서 교환하는데 써야 하는게 맞는데, CAD 시스템에서 제대로 지원해 주지를 못한다. 예를 들어, 어떤 부품이 Made 인지 Bought 인지를 구분해 주는 아규먼트가 AP203의 Express 스키마 구문 중에 분명히 있지만(PRODUCT 관련 구문), CREO 이든 CATIA이든 간에 이 항목을 제대로 매치시켜 STEP으로 생성해 주지 못한다. 그냥 없는 항목처럼 무시하는 것이다.
따라서 이렇게 생성된 STEP 파일을 PDM 시스템에 업로드 해서 해석하여 데이타베이스화하고자 해도, 형상 정보 이외의 이런 부가 정보들은 현실적으로 활용되지 못하게 된다. 각 CAD 시스템이 STEP 표준을 이렇게 대충 지원하는 이유는, 일반적으로 자사 전용 포멧을 고객에게 강요함으로써 시장지배력을 올리고 또 고객을 자사 솔루션에 종속시키기 위한 것으로 생각된다.

그리고 AP214에 관해서.

한편, AP214는 독일쪽 자동차 업계에서 주도하여 2000년 경에 확정되었다. 미국에 정면 대항하려는 목적도 있지 않았을까. 당연히 AP203보다 더 발전된 사양으로, 방대한 명세를 포함한 거대한 포멧이 되었다. 그러나 이기종 CAD간 호환성은 확실하게 AP203보다 확연히 떨어진다. AP214로 생성한 파일을 협력업체에 보냈을 때, 높은 확률로 "이 파일 읽어지지가 않아요"라는 전화를 받곤 한다.
내 경우엔, 이전 직장에서는 시제품 제작을 위해 목업 업체에 보낼 데이타는 AP214를 사용했다. 함께 서로 포멧을 조정한 기간을 거친 후에, 안정적으로 데이타 교환을 했기 때무에 문제가 없었다. 문제는 직장을 옮기고 다른 협력업체와 일을 하게 되자 그 새로운 회사에서 사용하는 소프트웨어가 달라졌기 때문에 자료 교환에 문제가 생긴 것이다. 결국 울며 겨자먹기로 AP203으로 포멧을 바꿀 수 밖에 없었다.
아무튼 AP214는 보다 더 많은 정보를 담아낼 수 있어 편리성은 높아졌지만, 이기종 CAD 간에 살짝 미묘하게 호환성이 떨어졌기 때문에 범용적으로 사용하기는 곤란한 점이 있었다.

AP242

마침내 AP203과 AP214를 합쳐서 AP242가 제정되었다. 그리고 그게 다시 업그레이드 되어 AP242-ed2 확정이 다 된 거나 마찬가지다. ed2로 올라가면서, 온갖 정보들을 더 많이 담게 되었다. PDM 관련한 각종 부가정보들, 부품간의 조립 구속조건, 파라메트릭 구속조건, 제조 관련 정보들, 전장 하네스 설계 정보, 히스토리 정보, 프리젠테이션을 위한 정보, 3차원 기구학 애니메이션을 위한 정보 등등. 이제까지의 전례를 봤을 때, 각 CAD 개발사들이 과연 AP242를 얼마나 적극적으로 준수해서 제대로 된 STEP 포멧 생성기를 만들어낼지 약간 의문이긴 하다. CAD 개발사들이 적극적으로 지원하지 않으면 사실상 죽은 표준이 될 공산도 크고…
아무튼 PTC사의 경우에는, 이 자료를 신뢰한다면, CREO 4에 AP242 관련 기능들이 다 구현되어 제공될 것으로 보인다. 경쟁관계에 있는 CATIA 및 UG 쪽도 앞서거니 뒷서거니 하면서 비슷한 시기에 나오지 않을까 싶다.
한가지 가정을 해 보자.
CAD 시스템에서 올바르게 AP242 표준에 맞도록 데이타를 만들어 낸다면?
그러면 오랫동안 사용자들이 원해왔던, 그리고 CAD 개발사들이 그렇게 오랫동안 방해해왔던 이기종 CAD 간의 그나마 쓸만한 자료교환이 가능해 질 것이다.
그렇게 될 경우, 특정 CAD의 Native Format을 지원하는 모듈을 별도 개발할 필요 없이, AP242만 지원하는 오픈소스 모듈만 가지고도 필요한 PDM/PLM, CAD 및 기타 관련 소프트웨어들의 구현이 될 것이고, 이것만으로도 프로페셔널한 수준의 진정한 산업표준 데이타 교환이 가능해져 제조업 효율이 좋아질 것이다.
개인적으로, 특정 CAD 솔루션에 종속된 설계환경은 벗어나야 한다고 본다. 생각해 보자.
CREO를 능숙하게 사용하는 구조설계자가 있을 경우, 이 사람은 CATIA를 사용하는 업체에 취업할 수 없다. 이 얼마나 바보같은 일인가?
CAD 소프트웨어가 본질이 아니고, 공학적 설계능력 자체가 핵심인데 그전에 엉뚱한 허들이 형성되어 있는 것이다.
또, CATIA를 쓰는 업체는 다른 CAD로 전환하거나 다종의 CAD 시스템을 운용하기가 어렵다. 인력 운용면에서도 그렇고 시스템 측면에서도 그렇다. (물론 대규모 자동차 업계 같은 데서는 이기종 CAD간의 조합이 이루어지기는 하지만, 악영향이 최소화되도록 모듈별로 철저하게 구분된 방식이라고 생각된다.)
따라서 CATIA에 종속된 제조업체는, 높은 비용을 고정적으로 강요받게 되고, 자금운용에서 경직적인 부분이 발생한다. 이것은 경영상의 위협요인이 아닐 수 없다.

대한민국의 현실

아마 정년퇴임하셨을 것으로 추측되는 이상헌 교수라는 분이 80~90년대에 걸쳐 초창기 CAD 분야에서 업적을 꽤 쌓았다고 알고 있다. 당시 이 분야에서의 화두 중의 하나였던 비다양체 위상 기하학을 다룰 수 있는 구조체를 구현한 CAD커널이 한창 개발되고 실용화 단계에 접어들 때의 이야기다. 현재는 비다양체 CAD커널은 그냥 아주 당연한 기본 특성이 되어 있다.
이상헌 교수의 경우, 자신의 연구에 펀딩만 좀 받았더라면 독자적인 CAD커널로 제대로 발전시킬 수 있었을 것이다. 왜냐면 같은 시기에 다른 나라들의 수준과 별 차이가 없었기 때문이다. 그러나 그런 장기적인 연구를 지원하는 시스템은 한국에 없었다. 사업가들의 눈에 띄지도 못했다. 이상헌 교수에게는 글로벌 경쟁에 나설 기회가 아예 주어지지 못했던 것이다.
그래서 지금의 한국은 그냥 CAD 및 PLM 분야에서 종속 국가가 되었다.
한국이 제조업 기반으로 흥한 나라라고들 하는데, 현재 상태로는 '제조업 2.0 (?)'이라던가 하는 말은 과대망상 내지는 허언증이다. 기초가 부실하다고 하는 좋은 예가 될 수 있을지 모르겠다.

OpenSource PLM에 관한 생각

OpenSource PLM에 관한 생각

PLM 시스템은 전통적으로 3D CAD 개발업체에서 나온 전용 솔루션을 쓰는 것이 당연하다고 생각된 시기가 있었다.
Pro/E를 쓰는 회사에서는 거기에 딸려서 붙어나오는 IntraLink 및 그보다 발전된 WindChill 같은 것을 쓰고,
CATIA는 Enovia 쓰고 뭐 이런 식으로...
간혹 해당 CAD와 붙어서 쓸 수 있는 3rd Party 솔루션도 있으나, 역시 전용인 것은 마찬가지다.

이런 전용 PLM 시스템은 거액의 도입비용 및 높은 실패위험을 감수해야 하므로
중소기업들은 그냥 없는 셈 치고 살았고
대기업들은 실무자의 고통과는 상관없이 시스템에 실무자(인간)들이 갈려들어가는 구조였다.
탁상머리 산업공학의 실패 아닌가 싶다.

최근 수년간의 동향을 보면,
특정 3D CAD에 종속되지 않는 개념의 PLM 솔루션들이 여럿 등장하고 있는데,
그와 함께 몇가지 특징들이 보인다.

(1) 웹서비스 기반 (클라우드화)
(2) 오픈소스 (커스텀 개발 가능하도록)
(3) 패키지 판매가 아닌 유지보수 서비스 판매 모델로의 전환 (서비스업화)

대표적으로 실적이 좋은 솔루션이 바로 ARAS INNOVATOR인 것 같다.
미국 MIT 출신 개발자들이 뚝딱뚝딱 만들어서 사업화 한 거라고 한다.
완성도가 높고 외국 대기업들 중에 채용한 사례가 많다.
계약을 하고, 아마존 클라우드나 MS 애저에 클라우드 서버를 개설하고, 요구조건에 맞춰 몇가지 기능 첨삭을 해서 서비스를 해 준다.
시스템 유지보수는 계약한 벤더가 알아서 해 주니 편하다.
대신 고정 비용이 들어간다.
만일 스스로 개조,유지보수할 자신이 있다면, 오픈소스이기 때문에 직접 설치해서 써도 된다.

문제는 이 녀석은 MS .Net 기반으로 개발된 거라는 점이다.
MS 윈도우 서버에서만 돌아간다.
또 (최근 버전업되어 해소된 것 같지만) 최근까지는 MS IE 브라우저에서만 이상없이 사용할 수 있다는 단점이 있었다.
아울러, 대기업 사용을 상정하다 보니 지나치게 복잡하고 거대하다.
꼭 필요한 기능이 많이 빠져 있어서, 이걸 집어넣으면 건건마다 비용이 발생한다.

간단히 말해 이름만 오픈소스고, 실무에 실제로 쓰려면 그냥 상용 솔루션이라고 봐도 무방하다.


이런 솔루션조차 부담스럽다면 진짜 오픈소스를 찾아야 할 것이다.

제일 눈에 띄는게 2가지였다.

(1) OpenPLM
(2) DocDoku

이중에 OenPLM은 파이선 쟝고(python Django) 웹프레임웍으로 개발된 것이다.
가장 해커스럽다고 할 만 하다.
구성에 필요한 유틸리티들은 전부 오픈소스를 끌어다 만들었다.
그런데도 의외로 상당히 강력하다.
VirtualBox로 패키지화된 것을 받아다가 바로 실행시켜 이것저것 사용해 봤더니 상당히 좋다.

가벼워서 반응이 상당히 빠르고,
3D STEP 어셈블리 파일을 업로드했더니 그걸 자기가 처리해서
곧바로 BOM까지 만들어준다.
전체 어셈블된 3D 모델 및 그 구성부품들 각각을 별도로 3D로 볼 수도 있다.
PDF로 된 도면은 각 파트마다 따로 업로드해 줬더니 웹브라우저에서 바로 열람이 가능하다.

부품번호를 자동으로 매겨주는 로직을 자사 규정에 맞게 고친다던가 하려면
소스코드를 좀 손봐야 하겠지만, 파이썬 쟝고 개발자가 만약 있다면 별로 어렵지 않다고 생각된다.

문제는 이 솔루션은 현재 개발이 버전 2.0에서 중단되었다는 점이다.
따라서 지속적인 향상은 기대하기 어렵다.


한편, DocDoku는 기존의 OpenPLM보다 좀 더 진보된 모습을 보여준다.
더 성숙된 JavaEE 기반으로 된 웹서버로 구성된다.
또 더욱 최신 웹기술이 대거 적용되어 있다.
화면도 깔끔한 디자인이다.
기능도 더 많은 것 같다.
사업화도 나름 잘 되고 있는 것 같으므로 개발이 갑자기 중단되거나 할 것 같지는 않다.

문제는, 서버 구성이 꽤 어려워 보인다.
내가 직접 하기는 좀 부담스럽다.
직업적인 자바 서버 개발자나 관리자라면 가능하지 않을까.

또, OpenPLM처럼 3D STEP 파일을 업로드하는 것만으로 BOM이 자동으로 구성되고 각 부품들이 자동으로 배치되는 기능이 아직 없는 것 같다.
각각의 부품들을 직접 하나하나 올린 다음에 그걸 좌표 및 오리엔테이션을 입력해서 어셈블해야 하는데 이건 정말 비현실적이다.
CATIA 플러그인이 있어서 이 경우에는 자동적인 구성이 되는 것 같기는 한데, CATIA 커넥션은 유료로 별도 제공된다.
또 국내 벤더도 아직 없다.

OpenPLM이든 DocDoku이든 간에 모두 GPL V3 기반이라, 데이타 변환 같은 기능들은 FreeCAD 같은 다른 오픈소스를 갖다 넣어 쓴다.
현명하고 효율적인 선택이다.

내가 개인적으로 보기엔, 중소기업 구조설계자에게 딱 맞는 솔루션은 오히려 OpenPLM 쪽인 것 같다.
복잡성도 낮고, BOM 구성하는데 들어가는 노력과 시간을 크게 단축해 준다.
(물론 보완해 줘야 할 것들이 몇가지 있기는 하지만, 기본 개념 자체는 아주 좋다.)

OpenPLM은 철저하게 ISO10303 STEP 기초를 둔다는 개념이 확실히 처음부터 잡혀 있었기 때문이라고 생각된다.
따라서 모든 3D 데이타는 표준 STEP 파일을 통해 받아들이게 함으로써, 단순성과 범용성을 동시에 만족한다.
아울러 이 과정에서 쓸데없는 잡 정보는 다 걸러버린다.
이런 단순성은, 맨파워가 충분해서 실무자들이 일을 분업하는 것이 가능한 대기업에게는 안 맞겠지만,
소수(1명 또는 1개 팀)의 설계자가 모든 일을 감당해야 하는 중소기업에게는 꼭 필요한 특성이다.


만약 내가 PLM을 직접 개발한다면 어떻게 할까...
아마 다음 특징과 기능들을 반드시 넣을 것 같다.

(1) 제품 전체 어셈블리 모델링 파일은 3D STEP으로 업로드.
(2) 2D 도면은 PDF 및 DWG 2가지를 반드 동시에 업로드. (DWG 파일만 올릴 경우, 웹브라우저에서 직접 보기가 어렵다.  상용 솔루션을 또 사다가 갖다 붙여야 구현 가능한데 그렇게까지 할 필요가 있을까.)
(3) 부품번호=부품명칭으로 동일화하거나 부품번호 자동으로 매겨지도록 로직 구성. (이 경우 부품명칭은 반드시 유일성을 갖도록 설계자가 잘 정해야 한다.  보통 프로젝트 네임을 두문자로 넣으면 중복 우려가 크게 줄어든다.)
(4) STEP 파일을 서버에서 자동 해석해서 BOM 및 PartList 작성, 각 부품별로 STEP 파일을 분해해서 알아서 저장.
(5) 기존에 이미 저장되어 있는 것과 동일한 이름의 것으로 중복이 발견된다면, 기존의 것을 대체하여 리비전을 올릴지 또는 기존 것을 그대로 쓸지 대화창을 통해 사용자가 결정하도록 함.
(6) 사용자가 고른 2D 도면을 서버측에서 Merge해 주는 기능, 웹브라우저에서 곧바로 볼 수 있는 기능. (하나의 파일로 합쳐서 다운로드..  실무자가 프린트하기 편하게.)
(7) 3D 모델은 WebGL로 변환해서 별도 플러그인 없이 웹브라우저상에서 직접 볼 수 있도록.  (가능하면 자동 분해 또는 수동 분해 기능, 단면 짤라보기 기능 같은게 있으면 좋겠는데 없어도 무방.)
(8) 리비전 관리는 새로 파일,정보가 갱신될 때 마다 자동으로 매겨지도록 한다.  리비전 갱신될 때는 반드시 자동으로 ECR,ECO 문서가 자동으로 생성되어 PDF로 저장되도록 한다.  이렇게 하면 ISO9001 인증 준비할 때 필요한 구비서류 작업하는데 들어가는 삽질을 줄일 수 있다.
(9) BOM, PartList에 들어가는 항목(열)을 관리자가 임의로 정의할 수 있도록 한다.  (예를 들어 부품 단가 항목을 새로 추가한다던가.)
(10) BOM, PartList는 Excel 포멧으로 다운로드 받을 수 있도록 한다.  (한국 기업에서는 Excel과 연계 안되면 안된다!)


아마 (4)번 기능이 좀 난이도가 있을 것 같은데, 능력있는 개발자라면 능히 구현 가능하다고 본다.  OpenPLM에서 구현된 바 있으니 이걸 레퍼런스로 갖다 써도 되지 않을까.

그리고 다음 기능은 뺄 것이다.

(1) 프로젝트 관리 기능 (한국 중소기업에 독불장군식 꼰대(?) 경영자들 및 변심이 잦은 고객의 존재 때문에 체계적인 프로젝트 관리가 현실적으로 어렵다는 사실을 인정하자.  정 필요하면 다른 툴을 쓰는게 낫다.)
(2) 소프트웨어 형상관리 기능 (소프트웨어 개발자의 형상관리툴은 따로 있으니.)
(3) 유저그룹 관리 기능 (불필요)
(4) PLM과의 DB 연동 (구현이 그다지 어렵지 않고, 또 필요성도 있긴 한데, 실무적으로 이걸 실제로 가동시키려면 구매팀이나 경영지원팀을 설득시켜야 하는 어려움이 존재한다.  쓸데없는 이런 노력을 할 필요가 있을까.)

아무튼 이런식으로 심플하게 구성하면 쓸만할 것 같다.

PLM에서 흔히 생각하는 3D 모델링 원시데이타를 직접 관리하겠다는 생각 자체를 버리는 것이 일의 규모를 줄여준다.
결과 데이타인 STEP 파일만 가지고 다루도록 하면 소규모 프로젝트로 충분히 쓸만하게 만들 수 있다고 생각이 된다.
그리고, 이런 컨셉으로 개발해서 오픈소스화하고, 이걸 필요한 기업에 살짝살짝 커스텀화해 주면서 저렴한 유지보수비용을 받으면서 고정수입을 얻는 비즈니스 모델도 성립하지 않을까 생각이 된다.
서버는 뭐 아마존 같은 클라우드에 올려서 해 주면, 자체 데이타센터 서버 관리도 필요 없으니까 순수한 소프트웨어 사업이 되지 않나 한다.
보통 엔터프라이즈 솔루션을 개발하는 회사나 개발자들을 보면, 그들의 고객인 '기업 경영자'를 생각하게 되는데, 영업적인 측면에서 실제 돈을 쓰겠다는 결정권자가 경영자이므로 당연하겠지만, 개발자는 그보다 실제로 그걸 사용하는 실무자(유저)를 생각해야 하지 않나 싶다.