SE@Google

구글 엔지니어는 이렇게 일한다

발표: 개앞맵시(이복연)

​

구름 COMMIT (2023-06-21)�발표자료 최신/전체 원본

컴퓨터학과

출판 기획/편집

9+년

소프트웨어 엔지니어

10+년

* 40권 이상 출간

* 집필/번역 가이드

- http://bit.ly/2pHH9QG

시간 위를 걷는 프로그래밍

“저는 소프트웨어 엔지니어링이라는 용어에 막연한 거부감을 느끼며 살아왔습니다. ..중략..�이 책에서 소프트웨어 엔지니어링을 ‘시간 위를 걷는 프로그래밍’으로 정의한 표현을 읽는 순간 거부감이 사라졌습니다. 지금까지 중요하게 여기고 강조했던 많은 활동이 소프트웨어 엔지니어링에 해당했기 때문입니다.”

박재성 <우아한테크코스 총괄>

원서 제목 <Software Engineering at Google>이

<구글 엔지니어는 이렇게 일한다>로 번역된 이유

시간 위를 걷는 프로그래밍(Programming Over Time)

소프트웨어 엔지니어링: 코드를 작성하는 행위에 더하여,�시간의 흐름에 발맞춰 한 조직이 코드를 구축하고�유지보수하는 데 이용하는 모든 도구와 프로세스 포괄

​

시간이 흐르면 → 변경 발생, 규모 증가, 조직 성장

아키텍처 설계, 코딩 시 이러한 변화에 따른 비용과 트레이드오프를 고려해 의사결정

개발자께서 “안 돼”라고 말씀하셨다

개발자들이 매번 안 된다고 말하면서�쪼으면 결국 해내는 이유는?

​

소프트웨어 엔지니어링

쪼을수록 프로그래밍에 집중하고

이 일들을 생략하고 진행하기 때문!

주인을 찾습니다

소프트웨어 엔지니어링을 올바르게 이해하고,�적어도 거부감은 갖지 않았으면..

소프트웨어 엔지니어?

개발자(디벨로퍼)?

프로그래머?

코더?

→ 소프트웨어 엔지니어임을 자각하고

→ 소프트웨어 엔지니어링을 주도해야

제대로 일하고 성장할 수 있다!!

오늘 발표 목표

1. SE에 대한 오해 풀기
2. SE의 주도권을 찾아와야 제대로 일하고 성장할 수 있음을 알리기
3. 구글은 무엇이, 왜 다르고, 어떻게 달라질 수 있었는지 논의하기
4. 개발 문화 개선에 동참하는 팁 전달하기

발표 구성

​

​

​

​

​

​

​

​

​

​

​

0. 구글은 다르게 일한다
1. 무엇이 다른가?
2. 왜 달라야 했나?
3. 어떻게 달라질 수 있었나?
1. 소프트웨어 엔지니어링이란?
2. 문화
3. 프로세스
4. 도구
5. 덧붙여서..

A. 주니어와 개발 문화

0부. 구글은 다르게 일한다

- 무엇이 다른가?

- 왜 달라야 했나?

- 어떻게 달라질 수 있었나?

구글은 무엇이 다른가?

예시 1 - 코드 리뷰

예시 2 - 버전 관리와 브랜치 관리

예시 3 - 문서자료도 코드처럼

예시 4 - 테스트 스위트 분류

예시 5 - 빌드 시스템

예시 6 - 내부 개발도 오픈소스st

접근, 버그 패치, 심지어 기능 추가까지 OK

예시 7 - 비욘세 규칙

적용: B팀이 CI에 등록해둔 테스트가 모두 통과한다면�→ 문제해결은 전적으로 B팀 책임�→ A팀은 CI만 믿고 계속 개발

상황

​

​

​

• A팀의 제품에 B팀 제품이 의존
• A팀이 수정 후 B팀 제품 오동작

​

비욘세 규칙

“네가 진심으로 좋아했다면 반지를 줬어야지”�- <싱글 레이디스> 가사 중�

​

누구 책임??

�해석: “너에게 중요한 기능이었다면 테스트를 준비했어야지”

왜 달라야 했나?

소프트웨어 개발 생태계가 달라졌기 때문

• 소프트웨어 규모, 복잡도, 수명이 꾸준히 증가
• 참여 인력 증가
• 배포 방식 변화
• 패키지 → 라이브 서비스
• 배포 대상 종류 및 수 증가
• PC, 스마트폰, 태블릿,�스마트워치, 자동차, VR, ..
• OS 버전별 대응
• ..

→ 기존 틀에 갇혀서는 변화하는 환경에서 경쟁력을 유지할 수 없음

어떻게 달라질 수 있었나?

끊임없는 변화의 원동력

• 소프트웨어의 지속 가능성을 항시 염두에 두고�엔지니어가 변화를 주도하는 문화 조성�(★ 소프트웨어 엔지니어링의 주인은 소프트웨어 엔지니어다!)�
• 인내심을 가지고 천천히, 꾸준하게�→ 강제보다는, 스스로 느끼고 따르도록 유도
• 심리적 안전을 토대로�소통하고 함께 배우는 문화 조성
• 겸손, 존중, 신뢰 위에 위대한 팀 만들기

(★ 우리가 어떻게 일해야 하는가는 우리가 고민하여 발전시켜야 한다!)

