SOLID 구조, 지금 고쳐야 할까 버텨야 할까

시스템에 문제가 생길 때 가장 먼저 떠올리는 해결책은 사람을 바꾸는 일입니다. 개발자를 교체하거나, 팀 구성을 바꾸거나, 새로운 인력을 투입하면 상황이 나아질 것이라 기대합니다.

하지만 많은 조직에서 비슷한 문제가 반복됩니다. 사람이 바뀌어도 일정은 다시 밀리고, 수정 작업은 여전히 부담스럽고, 시간이 지날수록 시스템은 더 다루기 어려워집니다. 이 지점에서 문제는 개인의 역량이나 태도가 아니라 구조에 있다는 사실이 드러나기 시작합니다.

빠른 결정, 단기적인 해결, 당장의 요구를 우선한 선택들이 시간이 지나며 구조로 남고, 그 구조가 다음 작업의 난이도를 결정합니다. 이 과정은 초기에는 잘 보이지 않지만, 운영이 이어질수록 점점 명확해집니다.

이런 상황에서 필요한 것은 더 많은 사람이나 더 빠른 개발이 아니라, 기준입니다. 무엇을 막기 위해 만들어진 원칙인지, 어떤 문제를 반복되지 않게 하기 위한 것인지에 대한 기준 말입니다. 그 기준을 이해하지 못한 채 개선을 시도하면, 또 다른 형태의 문제가 쌓일 뿐입니다.

SOLID란 무엇인가? 

변화와 확장을 전제로 만들어진 설계 원칙

SOLID는 객체지향 설계를 위해 정리된 다섯 가지 원칙의 약자입니다. 로버트 C. 마틴(Robert C. Martin)이 실무에서 반복적으로 발생하던 구조적 문제들을 바탕으로 원칙을 체계화하며 널리 알려졌습니다. 

각각의 원칙은 새로운 개념이라기보다, 여러 프로젝트에서 공통적으로 드러난 실패와 한계를 정리해 하나의 기준으로 묶은 결과에 가깝습니다.

SOLID는 특정 언어나 프레임워크에 종속된 지침이 아닙니다. 어떤 기술 스택을 사용하든 공통적으로 적용할 수 있는 구조적 관점을 제시하며, 코드의 형태보다 시스템이 어떻게 변화에 대응할 수 있는지를 더 중요하게 다룹니다.

이 원칙의 출발점은 처음 잘 만드는 것이 아니라, 시간이 지나도 감당할 수 있는 구조를 유지하는 것입니다. 요구사항이 바뀌고 기능이 확장되는 상황을 전제로 삼아, 이후의 변경과 확장이 시스템 전체를 흔들지 않도록 만드는 데 초점이 맞춰져 있습니다.

SOLID의 다섯 가지 원칙이 공통으로 말하는 것

SOLID는 다섯 개의 원칙을 묶은 이름이지만, 각각이 독립된 규칙처럼 작동하지는 않습니다. 이 원칙들이 공통으로 말하는 것은 하나입니다. 변경이 발생했을 때, 그 영향이 어디까지 퍼지느냐를 통제하자는 기준입니다. 이를 위해 각 원칙은 서로 다른 지점에서 구조를 나눕니다.

S — Single Responsibility Principle(단일 책임 원칙)

하나의 구성 요소는 하나의 책임만 가져야 한다는 원칙입니다. 여기서 말하는 책임은 기능의 개수가 아니라, 변경되는 이유를 의미합니다. 하나의 클래스나 모듈이 여러 이유로 수정된다면, 그만큼 변경 리스크도 함께 커집니다.

• 작은 변경에도 여러 파일을 동시에 수정해야 하는 구조
• 기능 수정이 곧바로 다른 영역의 버그로 이어지는 상황
• 수정 범위를 예측하기 어려워지는 흐름

이 원칙은 변경의 이유를 분리해, 영향 범위를 좁히기 위한 기준입니다.

O — Open/Closed Principle(개방/폐쇄 원칙)

기존 코드를 수정하지 않고도 기능을 확장할 수 있어야 한다는 원칙입니다. 새로운 요구사항이 나올 때마다 이미 안정적으로 동작하던 코드를 고쳐야 한다면, 시스템은 점점 불안정해집니다.

