devpia logo

컬럼게시판

여전법 시행에 따른 프로그래밍

jiocafe / 2015-11-24 오후 11:44:03 / 조회수(21754)

2015년 7월 21일로 여전법이 발효되었습니다.
그게 뭐냐면요. 음... 꾸린겁니다.
요즘 여전법 때문에 일거리가 겁나 많아서 힘든 나날을 보내고 있습니다. 아마도 이 칼럼을 보지도 못하는 많은 사람들이 여전법 관련 개발을 진행하고 있을 것입니다.
시행전엔 신용카드 마그네틱 트랙의 37바이트를 보관하였다가 신용카드 승인을 따는 개발은 매우 간단하였습니다. 사실상 소스코드가 얼마 되지 않았죠.
 
시행후에는요. 한숨 부터 나옵니다. 일단 리더기에서 읽어지는 데이타 자체가 이미 암호화되어 있어서 카드의 번호가 뭔지를 아예 모릅니다. 업무를 위해서 사용할 수 있는 번호를 사용할 수 있다는 모호한 표현으로 인해 개발을 이러지도 저러지도 애매한 상황입니다.
 
기존에는 신용카드 리더기를 통해 37바이트를 쓰윽 읽어드리면, 그것을 STX 부터 ETX까지 씌워서 LRC라든가 CRC를 만들어서 검증코드를 붙여서 VAN사 서버에게 쏘기만 하면 되었습니다.
이젠 리더기에게 신용승인을 딸 금액을 보내고, 리더기가 어떤(?) 암호화된 덩어리를 던지면 그걸 받아서 VAN사에게 보내고 VAN사는 암호를 풀고 암호화가 정상일때에만 각 카드사로 전송하여 승인을 받고, 받은 결과를 다시 암호화해서 내려주는 것이죠.
이 과정에서 카드번호가 무엇인지는 아무도 알수가 없는 것입니다. 
암호화가 잘 되어 있다면 그것을 인터넷을 통해 보내도 안전하다고 할 수 있을 것인데요. 인증을 해주는 회사에서는 어이없게도 이 암호화된 결과값 마져 송수신하는 모든 통로가 폐쇄 회로 내에 있어야 한다는 것입니다.
논리적으로 이미 암호화된 결과물을 또 다시 물리적으로나 논리적 방화벽으로 보호하도록 한다는 것이죠.
뿐만 아니라 그 프로그램들의 코드가 변경될 때마다 이 프로그램은 보안을 훼손하는 행위를 절대로 하지 않는다는 것을 검사받아야 하고 그 때마다 돈을 내야 하는 것이죠. 인증 비용으로요.
맨날 수정하는 것이 개발자들의 일인데, 수정을 할때마다 인증을 받아야 하고 그것에 대해 비용을 지불해야하는 문제가 생긴 것입니다. 아주 꾸리죠.
 
아무도 풀지 못하는 암호화를 했는데, 왜 그것을 또 쉴드를 쳐야 한다는 논리를 피는 것인지 납득이 안되는 대목이며, 그 비용을 전부 포스 개발회사에게 주유기 개발회사에게 부담시키고 수정할 때마다 허락을 받아야 하고 코드가 뭐가 어찌 돌아가는 것인지 까지 밝혀야 한다는 것입니다.
 
신용카드 관련해서 업무를 하시는 분들이 아주 많을 것입니다. 
 
일반적으로 사용하는 식당포스 같은 경우 단말기에서 금액을 입력하고 카드를 긁어서 결과만 포스에게 전달하는 방법을 사용하여 인증 대상에서 벗어나 버렸다고 합니다. 단말기는 어차피 인증받아야 하는 대상인거고요.
그런데 셀프주유기는 이야기가 많이 다르죠. 읽기는 주유기에서 읽고, 전송은 포스가 담당하고, 승인 과정은 밴사에서 담당하는 구조인 것이죠. 그러니 3개의 회사가 하나의 인증 대상이 되는 것입니다.
2015년 11월 24일 현재 인증 받은 회사는 동화계량기의 주유기 + 우주의 포스 + 금융결제원 밴사가 조합된 한개의 시스템이 유일합니다.  7월부터 지금까지 인증받은 회사는 유일하기에 그 사이에 사업을 시작한다거나 사업을 포기하고 판매하려는 분들은 전부 새로운 시스템으로 교환하여야 한다는 법에 걸려서 아무것도 못하는 실정입니다.
 
