성급한 추상화의 위험과 인지적 완결 욕구: 결합도 제어와 점진적 리팩터링 설계

들어가는 글: 왜 개발자는 코드가 겹치는 꼴을 참지 못하는가

소프트웨어 개발 현장에서 가장 빈번하게 목격되면서도 가장 치명적인 부채를 낳는 비극 중 하나는, 요구사항의 세 번째 변형이 미처 등장하기도 전에 작성된 장엄한 공통 인터페이스와 거대한 베이스 클래스입니다. 코드베이스를 살피다가 유사한 형태의 데이터 매핑 블록이나 조건 분기문이 단 두 군데에서 발견되었을 뿐인데, 많은 엔지니어들은 마치 시스템에 돌이킬 수 없는 결함이라도 발생한 양 심각한 불안감에 휩싸입니다. 곧이어 BaseAbstractDataNormalizerFactoryService와 같은 장황한 계층을 신설하고, 서로 다른 도메인 맥락을 지닌 두 코드를 하나의 추상 템플릿 메서드 패턴 속으로 강제로 밀어 넣습니다.

그 결과는 처참합니다. 불과 몇 달 지나지 않아 한쪽 도메인에 예외적인 비즈니스 규칙이 추가될 때마다 공통 클래스 내부에는 수많은 불리언 플래그와 if (context.isSpecialTenant()) 같은 누더기 분기문이 증식합니다. 결국 이 공통 모듈은 건드리는 순간 사방에서 부수 효과(Side Effect)가 폭발하는 시한폭탄이 되어버립니다. 샌디 메츠(Sandi Metz)는 자신의 기념비적인 에세이에서 잘못된 추상화는 중복된 코드보다 훨씬 더 큰 비용을 초래한다고 경고했습니다. 중복 코드는 각자의 맥락에서 단순히 읽고 수정하면 그만이지만, 잘못 엮인 추상화는 수많은 호출부의 가정을 추적해야만 겨우 한 줄 고칠 수 있는 결합도의 지옥을 만들기 때문입니다.