이제부터 책 내용을 중심으로

중요한 주제를 몇 가지 살펴보겠습니다.

책의 구성

1부. 소프트웨어 엔지니어링 (1장)

2부. 문화 (2~7장)

팀워크, 지식 공유, 공정 사회,

팀 리딩, 조직 성장, 생산성 측정

3부. 프로세스 (8~15장)

스타일 가이드, 코드 리뷰,

문서자료, 테스트, 폐기

프로그래밍

​

(다루지 않음)

거의 모든 조직 공통

개발 조직 이야기

구글 특화 내용

다수 포함

1부. 전제

1장. 소프트웨어 엔지니어링이란?

1장. 소프트웨어 엔지니어링이란?

소프트웨어 엔지니어링과 시간

1장. 소프트웨어 엔지니어링이란?

프로그래밍 소프트웨어 엔지니어링

​

​

​

​

�

개발

시간

개발

개념: 흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것�(programming integrated over time)

목표: 기대 생애 동안 요구되는�모든 가치 있는 변경에 대응할 수 있는�지속 가능한 소프트웨어 작성

1.0

2.0

1.1

1.2

규모를 확장할 수 있는 소프트웨어가 되려면?

1장. 소프트웨어 엔지니어링이란?

�

• 커진 프로젝트 규모 만큼의 인력만 추가로 투입하면 해결될까?
• 연산, 메모리, 스토리지, 대역폭 등 컴퓨트 파워를 추가하는 만큼 처리량도 증가하나?
• 빌드 시간이 개발 흐름을 방해하지 않는 수준으로 유지되는가?
• 리포지터리의 코드를 내려받고 수정하고 통합하는 시간은?

단기적 개발 능력뿐 아니라�여러 비용 요인들을 종합적으로�모니터링하고 개선해야 함

규모가 확장돼도 효율성을 유지하려면?

1장. 소프트웨어 엔지니어링이란?

• 전문성: 여러 방법에 대한 충분한 지식 쌓기
• 안정성: 짧고 규칙적인 릴리스로 릴리스 사이의 변경량 줄이기(Faster is safer!)
• 순응: 거의 모든 코드가 업그레이드를 경험해봄
• 익숙함: 정기적으로 업그레이드하는 과정에서 중복 작업을 찾아 자동화하기
• 정책: 비욘세 규칙과 같은 유용한 정책과 절차 갖추기

★ 100m 달리기만 해서는 마라톤을 뛸 수 없다. 엔지니어들에게 지구력도 함께 키울 여유를 주자.

변경 비용을 줄이려면

1장. 소프트웨어 엔지니어링이란?

비용 요인: 금융 + 리소스 + 인적 + 거래 + 기회 + 사회적 비용

​

창의력이 핵심인 분야에서는 인적 비용이 가장 큼

→ 엔지니어들이 행복을 느끼고

일에 집중하고 능동적으로 참여할 수 있게 해줘야 함

프로그래밍 vs. 소프트웨어 엔지니어링

1장. 소프트웨어 엔지니어링이란?

프로그래밍: 코드를 생산하는 즉각적인 행위

소프트웨어 엔지니어링: 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케 하는 정책, 관례, 도구 모두를 아우르는 종합 개념

그래서 소프트웨어 엔지니어링이..

그래서 준비했습니다.�

평범한 한 엔지니어가 ‘더 나은 개발자를 꿈꾸며’ 걸어온 길을 SE 관점에서 따라가 보겠습니다.

알듯 말듯 한데, 구체적인 예는 없나요?

제 삶 속에서의 소프트웨어 엔지니어링 (Link)

프로그래밍

프로그래밍

프로그래밍

프로세스

프로세스

도구

프로세스

도구

프로세스

문화

도구

도구

문화

생각해보기

​

​

​

​

​

​

​

​

​

​

​

1. 내가 알던 SE와 같은가?�(오해하고 있지는 않았나?)
2. “소프트웨어 엔지니어로서 제대로 일하고 성장하려면�SE가 제대로 이루어져야 한다”라는 말에 공감하는가?
3. SE의 주인은 누가 되어야 한다고 생각하나?

2부. 문화

2장. 팀워크 이끌어내기

3장. 지식 공유

4장. 공정 사회를 위한 엔지니어링

5장. 팀 이끌기

6장. 성장하는 조직 이끌기

7장. 엔지니어링 생산성 측정하기

2장. 팀워크 이끌어내기

팀워크가 왜 중요인가?

2장. 팀워크 이끌어내기

소프트웨어 개발 = ‘팀의 단합된 노력’

But 사람 = 간헐적 버그들의 집합�

​

훌륭한 소프트웨어 엔지니어는 기술뿐 아니라�사람까지 잘 이해해야 한다.

동료와 나 자신

종종 실수를 하며

그마저도 일관되지 못하다.

천재 vs. 팀

2장. 팀워크 이끌어내기

▼ 천재 신화 예시

• 진실
• 위대한 업적은 결국 팀이 이루어냄

모든 건 팀에 달렸다

2장. 팀워크 이끌어내기

초월적인 업적 대부분 위대한 팀이 이루어낸다. 비전을 공유하고, 역할을 나누고, 다른 이로부터 배우며 멋진 팀을 만들자.

​

