QA 클래스의 탄생

2014년 5월, 조직에 칸반을 도입한지 석 달만에 드디어 우리의 첫 번째 병목 지점이 드러났다. 다름 아닌 “테스트” 단계였다.

처음 NBT 개발 프로세스에는 명시적 테스트 단계가 없었다. 그럼에도 불구하고 굳이 테스트 단계를 칸반 보드 상에 넣었던 이유는 단순한데, 당시 구현 마지막 시점에서 때로는 생략하기도 하고 때로는 매우 제한적으로만 이루어지기도 했던 테스트를, 개발자들이 좀 더 노력을 기울이고 의식적으로 진행하기를 원했기 때문이었다. 테스트 단계의 WIP를 제한하지도 않았고, 테스트 단계의 완료 조건을 엄격히 정의하지도 않았었지만, 이 간접적 변화의 효과가 바로 드러나기 시작했다. 칸반 보드의 테스트 단계에 한 번 발생한 티켓 집중 상태는 해소될 기미가 없었다. 그 때 이런 의견이 팀에서 나오기 시작했다.

“우리도 테스터가 필요한 것 아닐까요?”

누군가 “QA”와 “테스터”의 정확한 차이를 물어본다면 아직도 정확히 답변하기는 어려울 것 같다. 게다가, 내가 아무리 정확한 정의를 내린다 한들, 사람들이 머릿속에 떠올리는 이미지는 완성된 (또는 완성에 가까운) 제품의 기능을 하나씩 실행해보며 문제점을 찾아내서 보고하는 역할일 것이다.NBT에 테스터로 이루어진 그런 조직을 만들고 싶은 마음은 조금도 없었다. 기획, 개발, 디자인, 테스트 등 모든 기능이 제품 개발의 처음부터 끝까지 호흡을 함께 해야 한다고 믿기 때문이다. 우리에게 어울리는 합리적 수준의 품질을 정의하고, 그 품질을 달성 및 유지하기 위해 필요한 모든 활동을 제품 개발 생애 주기 전반에서 수행하는 역할이 필요하다고 판단했다. (주변 이야기를 들어보면 이런 역할을 보통 QA[Quality Assurance, 품질 보증]라고 부르는 듯하다. 그러나, 나는 이 이름도 전혀 옳지 않다고 본다. 왜 특정 몇몇 사람들만 품질에 대한 보증을 해야 하는가? 품질 보증은 CEO부터 제품 개발에 참여하는 모든 사람까지 하는 것이라고 생각한다.)

다행스럽게도 많은 분들이 지원해주셨고, 그 중에서 테스터의 역할을 뛰어넘어 좀 더 큰 그림을 그리고 실현하길 원하는 두 명이 합류해서, NBT에는 QA 클래스가 생겨나게 되었다. 그것이 2014년 여름에서 가을로 넘어갈 무렵이었다.

QA의 역할에 대한 고민

하지만, 모든 일이 생각대로 순조롭게 흘러가지는 않았다. QA 클래스가 생겼는데도 제품 품질이 그대로라는 불만이 조직 여기저기에서 나오기 시작했다. 사람들이 QA라는 역할에 기대하는 바와, 우리가 QA 클래스를 만들면서 지향했던 방향이 일치하지 않았으니, 어쩌면 예견된 일이었을지도 모르겠다. 나 뿐만 아니라 QA 클래스를 포함해서, “우리에게 어울리는 합리적 수준의 품질을 정의하고, 그 품질을 달성 및 유지하기 위해 필요한 모든 활동을 제품 개발 생애주기 전반에서 수행하는 역할”을 하려면 구체적으로 매일매일 어떤 일을 해야하는지 아무도 모른다는 것이 가장 큰 문제였다.

QA 클래스에 테스터의 역할을 기대하는 사람들에게, QA가 서비스 기획이나 개발 단계에 함께 참여해야 한다고 설명하기가 쉽지도 않았고, QA 클래스도 역할 범위 문제 때문에 조심스럽게 접근하다보니 적극적인 역할을 펼쳐보이기가 매우 어려웠다. (어느 조직이든지 역할과 책임 문제가 가장 예민한 폭탄이다.) QA 클래스가 제품 개발 생애 주기 전반에 참여하려면, 거기에 걸맞도록 제품 개발 프로세스 전반의 변화가 필요했다.

엔지니어링 컬처(EC) 클래스의 탄생

프로세스에 대해 사람들이 흔히 저지르는 오류 중 한 가지가, 훌륭한 프로세스를 만들면 모든 일이 잘 될 것이라는 가정이다. 원하는 결과를 얻으려면 프로세스를 만들고 가이드를 배포하는 단계에서 멈추면 안된다. 프로세스를 만든 다음, 그 목표에 공감할 수 있도록 사람들을 설득하고, 구성원들이 충분히 자발적으로 실행할 수 있을 때까지 조직에 적용하면서, 거기에서 발생하는 역동을 주의 깊게 관찰하고 문제점을 보완하는 지속적인 조정이 함께 이루어져야 한다. 다시 말해, 프로세스를 바꾼다는 것은, 조직의 문화를 바꾼다는 의미다.

QA 클래스의 역할을 조직 문화 관점에서 고민하다보니, QA란 결국 내가 하고 있던 애자일 코치 역할과 큰 틀에서 다르지 않다는 것을 깨달았고, 두 역할을 동시에 병행하는 하이브리드 조직을 시도해보면 어떨까 하는 아이디어가 떠올랐다. 문제를 이런 방향으로 풀어보려는고 시도했던 이유는, 다행스럽게도 QA 클래스 구성원들이 애자일 코치로서의 역할에도 관심을 보여주고 있었고, 1년 남짓 함께 생활하면서 두 사람 모두 그 역할을 훌륭하게 잘 해낼 수 있다는 믿음이 생겼기 때문이었다.

