웹접근성 반영 홈페이지 구축비용은?

2배이상이 들지 않을까요?
인력+장비+시간

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

만약 돈이 더 든다고 생각 되는 문제가 발생한다면...

웹 표준화 프로젝트에 알려 주시면 돈 버는 방법을 알려드리겠습니다.
http://forums.mozilla.or.kr/viewforum.php?f=9

무슨 광고 같네^^

저도 위 글에 동감합니다.

표준에 대해 이해하고 꾸준히 그것을 지키려고 노력한 개발자들만으로 이뤄지는 프로젝트라면 비슷하거나 오히려 더 적은 비용이 들지도 모르지만, 현실적으로 대부분의 개발자들은 MS종속적인 방법만을 익히거나 구현에만 급급한 것이 일반적인 상황이라 생각합니다.

이런 상황에서 개발자들에게 표준적인 방법을 익히게 하고 표준에서 벗어나지 않게 감독하는것에 비용이 상당히 들어가리라 생각합니다. 만약에 프로젝트들이 충분한 시간적 여유가 있고, 개발자들의 적극적인 참여 의지가 있다면 언젠가는 저비용이 들면서도 위 사항들을 만족시키는 프로젝트가 될수도 있겠지만, 그건 어디까지나 이상적으로 이뤄졌을 경우이고 실제적인 상황에서는 비용이 증가되는 현상을 보이지 않을까요?

투표 결과를 보면 비용이 절감된다는 의견이 다수인데, 어떤 조건하에서 어떤 과정을 거쳐 그런 결과가 나올 수 있는지도 같이 피력해주신다면 도움이 되겠습니다. 저같은 경우는 (주위를 둘러보면....) 최하 1.5배는 감수할 수 밖에 없다는 생각이 들거든요.

그리고 욕심많은오리님의 말씀은 일리가 있기는 하지만 조금은 논외라는 생각이 듭니다. 사업에 있어서는 on time에 반드시 끝내야 하는 경우가 있습니다. 예를 들어 당장 x월 x일에 서비스가 되어야 하는데 타겟 유저는 한국내에 국한되고 개발인력은 웹 표준에 대한 이해가 부족한 상태다. - 라고 가정을 하면 좀 억지스러울지 모르지만 이런 경우는 국내에 수도 없이 많다고 생각합니다.

저같은 경우는 크로스브라우징을 염두하고 개발을 하는 편이지만 다른 사람을 설득/교육해가면서 개발을 하기는 쉽지가 않습니다. 특히 상대가 윗사람인 경우에는 더욱 더 말이죠. (거의 불가능하다고 생각하고 지냅니다) 저희 팀장은 제가 firefox를 띄워놓고 있으면 '이상한거' 쓴다고 합니다. 하지만 어쩔 수 없죠 상급자인데다가 회사 입장에서는 firefox에서 안된다고 항의받은 적이 한 번도 없고 돈은 꽤 잘 벌고 있으니까요. 그런데 이런 상황이 일본에서도 비슷한가봅니다. 얼마 전에 일본의 좀 큰 회사와 제휴를 해서 저희 프로그램의 일본판을 넘긴 적이 있는데, 지금 일본에 파견가있는 동료 개발자의 말에 따르면 일본측 회사에서도 firefox 및 IE 외의 브라우저에서 동작이 잘 안되는거 같다고 문의가 왔었다더군요. 그런데 '어쩔 수 없다'라고 얘기를 했더니 쉽게 수긍을 하는 분위기였다고 합니다. 그 일본 회사는 허접한 회사는 아니고 여러가지 인터넷 사업을 하는 꽤 큰 회사입니다.

조금 얘기가 옆으로 샜는데, 다시 요점을 정리해보면..
분명히 개발인력과 경영진이 웹표준에 대해 교육하고 설득하는 과정은 비용(돈과 시간 그리고 노력을 포함)이 듭니다. 그런데 많은 분들이 비용이 절감된다고 하시니 비법이 궁금할 따름입니다. 저같은 경우도 웹표준에 관심을 가지고 개인적으로나마 노력을 하게 되기까지 꽤 많은 시간이 걸렸습니다만 비즈니스의 관점에서 볼 때 그런것도 모두 비용이라고 볼 수 있겠죠. 물론 시장이 더 확대되기 때문에 투자라고 볼 수 있겠지만 그렇다면 얼만큼 시장이 확대되는지에 대한 이야기가 필요하다고 봅니다. firefox가 '이상'하고 css를 쓰면 느려지지 않느냐고 물어보는 상급자에게 표준 준수에 대한 도덕적인 설교는 불가능하니까요.

