Software Design

테스트 코드 왜 짜야 할까? 귀찮은데도 짜는 진짜 이유 (실무 정리)

"이거 언제 다 짜고 있어..." 기능 하나 만드는 데도 시간이 빠듯한데, 테스트 코드까지 짜라고 하면 솔직히 한숨부터 나옵니다.

이석우iOS Developer4분 읽기
테스트 코드 왜 짜야 할까? 귀찮은데도 짜는 진짜 이유 (실무 정리) 대표 이미지

“이거 언제 다 짜고 있어…” 기능 하나 만드는 데도 시간이 빠듯한데, 테스트 코드까지 짜라고 하면 솔직히 한숨부터 나옵니다.

결론부터 말하면, 테스트 코드를 짜는 진짜 이유는 “미래의 나를 지키기 위해서”입니다. 지금 10분 더 쓰는 대신, 3개월 뒤 새벽에 터지는 장애를 막는 겁니다.

테스트 코드 왜 짜야 할까, 초록불 하나면 이유가 설명됩니다
테스트 코드 왜 짜야 할까, 초록불 하나면 이유가 설명됩니다

테스트 코드, 왜 짜야 할까?

가장 큰 이유는, 코드를 고치는 게 더 이상 무섭지 않다는 거예요.

코드는 한 번 짜고 끝나지 않습니다. 계속 고치고 기능이 붙습니다.

테스트가 없으면 코드 한 줄 고칠 때마다 불안합니다. “이거 고치면 다른 데 안 터지나?”

테스트가 있으면 고치고 나서 실행 한 번으로 확인됩니다. 초록불이면 안심, 빨간불이면 어디가 깨졌는지 바로 보입니다.

고치고 실행 한 번, 초록불 아니면 바로 원인 확인
고치고 실행 한 번, 초록불 아니면 바로 원인 확인

이걸 ’회귀 테스트’라고 불러요. 예전에 잘 되던 게 다시 망가지는 걸 잡아준다는 얘기죠.


귀찮은데도 짜는 진짜 이유

솔직히 테스트 코드는 당장은 손해처럼 느껴집니다. 눈에 보이는 기능이 늘어나는 것도 아니니까요.

그런데 프로젝트가 커질수록 이야기가 달라집니다.

기능이 30개, 50개로 늘어나면 손으로 일일이 확인하는 건 불가능합니다. 하나 고칠 때마다 전부 클릭해볼 순 없잖아요.

이때 테스트가 있으면 명령어 한 줄로 수십 개를 몇 초 만에 검증합니다.

두 번째 이유는 테스트 코드가 곧 ’문서’가 된다는 겁니다.

잘 짜인 테스트 코드를 보면 이 함수가 어떤 입력에 어떤 결과를 내는지 한눈에 보입니다.

주석은 오래되면 거짓말을 하지만, 테스트는 실행되기 때문에 거짓말을 못 합니다.

간단한 예시를 볼게요. 할인 금액을 계산하는 함수의 테스트입니다.

// 1만원에 10% 할인 → 9천원이 나와야 한다
@Test func 할인_10퍼센트를_적용한다() {
    let result = applyDiscount(10000, rate: 0.1)
    #expect(result == 9000)
}

이 테스트만 봐도 applyDiscount가 뭘 하는 함수인지 바로 이해됩니다.

터미널에 PASS 뜨는 순간의 안심은 겪어봐야 압니다
터미널에 PASS 뜨는 순간의 안심은 겪어봐야 압니다

테스트 코드, 어떻게 시작하나요?

처음부터 모든 걸 테스트하려고 하면 지쳐서 포기합니다.

저는 이렇게 시작하는 걸 추천해요.

  1. 돈 계산, 로그인처럼 ‘터지면 큰일 나는’ 핵심 로직부터
  2. 조건 분기가 많아 헷갈리는 함수
  3. 버그가 한 번 났던 곳 (재발 방지용)

반대로 단순한 화면 코드나 자주 바뀌는 부분은 나중에 해도 됩니다.

모든 걸 100% 테스트하는 게 목표가 아니라, 비용 대비 효과를 따지는 게 핵심입니다.

저는 이 세 가지 우선순위부터 하나씩 붙여봤어요
저는 이 세 가지 우선순위부터 하나씩 붙여봤어요

자주 묻는 질문

Q. 테스트 짜면 개발이 느려지지 않나요?

A. 처음엔 느려집니다. 하지만 프로젝트 중반부터는 오히려 빨라집니다. 버그를 찾고 고치는 시간이 확 줄기 때문입니다.

Q. 테스트 커버리지는 몇 %가 좋나요?

A. 숫자에 집착할 필요는 없습니다. 70~80%면 충분하고, 중요한 로직이 덮여 있느냐가 더 중요합니다.


테스트 코드는 실력 자랑이 아니라, 미래의 나와 동료를 위한 안전장치입니다.

당장 오늘 짠 함수 하나에 테스트 한 개만 붙여보세요. 그 작은 초록불이 주는 안심을 느끼고 나면, 왜 다들 테스트를 짜라고 하는지 몸으로 알게 되실 거예요.

이어서 읽기