1P by neo 9달전 | favorite | 댓글 1개
  • 일을 제대로 하는 것과 회사의 빠른 속도가 충돌할때 당신의 선택은?
  • 신념을 지키고 타협할 것인지, 원칙에 맞는 일을 찾아 떠날지에서 후자를 선택한 엔지니어 Chris Krycho의 이야기
  • 크리스는 결국 자신의 원칙에 부합하는 일을 추구하기 위해 링크드인을 떠났음
  • 팟캐스트에서 이야기한 내용을 정리
  • 그의 이야기는 "혁신의 필요성"과 "프로젝트 건전성의 중요성" 사이의 긴장을 강조함

크리스 크라이초의 링크드인에서의 첫 날

  • 크리스는 2019년 1월 말에 링크드인에 합류. 큰 회사나 건강한 소규모 회사에서 흔히 볼 수 있는 다양한 온보딩 과정을 거침.
  • 크리스는 콜로라도에서 원격으로 근무할 예정이었으나, 처음 두 주는 온보딩과 팀과의 시간을 보냄.

수백만 줄의 코드

  • 이전 회사에서의 경험과 비교했을 때, 링크드인의 프론트엔드 클라이언트 앱과 백엔드 서비스의 규모에 크게 놀람.
  • 링크드인의 프론트엔드는 2백만 줄에 달하며, 이는 이전 회사의 전체 코드보다 훨씬 많음.

인프라 팀

  • 크리스의 역할은 인프라 팀에서, 서버 구축이 아닌 엔지니어링 지원 또는 개발자 경험 개선에 초점을 맞춤.
  • 링크드인의 대규모 데스크탑 앱을 보다 쉽게 작업할 수 있도록 지원하는 것이 목표.

자바스크립트 현대화

  • 자바스크립트 클래스 도입을 통한 코드 현대화 작업에 참여. Ember 프레임워크를 사용하면서 생기는 문제를 해결하는 과정에서 많은 것을 배움.
  • 대규모 코드베이스에서의 마이그레이션 작업은 가능한 한 자동화되어야 하며, 이는 수작업으로 처리하기에는 너무 큰 작업량임을 깨달음.

타입스크립트 도입

  • 프론트엔드에서 발생하는 오류를 줄이기 위해 타입스크립트로의 이동을 결정함.
  • 타입스크립트는 점진적으로 도입할 수 있으며, 이는 링크드인이 필요로 하는 확장성을 제공함.

느린 마이그레이션 계획 대 'Finger Gun's Plan'

  • 크리스와 그의 팀은 Ember 코드를 React로 마이그레이션 하는 3~5년 계획을 제안했으나, 다른 팀에서는 전체적인 재고와 빠른 속도를 약속하는 'Finger Gun's Plan'을 제시함.
  • 이러한 접근 방식의 차이는 크리스와 그의 팀이 겪는 문제와 회사의 속도를 우선시하는 문화 사이의 갈등을 반영함.

크리스의 경험과 배움

  • 부족한 알림 문제 인식.
  • 메모리 사용량 증가와 서버 재시작의 연쇄 반응으로 인해 전체 데이터 센터의 서버가 다운됨.
  • 시스템의 재설정과 권한 조정을 통해 문제 해결을 시도함.
  • 실패는 불가피하며, 소프트웨어 엔지니어링은 엔지니어가 제품 결과물을 만들어내는 과정을 지원하는 시스템을 설계하는 것임.
  • 다중 계층의 복원력을 갖춘 시스템 필요성 강조.

사건에 대한 반발

  • 문제 해결 과정에서 관리의 신뢰 부족으로 인한 불만 발생.
  • 고위급 엔지니어와의 의견 불일치 및 소통 문제.
  • 시스템이 최고의 상태에서만 작동하는 것이 아니라, 모든 상황에서 지원할 수 있어야 함을 강조.

압력 증가

  • 기술적 부채 해결과 복원력 향상을 위한 노력에도 불구하고 경영진의 불만 증가.
  • 복잡한 문제에 대한 단순한 해결책을 요구하는 경영진과의 갈등.

조직 재편

  • '핑거건스 팀'으로 인한 조직 재편과 역할 변화.
  • 다른 역할에서의 새로운 경험과 학습 기회 인식.

반성과 자각

  • 과거의 경험과 현재 상황을 통한 자기 반성.
  • 인간 관계 구축과 소통의 중요성 인식.
  • 기술적 문제와 사회적 문제가 서로 연결되어 있음을 이해.

