40대 리더의 시선: 유지보수 불가 코드 뜯어고친 썰

스파게티 코드 폭탄, 당신의 퇴근을 가로막고 있진 않나요?

어느 날 인수인계받은 수만 줄짜리 레거시 코드, 메인 함수(main.c)를 열어보는 순간 숨이 턱 막힌 경험 다들 있으실 겁니다.
전역 변수가 거미줄처럼 얽혀 있고, 하드웨어 제어 로직과 비즈니스 로직이 하나의 파일에 짬뽕되어 있는 소위 '유지보수 불가' 상태의 코드 말입니다.
특히 우리 같은 임베디드 소프트웨어 엔지니어들에게 이런 낡은 코드는 그야말로 언제 터질지 모르는 시한폭탄과 같습니다.

간단한 CAN 통신 기능 하나 추가하려는데 연관된 함수 수십 개를 뜯어고쳐야 합니다.
수정한 코드 때문에 엉뚱한 곳에서 uint16 비트 연산이나 바이트 오더링(Byte Ordering) 문제가 터져 밤을 새우게 되죠.
심지어 VectorCAST 2025 같은 자동화 툴로 단위 테스트를 돌려보면 빨간불이 수백 개씩 쏟아져 나와 개발 의욕마저 꺾어버립니다.

복잡하게 얽힌 스파게티 코드가 띄워진 듀얼 모니터 앞에서 머리를 감싸 쥔 40대 임베디드 소프트웨어 개발자

결국 본질적인 설계 개선 없이 땜질식 처방만 반복하다 보면, 개발 팀의 피로도는 극에 달하고 프로젝트 납기는 무한정 지연됩니다.

OCP와 패턴 관점으로 뜯어고치는 3단계 리팩토링 실무

더 이상 땜질은 통하지 않는다고 판단했을 때, 저는 과감하게 아키텍처를 뒤엎기로 결정했습니다.
핵심은 OCP(개방-폐쇄 원칙)와 디자인 패턴을 적용하여, '확장에는 열려있고 수정에는 닫혀있는' 견고한 구조를 설계하는 것입니다.

실행 단계	적용 기법 및 패턴	기대 효과
1단계: 하드웨어 종속성 분리	인터페이스(Wrapper) 패턴 적용	비즈니스 로직과 HW 드라이버 디커플링
2단계: OCP 기반 구조 설계	전략(Strategy) 패턴을 활용한 모듈화	기존 코드 수정 없이 새 기능(프로토콜 등) 추가
3단계: 단위 테스트 및 검증	의존성 주입(DI)을 통한 Mocking 테스트	VectorCAST 커버리지 100% 달성 및 회귀 버그 차단

실제 어떻게 구현하고 설계했는지, 단계별 소스 코드 예시를 통해 구체적으로 살펴보겠습니다.
기존에는 특정 장비에 종속된 통신 코드가 비즈니스 로직 곳곳에 하드코딩되어 있었습니다.

💡 [STEP 1 & 2] PCAN 래퍼(Wrapper) 클래스와 OCP의 적용

아래 코드는 추상화된 인터페이스를 통해 하드웨어 의존성을 완벽하게 분리한 예시입니다.

// 1. 공통 통신 인터페이스 정의 (수정에 닫힘)
class ICANInterface {
public:
    virtual ~ICANInterface() = default;
    virtual bool SendMessage(uint16_t id, const uint8_t* data, uint8_t length) = 0;
};

// 2. PCAN용 기본 래퍼 클래스 구현 (확장에 열림)
class PCANWrapper : public ICANInterface {
public:
    bool SendMessage(uint16_t id, const uint8_t* data, uint8_t length) override {
        // PCAN-Basic API 호출 및 바이트 오더링 처리 등 하드웨어 종속 로직
        return true; 
    }
};

// 3. 비즈니스 로직은 인터페이스에만 의존 (의존성 주입)
class DiagnosticService {
private:
    ICANInterface* canInterface;
public:
    DiagnosticService(ICANInterface* interface) : canInterface(interface) {}
    void ExecuteService() {
        uint8_t payload[8] = {0x02, 0x27, 0x01, 0, 0, 0, 0, 0}; 
        canInterface->SendMessage(0x7E0, payload, 8);
    }
};

이렇게 인터페이스를 구축하면, 향후 테스트 환경에서 `CANoe 11.0.96(SP4)` 가상 노드로 통신 채널을 스위칭할 때도 `DiagnosticService` 내부 코드는 단 한 줄도 수정할 필요가 없습니다. 이것이 바로 OCP가 가져다주는 강력한 유지보수성입니다.