C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

자유게시판
세상 살아가는 이야기들을 나누는 사랑방입니다.
[10092] MS SQL서버 2000의 치명적 버그를 의심하다...
박지훈.임프 [cbuilder] 5549 읽음    2004-11-17 03:23
최근 며칠 사이에 MS SQL서버 2000의 버그로 강하게 의심되는 사례를 두차례나 겪어 글을 써봅니다.
마침 방금 올린 IT뉴스 기사중에도 LG텔레콤이 오라클에서 SQL서버로 마이그레이션을 시도한다는 기사도 있고 해서요.

제가 다니는 회사에서 사용하는 DBMS 제품이 나오는 관계로 회사가 어디인지 공개적으로 밝히진 않겠습니다.
IT쪽 회사는 아니지만 해당 분야에서는 아주 잘 알려진 중견 기업이구요. 최근 오프모임에서 만난 분들은 물론 아시죠.

저희 회사에서는 전사적으로 MS SQL서버를 사용하고 있습니다.
파트별로 디비를 별개로 운영하고 있기 때문에 디비서버가 꽤 여러 대 되는데, 다 SQL서버를 돌리고 있죠.
그중에 제가 직접 관여한 시스템이 가장 많은 트래픽을 기록하는데요.

이 디비 서버는 제온 4CPU짜리 서버 한대에서 돌리는데, 바쁠 때는 1~2초 간격으로 두개 이상의 CPU가 100%를 칩니다.
데이터는 백만건 단위로 그렇게 대규모는 아니지만, 트래픽이 대단히 많고 시스템의 특성상 시간이 지날 수록 제곱배로
부하가 커질 수밖에 없는 구조인데요. 이미 4CPU로도 한계에 가까워지고 있어서 곧 디비 클러스터링을 고려해야 할
상황입니다.

사실 저는 디비 전문가는 전혀 아니지만, 그동안 개발을 하면서 당연히 디비쪽도 이래저래 꽤 다루기도 했고요.
또 어떻게 하다보니 이 회사에 입사하고 처음 한 일이 SQL서버 튜닝이었는데, 입사후 거의 한달 가까이 디비 튜닝, 특히
SQL서버 튜닝에 대한 관련 자료들을 뒤적거려서 성공적으로 튜닝을 마쳤습니다.
그러니까 디비쪽으로 DBA 수준의 아주 전문은 아니어도 알만큼은 알고 다뤄볼 만큼은 다뤄본 정도라고 할 수 있지요.

SQL서버의 버그로 의심되는 문제가 발생한 것은, 고객 정보를 DB에 등록하는 루틴에서였습니다.
고객 정보를 등록할 때 동시에 입력되는 정보가 꽤 많기 때문에 여러 테이블.. 대략 10개 이상의 테이블에 한방에
인서트를 합니다. 당연히 트랜잭션을 먼저 걸고 인서트 쿼리들을 날린 후에 커밋을 하지요. 그리고 트랜잭션의 특성상
어떤 에러라도 발생하면 전체 트랜잭션내의 모든 쿼리가 취소되지요.

며칠전.. 그러니까 지난주 금요일부터 갑자기 고객 정보 입력을 하는 ASP 페이지에서 에러가 나면서 입력이 안되는
문제가 발생했습니다. 입사한지 얼마 안되는 제가 알기로도 1년 이상 아무 문제없이 써오던 부분이라 꽤 당황스러웠죠.
하루에도 수십명씩의 고객을 등록해야 하는데, 입력 작업이 장난아니게 노가다이기 때문에 며칠 정도만 입력이 미뤄져도
감당 못하게 입력할 데이터가 쌓이고, 여러가지로 문제가 복잡해집니다.

보통 오랫동안 잘 동작하던 부분에서 문제가 생기면 어디서부터 뒤져봐야 할지 난감해지잖습니까.
월요일에야 문제를 찾았는데요. 문제의 직접적인 원인은 트랜잭션의 롤백이 제대로 이루어지지 않은 거였습니다.

