(영상) 서비스위크 2024: 영국 정부디지털서비스(GDS) 공개 세미나

영국 정부디지털서비스(GDS)가 서비스위크 2024에서 6개 팀의 작업을 공개했다.
GOV.UK 의 접근성·만들기 쉬운 폼 경험 강화
화이트홀 퍼블리셔의 디자인시스템 전환으로 일관·유지보수성 개선
생성형AI 기반 ‘GOV.UK Chat’ 실험(정확도 향상·리스크 디자인 완화 병행)
원로그인: 범정부 이해를 돕는 프로토타입, 이메일·MFA 중심 보안 UX 개선
접근성 팀 182일 성과: 자동화 테스트·정책·실무 역량 확장...
공공서비스를 ‘더 빠르고, 더 안전하고, 더 포용적’으로 만들기 위한 방안을 논의한다.

Services Week 2024: GDS Open Show and Tell
원본 영상 : https://www.youtube.com/watch?v=cPDBARbzGGg
UK Gov Design
번역 : 챗GPT (누락, 오역이 있을 수 있습니다. 원본을 확인하세요.)

2024. 3. 26.
서비스위크 2024의 일환으로, 영국정부디지털서비스(GDS) 6개 팀이 공개 쇼앤텔 형식으로 최신 작업을 공유한 영상임.

 
00:00:00 시작
00:04:30 소개 – Christine Bellamy(GOV.UK 디렉터)
00:16:49 GOV.UK Forms(Iain Boyd, Chris Cameron, Oliver Quinlan, David Biddle)
00:40:56 GOV.UK Whitehall 퍼블리셔 디자인 변경(Nikin Nagewadia)
00:48:43 GOV.UK AI 실험(Josh Davey)
01:01:21 GOV.UK One Login – 범정부 이해 증진(Matt Ashton, Monika Most)
01:13:52 GOV.UK One Login – 더 안전한 사용자 여정 디자인하기(Kim Clayden)
01:26:25 GOV.UK One Login – 접근성 팀의 182일 진행 상황(Shaun Conner)

---

Cara Kane:
좋습니다, 시작하겠습니다. 저는 카라 케인입니다. 저는 정부디지털서비스(GDS, Government Digital Service)에서 디자인 책임자이자 디자인 직군의 책임자로 일하고 있습니다. 오늘 진행을 맡았습니다. 또한 헬레나와 함께합니다. 헬레나는 우리 GOV.UK 원로그인 프로그램의 사용자중심디자인 책임자입니다. 오늘 저희 둘이 사회와 진행을 맡습니다.
이번 행사는 이번 주에 진행된 서비스위크의 일부입니다. 서비스위크에 익숙하지 않다면, 이는 지난 나흘 동안 영국 공공부문 전반에서 진행된 일련의 행사입니다. 정부 디지털·데이터 기능 부문이 후원하고, 범정부 그룹이 조직했으며, 중앙디지털데이터오피스(CDDO)도 후원했습니다. 자율적으로 기획된 일련의 이벤트로, 서비스 소양을 높이고 좋은 서비스와 좋은 서비스 전환이 무엇인지 논의하는 데 목적이 있습니다. 모든 행사는 각기 다른 조직과 부처의 사람들이, 서비스위크에서 무엇을 하고자 하는지에 기반해 자율적으로 운영했습니다. 올해는 세션과 트레이닝, 워크숍까지 매우 다양한 구성이 있었습니다. 20개가 넘는 조직이 60개 이상의 세션을 마련했습니다. 올해의 변화로 컨설팅사와 민간 등 정부 파트너에게까지 범위를 넓혔습니다. 중앙정부에서 지방정부, 더 넓은 공공부문으로 확장해 왔고, 올해는 그 범위를 더 넓혔습니다.
이번 주에 무엇이 있었는지 보고 싶다면 CDDO 블로그(cddo.blog.gov.uk)에서 전체 일정을 확인할 수 있습니다. 또한 우리에겐 행동강령이 있으며, 이 세션에도 적용됩니다. 세션에 참여하는 것은 행동강령에 동의한다는 뜻입니다. bit.ly/sw22conduct 에서 확인할 수 있습니다. 오늘 다룰 내용을 공개적으로 공유해도 됩니다. 이런 공개 세션은 자주 있지 않습니다. 오늘 경험하거나 배운 것을 공유하고 싶다면 해시태그 ServicesWeek를 사용하고, X, 인스타그램, 링크드인에서 저희를 태그해 주시기 바랍니다.
왜 이 주간이 중요하며 우리가 달성하려는 바가 무엇인지 간단히 개요를 말씀드리겠습니다. 참가자 인용을 몇 가지 소개하겠습니다. “서비스위크는 항상 한 해의 하이라이트입니다. 정부 전반에서 흥미로운 일이 아주 많이 벌어집니다. 서로에게서 영감을 얻고, 다른 이들이 어려운 문제를 어떻게 파고드는지 배울 훌륭한 기회입니다.” 제가 참석한 세션들에서도 이런 모습을 많이 보았습니다. 또 다른 분은 “서비스위크는 우리 조직에서 디지털이 단지 기술 그 이상이라는 점을 이야기할 수 있는 장(場)을 만들어 줍니다. 각 부서에서 무언가를 운영하고 훌륭한 대화를 촉발하는 데 매우 유용합니다.”라고 말했습니다.
GDS가 이 세션을 여는 이유는 우리의 에토스와 맞닿아 있기 때문입니다. 우리는 “열면 더 좋아집니다(Make things open, it makes things better)”라는 디자인 원칙을 자주 말합니다. 우리는 이 원칙을 진심으로 믿습니다. GDS의 미션은 정부의 사용자경험을 디자인하고 보호하는 것입니다. 저희는 런던, 브리스톨, 맨체스터에 근무하는 약 750명의 다양한 디지털·비디지털 직군으로 구성되어 있습니다. 잠시 후 GDS와 우리의 작업에 대해 더 들으시게 될 것입니다.
마지막 안내는 질의응답입니다. 질문이 있으시면 채팅에 남겨 주십시오. 각 발표마다 몇 개의 질문을 받을 예정입니다. 이제 본격적으로 시작하겠습니다. 먼저, 정부디지털서비스 산하 GOV.UK 디렉터인 크리스틴 벨라미의 소개 말씀입니다.

