수업 및 프로젝트 멘토링을 하다 보면, 프로젝트 구조나 클래스 설계에 굉장히 많은 고민을 하는 수강생들을 자주 만나게 됩니다.
그럴 때마다 저는 오히려 설계에 너무 많은 시간을 쓰지 않는 것이 좋다는 이야기를 하는 경우가 많습니다.
개인적으로도 설계와 구조 자체보다, 일단 잘 동작하는 코드를 만드는 데 집중하는 것이 더 중요하지 않을까라고 생각합니다.
아직 오지 않은 미래를 너무 많이 걱정하는 경우
설계를 잘해야 하지 않을까 고민하는 분들 대부분은, 나중에 프로젝트 규모가 커질 상황을 미리 상상하면서 설계를 시작합니다.
문제는 그 상황이 아직 오지도 않았다는 점입니다.
실제로는 아직 기능도 거의 없는 상태인데,
확장성과 추상화부터 고민하는 경우를 자주 보게 됩니다.
예를 들면:
- 확장성부터 고민하거나
- 사용하지도 않을 추상화를 미리 추가하거나
- 나중에 필요할 것 같은 구조를 먼저 설계하려고 합니다
물론 미래를 대비하는 태도 자체는 중요합니다.
하지만 실제 프로젝트는:
예상과 완전히 다른 방향으로 흘러가는 경우도 굉장히 많습니다.
결국:
지금 존재하지 않는 문제를 해결하기 위해
현재의 복잡도를 지나치게 높이는 상황이 자주 발생합니다.
“좋다고 알려진 설계”를 그대로 가져오는 문제
그리고 이런 경우 대부분 유명한 설계 기법을 그대로 적용하는 데 집중하게 됩니다.
대표적으로 아래와 같은 구조들입니다.
- 인터페이스 남용
- 과도한 추상화
- 무조건적인 SOLID 적용
- 델리게이트 / 이벤트 시스템 남발
물론 이런 기술 자체가 나쁜 것은 아닙니다.
문제는 프로젝트의 규모나 성격 분석 없이 무조건 적용하려는 태도에 있다고 생각합니다.
관리를 쉽게 하기 위해 설계를 추가했다고 생각했지만,
정작 본인이 추가한 복잡도를 감당하지 못해 프로젝트 구조가 오히려 더 복잡해지는 경우를 자주 봅니다.
몸에 맞지 않는 옷은 결국 불편할 수밖에 없습니다.
좋은 설계는 경험 속에서 자연스럽게 나온다
오히려 비슷한 기능을 여러 번 구현해보는 경험이 쌓이면, 좋은 설계는 자연스럽게 따라오는 경우가 많습니다.
왜냐하면 실제 구현 과정 속에서 무엇이 자주 수정되고, 어떤 구조가 유지보수를 어렵게 만드는지 직접 경험하게 되기 때문입니다.
예를 들면:
- 반복적으로 수정되는 코드 구조
- 지나친 추상화로 인해 복잡해진 흐름
- 수정이 어려워지는 클래스 의존성
같은 문제들을 직접 겪게 됩니다.
결국 설계는 책이나 이론만으로 배우기보다, 구현 과정 속에서 체득되는 부분도 굉장히 크다고 생각합니다.
잘하는 사람들은 의외로 설계에 집착하지 않는다
개인적으로 흥미로운 점은, 설계를 정말 잘하는 분들일수록 설계 자체에 과하게 집착하지 않는 경우가 많다는 점입니다.
오히려 현재 문제를 단순하게 해결하는 데 집중하는 경우를 더 많이 봤습니다.
예를 들면, 언제든 구조를 바꿀 수 있게 만들거나, 필요할 때 리팩토링하거나, 현재 문제를 단순하게 해결하는 데 집중합니다
결국 좋은 설계란 “처음부터 완벽하게 만드는 것”보다는,
변화에 대응할 수 있는 구조를 유지하는 것 에 더 가까운 게 아닐까 생각합니다.
마무리
그래서 저는 초기 프로젝트에서는 설계 자체보다, 직접 구현하고 부딪혀보는 경험이 더 중요하다고 생각합니다.
구현 경험이 충분히 쌓이면, 좋은 설계는 조금씩 자연스럽게 따라오게 되는 것 같습니다.
하고 싶은 말이 많지만 이만..