에러가 발생하기 시작한 시점의 직전에 고객 데이터를 입력하다가 에러로 롤백된 데이터가 있었나보더군요.
당연히 고객 정보 전체의 마스터 테이블에서 고객 번호를 딴 후에 그 고객번호로 디테일 테이블에 차례로 데이터를 넣는
흐름으로 처리되게 되어있는데, 마스터를 포함한 다른 모든 테이블의 레코드들은 모두 롤백되어 사라졌는데, 세번째
디테일 테이블에 추가되었던 레코드가 지워지지 않고 남아있더군요.

게다가 하필이면 찌꺼기 레코드가 남은 이 디테일 테이블이 마스터 테이블과 1:1 관계에 있는 테이블이었습니다.
다시 말해서 마스터 테이블의 PK는 고객번호인데, 이 디테일 테이블의 PK도 고객번호로 되어 있다는 얘깁니다.
테이블의 PK인 고객번호 필드에 연결되어 있습니다.

고객번호를 딴다는 표현에서 짐작하셨겠지만 이 고객번호가 일련번호로 되어있습니다.
그러니까 새로 고객을 등록할 때마다 1씩 증가하는 새 번호를 만드는 건데요.
먼저 마스터테이블에서 번호를 따고 마스터 테이블에 1:1로 연결된 디테일 테이블에 새 레코드를 인서트하려고 시도할 때,
이미 해당 고객번호의 레코드가 있기 때문에 트랜잭션이 커밋되지 못하고 매번 롤백되어버린 거였습니다.
마스터테이블에는 해당 고객 번호가 없고 디테일에는 남아있는 상황이죠.

아시다시피 MySQL과 같이 기본적으로 트랜잭션을 지원하지 않는 디비를 제외하면, 데이터베이스에 있어 트랜잭션의
특성은 기본중의 기본입니다. ACID라고 해서 4원칙도 있잖습니까. 그런데 MS가 그렇게 안정적이라고 장담에 장담을 하는
SQL 서버에서 롤백된 데이터중 일부가 지워지지 않고 남아버리는 어처구니 없는 상황이 벌어져서 며칠동안 대혼란이
일어난 겁니다.

이쯤 되면, SQL 서버를 상당기간 잘 써오신 분들은 제 말에 의심부터 드시겠지요.
정상적인 입력작업이 아닌 경로로 추가된 레코드가 아닌가? 라든지 말이죠.

그런데 이 DB 서버는 웹서버 머신과 저희팀의 네명의 PC 외에는 접근조차 할 수 없도록 IP가 막혀 있고요.
또 저도 설마, 혹시나, 하면서 저희 시스템의 전체 소스를 다 뒤져서 이 테이블에 인서트를 하는 다른 루틴이 있나 다시
찾아보기도 했습니다만 전혀 없었습니다. 게다가 남아있는 찌꺼기 레코드의 데이터와 입력되지 못하고 대기중이던
고객정보 문서들을 대조해본 결과 대기중이던 문서들중 하나에 그 레코드 내용들이 있더군요.

결과적으로 다르게 어떻게도 변명할 수 없는, SQL서버 자체의 버그가 아니면 있을 수가 없는 문제입니다.

게다가, 불과 이틀 후에 같은 문제가 다시 재발했습니다. 바로 며칠전에 겪은 일도 있고 해서 입력 에러가 생기기 시작하자
마자 바로 찌꺼기 레코드가 있나 찾아봤는데, 역시나 있더군요. 그런데 황당하게도 며칠전에 문제를 일으켰던 것과 똑같은
디테일 테이블에 똑같은 형태로 레코드가 남아있더라구요.

