Architecture vs Deadline
코드 구성을 범용적이면서도 유연하게 구성하는 것은 장기적인 개발 관점에서 필수입니다. 다만, 납기일에 밀려 급하게 일을 처리하다 코드 구조를 이상적으로 구현하지 못한 경우가 있을 수 있습니다.
로버트 C. 마틴가 저술한 Clean Architecture라는 책에서는 이 경우에 대해, architecture를 사수하기 위해 개발팀 전체가 다른 팀과 투쟁해야 한다고 말하고 있습니다.
아이젠하워 매트릭스는 일의 중요성과 긴급성에 따라 사분면으로 나누어져 있습니다. 저자는 architecture는 중요하면서도 긴급한 일이고, 납기일은 긴급하지만 architecture에 비해 중요하지 않은 일이라고 말합니다. 이후의 내용은 SW architecture와 관련된 일이라 잘 이해하지는 못했지만, 위의 기본적인 사상에 대해서는 깊이 공감하고 있습니다.
devops의 업무 또한 개발자들의 개발 환경을 편리하게 해주는 것인만큼 이 사상과 깊은 연관이 있다고 생각합니다. cloud 설계, terraform 코드 설계, pipeline의 설계 등 devops의 대부분의 업무에 대해 완수해야 할 날짜보다는 얼마나 완성도 있게 일을 끝마쳤느냐가 더 중요하다고 생각합니다. 완벽하게 일을 수행할 수록 개발자들은 좀 더 수월하게 개발할 뿐만 아니라 스스로의 업무 생산성도 비교할 수 없을만큼 늘어난다고 생각하기 때문입니다.
효율적인 devops 업무를 위해 다음과 같은 마음가짐을 가져야한다고 생각합니다.
- 효율적인 코드 구조, cloud 설계를 위해 충분히 고민하는 시간을 가져야 합니다.
- 설계하는 중간중간 확인, 테스트하는 과정을 거쳐야 합니다.
- refactoring은 날을 잡아서 하는 게 아니라 보이는 그때 그때 수행해야 합니다. 잘 돌아가는 코드를 건드리는 것은 용기가 필요하지만, 일단 건드리고 고치게 되면 전보다 훨씬 늘어난 생산성을 경험할 수 있을 것입니다.
- 재택이 가능하다면 적극적으로 활용해야 합니다. 이상적으로 재택을 활용할 경우, 출퇴근 시간을 절약하고, 자유로운 업무 환경으로 일의 능률이 올라갑니다.
- 일이 너무 많다고 느낀다면, 자신의 업무 처리를 효율적으로 하고 있는지 반성해봐야 합니다.