대체로 프로세스가 제대로 갖춰지 있지 않기 때문에 비용이 지출된다고 알고 있습니다만. 그 비용 지출 이후에 제대로 프로세스가 갖추어 지면 훨씬 비용 절감 효과가 있다고 알고 있습니다.

컴퓨터 뿐만 아니라 산업 전반에 걸친 진리입니다.

그렇지 않습니다. 표준 준수 자체로 비용 절감이 생길 수 있는 이유를 살펴 보겠습니다.

1. 우선 회선 및 장비 비용이 줍니다. HTML코드는 웹서버나 프로그램의 수행 결과로 떨어지는 겁니다. 따라서 코드가 간결해지고 크기가 줄면 그만큼 회선 및 장비 사용 비용이 줍니다. 특히, 이미지나 CSS, JS 파일이 확실히 분리되고 캐쉬를 제대로 쓰고 있다면 절약 효과는 배가 될 수 있습니다. 이것은 이미 외국이나 국내 포털에서 입증된 이야기입니다. (물론 작은 사이트 일수록 효과가 줄겠죠.)

2. 대략 웹페이지를 여러 버전을 만들어야 할 경우, PDA/휴대폰/인쇄용/텍스트/장애인용 등등.. 이 경우 한페이지만 만들고 스타일 변경 또는 해제 만으로도 각 audience를 만족하게 할 수 있습니다. 프로그램을 카피&패이스트를 하는 것도 죄악입니다.

3. 웹 표준은 궁극적으로 비 윈도우, 비 IE 사용자에게 비지니스 기회를 넓혀 줍니다. 특히 매킨토시 사용자의 경우 자신들을 위한 서비스를 제공해 주는 곳은 기꺼이 비용을 지불할 용의가 있는 사람들입니다. 돈 안되는 수백만의 윈도우 사용자 보다 돈낼 수천의 맥 사용자가 훨씬 가치 있을 겁니다. (맥.com에서 수만 카피가 팔린 블로그툴이나 freebank 프로젝트만 봐도 그렇습니다.)

4. 만약 회사가 웹 표준을 통한 사이트 구축에 대한 기술력을 확보하고 있거나 하려고 노력한다면 단기적으로 돈 벌 가능성이 있습니다. 행자부에서 공공 기관 평가 지침에 웹 표준을 준수하도록 함으로서 이에 대한 기술 지원을 할 사람들이나 구축 할 회사들이 부족하기 때문입니다. 실력을 쌓으면 돈이 보일 겁니다.

제가 이야기 한 것은 당장 돈이 눈에 보이는 것을 말씀 드렸구요. 그 외에 장점은 더욱 많겠죠.

표준에 맞게 잘 개발할 수 있는 인력을 구한다는것 자체가
기업입장으로선 추가비용을 지불하는것이 됩니다.
"만약 표준에 맞게 잘 개발할 수 있다면....절감할 수 있다.."
라는 가정은 받아들일 수 있겠으나 가정은 가정일뿐이고
대부분은 그런 인력을 구하던지 아니면 기존인력을
학습시키던지 둘중 하나를 택일해야 합니다.
두 경우 모두 추가 비용이 발생합니다.

php.net에 어떤 특징적인 기술이 적용되어 있는 것 같진 않는데요.. 가변해상도, 라는게 구체적으로 어떤 것을 말씀하시는지 모르겠는데, 제가 이해한 바로는 예로 들었던 php.net에서처럼 브라우져의 가로 크기를 줄이거나 늘여도 거기에 맞게 컨텐츠가 조절된다는 것인가요?
php.net은 그냥 table의 width를 px이 아닌 %로 주었을 뿐이던데...

