개발 일정 관리에 대한 단상

스타트업쪽으로 넘어오고 나서 종종 개발팀을 리딩해야 하는 경우가 있다. 리더로서 일하면 개발자가 아닌 외부 팀원들과 일정에 대해서 소통해야 할 일이 많다. 그 중 가장 어려운 질문은 이것이다.

“언제까지 개발 할 수 있나요?”

왜 이 질문은 그토록 어려운가

이 질문은 개발자의 숙명과도 같다. 주니어 개발자는 매니저에게, 개발팀장은 타 팀 혹은 대표에게 언제나 이 질문을 받는다. 그들 입장에서는 당연히 물어봐야 하는 질문이고, 꼭 필요한 질문이다. 하지만 이 질문에 대답하는 것은 질문자가 생각하는 것보다 훨씬 어려운 일이다.

어려운 이유는 그것이 미래를 예측해야 하는 영역이기 때문이다. 미래는 언제나 ‘불확실성’을 동반한다. 공학을 다루는 엔지니어 입장에서 불확실하다는 것은 모른다 혹은 어렵다보다 훨씬 두려운 말이다. 그리고 그 불확실성을 떠안고 기간에 대한 약속을 하는 것은, 개발자 입장에서 프로젝트의 완성을 책임지는 아주 무거운 일이다.

기획 → 디자인 → 개발로 이어지는 일반적인 SW 개발 프로세스에서 개발은 가장 마지막 단에 위치한다. 개발 완수가 곧 프로젝트 완수와 직결된다는 의미다. 대부분의 SW 프로젝트가 최초 계획한 일정을 맞추지 못한다. Agile 같은 다양한 방법론이 도입됨에도 최초 Deadline을 준수하는 경우는 50%에도 미치지 못하는 것 같다.

경험적으로 성공확률이 50% 이하라는 것을 알면서도, 그 불확실성을 떠안은 채 약속을 해야 한다. 어찌 보면 어려운 걸 넘어서 두려운 일이다.

일정이 무너지는 진짜 이유

사람들이 많은 고민 끝에 만든 일정임에도 지켜지기 힘든 가장 큰 이유는 부정확한 최초 요구사항과 변수들 때문이다.

서비스를 개발하는 것은 매우 복잡한 일이다. 기능을 하나 추가하는 것은 단순히 +1의 덧셈이 아니며, 복잡도가 올라갈수록 그 난이도는 지수함수처럼 급격히 증가한다. 요구사항을 최초로 전달하는 시점에 기획이 충분히 구체적이지 않을 가능성이 매우 높기 때문이다. 기획자가 무능하거나 게을러서가 아니다. 그 입장에서는 얼마나 구체적이어야 개발자에게 충분한지 판단할 수 없다. 이는 필연적인 일이다.

기획자의 “회원가입 되게 해주세요” 라는 요청은 누군가에겐 명확해 보일 수 있다. 하지만 개발자 입장에서는 가입 시 인증이 필요한지, 필요하다면 SMS나 이메일 중 어떤 걸로 해야 하는지, 자동 로그인은 되어야 하는지, 된다면 얼마 동안 유지가 되어야 하는지 — 이 같은 모든 디테일이 고려되어야 한다. 최초 기획에 명시되어 있지 않은 내용은 대부분 “나머지는 상식적인 수준에서 알아서 해주세요”를 내포하고 있는 경우가 많아서 문제가 생긴다.

이 디테일을 쫓아가다 보면 최초에 1주일이면 될 것이라고 생각했던 일이 2개월이 걸리는 일이 될 수도 있다. 심지어 그 디테일을 확인하는 일조차 공수가 든다. 그리고 디테일을 다 알아냈다고 해도 요구사항은 충분히 변할 수 있다. 기획자는 개발이 시작된 이후에도 더 좋은 서비스를 위해 계속 고민하고, 미처 생각하지 못한 것이 발견되었을 때 요구사항을 추가할 수 있는지 넌지시 물어보곤 한다.

기획자가 좋은 서비스를 만들기 위해 개선을 고민하는 것은 아주 바람직한 일이다. 하지만 문제는, 기획자 입장에서 단순히 페이지를 덧대는 +N의 작업이라고 생각한 요청이 개발 입장에서는 N², N³으로 기하급수적으로 올라가는 변수를 고려해야 하는 상황이 많다는 것이다.

기획자의 선한 의도, 그리고 그 선한 의도를 반영하려는 개발자의 선한 마음이 합쳐져 결국 대부분의 최초 일정은 무너진다.

효율적인 일과 효과적인 일

매니징을 하는 입장에서 내가 가장 크게 신경쓰는 부분은 효과적으로 일하는 환경 을 구축하는 일이다. 당장 급해 보이는 문제를 빠르게 해결하지 않고 묻어두는 초강수를 선택하더라도, 결국 가장 큰 효과를 얻을 수 있는 방법을 선택하는 것이 궁극적으로 더 일을 빠르게 끝낼 수 있는 방법임을 팀원들에게 납득시켜야 한다.

