Repository navigation
ErrorReporter 채택 범위 정리 — 실패 20곳이 Logcat 에만 남는다 #928
Description
담당자별 하위 이슈로 분할했다. 실제 작업은 아래 세 이슈에서 하고, 이 이슈는 진행 상황만 추적한다.
| 이슈 | 담당 | 범위 |
|---|---|---|
| #962 | @1hyok | core/network·core/data·feature/afternote — Log.e 16곳 분류 |
| #963 | @koongmai | feature/setting Log.e 4곳 분류 + feature/timeletter 계측 신설 |
| #964 | @Sadturtleman | feature/mindrecord 계측 신설 (현재 기록 0건) |
세 이슈는 모듈이 겹치지 않아 서로 기다릴 필요 없이 병렬로 진행할 수 있고, 각 이슈에 전제·제약·판단 기준을 복제해 두어 이 이슈를 참조하지 않아도 된다.
배경 (요약)
Result.failure 로 흡수되는 실패는 Crashlytics 자동 수집(uncaught 예외)에 잡히지 않는다. ErrorReporter 를 거쳐 명시적으로 기록해야 릴리즈에서 보인다(#536 · #544 에서 도입·확대).
인프라는 이미 올바르게 일원화돼 있고 4개 모듈 30곳에서 쓰이고 있다. 문제는 남은 쪽이다 — 20곳이 Log.e/Log.w 로 Logcat 에 찍고 끝나고, mindrecord·timeletter 는 아예 아무 데도 남기지 않는다.
채택 현황
6123a68a 기준 실측이다.
| 모듈 | Log.e/Log.w |
ErrorReporter 호출 |
담당 이슈 |
|---|---|---|---|
feature/afternote/presentation |
9 | ✅ 17곳 | #962 |
core/network |
5 | TokenReissuer 만 |
#962 |
feature/setting/presentation |
4 | ❌ 0곳 | #963 |
feature/afternote/data |
1 | ❌ 0곳 | #962 |
core/data |
1 | ❌ 0곳 | #962 |
app |
0 | ✅ 5곳 | — 완료 |
feature/onboarding/presentation |
0 | ✅ 7곳 | — 완료 |
feature/mindrecord |
0 | ❌ 둘 다 없음 | #964 |
feature/timeletter |
0 † | ❌ 둘 다 없음 | #963 |
† debug 소스셋의 TimeLetterDebugMockNetworkInterceptor.kt:67 에 Log.w 가 1건 있으나 릴리즈 빌드에 포함되지 않아 집계에서 뺐다.
손대지 않는 것
- 인프라 자체 —
core:common에 인터페이스,app에 Crashlytics 구현. Crashlytics SDK 를 코드에서 참조하는 곳은app/.../reporting/뿐이고 다른 모듈의 SDK 의존은 0건이다 - core 로도 app 으로도 몰지 않는다 — core 로 몰면
core:common이 Firebase 의존을 갖고 전 모듈이 딸려온다. app 으로 몰면core:network의TokenReissuer때문에 core → app 역의존이 된다 - stage 어휘의 모듈별 분산 — 도메인 어휘라서 의도된 설계다
- 이미 채택이 끝난 3개 모듈의 기존 호출부
공통 제약
Crashlytics 는 non-fatal 을 최근 8건만 보관하고 초과분을 오래된 것부터 버린다(근거). 일괄 치환하면 잡음이 한도를 채워 실제 장애를 밀어낸다 — 분류 작업이지 치환이 아니다.
Activity
Sadturtleman commentedon Aug 27, 2026
근거 추가 —
NullableTodayMoodSerializer의 조용한 폴백 (#591 에서 옮김)#591 을 닫으며 남은 사각을 여기로 옮깁니다.
feature/mindrecord/data/.../NullableTodayMoodSerializer.kt는 모르는 값을null로 접고 아무 신호도 남기지 않습니다.이 관대함 자체는 의도된 결정입니다 — 서버가 기분 종류를 늘렸다고 그 주 전체를 날릴 이유가 없고, 이모지 한 칸만 비우면 됩니다. 그 판단은 유지돼야 합니다.
문제는 접었다는 사실이 어디에도 안 남는다는 것입니다. 실제로 이런 일이 있었습니다.
week[].emotion을"기쁨"으로 내려줬고, 캘린더 이모지가 한 개도 뜨지 않았습니다."HAPPY")이라 증상이 사라졌지만, 되돌아가면 같은 방식으로 다시 보이지 않습니다.즉 이 자리는 「실패가 Logcat 에도 안 남는」 20곳과 같은 성질이고, 관대한 폴백이라 오히려 더 조용합니다.
제안: 접는 순간
ErrorReporter에 원문 값과 필드를 남깁니다. 사용자 영향은 그대로 두고(이모지 한 칸만 빔) 서버 계약 변화만 관측 가능해집니다. 이 serializer 는 순수object라 DI 가 닿지 않으므로, 접힘을 매퍼 쪽으로 노출해 거기서 보고하는 형태가 맞아 보입니다 — 구조는 이 이슈에서 정하면 되겠습니다.OnlyReadOneBook commentedon Aug 29, 2026
추적 역할이 끝났다 — 닫는다 (2026-08-30)
이 이슈는 0823 에 담당자별 하위 이슈로 분할하고 진행 상황만 추적하는 역할로 남겨 뒀다. 세 갈래 모두 담당자 큐의 이슈로 서 있으므로 부모를 열어 둘 이유가 없다.
core/network·core/data·feature/afternoteLog.e16곳 분류feature/settingLog.e4곳 +feature/timeletter계측 신설feature/mindrecord계측 신설「내 어사인인데 실제 작업은 남의 모듈」 인 부모 이슈가 큐에 남아 있으면 남은 내 일이 무엇인지 흐려진다. 진행 상황은 #963 · #964 자체로 보이므로 이 부모는 닫는다. 방침(일괄 치환이 아니라 분류 작업 · Crashlytics non-fatal 8건 한도 · core/app 어느 쪽으로도 몰지 않는다)은 세 하위 이슈 본문에 이미 옮겨져 있다.