[태그:] 리팩토링

소프트웨어 개발은 단순히 기능을 구현하는 것을 넘어, 잘 정돈되고 지속 가능한 코드를 작성하는 예술과 과학의 결합입니다. 정보처리기사 자격증을 준비하거나, 더 나은 개발자, 프로젝트 관리자, 심지어는 UX/UI 디자이너가 되기를 꿈꾸는 분이라면 반드시 이해해야 할 핵심 개념이 바로 ‘응집도(Cohesion)’입니다. 응집도는 코드의 품질을 결정하는 내적인 척도로, 모듈 내부의 요소들이 얼마나 서로 밀접하게 관련되어 있는지를 나타냅니다. 마치 잘 정리된 서재의 책들이 주제별로 꽂혀 있어 찾기 쉽고 관리하기 편한 것처럼, 응집도 높은 코드는 이해하기 쉽고, 유지보수하기 용이하며, 재사용성이 뛰어납니다.

이 글에서는 응집도의 개념을 깊이 파고들어, 왜 이것이 소프트웨어의 구조적 완성도를 결정하는지, 그리고 어떻게 하면 코드의 응집도를 높여 더 견고하고 유연한 시스템을 만들 수 있는지에 대해 상세히 다룰 것입니다. 우리는 응집도의 7가지 레벨을 구체적인 예시와 함께 살펴보고, 이것이 현대적인 마이크로서비스 아키텍처나 컴포넌트 기반 개발에서 어떻게 적용되는지까지 확장하여 탐구할 것입니다. 이 글을 끝까지 읽으신다면, 단순히 ‘동작하는’ 코드를 넘어 ‘품격 있는’ 코드를 작성하는 데 필요한 깊이 있는 통찰력을 얻게 될 것입니다.

목차

1. 응집도란 무엇인가?: 코드 품질의 바로미터
2. 응집도의 7가지 레벨: 좋은 코드와 나쁜 코드의 스펙트럼
3. 현대 소프트웨어 개발에서의 응집도 적용 사례
4. 결론: 좋은 코드를 넘어 위대한 제품으로

응집도란 무엇인가?: 코드 품질의 바로미터

응집도의 정의와 중요성

응집도(Cohesion)는 소프트웨어 공학에서 모듈 내부의 요소들이 하나의 목적을 위해 얼마나 긴밀하게 연관되어 있는지를 측정하는 지표입니다. 여기서 ‘모듈’이란 함수, 클래스, 컴포넌트, 서비스 등 특정 기능을 수행하는 코드의 단위를 의미합니다. 응집도가 높다는 것은 모듈이 단 하나의 명확하고 집중된 책임(Single Responsibility)을 가지고 있다는 뜻입니다. 예를 들어, ‘사용자 이메일 주소 유효성 검사’라는 기능을 수행하는 함수는 오직 그 기능에만 집중해야 합니다. 만약 이 함수가 이메일 유효성 검사 외에 데이터베이스에 로그를 남기거나, 사용자 인터페이스를 업데이트하는 등의 부가적인 작업을 함께 처리한다면, 이는 응집도가 낮은 것으로 간주됩니다.

응집도가 높은 코드는 수많은 장점을 가집니다. 첫째, 이해하기 쉽습니다. 모듈의 이름만 보아도 그 기능을 명확히 예측할 수 있기 때문에, 다른 개발자가 코드를 읽고 분석하는 데 드는 시간이 크게 줄어듭니다. 둘째, 유지보수가 용이합니다. 특정 기능에 대한 수정이 필요할 때, 해당 기능을 담당하는 모듈만 수정하면 되므로 변경의 영향 범위가 최소화됩니다. 이는 ‘사이드 이펙트(Side Effect)’ 즉, 의도치 않은 곳에서 버그가 발생하는 것을 방지하는 데 결정적입니다. 셋째, 재사용성이 극대화됩니다. 하나의 명확한 기능 단위로 만들어진 모듈은 다른 시스템이나 프로젝트에서도 쉽게 가져다 쓸 수 있습니다. 이는 개발 생산성을 높이는 핵심 요소입니다.

결합도(Coupling)와의 관계: 동전의 양면