그런데 우리는 왜 이 고통스러운 실수를 세대와 기술 스택을 불문하고 반복하는 것일까요? 단순히 객체지향 설계 원칙(DRY, Don't Repeat Yourself)을 맹신하는 주니어 개발자의 미숙함 때문일까요? 인지 심리학과 행동 과학의 렌즈를 통해 엔지니어링 조직을 관찰하면, 이 현상의 기저에는 인간의 본능적인 방어 기제인 '인지적 완결 욕구(Need for Closure)'가 자리 잡고 있음을 발견하게 됩니다. 엔지니어는 모호성과 복잡성이 열려 있는 미결정 상태를 극심한 인지적 위협으로 받아들이며, 이를 단칼에 종결짓고 통제감을 회복하기 위해 '추상화'라는 강력한 무기를 성급하게 휘두릅니다.

본 리포트에서는 인지적 완결 욕구의 2단계 심리적 기전(Seizing과 Freezing)이 어떻게 아키텍처적 판단을 왜곡하는지 실증적으로 추적하고, 개발 조직이 심리적 불안감에 굴복하지 않고 도메인의 진정한 응집도를 관찰할 수 있도록 돕는 실무 가드레일 설계 체계를 공유합니다.

심리학적 기전: 불확실성을 거부하는 인지적 완결 욕구(Need for Closure)

메릴랜드 대학교의 저명한 심리학자 아리 크루글란스키(Arie Kruglanski)가 정립한 인지적 완결 욕구 이론에 따르면 인간은 어떤 질문이나 문제 상황에 직면했을 때 모호함을 종결짓고 확실한 답에 도달하고자 하는 본능적 충동을 지닙니다. 이 완결 욕구는 평상시보다 시간적 압박이 크거나, 요구사항의 변경 가능성이 높아 인지적 과부하가 걸릴 때 극단적으로 증폭되는 특성을 보입니다.

크루글란스키 교수는 인지적 완결 욕구가 작동하는 과정을 크게 두 가지 핵심 국면으로 분류했습니다.

1. 포착 단계(Seizing): 미지의 상황이나 혼란스러운 상태를 마주했을 때, 가장 먼저 눈에 띄는 단서나 직관적인 해결책을 성급하게 붙잡는 충동입니다. 소프트웨어 엔지니어링에서 이는 서로 다른 파일에 존재하는 유사한 코드 구조를 발견하는 즉시 "이것은 중복이다"라고 단정 짓고 공통 인터페이스로 묶으려는 행위로 발현됩니다.
2. 동결 단계(Freezing): 한 번 선택한 해결책이나 가설을 고정 불변의 진리로 규정하고, 이후에 들어오는 반증이나 미묘한 도메인의 차이점을 의도적으로 무시하거나 기존 틀에 억지로 끼워 맞추려는 방어 기제입니다. 이미 생성한 공통 부모 클래스를 지키기 위해 하위 도메인의 이질적인 요구사항을 수많은 플래그 변수로 땜질하는 행태가 대표적인 동결 현상입니다.

개발자는 매일 수천 줄의 코드와 수십 개의 도메인 모델, 예측 불가능한 비즈니스 변경 요구 속에서 극심한 인지적 불확실성과 싸웁니다. "앞으로 이 기능이 어떻게 확장될지 모른다"는 열린 불확실성은 개발자 뇌의 전두엽에 지속적인 스트레스 신호를 전송합니다. 이때 '공통 추상화'를 도입하면, 개발자는 머릿속의 복잡한 세부 사항을 블랙박스 안에 가두고 시스템을 효과적으로 통제하고 있다는 강력한 심리적 안정감을 맛보게 됩니다.

즉, 성급한 추상화의 본질은 기술적인 우아함의 추구가 아니라, 모호한 도메인을 마주한 뇌가 스트레스를 줄이고 인지적 완결을 달성하기 위해 발동하는 일종의 '진통제 복용'인 셈입니다. 하지만 진통제가 원인 질환을 치료하지 못하듯, 심리적 위안을 위해 도입된 불완전한 추상화는 미래의 개발팀에게 막대한 유지보수 비용을 전가합니다.

DRY 원칙의 오독과 '우발적 중복'의 함정

성급한 추상화가 조직 전체로 정당화되는 과정에는 거의 예외 없이 실용주의 프로그래머들이 주창한 'DRY(Don't Repeat Yourself)' 원칙에 대한 위험한 오독이 개입되어 있습니다. 앤디 헌트와 데이브 토마스가 책에서 명시했듯, DRY 원칙의 본령은 시스템 내에서 모든 단일 지식(Knowledge)은 단 하나만의 모호하지 않고 권위 있는 표현을 가져야 한다는 지식의 중복 배제에 있습니다.

하지만 수많은 개발자들은 이를 단순히 화면에 보이는 코드 텍스트의 형태학적 유사성으로 협소하게 격하시킵니다. 소프트웨어 공학에서는 이를 명확히 구분해야 합니다.

• 본질적 중복(Essential Duplication): 동일한 비즈니스 지식과 규칙을 표현하며, 비즈니스 규칙이 변경될 때 우선적으로 함께 변경되어야 하는 코드입니다. 예컨대 부가가치세율 계산 로직이나 금융 거래의 최소 단위 검증 로직은 단일 진실 공급원(Single Source of Truth)으로 철저히 캡슐화되어야 마땅합니다.
• 우발적 중복(Accidental Duplication): 지금 이 순간에는 문법 구조와 변수 이름, 데이터 필드가 우연히 90% 이상 일치해 보이지만, 서로 완전히 다른 도메인 맥락과 수명주기(Lifecycle)를 가진 코드입니다. 예를 들어 '신규 회원 가입 양식 유효성 검사'와 '기존 회원의 결제 정보 업데이트 검사'는 현재 요구하는 필드가 이메일과 전화번호로 같을지라도, 향후 마케팅 정책이나 본인 인증 규제 변경에 따라 완전히 다른 속도로 진화합니다.

우발적 중복을 본질적 중복으로 착각하여 조기에 추상화할 경우, 두 도메인은 원치 않는 결합을 맺게 됩니다. 한 도메인을 위한 기능 수정이 다른 도메인의 서비스 장애를 유발하고, 개발팀은 배포 때마다 심각한 불안감에 시달리게 됩니다. 중복을 허용하는 것보다 잘못된 추상화를 되돌리는 데 평균 상당 부분 이상의 개발 공수가 소모된다는 현장의 통계는 결코 과장이 아닙니다.

