예상하지 못한 데스크탑, 델 Optiplex 7070 Ultra

Optiplex 7070 Ultra, 델의 비즈니스 데스크탑 라인의 새로운 제품이다. 하지만 정말 누구도 예상치 못했을 것이다. 제품 설계의 의도는 충분히 이해하겠지만, 새로운 제품으로서 자랑하고 광고할만한 지는 의아스럽다. 한 마디로 델 Optipelx 7070 Ultra를 표현하자면 모니터 분리형 iMac(이하 아이맥)이라고 해야 하나 싶다. 물론 아이맥은 모니터 그 자체가 본체라는 점에서 7070 Ultra와는 차별된다. 사실 사용자 입장에서 아이맥의 가장 큰 부담은 모니터 자체가 본체라는 점인데, 부품 업그레이드나 수리에 상당한 노하우가 필요할 뿐더러 위험도 감수해야 한다. 그런 점에서 7070 Ultra는 모니터를 제외한 본체가 이른바 모니터 스탠드로 바뀌게 되었다는 점에서 아이맥에서의 이런 부담은 없다. 오히려 업그레이드 기능의 측면에서는 아이맥 운용의 단점을 해소했다고 볼 수 있다.

그럼에도 이런 다소 우스꽝스러운 모습은 어쩔 수 없다. 물론 모니터 스탠드에 기존 데스크탑 본체의 기능을 몰아 넣었다는 것은 충분히 높은 평가를 받을 만하다. 하지만 한편으로는 노트북에서 모니터를 빼고 그리고 배터리를 빼고 나서, 노트북을 형태를 좁고 길게 만들었다는 점도 인정하지 않을 수 없다.

우리의 책상 공간을 차지하는 주범은 이른바 PC가 등장한 이래로 모니터와 키보드 그리고 마우스였다. 물론 가장 큰 덩치를 차지한 것은 본체였지만, 기술의 발전으로 본체의 크기나 두께는 점점 줄어 들었지만 모니터는 점점 커져갔다. 다행히 LCD, LED 기술이 적용되면서 무게와 두께는 비교할 수 없는 정도로 가볍고 얇아 졌지만 크기는 더욱 관리하기 힘들 정도로 커져만 가고 있다. 두께가 얇아진 만큼 책상 위에 멀찍이 설치하여 차지하는 공간이 크게 줄어들기는 했지만, 어차피 손이 닿는 위치에서 벗어날 수는 없다. 그리고 그 앞에는 아직도 널직한 크기의 키보드와 작지만 또한 널직한 공간을 필요로 하는 마우스가 차지하고 있다. 한마디로 거의 지난 40년간 컴퓨터가 놓여진 책상 위의 상황은 변한 것이 없다.

유일한 탈출구는 랩탑(Laptop), 노트북 컴퓨터였다. 노트북 컴퓨터를 통하여 책상 혹은 사무실이라는 한계를 벗어날 수 있게 되었다. 하지만 노트북이 책상 위로 돌아오게 되면 대부분의 경우 키보드, 마우스 그리고 모니터가 연결되기도 한다. 아예 노트북을-언제 이동할 지 모른다는 측면에서 구입한 이유가 있기는 하지만-데스크탑 컴퓨터처럼 고정하여 사용하는 경우도 많다.

그러고 보면 결국 곧 다가올 미래의 데스크탑 환경은 iPad에 키보드나 연결된 형식이 일반적일지도 모르겠다. 나 역시 처음에는 iPad와 같은 스마트 태블릿 PC의 기능과 활용성에 회의적이었지만, 이제는 PC 수준에 근접했거나 이미 성능에서도 앞서기도 하고 있다. 특히 처음부터 iPad 등으로 기존 PC를 대체하여 사용했다면 그 운용성과 생산성은 전통적인 컴퓨터 사용 습관에 젖은 이들의 상상을 초월하고 있음을 확인하고 있다.

그런 측면에서 애플은 이미 iPad로 스마트 태블릿 시장을 선도하고 있지만, HP나 Dell 혹은 Lenovo 등은 관련한 시장에서 기존 브랜드 네임에 걸맞는 성과를 보여주지 못하고 있다. 이제 본격전인 데스크탑과 스마트 태블릿의 경쟁이 다시 불붙지 않을까 싶은데, 이러한 상황에서 Optipelx 7070 Ultra의 보여주는 모습은 역시나 의아스럽다.

Apple Mac Mini 2018 그리고 서버

애플의 맥 미니 2018이 서버로서의 역할을 위해 도입되는 것에 대해 주변에서 우려가 많았다. 사실 스스로도 우려되는 바가 없지는 않았다. 하지만 기능적인 측면에서 문제가 없는 것은 분명했다. 그럼에도 이미 UNIX 서버 그리고 Windows NT 서버에 익숙한 입장에서 Mac 서버 더욱이 Mac mini 서버라니, 걱정스러운 의견을 피력하지 않는 것이 비정상일 것이다. 문제는 도입된 Mac mini 2018의 성능은 지금껏 우리가 경험한 그 어떤 서버 보다도 가격대비 성능이 우수하다는 사실을 인정할 수 밖에 없다는 것이다. 물론 수십개의 멀티 프로세서와 코어를 탑재한 서버와 비교할 수는 없으니, 워크그룹 수준의 Windows NT 서버에 비교하여 하는 말이다. 특히 가상화 환경에서 다수의 Windows Server를 구동하는 목적에서 VMWARE 기반 Windows Server에 비해 Parallels 기반 Windows Server가 훨씬 안정적이라는 경험에 비춰 볼때, 이는 데스크탑 수준에서의 macOS가 Windows OS에 비해 훨씬 높은 신뢰성을 보여주었다.

무엇보다도 설치 공간에 대한 고민이 없다는 점이 운영하는 입장에서는 작지만 엄청난 차이라고 할 수 있다. 덕지덕지 붙게 되는 케이블만으로 관리가 벅찬데 커다른 본체가 차지하는 물리적 심리적 부담은 말할 필요도 없을 것이다. 그냥 관리용 모니터 아래에 장착하는 것으로 위치는 잡혔다.

사실 대부분의 사람들이 새로 도입된 맥 미니 2018을 존재를 인식하지 못한다는 점에서 그 크기가 주는 놀라움은 매우 신기한 경험이다. 유사한 HP Z2 mini의 경우에는 작기는 하지만 컴퓨터처럼 보이기 때문에 쉽게 인식되는 반면 그야말로 검은 색 상자 외로는 보이지는 않은 맥 미니 2018의 외형 디자인은 의도했든 하지않았든 공간 사용 효율면에서는 다른 제품에 비교할 바가 아닌 듯 하다.

또한 i5 마이크로프로세서를 탑재한 데스크탑 모델이지만 6 개의 멀티코어, 64 GB RAM과 512 GB Flash Drive 그리고 네 개의 썬더볼트 포트는 서버로서 기대한 싱글 혹은 듀얼 가상화 서버로서의 역할을 최소 사양은 충분히 제공한다. 한마디로 사용자 입장에서는 하드웨어 측면에서는 따로 손 댈 필요가 없다고 본다. 향후 성능이 부족하면 다른 의견 없이 대체하는 것으로 마무리된다. 사실 서버 운용에서 가장 고민되는 것이 지속적 업그레이드와 그에 따른 비용에 대응되는 신규 시스템 구입과 마이그레이션 문제이다.

특히 Mac OS는 Windows OS에 비해 가공할만한 마이그레이션 기능과 신뢰성을 제공한다는 것은 경험해 보지 않고서는 이해하기 힘들다. 이전까지 사용한 Mac 시스템에서도 거의 10년 동안 재설치를 한 기억을 없는 것 같다. 새로운 OS 업데이트를 통해 기존 어플리케이션과 사용 환경 그리고 설정 정보들이 거의 99.9% 유지된다는 점은 놀라움을 넘어 신기하기까지 했다. 물론 이미 Mac 사용자라면 익히 알고 있는 사실이기도 할 것이다.

