문제를 해결해야 승진할까, 만들어야 승진할까

핵심 요약

• 프로젝트 규모로 성과를 평가하면 불필요한 일을 만들 유인이 생깁니다.
• 과잉 설계에는 개발 시간뿐 아니라 운영하고 사용법을 배우는 데 드는 비용도 따릅니다.
• 큰 설계가 필요한지는 실제 문제와 더 단순한 대안을 함께 놓고 판단해야 합니다.
• 일을 없앤 성과도 얼마나 시간을 아끼고 유지보수 부담을 줄였는지로 평가할 수 있습니다.

불필요한 시스템을 없앤 사람과 새로운 플랫폼을 만든 사람 중 누가 승진하기 쉬울까요. 평가 기준이 프로젝트 크기에 치우쳐 있다면, 문제를 조용히 해결한 사람이 오히려 불리해질 수 있습니다. 무엇을 성과로 인정하느냐에 따라 엔지니어의 커리어도, 회사가 개발 시간을 쓰는 곳도 달라집니다.

스태프 엔지니어는 무엇으로 성과를 증명할까요

스태프 엔지니어는 보통 관리자가 되지 않고 기술 분야에서 큰 책임을 맡는 엔지니어를 말합니다. 회사마다 맡는 범위는 다르지만, 여러 팀에 걸친 기술적 판단을 내리기도 합니다. 그런데 좋은 판단을 내렸다는 것을 눈에 보이는 성과로 설명하기는 쉽지 않습니다.

여러 팀이 같은 데이터를 중복 처리하는 상황을 가정해보겠습니다. 한 엔지니어는 기존 기능을 찾아 설정을 바꾸고 중복 작업을 없앱니다. 다른 엔지니어는 같은 문제를 해결할 공통 플랫폼을 제안합니다.

설정 변경만으로 요구사항을 충족한다면 첫 번째 선택이 더 경제적일 수 있습니다. 하지만 발표 자료에 넣을 구조도나 프로젝트 일정은 두 번째 선택에 더 많습니다.

평가자가 이런 자료로 성과를 가늠하면, 해결한 문제의 가치보다 얼마나 큰 일을 했는지가 앞설 수 있습니다.

평가표가 ‘일 만들기’를 보상하는 순간

승진 기준에 여러 팀을 아우르는 영향력이 들어 있다고 가정해보겠습니다. 그 자체로 이상한 기준은 아닙니다. 다만 영향력을 참여한 팀 수나 새 시스템을 도입한 범위로만 판단하면 문제가 생깁니다.

작은 수정으로 끝낼 일을 공통 플랫폼으로 키우면 참여 팀은 늘어납니다. 설계를 검토하고 기존 시스템에서 이전하는 작업도 생깁니다. 이런 일을 조율한 경험은 승진 자료에 적기 좋습니다.

그러나 조율해야 할 일이 늘었다는 사실만으로 조직이 더 나아졌다고 볼 수는 없습니다. 애초에 필요 없던 의존성을 만들고 이를 관리했다면, 일을 많이 했다는 것과 조직에 기여했다는 것을 구분해야 합니다.

이런 상황을 개인의 야심 탓으로만 돌릴 수는 없습니다. 일을 줄인 사람은 성과를 증명하기 어렵고, 일을 키운 사람은 쉽게 인정받는다면 평가 방식부터 살펴봐야 합니다.

과잉 설계의 청구서는 출시 뒤에도 옵니다

코드가 길다고 해서 과잉 설계는 아닙니다. 지금 필요한 것과 앞으로 필요하다고 설명할 수 있는 범위를 넘어, 감당할 이유가 충분하지 않은 복잡성까지 더하는 선택에 가깝습니다.

예를 들어 팀 하나가 쓰는 기능에 범용 플랫폼을 도입한다고 해보겠습니다. 플랫폼을 배포하는 절차와 접근 권한 관리가 필요할 수 있습니다. 장애가 나면 대응할 담당자도 있어야 하고, 새로 합류한 사람은 사용법을 배워야 합니다.

자동화도 이렇게 따져봐야 합니다. 가령 월 8시간 걸리던 수작업을 2시간으로 줄였다고 해보겠습니다. 대신 자동화 시스템을 관리하는 데 매달 4시간이 듭니다. 그러면 실제로 절약한 시간은 월 2시간입니다. 처음 시스템을 만드는 데 쓴 시간은 별도로 계산해야 하고요.

물론 큰 설계가 필요할 때도 있습니다. 여러 팀이 각자 배포해야 하거나 서로 다른 보안 요구를 충족해야 한다면 구조를 분리할 이유가 생깁니다. 복잡성을 더하기 전에, 그 비용을 감수할 만큼 구체적인 필요가 있는지 따져야 합니다.

일을 없앤 사람에게도 성과가 남아야 합니다

평가 방식을 바꾸려면 프로젝트를 설명할 때 묻는 질문부터 바꿔볼 수 있습니다.

• 어떤 사용자나 팀이 겪던 문제가 얼마나 줄었습니까?
• 기존 기능으로 해결할 수 있는 더 단순한 대안은 검토했습니까?
• 도입한 뒤 운영하고 유지보수하는 데 시간이 얼마나 듭니까?
• 이 일을 하지 않았다면 어떤 손실이 생겼을까요?

마지막 질문은 특히 잘 따져봐야 합니다. 프로젝트를 시작했다는 사실만으로 그 일이 필요했다고 볼 수는 없기 때문입니다.

일을 줄인 성과도 구체적으로 기록할 수 있습니다. 어떤 수동 절차를 없앴는지, 장애 대응 시간을 얼마나 줄였는지 적으면 됩니다. 더 이상 관리하지 않아도 되는 시스템도 여기에 포함됩니다. 다만 예상한 절감량과 실제로 확인한 결과는 구분해야 합니다.

저는 스태프 엔지니어에게 어디까지 만들면 충분한지 판단하는 능력이 중요하다고 생각합니다. 평가할 때도 이 판단을 인정해줘야 단순하게 해결한 일이 커리어에 불리하게 작용하지 않습니다. 큰 프로젝트를 성공시킨 사람을 인정하는 만큼, 그 프로젝트가 필요 없도록 문제를 풀어낸 사람도 인정해야 합니다.