LinkedIn을 떠나며

• Chris Krycho는 LinkedIn에서 약 5년간 데스크톱 웹 앱의 프런트엔드 인프라와 개발자 경험을 맡으며, 대규모 코드베이스를 안전하게 바꾸는 일과 빠른 제품 실행 요구 사이의 충돌을 겪음
• 입사 당시 약 200만 줄 JavaScript였던 LinkedIn 데스크톱 앱은 이후 약 320만 줄 모노레포로 커졌고, 마이그레이션은 자동화와 제품팀 부담 최소화 없이는 현실적으로 어려웠음
• Ember 현대화와 TypeScript 도입은 오류 감소와 개발 품질 개선을 겨냥했으며, TypeScript 전환으로 애플리케이션 로그 오류량을 최소 25% 줄일 수 있다는 분석이 내부 설득에 쓰임
• Ember에서 React로 옮기는 계획은 Chris 팀의 3~5년 점진적 자동화 전략과, 더 빠른 제품 실험을 위해 기존 방식을 크게 다시 설계하려는 접근이 맞부딪힘
• 대규모 장애 대응 과정에서 알림, 관측성, 복원력, 코드 리뷰의 한계가 드러났고, Chris는 속도를 최우선으로 두는 조직 방향이 자신의 가치와 맞지 않아 떠남

---

5년간 맡았던 일과 코드베이스 규모

• Chris Krycho는 2019년 1월 말 LinkedIn에 합류해 약 5년 동안 근무함
• 담당 영역은 서버 인프라가 아니라 LinkedIn 데스크톱 웹 앱의 프런트엔드 인프라와 개발자 경험 개선이었음
• LinkedIn.com의 비모바일 브라우저 경험을 담당하는 데스크톱 앱에서 대규모 JavaScript 현대화 프로젝트를 이끎
• 이전 회사 앱은 약 15만 줄 규모였지만, LinkedIn 프런트엔드는 입사 당시 약 200만 줄 코드였음
• 같은 앱에 분기마다 150~200명 엔지니어가 커밋했고, 수십 개 팀이 하나의 제품을 계속 배포하는 구조였음
• 입사 당시 원격 엔지니어는 전체 수천 명 중 100명 미만이었고, Chris는 Colorado에서 원격으로 일하는 드문 사례였음

200만 줄 코드에서 마이그레이션하는 법

• 초기 대형 작업 중 하나는 Ember 기반 코드에 JavaScript의 현대적 class 문법을 도입하는 일이었음
• 기존 Ember 클래스와 네이티브 JavaScript 클래스가 상속 체인에서 섞이는 문제가 있었고, 내부에서는 이를 “Zebra Striping”이라고 부름
• 이 규모의 마이그레이션은 가능한 한 자동화되어야 했음
  • 200만 줄을 수동으로 고치려면 몇 달 이상 걸릴 수 있음
  • 제품팀에 기능 개발을 멈추고 새 문법 도입만 하라고 요구하기 어려움
• LinkedIn에는 여러 팀을 가로지르는 수평 이니셔티브(horizontal initiatives) 프로세스가 있었고, 제품팀 참여를 10% 이하로 유지하려는 운영 원칙이 있었음
• Chris 팀은 제품팀이 직접 코드 모드를 실행하는 방식보다, 인프라 팀이 자동화로 PR을 만들고 제품팀은 리뷰와 스모크 테스트를 맡는 방식이 더 쉽게 받아들여진다고 판단함
• Ember 관련 작업은 전체적으로 18개월이 걸렸고, 대부분은 6개월 안에 진행됐지만 일부 팀의 지연으로 긴 꼬리가 남음

TypeScript 도입을 설득한 오류 감소 논리

• Ember 현대화 이후 Chris 팀은 프런트엔드에서 발생하는 대량의 JavaScript 오류를 다음 대상으로 삼음
• LinkedIn은 오류 로그 규모가 커서 외부 서비스 대신 내부 로깅 인프라를 사용함
• LinkedIn은 전년도에 회원 수 10억 명을 넘겼고, Chris가 떠날 때 모노레포는 약 320만 줄 규모였음
  • 절반은 테스트 코드
  • 절반은 프로덕션 코드
