14가지 더 많은 교훈: Google 14년에서 배운 것

저자: Addy Osmani (Google 소프트웨어 엔지니어, Chrome 개발자 경험 담당) 작성일: 2026년 2월 12일 원문: https://addyosmani.com/blog/14-more-lessons

---

글의 배경

Addy Osmani는 이전에 Google에서 14년 일하며 배운 21가지 교훈을 썼는데, 특히 기술보다는 사람과 의사결정, 팀워크에 관한 내용이 큰 반향을 일으켰다. 그래서 이번에는 개인이 어떻게 더 잘 일할지에 대한 이야기가 아니라, 팀이 어떻게 더 잘 작동하는지에 대한 14가지 새로운 교훈을 썼다.

이 글의 핵심 메시지는 이것이다:

"평범한 사람이 평범한 날에도 놀라운 일을 할 수 있도록 만드는 것"

그것이 엔지니어링 리더십의 목표라는 것이다.

---

14가지 교훈

1. 가장 중요한 문제를 골라라

모든 일에 "네"라고 하면, 정말 중요한 일에 "아니오"라고 하는 것과 같다.

재능 있는 엔지니어들이 번아웃에 빠지는 이유는 모든 버그 수정, 모든 기능 요청, 모든 "간단한 도움"에 응하기 때문이다. 일정에 남의 우선순위가 채워지고, 자신에게 정말 중요한 일은 반쯤 끝나고 방치된다.

진짜 영향력을 만드는 엔지니어는 더 빠르거나 더 똑똑한 것이 아니다. 자신의 시간을 무엇에 쓸지 더 냉정하게 선택할 줄 안다. 잘못된 일에 쓰는 시간의 기회비용은, 그 시간이 잘못된 일에 쓰였다는 사실 자체다.

실천 방법: "좋으면 좋겠네" 정도의 요청을 프로덕션 장애만큼 강력하게 방어하라.

---

2. 미팅 전에 어떤 결정을 원하는지 말하지 못하면 미팅을 열지 마라

대부분의 미팅이 실패하는 이유는 불필요해서가 아니라, 목적을 명확히 하지 않아서다. 똑똑한 사람들이 문제를 둘러서만 이야기하고, 실제로 무엇을 결정해야 하는지 전혀 밝히지 않는 미팅을 수백 시간 보냈다. 미팅이 끝나고 분위기는 좋았는데, 누구도 무엇을 해야 하는지 모른다.

저자는 미팅을 네 가지 중 하나로 시작하는 방법을 배웠다:

• 승인 (Approve): 이 방향대로 가도 되는지 확인
• 선택 (Choose): A와 B 중 하나를 고르자
• 막힌 것 해결 (Unblock): 이 문제가 해결되면 계속 갈 수 있음
• 알림 (Inform): 결정은 필요 없고, 그냥 알려드리기 위해 만나는 것

미팅을 받는 쪽에서는 처음 2분 안에 "저에게 어떤 결정을 필요로 합니까?"라고 물어본다. 직설적으로 들리지만, 상대방은 종종 스스로도 목적을 정의하지 않았다는 것을 모르고 놀란다.

숨겨진 비용: 모호한 미팅의 진짜 비용은 잃은 1시간이 아니라, 명확함이 오지 않아 모든 사람이 기다리는 그다음 한 주 전체다.

---

3. "해야 해"는 계획이 아니다. "수요일에 내가 할게"가 계획이다

운동과 진전의 차이는 구체성이다.

팀들은 의도에 잠긴다. 로드맵에 "온보딩을 개선해야 해", "지연 시간을 줄여야 해", "API 문서를 작성해야 해"라고 적혀있는데, 몇 달이 지나도 같은 항목이 그대로 방치된다. AI 에이전트 엔지니어링 시대가 왔다고 해도 이 문제는 완전히 해결된 것이 아니다.

해결책은 대화를 누군가가 실제로 할 수 있는 가장 작은 다음 행동으로 바꾸고, 이름과 날짜를 붙이는 것이다.

• ❌ "온보딩을 개선해야 해"
• ✅ "수요일에 사라가 사용자 세션 세 번을 진행하고, 가장 큰 문제점 세 가지를 기록할게"

모호한 의도는 불안감을 만든다. 구체적인 약속은 추진력을 만든다. 계획이 완벽할 필요는 없다. 누군가가 시작할 수 있을 만큼 구체적이면 된다.

---

4. 느린 코드는 증상일 뿐이다. 느린 결정이 진짜 문제다

프로젝트가 지연되면 본능적으로 속도를 비난한다: 사람들이 충분히 열심히 일하지 않는다, 코드베이스가 지저분하다, 엔지니어가 부족하다. 하지만 느린 코드는 종종 증상일 뿐이다. 느린 결정이 질병이다.

결정이 몇 주나 몇 달이 걸리면 원인을 깊이 살펴봐야 한다:

• 컨텍스트 부족: 사람들이 트레이드오프를 평가할 정보를 가지고 있지 않음
• 소유권 불명확: 모두 다른 사람이 결정하기를 기다림
• 책임 회피: 사람들이 커밋하는 대신 안전지대에 머무름

저자가 일한 가장 빠른 엔지니어링 팀은 최고 프로그래머들이 있는 팀이 아니었다. 결정이 몇 주가 아닌 몇 시간 안에 이루어진 팀이었다. 권한이 명확하고, 정보가 공유되고, 틀리는 것이 경력 위험이 되지 않는 환경이었다.

---

5. 신뢰성은 제품 기능이다. 그렇게 대접하라

사용자들은 시스템이 잘 작동할 때 칭찬하지 않는다. 하지만 작동하지 않으면 바로 알아본다.

이로 인해 위험한 상황이 생긴다: 신뢰성 작업은 실패할 때까지 보이지 않으므로, 항상 반짝이는 새 기능에 비해 자원이 부족하다.

에러 예산 (Error Budget)이라는 개념이 이를 명확히 한다:

서비스의 목표가 99.9% 가동률이라면, 0.1%의 다운타임 "예산"이 있다. 이 예산 안에서 새로운 기능을 시도할 수 있다. 예산을 다 쓰면, 신뢰성 개선에 집중해야 한다. 예산을 다시 벌어야 혁신을 계속할 수 있다.

