[특집] 아무도 일을 주지 않는 팀에서 일을 발명하는 법 — 스태프 엔지니어의 11가지 신호 완전 해부

크게 보기

들어가며: "다음엔 뭘 만들죠?"라고 아무도 말해 주지 않을 때

회사에서 일하는 엔지니어 대부분은 이런 장면에 익숙합니다. 분기가 시작되면 제품 관리자(PM)가 로드맵을 들고 옵니다. 고객이 무엇을 원하는지, 경쟁사가 무엇을 냈는지, 매출 목표가 얼마인지. 엔지니어는 그걸 받아 어떻게 만들지 고민합니다. 무엇을 만들지는 대개 다른 사람의 몫입니다.

그런데 회사 안에는 이 장면이 통째로 빠진 팀이 있습니다. 사내 개발자들이 쓰는 배포 시스템, 데이터 파이프라인, 쿠버네티스 클러스터, 관측 도구를 만드는 사내 플랫폼 팀입니다. 이 팀의 고객은 같은 회사 동료입니다. 매출이 없습니다. 경쟁사도 없습니다. 고객은 다른 선택지가 없으니 떠나지도 않습니다. 그리고 많은 경우, PM이 없습니다.

2026년 9월 22일, 데이터 인프라를 오래 만들어 온 엔지니어 수짓 제이 나이르(Sujith Jay Nair) 가 자기 블로그에 짧은 글을 올렸습니다. 제목은 「A Staff Engineer's Guide to Inventing Work」, 우리말로 '스태프 엔지니어를 위한 일 발명 안내서'. 첫 문단이 이 팀의 처지를 정확히 요약합니다.

플랫폼 팀은 제품이 아니라 엔지니어링이 이끈다. 로드맵을 건네주는 PM은 거의 없고, 따라갈 매출선도, 잃을 시장도 없다. 이는 곧, 엔지니어가 발명하지 않으면 일이 존재하지 않는다는 뜻이다. (…) 플랫폼 팀에서 스태프 엔지니어가 하는 일의 큰 부분은 팀이 다음에 무엇을 만들어야 할지 알아내는 것이다. 나는 이것을 '일을 발명한다'고 부른다.

글은 해커뉴스에 올라 277점, 댓글 57개를 받았습니다. 박수만 있지는 않았습니다. "플랫폼 팀이야말로 일을 발명하는 상아탑"이라는 냉소도, "그건 발명이 아니라 그냥 요구사항 공학"이라는 지적도 있었습니다. 이 반론들은 뒤에서 제대로 다루겠습니다.

필자의 핵심 주장은 간단합니다. 일을 발명할 신호는 이미 사방에 있다. 그 신호는 네 방향에서 온다. 시스템에서, 사용자에서, 조직에서, 그리고 업계에서. 글은 이 네 방향에서 오는 신호 11가지를 하나씩 읽는 법을 알려 주고, 마지막에 가장 중요한 질문을 던집니다. 이 많은 신호 중 무엇을, 언제 믿을 것인가.

이 글은 원문을 따라가되, 원문이 한두 줄로 지나간 개념마다 그 개념이 어디서 왔는지(구글 SRE의 토일, 로저스의 확산 곡선, 하이럼의 법칙, 베이조스의 6쪽 메모…)와 실제로 벌어진 사례(트위터 해시태그, 드롭박스의 AWS 탈출, 세그먼트의 모놀리스 귀환…)를 붙여 넣었습니다. 원문에는 사람 이름이나 회사 사례가 거의 나오지 않습니다. 인용하는 책은 『캐즘 마케팅』 하나이고, 나머지는 필자 자신의 옛 글입니다. 그러니 이 글에 나오는 역사와 사례는 원문을 이해하기 위해 이 글이 보탠 맥락이라는 점을 미리 밝혀 둡니다.

1부. 왜 '일을 발명한다'는 말까지 나왔을까

사내 플랫폼 팀은 어떻게 생겨났나

한 회사의 개발자가 열 명일 때는 누구나 서버에 직접 들어가 배포합니다. 백 명이 되면 배포 스크립트가 열 개쯤 생기고, 천 명이 되면 같은 일을 하는 도구가 팀마다 따로 생깁니다. 그 중복을 한곳에 모아 '회사 공용 기반'으로 만들어 주는 팀이 플랫폼 팀입니다.

말이 굳어진 건 2010년대 후반입니다. 소트웍스의 에번 보처(Evan Bottcher)는 2018년 3월 마틴 파울러의 사이트에 쓴 글에서 플랫폼을 이렇게 정의했습니다. "디지털 플랫폼이란 셀프서비스 API, 도구, 서비스, 지식, 지원의 기반으로, 매력적인 사내 제품으로 배치된 것이다." 2019년 매슈 스켈턴과 마누엘 파이스의 『팀 토폴로지』는 '플랫폼 팀'을 조직 설계의 기본 단위 넷 중 하나로 올리고, 필요한 만큼만 만드는 '가장 얇은 실행 가능 플랫폼(Thinnest Viable Platform)'이라는 말을 퍼뜨렸습니다. 가장 얇은 플랫폼은 추천 클라우드 서비스를 나열한 위키 페이지 한 장일 수도 있다고 했지요.

그리고 가트너가 못을 박았습니다. 2022년 10월 발표한 2023년 전략 기술 트렌드에서 "2026년까지 대형 소프트웨어 엔지니어링 조직의 80%가 플랫폼 엔지니어링 팀을 둘 것(2022년 45%에서)"이라고 예측했습니다. 바로 올해가 그 2026년입니다. 플랫폼 팀은 이제 대기업에서 흔한 존재가 됐습니다. 이 블로그의 「플랫폼 엔지니어링 완전 가이드」가 그 흐름을 자세히 다룹니다.

문제: 플랫폼은 '명령 경제'다

팀은 늘었는데, 이 팀들이 공통으로 앓는 병이 있습니다. 무엇을 만들어야 할지 모른다는 것입니다.

수짓은 6년 전인 2020년 10월에 이미 이 병을 진단한 글을 썼습니다. 제목은 「AWS Is NOT Your Ideal(AWS는 여러분의 이상형이 아니다)」. 그의 관찰은 이렇습니다. 모든 플랫폼 팀은 AWS가 되고 싶어 한다. 인프라를 추상화해 셀프서비스로 파는 모습이 닮았으니까. 그런데 결정적인 차이가 있다.

