'역할'과 '하는 일'은 다른 개념이다.

쉽게 생각했을때는 그렇다. 역할이 달라지면 분명 하는 일이 달라진다. 그러나 더 중요한 것이 달라져야 한다는 것을 알게 됐다.

개발 출신의 어느 개발자가 세월이 흘러서 품질을 담당하게 되었다. 그래서 품질을 관리하는데 필요하다는 일들을 해 오다가 어느날 자기가 무엇을 해야 하는지 모르겠다고 고민을 말해왔다. 자기가 하는 일은 다른 사람들이 다 하고 있고 그들이 더 잘하고 있다는 것이다. 품질 담당이 자기라면서 다른 사람이 다 하고 있다는 말은 무엇이고 그리고 다른 사람들이 더 잘하고 있다는 말은 또 무슨 말인지 이해할 수가 없었다. 

얘기를 들어보니 이런 것이었다. 예를 들어서, 보안이나 성능 등의 품질을 관리하기 위해서는 배포 솔루션을 개발하는 기법, 사용되는 개발 프레임워크, 코딩 패턴등에 대해서 모두 알고 있어야 하는 것은 아닌지, 그렇다면 그것들은 지금의 담당자들이 자신보다 더 잘알텐데 하는 고민을 하고 있었다. 그리고 또 한가지는 보안이나 유지 보수성 등 같은 품질을 구현하는 방법에 대해서는 이미 기술 PM이나  기술 아키텍트가 더 잘 알 고 있으니, 그러니 자신은 할 일이 뭔지 모르겠다는 식이었다.  

구현에 사용하는 기술들을 잘 알아야, 관리를 할 수 있는 것이 아니냐는 생각이었던 것이다. 아니면 개발 출신답게 기술에 대해서도 잘 알고 있어야 하지 않냐는 욕심도 있을 수 있었을지도 모른다. 필자가 판단한 문제의 원인은, 품질 담당이라는 것을 역할로 받기는 했지만, 그의 마인드는 아직 개발자 관점을 벗어나지 못하고 있었던 것이다. 즉 품질 관리라는 것을 개발, 구현 관점에서 바라보고 있었다. 그렇다 보니 앞에서 예를 든 두 경우 모두 구현에 대한 지식, 경험이라는 관점에서 보면, 다른 사람들이 자신보다 뛰어나다. 그래서 자신은 할 일이 없어지는 것 아니냐, 무엇을 할지 모르겠다는 것이다. 

그러나 품질 관리는 그런 것이 아니다. 기밀성, 신뢰성, 사용성, 효율성, 유지 보수성, 이식성, 보안 같은 품질은 프로젝트의 목표와 프로젝트의 요구사항에서 나오는 것이다. 그 요구사항으로 품질 목표가 정해지고 구현하는 사람들은 그 목표를 달성하도록 구현해야 한다. 즉, 우선 순위면에서 보면 품질 목표가 우선적이고 구현은 그 품질 목표가 제공하는 제약에 종속되어서 구현되어야 하는 것이다. 품질 관리자는 구현에 사용하는 기술의 품질을 책임지거나 그것을 먼저 알아야 하는 것이 아니라 프로젝트 요구사항으로 나온 품질을 먼저 정의하고 그것을 달성하기 위해서 구현자들과 논의해야 하는 것이다.  개발, 구현자들은 그 목표 품질을 달성하는데 자신이 사용할 기술이 타당한지를 검토해야 한다. 만약 구현 기술이 이미 결정되어 버렸고 그리고 구현 기술이 목표 품질을 달성하는데 부족한 면이 있다면 고객과 구현자, 품질 관리자가 모여서 협상을 해야 하는 것이다. 