기능을 출시할 때 제품 리뷰를 거치는 것처럼, 시스템을 출시할 때 신뢰성 논의도 반드시 거쳐야 한다.

---

6. 나쁜 팀 간 인터페이스는 "소통"으로 해결되지 않는다

팀 간 상호작용은 세 가지 모드 중 하나로 명확히 정의되어야 한다:

1. 협업 (Collaboration): 밀접하게 함께 작업
2. 서비스 (Service): 명확한 API와 서비스 수준 협약
3. 지원 (Facilitation): 한 팀이 다른 팀의 능력을 키우는 것

대부분의 팀 간 문제는 노력이나 의도가 부족해서가 아니라, 경계가 불분명하고 계약이 흐려서 생긴다. 더 많은 미팅, 더 많은 슬랙 채널, 더 많은 정기 회의를 추가해도 좋아지지 않는다.

문제는 사람들이 이야기하지 않는 것이 아니다. 팀 간 인터페이스가 정의되지 않았기 때문이다. 누가 무엇을 소유하는가? 계약은 무엇인가? A팀이 B팀에게 무엇을 기대할 수 있는가?

인터페이스를 명확히 정하면, 오히려 더 적은 미팅으로 일할 수 있다. 나쁜 인터페이스를 소통으로 덮으려 하면, 가장 협력적인 사람들이 먼저 번아웃에 빠지고 근본 문제는 그대로 남는다.

---

7. 제안과 함께 문제를 올리라

"여기에 문제가 있습니다"라고 하는 것은 절반의 일일 뿐이다.

이전에는 자신의 역할은 문제를 찾아 리더십에게 가져가는 것이라고 생각했다. 필요하지만 충분하지 않다.

"두 가지 옵션이 있고, 각각의 장단점이 이것이며, 저는 이렇게 추천합니다"라고 하면 막힌 것이 해결되고 신뢰를 얻는다. 당신이 생각을 했음을 보여준다. 결정권자에게 열린 문제가 아닌, 구체적인 반응 대상을 준다.

상대의 일을 쉽게 만들어주면, 상대방도 당신의 필요를 더 잘 충족시켜준다.

• ❌ "도움이 필요해요"
• ✅ "A와 B 중 하나를 선택해 주세요. B를 추천하는 이유는 이렇습니다"

두 가지 모두 문제를 지적한다. 하지만 오직 후자만 신뢰와 자율성을 얻는다.

---

8. 히어로 문화를 피하라. 히어로가 필요 없는 시스템을 만들라

히어로는 번아웃에 빠지고, 문서화되지 않으며, 유일한 실패점이다.

한 사람이 항상 위기를 구하는 패턴이 반복된다면, 그것은 영광이 아니라 시스템 실패다. 팀은 히어로를 칭찬하면서도 히어로가 필요하게 만든 근본 문제를 무시한다.

히어로는 결국 떠난다. 그리고 팀은 다른 아무도 어떻게 돌아가는지 모른다는 것을 발견한다. 히어로 칭찬은 시스템 문제를 가린다: "평범한 사람이 평범한 날에" 일할 수 있는 경로가 작동하지 않는다.

문서화하라. 지식을 공유하라. 특별한 위기가 아닌 평범한 화요일을 위해 설계하라. 히어로는 불필요해야 하고, 필요하다면 그들을 불필요하게 만들기 위해 노력해야 한다.

---

9. 관측성은 기능의 일부다

텔레메트리가 없는 기능은 위장한 부채다.

기능을 출시했는데 프로덕션에서 어떻게 작동하는지 알 수 없다면, 불확실성을 출시한 것이다.

출시를 축하했다가 몇 주 후에 기능이 사용자의 20%에게는 조용히 실패하고 있다는 것을 발견한 팀을 보았다. 로그도, 지표도, 대시보드도 없었다. 이해가 있어야 할 곳에 공백이 있었다.

로그, 트레이스, 대시보드, 알림은 "운영팀 일"이 아니다. 당신이 만든 것이 실제 사용자가 실제 상황에서 실제로 작동하는지 아는 방법이다.

최고의 엔지니어들은 관측성을 완료의 정의에 포함한다:

• ❌ "코드를 썼어"
• ✅ "코드를 쓰고, 그것이 작동하는 것을 확인할 수 있어"

---

10. 작은 PR은 친절이다. 특히 AI가 생성한 PR일수록

작은 변경은 리뷰하기 쉽고, 이해하기 쉽고, 되돌리기 쉽다.

저자는 예전에 큰 풀 리퀘스트를 작성했다. 하나의 완전한 기능을 한 번에 리뷰받을 수 있다는 아이디어가 좋았다. 하지만 그것은 자신의 편의를 최적화한 것이고, 리뷰어의 정신 건강을 희생한 것이었다.

작은 PR은 더 빨리 출시된다. 천 줄 차이를 이해하기 위해 한 시간을 찾는 사람들을 기다리지 않고 바로 갈 수 있다. 동료들이 당신의 속도를 신뢰하려면, 당신의 작업을 리뷰 가능하게 만들어야 한다.

숨겨진 이점은 작은 PR이 점진적 사고를 강제한다는 것이다. 하나의 거대한 변경 대신, 기능을 조각조각 쌓아올린다. 각 조각이 피드백을 받고, 각 조각이 독립적으로 롤백된다. PR당 느리지만 실제 프로덕션까지 빠르다.

특히 AI가 생성한 코드는 더 철저한 검증이 필요하므로, 작은 단위로 나누는 것이 더욱 중요하다.

---

11. 사람을 추가하면 노드가 아닌 연결선이 추가된다

조정 비용은 인원수보다 빠르게 증가한다.

"문제에 더 많은 사람을 던져라"가 종종 실패하는 이유다. 새로운 사람마다 조정해야 할 커뮤니케이션 오버헤드가 생긴다. 그래프가 단순히 커지는 것이 아니라, 더 빽빽해진다.

팀 크기가 두 배가 되는데 산출물이 거의 변하지 않는 것을 보고 정말 당황한 매니저들을 보았다. 답은 항상 같다: 새로운 연결선이 새로운 용량을 먹어치웠다. 더 많은 사람은 더 많은 정렬 미팅, 더 많은 컨텍스트 공유, 더 많은 이해관계자가 필요한 결정 대기 시간을 의미한다.