응집도를 이야기할 때 결코 빼놓을 수 없는 개념이 바로 ‘결합도(Coupling)’입니다. 결합도는 모듈과 모듈 사이의 상호 의존도를 나타내는 척도입니다. 응집도가 모듈 내부의 이야기라면, 결합도는 모듈 외부, 즉 모듈 간의 관계에 대한 이야기입니다. 이상적인 소프트웨어 설계의 목표는 ‘높은 응집도와 낮은 결합도(High Cohesion, Low Coupling)’를 달성하는 것입니다.

이 둘의 관계를 비유를 통해 설명해 보겠습니다. 고도로 전문화된 부서들로 이루어진 회사를 상상해 보세요. ‘마케팅팀’은 오직 마케팅 전략 수립과 실행에만 집중하고(높은 응집도), ‘개발팀’은 제품 개발에만 몰두합니다(높은 응집도). 이 두 팀이 소통할 때는 복잡한 내부 사정을 모두 공유하는 것이 아니라, ‘주간 업무 보고서’라는 명확하고 표준화된 채널을 통해서만 필요한 정보를 교환합니다(낮은 결합도). 이렇게 되면 한 팀의 내부적인 업무 방식 변경이 다른 팀에 거의 영향을 주지 않아 전체 조직이 안정적으로 운영될 수 있습니다.

반대로, 모든 팀원이 모든 일에 관여하고, 업무 절차 없이 수시로 서로에게 직접 일을 요청하는 스타트업을 생각해 봅시다(낮은 응집도, 높은 결합도). 이런 구조는 초기에는 빠르게 움직이는 것처럼 보일 수 있지만, 규모가 커질수록 누가 무슨 일을 하는지 파악하기 어렵고, 작은 변경 하나가 연쇄적으로 모든 팀에 영향을 미쳐 시스템 전체가 혼란에 빠지기 쉽습니다. 코드의 세계도 이와 똑같습니다. 따라서 우리는 각 모듈이 제 역할을 충실히 하도록 응집도를 높이고, 모듈 간의 불필요한 간섭은 최소화하여 결합도를 낮추는 방향으로 코드를 설계해야 합니다.

응집도의 7가지 레벨: 좋은 코드와 나쁜 코드의 스펙트럼

응집도는 단순히 ‘높다’ 또는 ‘낮다’로만 평가되지 않습니다. 소프트웨어 공학자들은 응집도의 수준을 7단계로 나누어 체계적으로 분석합니다. 가장 바람직한 ‘기능적 응집도’부터 가장 피해야 할 ‘우연적 응집도’까지, 각 레벨의 특징과 예시를 통해 내 코드의 응집도 수준을 진단해 봅시다. 이 레벨들은 아래로 갈수록 좋은(높은) 응집도를 의미합니다.

1. 우연적 응집도 (Coincidental Cohesion)

가장 낮은 수준의 응집도로, 모듈 내의 요소들이 아무런 의미 있는 연관성 없이 그저 하나의 파일이나 클래스에 묶여 있는 상태를 말합니다. 보통 ‘Common’, ‘Utils’ 같은 이름의 클래스에서 흔히 발견되며, ‘잡동사니 서랍’에 비유할 수 있습니다.

• 예시: CommonUtils 클래스 안에 calculateInterest(원금, 이율), validateEmail(이메일주소), getSystemInfo() 와 같이 서로 전혀 관련 없는 함수들이 모여 있는 경우입니다. 이메일 유효성 검사 로직을 수정하려고 CommonUtils 파일을 열었는데, 이자 계산 로직과 시스템 정보 조회 로직이 함께 있어 혼란을 유발하고, 이 파일의 변경이 전혀 예상치 못한 부분에 영향을 줄 수 있습니다.

2. 논리적 응집도 (Logical Cohesion)

유사한 성격의 기능들이 하나의 모듈에 묶여 있고, 특정 매개변수나 플래그(flag) 값을 통해 그중 하나가 선택되어 실행되는 구조입니다. 예를 들어, 모든 데이터베이스 관련 작업을 처리하는 하나의 함수가 있고, ‘INSERT’, ‘UPDATE’, ‘DELETE’ 같은 문자열 인자를 받아 각각 다른 작업을 수행하는 경우입니다.

• 예시: executeDbTask(taskType, data) 함수가 taskType 값에 따라 if (taskType == "INSERT") { ... } else if (taskType == "UPDATE") { ... } 와 같이 분기 처리되는 구조입니다. 이는 관련된 코드가 흩어지는 우연적 응집도보다는 낫지만, 함수 내부의 코드가 복잡해지고 서로 다른 기능을 위한 코드가 섞여 있어 가독성과 유지보수성이 떨어집니다.