• 겸손(humility) : 당신은 모든 것을 알지도, 완벽하지도 않다. 겸손한 사람은 배움에 열려 있다.
• 존중(respect) : 동료를 진심으로 생각한다. 친절하게 대하고 그들의 능력과 성취에 감사해한다.
• 신뢰(trust) : 동료들이 유능하고 올바른 일을 하리라 믿는다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋다.

​

★ 신뢰가 거저 주어지지는 않는다.�

• 신뢰할 수 있는 사람 뽑기
• 신뢰가 지속될 수 있게 꾸준히 노력하기
• 신뢰할 수 있는 사람으로 키워내기

겸손, 존중, 신뢰 실천하기

2장. 팀워크 이끌어내기

• 자존심 버리기
• 자존심 ≠ 자신감
• 개인의 자존심보다 집단적 자존심을 높이려 노력하자(팀의 성취와 단체의 자부심).
• 비평하고 비평받는 법 배우기
• 선의의 비평이라도 사전 조율과 공감 없이는 맹렬한 공격이 될 수 있다.
• 동료를 존중하며 건설적이고 공손하게 비평하는 법을 배워야 한다.
• 전문적인 제도와 문화가 큰 도움이 된다.�(예: 코드 리뷰, 멘토링, 오피스 아워)
• 빠르게 실패하고 반복하기
• 실패를 ‘배우고 다음 단계로 넘어갈 수 있는 절호의 기회’로 생각하는 문화 필요

3장. 지식 공유

지식 공유 = 함께 자라기

3장. 지식 공유

지식이 제대로 공유되려면?

• 전문가
• 지식 전파 메커니즘
• 사내 위키, 기술 블로그, 메일링 리스트, 스터디 그룹, 오리엔테이션 수업, ..
• 배움의 문화

왜 공유하는가?

• 초심자를 전문가로 키워내기
• 조직 규모와 문화에 적합한 지식 공유 방법 찾기
• 조직 성장에 부응하는 확장성 갖추기
• 초기의 전문가들이 빠져도 잘 굴러가는�팀/프로젝트 만들기

배움을 가로막는 장애물

3장. 지식 공유

심리적 안전이 가장 중요

3장. 지식 공유

심리적 안전

• ‘모른다고 인정하는 게 부끄럽지 않다.’
• ‘모른다는 게 알려져도 불이익이 없다.’

시니어의 걱정

• 내 경력이 얼만데,�모른다고 말하면 우습게 보겠지?
• 그동안 쌓아 온 내 이미지가 있는데..
• 괜히 말했다가 경쟁에서 밀리는 거 아냐?
• ..

주니어의 걱정

• 일단 자신 있게 얘기했는데,�이제와서 모른다고 하면 안 되겠지?
• 왠지 나만 모르는 분위긴데..
• 저번에 괜히 물어봤다가 한 소리 들었는데..
• 어디까지 알아보고 질문해야 하지?
• ..

대답하는 자세가 중요

3장. 지식 공유

모르는 게 많은 건 당연하다!

• 소프트웨어 개발은 광활하고 급변하는 세계다.
• 서로 걸어온 길이 다르므로�배우고 경험한 것도 제각각이다.
• 시니어라 해도, 고작 몇 년 차이로�대부분 영역에서 더 뛰어나긴 어렵다.

저번에도 말씀드렸다시피..

당연히 아실 줄 알았는데..

• 단점보다 장점을 보자.
• 나부터 잘 답해주자.

→ 나와 같은 사람이 한 명 두 명 늘다 보면

금세 팀 분위기가 달라질 것이다.

질문에도 노하우가 필요

3장. 지식 공유

5장. 팀 이끌기

소프트웨어는 결국 ‘사람’이 ‘모여’ 만든다

5장. 팀 이끌기

• 사람 = 앞에서 이야기한 팀의 구성과 문화를 궁극적으로 책임져야 할 주체
• 사람들을 조화시켜 일을 완수하려면..�→ 누군가는 리더를 맡아야..

어떤 사람이 리더가 되어야 하느냐…

5장. 팀 이끌기

팀원(개인 기여자) 역할

• 설계
• 코딩
• 문서화
• 디버깅
• ..

리더 역할

• 팀에 활기 불어넣기
• 생산성 높이기
• 팀 섬기기(섬기는 리더십)
• 겸손, 존중, 신뢰 분위기 조성
• 사회적 건강 관리
• 팀원 멘탈 케어, 동기 부여, 팀원 간 갈등 중재, ..
• 기술적 건강 관리
• 필요한 기술/인프라 확보, ..
• …

필요한 역량이

굉장히 다름

★ 경영진은 이 차이를 잘 고려하여 리더를 발탁해야..

★ 리더로 성장하고 싶다면�사회적 스킬도 갈고 닦고 어필해야..

리더의 종류와 역할 @ 구글

5장. 팀 이끌기

엔지니어링

관리자

테크 리드

리더십, 코칭, 멘토링에 관심 많음

(기술, 코드 < 사람, 제품)

‘관리자’ 트랙

실무와 기술적 전문성 추구

(사람, 제품 < 기술, 코드)

‘기술 전문가’ 트랙

<테크 리드>

<엔지니어링 관리자>

(Link)

vs.