Christine Bellamy:
여러분 안녕하세요. 오늘 이 자리에 초대되어 매우 기쁩니다. 이번 주 프로그램을 보니 정말 훌륭한 한 주였고, 오늘 오후도 멋진 시간이 될 것으로 보입니다. 저는 GDS 산하 GOV.UK 디렉터 크리스틴 벨라미입니다. 관례에 따라 서비스위크의 마무리는 GDS 쇼앤텔로 진행합니다. 본격적인 발표에 들어가기 전에, 올해 서비스위크, 디지털 정부 디자인의 현황, 그리고 전 세계 수백만 명의 공공서비스 이용자에 대해 성찰하고자 합니다.
먼저 숫자부터 보겠습니다. 연사 120명, 세션 60개(역대 최다), 20개가 넘는 조직이 참여했고, 1,700명의 참석자가 있었습니다. 상당히 큰 숫자입니다. 많은 분들이 이 일이 중요하다고 생각한다는 뜻입니다. 자부심을 가져도 됩니다. 의제에서 몇 가지를 뽑아 다양성을 보여 드리겠습니다. 버밍엄 시의회는 웹사이트와 서비스디자인의 도전 과제, 그리고 지방정부에서 무엇을 하고 있는지 발표했습니다. 업무연금부(DWP)는 디지털 서비스의 탄소발자국을 최소화하는 방법을 다뤘습니다. 앞으로 우리가 정말 심각하게 고려해야 할 핵심 주제입니다. 교육부와 법무부는 트라우마 인폼드 디자인에 관한 훌륭한 세션을 진행했습니다. 우리가 그동안 깊이 다루지 못했던 주제지만, 향후 수개월과 수년 동안 매우 중요한 영역이 될 것입니다.
변화하는 세계에서 사용자중심디자인의 중요성도 생각해 보아야 합니다. 우리는 약 12년 동안 이 일을 해 왔고, 그 사이 세상은 분명히 변했습니다. 우리의 성과에 안주해서는 안 합니다. 서비스위크가 몇 해 전, 2019년쯤 시작되었을 때 우리는 당시의 도전과 가까운 미래를 내다보며 대응했습니다. 그러나 지금은 많은 것이 변했습니다. GDS의 맥락에서 이것을 생각해 보겠습니다.
우리가 여정을 시작했을 때 핵심은 웹사이트였습니다. 지금은 트래픽의 대부분이 모바일입니다. 월별로 계속 변화하며, 매우 크게 이동했습니다. 또한 웹사이트를 주요 접근 경로로 여기지 않는 젊은 신규 사용자들의 니즈도 다뤄야 합니다. 소셜미디어는 완전히 확고한 채널이 되었습니다. 틱톡 같은 거대 플랫폼이 있고, 젊은 사용자 중 85%가 사용하며, 그중 42%는 매일 사용합니다. 사람들이 콘텐츠를 소비하는 방식도 바뀌었습니다. 앞으로 그 영역에 우리가 어떻게 더 기댈지 고민해야 합니다. 팬데믹이라는 거대한 전면적 현상은 사람들의 행동을 근본적으로 바꾸었습니다. 디지털 서비스에 대한 인식과 기대 역시 현재와 미래 모두에 영향을 미쳤습니다.
이러한 배경에서, 사용자들이 제품과 서비스에 접근하는 방식이 크게 달라진 현실을 외면할 수 없습니다. 12년 전에는 사람들이 항상 우리의 서비스로 ‘직접’ 와야 한다고 생각했을지 모릅니다. 그러나 GDS와 이 자리에 계신 많은 분들의 훌륭한 작업 덕분에 그 서사가 바뀌었습니다. 사용자중심디자인이 사람들의 삶에 엄청난 영향을 미쳤습니다. 그렇다면 다음은 무엇이겠습니까. 서비스가 계속해서 사용자 니즈를 충족하도록 하려면 어떻게 해야 하겠습니까. 우리 주변의 모든 것이 근본적으로 변한 상황에서 서비스를 어떻게 더 성장시킬지 고민해야 합니다. 이것은 진지하게 다뤄야 할 과제이며, 앞으로 몇 년을 내다보며 생각해야 합니다. 우리는 많은 것을 이뤄 냈지만, 할 일은 더 많습니다.
이제까지 GDS가 해 온 일을 조금 말씀드리겠습니다. 먼저 원로그인(One Login) 프로그램입니다. 지금으로부터 2년 전 시작했습니다. 팀의 헌신이 매우 훌륭합니다. 현재 380만 명이 원로그인으로 본인 인증을 마쳤습니다. 앱을 통해 이 서비스를 사용할 수 있도록 했고, 앱 평점은 4.7점입니다. 사용자가 이 서비스를 정말 원한다는 것을 보여 줍니다. 앞으로 이 부분을 더 강화하겠습니다. 또한 GOV.UK에 와서 서비스를 이용하기 어렵다고 느끼는 사용자의 니즈를 어떻게 해결할지 고민하고 있습니다. GOV.UK 폼스 팀은 사용자가 훨씬 더 나은 접근성과 사용성을 갖춘 서비스를 이용하도록 만들어, 일상적 업무를 더 쉽게 처리할 수 있게 했습니다. 기존 제품의 확장도 시작했습니다. 예컨대 GOV.UK 페이는 공공 8,000개 조직이 사용하고 있으며, GOV.UK 노티파이는 80억 건의 알림을 발송하고 있습니다.
GOV.UK 원로그인 앱의 평점은 4.7점입니다. 매우 훌륭합니다. 이 서비스가 사용자가 정말로 쓰고자 하는 서비스임을 보여 줍니다. 앞으로 이 방향을 더욱 강화할 것입니다. 또한 GOV.UK에 방문해 서비스를 이용하기 어렵다고 느끼는 사용자의 니즈를 어떻게 해결할지도 고민하기 시작했습니다. GOV.UK 폼스 팀은 사용자가 더 나은, 더 접근 가능한 서비스를 이용할 수 있도록 만들었고, 사람들이 일상적으로 처리해야 하는 서비스를 더 쉽게 탐색하도록 도왔습니다. 그리고 GOV.UK 등 기존 제품을 어떻게 확장할지에 대해서도 고민을 시작했습니다.
현재 GOV.UK 페이는 공공부문 조직 370곳이 사용하고 있습니다. 앞으로도 사용자 니즈에 부합하도록 지속적으로 발전시켜 나갈 것입니다. GOV.UK 노티파이 시스템은 80억 건의 알림을 발송하며, 8,000개의 공공부문 조직이 사용하고 있습니다. 이 서비스 역시 오늘의 사용자만이 아니라 미래의 사용자 니즈까지 염두에 두고 제공합니다.
제가 책임지고 있는 GOV.UK 영역으로 오면, 우리가 제공하는 서비스와 사용자가 지금과 미래에 GOV.UK에서 필요로 하는 것이 무엇인지에 대해 정말 깊이 고민해야 했습니다. 그래서 앞으로 몇 분 동안, GOV.UK가 앞으로도 사용자를 위해 해야 할 일을 제대로 수행하도록 어떻게 보장할 수 있을지 간단히 말씀드리겠습니다.
먼저 제품 제안(Product Proposition)부터 생각해 보겠습니다. 12년 전 시작했을 때 우리는 ‘웹사이트’였습니다. 그동안 우리는 이 제품을 목적에 맞게, 사용자에게 적합하도록 반복·개선해 왔습니다. 우리가 해낸 일들이 매우 자랑스럽습니다. 우리는 영국 전역은 물론 그 너머의 사용자에게도 도움이 되도록 열심히 일해 왔습니다. 올해 우리는 전략을 재정비하여 이를 더 발전시킬 수 있도록 했습니다. 사용자가 ‘필요가 발생하는 지점’에서, 혹은 아직 필요를 자각하지 못한 시점(막漠然히 뭔가 바뀌어야 한다고 느끼지만 서비스 탐색은 어려운 상태)에서 서비스에 접근할 수 있게 하는 방법을 고민하기 시작했습니다. 우리의 역할을 한층 확장하여, 사용자가 서비스에 접근하기 더 좋아지도록 만들 방법을 진지하게 모색하고 있습니다.
채널 전략도 점검했습니다. 올해와 내년에 걸쳐 소셜 플랫폼에서 무엇을 할지 본격적으로 고민하기 시작했습니다. 사용자가 어디서 서비스를 접하는지, 퍼널 상의 상위 지점에서 사용자에게 다가가 GOV.UK에 오기 전에 접근성을 높이고, 시장의 다른 진입점들이 제공할 수 있는 부정확한 정보와 잡음을 걷어 내는 일을 고민하고 있습니다. 접근 경로로서의 모바일도 언급했습니다. 현재 우리는 원로그인의 성과를 토대로 앱 제안을 반복·개선하고 있습니다. 매우 잘 진행되고 있습니다. 다만 ‘웹사이트를 그대로 앱으로 옮기는’ 일만 해서는 안 됩니다. 그것은 사용자에게 올바른 접근이 아닙니다. 우리는 사용자 관점에서 무엇이 필요한지, 그 경로에서 무엇이 더 나은 서비스 접근을 가능하게 하는지 반드시 따져 보아야 합니다. 올해 이 분야에서 우리의 활동을 많이 보시게 될 것입니다.
우리는 사용자가 서비스에 접근하고, 비용을 지불하고, 알림을 받고, 더 빠르고 쉽게 서비스에 도달하며, 원로그인 정보를 보관·활용해 접근을 더 쉽게 만드는 방법을 폭넓게 고민하고 있습니다. 오늘 이 자리에 AI를 실험 중인 동료들도 있습니다. 매우 이른 시점에 이 기술에 뛰어들 수 있어 기뻐합니다. 그들이 수행 중인 작업은 정말 훌륭합니다. 오늘 오후에 그 시연을 보게 되실 것입니다. 이 영역에서 할 일은 더 많습니다. 위험도 있다는 것을 압니다. 그러나 사용자에게 서비스 접근을 더 가능하게 만들 수 있다면, 충분히 실험할 가치가 있는 흥미로운 분야입니다.
또한 우리는 다양한 콘텐츠 포맷에 대해서도 생각하기 시작했습니다. 지난 12년간 GDS가 구축해 온 훌륭한 토대 위에서, 그 성과를 더 확장하고 고도화하려 합니다. 앞으로도 계속 더 해 나갈 것입니다.
지금은 사용자에게도, 정부에도, GDS에도 도전의 시기입니다. 우리는 제대로 해내고자 합니다. 도전을 받아들이고, 앞으로 우리가 ‘미래의 기준’을 만들어 가는 존재가 되기 위해 무엇을 해야 하는지 진지하게 고민하겠습니다. 지난 12년의 훌륭한 성과를 모두 모으고, 정부 전반의 파트너, 그리고 오늘 이 자리에 계신 여러분과 함께, 지금과 미래의 사용자 니즈를 해결하는 방법을 찾겠습니다. 매우 흥미로운 시기입니다. 정부에서 일하고 있다는 사실을 자랑스러워할 만한 때입니다. 할 일도 많고, 우리 주변의 변화도 큽니다. 그러나 이 자리에 계신 분들과 이 영상을 보게 될 많은 분들이 있어 우리는 매우 든든합니다. GOV.UK 디렉터이자 공무원으로서, 저는 사용자가 필요한 시점에 정부 서비스를 쉽게 이용하도록 만드는 이 미션의 일부가 된 것을 매우 자랑스럽게 생각합니다. 오늘 오후 세션도 즐겁게 보내시기 바랍니다. 저는 중간중간 세션에 들를 예정입니다. 아직 만나 뵙지 못했는데 대화를 원하신다면, 언제든 연락 주시기 바랍니다. 멋진 한 해가 되기를 바랍니다. 감사합니다.

Cara Kane:
정말 훌륭했습니다. 맥락을 잘 잡아 주셨고, 오늘 발표에서 무엇을 듣게 될지 개요도 제시해 주셨습니다. 이제 남은 세션의 구성에 대해 간단히 안내하겠습니다. 오늘은 일곱 개 발표를 듣습니다. 폼스 팀의 발표가 두 개 있습니다. 디지털 서비스 플랫폼을 대표해 폼스 팀이 발표하고, 이어서 GOV.UK 관련 발표 두 개, 그리고 GOV.UK 원로그인 프로그램 관련 발표 두 개가 있습니다. 다시 한 번, 자리를 열어 주시고 소개해 주신 크리스틴께 감사드립니다. 그럼 첫 번째 그룹인 폼스 팀으로 넘어가겠습니다.

GOV.UK Forms (Iain Boyd, Chris Cameron, Oliver Quinlan, David Biddle)

Iain Boyd:
좋습니다. 안녕하세요. 우리는 GOV.UK 폼스 팀입니다. 저는 참여(Engagement) 리드 아이언 보이드입니다. 이제 제 동료들이 차례로 본인 소개를 하겠습니다.

Oliver Quinlan:
안녕하세요. 저는 팀의 사용자 연구자 올리버 퀸런입니다.

Chris Cameron:
저는 팀의 디자이너 크리스 캐머런입니다.

David Biddle:
저는 팀의 프런트엔드 개발자 데이비드 비들입니다.

Iain Boyd:
보시다시피 모두 베테랑들입니다. 이 자리에 오게 되어 매우 기쁩니다. 서비스위크는 일주일 내내 멋진 행사입니다. 초대해 주셔서 감사합니다. 오늘은 우리의 비전과 미션, 사용자 연구와 사용자 피드백, 디자인과 실무에 대해 이야기하겠습니다. 그리고 새 기능의 짧은 데모도 보여 드리겠습니다. 가능하다면 질의응답 시간도 갖겠습니다.
지난 2년 동안 정말 열심히 일했습니다. 지금 우리는 동료들이 ‘디지털 폼’을 쉽게 만들 수 있는 훌륭한 플랫폼을 갖추었다고 생각합니다. 폼을 만드는 데 특별한 디지털 기술이 없어도 동료들이 폼을 만들 수 있습니다. 핵심적으로, 우리의 연구는 사람들이 PDF, 워드 문서, 엑셀 시트 같은 문서 기반 폼보다 GOV.UK 폼스로 만든 폼을 작성하는 것을 더 선호한다는 사실을 보여 줍니다. 다양한 사용자 그룹을 대상으로 테스트했으며, 각 그룹으로부터 매우 긍정적인 피드백을 받았습니다.
우리의 목표는 정부 전반의 동료들이 자발적으로 GOV.UK 폼스를 선택하도록 만드는 것입니다. 즉, 정부 전체에서 폼 제작의 기본 도구가 되도록 하는 것입니다. 우리의 비전은 GOV.UK 상의 모든 폼이 접근 가능하고, 사용하기 쉬우며, 처리 속도가 빠르도록 하는 것입니다. 여기서 ‘접근 가능하고 사용하기 쉬움’은 폼 빌더가 폼을 만들기에 단순하고 직관적이어야 한다는 뜻이면서, 동시에 만들어진 폼이 사람들이 정보를 정부에 제출하기에 쉽다는 뜻이기도 합니다. 그리고 처리 팀이 받게 되는 폼 출력물 역시 빠르고 쉽게 처리 가능해야 합니다. 할 일이 많고, 그래서 어렵습니다. 하지만 사용하기 쉬운 도구를 만들면 정부가 우리의 미션을 달성하고 비전을 실현하도록 도울 수 있습니다. 이제 연구에서 얻은 결과가 어떻게 디자인에 반영되었는지 공유하고, 자랑스러운 새 기능을 데모로 보여 드리겠습니다. 올리버에게 연구 이야기를 넘기겠습니다.