서로의 비전과 바람을 솔직히 이야기하면서 함께 밑그림을 그렸고, 2015년 7월에 QA 클래스는 엔지니어링 컬처 클래스(이하 EC 클래스)라는 새로운 이름과 역할로 진화했다.

그 때 세 명이 함께 만들었던, 그리고 지금도 유효한 EC 클래스의 비전은 다음과 같다.

“훌륭한 개발 문화가 매일매일 성장할 수 있는 환경을 누구보다 먼저 고민한다.”

EC 클래스의 역할

EC 클래스에서 수행하고 있는 역할은 크게 세 가지다.

• 첫 번째는 “지속적 프로세스 개선”이다. 일일 스탠드업 미팅이나 주간 회고, 또는 그 외 모든 모임에서 의견을 조율하고 더 나은 결론을 이끌어낼 수 있는 퍼실리테이터의 역할을 담당한다. 그러면서도, 개발 프로세스의 개선 지점을 도출해내고, 정책을 명시화하며, 품질을 비롯한 개발 완료 조건에 대해서도 고민한다. 이 과정에서 다양한 린/애자일 실천 방법들을 도입하고 실행하기 위해 노력하고 있다. 아직 흔하지는 않지만, 다른 회사에서는 스크럼 마스터, 애자일 코치, 또는 프로젝트 관리자들이 주로 수행하는 역할이라고 볼 수 있다.
• 두 번째는 “개발 지원 환경의 구축 및 운영”이다. 위키, 이슈 추적 시스템, CI, 코드 정적 분석 도구 등 각종 개발 도구를 리서치하여 구축하고 운영한다. 아울러 테스트 자동화를 위한 각종 지원을 위해서도 노력하고 있다. 대부분의 회사에서 이런 부분은 관심 있는 개발자가 자발적으로 담당하거나, 또는 몇몇 사람들에게 부가 업무로 주어진다. 나는 이런 활동들이 누군가의 선의에 의존하거나, 부가 업무가 되어서는 안된다고 생각한다.
• 세 번째는 “품질 문화 정착 활동”이다. 제품 및 코드 품질을 측정하고 시각화해서 각 파티에서 자발적으로 개선할 수 있도록 대시 보드 및 품질 지표들을 관리한다. 또한 제품에 대한 조직 내부 및 외부의 피드백에 대한 모니터링도 꾸준히 진행하고 있고, 그런 의견들이 제품에 잘 반영될 수 있도록 개발 과정에 꾸준히 참여한다. 어떤 관점에서 보면 우리가 처음에 바라던 QA의 역할이 여기에 제일 가깝지 않을까 생각한다.

사실 EC 클래스의 역할을 한 마디로 규정하기란 어려운 일이다. EC 클래스는 자신의 역할에 대해서도 지속적으로 개선하고 있기 때문에 상황에 따라 그 역할을 조금씩 바꾸어왔다. 프로젝트를 성공적으로 수행하고, 그 과정에서 구성원들이 만족할 수 있도록 모든 노력을 다 한다는 점에서 어찌보면 리더십 포지션에 가깝다고 볼 수 있다. 그러나 팀장이 팀원들 위에서 지시하고 통제하는 리더십을 발휘하는 것이 일반적인 모습이라면, NBT의 EC 클래스는 팀원들의 옆에서 그들의 어려움을 함께 공감하고 소통하는 방식으로 리더십을 발휘한다.

바람직한 EC 클래스 구성원의 조건

내가 생각하기에, 애자일이나 QA에 대한 경험이나 지식은 EC 클래스 구성원이 되는데 반드시 필요한 조건은 아니다. 어떤 경우에는 그런 조건들이 오히려 방해가 될 수도 있다. 가장 중요한 것은 “더 훌륭한 개발 문화를 이루고자 하는 열망”과 “나 자신과 주변 사람들의 성장에 대한 관심”이 아닐까.

스크럼이나 XP 또는 칸반 같은 방법을 중요하게 여기는 사람, 기존 시스템에 대한 절망이 분노와 냉소의 모습으로 남아있는 사람, 현재에서 탈출해서 새롭고 신선한 분위기를 원하는 사람보다는, 자신만의 비전을 갖고 있고 그 비전을 이루고자 하는 열정이 있는 사람, 함께 일하는 사람들에게 다가가서 먼저 신뢰를 보여줄 수 있는 사람, 지금에 만족하지 않고 서서히 더 나은 방향으로 나아갈 수 있는 사람과 함께 일하고 싶다.

그런 의미에서 지금 두 명의 EC 클래스 구성원들은 배울 점도 많고 건강한 자극이 되기도 하는 훌륭한 동료들이며, NBT 제품 길드가 지금까지 올 수 있었던 중요한 원동력 중 하나였다고 생각한다.

앞으로 어떤 사람이 새롭게 합류해서, EC 클래스와 구성원들이 어떤 방향으로 진화해갈지 매우 궁금하기도 하고 기대도 된다.

P.S. 그렇습니다. 이 글의 주 목적은 채용입니다^^ NBT의 EC 클래스에 관심이 있는 분이 계시다면, 함께 이야기를 나눠보고 싶습니다. cho.seungbin@nbt.com으로 언제든지 연락주세요.