• Chris 팀은 TypeScript가 잡을 수 있는 오류 범주를 따로 분석함
• 일부 오류는 TypeScript로도 잡을 수 없지만, 전체 마이그레이션을 마치면 하루 수백만 건 수준의 JavaScript 오류 중 애플리케이션 로그량을 최소 25% 줄일 수 있다고 봄
• Chris가 작성한 TypeScript 전환 문서는 엔지니어와 매니저 사이에서 반복적으로 공유됨
  • 해결하려는 문제
  • 기대할 수 있는 이점
  • 채용 경쟁력에서의 비교
  • 다른 우선순위와 비교할 판단 근거가 담김
• 이후 Chris는 까다로운 TypeScript 타입 문제를 도와주는 내부 전문가 역할을 맡게 됨

Ember에서 React로: 점진적 전환과 전면 재구상

• LinkedIn은 세계에서 가장 큰 EmberJS 사용자였지만, Chris의 업무는 결국 Ember에서 React로 옮기는 계획을 세우는 방향으로 바뀜
• 고위 리더들은 LinkedIn의 마이그레이션 비용이 너무 높고, 제품 속도를 늦춘다고 봄
• Chris 팀의 계획은 3~5년짜리 점진적 자동화 전략이었음
  • 제품팀이 거의 멈추지 않도록 자동화를 강화함
  • 빌드 파이프라인, 데이터 계층, 라우팅 계층, 반응성 시스템, 뷰 계층을 순서대로 분리해 전환함
  • 마지막에 Ember 렌더링·반응성 시스템을 React 쪽으로 바꾸는 흐름이었음
• 다른 팀은 속도 문제를 더 직접적으로 겨냥함
  • 아이디어에서 A/B 테스트까지 걸리는 시간을 몇 달에서 몇 주 수준으로 줄이는 것이 목표였음
  • 데스크톱 웹, 모바일 웹, iOS, Android의 서로 다른 스택과 긴 사이클 타임을 문제로 봄
• Chris는 그 팀의 접근을 “finger guns mode”에 가까운 태도로 받아들임
  • 수십 명을 지원하던 경험을 수백 명 엔지니어 지원으로 확장할 때 생길 문제를 충분히 다루지 않는다고 느낌
  • 질문에 대해 “문제가 되지 않을 것”이라는 식의 반응이 많았다고 봄
• Chris 팀의 3~5년 계획은 리더십에게 좋은 반응을 얻지 못함
  • 계획 자체가 길고 흥미롭지 않았음
  • 팀도 “가장 덜 나쁜 선택”처럼 제안했기 때문에 설득력이 약했음

장애 대응에서 드러난 복원력 문제

• Chris가 크리스마스 휴가에서 돌아온 뒤 LinkedIn 일부 사용자에게 최대 약 20분 동안 LinkedIn.com 페이지가 보이지 않는 문제가 발생함
• 문제는 클라이언트 코드를 Node.js로 실행해 백엔드 데이터를 모아 빠르게 전달하는 프리렌더링 서비스와 관련돼 있었음
• 서비스에는 메모리 누수가 있었고, 컨테이너가 메모리 한도를 넘으면 재시작되는 구조였음
• 장애를 키운 요인이 여러 개 겹침
  • 메모리 kill에 대한 알림이 충분하지 않았음
  • 동시에 재시작할 수 있는 컨테이너 수 설정이 YAML 파일의 키로 존재했음
  • 해당 값은 타입상 가능한 값이었지만, 이 시스템에는 잘못된 값이었음
  • 설정값이 사실상 실행 중인 서비스 전체 수에 가까웠음
• 배포 중단이 긴 주말처럼 오래 이어질 때 서비스들이 비슷한 시점에 메모리를 소진했고, 한꺼번에 재시작되며 사용자 요청을 처리하지 못함
• 일부 서버가 내려가면 남은 서버의 부하가 커지고, 그 서버들의 메모리 사용량도 더 빨리 증가해 데이터센터 단위로 서버가 내려가는 상황이 생김
• 동시에 fleet의 CPU와 메모리 사용량을 줄이는 리소스 적정화(rightsizing) 작업이 진행돼 여유 공간이 줄어든 상태였음
• Chris와 다른 엔지니어들은 더 나은 알림, 관측성, 복원력이 필요하다고 봄
  • Node 서버 하나가 runaway 상태가 되어도 호스트 프로세스까지 죽이지 않아야 함
  • Node 프로세스만 종료하고 알림을 낸 뒤 재시작하는 편이 안전함
  • 서비스가 내려가면 클라이언트 측 fetch로 넘어가는 대체 경로도 검토함

