시니어가 되면 티켓이 사라진다
주니어 시절엔 할 일이 명확했어요. 스프린트 보드에 티켓이 있고, 누군가 우선순위를 정해주고, 나는 그걸 잘 끝내면 됐죠. 그런데 연차가 쌓여서 스태프(Staff) 엔지니어쯤 되면 이상한 일이 생겨요. 아무도 나한테 뭘 하라고 말해주지 않는 거예요.
스태프 엔지니어가 뭐냐면, 시니어 다음 단계인 IC(Individual Contributor, 개인 기여자) 트랙 직급이에요. 관리자가 되지 않고 기술자로 계속 성장하는 길인데, 기대치가 '주어진 문제를 잘 푼다'에서 '풀어야 할 문제를 찾아낸다'로 바뀌어요. Sujith Jay의 글 'A Staff Engineer's Guide to Inventing Work'가 다루는 게 바로 이 전환이에요. 일을 '받는' 사람에서 일을 '발명하는' 사람으로 바뀌는 거죠.
'일을 발명한다'는 게 무슨 뜻일까
'일을 만든다'고 하면 괜히 바쁜 척하거나 필요 없는 프로젝트를 벌인다는 느낌이 들 수도 있는데요, 여기서 말하는 건 정반대예요. 조직 안에 이미 있지만 아무도 이름을 붙이지 않은 문제를 발견하고, 그걸 해결할 가치가 있는 '프로젝트' 형태로 바꾸는 일이에요.
비유하자면 이래요. 한 집에 사는 사람들이 매일 문턱에 발가락을 찧는데 다들 '원래 그런 집이지' 하고 넘어가요. 그런데 누군가 '이 문턱만 없애면 모두 하루에 몇 번씩 덜 아프겠네'라고 말하고 공사 계획까지 세우죠. 스태프 엔지니어의 일이 딱 그거예요.
그러면 이런 문제는 어디서 찾을까요? 흔히 보이는 신호가 몇 가지 있어요.
- 반복되는 장애와 온콜 고통: 같은 종류의 장애가 여러 팀에서 되풀이된다면 개별 버그가 아니라 구조적인 문제일 가능성이 커요.
- 팀과 팀 사이의 빈틈: 각 팀은 자기 서비스만 책임지는데, 그 사이를 잇는 부분은 누구의 것도 아니에요. 배포 파이프라인, 공통 라이브러리, 서비스 간 데이터 계약 같은 곳이죠.
- 모두가 투덜대지만 아무도 안 고치는 것: 느린 CI나 로컬 개발 환경 세팅에 하루가 걸리는 문제 같은 거요.
- 회사 전략과 현재 시스템의 간극: 경영진은 내년에 해외 진출을 한다는데 지금 시스템이 단일 리전, 단일 통화만 가정하고 있다면? 그 간극이 곧 미래의 프로젝트예요.
찾는 것보다 어려운 건 '파는' 것
문제를 찾는 것만으로는 부족해요. 진짜 어려운 건 그 일이 투자할 가치가 있다고 조직을 설득하는 거거든요. 이때 중요한 건 '기술적으로 멋진가'가 아니라 '비즈니스에 왜 중요한가'를 말하는 능력이에요. '이 레거시 모듈이 너무 지저분해요'보다 '이 모듈 때문에 지난 분기에 결제 장애가 세 번 났고, 신규 기능 출시가 평균 2주씩 밀렸어요'가 훨씬 힘이 세죠.
그래서 자주 쓰는 도구가 설계 문서(Design Doc, RFC)예요. 문제 정의, 왜 지금 해야 하는지, 선택지와 트레이드오프(하나를 얻으면 다른 하나를 잃는 관계), 성공 기준을 글로 정리하는 거죠. 글로 써두면 여러 사람이 각자 편한 시간에 검토할 수 있고, 내가 없는 회의에서도 문서가 대신 설득해줘요.
작게 시작하는 것도 중요해요. 처음부터 '전사 아키텍처 개편'을 들고 가면 거절당하기 쉬워요. 한 팀에서 파일럿으로 효과를 증명하고, 그 숫자를 들고 범위를 넓히는 게 현실적이에요.
업계 맥락: 스태프 엔지니어 담론의 흐름
이 주제에는 최근 몇 년 사이 꽤 두꺼운 논의가 쌓였어요. 윌 라슨(Will Larson)의 『Staff Engineer』는 스태프 역할을 테크 리드, 아키텍트, 솔버(Solver), 라이트 핸드(Right Hand) 같은 원형으로 나눠 설명했고, 타냐 라일리(Tanya Reilly)는 『The Staff Engineer's Path』와 'Being Glue'라는 발표로 잘 드러나지 않는 '접착제 역할'의 가치를 조명했죠.
'일을 발명한다'는 관점도 이 흐름의 연장선에 있지만 좀 더 실무적인 질문에 초점을 맞춰요. 역할을 분류하는 이야기라기보다 '월요일 아침에 뭘 할지 어떻게 정하지?'에 가깝거든요. 특히 요즘처럼 AI 코딩 도구 덕분에 구현 속도가 크게 빨라진 시대에는, 무엇을 만들지 고르는 능력의 상대적 가치가 오히려 커지고 있어요. 코드를 짜는 비용이 내려갈수록 올바른 문제를 고르는 판단이 병목이 되니까요.
한국 개발자에게 주는 시사점
한국 IT 회사들도 IC 트랙을 따로 두는 곳이 늘고 있지만, 아직은 '연차가 차면 팀장'이 기본 경로인 곳이 많아요. 그러다 보니 시니어 이후 IC로 남은 분들은 '나는 뭘로 평가받지?' 하는 막막함을 느끼기 쉬워요.
그런데 이 글의 메시지는 직급과 상관없이 써먹을 수 있어요. 주니어라도 '우리 팀에서 모두가 불편해하는 것 한 가지'를 찾아서 문제를 정의하고, 해결책을 한두 페이지짜리 문서로 제안해보는 연습은 당장 할 수 있거든요. 이런 경험이 쌓이면 평가 시즌에 '티켓 몇 개를 처리했다'가 아니라 '이런 문제를 발견해서 이런 결과를 냈다'고 말할 수 있게 돼요. 이직 면접에서도 훨씬 강력한 이야기가 되고요.
다만 주의할 점도 있어요. 조직의 우선순위와 동떨어진 '내가 하고 싶은 일'을 발명하면 그건 그냥 딴짓이 돼요. 매니저나 다른 팀 리더들과 꾸준히 대화하면서 방향을 맞추는 게 이 일의 절반이에요.
마무리
한 줄 정리: 스태프 엔지니어의 일은 문제를 직접 푸는 것보다, 풀 가치가 있는 문제를 찾아내고 조직이 그걸 풀도록 만드는 데 있어요.
여러분 팀에도 '원래 그런 거지' 하고 모두가 참고 넘어가는 문턱이 있지 않나요? 그걸 없애자고 제안해본 적이 있다면 어떤 반응이 돌아왔는지 경험을 나눠주세요.
🔗 출처: Hacker News