Addy Osmani가 구글 14년 동안 뽑아낸 21가지 교훈, 한국 개발자 관점으로 해석

구글 크롬 팀 Engineering Head인 Addy Osmani가 2024년 말 본인 블로그와 Substack, 링크드인에 「14년간 구글에서 얻은 21가지 교훈」을 공개했다. 이 글은 해커뉴스 프론트페이지를 찍고 긱뉴스, 서핏, 디스콰이엇까지 한 바퀴를 돌았다. 애디 오스마니 구글 14년 21가지 교훈은 시니어·스태프 개발자 테크트리의 압축판에 가까워, 개발자 커뮤니티에서 지속적으로 재소환되는 텍스트다.

 

다만 문제는 한국 블로그 대부분이 원문을 통째로 번역해 붙이거나 21개 중 3~5개만 체리픽해 대충 요약한다는 점이다. 그래서 이 글에서는 21개 전부를 훑되, 카테고리 5개로 묶어 인지부하를 줄이고, 한국 조직 맥락에서 무엇이 먹히고 무엇이 먹히지 않는지까지 솔직하게 필터링해본다.

 

Addy Osmani는 누구이며, 왜 이 글이 화제인가

 

 

애디 오스마니는 구글 크롬 팀에서 Engineering Manager를 거쳐 현재 Engineering Head로 근무하는 인물이다. 웹 성능(Web Performance) 영역에서 『Learning JavaScript Design Patterns』, 『Image Optimization』 같은 책을 집필한 저자이기도 하다. 개발자 트위터(X) 팔로워는 40만을 넘고, 본인 Substack 「Elevate」도 수만 명대 구독자를 보유한다.

 

이 사람이 2024년 말 구글 입사 14주년을 맞아 정리한 글이 바로 "21 Lessons from 14 Years at Google"이다. Addy Osmani 21 lessons라는 키워드로 영어권에서는 이미 한 바퀴를 돌았고, 국내에서는 긱뉴스(news.hada.io)가 가장 빨리 번역본을 올렸다. 다만 긱뉴스 번역은 bullet 직역 위주라 맥락이 빠져 있어, 한국 개발자들이 "뻔한 얘기 아닌가?" 하고 지나치는 경우가 적지 않다.

 

원문을 직접 읽어보면 실제로는 뻔하지 않다. 14년치 경험이 압축되어 있어 주니어가 읽으면 "나중에 겪을 일" 목록이 되고, 시니어가 읽으면 "이미 몇 번 처맞아본 얘기"가 된다. 뻔해 보이는 이유는 이미 처맞아본 사람만 그 중요도를 체감할 수 있는 종류의 교훈이기 때문이다.

 

21가지 교훈을 그대로 나열하면 지루하므로, 5개 카테고리로 묶는다

 

 

원문은 bullet 21개를 쭉 나열하는 구조라서 한 번 읽고 나면 무엇이 무엇이었는지 기억이 흐려진다. 그래서 의미가 비슷한 항목끼리 5개 카테고리로 재편했다. 카테고리 단위로 이해하면 훨씬 체계적으로 붙는다.

 

카테고리 1 — 임팩트와 가시성, 조용히 일하면 평가받지 못한다

 

첫 번째 묶음은 임팩트와 가시성(Visibility) 관련 교훈 5개다. 핵심은 다음과 같다.

 

• 임팩트는 코드 줄 수가 아니라 비즈니스·조직에 끼친 영향으로 측정된다
• 본인의 일을 아무도 모른다면 사실상 하지 않은 것과 같다
• 큰 문제를 푸는 편이 작은 문제 10개를 푸는 것보다 승진·평가에 유리하다
• 스코프(scope)를 의식적으로 확장해야 한다 — 팀 내 → 조직 → 회사 전체
• 해결한 문제를 문서화·공유하지 않으면 반쪽짜리에 그친다

 

한국 조직에 대입하면 어떨까. 연말평가·승진심사에서 "증빙"을 남기는 문화와 정확히 맞물린다. 다만 한국에는 "내가 이만큼 했다" 어필을 미덕으로 보지 않는 분위기가 섞여 있어, 개발자들이 은근히 가시성 작업을 게을리한다. 그러다 평가 시즌이 되면 매니저가 "지난 1년에 무엇을 했느냐" 물을 때 버벅이는 사태가 벌어진다.

 