아무튼 agolta님 글을 보니 예전 홈페이지마다 "이 사이트는 xxx해상도와 IE x버젼에 최적화 되어 있습니다." 라는 문구를 넣는게 유행이었던 시절이 떠오르는군요. :lol:

표준에 부합하는 웹사이트를 구성하는 것에 대해서 ‘옳으냐/그르냐’, ‘바람직하냐/아니냐’, ‘즐겁냐/괴로우냐’ 하는 생각은 해봤었지만, ‘비용이 얼마나 더/덜 드느냐’라는 생각은 단 한 번도 떠올려보지 못했었습니다.

개인적인 짐작으로는, 인식도 부족하고 제대로된 인력도 부족한 국내 현실에 비추어볼 때, 이 상태에서 강행한다면 아마 단기적으로는 비용이 더 들지 않을까 생각합니다. 하지만 장기적으로 생각한다면 여러가지 의미에서 부대 비용을 줄이는 효과가 있지 않을까요? 시장에는 표준에 부합하기만 하면 모두 제대로 동작하는 다양한 UA들이 쏟아져나와 경쟁하면서 성능과 가격을 향상시킬 수 있게되고, 제대로된 인력 공급이 들어나기 시작하면 인력 수출도 가능해지지 않겠습니까? :)

사례를 하나 들어보겠습니다.

사내 개발인원으로 충당한 것이기에 비용으로는 환산이 좀 어렵겠지만 웹 빌링 시스템(월간 트랜젝션 $1mil 규모)을 멀티플랫폼, 멀티브라우저 및 어느 정도 수준의 w3c 표준 준수로(기능과 디자인을 고려했을 때 완전히 지키는 것은 무리더군요.) "강행" 했습니다. (뭐 다 사내 개발 가능하였으니 트레이닝 겸해서 OK한겁니다만..)

웹접근성을 위해 그래픽 요소에 alt 정보를 입력하고 디자인을 위해 선택한 메뉴를 플래시를 이용할 수 없거나 스크린리더를 쓰는 사람을 위하여 대체메뉴를 구성하는 일 및 QA 작업에 들어간 리소스는 전체적으로 봐서 윈도우/IE 기준만 보고 개발하는 것의 3배 정도 들어간 것 같습니다. (개발기간과 인건비를 기준으로 산정한겁니다.)

비용 이야기에 테이블이나 CSS 이야기가 나오는 이유를 전 잘 모르겠군요. CSS를 잘 쓰는 인력이 비싸다면 모르겠지만 그렇지도 않고요...
실제 제작을 시켜보면 XP/IE, XP/FF의 두 구성이나 98/IE, XP/IE의 구성이나 리소스는 비슷하게 들어갑니다.

음...제가 글타래의 흐름을 잘 이해 못한 것 같아 질문 겸해서 써봅니다.

맨 처음에 올라온 글의 의도대로라면 단순히 웹페이지를 표준을 지켜서 만든다. 라는 의미가 아니라 멀티 플랫폼을 명시적으로 지원한다는 이야기가 아닌가요?

개인 홈페이지 정도라면 모르겠지만 백엔드와 별도로 웹 프론트엔드에 예산과 규모를 어느정도 배정할 정도의 프로젝트라면 검증작업에 들어가는 인건비 및 소요시간이 플랫폼 구성 수 만큼 늘어나야 할 것입니다. (그렇지 않고서는 그냥 동작 할지도 모른다. 라는 것이지 모든 디자인 의도대로 멀티플랫폼에서 동작을 보증한다고 할 수는 없죠. 그리고 표준을 지켰다고 해서 검증작업의 양이 줄어드는 것도 아닙니다.)

표준 준수 이전에 다른 방향에서 추가비용이 당연히 발생하는데 왜 표준이 비용 절감에 키포인트처럼 이야기되는지 모르겠습니다.

저로서는 오히려 표준을 지키고 4개의 멀티플랫폼을 가는 것과, 4개의 플랫폼에 종속적인 기술을(뼈대는 물론 같고요) 쓴 페이지를 UserAgent 구분해서 포워딩하여 보여주는 것이나 개발 및 유지 비용에 차이가 없다고 보고 있습니다. (오히려 후자가 프론트엔드 담당자에게는 로드가 늘지만 디자인 유연성이나 플랫폼간 특이요소 충돌로 발생하는 부분을 보수하기에 유리한 면도 있고요.)

