refactor(core): 온보딩 전환 후 이전 내비게이션 콜백 API 제거

작업 유형

refactor — 동작 변경 없는 구조·책임·경계 개선

주 담당 모듈

core — 코어

개요

#2001에서 FeatureNavigationCallbacks를 제공하고 기존 FeatureStackBoundary 타입 별칭·팩토리로 소스 호환을 유지합니다. 애프터노트·수신자·앱의 타입 사용처는 같은 PR에서 전환하며 온보딩은 수정하지 않습니다. 설정 Nav3 이관은 별도 Draft PR #1962에 보류되어 있으므로, 제거 전에 해당 브랜치를 포함한 모든 실제 소비처를 다시 확인합니다.

이 이슈의 남은 범위는 온보딩 담당자의 #1997 전환 완료 후 코어의 구 API를 제거하는 것입니다. 정상적인 호환 API 이관이며 소유권 예외 라벨을 사용하지 않습니다.

완료 조건:

refactor(onboarding): 호환 API 제공 후 내비게이션 콜백 타입 이름 전환 #1997 통합 후 프로덕션·테스트에서 FeatureStackBoundary 소비가 0개인지 확인
코어의 이전 타입 별칭과 이전 팩토리만 제거
앱 컴파일·온보딩 및 공통 내비게이션 테스트 통과

FeatureNavDisplay 및 OnboardingNavHost의 공개 boundary named argument는 기존 호출 계약으로 유지합니다. 타입 별칭 제거와 공개 파라미터명 변경을 혼동하지 않습니다.

#2001는 이 후속 제거를 기다리지 않고 독립 완료합니다. 코어 추가 → 담당자별 소비처 전환 → 코어 구 API 제거 순서입니다.

참고

선행 소비처 전환: #1997
호환 API 제공: #2001

관계와 선행 작업 실측 (2026-09-13 21:55 KST)

blocked_by 실태

gh api repos/Afternote/Afternote-FE/issues/1996/dependencies/blocked_by 결과는 #1997 하나다. blocking 은 비어 있다. 체인은 아래처럼 이미 본문의 순서대로 서 있어서 고칠 것이 없었다.

#1999  --blocks-->  #1997  --blocks-->  #1996

#1999 를 #1996 에 직접 거는 edge 는 없다. #1997 을 거쳐 전이로 이어지므로 중복 edge 는 추가하지 않았다. 라벨로 표현된 대기는 없다.

본문이 참조하는 것들의 현재 상태

번호	종류	상태	담당	비고
#1997	이슈	open	Sadturtleman	blocked_by #1999, blocking #1996. 코멘트 0개
#1999	이슈	open	1hyok	`pr-open` 라벨, blocking #1997
#2001	PR	open, 머지 안 됨	1hyok	`refactor/1999-navigation-callbacks` -> `develop`, head `bd674882`
#1962	PR	open, draft, 머지 안 됨	1hyok	`codex/1695-setting-nav3` -> `develop`, head `999612c2`

#2001 의 리뷰 상태는 REVIEW_REQUIRED 이고 Sadturtleman 에게 리뷰 요청이 걸려 있다. 제출된 리뷰는 0건. 체크는 전부 pass 이며 mergeable_state 는 blocked, 즉 CI 가 아니라 리뷰가 막고 있다.

#1962 는 draft 인데도 Sadturtleman 의 APPROVED 가 2026-09-11T01:06:57Z 에 이미 달려 있다. draft 라 큐에는 못 들어간다.

FeatureStackBoundary 소비 전수 집계

세는 방법은 git grep -n FeatureStackBoundary <ref> 로 파일 종류 제한 없이 센 것이다. 매칭은 전부 .kt 였고 문서나 설정 파일에는 0건이다. 컴파일러가 해석한 참조 수가 아니라 식별자 텍스트 기준이라는 점은 감안이 필요하다. 빌드는 돌리지 않았다.

origin/develop (`7d87aa3f4761e428de39fee6f8c094f216fa3cf9`)

총 45줄 / 22파일. 선언 파일 core/ui/src/main/kotlin/com/afternote/core/ui/navigation/FeatureStackBoundary.kt 의 4줄을 빼면 소비는 41줄 / 21파일이다. FeatureNavigationCallbacks 는 0줄이다.

구역	파일	줄
app	1	3
core/ui (선언 4줄 포함)	4	7
feature/afternote	8	17
feature/onboarding	4	7
feature/receiver	5	11
합계	22	45

소스셋으로 가르면 src/main 15파일 32줄, src/test 7파일 13줄이다. src/androidTest 는 0건.

온보딩 몫 7줄의 위치는 이렇다.

feature/onboarding/presentation/src/main/java/.../navigation/OnboardingExternalActions.kt:8
feature/onboarding/presentation/src/main/java/.../navigation/OnboardingLocalNavActions.kt:5,18
feature/onboarding/presentation/src/main/java/.../navigation/OnboardingNavHost.kt:13,45
feature/onboarding/presentation/src/test/kotlin/.../navigation/OnboardingLocalNavActionsTest.kt:5,24

PR #2001 head (`bd674882617954d954c9db496b23893d21597776`)