쓸데없는 맥 미니 2018에 대한 찬양성 포스팅이 되고 말했지만, 실제 사용자를 고민스럽게 하는 부분은 언제나 하드웨어가 아니라는 것이 함정이다. 새로운 Parallels 환경에서 Windows Server가 얼마나 안정적으로 구동될 지 사실 고민스럽기도 하다. 때문에 만약을 대비하여 VMWARE에서 같은 환경의 서버가 대기할 수 있도록 대응 환경을 함께 꾸미고 있다.

워크스테이션 맥킨토시의 여정

스티브 잡스가 Lisa 그리고 Mac을 출시하면서 가장 기대했던 가운데 하나는 애플의 컴퓨터가 워크스테이션 시장으로 진입 것이었다. 잡스가 1984년 Macinotosh 첫 모델를 대학이나 연구소에 보급하려고 동분서주했던 것은 널리 알려진 사실이다. 솔직히 무모하기에 앞서 어이없는 행보이기도 했다. 당시 Apollo나 SUN의 워크스테이션과 Macintosh를 비교하자면 같은 계열의 모토로라 MC68000 마이크로프로세서를 사용했다는 것 외에 아무런 동질성, 유사성 혹은 비교 대상이 없었다. 그의 생각을 정확히는 모르겠지만 단순하게 보자면 같은 계열의 CPU를 사용했으니 그 정도 수준의 성능을 제공할 것이라고 생각했고 그 정도 수준으로 비싸야하지 않나 생각했을 지 모른다. 분명한 것은 그가 제대로 워크스테이션을 사용해보지 않았을 것이라는 점이다. 혹은 접해본 워크스테이션이 Lisa나 Macintosh에 대한 그의 이상에 비춰 오히려 워크스테이션이 주는 감흥이 보잘 것 없었는 지도 모르겠다.

어쩄거나 잡스 혹은 애플은 Macintosh 이후 꾸준히 애플의 컴퓨터를 워크스테이션 시장으로 진입 시키고자 했다. 1987년 Macintosh II의 등장은 애플은 물론 마이크로컴퓨터 산업 전체의 시각에서 애플이 워크스테이션을 출시한 것으로 인정했다. 물론 짧은 기간 동안 찬사였지만, Macintosh II는 이전 잡스의 Macintosh가 아닌 애플 그리고 스컬리의 컬러 디스플레이와 모듈러 구성의 PC 혹은 워크스테이션이라는 점은 분명했다. 그러나 문제는 하드웨어가 아닌 운영체제 그리고 어플리케이션이었다. 워크스테이션으로서 Macintosh II는 워크스테이션에 기대하는 사용자의 요구를 만족시켜주지 못했다. 그저 애플의 빠른 컬러 컴퓨터 시스템이었다.

이후 Macintosh II 라인은 비록 일반 PC 수준으로 전락하지는 않았지만 그렇다도 워크스테이션으로서도 인정 받지 못하고 그저 애플의 고가 비즈니스 컴퓨터로서 자리잡았다. 그리고 다시금 워크스테이션 시장으로 진입하려는 애플의 시도는 Macintosh IIfx로 부활하게 되었다. 이전 Macintosh II 시리즈 가운데 최고의 성능을 제공했고 UNIX 기반 운영체제인 A/UX도 안정된 상태였지만 수 많은 이유로-물론 가장 큰 이유는 비싼 가격과 확장성 한계였지만-실망스러운 결과를 맞보게 된다.

1980년대 후반 80386에 대응될 수 있는 68030 마이크로프로세서 시대에서 실패를 맛본 애플의 워크스테이션 전략은 80486에 대응되는 68040 시대에서 또 다시 시도되는데, Macintosh Quadra 900/950 등과 같은 거대한 타워 형식의 워크스테이션 모델이었다. Macintosh Quadra 시리즈는 곧 하이엔드 라인에서 PowerPC 마이크로프로세서가 등장하면서 미드-레인지 라인으로 추락하게 되지만, 그런 상황에서도 Quadra 950은 나름 선전하면서 가장 오랫동안 생산된 애플의 컴퓨터 가운데 하나가 된다.

애플은 PowerPC 마이크로프로세서를 탑재한 Power Macintosh 시대에 와서는 워크스테이션 시장 진입을 포기한 듯 했다. Macintosh 그리고 Power Macintosh의 운영체제는 그 성능 개선와 상관없이 지난 10년간 거의 변화가 없어 보인 반면, PC 진영에서의 Windows 3.1 그리고 Windows 95/98로의 진화는 확실히 인상적이었다. 더욱이 Windows NT의 등장으로 Power Macintosh는 하드웨어 측면이 아닌 운영체제 그리고 소프트웨어 측면에서 경쟁력을 상실해가고 있었다. 엔지니어링 워크스테이션 진영에서도 POWER, PA-RISC, SPARC, MIPS 등 64-비트 RISC 마이크로프로세서를 무장하면서 PC 수준에서는 접근하기 힘든 벽을 만들고 있었다.

엔지니어링 워크스테이션과 X86 PC 워크스테이션 가운데 존재감 없는 Power Macintosh의 상황이 반전되기 시작한 것은 잡스가 다시 애플로 복귀하고 Next STEP에 기반한 Mac OS X를 탑재하면서 부터라고 할 수 있다. Power Macintosh 역시 마이크로프로세서가 PowerPC G3, G4 그리고 G5로 진화했지만 여전히 가격대비 성능에서 경쟁력을 유지할 수 없는 실정이었다. 그럼에도 애플의 워크스테이션 시장 진입에 대한 시도는 계속 되었고 2006년에는 Power Mac G5가 등장한다. 하드웨어 성능면에서 그리고 새로운 운영체제를 탑재했다는 사실에서 명실공히 워크스테이션으로서의 위상을 가졌다고 할만했다. 그러나 여전히 애플의 워크스테이션은 가격대비 성능에서 사용자들을 만족시키지 못하고 있었다.

애플의 하이엔드 머신과 운영체제는 단순히 성능면에서 워크스테이션 레벨에서 존재했다고 할 수 있었지만, 워크스테이션을 운용하는 목저으로서의 어플리케이션은 턱 없이 부족했다. 운용할 수 있는 3D CAD나 CAE 어플리케이션은 극히 제한적이었다. 산업 디자인이나 멀티미디어 분야 등 일부 제한적 영역에서 명맥을 유지하는 정도였다.

하지만 넘을 수 없을 것 같았던 엔지니어링 워크스테이션 시대도 가격대비 성능에서 X86 PC 워크스테이션에 의해 서서히 위협을 받기 시작했다. 그리고 21세기에 들어면서 20세기 엔지니어링 워크스테이션 시대를 화려하게 구가했던 RISC 마이크로프로세서 기반 UNIX 워크스테이션들이 X86 마이크로프로세서 기반 Windows NT 워크스테이션(PC 워크스테이션)으로 전환도기 시작했다. 몇몇 남은 RISC 워크스테이션들도 마지막을 향하고 있었다.

이런 시점에서 애플은 결국 맥킨토시 플랫폼의 마이크로프로세서를 PowerPC에서 X86 Xeon으로 전환하고 본격적으로 X86 기반 PC 워크스테이션 경쟁에 뛰어들지만, 애플의 제품 답게 사용자들은 Mac OS X 환경이 주는 특혜를 제외하고는 가격대비 성능 차이를 수용할 수 밖에 없었다.

이전 Power Mac G5의 모습을 한 이른바 1세대 Mac Pro는 Xeon 마이크로프로세서 기반의 멀티 프로세싱 환경을 제공하면서 보다 향상된 기능의 Mac OS X로 본격적인 PC 워크스테이션으로서의 경쟁력을 갖추게 되지만, 상대적으로 새로운 마이크로프로세서의 채용이 늦어짐에 따라 사용자들의 불만을 사기도 했다.

2013년 Xeon E5에 기반한-이른바 연탄맥이라는 비아냥을 받기도 했던-새로운 2세대 Mac Pro가 등장하면서 기존 워크스테이션에 대한 선입견을 가지고 있다면 도저히 용납할 수 있는 기능과 구성으로 많이 이들을 당황하게 만들었다. 물론 성능 대비 엄청난 가격 역시 달라지지 않았다.