같이 인서트되는 테이블이 디테일 테이블이 열몇개나 되는데 불과 며칠 사이에 유독 이 테이블에만 두차례나 문제가
생기는 것이 신기하고 황당해서, 다른 테이블과 다르게 설정된 특이한 점이 있나 해서 이래저래 뒤져봤는데요.
한가지 차이점이 있었습니다. 실수로 FK가 안잡혀있더군요. 구조상 FK를 잡아줘야 하는데, 그걸 빼먹은 겁니다.
다른 테이블에는 다 잡혀있었고요.

FK가 안잡혀있는 것은 분명히 실수이긴 하지만, FK가 안잡혀있다고 해서 롤백이 제대로 되지 않아서는 안되죠?
이번 케이스의 경우 서로 연관된 테이블들을 함께 인서트하는 거지만, 디비를 다루다보면 연관성이 없는 레코드들도
하나의 트랜잭션 안에서 커밋/롤백하는 경우도 종종 생깁니다. 트랜잭션의 All or Nothing 원칙에은 FK가 잡혀있건
안잡혀있건 무관하게 무조건 지켜져야 하는 겁니다.

아마도, 어떤 복잡하게 꼬인 조건에만 발생하는 버그가 있어서 그 조건중의 하나로 FK가 안잡혀있다는 조건이 포함되는
것 같습니다. 앞에서도 말했듯이 다른 경로로 이 찌꺼기 레코드가 들어갔을 가능성은 전무한 상태이므로 SQL 서버의
버그가 아니라면 있을 수가 없는 일이지요.

다시 한번 확인할 기회를 갖기 위해..
그 디테일 테이블에 FK를 잡지 않고 그대로 뒀습니다. 불과 3일만에 두번이나 발생한 문제이므로 다시 발생할 가능성이
높겠죠. 세번째까지 확인한 후에 FK를 잡아놓고 그 이후에 더이상 발생하지 않는다면 SQL서버의 버그일 가능성이
거의 틀림없겠죠.

하지만 FK를 잡기 전에 다시 발생하지 않는다거나 FK를 잡은 후에도 발생한다고 해서 SQL서버의 버그가 아니라고
할 수도 없습니다. 이런 종류의 버그는 발생하는 패턴을 잡아내기가 대단히 힘드니 예상한 방식으로 다시 나타나지
않을 가능성도 충분히 높죠. 그리고 이미 정황상 SQL서버의 버그가 틀림없어보이기도 하고요.

물론, 대부분의 다른 사이트에서는 잡음이 들리지 않는 걸로 봐서(들리지 않는다고 발생하지도 않는 것은 아니지만)
SQL서버를 채택한 기업들이 적어도 그럭저럭은 쓰고 있다는 말일텐데요. 그렇다고 안심할 것이 못됩니다.
저희 회사에서 발생한 이번 건의 경우 그나마 고객 정보 입력 단계에서 발생한 문제여서 그렇게 시분초를 다툴 정도의
큰 문제는 아니었지만, 이런 문제가 만약 1초 1초가 급한 업무에서 발생해버린다면?
그야말로 대란이 일어나는 거지요 뭐.

바로 이런 면 때문에 기업에서 미션 크리티컬한 업무에는 "충분히" 검증되지 않은 DBMS를 쓰지 못한다는 건데..
아직 SQL 서버는 충분히 검증되지 않은 상태인데 시스템 구축시에 SQL 서버를 채택한 것이 성급했다고 할 수 있죠.

MS에서 SQL서버는 사실상 7.0에서 완전히 새로 개발했다고 그렇게 자랑을 해대는데...
거꾸로 말하면 7.0이 출시된 98년인가 이후로 불과 6년 정도의 검증기회밖에 없었다는 얘기가 되죠.