코드 리뷰만으로는 막을 수 없다는 충돌

• 장애 대응 회의는 주 여러 차례 진행됐고, 진행 상황을 공유하고 임원에게 보고하는 성격이 있었음
• 다른 팀의 매니저가 장애 대응을 맡으며 추가 인력을 투입했고, Chris는 자신과 기존 팀의 답을 신뢰하지 않는 흐름으로 받아들임
• 그 과정에서 한 시니어 엔지니어가 “왜 코드 리뷰가 이걸 해결하지 못하나?”라고 질문함
• Chris는 코드 리뷰만으로는 같은 일이 다시 발생하지 않도록 보장할 수 없다고 봄
  • 사람은 실수함
  • 주니어 엔지니어가 매우 시니어한 SRE의 PR에서 설정값이 합리적인지 의심하기 어려움
  • 시스템은 시니어 엔지니어의 가장 좋은 날뿐 아니라, 주니어 엔지니어의 나쁜 날에도 안전하게 작동해야 함
• Chris에게 소프트웨어 엔지니어링은 제품 결과를 내는 엔지니어를 지원하는 시스템 설계까지 포함함
• 기술적 장애와 조직적 의사소통은 분리되지 않았고, Charity Majors의 말처럼 고위 수준에서는 순수하게 사회적이거나 순수하게 기술적인 문제만 존재하지 않음

리더십, 원격 문화, 가치 충돌

• Chris는 자신의 팀과 접근법이 다른 팀의 제안에 밀렸다고 봄
• 다른 팀의 계획은 데스크톱과 모바일 앱을 모두 다시 생각하는 방향으로 커졌고, LinkedIn의 제품 구축 방식을 전반적으로 재검토하는 성격이 됨
• Chris는 그 제안을 더 좋게 만들고 싶었지만, 우려나 질문이 충분히 받아들여지지 않는다고 느낌
• 한 매니저에게 “너는 너무 이상주의적이고, 손익을 충분히 신경 쓰지 않으며, 가치를 바꿔야 한다”는 말을 들었다고 함
• Chris는 원격 근무가 관계 형성에 영향을 줬다고 봄
  • LinkedIn은 대면 문화가 강했고, 많은 사람이 카페테리아나 복도에서 자연스럽게 관계를 쌓음
  • 고위 엔지니어·임원과의 반복적인 물리적 접촉이 갈등 상황에서 차이를 만들 수 있다고 느낌
• Chris는 자신에게도 관계 형성의 약점이 있었다고 돌아봄

결국 떠난 이유

• Chris는 기존 코드베이스의 많은 문제가 속도를 과대평가하고 보조 경로의 문제를 고치거나 제거하지 않은 결과라고 봄
• 속도가 최우선 가치가 되면 초반 속도는 얻을 수 있어도 시간이 지나며 유지하기 어렵다고 판단함
• 그는 이전 직장에서 번아웃을 겪었고, 심한 편두통, 복통, 운동 불능, 갑작스러운 울음, 공황 발작을 경험했다고 함
• LinkedIn에서 계속 일하면 매일 분노하지 않으려고 애써야 하는 상태가 이어질 것이라고 봄
• 거대한 조직의 방향을 작은 노젓는 배로 바꾸려는 상황에 비유하며, 자신이 믿지 않는 방식과 일에 몇 년을 쓰지 않기로 결정함
• Chris는 LinkedIn에서 300만 줄 규모 앱, 대기업의 TypeScript 마이그레이션, 대규모 엔지니어링 문제를 배웠지만, 자신의 가치와 맞는 일을 찾기 위해 떠남

[GN⁺]

Hacker News 의견들

