본문으로 건너뛰기

관심사 분리

개념

관심사 분리는 소프트웨어 시스템이 다루어야 할 서로 다른 문제를 독립된 부분으로 나누어 각 부분이 하나의 관심사만 다루도록 하는 소프트웨어 공학의 설계 원칙이다.

관심사 분리(Separation of Concerns, 약칭 SoC)는 소프트웨어 시스템을 구성하는 여러 문제나 측면을 각각 독립된 부분으로 나누어, 프로그램의 각 부분이 하나의 관심사만을 다루도록 설계하는 소프트웨어 공학의 원칙이다. 여기서 관심사란 시스템이 다루어야 하는 문제의 한 측면이나 요구사항, 이를테면 데이터 처리 로직, 사용자 인터페이스의 표현, 오류 처리, 성능, 보안, 데이터 저장 방식 등을 가리킨다. 이 원칙은 설계자와 개발자가 한 번에 하나의 문제에만 집중할 수 있도록 함으로써 시스템의 복잡성을 다루기 쉬운 단위로 나누는 것을 목표로 한다.

이 용어는 네덜란드의 컴퓨터 과학자 에츠허르 데이크스트라가 1974년에 작성한 글 “과학적 사고의 역할에 관하여”(On the Role of Scientific Thought, EWD447)에서 처음 사용한 것으로 알려져 있다. 데이크스트라는 이 글에서 컴퓨터 과학자들이 프로그램의 일반적 수용 가능성에 대한 관심과 그 결과물의 질에 대한 관심을 뒤섞거나, 프로그램의 정확성에 대한 관심과 그것이 실제로 바람직한지에 대한 관심을 뒤섞는 경향을 지적하며, 여러 성격이 다른 문제를 한꺼번에 다루지 않고 한 번에 한 측면에만 집중해 사고를 정리하는 태도를 관심사 분리라고 불렀다. 이는 본래 프로그램의 코드 구조 자체보다는 설계자가 문제를 사고하는 방식에 관한 논의였으나, 이후 소프트웨어의 구조를 나누는 설계 원칙으로 폭넓게 확장되어 받아들여졌다.

관심사 분리는 그 자체로 구체적인 기법을 규정하지는 않으며, 모듈화, 캡슐화, 정보 은닉, 결합도와 응집도 등 소프트웨어 설계에서 이미 논의되던 여러 개념과 밀접하게 연관되며 발전했다. 데이비드 파나스는 1972년 논문에서 시스템을 변경 가능성이 큰 설계 결정을 기준으로 모듈로 나누고 그 결정을 다른 모듈로부터 감추어야 한다는 정보 은닉 개념을 제시했으며, 웨인 스티븐스, 글렌퍼드 마이어스, 래리 콘스탄틴은 비슷한 시기에 결합도와 응집도라는 척도를 통해 모듈 간의 의존성과 모듈 내부의 응집성을 평가하는 구조적 설계 방법론을 제안했다. 이러한 개념들은 이후 관심사 분리라는 원칙을 실현하는 구체적 수단으로 자리 잡았다.

관심사 분리는 소프트웨어의 여러 층위에서 서로 다른 형태로 나타난다. 사용자 인터페이스 설계에서는 데이터와 표현, 입력 처리를 나누는 모델-뷰-컨트롤러 패턴이나 표현 계층, 응용 로직 계층, 데이터 접근 계층으로 나누는 다계층 아키텍처로 구현되며, 객체지향 프로그래밍의 캡슐화나 여러 모듈에 걸쳐 흩어지는 로깅, 보안 검사와 같은 교차 관심사를 별도로 모듈화하는 관점 지향 프로그래밍에서도 나타난다. 시스템 전체 구조 차원에서는 각 서비스가 하나의 사업 역량을 책임지도록 나누는 마이크로서비스 아키텍처가 관심사 분리 원칙을 조직과 배포 단위까지 확장한 사례로 거론된다.

관심사 분리는 단일 책임 원칙이나 정보 은닉과 같은 인접한 원칙들과 자주 비교되며, 이들 각각이 서로 다른 강조점과 적용 범위를 가진다는 점에서 구별된다. 한편 관심사를 지나치게 세분화하는 것이 오히려 계층과 간접 참조를 늘려 시스템의 이해와 추적을 어렵게 만든다는 지적도 제기되어 왔으며, 이러한 우려는 조엘 스폴스키가 제시한 누수되는 추상화의 법칙이나 마이크로서비스 분해의 적정 시점을 둘러싼 실무자들의 논쟁에서 구체적으로 드러난다.