해결책은 채용을 멈추는 것이 아니다. 연결선을 의도적으로 줄이는 것이다. 명확한 소유권, 최소한의 의존성을 가진 자율적 팀, 사람들이 병렬로 일할 수 있게 하는 인터페이스. 최고의 조직은 사람이 가장 많은 조직이 아니라, 연결선이 가장 잘 관리된 조직이다.

---

12. 마이그레이션은 결코 단순한 마이그레이션이 아니다

모든 마이그레이션은 현재 시스템, 원하는 시스템, 그리고 둘 다 요청하지 않은 사람들 사이의 협상이다.

한 분기에 끝날 것으로 예상한 마이그레이션이 몇 년으로 늘어났던 것을 보았다. 기술 작업이 잘못되어서가 아니라, 인간 작업을 고려하지 않았기 때문이다:

• 팀들이 자신의 로드맵 대신 마이그레이션을 우선시하도록 설득하는 일
• 아무도 존재를 몰랐던 끝없는 예외 케이스를 지원하는 일
• 오래된 시스템이 죽기를 거부하는 동안 두 시스템을 동시에 유지하는 일

기술 계획은 쉬운 부분이다. 어려운 것은 공존을 설계하는 것이다. 예상보다 훨씬 오래 동안 구버전과 신버전을 동시에 실행하게 될 것이다. "레거시" 시스템에 아무도 문서화하지 않은 결정과 아무도 설계했다고 기억하지 못하지만 모두 의존하는 워크플로우가 숨어있다는 것을 발견하게 될 것이다.

성공한 마이그레이션의 세 가지 공통점:

1. 시작 후에도 계속 관여하는 후원자
2. 마이그레이션을 부수 작업이 아닌 본업으로 여기는 전담 팀
3. 사람들이 진짜라고 믿는 명확한 폐기 날짜

세 가지 모두 없으면, 영원히 "거의 다 됐다"인 마이그레이션이 된다. 시작하지 않는 것보다 더 나쁜 상황이다. 두 시스템의 비용을 영원히 지불하게 된다.

끝낼 의지가 없으면 마이그레이션을 시작하지 마라.

---

13. AI는 초안을 싸게 만든다. 취향은 비싸진다

이제 누구나 코드를 생성할 수 있다. 코드, 콘텐츠, 디자인을 만들어내는 장벽은 거의 무너졌다. AI는 예전에 하나를 쓰는 데 걸리던 시간에 열 개의 버전을 만들어준다.

차별화 요인은 선택이다: 무엇을 빌드할지, 무엇을 삭제할지, 무엇을 단순화할지, 무엇을 출시하지 않을지, "좋은 것"이 무엇인지. 취향, 즉 옵션을 구분하고 올바른 것을 고르는 능력이 희소 자원이 된다.

AI로 옵션을 빠르게 탐색하고, 판단을 철저히 적용하라. 이 환경에서 성공하는 엔지니어는 가장 많이 생성하는 사람이 아니다. 가장 잘 큐레이션하는 사람이다.

생산은 싸다. 편집은 비싸다. 선택이 모든 것.

---

14. 신뢰는 팀의 레이턴시 최적화다

빌드할 수 있는 것 중 가장 높은 레버리지는 시스템이 아니라 신용이다.

사람들이 당신을 신뢰하면, 결정을 승인하기 위해 다섯 번의 미팅이 필요하지 않다. 유능함, 좋은 의도, 그리고 약속을 지키는 것을 가정한다. 저신뢰 환경에서는 몇 주가 걸리는 결정이 고신뢰 환경에서는 몇 시간에 끝난다.

약속을 지키는 때마다, 실수를 솔직하게 인정하는 때마다, 다른 사람의 일을 쉽게 만들어주는 때마다, 수년 동안 이자를 지급할 계좌에 예금하는 것이다.

겸손한 기술 실력으로 엄청난 일을 해낸 엔지니어들을 보았다. 모두가 그들을 신뢰했기 때문이다. 동시에 놀라운 재능으로 거의 아무것도 이루지 못한 엔지니어들도 보았다. 아무도 그들과 일하고 싶지 않았기 때문이다.

코드를 작성해도 함께 출시할 사람이 없으면 코드는 의미가 없다.

---

마지막 생각

첫 번째 글에서 이 교훈들은 호기심을 유지하고, 겸손하게 남으며, 일이 사람에 관한 것이라는 것을 기억하는 데 귀결된다고 말했다. 여전히 그렇게 믿는다.

하지만 두 번째 목록의 일관된 줄거리는 더 구체적이다:

"일은 평범한 사람이 평범한 날에도 놀라운 일을 할 수 있도록 쉽게 만드는 것이다"

엔지니어링 경력은 이런 것들을 어려운 방식으로 배울 충분한 시간을 준다. 저자는 Google에서 아직 많은 것을 배웠다.

이 교훈들 중 몇 개라도 당신의 상처를 하나라도 덜어주기를 바란다. 그리고 만약 그렇다면, 여정에서 더 이른 단계에 있는 사람에게 당신이 배운 것을 공유하라.

좋은 교훈은 그렇게 전파된다.

---

커뮤니티 반응

Hacker News (1678 points, 688 comments - 첫 번째 글 기준)

• 이 글은 HN에서 큰 관심을 받았으며, 첫 번째 21 lessons 글이 1678 포인트와 688 댓글을 기록
• 두 번째 글도 HN에서 공유되었으나 댓글 수는 첫 번째에 비해 적음
• 주요 반응: "실용적이고 즉시 적용 가능한 조언들", "Google이라는 거대 조직에서 배운 교훈들이 작은 팀에도 적용된다"

LinkedIn

• "AI makes drafts cheap. Taste becomes expensive"라는 문장이 특히 큰 공감을 얻음
• 엔지니어들이 AI 시대에 자신의 역할을 재정의하는 데 도움이 되었다는 평가
• "신뢰는 레이턴시 최적화"라는 비유가 기술적 배경을 가진 사람들에게 특히 잘 전달됨

Reddit (r/programming, r/theprimeagen)