일반적으로 HP의 워크스테이션을 보자면 새로운 마이크로프로세서나 칩셋이 출시면서 어김없이 새로운 모델이 등장하면서 이전 모델을 구형으로 만들어 버리는 것이 일상이었다. 반면 애플의 Mac Pro는 출시 후 거의 변화가 없거나 새로운 마이크로프로세서의 탑재가 새 소식이 될 정도로 사용자들을 애달게 만들었다. 이런 와중에 2017년 등장한 iMac Pro가 Mac Pro를 대체하는 것은 아닌가 하는-별 부담없는-불안감을 주기도 했다.

그리고 2019년 예상치 못한 등장한 새로운 3세대 Mac Pro는 지난 수십년간 애플이 워크스테이션 진입을 위한 노력한 결과로서-다소 어색한 외형 디자인에도 불구하고-성능과 가격면에서 호평을 받았다는 점에서 이전과 다른 평가를 받고 있다.

그렇더라고 이전 Mac Pro 문제가 완전히 해결되었다고 보기는 어렵다. 기본 사양으로 8-코드 Xeon 마이크로프로세서, 32GB RAM, Radeon Pro 580X 그래픽 카드, 그리고 256GB SSD를 갖추고서 약 US$6,000 수준이라니, 이 정도라면 분명 HP나 Dell의 동급 워크스테이션의 가격은 Mac Pro의 60% 수준일 것이라 예상할 수 있다. 다만 이전과 다른 점은 확장성이다. 이전까지 Mac Pro는 확장성에 제한되거나 2세대에서처럼 확장 자체가-일반적 시각에서-봉쇄된 경우와는 다른 워크스테이션에 기대하는 수준의 확정성을 갖추었다고 볼 수 있다. 아직 출시가 되지 않아 완전한 사양과 지원 항목을 확인할 수는 없지만 분명 이전 세대에 비해 많은 개선을 위한 노력을 보인다.

물론 내가 Mac Pro를 구입하는 일은 없을 것이다. 거의 30년 가까이 애플 컴퓨터의 사용자였지만 또한 HP 컴퓨터의 사용자이기도 했다. 내게 워크스테이션은 언제나 HP 9000이었고 지금은 Z의 이름으로 가지고 있다. 그럼에도 새로운 애플의 맥킨토시 워크스테이션이 어찌될 지 궁금하다.

AutoCAD 버전 이정표 – 2014 & 2019

얼마전 AutoCAD 2020 버전이 공개되었다. 아직 2018 버전도 제대로 사용하지 않고 있는 상황에서(DraftSight를 주로 사용하는 관계로) 벌써 2010 버전이라니 싶었다. 하지만 설치 요구 사양을 보니 이전과 큰 변화가 있음을 알게 되었다. 바야흐로 마침내 64-비트 운영체제만을 지원하는 AutoCAD가 되었다. 그리고 AutoCAD의 기나긴 역사에서 최근 수년간 가장 주요한 버전이 결국 2014과 2019로 마무리될 듯 하다.

Windows XP를 지원하는 최종 버전으로서 AutoCAD 2014 그리고 Windows 7/8.1을 지원하는 최종 버전으로 2019가 기억될 수 있다. 특이하고도 주요한 것은 2019 버전은 Windows 7/8.1의 32-비트과 64-비트를 모두 지원한다는 사실이다. 물론 실질적 사용성이나 생산성의 차이는 있겠지만 어찌되었든 설치되고 구동된다는 사실이 주요한 경우도 있을 것이다.

사실 아직도 32-비트 운영체제와 64-비트 운영체제 사이의 성능 문제는 일반 사용자에게 어떤 유익의 비유 여부로서도 중요한 문제는 아니다. 어차피 시간이 지나면서 64-비트 하드웨어의 지원이 지속되고 결국 64-비트 운영체제를 수용할 수 있는 환경으로 정리될 것이기 때문이다. 문제 아닌 문제는 아직도 32-비트 운영체제를 구동해야만 하는 32-비트 하드웨어를 가진 Windows 환경을 이용하는 일부 사용자에게 국한된다. 물론 이러한 선택이 필수적 사안이 되는 경우는 매우 특별한 경우로 국한될 것이다. 대부분은 HP XW6000을 아직도 구동하는 그 자체의 의미를 두고 있는 이 블로그의 소유자와 같은 이들이다.

엔지니어링 어플리케이션 부문에서 AutoCAD가 차지하는 비중은 성능 여부나 활용성 여부를 떠나서도 매우 주요한 의미를 가진다. 오래되고 느리지고 그래도 AutoCAD 정도는 구동할 수 있는 구형 시스템이라면 그나마 활용성을 인정할 수 있다. 하지만 이제 그리고 앞으로는 최신 AutoCAD는 구동할 수 없는 구형 시스템이 되고 말것이다.

AutoCAD 설치 지원 OS 요구 사항

그런 의미에서 AutoCAD를 구동할 수 있는 구형 시스템이라는 딱지를 붙일 수 있도록 만드는 버전이 XP(32-비트 및 64-비트)의 경우라면 2014 버전 그리고 마지막 32-비트 지원의 경우라면 2019이 그 대미를 장식하게 되었다.

PS. Mac 버전에서는 이미 오래전부터 64-비트 지원이 시작되었으니 굳이 그 시작과 끝을 언급할 필요는 없을 것이다.

DraftSight의 마지막 자유 행보

DraftSight가 처음 출시되었을 때가 생각난다. 이게 정말 기업에서 무료로 사용할 수 있는가 싶어 Dassault에 직접 문의하기도 했다. 사실 답은 정확하지는 않았다. 유료 혹은 무료의 여부를 확인해주었다기 보다는 사용 대상에 제한을 두지 않는다는 약각은 애매한 답이었다. 아마 내부에서조차 명확하지는 않았지 않나 싶기도 하지만, 어차피 제대로 사용하기 위해서는 유료 서비스인 Professional 패키지를 구입해야 하니, 일반적인 2D 도면 생성 용도로서는 아무런 문제가 없다고 생각했다. 사실 수년이 지난 후 국내 판매처에서의 인식은 여전했다. DraftSight가 뭔지를 아는 판매처는 없었다. 물론 SolidWorks 판매하기도 덕찬 그들에게 무료 어플리케이션이 무슨 관심이 있겠는가 싶었다.

DraftSight에 관심을 가지게 된 계기를 연구소나 설계부서의 구조 조정(인적 구조 조정이 아닌 기술적 구조 조정)를 진행하면서 였다. 솔직히-그때나 지금이나-각 설계자 개인의 행태를 비난할 생각은 없지만, 대부분은 설계자들은 AutoCAD의 기능적 범위에서 벗어난 그 어떤 새로운 시도 조차 관심이 없었다. 사실 AutoCAD 자체의 기능적 문제는 전혀 없었다. 실제 문제는 도면을 생성하는 과정이 절대적으로 한 설계자의 능력이나 한계에 제한되어 있다보니 전체적인 제품 개발이나 기술 개선 과정 보다는 단순한 일상 업무 혹은 개별 실적 수준으로 전락되어 버렸다는 것이다.

다시 말해 설계자의 자의적 판단에 의해 도면 추출의 시간이 결정된다는 점이다. 관리자 입장에서는 결과를 보는 과정에서 일관성이 없다보니 계획 수립에 곤란을 겪기도 한다. 물론 어느 정도 업무 파악이 된 후에는 직원들도 적당히 업무 생산성을 조절하여 눈치껏 대응한다. 이런 결과는 대개 관리자나 부서장이 공학도 출신이 아닌 경우 더욱이 엔지니어링 부문의 경험이 없다면 더욱 심각했다. 반대로 나의 경우는 드러내지는 않았지만 상당한 반발로 업무 파악 자체를 지연시키고 있음을 확인했다. 물론 난 어떤 경우라도 회사나 경영진 보다는 개별 직원들의 입장을 지원하고자 했기 때문에 굳이 드러내고 불만을 경고하지는 않았다. 어차피 그들이나 나나 모두 남의 돈 받는 입장이니. 하지만 업무 경험이나 근속이 길어진 담당자들의 대응은 심각한 수준이었다는 점은 분명했다.