• 팀/프로젝트 계획
• 목표 설정, 성과 산출, 피드백
• 생산성 개선
• 팀 빌딩과 문화 조성(겸손, 존중, 신뢰)
• 팀원 경력 성장 계획 및 코칭
• 팀 보호
• 사회적 건강 관리(팀원 행복 증진, 멘탈 케어, 동기 부여, 갈등 중재 등)
• 기술적 결정에 참여
• 실무 코딩(~30%)
• 필요 시 테크 리드 역할 수행

• 주요 기술적 결정
• 기술적 우수성과 혁신 촉구
• 아키텍처링과 시스템 설계
• 팀의 기술 포트폴리오 관리
• 기술 역량 확보 계획
• 필요한 플랫폼과 인프라 확보
• 패턴, 규약 발굴 및 내재화
• 코드 리뷰
• 제품 품질 보장
• 실무 코딩(30~70%)
• 필요 시 엔지니어링 관리자 역할 수행

• 개발 프로세스 정립 및 실행
• 팀 전체의 적극적 참여 촉진
• 인력 확충 계획 및 고용

성공적인 리더가 되기 위한 조언 1

5장. 팀 이끌기

안티패턴

• 만만한 사람 고용하기
• 저성과자 방치하기
• 사람 문제 무시하기
• 만인의 친구 되기
• 채용 기준 타협하기
• 팀을 어린이처럼 대하기

올바른 패턴

• 자존심 버리기
• 마음 다스리기
• 촉매자 되기
• 장애물 치우기
• 선생이자 멘토 되기
• 명확한 목표 세우기
• 정직하기
• 행복한지 확인하기

성공적인 리더가 되기 위한 조언 2

5장. 팀 이끌기

구글이 리더에게 권장하는 그 외 조언과 요령

• 위임하되, 곤란한 일은 직접 처리
• 여러분을 대신할 사람 찾기
• 파도를 일으켜야 할 타이밍 알기
• 혼란으로부터 팀을 보호
• 팀에 공중 엄호
• 팀이 잘하고 있다면 칭찬하기
• 실패해도 쉽게 되돌릴 수 있는 일에는 ‘해보세요’라고 말하기

동기 부여 (TED 강연)

• 내적 동기 부여 방법
• 자율성(주도성) 부여
• 목적(일의 의미) 인식
• 숙련(전문성 향상 → 성장) 기회 제공

더 읽어보기

​

발표 관련 참고가 될만한 주제를 브런치(brunch.co.kr/@wegra)에 추가로 정리하고 있습니다.�

• 엔지니어링 관리자 vs 테크 리드
• 수평적 문화로 가는 길
• 조직 바꾸기 실패/성공 사례 모음
• 조직 문화 바꾸기
• (멘탈 부여잡고) 좋은 문화 뿌리내리기
• 더 나은 개발자를 꿈꾸며 걸어온 길
• 한국 개발 문화 vs 구글 개발 문화. 구글의 특별함?
• 직원 성장과 행복 KPI(행복 OKR?)
• ..

3부. 프로세스

8장. 스타일 가이드와 규칙

9장. 코드 리뷰

10장. 문서자료

11장. 테스트 개요

12장. 단위 테스트

13장. 테스트 대역

14장. 더 큰 테스트

15장. 폐기

구글의 개발 워크플로

코드�리뷰

코드 리뷰

편집

컴파일

디버그

서브밋

릴리스

후보

(RC)

프로덕션

빠르고 안정적인 테스트

+ 느리고 덜 결정적인 테스트

정적 분석

단계별 RC 승격

리뷰어 역할�구분

가독성 인증�제도

변경 생성

스타일 가이드,�규칙,�지침

작은/중간 크기/큰 테스트

지속적 배포

지속적 빌드

다른 엔지니어,�코드 소유자,�가독성 인증자

+ (승격 때마다) RC 전체를�광범위하게 검증하는 테스트

9장. 코드 리뷰

코드 리뷰 이점

9장. 코드 리뷰

코드 정확성 검증

코드 이해 용이성 향상

코드 일관성 향상

심리적, 문화적 이점

지식 공유

변경 이력 기록

• 코딩 = 소프트웨어 엔지니어 핵심 역량
• 코드 수준에서 양방향 대화할 수 있는 거의 유일한 수단
• 소프트웨어 엔지니어 역량 상향 평준화

• ‘코드 = 조직의 공동 소유물’임을 인식
• 비판적 피드백을 중립적으로 중재
• 코드 리뷰 프로세스 = 나쁜 경찰
• 리뷰어 = 좋은 경찰
• 자가 검증 기회 제공

9장. 코드 리뷰

코드 리뷰 성공

프로세스

도구(Critique)

• 정적 분석 + 테스트 자동 실행

• diff, 정적 분석, 테스트 결과 표시
• 리뷰어에게 메일 전송

• 댓글, 코드 편집 등 피드백 기능 제공

• 승인 통지

• 프리서브밋 테스트 수행
• 통과 시 커밋 완료

리뷰어 선정 지원

• 다른 엔지니어
• 코드 소유자
• 가독성 인증자

리뷰어 역할 @ 구글

9장. 코드 리뷰

• 3가지 역할 + 분산된 소유권 구조
• 다양한 운영 방식 지원
• 코드 리뷰의 확장성 증가

