**객체 지향 프로그래밍**의 기본 개념은 작은 독립적인 단위의 객체를 만들어 조립하는 것입니다. 이 개념이 정립되고 다듬어지면서, 프로그래밍의 세계에서 큰 빛을 발하게 되었습니다. 하지만, 단순히 클래스와 객체를 많이 사용한다고 해서 좋은 코드가 만들어지는 것은 아닙니다. 좋은 객체 지향 설계를 위해서는 **객체들 간의 관계를 신중하게 설정**하고, **초기 설계 단계에서 많은 노력을 기울여야**합니다. 객체 지향 프로그래밍은 그 자체로 복잡함이 따르지만, 이러한 복잡함을 관리하기 위한 여러 원칙과 방법이 발전해왔습니다. 그 중에서도 프로그래밍 세계에서 널리 통용되는 **SOILD 원칙**에 대해 정리해보았습니다. # SOLID 원칙이란? SOLID는 좋은 설계를 위한 다섯 가지 원칙으로, 이를 지키면 견고한 소프트웨어를 만들 수 있습니다. 또한, 코드의 유지 보수성과 확장성을 크게 향상시킬 수 있습니다. 이 원칙들은 처음 접할 때는 다소 어려울 수 있지만, 이해하고 나면 코드 설계 시 중요한 이정표가 됩니다. 아직 개발 경험이 부족해서인지, SOLID 원칙을 완벽히 이해하고 적용하는 것이 어렵게 느껴집니다. 그러나 이 원칙들을 공부하면서 컴포넌트를 어떻게 분리하고 설계해야 할지 더 깊이 고민하게 되었습니다. 프론트엔드 개발자로서 어떻게 코드를 모듈화하고, 각 컴포넌트의 역할과 책임을 명확히 할 수 있을지 판단할 수 있는 능력은 정말 많이 중요하다고 생각합니다. 이 SOLID 원칙을 코드에 잘 녹여내기 위해 끊임없이 사고하는 훈련이 앞으로 저의 개발 능력에 큰 도움이 될 것이라고 생각합니다. SOLID 원칙은 다음과 같은 다섯 가지로 구성되어 있습니다. - **SRP (Single Responsibility Principle)** - 단일 책임 원칙 - **OCP (Open Close Principle)** - 개방 폐쇄 원칙 - **LSP (Liskov Substitution Principle)** - 리스코프 치환 원칙 - **ISP (Interface Segregation Principle)** - 인터페이스 분리 원칙 - **DIP (Dependency Inversion Principle)** - 의존성 역전 원칙 이 5가지 원칙들은 서로 독립된 개별적인 개념이 아니라, **서로 개념적으로 연관**되어 있습니다. 원칙끼리 서로가 서로를 이용하기도 하고 포함하기도 합니다. # SRP (Single Responsibility Principle) - 단일 책임 원칙 단일 책임 원칙은 하나의 클래스가 **오직 하나의 기능만을 담당**해야 하며, 클래스가 제공하는 모든 서비스가 하나의 책임을 수행하는 데 집중되어야 한다는 원칙입니다. 쉽게 말해, **클래스를 변경해야 하는 이유는 단 하나여야 한다**는 것입니다. 하나의 클래스에 여러 책임(기능)이 있다면, 특정 기능이 변경될 때 다른 기능에도 영향을 미치게 되어, 수정해야 할 코드가 많아질 수 있습니다. 예를 들어, A 기능을 수정하면 B 기능도 수정해야 하고, 다시 C 기능까지 수정해야 하는 상황이 발생할 수 있습니다. SRP 원칙을 따르면 **한 책임의 변경이 다른 책임으로 연쇄적으로 영향을 미치는 문제를 줄일 수 있습니다.** 핵심은 책임을 분리하는 것뿐만 아니라, **분리된 클래스들 간의 관계에서 복잡도를 줄이도록 설계**하는 것입니다. 이 SRP에 대해서는, 리액트 공식문서에서도 언급될만큼 중요한 원칙입니다. SRP 원칙이 위반된 사례와 그 코드를 수정한 정말 간단한 예제를 들어보겠습니다. ```jsx import React, { useEffect, useState } from "react"; const UserProfile = () => { const [user, setUser] = useState(null); useEffect(() => { // API 호출 (데이터 가져오기) fetchUser(); }, []); const fetchUser = async () => { const response = await fetch("/api/user"); const data = await response.json(); setUser(data); }; return (