• 팟캐스트에서 가장 흥미로운 대목이 “너무 이상주의적이고, 손익에 충분히 신경 쓰지 않으며, 가치관을 바꿔야 한다”는 피드백이었다고 봄. 읽기 전에도 그런 인상을 받았고, 중간중간 가치 있는 피드백을 받았지만 일부러 무시한 것처럼 들림
  시니어 스태프 엔지니어에게 어려운 건 ‘맞는 것’ 자체가 아니라, 맞는 해법을 향해 조직 전체의 정렬을 만들어내는 일임. 2019년에 facebook.com을 React로 다시 쓰는 작업에 참여했기 때문에 이 이야기가 특히 흥미롭게 느껴짐

  • 이 말에는 어느 정도 진실이 있음. LinkedIn에서 배운 큰 교훈 중 하나가 내가 조직적으로 충분히 효과적이지 못했다는 점이었고, 개발자 경험 팀의 가장 큰 과제는 일을 비즈니스의 핵심 우선순위와 어떻게 정렬할지임
    소통은 어느 정도 해냈지만, LinkedIn에 있는 동안 그 정렬에는 크게 성공하지 못했음. 일부는 내 책임이고, 일부는 LinkedIn의 책임이기도 함
    다만 이 경우 “너무 이상주의적”이라는 말은 정말로 “손익에 직접 기여하지 않는 건 신경 쓰지 말라”는 뜻이었고, 그건 뼛속까지 거부함. 손익은 중요하지만 사용자 경험, 개발자 경험, 우리가 무엇을 만드는지에 대한 기본 윤리도 중요함
  • 시니어 스태프 엔지니어에게 어려운 건 맞는 것만이 아니라는 데 더해, 내가 생각하는 ‘맞음’이 월급을 주는 사람들에게 ‘맞는 것’과 일치하지 않을 수도 있음. 그걸 부정하는 건 어리석음
    조직에서는 자신이 옳다고 믿는 것을 최선을 다해 옹호하고, 다른 누군가나 합의체가 동의할지 결정함. 그 결과를 받아들이거나 타협할지, 아니면 떠날지는 내가 정하는 일이고, 커리어에서 둘 다 해봤음
  • 맞기도 하고 아니기도 함. 스태프 엔지니어, 특히 시니어 스태프 엔지니어급 역할은 들어간 조직의 세부 맥락에 가장 민감한 자리라고 봄
    유명 유니콘에서 매우 똑똑하고 합리적이며 친절한 시니어 스태프 엔지니어가 있었음. 연간 5천만 달러 규모로 쓰는 프레임워크를 v2에서 v3로 올리자고 밀었고, Python 2에서 3으로 가는 수준과 비교하면 아주 사소한 변경이었음
    조사 결과 기본적으로 10% 성능 개선을 기대할 수 있었는데도 경영진은 “버전 업그레이드에 시간 낭비”하기 싫어했음. 결국 그 엔지니어가 혼자 밀어붙여 한 달도 안 돼 미리보기 버전을 만들고, 두 달 안에 큰 효과가 나는 작업 일부를 이전해 자기 연봉의 몇 배를 절약함
    초기 정치 비용과 엔지니어링 비용이 치러지자 모두가 옮기고 싶어했고, 1년 뒤 배포가 끝났을 때 위의 관리 체계는 절반쯤 해고와 퇴사로 갈렸지만 그 엔지니어와 마이그레이션은 남아 있었음. 때로는 스태프 엔지니어가 고집을 부리는 게 아니라 미친 세상에서 유일하게 제정신인 사람일 수 있음
  • 해야 할 일은 해야 하지만, 여유와 개념적 일관성이 있다면 ‘정렬’이라는 이름으로 도저히 감수할 수 없는 희생도 생김. 많은 ‘맞는’ 해법에 대해서는 동의하지만, 핵심 가치에 어긋난다는 걸 이해하고도 받아들이지 않는 상황도 있음
    그런 자리에 있었고 참여하지 않을 수 있었지만, 항상 그렇게 할 수 있는 건 아님
  • 이 맥락만으로는 판단하기 어렵다고 봄. 정치가 복잡한 큰 조직에서는 사람들이 더 나은 자리로 가려고 움직이고, 심지어 다른 부서를 사실상 적대적으로 장악하기도 함
    최고의 아이디어나 계획이 없어도 올바른 연결고리, 올바른 점심 자리, 올바른 말로 경영진을 설득하는 경우를 봤음
    “너는 너무 이상주의적이고 손익에 충분히 신경 쓰지 않는다”는 말도, 누군가를 밀어내려고 낙인찍는 표현일 수 있음. 특히 그렇게 자신과 자기 아이디어를 상부에 팔아온 사람이라면 더 그렇다
    개인적으로 Facebook보다는 작지만 수백 명의 엔지니어와 큰 코드베이스가 있는 조직에서 Ruby, Rails, Postgres 관련 대규모 변경과 업그레이드를 여러 번 해봤고, Chris가 설명한 방법론은 매우 합리적이며 내가 성공적이라고 느낀 방식과도 맞음
    리더십 역할은 신뢰와 존중이 있어야 효과적이라는 데 동의함. 물론 그 신뢰가 유용하려면 실제로도 맞아야 함. 잘못된 방향으로의 진전은 진전이 아님