어쨌든... 저희 회사에서는 현재 오라클로 마이그레이션할 것을 진지하게 고려하고 있습니다.
사실 오라클 마이그레이션 외에 다른 대안이 없죠.
김태선 [jsdkts]   2004-11-17 17:57 X
마이그레이션 외에 대안이 없다면 그렇게 해야 겠죠.
저는 박지훈님의 글을 보고 조금 놀랐습니다
저는 MS_SQL을 주로 사용해왔고, 특별히 MS-SQL의 버그라는 것을 별로 격지 못했습니다. 아마 경험이 부족해서이겠지요..;
그런데, MS SQL은 실무에서 대단히 많이 사용되고 있기에, 마이그레이션을 금방하기 보다는 그 버그같은 것을 피해가는 방법이 어떨까요? 마이그레이션 보다 오히려 적은 힘이 들수 있기 때문입니다.
과거로부터 프로그래밍을 할때 어떤 부분에서 이해할수도 없고 직접 해결할 방법도 없는 버그를 만나게 되면, 결국 우회방식을 택해서 해결하는 경우가 가끔 있었는데.. MS-SQL의 버그라면 대단히 심각한 문제 같습니다. 롤백은 DB의 안정 동작에 대한 마지막 신뢰같거든요...

아뭏던 잘 해결되기를 바랍니다. ^^;
제이 [jshin]   2004-11-18 10:38 X
저희 회사에서도 몇몇 MS SQL Server를 사용하는데 저번에 한 번 시스템 테이블이 날라간 적이 있었습니다. 윈도우를 리부트했는데 SQL 서버가 실행이 안되는 거였습니다. 다행히 일요일이라서 몇시간만에 시스템을 다시 구성해서 복구했지만 좀 불안한 건 사실입니다.
못된똥 [lancelot]   2004-11-18 19:42 X
SQL 서버는 기본적으로  트랜잭션의 속성(ACID) 중 원자성을 지원하지 않습니다.
SET XACT_ABORT ON 이라는 세션 옵션을 활성화 시켜야만 원자성을 지원합니다.
혹시 이 옵션을 사용한 상태인가요???? 님의 글을 보니 이옵션이 켜지지 않으신듯 한데요...
박지훈.임프 [cbuilder]   2004-11-18 22:09 X
아니!!! 정말 그렇군요!
트랜잭션에서 ACID는 기본 상식인데 그것도 지키지 않는다니...

게다가 제가 보고 있는 Professional SQL Server Programming에서는 트랜잭션 롤백시 (기본 상태에서도) 이전 상태로 돌아간다고 되어 있군요. 저자가 돌팔이였군... 두께만 딥따 두껍고...

그러면 별도로 설정을 해주지 않는 한 기본 상태에서는 트랜잭션이 별 쓸모가 없어지는 셈인데요. 롤백이 되지 않는 트랜잭션을 트랜잭션이라고 할 수 있을지...
마이크로소프트라는 회사, 사람을 정말 당황스럽게 하는군요.
이경석 [pmoffice]   2004-11-19 14:11 X
한가지 질문요? (수정)
XACT_ABORT 은 BEGIN TRAN 로 시작해서 ROLLBACK TRAN 없이 COMMIT TRAN 로 종료될때만 의미있는거 아닌가요?
BEGIN TRAN 로 시작해서 에러발생 체크한후 없으면 COMMIT TRAN 에러 있으면 ROLLBACK TRAN 를 사용하는데서는 의미가 없지 않나요?
이럴경우는 확실히 모두 롤백이 되지 않나요?
임프님 트랜잭션 걸어서 사용할때 ROLLBACK TRAN 구문을 사용 하시는지요?
그냥 궁금합니다....
박지훈.임프 [cbuilder]   2004-11-19 18:46 X
저는 소비자로서 제게 업계의 표준과 상식을 무시하고 자사의 철학을 강요하는 벤더가 당황스럽습니다. 새로 제품을 구입할 때마다 상식을 벗어나는 것이 없는지 조심해야 하는 것이 소비자의 의무입니까?

그리고 유치한 것은 김상욱님의 행동입니다.
얼마나 마이크로소트와 SQL 서버를 사랑하시길래 제게 한마디 하기 위해 가입까지 하셔서 제게 유치하다는 말 한마디를 던지십니까?
김태선 [jsdkts]   2004-11-19 20:01 X
두분 진정하세요. ^^;
변하지 않는 사실에 대해 열을 올리는 것은 아무런 소득이 없습니다.

