스케줄의 중요성
기본을 지키는 것
출근하면 가장 먼저 메일함을 연다. 전날 밤 누군가 보낸 메일이 있을 수 있고, 새벽에 업데이트된 기획서가 첨부되어 있을 수도 있다. 이 일을 20년 넘게 해왔지만, 메일 확인은 여전히 긴장되는 순간이다. 메일 한 통이 오늘 하루를, 어쩌면 일주일을 바꿀 수 있다는 걸 알기 때문이다.
프로젝트는 언제나 빠듯하다. 넉넉한 일정으로 시작하는 프로젝트를 본 적이 없다. 일을 주는 쪽에서는 기간을 줄이거나 인력을 줄이려 애쓰고, 일을 받는 쪽에서는 최대한 빡빡하게 스케줄을 잡아야 수주가 가능하다. 마감이 심하게 지연되면 지체상금이라는 벌금까지 물게 된다. 하루 단위로 벌금이 책정되니, 늦으면 늦을수록 손해가 커진다.
개발이 완료되고 테스트가 한창 진행되던 때였다. 고객과 테스트 전문인력들이 대거 투입되어, 매일 엑셀 시트에 가득한 오류 리스트가 날아왔다. 그날 오류를 수정하면 다음날 다시 테스트가 들어가는, 가장 힘든 고비를 넘기고 있었다. 테스트 전문 인력은 기획서 없이 일반 고객처럼 무작위로 테스트하기 때문에, 기획서에 없는 내용도 오류로 올라오곤 했다. 기획자나 프로젝트 관리자(PM)가 하나하나 오류가 아니라고 대응하느라 정신없던 시기였다.
그때 테스트 도중 데이터를 넣어달라는 요청이 왔다. 원하는 데이터가 무엇인지 메일로 문의했지만, 회신이 없었다. 재차 몇 번을 문의해도 마찬가지였다. 해결된 것으로 생각하고 시간이 흘렀다.
며칠 후, 오픈을 위한 종합 상황 체크 회의가 열렸다. 데이터를 요청했던 사람이 갑자기 이슈를 제기했다. 데이터가 들어오지 않아 테스트가 되지 않았다는 것이었다. 문의 메일을 보냈다고 해도 막무가내였다. 보냈던 메일을 전부 찾아내 언제 몇 시에 보냈다는 증거자료를 제시해야 했다. 급하게 데이터를 만들고 다시 며칠간 테스트를 진행한 후에야 해결됐다.
아침 메일 확인이 끝나면 WBS 엑셀 파일을 연다. Work Breakdown Structure, 작업분류체계. 간단히 말해 기능별 일정표다. 오늘 완료해야 할 기능이 무엇인지, 체크해야 할 사항이 무엇인지 확인한다. 별다른 이슈가 없으면 바로 개발 업무로 들어간다.
문제는 풀리지 않는 코드를 만났을 때다. 프로그램 개발을 하다 보면 하루 이틀 시간이 순식간에 사라진다. 학창 시절 수학 한 문제에 몇 시간, 며칠을 보낸 경험이 있다면 그 느낌과 비슷하다. 그래서 스케줄 체크는 하루하루 매일 해야 하고, 기간 안에 완수가 힘들면 바로 관리자에게 알려 조율해야 한다.
하지만 많은 사람이 하나의 기능에 모든 시간을 써버린다. 일정 마지막까지 혼자 고민하다가 그제야 다른 개발자나 프로젝트 관리자에게 문의한다. 그러면 해당 기능은 급하게 다른 개발자에게 넘어간다. 넘겨받은 개발자는 넉넉히 진행하다가 갑자기 날벼락을 맞는다.
쇼핑몰 프로젝트를 진행할 때였다. 두 명에게 이벤트 참여 고객 특별 할인 기능을 할당했다. 한 사람은 이벤트 페이지와 참여 고객 리스트 적재 기능을, 다른 한 사람은 주문 시 고객 조회와 할인금액 적용 기능을 맡겼다. 각자 가능한 일정을 받아 고객과 조율해 진행했다. 중간중간 개발 진도를 체크했을 때는 별다른 문제가 없어 보였다.
테스트 일정 이틀 전, 개발된 기능을 체크하는 순간 문제가 터졌다. 한 개발자가 기능 하나로 일정을 전부 소비해버린 것이다. 다른 기능은 손도 못 댄 상황이었다. 왜 못했는지 따질 시간도 없었다. 다른 경력 많은 개발자에게 급하게 넘기고, 고객에게는 사정을 이야기하고 일정을 지연시켰다. 이후 그 개발자에게는 간단한 기능만 할당하고, 하루하루 직접 스케줄을 체크해야 했다.
오랜 고민은 결코 득이 되지 않는다. 자신이 어떻게든 해보겠다는 생각은 자만심이다. 하루가 지나도 해결되지 않는 코드가 있다면, 다른 경험 많은 개발자의 도움을 받아야 한다. 경력 20년이 넘어도 막히는 부분은 분명 존재한다. 다른 개발자들과 함께 고민하면 해결책이 보인다.
과신도 금물이다. 프로젝트마다 개발 언어도 다르고 개발 방식도 다르다. 자신의 실력을 과신하면 어려움에 봉착하거나 스케줄 압박에 시달리는 건 시간문제다. 경력 15년 이상 개발자들도 새로운 프로젝트에 참여하면 프로젝트와 사용 기술 학습부터 시작한다. IT 분야는 하루가 다르게 신기술이 쏟아지고 새로운 개발 언어가 탄생한다.
반대로 두려움도 버려야 한다. 모르는 건 당연한데도 말하기 두렵거나, 풀리지 않는 문제로 끙끙 앓다가 마감 직전까지 끄는 사람이 많다. 회사 업무는 학원이 아니다. 마감 기한이 반드시 존재하고, 못하게 되면 프로젝트 자체가 지연되어 손해를 끼친다. 배우는 자세는 누군가 가르쳐주는 게 아니다. 먼저 가서 물어보는 적극성이 필요하다. - 내성적이라는 지극히 개인적인 성향은 변명이 안된다. -
두 사건 모두 같은 문제에서 비롯됐다. 가장 기본이되는 메일 확인을 소홀히 하거나(소통), 자신의 스케줄을 관리하지 못하는 것(일정). 경력 1년이든 10년이든, 이 기본을 놓치는 순간 프로젝트는 흔들린다.
그렇다면 스케줄은 어떻게 관리해야 할까. 개발 기능과 일정이 주어지면, 우선 기능을 세분화하고 어떻게 구현할지 코드 자료를 찾는다. 이전까지 코드 자료는 대부분 구글에서 검색했다. 네이버는 국내라는 한정성이 있어, 새로운 기술일 경우 구글이 더 효과적이었다. 검색으로 찾은 사이트들이나 코드들은 즐겨찾기나 텍스트 파일로 저장하고, 처음 사용하는 기술이라면 관련 서적을 사서 참고했다. 이제는 AI로 대체됐다. 검색은 Perplexity에서 검색하고, 코드는 GPT, Claude가 작성해준다.
모은 자료들을 주어진 일정 내에 언제 적용하고 시도할지 일일 단위로 적어둔다. 일 단위로 지정하는 이유는 모은 자료가 오류를 내거나 잘못된 코드일 수도 있기 때문이다. AI로 작성한 코드가 100% 제대로 작동할거라는 생각은 오산이다. 이럴 경우 검색이나 AI 대화에 시간을 대부분 투자한다.
세부 개인 일정이 정해지면 그날에는 그 기능을 완료해야 한다. 매일 스케줄을 체크하는 건 오늘 완료해야 할 기능을 체크하는 것과 같다. 완료하지 못하고 내일로 넘기면 내일 일정에 지장을 준다. 계속 미루면 일정 지연이 발생하고, 다른 개발자들에게 피해가 간다.
메일이나 메신저는 바로바로 회신하려 노력한다. 조금 시간이 필요한 경우에는 검토하겠다는 메일을 먼저 보내고, 하루 이틀 후에 반드시 회신한다.
프로젝트의 기본 툴은 다룰 줄 알아야 한다. 간트차트를 다룰 줄 알아야 하고, 엑셀은 기본으로 다뤄야 한다. 구글 드라이브는 물론, 기획자라면 파워포인트와 엑셀 함수까지 더 나아가 피그마 사용법 정도는 알아야 한다.
하지만 이 모든 도구와 방법론보다 중요한 건 성실함이다. 수시로 메일을 확인하고 자신의 스케줄을 체크하는 것. 단순해 보이지만, 이 기본이 지켜지지 않을 때 프로젝트는 무너진다.
20년이 넘게 이 일을 해왔다. 여전히 매일 아침 메일함을 열 때는 긴장된다. 메일 한 통이 일주일을 지연시킬 수 있고, 하루 하나의 기능을 놓치는 것이 프로젝트 전체를 흔들 수 있다는 걸 알기 때문이다. 스케줄 관리는 거창한 기술이 아니다.
매일,
성실하게,
기본을 지키는 것.
그게 전부다.