Oliver Quinlan:
감사합니다. 여기서는 사용자 연구, 특히 접근성 테스트 사례 몇 가지를 공유하겠습니다. 사람들이 작성하는 폼이 접근 가능하도록 만드는 것은 물론 매우 중요합니다. 동시에 폼을 제작하는 ‘도구’ 자체도 접근 가능하도록 만드는 데 많은 공을 들였습니다. 그 일환으로, 우리는 제품의 ‘집중 접근성 테스트’의 일부로 뉴로다이버스(신경다양성) 사용자를 포함한 대상과의 사용성 테스트를 수행했습니다.
알다시피 제품은 다양한 접근성 요구를 가진 실제 사람들과 테스트하는 것이 중요합니다. 그래야 그들이 겪을 수 있는 문제와 과제를 드러낼 수 있습니다. 우리는 프라이빗 베타 기간 동안 대략 두 달에 한 번씩 주기적으로 접근성 테스트를 진행했습니다. 매번 다양한 관점을 확보하기 위해 여러 유형의 참가자들과 함께 작업했습니다. 다음 슬라이드 부탁드립니다. 감사합니다.
그 목표를 달성하기 위해, 우리는 전문 리크루팅 업체와 협력해 신경다양성과 인지적 접근성 요구를 가진 참가자들을 모집했습니다. 물론 그 밖의 다양한 접근성 요구를 가진 참가자들도 포함했습니다. 오늘 공유할 결과는 특히 이 영역에 관한 것입니다. 다음 슬라이드 부탁드립니다.
여기 우리가 도구를 공유했던 사용자들의 코멘트가 몇 가지 있습니다. 첫 번째 참가자는 “세상에, 실제로 보일 때는 정말 도움이 됩니다.”라고 말했습니다. 두 번째 참가자는 “저장하고 다음 질문 추가라고 되어 있을 때, 그 자리에 미리보기가 있었으면 좋겠습니다.”라고 말했습니다. 이는 우리가 도구를 사용하는 내내 꾸준히 받아온 피드백으로, 사용자가 자신이 하는 일을 ‘시각화’하는 부분에 관한 것입니다.
사람들이 폼을 만들 때는 여러 맥락을 고려해야 합니다. 누군가 다른 사람이 사용할 것을 만들고 있기 때문에, 그 사람이 실제로 무엇을 보게 될지 항상 똑같이 볼 수 있는 것은 아닙니다. 그래서 자신의 관점과 최종 사용자의 관점 사이를 오가야 하고, 추상과 구체를 오가며 전환해야 합니다. 이 점에서 무엇이 잘 작동하고 무엇이 그렇지 않은지에 관한 매우 유용한 피드백을 받았습니다. 다음 슬라이드 부탁드립니다.
참가자들이 자신의 경험과 인식을 소리 내어 설명해 준 것도 큰 도움이 되었습니다. 최종 사용자가 폼을 채울 때 그것이 어떻게 보이고 어떻게 경험될지를 이해하도록 돕는 것은 중요한 원칙입니다. 다만, 그 ‘시점’이 언제 중요한지, 프로세스의 어떤 단계에서 그런 신호가 필요한지를 파악하는 것이 중요합니다. 한 참가자는 “완성된 폼이 어떻게 보일지 머릿속으로 이미지를 투사하고 있습니다. 완성된 레이아웃을 상상하려면 뇌를 좀 써야 합니다.”라고 말했습니다. 이 테스트를 통해, 사람들이 특히 그렇게 ‘상상해야 한다’고 느끼는 구간과 도구의 특정 부분이 제법 있다는 것을 발견했습니다. 심지어 잘 상상해내는 사람들에게도 도전이 될 수 있었습니다. 우리는 이 피드백을 다음 단계 디자인에 반영할 수 있었습니다. 다음 슬라이드 부탁드립니다.
구체적 예시입니다. ‘목록에서 선택(Select from list)’ 질문을 만들 때 한 사용자는 순서를 매우 혼란스럽다고 느꼈습니다. 이는 단일선택 혹은 복수선택(라디오/체크박스) 형태의 질문입니다. 초기 디자인에서는, 먼저 폼 작성자가 선택할 수 있는 ‘모든 보기(답변)’를 고르는 화면을 보여 주고, 그다음 화면에서 질문 문구를 만드는 흐름이었습니다. 여러 피드백이 있었지만, 특히 신경다양성 참가자들로부터 “아, 답변이 질문보다 먼저 나오네요. 이상한 흐름이네요.” 같은 반응이 반복적으로 나왔습니다. 그렇게 설계된 데에는 이유가 있었지만, 이 피드백을 계기로 순서를 바꾸는 것이 좋겠다는 판단을 하게 되었습니다. 다음 슬라이드 부탁드립니다. 여기서부터는 사용자 인사이트를 실제 디자인에 어떻게 반영했는지 크리스가 말씀드리겠습니다.

Chris Cameron:
감사합니다, 올리버. 올리버가 말한 대로, ‘목록에서 선택’ 답변 유형(최종 사용자에게는 라디오/체크박스로 보임)에서 혼란이 있다는 것을 연구에서 들었습니다. 혼란은 ‘폼 작성자’ 쪽에서, 올바른 정보 구조와 최종 사용자에게 물을 ‘질문’을 만드는 정신 모델을 세우는 데서 비롯되었습니다.
이것이 우리가 도달한 방향입니다. 이전에는 대부분을 한 페이지에서 처리했습니다. 먼저 보기(옵션) 목록을 추가하고, 그다음에 “질문이 무엇인지”를 물었습니다. 피드백을 반영해 우리는 ‘한 페이지에 한 가지(One thing per page)’ 모델로 전환했고, 폼 작성자가 먼저 ‘질문 문구’에 집중하도록 했습니다. 그들의 정신 모델과 맞추어 “좋습니다, 먼저 질문을 넣으세요.”라고 안내하는 식입니다. 그러면 다음 화면에서 필요한 보기(옵션)가 무엇인지 더 자연스럽게 생각할 수 있습니다.
이 흐름은 사용자들에게 더 자연스럽게 느껴졌고, 다음에 무엇을 추가해야 하는지—목록 형태의 보기뿐 아니라 힌트 텍스트까지—더 쉽게 떠올리게 도왔습니다. 이미 보기 목록을 넣은 뒤에는 힌트를 어떻게 구성해 폼 작성자(최종 사용자)가 알맞은 정보를 선택하도록 돕겠다는 생각까지 구체화됩니다.
사실 이 제품의 초창기부터 내부 프로세스는 ‘한 페이지에 한 가지’ 철학을 지향해 왔습니다. 다만 구현은 ‘질문 편집’ 화면 하나에서 질문 문구, 힌트, 기타 구성요소를 한데 다루는 형태였습니다. 여러 차례 테스트를 통해 사용자들의 복잡도와 정신 모델을 이해한 뒤, 우리는 ‘질문 여정’을 더 세분화하기 시작했습니다. 먼저 ‘답변 유형’을 묻습니다. 즉, 폼 작성자가 실제로 필요한 ‘데이터의 성격’을 먼저 생각하도록 유도합니다. 그러면 그에 맞게 질문을 어떻게 물을지, 이 사례처럼 정책·백엔드 제약으로 인해 어떤 유형만 허용되는지 등을 더 잘 정렬할 수 있습니다.
최종 사용자(UI) 관점에서도 ‘한 페이지에 한 가지’ 원칙을 적용했습니다. 첫 MVP에서는 한 화면에 한 질문만 보여 주었습니다. 자동완성 등으로 매우 긍정적인 피드백을 받았습니다. 사람들은 브라우저에 저장된 정보를 활용해 재빨리 항목을 채워 나갈 수 있었습니다. 서비스 전반과 신규 기능에서 제기되는 문제들도 같은 원칙으로 접근하면서, 내부 사용자와 외부 사용자 모두에게서 무엇이 잘 작동하고 무엇이 그렇지 않은지를 빠르게 찾아내고 있습니다. 전반적으로 매우 긍정적 피드백을 꾸준히 받고 있습니다.
다음 슬라이드에는 더 작은 규모이지만, 개발 초기부터 영향을 크게 미친 피드백이 하나 있습니다. 우리와 가장 먼저 테스트 도구를 탐색한 파트너 중 한 곳에서 나온 의견인데, 결과적으로 서비스 전반의 콘텐츠 디자인과 프로덕션 툴 내 알림 도입에까지 큰 변화를 가져왔습니다. 바로 ‘질문에 번호를 붙여 달라’는 것이었습니다. 사소하고 당연해 보이는 요청이지만, 당시에는 그 관점에서 충분히 생각하지 못하고 있었습니다.
그 참가자는 자신의 신경다양성 경험을 이야기했습니다. 정보가 많은 화면에서, 지금 어디에 있고 무엇을 했으며 다음에 무엇을 할지 기억하는 것이 상당히 복잡하다는 것입니다. 그래서 각 질문에 번호를 붙여, 폼 전체에서 질문의 위치, 현재 위치, 수행한 작업(이동·수정 등)을 추적할 수 있게 해 달라고 제안했습니다. 이 피드백 덕분에 성공 알림(success notifications)도 구체적으로 바뀌었습니다. 예컨대 “질문을 추가했습니다.”가 아니라 “질문 10이 추가되었습니다.”처럼 정확히 알려 줍니다. 질문을 수정했다면 “질문 3을 수정했습니다.”, 질문을 이동했다면 “질문 1을 질문 3 위치로 이동했습니다.”처럼 시작 위치와 도착 위치를 번호로 명시합니다.
이 접근은 서비스 전반의 알림에도 확산되었습니다. 단순히 “성공”이나 “변경 사항이 저장되었습니다.”가 아니라, 사용자에게 의미 있는 피드백을 제공하려 합니다. 또한 이는 특정 답변에 따라 질문을 건너뛰는 ‘라우팅’ 기능의 콘텐츠에도 반영되었습니다. 제품 내부에서 라우팅과 질문을 연계하는 방식을 명확히 함으로써, 시각적 다이어그램과 플로우차트에 의존하지 않아도 되게 했습니다. 이는 기존의 여타 도구들과 비교해 큰 차별점입니다. 핵심은 읽기 쉬운 콘텐츠, 쉽게 따라갈 수 있는 설명입니다.
화면의 예시는 질문 1 아래에 질문 1의 라우트와 if 문(답변 조건), 그리고 사용자가 어느 질문으로 이동하는지까지 표시한 것입니다. 이후 업데이트에서는 해당 라우트 블록 내부에서, 질문 텍스트 앞뒤에 그 질문의 ‘여정 내 위치’를 함께 알려 주어, 사용자가 빠르게 스캔하고 관련 질문으로 점프할 수 있게 했습니다.
우리의 지속적 개선 방식은, 올리버가 말했듯, 항상 다양한 사용자와 테스트하고 그들이 말해 주는 것과 우리가 실제 사용 장면에서 ‘관찰하는 것’ 모두를 토대로 반복·개선한다는 것입니다. 종종 사용자는 한 가지를 말하지만, 우리는 다른 어려움을 ‘눈으로’ 확인하기도 합니다. 사용자가 말로 표현하지 못해도, 어디서 어려움을 겪는지 분명히 보일 때가 있습니다. 이 과정은 계속됩니다. 우리의 디자인·반복·개발 방식에 본질적인 절차입니다.
또 다른 강점은, 우리는 디자인 시스템과 서비스 매뉴얼을 핵심까지 충실히 따른다는 점입니다. ‘한 페이지에 한 가지’를 비롯해, 선행 작업에서 축적된 패턴과 컴포넌트를 적극적으로 활용하고 있습니다. 매우 도움이 됩니다. 그럼 다음 슬라이드에서 실제 사용자 한 분의 목소리를 들어 볼 수 있을지 시도해 보겠습니다. 동영상이 잘 재생되길 바랍니다.
...

