삼성증권 시스템 규제와 공매도 금지 청원
- 작성일
- 18-04-10 00:41
이미 20만은 넘었기는 한데 진짜 이건 그냥 넘어가면 안되는 사태인데
개인의 실수로 치부 중
아래는 개발자가 이번 사태 관련해서 썼다는 글이네요.
.
.
금융권 시스템 운영 및 개발 경험이 전체 경력의 50%가 넘는 현직 개발자입니다.
쉽게 설명드리자면. 제가 쇼핑몰을 하나 만들어서 운영한다 치자면. 가방을 파는데 현재 재고가 10개 있습니다.
연말에 저희 직원들이 너무 이뻐서 가방을 하나씩 선물로 배당을 주기로 하였습니다.
배당 입력 시스템에서 15개를 입력하니. 5개가 모자르기 때문에 선물 입력이 불가능하고 에러메시지와 함께 팅겨져나옵니다.
선물이 불가능합니다. 선물을 주려면. 저도 재고를 5개 확보하고. 시스템에 15개로 수량을 늘려야 합니다. 이것이 기본입니다.
보유수량(재고) >= 판매수량
..이게 아구가 맞아야만 거래가 가능한 것 이지요. 일반 개인이 쇼핑몰을 만들어도 당연히 저렇게 하며. 저런 검증이나 벨리데이션 절차가 없다하더라도. 외부 결제시스템이니 회계와 연동시에 그쪽에서 알아서 벨리데이션에 걸려서 팅겨져 나옵니다.
전체 프로세스는 롤백되고 당연히 입력되지 않습니다. 특히 "상품" 이나 "돈" 과 관련된 시스템은 그 검증 절차나 벨리데이션이 어마어마합니다. 화면에서 또 하고 서버에서 또 하고. 연계된 시스템에서 또 하고 그런 식입니다.
그리고 그것은 하나의 트랜잭션(실제반영)에 묶여서 일어나도록 구현되기 때문에 중간에 하나만 어긋나서 reject가 나게되면
전체가 롤백(취소)되는 구조입니다.
대한민국 어디서도 대기업이나 공기업과 관련된 "금융"과 관련된 시스템들은. 그렇게 만들지 않는 시스템은 없다고 보시면 됩니다. 그렇게 만들고 싶지 않아도. 그것이 강제됩니다.
삼성증권은 자사보유주가 단 1주도 없다 합니다. 아무리 직원이 실수를 해서. 심지어 삼성증권 사장님에게 주식1주를 배당하려고 잘못 입력했어도 당연히 화면에서부터 거부당합니다. 재고가 0 이니까요.
어찌어찌 화면에서 통과가 되었다고 해도 서버 검증에서 오류가 발생합니다. DB에서 자사보유주 수량이 0이기 때문에. 재고가 없기 때문에 판매든 뭐든 사용이 아예 불가능한 것 이지요.
진짜로 만에 하나.. 설사 또 어찌어찌 거기까지 통과되었다고 하더라도.
DB에서 보유수량 정산처리등이 들어가다가 sql 에러등이 날 가능성이 높습니다.
어떻게 내부 DB가 그렇게 업데이트되었다고 가정 하더라도.
그 내역이 외부시스템. 거래소나 타 accounting이나 내역관리 시스템에 입력되기 위해 연계가 들어가는 순간 거기 벨리데이션에서 걸립니다.
야 니네 보유수량이 0인데. 사장님한테 1주를 어떻게 주냐. 하고 말이죠.
근데 이 모든것이 전부 통과되었고 그냥 단순 직원이 오입력한 실수다? 라는 건 말도 안되는 기가차는 상황입니다.
차라리 직원이 실수로 엑셀에다가 100억원이라고 적었더니. 자기 국민은행 계좌에 100억원이 생겼다. 직원이 실수를 저질렀다.
거의 그런 정도라고 보시면 됩니다.
제가 지금 국민은행 인터넷 뱅킹에 접속해서 이체하려는데. 금액란에 "실수로 1조를 입력했더니 진짜로 1조가 이체되었다."
아 내가 실수했네. 이런 정도라고 보시면 됩니다.
삼성, 현대, LG, 3대 통신사. 그 외에 공기업 프로젝트를 해본 IT 개발자들은 전부 아실만한 내용일껍니다.
게다가 특히 금융권. 소위 말하는 은행의 여신 시스템이나. 증권사의 증권, 보험사의 상품증권, 대출등등 돈이 왔다갔다하는 시스템을 잠시라도 운영을 해보았거나 SI개발에 참여하신 분들은 다들 당연히 아시는 내용입니다.
그 사람들. 툭하면 금감원 감사니. 보안감사니. 모의해킹이니 엄청 시달립니다. 특히 저런 벨리데이션은 애초에 수많은 시나리오를 가지고 계속해서 테스트하고 검증을 합니다. 그래야만 그 시스템이 오픈되어서 실제 내부 사용자든 외부사용자든 사용이 가능한 것 이구요.
저런 요구조건이 맞지 않으면 당연히 오픈 불가입니다.
대기업들 공공기업들은 그 절차가 너무 까다롭고. 툭하면 금감원, 국정원등에서 감사하고 체크를 하기 때문에 저런 모든 검증절차가 생략된 채로. 단순 오입력이 통과되는 시스템을. 그것도 "돈", "증권" 시스템에서 존재할 가능성은 단언하건데 0% 입니다.
제가 테스터라면.
배당관리 시스템을 테스트할때 뭐부터 할까요? 아마 배당입력 란에. 천억넣어보고. 배당주식수에 천억주 넣어보겠죠. 그리고 실제 자기들이 보유한 재고보다 많은 수가 입력되었을때 잘 팅겨내는지 확인합니다. 그리고 애초에 보유수량이 있으면 얼마든지 배당이 나갈수 있다하더라도. "너무 큰수". "너무 많은 물량" 인 천억이니 천억주같은건 불가능하게 만듭니다.
MAX값 LIMITED 값을 소스에 아예 하드코딩으로 박아놓아서. 아무리 입력을 준다하더라도. 그 값보다 큰 수를 넘는 값은 소스를 수정하지 않는 이상 그것이 수행되지 않게 합니다.
쉽게 설명드리자면. 제가 쇼핑몰을 하나 만들어서 운영한다 치자면. 가방을 파는데 현재 재고가 10개 있습니다.
연말에 저희 직원들이 너무 이뻐서 가방을 하나씩 선물로 배당을 주기로 하였습니다.
배당 입력 시스템에서 15개를 입력하니. 5개가 모자르기 때문에 선물 입력이 불가능하고 에러메시지와 함께 팅겨져나옵니다.
선물이 불가능합니다. 선물을 주려면. 저도 재고를 5개 확보하고. 시스템에 15개로 수량을 늘려야 합니다. 이것이 기본입니다.
보유수량(재고) >= 판매수량
..이게 아구가 맞아야만 거래가 가능한 것 이지요. 일반 개인이 쇼핑몰을 만들어도 당연히 저렇게 하며. 저런 검증이나 벨리데이션 절차가 없다하더라도. 외부 결제시스템이니 회계와 연동시에 그쪽에서 알아서 벨리데이션에 걸려서 팅겨져 나옵니다.
전체 프로세스는 롤백되고 당연히 입력되지 않습니다. 특히 "상품" 이나 "돈" 과 관련된 시스템은 그 검증 절차나 벨리데이션이 어마어마합니다. 화면에서 또 하고 서버에서 또 하고. 연계된 시스템에서 또 하고 그런 식입니다.
그리고 그것은 하나의 트랜잭션(실제반영)에 묶여서 일어나도록 구현되기 때문에 중간에 하나만 어긋나서 reject가 나게되면
전체가 롤백(취소)되는 구조입니다.
대한민국 어디서도 대기업이나 공기업과 관련된 "금융"과 관련된 시스템들은. 그렇게 만들지 않는 시스템은 없다고 보시면 됩니다. 그렇게 만들고 싶지 않아도. 그것이 강제됩니다.
삼성증권은 자사보유주가 단 1주도 없다 합니다. 아무리 직원이 실수를 해서. 심지어 삼성증권 사장님에게 주식1주를 배당하려고 잘못 입력했어도 당연히 화면에서부터 거부당합니다. 재고가 0 이니까요.
어찌어찌 화면에서 통과가 되었다고 해도 서버 검증에서 오류가 발생합니다. DB에서 자사보유주 수량이 0이기 때문에. 재고가 없기 때문에 판매든 뭐든 사용이 아예 불가능한 것 이지요.
진짜로 만에 하나.. 설사 또 어찌어찌 거기까지 통과되었다고 하더라도.
DB에서 보유수량 정산처리등이 들어가다가 sql 에러등이 날 가능성이 높습니다.
어떻게 내부 DB가 그렇게 업데이트되었다고 가정 하더라도.
그 내역이 외부시스템. 거래소나 타 accounting이나 내역관리 시스템에 입력되기 위해 연계가 들어가는 순간 거기 벨리데이션에서 걸립니다.
야 니네 보유수량이 0인데. 사장님한테 1주를 어떻게 주냐. 하고 말이죠.
근데 이 모든것이 전부 통과되었고 그냥 단순 직원이 오입력한 실수다? 라는 건 말도 안되는 기가차는 상황입니다.
차라리 직원이 실수로 엑셀에다가 100억원이라고 적었더니. 자기 국민은행 계좌에 100억원이 생겼다. 직원이 실수를 저질렀다.
거의 그런 정도라고 보시면 됩니다.
제가 지금 국민은행 인터넷 뱅킹에 접속해서 이체하려는데. 금액란에 "실수로 1조를 입력했더니 진짜로 1조가 이체되었다."
아 내가 실수했네. 이런 정도라고 보시면 됩니다.
삼성, 현대, LG, 3대 통신사. 그 외에 공기업 프로젝트를 해본 IT 개발자들은 전부 아실만한 내용일껍니다.
게다가 특히 금융권. 소위 말하는 은행의 여신 시스템이나. 증권사의 증권, 보험사의 상품증권, 대출등등 돈이 왔다갔다하는 시스템을 잠시라도 운영을 해보았거나 SI개발에 참여하신 분들은 다들 당연히 아시는 내용입니다.
그 사람들. 툭하면 금감원 감사니. 보안감사니. 모의해킹이니 엄청 시달립니다. 특히 저런 벨리데이션은 애초에 수많은 시나리오를 가지고 계속해서 테스트하고 검증을 합니다. 그래야만 그 시스템이 오픈되어서 실제 내부 사용자든 외부사용자든 사용이 가능한 것 이구요.
저런 요구조건이 맞지 않으면 당연히 오픈 불가입니다.
대기업들 공공기업들은 그 절차가 너무 까다롭고. 툭하면 금감원, 국정원등에서 감사하고 체크를 하기 때문에 저런 모든 검증절차가 생략된 채로. 단순 오입력이 통과되는 시스템을. 그것도 "돈", "증권" 시스템에서 존재할 가능성은 단언하건데 0% 입니다.
제가 테스터라면.
배당관리 시스템을 테스트할때 뭐부터 할까요? 아마 배당입력 란에. 천억넣어보고. 배당주식수에 천억주 넣어보겠죠. 그리고 실제 자기들이 보유한 재고보다 많은 수가 입력되었을때 잘 팅겨내는지 확인합니다. 그리고 애초에 보유수량이 있으면 얼마든지 배당이 나갈수 있다하더라도. "너무 큰수". "너무 많은 물량" 인 천억이니 천억주같은건 불가능하게 만듭니다.
MAX값 LIMITED 값을 소스에 아예 하드코딩으로 박아놓아서. 아무리 입력을 준다하더라도. 그 값보다 큰 수를 넘는 값은 소스를 수정하지 않는 이상 그것이 수행되지 않게 합니다.
- 게시물이 없습니다.
- 게시물이 없습니다.
- 게시물이 없습니다.