그는 이것을 명령 경제(command economy) 에 비유했습니다. 포획된 사용자에게는 선택지가 없으니, 더 나은 해법이 경쟁으로 이길 수 없다. 플랫폼 기능은 진화하는 게 아니라 '설계'된다. 그런데 설계에는 목표 함수가 필요하고, 그 목표 함수가 명세다. 믿을 만한 지표가 없으니 명세도 흐릿하고, 명세가 흐릿하니 만든 기능이 가치 있는 문제를 푼다는 보장이 없다.

같은 해 5월, 카미유 푸르니에(Camille Fournier)는 「Product for Internal Platforms」라는 글에서 같은 문제를 다른 각도로 짚었습니다. 사내 플랫폼의 제품 관리는 별개의 기술이고, 사용자 수가 적어 지표 중심 전략이 잘 통하지 않으며, 그래서 엔지니어가 아이디어 단계부터 함께해야 한다는 것. 수짓 스스로 2020년 글의 추신에 푸르니에의 영향이 크다고 밝혔습니다.

크게 보기

그 빈자리를 누가 채우나: 스태프 엔지니어

그러면 누가 '다음에 무엇을'을 정할까요. 수짓의 답은 스태프 엔지니어입니다.

스태프 엔지니어는 관리자가 되지 않고 기술 트랙으로 계속 올라간 시니어 엔지니어를 부르는 직함입니다. 2021년 윌 라슨(Will Larson)의 『스태프 엔지니어』가 이 역할을 네 가지 원형으로 정리했습니다. 기술 리드(Tech Lead), 아키텍트(Architect), 해결사(Solver), 오른팔(Right Hand). 2022년 타냐 라일리(Tanya Reilly)의 『The Staff Engineer's Path』가 뒤를 이었습니다.

라슨의 사이트(staffeng.com)에는 「중요한 일을 하라(Work on what matters)」라는 글이 있습니다. 거기서 그는 스태프 엔지니어가 빠지기 쉬운 두 가지 함정을 경고합니다. 쉽고 기분 좋은 작은 일만 골라 먹는 스낵킹(snacking), 그리고 영향은 작은데 눈에 잘 띄는 일을 하는 프리닝(preening, 깃털 다듬기). 수짓의 글은 이 경고의 플랫폼 팀판 해법이라고 읽어도 됩니다. 무엇이 중요한 일인지 아무도 알려 주지 않을 때, 그걸 어디서 찾는가.

2부. 신호는 네 방향에서 온다

수짓은 11가지 신호를 네 방향으로 묶었습니다. 원문의 소제목 그대로 옮기면 이렇습니다.

크게 보기

아래 탐색기에서 방향과 신호를 눌러 보세요. 각 신호의 요지, 읽는 법, 함정을 원문에서 옮겼고, 감을 잡기 쉽도록 가상의 장면을 하나씩 붙였습니다. 본문에서 하나씩 자세히 다루기 전에 먼저 지도를 훑어 두면 좋습니다.

3부. 시스템이 보내는 신호

① 장애 주도 발견 — 가장 분명하지만 가장 늦은 신호

시스템이 멈추면 포스트모템(사후 검토)을 씁니다. 수짓은 말합니다. 제대로 쓴 포스트모템은 무엇을 고치고 무엇을 갈아엎을지 분명히 알려 준다. 새로 만들 것을 가리키는 경우는 드물지만, 가끔은 있다. 어디를 보면 될까요? 장애가 길어지는 동안 사용자가 어떻게 버텼는지입니다. 사용자가 급하게 만든 우회로가 곧 다음에 만들 기능의 초안일 수 있습니다.

포스트모템 문화 자체도 역사가 있습니다. 2012년 5월, 엣시(Etsy)의 존 올스포(John Allspaw)는 「Blameless PostMortems and a Just Culture」에서 '누구 탓인가'를 묻지 않는 포스트모템을 주장했습니다. 사람을 벌하면 사람들이 사실을 숨기고, 사실이 숨겨지면 시스템은 배우지 못한다는 논리였습니다. 구글의 『사이트 신뢰성 엔지니어링』(SRE 책) 15장 「포스트모템 문화」도 같은 원칙을 명문화했습니다. 포스트모템이 진정 비난 없는 것이 되려면 어떤 개인이나 팀을 탓하지 않고 기여 요인을 찾는 데 집중해야 한다는 것. 이 블로그의 「SRE 입문」에서 그 배경을 볼 수 있습니다.

수짓이 덧붙이는 조언은 포스트모템 사이의 패턴입니다. 장애 하나하나는 원인이 달라 보여도, 여섯 달치를 나란히 놓으면 같은 뿌리가 보일 때가 있습니다. 그런데 이걸 습관으로 하는 팀은 드뭅니다. 장애는 띄엄띄엄 오니까요.

그리고 이 신호에는 치명적인 약점이 있습니다.

장애 주도 발견은 팀을 가장 시끄럽고 가장 최근의 장애 쪽으로 치우치게 한다. 가장 큰 기회가 아니라. 게다가 이것은 최대로 늦은(maximally lagging) 지표다.

심리학에는 이 현상의 이름이 있습니다. 1973년 아모스 트버스키와 대니얼 카너먼이 보고한 가용성 휴리스틱. 사람은 머릿속에 쉽게 떠오르는 사례일수록 더 자주, 더 중요하게 일어난다고 판단합니다. 어젯밤 새벽 3시에 울린 알람은 가장 생생하게 떠오르고, 그래서 가장 중요해 보입니다. 하지만 백로그를 채워야 할 가장 큰 기회는 알람을 울리지 않는 곳에 있을 수 있습니다.

크게 보기

② 비용 — 매출 대신 청구서를 북극성으로

플랫폼 팀에는 매출이 없다고 했지요. 수짓은 클라우드 청구서가 그 빈자리를 채운다고 말합니다. 비용은 이미 돈으로 표시돼 있어서, 그 자체로 설득력이 있습니다.

다만 그는 여기서 멈추지 말라고 합니다. 쿼리 하나를 튜닝하고, VPC 사이 트래픽 비용을 깎는 데서 끝내지 말라. 사업부 손익계산서가 있다면 보고, 팀의 벤더 계약서와 청구서 항목을 한 줄씩 보라. 각 비용 항목마다 물어라. 이 기능을 밖에 '외주' 줘서 우리 팀이 얻는 게 뭔가? 이걸 우리 범위 안으로 끌어들이면 무엇이 달라지나? 그리고 반대 방향도 보라. 지금 우리가 하고 있지만 벤더나 클라우드, 다른 팀에 넘겨야 할 것은 무엇인가.

