Hacker News 의견들

• 이번 “mandatory meeting”은 매주 열리는 전사 운영 회의임
  지난주 큰 운영 사고가 있었기 때문에 이번 주 참석률이 높을 뿐임
  언론이 너무 과장하고 있는 느낌임

  • 내부 사정을 알고 있을 때 뉴스 보도를 보면 항상 현실감이 다르게 느껴짐
  • 기사에서는 “보통은 선택 참석이지만 이번엔 참석 요청이 있었다”고 했는데, 그건 사실인지 궁금함
    또 “주니어와 미드레벨 엔지니어의 AI 코드 변경은 시니어 승인 필요” 정책도 언급되었음
    정기 회의라도 새 정책 발표가 있다면 뉴스 가치가 있다고 생각함
  • 뉴욕에서는 지난 금요일 오후 내내 Amazon 스토어프론트가 다운되었음
    가격이 표시되지 않고 장바구니에 담을 수도 없었음
    Walmart 같은 경쟁사였다면 뉴스에 나왔을 텐데 이상함
  • 이 스레드는 다른 제목의 글에서 합쳐진 것 같음. 댓글 시간대가 원글보다 훨씬 이전임
  • “언론이 과장한다”는 말에 동의함. 케이블 뉴스가 생긴 이후로 늘 그랬음

• “주니어와 미드레벨 엔지니어는 시니어 승인 없이 AI 코드 푸시 불가”라는 정책은
  시니어 리뷰가 만능이라는 착각에서 비롯된 것 같음
  실제로 시니어가 코드를 완전히 검증하려면 직접 작성하는 데 드는 시간과 비슷함
  즉, 리뷰는 가치 있지만 나쁜 코드를 좋은 코드로 바꾸지는 못함
  결국 “idiot proof” 시스템을 만들면 ‘idiot’을 고용해도 된다는 오해가 생기는 게 문제임

  • 경력 초반에 멘토가 “코드 리뷰는 버그 잡는 게 아니라 맥락 공유가 목적”이라고 했음
    버그 발견은 부수 효과일 뿐이고, 진짜 중요한 건 테스트를 쉽게 만들고 코드 복잡도를 줄이는 일임
    하지만 이런 일은 승진에 도움이 안 됨
  • AI 코드가 쓸 만하려면 전문가 리뷰가 필수임
    모델이 작업 중일 때부터 감시해야 효율적임
    그렇지 않으면 AI는 품질 낮은 코드 폭탄을 쏟아냄
    전문가가 5~15배의 시간을 들여 수정하면 괜찮지만, 그렇지 않으면 코드베이스가 망가짐
  • 남의 코드를 리뷰하는 건 종종 직접 작성하는 것보다 더 느리고 혼란스러움
    특히 나쁜 코드는 이해하는 데 시간이 배로 듦
  • 엉성한 코드를 고치는 건 새로 쓰는 것보다 어렵다고 느낌
    기존 코드와 새 해결책을 동시에 머릿속에 두고 비교해야 하므로 인지 부하가 큼
  • AI가 주니어 생산성을 10배 높인다면, 시니어를 10배 늘릴지 주니어를 줄일지 고민해야 함
    결국 기업이 평균 성과 관리 중심으로 변하는 자연스러운 진화 같음

• Amazon 내부에서는 대부분이 해고되지 않기와 승진만 신경 씀
  개발자 평가는 “티켓 처리 속도”, “PR 코멘트 수”, “문서 작성”으로 결정됨
  AI를 쓰지 않으면 경쟁에서 밀림
  이런 구조에서 “AI 사용 자제” 요청은 현실적으로 작동하기 어려움

  • PR에 코멘트가 너무 많아도, 남의 PR에 코멘트를 안 남겨도 불이익을 받음
  • PR에 논의가 많다는 건 협업 없이 혼자 일했다는 신호일 수도 있음
    잘 협업하는 팀일수록 PR 논의가 적음
  • 결론: 헝거게임식 경쟁 문화에서는 일하지 말아야 함