설계 및 개발 환경의 구조 조정이 시작될 수 있었던 것은 경영진 특히 회장의 관심이 컸다는 점이다. 그러니 개별 직원이나 팀장들이 드러내고 반발하지는 않았지만 공공연히 내게 불만을 제기하거나 나름의 방식대로 업무 태만 수준으로 업무를 조절하여 대응하기도 했다. 다시 말하지만 난-언제나(가능하면) 그들의 편에 서고자 했다. 그런 입장에서도 종종 선을 넘는 경우를 보았지만 사태를 크게 만들지 않고 내 수준에서 감당했다. 어차피 구조 조정 자체는 나나 그들의 의지와 상관없이 진행될 것이니.

회사의 설계 및 제품 개발 과정의 구조 조정은 3D CAD 시스템과 PDM/PLM 시스템 도입이 핵심 중 하나였다. 마침 회사의 ERP도 20년이 지나 새로 업데이트되고 있었기 때문에 맞물려 진행되었다. 그 가운데 유지보수 서비스를 한번도 이용하지 않고 있는 AutoCAD를 굳이 비용 지출 없이 사용할 수 있는 DraftSight로 대체하는 것이었다. 그리고 남은 비용은 차라리 3D CAD 시스템의 구입 비용에 이용하는 것이었다.

하지만 지난 수십년 2D CAD 시스템, AutoCAD 기반의 제도 환경에서만 진행되었던 설계 플랫폼을 변경이 결코 쉽지 않았다. 자세히 언급하자면 수 없는 우여곡절이 있었지만, 결국 DraftSight가 AutoCAD를 대체하는 거창한 계획은 실패했다.

만일 DraftSight가 AutoCAD를 성공적으로 대체했다면 3D CAD 시스템 역시 당연히 SolidWorks가 채택될 가능성은 거의 100%였다고 할 수 있고, PDM 시스템 역시 SolidWorks의 ePDM을 사용하게 되었을 것이다. 하지만 AutoCAD가 그대로 유지된 덕분에 전혀 다른-물론 Autodesk의 제품이 아닌-3D CAD 시스템과 PDM 시스템으로 전환하게 되었다.

DraftSight가 아닌 AutoCAD를 유지해야 하는 수만 가지 이유 중 최종적으로 해결하지 못한 것은 어이 없지만 기존 화면과 다르다는 설계자들의 푸념과 이를 빙자한 업무 지연 덕분이었다. 이러한 행태가 가능하게 된 것은 회사 입장에서는 어떤 시스템으로의 전환이든 기존 시스템 보다 나은 혹은 빠른 업무 성과를 기대했지만, 실질적 설계 업무를 장악한 몇몇 고참 직원들 중심의 이른바 적폐 행태로 인한 업무 지연에 적절히 대응하지 못했기 때문이다. 사실 프로젝트를 관리하는 내 입장에서도 충분하지 못한 비용 한도 내에서 완벽한 대응 체계를 마련해 줄 수도 없었기 때문에 결국 그들의 입장을 옹호하지는 않았지만 현실적 타협을 할 수 밖에 없었다. 난 그때도 여전히 그들의 편에 서 있었다.

그 결과는 설계와 개발 부서에는 2D CAD 시스템과 3D CAD 시스템이 공존하는-최악이라고 할 수 있지만 사실은 어느 회사에서나 일반적인-상황이 되었다. 단언컨데 2D CAD 시스템과 3D CAD 시스템이 공존하게 되면, 시간의 문제일 뿐이자 3D CAD 시스템의 역할이 줄어들 수 밖에 없다. 이것은 마치 간단한 계산을 하기 위해 단순한 이른바 쌀집 계산기과 스프레드시트 프로그램을 운용하는 컴퓨터 시스템 중 하나를 선택하는 문제가 비슷하다. 어차피 도면의 빠른 생성과 수정이 업무의 큰 부분을 차지하는 입장에서 아직 서튼 3D CAD 시스템을 통하여 도면을 생성하는 것보다 이미 손에 익숙한 2D CAD 시스템을 사용하는 도면을 생성하는 것이 훨씬 빠른 성과를 보여주기 때문이다. 물론 새로 학습해야 하는 신입 사원들 입장에서는 어느 경우나 비슷한 노력이 필요하겠지만 수 년에서 길게는 십수 년을 AutoCAD를 사용해 온 입장에서는 엄청난 양의 도면 수정 건에 시간을 들이는 것이 차라리 새로운 학습의 노력보다 훨씬 편하기 때문이다.

또한 회사의 실적에 따라 정리되는 직원 역시 새로운 신입 사원들의 비중이 크다보다 상대적으로 3D CAD 시스템 운용 인력은 자주 바뀔 뿐만 아니라 수도 줄어들게 되었고 설계와 개발 업무는 더욱더 기존 2D CAD 시스템에 의지하는 경우가 늘어나게 되었다. 결국 회사는 경영 실적 저하를 인한 또 다른 구조 조정의 일환으로 3D CAD 시스템의 운용을 포기하기로 했다. 그리고 관련한 PDM 시스템의 운용 규모나 수준도 크게 축소될 수 밖에 없었다. 사실 그즈음 회사에 3D CAD 시스템이나 PDM 시스템을 제대로 운용할 수 있는 인력은 거의 없었다. 새로운 제품 개발이 거의 없다보니 PDM 시스템은 그저 기존 도면 정보를 확인하는 용도로 제한되어 사용되는 수준으로 전락했다. 물론 3D CAD 시스템이나 PDM 시스템의 유지보수는 더 이상 지속되지 못했다.

그런 와중에 몇일 전 Dssault에서 DraftSight의 유료화에 관한 공지를 보았다. 사실 포스팅의 처음에서 언급했지만 업무적으로 DraftSight를 사용하고 있다면, 무엇보다도 SolidWorks의 ePDM 시스템을 사용하고자 한다면 Professional 라이센스를 구입해야 했기 때문에 큰 변화는 아니라고 볼 수 있다. 하지만 단순히 DraftSight를 AutoCAD(혹은 AutoCAD LT) 대체 용도로 사용했다면 큰 문제에 당면하게 되었다고 볼 수 있다.

물론 유료화에도 불구하는 년간 지출 비용적인 측면에서는 AutoCAD LT에 비해서는 DraftSight Standard 버전 기준 약 1/4 수준 그리고 AutoCAD에 비해서는 DraftSight Professional 버전 기준으로 약 1/8 수준이다. 드문 경우이긴 하지만 만일 AutoCAD를 3D CAD 시스템이라고 본다면, DraftSIght Premium 버전 기준으로 약 1/3 수준이다. 즉 가격적인 잇점은 여전하다고 볼 수 있다. 그러나 기존 Professional 버전을 사용하지 않은 대부분의 경우 공짜로 사용하다가 작더라도 비용을 지불해야 한다는 사실에서 거부감이 발생할 수 밖에 없다. 사실 이 정도 비용이면 AutoCAD 호환의 다른 2D CAD 시스템에 소요되는 비용보다도 훨씬 저렴하다.

그러나 DraftSIght 사용자 입장에서 감정적으로 가장 열받는 부분은 유료화 자체가 아닌, 기존 무료 버전에 대한 사용 제한이라고 본다. 아직까지는 Windows 운영체제에 한하지만 2019 버전부터는 무료 버전이 제공되지 않으며, 기존에 무료로 다운로드하여 사용하고 있는 2018 이전 버전에 대해서는 2019년말까지만 사용이 가능하도록 한다는 사실이다. 솔직히 10년 넘어 무료로 사용해온 입장이라면 이러한 정책 변화에 차라리 그 동안 고마웠다라고 할 수 있겠지만 업무와 관련한 일이라면 만만치 않은 것이 현실이다. 하지만 멋모르게 2019 버전을 다운로드하여 실행하고 나면 이전 2018 혹은 그 이하 버전을 다시 다운로드할 수 없을 뿐 아니라 재실행도 불가능하다는 점에서 황당한 경우를 당하는 선의(?)의 피해자가 생길 수도 있다.

