TL;DR

  • 대형 기술 기업의 엔지니어링에서 회의·설계 문서·업무 분배보다 먼저 갖춰야 할 토대는 조율 비용 없이 직접 변경 사항을 배포할 수 있는 능력임.
  • 도타 2의 라인전과 매직: 더 개더링·스타크래프트의 어그로 전략처럼, 기술 조직에서도 가장 직접적인 실행 방식이 다른 전략의 가능 범위를 제약함.
  • 프로젝트를 이끌면서 직접 배포할 수 없으면 부풀려진 작업 추정, 실행 불가능한 설계, 불필요하게 커지는 프로젝트와 팀의 불신이 발생함.
  • 시니어·스태프 엔지니어는 여러 요청을 빠르게 직접 처리해야 하며, 프로젝트 인력 배정 절차를 우회하려는 관리자의 요청도 지연 없이 해결해야 함.
  • 인공지능과 대형 언어 모델(LLM)은 배포 과정에 도움을 줄 수 있지만, 코드베이스·동료·관리자에 관한 맥락과 종단 간 실행 능력이 부족하므로 직접 검토와 조율을 대체하지 못함.

직접 배포가 엔지니어링의 토대임

  • 대형 기술 기업에서 성공적인 엔지니어가 되려면 효과적인 회의 운영, 좋은 설계 문서 작성, 티켓과 에픽 구체화, 팀 절차 개선, 소규모 엔지니어 그룹의 기술 리딩 등 다양한 역량이 필요함. 그러나 이 모든 역량의 토대는 변경 사항을 배포할 수 있는 능력임.

게임 전략이 보여주는 직접 실행의 우선성

  • 도타 2의 초반 라인전은 작은 공간에서 상대 플레이어와 자원을 두고 경쟁하는 단계이며, 고려할 전략이 많지만 가장 단순한 방식은 상대를 향해 달려가 공격해 도망치거나 죽게 만드는 것임.
  • 다른 라인전 전략도 우선 이 직접적인 공격에 대응해야 함. 플레이 공간에서 밀려나면 아무리 다른 플레이를 잘해도 의미가 없으며, 이 문제를 잘못 다루면 나머지를 아무리 잘해도 소용이 없음.
  • 매직: 더 개더링과 스타크래프트에서는 상대가 방어를 갖추기 전에 가능한 한 빨리 공격 전력을 만드는 ‘어그로’ 전략을 택하는 플레이어가 많음. 매번 어그로에 패배하는 계획은 아무리 영리해도 의미가 없으므로, 어그로는 게임의 전략 공간 전체를 제약함.
  • 게임에 어그로 플레이어가 없더라도 플레이어는 초반 공격에 대응할 가능성을 고려해 덱을 설계하고 플레이하므로, 어그로 전략은 게임의 전개 방식에 계속 영향을 줌.

기술 조직에서 배포가 갖는 의미

  • 기술 기업에서 배포는 게임의 공격적인 전략에 해당함. 티켓이나 설계 문서를 작성하거나 다른 엔지니어에게 업무를 맡기는 등 거의 모든 행동은 직접 앉아 변경 사항을 만드는 기본 전략과 비교해야 함.
  • 사소한 일을 조율 비용 없이 직접 처리할 수 있도록 배포 능력을 갖추는 것이 중요함.
  • 프로젝트를 이끌면서 직접 배포할 수 없으면 다음과 같은 역기능을 겪게 됨.
  • 5분이면 끝낼 작업의 추정에 15분을 씀.
  • 배포할 수 없는 설계를 제안해 성공할 수 없는 작업에 몇 시간에서 며칠을 낭비함.¹
  • 작업 소요 시간을 현실적으로 점검하지 못해 모두가 조심하려는 과정에서 추정치가 지나치게 부풀려짐.
  • 실제로 배포할 수 있는 엔지니어를 크게 좌절시키며, 그 좌절 자체가 추가 역기능의 원인이 됨.²
  • 사소한 작업을 거대한 프로젝트로 키움.

시니어 엔지니어가 간단한 요청을 바로 처리해야 하는 이유

  • 시니어·스태프 엔지니어는 일상적으로 다양한 일을 요청받으며, 더 성공할수록 요청량도 늘어남. 간단한 요청을 즉시 처리하는 능력이 중요함.
  • 관리자가 엔지니어에게 맡기고 싶어 하는 요청량은 이상적으로 매우 많음. 모든 작업을 여러 엔지니어가 필요한 느린 프로젝트로 만들면 충분한 결과를 내지 못함.
  • 프로젝트에 인력을 배정하는 과정은 느리고 고통스러울 수 있음. 관리자가 요청하는 일의 상당 부분은 통상적인 절차를 우회하는 빠르고 비공식적인 대안이므로, 혼자 빠르게 해결하지 못하면 요청의 취지가 사라짐.

인공지능이 배포 능력을 대신하지 못함

  • 인공지능이 모든 사람에게 배포 능력을 제공하는 것은 아님. 배포는 코드 작성에만 국한되지 않으며, 결승선의 형태를 정하는 일부터 가장 짧고 실용적인 완주 경로를 찾고, 진행 중 나타나는 사소한 문제를 해결하며, 관련 관리자에게 만족과 정보를 제공하는 일까지 포함함.
  • 대형 언어 모델(LLM)은 이 과정에 도움을 줄 수 있지만 종단 간으로 수행할 수는 없음. 회사의 기술 시스템 세부 사항, 관련된 사람과 그들의 동기 등 너무 많은 맥락이 필요함.
  • 경험상 최첨단 인공지능 모델도 코드베이스에서 자유롭게 실행하기에는 충분히 뛰어나지 않으며, 코드를 직접 읽어야 함.³

연구와 소프트웨어 엔지니어링의 유사성

  • 이 글은 수학 연구를 다룬 Xiaoyu He의 「Aggro is the Foundation」에서 영감을 얻음.
  • 연구에 관한 좋은 글, 예를 들어 Richard Hamming의 고전 「You and Your Research」와 소프트웨어 엔지니어링 사이에는 많은 유사점이 있음. 소프트웨어 엔지니어링은 흔히 연구 과정이기 때문임.
  • 소프트웨어 엔지니어링 연구는 과학·수학의 더 넓은 질문 대신 특정 프로그램의 작동 방식이나 변경 가능성을 다루므로 목표가 더 사소하지만, 여전히 연구임. 배포할 수 없다면 이 분야에서도 좋은 성과를 내기 어려움.

각주

  • ¹ 대개 코드베이스에 익숙하면 알 수 있는 기술적 이유나, 설계와 충돌하는 까다로운 기능이 원인임.
  • ² 행복하고 생산적인 팀은 원활하게 움직임. 설계를 신뢰하지 못해 좌절한 팀은 각 엔지니어가 설계를 ‘고치려고’ 미묘한 변경을 몰래 적용하는 악몽 같은 업무 환경이 됨.