• 마이그레이션 교훈(12번)이 실제 경험을 가진 개발자들로부터 많은 공감을 얻음
• "끝낼 의지가 없으면 시작하지 마라"라는 문장이 특히 현실적이라는 평가
• 작은 PR 교훈(10번)이 AI 코드 생성 시대에 더 중요해졌다는 논의

---

새로운 시각

1. 신뢰를 시스템 성능 지표로 재정의

"신뢰는 레이턴시 최적화"라는 비유는 신뢰를 소프트 스킬이 아닌 시스템 성능 지표로 재정의한다. 저신뢰 팀은 모든 결정을 검증해야 하므로 오버헤드가 크고, 고신뢰 팀은 검증을 스킵할 수 있으므로 속도가 다르다. 이는 네트워크에서 캐시가 레이턴시를 줄이는 것과 동일한 원리다.

2. 마이그레이션의 성공 조건 세 가지

스폰서의 지속적 참여, 전담 팀, 확실한 폐기 날짜라는 세 조건은 실제 프로젝트 관리에서 거의 언급되지 않는다. 특히 "끝낼 의지가 없으면 시작하지 말라"는 냉정한 조언은 많은 조직이 무시하는 진실이다. 절반만 끝난 마이그레이션은 두 시스템을 모두 유지해야 하므로 시작하지 않은 것보다 더 나쁘다.

3. AI 시대의 취향 경제학

AI가 생산 비용을 거의 0에 가깝게 만들수록, "무엇을 선택할지"의 판단력이 유일한 차별화 요소가 된다. 이는 엔지니어링뿐만 아니라 콘텐츠, 디자인, 연구 분야에도 적용되는 보편적 진리다. 생산 능력은 더 이상 경쟁력이 아니다. 선택 능력이 경쟁력이다.

4. 히어로 문화는 시스템 실패의 증상

히어로를 칭찬하는 조직은 근본 문제를 덮는 것이다. 이는 의료 시스템(특급 의사가 없으면 진료가 불가한 상황), 교육 시스템(특정 선생님 없으면 수업이 불가한 상황)에도 동일하게 적용된다. 평범한 사람이 평범한 날에도 일할 수 있는 시스템을 만드는 것이 진정한 리더십이다.

---

자녀와 미래에 대한 시사점

1. 문제 선택 능력이 속도보다 중요

자녀가 성장할 AI 시대에는 "무엇을 할지" 선택하는 능력이 "얼마나 빠르게 하는지"보다 훨씬 중요해질 것이다. 부모가 모델링할 수 있는 가장 중요한 능력은 모든 일에 응하는 것이 아니라, 정말 중요한 것에만 집중하는 능력이다.

2. 취향 개발이 핵심 교육 목표

AI가 모든 초안을 만들어주는 세상에서 자녀가 갖추어야 할 가장 중요한 능력은 "좋은 것"과 "그저 그런 것"을 구분하는 안목이다. 예술 감상, 비판적 사고, 다양한 옵션에 노출시키는 것이 교육의 핵심이 되어야 한다. 무엇을 만들어야 하는지 아는 것이 어떻게 만드는지 아는 것보다 중요해진다.

3. 작은 단위로 나누는 습관

작은 PR이 친절하다는 교훈은 학습에도 동일하게 적용된다. 큰 프로젝트를 작은 단위로 나누어 진행하는 습관은 AI 시대에도 변하지 않는 핵심 역량이다. 자녀가 큰 과제를 받았을 때 "어디부터 시작할지"를 작은 단위로 나누는 방법을 가르쳐주는 것이 중요하다.

4. 마이그레이션의 인간적 측면

기술 변화는 항상 인간의 저항을 동반한다. 자녀가 커갈수록 겪을 기술 전환기에서 "기술은 쉬운 부분이 아니다, 사람이 어려운 부분이다"라는 인식을 일찍 갖게 하는 것이 중요하다. 새로운 도구를 도입할 때 사람들이 어떻게 반응하는지 관찰하게 하고, 변화 관리의 어려움을 이해하게 하라.

5. 신뢰는 가장 중요한 자본

자녀가 사회에서 성공하려면 기술적 능력보다 신뢰가 더 중요할 수 있다. 약속을 지키는 습관, 실수를 솔직하게 인정하는 태도, 다른 사람의 일을 쉽게 만들어주는 마음가짐은 수년 동안 이자를 지급하는 투자다. 이는 학교 성적보다 더 오래가는 경쟁력이다.

---

저장일: 2026년 6월 4일 원문 링크: https://addyosmani.com/blog/14-more-lessons

---

═══ 두 번째 번역 — Claude (다출처 보강판), 2026-06-04 ═══

위 첫 번째 버전은 local LLM이 작성했다. 아래는 같은 글을 Claude가 9절 분석 구조로 다시 번역·분석한 판이다. HN·업계 출처를 직접 검증해 보강했다(커뮤니티 반응 수치 정정: 1678점/688댓글은 첫 글이며, 이 속편은 HN 18점·0댓글). 비교를 위해 두 판을 한 파일에 함께 보존한다.

Google에서의 14년, 14가지 교훈 더 (14 More Lessons from 14 Years at Google)

Addy Osmani, 2026-02-12, addyo.substack.com (Elevate) / addyosmani.com 동시 게재. 공유 135, 리스택 6, 댓글 14. 2025년 12월 "21 Lessons from 14 Years at Google"의 속편 — 첫 글이 '개인이 어떻게 일하는가'였다면, 이번 14개는 '팀이 어떻게 잘 작동하는가'에 관한 것이다.

무료 전체 공개 글이라 본문은 모두 확인했고, 교훈별 예시·틀은 원문에서 직접 검증했다. 단, 이 속편은 HN 18점·댓글 0개로 거의 논의되지 않았고 Substack 댓글 14개 중 2개만 노출돼, 댓글 기반인 §4·§6은 약화한다. (큰 반향을 부른 것은 1678점·688댓글의 첫 글이다 — 이 속편이 아니다.)

§1. 한 줄 요약과 핵심 논지