1. 다른 엔지니어(주로 팀원): 작성자가 의도한 작업을 코드가 적절하게 수행하는가? (정확성, 이해 용이성)�
2. 코드 소유자(주로 테크 리드 or 해당 기술 전문가):�체크인해도 될 만큼 변경 코드가 적절한가?�(like 오픈 소스 프로젝트의 커미터)�
3. 가독성 인증자: 해당 언어의 표준 스타일과 모범 사례를 잘 따르는가?�

가독성 인증자 양성과 효과

9장. 코드 리뷰

• 엔지니어들에게 소속 팀에서 통용되는 현장 지식 이상을 전달
• 구글 코드에서 따라야 하는 일관된 표준을 ‘모든’ 엔지니어에게 전파
• 프로그래밍 언어별로 인증

​

가독성 인증 프로세스

변경 목록 제출

가독성

리뷰어

그룹

코드 리뷰 모범사례

9장. 코드 리뷰

​

공손하고 전문가답게

작게 변경하기

변경 설명 잘쓰기

가능한 한 자동화

리뷰어는 최소한으로

• 작성자와 리뷰어 모두에게 배움의 기회
• 작성자의 방식 존중: 결함이 있을 때만 대안 제시
• 잘못되었다고 가정하기 전에 그렇게 처리한 이유 묻기
• 빠른 응답

• 모두 구분 : 기능 추가, 동작 변경, 가독성 개선, 최적화, 버그 수정

코드 리뷰, 이렇게 시작해보세요 (분할 정복)

9장. 코드 리뷰

팀 단위

• 좋은 코드에 대한 스터디
• → 이해 증진, 공감대 형성
• <클린 코드>, <좋은 코드. 나쁜 코드>, <리팩터링>, <디자인 패턴의 아름다움> 등
• 유명한 코딩 스타일 가이드

• 코드 포맷터, 정적 분석 도구 도입
• 검사 항목을 점차 늘리며 적용
• 사내 표준 외,�개발자별로 1개씩 더 활용�→ 코드 리뷰에 활용

• 테크 리드 주도
• 패턴, 규약 발굴 및 내재화
• 테스트 품질 개선 노하우 포함

• 4장. 개발 환경을 고려한 코드 작성
• 5장. 피할 수 없는 코드 의존성의 관리
• 6장. 테스트! 개발자의 든든한 지원군
• 7장. 올바로 주고받는 코드 리뷰

코드 리뷰, 이렇게 시작해보세요 (분할 정복)

9장. 코드 리뷰

팀 단위

• 좋은 코드에 대한 스터디
• → 이해 증진, 공감대 형성
• <클린 코드>, <좋은 코드. 나쁜 코드>, <리팩터링>, <디자인 패턴의 아름다움> 등
• 유명한 코딩 스타일 가이드

전사 단위

• 적절한 팀 선정
• 프로젝트 성격, 상황, 인력 구성 고려
• (왼쪽의) 팀 단위 활동을 비중 있게 수행
• 시행착오 및 노하우 정리
• 다른 팀 전파 시 가이드 및 지원

• 코드 포맷터, 정적 분석 도구 도입
• 검사 항목을 점차 늘리며 적용
• 사내 표준 외,�개발자별로 1개씩 더 활용�→ 코드 리뷰에 활용

• 테크 리드 주도
• 패턴, 규약 발굴 및 내재화
• 테스트 품질 개선 노하우 포함

가독성 인증자 양성

• 관심과 능력이 있는 인력 소수 모집
• 서로의 코드 리뷰로 일관성 확보
• 한 프로젝트씩 시범 적용

11장. 테스트 개요

구글의 테스트 스위트 분류 1

11장. 테스트 개요

분류 고려 기준

• 크기: TC 1개 실행에 필요한 자원
• 범위: 검증하려는 특정 코드 경로

분류

• 작은 테스트: 프로세스 하나에서 동작
• 중간 크기 테스트: 기기 하나에서 동작
• 큰 테스트: 자원 제약 없음

작은 테스트

• 주요 제약
• 프로세스(혹은 스레드) 하나만 사용
• 테스트와 대상 코드가 같은 프로세스에서 실행
• sleep, I/O 등 블로킹 호출 금지
• 네트워크, 디스크 접근 불가
• 특성
• CPU에서만 실행 → 빠름
• 비결정적 요인 제거 → 결과가 안정적

​

확실한 피드백을 빠르게 전달

구글의 테스트 스위트 분류 2

11장. 테스트 개요

중간 크기 테스트

• 여러 프로세스/스레드 활용 가능
• 로컬 호스트와의 네트워킹 등 블로킹 호출 가능�→ 유연성 up, 비결정성 up

큰 테스트

• 제약 없음 → 유연성 up, 비결정성 up
• 용도 한정
• 종단간 테스트
• 테스트 대역 사용 불가한 레거시 컴포넌트 테스트

작은 테스트가 중요한 이유

11장. 테스트 개요

구글의 규모

• 매주 약 25,000,000 라인 변경
• 절반은 엔지니어로부터, 절반은 자동화 시스템으로부터
• 수십억 개의 테스트 케이스 실행�
• 변경 대부분이 프로젝트 ‘외부’에서 촉발
• 접근 제약이 거의 없음�
• 모두 헤드^head에 직접 커밋
• 변경 즉시 모두에 영향을 줌
• 모든 제품이 테스트 인프라가 검증한 가장 최신 커밋까지 반영해 빌드

