개발 조직 안에서 일정이 목표가 되는 경우를 너무 자주 본다. 일정은 언제부터인가 성과를 판단하는 기준이 되었고, 지켰는지 여부가 잘하고 있는지의 척도처럼 사용된다. 프로젝트가 끝나면 무엇을 만들었는지보다 일정이 맞았는지가 먼저 이야기된다. 일정이 어긋나면 원인을 찾고, 맞추면 안도하지만 그 일정이 어떤 결과로 이어졌는지는 상대적으로 덜 중요해진다.
하지만 일정은 본질적으로 계획이다. 특히 프로젝트 초기에 수립된 일정은 현실을 정확히 반영하지 못하는 경우가 많다. 기술적 불확실성, 요구 사항 변경, 예상치 못한 외부 변수는 언제든 계획을 흔들 수 있다. 그럼에도 우리는 그 계획을 마치 확정된 약속처럼 다루고, 그 약속을 지켰는지를 성과의 기준으로 삼는다.
이런 상황에서 많은 조직은 일정을 지키는 것을 성과처럼 착각한다. 기술 부채를 쌓고 품질을 희생하면 일정은 맞출 수 있다. 테스트를 줄이고, 설계를 미루고, 당장의 문제만 덮어두면 숫자상 일정은 지켜진다. 하지만 그렇게 해서 얻은 ‘일정 준수’가 팀의 진짜 성과를 의미하지는 않는다. 오히려 그 선택은 나중에 더 큰 비용으로 돌아온다.
문제는 일정 중심 사고가 조직의 선택을 바꾼다는 점이다. 일정을 목표로 삼는 순간, 팀은 방어적으로 변한다. 왜 이 일을 하는지보다는 어떻게든 맞추는 것이 우선이 되고, 장기적인 품질이나 확장성보다 당장 지연되지 않는 선택이 반복된다. 이렇게 쌓인 결정들은 시간이 지날수록 조직의 발목을 잡는다.
그렇다면 시장과 사용자 앞에서 의미 있는 결과를 만들고자 한다면 개발 조직은 무엇을 목표로 삼아야 할까. 일정이 아니라, 그 일정 끝에 무엇이 달라졌는지를 묻는 방식이 필요하다. 개발이 끝났을 때 사용자에게 어떤 가치가 전달되었는지, 제품이나 서비스가 어떤 상태로 변화했는지를 기준으로 삼아야 한다.
일정은 언제나 계획이다. 반면 목표는 조직이 어디로 향해야 하는지를 알려주는 기준이다. 좋은 목표는 무엇을 했는지가 아니라, 그 결과로 무엇이 달라졌는지를 설명할 수 있어야 한다. 사용자가 어떤 가치를 얻었는지, 제품이 어떤 상태로 변화했는지를 말할 수 있을 때 비로소 목표는 힘을 갖는다.
이런 목표는 의사결정의 순간마다 기준이 된다. 일정이 흔들릴 때 무엇을 줄일 것인지, 기능을 덜어낼 것인지, 품질을 지킬 것인지를 판단해야 할 때 목표는 선택의 기준이 된다. 일정은 바뀔 수 있지만, 목표는 쉽게 바뀌지 않는다.
일정을 목표로 삼는 조직에서는 완료 자체가 성과처럼 취급된다. 하지만 완료되었다는 사실만으로 그 일이 의미 있었는지는 알 수 없다. 일정은 지켜졌지만 아무도 쓰지 않는 기능, 유지보수 비용만 늘어난 구조는 성과라고 부르기 어렵다.
진짜 목표는 시장에서 의미 있는 결과를 만드는 것이다. 일정은 그 목표를 달성하기 위한 수단일 뿐이다. 수단이 목적을 대신하는 순간, 조직은 분명히 바쁘지만 앞으로 나아가지 못한다.