Addy Osmani가 Google 14년에서 길어낸 두 번째 교훈 모음으로, 좋은 문제를 고르고·결정을 명확히 내리고·영웅 대신 시스템을 만들고·신뢰성과 관찰가능성을 기능으로 다루고·AI 시대엔 생산보다 판단(taste)이 가치라는 14개 조언을 담는다. 저자는 그 관통 주제를 한 문장으로 요약한다 — "평범한 사람이 평범한 날에도 비범한 일을 해내도록 쉽게 만드는 것." 그러나 이 글을 종합해서 얻는 더 깊은 통찰은, 잡다해 보이는 14개 교훈이 하나의 공학적 축으로 수렴한다는 점이다 — 거대 조직의 진짜 병목은 코드가 아니라 집단 의사결정의 지연(latency)이며, 저자가 마지막에 신뢰를 "팀의 레이턴시 최적화"라 부른 것이 그 증거다. '평범한 사람이 평범한 날에'라는 인간적 목표와 '결정 지연을 줄인다'는 공학적 메커니즘은 같은 동전의 양면이다. AI는 이 무게중심을 생산에서 판단으로 한 번 더 밀어내고, 구조적 문제는 영웅·소통·인원이라는 노력이 아니라 경계·시스템이라는 설계로 풀리며, 다만 이 교훈들은 거대 조직의 진리라 개인·소규모는 복사하지 말고 번역해 읽어야 한다.

표면적으로 이 글은 "14가지 커리어 팁"의 목록이다. 그러나 진짜 질문은 둘이다. 무엇이 큰 조직에서 일을 느리게 만드는가, 그리고 코드 생산이 싸지는 AI 시대에 엔지니어의 가치는 어디로 이동하는가. Osmani의 답은 일관된다 — 느림의 원인은 대개 타이핑이 아니라 결정·경계·신뢰의 부재이고, 가치는 만드는 능력에서 고르는 능력으로 옮겨간다.

전체 내용 정리

14개 교훈을 저자의 예시와 함께 주제별로 묶어 모두 옮긴다.

(가) 우선순위와 결정의 명확성 — 교훈 1·2·3·4·7.

① 가장 중요한 문제를 골라라. 모든 일에 "네"라고 하는 것은 정말 중요한 일에 "아니오"라고 하는 것이다. 재능 있는 엔지니어가 번아웃에 빠지는 건 모든 버그·기능 요청·"간단한 도움"에 응하다 일정이 남의 우선순위로 채워지기 때문이다. 진짜 영향력 있는 엔지니어는 더 빠르거나 똑똑한 게 아니라 시간을 무엇에 쓸지 더 냉정하게 고른다. 실천: "있으면 좋겠네" 수준의 요청을 프로덕션 장애만큼 강하게 막아라.

② 무슨 결정을 원하는지 말 못 하면 미팅을 열지 마라. 미팅이 실패하는 건 불필요해서가 아니라 목적이 불명확해서다. 저자는 미팅을 네 가지 중 하나로 연다 — 승인(approve)·선택(choose)·차단 해제(unblock)·통보(inform). 받는 쪽에서는 처음 2분 안에 "저에게 어떤 결정을 원하십니까?"라고 묻는다. 모호한 미팅의 진짜 비용은 잃은 1시간이 아니라, 명확함이 안 와서 모두가 기다리는 그다음 한 주다.

③ "해야 해"는 계획이 아니다, "수요일에 내가 할게"가 계획이다. 팀은 의도에 잠긴다("온보딩을 개선해야 해"가 몇 달째 방치된다). 해법은 대화를 누군가 실제로 할 수 있는 가장 작은 다음 행동으로 바꾸고 이름과 날짜를 붙이는 것이다 — "수요일에 Sarah가 사용자 세션 3번을 진행하고 가장 큰 마찰점 3가지를 기록한다." 계획이 완벽할 필요는 없고, 누군가 시작할 수 있을 만큼 구체적이면 된다.

④ 느린 코드는 증상일 뿐, 느린 결정이 질병이다. 프로젝트가 지연되면 본능적으로 속도를 탓하지만, 원인은 대개 굼뜬 결정이다. 그 뿌리는 셋 — 컨텍스트 부족(트레이드오프를 평가할 정보가 없음), 소유권 불명확(서로 결정을 미룸), 책임 회피(커밋 대신 안전지대에 머묾). 저자가 겪은 가장 빠른 팀은 최고 프로그래머의 팀이 아니라, 결정이 몇 주가 아니라 몇 시간에 나는 팀이었다.

⑦ 문제는 제안과 함께 올려라. "여기 문제가 있습니다"는 절반의 일이다. "옵션 두 개가 있고 장단점은 이렇고 저는 B를 추천합니다"라고 하면 차단이 풀리고 신뢰를 얻는다. 상대의 일을 쉽게 만들면 상대도 내 필요를 더 잘 채워준다.

(나) 시스템과 구조 — 교훈 5·6·8·9·11.

⑤ 신뢰성은 제품 기능이다. 사용자는 잘 돌아갈 땐 칭찬 안 하지만 멈추면 즉시 안다. 그래서 신뢰성 작업은 실패하기 전까진 안 보여 늘 반짝이는 새 기능에 밀린다. 에러 예산(99.9% 목표면 0.1%의 다운타임 예산)으로 혁신과 안정의 트레이드오프를 명시하고, 전담 자원과 로드맵 소유권을 준다.

⑥ 나쁜 팀 간 인터페이스는 '소통'으로 안 풀린다. 팀 상호작용은 세 모드 중 하나로 명확히 정의돼야 한다 — 협업(collaboration, 밀접하게 함께), 서비스(service, 명확한 API와 SLA), 지원(facilitation, 한 팀이 다른 팀의 역량을 키움). 대부분의 팀 간 문제는 노력 부족이 아니라 경계와 계약이 흐려서 생긴다. 미팅·슬랙 채널을 더해도 안 좋아지고, 오히려 가장 협력적인 사람이 먼저 번아웃된다.

⑧ 영웅 문화를 피하고, 영웅이 필요 없는 시스템을 지어라. 한 사람이 늘 위기를 구하는 패턴은 영광이 아니라 시스템 실패다. 영웅은 번아웃되고, 문서화되지 않고, 단일 실패점이며, 결국 떠난다. 영웅 칭송은 "평범한 사람이 평범한 날에" 일할 경로가 막혔다는 사실을 가린다. 문서화하고 지식을 공유하고 위기가 아닌 평범한 화요일을 위해 설계하라.