• 기능 추가가 곧 기존 로직 수정으로 이어지는 구조
• 수정할수록 테스트 범위가 넓어지는 상황
• 이전 기능에 대한 신뢰도가 계속 낮아지는 문제

이 원칙은 확장은 열어두되, 기존 구조는 보호하자는 관점을 담고 있습니다.

L — Liskov Substitution Principle(리스코프 치환 원칙)

하위 타입은 언제나 상위 타입을 대체할 수 있어야 한다는 원칙입니다. 구조적으로는 상속 관계를 말하지만, 실제로는 기대했던 동작이 깨지지 않아야 한다는 신뢰의 문제에 가깝습니다.

• 같은 역할을 기대했지만 동작 방식이 다른 구현
• 특정 조건에서만 예외가 발생하는 코드
• 사용 시점마다 예외 처리를 고민해야 하는 구조

이 원칙이 무너지면, 코드는 점점 사용하기 어려워지고 방어 코드가 늘어납니다.

I — Interface Segregation Principle(인터페이스 분리 원칙)

사용하지 않는 기능에 의존하지 않도록 인터페이스를 분리하자는 원칙입니다. 하나의 인터페이스에 너무 많은 역할이 담기면, 작은 변경도 여러 구현에 영향을 줍니다.

• 필요 없는 메서드까지 함께 구현해야 하는 상황
• 특정 기능 변경이 전혀 관계없는 영역까지 흔드는 구조
• 인터페이스 하나가 여러 책임을 떠안는 경우

이 원칙은 의존성을 최소화해, 변경의 파급 범위를 줄이기 위한 기준입니다.

D — Dependency Inversion Principle(의존성 역전 원칙)

구체적인 구현이 아니라, 추상적인 개념에 의존해야 한다는 원칙입니다. 이는 코드 수준의 기술 선택보다, 결합도를 낮추는 설계 방향에 가깝습니다.

• 특정 라이브러리나 구현에 강하게 묶인 구조
• 교체나 테스트가 어려운 의존 관계
• 작은 변경에도 전반적인 수정이 필요한 상황

이 원칙은 구조를 유연하게 만들어, 선택지를 남겨두기 위한 기준입니다.

이 다섯 가지 원칙은 각각 다른 이름을 가지고 있지만, 결국 같은 방향을 가리킵니다. 변경을 없앨 수 없다면, 변경을 관리 가능한 단위로 쪼개자는 것입니다. 이 기준이 지켜질수록 시스템은 시간이 지나도 예측 가능성을 유지할 수 있고, 그렇지 않을수록 구조는 점점 다루기 어려워집니다.

SOLID가 무너지면 나타나는 공통 신호들

SOLID가 무너졌다는 것은 특정 원칙을 어겼다는 의미가 아닙니다. 구조가 변화와 확장을 감당하지 못하는 방향으로 굳어졌다는 뜻에 가깝습니다.

이 상태에서는 코드의 품질보다, 작업 과정에서 문제의 신호가 먼저 드러납니다. 다음과 같은 현상들이 반복된다면 시스템의 구조 점검을 고려해보는 것이 좋습니다.

하나를 고치려면 여러 곳을 동시에 수정해야 한다

작은 부분을 변경하는데도 많은 파일과 로직을 수정해야 하는 상황이 잦아집니다. 책임이 명확히 나뉘지 않은 구조에서 하나의 변경이 연쇄적인 수정으로 이어지며, 작업 범위를 가늠하기 어려워집니다.

새로운 요구사항이 나올수록 일정 예측이 어려워진다

기능이 추가될 때마다 일정 산정이 점점 보수적으로 변합니다. 작업 난이도가 쉬워도 구조 리스크 때문에 일정에 더 큰 영향을 미치기 시작합니다.

• 비슷한 기능인데도 매번 소요 시간이 달라지고
• 예상치 못한 수정이 중간에 계속 발생하며
• 일정에 대한 확신이 점점 줄어듭니다
   

특정 사람이 아니면 건드리기 힘든 영역이 늘어난다

구조가 명확하지 않아 시스템의 일부가 특정 인력의 기억과 경험에 의존하기 시작하고  걀극 코드를 이해하는 데 필요한 맥락은 개인에게 축적됩니다.

• “이 부분은 ○○만 알아요”라는 말이 늘어나고
• 신규 인력이 접근하기 어려워지며
• 작업 분산이 점점 힘들어집니다
   

