콩고의 흑인 여성은 COVID-19 항원 검사 후 울어 버렸다. COVID-19 바이러스를 비롯하여 인간의 질병을 진단하는 진단 키트를 만들고 있다. 그중에 질병을 판단하는 의료 진단 기기의 소프트웨어를 개발하고 있다. 인간의 질병을 혈액이나 검체를 통해서 항원과 항체의 면역 반응을 통해서 검사자에게 특정한 질병이 있는지를 판단해 준다.
COVID-19 항원, 항체, 중화 항체를 비롯한 다른 아이템들도 전 세계로 수출을 하고 있다. 전 세계의 사용자가 많이 사용하고 있다. 인간의 질병을 진단하기에 소프트웨어에 버그가 없어야 한다. 개발자가 버그를 만드는 것은 죄를 짓는 것과 같다. 특히, 인간의 질병을 판단해주기에 소프트웨어는 버그를 만들면 안 된다. 버그를 만드는 것은 죄를 짓는 것과 같다. 버그를 만들었다고 해서 꼭 감옥에 가는 것은 아니지만, 오동작하는 소프트웨어는 사용자에게 엄청난 피해를 준다. 개발자는 버그를 만들지 말아야 한다. 버그(bug)는 소프트웨어가 예상하지 못한 잘못된 결과를 내거나, 오류를 발생하거나, 오작동이 발생하는 등의 문제를 말한다.
COVID-19 항원 진단 키트의 경우 검사자의 코에서 검체를 채취한 후에 카트리지에 적하한다. 12분 동안 면역 반응이 된 카트리지를 의료진단 기기로 읽어서 COVID-19 바이러스 감염 여부를 판단한다. 12분 후면 COVID-19 양성인지, 음성인지 판별을 해준다. COVID-19 판데믹이 선언이 된 이후에 우리 제품은 아프리카의 콩고에도 판매했다. 코딩하는 일들이 일상적인 것으로 여기며 소프트웨어를 배포했다. 그런데 아프리카 콩고에서 우리들이 만든 의료 진단 기기로 검사하는 동영상을 받아본 후 소프트웨어 개발자로서의 중요한 사명감을 느끼게 되었다.
콩고에서 보내온 WhatsApp 영상을 보았다. 젊은 흑인 여성이 우리 진단 키트로 COVID-19 Ag(항원) 검사를 받는다. 코에서 검체를 채취한다. 검체를 채취한 후 우리의 카트리지에 검체를 적하한 후에 12분을 기다린다. 이 기다림이 얼마나 긴장이 되고 긴 시간인지 모두 잘 알 것이다. PCR 검사나 신속 진단키트로COVID-19 검사를 한 번이라도 받아본 사람이라면 긴장된 기다림의 시간을 더욱 잘 알 것이다. 그 흑인 여성은 12분간 우리의 기기를 쳐다보며 간절히 결과를 기다리고 있었다. 긴장된 모습이 역력했다. 그 간절한 모습은 아직도 기억에 선명하다. 12분 후에 기기에서 COVID-19 Ag 음성(Negative)이라는 결과를 보고 그 흑인 여성은 환호했고 눈물을 흘렸다. 정말로 기뻐하는 모습이었다. 그 모습을 보면서 머리에 띵한 충격을 받았다. 소프트웨어를 개발하고 검증하면서 수도 없이 보았던 양성(Positive) , 음성(Negative)의 8개의 Text가 한 사람에게 저렇게 큰 영향을 주는 것에 충격을 받았다.
만약에 우리들이 만든 기기에서 소프트웨어적인 오류가 있어서 결과 판단에 영향을 주었다면 다른 사람의 인생에도 나쁜 영향을 주었을 것이다. 이런 모습들을 볼 때 버그를 만드는 것은 사용자에게 죄를 짓는 것이다. 개발자는 소스 코드 한 줄을 코딩할 때도 사명감으로 일해야 한다. 소프트웨어 버그 하나가 다른 사람의 인생을 좌지우지할 수도 있다. 아니면 버그로 인해서 사용자들에게 불편함을 줄 수가 있다. 앱에서 카드 등록 시에 카드 번호와 유효기간을 다 넣었다. 여기까지 긴 과정을 거치며 간신히 진행해왔다. 그런데 OK 버튼을 누르는 순간에 앱이 재시작되어서 처음부터 작업을 다시 시작해야 했다. 이런 사소한 버그를 만들면 사용자는 심한 불쾌감을 가지며 스트레스를 받을 것이다. 이러한 사소한 버그부터 심각한 버그까지 소프트웨어 엔지니어는 버그를 만들면 안 된다는 사명감으로 일해야 한다.
콩고의 흑인 남성은 우리들이 만든 기기를 손에 들고 얼굴에는 웃음을 흠뻑 머금은 채 가는 것을 보았다. 흑인 남성은 기대감으로 부풀어 있었다. 이것이면 코로나를 이길 수 있다는 희망을 품고 가는 것처럼 보였다. 개발자는 이 지구의 한 사람을 위해서라도 품질 좋은 소프트웨어를 만들어야 한다. 개발자가 일상적인 코딩으로 만든 소프트웨어가 지구 반대편에서는 아주 소중하고 가치 있는 물건으로 평가를 받고 있다는 것을 잊지 말아야 한다.
소프트웨어가 다른 사람의 인생에 악영향을 주고 불편함을 주었다면 죄를 짓는 것이다. 소프트웨어 엔지니어는 품질에 신경을 쓰면서 사명감으로 코딩을 해야 한다. 개발자가 만든 코드 한 줄이 다른 사람의 인생을 바꿔 놓을 수가 있다. 아프리카 콩고의 여성이 울었을 때 감격했고 전율을 느꼈다. 개발자는 사명감으로 일해야 한다.
버그를 최소화하려면 프로그램이 설계와 구현이 잘되어 있어야 하지만, 지금은 검증하는 방법만을 이야기하고자 한다. 좋은 개발자는 자신이 작성한 코드에 대해서 반드시 직접 검증을 해야 한다. 서버에 올리기 전이나 검증 부서에 배포 전에 반드시 검증해서 동작에 이상이 없고 다른 부분에 영향을 주지 않는지 확인을 해야 한다. 개발자가 수정한 부분이나 추가한 기능의 소스를 보면서 그 기능이 정상적으로 동작하는 것을 확인하는 것은 물론 다른 동작에 영향을 주지 않는 것도 확인해봐야 한다.
어느 개발자는 코딩한 것이 자기 업무의 끝인 것처럼 던지듯이 바로 QA(검증 부서)에게 버전을 배포한다. 검증자는 수정 내용을 보고받지만, 내부 구조를 모르기에 관련 부분을 검증하는데 애로 사항이 많다. 그리고 검증을 못 하고 놓치는 경우도 많다. 그래서 개발자가 반드시 수정이나 추가한 기능에 대해서 직접 검사를 하면 버그를 줄일 수가 있다. 물론, 개발자가 무척 바쁜 것은 안다. 코딩하기에도 바쁜데 언제 검증까지 하는가 하고 이야기할 수 있다. 하지만 좋은 개발자가 되려면 본인이 코딩한 소스의 기능들은 반드시 먼저 검증을 해봐야 한다. 지루하고 시간 낭비인 것처럼 보이지만 버그를 줄일 수 있는 가장 단순하고 좋은 방법이다.
본인이 작성한 코드는 끝까지 책임지고 간다는 마음가짐이 필요하다. 필드에서 버그가 나왔을 때 QA가 왜 버그를 잡지 못했냐고 할 수도 있다. 하지만 먼저 개발자가 책임이 더 크다. QA는 고객에게 심각한 피해를 주는 코드를 막는 최종 방어선으로 보아야 한다. 검증자가 자신의 버그를 찾아줄 것으로 기대하지 말고 개발자가 코드의 정상 작동 여부를 검증해야 한다. 개발자는 자신이 작성한 코드를 적용한 버전을 검증자에게 넘겨주기 전에 반드시 먼저 테스트할 책임이 있다. 개발자가 금방 찾을 버그를 검증자가 찾는 데 오래 걸리는 시간 낭비는 하지 말아야 한다.
개발자가 버그를 만드는 것은 죄를 짓는 것과 같다.