3. 시간적 응집도 (Temporal Cohesion)

특정 시점에 함께 실행되어야 하는 작업들이 하나의 모듈로 묶여 있는 경우입니다. 예를 들어, 프로그램이 시작될 때 초기화해야 하는 작업들, 즉 ‘데이터베이스 연결’, ‘설정 파일 로딩’, ‘네트워크 소켓 초기화’ 등을 initializeApp()이라는 하나의 함수에 모아두는 것입니다.

• 예시: initializeApp() 함수 내부에 connectDatabase(), loadConfigurations(), initializeNetwork() 가 순차적으로 호출됩니다. 이 작업들은 기능적으로는 서로 관련이 없지만 ‘프로그램 시작 시’라는 시간적 제약 때문에 함께 묶여 있습니다. 이 구조는 관련 코드들을 한곳에서 관리할 수 있다는 장점이 있지만, 각 기능의 독립성은 떨어지게 됩니다. 만약 설정 파일 로딩 방식만 변경하고 싶어도, 데이터베이스나 네트워크 코드까지 함께 테스트해야 하는 부담이 생길 수 있습니다.

4. 절차적 응집도 (Procedural Cohesion)

모듈 내의 요소들이 반드시 특정 순서에 따라 실행되어야 하는 관계를 가질 때를 의미합니다. 시간적 응집도보다 발전된 형태로, 작업들이 단순히 같은 시간에 실행되는 것을 넘어, 명확한 실행 순서를 가집니다.

• 예시: processStudentReport() 함수가 getStudentData()를 호출하여 학생 데이터를 가져온 후, 그 데이터를 calculateGrades()에 넘겨 성적을 계산하고, 마지막으로 printReport()를 호출하여 결과 리포트를 출력하는 순서로 구성된 경우입니다. 이 작업들은 순차적으로 의미 있는 절차를 구성하지만, 여전히 여러 기능(데이터 조회, 성적 계산, 리포트 출력)이 하나의 함수에 묶여 있습니다.

5. 통신적 응집도 (Communicational Cohesion)

절차적 응집도에서 한 단계 더 나아가, 모듈 내의 요소들이 동일한 입력 데이터를 공유하거나 동일한 출력 데이터를 생성할 때를 말합니다. 즉, 순서뿐만 아니라 ‘동일한 데이터’를 중심으로 묶여 있습니다.

• 예시: generateUserProfile(userId)라는 함수가 있다고 가정해 봅시다. 이 함수는 userId를 사용하여 데이터베이스에서 사용자의 기본 정보, 활동 기록, 친구 목록을 각각 조회한 후, 이 정보들을 조합하여 최종적인 프로필 데이터를 생성합니다. 이 모든 작업(기본 정보 조회, 활동 기록 조회, 친구 목록 조회)은 userId라는 동일한 데이터를 사용하므로 통신적 응집도를 가집니다. 이는 절차적 응집도보다 관련성이 더 높다고 볼 수 있습니다.

6. 순차적 응집도 (Sequential Cohesion)

모듈 내의 한 요소의 출력이 바로 다음 요소의 입력으로 사용되는, 마치 컨베이어 벨트와 같은 관계를 가질 때입니다. 데이터가 모듈 내에서 순차적으로 흘러가며 가공되는 형태입니다.

• 예시: processAndFormatData(rawText) 함수가 rawText를 입력받아 parseData()를 통해 구조화된 데이터로 변환하고, 그 결과를 다시 formatData()에 전달하여 최종적인 출력 문자열을 만드는 경우입니다. parseData의 출력이 formatData의 입력이 되는 명확한 데이터 흐름이 존재합니다. 이는 매우 강력하고 논리적인 묶음이지만, 여전히 파싱과 포매팅이라는 두 가지 기능이 하나의 모듈에 포함되어 있습니다.

7. 기능적 응집도 (Functional Cohesion)

가장 이상적이고 높은 수준의 응집도입니다. 모듈이 단 하나의 명확하고 잘 정의된 기능을 수행하기 위해 필요한 모든 요소들로만 구성된 상태를 말합니다. ‘단일 책임 원칙(Single Responsibility Principle)’을 가장 잘 만족시키는 수준입니다.

