얼마 전 사람 사이에서는 책임의 경계를, 코드 안에서는 지식의 경계를 정리하고 있다고 썼다.
그리고 바로 다음 날 휴가를 썼다. 휴가가 끝난 뒤에는 새로운 일이 담당자 이름부터 달고 찾아왔다.
두 장면은 처음에는 달라 보였다. 하나는 휴가 중 발생한 배포 문제였고, 다른 하나는 요구사항이 정리되지 않은 새 작업이었다. 그런데 최근의 대화를 다시 훑어보니 같은 흐름 위에 있었다.
사람의 상태와 일의 맥락은 충분히 넘겨지지 않는데, 확인과 책임만 특정 개인을 정확히 찾아왔다.
PC는 열기 어려웠다
회사 PC에는 근태 관리 도구인 시프티가 적용돼 있다. 휴가이거나 근무 시간이 아니면 화면 사용이 제한되기 때문에, 휴가 중 잠깐 업무를 확인하는 일도 예전보다 어려워졌다.
방향 자체는 이해한다. 휴가에는 일하지 않는 것이 맞다. PC를 켜지 못하면 자연스럽게 업무와 거리를 둘 수도 있다.
문제는 PC만 닫혔다는 것이다.
누구도 휴가를 무시하자고 말하지는 않았다
최근 두 달의 대화를 다시 훑어봤다. 의외로 누군가가 노골적으로 휴가를 무시한 장면은 찾기 어려웠다.
누군가는 내 휴가 일정을 발견하고 일대일 미팅을 다른 날로 옮기며 미안하다고 했다. 누군가는 자신이 자리를 비우는 날 동료에게 새 구성원의 온보딩을 부탁했고, 곧 휴가를 떠날 구성원에게 자신이 비운 동안 진행된 일을 미리 정리해 달라고 요청했다. 휴가와 부재를 인지하고, 필요한 경우 일정을 조정하거나 대행자를 세우려는 행동은 분명히 있었다.
그래서 이 글을 특정인의 무례함에 관한 이야기로 쓰고 싶지는 않다. 모두가 휴가를 존중해야 한다고 생각하는데도 실제 업무는 계속 휴가자를 찾아왔다.
문제는 의도보다 구조에 있었다.
규칙은 많았지만 팀의 규율은 없었다
이전부터 팀에는 확인해야 할 항목이 많았다. 티켓의 필수 필드를 채우고, 예상 일정을 숫자로 적고, 작업마다 문서를 남기고, 코드 변경과 도구 사용 기록을 관리했다. 무엇을 기록하고 어떤 형식으로 보여줘야 하는지는 점점 구체적이 됐다.
그러나 일이 어디로 들어와야 하는지, 요구사항이 비어 있을 때 누가 채워야 하는지, 담당자가 없을 때 누가 판단을 이어받는지, 여러 조직이 얽힌 일의 최종 결정자는 누구인지에 대해서는 같은 수준의 규율이 없었다.
규칙과 규율은 달랐다. 규칙은 구성원에게 무엇을 제출할지 요구할 수 있다. 규율은 팀 안에서 책임이 어떻게 흐를지를 정한다. 전자는 많았지만 후자는 충분히 만들어지지 않았다.
그 차이는 리더가 자리를 떠난 뒤 빠르게 드러났다. 확인을 위해 만들어진 형식은 남았지만, 그 형식 바깥에서 판단하던 사람의 역할은 제대로 분산되지 않았다. 과거 맥락을 아는 사람을 다시 찾거나, 가장 가까운 담당자와 온콜이 빈 부분을 조사해 채워야 했다.
내가 본 결과만 놓고 보면, 팀을 운영하는 체계보다 팀이 운영되고 있다는 흔적을 관리하는 체계가 더 많이 남았다.
리더의 역할은 자신이 있을 때 모든 상황을 확인하는 데서 끝나지 않는다. 자신이 없어도 일이 들어오고, 분류되고, 결정되고, 이어질 수 있게 만드는 데까지 닿아야 한다. 그 기준에서 보자면 남겨진 팀은 충분히 준비돼 있지 않았다.
개인적으로 휴가 일정을 배려하는 것과 팀이 휴가자를 찾지 않아도 되게 만드는 것은 다른 일이다. 전자의 친절은 있었지만, 후자의 책임은 완성되지 않았다.
동의는 있었지만 전달은 없었다
가장 이해하기 어려웠던 장면은 결정 자체가 없었던 경우가 아니었다. 누군가는 이미 앞선 논의에 참여해 방향을 알고 있었고, 그 자리에서는 동의했다. 그러나 그 내용이 실제로 작업할 사람에게는 전달되지 않았다.
실행자는 빠진 맥락을 모른 채 코드를 보고, 관련자를 찾고, 질문을 만들어가며 방향을 추정했다. 여러 사람이 시간을 들여 답에 가까워진 뒤에야 맥락을 알고 있던 사람이 대화에 들어와 “맞아요”라고 확인했다.
그 짧은 확인은 결론만 보면 틀리지 않았다. 하지만 이미 알고 있던 내용을 필요한 시점에 전달하지 않았다면, 사후의 동의는 실행자를 돕는 정보가 아니라 뒤늦은 판정에 가깝다.
더구나 그 사람이 중간에 개입해 방향을 바로잡으면, 겉으로는 문제를 해결한 것처럼 보인다. 전달 누락 때문에 발생한 탐색 비용은 기록되지 않고, 실행자가 처음부터 제대로 알지 못했던 것처럼 남기 쉽다. 정보를 가진 사람이 해야 했던 전달의 책임은 사라지고, 정보를 받지 못한 사람이 헤맨 과정만 보인다.
나는 이 방식이 특히 답답했다. 몰랐다면 함께 확인하면 된다. 알고 있었다면 작업이 시작되기 전에 전달해야 한다. 알고도 전달하지 않은 채 나중에 나타나 맞다고 확인하는 것은 리더십이라기보다 정보 병목에 가깝다.
합의는 회의에서 고개를 끄덕이는 것으로 끝나지 않는다. 결정 사항, 이유, 영향을 받는 사람, 다음 행동을 실행자에게 전달해야 비로소 팀의 합의가 된다. 그 연결을 책임지는 것은 리더 역할의 부수적인 친절이 아니라 기본 업무다.
일은 그대로 나를 찾았다
아침부터 정기배포 QA 문의가 Slack으로 들어왔다. 테스트 환경을 묻는 간단한 질문으로 시작했지만, 곧 화면에 필요한 정보가 나오지 않는다는 문제가 발견됐다.
나는 휴가였고 대무자는 정해져 있지 않았다. PC로 코드와 환경을 충분히 확인하기도 어려웠다. 결국 모바일 Slack으로 상황을 따라가며 원인을 추정하고, 출근한 동료에게 관련 변경의 리버트와 재배포를 부탁했다.
오후에는 다른 QA 이슈가 다시 나를 찾았다. 하나는 내 변경과 관련이 있었고, 다른 하나는 기존부터 있던 문제였다. 하지만 외부에서 짧은 메시지만 보고 있을 때는 그 둘을 바로 구분하기 어려웠다. 확인이 애매하면 관련 변경을 넓게 되돌려야 하나 고민했고, 다시 동료에게 조사와 실행을 부탁했다.
결국 문제는 정리됐다. 관련 변경은 되돌렸고, 무관한 기존 문제는 다음 작업으로 분리했다. 나는 직접 코드를 수정하지 않았지만 오전부터 오후 늦게까지 Slack을 계속 확인했다.
휴가 중 잠깐 대응한 것이 아니라, 하루 종일 간헐적으로 업무를 대기한 셈이다.
PC는 열지 못했지만 휴대폰은 내려놓지 못했다.
휴가가 끝나자 더 촘촘한 확인이 시작됐다
다음 날 출근하자 새로운 작업이 내게 배정됐다는 메시지가 와 있었다.
그런데 티켓에는 정작 요구사항이 없었다. 무엇을 해결하려는지, 기대 결과가 무엇인지, 어느 조직과 어떤 합의가 필요한지부터 확인해야 했다. 그와 동시에 언제 시작할지, 언제 끝낼지, 얼마나 걸릴지, 관련 의존성은 무엇인지 정리해 달라는 요청이 따라왔다.
누가 할지는 정해졌지만, 무엇을 왜 해야 하는지는 정해지지 않은 일이었다.
입력은 비어 있는데 출력 형식과 일정 확인은 촘촘했다.
업무 상황을 확인하는 것 자체가 마이크로매니징은 아니다. 여러 작업이 동시에 진행된다면 일정과 위험을 확인할 필요가 있다. 문제는 일을 결정하는 데 필요한 정보와 권한은 주어지지 않은 채, 담당자에게 조사와 판단과 보고를 한꺼번에 요구할 때 생긴다.
이 상태에서 담당자는 구현을 시작할 수 없다. 관련 대화를 찾고, 맥락을 가진 사람을 수소문하고, 다른 조직이 무엇을 할 수 있는지 묻고, 빠진 요구사항을 채워야 한다. 그렇게 겨우 시작점을 만들고 나면 이제 그 과정과 예상 일정까지 다시 보고해야 한다.
확인은 세밀한데 결정은 아래로 내려왔다. 일정은 묻지만 우선순위를 결정한 근거는 없었고, 담당자는 지정됐지만 요구사항의 소유자는 보이지 않았다.
내가 최근 느낀 마이크로매니징은 “몇 시에 무엇을 했는지”를 묻는 전형적인 모습만은 아니었다. 일의 작은 진행은 계속 확인하면서, 일을 성립시키는 큰 결정은 담당자가 알아서 복원하게 하는 방식에 가까웠다.
온콜에게 넘어온 맥락 없는 일
비슷한 장면은 그전에도 있었다.
처음 보는 프로젝트의 인수인계가 필요한지 판단해 달라는 요청이 온콜 담당자에게 전달됐다. 관련 문서만 넘겨받은 것이 아니었다. 인수인계가 필요한 상태인지부터 직접 확인해야 했다.
담당자는 대화와 코드 변경을 찾아보고, 현재 구현 범위와 남은 연동, 검증해야 할 부분을 파악했다. 관련 기획자와 서버 개발자를 찾아 질문한 뒤에야 “이 일은 아직 인수인계가 필요하다”는 결론을 만들 수 있었다.
요청을 받은 사람이 성실하게 조사했기 때문에 일은 앞으로 갔다. 그러나 온콜은 들어온 일을 접수하고 분류해 실제 소유자에게 연결하는 역할이지, 맥락이 사라진 모든 일의 새로운 주인이 되는 자리는 아니다.
질문을 받은 사람이 답을 찾을 수 있다는 이유로 조사, 요구사항 복원, 관계자 탐색, 일정 판단까지 떠안으면 책임의 경계는 계속 넓어진다. 처음에는 “이것만 확인해 주세요”였던 일이 답을 찾는 과정에서 하나의 프로젝트가 된다.
그리고 답을 만든 사람은 어느새 그 일의 담당자로 보이기 시작한다.
책임은 다음 사람에게 이동했다
최근의 일들을 순서대로 놓으면 흐름이 보였다.
맥락이 충분하지 않은 요청이 들어온다. 누군가는 가장 가까운 담당자나 온콜에게 먼저 넘긴다. 받은 사람은 자신도 모르는 일이라 다시 관계자를 찾는다. 관계자는 다른 조직의 확인이 필요하다고 말한다. 그 확인을 끝낸 사람이 다시 최초 요청자에게 결과와 일정을 보고한다.
일은 여러 사람을 거쳤지만, 정작 누가 요구사항을 확정하고 누가 최종 결정을 내리는지는 끝까지 흐릿하다. 책임은 명확해지지 않은 채 다음 사람에게 이동하고, 마지막에 멈춘 사람이 일단 들고 있게 된다.
그래서 때로는 폭탄 돌리기처럼 느껴졌다. 책임을 맡았다고 명시적으로 말하는 사람은 없는데, 누군가는 계속 받아서 다음 단계로 넘겨야 한다. 가장 성실하게 맥락을 찾은 사람이 가장 많은 책임을 갖게 되는 역설도 생긴다.
휴가 중 QA 문의가 코드 작성자를 바로 찾아온 일도 같은 구조였다. 작성자가 가장 빨리 답할 수 있다는 사실이 작성자만 답해야 한다는 뜻은 아니다. 배포 담당자와 대무자가 변경 목적, 검증 방법, 되돌릴 범위를 알고 있었다면 휴가자의 판단을 빌릴 필요가 없었다.
휴가 날에는 휴대폰으로 기존 작업의 책임을 붙잡았고, 복귀한 날에는 담당자 칸에 적힌 이름 때문에 새 작업의 빈 맥락까지 떠안았다.
내가 지친 것은 단순히 일이 많아서만은 아니었다. 결정할 권한 없이 결정에 필요한 맥락을 복원하고, 그 과정마저 촘촘히 설명해야 했기 때문이다.
잘못된 결론
휴가 날 나는 농담처럼 말했다.
화요일에는 휴가를 쓰지 말아야겠다.
정기배포와 QA가 몰리는 날이었기 때문이다. 하지만 이건 잘못된 결론이다.
배포가 있는 날에도 휴가는 쓸 수 있어야 한다. 담당자가 휴가라면 다음 사람이 판단을 이어갈 수 있어야 한다. 휴가자가 Slack을 계속 확인해서 문제가 해결됐다면 개인의 책임감은 작동했지만 업무 체계는 작동하지 않은 것이다.
복귀한 뒤에는 또 다른 잘못된 결론이 생긴다.
다음에는 요청받기 전에 내가 더 빨리 알아보고, 더 자세히 정리해 두자.
하지만 요구사항을 정하는 책임까지 실행자가 미리 떠안는 것으로는 문제가 해결되지 않는다. 오히려 맥락 없이 일을 넘겨도 누군가 알아서 채워주는 구조를 더 단단하게 만든다.
근태 시스템은 휴가자의 PC 사용을 막았다. 그러나 업무 시스템은 휴가자를 담당자 자리에서 내려놓지 못했다.
더 필요한 것은 보고가 아니라 앞단의 책임이다
이번 일에서 필요한 것은 더 촘촘한 상태 보고가 아니었다.
- 요청자는 해결할 문제와 기대 결과를 먼저 설명한다.
- 의사결정자와 실행 담당자를 구분하고, 최종 판단을 누가 할지 적는다.
- 새 담당자를 지정하기 전에 요구사항과 의존 관계를 티켓에 남긴다.
- 온콜은 모든 일을 떠안지 않고 접수와 분류 뒤 실제 소유자에게 연결한다.
- 휴가자의 작업에는 이름이 명시된 대무자와 판단 가능한 인수인계를 둔다.
- 배포 전 변경별 검증 방법과 리버트 범위를 남긴다.
- 장애급 상황이 아니라면 휴가자가 응답하지 않는 것을 정상으로 본다.
- 진행 확인의 주기와 형식은 업무를 시작할 때 합의한다.
요구사항이 비어 있다면 담당자가 채울 때까지 재촉할 것이 아니라, 요청자와 의사결정자가 먼저 빈칸을 메워야 한다. 담당자는 질문할 수 있지만, 질문을 했다는 이유로 요구사항의 소유자까지 되어서는 안 된다.
이 정도만 지켜도 휴가자는 PC와 Slack을 함께 닫을 수 있다. 출근한 담당자도 맥락을 발굴하는 데 에너지를 쓰지 않고 실제 문제를 해결하는 데 집중할 수 있다.
휴가를 지키는 것과 책임을 명확히 하는 것은 별개의 문제가 아니었다. 사람이 자리를 비웠을 때 누가 판단을 이어받는지 정하지 못하는 조직은, 새로운 일을 시작할 때도 누가 요구사항과 결정을 책임지는지 흐려지기 쉽다.
팀장 역할을 다시 생각했다
이 일을 겪으며 뜻밖에도 팀장 역할을 다시 생각하게 됐다.
예전에는 팀장을 맡으며 사람과 일정 사이에서 소모됐던 기억이 컸다. 다시 개발에 집중한 뒤에는 한동안 굳이 그 역할로 돌아갈 필요가 없다고 생각했다. 그런데 최근에는 오히려 내가 다시 맡아도 괜찮겠다는 생각이 든다.
내가 다른 사람보다 뛰어나서가 아니다. 팀장이 무엇을 해야 하는지에 대한 기준이 전보다 분명해졌기 때문이다.
팀의 규율은 사람을 더 자주 확인하는 규칙이 아니다. 일이 어디로 들어오고, 누가 우선순위를 정하고, 누가 최종 결정을 내리며, 담당자가 없을 때 누가 이어받는지를 합의하는 방식이다. 이 규율이 있으면 구성원은 매번 관계자를 찾아다니며 조직의 빈칸을 메우지 않아도 된다.
팀장은 모든 일을 직접 결정하는 사람도, 진행 상황을 가장 자주 묻는 사람도 아니다. 구성원이 결정할 수 있는 범위를 정하고, 필요한 맥락을 제공하고, 책임이 주인 없이 떠돌지 않게 만드는 사람에 가깝다. 문제가 생겼을 때 가장 가까운 사람에게 넘기는 것이 아니라, 문제를 품어야 할 자리를 분명히 하는 역할이기도 하다.
돌아보면 나에게도 좋은 경험과 좋지 않은 경험이 모두 있었다. 어떤 리더에게서는 부재를 준비하는 법을 배웠고, 어떤 상황에서는 규율 없는 위임이 사람을 얼마나 지치게 하는지 배웠다. 예전에는 그 경험들을 각각의 사건으로만 기억했다. 지금은 그것들을 내가 만들고 싶은 팀의 원칙으로 정리할 수 있을 것 같다.
직함이 있다고 저절로 리더십이 생기지는 않는다. 반대로 현재 직함이 없다고 해서 그동안 쌓은 경험과 기준까지 사라지는 것도 아니다. 어수선한 상황을 겪으며 내가 얻은 결론은 누군가를 평가하는 데 머무르지 말자는 것이다. 그보다 내가 겪은 좋은 방식과 나쁜 방식을 정리해, 다음 사람에게 더 나은 경험으로 전달하는 편이 낫다.
그래서 “내가 다시 팀장을 해도 괜찮을까”라는 질문에 예전보다 조금 편하게 답할 수 있게 됐다.
잘할 수 있다고 장담해서가 아니라, 적어도 무엇을 방치하면 안 되는지는 알고 있기 때문이다.
이번 휴가에도 나는 대응할 수 있었다. 동료들도 기꺼이 도와줬고 실제 문제도 정리됐다. 복귀한 뒤 받은 일도 결국 관련자를 찾아가며 구체화할 수 있을 것이다.
그러나 결과가 나올 수 있다는 사실과 과정이 정상이라는 판단은 다르다. 개인이 계속 빈칸을 메울 수 있다는 이유로 확인은 더 촘촘해지고 책임은 더 흐려져서는 안 된다.
나는 다음 휴가에는 내가 없어도 대응할 수 있는 상태를 만들고 싶다. 출근한 날에는 다른 사람이 넘긴 일의 다음 전달자가 아니라, 목적과 책임이 정리된 일을 제대로 해결하는 개발자이고 싶다.
언젠가 다시 팀을 맡게 된다면 구성원이 휴가 중 휴대폰을 붙잡지 않아도 되고, 빈 티켓을 받은 사람이 혼자 요구사항부터 복원하지 않아도 되는 팀을 만들고 싶다. 최근의 혼란을 누군가에 대한 불평으로만 남기기보다, 내가 알고 있는 더 나은 방식을 다시 꺼내는 계기로 남겨두려 한다.