on
열심히 보다는, 영리하게!
비즈니스 목표를 달성하기 위해서 우리는 어떤 설계 전략을 가져야 할까 고민을 했다. 회사의 사업 전략과 설계 방향이 동떨어져서 회사나 직원이나 모두 피곤해지는 경우를 보았다. 사업 전략을 고려하니 열심히보다는, 영리하게, 해야 할 일을 해야겠더라.
팀원들과 설계 논의를 할 때 자주 주고받았던 이야기를 세 가지로 압축해서 설계 원칙을 만들었다. 적어놓고 보니 나 자신에게 하는 이야기 같다 🤔
. . .
1. 가장 단순하게 문제를 해결합니다.
개발자의 업이란 한정된 자원을 최대한의 결과로 만드는 일입니다. 모든 조건이 완벽하게 갖춰진 순간이나 여유로운 날은 오지 않습니다. 화려하고 멋진, 하지만 쓸모없는 것을 만드는 데에 시간을 낭비하지 않아야 합니다.
가장 쉽고 빠른 방법을 찾아서 적용합니다. 그리고 필요할 때 고칩니다. 단, 대충 하지 않습니다. 경험하고 학습하며 균형을 찾습니다.
2. 확신할 수 없는 일은 고려하지 않습니다.
“만약…“을 가정하면 끝이 없습니다. 시간은 가장 소중한 자원입니다. 기회비용도 고려를 해야 합니다.
해야 할 일에 집중을 하기 위해서, 하지 않아도 될 일은 과감하게 미루세요. 눈앞에 보이는 문제에 집중을 합니다. 더 이상 미룰 수 없는 날에 대비해 퇴로는 확보해야 합니다. 테스트 자동화 같은 걸로 말이죠.
3. 말하지 말고, 보여주세요.
설계 이론은 눈에 보이지 않는 이야기를 늘어 놓는 경우가 많습니다. 보이지 않으면 이해하기 어렵습니다. 모든 문제를 말끔하게 해결하는 설계는 없습니다. 문제가 놓인 맥락을 살펴야 합니다.
설계를 논의할 때는 1)눈앞에 보이는 우리의 문제와 2)실제로 일어날 상황을 이야기하세요.
눈에 보이는 코드를 준비합니다. 프로토타입을 만들어서 보여주는 것도 좋습니다. 설계를 변경해야 할 때 어떤 작용이 발생하는지 보여주세요.
그래야 빠르게 의사결정을 할 수 있습니다.