결합도 감쇄를 위한 아키텍처 가드레일: Rule of Three

성급한 추상화라는 심리적 충동을 억제하고 건강한 코드베이스를 유지하기 위해서는 개발자의 개인적 인내심에만 의존해서는 안 됩니다. 조직 차원의 기계적인 아키텍처 가드레일과 코드 리뷰 합의가 수립되어야 합니다. 그 핵심이 바로 마틴 파울러(Martin Fowler)가 정립한 '3의 법칙(Rule of Three)'의 엄격한 적용입니다.

본 리포트에서 제안하는 실무 운영 기준으로서 Rule of Three 원칙은 코드가 3회 이상 실제로 중복되기 전까지는 공통 추상화를 명시적으로 금지하는 아키텍처 가드레일 체계입니다. 이 가드레일은 다음과 같은 3단계 점진적 검증 파이프라인으로 구성됩니다.

[Phase 1: 최초 작성] -> [Phase 2: 두 번째 중복 발견] -> [Phase 3: 세 번째 출현 & 경계 검증] -> [추상화 단행]
      |                             |                                      |
  직관적 구현                  의도적 중복 복사                      진정한 도메인 공통점 추출
 (단일 맥락 집중)          (결합도 유발 원천 차단)                   (다형성/컴포지션 적용)

1단계: 첫 번째 작성(First Occurrence)

새로운 요구사항을 구현할 때는 오직 해당 도메인의 비즈니스 목표와 가독성에만 집중합니다. 미래의 확장성이나 공통화 가능성을 의도적으로 고민하지 않고, 가장 직관적이고 단순한 형태로 코드를 완성합니다. 이때의 목표는 도메인 규칙을 명확히 드러내는 것입니다.

2단계: 두 번째 유사 코드 출현(Second Occurrence)

다른 모듈이나 도메인에서 구조적으로 거의 동일한 로직이 필요해졌을 때, 엔지니어링 본능을 거스르고 코드를 '의도적으로 복사'합니다. 이 단계에서 중복을 허용하는 이유는 두 가지 맥락 사이의 미세한 차이점과 변경 주기가 아직 충분히 검증되지 않았기 때문입니다. 두 개의 인스턴스만으로는 이것이 본질적 중복인지 우발적 중복인지 통계적으로 판별할 수 없습니다.

3단계: 세 번째 독립적 출현(Third Occurrence)

서로 다른 세 개 이상의 비즈니스 도메인에서 동일한 패턴의 로직이 반복해서 등장할 때, 비로소 팀은 추상화 테이블을 소집합니다. 세 개의 상이한 사례를 관찰하면 무엇이 진짜 변하지 않는 핵심이고 무엇이 상황에 따라 달라지는 가변 영역인지 비로소 선명하게 드러납니다. 이때 비로소 상속이 아닌 컴포지션(Composition)이나 전략 패턴(Strategy Pattern)을 기반으로 견고한 공통 인터페이스를 추출합니다.

실무 설계 패턴: 상속(Inheritance) 대신 컴포지션(Composition)

추상화를 단행할 시점에 도달했을 때도 어떤 방식으로 추상화를 구현하느냐에 따라 시스템의 운명이 갈립니다. 과거 객체지향 설계에서 관습적으로 사용되던 '상속을 통한 재사용'은 성급한 추상화의 피해를 극대화하는 주범입니다. 부모 클래스의 구현 세부 사항이 자식 클래스 전체로 누출되며, 컴파일 타임의 강력한 의존성을 형성하기 때문입니다.

진정한 아키텍처적 유연성을 확보하기 위해서는 GoF(Gang of Four)가 강조한 불변의 격언, "클래스 상속보다는 객체 합성을 우선하라(Favor object composition over class inheritance)"를 철저히 따라야 합니다.

아래 표는 상속 기반 추상화와 컴포지션 기반 추상화가 변경의 충격을 흡수하는 방식의 차이를 비교한 분석입니다.