{user ? (

{user.name}

{user.email}

) : (

)}

); }; export default UserProfile; ``` 여기서 UserProfile 컴포넌트는 데이터를 가져오는 것과 UI를 렌더링하는 두 가지 책임을 모두 가지고 있습니다. 위의 코드에서 SRP 원칙을 준수하도록 수정하면 다음과 같습니다. ```jsx // userService.js (API 호출을 위한 서비스) export const fetchUser = async () => { const response = await fetch("/api/user"); const data = await response.json(); return data; }; // UserProfile.js (UI 컴포넌트) import React, { useEffect, useState } from "react"; import { fetchUser } from "./userService"; const UserProfile = () => { const [user, setUser] = useState(null); useEffect(() => { const getUserData = async () => { const data = await fetchUser(); setUser(data); }; getUserData(); }, []); return (

{user ? (

{user.name}

{user.email}

) : (

)}

); }; export default UserProfile; ``` API 호출이 별도의 서비스로 분리되었습니다. 이제 ‘UserProfile’ 컴포넌트는 이제 UI 렌더링만 담당하게 됩니다. API 호출 코드에 문제가 있다면 userService.js의 코드를 수정하면 되고, UI에 문제가 있다면 UserProfile.js를 수정하면 됩니다. # 2. OCP (Open Close Principle) - 개방 폐쇄 원칙 **개방 폐쇄 원칙**은 소프트웨어 구성 요소(컴포넌트, 클래스, 모듈, 함수 등)가 **확장에는 열려 있고, 변경(수정)에는 닫혀 있어야** 한다는 원칙입니다. 간단히 말하면, 요구사항이 변경될 때 기존 코드를 변경하는 것이 아니라 새로운 코드를 추가하는 방향을 추구하는 원칙입니다. 이렇게 하면 코드의 안정성을 유지하면서 새로운 요구 사항을 수용할 수 있습니다. 프론트엔드에서 자주 접할 수 있는 컴포넌트 확장 상황을 통해 OCP를 적용하는 예제를 살펴봅니다. 다음은 버튼 컴포넌트를 구현하는 예제입니다. 버튼의 스타일을 변경할 때마다 기존 코드를 수정해야 하는 방식입니다. ```jsx import React from "react"; const Button = ({ type, onClick, children }) => { let className = "btn"; if (type === "primary") { className += " btn-primary"; } else if (type === "secondary") { className += " btn-secondary"; } return ( ); }; export default Button; ``` 물론 위처럼 작성될 일은 많이 없겠지만, 예시 설명을 위해 극적으로 상황을 가정해보았습니다. 이 코드에서는 버튼의 스타일을 변경하기 위해 ‘Button’ 컴포넌트의 코드를 수정해야 합니다. 새로운 버튼 스타일이 필요할 때마다 if문을 추가해야하는 불편함이 있습니다. OCP 원칙을 준수하도록 Button 컴포넌트를 수정하여 버튼 스타일을 확장할 때 기존 코드를 수정하지 않고 새로운 스타일을 추가할 수 있습니다. ```jsx import React from "react"; // 기본 버튼 컴포넌트 const Button = ({ className, onClick, children }) => { return ( ); }; // 기본 버튼 컴포넌트에서 확장된 메인 버튼 컴포넌트 const PrimaryButton = (props) => { return ); } ``` 위의 UserProfile 컴포넌트는 onFollow와 onSendMessage라는 두 가지 기능을 제공합니다. 하지만 만약 어떤 상황에서는 사용자 프로필을 표시하기만 하고, 팔로우나 메시지 전송 기능이 필요 없다면? 불필요한 의존성을 가진 인터페이스가 발생하게 됩니다. 이는 인터페이스 분리 원칙을 위반하는 예시입니다. **ISP를 준수한 설계** ```jsx // 팔로우 기능을 분리한 컴포넌트 function UserFollow({ onFollow }) { return ; } // 메시지 전송 기능을 분리한 컴포넌트 function UserMessage({ onSendMessage }) { return ; } // 사용자 프로필 컴포넌트 function UserProfile({ user, withFollow, withMessage }) { return (