테스트 · 배포 과정이 점점 불안해진다

구조의 일관성이 무너지면 작은 변경 하나도 어떤 영향을 미칠지 예측하기 어려워집니다. 그 결과 테스트와 배포 과정 전반에 불안 요소가 쌓이기 시작합니다. 배포 전 확인해야 할 항목은 계속 늘어나고, 사소한 수정에도 롤백을 염두에 두게 되면서 배포 자체가 부담스러운 작업이 됩니다.

SOLID는 한 번에 무너지지 않습니다. 잘못된 선택과 과정들이 쌓이면서 구조는 서서히 일관성을 잃고, 결국 작업을 시도하려 해도 손대기 어려워 계속 미루게 됩니다. 그 결과 당장의 기능 구현과 일정 대응에만 집중하는 상태로 흐르기 쉽습니다.

그리고 이 단계에 이르면, 기능을 더 빨리 만드는 것보다 구조를 어떻게 다룰 것인가가 더 중요한 문제가 됩니다.

왜 '알고 있는 것'과 '적용하는 것'이 다를까

SOLID는 대부분의 개발자에게 낯선 개념이 아닙니다. 이름도 알고 있고, 다섯 가지 원칙이 무엇을 의미하는지도 한 번쯤은 들어봤습니다. 하지만 실제 프로젝트에서는 이 원칙이 자연스럽게 적용되지 않는 경우가 훨씬 많습니다. 이는 이해가 부족해서가 아니라, 적용의 조건이 전혀 다르기 때문입니다.

SOLID를 아는 것은 비교적 쉽습니다. 책이나 글을 통해 개념을 익히고, 예제 코드를 보며 원칙이 어떻게 구현되는지 확인할 수 있습니다. 반면 적용하는 것은 전혀 다른 문제입니다. 이미 운영 중인 시스템, 누적된 코드, 촉박한 일정, 계속 변경되는 요구사항 속에서 구조를 판단하고 선택해야 하기 때문입니다.

지금 구조를 유지한 채 기능을 추가할지, 일부를 분리해 확장 경로를 만들지, 손대지 말아야 할 영역은 어디인지 같은 판단은 원칙의 정의만으로는 내려지지 않습니다.

맥락을 읽는 능력이 필요한 이유

SOLID 적용이 어려운 이유는 대부분 기술이 아니라 맥락에 있습니다. 구조를 바꾸는 순간 어떤 리스크가 발생하는지, 변경을 어디까지 허용해야 하는지, 지금 손대는 것이 맞는지 아니면 미루는 것이 더 안전한지 같은 문제는 경험 없이는 가늠하기 어렵습니다. 그래서 같은 SOLID를 알고 있어도, 프로젝트마다 선택은 달라집니다.

또 하나의 차이는 책임의 무게입니다. SOLID를 적용한다는 것은 단순히 코드를 바꾸는 일이 아니라, 이후의 유지보수와 확장에 대한 책임을 함께 지는 선택입니다. 이 책임을 고려하지 않으면 원칙은 쉽게 이론으로만 남게 됩니다.

구조를 분리했을 때 생길 추가 작업, 단기 일정에 미치는 영향, 팀 전체에 미칠 파급 효과를 함께 고려해야 비로소 적용이라는 단계로 넘어갈 수 있습니다.

결국 SOLID는 지식의 문제가 아니라 경험의 문제에 가깝습니다. 여러 구조를 겪어보고, 잘못된 선택이 어떤 결과로 이어지는지 직접 마주해본 사람일수록 원칙을 상황에 맞게 해석할 수 있습니다. 알고 있느냐보다, 어떤 상황에서 어떻게 적용해봤는가가 더 중요한 이유입니다.

PM은 SOLID를 이렇게 활용한다

PM에게 SOLID는 코드를 평가하는 기준이 아니라, 의사결정을 정리하는 도구에 가깝습니다. 구현 방법을 지시하기보다, 요구사항과 일정, 리스크를 구조 관점에서 설명하고 선택을 돕는 데 쓰입니다.

요구사항을 난이도가 아니라 구조 영향으로 분류한다

기능 요청이 들어오면 얼마나 복잡한지보다 기존 구조에 어떤 변화를 요구하는지부터 봅니다. 변경 이유가 하나인지 여러 개인지, 기존 로직을 수정해야 하는지 확장으로 붙일 수 있는지, 특정 구현에 더 강하게 묶이게 되는지를 먼저 확인합니다.