• 예시: calculateSquareRoot(number) 함수는 숫자를 입력받아 그 숫자의 제곱근을 계산하는 단 하나의 기능만을 수행합니다. 이 함수 내부에는 제곱근 계산과 관련된 코드 외에는 아무것도 없습니다. 이렇게 기능적으로 응집된 모듈은 그 목적이 명확하여 이해하기 쉽고, 테스트하기 매우 용이하며, 어디서든 재사용하기 좋습니다. 우리가 작성하는 모든 함수와 클래스는 바로 이 기능적 응집도를 목표로 해야 합니다.

현대 소프트웨어 개발에서의 응집도 적용 사례

응집도는 단순히 이론적인 개념에 머무르지 않고, 오늘날의 복잡한 소프트웨어 아키텍처와 개발 방법론의 근간을 이룹니다. 특히 제품 관리자(PM), 프로덕트 오너(PO), UX/UI 디자이너와 같은 비개발 직군도 응집도의 개념을 이해하면 개발팀과의 소통이 원활해지고 더 나은 제품을 만드는 데 기여할 수 있습니다.

마이크로서비스 아키텍처(MSA)와 응집도

최근 각광받는 마이크로서비스 아키텍처(Microservices Architecture, MSA)는 응집도 개념의 결정체라고 할 수 있습니다. MSA는 거대한 단일 애플리케이션(Monolithic Application)을 기능 단위로 잘게 쪼개어, 각각 독립적으로 배포하고 운영할 수 있는 작은 서비스들의 집합으로 만드는 방식입니다. 여기서 각 ‘마이크로서비스’는 가장 높은 수준의 응집도, 즉 ‘기능적 응집도’를 가져야 한다는 원칙을 따릅니다.

예를 들어, 하나의 이커머스 플랫폼을 MSA로 구축한다면 ‘사용자 관리 서비스’, ‘상품 조회 서비스’, ‘주문 처리 서비스’, ‘결제 서비스’ 등으로 나눌 수 있습니다. ‘주문 처리 서비스’는 주문 생성, 조회, 수정, 취소와 관련된 기능에만 집중하며, 사용자 정보가 필요하면 ‘사용자 관리 서비스’에 API를 통해 요청합니다. 이렇게 하면 주문 관련 기능 변경이 결제 서비스에 직접적인 영향을 주지 않아(낮은 결합도), 서비스별로 독립적인 개발과 빠른 배포가 가능해집니다. 제품 관리자 관점에서는 특정 기능 개선(예: 주문 프로세스 간소화)에 필요한 리소스와 일정을 더 정확하게 산정할 수 있고, 장애 발생 시 그 영향 범위를 해당 서비스로 국한시킬 수 있어 전체 시스템의 안정성이 높아집니다.

컴포넌트 기반 개발(CBD)과 UI 디자인

현대 프론트엔드 개발의 주류인 React, Vue, Angular와 같은 라이브러리 및 프레임워크는 모두 컴포넌트 기반 개발(Component-Based Development, CBD) 사상을 기반으로 합니다. 여기서 ‘컴포넌트’는 UI를 구성하는 독립적인 부품으로, 자체적인 상태(State), 로직(Logic), 그리고 스타일(Style)을 가집니다. 즉, 하나의 컴포넌트는 높은 응집도를 가지도록 설계됩니다.

예를 들어, 유튜브 페이지의 ‘구독 버튼’ 컴포넌트를 생각해 봅시다. 이 컴포넌트는 현재 사용자의 구독 상태(구독 중/미구독)를 내부적으로 관리하고, 클릭 시 ‘구독하기’ 또는 ‘구독 취소’ API를 호출하는 로직을 포함하며, 상태에 따라 버튼의 색상과 텍스트가 바뀌는 스타일까지 모두 책임집니다. 이렇게 잘 만들어진 응집도 높은 컴포넌트는 유튜브 내 다른 페이지에서도 쉽게 재사용될 수 있습니다. UX/UI 디자이너가 응집도 개념을 이해한다면, 단순히 화면을 예쁘게 그리는 것을 넘어, 개발팀이 재사용 가능하고 관리하기 쉬운 컴포넌트 단위로 디자인 시스템을 구축할 수 있도록 기여할 수 있습니다. 이는 전체 제품의 디자인 일관성을 유지하고 개발 효율을 높이는 데 큰 도움이 됩니다.