결론 및 교훈

  • 크리스는 속도를 최우선 가치로 삼는 문화에 대한 비판적 시각을 유지.
  • 경력과 개인의 가치에 대한 성찰을 통해 새로운 기회 모색.
  • 엔지니어링 우수성을 추구하는 역할을 찾기 위한 크리스의 여정은 계속됨.

GN⁺의 의견

  • 크리스 크리초의 경험은 기술적 원칙과 비즈니스 요구 사이의 갈등을 잘 보여줌.
  • 그의 결정은 개인의 가치와 직업적 선택 사이의 균형을 찾는 것의 중요성을 강조함.
  • 링크드인과 같은 대규모 기술 환경에서의 변화 관리는 복잡하며, 이는 다른 기업들에게도 중요한 교훈을 제공함.
  • TypeScript와 같은 기술 도입은 코드 품질을 향상시키고 오류를 줄이는 데 도움이 될 수 있으나, 대규모 코드베이스에서는 점진적인 접근이 필요함.
  • 이러한 기술적 변화를 추진할 때는 개발자 경험과 제품 출시 속도 사이의 균형을 고려해야 함.
Hacker News 의견
  • 한 관리자와의 대화에서 '너는 이상주의적이고, 수익을 충분히 중요시하지 않으며, 가치관을 바꿔야 한다'는 말을 들었다고 한다. 이에 대해 거부감을 표현하며, 자신의 가치관을 고수하겠다는 의지를 밝혔다. 이 발언은 팟캐스트에서 가장 흥미로운 부분으로, 저자는 이를 통해 중요한 피드백을 의도적으로 무시한 것 같다는 인상을 받았다고 한다. 경력에서 배운 교훈은 옳은 것을 아는 것이 어려운 것이 아니라, 옳은 해결책으로 조직 전체의 일치를 이루는 것이 진정 어려운 문제라는 것이다.

    • 관리자와의 대화에서 가치관 충돌을 경험한 사례
    • 중요한 피드백을 의도적으로 무시한 인상
    • 옳은 해결책에 대한 조직 전체의 일치가 중요한 교훈
  • 2019년에 facebook.com을 React로 재작성하는 작업에 참여했다. LinkedIn의 코드베이스나 조직에 대해 직접 알지는 못하지만, 유사한 코드베이스와 조직 구조를 가진 회사들을 본 경험이 있다. '핑거 건' 접근법을 지지하는데, 이는 잘 구현될 경우 긍정적인 결과를 가져올 수 있다. 여러 클라이언트가 동일한 작업을 시도할 때, 하나를 기반으로 다른 플랫폼을 서비스할 수 있다. 또는 새로 시작할 때, 깨끗하고 빠르며 간결한 방식으로 할 수 있다. 성공의 일반적인 요소는 베테랑 소규모 팀이 새로운 시스템을 만드는 것이며, 도메인 전문가와 기술 전문가가 결합된 소규모 엔지니어 팀에서 성공이 나온다고 믿는다. 기술 관리에서 반복되는 큰 문제는 가장 경험이 적은 사람들이 다음 큰 시스템을 구축한다는 것이다.

    • React로의 재작성 경험 공유
    • '핑거 건' 접근법과 소규모 베테랑 팀의 중요성 강조
    • 경험이 적은 사람들이 큰 시스템을 구축하는 문제 지적
  • 큰 재작성은 관리 가능한 코드베이스에서도 위험하며, 잔여 문제들이 완전히 사라지지 않는다. 몇 년이 지난 후에 숨겨진 설정 페이지를 다시 작성하려는 사람은 누구인가? 코드베이스를 재작성하는 프레임워크가 있었으면 좋겠지만, 실제로는 없다. 자동화된 코드모드는 일관성을 요구하는데, 이를 준수하는 경우는 드물다. 시간이 지남에 따라 코드 패턴이 많이 변화했기 때문에, 마치 나무의 나이테를 보는 것 같다. 코드를 상자에 넣고 재배열하는 것이지만, 상자 수준에서는 자동화가 이루어지지 않는다.

    • 코드베이스 재작성의 위험성과 잔여 문제들
    • 코드 재작성을 위한 프레임워크 부재
    • 코드 수준의 자동화와 상자 수준의 자동화 사이의 간극
  • 현재 LinkedIn에서 일하고 있으며, 팟캐스트에서 언급된 Chris의 역할과 프론트엔드 웹 개발은 ember와 관련이 있다고 생각한다. LinkedIn의 모놀리식 플래그십 웹 앱인 voyager-web을 언급하는 것 같다. LinkedIn에는 voyager-web 외에도 수백만 줄의 코드와 긴 빌드 시간을 가진 시스템이 많다. 예를 들어, 중간 계층, 오프라인 데이터 스택, 메트릭 시스템, Kafka 등이 있다. 17분 빌드 시간은 꽤 좋은 편이며, 일시적인 인프라 실패 없이 17분이면 매우 좋은 것이다.

    • LinkedIn에서의 현재 근무 경험 공유
    • 다양한 시스템과 빌드 시간에 대한 설명
    • 17분 빌드 시간에 대한 평가
  • 수백만 줄의 JavaScript 코드는 과도한 부피를 의미한다. LinkedIn과 같은 서비스를 재구현하거나 자신만의 연락처 데이터베이스를 만들고 싶은 생각이 들었다. 문제는 연락처를 대량으로 이전하는 방법이다. Microsoft LinkedIn의 주요 문제 중 하나는 연락처 정보를 내보낼 수 없다는 것이며, 이는 연락처 플랫폼에서 반드시 필요한 기능이다.

    • JavaScript 코드의 과도한 부피 지적
    • 연락처 정보 이전의 어려움
    • 연락처 정보 내보내기 기능의 중요성
  • LinkedIn에서 12년을 보냈지만, 이제는 과거의 엔지니어링 조직과는 거리가 멀다. Kevin Scott이 엔지니어링을 이끌던 시절이 훨씬 낫다고 평가한다.

    • LinkedIn에서의 장기 근무 경험
    • 과거의 엔지니어링 조직과 현재의 차이점
  • Conway의 법칙이 작용하는 상황이다. 조직이 변하지 않는 한, 같은 코드 혼란을 다시 만들어낼 것이다. 긍정적인 엔지니어링 이니셔티브는 상위에서 내려와야 하며, 매우 고위급의 지지가 필요하다. 조직을 하단에서 상단으로 바꾸는 것은 불가능하며, 조직이 코드베이스를 만들어낸다.

    • 조직 변화 없이 코드 혼란 재발 가능성
    • 상위에서의 긍정적인 엔지니어링 이니셔티브 필요성
  • Chris Krycho가 자신의 어려움에 대해 솔직하게 이야기하면서도 비난 게임을 하지 않는 태도에 깊은 인상을 받았다. CoRecursive는 코드 뒤에 복잡한 맥락을 탐구하는 것으로 내가 좋아하는 팟캐스트 중 하나이다.

    • Chris Krycho의 솔직한 태도와 비난 회피
    • CoRecursive 팟캐스트에 대한 긍정적인 평가
  • Ember에서 React로의 이전은 내가 이전에 일했던 클라이언트가 만든 기술에 적합한 사례로 보인다. 그는 'Unhack'이라는 언어를 만들어 AST 수준에서 검색 및 대체를 할 수 있게 했다. 원본 코드에서 패턴을 지정하고, 그것을 대체할 다른 패턴을 지정하는 언어를 사용했다. 몇 년 전 그 클라이언트와의 작업을 중단했기 때문에 현재 존재하는지는 모른다.

    • Ember에서 React로의 기술 이전 사례
    • AST 수준에서의 검색 및 대체를 가능하게 하는 'Unhack' 언어
  • LinkedIn의 코드베이스가 어지럽다는 것은 웹사이트를 사용해보면 놀랄 일이 아니다. 관심 있는 게시물을 클릭하고, 글을 쓴 사람에 대해 더 알아보려고 한 다음 뒤로 가기를 누르면 피드가 새로고침되어 게시물을 잃어버린다. 받은 메시지를 스크롤하려고 하면 전체 웹페이지가 느려지고 입력을 등록하는 데 10-15초가 걸린다. 왜 30개의 가짜 알림을 받는가? 이들은 사람들로부터 상호작용을 강요하기 위해 만들어진 가짜 알림이다. 추천 알고리즘도 완전히 끔찍하다.

    • LinkedIn 웹사이트 사용의 어려움
    • 가짜 알림과 느린 웹페이지 반응 속도
    • 추천 알고리즘의 문제점 지적