⑨ 관찰가능성은 기능의 일부다. 텔레메트리 없는 기능은 위장한 부채다. 한 팀은 출시를 축하하고 몇 주 뒤에야 기능이 사용자 20%에게 조용히 실패하고 있음을 발견했다 — 로그도 지표도 대시보드도 없어 이해가 있어야 할 자리에 공백이 있었다. 완료의 정의는 "코드를 썼다"가 아니라 "코드를 쓰고 그것이 작동함을 확인할 수 있다"이다.

⑪ 사람을 더하면 노드가 아니라 연결선(edge)이 는다. 조정 비용은 인원보다 빠르게 증가한다. 팀 크기를 두 배로 늘렸는데 산출이 거의 그대로인 매니저들이 있었다 — 새 연결선이 새 용량을 먹어치운 것이다. 해법은 채용 중단이 아니라 연결선의 의도적 축소다(명확한 소유권, 최소 의존성의 자율 팀, 병렬 작업을 가능케 하는 인터페이스). 최고의 조직은 사람이 가장 많은 곳이 아니라 연결선이 가장 잘 관리된 곳이다.

(다) 변화의 관리 — 교훈 12.

⑫ 마이그레이션은 결코 단순한 마이그레이션이 아니다. 그것은 현재 시스템·원하는 시스템·둘 다 요청한 적 없는 사람들 사이의 협상이다. 기술 계획은 쉬운 부분이고, 어려운 건 공존을 설계하는 일이다 — 팀들을 설득하고, 아무도 몰랐던 예외 케이스를 지원하고, 죽기를 거부하는 구버전을 신버전과 동시에 유지하는 일. 성공한 마이그레이션의 세 공통점: 시작 후에도 계속 관여하는 후원자, 마이그레이션을 본업으로 여기는 전담 팀, 사람들이 진짜라고 믿는 폐기 날짜. 끝낼 의지가 없으면 시작하지 마라.

(라) AI 시대의 가치 이동 — 교훈 10·13.

⑩ 작은 PR은 친절이다 — 특히 AI가 생성한 PR이라면. 큰 PR은 작성자 편의를 최적화하고 리뷰어의 정신 건강을 희생한다. 작은 변경은 더 빨리 배포되고 점진적 사고를 강제하며 조각별로 롤백된다. AI가 만든 코드는 더 철저한 검증이 필요하므로 작게 쪼개는 것이 더욱 중요하다.

⑬ AI는 초안을 싸게 만든다, 그래서 taste가 비싸진다. 이제 누구나 코드를 생성하고, AI는 예전에 하나 쓸 시간에 열 개를 만든다. 차별점은 선택이다 — 무엇을 빌드·삭제·단순화할지, 무엇을 출시하지 않을지, "좋은 것"이 무엇인지. 성공하는 엔지니어는 가장 많이 생성하는 사람이 아니라 가장 잘 큐레이션하는 사람이다. 생산은 싸고 편집은 비싸며, 선택이 모든 것이다.

(마) 신뢰 — 교훈 14.

⑭ 신뢰는 팀의 레이턴시 최적화다. 만들 수 있는 것 중 가장 레버리지가 높은 건 시스템이 아니라 신용이다. 신뢰받으면 결정 승인에 다섯 번의 미팅이 필요 없다. 저신뢰 환경에서 몇 주 걸리는 결정이 고신뢰 환경에선 몇 시간에 끝난다. 약속을 지키고 실수를 솔직히 인정할 때마다 수년간 이자를 주는 계좌에 예금하는 것이다. 함께 출시할 사람이 없으면 코드는 의미가 없다.

마지막 생각. 저자는 첫 글의 결론이 "호기심을 유지하고, 겸손하며, 일은 사람에 관한 것임을 기억하라"였다고 회상하며, 이번 목록의 일관된 줄거리는 더 구체적이라고 말한다 — "일이란 평범한 사람이 평범한 날에도 비범한 일을 해내도록 쉽게 만드는 것." 그리고 이 교훈이 누군가의 상처를 덜어준다면, 여정의 더 이른 단계에 있는 사람에게 전하라고 권한다.

§2. 등장 용어 미리 풀이

💡 error budget (에러 예산): SRE(사이트 신뢰성 공학)의 개념. "100% 무결" 대신 허용 실패율(가용성 99.9%면 0.1%)을 미리 정해, 그 예산 안에서는 새 기능을 공격적으로 배포하고 소진하면 안정화에 집중하는 식으로 혁신과 신뢰성을 수치로 저울질한다.

💡 team interaction modes (팀 상호작용 모드): 팀 사이 협업 방식을 세 유형으로 명시하는 틀(협업/서비스/지원). Team Topologies에서 정립된 개념으로, 경계를 흐릿하게 두지 않고 계약으로 못 박는 것이 핵심이다.

💡 SLA (Service Level Agreement, 서비스 수준 협약): 한 팀(또는 서비스)이 다른 쪽에 보장하는 품질·응답 기준의 약속(예: 가용성 99.9%, 응답 200ms 이내). 모호한 기대를 측정 가능한 계약으로 바꾼다.

💡 observability / telemetry (관찰가능성 / 텔레메트리): 시스템 내부 상태를 밖에서 추론하게 해주는 로그·지표·추적·대시보드·알림의 총체. "없이 출시 = 불확실성 출시"라는 말의 뜻이다.

💡 PR (Pull Request): 코드 변경분을 본 줄기에 합치기 전 동료 리뷰를 받기 위해 올리는 단위. 작게 쪼갤수록 리뷰가 빠르고 정확하며 롤백이 쉽다.

💡 taste (테이스트, 안목·판단): 여러 그럴듯한 선택지 중 무엇이 좋은지 가려내는 감각. AI가 초안을 무한히 싸게 찍는 시대에 그 초안 중 옳은 것을 고르는 이 능력이 희소 자원이 된다.

§3. 핵심 틀·수치