핵심 교훈: 만들 것인가 살 것인가(buy-versus-build)는 한 번 하고 끝나는 결정이 아니다. 범위, 팀 구성, 기술, 시장이 바뀌면 다시 따져도 된다.

이 문장이 얼마나 큰 돈이 걸린 이야기인지 보여 주는 사례가 둘 있습니다. 둘 다 회사 전체 규모의 결정이라 사내 플랫폼 팀의 일과는 크기가 다르지만, 논리는 같습니다.

재밌는 건 방향입니다. 드롭박스도, 37시그널즈도 처음엔 '사서 쓰기'(클라우드)가 옳았습니다. 작을 때는 서버를 직접 사서 운영할 사람도 돈도 없으니까요. 규모가 커지고, 사용 패턴이 안정되고, 인프라를 운영할 사람이 생기자 같은 계산이 반대 답을 냈습니다. 37시그널즈는 서버를 들여온 뒤에도 S3는 한동안 남겨 뒀다가, 2025년 6월 계약이 끝나면서 그마저 자체 스토리지로 옮겼습니다. 계산을 한 번 더, 또 한 번 더 한 셈입니다. 반대로 자체 운영하던 것을 관리형 서비스로 넘기는 결정도 똑같이 '다시 따지기'의 결과일 수 있습니다.

크게 보기

③ 우리 팀의 수고 — 보이지 않는 또 하나의 비용

수짓은 이것을 '또 다른 비용'이라 부릅니다. 많은 사람에게 보이지 않는 비용, 때로는 그 수고를 직접 하는 사람에게조차 보이지 않는 비용.

영어 원문의 단어는 토일(toil) 입니다. 이 단어를 엔지니어링 용어로 만든 건 구글 SRE 책 5장 「토일 없애기」입니다. 정의가 아주 구체적입니다.

토일이란 운영 중인 서비스를 돌리는 일 가운데 수작업이고, 반복적이고, 자동화할 수 있고, 전술적이며, 지속적인 가치가 없고, 서비스가 커지는 만큼 선형으로 늘어나는 종류의 일이다.

구글은 여기에 규칙 하나를 붙였습니다. SRE 한 사람의 시간 가운데 최소 50%는 미래의 토일을 줄이거나 서비스에 기능을 더하는 엔지니어링 프로젝트에 써야 한다. 그리고 분기마다 설문을 했더니, 구글 SRE가 토일에 쓰는 시간은 평균 약 33% 였습니다. 사람에 따라 0%에서 80%까지 갈렸고요. 구글처럼 규칙을 명문화한 조직에서도 3분의 1이 수고로 새어 나간다는 뜻입니다.

수짓은 토일이 일의 신호라는 건 모두가 이미 안다며 짧게 넘어갑니다. 대신 함정 하나를 꼭 짚습니다.

함정: 우리의 수고는 사용자의 수고가 아니다. 앞의 것을 없애면 단위 경제가 좋아지고, 뒤의 것을 없애면 사용자 경험이 좋아진다.

같은 '권한 승인' 문제라도 둘로 갈립니다. 온콜 엔지니어가 매주 승인 버튼을 40번 누르는 건 우리 팀의 수고입니다. 권한을 신청한 개발자가 사흘을 기다리는 건 사용자의 수고입니다. 앞의 것을 자동화하면 우리 팀이 같은 인원으로 더 많은 일을 받칠 수 있지만, 뒤의 사흘은 그대로일 수 있습니다. 둘 다 가치 있는 일입니다. 다만 무엇이 좋아지는지를 섞어 말하면 '우리 편하자고 만든 기능'이 '사용자를 위한 기능'으로 포장됩니다. 아래 여섯 장면을 직접 분류해 보세요.

크게 보기

4부. 사용자가 보내는 신호

④ 지속적 발견 — '더 빠른 말'을 넘어서

사용자에게 물어보면 되지 않을까요? 수짓은 여기서 스스로의 옛 주장을 인정하며 시작합니다. 그는 2020년 글에서 포획된 사용자는 "이상적인 도구의 모습을 가장 잘 보는 사람이 아니며", "사용자 인터뷰에 대한 과잉 의존은 플랫폼 제품 관리의 골칫거리"라고 썼습니다. 그리고 이번 글에서 그 말을 한 문장으로 요약합니다. "사람들에게 원하는 걸 물으면, 더 빠른 말을 달라고 할 것이다."

이 '더 빠른 말'은 흔히 헨리 포드의 명언으로 알려져 있습니다. "사람들에게 뭘 원하냐고 물었다면, 더 빠른 말이라고 했을 것이다." 그런데 포드가 이 말을 했다는 증거는 없습니다. 인용 추적 사이트 쿼트 인베스티게이터에 따르면 포드의 자서전에도, 헨리 포드 박물관이 검증한 약 200개의 인용 목록에도 이 말은 없습니다. 비슷한 표현이 처음 보이는 건 1999년 크루즈 업계지이고, 포드의 말이라고 명시된 가장 이른 기록은 2001년 한 마케팅 잡지의 독자 편지입니다. 2011년에는 『하버드 비즈니스 리뷰』에 「헨리 포드는 '더 빠른 말'이라고 말한 적이 없다」는 글까지 실렸습니다.

말의 출처는 가짜지만, 말이 가리키는 현상은 진짜입니다. 사용자는 지금 가진 것의 개선판밖에 떠올리기 어렵습니다. 그럼 사용자와 이야기하지 말아야 할까요? 수짓의 답은 아닙니다. "그렇다고 사용자와 대화하지 않을 핑계는 되지 않는다." 그가 제안하는 건 지속적 발견(Continuous Discovery) 입니다.

이 말은 제품 발견 코치 테리사 토레스(Teresa Torres)가 2021년 책 『Continuous Discovery Habits』에서 정의한 개념입니다. "제품을 만드는 팀이 원하는 성과를 좇으며 매주 고객과 접점을 갖고 작은 연구 활동을 하는 것." 한 번의 대규모 인터뷰가 아니라, 꾸준하고 작은 대화의 습관입니다. 수짓은 이것을 플랫폼 팀에 맞게 이렇게 정리했습니다.

