Karen
15k
2016-02-11 13:50:58
2
2627

Brunch with Roaster Kay - 다시는 QA를 무시하지 마라


개인적으로, TV를 통해 바라본 파푸아 뉴기니섬은 굉장히 엑조틱한 경관 때문에 한 번쯤은 꼭 가 보고싶은 곳입니다. 비록 몇몇 비평적인 매체의 폭로를 통해, 원주민들이 그들만의 전통과 습성을 오롯이 유지하는 게 아니라 관광산업을 위해 연출한다는 사실을 깨달았을지라도 말이지요. 커피 마니아가 아니라면 잘 모를 수도 있지만, 은은한 꽃향기가 나는 커피 생산지로도 유명합니다. 파푸아 뉴기니섬의 커피는 처음부터 자생한 게 아니라, 자메이카의 블루마운틴을 이식했습니다.


블루마운틴은 파푸아 뉴기니와 달리 꼭 마니아가 아니더라도 한 번쯤은 들어보았을 법한 이름입니다. 완벽한 밸런스와 부드러운 쓴맛으로 오랫동안 커피의 황제라는 타이틀을 내려놓지 않은 블루마운틴은 동생인 파푸아 뉴기니와 많은 점에서 빼닮았습니다. 원두의 모양새나 로스팅하는 방법, 맛까지도요. 단 하나 차이점이 있다면 가격입니다. 형님인 블루마운틴이 적어도 열 배, 심할 때는 스무 배 이상 차이가 납니다.


왜일까요? 물론 자메이카 블루마운틴이 오리지널이고 파푸아 뉴기니가 일종의 레플리카이기 때문이기도 합니다만, 그보다 중요한 건 품질 관리에 있습니다. 공장식 도정 및 가공이 끝난 뒤, 자메이카의 생두는 일일이 사람 손을 거쳐 검사되고, 콩 한알 한알이 정성스레 닦여 마치 할머니 손에 끼워진 옥가락지마냥 윤이 나거든요. 대개 다른 지역의 생두를 볶기 전에는 쟁반 같은 데 콩을 잔뜩 늘어놓고 어디 깨진 콩이나 벌레먹은 콩이 없는지 살펴보고 골라내야 합니다. 못된 콩 한 알이 망치는 원두의 개수는 무려 300개입니다(아메리카노 한 잔에 겨우 50알의 원두가 들어간다는 걸 고려하면 실로 어마어마한거죠). 하지만 자메이카 블루마운틴 생두에서 못난 콩을 발견한 날은, 당장 커피 로스팅을 중단하고 로또를 사러 달려가도 되는 날입니다.


품질관리에 있어, 커피와 개발은 상당히 비슷합니다. 여러분이 밥벌이로 코딩을 하는 이상, 여러분의 손을 떠난 바가지가 밖에서 줄줄 새기 시작할 때 여러분이 짊어져야 할 책임과 비난은 무겁습니다. 어쩌면 얼굴이 발갛게 익어서 개발실 문을 막차고 들어오는 팀장님이나 갑님과 흥미로운 대화를 해야할지도 모릅니다. 무엇보다 큰 문제는, 많은 사용자들이 실제로 여러분이 기대(혹은 염려)하는 것만큼 열정적인 종족이 아니라는 데 있지요. 그들은 문제를 보고하는 대신, 쓴 웃음을 지으며 ‘프로그램 삭제’를 실행할 겁니다.


하지만 테스트는 정말 고되고 지루한 일입니다. 여러분이 번뜩이는 재치로 무장한 개발자일수록, 품질활동의 미덕은 아마 여러분과 정반대의 정점 어딘가에 있을 겁니다. 뿐만 아니라, 합리적인 시간 안에 문제를 해결하고 여러분의 프로젝트를 완료하려면, 단지 테스트를 열심히 하기만 해서는 안 됩니다. 체계적이고 적절한 방법론이 동원되어야 하죠. 이 모든 재능은 여러분이 타고 나거나 어디서 배운 게 아닙니다. QA 엔지니어기의 특기죠.


여러분의 코드가 아무리 서말이라도 적절한 테스트를 통과해야 비로소 보배가 됩니다. 따라서 여러분의 조직이 QA인력의 중요성을 등한시하고 그들의 발언권을 무시할수록, 여러분이 작성한 모든 코드가 화려한 똥이 될 가능성은 올라갑니다. 똥이 쌀밥이 될 때까지 일일이 찍어 먹어보고 고통받으면서도 내색하지 않는 QA 엔지니어들은 존중받고 존경받아야 마땅합니다.


지금까지 왜 여러분의 프로젝트에서 품질활동이 중요한지, 왜 QA 엔지니어를 존중해야 하는지 설명했습니다만, 주의할 점이 한 가지 더 있습니다. 품질 지표에 너무 기대지는 마시란 겁니다.


자메이카 블루마운틴은 정말 완벽한 커피지만, 동시에 아무런 개성도 없는 커피이기도 합니다. 몇몇 지역의 커피는 꽃내음이나 자몽향같은, 척 듣기에 좀 비현실적인 향이 나기도 하는데 이런 향미는 대개 적절한 결점이 혼입되어야 일어나는 특이한 현상입니다. 품질 지표를 과업의 지표로 삼는 순간, 프로젝트의 가치가 퇴색할 수 있습니다. 로드맵을 좀 더 뻔하고 보수적인 플랜으로 가득 채울 우려도 있죠. 어떤 방법론이 다 그러하듯이, 품질 지표는 어디까지나 더 가치있는 소프트웨어를 개발을 돕는 수단이어야지 그 자체가 목적이 되어서는 안 되는 법입니다.


오늘 이야기는 여기서 끝입니다. 자, 이제 QA 엔지니어 또는 테스터와 점심 약속을 잡아 볼까요? 그는 여러분의 가장 든든한 지원군이자, 여러분의 코드를 열 배는 더 빛나게 해 줄 고마운 사람이니까요 :)



Roaster Kay님 Brunch 주소
https://brunch.co.kr/@roasterkay/  
1
  • 댓글 2

  • 진C
    1k
    2016-02-11 16:24:50
    좋은 글 소개 감사합니다^^ 이 분은 글을 재미있게 잘 쓰시는 것 같아요!
  • Karen
    15k
    2016-02-12 11:25:03

    진C // 감사합니다~^^ 실제 말씀도 엄청 잘 하세요~ㅎㅎ

  • 로그인을 하시면 댓글을 등록할 수 있습니다.