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