코드를 덜 써도 성과를 만드는 엔지니어링 리더의 하루

코드를 덜 써도 성과를 만드는 엔지니어링 리더의 하루

AI 뉴스 썸네일

728x90

엔지니어링 리더의 캘린더는 회의로 가득하지만, 그 시간이 어떤 결과로 이어지는지는 쉽게 보이지 않아요. 설계 검토를 계획했던 하루가 팀 간 갈등이나 운영 장애, 로드맵 변경을 다루는 날로 바뀌기도 해요. James Samuel은 이런 업무를 여섯 가지 활동으로 나누면 리더가 실제로 무엇을 만드는지 더 선명하게 볼 수 있다고 설명해요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
업무의 형태	대화와 판단, 조율이 주요 산출물이에요	스프린트 보드에 잡히지 않는 리더의 기여를 설명할 수 있어요
하루의 순환	정보 수집, 공유, 결정, 영향, 실행, 계획을 반복해요	갑작스러운 일정 변경 속에서도 우선순위를 다시 잡을 기준이 생겨요
판단의 출발점	사람과 제품, 지표에서 들어온 정보를 엮어 현실을 파악해요	처음 받은 정보가 부정확하면 뒤의 결정도 잘못될 수 있어요
권한 밖의 일	다른 팀의 목표와 제약을 이해한 뒤 협력을 이끌어요	기술 해법이 있어도 담당 팀이 움직이지 않으면 실행할 수 없어요
성과 확인	직접 만든 기능보다 사람과 조직을 통해 낸 결과를 봐요	개인 기여자에서 관리자로 옮긴 뒤 생기는 성취감의 혼란을 줄여요

1. 엔지니어링 리더의 하루는 여섯 가지 활동으로 돌아가요

개발자는 커밋이나 배포한 기능으로 하루의 진척을 확인할 수 있어요. 관리자의 결과는 여러 대화와 결정에 흩어져 있어서 같은 방식으로 세기 어려워요. James Samuel은 엔지니어링 리더의 업무를 정보 수집, 정보 공유, 의사결정, 의사결정에 영향 주기, 실행 이끌기, 계획으로 구분해요. 직급이 일선 관리자에서 디렉터나 임원으로 바뀌어도 이 순환은 이어진다고 봐요. 1

정보 수집이 판단의 바닥을 만들어요

리더는 엔지니어와 고객의 이야기, 제품 지표, 장애 기록을 한꺼번에 접해요. 들어오는 내용을 모두 처리할 수는 없어요. 반복해서 나타나는 문제와 일시적인 잡음을 구분하고, 서로 떨어진 단서를 연결해야 해요. 현재 상황을 잘못 이해하면 엉뚱한 문제를 먼저 풀거나 새로 커지는 위험을 놓칠 수 있어요. 그래서 1:1이나 제품 리뷰, 지표 검토는 단순한 일정이 아니라 판단에 필요한 맥락을 얻는 시간이 돼요. 2

정보는 필요한 사람에게 맞는 크기로 전달해야 해요

리더는 팀 내부 사정과 조직 전체의 방향을 함께 접해요. 같은 내용도 엔지니어에게는 구현 배경이 필요하고, 상위 리더에게는 선택지와 비용이 필요해요. 누구에게 무엇을 언제까지 알릴지 정하는 일도 관리 업무예요. 조직 개편이나 프로젝트 취소처럼 불확실성이 큰 상황에서는 사실만 전하면 질문이 더 늘 수 있어요. 확인된 내용과 아직 정해지지 않은 범위를 나눠 말해야 팀이 다음 행동을 고를 수 있어요. 2

불완전한 정보로도 결정을 미룰 비용을 따져요

우선순위와 채용, 기술 방향에 관한 결정은 모든 정보가 모인 뒤 찾아오지 않아요. 선택지마다 얻는 것과 잃는 것이 섞여 있어요. 확실해질 때까지 기다리면 결정하지 않은 시간에도 일정 지연이나 운영 비용이 쌓여요. 리더는 지금 결정할 사안과 더 확인할 사안을 나누고, 결정 뒤에는 결과를 다시 살펴 판단 기준을 고쳐야 해요. 결정과 결과를 꾸준히 검토하면 다음 판단에서 무엇을 먼저 볼지 알 수 있어요. 2

다른 팀을 움직이려면 상대의 제약부터 알아야 해요

엔지니어링 리더가 관련 사안의 최종 결정권을 모두 갖는 경우는 드물어요. 다른 팀에 협력을 요청할 때는 그 팀도 자체 목표와 일정, 한정된 인력을 안고 있어요. 우리 팀의 필요만 반복하면 우선순위 경쟁으로 끝나기 쉬워요. 상대 팀이 얻는 결과와 감수할 비용을 함께 제시하면 협의할 수 있는 선택지가 생겨요. 기술적으로 맞는 답을 찾는 능력과 실제 담당자들이 움직일 조건을 만드는 능력이 함께 필요한 이유예요. 2

방향과 행동 기준을 일상에서 보여줘요

리더는 목표를 선언한 뒤 실행을 넘겨주는 사람으로 끝나지 않아요. 오래된 시스템을 바꾸려면 왜 지금 바꿔야 하는지 설명하고, 단계와 담당자를 구체화해야 해요. 장애 대응이 자꾸 꼬인다면 직접 대응에 참여해 상황 공유와 역할 조율, 사후 검토가 어떻게 이어지는지 보여줄 수도 있어요. 팀원은 문서에 적힌 원칙보다 반복해서 본 행동을 더 쉽게 따라요. 리더가 보여주는 대응 방식이 팀의 작업 기준이 되는 셈이에요. 2

왜 중요한가요

개인 기여자에서 관리자로 옮기면 직접 만든 코드가 줄어든 만큼 성과도 줄었다고 느끼기 쉬워요. 하지만 관리자의 작업 단위는 커밋이 아니라 더 나은 판단을 가능하게 한 정보, 멈춘 협업을 다시 움직인 조율, 반복 장애를 줄인 계획에 가까워요. 이 단위를 의식하면 회의 수가 아니라 회의 뒤 달라진 결정과 행동을 기준으로 하루를 돌아볼 수 있어요. 2

실무에서는 여섯 활동을 별도 체크리스트로 늘리기보다 막힌 업무를 진단하는 질문으로 쓰는 편이 좋아요. 정보가 부족한지, 공유 대상이 빠졌는지, 결정을 미루고 있는지, 다른 팀의 제약을 놓쳤는지 차례로 확인하면 다음 행동이 구체적으로 보여요. 리더의 일정이 갑자기 바뀌어도 무엇을 하고 있는지 설명할 언어가 생기고, 팀에도 판단 배경을 더 투명하게 전할 수 있어요. 1

참고 자료

1. 엔지니어링 리더는 매일 무슨 일을 하는가 — GeekNews
2. Engineering Leaders Day-to-Day Activities — Effective Software Leads, James Samuel