기본 콘텐츠로 건너뛰기

오픈 뱅킹 - 접근성과 보안성의 딜레마

언제부터인가 은행들의 마케팅 용어 중 가장 많이 등장하는 용어 중 하나가 오픈 뱅킹이 되었다.

많은 사람들에게는 아직도 낯선 오픈 뱅킹이란 어떠한 운영체제나 어떠한 브라우저에도 구속되지 않고 은행 서비스를 인터넷에서 이용할 수 있도록 하는 것을 말한다.

당연한 것처럼 여겨지는 이 말은 아직도 대한민국에서는 현재진행형인 사건이다.

대한민국에서는 아직도 윈도우와 인터넷 익스플로러가 아니면 제대로 된 은행 서비스를 이용할 수 없는 것이 현실이다.

우리은행을 필두로하여 기업은행, 농협 그리고 최근의 국민은행과 같은 몇몇 은행들은 파이어폭스와 리눅스를 지원하기 시작했지만 이것은 말 그대로 궁여지책에 가깝다.

맥에서 파이어폭스를 사용한다면 제대로 된 서비스를 이용할 수 없는 반쪽짜리나 마찬가지인 이런 서비스에라도 만족하며 살아야하는 것이 작금의 대한민국 오픈뱅킹 서비스의 현실이다.

대한민국에서 오픈뱅킹이 어려운 이유는 여러가지를 들 수 있다.

MS에 종속된 브라우저와 운영체제 시장과 술상무들의 개드립으로 얼룩진 보안시장 그리고 IT와 보안에 대한 무지를 자랑스럽게 여기는 정보와 금융원 등..

어떤 특정 기술에 대한 종속이 얼마나 많은 부조리함을 드러내는지 우리는 이러한 현실을 통해 배웠지만 그에 따른 해결책은 자본이라는 명목아래 아직도 어렵기만 하다.

그나마 이러한 오픈뱅킹에 대한 발걸음이 시작될 수 있었던 장차법과 아이폰을 필두로 한 디바이스 시장의 변화가 고마울 따름이다.

또 다른 이유로는 보안을 들 수 있다. 국내에서는 은행 서비스의 이용을 위한 보안으로 공인인증서, 방화벽, 키보드 보안, 인터넷 보안 등 여러 액티브 엑스를 강제하고 있다. 이것은 여러 논란이 있지만 대체로 강제 조항쯤으로 인식하는 분위기이다.

그나마 반가운것은 6월 이후에는 공인인증서가 아닌 다른 본인 인증에 대한 시스템을 도입할 수 있게 되었다는 소식 정도..

사실 공인인증서도 여러 논란이 있지만 우리 나라의 공인인증은 실제적으로 공인인증이라 말하기 힘든 부분이 너무 많다.

최근 모 금융업체의 차세대 프로젝트(오픈 뱅킹) 서비스를 바라보며 여러 생각이 들었다.

멀티 브라우징을 지원하기 위한 시스템 업그레이드임에도 불구하고 개발자들은 HTML5와 CSS3에 대해 알지 못했다.

PC와 모바일 사이트를 별도로 개발하는 것만 보아도 정말 답이 없어보였다.

분명 멀티브라우징을 지원을 목표로 하는 프로젝트인데 운영체제는 윈도우만 지원한단다.

장차법에 대해서도 알지 못했다.

장애인들에 대한 고려는 없었다.

더 재미있는 것은 HTTPS 프로토콜이 아닌 일반 프로토콜로 서비스가 제공되고 인터넷 보안은 여전히 플러그인과 액티브 엑스에 의존하고 있다는 것이다.

최근의 오픈 뱅킹 서비스를 보면 시대에 따라 법률에 따라 별다른 고민없이 강제로 떠밀려서 어쩔 수 없이 한다는 느낌을 선뜻 지우기가 참 힘들다.

그들에게 장애인들과 사회적 약자들에 대한 좀 더 깊은 이해를 바라는 것은 무리인걸까? 보안도 중요하지만 지금의 보안을 위한 장치들이 정말 제대로 된 보안을 제공하고 있는 것일까? 웹접근성을 높이는 것이 정말로 보안에 취약해지는 것일까?

개발자만 탓할건 아닌 것 같다. 경영진을 포함한 기획자들부터가 장애인들에 대한 그리고 웹 접근성에 대한 이해가 전혀 없다.

물론 테스터들도 마찬가지다. 내가 만나본 웹 서비스 테스터 중 많은 경우 장차법이나 웹 접근성에 대하여 제대로 알고 이해하는 사람은 많지 않았다.

많은 테스터들이 그저 주어진 명세서대로 기능이 정상적으로 동작하는지에 대한 것만 테스트하는 기계의 부속같은 작업에서 벗어나 좀 더 멀리 보고 좀 더 깊이 고민하는 테스터들이 되었으면 한다.

