대한민국 개발자로 산다는 것
사업의 가장 확실한 기반은 품질이다. 그다음, 그것도 한참이나 다음이 비용이다.
- 앤드루 카네기
품질은 생명이다.
대부분의 기업은 품질이 중요하다는 것을 알고 있으며, 제아무리 강조해도 지나치지 않다는 것을 알고 있다. 이러한 품질을 최우선으로 대하는 경영철학은 시대를 초월해 현재에 이르기까지 여전히 유효한 전략이다. 하지만 현실에서는 흔히 지켜져야 할 품질 원칙들을 실천하지 못한다. 프로젝트 관계자들은 품질에 대한 확신이 없으며, 품질보다 중요하다고 여겨지는 가치에 밀려 절충안을 찾기 바쁘다. 결국 어느 정도의 결함을 허용하는 선에서 적정한 품질 수준을 책정한다.
품질은 있어도 그만 없어도 그만인 요소인가? 내가 몸담고 있는 소프트웨어 분야에서 품질 요소는 일정과 예산을 위한 희생양이 되는 경우가 많다. 일단 납기는 맞춰놓고 보자는 식이다. 그 만큼 납기에 대한 강박관념에 시달리고 있다. 고객과의 약속은 항상 최우선 과제이며 관리자들은 일정과 비용을 맞추기 위해 품질을 희생하는 것이 불가피하다고 여긴다. 왜 그들은 품질과 일정을 별개의 문제로 생각하는 것일까? 왜 품질 향상에 신경 쓰는 것이 일정에 쫓기고 생산성을 떨어뜨린다고 보는 것일까?
실제로 그들은 품질은 여유 있는 자들의 행복한 비명이라고 푸념한다. 하지만 내가 경험한 일부 프로젝트 중에는 프로젝트 후반부에 너무 많은 결함이 발생해 테스트 인력을 대거 투입하고도 품질을 이유로 고객이 인수를 거부한 사례도 있다. 또한 우여곡절 끝에 시스템을 오픈했다고 해도 운영 이관을 마치자마자 문제가 터져 나온다. 이런 경우 유지보수 비용은 기하급수적으로 증가하고, 많은 인력이 다른 일을 제쳐 두고 하자보수에 매달려야 한다. 결국 품질은 프로젝트의 성공이라 여기는 납기와 비용과 무관하지 않으며, 오히려 직접적인 상관관계를 보인다.
그러므로 프로젝트 초기부터 적극적으로 품질을 관리하고 결함을 잡는 데 주력해야 한다. 개발자는 단순히 개발로만 끝낼 것이 아니라 단위 테스트와 통합 테스트를 병행해야 한다. 요구사항을 정의하는 단계부터 적극적으로 테스트 계획을 세우고 개발 생명주기 동안 지속해서 수행한다는 생각으로 접근해보자.
일단 코드를 작성하고 나중에 고친다는 생각은 또 다른 문제를 더할 뿐이다. 테스트가 결국 오류를 잡고 코드의 품질을 높여준다. 오류가 또 다른 오류를 양산하는 악순환의 고리를 끊고, 다음 개발 작업이 원활히 진행될 수 있도록 도움을 준다. 결국 우리가 간과하지 말아야 할 사실은 지금 당장 눈앞에 보이는 결과에만 치우쳐 정작 중요한 것을 등한시하지 말자는 것이다. 결국 호미로 막을 것을 가래로 막는 실수를 저지르지 말자는 것이다. 별거 아니라는 생각이 나중에 가서는 큰 문제가 되어 돌아온다는 것을 우린 이미 알고 있다.
우리의 삶 속에도 소프트웨어에서 보는 품질과 다르지 않은 것들이 있다.
당장 눈에 보이는 이득이 손에 잡히지 않는다는 이유로 등한시되는 것들이 있다. 여기서 재미난 사실은 고객이 품질은 당연히 따라오는 것쯤으로 여겨 대가를 치르려 하지 않듯이, 우리 주변의 소중한 것들은 공짜가 많다는 사실이다. 공짜로 물건을 받아본 사람은 알 것이다.
내가 가치를 지불하지 않고 받은 것은 왠지 모르게 그 물건의 실제 값어치와 무관하게 하찮게 여겨진다. 조금은 함부로 대하게 되고, 나에게는 중요하지 않은 것쯤으로 여겨지기도 한다. 그런 착각들은 우리의 무의식 속에 감춰져 있다. 아침을 깨우는 신선한 공기, 마음을 녹여주는 따사로운 햇빛, 평온을 주는 자연, 마음을 열어주는 들꽃, 기운을 북돋아 주는 깊은 산, 확 트인 바다, 바쁜 일상 속의 여유, 내 안에 잠들어 있는 나의 꿈, 한 발짝 뒤로 물러난 행복, 늘 곁에 있어주는 사랑하는 사람... 이것들은 눈앞에 놓인 가치를 좇는 데 급급해 소외되고, 공짜로 여기는 것들이다.
그럼 우리가 정작 살아가면서 좇고 있는 가치는 무엇일까? 당장 해야 하는 산적한 업무, 풍요로운 생활을 영위하는 데 필요한 돈, 나를 돋보이게 하는 지위, 지나치면 소외될 것 같은 술자리들이다. 아이러니하게도 이것들은 대부분 달성하기 위해 많은 노력과 물질적인 가치를 지불해야 한다는 점에서 공짜가 아니다.
인간은 누구나 행복을 원한다. 그러나 누구나 행복한 것은 아니다. 자신에게 한번 질문을 던져보자.
내가 현재 좇고 있는 가치로 인해 나는 점점 더 행복해지고 있는가?
돈을 많이 벌면서 인생이 풍요로워졌는가?
현재의 지위가 주는 명예에 만족하는가?
지금 가치 있는 일이라고 여기는 일들에 시간과 노력을 쓰면서 우린 행복한가?
이 질문에 "그렇다"라고 대답하지 못한다면 우리가 지향하는 가치에 대해 다시 한번 더 생각해 봐야 한다. 결국 이 질문의 답을 구하는 것이 우리가 삶을 살아가면서 어떻게 살 것인가라는 질문의 답을 구하는 과정이 될 수 있다.
품질 저하가 결국 프로젝트를 실패로 이끌 수 있듯이 행복하지 않은 인생은 우리 삶의 본질을 흔든다. 프로젝트를 수행하면서 느낀 바는 부족한 시간에 쫓기며 개발된 결과물은 결국 품질을 희생시킨다는 점이다. 결국 관리자는 불가능한 일정으로 소프트웨어의 품질을 망친다.
결함은 나중에 해결하면 된다고 생각하겠지만 그 결과 불완전한 제품이 세상에 나오고 만다. 허둥지둥 시간에 쫓기며 항상 바쁘다고 하소연하는 사람들 역시 결국 자신의 행복을 희생한다. 지금 당장 처리해야 할 일이 산더미인데, 행복이 밥 먹여주느냐고 불평하는 사람들도 있을 것이다. 이런 사람들의 공통적인 특징은 행복을 삶의 부차적인 요소로 여긴다는 것이다. 상황에 따라 지금 당장 있어도 되고 없어도 되는 것쯤으로 치부해 버린다.
언제까지 품질의 희생은 정당화될 것인가? 더 늦기 전에 어떻게 해야 삶의 품질을 높일 수 있을지 생각해보자. 소프트웨어의 품질을 높이기 위해 반복 작업을 줄이고, 더 나은 방향으로 프로젝트를 이끌어 가며, 고객의 요구사항 변경에 효율적인 대처 방안을 생각하듯 우리 삶의 문제도 관심을 갖고 대응해보자.
결국 품질과 생산성의 적절한 균형이 필요하다. 품질은 지금 하는 일에 부가된 또 다른 일이 아니다. 품질이 부가적으로 부여된 일이라는 인식부터 거둬야 한다. 품질을 향상시키는 것이 결국 좋은 제품을 만들고, 고객의 가치를 높임과 동시에 비용을 줄이는 일이라고 생각해야 한다. 마찬가지로 내 삶에서 행복을 전방위로 끌어올려야 한다. 품질과 같이 항상 뒤에 숨어 희생을 강요받아야 했다면 이제부터라도 적절한 대우가 필요하다. 행복의 가치는 상대적이며 스스로 부여하는 것이다.
취업준비생들에게 행복의 조건이 취업이라면 직장을 다니고 있는 사람들은 취업이 행복을 보장하지 않는다고 말할 것이다. 직장인들에게 행복의 조건이 돈을 많이 벌어 하루 빨리 은퇴하는 것이라면 은퇴한 사람에게 행복은 일을 하는 것일 수 있다.
현재 행복하지 않다면 자신에게 물어보자. 내가 행복할 준비가 되어있는지, 그리고 자신에게 답하라. 나만의 행복조건을 찾았다고 말이다. 한 가지 명백한 사실은 주위에서 정해준 행복의 정의가 나에게는 통용되지 않을 가능성이 크다는 점이다. 누구나 원하는 바가 다르다는 점에서 행복은 지극히 주관적이다. 지금이라도 내가 만든 제품에 꾸준한 정성을 들이고 애정을 쏟듯 나에게 맞는 행복의 정의를 내려보자. 개발자의 행복한 품질관리는 시스템이 성공하는 이유 있는 비결이다.