애자일(Agile)과 제품 관리(Product Management) 관점에서의 응집도

애자일 개발 방법론에서는 작업을 ‘사용자 스토리(User Story)’라는 작은 기능 단위로 나누어 관리합니다. 이 사용자 스토리를 기술적인 관점에서 구현할 때, 코드의 응집도는 매우 중요한 역할을 합니다. 만약 코드베이스의 응집도가 낮다면, 간단해 보이는 사용자 스토리 하나를 구현하기 위해 여러 모듈을 동시에 수정해야 하는 ‘산탄총 수술(Shotgun Surgery)’ 문제가 발생할 수 있습니다. 이는 개발 시간을 예측하기 어렵게 만들고, 예상치 못한 버그를 유발하여 스프린트 계획에 차질을 빚게 합니다.

반면, 코드의 응집도가 높으면 하나의 사용자 스토리는 대부분 하나 또는 소수의 응집된 모듈만 수정하여 완료할 수 있습니다. 이는 작업의 범위를 명확하게 하고, 개발자가 기능 구현에만 집중할 수 있게 해줍니다. 프로덕트 오너나 프로젝트 관리자는 이러한 기술적 배경을 이해함으로써, 개발팀과 함께 더 현실적이고 달성 가능한 백로그(Backlog)를 만들 수 있습니다. 또한, 기술 부채(Technical Debt)가 쌓이는 것을 방지하기 위해 ‘리팩토링(Refactoring)’과 같이 응집도를 높이는 작업의 우선순위를 설정하는 데 있어 더 현명한 의사결정을 내릴 수 있습니다.

결론: 좋은 코드를 넘어 위대한 제품으로

지금까지 우리는 응집도의 정의부터 7가지 레벨, 그리고 현대 소프트웨어 개발에서의 적용 사례까지 폭넓게 살펴보았습니다. 응집도는 단순히 정보처리기사 시험에 나오는 기술 용어가 아니라, 소프트웨어의 건강 상태를 나타내는 핵심 지표이며, 장기적으로 성공하는 제품을 만드는 데 필수적인 철학입니다.

핵심은 명확합니다. 우리는 항상 가장 높은 수준인 ‘기능적 응집도’를 지향해야 합니다. 작성하는 모든 함수와 클래스가 단 하나의 명확한 책임을 갖도록 노력해야 합니다. 이는 마치 각 분야의 전문가가 자신의 전문성에만 집중하여 최고의 결과물을 내는 것과 같습니다. 이러한 노력들이 모여 전체 시스템을 예측 가능하고, 변경에 유연하며, 지속적으로 성장할 수 있는 견고한 구조로 만들어나갑니다.

물론 응집도를 높이는 작업에는 주의점도 따릅니다. 첫째, 과도한 조기 최적화는 피해야 합니다. 처음부터 완벽한 구조를 설계하려는 욕심에 너무 많은 시간을 쏟기보다는, 일단 기능을 구현한 뒤 지속적인 리팩토링을 통해 점진적으로 코드의 응집도를 개선해 나가는 것이 더 현실적일 수 있습니다. 둘째, 응집도는 절대적인 규칙이 아닌 가이드라인입니다. 때로는 비즈니스 로직의 복잡성이나 성능상의 이유로 약간의 타협이 필요할 수도 있습니다. 중요한 것은 응집도의 개념을 항상 염두에 두고, 모든 설계 결정의 트레이드오프(Trade-off)를 명확히 인지하는 것입니다.

결론적으로, 높은 응집도를 추구하는 것은 개발자만의 책임이 아닙니다. 이는 프로젝트 관리자, 제품 책임자, 디자이너 등 제품 개발에 참여하는 모두가 그 중요성을 이해하고 공감대를 형성해야 할 문화에 가깝습니다. 응집도 높은 코드는 더 나은 협업을 이끌어내고, 더 빠른 개발 속도를 가능하게 하며, 최종적으로는 사용자에게 더 안정적이고 가치 있는 제품을 제공하는 초석이 될 것입니다. 당신의 코드가, 그리고 당신의 제품이 ‘품격’을 갖추길 원한다면, 오늘부터 ‘응집도’라는 렌즈를 통해 세상을 바라보기 시작하십시오.