(구글이 아니더라도)�소프트웨어의 규모와 수명은 계속 늘어가는 추세�→ 테스트 범위와 상관 없이� 작은 테스트로 작성 권장

변경 생성

빠르고 안정적인 테스트

정적 분석

테스트 품질 개선과 정착을 위한 노력

11장. 테스트 개요

• 오리엔테이션 수업�
• 테스트 노하우 발굴 및 전파
• 화장실에서도 테스트 (Link)

​

• pH(프로젝트 건실성)
• 지표 수십 가지를 지속 수집하여 종합
• 테스트 커버리지, 테스트 지연시간, ..
• 지속적 빌드 인프라에서 자동 수집
• 건실성을 1~5 사이 수치로�(개선 사항, 방법과 함께) 알려줌

• 테스트 생활화
• 테스트 누락 시 코드 리뷰 거절 가능

기억할 점

​

• 한두 가지 지표로 판단하지 않는다.
• 엔지니어의 편의와 엔지니어에게 실질적인 도움이 되는 길을 모색한다.
• 테스트 문화를 바꾸는 데는 시간이 걸린다.

4부. 도구

16장. 버전 관리와 브랜치 관리

17장. Code Search

18장. 빌드 시스템과 빌드 철학

19장. Critique: 구글의 코드 리뷰 도구

20장. 정적 분석

21장. 의존성 관리

22장. 대규모 변경

23장. 지속적 통합

24장. 지속적 배포

25장. 서비스형 컴퓨트

구글의 도구들

리포지터리

Piper

모노리포

‘20억+ 라인’ 코드

하루 수만 건 커밋

​

트렁크 기반 개발

원-버전 규칙 준수

시간 흐름과 S/W·조직 규모 확장에�어떻게 대응하는가?

5. 덧붙여서

A. 주니어와 개발 문화

1. 주니어와 개발 문화

(멘탈 부여잡고) 좋은 문화 뿌리내리기 (Link)

같은 편 되기: 내게 이롭더라도 싫어하는 사람이 추진하는 일에는 협력하기 싫은 게 인지상정.�→ 내가 무언가 추진하려면 상대가 나를 같은 편으로 생각해야..

공감 끌어내기: 공감되지 않은 일에 내 시간을 쓰지 않음. 혹은 시늉만 함.�→ 함께 변해야 할 사람들이 공감해야 추진력이 생김.

실패하고 다듬기: 문화, 즉 사람을 바꾸는 일을 한 번의 실패도 없이 성공하기는 거의 불가능.

우선순위

1. 조직의 변화에 적극 동참하자

• 변화가 목표하는 ‘선한’ 의도 파악
• 피드백은 부드럽게
• 이점 적극 활용

한편, 조직 차원의 변화를 주니어가 주도하기는 어려움

• 결정권자는 결국 책임자

2. 그렇다면

• 옵션 1: 자신의 변화부터 주도
• 옵션 2: (정말 간절한 변화라면)� 한 계단 윗 사람 포섭

옵션 1: 자신의 변화부터 주도

• 개발 역량 키우기
• 새로운 기술, 도구, 프레임워크 등
• 리팩터링, 테스팅, 구조/인터페이스 설계 등�
• 사회적 영향력 키우기
• 스터디, 커뮤니티 활동
• 유튜브, 블로그 등�
• 흥미 유지하기
• 적절한 휴식, 건강 챙기기
• 토이 프로젝트

⇒ 서서히 신뢰가 쌓이고 영향력이 커짐

⇒ 변화를 주도할 기회가 왔을 때� 성공 확률 증가

옵션 2: 한 계단 윗 사람 포섭

(한 계단 윗 사람 = A)

방법:

1. A의 공감 끌어내기
2. A가 주도하게 한 후,
3. 나는 A를 적극 지원

→ 내가 주도할 때보다 성공 가능성 up

주의점

• 평소 A와의 관계가 돈독해야 가능
• A가 주도하는 순간,�나의 생각과 100% 일치하지는 않음
• 변화 성공의 공은 A에게

비중 이동: 스펙 쌓기 → 신뢰 쌓기

스펙: 상대에 대한 신뢰가 없을 때 중요

• 주로 사회 초년생, 주니어 이직자

연차가 쌓일수록 인맥으로 이직/팀 이동

• 인맥 = 그 사람에 대한 신뢰
• 신뢰: 실력, 마인드, 리더십 등�함께 일하면서 쌓인 종합 이미지�
• 신뢰가 있다면,�→ 변변한 스펙 없이도 오라는 곳 많음�
• 신뢰가 없다면,�→ 전공과목 복습, 코딩 인터뷰 준비부터 다시 시작해야..

• 경력자의 스펙에서는
• 거쳐온 회사, 프로젝트가 추가�→ 문닫은 회사, 평판 나쁜 프로젝트는 오히려 마이너스

★ 현재 프로젝트, 함께 일하는 동료에게 소홀하지 말자!

(마지막으로) 끊임없는 변화의 원동력

• 소프트웨어의 지속 가능성을 항시 염두에 두고�엔지니어가 변화를 주도하는 문화 조성�(★ 우리가 어떻게 일해야 하는가는 우리가 고민하여 발전시켜야 한다!)�
• 인내심을 가지고 천천히, 꾸준하게�→ 강제보다는, 스스로 느끼고 따르도록 유도
• 심리적 안전을 토대로 소통하고 함께 배우는 문화 조성
• 겸손, 존중, 신뢰 위에 위대한 팀 만들기

