원리금균등 vs 원금균등, 총이자 얼마나 다를까 [2편] 개발기

지난 [1편]에서는 대출 상환방식 비교기가 뭘 보여주는지 다뤘습니다. 이번 편에서는 세 가지 상환방식을 하나의 함수로 통합한 방법과, 그래프가 왜곡됐던 문제를 표로 바꿔 해결한 과정을 기록합니다.

1. 세 가지 방식을 하나의 함수로

원리금균등, 원금균등, 만기일시상환은 계산 방식이 다르지만, 공통적으로 “매달 이자를 계산하고, 원금을 얼마나 갚을지 결정하고, 남은 원금을 줄인다”는 흐름을 가집니다. 이 공통 흐름을 하나의 함수로 만들고, method 파라미터로 분기하는 방식을 택했습니다.

function simulateLoan(principal, annualRate, totalMonths, graceMonths, method) {
  const monthlyRate = annualRate / 100 / 12;
  let remaining = principal;
  const schedule = [];

  for (let m = 1; m <= totalMonths; m++) {
    const interest = Math.round(remaining * monthlyRate);
    let principalPaid = 0;

    if (method === 'bullet') {
      // 만기일시상환: 마지막 달에만 원금 전액
      principalPaid = (m === totalMonths) ? remaining : 0;
    } else if (m <= graceMonths) {
      principalPaid = 0; // 거치기간: 이자만
    } else if (method === 'equal') {
      // 원리금균등: 고정 상환액에서 이자를 뺀 나머지가 원금
    } else {
      // 원금균등: 매달 동일한 원금
    }

    remaining -= principalPaid;
    schedule.push({ month: m, principalPaid, interest, remaining });
  }
  return schedule;
}

세 방식을 각각 별도 함수로 만들었다면 거치기간이나 소득공제 계산 로직을 세 번 따로 구현해야 했을 텐데, 하나로 합치니 이후 기능들(중도상환, 대환대출 비교)도 이 함수 하나만 재사용하면 됐습니다.

2. 그래프가 고장 났던 이유

처음엔 월별 상환액을 선 그래프로 그렸습니다. 그런데 배포하고 확인해보니, 만기일시상환의 마지막 달 값(원금 3억+이자)이 다른 두 방식의 월 상환액(수십~수백만원)보다 압도적으로 커서, y축이 그 값에 맞춰 늘어나고 나머지 두 선은 바닥에 깔린 것처럼 보였습니다.

// 문제가 됐던 상황
// 원리금균등 월 상환액: 약 150만원
// 만기일시상환 마지막 달: 약 3억 1천만원 ← 이 값 때문에 y축이 왜곡됨

3. 해결책: 시각화 방식 자체를 바꾸기

처음엔 “마지막 달 값만 그래프에서 제외하고 텍스트로 따로 보여주자”는 임시방편으로 접근했습니다. 그런데 사용자 피드백을 받고 나서, 애초에 선 그래프가 이 데이터에 안 맞는 시각화 방식이라는 걸 깨달았습니다. 360개월치 연속 변화를 보여주는 데는 선 그래프가 적합하지만, “특정 시점에 세 방식을 나란히 비교”하는 목적에는 오히려 표가 더 정확하고 왜곡될 여지가 없습니다.

function getMilestoneMonths(totalMonths) {
  const points = new Set();
  points.add(1);
  const totalYears = totalMonths / 12;
  const step = Math.max(1, Math.round(totalYears / 6));
  for (let y = step; y < totalYears; y += step) points.add(y * 12);
  points.add(totalMonths); // 마지막 달은 항상 포함
  return Array.from(points).sort((a, b) => a - b);
}

대출기간을 6등분해서 대표 시점만 뽑고, 각 시점마다 세 방식의 원금·이자·합계를 표의 한 행에 나란히 넣었습니다. 표는 숫자가 아무리 커도 그 칸에 그대로 찍히기 때문에, 만기일시상환의 원금 뭉치도 왜곡 없이 정확하게 드러납니다.

4. “적합한 시각화 도구가 무엇인가”부터 다시 묻기

이번 문제에서 배운 건, 그래프가 이상하게 나올 때 그래프를 고치기보다 애초에 이 시각화 방식이 이 데이터에 맞는지부터 다시 물어봐야 한다는 점이었습니다. 연속적으로 완만하게 변하는 데이터에는 선 그래프가 좋지만, 이번처럼 극단적으로 튀는 값이 섞여 있고 “몇 개 시점을 정확히 비교”하는 게 목적이라면 표가 훨씬 정직한 선택이었습니다. 시각화 방식을 유지한 채 데이터를 보정하는 것보다, 목적에 맞는 시각화 방식을 다시 고르는 게 더 근본적인 해결이었습니다.

5. 마무리하며

이번 프로젝트는 계산 로직 자체보다 “결과를 어떻게 보여줄 것인가”에서 더 많은 시행착오가 있었습니다. 정확한 숫자를 계산해도 시각화가 왜곡되면 사용자는 잘못된 인상을 받을 수 있다는 걸 다시 확인했고, 이후 도구를 만들 때도 “이 데이터의 값 범위가 극단적으로 벌어지지 않는지”를 시각화 방식을 정하기 전에 먼저 점검하는 습관이 생겼습니다.

무료로 직접 사용해보고 싶으시다면 [1편]에 링크해둔 계산기를 확인해보세요.