실무자들은 주어진 일을 효율적으로 잘 해내면 된다. 하지만 리더는 효율적인 일이 아니라 ‘가장 효과적인 일’ 을 계획하고 실행해야 한다. 효율적인 일과 효과적인 일은 비슷해 보이지만 다르다.

수학을 잘하고 싶다는 목적을 위해 하루에 수학 문제를 10개씩 푸는 숙제를 만들었다고 해보자. 이 문제를 빠르게 잘 풀어내는 것은 효율적인 일이다. 하지만 비슷한 문제를 반복해서 푸는 것이 수학을 잘하는 데 꼭 효과적인 일이라고 할 수는 없다. 이미 알고 있는 공식을 스스로 처음부터 증명해 보는 일이 더 효과적일 수 있다.

가장 효과적인 일은 대부분 “중요하지만 급하지 않은 일” 이다.

팀은 언제나 바쁘다. 급하지 않은 일은 언제나 우선순위에서 밀려난다. “나중에 시간 될 때 처리하죠”라고 구두로 나눴던 이야기가 마법처럼 혼자 서랍에서 꺼내져서 처리되는 적은 거의 본 적이 없다. 그래서 아무도 신경쓰지 않는 “중요하지만 급하지 않은 일”은 리더가 직접 꺼내어 모두가 볼 수 있도록 테이블 한가운데 올려놓아야만 한다.

개발에서 중요하지만 급하지 않은 일의 예를 들면 이렇다.

문서 작성
테스트 코드
최적화
에러 처리
코드 리팩토링

잘 운영되고 있는 서비스라면 이 일들을 처리하지 않아도 당장 아무 문제가 생기지 않는다. 그래서 리더가 직접 끌어내오지 않으면 팀원들은 시간이 생겼을 때 신규 기능 아이디에이션에 몰두할 것이다. 하지만 지금 당장 아무 문제가 생기지 않는다 해도, 반드시 대가를 치러야 하는 순간은 찾아온다. 그 대가는 문제를 외면한 기간이 길면 길수록 눈덩이처럼 불어 감당하지 못할 수준으로 한 순간에 덮쳐올 것이다.

개발은 창작이 아니라 운영이다

보통 비전공자가 개발을 처음 배우면 재미있어 하는 경우가 많다. 외계어 같던 코드가 조금씩 이해되기 시작하고, 조금만 더 배우면 키보드 타이핑 몇 번으로 그럴듯한 웹페이지도 만들어낼 수 있다. 아무것도 없는 맨땅에 무언가를 만들어낸다는 건 재미있는 일이다.

하지만 개발자는 실무를 할 때 대부분의 시간을 코드를 작성하지 않고 모니터를 쳐다보면서 보낸다. 이는 대부분 서비스 운영에 관한 일이며, “중요하지만 급하지 않은 일”의 속성인 경우가 많다. 이 일은 무언가를 창작하는 것보다 훨씬 어렵지만 지루하고 고통스러우며, 재미없는 경우가 많다.

아무것도 없는 허허벌판에 새로운 건물을 올리는 것과, 24시간 운영되는 쇼핑몰 한가운데에서 사람들이 다치지 않게 보수공사를 하는 것을 비교해 보자. 전자가 훨씬 티가 많이 나고 뿌듯함을 느끼기 쉽다. 후자는 고려할 것도 많고 티도 나지 않는다. 하지만 개발자는 필연적으로 후자와 비슷한 일을 더 많이 해야만 한다.

네이버나 카카오 같은 대기업에서 몇 천 명의 개발자가 일하고 있음에도, 우리가 그 서비스를 쓰면서 인지할 만한 신기한 기능이 새롭게 출시되는 걸 자주 보지 못하는 것도 그 이유다. 대부분은 유저가 인지하지 못하는 뒷편에서 운영에 관여하고 있기 때문이다.

주니어 위주의 소규모 팀이라면 대부분이 처음 개발자가 되고 싶다고 마음먹게 만들었던 “무언가를 창작하는 일의 재미”를 놓치지 않고 싶어한다. 그렇기에 이 중요한 일들은 매니저가 신경쓰지 않으면 수면 위로 올라오지 않을 것이다.

SW 개발은 정원 가꾸기다

SW 개발은 종종 Gardening(정원 가꾸기)에 비유된다. Git 같은 버전관리 툴에서 Branch(가지)라는 용어를 쓰기도 하고, SourceTree처럼 대놓고 코드를 나무라고 표현하기도 한다. Root(뿌리)라는 말도 자주 등장한다.

아무런 관리도 하지 않는 소스코드가 아무 문제 없이 돌아가는 일은 없다. 이는 정원사가 매일 관리하지 않는 잔디밭이 곧 잡초가 가득한 밀림이 되어버리는 것처럼 자연스럽고 당연한 일이다.

팀을 매니징하다 보면 남들이 신경쓰지 않는 잡초를 묵묵히 뽑아야 할 일도 있고, 때로는 날씨가 덥더라도 “오늘은 잡초 뽑는 날”이라며 팀원들을 독려해야 하는 경우도 있다. 하기 싫더라도 누군가는 해야 하는 일이다.