우리가 무언가를 만들거나 정리하다보면 나름의 기준을 통해 행동하게 된다. 분류 규칙이나 기술 규칙이라든지 모든 것이 이 원칙을 기반으로 이뤄지게 있기 마련이다. 또한 사람들이 개별로 생각이 다르기 때문에 이 규칙이라는 것도 서로 다르게된다. 이러한 규칙의 다름 문제는 혼자서 작업할때는 크게 드러나지 않고 기존의 방식을 그대로 하기때문에 스스로도 뭔가 문제점을 인식하기는 어렵고 사실 문제가 되지도 않는다. 다만 어떤 작업을 완료되고 시간이 어느 정도 흐른뒤 다시 작업내용을 바라봤을 때는 불편함을 느끼기도 한다. 이는 이전의 나의 원칙에서 조금씩 바뀌어가고 있고 시간의 갭만큼의 차이를 느끼기 때문이다.
다른이들과 협업을 해야할때는 규칙의 다름은 약간의 불편을 야기한다. 사람마다 갖고있는 규칙도 다르지만 규칙을 바라보는 시선도 다르기에 종종 문제들이 들어나기도 한다. 어떤 사람은 별것 아니라고 생각하고 지나치는 문제도 사람에 따라서는 매우 중요하기 때문이다.
하지만 원칙은 필요하고 너무 수동적이 되지않기 위해서 자신만의 원칙을 정해두는 것은 필요하다. 따라서 나역시도 관련하여 생각을 정리해보고자 한다. 기술하는 내역들은 많은 곳에서 자신만의 논리로 주장하는 바가 다양한 철학적인 문제들이고 절대적으로 맞고 틀린것이 아닌 다름의 영역이다. 여기에 기술한 내용 또한 나의 주관적인 생각을 기준으로 필요한 근거 자료를 붙인 것임을 감안하기 바란다.
모듈화는 매우 필요하다.
첫번째 재사용성 - 추후에 사용될 가능성이 조금이라도(10%이상?) 있다면 그것은 모듈화 해야한다고 생각한다. 이 부분은 객체지향형 프로그래밍(OOP)이 나타나고 주류를 이뤘던 90년대 2000년대를 통하며 지금까지도 당연히 받아드려지는 원칙으로 생각된다.
두번째 시스템의 단순화 - 시스템의 복잡도를 줄이기 위해서도 모듈화는 필요하다. 단위 모듈을 정확하게 정의하고 이를 원자론적으로(atomically) 독립성을 보장하게 만드는 것이 중요하다. 복잡한 시스템을 한꺼번에 이해하는 것은 매우 어렵다. 하지만 기능별로 모듈화를 사용하고 모듈내부에서도 일관성있게 세부 모듈화를 수행한다면 훨씬더 이해하기 쉽고 유지보수하기에 좋은 시스템을 만들 수 있다. 예를 들어 다음과 같은 시스템이 있다고 하자.
물론, 현실적으로 개발 초기에는 이에 대한 명확한 구분을 하는 것이 불가능하다. 여러가지 정책들과 생각하지 못했던 케이스를 추가하면서 납기와 개발편의성을 추구하다보면 스파게티화 되어가는 코드들이 대부분이다. 하지만 원칙을 세우고 이를 기반으로 개발해 나가는 것은 매우 중요하고 지속적인 refactoring을 통해 원칙에 위배하는 부분들을 만들어둔 모듈화 기준에 맞게 수정해 가자.
이것은 프로그래밍을 바라보는 나만의 철학(개똥철학?)을 기술한 것으로 스스로 정리를 위해 쓴 글이다. 비슷한 고민을 하는 사람이 있다면 참고가 되길 바란다.(상반된 생각을 갖으며 욕을 할수도 있지만...)