정의와 유래

“관심사”의 의미

소프트웨어 공학에서 관심사는 시스템이 다루어야 하는 문제의 한 측면이나 요구사항을 뜻한다. 관심사는 기능적인 것일 수도 있고 비기능적인 것일 수도 있다. 기능적 관심사에는 특정 업무 규칙의 처리나 데이터 검증과 같이 시스템이 수행해야 할 구체적 작업이 포함되며, 비기능적 관심사에는 성능, 보안, 이식성처럼 시스템 전반에 걸쳐 요구되는 품질 속성이 포함된다. 관심사는 함수나 클래스 같은 작은 단위에서부터 하나의 모듈, 서브시스템, 나아가 서로 다른 설계 활동 자체에 이르기까지 다양한 규모에서 식별될 수 있다.

데이크스트라의 1974년 저술

데이크스트라는 EWD447에서 컴퓨터 과학자가 흔히 소홀히 하는 관심사 분리의 사례들을 제시했다. 그는 어떤 결과물이 일반적으로 받아들여질 수 있는가에 대한 관심과 그 결과물 자체의 질에 대한 관심이 뒤섞이는 경우, 그리고 프로그램의 정확성에 대한 관심과 그 프로그램이 실제로 바람직한지에 대한 관심이 뒤섞이는 경우를 예로 들었다. 그는 지적인 사고의 특징이란 주제의 한 측면을 그 자체의 일관성을 위해 깊이 파고들면서도, 그것이 여러 측면 가운데 하나일 뿐이라는 사실을 계속 인식하는 데 있다고 설명했다. 이 서술은 이후 소프트웨어 설계 문헌에서 관심사 분리 원칙의 정의로 널리 인용되었다.

역사적 배경과 전개

구조적 설계에서의 모듈 분할: 결합도와 응집도

데이크스트라가 관심사 분리라는 용어를 제시한 것과 비슷한 시기에, 웨인 스티븐스, 글렌퍼드 마이어스, 래리 콘스탄틴은 1974년 IBM 시스템 저널에 “구조적 설계”라는 논문을 발표했다. 이 논문은 모듈 사이의 의존성 정도를 나타내는 결합도와 모듈 내부 요소들이 서로 얼마나 밀접하게 관련되어 있는가를 나타내는 응집도라는 두 척도를 제시했으며, 좋은 설계란 모듈 간 결합도는 낮추고 모듈 내부 응집도는 높이는 방향으로 이루어져야 한다고 주장했다. 이 개념은 이후 에드워드 요든과 콘스탄틴이 1979년 펴낸 저서 “구조적 설계”를 통해 더 체계적으로 정리되었으며, 소프트웨어 품질과 복잡도를 평가하는 여러 후속 연구의 토대가 되었다.

정보 은닉과 모듈 경계의 기준

데이비드 파나스는 1972년 발표한 논문 “시스템을 모듈로 분해하는 데 사용할 기준에 관하여”에서 시스템을 모듈로 나누는 기준에 대한 새로운 관점을 제시했다. 그는 문헌 색인 생성 프로그램을 예로 들어, 처리 순서를 기준으로 모듈을 나누는 통상적인 방식 대신, 변경될 가능성이 큰 설계 결정 하나하나를 기준으로 모듈을 나누고 그 결정의 세부 사항을 다른 모듈에는 감추어야 한다고 주장했다. 이렇게 나뉜 모듈은 내부 구현이 바뀌더라도 그 모듈에 의존하는 다른 모듈을 수정할 필요가 없어진다는 장점을 가진다. 파나스는 이 기법을 정보 은닉이라 불렀으며, 이는 관심사 분리를 모듈 경계라는 구체적 형태로 구현하는 대표적 기법으로 자리 잡았다.

사용자 인터페이스 구조에서의 관심사 분리