{user.name}

{withFollow && } {withMessage && }

); } ``` 위의 예시에서는 UserFollow와 UserMessage 컴포넌트를 별도로 분리하여 필요한 기능만 UserProfile에 포함하도록 설계했습니다. 이렇게 하면 UserProfile 컴포넌트는 불필요한 인터페이스에 의존하지 않으며, 필요한 경우에만 해당 기능을 포함할 수 있습니다. 이러한 설계는 유지보수성과 확장성을 높이는 동시에, 의존성을 최소화하여 더 유연한 코드를 작성할 수 있도록 도와줍니다. # 5. DIP (Dependency Inversion Principle) - 의존성 역전 원칙 의존성 역전 원칙(DIP)은 클래스 간의 결합도를 낮추기 위한 원칙으로, **구현 세부 사항이 아닌, 추상화된 상위 요소(인터페이스 또는 추상 클래스)에 의존하도록 설계해야 한다**는 것을 의미합니다. 즉, **구체적인 구현 클래스에 의존하지 말고, 인터페이스나 추상 클래스와 같은 상위 요소에 의존**하라는 것입니다. 이는 변화가 잦거나 불안정한 구현에 의존하지 않고, 비교적 변화가 적은 안정적인 추상화에 의존함으로써 코드의 유연성과 유지보수성을 높이는 것을 목표로 합니다. 프론트엔드 개발에서 DIP를 적용하는 대표적인 방법 중 하나는 서비스나 API 호출을 처리할 때 인터페이스를 사용하는 것입니다. 예를 들어, 데이터를 가져오는 API 서비스가 있다고 가정해보겠습니다. **잘못된 설계** ```js class ApiService { fetchData() { return fetch("").then((response) => response.json() ); } } class DataComponent { constructor(apiService) { this.apiService = apiService; } loadData() { this.apiService.fetchData().then((data) => { console.log(data); }); } } // 직접적으로 ApiService에 의존 const apiService = new ApiService(); const dataComponent = new DataComponent(apiService); dataComponent.loadData(); ``` 위의 예시에서 DataComponent는 ApiService라는 구체적인 클래스에 직접 의존하고 있습니다. 만약 ApiService가 변경된다면 DataComponent도 변경해야 하므로, 두 클래스 간의 결합도가 높아지게 됩니다. **DIP를 준수한 설계** ```jsx // 추상화된 인터페이스 class IDataService { fetchData() { throw new Error("Method not implemented."); } } // 구현 클래스 1 class ApiService extends IDataService { fetchData() { return fetch("").then((response) => response.json() ); } } // 구현 클래스 2 class MockService extends IDataService { fetchData() { return Promise.resolve({ mock: "data" }); } } class DataComponent { constructor(dataService) { this.dataService = dataService; } loadData() { this.dataService.fetchData().then((data) => { console.log(data); }); } } // 인터페이스에 의존하여 구현 const apiService = new ApiService(); const mockService = new MockService(); // 테스트 시에는 MockService를 사용 const dataComponent = new DataComponent(apiService); dataComponent.loadData(); ``` 위의 예시에서는 IDataService라는 추상화된 인터페이스를 통해 ApiService와 MockService를 구현했습니다. 이제 DataComponent는 구체적인 구현이 아닌, 추상화된 IDataService에 의존하게 됩니다. 이로 인해 ApiService가 변경되더라도 IDataService 인터페이스만 유지되면 DataComponent는 영향을 받지 않으며, 테스트나 다른 상황에서는 MockService와 같은 대체 구현체를 쉽게 사용할 수 있습니다. 그렇다면 함수형 컴포넌트에서는 어떻게 DIP 원칙을 적용해볼 수 있을까요? 저는 **의존성을 주입하는 방식과 구체적인 구현 대신 추상화된 인터페이스나 함수에 의존하는 방식으로 구현**할 수 있겠다고 생각했습니다. 함수형 컴포넌트에서는 클래스형 컴포넌트와 달리 인터페이스나 추상 클래스를 명시적으로 사용할 수는 없지만, **상위 컴포넌트로부터 필요한 함수나 데이터를 주입받아 처리**함으로써 DIP를 적용할 수 있습니다. 예시 코드로 한 번 살펴봅시다. **잘못된 설계** ```jsx import React, { useEffect, useState } from "react"; function DataComponent() { const [data, setData] = useState(null); useEffect(() => { // 직접적으로 API 호출 로직을 내부에 구현 fetch("https://api.example.com/data") .then((response) => response.json()) .then((data) => setData(data)); }, []); return

