"AI 평가" 빈 박스를 발견했을 때 채우지 않고 지운 이유 — 의도 중복의 진단

"왜 이 박스는 항상 비어 있지?"

일일 리포트 화면을 둘러보다가 의문이 들었습니다. "AI 평가"라는 박스가 화면에 있는데 항상 비어 있었어요.

처음에는 단순한 미구현 상태라고 생각했습니다. 시간이 없어서 채우는 로직을 못 만든 것이거나, generate 호출이 빠진 거라고요. 그래서 채우는 코드를 짜려고 코드를 열어봤습니다.

그런데 코드를 보다가 다른 사실을 발견했습니다. 같은 화면의 다른 필드가 이미 같은 일을 하고 있었어요.

종합 인사이트 필드가 "오늘의 작업 의미와 다음 행동 제안을 한 단락으로 묶어주는" 역할을 하고 있었습니다. 사용자가 일일 리포트에서 원했던 "AI의 종합 평가"가 바로 이 필드였습니다. AI 평가 박스는 같은 의도를 노린 별도의 자리였는데, 의미가 겹치니까 자연스럽게 채워지지 않은 것이었습니다.

이 발견이 결정을 완전히 바꿨습니다. 이건 미구현이 아니라 의도 중복이었어요. 채우는 게 정답이 아니라 제거가 정답이었습니다.

"비어있다 = 채워라"의 함정

처음에 채우려고 했던 본능을 다시 들여다봤습니다.

화면에 빈 필드가 있으면 개발자는 거의 자동으로 "채워야 한다"고 생각합니다. UI에 자리가 있으니까 콘텐츠가 필요하고, 콘텐츠가 없으면 미완성으로 보입니다. "이걸 채우는 게 다음 작업이다"가 자연스러운 결론이에요.

그런데 이 본능에는 함정이 있었습니다. 빈 필드의 원인이 시간 부족인지 의도 중복인지 구분하지 않은 채로 채우면, 중복 의도가 그대로 남습니다. 사용자는 두 개의 비슷한 평가를 한 화면에서 보게 되고, 어느 쪽을 신뢰해야 할지 혼란스러워집니다.

본능적 판단의 차이를 정리하면 이렇습니다.

진단을 먼저 해야 합니다. 그 다음에 액션이 결정됩니다. 본능을 따라가면 진단을 건너뛰게 됩니다.

의도 중복을 어떻게 진단할까

빈 박스를 발견했을 때 의도 중복인지 진짜 미구현인지 구분하는 절차를 정리해봤습니다. 네 가지 신호를 보면 진단이 가능합니다.

1. 같은 화면에 의도가 비슷한 다른 필드가 있는가

가장 강한 신호입니다. 한 화면에서 "이 정보는 사용자에게 어떤 가치를 주는가"가 비슷한 필드가 두 개 이상이면 의도 중복일 가능성이 높습니다. 이번 케이스에서 "AI 평가"와 "종합 인사이트"는 둘 다 "AI가 본 오늘의 요약"이라는 같은 의도를 노렸습니다.

2. 그 필드가 한 번도 채워진 적이 없는가

데이터를 점검해보면 명확해집니다. 오래된 노드를 다 뒤져도 그 필드가 채워진 게 0건이라면, 그건 "구현이 안 됐다"가 아니라 "구현 의지가 자연스럽게 막혔다"는 신호입니다. 개발자 본인이 무의식적으로 채우지 않았던 거예요.

이번 케이스에서 AI 평가 필드는 사용 데이터 0건이었습니다. 손실 없음이 확인되니 폐기에 망설임이 없었습니다.

3. 사용자가 그 필드를 보고 "왜 비었지?"라고 묻는가

사용자가 의문을 가지는 빈 박스는 두 가지 신호 중 하나입니다. 진짜 미구현이거나 의도 중복이거나. 그런데 같은 화면의 다른 필드가 이미 같은 일을 하고 있다면, 사용자의 의문은 사실 "왜 이 박스가 따로 있지?"라는 의미입니다. 본인은 그렇게 표현하지 못하지만요.

4. 채우는 호출 경로가 코드에 존재하는가

코드 검토 결과 채우는 호출 자체가 없었습니다. "구현을 안 했다"가 아니라 "구현 경로가 처음부터 설계되지 않았다"는 신호입니다. 시간 부족이면 보통 "주석 처리된 호출", "TODO", "임시 placeholder" 같은 흔적이 남는데, 그게 전혀 없으면 의도 중복 가능성이 높습니다.

이 네 가지 신호가 다 맞으면 거의 확실하게 의도 중복입니다. 채우지 말고 지워야 합니다.

빈 박스를 발견했을 때 3가지 길

진단이 끝나면 결정이 남습니다. 빈 박스를 어떻게 처리할지 보통 세 가지 길이 있습니다.

옵션 A — 채우기 (구현)

원래 의도를 살려서 generate 호출을 추가합니다. 박스가 채워집니다. 다만 의도 중복이 본질이었다면 중복 그대로 남습니다.

장점: 빠른 해결, 화면 완성도 올라감
단점: 의도 중복이 본질이면 사용자 혼란이 누적됨

옵션 B — 숨기기 (UI만)

UI에서 박스만 안 보이게 처리합니다. 백엔드 인프라(DTO, 서비스 메서드, 컨트롤러 엔드포인트)는 그대로 남깁니다.