이 체크리스트에서 가장 날카로운 문장은 "해킹이 없다면 충분히 아프지 않다"입니다. 사람은 정말 아프면 뭐라도 합니다. 스프레드시트를 만들고, 크론 스크립트를 걸고, 옆 팀에 부탁합니다. 인터뷰에서 "그거 정말 불편해요"라는 말은 많이 듣지만, "그래서 이렇게 버티고 있어요"라는 말이 따라 나오는 고통은 드뭅니다. 그 드문 것이 진짜입니다.

크게 보기

아래 시뮬레이터로 직접 인터뷰를 해 보세요. 상대는 ML팀 데이터 엔지니어 '지수'(가상 인물)입니다. 원문의 네 질문과 두 원칙(해킹 찾기, 해법에 반문하기)이 어떻게 작동하는지 느껴 볼 수 있습니다.

⑤ 용도 밖 사용 — 사용자가 대신 만들어 준 시제품

수짓이 가장 좋아한다고 밝힌 신호입니다. 2020년 글에서도, 이번 글에서도 되풀이합니다.

어떤 플랫폼에는 우연한 속성이 있다. 사용자가 그 플랫폼을 원래 설계되지 않은 용도에 억지로 끌어다 쓴다. (…) 용도 밖 사용을 사용자가 대신 만들어 준 시제품으로 대하라. 그리고 그중 무엇을 흡수할 가치가 있는지 가려내라. 흡수 여부를 가리는 리트머스 시험은 간단하다. 우리 사용자 중 또 누가 같은 문제를 갖고 있나?

원문의 영어 표현은 'overloaded use-cases'입니다. 하나의 도구에 원래 짐보다 많은 짐을 실었다는 뜻이라, 이 글에서는 '과적재 사용 사례' 또는 쉽게 '용도 밖 사용'이라고 옮겼습니다.

이 현상은 소프트웨어 역사에서 가장 흔하고, 가장 생산적인 패턴 중 하나입니다.

사내 플랫폼에서도 똑같은 일이 매일 일어납니다. 메시지 큐의 보관 기간을 30일로 늘려 이벤트 이력 DB처럼 쓰는 팀, CI 파이프라인을 야간 배치 스케줄러로 쓰는 팀, 설정 저장소를 기능 플래그 시스템으로 쓰는 팀. 플랫폼 팀 입장에서는 '잘못된 사용법'이라 막고 싶어집니다. 수짓의 관점에서는 정반대입니다. 돈 안 들이고 얻은 시제품이자, 이미 운영 환경에서 검증된 수요의 증거입니다.

구글 엔지니어 하이럼 라이트의 이름을 딴 하이럼의 법칙이 이 현상의 어두운 면을 정리합니다. "API 사용자가 충분히 많아지면, 계약서에 무엇을 약속했는지는 중요하지 않다. 시스템의 관찰 가능한 모든 동작에 누군가는 의존하게 된다." 하이럼의 법칙이 '그러니 함부로 바꾸지 마라'는 경고라면, 수짓의 휴리스틱은 같은 현상을 기회로 뒤집습니다. 사용자가 무엇에 의존하고 있는지 보면, 그들이 무엇을 필요로 하는지 보인다.

크게 보기

그리고 흡수 여부를 가르는 질문은 늘 같습니다. 또 누가? 한 팀만의 기발한 해킹이라면 그 팀이 알아서 유지하게 두는 게 맞습니다. 다섯 팀이 같은 해킹을 돌리고 있다면, 그건 플랫폼이 비워 둔 기능의 모양 그 자체입니다.

⑥ 함께 시제품 만들기 — 용도 밖 사용을 일부러 꾸미기

용도 밖 사용은 사후에 발견됩니다. 누가 억지로 쓰고 있어야 보이지요. 함께 시제품 만들기(Partner-to-Prototype) 는 같은 일을 일부러 꾸미는 것입니다. 우리 팀과 사용자 팀이 함께, 우리 플랫폼 위에서, 그 팀의 문제를 풀 시제품을 만듭니다.

수짓이 못 박는 조건이 하나 있습니다. 시제품은 약속이 아니다. 이 기능이 플랫폼에 들어간다는 보장이 아니라, 함께하는 탐색일 뿐이다. 흡수 여부의 기준은 여기서도 같습니다. 또 누가 같은 문제를 갖고 있나.

이 아이디어의 뿌리는 앞서 말한 푸르니에의 글에 있습니다. 그의 팀은 고객 팀과 짝을 이뤄 특정 문제의 시제품을 만들고, 그걸 다듬어 일반 해법으로 키웠습니다. 수짓은 2020년 글에서 한발 더 나갔습니다. 비슷한 문제를 가진 여러 팀과 동시에 시제품을 만들면, 그 시제품들이 하나의 일반 문제를 두고 경쟁하는 후보가 된다. 명령 경제였던 플랫폼 안에 작은 시장을 들이는 셈입니다. 충분히 다듬어진 뒤 가장 나은 것을 흡수하고, 나머지는 그쪽으로 옮긴다. 그래서 그는 마이그레이션 전략에 일찍 투자하라고 덧붙였습니다.

크게 보기

5부. 조직이 보내는 신호

⑦ OKR — 이미 발명된 일

원문에서 가장 짧은 항목입니다. 거의 농담처럼 쓰였습니다.

이것도 뻔한 신호라, 완결성을 위해 넣었다. 팀이 OKR을 세웠다면(또는 위에서 내려받았다면), 그 일은 이미 발명된 것이다. 축하한다! 다음 신호로 넘어가자!

목표와 핵심 결과(OKR)는 1970년대 인텔의 앤디 그로브가 다듬고, 1999년 존 도어가 창업 1년 차의 구글에 들여가면서 실리콘밸리의 표준이 된 목표 관리 방식입니다. 수짓의 농담에는 뼈가 있습니다. OKR은 이미 누군가 발명해 둔 일을 추적하는 도구입니다. 백로그가 OKR만으로 가득 차 있다면, 그 팀에서는 발명이 한 번도 일어나지 않은 것일 수 있습니다.

⑧ 관리자 반복 휴리스틱 — 가장 약한 신호

관리자가(또는 그 위의 관리자가) 한 주에 같은 이야기를 두 번 하면, 그 뒤에는 아직 다뤄지지 않은 걱정이 있을 가능성이 크다. 1:1에서 메모를 해야 하는 좋은 이유다. 또는 LLM이 만든 회의록을 읽거나.

