패스키 서버 구현이 어려운 진짜 이유, 그리고 '불투명 레코드'라는 해법

패스키, 쓰는 건 쉬운데 만드는 건 어렵다?

요즘 구글이나 깃허브에 로그인할 때 비밀번호 대신 지문이나 얼굴 인식으로 들어가는 패스키(Passkey) 많이 쓰시죠? 사용자 입장에서는 정말 편한데요, 정작 자기 서비스에 패스키 로그인을 붙이는 개발자 입장이 되어 보면 이야기가 완전히 달라져요. Go 언어의 암호화 라이브러리를 오랫동안 관리해 온 필리포 발소르다(Filippo Valsorda)가 바로 이 문제를 정면으로 다룬 글을 냈는데요, 핵심 아이디어가 꽤 우아해서 소개해 보려고 해요.

서버 쪽 구현이 왜 어렵냐면

패스키의 기반 표준인 WebAuthn은 브라우저와 인증 장치(휴대폰, 보안키) 쪽 동작은 꼼꼼하게 정의해 놨어요. 그런데 서버, 스펙 용어로 RP(Relying Party, 신뢰 당사자) 쪽은 사정이 다르거든요. 등록 요청 한 번 처리하려면 CBOR이라는 바이너리 포맷을 파싱해야 하고, COSE 형식으로 인코딩된 공개키를 해석해야 하고, 인증 데이터 안의 각종 플래그(서명 카운터, 백업 상태 같은 것들)를 챙겨야 해요. 그리고 정작 제일 중요한 질문, “그래서 DB에는 뭘 저장해야 하는데?”에 대해서는 스펙이 딱 부러지게 알려주지 않아요.

그 결과 언어마다, 라이브러리마다 저장하는 필드와 형식이 제각각이 됐어요. credential ID는 어떤 인코딩으로 저장할지, 공개키는 COSE 그대로 넣을지 변환해서 넣을지, 나중에 스펙에 새 필드가 추가되면 스키마 마이그레이션은 어떻게 할지... 패스키를 실제로 도입해 본 팀이라면 다들 한 번씩 겪는 고민이에요.

해법: 열어보지 말고 통째로 저장하세요

발소르다의 제안은 단순해요. 서버는 패스키 하나당 불투명한(opaque) 레코드 하나만 저장하라는 거예요. 이게 뭐냐면, 라이브러리가 등록 과정에서 만들어 주는 데이터 덩어리(blob)를 내용도 모른 채 그대로 DB 컬럼에 넣어 두고, 로그인 검증할 때 그 덩어리를 다시 라이브러리에 돌려주기만 하면 되는 구조예요. 우리가 세션 토큰을 다룰 때처럼요. 공개키가 어떤 형식인지, 플래그가 몇 개인지 애플리케이션 코드는 알 필요가 없어지는 거죠.

여기서 “불투명”이라고 해서 비밀 포맷이라는 뜻은 아니에요. 오히려 반대인데요, 레코드의 내부 형식을 문서화된 표준으로 만들어서 다른 언어, 다른 라이브러리도 같은 레코드를 읽고 쓸 수 있게 하자는 게 제목의 “상호운용 가능(interoperable)”이 의미하는 바예요. 애플리케이션에게는 불투명하지만, 라이브러리 생태계에는 투명한 거죠. 이렇게 되면 나중에 백엔드를 Go에서 다른 언어로 옮기거나 라이브러리를 갈아타도 DB에 쌓여 있는 패스키 레코드를 그대로 쓸 수 있어요. 지금처럼 특정 라이브러리의 스키마에 묶이는 락인이 사라지는 거예요.

함께 공개된 Go API도 이 철학을 그대로 따라요. 등록 때 레코드를 받아서 저장하고, 인증 때 레코드를 넘겨서 검증하고, 검증 과정에서 갱신된 레코드(서명 카운터 같은 상태가 바뀌니까요)를 다시 저장하는, 딱 필요한 만큼의 표면적만 노출하는 API예요. WebAuthn의 복잡함은 전부 라이브러리 안쪽으로 숨기고요.

업계 맥락에서 보면

패스워드 매니저들 사이에서 패스키를 옮기는 표준(FIDO의 Credential Exchange)은 이미 논의가 진행 중인데, 그건 사용자 단말 쪽 이야기고요. 서버 쪽 저장 형식은 여태 사실상 무주공산이었어요. go-webauthn, 자바스크립트 진영의 SimpleWebAuthn, java-webauthn-server 같은 유명 라이브러리들이 전부 자기만의 데이터 모델을 갖고 있죠. 이번 제안은 정확히 그 빈 곳을 겨냥한 거예요. 암호학 커뮤니티에서 신뢰가 두터운 사람의 제안이라, 다른 언어 생태계로 퍼질 가능성도 지켜볼 만해요.

한국 개발자에게는

패스키 도입을 검토 중인 팀이라면, 어떤 라이브러리를 쓰든 저장 설계만큼은 이 패턴을 참고할 만해요. “검색용 credential ID 컬럼 + 불투명 블롭 컬럼” 구조로 가면 나중에 후회할 일이 확 줄어들거든요. Go 백엔드를 쓰고 있다면 바로 실험해 볼 수 있고요, 다른 언어를 쓰더라도 설계 철학 자체는 그대로 가져갈 수 있어요.

한 줄 정리: 패스키 서버 구현의 복잡함을 “내용을 몰라도 되는 표준 레코드 하나”로 캡슐화하자는 제안.

여러분 서비스는 패스키 도입하셨나요? 하셨다면 크리덴셜 저장 스키마는 어떻게 설계하셨는지 궁금하네요.