물론 오픈 뱅킹은 아직까지는 법적 강제력이 없다.

장차법에 따르면 '장애인 차별금지 및 권리 구제 등에 관한 법률 제 17조 금융상품 및 서비스 제공에 있어서의 차별 금지' 조항이 2008년 4월 11일부터 적용으로 되어 있지만 실제적인 오픈 뱅킹 서비스는 같은 법 '21조 정보통신, 의사소통에서의 정당한 편의 제공 의무'에 해당하여 2013년 4월 11일부터 적용되기 때문이다.

즉, 장애인을 위한 서비스는 2013년까지 유예기간이 있는 셈이고, 이것을 지금 고민할 필요성을 많은 은행들이 피부로 느끼지 못하고 있는 것 같다. 물론 준비는 하고 있겠지만... 이것이 결코 짧은 시간내에 이룰 수 있는 것인지에 의문이 든다.

보다 많은 은행들에 고용되는 개발자들과 테스터들이 이에 대하여 좀 더 진지하게 고민했으면 하는 바램이다. 그리고 무엇이 진정 제대로 된 보안인지에 대해서도 고민했으면 하는 바램이다.

그냥 갑갑한 마음에 적어본 포스트로 몇몇 내용들은 사실 여부에 논란이 있을 수 있음을 알고 있습니다. 관련 의견이 있으신 분들의 댓글은 열렬히 환영합니다.

댓글

  1. 승은 신14/7/11 17:33

    현재도 얼마든지 바꿀 수 있는 보안방식인 ActiveX방식에 대해 사용자 불편이나 보안문제를 문제시하는 핑계는 이미 물건너간 상황으로 보아집니다. 좀더 사용자 편의를 고려하는 고민을 조금만 더 하면 될걸로 보여집니다..장애유형별로 필요한 요소의 고려도 조금만 더 고민하면 해결되는 문제인데...

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

프로젝트의 3요소 - Project Management

프로젝트는 예산, 일정, 품질 3가지 요소로 이루어진다고 볼 수 있다. 물론 위 3가지 요소 외에도 개발 범위, 팀워크, 자원 조달 등 여러가지 요소들도 고려해 볼 수 있지만, 가장 중요한 요소를 꼽는다면 예산, 일정, 품질일 것이다. 위에서 말한 여러가지 요소들은 프로젝트를 계획하여 완료하는 순간까지 복합적으로 작용해서 프로젝트의 성과를 제한하게 된다. 위의 요소들을 잘 통제한다면 성공적인 프로젝트가 되는 것이고 그렇지 못한다면 실패하거나 사라지게 될 것이다. 프로젝트 관리란 그런 면에서 제한된 자원을 가지고 목적한 바를 제한된 기간내에 최소의 비용으로 완수할 수 있도록 하는 것으로 정의할 수 있을 것이다. 이것을 도식화 한다면 아래와 같은 그림으로 표현할 수 있을 것이다. 위의 그림에 보는 것처럼 일정과 품질, 예산은 우리의 프로젝트가 목적하는 바를 달성하도록 하기 위해 상호 연관되어 작용하게 된다. 우리가 접하게 되는 많은 방법론들의 가정에는 위의 요소들을 어떻게 관리할 것인가에 대한 기본적인 가정들이 설정되어 있다. 조직에서 어떤 특정한 방법론을 도입한다는 것은 그런 가정에 동의하는 것이고 그러한 철학을 받아들인다는 것이기 때문에, 방법론을 채택하기 전에 조직의 근본 문제와 문화에 대해 점검해 볼 필요가 있다. 그리고 위의 요소들 외에 고려해 볼 사항은 위의 요소들은 변동성과 불확실성을 내포하고 있다는 것이다. 특히 비용과 예산, 목적은 프로젝트를 진행하면서 가변할 가능성이 매우 큰 요소들이다. 대부분의 방법론은 이러한 변동성에 대한 안전장치들을 가정해서 세워져 있다. 변동성의 측면에서 위의 요소들을 다시 살펴본다면 아래와 같이 가정할 수 있다. 위의 그림을 일부 해석해 본다면 일정이 늘어난다면 비용은 늘어나게 된다. 범위가 변경되어도 비용은 늘어나게 된다. 범위와 일정은 상호 의존적이 된다. 만약 위 3가지 요소의 변동성을 통제하지 못하게 된다면 프로젝트는

내 인생 첫 차량 구매 후기 - 쉐보레 스파크