Iain Boyd:
지금 들으신 것은 우리가 정말 좋아한 사용자 피드백입니다. “익숙해서 정말 좋습니다. 제가 GOV.UK를 좋아하는 이유가 이겁니다. 항상 같거든요. 위에 왕관 마크가 있고, 상단은 검정색이고, 보기 좋은 초록색 상자가 있고, 흰 바탕에 초록 위 흰 글자, 본문은 흰 배경에 굵은 검정 GOV.UK 글씨… 훌륭합니다. 자폐 성향을 가진 사람에게는 꿈 같은 디자인입니다.”라는 말이었습니다. 오디오가 잘 들리셨기를 바랍니다. 지금 들으신 대로, 사용자 연구 참가자가 무엇을 보고 무엇을 좋아하는지 설명했습니다. 명도 대비가 좋고, 무엇을 해야 하는지 이해를 돕는 초록색 버튼을 좋아한다고 했습니다. 끝에 “자폐 성향을 가진 사람에게는 꿈 같은 디자인”이라고 말했는데, 정말 멋진 피드백이라고 생각합니다. 우리 팀이 실제로 사용자에게 의미 있는 변화를 만들고 있다는 확신이 이런 순간에서 나옵니다.

David Biddle:
이제 방금 출시한 새 기능을 짧게 데모하겠습니다. 들어가기 전에 맥락을 간단히 말씀드리겠습니다. 이 기능은 프라이빗 베타 파트너 다수에게서 요청받았고, 사용자 피드백도 많았으며, GOV.UK 전반의 폼에서 매우 흔한 요구입니다. 이 기능을 선보이게 되어 매우 기쁩니다. 제품의 활용 폭이 넓어지기 때문입니다. 그리고 이 작업은 더 큰 변화의 초기 단계이기도 합니다. 제품·플랫폼·서비스 디렉터리 아래 서로 다른 제품들이 더 잘 소통하고, 장차 하나의 큰 제품처럼 작동하도록 하려는 방향입니다. 이에 대해서는 앞으로 몇 년 동안 더 소식이 있을 것입니다.
(마이크 조정) 최대한 또렷이 말씀드리겠습니다. 화면을 공유하겠습니다. 지금 메인 폼 빌딩 도구에 들어와 있습니다. 여기에는 사용자가 폼을 라이브로 만들기까지 해야 할 작업이 보이는 태스크 리스트가 있습니다. 우리가 새로 추가한 선택적 태스크는 ‘GOV.UK Pay 결제 페이지 링크 추가’입니다. GOV.UK Pay에는 간단한 결제 페이지를 만들어 다양한 곳에 복붙해 쉽게 공유할 수 있는 기능이 있습니다. 우리는 여기에 ‘얹어서’ 연동했습니다.
이 태스크로 들어가 보면 안내 콘텐츠가 꽤 많습니다. 사용자 연구를 통해, 우리 플랫폼 사용자들이 GOV.UK Pay에 익숙하지 않은 경우가 많다는 것을 알았습니다. 그래서 우리 서비스와 잘 연동되는 결제 링크를 어떻게 설정하는지 자세한 안내가 도움이 되었습니다. 또 백오피스에서 결제를 가능하게 하려면 결제대행사(PSP) 연동 등 공공부문 특성상 절차가 필요하고, 시간이 걸린다는 기대치 설정도 유용했습니다. 이 기능이 제출 건을 처리하는 팀(수신자)에게 어떤 이점이 있는지, 최종 사용자에게 어떤 이점이 있는지도 설명합니다.
저는 미리 안내에 따라 GOV.UK Pay에서 결제 링크를 만들어 두었습니다. 설정은 이렇고, 저장합니다. 이제 해야 할 일은 그 링크를 복사해서 여기 폼 빌더의 해당 입력란에 붙여넣고 저장하는 것입니다. 그러면 태스크가 완료됩니다. 폼을 미리보기로 열어 실제로 채워 보겠습니다. 제출 이메일을 요청하고 제출하면, 참조번호가 표시되고 “아직 결제가 필요합니다”라는 안내가 뜹니다. 이어서 ‘결제 계속’ 버튼이 나타납니다. 이것을 누르면 매끄럽게 GOV.UK Pay로 넘어가며, 방금 생성된 참조번호가 미리 채워집니다. 사용자가 기억하거나 복붙할 필요가 없습니다.
그리고 제출을 받은 처리 담당자에게 가는 이메일과, 최종 사용자에게 가는 확인 이메일에도 이 참조번호가 포함됩니다. 사후에 결제 대사(대조)를 할 수도 있고, 사용자가 진행 상황을 문의할 때도 참조번호로 소통할 수 있습니다. 기능은 대체로 이렇습니다. 우리는 GOV.UK Pay의 손쉬운 시작 경험에서 큰 도움을 받았습니다. 앞으로는 Pay API와 더 밀접한 통합을 고려하겠지만, 지금 단계에서도 많은 사용자에게 충분히 유용한 기능이라고 봅니다.

Cara Kane:
폼스 팀 질의응답으로 넘어가겠습니다. 채팅에 API 관련 질문이 올라왔습니다. 이안, 데이비드, 크리스가 덧붙일 말씀이 있습니까?

Iain Boyd:
올리버와 크리스가 채팅에서 답했습니다. 저희도 생각 중이며, 정부 내 여러 팀과 논의하고 있습니다. 아직 개념적 초기 단계라 확정된 작업 계획은 없습니다. 다만 올 하반기의 중요한 우선순위라는 점은 분명합니다. 다른 우선순위도 많아, 가능한 범위에서 순차적으로 진행할 것입니다. 크리스가 ‘예정 기능’ 링크를 공유했습니다. 우선 집중할 항목으로는 파일 업로드, 저장 후 문서로 돌아오기, 하나의 질문에 다중 답변 허용(예: 지난 5년 주소 이력 같은 형식) 등이 있습니다. 이들에 먼저 집중하고, 병행해 논의를 진행한 뒤 설계·개발·테스트를 시작하겠습니다.

Cara Kane:
로드맵 질문에는 답을 주신 것 같습니다. 채팅에 결제 관련 질문이 두 가지 더 있습니다.
“왜 결제 전에 폼이 먼저 제출되나요? 팀에는 ‘결제 대기’ 상태로 이메일이 가나요? 결제가 완료되면 추가 이메일이 생성되나요? 둘은 어떻게 연계되나요? 사용자에게는 폼 제출 확인 이메일과 결제 영수증 이메일이 각각 가나요?”와 같은 구체 질문입니다.

David Biddle:
네, 폼은 결제 전에 먼저 제출됩니다. 지금은 두 서비스가 분리되어 있어 순차적으로 진행해야 하기 때문입니다. 제출물이 먼저 도착하면 처리 담당 팀이 필요 시 결제를 독촉하는 등 후속 조치를 취할 수 있어 실무상도 타당합니다. 방금 말씀하신 예상과 거의 같습니다. 처리 담당자에게 가는 제출 알림 이메일에는 “이 참조번호로 결제 여부를 확인하라”는 안내가 포함됩니다. 폼 작성자(최종 사용자)에게는 폼 제출 확인메일과 결제 관련 메일이 각각 별도로 갑니다. 추가 질문이 있으면 채팅으로 더 답변드리겠습니다.

Oliver Quinlan:
사용자가 확인 이메일 수신을 선택하지 않는 한, 폼을 제출해도 자동으로 이메일을 받지는 않습니다. 데이비드가 데모에서 본인 이메일 주소를 입력해 보여준 것처럼, 확인 이메일을 받도록 선택할 수 있는 기능이 있습니다. 그 이메일에는 폼 데이터는 포함되지 않습니다. 예컨대 의학적 병력이나 주소 같은 내용은 들어가지 않습니다. 단지 이 서비스에 대해 이 시각에 이 참조번호로 폼을 제출했다는 사실만 확인합니다.

Cara Kane:
아주 좋습니다. 채팅의 질문은 여기까지인 것 같습니다. 더 궁금한 점이 있으면 팀에 직접 연락하셔도 됩니다. 제가 다음 발표를 소개해도 될까요?