• LinkedIn 코드베이스를 모르고 일해본 적도 없지만, 무섭게 비슷하게 들리는 코드베이스와 조직·정치 구조를 여러 번 봤음. 그래서 보통 핑거건 방식을 옹호함
  핑거건식 재작성도 잘 구현할 수 있음. 같은 일을 하는 클라이언트가 여러 개라면 그중 하나를 다른 플랫폼의 기반으로 삼을 수 있고, 새로 시작하더라도 깨끗하고 빠르고 간결하게 할 수 있음
  성공의 핵심은 도메인 전문가이면서 기술 전문가인 소수의 베테랑 팀에 새 시스템을 맡기는 것임. 논쟁적이지만, 평범한 운영 유지 문제까지 포함해 모든 성공은 여기서 나온다고 봄. 나머지는 속도를 늦출 뿐임
  대부분의 기술 경영진이 반복하는 큰 문제는 다음 큰 시스템을 가장 경험이 적은 사람들에게 맡긴다는 점임. 핑거건 쪽에서 대칭적인 인터뷰도 들어보고 싶음

  • 경험 많은 사람들은 장애 대응과 운영 유지에 필요하기 때문에, 내가 일했던 대부분의 곳에서도 결국 가장 경험 적은 사람들이 새 시스템을 만들게 됐음
  • 소수의 베테랑 팀 방식에 반대하지는 않음. 다만 베테랑 팀은 기존 개념, 도구, 접근법에 깊이 투자돼 있는 경우가 많음
    그들이 이미 효과를 본 검증된 것들이니 자연스럽지만, 항상 최선은 아님. 게다가 베테랑 팀이 프로젝트를 시작해도 끝까지 남는 경우는 드물고, 결과나 후폭풍을 감당하지 않아도 된다면 결정을 내리기는 너무 쉬움
  • 시작하기 전에 모든 장애물을 어떻게 넘을지 알아야 한다는 태도와, 장애물 따위 없다는 태도 사이에는 분명 중간 지대가 있음
    계획에는 장애물을 다룰 현실적인 선택지가 있어야 하고, 그건 기술적 선택지만이 아니라 그 일을 할 사람의 시간과 역량까지 포함. 예를 들어 여러 팀이 서버를 운영하는 계획이라면 기술적으로는 가능해도 팀에 시간이나 역량이 없으면 현실적인 선택지가 아님
    반대로 모든 장애물을 피해가는 정교한 경로를 계획하는 것도 나쁨. 도착할 때쯤 장애물이 움직였을 수 있고, 길 위에 아직 모르는 장애물이 있을 수 있기 때문임. 한 가지 길만 계획했다면 거기서 멈춰버림
    다만 지금 보는 건 복잡한 아키텍처 논쟁을 만화처럼 요약한 팟캐스트 설명이라, LinkedIn에서 실제로 어떤 허수아비 논리가 가까웠는지는 알 수 없음
  • 제품 출시의 중요한 날짜를 맞추려고 3~4명이 회사가 1년 동안 못 한 일을 해냈고, 그 결과 너무 많은 사람의 심기를 건드려 퇴사하게 된 사람과 이야기한 적이 있음
    이사회가 엔지니어링 전체에 앞으로 어떤 프로젝트에서도 누구도 세부 사항을 지시할 수 없다고 말했다고 함
  • 글이 구체적이지 않아서 어느 쪽인지 판단하기 어렵지만, 5년 계획은 정말 안 좋게 들림