나 역시 솔직히 이런 정책 변화의 예상에도 불구하고 기존 다운로드 버전은 계속 사용할 수 있지 않을까 생각했지만, Dassualt가 바보가 아닌 다음에야 그렇게 할 이유는 없을 것이다. 다행스럽게도 어느 경우든 DraftSIght를 포함한 AutoCAD 호환성을 지닌 수 많은 2D CAD 시스템은 DWG 포맷의 정보가 특별한 변환 과정없이 그대로 사용할 수 있기 때문에 기술적인 어려움을 없을 것이다. ePDM 시스템 운용을 위한 이미 DraftSight Professional을 사용하는 입장는 사실 큰 변화가 없다고 보는 것이 더 옳은 표현일 것이다.

결론적으로 DraftSight의 정책 변화에 이런저런 의견이 있기는 하지만 그 동안의 사용에 대한 고마움도 물론이고 혹은 예상보다 늦은 변화라는 점에서 큰 불만은 없다. 남은 과제 혹은 관심은 이제 DraftSight가 누렸던 그 영광을 누가 차지하게 될 것이냐는 것이다.

PS. Draftsight의 이런 정책 변화는 현재 Windows 버전에 적용되고 있기 때문에 Mac OS나 Linux 버전은 그대로 다운로드가 가능하다. 하지만 위의 사항을 보고나니 왠지 2019 버전을 다운로드하기 두렵기도 하다.

AutoCAD vs. AutoCAD LT

놀랍게도 AutoCAD 사용자들 상당수가 자신이 AutoCAD를 사용하는 지 아니면 AutoCAD LT를 사용하는 지 모른다. 설마할 수도 있겠지만 일단 내 주변의 주변 상황에서 문의하니 거의 100%라고 예측된다. 사용하는 입장은 물론 공급하는 입장에서도 마찬가지였다. 덕분에 언제부터인가 그분들에게 AutoCAD는 그냥 150만원 정도하는 CAD 프로그램으로도 통용된다.

물론 AutoCAD LT가 AutoCAD 보다 못하다는 사실을 주장하거나 비하하는 바는 아니다. AutoCAD LT는 AutoCAD와 다른 영역의 사용자를 위한 제품이다. 가격 차이가 있듯이 기능에서도 차이가 있는 것은 분명하다. 그렇다고 그 차이는 제공하는 기능의 차이일 뿐 성능의 차이는 아니다.

회사에서도 AutoCAD는 AutoCAD LT를 함께 사용되었다. 대략 10 카피 정도에서 AutoCAD LT가 1/3 정도였지만 결국 AutoCAD든 다른 CAD 시스템이든 AutoCAD LT가 있는 이상 하위 호환성을 유지하기 위해 AutoCAD LT가 기준이 될 수 밖에 없었다. 이후 AutoCAD LT는 LT 레벨에서 계속 업그레이드되었다.

도면을 보거나 작성하는 직원들도 앞서 말한 상황과 다르지 않게 AutoCAD와 AutoCAD LT를 구분하지 않고 그냥 CAD라고 통칭했다. 기계 특히 설계 전공인 내 입장에서 거슬리는 말이기는 했지만 부하 직원들이 거의 금속이나 재료 전공이라 딱히 이해할 것으로 기대하지는 않았다. 물론 기계 전공이라고 다르지 않을 것이니.

설계 플랫폼은 2D CAD, 3D CAD 따질 것 겉이 모두 CAD로 통칭되었고, 시물레이션 플랫폼도 그냥 모두 DEFORM으로 통일되었다. 하지만 정작 우리가 운용하는 것은 DEFORM이 아니라 MSC Marc와 Transvalor FORGE 3D였다. CAD 시스템 역시 AutoCAD가 아닌 Pro/Engineer(CREO)였지만 아무도 구분하지도 이해하지도 못했다.

하지만 가장 놀라운 사실은 AutoCAD와 AutoCAD LT 차이에서 AutoDesk의 공식적인 입장은 AutoCAD는 3D CAD로(엄밀히 말하면 2D CAD와 3D CAD가 통합된) 그리고 AutoCAD LT는 완전한 2D CAD로 규정하고 있다. 결론적으로 틀린 사실은 아니지만 AutoCAD를 사용하는 그 어떤 사용자도 AutoCAD를 3D CAD 시스템으로 생각하지는 않을 것이라 생각한다. 물론 AutoCAD를 활용하는 입장에 따라 다르겠지만 개인적으로 이러한 의견은 기계 분야에 한정된 생각이다.

기본적으로 AutoCAD와 AutoCAD LT 간의 차이는 관리 수준에 따른 것이라 볼 수 있다. 가장 큰 예가 AutoCAD LT에서는 네트워크 라이센스를 지원하지 않았다. 물론 이러한 구분은 개인 혹은 몇명 수준의 사용자 입자에서는 큰 차이가 없을 수 있겠지만 십 수개 에서 수 백 개의 라이센스를 사용하는 입장에서는 분명한 차이가 있다.

그리고 AutoCAD는 운영하는 상황에 맞춰 커스터마이징될 수 있도록 개발 도구를 사용할 수 있다. 물론 메뉴 구성이나 화면 설정을 커스터마이징이라고 할 수는 없다. AutoCAD 메뉴의 플러그-인이나 애드온 앱에 본다면 AutoCAD LT에 대한 AutoCAD의 확장성과 활용성을 이해할 수 있다.

결국 기능적인 입장에서 AutoCAD LT는 AutoCAD의 서브 파트로써의 역할이 분리된 제품이라고 할 수 있다. 그냥 도면 작성을 위한 용도로서 최적화된 기능을 갖춘 완벽한 2D CAD 시스템으로서 고전적인 AutoCAD가 했던 역할을 다시 구현한 제품으로 성공했다고 볼 수 있다.

Mac OS에서 OneDrive 리셋

OneDrive가 기능성과 편의성 측면에서 DropBox나 Google Drive에 비해-개인적인 경험에 비춰-부족한 점이 적지 않다. 그럼에도 여러 경쟁 제품이 제공하는 못하는 서비스로 사용하지 않을 수 없도록 만들고 있다. 결국 마이크로소프트가 출시하여 성공 내지는 유지하고 있는 서비스는 운영체제 그리고 운영환경에 내포되는 수준에 따라 결정되었다고 본다. 그러므로 OneDrive의 사용 환경이 얼마나 Windows 운영체제에 잘 융합되는냐에 따라 그 미래가 결정되지 않을까 싶다.

일반적이지 않는 상황이라고 생각되지만 개인적인 입장에서는 운좋게 비즈니스 OneDrive 계정을 여러개 운용할 수 있다. 이럴 경우에 OneDrive는 여러 개의 계정을 동시에 운용할 수 있는 기능을 제공한다. 로컬 컴퓨터 시스템의 저장 공간이 충분하다면 엄청난 클라우드 저장 용량을 운용할 수도 있다.

그러다보니 생기는 문제인데, Windows 환경에서는 이런 증상이 크게 문제가 되지는 않았는데, Mac OS 환경에서 OneDrive 서비스가 중단 혹은 오류가 나는 경우가 종종 있다. 이때 새로이 OneDrive 서비스를 다시 시작해도 마찬가지의 결과를 보게 된다. Mac OS 환경에서 겪는 문제인지는 물라도 Windows 환경에서도 여러 개의 계정 운용에서 유사한 오류를 겪기도 했다.

그럴 경우 Mac OS 환경에서 OneDrive 서비스를 완전히 새로 설정해야 하는데, 시스템에서 OneDrive 서비스를 완전한 삭제하고 새로 설치하는 과정으로 대응할 수 있겠지만 매번 이런 식으로 대응한다는 것은 번거롭다. 이럴 경우 시스템에서 OneDrive 설정을 리셋하고 다시 시작하는 방법을 찾아 보았다.

우선 오류 여부에 상관없이 OneDrive가 구동되고 있는 상태라면 구동을 중지한다. 그리고 Applications 폴더에서 OneDrive를 선택한 후, 오른쪽 마우스 버튼을 클릭하면 패키지 내용 보기를 선택하여 들어 갈 수 있다. 다음으로 파인더에서 Contents 폴더 내의 Resources 폴더에서 ResetOneDriveApp.command 혹은 ResetOneDriveAppStandalone.command를 실행한다.

이후 OneDrive를 시작하면 설정 과정이 새로 시작되며 기존 폴더를 설치 경로로 선택하여 설정을 완료한다.