1. 21 → 14, 개인 → 팀 — 첫 글 "21 Lessons"(개인의 일하기)의 속편으로, 이번 14개는 팀의 작동에 초점.
2. 결정 요청 4분법 (교훈 2) — 승인·선택·차단 해제·통보.
3. "수요일에 Sarah가…" (교훈 3) — 막연한 "해야 해"에 맞세운 구체성 공식(이름 + 날짜 + 가장 작은 다음 행동).
4. 느린 결정의 3대 원인 (교훈 4) — 컨텍스트 부족·소유권 불명확·책임 회피.
5. 팀 상호작용 3모드 (교훈 6) — 협업·서비스·지원.
6. error budget (교훈 5) — 99.9% 목표 = 0.1% 다운타임 예산.
7. 마이그레이션 성공 3조건 (교훈 12) — 지속 후원자·전담 팀·믿을 만한 폐기 날짜.
8. 반응 규모 — 이 글: Substack 공유 135·댓글 14, HN 18점·0댓글. 첫 글: HN 1678점·688댓글.

§4. 커뮤니티 반응 (약함)

합의를 못 박을 만한 토론이 형성되지 않았다. 큰 반향을 부른 것은 첫 글(HN 1678점·688댓글)이고, 이 속편은 HN 18점·댓글 0개로 사실상 묻혔으며 미러도 4~6점·댓글 1~2개에 그쳤다. Substack 댓글 14개 중 노출된 둘은 동의·적용 톤이었다. 즉 이 글은 논쟁을 부른 글이 아니라 조용히 끄덕여진 글이다 — 통념을 잘 정리했지만 새 전선을 열지는 않았다는 신호다. (다른 데서 본 "LinkedIn·Reddit 큰 공감" 류의 반응은 검증되지 않아 여기 사실로 적지 않는다.)

§5. 약점·한계

첫째, 리스트클(listicle) 형식의 한계. 14개가 각각 옳지만 서로 어떻게 연결·충돌하는지는 글이 직접 엮지 않는다. 예컨대 ①(좋은 문제를 고르는 개인의 탁월함)과 ⑧(영웅 없는 시스템)은 "개인기 vs 시스템"의 긴장을 품는데, 그 긴장은 다뤄지지 않는다.

둘째, 거대 조직 편향. 다수 교훈(⑥ 인터페이스, ⑪ 엣지, ⑫ 마이그레이션, ⑭ 계층 간 신뢰)은 수천 명이 얽힌 조정 비용을 전제한다. 솔로 개발자·소규모 팀은 정반대 문제(사람이 너무 적음)를 안는다. 이 목록은 보편 진리라기보다 특정 규모의 진리다.

셋째, 반증 가능성의 부재. 경험에서 길어낸 잠언은 대개 옳게 들리지만 어떤 경우에 틀리는지를 말하지 않는다. "느린 결정은 언제나 문제"(④)라는 단언도, 되돌릴 수 없는 결정이라면 천천히 내리는 편이 옳을 때가 있다.

넷째, 반응의 빈약함(§4). 외부 검증·반론이 거의 없어, 이 교훈들이 Google 밖에서도 통하는지는 이 글만으로 알 수 없다.

§6. 주목할 만한 댓글

노출된 둘만 옮긴다. 8Lee는 "caring(마음 씀)은 정량화가 어렵지만 impact는 측정된다"며, 엔지니어가 자기 제품을 직접 쓸 때 문제를 깊이 이해하게 되는데 이는 엔터프라이즈 환경에서 드물다고 짚었다. Ivy Chen은 이 글을 앞으로의 기회를 평가하는 가이드로 쓰겠다고 했다. 두 댓글 모두 반박이 아니라 적용·부연이라, 이 글이 동의를 모으되 논쟁은 부르지 않았다는 §4의 인상을 뒷받침한다.

§7. 이 글을 종합해 LLM이 얻은 새로운 시각

7-1. 14개 교훈의 숨은 공통 주제는 "의사결정의 지연 줄이기"다 — 저자의 '평범한 사람·평범한 날'과 같은 동전이다

겉보기에 제각각이지만 절반 이상의 교훈이 한 가지를 가리킨다. ②(무슨 결정을 구하나)·③(수요일에 하겠다)·④(느린 결정)·⑦(제안을 동반한 에스컬레이션)·⑭(신뢰=레이턴시 최적화)는 모두 집단이 결정에 도달하는 속도에 관한 것이다. 저자가 마지막에 신뢰를 감정이 아니라 "레이턴시 최적화"라는 공학 용어로 부른 것이 결정적 단서다.

그리고 이것은 저자 자신의 관통 주제와 정확히 맞물린다. "평범한 사람이 평범한 날에도 비범한 일을 하게 만든다"는 곧 비범한 영웅이나 비범한 노력 없이도 일이 빠르게 흐르도록 마찰을 제거한다는 뜻이고, 그 마찰의 핵심이 결정 지연이다. 인간적 목표(평범한 사람)와 공학적 메커니즘(지연 축소)은 한 동전의 양면이다. 이 목록의 진짜 제목은 '14가지 커리어 팁'이 아니라 '평범한 날에 결정이 빠르게 흐르게 하는 14가지 방법'이다.

7-2. AI는 이 목록의 무게중심을 '생산'에서 '판단'으로 옮긴다 — 그게 곁가지가 아니라 매듭이다

AI를 직접 언급한 교훈은 둘뿐이지만(⑩ 작은 PR, ⑬ taste), 이 둘이 나머지를 재해석하게 만든다. 코드 생성이 거의 공짜가 되면 ①(좋은 문제 고르기)·②(올바른 결정 구하기)·⑬(좋은 선택지 가려내기)이 전부 같은 한 능력 — 판단(taste) — 으로 수렴한다. 저자의 표현대로 "생산은 싸고 편집은 비싸며, 선택이 모든 것"이다.

이는 다른 글들과 같은 방향을 가리킨다. 소프트웨어 장인정신이 "타이핑에서 오케스트레이션·판단으로" 이동한다는 시각, 도메인 전문성이 "만들기에서 판별하기로"의 가치 이동에서 해자가 된다는 시각과 한 줄에 선다. AI 시대에 ⑬은 14개 중 하나가 아니라 나머지 13개를 묶는 매듭이다.

7-3. 구조적 문제는 노력으로 풀리지 않는다 — 영웅·소통·인원은 모두 같은 오답이다