2026년다운 한마디가 끼어 있지요. 회의록 요약 도구가 1:1 대화를 받아 적는 시대라, 반복되는 단어를 세는 일은 그 어느 때보다 쉬워졌습니다.

그런데 수짓은 이 휴리스틱을 자신이 아는 방법 중 가장 약한 것으로 꼽습니다. 이유는 이렇습니다. 위계를 따라 올라갈수록 사용자에게서 멀어지고, 그만큼 HiPPO 위에 짓게 될 가능성이 커진다.

HiPPO는 '가장 연봉 높은 사람의 의견(Highest Paid Person's Opinion)'의 약자입니다. 데이터가 없을 때 회의실에서 가장 직급 높은 사람의 감이 결정을 좌우하는 현상을 비꼬는 말이지요. 출처에 대해서는 오해가 많은데, 이 말의 원형은 2006년 인튜이트의 딜런 루이스가 만든 'HiPO(Highest Paid Opinion)'였습니다. 웹 분석가 애비너시 카우식이 이를 마이크로소프트의 실험 플랫폼 책임자 로니 코하비에게 전했고, 코하비 팀이 'HiPPO'로 바꾸고 하마 마스코트까지 만들었습니다. 2007년 코하비 등의 논문 제목이 「…HiPPO가 아니라 고객의 말을 들어라」였고, 같은 해 카우식의 책이 이 말을 널리 퍼뜨렸습니다.

크게 보기

그런데도 이 신호가 목록에 있는 이유가 있습니다. 뒤의 7부에서 볼 텐데, 이 신호는 증거는 0이지만 약간의 발언권(standing) 을 줍니다. 윗선이 이미 걱정하는 주제라면, 그 일을 하자고 설득하기가 조금 쉬워집니다. 다만 그 걱정이 사용자의 실제 고통과 이어지는지는 다른 신호로 확인해야 합니다.

⑨ 마이그레이션 잔해 — 끝까지 안 온 팀이 알려 주는 것

플랫폼의 큰 변화에는 반드시 마이그레이션이 따릅니다. 새 배포 시스템, 새 데이터 저장소, 새 쿠버네티스 클러스터로 옮기는 일. 이 일을 이끌어 본 사람은 압니다. 채택에는 두꺼운 꼬리가 있다. 수짓은 이 곡선이 『캐즘 마케팅』의 그 유명한 곡선처럼 생겼다고 말합니다. 혁신가, 얼리어답터, 초기·후기 다수, 그리고 마지막으로 지각생.

이 곡선의 원조는 1962년 사회학자 에버렛 로저스(Everett Rogers)의 『혁신의 확산(Diffusion of Innovations)』입니다. 로저스는 새로운 농법, 의료 기술, 가전제품이 사회에 퍼지는 과정을 연구해 사람들을 채택 시점에 따라 다섯 범주로 나눴습니다.

1991년 경영 컨설턴트 제프리 무어(Geoffrey Moore)는 『캐즘 마케팅(Crossing the Chasm)』에서 이 곡선에 금을 하나 그었습니다. 새 것을 좋아하는 얼리어답터와, 검증된 것만 사는 실용주의자인 초기 다수 사이에는 깊은 틈(캐즘) 이 있어서, 많은 기술 제품이 거기서 떨어져 죽는다는 것입니다.

수짓이 주목하는 건 곡선의 반대쪽 끝, 지각생입니다. 끝까지 발을 끄는 팀, 새 플랫폼에 끝내 올라타지 않는 팀. 이들은 게으른 게 아닙니다. 그들은 우리의 제안이 왜 아직 불완전한지, 왜 해야 할 일이 더 남았는지 알려 주는 신호입니다.

그는 2020년 글에서 이미 이렇게 썼습니다. AWS는 규모의 경제 덕에 중앙값 사용자만 챙겨도 되지만, 사내 플랫폼은 중앙값보다 넓은 사용자를 챙겨야 한다. 그게 사내 플랫폼이 존재하는 이유니까. 그 글에는 종 모양 곡선 그림에 "AWS는 표준편차 하나 안에 머물 수 있다. 여러분은 그럴 수 없다"는 설명이 붙어 있었습니다. 마이그레이션 잔해는 바로 그 '중앙값 해법'이 놓친 사용자들을 가리킵니다.

크게 보기

아래 곡선에서 전환율을 올려 보세요. 대시보드의 숫자가 84%를 넘기면, 그때부터가 이 신호의 시작입니다.

원문은 이 신호의 성격을 절묘하게 요약합니다. 지각생은 방금 끝낸 마이그레이션에 대해서는 후행 신호, 다음 마이그레이션에 대해서는 선행 신호다. 이번 전환에서 GPU 팀이 안 왔다는 사실은 이미 늦은 정보지만, 다음 버전에 GPU 지원을 넣어야 한다는 사실은 가장 이른 정보입니다.

6부. 업계가 보내는 신호

⑩ 서술이 처방을 낳는다 — 이미 있는 시스템의 설계 문서를 써라

아이디어를 떠올리는 건 어렵습니다. 그런데 기존 시스템을 개선할 새 아이디어를 내고, 그걸 처방의 형태(예를 들면 RFC, 즉 변경 제안서)로 내미는 건 스태프 엔지니어의 일입니다. 수짓이 가장 좋아하는 아이디어 발굴법은 뜻밖에도 이미 있는 시스템을 설명하는 것입니다.

이미 존재하는 시스템의 설계 문서를 써라. 그리고 비슷하거나 인접한 일을 하는 최신 시스템과 비교하라. 서술하는 행위가 더는 말이 되지 않는 결정들을 드러낸다. 생각하기로서의 글쓰기가 가장 빛나는 순간이다.

독자는 고르면 됩니다. 동료, 사용자, 신규 입사자. 누군가에게 "이 시스템은 이렇게 생겼고, 이래서 이렇게 만들었다"를 설명하다 보면, "이래서"가 막히는 대목이 나옵니다. 2017년에 디스크가 비싸서 고른 압축 방식, 당시 팀에 자바 개발자만 있어서 고른 프레임워크, 트래픽이 지금의 100분의 1일 때 정한 파티션 수. 결정의 이유는 사라졌는데 결정은 남아 있습니다.

글쓰기가 생각을 드러낸다는 믿음에는 계보가 있습니다.