트뤼그베 렌스카우그는 1978년부터 1979년 사이 제록스 팔로알토 연구소에서 스몰토크 언어를 이용한 연구를 진행하며 모델-뷰-컨트롤러 패턴을 고안했다. 이 패턴은 사용자가 다루는 정보 그 자체를 나타내는 모델, 그 정보를 화면에 나타내는 뷰, 사용자의 입력을 처리하고 모델과 뷰를 중개하는 컨트롤러라는 세 가지 역할을 분리함으로써, 하나의 정보를 여러 관점에서 동시에 다룰 수 있게 하는 것을 목표로 했다. 이 패턴은 이후 글렌 크래스너와 스티븐 포프가 1988년 발표한 스몰토크-80 환경에서의 활용 지침을 통해 더 널리 알려졌으며, 사용자 인터페이스를 넘어 표현 계층, 응용 로직 계층, 데이터 접근 계층을 나누는 일반적인 다계층 아키텍처로도 확장되어 적용되었다.

핵심 원리와 메커니즘

관심사의 식별과 모듈 경계 설정

관심사 분리를 실제로 적용하는 과정의 핵심은 시스템이 다루어야 할 관심사를 식별하고, 그 경계에 따라 모듈을 나누는 것이다. 파나스가 지적했듯이, 처리 순서나 데이터 흐름을 기준으로 모듈을 나누는 방식과 변경 가능성이 큰 설계 결정을 기준으로 나누는 방식은 서로 다른 결과를 낳으며, 어떤 기준을 선택하느냐에 따라 이후 시스템을 수정하고 이해하는 난이도가 달라진다. 이 때문에 관심사 분리는 특정한 절차라기보다, 설계 과정에서 반복적으로 던져야 하는 질문, 즉 이 부분이 다른 부분과 독립적으로 변경될 수 있는가라는 질문에 가깝게 다루어진다.

결합도와 응집도라는 척도

결합도와 응집도는 어떤 분해가 관심사를 얼마나 잘 분리했는지를 평가하는 척도로 널리 쓰인다. 결합도는 한 모듈이 다른 모듈의 내부 구현에 얼마나 의존하는지를 나타내며, 응집도는 한 모듈 내부의 구성 요소들이 하나의 목적을 위해 얼마나 긴밀하게 연관되어 있는지를 나타낸다. 스티븐스, 마이어스, 콘스탄틴은 응집도를 우연적 응집에서 기능적 응집에 이르는 여러 단계로 세분화했으며, 이러한 척도는 이후 소프트웨어 복잡도와 품질을 정량적으로 다루는 여러 연구에서 기초 개념으로 활용되었다.

교차 관심사와 관점 지향 프로그래밍

객체지향 프로그래밍과 같은 통상적인 모듈 분해 방식에서는 로깅, 보안 검사, 트랜잭션 관리처럼 여러 모듈에 걸쳐 반복적으로 나타나는 관심사를 하나의 모듈 안에 깔끔하게 가두기 어려운 경우가 있다. 그레고어 키찰레스와 동료 연구자들은 1997년 유럽 객체지향 프로그래밍 학회에서 발표한 논문에서 이러한 관심사를 교차 관심사라 명명하고, 이를 별도의 모듈 단위인 관점으로 분리한 뒤 프로그램의 정해진 지점에 자동으로 결합하는 관점 지향 프로그래밍을 제안했다. 이는 기존의 계층적 모듈화 방식만으로는 모든 관심사를 완전히 분리하기 어렵다는 문제의식에서 출발한 접근으로 소개되었다.

실제 적용 사례

사용자 인터페이스와 애플리케이션 계층에서의 분리

모델-뷰-컨트롤러 패턴

모델-뷰-컨트롤러 패턴은 관심사 분리가 구체적인 설계 패턴으로 구현된 대표적 사례로 꼽힌다. 이 패턴에서 모델은 응용 프로그램이 다루는 데이터와 업무 로직을 담당하고, 뷰는 그 데이터를 사용자에게 시각적으로 보여주는 역할을 하며, 컨트롤러는 사용자의 입력을 받아 모델의 상태를 변경하고 그 결과를 뷰에 반영하도록 조정한다. 이러한 역할 분리 덕분에 동일한 모델에 대해 서로 다른 뷰를 구성하거나, 화면 구성을 변경하더라도 데이터 처리 로직에는 영향을 주지 않을 수 있다.

다계층 엔터프라이즈 아키텍처

기업용 응용 프로그램에서는 흔히 사용자에게 정보를 보여주는 표현 계층, 업무 규칙을 처리하는 응용 로직 계층, 데이터베이스와 상호작용하는 데이터 접근 계층으로 시스템을 나누는 다계층 아키텍처가 널리 쓰인다. 이러한 구조에서 각 계층은 인접한 계층하고만 상호작용하도록 설계되어, 한 계층의 내부 구현이 바뀌더라도 다른 계층에 미치는 영향을 최소화할 수 있다.