다사다난한 2011이 끝나고.. 2012년이 밝았군요.. 머.. 저는 언제나처럼 설날을 기준으로 하기 때문에 별다르게 주변 분들에게 새해 인사를 하거나 그러지는 않았습니다만.. TV고 어디고 간에 새해가 밝았다 하니 그런가 합니다.. 저는 어제 저녁 아내님이 2도 화상을 입으시는 바람에 송구영신 예배나 새해 맞이 예배는 가지도 못했고.. 그냥 한해의 액땜을 제대로 했구나 하고 있습니다. 오늘은 출장 가기 전에 체력 비축하고 있습니다... 아.. 그냥 방에서 뒹굴거리고 있습니다.. 간만에 좀 뒹굴거리는것 같네요.. 어쨌든 새해 첫날 먼가 참신한 글을 써보고 싶었지만.. 소재가 그렇게 뉴턴의 사과처럼 머리로 떨어져주는건 아니니.. 지난 해 진행했던 카드 소팅 결과는 참여하신 분들이나 기다려주시는 분들에게는 죄송하지만 조금만 더 기다려주시면 고맙겠습니다. 그래서 오늘의 소재는 써야지.. 써야지.. 하면서 차일 피일 미루던 제 인생 첫 차량 구매 후기를 올려보겠습니다. 제가 운전을 잘 하거나 차량에 대해 잘 알고 있는 것이 아니기 때문에 그냥 참고만 하시면 되겠습니다. 우선 제가 차량을 구매하게 된 동기는 .. 그렇습니다.. 애들 때문입니다. 자녀가 둘이 되니.. 엄마, 아빠의 팔뚝 힘으로는 더 이상 외출이 힘들어졌습니다. 그래서 차를 구매해야겠다고 무리를 하게 되었습니다만.. 역시 언제나 부족한 것은 총알이죠.. 그래서 당연히 경차로 알아보게 되었습니다. 하지만 아시다시피 우리 나라에 경차는 딱 두가지입니다.(지금은 레이라고 새로 나와서 세가지가 되었지만.. 제가 차를 구매할때는 두 종류였습니다.) 선택이라고 할것도 없죠.. 현대 차는 고객을 개새끼로 아는 현대의 투철한 정신에 절대 사고 싶지 않았고.. 쉐보레는 옛날 대우 생각을 하면 이것도 역시 사고 싶지 않았지만.. 여기 저기 얘기를 들어보니 쉐보레로 변하면서 차 좋아졌다.. 쉐비케어가 진리다.. 라는 얘기에.. 그냥 스파크 구매로 결정했습니다

QA 부서는 필요한 것인가?

많은 프로젝트 관리 방법론과 조직론에서 항상 얘기하는 것이 QA 부서를 독립적으로 두는것에 대해 강조하는 편이다. 테스트 역시 테스트 조직을 별도로 두는 것에 대해 강조하는 편이다. 이러한 QA 부서 또는 테스트만을 전담하는 조직이 꼭 별도로 존재해야 하는 것일까? 테스트의 경우에는 개발자와 다른 시각을 가진 사람들의 테스트의 필요성을 강조하기 위해서 테스트 조직을 별도로 두는 것을 강조하는 편이다. 만약 테스터가 개발이나 영업, 운영과 같은 조직의 하부 조직이 되다 보면 정치적인 독립성에 따라 자신만의 독립적인 시각이나 의견을 피력하기 힘든 점이 있기 때문이다. QA 부서는 어떨까? 여기서 먼저 생각해 볼 것이 있다. 그것은 QA 부서가 과연 무슨 일을 하는 부서인가? 하는 문제이다. 여러분의 회사에서 QA 부서는 과연 어떤 일을 하는가? 여러분은 QA 부서에 대해 얼마나 호감을 가지고 있는가? 펼쳐두기.. 회사마다 회사의 정책이나 전략에 따라 QA 부서의 역할은 매우 판이하다. 그리고 그 역할에 따라 회사 내에 QA 부서의 호감도도 매우 달라지는 편이다. 만약 여러분이 QA 부서에 대한 호감도가 낮다면 아래와 같은 문제가 있는 것은 아닌지 한번 고민해 보시고 댓글이나 트랙백등으로 의견을 주셨으면 하는 바람이다. 먼저 일반적으로 QA 부서가 하는 일은 제품의 품질을 측정하고 제품의 품질을 향상시킬 수 있는 모든 활동을 계획하고 제어하는 일을 한다. 그런데 문제는 소프트웨어의 품질이 문제가 된다. 먼저 공장과 같은 하드웨어를 제조하는 회사의 경우에는 품질 부서가 독립적으로 존재한다. 이 품질 부서에서 제품의 품질을 측정하고 제품의 품질을 개선하기 위해 집중하는 곳은 하드웨어 그 자체이다. 하드웨어는 각각의 부붐의 품질이 100인 제품이 모여서 하나의 제품을 구성하게 되었을 때 그 제품의 품질은 역시 100이다. 이것은 매우 명확한 사실이다. 소프트웨어를 만드는 회사의 조직과 관리 방법 역시 이러한 하드웨어를 만드는 회사의 조직과 관리 방법을