위에도 나왔지만 CSS와 테이블 중 어느 것을 선택해도 비용에 차이가 거의 발생하지 않는 것과 같이, 웹 구성에 있어 플랫폼 종속적인 기술을 일부 사용한다고 해서 비용에 큰 차이는 발생하지 않습니다.

웹 코더에 들어가는 비용은 전체에서 보면 매우 한정적이기도 하고요. 다른 쪽에 들어가는 인건비와 비교해도 싼 편이지요.

오히려 하나로 모든 것을 만족시키려는 시도가 싼 가격으로 끌어 쓸 수 있는 기존의 XPCOM/ActiveX 컴포넌트 대체재를 작성하는데 더 큰 비용을 지출하게 만들기도 합니다. (이쪽은 돈을 제대로 잡아먹으니...)

그리고 달라지는 부분이 몇%가 될 것인지는 코더 자신의 능력에 달려있는 문제입니다. 코더가 표준을(혹은 표준이 아니더라도 여러가지 workarounds) 잘 활용한다면 그의 고통은 줄어들겠지요. :twisted:

능력있는 사람에게 투자를 더 해야하는 것은 맞습니다만, 표준을 잘 지키는 것과 능력이 있다는 것에는 무슨 관계가 있는지 모르겠습니다.

표준을 지키지 않고 같은 결과물을 생산할 수 있는 인원과 비교하여
표준을 잘 지킨다고 돈을 더 받은 사례가 있다면 듣고 싶군요.

위 글에서 비용은 지급해야 하는 보수를 이야기하는 것이 맞나요? 그렇다면 좀 구체적인 사례를 들어주셨으면 좋겠습니다. (예를 들자면 CSS 를 잘 쓰는 인력을 고용하면 반값에 일을 시킬 수 있다던지...)

맨 처음 글을 다시 돌아보자면, 제가 말하고 싶었던 것은 비용은 멀티플랫폼의 수에 비례하여 증가할 뿐 표준의 준수 여부는 비용에 거의 차이가 없는 요소라는 것이었습니다. (첫 글에 제시된 것은 멀티플랫폼, 표준 준수의 두가지 기준이었죠.)

멀티플랫폼에서 비용이 증가한다는 것에는 이견이 없을 것 같고, 남은 것은 표준을 지키는데 추가비용이 발생하는지의 여부인데 쭈욱 읽어보면 표준을 활용하면 비용이 감소한다는 측과(인건비는 동일하게 들어가고 기타비용이 절감된다는 논지), 표준을 잘 쓰는 인력은 돈을 많이 받는다는 의견이 있군요.

보통 SI에서 말하는 비용은 man month, 사람은 다 같다고 보고 시간으로 비용을 산출하죠. 비용이 적게 든다 함은 보수를 적게 지불한다는 뜻이 아니고 짧은 시간에 일을 끝낼 수 있다는 뜻이랍니다.

그리고 멀티플랫폼에서 비용이 증가하는 건 당연하지만 여기서 비교를 해야할 것은 표준을 지킬 때 멀티플랫폼에서 비용 증가하는 양과 표준을 지키지 않을 때 증가하는 양이죠. 표준을 지지하는 사람들은 그 양이 표준을 지킬 때 훨씬 적게 증가한다고 주장하는 것이구요. 즉, 플랫폼 수가 늘수록 표준을 지키는 쪽이 비용 증가폭이 적다는 겁니다.

표준을 잘 쓰는 인력이 돈을 많이 받는다는 건 전 잘 모르는 바라 무어라 말을 못하겠네요.

MS 표준이란게 존재하나요? 비표준적인 MS 기술만 존재할 뿐입니다. MS도 W3C 회원사이고 표준을 대부분 지원합니다. W3C 표준을 사용하면 비 윈도 OS, 비 IE 웹브라우저, 장애인, 다양한 디바이스 접근성 등이 별도의 고려 없이 높아 지므로 비용이 감소한다는 것입니다. MS기술 만을 이용하면 당연히 비용이 증가하죠. VC++로 개발된 윈도우 프로그램을 리눅스나 맥에서 사용하게 하기 위한 비용 증가가 당연히 있는 거 아닙니까?

