복잡성을 없애는 은탄환은 없다: 그래서 설계에는 ‘이유’가 필요하다

오늘 주니어 개발자 분에게 들려드린 이야기를 정리해 보고자 합니다.

“복잡성을 해결할 은탄환 같은 건 없다.”

기술 스택을 바꾸거나, 새로운 아키텍처를 도입하거나, 특정 패턴을 적용한다고 해서 복잡성이 갑자기 사라지지는 않습니다.
대신 우리가 할 수 있는 건 한 가지입니다.

시간이 지날수록 늘어나는 복잡성을 ‘관리 가능한 형태’로 유지하도록 설계하는 것.

그리고 그 설계가 팀 안에서 오래 유지되려면, 코드 자체만큼 중요한 게 있어요.

**“왜 이렇게 설계했는지 설명할 수 있어야 한다”**는 점입니다.

깊은 관계의 도메인에서 자주 나오는 선택: “메모가 상위 관계를 전부 가진다”

오늘 주니어 개발자분과 이야기했던 사례는, 파트너 메모가 ‘예약’에 붙는 구조였습니다.
그런데 예약이 하나로 고정된 게 아니라, 비즈니스 흐름상 메모가 아래 중 어느 예약이든 연결될 수 있었어요.

이런 상황에서는 구현하다가 이런 생각이 자연스럽게 나오곤 합니다.

“메모가 예약에 붙는 거라면, 메모가 연결 키를 다 가지고 있으면 조회가 편하지 않을까?”

즉, 메모가 “예약 연결”을 하나로 추상화하기보다, 예약 유형별로 연결 필드를 따로 두는 방식을 택하는 거죠.
이 선택은 분명 실용적인 편의가 있습니다. 다만 동시에 부작용도 같이 따라옵니다.

그래서 코드 리뷰 요청을 한다면, 단순히 “편해서요”가 아니라
**‘왜 이 방식이 지금 도메인에서 합리적인가’**를 설명할 수 있어야 합니다.

여기서 중요한 포인트는 이거예요.

설계는 언제나 선택이고, 선택에는 반드시 비용이 따르니까요.
리뷰에서 설득력 있는 설명은 보통 아래처럼 “얻는 것”과 “감수하는 것”을 같이 놓습니다.

이 트레이드오프가 정리되지 않으면, 리뷰어 입장에서는 그 설계를 “이유 없는 편의”로 보게 됩니다.
반대로 트레이드오프가 정리되어 있으면, 리뷰는 “맞냐/틀리냐”가 아니라 “위험을 어떻게 관리하냐”로 바뀝니다.

리뷰 요청에 아래 4가지만 적어도 퀄리티가 확 올라갑니다.

복잡성은 늘어납니다.
좋은 설계는 복잡성을 제거하는 게 아니라, 관리 가능한 형태로 정리하고 팀이 납득할 수 있는 이유를 남기는 것입니다.

그래서 누군가가
“메모가 상위 관계를 전부 들고 있게 했어요”라고 말했을 때, 질문은 “그게 맞아요?”가 아니라 이렇게 바뀌어야 합니다.

“그 선택으로 얻는 이점과, 감수하는 비용을 어떻게 관리하실 건가요?”