회사에서 성실히 일하다 보면 어느 순간 큰 프로젝트를 맡게 되는 기회가 찾아옵니다
처음으로 큰 프로젝트를 맡게 되면 기대와 동시에 부담도 클 수밖에 없습니다
저 역시 그런 경험을 했기에 그 과정에서 깨달은 몇 가지 주의할 점을 공유하고자 합니다
첫 번째로 해야할 일은 프로젝트를 글로 잘 정리하는 것입니다
무엇을 만드는건지 상세하게 잘 정리해야 어떻게 만들어야하는지 확실하게 파악할 수 있습니다
그냥 글로 적는것도 괜찮고 UML을 그리는것도 좋습니다
UML을 이용하여 객체간 관계를 잘 정리할 수 있다면 아무리 큰 프로젝트도 어렵지않게 작업할 수 있습니다
하지만 무엇보다 중요한 것은 UML을 그리느냐 그리지 않느냐가 아닙니다
프로젝트의 주요 기능을 명확하게 정리할 수 있다면 어떤 수단을 사용해도 괜찮습니다
두 번째로 중요한 것은, 큰 프로젝트를 여러 작은 단위로 쪼개는 것입니다
프로젝트가 커질수록 관리의 복잡도는 기하급수적으로 증가합니다
이때 중요한 점은 가능한 독립적인 모듈로 분리하는 것입니다
독립된 모듈로 묶어서 추상화를 하게 되면 복잡도가 대폭 줄어듭니다
저는 개인적으로 API 형태로 분리하는 것을 추천합니다
API로 만들면 해당 모듈을 다른 프로젝트에서 가져다 쓰기 좋습니다
아무리 객체지향적으로 잘 만든 객체라도 재사용하는건 쉽지 않습니다
내가 만든 객체를 내 다른 프로젝트 혹은 다른 사람이 사용하는건 대단히 어렵습니다
하지만 API는 규약만 알면 누구나 가져가서 쓸 수 있기 때문에 재사용이 용이합니다
API로 만들기로 했다면 API 프로젝트 안에서는 강박적으로 객체지향을 고집하지 않아도 됩니다
필요한 기능을 만들다 보면 각 객체간의 추상성을 해치는 작업을 어쩔 수 없이 하게 됩니다
추가할 기능이 A객체에 만들어야하는지 B객체에 만들어야하는지 애매한 경우가 있습니다
A,B 어떤 객체안에 만들어도 각 객체간의 역할을 넘어서기도 하고
그렇다고 C객체를 따로 만들자니 시간도 오래걸리고 객체가 늘어날 수록 프로젝트 복잡도가 증가하여 관리 비용이 상승합니다
이럴때는 걍 A,B 객체 중 아무 객체에서 필요한 기능을 구현합니다
어차피 많이 쓰는 API라면 나중에 리뉴얼을 하게 됩니다
나중에 시간이 가서 API 리뉴얼이 필요하면 그때 잘 설계해서 수정하는게 효율적입니다
말단 설계에 까지 객체지향을 고집하는건 어렵다고 생각합니다
모든 기능을 너무 자잘하게 API로 나누는 것은 비효율적일 수 있습니다
API로 분리할 때는 프로젝트의 스펙을 글로 정리해보고 한 문단으로 끊어지는 단위가 적당한 기준이 될 수 있습니다
중요한 것은 적절한 분리와 관리를 통해 프로젝트가 지나치게 복잡해지는 것을 막는 것입니다
결국 프로그램은 데이터의 흐름을 다루는 작업이고 이 흐름을 언어로 명확히 표현할 수 없다면 프로젝트 진행에 문제가 생길 수밖에 없습니다
따라서 프로젝트의 본질을 이해하고 이를 명확히 정리하는 능력이 중요합니다
큰 프로젝트일수록 전체적인 흐름과 구조를 이해하고 이를 명료하게 표현할 수 있는 것이 성공의 열쇠입니다
처음 큰 프로젝트를 맡게 되면 부담이 클 수 있지만 이러한 원칙을 지키며 차근차근 나아간다면 성공적으로 완수할 수 있을 것입니다