• Chris가 몇 가지 불운한 선택을 한 것처럼 들림. 5년 계획을 제안했고, 사건을 리더십이 아니라 비난으로 이끌었으며, 문제를 해결하기보다 문제에 대해 더 많이 말했고, 관계 구축도 부족했던 것 같음
  Chris에게 공감하는 한편, 이 환경에서 성과를 내는 법을 몰랐던 것처럼 보이기도 함. 그래도 괜찮음. 모두가 관료주의적 매듭 속에서 일하는 법을 배워야 하는 건 아니고, 스타트업은 그런 면에서 더 단순함
  큰 회사들이 시간이 지나며 날을 잃고, 어느 임원이 회의실에서 솔직한 부사장 하나 없이 전년 대비 -10% 손실을 마주하는 데는 이유가 있음

  • Chris 같은 사람, 그리고 나 자신 같은 사람을 어떻게 해석해야 할지 자주 흔들림
    이런 상황에 있어보면 심리적으로 방향 감각을 잃음. 내가 맞는 것 같은데 정말 맞나? 주변 사람들은 정말 그렇게 무능하고, 동료에게 배우는 데 관심이 없는가?
    몇 년 뒤 떠나서 돌아보면 그 사람들은 해고되거나 떠났고, 조직은 여전히 X를 못 하며, 이후 합류한 팀들의 민첩성과 역량은 실제로 존재했음
    한편으로는 오만함, 정치적 무능, 병적인 실무 문화에 적응하지 못함일 수 있음. 다른 한편으로는 그게 올바른 반응일 수도 있음
    조직이 병적인 문화 국면을 지나고 있다면, 재능 있고 신중하고 열정적인 사람들이 그 때문에 미쳐가는 게 맞을 수도 있음. 그걸로 미치지 않는 사람들은 생산성과 성장에 무관하거나, 더 나쁘게는 순손실일 수도 있음
    그래서 이런 환경은 심리극이 됨. 상황이 정말 이렇게 나쁜가, 아니면 내가 과민반응하는 건가
  • 에피소드에서 시간 때문에 잘린 뉘앙스를 조금 보충하자면, 5년 계획은 “ㅋㅋ”가 맞음. 마음을 얻을 수 없는 계획이었고 우리도 가장 싫어한 계획이었음
    하지만 임원진이 “우리가 요청한 마이그레이션이라도 제품 반복 속도를 전혀 늦추지 말라”고 말한 상황에서 가져갈 수 있다고 느낀 유일한 계획이기도 했음
    사건을 비난으로 이끌었다는 부분은 무슨 뜻인지 잘 모르겠음. 오히려 반대로 하려고 했고, 메모리 임계값을 낮춘 사람이나 YAML에 잘못된 값을 오타 낸 사람을 탓하지 않았음. 다만 다음 사람이 또 터질 때까지 근본 원인을 방치하지 말고 실제로 해결하자고 고집했음
    문제를 해결하기보다 말만 했다는 부분도 잘 모르겠음. 방송에서 내가 해낸 일을 길게 자랑하지 않았을 뿐, 거기서 해결한 문제들은 꽤 잘 해냈음
    관계 구축 부족은 에피소드에서도 말했듯 내 가장 약한 부분이었음. 엔지니어들과는 관계가 좋았지만, 특히 위쪽 관리층과 정치적 신뢰를 쌓는 데는 크게 실패했음
    그래도 단순히 그 환경에서 성과 내는 법을 몰랐기 때문이라고만 보진 않음. 성공할 수 있는 방식이 보였지만, 내가 믿지 않는 방식으로 행동하지 않겠다는 선택도 있었음. 내가 존경하는 엔지니어 중 상당수는 믿는 일을 위해서는 정치적 춤을 추지만, 믿지 않는 일을 위해서는 그렇게 하지 않음

