[SWE-011][실무] 안전하게 코드를 고치고 기술 부채 줄이기 > IT 기술 공유

• 목록

[이번 수업]

동작하는 코드를 더 읽기 쉽고 바꾸기 좋은 구조로 고치는 리팩터링과, 미룬 설계 문제가 앞으로 만드는 비용인 기술 부채를 함께 다룹니다. 리팩터링은 겉으로 보이는 동작을 유지하면서 내부 구조를 바꾸는 작업입니다. 새 기능과 섞지 않고 작은 단계로 진행해야 문제 원인을 찾기 쉽습니다.

[선수지식]

SWE-003의 테스트 범위와 TOOL-004의 Git 커밋을 알면 좋습니다. Python 함수와 리스트를 읽고 파일 하나를 실행할 수 있으면 됩니다.

[학습목표]

1. 리팩터링과 기능 변경을 구분한다.
2. 테스트·작은 변경·차이 검토로 동작을 보존한다.
3. 기술 부채를 우선순위 있는 작업으로 기록한다.

[핵심개념]

안전한 순서는 ‘현재 동작 고정 → 작은 구조 변경 → 자동 테스트 → 변경 차이 검토 → 작은 커밋’입니다. 현재 동작을 고정하는 테스트를 특성 테스트라고도 합니다. 이름 바꾸기, 함수 추출, 중복 제거를 한꺼번에 하지 말고 한 종류씩 적용하세요. 테스트가 통과해도 테스트하지 않은 동작은 보장되지 않으므로 코드 리뷰와 실제 사용 흐름 점검이 필요합니다.

기술 부채는 빠른 선택이나 부족한 구조 때문에 앞으로 변경 비용과 위험이 커지는 상태입니다. 부채 항목에는 ‘근거’, ‘영향받는 기능’, ‘방치 비용’, ‘완료 조건’, ‘담당자와 재검토일’을 적습니다. 발생 가능성·영향·반복 빈도가 큰 항목부터 처리합니다.

[따라하기]

빈 폴더에 refactor_demo.py를 만들고 아래를 붙여 넣으세요. 할인 계산을 함수로 분리해도 결과가 같은지 세 가지 사례로 확인합니다.

```python
import unittest

def total_before(amounts):
    subtotal = 0
    for amount in amounts:
        if amount < 0:
            raise ValueError("금액은 0 이상이어야 합니다")
        subtotal += amount
    return subtotal * 90 // 100 if subtotal >= 10_000 else subtotal

def apply_discount(subtotal):
    return subtotal * 90 // 100 if subtotal >= 10_000 else subtotal

def total_after(amounts):
    checked = []
    for amount in amounts:
        if amount < 0:
            raise ValueError("금액은 0 이상이어야 합니다")
        checked.append(amount)
    return apply_discount(sum(checked))

class TotalTest(unittest.TestCase):
    def check_both(self, amounts, expected):
        self.assertEqual(total_before(amounts), expected)
        self.assertEqual(total_after(amounts), expected)

    def test_empty(self):
        self.check_both([], 0)

    def test_under_limit(self):
        self.check_both([3_000, 2_000], 5_000)

    def test_discount(self):
        self.check_both([6_000, 5_000], 9_900)

if __name__ == "__main__":
    unittest.main()
```

macOS·Linux에서는 `python3 refactor_demo.py`, Windows에서는 `py refactor_demo.py`를 실행합니다. 환경에 따라 `python`도 됩니다. 예상 결과는 점 세 개 뒤에 `Ran 3 tests`와 `OK`가 표시되는 것입니다. Git 저장소라면 `git diff -- refactor_demo.py`로 의도하지 않은 변경이 섞였는지 확인하세요.

[흔한 실수]

테스트 없이 ‘정리만 했다’고 생각하거나 큰 이름 변경과 새 기능을 한 커밋에 섞지 마세요. 줄 수 감소만 목표로 삼으면 의도가 숨겨집니다. 모든 부채를 즉시 없애기보다 실제 변경을 자주 막는 항목부터 처리하세요.

[보안 주의]

입력 검증, 권한 검사, 감사 로그 같은 보안 동작은 별도 테스트로 고정하세요. 테스트 뒤에도 권한이 넓어지거나 민감한 값이 로그에 추가되지 않았는지 차이를 직접 봅니다. 실습은 본인 소유의 로컬 복사본과 가짜 데이터에서 하고 운영 데이터나 자격증명을 넣지 마세요.

[직접 해볼 과제]

음수 금액에서 두 함수가 모두 ValueError를 내는 테스트를 추가하세요. 이어서 ‘중복 검증 코드 추출’을 근거·영향·완료 조건·재검토일과 함께 부채 항목으로 기록하고, 작은 리팩터링 뒤 테스트와 차이를 다시 확인하세요.

[확인문제]

1. 리팩터링과 새 기능 추가의 가장 중요한 차이는 무엇인가요?
2. 작은 변경 뒤 곧바로 테스트하는 이유는 무엇인가요?
3. 기술 부채에 담당자와 재검토일을 적으면 무엇이 좋아지나요?

[다음 학습]

SWE-012에서 기존 프로그램의 테스트를 보강하고 구조와 성능을 단계적으로 개선하는 종합 프로젝트를 진행합니다.

[공식 참고 자료]

https://refactoring.com/
https://docs.python.org/3/library/unittest.html
https://git-scm.com/docs/git-diff
https://www.sei.cmu.edu/library/technical-debt-from-metaphor-to-theory-and-practice/