복잡한 입력 화면까지 설계했는데, 데이터를 열어보니 단순 집계였습니다

기능 하나를 붙이려고 설계 문서를 쓰다 보면 문서가 갑자기 두꺼워지는 구간이 있습니다. 「이 값이 저 값에 의존하니 입력 장치가 하나 더 필요하겠다」, 「이 화면은 기준이 여러 개일 테니 기준을 고르는 UI가 필요하겠다」 같은 문장이 붙는 지점입니다. 어떤 B2B 채권 분석 시스템의 조건 분석 기능을 만들면서 같은 날 이런 문장을 두 번 썼습니다. 두 번 다 그 문장은 사실이 아니었습니다.

설계 문서가 두꺼워지던 지점

조건 분석은 사용자가 조건을 걸어 결과 지표를 뽑아보는 화면입니다. 그날 붙일 결과 항목이 두 개였습니다. 두 항목 모두 설계 단계에서 「이건 단순 집계로 안 끝날 것 같다」는 판단이 먼저 나왔습니다. 그래서 각각에 추가 장치를 설계 문서에 그려 넣었습니다.

그 판단의 근거는 데이터가 아니라 추론이었습니다. 계산식을 머릿속으로 따라가다가 「여기서 값이 필요한데 그 값도 계산 결과다」라는 지점을 만나면, 그 자리에 장치를 하나 놓게 됩니다. 문제는 그 지점이 실제 코드와 데이터에도 있는지를 아직 안 봤다는 것입니다. 설계 단계의 우려는 그때까지는 가설입니다.

첫 번째 사례 — 입력 섹션과 2-pass 계산까지 그렸습니다

첫 결과 항목은 회수 비율 계열 지표 4종이었습니다. 설계할 때는 이렇게 봤습니다. 이 비율을 내려면 평가 시점의 잔액이 필요하고, 평가 시점 잔액은 추정값이며, 그 추정은 다시 대표 회수 비율 파라미터에 의존한다. 값을 구하려면 값이 먼저 있어야 하는 구조로 읽혔습니다.

그래서 설계 문서에 들어간 장치가 이랬습니다.

화면에 접이식 입력 섹션 2칸 — 사용자가 대표 비율 파라미터를 직접 넣는다

평가월별 기본값 자동 채움 — 사용자가 매번 입력하지 않도록

2-pass 계산 — 1차로 잔액을 추정하고, 2차로 지표를 산출한다

구현에 들어가기 전에 계산 로직과 실데이터를 한 겹 확인했습니다. 지표 4종은 전부 매입 시점 잔액을 기준으로 하는 단순 집계였습니다. 평가 시점 추정이 끼어드는 자리가 없었고, 값이 값을 참조하는 순환도 없었습니다. 2-pass도, 파라미터 입력 섹션도, 평가월별 기본값 채움도 만들 이유가 사라졌습니다. 설계 문서의 한 장이 통째로 지워졌고 구현은 집계 쿼리로 끝났습니다.

두 번째 사례 — 기준을 고르는 UI를 그렸습니다

두 번째 결과 항목은 평가율을 곱해야 나오는 비율 지표였습니다. 평가율은 회사별·평가월별 매트릭스로 관리됩니다. 그런데 조건 분석 화면은 회사를 가리지 않는 통합 화면입니다. 여기서 질문이 하나 생깁니다. 통합 화면에서 평가율을 어느 기준으로 적용하느냐입니다.

이건 화면 문제이면서 동시에 합의 문제입니다. 어느 기준이 맞는지는 개발자가 혼자 정할 수 없습니다. 기준 선택 UI를 붙이든 대표 기준을 하나 정하든, 그 전에 사람들이 모여 답을 정해야 합니다. 설계 메모에는 일단 평가 기준 선택 UI를 적어 두고, 회의를 잡기 전에 데이터를 먼저 열었습니다.

매트릭스는 전 구간 한 종류뿐이었습니다. 회사에 따라 값이 갈리는 구간이 데이터에 아예 없었습니다. 「어느 기준으로 적용하느냐」는 질문 자체가 성립하지 않는 상태였습니다. 계좌에 걸린 회사를 조인해 값을 가져오는 것으로 끝났고, 기준 선택 UI도 그 UI를 정하려던 회의도 열리지 않았습니다.

우려를 코드로 받을 것인가, 확인 작업으로 받을 것인가

두 사례의 갈림길은 같았습니다. 우려가 생긴 자리에서 「필요할지 모르니 미리 짓는다」와 「정말 필요한지 데이터로 먼저 본다」 중 하나를 고르는 것입니다. 두 번 다 뒤쪽을 골랐고, 두 번 다 복잡한 장치는 불필요로 판명됐습니다.

