모듈화 관점에서의 오염

요즘 회사에서 일하던 프로젝트가 잘되서(?) 사업의 스케일이 커졌고, 모듈리식 레포지토리에서 작은 도메인 단위의

서브 프로젝트 여러개로 쪼개는 모노레포 리펙토링 작업을 진행하고 있다

 

공통 로직이랑 중복 코드를 추출하면서, 자연스럽게 추출 및 활용이 쉬운 코드와 어려운 코드가 나뉘는 걸 체감하고 있다.

 

처음엔 단순히 코드 복잡도나 의존성 때문이라고 생각했는데, 계속 리팩토링을 하다 보니까 그 차이의 본질이 결국 오염(contamination) 이라는 생각이 들었다. 한 모듈의 상태나 로직이 다른 곳에 얼마나 퍼져 있느냐, 그게 오염의 정도다.

오염이 심할수록 추출이 어렵고, 반대로 모듈 경계가 깔끔하게 지켜진 코드일수록 손쉽게 분리된다.

 

이를 “모듈화 관점에서의 오염(contamination)”은, 한 모듈의 책임/경계가 무너지고 부작용, 상태, 오류, 의존성, 규칙 등이 경계를 넘어 전파되는 현상 이라고 보면 될듯하다.

 

이 “오염”이라는 게 뭔지 구체적으로 말하자면, 한 모듈 내부에서만 머물러야 할 값이나 상태, 부작용이 경계를 넘어 퍼지는 현상을 말한다.

 

예를 들어 null이 대표적인 케이스다. 어떤 함수가 null을 반환하고, 그걸 받은 상위 함수가 별다른 검증 없이 그대로 다음 함수로 넘기면, 결국 그 null은 시스템 전반으로 퍼진다. 나중엔 어디서 깨졌는지도 모르는 상태에서 Cannot read property 'x' of null 같은 에러를 뿜는다.

 

 

function getUser(id: string) {
  const user = db.find(u => u.id === id);
  return user ?? null; // ❌ null 반환
}

function getUserName(id: string) {
  const user = getUser(id);
  return user.name; // ❌ 여기서 null 전파로 터짐
}

 

 

이게 바로 **데이터 오염(data contamination)**이다.
한 곳에서의 “불확실한 상태(null)”가 검증 없이 전달되며,
모듈 경계를 오염시키는 전형적인 예시다.

이런 식의 오염은 null뿐만 아니라 다양하게 존재한다.

 

• 전역 변수를 직접 수정하는 상태 오염
• 외부 변수에 의존하거나 부작용을 남기는 비순수 함수 오염
• 특정 API 구조나 데이터 포맷에 직접 묶인 의존성 오염
• try-catch 없이 흘러가는 에러 오염
• CSS 클래스가 전역에 영향을 미치는 스타일 오염
• 비즈니스 규칙이 있어야 할 곳이 아닌 곳에 섞여 있는 케이스

 

결국 오염이란 “내부의 영향이 외부로 새는 것”이다.
내부 로직의 부작용, 불확실한 값, 전역 변경이 다른 모듈로 번지면서, 코드 추출과 분리가 어려워지고, 유지보수성도 떨어지는 이유가 된다.

 

그래서 리팩토링을 하다 보면 “이 코드는 왜 이렇게 유지보수, 재사용 하기 힘들까?”의 답이 대부분 여기에 있다 —
경계 밖으로 새어나간 오염이 많을수록, 코드 리펙토링, 재사용이 힘들어진다.

 

결국 유지보수가 쉽고 어려운 건 코드량이나 난이도의 문제가 아니라, 얼마나 경계가 명확하고 불필요한 의존이 없는 구조인지에 달린 것 같다