비평의 수용자

비평 혹은 평론 어떤 식으로 부르든 그 대상은 생산자를 향한다. 문학적 작품이나 공학적 기술적 제품 역시 마찬가지다. 작품의 창작자 그리고 논문이나 제품의 저자 혹은 개발자이다. 하지만 문제는 생산자로서의 그 대상에 대한 비평은 예상할 수 없지만 종종 대상이나 생산자의 추종자들을 자극하게 된다. 쉬운 예로 요리를 대하여 비평은 원재료의 맛을 살리는 기준으로 평가하지만 대부분의 고객은 익숙하거나 새롭다고 느껴지는 맛을 선호하기 때문에 그 평가를 수용하기 어렵다. 하지만 알아야 하는 것은 그 비평은 자신들의 미각이나 음식 선호도를 평가하는 것이 아니라는 것이다. 음식을 사이에 두고 요리사와 비평가 사이의 경쟁일 뿐이다. 이 경쟁에는 승자도 패자도 없다. 서로 각자의 역할을 할 뿐이다. 마치 예술가가 예술성과 대중성 사이에서 고민하면서도 대중성을 위해 예술성을 희생할 때 그 상황을 인식하도록 하고 이를 통하여 예술가는 일반적인 평가의 기준을 뛰어 넘는 작품을 만들 수 있게 된다. 손님이라 불리는 대중은 그 사이에서 즐거운 시간을 보내면 된다. 하지만 미디어의 효과인지 혹은 고객들의 미적 감각이 높아져서인지 비평을 비난하고 작품을 무시하기도 한다. 어느 한 쪽이 마음에 들지 않는다면 비평을 무시하고 작품을 외면하면 된다. 반대로 그 비평을 기준으로 작품에 감춰진 면을 파악할 수 있고 혹은 작가의 다음 작품을 기대할 수도 있다.

만일 역사가 비평가에 의해서가 아닌 요리사나 예술가에 의해서만 기록되는 작품이라고 한다면 얼마나 왜곡되고 편집될 것인가. 실제 우리는 이 땅의 역시에서 세계 땅의 역사에서 그런 경우를 수 없이 알고 있다. 또한 그런 일이 지금도 이어지고 있다. 만일 고객의 눈이 비평가의 눈이 된다면 비평가는 자리를 잃을 것이고 요리사나 예술가는 고객의 눈과 입이 두려워 세상에 나오지 못할 수도 있다.

하지만 자신이나 작품에 대한 비평을 대중의 인기에 대한 비난으로 왜곡하여 비평을 외면하는 이는 예술가의 자격이 없다. 물론 감정적으로 비평을 겸허히 수용하기란 쉽지 않다. 비평 자체가 어쩌면 자신의 역량에 비례하여 비난 수준의 강도로 다가올 수 있기 때문이다. 역시 비평가도 비평에 대한 또 다른 비평이나 다른 의견을 수용할 수 있어야 하지만 마찬가지로 쉬운 일이 아니다. 기술적인 문제에서는 이에 대한 대응의 범위나 일정 부분 객관적으로 진행될 수 있지만 예술적인 분야에서는 명확한 기준으로 대응하기가 힘들기 때문에 감정적 접근으로 진행하게 되기도 하고 심지어 서로 감정적 대응을 유발하기도 한다.

하지만 오늘날 세상의 고객은 비평을 비난하고 작품을 무시하는 것으로 자신의 존재를 익명의 세상에서 인정받기를 기대하고 있다. 아무런 유익이 없는 일이라고 할 수 있지만 자신의 시간과 노력을 그런 무모한 일에 낭비하고 있다. 마치 지지하는 야구팀이나 축구팀의 승리와 패배를 자신의 일로 등치시키고 있다. 그 팀의 승리와 패배는 자신의 삶에 아무런 영향을 주지 않으며, 그 팀의 승리가 쌓인 스트레스를 날려버지지도 그 팀의 패배가 스테리스를 더 자극하지도 않지만 그렇게 위안하고 있다. 시간 낭비, 인생 낭비라고까지 할 필요는 없겠지만.. 자신의 삶을 괴롭히는 원인을 놔두고 특별한 한 인물이나 집단에 몰입하는 것이 효율적인지는 모르겠다. 물론 그 자체에 집중하는 것이 취미 수준이나 전문 영역까지 이어진다면 또 다른 차원의 문제다.

컴퓨터 관련 인물로서 스티브 잡스나 빌 게이츠를 젊은 청년부터 어린아이에 이르기까지 롤 모델로 삼은 시절이 있었고 아직도 그 여파는 지속되고 있다. 애플이나 Apple II 그리고 Macintosh에 관해서는 몰라도 스티브 잡스라는 인물을 알고 있다. 하다 못해 아이팟이나 아이폰 출시에 관련된 것 조차 모르면서 롤 모델로 삼는 이를 보고서 당황한 적이 있었다. 예전 워즈니악을 존경한다는 이가 그의 무얼 만들었는 지 아예 모르는 것을 보고 내가 느낀 반응도 그랬다. 한 인물의 배경이나 작품이 아닌 인물 그 자체에 집중하다보면 자신의 행동과 판단의 목적을 잃게 된다.

정치에 있어서도 마찬가지이다. 한 인물에 집중하고 찬사를 보내거나 혹평을 하는 경우도 다르지 않다고 본다. 왜 또는 무엇과 같은으로 시작한 의문을 던지는 것이 아니라 한 인물의 성장 배경이나 외모 등에 휘쓸리는 실수가 어떤 사태를 초래하는 지 처절하게 경험했다. 객관적 사실을 우선으로 외부적 요인을 참고하는 것이 정상적임을 알고 있음에도 주변의 분위기나 미디어의 편집에 현혹되어 잘못된 선택을 하고 다시 이를 스스로 합리화하기도 한다.

결국 좋은 작품이 세상이 드러나고 역사적 산물로서 전해지기 위해서는 비평이 필요하다. 좋은 비평과 나쁜 비평은 없다. 하지만 객관적이고 합리적인 비평가가 있는 반면 기회주의적인 대중에 맞추는 비평가도 있다. 안타깝게도 손님인 대중은 그 구분이 힘들다. 역사에는 대중의 인기와 바램이 아닌 비평가의 비평만이 남을 뿐이다. 그래서 기회주의자이자 대중에 영합하는 비평가를 주의해야 한다. 역사를 왜곡할 수 있기 때문이다.

코딩에 대한 시각 차이

최근 코팅 교육에 대한 관심이 매우 높다. 특히 초등학생 저학년에서도 코팅 학습이 진행되는 경우에 대한 보도를 많이 본다. 하지만 코딩 혹은 프로그래밍이라는 절차적 기능적 수행 능력에 대해 많은 시각차가 있다. 더욱이 나의 경우처럼 8~90년대 PC를 접하고 학교에서 공학 문제 해결을 위해 프로그래밍을 학습한 많은 이들은 오늘날 코딩의 미래 그리고 이를 위한 코딩 교육에 대하여 지극히 냉소적이다. 특히나 BASIC이나 FORTRAN 혹은 C와 같은 프로그래밍 언어를 수치 해석 프로그램을 작성한 이들은 대개 스스로를 프로그래밍을 잘한다고 생각한다. 나 역시 같은 부류로서 이러한 표현이나 생각이 완전히 틀렸다고 보지 않는다. 문제 해결을 위한 답을 얻기 위해 스스로에게 필요한 프로그램을 작성하고 이를 운용한 입장에서는 충분히 이해할 수 있다.

하지만 스스로나 일부 제한된 인원이 추구하는 결과를 얻기 위한 프로그램 작성이(개발이 아니다) 아닌 프로그래밍을 지금 언급하는 코딩, 프로그래밍의 목표와 동일시 할 수는 없다. 어플리케이션 그리고 최근에는 앱이라도 불리는 프로그램은 자신은 물론 타인의 함께 나아가서는 비용을 지불하고 사용할 수 있도록 개발되는 전 과정을 거쳐 만들어지게 된다. 단순히 계산 루틴만이 아닌 편리하고 다양한 사용자 인터페이스 그리고 화려한 구성 구성 더불어 빠른 처리 속도 나아가 유무선 네트워크 접속 기능이 탑재된 프로그램의 개발은 연구소내에서 진행되는 단순 과정의 결과를 얻기 위한 개발 과정돠는 다르다. 시간도 비용도 그리고 인력에 소비도 비교할 수 없다.

