로그인한 계정을 나중에 고르고 싶을 때는 ‘계정만 등록’, 그 계정으로 늘 같은 사이트를 열고 싶을 때는 ‘계정 + 사이트 등록’을 고른다. 두 방식 모두 지금 쓰는 로그인 공간을 연결한다. 사이트 주소를 함께 저장할지는 사용자가 정한다.
새로 로그인한 계정을 목록에 넣고 싶다는 요청에, 사이트를 바로 여는 방식도 필요하다는 요구가 더해졌다. 개발본과 시험 기록을 보면 두 선택의 차이는 입력란에서 끝나지 않는다. 다시 고를 때 어느 탭을 쓰고, 재등록하면 무엇을 바꿀지도 정해야 했다.
등록 방식에 따라 다음 버튼도 달라져야 한다
등록 양식에는 알아보기 쉬운 계정 이름과 등록 방식이 있다. 사이트를 함께 등록하는 경우에만 열 주소를 입력한다. 계정만 남기려는 사람에게 목적지 주소까지 받으면, 입력해야 할 이유가 없는 칸이 생긴다.
목록의 버튼 문구도 방식에 맞췄다. ‘계정 사용’은 로그인 공간을 선택하는 행동이고, ‘사이트 열기’는 그 공간에서 저장한 주소를 여는 행동이다. 같은 등록 화면을 쓴다고 두 결과를 같은 이름으로 묶지 않았다.
- 계정만 등록 → ‘계정 사용’. 현재 프로젝트에 같은 로그인 공간의 사용자 탭이 있으면 그 탭을 선택하며, 특정 사이트로 이동시키지 않는다.
- 계정 + 사이트 등록 → ‘사이트 열기’. 저장한 주소와 로그인 공간이 모두 맞는 사용자 탭을 현재 프로젝트에서 찾는다. 없으면 새 탭을 연다.
- 계정만 등록한 공간에 재사용할 사용자 탭이 없다면 그 공간의 새 홈 탭을 연다. 직전에 보고 있던 사이트를 추측해 열지는 않는다.
저장하는 것은 새 인증이 아니라 기존 공간의 연결이다
구현에서 등록 항목은 기존 프로필에 이름·사이트 식별 정보·등록 방식·선택적인 목적지 주소를 붙인다. 아직 미지정이던 일반 로그인 공간도 새 공간으로 갈아 끼우지 않고, 같은 식별자를 유지한 채 목록에 올린다. 이 흐름은 비밀번호나 쿠키를 다른 공간에 복제하는 기능이 아니다.
‘업무용’이라는 이름은 사람이 고른 표시다. 같은 공간에서 사이트 계정을 바꾼 뒤 이름만 하나 더 적어도, 이전 계정의 인증이 따로 남는 것은 아니다. 한 사이트의 계정을 동시에 독립적으로 유지하려면 별도 로그인 공간에서 각각 로그인해야 한다. 저장된 이름과 현재 인증의 관계는 아래의 기존 글에서 더 자세히 다뤘다.
다시 등록하면 기존 항목의 방식과 주소를 바꾼다
같은 로그인 공간에서 같은 출처의 사이트를 다시 등록하면 기존 항목의 식별자를 유지하고 이름과 방식을 갱신한다. 사이트 등록에서 계정만 등록으로 바꾸면 목적지 주소도 제거한다. 다른 로그인 공간에서 등록한 항목은 따로 남는다. 이름이 같다는 이유로 합치지 않는 것이다.
새 사이트를 처음 등록할 때 제안하는 목적지는 출처(origin)의 첫 주소다. 여기서 출처는 프로토콜·호스트·포트의 조합을 뜻한다. 현재 페이지의 쿼리와 해시는 기본 주소에 넣지 않는다. 직접 입력한 주소는 계정 정보 포함 여부, 쿼리·해시와 알려진 인증 경로 등을 검사하고, 같은 출처나 구현에서 같은 서비스로 분류한 주소인지 확인한다. 이는 읽은 구현의 허용 규칙이며 모든 사이트의 로그인 주소를 완벽하게 식별한다는 뜻은 아니다.
다시 열 때는 주소만 같아도 부족하다
사이트 열기는 현재 프로젝트와 저장된 로그인 공간이 모두 같은 탭을 찾는다. 그 안에서도 저장한 주소가 맞는 사용자 탭만 재사용하고, 다른 작업이 소유한 탭은 후보에서 제외한다. 다른 프로젝트에 같은 사이트가 열려 있다는 이유로 그 탭을 가져오지 않는다. 계정만 사용할 때는 목적지 일치 조건이 필요 없으므로 같은 공간의 사용자 탭을 고른다.
등록을 누르는 순간에도 현재 탭·프로필·프로젝트·사이트 출처를 다시 맞춘다. 저장한 로그인을 여는 경로에서는 진행 중이거나 대기·일시정지 중인 작업과 미확인 결과 등을 확인하고, 원고 보존 처리 뒤에도 문맥이 바뀌지 않았는지 본다. 이 조건에 걸리면 주변의 비슷한 탭으로 대신 진행하지 않고 다시 확인하도록 멈춘다.
내부 저장과 별도 폴더 갱신은 결과를 따로 알린다
이 개발본은 내부 등록 목록을 저장한 뒤, 기존 별도 로그인 폴더의 메타데이터를 갱신한다. 폴더 갱신만 실패하면 ‘내부 등록은 저장됐지만 별도 폴더 갱신은 실패했다’고 안내한다. 등록했다는 이유로 세션 폴더 자체를 새로 복사하지 않는다.
내부 저장만 끝났다면 성공한 저장소와 실패한 폴더를 각각 알려야 한다. 그래야 사용자가 전체를 다시 등록할지, 폴더 갱신만 확인할지 판단할 수 있다. 이는 재시도 범위를 보여 주기 위한 설계 해석이며, 모든 디스크 오류에서 자동 복구된다는 검증은 없다.
버튼이 보이는 검사와 로그인 성공 검사는 다르다
수정 기록에는 미지정 공간을 등록해도 현재 탭의 계정 모드가 ‘미지정’으로 남던 문제도 있다. 목록에 이름이 생기는 것과 탭이 특정 계정을 사용한다고 표시되는 것은 별개였다. 수정은 저장 목록과 현재 탭 상태를 함께 연결했다. 성공 문구만 봐서는 놓칠 수 있는 부분이다.
기존 단위 시험에는 중복 등록의 식별자 유지, 방식 변경 때 주소 제거, 문맥 변경 거절과 탭 재사용 조건이 있다. 당시 패키지 검수 기록에는 등록 방식 선택, 다시 열기, 프로젝트 선택의 재시작 후 유지, 작은 창에서의 조작을 확인한 내용이 남아 있다. 사용한 세션 표식은 합성 자료이며 실제 서비스의 인증 성공을 확인한 시험은 아니다. 이번 집필에서는 코드와 그 기록을 대조했으며 앱 실행·계정 전환·재로그인·화면 검수를 새로 수행하지 않았다. 당시 기록도 개발 후보의 검증과 운영 앱 반영 대기를 구분한다.
등록 뒤에 할 행동부터 정한다
예를 들어 업무 도구에서 ‘작업 계정’과 ‘작업 계정으로 여는 대시보드’를 함께 관리한다고 해 보자. 이 문장은 적용을 설명하기 위한 예시다. 계정 등록만 했을 때 화면을 유지할지, 바로가기를 눌렀을 때 어느 프로젝트의 탭을 쓸지부터 적으면 필요한 저장 항목이 정해진다. 이름 변경·방식 변경·중복 등록 뒤에도 같은 약속이 유지되는지 확인한다.
확인표에는 등록 뒤 이동 여부, 중복 등록 때 바뀌는 항목, 재사용할 탭의 소속, 일부 저장만 끝났을 때의 안내를 적는다. 이 글의 코드와 시험 기록에서 확인한 조건들이다. 로그인 공유와 인증 표시의 범위는 다음 제작기에서 이어 읽을 수 있다.