표준 무용론을 주장하시는 것 같습니다. 웹 브라우저는 Universal Access와 Interoperability를 중요시 하는 공공재적인 성격이 강합니다. 옛날 처럼 IE vs. NS 브라우저 전쟁이 가져온 폐해가 바로 우라가 다 알고 있는 독점의 폐해 입니다. 어쨌든 파이어폭스는 유럽에서 25%의 점유율을 보이고 있습니다. 점유율이 작다고 말하지 마십시오.

파이어폭스가 가져온 이득은 웹의 공공성을 확보하고 IE를 통한 독점으로 인해 웹 기술 적용이나 사용자 편의성이 발전하지 못한 상황을 바꾼 것입니다. 이런 오픈 소스의 노력에 대해 개발자들이 할 수 있는 것은 웹 표준을 지켜 주는 것입니다. 대안이 분명히 존재하는데 그걸 사용하지 않을 필요가 있는 것인가요.

표준과 비표준이라는 것은 관점의 문제에 불과합니다. 예를 들어 스페인에서 팔리는 냉장고는 스페인 표준에 맞게 생산된 플러그를 달고 있습니다. 이걸 우리나라에 가지고 와서 벽에 꽂으려고 하면 꽂히질 않지요. 우리나라 표준에 맞지 않으니까요. 그렇다면 스페인 냉장고는 비표준 제품입니까, 표준 제품입니까?

상식적으로 보더라도 전국의 모든 IE 전용 사이트를 고치는 게 비용이 적게 들까요, 파이어폭스가 IE 전용 문법을 이해하도록 고치는 게 비용이 적게 들까요. 전자의 경우 천문학적인 액수가 들 것이라고 장담합니다.

사실, "웹표준화 운동"의 목표는 비용 절감도 아니고, 유니버설 액세스라든가 웹의 공공성도 아닙니다(위에서 설명한 바와 같이). 단지 목표를 수립하고, 목표를 위해 노력하고, 목표를 달성한다는 운동의 3단계 과정 중 한 단계로서 표준화를 부르짖는 것 뿐입니다. 이것이 정말로 사용자에게 어떤 장점을 주느냐는 또 다른 차원의 문제입니다.

모든 표준은 그것을 지키는 사람에게만 표준입니다. 나머지 사람들, 즉 그것을 지키지 않는 사람들과는 관련없는 문제입니다.

알겠습니다.
새로운 쓰레드를 열도록 하겠습니다.

만약 수백만권의 장서를 자랑하는 국내 최대에 도서관을 새로 짓는다고 가정해봅시다. 도서관을 어디에 지어야 할까요?

'서울에 사람이 많이 사니까 서울에 짓자! 그게 제일 효율적인것 아니냐? 뭐? 부산에 짓자고? 아니 이사람이? 부산이 아무리 제2의 도시이긴 하지만 서울에 지으면 수도권및 경기도가 다 해택을 누릴수 있고... '

아마 이런 말들이 많이 나오겠죠? 도서관 같은 경우는 장소의 제약을 가지게됨으로 온 국민이 누구나 이용하기는 현실적으로 힘이 듭니다. 이런 거대한 도서관을 인터넷으로 짓는다면 어떨까요? 온국민 누구나 인터넷이 연결된 PC만 있다면 이런 멋진 도서관을 마음것 누릴수 있게될 것입니다.

하지만 인터넷이 연결된 PC가 없는 사람들도 핸드폰을 이용해서, PDA등 여러 도구를 이용해서 정보에 접근할 수 있다면 참 멋진일이 아닐까요?

또한 시각,청각 장애인들도 여러방법으로 접근할수 있도록 만든다면 누구나 이용할 수 있는 도서관 은 실현되는거라 생각됩니다.

만약 이러한 도서관을 특정브라우저 전용 으로 만든다면 위에서 말한 일들을 실현하기는 힘들겁니다.

