개발 vs 품질 Ⅰ

A는 S로 번역된다

완제품의 첫 출하 직전, 이음새가 먼저 말을 걸었다. 결함이라고 부르기엔 애매하고, 그렇다고 무시하기엔 껄끄러운 종류의 불편함. 자세히 봐야 알지만 한 번 보이면 자꾸 신경 쓰이는, 딱 옥에 티 같은 것이었다.

누군가 중얼거렸다.

“이거… 반품 들어오는 거 아냐?”

기준은 통과했다. 출하는 가능했다. 공장 입장에서는 오늘 해야 할 일을 오늘 한 거였고, 영업 입장에서는 납기만 맞추면 되는 일이었다. 그런데 개발 입장에서는 달랐다. 이 작은 흠이 고객 앞에서 문제라는 이름을 얻는 순간, 비용은 대개 돈이 아니라 사람에게 붙는다. 개발 한 명과 설치지원 한 명이 해외에 묶이고, 한 달이 사라진다. 그 한 달은 돈을 넘어선 비용이다. 체력과 책임과 관계가 깎여나간다.

공장으로 내려간 이유

그래서 우리는 공장으로 내려갔다. 문제를 고치기 위해서였지만, 실제로는 문제를 말하는 방식까지 함께 준비하는 일이었다. 원인 A는 이미 알고 있었다. 다만 A를 ‘해결’하자는 말은, 사실상 신제품을 다시 만들자는 말이 된다. 이번 출하 타임라인에서 가능한 건 근본대책이 아니라 당장 가능한 조치뿐이었다.

현장에 내려가자마자 논쟁이 시작됐다.

실무자들은 말했다. “최대한 덜 뜯고 가자. 뜯는 순간 더 망가질 수도 있어.”

파트장은 다른 언어를 썼다. “첫 출하에서 클레임 나면, 결국 우리가 간다. 한 달이다.”

나는 실무자 쪽에 가까웠다. 전수 해체는 고치려다 더 망가뜨리는 선택이 될 수 있었다. 하지만 이 불편함이 고객 앞에서 ‘문제’가 되는 순간, 그 말은 서류를 넘어서 사람을 움직인다. 그리고 그 사람은 대개 개발이다.

방향은 이미 정해져 있었다. 선배 실무자가 말없이 드라이버와 니퍼를 집었다. 볼트가 풀리고 조립 순서가 거꾸로 돌아가기 시작했다. 파트장은 일정 때문에 늦게 와서 잠깐 합류했다. 현장에 남은 사람들은 처음부터 끝까지 그 자리에 있었다. 밤이 길어질수록 손은 빨리 굳었다. 잦은 니퍼질로 손근육이 뭉치고, 뭉친 근육이 다음 조심성을 깎아먹었다. 그 피로는 어디에도 기록되지 않는다.

문제는 서류의 언어로 다시 태어난다

문제는 그 다음이었다. 현장에서 작은 흠을 줄였다고 해서, 조직에서 문제가 사라지는 건 아니다. 오히려 그 순간부터 문제는 ‘서류의 언어’로 다시 태어난다. 보고서에는 리스크를 리스크라고 쓰는 걸 꺼린다. 대책이 ‘대책처럼’ 보이지 않으면, 대책이 아니라는 판정을 받기 쉽다.

그래서 최종 보고서에서 A는 S가 되었다. A는 ‘지금 조건에서 드러나는 현상과 구조적 원인’이었고, S는 ‘지금 당장 할 수 있는 조치’였다. 보고서의 첫 줄에는 원인이 아니라 목적이 섰다. 신뢰성 확보. 고객요구 대응. 원인은 뒤로 밀렸다. 우리는 문제를 지운 게 아니다. 문제를 통과 가능한 형태로 번역했다. 이건 꼼수라기보다, 이 조직에서 일을 끝내는 방식이었다.

며칠 뒤, 정리된 내용을 품질에 올렸다. 개발품질은 현장에 내려와 그 작은 흠을 직접 보지 않았다. 출하품질이 확인한 내용을 보고받고 넘어갔다. 그 첫 반응은 현상이 아니라 문장이었다.

“조금 더 조리 있게 정리해오세요.”

재발방지도 당연히 따라왔다. 그 문장은 개인의 취향이 아니라 조직의 언어였다. 보고서는 위로 올라가야 하고, 위에서는 ‘이해되는 형태’여야 한다. 다만 그 순간 개발자는 알게 된다. 제품을 고치는 일보다, 문제를 말하는 비용이 더 크게 붙는 구조에서 “조리 있게”는 종종 해석이 아니라 포장을 뜻한다는 걸.

품질이 강해진 게 아니라, 문제를 말하는 비용이 강해진 거였다.

Gate가 결정을 돕는 문이 아니라 보고를 요구하는 문이 되는 순간, 리스크는 해결보다 ‘보고 가능한 형태’로 먼저 정리되고 그 정리 비용은 사람의 시간으로 지불된다.

여기서 질문이 달라졌다면 어땠을까. “근본원인 가져오세요” 대신, 더 앞에서 “지금 우리가 감수할 수 있는 리스크는 어디까지죠?”라고 물었다면. 그 질문은 마무리 단계의 질문이 아니라, 컨셉을 정하는 순간의 질문이어야 한다. 실무자가 밤에 니퍼를 잡는 대신, 의사결정자가 리스크를 안고 가는 방식으로.

회의록은 남는다. 개발 이력도 남는다. 다만 그 기록은 종종 ‘결정’이 아니라 ‘처리’를 남긴다. 누가 무엇을, 어디까지 감수하기로 했는지는 흐릿해지고, 대신 개발 이슈의 해결 주체만 또렷해진다. 그 틈에서 리스크는 해결로 관리되기 전에 ‘보고 가능한 형태’로 먼저 정리된다.

결정의 빈칸이 남아 있을수록, Gate에서 돌아오는 건 질문이 아니라 비용이다.

Gate는 그때 비로소 ‘문’이 아니라 비용 청구서가 된다.

그래서 A는 결국 S로 번역된다.