FeatureStackBoundary 11줄 / 6파일, FeatureNavigationCallbacks 40줄 / 19파일.

11줄의 구성은 코어 호환 계층 4줄과 온보딩 소비 7줄이다.

core/ui/.../FeatureStackBoundary.kt:9   public typealias FeatureStackBoundary = FeatureNavigationCallbacks
core/ui/.../FeatureStackBoundary.kt:12  public fun FeatureStackBoundary(onExit: () -> Unit): FeatureStackBoundary =
core/ui/.../FeatureStackBoundary.kt:13      object : FeatureStackBoundary {
core/ui/.../FeatureNavigationCallbacks.kt:31  public fun FeatureNavigationCallbacks(onExit: () -> Unit): FeatureNavigationCallbacks = FeatureStackBoundary(onExit)

앱, 애프터노트, 수신자 사용처가 같은 PR 에서 전환된다는 본문 서술은 실측과 맞는다. 이 세 구역의 옛 이름 소비는 0이 된다.

열린 PR 62개 전수 스캔

2026-09-13 21:55 KST 에 git fetch origin --prune 한 head 기준이다. tip 은 그 브랜치 끝에서 센 FeatureStackBoundary 줄 수.

tip 줄 수	PR 수	무엇인가
45	45	develop 과 같음. 이 주제를 건드리지 않는 브랜치
51	6	develop 45줄에 설정 6줄을 더 얹은 브랜치
11	8	#2001 을 조상으로 가져 이름 전환이 들어간 브랜치
0	3	FeatureStackBoundary 도입 이전 베이스 (#1905, #1708, #1365)

51줄짜리 6개가 이 이슈의 실제 위험이다. #2067, #2044, #2043, #2042, #2036, #1930 이고, 전부 설정 Nav3 스택의 리네임 이전 지점(186bcced6)에 얹혀 있으며 bd674882 를 조상으로 갖지 않는다. 여섯 PR 이 더하는 6줄은 모두 같다.

feature/setting/presentation/src/main/kotlin/.../navigation/SettingLocalNavActions.kt   +2
feature/setting/presentation/src/main/kotlin/.../navigation/SettingNavHost.kt           +2
feature/setting/presentation/src/test/kotlin/.../navigation/SettingLocalNavActionsTest.kt +2

11줄짜리 8개는 #2001, #1962, #1967, #1927, #1925, #2018, #2034, #2051 이다. 구성은 전부 코어 4줄과 온보딩 7줄로 #2001 head 와 같다.

본문 서술 중 실측과 어긋난 것

본문은 설정 Nav3 이관이 보류된 #1962 를 제거 전에 다시 확인할 대상으로 지목하고 있다. 실측은 반대였다. #1962 는 e01dd9816 로 #2001 을 이미 제 브랜치에 들여왔고, 설정 3파일 6줄은 이미 FeatureNavigationCallbacks 를 쓴다. #1962 가 그대로 머지돼도 옛 이름 소비는 늘지 않는다.

옛 이름을 되살릴 브랜치는 #1962 가 아니라 그 아래에 얹힌 #2067, #2044, #2043, #2042, #2036, #1930 여섯이다. 이들이 리베이스되지 않은 채 머지되면 제거 이후에 설정 3파일에서 옛 이름이 다시 들어온다.

또 하나. 본문의 완료 조건은 코어의 이전 타입 별칭과 이전 팩토리만 제거한다고 적었는데, #2001 head 에서 새 팩토리가 옛 팩토리를 호출한다(FeatureNavigationCallbacks.kt:31). 별칭과 옛 팩토리를 지우기만 하면 이 줄이 미해결 참조로 남는다. 제거 PR 은 이 한 줄을 object : FeatureNavigationCallbacks { override fun exit() = onExit() } 로 고쳐 닫아야 한다. 삭제 3줄에 수정 1줄이 붙는다는 뜻이다.

제거 시점에 확인할 숫자

다시 세지 않아도 되도록 기준값을 박아 둔다.

refactor(core): 내비게이션 콜백 이름 전환 분리 (#1999) #2001 머지 직후 develop: FeatureStackBoundary 11줄 / 6파일 (코어 4, 온보딩 7)
refactor(onboarding): 호환 API 제공 후 내비게이션 콜백 타입 이름 전환 #1997 완료 직후 develop: 4줄 / 2파일. 온보딩 7줄이 0이 되면 코어 호환 계층만 남는다
refactor(core): 온보딩 전환 후 이전 내비게이션 콜백 API 제거 #1996 완료 후: 0줄 / 0파일. FeatureStackBoundary.kt 파일 삭제와 FeatureNavigationCallbacks.kt:31 수정
제거 PR 을 열기 전 재확인 대상: 위 여섯 PR 의 head 가 bd674882 를 조상으로 갖는지 하나씩만 보면 된다

51줄 여섯 PR 은 새 소비처가 아니라 스테일 머지다 (2026-09-13 22:04 KST)

앞 코멘트에서 옛 이름 51줄로 나온 여섯 PR 을 이 이슈의 실제 위험으로 지목했다. 그 여섯을 더 파 보니 새로 생긴 소비처가 아니라 베이스를 늦게 따라온 결과였고, 리베이스 없이 베이스 재머지만으로 풀린다. 제거 PR 을 여는 사람이 이 여섯 앞에서 멈추지 않도록 근거를 남긴다.

앞 코멘트의 기준 숫자는 오늘 다시 세도 그대로다. origin/develop(7d87aa3f) 45줄 22파일, bd674882 11줄 6파일, 열린 PR 62건의 45/51/11/0 분포, #1962 가 bd674882 의 후손인 것까지 변동 없다.

여섯은 한 스택이고 그 베이스는 이미 전환돼 있다

루트가 #1930(handoff/1920-setting-1hyok)이고, 그 베이스가 #1925(handoff/708-setting-1hyok)다. #1925 의 head 7dfcb431 은 bd674882 를 조상으로 가지며 설정 3파일이 이미 새 이름을 쓴다.

7dfcb431:.../navigation/SettingLocalNavActions.kt:5,10
7dfcb431:.../navigation/SettingNavHost.kt:13,47
7dfcb431:.../navigation/SettingLocalNavActionsTest.kt:9,26

즉 전환본은 이미 이 스택의 베이스에 들어와 있고, 여섯 PR 이 그 지점을 아직 안 당겨왔을 뿐이다.

충돌 없이 들어온다는 근거

여섯이 develop 보다 더하는 6줄은 전부 같은 설정 3파일이다. 각 PR 이 handoff/708-setting-1hyok 에서 갈린 지점 이후로 feature/setting/presentation/.../navigation 을 자기 쪽에서 고친 적이 한 번도 없다. 그러니 베이스를 다시 머지하면 그 경로는 한쪽만 바뀐 상태라 전환본이 그대로 들어온다.

PR	갈린 지점	설정 옛 이름 줄
#1930	`9de394f7`	6
#2044	`9de394f7`	6
#2067	`9de394f7`	6
#2036	`62f89b5b`	6
#2042	`62f89b5b`	6
#2043	`62f89b5b`	6

세는 데 쓴 명령은 이렇다.

MB=$(git merge-base 7dfcb431 <head>)
git diff --name-only "$MB" <head> -- \
  feature/setting/presentation/src/main/kotlin/com/afternote/feature/setting/presentation/navigation \
  feature/setting/presentation/src/test/kotlin/com/afternote/feature/setting/presentation/navigation

다음 착수자가 할 일

여섯을 리베이스해 달라고 담당자에게 요청할 필요가 없다. 각 PR 이 제 베이스를 평소대로 다시 머지하면 스택을 타고 전환본이 내려간다. 제거 PR 을 열기 직전에 여섯 head 가 bd674882 를 조상으로 갖는지만 한 번씩 확인하면 되고, 그 확인이 통과하면 설정 쪽에서 옛 이름이 되살아날 경로는 없다.

위 판정은 오늘 git fetch origin --prune 한 head 기준이다. 브랜치가 그 사이에 움직였다면 갈린 지점부터 다시 잡아야 한다.

Navigation Menu

refactor(core): 온보딩 전환 후 이전 내비게이션 콜백 API 제거 #1996

작업 유형

주 담당 모듈

개요

참고

관계와 선행 작업 실측 (2026-09-13 21:55 KST)

blocked_by 실태

본문이 참조하는 것들의 현재 상태

FeatureStackBoundary 소비 전수 집계

origin/develop (`7d87aa3f4761e428de39fee6f8c094f216fa3cf9`)

PR #2001 head (`bd674882617954d954c9db496b23893d21597776`)

열린 PR 62개 전수 스캔

본문 서술 중 실측과 어긋난 것

제거 시점에 확인할 숫자

51줄 여섯 PR 은 새 소비처가 아니라 스테일 머지다 (2026-09-13 22:04 KST)

여섯은 한 스택이고 그 베이스는 이미 전환돼 있다

충돌 없이 들어온다는 근거

다음 착수자가 할 일

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

refactor(core): 온보딩 전환 후 이전 내비게이션 콜백 API 제거 #1996

Description

작업 유형

주 담당 모듈

개요

참고

Activity

1hyok commented on Sep 13, 2026

관계와 선행 작업 실측 (2026-09-13 21:55 KST)

blocked_by 실태

본문이 참조하는 것들의 현재 상태

FeatureStackBoundary 소비 전수 집계

origin/develop (7d87aa3f4761e428de39fee6f8c094f216fa3cf9)

PR #2001 head (bd674882617954d954c9db496b23893d21597776)

열린 PR 62개 전수 스캔

본문 서술 중 실측과 어긋난 것

제거 시점에 확인할 숫자

1hyok commented on Sep 13, 2026

51줄 여섯 PR 은 새 소비처가 아니라 스테일 머지다 (2026-09-13 22:04 KST)

여섯은 한 스택이고 그 베이스는 이미 전환돼 있다

충돌 없이 들어온다는 근거

다음 착수자가 할 일

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

origin/develop (`7d87aa3f4761e428de39fee6f8c094f216fa3cf9`)

PR #2001 head (`bd674882617954d954c9db496b23893d21597776`)