Nikin Nagewadia:
네, 다음으로 넘어가겠습니다. 감사합니다, 폼스 팀. 이제 Whitehall 퍼블리셔를 GOV.UK 디자인 시스템으로 업그레이드한 이야기를 하겠습니다. 저는 Whitehall 퍼블리셔 팀의 시니어 인터랙션 디자이너 니킨 나게와디아입니다.
배경을 간단히 말씀드리겠습니다. GOV.UK는 모두가 영국 정부와 쉽게 상호작용할 수 있도록 디자인되었습니다. 70만 개가 넘는 페이지로 구성되어 있으며, 영국 정부의 신뢰할 수 있는 단일 온라인 허브가 되려는 미션을 수행합니다. 그렇다면 이 70만여 페이지는 어떻게 GOV.UK에 올라올까요. 당연히 CMS(콘텐츠관리시스템)를 사용합니다. 그중 대다수 콘텐츠는 Whitehall 퍼블리셔라는 도구로 만들어집니다. Whitehall 퍼블리셔는 GDS의 인하우스 CMS로, GOV.UK 초기 시절에 도입되었습니다. 현재 2,000명 이상의 공무원 퍼블리셔가 이를 사용해 콘텐츠를 업로드·관리·수정합니다. 2022년에 우리는 Whitehall 퍼블리셔를 GOV.UK 디자인 시스템으로 업그레이드하는 전담 팀을 꾸렸습니다.
왜 디자인 시스템으로 업그레이드해야 할까요. 첫째, Whitehall은 트위터가 만든 스타일링 프레임워크인 부트스트랩의 구버전을 쓰고 있었는데, 더 이상 지원되지 않습니다. 반면 GOV.UK 디자인 시스템은 GDS의 인하우스 제품으로, 전담 팀과 영국 정부 전반의 디자이너·개발자 커뮤니티가 함께 유지·보수합니다. 또한 접근성을 고려해 구축되었습니다. 마지막으로 디자인 시스템으로의 업그레이드는 개발자 경험을 개선해, Whitehall의 추가 개선과 신규 기능 개발을 더 쉽게 하고, 그 결과를 사용자(영국 정부의 퍼블리셔)에게 더 빠르게 전달하게 합니다.
그렇다면 어떻게 업그레이드했을까요. 두 가지 접근이 있었습니다. 첫 번째는 비교적 ‘직진’ 업그레이드입니다. Whitehall의 기존 스타일과 컴포넌트를 디자인 시스템의 동등 요소로 치환하는 방식입니다. 경우에 따라 사법부(Ministry of Justice), 교육부(Department for Education) 등 타 부처 패턴 라이브러리도 참조했습니다. 이 접근에서는 레이아웃과 기능은 유지하면서, 디자인 시스템의 스타일과 컴포넌트를 적용했습니다. 예로 문서 검색 페이지를 들 수 있습니다. 화면 구성은 유지하되, 디자인 시스템의 스타일과 GDS 기본 내비게이션(헤더 바로 아래 1차 내비게이션)을 적용했습니다.
두 번째 접근은 ‘완전 재고(리씽크)’가 필요한 경우입니다. 디자인 시스템이나 타 부처 패턴 라이브러리에 해당 기능을 옮길 적절한 컴포넌트가 없을 때가 있습니다. 새 컴포넌트를 바닥부터 만들 수도 있었지만, 1회성 솔루션은 피하고 싶었습니다. 그래서 사용자 연구와 테스트를 병행하며, 특정 기능의 인터페이스와 경험을 처음부터 다시 디자인했습니다. 그 철학을 적용한 사례가 Whitehall의 ‘문서 콜렉션’ 기능입니다. 과거에는 콘텐츠 순서 변경, 추가/삭제, 검색을 한 화면에서 모두 처리했습니다. 이를 디자인 시스템으로 단일 페이지에 억지로 옮기려 하니 악몽 같은 일이 되었습니다. 결국 각 작업을 별도 페이지로 분리하고, 고유 URL을 부여했습니다. 이는 Whitehall 퍼블리셔의 다른 부분과도 일관됩니다. 폼스 팀의 ‘한 페이지에 한 가지’ 철학과 같은 맥락입니다.
결과적으로 1년 반의 작업 끝에 지난해 11월 최종 업그레이드를 배포했습니다. Whitehall 퍼블리셔는 예전보다 탐색하기 쉽고, 사용하기 쉬우며, 접근성도 크게 개선되었습니다. 제 말만 믿지 마시고, 사용자 의견을 들어보시겠습니다. 내무부(Home Office)의 콘텐츠 디자이너는 “앱에 꽤 많은 변경이 있었는데, 모두 긍정적입니다. 특히 Whitehall에 처음 온 사람들에게 더 쉽고, 더 직관적입니다.”라고 말했습니다. 환경청(Environment Agency)의 리드 콘텐츠 디자이너는 “동시에 합류한 동료들에게 더 명확해졌고, 제 작업을 방해하지 않는 방식이라 매우 긍정적입니다.”라고 했습니다.
업그레이드는 끝났지만, 이 작업으로 Whitehall 퍼블리셔를 더 개선하고, 영국 정부 전반의 퍼블리셔에게 가치를 더 빠르게 전달할 기회가 열렸습니다. 동시에 다른 퍼블리싱 앱들도 디자인 시스템으로 업그레이드하는 작업이 시작되었습니다. 개인적으로는 GDS에서 일하며 경험한 가장 어려운 인터랙션디자인 과제였습니다. 사용자 인터페이스를 업그레이드하면서, 사용자의 업무를 방해하지 않도록 보장해야 했기 때문입니다. 이로 인해 퍼블리셔들은 최소한의 혼란으로 콘텐츠를 계속 GOV.UK에 반영할 수 있게 되었고, 최종 이용자에게도 긍정적 영향을 줍니다. 또한 GOV.UK 디자인 시스템의 속속들이를 이해하는 계기가 되었습니다. 전반적으로 이 프로젝트는 “변화는 어렵다”는 귀중한 교훈을 다시 확인시켜 주었습니다. 더 자세한 내용은 Inside GOV.UK 블로그에 정리되어 있습니다. 구독해 주시면 새 소식을 받아보실 수 있습니다. 발표는 여기까지입니다.

Cara Kane:
질문을 받겠습니다. 아직 채팅에 질문은 없지만, 수 윌리엄스가 “새 변화가 마음에 듭니다. 콜렉션 관리가 훨씬 쉬워졌습니다.”라고 남겨 주셨고, 이그나스의 응원도 있었습니다. 질문이 떠오르면 끝에 다시 시간을 드리겠습니다. 다른 말씀이 없으면 다음 발표로 넘어가겠습니다.
다음은 GOV.UK 내에서 계속 진행하되, AI 팀으로 이동합니다. 인공지능 팀의 조시 데이비가 발표합니다.

Josh Davey:
여러분 안녕하세요. 저는 AI 팀의 프로덕트 매니저 조시 데이비입니다. 오늘은 지난 몇 달간 우리가 수행한 작업, 도출된 발견, 그리고 다음 단계 계획을 소개하겠습니다.
우리 팀의 역할을 먼저 설명하겠습니다. 우리는 새로운 AI 기술을 탐색·실험하여, 대중에게 제공되는 서비스와 GOV.UK 운영 방식을 정량적으로 개선하는 일을 한다. 이를 위해 생성형 AI가 GOV.UK의 사용자경험을 개선할 수 있는지, 가능하다면 어떤 방식이 효과적인지 검증하는 일련의 실험을 진행하고 있다.
첫 번째 실험은 ChatGPT 기반 챗봇인 GOV.UK Chat이다. 오른쪽 아이폰 목업처럼 보이는 서비스이다. GOV.UK Chat은 일상 업무를 수행하는 비즈니스 사용자에게 질의응답 형태로 정보를 제공한다. 세무, 각종 라이선스 문의 등이 해당한다. 화면의 예시는 수입·수출 관련 질의이다.
우리는 최근 이 서비스를 실제 사용자 앞에 공개했다. 정부 조직 가운데 최초였다. 구축 과정에서 배우는 것이 많았다. 화면에 보이는 단계적 테스트 접근은 우리가 직접 설계하고, 진행하면서 반복·수정해 온 것이다. 먼저 개념증명(POC)을 만들고 팀 내부에서 품질 테스트를 수행해, 올바른 종류의 정보를 돌려주는지 확인했다. 다음으로 GOV.UK의 내부 콘텐츠 디자이너들에게 제한적으로 프런트엔드 접근을 제공해 톤앤매너를 점검했다. GOV.UK에서는 기대되는 고유의 어조가 있으며, 이를 애플리케이션에 구현하고자 했다.
그다음은 연구실 테스트로 확장했다. 진행자가 있는 모더레이티드 테스트로, 사용자 연구자들이 비즈니스 사용자의 도구 활용을 관찰했다. 몇 가지 과제를 주고 “이 정보나 저 정보를 찾아보라”거나, 일상처럼 사용해 보라고 요청했다. 참가자는 10명이었고, 이 단계의 목적은 실제로 사용가치가 있는지, 사람들이 쓸 것인지 검증하는 것이었다.
그 뒤에 대규모 테스트로 전개했다. 1,000명의 비즈니스 사용자를 초청해 비모더레이티드 라이브 테스트를 진행했다. 경험을 평가하는 양식과 일부 인터뷰를 포함했다. 사람들이 어떤 유형의 과제에 이 도구를 쓰는지 파악하려 했다.
결과를 보면, 이 도구는 특정 정보를 찾는 데 탁월했다. GOV.UK 페이지 깊숙이 묻혀 있는 정보를 꺼내는 데 특히 강했다. 반면 세무 수치 계산 등 산술 작업에는 약했다. 다른 주요 발견을 덧붙이면, 69%의 참가자가 GOV.UK Chat의 응답이 유용하다고 느꼈다. 정확도는 전체 질문 기준 80%였다. 그러나 GOV.UK처럼 권위 있는 정보원에 기대되는 수준의 정확도는 아니다. 더 큰 문제는, 응답이 틀렸더라도 71%의 사용자가 답변을 신뢰했다는 점이다. 데이터가 말해 주는 바는, 사람들은 이 도구를 좋아하고 신뢰하지만, 현재 상태로는 제공하기에 충분한 정확도 수준이 아니다, 라는 것이다.
따라서 우리는 기술적으로 정확도를 개선하는 한편, 디자인을 통해 부정확성의 위험을 완화하려 한다. 사용자 중심으로 접근해야 한다. 현재 선택한 핵심 대상은 ‘비즈니스·세금’ 영역이며, 모든 정확도 개선은 이 질문군으로 평가한다. 지금은 GOV.UK Chat에 무엇이든 물을 수 있지만, 비즈니스·세금 쪽 정확도를 올리는 동안 다른 영역(예: 교육부 관련 주제)의 정확도가 내려갈 수도 있다. 그래서 방대한 계량 측정이 필요하고, 파라미터 조합을 조정하며 답변 생성 기술을 바꿔가며 테스트하고 있다. 사용 중인 대형언어모델도 바꿔가며 실험 중이며, 목표는 90% 이상이다.
부정확성 완화의 다른 축은 ‘디자인’이다. 이를 스펙트럼으로 본다. 정확도가 80% 수준일 때는 답변 형식을 더 통제한다. 단계별 출력, GOV.UK 원문 직접 인용, 특정 여정에 내장해 ‘최종 답’이 아니라 보조 도구로 위치시키기 등이 가능하다. 반대로 100%에 가까운 정확도라면 개방형 대화 방식으로 갈 수 있다. 그러나 현재 기술은 본질적으로 100%에 도달하지 못한다. 따라서 우리는 화면의 스펙트럼 어딘가에 머물 것이다. 기술적으로 가능한 것과 디자인적 안전장치를 결합하는 적절한 조합을 찾는 일이 핵심이다.
다음 단계로, 우리는 비즈니스 사용자를 대상으로 GOV.UK Chat의 테스트를 계속하며 최적의 용례(use case)와 더 틈새적인 잠재 사용자군을 찾겠다. 점진적으로 더 확장된 규모의 테스트도 진행하겠다.
한편 AI 팀의 또 다른 축은 GOV.UK의 ‘운영 방식’ 개선이다. GOV.UK 뒤에는 콘텐츠를 발행·유지하는 다양한 콘텐츠 팀 등이 있다. 퍼블리셔 여정 개선 방안을 탐색하고 있다. 예컨대 콘텐츠 디자이너의 작성 속도 향상, 피드백 요약, 콘텐츠 자산 전반의 유사 콘텐츠 탐지 등 LLM이 강점을 보이는 기능들을 실험할 예정이다. 향후 몇 달간 다양한 실험을 이어 가겠다. 발표는 여기까지이다. 질문을 받겠다.

