슈르의 오피스라이프

프로젝트 일정 수립...이라는 업무는 개발자들에게 상당히 낯선 업무다. 누군가가 쥐어주는 타임 프레임에 맞게 일한 적은 있어도 그걸 계획하는 일은 매우 드물 것이다. 물론, 이런 나의 말에 반감을 표하는 사람들이 있을 수 있다. 개발자가 일정도 못 짜냐고 되물을 수 있다. 대학 과제든, 학원이든, 교육 프로그램이든, 그게 뭐가 되었든 개발자라서 자기는 해봤다고 말이다. 

그럼 나도 되묻고 싶다. "그런데도 불구하고 일정을 수립해서 오라고 하면 개발자들이 다 그렇게 하는 거냐"라고 말이다. 

입사한 이례, 일정을 담당한 사람이 일정을 수립해서 가져오는 자료를 보면, 대외 사업을 경험한 적이 없는 사람 + 개발만 해본 사람들은 공통적으로 말도 안 되는 일정을 짜온다.

그래서 오늘은 일정 수립할 때 고려해야 하는 주의사항을 적어보고자 한다. 참고해서 다음엔 꼭. 정확하지 않은 일정이라도 말이 되는 일정을 짜오기를 바란다. 

1. 수행 단계별로 하는 일은 정해져 있다.

통상적으로 SI 프로젝트는 [분석] > [설계] > [개발] > [테스트] > [이행] > [오픈 및 안정화]라는 단계로 진행된다. 그리고 그 단계별로 하는 일은 정해져 있다. 그러니 제발 간곡히 부탁하건대 설계 단계에 개발을 하고 있다거나, 개발 기간에 설계를 하고 있는 둥 단계가 걸쳐져 있는 일정은 만들지 말아 줬으면 좋겠다. 

'설계가 안 끝날 건데 개발을 미룰 순 없는걸요?'라고 묻는 사람이 있을 수 있다.

'설계가 시작되고 되는 대로 개발을 시작하면 걸쳐져 있을 수도 있는 거 아닌가요?'라고 물을 수도 있다.

물론 다 맞는 말이다. 실제로 그렇게 프로젝트를 하는 경우도 발생한다. 그리고 일정 중에 설계 단계에 개발을 넣는 경우도 있긴 하다. 다만, 그런 경우에는 '선행 개발'이라는 명칭을 사용해서 '개발 단계가 아니지만 먼저 시작하는 거다'라는 의미가 충분히 내포된 타스크를 정한다. 그리고 이런 걸 일정에 넣는 경우는 '먼저 개발하는 걸 고객에게 알려주는 것이 우리의 강점이 될 수 있을 때'라고 모두가 생각했기 때문이다. 통상적으로는 설계 단계에 이미 개발 환경을 구성해서 개발을 시작해 버린다. 그걸 일정에 넣지 않을 뿐이다.

그러니 다시 말하면, 각 단계별로 하는 일은 정해져 있고, 그 단계별로 하는 일에 대한 세부 타스크를 나누고, 그 기간을 정리하는 것이 '일정 수립'이다. 그러니 그걸 마음대로 바꿔서 꼬아놓지 않기를 바란다.

2. 되도록 단계를 겹쳐놓지 말자.

어떤 경우는 개발을 쭉 하다가 개발 단계가 종료되지 않았는데 테스트 시작하는 일정을 수립하는 경우가 있다. 틀린 일정은 아니다. 불가피한 상황이 있기 때문에 그런 일정을 수립하는 것이니까. 그런 경우는 대표적으로 1차 오픈, 2차 오픈 등의 단계별 오픈이 있는 경우에 발생한다. 1차 오픈 대상은 개발이 끝나고 테스트 단계로 넘어가고, 2차 오픈 대상은 계속 개발 단계에 머무는 것이다. 이런 단계를 가져가는 경우는 프로젝트 기간이 너무 길거나, 프로젝트가 연말에 걸쳐져 있어서 중간에 성과를 보여주고 싶은 광팔이 고객이 있을 때다. 꼭 광파는 게 아니어도 차세대 같은 프로젝트는 2년도 걸리는데 단계별 오픈이 없으면 2년 동안 결과를 누구도 쓰지 못하는 상황이 발생하고, 그러면 시장에서 경쟁력이 없어진다고 생각할 수가 있다. 그런 경우는 '합리적 기준'으로 업무를 나눠서 단계별 오픈을 하기도 한다.

