디자인 패턴의 그림자, 안티패턴을 통해 배우는 잘못된 코드 습관

1. 안티패턴이란 무엇인가요?

소프트웨어 개발을 하다 보면 “이게 맞는 방향인가?”라는 고민을 끊임없이 하게 됩니다. 그런데 처음엔 좋아 보였던 방법이, 시간이 지나면서 점점 코드를 복잡하게 만들고 유지보수를 어렵게 한다면요? 바로 그런 현상이 **안티패턴(Anti-pattern)**입니다. 안티패턴은 ‘처음엔 효과적으로 보이지만, 장기적으로는 심각한 문제를 초래하는 나쁜 설계 습관이나 구현 방식’을 의미합니다. 마치 설탕처럼 처음엔 달콤하지만, 시간이 지나면 건강을 해치는 것처럼요. 디자인 패턴이 ‘좋은 예시’라면, 안티패턴은 ‘나쁜 본보기’라고 할 수 있습니다. 중요한 건, 단순히 실수가 아니라 의도적으로 반복되는 잘못된 방식이라는 점입니다. 오늘은 개발자들이 자주 빠지는 안티패턴 10가지를 총정리해 드리겠습니다.

2. 스파게티 코드(Spaghetti Code)

이름부터 무언가 꼬여 있다는 느낌이 드시죠? 스파게티 코드는 기능을 추가할 때마다 코드가 꼬이고 얽혀, 어느 부분을 수정하면 다른 곳이 터져나오는 악몽 같은 상태를 말합니다. 원인은 명확합니다. 모듈화 부족, 함수의 책임이 명확하지 않음, 변수와 흐름이 난잡함. 개발자는 수정하려고 손을 대면 대체 어디서 터질지 몰라서 코드 건드리는 게 두려워지죠. 마치 거미줄에 걸린 것처럼요. 특히 빠르게 결과를 내야 할 때 급하게 짜놓은 코드가 어느새 스파게티가 되는 경우가 많습니다. 이럴 땐 작은 기능이라도 책임을 분리해서 설계하는 SOLID 원칙을 지켜주는 게 예방의 지름길입니다.

3. 갓 클래스(God Object / God Class)

모든 걸 다 아는 전지전능한 클래스, 이름만 보면 대단해 보이지만 실제로는 시스템 전체를 위험에 빠뜨리는 괴물입니다. 하나의 클래스에 모든 기능, 데이터, 로직을 때려 넣는 방식은 나중에 유지보수가 거의 불가능해지며, 다른 클래스와의 의존도가 높아져 단 하나의 변경에도 연쇄적인 문제가 발생하게 됩니다. 갓 클래스는 테스트도 어렵고, 협업도 힘들며, 결국 전체 시스템을 블랙박스로 만들어버립니다. 하나의 클래스는 단일 책임을 가져야 하고, 여러 개로 나누어서 유연하게 설계해야 합니다.

4. 하드 코딩(Hard Coding)

“어차피 지금은 이렇게 쓰면 되잖아요?” 하며 하드 코딩을 남발하셨던 적 있으신가요? 하드 코딩은 값을 외부에서 주입하지 않고, 코드 안에 직접 상수를 박아 넣는 방식입니다. 예를 들어 환율을 코드 안에 1300이라고 직접 입력해두면, 환율이 바뀔 때마다 코드를 열어 수정해야 하는 상황이 옵니다. 설정 파일이나 환경 변수, 혹은 DI(Dependency Injection)를 통해 외부에서 유연하게 주입해주는 게 바람직합니다. 하드 코딩은 그 순간만 편할 뿐, 나중에 시스템 전체를 손봐야 하는 재앙을 불러올 수 있습니다.

5. 라바 흐름(Lava Flow)

라바는 처음엔 유동적이지만, 굳어버리면 주변을 덮고 움직이기도 어렵게 만듭니다. 소프트웨어에서도 비슷한 현상이 있습니다. 초기 프로토타입 때 만든 임시 코드가 정식 릴리스까지 살아남아 시스템의 일부가 되어버리는 현상, 이것이 바로 라바 흐름입니다. 테스트도 안 됐고, 이유도 모르는 코드인데 없애자니 뭔가 터질까봐 건드릴 수 없는 상태가 되죠. 이런 현상은 주로 문서화 부족, 코드 리뷰 생략, 명확하지 않은 책임 분리에 의해 발생합니다. 기술 부채를 늘리는 주범이기 때문에, 정기적으로 리팩토링과 문서화를 해주는 문화가 필요합니다.

6. 복사-붙여넣기 프로그래밍(Copy-and-Paste Programming)

“시간 없는데, 이거 복사해서 붙이면 되겠지”라는 생각으로 비슷한 코드를 복사해 여기저기 붙여 넣는 방식. 이는 장기적으로 코드 중복을 양산하고, 수정 시 한 곳만 고치면 되는 걸 여러 군데 다 찾아야 하는 상황을 만들게 됩니다. 특히 유지보수 시 버그가 생기기 쉬워지며, 코드의 일관성이 무너집니다. 반복되는 코드는 함수나 클래스로 추상화해서 재사용성을 높여주는 것이 정석입니다. 귀찮음을 선택하면, 결국 그 대가는 몇 배로 돌아오게 되어 있습니다.