• "생각만 하고 쓰지 않는다면, 생각한다고 생각할 뿐이다." 분산 시스템의 대가 레슬리 램포트가 강연에서 즐겨 하는 말입니다. 만화가 딕 기넌의 "글쓰기는 당신의 생각이 얼마나 엉성한지 알려 주는 자연의 방식"이라는 농담을 이어받은 표현이기도 합니다.
• 아마존의 6쪽 메모. 2004년 6월 9일, 제프 베이조스는 임원진에게 "지금부터 파워포인트 발표 금지"라는 메일을 보냈습니다. 대신 서술형 6쪽 메모를 쓰라고 했지요. 이유는 이랬습니다. "좋은 메모의 서술 구조는 더 나은 생각을 강제한다."
• 아키텍처 결정 기록(ADR). 2011년 11월 마이클 나이가드는 「Documenting Architecture Decisions」에서 결정을 제목·맥락·결정·상태·결과의 짧은 기록으로 남기자고 제안했습니다. 그가 든 이유가 바로 이 신호의 핵심입니다. "프로젝트가 사는 동안 추적하기 가장 어려운 것 가운데 하나가 특정 결정의 동기다."

여기에 체스터턴의 울타리를 겹쳐 보면 재밌습니다. G. K. 체스터턴은 1929년 책 『The Thing』에서, 길 한가운데 세워진 울타리를 보고 "쓸모없으니 치우자"고 하는 개혁가에게 이렇게 답하라고 썼습니다. "왜 세웠는지 알아 오기 전에는 못 치운다." 서술 글쓰기는 바로 그 '알아 오기'입니다. 울타리마다 세운 이유를 적다 보면, 이유가 아직 유효한 울타리와 조용히 유효기간이 끝난 울타리가 갈립니다. 앞의 것은 지키고, 뒤의 것은 RFC가 됩니다.

크게 보기

원문은 이 신호가 "논증도 긴급성도 주지 않지만, 조용히 만료된 결정을 알아챌 확률은 가장 높다"고 평가합니다. 설계 문서가 2026년에 왜 다시 중요해졌는지는 이 블로그의 「설계 문서는 왜 2026년에 다시 화제가 되었나」에서 더 자세히 다뤘습니다.

⑪ 지연이 곧 차익 — 진자는 돌아온다, 조금 늦게 따라가라

마지막 신호는 원문에서 가장 야심 찬 주장입니다.

업계 동향을 꾸준히 공부하는 건 당연히 가치가 있습니다. 오픈소스 릴리스, 다른 회사의 기술 블로그, 논문, 컨퍼런스 발표. 수짓은 이걸 더 날카롭게 읽는 법이 있다고 말합니다. 그의 믿음은 이렇습니다.

컴퓨팅의 어떤 분야든 묶기(bundling)와 풀기(unbundling) 의 긴 국면 사이를 오간다. 우리는 데이터 웨어하우스에서 계산과 저장을 묶었다가, 데이터 레이크에서 풀었고, 지금은 레이크하우스 엔진에서 다시 묶고 있다. 모놀리스에서 마이크로서비스로의 이동은 이제 모듈러 모놀리스에 자리를 내주고 있다.

'묶기와 풀기'라는 말에는 유명한 일화가 있습니다. 1995년 8월, 넷스케이프 상장 직전의 마지막 투자 설명회. 한 은행가가 "마이크로소프트가 브라우저를 윈도에 끼워 팔면 어쩔 거냐"고 묻자, 넷스케이프 CEO 짐 박스데일이 답했습니다. "제가 아는 돈 버는 방법은 두 가지뿐입니다. 묶기, 그리고 풀기." 이 말은 훗날 마크 앤드리슨이 여러 인터뷰에서 되풀이하며 실리콘밸리의 격언이 됐습니다.

수짓의 두 예를 실제 연표로 옮기면 이렇습니다.

애플리케이션 구조도 같은 춤을 췄습니다. 2014년 3월 제임스 루이스와 마틴 파울러의 글이 '마이크로서비스'라는 이름을 굳혔고, 수많은 회사가 모놀리스를 잘게 쪼갰습니다. 그리고 진자가 돌아왔습니다. 2018년 7월 세그먼트는 「Goodbye Microservices」에서 140개 넘는 마이크로서비스를 모놀리스 하나로 되돌린 이야기를 공개했습니다. 2019년 2월 쇼피파이는 「Deconstructing the Monolith」에서 쪼개지 않고 한 덩어리 안에 경계를 세우는 모듈러 모놀리스를 택했다고 밝혔습니다. 2023년 3월 아마존 프라임 비디오 팀은 영상 품질 모니터링 서비스 하나를 서버리스 분산 구조에서 단일 프로세스로 합쳐 인프라 비용을 90% 줄였다고 썼습니다. 이 90%는 프라임 비디오 전체가 아니라 그 서비스 하나의 이야기라는 점은 짚어 둡니다.

크게 보기

여기서부터가 수짓의 진짜 주장입니다.

사내 플랫폼도 같은 방향으로 흔들린다. 다만 지연을 두고. 아이디어가 스며드는 데는 시간이 걸리니까. 그 지연은 버그가 아니다. 그 덕분에 업계가 수렴한 논리와 증거를 함께 수입할 수 있다. 공개 포스트모템, 마이그레이션 성공담, 비교 벤치마크, 다른 회사가 버린 입장들. 증거를 만드는 비용을 치르지 않고 증거를 얻는다. 그리고 업계가 이미 버린 입장은 건너뛸 수 있다.

금융의 '차익 거래(arbitrage)'는 같은 물건이 두 시장에서 다른 값에 거래될 때 그 가격 차를 먹는 것입니다. 여기서 두 시장은 '업계'와 '우리 회사'이고, 가격 차는 시간입니다. 업계가 비싼 수업료를 내고 배운 교훈이, 우리 회사에는 아직 공짜로 도착해 있지 않습니다. 그 사이의 몇 년이 기회입니다.

물론 함정도 있습니다. 수짓의 경고: 지연이 너무 길면 안 된다. 추세를 가장 늦게 따라가는 무리(straggler)에 끼면, 그건 차익이 아니라 낙오입니다. 아래 위젯의 슬라이더는 '우리 회사가 마이크로서비스로 가기로 결정한 해'입니다. 해마다 공개돼 있던 증거가 어떻게 달라지는지 보세요.

7부. 어떤 신호를, 언제 믿을까

