정답표를 먼저 계산해 스펙에 박는다

기대값을 언제 정하는가

계산 도구를 만들 때 테스트의 기대값은 어디서 올까요. 흔한 순서는 이렇습니다. 코드를 짠다 → 돌려 본다 → 나온 값을 기대값으로 적는다.

이 순서에는 치명적인 약점이 있습니다. 코드가 틀렸으면 틀린 값이 정답으로 굳습니다.테스트는 초록불이지만 아무것도 검증하지 않습니다. "지금 코드가 지금 코드와 같다"를 확인할 뿐입니다.

순서를 뒤집는다

그래서 규칙을 정했습니다. 도구를 만들 때는 구현 전에 정답표를 계산해 스펙 문서에 적습니다.30개 케이스 정도를 잡고, 코드가 아닌 다른 방법으로 값을 구합니다.

복리 계산기에서는 계산식을 직접 적용해 30개 케이스의 기대값을 미리 산출했습니다. 연봉 실수령액 계산기에서는 4대보험 요율과 공식 세액표를 가지고 30행을 먼저 만들었습니다. 두 경우 모두 구현이 끝난 뒤 테스트가 그대로 통과했고, 문서와 코드가 어긋날 여지가 없었습니다.

정답표가 잡아낸 것

연봉 계산기에서 실제로 걸린 사례가 있습니다. 스펙에는 월 비과세액 기본값을 200,000원(식대 비과세 한도)으로 적어 뒀는데, 구현할 때 0으로 뒀습니다. 단순한 실수입니다.

코드만 보면 아무 문제가 없습니다. 계산 로직은 정확하고, 0도 유효한 값입니다.정답표 30행이 한꺼번에 어긋나면서 즉시 드러났습니다. 기대값이 없었다면 한참 뒤에 "다른 계산기랑 값이 다르네"로 발견했을 겁니다.

경계값을 일부러 넣는다

정답표를 만들 때 평범한 값만 넣으면 절반만 쓸모 있습니다.규칙이 바뀌는 지점을 반드시 포함시킵니다.

• 상한·하한이 걸리는 정확한 지점, 그리고 그 바로 아래위
• 계산 방식이 바뀌는 경계 (표를 쓰다가 공식으로 넘어가는 지점 같은)
• 0, 음수, 비정상 입력
• 등급이나 구간이 갈리는 경계의 ±1

연봉 계산기 정답표에는 국민연금 하한에 정확히 걸리는 행, 상한에 도달하는 첫 행, 상한을 넘어 값이 고정되기 시작하는 행을 따로 넣었습니다. 이 세 행이 없으면 상·하한 처리를 통째로 빼먹어도 테스트가 통과합니다.

손으로 못 푸는 값은 어떻게 하나

복리처럼 암산이 불가능한 값이 문제입니다. 그럴 때도 방법은 있습니다.코드가 아닌 경로로 계산하면 됩니다.스프레드시트를 쓰거나, 별도의 스크립트를 쓰거나, 공식을 직접 전개하거나.

중요한 건 "검증 대상과 다른 경로"라는 점입니다. 같은 함수로 기대값을 만들면 아무 의미가 없습니다. 외부에 신뢰할 수 있는 값이 있다면 그것과 대조하는 게 가장 좋습니다.

계약을 동결한다는 것

정답표가 통과하면 그 시점의 인터페이스를 계약으로 동결합니다. 이후로는 계약에 없는 내보내기나 필드를 만들지 않습니다.

이렇게 하면 코어와 화면의 경계가 명확해집니다. 화면 쪽이 필요하다고 코어에 함수를 하나씩 더하기 시작하면 순수 모듈이 서서히 무너지고, 테스트가 닿지 않는 영역이 넓어집니다.