만약 여러 데이터 소스로부터 주문 정보를 파싱하는 로직이 중복된다면, AbstractOrderParser를 만들어 공통 파싱 단계를 템플릿화하는 대신, 순수 데이터 변환 기능을 수행하는 독립된 OrderLineTransformer를 조합 가능한 작은 부품으로 주입하는 것이 바람직합니다. 이렇게 하면 특정 결제 수단이나 해외 주문 도메인의 특수 요구사항이 발생하더라도 기존 부품을 전혀 건드리지 않고 새로운 변환기를 끼워 넣을 수 있습니다.

엔지니어링 조직의 '인지적 완결' 지연 훈련

기술적인 가드레일 못지않게 중요한 것은, 개발 문화 속에서 '모호성을 건강하게 견디는 역량'을 내재화하는 것입니다. 뛰어난 시니어 엔지니어와 그렇지 못한 엔지니어를 가르는 결정적인 차이는 기술 지식의 양이 아니라, 아키텍처 결정의 순간에 불확실성을 기꺼이 품고 관찰을 지속할 수 있는 심리적 지구력(Psychological Stamina)에 있습니다.

조직 차원에서 인지적 완결 지연 역량을 육성하기 위한 세 가지 실천 방안은 다음과 같습니다.

1. 중복 코드에 대한 낙인 제거(De-stigmatizing Duplication): 많은 주니어 개발자들은 PR에 중복 코드가 남아 있는 것을 무능의 증거로 오해합니다. 팀 리더는 "알려지지 않은 맥락에서의 성급한 추상화보다 격리된 중복이 백배 낫다"는 원칙을 지속적으로 천명하고, 불확실한 상태에서의 조기 추상화 PR에 대해 당당하게 롤백을 제안할 수 있는 안전한 분위기를 조성해야 합니다.
2. 의사결정 지연(Last Responsible Moment)의 제도화: 애자일과 린 소프트웨어 개발의 핵심 원칙 중 하나는 가장 늦은 책임 있는 순간까지 중대한 설계를 미루는 것입니다. 기능 초기 단계에서는 도메인 모델의 경계를 열어두고, 실제 운영 환경에서 데이터 트래픽과 사용자 피드백이 누적되었을 때 리팩터링 스프린트를 통해 설계를 고도화하는 사이클을 정착시켜야 합니다.
3. 아키텍처 인지 부하 메트릭 추적: 정적 분석 도구를 활용하여 클래스 간 순환 참조율, 상속 깊이(Depth of Inheritance Tree), 모듈 간 불안정성 지표를 정기적으로 모니터링합니다. 코드 라인 수의 절감보다 결합도의 감쇄가 비즈니스 민첩성을 지키는 진정한 핵심 지표임을 조직 전체가 공유해야 합니다.

맺음말: 불완전함을 견디는 용기가 우아한 아키텍처를 만든다

효과적으로 정돈되고 결점 하나 없는 단일 상속 체계를 구축하고 싶은 욕망은 모든 엔지니어의 마음속에 내재된 본능입니다. 하지만 소프트웨어 시스템이 해결해야 하는 현실 세계의 비즈니스는 언제나 파편화되어 있고 모순으로 가득 차 있으며 시시각각 변화합니다. 이 혼란스러운 현실을 마주했을 때, 나의 불안감을 해소하기 위해 섣부른 추상화라는 거푸집을 씌우는 순간 시스템은 유연성을 상실하고 경직되어 버립니다.

진정으로 우아한 아키텍처는 코드가 단 한 줄도 겹치지 않는 무균실 같은 시스템이 아닙니다. 비즈니스의 변화 방향이 명확해질 때까지 기꺼이 중복을 품고 불확실성을 인내할 수 있는 시스템, 그리고 마침내 세 번째 신호가 도달했을 때 비로소 최소한의 결합도로 결단력 있게 응집하는 유연한 시스템입니다.

오늘 당신의 IDE 에디터 속에서 꿈틀거리는 성급한 추상화의 유혹을 잠시 내려놓으십시오. 두 개의 서로 다른 코드가 각자의 삶을 살아가도록 온전히 내버려 둘 줄 아는 그 침묵의 절제야말로, 지속 가능한 소프트웨어를 빚어내는 엔지니어의 가장 위대한 미덕입니다.

참고 자료

• Sandi Metz: The Wrong Abstraction (Duplication is far cheaper than the wrong abstraction)
• Webster, D. M., & Kruglanski, A. W. Individual Differences in Need for Cognitive Closure
• John Ousterhout: A Philosophy of Software Design