• 진짜 필요한 건 self-review 프로세스라고 생각함
  AI가 작성한 코드를 그대로 푸시하는 건 위험함
  GitHub 같은 곳에 “self-review 필수” 옵션을 추가해, 작성자가 직접 검토했음을 명시해야 함

  • 단순히 AI 출력만 훑어보는 건 리뷰가 아님. Heinlein식 ‘grok’ 수준의 이해가 필요함
  • 나는 git과 Sublime Merge를 쓰며 편집과 리뷰를 분리하는 습관을 들였음
    로컬 UI가 빠르다 보니 프로젝트 흐름을 더 잘 파악하게 됨
  • 자기 코드도 안 읽는 사람에게 버튼 하나 더 추가해봤자 소용없음
  • self-review만으로도 디버그 출력 같은 실수를 잡을 수 있음
  • 우리 팀은 PR 템플릿에 self-review 체크리스트를 넣었음
    당연한 일 같지만 실제로는 도움이 됨

• Amazon의 리더십 신뢰도가 떨어지고 있음
  베테랑 퇴사, AI 품질 저하, 잦은 장애로 인해 엔지니어링이 무너지는 인상임

  • 오랜 시니어들이 AI 코드 리뷰만 하며 시간 보내고 싶지 않은 건 당연함

• 의사결정자들이 파이프라인 병목을 이해하지 못하는 듯함
  AI가 10배 빠르게 diff를 만들어도 리뷰가 병목이면 전체 속도는 같음
  결과적으로 비용과 불확실성만 증가함

  • 다음 단계는 “AI가 AI 코드를 리뷰”하자는 아이디어일 듯함

• AI 코드 리뷰를 PR 단계에서 하게 되면 생산성 이점이 사라짐
  AI는 10분 만에 기능을 만들지만, 사람 리뷰는 10~20배 시간이 듦
  진짜 어려운 건 “무엇을 왜 만드는가”와 “제대로 만들었는가”를 아는 것임
  AI는 이 두 가지를 아직 못함

  • CEO 입장에서 보면, 결국 사람이 직접 검토해야 한다면 AI 속도 이점이 무의미함
    LLM이 생산과 리뷰를 모두 잘할 때까지는 리스크만 커짐
  • 시니어가 모든 PR을 승인해야 한다면 전문 코드 리뷰어가 되는 셈임
    현실적으로 불가능한 정책임
  • AI 옹호자들은 언젠가 모델이 개선되어 리뷰 병목이 사라질 것이라 믿음
    그때는 테스트 후 바로 배포하는 시대가 올 것이라 함
  • 리더십이 이런 현실을 모른다는 게 놀라움
  • 사실 리더십도 알고 있을 것임. 코드 품질 저하를 막기 위한 브레이크일 뿐임

• 코드 리뷰의 본질은 에러 탐지가 아니라 팀 동기화와 학습임
  리뷰를 통해 설계와 표준을 공유하고, 주니어를 교육하며, 다양한 시각을 반영함
  이런 과정이 에러 자체를 줄이는 핵심임

  • 데밍의 말처럼 “검사는 품질을 개선하지 않는다”는 원칙이 소프트웨어에도 적용됨
    잘못된 설계 방향으로 가면 되돌리기 어렵기 때문임

• AI 열풍에 쏟는 시간과 비용이 너무 큼

  • 하지만 지금은 쫓을 다른 대상이 없음
  • 코드를 검증하지 않는 건 결국 도박과 같음

• 앞으로 중요 인프라 소프트웨어는 어떻게 될까 걱정됨
  항공 소프트웨어도 이런 흐름에 휩쓸리면 치명적 결과가 날 수 있음

  • 그래도 핵심 인프라 코드는 여전히 사람 중심으로 작성될 것임
    AI는 품질 향상을 위한 보조 도구로 쓰일 가능성이 큼