어떤 설계 결정을 해놓고, 시간이 흘러서 문제를 너무 과하게 해결했다는 생각에 후회할 때가 있다. 대게 이런 설계는 “그런 일이 생길 거야”라는 가정으로 만들어지더라. 가정한 일이 일어나지 않았거나

어떤 설계 결정을 해놓고, 시간이 흘러서 문제를 너무 과하게 해결했다는 생각에 후회할 때가 있다. 대게 이런 설계는 “그런 일이 생길 거야”라는 가정으로 만들어지더라. 가정한 일이 일어나지 않았거나, 일어났으나 기대와 다르거나. 일도 비슷한데, 일의 근거가 "나중에 이런 상황이 생길 수 있어요."라면 경계한다. "이런 일"은 발생할 수도 있고, 영원히 발생하지 않을 수도 있다는 뜻이다. "이런 일"이 발생하지 않는다면, 기껏 한 일이 헛수고가 되어버린다. (대부분의 일이 그렇겠지만)우리의 일은 한정된 자원을 다룬다. 시간은 얼마나 소중한가. 학습이 목적이 아니라면, 쓸 데 없는 고퀄을 만들지 않으려고 노력한다. (사실은 고퀄을 만들 능력이 안 되어서.. 😢)가지고 있는 예산 안에서 할 수 있는 최대치를 목표로 잡는다. 코드는 비싼 자원이다. 코드를 적게 작성할수록 좋고, 아예 코드 없이 문제를 해결할 수 있다면 더 좋다. 어떤 문제는 코드 한 줄 없이, 말 몇 마디로 해결할 수도 있더라. 우선순위를 정리하다 보면 중요하다고 생각했던 일 중에 꽤 많은 일이 지금 하지 않아도 될 일로 판명 나서 버려지기도 한다. 잘 해야 하는 일을 잘 하려고 노력하는 만큼이나, 안 해도 되는 일을 적당히 묻어둘 줄도 알아야 한다. 일어날지 확신할 수 없는, 하지만 나중에라도 쉽게 해결할 수 있는 문제를 굳이 지금 해결하려고 애쓰지 말자. 미래를 알 수 없다면 충분한 정보를 얻을 때까지 해결을 미루는 것도 괜찮다. 물론 뒤로 미룰수록 해결 비용이 크게 증가하는 문제는 좀 더 빠른 시점에 고민해야 한다. 해야 할 일과 미뤄야 할 일의 경계를 무 자르듯 자를 수는 없다. 하지만 일을 하기 전에 이런 질문을 던지는 연습을 하는 것만으로도 낭비를 조금은 줄일 수 있지 않을까. - 이 일이 공동의 목표 달성에 얼마나 기여할까? - 지금 이 일을 반드시 해야할까? - 이 일을 하면 무엇을 얻고 무엇을 잃게 될까?