두 개발팀의 Governance, 그리고 나는 Proxy였다

개발팀은 두 개였고, Governance는 하나도 없었다. 한 팀은 영향범위 파악을 기획자에게 모두 해오라며 고압적으로 요구했다. 다른 팀은 개발리더가 "스토리보드 설명은 불필요다. 개발자가 소스 보고 판단한다"고 했다. 이것이 바로 Internal SLA의 불일치였다. 누가 무엇을 책임지는지, 경계는 어디인지에 대한 계약이 팀마다 달랐다.

나는 리더 B의 원칙을 믿었다. "개발자가 스스로 고민하면 된다"는 그 말이 Agile의 정수처럼 들렸다. 하지만 실제 담당자는 첫 스프린트 미팅에서 항의했다. "기획서에 기능 설명도, 영향범위도 없는데 어떻게 개발하라는 거예요?" 개발리더는 모르쇠로 일관했다. 그는 원칙만 이야기했고, 실행은 담당자에게 떠넘겼다. 이게 바로 Waterfall Governance를 Agile 포장지로 감싼 사기였다.

연차 높은 개발자도 마찬가지였다. 그는 기획자에게 영향범위 파악을 요구했다. 하지만 그가 만든 결과물에는 늘 허점이 있었다. "예외 케이스를 고려하지 않았다"거나, "레거시와 충돌난다"는 지적이 뒤따랐다. 그러곤 이번 배포 디펙에 대해 이렇게 말했다. "원인이 저에게 있든, 밖에 있든 업무요청은 원칙대로 하면 됩니다." 이것이 Accountability가 아닌, Blame Avoidance였다.

기획자의 역할은 Proxy가 아니라 Gateway였다. 팀 A는 내게 모든 요청을 막아내는 WAF(Web Application Firewall)가 되길 바랐다. 팀 B는 내게 아무것도 하지 않는 Transparent Proxy가 되길 바랐다. 하지만 나는 둘 다 제대로 하지 못했다. 팀 A에겐 영향범위를 모두 파악하지 못했고, 팀 B에겐 담당자가 원하는 정보를 주지 못했다. 그래서 나는 MITM(Man-in-the-Middle) 공격의 중간자가 되어, 양쪽으로부터 신뢰를 잃었다.

교훈은 명확했다. Governance는 팀 문화가 아니라, 명문화된 계약이어야 한다. 기획자가 영향범위를 파악할지, 개발자가 할지는 팀의 성숙도 모델(Maturity Model)에 따라 달라진다. 하지만 그 결정은 리더가 아니라, 실제 작업자들의 합의(Consensus)를 통해 이뤄져야 한다. 그렇지 않으면 리더의 원칙은 공허한 DRM(Digital Rights Management)이 되고, 담당자는 불법 복제된 기획서를 만들게 된다.