Hacker News 의견들

• “규모가 커지면 버그에도 사용자가 생김”이라는 말이 떠오름
  첫 직장에서 로드타임을 5분에서 30초로 줄였을 때, 고객들이 불만을 터뜨렸던 일화가 있었음
  예전엔 컴퓨터 켜놓고 커피 마시며 잡담하던 시간이 사라졌기 때문임
  이 이야기의 교훈은 단순히 개선하지 말라는 게 아니라, 소프트웨어는 실제 사람들의 습관과 상호작용 속에 존재함을 잊지 말라는 것임
  엔지니어의 일은 티켓을 처리하는 게 아니라, 진짜 사용자 문제를 해결하는 것임

  • 나도 창고 자동화 프로젝트를 맡았을 때 비슷한 경험을 했음
    효율을 높일수록 직원들이 더 많은 육체노동을 해야 해서 오히려 불만이 생겼음
    결국 나는 ‘좋은 시스템을 망친 사람’으로 보였음
  • 이 개념은 Hyrum’s Law에서도 잘 설명됨
    “충분히 많은 사용자가 있다면, 시스템의 모든 관찰 가능한 동작은 누군가에게 의존 대상이 됨”이라는 말이 있음
  • 내 비즈니스도 한때 Microsoft와 Netscape의 공통 버그에 의존했음
    매번 “이번엔 고치겠지”라 생각했지만, 10년 동안 고쳐지지 않아 오히려 사업이 유지됐음
  • Lehman은 개발자–소프트웨어–사용자 삼각 관계를 이야기했음
    세 주체는 문제를 서로 다르게 이해함
    코드의 의미는 의도나 희망으로 바뀌지 않으며, 현실 세계의 제약 속에서만 작동함
    관련 글: Laws of Software Evolution
  • “티켓을 처리하는 게 아니라 문제를 해결하는 게 일”이라는 말에 공감함
    하지만 모든 회사가 그렇게 생각하지 않음
    면접 때 기대치를 명확히 파악하는 게 중요함

• Addy Osmani가 쓴 글을 보고 약간의 위선을 느꼈음
  예전에 내 코드를 표절했고, 나중에 사과문을 올렸지만 SNS에는 공유하지 않았음
  진심 어린 사과라면 팔로워들에게도 공개해야 한다고 생각함

  • 실제 사과문 자체는 잘 써졌다고 봄
  • “그냥 잊자”는 반응도 있었음. “그게 그렇게 큰 일은 아니지 않냐”는 식으로 말함

• 처음 세 가지 교훈이 특히 와닿았음

  1. 최고의 엔지니어는 사용자 문제 해결에 집착함
     교육 과정에서 언어와 프레임워크만 배우고 문제 자체를 배우지 않는 게 문제임
  2. 옳음은 싸게 얻을 수 있지만, 함께 옳아지는 과정이 진짜 일임
     합의는 창의적 과정에서 쌓이고, 권력은 위기 때 쓰여야 함
  3. 행동 편향. 일단 Ship해야 함
     실패를 두려워해 논쟁만 하다 시간 낭비하는 경우가 많음

• “Boring Technology” 에세이에서 ‘혁신 토큰’ 개념을 처음 배웠음
  boringtechnology.club 글인데, 여전히 내가 가장 좋아하는 아키텍처 글 중 하나임
  “추상화는 복잡성을 제거하지 않고, 단지 당신이 온콜일 때로 옮긴다”는 말은 Joel Spolsky의 Law of Leaky Abstractions을 떠올리게 함

• 리더십 15년 동안 대형 리테일 기업에서 수십억 달러 규모의 시스템을 운영했음
  하지만 결국 중요한 건 정치와 인간관계였음
  더 똑똑한 사람들도 정치 못 해서 승진 못함
  아이들에게 “정치와 아부를 배워라”고 가르쳐야 한다는 씁쓸한 결론임

  • 어떤 이는 “차라리 그런 세상에서 벗어나 의미 있는 일을 하라”고 함
  • 또 다른 이는 “정치인을 불신하고 스스로 강해져라”고 조언함
  • 다른 사람은 “그건 단순히 인간관계 기술임”이라며, 영향력을 배우는 게 중요하다고 말함
  • 반면 “그런 게임 자체를 거부한다”는 의견도 있었음

• “Clarity is seniority”라는 말에 깊이 공감함
  명확함이 유지보수성과 확장성의 핵심임
  나는 이를 가르치는 책 Elements of Code를 썼음
  추상화는 나쁜 게 아니라 목적의 명확성이 문제임
  지형을 보지 않고 창고 안에서 다리를 짓는 토목기사와 같음
  추상화 자체를 탓할 게 아니라, 무엇을 모델링하려는지 이해해야 함

  • 나도 추상화의 위험성에 동의함
    잘못된 추상화는 오히려 명확성을 해치며, 불필요한 복잡성을 낳음
    차라리 부족한 추상화가 낫다고 생각함

• 이런 리스트의 진짜 가치는 직접 써보는 것임
  읽는 것만으로는 금세 잊히고, 스스로 커리어를 돌아보며 정리해야 의미가 생김

• 이 글은 Google의 공식 가치가 아니라, Google에서 일하며 배운 개인적 교훈임
  조직이 가르친 게 아니라, 경험 속에서 스스로 깨달은 것들임
  대기업에서도 여전히 어려운 부분들이라는 점이 핵심임

• “규모가 커지면 버그에도 사용자가 생긴다”는 건 ossification(경직화) 현상과 같음
  네트워크 프로토콜뿐 아니라 모든 시스템에 적용됨
  HTTP/3와 QUIC의 암호화 설계 이유도 중간 장치가 잘못된 가정을 하지 못하게 하기 위함임
  API도 마찬가지로 내부 상태를 노출하지 말아야 함

  • 이는 Hyrum’s Law와 유사한 개념임

• “Bias towards action” 문장이 인상 깊었음
  아무리 좋은 조언도 빈 페이지에는 도움이 안 됨
  일단 뭔가 만들어야 피드백을 받을 수 있음

  • 나도 그 문장을 좋아함
    첫 글자를 입력하는 순간, 예상치 못한 문제들이 드러남
    거대한 조직일수록 이런 보이지 않는 병목이 많음
  • 하지만 Google은 품질과 성능에도 더 편향됐으면 좋겠음
    “Ship fast”가 “엉성하게 내보내라”는 뜻은 아님
    완성도 높은 최소 기능 제품이 오히려 낫다고 생각함
  • 여러 회사에서 “행동 편향”을 내세웠지만, 실제로는 야근과 불량 릴리스로 이어졌음
    현실과 이상 사이의 간극이 크며, 글쓴이는 “Kool Aid가 맛있었다”고 풍자함
  • 내 버전은 “존재 자체가 가장 중요한 기능”임
  • 하지만 팀 전체가 같은 마인드여야 함
    그렇지 않으면 “날림”으로 오해받고, 문제 생기면 희생양이 됨