라떼 시리즈 (3): 일의 각을 재는 법
- 어느덧 가을이 끝나가는 시점, 라떼 포스팅은 글럼프글 + 슬럼프 없이 순항 중입니다. 이렇게 제가 라떼하다는 것을 증명하고 있죠. 하하하
- 이번 글은 일을 본격적으로 하기 전에 일의 각을 재는 방법에 대해서 쓰고자 합니다.
어머니는 설거지도 잘 해야 한다고 하셨어
저희 어머니는 설거지와 같은 사소한 일이라고 해도 "어떻게 하면 일을 잘한다고 소문이 날까?"라고 제게 묻곤 했습니다.
진지하게 고민할 필요 없이 "대충 해~!"라고 말씀드릴 수도 있었지만 저도 어머니를 닮았나봅니다. 이 질문에 진지하게 고민을 합니다.
‘어떻게 해야 설거지를 효율적으로 하지?’, ‘몇 시에 해야 내가 설거지를 즐겁게 하지?’, ‘어떤 수세미로 그릇을 닦아야 가장 깨끗하지?’ 등을 말이죠.
이처럼 어떻게 해야 일을 잘 할 수 있을까 (혹은 어떻게 해야 소문이 날까?)에 대한 고민도 필요하다고 생각했습니다.
일의 각을 어떻게 잰다는거야?
월루 (월급 루팡) 각을 재라는 것이 아닙니다.
{:.figure}
일의 각을 재는 것은 스케줄을 관리하는데 필수적이며, 일을 능동적으로 하는 데 중요한 능력입니다.
반대로 말하면 각을 재지 못하면 일이 늘어질 수도 있고, 정신 없이 여러 일을 동시에 맡으면서 질질 끌고 가는 경험을 할 수 있습니다.
저도 아직도 일의 각을 재는데 헤매고 시행 착오를 겪고 있는데요.
예를 들어 아주 작은 일인 줄 알고 자원했던 일이 1년 동안 지속되는 경우도 있고, 큰 일인 줄 알고 다른 일을 받지 않았는데 싱겁게 끝나는 경우도 있었습니다.
저희가 각도기도 아니고 정확하게 “이 일의 각은 30도야” 라고 잴 수는 없지만 일의 크기, 속성 등을 제대로 이해하고 일을 하게 되면 조금 더 능동적으로 일을 할 수 있다고 생각했습니다.
구체적으로 어떻게 일의 각을 잴 수 있을까요? 저는 이 4개를 파악하는 것이 중요하다고 생각합니다.
- When 언제 이 일을 마무리할 수 있는가? (이 일은 얼마나 시간이 소요되는가?)
- Why 왜 이 일을 하는가?
- Who 누구랑 일을 하는가?
- What 이 일을 세부적으로 나누면 어떻게 되는가?
Who: 누구랑 일을 하는가?
팀 내에서 하는 일이라면 그 분들과 쉽게 일정을 조율하면 될 일이지만, 특히 여러 팀이 관여했을 때 일을 하는 경우라면 누구랑 일을 하는지, 그 사람들의 역할은 무엇인지 정확히 아는 것이 중요하다 느꼈습니다.
왜 중요하냐면
- 여러 팀이 하나의 일에 관여하면 RnR Role and Responsibility가 나뉘기 때문에 이 팀은 이런 일을 하고, 저 팀은 이런 일을 하고 등을 파악하고 있어야 일의 전반적인 프로세스를 이해할 수 있기 때문입니다.
- 또한 일을 진행하면서 막히는 점이 있다면 관련된 분께 자유롭게 질문을 할 수 있어야 하기 때문에, 구체적으로 "팀"이 아니라 "누구"랑 일을 하는지 확인할 필요가 있습니다.
예를 들어 제가 개발한 추천 로직을 어떤 서비스에 적용하는 일이 생겼다고 가정해봅시다. 이렇게 크게 일을 나눌 수 있을 것입니다.
- 서비스에 핏하게 추천 로직 개발
- 실제 서비스에 추천 로직 구현
- 서비스에 실제로 추천 로직이 잘 작동하는지 검토
추천 로직 개발은 제가 담당한다고 했으니까 이 외의 일들은 누가 담당하게 될까요? (회사 규모나 체계가 어느 정도 잡혀서 RnR을 나눌 수 있는 상태라 가정합니다.)
아마도 실제 서비스에 추천 로직을 구현하는 것은 개발팀이 담당할 것입니다.
개발팀은 서비스에 고객이 유입되면 API를 호출해 추천 로직을 쌓은 DB를 바라볼 수 있도록 API를 설계하는 작업을 하시게 될 것입니다.
그런데 개발팀도 한 두 팀이 아니겠죠? 서비스별로 개발팀이 존재할 수 있고, 혹은 추천쪽 API만 개발하는 팀도 존재할 수 있습니다.
이렇게 개발팀이 개발을 담당하는 범위를 확인하고, 실제 담당하실 개발자는 누군지 확인하는 것이 좋다고 생각합니다.
또한 서비스에 실제로 추천 로직이 잘 작동하는지 검토하는 것은 추천 로직을 개발한 당사자 (본인)과 서비스를 전반적으로 운영하는 운영팀 모두일 것 같습니다.
추천 로직을 개발한 사람이라면 추천이 잘 되고 있는지 실제 서비스에 추천 로직이 적용되기 전, 후 모두 확인할 필요가 있습니다.
전에는 제가 설계한 대로 추천이 잘 나오고 있는지 확인해야 하고 (보통 API를 통해서 확인하기 때문에 이 때도 개발팀과 커뮤니케이션할 필요가 있더라고요), 후에는 추천 효과가 나고 있는지 트래킹할 필요가 있습니다.
운영팀은 추천 로직으로 인해 서비스에 과도하게 영향받는 부분은 없는지, 고객 동향은 어떤지 살펴볼 필요가 있습니다.
이처럼 어떤 팀의 누가 일의 어떤 단계를 맡는지 파악한다면 일의 큰 그림을 이해할 수 있습니다.
When: 언제 이 일을 마무리할 수 있는가?
일에 대한 작업 범위와 일정을 체크하는 것은 필수입니다. 그러나 일을 해보지도 않고서 언제 일을 마무리할 수 있을지 파악하는 것이 쉬운 일은 아닙니다.
일은 업무의 연속성에 따라 주기적 업무와 1회성 업무로 나뉠텐데요.
주기적 업무의 경우 짧은 기록만으로도 일을 마무리하기 위한 시간을 쉽게 예상할 수 있습니다.
위 그림에서 볼 수 있듯이 저는 어떤 주기적 업무에 대한 기록을 짧게 노션에 정리했는데요. 매 월 초에 시작하는 업무가 언제 끝나는지 확인하면서 이 업무 외에 어떤 업무를 할 수 있을지를 파악하는 용도로 기록하고 있습니다.
이보다 더 어려운 것은 1회성 업무입니다.
1회성 업무는 비슷한 업무를 했었을 때의 경험을 바탕으로 어느 정도 시간이 걸릴 것이다라는 감을 잡아야 하기 때문입니다.
이 말을 반대로 말하면 어떤 일을 경험해보지 않으면 완료 시간을 예상하기 어렵다는 것을 의미하기도 합니다.
그래도 처음 하는 일에 대해서 일의 완료 시간을 잘 예상하지 못했다고 해서 처음부터 부족하다고 생각하는 사람은 없을 것입니다.
아직은 주니어니, 여러 일들을 경험해보면서 이러한 데이터를 축적해나가는 것이 좋다고 판단합니다.
예를 들어 대시보드를 하나 만드는 데는 시간이 얼마나 소요될까요?
저는 빠르면 3일 ~ 늦으면 7일 정도 소요할 것이다라고 예상하고 있는데요. 이전에 대시보드를 만들었던 경험을 바탕으로 산출해낸 시간입니다.
대시보드를 만드는 과정을 복기해보면 다음과 같습니다.
- 대시보드에 필요한 데이터 소스를 찾고
- 데이터 소스에서 적절한 지표를 집계할 수 있는 코드를 짠다.
- 가라 (?) 데이터로 대시보드를 만들고 실제 잘 집계되었는지 데이터를 검증한다.
위에서 2번 코드를 짜는 과정은 데이터를 잘 찾았다는 가정에 하루, 3번 대시보드를 만드는 작업도 하루 정도 사용하고 있는데요.
1번의 경우 데이터가 얼마나 쉽게 접근할 수 있느냐에 따라 천차만별입니다.
잘 정제된 테이블에 "나 집계해주세요~!"하고 있는 데이터라면 하루만에 데이터를 후딱 찾고 2번 데이터 집계 코드를 개발하는 과정까지 완료할 수 있겠지만, 그렇지 않다면 정말 미지수이기 때문입니다.
다행인 건 이렇게 시간이 얼마나 걸릴지 파악하기 어려운 과정이 처음에 있다는 점입니다.
즉, 데이터 소스를 찾아보면서 데이터가 정말 잘 정리되어 있다면 바로 “빠르면 3일 안에 마무리할 수 있을 것 같다!” 라고 팀장님께 말씀드릴 수 있고,
아니라면 데이터 찾는 과정이 조금 걸리기 때문에 일주일 정도를 예상하고 있다고 말씀을 드릴 수 있을 것입니다.
이와 더불어 내가 예상하고 있는 일의 완료 시간을 그대로 보고하기 보다 조금의 여유를 두고 말씀드리는 것도 중요하다고 생각합니다.
라떼 시리즈 (1): 회사에서 꽤나 괜찮은 주니어가 되려면에서도 말씀드렸듯이 일이 한 가지만 있는 것이 아니라,
여러 성격을 가진 업무들이 같이 들어오기 때문에 우선순위를 따져 업무를 하다 보면 “일의 완료 시간” 그대로 지켜지기 어려울 때가 있기 마련이라 느꼈습니다.
그래서 저는 대시보드 업무도 빠르면 7일이라 생각하고 업무에 임하고 있습니다.
What: 이 일을 세부적으로 나누면 어떻게 되는가?
업무를 세부적으로 나눠야하는 이유는 Who와 When과도 밀접한 연관이 있습니다.
즉, 업무를 세부적으로 나눠서 각 세부 과정에서 누가 업무를 맡게 되는지 확인해야하고, 각 세부 과정에서 얼마나 걸릴지 예측해서 예상 시간의 총 합으로 이 업무는 언제 끝날 것이다라고 예상을 할 수 있기 때문입니다.
업무를 한 뭉텅이로 생각하고 일하다보면 진전 단계를 알기 어렵습니다.
내가 이 일을 진짜 하고 있는건지 이 일이 끝나기는 하는 건지 의구심이 들기도 합니다.
이에 비해 일을 세부적으로 나눈다면 크게 보면 이 일이 끝나지 않았더라도, 작게 봤을 때 하나 하나 이뤄가면서 성취감을 느낄 수 있다고 생각합니다.
위 예시에서 "대시보드를 만드는 과정"을 3단계로 짧게 나눴듯이, 대시보드가 모두 완성되어야 이 일이 끝나는 것이 아니라 하나의 과정이 끝날 때마다 중간 보고를 드리면서 업무의 일정을 업데이트하는 과정이 좋다고 생각했습니다.
Why: 왜 이 일을 하는가?
왜 이 일을 해야하는지, 그 목적을 파악하는 것이 일의 각 재는 것의 끝입니다.
그만큼 중요한 과정이기도 하고, 가장 어려운 과정이라고 생각합니다.
왜 이 일을 할까요?에 대한 대답으로
팀장님이 시켜서요.
라고 누군가는 말할 수 있겠지만, 이 것이 궁극적인 목적은 아니라 생각합니다.
일을 받을 때 수동적으로 팀장님이 하라고 해서 하는 것이 아니라, “이 일을 정말 해야 해? 해야한다면 왜 해야 하지?” 등을 명확히 하고 일을 해야 일을 잘 할 수 있다고 생각했습니다.
아묻따 팀장님이 시키는대로 다 잘 해낸다면 모두가 Happy한 걸 수도 있지만, 제 성격상 주도적으로 하지 않은 일에는 애정이 가지가 않더라고요…
하지만 일의 목적이 크지 않은 일도 분명히 존재합니다. 데이터 집계 요청과 같은 Ad-hoc 업무에는 열과 성을 쏟을 것이 아니라 빠르게 처리하고 끝내면 됩니다.
이와 반대로 제 커리어와 관련지을 수 있겠다 생각하는 업무에는 이게 어떻게 제 커리어에 어떻게 도움이 될 것인지 고민하면서 일을 하는 것이 필요하겠다 느꼈습니다.
또한 회사 입장에서도 이 일을 통해 무엇을 이룰 수 있는지, 그 궁극적인 목적은 무엇일지 상상해가면서 일하는 것도 좋을 것 같아요.
사실 저도 커리어를 막 생각하면서 일을 하는 입장은 아니긴 합니다. 그냥 이런 저런 경험을 하다 보면 어느새 성장한 내가 있겠지 이런 근심걱정 없는 마음…?
제가 일을 통해 얻어가는 게 있다면 가장 큰 부분은 성취감이기에 이 성취감을 만족시키기 위해 일을 왜 해야하는지 묻고, 실제로 일을 끝낸 후엔 이 목적을 달성했는지 확인하면서 성취감을 느끼는 것이 좋을 것 같습니다.
마무리
지금까지 일의 각을 재는 방법에 대해서 공유드렸습니다.
일의 각을 잘 재면
- 일을 체계적으로, 단계적으로 진행할 수 있고,
- 큰 단위의 일을 맡는다는 막막함에서 해방될 수 있으며
- 주도적으로 일을 할 수 있습니다.
저도 아직은 갈 길이 멀지만! 이렇게나마 일의 각을 계속 재가면서 시행착오를 줄여가는 노력을 하고자 합니다.
세 번째 라떼 끝!