이렇게 분류하면 일정 증가의 이유를 감각이 아니라 구조적 근거로 설명할 수 있습니다. "이 기능은 여러 책임이 섞여 있어서 수정 범위가 넓어집니다"라고 말할 수 있는 것과 "복잡해서 시간이 더 걸립니다"라고 말하는 것은 전혀 다릅니다.

설계 리뷰를 지적이 아닌 질문으로 바꾼다

원칙을 강요하는 대신, 판단을 끌어내는 질문으로 씁니다. 이 변경은 기존 코드 수정 없이 확장 가능한가, 이 책임은 다른 변경 이유와 섞이지 않았는가, 나중에 교체해야 할 때 무엇이 가장 어려워질까 같은 질문입니다.

질문만으로도 팀은 방어적이지 않게 구조를 점검하게 됩니다. 지적은 저항을 만들지만, 질문은 스스로 판단하게 만듭니다.

리팩토링 범위를 정하는 기준으로 활용한다

SOLID는 "다 고치자"가 아니라 "여기부터 자르자"를 정하는 기준이 됩니다. 어디를 먼저 개선해야 효과가 큰지 판단할 수 있게 해줍니다.

전체 개선이 아니라 가장 비용이 큰 결합부터 다룹니다. 테스트가 유난히 어려운 결합, 변경 요청이 자주 몰리는 모듈, 작은 수정에도 연쇄 변경이 발생하는 지점을 우선적으로 봅니다.

일정과 리스크를 설명하는 언어로 사용한다

왜 일정이 늘어나는지, 왜 지금은 손대지 말아야 하는지를 기술 용어 없이 설명할 수 있습니다. 지금 바꾸면 영향 범위가 커지는 구조인지, 미루면 더 비싸지는 결합인지, 어느 선택이 리스크를 낮추는지를 명확하게 전달할 수 있습니다.

특히 의사결정자와의 커뮤니케이션에서 효과적입니다. "구조적으로 결합이 강해서 변경 범위가 넓습니다"는 "복잡해서 어렵습니다"보다 훨씬 설득력 있는 근거가 됩니다.

인력 선택의 기준으로 쓴다

SOLID를 안다는 것보다 다뤄본 경험을 확인합니다. 원칙이 깨져 일정이 흔들린 사례가 있는지, 일부만 개선해 효과를 낸 경험이 있는지, 개선 이후 유지까지 고려해본 적이 있는지를 봅니다.

이 기준은 내부 배분에도, 외부 인력 선택에도 그대로 적용됩니다. 원칙을 아는 것과 상황에 맞게 적용해본 것은 전혀 다른 역량이기 때문입니다.

구조문제, 해결하려면 어떻게 접근해야 할까

SOLID가 무너진 구조를 마주했을 때 중요한 것은 지금 어떤 조건에서 어떤 선택이 가능한지를 구분하는 일입니다. 상황에 따라 접근 방식은 달라질 수 있고, 각각의 선택에는 분명한 장점과 한계가 존재합니다.

내부에서 작업을 이어가는 경우

이미 내부 팀이 시스템을 가장 잘 이해하고 있고, 일정과 운영을 함께 책임지고 있다면 구조 개선을 내부에서 진행하는 선택도 가능합니다. 다만 이 경우에는 몇 가지 전제가 필요합니다.

• 구조 개선을 위한 명확한 시간과 범위가 확보되어 있는지, 
• 기능 개발과 구조 개선을 동시에 감당할 여력이 있는지, 
• SOLID를 원칙이 아니라 상황에 맞게 적용해본 경험이 있는지를 먼저 확인해야 합니다.

이 조건이 충족되지 않으면, 구조 개선은 쉽게 뒷전으로 밀립니다. 당장의 요구사항 대응과 일정 관리가 우선되기 때문에, 구조를 다루는 작업은 계속 미뤄지고 임시 대응이 반복되기 쉽습니다.

내부에서 해결한다는 선택은 시간과 여유, 그리고 경험이 동시에 있을 때 현실적인 옵션이 됩니다.

외부 인력을 활용하는 경우

