다양한 직무의 사람들과 일해본 경험
그리고 어려웠던 점.
시작하기에 앞서 유명한 현실 100% 고증 조별과제 짤 첨부. (이 중 한 명은 저 뒤 멀찍이서 구경하고 있는 게 킬링 포인트) 좋은 협업이란 무엇일까. 그전에 먼저 나와 다른 직무를 수행하고 있는 사람들과 일해본 경험을 적게나마 정리해 보았다.
나는 이전에 소프트웨어 QA로 일을 했었기 때문에 아무래도 개발 팀과의 협업이 잦은 편이었다. 프로젝트를 진행할 때마다 담당하는 모델팀의 개발자들과 핑퐁을 주고받는 일이 많았는데 돌이켜보면 그 과정이 늘 매끄럽지만은 않았었다. 물론 큰 그림으로 볼 때야 준비 중인 제품의 무사 출시라는 공동의 목표를 가지고 품질 팀과 모델 팀 모두 각자의 자리에서 최선을 다하는 모습일 테지만, 들여다보면 팀별 목표는 상이하기 마련이고 그 입장 차이 때문에 일터에서 수많은 충돌이 빚어지고는 했다.
나 역시도 그랬으니 남의 일 말하듯이 하지는 못하겠다. 사실 입사 초기에는 중남미향, 일본향 모델을 담당했었기 때문에 크게 트러블이 일어날 상황도 없었다. 이러한 중저가의 모델들은 고가 모델에 비해 큰 이슈가 없었기 때문에 선례를 참고하여 문제를 정리하면 그만이었다. 하지만 연차가 쌓이고 이후에는 플래그십 모델을 담당하게 되면서 이해관계자들과의 핑퐁 빈도가 J커브를 그리기 시작했다.
플래그십 모델의 경우 신기능이 선반영되는 모델이고, 그렇다 보니 어떤 이슈가 발생되었을 때 이전의 선례가 남겨져 있지 않은 경우(Unknown issue)가 대부분이다. 그 뜻은 사고가 터졌을 때 이후의 책임공방이 아주 가열차게 벌어진다는 뜻이며, 선례가 없기 때문에 책임 소재도 모호해진다는 말이다. 초기의 불안정한 소프트웨어 버전에서는 하나의 앱에서 적게는 수백 개, 많게는 수천 개의 버그(Bug)가 콸콸 쏟아지는데 초반에야 수정이 쉽다. 있는 문제를 전부 리포트하고 최대한 수정하는 방향으로 물 흐르듯 진행된다. 문제는 그 이후인데, 선행 단계를 지나 중간 단계쯤 다다르면 버전의 안정화가 이루어져야 하는 시점이기 때문에 개발팀은 최대한 버그(Bug)를 신중하게 수정하려고 한다. 바로 이 과정에서 개발과 품질은 핑퐁다운 핑퐁을 주고받게 된다.
"선임님, Yellowish 현상 꼭 수정해야 하는 문제예요. 이거 출하에서 문제 될 수도 있어요."
"육안으로 봤을 때 큰 차이도 없고 현재 기능 구현상 화질을 수정하게 되면 카메라가 아예 뻑날 수도 있어요."
이전에 언급했듯이 이전 모델에도 있었던 이슈라면 정리가 한결 쉽겠지만, 안타깝게도 신규 반영된 features의 경우에는 참고할 만한 사례가 거의 없다. 그런 이유로 이슈 케이스를 쉽게 Close 해버리면 나중에 시장에서 품질 사고가 터졌을 때 자칫 곤란해질 수도 있다. 담당자인 자신이, 몸을 담고 있는 팀이 총체적인 책임을 져야 하는 불행한 사태가 벌어질 수도 있는 것이다. 언뜻 보면 담당자들끼리의 책임 공방처럼 보이지만 결국 팀의 목표를 위해서 제약된 부분이기도 하다.
어렵지 않게 수정해 줬던 Known 이슈를 갑자기 수정 못한다고 하길래 전화기를 붙들고 이전 사례들을 들어가며 한참동안 설득했던 적도 있는 반면에, 품질 담당자의 입장에서 보아도 문제는 안될 것 같지만 이후의 생산/출하 공정에서 문제의 소지가 있어 보여 개발팀에 수정을 요구했던 적도 있다. 이런 핑퐁을 할 때면 개발자마다 보이는 반응도 제각기 다르다. 불가피한 상황을 이해하고 협의를 준비하는 개발자가 있는가 하면, 왜 이런 얼토당토 한 요구를 하는지 모르겠다며 반박하는 개발자도 있다. 이러한 차이는 개발자뿐만 아니라 QA에서도 볼 수 있다. 회의에 참석했던 나 역시도 그 이슈를 수정하게 되면 얼마나 큰 사이드 이펙트가 발생할지는 이해하고 있었다. 그럼에도 팀의 목표 차이 때문에 최대한 입장을 관철하고 협의(라고 쓰고 증거라고 읽는) 자료를 남겨 이후에 생길 분란을 막을 수밖에 없었던 것이다. 그런 논의 자체를 의미 없는 과정이라 치부할 수는 없지만 상당히 급박한 시기에 이루어졌던 대화임을 고려해보면 Loss임을 부정할 수 없다. 이 과정에서 정작 고객은 뒷전이 되는 사태가 종종 벌어진다.
버전이 승인(인정)되고 다음 단계인 생산과 출하로 넘어가면 QA들도 개발자의 입장을 조금은 이해할 수 있게 된다. '말도 안 되는 이슈로 트집을 잡는다.' 수정을 해야 하는 주체에 있었던 사람들이라면 한 번씩 들어봤음직한 말이다. 우리 팀도 정말 이해하기 어려운 이슈를 제기받은 적이 있었다. 몇 번의 공방 끝에 결국 그 이슈 케이스는 제품 매뉴얼에 안내 문구를 포함시키기로 하고 종결되었다. 이는 결국 우리 팀 역시도 우리만의 상식에 갇혀 고객의 눈으로 바라보지 못했다는 반증이었고, 다시금 내 입장을 명확히 이해하는 계기가 되었다. 제품을 위한 제품을 만들고 있지는 않은지, 실 사용자인 고객을 충분히 고려했는지.
다양한 직무의 사람들과 일을 하며 어려웠던 점은 관계자들의 입장차를 이해하고 의견차를 좁혀나가기 위해 에너지를 쏟아야 했다는 점이다. 유의미한 논의를 위해 사적인 감정이나 비업무적인 요소는 배제하고 어젠다에 초점을 맞추는 것. 내가 가장 많이 고민하고 노력했었던 부분이기도 하다. 현장에는 요령만으로는 해결할 수 없는 '진짜 문제'들이 산재해 있기에 그것들에 관해서 어떻게 협업하고 조율할지는 끊임없이 고민해 봐야겠지만.