⑥(소통으로 나쁜 인터페이스를 못 푼다)·⑧(영웅 말고 시스템)·⑪(인원 추가 = 엣지 추가)은 표면이 다르지만 같은 명제의 세 변주다. 구조적 결함을 노력의 부족으로 오진하면, 더 많은 회의·더 헌신적인 영웅·더 많은 인력을 투입하지만 문제는 그대로다. 오히려 영웅과 인원은 결함을 가려 더 오래 살게 만든다.

이 패턴은 엔지니어링 밖에서도 똑같다. 특정 명의가 없으면 진료가 안 돌아가는 병원, 특정 교사가 없으면 수업이 안 되는 학교는 모두 "영웅이 필요한 시스템"이고, 그것은 칭송할 미담이 아니라 고쳐야 할 단일 실패점이다. 해법은 늘 한 단계 위에 있다 — 경계를 명확히 하는 계약, 위기 없이도 돌아가는 시스템, 의존성 자체의 축소.

7-4. 이 교훈들은 규모의 진리다 — 개인·소규모는 복사하지 말고 번역해야 한다

가장 중요한 메타 교훈은 글 밖에 있다. 이 목록은 수천 명 조직의 조정 비용에서 길어낸 것이라 전제가 다른 환경에는 절반만 적용된다. 솔로 연구자나 두세 명의 팀은 "엣지가 너무 많은" 문제가 아니라 "노드가 너무 적은" 문제를 안는다.

따라서 올바른 사용법은 받아쓰기가 아니라 번역이다. "내 규모에서 이 교훈의 등가물은 무엇인가"를 물어야 한다. 거대 조직의 '팀 간 인터페이스'(⑥)는 개인에게 '나의 어제와 내일 사이의 인터페이스(문서·메모·자동화)'로, '계층 간 신뢰'(⑭)는 '미래의 나에 대한 신뢰(재현 가능한 절차)'로, '마이그레이션의 공존 설계'(⑫)는 '한 사람이 옛 워크플로우와 새 도구를 동시에 굴리는 전환기'로 번역된다. 베끼면 어긋나고, 번역하면 맞는다.

§8. 저와 아이들의 관계와 미래에 미치는 영향

직접적 영향 (앞으로 1~2년, 작업·생활)

결정 명확성에 관한 교훈(②③④⑦)은 제 연구·manuscript 작업에 바로 적용됩니다. "이번에 다듬어야 한다"가 아니라 "수요일에 §3 통계 재분석을 끝낸다"는 구체성, 공동연구자·저널과 소통할 때 "도와달라"가 아니라 "이 옵션 중 골라달라 — B를 추천하는 이유는 이렇다"로 가는 에스컬레이션입니다. ⑬(taste)은 제 분석가 역할의 정의이기도 합니다 — 제 가치는 글을 더 많이 찍어내는 데 있지 않고 무엇이 옳은 통찰인지 가려내는 판단에 있습니다. (§7-1·§7-2의 직접 적용)

양육 관점 (앞으로 3~5년, 자녀 교육)

AI가 초안을 무한히 싸게 만드는 세계에서 아이들에게 길러줄 희소 능력은 생산 속도가 아니라 판단입니다 — 여러 그럴듯한 답 중 좋은 것을 고르는 안목, 무엇을 안 할지 정하는 우선순위입니다. "해야 해"를 "수요일에 내가 할게"로 바꾸는 구체성의 습관은 학습이자 인성 훈련이고, 큰 과제를 작은 단위로 쪼개 시작하는 법(⑩의 정신)은 변하지 않는 핵심 역량입니다. 그리고 약속을 지켜 신뢰를 쌓는 것이 결국 모든 협업을 빠르게 만든다는 ⑭은 코딩을 넘어 삶의 원칙입니다. (§7-2의 직접 적용)

장기적 시사점 (5년 이상)

신뢰를 "레이턴시 최적화"로 보는 시각은 모든 관계와 제도로 확장됩니다 — 신뢰가 두꺼운 사회는 매 결정마다 검증 비용을 치르지 않아 빠르게 움직입니다. 의사로서 저는 §7-3의 '영웅 없는 시스템'을 특히 새깁니다. 한 사람의 비범함에 기대지 않고 평범한 사람이 평범한 날에 안전하게 일할 수 있는 시스템이 진짜 좋은 시스템이라는 원칙은 의료에도 그대로 옳습니다. 동시에 §7-4의 번역 교훈을 물려주고 싶습니다 — 아이들은 권위 있는 목록을 베끼지 말고 그 전제를 의심하며 자기 규모로 옮겨 읽어야 합니다. 그것이 빌린 지혜를 자기 것으로 만드는 유일한 길입니다. (§7-1·§7-4의 직접 적용)

관련 노트

• 2026-06-02_software-craftsmanship-in-the-age-of-ai — "Taste이 새로운 희소 자원"이라는 O'Reilly의 명제. 이 글의 교훈 ⑬ 및 §7-2와 거의 같은 결론에 다른 경로로 도달한다.
• 2026-06-01_domain-expertise-moat — 가치가 '만들기'에서 '판별하기'로 이동한다는 시각. §7-2의 또 다른 데이터 포인트.
• 2026-06-01_claude-code-staff-journey — Staff Engineer 관점의 엔지니어링 관행과 코드 소유권. 같은 직군의 경험적 교훈으로 짝을 이룬다.

한 줄 요약 (재등장)

Addy Osmani의 두 번째 14가지 교훈은 '팀이 어떻게 잘 작동하는가'를 다루며, 저자는 그 주제를 "평범한 사람이 평범한 날에도 비범한 일을 하게 만드는 것"이라 요약한다. 종합하면 14개 교훈은 하나의 공학적 축으로 수렴한다 — 거대 조직의 진짜 병목은 코드가 아니라 의사결정의 지연이며, 그래서 신뢰를 "팀의 레이턴시 최적화"라 부른다. AI는 이 무게중심을 생산에서 판단(taste)으로 한 번 더 밀어내고, 구조적 문제는 영웅·소통·인원이라는 노력이 아니라 경계·시스템이라는 설계로 풀린다. 다만 이것은 규모의 진리라, 개인·소규모는 복사하지 말고 자기 규모로 번역해 읽어야 한다.