테스팅 개관 (구글의 소프트웨어 엔지니어링)

게시일: 2025년 11월 22일 | 원문 작성일: 2020년 3월 12일 | 저자: Titus Winters, Tom Manshreck, Hyrum Wright | 원문 보기

요약

핵심 메시지: 자동화된 테스팅은 버그 방지뿐 아니라 코드를 자신감 있게 변경할 수 있게 해주는 경쟁력이에요
GWS 변혁: 2005년 위기에서 테스트 의무화 1년 만에 긴급 배포 50% 감소, 코드 변경 역대 최고치 달성
핵심 프레임워크: 테스트 크기 분류(Small/Medium/Large), 범위 피라미드(80% 단위, 15% 통합, 5% 종단간), 비욘세 규칙
문화 전략: 상향식 접근(Testing on the Toilet, Test Certified)이 하향식 명령보다 효과적
왜 중요할까요: 20억 줄 코드, 주당 2,500만 줄 변경, 15년 문화 진화를 통해 검증된 실전 가이드

역사적 배경: GWS 사례 연구

2005년: 위기

구글 웹 서버(Google Web Server, GWS)는 모든 구글 웹 트래픽을 처리하는 핵심 시스템이었어요. 하지만 심각한 문제에 직면했어요:

엔지니어들이 코드 수정을 두려워했어요
긴급 배포가 너무 자주 일어나서 생산성이 떨어졌어요
팀 사기가 바닥이었어요 (우수한 엔지니어들이었는데도)
체계적인 테스팅 문화가 없었어요

개입

리더들이 결단을 내렸어요: 모든 새로운 코드 변경은 테스트를 포함해야 한다. 초기 반발이 심했어요. 엔지니어들은 테스팅을 관료적인 부담으로 여겼어요. 하지만 리더들은 확고했어요.

2006년: 변화

의무화 1년 만에 놀라운 결과가 나타났어요:

긴급 배포 50% 감소
분기당 코드 변경 횟수가 역대 최고치를 기록했어요
팀 자신감이 급상승했어요
다른 구글 팀들이 자발적으로 테스팅을 도입하기 시작했어요

유산

이 성공 사례는 구글 내부에서 전설이 되었고, 회사 전체에 테스팅 문화를 확산시켰어요. 교훈: 뛰어난 엔지니어들도 대규모에서는 집단적으로 버그를 만들어요. 체계적인 테스팅은 선택이 아니라 필수 인프라예요.

핵심 프레임워크

1. 테스트 크기 분류 (코드 커버리지가 아님!)

구글은 테스트를 자원 소비와 실행 제약으로 분류해요:

크기	특징	제약조건	비중
Small	단일 프로세스, 결정적, 격리된(hermetic), 빠르고 가벼움	sleep/I/O/블로킹 사용 금지, 60초 이내 (강제: 5초)	80% 이상
Medium	다중 프로세스, localhost 네트워크 허용	외부 의존성 없음 (여전히 격리됨)	-
Large	다중 머신, 외부 리소스 접근 가능	제약 없음 (가장 느리고 불안정)	최소한

왜 크기가 중요할까요? 인프라가 제약을 자동으로 강제할 수 있어요. “small”로 선언된 테스트가 제약을 위반하면 즉시 실패해요—불안정성도 없고, 놀라움도 없어요. 이렇게 테스트 스위트에 대한 신뢰가 만들어지는 거예요.

2. 테스트 범위 피라미드

크기가 실행 제약을 나타낸다면, 범위(scope)는 코드 커버리지의 폭을 나타내요:

__MERMAID_UNDER_0__

범위	설명	비중	특징
단위 테스트	단일 함수/클래스	~80%	빠르고, 집중적이며, 실패 위치를 정확하게 파악 가능
통합 테스트	여러 상호작용 컴포넌트	~15%	시스템 간 계약 검증, 단위 테스트에서 놓친 이슈 탐지
종단간 테스트	사용자 인터페이스를 통한 전체 시스템	~5%	실제 사용 사례 검증 (느리고 불안정)

피해야 할 안티패턴:

아이스크림 콘 (역피라미드): 종단간 테스트가 너무 많고 단위 테스트가 적어요 (불안정하고 느려요)
모래시계: 단위 + 종단간 테스트는 많지만 통합 테스트가 적어요 (커버리지 격차 발생)

3. 비욘세 규칙 (The Beyoncé Rule)

“If you liked it, then you shoulda put a test on it.”
(마음에 들었다면, 테스트를 붙였어야지.)

실제 적용:

코드가 안정적으로 작동해야 한다면 테스트를 추가하세요
계속 디버깅하고 있다면 테스트를 추가하세요
변경하기 두렵다면 테스트를 추가하세요
비즈니스 핵심이라면 철저히 테스트하세요

결론: 안정적으로 작동할 필요가 없는 코드라면, 왜 필요한지 다시 생각해보세요.

4. 설계 피드백으로서의 테스팅

테스트를 작성하면 설계 문제를 미리 발견할 수 있어서 코드 품질이 좋아져요:

강한 결합: 테스팅에 복잡한 mock/setup이 필요하면 코드가 너무 결합되어 있다는 뜻이에요
불완전한 API: 테스트 작성이 어색하면 API 설계가 부실하다는 신호예요
불명확한 계약: 테스트가 혼란스러우면 프로덕션 코드도 혼란스러울 거예요
엣지 케이스 맹점: 테스트를 작성하면 실패 모드를 강제로 생각하게 돼요

“테스트는 API의 사용자이며, API의 첫 번째 사용자는 테스트여야 한다.”

5. 문서로서의 테스트

테스트는 항상 최신 상태를 유지하는 실행 가능한 문서예요:

의도된 사용 패턴을 보여줘요
에러 처리를 시연해요
엣지 케이스 동작을 명확하게 해요
일반 문서와 달리 절대 구식이 되지 않아요
CI/CD를 통해 강제할 수 있어요

문화 변화 전략

구글은 상향식 접근법으로 회사 전체에 테스팅을 도입했어요 (강제가 아니라 자발적으로):

1. 오리엔테이션 클래스 (진입점)

모든 신입 사원이 온보딩 중 테스팅 수업을 들어요
팀 배치 전에 기대치를 설정해요
공유된 언어와 관행을 만들어요
테스팅을 표준 관행으로 정상화해요

2. Test Certified 프로그램 (게임화)

팀을 위한 5단계 성취 레벨:

레벨	요구사항
레벨 1	기본 수준 (테스트 존재, 통과, CI에서 실행)
레벨 2	지속적 통합 설정
레벨 3	커버리지 및 신뢰성 임계값
레벨 4	고급 관행 (small 테스트 우세, 코드 리뷰 통합)
레벨 5	테스팅 우수성 (사고 리더십, 혁신)

구체적인 개선 경로를 제공해요. 팀들은 명성과 구체적인 혜택(인프라 접근, 도구 우선순위)을 위해 자발적으로 인증을 추구해요.

3. Testing on the Toilet (문화적 침투)

화장실 칸막이에 게시된 한 페이지 테스팅 팁이에요
재치 있고, 기억하기 쉬우며, 실행 가능한 조언을 담고 있어요
100% 엔지니어에게 유기적으로 도달해요
옵트인이 필요 없어요
예상외로 효과적인 문화 구축 도구예요

“친근한 접근이 정말 효과적이에요. 화장실 전단지로 위협받는 사람은 없잖아요. 새로운 아이디어를 소개하기에 완벽한 매체예요.”

왜 상향식이 승리했을까요? 하향식 명령은 저항과 형식적인 따르기만 만들어요. 자발적 채택은 관행을 전파하고 스스로 실천하는 챔피언을 만들어요. GWS가 가치를 입증했고, 문화가 유기적으로 확산되었어요.

확장 과제와 해결책

문제 1: 불안정한 테스트 (정당한 변경을 막는 문제)

증상:

리팩토링으로 수백 개의 테스트가 깨져요
테스트가 동작이 아닌 구현 세부사항에 결합되어 있어요
엔지니어가 테스트 실행을 건너뛰거나 비활성화해요

해결책:

구현이 아닌 동작을 테스트하세요
테스트 더블(mock/stub)을 최소화하세요
내부 구현이 아닌 계약을 검증하는 통합 테스트를 사용하세요
프로덕션 코드와 함께 테스트를 리팩토링하세요

문제 2: 느린 테스트 (전체 테스트 실행을 방해)

증상:

테스트 스위트 실행에 몇 시간이 걸려요
엔지니어가 부분 스위트만 실행하고, 실패를 놓쳐요
CI/CD 파이프라인의 병목이 돼요

일반적인 원인:

타이밍을 위한 과도한 __CODE_UNDER_0__ 호출
실제 데이터베이스/네트워크 I/O
시스템 초기화 오버헤드
중복 테스트 케이스

해결책:

격리된 테스트 환경을 사용하세요 (외부 의존성 없음)
실제 I/O 대신 가짜 구현을 사용하세요
공유 테스트 픽스처를 사용하세요 (적절한 경우)
중복 테스트를 적극적으로 제거하세요

문제 3: 지표로서의 커버리지 (굿하트의 법칙)

“측정이 목표가 되면, 좋은 측정이 아니게 된다.” - 굿하트의 법칙(Goodhart’s Law)

일어나는 일:

엔지니어가 백분율을 맞추기 위해 무의미한 테스트를 작성해요
커버리지가 최소 기준이 아니라 목표가 돼버려요
양은 증가하는데 품질은 떨어져요

구글의 접근법:

커버리지는 목표가 아니라 진단 도구예요
백분율이 아닌 테스트 품질에 집중해요
커버리지를 사용해 테스트되지 않은 핵심 경로를 찾아요
회사 전체 커버리지 의무화는 없어요

자동화 테스팅이 할 수 없는 것

정직한 한계:

정성적 판단: 검색 결과 품질, UI 미학, 사용자 경험 뉘앙스
창의적 문제 해결: 보안 취약점 발견, 창의적 엣지 케이스
탐색적 테스팅: “이렇게 하면 어떻게 될까?” 실험
사용성 평가: 실제 사용자 혼란, 워크플로 마찰

해결책: 자동화 테스팅을 인간 QA, 사용자 연구, 보안 리뷰, 탐색적 테스팅과 결합하세요. 인간이 이슈를 찾으면, 회귀 테스트를 자동화하여 재발을 방지하세요.

조직을 위한 실용적 조언

테스팅 문화를 시작하는 경우:

작게 시작하세요: 하나의 핵심 서비스를 선택하고, 새 코드에만 테스트를 의무화하세요
영향을 측정하세요: 사고, 배포 빈도, 엔지니어 자신감을 추적하세요
성공을 축하하세요: 성공 사례를 널리 공유하세요
신입 사원을 교육하세요: 테스팅을 첫날부터 기본 관행으로 설정하세요

테스트가 있지만 고통스러운 경우:

불안정성을 감사하세요: 리팩토링마다 깨지는 테스트는? 삭제하거나 재작성하세요
속도를 분석하세요: 테스트 스위트 실행을 프로파일링하고, 가장 느린 것을 제거하세요
크기를 강제하세요: small/medium/large 분류를 도입하고, 제약을 강제하세요
범위를 재조정하세요: 종단간 테스트에서 단위 테스트로 이동하세요 (피라미드)

성숙한 테스팅을 가진 경우:

자만하지 마세요: 정기적으로 테스트 품질을 재검토하세요
인프라에 투자하세요: 격리된 환경, 빠른 피드백 루프
지식을 공유하세요: 자체 “Testing on the Toilet” 같은 프로그램을 만드세요
지속적으로 개선하세요: Test Certified 레벨, 게임화, 인정

이 글이 중요한 이유

1. 권위

극한 규모에서 운영하는 엔지니어들이 작성했어요:

20억 줄 이상의 코드
주당 2,500만 줄 이상 변경
40,000명 이상의 엔지니어
15년 이상의 테스팅 문화 진화

이건 이론이 아니에요. 세계에서 가장 큰 소프트웨어 조직에서 실전으로 검증된 거예요.

2. 실용성

프레임워크를 즉시 적용할 수 있어요:

테스트 크기 분류를 모든 코드베이스에 구현할 수 있어요
범위 피라미드가 구체적인 비율을 제공해요
문화 전략이 스타트업부터 대기업까지 작동해요

3. 정직

테스팅의 한계와 트레이드오프를 인정해요:

모든 코드에 포괄적인 테스팅이 필요한 건 아니에요
커버리지 지표가 역효과를 낼 수 있어요
문화 변화가 기술 변화보다 어려워요

4. 역사적 서사

위기(2005년 GWS)에서 우수성(2020년 구글 전체)으로의 변화를 문서화해요. 엘리트 조직도 테스팅 도입에 어려움을 겪었다는 걸 보여주면서—다른 이들에게 희망과 로드맵을 제공해요.

크로스 도메인 통찰

심리학 & 행동 변화

상향식이 명령을 이겨요
게임화가 채택을 유도해요 (Test Certified)
환경 단서가 문화를 형성해요 (Testing on the Toilet)

경제학 & 자원 배분

테스팅은 비용이 아니라 투자예요
빠른 테스트는 복리 수익을 내요 (빠른 피드백 → 더 많은 반복)
불안정한 테스트는 마이너스 ROI예요 (유지보수 비용 > 혜택)

시스템 사고

테스트 인프라는 시스템 속성이지, 개인 책임이 아니에요
격리된 환경이 규모 확장을 가능하게 해요
피드백 루프가 효과적이려면 빨라야 해요

조직 설계

신입 사원 오리엔테이션이 장기 문화를 형성해요
자발적 인증이 챔피언을 만들어요
분산된 의사 결정(테스트 소유자)이 중앙 명령보다 확장성이 좋아요

결론

이 글은 구글의 테스팅 문화 형성 과정을 상세히 다룬 권위 있는 자료예요. 2005년 위기 상황에서 시작해 2020년 회사 전체의 테스팅 우수성으로 이어진 여정을 통해, 테스팅이 단순한 버그 방지가 아니라 변화를 이끄는 경쟁 우위임을 보여줘요.

핵심 교훈:

크기 분류 (Small/Medium/Large): 실행 제약으로 테스트를 분류하면 신뢰할 수 있는 테스트 스위트를 만들 수 있어요
범위 피라미드 (80-15-5): 대부분은 단위 테스트, 일부는 통합 테스트, 최소한은 종단간 테스트
상향식 문화: Testing on the Toilet, Test Certified 등 자발적 채택이 강제보다 효과적
비욘세 규칙: 중요한 것은 테스트하라

한국 기술 조직을 위한 시사점:

테스팅 문화는 하루아침에 만들어지지 않아요 (구글도 15년 걸렸어요)
작은 성공(GWS 사례)이 큰 변화를 촉발할 수 있어요
게임화와 재미있는 커뮤니케이션(화장실 팁)이 실제로 효과가 있어요
측정 지표(커버리지)를 목표로 삼으면 역효과가 발생해요

적용 가능성: 구글의 규모(20억 줄 코드)는 대부분의 조직과 다르지만, 원칙은 보편적이에요. 스타트업이든 대기업이든, 테스트 크기 분류와 범위 피라미드를 적용할 수 있어요.

이 글을 읽고 나면, 테스팅이 단순한 품질 보증이 아니라 소프트웨어 엔지니어링의 핵심 인프라임을 이해하게 될 거예요. 테스트가 잘 갖춰진 조직은 더 빠르게 움직이고, 더 자신감 있게 변경하며, 더 적은 사고를 경험해요.

“마음에 들었다면, 테스트를 붙였어야지.” — 비욘세 규칙을 기억하세요.

저자 소개: Titus Winters, Tom Manshreck, Hyrum Wright는 구글의 소프트웨어 엔지니어로, 수십 년간 극한 규모에서 운영한 경험을 가지고 있습니다.

참고: 이 글은 O’Reilly 출판사의 “Software Engineering at Google” 11장을 번역하고 요약한 것입니다.

원문: Testing Overview (Software Engineering at Google) - Titus Winters, Tom Manshreck, Hyrum Wright (2020년 3월 12일)

생성: Claude (Anthropic)

총괄: 존 (디노이저denoiser)