• 지금 LinkedIn에서 일하고 있음. Chris의 역할과 팟캐스트는 Ember와 프런트엔드 웹 개발을 다루는 듯하고, 그가 말한 코드 줄 수와 빌드는 아마 LinkedIn의 모놀리식 대표 웹앱인 voyager-web일 가능성이 있음
  LinkedIn에는 수백만 줄 코드와 긴 빌드를 가진 시스템이 더 있음. 중간 계층, 오프라인 데이터 스택, 지표 시스템, 그리고 KafkaKafkaKafka 같은 것들임
  안타깝게도 17분 빌드는 꽤 좋은 편임. 일시적 인프라 장애 없이 17분이면 아주 좋음

  • LinkedIn 인프라에서 일했는데 내부 도구는 악몽이었음. Jugaad의 진짜 정의에 가까움
    회사 전체에 테스트 개념이 거의 없고 QA도 없음. 엔지니어들은 승진 자료에 넣으려고 반쯤 익은 프로젝트를 밀어 넣고 다음으로 넘어감
    내부 도구를 일상적으로 쓰면서 너무 많은 문제를 직접 해결해야 했고, 일을 하려는 엔지니어들이 사실상 QA가 되는 구조였음
  • 많은 사람이 이런 빌드 시간을 불변값처럼 본다는 게 가장 거슬림. 빌드·테스트·실행이 매 푸시마다 너무 오래 걸리니 하지 말자는 식임
    그 대신 빌드를 빠르게 만들거나 빌드 인프라를 더 빠르고 저렴하게 만들자는 쪽으로 가야 함
  • 다른 관점에서, LinkedIn을 포함해 몇몇 회사에서 백엔드 개발자로 일했는데 LinkedIn의 코드 품질은 아마 70~80퍼센타일 정도라고 봄
    적어도 내가 있던 팀에서는 코드 품질에 상당한 강조가 있었고 문화도 계속 나아지고 있었음. 다만 voyager 작업 하나를 해본 적이 있는데 그건 악몽으로 기억함
  • LinkedIn은 정확히 무엇이 되려는 건가? 2007년의 Facebook처럼 변하는 것 같은데, 의도적인가?
  • 코드베이스가 왜 이렇게 됐는지 궁금함. 플랫폼 팀이나 개발자 도구 팀 채용이 부족했던 건가?

• 대규모 재작성은 관리 가능한 코드베이스에서도 위험하고, 남은 찌꺼기는 끝까지 사라지지 않는 듯함. 몇 년 뒤 구석에 박힌 설정 페이지를 다시 쓰는 일로 누가 점수를 따고 싶겠나
  이런 시도를 너무 많이 봤으니 코드베이스 재작성용 프레임워크가 있을 법한데 없음. 자동 코드 수정 도구는 일관성을 요구하지만, 그런 일관성을 지킨 곳은 드묾. 코드 패턴은 시간이 지나며 너무 많이 진화해서 나이테를 보는 느낌임
  우리는 기본적으로 코드를 상자에 넣고, 상자를 재배치하며, 어떤 배치가 더 효율적이라고 타당하게 말하고 있음. 그런데 왜 더 나은 방법을 못 찾았을까? 자동화는 코드 수준에서 작동하지만 상자 수준에서는 작동하지 않음

• 이건 콘웨이의 법칙이 작동하는 사례임. 조직이 바뀌지 않았으니 같은 코드 수프를 다시 만들 가능성이 큼
  같은 배를 타본 입장에서, 긍정적인 엔지니어링 이니셔티브는 아주 높은 위치의 후원자를 통해 위에서 아래로 내려와야 함. 아래에서 위로 조직을 바꿀 수는 없고, 코드베이스를 만드는 건 결국 조직임

  • 위에서 내려오는 방식도 자체 위험이 있음. 큰 아이디어와 큰 변화는 위의 후원자, 아래의 좋은 이해, 중간 계층 전반의 충분한 정렬과 역량이 함께 있어야 가능함
    콘웨이의 법칙은 변하지 않지만, 반드시 공식 조직도에만 의존하지는 않음. 올바른 기술 리드와 유능한 관리자 사이에 임시 커뮤니케이션 구조를 만들면 다룰 수 있음
    다만 중간에 기술적으로 약하거나 자기 왕국을 세우려는 관리자 몇 명만 있어도 전체가 쉽게 망가지며, 회사의 생애주기에 따라 Pournelle의 관료제 철칙 때문에 이미 가망이 없을 수도 있음
  • 소프트웨어에 반복해서 닥치는 가장 큰 비극은 부실한 리더십임. 이상하게도 개발자들은 사람 문제를 더 나은 도구로 고칠 수 있다고 거의 항상 생각함
    예를 들어 개발자들이 전부 형편없으면 인기 있는 프레임워크를 주는 식임. 사람 문제를 다루지 않기 위한 핑계이고, 아이들이 어린이집을 운영하게 허락하는 꼴임
    탁월함을 원한다면 책임을 묻고 소유권과 보상·책임을 부과하는 규칙으로 높은 기준을 세워야 함. 복잡하지 않지만, 위에서부터 단호함과 충돌을 두려워하지 않아야 함
  • 콘웨이의 법칙과 그 함의를 파고들고 싶다면 Casey Muratori의 이 영상 에세이를 강력히 추천함: https://youtu.be/5IUj1EZwpJY?si=dPxsXieBwZsP0PPP
    다만 Microsoft 같은 회사가 뭔가를 만들고 나서 망치지 않을 희망을 전부 잃게 될 수 있음
  • 그래도 고위 후원자가 그 이니셔티브를 통과시키더라도 그 과정에서 번아웃될 수 있음. 나도 겪어봤음
  • 더 미묘하다고 봄. 아래에서 위로도 조직을 바꿀 수 있지만, 존재하지 않거나 초기 단계인 새 것일 때 가능함. 기존 것을 바꾸는 건 위에서 내려와도 매우 어려움

