You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
기존 QA에서는 4자리 입력이 앱 잠금 PIN으로 동작했다. 이는 제품이 그 인증 단계를 유지하기로 승인했다는 뜻이 아니다. 임의 문구 교체·PIN 설정 화면 유도·계정 비밀번호 전환 계획을 제거한다.
PM 확인이 필요한 결정
패스키 등록에 자체 앱 PIN 단계가 필요한지, Credential Manager 인증과 어떤 관계인지, PIN 미설정 사용자의 진입·취소·복구 흐름과 명칭을 PM에게 확인한다. #765와 결정을 공유한다.
완료 기준
PM의 명시적인 답변과 적용 범위·근거 링크를 기록한다. 답변 전에는 구현·재개·테스트 완료 체크리스트를 예약하지 않는다. 결정 후 최신 코드와 계약을 대조해 실제 필요한 작업만 정의한다. 디자이너에게 질문하거나 태그하지 않으며, 미답변이나 과거 FE 재량 위임을 승인으로 해석하지 않는다.
정리 근거
2026-09-13 사용자 요청에 따라 미확정 구현 예약을 제거했다. 기능 구현 완료를 의미하지 않는다. 기존 댓글의 실측은 참고 자료이며, 상충하는 옛 구현 지시는 현재 범위를 대체하지 않는다.
changed the title [-]fix(setting): 패스키 등록의 "비밀번호로 인증하기" 가 4자리 PIN 을 요구 — 계정 비밀번호와 구분 안내 없음[/-][+]패스키 등록의 "비밀번호로 인증하기" 가 4자리 PIN 을 요구 — 계정 비밀번호와 구분 안내 없음[/+]on Aug 28, 2026
코드 변경 없이 origin/develop7d87aa3f4 를 읽어 확인한 내용입니다. 본문과 2026-08-25 댓글이 "4자리 입력이 앱 잠금 PIN 으로 동작한다" 를 전제로 PM 질문을 짜 놨는데, 그 전제가 코드와 어긋납니다. PM 질문의 형태가 바뀌므로 답변을 기다리는 동안 기록만 남깁니다. 완료 기준(PM 의 명시적 답변 기록)은 그대로 미충족이고, 이 코멘트로 닫지 않습니다.
확인 버튼도 길이 검사조차 없습니다(PassKeyPasswordScreen.kt:37, onConfirmClick = { currentOnPinComplete(uiState.pin) }).
8-25 QA 시점의 4e0a648eb 도 같은 구조였습니다(그때는 38-43 줄의 LaunchedEffect, 69 줄의 onConfirmClick). 그 커밋의 DataStore 키 전수에도 PIN 키가 없습니다. 따라서 그 댓글의 "앱 잠금 PIN 1234 를 넣자 인증이 통과했습니다" 는 값이 일치했다는 증거가 아닙니다. 어떤 4자리든 통과합니다.
3. PIN 미설정 분기가 코드에 없으므로 O3 의 미확인 질문은 기기 QA 없이 답이 난다
설정 여부를 읽는 코드 자체가 없어 분기가 성립하지 않습니다. 미설정 상태에서도 같은 키패드가 뜨고 4자리를 채우면 같은 경로로 통과합니다. 8-25 댓글의 "남은 확인" 은 이것으로 닫힙니다.
그래서 PM 에게 물을 것도 "PIN 미설정 사용자의 진입·취소·복구 흐름" 이 아니라 다음 둘로 좁혀야 합니다. 첫째, 대조 대상이 없는 이 단계를 남길 것인가. 둘째, 남긴다면 무엇과 대조할 것인가(앱 잠금 PIN 을 실제로 저장해서 쓸 것인가, 아니면 Credential Manager 인증으로 대체할 것인가).
승인 상태로 열려 있는 #1927(head handoff/555-setting-1hyok9a6c033eb)이 이 화면을 이미 바꿔 놨습니다. 스택은 #1927 → #1967 → #1962 → develop 입니다. 그 head 에서는 4자리가 채워지면 실제 Credential Manager 와 서버 register 를 태우고, 서버 성공 이후에만 완료로 표시해 즉시 savePasskeyRegistered() 하던 가짜 성공을 없앱니다(PassKeyPasswordScreen.kt:57-68).
다만 그 head 에서도 입력한 4자리는 저장되지도, 대조되지도, 전송되지도 않습니다. head 의 AppLockSetupViewModel 역시 @Inject constructor() 로 주입 의존이 0입니다. 즉 머지 후에도 이 PIN 단계는 등록을 시작시키는 버튼일 뿐입니다. 결정이 "남긴다" 로 나면 저장·대조를 새로 만들어야 하고, "없앤다" 로 나면 #1927 머지 뒤에 지우는 편이 충돌이 없습니다.
같은 파일을 건드리는 다른 열린 PR 은 #1962(스택 하단)와 #1993 인데, #1993 은 Compose Preview 제거만이라 동작은 바꾸지 않습니다. 열린 PR 62건의 본문을 직접 조회했고 이 이슈를 Closes 하는 PR 은 없습니다.
5. 본문에서 정정할 항목
개요의 "기존 QA에서는 4자리 입력이 앱 잠금 PIN으로 동작했다" 는 성립하지 않습니다. 저장된 PIN 이 없어 대조가 일어난 적이 없습니다(위 1, 2번).
"PIN 미설정 사용자의 진입·취소·복구 흐름" 이라는 질문 전제도 성립하지 않습니다. 설정/미설정 분기가 코드에 없습니다(위 3번).
"기존 댓글의 실측은 참고 자료" 라는 문장은 유지하되, 8-25 댓글의 "요구하는 값은 앱 잠금 PIN 입니다" 한 줄은 참고 자료가 아니라 오독으로 읽어야 합니다.
본문 수정은 하지 않았습니다. 완료 기준을 좁히는 편집이 아니라 진단을 바꾸는 편집이고, 그 진단 자체가 PM 이 답할 대상이기 때문입니다. 정정은 이 코멘트로 남깁니다.
부수 사실 하나. PinSetupStep enum 에는 ENTER_NEW, CONFIRM_NEW, ENTER_CURRENT 셋이 있지만 라우트가 실제로 넘기는 값은 ENTER_NEW 하나뿐이고, 나머지 둘은 Preview 와 스크린샷 테스트에서만 쓰입니다. 확인 재입력 단계는 문구만 있고 배선돼 있지 않습니다.
셋 다 "PIN 이 저장돼 있고 그 값으로 인증한다" 위에 서 있습니다. #572 본문의 "당시 PIN 저장·패스키 인증 사용은 확인됐고" 도 같은 이유로 어긋나고, #765 의 "자체 PIN 단계의 필요성" 질문도 대조 대상이 없다는 사실 위에서 다시 써야 합니다. 다음 착수자가 "PIN 이 저장돼 있다" 는 전제로 시작하지 않도록 세 이슈에 같은 사실을 걸어 둡니다.
Activity
OnlyReadOneBook commentedon Aug 25, 2026
재현 확인 + 요구값 규명 (develop
4e0a648eb, 2026-08-25 17:05 KST)설정 → 패스키 관리 → 패스키 등록 → "비밀번호로 인증하기" 를 누르면 4자리 숫자 키패드와 "비밀번호를 입력해 주세요." 가 뜹니다.
계정 비밀번호는 서버
PasswordValidation.REGEX기준 8~15자 영문+숫자+특수문자라 이 키패드로는 입력 자체가 불가능합니다.요구하는 값은 앱 잠금 PIN 입니다. 직전에 설정한 앱 잠금 PIN
1234를 넣자 인증이 통과했습니다. 즉 동작은 정상이고 라벨이 요구값과 어긋난 것입니다 — "비밀번호" 가 아니라 "앱 잠금 비밀번호" 임이 드러나야 합니다.남은 확인
1차 QA O3 이 남긴 질문("앱 잠금 PIN 미설정 상태의 동작")은 이번 실측에서 PIN 이 이미 설정된 뒤라 확인하지 못했습니다. 미설정 상태에서 이 버튼을 누르면 무엇을 요구하는지가 별도 확인 대상입니다.
관련 — 앱 잠금 PIN 이 저장은 되는데 잠금 게이트만 미적용이라는 점은 #572 에 적었습니다.
docs(qa): 로그인 상태 설정 구간 실측 결과를 반영한다
[-]fix(setting): 패스키 등록의 "비밀번호로 인증하기" 가 4자리 PIN 을 요구 — 계정 비밀번호와 구분 안내 없음[/-][+]패스키 등록의 "비밀번호로 인증하기" 가 4자리 PIN 을 요구 — 계정 비밀번호와 구분 안내 없음[/+][-]패스키 등록의 "비밀번호로 인증하기" 가 4자리 PIN 을 요구 — 계정 비밀번호와 구분 안내 없음[/-][+]패스키 PIN 단계의 용도·미설정 흐름을 PM에게 확인한다[/+]OnlyReadOneBook commentedon Sep 13, 2026
develop 실측: 이 PIN 단계는 아무 값도 저장하지 않고 대조하지도 않는다
코드 변경 없이
origin/develop7d87aa3f4를 읽어 확인한 내용입니다. 본문과 2026-08-25 댓글이 "4자리 입력이 앱 잠금 PIN 으로 동작한다" 를 전제로 PM 질문을 짜 놨는데, 그 전제가 코드와 어긋납니다. PM 질문의 형태가 바뀌므로 답변을 기다리는 동안 기록만 남깁니다. 완료 기준(PM 의 명시적 답변 기록)은 그대로 미충족이고, 이 코멘트로 닫지 않습니다.1. 앱 잠금 PIN 은 develop 어디에도 저장되지 않는다
AppLockSetupViewModel의 생성자는 주입 의존이 0이고, 입력한 pin 은AppLockSetupUiState안에서만 삽니다(AppLockSetupViewModel.kt:12-14).라우트 두 곳 모두 완성된 pin 을 받아서 그대로 버립니다.
DataStore 키를 전수 조사하면(테스트 소스 제외) 8개뿐이고 PIN 키는 없습니다.
UserProfileDataSource.kt:31-32user_name,is_passkey_registeredTokenDataSource.kt:28-29access_token,refresh_tokenLocalStoreRegistryImpl.kt:201-202session_store_names,device_store_namesNotificationPermissionRequestStore.kt:56has_requested_post_notificationsReceiverMasterKeyDataSource.kt:17receiver_auth_codeSharedPreferences나 Room 으로 PIN 을 쓰는 경로도 없습니다. 저장하는 곳이 없으니 읽어서 대조하는 곳도 없습니다.2. "비밀번호로 인증하기" 단계는 입력값을 검사하지 않는다
PassKeyMakingContent.kt:83-87 의 버튼이 여는 화면이
PassKeyPasswordScreen입니다. 여기서 4자리가 채워지는 순간 대조 없이 통과합니다.확인 버튼도 길이 검사조차 없습니다(
PassKeyPasswordScreen.kt:37,onConfirmClick = { currentOnPinComplete(uiState.pin) }).8-25 QA 시점의
4e0a648eb도 같은 구조였습니다(그때는 38-43 줄의LaunchedEffect, 69 줄의onConfirmClick). 그 커밋의 DataStore 키 전수에도 PIN 키가 없습니다. 따라서 그 댓글의 "앱 잠금 PIN1234를 넣자 인증이 통과했습니다" 는 값이 일치했다는 증거가 아닙니다. 어떤 4자리든 통과합니다.3. PIN 미설정 분기가 코드에 없으므로 O3 의 미확인 질문은 기기 QA 없이 답이 난다
설정 여부를 읽는 코드 자체가 없어 분기가 성립하지 않습니다. 미설정 상태에서도 같은 키패드가 뜨고 4자리를 채우면 같은 경로로 통과합니다. 8-25 댓글의 "남은 확인" 은 이것으로 닫힙니다.
그래서 PM 에게 물을 것도 "PIN 미설정 사용자의 진입·취소·복구 흐름" 이 아니라 다음 둘로 좁혀야 합니다. 첫째, 대조 대상이 없는 이 단계를 남길 것인가. 둘째, 남긴다면 무엇과 대조할 것인가(앱 잠금 PIN 을 실제로 저장해서 쓸 것인가, 아니면 Credential Manager 인증으로 대체할 것인가).
4. 결정 후 손댈 코드는 develop 이 아니라 열린 PR #1927 이다
승인 상태로 열려 있는 #1927(head
handoff/555-setting-1hyok9a6c033eb)이 이 화면을 이미 바꿔 놨습니다. 스택은 #1927 → #1967 → #1962 → develop 입니다. 그 head 에서는 4자리가 채워지면 실제 Credential Manager 와 서버 register 를 태우고, 서버 성공 이후에만 완료로 표시해 즉시savePasskeyRegistered()하던 가짜 성공을 없앱니다(PassKeyPasswordScreen.kt:57-68).다만 그 head 에서도 입력한 4자리는 저장되지도, 대조되지도, 전송되지도 않습니다. head 의
AppLockSetupViewModel역시@Inject constructor()로 주입 의존이 0입니다. 즉 머지 후에도 이 PIN 단계는 등록을 시작시키는 버튼일 뿐입니다. 결정이 "남긴다" 로 나면 저장·대조를 새로 만들어야 하고, "없앤다" 로 나면 #1927 머지 뒤에 지우는 편이 충돌이 없습니다.같은 파일을 건드리는 다른 열린 PR 은 #1962(스택 하단)와 #1993 인데, #1993 은 Compose Preview 제거만이라 동작은 바꾸지 않습니다. 열린 PR 62건의 본문을 직접 조회했고 이 이슈를 Closes 하는 PR 은 없습니다.
5. 본문에서 정정할 항목
본문 수정은 하지 않았습니다. 완료 기준을 좁히는 편집이 아니라 진단을 바꾸는 편집이고, 그 진단 자체가 PM 이 답할 대상이기 때문입니다. 정정은 이 코멘트로 남깁니다.
부수 사실 하나.
PinSetupStepenum 에는ENTER_NEW,CONFIRM_NEW,ENTER_CURRENT셋이 있지만 라우트가 실제로 넘기는 값은ENTER_NEW하나뿐이고, 나머지 둘은 Preview 와 스크린샷 테스트에서만 쓰입니다. 확인 재입력 단계는 문구만 있고 배선돼 있지 않습니다.6. #572, #765 와 공유하는 오전제
셋 다 "PIN 이 저장돼 있고 그 값으로 인증한다" 위에 서 있습니다. #572 본문의 "당시 PIN 저장·패스키 인증 사용은 확인됐고" 도 같은 이유로 어긋나고, #765 의 "자체 PIN 단계의 필요성" 질문도 대조 대상이 없다는 사실 위에서 다시 써야 합니다. 다음 착수자가 "PIN 이 저장돼 있다" 는 전제로 시작하지 않도록 세 이슈에 같은 사실을 걸어 둡니다.
OnlyReadOneBook commentedon Sep 18, 2026
PM 결정 대기 항목은 깃허브 이슈로 두지 않고 피그마 질문 한 자리에만 둔다(2026-09-18 결정). 이 이슈의 질문은 피그마 스레드에 걸려 있다: https://www.figma.com/design/UP9ZR186jHvRBicjA2SOea/?node-id=4327-64956#1932490741 (#765·#572 와 합쳐 하나로 물었다.) 답이 오면 그 답을 근거로 구현 이슈를 새로 만든다.