의욕은 좋은데
뭔가 포인트가 어긋났다.
Why SW Stack
상황 오판
개방, 호환 그리고 Tmax의 기술적 한계
OS는 무슨 이유로 만드는가
뭔가 포인트가 어긋났다.
Why SW Stack
소위 'Tmax Software stack'을 주창하며 내세운 논리는
- 독점의 OS - MS
- 기술의 DB - Oracle
벤더 종속성으로, 횡포에 휘둘릴 수 밖에 없다.
이에따라 Tmax가 개방형 SW stack을
이에따라 Tmax가 개방형 SW stack을
- OS
- DB
- Middleware
- Application
로 구성하여 Total solution provider가 되겠다는 것이다.
상황 오판
하지만, 이런 stack을 구성함에 있어,
Tmax 제품군의 core에 이기종의 제품을 붙여도 작동하도록
개방형 SW Stack을 지향하겠다고 주장하는 것은
정황적으로나, 경험적으로나 납득이 어렵다.
M/F가 아닌 이상, 어떠한 솔루션을 채택할 것인가 하는 점은
pSeries-AIX와 같은 결합을 제외하고는
무슨 DB를 올리든, 무슨 미들웨어를 올리든 현재로서도
'특정 벤더사를 위한 조직으로 전락' 까지의 상황은 아니다.
market share를 뺏고 싶다고 솔직하게 말하는 게 낫겠다.
문제는 고객이 토탈 패키지가 갖춰져있다는 이유로 선호해주지는 않는다는 점.
Tmax 제품군의 core에 이기종의 제품을 붙여도 작동하도록
개방형 SW Stack을 지향하겠다고 주장하는 것은
정황적으로나, 경험적으로나 납득이 어렵다.
M/F가 아닌 이상, 어떠한 솔루션을 채택할 것인가 하는 점은
pSeries-AIX와 같은 결합을 제외하고는
무슨 DB를 올리든, 무슨 미들웨어를 올리든 현재로서도
'특정 벤더사를 위한 조직으로 전락' 까지의 상황은 아니다.
market share를 뺏고 싶다고 솔직하게 말하는 게 낫겠다.
문제는 고객이 토탈 패키지가 갖춰져있다는 이유로 선호해주지는 않는다는 점.
개방, 호환 그리고 Tmax의 기술적 한계
상황 파악에 대한 의문점을 차치하고라도,
지금의 consolidation 프로젝트의 복잡성을 크게 떨어뜨릴 수 있을만큼
Tmax에서 generic한 layer 내지는 stack을 만들 수 있는가 역시 회의적이다.
왜냐하면 Tmax는 당장 OpenFrame에서의 XA 통신 규약조차 정확히 구현하지 못하여
in-doubt transaction이 발생하는 상황에 대해
transaction coordination은 middleware의 role임에도 불구하고
"오라클에서는 잘 되는데 DB2에서는 안되니, IBM에 가서 물어봐라"
라고 답변하는 곳이었기 때문이다.
L사이트의 성공 사례라고 써있는 Proframe은
프로젝트와 동시에 프레임워크를 만들고 있으며(!)
원래부터 들어와서 만드는 것, 사이트마다 버전이 다른 것으로 유명하다.
SE들이 코딩을 하다 오류가 발생하면
대체 자신의 오류인지, 로직의 오류인지,
프레임워크의 오류인지조차 알 수 없다고 푸념한다.
어느 정도 이름을 알린 Zeus의 경우에는
모 미들웨어 제품과 에러코드까지 호환된다고 하니
이것은 개방과 호환의 흐름인 것인지
지금까지 보여준 놀라운 개발 속도의 원천인지는 알 수 없다.
지금의 consolidation 프로젝트의 복잡성을 크게 떨어뜨릴 수 있을만큼
Tmax에서 generic한 layer 내지는 stack을 만들 수 있는가 역시 회의적이다.
왜냐하면 Tmax는 당장 OpenFrame에서의 XA 통신 규약조차 정확히 구현하지 못하여
in-doubt transaction이 발생하는 상황에 대해
transaction coordination은 middleware의 role임에도 불구하고
"오라클에서는 잘 되는데 DB2에서는 안되니, IBM에 가서 물어봐라"
라고 답변하는 곳이었기 때문이다.
L사이트의 성공 사례라고 써있는 Proframe은
프로젝트와 동시에 프레임워크를 만들고 있으며(!)
원래부터 들어와서 만드는 것, 사이트마다 버전이 다른 것으로 유명하다.
SE들이 코딩을 하다 오류가 발생하면
대체 자신의 오류인지, 로직의 오류인지,
프레임워크의 오류인지조차 알 수 없다고 푸념한다.
어느 정도 이름을 알린 Zeus의 경우에는
모 미들웨어 제품과 에러코드까지 호환된다고 하니
이것은 개방과 호환의 흐름인 것인지
지금까지 보여준 놀라운 개발 속도의 원천인지는 알 수 없다.
OS는 무슨 이유로 만드는가
헤아릴 수 없는 40%의 시장이 application에 있다면서
application에 선택과 집중하는 대신에 OS의 구색을 갖추려는 이유는 무엇인가.
TmaxOS는 개인사용자들이야 흥미로 한 번 설치했다 지울 수는 있겠지만
엔터프라이즈 마켓에서 인프라를 바꾸는 것이 말처럼 쉬운 일도 아니고
W32 API, Posix API와 100% 호환되도록 만드는데 성공하여
주장하는 것처럼 SW stack, 표준 인터페이스의 밑단을 담당할 수 있게 된다고 해도
타사 제품에서 Tmax로 이탈시킬 수 있을만큼, 그 반대 역시 쉽다면
구매자에게 어필할 수 있는 장점이라 믿고 있는가.
아니면 진흥 정책을 등에 업고, 찍어내는 연구소를 믿고, 어쨌거나 밀어붙이는 로비력으로
전 제품군이 다 있으면 경쟁력이 있다는 미리 만든 명제를 억지로 끼워맞출 것인가.
application에 선택과 집중하는 대신에 OS의 구색을 갖추려는 이유는 무엇인가.
TmaxOS는 개인사용자들이야 흥미로 한 번 설치했다 지울 수는 있겠지만
엔터프라이즈 마켓에서 인프라를 바꾸는 것이 말처럼 쉬운 일도 아니고
W32 API, Posix API와 100% 호환되도록 만드는데 성공하여
주장하는 것처럼 SW stack, 표준 인터페이스의 밑단을 담당할 수 있게 된다고 해도
타사 제품에서 Tmax로 이탈시킬 수 있을만큼, 그 반대 역시 쉽다면
구매자에게 어필할 수 있는 장점이라 믿고 있는가.
아니면 진흥 정책을 등에 업고, 찍어내는 연구소를 믿고, 어쨌거나 밀어붙이는 로비력으로
전 제품군이 다 있으면 경쟁력이 있다는 미리 만든 명제를 억지로 끼워맞출 것인가.
invalid-file