결국 한 측면은 문제 해결을 위한 최적화된 방법론에 집중하고 그 구현의 방식으로서의 도구, 프로그래밍 언어를 통한 프로그램 작성이지만 다른 한 측면은 순전히 수익 창출을 위한 요소를 갖춘 제품으로서의 프로그램 작성, 개발이기 때문에 둘 사이의 간극 좀처럼 좁혀지기 쉽지 않다.

문제는 고등교육 기관에서의 프로그램 개발 교육은 전자의 교수자가 후자의 학습자를 이끄는 방식으로 진행된다는 것이다. 이러한 방식는 지난 수십년과 컴퓨터에 직간접적으로 관계된 공학과 기술 분야에서 변함없이 지속되고 있다. 그야말로 21 세기 프로그램 개발을 위한 20 세기 방식의 프로그래밍을 학습하고 있다. 물론 학술적 연구나 기술 개발을 위한 공학적 문제 해결에 FORTRAN이나 PASCAL 그리고 C와 같은 언어를 활용하는 것이 효과적인 것도 분명하지만 이런 필요성은 느낄만한 대학원 진학생은 극히 일부분일 뿐이다.

이는 교수자의 문제이기도 하지만 어쩔 수 없는 한계이기도 하다. 이미 수십년에 걸쳐 익숙한 프로그래밍 언어와 개발 방식을-물론 그나마 가능한 경우가 일부일 뿐이지만-새로운 특히나 학문적이지도 않은 목적에서의 프로그램 개발을 위한 인터넷 시대의 프로그램 언어와 개발 도구를 학습에 이용한다는 것은 거의 불가능하다. 아직도 프로그램 개발을 위한 통합개발환경(IDE)을 이해하지 못해 텍스트 편집기를 이용하여 프로그램을 작성하는 이는 주변이 적지 않으며, 이들은 일반적인 Windows 환경의 프로그램 개발을 이해하지 못한다. 그나마 문제 해결을 위해 스스로 프로그램을 개발할 필요없이 특정 분야의 상용 코드, 프로그램을 이용하여 이 문제를 극복할 수 있다는 점이 다행이라고 해야 할 실정이다. 사실 상용 코드, 상용 프로그램 역시 기능이 추가되고 인터페이스가 개선되면서 십 수년이 지나면 이전 사용자가 그 간극을 이해하고 받아 들이기는 불가능한 것이 현실이다.

심각한 문제는 많은 공학 분야의 프로그래밍 과정에서는 새로운 시대의 프로그램 언어와 프로그래밍 방식을 쓸모 없거나 또는 쉽게 배울 수 있는 대상으로 전락하여 학습의 대상이 아닌 것으로 폄하하기도 한다. 물론 교수자가 배우기 싫고 가르치기 힘들거나 불가능하기 때문이다. 물론 이러한 문제가 프로그램 개발에만 있는 것은 아니다. 대개 일반적인 공학 전 분야에 걸쳐 컴퓨터 시스템을 운용하는 모든 경우에 해당된다고 할 수 있다.

나는 일방적으로 이런한 문제의 해결을 위한 교수자가 우선적으로 새로운 시대의 흐름을 학습하고 이를 후배 학습자에게 전달해야 한다고 주장할 수 없다는 사실을 알고 있다. 하지만 이 방법이 아니라면 그 누구도 이 문제를 해결할 수 없다는 것 역시 모순적인 사실이다. 이미 코딩 교육은 초등학교 수준에서부터 시작되고 있으며 컴퓨터 관련한 학습 역시 정규 과정에 포함된 지 오래다. 얼마의 시간이 지난 후 정말 한 세기의 차이 만큼이나 서로 다른 시각을 가지 교수자와 학습자가 마주해게 될 것이다.

많은 대학생들에게 수업 시간에 완성한 과제를 이-메일로 제출하라고 하면 놀랍게도 상당수의 학생들이 어찌할 바를 몰랐다. 그들 대부분은 이-메일을 사용해 보지도 그리고 사용할 필요도 없었다. 고등학교에서 과제를 이-메일로 제출하는 경우가 거의 없을 것이라는 것은 쉽게 생각할 수 있으며 또한 학생들의 문서나 파일의 교류는 이미 스마트 기기의 메신저를 통하여 이뤄진 지 오래이기 때문에 이-메일은 이들에게 낯선 또한 구 시대의 컴퓨터 환경일 뿐이었다. 마치 플로피 디스크 드라이브 만으로 컴퓨터 간의 파일 이동을 경험 사용자가 어느날 인터넷을 통한 파일 공유나 이-메일을 통한 파일 전송에 느끼는 희열의 완전한 반대편의 느낌이라고 할 수도 있다.

다시 말하지만 이러한 모순적 상황을 극복하기 위해서는 앞선 선구자라고 스스로 생각하는 이들의 인식 변화가 우선 되어야 할 수 밖에 없다. 지금 이 마지막 전환의 시기가 지나가면 우려하는 간극은 실제 모순적 상황으로 드러날 지 모른다.

Woz U 사태에 즈음하여

엊그제부터 존경해 마지않는 워즈니악의 이름이 그 명성에 걸맞지 않게 거론되고 있다. 그가 미래 프로그래밍, 코팅 교육을 위해 추진한 Woz U의 교육 내용 부실에 대한 일부 학생들의 불만이 CBS에 의해 보도 되었다. Woz U의 시작때부터 관심을 가지고 봐왔던 입장에서 안타깝기도하고 한편으로는 현재 온라인 교육, 특히 첨부 분야에서의 교육 서비스가 가진 한계와 문제가 드러났다고 생각한다. 워즈니악이야 사실 자신의 이름을 브랜드로 한 교육 사업이니 부실 논란에 책임이 없다고 할 수는 없지만, 사실 그 누가 추진했더라도 온라인 교육 내용의 한계와 그 한계를 제대로 인식하지 못하는 학생 그리고 온라인 교육의 한계를 극복하기 위한 고품질 컨텐츠를 유지해야 기업의 입장에서는 현재와 같은 논란을 벗어날 수 없다고 본다. 특히나 미국처럼 고급 교육의 학습 비용이 비싼 곳에서는 서비스의 품질은 체감하는 학생들의 기대에 따라 천차만별일 수 있다. 평생 행복하고 재미있는 삶을 추구한 그가 이런 논란도 잘 수습하여 미래를 위한 온라인 교육의 가치를 다시 자리 잡을 수 있도록 기대한다.

온라인 교육뿐만 아니라 미래의 기술 혹은 첨단 선구의 기술이라는 분야는 교육 과정을 수립이나 교수 수행의 과정이 매우 어럽다. 때문에 대학 수준의 고등 교육에 만족하지 못하는 이가 온라인 교육에서 그 부족함을 채울 기대를 한다는 것은 위험하다. 이번 사례의 코딩, 프로그램의 경우는 그 대표라고 할 수 있다. 그리고 기계 설계나 기구 설계를 위한 교육 역시 유사하다. 단순하게 그리고 긍정적인 입장에서 보자면 일반적으로 교수들은 학생들에게 이론 또는 기술에 관한 사안을 전달하고자 하는 의도가 큰 반면, 학생들은 일반적으로 목표한 대상의 기능적 학습을 통하여 만족감을 얻고자 한다. 그러한 현실적으로 4년제 대학에서 특정 어플리케이션의 기능적 학습이 수업의 중심이 된다는 것은 매우 위험하며 유감한 상황이라 본다.

무엇보다도 21세기 이후 대부분의 대학 교육은 학생들이 처한 현실적 학습 기대를 충족시키기 어려운 상황으로 변했다. 20세기까지 대학은 기업이나 사회의 발전 수준에 비해 한 발 앞선 영역이었다. 모든 기술적 혜택을 먼저 접하고 누릴 수 있었다. 특히 컴퓨터와 인터넷으로 대표되는 ICT 기술이 그랬다. 하지만 현재는 이러한 기술 변화에 대부분의 대학의 가장 뒤쳐진 처지에 있다. 학생들은 집이나 회사에서 보다 열악한 환경에서 학습을 한다. 농담 삼아 이를 21 세기 학생들에게 20 세기 시스템으로 19 세기 교육을 한다는 자조한다.