• LinkedIn에서 12년을 보냈음. 슬프게도 예전의 엔지니어링 조직과는 거리가 멂. Kevin Scott이 엔지니어링을 이끌던 시절은 비교하면 정말 좋았음

  • 이 규모의 회사 엔지니어들은 모두 똑같은 말을 함. 특정 문화 때문이라기보다 엔지니어링 팀의 성장이 어떤 문화든 악화시키는 쪽에 가깝다고 봄
  • Ryan Rolansky는 LinkedIn이 본질적으로 기능 완성 상태라고 말했음

• JavaScript 수백만 줄이라니, 그 자체가 비대함의 화신임
  LinkedIn 같은 걸 다시 구현하거나, 정확히는 “Facebook스러운” 기능 없는 내 연락처 데이터베이스를 만들 생각을 해왔음
  문제는 내 연락처들이 어떻게 대량으로 옮겨오게 하느냐임. 비대함과 별개로 Microsoft LinkedIn의 주된 문제는 연락처 정보를 내보내게 해주지 않는다는 점이고, 연락처 플랫폼이라면 이건 필수 기능임

  • 플랫폼 종속은 분명 의도된 것임. 사용자에게는 별로지만
  • LinkedIn은 원래 Ruby로 만들어졌고 코드가 6만 줄이었음
    https://queue.acm.org/detail.cfm?id=2567673
    요약: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
    LinkedIn은 2010년 초에 Node로 이전했음
  • 이상하게 들릴 수 있지만 그 숫자가 놀랍지는 않았음. 예전에 큰 은행에서 소비자 대상 JavaScript 웹앱을 다뤘는데 코드가 600만 줄이었음
    다만 이 스레드 반응을 보니 그 숫자가 틀렸던 건가 싶기도 함
  • 연락처를 얻으려고 브라우저로 오는 웹 서버 응답에서 JSON을 직접 긁어본 적 있나?
    LinkedIn에서는 해보지 않았지만, 공개 웹사이트에 올라온 콘퍼런스 참석자 목록을 내보낼 때 내가 쓰는 지저분한 요령임. 상황에 따라 다를 수 있음

• Chris Krycho가 비난 게임으로 가지 않고 자신의 어려움을 솔직하게 말하는 방식이 인상적이었음. CoRecursive는 코드 뒤의 복잡한 맥락을 다뤄서 좋아하는 팟캐스트 중 하나임

  • Adam도 훌륭한 진행자라고 봄. 좋은 질문을 하고 게스트가 말하게 둠
  • 개인적으로는 함께 일해보고 싶은 유형의 사람처럼 보임

• 거의 항상 힘든 소프트 리더십 역할처럼 들림. 무언가에 대해 “책임”은 있지만 조직 나머지에 대한 권한은 거의 없거나 전혀 없는 자리임
  실제 기술 리더십이 있다면 자리를 비웠거나, 오래 있었고 “시스템 전문가”라 해도 실제 문제와는 더 이상 맞닿아 있지 않은 상태일 수 있음. 겪어봤고, 다시는 사양임