자.. 그래서 개발은 해야 하고 한번 개발한 후에 인증을 받으면 이제는 1바이트 조차 수정을 할 수 가 없는 것이지요. 수정을 할때마다 인증을 받아야 하고 인증받는 과정에 돈이 들어가고 시간이 들어가니 참 귀찬은 상황이 되어 버렸습니다.
오너 입장에서도 1회 인증을 받을 때마다 1800만원이나 한다는 그 인증 비용을 매번 내면서 인증을 받기엔 부담이 아닐 수 없죠. 그러므로 1회 인증을 받을 때마다 많은 개발을 한꺼번에 실시하고 많은 테스트를 실시하여 견고한 제품을 만든 후에 인증받아야 하는 상황에 놓인 것입니다.
 
개발자는 인증 받은 후에는 프로그램을 수정할 수 없는 상황에 놓이므로, 이제는 견고한 제품을 만드는데에 고도의 기술이 필요하게 되었습니다. 매우 꼼꼼한 성격의 개발자가 필요하게 되는 것입니다. 즉, 소프트웨어도 한번 출시하면 더이상 수정이 불가능하다는 점입니다.
 
그럼 견고한 프로그래밍은 어떻게 하는 것일까 생각을 해봐야 할 것입니다.
에러가 나지 않는 프로그래밍이 되겠죠. 퍼포먼스 보다는 안정성에 더 집착해야 하는 것이죠. 한줄 한줄마다 에러가 발생할 요소를 없애고, 함수 하나 하나 파라미터로 들어온 변수들의 값이 잘못된 경우에 오동작 하지 않도록 예외 처리를 아주 잘 매우 특별히 잘 작업해야 한다는 점입니다.
예외처리라 하는 것은 여러가지 방법이 있습니다. 에러 내용을 보여주고 그냥 조치를 기다리게 만들어버리는 유치한 방법은 제일 쉽지만 그 에러를 절대로 수정할 수 없는 것이기에 어떻게든 동작하는 방법으로 수정해야 할 것입니다.
atoi함수를 만들어서 문자열을 숫자로 바꾸고자 할때도 "a9"가 파라미터로 넘어왔다면 숫자가 아니므로 그냥 0으로만 넘겨야 한다는 것이죠. 에러를 발생하고 문자를 넘겼다고 하는 것이 아니죠. 어차피 수정할 수 없으므로
또한 모든 배열에 있어서 배열의 크기를 넘어서는 일이 없도록 모두 방벽을 쌓아야 합니다.
strcpy같은 함수를 사용하여 문자열 카피를 하는 경우라도 절대로 수신버퍼를 넘어서지 않도록 다른 함수를 써야 한다는 것입니다. strncpy를 쓰면 될것 같지만 .... 그건 아니죠. 널 문자가 마지막에 넣어지지 않아서 다른 메모리 침범을 일으킵니다.
 
double 형 숫자 변수를 사용하는 것이 안전할까?
포스 시스템을 수년간 개발해 오면서 float와 double형 변수 자체가 갖는 에러 때문에 저는 항상 int변수로 대신합니다. 큰자리수가 필요하면 int64를 쓰지요. 예를 들어 소숫점 3자리를 포함하는 필드라면 int로 1000을 곱해서 넣어두는 것이지요. 그럼 덧셈이나 뺄셈을 0.001을 반복하더라도 오류가 생기지 않습니다.  float연산 오류는 중급 프로그래머 이상이면 다들 잘 아실 것입니다.
내부적으로 1000을 곱한 수치를 보관하고 덧셈하고 처리하다가, 표시할 상황에서만 1000으로 나누어서 처리하면 연산 오류가 없습니다. 
 