Q1. ‘프로그래머’, ‘개발자’, ‘엔지니어’라는 명칭의 차이가 있다고 생각하나?

• 현장에서 딱히 구분하지 않고,�굳이 나눠서 얻는 이득도 X�
• 어떻게 부르든�함께 일하고 오래 살아 남으려면�프로그래밍뿐 아니라 문화, 프로세스, 도구까지 모두 신경 써야..

Q2. 성공적인 개발팀 리더로 성장하길 원하는 사람을 위해 추천하는 책, 강의 등의 자료가 있다면?

• 다양한 주제로 시야를 넓히고 꾸준하게 공부해야
• 예: 조직 관리, 리더십, 동기부여, 심리학, 대화법, 질문법 등
• 각자가 경험한 게 다르고, 처한 상황도 다름
• 무엇보다 사람은 단 몇 가지 잦대로 규정하기엔 너무 복잡�
• 한편! 공부를 하더라도, 내가 부족한 게 뭔지부터 알아야..
• 주변인들로부터 냉정하게 피드백받는 방법 고민 & 수행�(내가 생각하는 나와 전혀 다를 수 있음)

Q3. 신입 개발자에게 해주고 싶은 조언이나 공부법이 있다면?

• 이게 바로 조직의 리더들이 해줘야 할 일
• 성장 계획은 엔지니어링 관리자와 함께
• 기술적 조언은 테크 리드가..�
• 회사에서 쓰는 기술 스택 파악
• 회사 리더에 조언 부탁
• 토이 프로젝트로 관련 신기술 체험

(참고) 개발 분야별 로드맵: https://roadmap.sh

Q4. 단 하나의 개발 문화를 도입한다면?

코드 리뷰

Q5. 관성에 젖은 개발자들의 저항을 극복하여 좋은 문화를 뿌리내리려면?

• 극복해야 할 대상이 아닌,�‘함께 가야 할 대상!’이라는 생각의 전환 필요
• 할 수 있는 만큼씩 꾸준히 개선하여,
• 더 좋아지는 모습을 실제로 보여주기�
• 그러면 관심을 보이며 조금씩 마음을 열 것임!

Q6. 가장 재미 있던 팀 스터디는?

• 흥미 있는 주제별 온라인 강의 수집
• 정기적으로 모여 청취 후 토론

​

• 준비 노력 최소화(부담 없이 참여)
• 어설프게 우리끼리 나눠 준비하는 것보다 강의 품질 우수�
• 그날 주제에 대해 좀 더 아는 멤버 있으면 좋음
• 혹은, 가능하다면 그때그때 주변인 중 주제 전문가 초빙

Q7. 한국의 개발 문화에 적용하기 어려운 부분은?

• 크게 없음
• 다만, 상황에 대한 깊은 고민 없이 따라 하려고만 하지 않으면..�
• 다음 브런치 글 참고 ( brunch.co.kr/@wegra )
• ‘한국 개발 문화 vs 구글 개발 문화. 구글의 특별함?’
• ‘[조직 문화] 수평적 문화로 가는 길’

Q8. 구글의 테스트 커버리지 기준은?

• 크게 중요하지 않음
• 커버리지를 강조하면 목표치가 아닌 최대치로 작용하기 때문
• 그래서 테스트 관련 수십 가지 지표 중 하나일 뿐
• 대신 다양한 정책을 종합적으로 운용
• 깨뜨려보고 싶은 모든 것을 테스트하도록 장려
• 동작 정확성, 성능, 접근성, 보안, 실패 시 대처 능력 등
• 테스트 누락 시 코드 리뷰 거절
• 비욘세 규칙

Q9. 다른 신입 개발자와 차별화되는 신입 개발자가 되려면?

• 함께 성장하려는 마인드 갖추기�“함께 가야 더 빠르게 간다!”는 사실을 잊지 말자.

​

• 같은 회사 동기와는 차별화가 덜 되겠지만,�업계 전반으로는 확실하게 앞서 나갈 것

Q10. 주니어 개발자의 성장을 위한 구글의 시스템 혹은 문화는?

• 특별히 주니어만을 위한다기보다, 전반적으로 함께 성장하려 노력
• 그중 주니어에게 특히 도움되는 문화라면..
• 코드 리뷰
• 위로 올라갈수록 ‘주변인 성장 이끌기’ 역할을 강조하고�승진 시스템에 반영
• 사내 스터디, 발표가 굉장히 활성화되어 있음

Q11. 모든 팀원이 동의하고 공감할 수 있는 개발 문화를 채택하려면 어떤 프로세스를 거쳐야?

• 다음 브런치 글 참고 ( brunch.co.kr/@wegra )
• ‘(멘탈 부여잡고) 좋은 문화 뿌리내리기’�
• 단, ‘모두’의 동의를 얻는 건 비현실적
• 대신 어느 정도의 공감을 끌어내면�조금씩이라도 변화하여 계속 더 나아지는 모습을 보여주자.

Q12. 좋은 사람들과 함께 성장하며 일하고 싶다.�좋은 회사를 알아보고 선택하는 방법은?

