스태프 엔지니어를 위한 일감 발굴 안내서

AI 요약

플랫폼 팀은 제품 관리자(Product Manager)가 정한 로드맵이나 매출 지표를 따라가기 어려운 경우가 많습니다. 그래서 스태프 엔지니어(Staff Engineer)는 플랫폼 이용자의 가치를 높일 일을 찾아야 합니다. 저자는 이 과정을 ‘일 발명하기’라고 부르지만, 실제로는 이미 존재하는 신호를 읽고 어떤 문제를 풀지 정하는 일입니다. 신호는 시스템, 사용자, 조직, 업계 네 방향에서 옵니다.

시스템이 보내는 신호

장애와 사후 분석(Postmortem)은 고칠 부분이나 교체할 대상을 알려줍니다. 때로는 장애 중 사용자가 어떤 방식으로 일을 이어갔는지 살피면 새 기능의 실마리도 찾습니다. 다만 장애 신호는 최근에 크게 불거진 문제에 쏠리기 쉽고, 이미 문제가 발생한 뒤에야 나타나는 후행 지표입니다.

비용은 클라우드 청구서뿐 아니라 사업 부문의 손익, 공급업체 계약, 비용 항목별 지출까지 살펴야 합니다. 어떤 기능을 외부에 맡기는 편이 나은지, 다른 팀이나 클라우드 서비스에 넘길 일을 직접 운영하고 있지는 않은지 따져봅니다. 자체 개발과 구매 사이의 선택은 한 번으로 끝나지 않습니다. 팀과 기술, 사업 범위가 변하면 다시 검토해야 합니다. 팀 내부의 반복 작업(Toil)도 신호입니다. 다만 팀의 반복 작업을 줄이면 운영 효율이 높아지고, 사용자의 반복 작업을 줄이면 사용자 경험이 좋아집니다. 둘을 혼동하지 말아야 합니다.

사용자가 보내는 신호

사용자와 꾸준히 대화하되, 원하는 기능을 바로 묻기보다 최근 플랫폼을 사용한 일을 설명해 달라고 요청합니다. 겪은 불편과 그 불편을 해결했을 때의 효과, 같은 문제를 겪는 사람이 더 있는지도 확인합니다. 실제 문제에는 대개 임시방편이 생겨 있습니다. 그런 방법이 없다면 문제가 충분히 절실하지 않은 것일 수 있습니다. 사용자가 제안한 해결책은 그대로 받아들이지 말고, 왜 필요한지와 현재 설계에 갇힌 제안은 아닌지 살핍니다. 문제를 기록하고 얼마나 자주 언급되는지 정리합니다. 인터뷰의 목적은 해결책을 확정하는 일이 아니라 문제를 함께 이해하는 일입니다.

플랫폼이 처음 의도하지 않은 용도로 쓰이는 ‘과부하 사용 사례(Overloaded Use-cases)’도 유용합니다. 사용자가 대안을 두고도 플랫폼을 다른 문제에 활용한다면, 이를 사용자가 만든 프로토타입처럼 살펴봅니다. 같은 문제가 다른 사용자에게도 있는지 확인한 뒤 플랫폼에 포함할지 판단합니다. ‘파트너와 프로토타입 만들기(Partner-to-Prototype)’는 이 과정을 의도적으로 진행하는 방법입니다. 사용자와 함께 해결책을 시험하되, 프로토타입을 정식 기능으로 만들겠다고 약속하지는 않습니다.

조직이 보내는 신호

OKR(Objectives and Key Results)은 이미 정해진 일의 신호입니다. 관리자가 같은 주제를 일주일 안에 두 번 이상 언급하는지 살피는 방법도 있습니다. 해결되지 않은 우려가 숨어 있을 수 있지만, 조직의 높은 곳일수록 사용자와 멀어지므로 이 신호는 약한 근거에 머물 수 있습니다. 직급이 높은 사람의 의견만으로 우선순위를 정하는 HiPPO(Highest Paid Person’s Opinion)를 경계해야 합니다.

플랫폼을 크게 바꾸면 이전 버전에서 옮겨오는 과정이 필요합니다. 늦게 옮기거나 끝내 옮기지 않는 팀은 최신 플랫폼이 무엇을 충분히 지원하지 못하는지 드러냅니다. 이런 ‘마이그레이션의 잔여 신호(Migration Debris)’를 보면 평균적인 사용자를 위한 설계가 놓친 요구를 찾을 수 있습니다.

업계가 보내는 신호

현재 시스템을 설명하는 설계 문서를 쓰고, 비슷한 문제를 푸는 업계 시스템과 비교하면 이미 타당성을 잃은 설계 결정을 발견할 수 있습니다. 저자는 기존 시스템을 글로 설명하는 과정이 새 아이디어를 찾는 데 도움이 된다고 봅니다. 글쓰기가 사고를 정리하는 수단이 되는 셈입니다.

오픈소스 공개물, 다른 회사의 기술 블로그, 연구 논문과 발표도 살펴봅니다. 업계는 컴퓨팅 영역마다 기능을 묶었다가 나누고 다시 묶는 흐름을 반복합니다. 내부 플랫폼도 비슷한 변화를 겪지만, 업계보다 늦게 따라가는 경우가 많습니다. 이 시차를 이용하면 다른 회사의 장애 보고서, 마이그레이션 사례, 벤치마크와 포기한 선택을 참고해 근거를 얻을 수 있습니다. 다만 너무 늦게 움직이면 뒤처지는 팀이 됩니다.

