brunch

"아무것도 못 했는데 하루가 갔다"는 개발자에게

업무 우선순위 정리 4단계

by mingdu

일을 하다 보면 계획대로 흘러가는 날도 있지만, 모든 것이 엇갈리는 날도 있다.

모든 업종에서 흔한 일이겠지만, 개발자에게는 유독 뜻대로 되지 않는 날이 더 많은 것 같다. 일주일의 플랜은 커녕 아침에 정해놓은 오늘의 할 일을 그 날 정상적으로 끝내는 것도 버겁다. 이를테면, 라이브 운영 이슈, 기획 정책 변경, 테스트 후 발견한 오류 등으로 인한 상황들이 끼어들고는 한다. 이런 일들이 한꺼번에 몰려왔을 때 우선 순위를 어떻게 가져가야 할지, 멍해지고 앞이 깜깜해지곤 한다.

최대한 혼란없이 업무의 우선 순위를 잘 배치하려면 어떻게 하는게 좋을까?




가장 급한 일부터 : 라이브 이슈

‘지금 가장 급한 업무가 뭐지?’ 질문만 봐도 딱 생각나는 업무가 있다. 바로 "라이브 이슈" 이다. 라이브 이슈란, 현재 운영되고 있는 서비스에서 오류나 장애가 발생했을 경우이다. 물론 라이브라고 해도 사용자들에게 보이지도 않는 구석진 곳에 있는 기능에서 오류가 발생한다면 그 보다 더 급한 업무를 처리하는게 나을 때도 있다. 그렇지만 웬만한 상황에서는 가장 급한 업무는 현재 운영중인 시스템의 오류를 수정하는 것이다.


테스트 이슈는 빠르게 처리하기

이미 내 기준 개발이 다 끝난 기능을 QA팀에서 테스트를 할 때, 개발하면서 체크하지 못한 이슈들이 나오곤 한다. 그런 경우에는 다른 개발 건을 수행하고 있더라도 테스트 중 발생한 이슈들을 처리해야 한다. 이미 해당 개발 사항은 내가 '개발을 다 끝냈다' 라는 전제로 테스트를 진행한 건이기 때문에 오류 사항이 나온다면 바로바로 수정을 해주는 것이 맞다. 그래야 재검토를 QA팀에서 진행하고 이슈 없음을 체크해 줄 수 있기 때문이다.


전체적인 일정 확인하기

라이브 이슈도, 테스트 이슈도 아닌 개발 건들이 한꺼번에 몰려왔을 때는 프로젝트의 전체적인 일정 파악이 필요하다. A 업무와 B 업무가 실제 라이브에 반영되는 기간이 다르다면 당연히 빠른 순서의 업무를 먼저 진행해야 한다. 만약 반영 기간 마저 동일하다면 테스트 기간이 빠른 순으로 업무를 나열해보자. 그마저도 기간이 동일하다면 업무가 나에게 들어온 순서대로 처리하면 좋다.


빠른 일 먼저, 마음의 짐 줄이기

앞서 말한것과 같이 여러 업무가 배정됐는데, 라이브 반영날짜, 테스트 기간이 똑같고 심지어 나에게 업무가 들어온 순서마저 거의 비슷한 경우가 있다. 이럴 땐 당황하지 말고, 비교적 빨리 끝낼 수 있는 업무부터 차근차근 해보자. 여러 업무를 오랫동안 계속 가지고 있는 것보단 하나하나씩 빠른 처리가 가능한 업무부터 소거해나가면 내 마음의 짐도 하나씩 줄어드는 느낌을 받을 것이다.




부가적으로, 너무 급한 경우에는 하드코딩이나 지독한 반복문도 어느 정도 용납해주라고 말하고 싶다. 처음부터 구조를 잘 잡고, 확장성을 고려하고 싶은 마음은 누구에게나 있다. 그러나 지금 당장 나에게 주어진 시간이 너무 짧다면 일정에 맞춰 개발하고 이후에 개선하는 시간을 가지자. 다만, 개선 작업을 하면서 오히려 잘 되던 기능이 안되는 아이러니한 상황에 빠질 수 있으니 여유가 있는 상황에서 꼼꼼하게 해야한다.




위의 방식들이 정답은 아닐 수 있다. 하지만 업무가 몰려 머릿속이 하얘질 때, 이 방법들을 한 번쯤 떠올려보자. 그 짧은 생각의 틈에서 나만의 방식이 떠오를 수도 있다.

개발자에게 예상치 못한 상황은 매일 같이 찾아온다. 그 안에서 침착함을 유지하고, 스스로를 컨트롤할 수 있다면, 우리는 매일 조금씩 ‘추가 시간’을 벌 수 있을지도 모른다.


keyword