표에서 가장 아래 줄이 실무에서는 제일 오래 남습니다. 미리 지으면 「왜 만들었는지」만 남고, 확인하고 안 지으면 「왜 안 만들었는지」가 근거와 함께 남습니다. 반년 뒤 같은 질문이 다시 올라올 때 꺼낼 수 있는 것은 후자입니다.

아낀 것은 코드가 아니라 회의였습니다

첫 사례에서 아낀 것은 화면 요소 두 칸과 계산 구조 하나입니다. 눈에 보이는 절약입니다. 두 번째 사례에서 아낀 것은 성격이 다릅니다. 「평가 기준을 어느 쪽으로 잡을 것인가」는 개발자가 혼자 못 정하는 질문이고, 이런 질문은 대체로 회의 한 번에 끝나지 않습니다. 기준을 정하면 그 기준을 화면에 어떻게 노출할지, 나중에 기준을 바꾸면 과거 결과와 어떻게 비교할지가 줄줄이 붙습니다.

데이터를 한 겹 열어본 시간은 그 회의를 한 번도 열지 않게 만들었습니다. 설계 논의를 줄이는 가장 싼 방법은 논의를 잘하는 것이 아니라, 논의가 필요한 상황인지 먼저 확인하는 것입니다.

설계 메모에 선행 확인 필요를 적습니다

두 작업에서 실제로 작동한 장치는 거창한 원칙이 아니라 메모에 박아둔 문장 하나입니다. 계획 단계에서 우려가 생기면 그 자리에 「구현 전 한 겹 확인 필요」를 항목으로 적었습니다. 이 문장이 하는 일이 세 가지입니다.

우려를 지우지 않고 남긴다 — 잊고 지나갔다가 구현 뒤에 터지는 것을 막는다

우려를 구현 대상이 아니라 확인 대상으로 등록한다 — 할 일의 종류가 바뀐다

확인 결과가 기록으로 남는다 — 같은 질문이 다시 올라와도 조사를 반복하지 않는다

YAGNI를 「필요할 때까지 안 만든다」로만 읽으면 무조건 단순하게 가라는 지침이 됩니다. 그렇게 쓰면 정말 복잡도가 필요한 자리에서도 안 만들게 됩니다. 이번 두 건에서 통한 것은 「안 만든다」가 아니라 「확인하고 정한다」였습니다. 복잡도의 필요 여부를 감이 아니라 데이터로 판정하는 절차입니다.

이 방식이 안 통하는 자리

선행 확인이 언제나 답은 아닙니다. 세 가지 경우에는 다르게 판단합니다.

확인이 한 겹을 넘어갈 때 — 조사가 며칠짜리로 커지면 그건 선행 확인이 아니라 분석 마비입니다. 한 겹에 안 끝나면 일단 좁은 범위로 만들고 그 위에서 다시 판단합니다.

지금 단순한 것이 계속 단순하리란 보장이 없을 때 — 평가율 매트릭스가 나중에 다구간이 되면 두 번째 사례의 설계는 그때 필요해집니다. 「지금은 불필요」에는 시효가 있어서, 안 만든 이유를 기록에 남겨 둡니다.

사고 비용이 조사 비용보다 훨씬 큰 도메인 — 결제·정산처럼 한 번 틀리면 되돌리기 어려운 자리는 방어 장치를 미리 두는 쪽이 쌉니다.

설계 우려를 만났을 때 점검할 것

이 장치를 넣는 근거를 데이터로 말할 수 있는가, 아니면 추론인가

확인에 드는 시간이 구현에 드는 시간보다 짧은가

안 쓰게 됐을 때 걷어낼 수 있는 구조인가 — 화면에 노출된 입력칸은 걷어내기 어렵다

설계 문서에 선행 확인 항목이 붙어 있는가

안 만들기로 한 결정과 그 이유가 기록에 남는가

마무리

같은 패턴이 같은 날 두 번 나오면 우연이 아니라 작업 방식의 신호로 봅니다. 두 건 모두 계산식을 머리로 따라가다 나온 우려였고, 두 건 모두 실데이터를 한 번 열어보는 것으로 정리됐습니다. 설계 단계에서 떠오른 「이게 필요할지 모른다」는 문장은 구현 지시가 아니라 조사 지시로 읽는 편이 안전합니다.

설계 문서가 갑자기 두꺼워지는 구간이 보이면 거기서 한 번 멈추고, 그 두께를 만든 문장이 데이터로 확인된 사실인지 봅니다. 확인은 한 겹이면 충분할 때가 많고, 그 한 겹이 안 쓸 코드와 열지 않아도 될 회의를 같이 걷어냅니다.