다른 선택지는 구조를 다뤄본 경험이 있는 외부 인력을 활용하는 방식입니다. 내부 역량이 부족해서라기보다, 지금 상황에서 필요한 역할이 다르기 때문에 선택됩니다.

운영과 일정에서 한 발 떨어진 상태에서 구조를 판단할 수 있고, 여러 프로젝트에서 비슷한 문제를 다뤄본 경험을 바로 활용할 수 있으며, 단기간에 구조의 방향성을 정리하는 데 집중할 수 있습니다.

특히 구조가 이미 복잡해진 상태에서는, 처음부터 모두 고치기보다 어디까지 손대야 하는지 판단하는 일이 더 중요합니다. 이럴 때는 내부에서 장기간 학습하며 수행하기보다, 경험을 가진 인력이 개입해 방향을 잡는 방식이 더 효율적인 경우가 많습니다.

구조 개선, 언제 시작해야 할까

구조 개선은 문제가 커진 뒤에 시작하는 작업이 아닙니다. 다만 그렇다고 해서, 모든 상황에서 즉시 착수해야 하는 일도 아닙니다. 중요한 것은 지금이 구조를 다룰 시점인지 판단하는 기준입니다.

다음과 같은 신호가 반복된다면, 구조 개선을 검토할 시점에 가깝습니다.

1) 구조 문제의 신호가 분명하게 보이기 시작할 때입니다. 기능 추가나 수정 과정에서 영향 범위를 예측하기 어렵고, 작은 변경에도 불안이 커지는 상황이 반복됩니다.

2) 팀 내부만으로 방향을 잡기 어려울 때입니다. 문제는 인식하고 있지만, 어디까지 손대야 할지 합의가 되지 않거나 판단이 계속 미뤄지는 경우입니다.

3) 일정 압박과 구조 개선을 동시에 다뤄야 할 때입니다. 운영과 배포를 멈출 수 없는 상태에서, 구조 문제까지 함께 판단해야 하는 시점입니다.

반대로, 단기간에 종료될 프로젝트이거나 구조 변경이 오히려 리스크가 되는 상황이라면, 당장 구조 개선이 최선의 선택이 아닐 수도 있습니다. 구조 개선은 필요할 때 시작해야 의미가 있습니다.

이런 상황이라면, 구조 개선 경험이 있는 프리랜서와 함께 시작하는 것도 방법입니다.

구조는 한 번에 완성되지 않는다

구조 개선의 목표는 완벽한 설계를 만드는 것이 아닙니다. 지금의 문제를 감당할 수 있는 수준으로 구조를 정리하고, 다음 변경을 준비하는 데에 있습니다. 한 번의 작업으로 끝내려 하면 오히려 부담이 커집니다.

구조 개선은 완결이 아니라 과정입니다. 상황이 바뀌면 다시 조정해야 하고, 개선은 항상 이어집니다. 중요한 것은 이 문제를 혼자 안고 가지 않는 것입니다. 구조를 다뤄본 경험이 있는 시선과 함께할 때, 판단은 훨씬 명확해집니다.

26년의 데이터와 노하우로 

구축  ·  연동  ·  운영에 필요한 IT 전문가를 매칭합니다.

이랜서는 우리나라 최대 IT 프리랜서 매칭 플랫폼입니다. 26년간 8만 건 이상의 IT 프로젝트에 기업의 시스템 환경과 보안 요구 수준에 맞는 IT 프리랜서를 검증해 매칭해 왔습니다.

SOLID 구조 개선처럼 설계와 판단 경험이 필요한 영역에서는 단순한 개발 인력이 아니라 구조를 다뤄본 경험을 갖춘 전문가의 시선이 중요합니다.

• 프로젝트 등록 후 24시간 내, 구조 개선 경험 기반 IT 프리랜서 추천
• 1.5억 건 데이터, 350만 건 평가를 기반으로 검증된 인력 풀
• 프로젝트 재의뢰율 98%, 삼성·LG·SK 등 주요 기업과의 협업 경험

구조 개선은 한 번 고치고 끝나는 작업이 아닙니다. 시스템의 변경 이력과 팀의 운영 방식을 함께 이해해야 하는 영역이라면, 경험 있는 전문가와 함께 시작하는 것이 리스크를 줄이는 가장 빠른 방법입니다.

지금 이랜서에 프로젝트를 등록하고, 조직에 맞는 구조 개선 전문가를 만나보세요.