그래도 되도록이면 이런 단계를 안 만드는 것을 권장한다. 이건 고객사가 아닌 수행사로서의 입장이다. 왜냐.? 그건 SI 프로젝트가 단계별로 검수를 거치기 때문이다. 1차 오픈, 2차 오픈이 있다는 건 개발 단계가 2번 종료한다는 것이고 테스트 단계로 넘어가기 위해 2번의 검수를 거쳐야 한다는 뜻이다. 어차피 하는 건데 1번을 하든 2번을 하든 뭔 차이가 있냐고 물을 수 있지만... 이 질문은.. 굳이 비유를 하자면 500m 달리기 두 번이나 1000m 달리기나 같은 거라고 말하는 걸 수 있다. 하지만 정확히는 허들이 10개 있는 500m 달리기를 2번 할 것이냐, 허들이 10개 있는 1000m 달리기를 1번 할 거냐의 문제다. 허들 20개는 확실히 허들 10개보다 힘들다. 500m 한 번 하고 쉬고 다시 500m을 뛴다고 착각할 수 있지만, 천만의 말씀이다. 그냥 계속 달리는 거다. 그리고 추가로 강조하자면, 1차 오픈을 하면 2차 개발하는 동안 '운영'해야 하는 시스템이 존재하게 된다는 뜻이기도 하다. 개발자가 2명이었다가 1명이 운영자가 되고 남은 1명이 남은 물량을 개발한다 뜻이다.

3. 선행/후행 연관성을 검토해라

일정을 영역 담당자별로 작성하고 취합하는 형식으로 그리면 대체로 나타나는 문제는 선행/후행 과제가 연속적으로 맞지 않는 상황이 발생한다는 것이다. 예를 들면 다른 업무들이 갖다가 써야 하는 '공통 모듈'이라는 게 존재하는데, 공통 모듈은 5개월 차에 끝난다고 일정을 그려서 오고 다른 업무들은 3개월 차에 시작한다는 식으로 그리는 경우다. 성립하지 않는 일정이 오는 경우다. 안타깝게도 현재 기술로는 그 일정이 맞고 틀리고를 기계적으로 확인할 수 있는 방법은 없다. 사람이 논리적으로 추적해서 맞춰보는 수밖에 없다.

이런 일은 사실 거의 모든 프로젝트의 일정 초안에서 발생하는데, 보통 취합을 한 다음에 조율하는 형태로 진행되기 때문이다. 이렇게 일하는 게 문제라는 건 아니다. 그저 중요한 건 '난 내 일정을 줬어'하고 털어버리면 안 된다는 것이다. 자기 업무에 대한 오너십을 갖고 우리 파트에서 필요로 하는 인풋이 정확하게 들어오는지를 확인해야 한다. 내가 다른 파트의 업무 일정을 잘 서포트하는지까지 챙기진 못해도 자기 업무에 문제가 없는지 확인하는 기본적인 태도만 갖춰도 전체 일정에 문제가 없다.

안타깝게도, 그렇게 까지 챙기는 사람은 5명 중 1명밖에 안 되는 게 현실이다. '일정 담당자가 아니라서', '다른 파트 업무를 몰라서' 등 다양한 이유로 챙기지 않는 경우를 많이 본다. 모르면 물어보자. 담당자가 아니면 담당자에게 확인 요청이라도 하자.

말도 안 되는 일정만큼 화나는 건 없다.

4. 개발/운영 환경에 대한 고려가 되어 있어야 한다.

인프라 구축이 선행되어야 하는 프로젝트가 대부분인데 가끔 가다 보면 개발 환경이 없는 일정에 개발을 시작한다고 정리해 오는 경우가 있고, 운영환경이 완료되지 않았는데 그냥 1차 오픈이라는 일정이 들어오는 경우가 있다. 이런 건 보통 업무랑 인프라가 일정을 따로따로 적어와서 발생하는 문제인데, 3번의 문제랑 동일한 상황이니 추가로 설명은 생략하겠다. (협의 좀 하세요...)

