프로그래밍에서의 임시방편 — 정의, 원인, 정당화되는 경우

프로그래밍에서 “임시방편”이란?

임시방편(크러치)은 작동은 하지만 “급조된” 소프트웨어 해결책입니다. 특정 문제를 해결하지만 원인을 제거하지 않고, 프로젝트 아키텍처를 따르지 않으며, 환경의 미세한 변화에도 깨질 수 있습니다. 비유는 정확합니다. 실제 목발처럼, 이러한 코드는 “걷는” 것을 돕지만 “다리”를 치료하지는 않습니다.

개발자는 버그, 버전 비호환성, 플랫폼 특성, 긴급한 고객 요구사항을 “임시방편으로 버팁니다”. 전형적인 임시방편은 조건부 임시방편입니다: iOS 15이면 패딩을 추가하고, Huawei이면 버튼을 숨깁니다. 이러한 검사는 증식하여 코드를 플랫폼 및 버전 분기의 “레이어 케이크”로 만듭니다.

임시방편에는 다양한 규모가 있습니다. 임시방편 조건이 있는 한 줄의 코드부터 라이브러리 동작을 “수정”하는 전체 래퍼 모듈까지. 임시방편이 항상 나쁜 것은 아님을 이해하는 것이 중요합니다. 올바른 손에서는 제품을 제때 출시할 수 있는 도구입니다. 문제는 임시방편이 코드에 영원히 남을 때 시작됩니다.

임시방편이 생기는 이유: 원인과 맥락

주된 이유는 이상적인 해결책과 프로젝트의 실제 제약 사이의 충돌입니다. 개발자는 올바른 방법을 알고 있지만, 시간, 비용 또는 기술적 제한이 이를 막습니다. 결과적으로 “그냥 작동하는” 절충안이 나타납니다.

개발자가 의식적으로 임시방편에 의존하는 네 가지 주요 이유를 살펴보겠습니다. 이러한 이유를 이해하면 임시방편을 실수가 아니라 관리가 필요한 실용적인 도구로 대처하는 데 도움이 됩니다.

마감 기한

가장 흔한 이유입니다. 릴리스가 내일이고, 버그가 특정 모델에서만 재현되며, 아키텍처적으로 수정하는 데 2주가 걸립니다. 조건부 임시방편은 한 시간이면 문제를 해결합니다. 릴리스 후 팀은 돌아와서 제대로 다시 작성하겠다고 약속합니다. “임시방편보다 더 영구적인 것은 없다” — 이것이 바로 이러한 임시방편에 해당하는 말입니다.

버전 비호환성

라이브러리 A는 Android 12가 필요하지만 앱은 Android 10을 지원합니다. 해결책은 OS 버전을 확인하고 실행 경로를 선택하는 래퍼를 작성하는 것입니다. 이것은 임시방편입니다. 라이브러리를 업데이트할 때 래퍼를 다시 작성해야 하기 때문입니다. 하지만 대안(라이브러리나 오래된 기기 지원을 포기하는 것)은 더 나쁠 수 있습니다.

// API 29 호환성을 위한 임시방편
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

버그가 있는 타사 종속성

프로젝트가 의존하는 라이브러리에 버그가 있지만 업데이트하는 데 몇 주가 걸릴 수 있습니다(PR, 코드 리뷰, 게시 필요). 기다리는 대신, 팀은 래퍼를 작성하여 라이브러리 동작을 즉시 패치합니다. 수정된 버전의 라이브러리가 출시되면 래퍼가 제거됩니다. 제거하지 않으면 이미 아키텍처 문제입니다.

시스템에 대한 불완전한 이해

레거시 프로젝트의 새 개발자는 코드가 왜 그렇게 작동하는지 이해하지 못합니다. 알아내는 대신 기존 조건 위에 새 조건을 추가합니다. 이것은 가장 위험한 유형의 임시방편입니다. 작성자가 그것이 임시방편임을 인식하지 못하기 때문입니다. 유일한 치료법은 코드 리뷰와 새 팀원을 위한 페어 프로그래밍입니다.

임시방편이 정당화되는 경우: 실용적 접근법

모든 임시방편이 나쁜 것은 아닙니다. 실제 개발에서 코드의 절대적 순수함은 달성할 수 없고 종종 비현실적입니다. 실용적 접근법은 임시 해결책이 프로세스의 일부임을 인정하지만 인식, 문서화 및 제거 계획을 요구합니다. 임시방편은 깔끔한 아키텍처 해결책보다 비즈니스 문제를 더 빨리 해결할 때 정당화됩니다.

정당화되는 임시방편의 기준: 특정 문제를 해결하고, 소유자(제거를 담당하는 사람)가 있으며, 리팩토링 계획이 존재합니다. 이 세 가지 조건 중 하나라도 없으면 임시방편은 기술 부채로 변합니다. 트래커의 티켓이 있는 TODO 주석과 같은 도구가 최소한의 문서화 방법입니다.