실무 체크리스트 — 분기마다 15분만 투자:

 

1. 분기별로 "내가 한 일" 문서 하나 만들어 두기 (노션·원노트·무엇이든)
2. PR 링크, 설계 문서, 숫자(지표 개선치) 함께 붙이기
3. 평가 시즌이 오면 이 문서가 곧 promo packet이 된다

 

이것이 구글식 promo packet 문화의 축소판이다. 한국 회사가 공식적으로 요구하지 않더라도, 본인이 혼자 하면 가성비가 가장 좋은 작업이다.

 

카테고리 2 — 기술 대 사람, 커뮤니케이션이 코드보다 중요해지는 순간이 온다

 

두 번째 묶음은 하드스킬 대 소프트스킬 관련 교훈 5개다.

 

• 주니어 시기에는 코드 실력이 전부이지만, 시니어를 넘어서면 커뮤니케이션 비중이 더 커진다
• 코드리뷰 코멘트의 톤이 팀 문화를 만든다
• "No"라고 말하는 법을 배우는 것이 시니어의 핵심 역량이다
• 기술적 논쟁은 이기더라도 관계가 깨지면 장기적으로 손해다
• 멘토링은 받는 쪽뿐 아니라 주는 쪽에서도 배움이 크다

 

이 영역은 한국 개발자 커뮤니티에서 은근히 저평가된다. 특히 스타트업에서는 "코드 잘 짜는 사람 = 시니어"라는 등식이 아직 강해서, 커뮤니케이션을 "영업 스킬" 정도로 폄하하는 정서가 있다. 다만 팀이 10명을 넘는 순간부터는 기술 결정의 80%가 문서·회의·슬랙에서 일어난다. 코드는 그 결정을 실행하는 수단일 뿐이다.

 

그리고 코드리뷰 코멘트 톤에 관한 얘기는 실제로 정확하다. "이거 왜 이렇게 짰어?"와 "이 부분을 이렇게 하면 어떤 장점이 있을까?"의 차이가 누적되면 주니어 3년 뒤 실력 격차는 배로 벌어진다. 톤 하나가 심리적 안전감(psychological safety) 을 만들어내는 것이다.

 

실무 적용 팁: 다음 코드리뷰부터 코멘트에 "왜?"로 시작하는 질문 대신 "~하면 어떤가?" 식 제안형으로 바꿔보면 체감 차이가 바로 온다.

 

카테고리 3 — IC 트랙 대 매니저 트랙, 매니저는 "승진"이 아니다

 

세 번째 묶음이 국내 개발자에게는 가장 신선할 법한 영역이다. 교훈 4개가 여기에 묶인다.

 

• 매니저는 승진이 아니라 다른 직무다
• IC(Individual Contributor) 트랙도 끝까지 밀면 Staff·Principal까지 갈 수 있다
• 매니저 트랙에서 행복한 사람과 불행한 사람을 가르는 기준은 본인이 "사람 문제 푸는 것"을 좋아하느냐에 달려 있다
• 커리어 중반에 한 번씩 트랙을 바꿀 수 있다 — 돌이킬 수 없는 결정이 아니다

 

한국에서 이 주제가 왜 중요할까. "개발자 5년 차면 팀장" 관습이 아직도 공공연하기 때문이다. 특히 SI·대기업에서는 IC로 계속 가는 트랙 자체가 불분명하다. 그나마 토스, 쿠팡, 라인, 네이버 같은 곳이 테크 래더(Tech Ladder)를 공개적으로 정의해 두었고, 거기서는 스태프 엔지니어 되는 법이 어느 정도 명시되어 있다. 나머지 회사에서는 매니저로 가지 않으면 커리어가 막힌다는 암묵적 메시지가 존재한다.

 

애디 오스마니가 구글 14년 21가지 교훈에서 강조하는 바는 "매니저를 달면 돈을 더 받고 인정받으니 가는 것"이 아니라 사람·조직 문제를 푸는 일이 체질에 맞아야 간다는 점이다. 코드 짜는 일을 좋아하는 사람이 억지로 매니저가 되면 본인도 불행하고 팀도 불행해진다.

 