돈이 넉넉치 못하다던가, 여러 이유로 MS Windows를 구입할수 없는 개인, 기관, 단체 에게도 웹을 자유롭게 누릴 수 있는 권리가 있습니다. 이런 권리가 지켜지려면 웹 개발자들의 웹 마인드가 정립될 필요가 있다고 생각합니다.

누구에게나 열린 웹을 만들수 있는 방법중 가장 첫번ㅤㅉㅒㅤ가 W3C표준에 맞게 페이지를 만드는겁니다. 여기에 다른 더 좋은 의견이 있습니까?

'이제것 잘해왔다! 왜 힘들게 공부해서 만든걸 다 뜯어 고치라고 하느냐? 지금도 잘나오지 않느냐? 잘 안보이면 니가 잘보이는거 써라!! 난 잘보인다.'

이건 자신의 실력 없음을 완벽하게 드러내는(그리고 프로정신도 없고) 완벽하게 무식한 소리입니다.

'잘못 배운겁니다. 다시 배우세요.'

어차피 물은 흘러가는 법이고 그 흐름을 거부해봤자 도퇴 될 수 밖에 없는겁니다. 만약 그 흐름을 못느끼고 있다면 그도 어쩔 수 없지만, 최소한 눈치라도 있거나 겸손하기라도 해야할텐데...

:D :D :D :D :( - 현재 우리의 웹

:lol: :lol: :lol: :lol: :lol: + 8) - 우리가 만들어 가야할 웹

모두가 웃는 웹을 위하여

새는? 왱알앵알

그게 문제인데요. 도대체, 물건을 구입하는 쇼핑몰 하나당 ActiveX control을 하나씩 깔아야 하니... 그런데, visa 카드를 받는 어떤 곳에서 (어디인지 잊어 버렸습니다) 리눅스 상의 파이어폭스로 아무 문제 없이 결제(우리 은행의 BC/Visa 카드)를 완료했습니다. Visa는 요새 ISP라는 것을 쓰는 걸 아시지요? (안심 클릭) 비자 카드 본부에서 개발한 방법으로 ActiveX를 쓰지 않고도 얼마든지 결제가 가능합니다. 그런데, 이것도 - 귤이 회수를 건너면 탱자가 된다고 - 한국에서는 ActiveX로 해 놓은 곳이 많더군요.

같은 카드인데도 어떤 곳에서는 ActiveX를 써야 하고, 어떤 사이트에서는 리눅스에서도 아무 문제 없이 결제가 된다는 얘기는 최소한 ISP의 경우 카드/은행 차원이 아니라 웹 사이트 구축하는 측에서 결정할 수 있다는 얘기겠지요? 이런 경우라면 맥/리눅스 사용자로 시장 확대를 할 수 있다고 얘기해도 될 듯 합니다.

비용 문제:

설문에서 '웹 접근성'을 좀 오용한 감이 있습니다. 웹 접근성은 장애 정도에 관계 없이 누구나 웹을 사용할 수 있는 것을 말합니다. 웹 표준을 준수하고 장치 독립성과 상호 운용성 등을 고려해서 만든 웹 사이트는 그만큼 웹 접근성도 높겠지만, 그것만으로 웹 접근성이 보장되는 것은 아닙니다. 웹 콘텐츠 접근성 제작 지침 1.0을 보시면 좀더 자세한 내용이 있습니다.

비용이 더 많이 들 것이냐, 적게 들 것이냐는 한 마디로 답하기는 거의 불가능하다고 생각합니다. 현재 가용 인력의 웹 표준에 대한 이해 정도가 특히 큰 변수가 될 것 같습니다. 그 이해 정도가 높지 않다면, 그들의 재교육 비용이 꽤 들어갈 테니까요. 또, 문화적 차이를 극복해 나가는데 드는 비용도 비용이라면 비용이고요. 또, 비용을 계산할 때 딱 프로젝트 하나만 떼어 놓고 이런 재교육 비용을 모두 다 이 프로젝트 비용에 붙여 버리느냐, 앞으로도 계속 다른 프로젝트를 이런 식으로 수행할 것으로 보고, 재교육 비용을 분산해서 계상하느냐에 따라서도 결과가 달라지겠지요. 또, 딱 한 번 만들어 놓고, 그 뒤에 손도 안 대는 경우와 계속 유지 보수해야 하는 경우에 비용 계산은 또 달라지겠지요.