박지훈님의 의견은 사실 MS에서 귀기울여 들어야 하는 내용입니다.
MS가 비난받아야 하는 것은 독선이닌까요.
하지만 MS SQL은 저도 애용하고 그간 만족할만한 퍼포먼스를 보여줬기 때문에 좋은 제품이라고 생각합니다.
미리 MS SQL의 특성을 더 살펴볼 필요는 있는데, 박지훈님은 너무 바쁜 분이라서 당연하다고 생각한 동작에 이상이 있으니 그기에 의문을 재기한 것 뿐이라 생각됩니다.

좋게 생각하면 좋아지고, 나쁘게 생각하면 나빠지는게 세상의 일입니다.
그럼^^;
박지훈.임프 [cbuilder]   2004-11-20 01:11 X
김상욱님이야 말로 특정 제품에 국한된 짧은 지식으로 남을 함부로 깔보지 마셔야 할 듯 합니다. 아래 리플에서도 달았다시피, 오라클만의 방식이 아니라 ACID는 트랜잭션에 대한 업계 표준입니다. 그걸 오라클만의 방식일 뿐이라고 말하신 것은 김대우님이 잘못 아신 겁니다. 그런데, 반론을 달아서 사실을 밝혔는데도 불구하고 그걸 제 실수라고 우기시는 것은 앞뒤 안가리는 아집이 아닙니까? 지금까지 표준을 지키지 못했다고 자인하는 업체는 봤어도 표준을 고의로 어겨놓고 그걸 자사의 철학이라고 우기는 곳은 마이크로소프트밖에 못봤습니다.

그리고, 정치가도 연예인도 아닌 저를 공인이라고 치켜세워주신데 대해서는 감사합니다만, 만약 그렇다면 저는 공인이므로 더욱 잘못된 것은 확실하고 따끔하게 지적해야 한다고 생각합니다. 제가 볼랜드의 제품들을 아주 좋아합니다만 잘못된 것은 볼랜드코리아뿐만 아니라 엉성한 영어로 작문을 해서라도 볼랜드 본사에도 메일을 보내서 정정을 요구합니다. 저는 볼랜드 매니아이기도 합니다만 볼랜드 제품의 소비자 단체를 대표하는 입장이기도 하기 때문입니다. 잘못된 것은 눈감고 좋은 면만 본다면 속칭 '~빠'일 뿐 매니아도 좋은 고객도 아니라고 생각하는데요.

그리고 제 문체에 불만이 있으신가요? 제가 설령 중학생이라고 해도 잘못된 것은 잘못되었다고 지적한 것이 연령에 따라 차등 대우를 받아야 하는지요? 진실을 호도하는 것은 제가 아니라 김상욱님이 아니신가요? 그런데 그걸 지적하는 제가 실제로 그렇건 아니건 문체가 유치하다는 비난을 듣는 것은 어불성설이라고 생각되지 않으신가요?

당연하겠지만 김상욱님은 SQL 서버에 대해 애정을 갖고 계신 것 같습니다. 그러면 평생 SQL 서버만 사용하면 그만이다, SQL 서버가 표준을 지키건 무시하건 상관없는 겁니까? 일단 SQL 서버가 RDB 업계를 평정하고 나면 다 SQL 서버 시장이니까 표준은 유명무실해질 거다, 그정도의 생각을 가지고 계신 겁니까? 진정한 애정은 그런 것이 아닙니다.