Cara Kane:
좋습니다, 조시. 질문이 몇 가지 있습니다. 헬렌 개스코의 질문입니다.
“부정확한 정보가 시스템에 들어가 대형언어모델의 에코챔버에서 증폭되어 결국 ‘사실’처럼 굳어지는 위험은 우려하지 않습니까?
많은 부처가 레거시 콘텐츠를 유지 보수할 역량이 부족한데, 이 점도 위험을 키우는 듯합니다.”

Josh Davey:
정확도 문제를 다루기 위해 여러 가지를 고려 중입니다. 현재 GOV.UK Chat은 GOV.UK 내 약 40만 페이지에 해당됩니다. 따라서 잡음이 많습니다. 예컨대 2015년 세무 문서처럼 더 이상 유효하지 않은 자료도 잡힙니다. 시점상, 그리고 비즈니스·세금 영역과의 관련성 측면에서 ‘무관한 것’을 걸러내는 작업은 방대한 일입니다. 지금 하는 일의 큰 부분은 ‘올바른 콘텐츠’에 초점을 맞춰 잘못된 정보를 줄이는 방법을 찾는 것입니다.

Cara Kane:
감사합니다. 또 하나 매우 기술적인 질문이 있습니다. 페데로 자모의 질문입니다.
“일반 검색창, 지능이 낮은 챗, ChatGPT 기반 챗 사이에서 사용자가 체감하는 효율성과 만족도의 차이를 비교해, AI가 제공하는 추가 가치에 대한 사용자의 이해가 현재의 부정확성을 상쇄하는지 평가할 계획이 있습니까?”

Josh Davey:
핵심을 정리하면, 우리도 그 비교를 고려하고 있습니다. GOV.UK Chat의 편익과 투자 대비 효과(ROI)를 평가할 때, 사람들이 GOV.UK에서 정보를 찾는 다른 메커니즘과 비교해야 합니다. ‘친화적 경쟁자’로 검색을 떠올릴 수 있습니다. 챗 운영 비용과 검색 운영 비용을 비교할 수 있을 것입니다.
또 중요한 측정 과제는 사람들이 그 정보를 ‘무엇에 쓰는가’입니다. 비즈니스 페이지에서 챗을 열고 답을 얻은 뒤, 사용자는 무엇을 하는가. 그 정보는 어떤 가치를 창출하는가. 더 확대한 규모의 테스트로 나아가며, 우리는 분석 지표와 심층 정성 인터뷰를 병행해 비즈니스 사용자의 실제 활용을 파악하려 합니다.

Cara Kane:
발표 후에 혹시 더 질문이 있으면 팀 연락처를 채팅에 남겨 주면 좋겠습니다. 세션 말미에도 시간이 있을 것입니다. 그때 추가 의견이나 피드백을 주셔도 됩니다.
또 다른 질문이 있습니다.
“챗봇이 모를 때 할루시네이션으로 거짓 정보를 주기에 그래서 정확도가 80%인가요, 아니면 GOV.UK의 정보가 오래돼서 그런가요?”라는 질문입니다.

Josh Davey:
우리가 ‘할루시네이션’을 정의하는 방식이 몇 가지가 있습니다. 하나는 LLM이 학습 시점의 사전 지식을 갖고 있다는 점입니다. 여기서는 오픈AI가 학습시킨 지식입니다. 그래서 때로는 다른 곳에서 학습한 정보를 끌어와, 영국 맥락에서도 미국식 철자를 쓰는 식의 현상이 나타납니다. 또 다른 경우는, 정말로 답이 없으면 지어내는 경우입니다.
아주 초기에 테스트할 때(지금은 그렇지 않다) “국가보험번호(National Insurance number)의 문자들은 무엇을 의미하나?”라는 질문이 있었는데, GOV.UK에 답이 되는 콘텐츠가 없자 “N이 있으면 남성, F가 있으면 여성” 같은 식으로 전혀 틀린 답을 만들었습니다. 이 콜에 계신 분들 대부분의 NI 번호에는 그런 문자가 없을 것입니다. 요컨대 할루시네이션 양상은 여러 가지가 있고, 정확도를 개선하려면 동시에 돌봐야 할 접시가 많습니다.

Cara Kane:
아주 흥미롭습니다. 고맙습니다, 조시. 그럼 다음 발표로 넘어가겠습니다.

GOV.UK One Login Improving cross-government understanding (Matt Ashton and Monika Most)

Matt Ashton:
안녕하세요. 오늘은 GOV.UK 원로그인에 관한 세 가지 발표 중 첫 번째로, 범정부 이해 증진을 주제로 이야기하겠습니다. 나는 인터랙션디자이너 매트 애슈턴입니다. 동료 모니카 모스트는 서비스디자이너입니다.
혹시 모르는 분을 위해, GOV.UK 원로그인은 정부 서비스 접근을 위한 신규 로그인·신원확인 방식을 의미합니다. 언젠가는 하나의 이메일과 비밀번호로 모든 정부 서비스를 이용할 수 있게 될 것입니다.
우리는 중앙 UCD 팀에서 일하고 있습니다. 이 팀은 프로그램 전반의 핵심 엔드투엔드 서비스에 대한 전략적 UCD 과제를 수행하고, 고가치 UCD 자산에 투자하며, 접근성과 UCD 기준을 이끌어 갑니다. 오늘은 원로그인에 대한 범정부 이해를 높이기 위해 최근 수행한 작업을 보여 주겠습니다.
도전과제부터 설명하겠습니다. 도입(adoption) 팀은 부처 및 중앙정부 서비스 팀과 긴밀히 협업하며 원로그인의 확산을 지원합니다. 이 협업 과정에서, 우리 서비스를 사용하려는 팀들이 사용자 여정을 더 자세히 살펴보고, 자신들의 서비스에 어디서 어떻게 맞물리는지 이해하길 원한다는 사실을 알게 되었습니다. 다양한 사용자 경로와 각 경로의 세부를 이해해야, 끊김 없는 경험을 만들 수 있기 때문입니다. 하지만 우리의 서비스는 다양한 사용자와 서비스 요구를 충족하기 위해 지속적으로 진화하고 있으며, 빠른 속도로 작업하고 있어 난도가 높습니다.
이에 몇 가지 가이드를 정했습니다.
첫째, 사용자에게 ‘진짜와 거의 동일한’ 경험을 제공해야 합니다. 그래서 GOV.UK 프로토타입 키트를 사용해 서비스의 현실적인 버전을 만들기로 했습니다. 이 방식은 실서비스와 거의 동일한 모양·동작을 제공합니다. 디자인시스템의 템플릿·컴포넌트·패턴으로 페이지를 빠르게 만들 수 있고, 사용자 입력에 따라 다른 페이지를 보여 주는 실서비스 동작을 모사합니다. 또한 공공 부문에서 익숙한 도구이므로, 손쉽게 호스팅·공유할 수 있습니다.
둘째, 프로토타입은 가능한 한 단순하게 유지해야 합니다. 사용이 단순해야 하고, 우리가 업데이트하기도 쉬워야 합니다. 예컨대 분기 질문에만 답하면 여정을 자유롭게 클릭해 지나가도록 했습니다. 자주 사용하는 이용자를 위해 내비게이션 단순화도 탐색했습니다. 코드 구조도 정돈해, 서비스 팀이 내려받아 자체 프로젝트에 활용하기 쉽게 했고, 우리가 신뢰 가능한 ‘단일 진실의 원천’으로 유지·보수하기도 쉽도록 했습니다.
셋째, 작게 시작해 반복합니다. 이번 달에 엔드투엔드 서비스의 주요 경로부터 만들기 시작했고, 사용자 피드백에 따라 더 많은 분기와 개선을 연속적으로 추가했습니다. 결과로, 우리는 3주 조금 넘는 기간에 엔드투엔드 서비스의 HTML 프로토타입을 만들었습니다. 배포 전에 사용자 테스트도 했습니다.
이 프로토타입이 제공하는 기능을 몇 가지 말씀드리겠습니다.
첫째, 서비스 팀이 실제 사용자처럼 여정을 클릭해 체험할 수 있습니다. 일부 서비스는 신원확인을 요구하지 않으므로, 각 서비스 요구에 맞춰 ‘해당 시나리오만’ 살펴볼 수 있습니다.
둘째, 페이지 인덱스를 통해 엔드투엔드 프로토타입의 특정 지점으로 점프할 수 있습니다. 여정에 익숙한 빈번 사용자용 기능입니다. 많은 페이지가 유사하다는 점을 고려해 그리드 리스트를 사용했습니다. 유지보수 효율을 위해 각 페이지의 썸네일은 iframe으로 구성해, 기존 페이지의 콘텐츠가 바뀌면 인덱스도 자동 반영되도록 했습니다. 매번 전체를 클릭해 지나가지 않아도 된다는 점, 여정의 조감도를 제공한다는 점에서 초기 피드백이 매우 긍정적이었습니다.
셋째, 앱 여정의 인터랙티브 버전을 탐색할 수 있습니다. 접근성 있고 인터랙티브한 대체물을 요청받아, 정적 이미지 대신 상호작용 형식을 도입했습니다. iOS의 주요 경로부터 시작했고, 안드로이드와 추가 분기도 곧 추가할 예정입니다. 데스크톱에서는 중앙의 모바일 프레임 안에 앱 화면을 보여 주며, 화면 크기에 맞춰 적응합니다.
넷째, 프로토타입 전반에 노트와 옵션을 배치해 추가 맥락을 제공했습니다. 실서비스와의 혼동을 줄이기 위해, 라이브 서비스에서 일반적으로 쓰지 않는 GOV.UK 팔레트 색을 사용해 일관된 커뮤니케이션 스타일을 만들었습니다. 알림 배너는 해당 지점에서의 선택지(예: 이메일, 문자 발송)를 제공하는 데 사용했습니다. 패널 컴포넌트로 단계 전환 페이지를 만들어, 서비스 팀이 사용자가 여정의 어느 단계로 넘어가는지 이해하도록 했습니다. 여기서 중요한 정보나 지침을 전달해, 다음 단계에 대한 기대치를 관리합니다. 프로토타입의 노트와 옵션에 대한 초기 피드백도 긍정적이었습니다. 이제 모니카가 다음 계획을 설명해드리겠습니다.