보안에 필요한 범위를 최소화하여야 하므로, 관련 모듈을 한곳에 모으고, 별도의 프로그램과 통신을 하는 방법이 좋습니다. 인증받은 exe파일은 바이너리로 변경 유무를 확인해야 하므로 절대로 수정되어서는 안되죠. 그러니 자주 수정되는 UI관련 폼이라던지, 레포트라던지 그런것들은 인증 범위 밖에 두어야 할 것입니다.
 
UI는 사람의 마음에 따라 그 시대의 흐름에 따라 유행을 따라가듯 매번 바뀌는 것이 UI인데, 그럴때마다 돈을 내고 인증을 받아서는 안되지요.
 
리더기를 직접 제어하지 말아야 합니다. 리더기를 제어하는 프로그램이라면 인증 범위에서 벗어날 수가 없습니다. 읽는 과정과 읽은 데이타가 어디로 가는지 모든 것을 소명해야 할 것이고, 코드가 수정될 때마다 인증을 다시 받아야 하는 문제점에 이르게 됩니다. 
 
밴사의 경우도 단말기를 다양하게 보유하고 유지하던 것을 그 수를 줄이고 몇개만 가져가야 매번 인증을 받는 비용을 줄일 수가 있습니다. 그래서 단말기 종류 품목의 다양성이 확실히 줄어들 것이며, 가격은 올라갈 것입니다.
 
주유소와 밴사간의 리베이트 관계도 연매출 10억 기준으로 증여할 수 없도록 법이 시행됨에 따라 주유소도 단말기를 매번 새로 사야 한다는 것입니다. 
따라서 단말기를 무상으로 교환해줄 것이라는 기대를 가지고 개발하면 안될 것입니다. 단말기의 수명이 자주 줄어들게 되는 시스템은 개발해서는 안되겠죠. 예를 들어 단말기를 프린터 삼아서 자주 인쇄하도록 개발했다면 이제는 소형 영수증 프린터를 사용하도록 하는 것이 단가가 싸게 먹힐 수 있습니다. 
 
신용카드의 카드번호 몇 자리를 기억해 두었다가 어느 고객인지 확인하는 프로그램을 사용하고 있었다면 이젠 그런 기능은 해서는 안됩니다. 카드번호를 보관한다는 것 자체가 불법입니다. 또한 카드번호가 읽혀지지도 않을 것입니다.
 
신용카드 이외에 일반적인 마그네틱 카드를 이용해서 회원카드라든지 고객 카드를 만들었다면, 그 마그네틱 트랙에는 반드시 숫자가 아닌 문자를 포함하여야 합니다. 왜냐면 숫자만 있는 마그네틱 카드는 신용카드일 수 있으므로 리더기가 그것을 읽어서 암호화해 버리고 절대로 숫자를 알려주지 않습니다. 
기존에 1234 5678 9012 3456 이렇게 숫자형태의 카드를 만들었던 것을
이퀄을 넣어서 ==34 5678 9012 3456 이렇게 숫자형태의 카드를 만들었던 것을 이런 식으로 신용카드가 아니라는 것을 리더기가 인식할 수 있게 해야 합니다. 
 
한동안 여전법 때문에 IT인들이 일거리가 많아서 먹고살기 좋겠습니다.
화이팅 하십시오!

배너

댓글보기

psm1782 / 2015-11-25 10:15

그래봤자 관련 솔루션을 만드는 쪽만 일 많아지는거죠 뭐 ㅋㅋ

rjm9814 / 2015-11-25 17:41

화이팅요...ㅋㅋ

freerose / 2015-11-25 17:44

여전법이 뭔가해서 찾아봤네요... 별루 관련 없는 쪽에서 일하는지라... =.=;

djinni4u / 2015-11-27 15:34

보안이 필요한 건 맞는데... 그걸 인증이라는 이름으로 통일할 필요가 있을까요 음... 왠지 공인인증서 삘이 나늗데요

NeoMinky / 2016-03-03 16:53

당연한 조치라고 생각하는데요. 그냥 디버깅 하기 귀찮다 라고 하소연 하는 글로밖에 안보임.