논쟁을 유치하게 만든 것은 제가 아닙니다. 이미 대부분의 사람들이 알고 있는 표준과 상식이 있는데 그걸 고의적으로 어긴 것은 마이크로소프트이고, 그걸 당연하다고 주장하는 것도 코난님과 김상욱님이지 제가 아닙니다. 제가 없는 표준을 있다고 우긴 것도 아니고, 그 표준이 유명무실한 것도 아니라 실제로 대부분의 엔지니어들이 알고 있는 상식입니다. 이 문제에 대해서는 전 진중할 이유가 없으니 더 하실 말씀이 있으시면 초급 전산개론 공부를 더 하시고 와서 더 말씀하세요.
박지훈.임프 [cbuilder]   2004-11-20 15:49 X
지금 놀리십니까. 공인이라고 추켜세우고는 바로 유치하다고 깔아뭉갠 분이 김상욱님 아니십니까. 그런데 실컷 약을 올려놓고 '화가 많이 나셨군요'라니요. 혹 저랑 잘 아시는 분인가요? 김상욱님은 아무데서나 가서도 그 사람이 자신보다 지식이 적은 거 같다, 싶으면 바로 유치하다는 말이 튀어나오는 체질이신가요. 말장난으로 시작해서 말장난으로 얼버무리겠다는 생각이신가요. 그리고 제가 튜닝해놓은 것을 보시기라도 하신 후에 제대로 했는지 의심스럽다는 말씀을 하세요. 아주 기분 나쁠 말은 골라가면서 하시는군요.

표준과 상식에 대해서는 한마디도 못하시는군요. 그러면 제 심기를 건드린 것이 아니라 저보고 기본을 공부하라느니 하신 말씀이 잘못하신 것 아닙니까? 제가 진실을 알고 있었고 님께서 잘못 아신건데 도리어 제게 기초 공부나 더 하라니요. 제가 화난 것은 김상욱님의 그런 태도 때문입니다. 님은 DBA인 듯 하니 특정 DB만으로 먹고 사는 입장이시겠지만, 개발자 커뮤니티의 절대 다수는 평생동안 거의 대부분의 DB들을 다루게 됩니다. 혹 4~5년쯤 후에 SQL 서버가 단종된다고 해도 전혀 상관없이 업을 이어갈 사람들이란 말입니다. 그런데도 SQL 서버에만 해당되는, 그것도 표준도 지키지 않는 설정을 가지고 제가 기초도 모르는 사람이라는 말을 들을 입장인가요?

좋습니다. 백번 양보해서 그게 기본이고 SQL 서버를 이용하면 당연히 알아야 하는 거라고 칩시다. 그런데 그게 기본이라면 왜 SQL 서버의 매뉴얼이나 헬프의 가장 앞장에 있지 않습니까? 혹시나 그런게 있나 의심을 가지고 찾아봐야 구석에서 겨우 몇줄 찾아낼 정도뿐이지 않습니까? 그게 기본입니까? 혹시 초급서는 물론 중급서 한권을 통째로 다 봐야 기본이라고 생각하시는 건가요?

김상욱님은 평생 SQL 서버만 사용할 수 있는 환경에서 일하시는지 몰라도 저는 상황과 요구에 따라 RDB 정도는 얼마든지 바꿔가면서 개발합니다. RDB가 특성을 타는 것은 당연하다고 생각하지만 기껏해야 수백, 수천만원짜리 제품이 기본을 지키지 않는 것을 도리어 개발자들을 우롱하는 것은 어불성설입니다. 이 업계를 어떻게 생각하시는지 모르겠지만, 마이크로소프트가 얼마만큼의 영향력을 가지고 있는지와 무관하게, SW 업계의 주역은 마이크로소프트가 아니라 개발자들이라는 것을 유념해주시기 바랍니다. 김상욱님은 평생 DBA를 하세요. 그리고 개발자 함부로 깔보지 마세요. 그런 태도를 고수하신다면 도리어 개발자들이 DBA를 깔보게 되는 결과가 될 겁니다.

그리고 인기를 끌어보자고 마이크로소프트를 무턱대고 욕하는 것이 아닙니다. 김상욱님이 이 업계에서 얼마나 잔뼈가 굵으셨는지 모르겠습니다만 저도 SW 개발로 업을 삼은지 13년이 되었습니다. 그동안 마이크로소프트가 해온 짓들을 보고 비난받을 문제들에 대해 정당하게 비난하는 겁니다.