정당화되는 임시방편의 예

내일 배포 전에 수정해야 하는 릴리스 브랜치의 중요 버그. 깔끔한 해결책은 아키텍처 리팩토링이 필요하며 2주가 걸립니다. 임시방편: nil 검사를 추가하고 핫픽스로 수정 사항을 보냅니다. 정당화 조건: 트래커에 리팩토링 티켓이 생성되고, 소유자가 지정되며, 임시방편에 주석이 표시됩니다. 2주 후 팀은 작업으로 돌아갑니다.

// TODO: IT-1234 — AuthService 리팩토링 후 이 임시방편 제거
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

임시방편과 아키텍처 문제 구별 방법

인식된 임시방편과 아키텍처 문제(기술 부채)의 경계는 두 가지 매개변수에 의해 결정됩니다: 결정에 대한 인식과 이를 제거할 계획의 존재입니다. 임시방편은 항상 알려진 수명을 가진 임시 해결책입니다. 기술 부채는 방치된 많은 임시방편의 결과입니다.

임시방편이 문제가 되는 경우

임시방편의 수가 임계 질량을 초과하면 상황이 악화됩니다. 새 임시방편마다 시스템의 “취약성”이 증가합니다. 한 곳의 변경이 다른 곳을 깨뜨립니다. 결국 개발이 느려지고 버그가 늘어나며 새 개발자는 작성자 도움 없이 코드를 이해할 수 없습니다. 이 시점에서 임시방편은 더 이상 임시 해결책이 아니며 아키텍처 문제가 됩니다.

임시방편 위기의 징후

코드에 OS 버전, 기기 제조업체, 특정 라이브러리 존재 여부를 확인하는 5개의 중첩 검사가 있다면 — 이것은 임시방편이 아니라 아키텍처 문제입니다. 하나의 수정으로 관련 모듈에 3개의 회귀가 발생한다면 — 임시방편이 더 이상 국소적이지 않습니다. “또 임시방편”이라는 이유로 코드 리뷰가 정기적으로 거부된다면 — 리팩토링을 계획할 때입니다.

• 같은 임시방편이 세 군데 이상에서 반복됨 — 통합 해결책을 만들 때
• 임시방편이 제거 계획 없이 3스프린트 이상 지속됨 — 이미 기술 부채
• 새 개발자가 코드 동작 방식을 이해하지 못함 — 임시방편이 문서화되지 않음
• 임시방편 제거가 오류의 연쇄 반응을 일으킴 — 임시방편 의존성이 아키텍처화됨

임시방편 리팩토링: 전략과 실천

임시방편 리팩토링은 임시 해결책을 아키텍처적으로 올바른 해결책으로 대체하는 과정입니다. 시간이 걸리므로 우선순위 전략이 필요합니다. 모든 임시방편을 즉시 제거할 필요는 없습니다. 좋은 전략은 각 임시방편을 두 가지 매개변수로 평가하는 것입니다: 해당 코드 영역의 변경 빈도와 사용자에 대한 영향.

우선순위 전략

높은 우선순위 — 자주 변경되는 모듈(비즈니스 로직, 범용 UI)의 임시방편으로, 개발을 느리게 하고 회귀를 유발합니다. 중간 우선순위 — 드물게 변경되지만 사용자에게 잠재적 영향이 있는 모듈(결제 처리, 인증)의 임시방편. 낮은 우선순위 — 안정적으로 작동하고 수정이 예정되지 않은 레거시 코드의 임시방편.

단계별 제거 프로세스

1단계: 목록 작성 — 임시방편과 관련된 모든 TODO와 FIXME를 찾습니다. 2단계: 평가 — 어떤 것이 여전히 관련 있는지 판단합니다. 3단계: 계획 — 높은 우선순위부터 시작하여 스프린트에 임시방편 리팩토링을 일정에 포함시킵니다. 4단계: 교체 — 깔끔한 해결책을 구현하고, 임시방편과 TODO 주석을 제거합니다. 5단계: 검증 — 테스트가 통과하고 회귀가 없는지 확인합니다.

# 프로젝트에서 모든 TODO 임시방편 찾기
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

새 임시방편 방지

임시방편과 싸우는 가장 좋은 방법은 불필요하게 만들지 않는 것입니다. 임시방편을 작성하기 전에 스스로에게 세 가지 질문을 하세요. 합리적인 시간 내에 깔끔한 해결책을 구현할 수 있습니까? 임시방편이 아닌 대안이 있습니까? 팀이 돌아와서 다시 작성할 시간이 있습니까? 하나라도 “아니요”라면 — 코드를 “버티게” 하기 전에 다시 생각해보세요.