신호 11개는 한 번에 돌리기엔 너무 많다

원문의 마지막 절 제목은 「Which Signal, When」입니다. 수짓은 솔직하게 시작합니다. "신호 11개를 한꺼번에 돌리기엔 너무 많다." 그래서 그는 신호를 두 축으로 줄 세웁니다.

• 첫째 축: 그 신호가 논증을 얼마나 공짜로 건네주나. "이 일을 해야 한다"를 설득하는 데 필요한 근거가 신호와 함께 도착하는가, 아니면 내가 쌓아야 하는가.
• 둘째 축: 선행 신호인가, 후행 신호인가. 문제가 터지기 전에 오는가, 터진 뒤에 오는가.

한쪽 끝에는 논증이 이미 끝난 채 도착하는 신호가 있습니다. 포스트모템에는 이미 청중과 결론이 있다. 비용 항목은 이미 달러로 표시돼 있다. OKR은 이미 발명된 일을 추적한다. 행동하기는 싸지만, 정도의 차이는 있어도 모두 늦게 옵니다.

다른 쪽 끝에는 논증을 직접 쌓아야 하는 신호가 있습니다. 지연 차익은 가장 강한 논리와 가장 약한 발언권을 줍니다. 증거가 회사 밖에서 오니까요. 관리자 반복은 증거가 0이지만 약간의 발언권이 딸려 옵니다. 지속적 발견은 사용자의 고통을 주지만, 그걸 명세로 바꾸는 건 내 몫입니다.

그리고 가운데에 용도 밖 사용이 있습니다. 필자가 가장 좋아하는 이유가 여기서 드러납니다. 선행 신호이면서, 논증이 이미 만들어져 운영 환경에서 돌아가고 있다. 함께 시제품 만들기는 같은 증거를 사되 그걸 직접 만드는 비용을 치릅니다. 마이그레이션 잔해는 같은 거래를 마이그레이션 하나만큼 늦게 합니다. 서술 글쓰기는 논증도 긴급성도 주지 않지만, 조용히 만료된 결정을 알아챌 확률은 가장 높습니다.

말로만 들으면 헷갈리니 지도로 그려 봤습니다. 상대적 위치는 원문을 따랐고, 원문이 직접 배치하지 않은 '우리 팀의 수고'는 이 글의 추정으로 점선 표시했습니다.

이 지도에서 한 가지 더 읽히는 게 있습니다. 오른쪽 아래(늦지만 논증이 다 된 신호)는 이미 누군가 설득을 끝낸 일이고, 왼쪽 위(일찍 오지만 설득은 내 몫인 신호)는 아직 아무도 설득하지 않은 일입니다. '발명'은 대부분 왼쪽 위에서 일어납니다. 그리고 스태프 엔지니어의 일이란, 왼쪽 위에서 주운 신호에 논증을 붙여 오른쪽으로 옮기는 일이라고 할 수 있습니다.

실패는 빈 백로그가 아니다

원문의 맺음말은 이 글 전체에서 가장 인용할 만한 대목입니다.

이건 부족의 문제가 아니다. 신호는 언제나 켜져 있고, 위의 목록도 전부가 아니다. 엔지니어가 이끄는 플랫폼 팀의 실패 양상은 빈 백로그가 아니라, 가장 시끄러운 신호로 조립된 백로그다. 대개는 장애, 가끔은 상사의 상사. 일을 발명한다는 건 신호를 찾는 일이라기보다, '왜 다른 열 개가 아니라 이것인가'를 말할 수 있는 것이다.

말로는 쉬운데, 실제로 해 보면 어렵습니다. 아래 게임에서 직접 해 보세요. 여러분은 가상의 데이터 플랫폼 팀 스태프 엔지니어이고, 다음 분기 백로그에 넣을 수 있는 칸은 네 개뿐입니다.

크게 보기

8부. 2026년, 이 글이 더 중요해진 이유

만드는 비용이 떨어지면, 고르는 능력이 병목이 된다

이 글이 2026년 가을에 유독 큰 반응을 얻은 데는 시대적 이유가 있다고 봅니다. AI 코딩 에이전트가 '만드는 일'의 비용을 극적으로 낮췄기 때문입니다.

앤드루 응(Andrew Ng)은 2025년 7월 16일 뉴스레터 「더 배치」에 이렇게 썼습니다. "무엇을 만들지 정하는 것이 새로운 병목이다. 특히 초기 프로젝트에서. 나는 이것을 제품 관리 병목(Product Management Bottleneck) 이라 부른다." 그보다 한 달 앞선 6월, 와이콤비네이터 AI 스타트업 스쿨 강연에서는 이런 일화도 전했습니다. 한 팀이 PM 대 엔지니어 비율을 흔히 쓰는 1:4가 아니라 1:0.5로, 즉 PM을 엔지니어의 두 배로 두자고 제안했다는 것. "내 평생 처음으로, 관리자들이 엔지니어보다 PM을 두 배 많이 두자고 제안하고 있다." (이 강연 인용은 2차 보도를 거친 것입니다.)

이 흐름을 수짓의 글에 겹치면 흥미로운 그림이 나옵니다. 제품 팀은 PM을 늘려 '무엇을 만들지'의 병목을 풀려 합니다. 그런데 플랫폼 팀에는 애초에 PM이 없습니다. 에이전트가 코드를 빨리 쓸수록, 플랫폼 팀에서 '다음엔 무엇을?'이라는 질문의 무게는 고스란히 스태프 엔지니어에게 쏠립니다. 일을 발명하는 능력은 이제 부가 기술이 아니라 팀의 처리량을 결정하는 병목이 됐습니다.

크게 보기

AI가 바꾸는 신호들

에이전트는 병목을 옮겨 놓았을 뿐 아니라, 11가지 신호 자체도 바꾸고 있습니다. 원문에는 없는, 이 글의 관찰입니다.

그리고 새로운 사용자가 생겼습니다. 바로 에이전트 자신입니다. 2026년의 사내 플랫폼은 사람 개발자만이 아니라 코딩 에이전트가 호출하는 API와 CLI이기도 합니다. 하이럼의 법칙은 에이전트에게 더 가혹하게 작동합니다. 에이전트는 문서가 약속한 것보다 관찰되는 동작에 기대어 일을 끝내는 데 능하니까요. 에이전트가 플랫폼을 어떻게 '용도 밖으로' 쓰는지 보는 것은, 2026년에 새로 열린 신호원입니다.