또한 대부분의 교수들은 이러한 첨단 분야에 대한 학생들의 시급하고 절박한 학습 요구를 감당하기 힘들다. 앞서 언급했듯이 이미 학교 밖 세상은 자신들이 학습하던 시절의 내용보다 더 깊이 그리고 학습의 시간보다 더 빨리 새로운 정보가 생성되고 전달되기 때문에 이를 수행하기는 거의 불가능하다. 이론적인 문제도 그렇고 기술적인 문제도 마찬가지이며 더욱이 기능적인 문제는 매우 심각하다. 플로피 디스크 드라이브를 사용하며 FORTRAN으로 수치 해석 문제를 해결한 경험으로 스마트 기기를 항상 손에 쥐는 삶에서 시작한 이들을 학습하기란 불가능하다. 그렇다고 교수나 학교가 스스로 학생들의 상황을 파악하여 변화하기를 기대할 수는 없다. 때문에 결국 학생들은 자신들이 접하지 못한 그리고 접할 기회가 없는 상황을 학습하게 된다. 다시 말해 버전 10.0을 경험한 이가 버전 20.0으로 버전 30.0을 가진 이를 교육해야 하는 상황이다.

이 포스팅에서 대학이나 교수 혹은 고등 교육 체계의 학습을 비판하고자 하는 것은 아니다. 비판의 대상이 될 수 있는 학교나 교수의 입장에서는 세상이 너무 빨리 변화되고 있기 때문에 이에 대응할 시간도 능력도 그리고 의지도 갖출 수 없었다. 문제라면 문제이지만 역량의 범위를 이미 넘어 버려 더 이상 손을 쓰기 힘든 상황이다. 대학을 졸업한 학생들은 기업에서 이전까지 접하지 못한 새로운 기술과 기구를 운용하는 된다. 이전 세기의 상황이 지금은 전혀 반대의 일로 벌어지게 된 것이다.

지금도 많은 대학에서는 온라인 교습을 위한 강좌를 만들고자 한다며 국비를 받기 위해 애를 쓴다. 하지만 대학에서 온라인 교육 특히 공학이나 기술 분야에서는 강좌는 의미가 없다. 깊이도 없으며 신선하지도 않고 흥미를 유발하지도 못한다. 단순히 평소의 강의를 녹화하는 것으로 온라인 교육이 만들어지는 것으로 생각한다. 교수들의 눈에 학생들은 여전히 무지하고 선도의 대상으로 보일 뿐이다. 하지만 현실은 반대이다. 더 이상 21세기 즈음 삶을 시작한 이들을 이끌 동력은 상실된 지 오래다.

결국 지금 현실에서 온라인 학습은 목표가 명확한 경우, 예로 대학 입학 시험이나 자격증 시험과 같이 학습의 내용이 변화가 없거나 변화를 양자가 모두 인식하는 분야에서만 효과가 있다. 반면 목표가 명확하지 않거나 새로운 목표가 계속 생겨나는 분야에서의 온라인 학습을 지금까지의 온라인 교육 분야에서 활동했던 이들이 대응하기란 쉽지 않다. 새로운 목표와 새로운 내용 그리고 새로운 방식을 부담해야 할 이들은 없다.

많은 온라인 학습의 대상자들은 비용 부담의 크고 작음을 떠나 스스로 만족할 수 있는 체감적 목표 달성에 우선 만족감을 느끼기를 위하고 빠른 가시적 성과로서 복잡한 기능적 구현의 습득을 기대한다. 이런 경우 프로그래밍 언어의 문법적 특징이나 자료 구조의 구성 등은 불필요하거나 지루한 학습 내용으로 다가올 수 밖에 없다. 작더라도 무언가 자신의 컴퓨터에서 스마트폰에서 구동되는 현실적인 프로그램의 코딩과 실행을 기대한다. 때문에 프로그래밍에 관련된 기술적 레퍼런스 역시 때 지난 노트 필기처럼 여기기도 한다.

이러한 학습들의 욕구를 충족시키는 가장 일반적 학습 방법의 성공적 사례는 무수한 예제의 수행이다. 설계 수업에서 도면을 계속적으로 반복하여 그리게 함으로써 사용하는 CAD 시스템의 명령어에 익숙해지도록 하고 이후 예제에 기계적으로 대응될 수 있도록 기능화 시키는 것이다. 가르치는 입장에서는 수월하고 배우는 입장에서는 학습량을 체감할 수 있다. 그러나 현실적인 설계 능력을 전혀 배양할 수 없다. 마치 교통 법규에 대한 학습없이 자동차 구동 능력만 학습하여 운전면허 시험을 준비시키는 것으로 유사하다. 교통 법규의 세부적 학습의 응시자의 개별 부담으로 남겨진다. 그리고 누군가는 합격하고 다른 누군가가 탈락한다. 탈락한 이는 기존의 학습 과정을 답습하고 이후의 상황이 반복된다.

프로그램 작성, 코딩에서도 마찬가지다. 예제 코드로 학습하고 그 예제 코드를 입력하여 컴파일하여 성공적으로 구동되는 과정에 학생들은 스스로에게 만족감을 느끼며 좋은 교육 과정으로 인식한다. 하지만 이들 대부분은 실제 프로그래밍 과정에서 필요한 모든 것은 새로 학습하게 된다. 이들은 자신을 현실적 적응 능력이 부족한 이로 스스로 판단하고 새로운 학습 과정을 부담하게 되면서도 이전 교육 과정에서의 문제는 전혀 인식하지 못한다. 그 결과 교육 과정의 담당자 역시 새로운 교육 과정을 준비할 필요성을 느끼지 못한다. 악순환은 예전처럼 지금도 또한 앞으로도 지속될 것이다.

난 Woz U의 학습 과정에서 실망한 이들의 마음을 충분히 이해한다. 더욱이 싸지 않은 비용이 지불한 입장에서는 더욱 그렇다. 다만 미국 교육 산업에서 요구되는 비용을 고려할 때 Woz U의 비용은 싸지 않은 것은 분명하지만 결코 비싼 것도 아니다. 물론 넘쳐 나는 무려 온라인 학습 내용에 비춰 본다는 교육 품질이 비용에 적합하지 않다면 더욱 불만이 있을 만하다. 때문에 그 교육 수강생을 비판할 생각은 조금도 없다. 다만 학습의 목표로서 빠른 프로그래밍 기술의 습득으로 통한 취업 및 수익 창출이라는 목적에 비춰볼 때, 33주의 교육 기간 동안 스스로 만족함을 확인하고자 했다면 아마 쉽지 않았을 것이라고 생각한다. 다시 말해 책으로 혹은 다른 정규 교육 과정이 아닌 온라인 학습 과정을 통하여 단기간 프로그래밍 기술을 확보하고자 하는 욕심에 비해 교육 내용이 그 욕구에 부응할 수 없었다고 한다면, 다른 온라인 교육 과정에서도 비슷한 결과를 얻게 될 것이라 본다. 기존 방식이 아닌 새로운 방식으로 상대적으로 높은 기술 역량을 습득하는 것은 거의 불가능하다. 그 목표를 교육 과정의 특징을 소개했다면 교수 당사자도 분명 문제가 있으며 그 과정을 선뜻 선택한 학습 당사자 역시 욕심이 지나치다고 본다.

컴퓨터가 개발되어 프로그램이 컴퓨터 산업을 주도하게 된 지 30년 이상이 지났지만(난 그 시작을 1979년 VisiCalc의 등장으로 본다), 여전히 프로그래밍은 쉽지 않고 또한 높은 수준의 프로그램을 개발하는 일은 더욱 어려우면 특히나 개발된 프로그램 가운데 성공하는 경우도 손에 꼽을 정도라는 점이 코딩 교육의 학습 목표와 기대를 둘러싼 불만과 아쉬움을 증거한다고 본다.