장점: 빠른 해결, 미래에 다시 활성화 가능
단점: 백엔드 인프라가 잔존해 코드 노이즈가 됨. 6개월 뒤 누군가 "이게 뭐지?" 하고 다시 활성화하려고 시도할 위험

옵션 C — 완전 제거

UI + DTO + 서비스 메서드 + 컨트롤러 엔드포인트 + 노드 필드 + 타입 정의까지 전 계층에서 삭제합니다.

장점: 의도 중복 본질을 인정하고 정리 완료. 미래 재활성화 유혹 자체가 사라짐
단점: 작업 범위가 가장 큼

선택은 옵션 C — 완전 제거였습니다. 이유는 세 가지였어요.

첫째, 의도가 다른 필드와 본질적으로 중복이었습니다. 진단이 끝났으니 망설임이 없었습니다.

둘째, 미구현 상태가 우연이 아니라 정책 충돌의 결과였습니다. 개발자 본인이 무의식적으로 채우지 않았던 거예요. 이걸 강제로 채우면 본능을 거스르는 작업이 됩니다.

셋째, 어설프게 남기면 미래의 자신이 또 헷갈립니다. "구현 안 한 거네, 채워야지" 하고 같은 실수를 시도할 위험이 컸어요. 정정 노트만으로는 부족하고, 코드 자체가 깨끗해져야 했습니다.

한 가지 의도적 보존

전 계층 제거를 하면서 한 가지를 의도적으로 보존했습니다. 주간 리포트의 AI 평가 필드는 그대로 유지했어요.

이유는 단순했습니다. 주간 리포트는 일일 리포트와 사용 맥락이 다릅니다. 일일 리포트의 종합 인사이트는 "오늘의 작업 요약"인데, 주간 리포트의 AI 평가는 "한 주간의 흐름 분석"이라는 별개 의도를 노립니다. 같은 이름이지만 다른 일을 하고 있었습니다.

여기서 한 가지 원칙이 드러납니다. 이름이 같다고 다 중복은 아니다. 진짜 중복인지는 의도와 사용 맥락을 봐야 합니다.

만약 "AI 평가"라는 이름만 보고 전부 제거했다면, 주간 리포트의 진짜 LLM 작성 필드까지 사라졌을 거예요. 진단을 필드 이름이 아니라 의도와 사용 맥커락 기준으로 했기 때문에 정확한 정리가 가능했습니다.

의사결정자가 점검할 4가지

제품 UI를 정리하거나 기능 폐기 결정을 검토하실 때 점검할 일반 체크리스트입니다.

1. 빈 필드의 원인을 진단합니다

"채우면 된다"는 본능을 의심합니다. 빈 필드가 시간 부족인지, 의도 중복인지, 정책 충돌인지 진단을 먼저 합니다. 진단 없이 채우면 중복이 그대로 남습니다.

2. 같은 화면의 다른 필드를 함께 봅니다

빈 필드 자체만 보지 말고 같은 화면 전체의 의도 분포를 봅니다. 비슷한 의도의 필드가 두 개 이상이면 의도 중복일 가능성이 높습니다.

3. 사용 데이터로 폐기 안전성을 확인합니다

데이터가 0건이면 폐기에 망설일 이유가 없습니다. 데이터가 일부 있으면 마이그레이션 또는 이관 절차가 필요합니다. 사용 데이터 점검이 의사결정 속도를 높여줍니다.

4. UI만 숨기지 말고 전 계층을 정리합니다

폐기를 결정했다면 UI + 백엔드 + DTO + 컨트롤러 + 데이터까지 전부 정리합니다. UI만 숨기면 미래 재활성화 유혹이 남고, 코드 노이즈가 누적됩니다.

비슷한 발상이 다른 운영 결정에서도 흐릅니다. 본능적 액션 전에 진단을 한 번 끼워 넣는 것, 이름이 아니라 의도와 사용 맥락으로 판단하는 것. 제품 정리의 핵심 기준입니다.

마무리

일일 리포트의 AI 평가 박스가 항상 비어 있어서 처음에는 채우려고 했습니다. 코드를 열어보니 같은 화면의 다른 필드가 이미 같은 일을 하고 있었어요. 미구현이 아니라 의도 중복이 본질이었습니다. 결정은 전 계층 제거였습니다. 주간 리포트의 같은 이름 필드는 다른 의도를 노리기에 의도적으로 보존했습니다.

핵심 교훈은 세 가지입니다.

"비어있다 = 채워라"는 본능을 의심한다 — 빈 필드의 원인은 시간 부족일 수도 있고 의도 중복일 수도 있음

진단을 의도와 사용 맥락 기준으로 한다 — 필드 이름만 보면 보존해야 할 것까지 제거할 위험

폐기를 결정하면 전 계층을 정리한다 — UI만 숨기면 미래 재활성화 유혹이 남아 같은 실수를 반복

제품 UI 정리·기능 폐기 결정·미사용 필드 정비를 검토하신다면, 이번 글의 4가지 체크리스트(원인 진단 / 화면 전체 의도 분포 / 사용 데이터 확인 / 전 계층 정리)를 한 번 살펴보시길 추천합니다. 본능적 액션 전에 진단을 한 번 끼워 넣으면 제품이 깔끔해집니다.