SW 결함을 가장 무서워하는 분야(feat. 정부24)

많이 사용하고 있는 전자상거래, 사실은 상당히 많은 검증을 요구한다.

여러분 아르바이트 해본 적 있으신가요?

저희 아르바이트할 때 챙겨야 할 서류 있던 거 기억하시죠?

바로 주민등록등본인데요. 대부분 인터넷이든 오프라인이든 한 번쯤 발급받아보신 적 있으실 거예요 :)

저도 물론 인터넷 발급을 진행해 본 적은 많지만

저는 살면서 딱 한번 소송에 휘말린 적이 있었는데 민원서류 발급이 늦어져서 정말 애타게 기다린 적이 있었습니다....

그래도 어떻게든 잘 준비해서 대처하긴 했는데요,

공공 앱 <정부 24>의 장애 발생을 기억하시나요?

23년도 말 겨울에 일어난 사건인데요. 행정안전부 전산망 오류로 인해 센터에서 민원 처리가 중지됐었습니다.

문제는 장비 교체 이후로도 해당 시스템 서비스 전산망 먹통은 물론이고 정부 24 앱도 서비스가 중지되어서 안 그래도 많이 밀린 민원 업무처리가 골칫거리가 되었었죠.

해당 연도에 나이스(NEIS)도 장애가 발생했던 걸로 기억하는데.... 공공기관 시스템은 잠깐이라도 문제가 발생하면 상당히 큰 파장이 일어나게 되는데요, 해당 사건으로 인해 다른 공공기관 플랫폼 관계자분들도 느낀 바가 정말 많을 거 같네요. 특히 각 센터에서 민원 발생 지연으로 인한 뒷수습을 진행하시는 분들도 식은땀을 흘릴 수밖에 없겠죠....?

비슷한 사례로 22년도 가을에 발생한 <행복이음>이라는 시스템 오작동 사태도 생각나네요.

사회복지전담공무원 분들이 업무용으로 사용한 시스템이라고 합니다. 등록 전산 장애와 시스템 전산 오류가 반복되었는데 이 경우는 빼도 박도 못할 완벽한 시스템 결함으로 인한 오작동 사태네요....

공무 수행이나 국가 서비스 제공에 관련된 분들은 적임자 분이 자주 교체되기도 하고 문제 발생 시 사회적 파장이 클 것을 우려하여 결함에 민감하게 반응하며 요구사항 정리를 살짝 복잡하게(이상하게) 하시는 경우가 많아요.....

그런데 이분들이 꼭 그렇다고 해서 업무 참여도가 높지도 않.... 판사님 저는 아무 말도 하지 않았습니다.

그렇다면 금융계는 어떨까요? 민감도와 시스템 복잡도는 두 분야 다 만만치 않게 높지만, 개인적으로 요구사항 제시에 조금 더 적극적으로 기여하시는 등 참여도는 차이가 있다고 생각하긴 합니다. ( ⚆ _ ⚆ )

제 개인적인 생각입니다 돌을 던지지 말아 주세요 (^^;)>

그 와중에 조금 궁금한 게 있는데요,

여러분들은 주로 어떤 거래 수단을 사용하시나요?

저는 삼성페이를 자주 애용하지만 실물 카드를 사용하시는 분들도 많고 카카오페이, 토스페이 등을 사용하시는 분들도 많죠.

월 구독제 상품(넷플릭스, 유튜브 프리미엄, 쿠팡와우 등)도 많기 때문에 앱에서 자체적으로 간편 결제를 등록해 놓으신 분들도 수도 없이 많구요.

확실한 건 현금을 쓰는 사람들은 진짜 많이 줄어든 것 같더라구요.

청년적금, 교통비 할인 카드 등 알뜰한 상품이 많이 출시되는 가운데,

실용금융이나 재테크에 관심 있으신 분들이 부쩍 늘어나고 있는 것 같아요. 건실하게 돈 차곡차곡 모으시는 분들 존경합니다.

뭐 여러 가지 요인들이 많겠지만 중요한 건 전자상거래가 정말 정말 많이 이루어지고 있다는 겁니다.

제 글을 계속 읽어보셨던 분들은 제가 무슨 말을 꺼낼지 짐작이 가시죠? ㅎㅎ

은행은 정책이나 사회 이슈에 예민한 만큼, 자신들이 관리하는 업무에 큰 변경점이나 차질이 생길 수도 있는 요소에 엄청나게 민감합니다.

그래서 당연하게도 온라인뱅킹, 전자상거래 시스템에 굉장히 굉장히 예민합니다....

위에서 소개해드린 사례처럼, 시스템 결함으로 인해 그동안 쌓아온 사용자들의 신뢰도와 명성이 무색하게도 한순간에 무너져 내리더라고요.

