33
1
장
개발자와 데브옵스
이들의 피드백을 통해 프로덕트 오너는 벤치마크의 부합 여부와 적합도를 측정할 수 있다. 훌
륭한 소프트웨어 개발자에게 있어 이러한 상황은 모범적인 ‘완료’를 나타내는 썸네일이나 다름
없다. 다르게 표현하면, 운영 인력의 참여와 투명한 의사소통 없이는 ‘완료의 우수성’을 측정하
기 어렵거나 심지어 불가능하다는 뜻이다.
1.2.2 1.2.2
라이벌 관계라이벌 관계
데브옵스가 개발자들의 외침에서 비롯되지 않았음이 증명된다 해도, 데브옵스의 무한 순환이
모두에게 이롭다는 사실에는 변함이 없다. 그러나 이를 받아들이기 어렵게 하는 저항은 여전히
존재한다.
QA
테스터와 개발자 사이의 경쟁심 또는 적개심이 대표적인 예다. 자신의 창작물에
각고의 노력을 기울인 개발자에게 있어
QA
팀은 마치 해커 같은 존재다. 대체 무엇을 증명하
려는 것인지, 끊임없이 문제를 찾아다니며 파고들기를 멈추지 않는다.
이 대목에서 데브옵스 카운셀링이 필요하다. 무릇 소명 의식이 투철한 개발자일수록 자신의 결
과물을 자랑스럽게 여기는 법이다. 자신의 결과물이 지적당하면, 게다가 지적하는 쪽의 소명
의식 역시 투철하다면, 개발자는 자기 자신이 비난받는다고 느끼게 된다. 개발자와
QA
가 서로
투명하고 개방적이며 지속적으로 소통한다면 데브옵스가 주는 이익을 실현하는 동시에 구성원
모두가 궁극적으로 같은 목표를 추구한다는 공감대를 형성할 수 있다.
QA
가 버그를 식별하는
일은 자신의 동료가 더 나은 코드를 작성하고 더
나은나은
개발자가 되도록