한국 개발자에게 적용하려면 일단 본인 회사에 IC 트랙이 실제로 존재하는지부터 확인해야 한다. 없다면 솔직히 이직을 고민할 타이밍일 수 있다.

 

카테고리 4 — 피드백과 학습 루프, 실패는 빠르게 배움은 기록으로

 

네 번째 묶음은 피드백·학습 관련 교훈 4개다.

 

• 1:1 미팅에서 매니저에게 피드백을 먼저 요청하라
• 실패는 숨기지 말고 공식 postmortem으로 남겨라 — 책임자 찾기가 아니다
• 주간 회고 15분이 연간 성장률을 좌우한다
• 동료 피드백(peer feedback)이 매니저 피드백보다 자주 더 정확하다

 

구글의 postmortem 문화는 유명한데, 핵심은 "누가 잘못했느냐"가 아니라 "이 상황이 다시 발생하지 않게 하려면 시스템을 어떻게 바꿔야 하느냐"다. 이를 블레임리스(blameless) postmortem이라 부른다.

 

다만 한국 조직의 상당수는 아직도 장애가 나면 "누가 그 배포 했어?"부터 찾는다. 이것이 누적되면 개발자들이 장애를 숨기거나 우회하기 시작한다 — 결국 더 큰 장애로 쌓인다. 넷플릭스·토스 같은 곳이 블레임리스 문화를 공개적으로 밀어붙이는 이유가 여기에 있다.

 

실천 팁 — 개인 레벨에서 당장 가능한 것:

 

• 매주 금요일 15분만 잡고 "이번 주 배운 것 3줄"을 메모로 남긴다
• 장애가 났을 때 개인 노트에 postmortem 양식대로 정리한다 (근본 원인, 대처, 재발 방지)
• 1:1 미팅을 시작할 때 "제 부족한 점을 피드백 달라"고 먼저 요청한다

 

이 루틴을 실천하는 사람과 그렇지 않은 사람은 3년 뒤 완전히 다른 레벨이 된다. 정말이다.

 

카테고리 5 — 번아웃과 장기전, 14년을 버티려면 마라톤이어야 한다

 

마지막 묶음은 번아웃·지속가능성 관련 교훈 3개다.

 

• 14년을 버티려면 스프린트가 아니라 마라톤 페이스여야 한다
• 번아웃은 한번 오면 회복에 몇 달이 걸린다 — 예방이 치료보다 싸다
• 취미·운동·가족 같은 "일이 아닌 영역"이 오히려 일을 지속 가능하게 만든다

 

잡플래닛·원티드 설문을 보면 국내 개발자의 평균 이직 주기는 3년 안팎이다. 이것이 단순히 연봉 점프만이 이유는 아니고, 번아웃 누적 → 회복 불가 → 환경을 바꿔야 숨통이 트인다는 패턴이 상당수다. 애디 오스마니는 14년을 한 회사에서 버틴 희귀한 케이스인데, 본인이 강조하는 바는 "평소에는 70%로 달리다가 진짜 필요할 때만 100%를 쓴다"이다.

 

이 원칙은 한국 개발자에게는 더욱 중요할 수 있다. 왜일까? 한국 조직은 기본 페이스가 이미 80~90%로 세팅되어 있어, 뭐 하나 터지면 100%를 넘겨야 하기 때문이다. 그러니 번아웃 관리는 선택이 아니라 생존 기술이다.

 

이 중에서 한국 개발자에게 가장 뼈아픈 3가지를 추렸다

 

 

21개가 모두 중요하지만, 한국 맥락에서 특히 뼈아픈 것 3개를 꼽으라면 다음이다.

 

1) "본인의 일을 아무도 모르면 하지 않은 것과 같다" — 한국 개발자가 가장 소홀히 하는 부분이다. 겸손 미덕 문화와 본인 PR 사이에서 혼란에 빠지다가 결국 연말평가 때 손해를 본다.

 