• 완벽한 곳은 없음
• 어느 정도 갖춰진 조직이고 변화할 가능성이 보인다면,�조급해하지 말고 함께 개선해 가려는 자세 필요�
• 좋은 사람들과 일하고 싶다면 스스로도 좋은 사람이 되어야..

Q13. 책에서 가장 마음에 드는 챕터와 이유는?

• “2장. 팀워크 이끌어내기” + “5장. 팀 이끌기”
• 이유
• 일할 맛 나는 회사가 되려면 매일 부대끼는 동료들과 함께 있을 때 즐거워야..
• 좋은 팀을 완성하려면 좋은 리더가 필요�하지만 좋은 리더가 되는 방법을 제대로 훈련받고 리더가 되는 일은 흔치 않음

Q14. 비전공자라서 주변에 아는 선배 개발자가 적다.�많은 선배 개발자/멘토를 만나 배우고 성장하려면?

1. 꾸준히 실력을 키워서 더 나은 회사를 찾아 이직
2. 적극적으로 자신을 노출하여 접점을 늘리고 기회 만들기
• 재미난 아이디어 하나!
• (작더라도) 익힌 것들을 조금씩 정리
• 해당 주제 커뮤니티에 ‘작은 세미나를 엽니다’ 공지
• 2~3명이라도 만나 발표 & 네트워킹

왜?

• 생각지 못한 인연이 생길 수도..
• 후에 멘토를 만났을 때
• 노력하는 모습을 보일수록 더 진지하게 고민해줌
• 나에 대해 많이 알수록 더 구체적으로 조언�
• 노력하다 보면 스스로 길을 찾을 수도..

Q15. 코드 리뷰 문화의 성과를 보여주는 방법이 있을지?

• 다양한 지표 활용 가능
• 리뷰당 댓글 개수
• 댓글 내용의 수준 혹은 유형의 비중
• 단순 스타일 → 버그 → 설계 → ..
• 리뷰에 걸리는 평균 시간
• 리뷰 거절 비율
• 만족도 설문 등..

Q16. 챗GPT가 개발 공부에 유용하지만, 한편으론 사고력을 기르는 데 방해된다. 어느 수준까지 활용해야 하나?

• 적극 활용 추천
• 단, 강력한 도구일수록 잘못 쓰면 나를 해칠 수도..�
• 챗GPT가 내어주는 코드는 정답보다는 ‘숙제’에 가깝다.
• “이렇게 구현할 수도 있어.�하지만 온전히 네 것으로 만들지 못하면 개발자로서 살아남지 못할 걸!”�
• 회사 프로젝트에서는 자신이 제출하는 코드에 스스로 책임져야..
• 테스트, 디버깅, 앞으로의 요구사항 변경에 따른 업데이트, ..

프로그래밍 소프트웨어 엔지니어링

​

​

​

​

�

개발

시간

개발

1.0

2.0

1.1

1.2

Q17. 시니어가 없는 조직에서 주니어끼리의 코드 리뷰가 의미가 있을지?

• 정적 분석 도구와 함께라면 얼마든지!!
• 내가 짠 코드를 분석하여 다음 내용을 친절하게 설명해줌
• 어느 부분이, 어떤 경우에 문제가 될 수 있는가
• 어떻게 고쳐야 하나
• 서로 다른 도구를 써서 코드 리뷰 시 ‘가상의 시니어’로 활용
• 잘 이해되지 않는 결과는 함께 논의�
• + 더 나은 프로그래밍 기법 꾸준히 스터디

Q18. ‘개발자’들만의 문화는 어떤 특징이?

• 딱히 떠오른 건 없음
• 이 책에서도 ‘2부 문화’는 거의 모든 조직의 공통 관심사임�
• 오히려 ‘개발자만의’라는 생각은 선입견을 낳을 수 있어서 조심하는 편임

Q19. 구글의 모델이 소규모 스타트업에도 어울릴까?

• 거시적으로는 No�미시적으로는 케바케�
• 구글의 현 모습은, 과거부터 그때 그때의 상황에 맞게 조금씩 변화해온 결과임 (앞으로도 또 달라질 것임)
• 현재 모습보다는 과거에 어떤 문제가 있었고, 무슨 이유로 어떤 선택을 했는지, 그 과정에서의 트레이드오프는 무엇이었는지를 보는 게 훨씬 중요

Q20. (전공자 출신 기획자) 필요한 건 직접 개발/검증해 보고 싶지만 손 놓은지 오래라 자신이 없음. 조언?

• 자신감이 없다면 작은 것부터 시작하여�성공하는 경험을 쌓아야.
• ‘필요한 것’이 당장의 목표로는 너무 크다면,
• 대신 ‘할 수 있을만한 것’ 중 구미가 당기는 작은 목표를 찾아�시작 추천

Q21. 코드를 짜기 힘들거나 일을 자꾸 미루게 될 때, 자신만의 해법이 있다면?

• 우선, 더 근본적인 질문 던져보기
• 회사/프로젝트의 목표나 방향에 공감하지 못하나?
• 시키는 대로만 일해야 하는 분위기인가?
• 내 미래에 하등 도움될 일 없는 프로젝트인가?
• 함께 일하는 사람들과 맞지 않는가?
• 코딩 자체에 흥미를 잃었나?
• 너무 지쳐 휴식이 필요한 건 아닌가?
• ..