한 가지 주의할 점. 서술 글쓰기를 AI에게 통째로 맡기면 이 신호는 거의 사라집니다. 수짓이 말한 가치는 문서라는 결과물이 아니라 설명하려다 막히는 경험에서 나오기 때문입니다. 초안은 AI가 써도 좋지만, 그 초안을 붙잡고 "왜?"를 묻는 건 사람이 해야 합니다. 이 블로그의 「플랜 모드는 죽었다」가 AI 코딩 시대의 '이해'의 문제를 같은 각도에서 다룹니다.

9부. 반론과 한계

해커뉴스 토론은 박수만큼 날카로운 반론을 남겼습니다. 공정하게 옮겨 둡니다.

또 하나, 이름에 대한 반론이 있었습니다. "그건 발명이 아니라 발견, 또는 요구사항 공학"이라는 지적입니다. 1부에서 말했듯 필자가 '발명'을 고른 이유는 책임의 소재에 있다고 봅니다. 하지만 이 지적 덕분에 분명해지는 점도 있습니다. 11가지 신호 대부분은 제품 관리와 요구사항 공학이 오래전부터 써 온 도구입니다. 이 글의 새로움은 도구가 아니라, PM 없는 팀의 엔지니어에게 그 도구 상자를 통째로 건넨 것, 그리고 그 도구들을 '논증'과 '시점'이라는 두 축으로 비교할 수 있게 한 것입니다.

10부. 내일부터 해 볼 수 있는 것

원문은 실천 일정을 따로 주지 않습니다. 아래는 11가지 신호를 주기별로 나눠 본, 이 글의 제안입니다.

그리고 무엇보다, 백로그에 올리는 모든 항목 옆에 한 줄을 적어 보세요. "왜 다른 것이 아니라 이것인가." 그 한 줄이 '어느 신호에서 왔고, 그 신호가 논증을 얼마나 줬고, 일이 터지기 전인가 뒤인가'를 말하고 있다면, 여러분은 이미 일을 발명하고 있는 겁니다.

맺으며: 신호는 언제나 켜져 있다

로드맵을 건네주는 사람이 없다는 건 불안한 일입니다. 동시에 자유로운 일이기도 합니다. 수짓의 글이 주는 위안은, 그 자유가 막막함이 아니라는 데 있습니다. 시스템은 장애와 청구서와 수고로 말하고, 사용자는 고통과 해킹과 억지 사용법으로 말하고, 조직은 목표와 반복과 남겨진 팀으로 말하고, 업계는 흔들리는 진자로 말합니다. 신호가 없어서 실패하는 팀은 없습니다. 가장 큰 소리만 듣다가 실패합니다.

그러니 일을 발명한다는 건 결국 듣는 법과 고르는 이유를 말하는 법입니다. 새벽 3시 알람이 울릴 때도, 부사장이 같은 말을 두 번 할 때도, 조용히 한쪽 구석에서 메시지 큐를 데이터베이스처럼 쓰고 있는 다섯 팀을 잊지 않는 것. 그리고 그 다섯 팀을 백로그 맨 위에 올리며 "왜 이것인지 설명할게요"라고 말할 수 있는 것. 그게 PM 없는 팀에서 스태프 엔지니어가 하는 일입니다.

참고 자료

원문과 필자의 관련 글

• Sujith Jay Nair, 「A Staff Engineer's Guide to Inventing Work」 (2026-09-22) — sujithjay.com
• Sujith Jay Nair, 「AWS Is NOT Your Ideal」 (2020-10-01) — sujithjay.com
• 해커뉴스 토론 (277점, 댓글 57개) — news.ycombinator.com

플랫폼과 스태프 엔지니어

• Evan Bottcher, 「What I Talk About When I Talk About Platforms」 (2018) — martinfowler.com
• Camille Fournier, 「Product for Internal Platforms」 (2020) — medium.com
• Matthew Skelton & Manuel Pais, 『Team Topologies』 (2019)
• Will Larson, 『Staff Engineer』 (2021), 「Work on what matters」 — staffeng.com
• Tanya Reilly, 『The Staff Engineer's Path』 (O'Reilly, 2022)

시스템의 신호

• Google SRE Book 5장 「Eliminating Toil」 — sre.google
• Google SRE Book 15장 「Postmortem Culture」 — sre.google
• John Allspaw, 「Blameless PostMortems and a Just Culture」 (Etsy, 2012)
• Tversky & Kahneman, 「Availability: A heuristic for judging frequency and probability」, Cognitive Psychology 5(2), 1973
• 드롭박스 인프라 절감(2018 S-1) — geekwire.com
• 37signals, 「Our cloud spend in 2022」 — dev.37signals.com
• DHH, 「Our cloud-exit savings will now top ten million over five years」 (2024) — world.hey.com

사용자의 신호

• Quote Investigator, 「My Customers Would Have Asked For a Faster Horse」 — quoteinvestigator.com
• Patrick Vlaskovits, 「Henry Ford, Innovation, and That "Faster Horse" Quote」, HBR (2011) — hbr.org
• Teresa Torres, 『Continuous Discovery Habits』 (2021) — producttalk.org
• Hyrum's Law — hyrumslaw.com
• Boerge Svingen, 「Publishing with Apache Kafka at The New York Times」 (2017) — confluent.io

조직의 신호

• Everett Rogers, 『Diffusion of Innovations』 (1962)
• Geoffrey Moore, 『Crossing the Chasm』 (1991)
• HiPPO의 유래 (Ronny Kohavi) — exp-platform.com

업계의 신호

• Dageville et al., 「The Snowflake Elastic Data Warehouse」, SIGMOD 2016 — dl.acm.org
• Armbrust et al., 「Lakehouse」, CIDR 2021 — cidrdb.org
• Segment, 「Goodbye Microservices」 (2018) — twilio.com
• Shopify, 「Deconstructing the Monolith」 (2019) — shopify.engineering
• Marcin Kolny, 「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」 (2023)
• Jim Barksdale & Marc Andreessen, HBR IdeaCast (2014) — hbr.org
• Michael Nygard, 「Documenting Architecture Decisions」 (2011) — cognitect.com
• G. K. Chesterton, 『The Thing』 (1929) — chesterton.org

2026년의 맥락

• Andrew Ng, The Batch 310호 (2025-07-16) — deeplearning.ai