{data ? JSON.stringify(data) : "Loading..."}

; } export default DataComponent; ``` 위의 DataComponent는 API 호출 로직을 직접적으로 포함하고 있어, API가 변경될 경우 컴포넌트도 변경해야 합니다. 이는 DIP를 위반한 구조입니다. **DIP를 준수한 설계** ```jsx import React, { useEffect, useState } from "react"; function DataComponent({ fetchData }) { const [data, setData] = useState(null); useEffect(() => { // 주입된 fetchData 함수를 사용하여 데이터 로드 fetchData().then((data) => setData(data)); }, [fetchData]); return

{data ? JSON.stringify(data) : "Loading..."}

; } export default DataComponent; ``` 위의 DataComponent는 fetchData라는 함수를 **상위 컴포넌트로부터 주입받아 사용**합니다. 이제 DataComponent는 API 호출 로직에 의존하지 않고, fetchData 함수에만 의존하게 되므로 DIP를 준수하는 구조가 됩니다. 이렇게 구조가 바뀌면, 이제 상위 컴포넌트에서 실제 API 호출 함수 또는 테스트용 Mock 함수를 주입할 수 있습니다. ```jsx import React from "react"; import DataComponent from "./DataComponent"; function ApiService() { return fetch("https://api.example.com/data").then((response) => response.json() ); } function MockService() { return Promise.resolve({ mock: "data" }); } function App() { return (

{/* 실제 서비스용 */} {/* 테스트용 */}

); } export default App; ``` 이 구조에서는 DataComponent가 어떤 데이터 소스에서 데이터를 가져오는지 알 필요가 없으며, ApiService나 MockService 등 원하는 함수를 주입할 수 있습니다. 컴포넌트를 설계할 때, 각각의 컴포넌트가 단일한 책임에 맞게 잘 분리되어 있다면, 불필요한 속성(props)이 없는 독립적인 컴포넌트로 구성될 수 있습니다. 그러나 컴포넌트만으로는 페이지를 완성할 수 없습니다. 페이지를 구성하기 위해서는 여러 컴포넌트를 조합(composition)해야 합니다. 이때, 인터페이스 분리 원칙(ISP)과 의존성 역전 원칙(DIP)은 컴포넌트 간의 결합도를 낮추고, 더 유연하게 컴포넌트를 조합할 수 있게 도와주는 중요한 설계 원칙입니다. --- 이렇게 SOLID 원칙에 대한 내용을 정리하고 프론트엔드 개발에서의 활용 가능성을 살펴보았습니다. SOLID 원칙이 법칙이 아니라 원칙이기 때문에, 적용하는 기준이 상황과 개인에 따라 달라질 수 있고, 그 기준이 명확하지 않기 때문에 어렵게 느껴지기는 합니다. 하지만 꾸준히 SOLID 원칙을 염두에 두고 사고하며 개발에 임하면 좋은 코드를 작성하는 개발자로 성장할 수 있을 것이라 생각하기에 항상 인지하며 개발하려고 노력하고 있습니다.