Monika Most:
프로토타입은 한 달 전 프로그램 전반의 동료들에게 공개했습니다. 다음 단계는 두 가지입니다.
첫째, 지금 프로토타입은 서비스의 ‘주요 경로’를 반영합니다. 아직 추가해야 할 단계와 경로가 남아 있습니다. 다음 버전에서 이를 확장할 계획입니다.
둘째, 라이브 서비스 디자인이 반복·개선될 때 프로토타입을 어떻게 유지·갱신할지 프로세스를 정립합니다.
우리는 시나리오 기반 접근으로 이 과제를 풀기 시작했습니다. 다양한 유지 모델의 장단점을 논의하고, 각 모델의 실행 가능성을 이해관계자들과 검토했습니다. 현재는 중앙 UCD 팀이 수동으로 업데이트·유지하지만, 지속 가능하지 않습니다. 단계적 유지 전략을 도입하겠습니다. 궁극적으로는 자동화된 유지 모델로 이동하는 것을 목표로 합니다. 다만 타당성 탐색이 더 필요합니다. 그동안은 프로그램 전반의 동료들과 협력해, 라이브 서비스에 변경이 생기면 알림을 받는 체계를 만들고, 중앙 UCD 팀이 프로토타입을 업데이트하는 방식을 취하려고 합니다.
보다 넓게 보면, 이 프로토타입이 프로그램 전반의 팀에 가치를 주는 기회가 보이기 시작했습니다. 최신 디자인 자료가 필요한 프레젠테이션·워크숍·다른 프로토타입 작업에서 ‘교차 참조 도구’로 쓰이고 있고 연구 목적으로도 활용되고 있습니다. 또 프로그램의 콘택트센터(원로그인 계정 생성 중 어려움을 겪는 이용자에게 1:1 지원 제공)는, 이 프로토타입의 ‘모더레이티드 버전’을 운영 도구로 써서 지원 품질을 높이고, 교육 모듈에 포함하는 방식을 탐색하고 있습니다.
이처럼 다양한 사용사례와, 기존 업무 프로세스에 프로토타입(혹은 그 일부)을 통합하려는 관심 증가는, 이 프로토타입이 프로그램 차원의 자산으로서 가치를 가진다는 점을 보여 줍니다. 팀 간 협업을 돕고, 작업을 더 쉽고 빠르게 하는 새로운 자산으로 발전할 잠재력도 보입니다. 여기까지입니다.

Monika Most:
더 알고 싶거나 관심이 있으면, 중앙정부에 계신 분들은 여기 적어 둔 범정부 슬랙 채널로 연락하면 됩니다. 또는 GOV.UK의 서비스 페이지에서 더 읽을 수도 있습니다. 곧 채팅에 링크를 올리겠습니다. 감사합니다.

Cara Kane:
감사합니다, 모니카와 매트. 이그나시아가 또 응원을 보내 주었습니다. “훌륭한 작업이다. 매우 유용해 보이고 잠재력이 크다.”라는 메시지이다. 그리고 아누다가 질문을 했습니다.
“원로그인이 단일 ‘ID 체크 앱’으로도 이어지는가요? 현재는 ID 체크 앱이 약 4개가 있습니다.”
모니카나 매트가 답하시겠어요? 원하시면 제가 해도 됩니다.

Matt Ashton:
제가 답하겠습니다. 로드맵의 계획은, 원로그인이 ‘하나의 솔루션’을 제공한다는 방향입니다. 계정 생성뿐 아니라 정부 서비스 이용을 위한 신원확인까지 포함합니다. 이것이 민간이나 제3자가 사용하는 기존 ID 체크 앱들을 ‘대체한다’는 뜻은 아닙니다. 다만 로드맵상으로는 현재 정부 전반 약 30개 서비스가 우리와 통합되었고, 최근 HMRC와 프라이빗 베타로 연결되었습니다. 방향성은 그쪽입니다. 다만 갈 길이 멉니다. 매우 많은 서비스와 최종사용자가 있으며, 기술이 목적에 맞는지 확실히 해야 합니다.

Cara Kane:
또 다른 질문입니다.
“원로그인을 지방정부에도 롤아웃할 로드맵이 있습니까? 연계 기회가 커 보입니다.”

Matt Ashton:
그 부분은 논의 중입니다. 현재의 예산 심사(Spending Review) 범위와 로드맵에는 포함되어 있지 않습니다. 그러나 검토·논의는 진행 중입니다. 다만 현행 로드맵에는 아직 없습니다.

Cara Kane:
다른 질문이 더 없으시면, 채팅에 계속 남겨 주시고, 다음 발표로 넘어가겠습니다. 킴께 마이크를 넘깁니다.

GOV.UK One Login Designing more secure user journeys (Kim Clayden)

Kim Clayden:
안녕하세요. GOV.UK 원로그인의 ‘더 안전한 사용자 여정 디자인하기’를 주제로 이야기하겠습니다. 저는 시니어 콘텐츠디자이너 킴 클레이든입니다.
앞서 매트가 말했듯, 원로그인은 언젠가 GOV.UK의 모든 서비스에 로그인하는 방식이 됩니다. 사용자는 서비스에 로그인하고, 필요 시 신원확인을 진행하며, 그 증명을 다른 서비스에서 재사용할 수 있습니다. 나는 원로그인의 인증(Authentication) 팀에서 일하고 있습니다. 이 팀은 GOV.UK 원로그인 생성과 로그인 과정을 담당합니다. 현재 이 사용자 여정을 더 안전하게 만들기 위한 변경을 진행하고 있습니다.
먼저 현재 여정을 간단히 보겠습니다. 핵심은, 원로그인에서는 ‘이메일 주소’가 사용자 이름(username)이라는 점입니다. 사용자는 이메일 주소와 비밀번호, 그리고 2단계인증으로 로그인하게 됩니다. 사용자가 원로그인을 만들 때 이메일 주소를 입력하면, 기존 계정이 없으면 보안코드를 보내 이메일을 검증합니다. 그다음 비밀번호 생성, 2단계인증 설정 등으로 이어집니다. 만약 입력한 이메일 주소로 이미 원로그인이 있으면, 그 사실을 알려 주고 로그인으로 유도합니다. 반대로 로그인을 선택해 이메일을 입력했는데 그 이메일로 원로그인이 없으면, 그 사실을 알려 주고 계정 생성을 유도합니다.
이렇게 설계한 이유는 초기 사용자 연구에서 ‘계정 혼동(account confusion)’ 증거를 확인했기 때문입니다. 즉, 실제로는 계정이 없는데 있다고 확신하는 사용자들이 있었습니다. 이들에게 이렇게 초기에 사실을 알려 주면, 곧바로 올바른 경로로 수정할 수 있었습니다.
하지만 여기에는 보안 문제가 있습니다. 특정 이메일 주소가 원로그인의 ‘유효한 사용자명인지’를 노출하면, 사용자 보안에 있어서는 위험이 될 수 있습니다. 사기범이 여러 방식으로 악용할 수 있습니다. 원로그인의 초기에는 이 위험을 감수할 수 있었지만, 지금은 HMRC처럼 가치가 높은 서비스가 온보딩되고, 재사용 가능한 신원증명도 제공되므로, 사용자를 더 강하게 보호해야 합니다. 사용성(Usability)과 보안(Security)의 균형 문제이며, 지금이 그 균형을 다시 점검할 시점입니다. 우리는 보안팀과 긴밀히 협업했습니다.
생각보다 큰 도전이었습니다. 사용자명의 유효성을 로그인 단계에서 감추는 ‘확립된 패턴’이 있기 때문입니다. 보통은 사용자명과 비밀번호를 같은 화면에서 입력하게 하고, 오류 메시지로 어느 쪽이 틀렸는지 특정하지 않도록 합니다. 정부 게이트웨이도 그런 방식을 사용합니다. 그러나 원로그인은 사용자명이 이메일이기 때문에, ‘계정 생성’ 여정만으로도 이메일의 유효성을 알아낼 수 있는 문제가 남게 됩니다. 모든 사용자가 스스로 계정 보유 여부를 정확히 안다면 문제가 없겠지만, 분석 데이터는 계정 혼동이 여전히 존재함을 보여 줍니다. 따라서 ‘있다고 믿지만 없는 사람’과 ‘만들려 하지만 이미 가진 사람’ 모두를 위한 디자인이 필요합니다.

우리는 대규모 서비스들이 이 두 가지 ‘불행 경로(unhappy path)’를 어떻게 다루는지 검토했습니다. 살펴본 여러 서비스들은 다양한 접근을 했습니다. 다수는 인라인 오류로 “이 이메일은 이미 사용 중”을 노출했습니다. 이것은 원로그인에는 부적절합니다. 여전히 답을 쉽게 노출하기 때문입니다.
캡차를 쓰는 곳도 많았는데, 접근성 문제로 채택하기 어렵습니다. 나머지 접근은 ‘사용자의 이메일’을 활용하는 것이었습니다. 보안팀 자문 결과, 이는 보안에 도움이 되지만, 구현 방식의 사용자친화성이 떨어지는 경우가 있었습니다. 예컨대 “코드를 보내 계정을 만들게 하겠다”고 말해 놓고는 실제로는 “이미 계정이 있다, 로그인하라”는 메일만 보내고 ‘어떻게’는 안내하지 않거나, “비밀번호 재설정 링크를 보내겠다”고 해 놓고 아무것도 보내지 않는 식이었습니다.
그럼에도 ‘사용자의 이메일을 활용’하는 접근은 원로그인에 잠재력이 있다고 보았습니다. 우리는 사용성을 개선한 방식으로 여정을 재설계했습니다. 계정 생성과 로그인 두 여정 모두에서, 사용자가 ‘이메일 보안코드’를 받고 입력하기 전에는 그 이메일에 원로그인이 있는지 없는지를 드러내지 않습니다. 생성 여정에서는 화면 순서를 조정했습니다. 이제 원로그인 생성을 선택한 모든 사용자에게 우선 이메일 코드를 보냅니다. 그리고 코드를 입력한 뒤에야, 해당 이메일로 기존 계정이 있는지를 알립니다. 로그인 여정에서는 사용자명과 비밀번호를 같은 화면에서 입력하게 하고, 오류 메시지는 어느 쪽이 틀렸는지 노출하지 않습니다. 그리고 ‘비밀번호 재설정’을 진행해 이메일 코드를 받은 뒤에야, 해당 이메일로 원로그인이 없다는 사실을 알려 줍니다.
이 설계는 “이메일 또는 비밀번호 중 하나가 틀렸다”는 메시지를 받으면, 대부분 사용자가 ‘비밀번호가 틀렸다’고 추정해 재설정을 시도한다는 가정에 기대고 있습니다. 이는 과거 연구 결과에 근거하며, 이번 연구에서도 검증하고자 했습니다. 아주 초기 인사이트를 공유하면(불행 경로 테스트는 본질적으로 어려우므로 감안해야 합니다), 계정 생성을 시도했을 때 “이미 원로그인이 있다”는 안내를 받으면, 대체로 “예전에 만들어 두고 잊었다”고 받아들이며 여정을 완료할 수 있었습니다. 반면 로그인 여정에서는 혼란을 보고했습니다. 오류가 비밀번호 때문인지 이메일 때문인지 모르겠다는 것입니다. 의도한 바와 같습니다. 좋은 점은, 이런 상황에서 다수 사용자가 비밀번호 재설정을 시도한다는 가정이 검증되었다는 것입니다. 재설정 흐름을 타면, 결국 “해당 이메일로는 원로그인이 없다”는 사실을 알게 되고, 그 다음 계정 생성을 이어 갈 수 있습니다.
마지막으로, 라이브 반영 후에는 분석 데이터와 사용자 지원 피드백을 모니터링하여 현행 여정과 비교한 영향을 확인하고, 디자인을 반복 개선하고자 합니다. 보안과 사용성은 늘 균형 과제이며, 여정에 일정한 ‘비노출(Obscurity)’을 도입하면 마찰이 조금 늘어납니다. 그러나 우리의 연구와 벤치마킹 결과를 종합하면, 현재 시점의 원로그인에는 이 균형이 최선이라고 판단하고 있습니다. 경청해 주셔서 감사합니다.