저는 논쟁에서 제가 잘못한 것이 없다고 생각하면 잘못했다는 말은 죽어도 못하는 체질이니 괜히 공치사로 저도 잘못했다는 말은 안나오는군요. 저는 오라클이나 다른 어떤 제품이라도, 심지어 볼랜드의 제품이라도 잘못된 것은 잘못했다고 지적하는 데에 전혀 거리낌이 없습니다. 그러니 비단 마이크로소프트의 제품이어서가 아니라 잘못인 거 같다 싶어도 내가 주로 사용하고 좋아하는 제품이니까 덮어주자는 식은 못합니다. 왜냐 하면 저는 개발자이자 개발 관리자기 때문입니다. 잘못의 책임을 명확하게 보고를 해야 할 책임이 있으니까요.
SteelHeart [kronian]   2004-11-27 13:57 X
DB는 죽었다가 꺠어나도 잘 모르는 학생이지만..보고 어이가 없어서..

--------------------------------------------------------------------------------
흠. 앞의 사과가 무색하게 공격하시네요.
====> 사과는 자신의 잘못을 인정하고 상대가 받아들여야 하는 겁니다. 그건 사과가 아니에요..

=>표준과 상식은 제발 제대로 알고 말씀하세요. 밑에 김대우님글을 보니까 언급된게 있군요 꼭 읽어 보시고 좀더 찾아 보시고 연구해보십시오.
====> 제대로 아는 게 어떤 건지 글쓴 분의 '설명' 부탁드립니다..학생이라 잘 모르겠네요..

=> 님이 말씀하시는 표준이라는게 '님의 머리속에서 대강 짐작한' 그런 표준이 아닌가 궁금합니다. 그리고 단순 제품 인터페이스만 익혔다고 덤비는 것부터가 전문가로서(SQL에 국한된것이 아닌) 좀 어설프지 않나요?
====> 한 사람 머리속에 있는 건 표준이라 부를수가 없습니다. 학생도 다 알고 인정하는 표준인데 뭐..그리고 꼭 전문가만 비판을 가하고 논할 수 있는 건 아닙니다. 민주주의 사회는 어느 누구든지 의견을 표출할 권리가 있어요. 프로그램 사용자는 늘상 전문가만 있는 것도 아니랍니다.

=>흠... 자신이 아는것이 전부라고 생각하는게 더 잘못되지 않았나 싶은데... 예전에 아는 사람들은 눈에 휜히 보인다는 손으로 당기는 핸드브레이크를 몰라서 당황하다 누구한테 물어본 기억이 나네요. 모르면 비난하기에 앞서 찾아보고 물어보세요.
====> 동감입니다. 자신이 아는 것이 전부라고 생각하진 마세요.

=>첨에는 저와 MS를 한편으로 만들어 공적(공공의적)화 하시더니 이제는 저와 개발자사이 까지 적대화 시키시는 겁니까? 혹시 제게 항상 도움만 주시는 개발자들께서 님의 글만보고 오해하실까봐 걱정입니다.
====> 임프님이 공적화 한건 맞네요. 사실 제가 봐도 '한편'으로 보여요. 아참, 개발자들께서 오해하실 걱정은 안하셔도 됩니다. '표준'을 알고 '상식'이 있는 개발자라면 임프님 글이 옳은지 틀린지 알고 이해하실 거랍니다. 굳이 걱정 안하셔도 다들 아실 겁니다.

=>이제는 '너 몇살이야?'로 나오시는 건가요? 13년동안 아집과 편견에 사로 잡혀 사셨군요.
====> 경력은 나이가 아니에요. 전 7년동안 프로그래밍을 공부했지만, 아직 부족하다고 느낀답니다. 절대 '7년씩이나 공부했으니 난 실력자다' 라고 우기지 않습니다.

