dsgnmstr; Design Monster

[태그:] DRY

  • 코드 설계 (Code Design): 좋은 코드는 어떻게 만들어지는가? 아키텍처와 구현을 잇는 예술

    코드 설계 (Code Design): 좋은 코드는 어떻게 만들어지는가? 아키텍처와 구현을 잇는 예술

    목차

    1. 들어가며: 단순한 코딩을 넘어, 생각의 구조를 만드는 기술
    2. 코드 설계란 무엇인가?: 아키텍처와 구현 사이의 다리
      • 코드 설계의 정의: 가독성, 유지보수성, 재사용성을 위한 청사진
      • 아키텍처 설계와의 관계: 숲과 나무의 비유
    3. 좋은 코드 설계를 위한 핵심 원칙: SOLID
      • S: 단일 책임 원칙 (Single Responsibility Principle)1
      • O: 개방-폐쇄 원칙 (Open/Closed Principle)2
      • L: 리스코프 치환 원칙 (Liskov Substitution Principle)3
      • I: 인터페이스 분리 원칙 (Interface Segregation Principle)4
      • D: 의존관계 역전 원칙 (Dependency Inversion Principle)5
    4. 실용적인 코드 설계 철학: KISS, DRY, YAGNI
      • KISS 원칙 (Keep It Simple, Stupid)
      • DRY 원칙 (Don’t Repeat Yourself)
      • YAGNI 원칙 (You Aren’t Gonna Need It)
    5. 코드 설계를 현실로 만드는 도구: 디자인 패턴
    6. 결론: 코드를 통해 생각을 디자인하다

    1. 들어가며: 단순한 코딩을 넘어, 생각의 구조를 만드는 기술

    프로그래밍을 처음 배울 때, 우리의 주된 목표는 ‘동작하는’ 코드를 만드는 것입니다. 원하는 결과가 화면에 출력되거나 기능이 실행되면 큰 성취감을 느낍니다. 하지만 소프트웨어 개발의 여정을 계속하다 보면, ‘단순히 동작하는 코드’와 ‘잘 만들어진 코드’ 사이에는 거대한 간극이 존재한다는 사실을 깨닫게 됩니다. 6개월 전 내가 작성한 코드를 이해하지 못해 괴로워하거나, 작은 기능 하나를 수정했을 뿐인데 예상치 못한 곳에서 버그가 터져 나오는 경험은 모든 개발자가 한 번쯤 겪는 성장통입니다. 이 고통의 근본적인 원인은 바로 ‘코드 설계(Code Design)’의 부재에 있습니다.

    코드 설계는 단순히 문법에 맞춰 코드를 작성하는 행위를 넘어, 미래의 변경 가능성을 예측하고, 다른 개발자와의 협업을 고려하며, 시스템 전체의 건강성을 유지하기 위해 코드의 구조를 의식적으로 조직하고 체계화하는 지적인 활동입니다. 이는 마치 건축가가 건물의 하중 분산, 동선, 향후 증축 가능성까지 고려하여 내부 구조를 설계하는 것과 같습니다. 어떤 클래스가 어떤 책임을 져야 하는지, 모듈 간의 의존성은 어떻게 관리할 것인지, 코드의 중복은 어떻게 제거할 것인지에 대한 깊이 있는 고민이 바로 코드 설계의 핵심입니다.

    이 글에서는 소프트웨어 아키텍처라는 거시적인 설계와 실제 코드를 작성하는 미시적인 구현 사이에서, 견고하고 유연한 소프트웨어를 만드는 결정적인 역할을 하는 ‘코드 설계’의 세계를 탐험하고자 합니다. 객체 지향 설계의 금과옥조로 불리는 SOLID 원칙부터, 실용적인 개발 철학인 KISS, DRY, YAGNI에 이르기까지, 좋은 코드 설계를 위한 핵심적인 원리들을 구체적인 예시와 함께 파헤쳐 볼 것입니다. 이 글을 통해 여러분은 단순히 키보드를 두드리는 코더(Coder)를 넘어, 생각의 구조를 코드로 아름답게 빚어내는 진정한 설계자(Designer)로 거듭나는 길을 발견하게 될 것입니다.

    2. 코드 설계란 무엇인가?: 아키텍처와 구현 사이의 다리

    코드 설계를 제대로 이해하기 위해서는 먼저 소프트웨어 설계의 전체 스펙트럼에서 코드 설계가 차지하는 위치를 명확히 해야 합니다.

    코드 설계의 정의: 가독성, 유지보수성, 재사용성을 위한 청사진

    코드 설계는 소프트웨어 아키텍처가 제시한 큰 방향성 안에서, 개별 클래스, 모듈, 함수 등의 내부 구조와 그들 간의 상호작용 방식을 구체적으로 결정하는 활동입니다. 주요 목표는 다음 세 가지로 요약할 수 있습니다.

    • 가독성 (Readability): 코드는 컴퓨터뿐만 아니라 사람, 즉 미래의 나 자신과 동료 개발자가 쉽게 읽고 이해할 수 있어야 합니다. 변수나 함수의 이름이 명확하고, 로직의 흐름이 논리적이며, 구조가 일관성이 있을 때 가독성은 높아집니다.
    • 유지보수성 (Maintainability): 소프트웨어는 끊임없이 변화합니다. 버그를 수정하고, 새로운 기능을 추가하며, 성능을 개선하는 과정에서 기존 코드를 쉽게 수정하고 확장할 수 있어야 합니다. 좋은 코드 설계는 변경의 영향을 최소화하여 유지보수 비용을 줄여줍니다.
    • 재사용성 (Reusability): 한번 작성한 코드는 다른 곳에서도 활용될 수 있어야 효율적입니다. 특정 기능이나 로직을 독립적인 모듈이나 클래스로 잘 분리해두면, 코드 중복을 피하고 개발 속도를 높일 수 있습니다.

    결국 코드 설계는 ‘지금 당장 동작하는가’를 넘어, ‘시간이 지나도 건강하게 살아남을 수 있는가’에 대한 질문에 답하는 과정입니다.

    아키텍처 설계와의 관계: 숲과 나무의 비유

    소프트웨어 아키텍처 설계와 코드 설계를 비유하자면, 아키텍처 설계는 숲 전체의 구성을 계획하는 것이고, 코드 설계는 그 숲을 이루는 개별 나무들을 건강하고 아름답게 가꾸는 것과 같습니다.

    아키텍처 설계는 시스템을 어떤 큰 단위(예: 마이크로서비스, 레이어)로 나눌 것인지, 이 단위들이 어떤 통신 방식을 사용할 것인지, 어떤 데이터베이스를 선택할 것인지 등 시스템의 근간이 되는 거시적인 구조를 결정합니다. 반면, 코드 설계는 아키텍처가 정의한 각 단위의 내부로 들어가, 그 안에서 클래스들이 어떤 책임을 가질지, 메서드들의 시그니처는 어떠해야 할지, 상속이나 인터페이스를 어떻게 활용하여 관계를 맺을지 등 미시적인 구조를 다룹니다.

    아무리 훌륭한 나무(좋은 코드)가 많아도 숲의 구성(아키텍처)이 엉망이면 길을 잃기 쉽고, 반대로 숲의 구성이 좋아도 개별 나무들이 병들어 있다면 그 숲은 건강할 수 없습니다. 이처럼 아키텍처 설계와 코드 설계는 서로 다른 추상화 수준에서 소프트웨어의 품질을 책임지는, 상호 보완적인 관계에 있습니다.

    3. 좋은 코드 설계를 위한 핵심 원칙: SOLID

    객체 지향 프로그래밍(OOP)에서 좋은 코드 설계를 위해 반드시 따라야 할 다섯 가지 기본 원칙을 앞 글자를 따서 SOLID라고 부릅니다. 이 원칙들은 로버트 C. 마틴(Uncle Bob)에 의해 널리 알려졌으며, 유연하고 유지보수하기 쉬운 시스템을 만드는 데 결정적인 역할을 합니다.

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

    “하나의 클래스는 단 하나의 변경 이유만을 가져야 한다.” 즉, 하나의 클래스는 하나의 책임(기능)에만 집중해야 한다는 원칙입니다. 예를 들어, Employee 클래스가 직원의 정보를 관리하는 책임과 해당 정보를 데이터베이스에 저장하는 책임을 모두 가지고 있다면, 이는 단일 책임 원칙을 위반한 것입니다. 직원의 정보 구조가 변경되어도 클래스를 수정해야 하고, 데이터베이스 저장 방식이 변경되어도 클래스를 수정해야 하므로 ‘두 가지 변경 이유’가 생기기 때문입니다. 올바른 설계는 Employee 클래스와 EmployeeRepository 클래스로 책임을 분리하는 것입니다. 이렇게 하면 각 클래스의 응집도(Cohesion)가 높아지고, 한 부분의 변경이 다른 부분에 미치는 영향을 최소화할 수 있습니다.

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

    “소프트웨어 요소(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만, 변경에 대해서는 닫혀 있어야 한다.” 새로운 기능을 추가할 때 기존 코드를 수정하지 않고도 시스템을 확장할 수 있어야 한다는 의미입니다. 이는 주로 추상화(Abstraction)와 다형성(Polymorphism)을 통해 달성됩니다. 예를 들어, 결제 시스템에서 다양한 결제 수단(신용카드, 계좌이체, 간편결제)을 처리해야 할 때, PaymentProcessor가 각 결제 방식의 구체적인 클래스에 직접 의존한다면 새로운 결제 수단이 추가될 때마다 PaymentProcessor의 코드를 수정해야 합니다. 하지만 Payable이라는 인터페이스를 만들고, 모든 결제 방식 클래스가 이 인터페이스를 구현하도록 설계하면, PaymentProcessor는 Payable 인터페이스에만 의존하게 됩니다. 이제 새로운 결제 수단이 추가되더라도 기존 코드는 전혀 변경할 필요 없이 새로운 클래스를 추가하기만 하면 되므로 ‘확장에는 열려 있고, 변경에는 닫혀 있는’ 구조가 됩니다.

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

    “서브타입(자식 클래스)은 언제나 그것의 기반 타입(부모 클래스)으로 교체될 수 있어야 한다.” 즉, 자식 클래스는 부모 클래스의 역할을 완벽하게 수행할 수 있어야 하며, 자식 클래스를 사용한다고 해서 프로그램의 정확성이 깨져서는 안 된다는 원칙입니다. 예를 들어, Rectangle(직사각형) 클래스를 상속받는 Square(정사각형) 클래스가 있다고 가정해 봅시다. Rectangle에는 setWidth와 setHeight 메서드가 있습니다. Square는 너비와 높이가 항상 같아야 하므로, setWidth를 호출하면 높이도 같이 변경하고, setHeight를 호출하면 너비도 같이 변경하도록 오버라이드(Override)할 수 있습니다. 하지만 이는 리스코프 치환 원칙을 위반할 수 있습니다. Rectangle을 기대하는 어떤 코드가 setWidth(5)와 setHeight(4)를 차례로 호출했을 때 넓이가 20이 되기를 기대했지만, Square 객체가 전달되면 넓이가 16(4×4)이 되어 예기치 않은 동작을 유발하기 때문입니다. 이는 상속 관계가 논리적으로 타당한지 신중하게 고려해야 함을 시사합니다.

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

    “클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강요되어서는 안 된다.” 즉, 하나의 거대한 인터페이스보다는, 특정 클라이언트를 위한 여러 개의 작은 인터페이스로 분리하는 것이 더 좋다는 원칙입니다. 예를 들어, 복합기(프린트, 스캔, 팩스 기능)를 위한 MultiFunctionMachine 인터페이스가 print(), scan(), fax() 메서드를 모두 가지고 있다고 가정해 봅시다. 만약 어떤 클라이언트가 오직 프린트 기능만 필요로 함에도 불구하고 이 인터페이스를 구현해야 한다면, 사용하지도 않는 scan()과 fax() 메서드를 울며 겨자 먹기로 구현해야 합니다. 이는 불필요한 의존성을 만듭니다. 올바른 설계는 Printable, Scannable, Faxable이라는 작은 인터페이스들로 분리하고, 복합기 클래스는 이 세 인터페이스를 모두 구현하며, 프린터만 필요한 클라이언트는 Printable 인터페이스에만 의존하도록 하는 것입니다.

    D: 의존관계 역전 원칙 (Dependency Inversion Principle)

    “상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다. 또한, 추상화는 세부 사항에 의존해서는 안 되며, 세부 사항이 추상화에 의존해야 한다.” 이 원칙은 전통적인 의존성 흐름을 ‘역전’시키는 것을 의미합니다. 예를 들어, ReportGenerator(상위 모듈)가 MySQLDatabaseReader(하위 모듈)에 직접 의존한다면, 데이터베이스를 Oracle로 변경할 때 ReportGenerator의 코드를 수정해야 합니다. 이는 유연하지 못한 설계입니다. 의존관계 역전 원칙에 따르면, ReportGenerator는 구체적인 MySQLDatabaseReader가 아닌, DatabaseReader라는 추상 인터페이스에 의존해야 합니다. 그리고 MySQLDatabaseReader와 OracleDatabaseReader가 모두 이 DatabaseReader 인터페이스를 구현하도록 만듭니다. 이렇게 하면 상위 모듈과 하위 모듈 모두 추상화에 의존하게 되며, 하위 모듈의 구체적인 구현이 변경되어도 상위 모듈은 영향을 받지 않는 유연한 구조를 만들 수 있습니다. 이는 제어의 역전(IoC)과 의존성 주입(DI) 패턴의 이론적 기반이 됩니다.

    4. 실용적인 코드 설계 철학: KISS, DRY, YAGNI

    SOLID가 다소 학문적이고 구조적인 원칙이라면, 실제 개발 현장에서 매일 마주하는 코드에 적용할 수 있는 더 실용적이고 간결한 철학들도 있습니다.

    KISS 원칙 (Keep It Simple, Stupid)

    “단순하게, 바보야!”라는 다소 직설적인 이름의 이 원칙은 불필요한 복잡성을 피하고, 가능한 한 가장 간단하고 명료한 방법으로 문제를 해결하라는 가르침입니다. 개발자들은 종종 미래의 모든 가능성을 대비하여 과도하게 복잡한 설계나 불필요한 추상화 계층을 만드는 경향이 있습니다. 하지만 이러한 ‘오버 엔지니어링(Over-engineering)’은 오히려 코드의 이해와 수정을 더 어렵게 만듭니다. KISS 원칙은 “더 이상 뺄 것이 없을 때” 완벽함에 가까워진다는 미니멀리즘의 철학과도 통합니다. 복잡한 로직이 있다면, 더 간단한 알고리즘으로 대체할 수 없는지, 여러 클래스로 나눈 것이 오히려 불필요한 파편화를 만든 것은 아닌지 항상 되돌아보아야 합니다.

    DRY 원칙 (Don’t Repeat Yourself)

    “스스로를 반복하지 말라”는 이 원칙은 시스템 내의 모든 지식 조각은 단일하고, 모호하지 않으며, 권위 있는 표현을 가져야 한다는 의미입니다. 이는 단순히 코드의 복사-붙여넣기를 피하라는 것을 넘어, 동일한 로직이나 정보가 여러 곳에 중복되어 표현되는 것을 경계하라는 더 넓은 개념입니다. 예를 들어, 특정 비즈니스 규칙(예: VIP 고객 할인율 10%)이 코드 여러 곳에 0.1이라는 매직 넘버(Magic Number)로 하드코딩되어 있다면, 할인율이 변경될 때 모든 곳을 찾아 수정해야 하며, 하나라도 누락하면 버그가 발생합니다. 올바른 방법은 이 값을 VIP_DISCOUNT_RATE라는 이름의 상수로 한 곳에 정의하고, 모든 곳에서 이 상수를 참조하도록 하는 것입니다. 중복을 제거하고 단일 진실 공급원(Single Source of Truth)을 유지하는 것은 유지보수성의 핵심입니다.

    YAGNI 원칙 (You Ain’t Gonna Need It)

    “넌 그게 필요 없을걸”이라는 이 원칙은 지금 당장 필요하지 않은 기능은 만들지 말라는 익스트림 프로그래밍(XP)의 원칙 중 하나입니다. KISS 원칙과 마찬가지로 오버 엔지니어링을 경계하며, “언젠가 필요할지도 모른다”는 막연한 추측만으로 코드를 추가하는 것을 지양합니다. 미래를 예측하여 유연한 구조를 만드는 것은 중요하지만, 그것이 실제로 사용되지 않을 가능성이 높은 기능을 미리 구현하는 것을 정당화하지는 않습니다. 불필요한 기능은 개발 시간을 낭비할 뿐만 아니라, 시스템의 복잡성을 높이고, 테스트와 유지보수 대상을 늘리는 부채가 될 뿐입니다. YAGNI는 현재의 요구사항에 집중하고, 꼭 필요한 기능만을 단순하고 명확하게 구현할 것을 강조합니다.

    5. 코드 설계를 현실로 만드는 도구: 디자인 패턴

    앞서 설명한 설계 원칙들이 ‘무엇을 해야 하는가’에 대한 철학과 방향성을 제시한다면, 디자인 패턴(Design Pattern)은 ‘어떻게 할 것인가’에 대한 구체적인 해결책을 제공합니다. 디자인 패턴은 과거의 소프트웨어 개발자들이 특정 유형의 문제를 해결하면서 발견한, 재사용 가능한 설계의 정수(精髓)입니다.

    예를 들어, ‘개방-폐쇄 원칙’을 구현하고 싶을 때 전략 패턴(Strategy Pattern)을 사용할 수 있습니다. 알고리즘의 주요 골격은 유지하되, 세부적인 알고리즘을 동적으로 교체할 수 있게 해주는 이 패턴은 새로운 기능을 추가할 때 기존 코드의 수정을 방지하는 대표적인 방법입니다. 또한, ‘의존관계 역전 원칙’을 적용하여 모듈 간의 결합도를 낮추고 싶을 때 팩토리 패턴(Factory Pattern)이나 의존성 주입(Dependency Injection)을 사용할 수 있습니다.

    디자인 패턴은 모든 문제에 대한 만병통치약이 아니며, 패턴을 무분별하게 적용하는 것은 오히려 코드를 불필요하게 복잡하게 만들 수 있습니다. 중요한 것은 각 패턴이 어떤 설계 원칙을 기반으로 하며, 어떤 문제를 해결하기 위해 고안되었는지를 정확히 이해하고, 현재 마주한 문제의 맥락에 적절하게 적용하는 것입니다. 디자인 패턴은 좋은 코드 설계를 위한 강력한 어휘이자 도구 상자입니다.

    6. 결론: 코드를 통해 생각을 디자인하다

    코드 설계는 단순히 보기 좋은 코드를 만드는 심미적인 활동이 아닙니다. 그것은 끊임없이 변화하는 요구사항과 불확실한 미래에 대응하여, 소프트웨어가 지속 가능한 생명력을 갖도록 만드는 본질적인 엔지니어링 활동입니다. SOLID 원칙을 통해 구조의 견고함을 다지고, KISS, DRY, YAGNI 철학으로 실용적인 균형을 잡으며, 디자인 패턴이라는 도구로 구체적인 문제를 해결해 나가는 과정 전체가 바로 코드 설계입니다.

    좋은 코드 설계는 하루아침에 이루어지지 않습니다. 수많은 시행착오와 리팩토링(Refactoring), 그리고 동료 개발자와의 끊임없는 코드 리뷰(Code Review)를 통해 점진적으로 향상되는 기술입니다. 우리가 작성하는 모든 클래스와 메서드가 미래의 누군가(바로 나 자신일 수도 있습니다)가 읽고 수정해야 할 대상임을 항상 기억해야 합니다. 코드는 단순한 명령어의 나열이 아니라, 문제 해결에 대한 우리의 생각을 담아내는 가장 정밀한 표현 수단입니다. 코드를 통해 생각을 디자인하는 여정에 첫발을 내딛는 순간, 우리는 비로소 진정한 소프트웨어 장인으로 성장하게 될 것입니다.