2) "매니저는 승진이 아니라 다른 직무다" — "5년 차 팀장" 관습 때문에 성향에 맞지 않는 사람이 떠밀려 올라가 본인도 팀도 불행해지는 사례가 많다.

 

3) "장애는 책임자를 찾는 것이 아니라 시스템을 고치는 일" — 한국 조직이 가장 더딘 영역이다. 이 지점 하나만 바뀌어도 개발자 행복도는 훨씬 올라간다.

 

해커뉴스 댓글에서도 "뻔한 얘기 대 시니어가 되어봐야 체감된다" 논쟁이 있었는데, 다수 의견은 "처음 읽을 땐 뻔해 보이는데 3년 뒤에 다시 읽으면 밑줄이 다 쳐진다"였다. 절로 공감이 간다.

 

반대로 "이건 구글 특수 상황에 가깝다" 싶은 교훈도 있다

 

 

무비판적으로 전부 받아들일 필요는 없다. 구글이라서 가능한 것들이 섞여 있기 때문이다.

 

• Promo packet 문화 — 승진심사 때 본인이 직접 만든 패킷을 제출하는 구조인데, 이 장치가 있어야 "가시성" 교훈이 온전히 작동한다. 한국 조직에는 대부분 없는 개념이다. 그래서 개인 노션 정도로 대체하는 것이 현실적이다.
• 20% 프로젝트 — 업무 시간 20%를 자율 프로젝트에 쓰는 구글 제도다. 한국 SI·대기업에서는 거의 통하지 않는다. 스타트업도 최근에는 축소 추세다. 이 제도를 기대하고 교훈을 적용하면 현실과 괴리가 온다.
• 스코프를 회사 전체까지 넓혀라 — 구글 같은 플랫 조직에서나 가능한 얘기다. 한국 수직 조직에서 타 부서를 건드리면 정치 문제가 된다. 본인 조직 문화를 읽고 적용 수위를 조절해야 한다.
• "No라고 말하는 법" — 구글처럼 수평적이고 토론 문화가 있는 곳에서는 먹히지만, 한국 위계 조직에서 직접 No를 던지면 분위기가 싸해진다. 대안 제시를 함께 해야 한다 — "A 대신 B는 어떤가?" 식이다.

 

각설하고, 애디 오스마니 구글 14년 21가지 교훈을 읽을 때도 "이건 적용, 이건 한국 특수상황 필터링" 이라는 이중 해석이 필요하다. 무작정 받아들이면 조직과의 마찰만 생긴다.

 

애디 오스마니 구글 14년 21가지 교훈, 한국 개발자가 써먹을 5줄 요약

 

 

출처: alamy.com

정리하면 다음과 같다.

 

• 임팩트·가시성: 분기별 "내 기록 문서"를 만들어 둔다 — promo packet의 축소판이다
• 소프트스킬: 어느 시점부터 커뮤니케이션이 코드보다 중요해진다. 코드리뷰 톤부터 바꿔보라
• 커리어 트랙: 매니저는 승진이 아니라 다른 직무다. 본인 체질 먼저 확인하라
• 피드백 루프: 주간 15분 회고와 블레임리스 postmortem 문화가 장기 성장률을 결정한다
• 지속가능성: 14년을 버티려면 평소 70%로 달리고 번아웃 관리는 생존 기술로 삼아야 한다

 

14년치 시행착오가 21개 bullet에 압축된 글이라, 한 번 읽고 치우기에는 아까운 텍스트다. 원문(addyosmani.com)과 Substack의 Elevate 시리즈에서 전체 맥락을 확인하고, 해커뉴스 토론 스레드에서 다른 시니어들의 반응도 함께 읽으면 입체적으로 이해된다. 국내 요약은 긱뉴스 번역본이 가장 빠르다.

 

마지막으로 한 가지만 덧붙이자면 — 애디 오스마니 구글 14년 21가지 교훈 중에서 본인 조직에 당장 적용 가능한 것 1개만 고르고, 이번 주 안에 실제로 실행해보는 것이다. 21개를 한꺼번에 하려다 하나도 하지 못하는 것이 가장 흔한 함정이다. 1개씩 누적하다 보면 14년 후 본인 글도 한 편 쓸 수 있을 것이다.