Cara Kane:
질문이 채팅에 보이지 않습니다. 손든 분들은 많습니다. 다음 세션으로 넘어가겠습니다. 필요하면 나중에 돌아오겠습니다. 감사합니다, 킴. 계속 진행하죠. 채팅에 질문을 계속 올려 주시기 바랍니다.
여기 에밀리의 질문이 하나 있습니다. 지금 타이핑 중인 것 같습니다.
“누군가 이메일 주소를 여러 개 가지고 있다면 어떻게 관리하나요?” 아주 좋은 질문입니다. 네, 좋은 질문입니다.
“여러 이메일 주소가 있고, 원로그인에 어떤 주소를 썼는지 기억나지 않을 때”라는 보충도 달아 주셨습니다.

그 경우 사용자는 한 이메일 주소로 로그인 흐름을 먼저 시도할 것입니다. 만약 그 주소로 GOV.UK 원로그인이 아니라면 “원로그인이 없습니다” 화면이 보일 것입니다. 그러면 새로 만들거나 다른 이메일 주소를 시도할 수 있는 선택지가 주어집니다. 다른 후보 주소가 있다면 그때 다른 주소로 시도하면 됩니다. 답이 되었는지요.

Ramina:
신원 도용이 진행 중이거나 시도되는 시나리오에 대해서도 검토했는지요?

Kim Clayden:
신원 도용과 관련해 진행 중인 작업이 많습니다. 다만 이 프로젝트 범위에 직접 포함되지는 않았습니다.

Matt Ashton:
도움이 될 맥락을 보태겠습니다. 프로그램 내에 ‘One Login Home’ 팀이 있으며, 활동 내역 확인, 계정 침해 의심 시 알림 같은 기능을 다루고 있습니다. 해당 기능은 진행 중인 작업이며, 조만간 정식 공개될 것입니다.

Emily:
한 사람이 서로 다른 이메일로 계정을 두 개 만들면 어떻게 되나요?

Kim Clayden:
두 계정으로 각각 로그인할 수 있습니다. 개인용과 업무/비즈니스용을 나눠 쓰는 사례를 떠올리신 것 같습니다. 서로 다른 이메일로 두 개의 원로그인을 만드는 것을 막지는 않습니다. 어느 쪽으로든 표준 절차로 로그인할 수 있고, 잘못 들어갔다고 느끼면 로그아웃하고 다른 이메일로 다시 로그인하면 됩니다.

leis:
문자/이메일 기반 MFA에서 더 안전한 인증앱으로 전환하는 로드맵이 있나요?

Kim Clayden:
이미 서드파티 인증앱(예: Authy, Google Authenticator, Microsoft Authenticator)을 지원하고 있습니다. 다만 사용자 선호는 문자 메시지 MFA가 약 95%로 매우 높고, 인증앱은 월평균 약 5%가 사용합니다. 보안 강화나 포용성 확대를 위한 다른 인증 방법도 로드맵에 올라가 있습니다.

Cara Kane:
감사합니다, 킴. 질문도 감사합니다. 이제 마지막 발표로 넘어가겠습니다.
GOV.UK One Login 182일간의 접근성 팀 진행상황 (Shaun Conner)

Shaun Conner:
먼저 양해를 구하겠습니다. 두 살짜리 아이가 오늘 유난히 활발합니다. 배경에서 울음이 들릴 수 있습니다만 제 울음소리는 아닙니다. 최선을 다하겠습니다.
원로그인 접근성 팀이 출범한 뒤 첫 6개월 동안 무엇을 했는지 공유하겠습니다. 현재 팀은 소수 정예입니다. 저(숀 코너)와 시니어 접근성 스페셜리스트 대런 윌슨이 있습니다. 저는 GDS 이전에 Monzo에서 접근성 전략을 수행했고, 그 전에는 HMRC 접근성 리드, 그 전에는 NHS 리드 개발자였습니다. 대런은 프로그램에서 개발자로 일하다가 시니어 접근성 스페셜리스트로 전환했습니다.

새 팀이 가장 먼저 한 일은 프로그램의 지형을 파악하는 일이었습니다. 접근성 관여가 필요한 작업 채널을 식별해야 했습니다. 접근성 업무는 ‘횡단’ 성격이 강해 목록이 꽤 길어졌습니다. 그러나 이는 팀이 커질 때까지 중간기 자원계획을 세우는 데 도움이 되었습니다. 우리의 핵심 초점은 ‘양보다 질’이었습니다. 한꺼번에 10가지를 붙잡으면 임팩트와 품질이 희석됩니다.
우리는 ‘워크스트림’ 8가지를 정의했습니다. 복잡도·임팩트·긴급도가 제각각이었습니다. 각 워크스트림마다 ‘지금/다음/나중’ 할 일을 상위 수준에서 정리했습니다. HMRC 온보딩이 동시에 진행 중이라 기획에만 매몰될 수 없었습니다. 이 작업은 리드 입장에서 나와 대런의 번아웃을 관리하는 데 특히 유용했습니다. 접근성 분야의 번아웃은 지금 매우 심각합니다. 따라서 무엇에 레이저 포커스를 둘지를 분명히 했습니다.
우선순위를 정해 즉시 필요한 일부터 교부했습니다. 주요 성과는 다음과 같습니다.
— 원로그인 웹 여정의 엔드투엔드 접근성 감사 수행. 도출 이슈의 규모가 컸으나 거의 모두 해소했다.
— 접근성 성명(Accessibility Statement) 최신화. 초기에는 실제 상태를 반영하지 못했으나 지금은 반영한다. 팀/파드가 여정을 분담해 갖고 있어 정합성 확보가 복잡했으나 정리했다.
— 사용자 지원 챗봇의 개선 지원. 최초 상태는 매우 비접근성이었으나 지금은 ‘대체로’ 접근 가능 수준으로 끌어올렸다. 챗봇에서 이는 큰 성과이다.
— 프로그램 전반의 자동화 접근성 테스트 접근 정의. 코드 품질 상향의 빠른 승리(quick win)로 본다.
— 비기능요건(NFR) 중 접근성 항목 갱신·구체화.
— 프로그램 성장에 맞춘 접근성交付 프로세스 정의로 지속가능성과 확장성 확보.
— 퀵윈 실행 및 역량 구축 세션 진행(예: 사기(Fraud) 파드 대상 자동/수동 테스트와 결과 해석 교육).

우리가 중요하게 여기는 것은 ‘올바른 타이밍’에 가치를 제공하는 일입니다. 접근성이 체크박스가 되면 비용만 커지게 됩니다. 끝에 가서 재개발·재디자인으로 기술부채를 갚는 것보다, 애초에 문제를 예방하는 것이 국민 세금을 아낄 수 있는 방향입니다. 그래서 우리는 디자인 리뷰 보드에 정식 참여하고, 제품 스티어링 그룹에도 발표했습니다. 팀들을 ‘감시’하는 존재가 아니라, 협업 가능한 파트너로 보이길 원합니다. 범정부 커뮤니티에도 적극 참여해 모범사례를 공유하겠습니다.
이 일이 지금 그 어느 때보다 중요합니다. 온보딩 서비스가 30개에 달하고, 사용자 규모가 수천만으로 확장될 수 있습니다. 어제 발표된 Family Resources Survey 최신판의 장애 관련 통계를 보면, 아동은 2%p, 근로연령 성인은 5%p 상승했습니다.
5%p는 매우 큰 폭의 상승입니다. ‘5명 중 1명’에서 ‘4명 중 1명’으로 바뀌었습니다. 보고서를 꼭 보시기 바랍니다.

또한 사용자 세분화 조사에서 보조공학(Assistive Tech) 사용 비중이 우리가 예상한 것보다 훨씬 크다는 사실을 확인했습니다. 규정 준수만으로는 충분하지 않습니다. WCAG는 바닥선일 뿐입니다. 우리는 실제 보조공학 사용자에게 ‘그럭저럭 완주’가 아니라 ‘좋은 경험’을 제공해야 합니다.
이를 위해:
— 사용자 연구 역량을 적극 활용해 ‘실사용자’ 문제를 푼다. 특히 장애 사용자 피드백에 기반해 반복한다.
— 핵심 사용자군에 대한 연구 베이스라인을 세우고 개선을 계량한다.
— WCAG 바깥의 사용성 장벽을 정의·보고·해결한다. 이는 측정이 어려운 분야지만 불가능하지 않다. 우리가 해낼 과제라 믿는다. 세계 최고 수준의 접근 가능·사용 가능한 서비스를 지향한다.
— 문화 조성에 투자한다. 각 역할(프로덕트, 딜리버리, 리더십 등) 맥락에서 무엇을 할 수 있는지 교육한다.

다음 단계는 거버넌스·어슈어런스를 마련해 팀이 성공하도록 기반을 닦는 일, 문서·도구 체계를 보강해 디자인/콘텐츠/코드 품질을 끌어올리는 일, WCAG 2.2 중 ‘Accessible Authentication’이 원로그인에 의미하는 바를 구체화하는 일입니다. 모두가 로그인해야 하는 시스템인 만큼 이것은 핵심 과제입니다.
준수 모델을 구축해 지속적·효과적 접근성 전략을 만들겠습니다. 오늘 같은 쇼앤텔도 더 자주 하며 범정부 공유를 확대하겠습니다. 저나 대런, 혹은 팀에 연락하고 싶다면 공유 인박스나 제 개인 이메일로 연락해주시면 됩니다. 
질문이 있을까요? 

Cara Kane:
질문을 채팅에 남겨 주세요. 지금은 없는 것 같습니다.
그럼 마무리로 넘어가겠습니다.
(화면 공유 재시도)

모든 발표자께 감사드립니다. 그리고 참석해 주시고 훌륭한 질문과 참여를 보여 준 여러분께 감사드립니다.
GDS의 더 많은 작업을 알고 싶다면 GDS 블로그, 그리고 GOV.UK, 접근성, 디자인, 서비스 전용 블로그가 있습니다.
인스타그램, X, 링크드인에서도 소식을 공유하고 있습니다. 오늘 녹화본은 유튜브에 올릴 예정입니다.
동료와 공유하거나 다시 보고 싶으면, 방금 언급한 소셜 채널에서 링크를 확인하면 됩니다.
오늘 함께 오후 시간을 보내 주셔서 정말 감사합니다. 모두 좋은 오후 보내시기 바랍니다.