graph TD
    A[표현 계층] --> B[응용 로직 계층]
    B --> C[데이터 접근 계층]

관점 지향 프로그래밍과 교차 관심사

관점 지향 프로그래밍은 로깅이나 보안 검사, 트랜잭션 관리처럼 여러 모듈에 걸쳐 나타나는 관심사를 별도의 관점으로 분리해 다루는 프로그래밍 방식이다. 개발자는 핵심 업무 로직을 담은 모듈과는 별도로 이러한 부가적 관심사를 관점으로 작성하고, 이를 프로그램의 특정 실행 지점에 자동으로 적용되도록 지정한다. 이 방식은 아스펙트제이와 같은 도구를 통해 자바 등의 객체지향 언어 환경에서 구현되었다.

마이크로서비스 아키텍처

제임스 루이스와 마틴 파울러는 2014년 발표한 글에서 마이크로서비스 아키텍처를 하나의 응용 프로그램을 각각 독립적으로 배포 가능한 여러 개의 작은 서비스들의 조합으로 설계하는 방식이라고 설명했다. 이들은 마이크로서비스가 흔히 사업 역량을 중심으로 조직되고, 각 서비스가 자체적인 데이터 저장소와 기술 스택을 선택할 수 있는 분산된 거버넌스를 특징으로 한다고 서술했다. 이러한 접근은 관심사 분리의 단위를 소스 코드 내부의 모듈 수준에서 독립적으로 배포되고 운영되는 프로세스 및 조직 단위 수준으로 확장한 사례로 다루어진다.

관련 개념과의 비교

관심사 분리는 여러 인접 개념과 함께 논의되지만, 각각은 서로 다른 층위와 초점을 가진다.

개념 초점 대표적 논의
관심사 분리 어떤 문제를 독립적으로 다룰 것인가라는 설계 태도 데이크스트라(1974)
정보 은닉 변경 가능성이 큰 설계 결정을 모듈 뒤에 감추는 기법 파나스(1972)
결합도와 응집도 모듈 간 의존성과 모듈 내부 응집성을 평가하는 척도 스티븐스·마이어스·콘스탄틴(1974)
단일 책임 원칙 하나의 모듈이 하나의 행위 주체에 대해서만 책임을 지는 것 마틴(2003)

모듈성, 캡슐화, 정보 은닉과의 관계

관심사 분리는 왜 시스템을 나누어야 하는가에 대한 설계 원칙인 반면, 모듈성은 시스템을 여러 단위로 나누는 구조적 방식 자체를 가리키며, 캡슐화와 정보 은닉은 그렇게 나뉜 단위의 경계를 지키기 위해 내부 세부사항을 감추는 구체적 기법이다. 따라서 관심사 분리는 목표에 해당하고, 모듈성과 정보 은닉은 그 목표를 실현하는 수단에 해당한다고 설명된다.

단일 책임 원칙과의 관계

로버트 마틴은 자신의 2003년 저서 “애자일 소프트웨어 개발”을 통해 널리 알려진 단일 책임 원칙에서, 하나의 클래스는 오직 하나의 변경 이유만을 가져야 한다고 주장했다. 마틴은 이후 자신의 블로그 글에서 단일 책임 원칙을 관심사 분리와 직접 연결지어, 같은 이유로 변하는 것들은 한데 모으고 다른 이유로 변하는 것들은 서로 분리해야 한다는 말로 다시 풀이했다. 다만 단일 책임 원칙은 주로 클래스나 모듈 단위에서 변경을 요청하는 행위 주체를 기준으로 논의되는 반면, 데이크스트라가 제시한 관심사 분리는 정확성과 효율성처럼 설계 과정에서 이루어지는 서로 다른 사고 활동에도 적용되는 더 넓은 범위의 원칙으로 다루어진다.

논쟁과 비판적 시각

추상화 경계의 불완전성

조엘 스폴스키는 2002년 자신의 블로그에 발표한 글 “누수되는 추상화의 법칙”에서, 복잡성을 감추기 위해 만들어진 추상화라도 일정 수준을 넘어서면 그 아래에 감추어져 있던 세부 사항이 결국 드러나기 마련이라고 주장했다. 그는 이러한 현상 때문에 개발자가 특정 계층만을 이해해서는 문제를 완전히 해결할 수 없고, 결국 추상화가 감추려 했던 하위 계층까지 이해해야 하는 상황에 놓이게 된다고 설명했다. 이 논의는 관심사를 나누어 서로의 세부사항을 감추려는 시도가 어느 경계에서도 완전히 성공하기는 어렵다는 지적으로 받아들여진다.

