내 실력은 내 일정을 정확히 가늠하는 것에서 시작된다
이 개발자의 사고방식 #4
모든 일에는 일정이 있다. 일정 없는 일은 없다. 설령 있다 해도, 우리는 그런 것을 '일'이라 부르지 않는다.
일정이란 이 일을 언제까지 끝내겠다고 세상과 맺는 약속이다. 약속을 지키면 신뢰가 쌓이고, 그 신뢰가 쌓여야 비로소 타인과 함께 더 멋진 일을 도모할 수 있다. 그런데 이 '약속'의 기한을 정하는 방식에서 개발자들의 사고방식은 극명하게 갈린다.
나는 일정을 공격적으로 잡는 편이다. 내가 판단하기에 이 정도면 할 수 있을 것 같아 던지는 기한이지만, 대개 남들보다 짧다. 물론 지키지 못한 적도 있지만, 대부분은 해냈고 때로는 더 빨리 끝내기도 했다.
일정을 잡는 태도는 성향이나 경험에 기인하지만, 주변 환경의 영향도 크다. "일정이 너무 짧다"는 동료들의 우려 섞인 참견을 듣다 보면, 할 수 있을 것 같다가도 슬그머니 기한을 늘려 잡게 된다. 그것이 습관화되면 결국 '늘려 잡는 사람'이 된다.
일정의 기준도 제각각이다. 누군가는 코드 작성을 마치는 순간을, 누군가는 QA와 패치 준비 완료를, 더 나아간 사람은 업데이트 후 모니터링 결과까지를 일정으로 본다. 이처럼 각자의 능력, 성향, 기준이 다르기에 일정을 짠다는 건 생각보다 복잡한 고차방정식이다.
그 틈바구니에서 공격적인 개발자는 외로워진다. 시간을 축내고 싶지 않고, 더 아껴서 멀리 나아가고 싶은데 그 실력을 발휘할 공간이 없다. 하지만 개인의 속도가 팀의 합의를 앞지를 때, 일정이란 이름의 '현실'과 충돌하기 시작한다. 일정이란 개인의 역량뿐만 아니라 모두의 사정을 납득시켜야 하는 합리적인 기한이기 때문이다.
문제는 아무리 정교하게 합의를 마쳐도 일정은 늘 어그러진다는 점이다. 항상 누군가는 아프고, 가족이나 반려견/묘에게 사고가 생기고, 집수리를 하고, 가전제품이 오는 등 우리가 통제할 수 없는 변수들은 언제나 존재한다. 결국 공격적인 개발자는 이 '외로운 갈증'과 '예측 불가능한 현실' 사이에서 줄타기를 해야 하는 숙명을 지닌다.
일정 논의가 시작되면 다들 살얼음판을 걷는 마음으로 입을 닫는다. 널널하면 널널한 대로, 타이트하면 타이트한 대로 상처받기 싫어서 숨는다. 하지만 누군가는 입을 떼야한다. 리더든 신입이든 상관없다. 그리고 그 첫 번째 제시는 가급적 방어적이지 않아야 한다. 공격적인 기준이 먼저 나와야 비로소 일이 '진행'되기 때문이다.
"이 일만 할 수 있게 해 주면 가능하죠. 하지만 현실은 안 그렇잖아요?"
맞는 말이다. 현실은 우리를 가만두지 않고, 온전히 몰입할 환경을 주지도 않는다. 하지만 그럼에도 불구하고 해내는 것이 능력이고 실력이다. 실력의 시작은 내 일정을 정확하게 가늠하는 것이다. 스스로를 잘 알아야 한다. 계산이 틀렸다면 다음번에 조절해 나가며 나만의 '데이터'를 쌓아야 한다.
성향이 어떻든, 우선은 '개발자 스스로 개발을 완료하는 시점'을 1차 기준으로 삼고 모두가 이를 공유해야 한다. 이 기준이 흔들리면 안 된다. 그 뒤에 개발 테스트와 QA 시간을 붙이고, 갑작스러운 변수를 위해 20% 정도의 여유를 더해주는 것이 합리적이다.
사람마다 능력이 다른데 모두를 한 바구니에 담아 일정을 잡는 건 불합리하다. 누군가는 반드시 놀게 되어 있다. 리더는 그 남는 시간에 무엇을 할지도 미리 정해둬야 한다. 그래야 상대적으로 작업이 늦어지는 동료가 덜 외로울 수 있다.
일정을 방어적으로만 잡는 조직이 과연 건강할까? 정말 멤버들은 마음이 편할까? 경영진의 속은 이미 터졌다.
당신은 지금 스스로를 제대로 알고 있는가? 당신의 일정은 당신의 실력을 증명하고 있는가?