품질 관리자는 프로젝트에 필수적인 품질들을 정의한다. 즉 프로젝트 발주자나 사용자 관점에서의 요구사항으로부터 반드시 필요한 품질 속성들을 추출해서 고객과 합의해서 목표로 정의한다. 그러고 나서 이것들이 구현과 어떤 관계를 가질지를 분석한다. 예를 들어 보안을 달성하기 위해서는 설계, 개발이나 구현, 테스트 단계의 어떤 것들과 관계가 있는지를 분석해야 한다. 그리고 프로덕트 자체도 보안과 관련해서 어떤 면을 검토해야 하는지도 고려해야 한다. 이러자면 개발자와 PM, 비즈니스 담당자 등등 다른 역할을 담당하는 사람들과 목표 품질별로 의사 소통을 해야 할 수도 있다. 품질 담당자는 품질을 달성하는데 필요한 제약사항 등을 분석하고 플래닝하는 관점에서 의사 소통을 해야 한다.  품질은 프로젝트의 요구 사항 분석 단계에서 나오는 목표이고 구현은 그 목표를 달성하기 위해서 그것의 제약을 받아야 한다는 것이다.  품질 관리자가 품질을 관리하기 위해서 구현 기술의 지식을 알아야 하냐 몰라야 하냐는 현실적인 프로젝트의 상황에 따라서 달라질 수는 있겠지만 기본적으로 품질과 구현의 관계는 잊지 말아야 한다.  

예를 들어 역할에 따라서 품질 관리자와 구현자가 각각 분리되어 있다면, 엄밀히 말하면 구현에 사용되는 특수한 기술이나 기법들은 품질 관리자의 관심이 아니다. 물론 구현을 하는 특수한 기술까지 안다면 좋겠지만, 그렇다고 해서 품질 관리자가 그 기술의 구현 방법까지 모두 알아야 하는 것은 아니다. 품질 관리자는 그 기술이 어떤 품질 속성을 달성하는데 도움이 되는지, 부족한 부분이 없는지 판단하기 위한 곳에 관점을 두고 구현자와 커뮤니케이션을 해야 한다. 그래서 기술을 더 잘 알고 있는 구현자의 도움을 받아서 품질 관점에서 질문을 해서 얻어내면 되는 것이다. 그러나 품질 관리자가 구현자이기도 하다면 물론 기술에 대한 구현을 위한 지식과 품질 구현을 지식 모두을 알아야 할 것이다. 

품질 관리자는 개발, 구현자들과 커뮤니케이션을 할때, 어떨게 목표 품질을 달성할지에 대한 추상화된 개념적인 차원의 의사 소통을 해야 한다. 특정 회사에서만 사용하는 기술 명칭 대신에 일반적인 용어를 사용해야 한다. 개발자는 특수 용어인지 일반 용어인지 구분하지 못하는 경우가 있다. 그렇다면 경험이 있는 품질 관리자는 개발자가 사용하는 특수한 용어를 자신이 알고 있는 일반 용어로 변환하고 서로 확인해야 한다.

앞에서 언급한 품질 관리 담당자는 분명 품질 관리를 개발과 구현하는 관점에서 보고 있는 것이었다. 자신이 구현된 기술에 대한 지식을 모두 알고 있어야 한다는 생각이었던 것이다. 그래서 그 기술이 제공하는 모든 품질 관점의 특성들을 다 알고 있어야 한다는 생각이었던 것이었다. 그는 그것을 품질 관리자의 역할로 보았던 것이다. 

역할을 알기 위해서는 그 역할이 담당하는 일의 목록을 아는 것보다 그 이전에 그 역할이 전체 프로젝트 맥락에서 어떤 위치에 있는지를 아는 것 또는 역할이 달라지면 동일 사안을 바라보는 '시점, 관점'이 달라져야 한다는 것을 아는 것이 중요하다는 것을 깨닫게 되었다. 바라보는 방향이 달라져야 자신이 갈 길이 보인다. 시선은 여전히 개발자 관점을 유지하면서, 일만 품질 관리에서 정해진 일을 하는 것만으로는 역할 수행을 완전히 할 수는 없다는 것을 알게 되었다.