과도한 분해를 둘러싼 논쟁

마틴 파울러는 2015년 자신의 블로그에 발표한 글 “모놀리스 퍼스트”에서, 새로운 시스템을 처음부터 마이크로서비스 단위로 잘게 나누어 시작하는 접근은 흔히 시기상조라고 주장했다. 그는 설계 초기에는 어디에서 서비스 경계를 그어야 하는지 충분히 파악하기 어려운 경우가 많으며, 이런 상태에서 지나치게 세분화된 경계를 미리 설정하면 네트워크로 연결되어 있으면서도 서로 강하게 결합된, 이른바 분산된 모놀리스라는 상태에 이를 수 있다고 지적했다. 반면 스테판 틸코프와 같은 실무자들은 처음부터 모놀리스로 시작하면 이후에 모듈 간 결합을 되돌려 분리하기가 오히려 더 어려워질 수 있다고 반박하며, 처음부터 서비스 단위로 분리하는 접근을 지지했다.

아마존의 프라임 비디오 팀은 2023년 자사 기술 블로그에 발표한 글에서, 서버리스 구성 요소와 여러 개의 분산된 서비스로 이루어져 있던 영상 품질 모니터링 파이프라인을 단일 프로세스로 통합한 결과 인프라 비용을 90퍼센트 넘게 절감했으며 이전에 겪던 확장성 한계도 해소되었다고 밝혔다. 이 사례는 관심사를 지나치게 세분화하여 별도의 서비스로 나누는 것이 항상 최선의 결과로 이어지지는 않을 수 있다는 논쟁에서 구체적인 예로 자주 인용된다.

같이 보기

  • 모듈성(소프트웨어)
  • 결합도와 응집도
  • 정보 은닉
  • 단일 책임 원칙
  • 모델-뷰-컨트롤러
  • 관점 지향 프로그래밍
  • 마이크로서비스 아키텍처
  • 다계층 아키텍처
  • 누수되는 추상화

참고 자료

  • Dijkstra, Edsger W. (1982), “On the Role of Scientific Thought” (1974년 작성된 EWD447), in Selected Writings on Computing: A Personal Perspective, Springer-Verlag, pp. 60–66
  • Parnas, David L. (1972), “On the Criteria to Be Used in Decomposing Systems into Modules”, Communications of the ACM, 15(12), pp. 1053–1058
  • Stevens, Wayne P.; Myers, Glenford J.; Constantine, Larry L. (1974), “Structured Design”, IBM Systems Journal, 13(2)
  • Yourdon, Edward; Constantine, Larry L. (1979), Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Prentice-Hall
  • Reenskaug, Trygve (1979), “MVC XEROX PARC 1978–79”, Xerox PARC 기술 노트
  • Krasner, Glenn E.; Pope, Stephen T. (1988), “A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80”, Journal of Object-Oriented Programming, 1(3), pp. 26–49
  • Kiczales, Gregor; Lamping, John; Mendhekar, Anurag; Maeda, Chris; Lopes, Cristina; Loingtier, Jean-Marc; Irwin, John (1997), “Aspect-Oriented Programming”, Proceedings of ECOOP 1997, Lecture Notes in Computer Science 1241, Springer, pp. 220–242
  • Martin, Robert C. (2003), Agile Software Development, Principles, Patterns, and Practices, Prentice Hall
  • Martin, Robert C. (2014), “The Single Responsibility Principle”, Clean Coder Blog
  • Lewis, James; Fowler, Martin (2014), “Microservices: a definition of this new architectural term”, martinfowler.com
  • Fowler, Martin (2015), “MonolithFirst”, martinfowler.com
  • Spolsky, Joel (2002), “The Law of Leaky Abstractions”, Joel on Software
  • Ghezzi, Carlo; Jazayeri, Mehdi; Mandrioli, Dino (2003), Fundamentals of Software Engineering, 2nd ed., Prentice Hall
  • Kolny, Marcin (2023), “Scaling up the Prime Video Audio/Video Monitoring Service and Reducing Costs by 90%”, Prime Video Tech Blog