3번의 내용 외에 이와 관련해서 추가로 첨언하고 싶은 경우는 가끔 가다가 개발 환경과 운영 환경과의 차이는 '개발해 보는 공간'과 '실제로 런타임으로 쓰게 되는 공간' 정도로 생각하는 개발자들이 있다는 사실이다. 그래서 '개발 환경은 사양이 더 낮고' '운영 환경은 스펙이 더 빵빵하다' 정도만 생각하는 개발자가 태반이다. 하지만 개발/운영의 의미는 SI에서 그 이상을 내포한다. SI의 개발자는 기본적으로 '외주'인력이기 때문에 개발 환경에서의 접속과 사용은 상대적으로 자유로운 반면, 운영환경은 오픈 전까지만 접속이 가능하거나, 애초에 접속이 불가능한 경우가 엄청나게 많다. 그리고 개발환경은 데이터가 다 비식별처리된 가짜 데이터들이라는 점, 운영 데이터는 실데이터라는 점을 감안해야 한다.

가끔 가다가 챗봇을 만들거나, 뭐 모델을 학습한다고 너무나도 쉽게 '개발에서 학습할게요'라고 계획을 써서 내는 일정표를 볼 때가 있는데. 뒷목을 잡게 되는 상황이 많다. 개발로 내려오지 못하는 데이터에 대한 고민도 없이, 개발로 내리기 위해 작업을 해야 하는 시간을 고려하지 않는 경우가 많이 발생한다. 그리고 운영 환경도 언제든지 접속해서 조치할 수 있기 때문에 너무나도 쉽게 '운영 환경에서 빨리 테스트, 오픈!'이라고 외치곤 한다. 금융은 그렇게 호락호락하지 않으니 그런 고민도 일정 수립 시 꼭 필요하다.

* 사실 특정 일정은 그런 고려가 필요 없이 명확한 경우가 있다. '분석', '설계'단계가 그런 경우다. 이 때는 운영환경이라는 것이 없고 (필요도 없기) 때문에 어떤 일을 해도 개발환경에서 이루어진다. 근데 운영환경이라는 공간이 생기면 일정은 두배로 고려해야 한다. 그리고 어떤 작업이 어떤 공간에서 일어나는지 일정에 표시는 안 해도 고객이 질문하면 대답할 수 있어야 한다. 

5. 개발에 필요한 시간 + 몇 개월로 산정하자.

개발자들이 제일 오해하는 게... '들어가면 바로 개발한다'라는 생각과 '개발이 끝나고 오픈하면 바로 나간다'라는 생각이다. 아... 음... 아니에요. 그래서 고객이 '이런 시스템을 만들고 싶은데요, 얼마나 걸리나요?'라고 물어보면 엔지니어 출신은 언제나 앞뒤를 자르고 대답한다. 8개월이라고 해야 하는데 5개월이라고 하는 식이다. 그럼 고객이 '5개월짜리 사업에 대한 일정을 수립해 주세요'라고 요청을 하고, 개발자들은 그 5개월에서 밤샘 일정을 수립하게 된다. 제발 그러지 말아라.

언제나 전체 단계를 생각하고 답변하자. '개발'기간만 묻는 게 아니다. 어떤 프로젝트는 '분석', '설계'의 수준이 높아야 개발이 잘 되기도 한다. 어떤 프로젝트는 아닌가요?라고 물으면... '네, 아닌 프로젝트도 있어요. 솔루션 설치하고 끝인 프로젝트는 분석/설계가 짧아도 된답니다.'

여튼, 그래서 분석/설계에 대한 고려, (1개월이면 분석/설계가 다 되겠지!라고 합해서 생각하지도 말자. 분석 단계와 설계 단계는 엄연히 다르다...)  그리고 오픈 이후 안정화 기간에 대한 고려도 하자. 서비스가 단순하더라도 오픈 시점이 언제냐에 따라 안정화 기간이 달라지기도 한다. 3명이 1개월 있을 수도 있고, 1명이 3개월 있을 수도 있는 거다. (동일한 3MM). 이건 어떤 경우냐 물으시면... 마감업무가 있는 경우다. 분기 마감이 걸려 있는 업무가 있다면 그 마감 처리까지는 다 보고 나오는 게 맞다. 안 그러면 무책임하단 소리를 듣게 된다. (물론 고객이 인수인계하고 가시면 됩니다.라고 하면 안정화는 짧아도 된다. ^^)

이 외에 더 생각이 나면 다음 포스팅에서 써보겠다. 오늘은 일단 여기까지. ^^

모두가 모두에게 합리적인 프로젝트 일정을 수립하는 날을 기대하며...

2024.08.02 00:20