신호를 고르는 기준

저자는 신호를 두 축으로 비교합니다. 첫째는 신호 자체가 얼마나 근거를 제공하는지, 둘째는 선행 신호인지 후행 신호인지입니다. 사후 분석과 비용 항목은 근거가 이미 드러나 있어 행동하기 쉽지만 대체로 후행합니다. 업계 흐름은 강한 근거를 주지만 사내에서 추진할 명분이 약할 수 있습니다. 사용자 인터뷰는 실제 불편을 보여주지만 요구사항으로 다듬는 과정이 필요합니다.

과부하 사용 사례는 사용자가 이미 실제 환경에서 문제를 해결하고 있어, 근거가 갖춰진 선행 신호에 가깝습니다. 사용자와 함께 만드는 프로토타입은 비슷한 근거를 얻되 팀이 직접 실험해야 합니다. 마이그레이션을 늦추는 팀은 직전 변화에 대한 후행 신호이면서 다음 변화의 선행 신호가 됩니다. 신호는 늘 존재합니다. 문제는 신호가 부족한 게 아니라, 가장 크고 최근에 들린 신호만 따라 백로그를 채우는 일입니다.

Hacker News 반응

• @nmehner — ‘일 발명하기’는 제게 이상한 표현입니다. 요구사항 공학이라고 부를 수 있겠습니다.
  • @mytydev — 저도 같은 생각을 했습니다. 글에서 여러 번 쓰인 ‘발견’이 더 적절한 표현 같습니다.
  • @qrush — ‘일 정의하기’가 더 나은 표현이라고 봅니다.
  • @theanonymousone — ‘선제적 엔지니어링’은 어떨까요?
  • @gloryjulio — 요구사항 공학만으로는 스태프 엔지니어의 일을 다 설명하기 어렵습니다. 스태프 엔지니어는 팀이 맡을 범위 자체를 찾아야 합니다.
• @dabedee — 플랫폼 팀이 실제로 사람들을 잘 돕지 못하고, 자기 일을 만들어내는 조직처럼 기능하는 이유가 바로 이런 관점이라고 봅니다. 시장이 없다는 문제의 해결책은 지원 대상 팀이 다른 선택지를 택할 수 있다고 여기고, 그들이 제품을 떠날 수 있다는 듯 행동하는 것입니다. 글에는 신호가 여럿 나오지만, 사용자를 돌보는 제품 중심 사고가 빠져 있습니다.
  • @zem — 여기서 ‘일 발명하기’는 조직의 상위자가 팀에 할 일을 지정하지 않으니, 직접 사용자를 조사하고 문제를 발견해 해결 기능을 정하라는 뜻입니다.
  • @flowerlad — 제품 담당자는 어디에서 새 기능 아이디어를 얻을까요? 고객의 불편을 살피는 일은 이 글에서 설명한 내용과 같습니다.
  • @Rapzid — 저는 10년 동안 여러 플랫폼 팀을 이끌었고, 늘 내부와 외부 고객을 둔 제품처럼 운영했습니다.
• @aaroninsf — 제 이야기를 하는 것 같습니다. 저는 ‘일을 찾아 우선순위를 정하기’라고 표현했겠지만, 실제로는 발명하는 듯한 느낌도 듭니다. 조직에서 아무도 시키지 않았지만 필요를 미리 찾아 대응하거나, 놓친 마찰과 문제를 해결하는 일이 많습니다.
• @fsloth — 회사가 엔지니어를 고용하는 목적은 사업을 지원하는 일이라고 봅니다. 스태프 엔지니어라면 사업 측면에서 흥미로운 일이 무엇인지 관리자에게 듣기 전에 판단해야 합니다. 사업 지표와 연결할 근거를 제시하지 못한다면 학술 활동에 그칠 수 있습니다.
  • @devmor — 서로 ‘일’의 뜻을 다르게 쓰는 것 같습니다. 글은 할 작업을 누가 정해주지 않으니 직접 찾아 공식화해야 한다는 뜻입니다. ‘일 발명하기’는 약간 농담 섞인 표현입니다.
• @dirtbag__dad — 스태프급 플랫폼 엔지니어로 일하며 사용자의 가치를 높일 일이 무엇인지는 명백하다고 느꼈습니다. 정말 어려운 일은 고객과 가장 멀리 있는 플랫폼 팀이 왜 그 일을 해야 하는지 설명하는 일이었습니다. 데이터 품질과 지연 시간 문제를 반복해서 설명했지만, 데이터베이스 과부하와 심각한 장애 위험을 보여주는 그래프를 제시하고 나서야 승인을 받았습니다. 기술을 잘 아는 사람도 다른 영역의 상황은 모를 수 있습니다. 지표와 그래프가 문제에 대한 공통 이해를 만드는 데 도움이 됩니다.
• @syngrog66 — 큰 틀에서 보면 단기 성과를 좇고 기술 부채를 쌓기보다, 장기적인 작업과 기술 부채 상환에 더 무게를 두자는 이야기입니다.

원문: Sujith Jay Nair / 번역·요약: Trawling