시스템 결함을 악용하는 사용자는 물론이고 대규모 사용자를 가진 시스템일수록 한 가지 결함을 공론화하고 이슈화하고 싶은 세력이 정말 많을 텐데... 이 문제들을 감당하기가 정말 힘들어지기 때문에 예방을 정말 중요하게 생각하는 경우가 많죠..!

단순한 시스템 UI 오류만 해도 사용자들의 불안감을 조성할 명분이 있고, 입금, 출금처리 오류는 말할 것도 없네요. 입금되지 않았지만 입금처리가 진행되었다던가, 출금되지 않았는데 결제가 진행되었다던가오히려좋아, 이체가 사전 공지 없이 지연된다거나... 생각만 해도 아찔합니다.

따라서 정말 신중하게 업무 처리를 진행합니다. 결제 승인 오류 시 롤백처리를 매우 정밀하게 진행하기도 하고, 테스트 커버리지의 비율을 최대한 끌어올려서 분기를 최대한 많이 설계하고 진행하죠.

위키백과 또 시작이네

엥 이게 무슨 말이냐구요?

어떤 프로그램이 만들어졌을 때, 한 범위에서 테스트를 통해 실행된 구문이 전체 몇% 인지 나타낸 식이라고 보시면 됩니다.

예를 들자면, 커버리지가 40%라면, 한 케이스에서 실행되는 모든 경우의 수가 100개고 이들 중 40개 이상의 경우를 수행해야만 커버리지 40%를 달성한다고 볼 수 있는 것이죠.

40% 라고 그리 많아 보이지 않을 수도 있겠지만, 의외로 전문가들이 시도 때도 없이 야근을 진행해야 기간 내에 달성할 수 있는 수치인데요, 구문, 결정, 조건 커버리지 등등 범위를 다르게 정의하는 커버리지를 다 소화해야 하며 다중/변형, 조건/변형, 조건/결정(.......) 이런 식으로 또 2차적 분기 계산이 들어갑니다.....

흥미로운 사실이 하나 있는데요, 테스트 케이스에 대한 최대 테스트 커버리지가 100%여도 테스트 분기를 전부 다 진행하는 일은 절대 일어날 수 없습니다. 

프로그램 내에 내부 조건이 너무 많기도 하고 마음먹고 입력할 수 있는 값은 한정적인데, 사실 입력할 수 있는 데이터 자체는 너무나도  많기 때문이죠.

왜 완벽한 소프트웨어란 존재하지 않는 것일까? 테스트 엔지니어는 아무리 업무를 열심히 해도 이런 한계에 도달할 수밖에 없죠. 잠재적으로 존재하는 결함을 최대한 많이 찾아내어 줄이고 싶지만, 결함 발생 트리거는 측정 불가 수준으로 많고, 파고들기 전에는 결함이 없다고 증명할 수 없기에 테스트 커버리지 100% 달성은 논리적으로 존재할 수 없습니다.

커버리지가 높아질수록 발견되는 이슈는 무지하게 많을 테고, 또 개발자들은 수정작업이 들어가야 하는데 업무가 참 예사롭지 않죠? 적은 인력으로 전부 담당하기엔 한계가 명확합니다. 역시 완벽한 소프트웨어란 없네요...

그래서 엔지니어 분들이 테스트 커버리지를 소화하실 때 정적 테스트도 많이 진행하십니다.

정적 테스트란 앱을 실행해보지 않은 상태로 작성된 코드를 훑어보거나, 코드를 참고하여 나올 수 있는 결함을 탐지, 추적해 보는 정도의 업무라고 생각해 주면 될 것 같습니다.

코드를 훑어본다? 자격증 공부하신 분들은 많이 보셨을 겁니다. 이는 화이트박스 테스팅 기법으로 코드를 직접 오픈하여 테스트를 진행한다는 것이 이 기법의 핵심 개념입니다.

이 정적 테스트가 커버리지랑 무슨 관련이 있냐면요, 분기, 실행률 이런 거 다 제쳐두고 일단 커버리지를 만족하기 위한 작업과 관련이 있습니다.

분기, 실행률, 이전 글에 선보인 디버깅 같은 것은 동적 테스팅으로 볼 수 있구요.

화이트박스 테스팅 관련해서 업무 진행을 효율적으로 이끌어주는 국내 툴이 있는데요, 곧 해당 개념과 함께 더 자세히 설명하겠습니다.

위처럼 전자상거래이나 금융계에서 진행하는 시스템 테스트 커버리지는 이 정도는 기본으로 수행해야 합니다. 뭐, 그만큼 전문가들이 힘을 쓰시기에 사용자들은 편하고 더욱 안전하게 거래를 진행할 수 있는 것이죠 :)

이쪽 업계는 서버도 말썽이라는 건 안 비밀