저는 ISP와 visa3d(mastercard는 secure code라고 부르는)가 같은 방식인 줄 알았는데, 다른 것이었군요. 제가 오해를 한 이유는 제 카드와 BC card이면서 Visa 카드이고, 결제 시에 요구하는 정보도 같았고 UI도 같았기 때문입니다. 가르쳐 주셔서 감사합니다. 하지만, visa3d가 ActiveX가 있어야 한다고 하셨는데, 그것은 한국에만 해당하는 얘기 아닌지요? Visa 본부가 ActiveX가 필수적으로 요구되는 방식을 쓰리라고 상상하기 힘들고, 실제로 제가 국내 한 곳(거기는 어쩌다 운이 좋았다고 치고)과 외국의 몇 곳에서 Visa3d 방식을 쓰는 곳에서 아무 문제 없이 Visa 카드로 결제했거든요. 기존의 브라우저가 지원하지 않는 암호화 방식이라면 뭔가 다른 쪽에서 해 주어야 한다는 것은 맞는데.... 제가 리눅스에서 할 ㅤㄸㅒㅤ 돌아간 것이 무엇이었는지 모르겠군요. Java signed applet 정도 밖에 저는 생각할 수 없는데...

그렇군요. 하지만, 이 결제 모듈이 한 두 개가 아니라 여러 개인 탓인지 쇼핑몰에 갈 때마다 무슨 예약을 할 때마다 다른 모듈이 깔립니다. 카드는 딱 하나인데요 !

이 부분은 잘못 알고 계신 것입니다. visa3d의 경우 그 트랜잭션과 기능만 보면 activex가 필요 없습니다. 단지, pg사들이 isp(BC/국민)과 함께 기능을 제공하기 위해서 SSL(https) 트랜잭션 과정을 activex안에서 IE embed로 처리하는 것 뿐입니다. 이것은 PG사들이 어차피 activex를 뿌리는 거 visa3d도 같은 인터페이스안에 넣어두기 위해서 입니다. (IE 팝업을 쓰면 modal window 관리하는 것도 어렵고, 고객이 여러 번의 ssl 트랜잭션 중 창을 닫을 수도 있다고 핑계를 대기는 합니다만...)

기술적으로 visa3d는 actviex가 필요없습니다. 그리고 jshin님이 쓰신 BC Visa카드의 경우, 비자카드이기 때문에 ISP결제 해당 사항이 아닙니다. 따라서 기존의 SSL 방식으로 결제가 가능했을 겁니다. 아마 BC visa인 경우 삼성, 외환 등등의 기본 visa3d와 달라서 activex 없이 진짜 visa3d 방식(ssl)을 사용했을 것입니다. 아마 외국 쇼핑몰이였을 거고 당연히 visa3d가 ssl로 되어 있구요. 그리고 visa3d는 비대칭 암호화 방식이 아니고 그냥 ssl입니다.

단, 30만원 이상인 경우 금감원이 자체적으로 만든 내규에 따라 공인 인증이 필요하기 때문에 공인 인증 activex가 필수가 될 수 있습니다.

참고: visa3d는 비자카드가 만든 인증 방식입니다. 외국에서는 카드 비밀번호라는 게 없습니다. 단지 카드번호, 유효기간 만 있죠. 최근 까지 덧붙여서 zipcode를 받기도 했는데 워낙 도용이 심해서 visa3d라는 걸 만들었습니다. 한마디로 visa 홈페이지에서 비밀번호를 세팅하고 결제시 그 비밀번호를 쓰는 겁니다. (키로거에는 여전히 취약합니다. 키로거를 말한다면, 키보드 해킹 방지 activex가 안깔리면 인터넷 뱅킹도 취약합니다. 키로거 같은 악성 activex를 막기 위해 키로거 방지 actviex를 깔아야 하는 이 처절함이 윈도우의 현실입니다..)