=>정당한 비난 좋습니다. 그러나 잘 알지도 못하면서 편견과 아집에 쌓여 '누가 이랬데 저랬데' 하는건 이런 공간을 책임지시는 분으로서 창피하지 않나요?
====> 책임자나 공인이라고 해서 못할 말은 없습니다. 말에 대해서 책임만 지면 됩니다. 임프님은 적절하게 책임을 지시니깐, 별로 창피하다고 생각하지 않으실 겁니다.

=> 네! 알겠습니다, 지훈님 아무 잘못도하지 않으셨습니다. 단 공부를 더 하셔서 잘못된 오해를 푸셔야 할 뿐입니다.
====> 글쓴 분도 "공부를 더 하셔서 잘못된 오해를 푸셔야 할 뿐"인것 같습니다.

=>생각해 보니 자신이 최고며 자신의 생각이 진리라고 생각하시는 분에게 이러는게 시간낭비군요. 그냥 님께서 아무 문제없이 최고로 사용할 수 있다고 믿으시는 그 거룩한 DB를 사용하세요. 대신 님이 생각하시는 싸구려 DB들에 대한 허무맹량한 NEWS는 이제 그만 하시길.
====> 제가 보기에는 글쓴 분이 '자신이 최고며 자신의 생각이 진리라고 생각하'시는 것 같습니다. 그런 생각을 하는 사람은 다른 사람의 의견을 받아들일 줄을 모르거든요. 그리고 파이어버드는 무료이기 때문에, 결코 MS SQL이 '싸구려'가 될 수는 없겠군요. DB가 이제 신앙의 대상이 되었다는 걸 오늘 깨달았습니다. MS SQL 만세! Bless You!

+ -

관련 글 리스트
10092 MS SQL서버 2000의 치명적 버그를 의심하다... 박지훈.임프 5549 2004/11/17
10102     Re:안녕하세요. SQLER의 코난 김대우라고 합니다. 지나가다가 몇자 적습니다. 김대우 12907 2004/11/19
10104         반론 드립니다. 박지훈.임프 3796 2004/11/19
10107             (지적해 주셔서 감사합니다. 수정했습니다.)결국 SQL서버의 문제/버그가 아니란거군요. 김대우 5557 2004/11/21
10114                 김대우님... 박지훈.임프 2601 2004/11/23
10117                     참 안타깝습니다... 반MS, 친MS라니요... 김대우 2312 2004/11/24
10119                         저도 안타깝습니다. 누구나 아는 엄연한 사실을 루머라니요. 박지훈.임프 2243 2004/11/24
10128                             주제넘게 두 분께 싫은 말씀 드립니다. 소프트진™ 2198 2004/11/24
10120                             Re:반MS님이 말씀 하시는 누구나 다 아는 "사실"이 참 궁금합니다. 김대우 2354 2004/11/24
10125                                 보여드린 것을 보지 못하셨나봅니다. 박지훈.임프 2271 2004/11/24
10137                                     점심때 너무 날씨 좋았죠? 그동안 토론을 진행해 주신 지훈님께 감사 드립니다. 김대우 2331 2004/11/25
10230                                         두분께서 직접 만나셔서 담판을 짓고 알려 주세요.- 공개 세미나 소리바람.OJ 2038 2004/11/26
10141                                         Re:점심때 너무 날씨 좋았죠? 그동안 토론을 진행해 주신 지훈님께 감사 드립니다. 이성호 2038 2004/11/26
10123                                 잠시 휴식시간을 가지세요. 소리바람.OJ 1648 2004/11/24
10108                 Re:결국 SQL서버의 문제/버그가 아니란거군요. civilian,안영제 2371 2004/11/21
10111                     Re:Re: 그냥...... 서주형.무소유 2111 2004/11/22
10098     MS SQL서버 2000 사용자는 아닙니다만... 바람 10688 2004/11/18
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.