Skip to content
ioob.dev
Go back

소프트웨어 품질은 규모가 커질수록 죽는다 — 35명의 증언

Notes on Software Quality

원문 보기 · Anthony Hobday · Anthony Hobday ·
· 5분 읽기

품질이란 무엇인가

저자의 정의는 단순하다 — 품질은 문제의 부재다. 충분한 테스트와 전문가 검토를 거쳐도 문제가 안 나온다면 완벽에 가까운 셈이다. 다만 완벽은 도달할 수 없는 스펙트럼의 끝이고 현실에선 그쪽으로 얼마나 가까이 가느냐의 문제다.

품질은 진공에서 생기지 않는다. 리더십의 신념과 조직 문화가 품질을 살리기도 죽이기도 한다. 개발자·디자이너·PM, 때로는 CEO까지 품질을 값지게 여겨야 좋은 인터페이스가 나온다. 한 명이라도 “이 정도면 됐지”라고 생각하면 그 틈으로 품질이 샌다.

품질의 보편 신호와 소프트웨어 신호

저자는 모든 분야에 통하는 품질 신호를 먼저 든다 — 외양(공들인 티가 나는가), 연상(사회적 증거), 비용(더 투자한 것이 더 좋아 보인다), 성능(빠른가, 경험이 좋은가).

소프트웨어로 좁히면 여섯 가지다. 신뢰성(버그 없음), 속도(즉각 반응), 명료함(사용자가 이해하는가), 효능(할 일을 해내는가), 효율(쉽게 해내는가), 아름다움(미적으로 만족스러운가). 이 목록이 죄다 사용자 대면인 데다 “아름다움” 같은 주관적 항목이 섞였다는 게 뒤에 나올 반론의 표적이다.

규모가 품질을 죽이는 네 가지 메커니즘

이 글의 중심 주장이다. 규모가 커지면 품질이 어려워지는 정도가 아니라 불가능해진다.

증언과 사례

저자는 35명 넘는 업계 목소리를 인용해 “작은 팀이 큰 조직보다 일관되게 높은 품질을 낸다”는 패턴을 보인다. “디테일에 대한 집착은 팀 크기에 반비례한다”, 품질의 스윗스팟은 대략 30명 규모(엔지니어 5~10명, 디자이너 2명)라는 관찰도 나온다.

구체 사례도 든다. 스트라이프는 전담 품질 조직을 두고도 리더가 여전히 만족 못 한다고 인정한다. 피그마는 몸집이 커진 뒤 품질이 떨어졌다. 트위터·페이스북·인스타그램은 초고속 성장 이후 품질이 측정될 만큼 나빠졌다. macOS조차 수십 년 된 핵심 앱에 치명적 버그가 남아 시스템 차원의 부식을 드러낸다.

품질을 지키려는 회사들

규모의 문제를 인정한 회사들은 아예 전담 장치를 만든다 — Automattic의 최고품질책임자, GitLab의 “UX 종이베임(Paper Cuts)” 팀, Linear의 기능 개발을 멈추는 월간 ‘광내기 시즌’과 상시 ‘품질 수요일’, Shopify의 수평 품질 팀, 스트라이프의 “Head of Craft”, Zed의 연 2회 ‘품질 주간’. 성장 압력에서 품질을 구조로 지켜내지 않으면 안 된다고 인정한 셈이다.

종합

저자의 결론은 담담하다 — 품질은 이룰 수 있다. 다만 조직 차원의 분명한 헌신, 성장 압력에서 품질을 지켜낼 구조, 그리고 “규모는 결국 품질을 도달 범위와 맞바꾼다”는 사실을 받아들여야 한다. 큰 소프트웨어 조직에서 이건 풀리는 문제가 아니라 영구적이고 구조적인 제약이다.


Share this post on:

Comments

Loading comments...