1. 새마을호 객차
옛날에(1980~2010년대) 우리나라에 새마을호 열차가 다니던 시절에..
새마을호는 기관차 견인형과 액압변속 디젤동차형 둘로 나뉘었던 걸로 유명했다.
동차형 새마을호는 동력분산이 아니라 동력집중식이었다. 즉, 맨 앞, 맨 뒤 양쪽의 동력차만 빼면 그 사이의 객차들은 엔진 같은 게 전혀 들어있지 않았다.
 |  |
그러므로 기관차 견인형 새마을호의 객차와 동차형 새마을호의 객차는 크기와 좌석이 동일하고 인테리어 동일하고 외형적으로 다를 것이 전혀 없었으나..
모종의 이유로 인해 전원 점퍼 같은 세부 규격들이 서로 일치하지 않고 호환되지 않았다. 그래서 같은 새마을호 객차이지만 기관차 견인형과 동차형을 서로 섞어서 편성할 수 없었다..!
물론 새마을호 전용 동력차로부터 전력을 받는 거랑, 그런 거 없이 통상적인 기관차나 발전차로부터 전력을 받는 게 내부적인 구현 형태는 많이 다르긴 했을 것이다. 그리고 동차 편성은 그 특성상 유동적인 객차수 조절을 별로 염두에 두지도 않는 게 보통이다.
하지만.. 입출력 인터페이스가 달라야 할 필요가 없는 물건이 규격이 서로 일치하지 않은 것은 좀 아쉬운 점이다.
이제 우리나라에 동차형 새마을호와 비스무리한 외형을 유지하고 있는 열차는 경복호밖에 남지 않았다.
2. 아폴로 13호 우주선
1970년, 미국의 아폴로 13호 미션 때는 사령선에서 폭발 사고가 났다. 이 때문에 수단과 방법을 가리지 말고.. 달 착륙선에 있던 전기와 산소까지 어떻게든 끌어다가 사령선의 승무원들을 생존시키고, 이들을 지구로 생환시켜야 할 지경이 되었다.
그런데 이 와중에 사령선의 이산화탄소 제거기와 달 착륙선의 이산화탄소 제거기는 서로 다른 제조사에서 만들었는지 단자 모양이 서로 일치하지 않았다. =_=;;;
지상에 있던 엔지니어들이 단자 모양을 어떻게든 맞추는 방법을 찾아내 알려주고 위기를 간신히 모면했다.
이렇게 똥줄 타는 경험을 한 뒤, 아폴로 14호부터는 두 기계는 단자 모양이 당연히 서로 호환되게끔 시정 조치가 취해졌다.
3. 일본군의 육· 해군 대립
2차 세계 대전 시절에 일본군에서는 육군이 잠수함을 만들고 해군이 탱크를 만들기도 했던 게 아주 유명하다. =_=;;;;; 서로 노하우 공유나 부품 호환 따윈 안중에도 없었다. 전부 따로국밥..
해병대 상륙함이라든가 폭격기 같은 건 육· 해군 경계가 모호할 수도 있다고 치지만, 탱크와 잠수함은 너무했다. -_-;;;
구 일본군의 병크가 워낙 유명하긴 하지만, 컴터 업계에서도 마이크로소프트는 1990년대 말까지만 해도 꽤 악독했다.;;; 구글, 애플과 경쟁하는 게 아니라 내부의 팀들끼리 경쟁하고 못 잡아먹어 안달이었다. 정보 공유 같은 것도 없고 같은 기능의 중복 개발이 난무했다.
현재 시스템에서 실행 내지 load돼 있는 프로세스· DLL을 조회하는 API를 Windows 9x 팀과 NT 팀이 어떤 정보 공유도 없이 제각기 따로 개발했질 않나, (dbghelp vs psapi)
Visual C++ 팀과 Windows 팀이 C 런타임 라이브러리를 오랫동안 서로 따로 만들고 놀았다.
Office 팀은 파일 대화상자를 자체적으로 따로 개발하고 심지어 한중일 IME도 따로 자체 개발했었다. (Windows XP 시절까지)
4. C++ 표준 라이브러리
하긴, C++이라는 언어도 말이다. 처음부터 정교하게 설계된 언어가 아니라 "C에다가 객체지향만 살짝 얹은 그 무언가"에서 출발했다가 차츰차츰 아주 점진적으로 변화하고 진화된(evolved) 언어이다.
얘는 처음 등장했을 때 자기만의 표준 라이브러리, 클래스 라이브러리라는 게 없었다. 언어 차원에서 기본 제공되는 모든 오브젝트들의 뿌리 기본 클래스라는 개념도 없다. 그저 void*만이 있을 뿐;;;
1990년대 초, C++ 3.0에서 템플릿이라는 게 추가되고 나서 이를 이용한 범용적인 알고리즘/컨테이너 구현체인 STL이라는 게 알음알음 등장하고, C++98이 돼서야 라이브러리의 표준화가 논의됐을 뿐이다. 다른 객체지향 언어들과 비교했을 때 표준 라이브러리가 너무 늦게 제정됐다.
그 와중에 C++ 컴파일러가 등장하고 컴퓨팅 환경이 DOS에서 Windows로 넘어가는 동안..
수많은 라이브러리 개발사들은 그새 자기만의 문자열 클래스, 자기만의 동적 배열, 자기만의 링크드 리스트 컨테이너 등등을 만들고 또 만들게 됐다. re-invent the wheel!! 뭐, 이거는 앞에서 언급했던 마소 부서들의 중복 구현과는 성격이 좀 다른 현상이지만 말이다.
5. 전기 플러그
전기· 전자는 표준 규격이라는 게 오만 데 다 필요한 분야임이 틀림없다. (1) 가정용 교류 전기의 전압(100, 220)은 대표적인 예이고, 교류의 경우 주파수도 말이다(50 또는 60hz). 난 직류는 뭔가 민물고기(강=도시철도?) 같고 교류는 바닷물고기(광역/일반/고속철도??) 같다는 생각을 오래 전부터 해 왔다.
(2) 전기 자체의 물리량뿐만 아니라 전원 플러그의 외형적인 모양도 어쩌다 보니 세계적으로 완전히 통합되지 못했다. 전부 합하면 10여 종이나 되는데, 그렇기 때문에 전세계 모든 전원 플러그에 대응 가능한 뚱뚱한 플러그가 공항 면세점이나 잡화점에서 팔리곤 한다.
물론 전기 플러그는 전압과 직접적인 관계가 있는 게 아니다. 우리나라에서 옛날 100V용으로 쓰였던 각진 type A형 플러그로 220V를 넣을 수도 있고, 반대로 오늘날 220V용으로 쓰이는 동그란 돼지코 type C 플러그로 100V를 넣을 수도 있다. 그냥 정하기 나름..
그런 맥락에서 만능 플러그 역시 변압은 해 주지 않는다. 필요하다면 그건 소비자가 알아서 변압기를 구비해서 해결해야 한다.
승압을 하면서 플러그의 모양까지 딴 걸로 바꾼 건 뭐랄까 마소에서 16비트에서 32비트로 갈아탈 때 실행 파일 포맷이라는 껍데기를 NE에서 PE로 바꿔 버린 것과 비슷한 변화 같다.
6. 충전 단자
전원 플러그 다음으로는 충전기도 생각해 보자.
불과 20여 년 전만 해도 국내 핸드폰/피처폰들의 충전기와 짹 모양이 전부 제각각이었다는 게 믿어지지 않는다. 폰을 통째로 받침대에다 찰칵 꽂아 놓고 충전했던 적도 있는데..
이제는 USB 포트가 전자기기 간의 연결뿐만 아니라 소형 전자기기들의 충전까지 책임지는 만능 단자로 등극했다. 오죽했으면 그 도도하던 아이폰까지 USB C를 도입할 지경이니까.
하지만 컴퓨터와의 접점까지는 없는 일부 저렴한 손전등이나 전동 면도기 중에는 여전히 듣보잡 고유 단자와 전용 충전기만을 고집하는 물건이 있다. 이런 것들은 차차 정리가 되지 않을까 싶다.
아울러.. 개인적인 생각으로는 충전 상태를 나타내는 시각 피드백도 좀 통일돼야 하지 않을까 싶다.
- 충전 중엔 적색이다가 완료 후엔 녹색.
- 충전 중엔 녹색이다가 완료 후엔 녹색 점멸;;
- 충전 중엔 황색이다가 완료 후엔 불빛 꺼짐
- 충전 중엔 황색 깜빡이다가 완료 후엔 황색
옛날에 폰과 디카의 배터리를 따로 꺼내서 충전하던 시절엔.. 본인은 위의 케이스들을 전부 다 봐 왔다.;;;
7. 좌표계
국가별로 도로에 좌측/우측통행 기준이 다르다면, 컴퓨터에는 CPU 제조사에 따라서 비트 배열 순서(엔디언)가 차이가 있다. 그런데 컴퓨터에는 그것 말고 기하학적인 좌표의 취급 방향도 살짝 파편화된 구석이 있다.
2차원에서는 Y축의 양수가 아래로 가느냐, 위로 가느냐가 다르다. 아래는 글을 써 내려가는 방향과 일치하는 반면, 위는 수학 좌표계와 일치한다.
이건 뭔가 번호 다이얼(아래로)과 계산기의 숫자(위로) 배열 방향 차이와도 비슷해 보이는데..?
BMP 그래픽 파일은 위쪽(수학) 좌표계를 염두에 둔 것으로 잘 알려져 있다. Windows에서는 원초적인 픽셀 기반의 MM_TEXT 좌표계만이 아래쪽이고, 나머지 현실 단위계와 대응하는 좌표계들은 위쪽이다. macOS 환경은 MM_TEXT라는 개념이 아예 존재하지 않고 몽땅 위쪽인 걸로 난 알고 있다.
2차원을 넘어 3차원으로 가면.. XY 평면 위로 Z축의 양수가 어느 쪽으로 뻗느냐에 따라 왼손 또는 오른손 좌표계로 나뉜다. 오래된 표준 그래픽 라이브러리인 OpenGL은 오른손 좌표계이지만, 후발주자였던 DirectX는 왼손 좌표계를 채택한 것으로 잘 알려져 있다.
이상이다.
자고로 어떤 기계나 컴퓨터 프로그램은 겉으로는 똑같이 동작하더라도 내부 디테일은 어떤 규격을 선택하느냐에 따라 천차만별이 되는 경우가 많다. 그렇기 때문에 그 제품의 유지보수라든가, 타사 제품과의 연계를 위해서는 산업 표준을 만들어서 그걸 따라 만들게 하는 게 좋다.
컴퓨터 세계를 더 살펴보자면, 유니코드라는 게 없던 1990년대 초까지는 한글 코드조차 조합형이니 완성형이니 난립해서 문제였었다. 21세기 초까지는 동영상 코덱도 난립(1990~2000년대)했었다.
철도는 궤간이 대표적인 문제이고.. 아날로그 TV 시절에는 디지털 동영상 코덱이 아니라 아날로그 영상 신호 내부 구조가 PAL이니 NTSC니 하는 표준 규격이 있었다. 이런 걸 다 다루기에는 시간과 지면이 부족하니 이 글에서는 더 자세한 설명을 생략하겠다.;;
Posted by 사무엘
