무한의 덧셈 — “정답”보다 “정의”를 먼저 맞추는 습관

 

“그거 무한히 더하면 뭐가 되냐” 같은 질문은 얼핏 쓸데없어 보인다.

근데 개발을 오래 하면 알게 된다. 팀이 싸우는 지점은 구현이 아니라 정의다.

이 글은 무한의 덧셈이라는 글을 계기로, 개발자가 바로 써먹을 수 있는 “정의 맞추기” 감각을 정리한 메모다.

 

왜 “무한의 덧셈” 같은 얘기가 개발에 먹히냐

무한급수는 “계산을 많이 하면 답이 나오나?”가 아니라, “어떤 규칙을 답으로 인정할 건가?”가 핵심이다.

개발도 똑같다. 코드 한 줄을 쓰기 전에 팀이 합의해야 하는 게 있다.

• “빠르다”가 무슨 뜻인가(평균? p95? p99?).
• “정확하다”가 무슨 뜻인가(정답률? 재현율? 오탐/미탐?).
• “안정적이다”가 무슨 뜻인가(에러율? 다운타임? 롤백 가능성?).

이게 안 맞으면, 구현은 계속 바뀌고 회의는 끝이 없다.

 

정의가 안 맞으면 생기는 전형적인 사고

예를 들어 “검색이 느리다”는 이슈가 왔다고 치자.

A는 DB 인덱스를 만들고, B는 캐시를 붙이고, C는 프론트를 최적화한다. 다 맞는 말처럼 보인다.

근데 정의가 없으면, 셋 다 “문제 해결”을 했는데도 끝나지 않는다.

포인트: 정의가 없으면 개선도 없고, 성공도 없다. 측정 기준이 없어서다.

 

“수렴” 감각을 서비스 운영으로 옮기면

무한의 덧셈에서 수렴은 “계속 더해도 어느 순간부터 더 이상 크게 변하지 않는 상태”다.

서비스 운영에서도 비슷한 순간이 있다.

• 재시도(retry)를 무한히 하면 안정적이냐? 아니다. 어느 순간부터는 장애를 키운다(트래픽 폭증).
• 캐시를 무한히 붙이면 빨라지냐? 아니다. 어느 순간부터는 정합성/무효화 비용이 더 커진다.
• 관측(로그/알림)을 무한히 늘리면 안전하냐? 아니다. 알림이 많아지면 아무도 안 본다.

즉, “더 하는 것”이 답이 아니라 “어디까지가 유효한가”를 정하는 게 답이다.

 

팀에서 바로 쓰는 방법: 애매한 말을 “문장 1개”로 고정하기

내가 추천하는 방식은 간단하다. 애매한 말을 문장 1개로 바꾸는 거다.

• “빠르다” → “검색 p95 응답시간이 200ms 이하로 유지된다.”
• “안정적이다” → “배포 후 24시간 5xx 에러율이 0.1% 이하로 유지된다.”
• “정확하다” → “주요 케이스 50개에서 정답률 98% 이상이다.”

이 문장을 PR 템플릿이나 이슈 템플릿에 박아두면, 논쟁이 “감”이 아니라 “측정”으로 바뀐다.

 

예시: PR에 붙이는 “정의 블록”

이 정도만 있어도 팀 커뮤니케이션 난이도가 확 내려간다.

## 성공 정의(Definition)
- 이번 변경이 성공하려면 어떤 상태여야 하나?
  - 예: 검색 p95 200ms 이하

## 측정 방법(Measurement)
- 어디서 확인하나?
  - 예: 대시보드 링크 / 로그 쿼리 / 샘플링 방법

## 실패 시 대응(Rollback/Recovery)
- 터지면 어떻게 되돌리나?
  - 예: 플래그 OFF / 롤백 커밋 / 이전 버전 배포

 

마무리

무한의 덧셈 얘기는 “수학”이 아니라 “정의” 이야기다.

개발도 결국 정의의 게임이다. 정의가 맞으면 구현은 빨라지고, 정의가 틀리면 구현은 끝없이 흔들린다.

 

참고: https://jeho.page/essay/2026/02/14/infinite-addition.html