7. 골든 해머(Golden Hammer)

‘모든 문제를 하나의 도구로 해결하려는 경향’, 바로 골든 해머입니다. 예를 들어, 어느 프로젝트든 무조건 마이크로서비스 아키텍처(MSA)를 도입한다든가, 객체지향 패턴만을 고집하는 경우가 이에 해당합니다. 문제는 모든 상황에 같은 도구가 통하지 않는다는 점입니다. 때로는 단순한 구조가 효율적일 수 있으며, 과도한 패턴 적용은 오히려 프로젝트를 무겁게 만듭니다. 문제에 맞는 도구를 선택하는 유연함, 그리고 패턴을 맹신하지 않는 균형 잡힌 시각이 필요합니다.

8. 순환 참조(Circular Dependency)

클래스 A가 클래스 B를 참조하고, B가 다시 A를 참조하는 구조. 이런 순환 참조는 시스템을 복잡하게 만들고, 종종 컴파일 오류나 런타임 예외까지 야기합니다. 특히 규모가 커질수록 의존성 관리가 어려워지고, 테스트가 까다로워집니다. 순환 참조를 피하려면 인터페이스 분리, 의존성 역전 원칙(DIP)을 활용하여 결합도를 낮추는 방식으로 구조를 설계해야 합니다. 가끔 ‘왜 의존성 주입이 중요한가요?’라는 질문에 대한 가장 실감 나는 예시가 바로 이 순환 참조 문제입니다.

9. 마법 숫자(Magic Number)

코드 안에 무작정 숫자가 들어가 있으면, 그 숫자의 의미를 추론하기 어려운 경우가 많습니다. 예: if (score > 70) {…}. 여기서 70이 의미하는 바가 ‘합격 기준’인지 ‘경고 임계치’인지 모호하죠. 이럴 땐 상수를 정의하고 의미 있는 이름을 부여해주는 게 좋습니다. const PASS_THRESHOLD = 70;처럼요. 마법 숫자는 코드의 가독성과 유지보수성을 심각하게 해칩니다. 작은 정리 하나가 프로젝트 전체를 이해하기 쉽게 만들어주는 법입니다.

10. 미끄러운 경사(Slippery Slope)

“이번엔 그냥 이렇게 하자”라는 안일한 선택이 반복되면, 시스템 전반이 엉망이 되는 경우가 있습니다. 바로 미끄러운 경사 안티패턴입니다. 처음엔 작고 사소한 예외였지만, 그게 반복되면 어느새 시스템 전체가 일관성을 잃고, 규칙 없이 운영되게 됩니다. 코딩 컨벤션, 테스트 습관, 문서화 등의 규칙은 한 번만 깨져도 관성처럼 무너지기 시작합니다. 이 안티패턴을 방지하려면, 개발 팀의 원칙과 규율을 세우고 모두가 이를 존중해야 합니다. 결국 기술이 아닌 사람의 태도가 시스템의 품질을 좌우하니까요.

마무리하며

안티패턴은 단순히 ‘나쁜 코드’ 그 이상입니다. 개발자의 판단, 습관, 문화가 복합적으로 반영된 결과물이지요. 하지만 알아차리고 고치려는 노력이 있다면, 얼마든지 더 나은 방향으로 나아갈 수 있습니다. 마치 실수에서 배우며 성장하는 인간처럼, 소프트웨어도 그렇게 진화합니다. 여러분의 프로젝트는 어떤가요? 혹시 지금도 스파게티 코드와 씨름하고 계신가요? 이 글이 조금이나마 안티패턴을 피하고, 더 건강한 시스템을 구축하는 데 도움이 되었으면 좋겠습니다.

자주 묻는 질문 (FAQs)
Q1. 디자인 패턴과 안티패턴의 가장 큰 차이점은 무엇인가요?
A1. 디자인 패턴은 검증된 좋은 설계 방식이고, 안티패턴은 반복되면 문제가 되는 잘못된 습관이나 구조입니다.

Q2. 안티패턴을 피하려면 어떻게 해야 하나요?
A2. 코드 리뷰, 리팩토링, 테스트 자동화, 명확한 책임 분리 등의 개발 문화가 중요합니다.

Q3. 실무에서 가장 흔히 보는 안티패턴은 무엇인가요?
A3. 스파게티 코드, 하드 코딩, 갓 클래스가 실무에서 자주 등장하는 대표적 안티패턴입니다.

Q4. 안티패턴을 쓰면 왜 문제가 되나요?
A4. 유지보수 어려움, 버그 증가, 협업 문제, 시스템 전체 불안정성 등 다양한 부작용이 생깁니다.

Q5. 안티패턴은 무조건 나쁜 건가요?
A5. 꼭 그렇진 않습니다. 특정 상황에선 임시 해결책이 될 수도 있지만, 장기적으로는 반드시 개선이 필요합니다.